タグ

ブックマーク / blog.sushi.money (10)

  • 承認ではなくて、よさそう、と思って暮らしている - hitode909の日記

    普通に書いたdiffは、関心がさまざまなところに散らばっていたたり、書きかけだったりで、意味のまとまりがないもので、それを整形して、説明を書いたものがPull Requestであり、コードレビューは、そのまとまりごとに、他人から見て理解可能であるという承認する行為、という理解をしていた。 なので、レビューを通すことは、動くことに賭けて、以後、動かなかったら責任を取る、みたいなイメージはあまり持っていなかった。 レビュワーの責任をどこまでと規定するか考えて、責任が大きい順に並べていくと レビューを通した以上、以後は私の責任です、という態度 職人魂を感じる 見たところよさそうに思いました、という態度 通りすがり風情を感じる まったくの無責任なので、工数最小化のために何が来てもapproveする、という態度 やっつけ仕事 かるぱさんのチームでは1になっているのかな(追記)こうなっている、というこ

    承認ではなくて、よさそう、と思って暮らしている - hitode909の日記
  • アウトプットの品質を下げておくと気軽に書けるようになる - hitode909の日記

    12月であるし、アドベントカレンダーが回っていたりして、よくできた興味深いブログの記事を目にすることが多い。 よくできた記事ばかり見ていると、自分もちゃんとしたものを出さなければ、となってしまうことがありそう。しかしちょっと待ってほしい。 ブログ記事、といっても、プロの編集の手が入ったお金のかかった記事、一人で頑張って書いた大作、チョロっと書いて出てきた日記まで様々なものがある。 100文字くらいで終わっているものもあれば10万文字くらい書かれているものもあるので、文量に1000倍の差がある。 映像の世界で1000倍の差を出そうとすると、2時間すなわち7000秒の映画と、スマホで撮った7秒の動画、くらいの差がある。 2時間で観れるすばらしい映画がなにかあるとして、 Amazon.co.jp: フォレスト・ガンプ/一期一会 (字幕版)を観る | Prime Video これの1000分の1の

    アウトプットの品質を下げておくと気軽に書けるようになる - hitode909の日記
  • 時間を区切って設計を打ち切るのはおすすめできない - hitode909の日記

    最初にマイルストーンを切って、この週で設計、この週で実装、みたいなことをやるのはおすすめできない。 設計に使える時間を最初に決めた時間までしか使わないということは、どうすればいいか、考えきれてなくても作り始めているということ。 コードは書けていくので、進んでいるようにも見えるけど、問題を先送りしているだけなので、じっくり設計や作戦を詰めていれば気付ける問題に、あとのほうで直面することになる。 この問題を回避するためにはこのように作るべきであった、ということにあとで気づくと手戻りが大きくなり、こんなことをするくらいなら最初に決めておけばよかった、となることが多いと思う。 家を建てることをイメージすると、設計フェーズはここで打ち切って、手を出せるところから始めよう、といきなり柱を建てることをイメージしてほしい。 先のことを見据えると、4の柱は長方形になっているべきという制約があるけど、そのこ

    時間を区切って設計を打ち切るのはおすすめできない - hitode909の日記
  • 自分を退職に追い込む動きをすると良い - hitode909の日記

    去年,いまのチームに来たときは僕がフロントエンドのリファクタリングを進めたり面倒を見たりしていた.JS得意な友達がバイトに来てくれるようになり,今はその人がBabelを入れたりしてくれている.彼がバイトに来てくれなかったら,いまだになんとなく興味があるので見ますみたいな感じで一人で面倒見ていた気もする. よくある話で,属人性を高めないように自分の知識を展開しましょうという話があるけど,具体的にアクションプランを考えてもどれが一番良いのかわからない.抽象的に考えると,自分の仕事をなくして退職に追い込むような動きをすると良い.周りのレベルが上がったり移譲されたりしてその分野で価値を発揮できなくなってれば自分じゃなくてもできるようになっている 自分でなくても実装できるようになって,作戦の相談に乗ったりとかしていると,次はそこの属人性が上がってきて,自分のバリューを再びなくすには,誰でも計画を立て

    自分を退職に追い込む動きをすると良い - hitode909の日記
  • はてなブログのAMP対応で学ぶウェブサービスのAMP対応 - hitode909の日記

    プレゼンモード 再生 ← / →で移動 fでフルスクリーン escでおわる こんにちは,id:hitode909です.このあと14時から品川のマイクロソフト様のオフィスでおこなわれている,YAP(PはパチモンのP)Cで発表します. この記事では,発表資料を公開いたします.現地の方は今すぐCルームに来てください.そうでないかたは懇親会でお会いしましょう. はてなブログのトピックもあるようです. トピック「YAPC」 #yapc8ojic のツイート はてなブログのAMP対応で学ぶウェブサービスのAMP対応 2016/07/03 YAP(achimon)C::Asia Hachioji 2016 mid in Shinagawa hitode909 自己紹介 id:hitode909 @hitode909 京都から来ました はてなはてなブログを作っている 自己紹介 YAPC 2015でベスト

    はてなブログのAMP対応で学ぶウェブサービスのAMP対応 - hitode909の日記
  • 気が狂った設計 - hitode909の日記

    大きめのこととか,自信のないところを触るときは,コード書く前に,こういう作戦考えてみたけどどうですかって聞いてみたり,こういうことやりたいんだけど一緒に考えませんかって,いっしょに話して設計考えたりするとよいと思う. 一緒に考えたすぐあとに気が狂った設計とか言い出したらおかしいので,未然に変な設計のままコード書いてしまうのを防げる. 特に辛い気持ちになるのが、「気が狂った設計」「クソコード」「(こんな実装は)有り得ない」といった言葉だ。 Pull Requestのレビューが辛くて会社をやめたい 単に言葉が強いのはよくないと思う.我が社にはそんな強い言葉でレビュー書く人はいない. 我が社には,普段から強い言葉を発する人もいなくて,みんな物腰柔らかな変な言葉を話している. 言葉使いや文体は,ずっと過ごしてると同僚から移ったりするので,普段からそういう言葉を話していると,全体の雰囲気も悪くなりそ

    気が狂った設計 - hitode909の日記
    terkel
    terkel 2015/07/03
    “現実という制御不能な問題を対象にした,本質的に複雑な問題を解くためのソフトウェアを日々作っているちっぽけな私達”
  • プレゼンテーション - hitode909の日記

    プレゼン自分ではすべったことないから得意だと思ってるのでいつも気をつけてることをシェアします。これさえ守ればすべらないのだから楽。 目次 目次 最初にめちゃくちゃおもしろい話をする 箇条書きせず一行ずつページを分ける 絵をでかくする 新しいページ作ったらデフォルトのパーツを全部消す 先に言う 意見や疑問を述べる スターウォーズエピソード4を見る 最初にめちゃくちゃおもしろい話をする 聴衆は懇親会のことしか考えてないので、とりあえず最初におもしろい話をして、注意を引きつけるとよい。つかみはこれでオッケーだって言えればよいくらいの面白い話をしましょう。よくある技術ブログとか、技術雑誌だと、こんにちは、最近温泉に行って心身共にリフレッシュしました、ヒトデです、とか書いてあるけど、そんなの読んで喜ぶ人が人と家族と親類以外にこの世にいたらおかしいから、そういうのじゃないとよい。 箇条書きせず一行ず

    プレゼンテーション - hitode909の日記
  • コードレビュー - hitode909の日記

    コードレビュー,慣れるとできるけど,いきなりdiffを渡されて,どうぞ見てくださいと言われてもよくわからないと思う. やりましょうというのはいいけど,ただむやみに読んでもうまくいかない.変更がある程度大きくなるとdiffだけ見てもよくわからないので,いろいろ見ることになる. 僕はいつも以下のようなことを無意識にやってて,うまくいってる気がしてる.GitHubのPull Requestの仕組みを使ってる前提で. Discussionをさらっと眺めてどういう問題を解決したいのか見る Commit Statusを見て,テスト通ってることを確認する Commitsタブで1コミットずつブラウザの新しいタブに開く 全部クリックし終わったら古い順に1コミットずつ読む 気になる点があったらエディタとかにメモしておく.あとで書き直されるかもしれないので,まだコメントしない 全コミット見終わったらFiles

    コードレビュー - hitode909の日記
  • UI変更批判バトルと複数のバージョンのウェブサービスを同時に配信することについて - hitode909の日記

    ウェブサービス,UI変えると,改悪とか,元に戻してとか,そういう意見が出る. サービス提供する側の立場では,新しいUIのほうが使いやすかったり,機能が増えたり,収益が増えたりするので,新しい方を多くの人に提供することに価値がある.使いやすいかとか,儲かるかとかは,リリースまでに調べておく必要があり,リリースの結果使いにくくなったり収益減ったりしたら,失敗ということになる. 一方で,ユーザーの立場からすると,前の方がずっと使ってて愛着があったとか,新しい方を覚えるのは手間とか,確かにという感じはする.また,ウェブサービスは最終的にユーザーの手元のブラウザで表示されて動くので,映画の結末が気に入らないから変えたいといった要望よりは,受け入れやすい.データ構造についての,サーバー側の処理についてのユーザーからの要望というのはあまりなくて,このボタンがどうみたいな,UIの要望が多いと思う. 全部置

    UI変更批判バトルと複数のバージョンのウェブサービスを同時に配信することについて - hitode909の日記
  • 自作オブジェクトのイベントのやりとりにはjQuery.triggerではなくjQuery.triggerHandlerを使うほうがよいと思った - hitode909の日記

    DOMオブジェクトには昔からdispatchEventとか,addEventListenerとかあって,最近だと,node.jsのEventEmitterとか,jQueryのon, triggerを使って自作のオブジェクト間でアプリケーション的に定義されたイベントをやりとりできる. これまで,自作オブジェクトからイベントを発行するのに,jQueryのtriggerを使ってたけど,意図しない挙動をすることがあることが分かって,triggerHandlerを使うように変えた. jQuery.trigger()は,イベントタイプと一致する関数をレシーバが持ってるとき,その関数が呼ばれる. イベントのやりとりと,メソッドの呼び出しは独立しているというイメージがあったので,うっかり同名のメソッドを定義したときに,一見するとよく分からない挙動になって,難しい. なので,自作オブジェクトがイベントを発行

    自作オブジェクトのイベントのやりとりにはjQuery.triggerではなくjQuery.triggerHandlerを使うほうがよいと思った - hitode909の日記
  • 1