スキマ時間をスキマのままにする

スキマ時間というやつがあります。典型的には何かやった後、次に別の何かをやる前のほんのひと時。こういう時間の使い方はさまざまで、SNS見る人、本を読む人、音楽を聴く人、動画を見る人、短時間でできる勉強をする人、などなどがいます。

昔よく自己啓発本を見ていた時期があって、そのときは多くの本に「スキマ時間を利用して自分の価値を上げる。一日わずかづつでも成長すれば一年後には大きな差が…」というようなことが書いていました。当時の私はスキマ時間に読書したりネットサーフィンしながらダラダラしていたんですが、このようなものを見てからは技術書を読んだりして勉強するようになりました。その後、成長スピードはたしかに上がったんですが、それは短期間しか続きませんでした。だんだんと疲弊してきて、すぐに色々なものの能率が下がって、その後は低空飛行を続けました。

この不調はスキマ時間にダラダラするようになったらあっさり回復しました。無為な時間の使い方をしていると昔は思っていたけれども、実はそれは直接生産的なことをしているわけではないですが、ちょうどいい休息になっていたのでしょう。

いまではこの休息の効果を最大限に高めるべく、スキマ時間にはノイズキャンセリングヘッドホンをつけたり眼を瞑ったりして入力を極力減らしつつ、ぼーっとしてます。読書したりネットサーフィンもせず、本当に何もしません。最初は「何もしないこと」にかなり抵抗がありましたが、今ではすっかり慣れました。

もちろん時間をどう使うのがよいかは人によって違います。詰め込めるだけ生産的なことをするほうがいい人もいるでしょうが、それではうまくいかずに、実はとことん何もしないほうがマシだった人もいるという話でした。

kindleの本が全部消えた話

2022/5/27 変更
- 後述のアカウント統合後にamazon.comのアカウント削除によってkindle本が全部消えるのは仕様である旨、追記

2022/6/1 変更
- 「サポートの指示によってamazon.comのアカウントを消した」のではなく、「使用していないamazon.comのアカウントを閉鎖してもいいのか」という趣旨の質問を私がしたのに対して「そうですね」と回答されたということがわかったので、訂正。

編集前の記述には取り消し線を引いて、編集後の記述は強調表示しました。

NOTE: 上記変更点にもあるように、「サポートの指示によってamazon.comのアカウントを消した」という私の認識は誤っていたことがわかりました。これについてはamazon.co.jpのかたがたにメールで謝罪いたしました。

ここに書いたことは2022年4月21日現在の話です。

サマリ

あらすじ

しばらく前にamazon kids+についてトラブルが発生したのでamazonのサポートに問い合わせたところ、どうやら前節において書いたアカウント統合に起因する問題ではないかということになりました。いろいろ切り分けた後に、サポートの指示に従って(上述の通り、これは記憶違いの誤りだった)、もう使っていなかったamazon.comのアカウントを消しました。するとkindleの本が全て消えました*1。より正確にいうとアカウント削除依頼から実際にコンテンツが消えるまでには90日待つことになっていて(その間は削除をキャンセルができる)、kids+の件でアカウント削除処理をしてから90日後の4/9にkindle本全滅問題が発生しました。

その他に発生した問題

Androidのアプリからはamazon prime videoにもprime musicにもアクセスできなくなっていました*2。具体的にどうアクセスできないかというと、これらサービスを使うためのアプリからamazon.co.jpのアカウントにログインできなくなりました。なお、アプリにログインできないという点ではkindleアプリも同様です。

さらにいうとamazonの買い物用のアプリもログインしてから最短で数秒ほどでログアウトされてしまいます。事後に物理本を買ったところちゃんと買えたし届いたので、物理的なものを買うのは強制ログアウト問題は置いておけば大丈夫のようです。しかしkindle本はそうはいかなくて、試しに0円の本を買ってみると買えばしてリストには出てくるけど読もうとしたらログアウトされる、という具合でした。つまり現在このアカウントでkindleがまったく使えない状況になっています。

アカウント統合についての思い

アカウント統合のしくみはよくわかりませんが、統合後にデジタルコンテンツはamazon.comのアカウントが引き続き持っていて、このアカウントを消すと全滅するというような仕組みなのかもしれません。ここはただの仮説。

