今さらかも知れませんが、Groovy でコンストラクタを実装する方法をあれこれ試してみました。 今回試したのは以下のような方法です: 基本 デフォルト・コンストラクタ 名前付き引数 コンストラクタ定義 アノテーションによる AST 変換 @InheritConstructors アノテーション @TupleConstructor アノテーション メタプログラミング 実行時メタプログラミング マジック・パッケージ では、それぞれを見ていきましょう。 基本 まずは基本。 デフォルト・コンストラクタとコンストラクタ定義は Java と同じ。 名前付き引数は Groovy 用です。 デフォルト・コンストラクタ、名前付き引数 Groovy でクラス定義にコンストラクタを書かなければ、Java と同じようにデフォルト・コンストラクタが自動生成されます。 デフォルト・コンストラクタは引数なしで特に何の処
This webpage was generated by the domain owner using Sedo Domain Parking. Disclaimer: Sedo maintains no relationship with third party advertisers. Reference to any specific service or trade mark is not controlled by Sedo nor does it constitute or imply its association, endorsement or recommendation.
TDD及びペアプロを通じてプログラミングスキルを上げるべく、ネットで公開されている『お題』について色々情報収集してみました。 お題やテーマについては、見つけ次第随時追加していきます。 Stackユーティリティ from 『車窓からのTDD』 - 車窓からのTDD こちらについては自分でも試しに写経してみました。以下エントリ。 『車窓からのTDD』を写経してみた ( JDK7 / Eclipse4.2 / Quick JUnit / Mercurial / Bitbucket ) - Shinya’s Daily Report FizzBuzz問題 from TDDBC TDDBC お題 うるう年問題 from TDDBC TDDBC お題 LRU Cache from TDDBC TDDBC お題 ワードフィルタ from TDDBC TDDBC お題 以上、ここまでの4つのお題は和田卓人
BarkeepはGitリポジトリに対応したユーザビリティ高いコードレビューシステムです。 会社でプログラミングを行っているとそのコードの品質はばらつきが出てきます。そうするとバグが多くなったり、予期しない問題に直面したりします。それを防ぐのに有効なのがコードレビューです。Barkeepはユーザフレンドリーなコードレビューシステムになっています。 メイン画面です。コミットログが並んでいます。 詳細です。差分が表示されています。 サイドバイサイド。アニメーションしながら表示されて格好いいです。 コードをダブルクリックするとコメントできます。 コメントしました。 一つにまとまっている場合もコメントできます。 レビュー依頼もできます。 ステータスです。レビューされている、されていないといった情報が一目で分かります。 検索結果です。 こちらはプロフィール。 Barkeepは検索における入力補完やフィ
2012年7月21日に大崎のフューチャーアーキテクトさんで行われたChef de DevOpsで話してきましたのでその際の資料を公開しておきます。 なお、内容については2011年12月くらいに行ったワンクリックデプロイ勉強会の資料とほとんど同じですので、以前にご覧になっている方にとっては目新しいものは何もありません。 新作作りたかったのですがごめんなさい。 言いたかったことは色々あったりしますが、道具としてのツールを使いこなすのはプロとしてとても重要であるのは前提とした上で、それでも単にツール単体の話をする前に、もうちょっと大きな全体像をとらえる必要があるということです(仕事じゃないなら好きにすれば良いですがね) 目先の効率化ももちろん重要ですが、それがプロダクト全体に対してどう作用するのかというのを理解せずに進めてしまうと、周りの理解も得られませんし、長期的に物事をよりよくするという流れ
システム開発をする上で、完了条件は避けて通れない。完了条件とは、いつ仕事が終わったかを定義するものである。この仕事が完成したということをステークスホルダー間で合意できる基準といってもよい。 仕事全体の完了を示す完了条件もあれば、仕事が次のステップへと移っていいという指標になる完了条件もある。完了条件は、下位の完了条件が満たされることという完了条件もあれば、同じような大きさの完了条件が全て満たされてはじめて完了となるようなものもある。おおよそ仕事として分割できる単位であれば、完了条件があるといってもよい。それだけに、完了条件は重要である。 完了条件というと、どうも固い言葉で手戻りを許さないウォーターフォール型の開発でしか使われていないと感じる人もいるかもしれない。ところが、スクラムといったアジャイルプロセスであってもDoneの定義(=完了条件)は重要な位置を占めている。もちろん、ウォーターフ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く