martes, 28 de diciembre de 2010

Tunning your Checkstyle and Formatter

Content:
CheckStyle Eclipse plugin. Installation
Tunning your CheckStyle and Formatter
Every programmer working as only one
What if... I get a "Fileset from project [projectname] has no valid check configuration" Error?
CheckStyle configuration distribution

In the previous post, we installed Checkstyle and tested it a bit, a little proof-of-concept, useful for your little project at home, it doesn't cares anybody, and the world could survive without it perfectly.

Now focus on your company, it is unforgivable that every mate format their code as Sant Peter tells them. You implanted CheckStyle code in your I.T. dept. and it looks like better, but Sun style (default one for Formatter and CheckStyle) doesn't fit your interests.

One example. Your monitor is 1280 pixels wide, but Formatter defaults to 80 columns of text, and you find it miserable for your hardware, that supports much more, at least 120 columns.

Let's build this example, a comment of 143 columns length.



As soon as you invoke Formatter (Ctrl+Shift+F or Menu Source->Format), the result is next:


The comment line was broken at column 79, but I spent a large amount of money in a extreme-wide monitor and I find that length ridiculous. I better change this parameter.

Check your configuration in  Window menu -> Preferences -> Java -> Code Style -> Formatter. The best you can do in this point is create your own profile, based on an existent one. 

I chose New ... and type anavarro_prof, based on "Java Convention [built-in]"


Then, edit your new profile, as a sample, we will change line width...


 and comment width...



Once both parameters are changed, let's suppose your project is using the IDE default formatter, so, your formatter, that have been chosen as default one after its creation.

Return to your code, re-format it! it works! it has been formatted to 120 lines width.




Did it work? not completely... see that magnifying glass that appeared at the left side of your comment...




Line is longer than 80 characters?. What's up?
This is happening because your Formatter is not directly connected with your CheckStyle plugin, so you will have to transmit your Formatter changes into your CheckStyle configuration.


Open Window Menu -> Preferences -> CheckStyle. 

You should find the two built-in configurations, but you want to configure your own. 





So firstly select one of them, click "Copy" to create a configuration based on an already created one.



And change some parameters, as the type, make it external, change that ugly name and select a location where the new configuration will be created. I lend you an example:




Then, clicking "OK", your new configuration will be created and you can both "Set as Default" and "Configure". Yes, please, "Configure" it.


Search for "Maximum Line Length", and EDIT existent "Maximum Line Length" in the window on the right. Beware don't add an additional property already existent, because you won't get the desired goal.


Then change its maximum length doubleclicking it:




Save, Ok, Rebuild, do whatever neccesary to get your code window again, magnifying glass should dessapear after recompiling. Mine does! You have also got an external CheckStyle configurer as a xml file where you asked to. This file will be transferred to your mates in next chapter.


Quite a long article, you should have learned to customize your Formatter and make your CheckStyle configuration being Formatter-compliant. You can now impose both configurations to your entire team, in the next article, promise.


Have a happy New Year's Eve!!!

miércoles, 22 de diciembre de 2010

CheckStyle Eclipse plugin. Installation

Content:
CheckStyle Eclipse plugin. Installation
Tunning your CheckStyle and Formatter
Every programmer working as only one
What if... I get a "Fileset from project [projectname] has no valid check configuration" Error?
CheckStyle configuration distribution


In the lollipop world, your code and my code are completely equal, it is also well formatted, well documented and optimized for every executer machine. In that world, bugs does not exist, clients only do what they are supposed to do and the big boss never downplays your suggestions.

In a perfect world, your code and mine differs but not so much, your cat never walk over your keyboard and your pretty workmate is in love for you.

In this very real world, the stupid mate will not format a line correctly unless Damocles insert his sword in his back-door, clients bring up over your user manual and, probably, over the inexistent specification. Ups, I almost forget it, your ugly workmate is sexually harassing you.


In order to pacify this war field, the first tool I bring to you is CheckStyle Eclipse Plugin.


