Rubyのお勉強

Javaばっかりやってきていたので、動的言語が気になり、
Rubyになんとなく目が止まったのでRails使ってWEBサイトちょちょいと
作れるようになりたかったのでお勉強中。

「初めてのRuby」写経し終わり、「パーフェクトRuby」の4章まで進んだところで、
Rails Tutorialの日本語版が出たとのことでそっちに専念してます。

動的言語ってことでIDEの補完機能に頼ってばっかりもいられなくなったので、
タイピング能力高める+エディタの乗り換えのため、

HHKBと「実践Vim」を購入。

実践Vimには編集土台となる文章が公開されているので、
gitのリポジトリ作って編集しやすいようにしといた。

以上

今更ながらTDDBC Tokyo 2013

メモがあったので乗っけとく

TDDBC TOKYO
twada和田拓人
gihyo.jp
動作する綺麗なコード…
動くー綺麗か？

②つの道がある。
１．汚い・動かない→※②汚い・動く→綺麗・動く
２．汚い・動かない→※①綺麗・動かない→綺麗・動く

※①綺麗さには限界がないので、期限に間に合わなくなる。
　完璧主義沼地。
　ソフトウェア開発手法はまだまだ未熟。
　→動かして初めて分かることのほうが多い。

※②堕落沼に落ちる。
　コードを綺麗にすることを怠ってはいけない。

２．のほうがTDD。

TDDとは？
　目標を考える（TODOリスト。設計リストを作成。)
　作業を選択する。
　RED,GREEN,REFACTORのサイクルを回す。
　　→つまり２．のサイクルを繰り返す。
　　　何をしてるのかを常に意識することがアジャイルでは大事！
　矢印があるということは目的がひとつということ。
　
　GREEN…取りあえず動くコードを書く。【汚くていい】。
　Refactoring…小さいうちに片付ける。
　　リーダブルコード、リファクタリングの有名なやつ
　　2冊本がおすすめ。

大事なこと１．
　大きい問題をそのままテストするのではなく、
　小さい問題に分けて、それを組み合わせて
　大きい問題を解くようにする。
大事なこと２．
　サイクルを素早く、回数を行う。
大事なこと３．
　自分が最初のユーザである
　(自分が作るものをまず初めに自分が使う。)
　　→テストコードで使う。
大事なこと４．
　【不安なこと】をテストする。
　　→不安でないことはテストしない。
　　　getter,setterにはいらんでしょ？

TDDのメリット
　ソフトウェア工学的なメリッドもあるが、最大の理由は
　【心理的なもの】【健康】
　　→即座にフィードバックが得られる
　　→書いたコードに自信をもつため
　　→これから書くコードに自信をもつため

　健康なら毎日REDBULL＋終電ダッシュはしなくていい。

TDD採用(MS,IBMの例)
　管理者見積もりによる増加コード実装時間
　　15%~35%
　テストコードはプロダクトコードの30%〜90%

　コーディング行・時間は増えるが、
　デバッグの時間が減るので全体の時間は減る。
　　デバッグにかかる時間はブレが大きいが、
　　そのブレを抑える働きがある。

TDD応用
　テストのないコードがたくさんある…
　　レガシーコード改善ガイド本
　すでにデータの入ったデータベースがある…
　　データベースリファクタリング本
　SlowTests…
　　メモリに対するテストより、DB、ネットワークに対する
　　テストのほうが時間がかかる。
　　→フィードバックにかかる時間が増えてしまう。
　　xUnitTestPatterns本…英語
　　　ネットのwikiをまとめたもの。
　テストをどこまで行えばよいか・何をテストすればよいか…
　　ソフトウェアテスト技法ドリル本
　実際の複雑なテストをどう行うか？
　　実践テスト駆動開発

TDDはスキル！
　才能ではなく習得可能！
　量は質に変化する！
　写経！！

**********************
実践テスト駆動開発の著者の一人
スティーブフリーマン(Steve Freeman)

　新しい機能を追加するのではなく
　既存の機能をリファクタリングすだけなら
　リファクタリング用のテストコードを書いて、
　リファクタリングを行う？

　●テストダブルを行う理由は？
　オブジェクト間のメッセージが飛びかっていて、
　(オブジェクトが頂点でメッセージが辺のようなグラフ)
　　その中のやり取りが上手くフィットしているか
　　確認するってのが１０年前に言われて、
　　今もそれが目的だと思っている。

　　テストを細かくするため。
　　たくさんエラーが出た時にどれが問題かを判断するため。

　●不可能なテストをどのように対応するか？
　　　→レガシーコード改善ガイド本見て。
　　依存関係を切っていく。
　　大きな塊でやっていく。
　　
　小さく取り出して安全な形で変えていく(リファクタリング？)
　そのうち状況が変わったり、
　解決につながるアイディアが思い浮かぶ。

