書評: ISUCONを「ゴール」で終わらせない。『達人が教えるWebパフォーマンスチューニング ～ISUCONから学ぶ高速化の実践』 - その手の平は尻もつかめるさ
達人が教えるWebパフォーマンスチューニング 〜ISUCONから学ぶ高速化の実践 作者:藤原 俊一郎,馬場 俊彰,中西 建登,長野 雅広,金子 達哉,草野 翔技術評論社Amazon 著者のid:catatsuyさんよりご恵投いただきました。ありがとうございます。実は著者の方から本を頂戴するのってはじめてです。 さて、この書籍のタイトルをはじめて見たときは「オッ、ついにISUCONの攻略本が来ましたね、これでワシも優勝間違いなしや！！」と思ったものですが実際に手に取ってみると必ずしもそうではないことに気付きました。むしろ「ISUCONで勝つための小手先のテクニック」のような話題は極力排除されており、高速かつ高可用なWebアプリケーションをどのように構築・運用していくか、というような実戦的な内容がその多くを占めています。 まず書籍の冒頭では「『Webアプリケーションのパフォーマンス』の定義」か
テクノブレーン被害者アドベントカレンダー Day 19 - その手の平は尻もつかめるさ
この記事はテクノブレーン被害者アドベントカレンダーの19日目として書かれています。このアドベントカレンダーは今まさに作りましたから、参加者は自分しかいません。他に被害者がいたら続きを書いておいてください。 この記事は特定の企業に対する苦情および批判が含まれます。お前だ、テクノブレーン。 こんなことが横行していては、「リクルーティング」という職業の価値が著しく毀損されてしまうし、ソフトウェアエンジニアリング産業自体がスポイルされていってしまう。 明確に、俺は強く怒っている。お前たちは「駄目」だ。 TL;DR テクノブレーンは本当に悪質なリクルーティング企業なので使ってはなりません。 テクノブレーンから電話が来ましたか？ 奴らはカモフラージュしてきますが相手をしてはいけません。 テクノブレーンを貴方の所属する企業が採用目的で利用していますか？ こんな邪悪な企業を使っているようでは自身の会社も邪
macOSでDocker Desktopをアンインストールしてdocker-cli + docker-machineで動かすようにする - その手の平は尻もつかめるさ
www.docker.com Docker Desktopがここ最近活発に開発されているというか、かなり見た目がオシャレになってきてて「ヤル気あるな〜」と思って眺めていたのですが、なるほど有料化するということなのですね。 Docker Desktop remains free for personal use, education, non-commercial open source projects, and small businesses (fewer than 250 employees AND less than $10M USD in annual revenue). Commercial use of Docker Desktop in larger enterprises (more than 250 employees OR more than $10 million
awesome-perlのご紹介およびメンテナの大募集 - その手の平は尻もつかめるさ
こんにちは。id:moznionと申します。Hachioji.pmというIT技術コミュニティに所属しています。 本記事はPerl Advent Calendar 2020の記事として記述されています。前日の記事は@mihyaeru21さんのGitHub Actions で Perl を動かすときのテンプレートでした。 Hachioji.pmという名前からわかるように、ここは元来はPerlを書く人が多かったコミュニティなのですが、時代の推移によりPerlを書く人は徐々に少なくなりつつあります。かく言う私自身も、かつてはPerlでそこそこ大規模なWebアプリケーションを書いて糊口を凌いでいましたが、ここ最近は仕事で (というかそこそこ規模の大きなコードを) Perlを書いたことは久しくありません。 Perl Advent Calendarなのになにを突然不敬なことを言い出すのかという感じですが
ネットワーク越しリトライ考 - その手の平は尻もつかめるさ
ここ最近では何らかのインターネットサービスを構築・運用するにあたって、ネットワーク越しのリトライを考えることは避けられなくなりつつあります。 micro services のようなアーキテクチャを採用している場合はサービス間のメッセージのやり取りはまず失敗する前提 (つまりリトライをする前提) で組む必要がありますし、たくさんのクライアントがいてそのクライアントが定期的に何かを処理してセントラルにデータを送ってくる IoT のようなシステムを構築する時もその処理のリトライをよく考える必要があります。 というわけで「ネットワーク越しのリトライ」についてここ最近考えていることをざっくりと書き留めるものであります。 前提 リトライをする側をクライアント、リトライを試みられる側をサーバと呼称します リトライにおいて、サーバおよびネットワークはクライアントよりも弱者です クライアントはリトライをコン
pprof を使って nodejs アプリケーションのプロファイルを取る - その手の平は尻もつかめるさ
pprof って go のやつでしょ？ node のプロファイルが取れるわけ無いやろ，と僕も思っていたんですが以下のライブラリを使うことで取れることがわかりました． github.com 使い方については Using the Profiler に書いてあるとおりで，アプリケーション側に const profile = await pprof.time.profile({ durationMillis: 10000, // time in milliseconds for which to // collect profile. }); const buf = await pprof.encode(profile); fs.writeFile('wall.pb.gz', buf, (err) => { if (err) throw err; }); という風に書いてあげるとwall time
Dockerコンテナ内でpuppeteerを使うとChromeゾンビプロセスがたまる問題 - その手の平は尻もつかめるさ
表題のような問題があり，その調査したという記録です．なお，結論を一言で言うと--initを使え，ということになります． そもそもDockerコンテナを起動すると，CMDあるいはENTRYPOINTに指定されたコマンドがコンテナ内でPID 1として起動します．これが何を意味するかと言うと，「CMDあるいはENTRYPOINTに指定されたコマンド」はそのコマンド自体の責務をまっとうするのと同時に，initプロセスとしての振る舞いも行わなければならないということになります (id:hayajo_77さんにこの辺を詳しく教えてもらいました，ありがとうございます)． つまりPID 1で動いているプロセスは「SIGCHLDをトラップすることで孤児プロセスを適切に回収し，waitpidをかける」という処理も適切に行う必要があります． さて，puppeteerを使ってChromeブラウザを起動するとどうな
#builderscon 2018 tokyoに参加しました & 話してきました - その手の平は尻もつかめるさ
builderscon.io builderscon 2018 tokyoで「Java Cardの世界」というタイトルで話してきました．発表資料は以下のとおりです． 喋りたいトピックはJava Card以外にも様々あったのですが，「知らなかった、を聞く」というカンファレンスのテーマを鑑みた結果，あまり一般には知られていなさそうな *1，しかし身の回りを確かに支えている技術についてお伝えしたいと思い至り今回のような発表をした次第です．この発表で少しでも生活が豊かになってもらえれば望外の喜びであります． さてこの発表はありがたくもベストスピーカー賞第1位を頂戴しまして，感激の極みであります．本当に嬉しい！！！ もちろんこの発表は僕個人の力のみで成し遂げたものではなく，所属しているソラコムの同僚の多大なる協力があって達成したものです．特にJava Cardの偉大な知識を授けてくれたolivier
builderscon tokyo 2018に登壇します - その手の平は尻もつかめるさ
表題の通り，builderscon tokyo 2018に登壇します．JavaCardという環境をテーマにお話する予定です． builderscon.io 今回はかなりマニアックな話になることが現時点で予想されていますが，内容はかなり面白いと思います (先日社内の専門家にディープな講習を受けました)． いつものJavaとは一味違うJavaを目の当たりにすることになるでしょう…… 今回のトークめっちゃ面白いんですけど，「明日から役に立つ！！」みたいなのではなく，海外に行って意味不明なものを見ると面白いみたいな，そういうノリです— 片付けができない (@moznion) 2018年7月12日 国内行って意味不明なものを見ても面白いんですけど— 片付けができない (@moznion) 2018年7月12日 9/7 (金) の15:30からセッション開始ですから，お昼から会場内のHUBで一杯引っ掛
YAPC::Okinawa 2018 Onnasonに行きつつ喋りました - その手の平は尻もつかめるさ
yapcjapan.org 行ってきて，そして喋りました． スライドは以下にあります． speakerdeck.com Perlコードに別の言語のコードを埋め込んで動かしてしまう技術であるところのInlineモジュールの話です．今回のYAPCのテーマは「万国津梁」とのことだったので「じゃあPerlと他の言語をつなげるInlineモジュールの話でもすればよかろう」と短絡的に題材を選択してしまったわけですが，そのままではなかなか「引っ掛かり」が無い話になってしまったため (出オチみたいな感じになった)，色々風呂敷を広げてみました．それはそうとしてnumpyマジで速いですね．それだけ覚えて帰って下さい． 「グルー言語」の部分については碌々調べずにスライドのあるようなことを喋ったわけですが，恐らくこのような点はあるのだろうなと思っています． かつて言語側で頑張らなければならなかったコンポーネント間
私信です - その手の平は尻もつかめるさ
私信ですが転職いたします．以下の通りです． From: LINE To: Soracom 関係各位に感謝を申し上げます．ありがとうございました． 以上です．よろしくお願いします． なお本記事は以下のレギュレーションに従いました． タイトルで煽らない、かしこまった見出しもつけない、ウィッシュリストのせない、東亜飯店張らない、fromとtoを両方書く。職場崩壊を暴露しない。キラキラしない。これが私の求める退職エントリです。— laiso (@laiso) 2017年8月1日 twitter.com [追記] 職場崩壊だとか，ネガティヴな方向に持って行きたがる向きが散見されますが，それらに対する回答は以下の通りです．職場崩壊なんて一切無かったし，本当に良い会社及び同僚でした．これ，キラキラレギュレーションに引っかかりますかね？ まあいいや！ ブクマ100超えたら突然見当違いなことを言って来る人が
Kyoto.なんか #3で「そして物語は更に何度目かのアプリ内通知再実装を迎える」というタイトルで話してきました - その手の平は尻もつかめるさ
kyoto-nanka.connpass.com 「そして物語は更に何度目かのアプリ内通知再実装を迎える」というタイトルで話してきました．スライドは以下です． speakerdeck.com 前回開催のKyoto.なんか #2では「そして物語は何度目かのアプリ内通知再実装を迎える」というタイトルで話したのですが，今回はその後日談 (?) の話をしました． とにかくストレージ周りで苦労をしたくない，そしてできるだけ生に近い状態でデータを取り扱いたい，というモチベーションから，バックエンドのストレージにS3を採用し，RSS (Atom) ファイルをPUT (or PATCH) することで，低い労力でスケーラビリティを確保するというアーキテクチャを提案しました． 実際のS3をバックエンドとしたアプリ通知実装は，個人の趣味アプリでPoC的に実装した程度なので，実際に高い負荷が与えられた時にどうなる
YAPC::Fukuoka Hakata 2017にてWeb Application Good Error Messageというタイトルで話してきました - その手の平は尻もつかめるさ
表題のとおりです．話しました． これは僕が普段の開発中にエラーメッセージと触れあう時に気にしていたり，考えていることを上手いこと言語化したいという試みから始まったものです． speakerdeck.com 発表中にdan kogaiさんから「『間違えたことを言っているエラーメッセージ』も悪いエラーメッセージじゃないのか」というフィードバックを頂いて，確かに！！ と思いました．すっかり抜けていました．おっしゃる通りです． 発表後頂いた質問としては「(セキュリティ的な観点から) エンドユーザ (非開発者) に詳細なエラーメッセージを表示しては駄目な場合とかがあると思うんだけど，そこらへんどうしてるのか」というものがあったんですが，回答としましては: 技術的に詳細なエラーメッセージはエンドユーザに提供しない エラーが出ている場合，エンドユーザに技術的詳細を提供しても基本的に対処不可能 (多くの場
YAPC::Kansai 2017 OSAKAで喋ってきました - その手の平は尻もつかめるさ
タイトルは「Webアプリケーションのキャッシュ戦略とそのパターン 」です． speakerdeck.com 告知で書いたように，ここ1・2年は規模感のあるWebアプリケーションを開発していて，なおかつキャッシュ周りの設計・開発・運用をモリモリやっていたので，その関連で学んだこと，感じたことをまとめて発表したという感じです．聞きに来てくださった皆さんありがとうございます．内容についてはスライドをご覧いただければご理解頂けるかと存じます． ところでトーク中に言い忘れたこととして，「ランキングの構造を返すJSON」みたいなものはえてして大きくなりがち，かつランキングをバッチで構築している場合は或る単位時間内に変化することが少ない (あるいは無い) ので Cache-Control を付けてJSONを返してしまうと負荷が大きく下がって便利，みたいな話題もありました．しっかりした原稿を作っていないと
builderscon tokyo 2016で話してきました - その手の平は尻もつかめるさ
去年の話を今するのはどうかという感じですが *1，表題の通りbuilderscon tokyo 2016で話してきました． builderscon.io ビールサーバーを作ったという話です．スライドは以下です． speakerdeck.com 発表ではデモも行ったのですが，サーバから水が一瞬吹き出てしまったり，ソレノイドバルブの機構が上手く動かなかったりと，やはり本番発表のデモには魔物が住んでいるというな〜感じでした．概ね上手く行ったとは思います！ *2 今更ですが他の発表の感想など． builderscon.io ちょっと遅れて行ったのですが，mattnさんの変態的なモチベーションの話が聞けて楽しかった．Vimで動画を再生するデモで聴衆が大きくどよめいていたのが印象的．Windowsパッチでは日頃お世話になっております． builderscon.io 変態的な話かと思ったら果たして変態的
そして物語は何度目かのアプリ内通知再実装を迎える - その手の平は尻もつかめるさ
というタイトルでKyoto.なんか #2で発表してきました． そして物語は何度目かのアプリ内通知再実装を迎える / Reimplement in app notification // Speaker Deck スライドの内容としては，アプリ内通知 (Twitter appで言うところの「通知」タブにあたる部分) のサーバサイドを実装する際にどういう問題があって，それをどういう風に実装したかという葛藤の記録となっています． Webアプリケーションやスマートフォンアプリケーションを書いていると，そこそこの確率でアプリ内通知を書くことになると思うんですが，ところがどっこい「実際にどういう風に実装しているか」みたいな知見が共有されている感じがあまりありません．みんな実装しているはずなのに，ググってもあまり情報が出てこなくて寂しい．地味な機能だから？ という思いがあり，そこら辺アプリ内通知周辺の技
開発に使えるダミーのマイナンバーについて - その手の平は尻もつかめるさ
ところでマイナンバー使うシステム作る羽目になった場合、ダミーに使える絶対に重複しないマイナンバーとかってあるんですか？— 画力の高まり (@moznion) 2016年3月7日 テストのために開発者のマイナンバーがハードコードされて起こる悲劇— 画力の高まり (@moznion) 2016年3月7日 ダミーのマイナンバー、よく考えたら「マイナンバーの見本」みたいな画像に記載されてる番号つかえば良いのか— 画力の高まり (@moznion) 2016年3月7日 というわけでこれです (オリジナル: https://www.kojinbango-card.go.jp/, https://www.kojinbango-card.go.jp/shared/images/header/main_img.jpg) 1234 5678 9012 がダミーとして使えることがこの度わかりました．良かった良か
GitHub のリポジトリページにアクセスするだけで自動的に git clone される Chrome 拡張書いた - その手の平は尻もつかめるさ
GitHub のリポジトリページにアクセスするだけでローカルに git clone される Chrome 拡張を書きました．ggc という略称になりますが，まあなんかこれ紛らわしいですね． なぜこんなものが必要になったかというと GitHub のリポジトリ内検索は割と結果がひどくて，手元に clone してきてから grep なりなんなりをかけた方が必要なものを得られる可能性が極めて高い，というのがあるためです． そんでもっていちいち clone するっつうのもダルいので，それだったらブラウザでリポジトリのページにアクセスした瞬間に自動的に clone すればいいじゃーん，もう2015年なのでストレージとか気にせず豪快にいこうやガッハッハ，という方法に id:s5r 氏と話していて辿り着いたのでそれを実装したというのが経緯になります． Chrome 拡張を名乗っていますが，実態は Chro
相手の GitHub の ID さえ知っていれば暗号化したメッセージを送れる naisho というのを作った - その手の平は尻もつかめるさ
色々な事情があり，秘密のメッセージを送り合う必要性が今年に入ってから多数発生していて， そのたびに毎度毎度手で暗号化して〜みたいな風にやるのめんどいですね，そうですね， ということでこの度 naisho というものをこさえました．みんなには内緒ですよ． これは何かと言うと，やりとりしたい相手の GitHub の ID を指定するだけで その ID のユーザの ssh-rsa の公開鍵を引っ張ってきて その ID のユーザのメールアドレスを引っ張ってきて そのメールアドレスに対して公開鍵で暗号化したメッセージを添付ファイルにしてメールで送りつける という動きをするコマンドです． golang で書きたかったというのと golang で書くと便利なのではと思ったので golang で書いてあります． Wercker で Go のプロジェクトをクロスコンパイルし、GitHub にリリースする -
実行中のプログラムの進捗度を手っ取り早く確認したい - その手の平は尻もつかめるさ
完了するまでに結構時間がかかるプログラムを実行している時，そのプログラムの進捗度を確認したくなることがままあると思います．ほんとに動いてんのかお前，みたいな． そうした時に考えうる最も簡単な方法は，こんな感じで進捗度を標準出力に流してしまうという方法でしょう． (1..100).each do |i| # 例えばここで何らかの重い処理をする (下のsleepはその「何らかの処理」の例) sleep 0.1 # ここで進捗を表示 (プログレスバーみたいなもっとリッチな感じでも可) puts "#{i}%" end 簡単なものだとこれで良いでしょうが，途中で端末のセッションが切れると「アッアッ」という感じになったり，そもそもプログラムの実行に際して端末が割り当てられいるとも限らないし，というか時間のかかるプログラムがその処理中ずっと端末を占領しているのはつらいので別の方法が欲しかったりします．
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
