今週の初めくらいからちょっとずつTerraformを触っていて、といっても1日30分とか1時間くらいで手探り状態だけど、今のところの理解のメモ。 AWS CDKとなにがちがうか CDKはCloudFormationのYAMLを生成するためのもので、TypeScript, Pythonに対応していて、TypeScriptならTypeScriptの補完が使える TerraformはHCL(HashiCorp Configuration Language)という言語であって、補完はHCL用に開発されたものが動く VSCode拡張が乱立していて、HashiCorp製の拡張はインストール数は多く評価は低い、という謎な状況 AWS CDKはAWSだけど、Terraformは汎用的なものなので、GitHubのorgの管理とかもできる CloudFormationとの違い 既存のプログラミング言語のなかで

社内のScrapboxで雑誌を共有する試みをした。 共通の蔵書が可視化されておもしろいけど、オープンすぎる気もするのでインターネットに公開するのははばかられそうで、仲間うちで共有するくらいなら便利そう。 「この本読んでません」「私もです」みたいな会話のきっかけになる。 Kindle Cloud ReaderのWeb SQL Databaseから蔵書を作る手法を見て、蔵書をハッシュタグにしてScrapboxに流し込んだら共通の蔵書で繋がれるかと試したらはてしない雰囲気になったhttps://t.co/oHcjYAJnUE pic.twitter.com/1dZ5xHtCzJ— 趣味はマリンスポーツです (@hitode909) 2020年7月8日 蔵書共有、新たなメンバーが現れて共通の蔵書が可視化された pic.twitter.com/HW8ZVeifVx— 趣味はマリンスポーツです (@h

計測結果をインセンティブに結びつけるとハックされてしまうという本。 科学実験とかなら計測するのは有益だけど、対象が人間の営みとかだと、指標とする数字を上げるための操作が可能になってしまう。学校において、テストの平均点を上げるために、点数の悪い生徒を障害児として別のグループに入れる、とか、医療現場において、手術成功率を上げるために、リスクのある手術をしない、とか、厳しい事例が紹介されている。 短期的な目標が報酬に紐付いていると売上を追い求めて値上げし続けて信頼を失ったりする、指揮官は固定給に切り替えている事例もある、という話も載っていた。 我が社では半年ごとに目標を決めて、今期はこれをやりましょうってやっているけど、上の方の人の目線も一律で半年後で売上を追い求めている、というよりは、もうちょっと先を見据えて、一喜一憂したり数字をハックしたりせずに暮らせるようになっている方がよさそう。 たとえ

こういうSlackのカスタム絵文字があるとして、背景が透過されているのでダークモードを使っていると黒背景に黒文字になってしまい見えない。 透過部分に白いシャドウを入れられるとよくて、ImageMagickを使うと1コマンドでシャドウを入れることができる。 convert original.png \ \( +clone -background white -shadow 100x8+0+0 \) \ -background none -compose DstOver -flatten -compose Over \ out.pngドキュメント的にはこのあたり。暇なときにImageMagickのUsageをひたすら見ておくと、これImageMagickのUsageで見たやつだと進研ゼミ的に思い出せて便利。 Bluring and Sharpening -- IM v6 Examples 白い

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

Slackやissueで質問がきたら Scrapboxで検索して みつかったらページを案内 みつからなかったらその場でページを書いて案内 さらに疑問点とかあったらScrapboxを見ながら話して、その場で書いていく と言うことをよくやっている。 この動きを続けるとトラブルシュートしてるだけで知識がストックになっていって便利なはず。 聞かれた質問をそのままページにするのではなくて、タイトルは一般的な単語で書くようにしている。「アクセスログはどこにでていますか?」じゃなくて「アクセスログ」のページで、ログの在り処を説明する。そうすると他のページからもリンクしやすい。 逆に、一人だけが持ってる情報をみつけたら、ページだけ作って、ページを作ったので説明を書いてもらえませんか、というお願いをしたりしている。#誰か書いて というタグをつけておくと、書きたい人が書いてくれる、というのを試したりしている。

