第３回、合同勉強会を開催しました

はじめまして。技術チームのガブです。先日、第三回合同勉強会を弊社オフィスにて行いました。ビールやソフトドリンクを飲みながら、六名のすばらしいエンジニアの方々から、高度にテクニカルなお話を二十分間、楽しく伺うことができました。発表者の皆様を始め、今回の勉強会のために貴重なお時間と労力を割いていただいた方々に深く感謝いたします。

各プレゼンの模様を簡単にご紹介いたします。

1. 今村 雅幸 (株式会社Vasily CTO)さん

今村さんには、急増するユーザーに対応するべく、アプリケーションをスケールするテクニックをテーマに講演していただきました。やはり、VasilyのようなBtoCの場合、ID数の増加が急激すぎてやばいですね。スライドを見ていてゾクゾクしました。僕たちも早く新しいサービスでこんな悲鳴を上げてみたいです。ちなみにVasilyさんの場合、tumblrのinboxモデルを参考に独自の実装をされていました。tumblrのarchitectureについてはこの記事なんかが参考になります。

2. 林 孝之さん

林さんには今回、ごく少数の人に知識や情報が集中せずに生産性を上げていく一つの解として、ペアプログラミングについて発表していただきました。
僕は今、実際にペアプロをやっていますが自分で書いたコードよりも明らかに美しく、読みやすく、バグの少ないコードを書く事が出来ています。林さんがプレゼン中に言っていた、「ペアプロじゃないと怖くてコードを書けない」という事を実感します。一方で、相方とのスキル差が絶望的にあり（僕が低い方です... )、とても疲れるし、理解できていないまま進んでいってしまう時があります。この辺りの課題をどうするか、林さんに改めて質問してみたいなと思います。

3. 津留 一仁 (株式会社マインドパレット リベロエンジニア)さん

津留さんにはAngularJSの特徴、ユースケースについて、プレゼンしていただきました。
Gitコマンドをバシバシ叩きながら、分かりやすいサンプルデモをいくつも交えて発表していただき、（皆さんに共通しますが）とてもイメージしやすく素敵なプレゼンでした。
AngularJSはHTMLそのものがテンプレートである事や、パイプラインで検索フィルターを追加できる事（すごく簡単そう）など、簡単に始められて便利な機能満載。開発していて楽しい感じが伝わってきて思わずダウンロードしてしまいました。

4. 竹内 秀行(ユーザベース)さん

竹内さんのトピックは、みんな大好きDynamoDBの解説です。前々回、株式会社マインドパレットの神尾さんにSimpleDBの恐ろしさを存分に教えていただいた僕たちは、「SimpleDB、ダメ、ゼッタイ」を合い言葉にDynamoDBを採用する事にしました。そんな訳で今回、DynamoDBの素晴らしさを皆さんにお披露目する場になりました。例えば、DynamoDBのキャッチフレーズの一つに「支払いは実際に使用した分だけ。最低料金は不要です。」というものがあります。素晴らしい！さすがAmazon先生！ところが実際の料金プランを見ていくと、事前に利用枠を買って使うというこの矛盾！世の中そんなに単純じゃないんだぜ！という先生からのメッセージを胸に、僕たちはまた一つ大人になったのでした。

5. 加藤じゅんいち(id:j5ik2o)さん