twitterでこの件についてブツブツ言っていたら、他にもアカウント統合後に私と同じあるいは似たような問題に遭遇した沢山の方々から報告をいただきました。また、事象発生後にサポートのかたから「アカウント統合後にamazon.comのアカウントを消すとkindleの本が消えるという既知の不具合がある(必ずなのかどうかは未確認)」と伺いました。やばそう。

そんなこんなで、どうもアカウント統合後にはろくなことが起きないようなので、どうしてもという強い理由がなければやめておいたほうがよさそうです。少なくとも自分は二度とやりたくないです。

現状

実はまだ今後の対応が決まっていなくて、引き続き困っています。サポートの方とのやり取りは続いていますが、現在は次のような状況です。

  • 対応方法については協議中
  • 現時点で回答の日時を伝えられない
  • 週に一回連絡する

というわけで、お金が絡む話なので慎重にならざるをえないことは理解するものの随分ノンビリしてるなあと思いつつ、強権発動できる立場でもないために打つ手がとくにないので、ただ、待ってます。

誰か内部に働きかけられる人がいたらなんとかして…

*1:アカウントサービスからデジタルコンテンツを確認したら本のリストが空になっていた

*2:PCからは確認していません

Kinesis日本語配列モデルを買った

何年か前に人がが使っているのを見てかっこいいなと思ってたやつ。生活に刺激が欲しかったこと、将来的な腱鞘炎の発生を予防したかったことが決め手になりました。買ってから一週間くらい使ってみた感想を軽く書きます。なお、買ってからは三週ほど経ってるんですが、諸々あってまともに触れたのが現在一週間程度なのです。

これまで使っていたのは日本語配列のHHKBです。

Kinesisを使い始めてから一週間経ったところ、元に比べて日本語入力は60%から80%くらいの速度で入力できるようになりました。プログラミングは記号入力にかなり手間取るので、元に比べて40から50%くらいの速さです。たしかに手や腕をほとんど動かさず入力できるので、将来的にはかなり快適になると期待できます。

これまでに辛かった点をいくつか挙げておきます。

  • backspace, delete, space, enterあたりを親指で押す。具体的にはbackspaceが左親指のホームポジションにあり、deleteはその右にある。spaceが右親指のホームポジションにあり、enterはspaceの左にある。これらの配置はわかってくると最高なんだけど、そうでないうちはいちいち何をするにもひっかかるので辛い。わたしはある程度勘を掴むのに三日くらいかかった
  • タッチタイピングができるのが前提に近い。わたしは指を移動させまくるなんちゃってタッチタイピングだったので、いちいち「いつもはBを右指で押していたが、セパレート型であるがゆえに左指で押さなければならない。が、長年の癖はなかなか抜けないので戸惑う」「いちいち左右に一つずれたキーを押してしまう」などのしょうもない問題に引っかかった。というか、まだひっかかっている。タッチタイピングをもとからちゃんとできる人は多分習熟までの時間は短くなる
  • いくつかのキーがかなり変なところにある。例えば”\”と”_”のキーは普通の配列なら右端あたりにあるが、Kinesisでは親指で押す。場所はenterの左。"\"と"|"のキーは"x"の真下にある。
  • 一番つらいのが"^"と"~"の入力。左下あたりの”z”の真下にある"keypad"という特殊キーと、その右にある"\"と"|"のキーを同時に押さなければならない。これらの文字はわたしが使うプログラミング言語ではあまり出現頻度は高くないが、毎度余計なキーを押さなけれなならないのはあんまりうれしくはない*1

ある程度ストレスなく使えるという段階にたどり着くまでには、あと1,2週はかかるんじゃないかという印象があります。がんばっていきたいと思います。

*1:英語配列では"z"の下には”keymap"特殊キーはなくて通常のキーが割り当てられている

会社員になる前の話

以下エントリのさらに前の話です。

satoru-takeuchi.hatenablog.com

小学校時代あたりから大学に入る前あたりまで。勉強できたかどうかとか、プログラミングに興味を持ったきっかけとか、どうやって成長してきたかとかそういう話。私の書くこの手のエントリでよく前置きをするように、やりたいことだけやりたい、やりたくないことは嫌いだし苦手、というタイプの人には役立つかもしれません。

