はてなブックマーク

この記事は 🎄GMOペパボエンジニア Advent Calendar 2022 - Adventar 14日目の記事です。 私は2021年8月1日から2022年3月末まで育児休業を取得しました。育児休業中の子育てや過ごし方、復帰後の仕事の振り返りを書いていこうと思います。 産まれてから育休開始まで 会社からは休むことを勧められたが、仕事の区切りが悪く中途半端な状態で休みに入りたくなかったので、最初の一ヶ月は仕事をしながら育児をした。 産後ということもあり妻を夜寝かせてあげる必要があり、当面の間夜のお世話はメインで担当することにしていた。自分自身の寝つきが悪く、何度も起こされるのがつらいため、ずっと起きているという選択をした。特に産まれてから3 ~ 4ヶ月くらいは、ミルクを飲んで寝る → 数時間後に起きるというわけではなく、起きたら割とグズグズで起きているタイプだったので、この選択は正解だ

あまり大きな成果が出せずに思い悩んでいるジュニアエンジニアの方に意識して欲しいことがある。ジュニアエンジニアとは、一人前の手前のエンジニアのことである。実績を残すこと以上に、成長するためのアクションを取れているかが求められている。成長途中なので、バーンとした実績を残すことは現実的に難しいかもしれない。だがそこでめげず成長のための種をまき続けて欲しい。 ミーティング中に分からないことがあれば躊躇せず聞く。もし都合が悪ければ「後でフォローするから後で話しましょう！」となるだけで誰も損しない。その都度質問することが当人に有益なのはもちろんだが、他の人が質問しやすい雰囲気を醸成することに繋がる。なんなら先輩もその環境に助けられるかもしれない。チームの良い文化を作ることに貢献するというのは誰にでもできることではない。 PRを作る時、分からないから既存の処理をコピペするという経験は誰にでもあると思う。

CodeKeeperというGemをリリースした。循環的複雑度、ABCソフトウェアメトリクス、クラスの行数という品質面にまつわるメトリクスを取得するGemで、Rubyファイルを対象にしている。 github.com 動機 主に以下の3つである。 Four keysのような生産性を測る指標とは別に、内部的な品質に関する指標を取りたかった 継続的な改善を続けた結果としての変化を見たかった コードを解析するコードを書いてみたかった Saasなどもあるが自分で書いてみたかった Gemを1から書いて公開したことがなかったのでやりたかった 使い方 メトリクス・出力形式 対応しているメトリクスは 循環的複雑度（ファイル） ABCソフトウェアメトリクス（ファイル） クラスの行数 である。 前者2つは、実装の簡便さを鑑みファイル単位とした。また、出力について、取得したメトリクスをBigQueryなどに取り込め

シェル変数の末尾の文字を削除する シェルスクリプトを書く際、変数の末尾についた余分な記号を取りたいとき、以下のように行っていた（以下、"bananapencilbook"という文字列から"book"を削除する）。OSはCentOS、シェルはbashです。 $ echo ${testvar} bananapencilbook $ echo ${testvar} | sed -e 's/book$//g' bananapencil 上の方法は末尾の文字列以外にも適用できるので楽なのだが、他に何かないか探していたところ、 同じことが以下のようにできるらしい。 $ echo ${testvar%book} bananapencil %以下の文字列に後方一致するものを削除するという機能なのだが、他にも便利な記法があるようで、 以下にまとまっている。 qiita.com あるものは使いましょう。とりあ

serverless時代のテスト戦略（仮）を聴講したので、そのメモと感想を書きました。 資料が後日公開されるとのことなので、そのスライドと一緒に読んで頂ければ分かりやすいかと思います。メモなので流れが異なりますがご了承ください。 テーマとしては、テストコードのないlambdaにどう向き合っていくかというお話です。 ハッシュタグは#testlambdaでした。 2017.06.21追記: ご本人から資料・動画公開の旨教えて頂きました。ありがとうございます！ すばらしいエントリをありがとうございます！ この講演ですが、先日講演資料とセッション録画が公開されました。— Takuto Wada (@t_wada) June 20, 2017 下記リンクの「D4T7-4　Dev Day トラック 1」が当該講演です。 aws.amazon.com メモ lambdaのテストに関するベストプラクティス

nottegra.hatenablog.com を読んで、思ったことがはてぶコメントに書ききれなかったから、ブログで書いた。思ったより長くなった。 割りと思ったことベースでそのまま書いているので駄文です。あと、会社の元記事も合わせて読んでいますが、認識に間違いがあったらすみません。 はじめに まず最初に、筆者の方には辛い話を共有していただけて本当にありがたいです。色々勉強にになりましたし、今後私にもこのような知見が生きるときがあると思うので、参考にさせて頂きます。 以下に書くことは誰への批判でもありません。客観的に聞いて考えたことです。 思ったこと 複数の事業部が荒く速く進めていることで生じる問題を抑制するために横断的な別の組織が責任を持つようになると、インセンティブが異なる組織になってしまうが、そこに歪みが発生してしまったのだと感じた。事業部は速く進めようとする方にインセンティブ向くけど