ちょっと前にTwitterでAPIのバージョニングをどうやるかみたいな話をしていたのですが、そのへんもやもやしているので少し整理しておきたいなと。 APIのURLを/api/v1/*とかってやるの、やめたほうがいいとおもうんだけどなぁ。いざv2を作るとなったときに、大量のコピペが発生して後悔するよ、って伝えたい。— Kenn Ejima (@kenn) February 28, 2014 さて、これについて色々と異論・反論も含めた意見が出たのですが、まずは、大昔にURL方式（＝コントローラ分割）でやってきて後悔したぼくが、（5年ぐらい前から）現在はどうやってAPIのバージョンを管理しているか？について紹介します。 基本原理としては、コピペが多発する根っこで分岐（＝コントローラ分割）じゃなくて、必要最小限のところで限局的に分岐するのがいい、という考え方に基づきます。 一言でいうと、「パラメー
重要な事 これは僕の経験に基づくものであり、世の一般的な皆々様にはあてはまるかどうかは存じ上げません。 僕がマイノリティかマジョリティかどうかはよくって、こういう状況もあるというだけです。ツッコミは大歓迎ですが「それはコーナーケース過ぎる」というご意見には「そうかもしれませんね。」としか答えようがありません。 あと、基本的に@otfに向けた記事なので、言葉足りていない部分が多いと思いますが、彼とは職場が一緒でいろいろ共有できるので気にしていません。皆さんには言葉足りていなくってすいません。という謝りはすれども、反省はしない程度の感じ。 追記>> 言いたい事書いてなかった。 ただし、 設計書否定するなら、ここにある事くらい論破するくらいの人じゃないと一緒に仕事したくない。逆に、ここに同意するくらいなら設計書否定すんなよ。自分の仕事を呪え。 と思ってる。 <<追記 ではちょいちょいカテゴリ分け
図を適当に補足 ViewWrapperは既存のすでにあるどうしようもない設計のViewを何とか救いたいときに非常に便利、Wraper / Decoratorパターンを適用してボタンのタップを奪い取ってViewHelperに流すみたいな役目をする ViewHelperは簡単に言うならUITableViewControllerのdelegate, datasourceだけを担うオブジェクトみたいな感じ。要するにView専用のドメインロジックを書くオブジェクト Viewの表示を制御するドメインロジックが途方もなく大きくてViewControllerに納めるのが不可能になってしまったときに超便利 Serviceは準ドメインロジックだと思っている、たいていの場合セミシングルトンみたいにする（通信が絡むので複数画面をまたいで使うことがほとんど） Androidの場合はここ、普通にServiceクラスで
その2はこちら 以前勉強会の際に発表した View Controller の作り方のメモをまとめてみました。あくまでメモなので中身はうまくまとまっていませんが、何かのご参考になればと思います。 通信が絡んでくると、たいていの人がやりがちな問題（実例） API通信のレスポンスを処理するコードがViewControllerの中に入っている API通信が3種類必要で、Aを実行したあとにBとCを実行しなければならないとか ABCのレスポンスJSONのパースまでViewControllerでやっている というかAPIの呼び出しの組み立てだとかURLの指定だとか自体がIBActionの中に入っていたりする API通信だけじゃなくてIn App Purchaseなどでも同様の事例が見られる それに対する対応策。そもそもなぜこのような問題が発生するのか？ Outletの生成・更新・レイアウトが分離されてい
広木 大地/ エンジニアリング組織論への招待 @hiroki_daichi O/R MapperとりわけActiveRecordによって、Model/Entityの区別がつかない人ってのが増えたうえに意味不明な思い込みでMVC批判してみたりとかMVACとか言い出してる状況に名前をつけたいな。 広木 大地/ エンジニアリング組織論への招待 @hiroki_daichi Entityとは、システム設計上のデータの一塊としての実体をさしていて、DBのRowとは本質的には無関係。ModelはMVCパターンにおいて、Controllerからeventをうけとり、Viewに修正を通知するインタフェースであり、実装としてビジネスロジック/ドメインを持ってる 広木 大地/ エンジニアリング組織論への招待 @hiroki_daichi 簡単のためにEntity = Row = Modelとして動的言語によっ
Nicholas C. Zakas is a web software engineer who specializes in user interface design and implementation for web applications using JavaScript, Dynamic HTML, CSS, XML, and XSLT. Yahoo!の技術者でありJavaScript関連の技術紹介に定評のあるNicholas C. Zakas氏がNCZOnlineにおいて、パブリックに公開されているWebサービスはバージョン管理されたAPIを提供すべきだといった内容の記事を公開した。依然として多くのWebサービスがバージョン管理されていない状況で提供されており、開発において不利益を被っているという内容になっている。 デスクトップやサーバの開発で利用されるライブラリはバージョ
katzchangのつぶやきで、オブジェクト指向開発を理解した開発者に、設計書は不要という両記事を知る。書かれていることは特に目新しくない。前から言われていることだし別にオブジェクト指向に限った話でもなかろう。→The Source Code Is The Design 2009年2月23日に書いた記事より再掲: 今更ながら「設計ができる」人に問いかける その「設計書」なるもので、本当にコード書けるの？ 「書ける『はず』」ってのは「書ける」のとは違うよ。 だが、はてぶに寄せられた意見にはなんだかな〜と思わせるものも目立つ。 これは一緒に仕事したくない人だ。UMLも書きたくないのかな →UMLからコード起こせるの？ Really? この記事は酷い。この著者は10年間で何をしてきたのか？偏った開発経験しかしていない気の毒な開発者。 →ただしい開発現場で経験を積んできたようにしか見えないが...
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
Javaではpublic, protected, default, privateという4種類の可視性がある。 Javaを始めてしばらくの間、この4つの使い分けがよくできていなかった。 「外から呼ぶならpublic、呼ばないならprivate」時代 当時から、なるべく可視性は下げた方が良い（オブジェクト指向は「隠す技術」である → 継承とコンポジット - 都元ダイスケ IT-PRESS参照）ということは理解していたので、「外から呼ぶならpublic、呼ばないならprivate」という指針からスタートした。 上記に加えて「継承先からしか呼ばないならprotected」時代 Template Methodパターンを覚えた頃の話。この時代が一番長かった。 そして残ったひとつ、default(package-private)の使い方が全く分からなかった時代でもある。色々使おうと頑張ってみたが、pa
最近なんとなく： クラスの保持するインスタンス変数をなるべく少なくする インスタンス変数を使わないメソッドをクラスに含めない ようにすれば適切にクラス分割できるんじゃないかと考えていました。 今日「凝集度と結合度：このコードのどこが悪いのか？ - ITmedia エンタープライズ」という記事を読み、基本的にこのような考え方で間違いなさそうだと自信が持てました。 LCOM（Lack of Cohesion in Methods） その記事では、いわゆる凝集度（の欠乏度）の測定手法として、LCOM（Lack of Cohesion in Methods）という計算式が紹介されています。インスタンス変数の数、メソッドの数、そして各インスタンス変数にアクセスするメソッドの数を用いて、計算結果が0に近いほど凝集度が高いクラスとみなす手法です。 記事に掲載されている凝集度の低いクラスの例はこういうもの
Latest topics > 他のアドオンと衝突しないように心がけたいし、心がけて欲しい 宣伝。日経LinuxにてLinuxの基礎？を紹介する漫画「シス管系女子」を連載させていただいています。 以下の特設サイトにて、単行本まんがでわかるLinux シス管系女子の試し読みが可能！ « ツリー型タブとVimperatorが衝突する Main 中学生男子のおっぱいへの情熱に溢れた青春映画「おっぱいバレー」 » 他のアドオンと衝突しないように心がけたいし、心がけて欲しい - Apr 17, 2009 「次のエントリで書く」なんて予告じみたことを書いてはみたものの、どうも話がまとまらない。もう、思ったことを箇条書きで書くだけにする。 現実的に言って、1つのアドオンであらゆる人のニーズを満たすことは不可能だと思うし、そういう方向での努力はしない方がいいとも思う。何でもかんでも……と際限なく詰め込んで
オープンソースでフリーなER図作成ツール「DBDesigner4」の日本語化を試みるサイトトップページ このサイトについて bookmark このサイトはfabForceで公開されているDBモデリングツール「DB Designer 4」の日本語化を試みるサイトです。 個人が運営するサイトなので公式なサイトではありません。 「DB Designer 4」はGPLライセンスで公開されているオープンソースソフトウェアです。 「DB Designer 4」についての詳細情報は本家サイトをご参照ください。 fabFORCE.net DBDesigner4の特徴 bookmark 直感的なGUIによるERモデル図のモデリング ERモデル図からSQL文（CREATEやDELETE）の自動生成 データベースからリバースエンジニアリングによるERモデル図の生成 データベースとERモデル図の同期化機能 軽快
TopHatenarとHatenarMapsのシステム構成が、バージョンアップの度に複雑化してきて、自分でも把握しづらくなってきたので、整理する意味で図を作ってみました。 図に示したように、HatenarMapsは、S2RMIを使ってTopHatenarと協調動作しています。はてなダイアリーとはてなブックマークに関するデータをクロールしているのは、TopHatenarの側です。HatenarMapsの側では、TopHatenarのService層をS2RMI経由でコールして、集計済みのはてブ情報を取得し、クラスタリング処理の後にポリゴンを計算しています。その他、HatenarMaps上でコメントビームの表示等がリクエストされる度に、TopHatenarをコールしています。よって、HatenarMaps側のDBには、基本的にポリゴンデータしか入っていません。 以下、図中に出てくるフレームワー
リッチインターネットアプリケーション（RIA）の開発では、ある技術がデータバインディングをサポートしているかどうかとそのやりやすさが、一つのポイントになる、と感じている。 俺がデータバインディングという概念を初めて意識するようになったのは、Flex 3 が最初。その後、Silverlight や WPF ではどうなのかをわんくま勉強会で聞いたり、Seasar Conference では Uruma や S2Swing でもちょこっとデータバインディングについて話していたのを聞いた。それらを聞いて今感じていることがある。データバインディング機能の優劣だけでは、ある RIA テクノロジーがこの先生きのこるかどうかを決定付けるほどの重要さは無い。ただし、データバインディングがやりやすいかどうかはリッチなアプリの開発がやりやすいかどうかにジワジワと利いてくる。このため、データバインディングは「地味
インタラクションデザインパターン（2） アプリケーションロールデザイン、 基礎の10パターン ソシオメディア 上野 学 2007/3/19 前回の「80年代のAppleに学ぶUIの部品化とガイドライン」では、インタラクションデザインの作業にパターンを活用することの有用性について説明しましたが、今回からは、実際にどのようなデザインパターンがあるのかを考えていきたいと思います。 私はこれまでの連載（ユーザビリティのヒント、Webアプリケーションのユーザーインターフェイス）を通して、インタラクションやユーザーインターフェイスのデザインはプログラムが出来上がってしまってから最後に付け加えるというものではなく、システムの基本的な品質を決定する重要な要素として設計の初期段階から考えなければならないものであると主張してきました。なぜなら、そのシステムが提供しようとしている機能を、画面の見た目や操作の流れ
ここはプログラミングの原則を集める Wiki です。巨人の肩に乗って、ふつうの人がよいプログラムを書くための指針を集めたいなと思ってます。 目次 よいデザインのための Concepts + Principles DRY (Don'tRepeatYourself) 名前重要 直交性 トラッシュではなくクラッシュ DuckTyping よいルーチンを書く 凝集性 結合性 契約による設計 (DesignByContract) ルーチンを作る正当な理由 よいモジュールを書く 適切なモジュール性を確保するために守らなければならない5つの原則 開放/閉鎖原則 (OpenClosedPrinciple) よいアプローチのための Concepts + Principles 曳光弾 可逆性
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Amazon.co.jp: インターフェイス指向設計 ―アジャイル手法によるオブジェクト指向設計の実践: Ken Pugh (著), 角谷信太郎(監訳) (翻訳), 児島修 (翻訳): 本
