初めて勉強会に参加してから今まで学んだことを振り返る

11月前半の有給消化期間に暇だったことと、そういえば3月に大学院を修了したのに忙しくて何も書いてなかったなと気がついたので、初めて勉強会に参加してから何を学んだか振り返ってみます。

まぁ、メンズTDDというイベントの懇親会で下記エントリに関連する話を聴いたことも多少は影響しているとは思います。

僕がソフトウェア開発を勉強し始めて3年間でやったこと - うさぎ組

0. 勉強会初参加以前

初めて勉強会に参加した2010年7月より以前は、自主的にはやっていたものの、あくまで学内の中という狭い空間で知った単語、書籍を頼りに学んでました。
まぁ、GoFのデザインパターンやリファクタリング、TDDとは何ぞやということを本腰据えて唸りながら学んだのは、大学4年ソフトウェア工学専門の指導教員の下についてからのことです。

実装パターン

オブジェクト指向における再利用のためのデザインパターン

増補改訂版Java言語で学ぶデザインパターン入門

直近3か月はこいつらをゆるゆると読んでいました（結局読み終わったのは勉強会後でしたが…）。

1年目. TDDBC名古屋参加以降

人生で「学ばなければこの先生きのこれない」と恐怖したのは、この時が2度目でした*1。知識も、経験も、圧倒的に上な方々が、40人以上その場に居たわけですよ。これくらい持っていないとこの世界ではやっていけないのか、と思ったわけです。

それと同時に、あのイベント中にこんなことも感じました。


「あのOCamlやScalaとかいう言語でペアプロしている人々はなんて楽しそうな、素敵な笑顔でコードを書くのだろう！」*2
「もしや、あれら関数型言語というものには楽しく開発できる何かがあるのでは…？」


というわけで、これ以降はソフトウェア開発をメインに、関数プログラミングも少しずつ学んでいくことになります。

書籍に関してはTDDBC名古屋の主催者だった@bleisさんと、講師であった@t_wadaさんのつぶやきを主な情報源にしていました。
プラスしてbleisさんや@sinsoku_listyさん、@tosikawaさんのつぶやきを頼りにrebase、reset特化でGitを学んだり、指導教員に書籍を借りたりとかですね。

あとは、JaSSTに参加した影響もあって少しずつテスト(自動化寄りだったけど)について学んだり、途中からは講義の関係もありJavaを扱うことが多かったため、TDDBC福岡で存在を知ったGroovyも併用していました。

ソフトウェアテスト技法ドリル―テスト設計の考え方と実際

リファクタリング―プログラムの体質改善テクニック (Object Technology Series)

レガシーコード改善ガイド (Object Oriented SELECTION)

実践 F# 関数型プログラミング入門

オブジェクト指向プログラマが次に読む本　?Scalaで学ぶ関数脳入門

プログラミングGROOVY

プログラミングHaskell

ザ・ゴール 2 ― 思考プロセス

中でも、きのこ本はお気に入りの一冊です。

プログラマが知るべき97のこと

2年目. SCMBC開催以降

この少し前あたりから、勉強会に行く傍ら雑多に読んでた記憶があります。
あと、@kyon_mmさんや@oota_kenさん、@goyokiさん、@irofさんらと会話することでテストについてもっと真面目に考えたりした感じですね。

Clean Code アジャイルソフトウェア達人の技

ソフトウェアテスト教科書 JSTQB Foundation 第3版

ソフトウェア・テスト PRESS 総集編

ストラウストラップのプログラミング入門

ソフトウェア品質知識体系ガイド―SQuBOK Guide

Scalaスケーラブルプログラミング第2版

パターン、Wiki、XP ~時を超えた創造の原則 (WEB+DB PRESS plusシリーズ)

Making Software ―エビデンスが変えるソフトウェア開発

プログラミングの魔導書vol.2

あとはF#熱が復活したり、Kinect SDKで遊んだりしていました。

イベントの開催などは、今を思えばよくあんな無茶できたよなーというレベルでTDDBCを開催したりしていましたね…。

3年目. 学生生活最後

修士学生よそれでいいのか、と言わんばかりに研究以外のこともやっていた気がします。
あと、積読や挫折した書籍をきちんと読もうとしたのもこの時。

会社が決まってからは、こっちも必要だよなーと思いながら読んだりとか。

インターフェイス指向設計 ―アジャイル手法によるオブジェクト指向設計の実践

アジャイルサムライ−達人開発者への道−

アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~

オブジェクト指向入門 第2版 原則・コンセプト (IT Architect’Archive クラシックモダン・コンピューティング)

エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)

エンタープライズ アプリケーションアーキテクチャパターン (Object Oriented Selection)

アジャイルなゲーム開発 スクラムによる柔軟なプロジェクト管理

ソフトウェアテスト293の鉄則

白黒バイザーを読もうと薦められたり。

実践的プログラムテスト入門

ソフトウェアテスト技法

Functional Functionalしたり。

すごいHaskellたのしく学ぼう!

プログラミングErlang

Expert F# 3.0

あとは、HaskellやScala(z)のモジュールやクラスをF#に移植できないかひたすら考えたり、新卒研修課題をErlang+F#で提出して迷惑かけたりしていました。


あ、勉強会での10分以上の発表を行うようになったのもこの時からですね。そのきっかけをくださったTDDBC岡山運営メンバーの方々には、今でもとても感謝しています。


もう一つ、書籍のレビューにも初めて参加させていただきました。

JUnit実践入門 ~体系的に学ぶユニットテストの技法 (WEB+DB PRESS plus)

@shuji_w6eさん、貴重な機会をくださりありがとうございました。とても勉強になりました。

4月から今

気がついたらF# MVPになっていたり、もみあげと呼ばれるようになっていました。
そして、面白いメンバーとの遭遇を経て今の状況にあります。

新卒で入社した会社を8か月弱で辞めてしまったのは、他者からすれば色々と言いたいこともあるかもしれません。
が、今は後悔していませんし、だいぶ後になって後悔するかもしれませんが改めて納得することでしょう。私はそういうヤツなので。

まぁ、忙しかったりバタバタしてしまったりで、正直前よりもインプットはできていなかった…のは反省ですね。

Purely Functional Data Structures

SQLアンチパターン

Team Geek ―Googleのギークたちはいかにしてチームを作るのか

C++ ポケットリファレンス

なぜ学ぶか

まだまだ学ぶべきことは多いですし、やってみるべきだよねと思うことは多々あります。
では、なぜ学んだり試してみたりするのでしょうね？


振り返ってみると、私はやはり「誰かと技術的な話をしたい/聞きたい」に尽きるようです。仕事のためというのは確かにありますが、それ以外の部分が大きい。

時に笑顔で、時に真剣に技術的な話ができる、それは素敵なことだなと思うわけです。
そういうわけで、私は学び続けるのでしょう。

というわけで、いつも楽しい話をしてくださる皆様、私の話を聴いていてくれる皆様、ありがとうございます。これからも頑張るます！

さいごに

読みかけや頂き物を晒すことで年末追い込みメソッドを発動しておきます。

関数プログラミング入門 ―Haskellで学ぶ原理と技法―

組織パターン (Object Oriented SELECTION)

ITエンジニアのゼロから始める英語勉強法

.NETのクラスライブラリ設計 (Microsoft.net Development Series)

C#プログラマのための.NETアプリケーション最適化技法 (Programmer's SELECTION)

おまけ

しかし息抜きも重要なので、気が乗らなければ休みましょう。
そして積まれていくゲームとラノベは数知れず…

*1:一度目は大学1年後期だった

*2:今思うと絶対あれはmzpさん達だった！

愛知県のどこかで働きます

明日からPCがネットに接続できない日々になるので、今のうちに次の行き先を書いておきます。

次の住処は愛知県のどこかです。名古屋國ではありません。なので、まだ「なごやこわい！」と言ってもよいはずっ。

おしごとは？

Twitter上ではバレバレだったみたいですが、名古屋でソフトウェア開発に携わる予定です。

新卒でよくこのタイミングで転職(したね | できたね)

あとでかく(そんなに書くことがないともいう…)

まともな引越し日程を組みなさい

契約やらなんやらから引越しまでを2週間で行うべきではなかったですね、反省しています（2日で荷造りは死ぬかと思った）。

まとめ

これからも一人のプログラマとして、F# loverとして、あるいはぺんぎんとして、もしくはもみあげ(概念)として生きるので、遭遇した際にはよろしくお願いします。

おまけ

もみあげ(物理)をなくしたい。

wish list

最終出社日でした

明日から有給消化期間に入ります。

関係者の皆様

お世話になりました。
8か月という短い期間ではありましたが、皆様と一緒に仕事が行えたこと、感謝いたします。
周りの方々に恵まれたなぁ、と本当に感じます。

