read “Beyond Software Architecture”

ビヨンド ソフトウェア アーキテクチャをずいぶん前に積読にしていたので読んだ。

読む前はシステムアーキテクチャの話だと思っていたのだけれど、フタを開けるとソフトウェア開発に関する全般を扱っていた。単にシステム開発に限った話ではなく、ソフトウェア開発する対象や、マーケット、人といった様々な要素に対するアーキテクト、つまり様々な構造にまでその話の範囲を広げていた。

ソフトウェア開発と人の関わりから始まり、ソフトウェア開発とマネジメントの話(ここには、プロダクト開発におけるコンセプト提案などの重要なところも書かれていた)に入りながら、だんだんとシステムによっていく。作るシステムのマーケティングの話やテクニカルな話。もう少し進むと、ログやセキィリティ、リリース、変更管理なども取り扱う。

このように、ソフトウェア開発においてシステム自身の狭義のアーキテクチャではなく、全般を扱っている内容となっていた。

そういえば、私は大学なんかでプロジェクトマネジメントを少し学んだり、話を多く聞かせてもらったのだけれど、こういう全般的な話を受けたなーと思いながら読んでいた。社会人になって、経験も多少積んで、その上で読むと頭の中を整理したり、そういえばこれも必要だったなと思い出すことができた。

最後に。この本で印象的だったことは、品質保証という役割が度々出て来たことと、その活動の範囲の広さをちゃんと説明しているところだった。

Read “Functional Programming: A PragPub Anthology”

Functional Programming: A PragPub Anthology を読んだ。まだβだったけれど、内容はだいぶまとまっててあとは微調整して発売という感じを受けた。

The Functional Paradigmから入り、Scala、Clojure、Elixir、Haskell、Swiftと関数型というテーマに絡めたそれぞれの言語の特性に触れながら話は進む。それらがひととおおり終わり、考え方を経験した後、Going Deeperということでそれらを再び題材に、より言語毎の特性、テスト(コード)の話、タイプシステム、The DCI architecture、そしてLuaと理解を深めていく。

この書籍をまるっと読むと、いくつかの言語から関数型言語、関数型な考え方に触れ、それらを学ぶことができる。さらには軽くそれらに触れることで、いわゆる写経もやりながら理解を深めることができるので、とっかかりとしても有用な内容だった。特に前半は、その言語に触れたことがある人からすると読み物的な内容に見えるので、考え方を整理するという形で触れることができると思う。

個人的にはElixirやSwift、Testing周りが関係が強いので、そこら辺は特に楽しむことができた。

例えば、ElixirやSwiftのProtocolの話。SwiftではProtocolはGlobalスコープに対して定義される一方で、Elixirでは特定の型に対して定義することができる。そのため、影響範囲を限定することができるのでより安全に利用することができるという話も。

テストの話としては、Elixir、Haskellが題材になっていてよかった。Elixirの話では、TrueStoryを題材にして、可読性の高い(テストしたいシナリオ・ストーリーを理解しやすい)テストコードの書き方に対しても言及している。その中で、パイプ演算子を使った関数型としての書き方に触れながら話を進めている。

Haskellでは、型システムのほか、C言語で書かれたコードをHaskellでラップしてテストコードを書いていく方法を載せている。ほかの言語をテストするためにHaskellを使う形は興味深かった。

やー。思いの外、Elixirに関する話が多かったのとHaskellを使った説明も多く、個人的にはそれだけで満足度が高かった。Haskellはがっつり触れたことはなく、考え方を学ぶために触れている側面が強いけれど、触れる機会が増えてきたらまたこの書籍でさっとHaskellは頭の中を整理したい気分。

read “ZERO BUGS シリコンバレープログラマの教え”

ZERO BUGS シリコンバレープログラマの教えを読んだ。
タイトルと、その副題の高品質なコードを書くための物語というところですね。

エッセイ形式なので、全体を通して、物語を楽しむように読んでいきました。
わかる、あるある、なるほどなーというようなところが色々あり面白かったです。

「すべてのエラーは、あなたが最後にプログラムを変更した場所から3行以内にある」 by Joe Armstrong の引用。

ドナルド・クヌースの、ソースコードがドキュメントになるような文芸的プログラミング(literate programming)に対する考え方。

トランザクション処理のACID(Atomic, Consistency, Isolation, Durability)への言及。

人月の神話と、小さなチームならどんな方法論も上手くいくという話。これは、プログラマが習熟すれば、自分自身を実質的に管理できるようになるから。

Linuxカーネルのコードスタイルにある、それぞれの関数のすることは1つのことだけという姿勢。それとそのコードたちがPolymorphism、オブジェクト、関数型プログラミング、メッセージパッシングの全てをCで実現していること。

OpenBSD開発における、1箇所の修正に対して全体を見直すという、局所と全体の繰り返しのループ。

Erlangのモジュール同士のメッセージパッシングの形が、アラン・ケイがオブジェクト指向で表現したかったアイディアの理想形の1つであるという話。

