DenkiYagi RSSフィード

2011-12-06

[]NGK2011Bを開催しました

今年もNGK(名古屋 合同 懇親会)として、クロスコミュニティ忘年会を開催しました。

開催まとめ

昼の部

スピーカーの方々の素晴らしい発表と私の酷い司会っぷりが今年もバッチリ録画されてました。

夜の部
参加コミュニティ

謝辞

今年も色々な方のお陰で開催することができました。本当にありがとうございます。

  • 会場を貸して頂いたエイチームさん
  • ドリンクスポンサーとプロジェクタレンタルをしてくれたスタンドファームさん(@toyoshiさん)
  • 去年に引き続き今年もハイレベルなUStream中継をしてくれた@katzuenoさん
  • 急遽LTタイマー用のマシンを貸し出してくれた@clairvyさん
  • 受付や買い出しを手伝ってくれたボランティアスタッフのみなさん
  • スピーカーに名乗りでてくださったみなさん
  • 当日参加してくれたみなさん

KPT

とりあえず思いつくことを雑多に。去年のNGKのKPTも参考に。

Keep
  • 100人近い集客のイベントが開催できた。
  • 30以上のコミュニティ・勉強会が参加した。
  • スピーカーがちゃんと集まった。
  • katzuenoさんのUStreamすごい。
  • 大した額ではないけど、スポンサーを付けることに成功した。
  • フリードリンクを設置できた。
  • 事前集金(Eventnor)で6割ほどは事前集金ができた。
  • 学割で1500円。
  • 夜の部の野良LTが結構盛り上がった。
  • 今年は夜の部領収書を発行することができた。
  • 今年も夜の部は入場チケット制、更にチケットに地図を入れた。
Problem
  • とにかく準備不足、ACアダプタを忘れるというダメっぷり。
  • 参加コミュニティの紹介がちゃんとできなかった。
  • 司会がグダグダ、ちゃんと司会の準備をする必要がある。
  • フリードリンクのゴミの処分をエイチームさんに無理やりお願いしてしまった。
  • 受付作業を丸投げしてしまった。これはマニュアル化しないとダメだと思う。
  • 大人料金4300円は当日集金の事を考えると中途半端な額になってしまった。
  • ドタキャンの見込みミスで夜の部が若干赤字になってしまった。
  • PARTAKEのメッセージング送信機能が若干機能不足。
  • 集金管理周りの手間がかかりすぎている。
  • 結局、今年も実行委員会制にはできなかった。
  • 受け付け作業や会場準備の影響で開始が15分遅延してしまった。
  • 2010年のKPTを9月に一回だけ見たきりで、開催まで見返すことがなかった。
Try
  • 実行委員会にして私が死んだらイベントが死ぬような状況を回避したい。
  • 事前確認項目をマニュアル化しておくべき。
  • 受付をマニュアル化、さらに言えば電子化・自動化して効率化したい。
  • 事前支払い率をもっと上げたい。
  • 会場準備時間にゆとりをもつ。
  • 開催前の期間に何度もKPTを確認して、準備の練度を上げる。

その他雑感

今年は去年よりかは多少参加人数が増えましたが、おそらく私が主催している限り、100人あたりが上限値かなという肌感覚です。無理にイベントを大きくする必要は無いとは思うのですが、マンネリ化の兆候かな、と思う節もあるので、もし来年も開催するのであれば、やはり実行委員会化は必須かなと思っています。

2011-11-05

[][][]LL. 名古屋でDLRっぽい事を話してきました

古くからのDLR使いの人には懐かしいChiron.exeを車輪の再発明してみました的な。

夜なべしてつくったプログラムは、ゴミを整理したあとでBitBucketとかに公開予定です。

SkyDriveに置いときました。YADLR

2011-10-06

[][]Cassandra Conference Tokyoの資料を公開しました

GeQuuのアーキテクチャについての話です。Androidクライアントがまだほとんど機能を実装していない状態なので、こんなものに開発時間かけすぎだろ思われがちなGeQuuですが(自意識過剰?)、見えない所で異常に頑張ってるんですよというお話です。

テキスト装飾というか色付けをまどマギな感じにしたんですが、まさか発表中に気がついた人はいないですよね。

2011-08-26

[]自分用メモ:GPSロガーを実装する際に参考となるOSS

「これだ!」って状態が見極められたら、ちゃんとGPS周りのエントリー書くつもりだけど、とりあえずメモ。

要点

  • Serviceとして実装
    • Serviceにしないとアプリがすぐに殺される
    • startForeground()もする
      • ただ、startForeground()してても死ぬので、復活させる実装も必要
  • GPSロギング中はPARTIAL_WAKE_LOCK
  • 定期的にLocationListenerを再登録
    • 長時間に測位できていない状態が続くとLocationManagerがおかしくなるっぽいが、removeすると元に戻る(なんかリソース取得ロックの競合が発生しているような挙動)
    • MyTracksはTimerを利用して、1分ごとにLocationListenerを強制的に再登録している
    • Open Gps Trackerは(起動モードによるが)120秒以上測位できていなかったら、LocationListenerを再登録している

2011-08-25

[]別プロセスで動作させているServiceでGPSを使う方法

android:process=":remote"なServiceではGPS(LocationManager)を利用できない - DenkiYagiの解決編。

現象

プロセスで動作させているService(AndroidManifestでandroid:process=":remote"のように指定しているService)で、GPSを使おうとすると(LocationManager.requestLocationUpdates()をコールすると)エラーが発生する。LogCatには以下のようなエラーが表示される。

*** Uncaught remote exception!  (Exceptions are not yet supported across processes.)
java.lang.RuntimeException: Can't create handler inside thread that has not called Looper.prepare()

解決方法

プロセスで動作させるときは明示的にLooperを指定してあげないといけないらしい。

Looper looper = Looper.getMainLooper();
locationManager.requestLocationUpdates(LocationManager.GPS_PROVIDER, MIN_TIME, 0, listener, looper);