Tech Talk Blog http://www.sixapart.jp/techtalk/ ja Copyright 2012 Tue, 07 Feb 2012 15:20:00 +0900 http://www.sixapart.com/movabletype/?v=5.12 http://blogs.law.harvard.edu/tech/rss パーティーや合コンのお供に、Movable Type こんにちわ、Movable Type 開発担当のたかやまです。
本日は、パーティーや合コン役立つMovable Typeというテーマです。

シックス・アパートでは、年内最終営業日には、夕方くらいから納会という名のパーティーを行っています。（当日の模様はこちら）
その時に活躍するのが特殊プロジェクトチーム「忘年会・納会：ゲーム大会実行委員会」です。
忘年会におけるゲーム大会実行委員会は、司会業と裏方業に専念しています。しかし、納会は自分たちでゲームの企画から考えて実行しているのです。

]]>と、前置きは置いておいて。実はここ2年は納会のゲーム大会にクイズ大会を開催しています。忘年会のクイズ大会用に早押しピンポンや、マルバツブザーなんて小道具も買っているので当然の帰結ですね。
ただ、普通に早押しクイズをやるだけじゃ面白くないとい事で、クイズの進行をMovable Typeで作ったサイトで行っているのです。どういう事か解らない？スクリーンショットをご覧ください。（見ても分からないかもですが...）

Fullscreen.jpg Fullscreen-1.jpg Fullscreen-2.jpg Fullscreen-3.jpg

2011年バージョンでは、2010年バージョンの欠点を修正することを目的として1から作り直すという事をやっています。（2010年バージョンのテンプレートをロストしたという噂も...）
2010年バージョンの欠点とは。

  1. 解答済みのステータスを管理していなかったために、画面をリロードすると全問選択可能となってしまった。
  2. JavaScriptの時々が時々おかしくなり、アニメーションなどが正常に動かなかった。
  3. そもそも、オペレータが酔っ払ってしまった（これは人災）

問題１．の解決としては、オープンした問題のステータスを保持すればいいという事で、簡単にLocal Storageを使う事にしました。

問題一覧がロードされたタイミングで、Local Storageから問題のステータス情報を取り出します。

var storage = localStorage;
var data = JSON.parse(storage.getItem("quiz-"));

document.ready:
if ( data ) {
  for(var idx in data){
    jQuery("#"+data[idx]).css('background', '#fff');
    jQuery("#"+data[idx]).unbind();
  }
}

OnClick:
if ( !data ) { data = new Array(); }
data.push( $id );
storage.setItem("quiz-", JSON.stringify( data ));

そして、問題をクリックしたタイミングでIDをPushしてしまえばOKじゃないですか。ばっちり解決です。

問題２．は、SlideUpなどのアニメーションの際にいろいろ細かい調整をしていたのですが、それをスッキリ書き直したら起こらなくなってました。
そして、最大の問題が 問題３．ですが、これはオペレータの永遠のテーマなので放っておきます。

2011年バージョンは、無駄にHTML5+CSS3で書いてみたのですが、今回書いていて一番ステキに思ったところをご紹介して今日のエントリーを締めくくりたいと思います。

2010年バージョンでは、3カラムレイアウトを組むのに当然ながら float を利用していたのですが、CSS3では display: box とすると3カラムのそれぞれの高さを一番長いものに合わせてくれて、簡単に3カラムレイアウトが作れるようになるっぽいです。（ベンダー独自実装しかまだ無いので...）

CSS:
#container {
  display: -moz-box;
  display: -webkit-box;
  width: 100%;
}
.genre-container {
  width: 33%;
  height: 100%;
  background: #FFFFF0;
}

HTML:
HTML:
<body class="main-index">

<div id="container">

<mt:TopLevelCategories>
<div class="genre-container">
<div class="genre"><p><mt:CategoryLabel></p></div>
<mt:Entries sort_by="field:point" sort_order="ascend">
<div class="point<mt:If tag="EntryDataAngel"> quiz-angel</mt:If><mt:If tag="EntryDataDevil"> quiz-devil</mt:If>" id="entry-<mt:EntryID>"><p><mt:QuizPoint /></p></div>
</mt:Entries>
</div>
</mt:TopLevelCategories>

</div>

簡単ですね。今回は使いませんでしたけど（使う場所ありませんでしたけど）

box-ordinal-group: 1;


とか書くと、HTML内の位置とは関係なく 見た目の順番を指定できるそうです.


まとめ：HTML5＆CSS3は面白いですね。


では、また次回。

]]> http://www.sixapart.jp/techtalk/2012/02/movable_type_with_party.html http://www.sixapart.jp/techtalk/2012/02/movable_type_with_party.html Tue, 07 Feb 2012 15:20:00 +0900 CoffeeScriptとスコープ こんにちは。MTエンジニアチームの澤田です。
PSVitaが発売されましたね。うっかり発売日にゲームショップに足を運んだら、うっかり在庫があったのでうっかり買ってしまいました。今は「かまいたちの夜」シリーズの最新作「真かまいたちの夜」に夢中です。

「かまいたちの夜」シリーズはサウンドノベルと呼ばれるゲームの代表的な作品です。サウンドノベルは基本的には画面で読む小説といった趣なのですが、時々主人公の行動を決める選択肢が登場し、その選択によって物語の展開や結末が大きく変わってしまうのが特徴です。正しい選択肢を選んで主人公が幸せになるような結末を迎えることがゲームの目的となります。

「かまいたちの夜」シリーズは特に物語展開の幅広さと緻密なフラグ管理が特徴で、物語の序盤の一見どちらでも良いような選択が、最後の最後になって大きく展開を左右する場合があります。完全クリアを目指す場合、ずっと前に選んだ関係なさそうな選択肢まで含めて検討し、正しい選択を選び直すという、恐ろしく根気のいる作業が必要となります。まあそれが楽しいんですけどね。

「真かまいたちの夜」を買う前は、CoffeeScriptに夢中でした。先日社内の勉強会で、JavaScript The Good Partsを見習ってCoffeeScriptの好きなところ嫌いなところをあげていく、という内容のミニトークをしたのですが、その際に一番問題と思われたのが、変数の宣言とスコープでした。

]]>CoffeeScriptはJavaScriptにトランスコンパイルされる言語です。JavaScriptにはレキシカル変数を宣言するvarキーワードがありますが、CoffeeScriptはこれを隠蔽しています。変数の宣言文と代入文に違いは無く、変数が最初に左辺値として評価される箇所が自動的に宣言とみなされます。

CoffeeScript JavaScript 
foo = 42
 
var foo;
foo = 42

この自動宣言は、関数スコープを考慮しません。関数の外側で既にその変数名が使用されていたら、外側の変数を参照したものと扱われます。　

CoffeeScript JavaScript 
foo = 42
( -> foo = 43 )()
console.log foo  # prints '43'!
  
var foo;

foo = 42;

(function() {
  return foo = 43;
})();

console.log(foo);