Description from its webpage: Checkstyle is a development tool to help programmers write Java code that adheres to a coding standard. It automates the process of checking Java code to spare humans of this boring (but important) task. This makes it ideal for projects that want to enforce a coding standard.

The installation is quite easy, as said here, in your Eclipse/SpringSource just

1. In Eclipse go to Help->Software Updates...

2. Add a new installation site and providehttp://eclipse-cs.sf.net/update/ as location URL.

3. Mark the plugin version you would like to install, as well as future optional features, then press Install...

4. Review and confirm the plugins to install

5. Restart Eclipse




Afterwards, right click over your project -> CheckStyle -> Activate CheckStyle. Then you might find something like this:




You are able to see my best code ;) (I am sorry for Spanish description).

A bit summary of warnings in the code window:

-Javadoc is missing
-Missing package-info java file
-Comment is like to-do comment
- { should be in previous line
...
among others.


Firstly, with a Source -> Format (Ctrl + Shift + F) we will keep aesthetic warnings low.

I pass from 34 to 26 warnings, check how "{" have been moved and now they pass CheckStyle filter.

The Formatter and the Checkstyle Plugin must be synchronized, otherwise every formatting you do, and you should delegate format in tools like this, you will gain CheckStyle warnings in an endless war.

Benefits for a single programmers are limited, but benefits for a entire team that must work together are incalculable. If not this, tools like CheckStyle (and an automatic code formatter) are obligatory in every development department.


An article about Tunning CheckStyle in the oven...

domingo, 19 de diciembre de 2010

Roll your own Continuous Integration System (C.I.S.): Abstract.

Roll your own Continuous Integration System (C.I.S.)


Content:
Abstract
Install Tomcat
Basic Tomcat configuration - Memory
Basic Tomcat configuration - JMX
Basic Tomcat configuration - Application Manager and permissions
Apache and uSVN 
Installing Artifactory from WAR
Configure Artifactory and MySQL
Configuring Artifactory security and repositories 

http://looking4q.blogspot.com/2011/01/roll-your-own-continuous-integration.html

This is the very first goal for the followers of this blog.

For those who doesn't know what a Continuous Integration System is, you could take a look at wikipedia, but, summarizing with an example, is a software that every night downloads your code, compiles it, executes unitary testing and deploys it in your server or in your dependency repository.

That's not all. It could pass several control checks like code style, testing code coverage, code quality, it makes a report and send it to your email, and other for the guilty developer that wrote some code that generates lots of warnings.

This information is processed for cyclic dependencies, copied&pasted code, percent of commented code, percent of tested code... reports and more reports.

Some of this reports are also postprocessed in order to evaluate each developer independently. Then it creates a dashboard with scores for each participant, trying to motivate the team for a better code.

Appealing enough?

I have selected some tools that I use in my company. This list might be modified in near future:

Code Repository: We are using Subversion
Dependencies manager: Maven
Dependencies repository: Artifactory, which understands Maven among others.
C.I.S Manager: Hudson: which understands Maven and SVN among others.
Extra: Sonar as quality of code reporter.
Extra: Wiki or CMS

And Tomcat6 as the container of everything or almost everything.

In next articles, I will try to explain how to install and deploy each tool in order to get something similar to my example in your own company or at home.

See you soon!

martes, 14 de diciembre de 2010

What if... I create a Maven web application and Tomcat doesn't see it?

Content:

Maven abstract.
Tunning your Maven proyect
Maven standard folders
Managing dependencies with Maven
Adding a nature in Eclipse
Maven profiles inheritance

It's hard for me to replay this error in my well configured computer :P, but I found something useful.

You need to add a "Dynamic Web Module" in Project "Properties" -> "Project Facets".
Then F5 and try to "Run as.. Run on Server".

If I create a Maven Web Project (maven-archetype-webapp in the second configuration window on "New Maven Project", I can read inside my .project file:


<natures>
<nature>org.eclipse.jem.workbench.JavaEMFNature</nature>
<nature>org.eclipse.wst.common.modulecore.ModuleCoreNature</nature>
<nature>org.eclipse.jdt.core.javanature</nature> 
<nature>org.eclipse.wst.common.project.facet.core.nature</nature>
<nature>org.maven.ide.eclipse.maven2Nature</nature>
<nature>org.eclipse.wst.jsdt.core.jsNature</nature>
</natures>


As said in this web, if I delete the bold line, the option of running on server dissappears, so, it could be a nice clue.

If I try to read active facets in the "Project Facets" property page, I find this:

"This project is not configured to use project facets. Converting this project to faceted form will allow you to easily control the available technologies."

If I accept its proposal, then the bold line reappears! Mmmmm, interesting, isn't it?

That information is coded in ".settings/org.eclipse.wst.common.project.facet.core.xml"

Face and Unface "Dynamic Web Module" and check that file out to find how it works.


Have a nice day   :)

Basic Artifactory installation

On Un*x:

http://wiki.jfrog.org/confluence/display/RTF/Installing+on+Un*x

On Windows (I really like this one)

http://www.theserverside.com/news/1364121/Setting-Up-a-Maven-Repository

viernes, 10 de diciembre de 2010

Managing dependencies with Maven

Content:

Maven abstract.
Tunning your Maven proyect
Maven standard folders
Managing dependencies with Maven
Adding a nature in Eclipse
Maven profiles inheritance

How does Maven work?

Maven uses repositories for searching any dependency you declare in POM.xml, there are strictly only two types of repositories: local and remote.

The local repository (today's theme) refers to a copy on your own installation that is a cache of the remote downloads, and also contains the temporary build artifacts that you have not yet released. (As said in Maven website).

When working with Eclipse, there are two levels for local repositories. Maven builds one repository over your workspace, therefore, if you have any dependency loaded as project in your workspace, it will be taken previous to any other equally-versioned jar.

The second level for local repositories is your personal space in disk. Maven automatically configures a repository inside your user directory (.m2 for Maven 2), and it is used for synchronizing all your projects, Eclipsoid or not.

In the higher step of this ladder, remote repositories. They could be a server in our own intranet, or one of the mirrors proposed by Maven for downloading its huge library.


Let's do a practice example:

Step one: Creation of secundary project.

Open an instance of SpringSource, configure it for working in the brand-new workspace "workspace_a". It doesn't matter the real path, it only matters that it is new and clean.

Create a "Maven Project",







































We have reached the next window using only the "Windows Brain" (next.. next.. next..), until we are prompted for a "Group Id", "Artifact Id" and "Version".

Group Id: Sort of organizational name or hierarchy. It is a good idea that use your domain for all your packets, it could be at the same time your namespace and a good clue for where to locate more of your business.

Artifact Id: Name for this package.

Version: Initial version. SNAPSHOT tells Maven to look for more recent versions in their configured repositories. 






















If an App.java was created, we wont need anymore for this part of the example.

Try to Run as.. Maven Install.

With this command, you are telling Maven to compile, run tests, and, if succeeded, deploy in local Maven repository to share with other projects.

Now close your SpringSource IDE if you can't afford having two IDEs opened.


Step two: Creation of main project.

Let's do it quickly and painless. As we did in other article, New Project -> Spring Template -> MVC Spring Project (or something similar, I'm not reading it right now :P). I call it "war", why not.














We won't run this new project, because we don't need to. What we only want is being able to compile the code.

Write an import sentence with wildcard like the example, and use one inexistent class like me. God kills kittens for less than this.

Run As -> Maven Install

10/12/10 23:07:14 CET: [ERROR] The import es cannot be resolved
10/12/10 23:07:14 CET: [ERROR] UtilsA cannot be resolved to a type
10/12/10 23:07:14 CET: Build errors for war; org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.codehaus.mojo:aspectj-maven-plugin:1.2:compile (default) on project a: Compiler errors :
error at import es.anavarro.util.*;
       ^
/home/anavarro/Documents/workspace a/war/src/main/java/a/a/a/HomeController.java:10:0::0 The import es cannot be resolved
error at UtilsA a;
^^^^
/home/anavarro/Documents/workspace a/war/src/main/java/a/a/a/HomeController.java:20:0::0 UtilsA cannot be resolved to a type

Now type this in your pom.xml (inside <dependencies> tag, create it if it doesn't exist yet).


<dependency>
    <groupId>es.anavarro</groupId>
    <artifactId>util</artifactId>
    <version>0.0.1-SNAPSHOT</version>
</dependency>

Of course, adapt it to your step-one project. Rebuild the project, if everything went ok, Maven found the dependency and resolved the "import" error.

10/12/10 23:10:30 CET: Refreshing [/war/pom.xml]
10/12/10 23:10:30 CET: [INFO] snapshot es.anavarro:util:0.0.1-SNAPSHOT: checking for updates from org.springframework.maven.snapshot
10/12/10 23:10:44 CET: Maven Builder: AUTO_BUILD 

The other error is damn logical, that class doesn't exist in util project. Let's create it, one blank "UtilsA" class, in its workspace and project, then Run as -> Maven Install. A new version will be deployed in our local repository, with the same name and version, but (invisible to the user) with a newer timestamp.





















Once your "util" project is done, return to the main project, rebuild it, Maven should download your last version, find your "UtilsA" and be able to compile it all. If it doesn't compile by Eclipse build, try Maven Install, it's the important one, and forces checking and download of dependences.

That is the base of Maven approach, easy to version projects and libraries, easy to collaborate, easy to use.


See you on @anavarro_prof

martes, 7 de diciembre de 2010

Maven Essentials: standard folders.

Content:

Maven abstract.
Tunning your Maven proyect
Maven standard folders
Managing dependencies with Maven
Adding a nature in Eclipse
Maven profiles inheritance

Directly from Maven documentation entry, short and concise.


Introduction to the Standard Directory Layout

Having a common directory layout would allow for users familiar with one Maven project to immediately feel at home in another Maven project. The advantages are analogous to adopting a site-wide look-and-feel.

The next section documents the directory layout expected by Maven and the directory layout created by Maven. Please try to conform to this structure as much as possible; however, if you can't these settings can be overridden via the project descriptor.

src/main/java Application/Library sources
src/main/resources Application/Library resources
src/main/filters Resource filter files
src/main/assembly Assembly descriptors
src/main/config Configuration files
src/main/webapp Web application sources
src/test/java Test sources
src/test/resources Test resources
src/test/filters Test resource filter files
src/site Site
LICENSE.txt Project's license
NOTICE.txt Notices and attributions required by libraries that the project depends on
README.txt Project's readme

At the top level files descriptive of the project: a pom.xml file (and any properties, maven.xml or build.xml if using Ant). In addition, there are textual documents meant for the user to be able to read immediately on receiving the source: README.txt, LICENSE.txt, etc.

There are just two subdirectories of this structure: src and target. The only other directories that would be expected here are metadata like CVS or .svn, and any subprojects in a multiproject build (each of which would be laid out as above).

The target directory is used to house all output of the build.
The src directory contains all of the source material for building the project, its site and so on. It contains a subdirectory for each type: main for the main build artifact, test for the unit test code and resources, site and so on.

Within artifact producing source directories (ie. main and test), there is one directory for the language java (under which the normal package hierarchy exists), and one for resources (the structure which is copied to the target classpath given the default resource definition).

If there are other contributing sources to the artifact build, they would be under other subdirectories: for example src/main/antlr would contain Antlr grammar definition files.

lunes, 6 de diciembre de 2010

Tunning your Maven project

Content:

Maven abstract.
Tunning your Maven proyect
Maven standard folders
Managing dependencies with Maven
Adding a nature in Eclipse
Maven profiles inheritance

Now let's suppose you want to build a new Maven project in SpringSource,

New Project -> Other -> Maven project.

You already know about the benefits of a Maven project and you want to roll your own like a library, without Spring dependencies.

As soon as you have created your project, you notice that your project doesn't have any resource folder as source folder. They doesn't exist in the folder hierarchy either. But you need those folder for Unit Testing (that is something that will be explained afterwards).


Round one, fight!

As a Eclipse user, the first you think is you may create those folders manually- Create a "resources" folder inside "main", and another "resources" inside "test", then register them as "source folders" in Properties -> Java Build Path -> Source -> Add Folder. By selecting the new folders you may access resource files throw classpath.

It's important to sort the order of folders in Order and Export tab, put your main/resources above your test/resources entry.

Now create three files, "a.xml" in "main/resources", a different copy of "a.xml" in "test/resources" and finally one "b.xml" in "test/resources".

Try it please. Then Run As -> Maven Install and you will get a jar file in your target project directory. Unzip your jar, you should find an "a.xml" with the content of "main/resources" and "b.xml".

What did it happened?

Maven will export every file in "source folders", compiled or not, that's the reason of the undesired existence of "b.xml". We shouldn't export our testing data!
If Maven finds two or more files with the same name, it is chosen by classpath priority, so it is important to tune it well in "Order and Export" tab.

Nevertheless, we don't find the result appropriate, because we don't want to export our testing data.

Take a look to your "Order and Export" tab, you can't uncheck your "Source folders" for exporting (the box at the right of the entry), so, this isn't a good solution.


Round two, fight!

Please delete both entries from "Source folders" in Properties -> Java Build Path.

Now go to "Libraries" tab in the same dialog. "Add class folder" and check your main and test "resource" folders.

Is it the same than before? no. Because now you can drift to your "Order and Export" tab and check your "main/resources" folder for exporting, and not the same for "test/resources" one.

Run As -> Maven Install. Unzip your Jar and see how magically you haven't exported your testing resources. :) Terrific.

DELETE your project, without deleting sources or resources. Only the project from your workspace. Reimport it like a "Existing Maven Project" and... Ops, you have lost all your classpath configuration. Yes, you can reimport like a Simple Project as well, but have now experienced what will happen when any of your workmates download your project from any cvs/svn/other repository.

Take a look to your ".classpath" file, there you have all your configuration. But this file won't be uploaded to the repository, and therefore, no mate will be able to export this library correctly.

You have draft this round too ;)


Round 3, fight!

By losing your second round, you must have noticed that you can't win this battle by using local classpath files. Indeed, you won't never export it to the repository, so the solution must be as exportable as functional.

Take a look to your "Java Build Path" again, 

Let's take a look to your pom.xml file. It's quite clean, isn't it? Let's take a look to the "Super POM.xml" from Maven.

See the build entry:

<build>
    <directory>target</directory>
    <outputDirectory>target/classes</outputDirectory>
    <finalName>${artifactId}-${version}</finalName>
    <testOutputDirectory>target/test-classes</testOutputDirectory>
    <sourceDirectory>src/main/java</sourceDirectory>
    <scriptSourceDirectory>src/main/scripts</scriptSourceDirectory>
    <testSourceDirectory>src/test/java</testSourceDirectory>
    <resources>
      <resource>
        <directory>src/main/resources</directory>
      </resource>
    </resources>
    <testResources>
      <testResource>
        <directory>src/test/resources</directory>
      </testResource>
    </testResources>
  </build>


Quite appealing, I will take it as is and drop it in my "pom.xml". Delete and reimport as Maven project.

That is what you will find:
.classpath independent, the information is in your "pom.xml" file.
Files under "testResource" member of "pom.xml" file won't be exported
Appropiate for sharing throw control version repositories, every mate will build the project correctly.


Epilogue

Now clean every fingerprint from this project, create a new one, create the same folders, the same files inside:

src/main/resources
a.xml

src/test/resources
a.xml (different)
b.xml

Delete the project, reimport it like a Maven one again... yes, Maven did it for you.

Those are the standard folders for a Maven project, and, by being standard, as far as you name your folder so, you won't have to configure they as testResource folders, and their content won't be ever exported.

You are 20% smarter than your mates, you woooon! :)


