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

IE11で動かしたいコードでelement.prepend()してたら怒ってほしい ライブラリを使っていたらブラウザ間の差異を気にする必要があまりないけど、最近開発しているプロダクトではDOMのAPIを直接触っているので、このメソッドIEにもあるんだっけ、呼んでいいんだっけ、というのをレビューで確認したりしていて苦労していた。 過去にうっかり呼んでしまったメソッドについてはpolyfillが入っていたりして、appendのpolyfillは入ってるけどprependのpolyfillは入っていないためにIE11でエラーになる、ということが起き得る。 ブラウザ間の差異をlintしてくれるグッズとして、eslint-plugin-compatというeslint pluginがあって、fetch使えませんよ、とか発見してエラーとして報告してくれる。 便利なのだけど、たとえばelement.pre

ThoughtWorksの人たちの本．普段遭遇しているような問題がまさに書いてあって面白かった． ユーザーはビッグバンリリースを望んでいる > ユーザーは定期的に現れる新機能の弾幕を望んでいない． 独自のフレームワーク，インフラを作ってしまい，その後オープンソースで同じことができるようになっても固執して移行しない githubのscientist GitHub - github/scientist: A Ruby library for carefully refactoring critical paths. 新旧二種類のコードを書いておく，メトリクスを収集して，安全に置換可能か調べられる > より良いアプリケーションを構築する上でイノベーションを起こす代わりに，彼らは配管の中であくせくずっと働いていた． マイクロサービスのサービステンプレートの話 マイクロサービスはコードを共通しなくて

チームでどうやって活躍するか、まだイメージがついてない、振られた仕事をやっているだけで、仕事をしている間は忙しいけど、確認待ちになるとすぐ暇になってしまう、というメンバーの悩みを聞いていた。 巨大なチーム、巨大なプロダクトだと、すぐに全容を把握するのは難しい。その中で、この範囲なら触れています、任せてください、という庭を作るとよいのでは、という話をした。 思いつきで話したわりには意外といいことを言ってるなと思ったので掘り下げて書いてみます。 庭とは 現代では、庭のある家に住んでる人は少ないかもしれない。うちは実家が田舎だったので庭があって、ボールを蹴って回ったり、石をめくってアリを観察したり、隣の家の庭との境界もゆるくて、冒険と言って隣の家の庭で遊んだりしていた。 大人になってからの庭というと、池袋で遊んでた人が「池袋は俺の庭」と言ったり、JR新宿駅の東口を出たら椎名林檎の庭があることが知

企業が謝罪文などを公開するときに、謝罪文を画像として公開して、テキストで済むのにわざわざ画像にしているのは、検索避けする意図があり、不誠実な態度なのでは、といって怒られるということがよくある。 CSSでdirectionをrtlにして、その中での文字は逆順に書くことで、テキストとして選択できるけど検索されないかたちで、検索避けできるのではないか。 この茶碗蒸しを作りすぎたことを詫びる文は文字を逆順に書いていきCSSで右から左に並べて構成している。 。すまげ上し申礼御く厚り賜を配高ごの別格は素平 、いましてぎすり作をし蒸碗茶、はびたのこ 。たしでんせまいざご訳し申に誠、しけかおを惑迷ご <p style="text-align: left;direction: rtl; unicode-bidi: bidi-override;"> 。すまげ上し申礼御く厚り賜を配高ごの別格は素平<br> 、い

1月のKyoto.JSの休憩時間にMIDIコントローラとWeb MIDI APIでVJできるとよさそうって話になったので買ってみて、ちょっとずつ触ってみた。過去に作ったツールをMIDI対応する、とか、MIDIの入力に応じて絵を出す、という使いみちに加えて、既存のページにコードを差し込んでエフェクトをかけるのを作ってみた。 Scrapboxにエフェクトをかける Scrapboxのプロジェクトのトップページには四角いカードが並んでいるので、これをパーティクルとみなして毎フレーム見た目を書き換えると愉快なビジュアルを出せると考えた。 MIDIコントローラで操作するために、動きのパターンを座標、大きさ、色、背景、ページ全体の変形、などチャンネルがいくつかに整理して、縦フェーダーでエフェクトの種類がかわり、各チャンネルに対応するつまみでエフェクトの掛かり具合が変わるようにした。 こういう構造があって

最近Portal Elementの様子を見たりしていて、今日は#portals_studyに話しに行く。あと30人参加できるので来てください。 web-study.connpass.com 適当に触れる砂場としてこのブログを使っていて、ヘッダのインターン来てくれバナーも実はPortal対応している。対応ブラウザで見てください。 はてなブログの記事はカードとして貼れるようになっているけど、サービスとしての対応がなくても、JS/CSSを書ければカード的なものを作れるはずと思っていたのでやってみた。 この何の変哲もないブログ記事のカード部分がportalになっている。 頭痛(8) - hitode909の日記 貼られる側の対応 デザイン編集画面でJSやCSSを書いて用意しておく。 window.portalHostが真ならdocument.body.classListにportalクラスを足す

