この記事はテクノブレーン被害者アドベントカレンダーの19日目として書かれています。このアドベントカレンダーは今まさに作りましたから、参加者は自分しかいません。他に被害者がいたら続きを書いておいてください。 この記事は特定の企業に対する苦情および批判が含まれます。お前だ、テクノブレーン。 こんなことが横行していては、「リクルーティング」という職業の価値が著しく毀損されてしまうし、ソフトウェアエンジニアリング産業自体がスポイルされていってしまう。 明確に、俺は強く怒っている。お前たちは「駄目」だ。 TL;DR テクノブレーンは本当に悪質なリクルーティング企業なので使ってはなりません。 テクノブレーンから電話が来ましたか？　奴らはカモフラージュしてきますが相手をしてはいけません。 テクノブレーンを貴方の所属する企業が採用目的で利用していますか？ こんな邪悪な企業を使っているようでは自身の会社も邪

なんとなくZigを触っているのですが、ビットシフト演算が独特の挙動で面白かったです。 const n: u8 = 0b00000001; const shifted: u8 = n << 1; std.debug.print("{b}\n", .{shifted}); // => 0b00000010 これは直感的なコードでしょう。n が1バイト左にシフトしています。 さて以下のコードはどうでしょうか。 const n: u8 = 0b00000001; const shifted: u8 = n << 8; std.debug.print("{b}\n", .{shifted}); // expects 0, but... このコードは ./main.zig:5:30: error: integer value 8 cannot be coerced to type 'u3' const

達人が教えるWebパフォーマンスチューニング　〜ISUCONから学ぶ高速化の実践 作者:藤原 俊一郎,馬場 俊彰,中西 建登,長野 雅広,金子 達哉,草野 翔技術評論社Amazon 著者のid:catatsuyさんよりご恵投いただきました。ありがとうございます。実は著者の方から本を頂戴するのってはじめてです。 さて、この書籍のタイトルをはじめて見たときは「オッ、ついにISUCONの攻略本が来ましたね、これでワシも優勝間違いなしや！！」と思ったものですが実際に手に取ってみると必ずしもそうではないことに気付きました。むしろ「ISUCONで勝つための小手先のテクニック」のような話題は極力排除されており、高速かつ高可用なWebアプリケーションをどのように構築・運用していくか、というような実戦的な内容がその多くを占めています。 まず書籍の冒頭では「『Webアプリケーションのパフォーマンス』の定義」か