加藤じゅんいちさんは、Domain Driven Design(DDD)について、お話していただきました。最近、僕の入っているプロジェクトではTDDを始めていますが、DDDの基本的な考え方であるドメインモデルを中心に設計していけるとコードがすごくキレイになります。抽象化と共通化が適切にできる事に感動するとともに、今まで自分が書いたものは何だったのかと小一時間(ry
ただ、まだまだプレゼンしてもらった世界には全然到達できていないので、ご推薦の本を買って読もうと思います。

6. 矢野勉 (代表取締役　株式会社シェルフ)さん

Lispには括弧が多すぎる。

矢野さんのプレゼンはそんな風にして始まりました。
そうしてClojureをおもしろおかしく説明した後で、唐突に矢野さんは言いました。
「これで皆さんは明日からClojureが書けますね。もう知らないなんて言えないですよ」
動揺する会場。微笑みの矢野さん。
会場からの「結局、括弧多くないですかClojure」「そのサービス、Railsならすぐ作れるんじゃないですか（Clojure生産性低くないですか）」という優しいコメントに矢野さんは「括弧の種類がいっぱいあれば読みやすいから問題ない！」、「Javaの資産がそのまま使えるから生産性は超高い！」とClojureへの愛とモヒカンぶりを遺憾なく発揮し、万雷の拍手を浴びておりました。
僕はそんなロックな矢野さんが大好きです！

上記のメインプレゼンの間に、懇親会とライトニングトーク大会も行いました。
板倉さん、荒井さん(Vasily)、長澤さん(UB)、石橋さん(UB)、加藤さん(UB)にLTを行っていただきました。

次回、第４回合同勉強会は10月頃に行う予定です。

ご興味のある方は是非ご参加ください。スピーカーの方も大募集中です。

連絡先はこちらです：technology@uzabase.com

世界最大の素数とその見つけられた方法

こんにちは。
LTにて、ほかの方は最新技術など面白いものを紹介してくださるので
私はあさっての方向の紹介を担当しようと思います。

素数について from szilkworm

ユークリッドの補題

スライドの中で何の断りもなく登場することの補題ですが、意味は

正の自然数nが素数pで割り切れ
n = ab (a > 1, b > 1)と分解できるとき、pはa, bの内の少なくとも一方を割り切る。

というものです。

「0がn個続いたあと1がn個続く」を正規表現にできるか?

こんにちは。前回に引き続きたぬきです。
週次LTの担当ということで、計算機科学の基礎を紹介してみました。

「0がn個続いたあと1がn個続く」を正規表現にできるか? from tanukingUb

切り口として、正規表現まわりをやってみることにしました。Uzabaseは情報プラットフォームサービスSPEEDAを展開しており、どのエンジニアもデータベース周りの知識を持っているため、正規表現は慣れ親しんだものの１つであるからです。

具体的な問題として、「0がn個続いたあとに1がn個続く」を正規表現にできるか？をテーマとしました。

お話の流れとしては、(1) 正規表現は有限オートマトンに変換可能、(2) 有限オートマトンには必要条件がある、(3) 上述の問題は有限オートマトンの必要条件を満たさず、正規表現にはできない、という流れです。

ポンピング補題

オートマトンの復習および「(1) 正規表現は有限オートマトンに変換可能」については、文章よりスライドを見てもらえば十分かと思いますが、「(2) 有限オートマトンには必要条件がある」「(3) 上述の問題は有限オートマトンの必要条件を満たさず、正規表現にはできない」については口頭で話した部分を補足したいと思います。

(2) 有限オートマトンの必要条件のひとつに、ポンピング補題というものがあります。ある有限オートマトンの状態数をpとすると、そのオートマトンに認識される（受領される）文字列のうちp以上の長さの文字列は必ずポンピング補題の3条件を満たします。

条件のうちの1番目「各i≧0についてx(y^i)z∈A」についてもう少し意味を補足しましょう。まずAはある有限オートマトンが認識する（受領する）文字列の集合です。また、x(y^i)zとは、文字列xの後に文字列yが0回以上繰り返し続き、最後に文字列zがあるということです。つまり、1番目の条件は、ある有限オートマトンに認識される文字列は必ず、x(y^i)z∈Aを満たす文字列x, y, zにわけられるという意味になります。

ポンピング補題の証明は、スライドに記述した迷路のような図でも直感的に理解できるかもしれませんが、より詳しい証明は後述の本を御覧ください。

さて(3)に入り、「0がn個続いたあとに1がn個続く」がポンピング補題を満たすか調べてみましょう。もし「0がn個……」を満たす有限オートマトンがあるとすれば、その条件を満たす文字列で長さp以上のものはすべてポンピング補題を満たすはずです。

ここで、0がp個続いたあとに1がp個続く文字列sを考えてみましょう。sは明らかに「0がn個……」を満たします。またsは長さp以上なのでポンピング補題も満たすはずです。つまり「各i≧0についてx(y^i)z∈A」も満たすはずですが、どんなyならばそんな条件を満たすでしょうか？

実はその条件を満たすyは存在しません。もしyが0からだけ成るとすると、i≧2では文字列に含まれる1の数よりも0の数が多くなってしまい、Aに含まれることができません。yが1からだけ成るとしても同様です。あとはyが0と1から成った場合だけですが、この場合、yが連続すれば0の前に1が出てきてしまうため、やはりAに含まれることができません。よって、いかなるyも条件を満たしません。

以上のことから背理法により、「0がn個……」は有限オートマトンでないことが示されました。よって「0がn個……」は正規表現にできません。

まとめ

LTの時間的な制約から正確な定義などを説明せずに話を進めてしまいましたが、正確な定義や証明を理解していくと、とてもシンプルかつ奥深い世界に触れることができます。スライド内でも簡単に紹介していますが、下記の本がオススメです。

計算理論の基礎 [原著第2版] 1.オートマトンと言語

第二回、合同勉強会を開催しました

はじめまして。
技術チームのたぬきです。

先日、外部の方をお招きしての合同勉強会の2回目を、弊社オフィスで行いました。
社内外から5名のスピーカーにご登壇いただきました。

今回はオーディエンスとしても社外の方が参加してくださいました。
前回ご登壇いただいた株式会社マインドパレットの神尾さんは社内の方と4名でご参加、アイエント株式会社の西王地さん、某巨大BtoCサービスインフラチームリーダーのMr. Xさん（大人の事情でご紹介できません）にも来ていただけました。
だんだんと勉強会らしくなってきていますね！

以下、プレゼン資料と当日の様子を御覧ください。

1. Hazelbeck Gregory（ユーザベース）
Wikipediaのダンプデータとそれを使えるサービスについて。自然言語処理で博士論文を書いたGregさんの本領発揮といったプレゼンでした。

Wikipedia解析 from ghazel7

2. 西川真五さん（株式会社エムティーアイ）
アジャイル開発手法のひとつscrumについて、実際に運用されている経験と共に説明していただけました。

3. 川口浩司（ユーザベース）
前職で扱っていたXMLデータベースについて良いところ・悪いところを詳しく解説。川口さんが一線でやってきた内容だけあって、現実感がよくわかる内容でした。

XMLデータベースについて from Koji Kawaguchi

4. ????さん（某大手ITコンサルティング企業）
大人の事情で公開できません。が、とても未来的で興奮する内容でした。公開できないのが悔しい……。

5. 石橋隆平（ユーザベース）
コードの再利用について、あるべきと、どうしてそれができないか、どうすればできるかを解説。石橋さんのダークな部分がチラリ。

勉強会の後は、同じ会場でピザやお寿司をいただきながらのライトニングトーク大会！
技術的に面白い話も、☓☓的に面白い話もたくさんで、とても盛り上がりました。弊社チーフテクノロジストのたけうちさんは大富豪プログラミングについて発表。

Web時代の大富豪的プログラミングのススメ from Hideyuki Takeuchi

本人注）当たり前のことを大まじめに酒の席でのたまわるというLTです

ユーザベース技術チームでは今後も定期的に勉強会を行います。
ちょっと聞いてみたい、と思った方はお気軽にご連絡下さい。
もちろんスピーカーとして来ていただける方も大歓迎です。

連絡先はこちら：　technology@uzabase.com

次回は6月くらい……かな？

Ractive Programming

chimerastです。

週次LTの担当ということで、Reactive Programmingというパラダイムについて紹介しました。

Reactive Programming from Hideyuki Takeuchi

今流行りの関数型プログラミング言語では、Reactive ProgrammingというとFRP (Functional Reactive Programming)の事を指すことが多いのですが、そっちの説明を始めると若干複雑で前提として必要な知識も多くなるので、大元にある考え方にのみ焦点を当てました。

Reactive Programmingとは

JavaやRuby等の命令型プログラミング言語では

a = 10
c = a + 2
a = 1
print c

というようなプログラムがあった場合、12が出力されます。

これが、Reactive Programmingでは、cが出力される際にa+2という式が初めて評価され、3が出力されます（他の実装として、2行目ではちゃんとcに12を入れておいて、3行目のa = 1が実行されたときにcを再評価して3を代入するというものもあり得ます）。

現実にある実装

Reactive Programmingを体現した一番身近な言語（？）として、Excelがあります。

例えば、E1のセルに「=A1+A3」が入力されていたとして、A1やA3の値を変えると自動的にE1のセルも変わりますよね。

他にもFlexのMXMLにおけるデータバインディング式や、ちょっと違うかもしれませんがJavaFX(ScalaFX)もReactive Programmingが出来ると言っても良いと思います。

どういうところで便利か？

ロボット工学や、シミュレーション等いろいろと応用は効きますが、普通のプログラマにとっては上記のようにGUIプログラムで利用するというケースが一番効果が出やすいと思います。

例えば、コンボボックスが選択された時にその値に応じてテキストラベルを変えるようなプログラムをJavaもどきで書くと、

comboBox.addActionListener(new ActionListener() {
  public void actionPerformed(ActionEvent event) {
    label.text = indexToText(comboBox.index);
  }
}

というように長々と、何をやっているのか本質がぼやけてしまうプログラムとなってっしまいます。
これをReactive Programming的な書き方をすると、

label.text = indexToText(comboBox.index);

の１行で記述できてしまいます。読み方を知っていれば何をやりたいのかも非常に明確です。

これは非常に簡単な例ですが、入力に複数のコンボボックスが関わってきたり、連鎖的に複数のコンポーネントの値が変わるようなものを作る場合には、Java等で書くときとくらべて非常に簡潔に記述することが出来ます。

まとめ

Reactive Programmingを直接利用できる言語や環境はあまりないですが、この考え方を知っていると、データには流れがあるんだという事が理解でき、機能としてReactive Programmingを利用できないような言語でもプログラムの書き方が変わってくると思います。

コマンド実行結果のログ取得について

k-kawaguchiこと川口と申します。
Linux等でのコマンド実行結果のログ取得方法について、LTで発表しました。

コマンド実行結果のログ取得について from Koji Kawaguchi

ネットワークについて

k-kawaguchiこと川口と申します。
技術チーム定例社内研修会にて、ネットワークについて発表しました。

ネットワークについて from Koji Kawaguchi