また、明示的にレキシカルスコープを宣言する構文はありません。var宣言はエラーになります。CoffeeScriptとして正しい書き方をする限り、外側のスコープで利用されている変数名を、より内側のスコープで別の目的に再利用する方法はありません。(いくつか抜け道はあります。)

これらのルールは、すこし問題があるように感じます。大きなファイルの最初の方で宣言した変数と同じ名前を、レキシカル変数のつもりで使ってしまった場合や、逆に外側のスコープの変数を参照するつもりでtypoしてしまった場合、きづきにくいバグを生む可能性があります。
Perlをメインの言語として使っているかたは、use strict;を書き忘れたような落ち着かない気持ちになるのではないでしょうか。use strict;の書き忘れはエンジニア生命に関わりますからね。

さらに--joinオプションを使った連結コンパイルでは、問題はより深刻になります。--joinオプションは複数のCoffeeScriptファイルを同じスコープ内でコンパイルする(複数のCoffeeScriptファイルを単純に連結したものがコンパイルされる)からです。

#some.coffee
somefunc = ->
  foo = 42 # ローカル変数

#other.coffee
otherfunc = ->
  foo = 43 # これもローカル変数

これを--joinオプション付きでコンパイルして使用。

$ coffee -c --join joined.js some.coffee other.coffee
$ cat ./joined.js
(function() {
  var otherfunc, somefunc;

  somefunc = function() {
    var foo;
    return foo = 42;
  };

  otherfunc = function() {
    var foo;
    return foo = 43;
  };

}).call(this);

そして、ずっと後になって、some.coffeeファイルのfoo変数を外に出したくなった。

#some.coffee
foo = 42
somefunc = ->
  dosomething foo

#other.coffee
otherfunc = ->
  foo = 43 # いつの間にかグローバル変数に!!


$ cat ./joined.js 
(function() {
  var foo, otherfunc, somefunc;

  foo = 42;

  somefunc = function() {
    return dosomething(foo);
  };

  otherfunc = function() {
    return foo = 43;
  };

}).call(this);

some.coffeeファイルに対して修正を行った事により、別ファイルのotherfunc関数に、グローバル変数に対して意図しない副作用が発生するという問題が発生してしまいました。このようなバグは、そもそも見つけ出す事が難しく、運良く問題に気づいたとしても、ずっと前に宣言した関係なさそうな変数名まで含めて検討し、正しい変数名をつけ直すという、恐ろしく根気のいる作業が必要となります。これはあまり楽しそうではありません。

このような変数宣言とスコープの振る舞いに関しては、当然CoffeScriptのBTSでも議論されています。以下のスレッドでは、Pythonのように変数のスコープはもっとも狭いものとして扱い、globalやouterのような宣言、あるいは特殊な代入演算子(:=)でスコープを変更するようなモデルが提案されています。

そして、CoffeeScriptの作者jashkenasはそれらの提案に対して強く反発しています。上記スレッドからjashkenasの発言をいくつか拾ってみます。邦訳はかなり超訳です。

(前略)

Making assignment and declaration two different "things" is a huge mistake. It leads to the unexpected global problem in JavaScript, makes your code more verbose, is a huge source of confusion for beginners who don't understand well what the difference is, and is completely unnecessary in a language. As an existence proof, Ruby gets along just fine without it.

変数の宣言と代入を別々の"事柄"に分けて考えるのは、大間違いだと思う。それはJavaScriptでは、予期せぬグローバルの問題を導き、みんなのコードを冗長にする。冗長さは違いのよくわかってない初心者にとっては混乱のもとだし、言語にとっても完全に不必要なものだ。その証拠として、Rubyはそれ無しでうまくやっている。

However, if you're not used to having a language without declarations, it seems scary, for the reasons outlined above: "what if someone uses my variable at the top of the file?". In reality, it's not a problem. Only the local variables in the current file can possibly be in scope, and well-factored code has very few variables in the top-level scope -- and they're all things like namespaces and class names, nothing that risks a clash.

とはいえ、今までの議論を見る限り、これまで変数宣言の無い言語を使った事の無い人にとっては、恐ろしいものに感じるようだね。"どこかの誰かが、僕の変数をファイルの先頭で勝手に使ったらいったいどうしたらいいんだい？"。実際のところ、これは問題にはならない。現在のファイルにローカルな変数だけがスコープにふくまれるわけだし、"well-factored"なコードは、トップレベルのスコープではほんの少しの変数しか使わない -- そしてそれらの変数はすべてネームスペースかクラス名だ。衝突の危険はない。

And if they do clash, shadowing the variable is the wrong answer. It completely prevents you from making use of the original value for the remainder of the current scope. Shadowing doesn't fit well in languages with closures-by-default ... if you've closed over that variable, then you should always be able to refer to it.

もし衝突が起こるとしても、変数の隠蔽(shadowing)は間違った解決法だ。スコープ内のその他のすべての変数に関して、オリジナルの値の利用を完全に塞いでしまう。隠蔽は、クロージャが標準(closures-by-default)な言語にはうまくマッチしない。その変数を閉じ込めているならば、常に参照出来るべきだ。

The real solution to this is to keep your top-level scopes clean, and be aware of what's in your lexical scope. If you're creating a variable that's actually a different thing, you should give it a different name.

本当の解決方法は、トップレベルを奇麗な状態に保つ事、そして、何がレキシカルスコープにあるのかを意識する事だ。実際に異なる物事に対して変数を作成するなら、それには異なる名前を付けるべきだろう。

(後略)

そして、それでも議論が収束しないと、次のような事を述べています。

(前略)

I'd like to persuade y'all that strict lexical scope is a defining feature of CoffeeScript -- a massive improvement over the manual var-tagging of variables, and similar in spirit to the notion of structured programming. ... Think of it as "structured variable naming".

僕はみんなに、"strict lexical scope"はCoffeeScriptをCoffeeScript足らしめているものだってことを納得してほしいんだ -- 変数への手動のvarタギングを乗り越える大きな前進であり、精神的には構造化プログラミングの概念とよく似たものだ。 ..."構造化変数命名法"と考えてほしい。

We all know that dynamic scope is bad, compared to lexical scope, because it makes it difficult to reason about the value of your variables. With dynamic scope, you can't determine the value of a variable by reading the surrounding source code, because the value depends entirely on the environment at the time the function is called. If variable shadowing is allowed and encouraged, you can't determine the value of a variable without tracking backwards in the source to the closest var variable, because the exact same identifier for a local variable can have completely different values in adjacent scopes. In all cases, when you want to shadow a variable, you can accomplish the same thing by simply choosing a more appropriate name. It's much easier to reason about your code if a local variable name has a single value within the entire lexical scope, and shadowing is forbidden.

