るびまゴルフ 【第7回】 ― 2009/09/14
やはり、6回の解答でまっとうなものは23Bが最短で良いみたいだ。
今回のお題は
るびまゴルフ 【第7回】 一行の英単語が標準入力から与えられて、その末尾から 1Byte ずつ伸ばしていく形で文字数分の行を出力して下さい。具体的には hoge という入力に対して e ge oge hoge と出力して下さい。入力は末尾に改行があるとしても無いとしても構いません。
正規表現を利用したループ制御の問題だと思う。 だから、「入力は末尾に改行があるとしても無いとしても構いません。」になる。 (正規表現の$は改行の前にマッチするし、putsは末尾に改行が無ければ追加してくれる)
とりあえず24B。 この方針だと多分これで最短だと思う。
(訂正)23Bになった。そうか、制御構文に渡すときはナニがナニと扱われるのか……。
[あなごる] Negatenary ― 2009/09/14
抜かれていたので少し考えた。
Statisticsの差からして、括弧の省略の問題なのはほぼ明らかなんだけど、この括弧は省略できないものと思っていた。 思い込みは恐しい。
というか、この括弧は1.8.5だと省略できないのは確認していたんだけど、実は1.8.7では省略できるのであった。
この間のどこかで、構文解析規則が変わったようだ。
具体的には
method_a((a+b).method_b)
から括弧を省略しようという意図で
method_a (a+b).method_b
と書いた場合
1.8.5では
method_a(a+b).method_b
と解釈され(*)method_aの戻り値に、method_bを適用することになっていたのだけど、1.8.7では意図どおりの動作をするようになっている。
(*)そして、'warning: don't put space before argument parentheses'のwarningが出る。
るびま#27 ― 2009/09/14
ここ数回は記事が寂しい感じがしていましたが、今回は充実しています。
VBA より便利で手軽 Excel 操作スクリプト言語「Ruby」へのお誘い (前編)
そろそろ、Excelのセルの値を操作するためにWIN32OLEライブラリを使用する記事は 止めにした方が良いのではないかなと思う今日この頃。
セルのフォーマット(フォントや配色、罫線など)を操作する必要があるなら、 今のところWIN32OLEが適切な選択ではあると思いますが、値を操作するだけで良いなら Spreadsheet このブログの記事 を使用するべきだと 思います。
- xlsxフォーマットには未対応
- 統合セルの中身にはアクセスできない
という問題点がありますが、既存のフォーマットが崩れたりする問題は(今のところ自分の環境では)ありません。 これらのデメリットに対して得られるメリットは、なんと言っても速いということです。
特定の数セルを読んで更新するぐらいならWIN32OLEでも問題ないのですが、数百行~数千行のデータファイルをxlsファイルで受け取り、 それを全行舐めてデータ更新をする必要があるような場合、素直にWIN32OLEでWorksheetの使用領域をeachしたりすると日が暮れることになります。
Spreadsheetに出会う前は、WIN32OLE経由でCSV/TSVに変換してそれをパースとかしていましたが、これは余分な手間だし、更新はやっぱりどうしようもないとか、 色々面倒臭かったです。
あと、WIN32OLEでは、Rubyが明示的なデストラクタの構造を持っていない関係かもしれませんが、OLEで接続したプロセスをRuby側から殺す方法がありません。 気付かず、どんどんプロセスを生成しているとプロセス数が50ぐらいになったところで落ちるはずです。 このあたりも、ちょっと初心者向きではないと思います。
ActiveLdap を使ってみよう(前編)
一年前にこの記事があれば……。
後編も期待。
Ruby から DirectX を扱う簡単高速ゲームライブラリ DXRuby の紹介
昔、頓挫した何かに再チャレンジしたい気がした。
最近のコメント