迷走

友人と slack で話してて、「エンジニアとして生きていくためにはどうするべきか」という題の結論として離島に橋を掛けたい、といういい話をした。

2017年1月27日の深夜の会話。

star__hoshi [00:25]  
:thinking_face: これガチで動いたらすごいけどどうなんだろ

sjnya [00:29] 
htmlをjavaとかswiftに変換する感じなんかな

star__hoshi [00:30] 
なのかなあ、クソアプリが増えるのだけはやめてほしいな

sjnya [00:31] 
逆に考えるとネイティブエンジニアはちゃんとネイティブ要素考えないとって気になってくるな
ネイティブ要素だけで生き残れるのか…

star__hoshi [00:31] 
確かに

sjnya [00:32] 
webエンジニア極めたほうがニーズある気が

star__hoshi [00:32] 
まあ5年たったらスマホもオワコンな気がするんで、アプリに縛られない基礎的な知識とかサービスの概念とかそこらへん押さえとけって感じですかね

sjnya [00:33] 
あー分かる、そういうこと考えたことある

star__hoshi [00:33] 
web の方が明らかにニーズありますよね、 react-native キテるし、webフロントエンドに投資するのが一番コスパは良さそう

iOS やってて、iOSで最適に動かすためにはどうするかってのよく考えるんですが、それって iOS がなくなったら死ぬ知識なんでもっと根本的に OS がどうとか言語がどうとか設計とか知らないと死ぬなあという気持ちです

sjnya [00:35] 
そうだねー

コード書くのが楽しいから、目先の楽しさ追っちゃいがちになるけど、そういう先のこと考えないとだめだよなー

star__hoshi [00:40] 
といっても雇用は創出されるし、低レベルと言ってはあれですがもっとダメなエンジニアもたくさんいると思うので死ぬことはないですが、がむしゃらにコード書いてても成長しないなあと最近実感します

sjnya [00:44] 
スキルどうこうじゃなくてコード書くのが好きなんだからいいんだよ、的な言い訳してる感あるし、その言い訳のためにコード書くの好きだと思い込んでるだけかもしれないって思うことがある

冷静になるとコード書くよりも、パン焼いてるほうが楽しい的なw

star__hoshi [00:45] 
わかる

sjnya [00:45] 
本当にやりたいのかって思うと分かんなくなる

star__hoshi [00:45] 
というかおれにはコードを書いていく以外の人生が見えていないのでひたすらそれで高みを目指さねばならない、という強迫観念が強くて辛いところがある

もっと広い視野とか持てば人生楽になるのだろうな〜とか思う...

sjnya [00:46] 
あぁそれねー
無理にアイデンティティー化しようとしてる感

star__hoshi [00:48] 
そばとか1回も打ったことないけど、そば打ってみたらそれが天職かもしれないし、狭い IT 業界で色々考えるのもな〜という感じ

sjnya [00:48] 
ww

[00:49]  
hoge さんにこのはなしするとき、そば打ち題材にしてたわw

自分が本当になりたいものに自信がないのが原因だから、同じことばっかしないで人生経験つんで何か見つけなさいって結論だった

star__hoshi [00:50] 
そば打つか

sjnya [00:51] 
飲食のバイトとか楽しかったしなぁ

star__hoshi [00:52] 
コンビニバイトは何も身につかないし何も楽しくなかった

sjnya [00:52] 
コンビニバイト以外の何かだな

star__hoshi [00:52] 
早朝の新聞配達とかやってみたいな

sjnya [00:53] 
案外生き生きしてるかもね

shinyaozawa [00:53] 
土方おもしろいよ

star__hoshi [00:53] 
ITドカタ

物理でもの作りたい

sjnya [00:54] 
まじでやってみないと分かんないよなぁ

star__hoshi [00:56] 
不労所得で生きいけるようにして3年くらい色々やりたいけどそれただの自分探しの旅だわ

[00:56]  
アメリカ横断する意識の高い大学生みたいだな

shinyaozawa [00:57] 
橋作ろうぜ

star__hoshi [00:57] 
橋良い

shinyaozawa [00:57] 
離島にかける橋

star__hoshi [00:57] 
カッケェ

sjnya [00:57] 
あぁーいい

star__hoshi [00:57] 
本土と Dash 島つなごう

shinyaozawa [00:58] 
Dash 島って福島じゃねーの?w

sjnya [00:58] 
近いw

star__hoshi [00:58] 
それ dash 村では

[00:58]  
http://xn--50-hi4azc9fsf5155c.com/wp-content/uploads/2014/10/e.png (254KB)

sjnya [00:59] 
ばれてんのか

star__hoshi [00:59] 
荒らしに行くか

