自分のはてなブログをChat GPTにつないだ - hitode909の日記
id:nishiohirokazuさん作のScrapboxの情報をChat GPTに流し込んで対話するスクリプトがおもしろそうだったので動かして遊んでみていた。 自分のScrapboxをChatGPTにつないだ - 西尾泰和のScrapbox 自分のScrapboxからおすすめサウナを案内してもらえた。おもしろい。自分のはてなブログとも対話したい。 https://t.co/7L51YPVURe pic.twitter.com/ijVXEFDXGl— 趣味はマリンスポーツです (@hitode909) 2023年3月10日 自分はScrapboxよりはてなブログのほうをよく書いてるので、当然はてなブログと対話してみたい。 はてなブログのMT形式のエクスポート結果をScrapboxのエクスポート結果のJSONっぽく乱暴に書き換えるスクリプトを用意して、はてなブログのデータを使ってチャットでき
Asanaのダッシュボード内のバーンアップチャートに予測線と完了日をプロットするChrome拡張 - hitode909の日記
Asanaのダッシュボードに置けるバーンアップチャートには今後の予測を表示する機能がなく、過去の実績だけが表示されている。 Asanaのバーンアプチャートの例一方、よくあるバーンアップチャートはこんな感じで、予測線が引かれていて、タスクがこれだけあって、タスクの完了ペースはこうなってて、このペースが続けばいつ終わりそうです、という予測ができるようになっている。 差し込みの多いプロダクト開発のスケジュールの精度を上げるためにはバーンアップチャートがおすすめです - スタディサプリ Product Team Blog タスク管理にはAsanaを使いながら、いつ終わるかも予測したい。 既存手法 社内ではいくつかのアプローチが試みられていた。 タスク一覧をCSVをエクスポートして、Google Sheetsにインポートしてバーンアップチャートを構築する 最初に試みられた手法がこれで、更新するたびに
目についたところをやるか、ロードマップに沿ってやるか - hitode909の日記
ソフトウェアを作っていて、ここの開発体験が悪いのでちょっとリファクタリングしたい、と思ったときにどうするか。 とにかく直してしまう 今後のリファクタリング予定、みたいなロードマップと見比べて、ロードマップに合致してたら直す すぐには手を付けず、今後のリファクタリング予定、みたいなロードマップを粛々と進める とにかく見かけたら完膚なきまでに直す、という人もいると思って、カッとなって直してきました…みたいな言説はよく見る。 一方で、目についた順に手を付けていてもできることには限界があって、全員の意識を統一して、こういう順序でやればうまくいくに違いない、みたいにロードマップを作ったりして段取りをして、同じ方向に向かっていけると、より大きいことができたり、より良い状態になれたりする、ということもあるだろうと思う。 というときに、どれくらいのバランスで、ちょっと直すのか、直さないのか、段取りを定めて
JavaScript 長いループ 分割 - hitode909の日記
ブラウザで長いループや、重い処理をともなうループを回したいとき、同期的にJavaScriptを実行するとメインスレッドがブロックしてしまうので、ちょっとずつ細切れに分割して実行したい、ということがある。 昨日久しぶりに書いたら新たなパターンと出会ったので、これまでにどう書いてて今回どうなったかメモ。 setTimeoutする 以前(10年前とか)はこんなのをよく書いていた。 itemsがでかいArrayで、console.logがすごく重い処理だとして読んでください。 function iterateHeavyTask(items) { const startAt = new Date(); while (items.length > 0 && new Date().getTime() - startAt < 10) { console.log(items.shift()); } if (
テスト、正常系から書くか異常系から書くか - hitode909の日記
今週は同僚と毎日長時間ペアプロしていた。 おもしろかったのが、同僚のテストの書き進め方で、一番複雑な正常系のテストをちゃんと書いてから、その複雑なテストをもとに、いろんな条件を削っていって異常系のテストを作っていく、というところ。 僕は逆で、入力が空なら何も起きない、とか、一番簡単な異常系のテストを書いて、そこだけ通るのを確認して、よしよし、と進めていって、メソッド本来の動きは最後に確認して終わる。 変な進め方だな〜(主観)と思って眺めていたけど、たしかに正常系のテストが通っていれば、あとはバリデーションまわりのチェックとか、例外となる場合のチェックをすれば終わりで、異常系のテストがすごい速さで書かれていておもしろかった。 …という話をしたら、チームメンバーたちは正常系のテストから書きはじめるという人が多くて、正しくことを確認してから、1個ずつ前提となる条件を外してみて試す、と聞いて、同値
一人でやってると個人開発と同じクオリティになる問題 - hitode909の日記
たまに、今のこの状況は組織パターンに載ってたこのパターンだ、と思い出すことがある。数年前に読んでまだ役立ってる本のうちのひとつ。 今は「常に誰かが進捗させる」というプラクティスをやっている。それ自体はいいのだけど、問題なのは、チーム内チームのエンジニア二人チームでやっているので、一人が進捗させる、もう一人が差し込み対応する、という最小の形になっていること。 奥さんが家でやってる生け花教室のホームページを作る夫、みたいなものをイメージすると、奥さんが生花を教えることで進捗させて、夫がホームページ更新など雑務を巻き取るという構造をイメージできる。百人以上の人間がいる会社であっても、夫婦の生け花教室と同じ数の人のアサインでことを進めているのだとしたら、推進力では同じくらいしか出せないはず。実際には百人いる会社には経理の人がいたり総務の人が居たり、資本が潤沢にあったら良いパソコンを使えるとか、いろ
エンジニアアルバイト氏受け入れテクニック - hitode909の日記
いま社員エンジニアが何人かに加えてエンジニアアルバイト2人、くらいのチームで働いていて、その中でアルバイト氏のメンターもやっている。 前のチームでも何年かアルバイトの面倒を見たり、何回かインターンのメンターをやったりしていた。 手癖でいろんなことをやってしまっていて、属人性が高まってしまっていると感じたので、どんなことをやっているか書いておく。 1日に何回か口頭で会話する 実装ができててから方針がまずかった、となると時間がもったいない 方針書いたくらいでレビュー依頼に出してね、とお願いしてもやってもらうの難しいので、こちらから聞きに行くほうがうまくいきやすい レビュー依頼になったらすぐに見る 社員は明日も要るけど、アルバイト氏は週に数回しか来ないので、その日帰るまでにレビュー完了して打ち返しもしてもらえるように動けると良い レビュー依頼になってなくてもPull Request見に行く 方針
突然シェルのhistoryが消えてめっちゃつらい - hitode909の日記
突然シェルのhistoryが消えてめっちゃつらかった。学生の頃に、漢のzshという連載を見て、シェルのヒストリは無限に大きくすべしというプラクティスを実践していた。それ以来、10年間くらい育ててきたけど、今朝見たら突然15KBになっていた。偶然Dropboxに残ってるのを復元したけど、直近5年分くらい消えてしまった。数ヶ月ぶりにTimeMachineのディスクをつないでみたらそもそも認識されなくて、ディスクごと壊れてるようだった。バックアップはリストアできないと意味ない。 思うのが、シェルの履歴という形で各自が有用なコマンドを保持していて、消えて困っているのがおかしい。リポジトリごとにhistory置き場となるウェブサービスを作ってどんどんpushしていくような形とか、エディタのランチャから起動するだけで開発が完結するとか、現代的な形は考えられると思う。昔はsshですばやくサーバーに接続し
社内横断で開発効率を上げる取り組み #pepabohatena - hitode909の日記
プレゼンモード 再生 ← / →で移動 fでフルスクリーン escでおわる こんにちは，id:hitode909です．はてな・ペパボ技術大会 #4 〜DevOps〜 @京都において，「社内横断で開発効率を上げる取り組み」というお題で発表しています．この記事は，その発表資料です． 社内横断で開発効率を上げる取り組み はてな・ペパボ技術大会 #4 〜DevOps〜 @京都 hitode909 自己紹介 hitode909 株式会社はてな アプリケーションエンジニア 好きな本はオブジェクト指向入門とドメイン駆動設計 2009年〜 うごメモチーム 2012年〜 ブログチーム 2017年〜 マンガチーム 2018年〜 CTO室(兼務) アジェンダ CTO室での活動 特定のチームに閉じず，社内横断で開発効率を上げるための試み みなさん 学生の方? 🙌 社会人の方? 🙌 Devの方? 🙌 Opsの
飲み会IoTボタン作った - hitode909の日記
会社のオフィスは東京と京都に分かれていて，それぞれ，さらに7F，8F，9Fとか，B1，3F，4F，のように3フロアずつに分かれているので，合計6フロアあることになる．それに加えてリモートの人たちは家にいる． 定時後に，お疲れ様でしたとか言ってビールや日本酒をあけることがあるのだけど，他のフロアでワイワイやってても気付きにくく，駆け付きにくい，駆け付けてもらいにくい，という問題がある． そこで，AWSのIoTボタンを使って人を呼べるようにした． 張り紙 このビールを冷やしてる冷蔵庫付近の壁に張り紙を貼った． 使い方 この乱雑な紙に使い方と，IoTボタンを貼り付けている．IoTボタンはボタンの裏側が接着面になっていて，ドキュメントに貼り付けることができて便利． 開催 1回押すと，Slackの#drinkingnow(飲み会の様子を共有するチャンネル)に飲み会開催中のお知らせが流れる．これが流れ
Upgrade-Insecure-Requestsを使ってmixed-contentをだいたい直す - hitode909の日記
ブログをHTTPS化するとHTTPのリソースは読み込めなくなってしまう． http://example.com あらため https://example.com/ みたいにドメインはそのままでhttpからhttpsに置換するだけでアクセスできるなら，Upgrade-Insecure-Requestsを使うと簡単． 詳細設定→headに要素を追加 に以下を貼れば完成する． <meta http-equiv="Content-Security-Policy" content="upgrade-insecure-requests"> 対応しているブラウザで，かつサイト側がHTTPSでの通信を受け付けていたら，HTTPへのリクエストをHTTPSに書き換えてくれる． IEやedgeは対応していないので，IEやedgeでも見てる人が多いブログなら，手で記事内のURLを書き換えたほうが，手間なかわりに喜
一人で仕事してると不安になる現象 - hitode909の日記
ソフトウェアを作っていて，一人でずっとやってると不安になったり，他人がずっと一人でやってると心配になったりする． ふつうのチーム開発では，仕様や方針は皆で合意が取れていて，実装したところは「きのう話していたこの部分を作ってきました，レビューしてください」みたいな話をする 一方で，チームでやっていても，一人で仕事していたら，「実は私はこういうことをやっていて，その上で，この部分を作りました，仕様を理解した上でレビューしてください」みたいな話になる このとき，「実はこういうことをやっていて」という部分を一人でやっていると，見逃していたり，誤解していて，前提から間違っていて，まったくもってだめ，という可能性が上がっていく 一人で作り続けると，一人につき1回10%間違えるとしたら，2回一人で作ると，0.9*0.9=0.81くらいの精度に下がっている 設計段階で二人で見ていれば，間違う可能性は1-0
コードレビューのクオリティとスピード，とくにスピードについて，それとコミュニケーションについて - hitode909の日記
ソフトウェアを作るときにクオリティとスピードのバランスをとりたくて，どちらかに偏ってはいけなく，どちらもキープしないといけない．すごく雑に*1とらえると， クオリティ→正しく動き，不具合がないほうがよい スピード→(計算時間ではなく)早く作れるほうがよい ということになる． コードレビューでは，不具合を見つけて直してもらったり，動きはしてもコードの可読性に問題があって直してもらったりと，クオリティに目を向けられがちだと思う． ところで，コードレビューとスピードの関わりについて考えてみる．スピードのためにできることはいくつかあり， 早く読み始める→他のことやってても手を止めて読み始めたり，1日のうち決まった時間にレビュータイムを設けたり 速く読む→これはコツとかある*2けど精読しないといけないので難しい 不具合を見逃さない→リリース後とか，リリース直前に正しく動かないことが分かったら大きな手
querySelectorAllしてmapしたいとき[...すると短い - hitode909の日記
表示中のHTMLから情報を雑に抜き出して利用するため，ブラウザのデベロッパツールなどでquerySelectorAllしてmapしたい．しかし，querySelectorAllはNodeListを返すので，mapするにはArrayに変換する必要がある． NodeListをArrayに変換するときに短く書く方法ないですかって同僚に聞いたらいろいろ教えてもらえたのでメモ． Array.prototype.slice.callする オーソドックスな手法．昔からこれを書いていて，長くて困っていた．最近はアロー関数を使えるのでちょっと短くなったけど長い． Array.prototype.slice.call(document.querySelectorAll('a')).map(a => a.href) [].slice.callする Array.prototypeのかわりに[]で書く．ちょっと短い
エンジニアの立ち居振舞いについての知見を集めていきたい - hitode909の日記
普段，エンジニアの暮らしというとコードを書いているイメージだけど，実際には，1日8時間のうち2〜3時間しかコードを書けていなかったりする． 実際にはエンジニアはふだん何をしているのか，こういうことを気をつけている，とか，今日の1日はこういう形でした，といった立ち居振舞いを集めて，知見として集めていきたい． ということで，エンジニア立ち居振舞いのお題を作りました． お題「エンジニア立ち居振舞い」 せっかくなので1つ紹介して終わろうと思います． 立ち居振舞い：GitHubの通知を全部見る 僕はチーム内では長い期間在籍しているエンジニアで，一日中GitHubの通知を見ている． GitHubで通知が来るということは，誰かが仕事を進めたということで，何か質問を書いたり，方針を書いていたり，コードをpushしたり，いろんなことを誰かが進めている． そういうときに，そのissueにとって役立ちそうなこと
古いissueをとりあえず閉じる - hitode909の日記
ヤパチーで聞いた話で，古いissueはとりあえずcloseして，やっぱりやるとなったらまたopenする，というのがあった． ノリでKotlin化するというissueを入れたのだけど，テンションが下がってきたので，やめませんかってなってcloseする，とか． これは良いと思って，古いissueは単に古いというだけで価値が減っていきそう． すぐにやらないと困るようなら，古いissueがopenのまま置いてあるということはまずい状況で，そうでなければ，やらなくてもいいということで，openで置いてあるのは邪魔で，次に何をやるべきなのか分からなくなってしまう． また，当時とは状況が変わってきて，実はやらなくてよくなった，みたいなものもある． 誰かが意識的にissueの治安を維持しないと，どんどん増えていって制御できなくなってしまうと思う． ふだん仕事でやってるプロジェクトでは，たまに棚卸しするのだ
プログラミングとは何なのか - hitode909の日記
会社でボードゲームしてる人たちがいる。 僕はボードゲーム苦手で、たまにやっても全然勝てない。 将棋とかイメージすると、こっちがこういう手を出すと相手はどうするか、そしてその次は、というのを予測すればよいのだけど、なんかそれがめんどうで、なんでこんなこと考えないといけないのか、とか考えだしてくたびれてしまう。 ずっと論理的に考えるのが苦手で、すぐめんどうになってやめてしまう。 普段、仕事や遊びでソフトウェア作ってるのだけど、よく考えると、ソフトウェアの動作が論理的なだけで、ソフトウェア作るのは勘でできる。 ソフトウェアが正しく動くかどうかは論理的に決められて、電卓アプリなら計算結果が狂ってたら間違っているけど、その電卓アプリがどのように作られたか、には正しさはない。逆立ちして作っても、猿にタイプライターを渡して作っても、計算結果合ってれば良い。 過去のデータとか経験によると猿に書かせるのは効
テスト書きすぎ問題 - hitode909の日記
テスト書きすぎるとよくないって言ってる人がいた．DHHっていう人．作業時間の1/3以上テストしてたらおかしいとか，ActiveRecordのバリデーションなど，Railsの機能はテストしない，とか． Signals vs. Noiseの去年のエントリに、テストをどれくらい書くべきかということについてDHHが指針を示していたものがあったので... - Sooey 偉い人が言ってるからという理由で，テスト手抜き派の人に良い材料を与えてしまった．僕は意見ちがって，作業時間半分以上はテスト書いたりしてる． テストたくさん書くと，最初に書くときのコストは増える．けど，あとから読む時や，変更したい時には，読むだけだし，書くのも差分だけで良い．コード本体を理解できれば，要らないテスト捨てるのは，落ちたのを消すだけだから簡単．あとで見て，テスト足りないと分かったときに，明文化されてない仕様からテストを補う
上に行くcd作った - hitode909の日記
シェルで，上のディレクトリに行くのがめんどくさくて，cd ../../../../とかしないといけなくて，指を痛める． 上に行くためのupっていうコマンドを作ることにした． その1 up 3ってやると，3つ上に行くのを作った． function up() { i=0 while [ $i -lt $1 ] do cd ../ i=`expr $i + 1` done } 使い方 % pwd /Users/fkd/co/dev/dotfiles % up 3 % pwd /Users/fkd %これは使いにくくて，cd ../../って打つときは，いくつ上に行くか考えながら，../って打ってる．これだと，先に数えておかないといけなくて，難しかった． その２ 考えながら入力できるようにしてみた．引数の数だけ見る． function up() { i=0 while [ $i -lt $# ]
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
