My Brain is Open.

思いついたことを適当に列列と

ScalaでHello,world!

Scala

今更感がありますが、Hello,world!を自分なりに解説してみます。
サンプルコードはこちら。

// Hello.scala
object Hello {
  def main(args: Array[String]): Unit = {
    println("Hello,world!")
  }
}

Scalaでは次のようにスクリプト実行することもできます。（もちろん一度コンパイルするので遅いですが）

$ scala Hello.scala
続きを読む

Scala+Javaプロジェクト事始め with sbt (1)

Scala Java sbt

Scalaでコードを書きつつ、Javaコードも書いて、テストも両方書いて、同じプロジェクトとしてビルドしたい！という要望により、環境作成をシコシコとやってみることにしてみました。
今回はScalaの単体テスト環境構築まで。

とりあえず、sbtが一番簡単そうなのでsbtの利用を前提にしています。あと、環境はMac OS X 10.6.8 + Homebrewです。
*1

*1:sbt(Simple-Build-Tool) はScalaで記述できるビルドツールです。依存関係もIvyで解決できます。

続きを読む

homebrewでemacsをインストール

Mac OS X emacs homebrew

homebrew( http://mxcl.github.com/homebrew/ )でemacs23.4をインストールして環境構築中です。

あれこれいじってたら以下の表示が出てなんかおかしなことに。

Warning: arch-dependent data dir (/private/tmp/homebrew-emacs-23.4-P2zw/emacs-23.4/nextstep/Emacs.app/Contents/MacOS/libexec/emacs/23.4/x86_64-apple-darwin10.8.0/) does not exist.

調べてみると、起動時にフルパス指定したほうがいいらしい。
(ref: https://github.com/mxcl/homebrew/issues/6661)
しかし、この「フルパス」が曲者。

こうやってインストールした場合、

brew install emacs --cocoa

emacsコマンドは以下の場所にセットされる。

lrwxr-xr-x  1 User  Group  30  3 10 19:35 /usr/local/bin/emacs -> ../Cellar/emacs/23.4/bin/emacs

しかし、ここではなく実際には以下のパスが正しい。

/usr/local/Cellar/emacs/23.4/Emacs.app/Contents/MacOS/Emacs

そこで、homebrewでインストールした場合に常に使えるパス指定として、こんなエイリアスを.zshrcに記述。

alias emacs="$(brew --prefix emacs)/Emacs.app/Contents/MacOS/Emacs"

brewのインストールディレクトリは /usr/local/Cellar/emacs/{version}ってバージョン付きになってしまうので、brew --prefixなどのコマンドで差分を吸収できます。

PostgreSQLのコネクションをいっぱいにして保持するツール

需要あんのかな？

#!/usr/bin/env ruby

require 'rubygems'
require 'pg' # postgres

## Setting ##
ConnectionInfo = {
  :host => "localhost",
  :port => 5432,
  :dbname => "postgres",
  :user => "postgres",
}

# get wait_time from ARGV[0]
if ARGV.size < 1 
  puts <<EOS
Usage: ruby #{__FILE__} <wait_time>
    wait_time: Wait <wait_time> seconds with maximum pg connection.
               ( set <= 0 to infinite, ^C to exit )
EOS
  exit 
else
  wait_time = ARGV[0].to_i
end

# Create Connections
connection_array = Array.new

while(connection_array.empty? or connection_array.last.status == PGconn::CONNECTION_OK)
  begin
    connection_array << PGconn.new(ConnectionInfo)
  rescue PGError
    break
  rescue Interrupt # with Interrupt
    connection_array.each { |conn| conn.close }
    puts "All connection cleared."
    exit
  end
  # p connection_array.size
end

# Print number of connections.
puts "Maximum: #{connection_array.size} connections."

# Wait loop.
begin
  if wait_time > 0
    wait_time.downto(1) do |i|
      puts "Remain #{i} second(s)." if i % 10**((Math::log10(wait_time)-0.5).floor) == 0
      sleep 1
    end
  else
    i=1
    loop do
     sleep 1
      puts "After #{i} second(s)." if i % 10**((Math::log10(i)).floor) == 0
      i += 1
    end
  end
rescue Interrupt # if ^C sent, exit with no error. 
ensure
  connection_array.each { |conn| conn.close }
  puts "All connection cleared."
end

C言語ことはじめ

改めまして、お仕事でC言語を取り扱うことになって1ヶ月ほど経ちました。

これまでシェル(bash)とかRuby on Railsとかスクリプト系が多くてすっかり忘れている感がありました。
というか、実際のところ大学の実習程度にしかやっておりません。
そんな僕に何が出来るのか。とかくぶち当たって考えていこうと思っている次第です。

さて、C言語では何が必要となるか。思いつくままに列挙してみましょう。

  1. ポインタの扱い
  2. バイト単位、ビット単位での対応
  3. 型の明示的な処理
  4. 構造体の利用と整理
  5. 関数の分割方法の整理

適当ですが少しだけ所感を。

  • ポインタの扱い

Cをやるとポインタが難しいとか昔は言われてましたが、いざやってみるとそんなに難しい物じゃないです。
どう考えるかというと、単純に変数の格納先の先頭フラグをイメージするだけです。
配列は同じ大きさのメモリ割り当てが連続しているイメージで、インクリメント(+1)で一つ分ずつずらす感じ。

  • バイト単位、ビット単位での対応

たとえば int は4バイト、char は1バイトといった単位でメモリを使います。
当然 NxN 行列とかつくると大量に消費しますし、数式の計算ロジックなどではビット単位での演算(AND, OR, ビットシフト, etc)を使うことも考えられます。
関数単位での利用メモリ空間をある程度イメージして、無駄がないか、はみ出す可能性のあるロジックはないか、扱うはずのないデータに干渉していないかなど、十分なマッピングを心がけたほうが良いと思います。

  • 型の明示的な処理

Ruby などをやっていると時々忘れるのが型の処理。
例えばintにコマンドライン引数を入れようとしてlongが入ってしまい、値が変わってしまうなどはよくあることで、明示的なキャストや、扱う型が十分見合っているか、事前に型に収まるよう入力チェックが済んでいるか、などをチェックすべきでしょう。
また、最初は型を明示しない内部コード（マクロ定数など）は作成した当人は固定の型に入ると分かっていても、複数人で管理する場合は人為的なミスや仕様変更などが起こり得ることも想定しておき、型チェックを忘れないようにしましょう。

  • 構造体の利用と整理

構造体は意味のあるデータのまとまりをメモリ配置（メンバ変数の集まり）で表すものです。先に述べたポインタのインクリメントなどでは、構造体の配列の場合も有効です。
意外と構造体は使われる局面が少ない気もしていますが、ある単位でひとまとまりになっているべきデータは構造体にして整理すべきでしょう。
理由は例えば関数の入出力にchar*やintなどで引数の多い構成になっていた場合、つぎに変数が増えた途端に改修箇所が増え、改修漏れの原因につながります。
構造体の持つ意味をきちんと定めて、そのデータ単位を扱う関数であると明示すべきでしょう。
ただし、むやみに構造体宣言をすると何をする単位かわからなくなるため、DBのモデル定義のような観点は必要でしょう。

  • 関数の分割方法と利用

関数の中身はできるだけすっきりとすべきです。
どういう意味ですっきりかというと、「この関数は何をするための関数で、それを分割するといくつかのプロセスからなる」事を明示でき、「いくつかのプロセス」が他の人にも分かりやすいことが大切だと思っています。
例えばイベントループを持つようなプログラムであれば

  • main
    • コマンドライン引数処理
      • 入力値チェック
      • 型変換
    • メインループに引き渡す前処理
      • 変数一覧の確認（抜け漏れの無いよう一覧化や構造体化）
      • 引き渡す変数の初期化処理
    • メインループで行われるべきルーチン
      • イベントコールバックの登録
    • メインループ終了後の処理
      • free()などのメモリ管理
      • 適切な値で終了コードが返ってきたかチェック

などなど、まずは大雑把な流れがあり、そこから細かい処理に派生していきます。
この流れをささっとつかめることを大切に、一つ一つの関数を記述出来れば良いと思います。

また、部分関数化するに当たり以下のことに気をつけておきたいと思っています。

  1. 部分関数は一度しか使わなくても、細かくても、見通しを悪くする部分があれば処理のカプセル化出来る部分を探して作成すべき。
  2. 入力されるべきデータや書込み先のポインタを明示する。不必要なものは入れないし、必要であれば必ず明示する。グローバル変数を使わない。

細かいところだと思うのですが、自分のセンスを問うために、よりブラッシュアップして挑みたいと思います。

そんなわけで「初心者がなにかほざいている」程度に思っていただければと思いますが、これからも成長出来ればと思います。

引き継ぎ

そう言っていいのかどうか分からないけど、しばらくの間MongoDBとRuby on Railsで作っていたあるアプリケーション開発のお仕事は、諸事情により中断することになってしまい、僕自身も別の会社で仕事を始めることになっております。
元々の企画自体は引き継ぎをして開発をすることになった大手がいるようで、そちらへ行っていくつかおはなしをしてきました。

その仕事自体は引き継いだものの、このブログ上で色々書いたような経験や仕事の仕方の試行錯誤なんかは自分の中でとても良いものだったように思います。
これからもこのブログ自体でなにか発信出来ればと思いますし、MongoDBやRuby on Railsも個人の開発として続けていこうとは思っています。

以上、なんかすっきりした気持ちになったので書いてみました。

Carbon Emacs のカラーテーマ

Mac Emacs

Carbon Emacsにはcolor-theme.el が最初から入っているため、以下のコードを ~/.emacs.el などに書けば利用可能になる。

;; Color-Theme loading
(require 'color-theme)
(color-theme-initialize)
;; Select theme
(color-theme-clarity)

そんなわけで、デフォルトで使えるテーマ一覧を取り出してみた。
スクリーンショットがないと選びようがないけどね。

$ grep defun /Applications/Emacs.app/Contents/Resources/site-lisp/color-theme/themes/color-theme-library.el | cut -f 2 -d " "
color-theme-gnome
color-theme-blue-gnus
color-theme-dark-gnus
color-theme-blue-eshell
color-theme-salmon-font-lock
color-theme-dark-font-lock
color-theme-dark-info
color-theme-gnome2
color-theme-simple-1
color-theme-jonadabian
color-theme-ryerson
color-theme-wheat
color-theme-standard
color-theme-fischmeister
color-theme-sitaramv-solaris
color-theme-sitaramv-nt
color-theme-billw
color-theme-retro-green
color-theme-retro-orange
color-theme-subtle-hacker
color-theme-pok-wog
color-theme-pok-wob
color-theme-blue-sea
color-theme-rotor
color-theme-pierson
color-theme-xemacs
color-theme-jsc-light
color-theme-jsc-dark
color-theme-greiner
color-theme-jb-simple
color-theme-beige-diff
color-theme-standard-ediff
color-theme-beige-eshell
color-theme-goldenrod
color-theme-ramangalahy
color-theme-raspopovic
color-theme-taylor
color-theme-marquardt
color-theme-parus
color-theme-high-contrast
color-theme-infodoc
color-theme-classic
color-theme-scintilla
color-theme-gtk-ide
color-theme-midnight
color-theme-jedit-grey
color-theme-snow
color-theme-montz
color-theme-aalto-light
color-theme-aalto-dark
color-theme-blippblopp
color-theme-hober
color-theme-bharadwaj
color-theme-oswald
color-theme-salmon-diff
color-theme-robin-hood
color-theme-snowish
color-theme-dark-laptop
color-theme-taming-mr-arneson
color-theme-digital-ofs1
color-theme-mistyday
color-theme-marine
color-theme-blue-erc
color-theme-dark-erc
color-theme-subtle-blue
color-theme-dark-blue
color-theme-jonadabian-slate
color-theme-gray1
color-theme-word-perfect
color-theme-emacs-21
color-theme-jsc-light2
color-theme-ld-dark
color-theme-deep-blue
color-theme-kingsajz
color-theme-comidia
color-theme-katester
color-theme-arjen
color-theme-tty-dark
color-theme-aliceblue
color-theme-black-on-gray
color-theme-dark-blue2
color-theme-blue-mood
color-theme-euphoria
color-theme-resolve
color-theme-xp
color-theme-gray30
color-theme-dark-green
color-theme-whateveryouwant
color-theme-bharadwaj-slate
color-theme-lethe
color-theme-shaman
color-theme-emacs-nw
color-theme-late-night
color-theme-clarity
color-theme-andreas
color-theme-charcoal-black
color-theme-vim-colors
color-theme-calm-forest
color-theme-lawrence
color-theme-matrix
color-theme-feng-shui
color-theme-renegade