僕らはみんな、ダイナミックスコープはレキシカルスコープに比べて悪いものだと知っている。なぜなら変数の値を推論する事が難しくなるから。ダイナミックスコープでは、変数の値が、関数が呼び出されるときの環境に完全に依存するため、ソースコードの一部を読んで値を決定する事が出来ない。もし変数の隠蔽が許され、奨められている場合、ソースコードの中で一番近いvar変数を探して読み戻る事無しには、変数の値を決定出来ない。なぜなら、ローカル変数が、全く同じ識別子をもつ隣接したスコープの変数と、全く異なる値を持つからだ。変数を隠蔽したくなるときには、いつでも同じ事を、単にもっと適切な名前を選択する事で達成出来る。もしローカル変数の名前がすべてのレキシカルスコープのなかでただ一つの値を持っていて、隠蔽が禁止されているならば、コードはもっと読みやすくなるんだ。

So it's a very deliberate choice for CoffeeScript to kill two birds with one stone -- simplifying the language by removing the "var" concept, and forbidding shadowed variables as the natural consequence.

こいつはCoffeeScriptにとって、まさに一石二鳥な、とても計画的な選択なんだ -- "var"を取り除いて言語をシンプルにし、かつ、自然な成り行きとして変数の隠蔽を禁止出来る。

This brings us to Dmitry's second point: It's still possible to shadow with parameter names, because of the nature of JS functions. I think that Trevor has the right idea here, we should be more strict about shadowing instead of less. It would be great to entertain tickets that either make parameter shadowing a syntax error, or a compile time warning. If we ever go down the road of having a coffee --warn, it should be one of the first rules.

これは、Dmitryの二つ目の論点にもつながっている: JSの関数の本来の動作によって、関数のパラメータを使うと変数の隠蔽は可能なままだ(訳注:なのでスコープのルールが言語内で統一されていない)という問題だ。これは、Trevorのアイデアが正しいと思う。僕らはもっと隠蔽について厳密になるべきだ。パラメータによる隠蔽をシンタックスエラーやコンパイル時の警告にするというのは、おおいに考慮する価値がある。いつかcoffeeコマンドに--warnオプションを追加する日が来たら、こいつは最初のルールにするべきだね。

(中略)

Strict lexical scope isn't going to change in CoffeeScript proper, but I encourage you add outer to your own dialect, or take a look at Coco, which includes two different kinds of variable assignment.

CoffeeScript自体でStrict lexical scopeを変更する予定はないけども、"outer"キーワードをあなたの方言に追加する事や、二種類の代入文を持つCoco(訳注:CoffeeScriptからフォークしたプロジェクト)に注目する事はお勧めするよ。

(後略)

このように、jashkenasはかなり強い姿勢で、現在のCoffeeScriptのスコープの仕組みが意図されたものである事を主張しています。おそらく、当面スコープの振る舞いが修正される事は無いでしょう。

jashkenasの主張は、Perlのstrictプラグマのような、変数宣言を必須とすることでプログラマをケアレスミスから守る、という考え方と真っ向から対立しているように思えます。CoffeeScriptで変数を利用するときに何が起こりうるのかを理解せずに、本番環境で利用すると、落とし穴に落ちそうです。とはいえ、CoffeeScript自体はとても魅力的な言語なので、変数スコープの問題にとらわれて敬遠してしまうのはもったいないと思います。うまく付き合う方法を見つけたいですね。

]]> http://www.sixapart.jp/techtalk/2012/01/coffeescript.html http://www.sixapart.jp/techtalk/2012/01/coffeescript.html Mon, 23 Jan 2012 11:05:00 +0900 検索評価やソーシャルメディアでシェアされるリンクのURLを統一するのに必要不可欠なcanonical属性とは こんにちは。Zenbackのプロダクトマネージャーの壽（ことぶき）です。
普段はZenback 公式ブログや、@zenbackあたりで発信しているのですが、今回はちょこっと技術的なお話をさせていただきたくて Tech Talk Blog にお邪魔いたしました。

Zenback ってどんなサービス？　そしてどんな仕組み？

さて、Zenback。これは弊社が開発しているブログパーツです。 ブログの各記事の下の方に設置するだけで、記事へのソーシャルメディアでの反応をまとめて表示したり、逆にソーシャルメディアにポストするボタンを表示できます。この記事の一番下にも表示されてます。

これらの機能はどれも「記事ページのURL」がキーになっています。

「記事ページのURL」とひもづいているツイートやはてなブックマークの反応を集めてきて表示しますし、ツイートする／はてブする／mixiチェックする／Google+1する／Facebook いいねするなどの各種ポスト機能ではその記事のタイトルとURLを各サービスに投げています。

]]>URLまわりで、こんな困ったことってありませんか？

とあるサイトからリンクで飛んできた記事ページのURL。その後ろに何か余計なパラメータが付いていたりします。

http://example.com/article.html?ref=rss

これって実際には、

http://example.com/article.html

と全く同じページ。

同じであるにもかかわらず、記事への反応（ツイートやブックマーク）が両者に別々についてしまうことはありませんか？これをほぼ防ぐことが出来るのが、canonical属性を使った指定です。

canonicalって何？

表示しているページの正統なURLを、検索エンジンや各種シェアサービスに教えてあげるための指定方法です。ちなみにcanonicalという英単語には、「正統な」という意味があります。

正しく指定することにより、wwwの有無や、http/httpsの違いや、パラメータの有無や、ちょっとURLが違うだけのスマフォ用ページや、他サイトに全文引用してあるだけのページがあっても、それぞれのページ内で正統なURLはこれ！と指定することが出来ます。これにより、それぞれが別個のページとみなされにくくなります。

どうやって使うの？

<head> タグ内に、以下のように1行追加します。

<link rel="canonical" href="http://example.com"/>

hrefの中の"http://example.com"は、各ページごとに異なります。

例えば、このページの場合、以下のようになります。

<link rel="canonical" href="http://www.sixapart.jp/techtalk/2012/01/canonical.html>

このように指定しておくことで、wwwが無いURLでアクセスされても、検索エンジンその他各種シェアサービスからは、http://www.sixapart.jp/techtalk/2012/01/canonical.html がこのページの正統なURLであるとみなされます。

ただし、canonicalでの指定を利用するかどうかはサービスによって異なります。ヤフー、グーグル、マイクロソフトの大手検索エンジン各社はcanonicalサポートを正式に表明していますし、Twitterの公式ツイートボタンの技術ドキュメントにもcanonicalを認識することが明記されています。サービスによってcanonicalの対応状況は異なりますが、個人的には、URLをキーに検索結果を表示したり、シェアしたりするサービスは全部対応してくれると良いなと思っています。

さてZenbackも、このたびcanonical属性でのURL指定に対応しました。各ページの <head> にrel="canonical"で指定されたURLがあれば、ZenbackはそれをページのURLと認識します。そして、URLに関連する情報を表示したり、そのURLをソーシャルメディアにポストする際に、canonicalで指定されたURLを実際のURLよりも優先して利用します。

どこに設置すればいいの？

