ambie wireless earcuffs レビュー

ambie.co.jp

ambie wireless earcuffs（アンビー ワイヤレスイヤカフ） (Cactus Green)

今年の1月に買ってたらしい。 8ヶ月くらい経過してたつもりだったがまだ半年だった。 いまのところ普段使いとして不満らしい不満はあまりなくて、結構満足して使えている。

良い点

周りに音がほぼ漏れない

使ったことのある人には釈迦に説法なんだが思った以上に周りに音が漏れない。

以前iPhoneで使用していたときに事務所で隣りにいた人が音漏れに気づくまでどれくらい音量をあげられるか検証したところ最大近くになるまで気づかなかった。 これは事前に「音漏れしてたら教えてね」という意識させた状態でそれだったのでかなり気づかれにくい。

顔と顔をよせあうレベルまでいくとさすがに気づかれるが一般的に電車の中で隣になった人が音に気づくか？というとほぼわからないと思う。 イメージ的には指向性のスピーカーという感じで耳の穴に向けて指向しているので音漏れが少ないのでは？と思ってる。

静かなオフィスとかだったらこれで十分。うるさいオフィスだと厳しい。

耳奥までいれなくてすむ

ワイヤレス…なのは最近ではあまり珍しくないんだけど耳を塞がないという体験が思ったよりも素晴らしい。 ぼくはカナル型イヤフォンをいままで愛用していたのだけどどうしても密閉している関係で耳垢が溜まりやすくなったり、湿気の高い日などはじっとりしてしまうことがあったんだけどそれが解消されてめちゃくちゃハッピーな気持ちになってる。 これで毎回耳掃除しなくていい。

外の音を検知しやすい

ジョギングをするときにジョギングの上下の振動と口呼吸によって顎が動くことでイヤフォンがズレるということがあった。 比較的フィットするものを選んでいつも買っていたのだけど、イヤーカフは耳たぶに挟む形なのでそれがない。素晴らしい。

またジョギングをしているとカナル型イヤフォンだと外の音が聞こえにくくなってしまい危ないなと思うことが何度かあった。 こちらが悪いケースもあったし、そうでないケースもある。特に夜間などは自転車側もわかりにくいケースがあると思うので自衛としてイヤーカフを買うモチベーションの1つになっていた。

後ろから自転車が来ていたが気づかなかったとか無灯火の自転車に引かれそうになったとかまあジョギングしてるとよくあるよね、ぼくはよくある。 その点イヤーカフは外の音が入りつつも音楽が聞けて最高という気持ちになる。

BTの接続が比較的安定している

いまのところBT回線の接続が不安定になったことがない。 綺麗に聞けているしBoseのQC30と比べても遜色ないレベルで安定している…と思う。

何故かよく声をかけられる

勉強会などでつけていくと「それambieのやつですよね！」と見知らぬかたから声をかけられることが増えた。 みんな「気になってるけど音漏れが心配で買えないんですよねー」と言われることが多く気になってるんだな感がある。 ぼくもかつてはその1人だったので率直な感想を出来るだけ伝えるようにしている。

改善してほしい点

周りの音が強いと音が掻き消される

これは良い点の逆パターンなので仕方ないなと諦めているんだけど電車や駅のホーム、風の強い日などのある程度以上に外の音が強い状態だと音楽が打ち消されることがある。 特にぼくはジョギングしながらpodcastとかを聞いていることがあるんだけどポップスやアニソン、ロックなどの比較的ポップな音楽はまだしもクラシックやジャズ、podcastのようなものは聞き取りにくくなる傾向がある。

ジョギング中にクラシックやジャズはあまり聞かないがpodcastは割とよく聞いていたので少し残念だなという気持ちがある。 指向性が向上して音の集約性が高くなったら解決したりしないかな？という気持ちとそれよりは音源側をなんとかしたほうが早そうという気持ちの2つがある。

ネック部分なくしてほしい

まだ技術的に不可能だろうなという思いはあるんだけどネック部分はやはり無くしてほしいなという思いがある。 じゃあどこで音量とか電源をコントロールするんだよ！みたいな話しになりそうだけど、まあまあ邪魔なのでせめてスリム化してほしいなと思うことがある。

最初は少しイヤーカフが硬い

