- Refactoring
- Patterns of Enterprise Application Architecture
- Clean Code and other books by Robert C. Martin
- Domain Driven Design
- All McConnel Books (Rapid development, Code Complete, Software Estimation,…)
- The Pragmatic Programmer
- Implementing Lean Software Development
- The GoF book
- The Practical Guide to Defect Prevention
Friday, February 17, 2012
some more things working on
some more things working on
- Refactoring
- Patterns of Enterprise Application Architecture
- Clean Code and other books by Robert C. Martin
- Domain Driven Design
- All McConnel Books (Rapid development, Code Complete, Software Estimation,…)
- The Pragmatic Programmer
- Implementing Lean Software Development
- The GoF book
- The Practical Guide to Defect Prevention
Friday, February 3, 2012
Thursday, February 2, 2012
Interesting Stuff~~~!!!!
Setting "java.library.path" programmatically
When messing around with JNI, one have to set the “java.library.path” accordingly. Unfortunately the only way is to add a system property *before* the application is started:
java -Djava.library.path=/path/to/libs
Changing the system property later doesn’t have any effect, since the property is evaluated very early and cached.
But the guys over at jdic discovered a way how to work around it. It is a little bit dirty – but hey, those hacks are the reason we all love Java…
System.setProperty( "java.library.path", "/path/to/libs" );Field fieldSysPath = ClassLoader.class.getDeclaredField( "sys_paths" );fieldSysPath.setAccessible( true );fieldSysPath.set( null, null );
Explanation
At first the system property is updated with the new value. This might be a relative path – or maybe you want to create that path dynamically.
The Classloader has a static field (sys_paths) that contains the paths. If that field is set to null, it is initialized automatically. Therefore forcing that field to null will result into the reevaluation of the library path as soon as loadLibrary() is called…
Tuesday, January 31, 2012
interviewing – knowledge vs experience vs skill
When trying to explain the difference between knowledge and experience, I heard someone jokingly mention a formula between the two. While there isn’t really a formula (at least as far as I know), his point is still important. When interviewing, knowledge, experience and skill all come into play. Let’s look at the differences.
Knowledge
- Questions: Do you know how to do what needs to be done? Do you know where to find out?
- Example: Do you know how to read in a file so you can go through it and look for data?
- Why it matters: While technology changes fast, the ability to find knowledge quickly, is an asset. And caching it in your head or knowing what to look for in the API makes things faster.
- Where it is on the resume: list of technologies. Which tends to be buzzwords over depth. After all, if you list “Spring”, you could have just heard of it or be an expert.
Skill
- Questions: Do you know how to identify what needs to be done?
- Example: Do you realize using scanner with a regular expression can make the problem trivial?
- Why it matters: Solving the right problem is what makes development part art (and not all science.)
- Where it is on the resume: Sometimes shows up in the form of on the job accomplishments, but often has to be determined by talking to the person.
Experience
- Questions: Have you done something similar? What worked? What didn’t?
- Example: Do you identify this is the wrong problem to be solving and a better one would be to ….?
- Why it matters: Who wants to repeat the mistakes of the past!
- Where it is on the resume: In some form, it is on the resume as number of years. However, this doesn’t show what the person actually learned. I’ve met people who have managed to learn almost nothing in 7-10 years.
Why this matters at an interview
An interviewer should be interested in all three of these. (Plus potential, fit and many other things.). Everyone has some experience. If you are entry level, it might have come from school or a toy project.
What do you think?