あと、もみあげ剃ります。

短いですが

2週間休んだら、次の道を走ることになるので準備しないと、ですね。

今後に関しては、いずれまた。

24時間耐久ハッカソン 大阪を"なぜか"開催しました #24hack

なかやん氏〜、24時間耐久ハッカソン、大阪会場つくってくだされ〜

2013-08-08 22:55:04 via TweetDeck

@mzp え、あ、はい？

2013-08-08 22:55:47 via web to @mzp

@pocketberserker よろしくお願いしますm(_ _)m

2013-08-08 22:56:04 via TweetDeck to @pocketberserker

というわけで、開催しました。

24時間耐久ハッカソン @ 大阪 - connpass
24時間耐久ハッカソン #24hack - Togetterまとめ

大阪会場は普通にハッカソンやニンジャ真実を研究をしていました。
なので、あたまおかしいイベントではなかったですね。

他地域主催者の記事

• 24時間耐久ハッカソンを企画/主催しました - 眠気と戦う日々
• 24時間耐久ハッカソン@名古屋を開催しました #24hack - みずぴー日記

かいつまんで当日の流れ説明

• pbsk氏、某所で目覚め帰宅
• pbsk氏、開始1時間前までお掃除
• 11時参加者到着、他会場のことは気にせずハッカソン開始
• 某人がニンジャ真実を研究しに来訪
• ピザ！ピザ！
• ハングアウトで中継開始
• 某人、なぜか参加する
• 某人を迎えに行った際にPCのロックをかけ忘れ、画像をいじられる（猛省しました）
• 艦これをバックミュージックにハッカソン
• 晩御飯のためお出かけ（お好み焼き）
  • Makefileとbashつよい
  • 人類は今のところ負け(make)ている
  • 言語機能黒歴史集とかほしいよね（だったかな？）
• ○○さん（特定1名）爆発しろ談義
• 大阪組、順次普通に寝る（大阪会場は寝ても良いことにした）
  • 寝るまでの間、ひたすらいちゃらぶと艦これの音声が届く
• 起きる
• ハッカソン続き
• ハッカソン終わり
• 大阪組、帰宅組とペチャ焼き組に分かれる
• 解散

やったこと

私は以下のようなことをやっていました。

• msgpack-fsの続きに取り掛かるも早々に飽きる
• 間違えてvmを破壊する
• vmの環境構築
• drone.ioの設定をいじる*1
• かつてWebSharperで書いたコードをFunScriptで再実装（終わっていない）
• かつてErlangで書いたコードを修正

KPT?

• K
  • なんだかんだハッカソンしてた
• P
  • 冷蔵庫がないと参加者がつらい
  • 少し狭かった？

まとめ

会場の問題があるため、今後"私が開催するかどうか"はわかりませんが、東京や名古屋の方々は次回開催に意欲的(?)だったので頼み込めば開催されるのではないですかね。

*1:http://d.hatena.ne.jp/pocketberserker/20130921/1379915763

drone.ioを使って継続的にビルド & デプロイを行う(ssh編)

継続的インテグレーションなサービスとして、最近では drone.io を耳にすることがあります。

Continuous Integration · drone.io

drone.io は現時点では github, bitbucket, google codeと連携できます。

Free 版では public プロジェクトしか使えませんが、有料プランを選べば private プロジェクトが使用可能になったりConcurrentに動かせるようになったりするようです。
(private リポジトリが無制限に使える unlimited プランが現時点で ($ 49.00 / month) と、割と安価な印象？)

drone.io ではいくつかの環境への deploy も行えるようになっています。
今回は、ssh 経由で deploy を試してみました。

プロジェクトのセットアップ

New Project からリポジトリの選択、言語の選択を順次行っていきます。
ここまではボタンをポチポチ押すだけなので簡単です。

最後に、ビルドコマンドを記述します。
編集前には選んだ言語にあわせたひな形が記述されています。
これを各プロジェクトにあわせて修正します。
環境変数が必要な場合は、後から "Build & Tests"の"Environment Variables"に記述します。

言語によってはバージョンの指定が可能です。

余談：Status Badge

"Status Badges"に記載されているリンクをドキュメントに記述することで、(コードホスティングサイト側が対応しているのであれば)Status Badgeを表示させることができます。
GitHub + Travis CIなリポジトリでよく見るアレですね。

PNG Format と Markdown が用意されています。
Markdownを利用している方はドキュメントにそのまま貼り付けるだけです。

