プライベートでコードを毎日書き続けて２年以上が過ぎた
いつの間にか２年間継続してコードを書いていたので、その振り返りです。上のインコは日々僕を応援してくれる二羽のインコのうちの一羽です。この後本をボロボロに噛みちぎっていきました。 １年目との違い去年こんなポストを書きました。 このとき、自分はコードを１年継続して書いたわけですが、その後また１年継続してコードを書いていました。 １年目とは「書きたい」と思うものも変わりました。また、習慣を維持する労力も小さくなり、コードを書くことそのもの以外の、登壇などの時間を取れるようになりました。 この１年で新たにやったことツール作成markdownをMediumポストにするCLIツールAWS SSMで管理されたパラメーターを環境変数にInjectするツールGoogle Cloud Platform API向けに使える、goonと同様のDatastoreクライアント基盤作成AWS上にTerraform+An
継続してコードを書くということ
この度、githubへの一年間連続コミットを達成していたらしいことを確認しました。途中から平日、仕事の分も混ざっているのですが、プライベートでのコミットは毎日確認していたので、ちゃんと一年間継続できているはずです。 当初はどういうものを開発するのか定まっていなかったり、謎の練習コードばっか産まないか心配だったのですが、継続してコミットを続けていくことで、徐々に目的意識を持ってコードを書くのにも慣れてきました。 そこで、この一年でどういう考えで開発過程をたどってきたか、どういうものを開発してきたか、これからどうしたいかについて書こうと思います。 どういう考えで開発過程をたどってきたか最初は継続性のみを重視１年前と今とでは、コードを書き始める時の意識も少し変わったなと、今は思います。 １年前はどんな形であれ継続できるようにコードを書いて、たまにdotfilesいじったりとか、遅くに会社を出ると
クライアントはいつまでサーバーを意識するべきか ~設計議論の過程~
Facadeパターンの例として、サブシステムとしてのコンパイラーを考える。システムとしてのコンパイラーは字句解析器や構文解析器などから構成されている。これらの構成要素は、新たなコンパイラーやその他ソフトウェアを作成する上でサブシステムと… 通信処理+データ変換クラスの存在 上記のサービス層があっても、クライアントから通信するのは別のクラスに切り出さないともちろんダメ。クライアント側のモデルオブジェクトをRPCのオブジェクトに変換する、ないしレスポンスで受け取ったデータをクライアント側のデータクラスに詰めて、サービス層にコールバックで返す、みたいな処理もあるとして、それは通信処理+データ変換をしてくれるエージェント的なクラスがあった。 ということで、データの流れとしては、 View -> Controller -> Service(背後に複数のModel) -> 通信処理+ データ変換(Pr
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
