今日はプログラマって色んなものに例えられる、似ているというお話です。

今では「Y Combinator」で有名なポール・グレアムが書いた「ハッカーと画家」という本がありますが、最近、プログラマって建築士や医者に近いところもあるなーと考えています。
プロダクトを開発する初期の頃は、まだ何も無い更地にどういう建物を立てるか、どういう構造にするか、どういう機能を持った建物にするかなどを考える建築士のような感じで、一度作り切ったシステムを、運用し、メンテナンスしていくフェーズに入ると、バグの調査で、どういう症状なのか、悪い所はどこなのか、どういう治療法が効きそうかなどを考える医者のような思考フローになったりもします。

IT系ではプログラマの労働時間の長さやデスマーチなどがよくネタにされますが、何故、単純に「時間」や「人」を投入するだけではシステム開発が上手くいかないかというと、プログラマの仕事が「コードを書くこと」ではなく、「書くコードを考えること」だからだと思います。
単純にコードを書くだけであれば、より多くの時間、より多くの人を投入すれば、より多くのコードが書けます。
ですが、そもそもコードの価値はコードの「量」には比例しません。むしろ「量」が多いだけのコードは価値が低いと見なされます。
同じ処理を行うのであれば、コードはより簡潔に、より分かりやすく、より少ないコードで実装した方が基本的には価値の高いコードになります。

建築士や医者、画家などもそうだと思いますが、より多くの時間を掛ければ、より多くの人を投入すれば、より良い建築が作れる訳でも、より良い治療が出来る訳でも、素晴らしい絵が描ける訳でもないですよね。
それと同じように、プログラマも、より多くの時間を掛けても、より多くの人を投入しても、良いコードが書ける訳でも、良いシステムが作れる訳でもありません。

大事なのは、より良い解法を「発想」することであったり、「集中」して問題に取り組むことであったり、そしてちゃんと最後まで「終わらせる」こと、などではないかと思います。
プログラマが他の職種に似ている所があるように、これらの要素はどんな仕事をする上でも共通する、良い仕事をする為の要素なのかも知れません。

という、プログラマと他の職業の共通点に関するお話でした。

エンジニアの松本です。

Atraeでは今週の金曜日(1/9)に社内ハッカソンを実施する予定です。
なので、今までにハッカソンに参加した時に自分が個人的に気を付けたポイント、参加してみてこれは失敗したなと思った事から学んだ教訓などを少しまとめてみたいと思います。

最低限"使える"レベルのものを作る(極限まで機能を絞る)

ハッカソンは大抵1日や2日など、短い時間の中で集中して一気に作り上げる事が多いので、欲しいと思う機能、あったら便利そうな機能まで作っているとだいたい時間が足りなくなり、中途半端な部分までしか実装できずにタイムアップを迎える事になります。
そのため、ハッカソンで作る時は、作ろうと思っているプロダクトのコアとなる最も重要な機能の1つか2つに開発する機能のターゲットを絞り、まずはその機能をキチンと動作させる、その機能を主軸としたユーザの操作フローを一通り実行出来るようにするところまでを実装する、という事を最優先にした方が良いと思います。

今回実施するハッカソンも1日(およそ10時間)で行う予定なので、ちゃんと機能を絞って開発を進めたいと思います。

設計は事前に終わらせる

これはハッカソンのレギュレーションにもよりますが、作るものや使う技術などをあらかじめ決めておいて良い場合は、ハッカソン当日までに機能設計、テーブル設計(モデル設計)、画面フローなどはある程度、事前に考えてしまって、当日は実際に手を動かす、コードを書き始めるところから始められるとスムーズに開発に入れると思います。

デザイナーとエンジニアが組んで開発する場合などは、デザイナー側の開発環境を事前にエンジニアがサポートして整えておくと、特にRailsなどでデザイナーがViewファイルに直接htmlやcssの組み込みを行う場合、ローカル環境で動作確認しながら進められるので、かなり当日の作業効率が上がると思います。

新しい技術に挑戦しない

ハッカソンというと、つい今までにやった事の無い事や使った事の無い技術を使ってみたりしたくなりますが、大抵時間を浪費して一通りの機能を実装し切れなくなったりするので、基本的には自分が普段使っている技術や今までにやった事のあるものを組み合わせて作り上げた方がハッカソンの時間内で作り上げる場合には良いと思います。

もし新しい技術をハッカソンで使う場合は事前に技術検証を済ませたり、一度使ってみて感触を確かめたりしておいた方が当日、余計な時間を使ったりせずに済むと思います。

