2018-11-06

自分が参加した読書会(輪読会)を簡単に紹介

勉強会

先日このようなコメントをいただいたので、

読書会というのは、本をみんなで読む会（そのままですが....）というものなのでしょうか？感想を語り合う、というか

自分が参加したことがある読書会(輪読会)について紹介してみたいと思います

広尾勉強会グループ

特徴:平日開催、懇親会なし、設計、テスト

@t_wadaさん新訳のテスト駆動開発を読みました。

テスト駆動開発

作者: Kent Beck,和田卓人
出版社/メーカー: オーム社
発売日: 2017/10/14
メディア: 単行本（ソフトカバー）
この商品を含むブログ (1件) を見る

スタイルとしては@secret_hamuhamuさん主催で

節、あるいは適切なブロックごとに区切って黙読タイム、討論タイムを設けて読みます。それぞれ適当な時間をはむはむさんがタイマーで区切って本を読みます。

私が参加した読書会の中で唯一音読せず、討論時間もしっかりタイマーで図っているので

進みペースが良い
討論が脱線することが少ない

などの特徴があり、思い返すと生産性が高くなる工夫を一番されていたと思います。転職されたり、本を全て譲渡されたりしたので、今後はむはむさんが勉強会を開催されるかどうかはよくわかりません。

目黒バイナリ勉強会

特徴:SQL、平日開催、懇親会なし

meguro-binary-study.connpass.com

OracleでMySQLのサポートをされている@meijikさんが主催の勉強会です

以下の2冊を読んでいます

Effective SQL

作者: John L. Viescas,Douglas J. Steele,Ben G. Clothier,株式会社クイープ
出版社/メーカー: 翔泳社
発売日: 2017/12/20
メディア: 単行本（ソフトカバー）
この商品を含むブログ (3件) を見る

プログラマのためのSQL 第4版

作者: ジョー・セルコ,Joe Celko,ミック
出版社/メーカー: 翔泳社
発売日: 2013/05/24
メディア: 大型本
この商品を含むブログ (16件) を見る

スタイルとしては基本音読で適当に切れ目がいいところで分担して読んでいきます。

木村さんのMySQL知識が豊富
様々なDBユーザーが集まるので議論が面白い(DB2/Oracle/MySQL/PostgreSQL)

などの特徴があります。どちらの会も勉強になりますが、参加されるならEffective SQLがおすすめです。プログラマのためのSQLはマニア向けな感じがあります。

ちなみに勉強会の名前は@7shiさんが過去に池袋でやっていた池袋バイナリ勉強会のマネらしく、特にバイナリなどの低レイヤー技術をやる会という訳ではなさそうです?

横浜go読書会

特徴:休日開催、懇親会あり、Golang

JavaやGo関連の翻訳などで著名な@yoshiki_shibataさんが主催の勉強会です。月一回ペースでGoに関連する本を読んでいきます。

適当な切れ目で区切って参加者が音読します。

前回までGoならわかるシステムプログラミングを読んでいました。次回からGo言語による並行処理が始まります。

Goならわかるシステムプログラミング

作者: 渋川よしき,ごっちん
出版社/メーカー: ラムダノート
発売日: 2017/10/23
メディア: 単行本（ソフトカバー）
この商品を含むブログを見る

Go言語による並行処理

作者: Katherine Cox-Buday,山口能迪
出版社/メーカー: オライリージャパン
発売日: 2018/10/26
メディア: 単行本（ソフトカバー）
この商品を含むブログを見る

柴田さんがパソコンをプロジェクターに繋げてGoの実装などを写しながら本の内容と対比して説明されたりするので、一人で読んでいては到底得られないような知見を得ることができます。

Java読書会

特徴:休日開催、懇親会あり、実施時間が長い、Java、歴史が長い

@boochnichさん@ttdummyさんが主催の勉強会でJavaに関連する本を毎月1会ペースで読んでいきます。

土曜の朝10:00から夕方17:00までやるので紹介している勉強会の中では一番実施時間長いです。勉強会自体の歴史も一番長く(1998~)継続して参加されている方が多いため

同じ本を共通して読破している
「Java」というキーワードで集まってきているのでそちらの知識が豊富

などの特徴があります。書記以外の参加者が音読し、30分で読み方を交代していきます。今は現場で役立つシステム設計の原則を読んでいます。

現場で役立つシステム設計の原則〜変更を楽で安全にするオブジェクト指向の実践技法

