似非プログラマのうんちく

「似非プログラマの覚え書き」出張版

Scala でとことん FizzBuzz する(その 2)

前回のプログラムは無事動いたかな ? では改造を始める。でもその前に…。

SBT で作ったプロジェクトを Scala IDE for Eclipse で扱えるようにする

前回までの手順で、プロジェクト直下に project フォルダが出来ていると思う。そこに plugins.sbt というファイルを以下の内容で作成する。

addSbtPlugin("com.typesafe.sbteclipse" % "sbteclipse-plugin" % "2.5.0")

そうしたらプロジェクト直下で

> sbt eclipse

を実行する。これにより Eclipse 用の設定ファイルなどが作られ、Scala IDE for Eclipse でプロジェクトをインポートして扱うことが出来る。コーディング作業は IDE を使う方が楽なのでやっておくと良い。なお、SBT でライブラリの依存関係を変更したときは再度上記コマンドを実行しないと Eclipse 側に反映されないので注意。

続きを読む

Scala でとことん FizzBuzz する(その 1)

Scala sbt FizzBuzz

プログラミングをこよなく愛する皆さん、今日も元気に FizzBuzz してますか !

「FizzBuzz って何 ?」という人から「FizzBuzz が何の役に立つんだよ」という人まで、今回は存分に FizzBuzz を楽しめる(?)連載を始めますよ !

「FizzBuzz」とは何か

FizzBuzz。それはもっぱら英語圏で行われるちょっとしたレクリエーションのようなものである。数人が輪になって、最初の人から順々に数字を 1 から順に 100 まで言っていくのであるが、

  • 数字が 3 の倍数(3, 6, ...)のときは数字を言う代わりに「Fizz」と言う
  • 数字が 5 の倍数(5, 10, ..)のときは数字を言う代わりに「Buzz」と言う
  • 上記の両方に当てはまるとき、つまり数字が 15 の倍数(15, 30, ...)のときは数字を言ったり「Fizz」や「Buzz」と言う代わりに「FizzBuzz」と言う
  • それ以外のときは普通に数字を言う

という遊びである。これをプログラミングでやるときは、1 から 100 まで出力させ、その際に数字が 3 の倍数だったり 5 の倍数だったりするときにその出力を上記の文字列で置き換えて表示させるプログラムを組むことを FizzBuzz と言っている。

何故 FizzBuzz なのか

何故 FizzBuzz をプログラミングすることがそんなに大事なのかというと

  • 入出力
  • 反復
  • 条件分岐

の要素に習熟することに大変優れているから、というのが通説のようである。とりわけ反復と条件分岐が強調されることが多い。入出力は、いわゆる標準入出力はもちろんだが、広く「関数の in と out の関係」についても学ぶことが出来る。

参考 : 最終鬼畜FizzBuzz大全 - Qiita

原始 FizzBuzz

今回は Scala による FizzBuzz の様々な実装を考えてみることにする。まず最も素朴な FizzBuzz はこうなるだろう。

package jp.mydns.akanekodou.scala

object Main {
  def main(args : Array[String]) : Unit = {
    for (n <- 1 to 100) {
      if (n % 3 == 0) {
        if (n % 5 == 0)
          println("FizzBuzz")
        else
          println("Fizz")
      } else if (n % 5 == 0) {
        println("Buzz")
      } else {
        println(n)
      }
    }
  }
}

我々はこのソースコードからスタートして、さまざまな改造をしていくことになる。

SBT(Simple Build Tool)の導入

Scala プログラミングにおけるビルドツールの定番とされているのが SBT である。今回はこいつを使ってプロジェクトを作り、管理していく。Windows であれば MSI 形式のインストーラが配布されているのでインストールは難しくない。

プロジェクトの作成

まずプロジェクトのルートとなるディレクトリを作る。その中に build.sbt というファイル名で SBT 用の設定ファイルを作る。中身はこんな感じ。

name := "FizzBuzz"

version := "1.0"

scalaVersion := "2.11.6"

空行は省略できない。次にソースファイルを配置するフォルダの作成。プロジェクトルートで

> mkdir src\main\scala\jp\mydns\akanekodou\scala

作ったフォルダに先ほどのソースコードを Main.scala というファイル名で保存し配置する。

プロジェクトのビルドと実行

プロジェクトルートで

> sbt

を実行する。初回起動時は必要なライブラリをダウンロードしてくるため時間が掛かる。気長に待とう。プロンプトが帰ってきたら

> compile
> run

でコンパイル→実行できる。さて、意図した通りにプログラムは動いたかな ?

お詫びと補足

お詫び

昨日の記事ですが、IntStream の状態で一度 count をかますと、コメントに残していた一覧表示(forEach の部分)が不可能になります。お詫びして修正します。今回は個数だけを求めるプログラムに特化する形にさせていただきました。一覧も表示させる場合は、元のゆっちさんの書いたように、一度 boxed から collect して List 型にしておく必要があります。

補足

長くなるので折りたたむ。

続きを読む

エラトステネスの篩はもう古い !?

Java

タイトルは親父ギャグじゃねーです !

ゆっちさんがこんな記事を書いていたようで。
ゆっちのBlog » Java8 時代の素数の求め方

最初はそのままパクらせていただいて動かしていました(それでもなかなかに早い)が、地味に無駄な処理があることに気がつきました。

boxed して collect してる部分がそれです。IntStream のままでも count メソッドで個数は確認できるので、以下のように修正してみました。あと、秒未満の処理時間は細かい数値はいらないと思ったのでミリ秒単位で切って表示させてます。