検索評価の統一、シェアされるURLの統一のために、全てのページに最初から設置しておくことが望ましいと思います。忘れがちな場所も含めてリストアップしました。運営ポリシーにより、変わってくるかとは思いますが、設置場所の参考になれば幸いです。

  • トップページと各枝葉の全ての静的ページ
  • スマフォ用、ガラケー用、印刷専用ページなど
  • ECサイトなどでパラメータが違うだけで同じ商品を指しているような動的ページ
  • 外部サイトにて自サイト記事を全文引用しているページ

逆に設置しなくても良いページは、外部とシェアする必要がないクローズドなページです。

ogpでもcanonicalURLを指定出来ます

Facebookなどでは、OGP（The Open Graph protocol）の og:url で指定されたURLをcanonicalとみなします。rel="canonical"と同じURLを指定する箇所ですので、あわせて設定されると良いかと思います。

プレゼンテーション

この内容を、社内で発表したときのプレゼンテーションをEmbedします。ご参考まで。

全てのページにcanonicalを！

参考リンク

最後に、canonical属性について参考になったリンクをまとめました。

URLを正規化する、rel="canonical" 属性に関する 参考リンク集 [NAVER まとめ]
]]> http://www.sixapart.jp/techtalk/2012/01/canonical.html http://www.sixapart.jp/techtalk/2012/01/canonical.html Mon, 16 Jan 2012 13:50:37 +0900 Lekumo キャンペーンビルダーと Javascript フレームーク「Closure Tools」
  • Closure Library
  • Closure Compiler
  • Closure Template
    • の3つと、そして最近リリースされた
    • Closure Stylesheets
    から成ります。 開発の基本は、Closure Library にて提供されている部品群を組み合わせてコーディングしていくことになります。開発は、Closure Library さえあれば進めて行くことができます。この為、Closure Library こそが Closure Tools の核と思われそうですが、実は Closure Compiler 無しでは、Closure Library は成り立たないと言っても過言ではありません。 というのも、Closure Library で提供されている部品群はあらゆる用途に対応する為膨大であり、実際には使用しないものまで大量に含まれていたりします。例を挙げると、Lekumo キャンペーンビルダーには「ソーシャルメディア統計」という画面がありますが、この画面では、日付の選択に goog.ui.InputDatePicker という UI を使用しています。 lcb_sms_ui.png この UI では国際化の為、goog.i18n.DateTimeSymbols というモジュールが必須になるのですが、この goog.i18n.DateTimeSymbols が曲者で、めちゃめちゃサイズがでかいのです。ざっと見ただけでも、 
    goog.provide('goog.i18n.DateTimeSymbols');
goog.provide('goog.i18n.DateTimeSymbols_ar');
goog.provide('goog.i18n.DateTimeSymbols_bg');
goog.provide('goog.i18n.DateTimeSymbols_bn');
goog.provide('goog.i18n.DateTimeSymbols_ca');
goog.provide('goog.i18n.DateTimeSymbols_cs');
goog.provide('goog.i18n.DateTimeSymbols_da');
goog.provide('goog.i18n.DateTimeSymbols_de');
goog.provide('goog.i18n.DateTimeSymbols_de_AT');
goog.provide('goog.i18n.DateTimeSymbols_de_CH');
goog.provide('goog.i18n.DateTimeSymbols_el');
goog.provide('goog.i18n.DateTimeSymbols_en');
goog.provide('goog.i18n.DateTimeSymbols_en_AU');
goog.provide('goog.i18n.DateTimeSymbols_en_GB');
goog.provide('goog.i18n.DateTimeSymbols_en_IE');
goog.provide('goog.i18n.DateTimeSymbols_en_IN');
goog.provide('goog.i18n.DateTimeSymbols_en_ISO');
goog.provide('goog.i18n.DateTimeSymbols_en_SG');
goog.provide('goog.i18n.DateTimeSymbols_en_US');
goog.provide('goog.i18n.DateTimeSymbols_en_ZA');
goog.provide('goog.i18n.DateTimeSymbols_es');
goog.provide('goog.i18n.DateTimeSymbols_et');
goog.provide('goog.i18n.DateTimeSymbols_eu');
goog.provide('goog.i18n.DateTimeSymbols_fa');
goog.provide('goog.i18n.DateTimeSymbols_fi');
goog.provide('goog.i18n.DateTimeSymbols_fil');
goog.provide('goog.i18n.DateTimeSymbols_fr');
goog.provide('goog.i18n.DateTimeSymbols_fr_CA');
goog.provide('goog.i18n.DateTimeSymbols_gl');
goog.provide('goog.i18n.DateTimeSymbols_gsw');
goog.provide('goog.i18n.DateTimeSymbols_gu');
goog.provide('goog.i18n.DateTimeSymbols_he');
goog.provide('goog.i18n.DateTimeSymbols_hi');
goog.provide('goog.i18n.DateTimeSymbols_hr');
goog.provide('goog.i18n.DateTimeSymbols_hu');
goog.provide('goog.i18n.DateTimeSymbols_id');
goog.provide('goog.i18n.DateTimeSymbols_in');
goog.provide('goog.i18n.DateTimeSymbols_is');
goog.provide('goog.i18n.DateTimeSymbols_it');
goog.provide('goog.i18n.DateTimeSymbols_iw');
goog.provide('goog.i18n.DateTimeSymbols_ja');
goog.provide('goog.i18n.DateTimeSymbols_kn');
goog.provide('goog.i18n.DateTimeSymbols_ko');
goog.provide('goog.i18n.DateTimeSymbols_ln');
goog.provide('goog.i18n.DateTimeSymbols_lt');
goog.provide('goog.i18n.DateTimeSymbols_lv');
goog.provide('goog.i18n.DateTimeSymbols_ml');
goog.provide('goog.i18n.DateTimeSymbols_mo');
goog.provide('goog.i18n.DateTimeSymbols_mr');
goog.provide('goog.i18n.DateTimeSymbols_ms');
goog.provide('goog.i18n.DateTimeSymbols_mt');
goog.provide('goog.i18n.DateTimeSymbols_nl');
goog.provide('goog.i18n.DateTimeSymbols_no');
goog.provide('goog.i18n.DateTimeSymbols_or');
goog.provide('goog.i18n.DateTimeSymbols_pl');
goog.provide('goog.i18n.DateTimeSymbols_pt');
goog.provide('goog.i18n.DateTimeSymbols_pt_BR');
goog.provide('goog.i18n.DateTimeSymbols_pt_PT');
goog.provide('goog.i18n.DateTimeSymbols_ro');
goog.provide('goog.i18n.DateTimeSymbols_ru');
goog.provide('goog.i18n.DateTimeSymbols_sk');
goog.provide('goog.i18n.DateTimeSymbols_sl');
goog.provide('goog.i18n.DateTimeSymbols_sq');
goog.provide('goog.i18n.DateTimeSymbols_sr');
goog.provide('goog.i18n.DateTimeSymbols_sv');
goog.provide('goog.i18n.DateTimeSymbols_ta');
goog.provide('goog.i18n.DateTimeSymbols_te');
goog.provide('goog.i18n.DateTimeSymbols_th');
goog.provide('goog.i18n.DateTimeSymbols_tl');
goog.provide('goog.i18n.DateTimeSymbols_tr');
goog.provide('goog.i18n.DateTimeSymbols_uk');
goog.provide('goog.i18n.DateTimeSymbols_ur');
goog.provide('goog.i18n.DateTimeSymbols_vi');
goog.provide('goog.i18n.DateTimeSymbols_zh');
goog.provide('goog.i18n.DateTimeSymbols_zh_CN');
goog.provide('goog.i18n.DateTimeSymbols_zh_HK');
goog.provide('goog.i18n.DateTimeSymbols_zh_TW');
    と、これだけの数の言語がサポートされており、各言語の日付の名称やフォーマットがそれぞれ入っているわけです。この画面で必要となる Library を単純に Combine（結合）すると... 
    $ ls -l statistics.js
