サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
Wikipedia
yasutech.blogspot.com
オブジェクト指向エクササイズというのが一頃流行った。自分も Java プログラマだったころは、1,000〜2,000行ほどのプログラムに適用して試したり、同僚にも勧めたりしたことがある。 ただ今の時代、パラダイム面でオブジェクト指向一強だった昔とは違うし、自分でもフルタイムで関数型プログラミングをやるようになったりして、改めて見直してみるとオブジェクト指向エクササイズも色々と怪しいところが多い。 この記事では関数型の視点も取り入れつつ再評価してみたい。 ■ 評価の観点 オブジェクト指向エクササイズは『ThoughtWorks アンソロジー』所収のエッセイで紹介されたもので、著者によればオブジェクト指向の考え方を磨くのに役立つという9つのルールから成る。 原語だと Object Calisthenics と言うが、Calisthenics とは「懸垂、腕立て伏せ、ストレッチ、ジャンピングジャ
Java の仕事をしていると、WAR(Web ARrchive) をワーと発音する人をみかける。また、EAR(Enterprise ARchive) をアーなんて発音する人も多い。ちょっと気になるので調べてみた。 まずは Youtube で 英語圏の人たちがどう発音しているか観察してみる。ejb だとか Tomcat だとかで検索すると、いろんなのがヒットする。例えば、以下のビデオでは、01分43秒のところで、次のように話しているのが聞き取れる。 http://www.youtube.com/watch?v=wIKdM-d7FiA We go on a little bit about packaging our application. This is EAR, WAR and JAR files. 普通の英単語と同じように WAR ⇒ /wɔr/、EAR ⇒ /ɪər/、JAR ⇒ /
以下、その方法。 ==== リストを表示する XSLT は以下のようなものになる。ポイントは<a>要素を生成しているところで、javascript 関数 showDetail()に arabic 要素を渡すようなリンクが作られる。 <?xml version="1.0"?> <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"> <xsl:template match="/"> <ul> <xsl:for-each select="numerals/numeral"> <li> <xsl:element name="a"> <xsl:attribute name="href"> javascript:showDetail(<xsl:value-of select="arabic"/>)
アジャイル関連の資格について調べてみた。 アジャイルと認定資格って、なんとなく相容れないイメージで、開発者の間でも物議を醸しているらしいが、最近は結構、動きが活発になってきている。 まあ他の資格と同じで、保有しているからといって実務能力があるって事にはならないだろうが、少なくとも会話が成立するレベルの語彙を持っている事の表明くらいにはなると思う。もちろん実践で成功している人なら、我流に偏らないお墨付きの正統な知識も持っているという事になり、鬼に金棒で言う事が無い。 ==== ◆ Scrum Alliance: 認定スクラムマスタ 等 すでに日本でも取得者が増え始めている、Scrum Alliance の認定資格。 トレーニングコースに参加する必要があり、日本開催時の受講体験記をネットでも散見する。ただ、これが結構高い。ざっと検索したところ、同時通訳付きで20万、通訳なしで15万といったとこ
基底クラスのコンストラクタ呼び出しだけをモックですりかえるにはどうすれば良いか。 以下のように実験してみた。AssertionError を投げているところを、設定ファイルの読み込みとかマスタデータへの依存とか、面倒なセットアップが必要だったり時間がかかったりする処理に読み替えると、ニーズが分かると思う。 ==== 例題 (1) クラス BaseClass を継承したクラス CuT があるとする。こんな感じ。 public class CuT extends BaseClass { public CuT() { super(); } } ところが、BaseClass の実装はこんな感じだったとする。public class BaseClass { protected BaseClass() { throw new AssertionError(); } } 以下のテストコードを実行すると、
Haskell で ソケットを使ったクライアント-サーバ通信をやってみる。 Haskell を使ったネットワーク・プログラミングの入り口が分かればいいので、クライアントから受け取った文字列をひっくり返して返すだけの、簡単なお題とする。 まず、サーバはこんな感じ。 import Network import System.IO main :: IO () main = withSocketsDo $ do hSetBuffering stdout NoBuffering server `catch` (const $ putStrLn "Exception caught.") putStrLn "Connection closed." server :: IO () server = do sock <- listenOn (PortNumber 8001) repeats (receive
Redmine や Trac の wiki などを使ってプロジェクト内で情報共有している HTMLベースのコンテンツを、プログラムで取り扱うやり方を考えていて、Groovy でも使ってみようかと思い立つ。 で、やっぱり Eclipse で使いたいのでプラグインを入れる。Indigo なら update site は ここで、Required とマークされている Groovy Eclipse ってのがあるから、これを選択してインストール。 インストールできたら、お試しプロジェクトを作る。パッケージエクスプローラ上の右クリから New -> Other と進むと、Groovy Project がリストに出てくるから、選択して適当に操作すると、Groovy Project が生成される。 適当に Hello World を書いて、main() メソッド上の右クリから[Run As]を選択すると、
三項演算子を使うべきでないとする規約や現場って、結構多い。 それに対する「使う」派の主張もたまに見かけるが、「控えめに使うなら許されるべき」なんて消極派だったり、「三項演算子すら理解できない奴はクズ」なんて議論拒絶派だったり、或いは「三項演算子の方が格好良くて好き」的な頭脳労働苦手派であったりする。 自分は使用肯定派だけど、なるべく合理的に三項演算子について考えてみたい。日曜なのに暇だしな。 最初にまず、「if 文ではなく三項演算子を使うべき」状況を考えて、その後で、良くある三項演算子否定論への異議を述べてみる。(言語は C# とか Javaを想定) ■■ if 文を避けて三項演算子を使うべき理由 ★ 変数の宣言と定義を同時にできる 一時変数への値の設定について、宣言と同時なのと宣言から離れているのとで、どちらが良いコードかという問題だが、後者の「離れて」が正解なんて言う人は聞いたことが無
最近は、「xUnit で UnitTest を書いてカバレッジとってます」なんて、どいつもこいつも謳ってるけど、お前らマジかと。それで出来てるつもりなのかと…? というわけで、秋の朝がさわやかなので、自動テストの出来てる度合いの段階区分を考えてみたい。 Level 3: 出来てる:常時テスト成功、高カバレッジ ちゃんとできてるプロジェクトの出来る子ちゃん達からしたら、取り立てて言及することもない当たり前の状態だと思う。 "Clean Check-In" が普通に守られているから、当然、テストも常時全件成功する。まあ基本中の基本。 で、TDD/TestFirst で開発してるから、開発の最初期から高カバレッジ(計測対象範囲内でのカバレッジ基準充足)で始まり、進捗に伴いソースコード量が増えていく中でも、高カバレッジを維持したまま推移する。 Level 2:怪しい:ほぼ常時テスト成功、低カバレッ
サーブレットのユニットテストのやり方。 次のようなサーブレトの doGet() が、JavaDoc の仕様どおりに動作する事を、JUnit で検証するにはどうするか。 public class HelloServlet extends HttpServlet { private static final long serialVersionUID = 1L; @EJB private HelloBean helloBean; /** * req から 取得した GET パラメータ user を、helloBean の * sayHello()メソッドに渡し、その戻り値を res から取得した * PrintWriter に書き出す。 */ protected void doGet( HttpServletRequest req, HttpServletResponse res) throw
「Selenium Documentation 」を読みつついじってみると、単に get started 的なニーズに限っても、割りと読むところが多くて面倒くさい。あと、Selinium IDE から入る説明より、プログラマなら 多分 Selenium RC の方が始めやすい気がした。(ちなみに、ほんの数年前まで Selenium Core ベースでの説明が主流だったけど、この先 deprecated になって行くらしい。) という事で、以下に最小限の要素だけ抜き出してみた。 ■ やる事 以下の事をJUnitのテストメソッド内で自動実行する "http://www.google.co.jp/" を開く テキストボックスに"selenium rc"を入力 検索ボタンを押す 結果のページに"selenium rc の検索結果 約*件中*件目"というパターンが含まれる事を確認する。 以下の知識を
パターン・カタログ=GoFのデザパタだと思ってる人をたまに見かけるが、実は結構、他にもたくさんある。 以下、勝手に作ったパターンカタログのランキング。飽くまでも私的で主観的な尺度でポイントを付けた。 1位 GOFのデザパタ 言わずと知れたデザインパターンのバイブル、『オブジェクト指向における再利用のためのデザインパターン』掲載されている、23のパターン。まずはこれが基本かと。 実用度有名度使い勝手教養度面白さポイント
右のボタンを押すとメッセージボックスが開いて、OK すると文字列"OK"、Cancel すると文字列"Cancel"が、左のテキストボックスに表示される ようにしたい。 さて、この作業を TDD でやるとどうなるか。 GUI アプリは UnitTest できないものと考えがちな人は、やはりここでもメッセージボックスに伴うユーザ・インタラクションを理由に UnitTest を諦める。 実は、こういった場合の対処法は割と昔から研究されて、パターンとして広く知られているものも既にいくつかある。 基本的な方針は、最小限のコードを残して、振る舞いに関する責務をテスタビリティの高い別のオブジェクトに移動してしまうというもの。 そうやって、極薄にしたフォーム・コード(UnitTest はオプション)と、振る舞いを含む実質的な UI ロジック(カバレッジ100%)に分けることで UI 層全体としてのコード
「ワークフローエンジン - 構築すべきか、せざるべきか?」という記事を読んで、いちいち同意。 自前のワークフローエンジンを自作したがる人が多くて困るよねという話。 既製品に比べて、自前ワークフローエンジンは明らかに低品質・低機能の上に高コストなのに、なぜか横行している。「車輪の再発明」というアホでもわかる愚行が、ことワークフローに限っては、まかり通っている不思議についての考察。 記事を要約すると、3対の自作したがり派の主張と、対する筆者の反論。We only have very basic requirements(ワークフローエンジンを使う程難しい仕様じゃない)→ たいていの場合その後の仕様変更や機能拡張に対応できず、メンテ地獄に陥る。 We need to integrate the engine into your application(他人の作ったシステムに依存して振り回されるの
最近、あるソフトハウスの新人が、準委任契約の開発現場にアサインされるにあたって、顧客企業の開発部門の責任者の面接を受ける事になり、その現場に居合わせる機会を得た。 で、本人のスキル不足に関しては、新人だからと言う事で、まあしょうがないという雰囲気だったが、xUnit の経験が無いという話になると、顧客側責任者から、その新人に同行したソフトハウスの上司に対して厳しい指摘が飛んだ。 曰く、「これからの現場では、xUnit を用いたテストコードによる自動テストを"しなくてよい"なんて事はあるわけが無いから、新人研修では絶対にテスト駆動開発も教えるべき。」という事だった。 私としては、立場上、浮かれた態度を取れない状況だったので、その場ではほぼノーリアクションで神妙にしてたけど、内心は「我が意を得たり」の心境で、ちょっと気分が良かった。 開発の現場にいると、「先にやっておくべきことを後に回すと、利
リソース Foo は以下のようなクラスで表現する(以下、パッケージはどれも springmvc.web とした)@XmlRootElement public class Foo { String name = ""; public Foo() {} public Foo(String name) { this.name = name; } public void setName(String name) { this.name = name; } public String getName() { return name; } }コントローラはこんな風になる。@Controller @RequestMapping("/foo") public class FooController { @RequestMapping( value = "/id/{fooId}", method = Req
先日、低スキル志向なチームについて考えてみた。 それは、ある時点で比べたらたまたま高スキルなチームよりは相対的にレベル低かったというものではなく、落ちるべくして低スキル方向に転がっていくという性質をもったチームだった。 今回は低スキル志向チームをより低スキルに育てるポンコツ育成プラクティスを考えてみる。 ■ 低スキル側に合わせてルールを設定する あるプログラミングテクニックやライブラリについて、初心者には無理だとか、以前にだれかが間違った使い方をしたといった理由で、全面禁止とする文化。 実行しながら学習する文化、上手に失敗しながら成長する文化が醸成されず、低いレベルで成長が頭打ちになる。 出来るメンバーからアホらしくなって離脱してチームのスキルレベルが下がる一方となり、ルール設定がさらに低スキル向けになって負の強化ループが発生。 「メンバーのレベルが上がったら解禁しよう」などと言うが、そん
このページを最初にブックマークしてみませんか?
『yasuabe blog』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く