作者: 増田亨
出版社/メーカー: 技術評論社
発売日: 2017/07/05
メディア: Kindle版
この商品を含むブログ (4件) を見る

おそらく次の本はEffective Javaの3版になると思います

前職ではベテランのJavaエンジニアと会話する機会がなかったので、そこが大きなモチベーションでした。

余談ですがttdummyさんはJavaに関する本はほとんど持っているそうです。

分散処理本・CC本読書会

特徴:英語、平日開催、懇親会?あり*1、データベース、分散システム

どちらも英語の本です。@okachimachiorz1さんが朗読して節や段落など切れ目で参加者が自由に意見を言い合います。だいたい2週間に1回くらいのペースで開催されています。

Distributed Computing: Principles, Algorithms, and Systems

作者: Ajay D. Kshemkalyani,Mukesh Singhal
出版社/メーカー: Cambridge University Press
発売日: 2011/03/03
メディア: ペーパーバック
この商品を含むブログを見る

Concurrency Control and Recovery in Database Systems

作者: Philip A. Bernstein,Vassos Hadzilacos,Nathan Goodman
出版社/メーカー: Addison-Wesley
発売日: 1987/02/01
メディア: ハードカバー
この商品を含むブログを見る

参加者は朗読しないため、特に英語が読めなくても問題ないと思います(要予習)。不明瞭なところは随時引用されている論文を参照しにいったり、ホワイトボード上に実際にグラフや図を書いて議論が始まります。

データベースのユーザーではなく開発側の人たちや研究者の方が多く、一般的なソフトウェアエンジニアの知見とは違う文脈で議論が進むため、混乱することがよくあります。

また他の勉強会とかなり毛色が違うこともあり、予習・復習が欠かせません。

まとめ

なんとなく参加したいが、足を引っ張らないだろうか?迷惑ではないだろうかと不安に思うかもしれませんが、担当を決めて予習してきたことをレクチャーするタイプの読書会以外は基本的に誰でもウェルカムな空気があります*2

どの勉強会も自分が一番弱いのでいい感じにBe The Worstができていると思います。

yshibata.blog.so-net.ne.jp

*1:会場近くの中華料理屋などで食事をしています.予算1人1500円程度

*2:主催側の人間ではないので断言はできませんが...

2018-10-27

Java読書会「現場で役立つシステム設計の原則」を読む会第3回に参加

勉強会 DB

午後から参加しました。午前中は多分データベースに関する面白い議論がされていたと思うのでちょっと後悔。

現場で役立つシステム設計の原則 ~変更を楽で安全にするオブジェクト指向の実践技法

作者: 増田亨
出版社/メーカー: 技術評論社
発売日: 2017/07/05
メディア: 単行本（ソフトカバー）
この商品を含むブログ (1件) を見る

テーブル設計とNULL

※読書会での議論ではなく私の意見です

著者は基本的にNOT NULL全部付ける派のようです。

NULLを避けるために、Optionalな値のカラムは全てテーブルから切り出して外部キー制約を持たせて参照すべきと書かれています。

個人的な意見ではNULLは使ってもいいと思いますが、基本的には著者と同じくNOT NULLにすべきだと思うが、厳密にNULL禁止のルールを運用して

大量のサロゲートキー,外部キー,値の3カラムだけのテーブル
EAV

が発生するよりはNULLがあったほうがましな気はする。

例えば会員情報が入力できるようなシステムがあったとして、

誕生日
居住地
メールアドレス
電話番号

のそれぞれが任意入力だったとして、以下のような感じにそれぞれ1個ずつデータが別れたテーブルが発生するのは微妙な気がする

ユーザー誕生日テーブル:(id,user_id,誕生日)
ユーザー居住地テーブル:(id,user_id,住所情報)
メールアドレス:(id,user_id,mail_address)
電話番号:(id,user_id,tel)

正規化

※これも読書会での議論ではなく私の意見です

データモデリングの技法として正規化があります。正規化はとても大切な考え方です。しかし、正しく理解し実践するのはなかなか大変です。でも安心してください。正規化の理論をうまく説明できなくても、自然に正規化されたテーブル設計になるかんたんな方法があります。その第一歩が、NOT NULL制約を使うことです。カラムはすべてNOT NULL制約にします。そして、もしNULL値がどうしても必要なカラムを見つけたら、別のテーブルに分けることを検討します。この方法を徹底するだけで、テーブルの正規化が進みます。