小学校の最初のほうは算数とかが得意だった気がします。ただその後は反復練習をするのが嫌いだったり、一回授業を受ければすべて理解できるほど頭よいわけでもなかったので、順調に落ちこぼれました。このころは漫画読んでゲームして、くらいしかしてなくて、漫画家になりたいとか思ってました。従兄がMSXを持っていて、かつ、ベーマガのサンプルコードを自分で打ち込んでゲームやってたりしたので「プログラミングってすごい、ゲームが自分で作れる」という認識はここでできました。兄は勉強ができて、かつ、面倒見もよかったので、どこに行くにも兄と一緒で、兄に依存して、何も自分では考えずに頭に霞がかかったように、ぼんやり生きていました。

高校は地域内で勉強苦手な人がギリギリ入れるくらいのところに行きました。当時、その高校の中では中くらいの成績だったような覚えがあります。このころ、過去のMSXの記憶を思い出して漠然と「パソコンがあればゲーム作れるのか、作ってみたい」と思ったり、「ゲームプログラマで生きていければ楽しんでお金もらえてよさそう」とか思ってた気がします。1年の中盤あたりでたまたま物理の試験の点数がえらく高かったので、「ああ、自分は何もできないと思ってたけど、できることがあるのか」と思って、頭の霞が少し晴れました。そのときはあんまり意識しなかったんですが、実はこれが人生の重要なターニングポイントだったかも。自己肯定感と成功体験大事。あと、進学のときにうっかりもう少し難しい高校に進んでいれば、この体験がなかったかも。

高1の終わりくらいにたしか兄がPC買ってもらって自分もちょっと触ったんですが、プログラミングにさほど興味は示さず、兄がベーマガを見てなんかポチポチ打ち込むのを見ていたくらいでした。インターネットにもつながりましたが、2chなどのテキストサイトを見てるくらいで、とくに生産的なことはしていませんでした。そのころあったRPGツクールDante98というツールでゲームを作ろうとしたものの、よくある話で根気がないので続かず。高校2年から文型と理系のクラスに分かれることになったんですが、数学や物理がそこそこできたのと、「英語やりたくない」という理由で*1理系コースに行きました。

高校2年あたりで兄が大学進学のために実家を離れました。するといろんなことを自分で考えるようになって、これまた意識が大きく変わったことを覚えています。のちに家族からも「あれをきっかけにずいぶん変わった」と言われました。彼が残していったPCを使って、簡易プログラミング言語のようなものでいくつか小さいゲームを作っていました。このあたりで「プログラマ(主にゲームプログラマ)になりたい」「情報系の学科を受験したい」と固く決意したのを覚えています。そのころインターネットなんて使えないとか、それとは別に、前述の成功体験でいい気になって、なんやかんやで勉強して成績がよくなり、高校の成績が一番になりました。勉強できない人がいく高校の一番ではありますが、一番は一番なので気持ちよかったです。成功体験大事again。

そのあとは見事に慢心して勉強しなくなり、情報系学科の受験に失敗しました。受験した大学の別の学科に滑り込みで入れたので、なんとか首の皮一枚つながりました。あのとき浪人していたら多分勉強せずに順調に落ちぶれて、今も実家でグダグダしていたかもしれません。その学科は偏差値でいうと50切るくらいだったと記憶しています。高校でトップだったとはいえ、世間的には勉強できないのは変わりません。センター試験で数学や物理などのいわゆる理系科目よりも国語の点数が圧倒的によかったので、「一体自分は何者なんだ」と思った記憶があります。これはのちのちテクニカルライター個人事業主としてやる伏線だったのかもしれません。

大学に入ってからは専門教育も一般教育にもとくに身が入らず、B1の最後の成績は悲惨なもので、このままでは留年必至という状況になりました。ここから奮起してたくさん勉強して、最終的にはまあまあの成績に落ち着いてB4に至りました。毎度毎度、ギリギリになるまでは徹底的にサボり、その後に謎のパワーでピンチを切り抜けています。これはいまでも変わっていません。このころには「ああこれはこういう性格なのだな」と、ある程度割り切るようになっていました。自分を知るの大事。それ以外には数学と現実(専攻分野であった材料工学)が結びつくという体験ができたので、何かに開眼したように記憶しています。知識のリンクですね。この快感はすごい。

