タグ

関連タグで絞り込む (0)

  • 関連タグはありません

タグの絞り込みを解除

Programmingとdesignとprogrammingに関するch1248のブックマーク (38)

  • エンジニアが知っておいて損は無さそうなISOの標準規格たち - Qiita

    「それ○○で標準化されているよ」って指摘されることほど、エンジニアにとっての屈辱は無いですよね。 ということで、世間知らずだと思われないためにも、手始めにISO縛りで有益そうな標準規格1をまとめてみました。 ちなみに、ISOとは…? 国際標準化機構(International Organization for Standardization)は国際規格を策定する世界最大のボランタリーな開発組織で、国家間に共通な標準を提供することによって、世界の貿易を促進することに貢献している という組織だそうです。 (どう考えてもIOSと略すべきだと思うのですが、ISOになった理由は諸説2あるようです。) コード体系 ISO 639 (言語名コード) 例: 日語 = ja, jpn 朝鮮語 = ko, kor 中国語 = zh, zho, chi, zho ドイツ = de, deu, ger, deu

    エンジニアが知っておいて損は無さそうなISOの標準規格たち - Qiita
  • MVCについて (3) | ぶろゲ

    厳密なMVCについて書こうかと思ったが、そもそも厳密なMVCはSmallTalkのMVCで自分はそれを知らない、ということに気がついた。つまり、MVCと名前の付く派生としてはrobotlegsとPureMVCくらいしか知らないので、自分の解釈は間違っているのかもしれない、という不安はある。よって、今回の話はそれらの派生MVCの話として、話半分に読んでほしい。 前回はMediatorがMVCとMCVの明暗を分けるとか何とか。Mediatorについては、MVCの細かい機能分けの話が絡むので、今回の話で。 厳密なMVCの機能分け MVCは制約をつけること(例えばpublicやprivate)で、誰もがわかりやすくて保守性の高いプログラムを書きましょう、という認識を持っている。これは、つまり、Model層、Controller層、View層に分けるということだ。 MVCをもっと仕分けすると色々出て

  • 英国正版365官方网站|中文-Best Casino No.1

  • Think IT著者陣がおくる デザインパターン必携書籍 厳選6冊

    スレッドのわず嫌いを克服する入門書 今回は、『GoF以外のデザインパターン』第3回を掲載する予定でしたが、諸般の事情により予定を変更して『著者陣がおくる!デザインパターン必携書籍 厳選6冊』と題した書評記事をお送りいたします。 デザインパターンを学ぶ上で、これは読んでおいたほうがいい!という書籍を、5月特集「デザインパターンを学ぶ」の著者陣に紹介していただきました。 ------------------------------------------------- 評者:安藤 崇周(オージス総研) 『増補改訂版 Java言語で学ぶデザインパターン入門 マルチスレッド編』 結城 浩 著 価格:4,935円(税込) 発行:2006/3 ソフトバンククリエイティブ Amazonのページはこちら→http://www.amazon.co.jp/dp/4797331623 「スレッドが苦手」「スレ

  • コードコンプリートを再読した - $shibayu36->blog;

    以前職業プログラマーなら必ず読むべき「Code Complete」 - $shibayu36->blog;や補足 - 職業プログラマーなら必ず読むべき「Code Complete」 - $shibayu36->blog;で紹介したコードコンプリートを再読した。 Code Complete 第2版 上 完全なプログラミングを目指して 作者:スティーブ マコネル日経BPAmazonCode Complete 第2版 下 完全なプログラミングを目指して 作者:スティーブ マコネル日経BPAmazon 一年前はどちらかというと、コードのスタイルの話とか、条件をどうやって綺麗に書くのかとか、コメントはどう書くのかということを学びたくて読んだけど、今回はクラス設計をどうしていくべきかとか、チームでのエンジニアリングをどうしたら良いかとかを中心に読んでいった。 やっぱり学びたいと思っている内容が違うとそ

    コードコンプリートを再読した - $shibayu36->blog;
  • クソコードは人を育てるか? - ミッションたぶんPossible

    結論から言えば、「条件付きで『あり』」になります。 一年くらい携帯コンテンツの開発というか運用保守をやってきていたんですが、最近になってまた業務システムに従事するようになりました。大手企業さんの社内システムで、既に3年ほど稼働しているものですから、システムとしてもそれなりに規模が大きく、仕様も膨大で複雑です。後発のオレとしては覚えることが多くてなかなか大変なんですけれども、昔取った杵柄、まぁそれなりに楽しくやってます。立場的にはPG兼SE。要するに「何でもやりますよ」ってことですね。 このシステムでオレが一番気に入らないのは「ソースコード」。PHPで構築されているんですが、まーーーーー、ひどい。今まで見てきた中で文句なしのブッチギリでNo.1を獲得したクソコードです。オレ自身大したプログラマじゃないので偉そうなことを言えないんですが、その立場をいけしゃあしゃあと棚上げしてでも、このソースコ

    クソコードは人を育てるか? - ミッションたぶんPossible
  • オブジェクト指向の法則集 - Qiita

    Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? この記事は、故石井勝さんが1999年に書いた記事を Qiita に転載するものです。オブラブ(objectclub.jp)にて記事をホスティングしていましたが、現代でも十分に読める内容なので、たくさんの方に読んでもらいたいと思い、若干の編集(リンクとコンテキスト追加)を平鍋が行い、転載します。今でも、読みやすく、カジュアルな語り口のよい記事です。 オブジェクト指向の法則集(転載元:http://objectclub.jp/community/memorial/homepage3.nifty.com/masarl/article/oo-p

    オブジェクト指向の法則集 - Qiita
  • ダブル・ディスパッチ~ 典型的なオブジェクト指向プログラミング・イディオム ~

    図1 レンタル・ショップのクラス図 (レベル1) ※クリックして拡大表示 このレンタル・ショップ(RentalShop)は複数の商品(Item)を所有しています。各商品はCDまたはDVDのいずれかの商品種別(ItemKind)を持ちます。同様に、このレンタル・ショップには複数の会員(Member)が登録されています。各会員には一般会員(Common)またはゴールド会員(Gold)という会員種別(MemberKind)があるものとします。レンタル料金の計算方法やレンタル可能日数などは、商品種別と会員種別の組合せによって変わってきます。 さて、このもっとも単純な構造の上でレンタル・ショップのさまざまな業務を実装していくことを考えてみてください。一連の業務の流れを実現するために、各クラスにはいろいろな操作が必要になってくると思いますが、ここではレンタル料金の計算を行う操作(calculateRe

    ダブル・ディスパッチ~ 典型的なオブジェクト指向プログラミング・イディオム ~
  • PHPでは配列ではなくオブジェクトに状態を持たせよ - なんたらノート第三期ベータ

    アドベントカレンダーを書いたらコメントに面白い課題もらいました。 「Python - すごく簡単なアルゴリズムがphpで書けなくてつらい」のやつ。 id:methane php の array と参照の関係がクソで無いなら、 http://qiita.com/methane/items/41e1376c41d8c15e8894 これを普通に書いてみてください。 id:tanakahisateru 面白そう。やりましょう。 最近ずいぶんPHP成分多めですが、実はPythonも好物なのでホクホクです。 といっても、あのエントリーは「php の array と参照の関係がクソで無い」とは言ってなくて、むしろ逆にそこは腐ってるから避けろ、オブジェクトで囲んでやれ、という話だったので...(^^ そのままやってもPythonの性能にはならないとわかっているので、配列を直接使うのはイヤです。なので、オ

    PHPでは配列ではなくオブジェクトに状態を持たせよ - なんたらノート第三期ベータ
    ch1248
    ch1248 2014/08/02
    重くなりそうな方がより良い実装となるのか。
  • GoFの23のデザインパターンを,Javaで活用するための一覧表 (パターンごとの要約コメント付き) - 主に言語とシステム開発に関して

    GoFデザインパターンの一覧表と,活用のためのコメント,および入門者が独学するためのリンク集(サンプルコード付き)。 入門者の独学を支援するために,このページのURLを提示して熟読させ,各パターンを短時間で効率よく学んでもらう。 デザインパターンはプログラマの常識だ。 Java使いかどうかは問わない。 にも関わらず,入門書を買ったまま,途中で挫折する人が多い。 挫折の原因は,パターンの数が23もあって,多いからだろう。 全パターンをすんなり覚えてもらうためには,各パターンごとに 「要するにこういう目的のパターンなんだ。」 「10文字で表現すると,パターンの意味はこうなんだ。」 という要点・質を,短いコメントで伝えれば助けになるだろう。 こういった学習を通して,Java言語の「設計思想」も併せて感じ取ってゆけるはず。 全パターンの一覧表(要約コメント付き) 全パターンについて,10文字以内

    GoFの23のデザインパターンを,Javaで活用するための一覧表 (パターンごとの要約コメント付き) - 主に言語とシステム開発に関して
  • 再考: GoF デザインパターン - Qiita

    Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 投稿は私の主観によって書かれています。コメントは大歓迎です。もし長くなるようでしたら別途記事に投稿し、リンクを張っていただけると嬉しいです。 概要 GoFのデザインパターンは適当すぎるから、いい加減、修正されるべき。 参考までに各パターンに対するコメントを書く。 GoFのデザインパターン GoFのデザインパターンは適当であり、教科書通りに学ぶべきものではないように思う。 以下がGoFのデザインパターンの良くない原因だろう。 が出版されたのは1994年であり、Java(1995)が出てくるよりも前だった オブジェクト指向が未成熟な時代

    再考: GoF デザインパターン - Qiita
  • デザインパターンを読み解く

    ポリモーフィズム(サブクラスによる切り替え、抽象化) ここに分類されるのは、オブジェクト指向の第3原則、ポリモーフィズムを使用したパターンです。ポリモーフィズムを使用すると、動的に使用するクラスを切り替えることができます。<参照> 他に分類されているものでも、ポリモーフィズムが重要な位置を占めているものもありますが、ここではそれしか使われていないものを扱います。 ただデザインパターン全体を通して強調されているのは、インターフェースでプログラミングするということです。実装への依存をなくし、そうすることによって設計の骨組みを明らかにするのです。 Template 次のようなメソッドがあった場合に、処理Bのところを条件によって変えたい場合があるとします。 class Hogehoge { void doit() { ... 処理A ... ... 処理B ... ... 処理C ... } }

  • MVCの流れを簡単にまとめてみる - Qiita [キータ]

    Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 理解しやすいように適当に遮ったり、言い切ってしまったところもあるがご容赦いただきたい。 MVCの登場 MVCは、SmalltalkのGUIライブラリのモデルとして登場した。 これはGUIアプリケーションを記述する際に、適切なモデル化を進めるのにとてもいい考え方だと思われていたし、実際にそうだった。 これはアーキテクチャパターンとして、それぞれがどのように依存するべきか、どこにコードを書くべきかということを端的に表している。 安定依存の原則というものがある。これは、要件が安定しているモジュールに依存し、要件が変動しやすいモジュールには依存

    MVCの流れを簡単にまとめてみる - Qiita [キータ]
  • デザインパターンよりも、まずリファクタリングを学んだほうがいい - モジログ

    ウィキペディア - デザインパターン (ソフトウェア) http://ja.wikipedia.org/wiki/%E3%83%87 <ソフトウェア開発におけるデザインパターン(型紙(かたがみ)または設計パターン、英: design pattern)とは、過去のソフトウェア設計者が発見し編み出した設計ノウハウを蓄積し、名前をつけ、再利用しやすいように特定の規約に従ってカタログ化したものである>。 ウィキペディア - リファクタリング http://ja.wikipedia.org/wiki/%E3%83%AA.. <リファクタリング (refactoring) とはコンピュータプログラミングにおいて、プログラムの外部から見た動作を変えずにソースコードの内部構造を整理すること。いくつかのリファクタリング手法の総称としても使われる。十分に確立された技術とはいえず、「リファクタリング」の語にも厳

  • デザインパターンそのものをプログラミングする - 設計者の発言

    前回記事で示したスクリーンショットはいずれも実際に動作するアプリのものなのだが、従来のように人手でプログラミングされたものではない。それらは「仕様書」としてのみ存在する。それをある種のインタプリタに渡すだけで、仕様にしたがって動作するアプリが動的に立ち上がる。コードの自動生成も伴わない。 そのインタプリタは、前回記事で説明した「デザインパターン」毎に用意されている。つまりそれらは「プログラムのパターン」そのものをプログラミングしたものである。このようなプログラミングを「メタプログラミング」という。私はこれが、業務システムの開発・保守効率を劇的に向上させる鍵のひとつだと考えている。 ■メタプログラミングの威力 なぜなら、パターンそのものをプログラミングしておけば、そのパターンに類型化されるアプリをいちいちプログラミングせずに済むからだ。個々のアプリに求められている処理要件を洞察して、対応する

    デザインパターンそのものをプログラミングする - 設計者の発言
  • オブジェクト指向の本懐・あとがき・オブジェクト指向における再利用 - Strategic Choice

    「オブジェクト指向の懐」を書いていて、気付いたことが2つありました。1つめは「再利用」の意味です。オブジェクト指向的再利用いわゆるGoFと言われている書籍の正式名称は「オブジェクト指向における再利用のためのデザインパターン」です。私はこの「再利用」の意味をずっと勘違いしていました。これまでは、この再利用を「この書籍でデザインのパターンを紹介するので、そのパターンを是非再利用してください」という意味だと思っていました。しかし、この書籍の題意は「オブジェクト指向で流動的要素をカプセル化し、その他の部分を再利用するためのデザインのパターン」ということだったのです。 デザインパターンの流動的要素確かに、流動的要素のカプセル化は、多くのデザインパターンのテーマになっているようです。ただ、その観点で意識をしてデザインパターンを見たことがなかったので、当にそうなのか、考察してみる事にしました。Ab

  • デザインパターン入門 マルチスレッド編まとめ - リトルプログラマーの日記

    がーっと読んだ。実際に使うときの思い出しトリガーになるようにメモしておく。 Java言語で学ぶデザインパターン入門 マルチスレッド編 マルチスレッドプログラムの評価基準 安全性 オブジェクトを壊さないこと スレッドセーフなクラス 生存性 必要な処理が行われること 安全性を重視しただけでは生存性を下げてしまう場合がある。例えばデッドロック。 再利用性 クラスを再利用できること スレッドの排他制御の仕組みや方針をうまくクラスの中に隠蔽すれば、再利用性の高いプログラムになる。 パフォーマンス 処理を高速・大量に行えること 安全性と生存性を守るのは必須。その上で、いかにして再利用性とパフォーマンスを上げるかが重要。 Single Thread Execution 「この橋を渡れるのは、たった一人」 複数のスレッドがインスタンスを共有する場合の基パターン クリティカルセッション(インスタンスが不安

    デザインパターン入門 マルチスレッド編まとめ - リトルプログラマーの日記
  • ソフトウェア工学とは何か

    ソフトウェア設計とは何か? (原文: What Is Software Design?) by Jack W. Reeves (c)C++ Journal - 1992 訳者まえがき この文書は,Jack W. Reeves 氏が1992年に C++ Journal に寄稿した記事の邦訳です。 記事では,オブジェクト指向プログラミング言語の代表として C++ を挙げていますが,これは記事が執筆された当時,一般的に利用可能なオブジェクト指向言語は C++ だけであったという事情があるためです。 今では C++ に加えて Java,Delphi,C# といったオブジェクト指向言語が利用可能となっていますが,そんな今でさえこの記事は古さを感じないものとなっており,ソフトウェア開発の質,現状を鋭くえぐるものとなっています。 邦訳の公開を許諾していただいた Jack W. Reeves 氏に,