歩いたら休め

If the implementation is easy to explain, it may be a good idea.

【報告】微妙なコード

この間チームリーダー的な立場だった先輩が辞め、他から依頼されていたアナリストのコードレビューを私が引き継ぐことになった。

だが、そもそもその分析プロジェクト自体が(普段分析をやっているわけではない)私の目から見ても微妙で、コードやスキルの問題ではないので困っている。具体的には以下のような状況だった。

  • 以前先輩からレビューで指摘された点は、真面目に修正されている
  • ただ、そもそも分析の目的が微妙で、具体的なアクションに結びつかない
  • コード自体も分析も場当たり的な対処が多く、例えば「特定のライブラリがインストールできなかったから」「前任者の時代から使われているから」という理由で特に明確な意図なく複数言語・ツールが使われていて、確実に無駄な運用コストが発生しているし引き継ぎでも困るはず

そもそも、プログラミング言語やツールは「こういう目的のために最適な設計を目指している」のであって、表面上の書き方だけを知っていても本質ではないと思う。もうちょっとデータサイエンスっぽく言うと、プログラミングの仕事は「できるだけ運用コストを上げずに目的の問題を解く」ような最適化問題になると思う。一応「xxという理由でこの部分のコードは直したほうがいいと思う」というリストは伝えたが、これ自体も場当たり的な対処で本質的な解決にはなってない。

なんとなくコードから「そもそも何のためにやっているのか分からず、周囲から言われたことを真面目に直している」ような状況に見えてしまい、悲しくなってしまった。

「そうは言っても、じゃあ分析業務はどう進めればいいんだ」って思う方には、以下の記事を参考にしてほしいと思う。

qiita.com

こんなとき、自分のスキルに自信のある奴だったら安直に「そんな奴ほっとこうぜ」とか、もっと過激なことを言いそうな気がするが、 私自身も以前そういう「目的ベースで考える」ことが苦手で、かなり周りの人から教えて/サポートしてもらった覚えがある。 まあ結局、私の責務/できることは、真面目にレビューすることだけだと思うけど。

追伸: 全然関係ないけど、映画『若おかみは小学生!』が超面白かったのでお子さんと一緒に見に行ってください。

www.waka-okami.jp

【メモ】『ノートによる情報管理』を身につけるために読んだ本

エンジニアの知的生産術 ──効率的に学び、整理し、アウトプットする (WEB+DB PRESS plusシリーズ)』を読んだり、知り合いにいろいろ聞いてから、自分の情報・タスク管理法、勉強法を見直そうかなと思っています。

ただ、こういうのは人それぞれです。例えば私の周りのある人は「ノートにまとめる必要はない」と言っており、彼は優秀なエンジニアなのですが、その点参考にならないなと思っていました。そのため、周辺ジャンルの本をいろいろ読んでいて、今日のブログはその中間報告的な文章です。

1440分の使い方

1440分の使い方 ──成功者たちの時間管理15の秘訣

1440分の使い方 ──成功者たちの時間管理15の秘訣

タスク管理術として「様々なデジタル管理ツールを試したが、筆者にとっては手書きのほうが良かったからモレスキンのノート使ってる」というようなことが書かれていました。他もなかなかいい内容ですが、今の興味として学べたのはこれだけかな。

情報は1冊のノートにまとめなさい

情報は1冊のノートにまとめなさい[完全版]

情報は1冊のノートにまとめなさい[完全版]

一回手書きノート派になろうかと思って読みました。個人的に、既に社内の仕事ではやるべきタスクや、思いついたものをメモするページを作って管理しているので、あまり違和感無い内容でした。

友達はSONYDPT-CP1というデジタルペーパーを薦めていたのですが、正直7万円するので、すぐに手を出すのはアレかなと思って手をだしていません。

www.sony.jp

また、正直後から見返すことはそれほど考えておらず、一旦実ノートでいいかなと思っています。また、「ブログやSNSに全部書いちゃう」「Tumblrを非公開にして使う」みたいなことも考えたのですが、正直広く外向けに書けないこともあるのと、「頭の中を整理する」という目的のためにはアナログでいいかなと思いました。

