martedì 20 marzo 2018

PragPub September 2009 | Responsive Design

PragPub September 2009 | Responsive Design | The Pragmatic Bookshelf: "The challenge is to embrace responsibility and at the same time take an appropriate role in designing. Learning to achieve this balance is the next goal of the Responsive Design Project."

Responsive Design

PragPub September 2009 | Responsive Design | The Pragmatic Bookshelf: "But design has a dark side. While there isn’t a single best design for any system, there are many poor designs for that same system. The more experience a programmer has, the more design ideas he knows. The temptation is to put these design ideas in the system now because you just know you’ll need them eventually."

venerdì 15 settembre 2017

Procedural vs OOP — Sandi Metz

Breaking Up the Behemoth — Sandi Metz: "Sticking with procedures too long is just as bad as doing design too soon. If important classes in your domain change often, get bigger every time they change, and are accumulating conditionals, stop adding to them right now. Use every new request as an opportunity to do a bit of design. Implement the change using small, well-designed classes that collaborate with the existing object."

giovedì 17 agosto 2017

Code Smells – Part I | Codurance

Code Smells – Part I | Codurance: "a code smell is something that makes your developer instinct cry out to you, and you just know that something is wrong."

giovedì 13 luglio 2017

Open/Closed principle

Design patterns and practices in .NET: "the Open/Closed principle of SOLID: a class is open for extensions but closed for modifications."

giovedì 6 luglio 2017

Demystifying Conway's Law

Demystifying Conway's Law | ThoughtWorks: ""Any organization that designs a system (defined more broadly here than just information systems) will inevitably produce a design whose structure is a copy of the organization's communication structure.""

martedì 20 giugno 2017

The Three Laws of Test-Driven Development

The Three Laws of Test-Driven Development - Programmer 97-things:

"There are three simple laws:
  1. You can't write any production code until you have first written a failing unit test. 
  2. You can't write more of a unit test than is sufficient to fail, and not compiling is failing. 
  3. You can't write more production code than is sufficient to pass the currently failing unit test. If
If you follow the three laws every module will be testable by definition. And another word for testable is decoupled. "

[Clean Coder Blog] Tests need to be designed

Clean Coder Blog: "Yes. That’s right. Tests need to be designed. Principles of design apply to tests just as much as they apply to regular code. Tests are part of the system; and they must be maintained to the same standards as any other part of the system."

A Beginner’s Guide to Automated Testing – Hacker Noon

"Remember the rule: If it matters that the code works you should write a test for it."

A Beginner’s Guide to Automated Testing – Hacker Noon

mercoledì 7 giugno 2017

Surviving Legacy Code with Golden Master and Sampling - The Code Whisperer

Surviving Legacy Code with Golden Master and Sampling - The Code Whisperer:

"I treat valuable code with considerable respect. It provides food for families.
I treat difficult-to-change code also with considerable respect, although this comes more from fear than admiration."

This brings me to Rule Number Zero of Surviving Legacy Code:
 Maximize safety.

giovedì 11 maggio 2017

Keep your tests clean. Treat them as first-class citizens of the system.

Clean Coder Blog: "when people give up on unit tests, it’s usually because they haven’t followed the above author’s advice. They have not treated the tests like first-class citizens. They have not treated the tests as though they were part of the system. They have not maintained those tests to the same standards that they apply to the rest of the system. Instead, they have allowed the tests to rot, to become coupled, to become rigid, and fragile, and slow. And then, in frustration, they give up on the tests. Moral: Keep your tests clean. Treat them as first-class citizens of the system."

lunedì 24 aprile 2017

12 Things Truly Confident People Do Differently | Dr. Travis Bradberry | Pulse | LinkedIn

2. They Don’t Pass Judgment: "Comparing yourself to other people is limiting. Confident people don’t waste time sizing people up and worrying about..."

'via Blog this'

12 Things Truly Confident People Do Differently | Dr. Travis Bradberry | Pulse | LinkedIn

1. They Get Their Happiness from Within: "in order to be confident in what you do, you have to be happy with who you are."

