S.D. Tools

Setting Up GHUnit in XCode 4

2011-11-15T22:41:00.000-05:00

If you're looking for a hand held step by step walk through in getting GHUnit set up and configured in XCode 4, then you really need to watch this video put up by Robert van Loghem from Xebia. It does an excellent job at conveying exactly what you need to do, and where you need to go to grab additional external resources to get things up and running.

If you pop open GHUnitIOSTestMain.m, you'll notice a commented out section right at the top of the main method that lists some environment variables that can be useful and helpful in debugging. One that isn't listed though is GHUNIT_AUTORUN. Setting this to a value of YES will cause your tests to run automatically whenever you run them in the simulator, or if you choose, on your device. In XCode 4 you can set environment variables for a target by going to Product --> Edit Scheme... Selecting that should open up a view like the following, which is where you can add this setting. Make sure you're setting it for the application that has your tests in it.

It saves the step of hitting the "run" button in the UI, which is nice.

I found that useful little bit on Brett Schuchert's video series about doing TDD in iOS (specifically the one titled "Integer RPN Calculator: Setting Up The Environment"). I recommend giving the series a watch as he has some good information in it, and you get to see how he works. The series is based in XCode 3 so what you see won't exactly match up with what you see in XCode 4, but the more familiar you become with the environment the more adept you'll be a tracking things down.

Get Drunk

2011-04-25T13:57:00.000-04:00

Thank you Dave for passing this one along.

Concentration

2011-01-19T13:02:00.013-05:00

Most of the work we do (in software) requires uninterrupted concentration. Here are some thoughts on why being in the office is often more distracting than not from Jason Fried. I think he makes some interesting observations... have a watch. While your at it, take a trip over to Boycott A Meeting Day.

One of the things Jason points out that may help is using more passive means of communication such as email and IM to help to alleviate the constant interruption that can happen in our daily work life. I tend to agree with him with the exception of this observation... and that is this doesn't work if you are in an organization whose culture believes that email and IM trumps whatever else you are doing. But it definitely depends on the culture of your organization. In an organization that has a culture where IM and email trumps all else, you're going to have a hard time getting anything done in my opinion let alone blocking out time to concentrate on a problem.

Evolution

2010-12-08T12:44:00.004-05:00

Haven't really posted anything here in quite a while. Life has a way of sweeping by me, and that's how I've felt for a bit here. For whatever reason, just haven't had the time or energy to post... but we're trying to change that. I keep hoping for the 34 hour day to happen. I'll stop holding my breath, and start to use my lunch hour for more than eating lunch.

This has by large been sparked by my team at work choosing to read through Seven Languages in Seven Weeks by Bruce A. Tate. I feel extremely fortunate to work with a super smart group a guys that are eager to learn and extend themselves by reading a book like this. In short... to evolve. Evolving is something that's been occurring in several of life's corners for me this year... something that can feel like a hammer on one day and like an intoxicating Long Island Iced Tea on others. Point being, to continue to evolve. And that is what I hope and am sure that reading Tate's book will do for me.

As such, I hope to convey some of my thoughts and insights on the languages we go through. No doubt, it will be fun.

Frustrating II

2010-03-09T15:04:00.003-05:00

Here is a re-post of something I'd had up before, slightly annotated to include more information.

I've had the unfortunate experience of dealing with code generation tools on several different projects, and my abhorrence of them continues to grow.

The problems with code generation tools for a Software Developer - iReport and Websphere Portlet Factory.

1. You click things, you don't write code. I went into software development because I enjoy writing code, not because I find enjoyment in clicking buttons. My heart has been broken every time I've had to deal with one of these tools.

2. Provide you no visibility into the code. You're entirely blind from a code perspective, and have no real way to distinguish if things are not connected up correctly.

3. Provide no debugging or step through ability during runtime.

4. Rare, in my experience, to find one that provides code completion. And if it has, it's been spotty when it did work.

5. There is absolutely no way to test them in any meaningful way via any kind of unit test.

6. If you have to use one, read the book. You have no knowledge of how it's supposed to work without a reference.

7. There is often very little, if any, contextual help within the tool for tasks that you're trying to accomplish. This lends itself to googleing for your answer, and good luck to find someone that's posted anything of value for the scenario you are faced with. Chances are, you won't find it.

8. Oftentimes, the ability to control the same properties of objects or control items are found in different places. Or, labels to set properties across different controls or objects are named the same and appear to control the same thing but in actuality they do not. This makes it very confusing trying to figure out what exactly you are doing.

9. When making a change, a simple textual change, to a control or element... that change doesn't always get applied. And there is no rhyme or reason as to why. Sometimes simply closing the thing you are trying to change and re-oppening that same item will allow your change to take. Sometimes changing the same field but in a different spot (as noted in item #7 above) will work. Sometimes not. It's often hit or miss.

