コミケ告知

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

なぜ日本の情報技術系Q&Aシステムはクソなのか

現状

  情報技術に特化した日本語のQ&Aシステム。かの有名なstackoverflowに相当するもの。
少なくともQ&A@ITteratailが動いていますが、どうもいまいちですね。Qiitaが「質問もできる」となっていますが、単にそういう内容の書き込みができるだけで、システム上なにかサポートがあるわけではないと思うので、これは除外として。
 他にもあるかもしれませんが、日本語版Stackoverflowが待ち望まれているということは、使えるサービスは無いのでしょう。

原因の推測

  • 技術力のあるエンジニアほどstackoverflowで済むからそれ以外しか来ない?
  最初に思いついたのはこれでしたが、日本語の方が有難い人の方が圧倒的多数だろうし、ローカルな問題も無限にあるはずなので、致命的な問題ではなさそうな気がします。

  • 並んでいる質問内容が良くない?
  多分こっち。投稿者側の質を向上させるのでは難しいことで、そうではなくて不適切な質問を削除するルールが整っているかどうかの問題です。stackoverflowでは、時々ストップがかかっているのが見られます。(→例)
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion.
  議論、投票等々は容赦なくcloseされる仕組み。調べものしたときに「俺はこっちが好き」「これどう思う?」なんて文面のスレッドが検索で引っかかっても解決に至らず、問題解決システムとしての価値を損ねるだけですから…。

closeされるルールの説明 (stackoverflow)
全体の仕組みの説明 (stackoverflow)

  そして、この仕組みの運用。コミュニティが大きくなれば、スコアの高いユーザーが権限を持つ仕組みで回るでしょうが、スタートアップ段階では運営側でそこそこ人を割かないとだめでしょう。さらに日本人は厄介事を止めに入るのが苦手そうなので、定常的に運営介入を継続する必要があるかもしれません。Q&A@ITもteratailも「最低限だけ用意して、当たったら正式に投資しよう」程度のリソース投入度合いに見えますが、見た目だけ用意して適当にプロモすれば最低限かというと、たぶんそうではないです。
2014年9月7日日曜日

ScalaMatsuri 2014 参加記録

ScalaMatsuri。昨年はScala Conference in Japanという普通~の名前だったのに、突飛な名前になっていました。今年は1日目がカンファレンス、2日目がアンカンファレンス。

会場

会場となったサイバーエージェントさんのセミナールームは、電源環境・無線環境とも非常に快適。無理やりケチをつけるならば、どこから辿り着くのかさっぱりわからない点くらいですかね。探せば画像付きの案内図が見つかるものの、カンファレンスのページからは、13Fという情報しか得られないし…

内容

もはや小田好先生となってしまった設計者Martin Odersky氏を筆頭に、今年もかなり実績のある方々が参加。でも個人的にはそっち方面よりも、はてな・LINE・GREE等々最前線企業での使用例が出されて、システムアーキテクチャ・ソフトウェアの選択(ORMやテンプレートエンジン等)・導入の様子などが見られた方にありがたみを感じました。もはや導入 自体が珍しい段階は通りすぎて、使っている人が何かしらの課題・アイデアを抱えて参加している印象を受けました。

英語

海外からのゲストスピーカーを招いているため、一応スライドは英語ですが、発表や案内は日本語を使えない人以外は基本的に日本語。なぜか日本人同士が英語で質疑&応答を行い全然通じない場面があり失笑を買った場面がありましたが、基本的には各自得意な言語で淡々とやる感じでした。私事ですが今の勤務先では、英語頑張るのは結構だけど、英語を覚えるのと仕事するのは切り離せと釘を刺されております。コミュニケーションの質を下げてはいけない。

英語ネイティブスピーカーのセッションには、なんと文字による同時通訳つき。運営の方々頑張りすぎでは…。進行・質疑応答補助・食事案内等、すごい運営のパワーを感じるカンファレンスでした。もうちょっと力抜いても良いのでは?と心配してしまいます。

総括

覚えるべきこと、Scala周辺に限っても無限にあるなあというのを再実感。
カンファレンスには色々ありますが、ScalaMatsuriは「色々やってみたくなる」「色々覚えなければとプレッシャーがかかる」という、かなりプラス方向の意識が得られました。もちろん意識だけでなくて、知識も業務上のノウハウも得られたはずだ…!(後で資料読み直そう)
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に取り込まれた模様。