慣れるまで結構耳たぶに挟めなくてうーん、微妙…みたいな気持ちになった。 慣れるとそうでもない。慣れるまではそんなにかからなかったと思うけどその後もまれにうまく挟めない…みたいなことがあったので気にならなくなるまで多めにみて1ヶ月くらいという感じかな？

まとめ

いままでワイヤレスは音質が……みたいな気持ちで敬遠傾向があったんだけどここ何年かはケーブルが擦れてノイズ生んだり誰かの荷物に引っかかったりする鬱陶しさのほうが高くなってしまっていろんなものがワイヤレスにシフトしていっている。

イヤーカフはイヤフォンのイメージが強いと思うんだけど使用しているぼくの感想としては携帯型ワイヤレススピーカーというイメージでいい感じです。 ちなみにスタバとかで使った感想は「スタバの客層、ピーチクパーチクうるせえ」だったのでうるさいと思う基準の参考にしてください。

雨の日

今週のお題「雨の日の楽しみ方」

雨の日、外に行く用事があるとひたすらにダルい。 でも家のなかで雨粒が屋根を叩く音、ガラスを叩く音は嫌いじゃない。

ランダムなビートを刻む自然の音楽祭みたいな気持ちでこういうときに娯楽小説、それもミステリーを読むと捗る。 普段とは違うまったりとした時間の使い方をした気持ちになって贅沢だなと思う。

最近だとアプリで雨音を再生したりするものもあるがどうしても機械的なニュアンスを感じてしまうことがあり即興には敵わないと思ってしまう。 ただの思いこみバイアスかもしれないけども。

京都でお気に入りの喫茶店とパン屋

喫茶店編

六曜社

beacon-kyoto.com

ここの濃ゆいコーヒーにミルクをたっぷりいれるのがぼくの最高のコーヒー。 コーヒーの苦さとミルクの甘さ、それらが混ざったまろやかさとコクが好みです。 あとその状態で食べるドーナツがうまい。

難点は喫煙しているひとがいるとダルいのと混むのであまりゆっくりしてられない。

スマート珈琲

www.smartcoffee.jp

なんか最近いついっても人が並んでいるのでそのまま踵を返すことが多くなってしまったけど奇跡的に人がいないときにいくとまったり出来てよい。

カフェ火裏蓮花

cafequarirengue.wixsite.com

スマート珈琲にするか悩んだ結果こっちにした。スマート珈琲は最近並んでるひとが多すぎていけてないしね。

普通にしていると素通りして気づかない路地にぽつんとある町家を改装したブックカフェ。 店内にある本は好きに手にとって読んでいいとのこと、最高。

コーヒーに変わり種っぽいのがあるけどまったり出来て良い。 アガサ・クリスティーのアクロイド殺しまだ読了してないのでまた近日中によりたい。

ランチのプレートも美味しいけどピラフが美味しくてボリュームあって満足度高かった。

自家焙煎喫茶インパルス

www.kyoto-kawaramachi.or.jp

繁華街にある立地でありながらも上記の店舗などに比べて非常にゆったりした空気感がある。 サイフォン式でコーヒーを淹れてくれるのだけどついつい見入ってしまう。

生きている珈琲

ikiteiru.com

薄暗い店内と落ち着いた雰囲気、そして電源とwifiがあり最高of最高！！！ どのコーヒーが苦味があるとか酸味がつよいなどの四象限な表を用意してくれているのでコーヒーよくわからん！みたいなぼくでも色々試し飲みしてみようと思える。 コピ・ルアックのコーヒーもあるらしいが1杯3000円以上しているので頼んだことがない。一度頼んでみたい。

パン屋編

Café Bibliotic Hello!

cafe-hello.jp

喫茶店としてもお気に入りなんだけども隣にあるパン屋のパンがマジでうまい。 外側の生地がしっかりしているのだけど中はもっちりしていて小麦の甘みをしっかり感じさせてくれる。

ナカガワ 小麦店

nakagawakomugiten.com

わざわざ自転車で片道10km走って買いに行ったら14時くらいなのに売り切れていて出直したことがある思い出のお店。 とにかく小麦にこだわっていてパンがパンとして極上にうまい。 朝の贅沢〜！みたいな気持ちにしてくれる。

