コミケ告知

サークル活動の詳細は circle タグの記事へ。
2014年9月3日水曜日

OpenTweenの投稿エラー対策をした件

 ここしばらく、OpenTweenで夜間に投稿エラーが頻発していました。幸いOpenTweenはオープンソースであり、現象を捕まえたら対処はすぐでした。

問題の詳細

元のエラーは、投稿ボタンを押しても失敗し、しかも何秒か後にエラー通知+再投稿の確認のためのダイアログウィンドウがポップアップ表示される、というもの。再投稿すると成功するものの、ポップアップまでの何秒かが絶妙にストレスフルでした。

 エラー内容の日本語が謎ですが、原文のThe underlying connection was closed: A connection that was expected to be kept alive was closed by the server に対応するようです。(参考リンク)

修正内容

diffにある通り、HTTP層 (Connectionヘッダ)のKeepAliveを無効にしました。

 Twitter APIのKeepAliveについては、検索すると、2011年のTwitter Development Talk groupへのポストが引っかかります。KeepAliveがサーバー側で有効の場合は、Responseを返した後もサーバー側がTCP接続を切らず保持します。そんなリソースを食う挙動を、膨大なユーザーからの投稿があるTwitterでやるわけなかろう、というのが先のリンク先の会話。
 KeepAliceが無効なサーバーは用が済んだら即Closeしてくるはずなので、レスポンスの悪い環境で、問題が顕在化したものだと思われます。我が家は夜間の回線品質に明確に問題を抱えているOCNなので、見事にその時間だけエラーが出ました。

 エラー内容でも、捕まえた例外(pull reqのスクショ参照)でもKeepAlive関係であることが明らかであり、手元ではエラーが一切発生しなくなったため、この修正でいけるでしょう!と思いつつも、 環境によって再現性の違うエラーに対する対処は不安なので、直した翌日にフォロワーのOpenTweenユーザーの皆様に手元の修正版バイナリを試していただき、エラーが解消したようなのでpull requestしました。


LOC

修正した日+翌日の検証依頼で2日使ったので、このパッチの効率をSLOC(Source line of code)で表すと 1SLOC/Dayです。同じ内容を二箇所に書いているので、さらに半分かも。

 ネットワーク周りの修正って、ステートを持ち自律動作する複数の(最低限自分と相手の)プロトコルスタック相手なことが基本で、大山鳴動して最終結論はパラメータ1個修正みたいな話が時々ありますよね。いつぞや仕事でも、担当外部分のパフォーマンス問題解決のために、プロファイル→ソース解読→修正→プロファイル→コミットのために、確か2日かけて1行足しました。生産性がSLOC評価だと死んじゃいます(゚Д゚)


若干の愚痴

原因がわかったら一瞬で修正完了すべきものが、一瞬では終わらなかった原因が大きく2つありまして…
  1. catchした例外をstringに変換して渡している
  2. 13000行のTween.csにかなりの機能が入っている
例外の詳細が握りつぶされて、Messageだけ拾って呼び出し元に返しているため、それをやっている場所まで辿って例外オブジェクトを探す作業が必要となりました。stringに変換している時点で、もう表示する以外のエラー処理は諦めてますよねこれ。
(余談: Go言語はちょっと触っただけなんですが、String() stringしかないErrorインターフェイスって、素人が作ったら同様のstringly typedシステムになりそうな…?)

 Tween.csについては、何かあるたびにネタにしてしまうのですが(すいません)

 関数辿ったり戻ったりしながら修正するときに、同一ファイルだと不便なんです。何か直したときに全てTween.csへの変更になるので、修正箇所がわかりづらいとか、容易に修正がコンフリクトするとか、そういう問題も勿論あり。気合の入った構造改革せずとも、とりあえずpartialで分けるとこからでも、なんとかなりませんかねー。

 実は以前弄ったときに手元でやったのですが、こんなでかい変更プルリクされてもつらいよなーと思ってそのまま捨ててしまいました。Tween.csへの変更は基本的にコンフリクトする、という鶏・卵問題でもあります。

オープンソースとクローズドソースとの関係

OpenTween派生のクライアントで同じ問題が出ているものがあれば、同じ修正で直ると思われます。本家Tweenは状況知らないけども、もし同じ症状なら同様に直るのでは。
 OpenTween→Tweenへの取り込みは可能で逆は不可って状況、心理的に微妙ではありますが…

 09/05追記:あっさりTweenに取り込まれた模様。
2014年8月23日土曜日

A Tour of GoからGo言語に着手

積み言語のひとつであるGo言語の学習に着手。新しい言語を触り始める方法はいろいろあると思いますが、今回はA Tour of Goから始めることにしました。

A Tour of Go

Web上でコンパイラが動くので、環境整備せずとも今すぐ着手できます。さあ今すぐ。
日本語版がありますが、一部翻訳がおかしい(自動翻訳そのままの?)ところがあり、また英語の原版と番号がずれています。通し番号については、おそらく原版の時点で改版のたびにずれるので、そういうもののようです。問題番号で検索するのは不向き。


