Sebastian Aaltonen氏のプログラミング観 - Qiita
とても勉強になったので写経のつもりで翻訳しました。 普段自分でもわかっている気がするけど言語化するのが難しかったこと、自分でやっていて確かにあとから痛い目を見たかもしれないと反省を促される内容でした。 ※ゲームプログラミング特有だなと感じた内容はきちんと理解できなかったので割愛しています。 Now that people have already said highly controversial stuff like ”debugger is useless for C++ development”, I think I can share my own controversial thoughts about unit testing, DRY, copy-paste coding and function length, etc... with 20 years of C++ pro
500日のトライエラーから生まれた大規模設計ノウハウ / Frontend Conference Fukuoka 2018 - Speaker Deck
2018/12/8 Frontend Conference Fukuoka 2018にて発表した資料です。
Reactで開発するチームが共通認識しておきたい重要な概念 - KitchHike Tech Blog
SFC, Redux, HOCなどコンポーネント指向とReact開発のキーワード CTOの Shoken です。キッチハイクでは2年前にRailsへのReact導入、1年半前に0ベースからReact Nativeでアプリ開発を始めました。この記事では、React, React Nativeで開発しているチームが共通認識したいReactの重要な概念について紹介します。 2018/11/07 追記（はてブコメントより） Reactリポジトリで名称の変更が行われ、変数名やクラス名が変更されました。いままでの Functional Component が Function Component となり、 Stateless は使わなくなって Function に統一されるようです。 Terminology: Functional -> Function Component #13775 Before
『ドメインモデルに対する日米の温度差』
マーチン・ファウラー氏によれば、アプリケーションの中核部であるビジネスロジックを構築する方法には、Transaction ScriptパターンとDomain Modelパターンの2通りがあるという。Domain Modelパターンは、データと振る舞いを1つのオブジェクトにまとめ、オブジェクト指向のテクニックを駆使するやり方だ。一方のTransaction Scriptパターンでは、データと振る舞いは別々のオブジェクトに分け、振る舞いをスクリプト的に淡々とプログラミングしていく。 日本ではTransaction Scriptが優勢 この2通りのうち、日本ではTransaction Scriptパターンの方が優勢だ。日本のオピニオンリーダーも軒並みTransaction Scriptを薦めている。 たとえば、Seasarの開発者であるひがやすを氏は、古くからデータと振る舞いを分離するアプローチ
State Architecture Patterns in React: A Review
This is the first in a series of articles intended to provide an in-depth review of a few common architectural patterns that are employed when building complex web applications using React (or sufficiently React-like libraries), as well as some advice for avoiding common issues associated with those patterns. I confess that I also have a secondary intent. As I was writing, I realized that some of
最適な設計でアプリを作る
CAMPFIRE iOS #1での発表資料です。 https://yj-meetup.connpass.com/event/51735/ #yjcamp
技術的負債の返済プロジェクトが失敗する 11 のワケ - jfluteの日記
ワケ一覧 序の口: フレームワークだけが負債だと思ってる 序二段: ビジネスサイドに理解してもらう努力がない 三段目: 技術で遊び過ぎてしまう 幕下: 太り過ぎアーキテクチャ 十両: 過去に目もくれず、現状だって見ない 前頭: 技術に詳しいだけでアーキテクト 小結: アーキテクトの知識と覚悟が足りない 関脇: スパンが長く、モチベーションが続かない かど番大関: スパンが長く、人の入れ替えでチグハグ 大関: アーキテクチャデザインはどこへ？ 横綱: 実は人間的負債だった 序の口: フレームワークだけが負債だと思ってる みんな、フレームワークが大好き。とはいえ、さすがにみんな、「フレームワークが古いことだけが負債」だなんて思ってないはずだが...なのに多くの人が、あたかもそのような振舞いと判断をしてしまう。潜在意識の Big Issue だから？ o 信用できないテストデータ も負債 o 現
機構と方針の分離 - Wikipedia
機構と方針の分離[1]とは、計算機科学における設計原則の1つ。機構（操作の認可と資源配分を制御するシステム実装部分）は、どの操作を認可するかやどの資源を割り当てるかといった決定を行う際の方針を表すべきでない（あるいは過度に制限すべきでない）という考え方である。 主にセキュリティ機構（認証と認可）に関して議論されるが、様々な資源配分問題（CPUスケジューリング、メモリ割り当て、Quality of Serviceなど）にも当てはまる考え方であり、オブジェクト抽象化全般に関わる課題でもある。 機構と方針を分離すべきだと主張した計算機科学者として Per Brinch Hansen がいる[2][3]。 1987年の論文で Artsyらは「機構と方針を極端に分離」させたオペレーティングシステムの設計技法を論じた[4][5]。 Chervenakらは2000年の論文で、「機構中立性」と「方針中立性
「実践UML 第３版」と責務駆動設計: ソフトウェア工学には頭脳が足りない
さて「ソフトウェア工学には頭脳が足りない」シリーズの２回目です。「シリーズだったんだ、これ。」って自分でもそんな感じですが、前回のアクセス数が多かったのでタイトルを流用することにしました。現金で申し訳ありません。ついでにシリーズだけを追掛けやすい様にブログ自身も分けました。なお、予想通りtwitter上でアンチな反応もありましたが、直接メンションを付けられたわけではないので補足や反論はせず、伝え切れていない事を伝える事に専念したいと思います。議論をお望みでしたら、直接こちらにコメントする様にお願いします。 それでは始めましょう。 今回は前回にちょっとだけ触れた「ユースケース図」について取り上げる予定でしたが、予定を変更してUMLのバイブル本の一つ「実践UML 第３版」を吊るし上げたいと思います*。（おいw）語尾も今回だけ「ですます」調に変わりますが、よろしくお付き合いください。 さて、いき
README Driven Development
A relevant ad will be displayed here soon. These ads help pay for my hosting. Please consider disabling your ad blocker on Pony Foo. These ads help pay for my hosting. These are short-form “thoughts”, in addition to the usual longer-form articles in the blog. The goal is to publish one of these every weekday. I’d love to know what you think. You may send your questions to thoughts@ponyfoo.com. I’l
浅野紀予「思想としてのペースレイヤリング」 | ÉKRITS / エクリ
建物は変化する。刻々と成長し、みずから学んでいくものである。単なる空間的な構造物ではなく、時間というパラメータを考慮に入れ、この世界に生まれ、様々な成長を遂げ、やがては死に至る、一種の「有機的存在」としてとらえなおす必要があるのではないか。 スチュアート・ブランド※1 は、著書『How Buildings Learn』で、時の流れとともに建物に何が起こるのかを探究しました。そのなかでブランドが提示した「ペースレイヤリング（Pace Layering）」の概念は、建築の世界にとどまらず、情報やメディアに関わる分野でも多くの注目を集めてきました。 この本が世に出てから20年後の今、その思想の意味をあらためて考えたいと思います。 スチュアート・ブランドの基本モデル ペースレイヤリングの基本となったのは、この本で示された以下のモデルです。 ［図1］ “Shearing Layers of Chan
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
CSS for Software Engineers for CSS Developers