この一ヶ月ほど、軽い頭痛と吐き気と目眩みたいなのに襲われる事が多い。
夏バテか脱水症状かなにかかと思ってたんだけど、コーヒーを飲んだ後に体調を崩すことが多いのに気がついて、会社のslackでそのことを呟いたところ「コーヒーアレルギーじゃないですか？」と言われた。
コーヒーアレルギー自体知らなくて、最初は冗談かと思って聞いていたんだけどどうやら本当にあるらしい。 遅延型(数時間〜数日で症状が現れる)というところも合致してて(夕方4時くらいに飲んでるとちょうど帰宅時間くらいに目眩とか吐き気がくる)、コーヒー原因説が濃厚になってきた・・・
昔からコーヒー飲み過ぎるとこういう症状が出ることは自覚してたんだけど、最近は一杯くらいでもこういう症状が出てるので何か体の閾値を超えてしまったのかもしれない。 (もしくはアイスコーヒーなのでガブガブ行けすぎてしまう・・・というのはあるかもしれない)
しばらくコーヒーは控えよう・・・
って奥さんに話したら、「病院に行きなさい」と言われました。 はい。
年始にはこんなことを書いていた suzan2go.hatenablog.com
引き続き、新規サービスの立ち上げに関わっていた。正直結構しんどかったけど、一緒に仕事をしたエンジニアはみんな尊敬できる人たちだったし、とても良い経験になった。スピードも出しつつ、品質も落とさないよい開発が出来ていた気がする。 結果が芳しくなかったのはとても悔しい。
久しぶりに会社の創業時からある年季の入ったサービスに戻ってきた。久しぶりに触るコードはかなりレガシーに感じたが、入社時に見たときは追えなかったロジックが追えるようになっていたり、「ここはこうするべきでは？」みたいな思考が出来ていたので相当成長を感じた。 決済回りのコードを変更していて結構緊張感があったけど、致命的なバグは起こさずにそこそこ大きな機能を足せたのはよかった。
自画自賛になるけど、約1年半以上ぶりにサービスに携わってソースを読んでいる自分がチームの中では一番コードの流れを理解できている感があって、自分はコードを追う力は結構強いのかなって思った。
これは割と出来てる。3月くらいからは少しずつイベントにもいっていたし、いくつかイベントにも登壇できた。 ただどちらもRailsではない。
speakerdeck.com speakerdeck.com
http://www.amazon.co.jp/exec/obidos/ASIN/4873116384/hatena-blog-22/
刺激を受けて基礎的なところを改めて勉強し始めたりした。
いまこれを読んでいる。
進捗だめです
完全にソフトスキルズの影響。ちゃんとアウトプットしていこうと思うようになった。
4月以降、これは家庭の事情的なところも大きいんだけど、奥さんにメニエール病の症状が出てかなりつらそうだったので、できるだけ家事・子育ての負担がかからないようにしてた。 3月くらいまではかなり祭りな感じのプロジェクトにいたのでなかなか難しかったんだけど、4月以降は意識的に早く帰るようにした。 子育てが厳しいほど奥さんに目眩の症状が出ちゃうこともあったので、フレックスを利用して16:00に帰宅したり、午前中リモートのち午後休みにして家族のサポートに回った日も結構ある。柔軟な勤務体系がとれるとこういうときに有難い。
一年前に挫折したんだけど再入門。他の言語を学ぶことで自分の幅が広がるなーという感想です。 suzan2go.hatenablog.com
新卒の子のメンターをやっていた。新卒といっても半年以上アルバイトで来ている子だったので、一から教えるという感じでもなかった。 毎週1on1をやって一定彼のためになる時間を提供出来たたという感覚はあるものの、後半ちょっとマンネリ化した感じは否めない。
4月下旬から毎日コード書いている
ただし結構privateなものもあったりするので、厳密にいうとやれてるとは言えないかもしれない・・・
はい
腰を据えて本を読み、手を動かしていきたい
こっそり react-native で家庭内日記アプリを作っている。APIはGolangで書いている。
まだ expo 上で自分と奥さんにしか配信しかしてないので、ちゃんとApp Store とかに出していきたい。
最近、某スタートアップの人たちとお話する機会があって、自分がミドルウェアに関してすごく表面的な知識しか持っていないことに気付かされてしまった。
自分は幾つかのサービスの立ち上げ経験もあるしRailsやJavaScriptはかなり書いて来たほうだと思うし、テーブル設計・モデル設計もそれなりにやってきたつもりだ。
でも残念なことに？、どちらもめちゃくちゃアクセスがあるとか、大量のデータを使うとかそういう感じではなかったので、AWSやHerokuなどのマネージドなインフラを普通に使って困ることもなくここまで来てしまった。 要は、Railsの裏側で動いているミドルウェアについて表面的な知識しかもっていなくても何とかなってしまっていた。
ちょっと危機感を覚えてまずはちゃんとMySQLについて勉強し直そうと思い、高トラフィックなサービスの運用経験がある同僚に、どんな本を読んで勉強したかなどを教えてもらった。
いくつか既に持っていて、ちょっと読んだだけの本もあったので改めてちゃんと読もうと思う。 これとか。
この話をしたときに、意外だったのはその同僚から「隣の芝じゃない？」と言われたこと。 要はミドルウェアはマネージドなところにおまかせでたいてい何とかなってしまうようになってきてるんだから、それはそこに任せてアプリケーション開発のスキルをためた方が良いんじゃないか、という意見だった。(その同僚は自分の持っているミドルウェアの知識なんてもう不要になってきている気がするとも言っていた)
確かにそういう面もあるのかもしれないけど、自分はそういった裏側をちゃんと理解しているかどうかが、何というかその人の地力になると最近は感じている。そういうスキルを持っている人は、例え言語や使うフレームワークが変わっても強いイメージが実感としてもある。 物事をパターン認識(こういうときはこう)でしか理解していないのか、裏側の仕組みから導出できているかの違いなのかなと思うんだけどどうなんだろうな。
というわけでがんばっていきます。
最近急に意識が高まって本を読みまくっている。
この本は、色んな人が既に感想やまとめを書いていらっしゃるので個人的によかったところまとめる。
チームの状況に応じてリーダーがとるべき振る舞いは違うよねという話。本書ではチームの状態は以下のように説明されている。
これからの時代はサーバント型のリーダーだ！みたいなことをよく聞くわけだけど、当然それはチームの状態によって異なるよねという話。サバイバルフェーズ(チームに余裕がない状態)では、指揮統制型でリーダーがチームの取るべき方向を示し引っ張っていくことが大切だとのこと。
また例えばチームが学習フェーズであっても、過ちを正すのに沢山の時間がかかる場合には指揮統制型で望むべきだともあった(例えば、「Gitととかよくわからないし、ファイルサーバで管理しましょう！」みたいなことをチームが言い出したとき、バージョン管理されてないがゆえのデータ削除なんかの間違いが起きてからリカバリするのはしんどいよね)。
こういうリーダーシップ論って極端な話が多い気がするんだけど、現実に即して振る舞いを変えるべきだということが書いてあってとても納得した。
これは 「XXを△△△までにやります」 ということをチームのメンバーにコミットしてもらうようにする、と言うものだ。これは他の方のブログでは結構炎上していたけど、意図がちゃんと伝わってないのではと思う。
このコミットメント言語には前提がある
コミットメントをするのは、メンバーに期日や約束を絶対に守らせるようにする！！といった精神論的な話ではなく、コミットメントをすることで、問題を可視化する ためだ。
「今週中にやろうと思ってるんですけど難しいかもしれませんねー」みたいなタスクがずっと宙ぶらりんになってしまった経験はないだろうか。今思うと、こういったタスクは振り返りでもあまり進捗が悪かった原因が話し合われない気がする。
コミットメントしようとしたときに、「XXまでに実施する」といった断定的なことが言いにくい場合には以下のような課題が見える。
コミットメント言語は上記のような課題を早めにあぶり出すためのものなのだと思う。
この本には途中から日本人開発者のエッセイが収録されているんだけど、なかでも伊藤直也さんの話がよかった。チームを良くすることだけに集中して技術や事業の問題に向きあっていないと、本当に組織が困った時(事業が伸びない、プロダクトが使われない、技術的に困難な課題に躓いてしまった)に役に立たないリーダーになってしまうというようなことが書いてあった。
リーダーというとどうしても組織づくりみたいなところに目がいってしまうけど、文字通りチームを技術的に・プロダクト的に「リード」できる人間であり続ける必要があるんだなと再確認した(大変だな…）
前に友人のエンジニアと飲んでたときに、「今後のキャリアを考えたときに、マネージメントか技術かどっちに進んだらいいんだろうなー」という話をしたことある。そのときに「suzan2goさんは、マネージメントっていうよりはリーダーシップとかプロジェクトを引っ張ってくとかそっちな気がするなー」ということを言われた。
当時はあまりピンと来てなかったんだけど、この本を読んでいくらかそれがどういうことなのかクリアになった気がする。相変わらず「マネージメントをする」と言われるとちょっと身構えてしまうけど、「リーダーをやる」ということにはこの本を読んで少し抵抗がなくなった感じがする(単純に言い方だけの話だと思うｗ)。
リーン顧客開発 ―「売れないリスク」を極小化する技術 (THE LEAN SERIES)
積んでた本をちゃんと読んだ。 前回読んだときは、想像していた中身とちょっと違っていて、最初の数十ページ読んで積んでしまっていた。しかし、改めて読み直してみると現在会社でやっているユーザーインタビューに対してかなり知見を与えてくれそうな本だったので、一気に読んだ。
「顧客開発」というタイトルから、サービスのファンを如何につくるかみたいなマーケティング的な話を想像してしまっていたんだけど、中身はそういう感じではない(なので前回読んだときは途中でやめてしまった)。顧客と対話することで、どんな課題やニーズがあるのか、そもそもその顧客は作ろうとしているサービスのユーザーになってくれるのか、みたいなものを如何に見極めるかという話だった。
この本の殆どの部分は「ユーザーインタビューをどんな風に行ったらいいか」ということに割かれている。ユーザーインタビューで聞くべき質問から、インタビュー対象の見つけ方、どれくらいインタビューを重ねればいいかなど結構具体的だ、本のタイトルから自分はもっと心構えがどうといった抽象的な話が多いのかと思っていたので結構意外だった。
「ユーザーの言うことをそのまま実装してもダメ。本当の課題が何か考えよう」みたいな話はよくあるし自分も思う所だけど、ユーザーとの対話を通して如何に課題を引き出すか・見つけるか、みたいな視点をあまり意識したことがなかったので新鮮だった。
自分はユーザーインタビューで得られた意見に対して「尤もな意見だけど少数派なのではないか」「不満は感じてないと言っているけど、システムに慣れてしまっただけなのではないか」みたいなことをよく思っていたし、どう判断すればいいのかよく分からないなと思っていたんだけれど、そこについてもこの本は色々書いてくれている。
結局は漫然とユーザーインタビューをしていても駄目で、「自分たちの持っている仮説を検証する」という心構えでインタビューの対象者選びをして繰り返しインタビューをしていかないと、得られるものも少なくなってしまうんだなと思った(これはどういう意図のユーザーインタビューだったかにも依るとは思うけど…)。
MVPについてはこの本のメインの部分ではないだろうけど、様々なパターンについて具体例を交えて書かれていて結構参考になる。「最終的な製品をどうするか決めて、MVPとして出すためにカットできる機能を検討する」は「よく耳にする起業家の間違い」とはっきり書いてあってｱｯ…ってなった。
ユーザーインタビューにしてもMVPにしても、「どんな仮説を検証したいのか」ということがはっきりしていないと、それ自体が目的化してしまいそうなので気をつけたいと思った。リーンに開発していくぞ。
【Go言語LT大会！ 「最近、Go言語始めました」の会】でLTしてきました go-beginners.connpass.com
大体内容は前にブログで書いたような話で、 これからGolangを触る人向けに自分はこういうところで挫折した / 再挑戦してうまくいったよって話をした。
要約すると以下のような感じ
現場からは以上です。
Railsのプロジェクトやってると、app/models には ActiveRecord だけ、それ以外のオブジェクトは app/services とか app/forms層みたいなところに定義しないといけないと思っている人がそれなりに多い気がする。
個人的には app/models 配下に責務を分けたActiveRecordでないクラスを作っていくのはむしろ積極的にやるべきだと思っている。むしろそうしないとXX層みたいなものを導入したとしても、本来モデルの振る舞いとして表現されるべきものが手続き的に書かれてしまったり、新しく導入したXX層の処理がファットになっていってしまったりするのではなかろうか。(ActiveRecord のクラスと、そうじゃないプレーンなRubyクラスが app/models に交じるのが気持ち悪いという意見はまあ理解できるけど)
たとえば以下のようなクラスがあったとする。
class User < ApplicationRecord def nanka_fukuzatu_na_shori if user.hoge? private_na_method_a private_na_method_c else private_na_method_b end end private def private_na_method_a # なんかの処理 end def private_na_method_b # なんかの処理 end def private_na_method_c # なんかの処理 end end
見るとnanka_fukuzatu_na_shori と private_na_method_a~c は明らかに関連をもつひとまとまりの処理なので、こいつらを実行する実態はUserクラスではないところにあっても良さそうな気がする。
これを User::NankaFukuzatsuNaShoriHandler を作って、そちらに責務を分けてみる
# app/models/user/nanka_fukuzatu_na_shori.rb class User:: NankaFukuzatsuNaShoriHandler attr_reader :user def initialize(user:) @user = user end def perform if user.hoge? private_na_method_a private_na_method_c else private_na_method_b end end private def private_na_method_a # なんかの処理 end def private_na_method_b # なんかの処理 end def private_na_method_c # なんかの処理 end end
( nanka_fukuzatu_na_shori とかいう適当な名前で書き始めてしまったので User::NanakaFukuzatuNaShoriHandler#perform みたいにしちゃったけど、Handler、 Perform みたいな抽象的な名前は避けたほうが良さそう)
Userクラスはこんな感じになる。
class User < ApplicationRecord def nanka_fukuzatu_na_shori nanka_fukuzatu_na_shori_handler.perform end private def nanka_fukuzatu_na_shori_handler @nanka_fukuzatsu_na_shori_handler ||= User::NankaFukuzatsuNaShoriHandler.new(user: user) end end
基本的にはこんな感じで責務を分割していって、あるモデルの振る舞いとして定義するのが微妙なものだけそれこそXXX層みたいなの作ってやるのがいいんじゃないかと最近は思うんだけど、各社どうなっているんだろう。
みたいな意見はありそうかなと思っています。