わたしの私用PCの開発環境 - 覚書
わたしに声をかけてくれるIT技術者、とくに経験が浅い人に私用PCの開発環境は何を使っているかということをよく聞かれます。なにかの役に立つかもしれないので、環境を紹介しつつ、どういう思いでそうしているのかについても書きます。 私のバックグラウンドを説明しておくと、会社員として15年ちょっとLinuxカーネルの開発、サポート業務をしていました。その後6年くらい別のSaaS企業で自社インフラ用の分散ストレージの開発をしています。このストレージはLinux上で動作します。趣味ではLinuxカーネルやその周辺領域についての技術書を出したり記事を書いたり、YouTubeの動画を公開したりしています。つまりLinuxに非常に縁が深いです。 わたしはPCを2台持っています。一つめは普段使いのモバイルノートPC、もう一つはミニタワーのデスクトップPCです。ノートPCはVAIO Zで、スペックを盛れるだけ盛り
プログラミングを始めたころとは考え方が全然変わっていることに気づいてびっくりした話 - 覚書
家にパソコンがはじめて来てから30年くらい、プログラミングを始めてから20年以上が経ちました。その間、IT技術に対する愛は変わらずに、ずっと走り続けてきました。では当時の自分と今の自分で何が違うのだろうと考えてみたところ、めちゃくちゃ変わっていたのでびっくりました。本記事では何がどう変わったのか、それを見てなにを思ったかなどを書きます。 昔は次のようなこだわりがありました。 大きなものは一つの仕事をする単純で小さなツールを組み合わせて作るべし ソフトウェアは可能な限り設定可能になっていてほしいし、それを自分の好みになるまでカリカリチューニングしたい 可能な限りすべてキーボードだけで操作できるようになっていてほしい いわゆるUNIX哲学をはじめとして、いろんな本やWebサイトなどに強い影響を受けていることがよくわかります。 ところが今は次のように全然違うことを考えています。 トラブルハマった
ソフトウェア開発者のわたしが好きなコンピュータ以外の本 - 覚書
2023/8/13 18:20 タイトル変更。「ソフトウェア開発者が好きなコンピュータ以外の本」→「ソフトウェア開発者のわたしが好きなコンピュータ以外の本」 2023/8/15 16;20 「敗者のゲーム」から「星を継ぐもの」までを追加 私はソフトウェア開発者です。このブログなり別の場所なりでコンピュータについての参考書を何度なく紹介してみました。本記事はそれとはちょっと違って、私がこれまで出会ってきて感銘を受けたコンピュータに関係ない本たちを紹介します。紹介順とお気に入り度は連動していません。思いついた順番に書いただけです。 ルワンダ中央銀行総裁日記 銀行家である筆者がルワンダという国の中央銀行総裁を務めていた時期のことについて述べた本です。事あるごとに色々なところで紹介される有名な本なので、名前は聞いたことがあるとか読んだことがあるとかいう人は多いかと思います。本書の凄いところは2つあ
「［試して理解］Linuxのしくみ ～実験と図解で学ぶOS、仮想マシン、コンテナの基礎知識【増補改訂版】」が発売されます - 覚書
拙著、「［試して理解］Linuxのしくみ ～実験と図解で学ぶOS、仮想マシン、コンテナの基礎知識【増補改訂版】」が10/17日に発売されることになりました。本記事はその宣伝のためのブログエントリです。 ［試して理解］Linuxのしくみ ―実験と図解で学ぶOS、仮想マシン、コンテナの基礎知識【増補改訂版】 作者:武内 覚技術評論社Amazon まずは本書がどのようなものかについて説明し、その後に、すでに第一版を読まれている方向けに第一版と本書の差分について説明します。 どんな本なのか 筆者は過去にLinuxカーネル開発をしていたのですが、そのころから次のような思いをずっと持っていました。 OS、とくにOSカーネルについての広く浅い知識はOSカーネル開発者だけではなく多くの技術者にとって役立つはず 当時OSカーネルについての知識を得ようとすると、OSを作ったりサポートしたりする人用の難しくて分
当たり前のことをやっているだけで凄い - 覚書
IT業界で10年以上過ごしている中で、凄いと思う人達にたくさん出会ってきました。最初はとくに新卒で入社した会社の先輩方が中心でした。ここでいう凄さとは何かというと「仕事を片づけるのが早い」とか「成果物の完成度が高い」などです。当時、こんなふうに自分もなってみたいという思いが強くて必至で真似しようと試行錯誤したのですが、全然うまくいきませんでした。ありていにいえば、表面上の凄さだけを見ていたことが失敗の原因だったかと思っています。早く仕事を片づけようと焦り、結果完成度も下がり…と、さんざんでした。 その後はアプローチを変えて、彼らの日常の何気ない振る舞いなどを観察することにしました。すると、彼らのうちの多くの凄さの源泉は驚異的に頭の回転が速いとか、ほかの誰もが持っていない異能力を持っていたりするわけではなく、世間で当たり前と言われていることを息をするようにやっていることだとわかりました。たと
kindleの本が全部消えた話 - 覚書
2022/5/27 変更 - 後述のアカウント統合後にamazon.comのアカウント削除によってkindle本が全部消えるのは仕様である旨、追記 2022/6/1 変更 - 「サポートの指示によってamazon.comのアカウントを消した」のではなく、「使用していないamazon.comのアカウントを閉鎖してもいいのか」という趣旨の質問を私がしたのに対して「そうですね」と回答されたということがわかったので、訂正。 編集前の記述には取り消し線を引いて、編集後の記述は強調表示しました。 NOTE: 上記変更点にもあるように、「サポートの指示によってamazon.comのアカウントを消した」という私の認識は誤っていたことがわかりました。これについてはamazon.co.jpのかたがたにメールで謝罪いたしました。 ここに書いたことは2022年4月21日現在の話です。 サマリ kindleの本が全
ソフトウェア技術者はなるべくソフトウェア技術で目立つほうがいい 2 - 覚書
↓の続きです。 satoru-takeuchi.hatenablog.com 何をするにも知名度の有無によって注目度は変わります。極端な話をすると、誰かがものすごいことを成し遂げたとしても、誰とも接点が無い人がやれば誰にも知られず、すでに名のある人がやれば注目されます。なので知名度があればそれだけでいいか…というとそうではないです。 知名度の高まりかたにはいろいろと種類があります。そのうち一つは名声を博することです。名声を博するには技術者としてのスキルや地道な実績の積み重ね、場合によっては自己プロデュース能力が必要です。とてつもなく凄いが目立つのを嫌う人もいるので一概に知名度があればいいというものではないですが、その話はここでは置いておきます。 その一方で、人から眉をひそめられるようなことをすると悪名がとどろきます。これには別に技術者としてのスキルは必要ないので名声を博するよりも簡単です。
ソフトウェア技術者はなるべくソフトウェア技術で目立つほうがいい - 覚書
ソフトウェア技術者として名を上げたい人向けの記事です。 まずは前置き。ソフトウェア技術者の世界にはスーパースターといえるような凄まじい能力を持つ人達がいます。彼らのうちの一部は生活能力がゼロだったり、口や態度が悪かったり、好きなこと以外は一切できなかったりといった様々な欠点があります。すごい人の中でもこういう人は親近感を生むのか、なんとなく目立つ傾向にあるように思います。SNSなどでも粛々と技術の話だけしたりする人よりも、こういう破天荒な人たちがウケて人気を集める傾向にあります。かくいうわたしも、この手の人たちは人間臭くて好きです。 ここからが本題。スーパースターにあこがれる人が彼らのスキルを真似するのではなく、立ち振る舞いを真似してしまって、とくにSNSなどでそうしてしまって、自分の価値を貶めているのを頻繁に目にします。典型的には凄くなりたいけどまだまだ経験が足りない学生さんや経験の浅い
ヘタクソなコードを書いてもいい - 覚書
プログラミング言語のお作法から外れたコードやメンテ性が悪いコードを書くのはダメとよくいわれます。わたしは学生の頃、そういう意見を過剰に気にしていました。コードを書くことそのものに慣れていないのに綺麗に書こうとして手が動かず、動かないがゆえにコーディングの練習が進まない、という悪循環になっていました。そうすると何もアウトプットしないまま知識だけが増えていって、自分がこれくらいできそうというイメージと実際のプログラミング能力とのギャップで苦しみました。 この意識が薄れたのは、あるときものすごく手が早い人のコードを偶然見たときでした。たしかにちゃんと動くものができているんですが、そのコードの中身は当時の私の基準からいって*1おぞましいほど汚いものでした。そこで「これはわたしが書けば100倍くらい綺麗なコードを書けるんでは…」と一瞬思ったんですが、その後すぐに「あ、自分は知識はあるけど練習してない
企業にとってのプログラミング言語の位置づけ - 覚書
プログラミング言語の良し悪しについては昔から活発に議論されてきました。このような議論の中で企業がどのようなプログラミング言語を採用するかについて釈然としない思いをしたかたも多々いらっしゃるかと思います。典型的には「なぜ自分の会社では俺の好きな言語を採用しないのか」です。この「なぜ」の一部に回答する、かつ、そこに共感しないまでも理解してもらうのが本記事の目的です。 この手の会話は炎上しがちであり、かつ、私はそのようなことはしたくないので個々の言語の名前は挙げません。そのためやや抽象的な表現が多くなりがちですがご容赦ください。また、筆者はここで書く価値観が絶対というつもりはなく、読者のみなさま個人のプロジェクトは自分の欲望の赴くままに好きなものを使えばいいと思っています。 企業は継続的にプログラムの開発やメンテナンスをする必要があります。これを念頭に置くと、使いこなせる人が多い言語であれば複数
仕事としてOSS開発者をやってきた話 - 覚書
はじめに わたしは今も昔も仕事としてOSS開発者をしていて、twitterなどでそれなりに名前が知られていることもあって、昔から「どうすればそういうこと(業務としてOSS開発)ができるのか」「どういうキャリアを歩んできたのか」「Linuxカーネル開発者になるにはどうすればいいのか」ということをよく聞かれてきました。当時わたしが置かれた環境と現在の環境では違いがありすぎるので公開に積極的にはなれなかったのですが、一つの過去事例として何らかの意味はあるかもと思って公開することにしました。 書き方が難しかったのですが、うまくまとまらなかったので、自分が書くのが楽な日記みたいになりました。 きっかけ 2000年初頭に学部4年のころにLinuxを触りはじめてから「UNIXとかLinuxってすげえ」「こんなものが無償で使えるのか」「これらのソースコードが全部見られるのか」と感動して、「自分も成果物を公
IT技術についての書籍を商業出版するか同人誌として出すか - 覚書
IT技術者はさまざまなプラットフォームを通して情報発信して知見を共有するのが好きという印象が強いです。zennやqiitaといったサービスをはじめ、さまざまな場所で貴重な情報が無償で公開されているのは驚くばかりです。 情報発信を繰り返していくうちに自分のコンテンツを形にしたい、具体的には書籍を出したいと思う人も多いようです。そこで目の前に立ちはだかる壁のひとつが出版社から商業出版するか同人誌として出版するかという選択を迫られることです。本記事ではそれぞれのpros,consについて、これまでに商業出版、同人誌出版の両方の経験がある筆者の意見を書きます。 結論から書きますと、わたしは以下のような考え方を持っています。 なるべくお金がほしいなら、あるいは世の中に広く情報を行き渡らせたいなら商業出版 ニッチで客層が限られるものについては同人誌 いずれにせよ普段から誠実な情報発信をし続けるとリーチ
色々できるとおもわれがちな人ができないこと - 覚書
はじめに 以下記事の続きです。実例編といってもいいかもしれません。 satoru-takeuchi.hatenablog.com 完璧超人とまではいかないでしょうが、わたしも次の理由によりSNSなどでは「いろいろできるすごい人」「低レイヤに詳しい人」と思われがちです。 Linuxカーネルに詳しい。カーネルに詳しい人は無条件でなんでもわかっていると誤解されることが多々ある 自分あるいは自分が所属している組織の成果をよく宣伝する。このため、そういうことを好まない人に比べて「何かできる人」という印象がつきやすい twitter上でそれなりに認知されている、かつ、twitter上で様々なすごい人とよく話している。「すごい人と話しているとすごい」と思われがち。 本記事の趣旨は、その私が世の中で想像されるほどいろいろできるわけではない、できることは限られているということを書いてみようということです。自
Linuxカーネルで学ぶC言語のマクロ - 覚書
はじめに 本記事は電子書籍版もあります。 linuxカーネルはC言語のマクロを駆使して書かれています。それらのうち、凝ったマクロになじみの無い人には初見では意図がわからない&わかってみれば面白いであろうものをいくつか紹介いたします。対象読者は、C言語のユーザだけれども、マクロは定数定義くらいにしか使わないというライトなマクロユーザです。 マクロを使用する場所に依存するエラーを防ぐ 次のマクロは、二つの引き数の値を置換するだけの単純なものです。 #define swap(a, b) \ do { typeof(a) __tmp = (a); (a) = (b); (b) = __tmp; } while (0) 注目すべきはマクロの定義全体を囲んでいるdo { ... } while (0)という表記です。初見の人には何のことかわからないと思います。考えられる最も単純な定義から遡って、なぜこ
日本のでかいIT企業のLinuxカーネルパッチ数の推移 - 覚書
日本のでかいIT企業がupstreamのLinuxカーネルにどれだけパッチを取り込んできたかを、ふと気になったので調べました。調査期間はv2.6.13から本記事執筆時点の最新バージョンであるv5.5までです。対象とした企業は、筆者がLinuxカーネルを主な仕事をしていたころ(v4.xあたりまで)に目立っていた企業です。「あれからどうなったんだっけ」とふと気になったというのが調査の動機です。 パッチ数は次のスクリプトで数えました。 #!/bin/bash for company in fujitsu hitachi nec ntt sony toshiba ; do echo "=== $company ===" for i in $(seq 12 38) ; do git log --oneline --format="%ae" v2.6.${i}..v2.6.$((i+1)) | gre
性能と性能測定の基礎 - 覚書
はじめに コンピュータの世界では「性能」および「性能測定」という言葉があります。これらの言葉にはたくさんの意味があるのですが、業務システムの構築、運用にかかわったような人でなければ、「PCの新しいパーツに対して様々なベンチマークソフトウェアを走らせること」が性能測定であり、その結果得られるものが「性能」といったところでしょう。本記事ではそれ以外の、業務システムにおける性能や性能測定について述べます。 性能 ひとくちに性能といっても、さまざまな指標があります。代表的なものは「スループット」、「IOPS」、そして「レイテンシ」です。これらについてストレージデバイスを例に説明します。 スループットは単位時間あたりにどれだけのデータを送受信できるかであり、XX MB/sやYY GB/sのようにあらわします。性能といって一番イメージしやすいのはこれでしょう。スループットが重要な意味をもつのは大きなデ
「経験の浅いソフトウェア開発者が気になっていること」という募集への反応のまとめ - 覚書
数日前にブログや記事、書籍執筆ネタ集めのためにこういうtweetをしました。 [ゆるぽ] 経験の浅いソフトウェア開発者が気になっていること、とくにすでにそれなりのキャリアを積んだ人に聞きたいこと もっというと別に(ソフトウェア技術者としての)私個人について聞きたいことでもいいです— sat🧊 (@satoru_takeuchi) 2020年2月28日 その結果、返信および引用RTで数十個のネタが寄せられたので、まとめてみました。その場で回答したものについては回答一緒に書いています。それに加えて、私がわからないと言ったことについて別のかたから回答をしていただいたものについても書きました。さらに、既に経験豊富なかたがたから「経験の浅いソフトウェア開発者が気になっていそうなこと」や「知っておいてほしいこと」のようなネタもいただいたので、こちらもまとめました。 文面は基本的には改変せずにそのまま
実体の無い完璧超人と戦っていた過去の失敗談 - 覚書
かつての失敗談。ついった初めたばかりのころにはまった次のような悪い循環です。 すごい人をたくさんフォローする すごい人達がすごいこと言ったりやったりする それに比べて自分は大したことできないと自信喪失する 何もしなくなる フォローする人が多くなればなるほどこの傾向は加速していきました。なぜかというと、それぞれのすごい人達の凄い部分を全部合成した完璧超人と戦おうとしていたからです。 たとえば次のような3人をフォローしたとします。 RDBにめちゃくちゃ詳しい人 カーネルめちゃくちゃ詳しい人 特定のプログラミング言語にめちゃくちゃ詳しい人 ここで私は「RDBにもカーネルにも特定のプログラミング言語にも全部めっちゃ詳しい超人」を脳内で作って、その架空の超人を見上げて自信喪失していたのです。 この誤解が解消したのは、のちのち各種カンファレンスや勉強会などに参加して彼らに出会う幸運に恵まれたときでした
プログラミングでつまづいてきたこと - 覚書
プログラミング初心者に対してどういう情報が役立つのかをぼんやり考えていると、そこそこコードを書けるベテランが、いつ、どういうことにつまづいてきたのかを書くとけっこう有益なのではないかと思ったので書きました。これを読むと直接プログラミング能力が上がるわけではないですが、「ああ、こういうところでつまづいてもいっぱしのプログラマになれている人もいるのだな」と思ってもらうのが目的です。成功談よりも失敗談のほうが役立つとよく言われますが、それと少し似ているのかもしれません。 全段落で「いっぱしのプログラマ」とか言った手前、自分のことを書いておきます。18歳ごろから20年くらい前からプログラミングをしていて、主に有名どころのOSSに向けてコードを書いてきました。昔はLinuxカーネルを10年少々やっていて、ここ最近はCephオーケストレータであるRookの開発とかをしています。プログラマとしてはスーパ
「しくみがわかるkubernetes」を読んだ - 覚書
Kubernetesとはそもそも何者なのか、何のためにどういう設計思想で作られたのか、どうやって使えばいいのか、どういうしくみになっているのか、などなどについて書かれた本です。一言でいうと非常によい本でした。Kubernetesに関する良い本はたくさんありますが、私が読んだ中で下記対象読者(本文より引用)にとってこの本が最適だと思います。 Kubernetesをはじめて使う業務アプリケーション開発者 Dockerの基礎知識がある方 とにかく上記の対象読者の気持ちに寄り添って、Kubernetesの「最低限ここだけは理解しないと話にならない」という部分にだけ的を絞って最短経路で理解してもらいたい、という気持ちがにじみ出ていました*1。他のKubernetes本を見たものの難しすぎて挫折したというかたでも、この本を読んだ上でもとの本に戻ると驚くほど理解しやすくなると思います。Kubernete
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
