Get Started for FREE
Sign up with Facebook Sign up with X
I don't have a Facebook or a X account
 Your new post is loading...
Your new post is loading...
Scoop.it!
Single worst strategic mistake you could ever make? Rewriting code from scratch. 
No comment yet.
Sign up to comment
Scoop.it!
Cartes CRC - WikipédiaWard Cunningham a inventé les cartes CRC en s'inspirant d'une application de documentation d'architecture logicielle sous hypercard . Il les a présenté avec Kent Beck lors de la conférence OOPSLA de 1989.
Mickael Ruau's insight:
Il s'agit de simples fiches bristol qui contiennent le nom de la classes, ses responsabilités (les informations qu'elle connait, les actions qu'elle réalise…) et ses collaborateurs (les classes avec lesquelles elle interagit). Lors d'une réunion les participant manipulent les cartes pour simuler les interactions entre les classes du système lorsqu'il est soumis à cas d'utilisation.
Scoop.it!
So I’m going to define some concepts to flesh out an idea. This isn’t exactly a formalized theory or anything. It’s rather just a working lexicon of how I think about my application. This is a scale of system flexibility for a given future change. Or, put another way, here is a way of assessing how much effort on the part of the entire development/operations group doing X for the aforementioned user will be, from least to most significant. Users can do it themselves.An IT-level change is required (e.g. changing a config file, swapping out images, etc.)An architect/dev change is required to configuration (e.g. XML for an IoC container)A non-compiled source code change is required (e.g. you update the markup for a site but not the underlying code)An Open/Closed Principle Compliant source code change is required (basically adding new code).A localized tweak to existing code is required.A substantial change to existing code is required spanning various modules.
Mickael Ruau's insight:
None of this is even remotely comprehensive, but my goal here is really just to encourage people to understand at design time the difficulty of changing something at production time. It seems quite often to be the case that people don’t really think about this, and simply because no one has ever pointed it out to them. Your mileage may vary on the number of categories in the list and your preference for certain options, but at the core of this is a basic and incredibly important idea: you should always play “what if” when it comes to changes that users might request and understand how much of a headache it will be for you if the “what if” comes true. Oh, and also try to minimize the number of headaches. But hopefully that goes without saying.
Scoop.it!
Kevlin Henney believes that it's time to revisit the thinking behind "Worse is Better" which is what he does in this interview with Noel Wurst.
Mickael Ruau's insight:
Instead of aiming for full-scope perfection, take an empirical and incremental approach, ensuring that the implementation at each step is small and simple, bug-free, fast and works with existing code and software ecosystems. Reduce scope rather than compromise on quality, performance or simplicity—with a preference for simplicity of implementation over simplicity of interface if one must be traded for the other. Noel: In doing some research on "Worse is Better," I found Richard P. Gabriel's website and read his fascinating piece on the evolution of the "Worse is Better" concept. I really marveled at Gabriel's own back and forth flip-flopping on whether worse actually is better. Obviously you're a supporter of the method; what are your main reasons for being behind it?
Scoop.it!
If you are like me, in your career you came across Architects who want to homogenize every single application in the company : from the smallest web app to the biggest application.
Scoop.it!
Dans une implémentation SOA, un service n’a de sens que s’il est invoqué par plusieurs applications ou blocs applicatifs. Par conséquent, tout changement survenant sur un service impacte l’ensemble des consommateurs de ce service. Non seulement ces changements peuvent coûter chers, en plus, l’autonomie du service est un fondement de la mise en œuvre d’une architecture orientée services. L’autonomie se traduit par le fait que le service peut être modifié, déployé et maintenu indépendamment des consommateurs qui l’invoquent.
Mickael Ruau's insight:
Même si l’approche de versioning peut paraître simple, il est indispensable de traiter les volets suivants entre fournisseurs et consommateurs de services:
L’unité de versioning: il est indispensable de distinguer les versions majeures (V1, V2, etc.) des versions mineures (V1.x, V2.y) dans l’implémentation d’un service. Une version mineure porte sur une optimisation de performances, correction de bugs, évolution mineure du contrat de service sous condition de compatibilité ascendante entre versions, etc. alors qu’une version majeure porte sur des modifications/évolutions fonctionnelles ou techniques impactant fortement le contrat de service (avec rupture de la compatibilité ascendante) entre fournisseur et consommateurs du service.
La traçabilité d’une version: il est important de détailler, tracer et partager les changements survenus sur les différentes versions d’un service. Cela permettra aux consommateurs d’étudier les impacts fonctionnels et techniques sur leurs applicatifs et planifier des trajectoires de migration/évolution.
Le cycle de vie d’une version : Le cycle de vie doit être partagé par l’ensemble des acteurs pour que chacun puisse gérer l’évolution des versions de services que l’application qu’il gère invoque. Par exemple, la disparition d’une version de service peut profondément impacter le bon fonctionnement d’une application. En revanche, le fournisseur de service ne peut gérer indéfiniment toutes les versions. Un compromis sur le cycle de vie d’une version de service doit être trouvé entre consommateurs et fournisseur.
La stratégie de déploiement et d’invocation des différentes versions d’un service : Trois principales stratégies de versioning se distinguent.
Scoop.it!
Another superb guest post is up on Martin Fowler's blog today. This one is about a topic that doesn't get a lot of coverage outside of DZone, Enterprise Integration. Here was a pointed introductory paragraph from the article: Preview...
Scoop.it!
Separation of concernsIn computer science, separation of concerns ( SoC) is a design principle for separating a computer program into distinct sections, such that each section addresses a separate concern. A concern is a set of information that affects the code of a computer program.
Scoop.it!
Lorsque l'on entend parler de moteur de règles, on a souvent tendance à y associer le mot "Drools". Pourquoi ce réflexe : Par habitude ? Pa
Scoop.it!
The guide is intended to help developers and solution architects design and build effective, high quality applications using the Microsoft platform and the .NET Framework more quickly and with less risk; it provides guidance for using architecture principles, design principles, and patterns that are tried and trusted.
Mickael Ruau's insight:
The guidance is presented in sections that correspond to major architecture and design focus points. It is designed to be used as a reference resource or to be read from beginning to end. The guide helps you to: Understand the underlying architecture and design principles and patterns for developing successful solutions on the Microsoft platform and the .NET Framework.Identify appropriate strategies and design patterns that will help you design your solution's layers, components, and services.Identify and address the key engineering decision points for your solution.Identify and address the key quality attributes and crosscutting concerns for your solution.Create a candidate baseline architecture for your solution.Choose the right technologies for your solution.Identify patterns & practices solution assets and further guidance that will help you to implement your solution.
Scoop.it!
“Small pieces loosely joined,” David Weinberger’s appealing theory of the Web, has much to say to programmers as well. It always inspires me to reduce the size of individual code components.
Scoop.it!
Il existe de plus en plus de services Webs, qui vous permettent de couvrir un bon nombre de problèmes récurrents. L’heure est de plus en plus à l’intégration de service, et l’interface technique est bien souvent constituée d’un peu d’échanges HTTP, avec parfois du Javascript côté client.
Mickael Ruau's insight:
J’ai partagé l’article en 2 parties, vous retrouverez donc ici une première liste de solutions.
Quelques solutions : Envoyer un email transactionnelEnvoyer une lettre d’informationS’authentifier avec son compte Google, Yahoo, LinkedIn ou Github (OpenID)S’authentifier avec Facebook et accéder à l’API Social de FacebookAnalyser la fréquentation d’un siteDiscuter en direct sur le sitePartie 2 Analyser le parcours client et détecter les circuits des visiteursGéolocaliser l’adresse IP de vos visiteursIntégrer les commentaires des visiteursPrendre en compte les idées de vos visiteursAccepter des paiements par Carte bancaire
Scoop.it!
Scalable & Available Patterns for SuccessTuesday, March 8, 2011 1
|
Scoop.it!
DossierLe cloud : quels enjeux et quels rôles pour les DSI ?TechniqueRéussir l’urbanisation de son Système d’InformationComment ca marchePlus de 10 ans de projets de gestion des identités… et maintenant ?Rubrique a bracTests applicatifs sur environnements virtualisés avec Team Foundation Server
Scoop.it!
Méthode RACINESLa méthode RACINES est une méthode informatique destinée à étudier la stratégie du système d'information. RACINES est un acronyme de RAtionalisation des Choix INformatiqu ES. Elle a pour but de définir des priorités d'informatisation par domaine dans le cadre d'un fonctionnement global futur, en tenant compte des budgets et des calendriers.
Scoop.it!
Brute force performance and scalability testing, also known as "load it up and see what happens," is expensive, slow, and fairly subjective.
Scoop.it!
Let us celebrate this venerable structural stalwart with a rousing tour of examples showing just how classes are grouped and protected within their loving confines.
Supplying these specimens will be no Java weakling found huddled in an internet basement, but Apache's flagship software management tool, Maven itself. Specifically, the maven-core-3.0.5.jar has been casually selected as the lucky donor.
The contents of these packages will be shown as spoiklin diagrams in which a circle represents a class, a straight line represents a dependency from a class drawn above to one drawn below and a curved line represents a dependency from a class drawn below to one drawn above.
The colour of a class indicates the relative number package-dependency tuples (that is, transitive dependencies) of which it partakes: the redder, the more dependency tuples.
Mickael Ruau's insight:
We are losing the war on coupling. Little will change until front-line programmers tear off their blindfolds and see coupling as the enemy it is, until they learn to identify the stinking lairs in which coupling gestates, until they fix bayonets and get in nice and close.
Scoop.it!
Lorsqu’on parle de ressource et de REST en général, on associe souvent la notion de services, une représentation XML ou JSON d’un résultat, d’une donnée…On ne pense que rarement à la notion de ressource comme pouvant retourner une IHM ou une portion d’IHM, c’est-à-dire, de la donnée mise en forme. Ici, l’idée est simple : utiliser des ressources REST – proposant une représentation HTML – pour agréger et construire une nouvelle IHM côté client, dans le navigateur.
Mickael Ruau's insight:
Il s’agit là d’une façon simplissime d’intégrer de l’IHM au niveau du navigateur et de proposer des ressources ayant potentiellement une représentation au format HTML et donc une mise en forme partageable, réutilisable. Reste à ne pas tomber dans les extrêmes…
Scoop.it!
Making Your PHP Application Easy to CustomizeJohn Mertic@2010 SugarCRM Inc. All rights reserved.
Scoop.it!
The Microsoft SQL Server 2012 System Views Map shows the key system views included in SQL Server 2012, and the relationships between them.
Mickael Ruau's insight:
The Microsoft SQL Server 2012 System Views Map shows the key system views included in Microsoft SQL Server 2012, and the relationships between them. The map is similar to the prior versions of Microsoft SQL Server System Views Maps and includes updates for the Microsoft SQL Server 2012. Note that not all possible relationships are shown.
Scoop.it!
Swagger is a specification and complete framework implementation for describing, producing, consuming, and visualizing RESTful web services. The overarching goal of Swagger is to enable client and documentation systems to update at the same pace as the server. The documentation of methods, parameters, and models are tightly integrated into the server code, allowing APIs to always stay in sync. With Swagger, deploying managing, and using powerful APIs has never been easier.
Mickael Ruau's insight:
As a specification, Swagger is language-agnostic. But since a spec without a usable implementation has limited immediate value, Wordnik has released Swagger implementations in Scala, Java, and HTML5. Client generators are currently available for Scala, Java, Javascript, Ruby, PHP, and Actionscript 3. More client support is underway.
Scoop.it!
Un modèle doit être à la fois sobre (principe d’économie) et pertinent (principe d’efficacité). La justesse de ces principes résulte de la complexité inhérente au réel et de notre incapacité à le penser entièrement. Il faut percevoir cette incapacité non comme un manque, un défaut, mais comme une force : elle est condition nécessaire de l'action et de la formation du « coup d’œil », de même que l'imperfection de notre mémoire est condition nécessaire de notre capacité à créer des concepts (cf.Les embarras de la complication). Pour sortir de l'embarras, il faut assumer et cultiver la simplicité de la pensée. On peut aussi s'appuyer sur quelques outils méthodologiques : modèle en couches ; croisement des découpages ; raisonnement probabiliste ; élaboration de la pertinence par des consultations et validations, etc. On rencontre en informatique des difficultés d'origine technique : par abus de langage, on les baptise du terme « complexité ». Elles ne relèvent pas exactement de la présente étude, mais il est intéressant de les examiner (cf. "Complexité" en informatique).
Scoop.it!
Voici la suite d’un retour d’expériencessur différentes API et outils webs que j’utilise pour mes clients Analyser le parcours client et détecter les circuits des visiteursGéolocaliser l’adresse IP de vos visiteursIntégrer les commentaires des visiteursPrendre en compte les idées/suggestions de vos visiteursAccepter des paiements par Carte bancaire
Scoop.it!
Quand on en vient à l’interaction entre des machines informationnelles, revient toujours et systématiquement la question du “semantic gap”, qui est une façon condensée de dire : “comment deux machines peuvent-elles se comprendre sans se connaître a...
|
The old mantra build one to throw away is dangerous when applied to large scale commercial applications.
If you are writing code experimentally, you may want to rip up the function you wrote last week when you think of a better algorithm. That's fine. You may want to refactor a class to make it easier to use. That's fine, too.
But throwing away the whole program is a dangerous folly, and if Netscape actually had some adult supervision with software industry experience, they might not have shot themselves in the foot so badly.