作り直し - hitode909の日記
ソフトウェアを作ってて、作り直したり、書き直したりするべきかどうかという話をすることがある。 大きな規模だと、ソフトウェアを作り直す、というところから、小さな規模だと、込み入った機能を書き直す、くらいまであるけど、作り直すとうまくいくのは、次の二つのうちどちらかではないか。 最初に作ったときより世の中の技術が発展したとき 昔のコンピュータでは収まらなかったとか、昔は良いライブラリがなかったけど、今はある、というとき。 単に今ありふれた技術で作り直すと、よいものができそう。 最初に作ったときよりはコンピュータのスペックが上がったので、そのつもりで、並列度倍に上げても止まらないし、より速く動かせる、とか。 昔はバッチで計算しないといけなかったけど、今ならリアルタイムに返せる、とか。 昔は依存管理のよいライブラリがなかったけど、今ならこれ入れたら簡単、とか。 最初に作ったときより人間の技術が発展
アプリエンジニアから見てAPI設計において気をつけてもらえるとうれしいこと - Qiita
by @mixiappwchr アプリ向けのAPIの開発時に気をつけてもらえるとうれしい＆メンテナンスや実装コストが下がる点をつらつら書きます。 データ構造について データを返すとき、一定のルールを守って返す。例えば当然ですが同じデータ構造はもちろん、似たような構造もルールを作ってproperty名などそろえておく。relationやlistで返すときもどのデータ構造なのかがpropertyで明確にわかるようなっているようにする listを返す場合の形式やpagingが必要な場合の形式はそろえる。配列のデータがない場合も考慮しておく。例えば、データがない場合にNULLにするか or 空配列にする or property自体がないなどきめる pagingの場合とか複数のパターンが存在することを覚えておくと幅が広がる。単純なページング or twitterみたいなsince_idなど起点id以
「学び方のデザイン〜盲点を見つけよう」講義資料
「学び方のデザイン〜盲点を見つけよう」講義資料 このサイトではサイボウズ・ラボの西尾泰和と竹迫良範が 京都大学サマーデザインスクール 2014で行った 「学び方のデザイン〜盲点を見つけよう」の講義資料を公開しています。 わたしたちは、世界中のあらゆるチームを支援できる企業を目指しています。 みなさん、難しい問題を考えるときにはどのようにやっていますか？書き出してから考えることが大事です。目隠し将棋と普通の将棋はどちらが簡単か、暗算と筆算はどちらが簡単か、考えて見れば明らかです。頭のなかだけで考えようとすると、覚えておくために脳の一部が割かれてしまいます。 学ぶためには、まず「わからないこと」すなわち「盲点」に気づくことが必要です。 他人から教わるのではなく、自分で盲点に気づくために、わたしたちのチームではまず思いつくことをすべて付箋に書いて、それを他人と共有しました。 そして、その付箋を各
クラスの命名のアンチパターン - Qiita
昔から「名は体を表す」と言ひます。クラスの名前がクラスの果たす役割と一致してゐるかどうか常に考へ続けませう。 ImageInfo, AccountData, etc. Info って何やねん? Data って何やねん? ImageInfo って Image とはどう違ふねん?? FooInfo や FooData よりも好ましいかもしれない名前の例: FooAttribute, FooProperty, FooMetadata, FooDescription FooConfiguration, FooSetting, FooParameter FooResult, FooStatistics, FooSummary FooBuffer, FooList, FooCollection, ... ProductListItem, TranslationTableEntry, etc. Prod
「これだけ」モデリング - Qiita
これだけモデリングとは 「これだけモデリング」とは、メソドロジックの山岸さんが提唱されている「軽い」モデリング手法です（山岸さんはリーンモデリングとも呼んでいたがぼくはベタにこれだけモデリング、という日本語が好き）。 デベロッパーでなく情報システム部門目線で見て、どんどん複雑になる企業アプリケーションの要求や設計を見通しよく「共通合意」を作るための、「軽い」モデリングの必要性がテーマです。 そうなんです、従来は、「全部書かなきゃだめ」とか「全部メンテしないといけない」とか、「下流を触ったら上流までさかのぼって修正しなきゃ」とか足かせが多かったので、なかなか実装から遠いモデリングがペイしなかったのですね。だから、「これだけ」モデリングを提案したい、という訳です。 エンタープライズアジャイル時代のリーンモデリング（slideshare） これだけモデリングとは、 誰が？ ー 情報システム部門の
主キーはインデックスではない - 設計者の発言
仕事柄、奇妙なDB構造を目にすることが多い。どういう発想からそんな設計がされるのかを理解したいと思っていたのだが、モデラー仲間の秋里さんが先日うまい指摘をした。「主キーをインデックスみたいなものと勘違いしているからではないでしょうか」。インデックス（キー）というのは、レコードの並び順を規定するキーのことだ。 たしかに思い当たる節がある。「こんな順にレコードが並んでいれば処理上都合がよさそうだ」という考えで主キーが設定される。さらに主キーはユニーク制約でもあるので、重複が起こらないように「多め」に項目を突っ込んでおく。つまり「ユニーク制約をともなう代表的インデックス」程度に主キーが理解された結果として、グダグダなDB構造が出来上がるのではないか。 じっさい、昔こんなことがあった。{a,b,c,d}の複合主キーをもつテーブルＸがある。ところが、別のテーブルＹからテーブルＸの特定レコードにアクセ
アジャイルAPI設計時代の到来！？APIデザインの極意を読みました。 - シスアーキ in はてな
「プログラミング言語Java」「Effective Java」などの翻訳で有名な、柴田芳樹さんの新たな訳書である「APIデザインの極意」を読みました。 APIデザインの極意 Java/NetBeansアーキテクト探究ノート 作者: Jaroslav Tulach,柴田芳樹 出版社/メーカー: インプレスジャパン 発売日: 2014/05/23 メディア: 単行本（ソフトカバー） この商品を含むブログ (4件) を見る 「APIデザインの極意」は、NetBeansの生みの親で、初期のアーキテクトであるJaroslav Tulach（ヤロスラフ・ツゥラッハ）が著者で、NetBeansの開発で得た経験や教訓を纏めたノートが元になって書かれた書籍です。 従来のデザインパターンでは解決できない、後方互換性を維持しながらライブラリを発展させる設計手法について書かれています。 読んだ感想としては、GoF
APIデザインの極意 - ✘╹◡╹✘
APIデザインの極意 Java/NetBeansアーキテクト探究ノート 作者: Jaroslav Tulach,柴田芳樹出版社/メーカー: インプレスジャパン発売日: 2014/05/23メディア: 単行本（ソフトカバー）この商品を含むブログ (4件) を見る API設計は難しい "良い"APIを設計するのは難しく、APIの良し悪しを定量的に観測することは難しいとされている。後方互換性や拡張性、不具合の発生率などで曖昧に推し量ることはできるが、これは良い、これは悪い、とはっきり決め付けることは出来ない。そもそもAPIから「これ」と呼べるある側面を切り出すことも難しいと言える。また、APIの設計技法を学べる機会は多くないとしている。物事を感覚として認識することはできても、それを表現し他人に伝え信じてもらう方法を持たない場合が存在する。 API設計を芸術的取り組みにしてはいけない API設計の
シングルカラムから始める情報設計
横並びは複雑化の第一歩 Webサイトの設計をする際、必ずといっていいほど縦にコンテンツを並べて構成を考えるようにしています。どのような人が、何を求めて Web サイトに訪れているのかというシナリオを基に構成を考えていくわけです。詳細なレイアウトを考えるのではなく、情報の流れが適切であるかどうかを判断するための工程にしています。 パソコン向けの Web サイトデザインの悪い癖のひとつに、「同じくらい重要だったら、横に並べる」というのがあります。広いスペースがあったパソコンが主流の時代ならではのアプローチですが、今は状況が大きく異なります。配信者側にとっての『重要』を出すことは間違っていません。しかし、あれこれ重要だからという理由で隣り合わせにしてしまうと、様々なデメリットが生まれます。 訪問者に迷いが生じる 直接関係のないコンテンツが横に並ぶことで視点の動きが多くなる可能性があります。また、
iOS/Androidアプリエンジニアが理解すべき「Model」の振る舞い
iOS/Androidアプリを作る際に理解しておいて欲しい「Model」という役割について説明します。わりと意識していないケースがあるので、チェックしてみてください。Read less
ユーザー体験設計を軸にすすめるサービスデザイン
事業戦略と組織のビジョンデザイン〜デザイン的アプローチで事業・組織づくりにどう取り組んでいるかのリアル〜
web・スマートフォンアプリ設計に役立つ ワイヤーフレームUIキット「18 Free UI and Wireframe Kits」
TOP > Design > web・スマートフォンアプリ設計に役立つ ワイヤーフレームUIキット「18 Free UI and Wireframe Kits」 デザイン制作を行う際にはまず、全体の設計を行うためにワイヤーフレームを使って構成を考えることが多いと思いますが、本物のイメージにより近づけるため、また提案としてクライアントに提出するために、より現物に近いものをできれば作っておきたいもの。そんな時に役立つワイヤーフレームUIキット「18 Free UI and Wireframe Kits」を今回は紹介したいと思います。 webやスマートフォンアプリの設計をスムーズに進めることができそうな、制度の高いワイヤーフレームが揃っています。 詳しくは以下 Dribbble – A_better_look.jpg by Chris Bannister 定番のレイアウトのwebサイト制
Single Page Application ではない場合 JavaScript コードのエントリポイントはどこにあるべきか？ - @kyanny's blog
仕事で中規模程度の Rails アプリケーションのコードベースをいじっている。このアプリはもともと app/assets/javascripts 以下に必要に応じて JavaScript ファイルを置き、適当なテンプレートファイルから直接 JavaScript の関数を呼び出したりしていた。ごく普通の Rails アプリである。 このアプリは CMS で、いわゆる「ブログの管理画面」みたいな用途で使われている。一部の機能はそれなりに込み入った UI 操作を必要としページ遷移なしに操作できる必要があるが、旧来のやり方では JavaScript コードの管理が間に合わなくなってきたので部分的に Backbone.js を導入し始めている。 最近悩んでいるのが、 Backbone.js なコードのエントリポイントをどのように呼び出すべきなのか？ということ。そもそも自分が Backbone.js
ドメイン駆動設計読んだ - はこべにっき ♨
エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践) 作者: エリック・エヴァンス,今関剛,和智右桂,牧野祐子出版社/メーカー: 翔泳社発売日: 2011/04/09メディア: 大型本購入: 19人 クリック: 1,360回この商品を含むブログ (130件) を見る ドメイン駆動設計読み終った。ドメインを中心に据えてソフトウェアを設計するための方法を教えてくれる本だった。設計の話なので、抽象度が高く、なかなか読み辛いけど、良い話がたくさんでてくる。この本で例にでてくるソフトウェアが経理システムだとか貨物の配送システムなどのエンタープライズよりだったので、はじめは自分のようなWebエンジニアとっては参考にしにくいかと思っていたのだけど、まったくそういうことはなく、たいへん参考になった。 ドメイン駆動設計でいうドメインとはソフトウェアが
APIのバージョニングは限局分岐でやるのが良い - Hidden in Plain Sight
ちょっと前にTwitterでAPIのバージョニングをどうやるかみたいな話をしていたのですが、そのへんもやもやしているので少し整理しておきたいなと。 APIのURLを/api/v1/*とかってやるの、やめたほうがいいとおもうんだけどなぁ。いざv2を作るとなったときに、大量のコピペが発生して後悔するよ、って伝えたい。— Kenn Ejima (@kenn) February 28, 2014 さて、これについて色々と異論・反論も含めた意見が出たのですが、まずは、大昔にURL方式（＝コントローラ分割）でやってきて後悔したぼくが、（5年ぐらい前から）現在はどうやってAPIのバージョンを管理しているか？について紹介します。 基本原理としては、コピペが多発する根っこで分岐（＝コントローラ分割）じゃなくて、必要最小限のところで限局的に分岐するのがいい、という考え方に基づきます。 一言でいうと、「パラメー
「設定」を設計するための資料 - Hibariya
プログラムは、なるべく何もしなくても良い感じに動いてくれるのが理想的だけど、実際には何らかのかたちでユーザの設定を必要とすることがある。 Rails を使うときは config/application.rb でタイムゾーンを指定したり、DB へ接続するための情報を config/database.yml に指定する。 Bundler の挙動を変えたければ bundle config で設定を変更する。 Gem をインストールするときに毎回指定したいオプションがあれば、~/.gemrc に追記する。 もし自分の関わるプロダクトに「設定」のAPIが必要になったとき、何を判断の基準にして設計すればいいだろう。 ちょっと近所を見渡すだけでも、「設定」のやり方には色々ありそうだ。 設定という視点から、Rubyist にとって身近なプロダクトたちを資料として眺めてみた。 (NOTE: ちょっと悩みなが
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
エンジニアtype 技術者のキャリアを考えるWebマガジン - 転職＠type
InfoQ: Domain Driven Design（ドメイン駆動設計） Quickly 日本語版
モダンCSS設計の解説サイトまとめ - Qiita
社内システムの構造と設計、実装のはなし
