Markdownのテスト

h1

てすてす

h2

てすてす

class Foo
end

はてなブログへのフィードバック

アンケートがきたのだけど、欄が狭かったので、こちらに書きます。

ひとことでいうなら、「あと一息で完璧」です。

まずシンプルで使いやすい。ベースデザインが見やすくなった。字がでかくてHigh DPIな環境で使いやすい。軽快に動く。テキストエリアがでかい。こういう、「ブログを書きたくなる」要素については、大満足です。

さらに、はてなブログには、（日本国内の）他社にない、決定的に良い点があります。

それは、「はてな記法」の存在です。

はてな記法が使えることには、WYSIWYGエディタにありがちな、モデルにビューが入り込んでるような気持ち悪さのない、「データをデータとして扱える」「exportしたときにゴミがない」「かといってHTMLみたいにpタグで囲む必要なく、改行だけでパラグラフを切れる」「本文を書くことに集中できる」という絶大なメリットがあります。はてな記法は、はてなブログ最強のアドバンテージだと思います。

はてな記法の存在は必ずしもプログラマだけの利点ではなく、1990年代にウェブサイトを建てようとした人や、ちゃんとブログを書きたいと考える非プログラマたちが頑張ってHTMLを覚えたように、最小限の記法を覚えるということは、達成したいゴールが見えていれば、HTMLに比べてはるかにシンプルな記法を覚えることはそれほど苦ではなく、一旦覚えてしまえば、かえって生産性が高いと感じるようになるものです。

では、アメリカのブログサービスはどうでしょうか。最近、ブログを書くサービスとして人気が急上昇しているのは、TumblrとPosterousだと思いますが、両者に共通しているのは、Markdown記法という、HTMLとゆるやかに互換の、はてな記法にかなり近い方式をサポートしていることです。

その反対に、途中からHTML記法のサポートをやめ、WYSIWYGオンリーに切り替えたVoxは、サービス自体が終了してしまいました。Wikiの世界でも、2007年頃まで市場の牽引役であったPBWikiは、WYSIWYGオンリーに切り替えた途端、成長が止まってしまいました。WYSIWYGエディタの最高峰はMS Wordだと思いますが、みなさんは何か文章を書くときに、はたしてMS Wordを使っているでしょうか。使っていないとすれば、その理由は何でしょうか。WYSIWYG化への誘惑は、なにやらテキスト編集アプリすべてを飲み込んでいく、大きなブラックホールのようにも思えます。

このことは、「イノベーションのジレンマ」の逸話を思い出させます。つまり、企業間で競争を繰り返すうち、ユーザの要望にすべて答えるためにどんどん機能を追加した結果、平均的なユーザの要求をはるかに上回ってしまい、もっと低機能だが低価格で扱いやすいものにじわじわ裾野を侵食され、やがてどんどん最上層に追いやられてしまう、というものです。

シンプルで良いサービスをシンプルに保つのは、非常に難しい。プロダクトへの思い入れが強ければ強いほど、常に機能追加の誘惑があるし、ブログをブログと考えると、WYSIWYGエディタはもうなくてはならない必須機能だ、と考えてしまうかも知れません。

しかし、そうやってブログ界で内輪の競争をしているうちに、何がおきたでしょうか。

ソーシャルメディアの台頭です。TwitterやFacebook、そして最近ではGoogle+も参戦してきました。

これらは、ブログを書く、というそもそものモチベーションの大部分を持って行ってしまっただけでなく、「WYSIWYGや修飾なんて、実はどうでもよかったのだ」ということを思い知らせてくれました。

まずTwitterでは140文字という制約があり、つい先日まで画像URLのインライン展開すらサポートされず、@記法やハッシュタグをのぞけば、ほんとうに一切の修飾がありませんでした。Facebookでは、文字数制限が緩和され、URLは自動でリンク先の画像やサマリーが読み込まれ、ユニークなユーザIDによらない本名ベースでの呼びかけが可能になりました。Google+は、最後発のため、さらに太字やイタリックなどもサポートされました。もちろん、+記法による、ユニークなユーザIDによらない本名ベースでの呼びかけをサポートしています。しかし、いずれもブログを書くことにくらべれば、圧倒的に楽チンです。

では、そうして、ソーシャルメディアに「気軽に書く」という部分の大半をもっていかれた現在、ブログに求められることは何でしょうか。

私は今こうやってブログを書いていますが、普段はGoogle+やTwitterをメインにポストしています。そこで書き切れない、修飾の手段が足りない、見出しをつけたり、画像を二枚以上貼ったり、リスト表現をしたり、テーブルを使ったりしたい、と感じたときに、ブログを書きたい、という強いモチベーションが沸き上がってきます。

