mongo

久々でばかみたいなことにハマった。

 スキーマレスなのでこいつはRDBの構造考えずに、プロトフェーズだと

快適に使えるので、結構使ってる。ほいほいと、あれこれ

プログラム上で例えば insert(es,ds)だったやつに、insert(es,ds,fs)ってな感じで

やれば、そのまま動いちゃう。さらに、テストしててDB汚くなってきたら、

Dropして、動かせば、勝手にコレクション作られて動いちゃう。

さてさて、ハマったのは、es=1 といれて、 別のところで es=2 といれて、

最初はfindOne({es:1})が動いていて、別のところから findOne({es:2})で見つからなくて

なんで？ とハマっていた。 よく見てみると、動いていたのがwebからで、動かなかった

のは、swiftからだった。swiftをデバッグしてるとurlsessionのmultipartを

組み立てるとこで、querystringに、ストリングで渡して es='2'が渡っていて、

それが、格納されてた。。バカな話だ。

RDBだと、insert error なんだけどね。

楽な分、気をつけないといけないんだなあと。つでに、mongoにもっと

慣れないといかんなあと。

REST

RESTサーバ作ってました。仕事上大量のファイルをあーだ、こーだと扱わなきゃいけないので、

ワークフローを自動化したかったのが理由です。node angular mongo たしかに、こいつらは楽です。

ファイル中心なので、ファイルにキーだけつけて、それぞれの工程で必要なパラメータは

後でつけちゃう。ファイルが変わってて戻りしたら、パラメータだけは、活用。

なんでも、ござれデス。RDBだと、やりにくいだろうなあ。可変ワールドには、もはやRDB使わんほうがいい。なんて言い出すかも。

バタバタ

バタバタしてました。久々でモダンプログラマーってわけで、

webpackだのnode_modulesなど使っておりました。

ドップリ2週間いじると、さすがに、いろいろ学べますな。

新しい流儀も知って使えるようにしとかないと、剣客は

つとまりません。

本質は一緒なのですが、やっぱり、手を動かせる。というところが

本質でして。

コードを読むのは結構楽でも、いざ、それを書くとなるとちょっと別です。

ここの差がわからんという人が世の大多数であったりもする。

ふと、この世界、eclipseとか、vsとかは、帝国軍で、webpackとかは

共和国なんですかね。es6だなんだかんだ、であるが、こっちの流儀は、

あまり、他人に影響受けずに勝手にモジュールを作るってとこにあるな。

帝国流は、全てを均一のスタイルでやることに、意義を感じてるのと逆かな。

ともあれ

ともあれ、リリース終了。

今回は新しい機能を、調子に乗って入れすぎたかも。

オリジナルのシンプルさが、結構ズタズタになった。

まあ、プログラムちゅうものは、キレイと、ズタズタを繰り返して

リファクタされていくものなので、さもありなん。てこと。

若いこと

なんか、じじいの、たわごとみたいに

なって来たけど。

若い子には、キャッシュメモリー容量が大きいと思う。

じじいの場合、キャッシュが壊れ始めてるので、シグモイド関数が

働きやすくなって、別のものがヒットしてくる。

これが、ヒトのラーニングなんだよ。

pillow

ちょいっと、pilで直線探索をした。

単純アルゴリズム。やっぱ楽だわ。

頭悪いのかなあ。

面白いのは、白黒だろうと、思っていたjpegが

黒、灰色など組み合わせて5-6種類のピクセル値をもっていたこと。

これが、いわゆる、滲み問題の根源だな。

エンジニア

いろんなエンジニアがいる。

ひらめきタイプ。コツコツタイプ。

どっちがいいかは、わからない。

一つ言えるのは、他人の話を聞かないエンジニア。

これはダメですね。 優秀な人ほど、この傾向が強い。

自分ならこうするけど、どうして、そうやらないんだ。という方向にしか

考えがいかない。

あと、綺麗にやろうとする、傾向のあるエンジニアもダメですね。

どんなに設計理論的に綺麗にやったところで、例外はでる。

99%正解での、1%は例外。この1%の意味がわからんエンジニアが多いけど、

これ、10000件のデータだと100件はエラーってこと。。まあ、単純に

そうはならないのだけど、例外は起きることを前提にコードを書くこと。

Try catchすればいいじゃん。。ってことじゃあないよ。自分の想定外を、想定

することだよ。