クラデュラの戦いまたは作戦戦争マグネット

Sanya ingspree 、Sergey Joes 、Roma rofhとともにClojure Cup 2013に参加しました。 おそらく、あなたはカットを見たかもしれませんし、kloskurscriptとリアクティブプログラミングについてのサニによる完全なプレゼンテーションを見たかもしれません。 そこで、これらの技術を試してみる機会が生まれました。

競争の主題は、ClojureまたはClojureScriptを使用して48時間以内に何かを提出することです。 さまざまなオプションの中で、特に既存のアプリケーションはすべて、Flashで書かれたインターフェース、さらに悪いことにSilverlight、または他の方法で娯楽を台無しにするインターフェースによって破壊されるため、ブラウザーのRiskを削減することが決定されました。 ウォーマグネットという良い名前をまとめて思いついた。

よく考えることなく、共通のコードを使用して、ClojureでサーバーとClojureScriptでクライアントの両方を作成することにしました。 4人の参加者のうち、少なくとも断面で書く経験があったのはSaniのみで、残りは4clojureで数十個の問題を解決した経験しかありませんでした 。

サーバー

サーバー側についてはあまり語りません。競争の全期間を通じて、サーバー側に一度も触れたことはありません。 データベースとして、2つのオプションから選択しました。

Clojureと「データベース」という単語を組み合わせるときに最初に頭に浮かぶのは、 Datomicです。 試してみるのは非常に興味深いですが、私たちの誰も、数時間もしないで、アトミックの経験がまったくありませんでした。また、プロジェクトの別のまったく新しいコンセプトがイニシアチブを台無しにし、成功しません。

そのため、ここ数年で最もファッショナブルなデータベースであるPostgreSQLを選択しました。

彼らはsi14のクローニーをワークピースとして使用しようとしましたが、私たちにとって難しすぎることがわかりました。 開始から半日後、彼らはクローンなしで新しいリポジトリを作成し、そこですべての作業を迅速に転送しました。

サーバーで使用したライブラリ、compojure、ring、korma、friend、cheshire、http-kitをリストします。 私の耳からは、船尾について不快なコメントを聞いたので、セルゲイはこの主題に関する他のすべての詳細を彼のブログで説明することを約束しました。

お客様

クライアントで使用するテクノロジーを選択します。 新しくできたcore.asyncがありますが、すべてのチュートリアルとマニュアルがデータを管理するのがいかに素晴らしいかを書いているという事実のために消え、 セレクターによってDOMにOMられます。 これは欠陥のある概念であるという意見がありますが、HTMLがインターフェースを構築する方法であることを受け入れなければなりません。 そして、セレクターに参加する場合、私たちはそれと同じように、その側で作業しています。インターフェースの構造が変更されたため、これらのセレクターを非常に慎重に退屈に見なければなりません。

ClojureScript用の格好良い反応ライブラリがあります- ジャベリンとホップロンの束です。 概念的な観点からは優れていますが、最適化には誰も関与していないため、非常に遅くなります。最も単純なTodoの例は 、デスクトップFirefoxでも顕著に遅くなります。 より複雑なアプリケーションの開発は、インターフェースの絶え間ないブレーキのために痛みに変わり、彼らは拒否することにしました。

最新のプロジェクトでは、SanyaとRomaはFacebook Reactをコーヒースクリプトと組み合わせて使用​​しており、彼らは本当に気に入っています。 彼らは彼を連れて行きました。 競争が始まる前の金曜日に、私はReactを少しずつ扱い始め、彼のためにバインディングライブラリを書き始めました。 最初のバージョンは、土曜日に午後1時に完成しました。

これは、Reactの外観です。

var HelloMessage = React.createClass({ displayName: 'HelloMessage', componentWillMount: function() { ... }, render: function() { return <div class="smth">{'Hello ' + this.props.name}</div>; } }); 

このXMLに似た構文は便利であり、javascriptで理解できます。 しかし、Clojureに統合することすら考えていませんでした。 しゃっくり構文に触発されて、このオプションを作成しました。

 (defr HelloMessage :component-will-mount (fn [] ...) [this props state] [:div.smth (str "Hello " (:name props))]) 

スクリプトとリアクションの交差点でいくつかの問題が発生しました。 たとえば、最初にClojureScript'ovyeデータ構造を状態として直接使用しようとしましたが、プロトタイプを転送せずに自分自身の内部での反応が浅いコピーを作成し、すべてが壊れました。 松葉杖として、彼らはstate.stateフィールドに私たちの状態を追加し始めました。

もちろん、ライブラリには隠されていますが、このため、状態を変更するために使用する必要があるassoc-in-stateヘルパーとassoc-in-stateヘルパーを作成する必要がありました。 React開発者の1人であるircのPete Huntは、同じ回避策を提案しました。 どういうわけか彼らはより適切な方法で友人を作ることができるでしょう。

一般に、クライアントでは、状態全体を1つのアトム、1つのデータ構造に格納し、必要な部分でさらに深くコントローラに転送します。 javascriptがあれば、ローカルの黙示録があったはずですが、インフラストラクチャ内のデータ構造は不安定であるため、問題はありませんでした。

サーバーとクライアント間の通信にjsonを使用しました。これは、クライアントのクールなednレイアウト形式のデシリアライズが約1桁遅くなり、階層構造を保存するcljsonが馬鹿げて理解しにくいように見えたためです。 そしてそれは間違いであることが判明しました！

