どうしたものやら…

先に。「答えの出ていない問い」なので、そんなに歯切れのよい結論とかありませんので念のため。

元ネタはこちら。
突如発表された『拡散性ミリオンアーサー』 サービス終了の真相を訊く
http://app.famitsu.com/20141226_479007/

色々と「難しいなぁ」と、いろんな角度から思ったので。
まだ考察中のネタなんで悩みながら、一端、文章化してみようかなぁ、っと。
とりあえず、重要な箇所はこの辺。

もともと『拡散性』を配信する前後で、とあるどうしようもない事情からコアスタッフが抜けたんです。

コアスタッフが抜けてしまったがゆえに、核となるプログラム部分がブラックボックスのようなものになってしまい、それを手探り状態で更新していたんです。それをなんとか打破しようと考え、運営１年後のタイミングでいまの運営会社に移管をしました。そのタイミングでプログラムを1から作り直そうという話もあったんですが、通常の運営をしながら並行して新規でプログラムを作るのは思った以上の難易度で、想定していた作りにはなりませんでした。結果、運営のしやすさはさほど変わらない状態で、新しい仕組みを取り入れることも難しくなっていました。

割とあちこちで見受けられる状況な上に、あんまりにも「色々な可能性」があって、その色々毎に考察ポイントがあったりするもんで、この文章を書くに至ってみたり。
とりあえず雑に要約すると
・コアプログラマが抜けた
・その人以外では「核の部分」に手を出せない
・リメイクしんどい
・故にサービス終了
ってな感じかなぁ、っと。

ん…多分「よくある論調」で持ってくると「属人性ヨクナイ！」って話になるんだろうと思うんだけど、正直、そんなに簡単な問題じゃない可能性が想起されてみたり。
簡単な可能性としては
・作りが超キタナくて
・作った本人以外手が出ない*1ようなとっちらかりっぷり
のブツなのがあって。
…それにしてもなお
・ンな汚いコード書くな
以外に
・「とっちらかってること」を、発注側とかディレクターとかプロデューサとかがどうやって把握捕捉するか？
って問題が横たわってみたり。

少し先に横道にそれると「コアプログラマは、他の人に技術継承をしなかったんだろうか？」って疑問はまぁ出てきて。
・当人にその気がない
・周囲にその気がない
・工数的に無理ぽだった
あたりの可能性があって、それぞれにそれぞれの突っ込み所が。
「当人にその気がない」場合、当人に意識改革をってのもあるんだけど同じくらいに「ちゃんと周囲で仕切ってる人間が継承を促す」ってのも重要だし。
「周囲にその気が無い」については場合によっては「首を切ってでも、その気のある人間をある程度揃える」重要性。
「工数的に無理」については、マネジメント失敗してる、としか。

で…多分一番憂慮すべき可能性って「難易度が高くて他の人に手が出ない」場合。
何を以て難易度を高いとするかってのは勿論あるんだけど。

恐らく、ビジネスにある程度さとい人なら、こう考えると思う。
「結局の所"お仕事"でコードを組んでいる以上、周囲が付いてこれないレベルのものを自己満足で組んでいるのは、結果的にビジネスに悪影響を与えるのだから、ある程度技術レベルを落とした、周囲のレベルに合わせて配慮したものを納品すべきである」。
これについては正直「程度問題」としか思えないし、どちらかというと(今の)おいちゃんはこの見解には基本、否定的。

わかりやすく、極端な一例を。
・わからない人がいるからオートマトンは使わないでくれ
・わからない人がいるからオブジェクト指向プログラミング(クラス)を使わないでくれ
・わからない人がいるから共通関数は作らないでくれ
・わからない人がいるから配列は使わないでくれ
困った事に「全部実話」です。
有難い事に、幾つかは伝聞ですが。

結局の所。
技術は「それがないと困っているところで編み出された技法」なので。無論「乱用は厳に慎み、忌むべき」ではあるにしても、最低限を「適切に使う」場合において、技術ってのは「非常に重要なもの」ではあるわけです。
つまり「技術を使うな」って事は「出来ない事が発生する」や「非常に非効率なやり方になる」事を意味する訳なのでございます。

