2020年3月15日~21日 振り返り

プライベート

やったこと

  • AWS Certified SAPの勉強
  • AtCoder ABC 196 参加

AWS Certified Solution Architect Professionalの試験が今週控えているので、それに向けて模擬試験を解いて解説を読んだり、ドキュメントを読んだりしていました。

あと、土曜日のAtCoderのABCコンテストに初参加しました。

思ったよりも解けなくて悔しい思いをしたのと同時に、競プロ楽しいというのは少しわかった気がします。

リアルタイムでコンテストに参加すると制限時間もあるしスコアにも影響するので、この問題は絶対ACするぞみたいな気持ちにもなりやすいので競ってる感があって楽しいですね!

読書

ソフトウェア品質を高める開発者テスト アジャイル時代の実践的・効率的なテストのやり方

バグを出さない仕組みについて書かれた本。 15章まであるが、薄い本なのでサクッと読めます。

いくつかのテスト手法が紹介されているので、なんとなくでUnitTestを書いていたのであれば参考になると思います。

個人的に興味深かったのが、同じバグでも「要求や設計段階で潰す」場合と「統合テスト時のようにある程度開発が進んだ段階で潰す」場合ではそれに掛かるコストが違うという点です。

要件定義や設計段階でレビューをして、その段階で潰せそうなバグは潰しておくというのは、プロジェクトを効率的に進めるにあたって大切なんだなと感じました。

ただ、ところどころ日本企業がテストコード書かないみたいなディスりが書かれていたのは何か不快な文章なので省けば良いのになと思いました。笑

2021年3月8日 ~ 14日 振り返り

先週の振り返り。

プライベート

AWS Certified Solution Architect Professionalの試験が月末にあり、それに向けて試験勉強をしていることが多かったです。

AWSのドキュメントを読んだりするのはそこまで苦ではないのですが、明らかに今後も絶対使わないだろうというものを試験のために覚えるというのがどうも苦手みたいです。。。

割り切って頑張ってこう。

読書

忙しいビジネスマンでも続けられる 毎月5万円で7000万円つくる積立て投資術

インデックス投資に関する本。

毎月5万円、ボーナス時には追加で20万円、合計100万/年をインデックスファンドに投資するというものです。

まず、投資の前に自分、もしくは家族にとって必要不可欠な出費とは何か考えろと書かれていたのがすごく良いなと思いました。

7,000万という数字は著者が考える夫婦1組で老後25年で最低限必要な支出の総額で、公的年金がどれぐらいもらえるか支出はどれぐらいになるかは個々人の問題となるので、老後にどれぐらい必要なのかは自分で計算した方が良さそうです。

どれぐらいの額が老後に必要なのか、それをどのようにして賄うのか、これをちゃんと考えていくことが大切なんだと思います。

貯蓄・投資し過ぎで、今の自分にお金を掛けられないのももったいないことなので。。。

  • 人生の出費に「優先順位」を付ける
  • 積み立て貯蓄は元本を保証してくれて安全なように見えるがインフレ率のことも考える必要がある
    • 物価上昇に弱い
  • リタイアした夫婦1組の生活費平均が23.7万/月
    • 生活最低限必要な支出
  • 最低限必要な支出 + 趣味や生きがいに使うお金を含めて35万/月と計算した場合
    • 35万 * 12ヶ月 * 25年 => 1億500万
    • そのうち公的年金で毎月10万補助される前提で計算をすると、1億500万 - (10万/月 * 12ヶ月 * 25年) => 7,000万円を補う必要がある
  • 出口戦略
    • プライベート年金の引き出しは金額ベースではなく、パーセンテージで行う方が合理的
    • 期待収益率に対して引き出し率をどれぐらいとするか

やったこと

nakanoshima.dev#14 JVM Langs Night Talkにオンライン参加しました。

スピーカー方の発表はどれも面白かったんですが、個人的に立野さんの「Scala と AWS でフルサーバーレスなプロダクト開発事例(仮)」というテーマがかなり刺さりました。

Scalaで書かれたLambdaの起動を早くするためにGraal VM Native Imageを利用してネイティブ化するというところが大変そうだけどすごいな!と思いました。

立野さんの発表資料は以下になります。

speakerdeck.com