「ノートが大きいと持ち運びづらいし、小さいと書きづらい」ということが書かれていたので、持ちやすさ優先でA5サイズの大学ノートを試してます。

また、知り合いに聞いたら、「GoogleSlideにまとめながら作業している。図も書きやすいので便利」と言っていました。これもPCの作業が多い場合は便利ですね。

ハーバード式 大人のADHDパーフェクトガイド

ハーバード式 大人のADHDパーフェクトガイド

ハーバード式 大人のADHDパーフェクトガイド

  • 作者: クレイグサーマン,カレンウェイントラーブ,ティムビルキー,福西勇夫,福西朱美,Craig Surman,Karen Weintraub,Tim Bilkey,村木美紀子
  • 出版社/メーカー: 法研
  • 発売日: 2015/02/23
  • メディア: 単行本
  • この商品を含むブログ (1件) を見る

自分や家族がADHD(注意欠陥・多動性障害)で悩んでいる方向けの本。「タスク管理が苦手な特性の人」向けに書かれているので、「どうやって管理すればいいか」「習慣づければいいか」が丁寧に書かれている印象があります。

例えば「こういうことは一般の仕事術の本にも書かれているが、ADHDで無い人に比べてなおさら、ツールに順応する必要がある」みたいにこの本自体にも書かれていました。

また、「ポップコーン現象」の話で、「いろいろと考えが浮かんで本来の仕事に集中できない」というのは自分にも当てはまる気がします。今の所のノートの目的が「目の前の仕事を明確化させたい」だと思っていたのですが、その他に、自分にとっては「浮かんできた考えを一旦吐き出し、後で検討できる状態にして、元の仕事に集中できる状態を作る」って機能も必要なのを自覚できました。

難解な本を読む技術

難解な本を読む技術 (光文社新書)

難解な本を読む技術 (光文社新書)

これも『エンジニアの知的生産術 ──効率的に学び、整理し、アウトプットする (WEB+DB PRESS plusシリーズ)』で紹介されていましたね。私はかなり速読に寄っているため、難しい本(数学や哲学)の本はちょっと苦手意識ありました。

この本でも「読書ノートを書きながら読む」という方法が紹介されていました。また、「登山型」「ハイキング型」の分類はかなり本質を突いていると思います。

【メモ】知り合いから薦められた仕事本のアタックリスト

【まとめ】プログラマーが愚直に仕事を進めるための方法 - 歩いたら休め

「最近仕事でもプライベートでも忙しい時期が続いて、『やらなきゃいけないこと』が管理できなくなってきたからGTDの本読んでるんだ」って話したら、知り合いからいろいろと薦められました。とりあえずチェックしてみます。

もし「イシューからはじめよ」読んでなかったら絶対読んだ方がいいと思う。こっちは「仕事を一番はやく終わらせるには仕事をしない(減らす)こと」という観点から、仕事への考え方を変えるきっかけになる。プロダクティビティ以外でも活用できて読んでからダイレクトに成果が変わったと思う。

イシューからはじめよ―知的生産の「シンプルな本質」

イシューからはじめよ―知的生産の「シンプルな本質」

「1440分」にはGTDよりももう少し過激なことが書いてあって「タスクリストは無意味」「スケジューリングしないとダメ」って書いてある。ある調査によるとタスクリストに追加されたタスクの7~8割は消化されないらしい。なので、1週間の予定は週の初めに考えるのと、今日〜明後日くらいまでの予定は頭の中で組み立ててる(と言ってもざっくり「これとこれをやる」くらいだけど)

これはKindle Unlimitedにもあるのでありがたいですね。

1440分の使い方 ──成功者たちの時間管理15の秘訣

1440分の使い方 ──成功者たちの時間管理15の秘訣

GTDとポモドーロの運用はRebuild higeponさん回がおすすめ。

rebuild.fm

【まとめ】プログラマーが愚直に仕事を進めるための方法

最近、精神的に大変な仕事とか、プライベートでやっているイベントとか、いろいろ重なってしまって大変でした。

