コミケ告知

サークル活動の詳細は circle タグの記事へ。
2015年12月31日木曜日

C89 お疲れ様でした

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

新刊は12:50より前には完売してしまいました。コピー本としては過去最多の印刷数でしたが、それでも見込みが少なく、その後にいらっしゃった方にはご不便をおかけしました。次回があれば、またVol.5 は体裁を整えつつ、Vol.6のネタも収集しておきます。(申込みはする予定ですが、当選するかどうかは神のみぞ知る…)
0 件のコメント:
ラベル: ,
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の実行系に慣れるという副次効果まで考慮して、遊びのツールを作るという路線、布教あるいは学習方法のひとつとして、いかがでしょうか。
0 件のコメント:
ラベル:
2015年12月2日水曜日

Advent Calendarは時期が悪い

日本のIT界隈ではAdvent Calendarという、どこぞの神様のお祝いカウントダウンに便乗して、テーマに沿った記事をアップしていく、謎の慣習があります。しかし12月というのは、年度末ほどではないけれども忙しい。年度末リリースの仕事が佳境であったり、忘年会が平日にまで入っていたり…。さらにオタク的には冬コミ入稿時期直撃、声優やアイドルのイベントが多い、昨今はソシャゲのイベントも多い、とあります。

もっと他の時期にやったらいいのになあ。他の人のお祝いしましょう。竹達彩奈(6/23)あたりどうですか。Java竹達Advent Calendarとか、Go言語竹達Advent Calendarとかね。
0 件のコメント:
2015年11月3日火曜日

C89 配置されました

◎貴サークル「浜風もっこす」は、木曜日　東地区“ム”ブロック－36b に配置されました。

ありがたいことに今回もサークルとして参加させていただけるようになりました。
仕事が12月〆になったので、作業時間的に後ろにのばすほどやばい感じです。今月半ばには形が見えるくらいでないと死んでしまうでしょう。

現在のメインであるNetwork Maniacsは、原点回帰という感じで、プロトコル周りの話を書きたいです。ネタ精査中。なにか工作して現物展示も考えたのですが、前述のように仕事がヤバイのでつらそうです。工作方面ではESP8266が今年とてもホットだったのですが、みんなこれを使う(使っている)ので、生半可なことをしても面白くありませんよね。アイデアが浮かぶかどうか次第。
毎度中途半端に終わってしまっている艦これ攻略関係、もう艦これのブラウザゲームを続ける気力が尽きかかっているので、分量は少ないとしても、今回で形にして完結しないといけません…。夏まではモチベーション続かないな。
0 件のコメント:
ラベル: ,
2015年9月13日日曜日

tryする末尾再帰関数が普通には書けないScala

TL;DR

try～catch内で値を返す再帰関数を書くには、scala.util.Tryを使う。

説明


Scalaでは末尾再帰関数は最適化してくれるし、それをtailrecアノテーションでチェックすることができます。(最適化が効かない場合にコンパイルエラーが出るようになる) 
@scala.annotation.tailrec
def f(n: Int): Int = {
  ...  // (略)
  f(n - 1)
}
ただこれ、try～catchを付けて、そこで値を返そうとするとうまくいかないんですよね～ 
@scala.annotation.tailrec
def f(n: Int): Int = {
  try {
    ...  // (略)
    f(n - 1)
  } catch {
    // どの場合も返す型は正しいものとする
  }
}

