railsのherokuへの展開でつまずいた話

Ruby on Rails チュートリアル：実例を使って Rails を学ぼう でRailsの勉強をしていてつまずいたところがあったので、そこだけまとめ。

railsをherokuに展開する

チュートリアル2章のデモアプリケーション作成時には、Localで構築環境をherokuへ展開する時に以下のコマンドで展開します。

参照: 2.3.5デモアプリケーションのデプロイ

$ heroku create
$ git push heroku master

# データベースを動作させる場合はこれも必要
$ heroku run rake db:migrate

(ralsの構築、herokuへの展開の詳しい手順は、チュートリアルのheroku展開の手順を参照)

■問題
展開時に通知されたURLにウェブブラウザでアクセスしてみると、
「The page you were looking for doesn't exist.」
のページが表示されてしまいます。これに大分はまった。。

■解決策
いろいろと調べたところ、以下のサイトの質問者の方と同じ状況でした。
railsアップをproduction serverでデプロイしたら、 ActionController::RoutingError (No route matches [GET] "/"): - QA@IT

抜粋してみるとこんな流れです。

publicフォルダにindex.htmlを置いたら、エラーでなくなりました。これが正しいのかって感じですが。。。

コメントを見る限り、特にルートを処理するコントローラを作ったわけではないように見受けられます。
だとすれば、productionではそのようになります。

中略

public にindex.html を置くのは間違いではないんですが、最終的には / を解決するコントローラを置くことになると思います。

「herokuのURL/users」等、rails側で作成できているアクションに関しては、ページが作成されており、エラーも表示されませんでした。

ここまで読んだところによると、

• 「/」 を解決するコントローラを作成する
• public に index.html を置く

のどちらかで解決できそうです。
今回はindex.html を作成して、作成できているページへのリンクを張り付ける形式にしました。

イメージ図

これでherokuデプロイ時に発行されるURLにはindex.htmlが表示されます。

yokohama.rbに行ってきた

独学でruby勉強してみてきましたが、実際にrubyで色々作っている人に会ってみたいなと思い、初参加してきました(もう一か月たっちゃった)。
Yokohama.rb Monthly Meetup #42 - Yokohama.rb | Doorkeeper

会場の様子

もくもくとコード書いたり、わいわいと話をしたりする感じでした。
ノートPC持ってくか迷ったけれど、もくもくできるので持ってくのが吉です。

過去の会に参加していた方がまとめていたブログの写真とイメージは同じでした。

プレゼン形式で作ったものを紹介してくれたりもあります。

「開発コミュニティ」に参加するのも初めてなので緊張しましたが、
話掛けてくれる人も多く、業界違いの自分はWeb業界のこととか、開発環境のこと、「開発プロジェクトがうんぬん～」の話等、色々聞けてよかったです。

またどこかで行ってみよう！

coderwallの「説明文付き」バッジ一覧をブログに表示する

coderwallのバッジを、ブログに張り付ける方法が紹介されているので、自分も試してみました。ただ、このままだと何のバッジかわからないので、本家のページのようにバッジにマウスを当てると説明文が出てくるようにカスタマイズしてみた。

完成イメージ

バッジにマウスを当てると、説明文「Fork and commit to someone's open source project in need」が表示されます。

実際の動きは本ブログのサイドバーの「coderwall」の部分から見れます！

プログラム

Display badge's description when you hover badge image.
に作ったコードをまとめておきました。

何をしているか？

ざっと説明すると、追加した処理は2つ

説明文書の取得

<section class="coderwall" data-coderwall-username="kazuhirosaji" data-coderwall-orientation="vertical"></section>

の部分からバッジの一覧を表示してくれるのですが、表示されたバッジ画像の内容を調べてみると。バッジのimg要素のalt属性に、そのバッジの説明が記載されています。

この説明文をバッジのimg要素の上にマウスを合わせた時に発生するhoverイベントのタイミングで取り出し、span要素のテキストに反映します。(対象コードのset_description())。

説明文のstyleの調整

hoverのタイミングで、span要素のdisplay要素の切り替え(テキストの表示/非表示)と、span要素の位置の調整を行っています。

span要素の位置の調整は、はてなブログだとうまく効かなかった。。。

はてなブログのサイドバーに張り付けるとき

「デザイン」⇒「カスタマイズ」⇒「サイドバー」⇒「モジュール追加」で、
本記事の「coderwall_badge_markup.html」の

3行目の～41行目の　を張り付ければOKです。

是非使ってみてください！

「Scrum Boot Camp The Book x リーン開発の現場 - なぜ現場の実践本が必要なのか」に行ってきた

Scrum Boot Camp The Book x リーン開発の現場 - なぜ現場の実践本が必要なのか - - Agile Samurai Base Camp | Doorkeeper
に行ってきました。

みんながプロジェクト運用で抱えている問題に対する、解決策、ヒント等をいただくQ&A形式のセッションが後半にあったのですが、トーカーの御2人とも大小様々な解決策、案を持ってるので、なるほどな～と感心しっぱなしでした。
今後、プロジェクト運用する時等に覚えておきたいことが多々あったので、印象に残ったことをメモしておきます。

まずは最も印象に残ったポイント。。

プロジェクト運営、手法にゴールはなく、改善し続けることが大事

改善し続けることこそアジャイル！
アジャイル侍のBoot Campの時にもお話ありました。「リーン開発の現場」でも、著者のプロジェクトではプロジェクト初期からカンバンレイアウトの見直し等、様々な方法へのトライが行われていました。
これは、開発案件を持ってる時、常に意識し続けておきたいです。

