06プログラマは何に似てる?今日はプログラマって色んなものに例えられる、似ているというお話です。Combinator」で有名なポール・グレアムが書いた「ハッカーと画家」という本がありますが、最近、プログラマって建築士や医者に近いところもあるなーと考えています。プロダクトを開発する初期の頃は、まだ何も無い更地にどういう建物を立てるか、どういう構造にするか、どういう機能を持った建物にするかなどを考える建築士のような感じで、一度作り切ったシステムを、運用し、メンテナンスしていくフェーズに入ると、バグの調査で、どういう症状なのか、悪い所はどこなのか、どういう治療法が効きそうかなどを考える医者のような思考フローになったりもします。IT系ではプログラマの労働時間の長さやデスマーチなどがよくネタにされますが、何故、単純に「時間」や「人」を投入するだけではシステム開発が上手くいかないかというと、プログラマの仕事が「コードを書くこと」ではなく、「書くコードを考えること」だからだと思います。単純にコードを書くだけであれば、より多くの時間、より多くの人を投入すれば、より多くのコードが書けます。そもそもコードの価値はコードの「量」には比例しません。「量」が多いだけのコードは価値が低いと見なされます。同じ処理を行うのであれば、コードはより簡潔に、より分かりやすく、より少ないコードで実装した方が基本的には価値の高いコードになります。建築士や医者、画家などもそうだと思いますが、より多くの時間を掛ければ、より多くの人を投入すれば、より良い建築が作れる訳でも、より良い治療が出来る訳でも、素晴らしい絵が描ける訳でもないですよね。それと同じように、プログラマも、より多くの時間を掛けても、より多くの人を投入しても、良いコードが書ける訳でも、良いシステムが作れる訳でもありません。大事なのは、より良い解法を「発想」することであったり、「集中」して問題に取り組むことであったり、そしてちゃんと最後まで「終わらせる」こと、などではないかと思います。プログラマが他の職種に似ている所があるように、これらの要素はどんな仕事をする上でも共通する、良い仕事をする為の要素なのかも知れません。いう、プログラマと他の職業の共通点に関するお話でした。07ハッカソンでプロダクトを作る時の個人的ポイントエンジニアの松本です。Atraeでは今週の金曜日(1/9)に社内ハッカソンを実施する予定です。今までにハッカソンに参加した時に自分が個人的に気を付けたポイント、参加してみてこれは失敗したなと思った事から学んだ教訓などを少しまとめてみたいと思います。最低限"使える"レベルのものを作る(極限まで機能を絞る)ハッカソンは大抵1日や2日など、短い時間の中で集中して一気に作り上げる事が多いので、欲しいと思う機能、あったら便利そうな機能まで作っているとだいたい時間が足りなくなり、中途半端な部分までしか実装できずにタイムアップを迎える事になります。そのため、ハッカソンで作る時は、作ろうと思っているプロダクトのコアとなる最も重要な機能の1つか2つに開発する機能のターゲットを絞り、まずはその機能をキチンと動作させる、その機能を主軸としたユーザの操作フローを一通り実行出来るようにするところまでを実装する、という事を最優先にした方が良いと思います。今回実施するハッカソンも1日(およそ10時間)で行う予定なので、ちゃんと機能を絞って開発を進めたいと思います。設計は事前に終わらせるこれはハッカソンのレギュレーションにもよりますが、作るものや使う技術などをあらかじめ決めておいて良い場合は、ハッカソン当日までに機能設計、テーブル設計(モデル設計)、画面フローなどはある程度、事前に考えてしまって、当日は実際に手を動かす、コードを書き始めるところから始められるとスムーズに開発に入れると思います。デザイナーとエンジニアが組んで開発する場合などは、デザイナー側の開発環境を事前にエンジニアがサポートして整えておくと、特にRailsなどでデザイナーがViewファイルに直接htmlやcssの組み込みを行う場合、ローカル環境で動作確認しながら進められるので、かなり当日の作業効率が上がると思います。新しい技術に挑戦しないハッカソンというと、つい今までにやった事の無い事や使った事の無い技術を使ってみたりしたくなりますが、大抵時間を浪費して一通りの機能を実装し切れなくなったりするので、基本的には自分が普段使っている技術や今までにやった事のあるものを組み合わせて作り上げた方がハッカソンの時間内で作り上げる場合には良いと思います。新しい技術をハッカソンで使う場合は事前に技術検証を済ませたり、一度使ってみて感触を確かめたりしておいた方が当日、余計な時間を使ったりせずに済むと思います。Railsなどのバージョンアップのサイクルが速いフレームワークやライブラリを使う場合は、もし最新版を使った事が無ければ、無理に最新版を使わず普段使っているバージョンを使うというのも大事かも知れません。使い慣れていないものを使うと、思わぬエラーに遭遇したり、エラーを解消する為に多くの時間を費やしてしまったりするので、言語、フレームワーク、ライブラリなどもなるべく普段使い慣れたものを選んだ方がプロダクト作りに集中できると思います。自分がハッカソンで開発をする時に気を付けている点はこんなところでしょうか。時間が無い中でプロダクトを作り上げるのは中々大変ですが、逆に使える時間が限られる事によって、より重要な部分にフォーカスしたり、プロダクト自体がシンプルになったりという効果もあるので、時間を有効に使って良いプロダクトに仕上げられると良いですね。15フロントエンドもRubyで開発?「Opal」エンジニアの松本です。今日はフロントエンドもRubyで開発出来るかも知れない、RubyをJavaScriptに変換する「Opal」の紹介をしたいと思います。});↓Rubyでこのように書けるようになります。endend上記の他にも基本的なDOM操作やイベント駆動処理などは問題なく書けそうです。試しに使ってみた感じでは、CoffeeScriptやjQueryの代わりになりそうなイメージです。サンプルが溜まったらブログやQiitaなどで共有していきたいと思います。2014/12/15時点でOpalのバージョンが0.6.3なので、まだ1.0にも達していませんが、アクティブに開発されており、個人的には常々フロントエンドもRubyで書きたいと言っていたので、かなり期待したいと思っています。※毎回デフォルトでインストールするGemにも追加しました。https://github.com/shu0115/rails4apptemplate/blob/master/app_template.rb#L17それでは今日は短いですがこの辺りで。01全てのWebデベロッパーへ、Herokuのススメエンジニアの松本です。QiitaQiitaにHerokuの記事↑をあげたらちょっとバズってたので、今日はHerokuの話を。個人としてはたぶん2009年ぐらいからHerokuを使ってます。今Herokuに上げているアプリを数えてみたら47個ありました。使ってる方だと思います。Qiitaの記事にも書きましたが、とにかく手間が無くて、楽です。自分が作るWebアプリケーションは全てHerokuで運用したいぐらいです。(個人で作っているものは全てHerokuに上げています)開発用には無料枠で十分なので、ステージング環境を開発メンバーに1人1つ用意するような事も出来ます。あるHerokuアプリからフォーク出来るので、Herokuアプリの複製も簡単です。マイナビニュース↑上記の記事でも触れられていますが、インフラ周りの事を全てHerokuがやってくれるので、優秀なインフラチームが海外にいるようなイメージです。AWSで自前でシステムを組むと、本番のWeb/Appサーバ、ステージングのWeb/Appサーバ、本番、ステージングにそれぞれDBサーバ、バッチ処理だけを分離したバッチサーバ、クラッシュに備えて冗長保存させるログサーバが複数台など、1つのサービスを運用するだけでも数多くのサーバを管理しなくてはいけません。システム構成を組むだけであれば1度で済むのでまだ良いですが、運用していく上ではバックアップや負荷監視、インスタンスが落ちた時の復旧作業、アクセスが増えたらインスタンスを新たに立ち上げるなど、まだサービスが成長する前から多くの手間が掛かります。リソースの少ないスタートアップでは、インフラエンジニアを雇ったり、社内のエンジニアが誰か1人、専任でインフラを見るなども難しい事が多いです。スタートアップ以外でも、新しいプロダクトをMVPから作り、スモールスタートでユーザの反応を見ながら短い間隔で改善とリリースを繰り返すような最近の開発スタイルでは、インフラに初期からリソースを割くよりも、インフラ周りをHerokuに全て任せ、ほとんどのリソースをプロダクトの開発や改善に集中出来るという事は大きなメリットになると思います。Herokuを使う人が日本でももっと増えて、課金するユーザももっと増えて来れば、待望の東京リージョンも近付いて来るかと思うので、ぜひHerokuを使ってみましょう。東京リージョンを求める署名も募集しているので、よければご協力ください。14リアルタイムJSフレームワーク「Meteor」エンジニアの松本です。今日は最近Ver1.0になったJSフレームワーク、Meteorを触ってみたので、その共有をしたいと思います。Meteorとはデータのリアルタイム同期、クライアントサイド/サーバサイドの同一言語開発(JavaScript、Node.js)、フルスタックフレームワークである事に加えPaaS環境やDB環境まで備えた全部入りの特徴を持ったJSフレームワークです。2年前ぐらいに初期バージョンが公開され、わりと話題になりました。バージョンが1.0になったようなので、チュートリアルをやってみました。simple-todos(複数ブラウザで操作してみると変更がリアルタイムで同期されるのが分かると思います。Meteorインストールはコマンド一行です。createでアプリケーションのひな形を自動生成してくれます。sと同じようにmeteorと打つだけです。collectionデータを表示するhtmlとデータを取得するjsを用意します。simple-todos.htmlsimple-todos.js特に設定を書かなくてもMongoに繋がります。});データが追加された事を勝手に検知して、画面をリロードしなくても追加したデータが画面に表示されます。formフォームからデータを追加する場合もhtmlとjsだけで完結します。tasksデータの削除も、1つのページで削除を実行したらリアルタイムに他の画面にも反映されます。appMeteorはPaaS環境も備えているので、deployコマンドを実行するだけで他の人も閲覧可能な公開環境を作る事が出来ます。Sessionセッションを使う場合はSession.set、Session.getなどで。accountsMeteorはパッケージをインストールする事で色々な機能を追加できるらしいです。ユーザの登録やログイン機能などを追加する場合は↓こんな感じです。何もしなくてもリアルタイム同期されるっていうのはわりと感動的でした。シングルページのWebアプリケーションやチャットなどのリアルタイム性が重要なアプリケーションの開発にはかなり可能性はあるんじゃないかと思います。フルスタックでDBやPaaS環境も内包したようなフレームワークになってるので、わりと使う場面、力を発揮出来るケースが限定されるかもっていう気もします。クライアントサイドをMeteorで、サーバサイドをRailsで、データのやりとりはAPIで、という構成も出来なくはなさそうなので、機会があればやってみたいなと思います。31プロダクトを作る時に考えることはじめまして。先週10月20日からアトラエにジョインした松本です。Blogですが、あえて技術そのものではなく、技術を生かす道の一つである、"プロダクトを作ること"について書きたいと思います。趣味でWebサービスを作ったり、幾つかのスタートアップでWebサービス開発に携わった中で、自分がプロダクトを作る時に考えること、考えようとしていること、考えるべきだと感じている事などをざっくばらんに。誰が、いつ、どこで、何のために使うのかまず最初に考えるのは、"誰が使うのか"。"何を作るのか"ではなく、"誰が使うのか"を考えます。"誰が"、"いつ"、"どこで"、"何のため"に使うのかを考えれば、必要なプロダクトの形、機能などは自ずと浮かび上がってきます。最近はスマートフォンの普及に伴って、サービスを作る際にまずモバイルから考えるという事も多くなって来たり、PCのWebであったり、モバイルのWebであったり、iPhoneアプリ、Androidアプリ、ハードウェアと組み合わせたもの、オンラインで完結する、オフラインと連動するなど、プロダクトが動くデバイス、環境、シーンなども多種多様になっているので、ユーザがどういう時に使うのか、どんな状態の時に使うのかなど、より深くユーザの行動に根差したものを作らなければならないと感じています。当たり前に使うものスマートフォンならiPhoneが当たり前、PCならMacが当たり前、ある特定の人達にとってはそれを選ぶことが当然のような、使うことが当たり前であるかのようなプロダクト。今あるものより圧倒的に便利であったり、使いやすい、安価である、今までに無い価値があるなど、そのプロダクトを使う何らかの必然性があること。いうものでなければ、ユーザに時間を使ってもらう、お金を払ってもらう事はやはり難しいと思います。気が付いたらいつの間にか生活の一部になっていたり、これが無いと困るという必需品になっていたり、そういうプロダクトがやはりユーザに選ばれていくんだろうなと思います。Product)という言葉もよく聞くようになりました。プロダクトを作っていると、どうしてもこういう機能があった方がいいんじゃないか、この機能を追加した方が便利なんじゃないかと色々なアイデアが出て、つい多くの機能を付け足したくなってしまいます。以前作ったプロダクトでも、MVPという言葉は知っていたものの、開発リソースが比較的確保出来ていた事もあり、結果的にはファーストバージョンのローンチ時でも、かなり多くの機能を盛り込んだ、コントロールしづらい大きめのプロダクトになってしまいました。最近は「あったらいいねは全て要らない」と割り切り、絶対にこの機能は必要、この機能が無くなったらプロダクトが成り立たないと言えるようなもの以外は極力切り捨てるように意識して、機能の取捨選択やプロダクト自体の大きさなどを考えるようにしています。プロダクトを作る時に最近考えている事を書いてみました。分かっていても中々上手くは出来ないんですが。「言うは易く行うは難し」ですね。GitHub.Permalink。