-rw-rw-r-- 1 shazama shazama 2343578 Nov 24 13:54 statistics.js
    なんと、2MB を超える巨大なファイルになってしまいます。使いたいのは日本語の部分だけなのに使ってない言語までたんまり読み込まれてしまう為です。 これを解決してくれるのが、Closure Compiler です。Closure Compiler は、単にシンボルの短縮や不要な改行や空白を削除するだけでなく、不要な Function の削除までしてくれます。その為には、ADVANCED_OPTIMIZATIONS というオプション付きで Compile する必要があるのですが、Closure Library と Closure Compiler を組み合わせて使う場合、このオプションは必須だと思った方が良いです。コードの書き方に多少制約が出てきますが、その手間をかけるだけの価値はあります。 試しに、先ほどの JS ファイルを Compile してみます。Compile には、 
    python closurebuilder.py
--root=/closure/root
sixapart.app.Statistics
-o compiled
--output_file=/compiled/statistics.js
--compiler_jar=compiler.jar
-f "--compilation_level=ADVANCED_OPTIMIZATIONS"
-f "--define=goog.DEBUG=false"
    というような呪文を唱えます。結果、 
    $ ls -l statistics.js
-rw-rw-r-- 1 shazama shazama 119306 Nov 22 16:41 statistics.js
    単に Combine しただけでは 2MB だったものが、116KB、約20分の1になってしまいました。ここでは、中でも最も極端な例を挙げましたが、他の画面の Javascript ファイルについても顕著にサイズダウンしています。 ネットを検索してみると、ADVANCED_OPTIMIZATIONS には制約があるので、SIMPLE_OPTIMIZATIONS で Compile されているケースが見られます。しかし、SIMPLE_OPTIMIZATIONS では Closure Library の真価は発揮できません。Closure Library は ADVANCED_OPTIMIZATIONS で無駄をそぎ落とすことを前提に、あのような巨大なサイズになっていると考えられるからです。Closure Library は Closure Compiler を併せて使うならば、是非とも制約をクリアして ADVANCED_OPTIMIZATIONS で Compile するべきです。 ADVANCED_OPTIMIZATIONS におけるコーディングの制約については、以下の記事が参考になります。私も参考にさせて頂きました。 さて、上記で挙げた Closure Tools を構成する要素のうち、Library と Compiler には触れましたが Template と Stylesheets について触れていません。実はこの二つについては、私もまだあまり触っていません。いずれはここで何か書けるくらいには使ってみたいと思います。]]>     http://www.sixapart.jp/techtalk/2012/01/lekumo_campain_builder_closure_tools.html http://www.sixapart.jp/techtalk/2012/01/lekumo_campain_builder_closure_tools.html Fri, 06 Jan 2012 11:03:00 +0900     Movable Typeの開発 続編（5年ぶり） 3年ぶりのこんにちわ、Movable Type 開発チームのたかやまです。

    「Movable Type の開発」というタイトルで記事が公開されてから5年。あれから世の中も変化してオープンでソーシャルになってきました。Movable Type の開発もオープンでソーシャルな方向に変化しています。そこで、Tech Talk Blog 再開記念として、Movable Typeの開発チームの生態を改めてさらしてみようと思います。

    現在、Movable Type の開発は日本国内にいるチームによって「製品企画」「開発」「QA」「営業・広報・マーケティング」が行われています。また、外部リソースとして、米国内のサポート業務と英語のチェックを行っているチームと、ヨーロッパ言語のローカライズを行うチームがいます。
    国内の開発チームも日本人だけではなく、イスラエルからやってきたShmuel Fombergさんがいます。何気に国際色豊かな開発チームなのです。

    Octocatさて、5年で変わったのは体制だけではありません。コードの管理方法も変わっています。
    2010年までは、code.sixapart.com のSubversionを利用していましたが、2011年からは、Git を使うようにしました。併せてサーバーも github に移動しました。理由としては「流行っているし便利だから。」という点も大きいのですが、自社サーバ上でのSubversionでの公開よりもより多くのフィードバックが受けられるという点がメリットであると思ったからです。（Pull Requestやコミットのレビューをサイト上で行える事など）
    PerlやPHP、JavaScriptを書ける方は 、機能要望やバグレポートをPull Requestで送って頂けると中の人が泣いて喜びます。

    Jenkins Logo

    今日のソフトウェア開発において自動化というのは欠かせない要素になっていると思います。Movable Type の開発においても色々な事を自動化していますが、そこで活躍中なのが Jenkins さんです。現在は、t/ のユニットテストをコミット時に実行したり、github レポジトリのバックアップ、ナイトリービルドの作成などを行っています。Jenkins 採用の決め手は、既存のcron ジョブやバッチファイルの実行監視も行える点でした。あ、ロゴの名執事っぽさも決め手です。

    変わっていない部分もあります。たとえば、コミットログをIRC (#movabletype #movabletype-ja) に流したり、メーリングリストの運用などは当時と変わっていません。

    こんなMovable Type 開発チームが生み出す Movable Type を今後ともよろしくお願いします。

    ]]>     http://www.sixapart.jp/techtalk/2011/12/movable_type.html http://www.sixapart.jp/techtalk/2011/12/movable_type.html Tue, 20 Dec 2011 11:00:00 +0900     Tech Talk Blog をリスタートします 2006年8月にスタートした、この Tech Talk Blog を再開します。 忙しさを理由に徐々に疎遠になっていってしまいました。このブログもそうですし、通称「エンジニア天国」と呼ばれる社内勉強会も過疎化しました。 でも徐々にエンジニア天国が復活して定期的に開催されるようになったの受けて、いよいよ Tech Talk Blog の再開へとたどり着きました。 写真 (1).JPG エンジニア天国は毎週木曜日（少し前までは毎週金曜日でした）夕方18時に社内のエンジニアが集まります。各プロダクトの状況をシェアした後に、年功序列で順序付けされた選ばれしエンジニアが5分以上のトークをします。その後は飛び入りトークを含む雑談をしたりします。 「担当のエンジニアが当日のトークをブログに書いたら割と定期的に更新できるね」ってことになりまして、Tech Talk Blog の再開になりました。 選ばれしエンジニアのトークについては「5分以上を話す」という制約以外は自由です。毎週月曜には私がリマインダーしてあげるし、月に1度発表するかどうかだし、なんかはネタはあるでしょう。 もしネタがなかったら、私がインタビュアーで選ばれしエンジニアがゲストのトーク番組が公開される予定です。トーク番組なんてそれはそれで面白い企画だと思ったのですが、みんなには罰ゲームと感じているようです。 肩肘張らずに気軽にやるつもりです。今後の展開について暖かく見守っていただけると幸いです。 今後ともご愛顧のほどよろしくお願いします。 ]]> http://www.sixapart.jp/techtalk/2011/12/tech_talk_blog_restart.html http://www.sixapart.jp/techtalk/2011/12/tech_talk_blog_restart.html Wed, 14 Dec 2011 15:50:00 +0900 Six Apart Tokyo Hack-a-thon Vol. 4 のお知らせ 四半期に一度は開催する予定だったハッカソンですが、第3四半期分もやらないまますでに過ぎてしまいました。すみません。今回も、前回同様金曜日の夕方から夜にかけて行いたいと思います。お仕事帰りにぜひお立ち寄りください。

    今回も、プラグイン開発、テンプレートデザインはもちろん、Movable Typeに関連したコーディングやデザインのネタであればどんなものでも構いません。また、1日で一通り終わらせられるようものではないが、開発中のネタで質問したいことがある、ある課題を実現する方法について他の開発者やデザイナの意見を聞きたい、などの目的でも歓迎です。

    これからMovable Type 4でプラグインを書いてみたい方も歓迎します。プラグインのAPIの使い方がよくわからない、既存のプラグインがMovable Type 4で動作しないなど、Movable Typeの開発者に直接質問する、または突っ込みを入れるチャンスです。

    ]]>

    記

    議題
    Movable Type 4に関連するプログラミング、テンプレート開発、利用法に関する質問会など
    日時
    2008年11月14日金曜日 17時開場、22時頃終了
    会場
    シックス・アパート株式会社（地図）
    会費
    無料
    募集人数
    会議室に入れるだけ（20名くらい？）
    持ち物
    ご自分のPCとハッカー魂
    その他
    軽食と飲み物を（簡単ながら）用意する予定です。無線LANによるインターネット接続も用意します。

    お申込み方法

    大体の人数を把握したいので、こちらのWikiページにログインしてやりたいアイデアとお名前を投稿してください。Wikiの使い方がわからない方は、このブログ記事にコメントしていただいても構いません（Wikiに転記させていただきます）。なお、当日は入退場自由です。

    遠方で来られないが質問がある、またはリモートからハッカソンに参加したい方のために、irc.freenode.netの#movabletype-jaを活用します。どこまで何ができるか未定ですが、ご要望もWikiまたはコメントでお寄せください。

    ご注意

    ハッカソンはセミナーやカンファレンスのようなものではありません。ある種のお題に興味のあるプログラマやテンプレートデザイナが集って、それぞれにそれぞれのプログラムやテンプレートを書きながら、なんとなく交流するイベントです。セッションや講演などは特に予定していませんので、ご了承ください。

    ]]>     http://www.sixapart.jp/techtalk/2008/10/sakk_tokyo_hack-a-thon_4.html http://www.sixapart.jp/techtalk/2008/10/sakk_tokyo_hack-a-thon_4.html Mon, 27 Oct 2008 09:00:00 +0900     Six Apart Tokyo Hack-a-thon Vol. 3 のお知らせ 四半期に一度は開催する予定だったハッカソンですが、第2四半期をすでに過ぎてしまいました。すみません。今回は、金曜日の夕方から夜にかけて行いたいと思います。これまでの2度とも週末開催だったので来られなかった方も、お仕事帰りにぜひお立ち寄りください。

    今回も、プラグイン開発、テンプレートデザインはもちろん、Movable Typeに関連したコーディングやデザインのネタであればどんなものでも構いません。また、1日で一通り終わらせられるようものではないが、開発中のネタで質問したいことがある、ある課題を実現する方法について他の開発者やデザイナの意見を聞きたい、などの目的でも歓迎です。

    これからMovable Type 4でプラグインを書いてみたい方も歓迎します。プラグインのAPIの使い方がよくわからない、既存のプラグインがMovable Type 4で動作しないなど、Movable Typeの開発者に直接質問する、または突っ込みを入れるチャンスです。

    ]]>

    記

    議題
    Movable Type 4に関連するプログラミング、テンプレート開発、利用法に関する質問会など
    日時
    2008年7月11日金曜日 17時開場、22時頃終了
    会場
    シックス・アパート株式会社（地図）
    会費
    無料
    募集人数
    会議室に入れるだけ（20名くらい？）
    持ち物
    ご自分のPCとハッカー魂
    その他
    軽食と飲み物を（簡単ながら）用意する予定です。無線LANによるインターネット接続も用意します。

    お申込み方法

    大体の人数を把握したいので、こちらのWikiページにログインしてやりたいアイデアとお名前を投稿してください。Wikiの使い方がわからない方は、このブログ記事にコメントしていただいても構いません（Wikiに転記させていただきます）。なお、当日は入退場自由です。

    遠方で来られないが質問がある、またはリモートからハッカソンに参加したい方のために、irc.freenode.netの#movabletype-jaを活用するほか、ustream.tvを利用した中継、Skypeによる電話会議などを検討しています。どこまで何ができるか未定ですが、ご要望もWikiまたはコメントでお寄せください。

    ご注意

    ハッカソンはセミナーやカンファレンスのようなものではありません。ある種のお題に興味のあるプログラマやテンプレートデザイナが集って、それぞれにそれぞれのプログラムやテンプレートを書きながら、なんとなく交流するイベントです。セッションや講演などは特に予定していませんので、ご了承ください。

    ]]>     http://www.sixapart.jp/techtalk/2008/07/six_apart_tokyo_hackathon_vol.html http://www.sixapart.jp/techtalk/2008/07/six_apart_tokyo_hackathon_vol.html Thu, 03 Jul 2008 10:45:23 +0900     Watirでテスト自動化の話 - インストール編 こんにちは、TypePadのQAを担当している山口です。今回はWatirを使ったテストの自動化の話の第二弾として、watirのインストールについて話をしたいと思います。

    ]]>はじめに

    私はwatir以外ではrubyを使いません。そのため私のrubyの知識は「watirを使うために必要な最小限の知識」ということを前提に読んでいただければと思います。ここで書かれた方法よりも良い方法もあると思います。しかし、ここではそれを追求しません。重要なのは、深く洗練されたrubyの知識ではなく、テストを自動化するために必要十分な知識であるからです（とはいえ、より良い方法があればぜひコメントをください！！）。

    Rubyのインストール

    Rubyがインストールされていない場合は、まずRubyをインストールします。WindowsにRubyをインストールするには、One-Click Ruby Installer for Windowsを利用すると簡便です。

    Rubyのいくつかのバージョンでは、Watirがうまく動作しないそうです。watirのサイトでは「1.8.5-24」か「1.8.6-26 final」以降のバージョンを推奨しています。

    watirのインストール

    コマンドプロンプトを開いて、下記のように入力して実行します。 

    gem update --system 
