「ソースコード」を含む日記

■iTunes再生回数Top25を意味もなく晒してみる＋晒させてみたい。

この表を作る方法は以下のとおり。Macユーザならすぐ出来る。

1.まず、デフォルトのスマートプレイリストのTop25を表示する。そしてiTunesでの情報表示を、上のバーを右クリックしてタイトル、アーティスト、再生回数のみにチェックする。

2.全体を選択。iTunes.txtというファイル名で保存する。UTF-8で。

3.次のソースコードをコピペして、iTunes_list.rbという名前でiTunes.txtを保存したのと同じフォルダに保存する。

f = open("iTunes.txt")

printf "|*タイトル|*アーティスト|*再生回数|\n"

f.each{|str|
  str = str.gsub(/\t/, "|")
  str = str.chop
  printf "|"+str+"|\n"
}

4.ターミナルを立ち上げ、cdと打ち込んだ後にスペースを空けて、iTunes.txtとiTunes_list.rbが入っているフォルダを、ターミナルのウインドウにドラッグアンドドロップする。その後returnキー。

5.ruby iTunes_list.rbと打つと、はてな記法で表組されたテキストが出てくるので、これをはてダにコピペすればおk。

もしアルバム名なども表示したかったら、まずiTunesで表示したいヤツを出して選択してiTunes.txtにコピペ。そして最初のprintfのところを適宜書き換えればいい。

WinユーザもRubyを動かせる環境がそろってる人なら、すぐに出来ると思う。

さあ、みんなも再生回数晒してみようぜ。

Permalink | 記事への反応(3) | 09:35

ツイートシェア

■読むしかない

ＳＩによくあるリプレイスの案件で、数百ページもある既存システムの仕様書を渡されて「あとはよろしく」と肩をたたかれた。

この仕様書がWordのファイルなんだけど、恐ろしいことに章ごとにファイルが分けられていて、総数が百以上になっている。目次もない。

でまあ、連休をつぶして仕様書を読み込んでいる。

ソースコードを読むときもそうだけど、こういうのはとにかく読むしかない。

はじめのうちは、その分量に恐れおののいて「Wordを結合するツール」とか「Wordを検索するツール」とか使って効率化しようとするんだけど、ぜんぜん作業が進んだ気がしないので、適当な所にあたりをつけてぶつぶつ言いながら（「書いた奴氏ね」とか）とにかく読み込んでいく。

そのうちに全体の輪郭がぼんやりと見えてきて、何となく目星が付いてきて、（そこそこ）効率的に読めるようになる。

そんな連休２日目。

Permalink | 記事への反応(2) | 21:22

ツイートシェア

■ソースコードの修正履歴をコメントアウトで残す方式だった。別れたい

修正履歴をコメントアウトで残す方式だと、新旧のコードを並べて比較した時なんか分かりにくいｗｗ

可読性さがっちゃうしｗｗ

男にはせめてソースコード管理システムくらい使って欲しい・・・

バグとか出て、ソースコード修正が必要になったら・・・・もう最悪ｗｗ

せめて普通にVSSやCVSぐらいは使って欲しい。

常識的に考えて欲しいだけなんです！

コメントアウト方式のソースコードをレビューする時の恥ずかしさとか分かる？

あのね？たとえば商用系で障害が起こって10??20人ぐらいで対策会議とか開くでしょ？

それぞれ腕利きのプログラマとかお客さんとか来るわけじゃない？

みんな普通にSubVersionやGitやMercurialやClearCaseとか期待してるわけでしょ？

コメントアウト方式でノコノコ書いてたら大恥かくでしょうがｗｗ

Permalink | 記事への反応(1) | 00:25

ツイートシェア

■http://anond.hatelabo.jp/20081111053810

同じくITで半端なWebデザインやってるもんだけど。

ああ・・ベーマガとかテクポリとか懐かしいな。

昔は円を一つ描くだけでも、だらだらとしたBASICかマシン語が必要だったのにな。

でも、その苦労が楽しかったんだよな。

信長とか殆どBASICだったからLINE文でちんたらちんたら描画して、BREAKキーかなんかでプログラムストップさせたら

まんま、ソースコード丸見え。

で、まぁ・・そこで信長の名前や表示コメント変えたりしてオリジナル信長の野望でプレイした。

ハイドライドくらいまでくると、殆どマシン語になっちゃったからいじくれなかったけどPSG3和音の

音楽は今でも耳につくな。

Permalink | 記事への反応(0) | 17:43

ツイートシェア

■衰退していくIT業界に向けて、30半ばシステムエンジニアが昔の思い出を語るよ 0010

　たくさんのブックマークと期待コメントありがとうございました。続きを書いていきます。

※これは連載です。初めての方は下記から見てください。

衰退していくIT業界に向けて、30半ばシステムエンジニアが昔の思い出を語るよ 0001

• 前回の補足
  • FM-7を兄貴が選んだのは、当時出ていたPC-8801シリーズより低価格だったからと思われる。当時の価格、PC-8801（228,000円）、FM-7（126,000円）
  • FM-7が家に来た当時、僕は12歳の少年だった。兄貴は4つ上。
  • コンピュータ周りの細かな間違いは、おっさん特有の軽い健忘症なので、さくっとスルーで。
  • この話は思いつきで書き始めたものだし、大仰なオチは無いので、期待するだけ損と思われる。

　兄貴のFM-7で、初めはゲームばかりやっていたのだが、しばらくすると「信長の野望」には裏技が存在する事を知ってしまった。裏技を使い、稼いだ金に物を言わせて増兵をしまくり、簡単にクリアできるようになってしまった僕。（ど忘れしたのでどんなのか調べたら、『いったん年貢率を0にしてから収穫前に上げることで米収入が上がり、その米を元手に富国強兵を行うといったテクニック』らしい。）

　その頃やっていた他のゲームは、ハイドライド、ウィザードリィ、ザ・ブラックオニキス、デゼニランド、ポートピア連続殺人事件など。自分で買ったゲームがほとんど無いので記憶は薄いのだが、みんなテープ媒体だったように思う。

　一方、兄貴はというと、なにやら熱心に毎月雑誌を買って、どこかへ投稿しようと試みているようだ。当然、それとなくその雑誌も読んでみる事となる。それが僕と「マイコンBASICマガジン」、そしてプログラム言語との出会いだった。目の前にある機械がゲーム専用機ではなく、自分の思い通りに動かせるのか、と気付いた時の驚きと快感。今も忘れられない。

　前述の通り、その当時のマイコンは、電源を入れるとROMから「BASICモード」がいきなり立ち上がるのだけど、この状態から自力で何かを動かしたい場合、BASICと言われるプログラム言語を実行することにより、色々出来るようになる。

　マイコンBASICマガジン（長いので以降「ベーマガ」）は、主にBASICのソースコードが掲載されている専門雑誌だ。基本的に、雑誌の構成は読者からの投稿で成り立っており、自ら投稿したBASICのソースコードがベーマガに掲載されるかどうかが、その当時マイコン小僧たち最大の憧れであり、ステータスだった。

　ご他聞に漏れず、ベーマガを読み始めてから僕はBASICの虜となってしまい、今までやっていたゲームの頻度は自然と減り、BASICへ時間を割くようになった。

　今思えば、兄貴は本気でBASICプログラムを投稿し、掲載される気満々だったので、かなりの難しいコードを書いていたんだと思う。結局、彼の思いが果たせたのかは分からない。掲載されたコードを見せてもらった事が無いし、それなりに競争率が高かったので多分ダメだったんだろうと思う。

