  |
はてなキーワード: テンプレートとは
こどもに、ほんきで爪をたてられたことはありますか？
こどもに、ほんきで噛まれたことはありますか？
こどもから、病気をうつされたことはありますか？
こどもに、毎晩延々と泣かれたことはありますか？
こどもがあなたの枕元に吐いたゲロを、かたづけたことはありますか？
こどもが癇癪をおこして、床に落ちているバラバラになった買い与えたばかりのオモチャをかたづけたことはありますか？
こどもの尿を、かたづけたことはありますか？
こどもの糞（固形）を、かたづけたことはありますか？
こどもの糞（下痢）を、かたづけたことはありますか？
こどものからまった毛を、ハサミとブラシでほぐしたことはありますか？
こどもが花びんの花を触ろうとして失敗し、お気に入りのすべてのものを水びたしにしたことはありますか？
こどもが鉢うえの観葉植物を触ろうとして、部屋をどろまみれにしたことはありますか？
こどもの乳臭いにおいが家と服とにんげんのすべてに染みつき、こどもぎらいのひとから眉をひそめられたことはありますか？
こどもが布団で、ゲロまみれになって大泣きしているのを風呂場に連れて行ったことはありますか？
こどもずきのひとへの、回答をもとめないしつもん。
こどもずきのひとへ。こどもはこういういきものです。こどもぎらいのひとへ。こどもはこういういきものです。
昔はこどもだったの全てのひとたちに祝福を。
ガンダムはVが一番ブラッディなんじゃないかしら。
００は全体に小奇麗な演出に留まっていて、あんまりえげつない描写は見ない気がする（自分にはルイスの描写もテンプレート的すぎると感じられる）。時代の要請もあるんだろうけど、見ていてその辺は物足りなく感じてしまうよ。かなり直接的に現実世界を想起させる世界観である割に、アニメ的演出・お約束に頼る部分が大きいし。まあ、そういう不満は適当に流しながら、楽しんで見てるけどね。Mrブシドーって誰なんだろう？
元増田の言葉で思い出したけれども、子供の頃は残酷なシーンを残酷なものとして受け止められなかったなあ。
ポケットの中の戦争とか、見返してみると相当ヤバく見えるのだけど、当時は何か気持ち悪さとかそういうのを全く感じなかった。弾痕でズタボロになったケンプファーの残骸とパイロットシートを見て戦慄する、なんてことはちょっと出来なかったよ。逆襲のシャアでも、MSが人間を握り潰してたりするのを軽く流して見てたし。というか人間ドラマの部分飛ばして戦闘シーンだけ見てた（これ、すげえ怒られそうだな・・・）。自分が子供の頃ガンダムを見ていたときはそんな感じだったものだから、そうした描写が情操教育に影響がある印象はしないな・・・中には、それで人生観が変わる子もいるのだろうけど。
物語から衝撃を受けるには、一定の知識・想像力と、お話の中の出来事を「他人事」「作り物」扱いしない態度が必要なのだろうね。
いまさらだがFizzBuzz。
1から100まで、3の倍数5の倍数云々って、全部定数の計算じゃね？
というところに気付き、自称メタプログラマー（略してメタグラマー）俺の血が騒いだ。
定数計算なら、それは実行時ではなくコンパイル時に行なわれるべきだ……。
#include <iostream> const int FIZZ_NUM = 3; const int BUZZ_NUM = 5; const int BEGIN_NUM = 1; const int END_NUM = 101; template<int N> struct Fizz { enum {PRINT = 0, NEXT = N + 1}; static void print() {} }; template<int N> struct Buzz { enum {PRINT = 0, NEXT = N + 1}; static void print() {} }; template<int N, bool ForB> struct Number {static void print() {std::cout << N;}}; template<> struct Fizz<FIZZ_NUM> { enum {PRINT = 1, NEXT = 1}; static void print() {std::cout << "Fizz";} }; template<> struct Buzz<BUZZ_NUM> { enum {PRINT = 1, NEXT = 1}; static void print() {std::cout << "Buzz";} }; template<int N> struct Number<N, true> {static void print() {}}; template<int N, int F, int B> struct FizzBuzz { static void print() { typedef ::Fizz<F> Fizz; typedef ::Buzz<B> Buzz; Fizz::print(); Buzz::print(); Number<N, Fizz::PRINT || Buzz::PRINT>::print(); std::cout << std::endl; FizzBuzz<N + 1, Fizz::NEXT, Buzz::NEXT>::print(); } }; template<int F, int B> struct FizzBuzz<END_NUM, F, B> {static void print() {}}; int main(int argc, char **argv) { FizzBuzz<BEGIN_NUM, 1, 1>::print(); return 0; }
ifなし%なしループ系なし、しかも実行時オーバーヘッドなし！（多分）
ああ、久しぶりにC++を触ったけど、やっぱC++のテンプレートってダメダメだな。20世紀の遺物といわざるを得ない。
君がもし21世紀のモテ系イケメンメタグラマーなら、21世紀のプログラミング言語、D言語を使うべきだ！
驚くべきことに、D言語はコンパイル時に関数が実行でき、その結果をソースコードとして取り込める！
ただし実行できるのは簡単な関数だけだけど……。
import std.stdio; // これでFizzBuzzを全部出力するコードを作るぜ！ string makeFizzBuzzCode() { string code; for(int i = 1; i <= 100; ++i) { // 効率？ コンパイル時にそんな配慮は要らん！ if(i % 3 == 0 && i % 5 == 0) { code ~= "writefln(\"FizzBuzz\");\n"; } else if(i % 3 == 0) { code ~= "writefln(\"Fizz\");\n"; } else if(i % 5 == 0) { code ~= "writefln(\"Buzz\");\n"; } else { code ~= "writefln(" ~ static_itoa(i) ~ ");\n"; } } return code; } int main(string[] args) { // おまけで生成されたコードも見せるよ。 pragma(msg, makeFizzBuzzCode()); // 生成したコードを埋め込む。コピペみたいな感覚。 mixin(makeFizzBuzzCode); return 0; } // 以下ユーティリティ。このぐらい標準で欲しいな……。 /// 整数→文字列変換（コンパイル時） string static_itoa(int n) { if(n == 0) { return "0"; } // 10で割りながら余りを文字にして追加。桁が逆転した文字列になる。 string s; for(; n; n /= 10) { s ~= ("0123456789")[n % 10]; } // 桁位置を正常にする。相変わらず効率無視。 return static_reverse(s); } /// 配列リバース（コンパイル時） /// 実行時ならarray.reverseが使えるんだけどね……。 T[] static_reverse(T)(T[] s) { T[] result; foreach_reverse(c; s) { result ~= c; } return result; } // 心配なので静的ユニットテスト（笑） unittest { static assert(static_itoa(0) == "0"); static assert(static_itoa(10) == "10"); static assert(static_itoa(999) == "999"); static assert(static_itoa(9999) == "9999"); static assert(static_itoa(12345) == "12345"); static assert(static_itoa(314159265) == "314159265"); }
コンパイル結果
$ dmd -unittest fizz_buzz.d writefln(1); writefln(2); writefln("Fizz"); writefln(4); writefln("Buzz"); writefln("Fizz"); writefln(7); writefln(8); writefln("Fizz"); writefln("Buzz"); writefln(11); writefln("Fizz"); writefln(13); writefln(14); writefln("FizzBu(ry
出力結果は略。
さすがD言語！C++やJavaやC#にできない事を平然とやってのけるッ
そこにシビれる！あこがれるゥ！
というか、
writefln(1);
writefln(2);
writefln("Fizz");
writefln(4);
もうwritefln（出力関数）要らなくね？
修正。
// これでFizzBuzzを全部出力するぜ！ string makeFizzBuzzCode() { string code; for(int i = 1; i <= 100; ++i) { // 効率？ コンパイル時にそんな配慮は要らん！ if(i % 3 == 0 && i % 5 == 0) { code ~= "FizzBuzz\n"; } else if(i % 3 == 0) { code ~= "Fizz\n"; } else if(i % 5 == 0) { code ~= "Buzz\n"; } else { code ~= static_itoa(i) ~ "\n"; } } return code; } int main(string[] args) { // もうコンパイル時のメッセージしか出さない。（笑） pragma(msg, makeFizzBuzzCode()); return 0; }
コンパイル結果。
$ dmd -unittest fizz_buzz.d 1 2 Fizz 4 Buzz Fizz 7 8 Fizz Buzz 11 Fizz 13 14 FizzBu(ry
実行するまでもなく結果が出力された。つまり実行時間ゼロ、ということは……
世 界 最 速
みんな使おうD言語！
http://www.kmonos.net/alang/d/1.0/index.html(1.0。こっちの方が安定してる？)
http://www.kmonos.net/alang/d/2.0/index.html(もっと凄い2.0)
服装ってのは身にまとう人間の心の持ち方が発露したものであり、
コミュニケーションツールであるという考え方がわかりやすい。
非モテに推奨されているような、無難な服装をテンプレート化した手法は、
マイナス評価を打ち消してプラマイゼロに持っていくような、没個性アプローチでしかなく、
「いいからちょっと黙ってて」に近い圧迫感がある。
モテであれ非モテであれ、他者の承認欲求は自分の人間性に求めるもので、
身につけている服装のみを承認されることに興味あるのだろうか？
モテ達は理由があって、意味がわかって服を身につけているから、
服を褒められても自分の人間性を褒められたようにリンクできるから素直にうれしい。
モテ達に教わった服を、意味がわからないで身につけている非モテは、
服を褒められても褒められたのはモテの人間性だからうれしくない。
つきつめるとそういうところだと思うんだが。
元増田です。
ちょっとそんな目で見てる板を眺めてみました。
前にも書いたとおり、板は複数です。
…
流石にこれみんな小中学生ってないわ。
小中学生に人気あるキャラから、マニア向けキャラまであるけど、
みんなチラ裏カエレだよ？
キャラ晒しの数は多くないです。どこもせいぜい月に１回、２回だなー。
盛り上がる->カエレしてる方が断然多い。
最初から見てる板とかもあるけど、別に荒れた事はないしな。
（２，３レスがあるとカエレしてるから荒れる隙もあったもんじゃない）
まあ、自分の好みなんて偏ってるから、人気作品だろうが、マニアキャラだろうが、
同じような感じになっちゃうのはあるかと思う。
で
ちょっと考えたんだけど、2chって自分の言葉で語らないじゃないか。
自分語り→チラ裏→カエレってのは、もうテンプレート化された反応が用意されてるけど、
下手絵に対しての反応ってないのかもしれない。
「カエレ」ってのは「ぬるぽ」→「ガッ」なのかも。
脱オタにファッション指南したい人、通称「ネットピーコ」にもいろいろいるようで。聞いてるこっちにしてみれば、おいおいどっちだよ、と言いたくなる事が本当に多い。
・ポーター
ポーターをカッコよく持てるのは相当な大人だけ
ポーターをカッコよく持てるのは相当な大人（何かデザイン関係の仕事をしてる感を全身で出せるなど）だけだということに気付くべき。
・チノパン
女子目線でユニクロのチノパンがオススメ、すごくオシャレじゃないけどだいたいよいとおもいます
ユニクロでつくる女子目線コーディネイト
・パンツ
この中からどれか
チノパンも持ってると便利！
諸刃の剣なので控え目な方がよいかと
フォトプリントTシャツは小細工せずにそこそこお洒落に見えるアイテム
「コンバースが合う」って結構難しいよ
コンバースは定番
■定番アイテムは？
・リュック
「なんとなく暗男」だと判定する要素
「リュック」・・・これがマズい。
ちょっと増田関係で調べただけでこれだけあるのだが・・ネットピーコは自分のファッション指南によって悦に入ってるかもしれないが、聞いてる方からすると「どっちにしろ脱オタ出来ないじゃないか、これ」と無気力感を倍増させられる。矛盾する２つの指南が２つともテンプレートだったりする。センスあるヤツは何着てもそれっぽく見えるし、オタなヤツは何着てもオタに見える、と言うオタの主張に反論してるつもりなのかもしれないが、皮肉にもそれが逆にオタの主張を証明してしまっている。ネットピーコはファッションセンスという言葉がお好きなようだが、ネットピーコはネットピーコで「あんたたちオタなんかより遥かにファッションセンスのある、ワタシ」という自己愛に酔ってるんじゃないか？と嫌味の一つも言いたくなってくる。
三度元増田です。
詳しい人、ありがとう。
最近の子供は財力も情報収集力も桁違いだと思うから、その可能性はあるかもしれない。
元増田にしてみれば、たしかに2ch語って、テンプレート化しすぎてて個性とか年齢とか、全然分からない。
殺伐としてるってのは、ほんの少し自分語り（勿論キャラについてだよ）になった途端、チラ裏とかカエレ！って言い出すのを読んでて思ったんだけど、あれ、和気藹々なのかなぁ。
友達に向かって「ウザイ」とか「死ね」っていうのが普通で、実はお互い和気藹々って捉えれば納得…するしかないんだろうと解釈した。
言った者勝ちで言われた相手がどう思うかなんて、2chは「語らせない」風潮があるからなぁ。
自分の絵をアップするのと、自分語りと、どんだけ差があるんだ？って疑問は払拭できないけど。
元増田は、カラオケで下手な相手の歌を褒めるなんて事ぁしない。そんな偽善者じゃない。
勿論貶しもしないぞ。
下手な奴に下手って言う必要はないが、大褒めして持ち上げる必要もないんじゃないか？
それに、カラオケはみんな好きに歌うもんだから、演歌だろうが、ラップだろうが、好きに歌ってくれ、って思う。
ポップスは誰が歌っても大褒めして、民謡なんて聞きたくねぇよカエレ！なんてないよな？
あと、ふたばってのは知らない。あれ、ヲタ板もあるのか。猫は勧められたけど。
元増田はうまい絵を見たい訳じゃないから、自分語りも、下手な絵も、みんな受け入れる和気藹々なのがそっちなら、気分がいいだろうな、とは思う。
今度探してみます。
「オンラインで流せるテープ」 を提供していた muxtape が閉鎖して一月。昨日出た、運営者からのメッセージを勢いで翻訳する。
http://muxtape.tumblr.com/post/51762430 ←反応
僕は音楽を愛している。
音楽を愛している人にとって、そして音楽そのものにとって、音楽を共有するという欲望は、本質的でかかせないものだと信じている。
愛すべき音楽に出会ったとき、僕たちは友達をターンテーブルの前に集め、CDを貸し、カーステレオで鳴らし、ミックステープを作る。
僕たちは、音楽から感じるものを知っているから。他の誰かにも、それを感じてほしいから。
Muxtapeの物語が始まったのは、僕がオレゴンでやっていた、週一の大学ラジオ番組だ。
その番組で流した曲の記録のかたわら、そのプレイリストをウェブに上げていた。ひとつのブロックが、その週の番組を記録したカセットに対応するというものだ。
当時、ミックステープは斜陽の時代に入っていた。でも、あのプレイリストのページは、ミックステープと同じ役割を、そして多くの点でよりよい役割を果たすはずだ。僕は番組を終えてからも、そのことをずっと考え続けた。
ミックステープのように、プレイリストはある意図を持って集められたものであって、その価値は単なる足し算にとどまらない。
ミックステープとは違って、プレイリストには物理的に届けるための制約がない。でも同時に、そこには実際の楽曲がない。
誰かがそのページを見にきてくれても、知っている曲があれば共感してくれるだろうが、 本来リスナーである人たちにミックスを実際に編集する手間を押し付けるのは、もともとの目的をダメにしてしまう。
プレイリストのことをまた考えはじめ、ついにそれに命を吹き込んだのは、その頃のことだ。
僕の音楽を（ミックステープ的な意味で）共有するという欲望はなくなってはいなかった。
だけど、その行き場はなくなりつつあった。
大手のブログサービスは音楽ファイルを短期的に置けるようにしていたけれど、
そういう場は僕が求めていたものではない。
カセットテープを手に握ったときにうまれる、突き動かされるような感覚。
それを手にしただけで、プレイヤーを探してそいつの使命を遂げさせたくなる。
Muxtapeの設計の目標は、そういう実感ををデジタル世界に翻訳してやり、音楽が生命の火花を散らして、持つ人を聞かずにはいられなくするということだった。
最初のバージョンは僕のtumblrに載せた一枚のガジェットだったけれど、後の姿と本質的に変わりはない。
フィードバックはすごいものだった。
「俺の分も作ってくれないか」という質問が次々と来た。
でも考えが進むにつれ、それはひどくもったいないことだと気づいた。
ソースで配布すると、到達できる範囲はせいぜい自前のサーバーを持ったニッチなクラスタだけになってしまう。
音楽を発見するための、もっと大きな機会をすべて閉じてしまう。
ミックステープの抜け殻に見えていたそれは、すぐにミックステープの進化形に見えだしてきた。
作ってやらなければならない。
三週間の夜をけずった結果、僕はMuxtapeを公開した。
成功はすぐに目に見えて現れた。
24時間で8685人の登録があり、
1ヶ月で97748人の登録と1200万ユニークアクセスがあり、
さらに順調に伸びつづけた。
行き過ぎた予想。技術オタクは賛美するか、すぐに失敗すると断じるかに分かれた。
誰もがどきどきしていた。
僕はぞくぞくしていた。
Muxtapeは「レーダーの視界の下を飛んでいる」からなんとか生き残っているだけだ、という誤解は多かった。
いわく、メジャーレーベルに見つかれば、閉鎖させられるだろう、と。
実際には、レーベルとRIAAは普通の人と同じようにウェブを見ている。
僕も一週間かそこらで、連絡を受けた。
RIAAからの通告が、メールと書留郵便とFedEx夜間便（紙とCD）の三点セットで届いた。
彼らは、権利侵害に当たるらしい6つのmuxtapeを止めるように求めてきたから、僕はそうした。
同じ頃、あるメジャーの著作権問題(anti-piracy)担当者からの連絡を受けた。
電話をとって最初に聞いた一言は、「教えていただきたいんですが、召喚状と訴状は、どこに送ればいいんですかね？」
対話はそこから始まった。
召喚状は送られてこなくて、それは雰囲気を新規ビジネス立ち上げの会議にふさわしいものにしようとする彼の脅し戦術だった。
本当の狙いはビジネスだった。
同じ頃、別のビッグフォーの企画担当者からもコンタクトを受けた。
次の一月、僕は聴き続けた。
頭のいい法律家、この手の問題について傾聴すべき意見を持つ人々と話し、
Muxtapeの合法性について合意を得ようとした。
得られそうな合意は、合意がないということだけだった。
「Muxtapeは100%合法で何の心配もない」から「Muxtapeは違法コピーの宝庫。十億ドルの訴訟とライカー島(Riker's Island)での服役の覚悟はあるのか？」までのあいだで、二十以上のすこしずつ違う意見をもらった。
結局Muxtapeの合法性は法律的に曖昧(moot)だった。
正当性があろうとなかろうと、訴訟で戦う費用はない僕の上に、メジャーレーベルは斧を振りかざしていた。
僕はいつも、アーティストかレーベルが連絡してきて問題を訴えたなら、削除をすると、自分の中で決めていた。
でも、誰からもそういう疑義はなかった。
ひとつも、なかった。
逆に、僕が聞いた範囲では、どのアーティストもこのサイトのファンで、その可能性にわくわくすると言っていた。
そこの親会社は怒っているに違いない大きなレーベルのマーケティング担当から電話を貰い、最新の情報をホームページに反映させるにはどうすればいいかと訊かれたことも何度かあった。
小さめのレーベルからは、彼らのコンテンツを別のクリエイティブな仕方でアピールできないかと言われた。
明らかに、Muxtapeはリスナーにもアーティストにも、同じように価値あるものだった。
五月、メジャーレーベルのひとつ、ユニバーサル・ミュージックとの最初の会議をした。
僕は、最悪の扱いを覚悟して、一人でそこに行った。
この十年、インディーの界隈に片足を突っ込み、そこで大きなレーベルが彼らの利益になるものも知らず、頑固にラッダイトしているのをみたからだ。
ここで言っておきたいのだけど、レーベルは自分自身のビジネスを、ふつうの人が疑っているレベルよりはずっとよく知っている。
ただし、未来へのアプローチに関しては、個々のレーベルによって驚くべき違いがある。
ユニバーサルで僕が会った紳士たちはすごく柔軟で機転が効いていた。
僕は、彼らにMuxtapeが与える利点を売り込む必要はなかった。
彼らはMuxtapeの素晴らしさを知っていて、ただ、支払いを欲しがっているだけだった。
その点については同情する。
僕は、共同で提案を行うにはまだいくらか時間が必要だと伝え、決定を先延ばしした。
彼らは大きく違ったタイプだった。
僕は会議室に入り、8、9人と握手をしてテーブルの前に着くと、目の前に "Muxtape" と題された電話帳並のファイルがあった。
彼らは半円状になって左右の脳のように僕の回りに陣取った。片方は法律、もう片方はビジネス企画。
会議の相手は交互に切り替わった。
「貴方は意図的に権利侵害をしている、サービスを止めるまでに数時間の猶予は与える」という法律サイドのハードな尋問と
「仮にサービスを止めさせられなかったら、どのような協力がありえると思うか？」というおずおずとしたビジネスサイドとの議論。
僕は提案を作るのに二週間を求めたが、二日と告げられた。
決断をしなければならなかった。
僕がみるに、選択肢は三つ。
第一は、全てをやめること。これはずっと考えていなかったことだ。
第二は、メジャーレーベルのコンテンツを全て禁止すること。これなら、直近の危機を回避することができそうだが、二つ大きな問題があった。
ひとつは明らかなことだけど、ユーザーがミックスに使いたいと思う大半の音楽を禁止することになってしまう、ということ。
もうひとつはメジャーレーベル以外に関して、楽曲の所有権と利用をどう扱うべきかという重い問題についてなにもやらないに等しい、ということ。
中規模のレーベルと独立アーティストにも、彼らのコンテンツがどのように使われているかについて、それほど圧力は使えないにしろ、大企業と同様の基本的な権利がある。
これは、ユニバーサルの人に会ってからずっと挑戦していたことだ。
他のサービスでライセンスを受けているものは、いろいろな理由でうまくいっていることを知っていた。
同時に、Muxtapeの場合は違うということ、少なくとも模索する価値はあることを知っていた。
レーベルがそこに価値を見出しているかどうかという疑問の答えは得られていなかったが、次の疑問は、それにどれだけの費用がかかるか、だった。
六月。
僕は五番街の法律事務所に、メジャーレーベルとのライセンス交渉の代理人をつとめることを求めて、彼らは承諾した。
そして、取引をするための遅々としたプロセスが始まった。
第一回は、堅苦しく複雑だった。だけど、思ったほど悪くはない。
僕は彼らを説得し、Muxtapeがこのままサービスを続けることが皆にとっての最良の利益になる、と納得させた。
これでうまく行きそうだった。
さらに二ヶ月、投資家と会合を持ち、サイトの次のフェイズを設計し、交渉を監督した。
困難が予想されたのは、Muxtapeが単純なオンデマンドサービスではない、という点で、オンデマンドよりは支払いが低くて済むはず、という点を考慮に入れてもらえるかどうかだった。
ライセンスの条件からはじめたかったのは、めずらしいwin-winになると思ったからでもある。
僕は、どんな通達があっても(at any given notice)、楽曲を検索して再生する機能を持たせたくはなかった。
一方、彼らもそういう昨日にあまりいい顔はしない（少なくとも、今の価格では）。
それまでは、すべての議論は数字に関するものだったが、
合意に近づくにつれて、掲載位置の販売とかマーケティングの方向性に話が移ってきた。
Muxtapeのモバイルバージョンを提案したが、否定された。
僕の柔軟性は身動きできなくなっていた。
Muxtapeに対して公正な取引をすることに心を割いてはいたけど、僕がずっと持ちつづけていた最大の関心は、サイトの統一性と使用感を保つことだった。
（それはライセンスを求めはじめた元々の理由のひとつでもある）
Muxtapeの経済面での各種の侵略に合意したのも、動かしたい(play ball)からだった。
だけど、編集と創作についてコントロールを手放すのはものすごくつらいことだった。
これと格闘している最中、Muxtape のサービスをホストしているAmazon Web Servicesから通告を受けたのが、8月15日。
Amazonの規約によれば、とんでもなく長い一覧に挙げられた楽曲を一営業日以内にすべて除去しなければ、
これはかなりの驚きだった。
RIAAからの連絡はずっと途絶えていたのだけれど、僕はこれをレーベルの理解が得られたためだと思っていた。
僕はライセンス交渉の最中にあること、これは事務的な間違いじゃないか、夏の金曜日の午後をとりもどせるようにするためにはなんでもしよう、ということを説明しようとした。
一営業日どころか、週末を越えて月曜日までやり続けても、結局、Amazonが要求する文書を作ることはできなかった。RIAAに電話で連絡したけれど、受けてもらうことさえできなかった。
これを解決できるはずだという、ほんとうに感じていたままの期待をそこにメッセージとして残した。
僕はまだ、これがなにかのひどいミスだと思っていた。
でもそれは間違いだった。
事態がすこし把握できてきた次の週。
RIAAの動きは、レーベルの親会社とは別の、自律したものだということ。
レーベルとの間で得た理解は、RIAAには継承されないということ。
どのレーベルも、僕を助けることに特に興味を持っていないということ。
彼らの見かたでは、交渉には影響しない、という。
僕は納得しなかった。
取引にはまだ数週間か数ヶ月（インターネット上では永遠に等しい）はかかる。
つまり、Muxtapeはすくなくとも年末までは止まったままということだ。
また、どうやって支払うかという問題も残っていた。
この変わりやすい世界では、急成長するウェブサイトがある場合でさえ、投資を受けるのは難しい。
ライセンスの取引すべてからの撤退。
どの取引も、単純さを信条とするこのサイトに対しては複雑過ぎるものになりつつあり、
僕がやりたい方向のイノベーションにとって、制約が強すぎ敵対的すぎるものになりつつあった。
開発にほとんど注意を向けられなくなってしまった結果、僕は自分のモチベーションに疑問を感じはじめていた。
僕は、すべてを犠牲にして急スピードで大会社を建てるために、これをはじめたんじゃない。
僕がこれをはじめたのは、音楽を愛する人たちのために単純で美しいなにかを作りたかったからだ。
だから、またそこからはじめたいと思う。
でも、いままでどおりのものではない。
ある、開発初期段階にある機能を取り入れるからだ。これからはその機能に中心的な役割を持たせたい。
Muxtapeは、バンドだけのためのサービスとして再出発する。
インターネットで活動するための、これまでにないシンプルで強力なプラットフォームとしての機能を提供する。
2008年のミュージシャンは、ウェブ開発者と手を組まない限り、オンラインで地位を確保する手段はほとんどない。
しかし、彼らのニーズは、実は共通の問題の中にあることが多い。
あたらしいMuxtapeは、バンドが自分の楽曲をアップロードして、それを埋め込みプレイヤーとして提供し、
もともとのMuxtapeの形式に加えてウェブのどこででも動かすことができるようになる。
魅力あるプロフィールを取り付ける機能、さらに、カレンダーや写真、コメント、ダウンロード、販売、あるいはニーズのある他の全ての追加機能のモジュールを提供する。
システムは0の段階から無限に拡張することができ、CSSデザイナーが使えるようなテンプレートシステムの層を設ける。
詳細は追って公開する。
ベータ版はいまところ非公開だけど、数週間以内に変更する予定。
これは機能の点でかなりの大きな転換だということは、意識している。
僕はいまも、音楽をオンラインで経験する方法を変革したいと思っている。
僕はいまも、相互接続された音楽のもっとも興味深い側面、新しいものをみつける、という側面を実現したいと思っている。
第一フェイズのMuxtapeをこれだけすごい場所にしてくれた皆さんに感謝します。
皆さんのミックスがなければ、ありえなかったことです。
音楽業界はいつかついてくるでしょう。ぜったいに、そうすることになるはずです。
Justin
友達が結婚するそうだ。
初めに聞いたときから彼氏どころかその兆しすらない自分と比べて妬ましいと思った。
他人の状態に嫉妬しててもしょうがないと思ってだんだん落ち着いてきたけれど、新生活への準備をしている話を聞いてまた妬ましさがぶり返してきた。
幸せになってほしいという気持ちがないわけじゃないけれど、所詮「こうきたらこうかえしましょう」っていうテンプレートっていうか、建前のような感じがする。
醜いと思うけれど、正直なところ。
３０いくまでには何とかならないかな、何とかしなきゃと思うけれど、それは世間体の為であって、一人で暮らせるなら孤独死してもいいからほっておいて欲しい。子供もいらない。親には申し訳ないけどさ。
結局ママに褒められる○○ちゃんズルイ！ってことかな。情けねえや。
今更だけど60行で作るPHP用テンプレートエンジンをクラス化した。
<?php class NoSixTemplate{ protected $template_dir = null; protected $template = null; protected $context = array(); function __construct($filename = null, $directory = null){ $this->set_template($filename); $this->set_dir($directory); } function set_template($filename){ $this->template = $filename; } function set_dir($directory){ if(substr($directory, -1) != '/') $directory .= '/'; $this->template_dir = $directory; } function set_data($context_key, $context_data, $overwrite = false){ if(empty($this->context[$context_key]) || $overwrite){ $this->context[$context_key] = $context_data; }else{ if(is_array($context_data) && is_array($this->context[$context_key])){ $this->context[$context_key] = array_merge($this->context[$context_key], $context_data); }else{ $this->context[$context_key] .= $context_data; } } } function reset($context_key = null){ if(is_null($context_key)){ $this->context = array(); }else{ $this->context[$context_key] = null; } } function convert_template(){ $filename = $this->template_dir.$this->template; $cachename = $filename.'.cache'; if(!file_exists($cachename) || filemtime($cachename) < filemtime($filename)){ $s = file_get_contents($filename); $s = $this->convert_string($s); if(is_writable($cachename) || is_writable($this->template_dir)){ file_put_contents($cachename, $s); } } return $cachename; } function convert_string($s) { $s = preg_replace('/^<\?xml/', '<<?php ?>?xml', $s); $s = preg_replace('/#\{(.*?)\}/', '<?php echo $1; ?>', $s); $s = preg_replace('/%\{(.*?)\}/', '<?php echo htmlspecialchars($1,ENT_QUOTES); ?>', $s); return $s; } function display(){ $cache = $this->convert_template(); extract($this->context); include($cache); } } ?>
<?php require_once('NoSixTemplate.php'); $template = new NoSixTemplate('template.php', 'template_directory'); $template->set_data('title', 'Example'); $template->set_data('list', array(10,'<A&B>',NULL)); $template->display(); ?>
今更ながら使ってみたけどこれすげーわ
テンプレート弄れば何でもできる
jsだってヘッダに直接埋め込める
プラグイン？いらんいらんｗそんなまどろっこしいことしないで直接テンプレートに書くわｗみたいな
画像は1Gだし
転送量とかけち臭いことも言わないだろうし
太っ腹すぎるよ
画像の管理も分かりやすい
同じ名前があれば上書き
シンプルだからパワフル
スキルがある奴は自分でツール作ってインフラとして利用させてもらえる
まあ、fc2まではいかなくても最低限タグを100％使えないブログはツールとしてはまったく使えない
記事にタグつかえないとか。ありえないっしょ、自分のブログなのにタグ使えないとか。wikipediaじゃねーつの
ようするに、公開ページと管理ページが一緒になってるようなブログは駄目
素人さんには便利だろうけど
なんつーか、馬力が全く違う感じ
これぞブログ
他のすべてのブログがしょぼしょぼに感じられる
まあ、2chとかもそうだけど、結局CGM系のサービスって最後は運営者の器の勝負なんだよな
りすくへっじっすかｗリスクテイクしろよそんくらいｗ
まあ、しょっぺーやつらは、しょっペーブログサービスでしょっぺー馴れ合い日記
書いて小さな世界で満足してなさいってこった。
via Twitterオタが非オタの彼女にTwitter世界を軽く紹介するための10ユーザ
まあ、どのくらいの数のプログラミング言語オタがそういう彼女をゲットできるかは別にして、
「オタではまったくないんだが、しかし自分のオタ趣味を肯定的に黙認してくれて、
その上で全く知らないプログラミング言語の世界とはなんなのか、ちょっとだけ好奇心持ってる」
ような、ヲタの都合のいい妄想の中に出てきそうな彼女に、プログラミング言語のことを紹介するために
習得させるべき10言語を選んでみたいのだけれど。
（要は「脱オタクファッションガイド」の正反対版だな。彼女にプログラミングを布教するのではなく
相互のコミュニケーションの入口として）
あくまで「入口」なので、アーキテクチャに過度に依存するアセンブラ等の低級言語は避けたい。
あと、いくら基礎といってもBrainf*ckやUnlambdaのような難しすぎるものは避けたい。
ポール・グラハムが『Arc』は外せないと言っても、それはちょっとさすがになあ、と思う。
そういう感じ。
彼女の設定は
ロジカル度が高く、頭はけっこう良い
まあ、いきなりここかよとも思うけれど、「Java以前」を濃縮しきっていて、「Java以後」を決定づけたという点では
ただ、ここでオタトーク全開にしてしまうと、彼女との関係が崩れるかも。
この情報過多な言語について、どれだけさらりと、嫌味にならず濃すぎず、それでいて必要最小限の情報を彼女に
伝えられるかということは、オタ側の「真のコミュニケーション能力」の試験としてはいいタスクだろうと思う。
アレって典型的な「オタクが考える一般人に受け入れられそうなプログラミング言語（そうオタクが思い込んでいるだけ。実際は全然受け入れられない）」そのものという意見には半分賛成・半分反対なのだけれど、それを彼女にぶつけて確かめてみるには一番よさそうな素材なんじゃないのかな。
「プログラミング言語オタとしてはこの二つは“教育用言語”としていいと思うんだけど、率直に言ってどう？」って。
ある種の言語オタが持ってるラムダ計算への憧憬と、ACM監修の関数型言語的純粋さへのこだわりを
彼女に紹介するという意味ではいいなと思うのと、それに加えていかにも参照透過な
の二要素をはじめとして、オタ好きのする要素を言語にちりばめているのが、紹介してみたい理由。
たぶんこれを見た彼女は「Emacsだよね」と言ってくれるかもしれないが、そこが狙いといえば狙い。
この系譜の作品がその後続いていないこと、これがポール・グラハムの間では大人気になったこと、
ポールグラハムがウェブサービスの構築に使って、それがいろんなウェブサービス開発者にも影響しててもおかしくはなさそうなのに、
実際のウェブサービスでこういうのが使われないこと、なんかを非オタ彼女と話してみたいかな、という妄想的願望。
「やっぱりプログラミングはバッチ処理のためのものだよね」という話になったときに、そこで選ぶのは「awk」
でもいいのだけれど、そこでこっちを選んだのは、この言語にかけるラリーとdankogaiの思いが好きだから。
断腸の思いで延ばしに延ばしてそれでも2008年、っていうPerl 6のリリース予定日が、どうしても俺の心をつかんでしまうのは、
そのリリースというイベントへの諦めきれなさがいかにもオタ的だなあと思えてしまうから。
Perlのリリース延期を無駄だとは思わないし、拙速なリリースは無茶だろうとは思うけれど、一方でこれが
GuidoやMatzだったらきっちり予定通りリリースしてしまうだろうとも思う。
なのに、各所に頭下げて迷惑かけてリリースを延期してしまう、というあたり、どうしても
「自分の言語を形作ってきた哲学(TMTOWTDI)が捨てられないオタク」としては、たとえラリーがそういうキャラでなかったとしても、
親近感を禁じ得ない。言語自体の高評価と合わせて、そんなことを彼女に話してみたい。
今の若年層でPostscriptを直で書いたことのある人はそんなにいないと思うのだけれど、だから紹介してみたい。
PDFよりも前の段階で、DTPの哲学とか印刷技法とかはこの作品で頂点に達していたとも言えて、
こういうクオリティのプログラミング言語がエディタで書かれてたんだよ、というのは、
別に俺自身がなんらそこに貢献してなくとも、なんとなくプログラミング言語好きとしては不思議に誇らしいし、
いわゆるJava VMでしかスタック型言語を知らない彼女には見せてあげたいなと思う。
PHPの「HTMLに埋め込み可能な点」あるいは「RDBMSとの接続性」をオタとして教えたい、というお節介焼きから教える、ということではなくて。
「HTMLのテンプレートエンジンを作り続ける」的な感覚が言語オタには共通してあるのかなということを感じていて、
だからこそアメリカ版『Yahoo!』の開発言語はPHP以外ではあり得なかったとも思う。
「MとVとCを分離なんてできない」というオタの感覚が今日さらに強まっているとするなら、その「オタクの気分」の
源はPHPにあったんじゃないか、という、そんな理屈はかけらも口にせずに、
単純に楽しんでもらえるかどうかを見てみたい。
これは地雷だよなあ。地雷が火を噴くか否か、そこのスリルを味わってみたいなあ。
こういう述語論理風味の計算をこういうかたちで言語化して、それが非オタに受け入れられるか
気持ち悪さを誘発するか、というのを見てみたい。
9本まではあっさり決まったんだけど10本目は空白でもいいかな、などと思いつつ、便宜的にC++を選んだ。
Javaから始まってC++で終わるのもそれなりに収まりはいいだろうし、テンプレート以降のメタプログラミング時代
の先駆けとなった言語でもあるし、紹介する価値はあるのだろうけど、もっと他にいい言語がありそうな気もする。
というわけで、俺のこういう意図にそって、もっといい10本目はこんなのどうよ、というのがあったら
教えてください。
「駄目だこの増田は。俺がちゃんとしたリストを作ってやる」というのは大歓迎。
こういう試みそのものに関する意見も聞けたら嬉しい。
なんとなく駄文を書きつらねます。
コレ、いわゆるボヤキ駄文です。なのでテキストとしては面白くないです。
----
WEBサービスの運営に携わっています。
この会社ですが、大本尊（＝社長）の意向がとても強く（良い意味でも悪い意味でもトップダウン）
さまざまなことに日々振り回されてます…
で、本題に入りますが、ほんの２ヶ月くらい前までは、まったく微塵もなかった話ですが、
先月中旬に突然、人件費削減（＝人員削減）しろと…もうそなってくると真っ先に出てくる案は
■全社的にあまり残業しない（or させない）
の２案が毎度のごとくでてくるわけです。
⇒人員不足や経験不足の面を常に派遣会社経由のスタッフの方々に支えて頂いてもらっているのが現状ですが…
今回はそれでも、ほぼ全派遣会社経由のスタッフの方を１,２ヶ月以内に契約解除という大本尊の意向の元の
流れになってしまったのです。
といいながら、当然会社としては、本年度の計画や目標を設定してて、そんな案件内容を今の人員で？？？
つまり人員不足＝馬力不足のまま達成できるの？と目に見えて強く感じのです。
しかも当然ですが、その目標に満たない場合は、
生暖かく詰められる（＝クビ）なわけで。。
サラリーマンはつらいなぁ。
このことについて、上の人達に相談しても、皆さん「しょうがない」or「とりあえず今は…」という、
まるで共通の回答テンプレートでも出回っているような回答の返事しかしないのですが。;S
⇒ググると、そういう回答例でもでてくるのか？
ってくらい皆同じことしか言わない（爆）
でも、サラリーマンはつらくても、派遣会社経由のスタッフの方々はもっとつらいだろうなと思うと
最後まで（現場の当人達よりの目線で）できるだけフォローとバックアップに努めなければと思い、
己を奮い立たせてるのです。
情けない話でもありますが、残念なことに自分にはコネや権力が殆どないので、当人達が気落ちしているのを
励ましたり、話し相手になったり、次に繋がる様に同業他社でも使える、ささやかですが、自己流で覚えた
ナリッジと小ワザを伝授してあげたり、（こっそりと）他社で正社募集しているところ募集要項のページURLの
テキストリンク集をかき集めてメールで送ってあげるくらいしかないのです。。
同じチームの２８前後くらいの方達（就職氷河期の世代？？というのでしょうか？）をみていると
なんだかホントにかわいそう…日頃のお仕事でのがんばりやお世話になっている恩を
正にアダで返してるとはこのことかなと感じて、たまに分けもわからず、ホロっと涙目になっている自分がいます。
大本尊の機嫌がいいときは、株価がいいのか買収が成功したのか、新聞でいいこと書かれたのか、
さっぱりわからないけど、とにかくタイミング的な時期が良いときは、バイトでも派遣会社経由の
スタッフでも契約社員でも正社員になれる門戸が開いてるのに…実際、何人も社員になってもらって
一緒に働いてがんばっている人達もいるのに、こんな肝心なときにこそ、チャンスを廻してあげれない
自分に、正直最近凹みがちです。
むぅ、どーしたものか。
と、ボヤキつつ、自分が腐るのはいつでもできること。と思いながら、
最後の最後までフォローとバックアップに努めようと再決心しまスたです。
・・・あ、もちろん仕事もしなきゃ♪（←新規案件の提案・立案のこと。
jabba
米国の方ではもう出てるみたいだね・・・日本でもそういう会社が出ないかな。
通常利用料は無料で付加サービスに対して課金制度取るようにして、利益を出す。
付加サービスでは単語を直接Webの本の上で調べられる機能、編集に関しての機能追加、添削サービスetc.
付加サービスだけでは利益に心もとないので、本のページ上下隙間に広告を付ける（内容に合ったもの）
本の質感の再現も欲しい、あと電子ペーパーの普及に伴うサービスの拡大etc.
あとは、仮想本棚を登録者１人１人に無料設置、好きなWeb本を自分の本棚に並べられる様にし、書き手側からも自分の書いた本が本棚に並べられるとやる気に繋がる。
さらに一から書くから著作権は既存の本をWebに転記するよりも少なくなる。
著者はこちら側が用意したテンプレートに文章を記入するのも良いし、自分で作った表紙やページをアップロードしてそれを活用するのでも良い。
問題は著者側へのリターンが少なくて活性化しないことだけど・・・
出来れば有名な著者に出版してもらって、その場合はこちら側からある程度の金額はお支払いして。
○○を書いた○○○○が！Webで出版！
なんてのが理想だけど、無料で読めるし大勢の人に読んでもらって、その著者の他の出版物にも興味を持ってもらえるかもしれない。
でも、リアル出版社からの圧力とか出版社契約とかの問題もあるから難しそうだけど・・・
現状でもサイトで小説書いてる人、掲示板で書いてる人、埋もれた名作の著者、小説家志望の練習の場を少しでも書店で販売してる本と同等の立場まで持っていければ良いと思う。
諸君、私はC++が好きだ
諸君、私はC++が好きだ
諸君、私はC++が大好きだ
テンプレートが好きだ
STLが好きだ
Boostが好きだ
FC++が好きだ
Macで
BSDで
演算子の意味が変わり、直感的なコードが書き下せる時など心がおどる
動的言語の優位性を語っている奴等にそれを見せた時など胸がすくような気持ちだった
Boostが好きだ
Boost::lambdaを使って(_1 + _2)と二つの引数を足算した結果を返す無名関数を定義した時など感動すらおぼえる
Boost::regexで正規表現を書く時などもうたまらない
Boost::shared_pointerでオブジェクトが自動的に解放されるのは最高だ
納期に追われて急いで書かなければならないパーサを
Boost::spiritでBNFを記述して書いた時など絶頂すら覚える
そんなC++が複雑だと思われているのはとてもとても悲しいものだ
テンプレートが好きだ
諸君 私に付き従うC++好きの諸君 君たちは一体何を望んでいる？
更なるC++を望むか
糞の様なC++を望むか？
BoostやFC++によってさらに変態的になっていくC++を望むか？
よろしい ならばC++だ
だが、LL全盛の時代の陰でもはや組み込みかHPCぐらいでしか使われないという中傷に耐え続けて来た我々には
ただのC++ではもはや足りない！！
我々はわずかに小数
Perl、PHP、Python、Ruby、JavaScriptに比べれば物の数ではない
だが諸君は一騎当千のBinarianだと私は信じている
ならば我らは諸君と私で総兵力100万と1人のコンピュータサイエンティスト集団となる
我らを忘却の彼方へと追いやり、インタプリタしか知らない連中を叩きのめそう
髪の毛をつかんで引きずり下ろし 眼(まなこ)をあけて思い出させよう
連中にインタプリタでは実用的なプログラムが書けないということを思い出させてやる
C++には奴らの哲学では思いもよらない書き方がある事を思い出させてやる
1000人のBinarianの集団で 世界を変態的なコードで埋め尽くしてやる
逝くぞ 諸君