Javaの進化にともなう運用性の向上はシステム設計にどういう変化をもたらすのか
SonicGarden Study #11で放送された資料から一部スライドを抜いたものになります。 http://sonicgarden.doorkeeper.jp/events/13229 ----- 優れたプログラマだけが優れたソースコードを書くことができます。 では優れたプログラマになるにはどうすれば良いでしょうか。 自分の書いたコードを、優れたプログラマに指摘してもらうことが一番の近道です。それがコードレビューです。たった一人でコードレビューも受けずに、ただ書き続けてもクソコードはクソコードのままなのです。 そこで今回は、良いコードが書けるプログラマになるための、コードレビューを上手に実践する秘訣を話します。
The Twelve-Factor App
Introduction In the modern era, software is commonly delivered as a service: called web apps, or software-as-a-service. The twelve-factor app is a methodology for building software-as-a-service apps that: Use declarative formats for setup automation, to minimize time and cost for new developers joining the project; Have a clean contract with the underlying operating system, offering maximum portab
設定ファイルが難しすぎるシステムを作ってしまうのも過剰な抽象化の一種
設定ファイルが下手に高機能すぎて、それに頼りすぎた結果、運用環境が非常に難解になってしまうことがある。そういう設定ファイル地獄のようなシステムができてしまう理由は、開発しているプログラマのレベルが低いからというのではなく（それもないわけではないと思うが）、いくつか他の構造的な理由があると思う。 柔軟性が無条件に良いものだと思っているから ―― コードを変更せずに設定ファイルでカスタマイズできるならそっちのほうがいい設計に決まってるよ、という思い込みのある人が多い。実際には、ベタに書けば簡単なものを設定に出すと複雑になることが多いから、これは事実ではないのだけど。 バイナリのアップデートが面倒だから ―― 運用ポリシーによっては、バイナリの更新はオオゴトだけど設定変更は通常作業みたいな環境がある。そういう環境では、設定にできるだけ多くのものを追い出してインストール後の柔軟性を最大化しようとい
The Future of API Design: The Orchestration Layer
Daniel Jacobson (Twitter | LinkedIn), is currently director of engineering for the Netflix API. Prior to Netflix, Daniel ran application development for NPR where, among other things, he created the NPR API. He is also the co-author of APIs: A Strategy Guide. The digital world is expanding at an amazing rate, giving us access to applications and content on myriad connected devices in your homes, o
小さいライブラリを採用する - mizchi's blog
僕がJavaScriptでライブラリを選定する際、迷ったら小さいものを使う。その理由について。 前提 前提として、枯れた環境で大きいフレームワークができるのは理解できるし、メリットも大きい。あるいは言語それ自身と区別できないぐらいに発達したフレームワークに依存するのも理解できる。RubyにとってのRailsとか、ErlangのOTPとか(いや、これは詳しくないけどそうなんだろうなっていう予想なんだけど)。 危険信号 今のJS界隈は動きが早すぎて、何に依存するのも危ない。とくにフレームワークと銘打たれたものは、でかすぎてどれも危険信号を放っている。 数年後、廃れてしまったフレームワークで開発し続けるのは、僕個人としてもあまり関わりたくないし、現場の離職リスクとして数字に出るだろうし、採用後の教育コストの問題になる。だいたいそういうものは元の設計者もいなくなるものだ。プロダクトの死を意味する。
DCIアーキテクチャについて語ってみるよ - uehaj's blog
Trygve Reenskaug氏とJames O. Coplien氏らが提唱する「DCIアーキテクチャ」について、id:digitalsoulさんが論文を翻訳してくださり、またその解説とサンプル実装(groovy, scala)を示してくださっており、読んでみたところ、大変興味深いので理解した限りを書いてみます。 おじさん登場 たとえば、あるおじさんがいたとします。 このおじさんは、白いスーツ、グラデーションの入ったサングラスと金ぴかのネックレスをつけて新宿歌舞伎町に出かけ「やくざ」として振るまいます。とおりかかったお兄さんがそのおじさんに出会い、目が合ってしまい、因縁を付けられ、お金を巻き上げられてしまいます。 さて、おじさんは家に帰ります。実は、このおじさんは家では良いお父さんとして振る舞います。赤ちゃんはこのおじさんの目を見て笑いかけます。おじさんは相好を崩し、オーよしよし。 さて
「設定」を設計するための資料 - Hibariya
プログラムは、なるべく何もしなくても良い感じに動いてくれるのが理想的だけど、実際には何らかのかたちでユーザの設定を必要とすることがある。 Rails を使うときは config/application.rb でタイムゾーンを指定したり、DB へ接続するための情報を config/database.yml に指定する。 Bundler の挙動を変えたければ bundle config で設定を変更する。 Gem をインストールするときに毎回指定したいオプションがあれば、~/.gemrc に追記する。 もし自分の関わるプロダクトに「設定」のAPIが必要になったとき、何を判断の基準にして設計すればいいだろう。 ちょっと近所を見渡すだけでも、「設定」のやり方には色々ありそうだ。 設定という視点から、Rubyist にとって身近なプロダクトたちを資料として眺めてみた。 (NOTE: ちょっと悩みなが
意外と知られていない構造化プログラミング、あるいは構造化プログラミングはデータも手続きと一緒に抽象化する、あるいはストロヴストルップのオブジェクト指向プログラミング史観
意外と知られていない構造化プログラミング、あるいは構造化プログラミングはデータも手続きと一緒に抽象化する、あるいはストロヴストルップのオブジェクト指向プログラミング史観 書いた人: ると 猫型プログラミング言語史観(1) 〜あるいはオブジェクト指向における設計指針のひとつ〜という記事がありました。手続き型からの発展としてのオブジェクト指向という史観を書いた記事です。しかし、そこで次のように述べられている史観は少々単純化しすぎです。 手続き型プログラミングでは手続きを抽象化することで保守性を挙げることに成功したが、データを守ることには失敗してしまった。そこでオブジェクト指向はデータと手続きをひとかたまりにすることでデータを外から守るというコンセプトを打ち出した。 手続き型プログラミングの時代は、少なくとも思想的にはそこまで暗黒的ではありませんでしたし、「データと手続きをひとかたまりにする」の
エンジニア必須の概念 – 契約による設計と信頼境界線
(Last Updated On: 2019年5月29日)少し設計よりの話を書くとそれに関連する話を書きたくなったので出力の話は後日書きます。 契約による設計（契約プログラミング）（Design by Contract – DbC）は優れた設計・プログラミング手法です。契約による設計と信頼境界線について解説します。 契約プログラミングとは 契約プログラミングは比較的新しい設計思想で、サポートしている言語にはEffile、D、Clojure、Valaなどがあります。最近作られた言語の多くが契約プログラミングをサポートする機能を持っています。C++、C#やJavaなどでも契約プログラミングをサポートするライブラリが利用できます。契約プログラミングをサポートする言語やライブラリを利用しない場合でも、契約プログラミングの概念を適用すると安全かつ効率が良い開発の手助けになります。 Wikipdiaの
アンチパターン「成長する主キー」 - 設計者の発言
我ながらしつこいが、またまたテーブルの主キーに関する話題である。「複合主キー」を毛嫌いする開発者がいるとすれば、その根拠はおおむね２つある。「ID等の単独主キーにしておけば、主キーの仕様変更に振り回されない」、および「複合主キーにすると実装が煩雑になる」だ。それぞれについて反論しよう。なおこれらの他に「ナチュラルキーを主キーにすると値が変わったときに困るから、複合主キーはダメ」と説明されることがあるが、こちらは非論理的なので取り上げない（詳しくは「ナチュラルキーを主キーにしてはいけない」を参照）。 ■成長する主キー まず「ID等の単独主キーにしておけば、主キーの仕様変更に振り回されない」についてだが、この主張は一面的には正しい。じっさい私自身、複合主キーの仕様変更に振り回された思い出がある。 新人の頃、ある重要なテーブルを処理するアプリをプログラミングしていた。仕様書にしたがって検索すると
フロントエンドJavaScriptにおける設計とテスト
今日話さないこと JavaScriptの基礎知識、jQueryの導入 気持ちいいUIやUXがうんちゃら CanvasやWebGLを使ったリッチでイケてるゲームの作り方
軽減税率がITに与えるインパクト - 急がば回れ、選ぶなら近道
http://www.nikkei.com/article/DGXDZO50933940U3A120C1MM8000/ どうやら本格的に複数税率が消費税に適用されるようです。まだ、決定でもないし、今後の業界の猛烈な反対もあるだろうから、どうなるか分からないのですが、その辺を部外者的に（かつ元関係者的に）記録として書いておきますよ。 この軽減税率で、もっとも変更のコストがかかる「仕組み」の一つはITであることは、多分論を待たないと思います。特に、税率を複数適応する羽目になる流通・サービス系のITは下手をするとかなりのコスト負担になるところも出てきます。またか！またコストですか！いや、これこそがITなのですよ。 まず影響が出てくるところ予想すると、事の大小はありますが、ほぼ大抵のところで手を入れる必要がある気がします。んで、例によって、多分この辺が正確に予想できている、CIOを除く経営陣は皆無
事前設計とTDD - 2012-12-16 - やっとむでぽん
実はモデリングが大好きです。元々はオブジェクト指向プログラミングを勉強しているところからUMLに(自然に)興味が向き、そこからオブジェクト指向設計とかオブジェクト指向分析とかそういう脇道にそれ(脇道とか言ったら怒られる!)、仕様も設計もこれからはオブジェクト指向だ!というありがちな若気の至りもありました。デザインパターンにも転んだし、責務!ロール!コラボレーション!ってのもやったし、重厚長大なフレームワークとかもなかなか楽しいですよねえ。ねえ? 今でも概念モデルとか大好物で、上の話を聞きながらうっかりとこんなオブジェクトモデリングをしてしまったりします。 そんなわけで、プログラミングする対象の仕様を理解しながら頭の中でモデリングして設計を進めてしまうのはやむを得ません。多かれ少なかれ、なにかしらの設計が浮かんできてしまいます。 でもTDDはテストを書きながら設計をします。先行して設計してし
アマゾンCTOが語った、「クラウドネイティブ」なアプリのつくりかた
米アマゾンCTOのヴァーナー・ヴォーゲルズ（Werner Vogels）氏は11月29日、米Amazon Web Services（AWS）のイベント「re:Invent」2日目の基調講演で、21世紀的なアプリケーション開発のあり方について刺激的な議論を展開した。 クラウドコンピューティング（ヴォーゲルズ氏にとってはAWSを意味する）では、ITリソースに関する制約が取り払われるとともに、これらのリソースすべてがプログラマブルになる。このため、あらゆる局面でITリソースを意識しなければならなかった従来のアプリケーション設計手法は本質的に変化し、開発者は、ビジネスに対して価値を与えることに集中できるようになる、とヴォーゲルズ氏は語った。これは、前日のAWS総責任者アンディ・ジャシー（Andy Jassy）氏による基調講演の影のテーマともシンクロする。 「AWSのすべての機能やツールには、存在し
生産管理・原価管理システムのためのデータモデリング - YNishim BLog
ある意味で私の専門分野でもあるので，より詳しく感想を書いていく．いろいろ疑問も書いているが，このような本はいままで全く書かれていなかったという点だけでも，生産管理に携わる人は絶対に読むべき本である，ということは間違いない． DFDなど設計手法については別の本が詳しいので，そのときに書くことにする． 大胆な用語の使い方 アカデミックな人では絶対に真似ができないと思ったのが，用語をより直感的に翻案し，新たに作られている点である．著者が単に従来の方法を真似するのではなく自分の頭で考えて発想しているから，このようなことができるのだろう．具体例をいくつかあげる． 一次識別子と二次識別子 識別子とはいわゆる「キー」*1を指し，一次識別子とは識別子の中から代表的なもの一つ，二次識別子とはそれ以外の識別子を指す．一見すると主キー(primary key)と主キー以外の候補キー(candidate key)
内海 英一郎のブログ: REST の複雑性？
Web 上に展開されたサービスのいくつかは、ユーザーとのインタラクションを行う HTML ドキュメント ページ以外に、開発者向けに API を提供しています。これらは、直感的な URI と HTTP ベースのシンプルな方法でアクセスすることができ、RESTful Web サービス API と呼ばれています。僕も REST ファンの一人で、RESTafarians とまではいきませんが、WWW の生態系を支えるシンプルなスタイルをとても気に入っています。 REST (Representational State Transfer) アーキテクチャー スタイルについての概要は、Roy Fielding 氏による論文 http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm または、山本陽平さんのブログ http
RESTful Web アプリの設計レビューの話
1. RESTful Web アプリの 設計レビューの話 和田 卓人 (a.k.a id:t-wada or @t_wada) July 23, 2012 @ sendagaya.rb 3. 自己紹介 名前: 和田 卓人 (わだ たくと) ブログ: http://d.hatena.ne.jp/t-wada メール: takuto.wada@gmail.com Twitter: http://twitter.com/t_wada タワーズ･クエスト株式会社 取締役社長 4. 私と REST (input) • WEB+DB PRESS vol.32「REST アーキテクチャスタイル入門」 • はてぶ設計議論 • DHH の RubyKaigi 2006 Keynote • WEB+DB PRESS vol.38∼「REST レシピ」 • 『RESTful Web Service』
[プログラミング]よいコードを書くために - logiqboard
コードをたくさん読んでいると、よくできていて参考にしたくなるコードや、身の毛もよだつクソコードなど、色んなコードに出会う。 自分一人で書いていた頃は、コードの良し悪しは全て自分にはね返ってきていたのだが、チームを組むとそうはいかない。 人の書いたコードで苦しむこともあれば、自分の書いたコードで人を苦しめることもある。 そんなことにならないよう、少しでも良いコードを書くために意識するべきことをまとめてみた。 読むのに苦労しないコードを書く 書かれたコードは、それが使われ続ける限り、何度も読まれる。 読む人は自分かもしれないし、他のチームメンバーかもしれない。別の会社の顔も知らない人かもしれない。 そんな人たちでもスラスラ読み解け、理解できるコードは、きっと良いコードだ。 冗長さを制御する 大体の悪いコードは長い。どんなに素晴らしい設計がされていても、長いと読む気力が失せる。コードは短いに越し
![[プログラミング]よいコードを書くために - logiqboard](https://cdn-ak-scissors.b.st-hatena.com/image/square/824a64f5ea8b1fa29b6b1ff45aabef6b5568bc85/height=288;version=1;width=512/https%3A%2F%2Fogimage.blog.st-hatena.com%2F17680117127144886642%2F17680117127144886906%2F1558210211)
ダウンロードした画像をキャッシュするクラスの設計と実装について - 24/7 twenty-four seven
iOS組み込みのキャッシュモジュールNSCacheについて発表しました - ninjinkun's diary @k_katsumi キャッシュを分ける方のはわかりやすくて良いですね。後から読む人の参考になりそうなので、URL と URL の発言、ブログに引用させていただいても良いでしょうか。 2012-03-26 16:42:44 via web to @k_katsumi @ninjinkun はい。ぜひぜひー。せっかくなので便乗して僕がいつも使ってる画像キャッシュのコードを共有したりしてみます。 2012-03-26 16:45:05 via YoruFukurou to @ninjinkun @k_katsumi お、それは楽しみです！この手のものはみんな独自に作ってる感じだと思うので、参考にさせていただきたいですー。 2012-03-26 16:48:23 via web to
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ぼくのかんがえたさいきょうのうぇぶあぷりけーしょんふれーむわーく - YAPC Asia 2011