gem install watir

    1行目のコマンドでは、gemのアップデートをしています。watirの最新バージョンをインストールするには、gemのアップデートが必要です。

    2行目のコマンドでwatirのインストールが開始します。

    また、私はWindows XPを利用していますが、Vistaを利用の場合は「windows-pr」というものが必要なのだそうです（参照）。Vistaを利用されている方は、一緒に「windows-pr」をインストールしておくと良いでしょう。 

    gem install windows-pr

    動作確認

    irb（interactive ruby）で実行してみて、動作するかを確認してみます。irbは簡単にRubyを実行するためのツールでとても便利です。コマンドプロンプトを開いて、下記のように入力します。

    irb

    これでirbで起動しました。さらに下記のように記入していきます。 

    require "watir"
ie = Watir::IE.new
ie.goto("http://memolog.org/")

    watirが問題なくインストールされていれば、IEを自動的に起動して、http://memolog.orgに移動します。確認はこの程度で問題ないとは思いますが、より詳細のテストをされたい場合はRun the Watir Unit Testsのページを参照してください。

    参考サイト

    ]]>     http://www.sixapart.jp/techtalk/2008/06/watir_1.html http://www.sixapart.jp/techtalk/2008/06/watir_1.html Fri, 27 Jun 2008 12:25:50 +0900     Watirを使ってテストを自動化しようの話 こんにちは、TypePadのQAを担当している山口です。今回はWatirを使ったテストの自動化の話を少ししたいと思います。

    ]]>Watir = Web Application Test In Ruby

    WatirはRuby上で動作するウェブアプリケーション向けのテスト自動化ツールです。「Web Application Testing in Ruby」の頭字語で「ウォーター（water）」と発音します。

    Watirはこんな風に使います。

    require "watir"
