なんか会社のチャットネタが続きますが、先月、会社のチャットでマクドナルドの衰退と吉野家のリンクから最適化の話しになり、「もしトレタが最適化しすぎると、どういう風に発展の妨げになるんでしょう」って話しが出てちょっと面白かったのでブログにまとめて見ることにしました。 私がアプリ開発で一番怖いと思うのは、既存ユーザへの最適化です。
Posts Categorized: Products
チャットで勤怠管理する「みやもとさん」をリリースしました
トレタで使っている、チャットで勤怠管理する「みやもとさん」をオープンソースでリリースしました。 https://github.com/masuidrive/miyamoto Slackの#timesheetsという部屋で、「おはようございます」と書き込みと出勤が記録され、「お疲れまでした」と書き込むことで退勤となります。「明日はお休みさせて頂きます」と書き込むと、休暇の届け出になります。 チャットで勤怠管理する最大のメリットは、オフィスに居なくても誰がいつ出勤・退勤したのか全員が分かることにあります。出退勤管理アプリは色々出ていますが、営業で直行直帰する人や、リモートワーカーなどは、帰った時間がリアルタイムでわかりにくいという欠点があります。 「みやもとさん」では、チャットでやりとりする事でみんなの見える形で出退勤が記録され「あ、帰る前にあれも!」など、ありがちなコミュニケーションがスムーズに行えるようになります。 出退勤のあいさつの判定はかなり幅を持たせているので、みんなが色々なあいさつを試して遊んでいますし、みやもとさんの返事のメッセージも色々変な答えをするようにして、人間味を出すようにしています。 このスクリプトは、Google Apps Script(Javascript)で動いていますので、一人だけGoogleアカウントを持っていれば、サーバを借りることなく無料で運用できます。 設置方法などは、https://github.com/masuidrive/miyamoto を参照してください。現在はSlack用ですが、アダプタを書くことで他のチャットにも多分対応できます。 トレタのチャットの活用法については、弊社中村の記事も合わせてご覧下さい。 なぜチャットで勤怠管理なのか トレタでは、情報ハブ的なツールとして全社でSlackを導入しています。 もともと、別のチャットを使っていたのですが、スマホ版を含めたUIと、さまざまなツールとの連携が容易に行えるということで、夏に移行しました。最大の問題は英語のUIですが、思ったより抵抗感なく移行することができました。 Slackへ移行後は、辛口の人工無能「高橋」を作り、走らせて遊んでいました。 これはこれで社内で大ウケだったのですが、無意味なbotではなくトレタらしいChatOpsを作りたいなと思っていました。 社内システムには多くの課題があるのですが、その一つに勤怠管理がありました。営業の人が直行直帰したり、エンジニアが在宅業務するので、リモートで管理できる必要があります。 いくつかのiOSアプリなどを試したのですが、出勤退勤を押し忘れたり、修正には上司のアカウントが必要だったりと手間がかかり、なかなか定着しませんでした。 どこに居ても全社員必ずチャットは毎日使うため、チャットで「おはようございます」と書き込むと出勤扱いにすれば良いのではないかと思い、hubotで早速作り始めました。 とりあえず、動くモノはすぐできたのですが、日数の集計などを考えると管理側を作るのが、かなり面倒です。 そこで、データはGoogle Spreadsheetに書き出す様にしてみました。そうしているうちに、Google Apps ScriptでWebサーバを書き、SlackのWebhooksで通信すれば別途サーバを用意する必要がないことに気がつき、Google Apps Scriptで書き直しました。 これで9月から社内で勤怠管理として1ヶ月ぐらいつかっていますが、右の様に社内でも評判のツールとなっています。返答は顔文字を使ってユルい感じで返すようにすることで、みんな親しみを持ってくれています。 現在はSlack用として動いていますが、API部分は分離してあるので、他のチャットでもWebhooks的なモノがあれば、簡単に移植することができます。もし他のチャットに移植してくれる人がいたら非常にうれしいです。 今後の開発としては、月次の出勤日数や有給の管理、休み時間の登録などを予定しています。コレがないと社内的に困るので。 トレタ社内ツール トレタでは、「みやもとさん」以外にも、日々の統計処理などでGoogle Apps Scriptを利用しています。社内で使うツールはGoogle Apps ScriptとSpreadsheetの組み合わせがかなり便利です。各種データはBigQueryに入れており、統計情報はここから取り出す事で、管理画面を作り込むことなく柔軟にデータをみることができるようになっています。 このようなツール以外にも、社内の文化をシステム方面からも構築していくため、日報システムを始め、色々なツールを内製しています。 こんな環境で、アプリを作ってみたい方をトレタでは探しています。興味のある方は、まずはランチでも食べにきてみませんか? → ランチ申し込み トレタはITと少し離れた分野にITを届けて、働いている人にもお客さんにも幸せになってもらうシステムを作っています。そのためには社内のシステムも気持ちよく使えるモノをと考えています。 この「みやもとさん」が多くの場所で使ってもらえ、すこしでも便利だなと思って頂けたら幸いです。
4/1のスクー 「wri.peの作り方」で拾いきれなかった質問
4/1のスクー増井雄一郎の「wri.pe」を事例に学ぶ、自作サービスの作り方〜サービスデザイン編に参加頂いた方々ありがとうございましたー。 次回は4/8 21:00〜、もっと技術的な話しをする予定です。こちらも引き続きよろしくお願いします。 wri.peのソースコードを公開したので、先にこちらも見ておいて貰えると、より分かりやすいかも知れません。 人前での講演は多いのですがカメラの前で話した事はほとんどないため、結構緊張しました。後日公開されるビデオは自分では見たくないな・・・w デザインがらみで一つ紹介し忘れたのですが、色を決めるときはCOLOURloversを使っています。 質問をいろいろ頂いたのに授業内で答えられなかったものもあったので、ブログでお答えしたいと思います。
4/1のスクーでwri.peの作り方全公開
オンライン講座のschooで、4/1から4週にわたってwri.peを題材に「個人サービスをどうやって作るか」という話しをします。 コードの話しだけでなく、サービス設計や運用、広報も含め、個人サービスをどうやって作るのかを解説します。 無料ですので、興味のある方はここから登録してください。よろしくお願いしまーす。
プロにwri.peのデザインの駄目出しをしてもらう
wri.peのデザインは自分で作ったのですが、デザインのプロから見ると直すところは多々あるんじゃないかと思って、ミイルを一緒に作ったフォーユーの金田さんにデザインの駄目出しをしてもらいました。 まず第一に指摘されたのは、ターゲットユーザをどこに定めるかという話。エンジニアなどをターゲットにするか、一般ユーザをターゲットにするか。 wri.peは「自分用ツール」が起点なので、エンジニアなどPCやテキストに慣れている人をメインターゲットにして行こうと思っています。それであれば基本的なデザインはこの方向で良いとの事でした。
個人でメモ帳アプリ wri.pe リリースしてみました。
この1年間、ミイルとMobiRubyをコツコツと作っていて、個人としてWebサービス的なものを全く作っていなかったので、 気分転換 とRails4 + Ruby2.0のテストを兼ねて自分用に メモ帳サービス を作って wri.peとして公開しました。 私が使いたいメモ帳の要件は、こんな感じでした。 markdownをサポート gmailの様なアーカイブ機能 全文検索 カレンダーへのマッピング iPhone / iPadをサポート キーボードで操作ができる いままで色々なメモ帳サービスを使って見たのですが、どれもしっくりきませんでした。私はメモをtodo的に使うことが多いので、終わったタスクをアーカイブしたり、文章内に書いている日付でカレンダーに表示する機能は非常に欲しい機能でした。
PukiWikiの再構築
「PukiWiki の開発プロジェクトの再建案 – Sarabande.jp」を読み、プロジェクトの発起人としてちょっと書いてみることにしました。 私もPukiWikiプロジェクトが止まっている事は前から認識をしており、どきどき他の方からも相談を受けていました。 未だに多くのユーザもいますし、強力な代替がないのでPukiWikiの再出発を願う人も多くいるとおもいます。しかし、私ももう8年ぐらいPHPでコードも書いていなく、私自身はPukiWikiに手を入れるモチベーションが出てきませんでした。 このPukiWikiの問題は二つの側面があります。 PukiWikiというアプリの停滞と、PukiWikiプロジェクトの崩壊です。
MobiRubyが生き延びる為には
昨年の3月から開発を始めたMobiRubyは、まだ開発途中で多くの方々に使って頂ける状態ではないにも関わらず、福岡Ruby大賞のポストPC賞と、日本OSS奨励賞を頂くことが出来ました。多くの方が応援してくださった事で、受賞できたのだと思います。ありがとうございます! 当初の予定より時間は掛かっていますが開発は順調に進んでおり、ObjCとCocoaを使えれば何とかiOSのアプリを書けるようになりました。開発をこのまま進め、ObjCやCocoaの知識がなくてもRubyを使って、気軽にiOSやAndroidのアプリ構築を行えるツールにしたいと考えています。
EventMachineの速度が安定しない[解決]
Photo by the_amanda PhotoShareをRailsから、EventMachineベースの自作フレームワークに全面書き換えをしているのですが、大体作り終わりベンチマークを取っていると、概ね1msで処理しているのに、時々、数百ms掛かることがありました。 初めはGCとか疑ったんですが、GC.disable実行しても状況変わらず。絞り込みをしていると、どうもEventMachineで詰まって居るっぽい。 EC2上で動かしていたので、手元のマシンで試したり、LinuxじゃなくてFreeBSDで試しても同じように詰まる。同じEventMachineを使っているThinを使って、ベンチマーク取ってみても、100回に1回ぐらい、やたらレスポンスが遅い時間があるのを確認できました。 ApacheBenchやhttperfは、平均値は取れるけど、個別のレスポンスタイムを出力する方法が見つからなかったので、JMeterに初挑戦。HTTPだけじゃなくて、いろいろなプロトコルに対応しているのがいいね。 色々試してみると、HTTPに限らずTCPソケットサーバを作ると発生するらしく、こんなコードでも、1000回に1,2回、接続した後1000ms近く待たされることがあることが分かりました。 MLとか探しても、同じような現象の話が出てきていない・・・。探し方が悪いのか、じつは誰もあまりまじめに使ってないのか・・・・。 ここら辺まで原因がつかめたところで、takiuchi先生にご相談。 結局カーネルまで追って、変にselectを呼び出して居ることが判明。takiuchi先生さすが! 自分もカーネルとか追うように色々準備しておかないと駄目だなと反省。 このコードを元に検索してみると、迷ったりしていることは分かったけど、このパッチを当てると、接続が詰まる状況が改善。 ここ以外にも、微妙なコードが見られるので、引き続きコードを追ってみよう。 年末の忙しい時期なのに、手伝ってくれてありがとうございました!>takiuchi先生
Webでの非同期処理を考えてみる [長い記事だけどコメント求む!]
Photo by harry harris いまPhotoShareのサーバの実装を大きく変えようとして悩んでいます。 (参考: Life is beautiful: マルチスレッド・プログラミングの落とし穴、その2) Rails 2.2でThread safeになるとか、NeverBlockで12倍速くなるっていう話もあるんだけど、負荷が上がればレスポンスが悪くなるのは、どうしようもない。マシンを増やせば解決できる部分もあるけど、マシンを増やせばコストは上がる。 Life is beautifulで書かれていますが、確かに全部の処理を同期的に行う必要はないんですよね。 PhotoShareでも、既にいくつかのページは非同期にerbを生成して、それをRailsとerubisで読み込んで実行しています。 しかし、Railsだけではこういった非同期の処理やviewの一部を事前に生成するという処理ができないので、この処理は別途プラグインを作って実現しています。 高速化の為にはキャッシュを使おう Railsで高速化を考えていくと、特にキャッシュが重要になります。たとえばブログエンジンで、RSS Feedを生成するアクションがあったとします。