マタニティマーク、大丈夫でした

今年の6月から10月まで、マタニティーマークを付けて都内へ通勤していました。
約5ヶ月間、ほとんどお休みもせずに平日は毎日ひとりで電車を使用していましたが、
結果的には、老若男女国籍も問わず、様々な方が席を譲ってくださいました。

初めての妊娠だったので、私も最初はマタニティーマークを付けるかどうか迷いました。
もちろん、懸念するきっかけになったのは、ネット上で散見するネガティブな記事の数々です。

人間の心理として、やはりネガティブな情報はポジティブな情報よりも受け取った際のインパクトが強く、
訴求力も高くなってしまうことは仕方がありません。
ネット検索の結果は、そういった“衝撃的”な事柄の方が拡散されやすく目に付きやすい構造です。

という認識もあり、私の判断は「最大限、身を守れるよう警戒をしながら付けてみよう」となりました。

参考までに、条件は以下の通り。

• 使っていたのは私鉄と山手線の2本
• 通常であれば乗車時間は1時間程度
• ピークタイムは完全にアウトな混雑状況なので、1時間程の時差通勤
• 時短はせず、フルタイムで勤務
• （山手は絶対無理だけど）始発等、出来るだけ座れる電車に乗る

行き帰りの約4本のうち、だいたい3本は座れるような状況でないのですが、
これで平均して2週間に1度は、優先席付近で立っているとどなたかが声をかけてくださる感じ。
あとは運良く近くの席が空くとか、体調みながら気をつけて立っているとかで過ごしていました。

そんな今回の経験から、見えたことは以下。

1. マタニティーマークを付けていて良いことだってあった
2. 子どもと自分を守るのはまず自分
3. 優先席はだれだって座っていていい席
4. 今の行動は未来の妊婦さんのためになるかも
5. どうしてもマタニティーマーク怖かったら安産のお守りとかどうでしょう

それぞれに対して、とても個人的な見解を述べます。
私文章をだらだら書くの大好きなので、面倒な方は気になるトピックだけお読みください。

欲張りな女性こそPG／SEになると良いかも？[1]

2015年度で5年目になる、IT企業（しかもSIer）に勤めるプログラマーだかシステムエンジニア(29)です。
略歴は自己紹介記事を御覧ください。自己紹介 - ルーズリーフ

“欲張り女子こそPG／SE？”タグでシリーズ化して、気ままに記事を書いていく予定です。
ここで言う“欲張り”とは、

オフィシャルな自分の居場所も、プライベートでの願望も、
出来るだけ諦めずに欲しいものはすべて手に入れるんじゃい！！！

という気合いと野望に満ち溢れている感じ、とします。

タイトルに「かも？」と付いているのは、現在検証中のためです。
記事を積み重ねていくうちにタイトルが悲しい方向に変わっていくかもしれません。
飽きっぽいので、途中でやめてしまうかもしれません。
以上あしからず。
女性PG／SEの生きざまの一例として、いつかどなたかのお役に立てば幸いです。

女性のみならず、

• なかなか会社に女性が定着せず困っている
• どうにか支援したいが実際なにが起こるのか／どうしてやればよいかが前例も少なくてわからない

そんな会社運営上の「困った」ときのヒントになることがあるかもしれません。
とか適当なこと言った。

検証予定

1. 1人目の妊娠～安定期[イマココ]
2. 1人目の安定期～産休
3. 1人目の出産～育休明け仕事復帰
4. 子ども1人を抱えて仕事
5. 2人目の妊娠～産休
6. 2人目の出産～育休明け仕事復帰
7. 子ども2人を抱えて仕事
8. キャリアアップと子育て

明文化したせいで、既に1人目のあれこれで挫折する気が･･･
一応、子どもは2人を考えています、兄弟いると楽しかったから。

1人目の妊娠～安定期開始まで

POH6リオちゃん問題をScalaで解いた

前回に引き続き、POH!6の挑戦ログです。

POH6「女子高生プログラマーの大バトル〜コボール文明の逆襲〜」

paiza.jp

今回はリオちゃん、簡単でした。

昨日の今日でコーディングスキル上がってたらびっくりですよね、
さすがに変わるわけがないのです。

とりあえず今回も関数型超入門な、

変数の再代入はしない要するに“var”は使わない！

だけを意識した書き方です。

import java.util.Scanner

object Main extends App {
  val sc = new Scanner(System.in)
  val n = sc.nextInt
  
  def materials(sc: Scanner, ope: Int, vol: Int, water: Float, coffee: Float): (Float, Float) = {
    val mat =
    ope match {
      case 1 => (water + vol, coffee)
      case 2 => (water, coffee + vol)
      case 3 => (rest(vol, water, water + coffee)
                 , rest(vol, coffee, water + coffee))
    }
    if (sc.hasNext) materials(sc, sc.nextInt, sc.nextInt, mat._1, mat._2)
    else mat
  }
  
  def rest(vol: Int, target: Float, total: Float): Float =
    target - target * vol / total
  
  def conc(water: Float, coffee: Float): Int =
    (100 * coffee / (water + coffee)).toInt
  
  val mat = materials(sc, sc.nextInt, sc.nextInt, 0F, 0F)
  println(conc(mat._1, mat._2))

}

再代入なんていらない、ループも使わない、再帰の特訓じゃあああ！

以外に気を付けたところはありません。
再帰の終了条件が sc.hasNext 以外に見つけられれば良かったんですけどね。
カウンター持ちまわるとかは絶対嫌だし･･･。
あとは、最後の濃度計算、def にする必要ないね？とかが個人的な反省点でしょうか。

ついでにつばめちゃんも解きましたが、
あれは簡単すぎたのでなんかおかしなコード思いついたら記事書こうかなぁくらい。

また書くことがなくなってしまった。