AWS Summit 2016 Tokyoの感想 - プログラマでありたい
3日間のお祭りが終わったので、感想を残しておきます。私の立場としては、出展者やAWS本の著者、ベンダー、JAWSUG参加者など色々あります。まぁその辺りを無視して、ただの感想です。 出展者として AWS Summitのブースに立ったのは久しぶりでした。ブースに訪れてくれるユーザのAWSの関心の高さ・具体性が段違いに高いというのが印象的でした。たしか前にたったのは３年程前で、その時は情報収集段階という人が多かったです。今年は、もう既に導入している／導入検討している上で、具体的な悩みなどを色々聞くことができました。後のフォロー次第ですが、出展者側としては、AWS Summitはやはり重要な機会ですね。 AWS本の著者としてて ブースに『Amazon Web Services パターン別構築・運用ガイド』と『Amazon Web Services クラウドネイティブ・アプリケーション開発技法』を
エンジニアよ、越境しよう！！クラウド時代のエンジニア像 - プログラマでありたい
Amazon Web Services クラウドネイティブ・アプリケーション開発技法のAppendixとして、「クラウドとエンジニア」をテーマに、クラウド時代のエンジニアのあり方について少し書きました。その趣旨としては、次のようなものです。 従来は、アプリケーション・エンジニアとインフラ・エンジニアという役割で分業することが多かったです。しかし、API GatewayやLambdaのような新しいサービスが出てくる現状で、果たしてそれを扱うのは誰なのだという問題がでてきます。 図示化すると、次のような感じですね。 アーキテクチャが変われば、エンジニアの役割も変わる 今、Webの世界で一般的に見られるアーキテクチャはIntel LinuxサーバやWindowsサーバが普及してからのものです。せいぜい20年位の歴史だと思います。その前は、ホストを中心としたC/Sシステムなどが中心だったのでしょう
クローラー／スクレイピング本がざくざく - プログラマでありたい
2015年8月末に、クローラー／スクレイピング本が2冊同時に発売です。Python版メインのものとJavaScript版メインのものです。なかなか市場のニーズ突いてきていますね。 実践 Webスクレイピング&クローリング-オープンデータ時代の収集・整形テクニック 作者: nezuq,東京スクラッパー(協力)出版社/メーカー: マイナビ発売日: 2015/08/28メディア: 単行本（ソフトカバー）この商品を含むブログを見るJS+Node.jsによるWebクローラー/ネットエージェント開発テクニック 作者: クジラ飛行机出版社/メーカー: ソシム発売日: 2015/08/31メディア: 単行本この商品を含むブログを見る 実践 Webスクレイピング&クローリング-オープンデータ時代の収集・整形テクニック 実践 Webスクレイピング&クローリング-オープンデータ時代の収集・整形テクニックは、Py
WEB+DB PRESS vol.86を読んだ。Atomの衝撃的な事実 - プログラマでありたい
技評さんにWEB+DBの最新号頂いたので、さっそく読みました。何か最近いろいろ貰いすぎて申し訳ない感じです。 特集記事 この号の特集は、次の3つです。4月ということで、全般的に新入社員を意識しているようですね。 チーム開発 6つの心得 実践Atom Docker実践投入 個人的な感想として、一番驚いたのがAtomの特集で、理解が深まったのがDockerの特集。そして、タイムリーだったのが伊藤さんの連載のReactです。 Atomの衝撃 この特集の構成としては、Atomとは何ぞやという所から始まって、実際の使い方であるインストールや設定、各言語ごとでの使い方や開発環境としてのAtomと、WEB+DBの読者層の利用想定と一致した内容となっています。 この中で驚いたのが、何気にAtomとはなんぞやの部分です。今まで知らなかったのですが、Atomはブラウザのエンジンの上で動いていて、HTMLやJa
上級者向けの技術書が少ない理由 - プログラマでありたい
AWS本やクローラー本を出していると、「上級者向けの本は出さないのですか」とよく聞かれるます。残念ながら日本のIT業界向けの出版事情を考えると、なかなか難しいというのが正直なところです。 IT業界向け出版物の市場規模 難しい理由として、市場規模があります。IT業界で働く人の数は定義次第なので幅がありますが、100万人程度と仮定します。市場の規模は、この母数に対して1人あたり何冊買うかが上限となります。この段階で、コミックや一般書に較べて、著しく小さいことが解ると思います。 さらに初級・中級・上級とカテゴライズすると、この母数に対して更にフィルタリングすることになります。コミックだと対象年齢はある程度はあるものの、レベルによってフィルタリングすることはないですね。市場規模は下の概念図のとおり、上級者の市場は必ず初級・中級者の市場より小さくなります。 細分化されたカテゴリ この段階で上級者向け
「Amazon Web Services パターン別構築・運用ガイド」の執筆環境 - プログラマでありたい
Amazon Web Services パターン別構築・運用ガイド 作者: NRIネットコム株式会社,佐々木拓郎,林晋一郎,小西秀和,佐藤瞬出版社/メーカー: SBクリエイティブ発売日: 2015/03/25メディア: 大型本この商品を含むブログ (2件) を見る 今回の「Amazon Web Services パターン別構築・運用ガイド」は、会社の同僚たち4人で書き上げました。会社の同僚といっても、東京と大阪に別れていたり、日中に打ち合わせをする時間もないので、ほぼリモートのやり取りだけで完結させました。かなりスムーズにいったのですが、幾つか課題もあるので、忘れないうちにメモです。 執筆を支えるシステムの全体像 リモートでやり取りをする為に、幾つかのツールを組み合わせて簡単な環境を作りました。方針としては、執筆に集中するために出来るだけSaaSを利用し、余計な時間を取られないようにしまし
私とAWSの9年間 - プログラマでありたい
Amazon Web Services パターン別構築・運用ガイド 改訂第2版 作者:NRIネットコム株式会社,佐々木 拓郎,林 晋一郎,小西 秀和,佐藤 瞬SBクリエイティブAmazon 新幹線の中で、もうすぐ発売される「Amazon Web Services パターン別構築・運用ガイド」の前書きを考えています。ふと、AWSとの出会いはどうだったのかなと思い、過去の記録と記憶をサルベージしてみました。 AWSとの出会い AWSとの出会いは、2006年のAmazon S3です。当時はアメリカのシリコンバレーで働いていて、レンタルサーバのようなものを探していました。幾つか探している時に、ちょうどAmazonがWebサービスを出すというニュースが飛び込んできました。ストレージのWebサービスとは何か、さっぱり見当つかなかったものの、とりあえず惹かれるものを感じ使いだしたのが最初です。実はそれ以
AWSパターン別本の狙い。例えばAutoScalingを使えるように。「Amazon Web Services パターン別構築・運用ガイド」の裏話 - プログラマでありたい
Amazon Web Services パターン別構築・運用ガイド 作者: NRIネットコム株式会社,佐々木拓郎,林晋一郎,小西秀和,佐藤瞬出版社/メーカー: SBクリエイティブ発売日: 2015/03/25メディア: 大型本この商品を含むブログ (1件) を見る 先日、『Amazon Web Services パターン別構築・運用ガイド』を書きましたというエントリーで、執筆のご案内をしました。せっかくの機会なので、もう少し踏み込んで目標などを解説していきたいと思います。ちなみにタイトルを「AWSパターン別本」と省略していますが、今勝手に考えました。元のタイトル長すぎで、覚えられません。 本書の目標 今回書いた本の目標として、例えば「読んだ人がAutoScalingくらいを苦もなく使えるようになる」というのがあります。AWSを使いこなしている人にとっては、AutoScalingなんて当たり
Capybara+PhantomJS+Nokogiriを利用してスクレイピング - プログラマでありたい
CapybaraとPhantomJS、Nokogiriを利用してのクローラー・スクレイピングの紹介です。 PhantomJSとは？ PhantomJSは、ヘッドレスブラウザと呼ばれるWebKitのエミュレータです。ヘッドレスブラウザとは、GUIではなくCUIから利用できるブラウザでプログラムから呼ばれます。UIのテストツールとしてSeleniumのようなサービスがあります。Seleniumはブラウザを直接操作するので、環境依存や動作が重いといった幾つかの問題点があります。そこでよく利用されるのがPhantomJSです。Seleniumに比べて、軽量というメリットがあります。RubyからPhantomJSを扱うライブラリとして、Poltergeistがあります。 Capybaraとは？ Capybaraは、WebシステムのUI層のテストをサポートするためのライブラリです。主にDSL機能とDr
バッチ処理について再考 - プログラマでありたい
作業途中のメモです。バッチ処理の定義を確認しようとしてWikipediaをはじめとして幾つかのサイトをみてました。その時に目に入ったのが、下記の文章です。 利点 バッチ処理には以下のような利点がある。 ・多くのユーザーがコンピュータのリソースを共有できる。 ・処理をコンピュータのリソースがあまり忙しくない時間帯（多くは夜間、休日）にシフトできる。 ・人間がついていなくてもコンピュータのリソースが暇にならないように最大限有効活用できる。 ・高価なコンピュータをフルに活用することで費用対効果の効率向上に寄与する。バッチ処理 - Wikipedia これだけみると、人件費に対してコンピュータリソースが高い時代の産物なんですよね。今は、クラウドの登場で、有り余るコンピュータリソースをほぼ自由に低コストに使える時代です。そもそもバッチ処理である必要があるか、考える必要がありますね。特に夜間バッチにつ
AWSのアカウント管理の話 - プログラマでありたい
AWS Advent Calendar 2014の7日目です。あと、全部俺Advent Calendarも開催中です。 運用絡みで何か書くと宣言したので、AWSのアカウント運用について書いてみます。テクニックや技術より、考え方の面での整理です。 AWSのアカウントの種類 AWSで利用するアカウントは２種類あります。AWSアカウントとIAMアカウントです。AWSアカウントは、マスターアカウントと呼ぶこともあって大元のアカウントになります。AWSにサインアップ時に作るものが、AWSアカウントで１つだけ存在します。それに対して、IAMアカウントはユーザアカウントです。AWSの管理コンソールから、個々のユーザ向けなどに作成します。 AWSアカウントの取扱について AWSアカウントは、全権限を持っています。強力すぎるアカウントで、日常の運用に利用するには危険すぎます。日常の運用には使わないというのが
『Rubyによるクローラー開発技法』関連書評・イベントまとめ - プログラマでありたい
Rubyによるクローラー開発技法の発売から2ヶ月くらいが経ちました。ニッチすぎるとの予想を覆し、かなり好調な売れ行きです。既に2回目の増刷を迎えております。筆者としては、ありがたい限りです。最近、いろいろな方が書評を書いてくれています。自分用の整理を兼ねて、ピックアップしてみました。是非、ご覧ください。 書評 沢山の書評ブログを頂いています。どれも参考になります。抜けているものも多数あると思うので、指摘して頂ければ幸いです。 書評：Rubyによるクローラー開発技法 巡回・解析機能の実装と21の運用例 - Togetterまとめ @k5okadaさんによるTweetのToggeterまとめ。学ぶべきことの定義がきっちりとされていて、それに沿って行くと効率が良いとのお言葉頂きました。執筆の際に編集者さんに、何に対しての説明なのか常に意識して書けと、繰り返し指摘されていました。この書評を読んで、
今まで読んで良かった本 100冊 - プログラマでありたい
今まで読んできて良かったなぁという本をまとめてみました。せっかくなので100冊をまとめて一挙公開です。趣旨としては名著を紹介する訳ではなく、考え方の上で参考になった本を紹介するという方針です。しかしロクに記録していないし記憶も定かではないので、本当に良いと思ったものでも抜けているものも多数あると思います。また技術書については、専門外の人には意味が無いので省いています。 一般的に本を勧めるうえで、100冊並べるというのは一番効率が悪い方法です。書評ブログとしては、1冊もしくは類似の２〜３冊くらいを紹介するのが一番効率が良いのです。でも、私は意地悪なので、本を１冊紹介してくださいと言われると、10冊紹介するようにしています。暇な時に眺めてください。 歴史関係の本 私がジャンルとして一番好きなのは、歴史関係の本です。時間が許す限り延々と読んでいたいですが、そうも言っていられないのが現実です。面白
AWSのネットワークACLとセキュリティグループの違い - プログラマでありたい
前回、ブラックリスト型ファイヤーウォールとしてネットワークACL（NetworkACL）を紹介しました。セキュリティグループとの役割の違いが解り難いところがあるので、改めて整理してみたいと思います。 ネットワークACL（NetworkACL）とセキュリティグループ（SecurityGroup）の違い まずセキュリティグループとネットワーク ACLの違いは何でしょうか？これは、公式のドキュメントに表形式でまとめられていて非常に解りやすいので、是非一度見て頂ければと思います。表を転載すると以下の通りです。 セキュリティグループ ネットワーク ACL インスタンスレベルで動作します（第 1 保護レイヤー） サブネットレベルで動作します（第 2 保護レイヤー） ルールの許可のみがサポートされます ルールの許可と拒否がサポートされます ステートフル: ルールに関係なく、返されたトラフィックが自動的に
AutoScalingのインスタンスをどう扱うのか（デプロイ編） - プログラマでありたい
AWS Advent Calendar 2013 の 5日目 のエントリーです。ついでに独りでAdvent Calendarに挑戦中です。 みんな大好きAutoScalingの話です。AWSのAutoScalingは負荷に応じてサーバ（EC2）を自動的に縮小・拡張することが出来る夢のようなサービスです。AutoScalingを上手く活用出来れば、急なアクセス増でサーバが耐え切れずSorryページを出すという残念な結果を防げます。実際に使っていて、ピークに合わせて自動的にサーバが増えて徐々にサーバが減っていく様子をグラフで見ると、AWS使ってて良かったなぁとしみじみと実感できます。 しかし、JAWSUGなどでAWSを使い始めた人にAutoScalingを使っていると聞いても、使いたいのだけどまだ導入出来ていないという返事が多いです。何故でしょうか？幾つかパターンがありましたので、整理してみま
家庭内ストレージ／NASのあれこれ。保存方法からバックアップ対象まで - プログラマでありたい
はてブを見てると、NASやクラウドドライブなどストレージ関係のエントリーが幾つかあがっていました。私は、家庭内ストレージには比較的うるさいので一言いわせて頂きます。 家庭内でのストレージの種類 まずは一般的に家庭内のストレージはどういった種類があるのか整理してみましょう。主に下記の5種類くらいに分類出来るのではないでしょうか？ パソコンのローカルストレージ（HDD/SSD） スマフォ／タブレットのデータ領域 NASなどのネットワーク接続型共用ストレージ Dropboxなどローカル同期型のクラウドストレージ Amazon S3やBitcasaなどのローカル非同期型のクラウドストレージ ストレージを考える上でのポイントは、速度・容量・価格の3点です。 まず速度については、パソコンからファイルを読み取るスピードです。小さいサイズのファイルだと余り問題になりませんが、動画系など大きなファイルだとこ
アプリケーション・サーバのセッションの保存先の話 - プログラマでありたい
Webシステムの方式設計をする際に、わりと悩むのがアプリケーション・サーバのセッション（session）の保存先です。アプリケーションサーバとは、TomcatやJBoss,IISやRuby on Railsなどで利用するUnicornやPassengerなどです。そもそもHTTPの基本仕様がステートレスな為、状態を保持する為にはどこかに状態を保持する必要があります。その解決策がセッションになります。そこでセッションの保存戦略を考える必要があるのですが、アプリケーションサーバやサイトの用途や性格、扱うデータの気密性・重要性によっても変わってきます。 それ以前にセッションの保存先のことの呼び方の定番が何かすら解らなかったりします。セッション・ストアとかセッション・ストレージとか、はたまたセッション・マネージャーとか。今回は、セッション・ストアで統一します。 主なセッションストアの種類と保存戦略
サーバ構築・デプロイの自動化の話。或いはChefとCapistranoの素敵な関係 - プログラマでありたい
最近のChefのブレイクで、サーバの構築も自動化でという潮流になっています。そんな中でチラホラ見受けられるのが、アプリのリリースもChefでという考え方です。私は微妙に違うのではないかなぁと思っているので、ちょっと考えを整理してみました。併せてCapistranoの紹介もしてみます。 Chefの役割 まずChefについてです。Chefの役割としては、サーバの状態を管理するものです。ここで言うサーバの状態というのは、各種ミドルウェアのインストール状態＆設定です。いわいるサーバ構成ですね。またChefを使う最大のメリットは、開発環境やステージング環境、本番環境と全ての環境を同じスクリプトで構築するので、手作業によるミス等による微妙な差異が発生しなくなることです。 さてここで問題になるのが、サーバ上のアプリケーションのコードやデータベースのテーブル定義は、サーバの状態に入るのかという点です。入る
JenkinsとSelenium WebDriverでUI層のテストも自動化＆永続化する - プログラマでありたい
思い立ったようにJenkins特集をしておりますが、今回はJenkinsとSelenium WebDriverでUI層のテストの自動化をする話です。Seleniumは面倒臭い画面のテストを自動実行してくれるツールで、出てきてからもう７〜８年がたちます。Web系の開発に携わっている人であれば、一度は試したことがあるのではないでしょうか？そして、必ず挫折したことがあると思います。 その理由としては、せっかく作ったSeleniumのテストケースが腐ってくるからです。一般的にはUI層の変更は、ロジック層に比べて変化が激しいです。だからこそテスト自動化して保証することに意味があるのですが、そのテストケースを維持するのは大変です。そこで、Jenkinsの登場です。Jenkinsでサーバサイドで継続的に実行することにより、Seleniumのテストケースが成功を保てるようにします。また、複数のブラウザ・バ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
