私が生業とするソフトウェア開発において、OSやコードエディタやプログラミング言語など、様々なソフトウェアを使います*1。これらについて私が使っているものを理由付きで書くと次のようになります。 OS: Ubuntu 22.04 細かい設定をしなくてもそれなりに使える。よく普及しているから色々な情報を得やすい コードエディタ: VSCode 細かい設定をしなくてもそれなりに使える。Remote SSH extensionを使ったリモートマシン上での開発が楽 プログラミング言語: 主にGo 使い慣れているから。システムプログラムをするから。覚えやすいから これらにそれなりの愛着はあるものの、今後置かれる状況によって、どんどん変わってくるでしょう。じっさい10年くらい前はGoはほとんど使っていなくて、Cプログラマでした。 私はこんな感じですが、中には特定のソフトウェアに愛情を注ぐ人もいます。それ自

IT業界で10年以上過ごしている中で、凄いと思う人達にたくさん出会ってきました。最初はとくに新卒で入社した会社の先輩方が中心でした。ここでいう凄さとは何かというと「仕事を片づけるのが早い」とか「成果物の完成度が高い」などです。当時、こんなふうに自分もなってみたいという思いが強くて必至で真似しようと試行錯誤したのですが、全然うまくいきませんでした。ありていにいえば、表面上の凄さだけを見ていたことが失敗の原因だったかと思っています。早く仕事を片づけようと焦り、結果完成度も下がり…と、さんざんでした。 その後はアプローチを変えて、彼らの日常の何気ない振る舞いなどを観察することにしました。すると、彼らのうちの多くの凄さの源泉は驚異的に頭の回転が速いとか、ほかの誰もが持っていない異能力を持っていたりするわけではなく、世間で当たり前と言われていることを息をするようにやっていることだとわかりました。たと

大学ではB4の一年間、人によってはさらにMとかDとかで研究をします。そこで学べることについて、および、それを学ばなかったがために私が苦労したことを書きます。ここでは大学に行く人を主な読者層にしていますが、そうでなくても就職した後に後述の問題に遭遇することでは同じです。 わたしは高校時代は「プログラミング一本で生きていく」という決意をしていました。そこで近くの大学に情報工学科という学科があったので、そこを受験しましたが見事落選、第二希望だった別の学科に受かりました。このあとわたしの大学生活のポリシーは「可能な限り楽をして大学を出る、その間にプログラミングについての知識を独学する」でした。B4およびMでの研究においてもそのポリシーを愚直に守り通し、手抜きに手抜きを重ねてギリギリで卒業、修了しました。不良学生というやつです。最終的にはプログラミングやその他低レイヤといわれる領域の知識は平均的なC

プログラミング言語の良し悪しについては昔から活発に議論されてきました。このような議論の中で企業がどのようなプログラミング言語を採用するかについて釈然としない思いをしたかたも多々いらっしゃるかと思います。典型的には「なぜ自分の会社では俺の好きな言語を採用しないのか」です。この「なぜ」の一部に回答する、かつ、そこに共感しないまでも理解してもらうのが本記事の目的です。 この手の会話は炎上しがちであり、かつ、私はそのようなことはしたくないので個々の言語の名前は挙げません。そのためやや抽象的な表現が多くなりがちですがご容赦ください。また、筆者はここで書く価値観が絶対というつもりはなく、読者のみなさま個人のプロジェクトは自分の欲望の赴くままに好きなものを使えばいいと思っています。 企業は継続的にプログラムの開発やメンテナンスをする必要があります。これを念頭に置くと、使いこなせる人が多い言語であれば複数

はじめに わたしは今も昔も仕事としてOSS開発者をしていて、twitterなどでそれなりに名前が知られていることもあって、昔から「どうすればそういうこと(業務としてOSS開発)ができるのか」「どういうキャリアを歩んできたのか」「Linuxカーネル開発者になるにはどうすればいいのか」ということをよく聞かれてきました。当時わたしが置かれた環境と現在の環境では違いがありすぎるので公開に積極的にはなれなかったのですが、一つの過去事例として何らかの意味はあるかもと思って公開することにしました。 書き方が難しかったのですが、うまくまとまらなかったので、自分が書くのが楽な日記みたいになりました。 きっかけ 2000年初頭に学部4年のころにLinuxを触りはじめてから「UNIXとかLinuxってすげえ」「こんなものが無償で使えるのか」「これらのソースコードが全部見られるのか」と感動して、「自分も成果物を公

