技術書を積んでおこう。
自分の本棚に買った技術書がどんどん増えている。全部読めているわけではない。だいたい読むペースの3倍くらいのスピードで増えているので、増える一方だ。 積んだだけで読んでない本、かつ、心のどこかに引っかかっていていつか読もうと思っている本がたくさんある。
- マーティン・ファウラーの「リファクタリング」
- エリック・エヴァンスの「ドメイン駆動開発」
- 「すごいHaskellたのしく学ぼう」
- 「レガシーコード改善ガイド」
- 「30日OS開発」
- 「nand2tetris」
- 「SQLアンチパターン」
- 「effective java」
- 「SICP」
これ以外にもたくさんの本が本棚に眠っている。
リストに上がっているのは結構難しくて読むのに時間がかかる本ばかりだ。 でも、積んでおいて意識のうちに置いておくと凄く良いと思っている。
何故かというと、買ってみて読んでみて理解できなかったとしても、本棚に眠らせておくといつの間にか理解できるようになっていることが多いからだ。 もちろん、ただ眠らせておくだけでウィスキーが熟成するみたいに勝手に読みやすくなるわけじゃない。熟成されるのは本じゃなくて自分自身だ。 あの本をいつか読めるようになろうと意識して関連分野を勉強しているうちに、そのうち知識が身についてきて、 「あ、そういえばあの読みたかった本、本棚にあるじゃないか」と思って本棚に手を伸ばした時、驚くほどスラスラ読めるようになっていることがあるのだ。
これは実体験としてある。
恥ずかしながらエンジニアになって半年くらいのころに結木浩先生の「デザインパターン入門」を買ってみて、読んでみて、全く理解できなかった。 コードは何を書いているかわからないし、説明も全くわからなかった。 この本が理解できるようになる気もしなかった。 でも、それから1年半くらいたって、オブジェクト指向設計実践ガイドを読んでみたり、クリーンアーキテクチャを読んでみたり、 RubyとJavaのコードをたくさん書いてみたあと、ふと本棚に目をやった時、「デザインパターン入門」が目についた。 読んでみて驚いた。前は全然わからなかったのにスラスラ分かる。しかも内容が本当に面白くて、役に立つのがよく分かる。 どこかで見たパターンがいくつも書いてあって、あのコードはこのパターンを使っていたのか!というのがよく分かる。 いつの間にか、理解ができるレベルに達していたようだ。
こういう経験ができるととても楽しくて、自分の成長が実感できる。
だから、難しい本を積もう。今は読んでも理解できないOSSのレポジトリをブックマークしておこう。
いつか読めるようになるから。
オブジェクト指向設計実践ガイドを読んだので感想1
オブジェクト指向設計実践ガイドを読みました。 結構難しい本だった気がします。最初は翻訳が分かりづらいとか散々文句言ってましたが、単に知識がないだけだった気がします。反省。
ドメイン駆動設計入門 ボトムアップでわかる!ドメイン駆動設計の基本 | 成瀬 允宣 | コンピュータ・IT | Kindleストア | Amazon
最初はよく分かっていなかったんですが、 このあたりの本を読んでオブジェクト指向設計がデータと振る舞いの持たせ方を定義し、それぞれのオブジェクトがどのようにメッセージをやり取りし合うことで依存関係を構築するかを設計する行為だと分かった上で読んだらスラスラ分かるようになりました。とは言っても上の二冊も簡単な本ではなく、知識の結びつきで簡単に読めるようになっただけだとは思います。
オブジェクト指向設計では、このようにお互いがお互いを知っており、どのように呼び出すかを知っている状況を好ましくない状況とし、
このように単方向に自分が呼び出すべき相手を知っていることを好ましい状況として定義して、 これをどうやって実現するかを考えていく必要があるわけです。
変更が起こりうる部分を特定し、図でいうとrootのオブジェクトはあまり変更が発生しないオブジェクトを配置し、 leafの部分の方に変更の発生しうるオブジェクトを配置することで、変更時の対応がしやすくなります。
小さいソフトウェアであれば依存関係がゴチャゴチャであっても気合でなんとかしたり、自分が知ってさえすればそれで何とかなるのですが、 ある程度規模のあるソフトウェアになると、オブジェクトを入れ替えたり修正したいときなどに、お互いがお互いに依存して密結合になり、変更不可能になる部分が出てきてしまうため、 修正が困難になってしまいます。また、後々関わったプログラマは設計当時の状況を知らないので、オブジェクトを好き勝手に使ってメチャクチャにしてしまう可能性があるため、設計により、使用方法に制限を加えなければいけません。
そのための方法論が書いてあります。(今度まとめる
- is-a
- has-a
- behave like
に着目してそれぞれ継承、委譲、モジュールインクルードを使い分けることが重要です。
可能な限り委譲を使用し、継承はあまり使わないことが必要です。
今後調べる必要がある部分としては、 Rubyの場合は静的型ではなく、InterfaceやAbstract Classも存在していないので、JavaやC#との違いを深堀りしたい。
プログラミングスクールで勉強している。
タイトルの通り、2月初旬ごろからフィヨルドブートキャンプというプログラミングスクールで勉強しています。 記録上は累計200時間ほど勉強しています。少ないですね。記録をつけていない日があったり、割と時間は適当に計測しているので実際のところは合計350時間ほど費やしているでしょうか。だいぶ勉強が進んできて色々出来るようになってきたので一旦の振り返りとしてこの記事を書いてみます。別にこの記事で報酬を貰ったりは一切していないので、完全に個人の感想です。 bootcamp.fjord.jp
自己紹介
W大学の文系学部を卒業後、2年と少しSierで働いている26歳の男です。一応ITエンジニアという分類にはなります。
経緯
文系の大学を卒業した後Sierに入社しました。そこは、残念ですが私が期待していたエンジニアリングをやっている会社ではなかったです。良い会社だとは思いますが、価値観が合いませんでした。この会社でエンジニアとしての能力を身に着けるのは厳しいかなーと思い、 独学で勉強して転職しようと思ってました。 しかし、独学で勉強していると結構困ることがあります。
- カリキュラムがないので好き勝手気になることを勉強しがち
- 期限がないのでダラダラ勉強してしまう
- フィードバックがないので学んだことのアウトプットが正しいかわからない
以上が大きな問題になります。
そんなこんなで好き勝手ダラダラ勉強して時間が経つのに焦りを覚えていました。
ある時Vさんというソフトウェア開発会社の経営者さんがこんなtweetをしていました。
プログラミングの独学まじ悲しいくらいメリットないからやめた方がいい。無駄な時間がすごい多い ... 。フィヨルドブートキャンプとかに通うべき。
— V (@voluntas) July 8, 2020
この発言については一理あると思いました。この人が言うなら信用できそうだなと思い、フィヨルドブートキャンプで勉強してみることを決めました。 (いろいろあって2021年2月からになりました)
感想
結論を先に言っておきますが、フィヨルドブートキャンプで勉強を始めたのは非常にいい決定でした。
どう変わったか
フィヨルドブートキャンプで学習を始める前の私はだいたいこんな感じでした。 だいぶ雑ですが、分かってない部分を中心に書いてます。分かってることは書いてません。
- Javaで既存システムの改修はできる。新規にモジュールを作ると手続き型の酷いコードを書き始める。
- 基本的なJavaScriptは書ける。クラスは使わず、非同期処理も適切に書けない。
- DB設計は正規化していない滅茶苦茶なものを作る。
- Linuxについてはcd, ls, pwdくらいしかわからない。
- テストコードの書き方がわかってない。書いたことがない。
- 一般的なweb application frameworkにあまり触れたことがなく、機能としてどのようなものが存在するか知らない。
いま時点ではこんな感じでしょうか。
- 適切な抽象化をしてクラス分割をした上でRubyのコードが書ける。結果的にJavaでもオブジェクト指向に則って書けるようになった。
- クラスに分割してオブジェクト指向に則った形でJavaScriptを書ける。async/awaitとPromiseを使って非同期処理に対して適切に対処ができる。
- 適切に正規化をした上でDB設計を行うことができる。
- Linuxのパーミッション周りが分かっており、他にもsshで接続した上で必要なソフトウェアをインストールし、環境構築が出来る。
- TDDの方法論について知っている、どのようなテストコードを書くことで要件を満たしていることのチェックが出来るか考えられる。適切にテストコードを実装できる。
- Ruby on Railsにどのような機能が存在しているか知っており、要件に対してFrameworkの機能を使用することで実装が出来るか調査ができる。
他にも元々うっすら知っていて知識として強化された事柄は数え切れないほどあります。
他に技術と関係ない部分としては、フィヨルドブートキャンプでは基本的に勉強した日は日報を書くのですが、 書いていくうちに学んだことをアウトプットとして人にわかりやすく伝えることを意識するようになりました。これは結構大きな変化です。
フィヨルドブートキャンプで学んでいる人たちはプログラミング未経験であっても他の分野で優秀な人なんだろうな、と思わせることがあり、 根拠としては日報に考えをまとめるのが上手な人達が多いです。この点もかなり参考になります。
コードレビューがありがたい
フィヨルドブートキャンプでは皆さん優しくレビューしていただけます。頂いた指摘におかしなことはほとんど無いですし、間違っていたとしても(人間なので当然間違えることはあります)根拠を示せば皆さん納得して頂けます。このコードレビューで自分では気づかない部分で改善される部分が多かったです。
独学で学ぶデメリットは解消されるか
独学では以下のデメリットがあると挙げましたが、全て解消されました。
- カリキュラムがないので好き勝手気になることを勉強しがち
よく考えられたカリキュラムがあるので、それに則って勉強を進められる。
- 期限がないのでダラダラ勉強してしまう
明確な期限は無いのですが、他の方がガンガン進められているので、触発されて効率よく勉強するようになりました。
- フィードバックがないので学んだことのアウトプットが正しいかわからない
アウトプットを確認していただけるので、間違っている場合はちゃんと指摘を得られます。
結論
まぁ、このように色々出来るようになりました。勉強していて楽しいし、真面目に勉強している人は多くて好感を持てるしでかなり良かったです。 あとは、実際に学習に使っているシステムをアジャイルで改善する課題があるのですが、こちらをやってみたいが為に入ったようなものなので、頑張りたいです。(現職はウォーターフォールのため、アジャイルのことは何もわからない)
SierでITエンジニアを始めてから二年で読んだ本
棚卸として書いておく。
Python
- 独学プログラマー
大体この本を読んだせいで今ITエンジニアをやっている。
- みんなのPython
上の本の流れで読んだ。Pythonはもう忘れた。
コーディング
これからはじめる プログラミング基礎の基礎
Webを支える技術
リーダブルコード
Code Complete 途中まで
詳説 正規表現
プログラミングの基礎
おすすめ。関数型言語の入門に最適。プログラミングをする上での状態遷移やTDDやアルゴリズムやその他いろいろなことを学べる。
セキュリティ
- 安全なWebアプリケーションのつくり方
Java
DB
JavaScript
Node.js 超入門
JS primer
JavaScript本格入門
visual studio code 実践ガイド
ハンズオンJavaScript
ハンズオン Node.js
React
- りあクト 1-3
Ruby
Ruby超入門
プロになるためのRuby入門
パーフェクトRuby on Rails
テスト
オブジェクト指向
オブジェクト指向でなぜ書くのか
実践オブジェクト指向設計入門
unity
- unity5入門
Linux・unix
まだまだ読んだはずだがめんどくさくなったので今度更新する。
好きなゲーム
本当に好きなものだけ。記憶を消してまた遊びたいものだけ。 何故書いたかというとouter wildsは本当に素晴らしいということを伝えたいから。
シングルプレイ
- portal
- portal2
- outer wilds
- スーパーマリオサンシャイン
- マリオ64
- sekiro
- darksouls
- persona 5
- DQ 5
- ポケモン金銀
- last of us
マルチプレイ
- team fortress 2
- apex legends
嫌いなゲーム
- league of legends
徳丸本 33-001a:シンプルなリクエスト(CORS対応)にて CORS対応ができない
事象
徳丸本 33-001a:シンプルなリクエスト(CORS対応)にて CORS対応ができない
該当HTMLからXMLHttpRequestを行ったとき、
というエラーが表示される。
OWASP ZIPには以下のエラーが表示される
原因
api.example.netへの疎通が取れていないことが原因だった
解決策
hostsファイルのtypoを修正して解決
javaでxml parse実行時にjava.net.ConnectionException connection refusedエラーが発生する
事象:
java11にてDocumentBuilderを用いてxmlファイルをparseしようとした際に、
java.net.ConnectionException connection refusedというエラーが発生される。
原因:
DocumentBuilderはparse実行時にリモートにあるDTDというXML文書の形式を定義したファイルを読み取りに行く。今回の実行環境では、リモートファイルへのアクセスを遮断されていたため、事象が発生していた。
解決策:
以下を参考にし、DocumentBuilderの実行時にリモートDTDを読みに行かないようにインスタンスの定義を変更することで、解決することが出来る。ただし、リモートDTDを読み取ることが出来ないため、parse時に別の問題が発生する可能性がある。
https://qiita.com/yoshi389111/items/3d0da72b1f2ccd947052
振り返り:
なぜリモートDTDへのアクセスが遮断されていたか不明
リモートDTDへのアクセスが必要な理由が不明
リモートDTDの役割が不明
パース実行時にリモートDTDを読み込まないことによる影響が不明
パース実行時の動作が不明