　一方、僕といえば、ベーマガで面白そうなゲームのソースを見つけては、一生懸命コードを入力し、誰かが作ったゲームをやることに専念していた。しばらくの間、記憶する媒体がテープレコーダーしか無かった為、目の前にある「ベーマガ」のゲームがやりたければ、一字一句間違えずにソースコードを打ち込まなければならず、何回も何回も間違えながら入力していた記憶がある。テキストエディタなんてものがそもそもなかったので、ただ入力するだけでもかなりの難作業だった。

　そのうち入力しているだけでは我慢できなくなり、なんとなくBASICというものが理解出来て来たので、自力でゲームと言うものを作ってみる。しかし、「作る」と言っても一切の独創性はなく、ベーマガに載っていたゲームのアイデアをほとんど流用していた。

　一番初めに作ったのは、縦スクロール型のスキー風障害物除けゲームだった気がする。僕みたいな初心者がこれを選ぶのには理由があって、RND（乱数発生関数）とPRINT（画面表示）だけ知っていれば縦スクロール自体はターミナルが勝手にやってくれる為、後は壁の判定処理を入れるだけでよい。特に難しい事を考えなくてもある程度作れるからだ。

　当時、知っている命令語のレパートリーは極めて少なかったし、現在のwebのように、簡単な方法で調べる手立ても無かった。綴りや文法が分からない命令はいちいち調べるのが面倒くさいので、とにかく使わない方針で押し通していた。

　ロジックも見よう見まねで無理やりひねり出してたものだから、乱数が過激に発生して、スキーのゲレンデが右側から大きくはみ出して表示がぐちゃぐちゃになったり、両側の壁に隙間が出来てプレイヤーがそこをすり抜けてしまったり。しかし、こういう試行錯誤の中で、ロジックの作り方や、エラー処理と言うものを知った。

　立体迷路とか、横スクロールのゲームとか、ベーマガで輝いていたあのゲームを自力で作りたかったけど、その当時はそこまでのレベルに達することは出来なかった。

　ブクマを燃料として書き続けます。

次：衰退していくIT業界に向けて、30半ばシステムエンジニアが昔の思い出を語るよ 0011

Permalink | 記事への反応(2) | 04:18

ツイートシェア

■はじめてSEOを専門業者に発注した。

まとめ

• 私個人が運営するサイトをSEO業者に発注したことに関する日記。（契約期間は11月1日から6ヶ月間）
• 業者の担当者とのやりとり、業者がSEOと題して行ったこと、順位変動等について私自身の考えを加えながら紹介中。
• 現時点ではまだ業者名を出すつもりはない。
  • 発注前に「少なくとも1ヶ月以内に月10000セッションをYahoo!から得たい」と言ってあり、業者は「それなら我が社のサービスを今すぐに」と乗っている。
  • 業者ははてブでもよく見るWEB担当者フォーラムでよく名称が出てくる企業。
• 発注したのはトップページに対して5キーワードで、サブページ4ページに関して計5キーワードで、Yahoo!・Google・LiveSearchで10位以内。
  • なるべく頻繁にトップページの5キーワード（キーワード1,2,3,4,5）での順位チェックと順位変動を記録していく。
  • キーワード1がいわゆるビッグキーワード、2,3,4,5がビッグキーワード＋１単語の複合ワード。

• 11/10から3日間くらい。Google検索「SEO業者」で20位に入ってた。
• Webマーケティング ブログで紹介された。
• 「はじめてSEOを専門業者に発注した。Part2」> http://anond.hatelabo.jp/20081120014452

はじめは特に本気じゃなかったんだけど、一括見積もりみたいなサイトを利用してみた。予算は10万円以下にしといた。

その結果、3つの業者から連絡が来た。そのなかに、よくweb担とかに出てくる業者があって、ほかの業者に比べて見積もりが安かったから、そこにしてみた。

んで、担当の人と30回くらいメールのやりとりをした。当初、見積もりの段階ではトップページをビッグキーワード1つで上位表示してほしいって書いておいたけど、担当の人が予算が10万円あるなら、トップページだけじゃなくサブページもSEOを施してみてはどうかと提案してくれたから、そういうことにした。

結果、トップページをビッグキーワードを含む5キーワードでSEO（このうち4キーワードは業者に考えてもらった）、サブページ4ページを複合キーワード計5つでSEOということになった。サービスの内容はページのHTMLをチェックし「ページ改善書」というのを作ってくれるというものと、外部リンクの増殖。

どのくらいで効果が出てくるのか？と聞いたところ、キーワードによって異なるけど、ほとんどの場合は11から15日で上位表示している。ビッグキーワードに関してはもう少し遅くなるかもしれないが、そうでなければこのくらいとのこと。

サービスの開始は毎月1日か15日からで、1日からはじめるのなら今すぐに発注所をFAXせよとのことで、すぐに発注書を送った。ちなみに料金は翌月末払いだった。

発注書を送ると、すぐに確認のメールが来た。また外部リンクに使うキーワードのリストもきて、わからないことがあったら気軽に質問してくださいといったことが書かれていた。

外部リンクに使うキーワードのリストを見て、さっそく疑問がわいてきた。例えばトップページはキーワード1、キーワード2、キーワード3、キーワード4、キーワード5の5キーワードで上位表示ということだったけど、設置する外部リンクに使われるテキストは「キーワード1キーワード2」というもの。（リンクに使うテキストには字数制限があるそうだ）

キーワード345はリンクに使われていないがそれでも上位表示は可能なのか。すべてのリンクを「キーワード1キーワード2」とせずに、リンクの何割かを「キーワード1キーワード2」とし、残りの何割かを「キーワード3キーワード4キーワード5」としないのはなぜか。といったことを質問した。

一週間経つけど、これについての回答はこない。回答きた。システムの問題らしい。

システムの都合上、多くのアンカーテキストを扱うことができないが、検索エンジンは関連する語句を見分ける能力があるからキーワード1キーワード2を使ってもキーワード3,4,5で上位表示を行うことができると考えている。

改善書にてキーワード3,4,5は無理やりサイトタイトルに入れるように指示された。

無理やりってのは、「はてな匿名ダイアリー」→「はてな無料ブログ　匿名ダイアリー」みたいな感じ。

また、今日になって発注後はじめてのメールがきた。外部リンク設置作業1段階目が終了したとのこと。メールには「これから20から25日ほど経ったら、効果が出始めると思います」といったことが書かれていた。さて、ここでまた疑問がわいてきた。

発注前の話では15日ほどで上位表示されている場合がほとんどと言われていたが、発注後では20日ほどで効果が出始めるとなっている。となると15日の時点ではまだ効果が出始めていないということだから、15日ほどで上位表示されている場合がほとんどであるということと矛盾している。これについても質問をしたが、まだ返信はこない。回答きた。

平均して11日だが、発注されたキーワードは難易度が高いため20日ほど要すると考えている。

キーワード2,3,4,5については業者に決めてもらったのだが、業者はそのときに「ビッグキーワードは難しいが、ターゲットをしぼったこれらのキーワードなら短期間で上位表示できることが多い」と言っていた。「短期間」なのに「平均」の倍近くの期間を要するなんて、これまた腑に落ちない。

また「ページ改善書はいつ送られてくるのか」と質問したところ、「ページ改善書は今回のみ特別に無料で作成します。のちほどお送りいたします。」といった内容の返信がきた。発注前では契約内容としてページ改善書というのが入っていたが、発注後では「特別無料サービス」のような「おまけ」のような言われ方をしている。ここもどうも腑に落ちない。