はじめに 本記事はLinux環境における次のようなことをざっくり理解するための記事です。 Application Programming Interface(API)って何? Application Binary Interface(ABI)って何? システムコールとAPIとABIの関係って？ それぞれ何がどう違うの? この手の情報はググればwikipediaやらにいろいろ情報が載ってるんですが、初心者が理解するには細かいことまで書かれすぎていて、かつ、それぞれの関係がわかりにくいです。なので、用語を逐一解説するのではなく、ありがちな質問のQAという形をとりました。人によって用語の意味の揺らぎがあったりするんですが、私の解釈ということで。あからさまに間違っていたら指摘していただけると嬉しいです。 これを書こうと思ったきっかけは、以前こんなtweetを見かけたことです。それから「そういえば最

なんらかの情報発信をすると、いろいろなリアクションが返ってきます。本記事ではこれら負のリアクションに怖気づかずに発信を続けたい人に、これまでに色々な記事を書き、かつ、殺害予告を含めた多種多様なリアクションを受けてきた筆者の考えかたを書いたものです。とくに情報発信を推奨するものではありません。やりたい人がやればいいだけです。 負のリアクションにはいろいろなタイプがあります。ここでは以下の三つのタイプについてのみ述べます。 馬鹿だのアホだのいう悪口 答えが無いものについての反対意見 誤りの指摘 複数のタイプが混ざり合ったものもあります。たとえば「ここの定義が間違えている。こいつは頭がおかしい」は誤りの指摘と悪口が混じっているといえます。 上記3つのタイプのうち、悪口については無視するといいと思います。なぜなら気にしてもとくにいいことはないからです。仮に相手にしてもとくにいいことはありません。発

休むことがどれだけ難しいか、および、私がそういうときにどう考えてきたかについて書きます。 プログラミングをはじめとしてコンピュータが好きであればあるほど*1、やる気があればあるほど休むことが難しいです。若くて気力体力が有り余っている場合はとくにそうで、朝から晩までプログラミングをしていてもあまり疲れを感じず、かつ、寝て起きたらスッキリです。ところが次第にそうではなくなってくることが多いようです。私が実際にそうでした。私の場合は以下のような流れで休みかたを忘れていきました。 10代後半でコンピュータに出会ったことによって興味の持てる対象が激増した コンピュータについての知識を得るために毎日昼夜を問わずに作業していた 休憩という概念がなく、寝る(気絶する)まで作業して、起きたらまた作業という状態になった。若くて体力があったので死ななかった 生活のリズムが乱れて疲労が蓄積していった。が、茹で蛙の

趣味でプログラミングをはじめようとする人が陥りがちな罠と、それについてのわたしの考え方について書きます。一部については私が実際にひっかかった罠で、それ以外は自分以外の人を見ていて思ったことです。仕事だと話は変わってくるのですが、それについては触れません。 情報量が多い昨今、「さあプログラミングをはじめよう」となっても、目の前には次のような様々な選択肢が待ち受けています。 OS(典型的にはWindows, macOS, Linux) プログラミング言語 テキストエディタ(あるいはIDE) 初心者はこれらのうちのどれを選ぶべきかというところでまず躓いて、まったく先に進めなくなることが多々あります。ただ、このへんは使ってみなければわからない好みの部分が非常に多いので、まずはフィーリングで適当に選んで、合わないものがあれば別のものに乗り換えればいいと思います。なんなら複数を使い分けてもいいんです。

時間は有限です。その合間を縫ってひねり出した可処分時間は貴重です。こういう時間は自分が楽しいと思えることにとことんつぎ込めばいいと今では思っているのですが、そうではなかった時の失敗談を紹介します。読者のみなさまの中で、好きなこと、やらなきゃいけないことしかできないという私のようなタイプの人には刺さるかもしれないです。 10年近く前の、まだわたしが若手というカテゴリに入っていたとき、当時ずっと生業にしていたLinuxカーネル以外にも、将来のために何かもう一つ引き出しの数を広げておかないといけないと思っていたことがありました。そういうときに飛びつきがちなのは流行りものです。当時のわたしにはそれがARMサーバでした。当時は何やらやらないと取り残されるのではという空気が身辺にありましたし、カーネル屋さんなのでハードウェアに近いところの知識はあればあるだけ損ではないという思いもありました。 ところが

