https://orecon.connpass.com/event/63769/
iOS でテスト容易な設計を
実現するためのデザインパターン
https://orecon.connpass.com/event/63769/
MVC→MVP→MVVM→Fluxの実装の違いを比較してみる
iOSDC 2017 9/17 13:50 TrackB https://iosdc.jp/2017/node/1396 iOSDesignPatternSamples https://github.com/marty-suzuki/iOSDesignPatternSamples FluxCapacitory https://github.com/marty-suzuki/FluxCapacitor Flux & MVVM (Brooklyn Swift Developers) https://speakerdeck.com/martysuzuki/flux-and-mvvm-brooklyn-swift-developers 補足資料 【iOSDC2017】MVC→MVP→MVVM→Fluxの実装の違いを比較してみる https://qiita.com/marty-suzuki/item
Rust風にデザインパターン23種 | κeenのHappy Hacκing Blog
κeenです。 GoFのデザインパターンは有名ですが、言語機能によっては単純化できたりあるいは不要だったりするのでRust風に書き換えたらどうなるか試してみます。 発端はこのツイート。 デザインパターン、古いJavaの機能の足りなさのワークアラウンド的なテクニックも含まれてるからあまり宜しくないんだよね。enumやクロージャで十分なのもいくつかある。 Rustで写経、デザインパターン23種 - Qiitahttps://t.co/MhpS3Z2OlF — κeen (@blackenedgold) 2017年5月5日 一応誤解のないように説明しておくと、該当のQiitaの記事に不満がある訳ではなくてGoFのデザインパターンついての言及です。 リンク先のコードで十分な時にはここでは流すのでリンク先も同時に参照下さい。 また、比較しやすいようにサンプルコードはリンク先のものに則って書きます。
cssで作るシェアボタンのデザインパターン36種類 - FOXISM
cssで作るシェアボタンのデザインパターンをたくさん考えてみました。とりあえずシェア数の表示がない、単純なボタンとして36種類あります。（色違いなども若干含みます。） 記述するhtmlはどれも同じようなものですが、一部微妙に異なるものもあります。基本的にはcssだけでデザインを決めています。アイコンフォントに関してもcssだけでほとんどやっていますが、そのコードは省略していますのでソースを見てください。 コピペでもだいたい使えると思いますが、それぞれ微調整が必要なものもあると思います。なのでコピペだけでなく自分のサイトに合わせて調整できるcss中級者以上向けですね。スマホ表示も考えてないし。（スマホで見ると崩れてるやんwと思う人はこの記事の対象外です。） というか、ローカルなhtmlで作っていたものをここにコピペしたらうまく動かないものやフォントが反映されていないものがありました。面倒なの
開発を効率化するテストのデザインパターン
2017/3/13 iOS Test Night #3 https://testnight.connpass.com/event/49561/
2016年度版 僕が考えたChrome拡張機能を作るときのデザインパターン - Qiita
4年近く前の2012年に僕が考えたChrome拡張機能を作るときのデザインパターンというエントリを書きました。最近参加したイベントで「よういちろうさんの拡張機能の記事見て作ってみました〜」と声をかけてくれた人がいて嬉しかったのですが、2012年のそのエントリは、すでに内容が古くなってしまっています。最近の状況を踏まえて、内容を新しくした「2016年度版」を書いてみようと思います。 変更しようと思った点は、以下です。 prototype.jsは使わず、ECMAScript 2015で書く。 Background Page(常駐型)ではなく、Event Page(非常駐型)にする。 そもそも最初のコードセットは自分で書かない。 本文やコード的には、2012年度版をコピペしています。 （この投稿の内容は、自分のブログエントリと同じです。） 前にいくつかのChrome拡張機能を作っていて、すでに数
DI・DIコンテナ、ちゃんと理解出来てる・・？ - Qiita
意外と分からずに、「とりあえず」とか「なんとなく」で使っちゃうパターンが多い系案件な気がして書いてみます。 こんな事ありませんか？ DIとDIコンテナの違いを説明出来ない DIとサービスロケータの違いを説明出来ない DIを使ってるつもりが、サービスロケータになっている DI、サービスロケータが、ただの「パターン」の１つであることを理解してない DI(Dependency Injection)を正しく理解する そもそも、Dependeny Injectionを日本語にするとどういう意味になるでしょうか。 多くの人が「依存性の注入」とか応えるのではないでしょうか？ 私もそうでした。きっと何かで読んだのでしょう。 (wikipediaに「依存性の注入」と書いてありますね) 補足 なぜ依存性を注入してあげると良いのか、そのメリット等は後述しますが、 DIというのはただのパターンの１つです。 たまに
デザインパターンをチームで学んで得たもの - CARTA TECH BLOG
おはようございます、こんにちは。Zucks Affiliate事業本部でエンジニアをやっている新卒二年目のだっちと申します。 この事業部には最近部署異動で配属され3ヶ月ほど経ちました。 さて、今回は@t_wadaさんと事業部内エンジニアで毎週行っているJava言語で学ぶデザインパターン入門の読書会で得た知識によって設計の語彙がチームに浸透してきて円滑にリファクタリングの方向性が進んだ話をしたいと思います。 簡単な事業部紹介 Zucks Affiliateは名前の通りアフィリエイトを扱っている事業部で、エンジニアや営業間のコミュニケーションも盛んで日々雑談から事業・技術的な相談まで気軽にしています。 エンジニア間では朝・夕会でお互いにやっていること・詰まっている部分を共有しているのに加えて、コードは全員でレビューし、具体的に何をしているかがしっかりと把握できている状態になっています。 総じて
Railsで導入してよかったデザインパターンと各クラスの役割について - masato_hiのブログ
3年ほどRailsを書いてきてある程度知見が溜まってきたので、忘れないためのメモとしてKPTと導入例を交えながらダラダラと書いています。 見出しの命名規則は クラス名/ディレクトリ名の単数形をupper camel caseにしたもの + KPT です。 Keepは今後も使うもの、Problemは開発規模によっては問題が発生する(した)もの、Tryは現在使用していないが使用したほうが良いと思っているものです。 これらすべてを導入すれば上手くいくというわけでもないので、開発規模に合わせて適切に採用していくと良いと思います。 DDDやデザインパターン等見聞きはしているものの詳しいわけではないので間違っている部分等あるとは思うのでその辺りはコメントでご指摘お願いします。 はてブコメント欄で頂いた指摘内容等についてはまとめの後でまとめて返答を記載しています。 Asset (Keep) app/as
分散プログラミングモデルおよびデザインパターンの考察 その2 - Software Transactional Memo
前回の記事では 分散システムのデザインパターンと銘打っておきながら並列・並行システムの分野の話からクラウド環境へとこじつける事を「分散システム」と呼んだ事。 システム全体を決定づけるわけでもない通信パターン上の選択肢の一部を切り出してシステムの本質のように呼んだ事。 プログラミングモデルと言いながらプログラミングモデルの話が一切出なかった事。 のうち一番上についてしか書かなかったので次に真ん中の項目についての話をする。物事を分類する際の一般論としては MECE であることが好まれるがYahoo!の記事はレイヤーも目的も様々な物を一緒くたに語っており、取り繕おうにも議論の空間があやふやなので何に対して網羅的なのかも議論ができない。「マスターやワーカーというのは役割の議論であり通信パターンの議論ではない」「Producer-Consumerはデータフローの一種と呼べないのか？」「データフローは
デザインパターン（Design Pattern）#Singleton - Qiita
設計を意識したコードが書けるようになる為に、デザインパターン修行しました。 他のDesign Patternもちょくちょく出していきます。 前置き 増補改訂版Java言語で学ぶデザインパターン入門をJavaからPythonにしてます。（Pythonは3.4.2） githubにコード置いてあります（まだ動かないものもある） デザインパターンをどういう時に、何を、どう使うのかを理解することが一先ずの目標。 （Javaというか静的型付言語は初めてで、且つpython歴もそんなに長くないので、Pythonistaぽっくないところがあると思います。ご指摘ございましたらご教授ください。） まず、そもそもデザインパターンってどういうものかってとこから。 デザインパターンとは ソフトウェア開発におけるデザインパターン（型紙（かたがみ）または設計パターン、英: design pattern）とは、過去のソ
GoFの23のデザインパターンを，Javaで活用するための一覧表 （パターンごとの要約コメント付き） - 主に言語とシステム開発に関して
GoFデザインパターンの一覧表と，活用のためのコメント，および入門者が独学するためのリンク集（サンプルコード付き）。 入門者の独学を支援するために，このページのURLを提示して熟読させ，各パターンを短時間で効率よく学んでもらう。 デザインパターンはプログラマの常識だ。 Java使いかどうかは問わない。 にも関わらず，入門書を買ったまま，途中で挫折する人が多い。 挫折の原因は，パターンの数が23もあって，多いからだろう。 全パターンをすんなり覚えてもらうためには，各パターンごとに 「要するにこういう目的のパターンなんだ。」 「10文字で表現すると，パターンの意味はこうなんだ。」 という要点・本質を，短いコメントで伝えれば助けになるだろう。 こういった学習を通して，Java言語の「設計思想」も併せて感じ取ってゆけるはず。 全パターンの一覧表（要約コメント付き） 全パターンについて，10文字以内
【PHPで学ぶデザインパターン入門】第1回 Strategyパターン | 株式会社LIG(リグ)｜DX支援・システム開発・Web制作
こんにちは、エンジニアの王です。 今回はデザインパターンと、デザインパターンの中の「Strategy」について紹介したいと思います。 デザインパターンとは？ 端的にいうと、「よくある問題へのよくある解決策」です。 ここでは、あくまでもソフトウェア設計の場合に限定しているのですが、さまざまなコンテキストで活かせる概念です。 「今までの経験上、この手の問題なら、この方法（パターン）でやればうまくいくよ！」という経験則は誰にでもあると思います。それがゲームの場合なら「攻略法」、料理の場合なら「レシピ」、語学の場合なら「定型文」だったりします。 ソフトウェア設計の場合、特にオブジェクト指向プログラミングにおいて言うなら、「デザインパターン」とは、過去のソフトウェア設計者が失敗に失敗を重ね、試行錯誤の中から導き出した再利用しやすいノウハウの集大成のようなものです。 そう、要するに、柔軟性、拡張性、再
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
O/Rマッパーによるトラブルを未然に防ぐ
デザインパターン[モデリング] -TECHSCORE-