Hibernate Performance Tips: Dirty Collection Effect | Java Code Geeks

Why using property mapping Hibernate runs queries during commit and using field mapping are not executed? When a Transaction is committed, Hibernate execute a flush to synchronize the underlying persistent store with persistable state held in memory. When property mapping is used, Hibernate calls getter/setter methods to synchronize data, and in case of getOfficers method, it returns a dirty collection (because of unmodifiableList call). On the other side when we are using field mapping, Hibernate gets directly the field, so collection is not considered dirty and no re-creation is required.
But we have not finished yet, I suppose you are wondering why we have not removed Collections.unmodifiableList from getter, returning Hibernate collection? Yes I agree with you that we finished quickly, and change would look like @OneToMany(cascade={CascadeType.ALL}) public List<Officer> getOfficers() {officers;} but returning original collection ends up with an encapsulation problem, in fact we are broken encapsulation!. We could add to mutable list anything we like; we could apply uncontrolled changes to the internal state of an object.
Using an unmodifiableList is an approach to use to avoid breaking encapsulation, but of course we could have used different accessors for public access and hibernate access, and not calling Collections.unmodifiableList method.
Considering what we have seen today, I suggest you to use always field annotations instead of property mapping, we are going to save from a plenty of surprises.
Hope you have found this post useful.
via Hibernate Performance Tips: Dirty Collection Effect | Java Code Geeks.

Props to the Google Reader and Google Plus team

I track myself a lot and over the past few weeks since the redesign of google reader I’ve been using it considerably less. I really enjoy sharin stuff with my google reader friends and I read a lot of diverse things turning off the social features were a real bummer.
But old habits die hard. I was pleasantly surprised how well sharing to google plus from google reader is, save from the fact that a modal dialog popup is really not my thing using the old keyboard shortcut for sharing that has been imprinted to my muscle memory allowed me to discover this “new” feature almost by instinct. The integration with google plus also allows me to share stuff I know people from specific circles I have would be interested in. Wow, I really was beginning to think that the google social stuff are beginning to lead google towards irrelevancy but it seems that they actually knew what they were doing. If this goes on and facebook continues to impede fuck up my stream, I might just have to delete it and just say to people I don’t have a facebook account, find me in google plus!!!!!

Passion Versus Professionalism :: Gamasutra – Features – The Designer's Notebook:

They’re not mutually exclusive qualities, of course. One of the best examples of passion combined with professionalism was Vincent Van Gogh. There’s a lot of shallow psychoanalyzing about Van Gogh — “his paintings are so distinctive because he was mad,” and so forth.
But Van Gogh was no naïve artist operating on raw talent and passion alone. If you read his letters, you discover that he was a well-educated scholar of art, much influenced by the ideas of others.
His passion kept him going when nobody would buy his works, but it was his professionalism — his endless desire to learn more and do better, that exploited his talent to its fullest. Van Gogh’s early works didn’t amount to much. It was his growth as a serious, thoughtful, professional artist that turned him into what he became.
In fact, his bouts of madness had nothing to do with it; they disturbed his thinking and prevented him from painting. If anything, his work is all the more impressive because he was able to do it in spite of, not because of, his illness.
It’s time for a moratorium on recruitment ads that demand passion. It sounds cool, but ultimately, it’s meaningless except as an excuse for demanding long hours and offering poor benefits. By itself, it’s not much use to development companies, either.
Passion is no guarantee of talent or even basic competence. Ability, pride, discipline, integrity, dedication, organization, communication, and social skills are much more useful to an employer than passion is. And they’re more useful to you, too.
via Gamasutra – Features – The Designer’s Notebook: Passion Versus Professionalism.

Elink Video :: Ed Catmull, Pixar: Keep Your Crises Small


Ed Catmull
– Constant review.
– It must be safe for people to tell the truth.
– Communication must not mirror the organizational heirarchy.
– People  and how they function are more important than ideas. (Give a great idea to a mediocre group and they’ll mess it up, Give a mediocre idea to a great group and they’ll make something from it.)
– Don’t let mistakes mask problems., Do a deep assessment.
 

On Refactoring

Inspired by this post
I was recently handed the responsibility to maintain/fix the code of my officemate who has already left for greener pastures. Its my first day with the code so I did a 2-3 hour refactoring session with around 4k LOC.
I finished trudging through 1k LOC , and would probably be finished with the rest of the code if my team lead didn’t tell me to fix a critical bug (on the code I was refactoring).
Note One: I haven’t been told that the code was my responsibility but I have a sixth sense for things like this, so I faced the hurdle head on.
Note Two: Writing Unit tests before refactoring, trust me on this, You know that feeling you have before an operation, well that’s how you feel before and , while and after you are testing your code. No matter what you do you have that fear that maybe you didn’t do it right. So just write the test. Just do this for your sake.
I saw a few readily fixed errors around 10 and about 4 errors that took me awhile to understand and eventually fixed.
Around 2 hours after lunch we had a quick meeting because of the critical bug. The bug was a show stopper and at the meeting the code/functions/pages were formally given to me with a reminder:  We need the bugs fixed today.
luckily, some of the the bugs I have already fixed and my refactoring allowed me to easily zero in on the offending code. I was able to fix it in less than 30 minutes.
After two hours, my team lead comes to me and ask warily,
“When are you going to finish fixing the bug?”
“Its Already fixed”
“The bug? you sure?”
“yep”
The face of my team lead of disbelief/suspicion/slight admiration was priceless.
This was all due to refactoring!

Refactoring And Maintaining Other People's Code

I’ve been feeling the pain of other developers right now. Maintaining and actually changing other people’s code.
I have a couple of thorns in my side.
1. I’ve been using C# for almost two months now. Although I can already say that I a already have above average skill in C# I’ve had difficulty with mainly lack of familiarity of a lot of shorcuts and the best ways of doing things.
2. I am maintaining and at the same time creating a lot of the code. I feel like I am piling mistake upon mistake. I don’t blame the previous programmer, I must confess that I am slowly rewriting a lot of the code, not for dogmatic reasons, purely to make the code cleaner.
3. How Do You Do Unit Test with C#. This is my primary fear right now, If I cant design proper test units, I don’t know how I’ll survive testing this!
I’ll add more as I encounter more difficulty!