2021-05-05

読書記録【SOFT SKILLS　ソフトウェア開発者の人生マニュアル】の【第 3 部】

独学の方法、プロセス(ステップ 1 ~ 10)などについて書かれています。

何かしらを学ぶのに、いつもとりあえず本を読んでから少しさわってみる、くらいしか意識してなかったです。あまり興味がなければ長続きせず、割とハマれば深掘りしていました。

全てをこのステップ通りにやろうとはあまり思いませんが、今後は参考にしようと思います。特に、プロセスにある「全体像をつかむ」「スコープを決める」は少し意識して、幅広く何かを学ぶとしてもうまくキリをつけるようにしたいです。

2021-04-10

読書記録【SOFT SKILLS　ソフトウェア開発者の人生マニュアル】の【第 2 部】

これの続きです

e2araya.hatenablog.com

第 2 部では、自身のブランディングの方法などが書かれています。ここに書かれていることを実践すると、自身をアピールしやすいんだろうなあといった感じです。

SNS の使い方についても書かれていて、自身のブランディングのために SNS・ブログを書くかと考えると抵抗感があります。とりあえず自身の学びを振り返れるように少しずつアウトプットを増やしていきたいとは思います。

2021-03-28

読書記録【SOFT SKILLS　ソフトウェア開発者の人生マニュアル】の【第 1 部】

エンジニアのキャリアとか何を考えれば良いのか知りたくて、これを読み進めてます。

www.amazon.co.jp

全体としては技術的なことは一切書かれてないようです。

第 1 部ではエンジニアとしてのマインドセットや、就職先としてスタートアップ・中小企業・大企業を選んだ際のメリデメ、など、キャリアの方向性のメリデメと、それぞれの進み方のコツ、のようなことが書かれています。

気になる会社に採用されるためには、その会社の人と前もって接点を持って親しくなったり、自分のブログで自身を知ってもらうようにすると良い、という旨が書かれており、人見知りで、ブログを全然書いてない私にはウッ!と刺さりました・・。

専門性を上げることでの就職のしやすさについて書かれています。幅広く技術について知識を得た上で、その中でも専門分野を何か 1 つ持てれば良いと感じました。仕事で触っている技術に関して、あまり理解してないものあるので、一旦は幅を広げていきたいです。

2021-03-28

エンジニアの仕事に就いて 5 年経ちそう

はじめに

気づいたらエンジニアとして就職してから 5 年経とうとしてるので、節目てきなあれで諸々の所感とか書き残します。

現職は受託開発を主にしているIT企業です。新卒入社してから現在も勤めています。

仕事に関して

入社時点だとアプリケーション開発分からん

学生時代は情報系の短大に入っていたので、Java や C 言語で簡単なアプリを作ったことがあったのですが、その言語の文法的な理解があっても、フレームワークを使ったことがなければ、Git, AWS, など、アプリケーション開発でよく使われるようなツールやサービスを全然知らなかったので、その辺の勉強に少し苦労しました。

流行りの技術が変わってきたり、アサインされたプロジェクトによっては知っておくと良い技術が変わったりするので、さまざまな技術を追い続けるのは地味にしんどいです。

