Yabu.log

ITなどの雑記

IEEEなどの標準化周りの話

雑記

雑談でIEEEの話になった時、 ネットワークの規格のことでは？と言われ ぼんやりと、標準化をやっている団体、ということは知っていたが、 詳しく知っているわけではないので特に説明することができなかった。

IEEEとは?

The Institute of Electrical and Electronics Engineers, Incの略。 電気工学・電子工学技術の学会。 標準化がメインの活動というわけではなく、普通の学会同様、 論文の査読や賞の付与も行っている。(むしろこっちがメイン？)

IEEE802シリーズ:ネットワークの規格

※ちなみに、3GPやLTE等、日本の携帯回線でよく見る企画は3GPPが標準化を行っている。

IEEE754:浮動小数点計算の標準規格

浮動小数点の計算誤差などの話の時によく見る。 現在ほとんどのコンピュータはこの方式を採用している。

IEEE829:テストドキュメントの標準化

テストの本を読んでいるときに目にしました。

他よく使う技術の標準化等

身近な技術の標準化を調べたが、IEEEがかかわっているものは意外と少ない。 (インフラ屋とかならもっと身近な存在なのかな？)

ISOでの仕様策定は非常に時間がかかるらしい。 IETF:RFCで緩やかに決まっていく。(ネット時代らしい標準化の在り方？)

*1:WiFiの登場は、WEPのセキリティ代替手段(WAP)を普及させる必要があったからではないだろうか？WiFiの必須要件としてWAP2が必要とされていることからそう思う。

技術書の電子書籍の色々

電子書籍 技術書 雑記

よく利用する電子書籍の購入サービスを列挙してみました。

オライリー

O'Reilly Japan Ebook Store

こちらでDRMフリーのepubを購入する事ができます。 決済にpaypalを利用することができるので、クレカ番号など入れなくていいので安心です。 私はSQLアンチパターンを買いました。 古いものはあまり電子書籍化されておらず、PDFのみのものも結構多いのが玉に瑕。

オーム社(2018.2.18サービス終了予定)

すべての書籍 | オーム社 eBook Store

情報工学の教科書などでお世話になったオーム社も電子書籍を売っています。 こちらも決済にpaypal利用可能 私は達人プログラマーを買いました。 マスタリングTCP/IPもここで書いたかったけど、間違えてkindleで買っちゃった。

技術評論社

gihyo.jp

WEB+DB PRESSを出版していることで有名な技評(なぜか変換できない)の電子書籍販売サイトです。 こちらも決済にpaypal利用可能 Github入門やWEBを支える技術などを買いました。

達人出版会

tatsu-zine.com

オーム社他、多数の出版社の委託販売？をやっている ラインナップがかなり強力。技術書以外にも資格の対策本もepubで買える。絶対に一度はチェックすべし。

総評

紙が好きな方も多いと思いますが、ぶ厚い書籍を何十冊もタブレットに入れて持ち歩けるのはそれだけでメリットだと思います。

結論

みんなもpaypalアカウント作ろう。

2017年上半期(1〜6月)読んだ技術書

技術書 雑記

まずは13冊読んだ内、特によかったものを3つ紹介。

達人に学ぶ SQL徹底指南書

達人に学ぶ SQL徹底指南書 (CodeZine BOOKS)

達人に学ぶ SQL徹底指南書 (CodeZine BOOKS)

DBスペシャリスト受けるにあたって、ほしいものリストに入っているDB関連の本を片っ端から読もう、 と思い手に取った1冊です。

この本は全般的に「SQL/DBのコンセプトは集合論や述語理論につい強い影響を受けており、 そのような観点から、こういうふうなSQLを書くと効果的」という視点が一貫して語られています。

自分なりにそのような視点を少しでも吸収できたことは大きな財産です。

この本を読む前と読んだ後で、データベースを眺める目が変わったことをはっきりと感じました。 自分にとってエポックメイキングな出来事でした。

