レストランにおいて、喫煙者は優遇されている。タバコの持ち込み代かからないことが先ずものすごい既得権益だと思う。
過去にはタバコは成功者であり、金を消費するアイコンとして機能していたんだと思う。その流れで現在でも喫煙者に便宜をはかる店が多いんだと思う。それはいい。
しかし、タバコを吸わない人がもはや主流であることを考えると喫煙しない人の財布から所得移転しているように思えるのがいただけない。
そこで、こんな対応できないだろうか。
タバコを吸える自由のないような国には住みたくないので、法律で禁止するようなことはあって欲しくないが、その自由を維持するためにほかの客や、店側に一方的に責任を添加するのには賛成できない。
見つからないエンジニアを探し出す技術：なぜ，エンジニアの採用は難しいのか？｜gihyo.jp … 技術評論社というWeb連載が私の周囲だけかもしれないが、軽く話題になっている。この連載は「エンジニア出身の採用担当者」ならわかることだけど、そうでない人事部の人にはわからないことを教えてあげる、というスタンスで書かれているように見える。定義とターゲットがはっきりしないのでなんとも言えないけれども。
実のところ、エンジニアがあきらかに採用に関わっている会社でも実際は悩みまくっているのが本当のところ。自分も下手すると週に10回くらいは普通に面接して、最後のジャッジにも関わっているので関心のあること。まだ３回目なのでどのように発展するか楽しみである。
一方で、採用される側として見ると、それはそれで面白いことが書いてある。第3回には、勉強会を開こうにも場所を貸してくれない話が書かれている。「次にどういう行動をとるでしょうか」というのがあるあるネタがありました。また、第２回にはこんなことが書いてあった。
CodeIQのプロデュースを始めて驚いたのは，エンジニアの間では勉強会が盛んなことです。エンジニアはとにかく勉強会やカンファレンスやミーティングやセミナーや，あれこれ理由をつけ，集まり，そして学ぶということを繰り返していることに気がついて，とても感心したものです。
たとえば，営業マンが集まってセールススキルを磨き合うという勉強会はゼロだとは言いませんが，とても少ないと思います。総務の担当者たちが集まってスムーズにレイアウト変更をするためのセミナーを頻繁に開いている，という話も耳にしません。そう考えると，エンジニアの皆さんは，他人と触れ合うことで，自分のスキルを客観視する機会に恵まれている，と言っても良いでしょう。
これらを見て思い出したのは、同僚の松尾さんの寄稿。
非エンジニアCEOのためのエンジニア採用５つの鉄則【AWSアーキテクトが教える採用・マネジメント術】 | Find Job ! Startup
エンジニア採用の５つの鉄則を教えて頂けるのはアマゾンデータサービスジャパンの松尾康博さん。 松尾さんは現在、アマゾンウェブサービス（AWS）のソリューションアーキテクトとしてエンジニア採用に携わっていますがスタートアップの経験もあり、元々マイネットジャパンでCTOを務めていました。スタートアップの採用で悩んでいた松尾さんに、５つの鉄則を教わってきました。
■ 優秀なエンジニアを採用するための５つの鉄則
１．欲しいエンジニア像を明確にしよう ２．エンジニアを理解しよう ３．採用方針を決めよう ４．エンジニアと出会える勉強会に行こう ５．採用後はきちんとマネジメントしよう
この連載が意味ある形で深堀りされていくことを願ってます。
多く人がすでにAWSクラウドデザインパターン(CDP)を活用しています。CDPこそがAWSを使う目的とまでは言わないにしても、パターンとしてまとめられた体系の上であれば安心してシステムを作れると考えている人は多いのではないでしょうか。
それが証拠に、AWSのCDP関連書籍は、Webデザインのカテゴリで１位（平成25年8月6日現在）でした。
CDPがそのwikiで整備され、公開されてから１年半近くがたちました。日進月歩のこのクラウドの世界で、CDPが生き残っていることは、CDPがそれだけ良く練られた、万人受けするものである故であることは先ず間違いないでしょう。
一方で、CDPは多くの前提知識を必要とする形でまとめられています。CDPがAWSを使う目的だとしたら、AWSを使うために勉強せざるを得なかったことは、沢山あるのではないでしょうか。それらをまとめることはCDPほどの意義はないかもしれませんが、利用者の底辺を広げ、より洗練されたCDPを生み出す原動力となると考えました。
そこで必要になるのは、キャッチーなフレーズです。私はあえて、「AWSバッドノウハウ」と呼ぶことにしました。
「バッドノウハウ」という言葉を聞いたことはあるでしょうか。だれが言い始めたかには諸説あるのですが、最初にきちっと言語化されたものは、高林氏の次の定義でしょう。
計算機を使っていると、何でこんなことを覚えないといけないのだ ろうか、とストレスを感じつつも、それを覚えないとソフトウェア を使いこなすことができないためにしぶしぶ覚えなければならない、 といった類いのノウハウは多い。そうした雑多なノウハウのことを、 本来は知りたくもないノウハウという意味で、私はバッドノウハウ と呼んでいる。
http://0xcc.net/misc/bad-knowhow.html
2003-03-30、高林哲
繰り返しになりますが、「AWSを使うために勉強せざるを得なかったこと」がバッドノウハウであるならば、それらをまとめることには価値があるでしょう。CDPとバッドノウハウの関係を絵にするとこんな具合です。
CDPばかりが注目されていますが、CDPはそれだけで成り立つものではありません。その下にはアンチパターンがあり、バッドノウハウがあり、さらに次々とあらわれるAWSのサービスやユーザの要件などの広大な海の上にある、氷山の一角といえるものです。
それらを集める一つの方法として、「AWSバッドノウハウカンファレンス（仮称）」を開催したいと思っています。現時点では思いつきの段階ですが、皆様のご協力をいただけると幸いです。また、オンラインでアイデアを集める方法も模索しようと思っています。
最後に、この記事を書いたきっかけは、JAWSUG東京が大崎のフューチャーアーキテクトさんで開催され、そのLTでした。会全体の概要はしんやさんのレポートをご覧いただくとして、私の発表について説明することにしました。何しろ今回の私の発表は資料を見ただけではさっぱりわからないので。
cdn.debian.netの中身をきちんと説明したことがなかったのでやってみたのだが、５分では短かすぎた。
今日はcdn.debian.netのRuby2.0対応をしていて微妙に時間をつかった。しかも途中。。
クラウドアンチパターン研究家の荒木です。ITアーキテクトになるためのシステム設計・開発・運用 ミス撲滅ガイド (日経BPムック)
136頁から141頁迄の間に、「【第8章】 クラウドアンチパターン」のAmazon Web Servicesの節があった。この頁の出典は2012年11月の日経SYSTEMSのものだった。
S3-backedのEC2の場合にデータが消えることがあるという記事に関しては、EBSから起動するEC2を選ぶ「EBS-backed」のEC2がデフォルトになってから随分経つのに、いったんついたイメージは消えないのだなという感想。記事中ではEBSのことも触れてはあるのだが、EBSから起動できるEC2についてはあえて触れていないように見える。
このように記事が古いだけなのか、「書きやすい」ので意図して残したのかはわからない。率直な私の感想としては、「昔のデフォルトは人々の脳裏からなかなか消えない」ということを改めて感じた。今は「あえてその設定しないかぎり関係ない」と言いたい。
ELBの増強に時間がかかるという記述は中身については私のコメントの通り、ELBの負荷急増が予測されるのであれば、サポートおよびセールスに相談していただきたい。しかしながら、急増するトラフィックのほとんどはCloudFrontやS3へのオフローディングで対応できることを実感している。良い事ずくめなので、構成の見直しを行うのがいいと思う。
本自体はさくさくと読めるものばかりだし、あちこちに散りばめられたそこは違うだろーというところもなくはないのだが、それもふくめて「議論のネタ」となるのは間違いないので、日経システムズを購読していない私のような人は一読の価値があると思う。
まずはCloudFrontのFAQページを見てほしい。ここではそれ以外のことを。
最近立て続けに複数のルートで聞かれたCloudFrontのオリジンフェッチ（オリジンサーバーからエッジロケーションへのデータ転送）の細かな点を折角なので書いておくことにする。
ミスした場合は3回リトライする。詳細は、AWS Developer Forums: Cloudfront timeout pulling contents? ...を読んでほしいが、まとめるとこんな具合。
レイテンシベースで誘導される。CloudFrontには世界で現在40箇所にエッジロケーションが存在する。日本では東京二箇所、大阪一箇所。場合によっては韓国ソウルやUSのエッジロケーションのほうが近いユーザもいるだろう。
キャッシュはエッジロケーション毎に共有される。エッジロケーションが違えばキャッシュは共有されない。厳密なことを言えば、エッジロケーション内で一定時間内にキャッシュが掘り起こせないときはオリジンフェッチを行う。一旦エッジロケーションにキャッシュされればほぼ待たされることなく共有される。
質問は随時。
AWS の月額費用をシミュレーションする AWS Simple Monthly Calculator は初登場が2007年の6月(たしかそのあたり）。かれこれ6年近くになる。
当初はこんな超すっきりページだったらしい。（白状すると、このバージョンは使ったことがない。2008年夏のUpdateは使った記憶がある）
AWSの料金計算API欲しい…。SDKから叩ける奴…。そしてSIMPLE MONTHLY CALCULATORよりも詳細な奴…。 #jawsug
— 都元ダイスケさん (@daisuke_m) 2013年5月10日
ということなので情報提供。EC2およびS3の価格は次のURLから取得可能です。
http://aws.amazon.com/ec2/pricing/pricing-on-demand-instances.json
http://aws.amazon.com/ec2/pricing/pricing-reserved-instances.json
http://aws.amazon.com/s3/pricing/pricing-storage.json