sudo port upgrade outdatedの途中で終了しちゃって中途半端な状態で終わってたからか、atlasがインストール失敗する状態になってた。
% sudo port clean -f --all atlas
こうしたら治った。
sudo port upgrade outdatedの途中で終了しちゃって中途半端な状態で終わってたからか、atlasがインストール失敗する状態になってた。
% sudo port clean -f --all atlas
こうしたら治った。
最近仕事でWordPressのテーマやプラグインのコードに触れています。
WordPressには「結果を標準出力に出力する」か「返り値(文字列)として返す」かというフラグを引数に持つ関数がとても多い。
下記のコードは同じ動きをする。(実際にthe_titleの上記フラグは第三引数ですが分かりやすくするために簡略化しています。)
// エントリのタイトルを出力する
<?php the_title(); ?>
komagata [p0t]
<?php echo the_title(false); ?>
komagata [p0t]
本体にこういう関数が多いため、プラグインでも暗黙的にその動作を求められる。
何で後者がデフォルトじゃないのか。そもそも、
// エントリのタイトルを出力する
<?= the_title() ?>
komagata [p0t]
こうじゃ駄目なのか?
これはショートタグがマナー違反とされているため、<?php echoと書くのが面倒でこうなっているんではないでしょうか。
そもそも何故ショートタグが色々なコーディング規約で非推奨になっているのかも理解出来ない。XML宣言と同じ事はそれ程問題なんだろうか。何かセキュリティーホールがあるのかな?
テーマの中で<?php echo とわざわざ書かなければいけないせいで、テンプレートがウリのPHPの良さが損なわれている気がしてならない。
WordPressではthe_xxx()という名前だからといって必ず上記の機能を持っているわけではない。そもそも返り値を返さない関数も多い。
リファレンスを見ると、最近のバージョンになるにつれてthe_xxx()は関数内で出力、get_the_xxx()は文字列として返り値を返すというルールが出来つつあるっぽいが統一されそうな気配は無い。
この手の瑕があちこちに見られます。大勢に使われることで成長してきたソフトウェアだから仕方のない事だと思います。しかし、もう大きく舵を切らないとマズいところに来ていると感じました。
特に安価なレンタルサーバーで動くことが大きな長所であるWordPressは無料からあるクラウド環境に対応出来ないと今後生きていけないと思う。
それにはデータベースの抽象化がほぼ必須だ。このまま生SQL CREATE文を抱えた大量のプラグインと一緒に沈没していく危険性が高い。
地味で当たり前で退屈な方法だけど今はじめないと手遅れになると思いました。
お客さんからクローラーにメアド取られたくないという要望があったので以前のエントリ内容をWordPressのプラグイン(ショートコード)にしてみました。
[caesar-cipher komagata@gmail.com]
こう書くと、
こういうJSが吐かれて、
メアドが表示される。
紀元前の人でも簡単に解読できますが、とりあえずクローラーにわからなきゃいいかなということで・・・。
更新:wordpress.orgのsubversionで管理するのが普通っぽいのでGithubの方はやめて本家に登録しておきました。
VMware は知っている – クラウドでは仮想化が不要になることを « Agile Cat — Azure & Hadoop — Talking Book
サーバーの仮想化が、クラウド・コンピューティングを作り出した。 多数の論理サーバー・インスタンスを、物理的に一台のサーバー上で実行する能力を持つことなく、現時点で私たちが認識するクラウド・コンピューティングの経済学は成り立たなかっただろう。こうした認識に基づき、大半の人々はサーバーの仮想化について、クラウドの基本を構成するものだと思い込んでいる。しかし、それは、クラウドベースのアプリケーション・プラットフォームが成熟するまで、私たちが必要とする松葉杖に過ぎない。つまり、サーバーとオペレーティング・システムで当たり前となっている、現時点の概念を参照することなく、アプリケーションの構築と展開が可能になれば、不要になっていく。
PaaSの場合、ユーザーはパフォーマンス増強の為に追加する単位が仮想のOSインスタンスなのか、物理サーバーなのか分からない。(気にする必要が無い)
そうなると、仮想化はオーバーヘッドの分、損なので仮想化技術の重要性が低下していくという予測。
スペイシーズで月1でお会いする機会のある@ebiharahideyukiさんが8月3日にベンチャー支援のイベントをやるそうです。
インターネットビジネス支援プロジェクト Startups2010
やりたいサービスの試作品を出してプレゼンすると、良さげな場合、出資してくれるそうです。
僕なりの解釈なので間違ってたらスイマセン。何かこういう汚い言葉に直さないと理解できないのは育ちが悪いからでしょうか・・・。
1、2はありがたいすな。特に2は営業とかよくわからんっつーエンジニアには助かる。でも逆に影響受け過ぎるという面もあるかと。
3はいらないかなー。GAEとかHerokuとか好きなの使いたいからね。4,5はスゲー面倒なのでやってもらえると助かるけど必須ってほどじゃない。
これの特徴はアイデアだけじゃ駄目で、試作品(モック)を提出する必要があるとこ。
@ebiharahideyukiさんが言っててオモロかったのが、去年もこういうのを(試作品提出無しで)やったそうなんですが、作れる人がいないと何事も進むスピードが遅くなっちゃうんだそうです。
ブツが無いと結局アイデアのプレゼン大会になっちゃってどれがいいとか良く解らんという状態は確かに想像できる・・・。
起業志向のエンジニアには凄くいいんじゃないでしょうか。っつーか「日本はITベンチャーを支援する体制が無い」とか文句言ってる暇があったらこういう試みに協力するなり、「こうやった方がいいんじゃないか!」と議論するなりするべきかもとおもいました。
あと、8月3日のキックオフイベントにはid:dandasoが出るのでどんな話をしてくれるのか気になってメッセで聞いてみました。
「おいィ?」
是非、空気読まずにHadoopの話とか、DBのレコードを回すイテレータの引数が増えすぎて意味不明になってる話とか、Javaをvimで書いててnamespaceのディレクトリの深さに涙目になってる話とか、急行するためにデータセンターの近くに引っ越した話とかをして欲しいです!
/Library/LaunchDaemons以下とかにあるplistを手で編集するのって、
「嫌だな〜 怖いなあ〜 怖いなあ〜 怖いなあ〜」
って思ってたんですが、Lingonは開発止まってるらしいし、launchdに限らず、そもそもplistの標準エディタとか無いのかなと思ってTwitterで呟いたら@kyannyさんに教えて貰いました。
Property List Editorっていうのが最初からユーティリティの中に入ってるんですね・・・。(Spotlightで"pro"とか入れたら出てくる)
(launchdのpostfixのplist)
実際には結局viで編集しちゃってるんですが標準エディタがあることで何か安心しました。
JavascriptのInflectionライブラリ。
<html>
<head>
<title>Inflection</title>
<script src="../js/inflection.js" type="text/javascript"></script>
</head>
<body>
<script type="text/javascript">
document.write('<p>'+'project'.pluralize()+'<p>')
document.write('<p>'+'project'.pluralize().singularize()+'<p>')
</script>
</body>
</html>
便利。
デモ:Inflection
jquery.unk.jsプラグイン。
(function($){
$.fn.unk = function() {
$(this).text('unk')
return $(this) // 一応Chain出来るようにしとく
}
})(jQuery)
<html>
<head>
<title>jQuery Plugin Sample</title>
<script src="http://ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.min.js" type="text/javascript"></script>
<script src="jquery.unk.js" type="text/javascript"></script>
<script type="text/javascript">
$(function(){
$('body').unk()
})
</script>
</head>
<body>
</body>
</html>
結構簡単に書けちゃうんだね。仕方ないね・・・。
「今度のプロジェクトは"あの機能"の実装がキモだなー。難しそう・・・」
「このバグがどうしても治らん・・・」
というのをとりあえずHelp me, hackers!に書いといたらマジでそっこう(7時間ぐらい)で解決した・・・。
なんぞこれ。なんでこんなにありがたいことが起こるのか、考えてみた。
Aはプログラマー。今回のプロジェクトはJavascriptでのリッチなUI実装がキモだ。しかしAはクライアントサイドプログラムには明るくない。
A:「ここでこのイベントが取れれば・・・。あれ?ここでのthisは一体何を指しているんだ?」
BはAの隣の席のプログラマー。Aのプロジェクトは佳境を迎えているがBは別のプロジェクトが終わったばかりで暇だ。
B:(ちょうど未読RSSが無くなったところだしAをひやかすか)
B:「Aさんどうすか、JS。」
A:「キモイ。Java書きたいよ。thisがthisじゃないんだよ。どういうこと、これ?」
B:「ッハハ。大変っすねー。ちょwww、AさんFirefoxのAddon入れ過ぎじゃないすかwww」
CはAの向かいの席のプログラマー。Javaのプロジェクトに参加中。AやBとはあまり親しくは無い。
C:(向かいの席がうるさくて集中できん。どうせベタベタなJava風クラスを書いてるんだろ。JQueryのClickイベントハンドラ内だったらthisはそのボタンだろ。ボケが!)
Dはプログラマー。新人だがJavascriptは学生時代から書き慣れている。
D:(勉強のためにAさんのプロジェクトをチェックアウトして見てみたけどこれはひどいwww。冗長でソースの見通しが悪すぎる。136行目、これ動かないだろう、常識的に考えて・・・)
D:(まあ僕には関係無いから黙っとこう。下手なこと言ってあのデスマプロジェクトに入れられたらたまらないからな。)
通常、隣の席のプログラマーは数人しかいない。しかし、ネットにタスクがアップされていると沢山の人が冷やかしにくる。
タスクをアップした本人は自分の責任であるコードがバグってて本当に困っているんだけど、見に来る人にとっては、直らなくてもまったく困らない。ちょっと覗いてみて、もしなおっちゃったらラッキーぐらい。
なおらなくても、「ハハー、たいへんだねぇ〜」程度。
友人や同僚で「それわかるかもしれないので僕もちょっと見てみますね」といって問題を解決してくれる人がいるでしょう?そういう隣の席のひやかし同僚が超いっぱいいる状態になってるから1日もたたずに問題が解決されるんじゃないだろうか。