私は全く器用なタイプではなく、複数いろいろやっていると、例えば「他の仕事のことが気になってこっちの仕事もなかなか進まない」というような負のスパイラルに陥りがちでした。ただ、大変だった中で他の方からのアドバイスで学んだことや、「これじゃいけない」と思って諸々の本を学んで、多少マシな状態にはなりました‥いや、多分なったと思います(笑)。そこで、最近似たようなことで悩んでいる人もよく見かけるので、軽くまとめておきます。

私を実際に知ってる人が見ると、「いやいや、お前言うほどできてないじゃんw」って思われるかもしれませんが、後でこっそり教えてください。

すべてを実験だと捉える

プログラミングの仕事を進めていると、どうしても仕様が明確でない、後から修正しなくてはいけないことがあります。 100%想定通り進むことは絶対にありません。また、チームの他メンバーと常に認識を合わせることも、ほぼ不可能だと言っていいでしょう。

それなら、我々には「想定外のことが起きませんように」と祈ってるしかないのかというと、そうではないはずです。

確かめたいことに対して、「サーバーが突然落ちないかどうかは負荷テストの段階で(可能な限り)チェックしよう」とか、「(非プログラマーとややこしい仕事するとき)用語についての認識の齟齬が起きやすいので、定例ミーティングで確認するようにしよう」とか、できるだけ早い段階で実験して拾えるように工夫しましょう。

ありがちなのが、他の人に渡すドキュメントをまとめる際に、「すごく詳細にまとめてるけど、これって欲しい情報じゃないんだよね」って言われ、複雑な割に「使えない」ドキュメントになってしまうことです。こういうのは、「目次」を作った段階で相手にそれとなく「今こういう方針でまとめてます」って相手にチャットして、大まかな方針レベルで問題が無いのか「実験」しておくようにしましょう。プログラムの場合は実装方針とかクラス図とかのレベルですかね。

ちょっと余談ですが、知り合いのデータサイエンティストが「開発先とのやり取りで多目的最適化のソルバーを使っている」「最初に出てくる仕様だと最適化問題の目的関数がちゃんと決まらないことがある。その時に多目的最適化で考えられる解を実際にいくつか出して議論すれば、何を優先するのか決められる」と言っていました。私は今まで単に「多目的最適化は解が一つに決まらないので自動化するプログラムで使いづらそうだな」と思っていたので、専門知識を活かしてうまく『実験』していたことに驚きました。

タスクを実験だと捉えると、いきなりうまくいく方法が見つからなくても、

  1. 「こうすればうまくいくんじゃないか」という仮説を見つける
  2. 「仮説が正しい」を証明するための実験(テスト)計画を作る
  3. テストを実行する

ことで愚直に進められるので、少なくとも全く身動きができなくなることは無いと思います。仮説が正しい場合、安心して実装していい範囲が広がり、間違っている場合でも仮説を修正してリトライすればいいだけです。

タスクを全部書き出す

私のように「他の仕事が気になって進まない」という状況になりがちな人は、ツールに頼って、「ここを立ち返ればとりあえず見落としがない」ような状況を作って、頭の中から一旦全部追い出してしまうことです。おそらく理想は、一人ひとりに『秘書』がいることだと思いますが、少なくとも現在ではそれなりに偉い人でないと難しいでしょう。

最近私が「いいな」と思っている方法は、以下のやり方です。

  1. 自分が「気になってること」をとりあえず全部箇条書きにする(例えば「毎朝」くらいの頻度で)
  2. そいつの中から「今日やるべきこと」をピックアップする

これだけで、「とりあえず今やるべきこと」に集中しやすくなると思います。また、書き出す前には仕事の把握だけで無限の時間がかかるように思われる場合でも、実際にはひとつずつ潰していけばなんとかなることが分かることが多いと思います。

ところで、最近発売した『エンジニアの知的生産術』で紹介されていたGTDという方法が、これをもっと詳しくしたようなやり方だそうです。ただ、自分自身の性格や特性は人によって違うので、いろいろと実験して修正していく必要があるはずです。

