『達人に学ぶDB設計 徹底指南書 初級者で終わりたくないあなたへ』を読んだ

はじめに

『達人に学ぶDB設計 徹底指南書 初級者で終わりたくないあなたへ』という本を読みました。ちょっと古めの本ですが、よりよいデータベース設計・テーブル設計というものを感覚だけでなく、言葉で説明できるようになりたいと思い、手に取りました。

達人に学ぶDB設計 徹底指南書 初級者で終わりたくないあなたへ

私が買った時は、紙の本しか無いのですが、今ではKindle版もあるようですね。

結構稀有な存在？

世間では、SQLのテクニックやプログラミングのテクニックばかりが注目され、それに特化した本も多数出ているのですが、本書はその前段であるテーブル設計について焦点を当てて書かれています。

SQLやプログラミングに対する知識は当然必要なのですが、正しいテーブル設計を行うとトリッキーなSQLやプログラムを書く必要性はなくなります。トリッキーな技術をうまく使いこなせた時は嬉しいものですが、その直後から高いメンテナンスコストと終わりなきバグとの戦いを続けることになりそうです。

そのため、本書で設計について学ぶことは大変意味があるように思います。

くどい

ただ、ちょっと最初の正規化のところはくどいぐらいに記載されています。正規化の重要性やそれを学ぶことの必要性についてこれでもかとばかりに書かれていますが、ページを取り過ぎな感がありました。

本書の第7章から9章までに書かれているテーブル設計の話がもっと読みたかったのですが、前半のところでページ数が取られている感じがしました。

今後

この本は足がかりで、次は『SQLアンチパターン』が良い感じかなと思います。

SQLアンチパターン

また、同じ指向としては2月に発売予定の『理論から学ぶデータベース実践入門 ~リレーショナルモデルによる効率的なSQL』が該当しそうです。

理論から学ぶデータベース実践入門 ~リレーショナルモデルによる効率的なSQL (WEB+DB PRESS plus)

まずは『普段何気なく使っているテーブルの列の定義ってどう考えて設計しているの？』と疑問を感じた時に手に取るといい本だと思います。

神奈川Ruby会議にるびま班＋登壇者として参加してきた（追記あり） #kana01

はじめに

神奈川Ruby会議にるびま班＋登壇者として参加してきました。るびま業はまだまだ続くのですが、ひと通り区切りがついたのでメモを記しておきます。

運営業

はじめに

元々は、大江戸Ruby会議に出た時に「るびま班として参加してみない？」と声をかけられたのが最初でした。みなとRuby会議02をやろうかなぁと思っていた頃合いなので二つ返事でOKし、そこから運営業に色々と関わることにしました。

コミュニケーション

運営者が全員バラバラの所属だったので、意思の疎通を取るのは結構難しいところがあります。このツール選びにひと月以上費やしたものもあり、意外と揉めました。

結局、Facebookメッセンジャーをよく使ったのですが、Facebookメッセンジャーは日常のコミュニケーションを取るために使うものであって、打合せなどのコミュニケーションツールとしてはちょっと違うかなぁと思います。通知の頻度がちょっと違うかなぁと感じたのた原因でしょうか。

たぶん、決定的なツールは存在しないので、あるツールをいい感じに使うっていうのがベターなアイディアなのかもしれません。最初は「いまどきメールはないよね」っていう声も有ったのですが、コミュニケーションを取るためには有効な手段なので、とりあえず、始めてみればよかったのかなぁと思ったりもします。

後はオフラインコミュニケーション。オフラインコミュニケーションは10回も満たなかったのですが、顔を合わせて話をするというのは文字だけのコミュニケーションだけでは補えきれないものがたくさんあります。移動というコストがもったいなく感じる時もありますが、全員が揃わなくてもやったほうが良かったかなぁと思ったり。

ペアプロ

神奈川Ruby会議の技術的なエッセンスとしてペアプロを入れました。問題の難易度についてはいろいろとご意見があるかと思いますが、参加者が少なくとも隣の人と話すためのきっかけ作りとして、また、Rubyでなんらかの達成感を得てほしいためにペアプロを用意したので、若干難しめなものを作り、ペアと相談したり、TAからのアドバイスを貰うという形を狙っていました。

狙いがうまくハマったのか、開始早々に各ペアが活発な議論を交わし、コミュニケーションを取られていたのは感動的でした。

仲間たち

運営は一人ではできません。実行委員長の有賀さんだけではなく、会計の川口さん、会場の長住さんはじめNTT-ATのみなさん、るびま班の徳田さん、アドバイザーの高橋さん。カメラを向けたらみんないい顔してました。みんな、ありがとう。

発表業

さて、るびま業だけではなく「トークセッションで登壇してください」と言われました。幾度と無く断りましたが、どうしても外せない牌だからと言われ最後には腹をくくりました。

葛藤

自分はごくごく普通のSIerに勤めるSEだと思っています。技術的に光るものがあるわけでもなければ、なにか代表作となるGemやサービスが有るわけではない。そんな自分が登壇して、自分の生存戦略なんぞ語っても意味があるのかと散々悩みましたが、Yokohama.rbの運営業を何故しているのか、オンライン・オフラインの読書会をなぜ続けているのかを考えて話してみました。