Railsなどのバージョンアップのサイクルが速いフレームワークやライブラリを使う場合は、もし最新版を使った事が無ければ、無理に最新版を使わず普段使っているバージョンを使うというのも大事かも知れません。
使い慣れていないものを使うと、思わぬエラーに遭遇したり、エラーを解消する為に多くの時間を費やしてしまったりするので、言語、フレームワーク、ライブラリなどもなるべく普段使い慣れたものを選んだ方がプロダクト作りに集中できると思います。

自分がハッカソンで開発をする時に気を付けている点はこんなところでしょうか。

時間が無い中でプロダクトを作り上げるのは中々大変ですが、逆に使える時間が限られる事によって、より重要な部分にフォーカスしたり、プロダクト自体がシンプルになったりという効果もあるので、時間を有効に使って良いプロダクトに仕上げられると良いですね。

エンジニアの松本です。

今日はフロントエンドもRubyで開発出来るかも知れない、RubyをJavaScriptに変換する「Opal」の紹介をしたいと思います。

公式ページはこちら → Opal: Ruby to Javascript Compiler
Railsで使うならこちら → opal/opal-rails

コラム - Ruby ＆ Rails | 第16回　Opal ～JavaScriptもRubyで～｜CTC教育サービス 研修/トレーニング
↑この記事から抜粋させて頂きますが

↓このJavaScriptを

$(function(){
  $("h1").on("click", function(){
    var p_elem = $("<p>");
    p_elem.text("h1 was clicked");
    p_elem.css("color", "red");

    $().append(p_elem);
  }); 
});

↓Rubyでこのように書けるようになります。

Document.ready? do
  Element.find("h1").on(:click) do
    p_elem = Element.new("p")
    p_elem.text("h1 was clicked!")
    p_elem.css("color", "red")

    Element.find("body").append(p_elem)
  end
end

上記の他にも基本的な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

それでは今日は短いですがこの辺りで。

エンジニアの松本です。

Herokuのメリット、デメリット - Qiita

QiitaにHerokuの記事↑をあげたらちょっとバズってたので、今日はHerokuの話を。
個人としてはたぶん2009年ぐらいからHerokuを使ってます。
今Herokuに上げているアプリを数えてみたら47個ありました。そこそこ使ってる方だと思います。

Qiitaの記事にも書きましたが、とにかく手間が無くて、楽です。
自分が作るWebアプリケーションは全てHerokuで運用したいぐらいです。(個人で作っているものは全てHerokuに上げています)

開発用には無料枠で十分なので、ステージング環境を開発メンバーに1人1つ用意するような事も出来ます。
しかも既にあるHerokuアプリからフォーク出来るので、Herokuアプリの複製も簡単です。

Love Heroku? 急成長スタートアップが明かすPaaS活用事例 - Tech Compass (1) Herokuは優秀なインフラエンジニア | マイナビニュース
↑上記の記事でも触れられていますが、インフラ周りの事を全てHerokuがやってくれるので、優秀なインフラチームが海外にいるようなイメージです。

AWSで自前でシステムを組むと、本番のWeb/Appサーバ、ステージングのWeb/Appサーバ、本番、ステージングにそれぞれDBサーバ、バッチ処理だけを分離したバッチサーバ、クラッシュに備えて冗長保存させるログサーバが複数台など、1つのサービスを運用するだけでも数多くのサーバを管理しなくてはいけません。
システム構成を組むだけであれば1度で済むのでまだ良いですが、運用していく上ではバックアップや負荷監視、インスタンスが落ちた時の復旧作業、アクセスが増えたらインスタンスを新たに立ち上げるなど、まだサービスが成長する前から多くの手間が掛かります。

特にリソースの少ないスタートアップでは、インフラエンジニアを雇ったり、社内のエンジニアが誰か1人、専任でインフラを見るなども難しい事が多いです。
スタートアップ以外でも、新しいプロダクトをMVPから作り、スモールスタートでユーザの反応を見ながら短い間隔で改善とリリースを繰り返すような最近の開発スタイルでは、インフラに初期からリソースを割くよりも、インフラ周りをHerokuに全て任せ、ほとんどのリソースをプロダクトの開発や改善に集中出来るという事は大きなメリットになると思います。

Herokuを使う人が日本でももっと増えて、課金するユーザももっと増えて来れば、待望の東京リージョンも近付いて来るかと思うので、ぜひHerokuを使ってみましょう。