プログラミングについては徐々にマニアックなことをするようになってきました。

  • 「このテキストファイルはPC上にどのように保存しているのだ」と思ってデータをバイナリダンプしたり文字コードの概念を知った
  • 「プレステのゲームのポリゴンってどうなってるんだ」と思って三角関数を学んでポリゴナイザを作った
  • 「画像ファイルはどう表現しているのだ」と思って(たしかWindowsbmp形式ファイルの)エンコード方法を解析して、画像描画エンジンを作った
  • 「プログラムの起動は誰がやってるんだ。OSというのがやってるらしいが、そのOSは誰が起動するのだ」というのを考えてOSとかカーネルの存在に気づいた

なんかこう、レイヤが下がってきましたね。このころから「自分にはゲームプログラマになるためのセンスも情熱もないな」と感じるようになってきました。それとはいれかわりで「そのさらに下のしくみがおもしろそう」と思うようになってきました。

B4ではまたしても落ちぶれて、「興味がないことはないが、これで一生食っていける気がしないし、やりたくないし、一流には決してなれない」という強い思いがあって、一発逆転を狙ってサーバベンダのLinuxカーネル開発部署へのインターン応募に突撃することになりました。

後の流れは冒頭に紹介した記事の通りです。振り返ってみれば綱渡りのような人生を歩んできていますが(今もそうです)、そもそも自分はコツコツ勉強して着実に成果を出していくというのはストレスフルで困難なので、多少進路が変わったとしても、結局この手のギリギリの生き方をするしかなかったのかなあと今は思っています。人生人それぞれですよ。でもコツコツできる人はやったほうがいいと思いますよ。わたしはたまたまうまくいっただけで、わざわざ好き好んでハイリスク人生を送る必要ないと思います。

おわり。

*1:それは完全に間違いだったんですが

2021年の振り返り

今年も何をやったか振り返っておきます。

会社員としての仕事

ストレージチームのメンバーとして、ひたすら社内新インフラのストレージ開発をしていました。成果は以下の場所にK8sマニフェストとしてまとまっています。

github.com

github.com

成果は以下のような形で外部発表しました。

speakerdeck.com

speakerdeck.com

speakerdeck.com

Rookのメンテナという立場では去年に続き自分でコードをコミットしたのはもちろんレビュー回数がその倍以上になったので、メンテナの仕事をちゃんとやってるなあと年末に実感できました。それに加えて今年のKubeCon+CloudNativeCon 3回すべてで登壇して、デモを担当しました。

kccnceu2021.sched.com

kccncna2021.sched.com

kccncosschn21.sched.com

このうちヨーロッパ開催(といってもVirtualですが)のものについてはKubernetes Meetup Tokyoにおいてrecapもしました。

speakerdeck.com

わたしが仕事でかかわっている主な社外OSSはRookとCephで、去年まではコミットのほとんどがRookだったのですが、今年からはちょくちょくCephにも顔を出すようになってきました。Cephもコア開発者になれるくらいの実力を身に着けて前述のインフラの安定稼働に向けてこれからも頑張っていきます。

あとは会社員として前職を含め初めて雑誌記事を書きました。Software Design 12月号の「OSSとの上手な付き合い方活用」という特殊の1,2章を担当しました。

gihyo.jp

個人事業

Software Designの4月号の「新人教育に役立つLinux総復習」という特集のプロセス管理の章を担当しました。昔はこの手の情報は骨の髄に叩き込んでいるはずでしたが、実は叩き込まれていなかったようで、ジョブ管理のあたりとか、わりと忘れていることが多くて思ったよりも多くて書くのに難儀したと記憶しています。

gihyo.jp

以前出した、ブログや後述のzennに書いたIT系のエッセイをまとめた同人誌の第二版を出しました。第一版に続き好評だったようで何よりです。次の次の技術書典で三版も出す予定です。

techbookfest.org

あと二冊目の単著の原稿の完成が見えてきたので、来年の春ごろに出るとうれしいなあとか思っています。といっても今泣きながら仕上げをしている段階なので、まだまだわかりませんが…

IT系の無償情報発信系

たくさんあるので全部書ききれないんですが、ざっと書くとzennの記事21本、youtube動画7本、などなどです。

zenn.dev

www.youtube.com

これらのやる気の源泉となるgithub sponsorsにもone time、monthly両方についてたくさんの寄付をいただきました。みなさん本当にありがとうございました。

github.com

今後もこの活動については「活動に賛同してくださるかたがたから寄付を募って、それを気合いに変換してコンテンツを作って無償提供」というやりかたを続けようと思います。

趣味

