yikegaya’s blog

仕事関連(Webエンジニア)と資産運用について書いてます

言語処理100本ノック半分やった

思い立って言語処理100本ノックに挑戦してとりあえず半分(第5章)まで動くようになったので感想

そもそも言語処理100本ノックってなに

言語処理100本ノック 2015

ネットで無料で公開されている有名な自然言語処理プログラミングの問題集。サイト開いても一見説明がなくていきなり問題が始まる感じだが、下の方までスクロールして読むと東北大学の乾・鈴木研究室が公開しているらしい。。

なんでやろうと思ったか

  • 自然言語処理とか機械学習の分野がよく話題になる割に全然知識がないので、身につけたかった
  • 細かく問題が区切られているので続けやすそうだった
  • 趣味(当面実務で言語処理の深い知識を求められることはない。業務とは違う言語、違う分野でプログラム書いて気晴らししたかった)
  • (とはいえ、文字列処置とかは普通にweb開発でもよく使うので仕事でもやくに立ちそう。。)

自分のスキル

  • 普段使ってるのはRubyとJS、あとは前の職場でawkとかsedでの文字列処理は結構やってた
  • Pythonは使ったことないがこれに向けて軽く言語機能一通り勉強した。Rubyに似てる。。
  • LPICのレベル1は持ってるのでUnixコマンドとか正規表現での文字列処理は一通りの前提知識はあるはず
  • 形態素解析とか機械学習はちょっと本読んだり調べたりしたことはあるが踏み込んだことはほぼわからず。

で、実際やってみて

  • 一応Python以外の言語でも対応できる。。とはなってるみたいだけど、実際問題の中でPythonのライブラリが推奨されているのでまあPython前提
  • ブログとかで他の方の回答が出てるので解いた後に書き方比較したり全くわからないときは参考にさせていただきました。。

1章

準備運動として軽めの問題。RubyとかJSだとmapでループしてるが、Pythonだと for文でループするのでなかなかさくさく書けない。そのうち手が覚えるはず。。

2章

Pythonでテキスト解析してそれをUnixコマンドで確認する

Pythonの知識不足で詰まるのはともかく、意外とUnixコマンドも詰まるなと。。

uniq -cとかsort --keyとかunixコマンドのオプションが充実していることを再認識。。

3章

正規表現での文字列切り出し。wikipediaの記事からマークアップ取り除いたりURL切り出したり結構大変。

4章

mecabを使った形態素解析の問題。

とりあえずmecabをインストールしてお題の文章をmecabで解析して結果をテキストファイルに書き出す。 で、そこから問題で支持された条件の文章を切り出していく。あとその結果をグラフで描画したりする。

解析結果のフォーマットの見方とかそもそも形態素解析とは何か知らなかったりしてwikiとかで調べる。

5章

cabochaを使った係り受け解析の問題

cabochaというライブラリを使って文節間の修飾関係を解析して(係り受け解析)結果をテキストファイルに書き出して、あとは問題で支持された通りの条件で修飾、被修飾関係にある文節を出力していく。

cabochaの解析結果の見方とか係り受け解析が何か。。と言う理解ももちろん大事だけど結果を処理するのにPython力もないと辛い感じ

この後

4、5章も難しかったけど後半も機械学習とか出てきて難易度高そうな雰囲気。

これ以外にも勉強したい分野が諸々出てきているし一旦ペース落としつつ続ける。焦らず地道に時間かけてやっていきたい。。

最近読んだ本(だいたい年末年始)

技術書

進数計算とかlog(対数)計算とか再帰とか、なんとなくエンジニアが必須で学ばねばいけない。。と言われているものの実務では理解曖昧でもなんとかなりそうな分野がどうプログラミングに関係するのか納得感が得られる。数学とかコンピュータサイエンスのへ学習モチベは上がる。

あと2番だと機械学習についての解説があってこれがわかりやすかった。

スクラムの理解が曖昧なので読んだ。漫画部分多めで気軽に読める

