Intobox始動！！
Intoboxはもう駄目かもしれないという記事を書きましたが、あれからエラーの原因がわかり、やっと審査を通過することができました。
原因はFacebookの友達がいないユーザーでのみエラーが起こるというものでした。
友達がいないユーザーでテストしたつもりだったんですけどね。。。
これでDropBox認証が5人までしかできないという上限が外れたのですが、ガイドラインに沿っているかの審査があるらしく、アプリが公開できる状態になったらまた連絡してねと言われました。
Intoboxチームで集まって、いまの課題や今後どんな風に進めていくかということを話しました。
こんな感じです。
これから
- いまのデザインがいまいちなので、いけてるサイトにする
- エラーが起きたときの詳細がわからないので、トラッキングできるようにする
ここまでできたら広めていこうということで、全員の意見が一致しました。
サイトは使える状態なので、試してみて感想をもらえるとありがたいです。
不具合も色々出そうな気がするので、でたら教えてください。
このブログのコメント欄か、infoあっとintobox.inまでお気軽にどうぞ！
http://intobox.in
intobox.inはもうダメかもしれない
タイトル通りですが、intobox.inは窮地にたたされています。
昨年より、intobox.inの開発をしているとブログでも書いていましたが、開発も一通り終わったので、Dropboxに審査の申請を出しました。
というのも、DropboxのAPIはDevelop版では5人までしか認証ができないという制限があるのです。
その制限を外してもらうために申請が必要なのです。
審査は金曜日に出して、土曜日の朝にはもう返事が来ていました。
「Dropbox アプリプロダクション鍵不許可のお知らせ」というタイトルで・・・
愕然としながら内容を見てみると、エラーがでてるので直してねという内容。
アクセスログを見ると、たしかに500がでていました。
問題は、このエラーの発生原因がわからないというところです。
率直に言うと、「そんなエラーでないよ！」なのです。。。
Facebook APIを使っているので、もしかしたら友達が一人もいない場合にエラーが出るのかも、と検証してみましたが、エラーは起こらず。
原因は今でもわかっていません。
intobox.inを製作中
paperboy & co.でやったこと
paperboy & co.（以下、ペパボ）に入社して6ヶ月が経ちました。
ちなみにペパボはどんなことをやっているかというと、サイトのホスティングやドメインの提供など、主にインターネットの場所を提供することをやっています。
僕は担当しているサービスは昔からあるサービスでレガシーコードなのです。
で、この6ヶ月で業務をやりつつ開発環境の改善をけっこう頑張ってやっていました。
入社当時はどんな状態かというと、以下のような感じです。
一つの環境をみんなで開発していた
サーバ上のファイルにsambaでアクセスして開発していました。
誰かがファイルを変更していると同じファイルは触れません。
FTPで手動でファイルをアップロードしていた
デプロイの自動化ができておらず、FTPクライアントで手動でアップロードしていました。
バージョン管理ツールの本来の使い方ができていない
本来であれば、バージョン管理ツールのリポジトリからチェックアウトしたファイルを本番にデプロイするべきですが、ファイルをFTPで手動でアップロードしたあとにコミットしていました。
バージョン管理というよりは、バックアップ的なツールとして使われていました。
テストがない
テストがないので、ソースを修正したときの影響範囲がわかりません。
この環境を改善しようということで、半年間改善してきました。
現在は以下のような感じです。
個別に開発環境が持てるようになった
各個人でバーチャルホストを切って開発ができるようになりました。
VMを立ち上げてそこで開発することもできます。
VMの作成には、ペパボのテクニカルマネージャーのmizzyさんがつくったmaglicaを使っています。
webistranoでデプロイ自動化
ボタンクリックでデプロイができるようになりました！
SVNからGitへ移行
SVNよりGitのほうが使いやすい！
GitHubも使えますしね。
GItHubでの運用
ペパボではGitHubで運用しているサービスが多く、GitHubで運用していくことにしました。
それまで僕自身はGitHubを使ったことがなかったのですが、ショートカットやpull requestがとてもいい感じで気にいっています。
テスト自動化
基本的にはwebテストでやっています。
レガシーコードをテストができる形に書き直すのはコストがかかるので。
seleniumを使って書いたテストをJenkinsで自動化して実行しています。
結果はIRCに通知されます。
といった感じです。
苦労したところ
GitHubへの移行のところでけっこう苦労しました。
パスワードファイルは上げない方針だったのでソースファイルからそれらしいところを探して、外部ファイル化しました。
また、リポジトリと運用中のソースにけっこう差異があったので、その対応もけっこう大変でした。
基本的には、運用中のファイルを正として、よくわからない部分は既存の仕組みを知っている人に聞いたりして解決していきました。
次に、デプロイ自動化のところがけっこう大変でした。
webistranoのファイル構成は、DocumentRootがcurrentフォルダになります。
DocumentRootが変わると動かない部分がでてきたので、その部分を地道に直していきました。
これからやっていくこと
システムが古いので、ミドルウェアのバージョン上げたりしないと今後が厳しいかなといったところです。
まあ、その辺りは僕より詳しい人がいるので、僕はがりがりコード直していく感じになると思います。
あとは、レガシーコードというサバンナをオアシスに変えていけるように、テストを充実させていかないとなーと思っています。
gitのリモートリポジトリを消す2つの方法
git のリモートリポジトリの削除ですが、git 1.6以前は
git push origin :branch_name
のように、コロンをブランチの前につける必要がありました。
1.7から --deleteコマンドが追加されました。
git push --delete origin branch_name
ちょっと気になったのが、
git push --delete
や
git push --delete origin
とやってドッカーン！なんてことにならないかということです。
試しにやってみましたが、ブランチ指定してねーとちゃんとエラーになりました。
ユーザビリティ的に考えると
git push --delete origin branch_name
のほうが優れていますね。
git push origin :branch_name
知らない人が見たらどんな振る舞いをするか予測がつかないと思います。
ですので、これからは
git push --delete
を使うべきだろうなと思いますねー。
一括置換を簡単に使えるようにシェルにしてみた
一括置換を簡単に使えるようにシェルにしてみました。
使い方
sh bulk_replace.sh banana apple
カレントディレクトリ以下のファイルを対象に
banana→appleに置換します。
ダウンロード
git リポジトリからcloneしてください。
https://github.com/shoyan/utility-tools
さらに簡単に使えるようにする
実行権限をつけて、/usr/local/bin/以下などに置いておけばお手軽に使えます。
chmod +x bulk_replace.sh
mv bulk_replace.sh /usr/local/bin/
bulk_replace.sh banana apple
