時間を区切って設計を打ち切るのはおすすめできない - hitode909の日記
最初にマイルストーンを切って、この週で設計、この週で実装、みたいなことをやるのはおすすめできない。 設計に使える時間を最初に決めた時間までしか使わないということは、どうすればいいか、考えきれてなくても作り始めているということ。 コードは書けていくので、進んでいるようにも見えるけど、問題を先送りしているだけなので、じっくり設計や作戦を詰めていれば気付ける問題に、あとのほうで直面することになる。 この問題を回避するためにはこのように作るべきであった、ということにあとで気づくと手戻りが大きくなり、こんなことをするくらいなら最初に決めておけばよかった、となることが多いと思う。 家を建てることをイメージすると、設計フェーズはここで打ち切って、手を出せるところから始めよう、といきなり柱を建てることをイメージしてほしい。 先のことを見据えると、4本の柱は長方形になっているべきという制約があるけど、そのこ
チーム開発で活躍するために、自分の庭を作れると良い - hitode909の日記
チームでどうやって活躍するか、まだイメージがついてない、振られた仕事をやっているだけで、仕事をしている間は忙しいけど、確認待ちになるとすぐ暇になってしまう、というメンバーの悩みを聞いていた。 巨大なチーム、巨大なプロダクトだと、すぐに全容を把握するのは難しい。その中で、この範囲なら触れています、任せてください、という庭を作るとよいのでは、という話をした。 思いつきで話したわりには意外といいことを言ってるなと思ったので掘り下げて書いてみます。 庭とは 現代では、庭のある家に住んでる人は少ないかもしれない。うちは実家が田舎だったので庭があって、ボールを蹴って回ったり、石をめくってアリを観察したり、隣の家の庭との境界もゆるくて、冒険と言って隣の家の庭で遊んだりしていた。 大人になってからの庭というと、池袋で遊んでた人が「池袋は俺の庭」と言ったり、JR新宿駅の東口を出たら椎名林檎の庭があることが知
コードレビューのクオリティとスピード，とくにスピードについて，それとコミュニケーションについて - hitode909の日記
ソフトウェアを作るときにクオリティとスピードのバランスをとりたくて，どちらかに偏ってはいけなく，どちらもキープしないといけない．すごく雑に*1とらえると， クオリティ→正しく動き，不具合がないほうがよい スピード→(計算時間ではなく)早く作れるほうがよい ということになる． コードレビューでは，不具合を見つけて直してもらったり，動きはしてもコードの可読性に問題があって直してもらったりと，クオリティに目を向けられがちだと思う． ところで，コードレビューとスピードの関わりについて考えてみる．スピードのためにできることはいくつかあり， 早く読み始める→他のことやってても手を止めて読み始めたり，1日のうち決まった時間にレビュータイムを設けたり 速く読む→これはコツとかある*2けど精読しないといけないので難しい 不具合を見逃さない→リリース後とか，リリース直前に正しく動かないことが分かったら大きな手
開発中の機能を小分けにして本番環境にどんどん出すためには - hitode909の日記
ふだんの開発では，稼働中のシステムに影響を与えないように開発中の新機能や新システムを共存させながらちょっとずつデプロイして進めている．どんな事を考えてやっているか記しておきます． フィーチャートグルを使う すべてのコードが本番環境に入っているけど無効化されている状態で開発を進める ブランチをたくさん作るのに対する考え方で，フラグを有効にすると開発中の機能を使える スタッフなら有効にしたり，フィーチャーのオンオフを選べる画面を作ってたこともある フィーチャーブランチを利用した開発はチームを継続的インテグレーションから遠ざける – ゆびてく FeatureToggle 完成したらフィーチャートグルに関係なく全員に有効状態にして完成 フロントエンドの施策で，実際のデータやインフラ構成でどれくらいスピードが出るかわからないときに，ひとまずフラグをオンにすると動く形でデプロイしたりとか レイヤの下の
みんなでアジャイル - hitode909の日記
チームの新卒氏が読んでたので一緒に読んでみた。 アジャイルのプロセス自体がアジャイルで、なんのためにアジャイルをやるのか？とか、地に足のついた理解をしないと活用できないのだな、と思った。 こうするのがアジャイル！だからやりましょう！では、なんで？となったり、そうすればアジャイルで、成功が約束されているのね、では着いていきます、ということでは、うまくいかない。 何をやりたくて、だからこういう開発プロセスをやっていて、やってみたらこういう状況になったので、こういうことのためにここを変えよう、という議論ができるようになって、ようやく採用できる手法だと思う。 最近、自分たちは、自分たちがアジャイルなのかそうでないのかって話をしがちなのだけど、そのとっかかりがなくて、話が噛み合っていなかった。 この本の後半にはテンプレートが用意されているので、ためしに埋めていって、こういう理解でやってる？という話は
育休を取得してから復帰するまでのまとめ - hitode909の日記
4〜6月まで、育休を取得していた。こまごまとした出来事があったので、育休を取得して復帰するまでのことをまとめておく。 育休について 育児休業は国の制度で、会社の制度ではない。よく、何ヶ月か休むんです、と言うと、いいですね、うちの会社にはそういうのがなくて、と返されたりするけど、国の制度なので、まともな会社なら、ないことはないはず。ないように見えているとしたら、制度としてはあるけど雰囲気的に取りにくいか、本当に違法な状態で制度がない、ということらしい。 もう一つ、あまり知られていないこととしては、育児休暇ではなくて育児休業である、ということ。僕もしばらく知らなくて途中で気づいた。 前提 職業や労働環境が違うとぜんぜん違う話になりそうなので最初に書いておくと、Webアプリケーションエンジニアをしていて、ここ一年ほどは自宅からリモートワークしていた。 採用情報はこちら。全員応募してください。 h
デジタル・ミニマリスト スマホに依存しない生き方 - hitode909の日記
DEEP WORKの本は読んだ人も多いと思う。前作では、気が散る通知を省いて仕事に集中する、という話だったのが、この本では、人生においてもスマホの通知や、タイムラインの無限スクロールに気を取られずに生きる方法について教えてくれる。 昔からテクノロジーとの距離感には苦労していて、中学校3年間はmsnメッセンジャーを見ていたら終わり、高校3年間は匿名掲示板を見ていたら終わった。大学はtwitterを見ていたら4年で出れず5年目に突入した。社会に出たらSlackを四六時中見ている。 スマートフォンはもともとiPodと電話が合体したものだったけど、ユーザーに向けてリコメンドした広告を見せると信じられないくらいに儲かることが発見されて、巨額の富が投入されている。その結果、現代では普通のスマホユーザーは多大な時間をSNSを見て過ごしている。 この本では、そのような依存状態から脱出するため、デジタル機器
未知の道に突入せず、まずは半分知ってるくらいの状態になる - hitode909の日記
Perl製アプリケーションからGraphQLを喋ってみたい、ということがあって昨年末に2週間くらいでプロトタイピングしていた。 CPANにGraphQLというライブラリが公開されていて、社内の利用実績もあるので、これをいきなり使ってみても良かったのだけど、自分はGraphQLについては、耳では知っていて、GitHubのAPIを呼び出したことがある、くらいで、実際に実装したことはなかった。 このような状態で突き進むと、問題に遭遇したときに2パターンの怪しさが出てきて、切り分けていくことになる。未知のものが多すぎて、プロジェクトXの、トンネルを掘るだけで難しいのに現地の言葉はわからない、みたいな回をイメージしてください。 GraphQL自体への理解が間違っているパターン スキーマ、クエリの書き方が悪い、概念を勘違いしている、など PerlでのGraphQLライブラリの使い方が間違っているパター
今週は技術的な選択の仕方について考えることが多かった - hitode909の日記
今週は技術的な選択の仕方について考えることが多かった。 どうやって決めるか、というだけでなくて、どこに決めポイントがあるか、というところの見極めも難しい。 何も決めずに進んでいって、あとで見返すとすごいことになってしまい、ここをもうちょっと考えておけると良かったね、ということもあるし、考えすぎて重厚に作りすぎだったので、あとからシンプルな形に直していく、ということもある。 個人的には、ふだんはこのように考えています、という手順を書いておくと、 実現方法を考えるだけでなくて、他に取れる作戦がないか考えていく よさそうな方針が、他の作戦と比べてこれが一番良い、という確証を得る 確証が得られないときは、考えて決める 昼休みにプールに行って泳いでいると、これだけ考え続けて何も出てこないということはこれで行くしかない!と決められることが多かった というような形でやっていると思う。これでできるのでこれ
リモート飲み会でめちゃくちゃになっている人をまだ見ていない - hitode909の日記
現実世界で飲み会しているとめちゃくちゃになる人がたまにいて、机に突っ伏して寝ていて髪の毛がハイボールでびちゃびちゃになっていたり、歩けなくなって肩を担がれて帰っていったり、頭からゴミ箱をかぶったり、道で寝たり、気づくと指がしびれていたり、うちの夫はそこにいますかってLINEがきたり、奥さんが会社まで迎えに来たり、鯖寿司を投げたり、スマホを床に叩きつけて液晶が割れたりする。そういう人をリモート飲み会ではまだ見ていない。突然寝始める人くらい居てもいいと思うけどそれも見ていない。 また、二日酔いになるまで飲むこともなくなっている。おごってもらえるなら飲んでおくか、と飲み続けたり、コース料理なら料理が出てくるのにあわせて飲み続けたりするけど、家では必ず有料であったり、料理がコース状にどんどん出てくることもなく、きのうはチーズと焼豚をちょっと切ってちびちびつまんでいた。それに加えて常時水を飲むように
あなたがこう感じられているとしたら私はこう感じていますというのを先に話す - hitode909の日記
思惑うずめく、みたいなときに、きっと相手とゴールは同じなので、先に手を明かしてしまうと楽だと思っていて、「私はこう思います」「一方私はこう思っています」みたいになって、話がすれ違ったら、自分がどこまで先読みしてどう考えているか話すと話が早く終わる。 昨年末、実家に帰るかどうか、電話で母と話しているときに、「毎年帰ってるので今年も帰りましょうか」「忙しいでしょうから帰らなくてもいいですよ」みたいな、まあまあ、そこはなんとか、みたいな雰囲気重視の話になって平行線になった。そのとき母からは「こちらとしては来てもらわなくても何も困らないけど、もし来たくてたまらないのだとしたら、それを断るとかわいそうである、家で待ち受けるという立場を考えると、こちらから断っているのは家に帰ってくるなと言うメッセージを発しているようにも見える、そのように感じているとしたら、そのようなメッセージはなくて、ただあなたたち
開発内容の洗い出しを画面一覧から進めるのは適切かどうか、ボトムアップに洗い出した開発項目とマージすべきかどうか - hitode909の日記
プランナが画面一覧をもとに作ってくれた開発項目のリストと、エンジニアがボトムアップに必要そうなことを出していったリストがぜんぜん違う内容になっている、ということがあった。結果的にできるものは同じことが期待されているけど、一つの出来事に対して、言い回しが違うものが2種類ずつ用意されている。 この時点で差異があるのはいいのか、悪いのか、どちらかでいいのか、どちらも必要なのか、一つのリストにマージすべきなのかそうでないのか考えていた。 差異があるのは これはよい。たとえば検索エンジンを作ろうとすると、画面一覧から見ていくと、「検索ワードを入れる欄」「検索ボタン」「検索結果」くらいの構成要素しかないけど、その裏では膨大な量のコンピュータを束ねて計算する必要がある。 逆に、星座占いのページとか作ろうとすると、星座ごとのページを作ったり、射手座のイラストとか用意する必要があるけど、その裏の構成は同じで
計画の科学 - hitode909の日記
三点見積もりでもやってみるか、という話になって、id:onkさんにおすすめされたので読んだ。PERT、Program Evaluation and Review Techniqueについて教えてくれる本。1965年の初版が電子書籍化されていておもしろい。 読んでたら、こんなの大学の授業でやったなってだんだん思い出してきた。 PERTは各タスクの依存関係をグラフにしたもので、見積もり時間を持っているもの。ガントチャートと違って、各タスクの依存関係や、遅れたときに全体に影響がある箇所や、余裕がある工程がどこなのかを可視化できる。 ja.wikipedia.org 以下は読書メモ ネットワークは関係者が集まって描く。お互いの意見を出し合って最高のプランがネットワークとしてまとまるのが良い点 見積もりトータルフロートが0であるパスがクリティカルパス。そのパス以外はフロートがあり、早くやっても仕方な
雑なVSCode拡張を作ろう #kyotoasterisk - hitode909の日記
プレゼンモード 再生 ← / →で移動 fでフルスクリーン escでおわる id:hitode909です．Kyoto.なんか #4 に飛び入りでLTするための資料です． VSCode拡張を作ろう ここ2ヶ月くらい早起きして作っている 友達作りのため様子を紹介 自己紹介 はてなで働いている Emacs→Atom→VSCode 練習 祝日を挿入するコマンド gyazo.com const holidayList = "元日 成人の日 建国記念の日 春分の日 昭和の日 憲法記念日 みどりの日 こどもの日 海の日 山の日 敬老の日 秋分の日 体育の日 文化の日 勤労感謝の日 天皇誕生日 元日 成人の日 建国記念の日 建国記念の日 振替休日 春分の日 昭和の日 昭和の日 振替休日 憲法記念日 みどりの日 こどもの日 海の日 山の日 敬老の日 秋分の日 秋分の日 振替休日 体育の日 文化の日 勤労感謝
社内横断で開発効率を上げる取り組み #pepabohatena - hitode909の日記
プレゼンモード 再生 ← / →で移動 fでフルスクリーン escでおわる こんにちは，id:hitode909です．はてな・ペパボ技術大会 #4 〜DevOps〜 @京都において，「社内横断で開発効率を上げる取り組み」というお題で発表しています．この記事は，その発表資料です． 社内横断で開発効率を上げる取り組み はてな・ペパボ技術大会 #4 〜DevOps〜 @京都 hitode909 自己紹介 hitode909 株式会社はてな アプリケーションエンジニア 好きな本はオブジェクト指向入門とドメイン駆動設計 2009年〜 うごメモチーム 2012年〜 ブログチーム 2017年〜 マンガチーム 2018年〜 CTO室(兼務) アジェンダ CTO室での活動 特定のチームに閉じず，社内横断で開発効率を上げるための試み みなさん 学生の方? 🙌 社会人の方? 🙌 Devの方? 🙌 Opsの
モブプログラミングについて(2) - hitode909の日記
チームのみんなでモブプログラミングやってみたので記録 ブログの記事を参照しつつ，モブプロについて軽く説明してから始めた モブプログラミングについて - hitode909の日記 最初なので，簡単めなタスクをやってみた DBにカラムを足して，アプリケーション側で計算していた値をDBに持たせる 東京と京都でHangoutでつないで会話しながら進めた コードを書く人は手元で見て，その他はHangoutの画面を見る 1台のPCで人が交代するのではなく，各自のPCでコードを書いて，pushしたら交代 1コミットずつpushするたびに交代したので5分か10分ごとに交代した 分担は以下のような感じで，意図せずちょうど一周すると同時に完成して美しかった SQLのスキーマ定義とalter table モデルのテストと実装 リポジトリのテスト(TDDなので) リポジトリの実装 インデックスの追加 SQLのクエ
エディタの左上にリアルタイムに顔を表示する - hitode909の日記
エディタの左上にワイプでリアルタイプにカメラの入力が出てたらバラエティ番組みたいになって便利かと思ってやってみたけどただ意味不明な状態になるだけでとくに役には立たなかった，リモートペアプロするときにこちらの顔を送れるのは便利かもしれない． Atomのコンソールにこれを貼ればワイプ出せるはず． navigator.mediaDevices.getUserMedia({audio: false, video: true}).then((stream) => { const video = document.createElement('video');video.draggable=true;document.body.appendChild(video); video.srcObject=stream; video.style='position: absolute; left: 7vmin
モブプログラミングについて - hitode909の日記
ちょっとやってみよう，って話になったのでちょっと調べた mob programming，モブプロ http://www.mobprogramming.com/ カンファレンスとか開催されている 全員で集まって1つのPCでプログラミングする キーボードに座る人はどんどん交代する Hunter Industriesで採用されている この会社については存在を知らなかった 1日の様子(2011) A day of Mob Programming - YouTube 1日の様子(2016) A day of Mob Programming 2016 - YouTube 規模が大きくなっててオフィスもモブプロに特化していておもしろい 関係性 よくあるペアプロでは，ドライバーとナビゲータではなくドライバーとフォロワーになってしまうことがある 横に座ってる人が考えて，キーボードの前に座ってる人がタイピング
どんなに実装がしょぼくても，テストは合ってるはずなので，将来的にいい方法が見つかったときに，テストはそのままに実装だけ美しく書き直すことができる． ■ - hitode909の日記
どう作ればいいか分からないとき，同僚に相談したりするけど，それでもいい方法がなければ，我々のスキルがしょぼすぎて，しょぼすぎるスキルではそういうものしか作れないのだからあきらめて作ろう，ということになる． それはそれでよくて，どんなに実装がしょぼくても，テストは合ってるはずなので，将来的にいい方法が見つかったときに，テストはそのままに実装だけ美しく書き直すことができる． そんな都合よく行くのか，という話だけど，意外とうまくいっていて，ここいけてないなーと思ってたところは半年もすればどう書けばよかったのか分かってきて，初めからそこにあったかのような美しいモデリングができる． 本番環境でプロトタイピングしてるようなものだけど，半年間プロトタイピングを重ねてついにリリースよりは，なんか動くものを今日リリースできるほうがいいし，最初にしょぼいコードを書いているのは，さぼってるわけではなく，技術力が
一日に判断できる物事の数を増やしたい - hitode909の日記
夕方くらいになると，何も決められなくなってきて，一日に決断できることの数の上限に達していると感じる．物理的には元気いっぱいで，縄跳びとかできるくらいのパワーがあるけど，決断できないことで，仕様を決めたり，コードを書いたりすることが難しくなってくる．決められることの数を増やしたい． 翌日になると復活するので，しばらく寝たら復活するかもしれない 家に帰って翌日また来ると復活するので，意味なく移動してみると復活するかもしれない 昼にプールに行くとシャキッとして戻ってこれるので夕方にプールに行くと復活するかもしれない 会社の裏の銭湯に行くと復活するかもしれない 余計なことを考えるのをやめるため，Slack見るのをやめると体力温存できるかもしれない なんとなく漢方でパワーが出そうなので，3000円くらいの漢方を食べると元気になるかもしれない 別の話題なら決められるのだとしたら，チームを2つ兼務して，
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
