google app engine dbからndbへ移行メモ

dbからndbへ移行した際に実際に変更した箇所

上がdb、下がndb
しかし、こんなにも簡単に移行できるなんて素晴らしい対策をしてくれて感謝ですよね

all

query

run

iter

str(model_instance.key())

model_instance.key.urlsafe()

db.get(key)

ndb.Key(urlsafe=key).get()

row.delete()

row.key.delete()

filter('property in', [])

filter(Model.KeyProperty.IN([]))

db.StringProperty()のmultiline削除

db.ReferenceProperty()
ndb.KeyProperty()

db.StringListProperty()
ndb.StringProperty(repeated=True)

db.LinkProperty()
ndb.StringProperty()

db.BlobPropertyにpickle.dumps({})を代入する時、db.Blobオブジェクトにして
db.Blob(pickle.dumps({}))としていたものをdb.Blobを削除してpickle.dumpsしたものをそのまま代入

order('-date')とかを
order(-Model.KeyProperty)

db.ListProperty(db.Key)
ndb.KeyProperty(repeated=True)

javascriptにあるcall,applyについて

なんでこんなものが用意されているか意味不明なんですけど、これってcommon lispのfuncall,applyと似ているのだけど、だとしたらjavascriptにcall,applyは不要って言うかそんな気がするのだけど
common lispになぜfuncall,applyが必要なのかと言うと名前空間が変数用と関数用で分かれているからで、名前空間の扱いがscheme系のjavascriptではfuncall,applyが不要なんじゃないかなと

そもそもjavascriptって言語仕様がschemeっぽいけど、schemeにもfuncall,applyってあるんですかね
少し調べてみましたがやっぱりschemeではfuncall,applyが不要なのでそもそも存在しないっぽいのだけど

しかし、call,applyとは直接関係ないけど、この件でjavascriptのことを検索してたけど、出てくるもの、酷いものが多いな
クラス的と言うかオブジェクト指向の使い方の勘違い方も酷い例が多くて、これら記事を見てjavascriptで一歩進んだプログラムを書いてみたいな、なんて思ってる人達が混乱すると思うのだけど
混乱するって言うか、故意に不用意にプログラムが複雑化するだけで、ややこしくなるだけで、良いことなんてないのだけど、こういう複雑で理解しにくいプログラムが書けるって一歩上達したとか思っちゃうのかな
実際は全然上達してなくて迷惑なだけなんだけどな

Pythonでハマった件

変数のスコープでハマった

例えばこんな感じのコードで
row = #データベースから一行取得したもの---1
entrants = #データベースから複数行取得したもの
entrantnames = [row.name for row in entrants]
#とすると1のrowが上書きされてしまう

rowがリスト内包表記内のみで有効な変数だと思ったら、リスト内包表記のその側の変数を上書すると考えもしずハマってしまった
Lispのようにブロック毎に変数のテーブルが生成されるのかと勝手に勘違いしてしまった
まあ後から冷静に考えたら1のrowはもっと後で利用するんで、1の文自体をもっと後に、今回は上書きされてしまったリスト内包表記の後に記述するべきで、そうすれば変な上書き問題も発生しなかったのかなと思います
やっぱり変数は利用する直前で記述するべきですね

HyperDev

fog creekからHyperDevと言うWebアプリが発表されています

https://hyperdev.com/about/

内容はほぼGoogle App Engine、Windows AzurでPaaSって言うんですかね、ウェブサーバーとかOSとかまったく意識しなくてもいいって言うやつね
って言うか内容はほぼApp Engineなんだが
オンラインでソースコードが記述できるんで、App Engineとの違いはデプロイしなくてもいいっていうところかな
そんでもデプロイしてでもローカルで開発したいような気もしないでもないけど
あと、サンプルを少しだけみただけなんだけど、永続化がいまいちわかんなかったって言うかグローバルオブジェクトがそのまま残るみたいでして、これがうまい事クエリとかできるんだったら結構面白いかも
データベースとか意識しないでORマッパーとかもイチイチ意識しなくてデータベースがオブジェクトとして扱えるみたいで、LINQみたいなものがあればなおいいんじゃないかなと思った
データベースを激しく利用しないけど、少しだけ永続化は必要って言う場合には最適だと思うけど、データ量が多くなってきた時にどうなるかはちょっとわからないかな、未知数
まあ、なんかデータベースの途中から切り出すような操作は絶対用意されていると思うんだけど

あとこういうのを「full-stack web apps」と言うんだと言うことが分かった

AWK基礎

$0 行全て
$1,$2... 空白、タブ区切りの「欄」
パターン {アクション}の組み合わせ
基本入力行1行ずつ走査する、パターンに適合する行に対してアクションを行う
パターン、アクションどちらか省略できる
$ awk 'プログラム' 入力ファイル群
$ awk -f programfile 入力ファイル群
数と文字列　二つの型のみ
{ pring $1,$3}　特定の欄の印字
1行読みその行を欄に分解する

NF 欄の数
{print NF, $1, $NF} 欄数、最初と最後の欄を印字

NR 行番号

論理演算
&& || !

制御文
if else while for

配列
名前[添字] = 123

コメント
#行末まで

パターン

入力を読み込む前に実行
複数記述できる
BEGIN

すべての入力を読み終えた後実行
複数記述できる
END

比較演算子
比較は文字列にも使える
<
<=
==
!=
>=
>
~文字列照合
!~文字列照合

/正規表現/

式 ~ /正規表現/

式 !~ /正規表現/

正規表現
超文字
\ ^ $ . [] | () * + ?

エスケープ・シーケンス
\b
\f
\n
\r
\t
\ddd 8進数
\c cそのもの

範囲指定
NR==10, NR==20


アクション
print 式の並び
printf(書式, 式の並び)
if (式) 文
if (式) 文 else 文
while (式) 文
for (式; 式; 式) 文
for (変数 in 配列) 文
do 文 while (式)
break
continue
next
exit
exit 式
{ 文の並び }

common lispにおいての末尾再帰最適化

ループで実装する練習中ですが
どうやらclispのlinuxの実装は末尾再帰を最適化してくれているようです
同じ処理をループと再帰で実装したけど実行時間が同じだったという観測結果からによるものですが
言語仕様的には多分common lispでは別にする必要ないというか規定されていないだけなんだろうなと
多分schemeの仕様には末尾再帰を最適化するような記述があるんだろうな

苦手意識からか

関数型を意識しすぎていてループでのプログラミング方法が全くおろそかになっていていまさらながらdoを使うのに非常に苦労してしまっているところがとても歯がゆい
とにかく意味もなく関数型、common lispなのに関数型
どこでだれが言ってたか忘れたけどcommon lispは関数型じゃないって言ってたような
lispって関数型の印象が強いけど印象だけで別に関数型じゃないらしい
末尾再帰も最適化されるわけじゃないみたいだし
多分だけど憶測だけどschemeだったら末尾再帰は最適化されることになってるんじゃないかなと、多分ですが
と言うわけでしばらくループで書く練習に取り組もう
まずはdoが満足に使えるようになることを目指そう

乱数生成のシード

(setq *random-state* (make-random-state t))

を設定すると、起動するごとにrandom関数のシードを設定できる

多分いわゆる現在時刻とかをシードに設定しているのだと思う
指定しない場合、randomは一定の値を返す

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

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

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

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

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

あとボトムアップで作るならコンパイラが必須のような
コンパイラ使ってリファクタリングしまくってやらないとね
そうしないと作業が遅々として進まないから
コンパイラって言うか静的型付けと言いたいのだ
しかし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にそのまま展開されるだけ
第一引数が式なら対応する式へ展開される