全面改訂版 はじめてのGTD ストレスフリーの整理術

全面改訂版 はじめてのGTD ストレスフリーの整理術

エンジニアの知的生産術』を見ていて一番面白かったのは、「やる気の出し方」として「タスクを分割する」ことがまず書かれていたことです。 こういうのは(自分でも他人でも)本人の努力の問題にしがちですが、できるだけシステマティックにやってしまったほうがお互いに安心できると思います。

インターフェイスを取っ掛かりにする

プログラミングのアドバイスを受けているときに「先輩が言ってる方針ってうまく行きそうにない/そもそもよく理解できないけど、なんでこういうこと言ってるのかな?」って疑問に思い、さらに質問してもよく分からない返答が返ってくることも多いと思います。後から考えると、それは大きく2つ理由がありえると思います。

  1. 自分が「当然伝わってるだろう」という前提が伝えられていない
  2. 相手が対象について深いレベルで理解していない(更にそれを自覚できていない)

この辺の違和感を感じた時は、100%ではないにしても、実際に何か問題があることも多いので無視しないほうが良いです。なんとか対処しましょう。調べてみるとしょうもない思い違いや勘違いであることも多いですが(笑)。

①については自分の問題なので、「前提条件で伝わってない部分があるのか」を愚直に確かめていけば大丈夫だと思います。まあ大変ですががんばりましょう。

ただ、②の場合も、相手がかなり優秀な方でもけっこうありえるので困りますよね。自分自身を振り返っても「ちゃんと分かってないことが分かってない」ことは滅茶苦茶あったと思います。その場合は自力で勉強するとか、同じ質問を他のもっと詳しそうな人に質問するとか、なんとか工夫して勉強する必要があります。(だから、私は相手がわけわからない質問や、「それって当たり前じゃね?」と思うような質問をしてきた際にも、少なくともバカにしたり「デキないやつ」みたいなレッテルを貼らないようにしようと思っています)

特に、技術関連だと「オブジェクト指向」とか「設計のベストプラクティス」とか「静的型/動的型」の話題とか、その他だと「人事制度」とか「技術教育」とかの話は、相手が自分の経験したことのある範疇の話しか話ができないことが多く、割と地雷が多い(他人に頼って知識をつけるのが難しい)と思います。もしそういうところまで、自分の知識の限界を知りつつ論理的に話できる人がいたら大切にしましょう。

自分で勉強する場合は、以下の2点のどちらかに注目して調べていくと良いと思います。他人に教えて貰う(質問する)場合でも、ここをとっかかりにして議論を始めることができるでしょう。

  1. その技術を使うときのインプット/アウトプット
  2. その技術が作られた目的や経緯

ここに調べていくと、「〇〇は××という目的のために作られたでライブラリある」ということがわかり、××について調べると「他にも△△というライブラリがある」「実は自分の目的のためにはそっちのほうがいい」みたいに調べられて、最初の取っ掛かりはつかめると思います。

インプット/アウトプットが同じで、自分の目的に合っていれば、「他のツールやライブラリ差し替える」「どちらが良いか検討する」というような発想ができるようになると思います。こういうのってちょっとポリモルフィズムっぽい気もしますね。技術以外でも、同じような発想で「普段かかわらない相手と仕事するのでその分野を勉強しなきゃいけない」ような状況で、最初の取っ掛かりを掴めるかもしれません。

知識が足りずに身動きのとれない状況が減る(少なくとも勉強しなきゃいけない箇所や、質問すべきことは分かる)と思います。

多少は強引に進める

最近、「必要以上に全員の合意を取ろうとしてブロックしていることが多いのでなんとかしてほしい」と先輩から言われて反省しています。問題が無い場合でも全員にOKもらわないと先に進めないので、単純に効率が悪いと言われ、その通りだなと思ってしまいました。

単に「(チームメイトが)問題が無いので静観している」ような場合もあるので、「とりあえず今出してる案で問題あれば出してください。無ければ○月×日までで一旦出しちゃいます」。もしそのときに無茶なことを言ってしまっても、周りから「いや、それじゃあ期限がカツカツすぎるから後3日くらい欲しいよ」みたいにツッコんで貰えるはずです。

