You cannot under any circumstances have a single model that does everything for you and does it well. It doesn't exist!-Greg Young https://www.youtube.com/watch?v=JHGkaShoyNs
Saturday, May 26, 2018
Saturday, May 19, 2018
And nobody quite understood that there's no difference between a use-case and a user story: they're the same thing.The Principles of Clean Architecture by Uncle Bob Martin
Wednesday, May 9, 2018
The trick to cache design is finding an algorithm that gets key information into L1 cache when it's needed. This is so important to performance that more than half of a processor's transistors may be used for a large on-chip cache.https://www.computerworld.com/article/2584352/computer-hardware/inside-a-microprocessor.html
Since all diodes having only two terminal means no controlling action possible whereas Transistors (BJT, FET’s e.t.c) have three terminal.Thus configuration of transistors allows for controlling action due to presence of controlling terminal (i.e for BJT ‘Z’ is Base and for FET’s ‘Z’ is Gate terminal).http://qr.ae/TUTsSg
Tuesday, August 15, 2017
JSF was designed in part by the authors of Struts to create a "Struts" that did a more accurate implementation of MVC (Struts is technically "Model 2") and to get rid of all the interface and subclass dependencies. The idea being that POJOS are more re-usable and easier to unit-test offline than framework-dependent code. Which is why I chant endlessly:
The more JSF-specific code that is in your JSF webapp, the more likely it is that you're doing it wrong.
The other thing that the Struts folks didn't like about Struts was that you had to define too many classes for each component. In JSF, you define a view template file, a backing bean (model), and that's basically it. There's no separate "action" class to transition data in and out of the MVC part of the webapp, just POJO methods that are defined in the same class as the POJO model.
Tuesday, November 29, 2016
Large, complex private methods are a code smell. An implementation which is so complex that it cannot be usefully decomposed into component parts (with public interfaces) is a problem in testability that reveals potential design and architectural problems. The 1% of cases where the private code is huge will usually benefit from rework to decompose and expose. – S.Lott Feb 14 '12 at 20:06http://softwareengineering.stackexchange.com/questions/135047/new-to-tdd-should-i-avoid-private-methods-now#comment253312_135049
Wednesday, October 12, 2016
...a suite of tests is run, optimized to execute very quickly. We refer to this suite of tests as commit stage tests rather than unit tests, it is useful to include a small selection of tests of other types at this stage...
Begin the design of your commit test suite by running all unit tests. Later, as you learn more about what types of failure are common in acceptance test runs ... you should add specific tests to your commit test suite to try and find them early on.
Acceptance tests written without developer involvement also tend to be tightly coupled to the UI and thus brittle and badly factored, because the testers don't have any insight into the UI's underlying design and lack the skills to create abstraction layers or run acceptance tests against a public API.
- Continuous Delivery
- Jez Humble, 2011