東京リージョンを求める署名も募集しているので、よければご協力ください。
キャンペーン · We ask for the Tokyo region of Heroku／東京リージョンに対応してください #heroku · Change.org

エンジニアの松本です。

今日は最近Ver1.0になったJSフレームワーク、Meteorを触ってみたので、その共有をしたいと思います。

Meteorとは

データのリアルタイム同期、クライアントサイド／サーバサイドの同一言語開発(JavaScript、Node.js)、フルスタックフレームワークである事に加えPaaS環境やDB環境まで備えた全部入りの特徴を持ったJSフレームワークです。
2年前ぐらいに初期バージョンが公開され、わりと話題になりました。

で、ようやくバージョンが1.0になったようなので、チュートリアルをやってみました。

作業ログだけ見たい方はこちら→ Meteor Getting Started & Tutorial - Qiita

作業後のデプロイ済みの状態はこちら→ simple-todos (複数ブラウザで操作してみると変更がリアルタイムで同期されるのが分かると思います。)

セットアップ

• Installing Meteor

インストールはコマンド一行です。

curl https://install.meteor.com/ | sh
------------------------------
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  6117    0  6117    0     0   2958      0 --:--:--  0:00:02 --:--:--  2959
Downloading Meteor distribution
######################################################################## 100.0%

Meteor 1.0 has been installed in your home directory (~/.meteor).
Writing a launcher script to /usr/local/bin/meteor for your convenience.

To get started fast:

  $ meteor create ~/my_cool_app
  $ cd ~/my_cool_app
  $ meteor

Or see the docs at:

  docs.meteor.com
------------------------------

サンプルアプリ作成

• Creating your first app

rails newと同じようにmeteor createでアプリケーションのひな形を自動生成してくれます。

cd ~/WORK_DIR
meteor create simple-todos
------------------------------
simple-todos: created.                        

To run your new app:                          
   cd simple-todos
   meteor
------------------------------

• アプリ起動

ローカルでの起動もrails sと同じようにmeteorと打つだけです。

cd simple-todos
meteor
------------------------------
[[[[[ ~/labo/meteor/simple-todos ]]]]]        

=> Started proxy.                             
=> Started MongoDB.                           
=> Started your app.                          

=> App running at: http://localhost:3000/
------------------------------

データ格納

• Storing tasks in a collection

データを表示するhtmlとデータを取得するjsを用意します。

• simple-todos.html

• simple-todos.js

特に設定を書かなくてもMongoに繋がります。

• mongoDBコンソール起動

meteor mongo

• データ格納

db.tasks.insert({ text: "Hello world!", createdAt: new Date() });

データが追加された事を勝手に検知して、画面をリロードしなくても追加したデータが画面に表示されます。

フォームからデータ追加

• Adding tasks with a form

フォームからデータを追加する場合もhtmlとjsだけで完結します。

• simple-todos.html

• simple-todos.js

データ削除

• Checking off and deleting tasks

データの削除も、1つのページで削除を実行したらリアルタイムに他の画面にも反映されます。

• simple-todos.html

• simple-todos.js

デプロイ

• Deploying your app

MeteorはPaaS環境も備えているので、deployコマンドを実行するだけで他の人も閲覧可能な公開環境を作る事が出来ます。

meteor deploy simple-todos-sample.meteor.com
------------------------------
To instantly deploy your app on a free testing server, just enter your
email address!

Email: s.matsumoto0115@gmail.com
Deploying to http://simple-todos-sample.meteor.com.
Now serving at http://simple-todos-sample.meteor.com
                                             /
You can set a password on your account or change your email address at:
https://www.meteor.com/setPassword?C3mZnbHWKK
------------------------------

セッションに一時情報保存

• Storing temporary UI state in Session

セッションを使う場合はSession.set、Session.getなどで。

• simple-todos.html

• simple-todos.js

ユーザアカウント機能

• Adding user accounts

Meteorはパッケージをインストールする事で色々な機能を追加できるらしいです。

ユーザの登録やログイン機能などを追加する場合は↓こんな感じです。

meteor add accounts-ui accounts-password
------------------------------
  added accounts-password at version 1.0.4    
  added accounts-base at version 1.1.2        
  added less at version 1.0.11                
  added accounts-ui at version 1.1.3          
  added service-configuration at version 1.0.2
  added accounts-ui-unstyled at version 1.1.4 
  added email at version 1.0.4                
  added sha at version 1.0.1                  
  added localstorage at version 1.0.1         
  added srp at version 1.0.1                  
  added npm-bcrypt at version 0.7.7           