I will check my horrible English tomorrow. Enjoy this article as much as I enjoyed writing it.

domingo, 5 de diciembre de 2010

Maven

Content:

Maven abstract.
Tunning your Maven proyect
Maven standard folders
Managing dependencies with Maven
Adding a nature in Eclipse
Maven profiles inheritance

Maven is one of those useful tools that I had never heard before my current job.

"Maven's primary goal is to allow a developer to comprehend the complete state of a development effort in the shortest period of time. In order to attain this goal there are several areas of concern that Maven attempts to deal with:
  • Making the build process easy
  • Providing a uniform build system
  • Providing quality project information
  • Providing guidelines for best practices development
  • Allowing transparent migration to new features"
It sounds like marketing, doesn't it? What does it mean?

- It really makes building easier: Well, I suppose it uses Ant for building, just going to the root folder, type "mvn install" and you got your compilation built. It will take any needed dependence (even Maven dependences not yet downloaded) and will compile the project using the pom.xml configuration file.

- Uniform build system: I suppose so.. The great thing is that you have all your architecture-independent configuration in one file, and it doesn't matter most of the details.

I haven't yet discovered the rest of marketing stuff in the real world, but, what makes me crazy is the dependency management.

Let's suppose I'm working in a project, and my friend J needs my project in his. He can always take my code from our repository, completed or not, it compiles or not, every release.
Certainly, he can ask me if I finished it, but is it necessary?.