会社に置いてあったのでざっと読んだ。BigQueryの内部実装とか周辺ツールとの連携とかめっちゃ詳しく書いてあるけどとりあえず実務で使うんであれば詳しすぎると言うか。求めているものに対して情報が多すぎる感じはあるけど、読み物としては面白い。

この手の本とか記事でKJ法とかブレインストーミングとかよく勧められてるけどやったことないかもしれない。。

  • ElasticSearch実践ガイド

別に実務で使う予定はないけど会社の本棚にあったのでなんとなく読んだ。思ってたより多機能でプログラム側で制御しなくてもElasticSearchのAPIで結構細かいことできそう。。

  • プロセッサを支える技術

情報処理試験でやったことを思い出しつつ教養として読んでみた

その他

  • 創作する遺伝子

デスストランディングと言ういろいろシュールなゲーム(基本荷物を配達するゲーム)にはまって「どういう発想でこれ作ったんだ。。」と気になったので読んだ。SF中心に結構知らない映画、小説、漫画、アニメが紹介されていて細かくメモしながら読んでしまった。

なんとなく読んだ。音楽に対してよくこういう描写浮かぶよな。。と感心した

勧められて読んだ。本当にこういう龍が如く的な世界あるんだなと。。

最近読んだ本

アウトプットが重要とよく言われるWEB業界のエンジニアだしマメにブログ書こうと思ってたけどマッハでだれてきた。とりあえずたまには読んだ本でも書いてみる。

技術書

  • 実践TypeScript - BFFとNext.js&Nuxt.jsの型定義

業務は相変わらずRailsメインだけど少しTypeScript+Next.js触る機会があったので勉強してみた。型定義の言語機能に重きを置いている感じ。他の本でJSとかReactの基本学んでから読んだ方が良さげ

misreading chat(Googleのエンジニアが論文を紹介してくれるpodcast)聴いてたらコンピュータサイエンスの基礎的なとこ勉強したくなって読み始めた。 応用情報は前々職時代に落ちて放り投げてたけど来年辺りにリベンジしたい。

  • 改訂2版 みんなのGo言語

手元で一つくらい簡単にGoのアプリ書いてみたい、、と思っていて(できてない)とりあえず何ができそうか学ぶために読んでみた。 CLIでなんか作ろうと思ったらGo良さそう。。

会社でUIUXを議論する機会があったので読んでみた。エンジニア目線で書かれている。

図書館で見つけてちょっとPython気になってたので読んだ。最新は第4版だけどまあ、、

誰しもいろんな言語を触ってみたくなる時期があるというけど、今そんな感じなのかもしれない。。

その他

  • ロケット・ササキ ジョブズが憧れた伝説のエンジニア

ずっと積ん読になっていたシャープの伝説のエンジニアの伝記的な本。こういうジョブズとか孫正義みたいに人に比べればそんなに知名度高くないけどめっちゃすごい人の話を読むの好き

  • 洞窟オジさん

佐々木俊尚さんが紹介してたので読んでみた。13歳で家出してその後43年、野生人みたいな生き方をした人の話。月並みだけどいろんな人生あるな。。

最近読んだ技術書

最近いろいろ技術書読んだので読んだもの書き起こしてみる。

Goの基礎文法勉強するために読んだ。「Tour of go」よりも詳しい。

図書館で見つけて流し読んだ。ちょっと内容古い

並行処理の勉強のために写経しながら読んだ。これは後でまた読み返したい。。

Goやってたらシステムプログラミングに興味が出てきたので読んでみた。

図書館で見つけてなんとなく借りた。Cとか基本情報受けるときくらいしかまともに勉強したことなかったけど、説明詳しくて普通に読めた。

「プログラムはなぜ動くのか」が面白かったのでこっちも図書館で借りた。

こうしてみると最近なぜか仕事コンピュータサイエンスちゃんとやりたい的な気分になってる。。仕事は最近UIとかフロント的なところいじることが多かったので深層心理的にはローレベルなこと学んで気分転換したかったのかな?

