2015年8月15日

ソフトウェアの開発プロセスにおける大切な概念の一つ

トップダウン、ボトムアップの思考法
トップダウンに関しては関わるプロジェクトの規模に依存するが、だいたい中規模のプロジェクトになった辺りから特にトップダウンでの能力が問われるのではないかと
逆にボトムアップは関わるプロジェクトの規模に応じないでまんべんなく必要とされる能力だと思う
プロジェクトが小さいうちはボトムアップのみで対応可能なものが多い、トップダウンは必要とされない、出る幕がない
しかし規模が大きくなるにしたがってトップダウンの能力が問われるのでは
一般的に技術者と呼ばれる人はボトムアップからの流れは得意な人が多いのではないかと
どちらが重要というのではなく両方必要
ただしどちらが得意かは人それぞれ
両方の特徴を最適に活かすことができれば素晴らしいものが作れると思う

練習方法としては、先ずボトムアップでやってみてからの結果を眺めて結果こういう形になるようにトップダウンを行えばいいんだなとかやる方法か
何回も何回もボトムアップでやってみて結局出来上がった形からトップダウンの姿を眺めておいて、それを糧にトップダウンから始めた場合のゴールを体感しておくことか

個人的にはボトムアップは苦手
トップダウンが良い
ボトムアップが苦手というか実際の手続きを作る作業が苦手

規模が大きい場合、あるいは将来的に向かう方向が決まっていて段階的にリリースしていく場合トップダウンで事前に準備しておくことが不可欠ではないかと
でもそんなことないかな、今の段階でリリース予定でも本当にリリースするまでその機能が必要とされるかどうかはわからないからね
そのために無駄な準備をしておくこと自体不毛、特に自分は決定権がないプロジェクトの場合はモロ当てはまりそうだな

あとボトムアップで作るならコンパイラが必須のような
コンパイラ使ってリファクタリングしまくってやらないとね
そうしないと作業が遅々として進まないから
コンパイラって言うか静的型付けと言いたいのだ
しかしcommon lispは動的型付けなんだよな
例えばhaskellなんかだとボトムアップに向いてるんだよな
javascriptだとさリファクタリングしにくいったらありゃしないよね
関数に引数追加、変更したりしてもjavascriptだと例えば引数渡されてなかったらどうこうするって記述になるのかな
haskellとかだと関数のプロトタイプ変更してもさ、コンパイルエラーの箇所を変更すればいいからね、楽だよね

二項演算子って言うもの自体

この世には不要な概念、余分としか言いようがないよな
大体さ、「二」項演算子って言うのがムカつく
コンピュータサイエンス的には「n」項演算子って言う方が絶対しっくりくるはずだ

2015年8月1日

google app engine on linux

開発環境をダウンロード

Pythonインストール

開発環境解凍

パスを通す

開発環境を解凍した場所にプロジェクトフォルダを設置--a

開発環境を解凍した場所でdev_appserver.py [.yamlがあるフォルダ名--a]