あらためてRuby製のクローラー、"anemone"を調べてみた - プログラマでありたい
３年ほど前に、Ruby製のクローラー"anemone"を紹介しました。その当時から完成度が高く、Rubyでクローラーを使う場合はanemoneを利用してきました。最近、他に新しくて良いのがないか調べましたが、機能面の網羅性という意味でanemoneを超えるものは見つけられませんでした。そこで改めてanemoneのソースを読んでみたところ、クローラーが必要とする機能を必要最小限で実装され、やはり中々良い出来です。冬休みの宿題ではないですが、勉強の意味を兼ねてソースを追っていくことにします。 Anemoneが利用しているライブラリ一覧 anemoneが利用しているライブラリは、４種類に分類できます。 Ruby標準or一般的なライブラリ データ取得で利用しているライブラリ データ解析で利用しているライブラリ データ保存で利用しているライブラリ この分類別に構造をみるとわかりやすいので、順番に追っ
複数並行可能なRubyのクローラー、「cosmicrawler」を試してみた - プログラマでありたい
最近のRubyのクローラーは、EventMachineを使って並列化するのが流行のようです。EventMachineは、非同期処理をお手軽に実装できるフレームワークです。Rubyのスレッド機能との違いは、Reactorパターンを使いシングルスレッドで実装している点です。こちらのブログが詳しいので参考になります。 「見えないチカラ: 【翻訳】EventMachine入門」 EventMachineを使うと、イベント・ドリブンの処理を簡単に実装出来ます。使い方は簡単ですが、通常の同期処理やスレッドをつかった処理に比べると、どうしてもコードの記述量は多くなります。今回の例である並列化してクローラーを走らせるという用途であれば、短時間で多くのサイトにアクセスするのが目的です。イベント・ドリブンで並列化処理を実装するのが目的ではないはずです。その辺りの面倒くさい処理を実装したライブラリがcosmic
自分を首に出来るように働く - プログラマでありたい
年末ということで、自分がどのような働き方を目指しているのかを改めて考えてみました。結論的には、自分がいなくても仕事が回るような仕組みやチームを作り、いつでも抜けられる状態にするということです。つまり、いつ首になっても問題が無いポジションに落としこむということです。この働き方は、圧倒的に楽です。自分にしか出来ないことがないので負荷が集中しないし、代わりの人間がいるので心理的にもプレッシャーは少ないです。そもそもルーチンの仕事は、自動化などでシステムが出来るようになります。そうすると、面白い仕事が出てきた時に取り組み易くなります。 反対に自分にしか出来ない仕事を抱え込んでしまうとどうでしょう？自分自身がボトルネックになるので、休めないし心理的なプレッシャーもあります。そして、延々と同じ仕事を続ける必要があります。10数年働いてそれなりの数の人を見てきましたが、自分のポジションを保つために仕事を
JavaScriptにも対応出来るruby製のクローラー、Masqueを試してみる - プログラマでありたい
ちょっと前に試そうと思って、そのまま放置していたruby製のクローラー「Masque」を試してみました。ruby製のクローラーは、他にはAnemoneという優秀なものがあります。その上で何故というと、Anemoneにはない特性があるからです。 MasqueはCapybaraのDSLで記述出来るWebクローラーです。つまりCapybaraを動かす為のものなので、JavaScriptも解釈が出来るということです。また場合によっては、レスポンシブルデザインのサイトの確認も出来ます。一方で、Anemoneはあくまで個別個別のHTMLを取得する為のクローラーなので、JavaScriptを多用しているサイトでの情報取得に向きません。どちらが優れているという訳ではないので、用途に応じて使いこなせばよいでしょう。 Masqueのインストール $ gem install masque Fetching: h
AutoScalingやインスタンス障害に強い 〜Stateless Serverパターン〜 - プログラマでありたい
CDP Advent Calendar 2013 の14日目です。主に動的なWeb/アプリケーションサーバの話ですが、AutoScaling時や障害発生時に影響なく処理を継続するにはセッションの保持方法に一工夫必要です。またログなどもローカルに保存すると後々面倒くさいです。その辺りを解決するには、サーバの状態（セッション・ログ・etc）を外出しするのが一番です。名前を付けるとしたら、「Stateless Serverパターン」です。昨今のImmutable Infrastructureの概念にも影響を受けています。 1 解決したい課題 AutoScalingを利用すると、負荷の増減に応じてサーバの増減が出来る。しかし、動的サーバの場合はセッションサーバを個々のサーバに保持していると、サーバが増減して別のサーバに振り分けられた場合セッション維持が出来ずに問題が生じる。また負荷が下がってサーバ
Markdown記法+Git+md2review+ReVIEWで原稿・ドキュメント管理 - プログラマでありたい
来年は、インプットあたりのアウトプットの増加を目指しています。具体的なアウトプットとしては、ブログを書くこともその1つですし、公開・非公開を問わずに効率的にドキュメントを書いていくこともあります。その中で効率的にドキュメントを書くには、バージョン管理を含めドキュメントを管理する仕組みが必須だと思います。以前、原稿を書いていた時は、Git+MS Wordで書いていました。版管理出来るという点では良いのですが、Wordということで執筆出来る端末も限定され、またフォーマット変更もしづらいので改善を考えていました。 そんな中で、IT系の物書きの人たちの間でReVIEW良いよという話を何度も聞いたので試してみようと思いました。一方で、記述のデファクトは今後はMarkDown基本になると思うのでそちらもマスターしたいと考えています。Twitterで何気なく呟いたら、@masawadaさんにmd2rev
Statelessなサーバについて 〜クラウド時代のサーバの在り方 - プログラマでありたい
Immutable Infrastructure関連の記事を読んでいて、ここ最近AWS上でサーバを構築・運用する上でモヤモヤと感じていた事が一気に概念化されました。一番納得したのが、@stanakaさんの2014年のウェブシステムアーキテクチャです。その中のStatelessサーバのくだりです。 状態を持たない Stateless Server は、アプリケーションサーバーやリバースプロキシサーバー、キャッシュサーバー、ロードバランサーなどのことです。これらのサーバーは、本質的には状態を持つ必要がないため、いつ壊れてもよいし、再作成も容易にすることができます。そのため、負荷に応じて必要十分な数だけフレキシブルに増減させることが、もっとも効率的です。サーバーを増やしたり、減らしたり、設定を更新したり、切り戻したりするオペレーションコストをいかに減らすかが勝負どころです。 Statelessな
CAPの定理と分散データベースの話 - プログラマでありたい
前回、セッションストアについて悩んでいますという何も解決しないエントリーを書いたら、はてブやTwitterで非常に沢山のコメントを頂きました。色々な考え方があって、非常に参考になりました。ありがたい限りです。別途、考えを整理してまとめようと思いますが、下記の2つの考え方が多いようです。 共用セッションストアの格納先を分散データベースにすれば良いよ セッション設計をちゃんとすれば、クッキーストアを使ってもセキュリティや容量の問題はないよ 私も、どちらかと言えば上2つの方針で考えています。一方で、分散データベースは一貫性を保証しつつ可用性を高めるのは難しいという基本姿勢と、クッキーストアについては設計ミスや実装ミスが起こりうるという現実の中で、どう安全側に倒していけるかという点を考える必要があると考えています。今回は、分散データベースの一貫性について考えていることをまとめてみます。 CAPの定
アプリケーション・サーバのセッションの保存先の話 - プログラマでありたい
Webシステムの方式設計をする際に、わりと悩むのがアプリケーション・サーバのセッション（session）の保存先です。アプリケーションサーバとは、TomcatやJBoss,IISやRuby on Railsなどで利用するUnicornやPassengerなどです。そもそもHTTPの基本仕様がステートレスな為、状態を保持する為にはどこかに状態を保持する必要があります。その解決策がセッションになります。そこでセッションの保存戦略を考える必要があるのですが、アプリケーションサーバやサイトの用途や性格、扱うデータの気密性・重要性によっても変わってきます。 それ以前にセッションの保存先のことの呼び方の定番が何かすら解らなかったりします。セッション・ストアとかセッション・ストレージとか、はたまたセッション・マネージャーとか。今回は、セッション・ストアで統一します。 主なセッションストアの種類と保存戦略
金融機関の口座集約アプリの危険性について - プログラマでありたい
先日、銀行口座の口座集約のとあるiOSアプリの記事について、危険だよなぁと何気なく呟いたら中の人からリプを貰いました。Twitterで呟いているのですが、文字だけでは解りにくいのでまとめてみます。ただ、そのアプリ固有の問題ではなく、構造的な問題なのでアプリ名は開示しません。（安全なので安心ですという論調は、どうかと思いますが。。。） 口座集約アプリの構造 口座集約のアプリは、アカウント・アグリゲーション(Account aggregation)サービスと言われています。サービスの実体は、複数の銀行の口座情報とID,Passwordを預かり、代行でログインして結果のhtmlを解析（スクレイピング）して利用明細や残高を集約するものです。口座とID,Password情報、解析エンジンをどこに置くかで、クライアント型とサーバ型に分類されます。 サーバ型アプリケーション まずサーバ型アプリケーション
サーバ構築・デプロイの自動化の話。或いはChefとCapistranoの素敵な関係 - プログラマでありたい
最近のChefのブレイクで、サーバの構築も自動化でという潮流になっています。そんな中でチラホラ見受けられるのが、アプリのリリースもChefでという考え方です。私は微妙に違うのではないかなぁと思っているので、ちょっと考えを整理してみました。併せてCapistranoの紹介もしてみます。 Chefの役割 まずChefについてです。Chefの役割としては、サーバの状態を管理するものです。ここで言うサーバの状態というのは、各種ミドルウェアのインストール状態＆設定です。いわいるサーバ構成ですね。またChefを使う最大のメリットは、開発環境やステージング環境、本番環境と全ての環境を同じスクリプトで構築するので、手作業によるミス等による微妙な差異が発生しなくなることです。 さてここで問題になるのが、サーバ上のアプリケーションのコードやデータベースのテーブル定義は、サーバの状態に入るのかという点です。入る
何故、fluentdなのか？ - プログラマでありたい
最近、fluentdという言葉を聞くことが多いと思います。fluentdは、それぞれのサーバからログを収集し集約する為のアプリケーションです。fluentdは「Log everything in JSON」を合言葉に、全てのログをJSON形式で扱います。また一緒に聞くキーワードとしては、大規模とかリアルタイムとかがあると思います。この時点で関係ないやと思って、興味を失った人も多いと思います。しかし、今後のログ管理は、fluentdが主流になるか解りませんが、同様の集約するフレームワークが中心になると思います。 何故、fluentdが必要か？ まずはオンプレミスの世界から見て行きましょう。ログはサーバーにたまり、管理者はサーバにログインしてログを参照します。特に問題はありません。 次にAutoScalingを使わないAWSの世界です。これも同様に、ログはサーバーにたまり、管理者はサーバにログ
GitLabのPublic AMIを公開しました。 - プログラマでありたい
前回、GitLabのインストール手順をまとめました。しかし、手順はかなり複雑で、たぶん殆どの人がハマると思います。そもそもAWSだから誰かがAMIを作って公開したら良いのはと考えて、試しに自分のAMIをPublicで公開することにしてみました。 このAMIをPublic AMIから検索してください。 ami-b5e270b4 初期設定の仕方 AMI選択後に起動してec2-userでログインしてください。ログイン後にrootになってsetup.shを起動してください。gitlabユーザからgitにsshで接続する為の鍵と、gitoliteの設定を行います。 $ sudo su - # ./setup.sh 後は、Webでログインしてください。ID・パスワードはデフォルトの通りです。 login.........admin@local.host password......5iveL!fe お
Gitのフック機能で、リポジトリをAmazon S3にバックアップする - プログラマでありたい
Gitのリポジトリ運用の要となるのが、バックアップ運用です。一般的には、定期的なバックアップを仕込むといった運用をしている所が多いと思います。一方で、定期作業であれば最終バックアップから障害発生時点でのデータ消失という危険性はあります。ということで、プッシュごとにフルバックアップが取れれば理想です。それも利用者が意識しない形でないといけません。 #Gitなので分散リポジトリから復旧という話もありますが。 ということで、Gitのフック機能でAmazon S3にバックアップするパターン例です。やり方は簡単で、リポジトリ毎のhooksの部分に同期スクリプトを呼び出すコマンドを書けば良いだけです。 post-receive,post-update等に記載 #!/usr/bin/env bash /foo/var/sync.sh &ポイントは、&でバックグランドプロセスにした上で同期プログラムを呼び
Amazon Linux AMIにGit + Gitolite + Gitlabをインストールして、プライベートGitHubを構築する - プログラマでありたい
半年くらい下書きフォルダーにあったGitLabのインストール記事をサルベージしました。今回は、Amazon Linux AMIと最新のGitLab 4.1系でインストールしています。が、あまりに長く面倒くさいので、三行でまとめてみました。 GitLabはGitHubのクローンで、セキュリティー・ポリシー的にGitHubがNGな会社に最適 GitLabの中身は、Git + GitoliteをラッパーしたWebインターフェース インストールが死ぬほど面倒くさいので、後でAWSのPublic AMIとして公開するよしたよ →GitLabのPublic AMIを公開しました。 以下、手順です。気が長い人は読んでください。 ライブラリのインストール 素のAmazon Linux AMIを立ち上げたら、まずライブラリをインストールしましょう。一部sudoでやっていくと詰まるところがあったので、素直にr
Amazon S3のルートドメインでのWebホスティング機能を試してみた - プログラマでありたい
2012年の年の瀬に、Amazon S3に待望の機能が追加されました。それは「ルートドメインでWebをホスト出来る機能」です。なんじゃそれはと思われるでしょうが、つまりwww.example.comとかblog.example.comのようにサブドメインがつかずにexample.comだけでS3で静的Webサイトを作る機能です。 それくらい簡単だろうと言われそうですが、実はこれ根の深い問題があって実現出来ていなかったのです。S3 Web Hostingでドメインの設定をする場合は、CNameを利用することにより実現しています。そしてRFC 1034の規定でトップレベルドメイン（ホスト名無しのドメイン）は、Aレコード（IPアドレス指定）である必要があります。というところで、ルートドメインでのS3のWebホストが出来ませんでした。この辺りの事情は、以前調べて書いています。ちなみにELBでも同様
Kindle PaperWhiteの感想。PaperWhiteはこう使え！！ - プログラマでありたい
Amazonで予約しても待てど暮らせど来ないので、ビックカメラで予約してKindle PaperWhiteをゲットしました。数時間触ってみた感想は、これは本を読むことに特化した端末であるということです。そんなの当たり前と言うと思いますが、予想以上に特化しています。本というのは漫画も含むのではなく、活字の本のみです。 Kindle PaperWhiteの売りは、電子ペーパーの画面です。極めて消費電力が低く、数週間充電しなくても平気という代物です。一方で、パソコンやノートPCのディスプレイと全く別物なので、書き換えというのは苦手です。ですので、本の場合は6ページに1回リフレッシュで黒くチラツキます。漫画の場合は、これがページ毎にリフレッシュされます。結構ちらつくので、気になります。暫く使ってみましたが、結論としては漫画を読む場合はiPadのKindle。書籍を読む場合は、Kindle Pape
Git+DropBoxで、プライベートリポジトリ作成。或いはGitをAmazon S3でバックアップ - プログラマでありたい
2年程前に書いたSubversion+DropBoxの焼き直しです。今風にGitで書きなおして見ました。後は、同期だけでは心許無いので、バックアップ戦略について考えてみました。 まず解決したい問題は、下記の３つです。2年前から変わっていませんね。 ソースのバックアップをどこか違うところに持ちたい ネットワークがオフラインの時でも、コミット出来るようにしたい 違う環境から作業しても、最新のソースを取れるようにしたい まず1のソースのバックアップについてです。厳密にはバックアップではなく、同期で実現しています。開発機単体ではなくDropBoxにコピーされるので物理的障害等に対する対策は充分です。一方でDropBoxの特性として、DropBox上に置いているリポジトリを消してしまうと、消された状態で同期されてしまいます。DropBox上のリポジトリと、ローカルのワーキング・リポジトリに分ければ問
UIWebViewでWebサイトとネイティブアプリを連携する方法について - プログラマでありたい
iOSによるiPhone/iPadのネイティブアプリで、サーバサイドのプログラミングと連携するケースは割とあるかと思います。その場合に、iPhone/iPadで表示する一部の機能についてはサーバサイドでサクッと作ってしまって、UIWebViewで呼ぶという方法は有力な手段の一つです。ここで問題となるのが、サーバ側とiOS側の連携だと思います。幾つか方法はあるのですが、簡単に実現出来るものを紹介したいと思います。 連携の方法としては、iPhone/iPadからWebページの制御とWebページからiPhone/iPadの2通りがあると思います。今回は、WebページからiPhone/iPadのケースを紹介します。 大まかな流れとしては、次の3つの順番になります。 UIWebViewのDelegateを使って、画面処理のイベントを取得する UIWebViewのメソッドのstringByEvalua
Macbookの電源アダプタは、60Wが良い - プログラマでありたい
気がついたら自宅にMacbook Pro Retina、Macbook、Macbook Airがあるマック ユーザーになっていました。続けて買い続けているくらいなのでMacには当然満足しているのですが、一点だけ気に入らない点があります。それは、Magsafe 電源アダプタの故障率。 Macbook Pro RetinaのMagsafe2は使い始めたばかりなので未知数ですが、Macbookの60W電源アダプタとMacbook Airの45Wの電源アダプタはそれぞれ2回づつ、計４回故障しています。故障の原因はMacbookの60Wは、断線。古いタイプの電源アダプタで断線しやすいタイプで立て続けに起こりました。形状が変わった最近のMC461J/Aに交換して貰った後は、断線していません。 それより問題なのがMacbook Airの45Wタイプの電源アダプタ。これが内部的な回路の故障で２回壊れていま
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
