2020-09-17

休みの日は休めばいい

以下の記事にマージしました。

satoru-takeuchi.hatenablog.com

昔この記事を書いたのを忘れて似たような記事を書いたのと、両者とも似たようなことを書きつつ違うことも言っていたのがその理由です。

2020-08-30

「概説中国史」を読んだ

これまで中国の各時代の歴史についての本をいくつかばらばらに読んできたのですが、その後に、これらが現在の中国にどのようにつながっているのかを知りたくなって買ったのがこの本です。教科書的に淡々とその時々に起きたことを述べていくスタイルなのですが、退屈になることはまったくなく、すらすらと読めました。数十冊にわたるごっついシリーズではなく高々数百ページずつの上下巻というのが飽きっぽいわたしに丁度よかったです。これからまた各時代について深堀りした本を読む気にさせてくれました。そのときもこの本をまた参照することになるでしょう。

2020-08-30

「米の日本史」を読んだ

日本の歴史を日本人とは切っても切り離せない米と言う観点から見た本です。米と日本の関係については「縄文時代から弥生時代に伝わってきて云々」程度の歴史の教科書で学んだ知識しかない私にはいままで想像すらしていなかった多くの知識が得られました。たいへんよい本でした。たとえば稲作伝来については、今日本で主に食べられている品種以外のものを含めた様々な種類の稲がいつどこから伝わってきたのか、その後でどういう理由で現在に至ったのかを、そう考えるに至った理由を含めて丁寧に書かれていました。その他のトピックについても非常に興味深い内容ばかりで、一気に読み切ってしまいました。

2020-08-23

趣味でプログラミングをはじめようとするときの様々な誘惑

趣味でプログラミングをはじめようとする人が陥りがちな罠と、それについてのわたしの考え方について書きます。一部については私が実際にひっかかった罠で、それ以外は自分以外の人を見ていて思ったことです。仕事だと話は変わってくるのですが、それについては触れません。

情報量が多い昨今、「さあプログラミングをはじめよう」となっても、目の前には次のような様々な選択肢が待ち受けています。

初心者はこれらのうちのどれを選ぶべきかというところでまず躓いて、まったく先に進めなくなることが多々あります。ただ、このへんは使ってみなければわからない好みの部分が非常に多いので、まずはフィーリングで適当に選んで、合わないものがあれば別のものに乗り換えればいいと思います。なんなら複数を使い分けてもいいんです。

迷いで頭がいっぱいになってしまったら、自分のやりたいことはプログラミングをはじめたいことであってツールを選びたいわけではない、とにかく手を動かしてプログラミングしないと何も始まらない、ということを思い出してもらいたいと思います*1。

参考までに、たとえばわたしは次のような流れで使うツールを選んできました。

プログラミング言語: なんとなくCがかっこよさそうという理由ではじめて、そのままOSカーネル屋さんになったので使い続ける。日々の作業を楽にするためにbashやらRubyやらを覚えた。Pythonは流行ってたので使ってみようと思ったが音楽性の違いを感じて大して使わないまま、現在は「そこそこ読めるけどあんまり書けない」という状態になっている。あとは仕事でGoを使うようになって、かつ、気に入ったので今も愛用している。
OS: 最初はWIndowsを使っていたが、Linuxインストールブームの火が残っていた大学4年生のころに「なんとなくかっこよさそう」「すごそう」という理由で使い始めた。いろいろなツールが無償で手に入って便利だったので、そのまま今に至る。WindowsやmacOS上での開発については、やる必要を特に感じていないのでやっていないだけ
テキストエディタ: Linuxに入門したころ、当時流行っていたemacsとvimの2つのうちのどちらかを選ぼうと根拠の無い決意をして、2つ評価をして上で、より気に入ったemacsを使うようになった。その一方で、vimもrootで作業するときなどに使っている。その後15年ほど経過した去年、.emacsの編集に疲れていたころに「俺は別にエディタの設定をしたいわけでもelispを愛しているわけではないなあ」と気づき、かつ、VSCodeが複雑な設定をしなくてもよくて楽らしいと聞いた。使ってみたら実際その通りだったので、emacsを完全引退して今も使い続けている。

