Chrome仕事術 - 詩と創作・思索のひろば
いろいろ工夫した結果、最近 Chrome さばきが良くなってきた気がするので、やっていることを書いておく。 タブが必要になる時刻でグループ化しておく 忙しい一日の予定を立てる際に、あらかじめ必要な資料・会場をタブで開いて時刻を打っておくと便利。終わったらまとめて閉じることもできる。 Chromeのタブを必要になる時刻でグループ化しておくライフハック pic.twitter.com/P8RQLy7h9K— 美顔器 (@motemen) 2022年8月22日 ページのブックマークタイトルを自分用に変更する ブラウザのブックマークはあまり有効活用してなかったけど、タイトルを自分用につけておくとロケーションバーからの検索に便利なことを体感している。<プレフィクス> | <検索用ワード>, ... という感じでタイトルを設定していて、プレフィクスは ミーティングの議事録など会場: mtg 1on1
3Dアバターに話を聞いてもらう - 詩と創作・思索のひろば
近年、世間ではリモートでスピーチをする機会が増加している。人前で喋ったことがあると経験があるのではないかと思うけど、テレビ会議ごしに話をすると目線が合わない、そもそも顔が見えないなどで反応がものすごく薄い。だんだんと慣れてきた感もあるけどやっぱり喋りづらい。技術による人間の疎外、これは仕方がないことですよ。 そうであれば解決するのも技術だ、というわけで作ってみたのがこちら（マイクの権限が必要です）。ブラウザの中から誰かがこちらを見てくれていて、話にうなずいてくれる。ただそれだけ。だけど、多数に向けたスピーチの際にうなずいてくれる人間の貴重さを知っている人には、このありがたさに共感してくれるのではないだろうか。 Vnodroid pixiv/three-vrm を使って3Dアバターヒューマノイドをブラウザ上に表示し、あたかもそこで自分の話を聞いているかのように存在させている。呼吸とまばたきを
DevTools上でesbuildするChrome拡張を書いた - 詩と創作・思索のひろば
社内ではドキュメントの共有に Scrapbox が活発に使われており、するといきおい UserCSS や UserScript もさかんである。具体的には、/customize という共有のプロジェクトがあってみんなの自慢の装飾やカスタマイズが共有されている。これを個々人で import して使うんである。 こんな感じ。 自分の場合は /motemen/UserCSS/common に常に適用したいスタイルを書いておいて各プロジェクトから読み込んでいる。このページからさらに、共有プロジェクトや他人の個人プロジェクトページからよさそうな設定を import している次第。 つまりは多段インポート。こういうことを続けていると、だんだんと読み込みの遅さが気になってくる。こういうのはバンドルすればいいのだけど、巷のツールを普通に使うことはできない。インポートしてるリソースに認証がかかっているからだ
ISUCON9予選敗退（H::W::A::Abyss::Abyss::Abyss） #isucon - 詩と創作・思索のひろば
ISUCON9 2日目結果と本選出場者決定のお知らせ : ISUCON公式Blog 日曜日に行われたISUCON9予選に参加し、敗退してきました。前掲の記事の「失格となったチーム」がわたしたちです。チームメンバーは id:t_kyt と id:mechairoi。 去年も予選敗退していて、最近LINE本社に行ってないな～と思っていたので今年は勝ちたかった。今年もはてな京都オフィスで予選に参加。 事前の作戦が大事なので、「コミュニケーションが大切」「マニュアルを読む」を確認した。 だいたいハマり出すとコミュニケーションが減ったり同じことをやりだしたりしてチームとしての効率が下がってしまうので、一時間ごとにタイマーを鳴らしてそこで話そう、という作戦を立てていた。あとは alp と pprof と pt-query-digest でボトルネックを見ていくというシンプルな戦略。 あと、1日目の結果
作業ログと履歴をシンプルに共有できる furoshiki ってツールを書いた - 詩と創作・思索のひろば
おはようございます。この記事ははてなエンジニアアドベントカレンダー2017の25日目の記事です。昨日は id:alpicola さんによる 社内で機械学習ハッカソンを開催しました でした。 サービスのデプロイをはじめとして、チーム内の開発者が共通して担当すべき業務というのはさまざまに存在し、基本的に定型化されているものですが、開発者が手元で実行するなど自動化までは行えていないような場合、以下のような点が問題になります。 作業履歴が共有されない 同様に作業中に意図しない不具合が生じた場合、エラーログが実行した環境にしか残らない それぞれ、デプロイのタイミングを Mackerel や Slack に投稿して共有する、Gist にエラー時のログを貼るなど、チームに合わせた方法が存在していることと思います。また作業環境を同一にするため、チームにデプロイサーバを用意して作業はそこで行う、という方法も
prchecklist でリリース Pull Request のチェックフローをスムーズに行う - 詩と創作・思索のひろば
背景 GitHub を使った開発では、 master ブランチがいつでも本番に出せる状態として、 master から切った develop ブランチを開発のベースとし、 各フィーチャは develop から切って develop にマージし、 リリースのタイミングで develop を master にマージ、リリース ……という流れを pull request ベースで行うのがよくあるパターンのひとつだと思います。リリースの際、ステージングや QA という名前のついた本番前環境でそれぞれの機能が正しく動いているか確認するのもよくあるフローです。 このチェックを pull request 本文のチェックボックスを使って行おう、というアイデアを実装したのが git-pr-release で、もともと id:hitode909 がチーム向けにこしらえたものをパクった汎用化したものでした。この仕
直感的なグラフを簡単に作れるウェブアプリ - 詩と創作・思索のひろば
を作った。どうぞご利用ください。 The Beautiful Graph Maker 下の画像のようなグラフを簡単に生成できます。🙁 から 😊 になったことがひと目でわかりますね。説得力もあるのではないでしょうか。 矢印やY軸のラベルはクリックで変更できます。 実装には Elm を使ってみた。アーキテクチャが強制されるせいか、予想以上に書きやすかった。prompt() したいだけのところが妙に面倒で window.prompt() in Elm を参考に JavaScript も書くはめになった。あと画像ダウンロードのとこも生 JS です……。 GitHub - motemen/beautiful-graph-maker
なぜプレゼンで失敗するのか - 詩と創作・思索のひろば
自分も大方の人間と同じように人前で喋るのは苦手で、可能であれば避けたいと思っているけれど、一方でこの業界で生きのこる方法のひとつとして避けられないものでもあると思っている（ので苦しい）。若かりしころ手痛い失敗をしたこともあって、かなり苦手意識を持ちつづけていたが、最近はわりかし上手く付き合えるようになってきたかなとふり返って思う。 今もうまいプレゼンテーションをする方法は知らないし、それを僕から知りたいという人はいないとおもうが、プレゼンでしくじる方法なら経験から知っている。準備をしないこと。自分の経験からはそうだし、まずいプレゼンを見ていてもそうなんだろうな、と思うことはやっぱり多い。 このエントリはプレゼンがいやでいやで仕方がなかった自分のための分析であり、プレゼンのマイナスレベルをゼロまで引き上げようとする努力です。ソフトウェアエンジニアの技術者間交流のためのプレゼンというのが前提。
はてなの3代目CTOに就任しました - 詩と創作・思索のひろば
はてな退職の辞 - stanaka's blog にある通り、id:stanaka の引退に伴い、2016年8月1日付で私の勤務する株式会社はてなのCTOに就任いたしました。初代のはてなCTOが id:naoya でしたので、3代目のCTOということになります。 はてなで働きはじめたのは2006年、アルバイトの学生としてでした。まだはてなの本社が東京にあったころの話です。もともとはてなはユーザとして使っていて、すごいエンジニアが面白いものを作っている憧れの会社だったのを覚えています。入社すると社内で使っているグループウェア（はてなグループ）のメンバーにしてもらいましたが、そのグループ日記やキーワードにそれまでのはてなのサービスづくりにまつわる議論ほかもろもろのログが残っていて、全てにアクセスすることができたのは印象に強く残る経験でした。 はてなが京都に本社を移転した2008年より正社員とし
OAuth2 のフローを Alloy Analyzer でモデリングする - 詩と創作・思索のひろば
趣味でウェブの認証 API を地力で設計しようとしていたときに、認証フローの仕様を頑張ってこしらえたとして、その正しさをどうやって保証するんだろう？ と疑問に思い、調べていたところ、「形式手法」というのに行き当たった。 形式手法というのはシステムの正しさを上流工程から検証するための方法で、数理論理やロジックに基づいている。その中でも厳密な仕様定義を求める方向と自動検証を求める方向とあるらしいが、Alloy はその後者に位置づけられ、軽量形式手法と呼ばれるもののひとつだということらしい。Alloy はモデリングのための言語および実行環境で、以下のホームページから入手できる。 http://alloy.mit.edu/alloy/ インターネット上にチュートリアルやマニュアルもあるが、作者による教科書の邦訳が出ていて、これで勉強してみた。 抽象によるソフトウェア設計−Alloyではじめる形式手
リスクを直視しないという罪:『熊とワルツを』 - 詩と創作・思索のひろば
ウィッシュリストに入れてたのを同僚が贈ってくれた。 熊とワルツを リスクを愉しむプロジェクト管理 作者: トムデマルコ,ティモシーリスター出版社/メーカー: 日経BP社発売日: 2013/09/12メディア: Kindle版この商品を含むブログ (4件) を見る リスクのあることを知りながら何もアクションをおこさないことは罪である……といったエピソードからこの本は始まるのだけど、もうこの言葉だけで重要なことはほとんど言ってしまっているような感すらあった。自分が今までしてきたのこれは罪だったんだ！ と知らされる衝撃があった。いわゆる罪の文化というのもあるのかなと感じる。 もちろんこのことは導入であって、より詳細に、 リスクとは何なのか リスク管理をする理由・しない理由 リスク管理の方法 といった話がメインの内容として続く。 リスクとは何なのか この本では、リスクとは顕在化する前の問題であり、
2015年に作ったもの20点（セルフレビューつき） - 詩と創作・思索のひろば
いちおう振り返っておかないと 2016 年を迎えられないという心持ちになったので、全部ではないけど列挙する。また、作ってブログに書いたけど自分では使ってません、というのも無責任なので、現在自分で利用中かどうかも添える。 go-typeswitch-gen (Go、コマンドラインツール) Pocket Expose（Go、ウェブサービス） gore（Go、コマンドラインツール） goquickfix（Go、コマンドラインツール） lgtm.sh（シェルスクリプト） hub-pr（Go、コマンドラインツール） go-cli（Go、ライブラリ） google-apps-script.d.ts（TypeScript、型定義ファイル） Mackerel API でホスト名を補完（いろいろ） gobump（Go、コマンドラインツール） Goの簡易ベンダリングシェルスクリプト（シェルスクリプト） go-
任意の入力を human-readable にする humr ってツールを書いた - 詩と創作・思索のひろば
Web サーバのアクセスログを tail してながめている時にパーセントエンコーディングされた文字列をデコードしたり、コマンドラインで数字を sort -n したあとにでかい数字を丸めて表示したり（"1234567" を "1.2M" に、とか）したくなることが多かったので、その辺を汎用的におこなってくれる humr というツールを書きました。 npm でインストールできます: npm install -g humr 簡単に動きを確認するには、以下のコマンドを試してみてください: % echo '/search?q=%E6%97%A5%E6%9C%AC%E8%AA%9E 1234567' | humr 入力のうち読みづらいところが色付きで変換されて出力されたことが分かります。冒頭に書いたようにログなどの入力をパイプしてご利用ください。 仕組み humr は入力を Parser によって各行
ISUCON5 本選に参加して7位に終わりました #isucon - 詩と創作・思索のひろば
表題のとおり、ハロウィンの夜ゾンビ化した渋谷の街でヒカリエに取り残された俺たちは、ISUCON5本戦に参加してきました。 予選はこちらをご覧ください: motemen.hatenablog.com チームは id:wtatsuru （たつる先生）と id:ichirin2501 （いちりんちゃん）とで組んだ「2nd Party Cookies」。 結果は上記のように7位。8万点台に乗らなければ勝負に絡んだと言えず、一時は7万台まで伸ばしていただけに悔しい結果となりました。以下、当日やったことをふり返ります。 初動 開始時刻になってサーバにアクセスできるようになると、wtatsuru が諸々のセットアップをしているあいだにアプリケーションの挙動をチェック。マイクロサービスを使ったウェブサービスで、ユーザの登録情報から複数の HTTP API を叩いて画面に表示する、というものでした。 データ
はてなMackerelチームの開発フロー（スクラム、リモート）について話しました #nanapi_study #hatenatech - 詩と創作・思索のひろば
nanapi勉強会 vol4 - 【nanapi x はてな】はてなとnanapiの開発フロー - nanapi勉強会 | Doorkeeper 【nanapi x はてな】はてなとnanapiの開発フロー in Kyoto - connpass nanapi さんとはてなで開催した勉強会に登壇し、東京・京都で Mackerel チームの開発フローについて話してきました。自慢できるようなカッコイイことをやっているわけではないけれど、今こんな風に頑張っています、ということをお話したつもりです。 Workflow at Hatena Mackerel Team // Speaker Deck チームみんなで勉強する スクラムの導入時もリモートワーク開始時にも、チームメンバーには何冊か本を読んで予習しておいてもらいました。そうすることでチームメンバー全員が同じだけの知識を持って（全員その道に関し
まだmechanizeで消耗してるの? WebDriverで銀行をスクレイピング（ProtractorとWebdriverIOを例に） - 詩と創作・思索のひろば
今日はスクレイピングの話をします。 今回のターゲットは三菱東京UFJダイレクト。金融機関もウェブサービスを提供するようになり、金にまつわる情報を電子化しやすくなりましたが、かれらが API を提供しているわけではないので、私たちのほうで取得・加工をしてやる必要があります。今やウェブサイトであれば当然のように JavaScript を使っているわけなので、いわゆる mechanize、つまり HTML の解釈をおこない、リンクのクリックやフォームの送信をシンプルに実装するようなやり方でのスクレイピングはすでに無理筋だといえます。 もちろん今日においてはブラウザオートメーションという方法がすでにありますので、これを利用してやれば、なんの憂いもなく実際に人間が使うようなブラウザをプログラマティックに操作することができます。現在は Selenium WebDriver がデファクトで、これが使用す
スーパーハッカーの夢を諦め、普通自動車免許を取得しました - 詩と創作・思索のひろば
photo by Thomas Hawk 表題の通りです。実のところ、もう一年も前のことになります。 優秀なエンジニアの多くが自動車免許を所持していないことは有名な事実です[要出典]。私も彼らに憧れ、免許を持たずに生活していましたが、歳を取るにつれ「自分はスーパーハッカーにはなれない」と次第に実感してきたこと、新たな自分に変身したい、という思いと、あまりに暇でヤケになった気持ちから思い立って自動車学校に入学したのが一昨年の年末です。会社に通いながらの教習でしたが、週末と早退・遅刻を活用することで、半年かけて免許を獲得しました。当時のチームメイトに感謝。 すべてを終え、保有者サイドに堕ちてしまった私からそうでないあなた方に伝えられることは……「初心者マークの車に近づくな」。いち歩行者しかなかった頃は車であればどれも同じやろと考えていましたが、運転する側になると全然違う。初心者マークの車は生ま
はてなブログについた訂正コメントを適用する JavaScript パーツ - 詩と創作・思索のひろば
記事に typo があったとき、見知らぬ人に「s/荻原雪歩/萩原雪歩/」などといったコメントを書き残されることがありますが、それをいちいち適用するのも面倒なので、そのような形の訂正コメントをそのまま記事本文に適用するスクリプトを書きました。この記事でも有効になっています（何が起きるのか分からないと思うので、下部の「例文」をご覧ください）。 設置方法 デザイン編集画面 の「フッタ」部など HTML が書けるところに、以下の内容を貼り付けるだけでインストール完了です。 <script src="http://motemen.github.io/hatenablog-scripts/auto-apply-correction-comments/auto-apply-correction-comments.js"></script> 場所はこのへんですね。 リポジトリ https://github
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
めかぬか - 詩と創作・思索のひろば
デスノート1話感想（ネタバレあり） - 詩と創作・思索のひろば
