MOVEは望まれなかった子 - the sea of fertility
なにやらMOVEが話題です。 MVC is dead, it’s time to MOVE on. http://cirw.in/blog/time-to-move-on [翻訳]MVCは死んだ。MOVEするときがきた きしだのはてな http://d.hatena.ne.jp/nowokay/20120704 Twitterで「”MOVEは生まれた瞬間死んだ” って記事まだー？」って騒いでたら「お前が書けよ」の流れだったので息抜きに書きます。息抜きなので図が無いのは勘弁してください。 MOVEが生まれていない理由 この文中ではMOVEが生まれた理由はMVCの問題点に関わるとされており、そのMVCの問題点としてされているのは次の２点です。 MVCではControllerが肥大化する MVCは10年古い技術で設計されていて、最新のプログラミングパラダイムに対応していない。 しかしこの理由のう
MVCは死んだ。MOVEするときがきた - きしだのHatena
Conrad Irwinさんの「MVC is dead, it's time to MOVE on.」を訳してみました。 MVC is dead, it's time to MOVE on. この訳文も原文のライセンスを引き継いでCC-BY-3.0ライセンスで利用可能とします。 追記13:58 すでに訳してた方がいました。MVCの時代は終わった。MOVEを使い始めましょう。 - ふじこのプログラミング奮闘記 MVCは死んだ。MOVEするときがきた MVCはすばらしいアイデアだ。モデルを持ち、モデルは内部に少しの状態をもつ。ビューは内部に少しのUIをもつ。そして、コントローラは内部に少しの・・・ 何を持つ？ 私は確かにこのことに気づいた最初の人物ではない。しかし示されたようなMVCの問題のために、あなたは最後には過剰なコードをコントローラに詰め込むことになる。なぜなら、他にどこに入れていいか
MVC is dead, it's time to MOVE on.
MVC is a phenomenal idea. You have models, which are nice self-contained bits of state, views which are nice self-contained bits of UI, and controllers which are nice self-contained bits of … What? I’m certainly not the first person to notice this, but the problem with MVC as given is that you end up stuffing too much code into your controllers, because you don’t know where else to put it. To fix
名前のつけ方 - 2012-06-28 - ククログ
はじめに わかりやすいコードを書くことはソフトウェア開発において大切なことです。では、具体的にわかりやすいコードとはどんなものでしょうか？その観点はいろいろなものがあります。その中で今回は名前のつけ方に着目します。 コードに名前をつけるということ ソフトウェア開発において、名前をつける作業というのは絶えず発生します。メソッド名、変数名、クラス名、ファイル名などなど。名前をつける機会を挙げたらキリがありません。では、そもそもなぜ名前は必要なのでしょうか？ それはソフトウェアに限らず言えることですが、複数のモノを区別したいためです。例えば、まったく違う処理をする別々のメソッドに同じ名前をつけたらソフトウェアは正しく動きません。それを防ぐためにそれぞれのメソッドにちゃんと名前をつける必要があります。それぞれのモノにそれぞれ違う名前をつけて区別できなければソフトウェアはそもそも動きません。 名前を
世界で2番目にわかりやすいポインタの話
これ以上に解りやすく説明できるという人は、@super_rti までURLを教えて下さい。世界一わかりやすいの看板を差し上げます。
JSX の進化速度が半端ない - ぐるぐる～
気に入らない所を直して pull request 投げたら、取り入れられたので、8 日前に書いたエントリが過去のものとなっちゃいました。 関数型 以前の JSX では、関数型は function(: int): string のように書く必要がありました。 これはこれでそのまま使えるのですが、新たに (int) -> string という形式にも対応しました。 ちなみに、複数引数はカンマ区切りで (int, boolean) -> string のようになります。 カリー化された関数は、 function(: int): function(: number): string の代わりに (int) -> (number) -> string と書けます。 引数を囲むカッコは、(今のところ) 省略不可能です。 これには 2 つの理由があります。 この機能を追加したとき、JSX のパーサの能力
逆FizzBuzz問題 (Inverse FizzBuzz) - 平々毎々（アーカイブ）
just another scala quantを日本語にしました。 ちなみに、私の解はこちらに。 最初の解答 はてブに書いた解答方針、Inverse Fizzbuzz (FizzBuzzの逆関数) - Qiita - 与えられた範囲内のすべての解を数え上げてます。 もっと簡潔な解答 逆FizzBuzz問題 解きなおし - Qiita それでは、問題の日本語訳をどうぞ。 逆Fizzbuzz問題 2012年ではなく、2016年のお話。 世の中は大して変わっていない。 OOPと書き換え可能なオブジェクトによって何度もひどい目にあった後、世界はやっとのことでJohn Hughesの考察が正しかったことに気づき、関数型プログラミングに移行した。GoogleはTypesafe社を買収し、ScalaがAndroid上でネイティブに動作するようになっている。Googleに負けず劣らず、AppleはHas
GoFの23のデザインパターンを，Javaで活用するための一覧表 （パターンごとの要約コメント付き） - 主に言語とシステム開発に関して
GoFデザインパターンの一覧表と，活用のためのコメント，および入門者が独学するためのリンク集（サンプルコード付き）。 入門者の独学を支援するために，このページのURLを提示して熟読させ，各パターンを短時間で効率よく学んでもらう。 デザインパターンはプログラマの常識だ。 Java使いかどうかは問わない。 にも関わらず，入門書を買ったまま，途中で挫折する人が多い。 挫折の原因は，パターンの数が23もあって，多いからだろう。 全パターンをすんなり覚えてもらうためには，各パターンごとに 「要するにこういう目的のパターンなんだ。」 「10文字で表現すると，パターンの意味はこうなんだ。」 という要点・本質を，短いコメントで伝えれば助けになるだろう。 こういった学習を通して，Java言語の「設計思想」も併せて感じ取ってゆけるはず。 全パターンの一覧表（要約コメント付き） 全パターンについて，10文字以内
ifとreturnの使い方 - 2012-03-28 - ククログ
はじめに わかりやすいコードを書くことはソフトウェア開発において大切なことです。では、具体的にわかりやすいコードとはどんなものでしょうか？その観点はいろいろなものがあります。その中で今回はifとreturnの使い方に注目します。 ifとreturn プログラミング言語とは、コンピューターの作業の処理手順を書くためにあります。その処理手順は複数にわかれています。その複数の処理手順を順番に実行していくことでコンピューターは作業をこなしていきます。 プログラミング言語にはいろいろな処理手順を書くためにifとreturnと呼ばれる機能があります。ある処理手順をある時だけ実行したい場合には、ifを使います。その時以外はその処理手順は実行しません。また、続きの処理手順があるがその時点で実行を中断したい場合には、returnを使います。続きの処理手順は実行しません。ifとreturnを組み合わせることで
ObjectClub - ソフトウェア原則[5] - パッケージ分割
先日、ある人から次のような質問を受けた。 クラスが多くなったので、パッケージ分割をしたい。 パッケージ分割をする時の、指針を教えて欲しい。 話を聞いてみると、1つパッケージが大きくなってしまい管理が煩雑になって しまったため、今更ながら一旦整理をする決心がついたという。いわばパッケ ージ分割のリファクタリングを行おうというわけだ。 さて、ここで読者の皆さんに問題である。パッケージ分割の「観点」(指針) をできるだけ多く出してみてほしい。あなたなら、どんな観点で分割するだろ うか？可能なら数分時間を取って、自分の観点をできるだけたくさん書き出し てから次に読み進めて欲しい。 * * * 以下が、私が現時点で持っている観点である。1つ1つ説明しながら見ていく。 解説には、設計原則との関わりについて考察を加え、さらに、私が感じている ことを書いてみた。 (1) 名前 クラス
Island Life - 作りたいもの
About 南の島のプログラマ。 たまに役者。 Practical Schemeの主。 WiLiKi:Shiro 最近のエントリ 無限cxr高校受験Defense振り返ってみると2019年は色々学んで楽...覚えるより忘れる方が難しい(こともある)眼鏡のつると3DプリンタIris Klein Acting ClassSAG-AFTRA conservatory: Voice Acting創作活動って自分を晒け出さねばならないと...ループを使わずに1から100までMore... 最近のコメント shiro on 歳を取ると時間が速く過ぎるのは、新しいことに挑戦しないから? (2023/03/14)1357 on 歳を取ると時間が速く過ぎるのは、新しいことに挑戦しないから? (2023/03/01)ベアトリーチェ on ハイポハイポハイポのシューリンガン (2022/04/02)ベアトリーチ
テスト駆動開発について僕は誤解していた - 偏見プログラマの語り！
ここ数日 ruby をやってるんですけど、ruby といえばテストらしいので Test::Unit やら RSpec やらを調べてました。しかし僕はこれまでまともな TDD をやってこなかったので、先にテストとは何ぞや？TDD とは何ぞや？ってのを調べたりしていました。 この記事は、ずぶの TDD 素人がテストについて知り始めたまとめです。 1. きっかけは RSpec のドキュメント そもそも RSpec の↓紹介文の冒頭から意味不明に感じたんです。 FAQ:「RSpec って、要は Test::Unit でやっていることを別の書き方にしただけでは？」 この FAQ への短い答えはイエスです。 『スはスペックのス 【第 1 回】 RSpec の概要と、RSpec on Rails (モデル編)』 Rubyist Magazine えっ... じゃあ要らんやろソレ。いちいち手作業でチェック
プロとしての行為 Act as Proffesional
「ソフトウェアのプロになるには本書が必要だ！」と、ボブおじさんがおっしゃっております。 このボブおじさんは、あの有名なアジャイルマニフェストにも名前を連ねているRobert C. Martinです。 プロとしての最低限必要な知識、姿勢、規律など、教育を受けたり学んだことがあるプログラマはあなたの現場に何人ぐらいいるでしょうか？ 今こそ、本書を取って、プロとしての道を歩み始めて欲しい。（amazonでずっと売りきれだったけど、やっと入荷したようだ。すぐに売り切れそうではあるが…） プログラミングの練習 僕はプログラミングの練習というのを意識的にあまりやったことが無い。日本だとTDD Boot Campなどでおこなわれる小さなテーマでプログラミングをおこなうことである。本書の6章に練習について書いてる。 個人的にはRubyKaigiで、ペアプロした外人が、これはToys Programming
テストとデバッグ
The document discusses product architecture and its role in manufacturing firms. It defines product architecture as the scheme by which the function of a product is allocated to physical components. Product architecture impacts a firm's ability to achieve strategic goals like innovating new products, responding to market changes, and lowering production costs. The author argues that understanding
私が思う『良いコード』とは何かを語りたい - じゃがめブログ
久しぶりにシステムエンジニアっぽい話題。 良いコードというのはケース・バイ・ケースであり案件によって異なるものですので、あくまで『私が思う良いコード』についてです。 私がコードに対して持ってる座右の銘は、これです。 動く汚いコードより、動かない綺麗なコード 動く汚いコードはトラブルが発生して動かなくなったときに「なぜ動かないか」が解らず修正が困難ですが、動かない綺麗なコードは誰かが動くように直せば動き、修正が簡単です。故に、トラブルが発生したときのメンテナンス工数に差が出ます。トラブルは必ず発生するものですからね。動く汚いコードを綺麗にするには多大なるコストが掛かりますが、動かない綺麗なコードを動くようにするのはそれほど難しいことではないでしょう。一切トラブルも追加開発も発生しないと仮定するならば動く汚いコードでも問題ありませんが、果たしてそんなことがありうるでしょうか？ むしろ、トラブル
小野和俊のブログ:メンテナビリティの高いソースコードを目指して
ソフトウェアを中長期にわたってメンテナンスしていく場合、メンテナンスしやすいコードと、メンテナンスしにくいコードとの間には、同じ機能を実現していたとしても、その価値には雲泥の差があります。 メンテナンスの容易さを示す言葉として、メンテナビリティ(Maintainability)という言葉がありますが、私自身、アプレッソでDataSpiderを11年間開発・メンテナンスしていく中で、「この人の書いたコードは本当にわかりやすいし無駄がない」とメンテナビリティの高いソースコードに感心させられることもあれば、「急いでいたとはいえ、このソースコードはリファクタリングしないと・・・」と、メンテナビリティの低いコードがソフトウェアに混入してしまったことを嘆くこともありました。 このエントリでは、一本のソフトウェアを11年間開発・メンテナンスしてきた経験から、ソフトウェアのメンテナビリティについて考察して
「山浦恒央の“くみこみ”な話」関連の最新 ニュース・レビュー・解説 記事 まとめ - ITmedia Keywords
山浦恒央の“くみこみ”な話（181）： イチから全部作ってみよう（12）要求仕様書の異常系を階層構造を使って洗い出す ECサイトを題材にソフトウェア開発の全工程を学ぶ新シリーズ「イチから全部作ってみよう」がスタート。シリーズ第12回は、これまでに作成したたこ焼き屋模擬店の要求仕様書における異常系の洗い出しを行う。（2024/9/18） 山浦恒央の“くみこみ”な話（180）： イチから全部作ってみよう（11）たこ焼き屋模擬店の要求仕様書を抜け漏れなく作る ECサイトを題材にソフトウェア開発の全工程を学ぶ新シリーズ「イチから全部作ってみよう」がスタート。シリーズ第11回は、前回「機能分割」を用いて作成したたこ焼き屋の模擬店をの要求仕様書を抜け漏れのないようにブラッシュアップする。（2024/8/22） 山浦恒央の“くみこみ”な話（179）： イチから全部作ってみよう（10）トヨタとたこ焼き屋模
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
例外設計における大罪 - 契約
エンタープライズ分野での分散バージョン管理システム
ju11net九州体育(科技)有限公司