コロナ禍のおかげで外出が減ったこと、および外出しても行くところが非常に限られているという事情によってカメラの出現回数が去年に続き少なかったです。飽きたわけでは全然ないので普段見慣れているものを撮るであるとか家の中の小物を撮るとか、新しい試みをしようかと思っています。

去年までは作業中にコーヒーばっかり飲んでいましたが、飲みすぎで不調を来すことがよくあったので、中国茶や紅茶を飲み始めました。中国茶工夫茶器がかっこいいので買いました(リンク先の店でではないですが)。おいしいし見た目も美しいので非常によいです。

コーディング系でいうといままでPython嫌いだったんですが新しい本のサンプルコードを書いているうちになかなかいいなと思えるようになってきました。

まとめ

あいかわらずインプットに比べてアウトプット過多で生き急いでいるふうですが、何もしないよりはいいのかなとか思ってます。

「Linuxのしくみ」のサンプルコードの改善

拙著「Linuxのしくみ」の一部のサンプルコードを改善したものを公式githubリポジトリに置きました。一部についてはグラフ描画もしてくれるように変更しました。

amzn.to

Ubuntu20.04において動作する、本書において書かれたCプログラムをGoやPythonに移植して、かつ、コメントを日本語にしたものを各章のmiscディレクトリに入れています。必要なパッケージは以下の通りです。

binutils, build-essential, golang, python3-matplotlib, python3-pil, fonts-takao

2章

3章

4章

  • sched: sched.cに対応するPythonプログラム。結果をグラフ化にして"sched-<並列度>.jpg"に保存。

以下、1CPU上でschedプログラムを動かした結果を示すグラフです。上から順番に1並列、2並列、3並列のものです。

5章

6章

  • cache.go: cache.cに対応するGoプログラム。go build cache.goでビルドできる。

以下、cacheプログラムを1CPUコアあたりのL1d,L2,L3キャッシュ容量がそれぞれ32KB,512KB,4MBのCPU上で動かした結果を示すグラフです。

書籍を使った勉強のしかた

わたしがこれまでに書籍でなにか新しいことを学ぼうと思ったときにどういう手段で目的を達成してきたかについて書きます。生業にしているIT系のこともそうですが、それ以外も同じ方法を使っています。

はじめに書いておくと、これまでの自分自身の体験や優秀な人の観察などから、学習の原則コツコツと反復練習を続けることであり、近道は無いと思っています。原則を守るための典型的な方法の一つが「網羅的に書かれた決定版と呼ばれる本を何度も精読する」です。これができる人はこうしたほうがいいと思いますし、ここから先を読む必要はないです。しかしながら、わたしはこの方法がうまくいったためしがないので、自分なりに工夫して、金銭的コストがやや高いながらそこそこうまくいく方法にたどり着きました。本記事ではこの方法を紹介します。

わたしは何かを理解しようとするときには、まずは初心者向きのページ数が少なくて読みやすそうな本をたくさん買います。そのジャンル名、および「参考書」などというワードで検索するとまとめサイトの一つや2つはひっかかります。そこにあがっているもののからフィーリングで5~10冊くらい買って、読みふけります。ページ数が少なくて読みやすいがゆえにサクッと読み終えられて達成感が得られます。そのまま勢いに乗って全部読み終えるまで続けます。

これらの本を読んでいるときは一字づつ噛みしめるように読むのではなく、ほぼ流し読みです。200ページくらいの本なら30分から1時間位で読み終えます。読んでいるうちになるほどと思ったようなキーワードがあれば覚えておきます。「この本なんかおかしなこと言ってるな?」となれば最後まで読まずにその本は即座に切り捨てます。

何冊か読んでくると重複する内容が増えてきます。これによって、本を書くほど詳しい人の多くが言及するほどの「その分野のとても大事なところ」が浮かび上がってくる、かつ、そのようなところを自然と復習できるという利点があります。

乱読が終わった後は気になる本を再読するなり定番本に移行するなりします。ここまで来たら同じ分野の本を読む勘がつかめているので決定版的な本を読む苦労は最初から読む場合よりは全然少なく済みます。また、ここまで来て全く興味がわかない場合はどうしても学ばなければならない場合を除き、今の自分には必要ない知識だと割り切って学習をやめます。

この方法はたくさん本を買うので金銭的コストは高くつくのですが、すくなくともここ十年ほどはうまく機能しています。なかなか学習がうまく行かないという人は一度試してみてはいかがでしょうか。

おわり