私の今年上半期のベストはこれです。 紙の本で買いましたが、読み直す際にkindle版も買おうと思います。

アカマイ　知られざるインターネットの巨人

アカマイ　知られざるインターネットの巨人 (角川ＥＰＵＢ選書)

アカマイ　知られざるインターネットの巨人 (角川ＥＰＵＢ選書)

アカマイは学生時代に遊びでパケットキャプチャをした際に初めて知りました。 何もしてない状態でGoogle等よく知られた会社と通信しているのはなんとなく納得ですが、アカマイという謎の会社と通信しているのを見つけ、 怖くなって調べたのが最初の出会いでした。

世界に流れるパケットの20%がアカマイを経由しているそうですが、 一般的にその社名はほとんど知られていません。*1

誰もが世話になっているが、だれもその存在を知らない。

その奇妙なギャップから、謎の秘密結社くらいの印象でしたが、 ただ、B to Cのビジネスをほとんど行っていないというだけであり、 働き出してからは、アカマイの名はいろんなところで見聞きするようになったので 今では身近な存在という印象です。本書はそのアカマイ社をメインテーマに書かれた唯一無二の本です。

一般書っぽい売り方をしていますが、インターネットの仕組みを理解していないとアカマイについて知ることは出来ない、ということらしく、インターネットの技術的詳細に加えて、ネットワーク事業の金の流れと力関係というビジネス寄りの話も充実しています。

別に読んだネットワークの入門書にはASの説明やTTLの説明は特にありませんでしたが、 本書ではこれらも解説されていました。多分技術書に分類されませんが、 技術的なトピックを理解しながら読み進める一般書籍という位置付けだとおもいます。 あまり一般向けではないと思いますが…*2

アカマイ社は会社の設立～現在までめまぐるしいネットワーク・業界・経済の変化に振り回されながら時代を駆け抜けてきた数奇な会社であるという感想を持ちました。

知識ゼロから学ぶソフトウェアテスト 【改訂版】

知識ゼロから学ぶソフトウェアテスト 【改訂版】

知識ゼロから学ぶソフトウェアテスト 【改訂版】

フロリダ工科大学でjames whittaker, Cem Kaner*3らの元でテストの専門教育を受け、 マイクロソフト、SAP等のテスト業務に従事した まさにテストに特化したキャリア*4を歩んだ方によるテストの本。

テストとかセキュリティの本って硬い、つまらない等の第一印象を持ってしまいがちですが、 本書は著者のユーモアとエッセンスが詰まった素晴らしい1冊でした。

一般的にテストって苦行だとかつまらない作業だとか、 とりあえず新人に雑用と一緒にやらせとけみたいな扱いを受けている気がします。 「三度の飯よりテスト好き」な人は見たことがありません。

私見ですが、多くの人が、テストがつまらないと感じる理由は 納品のためのテスト、いわばテストのためのテストを行ってしまい、 有意義のある作業をやっていないという感情を抱いてしまうからなのではないでしょうか？。

極端な例を出すとニュースになってしまうような、ずさんな試験結果の改ざん等の担当者は 悪いことをやっている、という罪悪感の前に「なんでこんなことやらないといけないの？」という 退屈感・虚無感に襲われると思います。

少なくともこの本を読んでからは、価値のあるテスト*5を目指し、作業の改善を心がけるように成ったので、テストは退屈な作業、とは思わなくなりました。

私にとってテスト分野の最初の1冊としてこの本に出会えたことは幸福です。

読んだ本一覧

DB/SQL

  • SQL 第2版 ゼロからはじめるデータベース操作(kindle)
  • 達人に学ぶ SQL徹底指南書(紙)
  • 達人に学ぶDB設計 徹底指南書 初級者で終わりたくないあなたへ(kindle)
  • SQL実践入門(紙)
  • SQLアンチパターン(epub)

ネットワーク

  • おうちで学べるネットワークのきほん(kindle)
  • アカマイ　知られざるインターネットの巨人(kindle)
  • マスタリングTCP/IP(kindle)