ちなみに外部リンクを設置したサイトのリストももらった。外部リンクは500ページに設置したそうだが、500ページというのは5つのサイト（RSSを自動取得してページを量産するタイプのブログ、独自ドメインで構築されている）のそれぞれ100ページ（いちおうインデックスされているみたい）からということみたいだ。さっそくだがAdSense違反報告に出しといた。

web担の記事で、今回発注した業者の代表が「リンク元ページとリンク先ページとの内容が関連しているほどSEO効果が高い」「リンク元ページが多くのページからリンクされているほどSEO効果が高い」といったことを書いていた。しかしながら今回設置された外部リンクは関連性の低いページからのリンクで、また被リンク数の指標を示すGooglePRがなしか０のページからのリンクだった。言っていることとやっていることが違うが、どういうことなのか、と質問のメールを出しておいた。返信きた

外部リンクについては情報開示できません。

発注前は良質なリンクといわれていたが、どうもこれが良質なリンクだとは考えづらい。私が知識不足なだけなのだろうか。

補足:11/7

ちなみに料金は月額4万円ほど。契約期間は最短の6ヶ月で発注した。担当の人は韓国人と日本人のハーフみたいな名前だった。

見積もりがきた残りの2つの業者はどちらも初期費用10万の月間費用数十万で、予算10万？笑わせんなｗみたいな感じの内容だった。

まぁ、1ヶ月くらいたって順位がどう変わったか等を報告するよ。

補足:11/8

ブクマがたくさんついてたからもう少し具体的なことを補足しておく。

はじめに発注したのはYahoo!の月間検索回数20000回ほどのキーワード。担当に提案されたのはこのキーワード＋1単語の複合キーワード4つで、それぞれ2000回ほど。さらにサブページ4ページに対して計5キーワード、それぞれ2000回ほど。

また発注前の時点で私のサイトはGoogleとLiveSearchで担当に提案されたキーワード＋1単語の複合キーワードでは上位に表示されているが、発注したキーワードではGoogleもLiveSearchも80位ほど。Yahoo!はここ1年で100位以内に入ったことはない。セッション数はGoogle:LiveSearch:Yahoo!=90:8:2くらい。サイトの内容としてはYahoo!からのセッションのほうが成果をあげやすい。今回発注したのは上記の10キーワードでGoogle・LiveSearch・Yahoo!の3検索エンジンで目標10位以内というもの。

サイトのスペックは、GooglePR4、Yahoo!被リンク8000、Google被リンク100、Yahoo!/Googleインデックス数260、はてブ7件、Jエントリーに登録されてる。ブログをCMS代わりに使ってる個人運営のサイト。

http://b.hatena.ne.jp/entry/http://anond.hatelabo.jp/20081107171440

えらいタイムリーなタイミングでメールの返事が来とるｗ

被リンクの増殖はスパムと評価されないように、何回かにわけ、1週間単位で設置していくそうだ。開始から7日たった11/7にメールの返信がきたというのも納得できなくもないかもしれない。

http://anond.hatelabo.jp/20081108163851（抜粋）

SBMで多くのブクマを集めた方がよっぽど上位表示されるような気がする。

サイト診断をしてもらったのだが、今考えると、金返せ、と言いたくなる内容だった。

「サイトのヘッダー部分の画像を変えた方が良いですよ」

「Googleページランクを確認した方が良いですよ」

こんなもんだぞ。これってSEO業者のコンサルティングなの？

悪い事は言わんから、効果なかったらあきらめた方が良いかも。追加で金払ったりするのはやめた方が良いよ。

6ヶ月の契約で発注書を送っちゃったから、多分これから6ヶ月分は効果があろうとなかろうと料金を払わなければいけないと思う。もしかしたら「発注前後で言ってることが違うぞ！金返せ！」みたいに訴えれば払わなくて済むかもしれないのかもしれないけど、そういう面倒なのは嫌だ。

もちろん、効果がなかったら契約期間の延長をすることはない。これは担当の人にも言ってある。

実際に、担当の人とのメールのやりとりでしつこく「検索エンジンは外部サイトからのリンクを重要視している」と言われたし、「タイトルタグやメタタグにキーワードを入れることで上位表示云々」とも言われた。多分だけど、少なくともこの担当の人は回答テンプレみたいなのを打ち込んでるだけでSEOについて大した知識はないんだと思う。もしかしたら改善書というのも、このレベルのものなのかもしれない。

私のサイトはどちらかというとWEB初級者が好むような内容。だからはてブやdeliciousにはあまりブクマが付かず、Yahoo!ブクマが多い。けどYahoo!ブクマははてブと違って直リンクじゃないからたくさんブクマされてもあまり意味ないんだよね。もちろんゼロではないと思うけど。

検索エンジンの中の人が「被リンクは少なくともtitleタグより重要だ」と言っているように、やっぱりSEO業者ってのは料金が高かろうが安かろうが、外部リンクの設置がメインなんだと思う。

今は上位に表示されなければ金は取らないというところにしか頼む気にはなれないなあ。

そういうところはトラックバックスパムとか掲示板スパムをやりまくって、たまたま順位アップしたときだけ料金請求をし、順位アップしなかったら放置って感じが多いらしい。

金がたまったらSEO塾を受講してみたい。

補足：11/9

http://b.hatena.ne.jp/entry/http://anond.hatelabo.jp/20081107171440

koichi22

5キーワードくらいの順位取得ならGRC使っておけばいいんじゃないかな。

http://seopro.jp/grc/

紹介ありがとうございます、さっそくインストールしました。いい感じですが、無料版だと5キーワードまでしか設定できないんですね。残念。トップページの順位チェックに使わせていただきます。現時点でのトップページの順位は

http://anond.hatelabo.jp/20081109222125

その程度の予算しかないのに、SEOをしよう、という考えを改めるべき。

他の会社はもっとSEOに予算使ってます。

私がSEOを発注したのは企業サイトではなく、私個人が運営しているサイトだよ。確かに「もっと資金を用意してから」っていう意見はそのとおりだと思うけど、今年中にまとまった金が必要になってしまってね。個人相手だから業者も適当にあしらってる可能性もなくもないか。

補足11/10

※まだサブページにキーワード6,7でリンクを設置しただけのはずだから、サブページの被リンクがトップページに多少の影響を与えているかもしれないけど、恐らく自然と落ちたのだと思われる。

メール着た。

サイトを拝見したところ、非常に良く出来たつくりになっております。

ただ、少し改善した方がよいと思われる所がございました。

お世辞か？以前までは「改善書」となっていたが、今回のメールからは「改善指示書」と名称が変わったそうだ。メール中にはtitleタグ、metaタグ（keywordsとdescription）、キーワード出現率に関する説明がそれぞれ2行ずつくらい書いてあった。

それと、添付されていた改善書をこれから見てみようと思う。ちょまって、なんかこれひどい。一番最初に書いてあったのが「<META NAME="ROBOTS" CONTENT="NOINDEX, NOFOLLOW">を入れるな」。普段からXHTMLを使っているからか、全部大文字だと初心者っぽく見えるな。

メタディスクリプションタグとは、HTMLのソースコードに<description> ｘｘｘ </description>タグとして記述されているタグことです

説明間違ってる・・。

ごめん、なんか誤読してた。titleタグとmetaタグの具体例はちゃんと書かれていた。もっとも、キーワードを繰り返しすぎでおかしな文章になっていたけど。下記ページの悪い例のほうみたいな感じ。

