しょ〜うぃん広場

おもにTech系なブログ、ときどき個人的なブログ

初めてのPull RequestがMergeされた!

今日GitHubで初めてのPull Request(以下PR)がmergeされたので、mergeされるまでの一連の流れを書いてみようと思う。 showwinみたいな素人プログラマのPRでもmergeされることがあることを示して、だれでもOSS(オープンソースソフトウェア)の開発に貢献できるんだということを伝えたい。

『脱 PR童貞!!!』

1ヶ月前ぐらいに、「OSSの開発してみたいなぁ」って思って、PRの送り方とかネットで調べてみた。 コードを書いてPRを送ることももちろんひとつの貢献だし、普段使っているライブラリやソフトで不満に思っていることをissueとして投稿することもひとつの貢献方法らしい。

ぼくはコードを書いて、それを製品のなかに取り入れて欲しかったから、自分が開発できそうなプロジェクトをGitHubであちこち探した。  

Railsで開発するときに、通知機能の部分でよく使っているtoastrでこんなissueを見つけた。 Screen Shot 2014-10-05 at 11.47.24 しかも、enhancementついてる。  

中身を見てみると Screen Shot 2014-10-05 at 11.50.09 上中央に表示される通知をみんな欲しがっているぞ!!! (toastrには右上、右下、左上、左下、上Full-width、下Full-widthの6種類の通知場所しかなくて、みんな欲しいと言っているのは上中央に適度な大きさで表示される通知)

ちなみにぼくもこの上中央に表示される通知が欲しくて、なんとすでにその部分を自作して使っていた!

ownerも "feel free to open a PR." と言っていることだし、 オリジナルのプロジェクトから自分のレポジトリにforkして、 変更が必要な部分を自分のローカルtoastrからコピペして、上中央に通知を表示させるtoast-top-centerのpositionを作成した。

それで送ったのがこのPR
Screen Shot 2014-10-05 at 12.10.59
初めてのPRだから、ちょっと手間取ることもあるかもだけどよろしくって一応書いとく。

しっかり動くのを見せるために@uiureo氏が作ったGifzoを使って、Gif画像も載せておく。 (Gyazo GIFを使わずにGifzoを使ってるのは、個人的にはこっちの方が使い勝手が良いから。)

PR投稿してから、20日ぐらいずっと放置されていたんだけど、 ある人(Eagle3386)が、「おれのプロジェクトでtop-centerの機能が必要なんだよ!早くmergeしてくれ!」って3日前にコメントしてくれて、そこから管理人達も加わって、いろいろと話が進んでいった。

詳しくはPRのページを直接見てもらえればいいけど、 この後の流れとしては、

top-center作ったんだから一貫性保つためにbottom-centerも作ってね」 「toastr.cssだけじゃなくて、.lessと.scssと.min.cssのupdateも頼むね」 「今回作成した部分のUnit tests作ってくれる?」

って感じ。 それぞれぼくが対応して、最後にCollabolatorの人にfinal lookしてもらって、問題なかったので無事にmergeされた。  

いきなり2200★StarぐらいついてるプロジェクトにPR送ってしまって、ちょっと怖かったけど、このファイルが足りないよとか丁寧に教えてくれたから、特に問題はなかった。 issueでも+1が連発されてたし、PRの中でも「この機能が欲しいんだ!」って言ってくれる人がいたので、今回この機能を自分が追加できたのは満足度が高い。

PRを送ったことがない人は、自分が貢献できそうなプロジェクトを探してPRを送ってみるといいと思う。

『脱 PR童貞!!!』

クックパッド 5-dayインターンシップ に参加してきた

9月1~5日の5日間、クックパッド(COOKPAD)の5-dayインターンシップに参加してきた。 選考からインターン内容まで、ひと通り書いてみる。

きっかけ

きっかけは@uiureo氏のツイート

(交通費支給されることに惹かれたわけではないけど…笑)