Stream API を用いた並列化された素数検出プログラム

実行時に他のプロセスが動いてたりするとアレですが、一応の目安として

1973815 個の素数を検出しました。
0 時間 0 分 32 秒 914

と、期待される結果と共に、家の非力なマシンでも 30 秒そこそこで処理が完了する*1ことがわかりました。Java8 すげぇ。

*1:オリジナル版だと 1 分ちょい掛かる

エイプリルフールを満喫できる休日はいつ訪れるか

Java

今日は 4 月 1 日です。新年度の始まり、そしてエイプリルフールですね。いろんな人がよってこぞってエイプリルフールネタを投下してくるので、どれが本当の記事かわかりません(苦笑)。

しかし今日はあいにくの平日とあって、エイプリルフールを満喫している人は少なそうです。ましてこれから社会人になる新人さんにとってはエイプリルフールどころでは無いかも知れません。

お祭りごとを存分に楽しむにはやっぱり休日がいいですね ! ということで、そんなエイプリルフールを休日として迎えられるのはいつなのか、調べてみました !

…ってわざわざネタをひねり出したのは、実は先日 id:waman 氏が「2 月のカレンダーが日曜から土曜までにすっぽり収まるのはいつなのか Java Time API に問うてみた」っていう記事を書いていたのを見て、どこかで試したいなぁ、と思っていたのを今頃持ち出してきたわけです。

状況として 4 月 1 日が祝日になることはありませんので、ここでは「土曜日か日曜日である」ことを休日の条件とします(土曜や日曜がお仕事の人、ごめんなさい !)。


指定した日が休日(土・日)かどうか Java Time API で調べる


じゃーん !

2017
2018
2023
2028
2029
2034
2035
2040

直近だと再来年が該当するみたいですね。再来年のエイプリルフールは仕事を忘れて満喫しましょう ! (何)

やっぱり Rails を選択しない 3 つの理由

Ruby Rails

それでもRailsを選択する3つの理由 - pblog
を読んで、敢えて反論を書いてみたくなった天の邪鬼の戯言と思ってください。

まず反論

業務レベルで Rails の導入を検討した場合、概ね以下のような感じになるんじゃなかろうか。

「規約縛りの哲学」への反論

言語レベルでの規約があることは確かに大きいが、だからといって完全に自由度がないわけでもない。結局は現場レベルのコーディング規約で細かいところは縛らないといけないし、だったらわざわざ Rails に乗り換える必要性は感じられないのではないか ?

「周辺のエコシステム」への反論

OSS に貢献するのは義務なんですか ? OSS に貢献しない人は使っちゃいけないの ? Ruby 界隈が蛇蝎のごとく嫌われる理由がこの辺にある気がします。

「Web の進化への追従」への反論

Web が日々進化していることは動かしようのない事実で、それは誰も異論を挟まないと思う。しかし、Web がいくら進化しても、それを利用する人間まで急激に進化するわけじゃない。自分で作ったものを自分で使うならわかるけど、作る人が「Web は進化してるんだよ ! お前らも追従しろ !」って使う人に言ったところで「いや、俺ら素人だし」ってなると思う。

私が Rails を選択するたった一つの理由

じゃあ「お前は何で Rails を選択したんだ」と問われたら、私は自信を持ってこう答える。

「好きだから。」

それ以上の理由はいらないんじゃないかな。開発に携わる人がみんな Rails が好きで好きで仕方ないという状況なら、そうすればいいと思う。ぶっちゃけると使う側の人からすれば動いてれば何で作られていようがあまり気にしないだろうし。

JPA + EJB + JSF による Web アプリケーション(その 6)

Java JSF Sass 
　 ∧,,∧
　(；`・ω・）　　｡･ﾟ･⌒） View 作るよ！！
　/　　 ｏ━ヽニニフ))
　しー-Ｊ

Facelets 群 + α。
MajorCityJavaEE/list.xhtml at master · akaneko3/MajorCityJavaEE · GitHub
MajorCityJavaEE/detail.xhtml at master · akaneko3/MajorCityJavaEE · GitHub
MajorCityJavaEE/index.jsp at master · akaneko3/MajorCityJavaEE · GitHub(ダミー)

ソースコードをいちいち貼り付けるのが面倒なので GitHub のリンクでごまかす。JSF 2.2 用の名前空間を使用している以外は基本的に JSF 2.1 のころとそんなに変わらないです。もちろん JSF 2.2 からの新機能を利用した書き方もあるにはあるんですが。

Sass ファイル群はこちら。
MajorCityJavaEE/common.scss at master · akaneko3/MajorCityJavaEE · GitHub
MajorCityJavaEE/list.scss at master · akaneko3/MajorCityJavaEE · GitHub
MajorCityJavaEE/detail.scss at master · akaneko3/MajorCityJavaEE · GitHub
これ以外のリソースは Compass の初期設定時に作成されているのでいじる必要なし。ファイルを変更して保存すると Builder が勝手に走って Sass ファイル群のコンパイルをしてくれるはず。

Sass といえど基本は CSS なので、Facelets 用の独自のタグがどのような HTML のタグに変換されるのかがわかっていないとなかなか書けない。ここはある意味鬼門。

最後に MajorCityEJB プロジェクトと MajorCityJSF プロジェクトを内包する MajorCityEAR プロジェクトを作成して、これを WildFly に登録してやればよい。

あと、web.xml も filter 用の設定を書き加えておく。
MajorCityJavaEE/web.xml at master · akaneko3/MajorCityJavaEE · GitHub