Paul Croarkin

Ranch Hand
+ Follow
since Sep 30, 2004
Merit badge: grant badges
For More
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Paul Croarkin

Most of the work in my area is Government contracting. We have Scrum certification trainers come in and get a bunch of folks certified, but when you ask them real world questions they always answer "You aren't really doing Scrum". When you ask them who is really doing Scrum they answer "Spotifiy".

Going back to XP, most agile books assume that you are working on a utopian project where everyone has good will, the customer is not trying to pressure you to "do more with less", the project lasts forever, competitors aren't trying to take your work away from you.

What is the best way to be Agile in a Govt contracting situation?
Thank you, Tomek, I look forward to reading this book.
10 years ago
Thank you, Tomek. It is useful to think in these terms, even if most people are going to use the blanket term 'mock' for all of them.

My guess is that, using your definitions, there are more 'fakes' and 'stubs' out there in the wild than there are 'mocks' even though most people probably call them 'mocks'. I hadn't heard the term 'saboteur' before, but I do use them frequently.


10 years ago

I've seen the following terms tossed around: mock, dummy, fake, stub. Do you think it is useful to delineate between these and, if so, how would you describe the differences?
10 years ago
Key Responsibilities:
•Implement enterprise systems in J2EE
•Participate in the software development process including application design and software coding.
•Interact closely with customers, other developers, requirements analysts, testers, and operations staff
•Create design documents using UML
•Unit test application code
•Estimate Levels of Effort (LOEs)
•Problem solving / troubleshooting

Basic Qualifications:
•BS degree in Computer Science or related field
•5+ years of software development experience (a minimum of 3 in J2EE)
•J2EE architecture framework, conceptual design, complex detail design, and software development skills
Preferred Skills/Experience:
•Excellent core Java skills
•Object-oriented analysis & design
•Understanding of Design Patterns (GoF and Enterprise Java)
•Hands on experience with JSP, JSP Tag, Struts, HTML, XML, Servlet, EJB and JDBC
•Understanding on general persistence technologies including EJB 3 and ORM technologies.
•Knowledge of Java 5 (JDK 1.5).
•Experiences with Java IDEs - Eclipse, WASD, etc., and J2EE containers such as OC4J, Weblogic, WebSphere.
•Experience with Servlet containers such as Tomcat
•Experience with open source frameworks such as Spring, JUnit, Hibernate.
•Relational database knowledge (Oracle) and SQL.

Professional Skills:
•Ability to identify, analyze, and solve problems creatively and independently
•Ability to handle multiple tasks simultaneously and shift priorities as directed
•Able to work in fast paced environment with efficient team members

Please apply online:
Search for position number 1000000904
12 years ago
As pointed out above, you need to know what is really meant by "single per application" due to multiple JVMs, etc

However, given one JVM, there is a simple way to safely construct only one copy of the object.

- make the constructor private
- instantiate the object at class load time

Note: this only ensures that one copy is created in a particular JVM. There can be other concurrency issues associated with publishing the object.
Congratulations everyone.

I'm putting Clean Code on my "to buy" list.
My approach to Exception handling is keep throwing until it can be handled. Most low-level exceptions cannot be handled directly by the code.

A good rule is to catch exceptions anytime an actor makes an action.

For instance, in a Web app where the user uploads a file path that does not exist, the proper thing is to tell the user that the file path does not exist. What value does the user get from the program catching some IOException (or worse swallowing it) way down in the code. They want to know what they did wrong or what the system did wrong and how to get around it.

A web service could be an actor and you may be expecting an XML file to come down the wire and it does not parse against the DTD or schema. Log it to an error file (or table) and possibly send an alert (email or page) to the production support team. Also be sure that the response you send back explains the error. Also make sure that you rollback any transactions.

[ September 23, 2008: Message edited by: Paul Croarkin ]
[ September 23, 2008: Message edited by: Paul Croarkin ]
I agree with Ilja. Re-factoring to smaller methods makes code much more readable. Of course comments should be included for things that will be difficult for a future maintainer to understand.

I lump comments in with other artifacts. Generate as few artifacts as are needed to get the job done in a professional manner.

Setter / Getter comments are almost always a compete waste of time. But a comment that explains some difficult mathematical equation is always appreciated. I think that after you have coded every day for years, you get a pretty good feeling as to what is necessary.
Be careful with a name like that unless you can back it up (with tests) to prove that it is ThreadSafe.

Yes, overuse of inheritance can be a bad design, but I don't see how that excuses not using DRY. Maybe interfaces should have been used instead and / or composition.

Also, I do not see how violating DRY would help you with your serialization issue. It sounds like the classes in question did not properly implement Serializable.

If I ran across an issue like that, the first thing I would do is write some tests to serialize and de-serialize the objects. Tests would also be constructed to make sure that the existing production functionality worked. After that, re-factoring.
[ September 23, 2008: Message edited by: Paul Croarkin ]
You should never be afraid of future changes or refactoring. Adding an editable flag on the detail page does not seem like a big deal to me and it does not violate DRY.
I don't follow how repeating yourself would have made this a more manageable project. I've found that cut-and-paste coding (i.e. repeating yourself) almost always leads to maintenance nightmares.
Do you consider code to be complete if it lacks Javadoc? I've been on projects where code reviewers will ding people for not having Javadoc. The more I code though, the more I think that most of the time writing Javadoc is just a waste of time. Of course, it is very useful for frameworks, but I think most code is written not for frameworks, but to accomplish some business need. Self-documenting method names seem to add much more value.
How would you compare Clean Code to Steve McConnell's Code Complete?