なぜ、今さら「オブジェクト指向」を学ぶのか？ | 今さら聞けない！ゼロから学ぶオブジェクト指向 | Think IT（シンクイット）
はじめに本連載は、オブジェクト指向、クラス設計やデザインパターンを覚える必要があると感じている新人や若手エンジニアに一から分かりやすく学んでもらうことを目的としています。 また、新人や若手でなくても、これから勉強しよう、以前に勉強途中で理解できず諦めてしまったという中堅エンジニアでも、挫折することなく実務で活かせるまでに理解できるような指南書となれば幸いです。 本連載の開始に至った背景オブジェクト指向、クラス設計、デザインパターン。これらは新しい技術ではありません。以前はこれらの技術を使うことで汎用性、拡張性などに富み、一時期はもてはやされた技術でした。 しかし、何も考えずさっと作ってしまうより、プログラミング前に設計するという工数、つまりコストが掛かってしまうデメリットがあります。 また、「はじめに」でも述べましたが、オブジェクト指向などが理解できず断念してしまったエンジニアも数多くいま
Elixir から Elm の流れで、いよいよオブジェクト指向に対する懐疑心が無視できないレベルに達した2017年冬。 – ゆびてく
Click here to enter
2017年のPHPフレームワーク——2強時代に何を学ぶべきか？
動きの早いフロントエンド界隈や他の言語の躍進の話題に押されて、いつまでも古い知識のままPHPで開発していませんか？ 知識のアップデートに役立つ、最近のフレームワークの動向を、ちょっと辛口な現状分析とともに。 私が約1年前に書いた記事の続きを書くことにしたのは次の質問を受けたからです。 Q：PHP MVCフレームワークについて近況を教えてください。（2017/2/24） A：PHPのフレームワークといえば、現時点ではLaravelとSymfonyに尽きます。これから新しいプロジェクトを始めるなら、わざわざCakePHP、Zend、CodeIgniter、Yiiなどを使う理由は見当たりません。これらのフレームワークを使い慣れているか開発経験のある開発者がいないのなら、使う理由はないでしょう。 実際に開発が始まったら、ツールやプラグインを集めたり、よくある問題への対処方法を調べたりする必要があり
これだけは覚えたい、ユニットテストを書くための４つのデザイン - Qiita
もうちょっと規約的なものを「JavaでのUT作成基準を整理してみた」にもまとめてみました。 はじめに 去年、ブログの方に「ふつうのユニットテストのための７つのルール」という記事を書いたのですが、思ったより反響がありました。 あの記事で書いたのはあくまで原理・原則で、それを実現するためにはいくつかのテクニックが必要です。 特に、ああいうルールを作って「ユニットテストを書く事」を厳守するようにしても、 適切なテクニックを知らなければメンテが困難だったり、品質に寄与しなかったり、実行性能が悪いゴミが量産される可能性があります。 じゃあ、どうすれば良いかというと「最初からユニットテストが書きやすいように元のコードを設計する」ということです。 そう。まず身に付けるべきは「テストコードの書き方」では無く「テスト対象コード」すなわち「プロダクトコードの書き方」なのです。 また、ここで言ってる「最初から」
Functional DDD
This document discusses functional domain-driven design and the use of monads. It begins by stating that functional domain-driven design is still a work in progress. It then provides definitions of monads and functions as they relate to category theory. The document discusses how monads can be used with a functional approach to domain-driven design. It also includes brief biographical information
Domain-Driven Design (DDD)
3月19日(月)に要求開発アライアンスのセッション『Object-Functional Analysis and Design: 次世代モデリングパラダイムへの道標』を行いましたが、説明を端折ったところを中心にスライドの回顧をしています。 「Domain-Driven Design (DDD)」として用意した以下のスライドを説明します。 セッションの全体構成は以下のようになっています。 関数型プログラミング Object Functional Programming (OFP) Object Functional Analysis and Design (OFAD) 応用 この中で4番目「応用」は、今OOADやクラウド・プラットフォームで話題となっている技術がOFADでどのような影響を受けそうなのかということを考えてみる趣旨のセクションです。 具体的に考えてみることで、OFADへのイメージ
Docker vs. CoreOS コンテナ戦争とは何だったのか？ ―Linux Foundationが「Open Source Forum 2016」でOSSプロジェクト最新状況を紹介 | gihyo.jp
Docker vs. CoreOS コンテナ戦争とは何だったのか？ ―Linux Foundationが「Open Source Forum 2016」でOSSプロジェクト最新状況を紹介 Linux Foundationは11月15日、日本におけるオープンソース活用を推進する活動の一環として「Open Source Forum 2016」を横浜にて開催しました。 Linuxの普及をサポートするNPOであるLinux Foundationは、これまで毎秋に国内外のユーザ企業向け技術カンファレンスとして「Enterprise User's Meeting」を開催してきました。Linux Foundation 日本担当VPの福安 徳晃氏は、毎年改善を繰り返してきた「Enterprise User's Meeting」を今年から「Open Source Forum」として始動することになったといい
俺が悪かった。素直に間違いを認めるから、もうサービスクラスとか作るのは止めてくれ - Qiita
class HogehogeService # Hogehogeはモデル名まんま def process(hogehoge, option_a: nil, option_b: nil, option_c: false) history = hogehoge.histories.last unless hogehoge.active? hogehoge.histories.last.update(state: :cancel) return error_message end case hogehoge.kind when "type_a" # ... when "type_b" # ... end ActiveRecord::Base.transaction do history.save! history.create_foobars end end end 何が酷いって、機能が何なのか
コードレビューをより効果的にする方法
ツールに任せることができないどんなことを人間は指摘できるのだろうか？ 驚くほど多数の事柄があることがわかっている。この記事の残りで幅広い重要事項のリストに触れ、2つの特定の領域、パフォーマンスとセキュリティに関してはもう少し深く言及する。 設計 新しいコードは全体アーキテクチャに適合しているだろうか？ コードはSOLID原則、ドメイン駆動設計、もしくはチームが採用する他の設計手法に従っているだろうか？ 新しいコードでデザインパターンは使用されているだろうか？これらは適切だろうか？ コードベースの標準や設計スタイルが混合されている場合は、新しいコードは現在の原則に従っているだろうか？コードは現在の方向性を引き継いでいるか、徐々に除去される古いコードの例に従っているだろうか？ コードは正しい場所に配置されているだろうか？例えば、コードが注文に関係する場合は、それは注文サービスの中にあるだろうか
責任(関心)を意識したアプリケーション設計 - Qiita
プログラムが上手く組めるようになりたい プログラミングが上手くなりたいと考えたときに、個人的には『名付けを意識』するのと、『アプリケーション設計のときに責任を意識する』考え方を取り入れることをおすすめしております。 今回は『アプリケーション設計のときに責任を意識する』ことについて書いてみたいと思います。 基本的には単一責任原則と、関心の分離のお話になります。 ※ タイトルに『関心』というワードがありますが、アスペクト指向プログラミングの話ではありません 単一責任原則とは まずは単一責任原則とは何かについてです。 よく単一責任原則の説明では「クラスを変更する理由は複数存在してはいけない」というニュアンスの言葉がよく使われます。 例えば、社員管理システムの実装を行いたい場合、一つのクラスに「社員登録」「出勤管理」「給与管理」などの機能を詰め込むと、『社員登録』の変更をする際にそのクラスが変更さ
契約による設計と名前による型づけ, およびオブジェクトの不変性 - 貳佰伍拾陸夜日記
契約による設計と名前による型づけ 最近, 社内で契約による設計の話が雑談として何度か出ていて, id:hakobe932さんが社内勉強会で紹介していたり, id:shiba_yu36さんがWEB+DB PRESSでSmart::Argsで制約をチェックする記事を書いていたり, 活発な議論になっている. インスタンスのファクトリメソッドとオプショナルな型を組み合わせると事前・事後条件を満たすことが保証できて, id:hakobe932さんの資料で言うところの「要求型」と「保護型」の区別も明確になってよいという話を書こうかとおもっていた. (これはそのうち別で書く.) とはいえ, こんな話はもう言っている人がいるだろうと思ってちょっと調べていて, どういう語句で調べたらいいか考えていた. インスタンスの型からそれを生成したファクトリメソッドが特定できて, それによって事前・事後条件が保証される
「コメントを書かない言い訳」に関する考察再び - がるの健忘録
元ネタこちら プログラムにコメント書かない文化もあるよって話 http://nzmoyasystem.hatenablog.com/entry/no_comment_culture http://megalodon.jp/2016-0422-0815-58/nzmoyasystem.hatenablog.com/entry/no_comment_culture (魚拓：ものすげぇ念の為) まぁおいちゃんの結論は「コメントを書け！( http://d.hatena.ne.jp/gallu/20150328/p1 )」で片付くんだけど、そこに至るまでの諸々を、改めてざっくり考察。 筆者が勤めている会社では、原則、プログラムにコメントを書かないのがルールです。 まぁそれが「ルールである限り」、それはそれでよいのかなぁ、と。後先考えなければ。 同僚いわく、「コメントが無くても読めるようなプログラム
筋の悪さ - 氾濫原
JS しか書いてないんだなって人は筋悪いものをありがたがっていたりする印象はある。しかし筋悪いものをありがたがるみたいなのはどこにでもいるので、JSがどうとかは直接は関係がないはずではあると思う。JSしか書いてない人とPHPしか書いてない人は似たようなもんで、単に広範囲の知識に興味がないだけな気がする。 それはともかく「これは筋悪そうだな」っていう感覚がどこからくるのかよくわかってないので、現時点で思いつく限り雑にメモしておく。 割の合わなさ 「これは何の問題を解決してるんだろう」と思ってドキュメント読んだりソース読んだりした結果、大したことを解決してなくて、その割に実装量が多いとか学習コストが高いと、筋悪いなあと思う。 フットプリントや学習コストに対して提供されるモノが「割に合わない」のは筋が悪く感じる。 将来性のなさ 「あ、これはただの流行だな」みたいな、5年後には消滅してるなというも
最近のフロントエンドへの違和感 - nobkzのブログ
そういえば今日これらを読んでて d.hatena.ne.jp d.hatena.ne.jp その中で Mediumなど海外メディアでは、もはやこの種のツールを組み合わせたフロントエンド開発が当たり前として受け入れらており... はぁ? 「海外では当たり前()なんですねw 海外ってどこですか? タンザニア? パフアニューギニア? 」などみたいなリアクションを取りつつ、んで、まぁ、フロントエンドに関して、書きたかったことがあって、丁度良いので書いてみる。 というのも、フロントエンドが「凄く変化が早い」「ついていくのに大変」「新しい!!すごい」「これからは○○フレームワーク」だとかそんないろいろな意見が見られて、なんというか違和感を感じてるので今回はそれについて書く。 フロントエンドは変化が早い? まずこれ。僕は普通に違和感を感じている。確かに、jsフレームワークやライブラリとしたら、jQuer
変更履歴を持つテーブルの設計 - Qiita
ある日のできごと 少し前、「ブログの記事のようなものを、履歴を残しつつ編集できるようにするにはどのようなテーブル設計が良いか？」と尋ねられたことがありました. その時, まず思いついた（というか見聞きしたことがある方法）のは以下の様な2通りの方法だった. 記事テーブルにバージョン番号を持たせる方法 記事テーブルとは別に, だいたい同じ構造の履歴テーブルを持つ方法 こられの手法のメリット・デメリットについて, すこし考えていきたいと思います. その1 記事テーブルにバージョン番号を持たせる方法 概要 この方法では, 記事テーブルは一つだけ用意し, 更新される度に新しいレコードを追加していきます. 主キーはidとなるが, これはサロゲートキーで, 本当の主キーは「記事グループid + verison」の複合主キーとなっています. 記事の最終更新日時は, 最新Versionのレコードのinser
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
似非サービスクラスの殺し方 / #ginzarb
Rust vs. Go に対する @tanakh さんの発言まとめ
MVVMって何？ というか…MV○丸ごと、何？
これだけ覚えておけばOK！シェルスクリプトで冪等性を担保するためのTips集 - Qiita
http://post.simplie.jp/posts/34
