ScalaJP の Gitter がオープンしました

ScalaJP のメーリングリストでも流れていますが、 Gitter という Github と連携して使えるチャットサービスを利用して、Scala の日本語チャットルームができました。(kawachi さんが作ったのかな?)すでに 60 人くらい参加しているようです。

https://gitter.im/scalajp/public

Gitter → Twitter

Gitter に常駐するのがだるい人用に Twitter bot を作りました。

押そう→

Gitter で発言すると

f:id:tototoshi:20141004134531p:plain

Twitter に流れます。

Gitter の無料プランは 2 週間しか履歴が保存されないのですが、 Twitter に全部垂れ流すことで解決されました。Twitter はストレージサービスだったんだ!すごい!!

Twitter → Gitter

bot を作ったら Gitter のメッセージじゃなくてこの bot に返信してしまいそうになったので、 いっそのことこの bot にリプライすることで、Twitter から Gitter に投稿できるようにしてしまえ!となりました。

↑ のツイートは

f:id:tototoshi:20141004134217p:plain

↑ こんな感じで Gitter に流れます。

これで Gitter ⇄ Twitter の双方向のやりとりが可能になりましたが、 もしかして Gitter いらなくて全部 Twitter で良かったのではって感じがしてきました!

ともあれ、なにか質問を投げるとどこからか人が湧いてきて回答してくれる便利サービスになっているのでご活用ください。無料です。

ScalaMatsuri の運営に参加した感想

ScalaMatsuri の運営やってみての感想を書いておきます。そろそろ振り返りのミーティングもあるし。 ScalaMatsuri は体調のせいでほぼ参加できなかったので感想ありません(悲)。

ScalaMatsuri の意義について

今年 400 人も集まってしまったのは、オダスキーパワーですが、とはいえもう Scala の認知度はそれなりに上がってきていて、あとは使いたい人は勝手に使い始める段階に来ています。普及活動を目的とした ScalaMatsuri はもう意味がないのかなと思いました。実際会場に来ていた人の中でも業務で使っている人が多かったようです。

お堅い SIer でも普及させたいとか「ラムダがわからないおっさんに使ってもらうには?」みたいなのは会社や個人個人の都合がでかすぎるし、ScalaMatsuri としてそこに切り込んでいく必要はない、というか無理があると思いました。

...というのは割とこじつけかもしれない。一番の問題は自分に「Scala を普及させたい!」という気持ちがさほどない...

個人的には ScalaMatsuri の意義は、とにかく年1回カンファレンスを開いて盛り上がってる感を演出したり、コミュニティに刺激を与えること。Scala の普及とかは刺激を受けた人が自発的に勉強会始める、とかに任せたいです。(なぜならめんどうだから)

英語について

ScalaMatsuri は海外との交流を目的の1つとしてはいますが、それは英語をしゃべることを意味しないと思っています。 ScalaMatsuri の運営の中では英語を推奨する声が多数ですけど、自分は英語には興味はなくもっと Scala のほうを楽しみたいです。 英語の壁を取り去りたいという思惑が強すぎて、逆に英語を意識するようなイベントとなっていることは残念です。

イベントとしては同時通訳(できれば日本語英語双方向の)があれば解決する話。くよくよするな金で解決しろ。

リモートからの運営参加

準備ミーティングは体調の都合上リモート参加が多かったのですが、それほど困ることはありませんでした。 「来れない人はリモート」ではなく「基本リモートで、来れる人は現地に」という建前にしてもっと地方から協力してくれる方を増やしたいです。

その他

カンファレンスでのユニバーサル・アクセスへ向けて | eed3si9n Scala祭と日本のScalaコミュニティ - scalaとか・・・

だいたい同意です。

全体として

運営として、どのようなイベントにしたいか、というのはあるにしても、それよりもカンファレンスを楽しんでもらうことを優先したいです。

あと健康は大事です!

退院しました

退院ヤッター!

普段あまり医療のお世話にならずニュースとかだけで医療に接していると、すごいなあ最近の医療は進歩しているなあと思うけれど、実際入院して見るとそうでもないですね。腸の状態とか内視鏡入れなくてもわかるようになってて欲しいとか思うけどそんなことはなかった。

