マックでMac行ってきました
第何回か忘れてしまいましたが、id:aya_eiyaさんが久々に名古屋に来るとの事で、id:fumokmmさんと共に恒例のマックでMacへ参加してきました。
マックでMacとは「マックにMac Bookを持ち込んでいろいろやろうぜ！」という企画です。
家では集中できないという方、いっしょにマックでまったりしながらいろいろやりませんか？
行うことは自由！お仕事をするなりプログラミングの勉強をするなり開発するなり…参加条件は
・Mac Bookを持参する
・マックでお食事をするためのお金を持参する
これだけです！
いつもはマックで仕事の話したり開発の話したりプログラミングしたり読書したり絵を描いたり寝たりしてもうとっても自由なんですが、今日はaya_eiyaさんがHaskellを教えてくれました。
私はゆとりプログラマなので、Haskell自体全く知りませんでした。
いや、関数型言語というのは聞いていたのですが。
wikipedia:Haskell
今回はaya_eiyaさんの好きな（？）お題である迷路プログラムをHaskellで解説されていたので、こちらを元に進められました。
はてなブログに移行しました
ステップバイステップで解説して頂いたおかげでHaskellの片鱗を垣間見れた気がします。Wikipediaなどを覗いてみると、まだまだHaskellプログラマーには程遠いですが…。
しかし、Haskell、いいですね。
僕の勝手な印象は
真冬の朝、透き通った空気、しかしそれはピンと張りつめて緊張感のある、心地良い空気
そんな印象を抱きました。
なかなか仕事に使えるかどうかは難しそうですが、scalaやocamlなど他の関数型言語への理解の手助けになると思ってます。
名古屋アジャイル勉強会 分科会のMercurial入門に参加してきました。
名古屋アジャイル勉強会 分科会のMercurial入門に参加してきました。
名古屋アジャイル勉強会本会には一度しか参加したことがありませんでしたが、今回は入門編ということで友人を誘って気軽に参加してみました。
他にも初めて参加される方もおられました。今後は名古屋の勉強会に新規さんが増えて活性化するといいですね。
自己紹介
自己紹介では昨晩の晩御飯、今まで利用したバージョン管理システム、勉強会への意気込みを皆で話しました。
利用したバージョン管理システムではSubversionが多かったような印象を受けました。時点でVSS、CVSとかだったかな？
あと、昨晩の晩御飯を思い出せないと記憶力や脳的に色々とまずい気がしますので頑張りましょうね！
勉強会スタート
さて、勉強会の内容ですが、まずはバージョン管理システムについてお話がありました。
バージョン管理システムはファイルの履歴を管理するシステムのこと。
- いつ変更したのか
- 誰が変更したのか
- 何のために変更したのか
- 何を変更したのか
- どのように変更したのか
ファイルをバージョン管理システムで管理することにより、上記のポイントを押さえることができます。
これにより、過去の状態に戻したりメンバーが同じリソースを扱うことができるようになります。
また、何か問題が発生した場合などに原因を追うことが可能となり、開発者は安心して開発を進めることができます。*1
VCSの歴史
最初はローカル環境で。
- SCCS、RCS
- PVCS
どれもまったく聞いたことがありません。思わずTwitterで呟いたらきょんさんが反応してくれました。
流石はSCMBC主催者！今度参加します！
次に共有できるようにサーバー・クライアント方式へ進化。
- CVS、Subversion
- VSS、ClearCase、Perforce、TFS、RTC
有名なのはCSV、Subversion、VSSなどでしょうか。
VSSから更に高機能になったTFSは調べてみるとTFS単体でSCM(CIだけじゃない？)となっているようです。バージョン管理に加え自動ビルド、プロジェクト管理、レポート管理などを備えている模様。VisialStudioならTFSはかなり有効に利用できそうですね。
そして流行りの？分散リビジョン管理方式へ
GNU archは聞いたことがありませんでしたが、歴史は古いみたいです。
今回勉強するのは分散型リポジトリであるMercurialとなります。
サーバー・クライアント方式では集中リポジトリとして一つのリポジトリを各端末が参照するという形でしたが、分散型では各端末がリポジトリを持ちます。
ただ、分散型でも集中リポジトリを立て、各端末でのリポジトリは作業用リポジトリとして使用することが可能です。こちらのがより一般的ではないでしょうか。
今回学ぶ形式も後者となります。
ちなみに私も一人でGitを利用していますが、同様に集中リポジトリを立てて、ローカルでは作業用リポジトリとして利用しています。
Mercurialとは
Pythonで開発された分散型リビジョン管理方式です。ただ、一部パフォーマンスを重視しているロジックに関してはCで実装されているとのこと。
Mercury(水銀)から、コマンドは元素記号のhgが利用されている。ハードゲイを連想してはいけない。
プラットフォームによる依存もなく、WindowsでもLinuxでもMacでも楽々インストールが可能。
(私はMacだったのでMacPortsで導入しました)
コマンドがSubversionに似ていることから、今まで開発環境はWindowsでVCMはSubversionを利用していた人には移行しやすい。
プラグインによる機能拡張も可能。
GitはWindows環境にインストールするには少し敷居が高いですし、色々できるが故にコマンドが複雑という欠点もあります。
特にSIerなどスキルセットの幅が大きいプロジェクトに導入するにはMercurialは良さそうです。
ハンズオン
まずはMercurialのインストールから。
半数ぐらいは既にインストール済だったようです。そういう私もインストール済でした。
(私の場合はMacPortsとXCodeのバージョンが古すぎてインストールできずにエラー吐きまくり。当日インストールしていたら間違いなく間に合いませんでした。試しに入れてみて良かった…。ちなみに、MacPortsよりHomebrewのが素敵だと教えて頂いたので導入したいと思います)
ハンズオンで行われたコマンドの説明とかは最初頑張って書いてましたが、記事の量が多くなってきた（＝めんどい）ので省略します。
全員がコマンドの内容を理解する為に大変丁寧に進められました。
しかし、やはり時間が足りずに後半は巻き巻きで進行となりました。
コマンドを打つだけで結果を得て終わり、ではなく、このコマンドは何を意味しているのか、まで理解が伝われれば良いなぁと。
今回はそこまでの時間が足りなかったようにお見受けしました。
ハンズオン自体、もう少し時間があると良さそうですね。3時間だと短いかなー。5時間ぐらいは欲しい…。
借りてる会場の兼ね合いもあるので、已む無しですね。
KPT
最後にKPT(Keep Problem Try)が行われました。
初めて行う方もペタペタ貼られていて、素敵だなぁと思いました。
自分は最初、あまり思い浮かばなかったんですよね。聞いているようで頭に入っていない証拠ですね！
また、BitBucketの導入もできなかったので、こちらは用意して頂いた資料を元に導入したいと思います。
資料
勉強会で使用された資料です。参考にさせて頂きました。
Mercurial入門(前半)
Mercurial入門(後半)
Bitbucket入門
また、別のスライドですがMercurial導入時に参考にさせて頂きました。こちらも一通り眺めると楽しいと思います。
http://sliwww.slideshare.net/kenjis/mercurialbitbucket
懇親会
懇親会は近くの四川料理屋で。
開店前に到着したので外で待っていたのですが、他のお客さんもぞくぞくと…。
かなりの人気店のようです。
で、2500円のコース料理と1500円の飲み放題を付けて90分お食事しました。
感想：激辛
辛いのはかなり得意ですが、そんな僕でも唇と舌と胃が焼ける程熱かったです。
翌日は僕のお尻が大変なことになりました。恐ろしい…。
お客さんは年配の方が多かったのですが、えーと、大丈夫なんでしょうか…。
でも美味しかったのでまた行きたいですね。次はラーメンと餃子を頼む！美味しそうだった！
次回の分科会も参加するぞ、ということで締め。
TestNGで日本語メソッド名のテストケースを実行する
現在のプロジェクトではユニットテストにTestNGを使用しています。
なぜJUnitでなくTestNGを選択したかはまたの機会に。
さて、eclipseにTestNGのプラグインをインストールするとコンテキストメニューからTestNGを実行することができます。
もちろん、テスト単位で実行できますし、メソッド単位で一つ一つ実行することもできます。
が、メソッド名に日本語を使用している場合は実行時にUTF-8じゃないよと怒られてテストができません。
org.testng.TestNGException: com.sun.org.apache.xerces.internal.impl.io.MalformedByteSequenceException: Invalid byte 1 of 1-byte UTF-8 sequence. at org.testng.TestNG.initializeSuitesAndJarFile(TestNG.java:334) at org.testng.remote.RemoteTestNG.run(RemoteTestNG.java:86) at org.testng.remote.RemoteTestNG.initAndRun(RemoteTestNG.java:199) at org.testng.remote.RemoteTestNG.main(RemoteTestNG.java:170)
あるケースだけ確認したいのに毎回毎回クラス単位やスイート単位で実行するのもアレなので、対応を行います。
対応内容は簡単。メソッドを選択して実行する際のエンコードが環境依存になっているので、eclipse自体のencodeをUTF-8にするだけです。
eclipse.iniに下記を追加します。
-Dfile.encoding=utf-8
eclipseを起動したままであれば再起動すると日本語名のテストケースを実行できます。
とはいえ、この設定は別にTestNGには関係無く、eclipse自体のデフォルトエンコードを指定してあげるので、
例えばeclipseでファイルを開くと勝手にShift-JISになってしまって設定が面倒とかにも対応出来ます。
もちろん、JUnitでも同様だと思われます。今度試してみます。
日々のチケット駆動運用
日々の一連の流れを備忘録として残しておきます。
やり方に誤りがある、もしくはもっと良い方法があればご指摘ください。
１．作業が発生したらいきなり作業に着手するのではなく、Redmineで該当するプロジェクトのチケットを切ります。
チケットには件名、作業内容、バージョン、担当者、開始日、期日など必要な情報を記入します。
２．チケットが作成されるとチケット番号が割り振られます。そのチケット番号でGitのブランチを切ります。
>> git checkout -b [ブランチ名（チケット番号）]
このコマンドはブランチを作成しつつ[ブランチ名]ブランチへ移動します。
これで作業準備が整いました。
３．好きなように作業しコミットします。
コミットメッセージでチケットを連携したい場合は
・参照するチケット: refs, references, IssueID
・修正されたチケット: fixes, closes
上記キーワード+チケット番号をコミットメッセージに埋め込むことでRedmineでのチケット連携がより充実します。
４．作業が完了した（コミットする必要が無くなった）らmasterブランチへ移動します
>> git checkout master
５．作業を行ったブランチをmasterブランチへマージします。
>> git merge [ブランチ名]
６．マージが完了したらリモートリポジトリへpushします。
>> git push origin master
７．チケットへ更新情報があれば更新します。
Gitで正常にpush出来て入れば対象のチケットの関連するリビジョンにコミット情報が出力されています。
８．トピックブランチを削除します
>> git branch -d [ブランチ名]
これで１つの作業が終了です。
作業ごとにチケットを切るので面倒なところは出てきます。
ちょっと修正したい、とか他の人からもらったドキュメントで更新したい、とか。
ただ、チケットで管理しておくと作業が細分化・視覚化され、更にバージョン管理と連携しているので関連するファイルが即座に分かります。
まだまだ不慣れなところはありますが、勉強しながら覚えていきたいと思います。
Gitはじめました。
以前に他の方から教えてもらって、なんとなく使用していたGit。
CUI覚えるの面倒だよね、というより、色々出来ることもあってコマンドを忘れてしまったり、うまく利用出来ていませんでした。
現在のプロジェクトではビルド用PCでSubversionを導入していたのですが、繋ぐのにLANを繋ぎ直さなければいけないので非常に億劫でした。
おかげで他のメンバーもコミット頻度が落ち、纏めてコミットされてしまうので管理がし辛い。
今は私一人になってしまったので、折角なので無理やり導入してみました。
同じく無理やり導入したRedmineと連携してみましたが、チケット連携がかなり使い勝手がいい。
まだ全然使いこなせていませんが、実務で使用することで少しでも覚えていけたらな、と。
自分が使っている時にこんなことがしたいな、と調べる際に備忘録として日記に書いていこうと思います。
できればどんなシチュエーションの時にどんな方法で解決するのかも一言添えて。
直前のコミットに対してやり直す（再度コミット）する
『コミットしたけど実は他のファイルもコミットしたかったんです。』
『コミットしたけどgit addしていない状態でコミットしていてgit status打ったらびっくり漏れてた』
そんな時は再度コミットしてログを汚すのではなく、直前のコミットを取り消して纏めてコミットしよう。
>> git commit --amend
エディタが立ち上がると直前のコミットログの状態で起動するので、ログ内容を変更したければ変更、
そのまま黙って同様のログに漏れを追加したい場合はそのままエディタを終了しよう。
git logを確認すると新規にコミットログが追加されることなく綺麗に纏まっています。