イベント登壇された方の資料一覧はこちら。

nakanoshima-dev.connpass.com

2021年3月1日 ~ 7日 振り返り

先週の振り返り。

仕事

主に以下のタスクを行いました。

  • APIの実装/修正
  • テンプレートの受け渡し改善の調整
  • 新規機能開発MTGの準備

やはり全体的にコード書く量が少ないな。エンジニアと名乗るのもおこがましいぐらいぐらいだ。 純粋に業務時間に書くコード量を増やしたいところです。

APIの実装/修正

レスポンスにある項目が追加され、それをクライアント側であるモバイルアプリがテキストの表示の出し分けの制御に使う想定でした。 実装・修正自体はそこまで難しいものではないのですが、まだモバイルアプリのUI仕様が決まっていなかったので、プロダクトオーナーと仕様の調整・合意を行うのに主に時間が掛かりました。

新規機能開発MTGの準備

いくつかのサービスをまたいだ機能開発についてのMTGなので、携わったシステムの仕様を振り返ったり、細かいところを聞かれても大丈夫なようにサービスのコードを読んでました。

準備した甲斐もあり、今日のMTGでお客様に開発する機能についてスムーズに質問できたかと思います。

プライベート

いい年なので、老後のために何かを始めないとなと思い、つみたてNISAを始めました。 とりあえず、年40万つみたてNISAにぶち込んで、余裕が出てきたらiDeCoも始めます。

TwitterでつみたてNISAの設定完了とつぶやいたら、友達からあとは以下のリンクの通りにやるだけと言われました。 読んでみたけど良さそう!とりあえず淡々と積み立てます。

hayatoito.github.io

読書

お金は寝かせて増やしなさい

お金は寝かせて増やしなさい

お金は寝かせて増やしなさい

つみたてNISAをはじめようと思い、読みました。 主にインデックス投資とはなんぞやということが書かれた本。わかりやすいです!

  • インデックス投資について書かれている本
  • 投資信託「インデックスファンド」の説明、Pros/Cons
  • インデックス投資の実践方法
    • インデックス投資をはじめる前に
      • 家計の状態を把握する
        • まずはここから(家計が赤字の状態で投資している場合ではないから)
    • 生活防衛資金
    • リスク許容度の把握
    • 資産配分
  • インデックス投資の終わらせ方
    • ポートフォリオの期待リターンからインフレ率を引いた数字が年間の取り崩し比率

作って学ぶ Androidアプリ開発 追加Step

作って学ぶAndroidアプリ開発[Kotlin対応]

作って学ぶAndroidアプリ開発[Kotlin対応]

復習がてら読むにはすごく良い本だった。 Android開発を始められた方は読んでおいて損はない本だと思います。

画像投稿の場合、処理が重くなりがちなのでどうやってバックグラウンドで実行させるかみたいなところもちゃんと書かれてて良いなと思いました。 あと、WorkManagerは知らなかったので、このタイミングで知れてよかったです。

やったこと

去年からフォートナイトを始めて、わくやゲームズという配信者のコミュニティができた頃から参加しています。

www.youtube.com

そこではDiscordを使ってコミュニティ活動が行われていて、そのままDiscord使っても良いのですがボットを開発して「より便利に」なれば良いなと思ってDiscord ボットも運用しています。

そのボットに新しく「リアクションタグ」という機能を先週追加しました。

どういうものかというと、あるメッセージに対して リアクションタグを書いて投稿すると、いくつかの絵文字が自動で付与されます。

そして、メッセージ投稿者は追加で他の人にタップしてほしい絵文字をいくつか追加します。

その追加された絵文字を他の人がタップするので、そのタップした人を一覧で表示したり、絵文字をタップした人の中からランダムでチームを作成したりする機能です。

何が嬉しいかというと、あるイベントに参加する人はだれかというのがひと目でわかることや、その参加する人の中でいくつかのチームに分けてスクワッド(※1)に行きましょうとなったときにいちいちチーム分けをしなくて済みます。

他にもいろいろ機能を開発していて、Heroku + Node.js(TypeScript)で実装しているので、技術記事を書いていきたいところです。

※1 スクワッドとは、フレンドと4人1チームでバトルロワイヤルゲームに参加すること

2021年2月22日 ~ 28日 振り返り

