vagrantの共有フォルダのアクセス権とグループを設定する

ホストはOSX, ゲストはUbuntu, VMはVirtualBox

Vagrantfileを用意

ラクちん便利なVagrantfileジェネレーターのPuPHPet。
この PuPHPet – Online GUI configurator for Puppet & Vagrant にcommmon.yamlをドラッグアンドドロップすると僕の生成した設定が復元されます。

common.yamlはこちらのgistから

Read more vagrantの共有フォルダのアクセス権とグループを設定する

PHPのCIをwerckerでも試してみた

PHPでCIするTravis CIとdrone.ioを試してみた” 書いた直後 wercker というにおもしろそうなCIホスティングサービスを見つけた。

wercker

  • 見た目が今っぽい(重要)
  • ベータ期間中
  • なんかSNSっぽい機能がある(ユーザのフォローができる)
  • boxと言う環境構築のレシピみたいのがある
box: wercker/php
build:
  steps:
    - script:
        name: install dependencies
        code: composer install --dev
    - script:
        name: PHPUnit integration tests
        code: phpunit --configuration phpunit.xml.dist

バッチを貼ってみた。
Wercker status

感想

まだベータということもあって今後の料金プランとか趣味で利用する場合は気になるけど、SNS機能を取り込んできたのは斬新だなと。CIって秘伝のタレ的になりがちな気がするんだけどその辺共有できたらおもしろい。

Posted in

PHPでCIするTravis CIとdrone.ioを試してみた

ずっと前から試してみたいと思っててようやく試すことができた。

  • Travic CIdrone.ioはどちらもパブリックレポジトリであれば無料で利用できる
  • どちらもセットアップが簡単

他にもCircleCICodeshipwerckerというのがあった。

  • CircleCIは無料プランがなかった(最初の14日は無料っぽい)
  • Codeshipは月50ビルドまで無料。プライベートレポジトリも可!(今度ためしてみよう)
  • werckerはこの記事を書いてから知った。必ず試す。

Read more PHPでCIするTravis CIとdrone.ioを試してみた

Posted in

MBAクラムシェルモードとデュアルディスプレイ

MacBook Airにサンダーボルトのポートがもう一つ増えたら新型に買い換えようと考えていましたが、増えなかったので相変わらず 13-inch, Mid 2011 を使ってます。

ここ最近の猛暑の関係でMBAのキーボードが熱い→手が暖められる→眠くなる→納期やばいと言うことで、この状況を打開すべくUSBグラフィックボードを購入しました。

現在は

  • クラムシェルモード
  • ディスプレイディスプレイ(マルチモニタなど呼び方いろいろ)
  • USBキーボード
  • Magic Trackpad

で作業してます。

その調子が期待していたよりずっと良かったので共有します。

Read more MBAクラムシェルモードとデュアルディスプレイ

ネット越しにXdebugでリモートデバッグ

ちゃんと理解してないかもだけどメモ。

リモートデバッグと言われると、借りたVPSとかでも今までと同じようにデバッグできると思ってたけど、それは違ったみたい。

おそらく同じネットワーク内にいるか、それっぽくしないとダメな様子。

すぐ思いつくのはVPNだけどセットアップが手間だな〜と思ってたけどSequel ProみたいにSSHトンネルで接続ってどうなんだろと思って調べてみたらできた。

$ ssh -R 9000:localhost:9000 username@dev.example.com

Read more ネット越しにXdebugでリモートデバッグ

Meteor jsの今(2013-07-03)について

png

日本でもリリースされた2012年にはすこし盛り上がってた様子で、2013年の4月には東京でMeetupがあったようです。しかし現在、検索できる形で観測する限りユーザは増えておらずもったいないな〜思い“Meteorの今”についてこの記事でアピールしていこうと思います。

まず、日本語でMeteorについて検索してみると辿り着くおすすめ記事三本

そしてこの記事では、naoyaさんの当時のMeteorに対しての“まだ微妙なところ”を引用しつつ現在 0.6.4はどう変わったのかという話しにしたいと思います。

前提としておそらく当時のバージョンは0.4.1より低いと思われます。

以下、Meteor.js – naoyaのはてなダイアリーからの引用