Maven offers a way to synchronize throw a repository, something like uploading jars to a code repository (bad practice!). Now I can publish every version, snapshot or nigthly-build in that repository with a version number.

My contract for uploading dependences:
- Code compiles.
- Code passes unitary testing.
- Code passes other optional filters like code quality thresholds.
- New major version for backward code incompatibility.
- New minor version for new features
- Resolved bugs doesn't need additional number (if I'm wrong, I will fix this article).

Maven takes care of compiling, testing and other filters throw "mvn deploy" or "mvn install" command. This way, it makes it difficult to upload bad releases.

Every time J releases his project, Maven checks for a new release (under the same version) of my project, downloads it, compiles his project with my new version and upload his project to the repository. J doesn't even know all this :)


That's the same for Spring dependences, which came pre-configured in every Spring Maven project. You can check your pom.xml when you create a mvc project in SpringSource.

New Project -> Other -> Spring Template Project -> Spring MVC Project

Now read your pom.xml file...

My project needs spring-webmvc library with a variable version:
<dependency>
    <groupId>org.springframework</groupId>
    <artifactId>spring-webmvc</artifactId>
    <version>${org.springframework-version}</version>
</dependency>

The version I need now is:
<org.springframework.roo-version>1.0.2.RELEASE</org.springframework.roo-version>

