2016年7月8日のブックマーク (7件)

  • Continuous deployment to App Engine from Circle CI by Gradle - GeekFactory

    Circle CIを利用して、JVMベースのアプリをGoogle App Engineにデプロイする作業を自動化してみました。 うれしいこと 誰でも簡単にデプロイできる CIやPull Requestレビューを通過したコードのみデプロイできるように制限できる ビルド環境の差異による影響を排除できる 基的な考え方 ざっくりとした流れは以下になります。 GitHubにmasterをpushする Circle CIでビルドが実行される ./gradlew build でビルドする ./gradlew appengineUpdate でデプロイする App Engine SDKはgradle-appengine-pluginが自動的にダウンロードするように設定します。また、デプロイにはService Accountを利用するため、あらかじめ https://console.cloud.googl

    Continuous deployment to App Engine from Circle CI by Gradle - GeekFactory
    int128
    int128 2016/07/08
  • Google AppEngine - Custom Domain + SSLが簡単になった - Qiita

    Google AppEngine で独自ドメイン + SSL を使うとき、以前だったら Google Apps を経由しないといけなかったのですが、日 Apps なしで Google Developers Console から直接設定する機能がリリースされました。 Announcing SSL for GAE Custom Domains in the Developers Console さっそく試してみました。 まずは Custom Domain を登録する Adding a custom domain for your application Developers Console の Compute > AppEngine > Settings で Custom Domains タブをクリックして "Add a custom domain" ボタンをクリック。 未登録のドメインであ

    Google AppEngine - Custom Domain + SSLが簡単になった - Qiita
    int128
    int128 2016/07/08
  • 「共有会」, 「連絡会」の功罪, 或いはグループを横断した情報共有について - Masteries

    複数の事業(部署)を持つ会社, 或いは複数のチームを持つ部署において, 部署やチームといった"グループ"を横断した情報共有は, 非常に重要です. 特にエンジニア組織の場合, あるグループの課題を解決するソリューションを別のグループが持っていたり, 或いはあるグループの知見を別のグループが欲しがっていたりするものです. そのため, 会社が複数の組織を持つ利点, そして部署が複数のチームを持つ利点というのは, 適切な規模のグループで結果を出し, そこから得た成果物や知見をグループを横断して展開できるところにある, と思っています. ...とはいえ, この「グループを横断した情報共有」というのは, 言葉にすれば簡単ですし, みんな「そうあるべきだ!」と思うものだと思いますが, 実際にそれを実施していくのは簡単ではありません. 人間どうしても忙しくなると「目の前」, つまり「自分が所属しているグル

    「共有会」, 「連絡会」の功罪, 或いはグループを横断した情報共有について - Masteries
    int128
    int128 2016/07/08
    社内でブログや勉強会をやる方法もあるけど、ミーティングスペースで適当に集まって飲むのが最も効果的だった気がする(経験上)
  • npm で依存もタスクも一元化する - Qiita

    タスク管理 package.json にはパッケージの依存を書いて npm install するのが基だけど、 タスクの管理をどうするかというのは、別途また考えないといけない。 自分は gulp が良いと思っているが、 grunt や jake や make を使う人もいる。 また、たくさんオプションをつければほぼ一つのタスクが実行できてしまう browserify, jsh/eslint, mocha などのコマンドを提供するツールもある。 そして、 npm にも一部それらをサポートする npm run 機能があるので、そこに Unix ワンライナーを書くこともできる。 今回は、「どのタスクツールが最良か」みたいな話ではなく、それらをどうやって実行するか、または npm との棲み分けとか構成の流儀について、最近良いと思っているやり方について書いておく。 各方針で問題点を書いていくが、

    npm で依存もタスクも一元化する - Qiita
    int128
    int128 2016/07/08
  • タスクランナーを使わずに webpack だけでフロントエンド開発する方法 – Web Application Security Memo

    注意:この記事では Babel 5 を使っています。 Babel 6 を使用する場合は、このままだと動作しません。対応方法は、Quick guide: how to update Babel 5.x -> 6.x — Medium 等を参照して下さい。 Grunt や Gulp などのタスクランナーを使わず、webpack だけでフロントエンドを開発する方法を調べてみました。 以下、実際に簡単なウェブアプリケーションを作ってみます。 環境 webpack 1.12.0 ESLint v1.2.1 OS X 10.10.5 前提条件 JavaScriptは ECMAScript 6 で書けるようにします。但し、今回の記事内では ECMAScript 5の文法のみ使用しています。 CSSファイルは webpackで処理することにより、JavaScript のコードで表現されるようになります。こ

    タスクランナーを使わずに webpack だけでフロントエンド開発する方法 – Web Application Security Memo
    int128
    int128 2016/07/08
  • Infrastructure as Codeと組織構造

    2. 吉羽龍太郎 / Ryuzee.com ✤ アジャイル開発/DevOps/クラウドに関する従量課 金型コンサルティングサービスを提供 ✤ http://www.ryuzee.com @ryuzee 3. コンテキスト設定 複雑な領域 探索 理解 反応 カオスな領域 行動 理解 反応 込み入った領域 無秩序 な領域 理解 分析 反応 明白な領域 理解 分類 反応 ✤ 1チーム〜数10チームくらいの規模を想定 ✤ とてもお硬い領域というよりは変化の大き い領域の話 4. Infrastructure as Code (1) ✤ なんらかのアプリケーションを動かすためのインフラをコードで記述すること ✤ コードで書くことで再現性を高められる (はず) ✤ コードで書くことによって、ソフトウェア開発のプラクティスがインフラにも適用可能 になる

    Infrastructure as Codeと組織構造
    int128
    int128 2016/07/08
  • 【新機能】Amazon Elastic File System (Amazon EFS)がついにGA (一般利用可能)に! | DevelopersIO

    CloudWatchには[BurstCreditBalance]という項目がありますので、こちらをチェックしてみるとどれくらいの容量が必要か見積が出せると思います。 非同期書き込み EFSは共有ストレージ、ということで非同期による書き込みが出来るようにマウント時に非同期オプション(async)をつけることができます。その場合バッファはEC2内にキャッシュされます。 またパフォーマンスを確保するためにはEC2そのもののメモリやCPU処理能力も関係します。パフォーマンスが出ないと感じた時はインスタンスタイプを上げてみるのも手です。尚EBS最適化されたインスタンスでもEFSにはその影響はないので注意しましょう。 制限事項 その他制限事項を羅列します。 最大ファイルシステム数: 10 AZ毎の最大ターゲットマウント数: 1 ターゲット毎の最大セキュリティグループ数: 5 ファイルシステム毎の最大タ

    【新機能】Amazon Elastic File System (Amazon EFS)がついにGA (一般利用可能)に! | DevelopersIO
    int128
    int128 2016/07/08