http://www.suzukikenichi.com/blog/write-rich-keyword-content/

補足：11/11

昨日今日と、Googleが大きくランクダウンしてる件。まぁランクダウンしてるといっても、下位から超下位でトラフィックに大した影響はないのだけども。

補足：11/12

急降下したり、急上昇したり、もう少し穏やかにしてくれないものかね。LiveSearchなんか結構上がってるように見せかけて、11/9と比較すると実際には下がってるという。

http://b.hatena.ne.jp/entry/http://anond.hatelabo.jp/20081107171440

sozesoze

SEOスコープはどう？　ttp://search.submit.ne.jp/seoscope.html

紹介ありがとうございました。さっそく使ってみましたが、微妙です。

いちいちログインしなきゃいけないのが面倒なのと、登録した3サイト（というか3ページ）の順位チェックも一括ではなく、サイトごとにいちいち「診断結果レポートを見る」をクリックしなければいけないのが面倒です。（先日紹介したGRCというのは、「実行」をクリックすると登録されているページ・キーワードを一括にチェックできます）

それと、LiveSearchには対応していないみたいですね。

今、順位をチェックしてみたところ、サブページ（キーワード6,7,8,9,10）はすべて「圏外」と出てました。サブページのうち2ページに関しては、11/7の時点で外部リンクの設置がすべて完了しているとのことだったけど…

補足：11/13

補足：11/13

順位変動しすぎだろ・・

補足：11/15

担当者ではなく企業に直接問い合わせてみた。

すごく悩んだのだけど、やっぱりひどすぎる気がする。担当者は話が通じなそうだから、業者のお問い合わせフォームから直接問い合わせてみた。「必ず2営業日以内にご連絡」と書かれていたから、17日までには返信がくるはず。

問い合わせた内容は担当者の説明が矛盾していること、担当者の説明が誤っていること、担当者が糞だから違う人に代わって説明してほしいということ。

11/16：担当者から返信きた。下記はそのコピペである（タイプミスは担当者のもの）

お世話になります。（企業名）の（名前）でsう。

弊社のサービスのご説明に関して、行き違いがり申し訳ございませんでした。

改めて現在の状況を確認し、資料をまとめ、再度ご連絡させていただきますので今しばらくお待ちください。

補足：11/16

補足：11/17

キーワード５がここ1年くらい2位をキープしてたけど、3位に下がってた。ちなみに2位はついこの間まで3位だったページで、1位のサイトのサブページ。

補足：11/18

順位チェックツールでちゃんと動いてくれるものを探しています。

複数のURLを複数のキーワードで一括チェックでき、（短期間でも）ログを保

存できるツールを探しています。オンラインのものでも、ダウンロード・インストールが必要なものでもいいのでオススメがあれば教えていただけるとうれしいです。

Permalink | 記事への反応(7) | 17:14

ツイートシェア

■http://anond.hatelabo.jp/20081103101050

大概でいえば、それが有効である事は多いでしょう。

ですが、それだけでは足りないこともあるし、何を読むかが重要だし、「プログラミング初心者」の種類にもよる、という但し書きも必要だと思います。

そうすると、プログラミング初心者はサンプルコードがしっかり載ったリファレンスを片手に何か一つの言語で作られたオープンソースのソースコードを読んで学習するのがいいのかな？

というのも、単語（関数、ステートメント、ライブラリ、etc.）を文脈で覚えるには、文脈を理解しなければならないが、文脈を理解するためには知識が必要だから。そして、知識を得るには単語を知らないと難しい。

何も知らない状態ならば、まずは単文複文、変数、ステートメント、構造化プログラミングetc. と、言語で使用される概念を理解しなければならない。それが基礎から応用へ向かうにつれ、単語量が増え、記憶すべき事柄が増える。そしてついには、バッドノウハウ、歴史的理由、処理系依存などが出てくる。それらは必要とされるから存在する。その、必要とされる理由、必要とされる文脈を理解することが、それを応用するために必要なことだ。応用力、それは記憶と理解のバランスだ。

リファレンスとサンプルコードと実働コードを用いる手法の目的は、リファレンスで意味を、サンプルコードで小さな文脈での使用例を、実際の使用例でさらに大きな/多様な文脈での実例を、それぞれ得ていくことにある。それには、それぞれの文脈が理解できるという前提があり、今の知識・語彙で理解できるソースコードを選択しなければならない、ということである。しかし、どのようなソースコードを読めば一番効率が良いか、という問題は非常に難しい。また、実在するコードを読むもう一つの理由が、モチベーションの維持にある。しかし、これがまた難しい。難解な方が燃える人もいれば、簡易なほうが良い人もいる。また、コーディングルールや手法の違いを学ぶために、数をこなすことも有用だろう。しかし、そのためのモチベーションを維持するのは大変である。

なんにせよ、そういった、自分にあったお手本となるソースコードなど、初心者には選べるはずはなく、そういう意味で初心者にはお勧めできないかもしれない。いや、もしかすると、どこかの増田が「初心者が読むべき10のコード」とか書いてくれるかもしれないが、個人的には運命の出会いかとも思う。普段愛用しているツールに機能追加したくなって、ソースコードを読んで行くうちに覚えたとか。

Permalink | 記事への反応(1) | 13:43

ツイートシェア

■コーディングができないたった（ry

http://anond.hatelabo.jp/20081101050330

http://blog.livedoor.jp/dankogai/archives/51133522.html

いや、自分はコーディングが全くといっていいほどできないSEという肩書きをもつスーツなのですが。

上の増田氏のエントリからすると、

「コーディングができない＝関数(ライブラリ、クラス、メソッド、etc...)を覚えてないから」

となり、dankogai のエントリからすると、

「関数等を覚えられない＝文脈で覚えてないから」

となるのかな。

もちろん自然言語とプログラミング言語が違うのはわかっていますが、わりと共通点はあるのかな、と。

そうすると、プログラミング初心者はサンプルコードがしっかり載ったリファレンスを片手に何か一つの言語で作られたオープンソースのソースコードを読んで学習するのがいいのかな？

まあこの辺は正直スーツにはわからない世界ですが。

Permalink | 記事への反応(2) | 10:10

ツイートシェア

■http://anond.hatelabo.jp/20081025202001

いまさらだがFizzBuzz。

1から100まで、3の倍数5の倍数云々って、全部定数の計算じゃね？

というところに気付き、自称メタプログラマー（略してメタグラマー）俺の血が騒いだ。

定数計算なら、それは実行時ではなくコンパイル時に行なわれるべきだ……。

というわけでC++テンプレートメタプログラミング召喚。

#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言語はコンパイル時に関数が実行でき、その結果をソースコードとして取り込める！

ただし実行できるのは簡単な関数だけだけど……。

以下、それを使ったD言語によるメタプログラミング的実装。

import std.stdio;