全体的には、少しずつ覚えていくける良いチュートリアルだと感じました。ただし、HTTP関係の一部は除く。現時点で59ページ目にWeb serversが出てくるのですが、必要な情報へのリンクがないし、Webコンパイラ上では動かないし、なぜ存在するのか謎です。これとその次のExercise: HTTP Handlersはスキップするのをお勧めします。直後のImageの問題でinterfaceについてはしっかり学習できるので、飛ばしたから困るものではないでしょう。

操作関連の追加情報

画面右下の三角形、あるいはPageUp / PageDownで、ページを順番に切り替えられます。この際、入力中のコードは保存されているので、どう書くんだっけ?と思い出せなくなったらちょっと前のページを見て、戻ってきて続きを書けます。

Next

主要なところが大体わかれば、Effecrive Goも頭に入りやすいんじゃないか、ということで次に読む予定です。

Goファーストインプレッション

  • goroutine, chan, selectが便利そう
便利そう、というか、このあたりを使うのでなければGo言語と処理系を選ぶ理由がないですね。
ただ、ちょっと間違えると長時間ブロックしたりデッドロックしたりという状況になりそうで怖い。設計で間違えた場合もコーディングで間違えた場合も。

  • なぜC言語っぽい文法や命名にしたのか謎
C言語のライブラリが変な短縮名になるのは、8文字3文字で命名する必要があった時代背景によるものであり、 今から真似る必要はないのでは。Tour序盤に出てくる math/cmplxというライブラリ名を見て、ちょっと頭を抱えました。


2014年8月17日日曜日

C86完

無事C86終了しました。お疲れ様でした。来ていただいた方、ありがとうございました!

艦これの本は、14時過ぎの離席している間に完売したようです。
Network Maniacs vol.1+2は、ギリギリ残る感じでいい読みでした。あと一回だけ増刷するかもしれません。 

Network Maniacsのvol.3は、結局出せませんでした。待っていた方もいらっしゃったようで、非常に申し訳ないです。冬もし当選すれば、一年分のネタを材料に、ちゃんとVol.3が出るはずです。

誤植

艦これ本のほう、p.22にWordの参照先エラーが残ったまま印刷してしまいました。こんな大物がチェックを抜けるとは、なんと恥ずかしい。正常な参照情報の横に余計なエラーが出ている状態で、見た目が超カッコ悪い以外には実害はありませんので、どうか見逃してやってください…
2014年8月5日火曜日

C86 予定(更新)

◎貴サークル「浜風もっこす」は、日曜日 西地区“き”ブロック-22a に配置されました。
当選して3日目(8/17 日曜日)西に配置されました。真面目なソフトウェア関係の解説本が並んだ島で、時間を問わず混むエリアではありません。西なのでちょっと来づらいとは思いますが、薄い本確保のための戦闘が終わったあとにでも、散歩がてらに如何でしょうか。近くの電子工作島では工作物の実物展示もいくつかあり、下調べなしでも楽しめるエリアです。


予定している活動の概要

  • Network Maniacs Vol.1+2
Vol1とVol2を一冊にまとめた本です。前回どちらも早々に完売してしまったため、今回は少し余裕を持って持ち込む予定です。
【TCPの高速化手法】 基本的な話からLinux3系の新実装まで、TCPの高速化に使われている方法の解説。
【ネットワークバッファとパケットロス】 パケットロスとは何で、ネットワークバッファとはなにか? 【QUIC】 Googleの実験用プロトコルQUICの概要と試用方法。
【FiddlerCore】 .NET用のHTTP層解析ライブラリの紹介、使用例。


  • Network Maniacs Vol.3

ネットワーク関係の新刊は、出るとしてもコピー本で小部数となります。
7月末にHDD がコミケ作業中のデータとともに吹き飛んだ影響で、オフセットで出すことが出来なくなってしまいました…。

  • 
    
    未確定で進撃中 -艦娘でもわかる確率計算-
艦これを例に、ゲーム攻略全般に気軽に活用できる程度の、確率・統計周りの雑談・評論本です。
・確率とは何ぞや?
・確率計算の実践例&確率関係のネタ雑談
・ソーシャルな情報の扱い方
といった感じです。

しらニョロ氏に表紙を書いていただいた、珍しく見た目が綺麗な本になります。阿武隈さんだよー。中身は文字とグラフばかりですけどね!


よろしくお願いしマース!
2014年4月1日火曜日

Elixir relexによるassemble

Releaseに際して、Scalaならばfat JARを生成するためのsbt-assemblyというものがあります。Elixirではrelexがそれに相当するようです。
親切なドキュメントは無く、最初はうまくいかなかったのですがrelexを使っているプロジェクトを発見して、そこのmix.exsを真似するとうまくいきました。


  • depsにrelexを追加
  • Code.append_pathでライブラリのパスを追加
  • defmodule Release を追加