'via Blog this'

lunedì 9 maggio 2016

Why Won’t They Pair?

Why Won’t They Pair?: "Few companies recognize teamwork as a valued skill and instead look for the ‘super hero’ who can come in to save the day during a crisis."

"At the end of the day, most developers fear being discovered as less competent as they appear to be.  Some would call it an example of imposter syndrome."

"The fundamental challenge is creating an environment where people feel safe to learn, make mistakes, fail faster, and continually improve their skills."

"Be sure to celebrate the successes and the failures, as they are all learning opportunities."

venerdì 8 aprile 2016

Extreme Enthusiasm » Blog Archive » Bureaucratic tests

Extreme Enthusiasm » Blog Archive » Bureaucratic tests: "Bureaucratic tests are about testing a bit of solution (that is, a bit of the implementation of a solution). Valuable test are about solving a little bit of the problem."

giovedì 3 dicembre 2015

Command and Query Responsibility Segregation VS Command–query separation
"Command and Query Responsibility Segregation uses the same definition of Commands and Queries that Meyer .... The fundamental difference is that in CQRS objects are split into two objects, one containing the Commands one containing the Queries."

martedì 15 settembre 2015

the Repository pattern | Exercises in .NET with Andras Nemes

The Repository pattern | Exercises in .NET with Andras Nemes: "Our goal is to make the concrete repository layer to depend on the domain layer and not vice versa which is often the case in real-life projects. This repository-independence is central in Domain Driven Design and has a special term for it: persistence ignorance."

venerdì 11 settembre 2015

Aveva ragione mia madre... quando esci dalla "port" indossa un "adapter"

a volte capita di dover importare nel nostro codice delle librerie esterne.

In .NET è semplicissimo, basta importare un pacchetto nuget e il gioco è fatto.

Il rovescio della medaglia è che in questo modo capita di utilizzare direttamente gli oggetti e i metodi che la libreria espone e ci si lega mani e piedi a questa.

Questo vuol dire che se in futuro volessimo utilizzare una nuova libreria o la stessa modificasse o deprecasse le sue chiamate dovremmo intervenire direttamente nel nostro codice magari in "n" punti diversi, inoltre andiamo a creare delle dipendenze e il nostro codice diventa intestabile.

Meglio sarebbe ascoltare i consigli di coloro che ci sono già passati e ne sanno più di noi... mia madre mi diceva sempre di mettermi una maglia di lana quando uscivo e faceva freddo... avrei dovuto ascoltarla più spesso :-)
in particolare l'architettura esagonale o detta "port and adapters" di Cockburn (1) ci dice di disaccopiare tutto ciò che è esterno dal nostro codice e anche il "Dependency inversion principle" di SOLID (2) ci consiglia di non dipendere dalle implementazioni.

Cosa fare quindi?

1. Bisogna creare una nuova interfaccia che espone il metodo che ci serve
2. Implementare l'interfaccia
3. implementare il metodo che ci serve utilizzando la libreria scelta

Questo ci permette di cambiare facilmente libreria, basta creare un nuovo adapter (3) verso la nuova libreria scelta.

Questo permette anche di sostituire la libreria con un mock che estende la nostra interfaccia e testare quindi il nostro codice.


lunedì 7 settembre 2015

Eric Evans on Domain Driven Design

Eric Evans on Domain Driven Design: "So then sometimes plain old Java code is clearer actually than you UML diagram that tries to convey some sort of relationship that is more dynamic."

giovedì 16 luglio 2015

"Wilma dammi l'ABTest"

Immaginate di avere questa riga di codice:


chiaro cosa fa questo codice? direi di si... invia un'email.

Cosa si nasconde dietro il metodo Send?

Nella mia esperienza potrei giurare che dietro questo metodo si nascondono una serie (innumerevole) di if e il metodo send molto probabilmente avrà centinaia (o migliaia) di righe e non farà solo il send ma probabilmente molto altre operazioni al contorno!

