■ - hitode909の日記
id:minesweeper96さんがAIに中野区の情報を尋ねられていて、架空の喫茶店をおすすめしてもらっていた。 どう考えても住人のほうが詳しいことをわざわざAIに尋ねるのがおもしろいなと思ったので、僕の住んでる京都情報もいろいろ聞いてみようと思った。 良すぎる。とんかつ ぱんつ！ pic.twitter.com/wITnqDs4Xo— minekouki（みね） (@minesweeper96) 2023年1月26日 京都のIT企業事情を聞いてみる。NTTコミュニケーションズがあるとは思えないけど、大きな会社だろうし、子会社の子会社とかの出張所とかはあるのかな？とも思う。 烏丸御池に絞ってみたらWebっぽい会社が増えた。一時期、いろんなWeb企業が京都に進出していたのを思い出す。あちこちで勉強会があって、寿司を食べにお邪魔していた。 烏丸御池にはブログを作ってるような会社もある気がする
毎週やってる定例会のアジェンダに「これは月末の会で」としておくとスキップされがち - hitode909の日記
開発しているアプリケーションのフロントエンドの様子を見る会（フロントエンド草むしり会）を毎週30分ずつ開催している。 式次第の雰囲気を紹介するとこういう形で、毎週見るメトリクスやエラーに加えて、月に1回くらい様子を見たい項目もある。 アップデート関連は、Pull Requestが出たら都度対処するのだけど、それに加えて最近の様子はどうだろう、と眺める時間を取りたい。そういうものは月に1回くらい見ることにしている。 毎週 この会の大義を確認しよう 終わってない宿題を眺めよう エラーのメトリクスを見よう パフォーマンスのメトリクスを見よう 月の初めの会のみ Dependency Dashboardのアップデート候補を見よう Dependabot alertsを見よう ここで「月の初めの会のみ」としているのがポイントで、今回が月の初めかどうかは誰が見ても明らかで、間違いが起きにくい。 これを仮に
男性育休シリーズ - hitode909の日記
男性の育休についての本がKindle Unlimitedにあったのでざっと読んだ。 育休は国の制度なので誰にとっても平等だけど、知らない制度があったりなかったりして、知識の有無によって損得がある。 金銭面 育児休業給付金の振り込みは休み始めてから2.5〜3ヶ月後になるので、100万円くらい貯めておいたほうがよい、とのことだった。 ちゃんと調べず休み始めて、いつ振り込まれるのかな〜とニコニコして待っているけどまだ振り込まれず、本の情報を信じると、今月末か来月くらいになりそう。 多少は貯蓄があるとはいえ、2〜3ヶ月のあいだダブルインカムがゼロインカムになるのは初の体験で、お金の心配に脳のリソースを持っていかれると判断力が低下するのでよろしくない。 毎月の収入を失って分かったことは、給料さえ毎月入ってきたら何でも買えるということ。今は無収入なので買えないけど、給料が入っていたらリヴァイ兵長がしゃ
アウトプットの品質を下げておくと気軽に書けるようになる - hitode909の日記
12月であるし、アドベントカレンダーが回っていたりして、よくできた興味深いブログの記事を目にすることが多い。 よくできた記事ばかり見ていると、自分もちゃんとしたものを出さなければ、となってしまうことがありそう。しかしちょっと待ってほしい。 ブログ記事、といっても、プロの編集の手が入ったお金のかかった記事、一人で頑張って書いた大作、チョロっと書いて出てきた日記まで様々なものがある。 100文字くらいで終わっているものもあれば10万文字くらい書かれているものもあるので、文量に1000倍の差がある。 映像の世界で1000倍の差を出そうとすると、2時間すなわち7000秒の映画と、スマホで撮った7秒の動画、くらいの差がある。 2時間で観れるすばらしい映画がなにかあるとして、 Amazon.co.jp: フォレスト・ガンプ／一期一会 (字幕版)を観る | Prime Video これの1000分の1の
テスト、正常系から書くか異常系から書くか - hitode909の日記
今週は同僚と毎日長時間ペアプロしていた。 おもしろかったのが、同僚のテストの書き進め方で、一番複雑な正常系のテストをちゃんと書いてから、その複雑なテストをもとに、いろんな条件を削っていって異常系のテストを作っていく、というところ。 僕は逆で、入力が空なら何も起きない、とか、一番簡単な異常系のテストを書いて、そこだけ通るのを確認して、よしよし、と進めていって、メソッド本来の動きは最後に確認して終わる。 変な進め方だな〜(主観)と思って眺めていたけど、たしかに正常系のテストが通っていれば、あとはバリデーションまわりのチェックとか、例外となる場合のチェックをすれば終わりで、異常系のテストがすごい速さで書かれていておもしろかった。 …という話をしたら、チームメンバーたちは正常系のテストから書きはじめるという人が多くて、正しくことを確認してから、1個ずつ前提となる条件を外してみて試す、と聞いて、同値
今週は技術的な選択の仕方について考えることが多かった - hitode909の日記
今週は技術的な選択の仕方について考えることが多かった。 どうやって決めるか、というだけでなくて、どこに決めポイントがあるか、というところの見極めも難しい。 何も決めずに進んでいって、あとで見返すとすごいことになってしまい、ここをもうちょっと考えておけると良かったね、ということもあるし、考えすぎて重厚に作りすぎだったので、あとからシンプルな形に直していく、ということもある。 個人的には、ふだんはこのように考えています、という手順を書いておくと、 実現方法を考えるだけでなくて、他に取れる作戦がないか考えていく よさそうな方針が、他の作戦と比べてこれが一番良い、という確証を得る 確証が得られないときは、考えて決める 昼休みにプールに行って泳いでいると、これだけ考え続けて何も出てこないということはこれで行くしかない!と決められることが多かった というような形でやっていると思う。これでできるのでこれ
It Doesn't Have to Be Crazy at Work - hitode909の日記
土曜に強いチームはオフィスを捨てるを読んだ流れで日曜に読んだ。同じくBasecampの二人の書いた本で、仕事に夢中になる必要はなく、そのために時間が分断されない働き方で、無謀な目標や締切、できない量の仕事を持たないようにしています、という本。crazy at workは通勤時のcrazy trafficと同じ用法で、狂った人ではなくて狂った状態、とのこと。 basecamp.com Defend Your Timeの章が参考になった。中断しない、中断されないこと、非同期にコミュニケーションすること、の重要さが説かれている。 8時間のフライトは長いけど8時間の仕事は短く感じる。フライトには中断がない 企業は様々なものを守っているが、従業員の時間と注意力を守ることに失敗しがちである status meetingsをおこなわず、かわりに近況を書いて、空き時間に読んでもらっている エキスパートのも
コードを書くには連続した2時間が必要 - hitode909の日記
ある日の午後のスケジュールは、30分ミーティングx2→30分自由時間→そして1.5時間ミーティング、その後は30分自由時間と30分ミーティングを繰り返して定時を迎える…みたいな様子だった。案の定、自由時間で意味ある仕事を進めることはできなかった。 自由な時間が30分あれば、チャットを読んだり、コードレビューしたり、グループウェアを見て回ったり、とかはできる。コードを書くにしても、ここをこう変えれば良いことがわかっていて、書くだけ、とか、ライブラリのバージョンアップ、くらいなら30分で書いてpushしておいて、次の30分でテストが落ちたら直したりして、と進められる。 しかし、そういうことより難しいことをしようとすると、30分だと、さて、問題がどういうものかは分かってきたので、どうしようかな、というあたりで時間切れになってしまう。1時間あれば、ようやくコードを書き始められるかな、というところで
【現在は対応不要】Chrome80以降でALBの認証を使っているとcookieが4096バイトを超えて認証できないことがあり、社内サービスではcookie名を縮めて対応した - hitode909の日記
2020/2/18追記 サポートに問い合わせたところ、ALBの不具合はロールバック済みで、cookie名を縮める対応は不要、とのことでした。試してみたところ、たしかにcookie名の指定をやめても問題なく認証できました。 AWSのApplication Load Balancerの認証機能を使って、スタッフからのアクセスのみ許可する社内向けウェブサービスを運用しているのだけど、昨日くらいからGoogle Chromeで認証が通らなないという声を聞くようになった。 現象としてはリダイレクトループが発生していて、コンソールを見るとSet-Cookie headerが長すぎるというエラーが出ていた。 Set-Cookie header is ignored in response from url: https://****/oauth2/idpresponse?code=e51b4cf0-8b
野良1on1 - hitode909の日記
出張ついでに東京メンバーと1on1しまくったりしている。 1on1というと、上司と部下、とか、メンターメンティー、みたいなスタイルが多そうだけど、野良1on1みたいなことをやっていて、話したい人がいたら関係を問わず1on1を設定する、というのをやっている。 Scrapboxに話したいことベスト3を書いて持ち寄るスタイルで、二人ともが話したいことがあればそれを先に話したりできて便利。この手法はOKRに載ってたと思う。 OKR(オーケーアール) シリコンバレー式で大胆な目標を達成する方法 作者: クリスティーナ・ウォドキー,及川卓也(解説),二木夢子出版社/メーカー: 日経BP発売日: 2018/03/15メディア: 単行本この商品を含むブログ (1件) を見る こういうテンプレートを利用している、というのを貼っておきます。ご利用ください。 #1on1 話しづらいことがあったらprivate
ライバル - hitode909の日記
自分の能力はいまどんな感じなのか?と考えて，ライバルと自分の能力を比べよう，となったときに，ライバルに圧勝している人はいないと思う．いたらライバルとして役に立たないため． 僕だったら，会社の同僚とか，インターネットの友達とかを思い浮かべる．その同僚や友達たちの，それぞれ，この人はこういう部分が誰にも負けず得意だな，というのを考えていく．そうすると，ライバルを選ぶ時点で強い人を思い浮かべているので，全ての点で負けしていることになる． 全然だめで，自分にはなにもできず，まるで詐欺師のように感じてしまうのだけど，そうではない． ライバルたちが分散して持っている属性が架空の人格にバインドされて，最強の人間として君臨しているけど，実際にそのような人物はいない．蝶のように舞う人間と，蜂のように刺す人間がいるときに，その特徴が合成されて，蝶のように舞い蜂のように刺す最強の人間がいるような錯覚をしているこ
突然シェルのhistoryが消えてめっちゃつらい - hitode909の日記
突然シェルのhistoryが消えてめっちゃつらかった。学生の頃に、漢のzshという連載を見て、シェルのヒストリは無限に大きくすべしというプラクティスを実践していた。それ以来、10年間くらい育ててきたけど、今朝見たら突然15KBになっていた。偶然Dropboxに残ってるのを復元したけど、直近5年分くらい消えてしまった。数ヶ月ぶりにTimeMachineのディスクをつないでみたらそもそも認識されなくて、ディスクごと壊れてるようだった。バックアップはリストアできないと意味ない。 思うのが、シェルの履歴という形で各自が有用なコマンドを保持していて、消えて困っているのがおかしい。リポジトリごとにhistory置き場となるウェブサービスを作ってどんどんpushしていくような形とか、エディタのランチャから起動するだけで開発が完結するとか、現代的な形は考えられると思う。昔はsshですばやくサーバーに接続し
自分を退職に追い込む動きをすると良い - hitode909の日記
去年，いまのチームに来たときは僕がフロントエンドのリファクタリングを進めたり面倒を見たりしていた．JS得意な友達がバイトに来てくれるようになり，今はその人がBabelを入れたりしてくれている．彼がバイトに来てくれなかったら，いまだになんとなく興味があるので見ますみたいな感じで一人で面倒見ていた気もする． よくある話で，属人性を高めないように自分の知識を展開しましょうという話があるけど，具体的にアクションプランを考えてもどれが一番良いのかわからない．抽象的に考えると，自分の仕事をなくして退職に追い込むような動きをすると良い．周りのレベルが上がったり移譲されたりしてその分野で価値を発揮できなくなってれば自分じゃなくてもできるようになっている 自分でなくても実装できるようになって，作戦の相談に乗ったりとかしていると，次はそこの属人性が上がってきて，自分のバリューを再びなくすには，誰でも計画を立て
開発中の機能を小分けにして本番環境にどんどん出すためには - hitode909の日記
ふだんの開発では，稼働中のシステムに影響を与えないように開発中の新機能や新システムを共存させながらちょっとずつデプロイして進めている．どんな事を考えてやっているか記しておきます． フィーチャートグルを使う すべてのコードが本番環境に入っているけど無効化されている状態で開発を進める ブランチをたくさん作るのに対する考え方で，フラグを有効にすると開発中の機能を使える スタッフなら有効にしたり，フィーチャーのオンオフを選べる画面を作ってたこともある フィーチャーブランチを利用した開発はチームを継続的インテグレーションから遠ざける – ゆびてく FeatureToggle 完成したらフィーチャートグルに関係なく全員に有効状態にして完成 フロントエンドの施策で，実際のデータやインフラ構成でどれくらいスピードが出るかわからないときに，ひとまずフラグをオンにすると動く形でデプロイしたりとか レイヤの下の
作ったプレゼンがどこまで届くか - hitode909の日記
勉強会で発表すると，数十人とか数百人くらいに聞いてもらえる．そこで終わりだともったいない．数時間かけてリリースしたウェブサービスが数十PVだと，元をとれてないと感じそう． YAPCの発表の動画は2800回見てもらえている．通常の人間が2800人の前で話せる機会はないので，すごく効率がよい．一度喋ったのがそのまま再利用というかリピートされているのもお得．この動画なぜか人気で，いろんな人に，複数回観たって言ってもらえている．動画を公開してくださった勉強会のスタッフの皆さまには感謝しています． www.youtube.com 発表資料は33000回見てもらえていた．こっちは自分でめくっていかないと読めないのと，お喋りがある前提で資料を作っているから，これだけ見てもいまいちかもしれない． speakerdeck.com 工数ゼロで展開できるのも便利で，同じ話を，動画を使わずに2800人に届けようと
エディタの左上にリアルタイムに顔を表示する - 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 規模が大きくなっててオフィスもモブプロに特化していておもしろい 関係性 よくあるペアプロでは，ドライバーとナビゲータではなくドライバーとフォロワーになってしまうことがある 横に座ってる人が考えて，キーボードの前に座ってる人がタイピング
LGTM画像は見た目はおもしろいけど遊んでいるわけではない - hitode909の日記
YAPCのスポンサーセッションで，DeNAの採用担当の方が話されていて，エンジニア文化への憧れから，コードの意味は分からないけど勝手にLGTMしたり，会場の発表スライドに載せるには不適切な画像を貼ったりしている，という発表をされていた． 単に迷惑そう，と思ったのと，それ以上に悲しくなって，自分たちが大切にしていることを軽んじられると悲しい気持ちになる． LGTMな画像を貼るのは，傍目から見ると，にぎやかな画像が出てきて楽しそうな雰囲気があるけど，画像を貼る前にはコードが正しいか検証しているのであって，ミスの許されないシリアスな場所でもある． 見た目がおもしろそうだからといって遊びに来られると迷惑だし，そういうライトな活動をするような，遊んでいるように思われていたのか，という悲しさがある． 逆に，そんなシリアスな活動をしているなら，そうと分かる真剣そうな雰囲気になっているべきという気もして，
人月の暗黙知の本 - hitode909の日記
見積りについて興味が出てきたので読んだ．コードコンプリートを書いたスティーブマコネルの本． 具体的な見積りの技法が紹介されているけど，それよりも，いい話がたくさん書いてあって良かった． 見積りとターゲット 見積り=作業量とか規模とか ターゲット=いつまでにほしいとか 数ヶ月後の発表会のための開発なら，その規模のものは作れませんではなく，間に合うような物を一緒に考える 技術的な知識を使っていろんな代案を出すのは技術者の責任 即興で見積りしてはいけない→正確ではない 専門家の判断は品質が低い→正確ではない 計算できるなら計算しなければならない 見積りに幅を持たせる この期間で終わる確率は何%とか，最良で何週間， 最低で何週間，とか そのときも計算する 高く見積るとプロジェクトが却下されるからといって安く見積ってはいけない 正しい情報を提供できないので，意思決定できなくなってしまう リソースが本
コードレビューのクオリティとスピード，とくにスピードについて，それとコミュニケーションについて - hitode909の日記
ソフトウェアを作るときにクオリティとスピードのバランスをとりたくて，どちらかに偏ってはいけなく，どちらもキープしないといけない．すごく雑に*1とらえると， クオリティ→正しく動き，不具合がないほうがよい スピード→(計算時間ではなく)早く作れるほうがよい ということになる． コードレビューでは，不具合を見つけて直してもらったり，動きはしてもコードの可読性に問題があって直してもらったりと，クオリティに目を向けられがちだと思う． ところで，コードレビューとスピードの関わりについて考えてみる．スピードのためにできることはいくつかあり， 早く読み始める→他のことやってても手を止めて読み始めたり，1日のうち決まった時間にレビュータイムを設けたり 速く読む→これはコツとかある*2けど精読しないといけないので難しい 不具合を見逃さない→リリース後とか，リリース直前に正しく動かないことが分かったら大きな手
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
