最近業務で android も fastlane に乗せたので、 android 枠で話した。
fastlane android 良いと思う、継続的デリバるためのやつだからダメになったら捨てればいい、という軽い気持ちでいけるし。
発表では、たぶん自分はせわしなく話していて、他の人の発表見て「みんな落ち着いててすごいな〜」って思って見てた。
次話すときは資料の枚数もっと減らしてもっとゆっくり話すようにしてみようと思う。
自分は本を読むのが遅く、さらに理解度が低いというつらい感じなので、そこらへんをなんとかしたいと思ってこの本を手にとってみた。
「本を読むのが遅い人は無駄に頑張って読みすぎなので、音楽を聴くようにもっと気軽に本を読んで、1行でも心に残る文章があったらそれで良いんだぞ」みたいな内容だった。あと見出しで判断して違うと思ったら読まなくて良いんだぞ、とか。
無駄に頑張って本を読みすぎというのは心当たりがあるのだが、見出しレベルで判断するというのはする気になれない…それが遅読の原因なのかもしれないが。
言っていることはわかるのだが、あなたはそう考える人なんですね、という感じで自分にはあまりためにならない本だった。
というかそもそもこの本は内容が薄く、1/3くらいでかける内容を冗長に書いている感じがして、遅読家向けの本なのに内容が薄く長いというのはどうなんだ。
遅読の人が読むんだからもっとページ数少なくするべきでは。わざと冗長に書くことで読み飛ばすことを実践させるという高度な内容になっているのかもしれない、などと思いながら読んでいた。
本を読んだ後に「もっとも素晴らしいと思った引用を1つだけ選ぶようにしよう」とあったので、1つだけ引用する。
「なにか」が頭の片隅に残っているのだとすれば、少なくともその部分が自分にとって必要だということ。
その本から得られる価値の全てはまさにそこにあり、1冊を読み通したことの意味は、その一節に出会えたことにある
以下雑なまとめ。
プログラムはなぜ動くのか 第2版 知っておきたいプログラムの基礎知識
プログラムを書き始めて5年ほど経つが、今までずっと「何かアプリケーションを作る」という目的のためだけにソフトウェアを作ってきて、それゆえに低レイヤで何が起きているのか全然知らなかった。
プログラムを書くのにコンパイラが何をしているのかわからんのもよくないので、そこらへんを知りたくて読み始めた。
CPU から2進数、メモリ、コンパイラ、OS、アセンブラと今まで避けてきたことが色々書いてあった。
特にコンパイラとアセンブラの章がよかった。
コンパイラは色々ゴニョゴニョっとライブラリ入れたりスタティックライブラリ使ったりとかしてやっと exe ファイルができるらしい。
アセンブリ言語も mov とかでチョチョっと書ける、逆アセンブルというのはマシン語をアセンブリ言語に逆変換することだったのか、それすら知らなかった。
2進数とかってどうなんだろうか、どの程度まで理解していた方が良いのだろうか。あの 1001010101 みたいな数字が苦手で、 2進数を10進数に計算するのもろくにできない。
でもそれで困ったことがないと感じてて、それは私のレベルが低いから困ったことがないだけで他の人は2進数の理解によりメリットを感じているのだろうか。
本の内容としてはためになったけど、この本を読む前とあとで自分の書くコードは変わらないのかな、とも思う。
コンパイラを理解しているとデバッグがしやすいとか書いてあったけど、果たして iOS の Swift などでそれが役に立つことがあるのだろうか…。
自分の理解度が低いのか、時代に即していないのか、果たして。
とはいえ、ためになるいい本でした、終わり。
以下 wikihub 日報 のまとめ。
読み始めた。いつだかに買ったけど積んでたやつ。 ソフトウェアは書けるけどなぜ動くかわかっていないのでためになる気がする。 1章読んだけど全然わからんかった、パソコンは難しい。
備忘録として書いてたらめっちゃ長くなった。
2進数めっちゃ苦手だ。というか知らなくてもプログラム書けないですか?
計算とかだいたい Math.floor とかしちゃうから気にならないくないですか?
メモリに関しての内容。
C言語も書いたことないしポインタとか概念としてしか理解してない。
ためになる!
メモリとディスク(HDDとかフロッピーとか)について。
zip とかの仕組みが書いてあって面白い。
戦うプログラマーでいろんな環境で動くように作るみたいな話をしていたやつだった。
コンパイラとかのはなし。
知らないことばっかりだ。
コンパイラはこんな感じの処理になるっぽい。
ソースファイル
-> .obj + タートアップ + スタティックリンクライブラリ + インポートライブラリ
-> スタティックリンク + ダイナミックリンクライブラリ
-> exe
読み終わった。
この本で一番ためになる章だったと思う。
コードがコンパイルされ、それがどうコンピュータに読まれるかみたいなのを順を追って解説してくれる。
プログラムに人間の傾向とかを学ばせるみたいな話。
ディープラーニングみたいに深い話ではなく、人間がグーを出した後はパーを出しやすいとかを覚えるとかの話。
個人でアプリを開発するときによく思うのが「とりあえずまずリリースしてみる」というのが大事だと思っていた。
MVP とかいったりするし、そこらへんちゃんと理解したいという思いで読み始めた。
実際に読んで見ると「とりあえずまずリリースしてみる」というのは正しくなくて、「検証可能な仮説が正しいのか検証するための最速の一手を打つ」みたいなのが大事。
最速の一手というのはスケールしない方法という意味で、例えば洗濯をするサービスを作ろうと思ったとき「本当にそのサービスは必要なのか?」を検証するために、街中の人に1000円で洗濯するけどどう?って話して実際に CEO が洗濯する、というのを通して開発する意味があるのか検証しよう、という感じである。
昨今のサービスは、企画があってすぐに開発に移るけどそれはよくなくて、本当にその企画が正しいのか?というのを理解してからやったほうが良さそう。 そういう意味での Minimum Viable Product を作っていこう、というのが印象に残った。
検証するときにはちゃんとそこから学習して、次は良い結果になるように企画を変えるのはもちろん次の検証はもっと早く実施できるようにしよう、とかもよかった。
以下 Twitter に投げた感想。
“これが、リーン・スタートアップ(Lean Starup)と呼ばれる手法である。” めっちゃかっこいい…
— スターホシ (@star__hoshi) 2016年10月4日
スタートアップとは組織の構築であり、マネジメントは避けて通れない。スタートアップはマネジメントと真逆と思われがちだが、マネジメントは避けて通れないし、自由にやらせると逆に混乱を招く
— スターホシ (@star__hoshi) 2016年10月4日
リーンスタートアップの目標はできるだけ早く顧客が欲しがるものを作ること、突き止めることであり、「検証による学び」を通して画期的な新機能を開発する方法である
— スターホシ (@star__hoshi) 2016年10月4日
とてつもなく不確実な状態で新しい製品や事業を生み出そうとする者は、全員がアントレプレナー=企業家=スタートアップなのだ
— スターホシ (@star__hoshi) 2016年10月4日
いい / “スタートアップのMVPを素ラーメンに例えてみる。|Shoko|note” https://t.co/bujMzmZyND
— スターホシ (@star__hoshi) 2016年10月5日
"リーンな考え方における価値とは顧客にとってのメリットを提供するものを指し、それ以外は全て無駄と考える"
— スターホシ (@star__hoshi) 2016年10月5日
リーン関係なくね?
— スターホシ (@star__hoshi) 2016年10月5日
「検証による学び」とは、顧客の望みを学ぶためにどうしても必要な努力を指す
— スターホシ (@star__hoshi) 2016年10月5日
リーンスタートアップよんでるが、小さく出して育てていくというのではなく、仮設を検証する必要があり、どう検証していくか考えたときに小さく出すことで無駄が少ないということであって、まずリリースしようやっていうのは間違ってんな
— スターホシ (@star__hoshi) 2016年10月12日
小さくリリースして顧客の反応見ながら機能追加していけば良い、って思ってたけどそれは正しくなくて、まず我々の仮説は正しいのかというのを検証できる最低限の機能を作り、ユーザもしくは被験者に使ってもらい検証するのが良いという感じか
— スターホシ (@star__hoshi) 2016年10月12日
お前らのアイデアが大企業に漏れても、大企業は他に素晴らしいアイデアをたくさん持っているのでお前らのアイデアをパクる暇はない、むしろパクられたところで勝ち抜けるだけの力がないチームは、サービスがヒットしたとしてもあと追いに潰されるだけ
— スターホシ (@star__hoshi) 2016年10月13日
ユーザが本当に求めているものを検証したいが、ひどいサービスをリリースしてしまい評価に傷をつけたくないと言うならば、名前を変えて検証をして、しれっと本サービスをリリースすればよい
— スターホシ (@star__hoshi) 2016年10月13日
リーンスタートアツプやっと読み終わった、MVP作って仮説と検証を高速に回して改善してゆけ、ピポットも必要だけど全てを捨てるんじゃなくて今までの学びを生かして戦略やら変えるが今まで学んだことを生かしてまた検証を始めろ、とにかく仮説と検証という感じだった
— スターホシ (@star__hoshi) 2017年2月26日
大事なことに集中する―――気が散るものだらけの世界で生産性を最大化する科学的方法
rebuild.fm で本書の話しが出てて、最近集中できないことが多いので読んでみるか〜というノリで読み始めた。
言っていることはわかるのだが、ちょっと独善的すぎないか?と思ってしまう。
メールを返すのは1日1回だけで良い、あいつはメールを返すのが遅い人間と思わせたら勝ち みたいなの書いてあって、それはチームワークみたいな話じゃなくて独りよがりすぎないかなあとか思った。
オンラインの誘惑に勝てとか SNS は本当にお前の人生に必要か?という話はめっちゃ身にしみる。
沁みるのだが Twitter やめられねえ… って感じで己の意志の弱さに負けてしまう。
というかそんな Deep Work に命かけるとか人生何のためにいきてるんや!って思ってしまう。しかし Twitter やっている間に Deep Work している人がいると思うと自分はその人に勝てないとも思う。
とりあえず本を読んでから意識的に Twitter はしないようにしている。
就業時間を終えたら会社の Slack も見ていない、今のところ支障はないし無意識に iPhone で Slack 見るみたいなことはなくなって精神的にも良い。
毎朝やること書き出してタイムスケジュール決めて、その通りのスケジュールには行かないけど自分がどの仕事に集中するのか意識すべし、っていうのは良さそう(やれてないけど…)。
Deep Work 実践できたらめっちゃ強いけど自分はそこまで強い意志が持てずつらい、というのが正直な感想です。
以下 wikihub 日報 のまとめ。
読み始めた。まだ40%くらい。
これからは貧富の差が拡大していくから、富の側の人間になろうぜ!!!って導入でウケた。
毎日3~4時間は深い集中で仕事するべしってあって、めっちゃ同意できる。
SNS がどうとかって話が rebuildfm で言われてたけど、それより最近だと Slack が一番厄介だと思う。
仕事だと Slack でカジュアルにメンションくるけどあれ完全にシャローワークなんだよな。
ディープワーク/シャローワークらへんで言いたいことたくさんあるからブログ書こう。
とりあえず明日からポモドーロやってみよう。
50% くらいまで読んだ。
外界と断絶して集中するのがいいけどそうも言ってられないからフロー状態に入れる環境作ろうなみたいな話してる。
オープンオフィスは最悪とのこと。
60% くらいまで読んだ。
読み終わった。
言っていることはわかるし Deep Work の 必要性も感じているが、著者が人生 Deep Work って感じてついていけなさを感じる。
意識が高すぎる。
あと自分が Deep Work するために他者を拒絶する感じがあって、
例えばメールは5分以内に返すのが美徳とされるこの世界においてメールは1日1回しかチェックしません、
というのは働きにくい人間やな〜ってなりそう。
本書的にはそういう人間と思わせれば勝ちってあるけど、うーむ。
今まで Ruby, Java などオブジェクト指向言語に触れてきたけどオブジェクト指向っていうのが結局よくわかっていない。
クラスとかカプセル化とか継承とかの概念はわかるし使えもするけど、自分の知識は薄っぺらいというか真髄を理解していない気がしているので、オブジェクト指向を完全理解したいというモチベーションを持って読んだ。
しかし、この本ではオブジェクト指向は「クラスは処理を隠して、継承とポリモーフィズムは処理をまとめるだけだよ」みたいに書かれてて、それは本を読む前から理解してるし俺が知りたいのはそれじゃないんや〜って感じだった。
後半は要件定義とか関数型言語の話になって、何の本を読んでいるんだ?という気持ちになってしまった。
しかし、オブジェクト指向が生まれる前の話が書いてあって、昔は全てグローバル変数でサブルーチンがあるだけだったらしい。
なので、それと比較するとクラスで隠蔽できて、継承とかで処理を共通化できるのは素晴らしいことだったんだろうなと思う。
そこらへんの歴史的背景が知れたのはよかった。
自分が知りたいのは多分この本ではなくて、 オブジェクト指向のこころ (SOFTWARE PATTERNS SERIES) の方なのかなと思った。
以下 wikihub 日報 のまとめ。
読み始めた。20% くらいまできた。
恥ずかしながらオブジェクト指向をちゃんと理解しておらず、概念はわかるがちゃんと使えていないという状態なのでためになりそう。
オブジェクト指向をちゃんと理解できていないの、めっちゃコンプレックスなので完全理解したい…。
なんか読まないほうがいい気がしてきた
書評があまり良くないけど読み進めてる。45%くらいまできた。
「書評が良くない」という情報を一度得てしまうと、内容に対し懐疑的になってしまうの良くない。
↑ の理解でいいならそもそもオブジェクト指向を理解していたということになるのだが、本質はそこじゃないと思うんだよなあ。
とりあえずもうちょい読み進めよう。
60% くらいまできた。
知ってる内容ばっかで、おれが知りたいのはそういう話じゃないんや〜ってなってる。
80% くらいまできた。
要件定義とかウオーターフォールとかアジャイルの話とかになってて、おれが求めてた書籍じゃなかった…。
とりあえずもうちょいなので読み切ろう。
なんか最後の方は関数型言語めっちゃいいぞ!って話になってハァ〜って感じだった。
オブジェクト指向の表面だけ舐める感じで微妙な本でした。
チームが機能するとはどういうことか ― 「学習力」と「実行力」を高める実践アプローチ
単純な業務だったら上司が圧倒的パワーバランスで部下を管理してサボらないように効率化を測れば良いが、複雑な業務であったりイノベーティブな業務にはチーミングが必要。
チーミングのためにはリーダーシップが不可欠であり、心理的安全を高め意見を出しやすくすること、価値観の違いなどの境界を超えること、失敗を咎めずむしろ良いこととするなどし、学習しながら実行する組織を作ろうみたいな内容だった。
前職は完全に心理的安全がなく、失敗はそこまで咎められなかったが許容されている感じでもなかった。
現職はそもそもリーダーがおらんし、自分はチームで働いている訳でもないので寂しい気持ちがある。
本を読んだ後毎回思うのが、「ためになるいい本だった、おわり」という小学生並みの感想しか出てこず、他の人の感想文みてるとすげ〜って思う。
まともな人間になりたい。
以下、 wikihub 日報 でちまちま書いてたまとめと感想。
20%まで来た。やはり内容が難しい、というかすっと頭に入ってこないので読むのに時間がかかっている。
26%まで来た。相変わらず内容が濃く文章が長く理解しにくい… 俺の脳内メモリが足りないだけともいう。
35%くらいまできた。ゆっくりだけど毎日少しずつ読んでる。
周りの人を信頼し、信頼していることを伝え、目標を明確にし、労働でなく意義のある仕事なんだと認識してもらえるように頑張れという感じっぽい。
競合他社に負けないとかの目標で働くのはメンバーが学習や思考をしないのでよくないとのことだった。
友達の友達の会社は完全にアンチパターンにはまっているな〜と思いながら読んでいた :innocent:
48%まできた。
心理的安全について述べられてて、友達の友達の会社はあまり心理的安全を感じないので、まあそういうことなのかなと思って読んでた。
60% まで来た。ひたすら失敗を肯定しろという話がされている。
70% まで来た。
リーダーシップについて語られている、とりわけ境界という他者との違いを受け入れチームとして働く為には〜という話がされている。
80%まで来た。
学習しろみたいな話がひたすらされてた。あまり覚えていない。
読了。
まとめ
Karabiner 使えない対策: Hammerspoon で macOS の修飾キーつきホットキーのキーリマップを実現する - Qiita
local function pressFn(mods, key) if key == nil then key = mods mods = {} end return function() hs.eventtap.keyStroke(mods, key, 1000) end end local function remap(mods, key, pressFn) hs.hotkey.bind(mods, key, pressFn, nil, pressFn) end remap({'alt'}, 'h', pressFn('left')) remap({'alt'}, 'j', pressFn('down')) remap({'alt'}, 'k', pressFn('up')) remap({'alt'}, 'l', pressFn('right'))
let name = Notification.Name("notification") NotificationCenter.default.post(name: name, object: nil, userInfo: ["key": "value"])
disposeBag があるので購読やめるとかしないでよい。
NotificationCenter.default.rx.notification(name, object: nil) .subscribe(onNext: { notification in log?.debug(notification) }) .addDisposableTo(disposeBag)
カバレッジについて話したが、カバレッジが高けりゃいいわけじゃなくて、計算ロジックとかは絶対に書いた方がいいけどそうではないところは書くメリット小さいかなと思っている。
とはいえテストがないと影響範囲読めないし、「俺たちが書くコードは完璧だから絶対にバグが起きないぜ😎」という自信がある人以外はテスト書いた方がいいんじゃないかと思っている。
今日の勉強会では「そもそも静的解析で間違いを発見するべし」みたいな話が出ていて、素晴らしいと思った。
そもそもバグを生み出さない仕組みがあればテストいらんよねという話である。
司会の人とかだいぶ緩い空気出してて、 LT 以降は酒飲みながら、懇親会はシースーが出てくる感じでゆる〜くて良かった。
また次回も参加したい 😊
自分にとってはほとんど初 LT みたいなものだったので、だいぶ緊張した。
本番で頭真っ白になったらどうしようとかめっちゃ不安で、5分のライトニングトークなのに多分20回くらい練習した。
大して面白い発表はではなかったけど、まあ失敗はしなかったので良かったと思う。
他の勉強会にも出て行きたい。