気づいたら随分Blog書いてなかった。来月から本気出す。 去年の頭からアジャイルジャイル言い出して色々と開発現場の改善に取り組んで、改善にもコツがあるなーと気づいた。 KAIZENってなんだ? KAIZEN。改善。悪いところを改めること。数多くの進歩を継続的に行うこと。 改善を行っていくためには、簡単言えば、思考停止、ダメ。ゼッタイ。なんとなく作業している限り改善は行えない。 KAIZENするとどうなるか? 何か問題があったり、もっと良い方法を見つけたとき、仕事のやり方を変えていく。プロセスを追加・変更したり、ツールを導入したりする。仕事のルールが変わったり増えたりする。そうすることでもっと早く、あるいは安く、あるいは良いモノが作れるようになる。 でもそれは思考停止を誘発する。なぜならプロセスやツールというのは今まで考えないと出来なかったことを考えなくてもできるようにするためのものだからだ。考えること自体はコストだし、僕らエンジニアはもっと本質的で価値に繋がる部分で頭を使わなきゃいけない。
Scala Conference in Japan 2013 にスポンサーとして参加させていただきました。 個人的に Scala は、認知度や採用事例の面でこれからの言語だと思っていましたが、200名の一般参加枠が一瞬で埋まったことや、各社のScalaの事例を聞き、今後確実に広がっていく言語だと感じました。 技術的な面では、Akka のインパクトが相当強かったです。ちょうど今仕事で取り組んでいるところで使えそうな仕組みでしたので、非常に勉強になりました。あとは Play のライブコーディングが凄かった。 また、リクルーティングセッションにも参加させて頂きました。思ったよりも参加者が少なかったですが、意外と仕事で Scala を使える会社が多いんでしょうか。。マジで切実なので仕事で Scala 使いたい方はお声がけして頂けると嬉しいです。
この記事はTDD Advent Calendar jp: 2012の14日目の記事です。前日はposaunehmさんのJUnit実践入門 MSTest用パッチ #TddAdventJpでした。 プログラマであれば、多かれ少なかれシェルスクリプトを書いた経験はあると思います。でも、シェルスクリプトでユニットテストを書いたことのある人は意外に少ないのではないでしょうか。 シェルスクリプトでユニットテストを書くには? shunit2 を使います。ダウンロードして解凍してexamplesの下にあるシェルを実行すればサンプルが動きます。 $ sh ./equality_test.sh testEquality Ran 1 test. OK 使い方 test で始まるファンクションがテスト対象になります。また、テストスクリプトの最後でshunit2を読み込む必要があります。
この記事はPlay or Scala Advent Calendar 2012の13日目の記事です。Advent Calendar も折り返し地点になります。 ScalaはJavaに比べて非常に簡潔なコードを書けることが魅力のひとつですが、簡潔に書こうとして想定しない動作になってしまったことのひとつやふたつ誰にでもあるはず。 Exsample さて、以下のREPLの結果を見てください。 [code language="scala"] scala> val list1 = List(1, 2, 3) list1: List[Int] = List(1,
10/30, 10/31とad:tech tokyoに行ってきました。 参加したセッションは以下。 10/30 K−1 : Creativity in a Connected World. K-2 : Unilever Re-Frames Marketing for the Digital Age D-1 : ビッグデータとターゲティングの可能性を探る B-2 : モバイル広告の未来:事例から見るモバイル&タブレットの可能性と課題
サムライ・エピソード【電子書籍】 26人のサムライ達 達人出版会 発行日: 2012-09-14 対応フォーマット: EPUB, PDF 詳細を見る 26人のアジャイル開発の体験談をまとめた「サムライ・エピソード」が達人出版会から発売されました。定価800円のところが9月末までは特別価格500円になっております。 発端は、Agile Samurai Dojo Gathering の直後に@hirocasterさんがアジャイル開発の体験談をみんなで書いて本にしませんか?と呼びかけて始まりました。成功談や失敗談、TDDやCIなどのプラクティス、あるいはチームやマインドといった様々な体験が詰まっています。また、全員が日本人ということもあり、日本の開発現場にいるエンジニアの皆様には共感できる話が非常に多いと思われます。
主催していたアジャイルサムライ読書会が昨日で最終回を迎えました。全5回、半年足らずで駆け抜けた会になりましたが、いろいろと得るものがありました。 以下、最終回で発表した資料です。(一部のフォントがおかしくなってますがまぁ読めるので…) アジャイルサムライ読書会inFAN道場最終回Closing from Taisuke Shiratori 元はと言えば、Agile Samurai Dojo Gathering に参加したことがきっかけでした。あのセミナーで得た感動を現場の人たちと共有できたら、もっと良い方向に行くんじゃないかと思い込み、読書会をやろうと決意したわけです。結果は芳しくなかったですが…。 もう少し言うと、Agile Samurai Dojo Gathering ではアジャイルサムライの原著者・監訳者をはじめ、僕の手の届かないようなすごい人たちがスピーカーとして登壇されていたのですが、昼休憩中のアジャイルサムライ読書会の紹介ライトニングトークに登壇された方々に対しては「
エンジニアのためのJavadoc再入門講座を読んだ。Javadocいろいろ知らなかったなーってことを再確認。Javadocだけじゃなく、ドキュメンテーションコメントを書くとき(Scaladocとか)でも気をつけた方がいいことが色々あったのでまとめておく。 Javadocタグを使いこなす ブロックタグとインラインタグがある。ブロックタグは @param のように単体で何らかの概念を表現し、行頭に配置しないといけない。インラインタグは主説明やタグセクション内部で特定の部分をマークアップするために使う。 インラインタグ @literal 特殊な文字をエスケープする。 {@literal List<String>} のように書くと、<などのエスケープが必要な文字をそのまま書ける。 @code コードをコードとして整形する。{@code ~~~~ } でサンプルコードが書ける。 @link 他のクラスやメソッドに対してリンクを張る。
達人プログラマー―システム開発の職人から名匠への道 の中で、ストループ効果を例に挙げて名前の重要性を説いていたので実際に試してみました。 Javascriptでストループ効果を体感できるものをささっと作ったので、興味のある方は試してみてください。 ストループ効果を体感するまでもなく、名前というのは非常に重要です。プログラマの方々は特に、常日頃から様々な名前をつける機会があるはずです。ファイルの名前、オブジェクトの名前、関数の名前、変数の名前、etc...。そして、名前と実態が噛み合っていない酷いプログラムも数えきれないほど見てきたと思います。 さて、どうやったら名は体を表す名前をつけられるのか? 言い古されていることだけど、プログラムであれば名前をつける対象の責務をシンプルにすることが一番です。赤いものは赤と呼べばいい。実際のプログラムコードを、灰赤紫としか言い表せないようなエキセントリックな色にしなければいい。簡単に言うなぁと思うかもしれないけど、それが簡単にできないのはプログラマとして未熟だからですよ。自戒。 でも、現実的には名前重要というのはプログラマだけの問題じゃない。プランナーから上がってくる近未来的なすべてを解決してくれる夢のシステムを開発するプロジェクトなんかも、
最近アジャイルを導入しただとか、大手SI会社がアジャイルの人材育成に乗り出したりとなんだか盛り上がってますが、うちの会社でも今年からアジャイル開発に取り組んでいます。高速開発を実現するためです。ただ、実際にアジャイル開発によって、開発のスピードが上がるのか?というと僕はそんなことはないと思っています。 アジャイル開発というのは、スピード感を持つことはできるけれど、アジャイル開発そのものはスピードが上がるものではない、というのが僕の考えです。 スピードとスピード感。ぱっと聞くと何がどう違うのか一瞬戸惑いますが、言葉の通り物理的なスピードと、その速度を感じられるかどうか、という違いがあると思います。 例えば、新幹線ののぞみは最高速度が時速300kmで東京-大阪なら2時間半で走りますが、実際にそれがどのくらいの速さに感じるかは、のぞみに乗って流れる景色を眺めるのが一番なわけです。逆に、のぞみに乗っていても目隠しされていたらそのスピードは視覚的には体感できません。 何が言いたいかというと、スピードは「速い」か「遅い」かであって、スピード感は「