自分は4回生だし、日本で就職する予定もないから今年はインターンに行くつもりはなかったんだけど、 優秀なエンジニア(特にRubyist)が多いことでクックパッドは気になっていて、 今までコードを書く系の開発インターンには参加したことがなかったこともあって申し込むことにした。

選考

2時間の技術系Webテスト
 ↓
Skype面接
 ↓
インターン決定!
な感じだった。

Webテストは中身ヒミツにね!って言われたから割愛。 Skype面接は技術系のことを深く聞かれることもなく、「普段どんなことに気をつけて開発してる?」的なことを聞かれた気がする。"面接"って感じじゃなくて、雑談してる感じだったから、気付いたら終わってたし、あんまり中身覚えてない。 (人事部の方々は事前にFacebookで確認済みだったから、特に緊張することはなく…笑)

長期インターン/バイトの案内も頂いたんだけど、自分は就職は考えてなかったり、日程的にも都合が悪いこともあって、結局短期インターンに参加させていただくことになった。 ありがとうございます!

インターンまで

今回はモバイルネイティブアプリの開発インターンで、Androidで開発するかiOSで開発するか事前に選択する感じだった。 Apple信者なので、もちろんiOSを選択したけど、 Apple信者なのに、普段はRuby,RailsでWeb系ばっかりやってるから、 Obj-CとiOS開発の勉強を事前にやらないとなー やらないとなー やらないとなー … と思いつつ、気付いたらインターン1週間前。

1週間あったら余裕だろと思ってたけど、実際に勉強し始めたら、Web開発との違いにかなり戸惑って、かなり焦った。 2日間Obj-Cの勉強して、3日間ネイティブアプリ開発の勉強して、 「事前にこんなサンプルアプリを練習で作ってきてね!」なアプリも完成することなく

インターンに突入!

5日間のインターン

そんなクソ技術力でインターンに臨んだわけだけども、結論から言えば最終日には作りたいアプリは完成した! (バグは残っていて、発表時のDEMOでもちょっと上手くいかなかったけど…笑)

iOSAndroidと1人ずつメンターの方が5日間ずっと付いてくれていたから、わからない部分はすぐに聞くことができたし、インターン参加者にも「バイトで4年間iOS開発してます!」なすごい方がいて、いろいろ教えてもらえて良い環境だった!

  インターンの内容は、総合職(ディレクター役)とエンジニアが二人一組になって、 クックパッド公式アプリで解決できていない問題を解決する」アプリを作成する課題に取り組んだ。

クックパッドは「問題解決」にすごい重きをおいていて、社員さんからのフィードバックも「それはどんな問題を解決してるの?」とひたすら突っ込まれた記憶がある。

(ユーザ)は
(欲求)したいが
(課題)できないので
(製品の特徴)することに価値がある

明確にすることを常に求められた。

“技術力"があることはもちろん重要だけど、 それがあることが前提で、それを"どう使うのか"を常に考えている会社だなという印象を受けた。

そういう意味では、技術力だけではなくて、ものづくりに対する姿勢も勉強できた、素晴らしいインターンだったと思う。

まとまらないまとめ

たった5日間でも「問題解決」という会社の方針がビンビン伝わってきて、社内全体で考えが共有されているのがすごくよくわかった。 どんな方針であれ、組織全体で考えを共有できているというのはやっぱりすごい強いと思うんだけど、 クックパッドは最近海外企業をいくつか買収していたりして急速にスケーリングしている。 そういった状況の中で、いかに方針を 共有する/浸透させる ことができるかが、これからも強い組織であり続けるためのキーポイントになるのかな、と思ったりもした。 (どの立場で言ってんだよ!!笑)

大事なことなのでもう一回言うけど、 総合職の非エンジニアも、もちろんエンジニアも、ものづくりに対する「問題解決」の姿勢を学ぶことができる最高のインターンです!!

