タグ

ひがやすをに関するtakami_hirokiのブックマーク (10)

  • AppEngine/Jのspin-upを劇的に改善する方法 - ひがやすを技術ブログ

    AppEngineは、アクセスがあったときにアプリケーションを起動し、しばらくアクセスが無ければアプリケーションを終了させ、また次のリクエストで再起動するという仕組みを導入しています。 そのため、アプリケーションを起動(spin-up)する時間がとても重要になってきます。このspin-upの時間はpython(webapp)で60cpu_ms以下。(cpu_msはcpuが使う仮想的な時間ですがmsと同じ感じで捉えてもらってもとりあえずは大丈夫です)JavaのServletだと600cpu_msくらいです。PythonでもDjangoような大きなフレームワークだと1000cpu_msくらい(アプリによる)かかりますが、許容範囲内。JavaだとSlim3で1300cpu_ms、Springだと早くて7000cpu_msという感じで、Slim3がギリギリ許容範囲内でしょうか。ほんとうは、1000

    AppEngine/Jのspin-upを劇的に改善する方法 - ひがやすを技術ブログ
  • AppEngineにどんなアプリが向いているのかを知ろう - ひがやすを技術ブログ

    AppEngineは、万能なプラットフォームではありません。むしろ、かなり使い道は限定されていると言ってもいいでしょう。 向いていないアプリで使うとかなりはまって、アプリが完成しないリスクがあります。 一方、向いているアプリで使うとこれまでよりかなり費用を節約できたりとか、儲けにつなげることができます。 AppEngineにどのようなアプリが向いているかというと、AppEngineがGoogleの既存のインフラをそのまま利用していることをまず知っておく必要があります。 Googleのインフラは、(極端に単純化すると)大量のデータを多くの人に同時に見せるために最適化されています。 AppEngineも同様で、大量のデータに大量にアクセスがあっても大丈夫なように、BigtableというKVSを使っています。また、自動でスケールアウトするWebのFront Endも既存のインフラをそのまま使って

    AppEngineにどんなアプリが向いているのかを知ろう - ひがやすを技術ブログ
  • PHPを叩く人にガツンと申し上げたい - ひがやすを技術ブログ

    よって、PHPを「学ぼう」とするのは、時間の無駄だと弾言する。学ぼうとするから報われない。ただ必要な時、必要な呪文を、必要なだけ唱えればいいのだ。それ以上をPHPに期待するのは間違いだ。「なぜ」を問うてはならない。 PHP叩きって毎年必ず起こるじゃないですか。で、だいたいの結論が、PHPは「動くWebを作るには最適」でそれ以外はだめなんだということになってる。 俺からみると、PHPでさくっとできることは、たいていのLLで、同じようにさくっとできる気がする。デフォルトで用意されている呪文を一発唱えればいいという話も、そんな呪文を移植すればいいだけの話。移植もそんなに難しくはないでしょう。 デプロイや環境を用意するのが簡単だというのは、簡単にまねできない気もするけど。 だから、不思議なんですよ。PHPが「動くWebを作るには最適」いうなら、同じようなことは他の言語でもできるだろうと。 PHP

    PHPを叩く人にガツンと申し上げたい - ひがやすを技術ブログ
  • Strutsをなめんな - ひがやすを技術ブログ

    Strutsがいかにだめなフレームワークかという話。 ではなくて、Strutsに文句を言う前に、Webフレームワークを理解してから、批判しろという話。 Webフレームワークのやってることを超簡単に説明すると次のようになります。 リクエストが飛んできたときに、URLに関連付けられているコントローラオブジェクトを見つける。 リクエストのパラメータを何らかのオブジェクトにつめる。 入力値のバリデーションを行なう。 NGなら特定のURLに遷移する。 コントローラオブジェクトにリクエストのパラメータをつめたオブジェクトを設定する。 コントローラの特定のメソッドを呼び出す。 特定のURLに遷移する。 フレームワークがやってくれることを自前でやってもいいでしょう。自前でやってもやることは同じです。 Strutsは、上記のことを淡々とやってくれる薄いフレームワークなのです。Strutsのだめなところは、上

    Strutsをなめんな - ひがやすを技術ブログ
  • 社内評価に不満の技術者こそ、外へ――Seasar開発者がメッセージ - @IT

    2007/10/30 「偉くなりたい、金がほしいのではなく、自分のことを認めてほしいのがエンジニア。そのためには社外に出て行くしかないと思った」。オープンソースのJava軽量コンテナ「Seasar」の開発者で、電通国際情報サービスに勤める比嘉康雄氏は10月30日、「IPAフォーラム2007」で講演し、自身の経験から「エンジニアは社外に出て行くことで認められる」と訴えた。 社外に出て行かないとエンジニアは評価されない――比嘉氏がそう感じるのは自身の社内での仕事が正しく評価されていないと感じていたからだ。自身の仕事を社内にアピールできなかったことや、アピールしても仕事上司が正しく評価してくれなかった過去のケースを挙げて、「技術者は社内で認めてもらうのが非常に難しいと思った」という。 技術者の仕事を評価するのは一般的にはその上司。しかし、管理が仕事上司は最新の技術動向に詳しくなく、技術者が最

    takami_hiroki
    takami_hiroki 2008/05/03
    偉くなりたい、金がほしいのではなく、自分のことを認めてほしいのがエンジニア。そのためには社外に出て行くしかない
  • プログラミングファースト開発 - ひがやすを技術ブログ

    プログラミングファースト開発とは、ドキュメントを書いてからソースコードを書くのではなく、動くソースコードを書いてユーザに実際に触ってもらうということを何度も繰り返して、仕様を固める開発手法です。ドキュメントは仕様が固まった後に書きます。 テストサミットでは、極力ユニットテストを書かずに品質を確保する方法ということで、テストに重点を置いて話をしたのですが、今回のクロスコミュニティカンファレンスでは、「プログラミングファースト開発」そのものについて、会場の方々と一緒にディスカッションしました。 熱い(暑い?)ディスカッションになったので、思わず途中で泡のあるスポーツドリンクを飲まないといけなくなったほどです(笑)。 プログラミングファースト開発の開発手順は次のようになります。 実装してユーザに使ってもらうということを仕様が固まるまで繰り返す レビューの結果はその場で反映させる 仕様を決めながら

    プログラミングファースト開発 - ひがやすを技術ブログ
  • 極力ユニットテストを書かずに品質を確保する方法 - ひがやすを技術ブログ

    今日のテストサミットで、できるだけユニットテストを書かずに品質を確保する方法について、ディスカッションします。 やり方を簡単に紹介すると、最初は、Programming First Developmentで、機能を実装して、ユーザに動かしてもらうってことをユーザの要件が固まるまで繰り返します。このときは、基的にユニットテストは書きません。動かすことに集中します。 ユーザの要件が固まった(実装がほとんど終わった)ら、保守のためのドキュメントの一つとして、テストシナリオ(ユースケーステスト)を作って、テストを行います。そのテスト中に、バグが発見されたらその周辺のユニットテストを書いていきます。 これは、「バグは偏在(偏って存在)する」という特徴を利用して、一通り動かした後に見つかったバグの近くをテストしておけば、主なバグはつぶれるだろうという考えです。 これまでは、「ユニットテストは、できる

    極力ユニットテストを書かずに品質を確保する方法 - ひがやすを技術ブログ
    takami_hiroki
    takami_hiroki 2008/05/01
    Programming First Developmentで、機能を実装して、ユーザに動かしてもらうってことをユーザの要件が固まるまで繰り返します。このときは、基本的にユニットテストは書きません。動かすことに集中します。
  • ゾウはイノベーションの夢を見るか - ひがやすを技術ブログ

    スターロジックから新しいサービス「ギョイゾー!」が発表されました。 私たちは長年にわたり、多くの会社さんにて業務のIT化を実現してきました。それらのノウハウを集約して生まれたのがギョイゾー!です。ギョイゾー!をITの専門家向けに一言であらわすと「ワークフローとデータベースの合体したもの」となります。ギョイゾー!には次のような特徴があります。 あくまでもオーダーメイドですから、自社の業務にぴったり合ったシステムを実現します 余分な機能は一切ついていませんので、使いこなせないということがありません 導入にかかる期間も費用も非常にコンパクトなので、すぐに導入効果を感じていただけます 詳しくははぶさんのこころをみてください。 今回は、イノベーションの観点から「ギョイゾー!」を分析してみたいと思います。イノベーションといえば、クレイントン・クリステンセンのイノベーションのジレンマ、イノベーションへの

    ゾウはイノベーションの夢を見るか - ひがやすを技術ブログ
  • メンテナブルなコードよりもテストが重要っておかしくない? - ひがやすを技術ブログ

    その意味で、実はコーディング規約より、メンテナブルなコードよりも役に立つのが、テスト。要はテストをパスしてしまえばどうコードしても構わない、というのがTDD = Test Driven Development =テスト駆動開発の考え方のベースとなっています。 テストは、どう考えても、「目的」ではなくて「手段」ですよ。 メンテ不能なスパゲティコードだけど、テストは完璧ってソースに修正を入れられますか。 「テストをパスしてしまえばどうコードしても構わない、というのがTDD」というのは、TDDをかなり狭く捉えているっていうか、誤解している。 TDDの元になっている(と思う)XPは、メンテナブルなコードを書くことを目指している(と思う)。じゃどうやってメンテナブルなコードを書くかという「設計手法」がTDDなわけです。 TDDはテスト手法じゃない。設計手法です。テストって単語が入っていると、テストの

    メンテナブルなコードよりもテストが重要っておかしくない? - ひがやすを技術ブログ
  • Strutsをなめんな - ひがやすを blog

    リリースノートはこちら Bug [SASTRUTS-18] - ArrayWrapperでListを実装するようにしました [SASTRUTS-20] - ActionからActionへ遷移できない問題を修正しました Improvement [SASTRUTS-19] - ActionのプロパティがMapの場合も扱えるようにしました ダウンロードはこちら http://sastruts.seasar.org/download.html このバージョンから、チュートリアルに、ResourceSynchronizerプラグインを使ったリッチなエラーページをつけました。ResourceSynchronizerを超ざっくり説明すると、ブラウザからEclipseを操作するプラグインです。 チュートリアルのリッチなエラーページをクリックすると、Ext.jsで作ったリッチなエラーページが表示されます。ス

    Strutsをなめんな - ひがやすを blog
  • 1