勿論「とはいえ、他の人が扱えなくなるのは困る」ってのが天秤の片側に乗ってるんで、そう軽々に「学べ」で片付くもんじゃねぇだろうなぁ、ってのは、重々承知ではあるんですがね。
ただ「ある程度技術レベルを落とした、周囲のレベルに合わせて配慮したものを」って発言は、割と簡単に「水が低きに流れるが如く」駄目な方に行きやすく、結果的に「よりしゃれにならんブツが仕上がってくる可能性」が十分に想起される上に「それを抑止する方法が今ひとつ、明確になってない」んですね。

無論それで「学習させているうちにビジネスが潰れたら意味あんめ？」ってのはあるのですが。

まぁそこから考えると。
・可能な限り優秀なメンターを若干名
・適度に熟練度があり、且つ十分な向上心がある一般職人をある程度
・溢れんばかりの学習意欲に満ちあふれた見習いを、一般職人が扱える程度の数
ってな取りそろえを「如何に全力で取りそろえるか」って話になるのですが…まぁ「熟練職人ってどこにいるんですか？ http://www.mars.dti.ne.jp/~hirok/sekai/bou/bou387.html 」って話になるんですけどねぇ…えぇ…でも、それ以外に良い方法思い浮かばねぇのよ正直。

ただ。
その辺前提で考えると。どうにも「ある程度技術レベルを落とした、周囲のレベルに合わせて配慮したものを」って発言って。
勿論、真摯に捕らえるのであれば十分に「一考以上の価値がある」はずなんだけど、現実的には「現状維持と怠惰となまけの言い訳にしかならない可能性が高い」と考えられる状況が多すぎる訳で。

そうすると。
無論、書く側に「ちゃんと教育する胆力を要求する」前提ではあるにしても＆加減ってのはあるにしても、基本「上にあわせる」方が、最終的に獲られるモノが多いんじゃねぇかなぁ？ とか思う訳なんですよ。
その辺まで全部考察した後で改めて読むと、色々と、考えてしまう訳なんですねぇ。

コアスタッフが抜けてしまったがゆえに、核となるプログラム部分がブラックボックスのようなものになってしまい、それを手探り状態で更新していたんです。それをなんとか打破しようと考え、運営１年後のタイミングでいまの運営会社に移管をしました。そのタイミングでプログラムを1から作り直そうという話もあったんですが、通常の運営をしながら並行して新規でプログラムを作るのは思った以上の難易度で、想定していた作りにはなりませんでした。結果、運営のしやすさはさほど変わらない状態で、新しい仕組みを取り入れることも難しくなっていました。

何故にそこが「ブラックボックスになってしまったのかなぁ？」と。

現場の下っ端も中堅所も現場の技術仕切ってる人もプロジェクトをディレクションしている人もマネジメントしている人もプロデュースしている人も発注している人も。
割と真剣に考えておかないと、結構「激痛が走る」所なんじゃないかなぁ？ とか思うわけなんですね。

などという雑文を、つれづれと。

*1:下手したら、作った本人「でさえ」手が出ない

「質」と「心構え」

技術者として「現場にいる」時に。
どんな風に心の向きをおいていくか、ってのは、案外と難しい問いだったりするのですが。
そんな時に一助になりそうな書籍を。

おせん(1) (イブニングKC)

おせん 真っ当を受け継ぎ繋ぐ。(1) (イブニングKC)

王様の仕立て屋―サルト・フィニート (1) (ジャンプ・コミックスデラックス)

王様の仕立て屋~サルトリア・ナポレターナ~ 1 (ヤングジャンプコミックス)

いずれも、現場仕事をする人間にとって「なにがしか考えさせられたり参考になったり」する内容が諸々あるかと思います。
どっちも１巻しか紹介してませんが。
おせんさんは、古い方が16巻完結、新しい方が11巻完結。
王様の仕立て屋のほうは、古い方が32巻完結、新しい方が７巻継続中。