和田問写経

Githubリポジトリ
TDD伝道師の和田さんが出された問題が話題になったのでやってみた。
というか、黒魔法リフレクトを唱えるのもめんどくさくて、
解説見てから良さそうなやつを実践した。

解説で問題を解くパターンがたくさん紹介されているので、
それぞれメリット・デメリットがわかりやすくてとてもタメになります。

私が今回実践したのはSelf Shunt。
わかりやすく実践しやすい上に強力。

脆いテストにならないように注意して多用しようと思う。

〜追記〜
Junit4でテストクラスで継承を行った場合に下記例外が発生した。

java.lang.Exception: Test class should hava exactly one public zero-argument constructor

どうもテストフレームワーク側で引数なしのコンストラクタを使用しているため、
引数ありのコンストラクタのみしかない場合に例外になるようだ。

プロダクトコードに引数ありのコンストラクタしかない場合はSelf Shuntは使用不可なのか？

2013年に読んだ本(技術系)

• Java・スタイル

Javaの基本がわかりやすく解説されていると思う。読むだけで「ふむふむなるほど」と納得するような書き方になっている。 基本構文よりもう少し上の内容について学びたい人向け。



どちらも難しい＋古いのでほとんど読んでいない…
でもどっちかって言うとCODE COMPLETEの方が古いコードは出てこないので、概念的に活かしやすい内容になっている。


東京に就職してから初めて参加した勉強会で扱ってた書籍。社会人2年目になってやっと…。
Mac Book Airを所持してやっと勉強会への参加資格が得られた時だったので。
内容としては簡単でわかりやすい。半日もあればひと通り読める(勉強会前日夕方に買って読んだ)。
コードを綺麗に書くための入門としてはとっつきやすいです。
コメントを書く代わりに関数名や変数名で意味を表示できるようにすることや、 ある程度パターンとしてこういう名前が使われているってことを学びました。
勉強会の資料の一つ(2013/07) →資料
勉強会では@terahide27さんの黄色い髪の毛が気になって仕方がなかった…。


これまたあまり読んでない。 でも今なら読める気がする。


これは大学時代にひと通り目は通して、こういうものがあることは知っていた。 今では「たしかこれのパターンあったなー」って時に辞書として使うようにしている。


大学時代には手を伸ばさなかったマルチスレッド編。 そもそもマルチスレッドを殆ど書いたことがなかったので避けて通っていたが、 趣味で使うことがあって書いてみたけどどうにも動かなくて、この本見たらばっちりパターンがあったとかそういう感じ。ひと通り写経は済ませてある。1回だけだけど。やる人って本当に何回も写経してるんすかね？
この本の内容の内容を理解している人でないと怖くてマルチスレッド部分は任せられないですね。 結構この分野の書籍はあんまりないので古いですけど今でも必読かと思う。
RubyとかScala使うなら別だけどね。


本屋でパッと「リファクタリング」の文字が目に入って買ってみた本。
この本は私の中でのプログラムに対する間違ったイメージ「凄い機械的で机に向かい続けて作り上げるもの」を「もっと創造的で、人間の感性を活かして概念レベルで構築していくもの」に変えてくれたもの。
設計に困って行き詰まったら机に向かっているより散歩に行くと簡単に解決したりする場合があることや、いいアイディアなんかは酒飲んでる時が一番出てくる、といった効率よく開発を進めるテクニックが色々書かれていた。
ちなみにこの本にはコードのリファクタリングは全く出てきませんｗ

• TDD・CI

Jenkinsで出来るひと通りの機能が載っているので、 本書でツールのイメージができたら後は導入してどんどんJob作ってみるのが大事なのかなと思う。 「Jenkinsさんって何でもやっておいてくれて最高!!!」って言葉をよく聞くけど、自分は結構ハマることが多くて生意気な執事だなーと思っています…ｗ


JUnitを使う上では絶対に読んでおきたい。某名古屋怖いの人なんかは100回写経してるとか？ ひと通り学べる系なので「モックの部分詳しく」とかなった場合は他で調べる必要は出てくる。


まぁ意識高い系のエンジニアさんはすべて毎日使ってるんでしょうね。


ちょっと固い感じ。 デシジョンテーブルとか昔大学でやったな～とかあるけど、 6割以上のテスト技法は初めて聞いたもので現場でも見たことがない。 きちんと理解すれば生かせそうなんだけど理解度ががが…。


レガシーコード(テストのないコード)を改善していく場合に使えるテクニックが満載。 おそらく日本の先進的な企業以外で働いている人はほとんどがレガシーコード相手に仕事をしているはず。 これから作る場合はレガシーコードを書かないようにすればよいが(多分これも殆どの企業でできないが)、 今あるコードにテストを追加し、保守しやすくしていく上でどのようにアプローチしていけばよいのか、 コードレベルで書かれている。 レガシーコードに挑む全ての戦士にお薦めしたい。


