身の回りではチームのMTGとかは普段カメラオフでも、1on1のときくらいはオンにしている人が多い気がする。たぶん1年以上顔見てない人もいるけどとくに困ってないので、僕はどちらでもいいのだけどみなさんはどうだろう。 僕はある日、手荒れ対策でMacをクラムシェルモードにしたらカメラが畳まれてしまい使えなくなってしまった、という事情である日カメラオフにして過ごしていた。 さっき一念発起してMacのフタをあけてカメラオンにしてみたけど、ケーブル（高額なケーブルなので長さにゆとりのあるものは買えない）が短いので、ひきちぎれそう。 普段はカメラオフだけど、1on1のときくらいはカメラを— 趣味はマリンスポーツです (@hitode909) 2023年8月21日 この日記が、カメラオンにするのが当然、みたいな押し付けを推し進める記事にはならないようにしたい。 むしろ、1on1だからといってMacのフタ開

いろんな人の相談役をやっているのだけど、ささいなことに、わざわざ「良いと思います！」って言うようにしている。 この調子でいいと思います！ってわざわざ言う 言われた方からは、迷うことなく進めたら良いのだな、ということが伝わる 意見を言えるチャンスがあったら「この調子でよさそうだけど、ゆくゆくはこんな問題に直面しそうですね」とか、ちょっと意見をはさんでおく 頭出ししておいたら考えてもらえるかもしれないし、想定と違ったら、えっそんなことはないんですけど…と早めに変なことに気づけるかもしれない シニアっぽいロールの人物としては、聞かれてもないのに、良いと思います！って言っておくのが大事。 やってみてもらって、うまくいかなかったら、想定と違ってうまくいかなかったんですけど、って声をかけてもらえる。 最初の段階で黙っていたら、どういうスタンスだったのか不明で、相談しにいくときに、まず、どう思いますか？

優秀な人とか、仕事のできる人がいて、ちょっといいことをしてくれると、ありがたい、と思いつつ、そこまでできるんだったら、もうちょっと、こんなこともやってくれると、もっと良い状態になれそうですね、って言ってしまう。 一方で、この人はまだまだがんばってほしい、という人が、ちょっといいことをしてくれると、前はできてなかったのに、できるようになっててすごい！というフィードバックになる。 なので、いいことをしても、そんなに褒められてないな、と思ったら、その調子でやってればもっといい感じになれるのでいろいろ言ってくれてる、という状態である、ということがあるかもしれない。それか、単に、褒められるようなことをしていない。 人間ごとに期待値があって、80点取れそうな人なら、120点出したいよねって話をするし、20点くらいの人には、60点を目指そう、って言う、みたいな話。 そこで、やってくれそうかどうかも関わっ

技術検証とかやるときに、夢のおもしろ新技術の練習をしていると、おもしろさ、夢っぽさゆえに、導入しましょう!!となる力が働いてしまう。現在レガシー寄りの構成で、モダンな技術を試すときとかは、成功を願ってしまう。 移行先で今の苦しみが解消されているかは要確認で、技術スタックの問題ではなくて、ビジネスロジックの複雑さが現れているだけだったら、複雑さがそのままスライドして再構築されるだけだったりする。 というときに、粗探しをする前提の人を任命しておくと良いかもしれない。粗探しをするつもりでなくても、関係者が同質的すぎるときは一歩引いてバランスが取れているか確認する必要がある。 ちょっと別の話で、チームメンバーとどれくらい信じているものが同じことを期待するかという話題があって、 似たような人が集まっていると話は早い 合意形成が楽 結論が偏る恐れがある いろんな人がいると意見の偏りを防げる 合意形成は

ミ♭ファソの歌詞がドレミ、にくわえて、ファシ♭ソファの歌詞がソラシド これは前から知っていて、嫌だな、と思ってた。 ドド♯ド♯ド♯の歌詞がドレミファ はじめてのおつかいって昔あったよね、と話してたらイントロでドレミファドレミファって歌ってるのを発見してしまった。 サビではドレミファソラシドって言ってるけど音階はソラドレミファ♯ソなのでここは転調されてるのだと思えばギリギリ耐えられる。イントロのドレミファドレミファはきびしいと思う。 こういう曲だけを集めていつかDJデビューしたい。 ほかにこういう状態になっている曲を知ってたら教えてください。 そういえば、ヤマハ音楽教室で歌うドレミファソラファミレドは一致していてうれしい。すべての曲がこういう形になってほしいものですね。 追記 コメント欄で教えてもらえた。まとまってておもしろい。上記2曲はこの動画でも冒頭の2曲で、代表的な音ずれソングっぽい。

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

今週は同僚と毎日長時間ペアプロしていた。 おもしろかったのが、同僚のテストの書き進め方で、一番複雑な正常系のテストをちゃんと書いてから、その複雑なテストをもとに、いろんな条件を削っていって異常系のテストを作っていく、というところ。 僕は逆で、入力が空なら何も起きない、とか、一番簡単な異常系のテストを書いて、そこだけ通るのを確認して、よしよし、と進めていって、メソッド本来の動きは最後に確認して終わる。 変な進め方だな〜(主観)と思って眺めていたけど、たしかに正常系のテストが通っていれば、あとはバリデーションまわりのチェックとか、例外となる場合のチェックをすれば終わりで、異常系のテストがすごい速さで書かれていておもしろかった。 …という話をしたら、チームメンバーたちは正常系のテストから書きはじめるという人が多くて、正しくことを確認してから、1個ずつ前提となる条件を外してみて試す、と聞いて、同値