APIのリクエストにせよレスポンスにせよ、タイムスタンプを利用するというのはよくある話です。 この時、そのタイムスタンプのフォーマットをどうするのが良いのかという話題です。IDLを使って縛るというというのは良い考えだと思いますが、IDLを使うにせよフォーマットについては決めなくてはならないので。 1. 文字列を使う これあんま良くないと思うんですよね……というのも、とあるAPIを触っている時に「タイムスタンプはRFC3339です」というフィールドがあったんですけれどRFC3339ではないフォーマットで返却されたり受け入れられたりしたのであまり信用ができない…… まあフォーマットが不正というのは極端な例かもしれないですが、仮にフォーマットが不正だと多くの場合 strptime() や time.Parse() なんかの時刻文字列のparserが正しく動かず (良いケースだとエラーが上がる、悪

[追記] 実行中のシェルスクリプトをchattr(1)を使ってimmutableにするというのはどうか - その手の平は尻もつかめるさ 調べてみたけどこれが良さそう <a href="https://stackoverflow.com/a/3399850/1921216" target="_blank" rel="noopener nofollow">https://stackoverflow.com/a/3399850/1921216</a>2022/01/02 17:02 b.hatena.ne.jp このブックマークコメントで指摘されましたが、immutableにするまでもなくこのラッパースクリプトを噛ませると良さそう。 #!/bin/bash # usage: # sh-run.sh script-you-want-to-run.sh args... set -ue file="$

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

かなりニッチな話題ですが、OMA LwM2Mのサーバ・クライアントのJava実装であるEclipse Leshanにパッチを送って取りこまれたのでそのご報告です。 github.com Leshanのクライアントライブラリには予期せぬ例外が発生した際にクライアントアプリケーションがスタックし、プロセスは生き続けるものの一切の仕事をしなくなるという問題がありました。 Better handle unexpected error in DefaultRegistrationEngine. · Issue #933 · eclipse/leshan · GitHub 例えば以下のようなコードの箇所でRuntimeExceptionが発生すると、エラーログが記録されるだけで他のエラーハンドリングが成されません。 https://github.com/eclipse/leshan/blob/lesh

ここ最近では何らかのインターネットサービスを構築・運用するにあたって、ネットワーク越しのリトライを考えることは避けられなくなりつつあります。 micro services のようなアーキテクチャを採用している場合はサービス間のメッセージのやり取りはまず失敗する前提 (つまりリトライをする前提) で組む必要がありますし、たくさんのクライアントがいてそのクライアントが定期的に何かを処理してセントラルにデータを送ってくる IoT のようなシステムを構築する時もその処理のリトライをよく考える必要があります。 というわけで「ネットワーク越しのリトライ」についてここ最近考えていることをざっくりと書き留めるものであります。 前提 リトライをする側をクライアント、リトライを試みられる側をサーバと呼称します リトライにおいて、サーバおよびネットワークはクライアントよりも弱者です クライアントはリトライをコン

表題のような問題があり，その調査したという記録です．なお，結論を一言で言うと--initを使え，ということになります． そもそもDockerコンテナを起動すると，CMDあるいはENTRYPOINTに指定されたコマンドがコンテナ内でPID 1として起動します．これが何を意味するかと言うと，「CMDあるいはENTRYPOINTに指定されたコマンド」はそのコマンド自体の責務をまっとうするのと同時に，initプロセスとしての振る舞いも行わなければならないということになります (id:hayajo_77さんにこの辺を詳しく教えてもらいました，ありがとうございます)． つまりPID 1で動いているプロセスは「SIGCHLDをトラップすることで孤児プロセスを適切に回収し，waitpidをかける」という処理も適切に行う必要があります． さて，puppeteerを使ってChromeブラウザを起動するとどうな

[2018-12-05 追記] ビルド済みのLayerを公開しましたので，そちらを使うと便利です． See also: http://moznion.hatenablog.jp/entry/2018/12/05/211523 [追記ここまで] 先日のre:InventでCustom AWS Lambda Runtimesが発表され*1，これはつまり任意の言語でAWS Lambdaを実行することを可能とする機能なんですが，ということはPerl5が動くということでして，すなわち動くと嬉しいはず，したがって動かすためのLayerを書いたという話です． github.com この場合のLayerというのはPerl5を動かすための基盤だと思ってください．基本的にはbootstrapが実際にぐるぐる回ってperlの関数を実行するという感じになっております． どのようにして動いているかは公式のTutor

bitly/oauth2_proxyを用いて，ウェブアプリケーションに手っ取り早くOAuth2認証を導入するという話です． oauth2_proxyは良い感じでOAuth2による認証を肩代わりしてくれる君で，何らかのリバースプロキシの認証機構と組み合わせて利用すると簡単にOAuth2ログインを実現することができます． 今回は例としてKibanaにGoogleのOAuth2ログインを導入してみたいと思います． 構成 Kibana bitly/oauth2_proxy nginx +------+ +-------+ +--------------+ +--------+ | | | | ----auth----> | | | | | user | --request--> | nginx | | oauth2_proxy | <--auth--> | Google | | | | | <--

私信ですが転職いたします．以下の通りです． From: LINE To: Soracom 関係各位に感謝を申し上げます．ありがとうございました． 以上です．よろしくお願いします． なお本記事は以下のレギュレーションに従いました． タイトルで煽らない、かしこまった見出しもつけない、ウィッシュリストのせない、東亜飯店張らない、fromとtoを両方書く。職場崩壊を暴露しない。キラキラしない。これが私の求める退職エントリです。— laiso (@laiso) 2017年8月1日 twitter.com [追記] 職場崩壊だとか，ネガティヴな方向に持って行きたがる向きが散見されますが，それらに対する回答は以下の通りです．職場崩壊なんて一切無かったし，本当に良い会社及び同僚でした．これ，キラキラレギュレーションに引っかかりますかね？ まあいいや！ ブクマ100超えたら突然見当違いなことを言って来る人が

kyoto-nanka.connpass.com 「そして物語は更に何度目かのアプリ内通知再実装を迎える」というタイトルで話してきました．スライドは以下です． speakerdeck.com 前回開催のKyoto.なんか #2では「そして物語は何度目かのアプリ内通知再実装を迎える」というタイトルで話したのですが，今回はその後日談 (?) の話をしました． とにかくストレージ周りで苦労をしたくない，そしてできるだけ生に近い状態でデータを取り扱いたい，というモチベーションから，バックエンドのストレージにS3を採用し，RSS (Atom) ファイルをPUT (or PATCH) することで，低い労力でスケーラビリティを確保するというアーキテクチャを提案しました． 実際のS3をバックエンドとしたアプリ通知実装は，個人の趣味アプリでPoC的に実装した程度なので，実際に高い負荷が与えられた時にどうなる

ところでマイナンバー使うシステム作る羽目になった場合、ダミーに使える絶対に重複しないマイナンバーとかってあるんですか？— 画力の高まり (@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 がダミーとして使えることがこの度わかりました．良かった良か

人間生きていると高確率で連打機能を提供するシステムを構築する必要が出てくることがあります． 例えばあるコンテンツについてボタンを連打することで「良いね」を表明するようなシステムです． 連打は楽しい！！　しかし実装する方としては純粋に楽しんでばかりはいられません． こうしたシステムは素朴に実装したとしてもある程度のトラフィックまでは耐えられるかもしれませんが，ある規模を超えると安定して機能提供する事は難しくなってくるかもしれません． ここでは，サーバサイドの話題を中心として，快適な連打機能を提供するシステムをどうすれば提供できるかを考えていきます (あくまで一例です)． 想定としては， あるコンテンツについてボタンが付いていて，そのボタンは連打が出来る あるコンテンツについてボタンが何回押されたかを取得できる というシステムを仮定します． なんとなく結論が分かる雑な図 本題 サーバを分離する

色々な事情があり，秘密のメッセージを送り合う必要性が今年に入ってから多数発生していて， そのたびに毎度毎度手で暗号化して〜みたいな風にやるのめんどいですね，そうですね， ということでこの度 naisho というものをこさえました．みんなには内緒ですよ． これは何かと言うと，やりとりしたい相手の GitHub の ID を指定するだけで その ID のユーザの ssh-rsa の公開鍵を引っ張ってきて その ID のユーザのメールアドレスを引っ張ってきて そのメールアドレスに対して公開鍵で暗号化したメッセージを添付ファイルにしてメールで送りつける という動きをするコマンドです． golang で書きたかったというのと golang で書くと便利なのではと思ったので golang で書いてあります． Wercker で Go のプロジェクトをクロスコンパイルし、GitHub にリリースする -

そういえば昨日「ピクシブ株式会社」って言おうとして3回くらい噛んだ気がする— プリントゴッコ (@moznion) 2014, 7月 5 ページャNight，僕が当初想定していたよりも1000倍位有益な会になって本当に嬉しかったです．あとで記事等書きます．— プリントゴッコ (@moznion) 2014, 7月 5 録画したustの様子はこちら http://www.ustream.tv/recorded/49544381 ページャNight <[1]> on Zusaarというイベントを開催致しました． 実に冗談みたいな理由から興ったイベントでしたが，ページャ (ページネーション) というWebサービスの1コンポーネントに焦点を絞った非常に濃厚かつ興味深いトークの数々を聞くことができて，非常に良い勉強会になったと思います． 以下，発表の一覧です． 15分トーク @mizchiさん お前