他

一覧で見ると全13冊中電子書籍が11冊 紙が2冊とかなりの割合を電子書籍で買っています。

ちなみにepubと書いているのはkindleではなく、各出版社のサイトでpay palなどで決済できる　 drmフリーなepubファイルのことです。

個人的に購入の優先度はepub > kindle > 紙ですね

*1:私の口頭アンケート調査結果による。

*2:というより普通の人はアカマイに興味を持たないと思う

*3:今読んでいる「ソフトウェアテスト293の鉄則」の著者がこの人だった。

*4:エンジニアとしてこういうキャリアパスもあるんですね

*5:ここでは価値のあるテストとは、より少ないコストでより多くのバグを発見できるものをいいます

テストのためだけのコード変更は許されるのか？

テスト レガシー

レガシーコード改善ガイドに以下のような一節がありました。

私はテストが簡単に書けるなら、変数をpublicにすることでカプセル化が壊れても通常は気にしません。

私はEffective Javaに強く影響を受けているのでメンバを書くときは極力公開性を最小にコーディングする。 しかし困るのはユニットテストのときで、privateなメンバのテストはリフレクションを使ってテストコードからアクセスしていた。

可変性*1・公開性*2を最小にする、というこだわりを持っているので上記の引用の記述には少し驚いた。

そもそもテストコード内でのアクセス出来ないメンバはどう対処するのが最適なのか、少し調べてみた。

https://qa.atmarkit.co.jp/q/2784

短くまとめると、プライベートなメソッドのテストを書く必要は 無い と考えています。ほとんどのプライベートメソッドはパブリックメソッド経由でテストできるからです。プライベートメソッドは実装の詳細であり、自動テストのターゲットとなる「外部から見た振る舞い」ではありません。

こちらの方*3の意見は非常に説得力がある。 確かにブラックボックステストとしてユニットテストを作成するなら、privateメソッドのテストは書く必要がない。

一方でこの方はレガシーにも触れている。

レガシーコード(テストコードの無いコード)に対する「仕様化テスト(Characterization Test)」を書いているような状況では、リフレクションは唯一の、かつ強力な手段になります。プライベートメソッドにテストを書くことのデメリットを理解しつつ、黒魔術の強力さを堪能しましょう。

機能追加の際に、理想的なテストを書いてしまうと、既存バグが発見され、そちらの対応に追われるかもしれない。 バグ修正よりも現在の変更作業を優先するために、一旦既存バグを含めた現在の挙動を保護するテストを作成する。*4

ほぼ全てのレガシーシステムでは、「システムがどのようにうごくべきか」よりも、「実際にどのように動いているか」のほうが重要です。*5

仕様化テストはレガシーコードに対処し始めた初期段階のプロセスといえるかもしれない。

調べた知見を自分なりにまとめると

まともにやっている新規開発*6ではprivateメソッドのテストなんて書く必要はないけど、 設計が破綻しているレガシーコードに絡んだsingleton*7などはテストの観点から見ると有害なので、公開性をどれくらい壊すか、というところのトレードオフを考えながらコード変更やリフレクションという黒魔術を使おう、ということになる。

調べながら・考えながら読んでいるので読むペースは遅いが、どんどん内容が面白くなってきた

参考:レガシーコード改善ガイド 第9章

*1:Effective Java項目１５：可変性を最小限にする

*2:Effective Java項目１３：クラスとメンバーへのアクセス可能性を最小限にする

*3:ユーザー名を見たらt_wadaさんだった…

*4:もちろんこれはゴールではない。既存バグの修正よりも、機能追加を優先したというだけであり、既存バグは別に対処しなければならない。

*5:レガシーコード改善ガイド13.1仕様化テスト

*6:新規開発のすべてがまとも、というわけではない

*7:文中ではsingletonのコンストラクタの公開性をprivate→protectedに変更している例が挙げられている

