Author: Ivan Moscoso

Snow Leopard: the Obvious Choice

Ivan Moscoso, Wednesday, August 5, 2009 @ 11:00 am

When OS X 10.5 (Leopard) was released back in late 2007, I told a colleague at the time that Leopard was, by far, the worst release Apple ever put out. You can pardon a bit of hyperbole there, but after a healthy string of solid releases of OS X that just "worked", the problems produced by Leopard were numerous (one might counter that this is all relative-- four to five issues might not sound as numerous to users of other operating systems, but for OS X, these were a pretty big deal, and kept me from switching for months).

By comparison, Snow Leopard marks a great return to the kind of releases the Mac community came to expect. Yes we still have a month left to wait for its release, and yes there might always be small glitches, but as one long-time Mac user the answer to the question of "is it really all that?" the answer is pretty clear to me at least: "Yes, yes it totally is."
Continue reading »

Asterisk-Java Testing with Groovy

Ivan Moscoso, Thursday, July 2, 2009 @ 8:03 am

Recently I have taken a bit of a detour into the world of telephony, working with Asterisk-Java, which by itself is a very valuable tool, and worth knowing a bit about if you are integrating a system with Asterisk. While it is a Java-based library, I am integrating it into a Grails application.

We have a fairly comprehensive suite of unit tests asserting that desired behaviors are triggered upon certain events initiated through the Event API. This is made even easier, as usual, with Groovy-- specifically on the testing front. Here I show two hypothetical test cases, followed by supporting code that works specifically with the Asterisk-Java classes...

Continue reading »

• Digg
• Reddit
• del.icio.us

Comments (1)

software development best practices

Writing Your Own Protocol With NSURLProtocol

Ivan Moscoso, Saturday, June 27, 2009 @ 8:39 pm

I have a native iPhone application in development which requires me to interact with a server that uses a stateful protocol over a persistent connection to transfer messages over the wire. This is definitely not a trivial application to write, even though the UI itself is very simple.

The Problem

Stateful protocols and persistent connections are often interrelated, but not by design. My first problem was to divide the original problem in two: how to manage the persistent connection, and how to handle the underlying protocol so that the stateful aspects did not bubble up throughout the UI.

Continue reading »

• Digg
• Reddit
• del.icio.us

Comments (0)

software development best practices

The Costs of Building Secure Applications

Ivan Moscoso, Wednesday, March 25, 2009 @ 11:50 am

Security is unlike other aspects of software in that it follows a steep value curve: either your system is secure, or it is not. Either it provides its full level of value, or it provides none at all. There is often a tendency to address security up front (even when other aspects of the system are built iteratively). What others sometimes fail to see is how this generates unneeded cost and complexity as the project matures.

Continue reading »

• Digg
• Reddit
• del.icio.us

Comments (0)

software development best practices

‘Signature Survey’ Revisited

Ivan Moscoso, Thursday, March 5, 2009 @ 10:24 pm

'hieroglyphics' by Em_G

One of the things I most admire about Ward Cunningham's work is that you can read something like 'Signature Survey' and still find new things to appreciate, even years later.

Ward's original article discussed a method to tackle large code bases (based somewhat on Tufte's ideas on data visualization). To quote the original article, he summarized the process as the iterative application of two steps:

1. Inspection. Browse the report looking for startlingly regular or startlingly irregular structure. Examine the source code associated with each (ir)regularity.

2. Projection. Modify the summarization program (the cgi script that generates the report) so as to represent aspects of the inspected code that seem relevant to the inquiry at hand.

The real lesson I took years ago from 'Signature Survey' is that, when dealing with any sufficiently complex problem, knowing which questions to ask may not be obvious. And rather than approaching each problem with the same set of questions or criteria in mind, it is useful to let the problem itself guide you to the right questions.