グランディール

grandir-kyoto.jp

よく行くのは京都ポルタ店と下鴨店。 下鴨店のほうがよくいくかも。春先あたりの少し肌寒いときにコーヒーとパニーニを鴨川で食べてるとクソエモでおすすめ。

ファイブラン

fiveran.jp

試食したいパンがあれば遠慮なくお申し出ください。見た目では選ばないパンもあると思いますが、食べてもらわないと分かりません。

と書かれている通りほぼ全品試食が可能。気に入ったものを買って帰ることができる。 この店も生地にこだわりがあり、比較的薄めだがパリッとした外側の生地とモチモチした中の食感が日本人好みなパン。

菓子パン系も多くあるので子供やお母さん方に人気があるっぽい。でもわざわざ観光客のひとが買いに来ているのもみたので有名なお店？かも。

たま木亭

www.tamaki-tei.com

とにかくうまい。 そしてめちゃくちゃ並ぶ、とにかく並ぶ。 駐車場は第二か第三まであるらしいのだがそれがいついっても満車になってる。夏行くと死んじゃうので飲み物買っておいたほうがいいですよ。

1店舗なのに本になっちゃうくらいうまい。

忘れられないパン 「たま木亭」

うまいパンは語る―京都「たま木亭」玉木潤の直感と計算 (旭屋出版MOOK)

難点は遠いこと。 もはや京都ではなく宇治。

まとめ

他にもカフェ kociとかeightとか逃現郷とかあるんだけど紹介しきれない&めんどくさくなったのでこのくらいで切り上げる。 なんでこんなことをしたかというと最近お気に入りだった飲食店が潰れてしまっていて大変悲しい思いをしたので常日頃から感謝の気持ちをしつつちゃんと儲かってほしいな、継続可能なおいしいパン屋や喫茶店が残り続けてほしいなと思ったのでリストアップしました。

wifiと電源がほしければスタバいけばいいんだけどそうじゃなくて雰囲気や食べるもの、飲むものも楽しめるお店が残り続けてほしいなと願ったという感じです。 閉店告知される前に定期的にお店に行こうな！

IT未経験者の問題じゃなくてメンター側の問題だと思う。

note.mu

前提となる条件の会社で働いたことがないので正直的外れなのかもしれない。 でもぼくはこれを読んだときの素直な感想として「これは違うんじゃないかなー？」と思った。

とはいえ完全に否定したいわけでもなくて同意ポイントと違和感ポイントがあるなという感じです。

追記

ブコメでテスターでもいいんじゃないの？というコメントをみかけて誤解させてしまう文章を書いてしまったなと思ったので訂正です。

id: hotu_ta 自分は、自然とブラックボックステストっぽいことからエンジニアの人生を歩み始めたし、テスターからエンジニア的な理解を深めていくのは悪くないアプローチに感じる。

テスターそのものから開始すること、それ自体はあってもいいのではないか？と思います。 ただ上記エントリでの問題を解決するためにテスターを選択するのは短絡的な解決方法であって根本治療ではないのでは？ということで書いた感じです。

きちんとメンターがメンティーに対してチケットを渡せる粒度に落とし込めていればそもそもテスターになる必要はないかもしれませんし、その上で一度テスターになって全体のフローを知ろうというのであれば多分ひっかかりはなかったと思います。 誤解させる文章になっていてすみません。

同意ポイント 「徐々にできる範囲を広げる」

これは「やれる」という自信を持ってもらうためにまず実績を積むという意味だと思うんだけど大賛成。 まずはやれるところから、そしてやれるところを少しずつ増やす。 振り返りや1on1などで前回はここまでしか出来なかったのにいまはこんなに出来るようになったよ！すごい！！！みたいなことをきちんと伝えると自信と実績をちゃんと評価してますよというフィードバックになってよいんじゃないかな。

同意ポイント 「テスター案件で指導の下、「プログラマーの仕事の一部」としてシステム開発の仕事に慣れる」

これはIT未経験者だから、とか関係なく自分が知らないプロジェクトに参画したときによくやる手法の1つだと思うので賛成。 例えば転職して今日からAチームに配属されました、コードはここで環境はこれで…とその日のうちに開発できる状態になったと仮定する。 その状態でまずなにをするか？明確に事前の支持がある場合はそれに従うけどもそうでなければ自分ができそうだと思うissueを拾って直してしまうかな。