Look for my dependencies over here, even snapshots:
<repository>
    <id>org.springframework.maven.snapshot</id>
    <name>Spring Maven Snapshot Repository</name>
    <url>http://maven.springframework.org/snapshot</url>
    <releases><enabled>false</enabled></releases>
    <snapshots><enabled>true</enabled></snapshots>
</repository>

Tune my compiler, use a variable java version:
<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-compiler-plugin</artifactId>
    <configuration>
            <source>${java-version}</source>
            <target>${java-version}</target>
    </configuration>
</plugin>

Use this version for compiling:
<java-version>1.6</java-version>

Load this library only for testing, but don't export it afterwards:
<dependency>
    <groupId>junit</groupId>
    <artifactId>junit</artifactId>
    <version>4.7</version>
    <scope>test</scope>
</dependency>

Think of "groupid" like a sort of namespace, "artifactId" like library name, "version" is what you know you need (making possible linking old libraries without caring of new features of the same library linked by other dependencies). Finally, "scope" tells Maven if we need the library for compiling, runtime, or simply testing. Testing won't be loaded in compile time, and won't be exported when it all finish.

All the configuration in a file, architecture independent, quite clean and structured. That's Maven.

That's quite a lot for today, isn't it?

sábado, 4 de diciembre de 2010

Essential readings: Pragmatic Programmer