All of this should seems obvious right? It is, after all, a simple idea. Still, if you have never done so, I would ask you to really give this idea some thought. Sleep on it. Think about it during your walk back from lunch tomorrow and take your time with it. Toy with the idea and some current problem you are working on. I'm not kidding-- the exercise will be worthwhile in the end, and will continue to pay off.

• Digg
• Reddit
• del.icio.us

Comments (1)

software development best practices

Groovy 1.6 and Per-Instance Metaclass

Ivan Moscoso, Wednesday, February 25, 2009 @ 3:30 pm

One of the new features of Groovy 1.6 includes support for per-instance metaclasses. This is a nice addition to the language, since it allows to change the behavior of objects without affecting all instances of the class as a whole.

For testing, it is often useful to mock out specific behavior of an object without affecting the class as a whole. While some mocking frameworks already allow this, they usually run through a few hoops (i.e. "partial mocks"). Allowing support directly in the language can simplify this kind of approach.

Another case where per-instance metaprogramming can be useful is in employing template patterns on a per-instance basis. Picture the case where the domain decides that one of its children is no longer in a valid state. Most domain models handle this by embedding some sort of state object within the children, so that any object holding a reference to the children know what the child can or can not do. With a per-instance metaclass, however, the aggregate root can simply add or replace behavior of that instance of the object alone.
Continue reading »

• Digg
• Reddit
• del.icio.us

Comments (5)

software development best practices

OCMock: Handling Boolean Return Types with NSValue

Ivan Moscoso, Monday, January 19, 2009 @ 12:35 am

Testing your iPhone application, you may at some point in time need to stub a method call whose return type is a boolean (or some scalar value, or C based structure). The way to implement this (as described in a discussion on CocoaDev here) is to wrap the boolean in an NSValue using the OCMOCK_VALUE() macro defined in OCMockRecorder.h.

While this solution technically works, I find that doing this within the test class itself makes the test cases a little less readable along the way. Instead, I found it useful to extend OCMock to do this type of conversion for me, keeping my test code a bit cleaner as a result.

Let's take a look at an example by examining the set up for a simple test case..

Continue reading »

• Digg
• Reddit
• del.icio.us

Comments (4)

software development best practices

iPhone SDK: Testing UIApplicationDelegate with OCMock

Ivan Moscoso, Thursday, January 1, 2009 @ 2:12 pm

As I have discussed earlier, you can go very, very far in unit testing your view controllers using the following recipe, without the need to bend over backwards or employ any mocking frameworks:

1. Initialize the view controller in your setup using initWithNibName:bundle:.
2. Force the view to initialize by invoking the controller's loadView method within your setUp method.
3. Write tests to assert dependencies or behavior.

This works well enough for view controllers, but when it comes time to test your application delegate, this simple approach can begin to break down. Unlike UIViewController, your application delegate is only initialized as a by-product of loading the NIB. Thus, to get this code under test I find OCMock particularly useful.

I show an example unit test below, and discuss how I approached the problem..

Continue reading »

• Digg
• Reddit
• del.icio.us

Comments (2)

software development best practices

iPhone SDK: Cache Policy & Cookie Handling in NSURLRequest

Ivan Moscoso, Tuesday, December 30, 2008 @ 11:21 am

I recently ran into an issue building an app which hit an existing (protected) website. Passing credentials along with each request, responses at first appeared to be cached, even after the user credentials changed from within the iPhone app. In sorting through this issue, it gave me a chance to get a bit more familiar with NSURLRequest, and NSURLRequestCachePolicy. As I later found, however, my problem turned out to be cookie-related..

Continue reading »

• Digg
• Reddit
• del.icio.us

Comments (4)

software development best practices

Continuous Integration Meets Risk-Based Testing

Ivan Moscoso, Thursday, December 18, 2008 @ 1:30 pm

A new version of TeamCity is out, and while I have not taken it for a ride yet, I found this feature particularly interesting:

Risk Group Tests, Tests Re-ordering
TeamCity 4.0 is now able to determine a set of tests which are likely to fail (i.e., recently modified, those with frequent failures history, etc.), and perform those tests first the next time the project builds. This allows teams to confirm potential fixes sooner, reducing feedback time.

There are strong cases to be made for risk-based testing in certain environments. The reason why it is not more commonplace is that implementation is tricky since it requires the CI system to know a few things which are hard to generalize:

• The type of build and testing framework
• Historical perspective across multiple builds
• A good set of heuristics along the way

Since a risk-based approach may mean skipping certain tests on some builds, this may sound like a step backwards to the agile developer. But consider it an alternative to improving overall build time (i.e. "based on very low risk assessment, tests which never failed will not be run every time."). The hard part is defining what "low risk" means to your project, and how much value you would get reducing overall build time.

This is obviously not an issue on well-run projects with sub-minute builds, but if you were to be dropped into an existing project with, say, a large code base and a fifty-two minute build (I've seen it), this can become one way to perform triage on an otherwise untenable position. You don't need a new CI system to implement risk-based testing, but having this alternative can't hurt.

• Digg
• Reddit
• del.icio.us

Comments (0)

software development best practices

Underwhelmed by JavaFX 1.0

Ivan Moscoso, Saturday, December 6, 2008 @ 5:52 pm

By any measure, I should be a perfect candidate developer for JavaFX in its 1.0 release. All the more painful, then to recognize its deficiencies so early on.

While I work with a wide number of languages and frameworks, my career has focused on Java for most of the past ten years.

I mention this because there are some who might say that 24 hours is not enough time to make educated judgments on JavaFX. Perhaps, but it has been my experience that a day is enough time to develop a sense of curiosity or excitement about a new technology or framework, even if you don't completely "get it" yet. This happened for me the first time I played with Spring, with Squeak, Groovy, Rails, GWT, iPhone development, Flex, jQuery, etc. The list goes on and on. Without a sense of curiosity or excitement, one finds it hard to invest much time working with those technologies. And when something fails to stimulate a certain level of curiosity or excitement off the bat, it leads me to conclude one of two things:

• I must not be the target audience.
• There is little or no value in its current form.

Only in this case, I feel pretty certain that I am the target audience for JavaFX. I must be, right? But sadly, I'm left to conclude that there's not much to see here. Here's a list of things which I didn't much care for:
Continue reading »

• Digg
• Reddit
• del.icio.us

Comments (5)

Software Development

iPhone: Using Pre-processor Directives for Device Testing

Ivan Moscoso, Wednesday, December 3, 2008 @ 5:29 pm

Updated. (see comments below)

There may be cases where a certain setting needs to be tweaked based on whether you test on the device or simulator. It took me a while to find the pre-processor directive to detect whether or not the current build targets the iPhone device or the simulator, but with a bit of searching through the GTM code, I found everything I needed in "TargetConditionals.h". An obvious place, in retrospect, but I wasn't able to find this information easily elsewhere on the web, so I mention it here in case you find it useful.

Here's an example of how I've used it:

#if TARGET_CPU_ARM
#if TARGET_IPHONE_SIMULATOR
	// Device will hit external server over cell network
	NSString const *ROOT_URL = @"http://www.external-site.com";
#else
	// Simulator will hit local server over LAN
	NSString const *ROOT_URL = @"http://localhost:8667";
#endif

This kind of tweaking is particularly important when the device itself can not participate on the local network, but needs to access some kind of external environment (or proxy server). Conversely, targeting the simulator to use a local 'development' server is often faster when deploying and debugging issues in your application, particularly if you are developing the server component in tandem.

Another example involved certain audio playback features which work fine on the device, but run into hiccups running on the simulator. Since in this case the functionality is not critical to test, I ignore it in the simulator.

Related Services: iPhone Application Development, Custom Software Development

• Digg
• Reddit
• del.icio.us

Comments (3)

Software Development

App Security: Throw Out the Org Chart!

Ivan Moscoso, Tuesday, December 2, 2008 @ 12:48 pm

"Only administrators can add users-- no exceptions! ...except Bob in accounting, but that's because he's covering for Sally. But only until February. And this sort of arrangement might happen again. But most of the time, it won't. I mean.. ninety-nine point nine percent of the time. But there might be exceptions... ".

Sound like a requirement you've heard before? How did you handle it?

In an earlier post, I stated that all security models are idiosyncratic, and that the way you go about designing for security must reflect the nuances and -isms of your organization. You might mistake the form used to express the model (HR records, existing databases, or some XML schema) as your security model, but you risk an uphill battle getting your organization (and I mean the people here, not boxes and circles on an org chart) to accept the result.

All of this has less to do with how we design software and everything to do with the way people organize into groups..
Continue reading »

• Digg
• Reddit
• del.icio.us

Comments (3)

Software Development

iPhone SDK: Testing with TextMate & GTM

Ivan Moscoso, Wednesday, November 26, 2008 @ 12:30 pm

Developing in Xcode, I keep my project default "SDKROOT" and Target set to the default for the iPhone device and 'Release', respectively.

That said, I have been trying out TextMate as an alternative to Xcode, thanks to all of the great things TextMate provides (I won't go into all that here, since there are already many great resources on the web). For those iPhone developers who are new to the Mac platform, or to TextMate for that matter, here's a quick tip (and be sure to check install Xcode bundle first).

First, as always, an obligatory shout-out to Google Toolbox for Mac. I am testing my code with GTM, and set the following environment variables so that Xcode plugin for TextMate could run a build / tests accordingly.

  TM_BUILDSTYLE = "Debug"
  TM_TARGET = "Test SDKROOT=Test SDKROOT=iphonesimulator2.1"

This presumes you followed the GTM directions by creating a 'Test' target to run your tests, and also that you are targeting the 2.1 version of the iPhone simulator's firmware. Replace that last argument with 'iphonesimulator2.2' if you are targeting the recently released 2.2 firmware.

With these two settings, everything works great. I can write a bit of code, and run the build. Xcode definitely does a lot, and has its place in development, but I feel that the ease of use in TextMate outweighs the code completion of editing files in Xcode in cases where the code that I am working with is familiar to me.

Wherever I am working with new API's or need to constantly refer to documentation, Xcode is still worth it, particularly after you map some essential keyboard shortcuts (but that's another post). For familiar API's however, you can't beat the productivity gains of just coding in TextMate.

Related Services: iPhone Application Development, Custom Software Development

• Digg
• Reddit
• del.icio.us

Comments (0)

Software Development

iPhone SDK: UIViewController Testing & TDD

Ivan Moscoso, Tuesday, November 18, 2008 @ 11:47 pm

Unfortunately there are not enough examples out there on how to test view controllers with the iPhone SDK. My hope is to remedy that a bit by sharing some techniques I have been using to tackle the problem, particularly in keeping with the spirit of TDD along the way.

First, If you have not already done so, configure your project to use GTM. This is a bit of a no-brainer as it currently stands. Until Apple comes up with something better, GTM is the way to go. It works as advertised, and is a credit to the folks at Google for providing this toolkit.

Now then, many tutorials on the web seem to imply that one should test somewhere in the middle by suggesting to add a few outlets to your controller, fire up IB and wire up your view to your view controller before you even start to think about testing any of it.

Testing controller logic means working under the assumption that you have wired up your view components correctly to match the controller's actions and outlets. Wire up an element to the wrong action (or worse, forget to wire it up at all) and you can easily learn to rely too heavily on manual testing. While this might be acceptable for small one-off applications, within a team of developers practicing collective code ownership, this kind of error can cost real money over time. "Thanks for caring, but I'd rather have a unit test."

Now then, let's take a look at some code!

Continue reading »

• Digg
• Reddit
• del.icio.us

Comments (4)

Software Development