E pensare che probabilmente tutto è iniziato con una "semplice" if

if(il_dato_ha_questo_valore) { 
 fai questo;

semplice no?

e poi si sa come vanno queste cose, una "if" tira l'altra, l'emergenza, il fix "al volo" il poco tempo, sempre di corsa, il caldo... mi stanno chiamandodevoandare, sono le 18, suona la campanella... insomma "piccoli metodi crescono" e si arriva a creare nel tempo e a più mani un blob informe che assume comportamenti strani e diversi, che sembra vivere di vita propria a volte che a metterci mano bisogna prima farsi il segno della croce e quando ti chiedono una modifica bisogna avere la scusa pronta e non è sempre facile... una roba che "è colpa di chi ci ha messo mano prima di me", è codice legacy, non l'ho fatto io, io non c'ero e non ho fatto niente, non è colpa mia... insomma ci siamo capiti, è una storia già sentita vero?

Se qualcuno di voi ha mai sentito parlare della campagna anti-if (  sa di cosa sto parlando!

Molto spesso (anzi sempre) un "if" sottintende comportamenti diversi e logiche diverse.
Molto spesso (anzi sempre) l'applicazione dei principi SOLID (  salva la vita.

Facciamo un esempio e facciamo un viaggio nel meraviglioso mondo del metodo "Send" e probabilmente vedremo cose di questo tipo.
if(isABTest) {
 if(!recipients.isUnsubscribed) {
 var vetting = EseguiVetting();
if(vetting) {
 Logger.debug("fatto AB Test")

Cosa ne pensate se invece avessimo una serie di componenti (oggetti) ognuno dei quali fa una sola cosa (Single Responsibility) e che vengono utilizzati dal nostro EmailSender all'occorrenza abilitandoli o meno magari con un file di configurazione che li abilita solo in ambiente di staging e non li fa vedere in produzione perchè ahimè ci stiamo ancora lavorando?

immaginiamo di scrivere questo codice:


e torniamo nel nostro metodo Send dove al posto delle if troviamo una lista di SenderAction da eseguire, infatti il nostro metodo Enable aggiungerà semplicemente ad una lista l'azione da eseguire:

private var workflow = new List<SenderAction>;
public void Enable(
SenderAction actionToPerform){

mentre il metodo Send scorrerà semplicemente il nostro workflow e lancerà per ogni elemento il metodo Execute:

private var workflow = new List<SenderAction>;
public void Send(
 foreach(actionToPerform in workflow) {

infatti il nostro SenderAction è semplicemente un'interfaccia che espone il metodo Execute

interface SenderAction {
 public void Execute();

nell'esempio sopra il nostro parametro ABTest implementa il metodo execute alla sua maniera eseguendo solo l'ABTest ma ognuno ci può fare quello che vuole.

Quali vantaggi ho ottenuto?

L'oggetto che fa  l'AB test fa solo l'AB test(ancora Single Responsibility).
L'ABTest viene passata al EmailSender (Dependency Injection), quindi è mockabile permettendomi di testare il Sender.
L'ABTest è testabile a sua volta.
Ogni metodo ha poche righe e se devo mettere mano so dove andare.
L'EmailSender diventa quindi un semplice  orchestratore, cioè della serie "Miwa lanciami i componenti" (cit. Jeeg Robot)  oppure "Wilma, dammi l'ABTest!".

E se voglio fare il caffè?

Se voglio estendere il mio EmailSender e scopro che tra l'ABTest e l'operazione di Vetting per esempio deve farmi un caffè basterà semplicemente creare una classe AnExpressoPlease che implementa l'interfaccia SenderAction ed eseguire il metodo

emailSender.Enable(new AnExpressoPlease());

e il gioco è fatto! :-)

martedì 28 aprile 2015

The place to express yourself

douglascrockford/JSLint: "The place to express yourself in programming is in the quality of your ideas, and the efficiency of execution. The role of style is the same as in literature."

beautiful words!

lunedì 27 aprile 2015

le origini di javascript... sembra ieri!

ECMAScript - Wikiwand: "History JavaScript was originally developed by Brendan Eich of Netscape under the name Mocha, later LiveScript, and finally renamed to JavaScript.[1] In December 1995, Sun Microsystems and Netscape announced JavaScript in a press release.[2] In March 1996, Netscape Navigator 2.0 was released, featuring support for JavaScript."

sembra ieri!!! :-)

giovedì 16 aprile 2015

Naming mostly-abstract implementations

Naming mostly-abstract implementations - Google Gruppi: "If it's hard to think of a name for a class, I sometimes find it helpful to inline everything back to an unstructured mass, and then extract different methods and classes back out again.  Removing existing structure helps me see opportunities for a better new structure.  And inlining and extracting is very easy in refactoring IDEs.

 Interfaces that end in "Manager" or "Service" are a strong hint.  Interfaces named like this often define what I call a "CRAP" -- a Class That's Really a Procedure" --

Two techniques I find useful are:

 - Define interfaces to identify only what clients need, not what implementors provide.

 - Name interfaces in domain terms of the client, rather than using technology terms, pattern names, or vague words such as "Manager" or "Service".  This ends up guiding the code towards a Hexagonal architecture (or hexagons within hexagons within...).


martedì 7 aprile 2015

A Guide to Web Components

A Guide to Web Components | CSS-Tricks: "In an ideal scenario, the HTML language would be expressive enough to create complex UI widgets and also extensible so that we, the developers, could fill in any gaps with our own tags. Today, this is finally possible through a new set of standards called Web Components."

giovedì 26 marzo 2015

The Myth of the Rockstar Programmer - Scott Hanselman

The Myth of the Rockstar Programmer - Scott Hanselman: "Are rockstars about lines of code? No, good developers solve problems. More specifically, they make problems go away. They fix problems rather than complaining about them."

mercoledì 18 marzo 2015

Forget about command and control type of organization.

Starting out as a Scrum Master - | The home of Scrum - Forums | - The home of Scrum - Discussion Forums - Scrum:

"Forget about command and control type of organization.
 Start thinking in terms of value creation for:

 1) The customer
 2) The stakeholders
 3) The Scrum Team."

80/20 Practitioners Make Better Communicators · An A List Apart Article

80/20 Practitioners Make Better Communicators · An A List Apart Article: " Instead of labeling someone a “designer” or a “developer,” take stock of their true skillsets and passions. I’ve worked with amazing graphic designers, amazing UX designers, and amazing interaction designers, all of whom had the same title: designer. What works depends on the person."

A volte è necessario fermarsi e fare pulizia, sul proprio desktop e nella propria mente per cominciare a ritagliarsi un piccolo spazio per avere il tempo di fare cose utili alla propria crescita, al raggiungimento dei propri obiettivi e alla propria felicità. Fermati, respira, chiudi gli occhi e pensa a cosa vuoi davvero, in quale direzione vuoi andare, raccogli tutto ciò che ti serve, individua un piano, una serie di piccoli e semplici step che ti tratteggino la via, individua quelli che con minor sforzo danno maggior risultato e inizia dal primo...

lunedì 5 gennaio 2015

the key element of GOOS

Overcoming the one weakness of OOP, thoughts ? - Google Gruppi: "I think the key element of GOOS, w.r.t. your question, is that objects talk only to their immediate neighbours, and do not know anything about the object graph of which they are part.  Code does not explicitly traverse the object graph. The thread of control running through the objects does traverse the object graph (because it carries messages from one object to another), but the code that defines object behaviour is decoupled from the structure of that graph." Nat Pryce

mercoledì 27 agosto 2014

SourceTree TIP - Change the language to English in the Windows version? - Atlassian Answers

SourceTree - Change the language to English in the Windows version? - Atlassian Answers

"How can I change the language to English in the Windows version of SourceTree?"

answer :

"Just go to where SourceTree is installed and remove your language dir. In my case 'ru'. It will fallback to english!"

giovedì 17 luglio 2014

Educazione come dimensione della vita: il nuovo spazio da creare per la scuola | Luca De Biase

Educazione come dimensione della vita: il nuovo spazio da creare per la scuola | Luca De Biase: "Nell’economia della conoscenza l’educazione è come l’investimento e la ricerca è il generatore di valore aggiunto che consente di tenere a distanza i concorrenti.
Le persone e le strutture che ci lavorano sono straordinariamente importanti. 
nella nuova società della conoscenza il grande successo è valorizzare i talenti di tutti, nelle loro diversità e peculiarità.
L’addestramento riguarda il saper fare. L’istruzione riguarda le conoscenze intellettuali di base. La formazione è la maturazione della personalità nel suo insieme in relazione al contesto.
La nuova didattica, la formazione dei docenti, la gamification dei metodi, sono elementi della soluzione.
Si può creare uno spazio incentivante per questi progetti, un po’ come è stato fatto per le startup. Un ambiente liberato da eccessi di burocrazia e fisco che favorisca la progettualità. "

mercoledì 23 aprile 2014

the best way to acquire "Design Sense"... kata!

"the best way to acquire "Design Sense" is to find someone who has it, put your fingers on top of theirs, put your eyeballs right behind theirs, and follow along as they design something. Learning a kata may be one way of accomplishing this." ArticleS.UncleBob.TheBowlingGameKata

martedì 18 febbraio 2014

No More Technical Debt - Invest in Quality

No More Technical Debt - Invest in Quality: "Actually Technical Debt was introduced as a metaphor to help in these kinds of discussions. The idea is that code with a bad quality is like a financial burden. The total amount of the debt is the effort it would take to clean up the code base. The interest rate is the reduced productivity due to the bad code quality."

sabato 8 febbraio 2014

lunedì 3 febbraio 2014

MSDN Magazine: Dynamic .NET - Understanding the Dynamic Keyword in C# 4

"Remember that dynamic is in fact a static type in the C# type system, so the compiler infers this type for the anotherObject. It’s important to understand that the var keyword is just an instruction for the compiler to infer the type from the variable’s initialization expression; var is not a type."
Good blog post

lunedì 16 dicembre 2013

Elephant Carpaccio facilitation guide

Elephant Carpaccio facilitation guide: "The Elephant Carpaccio exercise is a great way for software people to practice & learn how to break stories into really thin vertical slices."

mercoledì 4 dicembre 2013

una sorta di ‘sistema nervoso autonomo’ nell’azienda

“Dirigenti e manager non servono più”, parla il guru Toyota | La nuvola del lavoro: "Un sistema che azzera le gerarchie, coinvolge maggiormente i dipendenti, con l’obiettivo di creare una sorta di ‘sistema nervoso autonomo’ nell’azienda che agisce con una sorta di indipendenza intrinseca. Non è anarchia, tutt’altro: è un sistema di redistribuzione delle responsabilità che, in Italia, può incontrare numerose resistenze."

mercoledì 18 settembre 2013

Anything else you'd like to mention?

Dev of the Week: Lukas Eder | Javalobby: "Creating a company around the project that has filled me with passion for the last four years has to be the best decision of my life. Ever since, I've met so many interesting people doing interesting things, inspiring me, letting me inspire them. I hope this intro about me will convince at least one or two other developers out there to pursue their dreams. "

Thanks, Lukas!

giovedì 22 agosto 2013

Have you ever experienced that you get a long list of compilation errors after adding Moles Assembly on a reference?

Moles not compiling | Degree Blogg: "The secret seems to be to add the ReflectionOnly attribute and set it to true."... solution to remember for the next time a caught in the same problem!

lunedì 8 luglio 2013

Difference Between Incremental and Continuous Improvement | BrainsLink

Difference Between Incremental and Continuous Improvement | BrainsLink: "Continuous improvement is quite different. It’s not an annual or quarterly event. In fact, it’s not an event at all. It’s more like an evolutionary lifestyle. When a development team discovers a better way of doing something, they change — immediately."

giovedì 30 maggio 2013

Naming standards for unit tests

Blog - Osherove: "If your test is not representing a requirement, why are you writing it? Why is that code even there?"

venerdì 17 maggio 2013

Can evolutionary design scale to SOA sizes?

EvolutionarySOA - Martin Fowler: "Can evolutionary design scale to SOA sizes? In my view we have an existence proof at a much larger scale than even a big SOA effort - the web itself. The web is built on very loose coupling and lots of unpredictable changes. It is, in many ways, a mess - but it's a mess that works, delivering real value to lots of people every day."


EvolutionarySOA - Martin Fowler : "Evolutionary design is an essential aspect of agile methods. One of the key foundations of agile methods is the desire to handle, indeed welcome, change.
Planned design assumes change is hard, and thus tries to predict where it occurs.
If changes occur within the predicted boundaries then it's easy, but if it falls outside those boundaries you're out of luck.
Agile thinking assumes unpredictable change is inevitable and tries to enable it in a controlled way."

mercoledì 15 maggio 2013

The London School of Test Driven Development

Coding Is Like Cooking : "In Classic TDD, whenever possible you check a return value or exception. If you’re testing a void method, then you usually take the second option and check state. Only if the other options are really unattractive do you ever turn to using a mock. It’s the last choice. With London School TDD, the option of using a mock is chosen much more often. You’ll still check return values or object states where that makes sense, but using a mock is often an attractive option. This is because using a mock helps you to both develop your system Outside-In, and to design your objects in an “Tell, Don’t Ask” manner."

'via Blog this'

domenica 12 maggio 2013

SOLID principles and TDD

Coding Is Like Cooking » Blog Archive: "I think you do need to invest in learning good design techniques independently of TDD."

mercoledì 8 maggio 2013

Get a Request Token (get_request_token) - YDN

Get a Request Token (get_request_token) - YDNBefore your Users get involved, your application uses your Consumer Key to obtain a Request Token (OAuth Core 1.0 Spec, Section 6.1).The Request Token is a temporary token used to initiate User authorization for your application. The Request Token tells Yahoo! that you've obtained User approval, but must be exchanged, along with the OAuth Verifier, for an Access Token. The Request Token is intentionally short so that a User can type it manually as part of the redirect URL in cases where the application cannot launch a browser (such as a mobile phone app or a device that has no browser).

lunedì 29 aprile 2013

Continuous Delivery is not just a technical process

"Continuous Delivery is not just a technical process but a change to the entire organization and the individuals within it." @ Continuous Delivery: Talk at HiQ 24th of April

mercoledì 17 aprile 2013

MokaByte 182 - Marzo 2013 - La gamification e il toccare con mano

MokaByte 182 - Marzo 2013 - Agile Gamification: apprendere le metodologie giocando: "Partendo da un concetto della vita reale che si vuole imparare, si possono scegliere o ideare dei giochi che permettano di trasmettere in modo semplice, immediato e coinvolgente i concetti. Questa è la tanto citata "gamification".

MokaByte 182 - Marzo 2013 - Agile Gamification: apprendere le metodologie giocando

MokaByte 182 - Marzo 2013 - Agile Gamification: apprendere le metodologie giocando: "Il gioco insegna quindi che per divertirsi bisogna rispettare le regole accettando le sconfitte e imparando dagli errori. Due aspetti molto importanti nella vita."

giovedì 31 gennaio 2013

Richardson Maturity Model

Richardson Maturity Model: "the web is an existence proof of a massively scalable distributed system that works really well"

"plain old XML (POX) back and forth"

lunedì 21 gennaio 2013

Internazionale » Opinioni » La scuola del duemila

Internazionale » Opinioni » La scuola del duemila:
"L’idea di base è che imparare non sia un’attività che trova la sua giustificazione in se stessa, ma serva a sviluppare il potenziale di ogni individuo."

"Il cambio di paradigma, dice Schleicher, è drastico: l’apprendimento non coincide più con un luogo (la scuola) ma è un’attività continuativa, una delle cui infrastrutture è la scuola. "

"In primo luogo, i sistemi scolastici eccellenti appartengono a paesi che valorizzano l’istruzione e gli insegnanti, considerati highly skilled workers la cui capacità va riconosciuta anche sotto il profilo retributivo."

"In secondo luogo, i sistemi scolastici eccellenti non prescrivono cose da insegnare ma obiettivi che gli studenti devono raggiungere"

"Le sfide per l’Italia: passare dalla logica del procurarsi una qualifica (il “pezzo di carta”) all’idea di un apprendimento che dura l’intera vita e migliora gli individui."

"la scuola deve preparare i ragazzi a continuare a imparare per tutta la vita"

giovedì 29 novembre 2012

decorator pattern key point!

"...its vital that the decorators have the same type as the objects they are going to decorate.
So here were using inheritance to achieve the type matching, but we arent using inheritance to get behavior."

the decorator pattern

"The Decorator Pattern attaches additional responsibilities to an object dynamically. Decorators provide a flexible alternative to subclassin"

the observer pattern

"The Observer Pattern defines a one-to-many dependency between objects so that when one object changes state, all of its dependents are notif"

the strategy pattern

"The Strategy Pattern defines a family of algorithms, encapsulates each one, and makes them interchangeable. Strategy lets the algorithm vary"

martedì 27 novembre 2012

design principle #4

"Classes should be open for extension, but closed for modification."  Head First Design Patterns

domenica 25 novembre 2012

Design Principle #3

"Favor composition over inheritance.Head First Design Patterns

Design Principle #2

"Program to an interface, not an implementation.Head First Design Patterns

Design Principle #1

"Identify the aspects of your application that vary and separate them from what stays the same." Head First Design Patterns

mercoledì 21 novembre 2012

Release Engineering at Facebook | Server Zone

Release Engineering at Facebook | Server Zone: "Be careful on Friday. At Google they had “no push Fridays”. Don’t check in your code and leave."

venerdì 16 novembre 2012

to make the diff

How to export from SVN repository only modified files between two tags with Ant?

here a simple script... URL1 and URL2 are the urls of the tags, "tmpDir" is a temporary folder(write permissions are necessary), "targetDir" is the destination folder.

USAGE: Simply run ant in the folder where you put the script (save the script as build.xml)

giovedì 15 novembre 2012

The Open/Closed Principle

Inversion of Control with the Plugin Pattern | Jeremy D. Miller: "The Open/Closed Principle   “Software entities (Classes, Modules, Functions, etc.) should be open for extension but closed for modification.”    As explained by Robert Martin here,"

Inversion of Control with the Plugin Pattern | Jeremy D. Miller

Inversion of Control with the Plugin Pattern | Jeremy D. Miller: "Inversion of Control is also known as the “Hollywood Principle” – “don’t call me, I’ll call you.”  In short, this principle applies when you create classes that are passive, i.e. they do not direct the executing flow of the code. "

How to Teach Design Patterns

Erich Gamma: "how we should teach patterns. ...  You have to feel the pain of a design which has some problem. I guess you only appreciate a pattern once you have felt this design pain."

The Dependency Injection Pattern

The Dependency Injection Pattern – What is it and why do I care? | Jeremy D. Miller: "In a nutshell, dependency injection just means that a given class or system is no longer responsible for instantiating their own dependencies."

Inversion of Control

What’s so great about Inversion of Control? | Jeremy D. Miller: "is an essential tool for any software designer’s design toolbox because it’s often a great way to break dependencies between classes and promote loose coupling.  IoC is vital for doing Test Driven Development without pulling out all of your hair in frustration. "

How to Use Design Patterns

Erich Gamma: "I think patterns as a whole can help people learn object-oriented thinking: how you can leverage polymorphism, design for composition, delegation, balance responsibilities, and provide pluggable behavior."

How to Learn about Patterns

Learning about Design Patterns | Jeremy D. Miller: "Write code.  Do some sort of nontrivial, personal coding project where you can freely experiment with design patterns."

Strategy pattern

Six Design Patterns to Start With | Jeremy D. Miller:
"Repeated switch statements can easily lead to duplicated code, and longish switch statements, in my experience, can lead to code that is hard to read and buggy.  Seeing a repeated switch statement on a type code is a sign that there is an abstraction in your code that’s trying to come out."

Template Method

Six Design Patterns to Start With | Jeremy D. Miller:
"I’ve learned that it’s often easier to introduce the superclass/Template Method combinations only after the second or third similar class."

Facade Pattern

Six Design Patterns to Start With | Jeremy D. Miller:
"It’s exactly what it sounds like, an attractive covering over a complex structure."

lunedì 9 luglio 2012

Automatizzazione dei processi che vengono coinvolti nella fase di rilascio di un'applicazione... quello che Jez Humble chiama "l'ultimo miglio", una fase spesso trascurata perché all'inizio di un progetto si è concentrati sul prodotto, ma che diventa sempre più complessa con il crescere dell'applicazione, fino a quando rilasciare diventa una fase critica, pressoché fatta manualmente e quindi soggetta ad errori, dimenticanze, poco o per niente standardizzata o ottimizzata, che richiede lunghi periodi e parecchio stress... rischiando di diventare un "collo di bottiglia" decisivo nella buona riuscita di un rilascio e quindi nella percezione che il cliente finale ha del prodotto.

Per contro cambiare certe modalità operative richiede tempo e risorse direttamente proporzionali alla complessità del prodotto e alla mancata attenzione che questa fase ha subito nel tempo, potrebbe richiedere cambiamenti nelle modalità di sviluppo ormai consolidate e per questo viene vista come un argomento scomodo da molti project manager poco lungimiranti. 

La regola è quella che indica Jez Humble in Four Principles of Low-Risk Software Releases: "The rule is that you never change existing objects all at once. Instead, divide the changes into reversible steps".

Automatizzare non vuol dire solo far fare tutto alla macchina, ma anche avere il controllo su quello che la macchina sta facendo, sullo stato del sistema in qualsiasi momento e la possibilità di ripristinare la situazione d'origine se necessario.

venerdì 6 luglio 2012

Every work day Facebook is safely updated with hundreds of changes including bug fixes, new features, and product improvements.

mercoledì 6 luglio 2011

timeline nel proprio sito

Ultimo World Wide Developer Conference di Apple (WWDC 2011), presentazione della nuova feature "Versions" che permette di mantenere le versioni di tutti i documenti in modo da poterli successivamente recuperare; nel filmato si vedono delle "tacchette" alla destra del monitor e avvicinandosi con il mouse queste si ingrandiscono e appare la versione del documento... se è quella che mi interessa ci clicco sopra e la versione viene ripristinata.

Ancora più interessante se applicato al web, per vedere articoli vecchi di un blog o a dei calendari di eventi... una sorta di linea temporale... che ne dite?
Si può fare lo stesso effetto utilizzando HTML + javascript + CSS?

domenica 26 giugno 2011

L'immagine si forma

l'immagine si forma
Un altro effetto che ho trovato interessante è quello della tag-cloud con parole di diverse grandezze che lentamente appaiono in un riquadro di fianco alla frase "L'immagine si forma".

Pensi che si possa fare lo stesso effetto utilizzando HTML + javascript + CSS?

venerdì 17 giugno 2011

lo sfondo che si sposta al muoversi del mouse

Uno dei primi siti che mi ha ispirato è quello di Edan Kwan
Questo sito, una volta passata la pagina di caricamento(abbastanza pesante), conduce alla pagina principale dove, tra i tanti effetti spettacolari che ostenta, ha lo sfondo che si sposta al muoversi del mouse.
la main page di (17 Giugno 2011)

Pensi che si possa fare lo stesso effetto utilizzando HTML + javascript + CSS?

Ci sono probabilmente mille possibili soluzioni, io ne ho trovato una.
Probabilmente non è la migliore: si accettano idee, proposte, confronti :-)