人事部の方々、技術メンターの方々、共に全力を尽くしたインターン参加者のみんな、 楽しい最高の経験をさせていただき、本当にありがとうございました。

おまけ

なんと、rebuild.fm@miyagawaさんが取材で日本オフィスにいらっしゃっていて、インターン生のrebuildリスナーで一緒に写真を撮らせてもらいました! IMG_6438

Macで常時VPNを繋いでおくFeVPNをリリースした

2日前にMacでVPNを繋ぎっぱなしにするAppleScriptという記事をあげたけど、それを少し改善して、Macのネイティブアプリを作った。

FeVPNという名前で、Forever VPNの意味。
Screen Shot 2014-08-01 at 22.32.14

ダウンロード: http://www.showwin.asia/contents/FeVPN/FeVPN.zip ソース + 説明: https://github.com/showwin/FeVPN

  詳しい説明はGitHubのREADME)を見てもらうとして、ここでは簡単な説明。

システム環境設定の、 FeVPN_11

サービス順序の優先度が一番高いVPNを、 FeVPN_13

15秒毎に繋がっているかどうか確認して、繋がっていなければ再接続!!! FeVPN_notification

以上!!

シンプルですねぇ。

 

前回の記事からの内部的な変更点は、VPNの名前を自分で入力しなくても、自動的に取得してくるようになったこと。 それによって、ソースコードを何も変更しなくても簡単に使えるようになった。

常にVPNを使い続けたいけど、ネットワークの接続が不安定でよくVPN切れる。 ことで困ってる人をユーザとして想定してるんだけど、 そういう人って、中国とかベトナムとかその辺に住んでる外国人ぐらいな気がしてて、 あんまり需要ないかなーという気もする。 でも、自分や彼女を含めて、困ってる人はかなり困ってるはずなので、そういう人に使ってもらえればいいかなと思っている。

[追記] 1.1.0をリリースしました。
ブログ記事: 30倍使いやすくなったFeVPN 1.1.0をリリースした! ダウンロードはこちら

MacでVPNを繋ぎっぱなしにするAppleScript

MacVPNを繋ぎっぱなしにするAppleScript を90%コピペで作成した。 中国にいるときはTwitter,Facebookとか見るために常時VPN使ってるし、 べつにVPN繋ぎっぱなしでもデメリットないから、ずっと繋げておくことにした。 (国内にいても、家からニコ動に繋ぐと途中の回線がどこか細いらしくてかなりプツプツするので、VPN使ったりする。)

VPN AppleScript」とかググると下のようなコードがいくつか出てくるんだけど、 2箇所だけ変更した。

on idle
  tell application "System Events"
    tell current location of network preferences
      set myConnection to the service "My VPN"
       if myConnection is not null then
        if current configuration of myConnection is not connected then
          display notification "Connecting VPN..."
          connect myConnection
        end if
      end if
    end tell
    return 15
  end tell
end idle

変更したのは7行目と12行目。

7行目で画面右上にNotificationを出してる。 再接続するときに"Connecting VPN..."と表示するようにした。 「気づかないうちに接続切れてて、知らないうちにに再接続される。」 みたいなことされると、気づかないうちにSSHのパイプ切れたりするから 一応繋ぎますよ〜って通知出すようにした。

12行目はVPNが繋がってるかどうかを確認する周期を15秒にしてる。 「ん?なんかサーバーからのレスポンスない!?」と思ってリロードするまでにだいたい15秒ぐらいな気がしたから、15秒以内に再接続されるようにしておくと、いいかなと思った。

あ、そうそう。 使うときには4行目の"My VPN"をここの名前に変えてね。
Screen Shot 2014-07-30 at 10.56.10

上のAppleScriptを使ってアプリケーションを作成する方法は Mac OS X起動時にVPNで自動接続&途切れても再接続するように設定できる を参考に。