accounts-ui: Simple templates to add login widgets to an app
accounts-password: Password support for accounts
------------------------------

meteor
------------------------------
[[[[[ ~/labo/meteor/simple-todos ]]]]]        

=> Started proxy.                             
=> Started MongoDB.                           
=> Started your app.                          

=> App running at: http://localhost:3000/
------------------------------

• simple-todos.html

• simple-todos.js

雑感

何もしなくてもリアルタイム同期されるっていうのはわりと感動的でした。
シングルページのWebアプリケーションやチャットなどのリアルタイム性が重要なアプリケーションの開発にはかなり可能性はあるんじゃないかと思います。

ただ、フルスタックでDBやPaaS環境も内包したようなフレームワークになってるので、わりと使う場面、力を発揮出来るケースが限定されるかもっていう気もします。
クライアントサイドをMeteorで、サーバサイドをRailsで、データのやりとりはAPIで、という構成も出来なくはなさそうなので、機会があればやってみたいなと思います。

はじめまして。
先週10月20日からアトラエにジョインした松本です。

初めてのブログ投稿なので、Tech Blogですが、あえて技術そのものではなく、技術を生かす道の一つである、"プロダクトを作ること"について書きたいと思います。

趣味でWebサービスを作ったり、幾つかのスタートアップでWebサービス開発に携わった中で、自分がプロダクトを作る時に考えること、考えようとしていること、考えるべきだと感じている事などをざっくばらんに。

誰が、いつ、どこで、何のために使うのか

まず最初に考えるのは、"誰が使うのか"。
"何を作るのか"ではなく、"誰が使うのか"を考えます。

"誰が"、"いつ"、"どこで"、"何のため"に使うのかを考えれば、必要なプロダクトの形、機能などは自ずと浮かび上がってきます。

特に最近はスマートフォンの普及に伴って、サービスを作る際にまずモバイルから考えるという事も多くなって来たり、PCのWebであったり、モバイルのWebであったり、iPhoneアプリ、Androidアプリ、ハードウェアと組み合わせたもの、オンラインで完結する、オフラインと連動するなど、プロダクトが動くデバイス、環境、シーンなども多種多様になっているので、ユーザがどういう時に使うのか、どんな状態の時に使うのかなど、より深くユーザの行動に根差したものを作らなければならないと感じています。

当たり前に使うもの

スマートフォンならiPhoneが当たり前、PCならMacが当たり前、ある特定の人達にとってはそれを選ぶことが当然のような、使うことが当たり前であるかのようなプロダクト。
今あるものより圧倒的に便利であったり、使いやすい、安価である、今までに無い価値があるなど、そのプロダクトを使う何らかの必然性があること。

そういうものでなければ、ユーザに時間を使ってもらう、お金を払ってもらう事はやはり難しいと思います。
気が付いたらいつの間にか生活の一部になっていたり、これが無いと困るという必需品になっていたり、そういうプロダクトがやはりユーザに選ばれていくんだろうなと思います。

あったらいいねは全て要らない

最近はリーン・スタートアップの流行により、MVP(Minimum Viable Product)という言葉もよく聞くようになりました。
ですが、プロダクトを作っていると、どうしてもこういう機能があった方がいいんじゃないか、この機能を追加した方が便利なんじゃないかと色々なアイデアが出て、つい多くの機能を付け足したくなってしまいます。

以前作ったプロダクトでも、MVPという言葉は知っていたものの、開発リソースが比較的確保出来ていた事もあり、結果的にはファーストバージョンのローンチ時でも、かなり多くの機能を盛り込んだ、コントロールしづらい大きめのプロダクトになってしまいました。

なので、最近は「あったらいいねは全て要らない」と割り切り、絶対にこの機能は必要、この機能が無くなったらプロダクトが成り立たないと言えるようなもの以外は極力切り捨てるように意識して、機能の取捨選択やプロダクト自体の大きさなどを考えるようにしています。

などなど。
プロダクトを作る時に最近考えている事を書いてみました。
少しでも参考になれば。

分かっていても中々上手くは出来ないんですが。
まさに「言うは易く行うは難し」ですね。

Next you can update your site name, avatar and other options using the config.yml file in the root of your repository (shown below :pointdown:).

The easiest way to make your first post is to edit this one. Go into /_posts/ and update the Hello World markdown file. For more instructions head over to the Jekyll Now repository on GitHub.