デザインパターンの話 - Qiita
irxground 君が再考: GoF デザインパターンといふ記事を書いてゐるので自分もちょっとコメントしてみます。 基本的に irxground 君と同意見のところは省略します。 あと、GoF の本自体は私は読んでゐません。 (GoF のパターン以外のパターンに関する意見の方が長くなってますね……。) GoF のデザインパターン 生成に関するパターン Builder そもそも builder パターンは Java の String と StringBuilder の様に可変オブジェクトと不変オブジェクトを別のクラスに設計しなければならない言語でしか基本的に役に立たないパターンであり、C++ の様にキャストだけで可変オブジェクトを不変オブジェクトに変換できる言語ではこのパターンは無用なはずである。 Java が出る前の本でこれがパターンとして挙げられてゐたといふのが俺には不思議に感じられる
変数や関数の名前がいつの間にか分かりにくくなる問題 - Qiita
TL;DR: 変数や関数を追加するときは、周りにある他の変数や関数の名前を修正すべきでないか検討せよ いきなりですが問題です。あるソフトウェアモジュールに以下の三つの関数があります。 show showWithSlideAnimation showWithoutAnimation 画面をスライドさせながら出現させるにはどの関数を使用すれば良いでせうか? 関数の名前だけを見て答へてください。 はい、その通り。showWithSlideAnimation が正解です。 では、画面をアニメーションなしで出現させたい場合はどの関数が良いでせうか? はい、showWithoutAnimation が正解ですね。 今度は、画面を回転させながら出現させたいとします。適する関数はあるでせうか? ブーーーッ! 残念、正解は「どの関数も適さないので新しく関数を実装する必要がある」でした。 これで最後です。画面
エンジニア歴20数年の私が、設計書を書く際に心がけていること - Qiita
はじめに 時の経つのは早いもので、私がIT業界に身を置いて四半世紀になってしまいました。 その間、膨大な数の「設計書（仕様書）」を書いて来ましたが、未だに悩み・迷いは尽きません。 それでも、亀の甲より年の劫とも申しますので、私なりの経験則を「個人」と「チーム」の両観点でまとめてみました。 本稿のテーマは、「主に設計書を想定した、開発ドキュメントの書き方」です。 本稿で前提とする設計書は、ExcelやWordで書かれた、フォーマルな（≒納品物になりえる）設計文書、です。 したがって、自社サービス開発よりも受託開発、アジャイルよりもウォーターフォール、を前提として読んでいただいた方が、しっくりくると思われます。 ＜ご注意＞ 本稿の内容は執筆者独自の見解であり、所属企業における立場、戦略、意見を代表するものではありません。 個人的に心がけていること 当該文書の作成目的や位置付けを冒頭に記載する
Go言語での構造体実装パターン
Go言語での構造体実装は、埋込や独自コンセプトのインターフェースといったGo言語独自の機能を理解して行う必要があります。 今年からGo言語を始めましたが理解が曖昧なままだと実装に迷うことが何度かありました。今回よい機会なので、Go言語での構造体実装パターンとしてまとめてみることにしました。 構造体実装パターン 実装パターンの洗い出しとして、GoFデザインパターンをGo言語で実装する手法をとりました。 その中で繰り返し現れる実装をGo言語での構造体実装パターンとしてまとめてみました。 コンストラクタ関数 エクスポートによるアクセス許可 インターフェースによるポリモフィズム 構造体によるポリモフィズム 構造体によるサブクラス・レスポンシビリティ 構造体による移譲 関数による移譲 以下、それぞれのパターンを解説していきます。 コンストラクタ関数 Go言語には構造体のコンストラクタがないため、構造
Railsアプリケーションで採用しているDBスキーマ設計ガイドライン - LCL Engineers' Blog
Webエンジニアの森脇です。 Railsアプリケーションで採用しているDB設計（スキーマ定義）について紹介します。 ※ Railsでは当たり前もの、Railsに依存していない内容も含んでいます。 前提 環境違えば、採用するルールも異なると思いますので、まずは弊社で利用している環境を記載します。 DBはPostgreSQL 9.x 開発言語は、Rails 4.x,5.xを利用 命名ルール Railsの規約に沿う命名を採用しています。DB設計にこだわりがあるメンバーにとっては、異論があるルールもあるのですが、アプリケーション開発の生産性も考慮しRailsの規約に寄り添うのがよいと判断をしました。 テーブル 動詞は使用せず、名詞とする 複数形とする 1:n のテーブル名は「単数形_複数形」 とする n:n のテーブル名は「複数形_複数形」とする カラム カラム名にテーブル名のprefixは付与し
自分たちにも優しい”デザインとは？ | MEDLEY Developer Portal
2018-01-31自分たちにも優しい”デザインとは？こんにちは。最近白髪が目立つようになりました。最初は蛍光灯の反射かな？とおもっていましたが実はそうじゃないらしいイケメン担当デザイナーの小山です。 私が担当しているジョブメドレーではサービスの改善をいくつも重ねますがその結果、全体の統一感が薄くなりデザインの改善をすることがあります。 こういった場合、もちろんユーザーの使いやすさを前提にリニューアルを考えますが、自分たち（開発者）にも使いやすいデザインはどういう姿か追いながら取り組むように心がけるようにしてみることにしました。 この試みの背景にはサービスのプロダクト基本理念が関係しています。このエントリでは、先般行ったモバイル向けの求職者画面のデザインリニューアルを通して、プロダクト基本理念に基づいた「自分たちにも使いやすいデザイン」を実現した話をご紹介いたします。 開発工数を増大させる
猫型プログラミング言語史観(1) 〜あるいはオブジェクト指向における設計指針のひとつ〜 - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
TL;DR 手続き型プログラミングでは手続きを抽象化することで保守性を挙げることに成功したが、データを守ることには失敗してしまった。そこでオブジェクト指向はデータと手続きをひとかたまりにすることでデータを外から守るというコンセプトを打ち出した。 ここから、「手続き型プログラミングで書いてるのに手続きが十分に抽象化されていないのはヤバいね」とか「オブジェクト指向で書いてるのにひとかたまりじゃない雑多なデータに関心をもっちゃってるのはヤバいね」などの設計指針を導くことができるのである。そして純粋関数型言語の場合は……という話です。 はじめに プログラミング言語にはいろいろなパラダイムがあるが、その中で手続き型プログラミング、オブジェクト指向、純粋関数型言語について、わたしなりのひとつの史観を示すのがこの稿の目的である。となんかかっこつけて言ってみたんだけど、要するに、それぞれのパラダイムがどん
適切に抽象化されたコードとはなにかって話 - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
適切に抽象化されたコードを書く、というのはまさに言うは易し行うは難しだ。 最近私が心がけていることのうちのひとつに、「未来を予測しない」というのがあって、「ここはあとから変更とか追加があるかもしれない」と思って抽象化しておくみたいなことはやめようと思ってる。ひとことで言うと、よくYAGNIとか言われるアレです。 そもそも、なんのために抽象化するのかというということを考えると、ひとつは「一塊の手続きに名前を付けて隠蔽して外から中を意識しないで済むようにする」ってことと、その副産物として「交換可能性が高まる」っていうのがある。 抽象化して実装を隠蔽することで、 コードが理解しやすくなる インターフェイスさえ合ってれば交換可能な部品として扱えるようになる という利点があるから、わたしたちは抽象化を行うわけだ(だからこそ「名前重要」なわけですね)。 この後者の利点に注目すると、ついつい「あっあとか
ランキング設計はどうあるべきか？ その3｜深津 貴之 (fladdict)
ここまでランキングのあるべき方向性と、実行可能なアプローチについて考察してきた。そして、いよいよプロトタイピングと実験の時間だ。残念ながら自分はサーバーサイドのコードが書けないので、ここからは開発チームに託すことになる。 妄想や実証不能なものをオーダーするのは非効率だと思う。ある程度はクラスをモデリングしておくと、エンジニアとディスカッションしやすい（ように思える）。 とりあえずnoteでのランキングは、様々な試行錯誤や実験が予想される。そのため、以下のような要素が必須となる。 ・工数最小 ・あらゆるランキングを表現できる ・拡張しやすい 今回はDecoratorパターンとCommandパターンを混ぜたような実装で、柔軟性のあるランキング計算システムのコンセプトを描いてみた。下手なコードでも、設計がある方がエンジニアさんに説明しやすい。 設計イメージとしては、まずランキングの各処理を同じイ
Railsのファットモデル問題に対処する前に読んでほしい記事 - Qiita
背景 Skinny Controller, Fat Model Railsではスキニーコントローラー、ファットモデル（Skinny Controller, Fat Model）という方針のもと、 コントローラーのコード量を少なくして、モデルを分厚くするという書き方が推奨されていました。 10 Ruby on Rails Best Practices — SitePoint Rails Best Practices 1: Fat Model – Skinny Controller このような背景から、ファットモデルという設計が目指すべき設計という認識となりました。 「ファットモデル問題」の登場 ところが、原因はわかりませんが、次第にファットモデルが問題があるものとしてみられるようになりました。 界隈では「ファットモデル問題」として取り上げて解決するという方法が紹介されるようになります。 20
ghqを使ったローカルリポジトリの統一的・効率的な管理について - Kentaro Kuribayashi's blog
GitなどのVCSからcloneしたローカルリポジトリをどう管理するのがいい感じなのか、よくわからない。なんとなく自己流でやっているが、もっといい方法を知りたい。 tl;dr - ディレクトリレイアウトをgolangの作法に合わせ、すべてのリモートリポジトリをghqを使ってcloneし、percolを使って簡単に検索できるようにしましょう。 追記: いまならpercolの代わりにpecoというツールを使うのもよいでしょう。というか、僕はそうしています。設定方法はこのエントリとほぼ同様の内容でいけると思います。 背景 そんな課題を抱えつつも、特になにかをするわけでもなく日々暮らしていた折、Rebuild: 42: When in Golang, Do as the Gophers Do (lestrrat)で@lestrratさんが、Goのお作法に、他の言語のリポジトリも含め、すべてあわせる
14. データベースにかける（soudai1025） | PHPの現場
@soudai1025 さんと、Silex 開発終了、ISUCON、PHP コミュニティでブーメランを投げ合うのはやめよう、データベースへのアクセス、設計、コミュニティ、色々な人と話す、東京移住、データベースマイグレーションツール、制約、責務を分ける、不吉な匂い、サロゲートキー、生存戦略、スキルの掛け算、反復横跳びなどについて話しました。 Show notes Larry Garfield on Twitter: “Big news! #Silex is dead, long live #Symfony Flex. #SymfonyCon https://t.co/TNTvIikHdz” azu on Twitter: “#phpgenba でこれについて聞きたい “PHP コミュニティでブーメランを投げ合うのはやめよう - Frasco” https://t.co/FFs4ZsZQAV”
DBリファクタリングの勘所と所感 - そーだいなるらくがき帳
表題についてそーだいなる見解を書き残します。 今年の夏に id:koemu さんにbuilderconの懇親会で下記のような話をいただいていました。 懇親会で、DB側ばかりでなくプログラム側でも適切なドメインモデルの設計ができていれば、リファクタリング時の影響範囲がさらに小さくできるのでは？という話をしたところ、この辺りはアンサーブログを書いてくれるかもしれないってことなので期待しています！！！ www.koemu.com 忘れてないんですよ！しっかり覚えています。 結論 仰る通りだと思うし、適切なドメインモデルはRDBに限らずデータストア層のリファクタリングの負担を大きく減らすと思います。 ここから先は僕なりの考え方を書きます。 実は似たような話を PHPの現場 っていうポッドキャストでも触れています。 php-genba.shin1x1.com システムの柔軟性 勿論、コードの綺麗さや
UXデザイナー深津貴之が語る身も蓋もない組織論!? 「ユーザー目線のない会社からは逃げるしかない」「それでもそこでがんばりたいなら……」 | HRナビ by リクルート
PCやスマートフォンを開けば、そこには不愉快なUIが至るところにあふれている。さして文章が長くもないのにページが4分割されているニュース記事（腹立たしいことに4ページ目はたった1行だったりする）、サッカーのハイライト動画でシュートの行方をカメラが追い始めた瞬間に始まる動画広告、場面転換をするたびにCMが挟み込まれ、もはやCMを見ているのかゲームをしているのかわからなくなるアドベンチャーゲームアプリなど……。 さらに不幸なことは、ウェブメディアの編集部や動画配信者、ゲーム制作会社の制作現場にいる人たちにとっても、これは決して愉快な状況ではないということだ。罵詈雑言混じりの苦情が書かれたユーザー評価欄やSNSを見ながら彼らは言うだろう。「誰が好き好んでこんなUIを作るものか」と。 関わる誰から見てもおかしなUIは、それでもなぜ量産され世の中のストレスを増幅させ続けているのだろうか？ その負のス
サクサク感をデザインする
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog ヤフオク!アプリ開発部の中島(@52shinNaka)です。今日はデザイナーの立場からサービスの体感速度をテーマに記事を書いていきます。 サクサク感の正体 サクサク動くサービスと聞いて、どんなサービスを思いつくでしょうか？サクサク動くを分解すると下の２要素に分かれると思います。 表示速度は、純粋にコンテンツが表示されるまでの時間、体感速度は、実際にプロダクトを触って感じられた時間の長さです。触っていて「サクサク動く！」と感じられるサービスは、上の２つの要素が満たされていることが多いです。 表示速度はサービス利益に直結する デザイナーが日々の作業の中で表示速度を意識するタイミングは少ないかもしれません。しかしグロースステージにある多
API デザイン : URL には名前と識別子のどちらを使うべきか | Google Cloud 公式ブログ
ウェブ API の設計に携わっている方であれば、API で使う URL のスタイルに統一的な考え方がないことも、選択した URL スタイルが API の使いやすさや寿命に大きな影響を与えることも、よくご存じでしょう。Google Cloud の Apigee チームは、社内だけでなくお客様とも協力しながら、API の設計について長く検討を行ってきました。本稿では、私たちが設計の現場で実際に使用している URL のデザイン パターンと、それを使う理由についてシェアしたいと思います。 著名なウェブ API をご覧になれば、いくつかの異なる URL パターンがあることに気づかれるはずです。次に示すのは、極端に異なる考え方に基づいた 2 つのスタイルの具体例です。 https://ebank.com/accounts/a49a9762-3790-4b4f-adbf-4577a35b1df7 htt
VO, DTO, POSO, DAO, Entity の違い - Qiita
はじめに try! Swift ではじめてDTO、POSOという言葉を聞いて、Entityとの違いとかよくわからなかったので調べてみた。 すると、類似の用語が5つでてきた。 VO (Value Object) DTO (Data Transfer Object) POSO (Plain Old Swift Object) JavaだとPOJO (Plain Old Java Object) DAO (Data Access Object) Entity いずれもシンプルに関連するデータをまとめたobjectだが、微妙に性質が異なる。 VO (Value Object) getterのみ 不変 DTO (Data Transfer Object) VO + setter 可変。外から変更可能 異なるレイヤー間（モデル層、ビュー層など）でデータを受け渡すのに使う POSO (Plain Old
お前らがModelと呼ぶアレをなんと呼ぶべきか。近辺の用語(EntityとかVOとかDTOとか)について整理しつつ考える - Qiita
お前らがModelと呼ぶアレをなんと呼ぶべきか。近辺の用語(EntityとかVOとかDTOとか)について整理しつつ考えるmodelDDD設計 みなさんは、Modelと言われたときに何をイメージしますか？ こんなアレを思い浮かべた方も多いかと思います。 マサカらせてください。やはりお前らのModelは間違っている。 アレをModelと呼ぶと何が不味いのか すみません、早速言い過ぎました。半分は正しいです。MVCの発明者、Trygve Reenskaug氏による1979年の説明によると、 Models represent knowledge. A model could be a single object (rather uninteresting), or it could be some structure of objects. 1 このように「Modelは単体のオブジェクトであっても
安定性のパターン大全 (とその実装) - Qiita
Cognitect社のNygardさんが10年ぶりに改訂したRelease It! 2nd Editionがまもなくリリースされます。内容は現在のベータ5版で全て書ききっておられるようなので、是非読んでみてください。 https://pragprog.com/book/mnee2/release-it-second-edition その中から4章の安定性パターンの概要をご紹介し、実際JavaのFailsafeライブラリを使った実装例を示したいと思います。 安定性のパターン Stability Patterns 分散システムや後続をブロッキングしてしまう重い処理は、システム全体がスローダウンしたり、無応答になってしまう危険にさらされています。クラウド時代になって、これらの安定性を保つための設計はより強調されるようになりましたが、わりと昔から様々な工夫がされてきたものでもあります。以下、Rel
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - UseMuffin/Webservice: Bringing the power of the CakePHP ORM to your favourite webservices