「発想する会社! ― 世界最高のデザイン・ファームIDEOに学ぶイノベーションの技法」を読んだので備忘録

会社で借りた「発想する会社! ― 世界最高のデザイン・ファームIDEOに学ぶイノベーションの技法」を読んだ。で、面白かったので備忘録。

アメリカの有名なデザイン・ファーム、IDEOのゼネラル・マネージャが書いた本。Appleのコンピュータをはじめ、パーム、プラダペプシなど様々な企業のプロダクトデザインに関わって来たIDEOがどうイノベーションを生み出して来たのか、社内の文化や方法論が書かれている。

備忘録

個人的に面白かったとこ、気になったところをメモ

IDEOの方法論

1.理解

市場、クライアント、テクノロジー、問題点について認識されている制約事項を理解すること

2.観察

現実の状況のなかで現実の人びとを観察し、なぜ人がそうするかを見つけだす。現在の製品とサービスで扱われていない隠れたニーズがどこにあるかを察知する。

3.視覚化

全く新しいコンセプトと、それを使う顧客の姿を目に見える形で描き出す。 - コンピュータによる作図 - 模型とプロトタイプ - 様々な人物がそれを使う場面や状況をストーリーボードで示す まだ実際に存在していない製品を使った生活を描いたビデオをつくる

4.評価とブラッシュアップ

短時間にいくつもプロトタイプをつくり、添えを繰り返し評価し、練りあげていく

5.実現

新しいコンセプトを市場に出すために、現実のものにする

観察する

私たちはモニターに製品について検討してもらう調査方法は好まない。従来のマーケットリサーチにもあまり関心はない。私たちはその源に行く。クライアント企業の「エキスパート」ではなく、その製品、あるいはこれからつくろうとしている製品に似たものを実際に使っている人々のところへ行く。

自分自身で見つけ出す

自分自身の目と耳で物事を見聞きすることは、画期的な製品の改良や創造の最初の重要な一段階である。これは一般に「ヒューマン・ファクター」と呼ばれる。

注意深く観察するようになれば、さまざまな洞察が得られ、あらゆる機会が開けてくる。

バグリストを作る

いつもの自分のやり方を外れたとき、もっと多くの発見への道が開ける。

現場に身を置く

芸術であれ、科学であれ、テクノロジーであれ、現場のそばにいることによってインスピレーションを得られることがよくある。これがインターネット時代にあってさえ、地理が意味を持つ理由だ。

左利きの人の身になる

私たちは「左利きの人の身になる」という原則を立てて、消費者のニーズへの共感を育んでいる。

観察の練習

単に自分をとりまく環境を見渡して検討してみるだけで、誰でもすぐれた観察術を学べる。 大抵の場合、人間のつくったシステムの多くの欠点に気づく。

ブレインストーミング

ブレインストーミングに関して困った問題は、誰もがそれをすでに実行していると思っていることだ。 ブレインストーミングはスキル、あるいは技術。たとえて言えば、靴紐を結ぶのではなくピアノを弾くようなものになりうるのに気づいていない。

よりよいブレインストーミングのための7つの秘訣

1.焦点を明確にする

2.遊び心のあるルール

  • 出されたアイデアを批判したり論争をしかけたりしてはいけない。批判した者を完全に無視するのではなく、その批判を脇にそらすことが重要。
  • IDEOでは、多くの会議室に高さ十五センチの文字でブレインストーミングのルールが書かれている「量をねらえ」、「思いきったアイデアをどんどんだそう」、「目に見えるように表現しよう」

3.アイデアを数える

ブレインストーミングによってわいてくるアイデアを数えることは二つの点で役に立つ。 1.参加者を刺激する道具になる「部屋をでるまでに100のアイデアを見つけだそう」 2.よどみなく進んだかどうかをはかる尺度になる

4.力を蓄積し、ジャンプする

優れた進行役について。「蓄積」の段階では会話を繋げる、議論が先細りする「ジャンプ」の段階では視点を変える。

