リファクタリングの練習問題がやっと完成

苦労して作っていた、
1200ステップ、サイクロマティック複雑度328の、
保守不能なC関数がようやく完成。

保守不能なプログラム

プログラム始めてすぐのころから、
メソッドは10行以下を心掛けてきていたので、
こんなに長い関数を書くのは初めて。

こういうのは天才しかできないものかと思っていましたが。
私にもやればできるものですねえ。
自分を見直しました。

とまあ、別に自画自賛するためにプログラムを作っていたわけでもなく。
リファクタリングの練習問題が必要だったので作ってみました。

リファクタリングというのはある程度ややこしいプログラムを組む時に特に役に立つもので、
その学習をするときには複雑なプログラムがあったほうがいいです。

実務でそういう保守不能なプログラムを作る人はいるのですが、
その場合は単体テストがなかったりしてまた練習用には向いていないというジレンマが。

それでなかなか実用的なリファクタリングの学習を広めることが難しかったので。
保守不能なプログラムを作っていたわけです。
ということで単体テストもついています。

単体テスト

なんか作っていて泣きそうでしたが。

Cの範囲で作って、かつ関数分割をしないという縛りのほかは、
なるべくきれいに書いたのですが。

まあ何とか完成。
と言って問題を作ったら今度は回答も作らねばならないのですが。
とりあえず問題だけ同僚に渡しておきましょうかね。

ああ疲れた。

老害になるのは避けたいものだ

先日、数年ぶりに若い人と一緒に仕事をする機会があったのですが、
なんか恰好を見て、その恰好で仕事をしていていいのか、とか思ってしまいました。

大変嘆かわしい。
いや若い人じゃなくて私が。

自分は、最近の若い者はとか言うようなキャラじゃなかったと思っていたのですが。
40前にしてもう言いたくなるとは。

というかそもそも別に自分だってパリッとした恰好をしているわけでもあるまいに。

人間だれしも年をとるとそういいたくなってくるような精神に近づいていくのですねえ。
これはもう髪が白くなるのと同じと考えるべきか。
なるべく食い止めるように気をつけねば。

まあ、２時間もすれば慣れてきたので、まだセーフといったところですが。

いや格好については、思わず口走っても、
単に若い人に嫌われるおっさんというだけですけれど。

そういう精神的傾向は、技術分野の学習に悪影響を及ぼしますし。
定着したら老害一直線。
極力そうならないように気をつけねばならないと思います。

「初歩からわかるAndroid最新プログラミング　増補改訂版」を読んで

カバー裏の説明に「基礎をおろそかにせず」とか書いてあったので、
それを期待して買ったのですが。

あまり基礎から詳しく説明してある本でもないようです。
どちらかというと、写せば動くようなコードを載せ、
初心者でもアプリが動くところまでたどり着けるというのを目指した本ですね。

そういう本としては、
今でも新しめの環境に対応した説明が載っていて、
加速度センサーやOpenGLまで動かし方がわかり、
楽しく学習できる本に仕上がっているのではないでしょうか。

こういう本は賞味期限が短いでしょうから、
買うなら早めのほうがいいですね。

POH3に挑戦してみる

paizaさんのPOH3に参加してみる。
https://paiza.jp/poh/kirishima

アルゴリズム問題というのは基本的にそんなに得意ではないですが、
少しノウハウを調べてやってみたらギリギリSはとれたのでまあよし。
ナップサック問題の変形らしいですね。

ただし、C#でラムダ式を使うと、処理速度が少し落ちてSが取れなくなります。
速度を目指すわけではないので、ラムダ式で美しく書けないとあまり面白くない。

もうちょっと選択肢を刈り込まねばならないのでしょうが。
そこはちょっと難しいかなあ。まあもうちょっと考えてみます。

SpreadsheetAsDataをやっと復旧する

使っていたziprubyのgemがruby2.0に対応していないため、
長らく放り出してあったSpreadSheetAsDataをようやく復旧しました。

使っているライブラリをrubyzipに変更。
ただし、書き込み機能は動かなくなっていますが。

とりあえず動くようになったのでやっと先に進めるかな。

C#版のパーサーコンビネータは無理だなあ。

昔から構想を練っていたC#のパーサーコンビネータなのですが、
C#では演算子のオーバーロードでジェネリックが使えないので、
Parl6やboost::spriitのようなBNFライクな記法を再現するのは無理っぽい。

dynamicを使えば可能ですが、インテリセンスがないとC#の意味があまりないですし。
他に代替え手段がないのならそれでもいいとは思いましたが、
Spracheという天才的な解法を見つけてしまいましたし。
BNFライクな記法ができるのに比べれば微妙といえますが、C#の範囲内ではあの発想はたぶん最高峰だ。世界にはすごい人がいたもので。

動的言語かジェネリック完備の言語のほうが有利ですかね。
Ruby版に注力しましょうか。
いずれF#版にも挑戦したいが、もう誰か書いているかなあ。

というかしばらくブログをさぼっているので、
前提条件が全く書いてないですな。
Ruby版を進めていたことすら全く書いてなかった。

まあその辺とかSpracheの紹介とかいずれブログに書きましょう。

Android開発を始めてみる

チャットで、一緒にAndroidアプリを作らないかと言っていた人がいたので、
作り始めてみました。

勉強するとしたらJavaFXがきちんと対応してからにしたいと思っていましたが。
なかなか対応しませんし。
まあ今始めてみるのもいいでしょう。

私はJavaもAndroidもほぼ初めてで、相手はプログラム初心者。
まあどうなることか。やってみよう。

C#でパーサーコンビネータを実装中

プログラマーを始めてから、
C#での構文解析ライブラリは何度か挑戦しています。

今度こそ決定版を作ろうとやり始めたのですが、
早々に行きづまりました。

まさか、演算子のオーバーロードにジェネリックが利用できないとは。
C#は実用的にはC++よりかなり使いやすいですが、
すべての要素が直行している美しい設計、とか言い出すとC++に劣りますね。

だから誰もBoost::Spiritに匹敵するようなものをC#で作っていないのでしょうか。
いくつか有名なライブラリは出ているのですが、そんなにすごいものではない模様。

まあ、作り始めたので現在私にできる限りの決定版は作ってみましょうか。
あるといろいろ便利ですしね。

現状だと動的性質が強いものになるので、前回に作ったのとあまり変わらないかな。
まあできるだけ便利にしてみましょう。