はじめに 以下記事の続きです。実例編といってもいいかもしれません。 satoru-takeuchi.hatenablog.com 完璧超人とまではいかないでしょうが、わたしも次の理由によりSNSなどでは「いろいろできるすごい人」「低レイヤに詳しい人」と思われがちです。 Linuxカーネルに詳しい。カーネルに詳しい人は無条件でなんでもわかっていると誤解されることが多々ある 自分あるいは自分が所属している組織の成果をよく宣伝する。このため、そういうことを好まない人に比べて「何かできる人」という印象がつきやすい twitter上でそれなりに認知されている、かつ、twitter上で様々なすごい人とよく話している。「すごい人と話しているとすごい」と思われがち。 本記事の趣旨は、その私が世の中で想像されるほどいろいろできるわけではない、できることは限られているということを書いてみようということです。自

はじめに 本記事は電子書籍版もあります。 linuxカーネルはC言語のマクロを駆使して書かれています。それらのうち、凝ったマクロになじみの無い人には初見では意図がわからない&わかってみれば面白いであろうものをいくつか紹介いたします。対象読者は、C言語のユーザだけれども、マクロは定数定義くらいにしか使わないというライトなマクロユーザです。 マクロを使用する場所に依存するエラーを防ぐ 次のマクロは、二つの引き数の値を置換するだけの単純なものです。 #define swap(a, b) \ do { typeof(a) __tmp = (a); (a) = (b); (b) = __tmp; } while (0) 注目すべきはマクロの定義全体を囲んでいるdo { ... } while (0)という表記です。初見の人には何のことかわからないと思います。考えられる最も単純な定義から遡って、なぜこ

数日前にブログや記事、書籍執筆ネタ集めのためにこういうtweetをしました。 [ゆるぽ] 経験の浅いソフトウェア開発者が気になっていること、とくにすでにそれなりのキャリアを積んだ人に聞きたいこと もっというと別に(ソフトウェア技術者としての)私個人について聞きたいことでもいいです— sat🧊 (@satoru_takeuchi) 2020年2月28日 その結果、返信および引用RTで数十個のネタが寄せられたので、まとめてみました。その場で回答したものについては回答一緒に書いています。それに加えて、私がわからないと言ったことについて別のかたから回答をしていただいたものについても書きました。さらに、既に経験豊富なかたがたから「経験の浅いソフトウェア開発者が気になっていそうなこと」や「知っておいてほしいこと」のようなネタもいただいたので、こちらもまとめました。 文面は基本的には改変せずにそのまま

以下記事の続きのような話をします。 satoru-takeuchi.hatenablog.com この記事には興味深いフィードバックがたくさんもらえました。その中でもとくにわたしが気になったのは次のメッセージについての反応でした。 その後、「自分もここなら詳しい」という部分ができてきたこともあって、徐々に自信を取り戻してきて、今に繋がっていきます。 これについては「自分には得意なものが無い」という反応が多かったです。しかしながら得意なもののうちの多くは生まれつき決まっているわけではなくて後天的に身につけられるものです。焦らずに好きなもの、得意そうなものを磨き上げていけばいいのではないでしょうか。わたしも「徐々に自信を取り戻して」とか書いてますけど、気持ちの整理がつくまで10年くらいかかりました*1。 続いて、「自分もここなら詳しい」という言葉について。こういうことを書くと、何らかの技術につ

かつての失敗談。ついった初めたばかりのころにはまった次のような悪い循環です。 すごい人をたくさんフォローする すごい人達がすごいこと言ったりやったりする それに比べて自分は大したことできないと自信喪失する 何もしなくなる フォローする人が多くなればなるほどこの傾向は加速していきました。なぜかというと、それぞれのすごい人達の凄い部分を全部合成した完璧超人と戦おうとしていたからです。 たとえば次のような3人をフォローしたとします。 RDBにめちゃくちゃ詳しい人 カーネルめちゃくちゃ詳しい人 特定のプログラミング言語にめちゃくちゃ詳しい人 ここで私は「RDBにもカーネルにも特定のプログラミング言語にも全部めっちゃ詳しい超人」を脳内で作って、その架空の超人を見上げて自信喪失していたのです。 この誤解が解消したのは、のちのち各種カンファレンスや勉強会などに参加して彼らに出会う幸運に恵まれたときでした

