サクサク読めて、アプリ限定の機能も多数！
トップへ戻る
CES 2025
gfx.hatenablog.com
JavaScriptプログラマーのためのTypeScript厳選ガイド という本を書きました。JavaScript中級者でTypeScript初心者のプログラマーに向けたTypeScriptの入門書です。 これまで何度かTypeScriptの記事を書いてきました。 TypeScript再入門 ― 「がんばらないTypeScript」で、JavaScriptを“柔らかい”静的型付き言語に｜ハイクラス転職・求人情報サイト AMBI（アンビ） 「がんばらないTypeScript」のための現実的な設定を考える ─ 4レベルの厳しさを使い分けてTypeScript疲れを克服しよう！｜ハイクラス転職・求人情報サイト AMBI（アンビ） 今回の本は、既存のJavaScriptプロジェクトをTypeScriptに移植するという場面を想定した「がんばらないTypeScript」路線ではなく、TypeScri
FastlyからStarleyに転職しました。Starleyは音声会話型おしゃべりAIアプリ「Cotomo」(コトモ)を開発している会社です。 cotomo.ai StarleyはFastlyとは打って変わってB2Cのスタートアップです。今回の転職ではせっかくなので生成AIに多少なりとも関わりたいと思っていて、Starleyはその点でがっつり生成AIを使ったサービスを開発していて、LLMの自前運用もしています。そして「生成AIで雑談」というのはおそらく技術的にはかなり難しい挑戦で、そこに「ときめき」がありました。 ところで、Fastlyはちょうど5年ほど勤めましたが、このたび大規模レイオフがあってその対象になってしまいました。レイオフの対象になった原因はおそらくこのところパフォーマンスが下がっていたせいです。去年の夏に新型コロナに掛かって以来ずっと体調が悪く*1、ついには2024年の3月か
Rustで作るプログラミング言語という書籍が先日発売されました。簡単なプログラミング言語を作ってバイトコードに変換して実行したりネイティブコードに変換して実行してみよう、という本で、大変面白く読みました。最終的にまあまあ本格的な言語になるので、これを元にするとわりとちゃんとした言語を作れそうです。 この書籍で最終的に作られる言語はこちら: GitHub - msakuta/ruscal: Programming language implementation learning project ちょうど私も、以前から構想していた言語があったので、ちょっと作ってみました。というのも、TypeScriptを設定記述言語としてさまざまなプログラミング言語から使えると便利ではないかとずっと思っていたのです。 この設定言語で複雑なことができる必要はなく、最終的にはJSONに準ずるデータ構造になればよい
デイリーポータルZの新着記事をBlueskyに投稿するbotを作りました。 github.com デイリーポータルZは2024年1月1日から独立した会社になるようですが、状況から察するに実態としては消滅まで秒読みと思われます。インターネットからデイリーポータルZが無くなるのは寂しいので、どこかの企業がスポンサーになってくれることを期待しています。 dailyportalz.jp それはそれとしてBlueskyのボットを作るのは結構楽しいですね！ボットのコードはRustで書きました。GitHub Actionsの定期実行でRSS feedをポーリングして新しいものがあったらポストする、という素朴なプログラムです: bsky.app Bluesky APIへのアクセスはsugyan/atriumを使いました: memo.sugyan.com 投稿の本文をリッチテキストにできたり*1、OGPカー
追記（2023/11/29）: 2023/11/1からまたZaimでアメリカン・エキスプレスとの連携ができなくなりました: （11/2 掲載）アメリカン・エキスプレスの連携不具合について:よくある質問｜家計簿アプリ Zaim。マネーフォワードではできているようです。困惑の極み…。とりあえずZaimのプレミアムプランは解約しました。 最近、我が家の家計のための家計簿アプリを、5年ほど使ったマネーフォワードMEからZaimに乗り換えました。今のところ、機能的には満足しており、かつこれまでできていなかった我が家の家計スタイルに合った家計簿の運用がようやくできるようになったので、大変満足しています。 もともとあった課題として、マネーフォワードMEは我が家の家計スタイルを実装していないというものがありました。我が家の家計スタイルは、別に特殊なものではなく、次のゼクシィの記事の「【2】お互いに、毎月定
次子のために5ヶ月の育休をとった記録です*1。 家族構成は、外資系*2勤務フルタイムワーカーの私、同じく外資系勤務フルタイムワーカーの妻、長子のmfx氏（2017年9月生まれ）、そして次子のrfx氏（2022年6月生まれ）という四人家族です。 私が育児休業をとったのはrfx氏の育児のためです。妻がはrfxの誕生の1ヶ月前から産休に入り、11月いっぱいまで育休をとりました。私は妻と入れ替わるように11月下旬から翌年の4月下旬まで育休をとったため、約5ヶ月間育児休業を取得することになりました。つまり、rfx氏が保育園に入園して慣らし保育が終わるまでの期間を、私たち夫婦で分担して育休をとり、育児に集中することにしたのです。 長子のmfx氏が生まれたときは、私は育休を取得しませんでした。当時は人数が一桁台のスタートアップ企業に勤めていましたが、育休は取ろうと思えば取れたはずです。しかしなんとなく「
3行で キウィフルーツなどのぬめりのある果物を切ったあとは、別の作業に取り掛かるまえに手を洗うべし リンゴなどの硬めの果物を手の上で切るのはハイリスクなので、可能であればまな板を使うべし 切り傷を負ったとき、5分経っても血が止まらなければ即病院へ（行きつけのクリニックでよい）。ナイフによる切り傷はよくあることなので医者も処置に慣れている 詳細 2022年6月に、果物ナイフで左の人差し指をばっさり切って縫合する羽目になりました。抜糸まで10日、その後キーボードをタイピングできるようになるまで数週間、だいたい全治一ヶ月くらいでした。そこからさらに半年ほど経過した今でも縫合痕は残っていますが、日常的にはまったく問題ないくらい回復しました。怪我の場所に意識を集中すると、違和感が多少残っているかな、という程度です。 これは朝キウィフルーツとリンゴをナイフで剥いているときに起こった事故です。この2種の
続き: 40代の男性プログラマーが5ヶ月の育休を取った - Islands in the byte stream 2022年の6月に第二子であるrfxを受け入れました。それに伴い、11月最終週から4月第1週いっぱいまで、約4ヶ月の育休をとることにしました。 第一子であるmfxのときは育休はとらなかったので、はじめての育休です。なんならプログラマーとして働き始めてから十余年、1ヶ月以上休みをとるのは初めてです。 rfxが産まれてからこのかた、認知的に高負荷な状態が続いていて、そのわりには仕事にも全然集中できなくてけっこうしんどい思いをしていたので、ここで育休をとって育児に専念できるようになるのは正直ほっとします。一方で、育休給付金を踏まえても収入が激減すること、4ヶ月の間キャリアを休止することについては不安もあります*1。 とくに収入については結構苦しいところです。育休給付金は雇用保険でまか
Chrome Web Store chrome.google.com 使い方ですが、GitHub PR pageに次のようにCI statusにcheckboxが現れるので、完了通知がほしいCI statusにチェックをつけるだけ。 チェックされたCI statusが完了（success or failure）になると、次のようなデスクトップ通知が出ます。この完了したときの通知をクリックすると該当のGitHub PR pageのタブをアクティブにします。 tab idごとにcheck状態をもっているので、リロードしてもtabごとのcheck状態は維持されます。 現在（v0.9.2）の機能はこれだけです。既知のバグとして、GitHubのPR画面で差分をみたりdiscussionに戻ったりしているとcheckboxが出ないことがありますが、そういう場合はリロードするとcheckboxが出ると思
2021年現在、M1 MacでDockerを使うのが大変という話がちょいちょいあります。 個人的な事情でいうと、私は現在、AMD64 Linuxでしか動かせないソフトウェアを開発していて、Dockerもちょいちょい使う、という感じです。なのでAMD64 MacでVMWareを使ってUbuntu VMを使って開発しています。 一方で、新規で購入できるMacbook ProがM1しかない、デスクトップマシンとしてWindowsやUbuntuを使うことにまだ踏ん切りがつかない（なんだかんだで10年Macで仕事をしてきているので…）ということもあり、どうしたものかと思っていましたが、会社が開発機としてIntel NUCを用意しているというので申請して導入したことで、一気に諸問題が解決しそうだなというところに至りました。 Intel NUCはIntelが作っているmini PCで、サイズ的には幅12
課題編 シェルスクリプトで「あるグローバルな状態を変える操作を行い、その結果をチェックし、状態をもとに戻す」みたいなタスクをするときに「その結果をチェックし」のところでコマンドの終了ステータスを変数に入れて置きたいみたいなことがあります。例えば、次のようなコマンド操作です。 set -e # グローバルな状態を変える操作を行う git merge --no-ff --no-commit $main_branch || true # 結果をチェックしてexit codeを変数に入れる git diff --cached --exit-code --quiet ; code=$? # グローバルな状態をもとに戻す git merge --abort # 上位プロセスに結果を渡す exit $code スクリプト全体には set -e （コマンドが失敗するとシェルスクリプトが即座に終了する）を効
engineer-lab.findy-code.io 詳細は記事を読んでいただきたいのですが、おかげさまで「ICという役割を初めて知った」「自分もIC的な働き方をしたいのだと分かった」という感想が複数みられたので、この記事を書いた甲斐はあったなあと思います。 一方でやや誤解というか説明が不十分だったかなと思うのが、「ICを役割としておいている企業では、ICはプレイヤーのデフォルトの役割である」ということです。Fastlyではそうですし、たぶんICを置いている他の企業でもそうです。ICはスタープレイヤーだけに許された特別な働き方では決してありません。私はIC的に働いてきて今後もICで行きたいと思いますが、ICと管理職（ピープルマネージャ）を行き来するという選択をとってもいいですし、むしろICとピープルマネージャを行き来するほうがICとしての成長に繋がりますよという主張もあります。 ともあれ私
GitHub ActionsからGitHub wikiを更新したいことがたまにあります。たとえば、何かのメトリクスを見やすく整形したものなど、repositoryのデータを何らかの形で加工したドキュメントを作りたいときです。コード生成したmarkdownドキュメントをコミットしてもいいですが、それよりはシンプルで運用が楽です。 今回は、GitHub repoで管理する原稿の文字数（など）を継続的に見れるページを作ると便利かなと思って作りました。自分一人だったらローカルで適当なツールを叩けばいいですが、同repoを見れる編集者にも共有したいとなると独立したページがあるほうが便利ですからね。 リポジトリはこんな感じです。 github.com 基本的には、 actions/checkout を使って "${{ github.repository }}.wiki" をcloneして編集してpus
クリスマスプレゼントで妻からもらったKindle Fire HD 10"が思いの外よくて快適だなという話です。 Kindle Fire HD 10" (amazon.co.jp) これまで電子書籍リーダーとしてはE-InkのKindleをここ数年ずっと使っていて、それはそれで軽量＆電池長持ち＆目に優しい仕様で十分に満足しているのですが、E-Ink端末は画面が小さくて固定レイアウトの書籍がとても読みづらいのです。というか、あまりに読みづらいので買っても読まないし、だんだん買わなくなってきたというのが実情でした。 物理書籍にはペラペラめくりやすいなどのいい面があることは重々承知しているのですが、とにかく物を増やしたくないし、手軽に手に取れる端末とちがって物理書籍を読む心理障壁もだんだん上がってきたなかで、（統計はとってませんが感覚として）電子書籍のほうが読了する率が上がってきていました。ここ数
最近はお仕事で h2olog を開発しています。これはC++で書いたBPF toolsで、H2Oに組み込まれたUSDTが出力するイベントをトレースするためのツールです。 具体的にはこんな感じで使ってH2OプロセスをトレースしてJSON-Linesにして出力します: # QUICを有効にした H2O serverが起動しているとして $ sudo h2olog quic -p "$(pgrep -o h2o)" {"type":"accept","seq":1,"conn":2,"time":1594471121930,"dcid":"9546e6940ebeec5f"} {"type":"crypto-decrypt","seq":2,"conn":2,"time":1594471121930,"pn":0,"decrypted-len":1236} {"type":"quictrace-
追記 (2021年12月): このエントリを書いた当初、1年経過時点では完全に回復しきったとは言い難くて、エディタのフォントサイズを16ptくらいにしていたのですが、3年たってようやく完全回復してフォントサイズを14にしました。長かった…。 アデノウィルスによる流行性角結膜炎という病気がありまして、これに保育園〜子供経由で感染した*1結果、しばらく視力障害になりました。 一年半経過した今はほとんど回復していますが、一番悪いときでメガネをしていても両目ともに視力0.1程度といった様相でした。これは角膜が濁っているので、目を凝らしたり近づけたりしてもはっきり見えたりはしません。この視力だと、ディスプレイを使った仕事はまともにできないし、スマホの文字を読むことすら困難で、日常生活にも支障がありました。この視力障害が重い状態が半年は続いて、そのあと1年くらいかけて徐々に回復したわけですが、けっこう
git tips: git push $remote HEAD で現在のブランチを$remoteにpushできて、コマンドラインでgitを使うときはよく使います。 ところで、この HEAD の実体はファイル（.git/HEAD）なので、ファイルシステムが大文字小文字を無視する（case-insensitive; e.g. macOSのデフォルト）ときは、 git push $remote head でも動いてしまいます。しかしこれを習慣にしていると、大文字小文字を無視しないファイルシステムで動かずハマることがあります（というかまあ、ハマってしばらく悩みました）。普段から HEAD とタイプする習慣にしておくとよいと思います。
最近仕事で h2olog を開発しています (H2O の QUIC 層をトレースしよう | Toru Maesaka) 。これはh2oのUSDT からデータを取り出すBPF toolです。その関係でBPFとかBCCをいろいろ触ったので、BPF toolsの開発に必要なことを書いておきます。 なおBCCまわりはまだ細かいところの作りが荒いので、思わぬトラブルがあるかもしれません。幸いpull-reqのレビュー＆マージもかなり早いので、気になったところはどんどん直していっています。 ToC ToC 開発環境のセットアップ トレース対象のプログラムのdtrace supportを有効にする トレース対象のプログラムのUSDTを確認する 開発する 用語集 BPF BPF module (BPF program) BCC (iovisor/bcc) BPF verifier eBPF USDT bp
追記: ツールはこちらの getkernel がメンテされているのでこちらを使うほうがいいでしょう！ ubuntu用のカーネルをとってくるやつ - w_tl00’s blog Ubuntuなどのディストリは、ディストリに同梱されたカーネルを別のバージョンに差し替えることができます。開発者の視点では、たとえばLinuxのBPFを使ったツールを開発しているときはカーネルのバージョンを本番に合わせたほうがよかったりします。 Ubuntu用のカーネルのパッケージは https://kernel.ubuntu.com/~kernel-ppa/mainline/ のあたりにあって、適切なアーキテクチャのものをダウンロード＆インストールするだけなんですが、ダウンロードするのがわりと面倒くさいのでスクリプトを書きました。 ./get-kernel 4.19.106 などとするとカレントディレクトリにパッケ
フィルターバブル (filter bubble) とは、「インターネットの検索サイトが提供するアルゴリズムが、各ユーザーが見たくないような情報を遮断する機能」（フィルター）のせいで、まるで「泡」（バブル）の中に包まれたように、自分が見たい情報しか見えなくなること。 Wikipedia/フィルターバブル 世界の真の姿をみるためにはフィルターバブルに陥らないようにしなきゃな！と数年前までは思ってたんですが、最近はQoL至上主義に傾いてきて、SNSなどでもミュートをどんどん活用するようになりました。 自分と主義主張が異なるという理由でミュートしたりはしません。また「この話に付き合うのは大変だけど付き合うことによって世界を少しでも良くできる」と思えれば全然いいんです。しかしそうでない場合は議論自体まったくの無駄かもしれません。 どうやっても分かり合えない人たちはいるし、そういう人たちを議論によって
2019年のまとめです。 前半3Qはウェブアプリのバックエンドやフロントエンドを開発し、最終1Qで転職してC言語でHTTPサーバーを開発するという感じに大きく方針を転換した年でした。 転職にあたっては「毎日楽しく開発をしたい」「生涯現役のプログラマーでいたい」というのを基本的な軸として今後のことを考えていて、これから中長期的に投資するのはどういうスキルにするべきかなあと考えた結果です。 また、それはそれとして2017年から子育てをしていて、子供が保育園から風邪をもらってくると私と妻が仕事を休んで世話をし、そうこうしてる間に親（私 or 妻）に風邪がうつってしばらく仕事を休む、といった感じで思うように仕事を進められない1年でもありました（これは2018年からそういう状況）。来年はもうちょい丈夫に過ごせるといいなあと願ってやみません。 あとはざっくり今年書いたブログ記事を眺めると gfx.ha
abstract: https://jsconf.jp/2019/talk/fuji-goro Wasmを触り始めるにはまだ少しはやくて、おそらく2020年にはリリースされるであろうSIMDなどがほしいところです。とはいえ、JSの最適化コンパイラ（スライドではV8のTurboFanにだけ触れていますがほかのJSエンジンでも基本的には同じ傾向なはず）に頼らず安定したパフォーマンスを出せるというのは大きなメリットなので、その方面だと現在の状況でも考慮に値する可能性はあります。 ところでスライドでも触れてますが、eBayのバーコードスキャナ事例は大変興味深いです。 WebAssembly at eBay: A Real-World Use Case ここのエントリでも次のように書かれていて This is sort of expected, as JavaScript can indeed be
2019年9月9日からFastlyに入社しています。勤務地は東京です。今後ともよろしくお願いいたします。 前職の Bit Journey, Inc. では3年ほどKibelaのサーバーサイドやフロントエンドアプリの開発に関わりました。Bit Journey在職中に子供がうまれ、現在も夫婦で分担しながら子育てをしていますが、この子育て初期という大変な時期*1にBit Journeyで気持ちよく働けたのはたいへんな僥倖でした。ここで改めて感謝いたします。 さて、Fastlyは方向性を変えて、ウェブアプリではなくVarnishやH2Oなどのミドルウェアの開発に関わります。 Kibelaは自分が数年のあいだ心血を注ぐにふさわしいサービスでしたし、実際のところ大いに開発を楽しみました。しかし、しばらく今後のキャリアの方向性を考えた結果、かねてから経験してみたいと思っていた低レイヤーなソフトウェア開発
発表の機会をいただきありがとうございました。会場を提供していただいたメルカリさんにも感謝いたします。 「AsssemblyScriptはTypeScriptのサブセットだから実質TypeScriptを書くだけでパフォーマンスアップ！」みたいな言説をみるにつけ、「ええ〜ほんとか〜？？ほんとにやってみて言ってるんか〜？？」と思っていたので、小規模とはいえ実際にやってみて検証＆考察できたのはよかったなあと。 speakerdeck.com 特に、最適化JITの効きずらい状況（たとえばスタートアップタイムの高速化）での高速化に寄与する可能性を示唆できたのは大きな発見です。V8チームの目下の関心事はスタートアップタイムのようですし（ただしJSのダウンロード＆パースなどの時間も含む）、FacebookもHermes Engineという新しいJSエンジンを開発してまでスタートアップタイムを改善しようとし
ちょっとまえに The cost of JavaScript in 2019 · V8 というブログが話題になりました。 このなかで次のように説明している箇所があります: As long as the JSON string is only evaluated once, the JSON.parse approach is much faster compared to the JavaScript object literal, especially for cold loads. （JSON stringを一度しか評価しないのであれば、オブジェクトリテラルよりも JSON.parse のほうがはるかに高速です。コールドロード（サイトの初回アクセス時、何のキャッシュも利用できないケース）では特にそうです。） この巨大なJSONリテラルは、たとえばwebpackの組み込み JSON lo
MessagePackはJSONのようなデータをシリアライズできるbinary formatで、JavaScript実装である msgpack-javascriptを基準で考えると次のような特徴があります: JSONよりencodeもdecodeも少し速い かつ、streaming decodeができるので fetch() のresponseのdecodeの効率がとてもよい とはいえ実用上は「JSONより遅くない」ということのほうが重要ではある binaryを直接扱える これに対してJSONでbinaryを扱うときははbase64などでエンコードする必要がある timestamp型があり、デフォルトではJSのDateにマッピングされる Intl.DateTimeFormatへの入力としてならこれで必要十分 マッピングをあとから変えることはできる 特にバイナリを直接扱えるのはJSONとくらべ
ブラウザ互換性表 (a.k.a. browser matrix) とは、こういうやつです。 ブラウザ互換性表 powered by Sauce Labs TypeScriptで MessagePack encoder/decoder を実装した - Islands in the byte stream で作った msgpack/msgpack-javascript にこのバッジをつけようとして苦労しました。今回は単に一度やってみたかったというのもあって頑張りましたが、いろいろ大変だったので記録を残しておきます。 しかし、どんなプロジェクトでもやるべきかというと微妙で、ブラウザの機能に大きく依存するライブラリでもない限りはバッジは頑張らなくてもいいかなあという結論です。ブラウザに依存した機能をもっと多用するのであれば、バッジの価値があるのかもしれません。 今回はブラウザテストをはじめてから1
npm install @msgpack/msgpack でインスコできます。NodeJS v12 でベンチマークしたかぎり、JSONと同程度の速度で、これまで最速といわれてきた msgpack-lite よりもさらに少しだけ高速です。 github.com もともとこのリポジトリには uupaaさんによる実装（tagged as classic) があったんですが、メンテされなくなって久しく npmjs.com にもリリースされていないという状況でした。 https://github.com/msgpack/msgpack-javascript/tree/classic その後kawanetさんが msgpack-lite を実装したのが2015年。これが2019年現在、もっとも週間ダウンロード数の多いMessagePack for JSの実装です。 msgpack-lite ピュアJa
employment.en-japan.com 「GraphQL」徹底入門 ─ RESTとの比較、API・フロント双方の実装から学ぶ に引き続き、TypeScriptの記事を書きました。 TypeScriptに苦手意識を持っている人に向けて再び触るきっかけを作りたいと考えて書いたので、細かい言語仕様にはまったく触れてませんが、「ああこれならやってみてもいいな」と思ってもらえたら幸いです。
次のページ
このページを最初にブックマークしてみませんか？
『Islands in the byte stream』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く