タグ

ブックマーク / ryoasai.hatenadiary.org (11)

  • 業務系のJavaプログラマーが知っておくべき10個のBad Partsとその対策 - 達人プログラマーを目指して

    Java: The Good Partsののタイトルに触発されて、逆にJava言語の使いにくい部分をいくつかピックアップしてみました。Java EEなどの業務系のアプリケーションプログラマーの視点で書いていますので、別の立場ではここで指摘している事項が必ずしもBad Partではないという指摘もあるかもしれませんし、他にもいろいろなポイントがあると思いますが、とりあえず、私の独断で思いついたものを10個説明したいと思います。 1.標準APIのチェック例外が扱いにくい Java言語のチェック例外は当にGood Partなのか? - 達人プログラマーを目指してでも取り上げましたが、Bad Partの第一番目として標準APIのチェック例外が扱いにくいという点を指摘させていただきたいと思います。チェック例外については、理屈上コンパイラーによって例外の処理をプログラマーに強制させることができるす

    業務系のJavaプログラマーが知っておくべき10個のBad Partsとその対策 - 達人プログラマーを目指して
    yuiseki
    yuiseki 2017/10/01
  • 開発チームにアーキテクトがいないなと感じてしまうような、残念なコードスメルの例 - 達人プログラマーを目指して

    まったく個人的なモチベーションの問題から、前回の最終更新から2年以上が経過してしまい、多くの読者のみなさんにはご心配をおかけいたしました。「プログラミングに関して調べたことや日々感じたことをメモとして残していきたいと思います。」というもともとの原点に立ち返って、あまり気負わずに、また今後も時々更新していけたらと思います。今までこのブログの主なテーマとして、JavaEEやSpringといったような、いわゆる業務開発で使われるような技術を中心としてきたわけですが、最近Springを使ったJavaの開発に(アーキテクトではなく)プログラマーとしてちょっと参加する機会があったので、その時気づいたこと、感じたことを書いてみたいと思います。 さて、皆さんはアーキテクチャやアーキテクトという言葉に対してはどのようなものをイメージするでしょうか。システムのセキュリティを確保するための方式であったり、大量の

    開発チームにアーキテクトがいないなと感じてしまうような、残念なコードスメルの例 - 達人プログラマーを目指して
    yuiseki
    yuiseki 2014/05/10
  • DDDの読書記録(第4章、ドメインを隔離する) - 達人プログラマーを目指して

    DDDのモデル駆動設計では、在庫管理、注文管理といったドメインから生じる問題を解決するのに特化した部分に焦点を当てます。そして、ドメインの問題を他の問題から明確に切り離すことを設計上の至上命令としています。 これは夜空に星座を見つけ出そうとするようなものだ。ドメインオブジェクトはシステムの他の機能から切り離す必要がある。そうすることで、ドメインの概念を、ソフトウェアの技術にしか関係しない概念と混同したり、システム全体の中に紛れ込んでドメインを見失ってしまったりすることを避けられるようになる。 夜空に星座を見つけ出すというのも印象的な表現ですが、プラネタリウムで一見バラバラに並んでいる星の中からサソリや白鳥の形が線や星座絵によって浮き上がってくるように、ドメインモデルを探し出してはっきりとチーム全体でイメージを共有できるようにするということが重要だと思います。この章ではそのための前提となるレ

    DDDの読書記録(第4章、ドメインを隔離する) - 達人プログラマーを目指して
  • 開発コストや技術リスクを考えない「上流設計」がシステムの複雑化と大規模な障害の原因となっているのでは? - 達人プログラマーを目指して

    皆さん、明けましておめでとうございます。昨年の後半は私自身SI業界からWeb業界へ転職したことなど仕事環境の変化があり、ブログの更新頻度も鈍りがちになってしまっていましたが、年もどうぞよろしくお願いいたします。 さて、ちょうど、一年前のお正月にはグルーポンのおせち料理事件が話題になっていましたが、私はおせち料理の品質とIT業界における品質の問題を絡めて、以下の記事を書きました。 グルーポンのおせち事件を受けてSI業界が当に教訓とすべきこと - 達人プログラマーを目指して この記事では、一般にSIerによって開発される日のシステムはあの事件おせち料理のように、低い品質に甘んじているが、多くの場合、社内システムなどではそういった品質の問題が公に明らかにされることが少ないのではということを指摘しました。ただ、その時は私の希望も込めて 最近はOSSやクラウドなどの影響で社内システムもどんど

    開発コストや技術リスクを考えない「上流設計」がシステムの複雑化と大規模な障害の原因となっているのでは? - 達人プログラマーを目指して
    yuiseki
    yuiseki 2012/01/04
  • Javaのクラスとオブジェクトについて再度解説を試みる - 達人プログラマーを目指して

    オブジェクト指向プログラミングの考え方については、今までこのブログでも何度か取り上げてきました。 [オブジェクト指向] - 達人プログラマーを目指して オブジェクト指向プログラミングはプログラミング技法のすべてではないとはいえ、Javaのようなオブジェクト指向言語で格的なプログラムを作るには理解を避けて通ることができませんし、また、関数型言語など他のパラダイムの言語を利用するにしても、オブジェクト指向の考え方をまったく理解しないまま使いこなすということは困難でしょう。オブジェクト指向の考え方はデータ構造やアルゴリズムといったことと同様に、プロフェッショナルなプログラマーが理解しておくべき基的な素養といってもよいと思います。実際、海外では募集要項でオブジェクト指向の理解を前提とすると書かれていることが普通ですし、プログラマーの面接試験で、アルゴリズムと並んでオブジェクト指向プログラミング

    Javaのクラスとオブジェクトについて再度解説を試みる - 達人プログラマーを目指して
  • 日本における初の解説書であるJenkins実践入門を送っていただきました - 達人プログラマーを目指して

    先日、技術評論社の傳智之さん(@dentomo)より、Jenkins実践入門を献していただきました。どうも、ありがとうございました。 Jenkins実践入門 ?ビルド・テスト・デプロイを自動化する技術 (WEB+DB PRESS plus) 作者: 佐藤聖規,和田貴久,河村雅人,米沢弘樹,山岸啓,川口耕介出版社/メーカー: 技術評論社発売日: 2011/11/11メディア: 単行(ソフトカバー)購入: 26人 クリック: 496回この商品を含むブログ (64件) を見る既に、Jenkins(Hudson)については、開発プロセスを自動化する継続的インテグレーションに欠かせないツールとして、日でも非常に人気高いツールとなっており、また、雑誌やインターネットの記事でも今まで時々特集が組まれてきたと思います。WEB+DB PRESS 総集編 [Vol.1?60] 作者: 森田創,cho45

    日本における初の解説書であるJenkins実践入門を送っていただきました - 達人プログラマーを目指して
  • すでに定年を過ぎていますが、Amazonで引き続き達人プログラマーを目指すことになりました。 - 達人プログラマーを目指して

    このたび9月末日をもってオージス総研を退職し、10月よりアマゾンジャパン株式会社に入社しました。今後はSoftware Development Engineerとして、日をはじめ世界各国のAmazonのモバイルWebアプリケーションの開発を担当することになる予定です。 およそ7年間にわたり、前職のオージス総研ではソフトウェアアーキテクトとして、SOAやEAといった全社的なシステムのアーキテクチャから、上流のモデリング、Java EEを使ったアプリケーションの開発など、技術者として様々な経験を積ませていただきました。私自身はこのブログでも何度も取り上げてきたように、モデリングやオブジェクト指向といった技術を用いて、実際の基幹業務システムの設計などに活用することで、高品質で保守性の高いシステムの構築に貢献したいという思いがありました。そのようなシステムを構築、維持するためには高品質なアーキテ

    すでに定年を過ぎていますが、Amazonで引き続き達人プログラマーを目指すことになりました。 - 達人プログラマーを目指して
    yuiseki
    yuiseki 2011/10/04
  • staticおじさん達に伝えたい、手続き指向とオブジェクト指向の再利用の考え方の違いについて - 達人プログラマーを目指して

    何が良いプログラムかという点はもちろん人やコンテキストによって異なりますが、少なくともプログラマーとしての私の信念としては、 機能拡張や変更が容易なプログラム 単体試験によって正しく動作することの検証が容易なプログラム どういった内容が記述されているか理解しやすいプログラム といったものこそ、「品質の高い」プログラムが持つべき性質として、まず真っ先に挙げるべき事項であると考えています。もちろん、前提として顧客の要件に従うということは大切なことです。しかし、一般に要件は長期にわたって変更されるものですし、使い捨てのプログラムを除けば、プログラムを長期にわたって保守するコストという点も見過ごすべきではありません。したがって、ユーザーの目には触れない上記の性質をもっと重視すべきだと思うのです。 DRYの原理 上記のような性質を満たすプログラムを作る上で大切になってくる原理として、DRYの原理とい

    staticおじさん達に伝えたい、手続き指向とオブジェクト指向の再利用の考え方の違いについて - 達人プログラマーを目指して
    yuiseki
    yuiseki 2011/07/03
  • プログラミングと設計は本来切り離せないものなのでは - 達人プログラマーを目指して

    最近はアーキテクトという役割で客先に常駐し、フレームワークの選定をしたり、事前に共通部品を設計したりする役割を担う仕事を引き受けることが結構あります。そこで運よくお客様のマネージャーがオブジェクト指向開発の経験が十分にある方だと、IDEなどの開発環境やインターネット接続環境を当然のように用意してくれるので最初から仕事がスムーズにできるのですが、そうでないとMS Officeしか入っていないロースペックのノートPCを渡されて、要件定義フェーズの期間中、フレームワークの設計をお願いしますとか、私としてはちょっと首をかしげてしまうような困ったことを言われてしまう場合があります。開発フェーズが始まる半年後まではコーディングは基的に不要という考え方です。アプリケーションのアーキテクトという役割では少なくともコーディング規約を考えたり、ツールやフレームワークの選定をしたりする必要がありますし、プロジ

    プログラミングと設計は本来切り離せないものなのでは - 達人プログラマーを目指して
  • O/Rマッピングで緩和されるインピーダンスミスマッチには静的と動的の側面がある - 達人プログラマーを目指して

    一般的な業務アプリケーションではデータを永続化するために、RDBMS(関係データベース管理システム)を利用します。RDBMSでは大量のデータを効率的に検索したり、集約してレポートを作ったりすることが得意ですし、一般的に業務システムで求められるトランザクションのACID特性*1を満たすことも容易です。また、適切にテーブル設計の正規化を行うことにより、運用面においてデータの管理コストを下げることもできます。最近ではスケーラビリティの問題などもあり、RDBMS以外のデータベースについても注目されるようになってきていますが、今後も業務アプリケーションの主流としてRDBMSは使われていくだろうと思われます。 従って、Javaなどのオブジェクト指向言語で開発を行い、DDDのようなオブジェクト指向の設計技法を利用する場合に必ず考えなくてはならない問題は、オブジェクト指向と関係モデルとのインピーダンスダン

    O/Rマッピングで緩和されるインピーダンスミスマッチには静的と動的の側面がある - 達人プログラマーを目指して
  • 普通の業務系PGには意外と知られていないJavaとJavaScriptの相違点10選 - 達人プログラマーを目指して

    以前はJava EEの普通のWebアプリケーションで、JavaScriptはあくまでも利便性のために補助的に使うものという認識がありましたが、さすがに最近では普通の業務系のSI案件でもテーブル表示や入力補助などで高度なAjaxライブラリーの使用が当たり前のように求められるようになりつつあります。サーバーサイドのJavaScript技術といったものもありますが、そういった新しい技術を使わないまでも、ごく普通にある程度大きなJavaScriptの作成が必要になってきているということです。 もちろん、JavaJavaScriptはその名前にかかわらず、来全く別の言語です。しかし、意図的に似た構文でロジックが書ける*1ため、兄弟の言語として認識している人も意外に多いのではないかと思います。しかし、使用できるライブラリーに違いがあるという点が一見してわかる最も大きな違いですが、基的な言語の文法

    普通の業務系PGには意外と知られていないJavaとJavaScriptの相違点10選 - 達人プログラマーを目指して
    yuiseki
    yuiseki 2011/04/24
  • 1