eXtreme HAGO2 Lightning Talk
2011.02.05 に行なわれた xhago の第2回目が開催されたので行ってきました．
前回はトップバッターで発表だったけど今回はネタがないって事で完全な聴講のみで参加
xHAGO とは
xHago は正式名称を(おそらく) eXtreme HAGO といい沖繩県内の技術者が日頃自分がやっている事を発表してみようというLT大会です．
HAGO (ハゴー) とは沖繩の方言で本来は汚いとかネガティブな意味で使用されますが，今回のイベントではどちらかというと黒魔術のような他人に理解しにくい技術というポジティブな意味合いで使用されています．
第一回目となる前回は未踏に採択された子の話や世界最速grepを作った話など本当に理解できないけどすごい事だけは解るといった話やデザイン周りの話，ハード寄りなDIYな話しなど HAGO の名に相応わしい内容となっていました．
xHago2 LT
正直今回はそこまで午前の部に期待してなかったのだけれど始まってみれば他の事してる余裕ないぐらい全部おもしろかったです．
今回の発表は沖繩高専生ががんばっていておもしろいLTを連発していました．
またあの有名な Tython の作者である id:gongoZ が Tython を利用したプレゼンを行い会場は爆笑の荒らしでした．
感想
沖繩でこのレベルの技術的な集りができるのはとてもすごい事ではないだろうか
学生と社会人，大学生と高専生といった日頃あまり絡む事の少い人同士がこういった技術発表を通して交流を深めていくのは互いにプラスになるいい機会です．
今回の発表を見て「自分も何か作りたい．作らないといけない．」と強く思う事ができました．
また次回参加したいとおもいました．
Serversman の VPS がものすごく遅いので調べてみた。
現象
Load Averageはほとんど上ってないのにIdleからの復帰が遅い感じ。
vi コマンドなど叩くとviが起動するのに30秒ぐらいかかる。
実行中のプロセス自体は遅いと感じた事はない。
新しいプロセスを作るのが遅いといった感じだろうか。
現状
Serversman
今日から初めるGist.vim
みなさん github は使っていますか？
github でソースコード管理はいまや定番ですが、github で管理するほどでもないしそもそもコードじゃないような物は gist で管理しているのではないでしょうか。
gist はちょっとした使い捨てコードや irc ログを貼りつけるにはベストなサービスで Limechat から POST する事だってできます。
しかし、そんな使い捨てコードを貼るためにいちいちサイトまで飛ばないといけないのも面倒臭い。
gisty で管理するのは大袈裟だしあれ使いにくい。
なにかいいのないかなーと思っていた所みつけたのがコレ！
Gist.vim
名前の通り vim から Gist を扱うための vimscript で public/private での POST から User 指定での Gist の閲覧まで可能とする vimmerには嬉しい機能がもりだくさん！
使い方は簡単！
Install
Vundleを使いましょう.
~/.vimrcに以下を記述
Bundle 'Gist.vim' " for Gist.vim :let g:github_user = '***' :let g:github_token = '****************'
そしてインストール実行
:BundleInstall
Post
現在開いているファイルを Gist へ public で Post する時は
:Gist
private で Post するには
:Gist -p
教えて！
一通りはやりたい事ができるのですが、Gistの編集のやり方がわかりません。
みんなも Gist Life を Enjoy しましょう。
*1:ためしてみた所うまくいきませんでした。
CodeEval で遊ぼう
みなさん CodeEval やってますか？
CodeEval とは企業がプログラマ採用するにあたり事前にコーディング技術を評価する事ができるような指標となってくれるサービスです。
中身はというと3つのランクからなるコーディング問題が約40問あり、それに回答していく事で自分のランクが決まっていきます。
問題の中身もさまざまで、有名な FizzBuzz から暗号の複合化まで様々です。
選択する事のできる言語は
- Python 2.6
- C 4.3.4
- C++ 4.3.4
- Java 1.5
- Ruby 1.8.6
- Perl 5.8.8
- Php 5.2.6
- Tcl 8.5
- Clojure 1.2
- javascript 1.8.5
となっています。
全体的にバージョンが古めなのは何か理由があるのでしょうか？
問題を選択すると直接 TextArea にコーディングするか又はプログラムファイルをアップロードするか選択する事ができます。
POSTしたプログラムは Submitted -> Execution と進んでいき Worning や Error を吐いた場合は Fail, 正常にテストが実行完了した場合はComplete が表示されます。
Complete まで進むと実行されたテスト結果によってScoreが与えられます。
全てのテストが通れば 100.0 となります。
現在は参加人数も少い事もあり18問解いた段階で45位となっています。
Easy 問題は1問5分もあれば解けるのでちょっとした休憩や頭の体操にいいかもしれません。
全体的に short Code で書けるので Code Golf 的な遊びをしてもいいかもしれません。
チャレンジして1位を狙ってみましょう！！
hatena.vim を使う
Install
Vundle を使いましょう。
Vundle については blog.shu-cream.net: 2011年のVimプラグインの管理はVundleで を参照
.vimrcに下記を追加
Bundle 'motemen/hatena-vim'
vim のコマンドモードでインストールを実行
:BundleInstall
hatena.vim の使い方
:HatenaUser usere
使用するユーザ名を指定します。
もしくは .vimrc に下記を記述します。
" for Hatena.vim :set runtimepath+=$HOME/.vim/hatena :let g:hatena_user='naoSora'
:HatenaEdit
記事を書きます。
最初にいつの記事を編集するのかを日付で指定します。
:w で記事を POST します。
help
詳しい使い方は ~/.vim/bundle/hatena.vim/plugin/hatena.vim に載っています。
Manual Version Control による資産管理
MVC の利点
MVC は考え方でありシステムの名称ではない。
しかしその思想はあらゆる OS に組み込まれており実装されている。
またこれまでのバージョン管理とは異り変更前にバージョンを上げる事が可能となっている。
MVC による分散ディレクトリ
MVC は高度な分散ディレクトリ構造となっている。
分散ディレクトリの概念では trunk/branches のディレクトリというものはなく全てのディレクトリが trunk であり branches なのだ。
MVC の親子関係
MVC ではバージョンが上る毎にディレクトリにバージョン数を記述する事になっている。
特定のバージョンのディレクトリから枝分れする場合は元となるバージョン番号と枝分かれしたバージョン番号の両方が記述される*1。
あらゆるバージョン管理システムは MVC により管理される
今一番熱いバージョン管理と言えば git だろう。
またエンタープライズの現場では svn や cvs がメジャーである*2。
しかしどのシステムを使用したとしても最終的には MVC によって管理されているのだ。
例えば git では分散リポジトリの概念によりリポジトリがローカルにコピーされる。
そのコピーされたリポジトリは HVS や MVC の思想に準拠したプログラムなどによって外部記憶媒体に移されるだろう。
HVS でのバージョン管理の仕方
1. 対象ファイルを選択
2. Ctrl + c
3. Ctrl + v
とする事により「コピー 〜 hoge」*3というフォルダが生成される
そのまま新しいディレクトリ(バージョン)を作成する度に「コピー (2) 〜 hoge」*4などディレクトリの名称にバージョンが記述される。
MVC で気をつけるべき事
MVC はとても自由度が高い為、様々な拡張がされて使用される事が多い。
ディレクトリ名に日付を入れたり、最新などとタグを付けたりする習慣のプロジェクトもよくあるが、徹底して管理しなければ複数の最新タグがついたディレクトリなど混乱の原因になってしまう。
Javaでシステムコール
仕様の都合上、どうしてもサーブレットからシステムコールしてbatchを叩かないといけなくなりました。
しかもサーバのOSはwindows。
batchの内容は同一LAN内のDBサーバにあるexeを叩くというだけのものです。
batchの中はよくわからないのですが、PsToolsとかいうリモートアクセスツールを使用しているみたいです。
さてJavaでシステムコールをする時はいくつか方法があると思いますが、今回は「java.lang.Runtime#exec」を使用しました。
public class foo { public void bar(){ Runtime runtime = Runtime.getRuntime(); Process process = runtime.exec("c:/foo/bar.bat"); process.waitFor(); } }
最初、上記のようにしていましたがいくらまっても「waitFor()」から復帰しない。
しかしbatch自体は正常終了しておりリモートのexeも実行されています。
色々調べてみるとProess#getInputStreamのbufferが512バイト以上になると終了コードを取得できずにタイムアウトになるという情報がありました。
dfltweb1.onamae.com – このドメインはお名前.comで取得されています。
しかしbar.batは「@echo off」にしているため512バイト以上はなっていません。
関連してProcess#getErrorStreamも取得しないとプロセスが終了しないという情報を発見
しかしこれもハズレ
getErrorStreamで取得したInputStreamインスタンスをBufferdReaderに食わせてwhileでreadLineしているとやはり止る
ハマったかと思ってた所でcmd.exeで実行すればいいという情報を発見
http://oshiete1.watch.impress.co.jp/qa3730481.html?ans_count_asc=1
cmd.exeで実行する事によりシェルの終了が無事取得できました
public class foo { public void bar(){ Runtime runtime = Runtime.getRuntime(); Process process = runtime.exec("cmd.exe /c c:/foo/bar.bat"); process.waitFor(); } }
windowsのシェルの概念がわかっておらず、batchを叩けばシェルで実行されると思っていましたが違うようです。
しかしGoogle先生に頼ってばかりでひどい事になっているのでもう少しJavaの深い所も勉強しようと思いました。
