コミケ告知

サークル活動の詳細は circle タグの記事へ。
2016年6月25日土曜日

技術書典 お疲れ様でした

技術書典 https://techbookfest.org/ A-31 浜風もっこすで参加しました。頒布内容は前記事参照。

頒布物について

持ち込んだ二種類とも、14時すぎに完売となりました。購入してくださった方、見に来てくださった方、ありがとうございます。完売後にいらっしゃった方、申し訳ありませんでした。言い訳はあれどイベントの中間地点あたりで切らしてしまったのは痛恨です。
しかしこれでも、夏コミ分と合算した数量を印刷したつもり、つまり適性数の倍くらい刷ったつもりだったのです。予想の3倍刷っていくというのはかなり無理な話であり、どう思い直してもこれ以上は持って行けなかったなと…。
電子書籍販売や店舗委託・通販委託などに手を出したことはなかったのですが、これを機にまとめて検討を始めています。

イベントについて 

大盛況でしたし、欠席サークルもほとんどなく、またほとんどのサークルに人だかりが出来ていて、主催・出展側ともすばらしいイベントだったのではないでしょうか。入場規制がかかった上に、終盤おそらく完売ばかりだったので、一般参加の皆様からするとそのあたり不満があったのではないかと思いますが、こんなに盛況になるのを読むのは難しかったかなと。次回以降、規模を拡大しての開催も、おおいに期待したいです。
唯一、時々端の方でスポンサー公演(?)やじゃんけん大会(??)があったらしいけども、会話の邪魔なだけだったので、あれには不満があります。そもそも何なのか全然わからないまま始まってたのが一番の問題かも。
2016年6月24日金曜日

出展情報: 技術書典/C90

技術書典

https://techbookfest.org/
A-31 です。よろしくお願いします。 (なんで書展ではなく典なのだろう)

新刊は二つ考えたのですが、どうも面白いものにならなかったので没です。すいません。既刊 のうちvol. 1+2(ネットワークバッファ・パケロス・TCP高速化・QUIC等) と vol. 3 (TCPプログラミング・コマンドラインツール)を増刷したので持っていきます。
Vol.4と5はいったん廃刊にして、部分的に再利用できるものはどこか総集編的なもので採録にしたいと考えています。なぜ新しいほうがそういう扱いになったかというと、中途半端に新鮮味(時事性)のあるものを書いてしまったために、さっさと賞味期限が切れたということです。根本的な技術ネタと、時事的なものとをどう扱っていくべきか。

C90

◎貴サークル「浜風もっこす」は、日曜日 西地区“f”ブロック-33a に配置されました

珍しくサークルカットの予定通り、次のテーマはシリアライズ周りの予定です。SerDesではなくSerDeのほうです(わかりづらい表現)。ProtocolBuffer等々。
2016年3月24日木曜日

Elixirでattributeを用いたコンパイル時分岐

C/C++でいう#ifdef DEBUG 的なことを、moduleのattributeを使って行おうとしたところ、dialyzerさんに文句を言われてしまいました。if (@flag)のような記述が展開され、if(true) とか if(false) とかになって、欠陥のあるパターンマッチ記述として検出されるわけですね。
そこで、ただコンパイルの前にtrue/falseが判定されるだけのマクロを書いて対処しました。

上記のソースコードをdialyzerにかけた結果はこうなります。(dialyxir使用)
% mix dialyzer
Starting Dialyzer
dialyzer --no_check_plt --plt C:\Users\moccos/.dialyxir_core_18_1.2.3.plt (オプション略)
  Proceeding with analysis...
hoge.ex:8: The pattern 'false' can never match the type 'true'
 done in 0m1.31s
done (warnings were emitted)

# 最初に書いたバージョンに間違いがあったので、2016/03/28に修正しました。
# Elixir1.3系で動かなかったので2016/06/24に再度修正
2016年3月5日土曜日

Cowboyの使い始めではまったところメモ (privとは何ぞや)

ElixirでWebサーバーといえばPhoenixですが、既存のElixirアプリケーションにちょっとWebサーバーの機能を足すだけの場合にはちょっと大規模すぎたので、PhoenixよりもコンパクトなCowboyを使うことにしました。Phoenixのサーバーコア部分はCowboyなので、比してコンパクトという表現は実はちょっとおかしいですね。