これには2つ良いと思ってる面がある。

1つ、時間的制約があって後回しになっている軽微なバグを直すことでどう動いているのか確認できる 2つ、入ったばかりのチームに貢献したという自信がつく 3つ、自分という存在のプレゼンスを強調できる

2つといったな、あれは嘘だ。3つだったわ、めんご。

なので「テストから入る」自体には賛成という立場です。

違和感ポイント 「果たしてテスターから始めるのが正しいのか？」

なるべく易しい案件から始めて、潰れずにゆっくり成長してほしい

これは多分未経験者を採用するうえでメンターや上司、会社として誰もがそう考えることだと思う。 反面きちんとこのコンテクストが共有されるなら別にテスターでなくてもいいのかなと思う。

フィヨルドブートキャンプを主催されている方のブログかなにかで「プログラミングのオンライン教室に通うだけでは会社の戦力にならない。では戦力とはなにか？どんなに簡単なissueであったとしても独力で解決できることだと私達は考える。」みたいな話があっておおー！なるほど！ってぼくは思ったんだけどそうすると↑の考え方は「イシューからはじめよ」でいうところの「犬の道」のように感じる。

確かに辞めにくくはなるかもしれない、生存確率は上がるかもしれない。 でもIT未経験者がわざわざ未経験であるというハンディキャップを押してITの扉を叩いているのは「何かを創りたい」という強烈な創造的な思いからだろう。

そこにイメージと違うテスターという仕事をあてがったとする。

ぼくなら「プログラマとしてものを作る仕事につきたいと考えていたのに雑用をさせられている」と感じてしまうのではないかなと思う。 結果としてテスターのことを誰でもできる些末な雑事と認識してしまう可能性まであると考えるとそれはすごく危険な賭けに思えてくる。 もしここでテストのことを軽視してしまうとそのあとは地獄しか待っていないだろう、恐ろしい。

このブログでは特定の状態にフォーカスしていないのでこういう書き方なんだろうけども自分がメンターだったとしたらまず「どういうキャリアを目指していきたいのか」「何故そのキャリアを目指すのか」「ぼくが協力できることはなにか」あたりを聞いたり確認したりすると思う。 その上で「じゃああなたはテスターをやってみるのがいいですね」となったら進めるかもしれない。

でも多分IT未経験者がいきなりそんなことになるか？というと最初はそうではなく「ものづくりに携わりたいです！」とかもっとふわっとした内容だと思う。 そこにいきなり「じゃあテスターやろうか」っていったら最初のやる気を挫く可能性があるとぼくは思って逆にそっちのほうが怖いなと感じた。

つまり何故テスターをやるのか？のコンテクストが重要できちんとその情報が共有されていない場合非常に怖いことになると思うのが違和感としてあります。

多分やりたいこととしては「やれることの実績を積む」「プログラミングのワークフローを知る」あたりを学んでほしいんだろうけどその手段としてテスターをする、は少し的はずれなように感じた。 別にテスターでなくてもそれらは習得可能かなと思う。テストから始めるの自体を否定したいわけではないが専任するほどのことかな？そんなに人的リソース余ってるの？って気持ちになった。

「じゃあお前やったらどうすんねん！」となるんだけどぼくなら細かいバグだけど優先順位の問題で後回しにしているもの、やれば一瞬で終わるんだけど後回しにしているものを担当して直してもらうかな。 あとはテストコードを書いてもらう、ここで重要なのはテスターではなく実際にテストのコードを書いてもらうということ。

いきなり1機能を実装してもらうとかはサービスがどう動いているのかわからない人がやりきれるとは思えない。

例えバグっても影響が軽微なものを担当してもらうか、最悪バグって壊れてもサービスに影響がないことをやってもらう。 そのほうが任された側も安心してコードを書けると思うし。

あとはいきなりissue渡すんじゃなくてペアプロで一緒のタスクをこなすとかデプロイを一緒にペアオペするあたりはするかな。

違和感ポイント 「もしかしてメンターがいない？」