Rubyに関する生存戦略

自分のRubyに関する生存戦略は単純で、「Rubyに投資する時間を増やしてそれを続けること」です。

Rubyは生産性の高い言語ですが、文法を知り、記述パターンを覚え、使いこなせるようでなければ仕事や武器としては使えません。自分にはその力を身につけるために、時間を費やす必要があると考え、そのためには強制的に勉強する場に自ら参加することをやり続けています。

偶然にも、高橋正義さんが同日の講演の中で話されていましたが、自分は「勉強会は受け身でいると何も技術は身につかない。モチベーションも翌営業日にはしぼんでしまう」考えていて、そのためには強制的に勉強をする時間を設けようと思ってました。

ただ、あくまでRubyに関する生存戦略なので、会社で生きること、世間で認められるための生存戦略はまた別です。Rubyに関する生存戦略を含んでいますが、世間で認められるための生存戦略はまた更にあるので、話す機械があればちょっとまとめて話してみたいですね。

質疑応答に対するちょっと長い回答

最後に「なぜ、今の会社に？」と言う質問をいただき、それに対して「お金」と答えました。

お金が全てではありませんが、お金がないと生きてはいけません。やりがいを強調されてもそこに対するベクトルが合わなければ意味ありませんし、なぜ自分を評価してくれているのかについて説明しないところには、単なる人集めとしか映りません（SIer出身者だからっていうのは、説明不足ですよね）。

今のところ、自分がやっていることと、やりたいことのベクトルが多少あっていて、生活できる程度のお金を頂けており、安定性もある程度は見込めているので、これを崩すためには...あとは省略。

まとめ

多くの方々に参加して頂き、大変ありがとうございました。次回があればですが、よりよい会議を開きたいと考えています。

Working with TCP Socketsを読み終わった

はじめに

Working with TCP Socketsという本を読み終わりました。私は、The Pragmatic Bookshelfで購入しましたが、販売ルートは作者自身のサイトのほかAmazon Kindle版もあるようです。

Working With TCP Sockets (English Edition)

いま見てみると、Kindle版、安いですね。この記事を書いている時点（2014年12月29日）で933円。

みんなで読むとサボれない

この本ですが、横浜技術書朗読会という場で輪読する形として読み進めました。横浜技術書朗読会は、@1syoさんが始めた少人数制の技術書朗読会で、現在は毎週土曜日の午前中にタネマキさんで読み進めています。

一人で読んでいる場合、英語の本はちょっと壁に当たるとすぐ諦めてしまいがちですが、こういう輪読の形で読み進めるとサボれないという強制力が発生することから、読み進めることが出来ました。

また、疑問点や英語の表現でわからないところも助け合えるので、こういう進め方はできればずっと続けたいです。

本の内容

他のマシンとデータをやりとりするために、TCP Socketの各種APIをRubyで紹介しています。また、簡単なFTPサーバを作ることでネットワークプログラミングのアーキテクチャを学ぶことが出来ます。

全体としては、容易な英語で書かれており、英単語を調べながら読むとサクサク読み進めることができるかと思います。

本の展開の仕方もSocketとは何か？から徐々に高度な内容に話を展開しており、分かりやすい内容かと思います。後半はFTPサーバを作っていきますが、それぞれのコードの意味をちゃんと解説しています。

ただ、Chapter 23ぐらいからはぐっと難しくなります。特に使われている英語が急に難しくなるという印象を受けました。ココらへんからはなかなか読み飛ばしすることが難しいかなぁと思います。

「Ruby Association Certified Ruby Programmer Silver version 2.1」を受けてきた

Ruby技術者認定試験の新版である「Ruby Association Certified Ruby Programmer Silver version 2.1」を受験して、合格しました。

このエントリーでは、その受験体験を簡単に記してみます。

きっかけ

古いバージョンのRuby（1.8が前提のもの）はSilver/Goldともに合格していたのですが、バージョンアップしたということと、Ruby技術者認定試験再受験無料キャンペーンってものをちょうどやっていて、万が一に不合格でも金銭的なダメージが少ないということで、とりあえず、受験してみました。

ちなみに、Ruby技術者認定試験再受験無料キャンペーンは2015年1月20日申請分までが上限らしいので、気になっている人はおやめに。

受験勉強

さすがに一回落ちてもいいという気楽さはあるとはいえ、流石に落ちてしまうのはどうかと思ったので、勉強しました。

勉強において、version 2.1に対応したいわゆる試験対策本は無いです。とりあえず、1.8のもので勉強することにしました。

Ruby公式資格教科書 Ruby技術者認定試験 Silver/Gold対応 (EXPERT EXPASS)

ネットで検索すると、version 2.1での変更点は（Silverに関する限り）あんまりないみたいなので、Rubyアソシエーションビジネスセミナー試験案内講演資料（注：リンク先PDF）に軽く目を通しておくだけにしました。

資格 - Ruby技術者認定試験Silver version 2.1 必勝合格法 - Qiita

