漫画、作曲、ラップ、プログラミングをやっています。I am Keita Roimo: Manga Artist, Musician, Rapper, Software Engineer.
Saturday, December 31, 2016
vimfind, Railsユーザー用に新機能を追加しました
https://github.com/keitaroemotion/vimfind
主に以下の機能を追加
1) ファイル選択時に "l"コマンドを叩いてエンターキーを押すと、現在選択しているファイルのdef, concerns, belongs_to, has_one, has_many がコンソールで一覧表示される。(ファイルに入らなくてもいい。ナビゲーター的な)
2) ファイル選択時に "db" コマンドを叩いてエンターキーを押すと、 db/schema.rb をパースして検索、コンソールで該当のテーブルを洗い出し、ハイライトして表示してくれる。
3) grep機能の強化
4) prev機能追加(選択時、一個前に戻る)
結論から言うとコンソールベースで、必要なものを参照する際に使う手間を大幅に省いたということになる。
これまでの find や grepは、
探す > パスを指定する > 開く
探す > 関連するファイル間を行ったり来たりする > 開く
という形で、事実上手間がかかっていた。でもよりベターなのは、探したらすぐそのまんま開くということだし、よりベターなのは、
「東京都千代田区飯田橋何丁目のx-x-xの山田さん」
と毎回指定して入ることじゃなくて、
「山田」と唱えたら、自動的にロボットが駆けずり回ってくれて、そのままボタンひとつて山田さんに会える、
これがエディタ周りで特に考えなきゃならないことだ。
今回のアップデートによって、より大量かつ複雑なものを、簡単に見ていくことができる、簡単にアクセスできるようになった、と言っても過言ではない。
主に以下の機能を追加
1) ファイル選択時に "l"コマンドを叩いてエンターキーを押すと、現在選択しているファイルのdef, concerns, belongs_to, has_one, has_many がコンソールで一覧表示される。(ファイルに入らなくてもいい。ナビゲーター的な)
2) ファイル選択時に "db" コマンドを叩いてエンターキーを押すと、 db/schema.rb をパースして検索、コンソールで該当のテーブルを洗い出し、ハイライトして表示してくれる。
3) grep機能の強化
4) prev機能追加(選択時、一個前に戻る)
結論から言うとコンソールベースで、必要なものを参照する際に使う手間を大幅に省いたということになる。
これまでの find や grepは、
探す > パスを指定する > 開く
探す > 関連するファイル間を行ったり来たりする > 開く
という形で、事実上手間がかかっていた。でもよりベターなのは、探したらすぐそのまんま開くということだし、よりベターなのは、
「東京都千代田区飯田橋何丁目のx-x-xの山田さん」
と毎回指定して入ることじゃなくて、
「山田」と唱えたら、自動的にロボットが駆けずり回ってくれて、そのままボタンひとつて山田さんに会える、
これがエディタ周りで特に考えなきゃならないことだ。
今回のアップデートによって、より大量かつ複雑なものを、簡単に見ていくことができる、簡単にアクセスできるようになった、と言っても過言ではない。
Friday, December 30, 2016
Railsって使いにくいよね問題
いわゆるRailsのMVC間を探し回ることをしなくても、一発で探せる機能をvimfindに追加した。
https://github.com/keitaroemotion/vimfind
READMEを読んでもらえればわかるけど、model, view, controllerのディレクトリにターゲットを絞り、ひたすら探し回る。 (こともできるし、ディレクトリを全部探し回ることもできる)
該当のディレクトリに行き、以下のようなコマンドを叩く
$vf employee
こうすると、 全ディレクトリの employeeに部分一致するファイルを全部取ってくる
$vf -g employee
これで、全ディレクトリの各ファイルの中身に "employee"が入って来る場合にそのファイルを取ってくる。
ここで重要なのが、取ってきた後、開くかどうか聞いて来るので(vimが入っていることが前提) y+ Enterでそのまま編集できる。
$ vf -mvc employee w:fixture_marry
とか叩くと、 mvcディレクトリ限定で fixture_marryが本文に記載されているファイルを取ってくる。
今いるディレクトリ以外のところを指定して取ってくるのも実装したけど、これはまだバグがあるみたい。
後、 db/schema.rb は必ず取ってくる
長いパスを行ったり来たりってのは何万回も繰り返すことなので、これは楽にしたい、という動機で作った。
よかったらぜひ。
https://github.com/keitaroemotion/vimfind
READMEを読んでもらえればわかるけど、model, view, controllerのディレクトリにターゲットを絞り、ひたすら探し回る。 (こともできるし、ディレクトリを全部探し回ることもできる)
該当のディレクトリに行き、以下のようなコマンドを叩く
$vf employee
こうすると、 全ディレクトリの employeeに部分一致するファイルを全部取ってくる
$vf -g employee
これで、全ディレクトリの各ファイルの中身に "employee"が入って来る場合にそのファイルを取ってくる。
ここで重要なのが、取ってきた後、開くかどうか聞いて来るので(vimが入っていることが前提) y+ Enterでそのまま編集できる。
$ vf -mvc employee w:fixture_marry
とか叩くと、 mvcディレクトリ限定で fixture_marryが本文に記載されているファイルを取ってくる。
今いるディレクトリ以外のところを指定して取ってくるのも実装したけど、これはまだバグがあるみたい。
後、 db/schema.rb は必ず取ってくる
長いパスを行ったり来たりってのは何万回も繰り返すことなので、これは楽にしたい、という動機で作った。
よかったらぜひ。
スーパーマーケットと教育
今日、スーパーマーケットで買い物をしていたら、お母さんと5歳くらいの小さい子供が後ろに並んでいた。
お母さんは子供に以下のような注意の仕方をしていた。
「そこに手をつかないの、手が挟まったらどうするの」
「何々しないほうがいいよ」
などなどだ。
一点、引っかかったことがある。
人格形成期の子供を、「納得させる」という行為は無意味だ。時には害になる、というのが僕の持論だ。
人格形成期の子供を育てる時に、絶対にしてはならないことがある。それは、
1) 善悪の基準を教える際、「なぜなら〜」と納得させようとすること。
2) 同じ目線に立って会話すること
3) 間違いを犯した時に罰を与えないこと
4) 親子の力関係において、主導権を取れない状態になること
5) 子供の人格を否定し、傷つける言動をすること(感情的に怒ること)
6) 子供に関心を持たないこと。
これは人格形成期に顕著に守らなくてはならず、少年、青年期と自我が確立するにしたがって少しずつこの縛りやタガを外していく、ということが必要である。
1) 善悪の基準を教える際に、子供を納得させようとしてはならない。納得させようと「Aしちゃダメでしょ、Bだからだよ」と注意した場合、子供はBだからAなのか、と思うが、お母さんが伝える時、だいたいこのBには「危ないから」「怪我をするから」といった自分がわの理由が入りがちになる。
これは頭の中にインプットするときに極めて無駄なプロセスだ。人格形成期の子供の頭に入れなければいけないのは、「Aするな」だけでいい。TrueとFalseを叩き込むのが幼児期や人格形成期に一番やらなくてはならないことである。口頭言語で「Because」を付加するということを子供に対して行うことで考えられ得ることは、子供が無駄に相対的に考えることを覚えてしまい、秩序の中で行動できなくなる、ということだ。(相対的に考えるのは思春期、反抗期、青年期でよい)むしろ、子供にいうことを聞かせるのに、説得しなきゃいけないということは、親子関係において親の権威が確立されていないということに等しい。(ちなみに、僕はジョンロックの説を信じるので青年以降は親の権威はいらないと思っている)※なぜならを教えるのは後回しで良い
2) 同じ目線になってはならない。1)と同様、インプットをする際、自分のいうことを聞かせられる人間関係が確立されているかどうか、がネックである。
3) 間違いを犯した時に罰を与えなければ、人格形成の中で、善悪の基準(人としての基礎的な行動基準、価値基準、倫理基準、遵法意識)をインプットすることを放棄していることになる。人格形成期、子供は自分に対して自分を罰する行為を行わない。善悪の基準ももちろんわからない。「口で説明する」という高度な方法で子供に善悪の基準を教えるのには無理がある。というか無理だ。
a) 火に触ったら、「熱い」。
b) お友達のものを盗ったら、「げんこつ」「ご飯抜き」になる。
c) 嘘をついたら、「怒られる(叱られる)」
d) 宿題をしなかったら、「廊下に立たされる」
e) 門限を過ぎたら、「怒られる」「ご飯抜き」になる。
....
こういった因果関係を格律(maxim)と呼ぶと、
Bad Action -> Sanction
という経験の積み重ねにより、子供は何が「よくて」何が「悪いか」を埋め込まれていく。
これは人格を作っていくプロセスなので、とても重要なことだ。ここで与えられた格律の束を、その子供は一生抱えて生きていくことになる。束が全然なければ、社会の中で生きていくことが難しくなることも考えられる。とても重要だ。
4) 親子関係において主導権をとるということはとても大事だ。
特に人格形成期においては、教える側が立場的に、力的に上でないのに、子供に何かを教えることはできない。(子供は従わない)なので、主導権を取っていない場合、子供に「インプット」ができない。これは致命的になることがある。主導権をとる簡単な方法がある。それは 3)で述べた通り間違ったことをした場合には適正にわかりやすい(肉体に近ければ近いほど良い)罰を与えることであり、また、命令形を使うことだ。
「〇〇するな」
「〇〇しなさい・しろ」
(これよりきつくなっても、マイルドになってもいけないと思う)
そして、子供がそれに従うまでそれを放置したり、黙認してはならない。
5) -6)は言わずもがななのでここでは割愛する。
ただ、一点だけ述べるとすると、上記の「しつけ」が子供を傷つけてしまえば、それは虐待になる。特に父親は子供の恐怖の対象にならなければならない時期や場面があり、その際に、子供に加える暴力(げんこつとかお尻ぺんぺんとか)をどのように制御し、有効に教育に使うか、というところは意識しなくてはならないことだ。ただ、感情的に、等身大の憎悪を親からぶつけられた時、子供には一生消えない傷が残る。それはおそらくずっと忘れない。
また、教育機関においても体罰がタブーになってから久しいが、この習慣が奪ったものもまた大きいということも、議論しなくてはならない(僕は小学一年の時机ごと廊下に出された経験が....)
以上、所帯も持ってない人の空論といえばそれまでだが、今日の親子のやり取りを見ていて少し考えたことであった。
みなさん良いお年を
2017年も日本が平和でありますように
お母さんは子供に以下のような注意の仕方をしていた。
「そこに手をつかないの、手が挟まったらどうするの」
「何々しないほうがいいよ」
などなどだ。
一点、引っかかったことがある。
人格形成期の子供を、「納得させる」という行為は無意味だ。時には害になる、というのが僕の持論だ。
人格形成期の子供を育てる時に、絶対にしてはならないことがある。それは、
1) 善悪の基準を教える際、「なぜなら〜」と納得させようとすること。
2) 同じ目線に立って会話すること
3) 間違いを犯した時に罰を与えないこと
4) 親子の力関係において、主導権を取れない状態になること
5) 子供の人格を否定し、傷つける言動をすること(感情的に怒ること)
6) 子供に関心を持たないこと。
これは人格形成期に顕著に守らなくてはならず、少年、青年期と自我が確立するにしたがって少しずつこの縛りやタガを外していく、ということが必要である。
1) 善悪の基準を教える際に、子供を納得させようとしてはならない。納得させようと「Aしちゃダメでしょ、Bだからだよ」と注意した場合、子供はBだからAなのか、と思うが、お母さんが伝える時、だいたいこのBには「危ないから」「怪我をするから」といった自分がわの理由が入りがちになる。
これは頭の中にインプットするときに極めて無駄なプロセスだ。人格形成期の子供の頭に入れなければいけないのは、「Aするな」だけでいい。TrueとFalseを叩き込むのが幼児期や人格形成期に一番やらなくてはならないことである。口頭言語で「Because」を付加するということを子供に対して行うことで考えられ得ることは、子供が無駄に相対的に考えることを覚えてしまい、秩序の中で行動できなくなる、ということだ。(相対的に考えるのは思春期、反抗期、青年期でよい)むしろ、子供にいうことを聞かせるのに、説得しなきゃいけないということは、親子関係において親の権威が確立されていないということに等しい。(ちなみに、僕はジョンロックの説を信じるので青年以降は親の権威はいらないと思っている)※なぜならを教えるのは後回しで良い
2) 同じ目線になってはならない。1)と同様、インプットをする際、自分のいうことを聞かせられる人間関係が確立されているかどうか、がネックである。
3) 間違いを犯した時に罰を与えなければ、人格形成の中で、善悪の基準(人としての基礎的な行動基準、価値基準、倫理基準、遵法意識)をインプットすることを放棄していることになる。人格形成期、子供は自分に対して自分を罰する行為を行わない。善悪の基準ももちろんわからない。「口で説明する」という高度な方法で子供に善悪の基準を教えるのには無理がある。というか無理だ。
a) 火に触ったら、「熱い」。
b) お友達のものを盗ったら、「げんこつ」「ご飯抜き」になる。
c) 嘘をついたら、「怒られる(叱られる)」
d) 宿題をしなかったら、「廊下に立たされる」
e) 門限を過ぎたら、「怒られる」「ご飯抜き」になる。
....
こういった因果関係を格律(maxim)と呼ぶと、
Bad Action -> Sanction
という経験の積み重ねにより、子供は何が「よくて」何が「悪いか」を埋め込まれていく。
これは人格を作っていくプロセスなので、とても重要なことだ。ここで与えられた格律の束を、その子供は一生抱えて生きていくことになる。束が全然なければ、社会の中で生きていくことが難しくなることも考えられる。とても重要だ。
4) 親子関係において主導権をとるということはとても大事だ。
特に人格形成期においては、教える側が立場的に、力的に上でないのに、子供に何かを教えることはできない。(子供は従わない)なので、主導権を取っていない場合、子供に「インプット」ができない。これは致命的になることがある。主導権をとる簡単な方法がある。それは 3)で述べた通り間違ったことをした場合には適正にわかりやすい(肉体に近ければ近いほど良い)罰を与えることであり、また、命令形を使うことだ。
「〇〇するな」
「〇〇しなさい・しろ」
(これよりきつくなっても、マイルドになってもいけないと思う)
そして、子供がそれに従うまでそれを放置したり、黙認してはならない。
5) -6)は言わずもがななのでここでは割愛する。
ただ、一点だけ述べるとすると、上記の「しつけ」が子供を傷つけてしまえば、それは虐待になる。特に父親は子供の恐怖の対象にならなければならない時期や場面があり、その際に、子供に加える暴力(げんこつとかお尻ぺんぺんとか)をどのように制御し、有効に教育に使うか、というところは意識しなくてはならないことだ。ただ、感情的に、等身大の憎悪を親からぶつけられた時、子供には一生消えない傷が残る。それはおそらくずっと忘れない。
また、教育機関においても体罰がタブーになってから久しいが、この習慣が奪ったものもまた大きいということも、議論しなくてはならない(僕は小学一年の時机ごと廊下に出された経験が....)
以上、所帯も持ってない人の空論といえばそれまでだが、今日の親子のやり取りを見ていて少し考えたことであった。
みなさん良いお年を
2017年も日本が平和でありますように
Wednesday, December 28, 2016
Friday, December 23, 2016
Saturday, December 17, 2016
Friday, December 16, 2016
Saturday, December 10, 2016
Saturday, December 3, 2016
Sunday, November 27, 2016
Saturday, November 26, 2016
孤独死はビジネスチャンスじゃね?
こういうトピックにはかなりビジネスチャンスがある。
まず、家屋の中の 1)トイレのドア 2) メインの部屋の照明 3) 玄関ドアの三つの ON/OFFを定点観測する。そうするとこれらは生きていることの大まかな指標になるので、 1) - 3)のなかで異常を検知した時はアラートが業者のウェブサイトに飛ばされる。業者は それを検知して、迅速に大家さんや物件会社に連絡する。彼らが状況を確認し、場合によっては警察や病院、となる。
このアイデアは技術的にはそんなに実現のハードルは高くないし(アラートはマンションのWIFIかなんかに飛ばせば工夫すれば工事費もそんなにいらない)、適用すれば「死後3ヶ月」とか「死後三日」みたいな状況は防げる。
この場合、特殊清掃の仕事を奪うような技術的な工夫とか新しいビジネスチャンスが必要かと思う(孤独死も増えるだろうし)
誰かやってみればいいんじゃないか
もちろん会社がサーバーを用意するもよし、すごく経済的なハードルを低くすれば大家さんのパソコンにVMなりドッカーなり立ち上げるとか、単に各設置デバイスからのメール送信でも良い。
無論、海外出張で意図的に部屋を開けていましたみたいなパターンがあるので、異常検知後すぐ警察にアラートは色々と問題あるかもしれないが、 マンションの管理人へのアラートは意義があるし、これはマンション管理人も、住人も、その家族も、みんな幸せになれると思う
何より、命が助かる可能性すらある
インテリチキン (過去の作品です)
大昔に少年チャンピオンの最終選考で落ちたやつ。
物語の特性上、トリガーがないとイベントが発生しないのでヒロインが積極的に追いかけているけど本来のジェンダーと役割としてはあべこべであり、かなり不自然さはある。
(二次元だから成立している的な)
http://www.pixiv.net/member_illust.php?mode=manga&illust_id=60124941
Tuesday, November 22, 2016
Sunday, November 20, 2016
日本のIQテスト受けてみた
日本のIQテストでやってみたら135だった 英語より2下がるけどある程度はここら辺で落ち着いているっぽい https://curazy.com/archives/42747 もちろん、実生活はアスぺなので大して楽ではない
まあ二つ受けて 135-137あたりで安定しているってことは、
そこそこ快適に暮らせるはず......たぶん
Saturday, November 19, 2016
Thursday, November 17, 2016
Monday, November 14, 2016
Saturday, November 12, 2016
Thursday, November 10, 2016
Monday, November 7, 2016
Sunday, November 6, 2016
Saturday, October 29, 2016
about local wiki management tool (liki)
People know that wiki is necessary documentation agent, but there are obstacles like...
1) You cannot customize wiki as you prefer for it affects whole team or entire company. (so veto to deployment of plugins occurs often).
2) There sometimes appears necessity to handle trivial document data, locally.
3) Your local documents piled/messed up as time passes and you no longer be able to manage almost all of these documents any longer. It is pretty hard to refer to something embedded in the document saved two years ago on your hard drive, which you ain't remember any more.
The liki emerged for these reasons. We need to create, relate(this part not implemented yet), update, grep, find documents efficiently, locally, as wiki. Keyword-based search easily let user find what they want to look for. This script had to be used solely via terminal because terminal/editor oriented developer always suffered for GUI-based development or third party tool which had disgusted them for a long time.
TODO// See also or tagged-link function. (we need to establish dsl here)
Here is the repository:
https://github.com/keitaroemotion/liki/blob/master/liki
Here is the code (in progress)
indentation is dead here so you need to look out github
}[sys.argv[1]]()
1) You cannot customize wiki as you prefer for it affects whole team or entire company. (so veto to deployment of plugins occurs often).
2) There sometimes appears necessity to handle trivial document data, locally.
3) Your local documents piled/messed up as time passes and you no longer be able to manage almost all of these documents any longer. It is pretty hard to refer to something embedded in the document saved two years ago on your hard drive, which you ain't remember any more.
The liki emerged for these reasons. We need to create, relate(this part not implemented yet), update, grep, find documents efficiently, locally, as wiki. Keyword-based search easily let user find what they want to look for. This script had to be used solely via terminal because terminal/editor oriented developer always suffered for GUI-based development or third party tool which had disgusted them for a long time.
TODO// See also or tagged-link function. (we need to establish dsl here)
Here is the repository:
https://github.com/keitaroemotion/liki/blob/master/liki
Here is the code (in progress)
indentation is dead here so you need to look out github
#!/usr/bin/env python |
import os |
import sys |
from os import listdir |
wiki_dir = "/usr/local/etc/liki/pages" |
def makeDirs(directory): |
if(not os.path.exists(directory)): |
os.makedirs(directory) |
return directory |
def addChild(node, term): |
return (node + "/{0}").format(term) |
def getDirectory(rootdir, folder): |
return makeDirs(addChild(rootdir, folder)) |
def getPage(term): |
return addChild(getDirectory(wiki_dir, term[0]), term) |
def writeToFile(page, text, mode="a"): |
f = open(page, mode) |
f.write(text + "\n") |
f.close |
def makeText(text, addition, message=""): |
sys.stdout.write(message) |
return text if (addition == "fin") else makeText(text + addition + "\n", raw_input()) |
# look for page file |
def findPage(keyword=""): |
if(keyword == ""): |
sys.stdout.write("[find] word: ") |
keyword = raw_input() |
result_list = [f for f in listdir(getDirectory(wiki_dir, keyword[0])) if f.startswith(keyword)] |
{ |
True : (lambda x : showPage(x[0])), |
False : (lambda x : findPage()) |
}[len(result_list) == 1](result_list) |
def showPage(page): |
f = open(getPage(page), "r") |
print(f.read()) |
# create page file |
def createPage(): |
sys.stdout.write("[create] word: ") |
page = getPage(raw_input()) |
writeToFile(page, makeText("", "", "text[type fin at EOF]: \n")) |
# edit page file |
# link page file |
# list pages with key |
# grep pages |
# |
# here is the main execution part. |
# |
# if argument does not exist, show help message |
if(len(sys.argv) < 2): |
print("you need argument") |
print("") |
print("[find] : find page") |
print("[create] : create page\n") |
sys.exit() |
# dispatch execution function |
{ |
"find" : findPage, |
"create" : createPage |
Friday, October 28, 2016
local wiki management script
This script is in the development process: (written in python)
https://github.com/keitaroemotion/liki/blob/master/liki
https://github.com/keitaroemotion/liki/blob/master/liki
Network easy access helper 'netw' created
I had been fed up with the trouble.... for there are unnecessary wifi networks I gotta dismiss every time, so I made a script to easily manage networks and its passwords.
https://github.com/keitaroemotion/netw/blob/master/netw
the password is currently directly stored therefore needs encryption and decryption implementation.
with this script, you can easily launch/disable target networks via terminal instantly.
Recording conversations on Mac via terminal
(suppose you are Mac OSX user and already have installed homebrew)
$brew install sox
$rec sample.wav
(now you are recording)
(Ctrl-D)
$play sample.wav
$brew install sox
$rec sample.wav
(now you are recording)
(Ctrl-D)
$play sample.wav
Wednesday, October 26, 2016
Tuesday, October 25, 2016
Monday, October 24, 2016
Sunday, October 23, 2016
デスマーチの仕組み
"If painful programming were the most cost-effective way to produce
working software, programmers would be morally obliged to suffer
stoically or to find other jobs."
"Fortunately, you do not have to choose between pleasure and productivity. The programming techniques that make code a joy to write overlap with those that most efficiently produce software."
- SANDI METZ
どっかの誰かに聞かせてやりたい ITドカタが正義な国だと無理か....
本気で overlap with じゃなくてconflict with とか most efficiently じゃなくて the matter of preference とか思ってそう... そういう場所がうじゃうじゃあるので、精神を病む人が多い業界になってしまっている 業界を挙げてそもそも誇れないのに、業界のしがらみもクソもない。個人的に「職業プログラマー」という言葉は恥ずかしい単語だと考える「割り切り」みたいだ
エンジニアの職場環境や理念として、「楽しく」「生き生きと」「新しいものを積極的に取り入れ」「可能な限り楽をしようとする」という大原則から大幅に外れることがあってはならない。「新しい言語は覚えたくないけど大変なことをするのは得意です」って人をあまりにも多く見てきた。そんなエコシステムが生み出す幸福などありえない。デスマーチの根本原因だ。気づいてない。昔「私はphpに明るくない」なんてことを言われたりもしたが、phpなんて覚えるのに2、3時間もかからない。その2, 3時間を惜しむ意味がわからない。だから仕事量が増えている。Java をJavaでリプレイスする意味もわからない。明らかに金をドブに捨てている。一つの言語を覚える時間の方が、無駄な仕事をたくさん量産してデスマーチに突っ込んで、毎日意味もなく10時まで居残って仕事をするよりも結果的に、等比級数的に、時間も工数もcost-effectiveである。
例えば僕の知ってるある現場では、こんなコードが山ほど横に並列に並んでいる:
class Model1 {
@annotation1
@annotation2
/*
* 顧客ナンバー
*/
public String empNo() ;
@annotation1
@annotation2
@annotation3
/*
* 日付更新追加区分
*/
public String dtUpdWCtgr();
@annotation1
@annotation2
@annotation3(size = 3)
/*
* 日付フラグ二次長
*/
public String dtFlgNxtLen();
....
/*
* 顧客ナンバーをセットする
*/
public void setEmpNo(String empNo){
this.empNo = empNo;
}
/ *
* 顧客ナンバーを取得する
*/
public String getEmpNo(){
return this.empNo;
}
/*
* 日付更新追加区分をセットする
*/
public void setDtUpdWCtgr(String dtUpdWCtgr){
this.dtUpdWCtgr = dtUpdWCtgr;
}
/ *
* 日付更新追加区分を取得する
*/
public String getDtUpdWCtgr(){
return this.dtUpdWCtgr;
}
/ *
*日付フラグ二次長をセットする
*/ public void setDtFlgNxtLen(String dtFlgNxtLen){
this.dtFlgNxtLen = dtFlgNxtLen;
}
/ *
* 日付フラグ二次長を取得する
*/ public String getDtFlgNxtLen(){
return this.dtFlgNxtLen;
}
.....
}
こんなクラスを何十と横に並べた上、(しかも同じデータや定義は再利用はせず、それぞれ全部書く(分散記述)、ため同じコードやコメントが何十ファイルにまたがって複製してかかれている)これはインプット部門で、さらにアウトプット部門もあり、かつ、入れ子になっているものは入れ子用のクラスを作ることで対応、依存関係が強すぎて誰かが何かを変更したら一回ずつ他のメンバーもそれに合わせて一つ一つ変更する
だから例えば誰かのつるのひとこで日付フラグ二次長 じゃなくて 日付フラグ二次って名前に変えてー と言われたら関連するとこを全部洗い出して一個一個手で変えていかないといけない。そんなのが半永久的に降ってくる感じ
闇は深い
ちなみに私ならこうやる
ファイル名 : model1.dsl
==========================================================
employeeNumber | S | 顧客ナンバー | @annotation {1,2,3} | @action {}
categoryOfUpdatedDate | I | 日付更新追加区分 | @annotation {4,5 } | @action {x}
dateFlagSecondaryLength | I | 日付フラグ二次長 | @annotation {1,2,3}| @action {}
...
ファイル名: ReadData.java
==========================================================
class <T> ReadData {
public T get(String key, Integer index, List<T> options){
List<String> values = ReadDsl.getDSL(FILE_PATH).getValues(key);
return assignValueWithType(values.get(index), values.get(1));
}
public void set(String key, Integer index, List<T> options){
// set
}
public Tuple getAll(Integer index){
Tuple t = new Tuple();
ReadDsl.getDSL(FILE_PATH).getAllValues(index){ (value, type) =>
t.add(assignValueWithType(value, type));
};
return t;
}
public void setAll(Integer index){
// set all
}
public assignValueWithType(String value, String type){
switch (type){
case "S":
return value.toString();
case "I":
return value.toInteger();
default:
throw Exception();
}
}
}
ファイル名: ReadDsl.java
==========================================================
class ReadDsl{
public static Map<String, List<String>> getDSL {
// parse model1.dsl into multi-dimentional array
// convert array into map
// return map
}
}
まあ細かいJavaのルールなんていちいち覚える気ないからそこは雑になってるけど、
さて、どっちが長期的に使いやすいしヒューマンエラーも少ないだろうか?????
機能とデータを分けられてない時点でスタート地点にすら立ってないってこと。
Javaみたいなスカトロ言語でもこれくらいはマシにかけるのに、コードのセンスがない人がプロジェクトを引っ張ること自体意味わからない。
前者をやりきることが「良い仕事」っていう空気だから、できる人からどんどん逃げられていくのではないか?????
コードについてもbetterとか好みとかじゃなくて優劣の差が明確だと思うが....
そういう仕事の仕方だから、長時間に必然的になる。
闇は深い
"Fortunately, you do not have to choose between pleasure and productivity. The programming techniques that make code a joy to write overlap with those that most efficiently produce software."
- SANDI METZ
どっかの誰かに聞かせてやりたい ITドカタが正義な国だと無理か....
本気で overlap with じゃなくてconflict with とか most efficiently じゃなくて the matter of preference とか思ってそう... そういう場所がうじゃうじゃあるので、精神を病む人が多い業界になってしまっている 業界を挙げてそもそも誇れないのに、業界のしがらみもクソもない。個人的に「職業プログラマー」という言葉は恥ずかしい単語だと考える「割り切り」みたいだ
エンジニアの職場環境や理念として、「楽しく」「生き生きと」「新しいものを積極的に取り入れ」「可能な限り楽をしようとする」という大原則から大幅に外れることがあってはならない。「新しい言語は覚えたくないけど大変なことをするのは得意です」って人をあまりにも多く見てきた。そんなエコシステムが生み出す幸福などありえない。デスマーチの根本原因だ。気づいてない。昔「私はphpに明るくない」なんてことを言われたりもしたが、phpなんて覚えるのに2、3時間もかからない。その2, 3時間を惜しむ意味がわからない。だから仕事量が増えている。Java をJavaでリプレイスする意味もわからない。明らかに金をドブに捨てている。一つの言語を覚える時間の方が、無駄な仕事をたくさん量産してデスマーチに突っ込んで、毎日意味もなく10時まで居残って仕事をするよりも結果的に、等比級数的に、時間も工数もcost-effectiveである。
例えば僕の知ってるある現場では、こんなコードが山ほど横に並列に並んでいる:
class Model1 {
@annotation1
@annotation2
/*
* 顧客ナンバー
*/
public String empNo() ;
@annotation1
@annotation2
@annotation3
/*
* 日付更新追加区分
*/
public String dtUpdWCtgr();
@annotation1
@annotation2
@annotation3(size = 3)
/*
* 日付フラグ二次長
*/
public String dtFlgNxtLen();
....
/*
* 顧客ナンバーをセットする
*/
public void setEmpNo(String empNo){
this.empNo = empNo;
}
/ *
* 顧客ナンバーを取得する
*/
public String getEmpNo(){
return this.empNo;
}
/*
* 日付更新追加区分をセットする
*/
public void setDtUpdWCtgr(String dtUpdWCtgr){
this.dtUpdWCtgr = dtUpdWCtgr;
}
/ *
* 日付更新追加区分を取得する
*/
public String getDtUpdWCtgr(){
return this.dtUpdWCtgr;
}
/ *
*日付フラグ二次長をセットする
*/ public void setDtFlgNxtLen(String dtFlgNxtLen){
this.dtFlgNxtLen = dtFlgNxtLen;
}
/ *
* 日付フラグ二次長を取得する
*/ public String getDtFlgNxtLen(){
return this.dtFlgNxtLen;
}
.....
}
こんなクラスを何十と横に並べた上、(しかも同じデータや定義は再利用はせず、それぞれ全部書く(分散記述)、ため同じコードやコメントが何十ファイルにまたがって複製してかかれている)これはインプット部門で、さらにアウトプット部門もあり、かつ、入れ子になっているものは入れ子用のクラスを作ることで対応、依存関係が強すぎて誰かが何かを変更したら一回ずつ他のメンバーもそれに合わせて一つ一つ変更する
だから例えば誰かのつるのひとこで日付フラグ二次長 じゃなくて 日付フラグ二次って名前に変えてー と言われたら関連するとこを全部洗い出して一個一個手で変えていかないといけない。そんなのが半永久的に降ってくる感じ
闇は深い
ちなみに私ならこうやる
ファイル名 : model1.dsl
==========================================================
employeeNumber | S | 顧客ナンバー | @annotation {1,2,3} | @action {}
categoryOfUpdatedDate | I | 日付更新追加区分 | @annotation {4,5 } | @action {x}
dateFlagSecondaryLength | I | 日付フラグ二次長 | @annotation {1,2,3}| @action {}
...
ファイル名: ReadData.java
==========================================================
class <T> ReadData {
public T get(String key, Integer index, List<T> options){
List<String> values = ReadDsl.getDSL(FILE_PATH).getValues(key);
return assignValueWithType(values.get(index), values.get(1));
}
public void set(String key, Integer index, List<T> options){
// set
}
public Tuple getAll(Integer index){
Tuple t = new Tuple();
ReadDsl.getDSL(FILE_PATH).getAllValues(index){ (value, type) =>
t.add(assignValueWithType(value, type));
};
return t;
}
public void setAll(Integer index){
// set all
}
public assignValueWithType(String value, String type){
switch (type){
case "S":
return value.toString();
case "I":
return value.toInteger();
default:
throw Exception();
}
}
}
ファイル名: ReadDsl.java
==========================================================
class ReadDsl{
public static Map<String, List<String>> getDSL {
// parse model1.dsl into multi-dimentional array
// convert array into map
// return map
}
}
まあ細かいJavaのルールなんていちいち覚える気ないからそこは雑になってるけど、
さて、どっちが長期的に使いやすいしヒューマンエラーも少ないだろうか?????
機能とデータを分けられてない時点でスタート地点にすら立ってないってこと。
Javaみたいなスカトロ言語でもこれくらいはマシにかけるのに、コードのセンスがない人がプロジェクトを引っ張ること自体意味わからない。
前者をやりきることが「良い仕事」っていう空気だから、できる人からどんどん逃げられていくのではないか?????
コードについてもbetterとか好みとかじゃなくて優劣の差が明確だと思うが....
そういう仕事の仕方だから、長時間に必然的になる。
闇は深い
Friday, October 21, 2016
It was the last day of attending my current company
I am so glad to be part of the new company.
I've read part of the codes provided as open source, and these were really sophisticated, smart, intellectually stimulative, and makes me excited.
Probably I am weird in my own country for indigenous language often looks nothing but contraption, for instance, I had to convert each indigenous documents or conversations into international one for it is really hard to process logically in my cranium originally.
Sometimes I encountered with a sort of culture shock in Japanese technical community, for they have their own indigenous customs. They loved excel. Verbose coding. Verbose document handling.
Auto-testing or regression test never existed. They wrote each test cases and corresponding dataSets, expectations, and commands in excel spread sheets. It was totally insane for me so I personally implemented regression test in Python. (terminal-base development is worthy because it is easy to be automated).
If you have thousand test cases, these have to be examined with a single hit of Enter button, nothing more, nothing less. If the labor or academic approach to eliminate the repetitive manual operations is spared, and if the expert guy who is so good at handling bulk of manual repetitions would be regarded as "bonus est", the workplace is never gonna be an ecosystem attractive to highly-skilled or well-sophisticated developers/engineers, in my arrogant opinion.
I am sloppy guy, my cranium forgets details often. But because of this biological facts, my development and coding never trust human memory. It always take the possibilities of human errors into account. This is my belief in coding.
Productivity is correlated with the laziness. You do not want to repeat something, then you make something as script. You do not want checking errors, then you simulate the review process with coding.
If you are not lazy, you never question what you are doing. You never question the repetition and bulk of operations and information which you keep in your cranium.
Code syntax have to be precisely written because you are lazy enough not want to memorize these.
If you gonna memorize these bulk of information, you are bureaucratic Japanese Software Engineer.
If there is the following database (example):
Table : SALES
Column1: BALANCE
Column2: INCOME
Column3: EXPENSE
Column4: TRANSACTION_ID
methodName
getEmployeeName()
getLastDateUpdated()
isDateTimeBeforeChristmas()
In Japan, you see the following syntax:
Tables: URIAGE
Column1: URIAGE_BLNC
Column2: URIAGE_INC
Column3: URIAGE_EXPNS
Column4: URIAGE_TRNS_ID
methodName
getEmpName()
getLstDateUpd()
isDtChrm()
... This occurs everywhere and the reason why thousands of failures and unnecessary extra work hours of my people happens is this indigenous way of syntax. (I know the abbreviation required sometimes, but the flood of Japanese abbreviations collapses everything)
Excel, Excel, Excel... Many Japanese Engineers are totally religious to excel. Often misspelled and misused English terms are found anywhere and allows verbose coding, on the other hand, their mindsets are very precise and detail-nazi (but write the same code everywhere at the same time). It is one of the biggest problem in our indigenous technical society.
Tuesday, October 18, 2016
Project Maturi: まだ開発段階ですが.... インストーラを追加しました
Project Maturi: まだ開発段階ですが.... インストーラを追加しました: https://github.com/keitaroemotion/maturi まだ version 0.0 ですが、 対象OS MaxOSX 10以降 1. インストーラの追加 2. Firefoxブラウザの簡易参照機能の追加(オマケ機能) 3. READM...
上手な詐欺に気をつけて!
一応アカデミズムのバックボーンがあると終始血圧が上がるようなプレゼンで結局途中飛ばしたんだけど、人間の知覚の死角をついているという意味で良い詐欺商法だと思う。
この手の情報商材には決して引っかからないように。情報弱者は搾取されるだけです。
上記プレゼンの問題として
(1) 核心に迫らない(核心は一番最後の情報商材を買え、ということ)
(2) いかにもそれっぽいことを非論理的にグダグダ並べることで視聴者の知覚を混乱させ、 振り回すこと。
(3) 中身の薄っぺらい情報の切れ端のパッチワークであること。
(4) 文字をただ羅列して右から左に流していくことであえて論理的にわかりにくくさせること
上記のプレゼンは、一応学問の世界ではNGで、まず
1. 何を言いたいかの総括 (Summary)
2. 総括の詳細 (Body)
3. 結論、1.から逸脱しないパラフレーズ (Conclusion)
が無茶苦茶、最低限の要件も満たしていない。
つまりそもそも情報コンテンツとしては成立しない。
論理性という意味で言ったらどっかのムラや部族の口伝の方がまだコンテンツも論理性もあるっていう....
一言で言うと論理的にものを考えることのできない(ないし苦手な)情報弱者の思考を疲弊させることで自分のイカサマコンテンツを買わせているので、かなりタチが悪いです。
普通にMBAなり国内外で実際に名前がとおっている実業家とかの本を読んで勉強しましょう。
おしまい
☝️イヤイヤ0円でも高いっすよ....
若いんでしょ?こんな詐欺でお金稼いで何になるの....
社会貢献しようよ..... と思うおじさんであった
あと、新規事業の倒産率の話だけど、その何%というデータには実はあまり意味はなくて、
「事業カテゴリ」
「取引先の規模や数」
「商品」
「商品の更新頻度」
「サービスの質」
「初期費用」
「運用コスト」
「従業員数」
「店舗数」
「顧客層」
「顧客数」
「リスク要因」
とか色々パラメーターでバラしていかないと正しい評価はできないのでは?
露骨な印象操作とか、あまりにも杜撰で雑な作り方(人をだますにしても)なので、血圧が....上がる....
「チャンス待ち型 」と「しっかり計画する型」なら後者が上手くいく、とかそこらの小学生の坊やでもわかることじゃないのか?それで金を取る?んんん?
おじさん激おこぷんぷん丸だほよ!!!!
Monday, October 17, 2016
Wednesday, October 12, 2016
ミス慶應の事件について、思うこと
今回のミス慶應の暴行事件然り、かつての早稲田然り、その他然り、いわゆる学生間での暴行が問題となっている。(いわゆる大学のサークルの中には昔から結構危険なものがある、ということは新入生の方々は、男女関係なくよく注意してほしい)
一つにはシステムサイドからアプローチする防犯策、というものが考えられるが、ここについてはまだ私の知識的に限界があるので、女性の安全を守るためにどのようなことを今後開発していけばいいのか、について考える。
新型貞操帯
既存のありものの貞操帯には排泄時の問題があるので、それをクリアした貞操帯を開発すべきだ。これは、物理的に弱い女性がご自身を守るために必要な手段だと思う。
要件
必須要件
(1) 小便時、貞操帯が最大限汚れない
(2) 大便時、貞操帯が汚れない(貞操帯が肛門までリーチしない)
(3) 皮膚との親和性(湿度や摩擦によりむれないこと、皮膚を傷めないこと)
(4) 可能な限り軽量であること
(5) 壊すのに時間がかかること
(6) 上から下着を履けること(目立たないこと)
(7) 着用者自らが、好きな時にとりはずしできること。(認証による)
希望要件(あるとより良い)
(8) 破壊を察知すると、ネットワーク経由で通信し、GPSなどから場所を特定して警察に通報、関係者にも即時アラート
(9) 破壊を察知すると、大音量が鳴る(アラート機能)
こんな感じでどこかの研究機関や企業が開発してみては?
一見アホみたいに見えるが、 6, 7まで巻き込むとバカにできないくらい犯罪被害が減少すると思う
(これも、常時着用するとかではなく、使用者の方々が危険を予知するような場所に赴く場合に、お使いになればよい)
また、上記の実装の他では、
いわゆる女性用のガジェット(腕時計とか?)のデバイスで、ある場所を押すと(押したり思い切り叩きつけたり)大音量が出たり、通信を行って警察に連絡が行く、また、何かの施設であれば即座に察知して係員がそこに駆けつける、みたいな仕組みが必要なのではないか。
セコムはやらないのか?
ワコールとセコムとかで連携してやれば面白いのに
ないしは中小企業が
Subscribe to:
Posts (Atom)