リーダーっぽい人が忙しくても、忙しいって言ってると感じが悪い - hitode909の日記
すみません、私から発表があります！忙しくて、マジむかつくんですけど、とかチームの朝会で発表してしまうと、一緒にやってるメンバーからすると、そんなに忙しいのなら声かけるのを遠慮しとこう…となり、会話タイミングが減ったりして、それによってあとで来月そのリカバリでさらに大変なことになり、さらに忙しく、こんなことなら先月のうちにしっかりやっておくべきでしたな、ということがありえるので、あまり、忙しくしていても、忙しすぎる、って言えない、という問題がある。 よく、ここは問題VS私たちでいきましょう、とか言うけど、主にメンバーたちと仕事している場合は、問題←→私たち←→私、で、私は直接問題と繋がっていない、私たちの手助けをしている、ということがあって、問題の先が私たちにいきつくので、あまり具体的なProblemを連発しづらくて、毎日の会話の実りが少ない、とか、ペアプロの進捗が悪い、とか言うと、個別のメ
承認ではなくて、よさそう、と思って暮らしている - hitode909の日記
普通に書いたdiffは、関心がさまざまなところに散らばっていたたり、書きかけだったりで、意味のまとまりがないもので、それを整形して、説明を書いたものがPull Requestであり、コードレビューは、そのまとまりごとに、他人から見て理解可能であるという承認する行為、という理解をしていた。 なので、レビューを通すことは、動くことに賭けて、以後、動かなかったら責任を取る、みたいなイメージはあまり持っていなかった。 レビュワーの責任をどこまでと規定するか考えて、責任が大きい順に並べていくと レビューを通した以上、以後は私の責任です、という態度 職人魂を感じる 見たところよさそうに思いました、という態度 通りすがり風情を感じる まったくの無責任なので、工数最小化のために何が来てもapproveする、という態度 やっつけ仕事 かるぱさんのチームでは1になっているのかな(追記)こうなっている、というこ
個人で作ったツールをなんでもDocker Hubに上げる姿勢に違和感を感じてきた - hitode909の日記
docker pullしてdocker runするだけで動いて便利じゃん、各言語のセットアップとかも省けるのでどこでも動いてありがたい、と思っていて、個人で作ってるツールもDocker Hubに上げたりしていた。 でも最近は、そういう時代でもないのかな、と思ってきている。 各言語でのライブラリ管理と二重の管理になってしまう Node.jsで作ったツールのイメージを作ると、awesome-tool2.0っていうdockerイメージの中にawesome-tool2.0がインストールされていて、そのイメージにNode.jsも同梱する形になる。 awesome-tool3.0をリリースするときには、まずはnpmに3.0を公開して、そのあとでDockerHubにもビルドして公開する、という流れになる。 各言語のパッケージマネージャのライフサイクルと別に、DockerHubへの公開、というフローが挟ま
1画面1APIと比べるとGraphQLのAPIはどこから作ったらいいか分かりにくい - hitode909の日記
Backends for Frontends的に、1画面につき1つずつAPIを作っていると、画面のリストを作って、それぞれ1画面につき1個ずつAPIを作っていくことになるので、進捗の把握がやりやすかった。10画面あって3APIできてたら進捗30%ということになる。 グラフをたどって開発することになる GraphQLでAPIを作っていると、「実はこの画面を組み立てるためのクエリは、あちらの画面の条件を変えたものである」みたいなことが起きるようになる。たとえば、トップページではサマリを表示していて、もっと見るを押すと全件表示するような場合とか。 このように、着手しようとするともう作るものがなかったりとか、逆に、作るときに、他の画面から使う想定でパラメータの設計をするなど、考えることが増えたりもする。 スキーマに沿ってグラフをたどるだけで画面を組み立てられるのは良いことだけど、開発内容の依存関係
アウトプットの品質を下げておくと気軽に書けるようになる - hitode909の日記
12月であるし、アドベントカレンダーが回っていたりして、よくできた興味深いブログの記事を目にすることが多い。 よくできた記事ばかり見ていると、自分もちゃんとしたものを出さなければ、となってしまうことがありそう。しかしちょっと待ってほしい。 ブログ記事、といっても、プロの編集の手が入ったお金のかかった記事、一人で頑張って書いた大作、チョロっと書いて出てきた日記まで様々なものがある。 100文字くらいで終わっているものもあれば10万文字くらい書かれているものもあるので、文量に1000倍の差がある。 映像の世界で1000倍の差を出そうとすると、2時間すなわち7000秒の映画と、スマホで撮った7秒の動画、くらいの差がある。 2時間で観れるすばらしい映画がなにかあるとして、 Amazon.co.jp: フォレスト・ガンプ／一期一会 (字幕版)を観る | Prime Video これの1000分の1の
Perlの依存モジュールのアップデートを自動化するためのCLIツールを作った。GitHub Actions上で動かしてPull Requestも送れる - hitode909の日記
近年のソフトウェア開発では、RenovateやDependabotといった依存関係更新のためのツールが普及していて、ツールの支援を借りながら依存ライブラリを更新していく開発フローが広まってきている。 これらのツールは、package.jsonで管理されているライブラリだったり、Dockerfileで指定しているイメージだったりを自動的に最新版に更新してPull Requestを出してくれるので、人間は内容を確認してマージボタンを押すか、変なところがあったら手直ししてからマージしていくだけでよい。 はてなでの開発フローでも使い倒していて、先月くらいにも、社内で共有して使ってる設定を公開したりしていた。今ではRenovateのない暮らしに戻ることは考えられないくらいに広まっている。 developer.hatenastaff.com 普段、仕事ではPerlやTypeScriptを書いていて、T
チーム開発で活躍するために、自分の庭を作れると良い - hitode909の日記
チームでどうやって活躍するか、まだイメージがついてない、振られた仕事をやっているだけで、仕事をしている間は忙しいけど、確認待ちになるとすぐ暇になってしまう、というメンバーの悩みを聞いていた。 巨大なチーム、巨大なプロダクトだと、すぐに全容を把握するのは難しい。その中で、この範囲なら触れています、任せてください、という庭を作るとよいのでは、という話をした。 思いつきで話したわりには意外といいことを言ってるなと思ったので掘り下げて書いてみます。 庭とは 現代では、庭のある家に住んでる人は少ないかもしれない。うちは実家が田舎だったので庭があって、ボールを蹴って回ったり、石をめくってアリを観察したり、隣の家の庭との境界もゆるくて、冒険と言って隣の家の庭で遊んだりしていた。 大人になってからの庭というと、池袋で遊んでた人が「池袋は俺の庭」と言ったり、JR新宿駅の東口を出たら椎名林檎の庭があることが知
【現在は対応不要】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
いつも「時間がない」あなたに 欠乏の行動経済学 - hitode909の日記
リソースが足りない状態の人間について研究した本。そのリソースは時間だったり資金だったりする。 スラック、つまり余裕があることが大事で、100円のおやつとか買うとき、それによって財産が100円減ることを考慮する人は居ない、毎月使えるスラックから支払われることになる。しかし、本当に切羽詰まってると、少しのお金を作るために借金し、次の入金は利子の返済に当てることになる。 人間、気になることがあると、判断に使うためにリソースを奪われていって、能力が下がっていく。貧しい状態の人は生まれ持った能力が低いわけではなく、お金や時間の心配をしていることで能力が下がっていくことが実験によって確かめられている。という本。 現代日本で考えると、テレビに繋いでるレコーダーが残り1時間とか3時間とかで、毎日、次の番組を録画するために、歌まつりを早送りで見続けたり、古いバラエティ番組を消すかどうかで議論したりして時間を
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とらえると， クオリティ→正しく動き，不具合がないほうがよい スピード→(計算時間ではなく)早く作れるほうがよい ということになる． コードレビューでは，不具合を見つけて直してもらったり，動きはしてもコードの可読性に問題があって直してもらったりと，クオリティに目を向けられがちだと思う． ところで，コードレビューとスピードの関わりについて考えてみる．スピードのためにできることはいくつかあり， 早く読み始める→他のことやってても手を止めて読み始めたり，1日のうち決まった時間にレビュータイムを設けたり 速く読む→これはコツとかある*2けど精読しないといけないので難しい 不具合を見逃さない→リリース後とか，リリース直前に正しく動かないことが分かったら大きな手
6年前に書いたCoffeeScriptをES6に変換した - hitode909の日記
昔はCoffeeScript好きで，たのしく書いてて，いまもたのしく書けるのだけど，最近はこういうグッズを使わなくても，ESLintとかFlowとか，安全便利グッズが増えてきているので，Coffeeやめることにした． しばらく運用モードだったのだけど，追加したい機能が出てきたので，Coffeeのままやるよりは，型書けるようにしてからやったほうが安心できそう． やったこと decaffeinate でJSに変換する これで脱出できるってパスタ君に教えてもらった BabelとBrowserify入れる Flow入れた jQueryとunderscoreに依存してたので型定義をダウンロードしてくる ESLint入れた Gulpメリットない感じになってきたので，package.jsonにCLIのコマンドを書いてコンパイルするようにした 型をちょっとずつ書いた 型を書くときに困ったのが，Coffee
レガシーソフトウェア改善ガイド読んだ - hitode909の日記
去年出てた本．レガシーコード改善ガイドとは別の本．アーキテクチャの改善の話． FindBugsとかでメトリクスを取りましょうという話，コードを良くしましょうという話，アーキテクチャを改めましょうという話，どうにもならないのですべて書き直しましょうという話，あたりがおもしろかった．開発環境セットアップやドキュメントの話などもあるけど，そのあたりは普通にやればいいので目新しさはなかった． ちょっとしたテクニックで，こういうときにロジックをViewからViewModelに移すとViewがスッキリして便利，という話が載っていて，ちょうど困っていたところなので，早速チームで議論していて取り入れることにした． どうリファクタリングしてもどうにもならないので完全に書き直す，という話も載っている．リライトの知見を教えてくれるのだけど，それを読んでいると胃が痛くなる． 最初に明らかにしておくが、完全な書き直
テスト書きすぎ問題 - hitode909の日記
テスト書きすぎるとよくないって言ってる人がいた．DHHっていう人．作業時間の1/3以上テストしてたらおかしいとか，ActiveRecordのバリデーションなど，Railsの機能はテストしない，とか． Signals vs. Noiseの去年のエントリに、テストをどれくらい書くべきかということについてDHHが指針を示していたものがあったので... - Sooey 偉い人が言ってるからという理由で，テスト手抜き派の人に良い材料を与えてしまった．僕は意見ちがって，作業時間半分以上はテスト書いたりしてる． テストたくさん書くと，最初に書くときのコストは増える．けど，あとから読む時や，変更したい時には，読むだけだし，書くのも差分だけで良い．コード本体を理解できれば，要らないテスト捨てるのは，落ちたのを消すだけだから簡単．あとで見て，テスト足りないと分かったときに，明文化されてない仕様からテストを補う
BitBarとsparkコマンドで日ごとのエラー数をメニューバーに表示する - hitode909の日記
ふだん開発してるアプリケーションのエラーの様子を見る仕組みを作って，ふだん便利に暮らせているので紹介します． BitBarについて BitBarはメニューバーにいろいろ出せるやつで，コマンドラインの標準出力をそのままメニューバーに表示できる． getbitbar.com プラグインを置くディレクトリが用意されていて，シェルスクリプトを置いていく．calコマンドを呼ぶだけのスクリプトを配置するとこんな感じで，そのままカレンダーが出る． sparkコマンドについて sparkコマンドはコマンドラインでスパークラインを表示するもので，標準入力で数字の列を渡すと，数字の列をグラフにして表示してくれる． 数字を正規化してから渡す必要はなくて，なんでもいいから数字を渡すとその形を教えてくれる． % echo '1 2 3 4 5 6 7 8 9 10' | spark ▁▁▂▃▄▄▅▆▇█ % ech
古いissueをとりあえず閉じる - hitode909の日記
ヤパチーで聞いた話で，古いissueはとりあえずcloseして，やっぱりやるとなったらまたopenする，というのがあった． ノリでKotlin化するというissueを入れたのだけど，テンションが下がってきたので，やめませんかってなってcloseする，とか． これは良いと思って，古いissueは単に古いというだけで価値が減っていきそう． すぐにやらないと困るようなら，古いissueがopenのまま置いてあるということはまずい状況で，そうでなければ，やらなくてもいいということで，openで置いてあるのは邪魔で，次に何をやるべきなのか分からなくなってしまう． また，当時とは状況が変わってきて，実はやらなくてよくなった，みたいなものもある． 誰かが意識的にissueの治安を維持しないと，どんどん増えていって制御できなくなってしまうと思う． ふだん仕事でやってるプロジェクトでは，たまに棚卸しするのだ
好きなLGTM画像を登録できるHubotのLGTMコマンドを作った - hitode909の日記
HubotにLGTMって言うとlgtm.inからランダムなLGTM画像を出してくれるコマンドを使ってたのだけど，最近lgtm.inの仕様が変わって動かなくなってしまった． それはそうとして，lgtm.inからあまりにしょうもない画像が出てきてしょうもない気持ちになるので，良い機会ということでLGTMコマンドを自作することにした． 絵が出る lgtmと言うと絵が出る．デフォルトで，はこべさんのノーチラスポセイドンが出る． 絵を登録できる lgtm register すると画像を登録できる．次にLGTMしたときにランダムに出てくる対象になる． どうぞご利用ください gistに置いてるのでコピペして使いましょう． なにか分からない謎の画像じゃなくて，自作のLGTM画像を使っていくと仕事が楽しくなると思う．どうぞご利用ください． Registerable Hubot LGTM Command ·
なぜひどいコードを書いてはいけないか - hitode909の日記
ひどいコードは何やってるか分からない ひどいコードが何やってるか分かっても、なぜそうなってるのか、そこを変えるとどうなるか分からない ひどいコードは新たな変更に耐えられず書き直されることになる ひどいコードを書き直すには、ひどいコードがどうなっているか理解し、どこを変えるとどうなるのか理解する必要がある ひどいコードはたいていひどいテストコードが支えていて、テストコードがあったとしてもひどいコードと同様の問題があり、頼れるものが何もない どんなにひどいコードでも、書いた人を憎んではいけない。たとえ自分の書いたコードだとしても、先輩の書いたコードだとしても、ソフトウェアとしてひどい物にはひどいと言っていくことが大切で、だからと言って人に向かってひどいと言ってるわけではない。 最高の仲間たちが日々変化する難しい問題に対処していいコードを書いたり、ときにはひどいコードを書いている、という😇的な
Rが変な場所に入ってるときのRStudioの起動方法 - hitode909の日記
% which R /Users/hitode909/homebrew/bin/R % RSTUDIO_WHICH_R=$(which R) open -a RStudiosupport.rstudio.com
bash -eより set -e - hitode909の日記
こういうシェルスクリプトがあるとする． -eしてるので，途中でエラーが出たときには止まってほしい． #!/bin/bash -e echo 1 ehco 2 echo 3 止まってくれ……!! % ./a.sh 1 ./a.sh: line 4: ehco: command not foundちゃんと止まった． ところで，bash ./a.shとか，cat a.sh | bashとかして実行してみると，3まで実行されてしまう!!!． % bash ./a.sh 1 ./a.sh: line 4: ehco: command not found 3 % cat ./a.sh | bash 1 bash: line 4: ehco: command not found 3 こういったことがあってはつらいので，bash -eじゃなくて，set -eしましょう． #!/bin/bash set -
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