“できたばかり” という感じは否めない。たとえば Minimongo によるモデルには認証の仕組みが全くない。Minimongo はクライアントサイドで操作もできる上にそれがサーバサイドにも反映される。なのに認証がない = アプリケーションに保存された全データをクライアントでいじり放題、ブラウザの Console からでも操作できる。つまり、まだまともなデータベースアプリケーションを作れるフェーズではない (認証がない点については、ドキュメントにもそう書いている)。 認証だけでなく、そもそも Minimongo の機能がちょっと少ない。

Meteor 0.5.0より認証機構が用意され

Meteor.allow

Meteor.deny

によって権限のコントロールが可能になりました。通常のパスワード登録に加え、Google、Twitter、Facebook、GitHubなどのoauthのパッケージも追加され

{{loginButtons}}

とテンプレートに記述するだけでユーザ認証が可能になりました。

Reactive Programming しようとすると、モデルの操作含めクライアントサイドにコードが集中していってサーバサイドではほとんど何もしないということが多い。それはそれで一見良いようで、そうするとせっかくバックエンドに node.js が控えているのに、node_modules をうまく活用できなかったりする。例えばモデルから find() で引っ張ってきたデータの加工に md5 な処理を加えよう・・・サーバサイドだったら md5.js を npm install して require すればいいところ、実はクライアントサイドにコードを書いているのでそういうわけにいかない。モジュール開発が活発な node という一番良いところがスポイルされてしまっている

Meteor 0.6.0からMeteorのパッケージ側からはNPMを

Npm.require

で利用できるようになったようです。さらに2013/6/15にComplete NPM integration for Meteor – MeteorHacksでユーザ側からもりようになりました。

「しょうがないので md5.js とかインターネットで見つけてきて script タグで読み込ませるか・・・」と思っても、Dirty Hack なしでうまくそれを実現できる方法がない。そういう細かいところの作り込みがまだまだ。この辺は時間が解決するとは思うけれども。

上記の通り解決されたと思われます。

Reactive な要件を満たすためにもフルスタックにしているんだろうというのはなんとなく想像できるのだけれど、たとえば npm ではないパッケージ管理システムを自前で持っていたり (その分、フレームワークによりモジュールを簡単に統合できるようになっているのだけど)、Minimongo しかり、さすがにいろいろ作りすぎている。この作り込み具合でまともにプロダクションで利用できるレベルを維持しようとすると、開発コミュニティが相当活発になる必要があってそこは結構リスクだと感じる

これは今でも続いている問題だと思います。しかし、ソフトウェア開発がホットな投資対象: JavaScriptフレームワークMeteorにAndreessen Horowitzが$11.2M | TechCrunch Japanという話もありとりあえずは大丈夫なのかと。

以上、引用とコメント終わり。

と言うことで、Meteorはかなり使える状況に近づいてきたとおもいます。一年前に触ってそれっきりの方も、これから触ってみようと言う方もMeteor楽しいですよ!

おしらせ

日本語でもMeteorについて雑談がしたい思い、なかったのでMeteorの日本語ユーザコミュニティを作ってみました。ぜひご参加ください。Meteor JP – Google+

リンク

TypeScript+PHPStorm+homebrewの設定

TypeScriptをPhpstormでコンパイルしようとしたら、

env: node: No such file or directory

って出てちょっとハマったのでメモ。

環境

  • Mac
  • Homebrew
    • node
    • npm
  • PhpStorm/WebStrom

Preferences > File WachersでProgramに

/usr/local/share/npm/bin/tsc

を、Environment variablesには

$ env

で吐き出すPATHを全部突っ込んだらエラーが出なくなった。

Edit_Watcher
Environment_Variables

Meteorの秘密情報は/server以下に書くべき

タイトルで書ききりましたが、以下のように

$ meteor create myapp

直後のルートにあるJavaScriptを利用した場合だとデプロイ後のJavaScriptファイルに”HIMITSU”が含まれています。

if (Meteor.isServer) {
  Meteor.startup(function () {
    // code to run on server at startup
    var fuga = "HIMITSU";
    console.log(fuga);
  });
}

以下だとソースに含まれない

if (Meteor.isServer) {
  Meteor.startup(function () {
    // code to run on server at startup
    var fuga = "HIMITSU";
  });
}

みたいな事がおきるようです。なのでMeteorの秘密情報は/server以下に書くべきです。