Thursday, April 28, 2011

Yesterday I have VERY STUPIDLY tried to install a dodgy JPEG editor downloaded from some dodgy site..... (IDIOT ME!)....
I was counting on my registered AVG antivirus to protect me....
the malware pierced AVG like a hot knife the butter.

Here the consequences:

- My Web Search plugin installed on IE and Firefox
- every browser was using as a proxy 127.0.0.1:57152 (even if you removet it, every 5 seconds it's set again)
- a fake DWM.EXE * 32 process was being spawned every 5 seconds, even if I killed the whole process tree it comes back
- a fake CSRSS.EXE * 32 as above
- a fake CONHOST.EXE as above
- a fake SVCHOST.EXE as above

(in your task manager, processes, right click on the process and use "locate folder" to identify if the EXE is in c:\Windows\System32 or somewhere else.

I bought Lavasoft Ad-Aware, with runtime protection: it could identify that something dodgy was going on, but could not eradicate it completely.

I also run MalwareBytes anti malware, which identified some stuff.

Finally I killed all the dodgy processes, deleted all the dodgy EXE files, cleaned up all the dodgy Registry entries (see here http://www.threatexpert.com/report.aspx?md5=9d94b6111ce550c0e999d2deba07b018 for a non exhaustive list), and now everything SEEMS to be back to normal. Here a good description of this Trojan.

I am really amazed how easily Windows 7 64 Bit Security is pierced.

I will immediately resize my partition, install Ubuntu and use Windows 7 only if really needed.

Monday, April 25, 2011

"CowboyThe Cowboy sees Agile as an opportunity to abandon processes and documentation so that they can enjoy the wild west life. Cowboys are the type of folks who are not necessarily negative about Agile because, in many cases, they know that they get away with pretending to be Agile since many folks, particularly the bandwagon crowd who are their up-line management, really have no idea what Agile is. It is the cowboy that has propagated the myth that Agile is an undisciplined approach for wild-west coders. "

I really appreciate this definition. I had to work in a team whose lead was as undisciplined as Billy the Kid, striving on the general ignorance about what "Agile" entails. He would always say "Agile abolishes the need of analysis, through the delivery of quick throwaway code". He lead my team to chaos and exhaustion - before management realized he was just a manipulative Rasputin.

In 15 years of development, I have rarely seen people actually adopt pair programming the "hard way", that is having one person sitting next to the other without using a keyboard. Much more popular is "help on demand", if you need me just call me.

I think there are several reasons why Pair Programming is not so popular.

- developers are mostly a bit individualistic

- most code is "easy" enough to require not so much brain effort behind it

- nobody likes to work with a jerk, so if one of the 2 developers is a jerk the experience of working shoulder-to-shoulder will be painful

- cultural reasons might encourage isolation rather than open communication

For instance, I normally ask a lot of questions to my collegaues, bringing up issues and sharing my findings. But in some contexts you are supposed to keep your head down and just deliver what you have been requested. In these contexts, PP will never find easy adoption.

Wednesday, April 20, 2011

Most Java code is simply a fist in the eye... too much rumor... I want to improve readability of the code by using tricks like "import static" and operations (setters) which return the object itself on which the operation was invoked, so you can chain multiple operations on the same line.

a) constraints are ENORMOUSLY valuable as a part of the Business Rules enforcement

b) they are normally understated in the code and scattered everywhere (XSD, SQL Constraints, Java Code...)

c) constraint exercising is normally not enough covered by Unit Tests

d) DbC testing as exercised by the Unit Tests is not guaranteed to be active in production, hence it doesn't give us the benefit of validations in real life environment.
Why Unit Test should explicitly code logic which belongs to the Business Domain? These Rules/Constraints should be incorporated in the Business Logic (vs the test logic).... the test logic should be reduced to setting up scenarios which exercise those rules, and let the rules fail themselves.

Here http://c4j.sourceforge.net/ a nice and simple example of DbC in Java (most links are broken though :o( ).
It shows clearly what a pre_condition, post_condition and invariant is.