三点見積もりでもやってみるか、という話になって、id:onkさんにおすすめされたので読んだ。PERT、Program Evaluation and Review Techniqueについて教えてくれる本。1965年の初版が電子書籍化されていておもしろい。 読んでたら、こんなの大学の授業でやったなってだんだん思い出してきた。 PERTは各タスクの依存関係をグラフにしたもので、見積もり時間を持っているもの。ガントチャートと違って、各タスクの依存関係や、遅れたときに全体に影響がある箇所や、余裕がある工程がどこなのかを可視化できる。 ja.wikipedia.org 以下は読書メモ ネットワークは関係者が集まって描く。お互いの意見を出し合って最高のプランがネットワークとしてまとまるのが良い点 見積もりトータルフロートが0であるパスがクリティカルパス。そのパス以外はフロートがあり、早くやっても仕方な

どういう流れだったか忘れたけど、フロントエンドの開発がこれから複雑になるか簡単になるかという話をしていた 個人的には簡単になって、というか、複雑さがブラウザに隠蔽されて、複雑なJS書かなくてもことたりるようになってきてほしい input elementのtypeが増えてきたことでカラーピッカーを実装しなくても済むようになった portals elementとか登場すれば、HTMLを書くだけで快適なナビゲーションが可能になる https://blog.uskay.io/article/002-hands-on-portals 現代ではサイトに訪問する前に検索結果ページで内容を読めたり、スマートスピーカーに聞いたら教えてくれたりするので、サイトに来た人にリッチな体験を提供するよりは、検索エンジンが理解できるマークアップであるとか、スマートスピーカーに読み上げてもらえるメタデータとかを用意してい

丸一日、金のことを考えていて、寝る直前までクレジットカードの手数料について調べてそのまま気絶、朝起きたらカレーを食べてふたたび金の心配をする、という暮らしになっていて、金のことで頭がおかしくなってしまったと感じる。 昨日見たアンベール城の話をしている時間より、ここで買ったこのおみやげは適正価格じゃなかったとか、いらないのに買ってしまったとか、トータルで見ると高かったとか、もっと交渉しなければならないとか、値切るというのが相手を信用してないということではないかと感じてしまいつらいとか、金銭面への不満について話す時間が圧倒的に長い。すべての思い出を金が打ち消していく。 ブログだからこんな話をしているのではなくて、夫婦間の話も完全に金の話になってしまった。 このままではいけないので一度振り返りをしましょうと、カスタマージャーニーマップを書いて、いつどんなことをしたらどんな感情になったか、これまで

ブログに困っていることを書いていけばインターネットの全世界の仲間たちからアドバイスを貰えると思って書いてみます。 会社で、いまエンジニアとして複数のチームに所属していたり、シニアエンジニアをやっているので人々と1on1をしたり、採用系の仕事もちょっとやっている。 開発系の仕事を2つ持っていると切り替えやスケジューリングが難しい チームAの仕事とチームBの開発系の仕事どっちをどういう順序でやるか難しくて困っていて、時間の使い方としてはこのような配分でいきましょう、という話はしていても、たとえば、金曜だけぱちっと切り替わるとか、午前中だけ切り替わる、みたいなことをするのが難しい。 ソフトウェアを作る仕事は、これまで誰も考えたことがないものを作る仕事で、そうでなければすでに完成品のソフトウェアがあるはずなので、集中が必要で、正しく作らないと正しく動かないので、間違いは許されない。そういうものを複

