はてなブックマーク

一般書編の続きです。 blog-dry.com 毎年恒例ですが、本を横に置きつつもまあまあ記憶に頼って書いている箇所があります。なので、事実誤認は少なからず含まれる可能性が高いです。また、Amazonアソシエイトリンクが付与されているので、苦手な方はご自身で再度URLを編集するか検索し直してください。 印象に残った技術書 スタッフエンジニアへの道 エンジニアリング統括責任者の手引き ソフトウェアアーキテクトのための意思決定術 Managing Technical Debt APIデザインパターン 達人に学ぶSQL徹底指南書 NewSQL徹底入門 原論文から解き明かす生成AI 積んでるけど紹介したいもの ドメイン駆動設計と結合 単に積んでる まとめ 印象に残った技術書 といっても、個別具体の技術を今年一年はあまり深められませんでした。というのもなんだか組織や人をリードするようになってしまい、

覚えてたのでやります。 blog-dry.com 前提として、macOSです。 エディタ Neovimを使っています。仕事ではKotlinを使用しています。KotlinのLanguage Serverは登場しましたが、相変わらずまだ安定的に使える状態にはないのでKotlinを書くときだけ仕方なくIntelliJを使っています。ちなみに別にIntelliJに強い不満があるわけではなく、がんばってlazygitをfloating windowで開かせてそれっぽい動作をさせるなどの涙ぐましいカスタマイズをしています。 なお今年は一瞬Rustのコードレビューなどをする時間を仕事で得たのですが、Neovim上で全部完結できて、これだよこれとなりました。 コーディングエージェント 2025年版の記事を書いた時点でまさか世の中がこうなると思ってもみませんでしたが、2025年時点で私もすでにコーディング周

NewSQLというキーワードを最近よく聞くようになってきました。TiDBはその代表格で、私の所属する会社でもよくその動向に関する情報が共有されています。最近話題になっていたものだとモンスターハンターワイルズへの利用でしょうか。[*1]最近だとAWSがDSQLを発表していて、書き込みがスケールするという話を見かけ、一体どういう仕組みで書き込みがスケールするようになったのかとても中身が気になっていました。 ただ、私が現在仕事で扱っているのはtoB向けのSaaSであり、ゲームや広告配信と比較してそれほど大きなトラフィックがないプロダクトです。本書でも言及されていましたがNewSQLそれ自体は「Not for me」なのかなと思っていました。が、どうやら違うということが本書を読んでいてわかってきました。私の関わるSaaSはPostgreSQLを使用しておりそれで満足しているのですが、よりスマートに

導入 Kotlinにおける高階関数 2種類の高階関数 スコープ関数 コンテクスト指向プログラミングで何ができるか？ Context Parametersによるコンテクスト指向プログラミングの拡張 定義と解決したい課題 できること モノイド Raise DSL 関数型プログラミング言語からの影響 最後に 導入 あまりKotlinそれ自体で話題になっているわけではないのですが、Kotlinは「コンテクスト指向なプログラミング言語だ」とたまに言及されることがあります。たとえばKotlinのコンパイラチームの方が書いている記事にそのような用語で言及されているのを見かけます。 proandroiddev.com 私はKotlinに入門した際に、この言語はスコープの単位でいろいろ物事が整理されるように作られていそうだと感じていました。たとえばスマートキャストのように、特定の操作をして以降のスコープにお

本書はドキュメントについてはもちろんのこと、たとえば人に伝える際にどうすればよいかやリモートワークで働く際に何を気をつけたらよいかといった、開発現場で遭遇する「コミュニケーション」つまり情報伝達の方法論をいろいろと教えてくれる一冊です。今回は私が印象に残った内容を思考の整理がてら紹介したいと思います。 なんとなくタイトルが気になって買ったのが最初でしたが、思ったより自分の知らない話題が多くて得るものは多かったです。また、なんとなく意識していたものに対して名前がついていたことを知れたのもまた収穫だったと思いました。 開発者とアーキテクトのためのコミュニケーションガイド ―パターンで学ぶ情報伝達術 作者:Jacqui Readオーム社Amazon どんな本か 開発時に出会う情報伝達術についていろいろと体系的に指南してくれる一冊と思って良いでしょう。 まず最初は視覚的なコミュニケーション、つまり

