Code Goop

Chad — Tue, 31 Jan 2012 21:45:40 +0000

Not sure why people keep pushing you must build a mobile app w/native language. We are building awesome, cross-platform stuff with Adobe AIR

ReplyRetweetFavorite

@codegoop

Chad — Thu, 24 Nov 2011 00:30:01 +0000

S. Colebourne: Scala feels like EJB 2 http://t.co/Xw1wiSzLDon't like eggs, but I don't waste time trying to convince others that eggs r bad

ReplyRetweetFavorite

@codegoop

Rocking out on some ScalaTest and trying to convince my team to use it. Loving how well it integrates with Maven and our builds.

ReplyRetweetFavorite

@codegoop

Bruce Eckel talks Scala

Chad — Mon, 11 Jul 2011 11:27:27 +0000

Back in the day, Thinking in Java by Bruce Eckel was the first real Java book I read. I was new to the language and needed lots of help. It was generally required reading for any self-respecting Java professional. The problem is, that was 11 years ago. For a stable industry, that seems like a long time. In software development, that’s ancient history. Ideas change, concepts evolve, and languages fall out of flavor. For better or for worse, change happens and it can be really fun if you embrace it. Bruce wrote a very compelling post on some of the advantages of Scala. He touched on code expressiveness, case classes, traits, functional programming, and a few other interesting concepts. It’s a great read and well worth your time. I’ve been a Scala fan for some time, but I was a fence sitter. I’d dip my toe in and if the water was too cold, I turn and run back to the safety of what I knew. It seems like there is now a critical mass behind Scala though. I’m hoping I can find a way to work it into my next project and get off the fence for good.

Scala: The Static Language that Feels Dynamic

Back from hiatus

Chad — Tue, 17 May 2011 17:23:34 +0000

I’ve been on a bit of a hiatus recently, but I should be back to posting soon. I switched projects and have been spending a lot of time cleaning up some big messes. I turned a nasty Eclipse right click/export build into something usable. We ended up with a sweet Maven/Nexus/Hudson build process. I’ve used Maven on a lot of projects and have a love-hate relationship with it. Dependency management is such a freeing experience, but I’m trying to cut down on the amount of time I spend with XML. I know Maven 3 has the ability to create poms with Groovy, but I haven’t gotten into that much. Instead, I’ve been using Gradle. It has all the advantages of dependency management without the legacy cruft. It took me a couple of days to understand what Gradle was doing and it’s still immature, but I think it has a bright future. Either way, Nexus has been the core product that has brought all of this together. Whether we are using Maven, Gradle, or Ant/Ivy, Nexus just keeps getting better and better. It’s one of those products that I find just “works”. I highly recommend it as the heart of a jvm build process. I’ve got a lot more to talk about in this space, so hopefully I can’t blog on that soon.

Scala Stuff

Chad — Thu, 14 Oct 2010 02:08:47 +0000

I’ve been trying to spend a lot of my free time hacking on Scala. I love the language. It’s had a steep learning curve for me, but I’ve really enjoyed the trip. As you get into the language, you appreciate how it’s consistency can make complicated concepts seem simple. Here are some good links that helped me get started:

Scala training slides: http://github.com/javaBin/scala-training-slides
Dick Wall’s functional koans: http://github.com/relevance/functional-koans/tree/scala
Scala for Java refugees: http://www.codecommit.com/blog/scala/roundup-scala-for-java-refugees
Java Posse Roundup 2010 – Scala discussion: http://javaposse.com/java_posse_314_roundup_10_scala

Fitting in

Chad — Wed, 18 Aug 2010 01:11:21 +0000

I had a relatively long post put together about writing code and how important it is to be consistent with your teammates. I had a few paragraphs on maintaining style, architecture, and keeping the essence of the code you’re working with. Instead of going through that, I boiled it down to a few basics that I run into often.

Keep the style consistent

If you have a corporate style, follow that. Otherwise, the Snoracle code conventions are mostly your friend. I always have to grit my teeth when someone abuses this. If the project is written in a K&R style, don’t complain when your Allman style classes get reformatted. Checkstyle does a really good job at automating this at check in time, while the major IDEs have very good formatting tools.

Maintain the architecture

If the project you’ve been asked to maintain is straight JSF, don’t slam in your favorite DI framework because that’s all you know. Take the time to look through the code and get to know it. Maintain the architecture whenever possible. When it’s your turn to decide the design, you can do it however you want. Until then, it’s helpful to stick with the groundwork that’s already present. Keeping the architecture clean is a huge advantage when it comes time for refactoring or retrofitting for missed requirements.

Follow the spirit

If a class has only 5-line methods, don’t slam in a 50-line monstrosity. When all the parameters are declared final, take note, and do the same where appropriate. If the class is immutable, don’t add javabean setters. In other words, don’t redecorate your friend’s house when you stop by for a visit. For good or bad, a lot of developers feel strongly about code they initially created. If someone else isn’t considerate of the spirit in which that code was written, feelings can fray and productivity can plummet.

Don’t break things