あとは、るりまをみながら、Array、Hash、Stringなどの各種メソッドをirbでタイプして動作確認をしてみました。名前が違っても処理が同じもの（mapとcollect、findとdetectなど）、!がついてなくても破壊的なものを覚えるようにしました。

試験日の前日に本の模試を解くと全問正解だったので、まぁ、なんとかなるだろうと思い試験に備えました。

試験

試験はプロメトリック。本人確認書類が二種類いるのがポイントで、少々面倒くさいです。また、遅刻厳禁なので、注意しましょう（身近に経験者が居て、本当に受けさせてもらえませんでした）。

受付を済ませて、荷物をロッカーに入れて、5分もしないうちに「じゃ、簡単に説明したあと案内します」と言われすぐ試験会場に。トイレ行く暇もないので、受付前にトイレは済ませたほうがよいでしょう。

試験は全てパソコンで。ラジオボタンやチェックボックスにチェックを入れる方式。タイプする問題はないので気楽なものです。

時間は余程のことがない限り余ると思います。私の場合、20分でひと通り問題を解き終え、さらに10分で全問の復習を終えて試験終了のボタンを押しました。

結果

100点満点中90点で合格でした。1問2点という計算かと思うので、5問間違えたという計算になります。本当は100点取りたかったんですが、いくつか記憶があやふやなものがあったので、ま、これぐらいかなという感じです。

75点が合格ラインなので、12問は間違えることが出来ます。普段Rubyを触っていて、るりまで復習をすれば合格できるような気がします。

Opal

Ruby5 Episode #514を聞いていたら、RubyからJavaScriptに変換するOpalというGemが紹介されてました。

CoffeeScriptのRuby版といった位置づけでしょうか。面白い試み。

Try Opal in your browserのページで、ブラウザ上でOpalを動かすこともできます。

いずれRailsに載る日が来るかも？

【Ruby】コーディング規約に違反したものを自動的に正しいものにする

RuboCop

Rubyのコードがコーディング規約にあっているかどうかチェックしてくれるツールとして有名なRuboCop。チェックだけなの？簡単なものなら修正してくれたらいいのに...と思っていたところ、そんなオプションが有ることを最近知りました。

Automatic Corrections

詳細は、RuboCopのWikiページを読んで欲しいのですが、-aオプションを付けるだけ。自動修正してくれるものは先ほどのWikiページの下の方にかかれています。結構たくさんありますね。

ただ、これは...

ただ、-aオプションでは全部の自動修正が行われます。例えば、文字列を"（二重引用符）から'（引用符）に変換だけしたいときどうすればいいんだろう...とツイートしたら、ありがたいことに教えていただきました。

@miyohide rubocop -a --only Style/StringLiterals で文字列リテラルの auto correct だけ実行できますよー

— Yuji Nakayama (@nkym37) 2014, 12月 3

やり方は-aのあとに、--onlyとつけて、変換する名前をつけるだけ。

今日も一つ勉強になりました。

【個人的メモ】公にする情報の取り扱い方

これはなにか

@bash0C7さんのブログエントリ「仕事で公にしていいことは公開された場所で議論をしていきたいが」を読んで色々と思ったことを書いたものです。全然まとまっていないので、個人的なメモ。

前提

そもそも、「公にしていいこと」とは何か。例えば所属員の給与とか査定情報とかは「公にしてはいけないこと」の代表かなと思う。「公にしていいこと」とは、「誰が現在、どのようなタスクを持っているか」とか、「こんな仕事の話があるんだけど...」とか。

人それぞれ

世の中、いろんな人がいるわけで「俺は今の仕事のことしか知りたくない」といった自分オンリーな人もいれば、「周りの人がどのようなタスクをこなしているのか」といった極力情報を公にすることを求める人もいます。

個人的には後者依りな考え方をする人だし、後者のほうがメリットが大きいと考えているんだけど、自分が興味ないことについて永遠と話聞かされても辛いよなとは思います。

メリットとデメリット

情報を公にするメリットで思い当たるのは、

• 「え？俺、その情報知らない」と言ったような人に対する情報の伝え漏れが防げる
• 「Aさんにはこのことを伝えるけど、Bさんには伝えない」と言った情報統制の必要がない
• 情報を持っている人が権威者になってしまうことを防ぐ

の点だと思っています。

権威者ができると、どうしてもその人に向けての仕事をするようになるので、無用な権威者は作りたくないなという思いがあります。

一方でデメリットは、

• 興味が無い人にとっては情報がノイズとして捉え、邪魔に思えてしまう

な点が思いつきました。

ノイズの許容量については人それぞれなので、「スルー力が足りないだけ」って言うのは集団で働く会社って組織の中ではあまり解になっていないです。もうちょっと良い方向の解決案がある気がします。

その解決方法は？

ノイズに対する許容量はトレーニングによって増やせると思っているので、一気に情報を流すんじゃなくて、徐々に流していくって形を取っています。今のところ、定期的に時間をとってみんなの話を聞くって場を開催。

本当は、もっとカジュアルにやりたんだけど、「うるさい」っていう人もいたり、脱線しまくって本論を忘れたりするし。