人生は練習と思ってる所が本番で、本番と思ってる所はオマケだ。 http://d.hatena.ne.jp/teruyastar/20131207/1386476138 年末の記事に反響があったのですが、 「ずっと本番って、その努力ほんとに報われるのか？」 という意見をもらいました。 あと関連で、 ｢基礎が大事｣という本当の意味を理解しているか? http://d.hatena.ne.jp/teruyastar/20110208/1297157480 「基礎を無意識のゼロに限りなく近づけるのが守破離の守、 といっても、いつになったら破・離へ移行するの？」 みたいな意見も。 なるほど、、基礎や準備こそ大事ではあるのですが、 これは確かにやみくもな努力へのミスリードに見えるかもしれません。 そうならないよう「正しい努力の仕方」を示す記事 をまとめてみました。 前提・7つの習慣における「第2領域」
メルカリでCDNにキャッシュされるべきでないページがキャッシュされることにより個人情報の流出が発生してしまうインシデントがありました 自分は動的コンテンツをCDNで配信することにあまり積極的ではない立場だったのですが流出への反応を見るとCDNを利用しているサービスはかなり増えてきているようです 個人情報やユーザーのプライベートデータを決して流出しないようにしつつCDNを利用する方法を考えてみました CDN利用のメリット このふたつ 経路が最適化されレイテンシが小さくなる DDoS対策となる キャッシュされないようにする方法 Twitterで動的コンテンツもCDN通すの当たり前でしょーと言ってる人にリプしてきいてみました CDNとレスポンスヘッダで二重にキャッシュを無効化する キャッシュを細かくコントロールCDNを使う ホワイトリスト方式で特定のパスのみキャッシュを許可 ログインセッションを
この記事の内容 オブジェクト指向は難しい！わかった気になって実践すると詰みます... ｳｷﾞｬｰ この記事は10年以上オブジェクト指向と戦った筆者が、通常とは異なるアプローチでオブジェクト指向を解説したものです。 筆者はJavaを使って本格的なシステム開発をしたことがありませんが、オブジェクト指向言語として最もポピュラーなJavaをベースにオブジェクト指向について解説させていただきました。 また、この記事の続編にあたります「なぜオブジェクト指向は難しいのか」を更に2年の時を経て執筆させて頂きました！是非こちらも一読していただけると嬉しいです。 オブジェクト指向三大要素の謎 オブジェクト指向三大要素ってありますよね。オブジェクト指向は「カプセル化」「継承」「ポリモーフィズム」の3つの要素で成り立つと言われています。最近では、この三大要素が語られる傾向は薄いようですが、一度は耳にしたことがある
DevLOVE X Day1 C-5のセッションです。 ITの活用範囲の広がりとともに、費用・品質よりもデリバリを優先するプロジェクトも増えてきました。しかし「しっかり考えるよりも、作ってリリースしちゃおうぜ、正解なんて誰にも分からないんだから」というマントラを唱えながら、返済見込みの立たない大量の技術的負債を抱える。それが最善の選択なのか、もう少しだけ立ち止まって考えてみませんか? YAGNIという言葉を便利に使いすぎてはいませんか? コードを書きなぐるのと、ちょっと考えて設計して作るのとで、そんなに開発スピードに違いがありますか? 考えてみたいと思います。 Read less
「よい」とされているプログラミング手法のひとつに差分プログラミングがある。クラスを継承して親クラスとの差分だけのコードを書けば、親ですでに実装されている機能はそのまま使えて、かつカスタマイズもできるというやつだ。 たとえばGUIのボタンをカスタマイズしてマウスオーバーするとなにかちょっと特殊なことを行うボタンを作りたいとしたら、ボタンクラスを継承して、マウスオーバーのイベントハンドラをちょいちょいとカスタマイズしてやればよい。差分プログラミングは大変素直でよいプログラミング手法のような感じがする。 よいのはよいと思う。 しかしこういういい例だけをみてそれをどこでも真似しようと思ってしまうと、不必要な抽象化を積み重ねる困ったプログラマになってしまう（そういう人は結構たくさんいる）。自分でプログラムを書く場合には、よくできたクラスライブラリやフレームワークをお手本にして抽象化を行うのは、ほとん
プログラミング地獄への道は“ベストプラクティス”で敷き詰められている：Rails Hub情報局：エンジニアライフ
Ruby on RailsのメジャーバージョンアップとなるRails4のリリースが近づいて来ました。先日、日本人（あるいはアジア人）として初めてRailsコアチームのコミッタとして迎え入れられた松田明氏によると、Railsの生みの親であるDavid Heinemeier Hansson氏（以下、通称のDHHを使います）は、プロジェクトをリードするという意味で活動が活発になっているそうです。 そして最近のDHHは、ブログもよく書いています。彼は歯に衣着せぬ発言でも知られています。強い主張を持った（opinionated）なフレームワークの作者らしく、DHH自身もきわめてハッキリと物を言います。攻撃的とまでは言いませんが、IT業界や技術動向などでは割と何かをクソミソにけなしたりということをします。 DHHが何かをけなすときは、だいたい何らかの鋭い洞察とパンチの効いた皮肉が含まれていて、Twit
「CoffeeScriptの関数は明示的にreturnしてはいけない理由」を探す暇あったら他にやるべきことあるのでは？ - mizchi's blog
CoffeeScriptの関数は明示的にreturnするべき | CreativeStyle 本当に遅いのか、それを確かめましょう。 適当にでっちあげたコードです f1 = -> for i in [1, 2, 3] for j in [4, 5, 6] i + j f2 = -> for i in [1, 2, 3] for j in [4, 5, 6] i + j return console.time "f1" for i in [1..100000] then f1() console.timeEnd "f1" console.time "f2" for i in [1..100000] then f2() console.timeEnd "f2" 実行してみます $ coffee hoge.coffee f1: 105ms f2: 4ms 約26倍違う、ということがわかります。
YAGNI - Wikipedia
英: You ain't gonna need it[1]、縮めて YAGNI とは、機能は実際に必要となるまでは追加しないのがよいとする、エクストリーム・プログラミングにおける原則である。 YAGNI原則を提唱する人々は、その理由として以下を挙げている。 後で使うだろうという予測の元に作ったものは、実際には10%程度しか使われない。したがって、それに費やした時間の90%は無駄になる[2]。 余計な機能があると、仕事が遅くなり、リソースを浪費する[2]。 予期しない変更に対しては、設計を単純にすることが備えとなる。そして、必要以上の機能を追加すると、設計が複雑になってしまう[2]。 人生の時間は、貴重である。したがって、人間の能力は、ただコードを書くためではなく、現実の問題に集中するために使うべきである[3]。 結局は、その機能は必要ないかもしれない。もしそうなったら、あなたがその機能を実
適切に抽象化されたコードを書く、というのはまさに言うは易し行うは難しだ。 最近私が心がけていることのうちのひとつに、「未来を予測しない」というのがあって、「ここはあとから変更とか追加があるかもしれない」と思って抽象化しておくみたいなことはやめようと思ってる。ひとことで言うと、よくYAGNIとか言われるアレです。 そもそも、なんのために抽象化するのかというということを考えると、ひとつは「一塊の手続きに名前を付けて隠蔽して外から中を意識しないで済むようにする」ってことと、その副産物として「交換可能性が高まる」っていうのがある。 抽象化して実装を隠蔽することで、 コードが理解しやすくなる インターフェイスさえ合ってれば交換可能な部品として扱えるようになる という利点があるから、わたしたちは抽象化を行うわけだ(だからこそ「名前重要」なわけですね)。 この後者の利点に注目すると、ついつい「あっあとか
「軸がぶれないことが重要」っていう人は、結構多いと思うんだけど、危険なことかもね。最初に決めたことがあっているならそれでいいけど、あってるとは限らないからね。 「だからこそ最初に良く考えるんだろう」っていいそうだけど、どんなに良く考えたって、間違いはある。人間は、未来のことはわからないんだから。 私は、XPのYAGNI(You Aren't Going to Need It)の考え方が好きです。「今必要のあることだけをやれ」っていう考えが。 「人は未来のことはわからないんだから、できる限りの予想をして未来に備えよう」ってのと真逆な考えで、「人は未来のことはわからないんだから、予想するのはやめちゃって、今必要最小限のことだけをしよう」ってことです。 そして、「現実にあわせて素早く舵を切る」のです。 私は、XPにふれて以来、ずっとこの考えに従っています。 先のことは予想しない。 現実にあわせて
Joel on Softwareに面白そうな記事が載っていた。 とはいえ、どうも僕の英語力では完全な読解が難しい。会話を書き起こしたものなので当然ながら文体が会話調で、僕にはなかなか理解が難しいのだ。以下で僕の読み間違いがあれば指摘して欲しい。 さて、冒頭で Joel 氏はこう言っている。 Joel: There's a debate over Test Driven Development... should you have unit tests for everything, that kind of stuff... a lot of people write to me, after reading The Joel Test, to say, "You should have a 13th thing on here: Unit Testing, 100% unit tests
プログラミング一般 DRY原則 YAGNI KISS原則 OAOO UNIX思想 可逆性 曳光弾 直交性 契約による設計 DbC プログラマの三大美徳 PIEの原則 SLAP パフォーマンスチューニングの格言 驚き最小の原則 ボーイスカウトの規則 One Fact in One Place DTSTTCPW 割れた窓の法則 名前可逆性 オブジェクト指向プログラミング デメテルの法則 パルナスの規則 求めるな、命じよ コマンドとクエリ分離原則 オペランドの原則 用語 抽象データ型 サブタイプ ダックタイピン
プログラミング原則一覧 - Strategic Choice (via jun26)
こんにちは！Xイノベーション本部プロダクトイノベーションセンターの米久保 剛です。 弊社のテックブログ上では今回が初めての記事執筆となります。アーキテクチャ設計やアプリケーション設計の話を中心に、不定期に情報発信していきたいと考えています。 YAGNI原則 YAGNI原則をご存知でしょうか。 エクストリーム・プログラミング（XP）の重要な原則の一つであるこの原則は、You Ain't Gonna Need Itのアクロニム（頭字語）から命名されています。日本語にすると「どうせ要らないって」というニュアンスでしょうか。推測に基づいて余計な機能を作り込んだところで将来実際に使われる可能性は低く、時間と労力を無駄にするばかりかコードの複雑化などのリスクさえあります。ですから、現時点でわかっている要件をちょうど満たすだけの機能を実装すべきであるとYAGNI原則は主張します。 YAGNI原則は機能（
ある Mac プログラマから "WebKit ってドキュメントがすくないよね" という話を聞いた. WebKit の挙動が気に入らないので直せないかと調べたところ, Mozilla と比較した文書の少なさに呆れたという. 私としては連載枠が貰えたのもひとえに文書がないおかげだから, そこに不満はない. (むしろめでたい.) けれどコードを直したい人が不便なのは困ったことだ. WebKit に比べ, Mozilla の内部は網羅的ではないにしろそれなりに文書化されている. この違いはどこから来るのだろう. 私の印象は, Mozilla が "書き直し" プロジェクトだからというものだった. Netscape は Netscape Natigator 4.x のコードベースを捨て, ほぼスクラッチから Gecko を書いたとされている. 私の仄暗い経験によれば, 書き直しのプロジェクトは最初に
634 - ソフトウェア開発の原則・法則
概要 原著者の許諾を得て翻訳・公開いたします。 英語記事: Practicing YAGNI 原文公開日: 2018/01/17 著者: Jason McCreary 画像は英語記事からの引用です。 しばらく前に私はLaraconでYAGNIの実践についてスピーチしました。このような大きなカンファレンスで大勢の観衆を前にプレゼンしたのは名誉なことでした。以来、私のスピーチに多くの反応や関心が寄せられています。 私のスライドを共有したいという申し出を多くの方からいただきましたが、ほとんどの議論がスライドに対して行われたので、ブログ記事にまとめる方がよいと思えました。スライドをご覧になりたい方は、StreamAConで私のスピーチを視聴できます。 私は自分自身を「探求者」だと思っています。プログラミングの秘訣における聖杯、それさえ手に入れれば即座にスキルアップできるたったひとつの聖杯の探求です
エンジニアtypeは、各種エンジニアをはじめ「創る人たち」のキャリア形成に役立つ情報を発信する『＠type』のコンテンツです。
「プロのための Linux システム・ネットワーク管理技術」 の出版が決まりました。５月下旬に発売の予定です。（前書 「プロのための Linux システム構築・運用技術」 のネットワーク編にあたります。2 冊セットで読んでいただけると幸いです。） 各章の概要は次のとおりです。 第1章 セキュリティ管理の基礎 セキュリティ管理の目的や考え方など，Linux システムにおける適切なネットワーク管理の前提となる，企業システムのセキュリティ管理の基礎を説明します。Linux サーバの基本的なセキュリティ設定やネットワーク・セキュリティに関するカーネル・パラメータ，そしてこれらに関連するネットワーク経由によるシステム攻撃手法についても解説します。 第2章 iptables によるアクセス管理 iptables の基本的な使い方であるパケット・フィルタリングとNAT（DNAT/SNAT/MASQUER
プログラミングにおける過度な抽象化についての、若干のメモ - Line 1: Error: Invalid Blog('by Esehara' )
はじめに 少し思うところがあって、『コード・シンプリシティ』を読みかえしている。 というのも、この本には「一般的すぎるコードを書く」という項目があって、そのことがここ最近引っかかっているからだ。なぜ引っかかるのかというと、それはたびたび「抽象化」というか「共通化」という部分に対するアプローチにおいて、どこかモヤモヤすることがあって、それが何処から来るものなのかな、というのをちゃんと自分の中で言語化しておきたかったからだ。 継承 クラスベースのオブジェクト志向の場合、「継承」という概念がある。とりあえず、Web上に散らかっている適当な解説には、次のように書いてある。とりあえず、疑似コード的なものをPythonで書いてみよう。 class Animal(object): pass class Human(Animal): pass class House(Animal): pass 通常、この
Spring BootによるAPIバックエンド構築実践ガイド 第2版 何千人もの開発者が、InfoQのミニブック「Practical Guide to Building an API Back End with Spring Boot」から、Spring Bootを使ったREST API構築の基礎を学んだ。この本では、出版時に新しくリリースされたバージョンである Spring Boot 2 を使用している。しかし、Spring Boot3が最近リリースされ、重要な変...
「悪い方が良い」原則をご存じだろうか？ 私はニュージャージー式「悪い方が良い」原則の信奉者だ。以前参加したあるスマホゲームの開発プロジェクトでその意を改めて強くした。今回はその話をしたい。
New community features for Google Chat and an update on Currents
Join the official community for Google Workspace administrators In the Google Cloud Community, connect with Googlers and other Google Workspace admins like yourself. Participate in product discussions, check out the Community Articles, and learn tips and tricks that will make your work and life easier. Be the first to know what's happening with Google Workspace. ______________ Learn about more Goo
"You aren't gonna need it"[1][2] (YAGNI)[3] is a principle which arose from extreme programming (XP) that states a programmer should not add functionality until deemed necessary.[4] Other forms of the phrase include "You aren't going to need it" (YAGTNI) [5][6] and "You ain't gonna need it".[7] Ron Jeffries, a co-founder of XP, explained the philosophy: "Always implement things when you actually n
プログラミング一般 DRY原則 YAGNI KISS原則 OAOO UNIX思想 可逆性 曳光弾 直交性 契約による設計 DbC プログラマの三大美徳 PIEの原則 SLAP パフォーマンスチューニングの格言 驚き最小の原則 ボーイスカウトの規則 One Fact in One Place DTSTTCPW 割れた窓の法則 名前可逆性 オブジェクト指向プログラミング デメテルの法則 パルナスの規則 求めるな、命じよ コマンドとクエリ分離原則 オペランドの原則 用語 抽象データ型 サブタイプ ダックタイピン
プログラミング原則一覧 - Strategic Choice (via jun26)
オーバーエンジニアリング - Kazzzの日記
Railsを使って既存のJavaアプリケーションを書き直しているのだが、当時自分たちでで書いたプログラムに対して標題の言葉が浮かんでしまう。 当時、既にEJB(EJB1.1)に見切りをつけて独自のDAO(今のように立派なものではなくハッシュに属性を格納しただけのシンプルなもの)を使い、フロントコントローラー+MVC、ビューはJSP(除くスクリプトレット)とかなりシンプルにしたつもりだが、今見るとどうしても冗長で七面倒くさく感じる。 結局、当時は生産性が大事と言いながら、実は生産性のことなんてこれっぽっちも考えていなかったんだだろうか。いや、そんなことは絶対に無い。 同じようなケースを経験されている方はたくさんいるだろうと思うが、 「ひょっとしたらここは〜と変更されるかもしれないので結合を緩くしておこう」 「ここは〜のように修正されてもコンパイルの必要が無いように括りだしておこう」 「データ
その１ YAGNI（ヤグニ）の原則でいこう
＜戻る STGつくろー！ その１ 「YAGNI（ヤグニ）の原則でいこう！」 ① YAGNIとは？ STGを作るなどという大それた目標を掲げてしまいました。 掲げたからには、本腰と気合を入れて取り組まなければ！と思う反面、いったい何からてをつければいいのか皆目見当もつかないありさま･･･ 「どうして見当がつかないんだろう･･･」 目の前に広がるプログラムの渦。流される私、そして滝が･･･ 「滝･･･そうか！」 半ば強引に、理由がわかりました。そう、私はSTGを作ろうと気張るあまり「ウォーターフォール型」の設計を思い浮かべていたのです。 ウォーターフォール型の設計とは、分析・設計・実装・テスト・運用と滝が落ちるかのように製作工程を進めていく古典的なソフトウェア開発手法です。最初の「分析フェーズ」で実現したいソフトウェアに関するすべての事柄を将来の追加予定を含めて洗い出し、「設計フェーズ」でそれ
YouArentGonnaNeedIt (often abbreviated YAGNI, or YagNi on this wiki) is an ExtremeProgramming practice which states: "Always implement things when you actually need them, never when you just foresee that you need them." Even if you're totally, totally, totally sure that you'll need a feature later on, don't implement it now. Usually, it'll turn out either a) you don't need it after all, or b) what
STGつくろー！
STGつくろー！ ついに始まってしまった無謀な企画！ これまで貯めてきた知識を元に、大胆にもSTGを作ってしまいます。 ここでは、その製作過程を書き尽くします。 行く先未知数、失敗の可能性限りなく大！ さあ、どうなるか？ (2005. 8. 28)
最近は一人で小規模なバッチ処理を製造している。あまり周りを気にしないで黙々と作ることができるせいか、ドキュメントが無いせいかソースコードにコメントを書くことが少なくなった。 今まで自分の経験から詳細なドキュメントがある場合はソースコードにこんなものを見たことがある // 1.ユーザ情報を取得する UserInfo info = getUserInfo(); // 2.取得したユーザ情報から最新のメッセージ１０件を取得する String[] result = getLatestMessages(info, 10); // 2-1.もし取得できなかった場合はメニュー画面に遷移する String strJsp = null; if (result.length == 0) { strJsp = "menu.jsp"; } // 2-2.取得できた場合はメッセージ一覧画面に遷移する else {
YAGNI exceptions
I'm essentially a believer in You Aren't Gonna Need It – the principle that you should add features to your software – including generality and abstraction – when it becomes clear that you need them, and not before. However, there are some things which really are easier to do earlier than later, and where natural tendencies or a ruthless application of YAGNI might neglect them. This is my collecti
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
もらえる経験値を最大化する「正しい努力」のまとめ - teruyastarはかく語りき
CDNに動的コンテンツを安全に通すにはどうするべきか - 方向
オブジェクト指向と10年戦ってわかったこと - Qiita
それはYAGNIか? それとも思考停止か?
すべてのソースコードが手元にあるのに不要な抽象化を行うのはよくない
適切に抽象化されたコードとはなにかって話 - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
軸がぶれないって危険なことかもね - ひがやすを blog
TDDはYAGNIに矛盾する？ - カタチづくり
YAGNIと拡張性のあいだ - 電通総研 テックブログ
明日の空模様 - Backnumbers: Steps to Phantasien
YAGNIを実践する（翻訳）｜TechRacho by BPS株式会社
エンジニアtype 技術者のキャリアを考えるWebマガジン - 転職＠type
プロのためのLinuxシステム・ネットワーク管理技術 - めもめも
Martin Fowler氏が"Yagni: You Are Not Gonna Need IT"について語る
テスト駆動開発とマイクロサービスのせいで短命に終わったスマホゲームの話
You aren't gonna need it - Wikipedia
You Arent Gonna Need It
コメントを書かないソースコードを書こう！ - 脱エンタープライズ志向