重要そうだけど興味のないことを頑張っても大していいことなかった話 - 覚書
時間は有限です。その合間を縫ってひねり出した可処分時間は貴重です。こういう時間は自分が楽しいと思えることにとことんつぎ込めばいいと今では思っているのですが、そうではなかった時の失敗談を紹介します。読者のみなさまの中で、好きなこと、やらなきゃいけないことしかできないという私のようなタイプの人には刺さるかもしれないです。 10年近く前の、まだわたしが若手というカテゴリに入っていたとき、当時ずっと生業にしていたLinuxカーネル以外にも、将来のために何かもう一つ引き出しの数を広げておかないといけないと思っていたことがありました。そういうときに飛びつきがちなのは流行りものです。当時のわたしにはそれがARMサーバでした。当時は何やらやらないと取り残されるのではという空気が身辺にありましたし、カーネル屋さんなのでハードウェアに近いところの知識はあればあるだけ損ではないという思いもありました。 ところが
コードの写経中にやってること - 覚書
ソフトウェアのプログラミングの文脈でソースコードの写経と呼ばれるものがあります。簡単に言うとソースコードの読み書き技術の上達のために既存のソースコードを手元で入力する作業です。最近ではgithubなどでOSSが大量に公開されているのでいくらでもできます。 写経は明確に定義がある言葉ではないので、ただ無心に写すという人もいるでしょうし、写しながらその他のことをする人もいるでしょう。ここでは私が「(ソースコードの)写経をする」といったときに何をしているのかを、だれかの参考になるかもしれないので書いておきます。なお、別にこれが唯一絶対とかいうつもりは毛頭ないです。 (とくに不慣れな分野、言語において)何をしたいときにどういうライブラリを使うか、どういうコードを書くかというパターンを覚える、およびそれを体に叩き込む コードを書いたときの作者のお気持ちを推測する 実際に書かれているコードと自分ならこ
べつにQiita使ってもいいんじゃないの - 覚書
Qiitaは悪く言われがちです。よく聞く理由は次のようなものです。 記事の品質が低い 低品質なものが検索上位に来るので邪魔 これらからのコピペばっかでプログラミングしてるやつらが嫌い これらはごもっともだなあと思う反面、そこから一歩先に進んで「Qiita見んな」「見てるやつはエンジニア失格」とか言われるとちょっと違うかなあと思います。ここには良い記事もけっこう転がっているので、やりかたさえ気を付ければとても便利なサイトだと思っていますし、実際けっこう参照しています。 気を付けているのは次のようなことです。 記事の品質の問題 タイトルがそれっぽいものはとりあえず斜め読みしてみる 中身がスカスカだったり論旨が不明瞭だったり煽りっぽかったりする人は容赦なくブロック 検索の問題 文字列検索では、なるべく具体的、かつ、ひっかかる数が少なそうなものにする「kubernetesについて検索したけどk8s
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