[00:59]  
海賊だ

sjnya [01:00] 
僕はもくもく会からはじめて世界広げてくよ

[01:01]  
今年は迷走してみよう!

star__hoshi [01:01] 
いいな

[01:01]  
スローガン: 迷走

sjnya [01:02] 
嫌いな人としゃべるとかもして、世界広げてく

star__hoshi [01:02] 
意識高い

sjnya [01:02] 
圧倒的成長

star__hoshi [01:03] 
やっていくぞ

「エッセンシャル思考」を読んだ

エッセンシャル思考 最少の時間で成果を最大にする

エッセンシャル思考 最少の時間で成果を最大にする

誰かの DeepWork の書評に「これならエッセンシャル思考を読んだ方が良い」などと書いてあったので読んでみた。

エッセンシャル思考とは、「より少なく、しかしより良く」を追求する生き方で、本書の中で繰り返し述べられてたのは2点だと感じた。

  1. 本質的なことのみ行い、より大きな成果を出そう
  2. 本当に重要なことにのみイエスと良い、その他全てのことにノーと言おう

とにかく本当に大事なことにだけイエスをして、それ以外はノーと言うので、結果としてより大きな成果が出る、と言う感じ。わかる、しょーもない仕事はしない方が良い。

と言ってもなかなかノーと言うのは難しい。この前も悩んだ末に社員旅行と言うイベントにイエスと言ってしまった。行きたくないが、まあ断るのもアレだしと思ってイエスにしてしまった。

イエスと言ってしまうことはあるかもしれないが、ノーと言える基準はしっかり持っていきたい。

私はなぜソフトウェアエンジニアをしているのか?

話は変わるが、サンクスコストと言うのがある。一度やり始めたから後戻りができなくなって無駄にズルズル続けてしまうのは良くないので、早々に辞めろと言うやつだ。本書でも言及されている。

なぜいまソフトウェアエンジニアをしているのかと言うと、その職しか知らないから、と思っている。もちろんコードを書くのは楽しいし、ユーザに価値を提供できる仕事だし、合理的な会社が多い、などの理由もある。

そもそもコードを書こうと思ったのは、大学の周りの人がプログラミングをしててかっこいいと思ったからが5割で、暇だったからが5割。

そのコードを書き始めたのも大学の中盤からで早いとは言えず、最初の頃は勉強するのが辛くて仕方がなかった。中学高校から息を吐くようにプログラムを書いている人とは違う。数学も苦手で、高校1年の初めてのテストが赤点でそれからずっと苦手で、受験も日本史で入学した。仕事でコード書いててもつらい気持ちになることが多いし、毎日勉強しないといけないという焦燥感があるし、5年コード書いているのにオブジェクト指向も良くわからないし、デザインパターンも5個くらいしか知らないし、劣等感ばかりつのる。

つまり私はソフトウェアエンジニアに向いていないのではないか、という話である。

向いていないのであれば、それはサンクスコストなので早々に辞め別のことをした方が良い。
「ソフトウェアエンジニアに向いていないかもしれない」と思いながら「自分の仕事の本質」などを考えるのはおかしいのでは?と思ってしまっている。

しかしコードを書くのが楽しい時もあるし、適当にコード書いてる人よりかはまともなコードかける自信が付いてきたし、正直それ以外の職でどうやって働くのか全くイメージが湧かない。
結局ソフトウェアエンジニアとして顧客に価値を届けることに従事していきたい、という結論に達した。

IT と全く関係ない他の職も経験してみたい、パン屋さんになりたい、蕎麦打ってみたいし、ろくろも回してみたい。しかし他の職を体験したら絶対に「こんな非効率的な職業ありえない」と言うと思うし、ソフトウェアエンジニアに向いているのかもしれない。いや染まっただけか。


以下 wikihub 日報 のまとめ

読み始めた、半分近くまで来たので明日読み終わりそう。
Deep Work みたいな内容で、何かを選択することは何かを捨てることである、自分が何を選択すべきなのか考えよう、みたいな内容。
いわゆる自己啓発本ってやつっすね。

  • エッセンシャル思考とは、「より少なく、しかしより良く」を追求する生き方
  • 今自分は正しいことに力を注いでいるか?を絶えず問い続ける
  • 優先順位を決められない人は他人のいいなりになる
  • 重要なことにイエスというために、その他すべてのことにノーという
  • 何かを得ることは何かを失うことであり、何が最優先か明確にしておかなければならない
    • 以前弊社で「結局ユーザって誰なんですか?」って聞いたら「全員です」って言われてキレそうになったの思い出した
  • トレードオフから目を背けても、トレードオフから逃れられない
  • 集中は歩いてこない、だから自分から集中できる環境に飛び込む
    • Deep Work で読んだやつだ
  • 遊びは大事、遊びはどこまでも本質的である
  • 絶対にイエスだと言い切れないならそれはノーだ