突然シェルのhistoryが消えてめっちゃつらかった。学生の頃に、漢のzshという連載を見て、シェルのヒストリは無限に大きくすべしというプラクティスを実践していた。それ以来、10年間くらい育ててきたけど、今朝見たら突然15KBになっていた。偶然Dropboxに残ってるのを復元したけど、直近5年分くらい消えてしまった。数ヶ月ぶりにTimeMachineのディスクをつないでみたらそもそも認識されなくて、ディスクごと壊れてるようだった。バックアップはリストアできないと意味ない。 思うのが、シェルの履歴という形で各自が有用なコマンドを保持していて、消えて困っているのがおかしい。リポジトリごとにhistory置き場となるウェブサービスを作ってどんどんpushしていくような形とか、エディタのランチャから起動するだけで開発が完結するとか、現代的な形は考えられると思う。昔はsshですばやくサーバーに接続し

ある日zshの履歴が消えた悲しみからいくつか課題感を持っていた。 巨大な1ファイルにどんどん書いていくので、壊れたときの影響が大きい 追記方式なので、複数の端末で共有するためGitやDropboxなどに入れるとコンフリクトしやすい 履歴から取り出すときにどのディレクトリで実行したコマンドなのかわからない シェル履歴をファイルに書いて終わりという暮らしは数十年変わっていない。 履歴はクラウドサーバーに保存して、補完したいときにAPI経由で問い合わせるというアーキテクチャが良いと思ったので、作ってみた。 github.com コマンドの実行時 zshのフックを使って、コマンドの実行時に、実行したコマンドと$pwdをAPIにPOSTする Cloud Functionsが立っていて、送られたコマンドをCloud Datastoreに保存する Cloud FunctionsはGoogle製のAWS

偶然暇だったら出ましょうということでid:takuya-aとid:shiba_yu36とチームを組んで出た．チーム名は「ディメンジョナルハイソサイエティぬれねずみ」で，サークル名ジェネレータで決めた．僕は3回目で過去2回は予選敗退，二人は初参加． www.doujinbu.com 準備 事前準備はだいたいしばゆーがやってくれて助かった 最初はGoでやるかって言ってたけど慣れたPerlになった．練習する時間はないので，ぶっつけ本番で問題の質によって言語を決めようという話をしていた デプロイはrsyncで 初参加の年はソフトウェア工学を重視しCircleCIが通ったら自動デプロイしていた これが最悪で，急いで手で書き換えてデプロイしたら自動デプロイが走ってロールバックされたり，ベンチマーク実行中にデプロイされたり 去年はrsyncでデプロイしていて，コミットする前にデプロイしてうまくいったらコ

コメントで質問もらったので回答 デバイス いろんな端末でどこでも読めるようにすると便利で，数分単位でも細切れに読めると進んでいく． 普段は7インチのタブレットで読んでます 漫画を読むために買ったやつ フルHD出せると解像度的には気にならない SNSにはログインせず通知も全部切ってある 防水のカバーも買ってあって風呂でも読めるようにしている ちょっとした移動のときには5インチの携帯で読んでます IIJmioがキャンペーンしてて買ったやつ 評論とか文字メインの本なら読みやすい 図のある技術書だとしんどいけど，今こうして文字を目にしているということは読み進めることができるみたいなことを考えてがんばって読む Kindleは何度か買ったけどいずれも使わなくなりました e-inkの反応が遅いのがつらい 携帯は充電するだろうけど用途の限られたデバイスはバッテリーなくなりがち タブレットもたまに電池切れて

ふだんの開発では，稼働中のシステムに影響を与えないように開発中の新機能や新システムを共存させながらちょっとずつデプロイして進めている．どんな事を考えてやっているか記しておきます． フィーチャートグルを使う すべてのコードが本番環境に入っているけど無効化されている状態で開発を進める ブランチをたくさん作るのに対する考え方で，フラグを有効にすると開発中の機能を使える スタッフなら有効にしたり，フィーチャーのオンオフを選べる画面を作ってたこともある フィーチャーブランチを利用した開発はチームを継続的インテグレーションから遠ざける – ゆびてく FeatureToggle 完成したらフィーチャートグルに関係なく全員に有効状態にして完成 フロントエンドの施策で，実際のデータやインフラ構成でどれくらいスピードが出るかわからないときに，ひとまずフラグをオンにすると動く形でデプロイしたりとか レイヤの下の

