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

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

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

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

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

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

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

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

google app engine on linux

開発環境をダウンロード

Pythonインストール

開発環境解凍

パスを通す

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

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

common lispのfとgの違い

次の関数fとgの違い

(defun f()
  (let ((i 0))
    (lambda()
      (prog1
 i
 (format t "lazy call ~A~%" i)
       (incf i)))))

(let ((i 0))
  (defun g()
    (lambda()
      (prog1
 i
 (format t "lazy call ~A~%" i)
       (incf i)))))

(let ((a (f))
      (b (f)))
  (dotimes (i 10)
    (format t "~A ~A ~A~%" (funcall a) (funcall b) (funcall b))))

(let ((a (g))
      (b (g)))
  (dotimes (i 10)
    (format t "~A ~A ~A~%" (funcall a) (funcall b) (funcall b))))

fを呼び出すと、呼び出すたびにlet iが実行されて新しいiが生成されるってことなんだろうな
そんでfの中のlambdaは都度生成されたiを参照するようになるということなんだろうな
多分そんな理解でいいんじゃないかなと思います

あと、common lispでできるか不明だけどマルチスレッドの場合prog1で囲った部分を排他できるとなお吉ではないかなと思います

問題のスモールステップ意味論、ビッグステップ意味論

に関してです
スタックを消費してもいいから計算をなるべく簡約したい場合はビッグステップ意味論が適している
スタックの消費がやばい場合はスモールステップ意味論が適している
と言う認識でいいのだろうか
で、具体的にどちらがどんな場面に向いているかと言うことなんだよな
普通にビッグステップ意味論だけでまかなえそうなんだけど無理なのかな
スタック、と言うかramが少ない昔のコンピュータはスモールステップ意味論の方が向いているような気がするけどfortranなんかだとスモールステップ意味論で構築されているのだろうか、あとcobolとか
でもlispは絶対ビッグステップ意味論でやっている感じがするな
あの簡約のしかたは完全にlispの流儀に沿っている気がするので

dvorakの代替案

と、言うわけでdvorakもqwertyもどっちもイマイチってことになったので最適な案を考えてみたいと思います
って言うか「qwerty vs. dvorak」って言う対決の図式がそもそもおかしい、別にどっちも最適じゃないと思うので
ですが、とりあえず前提条件としてqwertyのレイアウトを元に新たなキー配置を考えてみたいと思います
新たなキー配置をゼロから考えられる状況じゃないので、現在qwertyがこれだけ優勢な状況にある事実を真摯に受け止めてそこから最適なキー配置を考えたいと思います

