iCrossing is hiring a Java developer in Chicago

My employer, iCrossing, has opened a search for a new member for the Merchantize team. Here's the description. To apply for the position, visit http://www.iCrossing.com/careers, select U.S. Career Offerings, Jobs by Location, then Jobs in Chicago, IL.

Java Software Engineer (Open Source / Web Analytics / ETL)

JOB DESCRIPTION

We’re a people business.

People are the heart and soul of our company, working every day to make our clients’ marketing programs successful.

At iCrossing, we combine experienced talent with world-class technologies to efficiently create marketing programs that truly perform. With more than 620 professionals in 15 offices in the U.S. and Europe, we are equipped to service the digital marketing needs of large enterprises and growing companies alike.

We’re seeking the talented, the experienced and the exceptional to give our clients the most creative and successful solutions for an ever-changing industry. When we find them, we offer a dynamic working environment, competitive compensation, the opportunity to work on exciting client programs, and occasional bagels.
We are seeking a highly motivated and technically proficient JEE Software Engineer / Software Developer to work on our industry leading and mission critical Paid Media Management (Search Engine Marketing, bid management) product.



Features of the position:
• Work on a high-visibility, high performance product that supports iCrossing’s industry leading SEM practice in a growing and fast moving industry.
• Work closely with all of the major search engines (Google, Yahoo, MSN, Ask, AOL) and their APIs.
• Work in a fast moving and forward thinking development environment that is constantly researching and rapidly implementing the latest technologies.
• Research and participate in the advancement and implementation of open source frameworks and architectures such as SOA/ESB, MapReduce, Grid and Cloud computing, and others.
• Work with an experienced Agile Software Development team in a highly collaborative environment.
• Modern Java Enterprise open source based product stack, Java 6, Spring, Hibernate 3, Webworks/Struts 2, JMS, JUnit, MySQL and more.
• Learn current software development best practices (continuous integration, build automation, test driven development, pair programming, agile estimating and planning, etc)
• Apple MacBook Pro, 24” widescreen monitor, IntelliJ or Eclipse.
• A casual, fun, and creative work environment
Major Job Responsibilities / Accountabilities:
• Write test driven quality code.
• Work closely with your dev team.
• Follow and encourage development best practices.
• Develop knowledge of Search Engine Marketing (SEM) principles and techniques.

Skills/Requirements:
Required Technologies (At least one or more of the following)
• Spring
• Hibernate
• SQL scripts
• Shell Scripting
• Webwork (Struts 2.0)
• Linux / Unix admin
• Junit (required) or TDD (preferred)
• Grid Computing (GridGain preferred)

Bonus Technologies (Preferred any of these)
• MySQL (especially advanced knowledge of replication, storage engines, backup and recovery)
• PERL
• Data warehousing design concepts, ETL
• Mondrian OLTP
• JMS
• Amazon EC2 / S3 / AWS

Knowledge / Skills / Abilities:
• BS in Computer Science or equivalent level of experience
• Understanding and/or appreciation for Agile software development methodologies.
• 1+ yrs of professional development experience.
• Familiarity with source control using Subversion
• Familiarity with IDE tools such as Eclipse or IntelliJ
• Must possess effective interpersonal and communication skills and ability to work successfully in a team environment.
• Good organizational and time-management skills.

Do Not Apply if you:
• Do not know Java
• Have no interest in Agile, TDD or Unit testing
• Are close-minded and don’t want to learn new technologies.
• Are more comfortable working on the same technology you did last year.

*ICROSSING IS NOT ACCEPTING RESUMES FROM STAFFING AGENCY PARTNERS AT THIS TIME. THANK YOU.

iPhone SDK Presentation at CJUG 2/17/09

Our local Java User's Group chapter, CJUG recently hosted a presentation by Rakesh Vidyadharan titled iPhone SDK: Java Developers Perspective (link to PDF). It wasn't so much an immersion in iPhone development per se, but an introduction to development in Objective C.