Pragmatic Programmer
by Andrew Hunt and David Thoma. 1999.


(33$ kindle edition, 29$ paperback edition in Amazon.
Incredible, <españolada>we are all crazy</españolada>).

When I came to Barcelona in 1997, this was the first task in my first serious job. I was asked to read this book in order to understand the basis of their job, and I found it quite illuminating. I want to spread this good practice :)

In my humble point of view, this is a great compilation of good practices about programming, and simply being, as you may read below:

[From the book]
While software development is immune from almost all physical laws, entropy hits us hard. Entropy is a term from physics that refers to the amount of ``disorder’’ in a system. Unfortunately, the laws of thermodynamics guarantee that the entropy in the universe tends toward a maximum. When disorder increases in software, programmers call it ``software rot.’‘
There are many factors that can contribute to software rot. The most important one seems to be the psychology, or culture, at work on a project. Even if you are a team of one, your project’s psychology can be a very delicate thing. Despite the best laid plans and the best people, a project can still experience ruin and decay during its lifetime. Yet there are other projects that, despite enormous difficulties and constant setbacks, successfully fight nature’s tendency toward disorder and manage to come out pretty well.
What makes the difference?
In inner cities, some buildings are beautiful and clean, while others are rotting hulks. Why? Researchers in the field of crime and urban decay discovered a fascinating trigger mechanism, one that very quickly turns a clean, intact, inhabited building into a smashed and abandoned derelict .
A broken window.
One broken window, left unrepaired for any substantial length of time, instills in the inhabitants of the building a sense of abandonment—a sense that the powers that be don’t care about the building. So another window gets broken. People start littering. Graffiti appears. Serious structural damage begins. In a relatively short space of time, the building becomes damaged beyond the owner’s desire to fix it, and the sense of abandonment becomes reality.
The ``Broken Window Theory’’ has inspired police departments in New York and other major cities to crack down on the small stuff in order to keep out the big stuff. It works: keeping on top of broken windows, graffiti, and other small infractions has reduced the serious crime level.
Don’t Live with Broken Windows
Don’t leave ``broken windows’’ (bad designs, wrong decisions, or poor code) unrepaired. Fix each one as soon as it is discovered. If there is insufficient time to fix it properly, then board it up. Perhaps you can comment out the offending code, or display a “Not Implemented” message, or substitute dummy data instead. Take some action to prevent further damage and to show that you’re on top of the situation.
We’ve seen clean, functional systems deteriorate pretty quickly once windows start breaking. There are other factors that can contribute to software rot, and we’ll touch on some of them elsewhere, but neglect accelerates the rot faster than any other factor.
You may be thinking that no one has the time to go around cleaning up all the broken glass of a project. If you continue to think like that, then you’d better plan on getting a dumpster, or moving to another neighborhood. Don’t let entropy win.