この考え方に異論がある人はいくらでもいるでしょうが、これは「私の意見」なので、とやかく言われる筋合いはありません。みなさんも最初はフィーリング、その後は人の意見を参考にしつつも、あくまで自分の感性を信じて心地よいものに次第に移っていけばいいと思います。

これ以外にも「プログラミングするからには開発を支援するツールをマスターしなければ」と、必死に次のようなものの網羅的な知識を得ようとして疲弊している人をよく見ます。

gitなどのバージョン管理システム
CircleCIなどのCIツール
Redmineなどのバグ管理システム

これらについても、こだわり出すといつまでたってもプログラミングをはじめられないので、まずは小さなプログラムをたくさん書みることをおすすめします。その後に実際に困ったときに使い始めて、かつ、必要なところだけを徐々に覚えていくとよいでしょう。

とくにgitは機能が異常に豊富で、マスターしようなんて思うとかなりキツいですし、そんなことをする必要もありません。実際わたしもgitのコマンドで知っているのはおそらく20個ほどだけですし、それらのオプションについても知らないもののほうが多いです。

上記のツールが必要になるタイミングは典型的には次のようなときでしょう。

gitなどのバージョン管理システム: ソースコードのどこをどんなふうに変更したかがわからなくなったとき、安定版と開発版を分けたくなった時、複数人で開発をするとき*2。
CircleCIなどのCIツール: マージ前、リリース前の手動テストが苦痛になったとき
Redmineなどのバグ管理システム: 複数人で開発するようになったとき。脳内で問題を覚えておくのが苦痛になったとき

いろいろ書きましたが、最後にまとめ。枝葉末節にこだわらず、本来やりたいことをするのを最優先に考えましょう。たのしくプログラミングしましょう！

*1:その後ツールにのめりこんで楽しくなった、というのであればそれはそれでいいです

*2:おそらくgitはこのリストの中で一番早く使い始めることになるでしょう。すぐないとやってらくなると思います

2020-08-10

重要そうだけど興味のないことを頑張っても大していいことなかった話

時間は有限です。その合間を縫ってひねり出した可処分時間は貴重です。こういう時間は自分が楽しいと思えることにとことんつぎ込めばいいと今では思っているのですが、そうではなかった時の失敗談を紹介します。読者のみなさまの中で、好きなこと、やらなきゃいけないことしかできないという私のようなタイプの人には刺さるかもしれないです。

10年近く前の、まだわたしが若手というカテゴリに入っていたとき、当時ずっと生業にしていたLinux カーネル以外にも、将来のために何かもう一つ引き出しの数を広げておかないといけないと思っていたことがありました。そういうときに飛びつきがちなのは流行りものです。当時のわたしにはそれがARMサーバでした。当時は何やらやらないと取り残されるのではという空気が身辺にありましたし、カーネル屋さんなのでハードウェアに近いところの知識はあればあるだけ損ではないという思いもありました。

ところがこれが大失敗。本を読んだりラズパイを買ったりしてみたものの大して熱がこもらず大した知見が得られないままに時間を浪費するというありさまでした。ここで何がまずかったのかを振り返ってみたところ、一番の原因は「ARM,もっというとCPUのアーキテクチャに大して興味がない」ことと、「好きなこと、やらないといけないことしかできない」という自分の特性の強さをあなどっていたということでした。気づいてしまえは当たり前で、やる前に気付けよといったところですが、当時は焦りからか非常に視野が狭くなっていたのでしょう。

この後は考え方を変えて、次のようにバッサリと割り切りました。

今持っている技術が陳腐化しそうになったら、その時はその時、追い詰められたら奮起する能力は持っているのでなんとかなるだろう
一番興味があるものから順番に学んでいれば将来それらに活路が見いだせるかもしれない
無理して頑張っても、楽しく学んでいる人にはどのみちかなわない

この変心が正解というつもりはまったくないですが、将来の来るかどうかわからない危機に対して確実でもなんでもない備えを苦痛に耐えながらやり続けるよりも、楽しいと思えることを効率よく学べている今のほうが幸せだとは思います。

この文書がわたしと似た特性を持つ人に参考になれば幸いです。おわり。

2020-08-01