Q: 現場でのアジャイル開発　どうやって始めるか？

A:
まずは自分がやれる範囲で始めること

• DailyMTG(朝会)
• 継続的インテグレーション(Jenkinsの導入など)
• 個人でテスト駆動開発を始める etc...

小さく始めれるところから　OR　自分達の案件に効きそうなところから改善していく。
個人的には、小さく始めれるプラクティスをたくさん紹介している「アジャイルプラクティス」に目を通して、使えそうなものを導入するのも良かなと。

アジャイルプラクティス 達人プログラマに学ぶ現場開発者の習慣

アジャイルとはなんぞや？の状態で初めて読んだ時はこんな方法あるのかー！とテンション上がってました。

アジャイル開発方式を周りに広げるとき

小さく導入したアジャイルを周りに広げる時のお話。

• 何故その方式でやるか、周り(上司や同僚、顧客)にその理由を伝える。
  • 「Why?」が抜け落ちてはいけない。
• 周りの理解が取れない時は、個人やチーム、内部で先にできることを行う
  • 内部でやっている内に「お前ら何やってんだ？」と周りが(いい意味で)興味を持ってくれることも。

Q:受託案件で顧客を巻き込んでスコープ調整を行いたい

Q : 優先度の低いスコープをDropするにはどうすれば良いですか？
これは、自分の質問。「リーン開発の現場」、「SCRUM BOOT CAMP」共に苦労しつつもスコープ(要件)の調整を行えているけれど、実際の現場ではどうやってこの状況にもっていっているのか？

A:

• 実際は顧客に信用されていないとなかなか難しい。。
• 難しい課題は代案を提示して調整を行う。
• 案件の後半ではなく、最初にスコープを顧客と調整しよう！
• そのスコープが本題とずれている可能性がある場合は何のために作るのか？を明確にする

「アジャイル開発」だって、やるべきことをきっちりやることなんだ！ストンと落ちました。

Q:デザイナーと開発者等、違う目的を持っている人たちの間でのお仕事、どうやって協力関係を築くか？

A:

• まずはインセプションデッキ等で、小さく巻き込む
• 小さい繋がりから、部署間のコミュニケーションに発展させる
• 場合によっては、非公式に時間を取る(飲み会、ランチ等)

感想

あいまいな記憶ながらざっくりまとめました。
上記以外にもたくさん。。解決策の引き出しの多さに感心しました。
これ言うの年末に続き2回目だけど、、僕も小さく始めよう。
DailyMTGはやってるから、次は振り返りMTGの導入かな？

関連書籍

実践したいときのヒントとして。。

SCRUM BOOT CAMP THE BOOK

リーン開発の現場 カンバンによる大規模プロジェクトの運営

FIFAランキングをMapchartを使用して世界地図に表示してみる

以前の記事で紹介したGeoChatを使って、FIFAのランキングを世界地図に表示するものを作ってみました。

イメージ

GeoChartで世界地図を表示。赤い国程強いです。

マウスカーソルを当てると、その国のランキングが表示され、

クリックすると。

その国の代表チームのWikiページが表示されます。

中でどんな処理をしているか

ざっとまとめると。。

1. FIFAのページから拾ったJSONデータをJavaScriptで取り込み、国名[ランキング]の配列を作る。

1. 国の地域コード(ISO-3166-1)がまとまっているJSONデータを使用して、「01」で作った配列の国名をGoogle GeoChartが認識できる地域コードに変換する
2. Google GeochartのAPIを使用して、世界地図にFIFAランキングを表示する
3. selectHandlerを使って、タッチした国のサッカー代表チームWikiページを表示する

をやっています。

もっと詳しく！

興味ある方はGitHubのページを見てみて下さい！！
kazuhirosaji/maplinks · GitHub

実際に動かしてみる

xamppやapache等にダウンロードしたファイルを置いて、geochart.htmlを開けばOKです。

リーン・スタートアップは「小さく、細かく、早く」

今更ですが「リーン・スタートアップ」

リーン・スタートアップ

数か月かけてだらだらと読んでみたので、印象に残った点をまとめてみます。

印象に残ったこと

必要最小限の機能をそなえたプロダクトの作成、実際に顧客の反応を見る実験、検証、検証結果からの学びの取得を素早く回し、最も大事な「顧客にとって価値のある製品」を作っていく方法です。
顧客に製品を見せながらフィードバックを得て、製品の機能を固めていく点はアジャイルも似ている(同じ？)ので、開発者の自分も学ぶことが多かったです。

リーンをソフト開発に適用した実例をまとめている「リーン開発の現場」もこの後読んでみようと思います。

ポイント

製品の「実験、検証」にどのような尺度を採用するかが大事のようで、ここに間違えた尺度を用いてしまうと、サービスが順調に成長しているようで、実は問題の見落としがあったり、製品、サービスの方針転換(ピボット)のタイミングを逃してしまうなどの問題が発生してしまいます。
製品、サービスの見極めと方針の決定、転換の決断、、
スタートアップのスピード感、決断力。自分にも欲しい！

まとめ

先に読んだ「テスト駆動開発入門」でも感じたけど、「小さく、細かく、早く」が無駄の少ない開発には必要である。

JavaScriptの命名規則

Rubyの命名規則は以前教わったことをまとめていましたが、JavaScriptについてはよくわからないままコーディングしていたので、ちょっと探してみました。

これでいいんじゃないかな？
JavaScriptにおける命名規則の個人的まとめ｜もっこりJavaScript｜ANALOGIC（アナロジック）