読み終わった。
いい本だったが、自分の考えとだいぶ近く「ウンウンわかる」という内容だったので読む意味はあまりなかったかもしれない。

  • 目的が明確でないと人を動かすことはできない、目的がわからないとやる気が出ない
  • 具体的で魅力的、意味があって覚えたい本質目標を立てよ
  • 絶対にやるべきこと以外の全てに対しノーということが大事
  • サンクスコストにとらわれずダメな行動をすっぱりきる
  • 授かり効果
    • 一度所有すると、それに価値があると思ってしまう
    • これは買う価値があるか?を考えそうでなければ捨てる
  • 人助けもいいが、問題を肩代わるのは逆効果
  • しくみ化
    • 無意識にできるようにすると良い
  • 確実に言えるのは、世の中に確実なことはない、ということだけ
  • 見積もりは1.5倍で考える
  • 仕事を減らしより多くを生み出す
  • 小さいことからはじめ、成功体験を通し、大きい目標を達成しよう
  • 習慣を作れればあとは勝手にうまくいく
  • 大切なのは「選ぶ」こと
  • 「本当に重要なのは何か?」それ以外のことは全部捨てていい

「オブジェクト指向設計実践ガイド」を読んだ

先日 「オブジェクト指向でなぜつくるのか」を読んだ が、内容が薄かったのでもっと濃いオブジェクト指向についての本が読みたかったので、先輩に勧められたこともあり読んでみた。
内容は濃くて良かった、こういう本が読みたかった。

特に良かったのが「オブジェクトがあるからメッセージを送るのではなく、メッセージを送るためにオブジェクトがある」とのところ。
自分はそんな真面目に考えたことはなく、軽い気持ちでクラスを定義しメソッドを作成してしまうので、そうではなく相互関係をちゃんと検討した上で実装すべきなんだなと思った。
そういうメッセージベースの考え方ができるようになると一段上に上がれるとのことなので、意識していきたい。

また、クラス内で具象化してしまうと依存度が高くなってしまい良くないので、 DI して依存度を外から設定できるようにしよう、というのが繰り返し述べられていた気がする。
ここはテスト書くときにほぼ必須なので最近気をつけている。

1つ疑問だったのが、この著者は静的型付を「コンパイル時間がかかる割にメリットが少なすぎる」と言って動的型付を持ち上げているところ。
別にそれはいいのだが、静的型付だったら何も意識しないで済むところを動的型付はテストを書くことでカバーしていて、静的型付にもメリットがあるところをちゃんと書くべきでは、と思った。

全体的な内容は良かったのだが結構難しく、正直あまり理解できない部分が多い… 3ヶ月後くらいにまた読み直そうと思っている。

以下 wikihub 日報 に雑に書いてた感想まとめ。


読み始めた。 Rubyオブジェクト指向についてガチで学ぶ感じになりそう、うわべだけのオブジェクト指向 ではなく真髄に迫る感じがして良い。

  • オブジェクト指向設計とは、「依存関係を管理すること」
  • 設計がないと管理されてない依存関係が大混乱を起こし、1つ変更すると他のが壊れてやばくなる
  • 設計は芸術と言えます、コード構成の芸術なのです。
  • SOLID
  • 前もって詳細設計を作るのは全く意味がない
  • アジャイルが成功するかはシンプル、適応性、柔軟性のあるコード
  • アジャイルは「どれだけの期間で完成するかわからない」を肯定するものであり、オブジェクト指向だってそう、完成時期はわからない

25%まできた。
ためになる!(いつもためになるって言ってる気がする)

