持て余した時間を、子供の相手もそこそこに、個人的なアプリ開発に費やしてました。
もう飽きた見せてもいいくらいになってきたのでお披露目しようかと思います。
家にあるスケジュールボード的なものをイメージして、（主に家族間の）メッセージのやりとりができるようにしたかったんだけど、ごちゃごちゃしてきてわけがわからなくなりました・・・。GAE/Jで動作します。
サイト
ソースコード
基本的にサーバからJSONでデータ貰ってjsでレンダリングしてます。新し目のブラウザであれば大きな問題は無いと思います*1。この方式にもかなり慣れてきました。
GAE上で動作するアプリはGoogleアカウントが必要ですが、デモサイトもあるので動かしてみて感想を頂ければ嬉しいです。
*1:IEは気にしてません
9/22にNDSに参加してきました。
「スーツvsギーク討論会」というテーマでディスカッション形式でした。勉強会でディスカッションってめずらしかったです。皆さんが現在に至るまでの経緯の違いからか、伝えたいことが伝わらず歯がゆく思うこともありましたが、最終的に「ゴールは一緒なので協力しましょうよね」、という落とし所になってよかったと思います。こういう話でムズムズしている人は、社内でやってみたらいいのに、と思いました。そっちの方がわだかまり少なくなると思います*1
僕の勝手なイメージからすると「スーツ」「ギーク」って、自分に壁を作っているだけだと思うんです。僕は「スーツ（ギーク）」だから「ギーク（スーツ）」の話はわからないと言っているように思えて。「俺がこんなに頑張ってるのに報われないのはギーク（スーツ）の奴らのせいだ」って言いやすくしてるだけじゃないかな、なんて歯がゆく思ってましたが、今回の人たちはそうではありませんでした。本当に「できる人」ってのは両方の素養を持っている人なんだろうと思ってまして、私もそうありたいと常日頃考えている次第です。ギークだってコスト意識持つべきだし、スーツだっていつまでもStr◯tsベースの自社フレームワークを使いまわしてシステムを開発することに疑問を持つべきです。*2
僕の話になりますが、仕事である以上気が進まなくてもやらなければならないことが往々にしてあります。そんな中でも自分が選択し決定した中で仕事をして少しでもモチベーションを高く維持したいと思った時にはプライムで仕事をするしかないと思い、技術だけでなくマネージメントの勉強もするようになりました。技術だけだと結局マネージャに良いように使われる、マネージメントだけだとデベロッパーに嘘をつかれても気づかない、と思ったからです*3
他人が頼りないなら自分がなってやるという選択肢もあると思います。それを放棄するのなら状況はきっと変わらないし、押し付けられたと思いながら言われたことをやるしか無いと思うんです。お互いの話が（納得できなくても）理解できるような人間になりたいなぁ、と思ってます。
今回の勉強会は学生さんの参加が多かったので意味がわからないことも多かったと思いますし、必要以上に怖がらせたこともあったと思います。若干煽ってしまった感があります。ごめんなさい。ですが、SIとWeb系でのビジネスの違いはあれど、開発に携わってお金を貰う以上、一人でやるのでなければこの手の話は出てきます。すでにお金を払う人がいる時点で一人じゃないですしね。それに、閉じられた世界で気の合う仲間と仲良くビジネスをする、というのは現実問題無いでしょう*4。それだけ、お金を稼ぐというのはシビアなんです。
ただ、今までの技術的な興味が「プロジェクトの成功率を上げる」ことから始めていたのですが、純粋に「楽しいからプログラムする」ということからこともしてみたいなーと思うようになりました。静的言語は最近の他人からは敬遠されるのかな・・・。
表題の通りなのですが、Facebookの認証画面でキャンセルされると
OmniAuth::Strategies::OAuth2::CallbackError
の例外が発生します。
まぁ、キャンセルされることは少ないでしょうから放っておいても大丈夫な気がしますが、やっぱりかっこ悪い。対応してみましょう。
/config/initializers/omniauth.rbに次の文を追加
OmniAuth.config.on_failure = SessionsController.action(:oauth_failure)
※キャンセル時、SessionsControllerクラスのoauth_failureメソッドが呼ばれることを定義します。
で、コントローラ(/controllers/sessions_controller.rb)にoauth_failureメソッドを追加
class SessionsController < ApplicationController def oauth_failure flash[:notice] = "キャンセルしました。" redirect_to "/" end end
※この例ではメッセージを設定して、指定URLにリダイレクトする処理を記述します。
RoRはこういうの楽でいいですねぇ。
RailsのAsset Pipelineの対応で、
# config/environments/production.rb config.assets.compile = true
で逃げていたのですが、稼働中のサーバに対して無駄なリソース使うことになるのでイケてないと思い、対応しようと思った時のメモです。
productionで動作させるときには、
app/assets/javascripts/application.js
app/assets/stylesheets/application.css
config/environments/production.rbのconfig.assets.precompile
等を編集しただけではダメで、
bundle exec rake assets:precompile
で、プリコンパイルしておく必要があるので、実行しておきます。
で、serverをproductionで実行。
・・・あれ？
cssやjsが404となります。
生成されたhtml見ても該当するファイル名はpublic/assetsに存在します。
ブラウザから直接叩いても404です。
試しにHerokuにあげてみると、問題なく動作している模様。
不思議な状況です。
google先生に聞いてみると、このような情報が！
Rails3.2で production にした途端にapplication.css が参照できなくなる:お題目うぉっち
config/environments/production.rbの「config.serve_static_assets」を
コメントアウトすることできちんと動作しました。
開発技術は日を追う毎に複雑になってきます。
昔勉強したものも今現在では役に立たない、むしろ固執することで足かせになることが多いかもしれません。
なまじ過去に成功体験を多く持っている人は、時代の変化によって、勝利の方程式だと信じてやまないプロセスが通用しなくなってきたことに焦りや苛立ちを持っているのではないでしょうか。私もその中の一人だったりします。
システムの利用者にとって「価値あるもの」の定義も時間とともに変化していきます。システム開発当初に合意した仕様が今も正しい仕様である保証はありません。ビジネス自体が変化しなければならないのにシステムが追いつけなくて足かせになっている、というのは非常に不幸な状況です。
システムの作り方に問題があるのでしょうか？
開発言語の選定が甘かったのでしょうか？
ケース・バイ・ケースではあるでしょうけど、ただ、１つ言えるのは、時間の経過により、仕様の『鮮度』が落ちるものがある、ということです。システムは作って終わりではありません。
長期間変更が不要な保存の効く仕様ばかりではありませんし、システムが提供する機能に対して使用されているのか、仕様はこのままで良いのかの棚卸が必要ではないでしょうか。
要件定義の際には必要だと思われた機能が今では誰からも使用されていない場合、思い切ってdropし、機能を必要最低限のものとして保守工数を減らし、その分新しい機能の追加工数に充てる、とか、技術的、ビジネス的な観点でジャッジできる体制にならなければなりません。
仕様の決定に関しては開発費用を出すユーザ側が立場が上であることが多く、その決定は開発側だけでは如何ともし難い状況が多いでしょう。場合によっては、ユーザ側は予算の中で開発側に機能をいくつ作らせるか腐心することもあるかもしれません。機能が多いからといって、良いシステムになるわけではないのに、です。一般的にはお金を払う側が強いので、主従関係となってしまうことが多いでしょう。
このような関係では、良い提案が出てくる可能性は皆無で、開発側は提示された仕様を愚直にシステム化することだけに専念します。契約から逸脱すること無く、それ以上でも以下でもないシステムが出来上がることになります。
で、開発現場の若手は今までの成功事例を元にした超保守的な仕事が面白くないもんだから社外の勉強会に参加するようになって新しいことを学ぶんだけど「結局今の状況じゃ何も変わらない」と思って社内で活かすことをせず、「誰かの目に止まらないかな」と淡い期待を込めながらgithubにソースコードを上げてキャッキャウフフすることに注力するようになります。悪循環。
頑張ってシステムを完成させて、利用者から改善要望が来た場合、追加工数が無ければ何もしないと突っぱねます。要件の考慮漏れだったとしても同様。金を貰わずに作業をするのではビジネスは成り立たないのも理解できます。
多くの人が受託開発に見切りをつけようとしているこの状況を改善するには、継続的にシステムに携わることのできる契約形態を模索しなければならないと思います。
システム開発の成功は、QCDも確かにあるかもしれませんが、当初の予定通りの費用対効果が出たか、ということであるべきで、「完成したか」ではないはずです。ですが、一括請負の受託開発の場合、契約として成果物責任があるので完成させなければなりません。
小さな機能に分割して作りながら様子を見ながらやりましょうよ、と言ってますけど、基本的には開発側と利用者でゴールを共有しようよ、ということが大前提にあるはずです。
契約で縛り合うのではなく、良好な信頼関係を築くほうが生産性は何倍も上がるだろうし、多少の無理は聞くでしょう。基本的に開発側は利用者に喜ばれたいんですから。
一括請負の契約で縛ることで開発側は下手な見積を出すわけにもいかず、それなりに精査し、リスクを積み、失敗しないようにしようとします。時間もかかるし結局高くつくことでしょう。一括請負は「発注したシステムが完成しなかった」リスクを回避する為の契約で、「価値あるシステムを保証する契約」ではありません。
これからはシステム開発に関しても費用対効果を鑑みることが重要だと思います。「システムが完成しない」よりも「コストをかけて価値がないシステムを作った」方がよりリスクだと考えなければならないでしょう。
仕様の叩き台を元に開発(実現)するための工数と、得られる効果を天秤にかけて、実施のジャッジ／合意をするようにならなければ、システム化の目的がブレてしまいます。また、機能を詰め込みすぎてシステムが肥大化し、リプレースを行う時のハードルにならない様にするために、機能の棚卸も必要でしょう。使わないものは捨てる、部屋と一緒ですよ。
本来、そのジャッジはユーザ企業で行う必要があるのですが、社内システムを内製する文化にない企業では難しいでしょう。実現する為の工数が検討もつきませんから。そこで、信頼出来るパートナーを見つけることと、いつでも相談できるような契約を結ぶ、ということが必要だと考えます。
ユーザ企業と開発側が、契約でなく信頼関係で結ばれれば、受託開発も面白く感じる人が増えるんじゃないかなぁ、と考えます。幅広くそれなりのスキルがなければやっていけないと思いますけどね。ただ、厳しい時代には変わりない。
遅ればせながら、OS XをMountain Lionへupdateしました。その中で、開発していたRoR環境が動作しなくなったので備忘録的に。
unit testでエラーが出てしまいます。挙動が云々でなく、そもそもDBサーバが動いてねぇよ、的なメッセージ。
rake aborted!
could not connect to server: No such file or directory
Is the server running locally and accepting
connections on Unix domain socket "/var/pgsql_socket/.s.PGSQL.5432"?あれー？Posgres逝ったか？？と思って、ターミナルからpsqlを叩くと・・・接続できる・・・。なんじゃい、こりゃ？？で、ネット上に情報が落ちてないかウロウロしてた所、ありました。
API Only - Stack Exchange
どうも、database.ymlの中で接続先の指定をする際に、localhost上のPostgresを参照するので設定していなかったのですが、Mountain Lionにすると指定が必要なようです。
test: adapter: postgresql ・・・ host: localhost
hostを指定した所、動作しましたとさ。