DeepLで論文を邦訳して読んだ

以前日本からはDeepLは課金できなかったんですが、少し前にできるようになりました。

satoru-takeuchi.hatenablog.com

その記念といってはなんですが、Webブラウザのテキストボックスに入れた文書を訳すのではなく"Translate whole files"というファイルを丸ごと翻訳する機能を使ってみました*1。

私が今回この機能を試す際に使ったのは"Decoupling Cores, Kernels, and Operating Systems"という未読の英語論文です。

www.usenix.org

なぜもっと一般的な文書ではなくわざわざ論文なのかというと、理由は2つあります。1つは単に他に別に読みたいものが無かったこと、もう一つは、未読の英語論文を計算機が邦訳したものをどれだけ理解できるかに興味があったからです。

さて、この論文はpdfとして公開されているのですが、残念ながらこの機能で現在訳せるのはwordのファイル、powerpointのファイル、そしてテキストファイルだけでした。しょうがないので次の方法を使いました。

pdfをgoogle docsに食わせる
docxにexportする
docxをDeepLに食わせる

で、それっぽい日本語が出てきたので喜び勇んで読み始めたら、何を書いているか全然わかりませんでした。文法的に日本語として成立しているけれども何が書いてあるかはわからない、といったところでしょうか*2。技術カンファレンスにおける技術者ではない翻訳のプロによる同時通訳くらいのものを思い浮かべてもらうといいかもしれません。

「これで英語理解できなくても英語論文が読める！」なんというのにはほど遠いですが、翻訳ソフトはここまでできるようになったのか、と感心してしまいました。すごい。

最後になりますが、たぶん専門用語が少ない文書ならもっといいのが出てくると思います。

*1:無料版でも使えるんですが、文字数が限られるらしいです

*2:その後英語で一ページ目を読んだらちゃんと理解できる内容だったので、読解に必要な能力不足というわけではないはず

2020-07-22

github sponsorでスポンサー募集することにしました

以前よりわたしはOSS、とくにLinux カーネルなどのハードウェアに近い部分のものについての普及活動にライフワークとして取り組んできました。そのうちの一部は書籍として販売して印税を受け取ったり、雑誌に掲載してもらって原稿料を受け取ったりしてきましたが、ほとんどのものは無償で公開しています。この無償で公開している部分についてgithub sponsorsを使ってスポンサーを募ることにしました。

github.com

github sponsorsで支援を受ける人といえばOSSのコードやドキュメントへの貢献者というイメージがあるでしょうが、私はOSSおよびその関連技術についての普及活動をする人、として登録しました。なぜこういうことをするかというと、理由は大きく2つあります。

1つ目は単純に「お金ほしい」です。お金をもらわなければ活動をやめなければいけないといった切羽詰まった話では全然ないのですが、趣味とはいえ限りある可処分時間*1を費やして人のためになるであろうコンテンツを提供しているので、可能であれば対価を受け取りたいと思っています。

2つ目は私の好むお金の流れを作れないかなという実験です。私は常々、お金は余裕のある人や年長者から余裕のない人、若者によどみなく流れていくのがよいと思っています。この考えをもとに、私が提供するコンテンツが後進のために有用だと思ってくださるかたに支援していただき、コンテンツを必要としているかたがたに無償で提供する、というような流れが作れればと思っています。

スポンサーが増えたらどうなるかというと額にもよるのでなんともいえませんが、たとえば次のような展開が考えられます。

コンテンツの更新頻度が増える
いままで有償で公開しようと思っていたものを無償公開することが増える
コンテンツの英訳をする(現在はほとんどが日本語)

2022/10/11追記上のリストには、もともと"- youtube動画コンテンツを収益化しない(つまり広告を出さない)。現在は収益化条件を満たしていないので広告は出ませんが、いまのところ条件を満たせば収益化する予定でいます"という文書がありましたが、いまいち何言ってるかわかりづらいし、そもそも誤解に基づいた記述だった(実は今は収益化してなかろうと広告が出る)ので消しました。

どうなるのかよくわかりませんが、わたしがやっていることに賛同してくださるかたはぜひご支援いただけたらと思います。

以下、いままでやってきたことリストです。