  |
はてなキーワード: テストファーストとは
法人成りはしているけど分類は店。事業を大きくするつもりもなく人を雇いいれるつもりはないのだけど、心身を病み無職期間が続きどうしょうもないとか、一度も働いたことなく４０歳間近とか。近所とかNPOからおっつけられることがある。単純軽作業をしてもらうんだけど、考えられないようなミスをぽんぽんやらかす。時給1000円なのにカジュアルに損失をだす。
軽作業によって付与できる付加価値なんてたかが知れてて、原価950円のものをちょっと手間をかけて1000円のものにするというような最終工程を想像して。時給1000円の子なら一時間でこの作業を20回できて人件費とトントンだ。習熟度があがってそれがどれくらいいくかとか、歩留まりや変動費、固定費を踏まえて最終売価を決定する。
だけれども困ったことに、そういう子は何故かケースごと落としてものをだめにしたり何故か設備ごと破損したりするわけだ。なにかをやらかしても自分で始末ができないので熟練者の指導や補助が必要。給食当番でクラスの給食をまとめてひっくり返えす子が給食当番専任になるクラスを思い浮かべて欲しい。みんなが無事に食べ物にありつくために対その子シフトの専用のフォーメーションは必須になる。
実際に働いてみて、その後に障害者手帳をとった子も何人かいた。
こんな風に社会にぎりぎり出れないぐらいのボーダーの子は世間にはそれなりにいる。それこそ給食をひっくり返す子ぐらいには存在する。
真面目に一生懸命掃除したつもりで、結果、散らかしたのかなっていう成果しか出せない子は実在する。根気よく指導すればいずれ人並みになんとかなると思うかもしれないがそれは幻想かもしれない。
このような人は金を払って損失を買い招くようなものだから普通は雇いいれることはできず採用の段階でスクリーニングされる。日本はクビにもできないし、損害分を従業員から取るようなことはできないのだからなおさら慎重になる。もし、正社員などとして雇ってしまったら、なにかをしてもらうだけで信用問題や莫大な損失になりかねないので閑職に追いやることになるのだろう。
最低時給をあげても、その事業が市場において価格決定権があるなら問題ない。
だが、世界にはコモディティの過剰供給能力があり、あらゆる市場はほぼ完全競争になっている。プライステイカーが大勢をしめる社会で、ロースキル、ノースキルなために、時給で働く人材の活用領域はごくごく狭い。産業分類別の付加価値額や年代別の売り場面積あたりの必要人員数などをみればわかる。
最低時給をあげても新たに仕事が生まれるわけではない。← ここ重要
冒頭の軽作業でいえば1時間で20回でクリアだったのが時給1500円なら30回いかないと不採算人材になる。
不採算事業は整理され、不採算人材のボーダーが上にあがり、そこに届かないものは不要とされ、他のものに代替される。
ボーダーからぎりこぼれ落ちるぐらいの子ができる仕事を先に作らないと社会からあぶりだされ不要人材となる。
不要の用は要だ。遊びがななければ外的環境変化によって滅んでしまう。
実際の障害者と非障害者の能力は連続的でほぼ正規分布曲線に従うが公的支援は段階的だ。
最低時給を先行して一律悉皆にあげるべきではない。テストファースト。まずどっかでやってほしい。何がおこるかわかるから。
というか、外国でやった国あるよな。
プライベートなメソッドや関数をテストする必要は無いと考えています。プライベートなメソッドは、実装の詳細であるからです。
ほとんどの場合、プライベート メソッドをテストする必要はありません。 プライベート メソッドは実装の詳細です。
「プライベートメソッドはテストするな」と強く主張されるのは、ケント・ベックの影響もあるかもしれない。
例えばtwitterで、パブリックメソッドにだけテストを書き、テストが必要なほどプライベートメソッドが複雑ならそれを別のオブジェクトに切り出す必要があると発言している(twitter/kentbeck)ように、プライベートメソッドのテストに強く反対している。
またベックの書いたSUnit(xUnitの源流にあたる)には「ひとつのテストをひとつのオブジェクトで表し、それによってテストの独立性を高める」というアイディアが使われている(そのアイディアを実現するためにとても複雑な設計をしている Simple Smalltalk Testing: With Patterns)。テスト自身がひとつのオブジェクトとして独立しているなら、テスト対象となるオブジェクトのプライベートメソッドがテストできないのは当然のことになる。
が問題になる。
テストファーストで開発するなら手を動かしながら軽い気持ちで書きたい。
privateなルーチンの自動テストは面倒だ。実際にコーディングするときは最初publicにしておいてテストしてうまく動いていそうならprivateにするのだけど、この「いそう」がくせ者。いっそのことすべてpublicにしたくなる。
私は元々メソッドはprivateにしない主義なのでメソッドの場合は問題ないのだけれど、ファイル内の「関数」が問題になる。和了点計算だと和了形判定とか符計算とか和了役判定とか単体でテストしたい内部関数が山ほどある。(twitter/koba0367)
private メソッドをテストすべきか問題、原則論だけだと袋小路に入りがちだから、private メソッドをテストしたくなる具体的な場面について議論したほうがいいと思う。
自分がレビューでよく見る例としては、複数の public メソッドの重複部分を private メソッドに抽出した結果、濃い private メソッドと薄い public メソッドが一対多関係になる場合が挙げられる。設計としては間違っていないし、わざわざ public メソッド経由でテストする意義があるかというと微妙。(twitter/ts7i)
きれいなインターフェースを作ろうとすればするほどpublicメソッドじゃない部分に複雑性を追いやることになり、壊れた時に手戻りが大きすぎると思ったら、プライベートにバックドア開けてでもテスト書くようにしてます (twitter/mizchi)
しかしプライベートメソッドに対するテストを書こうとすると大概リフレクションなどで可視性の制限をすり抜けるとかメソッドの可視性を変更するといった回りくどさやコストの導入が必要になるので、じゃあプライベートに対するテストはそうしたコストに見合うのかが問題になる。
伊藤さんの答えは「原則書かないほうがいいという大前提のうえで、どうしてもというときは、"これはテストのためにpublic"にしているというコメントの上でpublicにする」だった。
自分は「テスタビリティのためにメソッドをpublicにする」っていう"実プログラムの挙動を変えること"の方が、「privateなメソッドをテストコードのみsendで叩く」よりも怖いって思ってることに気がついた。(twitter/highwide)
単体テストがホワイトボックステストだとするなら、publicかprivateかでテストの有無が変わるのは明らかにおかしいだろ。ややこしいロジックはprivateに隠蔽すべきだが、そこがテストできないなんて。 (twitter/kmaebashi)
private メソッドをテストするかどうか？ まず最初に言っておきたいのは public/private は抽象の設計の問題であって、テストすべきかどうかとは当然無関係だろうということ。(twitter/qeigoi)
特定の言語の貧弱な機能に思考が制限を受けて誤った結論を出している典型的な例。
https://b.hatena.ne.jp/entry/4684049296462116226/comment/megumin1
テストの粒度とメソッドのアクセス権は独立したものなので、「プライベートメソッドをテストすべきか否か」という切り方自体がナンセンスではあるのだが、現実問題としてはアクセス権がテストに影響するので難しい。(twitter/AoiMoe)
private メソッドのテストはすべきかどうかというより、「できるべき」であって、それができないというのも、ある種、言語機能とテストのインピーダンスミスマッチと言えるのではないだろうか、と思っている。(twitter/aetos382)
RustやGoではプライベートメソッドに対するテストが簡単にできる。
そのためかプライベートメソッドをテストすることに対して拒否反応があまりないようだ。
Rustのテストはファイル内とtests/以下の2箇所に書ける。
テストには開発用のホワイトボックステストと仕様確認用のブラックボックステストがあり、前者をファイル内に、後者をtests/に書けば良い。
例えば度々議論になるプライベート関数のテストについてはもちろんホワイトボックステスト。(twitter/blackenedgold)
Rustではプライベートに対して何の手間もなくテストが書ける。
Rustでprivateなメソッドのテストを書きたいなら、そのメソッドのすぐ隣に書けば内部アクセスになるから普通に書けるよ、ってのは目からウロコだった。できるだけ近いところにテストを書こうっていう文化と相まって最高。(twitter/kuy)
Rust のようにユニットテストをプロダクションに混ぜる方式はおれもいいと思ってて、テストとプロダクションを分離することで private 関数のテストができない問題があるけど（テストしたければクラスを分けよ/メソッドを公開せよ/テスト必要なし、に分かれるよね）、そもそもこの議論が不要になるよね (twitter/nunulk)
昨日「private method の単体テストは書くか否か」という話題がちょいとあったのだが、わしは当然書く感じの昨今を送ってきたもんで何で書かんのやくらいに思ってたんだけど、Go だと private なやつのテストが書きやすいってのがデカそう。(twitter/pankona)
golangのテスト書いてたけど、テストプログラムの名前空間(パッケージ)が、対象のプログラムと一緒で、そのためプライベートメソッドでもテストできるの良い感じ (twitter/74th)
Goのテストコード、テスト対象と同じパッケージにすればエクスポートしてない関数でもなんでもテストコードから参照できるんだけど、これってプライベートメソッドはテストすべきか議論するよりテスト書けと言われているようで好き。(twitter/plan9user)
「プライベートメソッドをテストするか？」とは別に「ドキュメントをソースコードと同じファイルに書いていい(文芸的プログラミング)なら、単体テストをテスト対象と同じファイルに書いてもいいのでは？」というのも論点になるかもしれない。
「仕事にしてしばらく経ったら大して好きでもなかったな」と「○○歳定年説」は、ベクトルが違う。
キャリアアップと言えば、手を動かす → 人を使う、の一択しかなかったから。
今は良い時代だ。
正直、アジャイルとかテストファーストとかDDDとか、どうでも良いと思ってる。
正直、真似事ですら、できるやつはあまりいない（定年説を唱えている界隈では）。
効率だ、品質だ、に、ふんづまったところで、大義名分は、ポンコツを除外できる とても良い言い訳になる。
少数で、歳は食ってるけど、その分、経験はあるやつと、経験は少なくても、知識に貪欲でパワーのあるやつだけでチームが構成できると、とても楽チン。
単純に俺が嫉妬してるだけだけど、ひとつのプログラミング言語でたくさんの人たちが慣れ合っているのを見るのが辛い。
職場で使ってるC#(いまだに2.0)もJava(いまだに1.4)も、そんな世界とは無縁なんだもん。
どんなにPerlがすごいことになったとしても、俺には全く関係ない。っていうか、仕事でプログラミングする世界というのは楽しくないはずなのに。
そして、この「プログラミングが楽しくない」というのはきっとプログラミング言語そのものとは関係ない。今の職場でPerlが使われたとしても、それは今使っているC#/Javaと同じように、訳の分からないクラス／メソッド命名ルール、肥大化してメンテのされない"共通メソッドライブラリ"、前バージョンのコードはコメントアウトして保存、テストファーストでもなくリファクタリングも許可されない、のようなやり方になるわけで。
勉強会のつもりで行ったらただのOFF会であまり勉強にならない、という事が多い。
(OFF会的な側面がメインなら、そう銘打って欲しい)
アウトプットは大切だけど、LTは銀の弾丸ではないので万能のように言うのいくない
テストファーストは有効な場面が多いけど、TDDは銀の弾丸ではないので万能のように言うのいくない
アジャイルの理念は素晴らしいけど、アジャイルは銀の弾丸ではないので万能のように言うのいくない
全ての言語は銀の弾丸ではないので、万能のように言うのいくない
アレ。。。
いじょー。
Eclipseがemacsやvimより優れている点を挙げてみよう。
・CVSリポジトリの構成を直接覗ける →redmineとかを使ったほうがいいんじゃないのか
・設定できる警告メッセージの種類が豊富。→警告そんなにいるのか
・復元機能が非常に充実している。 →バージョン管理ソフトがあれば普通だし
CVSのように以前の状態に復元すること、以前の状態の →diffじゃダメか、というかなんでいまどきCVSなの
ソースコードとの比較も容易。CVS(Eclipse標準装備)/Subversionプラグインにもこの機能は存在する。
・プラグインの数が豊富、膨大。 → 数があってもつかえるのは少ない
・プラグイン開発環境もEclipse自体に用意されている。 →開発環境を使って作る程のものでもなく、バッチファイルとかスクリプトでよくね
・ライセンス形態がCPLであり商用利用もしやすい。 →eclipse組み込んで出荷するの？
・上位版にWSADが存在する。 →WSDADってなに、WebSpereの残骸？
・Smalltalkで有名なVisualworksの影響を受けているため、
JUnitプラグイン(Eclipse標準装備)によるテストファースト、リファクタリングの他、eXtreme Programming環境が充実している。→Jenkinsのほうがよくね
・SubclipseプラグインによりSubversionにも対応できる。これはCVSよりも強力！→コマンドラインから実行するsvnコマンドを覚えておくとはターゲットでも動いて便利だよ
・Call Hierarchyプラグイン(Eclipse3.0から標準装備)によりメソッドの呼び出し階層を調べることができる。この機能は強力だ！→スタック見るだけのことじゃないの
・プラグインによってはURLを指定するだけでプラグインの自動ダウンロード、自動インストール、
自動アップデートができるためプラグインのインストールが非常に容易。→勝手に変わったら怖くない
・Eclipse上から直接Tomcat, JBossなどを再起動できるSysdeoプラグイン、JBoss-IDEプラグイン
という強力なプラグインが充実している。→えー、今頃Tomcat
・EclipseUML Omondoプラグインによりクラス図などを書いたり、
UMLによるModel Driven Architecture, リバースエンジニアリング
・RSSリーダープラグイン、MP3プラグイン、All The Newsプラグイン、
など様々なプラグインが充実している。→それ開発ツールじゃなくて携帯でやったほうがよくね
・PHP開発が可能なTruStudioプラグイン、Perl開発が可能なPerl E.P.I.C. プラグイン、
C/C++開発が可能なCDTプラグイン、AspectJ開発が可能なAJDTプラグインなど
他言語プラグインが充実している。→Java以外は所詮おまけだけどね
・そのほかにD言語プラグイン、C#プラグイン、Pythonプラグイン、JavaScriptEditorプラグイン、
CSSプラグイン, HTMLプラグイン, XMLプラグイン、(Jakarta)Velocity UIプラグイン、
Apache Antプラグイン(Eclipse標準装備)、非常に強力なApache Mavenを使うことができるプラグイン、
ゲームができるプラグイン、メーラとしてつかえるプラグイン、Wikiプラグイン、Hibernateプラグイン、
FindBugsプラグイン、CheckStyleプラグイン、Jalopyプラグイン、Sobalipseプラグイン、ソロプログラマープラグイン、
など様々なプラグインが充実している。→それぞれ単機能のソフトのほうが充実してるんじゃないの
どうしてもeclipseというなら止めないけど
というのが、作ってる人たちは「これ、正直やばいけど稼げるし短期決戦で得るもん得ていこうか〜」くらいの気持ちでやってるのかと思ってた。
実際この考えの人は少なからずいるはずだ。
あるいは、「ヤバいけど、ライバル会社もやってて生き残るには自分も参加するしかない。」っていう、
ある種の邪悪なチキンレースに乗ってしまっている事を自覚してる人たち。
この人たちは、まぁ、邪悪だけど仕方ないのかなと思う。
※なお、本当に本当の意味で『邪悪』な人たちはとっくの昔に上がりを頂戴して既にあの場にはいないはず。
少なくとも某女史は完全に逃げ切ったのかなと。
けれども、どうも中の人たちのレスポンスを見る限り、「俺たち悪い事してねーし！」みたいなことを本気で考えている人たちがいる様子。
この人たちはヤバい。何がヤバいかと言うと、「罪の意識の希薄化」がされたことに一切気づいていないと言う点でヤバい。
そしてそのヤバさが、プログラマーっていう職業に対する社会の認識が悪い方向に傾きかねないのでヤバい。
いや、もう手遅れだ。多分、後一年後にはIT業界に対する世間の目そのものが冷たいものに変わっているだろう。
まず僕はあの場で「俺悪くねーし！」って言ってる末端を攻めるつもりは無い。
（といっても役職持ちでこんなことを言ってる連中には残念ながら、だけど。）
けれども、彼らが嵌った「脱法的ソシャゲー開発」の一端は解き明かしておきたい。
何故なら、このロジックは非常に単純で、かつ効果がテキメン。特に技術職に従事する連中に対しては。
さて、例え話をしよう。
それは先端のライブラリを使い、高負荷をものともしない作りにし、
またユーザーを飽きさせないよう常時色々なキャンペーンを打っていくアプリケーションだ。
ユーザー数は膨大で、アクティブなユーザー数だけでも１０万を超す。
このアプリケーションを作成して運用するのは、いくら何でも一人では無理だ。
そこで仕事を分割し、プログラマー、インフラエンジニア、UXデザイナ、WEBデザイナー、ディレクター、
アナリスト、PM、営業…などなど、それぞれの専門職を適切に配置し、
それぞれが自分の得意な事に集中できるようにする。
こうすることで、それぞれの専門職にとって雑多な事は、耳半分で会議を聞きつつうまく回る。
さて、次の例え話をしよう。
とある邪悪な人間が、邪悪で脱法的な方法でお金を稼ぐロジックを思いついたとしよう。
しかし、規模が大きいので人手がいる。けれども、他の邪悪な連中を誘い込むと美味しいところを奪われたあげく、
責任をなすり付けられる可能性が高い。
ならばどうするか？「普通の人」を巻き込めばいい。
でも、「この方法で情弱を騙して稼ごうぜwww」というと、人は訝しみ、拒絶する。
けれども、その邪悪なロジックを分割して、分割したそれぞれの仕事が違法ではないものにすると…？
あるいは、分割したロジックを事前に３つ前後の別のクリーンな仕事に適用して失敗して後が無い状況を演出しておき、
ここで、だ。結合された後のサービスのありようを見て、「これって、ダメなんじゃない？」という人は必ず出てくる。
ここで、技術職の悪い癖を利用する。
技術職は「０か１か」での判断をすることに常にさらされているため、
そうではない世界でも「０か１か」で決まるものだと錯覚しやすい。
「うちの法務に事前に確認しましたが、法律上問題ないとのことです」と。
※注意
法務の方々の名誉の為に言っておくと、システムの邪悪さを理解して邪悪さを誤摩化す回答をする法務も一部にはいるが、
そこで、邪悪な人は特定の条件下で起こりうる例外を提示して「それならグリーンだ」と言わせておき、
その例外を隠して「この前うちの法務に事前に確認しましたが、法律上問題ないとのことです」と
法律は「０か１か」に見えてそうじゃない。
少なくとも過去に判例が出ていないものについては「０か１か」すらわからない。
ようは「未テストの項目」に過ぎない。
「裁判所」というテストを通らない限り、「０か１か」なんて本当はわかるはずもない。
それも、テストの内容によっては関係するモジュールや実行環境、タイミングによって結果が変わる事すらあり得る。
法務の言う「大丈夫」なんて、ようは自動テストやってない職場でベテラン開発者がいう「あ〜あそこはきっとOracleのバグ（※ただし未検証」と同じ程度の回答だ。
（本当はOracleのバグではなくそいつが作りこんだバグなのかもしれない。）
さて、普通の技術者が邪悪なテスト結果をまんまと信じたら、あとは邪悪な人の思い通りだ。
まず、そのテスト結果を信じた普通の人は、他にも不審に思った人に対して「あれは問題ないって法務が言ってたよ」と伝える。
が、ここでは同じテストを繰り返さず、過去のレポート、それも又聞きのレポートを伝えているに過ぎない。
もう一度同じテストをかけていない。自分の目と耳で、法務から直接話を聞いていない。
また、結合前のクリーンな仕事をしているそれぞれの担当者に取って、
結合後の姿より結合前の状態がその人の仕事の大半であり、「本当の意味での」結合後の姿を見てるようで見ていない。
単体テストはバリバリこなすだろう。しかし結合後のストレステストやセキュリティのテストは専門外として見向きもしない。
いや正確には「何かあったら、専門の担当者が文句つけてくるはずだ」と待ちの姿勢でいる状態だ。
邪悪な人は、間違いなくその専門の担当者が各部署を回って抜き打ちテストをやらせるなんて事はしない。
そもそも専門の人を社内に常駐させないか、もしくは置いても他の事（例えば他社とのライセンス問題など）にリソースをさくよう仕向ける。
だから否定されると「俺悪くねーし！」と言い出す。
細分化された仕事のことしか見なければ悪いことは何も無いだろうね。
しかし…もう…嵌っちゃったんだなぁというのが外野からの印象。
まぁせいぜい人身御供になってくれ。
今回の件、役職だけではなく実務の担当者まで引っ張られる可能性はある。
裁判にかけられるかどうかは謎だけど、企業や業界への揺さぶりの手段としては有効だしね。
なお、最初に言ったが本当に邪悪な人はもう既にあの場所にはいないはずだ。
もう既に後進に道を譲るだの自分の力を別の場所で試したいだのもっともらしい理由を付けて、
「普通の人々」のその後がどうなるかはこれからの物語なので、とても楽しみではある。
おそらく、なのだが、この件、ワーストケースで転がれば、当該の企業だけではなく
「ITの技術者はマッドサイエンティストと同じで法の遵守する気がない連中だ！」と言われる日は意外とそう遠くないと思う。
そんな風がもし吹こうなら、政治家の先生方や警察のお歴々も「インターネットの健全性を保証する」という名目で、
色々と無茶な法律を作るかもしれませんね。
少なくとも、「インターネット＝悪」として自分らの有利な方向にネットをコントロールしたい方々にとってはとても好都合でしょうよ。
そろそろ、誰かが「良い意味で」健全化のために何かを仕込む頃合い。
政治家や警察といったレイヤーではなく、業界の自主努力のレイヤーで。
２、３年後、どんな団体ができでどんな人が所属するかなぁ？
ダンコーガイ、津田、はまちちゃん、ちきりん、高木先生、漢のMySQLの人、徳丸本の人…多分この中から二人は自ら、あるいは担ぎだされる/巻き込まれる形で関わってくるかな。
切込隊長は面白おかしくレポートしつつ裏で謎の秋波を送るんだろうなぁ。
多分ひろゆきはその集まりを「つまらない」と見て何もしないかな？
ま、きっと「自分は忙しいから…」みたいなことで誰も参加せず、
Eclipseがemacsやvimより優れている点を挙げてみよう。
ソースコードとの比較も容易。CVS(Eclipse標準装備)/Subversionプラグインにもこの機能は存在する。
・上位版にWSADが存在する。
・Smalltalkで有名なVisualworksの影響を受けているため、
JUnitプラグイン(Eclipse標準装備)によるテストファースト、リファクタリングの他、eXtreme Programming環境が充実している。
・SubclipseプラグインによりSubversionにも対応できる。これはCVSよりも強力！
・Call Hierarchyプラグイン(Eclipse3.0から標準装備)によりメソッドの呼び出し階層を調べることができる。この機能は強力だ！
・プラグインによってはURLを指定するだけでプラグインの自動ダウンロード、自動インストール、
自動アップデートができるためプラグインのインストールが非常に容易。
・Eclipse上から直接Tomcat, JBossなどを再起動できるSysdeoプラグイン、JBoss-IDEプラグイン
という強力なプラグインが充実している。
・EclipseUML Omondoプラグインによりクラス図などを書いたり、
UMLによるModel Driven Architecture, リバースエンジニアリング
などを即座に実現できる。
・RSSリーダープラグイン、MP3プラグイン、All The Newsプラグイン、
など様々なプラグインが充実している。
・PHP開発が可能なTruStudioプラグイン、Perl開発が可能なPerl E.P.I.C. プラグイン、
C/C++開発が可能なCDTプラグイン、AspectJ開発が可能なAJDTプラグインなど
・そのほかにD言語プラグイン、C#プラグイン、Pythonプラグイン、JavaScriptEditorプラグイン、
CSSプラグイン, HTMLプラグイン, XMLプラグイン、(Jakarta)Velocity UIプラグイン、
Apache Antプラグイン(Eclipse標準装備)、非常に強力なApache Mavenを使うことができるプラグイン、
ゲームができるプラグイン、メーラとしてつかえるプラグイン、Wikiプラグイン、Hibernateプラグイン、
FindBugsプラグイン、CheckStyleプラグイン、Jalopyプラグイン、Sobalipseプラグイン、ソロプログラマープラグイン、
など様々なプラグインが充実している。
PHPerの問題点は、視野が狭いこと。典型的には以下のような悪癖を持つ。
何も知らないからPHPを愛せるんだよ、PHPerは。だからまず、HTML、CSS、JavaScript、SQLを覚えろ。次に、Javaに移行しろ。そんなに難しくないよ、Java。特に大量にコードを書けるPHPerは、速度が出てライブラリ化が容易なJavaの方が向いている。今はVPSがあるので、小規模案件でも問題ない。
15年間ほどPHPはインターネットを支えてきたが、そろそろ設計の脆さが問題になっている。PHP 6の開発が振り出しに戻ったのは、不幸な事故ではない。ウェブで仕事をしていれば、PHPとJavaで共通する知識も多い。PHPerはJavaを覚えてPHPとさよならしろ。そして恥ずかしい悪癖を直すべきだ。
やったことない商売はなれるまで時間かかるから、あてこんでのスタートはやめたほうがいいよ。
テストファーストじゃないけど、最初は金をかけないでなにごともはじめるのがおすすめ。
金をかけないで何ができるかを考えよう。
さすがに漠然としすぎててありきたりのことしか考えられないよ。
いま住んでいるところの土地はひと坪・・・
http://www.land.mlit.go.jp/landPrice/AriaServlet?MOD=0&TYP=2
約５５万/平米、 坪＝３平米だっけ？・・・。
http://blog.livedoor.jp/dankogai/archives/50979976.html
試訳 - コードをセキュアにする10の作法
セキュアとかいまだに和製単語がないの……？ 根付かないわけだわ。
この10の作法みてても、まるっとただのwebコーディングの話しなのであまりピンとこなかった。
つーか、なんか、ほんとはてブってLLな人ばっかりだよね。
せっかくの内容なので、ちと裾野を広げて考えてみたよ。
どのような操作をうけつけるのか、どのようなデータをうけつけるのかまず最初に決めましょう。
そして受けとったものをもとになにをしたいのか明確になっているのはもっとも重要なことです。
お金のかわりに注文をうけるだけなんていうのもありますよね。
まず最初に決めておくのが重要なことです。
1で決めたように挙動の想定なしには規定外のデータの受け渡しなどは追うことができません。
想定内以外はすべて想定外に落とすのが悪意から身を守りやすいです。
構造的エラーはtryで括るなり、error procでおとすなりし、
構造エラーが起きたときにどこでどのようなエラーが起きたのかは最低限いつでも追えるようにしましょう。
（PHPとかでtryつかってるひといる？）
3匹の子豚の童話をおもいだしてください。
ドアには鍵をかけられるようにして、暖炉には火をともせるようする必要があります。
そしてなによりその前提は建物が頑丈であることです。
その場所に狼が住んでいるのかいないのかは家の設計に大きな影響を与えます。
また狼がいるのがわかったら家を建てる必要があるのか吟味するのはとても重要なことです。
社内のLANで済ませれるシステムをわざわざon Webな設計で建てる必要はありませんよね。
部品が増えれば大工さんの工数は増えますし、住んだあともお掃除が大変です。
家を建てるのにいくら掛かるのか？
そのサイズの家を建てたら家政婦さんにはいってもらわなければならないのか？
家政婦さんがいいのかメイドがいいのか？
庭師をいれなければならない大きさなのか？
警備員を雇わなければいけないのか？
自宅警備員はやくにたつのかたたないのか？
お財布と相談するのは非常に重要なことです。
本当は1Kで十分なんじゃないですか？
見栄はときに判断を見誤らせます。
もしあなたが建てるのを手伝う側だとしてもお客さんを諭すのは大切な仕事です。
家を建てるまえにその地域にすんでみるのも必要です。
甘い言葉に騙されていきなり30年のローンとか抱えないでください。
完成例ばかりに目を奪われると完璧なものばかりに目がいき真似したくなります。
もしあなたが商売を始めようとして、そこに経験がなかったらどうしますか？
路面店を構える前に自転車の後ろに商材つんで売ってみてからでも遅くはないのでは？
最初からすべてを用意しようとすると取り返しがつきません。
「だってみんなやってるよ！」
そういったときに親からなんていわれたか思い出しましょう。
規模に応ずることは非常に重要なことです。
システムキッチンをつかったこともないのに新しく建てようとする家に入れたいのはどうしてですか？
ほんとうに自分にあった家をたてたいのであれば、まずはあれこれ使ってみることが重要です。
あなたのつくった木造の小屋がもし火事になった場合どのような被害を出すか考えておく必要があります。
どんなに頑丈な設計をしていたとしても、地震や台風、放火など”ありえない”なにかの災害はおきうることです。
そのときにあなたのつくったものはどうなりますか？
まわりの建物に火がまわってしまいませんか？
危険というものはすべてを排除しようとするのは困難です。
もしもの時にそなえる方法はいくつかあります。
火災保険にはいるだけではなく、消火器などを用意して被害を最低限に抑えるということも重要になります。
数千円の消火器で家の全焼が防げるならコストパフォーマンスは悪くないですよね。
Hedgeとassessmentは別々(並列)にもうけることができる性質のものです。
ヘッジばかりで満足していませんか？
あと、風の強い日に焚き火をしないとか、そういうわきまえも大切ですよね。
(risk deterって言葉ないね？ こーゆーのなんていうん？）
割られてしまった窓ガラスはさらにわられないために早めに直しましょう。
できるだけ早く「対応した」と見せかけるだけで大きな効果があります。
次なる悪意から身を守る術はできるだけ早い対処です。
検収さえのりきって瑕疵責任だけまぬがれるような糞システムねじこんだらいいやとおもってるから、いつまでたっても糞なんだよだぼがぁあ！！
・・・ゴホン。
失礼しました。
つくったものは古くなります。
建物の場合だってニスを塗り替えるだけで経年劣化は相当防げます。
そのために既成関数などをラップ関数に差し替えて最初に書いておくのも実はメンテナンス効率をあげる手段だとおもいます。
全財産を引き出しに入れておくとか、そういうことはしてはだめですよ。
個人情報だってそもそも集めなければ取られる必要がありません。
不必要なものを保持しておくのは初期費用も保守費用も莫大に押し上げます。
使用用途ができてからでも遅くはありません。
部屋を綺麗にしておきたいなら要らないものは買うな！！
(部屋汚くてごめんなさい……。)
成功例、失敗例、参考にするのは非常に有意義なことです。
ですが、その意味もわからず模倣することほど意味もなく危険なことはありません。
あなたがだれかの真似をして飛ぼうとするまえに、自分の足元を確認する必要があります。
でも自分と他人というものは違います。
相手がどんなものであれ、それをもとに自分を磨かなければ意味がありません。
また相手がどんな体験をしたのであれ自分を磨くことの役に立てることはできます。
人のせいにするのは簡単な事です。×××でよんだから、×××で見たから。
でも、そもそもこの記事だって猫が偶然キーボードの上で暴れて書いたものかもしれないのですからニャー。
日本円を受けるところでインドルピーうけてちゃレートもわからなければ偽札も区別できないよ！
リスクアセスメント（リスクアクセスメントだと思ってたのは内緒）
いいえケフィアです
みんなってダレ？
ヨソはヨソ、ウチはウチ。
全焼
火の用心！
いいえ、あなたの心です
他山の石
ニコニコの時報。
これができると何ができるかというと、運営が決められた時間にＣＭを流せるということ。
詳しくは追っていないのでわからないけど、
ギャオみたいに前後に割り込みというのはメディアサーバーの機能としてもっている。
だが、ぶったぎって割り込みとなると、プレイヤー側にも細工をしなきゃいけないし、
なにより複数ストリーミングサーバーでの振り分けは相応に厄介。
時報を裏でスプールしてるのかな？
もしかしたらプレイヤーの中にプレイヤーをいれてフリップしているだけかもしれないけど。
なんにせよ、ストリーミング最中のストリーミング割り込みは難しい。
みんなやれなかったぐらい難しい。
Youtubeだってできていない。
これができると何ができるか。
長い尺での動画を運営側が歓迎することになるだろう。
rimoみたいにノンストップチャンネルができるのも時間の問題だ。
なんにせよ、いきなりＣＭではなく技術的なテストファーストとして時報をもってきたのはセンスとして物凄い。
傑物だとおもうよ実際、まろゆき・・・。
http://anond.hatelabo.jp/20070313163701
そんな意見を聞く。
そもそも実験できたとしても目指す社会像自体が人によって違うんだから駄目だろ。今日の晩御飯はカレーにするかラーメンにするかでもめてるところに料理方法に詳しい奴が来たところで揉め事は収まらない。