正直興味ないが知っておかないと仕事で困るものあったり、知っておいた良さそうなことが多かったり、など、その辺りが辛みです。 (全部に、興味持てるような人間になれたらいいな・・）

主体性を持って動くと良き

入社した当初は、基本的に開発チームのリーダーの指示に従って仕事を進めていたのですが、正直面白くなかったです。数ヶ月くらい、ほとんどの作業が何かしらのWebアプリの結合テストをしていた記憶です。

別のプロジェクトにアサインされ、「次何をすれば良いと思う？」というのを、そのチームのリーダーに質問されました。それは、プロジェクトが立ち上がってすぐ、プロジェクトの進め方や直近のタスクなどを整理する打ち合わせのできことです。その時までプロジェクトをどう進めるかはリーダーが決めるものだと思っていたので、少し驚きました。

プロジェクトの進め方をリーダーが決めるのか、各メンバーの意見を反映するのか、などは人によって考えが違うと思います。リーダーが質問しないだけで、実はメンバーが何を考えているか知りたかったりすることもあるので、とりあえず自身の考えていることを伝えるのは良いです。

プロジェクトの進め方、タスク出しに限らず、開発チームでの決め事や、スケジュール、アプリの改善方法、など、自身がどうしたいかを考え、それをチームに伝えて、反映されることがあるというのは楽しいです。何かしらのアイデアなどは、個人より複数人の意見でより良いものに変わっていくと思います。

周りの人巻き込め

担当するタスク・作業は担当した人が解決することは大して重要じゃなくて、チームの誰かというかチームで解決すれば良いです。なので、何か技術的な課題で困ったり、進捗が悪かったりなどしたら、周りの人にすぐ聞いてしまうと良いです。

メンバーがお互いに、何かあれば声をかけてください、という雰囲気を出すのも大切だと思います。

プログラミング以外の作業がほとんど

エンジニアになったらほとんどの作業がプログラミングだと思ってました。さまざまな工程があるのは分かっていましたが、それでもプログラミングする時間がほとんどだろうと。

そんなことなかったですね。

技術向上

技術書読んでいて良かった

技術書に限らず、技術・知識を吸収し続けるのは良いです。仕事がより楽になったり、面白くなったりします。

作りたいものなくてもとりあえず作ってみる

知らない開発言語とか、フレームワーク・ライブラリとかは、本や技術ブログを読むのも良いですが、とりあえず適当なアプリを作ってみると理解しやすかったりします。(人によるかも・・)

私はよく何か (本、商品、などテキトーな) の管理画面を作ってます。CRUD の機能があり、そこを開発してみるとだいたい仕事でも役立つ知識になったりします。

カンファレンスとか参加して良かった

知らない技術を知ることができたり、他社の事例を知ることで業務改善につながったり、良いことだらけです。

自分が所属する会社・チームで何か使ったことのない技術を利用するのに、他社の事例を説明すると受け入れてもらえやすくなったりすると思います。

その他

英語分からん

良い感じのクラス・メソッド・変数名など、英単語がすぐに分かりません。

公式のドキュメントが英語で辛いです。

気になるカンファレンスのセッションが全て英語で何を言っているのかが分かりません。

Google 翻訳がないと生きていけません・・。

肩こりが辛い

肩こりが辛いです。

肩こりからくる頭痛も辛いです。

今後

定期的にアウトプットしたい

全然アウトプットしてないので、どれくらい何を理解できているのかとかが、自分の中であんまり整理できてないです。

低レイヤーの技術について分かるようになりたい

仕事で利用する技術 (Java, Spring Framework, AWS など) を追ったりしますが、それ以外はあんまり分かりません。

低レイヤーの技術については、技術の流行り廃り関係なく知っておいて損はないと思うので、勉強していきたいです。

英語が読める&聞き取れるようになりたい

Google 翻訳から脱したいです。

肩こり解消してくれ

人類が肩こりに悩まなくなる日が来ることを願います。

2020-07-06

フロントエンドにクリーンアーキテクチャを導入

ちゃんとしたクリーンアーキテクチャというよりはそれっぽくした話です。

きっかけ

フロントエンドの実装をあまりしないのですが、プロジェクトで担当することになりました。以前関わった別のプロジェクトでのフロントエンドの実装は、特に設計方針とかアーキテクチャとかをちゃんと決めずに進めた結果、画面のどの処理をどのファイルに実装したかなどを追うのが辛い状態になりました。そんな経験があり、アーキテクチャをどうしようかと困ったときに調べてみたところ、クリーンアーキテクチャでの事例があったので導入しました。

フロントエンドの技術要素

以下

Vue.js
Vuetify
Twilio Video Client
その他諸々

ディレクトリ構成

project/
├── public
│   └── index.html
├── src/
│   ├── assets/
│   ├── components/
│   │   ├── atoms/
│   │   ├── molecules/
│   │   ├── organisms/
│   │   ├── templates/
│   │   └── pages/
│   ├── domain/
│   │   ├── repository/
│   ├── infrastructure/
│   │   ├── datamodel/
│   │   │   ├── api/
│   │   │   └── twilio/
│   │   ├── driver/
│   │   │   ├── api/
│   │   │   └── twilio/
│   │   └── inmemorystorage/
│   │       ├── twiliotextchat/
│   │       └── twiliovideo/
│   ├── service/
│   ├── main.ts
│   ├── plugins/
│   ├── repository/
│   ├── router/
│   │   └── index.ts
│   ├── App.vue
├── babel.config.js
├── tsconfig.json
├── tslint.json
├── vue.config.js
├── package.json
├── package-lock.json
└── README.md

クリーンアーキテクチャのレイヤーに合わせた考えるとこんな感じです

Entities → project/src/domain
- 画面で扱いたい概念などをクラスとして表現
Presenters → project/src/components
- domainを画面に反映
Use Case → project/src/service
- だいたい画面の操作ごとにメソッドを実装
Interface Adapters → project/src/repository
- 外部のデータをフロントエンドで扱いたいクラスに変換
infrastructure → project/src/driver, inmemorystorage
- 外部とのデータ通信

良かったこと

どのような処理をどのレイヤーに存在させるか決まっているので実装を追いやすい
ソースコードをメンテしやすい

悩ましいこと

一部の描画処理をinfrastructureで行っている。その描画処理はSDK(Twilio Video Client)に依存するので、移動させたいが難しい

2019-12-31

JavaのWebアプリのライブラリバージョンアップ/依存関係の解決

1年を振り返ってという題目で社内LTで発表しました。その時の話になります。

(LTは題目に沿った内容でなくても良かったのですが）

資料はこちらです。

以下は詳細な内容となります。

はじめに

2019年を振り返ると、だいたいJavaのWebアプリのライブラリ/フレームワークを整理/バージョンアップの対応をしていました。
バージョンを変えるのに何調べたかとか、どんなバグが発生したかとか話します。

バージョンアップの理由

オンプレからクラウドへの移行にあわせて以下の変更がありました。

Java 6 → 8
実行環境 Weblogic → Tomcat
Redisサーバの追加(セッション維持のため)
Oracle DB 11g → 12c R2

上記の理由に当てはまらなくても、最新バージョンのほうがバグがなくなってたり、より便利になっていたりするのでバージョンアップすることにしました。

バージョン選定の流れ

以下の順で作業を進めました。

Springの各バージョンの変更点を確認
現在使用しているライブラリを一覧化
各ライブラリの最新バージョンの確認
ライブラリにセキュリティ面で問題はないかの確認

Springの各バージョンの変更点を確認

このWebアプリではSpring Framework, Spring Security, Spring Data JPAなど、Springのモジュールをいくつか使っています。

フレームワークのバージョン変更はWebアプリに大きく影響するので優先して確認することにしました。
バージョンごとの変更点は各モジュールのreferenceやgithubのwiki, Release-Notes, マイグレーションガイドから確認しました。
Spring Bootを使うか検討していたのでそちらも確認しています。
Spring Frameworkのバージョンアップをするのに、他ライブラリ等に影響があるので注意しないといけません。というのも、今回、4.1→5.xに変えることを考えていたのですが、velocity template使っているのに連携クラスがなくなるため、全ての画面(html)を修正する必要がありました。全ての画面テンプレートを改修するとなると改修規模が大きすぎてスケジュール的に厳しいとのことで5.x系へのバージョンアップは断念することとなりました。
最後に、Session維持のためにSpring Session, Redisを使うので対応するバージョン等の確認をしました。

現在使用しているライブラリを一覧化

Spring以外はWebアプリでどのようなライブラリを使用しているのか知らなかったので、プロジェクトレポートプラグインを使って一覧化しました。

http://gradle.monochromeroad.com/docs/userguide/project_reports_plugin.html

こちらはMaven/Gradleで使用可能なプラグインで、依存関係をレポート出力してくれます。

HTML出力結果は以下のようになります（今回対応したWebアプリの依存関係ではありません）

https://yito0000.github.io/java-webapp-dependencies-update-docs/dependencies/index.html

対応したWebアプリでは使用しているライブラリが何十とあり、知らないものもいくつもありました。このレポートの内容をExcelに貼り付け、対応前後のバージョン、使う理由等、まとめることにしました。

一通り確認したところ、そもそも使っていないものがあり、それらは依存関係から削除することにしました。

ソースコード上は使っていないがライブラリを使用するのに必要なものもあり注意が必要でした。

各ライブラリの最新バージョンの確認

リポジトリの取得元がmaven repositoryであればライブラリのHPリンク記載があります。情報がなければgithubかググって探しました。(だいたいgithubにあった)

確認したのは以下についてです。

対応するJavaバージョン
バージョンごとの変更点(Release Noteから)
バージョン変更によってWebアプリへどのような影響があるか

OracelのjdbcドライバのバージョンについてはOracleのドキュメントから確認しました。影響するのはJavaとDBのバージョンです。

ライブラリの脆弱性確認

明らかな脆弱性があるライブラリは使いたくないのでOWASP dependency checkを使って、バージョンアップ後のライブラリの脆弱性を確認しました。

https://plugins.gradle.org/plugin/org.owasp.dependencycheck

https://www.owasp.org/index.php/OWASP_Dependency_Check
OWASP(Open Web Application Security Project)というのはWebアプリケーションセキュリティのコミュニティのことです。
このプラグインはNVD(National Vulnerability Database)などに既知の脆弱性のがあるか確認をしてくれます。
出力結果は以下のようになります。（今回対応したWebアプリのチェック結果ではありません）

https://yito0000.github.io/java-webapp-dependencies-update-docs/dependency-check-report.html
解決済みの内容についても出力されるようでした。