どちらも、一読してそんのない物語かと思います。
こーゆー「心構え」って、実は知識や経験と同じくらいに大切なんだけど、それが「継承される」状況が昨今特に減っているような気がするので。

お金を稼ぐってのはやっぱり大事！

嫌儲を声高に叫んでも別に否定はしませんがとはいえ霞を食って生きて行く訳にもいかんわけで。
ってことは如何に「経済をぶんまわすか」ってのは大切なんですが。
その辺で、極めてよろしい良書です。

人はなぜ形のないものを買うのか

人はなぜ形のないものを買うのか

この本が出来た由来とかお話も大変にぶっちゃけ「爆笑」なものがございまして、他にも良コンテンツを書かれている、「実務と学術のバランスの良い」御方………でした。
過去形な理由は、いかのURIをご覧下さいませ。
http://d.hatena.ne.jp/gallu/20140109/p1

ゲームの話が多いですが、それ以外にも十分に意味のある内容なので。
ビジネスに関わるのであれば〜つまり全員〜一読を強くお勧めいたします。

ってな訳なので。
学生さんにも「ビジネス」ってキーワードは重要だと思っての紹介でした。

ヨーダ記法を応援します

軽く各方面とバトりそうなネタなれど。

まず。
ヨーダ記法(ないしNTT記法…って、うちのまわりではいってたんだけど、ググるとあんまりでてこない)ですが。
これは「if等の比較演算において、左辺に定数、右辺に変数を置く」記法です。

とりあえず幾つかネットで拾ってみる。

http://uchidak.net/yoda-notation

このようにヨーダ記法とは、予期しない代入を防ぐために産み出された安全側へ倒すための書き方です。
しかしながら、現在はコンパイラがよしなにしてくれるため、あえてヨーダ記法で可読性を失うような書き方をすることをリーダブルコードでは推奨していませんでした。

http://qiita.com/moriturus/items/723eb17873381f94baf8

確かに、ヨーダ記法(1 == hogeのように記述する)は、発見しづらいミスを防ぐのに有用かもしれないが、明らかに英語として不自然である。(if 1 equals hogeよりもif hoge equals 1のほうが直感的)

http://www.tom-gs.com/weblog/27-web%E3%80%81web%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0%E9%96%A2%E9%80%A3/314-%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0%E3%81%A8%E3%82%B9%E3%82%BF%E3%83%BC%E3%82%A6%E3%82%A9%E3%83%BC%E3%82%BA%E3%83%BB%E3%83%BB%E3%83%BB%E3%82%AD%E3%83%BC%E3%83%9E%E3%83%B3%E3%81%AF%E3%83%A8%E3%83%BC%E3%83%80

ただプログラマからするとちょっと気持ち悪い。
プログラマ的には条件の対象となる値は左辺に、条件の値を右辺に書きたい。これは「Does $num equal to 1?」といった英語の文法に関わっていると思う。
ヨーダ記法だと「Does 1 equal to $num?」となる。変ではないが、「1は$numと等しいか？」とするより「$numは1と等しいか？」とするほうがわかりやすい。

http://mindia.jp/medicalcloud/%E3%83%A8%E3%83%BC%E3%83%80%E8%AA%9E

確かに、if(null==obj)...みたいな書き方はヨーダっぽいですね。意味が分かりにくいから書きたくないですが。

http://tsurujiro.blog.fc2.com/blog-entry-57.html

この記法はヨーダ記法というらしいです。この書き方なら定数に値を代入することができないため、コンパイルエラーとなります。しかし、僕はこの記法を初めて見たときには、とても奇妙な印象を受けました。おそらく、順序を逆にするとソースコードが不自然で読みにくくなるからです。

http://cloudsquare.jp/hibiki/?p=302

コンパイルでエラーになり、バグを減らすための工夫。
プログラムは文章であり、シナリオであると考える私は、嫌いな書き方なのでやらないが。

https://sanematsu.wordpress.com/2012/08/13/readable-code/