参考サイトに書かれているように、アプリアイコンをDockに表示させないようにすると "VPN Auto Connect" のアプリを終了することができなくなる。

どうしても終了したいときにはターミナルで

$ kill -9 `ps -ax | grep '[V]PN Auto Connect' | awk '{print $1}'`

とやってあげると終了できる。

  へへへ、これで中国でのネット生活も充実するぜ

【Rails】GitHub Webhooks + Sinatraで自動デプロイ環境を作った

今までRailsWebサービス開発するときには、
1. ローカルで開発
2. GitHubにPush
3. サーバーにSSH
4. サーバーでGitHubからPull
5. Apacheの再起動

とかかなり原始的な方法をやってたんだけど、さすがに面倒に感じてきたので 3~5の手順を自動化しようと思って、やってみた。

Railsでデプロイ自動化といえばCapistranoが定石っぽいけど、 なんか設定めんどくさそうだし、バージョン管理しようとすると $ git push $ cap deploy とか2つコマンド実行しないといけなさそうだし、 Capistrano複数個のサーバーにデプロイできるけど、 そんな機能はぼくにとってオーバースペックだし… ってな感じで、Capistranoはパス。

最近は「GitHub 時代のデプロイ戦略」に書かれているみたいに、CIを使うのがナウいらしいけど、個人でそこまでやるのは… ってな感じで、CIはパス。

まぁ若いうちはできあいのものに頼るなってのもあるし(適当) WebHookしてみたい!って憧れもあったので、今回はGitHub Webhooks + Sinatraという形で作ってみた。

 

ここから本題

作成したコードはGitHubにおいてあるので、適当にcloneして、適宜書き換えてください。 GitHub: Automatic-Deploy-Tool-for-Rails

今回はhttp://example.comRails appが動いてるとして、http://deploy.example.comGitHubからPOSTリクエストを投げてもらうことにしました。 Apatcheの場合は/etc/httpd/conf/httpd.confをこんなふうにすればいいと思います。 Passengerの方の設定は変更の必要はありませんでした。

<virtualhost *:80>
 servername example.com
 serveralias www.example.com
 documentroot /var/www/example/public
 railsbaseuri /
 <directory /var/www/example/public>
   allowoverride all
   order allow,deny
   allow from all
   options -multiviews
 </directory>
</virtualhost>
 
<virtualhost *:80>
 servername deploy.example.com
 serveralias deploy.example.com
 documentroot /var/www/deploy/public
 RackEnv production
 <directory /var/www/deploy/public> 
   allowoverride all
   order allow,deny
   allow from all
   options -multiviews
 </directory>
</virtualhost>

/var/www/deployのところにAutomatic-Deploy-Tool-for-Railsを配置します。

$ cd /var/www/
$ git clone https://github.com/showwin/Automatic-Deploy-Tool-for-Rails.git
$ mv Automatic-Deploy-Tool-for-Rails deploy
$ cd deploy/
$ echo '<Rails-app path> <root-user password>' >> pathpass.txt
$ touch log.txt

[Rails-app path]はデプロイしたいディレクトリのパス、今回だと/var/www/exampleになります。 [root-user password]はApacheを再起動する際($ sudo service httpd restart)に使うものです。

 

最後にGitHub WebHooksの設定。 管理したいレポジトリのページに行って、 画面右側メニューの「Settings」→「Webhooks & Services」→「Add Webhook」 でPOSTリクエストを送りたいURLを指定できます。 今回であればhttp://deploy.example.comを指定します。

以上!

完成

これでGitHubにPushすると以下の4つのコマンドを行ってくれます。

$ git pull origin master
$ rake assets:precompile RAILS_ENV=production
$ rake db:migrate RAILS_ENV=production
$ sudo service httpd restart

かんたんだな〜 (いろいろハマってこれ作るのに4時間かかったけど…)


なんか手順書き忘れてる気がしないでもないので、うまくいかなかったら @showwinに連絡ください。