From: http://pragprog.com

viernes, 3 de diciembre de 2010

Essential tools: SpringSource

What is SpringSource?

As far as I know, that is the most comfortable open-source tool for developing Spring. It is Eclipse based, so you will be able to complete your favourite IDE with other plugins like Subclipse (SVN), CheckStyle or Covertura.

SpringSource comes with Spring project templates, Maven and JUnit, so, if you want Q, it does their best for you to get it ;)

Its goals:
  • J2EE should be easier to use
  • It is best to program to interfaces, rather than classes. Spring reduces the complexity cost of using interfaces to zero.
  • JavaBeans offer a great way of configuring applications.
  • OO design is more important than any implementation technology, such as J2EE.
  • Checked exceptions are overused in Java. A platform shouldn't force you to catch exceptions you're unlikely to be able to recover from.
  • Testability is essential, and a platform such as Spring should help make your code easier to test.
Yes, they accomplish their goals, so it will be my dev tool for coming reviews, examples and articles.

Download it!
springsource.org

Welcome

Welcome!

This is my blog, my brand-new and original way to show and share my learnings and discoveries in the professional world with you, whoever you are.

The real target of this blog are my friends, those who want to learn doing programming and designing correctly. But, of course, if you are not, you are my guest too.

Thanks for your reading, you help me to keep writing.