scalac Main.scala
Main.scala:3: error: could not optimize @tailrec annotated method f: it contains a recursive call not in tail position
  def f(n: Int): Int = {
エラーメッセージも正しくなくてなんだこりゃって感じですが、stackoverflowに回答がありました。

何度も回答がEditされていますが、その一番下。try～catch節ではなく、scala.util.tryを用いることで回避できるようです。
@scala.annotation.tailrec
def f(n: Int): Int = {
  scala.util.Try(例外の出る処理内容) {
    case Success(処理の返り値) => ...
    case Failure(e: 例外の型) =>
    case Failure(e: 例外の型) =>
  }
}

知っていて最初からこれで書けば面倒くさいことはないんだけど…Scala、あちこち珍妙なとこあるよな。

0 件のコメント:
ラベル:
2015年9月1日火曜日

Akkaのsenderは値ではない

久々に使うと忘れがちなのでメモ。

AkkaのActorは、メッセージ受信時にはその送信元を示すActorRefをsenderで取れます。メッセージを送り返したり、デバッグ時に表示させたり、何かと便利です。
def receive = {
  case x => sender ! x  // echo
}
しかしこのsender、Futureで使おうとすると望み通りの挙動をしません。表示させてみると、送信元とは違う値になっています。(deadLetters宛になる)
Future {
  sender ! myFunc(x)  // NG
}
こういうときは、一時的に別の定数に入れて使うか… 
val dst = sender
Future {
  dst ! myFunc(x)  // OK
}
最後に結果を返したいだけなら、pipeToを用いるか。 
Future {
  myFunc(x)
} pipeTo sender

senderとは何なのか

senderはcontext.senderを呼び出すようになっていて、さらに追っていくとActorCellの実装に辿り着きます。
  final def sender(): ActorRef = currentMessage match {
    case null                      ⇒ system.deadLetters
    case msg if msg.sender ne null ⇒ msg.sender
    case _                         ⇒ system.deadLetters
  }
これは変数ではなくメソッドであるので、sender と記述したところに制御が到達したタイミングで、初めて処理が行われます。ちなみにvar currentMessageを弄っているのも同じActorCell内で… 
  final def invoke(messageHandle: Envelope): Unit = try {
    currentMessage = messageHandle
    cancelReceiveTimeout() // FIXME: leave this here???
    messageHandle.message match {
      case msg: AutoReceivedMessage ⇒ autoReceiveMessage(messageHandle)
      case msg                      ⇒ receiveMessage(msg)
    }
    currentMessage = null // reset current message after successful invocation
  }
  //  以下略…
まずcurrentMessageがセットされたのち、システム側で処理されるAutoReceivedMessage以外であれば、receiveMessageからActorのおなじみreceiveメソッドの処理へ。終わったら戻ってきてnullに戻します。(普通にnull使うんだ… 初期値が _ だからnullで統一してるんだな)
Futureの処理がどこかで走るときには、このメッセージ受信による処理駆動パスとは異なるので、 currentMessage == null であり、 sender()はdeadLettersを返すのですね。

カッコ省略のデメリット？

仕組みが分かっていない段階で誤った使い方をしてしまった原因のひとつが、引数なしメソッドのカッコが省略されていることでした。サンプルでも基本的に省略されているから、そもそも最初はメソッドだと思っていなかったよ…(´・ω・｀)
記述が簡潔！の思想に走りすぎるとデメリットもありますよ、ということで。
0 件のコメント:
ラベル: ,
2015年8月24日月曜日

C88 お疲れ様でした

夏コミで当サークルまで足を運んでくださった皆様、ありがとうございました。
(当日からだいぶ時間が経ってから書いております…)

今回は多めに持って行ったために、在庫が切れることはありませんでした。
新刊として、Webサーバーやバックエンドで大活躍する並行プログラミング向けの、アクターモデルについての解説を出しました。ただ、今までと結構毛色が違うのと、アクターモデルとは何ぞや？という説明を、事前にも当日その場でもほとんどせずに出してしまったので、ちょっと対象読者を絞りすぎたかなという反省です。

冬コミにもし当選できれば、原点回帰のネットワークプロトコルまわりのネタでVol.5を出すつもりです。TCP・QUIC・そしてインターネット全般について、既刊で触れている話題以外にも既にいくつか候補があります。
それから、何かネタを練ってネットワーク系の動態展示が出来ないものか思案中です。無線系のいいチップも出ましたし、昨今はタブレットも結構電池が持つので、人通りの多い10時半～2時くらいなら十分耐えられそうな見込みがあります。
0 件のコメント:
ラベル: ,
2015年8月17日月曜日

Network Maniacs vol.4 リンク集

夏コミで頒布させていただいた Network Maniacs vol.4 のリンク部分一覧です。
出来るだけページ内脚注に参考URLを載せるようにしたので、今回はかなり多くなりました。

0 件のコメント:
ラベル: ,
2015年8月12日水曜日

Network Maniacs vol.1 エラッタ

タイトルの通りです。もう年単位で前に発行したものですが、誤りを見つけてしまったので、訂正させていただきます。2015夏(第三版)以降では、修正ずみです。
場所はp.5 「Nagleのアルゴリズムを無効にするべきか？」の項目で、例が間違っていました。それより前のページにある説明は問題ないはずです。例だけおかしい。

以下に修正済みのページをアップロードしておきますので、お手数ですがご参照ください。
なぜこれが発生したかというと、この本は手元で書き溜めた(特にどこかに公開しているわけではない)文章ストックからペタペタして作っている部分があるのですが、かなり古いもので間違ってるものがあったのです。 確認不足ですね…
0 件のコメント:
ラベル:
2015年8月10日月曜日

scalikejdbc-mapper-generatorでテストを生成しない方法

TL;DR

generator.testTemplate
に無効な値を入れる。空白でよい。

本文


　ScalaでSQLを扱うときの選択肢のひとつであるScalikeJDBC。黒魔法Slickよりは何が起きているか理解しやすいので、せいぜいJavaのORMの3倍くらいの難易度に収まっていて、人間でも使える感があるライブラリです。
　機能のひとつに、既存のDBに接続して、その内容に合うようにインターフェイスを生成してくれるものがあります。ライブラリは scalikejdbc-mapper-generator として分かれており、ScalikeJDBCではReverse Engineeringという機能名で呼ばれます。Slickの同等機能はSCHEMA CODE GENERATION ですかね。

　このライブラリはテストコードも吐くようになっていますが、これがそのままでは通らなくて外したい、と思うことがあるでしょう。そんなときには、
project/scalikejdbc.propertiesのgenerator.testTemplate に、無効な値を設定すれば、出力されないようです。ソースコードではscalikejdbc/mapper/CodeGenerator.scala のdef specAll() あたり。
0 件のコメント:
ラベル: ,
2015年8月2日日曜日

サークル浜風もっこす C88情報

C88には無事当選しておりました。
日曜日 東地区 "Ｏ" ブロック 38a
に配置されています。3日目です。

今回のラインナップは以下を予定しております。

  • Network Maniacs vol.4 [新刊]
    • ネットワーク向け高並列アプリケーション向け「アクターモデル」フレームワーク紹介
      • Erlang
      • Elixir
      • Akka
      • Orleans
      • Orbit
      • Pony
  • 艦これ攻略本 [新刊・コピー本]
    • 出来るのか謎
  • Network Maniacs vol.3
    • TCP受信プログラミング
    • 「ネットワーク向けコマンドラインツール紹介
  • Network Maniacs vol.1+2
    • 【TCPの高速化手法】 基本的な話からLinux3系の新実装まで、TCPの高速化に使われている方法の解説。
    • 【ネットワークバッファとパケットロス】 パケットロスとは何で、ネットワークバッファとはなにか？
    • 【QUIC】 Googleの実験用プロトコルQUICの概要と試用方法。
    • 【FiddlerCore】 .NET用のHTTP層解析ライブラリの紹介、使用例。


まだ新刊が出来上がってないので情報が不完全ですが、逐次この記事は更新します。
8/13 Network Maniacsについて情報を更新しました。


当日、基本的にはサークル内におりますが、午後のどこかの時間で挨拶回りをする予定です。

よろしくお願いします。
0 件のコメント:
ラベル: ,
2015年7月8日水曜日

Googleのインチキグラフを叩くべきかどうか

先日、Googleの講演を見ていて、ちょっとした衝撃を受けました。
上記リンク先に指定してある、37:20頃に出てくる棒グラフ。出典は2010年のGoogleの論文なのですが…



左軸に注目。原点が0ではありません。
よく言われるように、棒グラフなので厳密に原点0にすると、以下のようになります。(棒と左側の縦軸以外は手抜きな画像で、左軸の大きな目盛は100msec単位)



一番左がちょっと高いかなという程度で、あまり情報量のないグラフになりました。

これは、Googleの誰かがうっかり出した資料ではなく、こうして重要な資料として5年後にまで引用されるものであり、またSIGCOMMという有名どころで発表されているものでもあります。

良い表示方法ではないかもしれませんが、日本(のTwitter)でよくやるように、○○グラフはこういう表記をしなければだめだ！！という堅いルールではなく、読む側が気を付けましょうねという運用を考えても良いのかもしれません。実際、折れ線グラフで表示されたって、軸があれば絶対値が読めてしまうし、そちらに話題が発展してしまうこともあります。
 もし原点の編集をした上で軸の数値表記を削ってしまったら、正確に絶対値を読み取ることが不可能になるので、それこそ人間界から排除すべきインチキグラフですが。

グラフを読む姿勢の違いが、日本でインフォグラフィックを見かけることが少ない原因のひとつなのかな、と思うこともあります。表現側で形式に従ってきっちりしていないと読めない(読み違いやすい)のは、あまり自慢できることではないと思うのですが。
0 件のコメント:
登録: 投稿 (Atom)