先週の振り返り。

仕事

仕事に関して、ぼかしつつ振り返りを書くのは難しいな...

ぼかしちゃうとやったことが仕様修正、機能開発、リリースとかになっちゃうからどうしたものか。

エンジニアとして仕事でやった中で技術的な部分を抜き出して技術記事書くのがやっぱり良い気がします。

そういえば、堤 修一さんのYouTubeを見ていてすごく良いことを言っていました。内容は次の通りです。(言葉は正確ではないです)

仕事の報酬は金銭的な報酬 + そこで得たスキルや経験・実績が含まれているが、そこで得たスキルや経験・実績を発信しないと金銭的な報酬を放棄しているのと同義。

今まで頻繁にブログは書いてこなかったので、金銭的な報酬を放棄しちゃってたわけですが、 今からは報酬をちゃんと受け取ろうと思った次第でした。

現在携わっているプロジェクトだと、Scala(cats etc..) + Play Frameworkで開発しているので、ここらへんを整理して発信していくのが良さそう。 インフラはAWSを使っているので調査や障害対応で得た知見は発信できそう。

プライベート

読書

投資信託選びでいちばん知りたいこと / 朝倉 智也

今まであまり投資する金銭的な余裕がなかったので手を出してなかったんですが、良い年にもなってきて老後のための貯蓄をする必要があるなと感じてきました。 そこで「つみたてNISA」を始めて投資信託で運用しようと思い、とりあえずざっくり情報を知るためにこの本を手に取りました。

投資信託について、ざっくり理解できる内容になっていておすすめです! もともとインデックスファンドの種類をあまり知らなかったので、ふーんと思いながらサクッと読めました。

作って学ぶAndroidアプリ開発 追加Step

たまたま正誤表を確認しようとしたときに見つけました! こういう本に書ききれなかったことを追加で公開してくれる著者には感謝しかないですね!

とりあえず、復習がてらやります。

gihyo.jp

やったこと

週末にLISTのAndroidアプリのバグを修正しました。やっぱり、Androidのコード書くの楽しいですね。

Android関連でいうと、DroidKaigi 2021の公式アプリのコードもGitHubに公開されたようなので暇なときにでも読んでみよう。

github.com

あと、AndroidDevChallengeというものがあるらしく、Jetpack Composeを学べるようなのでこれも今週やっておきたいところ。

developer.android.com

Circeでエンコードされたオブジェクトの値を抽出するには?

Circeを使ってあるオブジェクトをエンコードした際に、正常にエンコードされたかどうか値を確認したいときがあります。

そのオブジェクトが複数のオブジェクトのリストを抱えている場合、どうやって確認すればよいのか少し詰まったので備忘録として残しておきます。

事前準備

まず、確認のために必要な前準備をします。

IntellJなどでプロジェクトを作成します。

次に、build.sbtを以下のように記載します。

name := "blog-circe"

version := "0.1"

scalaVersion := "2.13.5"

val circeVersion = "0.13.0"

libraryDependencies ++= Seq(
  "io.circe" %% "circe-core",
  "io.circe" %% "circe-generic",
  "io.circe" %% "circe-parser"
).map(_ % circeVersion)

libraryDependencies += "org.scalactic" %% "scalactic" % "3.2.2"
libraryDependencies += "org.scalatest" %% "scalatest" % "3.2.2" % "test"

あとは、確認に必要なクラスを作成します。

package vo

case class Tag(name: String)
case class Item(name: String, price: Int, tags: Option[Seq[Tag]] = None)
case class Cart(items: Seq[Item], totalPrice: Int)

object CartFactory {
  def create(items: Seq[Item]): Cart =
    Cart(items = items, totalPrice = items.map(_.price).sum)
}

確認方法

以下のように、テストコードを書きます。

import org.scalatest.flatspec.AnyFlatSpec
import vo.{CartFactory, Item, Tag}
import io.circe.syntax._
import io.circe.generic.auto._
import org.scalatest.matchers.should.Matchers