5.場所は記憶を呼び覚ます

壁に大きなポストイットを貼り、テーブルには昔から肉屋が使っている包装紙を広げ、油性マーカーを使う。

  1. 精神の筋肉をストレッチする

グループのウォーミングアップをする必要があるケース - メンバーが一緒に仕事をしたことがない - 頻繁にブレインストーミングをしていない - ブレインストーミングのテーマとは関連のない差し迫った問題のせいで気が散っている

7.身体を使う

競合する製品、他の分野で見られるあざやかな解決法、問題に応用できる見込みのあるテクノロジーのすべてを持ち込む。

ブレインストーミングを台無しにする六つの落とし穴

1.上司が最初に発言する

2.全員にかならず順番が回ってくる

3.エキスパート以外立ち入り禁止

4.社外で行う - スキー場とかビーチでやると逆効果になる場合がある

5.ばがげたものを否定する

6.すべてを書き留める

障害のなかの機会

逆境はチームを一つにする接着剤の役割をはたし、そこからさらに強くて固い絆が生まれる。

チームは狭い場所に

狭い場所で一緒に働き、生活をともにすることによって、ホット・グループに力をみなぎらせることができる。

面積が広すぎるのは、予算が多すぎるのと同じく、エネルギーが拡散さえ、チームのメンバーのあいだの固い仲間意識が損なわれることがある。 