ソーシャルメディアという気軽なツールに飼い慣らされた身にとっては、もう閉じるタグが必要なHTMLなんてありえない、しかし一方で、ソーシャルメディアで表現しきれない修飾をしたいからこそ、ブログを書くのです。

ソーシャルメディアに「WYSIWYGや修飾なんて、実はどうでもよかったのだ」と気付かされつつも、「修飾ができなくてイライラする」ことで、やっぱりブログが必要なこともあるんだ、と気付かされる。

Twitterを最左翼、MS Wordを最右翼とするスペクトルのなかで、はてなブログはどのポジションをとりにいくのでしょうか。イノベーションのジレンマ的には、左に近ければ近いほど、特定の時代の要請に過剰最適化されず、世代を超えて生き残っていける可能性が高いように思えますが、はたしてどうでしょうか。

そういう時代性のニュアンスを感じ取るセンスこそが、今すごく試されてるんだろうな、と感じます。

一方で、「ブログ」と改名したにもかかわらず、キーワードリンクが残るという形ではてなダイアリー仕様が残っている点については、思い切りが悪いなぁ、と感じます。はてなを知らない読者に「なんで下線ついてるの、紛らわしいからやめて」といわれるけれども説明できない。

ブログ著者は、自分の文章の「見せ方」を徹底してコントロールしたいと考えるものですから、意図しないリンク、それもさほど品質の高くないリンクは、はっきりいって邪魔です。Twitterでさえ、キーワードでつながりたいときには140文字のなかの貴重な一文字をさいて「#」をつけて明示的にリンクするのです。そのお手軽さがあるからこそ、新しい造語や言葉遊びが、ハッシュタグを介してたくさん誕生しました。これは、はてなも時代の変化にならって、とりいれるべきだと思います。日本語でのハッシュタグは区切りが難しいので依然として微妙ですが、そういうものこそ、工夫のしどころではないでしょうか。

また、はてな記法をさんざん褒めておいてからアレですが、はてなダイアリーが登場してからの8年で、さまざまなwiki記法が登場してきました。そして2011年現在、世界のスタンダードはMarkdownに収束しつつある、という確かな手応えを感じつつあります。これは主に英語圏で、単語を強調するときに*bold*のように*で囲む習慣があったことや、メールを書くときに見出しの下に=====や-----などで下線を引いて強調する習慣があったことをうまく活用し、そのままプレーンテキストで読んでも、HTMLにレンダリングされたものを読んでも、どちらでも読みやすい、というところが良かったのでしょう。

Tumblrで書くときも、GithubでREADMEを書くときも、だんだんとMarkdownを使う機会が増えてきました。そうなると、似て非なる文法であるはてな記法を使うと、なまじ似てるだけに、その非互換性にイライラさせられることが多くなってきました。

日本語でMarkdownを使うと、分かち書きの不在のため、*と*で囲まれた部分を自動で強調してしまうと、想定外の挙動にイライラさせられるであろうことは容易に想像がつきます。しかし、そういうインライン修飾以外の部分でも、Markdownとの「無意味かつ恣意的な」差異は、なくしていったほうがいいのではないでしょうか。

エンジニアの美徳は、遠い未来を見通せることです。Markdownが世界のスタンダードになる未来が予見できるなら、それになるべく準拠しておくことが、エンジニア主体の会社であることの強みを活かすことにつながるのではないでしょうか。

今、はてなブログは誕生したばかりです。過去の遺産も引きずっていません。はてな記法の仕様を変えるとしたら、この好機を逃してはあまりにももったいない。はてな記法が、この先10年20年と生き残っていけるかどうか。Markdownが10年後に世界を支配して、はてな記法ははてなだけで生き残り、Markdownを正式採用した、いまはまだこの世に存在しない日本発のブログサービスが、はてなブログを一気に追い越してしまう未来が見えないでしょうか。そういう未来の敵と、どうやって戦っていくのでしょうか。

ここまで、ぼくが主張していることは、「キーワードリンクやめろ」「はてな記法をMarkdown互換にしろ」と、いずれも「はてなの独自性・個性を捨てろ」と言っているように聞こえるかもしれません。

実は、そのとおりなのです。

サービスが成功する上で、それも大成功する上で大事なのは、独自性なんかではないのです。

「最高のサービスを作ること」なのです。

ここで、iPhoneが登場したときのことを思い出してみましょう。2007年当時、iPhoneというのは極めて斬新な存在でした。マルチタッチ、画面に出るソフトウェアキーボード、スタイラスいらずのUI、いずれも、個々の要素技術は、世の中にバラバラな状態で存在していたものでした。それを、ひとつの製品として完成度高くまとめあげた。その結果、iPhoneという商品はきわめて大きな「独自性」を身にまとって誕生しました。