class CartSpec extends AnyFlatSpec with Matchers {
  it should "エンコードしたItemの名前を抽出できる" in {
    val chocolate = Item("チョコレート", 250, Some(Seq(Tag("food"))))
    val apple = Item("りんご", 100, Some(Seq(Tag("food"), Tag("fruit"))))
    val error = Item(name = "error", price = 0)
    val cart = CartFactory.create(Seq(chocolate, apple))

    val itemsCursor = cart.asJson.hcursor.downField("items")

    itemsCursor.downArray
      .as[Item]
      .getOrElse(error)
      .name shouldBe chocolate.name

    itemsCursor
      .downN(0)
      .as[Item]
      .getOrElse(error)
      .name shouldBe chocolate.name

    itemsCursor
      .downN(1)
      .as[Item]
      .getOrElse(error)
      .name shouldBe apple.name
  }
}

Circeには、データを抽出のためにCursorというものが用意されています。 これを使うことで、エンコードされたオブジェクトを読むことができます。

ちなみに、cartのjson構造はこのようになっています。

{
  "items" : [
    {
      "name" : "チョコレート",
      "price" : 250,
      "tags" : [
        {
          "name" : "food"
        }
      ]
    },
    {
      "name" : "りんご",
      "price" : 100,
      "tags" : [
        {
          "name" : "food"
        },
        {
          "name" : "fruit"
        }
      ]
    }
  ],
  "totalPrice" : 350
}

例えば、itemsの中にある1番目のitem.nameを取り出したいとします。

その場合、HCursorのdownField関数などを使用してフォーカスを移動させることによってデータを抽出します。

まず、downField("items")でitemsにフォーカスを移動させます。その後、downArray関数 or downN関数 を使用してitemsの中の1番目のitemにフォーカスを移動させます。

downArray関数は、以下のコメントにもあるように、配列の最初の要素にフォーカスを移動させます。

If the focus is an element in a JSON array, move to the first element.

downN関数は、配列のどの要素にフォーカスを移動させるか指定することができます。

配列の最初の要素にフォーカスを移動させたら、その要素がどういう型なのか as関数 で型を指定してデコードします。

その後、getOrElseでitemを取り出して、nameを取得してあげれば確認できます。

参考:

circe.github.io

最後に

play-jsonよりCirceの方が絶対に書きやすい!!

2021年2月15日 ~ 21日 振り返り

先週の振り返りを書いていきます。

仕事

先週も長時間のMTGやスプリントでできるタスク時間の見積もりが少なかったため、 主にコードレビューやリリース準備、Google PlayのアプリレビューをSlackに投稿する簡単なLambdaの開発などやってました。

ここ最近、リリース準備にかなりの時間が割かれているのが問題です。

具体的には、今のプロジェクトではEpicブランチを導入しているのですが、 諸事情により機能を本番環境へリリースできるタイミングがどんどん遅れに遅れているにも関わらず、 機能開発は止まらない状態で、Epicブランチがどんどんと増えており、そのため検証環境と本番環境で大きな差分が出てきてしまっています。

そうなると、いくつかの問題が発生してきます。

  • 複数のEpicブランチをリリースブランチにマージして問題ないか
  • 検証環境では動いているが、本番環境では正常に動作するか
  • Epicブランチをマージしたらコンフリクトした。解消はしたけど、これ大丈夫?といった不安
  • etc...

このような問題がリリースが予定されるたびに発生しており、このままやっていてもコストばかりかかってしまうためgitのブランチ戦略を考え直す必要が出てきています。 もっとリリース回数を増やしたり、外部のサービスに影響されないようなリリース運用ができるようにしたいところです。

参考: チーム開発で Epic branch を運用した話-フリューテックブログ | Furyu Tech Blog

プライベート

先週はビジネス書を読むことが多かったです。

読書

365日 #Tシャツ起業家 「食べチョク」で食を豊かにする農家の娘

  • 食べチョク代表の秋元さんが書かれた本
  • 2部構成になっており、
    • 第1部は主に秋元さんの幼少期やDeNA、食べチョクを起業するまでが描かれています。
    • 第2部は、食べチョクを利用されている生産者さんのインタビューや食べチョクの社員の方から見る秋元さんや食べチョクに対する想いが語られています。
感想

秋元さんの人柄の良さやどういう風に考えて成長してきたかが書かれていて読んでいて食べチョクを応援したくなる本でした! また、生産者さんのインタビューや社員さんの想いが語られているも最高でした!

www.amazon.co.jp

