Somurie Engineer's Blog

書籍「ドメイン駆動設計入門」をKotlin+TDDで試してみた感想

はじめに 成瀬さんの書籍「ドメイン駆動設計入門」を読んで気づいた点、ポイントをまとめました。 自分用メモなので新たに気づいた点や忘れかけていた点を洗い出しています。 実装に関してはKotlinとTDDを初めて使ってみました。普段はJavaがメインですが、Kotlinを使ってみての感想も後ろにまとめてあります。 書籍を読んで気づいた点・ポイント ドメイン駆動設計を選ぶ理由 ドメイン駆動設計は初期開発速度は劣るが、サービスの変化、開発途中における要件の変化などへの対応が柔軟。長期目線で見たときにドメイン駆動設計の優位性がある。 値オブジェクト 値オブジェクトの分割基準として、ドメイン内で分ける必要がある単位で分割する。ルールを作成する必要がある単位など、取り扱ううえでまとめる必要があるかがポイント。 細かくしすぎるとメンテナンス性が低くなる。 ある程度、不変性を保つことができる範囲で作成する。 値オブジェジェクトを使用することで使用法に強制力を持たせるため、バグ混入を防ぐことに繋がる。また、ロジックを1箇所に集めることになるため、メンテナンス性も高い。 エンティティ DB設計時にER図でエンティティという名が用いられるがドメイン駆動では別の意味を表している。 エンティティには値オブジェクトにはないライフサイクルの概念が存在する。すなわちエンティティはシステム利用中に値が変化したり削除されたりする。 ドメインサービス ドメイン駆動設計で表されるサービスはドメインサービスとアプリケーションサービスの2つ。明確に分ける必要がある。(エヴァンス本ではサービスは1括りである) ドメインサービスには値オブジェクトやエンティティに書くと不自然になるものを記述する。 値オブジェクトやエンティティと異なり自身のふるまいを変更する記述は書かれず、複数のドメインオブジェクト(エンティティ及び値オブジェクト)を横断して操作する処理を記述する。 エンティティに書くことができる処理をドメインサービスに書いてしまうとドメイン欠乏症に陥る。エンティティの責務をドメインサービスが奪わないようにする。 命名規則としては「ドメイン名 + Service」が良さそう。自分の知っているプラクティスではパッケージによってdomainやserviceを分けているが、本書ではXxxDomain.Services.XxxServiceのようにドメイン単位でサービスを分けてることを例に挙げている。 リポジトリ リポジトリはドメイン駆動設計以外でも頻繁に目にする考え方。オブジェクトの永続化、再構築を行う。 重複確認existsメソッドはリポジトリではなくドメインサービスに実装すべき。何をもって重複とするかはドメインの責務。 永続化する単位で処理を行う。一部しかupdateしない場合でも永続化単位を引数として受け取る。 リポジトリクラスを切り替えることでインメモリのDBを使用し、テストを行う記述があったがコーディング量が多くなるため接続先DBを切り替えるだけの方が実用的な気がした。 アプリケーションサービス ユースケースを実現するオブジェクト。メソッド1つがふるまい1つを表すイメージ。 アプリケーションの返り値がドメインの場合、プレゼンテーション層でドメインを操作される可能性がある。返り値は画面表示用のクラスにするなど、境界を保つことも検討する(クリーンアーキテクチャのイメージ)。開発コストや規模との兼ね合い。 updateのように何かしら命令を送る場合、引数を修正することを避けるためにcommandクラスというDTOを引数とすると疎結合になる。 凝集度を測る指標としてLCOMがある。インスタンス変数が全てのメソッドで使用されているかを基に測る指標。 インスタンス変数を使用しているメソッドが偏っている場合はクラス分割を検討する一因となる。 サービスとはクライアントのために何かを行うもの。自身のふるまいを持たない。 ドメインにおける活動をドメインサービス、アプリケーションとして成り立たせるためのサービスをアプリケーション・サービスといった形で領域を明確に分けする。 ファクトリ IDの採番はどこの責務か。DBをの自動採番、ファクトリ、リポジトリの3つが挙がっているが、自動採番することを開発者内の暗黙の了解とするのが最適としている。 著者はリポジトリの責務は永続化と再生成が主と考えているためリポジトリ内の採番を推奨していない。。 ドメインオブジェクトがふるまいとして定義できるようであればあるドメインオブジェクトが他のドメインオブジェクトを生成するようにファクトリをメソッドとして定義することができる。 データの整合性を保つ 整合性を保つための手段として特定の技術基盤に依存することは避けるべき。DBに頼った場合、整合性の条件変更の対応が漏れる可能性がある(例えばテーブル内のユニーク条件が変化した場合、プログラム上の記載がなくDBのユニークキー設定変更は漏れやすい) アプリケーションサービスでトランザクション管理をすると、RDBに依存していることになる。JavaのSpring上の実現方法としては、AOPを実現する@Transactionalアノテーションを付与することでメソッド内のトランザクション整合性を担保することができる。 アプリケーションを1から組み立てる 集約 DomainのクラスをRepositoryで永続化に使用するDataClassに変換する際、Domainのフィールドを直接取得するのではなく通知オブジェクトを経由してDataClassを生成するパターンがある。Domainのフィールドに直接アクセスさせないための強制力がかなり強い。 Scalaだとフィールドのアクセス権限をInterface単位で設定でき、Interfaceを実装するクラスからのアクセスのみを許可することができる。 リポジトリは集約の単位で作成する。永続化の単位が集約であるため。 集約の単位でデータをロックしてしまうため、大きすぎる集約は厳禁。 仕様 仕様を全てDomainクラスに盛り込んでしまうと肥大化してしまい変化が容易ではなくなる。 仕様クラス(〜Specificationクラス)として括りだすことで扱いやすくなる。(リポジトリに仕様クラスの処理を移譲するとパフォーマンス上の問題もある) 検索に関わる複雑・特殊な条件の場合はリポジトリを使わない方法もとり得る。ドメインの防衛を第一に考えず、アプリケーションの猟奇はプレゼンテーション(利用者の利便性)を第一に考える。例えばドメイン内の操作でN+1問題が発生しそうだったりページング処理などがあれば1回のSQLクエリで取得できるようにするなど、例外的な対応も検討する。 アーキテクチャ アーキテクチャはドメイン知識が流出しないように記述すべき箇所を示す方針。 レイヤードアーキテクチャはオブジェクトを4つの層(プレゼンテーション・アプリケーション・インフラストラクチャ・ドメイン)に分け、それぞれの層が責務を持つ。また、記載した4つの層の順に上位層から下位層へ依存が存在し、逆の依存は許されない。 ヘキサゴナルアーキテクチャはアプリケーションに対するその他のインターフェース・保存媒体を取り外しできるようにすることがコンセプト。インターフェースを利用して依存性逆転の原則を実現するため、レイヤードアーキテクチャとは依存関係が異なる。 クリーンアーキテクチャのコンセプトはヘキサゴナルアーキテクチャと同じ。ビジネスルールをカプセル化したモジュールを中心に据え、依存関係を制御する。加えて、具体的な実装方法を明示している。 アーキテクチャを適用することで開発方針が決まるため、システム開発中に考える問題を少なくすることができるため有用。 ドメイン駆動設計の扉を開こう ユビキタス言語を使う。updateなのかchangeなのか、システマチックな言葉ではなくドメインエキスパートが使う言葉に合わせる。 同じ言葉でも視点が変わることにより必要な属性は異なる。境界づけられたコンテキストを適用し、別のエンティティを作る方が賢明。大規模になればなるほど同一のエンティティで全ての動きを賄うことは困難。 Kotlinで試し書きした感想 総じて書きやすかったです。Javaよりコード記述量が少なく、nullSafeな書き方ができる点がDDDに向いているなと思います。 nullSafeだとコンパイルエラーとしてnull混入を防ぐことができる点は本当に助かります。 nullSafeな言語は記述量がかなり少ない。DDDに向いている 値オブジェクト書きやすい。プライマリコンストラクタが便利 safe call (?

IntelliJでReactToolkitのアプリを作成しNetlifyに公開する

はじめに 遅ればせながらReact-Toolkitの存在を知りました。 試しに使ってみたら生産性が高い! 今回はIntelliJでReact-Toolkitを使ったシステムを開発する最初の手順をまとめてみました。 自分がまだReact開発に慣れていないので備忘録として細かいことも書きます笑 パッケージのインストール そもそもパッケージのインストールコマンドから書き出します。たまにしか使わないと忘れてしまう。 リリース時に使うものはnpm -i。開発のみで使用するTypeScriptなどはnpm -i -Dです。 npm -i [パッケージ名] (npm でも良い) npm -i -D [パッケージ名] ( npm install -Dや npm install --save-devでも良い) 設定方法 React公式テンプレートからテンプレートを作成する React公式のテンプレートがあるのでそこからclone $ git clone https://github.com/reduxjs/cra-template-redux.git ReduxTypeScriptのテンプレートを作成 $ npx create-react-app my-app --template redux-typescript これだけでもうテンプレート機能が動きます。以下コマンドで実行。 $ npm start 私はIntelliJを使っているのでRun -> Edit Configuration から~/my-app/package.jsonをnpm startするように設定し実行します。 追加パッケージをインストール パッケージを必要に応じて追加する。 Material-UIを使う場合 $ npm install @material-ui/core @material-ui/icons axiosを使う場合 $ npm i axios react-router ESLint TypeScript Pluginのインストール(ESLintとは違うみたいだけどちょっとまだよく分かっていない)

2020年4月振り返り

4月の振り返り Reactの文字列加工システム(上記とは別のシステム)は一旦完成。認証周りの動作確認が面倒なのでリリースせず自分用として使うことにした。あとDB周りの変更に耐えられるか微妙であった。 一方で、新たにReactで百人一首の読み上げシステムを作成中。最低限は一旦完成し、来月はリリース作業と機能追加を行う。 4月から引き続き、私生活に新型コロナの影響が大きく出ている。 1月末からリモートワークに移行しており、あり難いことに通勤時間を省けているため、勉学や運動に引き続き時間を費やす。 読書に加え、英語学習も合わせて開始した。久々にやると面白い。 Achieved 開発 SQLアンチパターンを読む → 40%読了 DDD案件の経験(@開発現場) フロントエンド Reactの百人一首システムを構築中 Redux Toolkitを使用。コード記述量が劇的に減り、開発速度がかなり上がった 基礎 FACT FULLNESS → 読了(ITではないけど教養として学習) 英語で毎日ニュースを読む(CNNとTechCrunch) Problem 新規 なし 継続中・保留 ビルド・デプロイツールの知識が少ない → React案件で多少解決予定 アーキテクト経験がない(1からシステム構成を検討) → React案件で解決予定 AtCorderで有向グラフが理解できていない AtCorderでDPのパターン経験が不足 解消 なし Try for next month フリーランスなのでコロナ影響によって急遽契約が打ち切られる恐れがあるため、次の現場の面談用にアピールポイントを増やすことを重視し見せることができるシステム構築を継続する。 また、英語はIT関連のリファレンスを見る程度であったが今月からニュースを毎日見るようにし始めた。5月も継続する。 新規 なし 継続中(前月中に達成できなかった) ドメイン駆動設計入門を読む 複雑な宿予約システムのDDD開発練習 モデリングスキルを高める書籍を読む Reactの開発案件はサーバ側の対応待ち Done Firebase上で文字列加工システムを公開する ⇒ 公開はせずクローズ

2020年3月振り返り

3月の振り返り Reactの開発案件はサーバ側の対応待ち。当分リリースできなそうなのでTry for next monthに移動する。 Reactの文字列加工システム(上記とは別のシステム)を開発中。Reactに慣れてきたが、設計がうまくできていない気がしている。NoSQLのデータベース設計ももやもやしながら進めている。DB設計事例を見ながら見様見真似で実験中。リリースした後にDB修正しにくそうなのでなかなかリリースに踏み込めない。 DDD周りの学習は平日の常駐先で積むことができている。 私生活に新型コロナの影響が大きく出ている。 1月末から平日の仕事はリモートに変わり、通勤時間が減った分を運動と勉強時間に費やしている。 ドラゴン桜や小学館の少年少女日本の歴史が無料公開されていたり、株の大幅下落を受けて投資に費やす時間に多くを費やしてしまった。(後悔はしていない) Achieved 開発 SQLアンチパターンを読む → 40%読了 「実践ドメイン駆動設計」から学ぶDDDの実装入門 ⇒ 読了 DDD案件の経験(@開発現場) DDD開発現場のぼやき 開発現場で感じたことだが、大規模な業務アプリケーションの場合、設計書を完全に廃止することは難しい現場が多いと思う。私が今参画している現場も同様で、設計チームが設計書を作成し、開発チームが設計書を元にDDDの開発を行っている。 設計チームと開発チームの意識の違いがあり、どうしても設計書はDDDに則しておらず(そりゃ設計チームメンバーがDDDに熟知していたりDDDを意識した設計をするのは無茶だと思うけど)、設計書と実装に差が出てしまう。 設計書を見て実装を見て、どこがどこと紐づいているかがわかりにくく、結局実装を詳細に見て仕様を理解しなければならない。少量なら簡単だが、設計書が10個、実装箇所が10クラスを超えるとかなりしんどい。 実装箇所を見て内部的に何をやっているか自信を持って推測できたりすれば良いんだけど、規模が大きくなってくるとなかなかクラス名・メソッド名だけから自信を持って判断ができず。。 lambdaの受け渡しが多かったりするので責務を絞る必要があるのではないか、DDDで言うコアドメインの線引きがうまくできていないのではともやもやしながら開発しています。(じゃあどうすれば良いのか、が浮かばないのが悔しい!!) フロントエンド React-Reduxシステムを構築中 FirebaseAuthenticationを使った認証機能を実装 CloudFirestoreの設計例をいくつか探して冗長な構成で実装。パフォーマンスは後回し CloudFunctionsによりFirestoreのデータコピー等を実装 基礎 法律を読む技術・学ぶ技術[改訂第3版] → 読了(ITではないけど教養として学習) Problem 新規 なし 継続中・保留 ビルド・デプロイツールの知識が少ない → React案件で多少解決予定 アーキテクト経験がない(1からシステム構成を検討) → React案件で解決予定 AtCorderで有向グラフが理解できていない AtCorderでDPのパターン経験が不足 解消 なし Try for next month 3月はFirebaseを用いたReactベースのシステム構築がメイン。 書面学習ばかりであったため3月からは手を動かす時間を長くしたい。当面コロナウイルス影響により資格試験も受けたくない(密室空間に居たくない)ので丁度良い。 React-Redux回りで良い設計ができているのか評価できない。時間ができたら他人の設計を見てみたい。 新規 ドメイン駆動設計入門を読む 継続中(前月中に達成できなかった) Firebase上で文字列加工システムを公開する。 複雑な宿予約システムのDDD開発練習 モデリングスキルを高める書籍を読む Reactの開発案件はサーバ側の対応待ち Done DDD書籍(IDDDを読み解く本)を読む

2020年3月振り返り

はじめに システム設計に関する記事が多く、後で読み返したいと思う記事を以下にまとめました。 これからシステム設計を学ぶ人の参考になれば幸いです。 DDD ボトムアップドメイン駆動設計(成瀬さん) 記事1つでとんでもない量のDDD情報が記載されている。具体的なコードもあるため時間をかけて見てみる価値あり。書籍化もされている。 リファクタリング クラウドワークス リファクタリング専門チームによるお金周りリファクタリング Railsで構築されたシステム。レガシーソフトウェア改善ガイドやDDDのエヴァンス本をオススメしている。 動的型付け言語だと調査が大変な点についても言及あり。お金周りでRails大変そうだな・・・。 単体テスト 現在時刻が関わるユニットテストから、テスト容易性設計を学ぶ テストケースの具体的なパターンとメリデメをまとめた記事。 テストケースを立てる時に感覚に頼っていたが、体系立てて記載されているものを見て目からうろこでした。 単体テストに自信がない人は特にオススメ

2020年2月振り返り

2月の振り返り 税金・簿記関連の作業がメイン。初の確定申告は無事完了。 簿記2級の試験はコロナ影響のため断念。 Reactの開発案件はサーバ側の対応待ち。(リリース予定は1月だったが延期) Reactの文字列加工システム(上記とは別のシステム)を開発中。 平日の常駐先でDDD周りの学習、実装の経験を積むことができている。 Achieved 開発 SQLアンチパターンを読む → 40%読了 DDD案件の経験(@開発現場) フロントエンド React-Reduxシステムをゼロから構築中(2回目) FirebaseでDBを構築。NoSQLを勉強中 基礎 簿記2級の試験勉強中。全量完了(2/23試験はコロナ影響により断念) Problem 新規 なし 継続中・保留 ビルド・デプロイツールの知識が少ない → React案件で多少解決予定 アーキテクト経験がない(1からシステム構成を検討) → React案件で解決予定 AtCorderで有向グラフが理解できていない AtCorderでDPのパターン経験が不足 解消 なし Try for next month 3月はFirebaseを用いたReactベースのシステム構築がメイン。 書面学習ばかりであったため3月からは手を動かす時間を長くしたい。当面コロナウイルス影響により資格試験も受けたくない(密室- 空間に居たくない)ので丁度良い。 React-Redux回りで良い設計ができているのか評価できない。時間ができたら他人の設計を見てみたい。 新規 Firebase上で文字列加工システムを公開する。 ドメイン駆動設計入門を読む 継続中(前月中に達成できなかった) DDD書籍(IDDDを読み解く本)を読む 複雑な宿予約システムのDDD開発練習 モデリングスキルを高める書籍を読む Done 簿記2級の試験勉強(過去問10回分を解く)

OCC2020

成瀬さん コンテキスト 文脈、前後関係 UserContext: その時点のユーザーの情報。HttpContext: HttpRequest、セッションなど現時点の情報。 フロントエンドの関心事 ユーザーがしたと思ったことを画面に表示すること 操作と表示をオブジェクト指向で宣言する

PostgreSQLよく使うキーワードまとめ(作成中)

はじめに 以前はMySQLをよく扱っていたのですが最近PostgreSQLを扱う頻度が高くなってきました。 細かいコマンドがわからずに毎度調べているので使用頻度が高いコマンドをまとめることにしました。 DBのログイン、作り方、PL/pgSQLまで、MySQLと違うコマンドが多い(少し違うのではなく全然違う)ので少しでもPostgreSQLから離れると記憶からすぐに消えてしまうので心が折れました笑 DB操作 PL/pgSQL 前提知識 全体構成 PL/pgSQLの全体構成は以下の通り。基本的には変数の宣言(DECLARE)と処理記述(BEGIN)の後ろに書くだけ。 EXCEPTION範囲を入れ子にしたい時はBEGIN〜ENDを入れ子にすることも可能。 DECLARE 変数の宣言を行う BEGIN 処理を記述する EXCEPTION 例外を記述する END; 処理の終わりを宣言する ファンクション 関数の作成には「CREATE OR REPLACE FUNCTION」を使うと楽(関数が既にあれば上書きする)。 削除だけしたい場合は「DROP FUNCTION」。 作成した関数一覧を表示したい場合は「pg_proc」システムビューを参照。「\df」メタコマンドを使うと情報を絞って表示。 ストアドプロシージャ PostgreSQL11から実装された。ファンクションとの大まかな違いは以下の通り 戻り値がなくなる 呼び出し方がcall proc();のようになる(ファンクションはSELECT func();) トランザクション管理ができる(コミットやロールバック) 変数の扱い 変数の記述方法は以下の通り CREATE OR REPLACE FUNCTION func(integer) RETURN integer AS $$ DECLARE age1 integer; // DECLARE部で宣言。 age integer := 3; という記述でもOK age2 ALIAS FOR $1 // ALIAS FORで第1引数の値を指す変数を宣言 BEGIN age1 := 3; // :=で値を代入 RETURN age1; END; $$ LANGUAGE plplsql; 代入の記述は以下3つが使用可能。DECLARE部で宣言しながら代入することも可能。

2020年1月振り返り

1月の振り返り 税金・簿記関連の作業ばかりしていた。 法人化の検討は時間がかかったが具体的な計算ができた。計算が複雑だし法人と個人事業主とで損金算入できるものが違うことがよくわかった。調べれば調べる程情報が出てきすぎ。 ちなみに、免税事業者と任意継続健康保険の効果が大きいため今年いっぱいは個人事業主とする結論とした。 Reactの開発案件はサーバ側の対応待ち。(リリース予定は1月だったが延期) 12月に引き続きReact-Redux周り機能を実装した。 平日の常駐先でDDD周りの学習、実装の経験を積むことができている。 Achieved 開発 DDD案件の経験(@開発現場) レガシーコードからの脱却を読む→ 読了 EffectiveJavaを読む → 読了 フロントエンド お気に入り画面等、余計な機能を遊びで追加(新しく使った技術・ライブラリ等はなし) ノンデザイナーズ・デザインブックを読む → 急ぎで一通り目を通した 基礎 法人化のタイミング検討(税金・経費・社会保険等の計算) 簿記2級の試験勉強中。半分程度完了(2/23試験) さおだけやはなぜ潰れないのかを読む → 読了 会計の基礎を読む → 読了 Problem 新規 なし 継続中・保留 ビルド・デプロイツールの知識が少ない → React案件で多少解決予定 アーキテクト経験がない(1からシステム構成を検討) → React案件で解決予定 AtCorderで有向グラフが理解できていない AtCorderでDPのパターン経験が不足 解消 なし Try for next month 簿記2級の試験勉強、個人事業主の確定申告をするのがメインになりそう。 Reactアプリは担当分を終えているため相方ペースに併せて引き続き進めようと思う。試験(2/23)が終わったらReactNativeにも触れてみたい。 また、合間時間にDDD関連の学習も進める(読書+平日現場で実践) 新規 なし 継続中(前月中に達成できなかった) 簿記2級の試験勉強(過去問10回分を解く) DDD書籍(IDDDを読み解く本)を読む 複雑な宿予約システムのDDD開発練習 モデリングスキルを高める書籍を読む Done レガシーコードからの脱却を読む EffectiveJavaを読む

2019年振り返り

2019年振り返り フリーランスSEになって1年が過ぎました。 良い状態で勉強し続けることができ、不安から自信へと変化した1年でした。 きりの良いタイミングなので振り返りを書いてみました。 開発現場の当たり前をキャッチアップ フリーランスに転向し、本格的な現場での開発は4年ぶりでした。 4年ぶりにもなると初見のツールやライブラリ、言語が多く、1年間は休日なしで勉強漬けになることを覚悟していました。 (以前の開発がJava6、Spring2.5、Subversion、社内独自のツール多数、というタイムスリップぶり) 最初から未経験のことだらけになるのは危険と思い、経験のあるJavaをベースに案件を探したのは正解で、Java経験で自尊心を保ちつつ(苦笑)、Git、BitBucket、Docker、Vagrant、スクラムといった開発のデファクトスタンダードとなるツール・プラクティスを経験しました。 事前にかなり不安があったものの、1ヶ月もあれば不安はなくなりますね、難しいことをやろうとしなければ全然問題ないです。技術的にもまだまだ通用するようで安心しました。 (迷惑をかけないように一人自宅でGitのmerge練習したりしていたのが懐かしい) ドメイン駆動設計 開発現場の当たり前を引き続き探していると原則やお作法、ベストプラクティスといったモノたちに辿り着きました。デファクトスタンダードといえるような「これだけ学べばOK!」というものはなく、手当り次第に物色。 KISSやYAGNIの法則、デザインパターン、SOLID原則などを色々と学び、最後はドメイン駆動設計に辿り着きました。 エヴァンス本が難しすぎて進まず、まとめブログや関連書籍で荒い知識を身に着けて、ドメイン駆動設計の案件に片足参加させて頂きました。 他者のコードやコードレビューなど、実戦ならではの学びが多く、短い期間でしたが大変勉強になりました。そして何よりも楽しんで参加できたことが良かったです。 この経験があったおかげで、年末からはドメイン駆動設計の現場に移ることになりました。 フロントエンドの開発 過去の開発ではサーバサイドの開発がメインであったため、フロントエンドの開発はjQueryを少しかじった程度のレベル。 ただ、サーバレスを耳にする機会も多く、自分でサービスを展開したい思いもあるため手を付けることにしました。 タイムスリップ期間がかなり長く、HTML5、CSS3、ES6等の基礎からキャッチアップ。 CSSフレームワークではBootStrap、Bulma、Material-UI、JSライブラリではReact、Redux、Vue、TypeScriptなどを扱いました。 小さめの開発に携わったものの、案件規模が大きくなると難易度が高くなるんだろうなと薄々感じますね… 年末の時点で、Reactをベースとしたアプリケーションの開発はできるようになりました。来年はいくつかサービスを作ってみようと思います。 IT基礎スキル 地道だが基礎トレーニングは重要。そして半分は趣味と自己満足だけど、以下に挑戦してみました。 データベーススペシャリスト ネットワークスペシャリスト 競技プログラミング デスペは残念ながら不合格。午後2があと4点だったので来年なんとか受かりたい。 ネスペは無事に合格することができた。 競プロはAtCorderで茶色。緑色まであと一歩。さすがに時間を取ってじっくりやらないとレベルが上がらない。あと、RubyではなくPythonでやっておけば良かったかも。中途半端にRubyができるようになってしまった。 全体的に少なからず力をつけることができたと思います。 その他 腱鞘炎になたり腰を痛めたりと、健康面では反省が多いです。 仕事や勉強に精を出していたものの、あまりにも動かなすぎたと思います。 仕事のスタミナをつけるためにも適度な運動はしよう。 総括 全体的によく頑張り、それなりに成果が出たと思います。 アウトプットが少なかった点は反省。 ITのキャッチアップ時間がかなりかかり、IT以外の勉強に手が及ばなかったので来年はもう少しITの以外も頑張りたい。 2020年に頑張ること ITだけでなく、興味が強いファイナンス・会計、避けて通れない英語を併せて学びます。 資格は自己満足と、商談時にわりと威力を発揮するので引き続きコレクションを増やそうと思います。 IT FEやデプロイツール、AWSといったインフラ関連などを手広く学ぶ。浅く広く DBスペシャリストを取得する ドメイン駆動設計を引き続き学ぶ なんらかのシステムを構築する できれば公開する 株関連が有力 AppStoreに何か出す。ReactNativeを使う(iPhoneを買ったので) ファイナンス・会計 法人化と資産運用・節税のために学ぶ(会計は現場で必要なスキル) 簿記2級を受ける。個人事業主の確定申告、法人化、現場の会計周辺業務で活かせるため FP2級を受ける。5月かな。優先度低 外交員一種。投資のベース知識として取りたい。優先度低 英語 プランはないが気長に実施する 年間予定 大まかな年間予定は以下の通り。1年のうち4ヶ月は机上勉強ですね。(本当はITストラテジストに挑戦したかったが開発時間がなくなるため断念)

2019年12月振り返り

12月の振り返り Reactの開発案件を主に実施した 11月に引き続きReact-Redux周り機能を実装した ※リリース予定は12月から1月延期。 平日の常駐先でDDD周りの学習、実装の経験を積むことができている 個人事業主になって初めての確定申告に向けた作業も平行して進めた Achieved 開発 DDD案件の経験(@開発現場) レガシーコードからの脱却を読む→(6割完) フロントエンド React案件の開発を進めた(最低限リリースできる状態まで完成) IndexedDB(PWA化の一環) TypeScriptハンドブックを読んだ http://js.studio-kingdom.com/typescript/ 基礎 簿記2級の試験勉強を開始した(物流システムや個人事業主の確定申告、法人化に役立つため) Problem 新規 なし 継続中・保留 ビルド・デプロイツールの知識が少ない → React案件で多少解決予定 アーキテクト経験がない(1からシステム構成を検討) → React案件で解決予定 AtCorderで有向グラフが理解できていない AtCorderでDPのパターン経験が不足 解消 Webデザインセンスがない。ノンデザイナー向けのUIライブラリ等を学ぶ → MaterialUIや色合いを自動設定してくれる機能があるため解消とする Try for next month 簿記2級の試験勉強、個人事業主の確定申告と法人化検討をする Reactアプリは担当分を終えているため相方ペースに併せて進める 合間時間にDDD関連の学習も進める(読書+平日現場で実践) 新規 簿記2級の試験勉強 継続中(前月中に達成できなかった) ノンデザイナーズ・デザインブックを読む EffectiveJavaを読む レガシーコードからの脱却を読む DDD書籍(IDDDを読み解く本)を読む 複雑な宿予約システムのDDD開発練習 モデリングスキルを高める書籍を読む Done レガシーソフトウェア改善ガイド(5割完)→すぐ使えそうな内容が多いため中断

2019年11月振り返り

11月の振り返り Reactの開発案件を主に実施した。 ReactはHelloWorld程度の経験。TypeScriptとReduxは未経験であったため学習と実験的な実装及びリファクタリングに多くの時間を割いた。 React-Redux周りのトレンドは抑えることができたと思う。 平日の常駐先でDDD周りの学習に時間を費やすことができるため、その他の時間はフロントエンドの学習を行っている。 12月にリリース予定のため引き続き当案件に時間を割く予定。 Achieved 開発 DDD案件の経験@開発現場 レガシーソフトウェア改善ガイド(5割完) ノンデザイナーズ・デザインブックを読む(2割完) EffectiveJavaを読む(3割完) フロントエンド React+Redux+TypeScriptを使ってシステムのα版が完成 以下、React-Redux周りのスキル・知識を身に着けた Hooks各種機能 Ducksパターン Fluxパターン Saga React-Router Material-UI 基礎 業務知識として物流システムを体系的に学習(業務知識の本) Problem 新規 なし 継続中・保留 ビルド・デプロイツールの知識が少ない → React案件で多少解決予定 アーキテクト経験がない(1からシステム構成を検討) → React案件で解決予定 Webデザインセンスがない。ノンデザイナー向けのUIライブラリ等を学ぶ AtCorderで有向グラフが理解できていない AtCorderでDPのパターン経験が不足 解消 JSのフレームワーク1つも使えない(サーバ側に知識が偏りすぎている) → React案件で解決予定 Try for next month Reactアプリに注力する(丁度良くProblemも解決する) 合間時間にDDD関連の学習も進める(読書+平日現場で実践) 新規 なし 継続中(前月中に達成できなかった) ノンデザイナーズ・デザインブックを読む レガシーコードからの脱却を読む DDD書籍(IDDDを読み解く本)を読む 複雑な宿予約システムのDDD開発練習 モデリングスキルを高める書籍を読む Done ReduxのサンプルWebサイトを作成する(11月以降実施予定)

2019年10月振り返り

10月の振り返り ドメイン駆動設計、ネットワークスペシャリスト(以下ネスペ)の勉強の時間を割いた。 10月よりDDDの案件の現場になり、業務=DDD勉強になった。 10月20日にネスペ試験があったため前半はほぼネスペ勉強、試験後はブログのWordPress脱却作業と、React開発案件の着手をした。 9月のうちにJavaのStreamとジェネリクスを手堅く学習しておいたため業務後に追加学習する必要はあまりなかった。 Achieved 開発 DDD案件の経験(@開発現場) ブログをAmazonEC2からHugo(静的ジェネレーター)に移行 Gradleの仕組みを学習(現場トラブル) EffectiveJavaを読む(3割完) フロントエンド ReduxのHelloWorldを作成した(React開発案件の一環) 基礎 ネスペの教科書午後1と午後2を6年分+α実施した 東京都主催のネットワークセキュリティ状況研修(全3日)に参加した(Ciscoルーターを用いたネットワーク構築、IPsecの構築などを実施) Problem 新規 Webデザインセンスがない。ノンデザイナー向けのUIライブラリ等を学ぶ 継続中 ビルド・デプロイツールの知識が少ない → React案件で多少解決予定 アーキテクト経験がない(1からシステム構成を検討) → React案件で解決予定 JSのフレームワーク1つも使えない(サーバ側に知識が偏りすぎている) → React案件で解決予定 AtCorderで有向グラフが理解できていない AtCorderでDPのパターン経験が不足 解消 なし Try for next month Reactアプリに注力する(丁度良くProblemも解決する) 合間時間にDDD関連の学習も進める 新規 ノンデザイナーズ・デザインブックを読む レガシーコードからの脱却を読む 継続中(前月中に達成できなかった) DDD書籍(IDDDを読み解く本)を読む 複雑な宿予約システムのDDD開発練習 モデリングスキルを高める書籍を読む Done ReduxのサンプルWebサイトを作成する(11月以降実施予定) ネスペ6年分の過去問をこなす

2019年9月振り返り

9月の振り返り ドメイン駆動設計、ネットワークスペシャリスト(以下ネスペ)、SpringBootの勉強に時間を割いた。 8月よりDDD案件のタスクは少なめ。主に休日に実施している。 AtCorderについては時間を少なめにし、大会に隔週参加している状況。 Achived 開発 DDD案件によるDDD経験アップ(今月は長めに時間を取ることができた) DDDの書籍「エヴァンス本」読了 Java11〜12のブログ記事を作成。 SpringBootのコメント付きサンプルシステム構築。DB2連携、SQLログ出力を実装。やりたかったことはとりあえず完了 AtCorder大会に週2で参加。緑色ランクまであと一歩。 JavaのStream、ラムダ式、ジェネリクスの詳細を理解した。JavaGoldの書籍、Streamを使った検索や処理の実装サンプルプログラムを作成した。 フロントエンド ES6の学習。以下をハンズオン(第1部は全て完了。全3部構成) [https://ja.javascript.info/][1] 基礎 ネスペの教科書一通りおさらい ネスペ午後1を5年分実施 ネスペ午後2を1年分実施 Problem 新規 なし 継続中 ビルド・デプロイツールの知識が少ない アーキテクト経験がない(1からシステム構成を検討) JSのフレームワーク1つも使えない(サーバ側に知識が偏りすぎている) AtCorderで有向グラフが理解できていない AtCorderでDPのパターン経験が不足 解消 なし Try for next month 次の案件の復習とネスペ勉強が主になる。 ネスペ試験が10月にあるため学習をする。 新規 ネスペ6年分の過去問をこなす モデリングスキルを高めたい。何か書籍か問題集を探す 継続中(前月中に達成できなかった) DDD書籍(IDDDを読み解く本)を読む 複雑な宿予約システムのDDD開発練習 ReduxのサンプルWebサイトを作成する(11月以降実施予定) [1]: http:// https://ja.javascript.info/

今更ながらJava12の新機能をまとめてみた

背景 今までJava8の案件が主だったのですが、最近Java12の案件にも参画させて頂いています。 ただ、開発している中でJava9以降の機能を使っておらず、使える機能がないかを調べる目的でまとめてみました。 今回使用するサンプルコードは以下に全て置いてあります。 https://github.com/somurieengieer/javaSelfTraining/blob/master/src/sample/java12newFunc/Java12sample.java 追加された機能 switch文の追加(プレビュー版) switch文の新たな使い方が追加されました。右辺として使うことができるようになります。 具体的には以下の通りです。 System.out.println("-- アロー構文 --"); int num = 4; switch(num) { case 1, 2, 3 - System.out.println("複数条件を記述できます"); case 4, 5, 6 - { System.out.println("複数行の処理を書くときには"); System.out.println("ブロックで書きます"); } default - System.out.println("条件に合致しない場合"); } System.out.println("-- switch式 --"); String message = switch (num) { case 1, 2, 3 - "複数条件を記述できます"; case 4, 5, 6 - { System.out.println("ブロックの場合はbreakにより値を返却する"); break "ブロックによる記述もできます"; } default - "条件に合致しない場合"; }; System.out.println(message); String transform()の追加 今まで処理メソッドに対してStringの文字列を引数で渡していた処理に対して、transform()を使うとStringの文字列に対して処理を記述することができます。