Rubyを使ってAmazon SNSとSQSを操作する：fanoutパターン | DevelopersIO
AWS SDK for Ruby 今年の7月にAWS SDK for Rubyがリリースされました。いつもはフルセットで用意されているJavaを使っているのですが、今回はRubyがどの程度簡単に記述できるのか確認するためにサンプルを作りました。また、サンプル作成にあたって、SNSとSQSの連携を試しました。 Amazon LinuxでAWS SDK for Rubyのセットアップ 早速セットアップしましょう。 $ sudo yum install ruby-devel rubygems gcc make libxml2-devel libxslt-devel aws-sdk Amazon SNSをセットアップする 通知先としてAmazon SNSのトピックを作成します。トピックは、受付窓口として対応します。受け付けられたメッセージはサブスクライバ（購読者）に渡されます。サブスクライバには、
月315円から使えるインフラサービス Gehirn Web Services がステキで恋に落ちるレベル。 - このブログは証明できない。
あと1ヶ月もすればもうクリスマスだ。そしてまた1年と1ヶ月もすれば来年のクリスマスだ。アレも欲しい、コレも欲しい。でも、本当に欲しいモノって何だっけ？欲しいモノを聞かれて、すぐに答えていた子供の頃。歳をとるほどに、自分の欲しいモノがわからなくなる。そしてプレッシャーがかかると、思わず「からあげ」と答えてしまう。僕の欲しいモノは何なんだろう。 そうだ。サーバーだ。サーバーが欲しかったんだ。僕はずっとサーバーを探していた。昔はRailsが動くレンタルサーバーなんてなかった。専有サーバーを借りるお金などなく、ロリポップの525円の共用サーバーは当時としては珍しくRubyのCGIが動いたので、妻名義で申し込んで（ごめんなさい！）、RailsをCGIモードで動かしては画面遷移するたびに10秒くらい動かない画面を見つめたりしていた。最近は、ServersMan@VPSが490円で使えて安いんだけど、や
危なくないgitこと、うちのチームのgit戦略草案(ver. 2)
履歴 恥を忍んで記事を公開させていただいたおかげで、いろいろフィードバックいただきました。フィードバックを取り込んで更新を行なっています。 2012/11/16: cherry-pickしやすいように、というくだりのところは論理通ってないので削除しました。 1 pull req. 1 commitの原則をやめました。言いたいことであった「試行錯誤の過程を入れないで」を丸パクリしました！ > id:kazuho その他表記修正、クリアコードさんの記事に説明丸投げなど。 まえがき gitでトラブった！という話を何度か聞いたことがあります。なんでトラブッてるんだろう…と話を聞いたところ、同一のリモートブランチに対して複数人・複数環境から操作が行われているようです。極端な例を挙げると、masterブランチしか存在しておらず、コミットログをキレイにするためと称してgit pull –rebaseを常
『達人に学ぶDB設計 徹底指南書 初級者で終わりたくないあなたへ』 - 杉風呂2.0 - A Lifelog -
GW中の2日間でいっきに読んだ。よくまとまっている。いろいろ触れていない項目もあるけど、論理設計では業種やプロジェクト運営に依存するし、物理設計では、ターゲットのRDBMSを固定しないと詳細に入れない部分もあるから仕方ない。本書の態度として、論理設計と物理設計を明確に境界を持たせずトレードオフを意識することを挙げていて、それなりのシステムを扱う人にはこれが基本的な態度になるだろうなと思う。読みどころとしては、7章「論理設計のバッドノウハウ」8章「論理設計のグレーノウハウ」で、それなりに経験の積んだエンジニアは該当事例に出会ったことがあるはず。で、その中には自分の現場では上手くいったということさえあると思う。なぜそれで上手くいっていたのか、逆にダメだったのか、どうすればよかったのかということを考えながら読むと面白い（にがい記憶が思い出される？）と思う。他、akipii さんによると、8章「一
CakePHP2アプリケーションをCapistranoでデプロイする
アプリケーションのデプロイを自動化すべきなのは言うまでもないことです。 一応手動でデプロイを行う場合の問題点について整理しておくと以下になります。 プロジェクトの期間中そして運用に入ってからも何度も手でデプロイするということはとてつもなく多くの時間を手作業に費やすことになるデプロイ先の環境の数が多くなればなるほど作業の時間も増える手作業で作業すると間違えやすい。特に手順が複雑だったり環境が多かったりすると確率は飛躍的にあがるもしデプロイしたアプリケーションに問題があってすぐに戻さなければならない場合に多くの時間がかかる。場合によってはビジネス上の機会損失に繋がる本来は価値を生むフィーチャーを実装することに時間をかけたいはずが、こういうことをやっているとどんどん時間がなくなっていきます。また手作業のリスクや消費される時間を恐れてデプロイの回数を減らしてしまうのは、ビジネス側からみると納得いか
仕事で使ってる巨大SVNレポジトリをGithubに移管するためにやったことまとめ · DQNEO日記
動機 Subversionで困ってない ぶっちゃけSubversionで全然困っていませんでした。 コードレビューはちゃんとやっていたし、マージ・ブランチングも自作シェルスクリプトのおかげてスムーズにやれていました。 よく「Gitはマージが賢い、ブランチ作成が一瞬でできる」とかいわれますが、Subversionだってちゃんと使えばコンフリクトなんかめったに起きないし、ブランチ管理・マージだって全然めんどくさくない。 特にver1.7からはサーバもクライアントも大幅に高速化されたし、.svnディレクトリが.gitみたいに１個になったし、rebaseみたいなことだってできる。(sync merge & reintegrate) ただ、世の中が一斉にGitにシフトしている中でいつまでもSubversionを使っててよいのかという不安がありました。 また、月から金までSubversionにどっぷり
Amazon Web Service (AWS) でサービスをデプロイしてみた | feedforce Engineers' blog
3 年ほど前、 「えもにゅ」というサービスを Amazon EC2 でリリースしました。残念ながら「えもにゅ」はサービスを終了しましたが、今回、別プロダクトで再び AWS を使う機会がありました。「えもにゅ」当時と比べて、AWS も大きな進化を遂げました。 「えもにゅ」当時にはなかった東京リージョンがある。 EC2 / S3 以外にも VPC, ELB や RDS といったサービスが展開されている。 久々の FFTT では、 AWS をどのように利用しているかについて、公開できる範囲でご紹介したいと思います。 AWS 選定までの流れ 要求諸元 今回サービスを立ち上げるに当たって、インフラ面では以下の要求がありました。 Rails 3.2 アプリケーションを動作させたい。 IaaS またはデータセンタの場合は、一般的なロードバランサ → Web appサーバ → MySQL という構成にした
RSpecの話を少し | feedforce Engineers' blog
弊社内のRubyを使ったプロジェクトでは、自動テストツールのひとつとしてRSpec(バージョン2と1両方)を使っています。 先日社内勉強会でRSpecのトピックを取り上げたので、いくつか紹介したいと思います。 Tipsなど (以下のコードはバージョン1でも動作します) as_null_object 通常、Mockオブジェクトに対してstub定義していないメソッドを呼ぶとMockExpectationErrorが発生します。ですがテストによっては、ある特定のメソッド呼び出し以外を無視したいケースもあるでしょう。（例えばログ出力内容の検証など） その場合はMockオブジェクトに対してas_null_objectメソッドを呼んでおくことで、特定のメソッド呼び出し以外を無視することができます。 def start(logger) logger.debug('debug message.') # a
GitHubのissueを使いこなす！ | Firegoby
GitHubにはissueっていう、tracでいうticketと同じような懸案リストを登録し管理する機能があります。 今回は、このissueとファイル修正時のコミットを関連付けして、さらにハイレベルなタスク管理として利用しちゃうためのテクニックを紹介します。 issueとコミットをリンクさせる issueには以下のような感じでプロジェクトごとに固有のidが表示されています。 このIDを覚えておいて、gitでコミットする際にコミットメッセージにIDを含めてあげましょう。 $ git commi -m "#3 fixed" #3の部分がissueのIDです。#をわすれないこと。 コミットが完了すると該当するissueに以下のように自動的にコメントが追加されます。 コメントには、修正内容の差分を表示するページへのリンクも自動的に貼ってくれます。 修正内容のページでは差分を色分け表示してくれるので
スマートフォンと画面解像度・ピクセル密度
320 dpi Androidの密度グループ iPhoneを当てはめると、iPhone 3までがmdpi、iPhone 4からはxhdpiに区分けされそうです。日本で流通しているAndroidスマートフォンの多くはhdpiに属するでしょうが、最近のHD解像度の端末はxhdpiに属しそうです。 IS05やXperia ray, INFOBAR A01/C01などはグループ上hdpiに属しています。しかし、画面サイズが小さいことからピクセル密度が300dpi前後と、xhdpiに近くなっています。小型で高解像度な端末が増えると、所属するグループだけでは画面の精細さを判断するのは難しくなるでしょう。 ピクセル密度の違いが見た目に影響する さて、ピクセル密度のばらつきによって、すこし困ったことが起こります。密度の低い環境に合わせて作られたコンテンツの見た目が、密度の高い環境で良く見えない可能性が出て
Apacheがトラフィックを監視して勝手にtweetしてみた（mod_mruby + iij/mruby）
人間とウェブの未来（旧） 「ウェブの歴史は人類の歴史の繰り返し」という観点から色々勉強しています。2014年までの人間とウェブの未来の旧ブログです。 少し前に、IIJさんによってmrubyの拡張ライブラリが公開されました。個人的にも待ちに待った公開だったので、これを使ってmod_mrubyで試しに何かしてみようと思い、エントリ名みたいな事をやってみました。 やったこととしては、 mod_mrubyをiij/mrubyの拡張ライブラリ版に対応 mod_mrubyでトラフィックを監視して閾値を超えたらtweetする機能を実装 です。 mod_mrubyをiij/mrubyの拡張ライブラリ版に対応 以下のように、Githubからmod_mrubyをダウンロードしてmakeすれば、iij/mruby拡張ライブラリ版のmod_mrubyがビルドされます。 make extend インストールは今まで
PHPカンファレンス2012 で Git と Pull Request をつかったチーム開発の話をしてきました #phpcon2012 - 肉とビールとパンケーキ by @sotarok
PHPカンファレンス2012 | 日本最大のPHPの祭典 先日 9/15 に行われた PHP カンファレンスで、Git と Pull Request をつかったチーム開発について、発表をしてきました。 資料と補足 まず、発表資料です。 あらためてメインの主張をすると、「Git に移行する」というのは、「svn のコマンドに対応する git のコマンドを覚えること」や、「GitHub Enterprise を導入したら完了」するものではなく、Git を利用した最も効率的な、開発フローや業務フローを考え、チーム開発・運用に適用すること、です。 9/19 時点で、また Speaker Deck の embed が使えなくなっているのでリンクもおいておきます (そのうち対応してくれ、ということで↑は放置) Presentation Not Found // Speaker Deck あと補足っぽい
『Ruby on RailsとApache Solrで構築するドキュメント全文検索システムの開発』
はじめまして、アプリケーションエンジニアをしています、たかぎわ (@shun_tak) と申します。 2013年度4月入社予定の内定者で、現在はアルバイトとして週に2日間ほど勤務しております。 今回のエントリーでは、私が業務で開発した社内システムについて紹介しようと思います。 社内システム Tech Search を開発・リリースしました。Tech Searchのリリースにより、社内に蓄積された知識資産の活用が大幅に改善されました。 Tech Searchとは、弊社の研究レポート制度を利用して執筆されたテックレポートの全ファイル・全文章を横断的に検索するための社内システムで、Ruby on RailsとApache Solrを利用して実現しました。全文検索だけでなく絞り込み検索も実装し、UIにも手を抜かず、ユーザーに使いやすいシステムを目指して開発しました。 Tech Searchがリリー
GitHub スピードの秘訣
みんな大好き GitHub のスタッフ blog で『Github は如何にして速いままでいられるか』という記事が出ていました。内製のツールなどが screenshot 付きで紹介されています。 How we keep GitHub fast しかしツールの見栄えの良さにちょっとくらくらしますね。Web な startup だとよくありがちな Staff モードの SQL query log や、call graph。Graphite や statsd を使ったグラフを大型モニタに映し出すのがNew York の startup では流行って（いるような気がし）ますが、ここまでビジュアル的によく出来たものは見たことがないです。 Etsy の performance dashboard 結論としてはまとまっていませんが、一言でいえば『メトリックス大事』ということでしょうか。皆さんの会社では、
ぼくが実際に運用していたGitブランチモデルについて
オペレーションとかインフラ系のエンジニアリングからは少々離れそうなので、個人的な備忘録がてら、Gitのブランチモデルについて。淡々と書くよ。 見えないチカラ: A successful Git branching model を翻訳しました 基本的に、このA successful Git branching model（上記は翻訳記事）を参考にしています。ですが、完全ではありません。運用しながら都合よく省略していますし、悪く言えば曲解もしています。あくまで、わたしが都合良く解釈して取り回した結果と考えてください。 さて、このようなドッシリとしたブランチモデルが、あらゆる規模のプロジェクトに対して有効であるかといえば、もちろんそうではありません。コツコツ個人で開発しているライブラリなどは、ブランチを使わなくても良いケースがあるでしょうし、作ってもバージョン番号ブランチぐらいのケースだってザラ
サービス終了のお知らせ - NAVER まとめ
サービス終了のお知らせ NAVERまとめは2020年9月30日をもちましてサービス終了いたしました。 約11年間、NAVERまとめをご利用・ご愛顧いただき誠にありがとうございました。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
IDEA * IDEA
IDEA * IDEA
Developing with Git and Pull Request / Git x Pull Request でチーム開発 // Speaker Deck
Loading...