もしかすると、自分がすごく偉い立場で、周りを萎縮させている場合には「え?リーダーが○月×日までって言ってるなら間に合わせなきゃ」って無理させてしまうかもしれませんが、今の所私はそうではないので考えていません(笑)。

他に、私の場合は「(割と慎重すぎるタイプなので)もうちょっとスピード重視で進めちゃっていいよ」と言われ「じゃあちょっとクオリティ下げて進めるか」と思って、ちょっとプログラムが雑すぎると怒られることもありました。その時分かっていれば良かったのですが、実際にはスピード重視 OR クオリティ重視の二者択一であることはあまり無く、上のように「チェックしてもらう期間を決める」みたいにどちらも担保できる方法は割と考えられます。

ただ、試行錯誤している間(つまり人生のほとんど)は、多少痛い目を見るのはしょうがありません。こういうときにちゃんと仮説を持って「これは実験だ」という意識があると、後に活かせるので多少前向きになれると思います。

自分自身の特性を知る

自分自身の特性を知って、苦手分野をシステム的に、もしくは周りのチームメンバーとのやり取りでカバーする方法は身につけておくべきです。

例えば、大勢と交流するとエネルギーを貰うタイプとか、逆にストレスを感じるタイプとかいます。例えば、私は社内行事で集団行動すると正直かなり疲れる(一応言うと苦手な人がいるわけではありませんw)のですが、違うタイプの人が多い環境にいると、自分の性質が分からずに無理してしまうことが多いように思います。そういう性質と対処法を知るために、次の本が役に立ちました。

片づけられない人のための仕事の本

片づけられない人のための仕事の本

プログラマーという世界だけに限ると、(きれいに分かれるわけではないし、他人へのレッテル貼りにもなりかねないので危険ですが)ADD/ADHD的な性質を持つ人が多いように思います。

この本では、3つのタイプに分けて、ADD/ADHDについて3つのタイプに分けて、それぞれの性質や対処法について説明しています。私は割と②のタイプが参考になりました。

  1. 多動が目立つタイプ
  2. 内部で混乱してるタイプ
  3. 枠組みに頼って生きてるタイプ

もちろんADD/ADHD的な性質の人だけじゃないし、この本のタイプ分けもざっくりしているので、これだけで自分や他人を分かった気になるのは危険だと思います。

ただ、世間一般を見ると「この人、特定の枠組みに頼りすぎてるな」とか、自分自身の性格や性質に合わないやり方を無理にやろうとしている人が多いようには思います。私の場合は「物覚えが良い方じゃないのに、(すごい知り合いのエンジニアのやり方を無理に参考にして)タスクの管理方法を考えずに仕事に着手してしまう」ようなことがありました。人それぞれ、自分自身に合ったやり方を身に着けていく必要があります。

まとめ

一番危険なのは「現状を把握できてなく、どこから着手すればいいか分からない」ような状態だと思います。上の考え方なら、とりあえず試行錯誤して先に進め、少しずつ改善できるようにはなるはずです。少しずつ改善できるなら、まあ数年後にはそれなりのものにはなっているはずです(なっているといいなあ!)。

それでは、お互い無理せずがんばりましょう。

【Python】ジェネレーターをn個ずつに分割する実装

「巨大なテキストファイルをジェネレーターとして読み込み、100万行ごとに分割し、別々のファイルに保存する」という処理を書いてました。

数百行ごとに分けるのならリストにして分割するのですが、今回は分ける単位が1000万行ごとなので一度にメモリに載せたくありません。遅延評価を保ったまま、以下のようにファイルを分けるコードを書こうと考えていました。

要するにnumpy.array_splitの入力値も出力もgenerator版です。

numpy.array_split — NumPy v1.14 Manual

from pathlib import Path

path = Path("/tmp/example/")

# tableは巨大なテキストファイルを一行ずつ読み込んだgenerator