GitHub Webhooks + Sinatra のJSON Parseでハマった

題名のとおりです。

いろんなサイトを見ていると GitHubのサイトに以下のようなSinatra向けのサンプルがあって…

post '/' do
  push = JSON.parse(params[:payload])
  "I got some JSON: #{push.inspect}"
end

とか書かれてたから、そのままやってみたんだけど どうもJSON.parseの部分で引っかかってうまくいかない。

と思ってGitHubのWebHookの説明サイトに行ったら、サンプルコードが変わっていた!!

post '/payload' do
  push = JSON.parse(request.body.read)
  puts "I got some JSON: #{push.inspect}"
end

JSON.parse(params[:payload])JSON.parse(request.body.read)に変えたらイケた。

Sinatra詳しくないし、JSONも詳しくないから、 どこのバージョン変更で動かなくなったのかよくわからないけど、 ここで2時間ぐらいハマったので、一応備忘録として残しておく。

MacでSSL証明書を復元する

すみません、タイトルは誤りです。

自分が困ったときに「Mac SSL証明書 復元」とかググったので、タイトルこの方がみんな来るかなーとか(笑

あれですよね、OS X 10.9.2になってからGitHubにアクセスするときにSSLの証明書がどーとかこーとかで、上手くアクセスできないから、あるSSL証明書を削除しましょう! みたいなことがあるじゃないですか。

[参考]http://orangain.hatenablog.com/entry/2014/03/01/mavericks-ssl-certificate

で、ぼくもそれと同じことをやるんですけど、今回のこの作業をやるのが3回目で、

「あぁ、またこれか、"DigiCert ..."とかいうやつ消せばいいんでしょ」

と思って、一番最初に見えた"DigiCert"なんとかってやつを消しちゃったんですよ。

そうしたら、本当は必要だったSSL証明書を削除してしまったみたいで、 もちろんGitHubは見れないままだし、Twitterとかその他サイトも見れなくなってしまって…

あ、これ間違ったわ。復元しよう!と思ったんですけど、

上の参考をページ見るとこう書いてあるんですよね。

注意:証明書の削除は間違って行うと、正常なWebサイトにアクセスした時にも警告が出るようになり、元に戻せません。自己責任で行ってください。

はい、事実です。Keychainの初期化とかしても証明書は消えたまま… ググっても解決方法出てこない。(他にこんなバカな事する人いないのかな…) もしかして、、、OSクリーンインストール…(泣)

とか思ったんですけど、そんな事する必要ありませんでした。 というお話。

前置き長いですね。

 

結論

DigiCertの証明書を消してしまったなら http://www.digicert.ne.jp/howto/basis/digicert-root-certificates.html からダウンロードしろ!

 

SSLの仕組みを理解しないといけませんでした。

そもそももとからMacに入っているSSLサーバ証明書はなんのために使われているのか。 (以下間違っていたらすみません)

SSL通信するサイトにアクセスするときに、そのサーバが持っているSSLサーバ証明書が本当に信用できる証明書かどうかをまず判断するようです。 そこで、その判断に使われるのが、最初からOSに入っている証明書。(正式名称:クライアント証明書)

クライアント証明書によって「あぁ、このサーバの証明書信用できるよ!」ってわかると、そこのサーバーから公開鍵をもらって、セキュアな通信をするようですね。

 

それで、そのクライアント証明書はSSLサーバ証明書を発行している機関からダウンロードできるみたいです。 今回僕はDigiCertのクライアント証明書を消してしまったので、公式HPからダウンロードしてきて、Macに適用(インストール?)しました。

インストールするには、ダウンロードしてきたファイルをダブルクリックするだけです。 「証明書を追加しますか?」 みたいなことを聞かれるだけなので、Yes!したらすぐに完了しました。

おしまい。

 

いやぁ、あの時本当に焦ったけど。直ってよかった。