Webフレームワークのパフォーマンス比較Spring BootによるAPIバックエンド構築実践ガイド 第2版 何千人もの開発者が、InfoQのミニブック「Practical Guide to Building an API Back End with Spring Boot」から、Spring Bootを使ったREST API構築の基礎を学んだ。この本では、出版時に新しくリリースされたバージョンである Spring Boot 2 を使用している。しかし、Spring Boot3が最近リリースされ、重要な変...
初めての Java EE 開発から学んだこと JJUG CCC 2014 Spring
2014年5月18日、ベルサール西新宿にて行われたJJUG CCC 2014 Springにて発表させて頂いたプレゼンの資料です。
5分でよく分かるロジカル・コミニュケーションのポイント - GoTheDistance
ロジカル・コミニュケーションを考えるのにとてもぴったりのエントリが２つ並んでいたので、便乗させて頂きます。 「AともいえるがBともいえる」とか言う人の役立たなさ - Chikirinの日記 「Aしかない」とか極論を言う人の役立たなさ - プロマネブログ このように全く反対のことを２つ並べて考えるのが、最も思考訓練になると思います。「Aは最高や！」と「Aはマジクソ」の本が２つ並んでいる書店って気が効くなぁと思う。 何かを主張するのなら断定的であるべき 特にインターネットで顕著なんですが、何かを意見表明して主張をしたいなら言い切るのがベストです。ネットの文章はタイトルが全てとはよく言われますが、言いたいことが簡潔でないと伝わりにくくなりますし、読まれるかどうかも怪しくなります。読まれないと始まらないという、鶏卵問題がありまして。 実は「AともいえるがBともいえる」言説は、読者のためにならないこ
PlayFramework2が驚くほど早い！
こんにちは。 R&D部のtakayamaです。 「takayamaさんはブログ書かないんですか？」と聞かれて早2年弱。 象より重い腰がようやく上がりました。 今回は新製品を開発するに当たり採用するWebフレームワークを選定するために Scala + PlayFramework2 node.js + express perl + Mojolicious の3つのフレームワークのベンチマークを測ってみました。 （R&D部ではScala+Play2を推進しています。僕はperlとnode.jsが好きです。） ベンチマークを行ったそれぞれの構成は以下のようになっています。 OS CPU メモリ kernel version
MOVEは望まれなかった子 - the sea of fertility
なにやらMOVEが話題です。 MVC is dead, it’s time to MOVE on. http://cirw.in/blog/time-to-move-on [翻訳]MVCは死んだ。MOVEするときがきた きしだのはてな http://d.hatena.ne.jp/nowokay/20120704 Twitterで「”MOVEは生まれた瞬間死んだ” って記事まだー？」って騒いでたら「お前が書けよ」の流れだったので息抜きに書きます。息抜きなので図が無いのは勘弁してください。 MOVEが生まれていない理由 この文中ではMOVEが生まれた理由はMVCの問題点に関わるとされており、そのMVCの問題点としてされているのは次の２点です。 MVCではControllerが肥大化する MVCは10年古い技術で設計されていて、最新のプログラミングパラダイムに対応していない。 しかしこの理由のう
Javaで軽快に使える「軽量フレームワーク」特集 ～本格的なRoRスタイルフレームワーク「Play!」（1）
はじめに 今やWebのフレームワークと言えば、そのほとんどが「RoRタイプ」です。RoR（Ruby on Rails）がWebの開発に与えた影響は非常に大きく、その後生まれたフレームワークの多くがその影響を受けています。 しかし、Javaの世界に関しては、RoRはなぜか素通りしてしまいました。既にStrutsというデファクトスタンダードがあったために新しいMVCフレームワークが割り込む余地があまりなかったのか、あるいはLL（ライトウェイト）言語でないとRoRなスタイルは作りにくかったのか。ともあれ、その後、長い間、Javaでは「いわゆるRoRタイプ」と言えるフレームワークは登場しませんでした。 その流れを変えたのは、Groovyです。Groovyの登場により、JavaでもLL言語のような小回りの聞くコーディングが可能となりました。そのおかげで、ようやくJavaの世界にも遅まきながら新しい世
出張Java講座: 身体で覚えるSpring Framework — ありえるえりあ
出張Java講座: 身体で覚えるSpring Framework - Spring Framework(以下、Spring)の概要を知る - (可能な限り)身軽に(*)Springプログラミングを試して、身体で感覚を養う - ついでに、5分でWebとServletの動作を知る
Struts1に代わるWebフレームワークの選択 - 達人プログラマーを目指して
先日書いたいつまでStruts1を使い続けるの？ - 達人プログラマーを目指してが想像以上の反響の大きさで驚いています。こんなにたくさんブクマいただいたのはブログ開設以来初めてです。政治的理由でフレームワークが最初から天下り的に与えられてしまい、結果的に要件に合わないフレームワークの使用を強いられて苦労させられた経験のある開発者の方も多いと思います。また、逆にフレームワークを提供したり選択したりする側の立場で、時代遅れのフレームワークを今後どうにかしなくてはならないという問題意識を持たれている方も多いのではないかと思います。（これは、ちょうど多くの会社のパソコンでWindows XPやIE6ではさすがに時代遅れだと認識はしていても、コストなどからなかなか思うようにバージョンアップが進まないというのと似たところもあると思います。*1）Struts1が既に時代遅れなのは知っているけれど、抱えて
Struts化するRailsって本当か - ひがやすを技術ブログ
良い悪いは置いておくとしてRubyOnRailsはStrutsになるのだなと感じています（エンタープライズ開発でデファクト・スタンダードになって一定のポジションを獲得する） 最近、「RailsはStruts化する」という風に思っている人が多そうなので、私の意見を書いておきます。 そんなことはないでしょう。 エンタープライズ開発をおこなっている多くのSIerは、とても保守的(だと思う)です。Strutsの導入だってとても慎重で、他で結構使われてもう大丈夫と思ったところで導入したというケースが多いのではないでしょうか。 理由は簡単で、規模が大きいと失敗の損失が大きいので、できる限りリスクを避けようとするためです。今特に困ってないなら、冒険する必要はないという判断です。 新たなテクノロジーを導入するのは、リスクがなく生産性が向上すると判断したか、今のテクノロジーではコストがかかり過ぎると判断した
プログラミングと設計は本来切り離せないものなのでは - 達人プログラマーを目指して
最近はアーキテクトという役割で客先に常駐し、フレームワークの選定をしたり、事前に共通部品を設計したりする役割を担う仕事を引き受けることが結構あります。そこで運よくお客様のマネージャーがオブジェクト指向開発の経験が十分にある方だと、IDEなどの開発環境やインターネット接続環境を当然のように用意してくれるので最初から仕事がスムーズにできるのですが、そうでないとMS Officeしか入っていないロースペックのノートPCを渡されて、要件定義フェーズの期間中、フレームワークの設計をお願いしますとか、私としてはちょっと首をかしげてしまうような困ったことを言われてしまう場合があります。開発フェーズが始まる半年後まではコーディングは基本的に不要という考え方です。アプリケーションのアーキテクトという役割では少なくともコーディング規約を考えたり、ツールやフレームワークの選定をしたりする必要がありますし、プロジ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