for i, rows in enumerate(split_generator(table, 1000000)):
    filepath = path / f"output{i}.txt"
    with filepath.open("w") as f:
        for row in rows:
            f.write(row)

しばらく悩んでいたのですが、一応、以下のようにitertoolsを駆使して実装することができました。

from itertools import islice, chain

def split_generator(iterator, n):
    while True:
        each = islice(iterator, n)
        first = next(each, None)
        if first is None:
            break
        yield chain([first], each)

ただ、ジェネレーターが先頭から評価されなかった場合にどうなるのかとか、そもそも本当に1行ずつメモリに載ってんのとか、ちゃんと見ていかないと安心して使えなさそうなコードになってしまいました。もっと安心して使えそうな実装を思いついた(知ってる)方はコメントください。

「この問題についての正しい回答はおそらくPythonではなく適切なデータ処理基盤を使うことだ」と思っているのですが、今回はデータ元が特殊(記事ではテキストファイルとしてしまいましたが)だったのでそれも難しいです。

エンジニアリングって難しいですね。

【メモ】「買ってよかったもの」と「Strikingly」を使い始めてみました。

知り合いが薦めていた「買ってよかったもの」ってサービスを使い始めました。

katteyokatta.morishin.me

morishin.hatenablog.com

「毎回ブログを書くのもダルい」「でもツイートするだけは流れちゃうのでアレ」と感じてたのでちょうどいいサービスだと感じました。

あと自分のブログ横に表示するパーツがあれば個人的には嬉しいです。もしやったら一気にアフィリエイトサイトっぽくなっちゃいますがw

また、ポートフォリオサイト的なのも欲しかったのでStrikinglyってサービスを無料プランで使ってみています。

www.strikingly.com

自前でHTML書くのはメンテが面倒で放置しそうだし、かといってJekyllやPelicanで生成するのはオーバースペックだし、って悩んでいたのでこれもちょうどいいです。こちらはイラストレーターの方が使ってました。今後、作ったものはこっちにまとめていこうと思います。

http://takeshi0406.strikingly.com/takeshi0406.strikingly.com

【本】新年になってからいろいろ読んだ本

読んだ本をまとめつつ、アフィリエイトで小銭を稼ぐための記事です。もちろん書籍代のほうがかかるので赤字ですがw

集中力はいらない

西尾泰和さんが話されていた本。

scrapbox.io

私自身は「(著者の性格だと)1つの作業は途中で飽きるので、複数の仕事をConcurrentにこなしたほうが楽」「一つのことに集中しすぎると偶然必要な要素が手に入る、セレンディピティが無いので、いくつか関心のある物事を持ち続けてるほうがいいアイデアが見つかるよ」って意味合いだと理解しました。落合陽一さんが「百姓になろう」って言ってたのと似た感じ。

自分自身の生存戦略を考える際には、時間スケールが数時間~1日なら「集中」を、数日~数年なら分散(自分のテーマを元にいろいろ手を出す)を中心に考えたほうがいいかも。(急に生存どうこうってどういうことって思われた方、WEBエンジニアは生存戦略って言葉が好きなんです!)

Effective Java

全体的にいい本で、Javaプログラマーでなくても参考になります。

個人的にはHaskellの例外について調べていた時に見つけた例外安全性のスライドでExceptional C++とともに勧められていて、そちらはまだ私には難しかったので読みました。「例外を起こしたときにオブジェクトや変な状態にしたり、変な参照を残すな」、そのために「実際に使う前に、先にオブジェクトの状態をチェックして例外を投げる」とか「例外が起きた場合にロールバックする」ということまでは理解しました。

並列・並行処理の章はちゃんと読めてませんが、必要ないときに読んでもピンとこないので、きちんと取り組む必要が出てきたら読もうと思います。

EFFECTIVE JAVA 第2版 (The Java Series)

EFFECTIVE JAVA 第2版 (The Java Series)

ナリワイをつくる

Kindle Unlimitedでタダで読めましたw

エンジニアリング組織論への招待

最近やけに話題になってますね。エンジニアリングの仕事を「不確実性を下げる行為」と言っているのはスタンド能力っぽくてかっこいい分かりやすいし、ある本質をついていると思います。