などなど。

私の専門は品質/テストにあたる分野ですが、そのような立場の人も様々な領域を学ぶ必要があるのと同様、こういう話も知ってもらいたいですね。

read “実践 日本人の英語”

実践 日本人の英語を読んだ。

3作目。

ちょっとしたtipsとして読める点が良いですね。その中で、自身が出来ていること/いないことを確認しながら頭の中に印象付けることができている感じがします。

そういえば、so/very は同じ副詞として使えると思っていたのですが、違ったのですね。お恥ずかしい。
so…that… の形が必要で、感嘆詞などはこのthatが省略されているから類似用語として使うことができる。一方、この that… が使えないような文章の場合はsoではなくveryを使っていくべきという。例を見ていると、感覚的には正しく使えていたみたいですが、運が良かっただけぽい。

接続詞のつながりも。so, since/because, as, for, and 。因果関係の繋がりで、 so が強く、 and がよりカジュアルな弱い感じになるとか。 as/for は書き言葉のような強さがあるみたい。これらはあくまでも論理的関係性だけを指す模様。
普段、 andsince, so をよく使うなーと読んでいたのですが、所々、因果関係が弱い(必然性がない)のに so を使うところとかちらほらあった気がします。 andsince はそこまで外れた使い方はしていなかったぽい。最近。

あと、小技として紹介されていた副詞の位置、接続詞、分詞構文の使い方は感覚的にやっているところもあったけれど、色々と説明を読んで入るとこうする方が良いのかとか気づけてよかった。

色々と自分のケアが届いていないところだけれど、意味としては大事なところに気づかされるというのが良いですね。この本。
反射的に英語が出る、出すことができる語彙/文法はまだ限定的だけれど、それがスラスラ出るように継続して学んでいきたいですね。

「続・日本人の英語」を読んだ。

続・日本人の英語を読んだ。

前回読んだ日本人の英語に引き続きですね。

特に文体が変わったとかもなく、なぜそう英語で表現するか、日本語からの英語訳、その逆などで一方の言語では表現できないこと、その逆などが説明されています。

個人的に、使役動詞に関するところの認識が一部想像してたことと異なるところがあり、学びになりました。

確か、あと実践編があった。

「Hooked: How to Build Habit-Forming Products」を読んだ

Hooked: How to Build Habit-Forming Productsを読みました。

これも何か読んでて気になったので。この書籍は習慣を作るための戦略とか、ケーススタディを中心にのせているものです。

Trigger => Action => Variable Reward => Investment => Trigger => …

というサイクルが、習慣として続いていくことが理想として、そこに至るための様々な学びがまとめてあったり、ケーススタディとしてまとめられています。また、習慣ゾーンにはいるには、frequencyとperceived utilityが重要な2大要素だと書いています。

この習慣化は、初めは nice to haves から入り、それがだんだんと習慣へと変わっていき、いつの間にか must haves になって習慣となっているという形が案外多いようです。いきなりmust havesではなく、やっぱり入り口はnice toからなのですね。きっかけづくり。

以下でいくつかかいつまんで見ると:

  • Triggerは、利用者の環境から影響を及ぼすexternal(外側)からの動機づけと、何か利用者の記憶に植え付けて影響を与えるinternal(内側)からの動機づけが大きくある。
  • 習慣的に利用するようになるには、Time, Brain Cycle, Money, Social Device, Physical effort, Non-routineによるものがあり、それらを行動のきっかけとして作る。

など。このほかに、hobit testingと題して習慣化に対するテストの話も書かれていました。そこでは、ユーザインタビューなどの中で、習慣化するような操作手順を踏んでいるかなどを見るためのtipsが書かれたりしています。

ただ、これらは結局はそのアイディアを自分たちで出すことが第一歩なので、1つの大枠としてこういう思考をすると習慣に結びつけやすい、ということを意識するくらいが良いのかもしれないですね。

[Kotlin]Kotlin in Action vol3

Kotlinを学んでいて、

みたいな感想を受けました最近。

class Button : Clickable, Focusable {
    override fun click() = println("I was clicked")

    override fun showOff() {
        super<Clickable>.showOff()
        super<Focusable>.showOff()
    }
}

interface Clickable {
    fun click()
    fun showOff() = println("I'm clickable!")
}

interface Focusable {
    fun setFocus(b: Boolean) =
        println("I ${if (b) "got" else "lost"} focus.")

    fun showOff() = println("I'm focusable!")
}

fun main(args: Array<String>) {
    val button = Button()
    button.showOff()
    button.setFocus(true)
    button.click()
}

Kotlin、このように複数interfaceを受けてsuperで順序選択するんですね。
Kotlinでは、初期では final がデフォルト。open class Hoge : Neko {} を使う場合、そのクラス内で宣言されるoverrideなんかは open が暗黙的に宣言されるので、final にしたい場合は final を宣言する必要があるらしい。

まだ先は長いですが、徐々にKotlinに取り組むことができ始めた。