私はrstを使っているので、

.. image:: https://drone.io/hoge/pocketberserker/fuga/status.png

と記述してホスティングサイト上で表示させています。

sshでデプロイ

下記ページを読めばだいたいやるべきことがわかります。

SSH Deployments · drone.io

• User ... デプロイ時に使用するユーザ名
• Host ... デプロイ先のホスト名(or IPアドレス)
• Remote Path ... プロジェクトのコピー先
• Remote Commands ... プロジェクトのコピー後に実行したいコマンド
• Branch(Option) ... どのブランチの時にデプロイを実行するか。何も記述しない場合はすべてのブランチを対象。コンマ区切りで複数指定。

ssh + rsync でプロジェクトのコピーを行うため、下記に注意する必要があります。

1. パスワードなしでsshログインするため、"Deployment Key"に記述されている文字列をデプロイ先の ~/.ssh/authorized_keys ファイルに記述する必要がある。
2. リポジトリディレクトリとRemote Pathディレクトリを rsync で同期させるため、リポジトリ側に存在しないファイルはおそらく消えます。

試した環境

私は以下の構成で試しました。

• リポジトリ ... GitHub においている個人プロジェクト
• 言語 ... Erlang (リポジトリ内にrebarを同梱)
• デプロイ先 ... Windows Aure上の仮想マシン(Ubuntu 13.04)

まとめ

ビルド用スクリプトとデプロイ用スクリプトを用意できれば、そんなに手間をかけずに自動デプロイできるようになりました。
環境変数を利用する場合はもう少し複雑なことをやらなければならないかもしれませんが、用途を絞れば色々と使い道があるのではと思いました。

TFServiceを使って F# プロジェクトのビルドを試した時のメモ

そういえば、TFServiceを触ったことがないなーということで、作業メモ。
とはいえ、基本的に以下の記事を参考にすればビルドとテストが行えるようになります。

• TFService 入門(1)：Team Foundation Server/Serviceについて
• Team Foundation Service で既存プロジェクトのビルドをする方法 #tfsug
• TFS2012 自動ビルドで NUnit テストを実行する #tfsug - kaji_3's blog
• Create and run unit tests
• Part 3: Unit testing with Traits and code coverage in Visual Studio 2012 using the TFS Build – and the new NuGet adapter approach - Microsoft Application Lifecycle Management - Site Home - MSDN Blogs

私の環境 + 今回使用したプロジェクトはこんな感じです。

• Windows 8
• Visual Studio 2012 Ultimate
• Gitでバージョン管理
• プロジェクトは→を使用 https://github.com/pocketberserker/FsMachines
  • つまりF#なプロジェクト
  • NUnit + FsCheck

Team Foundation Serverの資料であってもServiceのほうも似たような形で設定できるので、そんなに問題にならなかった気がします。
あと、C#とF#で設定方法に差は見られないようです。

細かい設定方法はまだ調査中なので、また今度。

詳しい手順

あとでかく

まとめ

TFSUGの方々が素敵すぎた。

"Async in C# and F#: Asynchronous gotchas in C#"を翻訳しました

4月末に C#の非同期の落とし穴 でとりあげられていた Async in C# and F#: Asynchronous gotchas in C# を読みながら「面白いなぁ」とつぶやいたところ、ハマの子連れ狼さんに翻訳を勧められたので、英文和訳の訓練も兼ねて翻訳しました。

Async in C# and F#: Asynchronous gotchas in C# (Japanese translation)

公開後も diff を確認しやすい Gist で公開しています。

謝辞

4月末の連休に翻訳を開始してから公開まで、2週間くらいでしょうか。
この速度で、かつこの訳質で公開できたのは、的確な助言をくださったハマの子連れ狼さん、翻訳について快諾くださった原文著者のTomas Petricekさんのおかげです。

ありがとうございました。

短いあとがき

あとがきを書いておきます。
翻訳者個人の言葉であって原文著者の言葉ではないことを理解した上で、下記を読んでください。

記事内でも記述されていますが、決して C# async を批判する記事ではありません。
あくまで"こういった部分に気をつけましょう"という話です。

訳に問題があるとすれば、それはすべて翻訳者である私の責任です。
訳について指摘事項などありましたら、Gist もしくは本ブログ記事のコメント欄に投稿していただければ幸いです。
Twitter のメンションでもかまいませんが、見逃す可能性があるのは否定できないので…。

それでは、引き続き Async な世界を楽しみましょう！