Gear と言うクラスを愚直に作った後に徐々に綺麗にしていく流れ。
自分はメンバ変数をいろんなところで叩いてしまうのだが、この本によるとアンチパターンっぽい…。

  • 単一責任のクラスを設計しよう
  • シンプルであれ
  • 設計とはアプリケーションの可変性を保つために技巧を凝らすことであり、完璧を目指す行為ではない
  • TRUE
    • 見通しが良い(Transparent)
    • 合理的(Reasonable)
    • 利用性が高い(Usable)
    • 模範的(exemplary)
  • TRUE なコードを書くために、それぞれのクラスが、明確に定義された単一の責任を持つ ように徹底すること
  • 2 つ以上の責任をもってはいけない
  • クラスが実際に何をしているか、1文で表現できるか?
    • それと、またはみたいな言葉が出たら2つ以上の責任を負っている証拠
  • 設計を決める時、何もしないことで将来的なコストが変わらないなら何もしないで良い
  • 今と未来の可能性のトレードオフを理解しコストが最小になる決断をする
  • 変数はそれらを定義しているクラスからでさえ隠蔽しましょう
    • ruby の attr_reader を使う
    • ジャバで言うと getter, setter かな?
  • メソッドもクラスのように単一の責任を持つべき
  • 1つのこのに専念するクラスは、その1つのことをアプリケーションの他の部位から「隔離」する
  • クラスが知るべきことは自身の責任を果たすために必要十分なことのみ
  • dependency injection で依存をクラスの外にだす
    • Ruby は Interface ないから DI できないと思ってたけどそもそも動的型付だから Interface とかいらないんだった…
  • 場合によっては依存を隠すのではなく、逆に依存部分を強調することでわかりやすくする
  • 初期化の引数にハッシュやデフォルト値を使うとわかりやすい
  • 初期化の引数を変えられない場合(3rd party ライブラリとか)はファクトリーでラップすると良い