第６章「NOT NULL制約が導くテーブル設計」より抜粋

この主張は強引に感じました。正規化の理論をうまく説明できない人が「かんたんな方法」を使ってテーブルを作るよりも、周りの詳しい人に任せた方がいいと思います。

流石に新人が作ったものはレビューすると思いますが、前職ではレビューが存在しない現場の方が多かったのでどうしても心配してしまいます。

データ整合性(外部キー制約)と正規化は別
- 混ぜて考えるべきではない
- 整合成を保つ工夫としてストアドプロシージャー、トリガーも紹介して欲しい

デザイン

概ね、画面デザインについて書かれている章は好評でした。紹介されている本を読みましょう、という話になった。

ノンデザイナーズ・デザインブック [第4版]

作者: Robin Williams,小原司,米谷テツヤ,吉川典秀
出版社/メーカー: マイナビ出版
発売日: 2016/06/30
メディア: 単行本（ソフトカバー）
この商品を含むブログ (3件) を見る

会の途中に話題に出しましたが、DDD特化型デザイナーとかいるんでしょうかね。少なくともこの勉強会に参加されている方にはいませんでした。*1

キューなど

AWSのSQSキューは順序生保証が無くて、ベストエフォートになっている
- ポーリングしかできない(通知ができない)

OR Mapper

著者はアンチhibernateでmybatis派なのか?
- SQLを自分でかける人はmybatis好きな傾向がある
ORMapperだけでやると仕様を満たせない可能性がある。
- 画面や帳票が元になっていて、機能のことを考えていないテーブル設計とか

ドメイン モデリングの難易度が高い分野

通貨
- 小数点以下の扱い(丸め)の桁数などは通貨ごとに違っている(各国の法律?で規定されている)
時刻

国際化はとにかくDDD以前に難しそうという印象です。

SQLのUPDATE文は禁止すべき

アプリケーションが発行するUPDATE文はバグの温床なので、避けましょうという趣旨のことが書かれている。個人的に思うのはUPDATE文よりUPSERT*2が不要な気がします。複雑なUPSERT文を書くくらいなら、DELETE INSERTの方がいいと思う

ショッピングカートの中身情報はコトか

そもそもECサイトのショッピングカートの中身は永続化するのか?
- クッキーやキャッシュでは？カートの中身は永続化しないのではないか?
- 別のデバイスで同じアカウントでカートの中身をみると一致しているので永続化する必要がある。
モノかコトか？

感想

若干批判的な書き方になっていますが、読書会全体では納得できる箇所が多い、という方が多かったです。

次回は「CHAPTER8アプリケーション間の連携」から

*1:多分いませんでした。いたらごめんなさい

*2:なければINSERT、あればUPDATEという処理

2018-10-23

平成30年度秋期の情報安全支援士を受けてきました

資格セキュリティ日記

会場は成蹊大学。安倍首相の母校です。

f:id:yuyubu:20181023163450j:image:w400 — 吉祥寺駅から徒歩17分くらい?

情報処理試験の会場としては珍しくゴミ箱が解放されており、また会場に掛け時計もありました

f:id:yuyubu:20181023163510j:image:w400 — 試験会場のゴミ箱は使用禁止的な張り紙で蓋されてることが多いです

午前

miraiやblock chainやVRなど、旬の技術が出題されていたのが印象深かったです。

miraiについてdev.toに英語で書いてみました

dev.to

午後

バッファオーバーフロー

C言語とバッファオーバーフロー脆弱性について書かれた問題が出ました。

バッファオーバーフロー脆弱性を防ぐ技術に関する問題です。

DEP
SSP(Stack Smashing Protection)
ASLR(Address Space Layout Randomaization)
PIE(Position Independent Executable)
Automatic Fortification

ちなみに暗記問題ではありません。事前にこれらの技術を知らなくても基本ができている人は回答できるチャンスがあったと思います。 Hacking:美しき策略を参考にバッファオーバーフローを検証しているブログエントリはよくみますが、対策まではまとめられている記事はそう多くないので、バッファオーバーフローを防ぐ技術としてこの問題で触れられている概念を検証してみようと思います

Hacking: 美しき策謀第2版 ―脆弱性攻撃の理論と実際

作者: Jon Erickson,村上雅章
出版社/メーカー: オライリージャパン
発売日: 2011/10/22
メディア: 単行本（ソフトカバー）
購入: 9人クリック: 163回
この商品を含むブログ (19件) を見る