これは思い出深い一冊。
2013年7月TDDBC Tokyoでの特別ゲストSteveFreemanさんが書かれた本です。 それをじゃんけん大会で獲得し、サイン+手渡しで頂きました。ありがとうございます。
GUI+マルチスレッド+非同期通信と言ったTDDを行う人にとっては泣きたくなるアプリに対しての アプローチ方法が書かれている。
ストーリーに沿って開発を進めアプリが完成していく様子を体験できる。
この開発部分の内容は少々難しくなっており、本書に載っているソースだけではコンパイルが通らないようになっている。 あとがき部分にGithubのリポジトリが記されているので、そこを参考にしていくと良い。
第Ⅲ部からの実践部分も大変ためになるが、第Ⅰ・Ⅱ部で彼らがどういった考えで テストを書き、設計を行いTDD・プロジェクトを回しているかといった部分が 書かれているところがとても良いと感じた。 TDDはアジャイル開発の原動力になると感じているが、なぜそのように出来るかといった点の理解がこの部分で深った。

• プロジェクト

取り敢えずアジャイル開発に関わる人なら読んでおいてもらわないと困る。 アジャイル開発はただ工程が変わるだけじゃなくて、現場レベルでは色々なプラクティスを使って、 関係者間のコミュニケーションを図っていたりするわけで。 それがあってこそのアジャイルなはずなのに、言葉しか知らない人はそこを全くわかっていないと思う。 アジャイル開発で用いられているプラクティスはアジャイル開発に限らず、 WFでも他の分野でも使えるものが多いので、 プロジェクトの運用方法を改善したいと思っている方には参考になる本だと思う。


@papandaさんが翻訳をされた本。 リーン開発はトヨタ生産方式を参考にした非ウォーターフォール開発手法の一つで、 そのなかのカンバンをベースにプロジェクトを回した経験が記されている。 リーン開発の書籍は読んだことがないのでリーンにおけるカンバンの重要度がわからないのですが、 カンバン以外の周りの部分が見えづらいのが気になったところ。 終始カンバン・カンバン・カンバンであり、カンバンを極めるなら良いのかも？ 2013年11月に行われたDevLove甲子園で@papandaさんが熱心に宣伝されてましたW

WFをずっとやってきた会社でアジャイルを取り入れてプロジェクトを回してみた成果報告が書かれている。 各プラクティスの実践方法に関しては他の書籍で学べばよいが、 それを現場で広げていくために「上と掛け合うための材料」をどのように集めるかといった知識が書かれている点が優れていると思う。 アジャイル開発の効果を示すために定量的データの取得方法を模索されている方にお薦めしたい。

• Git

Gitって直感的でなくって難しいのですが、これはストーリー立てて簡単に書かれているので、 入門として最適だと思います。 このストーリーを完璧にこなせるようになってから「他にもこんなことできないの？」って部分を 学んで行けばよいかと。


こっちも入門ですが難しいです。上の知識を蓄えてから掘り下げたい部分を本書でのスタンス。 写経しつつGitでコミット練習しながら使ってます。

• その他

統計が流行った時期があったので。ビックデータとか言われている時代に利用方法がわかってないとなにも価値を見いだせないので。 統計がわかっている人は実践の使い方が学べるのかな。 あんまりわかっている人間ではないので勉強し直さないと役に立たないですね。



大学時代に読んだ本の一つでかなり影響は受けている。 一生懸命働くことがいいことではなく、きちんと稼ぐように働かないと一生お金持ちになんてなれないよって話。 小中高大で勉強してきたけどお金の儲け方については一切教えてくれないわけで、 この本なんかがその方法の突破口になっている。

半年の間で64,000円か…。
収入の1割には届かないけど昔に比べたら大分投資してますね。

MySQLでの識別子は大文字小文字を区別する事がある

公式参考
DBでのクエリは一般的に大文字小文字区別しない認識だったが…。
MySQLの場合テーブル名をOS上のディレクトリ構造で表現した時に
区別される場合はそれがクエリにも反映される。

通りでWindowsからCentOSに移行した後で下記エラーが出るわけだ。
「Table 'XXXX.YYYYYYY' doesn't exist」

Linuxで思ったように動かない時

・実行しているのは誰？実行しようとしているファイルは誰の？権限は？
・ファイアウォールに穴は開けた？
・パスは通っている？
・今どこにいる？

iptablesの場所

CentOS6.4の場合

/etc/sysconfig/iptables


再起動は
/etc/rc.d/init.d/iptables restart