// これでFizzBuzzを全部出力するコードを作るぜ！
string makeFizzBuzzCode() {
    string code;
    for(int i = 1; i <= 100; ++i) {
        // 効率？　コンパイル時にそんな配慮は要らん！
        if(i % 3 == 0 &amp;&amp; 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 &amp;&amp; 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言語の宣伝でした。

みんな使おうD言語！

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)

D言語本家配布元（無料でコンパイラが入手できます）

http://www.digitalmars.com/

それにしても、ちゃんとD言語のシンタックス・ハイライトを実装しているはてなは偉い。（笑）

Permalink | 記事への反応(1) | 22:45

ツイートシェア

■プログラマになれません

私は今某社でWebアプリ開発の補助をするアルバイトをしている。一応少しはコードを書く。でも、自分はプログラマじゃないな、と思う。素敵なアルゴリズムを考えたりもしない。アプリの設計は当然社員さんがやる。私がやることと言えば、機能追加のための簡単なコードを書いたり、簡単なWebアプリをフレームワークを勉強しつつ書いて、見た目をCSSで整えて、そんなことだ。

やりがいを感じないわけではない。やっぱり自分の書いたコードが上手く動けば嬉しい。でも、プログラマの壁を読むと、何となく自分はコーダーになれてもプログラマにはなれないような気がしてくる。一応FizzBuzzは解ける。以下、そのコード。※追記参照

#include <stdio.h>

int main(void){
  int i;

  for(i=1; i<=100; i++){
    if((i % 3 == 0) || (i % 5 == 0)){
      if(i % 3 == 0)
        printf("Fizz");
      if(i % 5 == 0)
        printf("Buzz");
      printf("\n");
    }
    /* 以下二行と返り値追記 */
    else
      printf("%d\n", i);
  }
  return 0;
}

アルゴリズム自体は多分2分足らずでもやっと思いつき、書いてる途中で脳内もやっとを形にできた。でもCの文法を忘れていて、コンパイルを通すのに独習Cを調べつつ、5分くらいかかった。

その時に、(i mod 3 = 0)とか書いてて、なんか自分はやっぱりダメなんじゃという気にさせられた。代入と比較の区別がついてない。そういえば先日も、編集してるファイルが違ってたとかカンマをつけ忘れてたとかでエラーがでてるのに、それになかなか気がつかなかったり、if文の条件が成立する場合としない場合を逆に考えてしまったりと、そんなぼんくらミスばかりしている。

そんなときに、「ああ、自分ってプログラマ向いてないのかも」と感じさせられる。

そしてなにより自分がプログラマに向いていないと思うのは、知的探求心の問題だ。プログラマを志していたがその道を諦めた友人に、なぜプログラミングの勉強をやめたのか？と聞いたとき、彼から帰ってきた答えはこうだった。「この道に進んだら一生勉強しなきゃいけないから。自分にはそんなことはとても無理だと思った」この答えを聞いたとき、でもプログラミングの勉強だったら楽しくないのかな？と思った。しかし自分を省みたとき、私自身もそう熱心にプログラミングの勉強をしているわけではないことに気がついた。Macに入っている一通りの言語でとりあえずHello!World!を書いたりしたが、だからといってそれらの言語の得手不得手がはっきりわかるまで勉強したわけではない。文法だって忘れてしまった。アルゴリズムを熱心に勉強したことはないし、なにより自分は最も唾棄すべき「とりあえず動けばいい」と思っている人間だ。エラーがでてそれを直しプログラムが動いたとき、なぜそのエラーが出なくなったのか？なぜ動くようになったのか？そうしたことを納得がいくまで調べることは滅多にない。なんとなく、ああいう理由なのかな？と考えて、それだけですませてしまう。もう一度書くが、自分が書いたプログラムが思った通りに動いたときは楽しい。でも、そこで止まってしまうのだ。なぜ動いたのか？それを徹底して考え、理解してはいない。

今のバイト先の開発チーフには、いつもこの点を注意される。なぜそれでいいのか徹底的に考えろ、ドキュメントをちゃんと読め、関数の挙動がわからなかったらソースを読め、と。でも正直、動いてくれたらそれでいい。さすがにライブラリのドキュメントを読む癖は多少ついてきたが、けれどもそのソースを読むところまでは正直頭が、気持ちが回らない。

だから、自分はプログラマになれないと思う。いつまでたってもコーダーのままだろう。

プログラミングはとても特別な才能がいる仕事だと思う。それは、アルゴリズムやデータ構造、オブジェクト指向などといった抽象的なものごとを理解し、それを具体的なソースコードに落とす頭だけではなく、ものごとについてとことん考える知的探求心も必要だ。その二つを満たす人こそがプログラマなのだと、一コーダーなりに私は思う。

だから私は、プログラマになれません。

【追記】

さすがに仕様を満たしていないのは恥ずかしいので直しました。こういう間抜けなミスをするところがなぁ…orz。

mainについて熱くなっている方々の話にはいまいちついていけないのですが、私はこれをCで書いたつもりですし、戻り値がないことにも警告はありませんでした。コンパイラはgcc version 4.0.1 (Apple Inc. build 5465)です。

Permalink | 記事への反応(11) | 20:20

ツイートシェア

■エガミくんの脆弱性のやつ

こんにちは！
id:Hamachiya2 ですよー。
ブックマークコメントでIDコールされたけど、
「コメント返すためにブクマ (してリンクジュースを流すこと) 」は、ちょっと今回は間接的にでもできない感じなので
こっちで返答しますね！

http://zapanet.info/blog/item/1418
http://b.hatena.ne.jp/entry/http://zapanet.info/blog/item/1418

2008年10月19日 hiroyukiegami id:Hamachiya2 助けてください。色々やってみたのですがやはり、わかりません…。コード公開しております。すみません、誰か具体的に教えてもらえると嬉しいのですが（涙）http://flickr2.in/flickr.zip

いきなりソースコード丸投げして「わかりません」って言われてもちょっと困るよー。
まずはその「色々やってみた」っていうの、どういうことをやってみたか教えてもらえるかな！

で、どうすればいいのか、一緒に勉強していこうよ。
ここで。

(関連リンク)
今年ぼくが書いたはてな匿名ダイアリーまとめ - ぼくはまちちゃん！(Hatena)
ドリームメーカー : ブラウザで簡単にノベルゲームが作成できるWebサイト
ソーシャルゲーム速報

Permalink | 記事への反応(5) | 03:28

ツイートシェア

■http://anond.hatelabo.jp/20081015040555

近い内に仕様書もソースコードも直さないといけないんだろ？

その時にもっと苦痛になるぞ。

Permalink | 記事への反応(0) | 08:01

ツイートシェア

■ソフトウェア開発での分担

増田的話題じゃないけど、書きたくなったので書く。

多人数で開発するとき、ユーザーの意見を聞いて仕様を決めた人がソースコードを直接書くことはあまりなさそうだが、

一番大事な部分だけでも仕様を決めた人が書くべきだと思う。

さらに、詳細の仕様を決める人と上記の2工程を担当する人は別にして、詳細仕様がサンドイッチ的に上下から同じ人に評価される形というのが望ましいように思う。

どっか、これに近いことやってる会社ないかなぁ。多重請負じゃ絶対無理だけど、自社で完結してるようなとこで。あれば様子をみてみたい！

Permalink | 記事への反応(0) | 05:36

ツイートシェア

■ブクマしたことで満足している人達

PHPを使ってミニブログを作るチュートリアル:phpspot開発日誌

これが120ブクマされてる。

内容は、たったこれだけ。

Create a Basic Shoutbox with PHP and SQL - NETTUTS

PHPを使ってミニブログを作るチュートリアル。

簡単な掲示板のようなShoutBoxというものを作るチュートリアルです。

PHPソースコード、SQL、HTMLマークアップやCSSの作成の流れも分かります。

PHP初心者の方はトライしてみましょう。

関連エントリ

* jQueryを使ったブラウザ上で動作するLeopardデスクトップの構築

* Ajaxベースのクールなショッピングカート作成

* 超クールなログインフォームを作成するチュートリアル

一番大事なのは紹介されているページである、

Create a Basic Shoutbox with PHP and SQL - NETTUTS のはずだ。

しかしこのページをブクマしてるのは24人しかいない。

結局何もやらない人ばかりブクマしてるんだな。

phpspotの本文中3行はブクマコメントに書いておけばいいことだし。

被ブクマ件数は10月9日20時頃に参照した。

Permalink | 記事への反応(1) | 20:12

ツイートシェア

■http://anond.hatelabo.jp/20081006220009

ruby のソースコードってなんか気持ち悪いな。

なんでだろ。

C系になれてるとかっこがないのが気持ち悪く感じるのかな。

Permalink | 記事への反応(3) | 22:03

ツイートシェア

■社内オープンソースプロジェクトについて（まとまらない版）

うまくやる方法を考えてみた。

っつうか、社内オープンソースってのが既に矛盾か・・・

【目的】

社内でオープンソースのプロジェクトを行うことにより以下の４つの価値を生み出すことができる。

　１．部門間におけるノウハウの共有

　２．外部に公開した場合の宣伝効果

　３．新製品・新サービスの実験の場

　４．仕事そのものを作る効果

　（４補足）

　　　・新入社員の研修などが発生した場合に効果的に仕事を割り当てることができる。

　　　・在宅勤務をせざる得ない状況における作業の割り当て。

【前提】

基本的に下記の事項を前提として考察を行う。

　１．社内の人間であれば、誰でも参加できる。

　２．途中で各人の任意のタイミングで抜けても、問題とならない。

　３．社内の人間であれば、だれでもアクセス可能なWebサーバー上で情報を管理する。

　　ただし、必要に応じてアクセス制限をかけることができる。

　　インターネットに接続されている、Webサーバーは存在しているものとする。

　４．各開発者は場所的、時間的に同じところにいないことを前提とする。

【Webサーバーが用意すべき機能】

以上の前提より、下記の機能を有したWebサーバーの準備を行う。

１．構成管理機能

　簡単にソースコードの取得、更新を行えるようにして、その履歴を残す。

　案：Subversion

２．Wiki

　マニュアル、方針、仕様などを記録する。

　Wikiにすることにより、誰でも編集が容易になる。

　案：Trac/Redmine/Pukiwiki

３．フォーラム

　意見や質問を容易におこなえる掲示板を用意する。

　これにより、場所と時間にとらわれずに意見交換を行うことができる。

　案：Wiki/Redmine

４．タスク管理、バグ管理

　どのようなバグやタスクが残っているか管理を行う。

　これにより、リリース時期の予測、作業の有無を効果的に確認できる。

　案：Trac/Redmine/BugZila

５．テスト管理

　テスト仕様やテストの状況を管理する。

　これにより、リモート環境であってもリアルタイムにテストの進捗状況を確認できる。

　案：TestLink

６．コードレビューのサポート

　ReviewBoardの使用

　http://blog.monospace.jp/2008/03/24/reviewboard_installation/

　（※要調査）

７．フィードバックを受ける場

　関係者のモチベーションを保つため、成果物に対して、フィードバックを受ける場を作成する。

　案：社内のソーシャルブックマーク、アンケート機能

【効果的な手法】

その他、効果的な開発の進め方を考察する。

１．xUnitの使用

　xUnitでテストコードを記述することにより以下の効果がある。

　・修正後でも修正前と同じ動作するかどうかが、確認できる。

　・テストコード自体が一種のリファレンスになる。

　これにより、人の作成したコードでも修正を行いやすくなり、前提１、２の人の出入りに対応する。

２．自動ビルド

　自動ビルドを定期的に実行する。また、１のxUnitを使用して単体テストの失敗も監視する。

　これにより、サーバー上にコンパイルが通らないソースコードや単体テストに失敗したコードの存在をチェックすることができる。

　これは不特定の人間がかかわった場合に異常を検知するためである。

３．短期的なリリース

　開発者のモチベーションを保つため、一定のめどがついた時点でα版という形でリリースを行う。

だめだまとまらん。

Permalink | 記事への反応(0) | 22:22

ツイートシェア

■表情筋を使わなくなった

最近、表情筋を使わなくなってきてやばいなー、と思う。

風邪か何か知らないけど、ここ２週間くらいずーっと他人とまともに話をしていない気がする。

あ、いや、してるか。日曜にとても気の合う友人が家に訪問してきて、延々とヲタトークしてた時は割りと表情動いていたと思う。

でも、平日はずーっと無表情で職場の仕事用デスクトップに向かい、ソースコード書いてる。無茶なスケジュールを組まされた案件のソースコードを、ただ書いてる。時折、他案件の相談とかも舞い込んでくるんだけど、その受け答えがクソ面倒なのね。あー、うぜぇって単純に思う。仕事に関する話じゃなくても、職場で話しかけられると何であろうがとりあえずうぜぇって思う。自分の頭の向いている方向以外の話をするのが、とにかく面倒。

なんだろう、この感覚。コミュニケーション能力が一時的に欠如しちゃってる。表情を動かすのが辛い。すべて面倒。寝るのも、飯食うのも、立ち上がるのも、考えるのも。すべての行動に、鎖がまとわりついているかのような感覚がある。

物理的なすべてが面倒なんだけれど、キーボードとマウスだけは脳直結で動作する。うん、なんて都合のいい。

生きる目的も、やりたいことも、能動的な何もかもが薄れてきてるから、いつでもボールを追って車道に出た子供をかばって死ねる体勢はできてるよ。ハードディスクの中身を見られたって、死んだあとなら問題あるめぇ。いくらでも蔑み馬鹿にするがいいよ（死んだ後限定）。というか、そういう正義の死に方をしたいね。

あと、苺ましまろのアニメを見てた時も表情緩んでたと思う。よし、ロリコンの俺死ね。でも死ぬと親が悲しむから、死ねない。父親も母親も早く死ねば…、いや、この俺が命令する！「生きろ！」長生きしろや二人とも。これは何人たりとも破れない絶対遵守の力だ、わかったな。あー、つまりは死ねない死ねない死ねない。十字架背負わされてるよ。

ちょっと気が楽になった。ありがとうマスダマス。

Permalink | 記事への反応(0) | 15:57

ツイートシェア

■Muxtapeの物語

「オンラインで流せるテープ」 を提供していた muxtape が閉鎖して一月。昨日出た、運営者からのメッセージを勢いで翻訳する。

http://muxtape.com/story

http://muxtape.tumblr.com/post/51762430 ←反応

僕は音楽を愛している。

音楽を愛している人にとって、そして音楽そのものにとって、音楽を共有するという欲望は、本質的でかかせないものだと信じている。

愛すべき音楽に出会ったとき、僕たちは友達をターンテーブルの前に集め、CDを貸し、カーステレオで鳴らし、ミックステープを作る。

僕たちは、音楽から感じるものを知っているから。他の誰かにも、それを感じてほしいから。

Muxtapeの物語が始まったのは、僕がオレゴンでやっていた、週一の大学ラジオ番組だ。

その番組で流した曲の記録のかたわら、そのプレイリストをウェブに上げていた。ひとつのブロックが、その週の番組を記録したカセットに対応するというものだ。

当時、ミックステープは斜陽の時代に入っていた。でも、あのプレイリストのページは、ミックステープと同じ役割を、そして多くの点でよりよい役割を果たすはずだ。僕は番組を終えてからも、そのことをずっと考え続けた。

ミックステープのように、プレイリストはある意図を持って集められたものであって、その価値は単なる足し算にとどまらない。

ミックステープとは違って、プレイリストには物理的に届けるための制約がない。でも同時に、そこには実際の楽曲がない。

誰かがそのページを見にきてくれても、知っている曲があれば共感してくれるだろうが、 本来リスナーである人たちにミックスを実際に編集する手間を押し付けるのは、もともとの目的をダメにしてしまう。

五年後、インターネット技術が格段に進歩していた。

僕はウェブサイトの実験的なUIを試す仕事をしていた。

プレイリストのことをまた考えはじめ、ついにそれに命を吹き込んだのは、その頃のことだ。

僕の音楽を（ミックステープ的な意味で）共有するという欲望はなくなってはいなかった。

だけど、その行き場はなくなりつつあった。

大手のブログサービスは音楽ファイルを短期的に置けるようにしていたけれど、

そういう場は僕が求めていたものではない。

カセットテープを手に握ったときにうまれる、突き動かされるような感覚。

それを手にしただけで、プレイヤーを探してそいつの使命を遂げさせたくなる。

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の素晴らしさを知っていて、ただ、支払いを欲しがっているだけだった。

その点については同情する。

僕は、共同で提案を行うにはまだいくらか時間が必要だと伝え、決定を先延ばしした。

数週間後、EMIとの会議をした。

彼らは大きく違ったタイプだった。

僕は会議室に入り、8、9人と握手をしてテーブルの前に着くと、目の前に "Muxtape" と題された電話帳並のファイルがあった。

彼らは半円状になって左右の脳のように僕の回りに陣取った。片方は法律、もう片方はビジネス企画。

会議の相手は交互に切り替わった。

「貴方は意図的に権利侵害をしている、サービスを止めるまでに数時間の猶予は与える」という法律サイドのハードな尋問と

「仮にサービスを止めさせられなかったら、どのような協力がありえると思うか？」というおずおずとしたビジネスサイドとの議論。

僕は提案を作るのに二週間を求めたが、二日と告げられた。

決断をしなければならなかった。

僕がみるに、選択肢は三つ。

第一は、全てをやめること。これはずっと考えていなかったことだ。

第二は、メジャーレーベルのコンテンツを全て禁止すること。これなら、直近の危機を回避することができそうだが、二つ大きな問題があった。

ひとつは明らかなことだけど、ユーザーがミックスに使いたいと思う大半の音楽を禁止することになってしまう、ということ。

もうひとつはメジャーレーベル以外に関して、楽曲の所有権と利用をどう扱うべきかという重い問題についてなにもやらないに等しい、ということ。

中規模のレーベルと独立アーティストにも、彼らのコンテンツがどのように使われているかについて、それほど圧力は使えないにしろ、大企業と同様の基本的な権利がある。

第三の選択肢は、完全にライセンスを受けるモデルにすること。

これは、ユニバーサルの人に会ってからずっと挑戦していたことだ。

他のサービスでライセンスを受けているものは、いろいろな理由でうまくいっていることを知っていた。

同時に、Muxtapeの場合は違うということ、少なくとも模索する価値はあることを知っていた。

レーベルがそこに価値を見出しているかどうかという疑問の答えは得られていなかったが、次の疑問は、それにどれだけの費用がかかるか、だった。

六月。

僕は五番街の法律事務所に、メジャーレーベルとのライセンス交渉の代理人をつとめることを求めて、彼らは承諾した。

二週間後、今度は弁護士を同席して、僕は四レーベルに会った。

そして、取引をするための遅々としたプロセスが始まった。

第一回は、堅苦しく複雑だった。だけど、思ったほど悪くはない。

僕は彼らを説得し、Muxtapeがこのままサービスを続けることが皆にとっての最良の利益になる、と納得させた。

これでうまく行きそうだった。

さらに二ヶ月、投資家と会合を持ち、サイトの次のフェイズを設計し、交渉を監督した。

困難が予想されたのは、Muxtapeが単純なオンデマンドサービスではない、という点で、オンデマンドよりは支払いが低くて済むはず、という点を考慮に入れてもらえるかどうかだった。

ライセンスの条件からはじめたかったのは、めずらしいwin-winになると思ったからでもある。

僕は、どんな通達があっても(at any given notice)、楽曲を検索して再生する機能を持たせたくはなかった。

一方、彼らもそういう昨日にあまりいい顔はしない（少なくとも、今の価格では）。

Muxtapeの特徴的な機能は、複数の意味で強みになった。

最初の危険信号は八月に来た。

それまでは、すべての議論は数字に関するものだったが、

合意に近づくにつれて、掲載位置の販売とかマーケティングの方向性に話が移ってきた。

Muxtapeのモバイルバージョンを提案したが、否定された。

僕の柔軟性は身動きできなくなっていた。

Muxtapeに対して公正な取引をすることに心を割いてはいたけど、僕がずっと持ちつづけていた最大の関心は、サイトの統一性と使用感を保つことだった。

（それはライセンスを求めはじめた元々の理由のひとつでもある）

Muxtapeの経済面での各種の侵略に合意したのも、動かしたい(play ball)からだった。

だけど、編集と創作についてコントロールを手放すのはものすごくつらいことだった。

これと格闘している最中、Muxtape のサービスをホストしているAmazon Web Servicesから通告を受けたのが、8月15日。

RIAAからの訴状がAWSに届いている、と。

Amazonの規約によれば、とんでもなく長い一覧に挙げられた楽曲を一営業日以内にすべて除去しなければ、

サーバーを止められて全データを削除されることになっていた。

これはかなりの驚きだった。

RIAAからの連絡はずっと途絶えていたのだけれど、僕はこれをレーベルの理解が得られたためだと思っていた。

パニックになりながら何度かAmazonとメールを交換し、

僕はライセンス交渉の最中にあること、これは事務的な間違いじゃないか、夏の金曜日の午後をとりもどせるようにするためにはなんでもしよう、ということを説明しようとした。

一営業日どころか、週末を越えて月曜日までやり続けても、結局、Amazonが要求する文書を作ることはできなかった。RIAAに電話で連絡したけれど、受けてもらうことさえできなかった。

そしてサーバーは止められ、アカウントは停止された。

僕はドメインネームを新しいサーバーに移して、

これを解決できるはずだという、ほんとうに感じていたままの期待をそこにメッセージとして残した。

僕はまだ、これがなにかのひどいミスだと思っていた。

でもそれは間違いだった。

事態がすこし把握できてきた次の週。

RIAAの動きは、レーベルの親会社とは別の、自律したものだということ。

レーベルとの間で得た理解は、RIAAには継承されないということ。

どのレーベルも、僕を助けることに特に興味を持っていないということ。

彼らの見かたでは、交渉には影響しない、という。

僕は納得しなかった。

取引にはまだ数週間か数ヶ月（インターネット上では永遠に等しい）はかかる。

つまり、Muxtapeはすくなくとも年末までは止まったままということだ。

また、どうやって支払うかという問題も残っていた。

この変わりやすい世界では、急成長するウェブサイトがある場合でさえ、投資を受けるのは難しい。

サイトがまったくない状態では、筋違いもいいところだ。

だから僕は、これまでの人生で一番つらい決断をした。

ライセンスの取引すべてからの撤退。

どの取引も、単純さを信条とするこのサイトに対しては複雑過ぎるものになりつつあり、

僕がやりたい方向のイノベーションにとって、制約が強すぎ敵対的すぎるものになりつつあった。

開発にほとんど注意を向けられなくなってしまった結果、僕は自分のモチベーションに疑問を感じはじめていた。

僕は、すべてを犠牲にして急スピードで大会社を建てるために、これをはじめたんじゃない。

僕がこれをはじめたのは、音楽を愛する人たちのために単純で美しいなにかを作りたかったからだ。

だから、またそこからはじめたいと思う。

約束したとおり、サイトは復帰させる。

でも、いままでどおりのものではない。

ある、開発初期段階にある機能を取り入れるからだ。これからはその機能に中心的な役割を持たせたい。

Muxtapeは、バンドだけのためのサービスとして再出発する。

インターネットで活動するための、これまでにないシンプルで強力なプラットフォームとしての機能を提供する。

2008年のミュージシャンは、ウェブ開発者と手を組まない限り、オンラインで地位を確保する手段はほとんどない。

しかし、彼らのニーズは、実は共通の問題の中にあることが多い。

あたらしいMuxtapeは、バンドが自分の楽曲をアップロードして、それを埋め込みプレイヤーとして提供し、

もともとのMuxtapeの形式に加えてウェブのどこででも動かすことができるようになる。

魅力あるプロフィールを取り付ける機能、さらに、カレンダーや写真、コメント、ダウンロード、販売、あるいはニーズのある他の全ての追加機能のモジュールを提供する。

システムは0の段階から無限に拡張することができ、CSSデザイナーが使えるようなテンプレートシステムの層を設ける。

詳細は追って公開する。

ベータ版はいまところ非公開だけど、数週間以内に変更する予定。

これは機能の点でかなりの大きな転換だということは、意識している。

でも、Muxtapeの核となる目標は、変わっていない。

僕はいまも、音楽をオンラインで経験する方法を変革したいと思っている。

僕はいまも、相互接続された音楽のもっとも興味深い側面、新しいものをみつける、という側面を実現したいと思っている。

第一フェイズのMuxtapeをこれだけすごい場所にしてくれた皆さんに感謝します。

皆さんのミックスがなければ、ありえなかったことです。

音楽業界はいつかついてくるでしょう。ぜったいに、そうすることになるはずです。

Justin

Permalink | 記事への反応(3) | 20:25

ツイートシェア

■u¨??л??AÜ[ØÒ[è??Φ??¦vc????ª???????????????? : ????êÅ[Ø : ýì[E???? : YOMIURI ONLINEi????Ж??j

あの国で商売するのだったら、全く別のソースコードを作ってやらないと。

Permalink | 記事への反応(0) | 18:22

ツイートシェア

■http://anond.hatelabo.jp/20080918163227

愛の告白をしたためたソースコードを君の心にcommit!

↓

conflictしました

Permalink | 記事への反応(0) | 17:19

ツイートシェア

■http://anond.hatelabo.jp/20080918163227

愛の告白をしたためたソースコードを君の心にcommit!

↓

commit権限がありません

Permalink | 記事への反応(0) | 16:34

ツイートシェア

■

今、プロジェクトの共通ライブラリのソースコードをダウンロードしてみたら、俺が書いた箇所のコメントがわかり辛いと、コメントで指摘されたんだ。

どうだろう、ソースコードのコメント欄で愛の告白ってのは。最高にgeekな告白方法じゃないかと思うんだ。

Permalink | 記事への反応(2) | 16:32

ツイートシェア

■http://anond.hatelabo.jp/20080831163038

いやいや、そういうことじゃなくて

なんとなく人の命を論理的に考えちゃう人って、

全ての行動はソースコードで書き表されるとか思ってるんじゃないか、という揶揄です。

メソッド名に「kill()」とかあっても気にせず実行しちゃう、みたいな。

Permalink | 記事への反応(2) | 16:38

ツイートシェア

■ありがとう

研修での課題消化が一番早かったということで

俺だけいきなり客先投入。

そして、ただただ動くプログラムを作成する日々

５年目になって余裕のあるプロジェクトへ投入され

はじめてソースコードレビューをしてもらう。

もういろいろいろいろ言われたは。

遅くなったが、本当の意味でのプログラマになれるように

今はひたすら勉強＆実践中

Permalink | 記事への反応(1) | 23:56

ツイートシェア

■Googleストリートビューについて見て回ってみた

ほっといたけど気にはなっていたので、色々見て回ってみた。

肯定派否定派入り混じって議論してるけど、

やはりどうにもこのサービスについては賛同できない。

肯定派の諸君はこのサービスに来るべき未来を垣間見てGoogleを褒めちぎり

否定派を見ては「感覚が古い」「日本人特有の閉鎖的メンタリティは醜い」とか言ってるけど、

なんだか宗教みたいで気持ち悪いですね！

僕の信じてる神様はこんなにすごいんだぜ！はぁそうですか。侮辱したな教化してやる！！

どこの十字軍だ。

そもそもGoogleって信頼するに足る相手じゃねーだろ。

企業なんだから根っこはマイクロソフトやらライブドアやらと同じ。

便利に使えるものは便利に使わせてもらう、程度の扱いで十分っつーか

そーゆー扱いをしないといかんと思うんだけど。個人としては。

いくらお得意様扱いされてる店に行ったからといって、店員さんにすすめられたからって

何でもかんでも買うわけにはいかないでしょ？

Web上の無料サービスだから現実の商売とは違う？

たとえば、利用履歴上のいろんなショップにGoogleが

「こいつこのあたりに出没する可能性があるんで、広告だしましょうか？」って売り込むかもしれない。

ユーザー情報とヒモ付けされた位置情報やらクリック履歴やらを

（頭の悪い僕には良くわからん仕組みをもって)検索結果に反映させたりも出来るだろう。

Googleを使う限りは、だけれども、ストリートビューを使うことでどんどん僕らが得うる情報の幅を

「利便性」の御旗の元に狭められてくってわけだ。

アカウントを使ったときの検索結果を、過去の検索履歴とかで操作とかはもうやってるから、

これは既に実装されているかもしれない。

つまりは、自分自身の情報(名前やらアドレスだけでない、行動履歴)を売り渡してるも同じなわけで。

まーこれまでもそうだったんだけど、

今度のは現実空間を挨拶もしないで激写しまくって公開しまくるっつー

いくらなんでも暴挙だろそれはって感じなわけです。

情報のハンドリングが自分で出来ないんだから。

これまでだと「Google使わなきゃいいじゃん」で済んだ。

これからは「Googleへ削除依頼しろよ」に変った。

これってすごいことよ？稀だけど、自分のことをビックブラザーGoogleが既に知っていて、

自分でお伺いを立てないと削除もしてくれない。自分自身のことなのに。

自意識過剰とか、そういう問題ではない。

世界はそこまでフラットになりたがっているのか？？

最先端の情報を収集してるスマートですばらしい皆さんにとっては当たり前のことなんだろうけど、

Google使ってない人や、GoogleどころかPCもつかってない人(携帯オンリーの子供とか)にとっては

受け入れる下地もなにもあったもんじゃない。

知っていれば、進んでいれば、実験的であればなにをやってもいいのか？

事後承諾、事後承認されればいいのか？できちゃった結婚肯定派か。

よくわからんくなってきたけど結論。金持ってりゃ何やってもいいんだなってのが分かったのは今回得た知見。

あ、でも、ストリートビュー問題のおかげで、いろんな情報がGoogleに集められていることが

より多くの人に身体的感覚を伴って浸透した(しそう)ことは、いいことなのかもしんない。

それはそーとプログラマとかはストリートビューにすごく好意的だけど、

オープンソースプログラマはどう思ってるんだろう？

ソースコードの自由さえ担保されてたらなんとも思わんのかな。

Permalink | 記事への反応(2) | 04:27

ツイートシェア