午後2

インシデント対応の問題が出ました。

シナリオとしては挨拶の例文を探していた社員が文章ファイルに偽装したマルウェアをダウンロードし、遠隔操作されてしまい情報流出が発生した、というものです。

被害状況のレポートの穴埋めや、対応できていない点などを答える質問が出題されました。

被害状況の調査報告書?の作成は結構自信がありましたが、時間が足りず書ききれない部分があったので合格しているか不安です。ただインシデント対応チームの仕事としてこういうことが出来るなら結構面白そうだな、と思いました。その手の仕事をする人と雑談したことがありますが、マスコミ向けの謝罪文とかも作ったりするそうです

感想

あまり準備がきちんとできていない状態で挑んでしまいましたが、日頃からある程度勉強していることもあってか、どの問題にもそこそこ対応できていたと思います。よく言われていますが、情報処理安全支援士が高度区分の中では一番簡単だと思います。また出題される固有代名詞であまり詳しくないものは調べてみるとブログのネタになりそうなものが多いので、技術ブログを書いてる人にとってはいいネタになると思います。

参考

問題文です。このエントリで引用している図は全てこの問題文からです IPA 独立行政法人情報処理推進機構：問題冊子・配点割合・解答例・採点講評（2018、平成30年）

2018-10-16

ネットワークの物理層に関する5つの興味深いエピソード

ネットワーク物理層

コンピュータネットワークの第２章は物理層についての章でした。読み終えたので感想でも書こうと思います。この章は難解なので自分が楽しめたのは精々物理層に纏わる様々な歴史上のエピソードのみでした。いくつか紹介してみようと思います。

エピソード1:警察無線がキャデラックのABSの誤動作の原因になった
エピソード2:建物間で照射し合うレーザー光線を利用した通信システムが実現化されていた
エピソード3:静止衛星の基礎原理は技術的に実現が難しかった時代にSF作家が考案した。
エピソード4:低軌道衛星のバブルは携帯電話の普及によって弾けた
エピソード5:通信インフラに使われている銅がAT&Tの資産価値の80%を占めていた時代があった
2章(物理層)全体の感想

コンピュータネットワーク第5版

作者: アンドリュー・S・タネンバウム,デイビッド・J・ウエザロール,水野忠則,相田仁,東野輝夫,太田賢,西垣正勝,渡辺尚
出版社/メーカー: 日経BP社
発売日: 2013/09/12
メディア: 単行本
この商品を含むブログ (4件) を見る

エピソード1:警察無線がキャデラックのABSの誤動作の原因になった

1970年代にGeneralMotorsはすべての新しいキャデラックにコンピュータ制御のアンチロック・ブレーキを装備することにした。 (中略) ある晴れた日に，オハイオ州のハイウェイ警察官が，本署を呼び出すために，新しい自動車無線機を使い始めると，隣にいたキャデラックが突然，暴れ馬のようになりだした。 (中略) キャデラックはときどき凶暴になる。ただしオハイオ州の主なハイウェイ上で，しかもハイウェイ・パトロールが見ているときに限ってである。 (中略) キャデラックの配線がオハイオ州ハイウェイ・パトロールの新しい無線システムが使っている周波数にとって格好のアンテナとなることを発見した。

この本以外のソースが見つからなかったが、本書によると、特定の周波数を使う警察無線がABS回路に影響を与えていたらしい。

少し粘ってネットを検索してみると、車好きのコミュニティっぽいサイトで学生が本書のこの内容を取り上げたスレッドを発見した(が特にこの件に関して結論は出ていない)。周りの人間は懐疑的だが、私も本書のこのストーリに驚かされた。

www.pakwheels.com

日本でも赤外線リモコンが干渉を起こして火事の恐れがある、として電気ストーブの販売規制がかかったことは記憶に新しいと思う

www.nite.go.jp

本書のこのエピソードの驚くべき点は赤外線リモコンのように同じ種類の媒体同士(無線 & 無線)の干渉事故ではなく、有線(ABS) & 無線(警察無線)の干渉である点だと思う。

エピソード2:建物間で照射し合うレーザー光線を利用した通信システムが実現化されていた

筆者の一人（タネンバウム）はかつて欧州の近代的なホテルで，退屈なセッションの間，参加者が電子メールを読むことができるように，会議の主催者たちが端末をいっぱいに設置した部屋を用意した会議に参加したことがある。地元のPTTは3日間だけのために多数の電話回線を設置するのを望まなかったため，主催者は屋根にレーザーを置いて数km先の彼らの大学のコンピュータ科学の建物を狙った。