先日より開催されていたKotlinConfで、新しいエラーハンドリング「Rich Errors」についての言及がありました。従来のように例外を使用するのではなく、エラーを値として扱えるようにする新機能です。聴き逃しているだけかもしれませんが、まだリリース予定などは立っておらず、機能を設計中の段階なのではないかと思われます。 私はもともとKotlinのエラーハンドリングはなかなか悩ましいなと思っていた節があり、ずいぶん前からKEEP上での議論を追うなどしてキャッチアップしていました。最近同僚ともエラーハンドリングに関する決め事をあれこれするために議論しており、私自身はエラーハンドリングに対する関心が高いです。 私の所感としては、Kotlinの言語設計によく合ったエラーハンドリングの方式が採用されそうで非常に楽しみにしています。最近の議論ではともすればモナドであるとか、Result<T, E>

生成AIが直のMarkdownを読み込みやすいという話から、にわかにObdisianが注目を集めているようです。そしてObsidianが注目を集めるにあたり、Zettelkastenという手法にも同時にスポットライトが当たり始めているように見受けられます。実は両者をそれなりに使ってきたので、どう使っているかやどう思っているかについて簡単にまとめてみたいと思います。なお、勢いで書いたので事実誤認（AIでいうならハルシネーション）を含む可能性があります。厳密に見ると間違いがあるかもしれません。ご了承ください。 Zettelkasten 元々Obsidianを使い始めたのは、前職にてローカルで自分のメモ書き等を管理したいためでした。というのも前職では最初の方、いい感じに使えるドキュメント管理ツールがなく、自分のメモ書きを残す場所を探していたという事情がありました（のちにConfluenceが導入

同期Rustと非同期Rustの書き心地や使い心地の違いがRustのAsync WGでも課題として挙げられており、目下できるかぎり近づける取り組みが進行中です。詳しいところはRustが最近運用しているProject Goalsの非同期Rustに関する部分を参照してください。ここを見ると、概ね現状抱えている課題などが見えてくると思います。 理想を言えば、std::ioやstd::netではじまるものを、たとえばtokio::ioやtokio::netに書き換え、必要な箇所にasyncと.awaitを付与していくだけで作業が完結してほしいところではあります。他の多くのプログラミング言語では、ままそのようにするだけで済むものが多い印象を持っています。たとえば、私が業務で使用するKotlinが実際にそうで、suspendをつけるだけでほとんどの処理を楽に非同期化することができます。もちろんKotli

例年年の終わりにまとめを書くときに、その年に何を読んだのかを忘れがちです。本棚を漁れば思い出すんですが、そうすると電子で読んで印象に残ったものを紹介し忘れがちです。ならば、毎月やれるときは紹介してみてはどうかというのが、今年のテーマです。 読んだ本と簡単なメモを記しておきます。 ソフトウェアアーキテクトの意思決定術 ソフトウェアアーキテクトのための意思決定術　リーダーシップ／技術／プロダクトマネジメントの活用 作者:Srinath Perera,島田 浩二インプレスAmazon 年末から読み始めて、年始にかけて読み終えた本でした。ソフトウェアアーキテクトの意思決定の失敗は、実は知識の不足よりも判断力の不足の方が大きいのではないかという問題意識から始まり、さまざまな決定のための考えるべきポイントが紹介されています。 詳しい感想は下記に書きました。 blog-dry.com 内部構造から学ぶP

バイリンガルITエンジニアの英語 作者:mayukoKADOKAWAAmazon 最近本ばかり読んでますね。そろそろコードを書いた話をしたいところなんですが、積読を消化するのに手一杯です。いえ、仕事ではコードを書いているんですけどね。 さて、ITの現場でよく使われる英語表現が詰まった一冊が出版されたので読んでみました。ぱらぱらと目を通して気になるフレーズをメモした、の「読んだ」です。 かくいう私もここ数年はずっと英語を使って仕事をする職場に従事しており、英語に対する意識はちょっと高めです。私自身は英語自体はケンブリッジ英検だとB2を昔とった（今だとC1取れるかも？）レベルなので、日常会話や仕事での会話で一通り困りはしないが、フォーマルな表現で言い換えたり、単語にある微妙なニュアンスをちゃんと使い分けて会話したり、複雑な概念（哲学に出てくるやつとか）を英語で的確に伝え切るみたいなところは難し

ソフトウェアアーキテクトのための意思決定術　リーダーシップ／技術／プロダクトマネジメントの活用 作者:Srinath Perera,島田 浩二インプレスAmazon 私は現在、会社でアーキテクト[*1]という職位についています。実際のところは、自分の半分くらいの時間でチームのテックリードを務めつつ、半分くらいの時間でアーキテクトをしているという時間配分です。アーキテクトというのは、勤務先ではテックリードの上位に置かれているようなイメージで、テックリードがチーム単位での技術的なリードを司る職位だとすると、アーキテクトはチームの上位概念である事業領域単位での技術的なリードを司る職位、ということになります。 アーキテクトの主な仕事は、基本的にはテックリードと変わらず技術的な意思決定です。さまざまなトレードオフを掻い潜りながら、その時点での最適な結論を出すのがお仕事といったところでしょうか。ただ、