参考資料

特に追加設定をせず mix relex.assebleを実行すると、Erlangのランタイムまで丸ごと入ります。include_erts? や include_elixir? などのオプションがあり、Releaseモジュールの中で定義することでデフォルト設定を上書きできるようです。ドキュメントはなさそうなので、relexのrelease.exsを参照。

中でシェルスクリプトを生成しているため、純粋なWindows環境では上手く動かなそうに見えます。
2014年3月25日火曜日

Elixir - Hello worldを求めて右往左往

先日の歌舞伎座.tech #3で存在を思い出したElixir。早速というほど早速でもないのですが、ちょっと使ってみるかーという気になりました。情報量が少ないのは覚悟していたものの、困ったことにちゃんとしたHello worldが見つからず、それなりに苦労することに。


Hello worldにおいて、「コンソールに文字を表示する文法を覚えましょう」というのは目的の一部でしかありません。元々のC言語で言えば、ソースコードを作成する→コンパイルする→実行する この一連の流れを体験するためのものです。
公式にはGetting Startedがありますが、インストールの次はいきなりインタラクティブシェル(iex)を使った文法説明。いやそうじゃない、まず最終的な出力ファイルの作り方を教えてくれよと。プロダクトでもiexから走らせます、という事であればそれで良いんですが。

試行錯誤したりTwitterで教わったりしつつ、最低限のところまでは進めたので、書き残しておきます。

ソースコード作成

% cat hoge.ex
defmodule Hoge do
  def hello do
    IO.puts "hoge world"
  end
end

Hogeモジュールを定義し、その中にhello関数を作成。中はコンソールへの出力のみ。

コンパイル

% elixirc hoge.ex

ここまでは何の問題も無し。ただし、2回目以降のコンパイルではwarningが出ます。
% elixirc hoge.ex
hoge.ex:1: warning: redefining module Hoge

びっくりするけども、実際のところ問題はない模様。
参考:Warning “Redefining module” when file is containing 2 Modules

実害のないwarningなんて、warningをスルーする習慣がつくだけだから良くないのでは…

実行

% elixir -e Hoge.hello
hoge world

-eで ModuleName.function_name を指定。

コンパイルで出来あがるのはErlang VMのbeamファイルなので、Erlang VMで実行できるはずだ!と試したところ、Elixirのbeamファイル群がある場所を検索パスに含めてあげれば、実行できる模様。

% erl -pa "D:\bin\elixir\lib\elixir\ebin" -noshell -s Elixir.Hoge hello -s init stop
hoge world
 

mixを使う

mix.は、Scalaならsbt、元のErlangならrebar相当となる、依存するライブラリ管理・テスト・実行あたりまでをカバーする、Elixir付属のビルドツールです。前述のようにいちいちelixircを叩いてコンパイルすることはあまりなくて、基本的にこれを使うっぽい。
参考:Introduction to Mix

まずは雛形を作成。

% mix new hoge --bare
* creating README.md
* creating .gitignore
* creating mix.exs
* creating lib
* creating lib/hoge.ex
* creating test
* creating test/test_helper.exs
* creating test/hoge_test.exs

Your mix project was created successfully.
You can use mix to compile it, test it, and more:

    cd hoge
    mix compile
    mix test

Run `mix help` for more information.


ソースコードはlib以下に出来ます。今回はhello worldなので、lib/hoge.exにIO.putsを置くだけ。(要は前述のソースコードと同じようにhello関数を作るだけ。ソースコード略)
あとは、mixにコンパイルしてもらいます。

% mix compile
Compiled lib/hoge.ex
Generated hoge.app

そして実行。

% mix run -e Hoge.hello
hoge world

依存するライブラリやアプリケーション設定などは、mix.exsに記述すればいいようです。


2014年1月2日木曜日

C85 おつかれさまでした

3日目し39b サークル浜風もっこす まで足を運んでくださった皆様、ありがとうございました。

次にお詫びをしないといけません。
次回も持って行けるように前回の倍刷ったのですが、13時頃に在庫がなくなってしまいました。
完売ありがとうございます、なのですが、在庫余裕ですみたいな事を言っておきながら、ゆっくり来た方は残骸しか見られないという状況になってしまいました。前回から、活動ジャンルを微妙に変えた(扱う話題上のレイヤーにシフトした)のですが、その変化にも十分に対応できていなかったようです。


早く畳んでしまったことにはもう一つ原因がありました。見本を用意しなかったので、本が無くなったら何もお見せできるものが無くなってしまったのです。前回は「完売してしまいましたがこれが見本です」という感じで居座っていたのですが、今回は机の上に何も無くなってから気づきました…。

反省を生かして、次以降の参加があればそこに生かします。
引き続き、サークル浜風もっこすをよろしくお願いいたします。

出版物に関するご感想、ご意見もお待ちしております。
Twitterの@moccos、奥付にあるメアド、ここのコメント欄などまでお寄せください。