誤りを認める練習 - 覚書
明らかに誤ったことをしたのにそれを認められずに醜態をさらしている、場合によっては傷口を広げて自分を窮地に追い込んでいる人を大量に見てきた結果、「こうはなりたくないな」と思う気持ちがずっとありました。にもかかわらず、数年前に見事に過ちを認められずに、謝罪できずに無様な姿をさらしたことがありました。公の場でやったことではないし、もしかすると謝罪されるべきだった相手は気にしていなかったかもしれませんが、自分から見れば間違いなく無様でした。 こういうことがあって以来、誤りを認める練習をするようになりました。練習といっても、壁に向かって謝罪し続けるというような話ではなく、自分の言ったこと、書いたことが間違っていたとわかったら、何もしなくてもその場はやりすごせそうな小さなことでも即座に「これは誤っていた」と表明するということをやっています。小さな誤りを認められなければ、大きな過ちを犯したときにも認めら
低レイヤ技術を間接的に仕事で生かしてきた経験の共有。元Linuxカーネル開発技術者の場合 - 覚書
はじめに ITの世界で「低レイヤ技術」と呼ばれるものがあります。明確に定義されているわけではありませんが、アプリケーションのような直接エンドユーザに触れる部分ではなく、しかもなるべく生のコンピュータに近い部分、たとえばOSカーネルやコンパイラ、CPUを開発する技術などがあります。これらの技術に明るい人はそうそういないのですが、「やってみたい」という根強い人気があります。 学生のかたでもセキュリティキャンプなどで実際にある程度身につけてしまうような人もいます。そしてますますこの手の技術に趣味としてのめり込んでいって楽しくなる…というところまではいいのですが、「ではこの技術を会得した先に何があるのか」と不安になる人も多いようです。とくに学生さんの場合は「低レイヤ技術を使って今後なんらかの仕事をして生きていけるのか？」といったことが気になるようです。今日もそのような話を少し耳にしたので、自分の経
仕事としてOSS開発者をやってきた話 - 覚書
はじめに わたしは今も昔も仕事としてOSS開発者をしていて、twitterなどでそれなりに名前が知られていることもあって、昔から「どうすればそういうこと(業務としてOSS開発)ができるのか」「どういうキャリアを歩んできたのか」「Linuxカーネル開発者になるにはどうすればいいのか」ということをよく聞かれてきました。当時わたしが置かれた環境と現在の環境では違いがありすぎるので公開に積極的にはなれなかったのですが、一つの過去事例として何らかの意味はあるかもと思って公開することにしました。 書き方が難しかったのですが、うまくまとまらなかったので、自分が書くのが楽な日記みたいになりました。 きっかけ 2000年初頭に学部4年のころにLinuxを触りはじめてから「UNIXとかLinuxってすげえ」「こんなものが無償で使えるのか」「これらのソースコードが全部見られるのか」と感動して、「自分も成果物を公
重要そうだけど興味のないことを頑張っても大していいことなかった話 - 覚書
時間は有限です。その合間を縫ってひねり出した可処分時間は貴重です。こういう時間は自分が楽しいと思えることにとことんつぎ込めばいいと今では思っているのですが、そうではなかった時の失敗談を紹介します。読者のみなさまの中で、好きなこと、やらなきゃいけないことしかできないという私のようなタイプの人には刺さるかもしれないです。 10年近く前の、まだわたしが若手というカテゴリに入っていたとき、当時ずっと生業にしていたLinuxカーネル以外にも、将来のために何かもう一つ引き出しの数を広げておかないといけないと思っていたことがありました。そういうときに飛びつきがちなのは流行りものです。当時のわたしにはそれがARMサーバでした。当時は何やらやらないと取り残されるのではという空気が身辺にありましたし、カーネル屋さんなのでハードウェアに近いところの知識はあればあるだけ損ではないという思いもありました。 ところが
日本のでかい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
「経験の浅いソフトウェア開発者が気になっていること」という募集への反応のまとめ - 覚書
数日前にブログや記事、書籍執筆ネタ集めのためにこういうtweetをしました。 [ゆるぽ] 経験の浅いソフトウェア開発者が気になっていること、とくにすでにそれなりのキャリアを積んだ人に聞きたいこと もっというと別に(ソフトウェア技術者としての)私個人について聞きたいことでもいいです— sat🧊 (@satoru_takeuchi) 2020年2月28日 その結果、返信および引用RTで数十個のネタが寄せられたので、まとめてみました。その場で回答したものについては回答一緒に書いています。それに加えて、私がわからないと言ったことについて別のかたから回答をしていただいたものについても書きました。さらに、既に経験豊富なかたがたから「経験の浅いソフトウェア開発者が気になっていそうなこと」や「知っておいてほしいこと」のようなネタもいただいたので、こちらもまとめました。 文面は基本的には改変せずにそのまま
性能と性能測定の基礎 - 覚書
はじめに コンピュータの世界では「性能」および「性能測定」という言葉があります。これらの言葉にはたくさんの意味があるのですが、業務システムの構築、運用にかかわったような人でなければ、「PCの新しいパーツに対して様々なベンチマークソフトウェアを走らせること」が性能測定であり、その結果得られるものが「性能」といったところでしょう。本記事ではそれ以外の、業務システムにおける性能や性能測定について述べます。 性能 ひとくちに性能といっても、さまざまな指標があります。代表的なものは「スループット」、「IOPS」、そして「レイテンシ」です。これらについてストレージデバイスを例に説明します。 スループットは単位時間あたりにどれだけのデータを送受信できるかであり、XX MB/sやYY GB/sのようにあらわします。性能といって一番イメージしやすいのはこれでしょう。スループットが重要な意味をもつのは大きなデ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
