組織も人も最適化の果てにあるのは緩やかな死
なんか会社のチャットネタが続きますが、先月、会社のチャットでマクドナルドの衰退と吉野家のリンクから最適化の話しになり、「もしトレタが最適化しすぎると、どういう風に発展の妨げになるんでしょう」って話しが出てちょっと面白かったのでブログにまとめて見ることにしました。 私がアプリ開発で一番怖いと思うのは、既存ユーザへの最適化です。 既存ユーザはある程度使いこなした上で「あの機能が欲しい」と要望を出してきます。確かにその機能があると便利ですし、他のユーザでも喜ぶ人が大勢います。 実際、その機能実装すると多くのユーザが便利になり満足度があがります。画面にボタンは増えましたが使わないユーザが不便に思うほどではありません。 誰も困らないし、この機能追加はとても正しいことに見えます。 でもその機能があることで、初めて触るユーザはどう感じるでしょうか？画面にボタンが多いほど、マニュアルが厚いほど初めてのユー
チャットで勤怠管理する「みやもとさん」をリリースしました
トレタで使っている、チャットで勤怠管理する「みやもとさん」をオープンソースでリリースしました。 https://github.com/masuidrive/miyamoto Slackの#timesheetsという部屋で、「おはようございます」と書き込みと出勤が記録され、「お疲れまでした」と書き込むことで退勤となります。「明日はお休みさせて頂きます」と書き込むと、休暇の届け出になります。 チャットで勤怠管理する最大のメリットは、オフィスに居なくても誰がいつ出勤・退勤したのか全員が分かることにあります。出退勤管理アプリは色々出ていますが、営業で直行直帰する人や、リモートワーカーなどは、帰った時間がリアルタイムでわかりにくいという欠点があります。 「みやもとさん」では、チャットでやりとりする事でみんなの見える形で出退勤が記録され「あ、帰る前にあれも！」など、ありがちなコミュニケーションがスムー
デブサミ2014で「エンジニアだからできる自由な生き方」の話をしてきました。
昨年の後半から、「エンジニアとしての生き方」のような話をする事があり、ずっと継続して考えてきました。 先日も「一生、エンジニアであり続けるために必要なこと(レポート)」という講演をしたのですが、実はその時点でもまだ自分で分からない部分がありました。 自分が「自由に生きたい」と思っている事は分かっていたのですが、「なぜ自由でいたいのか」という説明がうまくできなかったのです。自由は手段であり、得た自由を使って何をしたいのか、それが説明できませんでした。 漠然とは感じるんだけど、説明できないもどかしさをずっと感じていたのですが、デブサミの数日前、こんなツイートを見つけてやっと自分で納得できました。 @ukedchat @gapingvoid There’s one more image to this that you’re missing… creativity. @ElsiumEd pic.
WordPressをStaticPress+Amazon S3+Vagrantでセキュリティ万全にする方法 [前編] - @masuidrive blog
最近、大規模なWordPressのサイトの乗っ取りが発生しました。今回の原因はWordPressではなくサーバの設定に問題があったようですが、LAMPサーバの設定を正しく行うのは難しいですし、ApacheやPHP、WordPressのバージョンアップをきちんと行っていくのは、結構大変です。 自分でサーバを運用していて、セキュリティ対策をきちんとしていると言える人は、実はあまり多くないのでは無いでしょうか？プラグインなどを複数導入している場合には、それらのプラグインのセキュリティ対策を行うのはかなり難しいといえます。 そんな中、高セキュリティ環境でWordPressを運用する方法はないのか考えてみました。それにはサーバ上でアプリを動かさないのが一番では無いでしょうか？ 私のブログであれば、Voteなど動的な機能は使っていないので、WordPressのデータから静的なHTMLを生成して、Ama
![WordPressをStaticPress+Amazon S3+Vagrantでセキュリティ万全にする方法 [前編] - @masuidrive blog](https://cdn-ak-scissors.b.st-hatena.com/image/square/5c5c3e4330805bfc33fc80aa0e5843be18a0177d/height=288;version=1;width=512/http%3A%2F%2Ffarm1.staticflickr.com%2F6%2F5961468_60d27d4dde_m.jpg)
オープンソースで必要な英語力を調べてみた
最近、mrubyのIssuesを英語で書くのが厳しく、やっぱり英語は勉強しなきゃなと日々痛感しています。 勉強するにしても普通の英語とは違うので、Issueを英語で書くためにどれぐらいの単語力が必要なのか調べてみました。 GitHub上のmrubyとnodejsのIssuesをダウンロードして形態素解析をして、単語の頻度をグラフにしてみました。 ものすごく偏っていることがわかります。 ここから1000だけ切り出してみます。 これを見ると3-500でほとんど部分をカバーできそうです。固有名詞もあるからもっと少ないはず。 これをベースにして「300語で書くオープンソースの英語」とか出来ないかな？ あとは、Phrasal verbs(get into, put onみたいなヤツ) なんだけど、代表的な物を公開しているリストないかな？それもランキングできると面白そう。 なお、この単語数は形態素解析
iPad miniで持ち歩けるコーディング環境を作る
iPad mini + Cellularを朝一番から並んで買いました！軽くてLTEでネットが使えるということで、外に持ち歩き端末としてはApple史上最高な端末です。 しかし、私は出かけるときには常にコードを書ける環境を持って歩きたいので、結局MacbookProかAirを持って出かけることになってしまいます。 最近、MBP15に代えたのでちょっと持ち歩きが厳しいなと思っていたので、この際iPad miniでコードを書く環境を構築することにしました。 まずはキーボード。前に買ってあったrapoo E-6300をBluetoothで接続してみます。一発でつながったし、サイズ感も良い感じです。 蓋になる形のキーボードも出ているようですが、とりあえずE-6300で問題なさげ。 次にメインとなるエディタです。iPadでソースコードを書くのに適していて、Dropboxに対応しているエディタといえば、
Appceleratorを退職しました
2012/09/30を持ちまして、Appcelerator, Inc.(以下Appc)を退職しました。2010/12に入社して以来、Titanium Mobile(以下Ti)のエバンジェリストとして活動し、多くの方々にお世話になりました。この場を借りてお礼申し上げます。 私はAppcを離れますが、Appcに取って日本は世界で2番目に大きなコミュニティを持つ、大切な場所であることに変わりはありません。CEOのJeffやCOOのSandeepが先週来日し、その講演の中で日本のビジネスについても、近々発表すると話をしています。Jeffは海外のメディアによるインタビューの中でもAppcは今年、日本を含むAPAC地域に投資をする明言しており、これからも日本でのTiビジネスが加速していきます。 Tiは大変多くのユーザー支えられおり、各地でも有志によるイベントなどが開催されています。また先日、Titan
リビングにIKEAで作る2畳の快適仕事環境
予定では年内に、AppceleratorのHQのある、Mountain Viewに行く予定だったのですが、いろいろありまして、アメリカへ戻ることなく、しばらく日本で腰を据えることになりました。引き続き、日本でよろしくお願いします。 そこで東京でマンションを契約して、半年以上アメリカに置きっぱなしだった荷物を取り寄せることにしました。アメリカでの家具や家電はほとんど処分してきたので、また全部買い直しです・・・ orz 「IKEAと5万円で作る快適仕事場」が好評だったので、今度は日本バージョンで書いてみることにしました。前回と同じでリビングで快適に仕事をするための環境を作ることを目標にしています。予算も前回と同じぐらいな感じで。 リビングに机を置くため、家を探すときにも、都内でリビングが広い1LDKを中心に探しました。家探しについては、Togetter – 「@masuidrive / @ka
AmazonがMySQL 5.1をサービス化 – Amazon RDS
AmazonがAmazon RDSという、MySQL専用のインスタンスをサービス始めました。 これは、MySQL 5.1がセットアップしてあるインスタンスで、Small(1CPU, 1.7 GBメモリ)〜Quadruple Extra Large(26CPU, 68 GBメモリ)までスペックが提供されています、Smallは$0.11/時 ($81/月)か。Largeだと$0.44時で$327/月なので、通常のEC2よりはちょっと高めの様です。 EC2と違うのは、ネットワーク代は別でDBへ外部からアクセスした場合には、1GB辺り、Inは$0.10、Outは$0.10〜$0.17掛かります。 これ以外に、1GB辺り$0.1のストレージ代と、100万IOアクセス辺り$0.1の代がかかります。この辺はEBSと同じみたいですね。 アプリケーションからアクセスする場合、今までのMySQLと同じように見
Webでの非同期処理を考えてみる [長い記事だけどコメント求む!]
Photo by harry harris いまPhotoShareのサーバの実装を大きく変えようとして悩んでいます。 (参考: Life is beautiful: マルチスレッド・プログラミングの落とし穴、その２) Rails 2.2でThread safeになるとか、NeverBlockで12倍速くなるっていう話もあるんだけど、負荷が上がればレスポンスが悪くなるのは、どうしようもない。マシンを増やせば解決できる部分もあるけど、マシンを増やせばコストは上がる。 Life is beautifulで書かれていますが、確かに全部の処理を同期的に行う必要はないんですよね。 PhotoShareでも、既にいくつかのページは非同期にerbを生成して、それをRailsとerubisで読み込んで実行しています。 しかし、Railsだけではこういった非同期の処理やviewの一部を事前に生成するという処
![Webでの非同期処理を考えてみる [長い記事だけどコメント求む!]](https://cdn-ak-scissors.b.st-hatena.com/image/square/5bfe0ff7b7b40f7cbbbf772fcb58fe20116a468d/height=288;version=1;width=512/http%3A%2F%2Ffarm1.static.flickr.com%2F124%2F414124784_2ddd9e2e05_m.jpg)
RailsでMemcachedが落ちていてもエラーにならない方法
Photo by masuidrive76 Railsで高速化するためには、Memcachedによるキャッシュが欠かせないですが、もしmemcachedが落ちてしまうと、サービス全体でエラーが発生してしまうのが、気になるところでした。 Takiuchiさんと話をしていて、fiveruns-memcache-clientを使うことで、memcachedを再起動さえすれば自動で再接続されることはわかったのですが、やはりmemcachedが落ちている時はエラーになってしまうのが問題でした。 どうせ、キャッシュはキャッシュなのだから、memcachedが落ちている間はキャッシュを使わない様にするパッチをmemcache-clientに組み込もうと思って作業をしていたら、実はcache_fuにその機能があるのを発見しました。 config/memcached.ymlで、「raise_errors:
masuidrive on rails - RailsアプリをチューニングするならNew Relic RPM
Photo by Riverman72 あとで自分メモを書こうと思うけど、先に一言。 37signalsも使っているといううたい文句に惹かれて試してみた、Railsのパフォーマンス記録ツール/サービスNew Relic RPM(Rails Performance Management)が、すばらしい。 RPMは開発時用のDeveloperと、実機用のProductionのが二つあり、まだ開発時用のDeveloperモードしか試してはいないんだけど、専用の管理画面で、アクションを実行時のメソッド単位の実行時間、生成されるSQL、SQLの実行時間やインデックスの利用状況などが非常に簡単に把握できます。 Railsで開発している人なら、下のムービーを見れば、そのすごさが分かるはず。 RPM developerのデモ動画 | RPM production のデモ動画 いまこれを使って、PhotoS
mod_rails用のdeploy.rbとapache用設定ファイルジェネレータ
Railsで一番めんどくさかったアプリの公開を、Apache httpdが動いているサーバに、普通にアップロードするだけで行える様にするモジュール、mod_railsがリリースされました。 いままで似たようなものにmod_rubyがあったのですが、ずっとメンテナンスされていない上に、構造的にRailsには向かないようになっていたので、Phusion社が新しく作ったものです。 日本語での紹介はmoongiftさんの記事をご覧ください。インストール方法や使い方は、こちらの記事を参考にしてください。 このモジュールの評価が高まれば、レンタルサーバでもRailsサポートをしてくれる所が増えるんじゃないかと期待してます。 早速、自分のサーバ(EC2)に入れてみた所、特に問題もなくあっさり動きました。 ただ、Capistranoを使っている場合、mongrelの時のままだと、サーバの起動などで失敗する
[メモ] AmazonS3とEC2を使う時にはX-REPROXY-URL
S3+EC2を使っていると、S3に保存したムービーや画像と言った大きなデータを、クライアントに返したい場合があります。 そのときにリバースプロキシを使う方法もあるけど、権限やユーザによって振り分けたい場合などは、単純なリバースプロキシではうまくいきません。 Rails側でNet::HTTPなどを使ってS3からデータを取ってくる方法もあるのですが、それだとパフォーマンスが悪すぎです。 負荷分散することを考えると、これはApacheモジュールか、リバースプロキシ側でやって欲しい作業です。自分で書こうと思ったけど、調べてみたらやっぱり同じようなのがありました。 リバースプロキシなどの中には、X-REPROXY-URLというヘッダをサポートしているものがあり、これを戻すとリバースプロキシが代わりにこのURLにアクセスしてデータを返してくれます。 Perlbalが始めにサポートしたらしいですが、li
Flickrでかっこいいデスクトップを探してみた
自分の仕事環境をもっとよくするために、参考になりそうな机は無いかなーとFlickrで検索してみました。 特にデザイン系の会社だと、カッコいいオフィスがありそうなので、もしご存じの方いましたら、できれば写真があるページを教えてもらえませんか？ コメントかはてブでお願いします。 view from my workspace Originally uploaded by cityflickr こんな環境で仕事してみたい。 400年前の城らしいですよ。ここ。 ニセコで仕事したときは気持ち良かったなぁ。 Before-after1 Originally uploaded by m2j2 机のビフォーアフター。 前は何でこんな位置にディスプレイがあったんだ？ Home office 2.0 Originally uploaded by slrw82 シンプルでいいですね。屋根裏っぽいのが憧れる。 Th
masuidrive on rails - IKEAと5万円で作る快適仕事場
日本での仕事場環境作りの話はこちら。 Impress BB Watchのデスクトップ百景でMac上のデスクトップを紹介して頂いたので、連動してリアルなデスクトップの話です。 私は家で仕事をしていますが、仕事部屋を設けるのではなく、リビングに机を置いて仕事をしています。 一日の時間のほとんどをPCに向かっているので、一番広い部屋を使わないのはもったいないのです。 仕事机を置くのに必要なスペースは大体2畳程度です。リビングが広めだと、思ったより圧迫感は出ないと思います。なので、うちでは、1LDKで広い部屋の物件を探しました。いま住んでいる家も1LDKです。 アメリカに引っ越してまず行った場所はIKEA。今回の引っ越しでは、アーロン以外の家具類は全部処分してきてしまったので、仕事机も棚も全部買い直しです。 私は、17インチ2枚と、24インチ1枚のディスプレイをアームで固定しています。アームを使う
masuidrive on rails - ブログにはてブのコメントを表示するhatana_bookmark_anywhere.js
Photo by puddles for snails ブログを書いていると、はてなブックマークにいいコメントが付くことがあって、これが多くの人に見てもらえないのは、勿体ないなぁーと思うことがたまにあります。 本当はブログのコメント欄に残してもらえるとうれしいのですが、敷居が高いのかなかなか書いてもらえません。 それなら、ブログにはてなブックマークのコメントを表示すればいい！と思って作ってみました。 どこでもはてなブックマークのコメントを表示するスクリプト、「hatana_bookmark_anywhere.js ver 0.1」をリリースします。 実際の設置例はこのページの下の方を見てください。 設置方法は超簡単。https://raw.github.com/masuidrive/hatena-bookmark-anywhere/master/hatena-bookmark-anywhe
Amazon EC2でインスタンスを終了しても消えないディスク領域を年内にリリース
Photo by callumalden Amazon EC2を人に勧めると必ず言われるのが、「インスタンスを再起動したらディスクが消えるのが怖い」。 これは「インスタンス」を再起動であって、OSを再起動してもディスクは消えないのだが、確かに起動に必要なファイルを消してしまって、OSが起動できなくなってしまうと、確かに取り出せなくなってしまいます。 ただ、このようなケースは相当少ない上に、S3という巨大なストレージがあるので、再起動まえなどバックアップをマメに行なう事で、ほぼ解消できる。事実、Stickaでは1時間おきにdumpを取って、1週間分をS3に保持するようにしています。 それでも、やはり容量が大きなデータベースを構築する場合などは、dumpを取るのが難しいなどの問題は出てきます。 これに対する回答として、Amazonがやっと、EC2でも使えるインスタンスを終了しても消えないディス
mod_rails(passenger)はmogrelの3倍メモリを食う？
Rails運用時で気になるのは、安定性とパフォーマンス。安定性はいろいろ負荷テストをして時間が経たないと分からないので、まずはメモリのパフォーマンスから調べてみます。 とりあえず、ちょっとしたサンプルをmongrelで動かしてみると、44Mほどメモリを確保しています。 USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND 1003 14412 0.0 2.2 44316 23556 ? Sl Apr10 0:01 /usr/bin/ruby1.8 /var/lib/gems/1.8/bin/mongrel_rails start んで、同じプロセスをmod_rails(passenger)で起動すると、143Mほど確保されます。 USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAN
EC2の固定IPを使ってみる
初期状態では、一つのインスタンスに、EC2の中だけで使えるPrivate IPと、外部からアクセスするためのPublic IP(グローバルアドレス)が割当たってます。 インスタンス自体への割当IPはPrivate IPですが、上位のルータに1:1のNATがあり、これによって外部からPublic IPでアクセスできる様になっています。 今までの、Private IPとPublic IPに加えて、今度は固定IPのグローバルアドレスが割り当てられるElastic IPを選択出来るようになりました。 これは、Public IPと同じ様に、外部からアクセスするためのグローバルアドレスですが、AWSアカウント毎に発行されるので、インスタンスの再起動などによって代わる事はありません。 これを使えば、EC2で最大の問題点であった、「インスタンスを再起動するとIPアドレスが代わる」という問題から解放されます
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