たまに、今のこの状況は組織パターンに載ってたこのパターンだ、と思い出すことがある。数年前に読んでまだ役立ってる本のうちのひとつ。 今は「常に誰かが進捗させる」というプラクティスをやっている。それ自体はいいのだけど、問題なのは、チーム内チームのエンジニア二人チームでやっているので、一人が進捗させる、もう一人が差し込み対応する、という最小の形になっていること。 奥さんが家でやってる生け花教室のホームページを作る夫、みたいなものをイメージすると、奥さんが生花を教えることで進捗させて、夫がホームページ更新など雑務を巻き取るという構造をイメージできる。百人以上の人間がいる会社であっても、夫婦の生け花教室と同じ数の人のアサインでことを進めているのだとしたら、推進力では同じくらいしか出せないはず。実際には百人いる会社には経理の人がいたり総務の人が居たり、資本が潤沢にあったら良いパソコンを使えるとか、いろ

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

ソフトウェアを作るときにクオリティとスピードのバランスをとりたくて，どちらかに偏ってはいけなく，どちらもキープしないといけない．すごく雑に*1とらえると， クオリティ→正しく動き，不具合がないほうがよい スピード→(計算時間ではなく)早く作れるほうがよい ということになる． コードレビューでは，不具合を見つけて直してもらったり，動きはしてもコードの可読性に問題があって直してもらったりと，クオリティに目を向けられがちだと思う． ところで，コードレビューとスピードの関わりについて考えてみる．スピードのためにできることはいくつかあり， 早く読み始める→他のことやってても手を止めて読み始めたり，1日のうち決まった時間にレビュータイムを設けたり 速く読む→これはコツとかある*2けど精読しないといけないので難しい 不具合を見逃さない→リリース後とか，リリース直前に正しく動かないことが分かったら大きな手

プレゼンモード 再生 ← / →で移動 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でベスト

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

会社でボードゲームしてる人たちがいる。 僕はボードゲーム苦手で、たまにやっても全然勝てない。 将棋とかイメージすると、こっちがこういう手を出すと相手はどうするか、そしてその次は、というのを予測すればよいのだけど、なんかそれがめんどうで、なんでこんなこと考えないといけないのか、とか考えだしてくたびれてしまう。 ずっと論理的に考えるのが苦手で、すぐめんどうになってやめてしまう。 普段、仕事や遊びでソフトウェア作ってるのだけど、よく考えると、ソフトウェアの動作が論理的なだけで、ソフトウェア作るのは勘でできる。 ソフトウェアが正しく動くかどうかは論理的に決められて、電卓アプリなら計算結果が狂ってたら間違っているけど、その電卓アプリがどのように作られたか、には正しさはない。逆立ちして作っても、猿にタイプライターを渡して作っても、計算結果合ってれば良い。 過去のデータとか経験によると猿に書かせるのは効

弊社では毎年インターンを受け入れているのだけど，いまもインターンが来てて，テスト先に書きたいけど油断すると先に実装を書いてしまう，とか話してた． 個人的には，テスト先に書くのが大事というよりかは，意識して仕様を先に考えるのが大事だと思っている．テストを先に書くと，先に仕様を考えざるを得ないので，良いスタイルが身につく． 僕がよくやるのは，関連しそうなクラスの絵をひと通りノートに書いてみて，その図だけで，うまく動くことを説明できるくらい考えてみる．その時点でおかしかったら，コード書いてもおかしくなる．ノートに方眼ついてるとクラス図書きやすい．UMLとかじゃなくても，自分で見て分かるくらいでもいいと思う． 紙でうまくいったら，外部仕様だけソースコードに書いてみる．クラス名と，メソッドの定義と，メソッドの上くらいに，ひと通りコメントでも書いてみて，この関数はこういうことをするんです，こういう引数

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

こういうCSSを書くとなんとなく丸くなる．スターとかも丸くなってかわいい．けど全部丸くなるので乱暴な感じはする． * { border-radius: 30px !important; } デザイン編集画面の，デザインCSSっていうところに追記すれば丸くなる．スマフォ版は変わらず，PC版だけ丸くなる． http://blog.hatena.ne.jp/my/config/design/detail

rokugaっていうウェブアプリケーションを作った．ブラウザ上で動画をアニメーションGIFに変換できる．Google Chromeでもちょっと動くけどSafariで見るのが良い． http://rokuga.herokuapp.com/ 使い方 こんな感じで，動画をドロップしてくださいとか言ってる． 1コマずつ出てきて，このコマとこのコマ，この速さ，みたいな指定ができる． 完成したアニメーションGIFは名前を付けて保存しましょう． 特徴 ブラウザで再生できる動画なら何でも変換できる Macなら動画はQuickTime Playerで撮れるので気軽に使える リアルタイムにプレビューしながら仕上がりを確認できる コマ送りは逆再生，行ったり来たり，シャッフルに対応 Herokuで動かしたらCPUが遅くて動画の変換にす時間かかる git cloneしてローカルで動かすとちょっと速い ソースコード→

この記事はめちゃくちゃ古いです．別の方法で，oAuthに対応したbotを作ってください．google:twitter bot oAuth 今日はTwitterの簡単なbotを作ってみます。 作るもの 現在のUNIXタイムを配信する、unixtimebotを作ります。 既に完成したものが以下のURLで動いています(飽きたら配信が止まるかもしれません)。 http://twitter.com/unixtimebot あなたはこのbotをfollowすることによって、常にUNIXタイムを意識しながら暮らすことができます。 方針 Rubyを使います。 直接TwitterのAPIを叩くのではなく、RubyGemsからライブラリを取ってきてそれを使ってアクセスします。 Twitterにアクセスできるgem Twitterにアクセスするためのgemは、ちょっと探しただけで、これだけありました。 Twit