不悔必省

ScalaでFizz Buzz

Scala, fizzbuzz

そのいち。一番素直に見える。

object FizzBuzz1{
  def main(args:Array[String]):Unit={
    1 to 50 map (n => n match {case n if (n % 5 == 0 && n % 3 ==0) => "fizzbuzz"
        case n if (n % 3 == 0) => "fizz"                                            
        case n if (n % 5 == 0) => "buzz"                                            
        case n => n}) foreach {println}
  }
}

そのに。手続き型伝統的。

object FizzBuzz2{
  def main(args:Array[String]):Unit={
    for (i<-1 to 50){
      if(i % 3 == 0 && i % 5 == 0){println("fizzbuzz")}
      else if(i % 5 ==0){println("buzz")} 
      else if(i % 3 ==0){println("fizz")}
      else{println(i)}
    }
  }
}

そのさん。再帰。

object FizzBuzz3{
  def main(args:Array[String]):Unit={
    val result = fizzbuzz(1,50,List()).reverse
    result foreach {println}
  }
  def fizzbuzz(n:Int,max:Int,list:List[Any]):List[Any]={
    val v = (n match { 
      case n if (n % 3 == 0 && n % 5 == 0) => "fizzbuzz"
      case n if (n % 3 == 0) => "fizz"                                            
      case n if (n % 5 == 0) => "buzz"
      case n => n}) :: list
    if (n == max)  v 
    else fizzbuzz(n +1,max, v)
  }
}

参考：

FizzBuzz - SumiTomohikoの日記

2008-01-12 - ryugateの日記

Symfoware ScalaでFizzBuzz

Permalink | コメント(0) | トラックバック(2) | 02:07

ScalaとSpecs事始め

scala, specs

最近Scalaを始めた。とりあえず鉛筆本を読んだ。O’Reillyの獏本も、iPhone/iPod用電子書籍版を読書中。

ちょっと何か書いてみようか、まずはBDD*1のコードを書いてみようと、Specsのjarをダウンロードしてきた。

SpecsのQuickStartのページを見ながら、helloWorld.scalaを作成した後、

% scalac -cp specs-1.6.1.jar helloWorld.scala
% scala -cp specs-1.6.1.jar helloWorld
no such file: helloWorld

…QuickStart通りだが動かない。まぁ記述がおかしいからさもありなん。パスを追加して再実行。

続きを読む

Permalink | コメント(0) | トラックバック(0) | 01:10

Release It!

書評

　最近、想定ユーザ数がかなり多いアプリケーションの開発に(末端の開発者として)関わったが、悲しいかな、この本を読んで何も知らなかったという気分にさせられた。そして恐ろしくもなった。

例えばケーススタディにこうある。

数百の旅客機と数万人の社員を擁し、全世界を股にかける数十億ドル規模の巨大航空会社の運行をストップさせたのは、たった１つのSQLExceptionの捕捉を怠るという、一人のプログラマが犯した初歩的なミスだったのだ。 （p.21）

サービスというものが、作り方によっては一行のコードから全体まで、いかに容易に密結合できるか、ということを教えてくれる。また、

依存システムがみんな、あなたのシステムと同じSLA(サービス品質保証契約)を提供するようになっていなければ、どうがんばっても最も低いSLAを提供するサービスプロバイダと同じ程度のSLAしか望めない。 （p.87）

ということで、当然ではあるが接続する他のシステムにも深い理解が必要となる。

　ただし著者が、開発時にすべてのケースを想定、テストし、万全な状態で送り出すべきと書いている訳ではない。現実のテスト環境は、いかに実環境とは違うかということが列挙されている。（ex. p.133）

続きを読む

Permalink | コメント(0) | トラックバック(0) | 03:19

DevLove新陰流ユーザビリティ勉強会

devlove-usability

　初めて、DevLOVEに参加できた。

日立SASの柳生 大介氏による、ユーザビリティの勉強会。

　ユーザビリティは、人間中心設計の上に成り立つ。「思いやり」という言葉が印象に残った。

続きを読む

Permalink | コメント(0) | トラックバック(0) | 01:31

ことわざはアウトプットであってインプットではない

life

悩んでいるとき、考えているときに、ことわざとか、格言とかなんでもいいけど短くまとめられた言葉が役に立ったことがない。問題が解決して振り返ったときに、端的に表すとことわざでうまく表せたりする。

短い言葉は多くの意味を含むけれど、受取る人によっていかようにも解釈しうるから、人を動かすにはあまり効果的ではないと思っている。

短い言葉に実感を持たせるには、広大なバックエンドを必要とする。自分の体験では、学生時代に読んだ「姑獲鳥の夏」「解体屋外伝」「勇午　ロシア編」が特に思い出深い。

「僕は人間を信じたのです」(勇午)という、これだけ聞くと何とも陳腐な台詞。それにどれだけ意味を持たせられるかは著者の力量が物をいう。このロシア編は今読んでも涙が出る。

最近だと、映画「スラムドッグ・ミリオネア」の最初に仕掛けられたクイズは、映画を見終わると思わずガッツポーズしたくなる問いかけだし、先日のJava-jaでは、「スティール・ボール・ラン」の「黄金の回転」というキーワードにみんな盛り上がっていた。*1

だから、文化的な共通項があると、短い言葉に共通認識を得やすい。かつては、ことわざにもそんな状態を期待できたんだろうか。

さてなんで改めてそんなことを思ったのかというと。

eXtreme Programming(XP)は「シンプル」「コミュニケーション」「フィードバック」「勇気」という「四つの価値」を定めている。先日XPを説明している社内の資料を見たのだが、価値から説明されても、知らない人には何のインパクトももたらさないと感じたから。だいたい、自分だってこの「価値」を分かっている自信がない。

人になにかを伝えるには、小説や映画を作るような多大な努力と感性が必要なのだろう。講義では網羅的に教えなければならないという、お約束を打ち破ることも。

能書きをたれるより、気づきを与えること。人に教えるにあたってはとても重要なのだが、一番難しいことかもしれない。

そうしてみると やっとむ (id:yach) がやっているプロジェクトゲームはとても効果的だと改めて思う。

Permalink | コメント(0) | トラックバック(0) | 22:12