なんでもかんでも「バグ」ってひとくくりにしないで - 覚書
はじめに プログラマがソフトウェアを作るとユーザがつきます。ユーザがそのソフトウェアを使っていて何らかの問題が発生すると「このソフトはバグってる、直して！」と言われることがままあります。それに対して「いや、仕様だから」と突っぱねられることがあります。その後お互いの意見が「バグだ！」「いいや仕様だ！」と平行線になってお互いモヤモヤのまま終わるというのはよくある話です。 なぜこういうことが起きるかというと、原因の一つは「問題」イコール「バグ」という短絡的な考え方です。とくにソフトウェアを作ったり使ったりした経験が浅い人がこうなる傾向があると推測しています。このような食い違いは「要件」「仕様」と「実装」という言葉の意味を理解していればある程度解決できます。本書はこれらの用語について実例を挙げて簡単に紹介します。 注意点 本記事では要件や仕様を定義することが前提となっていますが、とくにユーザと開発
書籍を使った勉強のしかた - 覚書
わたしがこれまでに書籍でなにか新しいことを学ぼうと思ったときにどういう手段で目的を達成してきたかについて書きます。生業にしているIT系のこともそうですが、それ以外も同じ方法を使っています。 はじめに書いておくと、これまでの自分自身の体験や優秀な人の観察などから、学習の原則コツコツと反復練習を続けることであり、近道は無いと思っています。原則を守るための典型的な方法の一つが「網羅的に書かれた決定版と呼ばれる本を何度も精読する」です。これができる人はこうしたほうがいいと思いますし、ここから先を読む必要はないです。しかしながら、わたしはこの方法がうまくいったためしがないので、自分なりに工夫して、金銭的コストがやや高いながらそこそこうまくいく方法にたどり着きました。本記事ではこの方法を紹介します。 わたしは何かを理解しようとするときには、まずは初心者向きのページ数が少なくて読みやすそうな本をたくさん
ソフトウェア技術者はなるべくソフトウェア技術で目立つほうがいい - 覚書
ソフトウェア技術者として名を上げたい人向けの記事です。 まずは前置き。ソフトウェア技術者の世界にはスーパースターといえるような凄まじい能力を持つ人達がいます。彼らのうちの一部は生活能力がゼロだったり、口や態度が悪かったり、好きなこと以外は一切できなかったりといった様々な欠点があります。すごい人の中でもこういう人は親近感を生むのか、なんとなく目立つ傾向にあるように思います。SNSなどでも粛々と技術の話だけしたりする人よりも、こういう破天荒な人たちがウケて人気を集める傾向にあります。かくいうわたしも、この手の人たちは人間臭くて好きです。 ここからが本題。スーパースターにあこがれる人が彼らのスキルを真似するのではなく、立ち振る舞いを真似してしまって、とくにSNSなどでそうしてしまって、自分の価値を貶めているのを頻繁に目にします。典型的には凄くなりたいけどまだまだ経験が足りない学生さんや経験の浅い
企業にとってのプログラミング言語の位置づけ - 覚書
プログラミング言語の良し悪しについては昔から活発に議論されてきました。このような議論の中で企業がどのようなプログラミング言語を採用するかについて釈然としない思いをしたかたも多々いらっしゃるかと思います。典型的には「なぜ自分の会社では俺の好きな言語を採用しないのか」です。この「なぜ」の一部に回答する、かつ、そこに共感しないまでも理解してもらうのが本記事の目的です。 この手の会話は炎上しがちであり、かつ、私はそのようなことはしたくないので個々の言語の名前は挙げません。そのためやや抽象的な表現が多くなりがちですがご容赦ください。また、筆者はここで書く価値観が絶対というつもりはなく、読者のみなさま個人のプロジェクトは自分の欲望の赴くままに好きなものを使えばいいと思っています。 企業は継続的にプログラムの開発やメンテナンスをする必要があります。これを念頭に置くと、使いこなせる人が多い言語であれば複数
色々できるとおもわれがちな人ができないこと - 覚書
はじめに 以下記事の続きです。実例編といってもいいかもしれません。 satoru-takeuchi.hatenablog.com 完璧超人とまではいかないでしょうが、わたしも次の理由によりSNSなどでは「いろいろできるすごい人」「低レイヤに詳しい人」と思われがちです。 Linuxカーネルに詳しい。カーネルに詳しい人は無条件でなんでもわかっていると誤解されることが多々ある 自分あるいは自分が所属している組織の成果をよく宣伝する。このため、そういうことを好まない人に比べて「何かできる人」という印象がつきやすい twitter上でそれなりに認知されている、かつ、twitter上で様々なすごい人とよく話している。「すごい人と話しているとすごい」と思われがち。 本記事の趣旨は、その私が世の中で想像されるほどいろいろできるわけではない、できることは限られているということを書いてみようということです。自
日本のでかい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
メモリダンプの模様とはどのようなものなのか(入門編) - 覚書
はじめに 最近バズった以下の記事について、補足のようなものを書きたくなったので書きます。 note.com 上記の記事に対して「模様って何…？」のようなコメントが散見されましたので、カーネルのメモリダンプ解析経験が数年ある筆者が、わたしの理解できる範囲でメモリの模様とはどんなものかについて書きます。なお、模様とはあくまで感覚的なものなので、上記記事で扱われているかたの定義とわたしの定義は違うかもしれませんのであしからず。また、LinuxカーネルやCPUについてのある程度の知識が必要な表現や用語が出てきますが、本記事ではそれらについての説明は割愛します。 メモリのさまざまな模様 メモリの模様とは(少なくとも私にとっては)16進バイナリの文字列の特定パターンです。ここでいうパターンとは正規表現マッチングできるようなパターンのことを指します。その中の代表的なパターンを見てみましょう。 ポインタ
プログラミングでつまづいてきたこと - 覚書
プログラミング初心者に対してどういう情報が役立つのかをぼんやり考えていると、そこそこコードを書けるベテランが、いつ、どういうことにつまづいてきたのかを書くとけっこう有益なのではないかと思ったので書きました。これを読むと直接プログラミング能力が上がるわけではないですが、「ああ、こういうところでつまづいてもいっぱしのプログラマになれている人もいるのだな」と思ってもらうのが目的です。成功談よりも失敗談のほうが役立つとよく言われますが、それと少し似ているのかもしれません。 全段落で「いっぱしのプログラマ」とか言った手前、自分のことを書いておきます。18歳ごろから20年くらい前からプログラミングをしていて、主に有名どころのOSSに向けてコードを書いてきました。昔はLinuxカーネルを10年少々やっていて、ここ最近はCephオーケストレータであるRookの開発とかをしています。プログラマとしてはスーパ
「OSSライセンスの教科書」を読んだ - 覚書
タイトル通りオープンソースソフトウェア(Open Source Software, OSS)のライセンスについて扱った本です。難解なことを筆者の経験を踏まえて平易に解説してくれているので、この手のことを知りたいと相談された場合は「これを読んでみてください」と勧められる本でした。 OSSのライセンスについての知識は近年のソフトウェア開発者には避けては通れません。しかしこれを十分に理解している開発者は多くはありませんし、(とくに「コードだけ書いていたい」というタイプの人には)それほど興味をひく題材ではないというのが実情ではないでしょうか。この状況をなんとかしようと長年OSSに関わってこられた筆者が一石を投じたのが本書です(多分)。筆者が技術者の目線だけ解説するだけではなく、弁護士のかたの監修を受けることによって法律家の目線からも解説しているという点で本書は貴重です。私はこのような本を少なくとも
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