Before you check your code in, make sure it compiles and passes all of the unit tests. Continuous integration helps this situation, but you can save yourself embarrassment and the wrath of your coworkers by making sure things are ok before committing. If you don’t have unit tests for your stuff, now is the time to write some. No one likes a broken build, but it’s even worse when broken code ends up on your machine straight from source control. Developers have a hard enough time tracking down their own bugs. Adding to that burden and making them fix yours is not appreciated.

Addicted to final

Chad — Fri, 25 Jun 2010 02:44:36 +0000

What can I say? I’m addicted to the final keyword. My code is littered with it. A typical class can end up looking like the following:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

public class SimpleClass {

private static final Logger logger = Logger.getLogger("SimpleClass");
private final String foo;
private final List<String> bars = new ArrayList<String>();

public SimpleClass(final String foo) {
this.foo = foo;
}

public void addBar(final String bar) {
bars.add(bar);
}

public void printFooBars() {
final PrintStream out = System.out;
try {
out.println(getFoo());
} catch (final Exception e) {
logger.info(e.toString());
}
for (final String s : bars) {
out.println(s);
}
}

protected String getFoo() throws Exception {
if (foo == null) {
throw new Exception();
}
return foo;
}
}

Constants, variables, and parameters have final attached to them. I wasn’t always this addicted, but I’ve since learned through painful experience. With the final keyword spread liberally around my code, the compiler does the hard work and tells me when I’m doing something wrong. I can’t accidentally change a value or reassign a variable I didn’t mean to. I know that a lot of people will complain about how verbose this can be and they’re correct. That’s part of the language, though. I’d love to have all variables set as final by default. Until then, I’ll sprinkle it around every chance I get.

Favorite books

Chad — Thu, 13 May 2010 01:15:52 +0000

I love to read. Every developer needs a few of their favorite books sitting on their desk for quick reference or to loan out. It always gives me pause to come across a developer that doesn’t have any books on their desk. One of my favorite interview questions is to ask a candidate to list a book they’ve read recently or to name a favorite author. You can learn a lot about a person based on the books they have read, which gives you more insight into hiring decisions. Recently, someone asked me about books I’d recommend for someone just getting started or in need of a Java/Dev refresher. There are a lot of great books for that situation, but these are some of my favorites:

What job posting phrases really mean

Chad — Wed, 24 Mar 2010 16:34:33 +0000

A bit of humor for the week….

Challenging:	We fired the person that wrote all this junk and we need you to clean it up.
Self starter:	We won’t be giving you any direction, so it’ll be up to you to sink or swim.
Ability to prioritize:	You’ll have 6 projects to work on and they all are the most important.
Gets the job done:	You may be asked to do things that are immoral or illegal.
Team environment:	Everyone else has already formed a clique and you’ll be the outsider who gets the used PC and the crappy desk.
Fast paced:	We require a code slinging monkey hopped up on caffeine, which we’ll provide.
Flexible schedule:	We don’t mind if you take a long lunch because we expect you to work nights, weekends, and holidays.
Company first:	Resistance is futile.

Interview the process

Chad — Sun, 14 Mar 2010 14:12:11 +0000

I ran across a few interesting posts that somewhat go with mine on tech interview tests. First, Norman Richards, talks about the worst interview question ever while, Neil McAllister, talks about how you hire a developer. I’m glad other people are experiencing the same frustrations I have with the interviewing process. It’s mostly hit or miss walking into an interview cold if you don’t already have an inside connection. It almost makes serious networking a required skill for finding that next killer job you covet. I’ve found consulting has helped in that regard, but there are other things you can do from attending user groups, answering forum postings, working on open source projects, or anything else that gets you interacting with more people in a positive way. That’s not always easy for someone that sits behind a keyboard 9 hours a day.

On the other side of the fence, Mike Taylor, complains that programming is too easy while, Jeff Atwood, laments that he can’t find anyone that programs well. Which is it? It’s certainly not both of these. Mike is completely wrong when he whines that all programmers do today is glue stuff together while *real* programmers create everything from scratch. Attitudes like that completely smack of a not invented here syndrome. That just doesn’t cut it when your project deadlines are coming up and the feature creep sets in. It’s still and always has been about the customers and meeting their needs. Anything else is pure self indulgence. Meanwhile, Jeff Atwood, is trying to interview people by using a “pen and paper” style. While that method can work, I’d be afraid to disqualify someone good that isn’t adept at writing code on paper. That can be a difficult thing to do, when stressed, if you don’t do it often. At the very least, sit someone you’re interviewing down at a computer and walk through some code. Give them a taste of what they are going to actually be doing. The interview is your first and best chance to set expectations about what the job really is and what the work will be. It’s as much about them knowing if they are a good fit as it is you thinking they are. I’ve found most people are honest and will tell you if they don’t think they are a good match. They just need to be given that chance. If you can make your candidates a little more comfortable, you might be surprised at how much better they do. After all, the end goal is finding someone good to work with, not tripping people up on abstract or overly technical questions and yelling “gotcha” when they don’t produce the desired answer.