Coderwall API の Scala インターフェース作った

Scala 勉強しようと作ってみたらスゲーサクッとできた。

package org.yoshiori

import net.liftweb.json._

case class Coderwall(username:String, name:String,location:String,endorsements:Int, badges: List[Badge])
case class Badge(name:String,description:String,badge:String)

object Coderwall {
  def get(username:String):Coderwall = {
    val json = scala.io.Source.fromURL(
      "http://coderwall.com/%s.json".format(username)).getLines.mkString
    implicit val formats = DefaultFormats
    parse(json).extract[Coderwall]
  }
}


object Main {
  def main(args: Array[String]) {
    if( args.size < 1){
      println("Usage: Coderwal.scala USERNAME")
    } else {
      val username = args(0)
      val c = Coderwall.get(username)
      println(c)
    }
  }
}

case class 用意しておくと extract でよしなにへのマッピングしてくれるので楽だった。


github はこちら
https://github.com/yoshiori/coderwall-scala

「はじめる！ Rails3（１）」の 演習問題を twitter-bootstrap-rails と kaminari を使ってやってみた！！

と言うことで、写経終わったので演習問題をまとめてやってみました。
（演習問題は全部終わってからまとめてやったほうが復習になるので）


今回は Rails3.2.2 だけだと面白く無いので twitter-bootstrap-rails を使ってみました。
あと、時代は will_paginate ではなく kaminari だよねってことでページねージョンは kaminari でやってみました。

いやぁ、bootstrap 使うとおしゃれなフリができていいですね！！！

そーす
https://github.com/yoshiori/practice_shelf

tomcat7 の Parallel deployment を試してみる

最初に……
同様の機能は jboss にも glassfish にもありますよってことで

「Parallel deployment」は、TomcatにおけるWebアプリケーションのバージョン管理機能です

http://www.atmarkit.co.jp/fjava/rensai4/tomcat7_03/01.html#02

とあるのですが、実際どのくらい使えるのか触ってみないとわからないですよねって事で触ってみた。

最初の登録

war ファイルにバージョン番号を特定の書式で書いておくとアプリケーションのバージョン管理ができます。

appName##version.war

pom には下記のように書いておくと楽ですね。

  <build>
    <finalName>servlet-test##${project.version}</finalName><!-- こんな感じでバージョンを記述 -->
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-war-plugin</artifactId>
        <configuration>
          <failOnMissingWebXml>false</failOnMissingWebXml>
        </configuration>
      </plugin>
    </plugins>
  </build>

で、tomcat にアップロードをすると
こんな感じでバージョンが反映されているのがわかります。

実際にアクセス

当たり前だけど普通にアクセスして動きます。

新しいバージョンをデプロイ


こんな感じで複数バージョンが共存しています。

他のブラウザからアクセス

セッションが共有されないように他のブラウザからアクセスしてみると見事共存して動いていることがわかります

古い方のレスポンスが終わる前に古い方を削除してみる

古い方のコネクションが残ってるまま古い方を削除したらどうなるのでしょう？
$ rm -rf servlet-test\#\#1.0.0.war servlet-test\#\#1.0.0/

削除完了した後も古い方も動き続けています。

無事に終了


無事に終了しましたね。

結論

アプリケーションのデプロイや削除は manage の画面からやっても
普通にコマンドラインで cp や rm でやっても同じ結果でした。

同じアプリが同時に二個動くのでメモリや CPU のコストもそうですが、static な値や DB へのコネクションなどが倍になったりする可能性もあるでそこは注意しないとですが、便利ですね！！！

ソース
https://github.com/yoshiori/servlet-test

github の README.rdoc をサクっとプレビューしたい 

$ gem install github-markup

して

#!/usr/bin/env ruby                                                                                                                          

require 'github/markup'
require 'tempfile'

if ARGV[0] && File.exists?(file = ARGV[0])
  html = GitHub::Markup.render(file)
  tmp = Tempfile::new(['','.html'])
  tmp.write(html)
  tmp.close
  `open #{tmp.path}`
  sleep 5
else
  puts "usage: #$0 FILE"
end

こんなスクリプト書いて Path 通ったところに置いてるんだけどどうなんだろう？？
ブラウザが読み込むまで 5 秒スリープしてるのとか、open コマンドだから Mac でしか動かないとかカッコ悪すぎるんだけど
Ruby な人おしえてくだしあ＞＜


あと、gist がはてダに貼り付けられない？？？

追記:
id:takahashim,@takkanm,@a_matsuda から
http://github-preview.herokuapp.com/
を教えてもらいました！！ ありがとう！！

「はじめる！ Rails3（１）」を Rails3.2.2 で写経してみた

Scala の Specs2 覚えたい！！ → そもそも XUnit 系は得意だけど Spec 系はよく知らないので、本家である RSpec を学ぼう！！ → そのためにはとりあえず Rails を再勉強してみようか（イマココ）

ということで「はじめる！ Rails3（１）」を写経してみました。

そういえば Rails って 6 年くらい前の Rails1 の頃しか触ってなかったので色々変わってるんだろうなぁと思いながら触ったのですが、なんていうか黒魔術的なところが減った？？ って感じでしたね。

で、写経のコードはこちら
https://github.com/yoshiori/practice_hinagiku

メジャーバージョン一緒なので、ほぼそのまま行けたのですが、何点か Rails 3.2.2 対応のための変更点があるのでまとめておくと……

  1. リソースの配置場所が public/ 以下ではなく app/assets 以下になってる
  2. migrate の結果が違う self.up self.down じゃなく、インスタンスメソッドの change になってる
  3. will_paginate-3.0.pre2 だと動かないので 3.0.3 使う

くらいでした。
このくらいの量だとサクッと通勤時間とかで 1 章づつとか写経出来ていいですね！！

Ruby の retry-handler が激しく便利そうなので Java で実装してみた

http://kimoto.hatenablog.com/entry/2012/03/05/103052 を読んでたら
Ruby の retry-handler が激しく便利そうなので Java で実装してみた。

ソース→ https://github.com/yoshiori/retry-handler

どんなものか簡単に説明すると
特定の処理を実行したいんだけど、途中で何らかのエラーが発生した場合はリトライさせたい時に使えます。


具体的にはこんな感じで書くと、処理の途中でエラーが発生しても指定した回数はリトライしてくれます。

Proc.retry(3,new Runnable() {

    @Override
    public void run() {
        //なんか処理
    }
});


特定のエラーの時だけリトライしたい時はそれも指定できます。
例えば IOException とそのサブクラスのエラーの時のみリトライさせたい場合はこんな感じ

Proc.retry(3,new Runnable() {

    @Override
    public void run() {
        //なんか処理
    }
}, IOException.class);


処理をリトライするときに wait を入れることもできます。
例えば 5 秒置いてからリトライさせたい場合はこんな感じ

Proc.retry(3,new Runnable() {

    @Override
    public void run() {
        //なんか処理
    }
}, 5 * 1000);


もちろん、上記を複合で指定することも可能です。
例えば IOException とそのサブクラスのエラーの時のみ 5 秒置いてからリトライさせたい場合はこんな感じ

Proc.retry(3,new Runnable() {

    @Override
    public void run() {
        //なんか処理
    }
}, 5 * 1000, IOException.class);

とりあえず使い方はテスト見ればわかると思うので適当にどうぞ
よく考えると俺、こういう処理が欲しいようなコード書くときはあんま Java 使わねーなｗｗｗ