たしかに、その年ごとに何を使っているのかログ取れるとおもしろいですね。来年もやるかどうかは未知数ですが！ blog.handlena.me エディタ Neovimを使っています。2023年ごろにVS Codeから乗り換えたはずです。一応緊急避難先としてVS CodeやZedもセットアップしてはありますが、普段は使っていません。 ただ、仕事ではKotlinという言語がちゃんと動くLanguage Serverを持っていない関係で、IntelliJを使っています。マウスカーソルを動かす必要があり、とてもイライラします。Kotlin以外の言語ではすべてNeovimを使用しています。 VS Codeで少し羨ましいのは、コーディング用のAI周りの対応が速いことです。時代の変化についていくためにはVS Codeをしっかり使っている必要がありそうではあります。 しかし、Neovimでも実はCopilot

ここ数年で『関数型ドメインモデリング』という書籍や、『Functional and Reactive Domain Modeling』といった書籍を読んだ経験から、今業務で取り組んでいるKotlinではどう表現できるのかに興味がありました。年末年始に少しまとまった時間が取れたので、実際に実装してみました。今回は、その過程でどのような知見を得られたかを、主には自分の理解のためにまとめておきたいと思います。 関数型ドメインモデリング　ドメイン駆動設計とF#でソフトウェアの複雑さに立ち向かおう (アスキードワンゴ) 作者:Scott Wlaschin,猪股 健太郎ドワンゴAmazon github.com 先に書いておきますが、長いです。目次をご覧になって、興味のある場所をかいつまんでお読みください。 免責事項 お題 技術スタック 設計 全体的な設計 Kotlinの使用に関するもの データ型の定

2024年に読んで印象に残った本の技術書編です。去年はそんなに多くの冊数は読めていません。というか、技術書を執筆して出版したので、技術書そのものにお腹いっぱいだったのは大きいと思います。 本を書いたという話は下記です。 blog-dry.com 非技術書編を先に書いているので、よかったらこちらもどうぞ。 blog-dry.com 免責事項ですが、記憶を元に書いている箇所が含まれることがあります。また、書籍のリンクにはアフィリエイトコードが付与されているので、苦手な方はURLから外してご購入ください。 目次 ルールズ・オブ・プログラミング Tidy First? Domain Modeling Made Functional 大規模データセットのためのアルゴリズムとデータ構造 コード×AIーソフトウェア開発者のための生成AI実践入門 モデル検査器をつくる〜Goで実装して学ぶ形式手法〜 まとめ

2024年は終わってしまいましたが、2024年読んで良かった本を紹介したいと思います。今回は技術書でない本を紹介します。 2023年くらいからこちらのブログでやっています。 blog-dry.com 免責事項ですが、完全に読了したものではなく読みかけの段階でも「これは…」という本も紹介しています。内容については記憶を頼りに書いているので、一部解釈誤りや記憶違いなどを含む可能性があります。アフィリエイトが入ってるのであらかじめご了承ください。 目次 技術革新と不平等の1000年史 論理的思考とは何か 近代美学入門 エビデンスを嫌う人たち 乳幼児は世界をどう理解しているのか 他者と沈黙 モヤモヤする正義 まとめ 技術革新と不平等の1000年史 技術革新と不平等の1000年史　上 作者:ダロン アセモグル,サイモン ジョンソン早川書房Amazon 技術革新と不平等の1000年史　下 作者:ダロン

日常的にはWezTermを使用しているのですが、Ghosttyがリリースされたのでセットアップしてみました。という記録です。 Ghostty GhosttyはTerraformやVagrant、Packerなどを提供するHashiCorpという会社を作ったMitchell Hashimoto氏によって開発が進められるターミナルエミュレータです。Zig製です。 ghostty.org 興味深いポイントは、Zero Configuration Philosophyを掲げている点でしょうか。要するに設定ファイルをガチャガチャ書かずとも、必要な機能が揃っていて起動さえすればあとはいい感じに利用できるというものです。設定をせずにとりあえず試してみて欲しいという趣旨の話がドキュメントを見ると記載されています。 実際のところはこれからお見せしますが、設定ファイルの行数は本当に減りました。WezTermと