あとハンロンの剃刀として「相手が嫌なことをしてきても、無能で説明が付く場合は悪意を見出してはならない」って身も蓋もないこと書いてたのも印象に残ってます。西海岸のハッカー文化など、エンジニアの文化的な話も多いので、そういうの興味ある人にもいいかもしれません。

恋する文化人類学

この記事が素晴らしかったので、著者の本も読んでみました。

文化人類学の入門書としても個人的な異文化交流の事例としても読めるようにした」ものらしいです。

現地の引き出物や結婚式の変わった風習に面食らいつつも、いちいち冷静に立ち止まって「これは親族の基本構造で言われた~」とか「贈与論の~」とか冷静な目で分析を始めるのでかっこいいです。ただ、資料収集時の癖が出てしまい、奥さんに「あなたの撮った結婚式の写真は誰が来てたのかわかりづらいよ」って言われてしまったというエピソードは職業病っぽくて笑ってしまいましたw

恋する文化人類学者

恋する文化人類学者

西太平洋の遠洋航海者

『恋する文化人類学者』で勧められてた本の一冊です。こういう本もKindleで売ってるのでいい時代ですね。

西太平洋の遠洋航海者 (講談社学術文庫)

西太平洋の遠洋航海者 (講談社学術文庫)

ガベージコレクションアルゴリズムと実装

社内チャットでJavaのstop the worldの話が出ていて、「Pythonだとどうなんだろう」と興味持っていたときにちょうどブックオフで見かけたので買いました。でもちゃんと理解してません😢

私が普段使っているのPythonでは、参照カウントがメインで、循環参照の処理に他のGCを使い分けている。そのため「(stop the worldのように)GC実行中にアプリケーションが完全に止まる」ってことは考えにくいが、循環参照のGC実行中はその可能性があるかもね。もしあったらgcモジュール試してねってある意味当たり前のことが書いてました。

また、そもそもGCアルゴリズムはおおまかに分けて3種類あるらしい。他のアルゴリズムもだいたい得意分野の組み合わせで考えられるそうです。

  • 参照カウント
  • マーク・アンド・スイープ
  • コピーGC

世代別GCみたいに言われているものは、これらのアルゴリズムにプラスαで工夫する感じみたいです。だいたいこの3種類の特性と、世代別GCみたいなよくある工夫まで知っていれば最初のひとまず自分の疑問には答えられそうです。

ガベージコレクションのアルゴリズムと実装

ガベージコレクションのアルゴリズムと実装

超AI時代の生存戦略

なかなかいい本で、「進化した機械学習やグローバルな競争には勝てないから、自分ならどうやってコモディティ化したものに対して+αできるかを考えればいい」「競争自体を避けよ」みたいな主張です。

あと「ローカルなコミュニティで1位になるところを作り、それをグローバルな文脈に持っていく→またローカルで…」みたいなサイクルで勉強できるといいよね、みたいな話もありました。

超AI時代の生存戦略 ―― シンギュラリティ<2040年代>に備える34のリスト

超AI時代の生存戦略 ―― シンギュラリティ<2040年代>に備える34のリスト

お金2.0

けっこう話題になってたので読みました。「誰もが自分の都合のいい経済圏や思想を選び、分断された社会が来る」って話はポスト真実社会的な話は面白いです。

細かい話ですが、「ベーシックインカム(BI)があればお金がボトルネックにならなくなる」という主張があり、そもそも「なぜBIが導入されるのか」「そもそもBIを導入するインセンティブあるのってそもそも誰なの?」って根拠が書かれてなかったのがちょっと残念でした。そこだけでもけっこう面白い話できそうですし。

お金2.0 新しい経済のルールと生き方 (NewsPicks Book)

お金2.0 新しい経済のルールと生き方 (NewsPicks Book)

増補改訂版Java言語で学ぶデザインパターン入門

「そういえば今までちゃんとデザインパターン勉強したことないな」と思って読みました。