ほしい機能がなくて，どういう作戦でやれば動くかなって話してるときに，死滅すればいいって言われるのはすさまじい体験だと思って，記録しておきたい． VSCodeのデバッガが便利なのでDocker環境上のPerlでも使いたい，助けてください - hitode909の日記 Perl とかはやく死滅すればいい。2018/08/26 01:03 b.hatena.ne.jp 足りないものは諦めるんじゃなくて作るマインドで暮らしていて，VSCodeで動くperl用の拡張を作ったり，無いライブラリは作ったりしている． 死滅させるにしても，すでにPerlで動いているアプリケーションを安全に止めるには，開発環境が整ってないと難しいので，デバッガは動かす必要がある． 追記 議論が進んでいる エディタのデバッガの話をしていたらPerl死滅すればいいって言われる体験 - hitode909の日記 「Perl とかは

プレゼンモード 再生 ← / →で移動 fでフルスクリーン escでおわる id:hitode909です．Kyoto.なんか #4 に飛び入りでLTするための資料です． VSCode拡張を作ろう ここ2ヶ月くらい早起きして作っている 友達作りのため様子を紹介 自己紹介 はてなで働いている Emacs→Atom→VSCode 練習 祝日を挿入するコマンド gyazo.com const holidayList = "元日 成人の日 建国記念の日 春分の日 昭和の日 憲法記念日 みどりの日 こどもの日 海の日 山の日 敬老の日 秋分の日 体育の日 文化の日 勤労感謝の日 天皇誕生日 元日 成人の日 建国記念の日 建国記念の日 振替休日 春分の日 昭和の日 昭和の日 振替休日 憲法記念日 みどりの日 こどもの日 海の日 山の日 敬老の日 秋分の日 秋分の日 振替休日 体育の日 文化の日 勤労感謝

プレゼンモード 再生 ← / →で移動 fでフルスクリーン escでおわる こんにちは，id:hitode909です．はてな・ペパボ技術大会 #4 〜DevOps〜 @京都において，「社内横断で開発効率を上げる取り組み」というお題で発表しています．この記事は，その発表資料です． 社内横断で開発効率を上げる取り組み はてな・ペパボ技術大会 #4 〜DevOps〜 @京都 hitode909 自己紹介 hitode909 株式会社はてな アプリケーションエンジニア 好きな本はオブジェクト指向入門とドメイン駆動設計 2009年〜 うごメモチーム 2012年〜 ブログチーム 2017年〜 マンガチーム 2018年〜 CTO室(兼務) アジェンダ CTO室での活動 特定のチームに閉じず，社内横断で開発効率を上げるための試み みなさん 学生の方? 🙌 社会人の方? 🙌 Devの方? 🙌 Opsの

会社のオフィスは東京と京都に分かれていて，それぞれ，さらに7F，8F，9Fとか，B1，3F，4F，のように3フロアずつに分かれているので，合計6フロアあることになる．それに加えてリモートの人たちは家にいる． 定時後に，お疲れ様でしたとか言ってビールや日本酒をあけることがあるのだけど，他のフロアでワイワイやってても気付きにくく，駆け付きにくい，駆け付けてもらいにくい，という問題がある． そこで，AWSのIoTボタンを使って人を呼べるようにした． 張り紙 このビールを冷やしてる冷蔵庫付近の壁に張り紙を貼った． 使い方 この乱雑な紙に使い方と，IoTボタンを貼り付けている．IoTボタンはボタンの裏側が接着面になっていて，ドキュメントに貼り付けることができて便利． 開催 1回押すと，Slackの#drinkingnow(飲み会の様子を共有するチャンネル)に飲み会開催中のお知らせが流れる．これが流れ

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 作