AWSでメールを受信してLambdaで処理する - GeekFactory
AWSでメールを受信してLambdaで処理するには以下の方法があります。 SES→S3, SES→Lambda SES→SNS→Lambda 大きなメールを受信したい場合は1を選びます。1はS3にメールを格納してから読みに行くため、サイズの大きなメールも受信できます。2では160kB以下のメールしか受信できません。 SESとLambdaを異なるリージョンに配置したい場合は2を選びます。SESから直接Lambdaを実行する場合は同じリージョンでなければならない制約がありますが、SNSを経由させると異なるリージョンに配置できます。LambdaをVPCに配置して内部APIを叩きたい場合などに便利です。 なお、大きなメールを受信する要件と異なるリージョンに配置する要件の両方が必要な場合はLambdaからLambdaを呼び出すといった工夫が必要になります。よい方法があったら教えてください！ SES→
Jenkinsfileによるジョブ管理のメリットと実例 - GeekFactory
ジョブの設定をJenkinsfileで管理し始めてから3か月ぐらい経ったので、知見をまとめてみます。 Jenkinsfileを使うメリット Jenkinsの画面でジョブを管理していると以下のような問題が起きることが多いと思います。 誰かが勝手にJenkinsの設定を変更して動かなくなった ジョブ設定を別リポジトリに横展開したいけど、ポチポチ設定するのが面倒 JenkinsfileをGitで管理することで、以下のメリットがあります。 いつ、誰が、なぜジョブ設定を変更したのか後から調べられる Pull Requestでジョブ設定の変更をレビューできる ブランチを使ってジョブ設定を試行錯誤しやすい Jenkinsの運用ポリシー 前項のメリットを実現するには、Jenkinsを以下のポリシーで運用することが望ましいでしょう。 Jenkinsの設定は最小限に抑える なるべく画面からジョブ設定を変更せず
Jenkinsでジョブの結果を集計する - GeekFactory
Jenkinsはジョブを実行するだけでなく、結果を集計する機能にも優れています。Jenkinsには標準でJUnitの結果を集計する機能が付いており、これを応用すると、複数サーバで実行したジョブの結果を分かりやすく表示するといったことが簡単にできます。 複数サーバで同じジョブを実行するには Multi-configuration Project を使います。ジョブの設定で、実行したいサーバにチェックを入れると、同じスクリプトが指定したサーバで実行されます。そして、後処理に「JUnitテスト結果の集計」を追加すれば結果を集計することも可能です。 例として、各サーバの設定ファイルをdiffでチェックするジョブを考えてみましょう*1。 リポジトリからお手本を取得した後、お手本とサーバの設定ファイルを比較するスクリプトを実行します。こんな感じ。 find . -type f | cut -d/ -f
Task Queue用のジョブスケジューラを設計する - GeekFactory
App Engineで日次バッチを動かす場合はCronかTask Queueを選択することになります。重複起動したくない、ジョブ失敗時はリトライしたい*1という要件があるならTask Queueを使います。Cronの場合は WEB-INF/cron.xml を編集するだけですが、Task Queueの場合はジョブスケジューラを自分で書かなければなりません。 追記： Cronの場合はスケジュール指定でsynchronizedキーワードを付けると重複起動が許容されます。@bluerabbit777jpさん、ありがとうございます。 ここでは、App Engineに限らず汎用的に使えるジョブスケジューラを書いてみます。日次ジョブスケジューラのアルゴリズムを考えてみましょう。例えば、午前3時にジョブを実行したい場合、 現在日時をTとする。Tは年月日時分秒ミリ秒から成る。 Tの時、分、秒、ミリ秒を0に
47,000件のbatch putを16秒で処理 - GeekFactory
以前に 大量のエンティティを処理するデザインパターン - GeekFactory を紹介しましたが、シングルスレッドのバッチ処理なのでスループットが頭打ちになる問題がありました。コンカレントに処理する方法を思いついたので実装してみました。 シングルスレッドではこんな流れでした。 S3QueryResultListでn件のエンティティを取得する。 エンティティをバッチ処理する。 t秒以内であれば上記を繰り返す。 次のタスクにカーソルを渡す。 ここで、エンティティを取得するタスク（Splitter）とエンティティをバッチ処理するタスク（Mapper）を分けてみます。 Splitterタスク S3QueryResultListでn件のエンティティを取得する。 エンティティをmemcacheに入れて*1、Mapperタスクに渡す。 t秒以内であれば上記を繰り返す。 Mapperタスク memcac
AppEngineで大量のエンティティを処理するパターン - GeekFactory
App Engine上で大量のエンティティを処理するパターンをまとめてみました。 Concurrent Pattern 対象のエンティティをシャードに分割し、それぞれを並列に処理するパターンです。シャーディングを行うSplitterとエンティティを処理するMapperが並行して動きます。SplitterとMapperは独立したタスクであるため、memcacheを介してエンティティを受け渡します。 このパターンの利点は、エンティティの処理内容に関係なく一定のスループットを確保できることにあります。Mapperでどんなに長い処理を行ってもSplitterは淡々とシャーディングを続けるため、スループットに影響はありません。 Mapperの処理結果をmemcacheに突っ込み、別のタスクで集約することで、MapReduceのような処理も可能かなと思います。 Serialized Pattern 対
直営社員にプログラミング能力が必要なたった一つの理由 - GeekFactory
大きなSIerでは社員はプロジェクト管理だけを行い、実作業の大半を外部に委託するところがほとんどです。直営比率が低いところは管理作業しか行わないため、入社してから設計書もプログラムも書いたことがない人は割といます。感覚的には、直営比率が1/3を超えるプロジェクトは社員が自ら現場で作業することが可能で、若手社員にも実作業を経験する場が与えられる気がします。 大きなSIerの小さなプロジェクトはたいてい同じ構造をしていて、ソフトウェア開発自体を丸ごと外注していることが多いです。一括請負契約ですね。この場合、委託元と委託先の責任境界は明確で、委託業務に社員が深く関わることはあり得ません。それでコストが増えたら喧嘩になります。残念ながら、このような構造では社員がソフトウェア開発の実作業を経験することは不可能です。 私は、直営社員もコーディングやテストを自ら行える能力が必要と考えます。その理由は、現
プロセス改善のインセンティブと値切りの誘惑 - GeekFactory
人月ビジネスの世界では、単金と工数を掛けた値が原価です。売値から原価を引いた値が利益です。発注者は最小の費用で最大の仕事をさせようとし、受注者は最小の仕事で最大の利益を得ようとします。 発注者は費用を下げようとするので、単金もしくは工数を小さくしようとします。工数を小さくするにはプロセスを改善しなければなりません。これは一朝一夕で効果が出るものではなく、あれこれ試行錯誤が必要になります。時間と研究開発費がかかってしまいます。一方で、単金を下げるには品質を下げるか発注先を変更すればよいだけです。すぐに効果が得られます。 単金を下げるとどうなるでしょうか。一般には品質が下がります。そこで、単金と品質が均衡する点に単金が落ち着きます。しかし、ソフトウェア開発は不確定性の固まりです。工場で物を作っている訳ではないので、どうしても対処できない事象が発生します。偶に起こる非常に高度な事象に対処するため
夢見るSIerと虚構 - GeekFactory
たまには実情を書いてみる。愚痴大会なので読み飛ばしてくだしあ。 SIer の経営方針としては、｢どんなカタチにせよ、生産性を高めるのである｣という方向に行くと思います。生産性を高める要因は２つしかなくて、｢開発プロセスの改善｣と｢ソフト生成の自動化｣です。要するにワンタッチでポンでシステムが出来ればすげぇじゃんっていう発想。でも、そもそも要件定義が終わると全部終わるので、どうにかして改善されたプロセスを最大限に働かせるアジャイル的プロセスへの移行は不可避だと思う。 http://d.hatena.ne.jp/gothedistance/20090723/1248331426 「開発プロセスの改善」はどこのSIerでも施策に挙げていると思いますが、成果を上げているところはあるのですかねぇ。要件定義と開発はまったく別の仕事だから、両者で改善方法はまったく異なるはず。まずは後者のウォーターフォー
ソフトウェア工業化と職人化が待ち受ける世界 - GeekFactory
生産性が 30 倍違うのであれば、バカプログラマー 30 人を雇うより、スーパープログラマー 1 人にサポートスタッフ 5 人つけたほうが安くていいものができるだろう。Ruby の開発でいえば、まつもとさんやささだ先生にサポートスタッフ (あるいは秘書とか内弟子とか) をつけて、極力彼らが雑用をせずに Ruby 開発に専念できるような環境を整えるべきではなかったか。 http://d.hatena.ne.jp/kwatch/20090204/1233769288 基本に立ち返って、ソフトウェア工学の目的とはなんだろう。それは「ソフトウェア開発が産業として安定成立する事」だろう。そこでこれを、大目的とする。 では、さらに考えて「産業として安定成立」するにはどうしたらいいだろうか。 大目的を成立させる為の、最低限の条件として考えられるのが、 ・条件１：成果物の品質安定 ・条件２：関連人材の安定
プログラミングを単純労働と捉える3つの理由 - GeekFactory
int128殿の会社では、 >プログラミングは誰でもできる、頭を使わない作業 と思う方が多くいるのかしら？ http://d.hatena.ne.jp/int128/20080414/1208181589 うちに限らず、多くの大企業SIerではプログラミングを単純労働と捉えています。その理由は3つあります。 （1）プログラミングは業務をプログラムに落とし込む単純労働 SIの開発手法（の考え方）は30年前から進化していません。業務をプログラムに落とし込む作業は誰がどうやっても同じようになるという思想に基づいています。現在のように高品質なフレームワークやライブラリが溢れる時代では、いかにそれらを組み合わせて作るかが効率化の鍵になります。組織のトップが進化した設計思想を理解しようとしないのは問題です。 30年前の設計思想であれば、プログラミングは業務をプログラムに落とし込む単純労働です。 （2）
手順どおりにやるだけでソフトウェアを製造できるようになるのか？ - GeekFactory
ユーザー企業がイノベーション・エンジンとして動くようなそんな仕組みが絶対必要になると思う。（中略）僕が考えられるオプションとしては「内製回帰」か｢人材サービス前提からSaaS型の業務アプリ開発への転換｣の2つかな。 http://d.hatena.ne.jp/gothedistance/20080529/1212033139 しばらくid:gothedistanceの記事をチェックしていなかったのですが、私の先日の記事は二番煎じだったようです。素晴らしい考察です。脱帽。 もう少し引用させてもらいます。 個人に依存して良いことは限られています。業務システムには運用があって、いくら開発時に「超生産性高い技術者」が颯爽と現れ短期間でカットオーバーできたとしても、もうその技術者は戻ってこないわけで。それ、誰が面倒見るのよ、と。 http://d.hatena.ne.jp/gothedistance
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