「2.3.5 光伝送」より抜粋

この話には悲しいオチがあって、昼間の太陽に暖められた対流によってレーザーの軌道が変わって、昼間だけネットが繋がらないという結果に終わったそうだ。

f:id:yuyubu:20181016202341p:plain — レーザー通信で発生した障害

しかしそこまでして会議中にメール読みたいのかよwwwと思ったけど、レーザー光線やLEDを使った2転換通信を行う発送はそこまでぶっ飛んだものでもなく、それ用の道具は普通に売ってるようだ。

www.airlinx.com

また電子工作でレーザー光線を使った通信を電子工作で実現したブログエントリがあった。

Homemade 10 Mbit/s Laser / optical Ethernet transceiver – Linux, Games, Programming and some random science stuff

技術ある人すごい

エピソード3:静止衛星の基礎原理は技術的に実現が難しかった時代にSF作家が考案した。

1945年に，サイエンス・フィクション作家ArthurC.Clarkeは高度3万5800kmの円軌道の衛星は空で動かないように見え，追跡する必要がないことを計算した（Clarke，1945）。彼は，さらにこれらの（人工）静止衛星（geostationary satellites）を使った通信システムの全容を，軌道，太陽電池パネル，無線周波数，打ち上げ手順を含めて記述した。残念ながら彼は，電力を要し，壊れやすい真空管増幅器を軌道に乗せることは非現実的であると結論付け，いくつかのサイエンス・フィクションは書いたものの，それ以上このアイデアを推進しなかった。　トランジスタの発明はすべてを変え，最初の通信衛星であるテルスター（Telstar）が1962年7月に打ち上げられた。

「2.4.1静止衛星」より抜粋

SF作家の想像力と先見性
フィクションをファクトに変えてしまうトランジスタ技術の力

などなど、この辺は読んでてロマンが溢れる節でしたね。

常識っちゃ常識ですが人工衛星に限らずトランジスタは真空管に取って代わってコンピュータの進歩を大きく飛躍させていますね。

エピソード4:低軌道衛星のバブルは携帯電話の普及によって弾けた

1990年にMotorolaはFCCに対して77個の低軌道衛星を打ち上げるイリジウム（Iridium）・プロジェクト（原子番号77の元素はイリジウム）の許可を申請して新天地を開拓した。後になって計画は66個の衛星を用いるように変更され，したがってジスプロシウム（原子番号66）と改名されるべきであったが，病名のように聞こえたのであろう。 7年間，協力者や資金調達をつぎはぎした結果，1998年11月に通信サービスが開始された。しかし不幸なことに1990年以降，携帯電話ネットワークが目覚ましく発達したため，大きくて重い衛星電話に対する商業需要はほとんどなかった。その結果，イリジウムは利益を上げることができず，1999年8月に破産へと追い込まれ，歴史上最も劇的な大失敗企業の一つとなっている。

「2.4.3　低軌道衛星」より抜粋

約200万分の1の価値に暴落したようです。

いる。衛星その他の資産（50億ドルの価値）は，その後，地球大気圏外ガレージセールのようにして投資家に2千5百万ドルで買われた。

衛星電話は携帯電話ほどではありませんが、結構お安く運用することができます。

www.kddi.com

これはインフラ構築が難しい場所(離島、船上、災害地)などで有用という大きなメリットがあります。

エピソード5:通信インフラに使われている銅がAT&Tの資産価値の80%を占めていた時代があった

ある時点では，AT＆Tの資産価値の80％はローカル・ループの銅であった。その時点ではAT＆Tは事実上，世界最大の銅鉱山であった。幸いなことにこの事実は投機筋にはあまり良く知られていなかった。もし知られていたら，ある企業侵略者がAT＆Tを買収して米国のすべての電話サービスを打ち切り，電線を外して銅の精錬業者に売却して投資を回収したかもしれない。

「2.6.1　電話システムの構造」より抜粋

ある時点でAT&Tを買収してインフラの銅を全て売ればお釣りが帰ってきそうな記述ですが、特にソースがないので本当の話なのかは不明。

WEB上での議論を引用すると、

The point is to put the value of that copper (and the cost of replacing it in the event that it is damaged) into perspective.

Highly relevant quote: *At one time, 80% of AT&T's capital value was the copper... | Hacker News