はてなブログを1ヶ月使ってみての感想

雑記

はてなブログを書き始めてから多分1ヶ月位たったので適当に使い心地でも書いてみる

いいところ

Markdownで書ける

これが一番重要。もうね、手打ちでタグ書いたり、セルの幅揃えたりするのに消耗したくないんだよ。

意外と簡単

なんかはてなのサービスってごちゃごちゃしてて難しそうな印象があったけど はてなブログはUIも洗練されてて使いやすい。

Qiitaと違ってブログは内容にあまり気を使わなくて良いのが楽。

注釈がめちゃくちゃ書きやすい！！！！

ブログ本文((注釈内容))

こんな感じでかなり手軽に注釈がかけちゃうんです。 この記法考えた人凄い。Markdownにも標準化団体みたいなのできたら 絶対これは入れて欲しい。*1

　わるいところ

はてなキーワードとかいうやつが邪魔

一応課金すれば消せるらしいけど、そもそもこれいるの？

*1:多分今って互換性のない方言がボコボコ生まれてるフェーズなんかな？

わけわからんコードにはとりあえず影響スケッチ。

レガシー

影響スケッチとは？

レガシーコード改善ガイドに掲載されている、影響を把握するための方法です。

影響はどのように伝搬するか

影響は

  1. 呼び出し側によって使われる戻り値
  2. パラメータとして渡されるオブジェクトの変更
  3. グローバルスコープのデータの変更

によって伝搬します。

影響スケッチの書き方

ただ影響の伝搬を線で結ぶだけです。変数だけでなく、メソッドも結びます。

例:直したメソッドがグローバル変数を書き換えていた→そのグローバル変数を参照している箇所には全て修正の影響が伝搬してしまっている(涙)*1*2

レガシーコード改善ガイドの例では変数もメソッドも同じように丸で囲っていてわかりにくかったので、メソッドは()をつけるなどの工夫が必要でしょう。*3

影響スケッチは何に役立つのか。

1.テスト箇所の把握

まだテストコードが十分に整備されていない時は、変更を入れたコード以外にどこまでテストコードを準備する必要があるのか、という把握のために使える。

2.リファクタリング

本書の中の例では、変数の取得方法をgetterメソッドに統一することで影響の重複を排除していた。*4

感想

なぜ影響スケッチが必要になるかというと、そもそも変数に必要以上に広いスコープや可変性を持たせているからであって、 きちんと構造を持っているコードなら影響スケッチはシンプルになるし、そもそも影響スケッチを書くまでもないかもしれない。

レガシーコード改善ガイドは自動テストが導入されていることを前提に話を進めているので、そういう現場で働いていないと役立たないかもしれない。 でも調査や分析のためのテクニック、精神論などはテストを自動化していなくても役に立つと思う。

今回紹介した影響スケッチもそんな役立つ技術の一つだと思う。

参考:レガシーコード改善ガイド第11章 変更する必要がありますが、どのメソッドをテストすればよいのでしょうか？

*1:図は書くのがめんどくさいのでなんとなくイメージしてください。。。

*2:スコープの広い変数に影響与えたあとにはきちんと調査してください

*3:別にこの本にケチを付けているわけじゃないよ。アメリカ人は変数は名詞、メソッドは動詞みたいなことをちゃんと徹底できるから別に俺が書いてる工夫なんてしなくて良いんだよ。ﾌﾞﾂﾌﾞﾂ…

*4:参考:11.6影響スケッチの単純化

Effective Java 3rd予約開始!

日本語版翻訳者の柴田さんのブログで知りました。

yshibata.blog.so-net.ne.jp

アマゾンの紹介を見る限り7~9も扱うらしい。*1 2ndはjava 6までの内容だったので少し古い感じがあった。

https://www.amazon.co.jp/Effective-Java-3rd-Joshua-Bloch/dp/0134685997

今から英語鍛えようかな

*1:なんでリリースしてない9が書けるんだろう？