10. Refactoring items is typically a manual process that is error prone and fraught with manual-ness (my new word). It becomes very difficult to change items that have dependencies between them. I've not seen this automated well, if at all.

11. You will waste an inordinate amount of time on things that work one second and don't the next, and then do again even though all you did is regenerate the code a couple of times during your troubleshooting.

12. Sometimes items that get created via the tool will just simply behave erratically, no matter how much you tinker with it to get it to stop doing so. What I mean by this is that I've seen these types of tools implement some type of behavior that I have not told it to do. They just seem to do their own thing. And this newly unwanted behavior screws up what you are trying to accomplish. The unfortunate answer is often scrap the widget/report/whatever you are trying to create and start over. The art is knowing when to scrap it and when to keep banging on it. My hope is that I never use these tools long enough to become that artistic with them. The unfortunate thing is this is one of the most frustrating pieces of these things.

Never Blog When You're Mad

2010-02-17T08:58:00.003-05:00

I read the other day on Kent Beck's blog some wise advice that he was both simultaneously giving and breaking at the same time.

Even though I had read this wise advice, I too did not follow it. The advice was to never blog when you're mad. It was never anything that I had thought about, but upon seeing it in writing it made perfect sense. Why? It just looks bad. You'll say things in the heat of the moment that you'll regret. And you just don't want the whole world to see your temper tantrum do you?

Why did I not follow this advice that I had not even one day earlier stumbled upon? Because I was mad of course. And I wanted to express that... to get it out of me... so that I no longer held onto it. But after having my minor rant exposed on the web for a short duration of time... his advice kept ringing over and over in my head. "Never blog when you're mad... never blog when you're mad... never blog when you're mad...".

And now that post is digital trash... I deleted it. There are more constructive things to write about or do. Such as this... passing on the advice... never blog when you're mad. Lesson learned.

A Shoutout to the Agile Manifesto

2010-02-11T09:11:00.003-05:00

Just pausing for a moment to recognize the anniversary of the Agile Manifesto.

Apple Kudos Long Overdue

2010-01-30T21:37:00.004-05:00

I bought an iPhone probably about a year and a half ago. Like any other iPhone owner that you ask… I love it. Tough to bump into someone that doesn’t love their iPhone. I’m not making any huge revelation when I point out that they absolutely did change the game in the mobile telco space when they came out with this phone.

The revolutionary revelation that I have experienced, and want to point out to others, is the level of customer service that Apple has provided to me. This past November, my iPhone out of the blue decided that it would no longer connect up to any Wi-Fi access point. Not at home, not at work, not at Starbucks… not anywhere. For me this was incredibly disappointing as that is my primary method of choice to pull down podcasts, which I love to listen to. I’ve come to love listening to The Java Posse and the Clarke Howard Show on my way to and fro work (along with a litany of other podcasts that I fit in here and there). Granted, you can pull down podcasts via iTunes and drag them onto your phone, but it’s just several more steps to go through that I wish I did not have to. And besides that, I didn’t fork over hard earned cash for mobile equipment that would fail within a year, forcing me to sit back down at a desktop to use all of the functionality of my mobile device.

After Googleing the issue and trying several suggestions to fix it… I decided I had to make a trek to my local Apple Store to visit the “Genius Bar”. For no real reason that I can point to, I’ve always felt that Apple’s labeling their in-store tech support as the “Genius Bar” rather pompous and pretentious. I’d never experienced any of these “Geniuses” before so who was I to judge if they were pretentious or not… maybe they all really are geniuses. Just has a pretentious feel to it to me. Anyways, off I go to the Lenox Mall Apple Store after setting a reservation with one of the tech’s (Note: a reservation is necessary, so make sure to set one at apple.com prior to heading off to the store).

After taking my seat and explaining my dilemma to the technician assigned to me he ran some diagnostics on my phone. All came back to indicate that there was an issue with the phone. And after several reset’s to the phone, the conclusion was that there was no helping this phone of mine. It was just simply not going to authenticate onto any Wi-Fi access points. And of course, this issue is very rare he said… I was just lucky enough to experience the problem. Then the rub came... sort of. After looking up the information in their system via the serial number of the phone, the tech informed me that my phone was 20 days outside of its warranty timeframe. A big resounding Charlie Brown-ish “AaaaUuuuuuGggggHhhhhh” rang through my brain as these words came out of his mouth. How could this be… Why Me… @#*&$*@(!!! As I mentally rolled around in self pity… I almost didn’t catch the next sentence out of his mouth, which was “But, they do give us some discretion over cases that we get. I’m going to give you a new phone and call it a day.” After hearing this, I almost kissed the guy. YES… THERE IS A GOD. Kindness and being human have not been abolished from the American corporate vocabulary. I looked him straight in the eye and said “You’ve just won a customer for life. What is your boss’s name? I would love to press in on him to give you a raise.”

