Java EEを説明してみる #javaee - 日々常々
これは Java EE Advent Calendar 2014 の2日目です。 Java EE をよくわかっていない私がよくもまぁアドベントカレンダーなんて登録したなーとしみじみ思いながら。 確かアドベントカレンダーに登録したのをきっかけに、なんか調べようと思ってたのですが、 思ったより12月が来るのが速くて無理でした！ そんなこと言っていても仕方ないので、今書けるものを書くとしましょう。そうしましょう。 Java EEってなんぞ Java EEはJavaのEnterpriseEditionのことで、企業向けとかだけど、なんかサーバーとか使うせいか、Webっぽい雰囲気がある物体です。また、Java EEはいくつかのJSRをまとめたJSRのことを指したりもします。 こういうJSRを"アンブレラJSR"と言うとか言わないとか。 JSR(Java Specification Request)は
【Javaの仕様が決まるとき】JSRの歩き方(基本編)
はじめに Javaでのプログラミング、特にJava EEを用いたコーディングとかをしていると、 僕は「あれこれってどういう仕様なんだろう」ってなることが結構あります。 僕「なんか良い本無いですか？」 某氏「JSR読め」 ほほーそっか。仕様そのもの読んじゃえば間違いはないよな、と。 だがしかし、読み方がよく分からない！っていうか仕様ってどうやって決まってるの？ Java公開されてるの？ …とかそういう僕はレベルだったので、これを期に、Javaの仕様である（定義間違ってたら教えて下さい） JSRあるの読み方を調べてまとめてみようかなというお話です。 調べたっていうレベルですので、間違ってたり表現が適切で無い場合は、 どこかでご指摘ください。 基本的な用語 ・JSR Java Specification Request。Java仕様要求。つまりJavaの仕様です。 ・JCP Java標準化機関J
株式会社デーコム
404 NOT FOUND 申し訳ございません。お探しのページが見つかりませんでした。 お探しのページは見つかりませんでした
アーキテクト向けのパターン本 - 達人プログラマーを目指して
ソフトウェアアーキテクチャ―ソフトウェア開発のためのパターン体系 作者: F.ブッシュマン,H.ローネルト,M.スタル,R.ムニエ,P.ゾンメルラード,Frank Buschmann,Hans Rohnert,Michael Stal,Regine Meunier,Peter Sommerlad,金沢典子,桜井麻里,千葉寛之,水野貴之,関富登志出版社/メーカー: 近代科学社発売日: 2000/12メディア: 単行本購入: 15人 クリック: 448回この商品を含むブログ (54件) を見るPattern-Oriented Software Architecture, A System of Patterns (Wiley Software Patterns Series) 作者: Frank Buschmann,Regine Meunier,Hans Rohnert,Peter Somme
EJBコンテナが分散コンポーネントモデルから軽量なDIコンテナに変化してきた歴史を振り返る - 達人プログラマーを目指して
十年一昔といいますが、文字通り一昔前の書籍ではJ2EEのEJBコンポーネントはプロセスが分散化されたリモート呼び出しにより処理を行う分散コンポーネントとして説明されています。そして、残念ながら現状Java EE関連の日本語の書籍はこうした古い時代に書かれたものがほとんどとなっています。それゆえ、 開発効率がきわめて悪い 実行性能が悪い*1 仕様がきわめて複雑で理解が大変 といった悪いイメージが定着してしまっているのではないかと思います。しかしながら、最新バージョンのJava EE6では、Spring、Guice、SeamなどのOSSの軽量コンテナのアイデアを取り込むことにより、以前とは比較にならないくらい開発効率が改善されているという事実があります。 ここでは、Hello WorldのEJBの書き方を以前の古いバージョンから順次振り返りながら比較してみることで、EJBのプログラミングモデル
アーキテクトもプログラミングするべきか？ - 達人プログラマーを目指して
プログラミングと設計は本来切り離せないものなのでは - 達人プログラマーを目指して で以下のようなコメントをいただきました。 アプリケーションのアーキテクトという役割についてちょっと理解が曖昧だったのがこのエントリ読んでだいぶスッキリした。今度の開発系の勉強会のネタにとりあげようかな アーキテクトの働き方の参考に。 そもそもオブジェクト指向を本当に理解していてプログラミングも得意なアーキテクトがどれくらい居るのやら。 全体の設計がちゃんと推敲されていて、きちんと疎結合が達成されているなら、後の修正にも耐えられる。 アーキテクトが何をどこまで責任持つのか、という認識が整合されてないんじゃないの 現代的アーキテクトの仕事 このようなコメントから、「アーキテクト」という仕事の内容については、実はよくわからないと考えている方が多いように感じられます。実は、私自身も「アーキテクトという役割で仕事をす
プログラミングと設計は本来切り離せないものなのでは - 達人プログラマーを目指して
最近はアーキテクトという役割で客先に常駐し、フレームワークの選定をしたり、事前に共通部品を設計したりする役割を担う仕事を引き受けることが結構あります。そこで運よくお客様のマネージャーがオブジェクト指向開発の経験が十分にある方だと、IDEなどの開発環境やインターネット接続環境を当然のように用意してくれるので最初から仕事がスムーズにできるのですが、そうでないとMS Officeしか入っていないロースペックのノートPCを渡されて、要件定義フェーズの期間中、フレームワークの設計をお願いしますとか、私としてはちょっと首をかしげてしまうような困ったことを言われてしまう場合があります。開発フェーズが始まる半年後まではコーディングは基本的に不要という考え方です。アプリケーションのアーキテクトという役割では少なくともコーディング規約を考えたり、ツールやフレームワークの選定をしたりする必要がありますし、プロジ
開発コストや技術リスクを考えない「上流設計」がシステムの複雑化と大規模な障害の原因となっているのでは？ - 達人プログラマーを目指して
皆さん、明けましておめでとうございます。昨年の後半は私自身SI業界からWeb業界へ転職したことなど仕事環境の変化があり、ブログの更新頻度も鈍りがちになってしまっていましたが、本年もどうぞよろしくお願いいたします。 さて、ちょうど、一年前のお正月にはグルーポンのおせち料理事件が話題になっていましたが、私はおせち料理の品質とIT業界における品質の問題を絡めて、以下の記事を書きました。 グルーポンのおせち事件を受けてSI業界が本当に教訓とすべきこと - 達人プログラマーを目指して この記事では、一般にSIerによって開発される日本のシステムはあの事件のおせち料理のように、低い品質に甘んじているが、多くの場合、社内システムなどではそういった品質の問題が公に明らかにされることが少ないのではということを指摘しました。ただ、その時は私の希望も込めて 最近はOSSやクラウドなどの影響で社内システムもどんど
こだわりのある職人プログラマーほど、無駄なコードを少なくしたいものという事実を理解してほしい - 達人プログラマーを目指して
ちょっと興味深いエントリが目に留まりました。「プログラミングへのこだわり」を方向づける: 設計者の発言基本的に、この方自身もプログラマーや開発者をされているようですし、他のエントリを読んでも「プログラマーの地位向上をすべき」ということで、私にとっても非常に共感することをおっしゃっているのです。それでも、ちょっとこのエントリの内容については疑問に思うところがあったので、勝手ながら私の意見を書かせていただきたいと思います。 業務システムの生産性や保守性を高めるための基本は「コードを１行でも減らす」である。なぜなら、コーディングとこれにともなうテスティングこそが、開発作業の中でもっとも人手のかかる作業だからだ。個別案件においては、良いコードだろうが悪いコードだろうが少なければ少ないほどよい。 これは、まさにおっしゃる通りですね。もちろん、可読性ということもあるため、厳密には最少のコードが最良とい
OSS Javaフレームワークはどんどん高度化している - 達人プログラマーを目指して
以前、いつまでStruts1を使い続けるの？という記事を書きました。技術から離れているSEの方は、いまだにJavaのオープンソースフレームワークと聞くとStrutsくらいしか思い浮かばないという人も多いと聞きますが、その記事では、Strutsの問題点をあげて、そろそろ新しいフレームワークを使いましょうという話をしました。 しかし、単にSpring MVCに移行しましょうということではなくて、OSSを利用したエンタープライズJava開発の世界*1では、もっと根本的なレベルで進化が起こっているのではないかということを最近考えます。単純にOSSのJavaフレームワークといっても、時代によって考え方が大きく変わってきているという事実があるのです。この点についてちょっとまとめてみたいと思います。 第1世代（2000年〜2003年） いわゆるStrutsとかHibernateといったフレームワークで、
開発チームにアーキテクトがいないなと感じてしまうような、残念なコードスメルの例 - 達人プログラマーを目指して
まったく個人的なモチベーションの問題から、前回の最終更新から2年以上が経過してしまい、多くの読者のみなさんにはご心配をおかけいたしました。「プログラミングに関して調べたことや日々感じたことをメモとして残していきたいと思います。」というもともとの原点に立ち返って、あまり気負わずに、また今後も時々更新していけたらと思います。今までこのブログの主なテーマとして、JavaEEやSpringといったような、いわゆる業務開発で使われるような技術を中心としてきたわけですが、最近Springを使ったJavaの開発に（アーキテクトではなく）プログラマーとしてちょっと参加する機会があったので、その時気づいたこと、感じたことを書いてみたいと思います。 さて、皆さんはアーキテクチャやアーキテクトという言葉に対してはどのようなものをイメージするでしょうか。システムのセキュリティを確保するための方式であったり、大量の
モジュールの凝集度・結合度・インタフェース
1. インタフェース と モジュールの 凝集度 と 結合度 柳川 一芽 twitter: yangiYA WEB: http://ti.que.jp/p/ 2. インタフェースって重要です • 優れたインタフェース設計なら – 改造は簡単です – 機能追加は簡単です – 公開インタフェースを変更せず、内部実装をリファクタリング することでソースを改善できます。 (インタフェースのリファクタリングは影響範囲が広い) – 使う人が簡単に使い方を理解できます • � 驚き最小の原則 – 使う側が使いたい使い方ができます
ConQATを利用してソースコードの品質をチェックする - 達人プログラマーを目指して
ある程度プログラマーとして経験を積めば、ソースコードを読んだときに、そのソースコードの良し悪しというものは、嗅覚を使って直感的に嗅ぎ分けることができるものです。実際、そのように体の感覚を使ってこのコードは不吉だと感じるところは実際大いにあり、コードの臭い（code smell)として知られています。 コードの臭い - リファクタリングの必要性を示す兆候 これはファウラーの名著 リファクタリング―プログラムの体質改善テクニック (Object Technology Series) 作者: マーチンファウラー,Martin Fowler,児玉公信,平澤章,友野晶夫,梅沢真史出版社/メーカー: ピアソンエデュケーション発売日: 2000/05メディア: 単行本購入: 94人 クリック: 3,091回この商品を含むブログ (312件) を見るでも紹介されており、こういった不吉な部分を適切に嗅ぎ分け
コードの臭い - リファクタリングの必要性を示す兆候
重複したコード (Duplicate Code) 同じようなコードの並びが、複数の場所で見られる。 長すぎるメソッド (Long Method) メソッドが長くて理解しづらい。 巨大なクラス (Large Class) インスタンス変数を持ちすぎている。コード量が多すぎる。 多すぎる引数 (Long Parameter List) 引数が多くて、それらの意味がわかりにくくなっている。 変更の発散 (Divergent Change) 1つのクラスがさまざまな変更要求の影響を被る。 変更の分散 (Shotgun Surgery) 1つの変更がさまざまなクラスの変更を引き起こす。 属性・操作の横恋慕 (Feature Envy) 他のクラスの属性やメソッドを使いすぎる。 (これは他のクラスに強く関連していることを意味します) データの群れ (Data Clumps) いつも一緒に使われるデータ
Deep LearningとNLPの最新論文の情報を集める方法 - あおのたすのブログ
(5/29 追記：Deep Learning のGoogleグループコミュニティを追加) (6/8 追記：松尾研究室の勉強会ページを追加) (6/13 追記：neural language notesを追加) はじめまして。@aonotas（あおのたす）です。 Deep Learningと自然言語処理に興味があります。 好きなフレームワークはChainerです。 さて、Deep Learningが自然言語処理のタスクでも応用されています。 ACLやEMNLPなど国際会議でもタイトルに「Neural」が入ったものが多いですが、arxivにも査読前の論文がよくアップロードされています。 （スピードが早くて追いつくの大変ですよねorz） そこで最新のDeep Learningの論文の集め方を紹介したいと思います。（あくまで私個人の方法です。皆さんどうしてるか教えてもらえると嬉しいです。） 面白い
Javaと偽Javaの話。 - なるようになるかも
qiita.com これの話。ブコメに書こうとしたら4000字は入らなかった。 Microsoft Java VM かつての WIndows には MS 製の Java VM が搭載されていました。 古代の Java は「Write once, run anywhere」を掲げていた通り、クライアントサイドで Java アプレットとして利用されるのが主流でした（サーバーサイドで動くようになって、真価を発揮した感じがあります）。 しかし Java VM の仕様は、パフォーマンスについての記述は曖昧になっており、OS ごとの実装の違いによって、実行速度に顕著な差がありました。 Windows の Sun 純正の Java VM は性能が悪かったため、MS は独自の Java VM を開発し、Internet Explorer にバンドルしました。調子に乗った MS は Windows GUI
計算量とBig-θ記法. - SE Can't Code
アルゴリズムの計算量を簡易的に把握するために、よくBig-Oを用いることがある。たとえば、O(n)やO(log n)といった具合になんとなくlog n < n < n^2というイメージを持っている人は多いと思う。このような記法は漸近的成長と呼ばれている。今回はその中でBig-θについてまとめる。 Big-θ(ビッグ・シータ) とはg(n)と等しい速さで成長するという関数の集合を表している。 たとえば、 のようにある関数f(n)がg(n)と成長率の等しい関数の集合に属する場合、 必要十分条件は , , となり、 において、漸近的に成長して十分大きな極限になると となる。 この不等式が成り立つ場合、 は に属すると言うことができる。 では逆に は成り立つかどうかを確かめる。先ほどの不等式に対して で除算すると以下になる。 (1) また、同様に で除算すると以下になる。 (2) 各 と で除算し
ITアーキテクトって何だろう その１ | TECHSCORE BLOG | TECHSCORE BLOG
こんにちは。三苫です。 この記事はTECHSCORE Advent Calendar 2014、14日目の記事です。 この記事は、私がITアーキテクトって何だろうと学習した記録です。たぶん、全三回程度になると思います。 本記事は書籍「システムアーキテクチャ構築の原理」をもとに書かれています。不明点あれば本書をあたるのが確実です。 ニック・ロザンスキ、イオイン・ウッズ 榊原 彰(監訳) 牧野裕子(訳) (2008)． システムアーキテクチャ構築の原理 翔泳社 要約 あらゆるシステムには静的構造、動的構造、外部から観測できる振る舞い、品質特性が存在する。それらを提示することができるものがアーキテクチャであり、要求を実現するために考えられる複数の候補アーキテクチャから最適なものを決定することがシステムアーキテクトの仕事である。 ITアーキテクトは、設計の根拠を問われたときにそれを説明できなければ
NTTデータとの決闘シリーズ第二幕 - ひがやすを技術ブログ
昨日は、NTTデータとの決闘シリーズ第二幕。戦闘服には、かりゆしウェアを選びました。 今回は、データの顧客であるユーザ企業からも参加していただきました。この人はKさんと呼ぶことにします。Kさんは、現在Seasar2(SAStruts, S2JDBC)を使って、プログラミングファースト開発を実践されている先進的なユーザです。BtoCのサイトを作っていると考えてください。 プログラミングファースト開発の詳細はこちら。 http://d.hatena.ne.jp/higayasuo/20080501/1209636051 http://d.hatena.ne.jp/higayasuo/20080721/1216607451 最初のテーマは「品質」。データとしては、 テストコードのカバレッジやバグ密度などで品質を確保しようとしている。 でも、品質に問題があるプロジェクトも残念ながら存在する。 品質
NTTデータと真昼の対決 - ひがやすを技術ブログ
昨日、NTTデータに「お前は最近、NTTデータに批判的でけしからん」ということで、呼び出されました。もちろん、「批判的でけしからん」というのは冗談ですが、私が、NTTデータを嫌っていると思っているデータ関係者は、実際多いようです。 データの偉い人の発言に対して、それはちょっとおかしいんじゃないのといったことはありますが、データを嫌いといったことはもちろんないはず。 データの社員の中に根強くある(と思う)「プログラミングがあまりできない人でも何とかなるように、ガチガチにルールやツールで縛る。できる人はスキルを発揮できなくなるかもしれないけど、それはしょうがない。」という考えは、個人的には好きじゃないけど。大規模なプロジェクトをまかされるSIerとして、そう思う気持ちは良くわかるんだけどね。 話し合いの中で、私が言ったのは、できる開発者が力を発揮できるように、体力勝負になってしまうような縛りは
SI業界からはさっさと抜けだしたほうがいい - ひがやすを技術ブログ
SI業界（日本）のJavaプログラマーにはオブジェクト指向より忍耐力が求められている？ - 達人プログラマーを目指して http://d.hatena.ne.jp/ryoasai/20110109/1294581985 をうけて自分の考えを書いておきます。 二年前なら、自分もどうしたらSI業界をよく出来るか真剣に考えていたし、NTTデータの人達と実際に話し合いもしています。 NTTデータとの真昼の対決シリーズ http://d.hatena.ne.jp/higayasuo/20080612/1213241779 http://d.hatena.ne.jp/higayasuo/20080828/1219901392 でも、ソーシャル、クラウド、スマフォの時代になって、考えが変わりました。 今は、世の中の動きがかなり速くなっているので、その中で素早くチャンスを捕まえたものだけが生き残ります。受
ソフトウェアアーキテクトが知るべき97のこと
ソフトウェアアーキテクトが知るべき97のこと大人気の書籍『ソフトウェアアーキテクトが知るべき97のこと』のエッセイを無料で公開中！すべてのソフトウェアアーキテクトにおすすめの本がウェブで読めるようになりました。 エッセイ一覧システムの要件よりも履歴書の見栄えを優先させてはならない本質的な複雑さは単純に、 付随的な複雑さは取り除け最大の問題は、たぶん技術的なことではないまずコミュニケーション、そのための明快さとリーダーシップパフォーマンスの決め手はアーキテクチャー要求仕様の本当の意味を探れ立ち上がろう!すべてのものは、かならずエラーを起こすそれは交渉だということに気付け定量化を求めよ500行の仕様書より1行のコードフリーサイズのソリューションを求めるなパフォーマンスの検討に早過ぎるということはないアーキテクチャーとはバランスをとること犯罪的なコミットエンドラン
- 不吉な匂い
不吉な匂いとは、リファクタリングを必要とするコードから感じられる雰囲気を、比喩で表したものです。 ここでは、感じ取った不吉な匂いに対して、どのような解決法を選ぶことができるかを取り上げます。 匂いとして示されているのは、次の２２のケースです。ひとつずつ見ていきましょう。 また、解決法に添えられている数字は、参考書籍「リファクタリング」の何ページに記されているかを示しています。
5分で絶対に分かるITアーキテクト − ＠IT情報マネジメント
0分 － ITアーキテクトとは何者か？ 最近、IT業界で「ITアーキテクト」という単語をよく聞きます。システム基盤分野だけではなく、業務アプリケーション分野でもちらほらと耳にします。「エンタープライズ・アーキテクチャ」「サービス指向アーキテクチャ」というように、関連用語のアーキテクチャという言葉も頻繁に登場します。 ITアーキテクトは、若手IT技術者の間ではプログラマやデータベースエンジニアといった実装担当者よりも上位の、比較的高い報酬の得られる魅力的な職種として認識されているようです。実際、IT戦略立案や個別ITプロジェクトの実務においては、貴重な存在として位置付けられ、活躍の幅がどんどん広がりつつあります。 一方、ITアーキテクトのリアルな人材像はややあいまいです。一般社会はともかく、IT業界内でも明瞭かつ具体的に統一されたイメージはまだ根付いてはいない、とも感じます。 この記事はそん
エンジニアのキャリアパスと役職定義 | GMOメディア エンジニアブログ
技術推進室の宇津井です。 今年はエンジニアのキャリアパスを書いた記事を多く見ましたので、世の中でも整備する動きが広まっているのでしょう。 ここ最近は通常業務の傍らでキャリアパスとか役職定義のようなものを作るのに大きく時間を使っていました。 （これも立派な業務ですし、これが私にとっては通常業務なのかもしれません） 折角なので社内向けの資料を一般公開できるように一部編集しました。良かったらご覧ください。 なんで今キャリアパス？当社はもともと以下のようなキャリアパスを設けて、各々のパスに基づいて役職定義をしていました。 これは様々な歴史を歩んできた結果なんですが、つぎはぎを重ねたので社内でも以下のような疑問があがっていました。 (当社は創業14年です！) なんでWebマスター(WM)が存在しないの？シニアWebマスター(SWM)とシニアシステムアーキテクト(SSA)は同じシニアが付くのに同格じゃ
3ページ目｜第7回 キャリアデザインを行う その1目標設定｜田中ウルヴェ京のキャリアプランニング講座｜日立ソリューションズ
コラム 日立ソリューションズでは、お客様のビジネスにお役立ていただけるよう、さまざまなコンテンツを用意しています。 ぜひご覧ください。
30代前半、これだけは身に付けたいスキル ― ＠IT自分戦略研究所
30代前半、これだけは身に付けたいスキル：30代前半、これだけは身に付けたいスキル（1/3 ページ） 上級ITプロフェッショナルのスキルとキャリア上級ITプロフェッショナルのスキルとキャリア ＠IT自分戦略研究所は2008年9月27日、「＠IT自分戦略研究所カンファレンス ～上級ITプロフェッショナルのスキルとキャリア～」を開催した。 午前の部では「市場価値の高いエンジニアであり続けるための12のポイント」と題してパネルディスカッションが行われた。テクノブレーン 能勢賢太郎氏、ケペル 小林学氏、イーシー・ワン 鈴木智弘氏、3Di 鎌田卓氏、ベリングポイント 平野寛之氏、情報セキュリティ大学院大学 内田勝也氏が登壇し、「市場価値とは何か」「年齢別に求められる能力は何か」などについて話した。午後の部は、パネルディスカッションでの問題提起を受けた形のセッションが6つ行われた。 本記事では、1ペー
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Silicon Valley Japanese Entrepreneur Network (SVJEN): アーキテクトという仕事