とあるので、インフラを再構築するための費用として計上するなら...という意味なのかもしれない。

2章(物理層)全体の感想

この章は私のようなソフトウェアエンジニア向けの章というより、インフラエンジニアやネットワークハードウェアを研究開発する人が身につける基礎的な知識、という印象を持ちました。*1

技術パートはアナログ - デジタル変換的な話やフーリエ変換と信号処理、物理層の媒体となる素材(ガラス、銅) や電波(長波,短波)や光線(可視光線、赤外線)等の特性などについての解説が延々と続きました。

本章に掲載されている計算などは一応、情報系の学部なのでなんとなく耳にしている概念はありましたが、多くは初見のものであり、理解できないものが多かったです。

自作ネットワークプロトコルの作成などを考えている人がいるならこの辺は理解しておく必要がありそうです。

*1:このタイプのエンジニアもいるので、単なるソフトウェアエンジニアというべき文脈でエンジニアと記述する最近の風潮はあまり好きではありません。

2018-10-15

Goの時間フォーマットは他の言語とかなり違っている

golang

多くのプログラミング言語には時間を表示、保存するときに文字型に変換するためのフォーマットが用意されています

例えばJavaではこんな感じでyやMを使って日付フォーマットを指定します。大方他の言語でもこのような方式になっていると思います

 SimpleDateFormat format = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss.SSS");
 Date now = new Date(System.currentTimeMillis());
        
String nowStr = format.format(now);
System.out.println(nowStr);
//出力:2018-10-15 13:07:24.872

Goだとどうでしょうか。こんな感じに指定します。

now := time.Now()
nowStr := now.Format("2006-01-02 15:04:05.000")
//出力結果:2018-10-15 22:14:57.1516

あれ？なんで時刻の値を与えているんだ？と最初戸惑いましたが、Goでは2006年1月2日の15時4分という時間をサンプルとして与えてフォーマットとしています。

意味	Java	Golang
月	M	1
日	d	2
時間	H	3
分	m	3
秒	s	5
年	y	06(2006)

なおこの時刻は何か特別な日付ではなく、作者が自然と考えるフォーマットで書いたときに1,2,3...と並ぶように作ったようです。

これはアメリカ式の時刻の順番なのだ。"1月2日午後3時4分5秒2006年"（つまり「自然な順番」で1, 2, 3, 4, 5, 6）を指しているのである。

qiita.com

2018-10-14

Goならわかるシステムプログラミングを読み終えました

golang

13章までは一人で読みました。14章以降は横浜Go読書会に参加して読みました。

Goならわかるシステムプログラミング

作者: 渋川よしき
出版社/メーカー: Lambda Note
発売日: 2017/10/19
メディア: テキスト
この商品を含むブログを見る

どんな本だったか?

Go言語の要素

io.Writeやio.Readなどのinterface
chanelで同期をとる仕組み
go routineで並列に処理する仕組み

などを使ってコンピュータやOS,ネットワークの仕組みに迫るという本です。大体以下の要素を学びます

OSのシステムコール
ネットワーク全般
ファイルシステム
プロセス、スレッド
シグナル
並列処理
メモリ管理
時間・時刻の扱い
コンテナ、仮想化技術
OSのセキュリティ(付録)

どんな人向けか?

この本はGolang × システムプログラミングな本であることは確かだけど、どちらかの理解が浅い人が片方を頼りに理解を補うような本ではないと思う。文章とか可愛い図が多かったりする点から初心者テイストを感じするが、読後は中級者向けな印象を受けた。入門書ではないかなと。 Golangとシステム双方をある程度理解した人がその接点を探るような読み方が、ベストなのではと思う。

感想

私にとってGolangに関して初めて読んだ本となりました。ネットワークの話題などはいくつかブログに検証する記事をあげました。

yuyubu.hatenablog.com

またこの本に影響されてTour of Goをやってみた。

yuyubu.hatenablog.com

OSについては今年の前半に割と頑張って勉強したから分かる箇所が多かったものの、並列処理などはわからない点が多かった。

yuyubu.hatenablog.com

私自身マルチスレッドなプログラミングはあまりやったことがないので、他の言語と比較することはできないはgoはかなりカジュアルに並列処理(go routine)ができる点が特徴だと思うので、並列・並行制御に関するベストプラクティスを紹介するような本が相性がいいんじゃないかなと思います(横浜Go読書会の次回の課題本)