好きなの使って他のをけなさない - 覚書
私が生業とするソフトウェア開発において、OSやコードエディタやプログラミング言語など、様々なソフトウェアを使います*1。これらについて私が使っているものを理由付きで書くと次のようになります。 OS: Ubuntu 22.04 細かい設定をしなくてもそれなりに使える。よく普及しているから色々な情報を得やすい コードエディタ: VSCode 細かい設定をしなくてもそれなりに使える。Remote SSH extensionを使ったリモートマシン上での開発が楽 プログラミング言語: 主にGo 使い慣れているから。システムプログラムをするから。覚えやすいから これらにそれなりの愛着はあるものの、今後置かれる状況によって、どんどん変わってくるでしょう。じっさい10年くらい前はGoはほとんど使っていなくて、Cプログラマでした。 私はこんな感じですが、中には特定のソフトウェアに愛情を注ぐ人もいます。それ自
kindleの本が全部消えた話(3) 「仕様です」編 - 覚書
2022/5/27 変更 - この挙動が仕様ということを示すamazon.comのヘルプページへのリンクを張るとともに引用した - amazonのサポートに、amazonの指示によって問題のある操作をしたことがわかる通話履歴があるはずの日時を伝えた - amazon.comのサポートセンターに諸々書くにした旨追記 - こちらからamazonへの要求について補足 2022/6/1 変更 - 「サポートの指示によってamazon.comのアカウントを消した」のではなく「使用していないamazon.comのアカウントを閉鎖してもいいのか」という趣旨の質問を私がしたのに対して「そうですね」と回答されたということがわかったので、訂正。 編集前の記述には取り消し線を引いて、編集後の記述は強調表示しました。 NOTE: 上記変更点にもあるように、「サポートの指示によってamazon.comのアカウントを
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 何をするにも知名度の有無によって注目度は変わります。極端な話をすると、誰かがものすごいことを成し遂げたとしても、誰とも接点が無い人がやれば誰にも知られず、すでに名のある人がやれば注目されます。なので知名度があればそれだけでいいか…というとそうではないです。 知名度の高まりかたにはいろいろと種類があります。そのうち一つは名声を博することです。名声を博するには技術者としてのスキルや地道な実績の積み重ね、場合によっては自己プロデュース能力が必要です。とてつもなく凄いが目立つのを嫌う人もいるので一概に知名度があればいいというものではないですが、その話はここでは置いておきます。 その一方で、人から眉をひそめられるようなことをすると悪名がとどろきます。これには別に技術者としてのスキルは必要ないので名声を博するよりも簡単です。
ヘタクソなコードを書いてもいい - 覚書
プログラミング言語のお作法から外れたコードやメンテ性が悪いコードを書くのはダメとよくいわれます。わたしは学生の頃、そういう意見を過剰に気にしていました。コードを書くことそのものに慣れていないのに綺麗に書こうとして手が動かず、動かないがゆえにコーディングの練習が進まない、という悪循環になっていました。そうすると何もアウトプットしないまま知識だけが増えていって、自分がこれくらいできそうというイメージと実際のプログラミング能力とのギャップで苦しみました。 この意識が薄れたのは、あるときものすごく手が早い人のコードを偶然見たときでした。たしかにちゃんと動くものができているんですが、そのコードの中身は当時の私の基準からいって*1おぞましいほど汚いものでした。そこで「これはわたしが書けば100倍くらい綺麗なコードを書けるんでは…」と一瞬思ったんですが、その後すぐに「あ、自分は知識はあるけど練習してない
仕事としてOSS開発者をやってきた話 - 覚書
はじめに わたしは今も昔も仕事としてOSS開発者をしていて、twitterなどでそれなりに名前が知られていることもあって、昔から「どうすればそういうこと(業務としてOSS開発)ができるのか」「どういうキャリアを歩んできたのか」「Linuxカーネル開発者になるにはどうすればいいのか」ということをよく聞かれてきました。当時わたしが置かれた環境と現在の環境では違いがありすぎるので公開に積極的にはなれなかったのですが、一つの過去事例として何らかの意味はあるかもと思って公開することにしました。 書き方が難しかったのですが、うまくまとまらなかったので、自分が書くのが楽な日記みたいになりました。 きっかけ 2000年初頭に学部4年のころにLinuxを触りはじめてから「UNIXとかLinuxってすげえ」「こんなものが無償で使えるのか」「これらのソースコードが全部見られるのか」と感動して、「自分も成果物を公
APIとかABIとかシステムコールとか - 覚書
はじめに 本記事はLinux環境における次のようなことをざっくり理解するための記事です。 Application Programming Interface(API)って何? Application Binary Interface(ABI)って何? システムコールとAPIとABIの関係って？ それぞれ何がどう違うの? この手の情報はググればwikipediaやらにいろいろ情報が載ってるんですが、初心者が理解するには細かいことまで書かれすぎていて、かつ、それぞれの関係がわかりにくいです。なので、用語を逐一解説するのではなく、ありがちな質問のQAという形をとりました。人によって用語の意味の揺らぎがあったりするんですが、私の解釈ということで。あからさまに間違っていたら指摘していただけると嬉しいです。 これを書こうと思ったきっかけは、以前こんなtweetを見かけたことです。それから「そういえば最
github sponsorでスポンサー募集することにしました - 覚書
以前よりわたしはOSS、とくにLinuxカーネルなどのハードウェアに近い部分のものについての普及活動にライフワークとして取り組んできました。そのうちの一部は書籍として販売して印税を受け取ったり、雑誌に掲載してもらって原稿料を受け取ったりしてきましたが、ほとんどのものは無償で公開しています。この無償で公開している部分についてgithub sponsorsを使ってスポンサーを募ることにしました。 github.com github sponsorsで支援を受ける人といえばOSSのコードやドキュメントへの貢献者というイメージがあるでしょうが、私はOSSおよびその関連技術についての普及活動をする人、として登録しました。なぜこういうことをするかというと、理由は大きく2つあります。 1つ目は単純に「お金ほしい」です。お金をもらわなければ活動をやめなければいけないといった切羽詰まった話では全然ないのです
twitterでのふるまいで気を付けていること - 覚書
twitterは有益なことが多々あるんですが、ちょっとしたことでストレスを溜めたり、他の人に害を及ぼしたり、身を滅ぼしたする可能性があります。それを避けるためにわたしが気を付けていることを書き連ねてみました。別に「みんなもこれやろうぜ！」とか「これをやったら必ずストレスフリー」とか言いたいわけじゃなくて、この中のどれか一つでもなるほどと思えば参考にしてもらえれば、という意図で書いてます。 自分の意にそわないこと、ばかげていると思っていることを「世の中にはこんなにけしからん人がいますよ、ひどいものがありますよ」とわざわざ紹介するのを避ける*1。「不快だ！」というだけでは不快の再生産になるだけかなと 特定の人物、事物をこき下ろすようなことはしない。単に好みでないというのもあるが、まわりまわって身を滅ぼすリスクもある。それは発言した瞬間だけではなく、何年も後になったときかもしれない。たとえば自分
実体の無い完璧超人と戦っていた過去の失敗談 - 覚書
かつての失敗談。ついった初めたばかりのころにはまった次のような悪い循環です。 すごい人をたくさんフォローする すごい人達がすごいこと言ったりやったりする それに比べて自分は大したことできないと自信喪失する 何もしなくなる フォローする人が多くなればなるほどこの傾向は加速していきました。なぜかというと、それぞれのすごい人達の凄い部分を全部合成した完璧超人と戦おうとしていたからです。 たとえば次のような3人をフォローしたとします。 RDBにめちゃくちゃ詳しい人 カーネルめちゃくちゃ詳しい人 特定のプログラミング言語にめちゃくちゃ詳しい人 ここで私は「RDBにもカーネルにも特定のプログラミング言語にも全部めっちゃ詳しい超人」を脳内で作って、その架空の超人を見上げて自信喪失していたのです。 この誤解が解消したのは、のちのち各種カンファレンスや勉強会などに参加して彼らに出会う幸運に恵まれたときでした
Ryzenにまつわる2つの問題 - 覚書
NOTE1: 2017/8/12に2つ目の問題について更新しました。ついに両方の問題が解決しました。 NOTE2: 2つ目の問題についてはすべての経緯をまとめた書籍があります。 4月にRyzenを積んだデスクトップマシンを買いました。その上で日課であるカーネルビルド&テストをした*1ことをきっかけに、2つの問題が発生しました。先代のCore i5を積んだマシンでは起きなかった現象です。 このエントリは自分用のメモがてら、新しいことがわかれば随時更新していきます。後者については9月に開催されたkernelvm北陸にて、本ブログには書かれていない解析の詳細などについて発表してきました。 Ryzen segv battle from Satoru Takeuchi www.slideshare.net 環境 ハードウェア CPU: Ryzen 1800X Motherboard: ASUS PR
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
