【試してみた】Amazon Route 53にドメインを移動してみた。 | Pocketstudio.jp log3
AWS 上の DNS 環境である Amazon Route 53 に、 DNS を移してみました。これは、その記録。 Amazon Route 53 http://aws.amazon.com/jp/route53/ 一般的に DNS といえば、Linux 系の方であれば BIND や unbound を思い出される方が多いのではないでしょうか。BIND であれば、named.conf にゾーンのエントリを追加したり、セカンダリDNSサーバを登録したりと、ゾーン転送したり。…これが手作業だと、結構面倒だったりしますよね。ウッカリ Serial を更新し忘れて、一日中延々と悩んだり、レコードに「.」をつけ忘れて www.example.jp.example.jp のような情報ががが、とか。 一方、Amazon Route 53 は、ブラウザで画面をポチポチするだけでドメインを管理出来てしまう
The First Cry of Atom
As touched on in this blog several times, I experimentally try to learn multiple languages simultaneously. The first one I started to study was Spanish before the pandemic. I added Chinese to the list last year. Now, I am starting to study Korean this summer. Although I gradually get used... [Read More] These days, I am addicted to the book illustrating the vivid experience of the author who faces
GitHub上のコードを補完候補にするEZ Completionを作った
EZ Completionは、GitHub全体を巨大な知識データベースとして捉え、開発者が作成しているプログラムと類似したプログラムがGitHub上にある場合には、補完候補として提示します。 具体的には、プログラム上に定義された関数を監視し、似たような関数が実装されているソースコードをGitHub上から取ってきます。 要は、巨人の肩の上に立ち、車輪の再発明はやめようというコンセプトです。これにより、開発者全体で類似コードを作成する必要がなくなり、開発者はプロジェクト固有部分の開発に集中することができます。 仕組みはこんな感じ 1. 自分のプロジェクトに関係ありそうな特定のキーワードからGitHubのリポジトリをクローリングし、ローカルにリポジトリをダウンロード 2. ローカルにダウンロードしたファイルに定義されている関数の情報を抽出し、検索用インデックスを作成 3. 自分が作成しているプロ
スペシャルゲストも登場して盛り上がったQiita 2-day Hackathon総まとめ！ - Qiita Blog
2013年2月2日(土)から3日(日)の2日間にわたって開催された、Qiita 2-day Hackathonの総まとめレポートです！ ハッカソンの概要今回のハッカソンは下記の内容で実施しました。会場を提供していただいた株式会社デジタルガレージ様ありがとうございました！ 日時: 2月2日(土)〜2月3日(日)場所: 株式会社デジタルガレージ 9Fテーマ: 「GitHub APIを使った開発」＋ プログラマの問題を解決するサービス賞品: iPad miniなど詳しくはこちら当日の流れハッカソン当日は2日の13時から開発を開始、希望者の方は夜もそのまま開発を継続し、3日の夕方に1チーム3分間のDEMOを行うという流れでした。宿泊設備があるわけではなく普通の会議室の床で寝るという、すごいイベントでした。（※宿泊は任意であり、宿泊設備がないことも事前了承済みでした。念のため。) 受付の様子 開発の
現場志向でELBについて考える | TecTec Cloud
ELBについて深く知りたくなってしまったので、改めて調べたり聞いたりした。 今回そもそも知りたかったポイントは下記の2点 ELBがどういう仕組みで膨大なトラフィックに耐えているのか ELBで稀に障害が発生するみたいなので、その影響をなんとか回避できないか ELBの概要 内部仕様に踏み込む前に、改めて概要と基本機能を確認。 ELBの役割 ELB（ElasticLoadBalancer）は、Webトラフィックを配下のEC2Instanceに適切に分散してバランスを取る仕組み、いわゆるロードバランサー。なぜ分散させる必要があるかというと、1台のサーバで処理可能なトラフィックには限りがあるから。また、AutoScalingや、Zone間分散（Multi-AZ）といった構成をとる為にも必要となる。 ELBの基本機能 ELBの基本機能は、高負荷システムにおいて、肝となる重要なものばかり 負荷分散
Amazonのロードバランサーの使い方 | さぶみっと！JAPAN
はじめに Amazonのロードバランサー、“Elastic Load Balancing”（以下ELB）は他にあまりないクラウドのロードバランサー（以下LB）です。 極シンプルなELB×1+ノード×2で見積もってみると ※AWS東京リージョンのEC2,microインスタンスをノードとする ELB $20.16 ノード $19.44×2 =$59.04 1$80円で計算して4,723円/月 です。 これにトラフィックに応じた料金がかかります。 AWSの料金計算はいろいろな組み合わせがあって複雑ですが、サーバ会社の共用ロードバランサーを使うより、初期費用は格段に安く済みます。 さらにクラウドの恩恵が享受ができます。 しかし いくつか通常のLBと異なる特徴があります。 Amazonは詳細な理由を積極的に発表していないのですが、おそらくクラウドの可用性をとるためにいくつか、制約が必要だったように見
Route53の新機能によって解決したELBの大きな問題 | TecTec Cloud
AmazonRoute53のβがとれ、正式版になったららしいです。これに伴い、AWSエヴァンジェリストである玉川氏のブログでさらっと紹介されている「新しいエイリアス機能、Zone Apex対応」の文章を読みました。 これ、ELBを利用している人にとっては相当衝撃だったのではないでしょうか。 少なくとも、私にとっては衝撃でした。ビビりました。AmazonEC2最大の弱点（だと個人的に思っていた）ELBのある問題を見事に解決しているからです。あまりに衝撃的だったので、さっそく本ブログで検証してみました。 これまで何が問題だったのか。 実は、AmazonEC2でELBを利用している場合、http://ttcloud.netのような、ドメインルートなURLを利用することができませんでした。http://www.ttcloud.netのような、ホスト名指定のURLにする必要があったのです。サイト
Chefを最速で使いこなすためのいくつかのポイント - Masatomo Nakano Blog
前回書いた さようならPuppet、こんにちはChef が、それなりに反響あったので調子に乗ってもうちょっと書いてみる。 前回、ChefはPuppetに比べて簡単！とか書いたが、実際には慣れるまでそれなりに戸惑うところがあった。 ドキュメント を読み、実際に触っただけでは一発で理解できなかった部分を、自分のメモを元に晒しておく。これだけ読んでもいまいちだと思うので、関連するドキュメントへのリンクも張っておくので合わせて読んでみると高速でChefを理解できるかも！ client vs node Chef Client Nodes ドキュメントを読んだりChefを触っていると client と node という二つのワードが出てくる。この二つは似ているけど別物。 client は文字通り Chef server の相手になるもの。 Chef server にアクセスするものはすべて clien
非公開サイト
サイトの構築。作品の販売。ブログの投稿。この他にもさまざまな機能があります。 ログイン サイトをはじめよう 非公開サイト このサイトは現在プライベート設定になっています。
coco
世界をコラージュする地図アプリケーションcocococo 世界をコラージュする地図アプリケーション cocoであなたが撮った写真を観て、誰かが明日そこに行きたいと思ったり、 誰かの道標になったり、もしかしたらそれが誰かの運命の場所になるかもしれません。
非公開サイト
サイトの構築。作品の販売。ブログの投稿。この他にもさまざまな機能があります。 ログイン サイトをはじめよう 非公開サイト このサイトは現在プライベート設定になっています。
Git - Git の属性
1. 使い始める 1.1 バージョン管理に関して 1.2 Git略史 1.3 Gitの基本 1.4 コマンドライン 1.5 Gitのインストール 1.6 最初のGitの構成 1.7 ヘルプを見る 1.8 まとめ 2. Git の基本 2.1 Git リポジトリの取得 2.2 変更内容のリポジトリへの記録 2.3 コミット履歴の閲覧 2.4 作業のやり直し 2.5 リモートでの作業 2.6 タグ 2.7 Git エイリアス 2.8 まとめ 3. Git のブランチ機能 3.1 ブランチとは 3.2 ブランチとマージの基本 3.3 ブランチの管理 3.4 ブランチでの作業の流れ 3.5 リモートブランチ 3.6 リベース 3.7 まとめ 4. Gitサーバー 4.1 プロトコル 4.2 サーバー用の Git の取得 4.3 SSH 公開鍵の作成 4.4 サーバーのセットアップ 4.5 Git
エンジニアも避けては通れない「安全な利用規約」の作り方
1月18日、「エンジニアサポートCROSS 2013」が開催された。その中から、NHN Japanのmala氏による「体系的に学ぶ安全な利用規約の作り方」をレポートする。 1月18日、Web技術について横断的に語り合うイベント「エンジニアサポートCROSS 2013」が開催された。その中からNHN Japanのmala氏による「体系的に学ぶ安全な利用規約の作り方」をレポートする。 mala氏は、サービスを作る側と使う側の両方の立場から、「安全な利用規約の作り方」を語った。昨今、アプリケーションの実行環境の多様化や、ビジネスモデルの複雑化、大規模なログデータや個人情報の利活用など、サービス自体の複雑化が原因となった利用規約に関する炎上が多々見受けられる。このような炎上の原因はどこにあるのか。エンジニアとして何ができ、どのような解決策があるのか。 Webに関わるエンジニアが知っておくべき5つの
RailsエンジニアのためのTwitter Bootstrapカスタマイズ例
Sassを使ったり、人からパクったりして、極力失敗しない方法
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://d.hatena.ne.jp/happy_ryo/20130204