  |
はてなキーワード: 名前空間とは
Qiitaに書こうかと思ったけど、言いたいことも言えない、こんな世の中じゃ。
モバイルファースト、APIファーストな文脈でハイブリッドWebをやってきた目からすると、サーバーサイドでHTMLを生成してページ遷移させるなどという90年代調のクラシカルな発想を基本に据えるフレームワークはとても斬新に思えました。HTMLをゴリゴリ生成するなんてよほど特殊な最適化をしようとするのでなければそもそも発想として出てこないです。それでいてDSLやメタプログラミング等のテクニカルな技法が宝石のように鏤められている様はまるでエジプト時代の骨董品を見るかのような趣がありました。turbolinkなどは、かつて表計算ソフトに出しゃばっていたイルカを思い起こさせる味があります。かつて慣れ親しんできたSPAが星のように遠い存在になりました。
Web界隈の人々がモデルだとかアクティブレコードだとか"MVC"だとかを非常に具象的に話す様を見るにつけ、お前らどんだけPofEAA読み込んでるんだよと畏怖していた時期が僕にもありましたが、どうやら彼等はRailsのクラスやディレクトリという特定の実装について話していただけだったようです。Modelという概念もこれだけ肥大化してしまったら、オリジナルな概念で彼等と会話するのは諦めるべきかなと思いましたし、Railsの"MVC"をアンクォートして語るのはもはや害悪であるとすら感じました。
Rails界隈の人がよく「Railsの流儀」や「正しい"MVC"」というのを口角泡を飛ばして議論しているのを目にするのですが、おそらく外に広がる不条理で火傷を負って快適なRailsの世界に引き篭もった結果としての一種のストックホルム症候群なのだなと思いました。いまやAjaxとかWebsocketとかWebRTCとかを組み込もうとする至極真っ当な方法論がとてつもない高難度に見えてきます。設定よりも規約、というのも一つの方向性だと思いますが、ドメインやサービスレイヤの名前空間を構築しようとしたりコードジェネレーションしようとしたりしただけで地獄のようなCircular Dependency罰を受けてしまったので、自分がとても間違った事をしているような気がしてしまいました。とはいえConcernsに特別な名前や役割を与えられても正直しんどいので、皆が皆libにゴミを放り込んでいく様子にも納得がいきました。
RailsをAPIサーバーとして使おうとするとまずビューが無くなってMとCだけになりますが、いわゆる"MVC"の文脈で育ったエンジニアがなぜ息を吸うようにFat ControllerやFat Modelを作ってしまうのかという事が良く分かりました。多くのRailsのリファクタ手法と称されているものはクラスを書くファイルを分割する事以上のものでは無いように思えたので、Rails使いを大きめなAPIサーバー案件に回すときはセットポジションでDDDの青本を投げつける必要が有るなと思いました。
ビューとコントローラを結合させた場合、結合テストはCapybaraとかのBDDでマークアップサイドとの干渉を恐れながら強い気持ちでメンテしていくしか無いのかなと思いました。おそらく脳に電極を埋め込んでいるか、緑色のランプを見るだけでハイになれる特殊な人にしか生き抜けない闇が垣間見えました。コントローラを薄くしてサービスレイヤを挟めばその辺りもうまくいけそうな気がしましたが、ビューからヘルパーやモデルがいくらでも透けて見えてしまうという状況では裏側の完全性に自信を持つ事は難しそうでした。
ビューがRubyを叩いて永続化レイヤと直接コミュニケーション出来るというのはとても生産性が高いのだろうとは思いましたが、こうして出来たパーシャルやら何やらをデザイナーとどうやって共有するかを考えると頭痛が痛くなりました。おそらく適当に切り出して綺麗な空間をassets以下に構築した上でpublicにRPCのような窓口を備えたゴミを量産していくのかなと思いましたが、もっと綺麗な方法はあるのかもしれません。でもきっとRails案件に関われるデザイナーはRubyもバリバリ書けるに違いないはずなので、ここが問題になる事は無いのだろうなと思いました。
RESTはとても美しいパラダイムではありますが、そもそもHTTPがさほど美しくないので歪んだ空間には目を背けるか勝手解釈を与える事で人は初めてRESTfulを名乗る事が出来るのだと思います。GETがbodyを(公式には)持たないという事について美しい説明を与える事は出来ないでしょう。サーチAPIはどうしますか。ステータスコード足りなくないですか。401エラーはどうしますか。そしてRESTはあくまでリソースを抽象化する美しい概念なので、アクションや副作用については貧弱です。動詞が足りないですし、一般動詞に狭義の意味を与えてドキュメントするのは二度手間にしか見えません。PUTには冪等性があるべきみたいなこだわりは家の猫にでも説教してればいいと思います。というわけで、REST的な設計を拝借することはよしとしても、「○○はRESTでは無い故云々～」みたいな注文はやめて頂きたいものです。
とか言わないで欲しいです。こういう時にセットでPHPをディスって悦に浸るのは知る限りRubiestとPythonistaと中学生だけです。それにこれはあくまでサーバーサイド初心者の感想なので、想像するにこれ系のFWは多かれ少なかれ似たような不満を抱えるものなのかなと思います。というわけで、おそらくこれから選択肢がある限りはRailsを使い続けると思います。
PHP最新版がようやく正式に発表されましたね。新機能等について調べてみたので流行に敏感な人はぜひ今のうちから勉強しておきましょう。
「?>」を積極的に使うことにより、余計なホワイトスペースを混入させてしまう問題がありました。
これは厄介で非常に根が深い問題でしたが、ようやく根本解決として廃止されました。素晴らしいですね。
今後「?>」を使うとコンパイルエラーとなるので注意が必要です。
昨今抽象化抽象化と特に意味もわからず言葉だけ連呼する人間が増えてきました。しかし新PHP時代における抽象化はもはや人間が理解しなくてもできるようになります。
$class = abstract { $人間 = array('name' => 'yamada', 'age' => 20); $佐藤 = array('age' => 20); $動物->name = '花子'; $動物->type = '犬'; function move ($a) { $a->position++; } }; $class->move();
このような処理が、自動で抽象化され再利用できるようになります。もちろんクラス抽象化だけでなく、手続きやデータ構造であっても適切に自動で抽象化されます。
またcatch文を繋げる事で抽象化に失敗した場合を検出することが可能です。
php実行時オプションに強力な型チェックオプション(-compile)が追加されました。
$ php -compile example.php
そのスクリプトにおける全ての処理パターンを実行し、全ての型のチェックを自動で行います。その際、外部に影響を与えるような処理(ファイルへの保存等)は型チェックのみを行い無視されます。
この強力な機能のおかげでもはや静的言語の利点といわれていたコンパイル時の型チェックを軽く超えました。
動的言語でありながら、考えられる全ての型の引数、例外系を全ての関数の組み合わせで網羅的にチェックします（しかもチェック時間は長くても0.数秒という驚異的なチェック能力です！）
これが今回の目玉機能でしょう。
theworld {
// 止まった時間の中を動けるのは$dioだけ
$dio->foo();
$dio->bar();
};
$dioという特殊変数が用意されているのでその変数を使って処理をすることができます。
用途としては非常に重たい処理をさせるのがいいでしょう。実時間0秒で実行することが可能となります。
ただし9秒までしか止められないので注意が必要です。ですが回避策として以下のようにすれば追加で5秒止めることも可能です。
theworld {
$dio->foo();
$dio->bar();
}
starplatinum {
// 9秒過ぎた時点でこちらへ
$jotaro->foo();
};
名前空間(namespace)が非推奨になりました。これを使用するとE_NAMESPACE_YEN_ARIEHENという警告が発生します。
非推奨となった理由ですが明確にはされていません。大人の事情ってやつでしょう。
ただ噂レベルでは、やはりというか区切り文字の「\」がありえへんという声が多かったからではないか？と一部囁かれています。
mandomキーワードが非推奨になりました。mandomはきっかり6秒戻すという機能ですが、逆に言うと6秒きっかりしか戻せないので扱いづらいという問題がありました。
また以下のような処理を書いた場合に$flagがバグ等で常に真になるケースにおいて無限ループとなり、非常に危険だという問題もあります。
// 何かしらの処理・・・ if ( $flag ) { mandom; }
このようにPHP初心者がmandom使って無限ループをさせてしまう事案が後を絶たず、なかなか現実時間が進まないという問題が発生したため、廃止予定となります。
$mail = google_search_exec("メール送信するやつ",2); $mail("user@example.com");
第一引数は検索ワード。PHPというワードは自動で含まれるので指定する必要はありません。
第二引数は検索結果一覧の指定位置。2だと上から二つ目の検索結果のURLのコード小片を使うという意味になります。
また第三引数にはコールバック関数を指定することによりコード小片にフィルターをかけることも可能です。
このような処理がたった2行で書けるというのがPHPの利点ですね。
日本語名の関数が新たに追加されました。これは非常に便利な関数です。
$code = 写経(" $a = 1 + 2; print $a; ");
引数に与えられたコード片を写経します。戻り値に写経結果が返ってくるのでそれを利用するだけです。簡単ですね。
この関数が呼ばれると一瞬処理が止まったように見えますが、実際には自動補完で動作が完了している状態になります。
for($i=0;$i<10000;$i++) {
if ( $i % 2 == 0 ) {
chronostasis();
}
// 何かしらの処理・・・
}
素晴らしい機能ですね。今後はこれ無しじゃプログラムできなさそうです。
用途ですが、言わずもがな今流行の真契約プログラミング用ですね。アサートの代わりに使うとよいです。
function foo ($a) {
pc_explosion(!is_null($a),'$aはNULLはダメー！');
// 何かしらの処理・・・
}
テストコードを実行する場合はPCの周囲に人が居ないか気をつけてから実行させましょう。
個人的に良いなと思ったのはpc_explosion関数ですかね。約束事を守らないプログラマーなんぞ爆死しちゃえばいいんです。僕を含めて（お
JavaScript って生き物っぽいって思ったのがきっかけだった。
なんか菌？に遺伝子いれてたんぱく質を生産させるやつ？ Function は菌の細胞膜で prototype は遺伝子で、だから prototype に全然関係ない違う生物の遺伝子を生きてる菌に入れちゃったり。そうすると全然ちがうたんぱく質が生産されたり。prototype にべべーっとコピーして追加するのなんてまさしくそれっぽい。
だってプロトタイプベースって、生き物しかいない世界じゃない？基本的に。インスタンスってのは生き物じゃない設計図があってそれにしたがって出来た生き物がインスタンスってイメージあんだけど。プロトタイプベースの世界にはそんな設計図も生き物じゃないものもないよね？なのにわざわざインスタンスっていうのに何か違和感？ご都合主義的なもの感じる。クラスは型で、インスタンスを実体だとかなんとかって氾濫してるせいかな。多分この辺の用語が JavaScript をわかりにくくさせてる気がする。
僕の感覚では、オブジェクトってのは生き物で、クラスベースってのは神が設計図に基づいて生き物を生産してる世界で、インスタンスベースってのは生き物が生き物を複製してる世界のイメージだ。多分、原始の生物はインスタンスベースみたいな世界で、海の中にうようよしてたんだろうな、とか。
オブジェクトじゃないものは、生き物じゃない死んでるたんぱく質や RNA の破片みたいな。それだけじゃなにもできないみたいな。それだけじゃ命がないから、生き物の殻に詰めるってのが JavaScript のコンストラクタのイメージ。
Perl の bless したらこれはもう命入ったよ生き物だからねっあとは勝手にしてねってのも、Python の名前空間さえあればなんとかなるよねってのも、JavaScript のハッシュさえあれば世界作れるよねってのも、みんなどこか似ている。ちゃんと OOP を理解できてるかは別としてもこの三つはわりとすぐやりたいことができた。昔 Java の本を買ってきて挫折したのにくらべたら、なぜかずっとわかりやすかった。（bless という命名はすごく洒落てる）
全然関係ないけど、Django の日本語リファレンスは何か萌える。ラクダ本の日本語訳はむかつくのに。
プログラミングを始めたばっかりの時は、なんだか難しい用語の意味を理解しないと OOP がわからないと思ってた。それは僕らの住んでる世界とは全然関係のないプログラミングの技術ってやつだと思ってた。
でも多分違う。
世界が動く仕組みさえあれば、あとは作り手に世界の成り立ちを抽象化する表現力さえあれば、世界は勝手に表現されていくし、動き出してく。たまたま僕らの世界はオブジェクトなもので溢れていて、プログラミング言語が進化すれば世界に似るのも当然だろう。いや逆か。プログラミング言語が世界に似てきたから、オブジェクトなんていう世界に似た概念が出てきたってことか。なんだか難しい用語ってのは、その表現の一部分の技術に名前をつけてるだけなんだな、と。例えば何とか歌唱法や何々画法とか何とかレトリックとかパースの取り方みたいなのと同じ。それは表現を理解する手助けにはなるけど、その意味を知る事がイコール表現力をあげることにはならないんだよね。これに気づくのに遠回りしすぎたなあ。
（知識を得るだけで、100% 還元される人もいるかもしれないけど、そんなのは一部の天才だけだと思う。殆どの凡人はそうはいかない。とはいえ、元の錬度が低ければ、コツをいくつか教わるだけでいきなりうまくいくこともある。ただ、それをまるまんま実力だと思うのは、どんな分野でも危険だ。恋愛テクニックやらを必死に読んでる連中が男女間の深い人間関係を上手くやれてるとはちょっと想像できない！）
プログラミングで表現力を上げるにはどうすればいいんだろう。きっと他と同じだろうな。いい表現を沢山味わって、世界をよく観察して、どう成り立ってるかどう動いてるか、私達はそれをどう認知しているのか、考えることかもしれない。漫画家を志す人が美術解剖学を学んだり、優れた画家が絵筆で世界を生々しく描写するように、優れたプログラマは世界のなりたちをプログラムに写し取ったり、世界の仕組みを作る事が出来るのだと思う。
最後に、宇野は「〈いま・ここ〉だけが無限に広がるこのリトル・ピープルの時代の新しい世界においては、私たちは〈いま・ここ〉に「潜る」こと、徹底して内在的であることが逆説的に超越に接近してしまう」と語るけど、このレトリックって、大澤真幸が麻原彰晃に対して指摘した、
徹底した俗物性、過剰なまでの〈内在性〉が、逆に、麻原の〈超越性〉の根拠になっているのではないか。（大澤真幸『虚構時代の果て』）
とまったく同じなのだけど、これは本人的には大丈夫なのかしら。
ttp://blog.livedoor.jp/toshihirock_n_roll/archives/51653048.html
たとえば『完全自殺マニュアル』の鶴見済氏やオウム真理教の麻原彰晃は、「革命」を失った今、世界を変えるのではなく自分を変えようとしたわけですよね。ドラッグや「修行」によって。麻原は鶴見さんほど徹底できなかったヘタレだから革命のでき損ないに走っちゃったわけです。しかし、彼らのやったことはまさに「内在」的なアプローチだったと思う。だって、世界変革を「諦めて」自分をチューニングするんだから。
でも、ぼくがこの本で書いた「拡張現実の時代」においては、先ほどのゲームの例が代表するようにネットワーク的なものに支援されて超越―内在といった図式自体が崩壊していて、徹底的に内在することが超越に近づくというモチーフが頻出する。「ここではない、どこか」ではなく「いま、ここ」に留まったままゲームのルールを書き換えるための想像力の行使に焦点を合わせているわけ。それはそのまま「虚構の時代」（鶴見・麻原）と「拡張現実の時代」の違いでもある。ここもポイントで、「外部」を断念するというとすぐに鶴見・麻原的なものを年長世代自体は想像しちゃうけれど、それは90年代で時間が止まっている思考ですね。21世紀的な現実は「徹底して内在することによる超越」が、自意識のチューニングではなく現実のコミュニケーションとして創作物の生成や社会変革の可能性の方向に向かっている。これがまさに「仮想現実から拡張現実へ」ということ。
いやいやいや。。。ちょっとウノさん、何言ってるんですか・・・・。「内在」っていうこれまで批評用語としては、「超越-内在」っていう二項対立の一項として使われてきた用語を、かなり強引に自分タームの「内在」（これってむしろ「組織のインサイダー＝内在者」っていう意味に近いと思うんだけど）に引きつけて使ってて、不要に名前空間のコンフリクトを起こしてる気がする。まさに、
人文系の評論はすぐに一般名詞を専門用語化する傾向がある。しかも、その本だけでしか通用しない専門用語をすぐにつくっちゃうのだ。”壁_temp”とか、”想像力_temp”とかいう名前にしてくれればわかりやすいのだが、我慢して慣れてみよう。
っていう奴。今まで現代思想界にはCritique.naizaiっていう広く使われてる変数なり関数なりがあったのに、そこにまた紛らわしいUno.naizaiっていう変数なり関数なりを持ってきてて、そこでCritique.naizaiをUno.naizaiと間違えてコンパイルした人に、「お前はUnoパッケージをインポートしてないから俺の本が読めてない」って文句言うのはちょっと無理筋過ぎないか。
まあ、用語の問題を脇に置けば宇野常寛の言いたいことも分からなくはない。現代思想や社会理論がこれまで、超越（トップダウンの理想主義的な社会モデル）か、内在（個々人の内面＝インナースペースからの改革）か、という二項対立に拘泥したきたのに対して、組織の内在者＝インサイダーが、組織へのハッキング的なコミュニケーションによるアプローチをかけることによって、ゆるやかに社会を変えていきましょう、ってのが彼の言いたいことなんだろうなあ、と思う。だけどそこで、現代思想のこれまで数十年の歴史のある用語体系に土足で踏み込んで、「内在」なんていう一般名詞を無理やり自分タームで使うのは無理筋だし、これまでその用語体系を使ってきた人の名前空間を不必要に混乱させる振る舞いだと思う。せめて「内在者（インサイダー）的アプローチ」くらいの用語にしておいてくれれば分かりやすいのにねえ・・・
PHPユーザー会の中の人とたまたま話したんだけど、アプリケーションのPHP5.2系からPHP5.3系への移行が滞っているようだ。
「業務でPHP5.3使ってますよー。」って言ったらむしろ驚かれた。どういうこった？
いま移行せずに、PHP5.3ってどうなるのよ？その先にあるPHP6系ってどうなるのよ？不安しかでてこない。
140字制限からURLを除き、返信時にコメント元を表示して、コメント元からも返信があることが分かるようになれば、大半の問題は解決しそう。
ほかに問題があったらブクマか、@youkosekiにコメント下さい。
3/25：ふぁぼ死やアカウント融合、APIや運営まわりの問題を追記しました。ブクマ、Twitterでのご指摘ありがとうございました。問題があるからダメではなく、現状の問題を認識しつつ、どういう風にすればより便利になるか考えたいと思っています。以前にお仕事でTwitterについてのコラムを書いたので、お時間のある方はどうぞ。http://www.mri.co.jp/NEWS/column/thinking/2010/2015508_1805.html
百万回繰り返された例の件について書いてみるよ。あ、タイトルは必要ないよね？このタグだけ見ればわかるものｗ
総評：とにかく微妙というか、中途半端につかいにくい。いまだにPerlが生きていたり、Rubyにキャッチアップされてるのも納得の出来。これがＬＬ界を制覇したらPerlよりうっとうしい。
総評：Perlのライブラリが流用できたら最高。できなかったらNIH症候群にかかる。
しかし、OOPは各オブジェクトの構造や関連に注目した記述となるため、自然言語との親和性が手続き型よりも低い。オブジェクト指向は視覚的なアプローチなのに対し、手続き型言語は言葉による理解。一昔前の言葉で言えば、ランダムアクセスとシーケンシャルアクセス並の違いがある。
OOPが人間界、、、人間の世界観に沿っているのは同意するが、人間の言葉に合わせているのではない。
また、「xxx.doThat()」を羅列しただけのようなプログラムはOOPではない。それは手続き型だ。
ちなみに俺はOOPの利点は、メソッド・変数群の名前空間の整理(大規模プログラムを書いても名前が混乱しにくい)、データのカプセル化(複数の違うフォーマットのデータを同じもののように扱える。多態性)であると思っている。分析との親和性についてはオブジェクトもデータフローもペトリネットも大して差がない。
いや、なんていうか覚え立ての言葉をいろいろ使ってみたかっただけだ、すまん。
私的にはこんな感じ
// 自分で決められる場合は、関数のはじめは小文字にすることが多い // size_getみたいに繋げる時にはアンダーバー // getとかは後ろに書くことが多い int hoge(int n) { // int i; int retVal = 0; // 初期値付き変数と無しの変数とは分離 // 変数は使うところ付近で宣言 特にforは可能なら括弧内で // 短ければ一行で書き切る for (int i = 1; i <= n; ++i) retVal += i; // 長ければ二行 /* for (int i = 1; i <= n; ++i) retVal += i; */ // 複数行 /* for (int i = 0; i <= n; ++i) { // 略 } */ return retVal; }
関数とかクラスとか名前空間みたいなスコープっぽいものは改行して、
forやらifやらみたいなのは改行しないよ
otune(otuneはアスキーアートとして記述しています)は言った。
「もういいだろ！ メタだのエアだの、結局モヒカン族であることにかわりはないんだろう？」
「いいえ。それは違います。はてなグループモヒカン族の定義ではあなたの言うメタモヒカン族をエアモヒカン族とした場合、名前空間でバッティンｇ
「うるさい！ 憎きモヒカン族が！ おまえたちが！ 私の娘をweb社会から葬り去ったのだ！ Yoぉぉぉkoぉぉぉ！！」
私はその場に崩れ落ちた。それに気付かないでかotuneは一心に「マイコームで髪型をセット」「バギーのエンジン始動」「ハンドアクスを研ぐ」などのジェスチャーをしている。
私はこの男を絶対に許さない。