ie = Watir::IE.new
ie.goto("http://memolog.org/")

    といった風に使います。Watirに組み込まれているメソッドを利用するだけで簡単にIEを操作することができます。この例では、IEを自動的に起動して、http://memolog.org に移動します。

    Watir vs Selenium

    WatirとSeleniumの違いはその動かし方にあります。SeleniumはJavascriptをベースにブラウザを操作するため、Javascriptが有効なブラウザなら基本的に動作するという利点があります。ただし、Javascriptで動かすゆえに、cross-site scripting の制限があり、テストするアプリケーションと同じサーバーに、Seleniumをインストールする必要があります。

    WatirはWin32OLEというライブラリを使って、IEそのものを操作するため、サーバーに何かをインストールする必要はありません。ただしWin32OLEを使うという性格上、Windows IE用という性格が色濃い印象があります。FirefoxやSafari用のWatirも用意はされていますが、たとえばFirefox版のWatirでは日本語入力がうまく利用できないなど、各ブラウザの対応状況はまちまちです。

    こうした点を考えると、複数のウェブサービスをまたがるようなテストを自動化したい場合はWatir、複数のブラウザ・プラットフォームでテストしたい場合はSeleniumを利用する、という切り分け方ができるように思います。重要なのは「どんなツールを使うか」ではなくて「そのツールで何をするか」です。TypePadを例にすると、複数のASPサービスで動作をテストする必要があることや、USでの実績があること、検証環境の都合、個人的な趣味など、いくつかの点を考慮して、Watirの方を採用しました。

    参考サイト

    ]]>     http://www.sixapart.jp/techtalk/2008/06/watir.html http://www.sixapart.jp/techtalk/2008/06/watir.html Wed, 11 Jun 2008 20:55:03 +0900     YAPC::Asia 2008 に行ってきました yapc_logo.png 15（木）は吉松の Hacking Movable Type Open Source、 16（金）は酒井の OpenSource TypePad Mobile と宮川の 20 10 modules I haven't yet talked about のセッションがありました。プレゼンテーションがアップロードされていますので、それぞれのリンクからご覧ください。いずれ動画もアップロードされると思いますが、まずはスライドをお楽しみください。 15（木）の懇親会では、ジョブフェアということで弊社の PR タイムをいただきました。口頭でお伝えしました URL は Six Apart - 人材募集 です。 また、司会の方から「40才までに退職したいのですが。。。」という質問をいただきました。（笑）（写真）さすが Perl ハッカーの視点はユニークです。私からは「65才定年まで頑張っていただきたい」「40才までブログをしてみたらどうか？」ということを回答しました。月並みな回答で申し訳ありませんでした。。。 （また現在弊社では人材募集をしております。Six Apart - 人材募集 をご覧いただき興味のある職種にご応募ください。） 私はスタッフとして参加しました。主な役割としましては、14（水）は会場セッティング、受付関連、ノベルティ関連の作業をしました。15（木）は 西8号館 E棟 10F 大会議室（通称：DeNA room）のタイムキーパーを終日行いました。16（金）は午後からメイン会場の講堂にて司会を担当させていただきました。そして期間中はとても忙しかったのですが、たくさんの方々にご協力いただいたりお声がけいただいたりしたことが本当に励みになりました。ありがとうございました。 世界最大の YAPC ということで、Perl の生みの親である Larry Wall をはじめ Perl の世界で著名なハッカーたちも多く訪れて、ここが日本であることを忘れてしまう瞬間もあり、他では類を見ない刺激的なイベントだったと思います。 来年もまた YAPC::Asia は開催されると思います。（来年は京都という噂もありますが。）今回参加することができなかった皆さんも来年もぜひご参加ください。 また来年に YAPC::Asia でお会いしましょう！]]> http://www.sixapart.jp/techtalk/2008/05/yapcasia_2008_1.html http://www.sixapart.jp/techtalk/2008/05/yapcasia_2008_1.html Sat, 17 May 2008 13:05:23 +0900 YAPC::Asia 2008 開催！ シックス・アパートで TypePad の開発を担当しております、重田です。

    いよいよ YAPC::Asia の季節がやってきました。

    今年はシックス・アパートからは次のメンバがセッションを担当します。

    宮川達彦
    吉松史彰
    酒井宏

    今回の会場は東京都目黒区にあります東京工業大学大岡山キャンパスで行われます。トラック数も2から3に増え、去年よりも規模が大きくなっております。また日程も5/14（前夜祭）, 5/15, 5/16 と3日間に渡り開催されます。きっと盛り上がることでしょう。

    ところで、今回の会場の各部屋には名前が付けられています。そして、百年記念館 2F 第一会議室 は ArcheType Room と名付けられました。ArcheType というのは Six Apart の プロダクトのプラットフォームの名称です。弊社のプロダクトの Vox は ArcheType の上に実装されています。シックス・アパートの豆知識の一つとして覚えていただけると幸いです。

    私は YAPC::Asia 2008 のスタッフとして会場におります。皆様にお会いできるのを楽しみにしております。

    YAPC::Asia 2008

    ]]>     http://www.sixapart.jp/techtalk/2008/05/yapcasia_2008.html http://www.sixapart.jp/techtalk/2008/05/yapcasia_2008.html Wed, 14 May 2008 00:00:00 +0900     Movable Type Hack-a-thon またやります 決してハッカソン告知および報告ブログではないのですが、エンジニアが忙しくてネタを書く暇がないので許してください。

    1270763791_4772b6851c_m.jpg8月にBrad Choate来日を記念して行ったハッカソンが大変好評だったので、またやろうと思います。今回も、プラグイン開発、テンプレートデザインはもちろん、Movable Typeに関連したコーディングやデザインのネタであればどんなものでも構いません。また、1日で一通り終わらせられるようものではないが、開発中のネタで質問したいことがある、ある課題を実現する方法について他の開発者やデザイナの意見を聞きたい、などの目的でも歓迎です。

    これからMovable Type 4でプラグインを書いてみたい方を歓迎します。プラグインのAPIの使い方がよくわからない、既存のプラグインがMovable Type 4で動作しないなど、Movable Typeの開発者に直接質問する、または突っ込みを入れるチャンスです。

    ]]>

    記

    議題
    Movable Type 4に関連するプログラミング、テンプレート開発、利用法に関する質問会など
    日時
    2008年1月26日土曜日 10時開場、18時頃終了
    会場
    シックス・アパート株式会社（地図）
    会費
    無料
    募集人数
    会議室に入れるだけ（20名くらい？）
    持ち物
    ご自分のPCとハッカー魂
    その他
    昼食、スナック、飲み物を（簡単ながら）こちらで用意する予定です。無線LANによるインターネット接続も用意します。

    お申込み方法

    大体の人数を把握したいので、こちらのWikiページにログインしてやりたいアイデアとお名前を投稿してください。Wikiの使い方がわからない方は、このブログ記事にコメントしていただいても構いません（Wikiに転記させていただきます）。なお、当日は入退場自由です。

    遠方で来られないが質問がある、またはリモートからハッカソンに参加したい方のために、irc.freenode.netの#movabletype-jaを活用するほか、ustream.tvを利用した中継、Skypeによる電話会議などを検討しています。どこまで何ができるか未定ですが、ご要望もWikiまたはコメントでお寄せください。

    ご注意

    ハッカソンはセミナーやカンファレンスのようなものではありません。ある種のお題に興味のあるプログラマやテンプレートデザイナが集って、それぞれにそれぞれのプログラムやテンプレートを書きながら、なんとなく交流するイベントです。セッションや講演などは特に予定していませんので、ご了承ください。

    前回の模様

    1270761801_45f0adbb18_m.jpg 1270761381_dd6d20ab1a_m.jpg 1271624912_5ab698ac42_m.jpg 1270760165_e27961ba78_m.jpg
    ]]>     http://www.sixapart.jp/techtalk/2007/12/mt_hack_a_thon_02.html http://www.sixapart.jp/techtalk/2007/12/mt_hack_a_thon_02.html Wed, 19 Dec 2007 17:20:12 +0900     Hack-a-thon やりました 8月25日土曜日、赤坂はシックス・アパート株式会社で、第1回 Movable Type 4 Hack-a-thonを開催しました。

    1270761801_45f0adbb18.jpg

    午前11時ごろ集合、なんとなくお題をホワイトボードに書き、なんとなくコーディング開始、おなかがすいてきたので12時過ぎごろ弁当を注文、その後も何となくコードを書きすすめ、午後5時からビール片手に成果の発表会をするというゆるい流れで進行しましたが、参加された皆さまからは一様に楽しかったというご感想をいただきました。

    ]]>また、当日はIRCの#movabletype-jaチャンネルで会話したり、ustream.tvを通じて様子を中継したりして、来られなかった方々にも雰囲気をお伝えするようにしてみました。

    Brad Choateも黙々とコードを書き続け、数年来アップデートしていなかったプラグインをすべてMT4対応にし、満足したようです。また、参加された方々の成果物を見ては小さな声で「cool」を連発していました（彼は大声でしゃべるタイプじゃないんです）。

    1270760165_e27961ba78.jpg

    ホストの僕らも楽しめたので、またぜひ開催したいと思います。

    ]]>     http://www.sixapart.jp/techtalk/2007/08/hackathon.html http://www.sixapart.jp/techtalk/2007/08/hackathon.html Fri, 31 Aug 2007 11:00:00 +0900     Movable Type 4 Hack-a-thon のお知らせ 8月24日にあのBrad Choateが来日します。8月25日は土曜日です。土曜日といえば、ハッカーが集ってハックする日と昔から決まっています。Movable Type界最強のハッカーが東京にいるのに、東京でハッカソンをしないわけにはいきません。 ハッカソンとは、プログラマが一堂に会して、黙々と、ときには見せ合ったり質問しあったりしながら、自分のしたいことについて自分のしたいようにプログラムを書くというイベントです。今回は、せっかくBrad Choateが東京にいるので、Movable Type 4に関連するお題でハックをしたい方に集まってほしいと思っています。PerlやPHPでのプラグイン開発ですでにアイデアやコードを持っている方はもちろん、テンプレートタグを使い倒して思い通りの出力を得たいデザイナの方や、これからMovable Type 4でプラグインを書いてみたい方を歓迎します。プラグインのAPIの使い方がよくわからない、既存のプラグインがMovable Type 4で動作しないなど、Movable Typeの開発者に直接質問する、または突っ込みを入れるチャンスです。日本中のMTハッカーにお集まりいただきたいと願っています。Brad Choateに聞きたいが、英語が....という場合はシックス・アパートのメンバーがなんとかします。 記
    議題
    Movable Type 4に関連するプログラミング、テンプレート開発、利用法に関する質問会など
    日時
    2007年8月25日土曜日 11時開場、18時頃終了
    会場
    シックス・アパート株式会社（地図）
    会費
    無料
    募集人数
    会議室に入れるだけ（20名くらい？）
    持ち物
    ご自分のPCとハッカー魂
    お申込み方法 大体の人数を把握したいので、一応こちらの申込フォームからお願いします。当日は入退場自由です。 遠方で来られないが質問がある、またはリモートからハッカソンに参加したい方のために、irc.freenode.netの#movabletype-jaを活用するほか、テレビ会議システムやSkypeなどの仕組みを運用できるように検討しています。どこまで何ができるか未定ですが、ご要望をコメントでお寄せください。

    ご注意

    ハッカソンはセミナーやカンファレンスのようなものではありません。ある種のお題に興味のあるプログラマが集って、それぞれにそれぞれのプログラムを書きながら、なんとなく交流するイベントです。セッションや講演などは特に予定していませんので、ご了承ください。]]>     http://www.sixapart.jp/techtalk/2007/07/movable_type_4_hackathon.html http://www.sixapart.jp/techtalk/2007/07/movable_type_4_hackathon.html Thu, 12 Jul 2007 15:00:00 +0900