toastyは先日tokioから発表されたORMです。 tokio.rs このORMは現状開発段階のもので、まだ実用に耐えうる段階にはないとGitHubには書かれています。というか、crates.ioにはダミー用関数が用意されているだけで、プロジェクトの依存に追加したとしてもまだ何もできません。現時点で対応しているのはsqliteとDynamoDBのようで、他のデータベースないしはCassandraなどには今後対応予定とのことです。async対応しています。また、SQLとNoSQL対応しているとなると、両者を抽象してくれるなにかかと思われるかもしれませんが、両者に対する操作を抽象してくれるわけではありません。 toastyの特徴 特徴としては、toastyというファイルにスキーマ定義を書き、toasty cliを実行すると、専用のRustコードが生成されるという点でしょうか。そして、生成さ

RustのWebアプリケーション開発に関する書籍を共著で執筆しました。1年くらい執筆していましたが、出版時期などが定まってきたので内容の紹介を込めて告知の記事を書きます。9/26刊行予定です。予約よろしくお願いします。 RustによるWebアプリケーション開発 ↓AmazonのURL（アフィリエイトなし） www.amazon.co.jp 数年前に書籍を執筆した際に、「次はWebアプリケーションの実装に関する本を書きたい」と記事に書き残していたのを今見つけたのですが、有言実行できたようです。 どんな本か？ Rustってバックエンド開発に向いてるの？ 著者について 目次とトピックの簡単な紹介 はじめに 第1章 本書で開発するアプリケーション 第2章 開発環境の構築 第3章 最小構成アプリケーションの実装 第4章 蔵書管理サーバーアプリケーションの設計 第5章 蔵書管理サーバーの実装 第6章

ここ数回の記事を見返してみると、書評ばかりしていてコード書いてるのか…？となったので、久しぶりにちゃんとコード（設定ファイル）を書く記事を書こうと思いました。いえ、コードは書いてるんですが、まとまった成果になっていないか、あまり新しいことをやっていないだけです。 Zed Zedの設定方法と今回目標 settings.jsonとkeymap.json snippet 設定の目標 私の設定 vim_mode、フォント、テーマ inlay hints rust-analyzer キーバインディング 設定してみての感想 参考資料 Zed Zed（ゼッド）というエディタが最近話題ですね。私も実は最近会社のPC上のNeovimが壊れてしまって、直している時間がないので一旦Zedを使ってその場しのぎをしています[*1]。VS Codeを使わなかったのは、あんまりVimバインディングが強くないとわかってい

しばらくは忙しく過ごしていてなかなか技術書を読む余裕はありませんでしたが、ようやく一冊読めたのでメモを残しておきたいと思います。『Kotlin in Action』という本の第2版です。未邦訳らしかったので、原著を読みました。 なお、気になったところだけつまんで読んだので、すべての章のメモが記されているわけではありません。ほとんどの章はScalaの頃の経験で概念としては知っている状態だったので、あまり印象に残りませんでした。後半戦は比較的Kotlin固有の概念が多くそちらは印象に残りました。 Kotlin in Action, Second Edition (English Edition) 作者:Aigner, Sebastian,Elizarov, Roman,Isakova, Svetlana,Jemerov, DmitryManningAmazon 大前提ですが、Android側の

Ghost of Tsushimaなどを作った会社の人が書いた本です。ゲーム開発におけるコードを書く際の教訓を整理し、改めて示し直したいい一冊だったと思います。大事なことですが、著者は決して「このルールを絶対使え」と言っているのではなくて、そもそもまず会社の製品の特性上、このようなルールを敷いておくと品質や生産性を高く保てたという前提があり、その前提を元に「ルールを選び取って自分たちのコーディング哲学を構築しよう」と推奨しています。 ルールズ・オブ・プログラミング ―より良いコードを書くための21のルール 作者:Chris Zimmermanオーム社Amazon この手の本では『リーダブルコード』がよく薦められる傾向にあると思います。私にとってもリーダブルコードは確かに駆け出しの頃すごく役に立った記憶はあるのですが（もう10年くらい前に読んだので正直忘れた）、そこから知識がアップデートされ

最近アーキテクトなるお仕事になったようなので、コードやアーキテクチャ関連の本を読み漁っています。何冊か読んでいるんですが、まずは最近Kent Beckが出版した『Tidy First?』の話を書きたいと思います。 Tidy First? (English Edition) 作者:Beck, KentO'Reilly MediaAmazon パート1: Tydings 「Tidy」というと、USでは一時期からコンマリが大流行りしているようで、「Kondo」がそもそも動詞化していたりするなど一大ブームとなっている（た）ようです。コンマリといえばそう、「お片付け」なんですが、なんとなくここから着想を得ているのかなと思います。Netflixでも「Tidying Up with Marie Kondo」という番組が作られていたくらいです。 Tidyingは「片付け」ないしは「整理整頓」あたりで訳せそ