Some of the things I found interesting:

• The SDK requires an Intel-based Mac
• The MVC approach is pretty much baked into the framework. Not everyone likes that.
• Development with an emulator is a breeze, but pushing an app to a real iPhone is time consuming
• Getting apps considered for inclusion in the app store is well-documented, but a convoluted process

Some things about Objective C:

• Very similar to TCL scripting
• Weak typing and dynamically-bound variables like javascript, ruby and php
• There's no namespaces or packages, which means every class has to have a complete unique name. To group variables, developers adopt precursors, like CUreader, CUwriter, CUcreator, etc. And the language has several precursors reserved for the language core. For example, you can't define any classes or variables beginning with NS, IB, or UI.
  
• Parameter names are part of the signature of a method. For example, foo(first_name: "Greg", last_name: "Sandell")
• The code is visibly very different from Java, or even C and C++. Many lines start with a plus or minus sign.
  

Object-Oriented characteristics of Objective C:

• Much less a "real" Objected Oriented language than C++
• Objects don't automatically inherit a base Object as in java. You have to explicitly extend NSObject
• Objects automatically have setters and getters, like ruby
• Like C, you completely manage your own memory. OsX since Tiger has a garbage collector, but Objective C doesn't use it
• Memory is managed by a incremental counting approach called refcount. Each alloc increments refcount, each release decrements it
• Dealloc is like finalize in java
  
• Messaging is a big part of the language. For example, methods are invoked via messages.

Recruiter tips: finding software developers

Recently a friend from a company outside of Chicago asked me some advice on how they should go about hiring a java developer. I found myself offering advice on screening techniques for technical people and how not to blow it, and found myself thinking, damn, these are things that professional recruiters should hear.