ヨーダ記法見たらリーダブルコード読んでない認定していい

http://sss.kitetu.com/F85E/A-84F5/%E3%83%A8%E3%83%BC%E3%83%80%E8%A8%98%E6%B3%95

利点は，主に代入と書き間違えたときにコンパイル エラーになること。欠点は，英語をはじめ多くの自然言語の語順に慣れた人間にとっては感覚的に不自然であること。

http://miffysora.wikidot.com/if

しかし、ヨーダ記法で書くと、読みにくくあるので、今風じゃない。

うんうん面白いなぁ。
いやまぁあえて「否定的見解ばかり」切り抜いたわけなのですが(笑
幾つかを除いて「自然じゃない」「読みにくい」としか書いてない。

いったい、先人達が「なぜ」わざわざ、ンな読みにくい書き方を「会得するに至ったのか」って背景とか、なんにも考えてないんじゃないかなぁ？ としか。

んと…とりあえず、ここ。
http://under-siege.jugem.jp/?month=201311

==を=に誤ったとして、
if (obj = null) {
は、trueになり、
if (null = obj) {
はコンパイルエラーになるので安全なのだけれど、不自然で読みにくいし、いまのコンパイラは警告を出してくれるので、もうやめちまおうぜ！という意見。

で、ここ。
https://gist.github.com/ajiyoshi-vg/d72b2cae129d73a405e4

貫禄のPHPは、なんの警告もつけないし、黙って実行する。いいね？

Java、PHP、および昔のCなどの環境では、残念なことに「老害」の意見には一理ある。

「自然じゃないからキモチワルイ」とかいう方々の意見はドン無視するとして。
…一回だけ書いておくと「そもそもプログラム自体、見る人がみたら自然じゃない」わけだし、「自分の感性と実利と、どっちを優先するの？」ってのもある。
別所で「プログラミングが上達するかしないかの分岐点の一つに"ルールをある程度無条件に受け入れられるかどうか"っていう適正のはかり方がある」的な話を読んだ記憶があるのも、なんか色々とうなずけたりする。

で、本題。
文脈的に「コンパイラなどが警告を出してくれる」環境においては、ヨーダ記法は「メリットが失われている」し、その状態で「より多くの人が"読みやすい"と感じる記法 vs "読みにくい"と感じる記法」なら、当然ながら、読みやすい方がいい。
ちなみに「左辺値に定数」がそんなに読みにくいのか？ と聞かれると正直おいちゃんは「別に？」としか思わないんだけど、こんだけ多くの人が「感情的に騒いでる」んだから、きっと「多くの人達にとっては読みにくいんだろうなぁ」と思う訳なので、特にそこに対して反論はなし。別に「右辺に定数だと読みにくい」って訳でもないし。

ただ、残念なことにおいちゃんが扱っているのはPHPだ。
if内で代入が「出来る」し、正直「それを一つのテクニックとして使う事もある」ような状態だ。
なので、気をつけないと「代入が、間違いなのか意図しているのか」が、判断しにくい状況だってあるのだ。
例えば、こーゆー構文で「判定式で代入使う」ケースを、PHPerなら、見たことがあると思う。

while($row = $res->fetch(PDO::FETCH_ASSOC)){
　　なんか、処理;
}

なので。
ヨーダ記法には、正直「十分なメリットが存在する」のだ。PHPの場合。
で…実際、PHPの界隈においても「ヨーダ記法は時代遅れの老害テクニックだ」とか騒ぐ連中がいる。

ふと思い返すと…

例えば「global変数」で同じような話をきく。
「地獄を実体験している」と「global変数とその使用者、死すべし！」となるわけなんだけど、その辺の実感がないと「便利でいいぢゃん」とか言い出す。

例えば「動的な型」で同じような話をきく。
そも、一度、マシン語やってからC言語にいってみたまへ。型という概念がどれだけ恩恵にして福音であるかが、身に染みると思うっていうかおいちゃんは身に染みている。
あんど、2a問題( http://d.hatena.ne.jp/gallu/20061108/p1 )も参照のこと。比較演算子は === であって、== ではないのだ！(あえての断言)
あと、戻り値が「状況によって型が違う」とかやめてマジで orz
# 久々の(?)PHP disり発言(笑

個人的には最近、この方角で「関数切りすぎ問題」に割とちょいちょい出くわすので、それは別に改めて書いてみたい。
メリットが見えきれない(０たぁ言わんが、そのメリットを使っていないんならそれは０だ)上に、メンテがしにくい。

まぁ…別に「老害だなんだ」騒ぐのはいいんだけど。
それで痛い目にあって泣いた後に「同じ事が言えるのかねぇ？」とか、量的にはそれなりの経験をもつ(んだと思う多分)おいちゃんは、思ってみたり思い返してみたり思い出してみたりする。

多分、定期的にヨーダ記法の話は出てきそうだなぁ、と思ったので、よいタイミングなんで、メモり。

追伸
………Javaはコンパイルエラーになるって信じてたのに orz

知識労働者を語るドラッガー

いやまぁドラッガーの書籍自体は
http://d.hatena.ne.jp/gallu/20140617/p1
で一度取り上げているんですが。

ドラッガーは「マネジメント」だけじゃなくて「知識労働者(ナレッジワーカー/knowledge worker)」ってな事をおっしゃっていて、これがまた大変にエンジニア関連と馴染みがよいので、そちらの角度から。

…とはいえまずは「最ベーシック」なこちらを。

マネジメント[エッセンシャル版] - 基本と原則

有名所ですんで、一度はどんぞ。

で、メインはこちら。

［英和対訳］決定版 ドラッカー名言集

和英の対訳なんで、色々と勉強になります。
あと、電車とかで「とりあえず数ページ」とか読みやすいのも楽。

プロフェッショナルの条件――いかに成果をあげ、成長するか (はじめて読むドラッカー (自己実現編))

時々するのですが「プロフェッショナル、の定義は？ 必要十分条件は？」っての、考えると色々と出てきたり悩んだりするもんなんですね。
一度、その辺を考えてみるのも面白いんじゃないか？ と思うのです。

テーブル設計

基本は以下の通り

• ユーザテーブル

→ユーザの情報が一式。「１レコードが１ユーザを意味するテーブル」。

• 商品テーブル

→商品の情報が一式。「１レコードが１商品を意味するテーブル」。在庫管理は一端なし。

• 受注テーブル

→受注情報の根っこ。「１レコードが１つの受注を意味する」テーブル。

• 受注詳細テーブル

→受注の情報が入ってる。「１レコードが、１つの受注の１種類の商品を意味する」テーブル。

• 管理者テーブル

→adminのログイン情報が入ってるテーブル。

うんまぁ５枚か。
ユーザテーブルと「配送先」を分離するか僅かに悩んだのですが、普通のECだと「１ユーザで２つ以上の配送先」って少なそうなので、一端同梱。

後で変えるかもしれないのですが、一端、このテーブル構成で考えてます。

目的

基本的には
・コード含めて、設計が出来るだけ平坦でシンプル
なものを作る予定。
機能としては「ギリギリECとして成り立つ」程度まで削り落として。
どちらかと言わなくても「エンジニアがカスタマイズする前提」にしようと思っています。

受託での実務の実用を考えているので、ある程度「古いバージョンでのPHP」でも動く事を想定。
確認はしないけど、基本的に「PHP5.2系」で行けるくらいの状況を想定したいと思ってまふ。

他のあちこちのプログラムは「エンジニアがいなくても色々出来る」ところに結構いろいろなリソースを割いていると思われるので。
その辺は割り切って「プログラムが書ける人がいる」前提で。

ポイントポイントで「こーゆー機能を追加したいときはこんな風に書きましょう」で枝を入れておく感じ。
…なので、DI機能入れたほうが良いだろうなぁ(後で解説します)。

上述を前提に、おいちゃんが出来るだけ「実用的かつシンプルで綺麗なもの」を目指して行ければなぁ、と思います。