・一段目はそのままにする(記号も含めて)
・記号はそのままにする([];',./)
・アルファベットのみ置き換える
・置き換える際、できるだけqwertyと合わせる(q、zあたりはそのままにする)
dvorakの失敗はこれらの点にあると思うのですよ
あまりにも理想を追求しすぎたと思う
まあ、当時の状況では仕方がないことかもしれないけどdvorakさんはqwertyの趨勢を読み間違えてしまったからではないかと思う

[qwerty配列]
qwertyuiop[]
asdfghjkl;'
zxcvbnm,./

[dvorak配列]
'<>pyfgcrl/=\
aoeuidhtns-
;qjkxbmwvz

[qwerty-dvorak配列]
qwdrfjyklp[]
aoeuihtns;'
zxcvbgm,./

技術の寿命について

ソフトウェアの世界に身を置いて「数」十年経過したと言えるレベルには達していませんが数十年達しようとしている今、感じることが多くなったこととして、ソフトウェアの寿命は意外と長いということがあります
「寿命」と言う用語について説明を補足しておくと、想定より長い期間有用であり続けてくれて大変助かりました、とは逆に、意外とコイツ長い事使わないといけないなって言う意味での寿命ということです
仕事していて良く思うのですけど、「コノクソプログラムをまだメンテナンスしていかないといけないのか」とか「2015年にもなってまだこんなもん使っているとは2005年の頃には思いもよらなかった」ってなるんですよ
ソフトウェアって実物が無いだけに変更、入れ替えが簡単みたいな触れ込みが大学の授業とかであったような記憶がうっすらあるんですけど、あれ絶対ウソだな
実物が無いソフトウェアなんかより実物があるハードウェアの方が絶対入れ替わり早いと思うな
携帯電話とかそうなんですけど、数世代前の機種って異常に古臭く感じますよね
初代iモードとかj-skyとか謳っていた機種の古臭さと言ったらわかってもらえますか
ハードウェアってものすごい勢いで入れ替わってると思うもの
まるで、若者の代謝のよう、その点、ソフトウェアって完全にオジイの代謝っていうくらい全然入れ替わらないですね、代謝が悪すぎる
だからと言ってソフトウェアの代謝を高めるためにどうすればいいかと言われてもまあ困るんですけど
と、言うわけですがこれからは、ソフトウェアの選別時において寿命は意外と長いぞと思って臨もうと思います

プログラミングコンテストについて思うこと

いまさら言うまでもないけど、プログラミングコンテストはあくまでもプログラミングコンテストドメインに特化した能力だよな
問題解いていて面白いと言えば面白いのだけどね
まあ、でもその辺りのしょぼい二流、三流プログラマで成り立っているいわゆる「システム開発」「アプリケーション開発」とか募集している会社だったらプログラミングコンテストで良い成績を残せる、と言わないまでも正解を提出できるレベルだったら間違いなく有用なことに違いはないと思うけど、やっぱり採用ツールとして見るとプログラマを募集している職業の求人ツールとしてみるとどうなのかな
会社が、自分の会社にあった問題を掲載して、その問題に対する姿勢で会社として雇っていいかどうか判断しないとダメだよな
でもfizzbuzz程度も満足に書けない人達で成り立っている会社だったら別にどんな問題でも解答できたら即採用候補ってことでもいいかもしれないけどね
就職先を探すために利用するの諦めようかな
なんか仕事探す良い方法ないかね
なんとかナビとか普通の求人サイトに載っているような求人なんてどうせイマイチな会社ばっかりだからあんなもんで仕事探したくないんだよな

たまには豆知識

'aは(quote a)の代わり
リードマクロで実現されている

quoteと言う関数の存在が普通の人にとっては、先ずよくわからない点だろうな

こいつの素晴らしさと言ったらないのだけど

lispの沢山ある良いところの一つ、だったらこんなんで良くね？って感じであっさりとスゴイ斬新な機能を実現しているところだね

へんな名前の関数

nconcはなぜこんな変な名前になったのだろうか
appendの非破壊版とはとても思えない命名
先頭の「n」で破壊版関数を表現して、多分そのあとにはconcatenateが続いていると思うのだけど、concatenateとappendって英語的には大体同じような意味なのかな
素人目にはnappendで良かったような気がするけど
しかし、このあたりもマクロを利用すればなんの障害もなく覆い隠せるからlispはすごいな

common lispに対する偏見

S式が苦手
ポーランド記法が受け入れ難い
見かけがとっつきにくい
って言うか括弧が多いよね
なんか変だよね

マクロの威力を活用できていない(高階関数が利用できれば十分なレベルでしか利用できていない)

確かに括弧にもいろいろな意味があるので一概に()で対応するのは微妙かもしれませんね[]{}も利用できるならそれに越したことないかも
別にソースコードの表記上[]{}が利用できるだけで()と同等に扱われるで問題ないのではないかなと思います

オブジェクトのアクセサの表記は大賛成ってかこれがないからCLOS使いたくないかな

関数名と変数名の名前空間が分かれているのは好意的だけどな
しかしfuncallは勘弁って感じなんだよね

括弧は補助記号との認識が強いから受け入れられないのか

condは括弧が多いから鬱陶しい
少し括弧を減らすことはできないかね
って言うかいまの括弧が最適なのか、これ以上は無理なのか

setfとsetqの違い

一言でいうとsetfはsetqの一般化
setfの第一引数がシンボルならsetqにそのまま展開されるだけ
第一引数が式なら対応する式へ展開される

lispの括弧の扱いについて

って言うか、演算子の優先順位とかブロックとかでどっちにしても括弧が必要になるから別に最初から括弧だらけのLispでいいんじゃね
と思いますが、こう思うようになったら重症なんだろうな

だってさ例えば

ある変数が10 < a < 15の範囲にあるかどうか判定する場合とかだと

if ((a < 15) && (10 < a)){

文ブロック

}

else {

}

ってなコードになる訳でさだったら

(if (and (< a 15) (< 10 a)))

って言うのでも別に全然違いがないと言うかそう大きな違いが無いと思うのだけど

lispと言えばとにかく括弧と言う印象をもたれがちですけど、この括弧の扱いが逆にマクロとかで生きてくるんだけどな

逆に括弧で成り立っているからこその良い側面があるのだけど

と言い出したら「ああ、こいつはいわゆるlisperだから相手にすると大変なことになるからかかわらないでおこうと」と思われるのだろうな

キーボード配列QWERTYの謎

dvorakさんが意外とインチキ系だったって言うのが一番の収穫かな
二番目はqwertyの市場原理で良い物が市場を独占できるわけじゃないって理論も別に正しくなかったってところかな
結局どんな配列が効率的なのかよくわかんない
って言うかなんでこの配列になっちゃったかは結局キーボード入力とはまったく関係ない筋道だったと言うか、コンピュータのキーボードを微妙に関係ないタイプライターをもとにしちゃったのが不幸の始まりなんだろうな
入力装置のことをあまく見た結果なんだと思う
あと、石田晴久氏なんかも都市伝説の流布に一役買っていたって言うのが以外でした
得られた教訓としては一次ソースをあたれってことだよね

linux mintでgnuplotを利用する

apt-getでインストールしてターミナルからgnuplotで起動すると

Terminal type set to 'unknown'

と表示されてgnuplotが正しく動きませんでした

解決策は追加でgnuplot-x11をインストールしました

sudo apt-get install gnuplot-x11

無事実行できるようになりました
やっぱり数値データだけ見てても面白くないね
視覚化されるってやっぱり重要だな
なんだかんだ言ってもcuiには限界がある
guiの限界の高さは伊達じゃないな

積んである本について

減らしましょう

アンダースタンディングコンピュテーション
プログラミング言語C++
人工知能の基礎
関数型プログラミング珠玉のアルゴリズム
On Lisp
LET OVER LAMBDA
数学で織りなすカードマジックのからくり
Vim scriptテクニックバイブル
リファクタリング新装版
コンピュータ囲碁
すごいErlangゆかいに学ぼう！
エリック・エヴァンスのドメイン駆動設計
入門データ構造とアルゴリズム
プログラミング言語AWK
 Haskellによる並列・並行プログラミング
ピープルウェア
アルゴリズムパズル
コンパスと定規の幾何学
抽象によるソフトウェア設計
関数プログラミングの楽しみ
Real World Haskell
Erlangプログラミング
ヘネシー＆パターソンコンピュータアーキテクチャ
シューティングゲームアルゴリズムマニアックス
型システム入門
ユークリッド原論

pc買い替え

ASUS
B85M-G
core-i3 4160
intel ssd 530 series 120GB
システムメモリ4Gx1

マイナビやっぱりスゲーや

ソフトウェア業界特集
最新用語集
http://job.mynavi.jp/conts/2016/tok/p/189/

「最新用語集」と謳っちゃってるところが味わい深くさせるポイントですよね
個人的に気に入った用語をいくつかピックアップします
この辺りのセンスでその人の特徴が掴めそうですが
感覚的には一発当ててから業界から消え去った有名人と言ったところでしょうか
「あの人は今」的な

シンクライアント
いつの時代の用語だよ

オフシェア
しばらく聞かない用語だな

グリッドコンピューティング
たしかに聞いた覚えがある

このページの一番の見どころはJava、C言語、C++、COBOL、FORTRUNが連続で登場するページ最下部ですね
ここは非常に味わい深い箇所ですね
フォートランなんてスーパーコンピュータで使われているって断言しちゃってる始末ですし
このページの内容って二十年くらい使いまわされてる内容とかも混ざってそうなんだけど
コボルとフォートランなんて名前がでてくるだけでも十分笑いが取れる、出オチの域に達しておられますからね
C++の説明も、オブジェクト指向って言うよりもジェネリックプログラミングの方が全然有用だと思うのだけどまったく触れられていない始末です
スゲーな、さすが天下のマイナビ様だな
マイナビから募集するとこんな最新用語を把握されている方達と接触できるのか
まあでも今の管理職辺りにはウケそうな用語をあえて狙って掲載してるのかもしれないけどね
しかしスゲーな

新卒学生だとこの手の情報を真に受けちゃう人っているんじゃないの
って言うか今時の大学でプログラミングってやっぱりいまだにフォートランやってるのかな
今だったらJava教えてるところとかありそうだけど
やっぱりなんだかんだ言ってもC言語が本命なのかもね

こういう就職斡旋業者って結局この程度だと思うとこういうサイトを利用して仕事探そうなんて気が失せるよね
逆にマイナビに掲載していないことを強みにできるのかも
あるいは、掲載依頼する企業側も閲覧する側もこの程度のレベルでお互い釣り合いが取れて均衡が保たれていることは丸く収まっていいことなんだろうな
結局こういうサイトから応募して就職できた人が今度は採用する側になってっていう繰り返しが行われるんだろうな

アンダースタンディングコンピュテーションの感想の続き4

なんとか読み進めています
内容は個人的にはなかなか面白いし、興味深い分野ではあるのだけどこれが実際どう活かせるかよくわかんないよな
あと、そのへんのアプリケーションエンジニアにとってこのような内容が必要なのかと言われるといわゆる「プログラマ」には不要、とまでは言わないけどこんなことやっててもあんまり意味無いような気がするので需要は大変少なそうですね

コンパイラ作ったりする人たちにはとっても有益な、必須な内容だと思うのだけど別に誰かが作ったOSで、誰かが作った開発環境で、誰かが作ったライブラリで誰かが作ったソースをコピペで作業している人にはまったく不要な内容なんだよな
この本の内容を理解して実務に取り入れられるような会社や仕事ってどこにあるんだろうね
webでmvcとか必要な場合とかこんなことが役に立ちそうなんだけど
というかこの本の内容の知識がないとまともなmvcとか作れなさそうなんだけど
あるいはphpとかで適当なmvc作る程度だったら別にどうでもいいのかもしれないけどね

でも、今どきプログラムとか業務で行っている会社だったら自社DSLとか構築していると思うのでやる気になればどの会社でも活かせるって言えば活かせるか

あとはやっぱり結局人間次第ってか

挫折した本について

http://shop.ohmsha.co.jp/shopdetail/000000004066/
久しぶりに挫折した本
とにかく難しい
何が書いてあるかさっぱり意味不明
と言うとちょっと言い過ぎですけどまあ難しいな
挫折した

と言うことで挫折記念にいままで挫折した本の紹介
コンピュータプログラミングの概念・技法・モデル
http://www.shoeisha.co.jp/book/detail/9784798113463

On Lisp
LET OVER LAMBDA
コンパスと定規の幾何学
実用Common Lisp