I am pleased to report… I didn’t experience any pompous and pretentious geniuses at the “Genius Bar”… just some really nice people doing a really good job. Taking care of their customer.

Oracle's Documentation Site

2009-11-18T14:40:00.005-05:00

If anyone has any insight into why Oracle's documentation site is so slow, I am seeking understanding and am open to ideas.

My First Agile Atlanta Meeting

2009-10-13T23:53:00.005-04:00

I attended my first Agile Atlanta meeting tonight at IBM's offices over near Perimeter Mall here in Atlanta. The building was easy enough to find, and I arrived early enough to grab a quick and unnecessary snack of potato cakes from Arby's. Unnecessary because pizza was served at the meeting.

I couldn't have unknowingly picked a better night to attend for my first meeting, as I discovered that John Scumniotales, a co-creator of Scrum and the first Scrum Master, would be the presenter. I had the pleasure of sitting next to him prior to the meeting and the opportunity to get to know him a little. Seems like an extremely nice guy. I hadn't realized it but Easel Corporation was a direct competitor with PowerBuilder back when he, Jeff Sutherland, and Jeff McKenna were working there and came up with the phrase Scrum to describe what they were doing.

Some of what I heard him speak of this evening re-affirmed other things that I had learned about Scrum, and Agile methods in general, from others that I've worked with in the past. One thing that I did learn was that he did not consider a development shop practicing Agile unless they are doing Test Driven Development. It's a cornerstone that seems like he doesn't believe can or should be compromised. There were 5 things that he mentioned, and unfortunately my skill at typing on my iPhone was not honed enough to capture them all.

Beyond what is commonly known as Agile and Scrum methods, he spoke in part to Scrum methods spilling out from sort of the software construction time frame to other parts of the business.

He also spoke to Agile and it's implications for distributed teams. He makes a good point, in that tooling in this circumstance is very important. He walked us through some of the application that he manages development for, Serena - Agile On Demand.

Suffice to say, I'm glad I finally made it to my first Agile Atlanta meeting, and I definitely intend to make it to next months meeting, time permitting. Thank you, John, for taking the time to come out and talk to us this evening.

Spring in Action: Section 9.1

2009-08-31T22:55:00.008-04:00

For some reason, lately I've been picking on Spring In Action, Second Edition. This is due in large part to it being the primary book that I've been reading. I would like to set the record straight before continuing with this next post and say that I like this second edition of Spring In Action by Craig Walls and Ryan Breidenbach. I would go so far as to say that I like it a lot. I've used it for many things, first and foremost for giving me a deeper understanding of the Spring framework. And a natural extension of that has been professionally at work.

That being said, I do want to point out that there is a typo on p.345, Section 9.1, paragraph 1, last sentence in the paragraph reads:

"It might be easier to answer that question by first talking about their antithesis: contact-last web services."

This should read:

"It might be easier to answer that question by first talking about their antithesis: contract-last web services."

I think I've potentially missed my calling as a nit-picky book editor. Perhaps I need to make myself useful and point this out to the book's publisher (Manning Publications)in case they care to correct it.

Spring In Action - KnightApp modification

2009-07-03T16:12:00.012-04:00

I'm currently reading Spring In Action by Craig Walls and Ryan Breidenbach from Manning Publications. Let me first thank them for writing this book as it's a reference that I've used both professionally and personally. I like the Manning "* In Action" series of books as they tend to get to the point with doing things through examples. However, I believe that the examples could have been a little better worked out, which I will point out here in a minute. Like any good technical author, though, they did include their source code for each of their examples.

In Chapter 1 they begin walking you through core Spring via the characteristic Hello World app pointing out Dependency Injection, and it's benefits. Their second example walks through a Knight application, and is used to demonstrate both dependency injection and Aspect Oriented Programming (AOP). I'm looking forward to seeing how Spring facilitates AOP.

They describe AOP as a technique that "promotes separation of concerns within a software system." It looks like the intention is to remove from application code those items that all portions of a system need to concern themselves with, such as logging, transaction management, and security. All classes in a system shouldn't have to concern themselves with these items as part of their application/business logic as they are concerns for the entire system being developed. I'll probably have more to post on AOP once I become more familiar with it's cross cutting domain and how this paradigm addresses them. The intention of this particular post is to point out a change you will need to make to one of your classes in this example or else it will not work.

While walking through dependency injection Walls and Breidenbach write a driver class to kick of the application called KnightApp.java. Their main in KnightApp.java is coded as follows:

-- KnightApp --
(Click for source)


package com.springinaction.chapter01.knight;

import org.springframework.beans.factory.BeanFactory;
import org.springframework.beans.factory.xml.XmlBeanFactory;
import org.springframework.core.io.FileSystemResource;