ソースコードのexamples以下には、いくつもサンプルプロジェクトがあり、それをそのまま動かすのも、参考にして動かすのも簡単です。ドキュメントもErlangなのに十分にあり、必要なハンドラを定義して差し込むだけで動きの把握もしやすく、素晴らしいライブラリですね。

ただしひとつだけ罠があり、それはサンプルで用いられるファイル読み出し指定が priv_dir や priv_file であることです。例えばstatic_worldのサンプルでは…

Dispatch = cowboy_router:compile([
 {'_', [
  {"/", cowboy_static, {priv_file, static_world, "index.html"}},
  {"/[...]", cowboy_static, {priv_dir, static_world, "", 以下略
 ]}
]),
Elixirで書くとこんな感じ:
dispatch = :cowboy_router.compile([
  {:_, [
      {"/", :cowboy_static, {:priv_file, :static_world, "index.html"}},
      {"/[...]", :cowboy_static, {:priv_dir, :static_world, ""}, 以下略}
  ]}
])

これをiexで走らせると動いて安心していたのですが、escriptにしたりアプリケーションとしてリリースしようとしたりすると全然動かない。index.htmlなどのファイルが見つからないときの挙動をする…。 どこに置いてもindex.htmlなどのファイルをアプリケーションが見つけてくれない。
同様にpriv方面ではまっている英語の記事があり、そちらではそのまま力技で解決していましたが、そんなに頑張らなくても、単にprivディレクトリを使う指定をやめればOKでした。

dispatch = :cowboy_router.compile([
  {:_, [
      {"/", :cowboy_static, {:file, "web/index.html"}},
      {"/static/[...]", :cowboy_static, {:dir, "web/static"}}
  ]}
])

実コードから引っ張ってきたので若干パス指定が違いますが、要点は:priv_fileではなく:file、:priv_dirではなく:dirを使うこと。アプリケーションからの相対位置で無事読めました。privディレクトリがErlang的に特別なものらしいのです。ぐぐるとほとんど情報がないなかに、ユーザーズガイド邦訳から以下の説明が見つかります。

アプリケーション固有のファイルの格納に使用されます。例えば、Cの実行ファイルがここに置かれます。code:priv_dir/1関数を使用すると、このディレクトリにアクセスすることができます。

単にprivという名前のディレクトリではないことはわかりました。Cの実行ファイルを格納するようなところに、Webのリソースを置くのはなんか違うんじゃないかなという感覚があるのですが…

# 2016/04/20追記
公式のMix.Tasks.Escript.Buildの項目に
Note: escripts do not support projects and dependencies that need to store or read artifacts from the priv directory.

とありました。
2016年1月22日金曜日

一時ファイルのサイズはどこまで許容されるのか

ここで一時ファイルとしているのは、linuxなら/tmp、Windowsなら%TMP%および%TEMP%のことです。特にWindowsだと、GetTempPathのように安直にパスを得られて、気軽に使えます。

遭遇した問題 

昔かなり遊んでいた音楽ゲームにbeatmania IIDXというものがありまして、そのクラウドバージョン、PC上でプレイできる beatmania IIDX Infinitasというサービスが始まりました。トライアル版が無事動いたので、さっそく製品版を遊んでみようと思ったんですが、インストール中にエラーが出るんです。
何度やっても同じところで停止。そんな重大不具合ならば騒ぎになるはずですが、Twitterで検索してもそんな話は出てこない。つまり、こちらの環境の問題である可能性が極めて高くなりました。インストーラーの動作中にディスクの書き込みを監視すると、どうやら一時ディレクトリに書き込んでいる…
そのサイズ、3GB弱。マジか。明らかに曲データが入っているでしょうから、今後サービスが継続していくにつれ、どんどん大きくなっていく可能性もあります。うちのメインPCでは、テンポラリはRAMディスクに割り当てているので、こんな大きなサイズは入りませんでした。

# 追記: 本件はset %TMP%して実行することで回避は可能っぽいけども、エラーが発生しました!としか出ないので、そこそこ詳しい人でないと解決できなそう。

一時ディレクトリは何GBあればよいのか

デフォルトではWindowsではシステムドライブ、Linuxも律儀に分けていなければ、/binや/usrなどと同じパーティションになるのではないかと思います。HDDにどかんと置いている場合には問題にならないでしょうが、うちのようにRAMディスクを割り当てている場合、システムSSD+HDD構成でシステムドライブの容量が限られている場合などは問題になる可能性がありそうです。
果たして一時ディレクトリにどのくらいまで置いていいのか、という議論は、あまり見たことがありません。適当にGoogleで検索すると、ユーザー側の対処がたくさん引っかかって難しい。はたして、どれくらいまで置いてよいものでしょうね?

さらに追記 

2015年12月31日木曜日

C89 お疲れ様でした

大晦日のコミックマーケット89、当サークルまで足を運んでくださった皆様、ありがとうございました!

新刊は12:50より前には完売してしまいました。コピー本としては過去最多の印刷数でしたが、それでも見込みが少なく、その後にいらっしゃった方にはご不便をおかけしました。次回があれば、またVol.5 は体裁を整えつつ、Vol.6のネタも収集しておきます。(申込みはする予定ですが、当選するかどうかは神のみぞ知る…)
2015年12月9日水曜日

Elixir ゆるデスクトップアプリ のすすめ

Elixirは、実績のあるErlangのVMやライブラリを使うための、人当たりのよいDSLのようなものです。そのため、得意な領域はErlangと変わらないはずで、Erlang系の本領は、高信頼・高い並行性という特性を生かしたバックエンドです。しかしそれに加えて、コードが書きやすくなったがゆえに射程範囲に入った分野もあります。流行りのPhoenixもそうだ、と言えなくもないでしょう。本記事では、そんな変わった使い方のひとつを紹介します。

この記事は、Elixir Advent Calendar 2015 9日目です。前日は Elixirでリバーシ でした。実は昨年のElixir Advent Calendar 2014にも参加させていただいておりまして、2014年のElixir1.0初心者 という題で、触り始めで良かった・困ったことなどを書くソフトな記事を書いておりました。

何を作っていたのか

  • ネットワークゲームの通信を入力
  • JSONをばらして内容を解析
  • 解析内容を組み合わせて現在の状態を計算
  • 適当に表示

ネトゲの(非友好的な)解析としては基本的なやり方のひとつです。

何が便利なのか

  • アプリケーションを動かしたままコードを入れ替えられる
  • アプリケーションは部分的に死ぬ (全滅しない)
この組み合わせが、趣味のツールであってもたいへん快適です。まずコード入れ替えについて実例をあげると…



真ん中の行、処理していないAPIは単にコンソールに名前を吐いています。この api_get_member/ship_deck が来たときにもコンソールに情報出しとくかー、と思いたったとしたら、ささっとコードを追加あるいは更新してリロード。メモリ上に保持したアレコレをそのままに、さらりと次回叩いたときから処理が動くように組み込めます。

(enemyとmap infoの間に追加情報が2行出るようになった!)

コード上では、 Kernel.ParallelCompiler のfiles/2に対象のファイル名を渡しています。保持しているデータ型を変えようとすると面倒になるはずですが、処理ロジックの入れ替えだけであれば、大したことはありません。

そして次の、アプリケーションが部分的に死んでくれるという特性について。ゲームしながら空き時間にいじるような注意力散漫なコーディングをしていると、よくエンバグしてこけます。言語に不慣れならなおさらのこと。あるいは、ある日突然JSONの構造が変わって、処理がうまくいかなくなることもあります。そういったときに、アクターモデル(Erlangプロセス)の仕組みは便利なものでして、JSONをパースしていくらかの計算をする部分、構成図でいうparseの部分が死んだところで、アプリケーション全体としてはなんともありません。その失敗した処理要求は、何も工夫しなければどこかに吹き飛んで消えてしまいますが、必要ならオペレーションを保持しておいて、処理関数を更新した後にリトライすれば復旧も可能です。Event sourcing的な。
Erlangを用いたシステムの高信頼性とは、「落ちてもいいように作る(そういう仕組みを作りやすい)」という面があって、趣味でだらだら遊ぶにも向いているのでは…!

Elixirによる自作ツールの可能性

以上、ちょっとしたツールにも便利ですよーという話でした。単純なスクリプトにお勧めはしませんが、処理を待ち受ける or 何かを監視する、生存期間がそれなりにあるツールには向いています。GUIが欲しければ、Phoenixを組み込んでしまえば良さそう。
Elixirという言語&Erlangの実行系に慣れるという副次効果まで考慮して、遊びのツールを作るという路線、布教あるいは学習方法のひとつとして、いかがでしょうか。