2013年11月30日土曜日

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

  • Java・スタイル

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



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


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


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


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


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


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

  • TDD・CI

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


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割には届かないけど昔に比べたら大分投資してますね。

2013年11月17日日曜日

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

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

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

2013年11月16日土曜日

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

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

iptablesの場所

CentOS6.4の場合

/etc/sysconfig/iptables


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

httpclient 4.2.1でのマルチスレッドによるアクセス

最新の4.3.1だとやり方が違います。

4.2.1の場合。
クローズする前に他のアクセスをする場合は必須。

公式参考ファイル


オンラインドキュメント各種

Apache HttpComponents
http://hc.apache.org/httpcomponents-client-4.2.x/index.html

CalendarからDateに変換して文字列整形

参考

gitのコミットメッセージで#を使いたい

gitでコミットの際にviなどから先頭に#をつけて記述を行うとコメントとして認識されるわけだが、
Issueと結びつけるために先頭で#を使いたい場合、どうすればコメンと扱いにされなくなるのか…?

git commit -m "#1 メッセージ"
とやれば回避できるが…。

複数行のコメントをちゃんと書けということでしょうかね。

Linux間のファイル送信

scpコマンドを使う。
CUIの最小構成でも入っているのでどこでも使える。
ファイルの送信中は状況が表示される。

scp 送信ファイル 送信先アカウント@送信先IP:送信先ファイル名

ディレクトリを送るときは-r指定で。