いい本だとは思いますが、やっぱりこういうものって必要あって産まれてきた概念だと思うので、何もない時期に勉強するのはモチベーション上がりませんでした。でも後々リファレンス的に使うかもしれません。

Haskell等だと数学の概念を援用するけど、Javaだと工場とか人の喩えを使うのが文化の違いっぽくて面白いです。

増補改訂版Java言語で学ぶデザインパターン入門

増補改訂版Java言語で学ぶデザインパターン入門

僕たちのインターネット史

ゆるい本です。「西海岸っぽい考え方に影響された人は技術に夢見がちで大仰な警告出したがるけど、山形浩生さん(伽藍とバザールとか、ローレンス・レッシグのCODEとかを翻訳した人)はいい感じに東海岸(現実的)っぽくてバランス取れてていいよね」って書いてたのを覚えてます。あと、日本のインターネットって、2ちゃんねるニコニコ動画で「思想は無くても盛り上がればいいや」カウンターカルチャーっぽさが薄まってるよねって話とか。

「WEB時代になって(サイトが公開されている一方、裏側のコードはクローズドだから)オープンソースの考え方って薄まったよね」って書いてたけど、ここにはちょっと疑問があった。有名な企業はだいたいオープンソースにもコミットしているので、変容はしてるけど薄まってはいないと思う。って話を先輩としたら、「OSS自体でマネタイズしようとした企業はほとんどいなくなったよね(Mozillaみたいなもの?)」って話をされました。

あと伺か(with 任意)の話とかありました。えんいー。

僕たちのインターネット史

僕たちのインターネット史

プロカウンセラーの共感の技術

これもKindle Unlimitedでタダで読めました。いい時代です。

以前読んだ『医療とコミュニケーション』という本では合理的な議論では良いのですが、「共感」という視点は欠けていたと思います。その場合、こちらの本が参考になるかもしれません。

kiito.hatenablog.com

プロカウンセラーの共感の技術

プロカウンセラーの共感の技術

時間の言語学

時間は抽象なので、私たちが時間を認識するとき、なにかに「見立て」るしかない。この「見立て」つまりメタファーを分析することで、“時間”を具体的に意識化することができる。近代において最も強固な「見立て」は〈時は金なり〉のメタファー。コーパスや、具体的なテキスト(「吾輩は猫である」「モモ」等)を探り、私たちが縛られているさまざまな時間のメタファーを明らかにした上で、新しい時間概念(「時間は命」)を模索したい。

近代になってから「Time is money」のメタファーで「時間は浪費するもの」「管理するもの」ってイメージが出来たって話が面白かったです。

人はなぜ物語を求めるのか

この本を読んでたら「筆者は人生に期待するのを止めたら生きるのがラクになった」って書いててブッダかと思いました。「一切皆苦」って言葉の「苦」は、苦しみだけじゃなくて思い通りにいかないこと全般を表しているそうです。

人は真実を手に取ることができない。ましてやその手触りを他者と共有することは不可能である。そこで、思考の枠組みとして導入されるのが「物語」だ。そう、本書の指す「物語」はしばしば「演劇」や「小説」ではなく、事実の羅列に因果関係を見いだそうとする人間の思考癖についてである。

こういうのって、例えばデータ分析のとき、分析者が意識してないとまずいことかもしれませんね。

Hit Refresh(ヒット リフレッシュ) マイクロソフト再興とテクノロジーの未来

最近、マイクロソフトのプロダクトがイケてる(例えばVS Code等)のは、この人のおかげなのかもしれません。

Hit Refresh(ヒット リフレッシュ) マイクロソフト再興とテクノロジーの未来

Hit Refresh(ヒット リフレッシュ) マイクロソフト再興とテクノロジーの未来

SM調教師瞳 と同人ハードの夜明け

同人誌です。スーパーファミコンをハックして任天堂非公認のゲームを作る(作った人へのインタビュー)内容です。芸能活動する前の桃井はるこのバイト先の話もあって、技術以外でもかなり濃い内容でした。

ソーシャルメディアと公共性

kiito.hatenablog.com

こっちに書きました。