その後、 :keyword 「キーワード」としてシリアル化され:keywordという事実に問題が生じました。 :keywordize-keys言うことができ:keywordize-keysから辞書からキーワードを作成します。 しかし、これはすべての問題を解決するわけではありません-すべてのキーワードが辞書のキーではなく、他のものを作成します-辞書のすべてのキーがキーワードではありませんでした。 数値では特に不快であることが判明しました-サーバー側のClojureはまったく実行できず(keyword 1) 、 nilを返し、ClojureScriptは:1を返しますが、特別なオプションで逆シリアル化されたjsonのキーには、数値ではなく文字列が含まれていることがわかります。 (keyword "1") 。

日曜日の後半から、私たちはこの問題で少なくとも1時間半を失い、今では松葉杖があちこちに置かれています。 最初はcljsonを使用する必要がありましたが、おそらく使用するためにやり直します。



このウィンドウのコードは次のとおりです。

 (defr Attack [C {:keys [attacker attacking defender defending attack!]} S] (let [[aname {:keys [coordinates]}] attacker [dname dmap] defender [xy] (xy-for-popover coordinates)] [:div.popover {:style {:display "block" :left x :top y}} [:div.popover-content [:table [:thead [:tr [:th (name aname)] [:th (name dname)]]] [:tbody [:tr [:td attacking] [:td defending]]]] [:div.btn-group [:button.btn.btn-warning {:on-click #(attack! 1 aname dname)} "Attack"] [:button.btn.btn-danger {:on-click #(attack! (dec attacking) aname dname)} "Blitz"]]]])) 

私の意見では、ここで起こることはすべて明確です。 そして、誰かがここの括弧の数に悩まされている場合、実際のHTMLにはさらに2倍あることに注意してください： <div></div> 、 [:div] 。 さらに、編集時にpareditが非常に役立ちます。括弧で混乱することはまったくありません。

一般的に、ClojureScriptとReactはumatの束であると感じました。使用することができ、使用する必要があります。

競争

Sanyaは2週間前にClojure Cupに参加することについて叫び、その後、彼らは私たちが何をするか、そしてどのテクノロジーを使用するかについて合意しました。 しかし、いつものように、自分自身や同志への約束にもかかわらず、そのような競技の準備をしている人はほとんどいません。私たちも例外ではありません。 金曜日の夜にライブラリを作成し始めましたが（これはルールで許可されています）！

Clojurecup自体は、土曜日の00:00 UTCから月曜日の00:00 UTCまで、週末のちょうど48時間続きました。 私たちの時間では、午前3時です。

土曜日の朝にオフィスに集まって、私たちは約半日をかけて、図書館、あらゆる種類のセットアップ、およびその他の労働条件の構築に費やしました。

土曜日に、MozillaのPerson （素晴らしいこと！）を介して承認を得ました。Webソケットを介してクライアントとサーバー間でメッセージを送信し、クライアントとサーバー間のビットコードを少し、データベースにはユーザー、ゲーム、イベントログを含むタブレットがあります。 クライアント上でも、テリトリーを含む従来のリスクマップが描画され始め、ホバーで何らかの形で強調表示されました。 最終コミットは22:30です。

日曜日の朝、私は私たちに素敵なロゴを描いて、それから私は日曜日すべてを1つの連続したペダルコードに塗りつけました。 ゲームカードとサーバーのリンク、移動、攻撃、補充などは、実際には最後に残りました。



夕方まで、それはまだ分解された状態で、8時までにマップの記述形式をわずかに変更し、サーバーに初めてロードしました。 ゲームを最小限の作業状態に仕上げる時間があるかどうかはまだ完全に理解できないので、何かをするチャンスと欲求/能力が見えるまで続けることにしました。

8時か9時ごろ、私たちは別の部屋に移動しました。そこでは、照明がより良く、涼しく、お茶とコーヒーのあるコーナーに近づいていました:)作業バージョンを作る機会が常にあり、十分なエネルギーと熱意があり、私たちは見た、締め切りまで彼を見た。

動作中のゲームと「移動を終了する」ボタンでコミットします。

  2013年9月30日月曜日02:59:54 GMT + 0300（EEST） 

残念ながら、本番バージョンでは、ファイルからマップデータを読み込む際にバグが入り込みました。 ローカルで動作しますが、uberjarでパッケージ化する場合-いいえ、リソースからロードする必要があります。 これを修正するコミットは終了の5分前でしたが、失敗したことが判明し、再生できないバージョンを投稿しました。 文字通り15分では不十分です。

ルールに従って、私たちは何かを修正したり、別のバージョンをどこかに投稿する権利はありません。 これで投票が行われ、木曜日に終了し、金曜日に完全に機能することを更新して表示することが可能になります。

合計で、90以上のチームが登録されました。 すべてのチームの合計コミット数のコミットの6.5％を取得しました。さらに1つ以上のチームがあり、9.15％のようです。 42チームが投票のために選ばれました。 何らかの理由で、Firefoxでは、彼らのサイトは実際には機能しません。 クロムで動作します。

金曜日には、いずれにせよ作業バージョンを投稿することをお約束しますが、今のところはチームのページで投票してください！