In the Apple Developer Library, it explicitly states that for MacOS applications take both the Language and Regional preferences of the user into account, but only look at the preferred language on iOS – Support for Internationalization. This means that a single variant per language is supported.

However, these is a way around this. I’m not sure if this is a good thing to do, but it works for me and I haven’t noticed any ill side effects yet.

To support both US English and British English in your iOS application, create 2x Localization.strings files just as you would for multiple language. Put the US English translation file Localization.strings in a directory in your iPhone app called English.lproj (Apple defaults) and the British English translation in a directory named en_GB.lproj (just in case they decide to support regions in the future).

Then, you’ll need to create some code to manually set the preferred localization. In your main.m file (yup, main.m is being edited) alter it so it performs some logic similar to below.

int main(int argc, char *argv[]) {
	NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];
	NSString *language = [[NSLocale preferredLanguages] objectAtIndex:0];
	NSString *locale = [[NSLocale currentLocale] objectForKey: NSLocaleCountryCode];
	if ([language isEqualToString:@"en"] && [locale isEqualToString:@"GB"]) {
		[[NSUserDefaults standardUserDefaults] setObject:[NSArray arrayWithObjects:@"en_GB", @"en", nil] forKey:@"AppleLanguages"];
	}
	int retVal = UIApplicationMain(argc, argv, nil, nil);
	[pool release];
	return retVal;
}

When the line

int retVal = UIApplicationMain(argc, argv, nil, nil);

gets executed, it seems to set up all the Localization bundles before calling the application:didFinishLaunchingWithOptions method on your app delegate, so putting Localization code in the app delegate is too late. So, what the code above does is retrieve the users current language and region, and compares those against pre-determined values – en for the language and gb for the region. If these match, then I force a new setting in the NSUserDefaults to overwrite the users preferred language. Then, when the UIApplicationManager function gets called, it appears to retrieve the users preferred language setting, and look up the Localization for that – which in my case I’ve forced to be en_GB.

One thing you need to be careful about is persistence of this NSUserDefault setting. It is saved once it’s set, and persists through multiple application executions. To get around this (lets say the user changes their region back to US), you need to remove the setting after the bundle initialization has taken place. In you app delegates application:didFinishLaunchingWithOptions method, just execute the following code.

[[NSUserDefaults standardUserDefaults] removeObjectForKey:@"AppleLanguages"];

This wipes out the NSUserDefault setting that the app made in the main.m file.

If anyone knows of issues with this approach (apart from being a dirty hack), or faults with my code please let me know in the comments below. I wish Apple supported different regions per language natively in iOS but they don’t. This is the only way I’ve found to do this, and continue to use localization functions such as NSLocalizedString.

How frickin’ exciting!

- (NSInteger)age:(NSDate *)dateOfBirth {
  NSCalendar *calendar = [NSCalendar currentCalendar];
  unsigned unitFlags = NSYearCalendarUnit | NSMonthCalendarUnit | NSDayCalendarUnit;
  NSDateComponents *dateComponentsNow = [calendar components:unitFlags fromDate:[NSDate date]];
  NSDateComponents *dateComponentsBirth = [calendar components:unitFlags fromDate:dateOfBirth];

  if (([dateComponentsNow month] < [dateComponentsBirth month]) ||
      (([dateComponentsNow month] == [dateComponentsBirth month]) && ([dateComponentsNow day] < [dateComponentsBirth day]))) {
    return [dateComponentsNow year] - [dateComponentsBirth year] - 1;
  } else {
    return [dateComponentsNow year] - [dateComponentsBirth year];
  }
}

The situation I was finding was that PHP apps would run, but only if you explicitly call the script (ie index.php) rather than just the directory. If you called the directory, passenger would take over and give me a rails routing error.