文中だと先輩プログラマの話題がでるけどメンターのような存在がでてこなかったのが違和感として残った。 この問題の多くの部分はメンター側が適切なアドバイスやサポートができれば大部分解決できると思うものばかりだったのでいきなり「テスターからはじめよ」に飛躍しなくてもちゃんとメンターメンティーの関係と時間を持てばほぼほぼ解決するんじゃあないかな。 なんとなくだけどこのブログからは先輩プログラマの時間を使わせないようにするような臭いを感じていてそれをメンティー側に求めるのは違うでしょ？と感じた。

課題はメンティー側ではなくメンター側にあると思う。あるいはそのメンターを取り巻く環境か。

違和感ポイント 「テストって何度も言いましたがそんなに難しくないんですよ」

テストってプログラムがどう動かないといけないのか、どういう振る舞いを期待しているのか、そのための事前の条件はなにか？みたいなのがわかってないと書けない、試せないと思うので「難しくない」は明らかに偽だと思う。 ここでいうテストがいわゆる手動テスト、動作検証なんだろうと思うんだけどそれだって「なにをどうしたらこうなった」を伝えるというのは結構しんどい。

またテスターに求められる能力の一つに違和感と期待する動きがあると思うんだけどそのためにはこのシステムやサービスがどういう期待のもと動いていないといけないか？というのがわからないといけないとぼくは思う。 なのでここは少し誤解を生む表現をしていると思った。

違和感ポイント 「事情は分かった。でもテスターはスキップしたい。開発案件に入るにはどうしたら？」

これが一番気になるテーマかなと思います。でも敢えて言います。

自分で考えてください。

ここが最大にひっかかったところなんだけど

え？なんでいきなり突き放したの？？？ってめちゃくちゃ疑問。 気持ち的にはちゃぶ台返しされた気持ちでもうこの時点でぼくの評価は真逆になってしまった。

攻略wikiの手順通りにゲームをクリアしていく感覚は、テスト実施の次のステップであるテスト項目作りあたりからだんだん通用しなくなります。

これはその通りなんだけど前提条件としてIT未経験者なんだよね？だったらまずは「守破離」で真似るところから始めましょうとかそういう話をすべきでない？ 多分ぼくはメンターよりな立場としてこのブログを読んでいてその観点からいうとこの結論は許容し難い。

正直それなら何も書かないでいたほうが良かったんじゃないかとすら思ってしまう。 考えさせたいというのはわかるんだけど、ターゲットはIT未経験者だよ？ IT未経験者だったときにこんなことをもし言われたぼくならそれだけでマインドがブレイキングチェンジですよ。

まとめ

基本的にひっかかるというか違うんじゃね？って思うポイントはメンターメンティーの関係を作る、1on1する、OKRのような目的を考えるあたりでほぼほぼ解決すると思うしどちらかというIT未経験者の課題というより出題者側(先輩プログラマ、上司、会社)の課題だと感じた。

それをIT未経験者に自力で解決させようとするのが根本的な問題ではないかなと思う。

プログラマなら当然知ってるよね？でもぼくは知らんので振り返りしてみた

anopara.net

↑元ネタ。

この手の話は定期的にあがり、そしてだいたいGW前後に発生してそのたびに「あーこれぼく知らないな…」とかよく思ってたんだけどとりあえず「これ読んどけば頭の片隅にはある」レベルを目指すというめちゃくちゃ志の低いやっていきと今何を理解してるのか振り返りとして書き出して来年どうなってるか計測しようと思って書き出した。

あともしこのエントリをみて「これ読んどけ」みたいなのあれば教えてくれると助かります。 他にも海外版これ読んどけがあったのでそれもあわせて読んでおけばだいたいのところはカバーできるんじゃあないかという目論見です。

medium.freecodecamp.org

プログラマだったら当然知っててほしいと思う知識

データ構造

プログラミングコンテスト攻略のためのアルゴリズムとデータ構造

ブログなどでよく見かけるシリーズ。未読。 当たり前なんだけどデータ構造、だいたいアルゴリズムとセットで書籍として語られることが多いのでこれが一番いいというわけではないが以前なにかで紹介されていて気になって積読リストにいれたところで止まってる。

計算量（計算複雑性）

正直よくわからない。 専門学校で習った気はするんだが改めてこれを勉強し直そうと思ったときに必要な書籍ってなんだろう？ってなった。 数学とかCSあたりの書籍を当たればいいのだろうか？