ICカードを首から下げて、パーカーに紐もついていると、邪魔で仕方ない。顔洗うときにもピロピロなったり、ラーメン食べるときにすすったりして邪魔。 頭が十分に小さければ、紐を絞って良いフィット感を得られるけど、幸いにも顔がでかいので絞ったことなく、パーカーの紐が役に立ったことがない。 と思ったのでパーカーの紐全部捨てた。人に会ったときにも、パーカーの紐要らないんじゃないの、役立ったことないでしょ、ってマウンティングしている。 #パーカーの紐を捨てる pic.twitter.com/xaIcYs1BMS— 趣味はマリンスポーツです (@hitode909) 2019年3月9日 #パーカーの紐を捨てる pic.twitter.com/PECsJK7Ui9— 趣味はマリンスポーツです (@hitode909) 2019年3月9日 #パーカーの紐を捨てる pic.twitter.com/4yflvJU

リソースが足りない状態の人間について研究した本。そのリソースは時間だったり資金だったりする。 スラック、つまり余裕があることが大事で、100円のおやつとか買うとき、それによって財産が100円減ることを考慮する人は居ない、毎月使えるスラックから支払われることになる。しかし、本当に切羽詰まってると、少しのお金を作るために借金し、次の入金は利子の返済に当てることになる。 人間、気になることがあると、判断に使うためにリソースを奪われていって、能力が下がっていく。貧しい状態の人は生まれ持った能力が低いわけではなく、お金や時間の心配をしていることで能力が下がっていくことが実験によって確かめられている。という本。 現代日本で考えると、テレビに繋いでるレコーダーが残り1時間とか3時間とかで、毎日、次の番組を録画するために、歌まつりを早送りで見続けたり、古いバラエティ番組を消すかどうかで議論したりして時間を

いま社員エンジニアが何人かに加えてエンジニアアルバイト2人、くらいのチームで働いていて、その中でアルバイト氏のメンターもやっている。 前のチームでも何年かアルバイトの面倒を見たり、何回かインターンのメンターをやったりしていた。 手癖でいろんなことをやってしまっていて、属人性が高まってしまっていると感じたので、どんなことをやっているか書いておく。 1日に何回か口頭で会話する 実装ができててから方針がまずかった、となると時間がもったいない 方針書いたくらいでレビュー依頼に出してね、とお願いしてもやってもらうの難しいので、こちらから聞きに行くほうがうまくいきやすい レビュー依頼になったらすぐに見る 社員は明日も要るけど、アルバイト氏は週に数回しか来ないので、その日帰るまでにレビュー完了して打ち返しもしてもらえるように動けると良い レビュー依頼になってなくてもPull Request見に行く 方針

心斎橋で食べたカレーがめっちゃうまかった。ビーフカレーはこれまでのカレー人生を更新した。カレーが美味いだけでなく、肉もうまい。鶏肉とかよくギュッとなってるけど、この牛肉は脂身が溢れ出てくる感じ。ヨーグルトも効いてて、出てきた脂がうまいったなった瞬間に酸味と調和され、そんななか米はバスマティライスで、情報量が多くてめっちゃうまい。関西圏の人は必ず行ってください。ランチのカレーあいがけ1000円です。 アリーズ キッチン （ALI'S KITCHEN） - 心斎橋/パキスタン料理 [食べログ] めちゃうまい

ImageMagickのリサイズまわりの挙動を調べてたら異常なアニメーションGIFが掲載されいているのを発見して，その瞬間に調べ物はどうでもよくなった． 領域が狭くなると，文字が帽子の上に周りこんでいる． http://www.imagemagick.org/Usage/resize/#liquid-rescale Seam carving(liquird rescale)は画像のなかで自然に切り取れるところを探してリサイズする技術．物がないところを探して切り詰めるので物だけが残る． Seam carving - Wikipedia ImageMagickをliblqrつきでインストールすると使えるようになる． brew install imagemagick --with-liblqrオライリーの書影とか見るからに縮めやすくてめちゃくちゃ楽しいのでは?と思ったので練習． Docker 作

Webフロントエンドハイパフォーマンスチューニングを読んだ．最近フロントエンドでがんばるアプリケーションを作ってるので参考になった．ネットワークまわりからブラウザの細かい実装の話まで書かれていて良かった． link rel=prerenderで次のページをプリレンダリングできる 次のエピソードに飛ぶとか，コメントページからメインページに飛ぶとか，次に遷移するページが明確なときは有効そう あとからJSで足してもよい CSSのマッチ方法，div>div>span とか書くと右から左に順にマッチしていく なので入れ子をやめると速くなる．BEMでCSSを書くとネストせず書くので速い デベロッパツールでレンダリングの様子をこまごま見れる ペイントが発生した様子 レイヤの様子 ためしに，このブログのaboutページをプリレンダリングしておいたので，下のリンクから遷移するとすばやく遷移できるはず． <l

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