『Rubyによるクローラー開発技法』を書きました - プログラマでありたい
勉強会やスライドで紹介していましたが、Ruby×クローラーという題材で、『Rubyによるクローラー開発技法』という本を書かせて頂きました。RubyとEmacsの鬼であるるびきちさんとの共著です。 Rubyによるクローラー開発技法 巡回・解析機能の実装と21の運用例 作者: るびきち,佐々木拓郎出版社/メーカー: SBクリエイティブ発売日: 2014/08/25メディア: 大型本この商品を含むブログ (1件) を見る この本を書いた理由 そもそものキッカケは、るびきちさんのエントリーにある通り、SBクリエイティブの編集者さんが、クローラーの作成経験のある人を探していて、私の書いた「オープンソースのRubyのWebクローラー"Anemone"を使ってみる」を読んで打診してくださったというのが始まりです。 私自身も、Webからデータを収集して分析するということは、趣味として長年やってきました。一
金融機関の口座集約アプリの危険性について - プログラマでありたい
先日、銀行口座の口座集約のとあるiOSアプリの記事について、危険だよなぁと何気なく呟いたら中の人からリプを貰いました。Twitterで呟いているのですが、文字だけでは解りにくいのでまとめてみます。ただ、そのアプリ固有の問題ではなく、構造的な問題なのでアプリ名は開示しません。（安全なので安心ですという論調は、どうかと思いますが。。。） 口座集約アプリの構造 口座集約のアプリは、アカウント・アグリゲーション(Account aggregation)サービスと言われています。サービスの実体は、複数の銀行の口座情報とID,Passwordを預かり、代行でログインして結果のhtmlを解析（スクレイピング）して利用明細や残高を集約するものです。口座とID,Password情報、解析エンジンをどこに置くかで、クライアント型とサーバ型に分類されます。 サーバ型アプリケーション まずサーバ型アプリケーション
自分を首に出来るように働く - プログラマでありたい
年末ということで、自分がどのような働き方を目指しているのかを改めて考えてみました。結論的には、自分がいなくても仕事が回るような仕組みやチームを作り、いつでも抜けられる状態にするということです。つまり、いつ首になっても問題が無いポジションに落としこむということです。この働き方は、圧倒的に楽です。自分にしか出来ないことがないので負荷が集中しないし、代わりの人間がいるので心理的にもプレッシャーは少ないです。そもそもルーチンの仕事は、自動化などでシステムが出来るようになります。そうすると、面白い仕事が出てきた時に取り組み易くなります。 反対に自分にしか出来ない仕事を抱え込んでしまうとどうでしょう？自分自身がボトルネックになるので、休めないし心理的なプレッシャーもあります。そして、延々と同じ仕事を続ける必要があります。10数年働いてそれなりの数の人を見てきましたが、自分のポジションを保つために仕事を
技術を伝えても、技術者の価値はなくならないという話 - プログラマでありたい
増田で、この記事が話題になっていました。 正社員に仕事を教えたくない 私は今年で契約が切れるパート。同じ部署に昨年、数歳年下の新入社員が配属された。 彼女は私が少ない仕事から数年かけて学び、また効率的に処理できるように試行錯誤して会得したノウハウを、たくさんの仕事の中でどんどん吸収している。これまで私しか使えなかったソフトも、ほぼ同じくらい使えるようになった。 この記事書いた人の仕事の内容はよく解らないので元ネタに対するコメントは差し控えます。一方で、これを見ていたIT系エンジニアのクラスタっぽい人々が、技術職にとっては技術を伝えると自分の価値が無くなるよなぁ的な発言をしているのを幾つか見たののが興味深かったです。なので、ITエンジニアにとっての技術と、それを伝えるということを考えてみました。前提として、ITエンジニアの技術についてです。製造業の技術流出は別の問題だと思うので、対象にしてい
ちょっと内緒にしたいスポットインスタンスの話 - プログラマでありたい
ちょっと内緒にしたいような気がしますが、知っていたら確実に得をするAWS EC2のチップスがスポットインスタンスの活用です。まずスポットインスタンスとは？AWSのインスタンススポットのページを読むと大体解りますが、簡単に説明するとAmazonで余剰のEC2のインスタンスを入札制で大幅に安い値段でを利用する仕組みです。デメリットとしては、スポットインスタンスのインスタンス価格が入札価格を上回った場合、情け容赦なくインスタンスがストップされることです。ということで、Amazonの推奨としては以下のように、通常のインスタンスを補完するような位置づけとなっています。 オプションのタスク 遅延可能なタスク コンピューティング能力を追加することで高速化できるタスク 他の方法ではアクセスできない大量のコンピューティングインスタンスが必要になるタスク しかし、制約があるものの圧倒的に安いです。オンデマンド
サーバ構築・デプロイの自動化の話。或いはChefとCapistranoの素敵な関係 - プログラマでありたい
最近のChefのブレイクで、サーバの構築も自動化でという潮流になっています。そんな中でチラホラ見受けられるのが、アプリのリリースもChefでという考え方です。私は微妙に違うのではないかなぁと思っているので、ちょっと考えを整理してみました。併せてCapistranoの紹介もしてみます。 Chefの役割 まずChefについてです。Chefの役割としては、サーバの状態を管理するものです。ここで言うサーバの状態というのは、各種ミドルウェアのインストール状態＆設定です。いわいるサーバ構成ですね。またChefを使う最大のメリットは、開発環境やステージング環境、本番環境と全ての環境を同じスクリプトで構築するので、手作業によるミス等による微妙な差異が発生しなくなることです。 さてここで問題になるのが、サーバ上のアプリケーションのコードやデータベースのテーブル定義は、サーバの状態に入るのかという点です。入る
UITextFieldの入力制限を実装する - プログラマでありたい
UITextFieldに入力された文字列チェックをスマートに行う方法がないか探していました。 どうやらロード時にテキストフィールドをデリゲートすれば、shouldChangeCharactersInRangeでイベントを取れるようです。このメソッドは、booleanで返すのでチェックして不可であればFALSEを返せばよいのです。実装の抜粋は、以下のとおりです。この例では、文字列長を5桁以内に制限しています。 - (void)viewDidLoad { [textField setDelegate:self]; [super viewDidLoad]; } - (BOOL)textField:(UITextField *)textField shouldChangeCharactersInRange:(NSRange)range replacementString:(NSString *)s
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
