You ain't gonna need it "You aren't gonna need it"[1][2] (acronym: YAGNI)[3] is a principle of extreme programming (XP) that states a programmer should not add functionality until deemed necessary.[4] Ron Jeffries writes, "Always implement things when you actually need them, never when you just foresee that you need them."[5] The phrase also appears altered as, "You aren't going to need it"[6][7] or sometimes phrased as, "You ain't gonna need it". YAGNI is a principle behind the XP practice of "do the simplest thing that could possibly work" (DTSTTCPW).[2][3] It is meant to be used in combination with several other practices, such as continuous refactoring, continuous automated unit testing and continuous integration. YAGNI is not universally accepted as a valid principle, even in combination with the supporting practices. Rationale[edit] See also[edit] References[edit] Jump up ^ Extreme Programming Installed, Ronald E.
Lazy Loading with External PHP Iterators The fun side of outer iterators (at least when using an OOP approach) is that their implementation is (in most cases) a straightforward process that can be mastered in a snap. Of course, claming this without concrete proof would be rather pointless. In line with this idea, in previous installments of this series I went through the development of a couple of concrete examples that demonstrated how to use an external iterator for traversing the protected fields of a class whose primary use was to model generic entities. In the first tutorial, the whole traversing task was performed via a custom array collection, while the second how-to achieved the same process through the native ArrayIterator class bundled with the SPL. It goes without saying that external iterators can be used for many different purposes, aside from those described above. Traversing Array Elements: Building a Custom Array Collection Pretty simple right?
CSS Dry Principle The DRY (Don’t Repeat Yourself) principle is a software design theory that stresses the importance of not duplicating code. Every software programmer these days uses a variety of design principles and design patterns in their day to day programming tasks. It helps them improve the quality, performance and maintainability of the software system by avoiding code redundancy. Other useful CSS articles: We have to alert schools, banks, insurance companies, doctors, friends, etc. The DRY principle suggests that we should have only one copy of our address stored somewhere and everyone else should refer to that address. Grouping Selectors Incorporating DRY principle in web design, especially in CSS coding can really enhance our web design experience. The normal CSS code will look like this: By grouping the CSS selectors the same code can be re-written like below. Shorthands Properties Div can be re-written using CSS shorthands in a much simpler manner like below. Nesting Selectors Summary In Closing
A beginners guide to Dependency Injection Scope This article presents a high level overview of Dependency Injection (DI). It aims to present the overall concept of Dependency Injection to the junior developer within the context of how it could be used in a variety of DI containers. Dependency Injection (DI) or Inversion of Control (IOC) ? A lot of current literature often refers to the same design pattern as either Dependency Injection or Inversion of Control. Also note that I have used the term Service extensively through this article. Simple Introduction to Dependency Injection A simple introduction Scenario 1 You work in an organization where you and your colleagues tend to travel a lot. Thus your typical travel planning routine might look like the following : Decide the destination, and desired arrival date and time Call up the airline agency and convey the necessary information to obtain a flight booking. Its not just you, but probably many of your colleagues would need to adjust themselves to the new scenario. Scenario 2
Model–view–controller Model–view–controller (MVC) is a software pattern for implementing user interfaces. It divides a given software application into three interconnected parts, so as to separate internal representations of information from the ways that information is presented to or accepted from the user.[1][2] The central component, the model, consists of application data, business rules, logic and functions. A view can be any output representation of information, such as a chart or a diagram. Component interactions[edit] A typical collaboration of the MVC components In addition to dividing the application into three kinds of components, the Model–view–controller (MVC) design defines the interactions between them.[4] Use in web applications[edit] Although originally developed for desktop computing, model-view-controller has been widely adopted as an architecture for World Wide Web applications in all major programming languages. History[edit] See also[edit] References[edit] External links[edit]
KISS principle From Wikipedia, the free encyclopedia Design principle preferring simplicity A simple sign of the KISS principle (without the fourth word). Origin[edit] While popular usage has transcribed it for decades as "Keep it simple, stupid", Johnson transcribed it simply as "Keep it simple stupid" (no comma), and this reading is still used by many authors.[9] The principle is best exemplified by the story of Johnson handing a team of design engineers a handful of tools, with the challenge that the jet aircraft they were designing must be repairable by an average mechanic in the field under combat conditions with only these tools. The acronym has been used by many in the U.S. military, especially the U.S. Variants[edit] The principle most likely finds its origins in similar minimalist concepts, such as: Heath Robinson contraptions and Rube Goldberg's machines, intentionally overly-complex solutions to simple tasks or problems, are humorous examples of "non-KISS" solutions. Usage[edit] In politics[edit]
Lazy Loading An object that doesn't contain all of the data you need but knows how to get it. For a full description see P of EAA page 200 For loading data from a database into memory it's handy to design things so that as you load an object of interest you also load the objects that are related to it. However, if you take this to its logical conclusion, you reach the point where loading one object can have the effect of loading a huge number of related objects - something that hurts performance when only a few of the objects are actually needed. A Lazy Load interrupts this loading process for the moment, leaving a marker in the object structure so that if the data is needed it can be loaded only when it is used. There are four main varieties of lazy load. These approaches vary somewhat subtly and have various trade-offs.
DRY CSS: Don’t Repeat Your CSS A few weeks ago in the comments on my post about css formatting, Brett and David pointed me to a couple of articles and a presentation I hadn’t yet seen. All had interesting ideas about css practices and I thought I would offer some of my thoughts on them. One of the articles, Don’t use IDs in CSS selectors? In this post I want to talk about a presentation Brett pointed me to. DRY CSS Principles I wasn’t quite sure what to make of Jeremy’s presentation. Some of my doubt is probably due to a lack of practical application on my part so keep that in mind. If you’re not familiar with DRY, it stands for don’t repeat yourself, which is hopefully something we can all get behind. Jeremy offered 2 principles for writing good css. Keep style separate from contentAvoid specificity by harnessing the cascade These should look familiar as they’re essentially the same principles of OOCSS and SMACSS. So how does it work? How DRY CSS Works DRY CSS comes down to 3 things: Additional Thoughts DRY and OOCSS
Factory method pattern Factories may be invoked in various ways, most often a method call (a factory method), sometimes by being called as a function if the factory is a function object (a factory function). In some languages factories are generalizations of constructors, meaning constructors are themselves factories and these are invoked in the same way. In other languages factories and constructors are invoked differently, for example using the keyword new to invoke constructors but an ordinary method call to invoke factories; in these languages factories are an abstraction of constructors but not strictly a generalization, as constructors are not themselves factories. Terminology differs as to whether the concept of a factory is itself a design pattern – in the seminal book Design Patterns there is no "factory pattern", but instead two patterns (factory method pattern and abstract factory pattern) that use factories. # collections.defaultdict([default_factory[, ...]]) d = defaultdict(list)
Convention over configuration Convention over configuration (also known as coding by convention) is a software design paradigm which seeks to decrease the number of decisions that developers need to make, gaining simplicity, but not necessarily losing flexibility. The phrase essentially means a developer only needs to specify unconventional aspects of the application. For example, if there's a class Sale in the model, the corresponding table in the database is called “sales” by default. It is only if one deviates from this convention, such as calling the table “sale”, that one needs to write code regarding these names. When the convention implemented by the tool matches the desired behavior, it behaves as expected without having to write configuration files. Only when the desired behavior deviates from the implemented convention is explicit configuration required. Motivation[edit] Some frameworks need multiple configuration files, each with many settings. Usage[edit] See also[edit] References[edit] External links[edit]
SOLID (object-oriented design) In computer programming, SOLID (Single responsibility, Open-closed, Liskov substitution, Interface segregation and Dependency inversion) is a mnemonic acronym introduced by Michael Feathers for the "first five principles" named by Robert C. Martin[1][2] in the early 2000s[3] that stands for five basic principles of object-oriented programming and design. The principles when applied together intend to make it more likely that a programmer will create a system that is easy to maintain and extend over time.[3] The principles of SOLID are guidelines that can be applied while working on software to remove code smells by causing the programmer to refactor the software's source code until it is both legible and extensible.
CRUD: creating, reading, updating, deleting CRUD is een afkorting uit de informatica die staat voor de vier basisoperaties die op duurzame gegevens (meestal een database) uitgevoerd kunnen worden. Deze zijn: Create (of insert): Toevoegen van nieuwe gegevens.Read (of select): Opvragen van gegevens.Update: Wijzigen van gegevens.Delete: Verwijderen van gegevens. Vrijwel elk softwareprogramma maakt gebruik van de CRUD-functionaliteit. CRUD-matrix[bewerken] Een CRUD-matrix legt de relaties vast tussen data-objecten (tabellen in een relationele database) en systeemfuncties. CRUD-matrices (of tabellen) kunnen gebruikt worden als een hulpmiddel voor de compleetheidscontrole van een logisch informatie- of datamodel. Gegevenscyclustest[bewerken] Een CRUD-matrix is ook nodig als er een gegevenscyclustest moet worden uitgevoerd. Geschiedenis[bewerken]
Inyección de dependencias En Informática, Inyección de Dependencias (en inglés Dependency Injection, DI) es un patrón de diseño orientado a objetos, en el que se suministran objetos a una clase en lugar de ser la propia clase quien cree el objeto. El término fue acuñado por primera vez por Martin Fowler. Historia[editar] En los comienzos de la programación, los programas eran lineales y monolíticos. Aparecieron dos conceptos para estructurar el código: la modularidad y la reutilización de los componentes: se crean bibliotecas de componentes reutilizables. El problema de la dependencia se empieza a considerar lo suficientemente importante como para definir nuevos conceptos en el diseño : Inversión de control (IoC, por sus siglas en inglés)Inyección de Dependencias (Dependency Injection, DI) que es una forma de inversión de control. Implementación del patrón en Java[editar] La forma habitual de implementar este patrón es mediante un "Contenedor DI" y objetos planos o simples por ejemplo los llamados POJO en java.