Despite this economy, the market for programmers seems very hot right now. (Seller's market.) I get contacted by a lot of recruiters all the time. When I'm actually on the job market, I get more of these cold-call emails/phonecalls than I can possibly consider returning. So unfortunately I have to go on their voicemail or email as to whether they are worth my time or not. (First impression is a big deal.) Many people say things that send bad messages, like the job description doesn't make sense (they want strange mixtures of technical and business skills), or there's too much detail on company operations and history at the expense of core details (e.g., what the software development environment is like, whether it's Windows vs Linux vs Mac, what webserver they use, etc.), or they want you to complete some coding test before you even get a how-do-you-do. When recruiters get the message wrong like this, the more senior and experienced people know to stay away, and you get more junior or unqualified people who are willing to go along...and you waste a lot of time discovering that, or even make the mistake of making a bad hiring choice.

So here's my advice. Before you contact any software developer, get a complete job description. Keep the description of the nature of the company's business to no more than 1/3 of the description; the rest should all be technical specifics of the programming core responsibilities. Make sure that part is written by, or at least with the collaboration with, a person qualified to manage that person. Get coached by that person on how to describe that position over the phone. When you find a person to contact, either get them the description in their hands before the phone call, or try to send it to their email address during the phone call. On the phone, don't try to say more than you know. Don't bore the candidate with the history of your recruiting firm---trust me, all recruiting firms histories and mission sound completely identical. Don't ask the candidate to read their resume over the phone to you; do your due diligence and show them that you've digested it already. If you meet the candidate first, don't insult them by making the meeting be about nothing. The recruiters who did the best work for me never asked me to meet them first. Hope that helps!

Maven2 Introduction part 1: the Coordinate System

Maven is gaining traction as the premiere form of Java code organization and managing builds. The entire world won't convert overnight, but adoption is likely to steadily increase once more people get over the learning curve and conceptual difference with ant scripts, the previous prevailing model of build management. In this article I'm going to try to take a bit of the steepness off of the learning curve for you.

The big sell for Maven is the dependency management and the coherence it brings to both your individual projects, and your code development overall. And by dependency management, I mostly mean where and which jar files you use. For ant users reading this, this is a way more than what the "depends" attribute of an ant target gets you. It's a way of:

• Avoiding confusion between different versions of the same jars


• Maintaining only one copy of the same jar on your computer (instead of having one copy for each of your projects that use it)


• Having a mechanism that retrieves jars (and making sure it is the right version as well) from the internet for you without you having to think about where it should be stored

Maven does this my having a highly structured approach to dependencies, and importantly, the adherence to this framework by the community who uses Maven. In this part of the article I'll start by covering the cornerstone of the Maven approach, the "Coordinate System," then we'll move on to Maven repositories.

The Coordinate System: groupId, artifactId and version

At the core of Maven 2 is its method of identifying resources (mostly jar files) by a strictly followed practice of file and directory naming. The goal is similar to that of XML namespaces and the java packaging conventions: to define items as distinct points in space according to a unversally followed set of conventions. It's simply these four identifiers:

• groupId: usually a reversed domain name such as com.lowagie.


• artifactId: a common name for the resource, such as itext.


• version: a version indicator such as 1.4. Numbers and decimals are typical, but not required, values for the version.


• packaging: the type of end product which could be ear or war, but is most often jar (and therefore the default, so packaging need not be specified)

(A side note about the groupId: there are many jars out there that do not use their organization's reverse domain name. In fact, they comprise some of the most widely used jars out there: log4j, jdom, ant, and xalan to name a few. All they use for their groupId is their simple well-known name (log4j, jdom, ant, and xalan for the examples just mentioned), and their artifactId is the same. These famous jars just happen to have been on the scene during an earlier version of Maven before the convention of using reversed domain names took hold; they held on to their old coordinate locations instead of updating.)

1. Here is the location of a jar file named itest-1.4.jar in a proper Maven repository. The initial part is chosen by the individual user (c:/.m2/repository) but everything following that is dictated by the coordinate system:
   
   c:/.m2/repository/com/lowagie/itext/1.4/itext-1.4.jar
   


2. In the same directory as itest-1.4.jar, you will find the file itest-1.4.pom. This is an XML file containing the following:
   
   

   
   <project >
   
   <modelVersion>4.0.0</modelVersion>
   
   <groupId>com.lowagie</groupId>
   
   <artifactId>itext</artifactId>
   
   <packaging>jar</packaging>
   
   <version>1.4</version>
   
   </project>
   
   

   
   
   


3. In the project's root directory, you will find a file called pom.xml, and that file will contain the same lines as above, but wrapped inside a <dependency> element:
   
   

   
   <dependency >
   
   <modelVersion>4.0.0</modelVersion>
   
   <groupId>com.lowagie</groupId>
   
   <artifactId>itext</artifactId>
   
   <packaging>jar</packaging>
   
   <version>1.4</version>
   
   </dependency>
   
   

   
   
   


4. Retrieval of resources over the internet is integral to maven. A jar can be referred to by its URL on a known repository. The first part of the URL is specific to the repository, whereas the rest follows the file structure of the coordinate system. Here is a URL for the location of a jar at the well-known repository ibiblio:
   http://mirrors.ibiblio.org/pub/mirrors/maven2/com/lowagie/itext/1.4/itext-1.4.jar
   


5. Now here is a Maven command line statement. It's purpose is to install a jar in a repository, but don't worry about that right now; just notice how the coordinate system manifests itself on a typical command line statement.
   

   
   mvn install:install-file -DgroupId=com.lowagie \
   
   -DartifactId=itext \
   
   -Dversion=1.4 \
   
   -Dpackaging=jar \
   
   -Dfile=itext-1.4.jar
   

   
   
6. Occasionally a point in space is referenced with a single line of text, using the format
   
   groupId:artifactId:packaging:version, as in:
   
   com.lowagie:itext:jar:1.4
   

These 5 situations show you most of the ways in which jars are referenced in the Maven world. There is a maddening consistency and pervasiveness to the Coordinate System throughout Maven. The more you learn about Maven, the more you discover you've already learned it.