おすすめあれば教えてください。

アルゴリズム

定本 Cプログラマのためのアルゴリズムとデータ構造 (SOFTBANK BOOKS)

アルゴリズムと聞いて思い出す1冊なんだがよく紹介されているという覚え方で読んだこと無い。 最近よくアルゴリズム関連の書籍がいっぱい出ていたのでこれがいいというのが変わってそうな気もする。

数値計算

おすすめあれば教えてくださいシリーズ。

これは技術書というより数学的分野かなと思うので高校数学とかの教科書読めばいいかも？

グラフ理論

おすすめあれば教えてくださいシリーズ。

有向・無向グラフ、木、ループ、カット、彩色、結婚定理とかの基礎の理解

とあるので多分そういう名称だと知らずに認識している（Not理解）可能性がある。 グラフ理論、データ構造とかの亜種というかそういう話の流れで語られてそう。

理論計算機

おすすめあれば教えてくださいシリーズ。 正規表現に関しては使っているし列挙されたなかでは理解できる。 他は名前聞いたことあるレベルからそもそも知らないまで幅広すぎるので正規表現以外知らないといってしまっていいかも。

セキュリティ・暗号化

暗号技術入門 第3版　秘密の国のアリス

歴史的経緯とかどういう理屈で暗号化されているのか？などが非常にわかりやすかった。 専門職でないのでわからないけどぼくが暗号化で上げるとしたらこれが一番最初にあがる。

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

それぞれのパラダイムには理由があるので1冊でざっくり知るのが難しそう。 Clean Architectureにそれぞれの歴史的経緯とか書かれていたのでニュアンスとしては1冊選ぶならそれかも？

Clean Architecture 達人に学ぶソフトウェアの構造と設計

並列・非同期処理の基礎

増補改訂版 Java言語で学ぶデザインパターン入門 マルチスレッド編

以前いた職場でJavaだし、古いけどめちゃくちゃいい本だよとおすすめされた本。未読。

できれば知っておいたほうが良いと思う知識

ソフトウェア工学

DDDの文脈だとこれらが定番なのかな。エリック・エヴァンスのほうは読んだ。実践ドメイン駆動設計は未読。

エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)

実践ドメイン駆動設計 (Object Oriented SELECTION)

DDDではないがユースケース駆動開発実践ガイドを以前ビブリオバトルで紹介されたのでいれるとしたらここかなと思って追加した。

ユースケース駆動開発実践ガイド

最近読んだ本で良書だなと思ったのがClean Architecture。 ただ一部納得いってないのと飲み込みきれてない感じがすごくするのでまた再読する予定、一応読了済み。

Clean Architecture 達人に学ぶソフトウェアの構造と設計

現代コンピュータの性能

正直詳しくないのでどれくらい知ってることが効果的なのか？とかよくわからない。 マルチコアとシングルコアによる違いとかはTechブログなどで「○○だと1コアしか使わないのでマルチコアを活かしきれない」みたいなのを呼んでるくらいのざっくりした認識でしかないのでなにか読んだらまとまった知識が手に入る…みたいなのあれば知りたい。

CPUの仕組み

CPUの創りかた

古い本だけどこれがいいと聞いたことがある。 正直ハードウェア周りは疎いのでわからない。

OSの仕組み

30日でできる! OS自作入門

[試して理解]Linuxのしくみ ~実験と図解で学ぶOSとハードウェアの基礎知識

両方とも読みたいとは思うもののなかなか読み出すきっかけがつかず積読になってる。 読んだ人の評価などをみてるとどちらも良さそうな雰囲気は感じる。

ネットワーク（7階層モデル, IP, TCP, UDP, HTTP, HTTPSなど）

マスタリングTCP/IP 入門編 第5版

昔そーだいとか言う人に雑に「なんかおすすめのこれ読んどけ！みたいな本あります？」って質問したら3冊くらいタイトルが返ってきた唯一未読な本。 未読なので当然読めてない、ごめんなさい。

セキュリティ

防ぎ方、というよりはどういう攻撃経路があってなんでそれが可能なのか？みたいなところっぽいので前述のセキュリティーとは多分違うコンテクストっぽいんだけどあってるかわからん。

