所属変更のお知らせ - その手の平は尻もつかめるさ
2024年4月1日より id:moznion の所属が以下の通り変更となります。 旧: 株式会社ソラコム 新: ソフトバンク株式会社 (SB Intuitions株式会社出向) 以上となります。 引き続きよろしくお願い申し上げます。 ソラコムには大体6年半くらいいて、実際数えきれないほどたくさんのものを作り、たくさんのものを直し、たくさんのとりくみをしました。なおかつ最後の2年はUSのシアトル駐在で働いていたということもあり非常に貴重な体験となりました。あと在米中にCTO Technical Advisorという迫力のあるタイトルがついたりもしました。 僕がソラコムに入った日はちょうどKDDIがソラコムを買収した2017年9月1日で、そして先日2024年3月26日にソラコムがIPOを成し、ちょうどそのタイミングで退職するということとなり、つまり上場と共に去る男と相成りました。これはソラコム
#yapcjapan YAPC::Kyoto 2023に行ってきた・喋ってきた - その手の平は尻もつかめるさ
yapcjapan.org 2023年3月19日に開催されたYAPC::Kyoto 2023に参加してきました。もう2週間も前の話になるんですね......USに戻ってきてから色々あり、すっかりブログを書くのが遅くなってしまいました。 YAPC::Kyotoの様々な感想については「にゃんこ酒場.fm」で id:papix、id:karupanerura さんら運営の方々と喋ったPodcastが公開されているので是非お聴きくださいませ！ nyanco-sakaba-fm.hatenablog.com 面白かったトーク ジョブキューシステムFireworqのアーキテクチャ設計と運用時のベストプラクティス id:tarao さんの発表。Fireworqが発表されたあたりって、スケーラビリティが高くなおかつ複数の言語から良い感じで使えるジョブキューのプロダクトについて「何使えば良いんだろうねえ」っ
テクノブレーン被害者アドベントカレンダー 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
ネットワーク越しリトライ考 - その手の平は尻もつかめるさ
ここ最近では何らかのインターネットサービスを構築・運用するにあたって、ネットワーク越しのリトライを考えることは避けられなくなりつつあります。 micro services のようなアーキテクチャを採用している場合はサービス間のメッセージのやり取りはまず失敗する前提 (つまりリトライをする前提) で組む必要がありますし、たくさんのクライアントがいてそのクライアントが定期的に何かを処理してセントラルにデータを送ってくる IoT のようなシステムを構築する時もその処理のリトライをよく考える必要があります。 というわけで「ネットワーク越しのリトライ」についてここ最近考えていることをざっくりと書き留めるものであります。 前提 リトライをする側をクライアント、リトライを試みられる側をサーバと呼称します リトライにおいて、サーバおよびネットワークはクライアントよりも弱者です クライアントはリトライをコン
aws-lambda-perl5-layer 書いた - その手の平は尻もつかめるさ
[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
Linux Kernel 4.12以前であればhostマシンのsysctlの値がDocker container環境に引き継がれるかどうか検証した - その手の平は尻もつかめるさ
Docker - IPVS connection timeout issue これを読んでいたところ From Linux kernel 4.13 onwards, sysctl default values can be modified per container basis. Container will not inherit changes from the host sysctl modified values. とあったので，逆にhostマシンのLinux Kernelが4.12以前であればhostマシンのsysctlの値がDocker containerに引き継がれるのか？ と思い検証してみました． TL;DR (手元の環境で試してみた限り) 引き継がれなかった 変なことを考えず，おとなしくdocker run の --sysctl オプションを使おう！！ Amazon E
Kyoto.なんか #4で最近運用しているJenkinsの情報について発表してきました - その手の平は尻もつかめるさ
[2020-09-07追記] この構成，もうウチではやってません！！！！ moznion.hatenadiary.com [追記ここまで] kyoto-nanka.connpass.com 表題の通り，最近AWS上で運用しているスケールする & 運用が省エネなJenkinsについて発表してきました． 簡単にまとめると JenkinsのslaveをAWS CodeBuildに委譲することで実質無限のスケールアウトとメンテコスト削減を実現 JenkinsのストレージをAmazon EFSにすることでロバスト性と自動ボリューム拡張を実現 ElasticBeanstalk with Dockerを使って運用することで運用コストの省力化 という内容です． 会場やインターネットで質問されたことについては以下のとおりです: 値段的には従来のサービスを使うよりも下がったかどうか？ 試算的には下がっている
GitHub releasesのフィードを購読する - その手の平は尻もつかめるさ
生きているとOSSのライブラリを使ったり，OSSのソフトウェアを使用することになるでしょう． そうなってくると内部実装や変更点を逐一知りたくなるというのが人情というものです． GitHubでコードが公開されているのであれば，「リポジトリをwatchする」というのは有効な方法に思えますが，しかしwatchしているリポジトリが増えてくると現状のGitHubのタイムラインは即座に崩壊し，容易に取りこぼしが生じてしまうでしょう．これはGitHubのタイムラインの問題の一つだと思っていて，なんとかなって欲しい点はあります (例えばタイムラインを分割できるとか……)． というわけでどうするか．もちろんAtomフィードです． https://github.com/{author}/{repos}/releases.atom と指定してやると当該repositoryのGitHub releasesをAto
PerlのYAMLライブラリ性能比較 - その手の平は尻もつかめるさ
なんと2018年の記事です．皆様無事明けられておりますでしょうか． さてYAML::XSには2017年に色々と変更が入り，実用するにあたり非常に便利な機能が色々と導入されました (具体的に言うと，$YAML::XS::LoadBlessedと$YAML::XS::Booleanです)．また安定化が図られました *1． というわけで個人的に，最近PerlでYAMLをserialize/deserializeするにあたってはYAML::XSを使うことが多くなってきたわけですが，そこでふと各YAMLライブラリの性能について気になったのでベンチマークを取ってみたという次第です．以下はその記録です． 追記 最近はYAML::PPもオススメな気がします。— Shoichi Kaji (@shoichikaji) 2018年1月18日 とのことでしたので，YAML::PPについても記載しました． ベンチ
手っ取り早くウェブアプリケーションにOAuth2認証を導入する - その手の平は尻もつかめるさ
bitly/oauth2_proxyを用いて，ウェブアプリケーションに手っ取り早くOAuth2認証を導入するという話です． oauth2_proxyは良い感じでOAuth2による認証を肩代わりしてくれる君で，何らかのリバースプロキシの認証機構と組み合わせて利用すると簡単にOAuth2ログインを実現することができます． 今回は例としてKibanaにGoogleのOAuth2ログインを導入してみたいと思います． 構成 Kibana bitly/oauth2_proxy nginx +------+ +-------+ +--------------+ +--------+ | | | | ----auth----> | | | | | user | --request--> | nginx | | oauth2_proxy | <--auth--> | Google | | | | | <--
相手のサーバにHTTP(S)で接続できるかどうかを確認するときにリトライしながらやりたいんですけどって時 - その手の平は尻もつかめるさ
例えばCIでテストのためのストレージのコンテナを上げる際，そのストレージが上がりきるまで待たなければテストには使えないわけですが「上がりきるまで何秒待てばよいのか」というのは一概に決められるものではありません． そうした際，実際にストレージに対してHTTP(S)のリクエストを投げてみて，繋がったら「上がりきった」とみなして処理を次に進めるというようなことがよく書かれます．そういった要件を満たす為には接続に失敗したらリトライをしつつ一定回数試行するという処理を書かなくてはなりません． つまりはそういう話です． wgetの場合 retry-connrefused tries waitretry を利用すると出来る． retry-connrefused が無いと connection refusedに対応できずにリトライが不可能となるので，今回のような要件を満足するためには付ける必要があります．
Karabiner-Elementsでcolonとsemicolonを入れ替える - その手の平は尻もつかめるさ
[追記] コメントで指摘がありましたが，Karabiner-ElementsのGUI上で complex modifications → Add rule → import more rules from the Internet → Exchange semicolon and colon を選択することで所望の動作の実現が可能なようです． 従って本記事はcolonとsemicolonを入れ替えるというよりも，任意のキーを入れ替える時のためのtipsとなります． [追記ここまで] MacのUSキーボードの話です． Karabinerにはcolonとsemicolonを入れ替えるという項目があり，これが大変便利だったのですが (特にvimを使っているときとかに便利)，Karabiner-Elementsではこのオプションがありません．現時点では，macOS Sierra上だとKarabin
社内でDDD勉強会をやった - その手の平は尻もつかめるさ
DDD (Domain Driven Design/ドメイン駆動設計) についての学習気運があり，その勉強会を社内でやったのでその経過を記すものです． DDDに関する詳細な内容には触れません (良い本や資料が巷には溢れています)．読書会自体をどうやったか的な話です． 前提 developer.hatenastaff.com 基本的にこのスタイルを真似しました． 読んだ本 エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践) 作者: エリック・エヴァンス,今関剛,和智右桂,牧野祐子出版社/メーカー: 翔泳社発売日: 2011/04/09メディア: 大型本購入: 19人 クリック: 1,360回この商品を含むブログ (131件) を見る 実践ドメイン駆動設計 作者: ヴァーン・ヴァーノン出版社/メーカー: 翔泳社発売日: 2015/03
私信です - その手の平は尻もつかめるさ
私信ですが転職いたします．以下の通りです． 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::Kansai 2017 OSAKAで喋ってきました - その手の平は尻もつかめるさ
タイトルは「Webアプリケーションのキャッシュ戦略とそのパターン 」です． speakerdeck.com 告知で書いたように，ここ1・2年は規模感のあるWebアプリケーションを開発していて，なおかつキャッシュ周りの設計・開発・運用をモリモリやっていたので，その関連で学んだこと，感じたことをまとめて発表したという感じです．聞きに来てくださった皆さんありがとうございます．内容についてはスライドをご覧いただければご理解頂けるかと存じます． ところでトーク中に言い忘れたこととして，「ランキングの構造を返すJSON」みたいなものはえてして大きくなりがち，かつランキングをバッチで構築している場合は或る単位時間内に変化することが少ない (あるいは無い) ので Cache-Control を付けてJSONを返してしまうと負荷が大きく下がって便利，みたいな話題もありました．しっかりした原稿を作っていないと
linenotcatというツールを書いた - その手の平は尻もつかめるさ
LINE Notifyが便利でよく使っています．LINE Notifyが何かとか何が便利なのかとかをご存じない方は コマンドラインから LINE にメッセージを送れる LINE Notify « LINE Engineers' Blog を読んでいただければと思いますが，あえてものすごくざっくり説明するとim.kayacのLINE版みたいなやつです． んで，Slackというやつも便利で，こちらはチャットツールなわけですが，そのSlackにはslackcatというこれまた便利なコマンドラインツールがあり，これはコマンドを叩くだけで任意のSlackのchannelに対してメッセージやファイルの中身を送ることが出来ます．その名の通りcatコマンドの結果がSlackに流れるという感じ． というわけでそのLINE Notify版を作ったという話です．コマンドライン経由でLINE Notifyにメッセ
ソフトウェアライセンスのURLが軒並みhttpsが使えた - その手の平は尻もつかめるさ
READMEだとかLICENSEファイルだとかに書くソフトウェアライセンスの文言には，そのライセンスのURLが含まれていることが多いと思う． 最近ソフトウェアライセンス文言をめちゃめちゃ書く事があって，その時にふと「ライセンスのURLは軒並みhttpで表記されてるけど実はhttpsでいけるんじゃないのか？」と思ってざっくり調べたら色々なライセンスがhttpsのコンテンツを提供していることがわかった．全部書くと大変なので一部だけれどこんな感じ． https://www.apache.org/licenses/ - APACHE LICENSE, VERSION 2.0 https://www.gnu.org/licenses/ - GPL https://www.mozilla.org/en-US/MPL/2.0/ - MPL https://www.eclipse.org/org/docu
そして物語は何度目かのアプリ内通知再実装を迎える - その手の平は尻もつかめるさ
というタイトルでKyoto.なんか #2で発表してきました． そして物語は何度目かのアプリ内通知再実装を迎える / Reimplement in app notification // Speaker Deck スライドの内容としては，アプリ内通知 (Twitter appで言うところの「通知」タブにあたる部分) のサーバサイドを実装する際にどういう問題があって，それをどういう風に実装したかという葛藤の記録となっています． Webアプリケーションやスマートフォンアプリケーションを書いていると，そこそこの確率でアプリ内通知を書くことになると思うんですが，ところがどっこい「実際にどういう風に実装しているか」みたいな知見が共有されている感じがあまりありません．みんな実装しているはずなのに，ググってもあまり情報が出てこなくて寂しい．地味な機能だから？ という思いがあり，そこら辺アプリ内通知周辺の技
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
