フリーランスのエンジニアが2017年に読んでためになった本5冊
2017年、読んで良かった本3冊 - 2Dゲームを開発する日記 https://t.co/xSrokoluhb
— 闇のAndroidアプリデベロッパー (@okuzawats) 2018年1月2日
@okuzawats さんのツイートを見て、マイナー?な本の紹介もされていて刺激をもらったので、たいしたことないAndroiderな僕の去年勉強になったと思う本を5冊ほど紹介していきます。
逆説のスタートアップ思考
別に、ハッキリしたホームランを狙うプロダクトがあるわけでもなくスタートアップを興そうとかは考えていないのですが、ここに書いてある事がSF界隈での当たり前なのだという事をしるためには良い本です。
この書籍に書いてある大まかなことは下のスライドをみるとわかります。
www.slideshare.net
これだけでもかなり面白い内容ですが、書籍の方には(情報が多少古かったりするのかもしれませんが)米国のスタートアップ界隈どのようなことが起きているのかを垣間見る事ができ、日本でフリーランスとして活動したり、就職が必要になったときにどういう企業を選ぶかの参考にもなります。日本のプログラマ等のエンジニアがSO狙いの糞しか集まらないような筋の悪いスタートアップに遭遇する確率を減らすためにもどうでしょうか?
関数型リアクティブプログラミング(Programmer's SELECTION)
プログラミングが本業なので、自分のプログラミング観を一つ崩した本としてこの「関数型リアクティブプログラミング(書籍)」を紹介したいです。
RxJavaが日本のAndroider界隈で話題になったとき、RxJavaが何なのかを知るには情報がほとんどなくて全然理解できないで、しばらく使い方や利用例だけで何とか知識を増やしていったのですが、この本の序盤のラザニアの例やリアクティブプログラミングと関数型リアクティブプログラミングの違いの解説で腹落ちしたので、僕のように他人の説明ではまったく腹落ちできない僕のような人は序盤の部分を読むだけでもリアクティブプログラミングについて理解したい人には充分に価値があると思います。
僕のプログラミング観がどう崩れたのかって話をすると、やはり本書のラザニアの例が中心になります。FPRでのコードは「手順の説明(操作的定義)的なコードであるより概要的(概念的定義)であるように宣言的プログラミングを利用する」という感じの説明が序盤にあるんですが。まさに僕が日ごろからOOPで書いても「コードがぐちゃぐちゃになる人は、処理の粒度が混ざって見通しが悪いコードを書く、逆に粒度が整理されていて見通しが良いコードはぐちゃぐちゃになりにくい」ってところと、厳密的には違うのですが、リンクしたというかそれにさらに、昇華されたもののような知識を手に入れられたのが大きいです。
具体的にはこんな感じです。
ラザニアの作成を手順の説明(操作的定義)的な書き方で表した時の例
1. 大き目の鍋に油を熱する。
2. 玉ねぎをきつね色になるまで炒める。
3. 牛ひき肉とトマトを加える
4. …
ラザニアを概念的定義で表した例
* ラザニアとは、チーズソースの上に平打ちのパスタ、ボロネーゼ、チーズソース、平手打ちのパスタ、ボロネーゼを順番に重ねていき、その上にする下したチーズをかけてオーブンで45分焼いたものである。
* ボロネーゼとは・・・
* チーズソースとは・・・
とこんな感じです。これをコードで表す感じです。あまり厳密的ではないですがRxでいうならそれぞれボロネーゼ、チーズソースといった名前のついたObservableをつなげて合成していくとラザニアができあがって行くイメージでしょうか? 細かい点は購入するなりして本書にあるコードを見てくださればわかると思います。
FRPではそれがストリーム(シグナル?)の関数の合成として表現できるという事がわかったので、現在の自分が個人開発で書くViewとロジックをつなぐコードはRxBindingなどを使ってストリームの合成で書くようになってしまっていて、それ以外の書き方はなるべくしないようにしています。ちょっとしたハシカです。(この手法がプログラミングにおける書き方のベストというわけではなくあくまでも個人の趣向に依存していますが、対話的で複雑なリアクティブなコードが書きやすくなっていて非常に有益性を感じています)
RxJavaの記事を見ているとFRPについてネガティブに書かれている記事が見られたりするんですけど、まだ何がどう悪いのかについては彼らが言う事を理解するには至っていません。状態が隠れて見にくい。一度作りこんでしまうと変更しづらいという話を聞きますが、それは書き方の問題をFRPの問題と転嫁しているのか、FPR自身の問題なのかを確かめられFRPに未来がないと感じるまでは少なくとも続けるかもしれません。(賢者は歴史に学ぶという話がありますが、それが可能なのは限定的で、当人や伝達者の改竄、バイアスが発生している可能性が小さくない以上、学べることはそうは多くないと考えています。選択と集中はこういうところで発揮したらいいかと。)
本書で紹介されるのは主にSodiumというライブラリなのですがRxJSでFRPのやり方やRxの問題点なども開設されているので、RxJavaについて知見を得たい方にもおススメです。(それがRxであるはず)
本書はさらに実践的なFRPを段階的に学べる内容になっています。僕もここの3章までの内容などを実際にRxJava(Kotlin)で書き起こしてみました。
プログラミングClojure 第2版
去年は、僕にとっての関数型プログラミング事始めでした。
関数型プログラミング自体は以前から気にはなっていましたが、Kotlin、ScalaやRxJavaを少し触る程度でおわっていたので、改めて本格的に関数型プログラミングを学んでみたいという事で、Scheme、OCamlやHaskell、Scala、Rustなどを選定しているうちに一番興味を持ったのがClojureでした。
まずなぜClojureを選んだかというポイントで言うなら、言語的にシンプルであるというポイントです。実は始めたときにはそのシンプルが何を指すのかわかっていなかったのですが、いろいろな関数型プログラミングが利用できる言語について知っていく上で他の言語は単純な関数型プログラミングを知る以上に多くの知識があふれており面倒に感じました。情報が多いことは良いのですが、関数型プログラミング初心者が選ぶにはたやすい言語ではない言語が多すぎ、少々辟易していたところにClojureという言語を知ることができたのが大きかったかもしれません。さらにRxやKotlinなどで勉強している関数型プログラミングが表現している延長に近いもの(厳密的ではないが並行処理としてのデータ不変やロック回りの話や関数ファーストみたいなところで、モナドがどうとかという部分ではない部分)を勉強したかったというのもあります。
本書ではClojureを知るという意味で全体像、文法の基礎を学ぶのに適しています。
書籍の話ではなくClojureの勉強の話全般になってしまうのですが、日本語書籍は限られていますがClojureのコミュニティは非常に活発的で多くの人が積極的に参加している感じで、Clojure言語の設計者であるRich Hickey氏のカンファレンスでの発言はとても本質的で、非常に刺激されるものがあり。ぜひ継続して学んでいきたい動機が多い言語です。
Clojureのサブ勉強本として仕えたのが「七つの言語 七つの世界」という書籍です。全部は読んでませんがいろいろな言語を知ることができます。この本の著者はモナド推し、Haskell推しのようですがw
Clojureでリアクティブプログラミングやりたいと思ったので下記の書籍もKindle版を買ってみました。
手順の説明は非常にわかりやすい英語になっているので、英語が苦手でもそう怖くはない気がしています。
Clojure Reactive Programming - How to Develop Concurrent and Asynchronous Applications with Clojure
真面目な話はそろそろやめて、怪しい本系を紹介していきたいと思いますw
残酷すぎる成功法則
これはAmazonで結構上位にあった本なので、有名どころすぎてアレかもしれませんが。
最近話題になったグリッドについても、それだけではだめだとかいろいろ気づかせてくれる内容が多かったし、エビデンス込みで解説してくれるので自己啓発に余念のない人は、一読しても損はないかなーという気がします。
2100年の科学ライフ
この本は怪しい本ではないですがw
今後のテクノロジーが発展していっても、ハイテクはハイタッチ(他人との共感を示せる場)がないと決して成功しないという話があり。全部読んではいませんがとても興味深い内容になっています。
去年はKindleのOasisを買ったので、積極的に利用して通期でぶっとい本2冊、MBA、スマホ3台みたいな重装備をするケースを減らしていこうと思います。
難問!?:ロジカルな思考能力を試そう~
妹の中学校の問題マジでわからんねんけどwwwwww
— いざかや (@izakayanotenin) 2018年1月1日
誰か解ける人おる??ww pic.twitter.com/jhMe9yYLJB
これ10分くらいで解けた。
難問ってほどではないけど。
これって
ログを読んで、そこに書いてあることから推測ができるエンジニアならわかる系の問題ですね。
なので問題解決が大得意なエンジニアさんにもやってみてもらいたいです!
問題が解けたら煽っていくすたいるw
DDDが難しいって話なんじゃけど...
DDDの入門でつまづくって話
なんか思う事があったのだ書いた。
DDDのサンプルコードのリンク集だとおもってみてもらうのがいいかも。
— ぷなつしー@サイドPJもやる個人事業主 (@Pooh3Mobi) 2017年9月24日
DIが前提で難しいん?
ヘキサゴナルアーキテクチャみたいなものを使うとDIPの概念とDIの導入の検討が必要になるという話で、DDDの思想には関係ない。
それでもDIが知りたい場合は次の項へ。DDDの話のみでいいなら飛ばしてね。
それでDIってなんなん?
DI自体は単純に依存関係をJavaのインターフェイスみたいなもので、実装と抽象を分離するって話。
たとえばサーバー側がまだ用意できてないみたいな状況でもMockクラスで置き換え可能にしておいて、Stubなデータを返す実装で簡単な通信回りの単体テストができるようにしたいとか,Javaのクラスベースで実装の置き換えを可能にしておくとか、そんなイメージで良いと思う。
実際にそれを使う事はテストコード書く時が一番使う。
単体テスト時、サーバーが準備されていないけどJsonのフォーマットだけ決まっている時とか。new Foo(new BarMock())としているところがnew Foo(new BarImpl())みたいに簡単にスイッチできるのって楽だよねとかいうのはほとんど幻想だってこと。
ポエム・より良い未来を選んで滅亡する話
みなさんはナッシュ均衡とい言葉をご存じだろうか?
僕もついこないだ知って大変関心して以来
馬鹿の一つ覚えのようになってしまっている(実際はそうではないが
僕が今頭の中に残っている、ナッシュ均衡というのを要約すると
ゲーム理論上で考えられる、プレーヤー同士が協力関係にない時 プレーヤー同士が互いにベストの選択をしようとした結果 プレーヤーが選べる選択肢が狭まる
そんな話だったと記憶している。
うろ覚えで悪いが、今回重要なのはゲーム理論の話ではない。(よってここで僕の記憶力に関する問題がテーブルに並ぶことはない
まぁ題名と、ナッシュ均衡という言葉を知っているだいたいの人は
ここでブラウザバックをするのだろう。
まぁそれはそれでよいかな。
いまさらだけどDDDとその書籍とサンプルコードのご紹介
この記事はDDDについてメモです。よくまとまっている記事をめざしているものではありません。 またこの時点では曖昧な知識も多いですので、多少読みにくかったりツッコミどころが多い事もあります。 またブログはまだ苦手な領域ですので読みにくいと思いますがすみません。 ご了承いただければとおもいます。いただけない場合はブラウザバック
続きを読む個人事業主PG(プログラマ)のススメ
今日は電車で思いっきり体重をかけられた背中が痛いのか、風邪で痛いのかわからない+本当に鼻づまりと、咳、くしゃみ、37度ちょっとの熱が出て、どう見ても風邪なので仕事がまともにできない問題もあり... あと稼働状況も適切な範囲内なので、バグ修正?テスト後、リリース前ですがお休みをいただけたので、ブログを更新しようとおもいました。
ターゲット 今日話したいのは、ちまたでよく言われる?35歳定年説と、30台後半に差し掛かってもマネジメントじゃなくてもっとプログラムが書けるような環境に身を置きたいと考える人がターゲットでしょうか? あとは自分と同じ境遇(僕は過去形だけど)の人ですね。
境遇というのは、 SIerみたいな会社に勤めていて、客先で常駐していて、自分が所属している会社への帰属意識が段々薄くなり、 会社の行事や、会社の人との交流で、自分の技術志向?と回りの意識差が大きくて悩んでいる人のことです。
注意<Caution!>
お客さん視点でももっと、個人事業主がカジュアルになればいいなとは思いますが、どんな人でも個人事業主をやったらいいという話ではないです。
あくまでも自己責任ですし。いい大人としてしっかり判断していただければと思います。
以下本文です。
続きを読む