オブジェクト思考はクラスがどうこうではなくメッセージをどう送り合うか、と言うことらしい。
正直あまり理解ができてない点が多く、自分は全く理解できてないだなと言うのを理解できて良い。

  • 自身より変更されないものに依存しなさい
    • 具象クラスは抽象クラスよりも変わる可能性が高い
    • 多くのところから依存されたクラスを変更すると広範囲に影響する
  • 変更が多くかつ依存するものが大量にあるとやばい
  • 依存関係の管理で鍵になるのはその方向を制御すること、また自身より変更の少ないクラスに依存するべき
    • Clean Architecture の思想は依存を一方方向にするしそう言うことなんかな
  • オブジェクト指向アプリケーションは「クラスから成り立つ」がメッセージによって「定義される」
  • クラスが何を「する」かではなく、何を「明らかにするか」
  • クラスに基づく設計ではなくメッセージに基づく設計ができるようになるとキャリアの天気になる
    • このクラスがどうするでなく、このメッセージを送る必要があるがどうするかみたいに考えられるようになれ
    • オブジェクトが存在するからメッセージを送るのではなく、メッセージを送るためにオブジェクトは存在する
  • public, private などは明確に意図を持ってやれ
    • rails は private method の先頭に _ をつける (知らなかった…
  • デルメルの法則
    • オブジェクトを疎結合にするための規則
    • 異なる二つ目のオブジェクトを介すことを禁じる (ドットで2つ以上繋ぐな、 music.song.artist とかはドットが2つ繋がれている)
    • 遠く離れたものに依存しているのは影響に気がつきにくくよくない
    • この法則に違反している場合インターフェースがよくないことが多い
  • オブジェクト指向オブジェクト指向間で交換されるメッセージによって定義される、そのメッセージは public interface にそって行われる

真ん中まで読んだ。
ためになる!のだが、静的型付と動的型付を比較し、最終的に「いいから動的型付は最高なんだよ」みたいに押し付けっぽい感じになっててかなり萎えた。
それぞれ良さはあるし、「私は動的型付けの方が良いと思っています」と主張を述べるだけのが良いのでは、この本の内容全部押し付けなのかなと思ってしまう。

  • ダックタイピング
    • DI みたいなもんっぽい、ダックタイピングの概念がしっくりこないまま読み進んでしまっているので結局なんだっけと言う感じになっている
    • 具象クラスに依存しないで抽象クラスに依存しよう
  • 動的型付けに慣れればその方がよくやすく、描きやすく、理解しやすいと思うでしょう
    • お前んなかではな?
  • 静的型付によて安全になると言う考えは幻想です
    • お前んなかではな?
  • 動的型付けはコンパイル時の型検査と言うコストが高い割にわずかな価値しか得られないが、動的型付けは莫大な効率性がある
    • まあビルド時間長いのはつらいな
  • 継承
    • 根本的には「メッセージの自動委譲」の仕組み

65%まできた。 Module と Class の違いが述べられていたがあまりよくわからなかった、つらい。

  • 抽象のルール
    • モデル化しているオブジェクトが一般-特殊の関係をしっかりと持っていること
    • 正しいコーディングテクニックを使っていること
  • Ruby は抽象クラスが存在しないので具象化できてしまうが、みんな良識があるから問題がない
    • いやいや、それで問題があるから静的型付によって強制力を効かせるんじゃないの
  • 抽象クラスを作るときには、具象クラスのメソッドを抽象クラスに移動させた方がいい
    • 抽象クラスから具象クラスに移動させるのはやめた方がいい
  • テンプレートメソッドで継承うまくやろう
  • モジュール
    • 様々なクラスのオブジェクトが、一箇所に定義されたコードを使って共通のロールを担うための完璧な方法
  • is-a
    • class
  • behaves-like-a
    • module

75%。コンポジションとかの話、正直よくわからなくて、もう一度この本を読み直した方が良さそう :cry:

  • 一部のサブクラスだけ使うようなメソッドをスーパークラスに置いちゃメッ!
  • スーパークラスとサブクラスは置換可能でなければならない
  • 継承する側で super を呼び出すのはやめて、フックメッセージを使おう
  • コンポジション
    • 組み合わされた全体が、異なる備品の就業以上となる方に、個別の部品を複雑な全体へと組み合わせる(コンポーズする)行為
    • 自転車にはパーツがある、 has-a の関係であると言うことらしい
    • 包含される側のオブジェクトは、包含する側のオブジェクトがなければ存在し得ないもの
      • 学部と言うのは大学がなくなれば存在しなくなるので、コンポジションと言える

87%まできた。明日読み終わる。
静的型付だったら問題にならないようなことをつらつら書いていて、なんでこの人静的型付ディスってたんだろうって感じがある。

  • 継承かコンポジションか迷ったらコンポジションにした方が良い
    • 継承よりも依存が少なくなるから
  • 継承の懸念2つ
    • 継承が適さない問題に対して、謝って継承を選択してしまう
    • 他のプログラマが予期せぬ目的で使うかもしれない
  • コンポジションをちゃんと使えれば、単純で抜き差し可能で、拡張性のたかく変更にも寛容なのができる
  • 継承は特殊化、 is-a関係に継承を使う
  • behaves-like-a関係にダックタイプを使う
  • has-a関係にコンポジション
  • テストダブルはロールの担い手を洋式化したインスタンスで、テストで飲み使われるもの
  • モックはダブルではない
    • モック、スタブ、テストダブルらへんが何をさすのかよくわからないのでちゃんと学びたい

読み終わった、良い本だった。

  • プライベートメソッドはなるべく書くな、書いたとしてもテストは書くな
  • 副作用のないメッセージはクエリメッセージ
  • テストを書く前にリファクタリングをしてより良い設計にしていこう
  • リスコフの原則に従っているか証明する簡単な方法は、契約を共有したテストを書き、全てのオブジェクトにそのテストをインクルードすること
  • スタブを用意するためにサブクラスを作るのは、リスコフの置換原則を破らない限り使える
    • サブクラスを作るときは、そのサブクラスが古くならないようにテストを書こう

iTunes Connect の売り上げとトレンドにある「デスクトップ」は何者なのか

iOS 向けにしかアプリをリリースしていないのに、 デスクトップ というデバイスでのダウンロードがある。

f:id:star__hoshi:20170427101820p:plain

デスクトップとは

stackoverflow.com

どうやら、 PC の iTunes からダウンロードした時はデスクトップとしてカウントされるらしい。どこ経由でダウンロードされたのかが計測対象になっていると思われる。
デスクトップとしてカウントされると、 iPhoneiPad どちらで使われるかは不明。

おそらくだが、 MDM とかで機械的にインストールする場合もデスクトップとしてカウントされる気がする。
(確信はないが、会社でリリースしているアプリが異常にデスクトップ率が高い)

「モバイルアプリ開発エキスパート養成読本」を読んだ

モバイルアプリ開発エキスパート養成読本 (Software Design plus)

モバイルアプリ開発エキスパート養成読本 (Software Design plus)

モバイルアプリ開発エキスパートになりたいので読んでみた。
初っ端からいきなり Kotlin の話があり攻めてて良い。

iOS エンジニアなので iOS 関連のところの心に残ったことだけ、さらにこれは書評ではなくメモに近いので、本の内容がどうこうよりもそれを読んで感じたことを書いておく。

3-1 Swift 3.0 入門

Swift 3 の命名規則についての記事を読むたびに、英語力が足りないと Swifty なコードをかけないと感じる…。

Protocol の命名、 HogeProtocol とか書いてるのみたりするけどそれは思考停止で Swifty じゃないのだろうな。
メソッドの定義はなんとなく動詞で書きたくなってしまうのだが、これは Swift 関係なく改めないとマズそう。

3-2 Xcode 8 入門

Memory Graph Debug の使い方などが書かれている。
Xcode Extension については、私は XVim のために署名を外して使ってしまっている、誰か XVim-Extension を作ってくれと言う気持ちしかない。

4-1 リアクティブプログラミングと Rx, 4-3 RxSwift 入門

Rx なんとなく理解してきたタイミングで読んだが、やっぱり概念はわかるけどモヤモヤが晴れないと言う感じ。難しい。

Subject や Value は積極的に使うべきではないと書かれていて、でも MVVM やるなら PublishSubject とか使うわけじゃないですか、これもアンチパターンなのだろうか。
宣言的にかけるのは確かに良い。のだが、素人が Rx してしまうとわけがわからない複雑な Stream ができてしまう気がする。と言うか私の書いている個人開発の MVVM がだいぶ辛くなっている。
自分一人でやっていると間違いに気がつきにくいので、複数人でレビューし合いながらやるのは良いと思う、自分の理解力や実装力が足りないと言われてしまえばそれまでだが。

UITextField の初期化時に空文字列が bind されてしまうのに困っていたのだが、 skip(1) で初期化時の空文字列は無視しよう書かれていて、一つ疑問が晴れてよかった。

5-2 タイプセーフでモダンな iOS アプリの設計

storyboard, TableViewCell の初期化やキャストを Swifty に書いていこうという内容。
会社でやっているのは segue で画面遷移しているので、 segue は早く引き剥がしたい。
TableViewCell のもこのやり方に変えるぞ!

6-3 iOS アプリのテスト

めちゃくちゃためになる。
UITest は書いたことないし、パフォーマンスがテストできるのも恥ずかしながら知らなかった。
今後 UITest を書くかと言われると微妙、でも書いてある通りログイン画面などの非常に重要なところはあったほうがいいかなと思った。

全体として

読むのにそんなに時間はかからないし、ポイントがわかりやすくまとまっているので良かった。
やはり読んだだけではモバイルアプリ開発エキスパートにはなれなかったので、学んだことを少しでも実践していきたい。

あと表紙のおっさんは誰なんだろう。

「SOFT SKILLS ソフトウェア開発者の人生マニュアル」を読んだ

SOFT SKILLS ソフトウェア開発者の人生マニュアル

SOFT SKILLS ソフトウェア開発者の人生マニュアル

めっちゃいい本だった。

ソフトウェアエンジニアとして勝ち組になるためには〜みたいなことがひたすら書かれており、意識が高い。

面接、給料、資産運用、健康などとソフトウェアとは関係ないことも多く、確かに人生マニュアルだった。
1年に1回読み直したい。

特に強く心に残ったことが2つあった。

バカにされるのを恐るな

何かをやろうと思うとき、バカにされるのが怖くて一歩を踏み出せないことがある。
例えば勉強会に登壇して失敗したらどうしようとか、記事を公開した時に内容を間違えていたらどうしようか、などである。 しかし勉強会で上手く話せなかった人のことをあなたは覚えているだろうか、そんなことは誰も気にしないし過ちにも気がつけるのだから勇気を出しなさい、と書かれていた。

また、失敗は敗北ではないのでどんどん失敗し学んでいけとあり、自分は割と失敗を怖がり安全に走るので心にクる内容だった。

本を読み終わりとりあえず勉強会の登壇ボタンをポチッと押した。

ポモドーロ

生産性を高めるためにポモドーロが良いと書いてあり、実際にやってみたらめちゃくちゃ進捗出てすごい。
25分仕事して5分休む、というのは前にもやってみたけど全然効果がなかったけど、「ちゃんとその日やるタスクを決めてからそれを25分以内に1つ消化できるように全力を出す」ようにしたらめっちゃ効果が出て、ちゃんとタスクを決めるのが重要なんだなと思った。

また、ポモドーロやっていると、誰かから話しかけられた時にタイマーを指差して「その話めっちゃ緊急ですか?10分後でもいいですか?」とできるので良い。(向こうは面倒だと思うだろうけど…)

Deep Work にも、毎週・毎朝のスケジュールを決めて時間を意識し仕事をすると進捗が出るなどと書いてあって、本当にその通りだった。

KanbanFlow というサービスがあって、これはタイマーとタスクリストを連携させて、そのタスクがどれだけ時間かかったかなどの分析も丸っとできて良い。

kanbanflow.com


以下 wikihub 日報 で雑に書いてた感想のまとめ。


読み始めた、17%くらい。読み応えがある。
耳が痛いことがめちゃくちゃ書かれている。この本は毎年読み返した方が良い気がする。

特に

自分の仕事はコードを書くことだと思っているなら、考え直すべきだ。…他のあらゆる職種と同様、人と接することである。

がだいぶ心にきた。 :sweat:

以下雑なメモ:

  • あなたはソフトウェア開発の事業主であり、雇用主は顧客である
  • キャリアの目標を決めよ、そして今からその目標に対する月、週、日単位での目標を立てよ
    • ぐぅ、ハードだ…
  • あなたの仕事はコードを書くことではなく人と接すること
  • 悪い行動を懲らしめるのでなくいい行動を褒めよ
    • チームとして〜に出てきた失敗を許容しろって話だ
  • 社交術を学ぶことから得た利益はは一生モノであり、値段をつけられないほどの価値がある
  • 面接する前に相手の会社のブログ読んでマサカリ投げとけ
  • 面接では、能力の高さよりも「頼まれなくても仕事を終わらせるタイプの開発者」と強調しろ
  • まず専門性を特化させ、それから多才になれ
  • ソフトウェア開発で食べている会社は、雇っているソフトウェア開発者に高い価値を置いていることが多い
    • 弊社〜 :innocent:
  • 他の人が嫌がる仕事をすると信頼上がって出世や!
  • プロであれ
    • 自分が正しいとわかっていることのために、難しい選択をあえてすることを厭わない
    • めんどいしこの実装で妥協するか〜というのはプロではない
  • 他人のために働くときは一生懸命度合いが半分くらいになる
    • 独立すると自分のために働くので、その差を感じることになるらしい

5% くらい読み進めた。


32% くらいまできた。
自分の価値を高めよみたいな話で、有名な Podcast にでろとか言ってるけど、そもそも有名な Podcast に出る人は価値が高いんじゃないですかね?

  • 履歴書はプロに書いてもらうのもアリ
  • 自分が選んだテクノロジー以外にもいいものはたくさんあるから選択肢を制限するな
  • 自分をマーケティングするとは、あなたが提供できるものを、欲しいと思っている人と結びつけることに他ならない
  • 質の高いブログを毎週書け

ためになる。
自分をプロモーションするために SNS をうまく使え、カンファレンスで講演しろみたいな話が続く。
ひたすら意識が高い。

  • 自分がやってることの90%は無料で公開せよ(自分のプロモーションのため)
  • SNS で朝食に何を食べたみたいなツイートばっかりしてると人々は離れるから価値のあるツイートをせよ
    • :scream:
  • バカにされるのを恐るな、勉強会にでよ、ブログを書け、マサカリを恐るな
  • 独学
    • 基礎的な知識は何が必要か
    • テーマの幅: どれくらいの規模で、どんなことが可能か
    • 基礎: 20%の知識で日常の80%をカバーするにはどうしたら良いのかを知る
  • 基礎的な理解を得て、その上で何を学習するかの範囲と成功のイメージを定義する

55%まできた。
理解を深める一番の方法は人に教えること、というのが強調されている。
また、生産性の章では Deep Work に書いてあるのとほぼ同じことが書かれている。

本の前半で「あなたの仕事はコードを書くことではなく人間とコミュニケーションを取ること」と書いてあったが、この章では「オフィスのドアの前に'話しかけるな!'と書いた札を置いておけ」と書かれてて、ハア〜どっちなんじゃいという感じだ。

  • 何かを学び始める前に全体概要を把握しておけ
  • 何かを学び終えたと証明できる目標を立てろ、その目標はできる限りスコープを絞れ
    • C# で website 作るぞ、みたいな目標
  • 1冊の本だけでなく多くの異なる本を集めよ
    • 5冊の目次を見比べると重要なことが見えたりする
  • 学習-実践-学習-教え(LDLT方式)
  • メンターは経験をあなたに伝授してくれる重要な存在
    • メンター欲しい〜〜〜〜 :sob:
  • メンターいない人は本を仮装メンターとする
  • あなた自身もメンターになれ、難しそうだけど他者より1歩前に進んでいるだけで良い
  • しかし弟子は選べ、ぶたに真珠を投げてはならない
  • 学位はあって損はない、ない人は資格を取ろう
  • なんかよくわからんけどそのままにしていることは都度メモっていけ、早めに理解した方が今後のためになる
  • チャットは完全な時間の無駄。メールの方が割り込みがないので良い
  • ポモドーロやる時は進捗を計測し分析しろ
  • 毎月、毎週、毎日何をやるのか予定を立てよ。
    • Deep Work で読んだわ…
  • 毎週ブログを1回は更新すること、本を1冊読むことみたいにキメを作ると習慣化される
  • シャローワークはバッチ処理として1日にまとめてやろう

75%くらい。めっちゃためになる。
「この本を読んでる君たちは特別だから勝ち組になろうや」みたいに書いてあって、読んでるだけで肯定感があって上手いな〜と感心してる。

  • 大きなタスクはやる気が出ないかもしれないが小さく分解しよう
    • プログラムだってメソッド分けるでしょ?
  • ハードワークは大変だ、つらい、けどやらないといけない
    • ハードワーク楽しいって口でいう人はいるけど本当に楽しいと思っている人はいない
  • やる気が出ない?いいからデスクに座ってやるしかねえんだごちゃごちゃいうな
  • 怖くて行動に移せない奴がいるが、行動に移さないことが一番怖いんだぞ
  • 給与交渉では先に金額を出すな、会社に言わせろ
  • 筆者もかなりの苦労をした結果金持ちになっているし、運が良かったのもある
    • でも幸運はある程度は自分で引き寄せるもの
  • 不動産投資はローリスクでリターンが見込めて最高

85%、明日読み終わる気がする。 筋肉は素晴らしい、体の健康は心も健康にするなどと書かれている。

私は胃下垂というやつで食べても太れない側の人間で、筋肉をつける前にまず一般的な体型になりたい…。 BMI は17.5とかで異常値であり、大変厳しい。まず病院に行こうと思う。

  • 食事を変えてエクササイズすることで体と頭どっちもよくなる
  • 腹筋割れてるやつは脂肪なさすぎて死ぬやつだからそれを目標にするな
  • トレーニングはつらいが結局最後は根性で歯を食いしばってやるしかない
  • 思考を制御し考えたことを具現化せよ
  • 意志が体を動かす

読み終わった。
いい本過ぎた、感化されたので勉強会に登壇するボタンを押し、病院に予約を入れた。

失敗は良いことだしどんどん失敗しろ、怖いかもしれないが失敗は敗北ではない!とあり、なるほどという感じがある。

  • マイナス思考は実際によくないことにつながる
  • プラス思考は現実を変えるパワーがある
  • プラス思考は、悪いことではなくいいことを考えることを選ぶこと
  • 瞑想はいいぞ
  • 結局正しく実行するためには時間と忍耐が必要である
  • 失敗を喜び、期待し、受け入れ、正面からぶつかることを学ぼう

「軽量・高速モバイルデータベース Realm入門」を読んだ

軽量・高速モバイルデータベースRealm入門

軽量・高速モバイルデータベースRealm入門

Realm は個人開発でそこそこ使っててそれなりに理解しているけど、雰囲気でしか理解してない気がしていたのでちゃんと理解しようと思って読み始めた。

内容的には基礎 + 応用という感じで上級者向けという感じではない。

私は基礎がガバガバだったので、Part2 の基礎編を読むだけで今まで知らなかったことや間違いに気がつけたりしたので大変良かった。
(今まで List クラスを使っておらず、LinkingObject を乱用していたのだが多分使い方が間違っていることに気がついてしまった。)

特に良かったのが Part3 の活用編で、暗号化とか keychain とか Apple に申請するときとか、細かいけどこれを知るのには結構な経験が必要そうなのがまとめられててめっちゃためになった。

Part4 の Twitter クライアントを作る編もためになるのだが、本だけで文字を追うのが辛すぎて流し読みした。多分これはコードを Xcode で開いてちゃんと読みながらやった方が良い。
サーバサイドAPI -> Realm -> UI という流れを経ることで UI は Realm のデータだけを見ればよく、 Realm の Notification で UI も更新できるので、データの流れが綺麗でめっちゃよさそう。

内容はとても良かったのだが、1つどうしても許せない点があって、説明文とサンプルコードが読み手の想像した位置と違うのが大変つらい。
リスト10.3 のサンプルコードを参照、と書いてあるのにその下にリスト10.2のサンプルコードが載っていていて、リスト10.3は隣のページの右下にあったりする。
ページの都合なのかも知れないが、読んでるときめっちゃ混乱したしかなりイライラした。

とはいえ内容は良いし、Realm これからやる人はもちろん、 Realm それなりに理解している人なら2時間くらいでザーッっと読めるのでとりあえず読んでみるといいと思う。
Qiita などに落ちている記事よりずっとためになり、今後のリファレンスになります。

以下個人的な雑メモ:
  • String,Date, Data をオプショナル型で定義するには dynamic var を使用するが Bool, Int などの数値は RealmOptional を使う
    • これは RealmSwift 内部で ObjC の機能を使っているための技術的問題による制約
  • 一対多は List を使う
  • 逆方向の関連に LinkingObject を使う
  • 検索には indexedProperties メソッドをオーバライドする
  • マネージドオブジェクト/アンマネージドオブジェクト
    • 保存したやつをマネージド、保存前をアンマネージドと呼ぶ
  • Xcodeデバッグ
    • lldb で po object する
  • 異なる Realm に同じ object を追加できる
    • add じゃダメ、 create でやる
  • 暗号化キー
    • 文字列で持っていると ipa 解析される恐れがある
    • 動的に生成し keychain に保存するのがいいが、 keychain が消えたら復元できない
    • ローカルに貯めとくデータは最悪見られても良いものにしておこう