病院内は医師看護師さんがバタバタ動いてて血を抜いたり点滴変えて回ったり老人あやしたりしてました。医療はなにかすごいマジカルな仕組みで動いてるとかではなく、マンパワー&エンジニアリングだなと思いました。

病院と同じように Web サービスもぱっと見すごそうでも、魔法ではなく中の人のがんばりによって支えられているわけで、病院に失望したというわけではなく、医療従事者の方々に仲間意識のようなものを感じるとともに、世の中そんなもんですよねって思ったということです。

んなことより寿司食いたい。

入院しています

9/1から入院しています。 各方面ご迷惑をおかけしております。申し訳ありません。

ゴールデンウィークのころからお腹の調子が悪く、腹痛と下痢、血便で困っていました。近所の病院(代々木病院)に通っていたのですが、なかなか改善せず、代々木病院も全然話を聞かないひどい医者だったので、見切りを付けて別の病院に行ったところ、一瞬で大学病院送りとなりました。

内視鏡検査の結果、大腸の始まりと終わりの部分、2/3くらいが炎症を起こしており、潰瘍ができていました。 薬をもらって経過観察となりましたが、なかなか回復せず、検査入院ということで入院し、潰瘍性大腸炎と診断されました。検査入院で入院したんですが、いつのまにか治療モードになっていて、いや治療と言っても薬飲んで寝てるだけなんですがまだ退院できてません…

潰瘍性大腸炎については各自ぐぐって、めんどくさそう…と思っていただければと思います。 私から提供できる有用情報は

  • 健康は大事
  • お腹痛い人は変なのが出てきたらとっとと病院に行け
  • 緊急でない入院は高額療養費制度を考えると月をまたがないほうが良い
  • 関東ITS健保は高額療養費制度に一部負担還元金なるものがついてオトクっぽい

といったところです。

入院って暇ですね...

YAPC 2日目に行ってきました

YAPC初めて行きました。

1日目も行きたかったんだけど、諸事情(2つ前のエントリ参照)により来週から入院することになってしまい、ドタバタしたため行けませんでした。2日目も午後から参加です。PHP のやつ聞きたかったけど残念。

一番良かったのは Github の Andy さんによる「Changing the tires on a moving car: a case study in upgrading legacy architecture」。自分も仕事で最近はずっと古いシステムからの移行をやっているので、どこも大変だな〜と共感できるだけでも良かったです。サービスが大きくなるにつれてアーキテクチャを変えて行くのは難しいけれど Web エンジニアとしてはやりがいのある仕事だと思います。

後から考えてみると Grit から Rugged への移行で RPC を監視しているという話がいまいちわからないような。。。静的な解析ではだめなんだろうか?

あとこのセッションは同時通訳のクオリティに驚きました。専門性が高いテーマでもできちゃうんですね。

「モバイルアプリとAPIのありかたを考える2014」とか「Mobile Application Development for Perl Mongers」とか見たせいか、全体として Android/iOS のモバイルに移る Web エンジニアが増えたなという印象が強く残りました。自分も Java は書けるんだしそろそろ Android くらいには手を出しとこうかという気分になりました。

「趣味開発のためのクラウド/VPS活用術」もよくある話ではあるけれど実際に使ってみた結果としての各サービスの比較はあまりないので参考になりました。どうでもいいけどスポンサーに Conoha 並んでるのに Conoha の話が全然出てこないのがドキドキしました。

悪かった点としては席が全然足りていなかったこと。4並列でやっていたら偏りが出て座れない部屋が出るのは当然としても足りなすぎでした。最後のほう2時間くらいはずっと立ちっぱなしになり、体調も悪かったので途中で帰りました。1300人以上の参加者に対して藤原洋記念ホールのキャパ500人は少なすぎると思います。

それから YAPC ASIA というイベント名なのに、壊れた自撮りグッズのことをチャイナクオリティと言ったおっさんには不快感を覚えました。フィリピンの女性がうんぬんも場所によったらアウトでしょうね。