public class KnightApp {

public static void main(String[] args) throws Exception{
BeanFactory factory =
  new XmlBeanFactory(new FileSystemResource("resources/knight.xml"));
Knight knight = (Knight) factory.getBean("knight");
knight.embarkOnQuest();
}

}

As you move from using the Knight application from looking at dependancy injection to looking at AOP, they don't mention that the driver application KnightApp.java needs to be updated to no longer load the spring config file using BeanFactory and XmlBeanFactory to using ApplicationContext and ClassPathXmlApplicationContext, as shown below.

-- KnightAppModified --
(Click for source)


package com.springinaction.chapter01.knight;

import org.springframework.context.ApplicationContext;
import org.springframework.context.support.ClassPathXmlApplicationContext;

public class KnightApp {
public static void main(String[] args) throws Exception {
ApplicationContext ctx =
new ClassPathXmlApplicationContext(
    "com/springinaction/chapter01/knight/knight.xml");

Knight knight =
  (Knight) ctx.getBean("knight");

knight.embarkOnQuest();
}
}

As I mentioned earlier, like any good technical authors they included the working source code for their examples, as this is how I discovered what needed to be changed. But it does tend to be tedious to track down. I'm not entirely sure of the need for the change yet, but intend on discovering it as I go through more of the book.

The Vendor Client relationship - in real world situations

2009-06-01T16:04:00.012-04:00

Starting a new project

2009-04-15T23:55:00.009-04:00

So, I'm starting a new project in my "off" hours at night. It's a scary scene...me, my lava lamp, in my basement, with XM radio on, and all of the lights are off save for a small lamp with a 40-Watt light bulb in it.

For my project I have chosen to to use MySQL, which I have never used before and am excited to explore. I've worked with Oracle and a tiny bit of MS SQL Server, and it's about time I play around with MySQL. One of the tools that I've chosen to use in this project is SQuirreL, otherwise known as the universal SQL client. I had the pleasure of being introduced to SQuirreL by a colleague during the past year while working on a project at work, and since then it has become my tool of choice if I have to attach to a database and do some work.

It's written entirely in Java and allows you to do pretty much whatever you need to do (or whatever I've needed to) administrative wise on a database, without any quirky restrictions often found in limited versions of pay-for tools (such as DBVisualizer). Oh, I didn't mention that it is freely available via an open source license. The latest version made a UI change that I like, and that is that Drivers and Aliases are now available as tabs on the left hand side of the application. It seems like in prior versions I always seemed to loose one or both of those, and had to go searching to pull them back up. You pretty much just have to point SQuirreL to the jdbc drivers for whatever database you want to attach to, and away you go.

Road rules for commenting your code

2009-04-07T13:24:00.009-04:00

I'll never forget the first programming professor I had in college. He was a developer for Coke in Atlanta, GA corporate offices and taught "Intro to Java" as a side gig. He was a good teacher so far as I can remember, very capable at presenting completely foreign material to a diverse group of students in a concise and understandable way, and for that I thank him. He made himself readily available for questions, including business hours when he was on duty at Coke if you had a pressing question that you needed to get in touch with him about.

However, one of the principals that he hammered us on was that you needed to comment all of your code. This included every class, every method...on down to every variable. Closing braces should have a comment on what block it was closing off whether it be an if-elseif block, or a for loop, or the closing brace on your class. Did not matter...it had better have a comment on it or you could count on 2 points coming off of your grade.

It was not until I graduated and entered the working world that I would discover that this was in fact, not the best practice to follow. I was surprised to find that the majority of developers on a large project I was involved with at work shunned the practice of comments (not always, but most of the time you could say). Why? They were quick to point out that comments quickly get outdated, and that it's better to rely on the code to tell you the story instead of the comment. The one caveat to this was that an interface (we were coding in java) should always have comments as it is a public and published contract.

I was reminded of this professor recently after having stumbled upon a series of articles by Robert C. Martin (otherwise known as Uncle Bob). These articles provide you with a glimpse into what you can expect to find in one of the most recent books he has been involved with, Clean Code: A Handbook of Agile Software Craftsmanship. They give a just shy of humorous but pragmatic viewpoint of how comments don't work sometimes... a lot of times. I've not had the chance to read the book yet, but if the article series of excerpts are a good representation of what is in the book, then I intend to be picking it up soon.

My personal viewpoint... definitely comment code that could be confusing. If this is the case though, then perhaps you should try to find a way to refactor the code to make more sense. I agree with my friend, comment interfaces that you write. Remove old commented out code as it is outdated and most likely will never be needed again. And if it is, that's what version control systems are for. And keep comments short and to the point... don't try to tell a story with your comment. If you are, then your code could probably use a refactoring in this instance as well.