チームの士気

  • 特別な気分を味わうと人は破天荒な夢さえ上回ることを成し遂げる

  • 大切なのはどれほどの金をかけるかではなく、どんな経験ができるかである。

  • 人を特別な気分にさせるもう一つの素晴らしい方法はさぼらせることだ。(午後を休みにしてチーム全員で野球の観戦に出かけたり

  • 楽しみに費やす時間と費用について心配してはいけない、チームがどれほど時間を失おうと、翌週には取り戻すし、あっという間に黒字になる。

ホットグループのための八つの風変わりな個性

  1. 預言者

  2. トラブルシュータ

  3. 因習破壊者

  4. 人の心を読む人

  5. 職人

  6. テクノロジー・マニア

  7. 企業家

  8. ちがうタイプの服を着こなす人

プロトタイプ

プロトタイプ制作は、問題を解決する方法だ。そして、文化であり言語である。新しい製品やサービス、あるいは特別なプロモーションなど、ほぼすべての物事についてプロトタイプを作ることができる

アマゾンのやり方

ベゾズは数週間のうちにウォール・ストリートの安楽な仕事を辞め、引っ越しトラックを呼ぶと「荷造りをして、行き先を運転手に告げる前にトラックに積み込んだ」。信じられないことに、ベゾズは自分のインターネットビジネスの種をどこに蒔くかもまだわかってなかった。

幸運を作り出す

図面を引いたり何かをつくりはじめたりすれば、思いがけない発見、あるいは幸運と呼んでもいいが、何かを新たに発見する可能性が開けてくる。

モノをつくったり、試作品を使ってみたりする癖をつけよう。次の画期的な作品の着想となる洞察が得られるかもしれない。

まずいアイデアをつぶす

思いついたアイデアがまずくても、とりあえずそのプロトタイプをつくり、やはり駄目だからつぶしてしまう

温室をつくろう

ごちゃごちゃしてるけどなんかかっこいいオフィスの写真が載ってて良かった。。

オフィス

とっさにミーティングが開ける場所があるだろうか?開放的な部分とプライバシーを保てる部分が違和感なく溶け合っているだろうか?そして同じくらい大切なことだが、社員たちが自分のスペースに仕事と趣味を堂々と示すように奨励されているだろうか。

ブロック

私たちのオフィスには、大きさが牛乳パック用ケースほどの立方体のフォームがいたるところにある

種まきの七つのヒント

  1. 雑誌の購読とネットサーフィン
  2. 映画監督になる

映画監督の視点を身につけて観察の達人になろう

  1. 一般公開する

定期的に会社の一般公開日を設ける

  1. さまざまな主張に耳を傾ける

  2. アウトサイダーを雇う

  3. 違う人間になってみる

  4. 二職種以上の仕事ができるように訓練する

バリアを飛び越える

バリアは外部的なもの、新しい製品やテクノロジーに対する文化的な抵抗かもしれない、あるいはしっかりと根付いた習慣であるかもしれない、人びとの製品の理解の仕方や使用方法はしばしばイノベーションの障害となる

  • 人びとが新しいテクノロジーを受け入れるのに時間がかかるとき、仮定を見直す必要がある。ときには、選択できる最も賢い道が、限られた狭いアプリケーションの開拓といった控えめなステップである場合もある。

バリアと橋

バリア
階層ベース 利益ベース
官僚制 自治
個性がない 気兼ねがない
整頓 乱雑
専門家 何でも屋

楽しい経験をつくりだす

  • 何かを創造する仕事をしている人は、誰でもなんらかの経験をしている。だから、動詞、つまり行動に焦点をおこう。

  • 目標は店舗をより素敵にすることではない。買い物という経験をより素敵にすることだ。

  • 製品やサービスを要素に分解することから始める。これが、言わば経験のDNAとなる

  • ナイキタウン、ワーナーブラザーズ、スタジオ・ストア、ディズニー・ストアはテーマによって構成した「独自の経験を売っている」

  • ラスベガスに行ってみることをお勧めする。どんな分野の仕事や産業も多くのことを学べる

時速100キロのイノベーション

  • スピードは重要である。スピードがあればこそ、ライバルがスターティング・ゲートをでる前にあなたのブランドを消費者の心に植えつけられる。

枠をはみだして色を塗る

  • イノベーションに関して決定を下すのは、危険をおかすことだ。

  • 最良の企業は常に未知の世界に飛び込んだ全く新しい企業である。

  • 失うかもしれないもの 市場のシェア、収入、肩書き、ステータス、仕事について考えてしまうと、まず飛躍はできない。

  • サウスウェストは大手航空会社に成長しても、敏感で起業家精神にあふれたその企業文化を失っていない。小企業と同じように考えて行動することは重要だ。

  • 私たちが肩書きや大きなオフィスを拒否するのは、それが精神的にも物理的にもチームと個人の間に障壁を生み出すからだ。

  • 1日に20のアイデアを生み出さなければならないホールマーク社のトップ・プロデュース・ユーモア部門シューボックス

  • はみ出し過ぎは禁物

ウェットナップインターフェイスを探して

  • 機能のつめこみと戦う

すばらしい製品やサービスを生み出す方法

  1. 入りやすい入り口をつくる

  2. 発想をうながす具体例を探す

  3. 15センチ上からそれをデスクの上に落としても、壊れないと思えますね?

  4. ブリーフケースを考える

  5. アメリカの典型的な働く男性がブリーフケースやランチボックスを愛したのは、それが家に持ち帰れる数少ないものの一つだという単純な理由からだ。

  6. 仕事と家庭の枠を超える機器は愛着をかきたてる

  7. 色のインスピレーション

  8. デザインにおいて色が最も役に立つのは、きわめて重要な初期の段階である。

  9. 舞台裏を見せる

  10. カーテンの向こうで何が起きているかを顧客に知らせてあげよう。そうすればビジネス面での見返りがあるし、会社や製品の忠実なファンをつかむこともできる

  11. クリックは二回よりも一回の方がいい

  12. ミスを許容する

  13. 「自動保存」や「もとに戻す」コマンド

  14. 傷つけないことが第一

  15. 当たり前のことに聞こえるが、あまりにも多くの企業がこの最も基本的な原則を忘れている

  16. チェックリスト

  17. チェックしなければいけない基本機能と互換性の一覧

  18. 必要事項のチェックリストを作成しよう

  19. すばらしいおまけ

  20. すばらしいアクセサリーや小さい部品が製品自体を支えることがある

未来を生きる

  • バートンのスノーボード、eシュワブ、ヤフー、スウォッチのすべてに共通しているのは、ライバルを模倣しなかったことだ。

  • 高齢者に製品やサービスを売るのなら、退職者のコミュニティやコーヒーショップへ行ってみるのも悪くない。

映画の予告編をつくる

製品やサービスを開発しながら広告を書いてみよう

完璧なスイングを身につける

何より大切なのは、できる限り練習することだ

  • 顧客を(顧客でない人々をも)観察する。特に熱中している人がいい

  • 前向きな「ボディランゲージ」を従業員と訪問者に送れるような仕事場を工夫する

  • 製品やサービスを提供するとき、「名詞」ではなく、「動詞」で考える

  • ルールを破り「失敗して前進する」

  • 人間らしさを失わず、組織の環境を調整して、ホットチームが生まれ育つ環境をつくる

  • 一つの部門から別の部門へ、会社から将来の顧客へ、そして最終的には現在から未来への橋をかける

「Clean Archtecture」読んだので備忘録

評判のいい「Clean Archtecture」を読んで役に立ちそう感あったので、章ごとに印象に残ったところを備忘録として書いてみる。

著者は通称「アンクルボブ」と呼ばれている1970年からプログラマをやってる超ベテランの人。この本が出版されたのが2017年なので50年近くプログラマの経験があることになる、

著者のキャリアで一番長いのはJavaによる業務システム開発だけど、WEB、組み込みといろんなシステムの構築経験がある人で、アーキテクチャ選定を間違えてしまったがために踏んできた地雷について様々語られている。

本の構成

第一部がイントロダクション、第二部がプログラミングパラダイム、第三部が設計の原則、第四部がコンポーネントの原則、第五部がアーキテクチャー、第六部が「詳細」第七部が付録で「アーキテクチャ考古学」について語られるという構成になっている。

第一部

導入箇所でソフトウェアアーキテクチャの定義だったり重要性、著者の紹介など。

ここでアーキテクチャの目的がこう定義されている

ソフトウェアアーキテクチャの目的は、求められるシステムを構築・保守するために必要な人材を最小限に抑えることである

第二部

プログラミングパラダイム

プログラミングパラダイムがテーマ。構造型プログラミング、オブジェクト指向プログラミング、関数型プログラミングなど。著者の意見としては「アーキテクトとプログラマは別のスキルセットだからアーキテクチャはプログラミングなど知らなくて良い」的なたまにある意見には反対派なので(というか今時賛成派の人いるのか、、)アーキテクチャの話に繋がる前提としてプログラミングについて語っている。

パラダイムの歴史的な教訓は、アーキテクチャとどのように関係しているのだろうか?「すべて」において関係している。

ソフトウェア(コンピュータプログラム)の本質は、「順次」「選択」「反復」と「間接参照」で構成されている。それ以上でも、それ以下でもない。

第三部

SOLID原則について

SOLID原則の目的としては

変更に強いこと 理解しやすいこと コンポーネントの基盤として、多くのソフトウェアシステムで利用できること

  • SRP:単一責任の原則

    ここのモジュールを変更する理由がたったひとつになるように、ソフトウェアシステムの構造がそれを使う組織の社会構造に大きな影響を受けるようにする

  • OCP:オープン・クローズトの原則

    既存のコードの変更よりも新しいコードの追加によって、システムの振る舞いを変更変更できるように設計すべきである

  • LSP:リスコフの置き換え原則

    要するに、交換可能なパーツを使ってソフトウェアシステムを構築するなら、ここのパーツが交換可能となるような契約に従わなければならないということ

  • ISPインターフェイス分離の原則

    ソフトウェアを設計する際には、使っていないものへの依存を回避すべきだという原則

  • DIP:依存関係逆転の原則

    上位レベルの方針の実装コードは、下位レベルの詳細の実装コードに依存すべきではなく、逆に詳細側が方針に依存すべきであるという原則

第四部

コンポーネントの原則

コンポーネントとは、デプロイの単位のことである。システムの一部としてデプロイできる、最小限のまとまりを指す。

  • 再利用・リリース等価の原則(REP)

    再利用の単位とリリースの単位は等価になる

  • 閉鎖性共通の原則(CCP)

    同じ理由、同じタイミングで変更されるクラスをコンポーネントにまとめること。変更の理由やタイミングが異なるクラスは、別のコンポーネントに分けること。

  • 全再利用の原則(CRP

    コンポーネントのユーザに対して、実際には使わない者への依存を強要してはいけない。

第五部

アーキテクチャ

アーキテクチャの形状の目的は、そこに含まれるソフトウェアシステムの開発・デプロイ・運用・保守を容易にすることである 最終的な目的は、システムのライフタイムコストを最小限に抑え、プログラマの生産性を最大にすることである

あと、組み込みシステムのアーキテクチャの話が、異次元だけど業務システムとかWEBとも共通するところありそうで「へー」ってなった。

第六部

詳細

アーキテクチャのエンティティ(構成要素)として語られないものについて。これを「詳細」と定義している。アーキテクチャに含まない方がいいものとして「データベース」、「ウェブ」、「フレームワーク」を挙げている。

  • データベース

    データベースは、ディスクとRAMとの間でデータを移動する仕組みにすぎない。 アーキテクチャ的な観点からすると、回転する磁気ディスクに存在するデータがどんな形式であるか気にすることはない。

  • ウェブ

    結論はsinnpuruda.GUIは詳細である。ウェブは詳細である。したがってウェブは詳細である。

  • フレームワーク

    フレームワークにはどんなリスクがあるのだろうか。ここでいくつか挙げてみよう

  • フレームワークアーキテクチャになんがあることが少なくない
  • プロダクトが成長するに連れて、フレームワークの提供する機能では手に追えなくなってくる
  • フレームワークが進化する方向が、あなたの望む道からずれてしまうかもしれない
  • 優れたフレームワークを見つけたときに、乗り換えたくなる可能性がある

まとめとして

優れたアーキテクトは、システムのアーキテクチャが下位レベルの仕組みに汚染されることを許さない。

付録(アーキテクチャ考古学)

著者の長いキャリアの中で関わってきたシステムの話。アセンブラの時代からの話でアーキテクチャ軽んじるとどうなるか伝わってきた。。

今まで聴いたエンジニアリングのPodcast

通勤中に結構エンジニアリングのPodcastを聴いてきたのでなんとなく感想書いてみる。

結構聞いたやつ

  • Rebuild
  • TuringComplete
  • Admins Bar
  • EMFM

Rebuild

多分日本語のエンジニアリングPodcastで一番有名なやつ。ゲストも豪華。

WEBエンジニアのPodcastだけどプログラミング以外の話題も多くてあんまり構えずに聴ける。

その他の話題が多い。ざっと印象に残っている範囲で書くと

  • ガジェット
  • 将棋
  • アメリカ生活
  • ゲームとか海外ドラマとか映画とかアニメ とか色々。

TuringComplete

システムプログラミングを話題にしたPodcast。Cコンパイラを作る話とか任天堂Switchのエミュレータ書いた話とか、東大のCPU実験の話とかコンピュータに近い開発の話題がメイン。

私みたいに業務システムとWEB開発が仕事のエンジニアだと何言ってるのかわからない部分も多いんだけど不思議と面白く聴けてしまう。

Admins Bar

クックパッドのCTOが配信しているPodcast。インフラの話がメイン。最近あまり配信されてないけど、業務システム時代にこれとRebuildを聞いて「あれ。。今の職場と話題が全然違う。。」みたいに感じて焦った思い出。

EMFM

最近ちょこちょこ聞いているエンジニアリングマネージメントをテーマにしたPodcast。DMM(元グノシー)CTOとか、GMOペパボのCTOとかエンジニアの中で有名らしい人たちの話を聞けて面白かった。