しかし、その後どうでしょうか。すぐさまAndroidが登場し、Windows Phoneが登場し、WebOSが登場しては消え、iPhoneソックリな類似品が次々に登場しました。

今となっては、iPhoneとそれらの類似品のちがいを、スマートフォンに詳しくないひとたち伝えるのは、非常に難しくなっています。「うまく説明できないけど、とにかくiPhoneのほうが使いやすいよ」と。

それでもなお、世界中で作られる全ての携帯電話からうまれる総利益の大半を、Apple一社でごっそり持っていく状況が、何年も続くどころかその傾向はますます強まっているのです。

iPhoneが売れているのは、「独自性があるから」ではないのです。「最高に良いから」なのです。

ここにひとつ、パラドックスがあります。最高に良いものは、すぐに類似品が登場します。逆にいうと、良いものしか類似品は登場しないのです。つまり、最高に良い独自性こそ、すぐさま消えてなくなり、あまりよくない独自性だけが、誰も真似しないからという消極的な理由により、独自性を保っていられるのです。

ぼくは、はてなブログには「独自性」を目指すのではなく、直球勝負で王道な「最高」を目指して欲しい。

その「最高」のポジションに、一番近いところにいるのが、はてなブログだと思っているから。

応援しています。

スーパーpre記法（シンタックス・ハイライト）のテスト

スーパーpre記法：

class Redis
  class Classy
    class << self
      attr_accessor :db

      def inherited(subclass)
        subclass.db = Redis::Namespace.new(subclass.name, :redis => self.db)
      end

      def method_missing(method_name, *args, &block)
        self.db.send(method_name, *args, &block)
      end

      Redis::Namespace::COMMANDS.keys.each do |key|
        define_method(key) do |*args|
          self.db.send(key, *args)
        end
      end
    end

    attr_accessor :key

    def initialize(key)
      self.key = key
    end

    def method_missing(method_name, *args, &block)
      self.class.send(method_name, self.key, *args, &block)
    end
  end
end

gist:

開発者のマシンを英語環境にしない理由はもはや一つもない

2011年も終りが近づいた昨今、日本の市場が今後どんどんシュリンクしていくことは、もはや子供でも知ってる周知の事実なわけです。

そういう時代にあって、開発者が日本語環境のマシンを使い続けることの意味は、よくよく考えたほうがいいと思うわけです。

個人的には、「世界中で使われるサービスを作りたい」といってる開発者のマシンをみて、キーボードがJISだったりOSが日本語だったりすると、もうその時点でかなりガクッときます。

とくに完全なる国際化が実現されているMacなら、キーボードさえBTOでUS仕様にしてしまえば、アメリカで売ってるMacと100%同じものになります。逆に言うと、アメリカで買ったMacでも、そのまま何の問題もなく日本語が使えるわけです。（実を言うと、現在アメリカのApple Storeでは、日本語JIS配列のキーボードを選ぶことさえできるようになっています）

買ったばかりのMacをはじめて起動するときに、使用言語を選んだのを、覚えていますか？世界中どこの国でも、その国の母国語を話すわけではない外国人が住んでいる、ということを配慮して、何語を話す人々にとっても平等なセットアップの手順になっているのでしょう。英語環境と日本語環境の切り替えも、再起動さえする必要がないぐらい簡単です。（設定を変えたらログオフ・ログインするだけでOK）

そして、

• 英語キーボード
• 英語OS
• 英語ブラウザ（実際には設定でen-usをja-jpの上に持っていくだけ）

という環境にしてしまえば、世界中の主要なソフトウェアを開発している人たちのほぼ全員と、何も違わない環境が手に入るのです。英語圏のユーザたちと同じ目線で、世界を見ることができるようになるのです。そのメリットははかりしれません。

では、そうすることのデメリットは何でしょうか。実は、誤解されていることがいくつかあります。

• 英語環境だと、日本語が表示できなくなるんじゃないの？
• 英語環境だと、日本語が入力できなくなるんじゃないの？

これらは、いずれも誤りです。世界中で販売されるすべてのMacには、世界中のあらゆる文字を表示できるだけのフォントが入っており、また世界中のあらゆる言語を入力するためのツールが入っています。これはiPhoneやiPadも同じです。

ぼくはもう15年以上、日本にいたときからMacを英語環境で使っていますが（注：OSX以前から漢字Talkではなく輸入版+language kitを使ってた）、何一つ不自由していません。強いて言えば、（今はもう使っていない）ATOKをインストールするときに、なぜか「日本語環境でないとインストールできません」と怒られるというクソ仕様があり、このためだけに、いったん日本語環境に切り替えてATOKをインストールして、すぐ英語環境に戻す、という手順を踏まなければいけない、ということがありました。それすらも面倒くさいので、現在はATOKを捨ててGoogle Japanese Inputを使うようになりました。それ以降、日本語環境に切り替えたことは、ほんとにただの一度もありません。