なぜ、あなたの仕事は終わらないのか (中島 聡)

  • 中島さんが実際にされている仕事術に関する本
  • この本で大切だと思ったのは以下の通り
    • すべての仕事をスタートダッシュでこなして、絶対に負えられる納期を導き出す
      • ラストスパートはだめ!仕事を楽観視しすぎるなということ
    • 最初の2割の期間を「見積もり期間」としてもらい、実際には、仕事量の8割を終える
      • 最初の2割の期間で8割のしごとができなかったら、期限を延ばしてもらう
    • 大きな仕事は縦に切り分ける
  • とにかくスタートダッシュで8割の仕事を終わらることが大切 www.amazon.co.jp

作って学ぶAndroidアプリ開発

作って学ぶAndroidアプリ開発[Kotlin対応]

作って学ぶAndroidアプリ開発[Kotlin対応]

  • 作者:有山 圭二
  • 発売日: 2020/04/17
  • メディア: 単行本(ソフトカバー)

写経も完了

感想

Android開発の初級者向けの本はいくらでもあるが、正直説明書みたいな感じでサンプルアプリも実際に作るアプリの参考になりづらい。 ただ、この本は初級者~中級者向けの本で本当に動くアプリを作る場合にどういう風に作るのか非常に参考になる本だと思いました。

一回自分でAndroidアプリを開発してリリースまでしているので、復習がてらすごく良かったです。

2021年2月8日~14日 振り返り

先週の振り返りを書いていきます。

仕事

先週はスクラム定例と祝日・有給取得でほぼほぼ働いてないのと、課題の整理・リリース準備でやったことに書ける内容がなかったです。

プライベート

やったこと

読書

  • 作って学ぶAndroidアプリ開発
  • エンジニアが学ぶ物流システムの「知識」と「技術」(途中)
    • 物流システムってどういうことをしていて、どういう技術を使っているか興味があり読み始めました
    • 物流関係のシステムの開発に関わったことがないので読んでいてとても面白い
    • 同じ感じで金融系の本もあるみたいなので、そっちも読んでみたい

作って学ぶAndroidアプリ開発[Kotlin対応]

作って学ぶAndroidアプリ開発[Kotlin対応]

  • 作者:有山 圭二
  • 発売日: 2020/04/17
  • メディア: 単行本(ソフトカバー)

2021年2月1日~7日 振り返り

先週の振り返りを書いていきます。

仕事

先週も事情により、主に改善タスクに着手しました。

特に、先週はライブラリのアップデートはなかなか難しいものがありました。プロジェクト初期から関わっていればフレームワークとライブラリの依存関係等の知識を把握しつつ、どこに影響が出そうか予測が立てやすかったかもしれないが、それがあまりできてなかったのでタスクとして出した見積もり精度が低く、結局見積もり以上の時間を費やすことになりました。

Scala周りのフレームワークやライブラリについてもっと知見を増やして・理解を深めたい。

あと、関数型ライブラリ周りのライブラリの使い方がまだまだ理解が浅い。継続して猫番を読んだり、Haskellを書いたり、Scalaのライブラリを使ってみたりしていこう。

やったこと

  • ビルド環境のファイルパスがログに含まれる問題を解決
  • Circeのバージョンアップデート
    • PlayFrameworkや他の依存ライブラリでエラーが出て、アップデート完了できず
    • 見積もりが甘かった
    • 関数型ライブラリをゴリゴリ使っているのでもっと理解を深めないといろいろキツい。。。

プライベート

先週はほぼ本のインプットが多かったです。

読書

  • ライト、ついてますか?
    • 問題について扱った本
    • 良い本だと思うが、すんなり入ってくる日本語じゃないので何度も読まないと理解が進まないかも
  • システム開発・刷新のためのデータモデル大全
    • 期待したほどではなかった
  • WebAPI The Good Parts
    • 昔に読んでたのでサクッと読めた
  • 達人に学ぶDB設計 徹底指南書
    • ミックさんが書かれた本で、やっぱりわかりやすい

システム開発・刷新のための データモデル大全

システム開発・刷新のための データモデル大全

  • 作者:渡辺 幸三
  • 発売日: 2020/04/16
  • メディア: 単行本(ソフトカバー)