主に体調が悪いせいであまり楽しめなかったけれど、トークのクオリティは全体的に高くて面白いし、エンジニアが大量にいるのはそれだけで面白いので来年は全参加したいです。

YAPC運営・スピーカー・参加者の皆様お疲れ様でした。

「メンテナンス大変なのでサービス閉じたいです」

Web サービスの会社にはイケイケなサービスの陰に隠れて、かつてイケイケだったけど今はイケテナイサービス、とか、ぶっちゃけ最初っからあんまりやる気なかった☆サービス、これどこで拾ってきちゃったのサービス、などなど、惰性で続いちゃってるようなサービスがごろごろあったりします。

そういうイケテナイサービス群はメンテナンスの手間を取らせる物なので、エンジニアとしては閉じてしまいたい。でも非エンジニアとしては閉じたくない。いや、本当は閉じたい!でもちょっとは儲かってるし、閉じるとわずかながら存在するユーザーからクレームくるし、連携先の企業とやりとりするのめんどいし、まあいろいろめんどうそう。

そこで、「イケテナイサービスにはできる限りメンテナンスの手間を払うな」という話がエンジニアのとこにきて「お前なーっ!そのメンテナンスの手間がなーっ!」となり、話がループを始めます。なぜこういう噛み合わない話になってしまうのか。

エンジニアがメンテナンスの大変さを説明するのに「フレームワークのバージョンアップとか大変なんですよー」とか言っても、非エンジニアは「ふーん、そうなんだ(無理にバージョンアップしなければ良いんじゃね?)」とか思ってそうです。自分エンジニアだからわからないけど多分そう。

エンジニアは「Webサービスは(言語・ライブラリ・関連しているサービスの影響などで)メンテナンスしないと壊れる。」などと思っているのに対して、非エンジニアはなんとなく「ほっとけば動いてそう。」と思ってる気がします。

なので、最近は「メンテナンス大変なんですよー」じゃなくて「ほっとくと壊れるんですよー」とかよく言ってます。なにか他にもっと気の利いた言い方あります?

WEB+DB Press 82 に PHP の記事を書きました

WEB+DB PRESS Vol.82

WEB+DB PRESS Vol.82

  • 作者: 山口徹,Jxck,佐々木大輔,横路隆,加来純一,山本伶,大平武志,米川健一,坂本登史文,若原祥正,和久田龍,平栗遵宜,伊藤直也,佐藤太一,高橋俊幸,海野弘成,五嶋壮晃,佐藤歩,吉村総一郎,橋本翔,舘野祐一,中島聡,渡邊恵太,はまちや2,竹原,河合宜文,WEB+DB PRESS編集部
  • 出版社/メーカー: 技術評論社
  • 発売日: 2014/08/23
  • メディア: 大型本
  • この商品を含むブログを見る

8月23日発売の WEB+DB Press 82 で PHP の記事を書きました。

大規模な PHP プロジェクトをどうやって安全に、というか事故らずに運用していくかという視点で書きました。まあそんなの無理なんで、内容としてはかなり保守的に見えるかもしれません。イケイケ PHP プログラマは嫌がるのかな、わからん、とか思って書きました。

大規模になってくると、もう PHP がどうとかそういう大変さよりは、負荷が...ストレージが...コネクションが...とかのパフォーマンス問題や、あっ、PCサイトバグってる、よし直した、あっ、iPhone アプリ...し、死んでる!!みたいなマルチデバイス対応の辛さ、などなどばかりで、あまり PHP 関係ないんじゃないかな、と思うんですが、そう思って原稿書いてたら「なんか PHP の連載なのに PHP のこと書いてないですね」「ですよねー!!」となり、頑張って PHP のことも書きました。

特徴的な点としては、PhpStorm について詳しめに書いていることでしょうか。それから最近の弊社開発チームでの取り組みなどについても少し書いてあって面白いと思います。

ところで、書いてる途中、お腹痛いなーと思ってたら腸に穴が空いていました。お尻から血が噴き出して、死ぬのかな?って思いました。やっぱ PHP 体に悪いのかな...ちなみにまだ治ってません。

ということで、WEB+DB Press 82 買ってください。10 冊買っても内視鏡検査より安い。なんてこった。