だから、実際的なデメリットは以下になるでしょう。

• 英語OSではメニューや設定が英語になるので使いにくい
• 英語ブラウザでは表示が英語になるので使いにくい
• キーの配置が違う、returnキーが小さくなるので押しにくい、controlキーが押しにくい
• 「英数キー」「かなキー」がなくなるので日本語入力の切り替えがしにくい

このなかで、前半２つは、デメリットではなくメリットと見るべきです。

• メニューや設定に出てくる英語は、基本的に非常に平易で、少量で、日々繰り返し見るものなので、すぐ慣れます
• あなたは開発者なのですから、メニューや設定にどういう英語表現を使うのが適切か、ということを学べるいい機会だと考えるべきです
• 英語圏のひとがサイトをみたときに、どういう風に見えているのかを、日常的に意識することができるようになります。ところどころ日本語が混じったりしている中途半端に英語化されたサイトが、いかに不格好で気持ち悪いかを体験することができます

逆に、「日本語環境でどう見えるか？」を確認するにはどうしたらいいでしょうか。ぼくは、そのためだけに、普段は使わないFirefoxで、日本語での表示を優先するようにしています。Preference -> Content -> Languagesと行って、Japanese [ja]をEnglish/United States [en-us]の上に持ってきています。（Firefox自体は英語版なのでメニューの表示は英語です）

ぼくはFirefoxでやっていますが、Chromeなど他ブラウザでも優先言語を変える設定なりExntensionがあるはずです。ポイントとしては、普段使うメインのブラウザは英語環境にしてしまう、ということです。

では、残り２つはどうでしょうか。

• キーの配置が違う、returnキーが小さくなるので押しにくい、controlキーが押しにくい
• 「英数キー」「かなキー」がなくなるので日本語入力の切り替えがしにくい

キーの配置の違いは、ぶっちゃけ言ってしまうと、慣れです。世界中のほとんどの開発者はJISキーボードを使ってないのだから、それが本質的・根源的な問題であるということはありえません。それに、実際的なメリットもあります：英語キーボードのほうが、スペースバーが大きくて押しやすい。JISキーボードは、FとJに左右の人差し指を置いたホームポジションで自然に使うには、ぎゅうぎゅうしすぎており、また、注意深く見るとわかりますが、左右のバランスが悪く、トラックパッドさえもやや左に寄せないと使いにくい配列になります。

Controlキーが押しにくいという問題は、プログラマーにとっては致命的なので、当然ながら解決方法があります。それもOS標準で。System Preference -> Keyboard -> Modifier Keys...と行くと、Caps LockをControlに設定することができます。この設定をやると、きちんとCaps Lockのランプがつかなくなるので、普通にControlキーとして使えるようになります。英語圏のプログラマーはほぼ全員が設定してるような気がします。

詳しくは、このあたりをどうぞ。 http://d.hatena.ne.jp/inouetakuya/20110726/1311640787

そして、「英数キー」「かなキー」これらは、なくてもcommand+spaceなどで入力言語を切り換えることができます。が、言語切り替えをステートレスにしてしまい、画面の右上をいちいち確認（あるいは実際に試し打ち）しなくても日本語or英語を打ち始められる、という意味では、これらのキーには一定の意義があります。

これを実現するには、KeyRemap4MacBook ( http://pqrs.org/macosx/keyremap4macbook/index.html )を使います。これで、「左のcommandキーを空打ちしたら、英数キーが押されたとみなす」「右のcommandキーを空打ちしたら、かなキーが押されたとみなす」というマッピングをすることができます。名前はfor MacBookとなっていますが、iMacでも普通に使えます。細かい気をつけるべき点としては、KeyRemap4MacBookを導入したらキーリピートの速度などをここで設定する必要があるということです。個人的には、[Key Repeat] Waitが83msというデフォルトは非常に遅いので、30msに変更してつかっています。

以上で、開発環境を完全に英語にしてしまうことに対するデメリットは、もうほとんどない、ということがおわかりいただけたのではないでしょうか。

さぁ、これを読んだら、今すぐMacを英語環境に切り替えましょう。

Hatena Blog Betaの不具合

• 招待状を受け取ったあと、登録するときにprivate / friends / publicの選択肢がグレーアウトされたまま選べなかった
• そして作成ボタンの直前にある説明がエスケープしすぎで≶なんちゃらみたいな文字になってた、てか本文はエンティティ筒抜けかい！ちゃんと&の処理しようよ
• ブログを英語設定にしてる（かつOSもブラウザも英語設定）のに日本語の広告が出る
• 右サイドバーの「Links / トップページ / ヘルプ / お知らせ」も日本語のまま

Hello World

こんにちは世界