体系的に学ぶ 安全なWebアプリケーションの作り方 第2版［リフロー版］　脆弱性が生まれる原理と対策の実践

あとは気になってるレベルだけどこの2冊が良さそう。

ハッキング・ラボのつくりかた 仮想環境におけるハッカー体験学習

ハッカーの学校

統計・データマイニング・機械学習系の基礎知識

正直全くわからない。 ここ数年？機械学習系の書籍が大量出版されているせいでどれがいいとか悪いとかすら判断がつかない。

手元にあるのはこれだけ、これだって数学的知識の欠落が激しくてなかなか読み進められていない。

やさしく学ぶ 機械学習を理解するための数学のきほん ~アヤノ&ミオと一緒に学ぶ 機械学習の理論と数学、実装まで~

その他シリーズ

海外版これ読んどけシリーズにリストアップされてたけどどこに入れればいいのかわからなかったやつら。

Clean Code アジャイルソフトウェア達人の技

Clean Coder プロフェッショナルプログラマへの道

Robert.C.MartinのCleanシリーズ。未読。 Clean Architectureが良書だったのでそのうち買って読もうと積読リストの上位に追加した。

Refactoring: Improving the Design of Existing Code (2nd Edition) (Addison-Wesley Signature Series (Fowler))

去年？だかに英語で第2版が出て話題になったやつ。日本語版出たらそっちを買う予定なので当然未読。

オブジェクト指向における再利用のためのデザインパターン

これ読んどけと紹介されたが日本だと↓のほうがよく紹介されている気がする&Java言語で学ぶ〜のほうは購入済みなので読むならそっちかな。

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

明確にこっちのほうがいいとかあればコメントかブコメで指摘をお願いします。

SOFT SKILLS　ソフトウェア開発者の人生マニュアル

読む人によって感想が違うのが面白いが個人的にはそういう生き方はあっていいと思うがぼくにはあわなさそうという感想を抱いて途中で読むの辞めた。

The Effective Engineer: How to Leverage Your Efforts in Software Engineering to Make a Disproportionate and Meaningful Impact

完全に知らないやつ。 ちょっと興味があるんだけど英語だし、どうもプログラミングに関係するというよりはSoft Skillsっぽい雰囲気を感じているのでそうすると英語で読みきるのが難しそうだなと感じて尻込みしている。

新装版 達人プログラマー 職人から名匠への道

購入はしたんだけどまだ未読。

まとめ

海外でも名著と呼ばれるものはさほど差がないのが面白いなと思ったのとCSを学んでおらず実践でそのばその場で知識のつまみ食いをしてきたのでやはり不足している知識が広範に渡っているのが見える化されたのが厳しい。

来年の今頃までにいくつかの書籍を読んで少なくとも「頭の片隅にはある」という状態にレベルアップしておきたい。

あと日本だと定番のパール本が海外だと上がっていなかったのが少し面白いというか不思議に思った。未読だけどいい書籍らしいといろんな人がいうので当然リストアップされているだろうと思ったらなくてビックリした。

珠玉のプログラミング 本質を見抜いたアルゴリズムとデータ構造

追記分

文系出身ですが、「みんなのコンピューターサイエンス」は、元ネタで記載されているエントリポイントをある程度網羅しているのかなと思います。

— guxiken (@__annkara__) June 4, 2019

みんなのコンピュータサイエンス

目次見たかんじおっしゃる通り満遍なくフォローしてくれてそう。 ざっくり理解するのには良さげ。

更に追加情報をもらえたので追記。

いえいえ。追加で恐縮ですが、オライリーの「詳解システムパフォーマンス」は見た目の分量に対して、理論編と実践編で分かれていて理論編だけでもCPUやメモリなどのパフォーマンス観点での理解が得られるので、おすすめしたいなと思いました。

— guxiken (@__annkara__) 2019年6月4日

詳解 システム・パフォーマンス

詳解システムパフォーマンス、各社の輪読会とかで話題になりますね。ぼくが観測した範囲だとHatenaさんとかMisocaさんとか良さそうという気持ちはありつつあの厚みに心砕けそうです。

ザ・コーチ

ザ・コーチ

読んだ。

blog.shibayu36.org

