2015年11月4日のブックマーク (10件)

  • Capistrano3のデプロイフレームワークの使い方 - Qiita

    Capistranoはバージョン3から汎用的なデプロイフレームワークになりました。タスクのフックを利用することで簡単に自分のアプリケーション環境に特化したデプロイプロセスを記述することができます。 稿では、この汎用化されたデプロイ機能の使い方に焦点を絞って解説したいと思います。より基的なCapistrano3の解説は 入門 Capistrano 3 ~ 全ての手作業を生まれる前に消し去りたい | GREE Engineers' Blog がよくまとまっているので、そちらを参考にしてください。この参考記事では "5. Capistranoデフォルトタスクの消去" でCapistranoの新規導入時のコストを下げる目的で、このフレームワーク機能を消去しています。稿はこのフレームワーク機能の使い方を解説するものです。 deployとframeworkの2つの抽象度が用意されている Capi

    Capistrano3のデプロイフレームワークの使い方 - Qiita
    to_tu
    to_tu 2015/11/04
  • capistrano 3 をできるだけシンプルにサーバーにコマンドを流し込むツールとして使いこなす - Qiita

    戦略 Railsのことは忘れる(そういうこともあるよ) capをサーバーにsshでコマンドを送り込むrake taskの塊と見る 「とある役割のサーバー」に対して「とある処理」を実行して回りたい、という場合を想定 単にrestartだけ切り出して実行するとか、あるコマンドの結果だけ手に入れるとか 個人的にはansibleでもできると思ったけどrubyメンバーに強要できないし、小回り効かせたい 準備

    capistrano 3 をできるだけシンプルにサーバーにコマンドを流し込むツールとして使いこなす - Qiita
    to_tu
    to_tu 2015/11/04
  • Linux creator Linus Torvalds had a meltdown over a pull request, and it was awesome

    to_tu
    to_tu 2015/11/04
  • さいつよのターミナル環境を構築しよう - Qiita

    昔に書いたものなので余り参考になさらずに 僕はターミナルに引きこもっています。たまに外出しても最寄りのブラウザ程度です。そんな僕は Mac を使っています。綺麗な UNIX だからです。ターミナルアプリとしてターミナル.app を使っています。iTerm2 含めいろいろ試しましたがコレがさいつよでした。そして、僕は 2 年半かけてさいつよ環境を築き上げました。 tl;dr 最強のターミナル開発環境の構築する 最強の開発環境を目指して タイトルで豪語しすぎた感はありますが、気で構築中です。僕がターミナル環境の整備に目覚めたのは学生の時でした。特に何かのプロジェクトに携わるといったこともなく、たまに講義の課題を解いたり趣味のアプリを作成したりといった程度での開発だったので、環境構築や整備に割く時間がありました。 まずは現状 普段のターミナル環境は次のとおりです。 ターミナル.app(全画面)

    さいつよのターミナル環境を構築しよう - Qiita
    to_tu
    to_tu 2015/11/04
  • 実績を解除してエンジニアスコアを上げろ!はてなのエンジニア実績システムのご紹介 - Hatena Developer Blog

    こんにちは、id:onishiです。今日もはてな技術部の取り組みを紹介します。今回のネタは「エンジニア実績システム」です!ちなみに前回は「毎週勉強会」を紹介しました。 エンジニア実績システム はてな技術部では、ブログの公開やOSS活動、イベント登壇など社外にプレゼンスを発揮する活動を推奨するための取り組みを行っています。今回紹介する「エンジニア実績システム」もその一つです。 実績とは何ですか? 実績とは、特定の行動をゲームで達成したことに対するリワードです。 Xbox One の実績とチャレンジ 「実績」とはXbox 360, Xbox One に搭載されている同名のシステムを意識しています。Xboxのそれがゲーム内の進行状況や難易度の高い行為によって報酬を獲得できるのと同じように、エンジニアの社外プレゼンス活動に対して実績を設定し、エンジニアスタッフ個々人の実績解除を推奨しています。

    実績を解除してエンジニアスコアを上げろ!はてなのエンジニア実績システムのご紹介 - Hatena Developer Blog
    to_tu
    to_tu 2015/11/04
    “miyagawaさんにブクマされた”
  • 「エンジニア実績システム」を導入した - Kentaro Kuribayashi's blog

    はてなさんの「実績を解除してエンジニアスコアを上げろ!はてなエンジニア実績システムのご紹介 - Hatena Developer Blog」というエントリにある「エンジニア実績システム」がすごくいいなと思ったので、うちの会社でも導入してみました。 「実績」について 上記のエントリに紹介されている項目を取捨選択した上で、以下のようなものを追加したりしました。 プライベートでWebサービスを運営する(Paas or Shared Hosting, VPS, IaaS, 自宅サーバ) プライベートでモバイルアプリを公式ストアへリリースする(ダウンロード数) GitHubの年間アクティビティ数(100, 500, 1,000, 3,000) 勉強会の開催 修士号取得 博士号取得 論文誌への論文掲載 また、後述する「意義」に沿うよう、追加すべき「実績」を募集し、内容を更新しています。 ソーシャル要

    「エンジニア実績システム」を導入した - Kentaro Kuribayashi's blog
    to_tu
    to_tu 2015/11/04
    かっこいい
  • nginx + rapid-ssl導入 – わかりやすいよ - Qiita

    nginx + rapid-sslの導入方法を書きます。SSLって何かとめんどくさいイメージありますが、ファイルがどれがどれかわからなくなるから問題なのです。仕組みがわかっていてもファイルがどれがどれかわからなくなります。この時点でめんどくさいですね。でも簡単になるように説明します。 1.Rapid-SSLで暗号鍵を作成 http://www.rapid-ssl.jp/ でSSLを取得します。年間で2,600円ですね。 ダイレクトアクセスできない場合は トップページ> 新規お申し込み > お申込みフォーム > CSR作成ツールより で2048ビットの秘密鍵の作成を行います。このツールを使ったほうが楽で確実です。 https://www.rapid-ssl.jp/tools/makePkeyCsr2048.php (ダイレクトアクセスできませんでした。ごめんなさい。) - 秘密鍵のパスワード

    nginx + rapid-ssl導入 – わかりやすいよ - Qiita
    to_tu
    to_tu 2015/11/04
  • S3の料金体系が分かりにくいと聞かれたので纏めた - Qiita

    課金ポイントは3つ そんなに難しいことはないと思いますが 課金ポイントは3つ あります。 ストレージ容量 単純に保存容量に対して課金されます。 低冗長化ストレージを指定すると2割くらい安くできます。 ログだとか家族写真の保存だとかメインだとデータ転送よりここにお金がかかってきます。(容量でかいけど古いやつは殆どアクセスしないようなのはライフサイクル設定でGlacierに移動する手もあります) データ転送 課金されるのは(S3からの)送信だけです。受信(S3へのアップロード)は無料です。 また、インターネットへの送信と別のAWSリージョンまたはCloudFrontへの送信で別料金が設定されてますが、小~中規模のシステムならサーバ群は1リージョンに纏まってることが多いでしょうから、CroudFront利用時くらいにしかその料金は発生しないと思います。しかもCroudFront利用時は殆どのトラ

    S3の料金体系が分かりにくいと聞かれたので纏めた - Qiita
    to_tu
    to_tu 2015/11/04
  • AWS費用試算例 · さよならインターネット

    November 7, 2013 実在するかどうかはわかりませんがこのような構成があった場合に どのような費用が発生するのか試算してみました。 AWSは費用の算出が難しいので、参考になれば幸いです。 また、計算方法の誤りや、情報の過不足等あれば gistにコメントか、Twitterなどで教えて頂ければ有難いです。 Simple Monthly Calculatorを利用して算出しています。 {% gist 7349351 %}

    to_tu
    to_tu 2015/11/04
  • AWSの費用見積でおさえておくべきポイント | DevelopersIO

    はじめに AWSの費用見積をする際におさえておいたほうがよいポイントについて説明します。 従量課金制である AWSのほとんどのリソースは1時間毎、もしくは利用量毎の課金です。 従量課金制の一番よいところは、ずっと使い続けなくてよいというところです(あたりまえですが)。 急なイベントの時にだけリソース増強 (弊社のこの事例はまさにそれです) 検証環境は必要な時に番環境から作成 という使い方をすることで費用削減が可能です。 実際の必要リソースがわからない部分については、リソース大目の環境を作って検証して、結果的に不必要であればその時点でインスタンスを小さく/大きくする等で対応できます。 最初の見積がずれていても、ずっとそのコストを払わなくてもよい点、頭の片隅のおいておいてください。 また、AWSならではの従量課金の項目もあります。 EBS(ネットワークストレージ)のI/O ネットワークの通信

    AWSの費用見積でおさえておくべきポイント | DevelopersIO
    to_tu
    to_tu 2015/11/04
    “AWSの費用見積でおさえておくべきポイント”