発端 Pull Request で force push されると差分がわからなくなるから困るんだけどみんなどうしてますか？— codehex.bsky（へっくす） (@codehex) 2024年2月25日 ポストの前提がちょっとわかりませんが、レビュー後にforce pushされると、どこに修正を入れたのかわからないケースだと仮定します。プルリクエストがまだドラフト状態でのforce pushやrebaseで困るケースはそんなにないと思うからです。 git commit --fixup このケースではgit commit --fixupが便利です。レビューで指摘が入ったコミットに対して--fixupをかけておき、レビュワーはfixupコミットの内容を確認します。レビュワーが確認してOKが出た段階で、git rebase -i --autosquashなどを使ってfixupコミットを元コ

最近よく聞かれるのですが、実際のところ答えに困ったので普段何をしているかをメモしておこうと思います。自分語りです。前提として、筆者はソフトウェアエンジニアであり、ソフトウェアエンジニアとしてどうしているかという話をしています。 学び方 学ぶ際に気をつけていること 濃淡をつける 身体知を大事にする 時間がかかることを前提とする まとめ 学び方 学ぶチャネルは学ぶ対象に完全によります。大別するとふたつかもしれません。 文字媒体（技術書やドキュメント、チュートリアル）を読んで学ぶ。 「大規模言語モデル」「typescript」のような大きなテーマを学ぶ際は、基本的に技術書を読んでいます。 YouTubeなどの動画を見て学ぶ。 技術書やドキュメントを読んだ上で、特定のテーマについて具体的に知りたくなったときに利用しているかもしれません。 最近だと、Neovimのセットアップについてよく海外のストリ

昨年買っていたんですが、年末年始の時間を使って少し読めました。 著者はRustコンパイラにコントリビューションをしたことがあれば誰でも知っているかもしれない、Mara Bos氏です。 ちなみにですが、原著は下記サイトで無料でも読むことができます。 marabos.nl 書籍は下記です。 詳解 Rustアトミック操作とロック ―並行処理実装のための低レイヤプログラミング 作者:Mara Bosオーム社Amazon なおこの記事内で「本書」と明記する場合、それは『詳解Rustアトミック操作とロック』を指します。また、「筆者」は私自身のことであり、「著者」はMara Bos氏のことです。 内容のメモ 1章 2章 3章 4章、5章 6章 Miri Loom 7章 8章 9章 10章 感想 日本語での別の資料 内容のメモ 読んだ内容のうち、印象に残ったり初見だったものをメモしておきます。 1章 1章

あけましておめでとうございます。年がもう明けてしまいましたが、2023年に読んでよかった本について簡単に書いていこうと思います。noteで書いていましたが、こちらのブログをしっかり使わないといろいろもったいなと思ったので、技術に関係ない話題ではありますがこちらに書いていきます。 技術書 単体テストの考え方/使い方 フロントエンド開発のためのセキュリティ入門 知らなかったでは済まされない脆弱性対策の必須知識 プロを目指す人のためのtypescript入門 安全なコードの書き方から高度な型の使い方まで 技術書でないもの サピエンス減少 縮減する未来の課題を探る ネガティヴ・ケイパビリティで生きる 2050年の世界 見えない未来の考え方 訂正可能性の哲学 GitLabに学ぶ 世界最先端のリモート組織のつくりかた ドキュメントの活用でオフィスなしでも最大の成果を出すグローバル企業のしくみ 2024

小学生の頃にパソコンというものを触り始めてから社会人になってソフトウェアエンジニアとして働いて10年近く、ずっとJISキーボードを使ってきました。「日本語を打つのになぜUSキーボードをわざわざ使うのだ」という考えからずっと使ってきましたが、最近ついにUSキーボードに変えてしまいました。 買ったキーボード Nuphy Halo75 Nuphyの「Halo75 Wireless Mechanical Keyboard」というものに変えました。Night Breeze軸の音と軽さがちょうどよかったのでこれにしました。あんまり指の力が強くないので軽めのものがタイプです。ただ軽すぎると押したつもりもないのに押した判定されてそれはそれでストレスなので、35g〜45gくらいがちょうどいいなと思っています。この辺りの条件にフィットしたのがNight Breeze軸でした。 Nuphy Halo75 メカニ