しばゆーさんが読んでいたレビューをみて面白そうだと思い購入…3年近く経過してしまったことが判明した、反省。 気になったときが読み時なのでこういうものはガガガッと勢いに任せてとりあえず目を通してしまったほうがいいなと思いました。

別の書籍などを優先していたらなかなか読まずにいた&Clean Architectureを読んだあとだったので口直しに軽いものが読みたいという気持ちもあってえいやっ！という感じで読み始めた。

ストーリー仕立てなのでさっと読めた、もっと早くに読んでいてもよかったかもしれない。 多分読んだ時間はメモ取りながらで3時間〜4時間くらい。Kindleの目安読書時間が2時間半くらいなのでまあそんなところかな、という感じがする。

期待していたのはコーチングとかの技術習得のためだったんだけどもしばゆーさんも書いているとおりコーチングという分野を全体的に学ぶ…ということにはあまり向いていなかった。 時間が立っていたので完全に忘れていたがある意味で先入観なく読めたのでそれはそれでよしという気持ちがある。

反面、目的や目標、ゴールなどの概念として知ってるけどもそれぞれがどういうものか？というのを再認識&無知の知を教えてくれるという意味においていい本だった。 登場人物が主にメンターとメンティーの立場なので自分がどちらの立場を想定しているのか？という立ち位置を変えて読んでみるとまた少し違った印象を持つかもしれないなと読んでいて感じた。

ぼくは今回メンティー的な立場で読んだけどもメンターとして読んだ場合彼にどうアドバイスするだろう？というのを考えている自分がいたし、メンター的な立場にたったときにこのように的確な「考えさせ、答えをみつけさせるよう自発的な行動を促す」助言が思いつかなかったのでまだまだ学ぶところがありそうだと感じた。

そういう意味では参考例として自分だったらこうする、ああするという題材にしやすいのかもしれない。

文中にも目標の達人という言葉が出てくるがまさしく主題として目標があり、それを如何にうまく達成するか？ そのためにどういったことを考える、考えさせるとよいのか、という面の情報が強化された感じがした。

1on1などをする前にメンター、メンティー双方が読んでおくとなんのための目的で、目標なのか？ 個人としての目標はどこでそこにどう会社の目標を重ねていくのか、みたいな話ができると1on1もより実りがあることにフォーカスできそうだなと読んでいて思った。

いくつかの項目で似た話を別の本で読んだなと感じたところがあった。

特に「死ぬまでに叶えたいドリームリスト100を作る」というのはエンジニアの知的生産術にも似た話が出ていた。 目標は違っても使うツールや手法が似通っているのが面白いと感じたがこれは目的の部分が重複しているからかもしれないなと読んだ後でメモをみながら思った。

個人的に印象に残っているのは「ゴールに向かうということは、今の自分より高みを目指すということです。それは、今の自分のままの力や心では、なし得ないことをしようとすることです」という一文があるんですが、ゴールを目指すということは否応なく変化しなくてはいけなくてそれだけでもすごくチャレンジングなことをしているのだなと改めて気づけたのが良かったですね。

成長し続けないといけないだと息苦しい面がでてしまうことがあるんですがゴールを目指していままさに変遷の最中にいるのだと自分の状況を置き換えると他者と比較したときに遅れていると感じる部分がすこし柔らかくなったように感じました。

個人的に期待した効果、という意味では力不足感が否めないなという印象ではあったのですがそれはそれとしていい言葉、心に勇気をくれる言葉が散りばめられているので悩んでいるときやうまくいかないなと落ち込んでいるときに読み直すことで心の中のワクワクを取り戻せそうな本だなと思います。

本来はこのあと続編を読むか、コーチング全体について書かれた書籍を読むかしたほうがいいんだと思うのですが少々思うところがあるので次はScrumBootCampを読んでいます。

SCRUM BOOT CAMP THE BOOK

そのあとは技術書に戻る予定でClean Architectureをもう一度読み直すか、Java言語で学ぶデザインパターン入門を読む予定です。

Clean Architecture 達人に学ぶソフトウェアの構造と設計

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

もっと褒めてください

友人にQiitaのトレンド乗ってるじゃん！と教えてもらい確認したら本当に乗ってました。 最高なのでもっと褒め称えてください。