The issue was to do with the passenger vhosts configuration. On my machine I have an number of ruby on rails apps configured with the passenger preferences pane (creating vhost entries within /private/etc/apache2/passenger_pane_vhosts/. I have enabled user_dirs, so that the users of my machine’s pages (and other apps) are served from their ~username/Sites directory.

My users configuration info for apache is installed in /private/etc/apache2/users/, and the instructions to load the configuration from that directory is stored within /private/etc/apache2/extra/httpd-userdir.conf (content below).

# Settings for user home directories
#
# Required module: mod_userdir
#
# UserDir: The name of the directory that is appended onto a user's home
# directory if a ~user request is received.  Note that you must also set
# the default access control for these directories, as in the example below.
#
UserDir Sites
#
# Users might not be in /Users/*/Sites, so use user-specific config files.
#
Include /private/etc/apache2/users/*.conf

To get everything working together nicely, I merely wrapped this inside a vhosts configuration directive, and gave it a ServerName of localhost – so that this vhost would be the one that responds to requests for localhost, rather than some random passenger vhost assuming it was the boss of everything. New /private/etc/apache2/extra/httpd-userdir.conf below.

<VirtualHost *:80>
  ServerName localhost
  UserDir Sites
  Include /private/etc/apache2/users/*.conf
</VirtualHost>

Thanks to this, all of my rails apps are served under passenger, and I can have static HTML, PHP and camping apps (previously configured – nothing to do with the above) all served from within my ~username/Sites directory.

Hope this helps someone.

This was basically my first (well, second, but that wasn’t public) go with github, and first contribution to an open source project. Paul Dix accepted my code, and I’m oddly excited about it all.

AND to make things even better, someone has already started to enhance my contribution. Woo hoo!

I needed to store a string (NSString object actually) however, and the tutorial didn’t help me with that. The NSUserDefaults object has dedicated methods for storing and retrieving BOOL, float, and NSInteger values.  It also has a setObject:forKey: method – which is what I ended up using.  The setObject method handles data of types NSData, NSString, NSDate, NSArray or NSDictitionary – making it incredibly useful indeed.

My Preferences.h

#import <Foundation/Foundation.h>
#import "Constants.h"
@interface Preferences : NSObject {
}
+ (NSString *)emailAddress;
+ (BOOL)setPreferences:(NSString *)emailAddress;
@end

My Preferences.m

#import "Preferences.h"

@implementation Preferences

/*-------------------------------------------
* Return the users default email address
*-------------------------------------------*/
+ (NSString *)emailAddress {
  NSString *returnValue;
  // If preference exists
  if ([[NSUserDefaults standardUserDefaults] stringForKey:kPreferencesEmailAddress]) {
    returnValue = [[NSUserDefaults standardUserDefaults] stringForKey:kPreferencesEmailAddress];
  } else {
    returnValue = @"";
  }
  return returnValue;
}

/*-------------------------------------------
* Write preferences to system
*-------------------------------------------*/
+ (BOOL)setPreferences:(NSString *)emailAddress {
  // Set values
  [[NSUserDefaults standardUserDefaults] setObject:emailAddress forKey:kPreferencesEmailAddress];
  // Return the results of attempting to write the preferences to system
  return [[NSUserDefaults standardUserDefaults] synchronize];
}
@end

kPreferencesEmailAddress is a constant I’ve defined with the key value of the users email address. It just makes sure I don’t mistype anything.

Key (only) differences between my code and the code at iphonedevelopertips.com are the use of the objectForKey method to set the NSString value, and stringForKey to retrieve the object and cast it to a NSString object.

Hope that helps someone!

It’s actually really easy to do. If you haven’t created a Radiant extension before I’d recommend following this tutorial on the Radiant wiki.

Inside the Radiant GEM, the standard page layout resides at app/views/layouts/application.html.haml

The lines of code that insert the javascript tags are:

- @javascripts.uniq.each do |javascript|
  = javascript_include_tag javascript

The @javascripts variable is populated from inside the app/controllers/application_controller.rb file. The culprit is below.

def include_javascript(script)
  @javascripts << script
end

Pretty simple huh? So, all you need to do, is call this method from within your new controller, because all controllers inherit from the application_controller.rb file, so they have access to this method, and you can have different javascript included for each method if you so wish. In (assuming the example LinkRoll extension was built as linked above) vendor/extensions/link_roll/app/controllers/admin/links_controller.rb

def index
  include_javascript("admin/mootools-1.2-core-yc.js")
  @links = Link.find(:all)
end

That will insert a link to admin/mootools-1.2-core-yc.js inside the admin/links/index page. Righto, so now the only thing left to do is get the mootools-1.2-core-yc.js file into the actual public/javascripts/admin directory within the project. What you want to do is alter the vendor/extensions/link_roll/link_roll_extension.rb file so that within the activate method the file is copied over. I’d recommend making a public/javascripts/admin directory within your extension folder, and putting the file in there. Then, when activate is called on the link_roll_extension.rb file, the activate method will copy the file over to the projects public/javascripts/admin directory. You should also delete the file when the deactivate method is called in the link_roll_extension.rb file.

Questions and comments please!

For those who are not in the know, check out the following 2 resources for a bit of background

• http://en.wikipedia.org/wiki/Software_release_life_cycle
• http://en.wikipedia.org/wiki/Release_Management

When companies often start out, they focus on getting IT systems enhanced as soon as possible.  A simplified, but common cycle is design (maybe), build (definitely), test (should) and deploy (definitely).  Steps in this process may be skipped when an organisation is small, and the side-effects of getting something wrong in build or deploy can be handled on-the-fly.  As companies mature and grow (in both size, application complexity, and IT landscape complexity), they often wish to have more control over the processes that manages software design, development and deployment.  As enhancements start to involve distributed application development (eg, introducing a new feature on a customer care system, that requires a service on a billing system, and have that exposed by an integration bus, and that integrated with from a web or IVR channel), the process and dependencies involved with deploying that application become more complex.

To ensure that the cross system (and often) cross department, company or country design, development, test and deploy process, companies introduce Release Management Processes.  Different application development projects are collected together, and managed from a central point – who is unimaginatively known as the Release Manager.  The release manager usually has responsibility for delivery and deployment of all the changes requried within a system, and across systems for a particular instance of deployment activities (that’s a wordy way of saying that a whole load of stuff gets developed, tested, and then deployed together).

So, to recap – early days – applications designed, developed, tested and deployed whenever people want.  More mature business – applications designed, developed, tested and deployed under a managed process, with defined implementation dates.  In principle, that sounds fine.  In fact, it sounds like a sensible way to manage development and deployment.  Software can be complex, and complexity grows as you have more systems involved, different parties, different skills, and in some extreme cases, different countries and cultures.

Business users (ie, the people paying for the development, and specifying the functionality) rarely like release management.  It’s costly.  It’s slow.  It’s inflexible.  And this is more true if the business users know a little bit about software development, and especially if it involves the web.

The web is known for being an inherently agile environment.  Web applications are usually self-contained and loosely coupled, and can be easily and quickly altered.  There are other types of applications that exist in enterprises that do not have the same inherent agility.  Customer Management Systems, Billing Systems, Banking Systems, ERP systems.  All of these systems usually have long lead time on changes, strict testing requirements, are have historically been designed and developed in a different (monolithic) manner to web systems.   The requirements on them are often different too – they often aren’t about exposing new “services” to the public, but more about internal services, bug fixes, operational fixes, or enhancements to allow new products to be offered.  However, they don’t interface with the external customer and often aren’t driven by the same requirement for agility – it’s often easier in business (for your brand, and bottom line) to deploy something that is a bit crappy internally (manual processes, double-keying data etc) if you can get the message out to the customer.

Business users want the ability to alter the messages and functions that are delivered to their customers on their terms – when they want – not bound to some (in their eyes) arbitrary release schedule.  They don’t understand why their functionality must be deployed with another, completely unrelated, system or process.  They want to get their product to market.

I feel strongly that certain types of systems fall nicely in a “release managed” category, and others fall into a “system owner” managed category.  (sidenote: I feel that for a platform that supports as much functionality as “the web” that often The System is too coarse a unit for splitting – it could be taken down to business process, journey, or user type).  For me, I believe that systems that have a requirement to be highly agile, provide a high level of flexibility (configuration/scripting, as opposed to packaging and release of compiled code), and support essentially decoupled functions and flows, should not necessarily form part of conventional release management processes.  The “release early, release often” convention can be followed on these systems.  Obviously, a business must be made aware of the risks with this approach (e.g., more defects are likely to arise), and they should also be made aware of some of the sensible processes and changes in methodology to make this approach work (e.g., agile development methodologies).  In my mind, integration and web implementations fall into this category.

Integration systems enhance the ability for each system to remain decoupled from it’s peers – and this in turn means the systems are more modular, and should be able to support development and implementation (outside of a monster sized release), even when all of the required functions are not implemented.  Integration systems can provide stubs that indicate a service is unavailable, and when each system is finally ready, then the processes can be turned on in each.  Integration systems are inherently cross application, yet system independent at once.  This paradoxical view on integration is what makes them great candidates for exclusion from release cycles – they are self contained, but support both the situations where external systems are present, as well as when they aren’t.  This level of resilience and flexibility means that they are a core enabler to allow other systems to deploy functions, and still work when the up/downstream systems they are reliant on do not exist.

I have a couple of recommendations if your organization is considering looking to migrate to a release management style approach for application development and deployment:

1. Applying release management only to systems where it makes sense to do so, will allow a business to maintain the necessary rigour required for financial, legal, regulatory, professional and moral obligations.  Release management should not be a one-size-fits-all approach.
2. Shielding systems with integration and process configuration flexibility (on/off switch for process/service enabling) will reduce the dependency of each system on it’s peers to be launched – and this in turn increases the flexibility to make changes to an individual system without them having a downstream impact, and increases the ability to more quickly make changes.
3. Applying a finer-grained design, build, test and deploy scope (i.e., not cross-system) to customer facing systems will give businesses the agility they desire to get their messages to market.  This in turn will allow businesses to try more products and services in the market, and respond to competition in a more timely manner.

I believe following an approach that ensures that your systems are shielded from changes in each other, and promotes flexibility and agility in the customer facing systems is key to delivering true value to the business in terms of both responsiveness, and reliability.

Coté from Redmonk quoted the title of this entry in episode 14 of Redmonk Radio. Again, it’s another quote that was like an “Oh yeah” moment for me. In companies where you produce software (usually) the project timeline or budget is king. In the open source movement, the best ideas take as long to get implemented as needed – there is no overriding time line that says you must ship that feature by this date. Also, in distributed projects there can be healthy debate about the best way to implement things – the ideas and implementations with the best merit win.

I’m slowly catching up on these podcasts – making time on the train to listen is really working out for me.

Historically people (like me) in enterprises have harped on to vendors for years about how we want their large enterprise applications to be more configuration driven rather than coding driven. The actual purpose behind this was about time to market, resource availability with the necessary skill sets required to maintain and alter the application, effort around testing and deployment, and certainty about the validity of the syntax and sensibility of the customisation. Vendors have responded by closing the code base, but offering more complex configuration environments – which is exactly what we have asked for (see next paragraph about how we have asked for the changes). However, what they have provided doesn’t meet the actual business goals of the request. For example, I’ve been recently looking at some Product Configuration software that has a guided Java coding environment for rules definition. This doesn’t actually make the implementation simpler. It means that your (previously) relatively unskilled (and that’s flame bait if ever I’ve seen it) configuration staff have to significantly increase their skills to match those of java developers. Its called “configuration” because its done in a “configuration” tool. The configuration tool is as much a config tool as Eclipse is (which has code completion BTW, is equally applicable for the task, probably nicer to use and definitely cheaper). What it’s done is moved the effort from the development staff, to the configuration staff. Assuming staff are happy with what they do, developers are unlikely to want to join a “configuration” team, and configurators are unlikely to want to gain development skills. One may also argue that your testing and deployment efforts are more difficult, because the coding that was done by people who know how to code, is now done by people who don’t know how to code – this in my mind introduces more risk. You also don’t know which parts of the application are affected by this complex configuration activity, and this may drive for more rather than less regression testing.

I’ve also been reading recently about user stories, which are something I’ve never professionally come across. I’ve been working for my entire professional career on waterfall based implementation projects, with requirements and scope specified in documentation like traditional UML use cases, interaction/sequence diagrams, and IEEE 830 style requirements. I wonder if the large enterprise is its own worst enemy when it comes to vendor software direction and influence. We are always writing (and that’s the first mistake) very specific (and that’s the second mistake) requirements for vendors to implement, and influencing them through RFIs and RFPs which contain hundreds or thousands of these requirements. Maybe if the interaction was more conversation and (business) outcome based we’d actually get what we wanted, instead of getting what we write down – which is always going to be flawed (inaccurate, incomplete, technology based rather than business value based, and driving misunderstandings between reader and writer). Conversations about outcomes are the way to get around the limitations of written software system specifications.

What we actually want and what we get are often different things. I’m beginning to understand that outcome driven conversations between parties playing their specific roles are the way to go. In a supplier-customer relationship, the customer should tell the supplier what they want to achieve (in a business context), perhaps explaining why the current implementation does not meet their needs. The suppliers role is to understand the customers issues and the drivers behind why those issues are actually issues, and then propose ways those issues could be resolved. Often it may be a process or simple usability issue, sometimes there are fundamental issues with the implementation that require longer term efforts to fix. Regardless, the vendors know their software and the capabilities it possesses and the customers know their business drivers and understand how they are using the software. Each party should focus on playing their part in the relationship and achieving their eventual outcome (customer = achieving the business value and business purpose they want, and vendor = getting a satisfied customer, which hopefully translates into a big purchase order for them).