年末なので手短に一年間の振り返りをします。 会社の仕事はぼちぼちでした。夏までは色々あって当初想定していたほどプロジェクトに貢献できなくて苦労しましたが、それ以降はOSSコミュニティ活動がはじまったので自分の持ち味を最大限に活用できるようになりました。来年はさらに飛躍をしたいなと。めざせRookメンテナ。 個人事業主としては少し広がりました。まずは例年通り、春と秋の技術書典に新刊を出し、Software Designの連載「Linuxのしくみ」も12月原稿を落とさずにやりとげました。去年出した前記連載と同名の書籍が一年を通してじりじりと売れ続けたのはとてもうれしかったです。それ以外には単発の仕事としてWeb上に「いま知っておきたLinux」という記事を書きました。これはたくさんの人に読んでもらって、かつ、想定読者に刺さったようなのでよかったです。書籍の次回作も仕込みをはじめたので、来年以降

去年個人事業主として何をやったのかの一覧と、やってみての感想。 やったことはおおよそ次の通り。 現在働いている会社における技術顧問業(4月までで終わり) 拙著「Linuxのしくみ」の印税 Software Designでの連載「Linuxのしくみ」の原稿料(5月から) セキュリティキャンプ全国大会2018の講師 技術同人誌販売(春秋の技術書典とオンライン販売) gihyo.jp windhole.booth.pm このような組み合わせになったのには次のような事情があります。 IT技術、物を書くこと、人に伝えることが好き 好きなことだけしたい 売れなければキャッシュアウトになるようなリスクはなるべく負いたくない。たとえば在庫を抱えるとか なるべく好きな時に好きなだけ好きなところで働きたいので、空間的、時間的な制約を強く受けることはしたくない 稼いだ金額については具体的な数値は書きませんが、幸

大晦日なので2018年の振り返りと来年の抱負をば。個人ブログなので会社の仕事のことは置いといて、主に個人的なものについて。 2018年の振り返り 全体的に良い年でした。旧知の人たちとも会う機会も増えたし、新しい人たちとも多く出会えました。彼らと会うときにいいものを食べ過ぎてお肉もついたのが玉に瑕です。書籍の出版、雑誌連載の開始、再就職などという初物イベントがたくさんあったので、劇的だったと言ってもいいかもしれません。他には個人事業主として色々手を出したことによって、月並みな感想ですが「自分自身でお金を稼ぐって大変だ」を実感しました。どれだけ技術的に面白いことをやって頑張っても、お金にならないと生きていけないですから*1。 2月にはLinuxのしくみというLinuxを通してOS、その中でも主にカーネルについて図解と演習によって学ぶ本を出版しました。書籍を書くことそのもの、および、OS知識を広

プログラミング初心者に対してどういう情報が役立つのかをぼんやり考えていると、そこそこコードを書けるベテランが、いつ、どういうことにつまづいてきたのかを書くとけっこう有益なのではないかと思ったので書きました。これを読むと直接プログラミング能力が上がるわけではないですが、「ああ、こういうところでつまづいてもいっぱしのプログラマになれている人もいるのだな」と思ってもらうのが目的です。成功談よりも失敗談のほうが役立つとよく言われますが、それと少し似ているのかもしれません。 全段落で「いっぱしのプログラマ」とか言った手前、自分のことを書いておきます。18歳ごろから20年くらい前からプログラミングをしていて、主に有名どころのOSSに向けてコードを書いてきました。昔はLinuxカーネルを10年少々やっていて、ここ最近はCephオーケストレータであるRookの開発とかをしています。プログラマとしてはスーパ

Kubernetesとはそもそも何者なのか、何のためにどういう設計思想で作られたのか、どうやって使えばいいのか、どういうしくみになっているのか、などなどについて書かれた本です。一言でいうと非常によい本でした。Kubernetesに関する良い本はたくさんありますが、私が読んだ中で下記対象読者(本文より引用)にとってこの本が最適だと思います。 Kubernetesをはじめて使う業務アプリケーション開発者 Dockerの基礎知識がある方 とにかく上記の対象読者の気持ちに寄り添って、Kubernetesの「最低限ここだけは理解しないと話にならない」という部分にだけ的を絞って最短経路で理解してもらいたい、という気持ちがにじみ出ていました*1。他のKubernetes本を見たものの難しすぎて挫折したというかたでも、この本を読んだ上でもとの本に戻ると驚くほど理解しやすくなると思います。Kubernete