It's lovely how it liquidates the Ant vs Maven endless religion war as a "rant over dead technologies".
I absolutely share the same point of view. Let's focus on the future and forget the XML-mistakes of the past.

I assume that with the same logic one should also be against specialists in anestetics, in liver surgery, in kidneys surgery, in brain surgery etc and have only one general "do-all" category of surgeons in a hospital.

Someone will scream "ah no but surgery is different". Please explain how - apart that a mistake in surgery costs a human life, while a wrong build process is simply a project which is not delivered on time.

Knowledge is infinite and specialization is surely an evil, but an unavoidable evil. He who believes that everybody should be able to do everything is, evidently, living in an Ivory Tower.

don't even think of manually producing separate views of - basically - the same thing.

These views are:

- the UML class diagrams
- the JPA Entity models
- the DDL to create the tables backing the Entities
- the SQL Insert statements to generate reference/test data
- the XML datasets to populate the DB fefore each Unit Test
- the XML datasets to assert the content DB after each Unit Test

If you do all this by hand, I can guarantee you will waste a lot of time and energies at each minor refactoring. Mainly because things which are loosely or not connected at all (XML, SQL...) break silently and most of the time you will find the problem only runtime.

this is an application where each layer has been generated painfully and manually by a herd of monkeys

this is an application where all artifacts have been generated from a single repository

Design time validation is a LOT better than Runtime validation, so....

Build only ONE metamodel - if you dare you can be Java Entities with JPA annotations, but I am not 100% sure this will cover all your needs.
Otherwise build your own metamodel and use it to generate all the rest.

Datasets (INSERT ox FlatXML) can be generated by hand coded Entities. The advantage is that when the model changes, Entities break and you just have to follow the red in Eclipse.

Wednesday, April 6, 2011

We are moving away from an Anemic Data Model (the Entity contains only data; the Logic to validate/manipulate/cross join this data is in the EJB Service)
towards a Rich Data Model (Entities contain most logic, entity methods are allowed to retrieve data from related entities).

This is more in line with good OO practices (mostly encapsulation), and it avoids have a lot of imperative code in the Service Layer. It improves, of course, code reusability, since the logic is one layer down the Service layer - so you avoid cross-services calls.

The only drawback is that Entities become more Service-like, sometimes they need to make DAO or EJB calls to retrieve extra information - its very difficult to expect an Entity to stay as a pure POJO without any access to Resources.

Tuesday, April 5, 2011

org.hibernate.LazyInitializationException: failed to lazily initialize a collection of role: acme.domain.model.Bla.mumbles, no session or session was closed
at org.hibernate.collection.AbstractPersistentCollection.throwLazyInitializationException(AbstractPersistentCollection.java:358)
at org.hibernate.collection.AbstractPersistentCollection.throwLazyInitializationExceptionIfNotConnected(AbstractPersistentCollection.java:350)
at org.hibernate.collection.AbstractPersistentCollection.initialize(AbstractPersistentCollection.java:343)
at org.hibernate.collection.AbstractPersistentCollection.read(AbstractPersistentCollection.java:86)
at org.hibernate.collection.PersistentSet.iterator(PersistentSet.java:163)

If in your client layer you try to do a bla.getMumbles(), you get the exception LazyInitializationException. The session was closed in the EJB, and in the client you have only a detached entity.
To avoid the problem, in the EJB do a

Monday, April 4, 2011

I am not in love with the book as I find it really verbose, it doesn't really catch my attention.

Anyway at page 216 they refer to ROA. The wikipedia article is very clarifying, the guidelines express the essence of the REST approach.
- stick all what you can in a URI
- documents should contain links (URIs) to related documents
- everything should be stateless

They talk a lot about "REPRESENTATION".
The table "RESTful Web Service HTTP methods" clearly shows what GET PUT POST and DELETE are supposed to do.

As usual, I keep thinking that all these technologies are simply CRAP, and that CORBA 20 years ago was doing much better than this. If you find a technology good only because anybody can write a URL in a browser and get a result, and you want to base on that your enterprise architecture, then good luck.