Web API: The Good Parts

Web API: The Good Parts

達人に学ぶDB設計 徹底指南書

達人に学ぶDB設計 徹底指南書

  • 作者:ミック
  • 発売日: 2013/08/07
  • メディア: Kindle版

2021年1月25日~31日 振り返り

先週の振り返りを書いていきます。

仕事

先週は事情により機能開発が止まったので、主に改善タスクを行いました。

前回の振り返りエントリでは、「Integrationテストの実行時間が長いのが問題だ」と書きましたが、そのそもテストを並列で実行する以前に他の要因でテストがFAILEDしてしまうケースがあったため、まず安定しないテストケースの修正などを行いました。

ただ、アクセストークンの有効期限が切れたり、再取得時にテストケースがFAILEDになるパターンなど、調査するとなかなか手ごわい問題もあり、簡単にテストを並列実行して高速化できました、といった結果が出せなかったのが残念です。

引き続き、機能開発を行いつつ、テストコードの改善を行っていきたいと思います。

あと、テストコードを読むことで、このAPIはどういう挙動をしているのか、仕様はどうなっているのかを理解しやすくなります。なので、新しいプロジェクトに参加した場合は、ドキュメントやテストコードを読みつつつ、気になるコードを追っていくのが良いと思います。

やったこと

  • Integrationテストの安定化

プライベート

読書

  • すごいHaskellたのしく学ぼう!(途中まで)
  • Pythonではじめる情報検索プログラミング(途中まで)
    • Haskell本読んでるのに手を出してしましました
    • サンプルコードが多いので、いろいろ試しつつ読めるのが良い
    • Pythonはほとんど書いたことないので、基礎本も少し読みたくなってきた

Pythonではじめる 情報検索プログラミング

Pythonではじめる 情報検索プログラミング

  • 作者:佐藤 進也
  • 発売日: 2020/12/17
  • メディア: 単行本(ソフトカバー)

やったこと

  • AWS SAPの勉強
    • WizLabs

2021年1月18日~24日 振り返り

先週の振り返りを書いていきます。

仕事

プロジェクトでは、単体テストの他にインテグレーションテストも書かれていて、GitHubにプッシュするとCIが走り、単体テスト・インテグレーションテストが実行されます。

ここで問題だなと感じているのは、インテグレーションテストの実行時間です。このインテグレーションテストに掛かる時間は約20分ほどです。データの不整合や他の外部サービスの影響により途中でテストにこけてしまうと20分が無駄になりますし、3回やり直しただけで1時間も溶けてしまうので、これは開発体験に影響ある問題です。

また、インテグレーションテストは順序関係なくテストを実行しても問題ないように作られてはいるようなのですが、同時にテストを実行するとテストにこけてしまうといったケースもあるようで、このケースを修正しないまま、並列にテストを実行できるようにしても上手くいかなさそうです。

今後、スプリントで優先的に行うPBIの他にこういう問題に着手していきたいところ。

やったこと

  • 仕様書の変更
  • お客さんへの仕様説明&合意もらう
  • 欠品情報をもとにレスポンスのある項目を変更する
  • 単体テスト・インテグレーションテストの追加・修正
  • デプロイ・検証

プライベート

読書

  • システム設計のセオリー
    • ざっと流し読みしました。
    • 実際にシステムを開発するときに考えるリストみたいなのがまとめられてて良いと思う一方、業務アプリケーション寄りの知見が多かったので、あまり鵜呑みにもできないなという感じでした。
    • 新人のときに読んでおけば、概要つかめて良さそうだなと思います。
  • すごいHaskellたのしく学ぼう!(途中まで)
    • 業務でScalaを書いてるとKleisliやら何やら色々出てくるので、しっかり基礎を固めておきたい
    • Haskellやらの本を読みつつ、圏論の基礎やらなっとくする群・環・体(なっとくシリーズ) のような本を読んで、数学的な知識もちゃんと頭に入れておきたいところ
      • 正直、今まで数学から逃げてたので今年は向き合わねば。

やったこと

  • WizLabsの問題を解く
    • AWS SAP取得のため、ひたすら問題解いてドキュメント読んでました。
    • まだまだ、試験を受けるには不安がありますね。。。
    • さっさと12冠とって楽になりたい