In my last post I illustrated the advantages of short consistent release cycles but in order to achieve this, you often need to build your software in a way that helps ensure that releases cannot be missed.

1. Support enabling / disabling features without deployment or rollback

   Having atomic feature configuration for new or risky features reduces the need for a rollback, helping safely deploy new or risky changes. This prevents the friction caused when a deployment containing 5 new features fails because of an undiscovered bug being found in a single feature. Rather than rolling back the code, costing you business confidence and a disrupted development flow, instead prefer disabling the feature and taking a story into your current iteration to fix the problem. You’d be doing this anyway, but rather deliver value with the other 4 features while you’re diagnosing the problems.
   

2. Use tiny, frequently integrated feature branches to isolate development of features.

   Any form of long running feature branching should definitely be considered an anti-pattern because any un-integrated changes that diverge from your trunk can potentially cause problems with other features. However, small and short lived feature branches consisting of a day or half a days work on a single atomic feature can help you compose a build of integrated features excluding one that is causing problems in QA.
   

3. Stick to MVP: Always cut features, never change your release date

   The temptation to fire fight a broken feature in a release is always strong, but it’s often the core reason of a delayed release. Frequently developers and product managers will want their new shiny feature in the release it was expected and will operate under the belief that “holding the release for an extra day” is the right thing to do. It’s never the right thing to do.

   By doing this, you prevent any other features in the release from delivering business value on time, and this is always the wrong decision. It’ll hurt, but you should always disable the feature and release, or compose a new build without that feature integrated to keep the steady canter of your release and development cycle.

   If you don’t do this, your next iteration will slip by the time it takes to fix the issue you’re currently facing. Rather, prefer pulling the feature and adding a story to fix it at the top of the next iteration.

   It’s a much more transparent and accountable way of dealing with slippage, otherwise people will expect a larger delivery than is possible come your *next* release, costing you trust.
   

4. Deployment as a first class citizen: Automate your deployment and rollback

   As you tighten your development and release cycles, any form of manual deployment will become a chore on your development and operations team, possibly counterbalancing the benefits of a tighter focus on releasing. You should always treat deployment and installation as a first class citizen. All your software, from day one, should support continuous integration and automated deployment. If you configure software with these characteristics when it’s new and inert you can prevent any large arduous tasks configuring it later.
   

5. Configure old and new behaviour side by side

   If you’re touching particularly sensitive or high traffic portions of your software, ensure you can switch the behaviour between the two implementations trivially and without rollback. Remove the configuration when the new code is “trusted” to prevent costly rollbacks and patches.
   

6. De-scope existing bugs in order to ship

   If an existing bug is threatening your release, de-scope the bug fix to the next release or hotfix it later. Always ship if you’re adding value rather than wait for unconfirmed fixes.

Always prefer de-risking releases for the sake of consistency, it’s a more honest way to deliver software on time.

One of the greatest challenges facing any software company is the risk associated with new releases. As a responsible software development team, you should put just as much emphasis on delivery of the software as you do on development.

The most direct and deliberate way to mitigate the risks associated with software delivery is to stick to the mantra of “Release early, release often”. The surest way to accomplish this is to repeatedly build *and* deploy the minimum viable product and the smallest possible change. Doing this mitigates risk by reducing the impact of a rollback to “just a single feature”.

The reason that this is so important is that it allows you to stick to short and simple release dates, which encourages and enforces predictability into your software development. Your release cycles should be small and take place at the smallest sensible interval on a sliding scale between “as soon as the feature is QA’d” (which represents the least possible risk and the smallest possible change) to “as soon as the current iteration or sprint is complete” (which is often a fair compromise allowing a more coherent shipped change).

Ensuring that your releases happen on simple and consistent dates (for example “Every Tuesday”, “Every day at 7pm”, “Every time QA signs off a feature”) maximises transparency for the rest of your organisation and helps build trust in too-often-opaque software development departments. In addition to transparency you will also gain a tight appreciation for scripting your release processes and increasing your comfort in your deployments due to the increased and and consistent nature of installing software. This focus will quickly surface any points of friction in your software release process that need improvement.

I frequently have trouble trying to copy music onto my iPod due to iTunes’s draconian binding and synchronising rules. These rules exist to ensure that only “authorised” files can be copied onto any given device. Apple implement this by binding your device to a specific instance of iTunes using a randomly generated Persistent Id that’s registered on your computer and on your device.

I have 3 computers that I use regularly, and I regularly rip CDs in different places and want to put that music on my iPod for travelling imminently. By default, iTunes restricts me from being able to do this.

Tonight I hacked together a little command line app to clone your persistent Id’s across multiple machines.

In order to use it, you need a copy of iTunes bound to your device installed on a machine. Once you have that, you run the program in –extract mode, which will show you the persistent Id for that machine. You can then use the program on other computers to patch any installed iTunes libraries to believe that they have the same persistent Id as the “master” machine. It’s a pretty trivial process.

If it breaks anything, don’t come crying, but “works on my machines”. Happy listening.

Source code / detailed instructions: https://github.com/davidwhitney/itunes-persistent-id-cloner
Executable: https://github.com/downloads/davidwhitney/itunes-persistent-id-cloner/4f7dd551998d515108d937d5b39f28a7b2a058ff.zip

The iTunes Persistent Id Cloner!

Small command line app to:

1) Extract the persistent Id from an iTunes library (this is the thing that your device is bound to)
2) Patch up an iTunes library with a persistent Id you supply (I bet you can see where this is going).

Usage:

Compile.

1) Quit iTunes on machine that you want to be considered your "master" persistent Id.
    I'd suggest the one you've already got your iPod / iPhone registered on.

2) Run itunes-persistent-id-cloner.exe -extract
    Write down the Persistent Id it gives you.

3) Install a fresh copy of iTunes on another machine
    Run it once, and quit iTunes.

3) Run itunes-persistent-id-cloner.exe -patch on another machine
    When prompted, enter the persistent Id supplied by the other Id.
    Ensure iTunes isn't running.
    Hit enter.

No friendly error messages or error handling at the moment.
Don't make typos, things might crash. Worse case, you can run / patch a second time.

JustGiving SDIs, ExitUrl redirection and monthly direct debit donations. Y U NO WORK?!

When we first implemented SDI, it worked for everything everywhere. At that time, we accepted single donations via credit card and PayPal, and monthly donations via a recurring credit card mandate where we manually re-requested authorisation on a schedule until the end user stopped it from their control panel. Nice and easy.

SDI operates on a single principle: If you specify an ExitUrl, we guarantee that if the user completes the donation flow, regardless of the success of the donation, you’ll end up with that user hitting the exit Url. This allows people to integrate, validating the donation result using the API, and keeping the user on their website for anything they want to message after. It also hooks in to a few iPhone and Android apps, where that ExitUrl re-launches the application through some nifty JavaScript hacks.

Several months later, we implemented what we internally call “IPDD”, internet paperless direct debit. Which is… kind of cool? Depending on what you think about the awesomeness of lack thereof, of Direct Debits. Suffice to say, charities were begging for it, because recurring donations are really good for them (largely because people forget to ever cancel them, and they’re a solid source of predictable income for financial planning). We switched out our credit card mandate for direct debit processing.

Part of the legal requirements surrounding Direct Debits is that you have to show some *very* specific information in a *very* specific format when the user creates one. Basically, the user needs to know their rights, they need to know how to cancel, and these things are all the more important when you’re just pulling money right out of their account, as a result, we were literally forced to show the success page that you’ll have seen if you’ve set up an IPDD on JustGiving. It’s not pretty, but in short, there’s a reason that all direct debit forms look the same.

Jumping back to SDI, the way we ensure that a user is correctly redirected, is that we don’t give them a choice, this is also the reason that the users don’t see the “leave a message” page during SDI, and that we implemented a default message in the SDI url schema. We hook on to our processing page and immediately send them back to the integrator after we have some kind of response (or send them regardless after 13 seconds). Unfortunately, our direct debit confirmation page comes *after* the processing page (because by definition, it comes after the “donate” click) in the process.

So, long story short: we’re required to show a direct debit confirmation, and SDI needs to hook in before that point and as a result, SDI broke for direct donations when we integrated IPDD and we had to make the choice to leave it broken. Furthermore, the nature of the IPDD produce means that (I believe) we are legally required to supply the user with certain information.

So, rock and a hard place right?

Honestly, at the moment this hasn’t been the most high priority thing to look at, as it’s not a huge use case (this is also why I’m writing this on a Sunday afternoon) but I feel like we need to do *something* about it, but my options are fairly limited.

Here are a few ideas that have been suggested internally and externally with some pros and cons.

· Do a server side call to the return Url to confirm a donation

o Pro: You’ll still be aware of a donation and can sync your data
o Con: Not the anticipated user flow, this kind of various will confuse integrators
o Con: Useless for UI based logic at integrators end

· Move the direct debit “confirmation” information to before the “confirm” button click

o Pro: Almost a perfect solution, as we could then re-enable SDI
o Con: Technically wouldn’t be a “confirmation” page, so may have to get some special sign off from external parties

· Don’t show the confirmation at all, just send the user an email

o Pro: Again, ideal from an integration perspective, may lead to some users to be confused and not realise it’s actually been “done”, so may lead to support issues
o Con: Not even sure if we’re allowed to do this. Would definitely need external sign off

Does any have any other ideas about how they’d prefer this to work? Regardless, I hope this answers some questions related to this problem.

For my part, I’d love to fix it, but it’s not super high priority right now. HOWEVER, if there’s something we can do practically with a small amount of effort, and the demand is there, I’m sure we’ll get it looked at much sooner.

(Cross posted to Google groups and my blog for seachability)

Oh dear lord, I’ve just lost two days of my life trying to find the exact incantation to persuade a fresh install of Windows Server 2008 R2 to act as a file server on my home network. I did this last two and a half years ago, and it’s taken me two days to regain the knowledge.

Here’s the list of things you need to do to make it play nicely, both with anonymous / legacy accounts and operating systems, and to allow access control for protected shares.

1. Add the file server role
2. Modify the Local Security Policy –> Local Policies –> Security Options
1. Network access: Allow anonymous SID/name translation = Enabled
2. Network access: Do not allow anonymous enumeration of SAM accounts = Disabled
3. Network access: Do not allow anonymous enumeration of SAM accounts and shares = Disabled
4. Network access: Let Everyone permissions apply to anonymous users = Enabled
5. Network access: Restrict anonymous access to Named Pipes and Shares = Disabled
6. Network access: Sharing and security model for local accounts = Classical
7. Network security: Do not store LAN Manager hash value on next password change = Enabled
8. Network security: LAN Manager authentication level = Send LM & NTLM – use NTLMv2 session security if negotiated
3. Flush your group policy like a boss (gpupdate /force)
4. Control Panel\Network and Internet\Network and Sharing Center\Advanced sharing settings
1. Turn on network discovery
2. Turn on file and printer sharing
3. Turn on public folder sharing
4. Turn off password protected sharing (else nobody will be able to browse to machine names)
5. Turn on the Guest user account
6. Create any user accounts you want to give specific access to.

Now: Anonymous users will authenticate as the guest account, so “Everyone” network sharing will work fine, and you can specifically log on to the server as SERVERNAME\user for specific access rights on mapped network shares.

It’s just that easy.

Yeah.

So this year @JustGiving we’re going to be making a little bit of a big deal at Charity Hack 2010 by releasing the first round of public JustGiving APIs.

The new JustGiving APIs are a suite of RESTful resources covering a few key areas of the site, debuting at Charity Hack 2010 after closed testing as the tech powering the JustGiving iPhone, Android and Facebook applications.

Headlines: JustGiving. RESTful APIs debuting at Charity Hack 2010. Fully documented and with code examples in major languages.

We’re covering four key areas: End user accounts, Fundraising Pages, Search and Donation Integration.  Don’t worry, this post isn’t the documentation, instead, it’s a bit of a teaser.

Account

• Account Registration

Fundraising

• Get Fundraising Page Details (key page details)
• Get Fundraising Page Donations (with pagination)
• Get Fundraising Pages (retrieving all pages owned by the authenticated user)
• Fundraising Page creation (automate page creation)
• Update Fundraising Page (to modify details and user stories)
• Upload Fundraising Page Image (upload new FRP photos to the gallery)
• Fundraising Page Url Availability Check (check the availability of JG Page Urls, useful paired with creation)

Search

• Charity Search

Donation

• Get Donation Status (for a given donation Id, check the processed state of the donation)

Simple Donation Integration (SDI)

SDI is similar to PayPal’s Express Checkout allowing partners to funnel their users through the JustGiving donation process as part of the flow of other / existing applications.  It’s designed to be partnered with the Donation Status API methods.  The idea is, a user is redirected / pushed through to a web browser directly into the JustGiving donation process.  The user makes a donation and is then redirected back to a call-back Url on the originators domain.  This call-back will optionally pass the donation Id of the users donation on the query string, allowing the destination site to query the status of the users donation.

This may be of extra interest to mobile application developers, as combined with registering protocols for your mobile app in iOS or Android, this will effectively enable you to take donations in your mobile applications.  SDI powers the recently released Facebook JustGiving Charity Gifts application.

I’m going to be there on the day with a few of my colleagues to babysit the APIs and answer questions, but more importantly, I’m going to be there as a hacker. Obviously we can’t really compete in any of the "hack offs", but we might well end up cooking up something cool or fun on the show floor.

The APIs we’re going out with are RESTful and use XML as the content-type (boo!), but if you dig deep enough, we might well just be respecting other content types (in an unsupported, on the quiet, kind of way) if your client asks nicely (yay!).

Happy hacking!

A quick note: I’ve upgraded MobileTFL to version 1.0.0.9.

Get it here.

+Fixed critical bug due to data format changes.
+Reworked parsing of source data so it’s less sensitive to format changes in the future.

Apologies for the rapid releases, but hopefully the app should be good “long term” as of this release.
There will be one further release in the near future consisting solely of cosmetic changes.

A quick note: I’ve upgraded MobileTFL to version 1.0.0.8.

Get it here.

+Improved loading speed (less start up lag)
+Fixed critical bug due to data format changes

I’m planning on listing this app on Windows Mobile Marketplace when it launches later in the year for a small fee (£1.50 ish).

Don’t be alarmed if you see this happen. The software will remain free to download from the web (likely relocating to www.electricheadsoftware.com), however there will be above mentioned small fee for those wishing to show support / download it off Marketplace to cover initial costs (certification / enrolment in Marketplace isn’t free).

I’m looking forward to seeing how well a small utility app can do in the wider Windows Mobile “consumer” market as a test bed for a few future projects. I’d appreciate it if people showed support if they fell it appropriate.

There was a piece on Kotaku this weekend looking at the development at AI in games, It specifically set out to ask leading figures what they thought of the development of virtual “beings” in games,

“Kotaku set out to ask experts in the fields of Hollywood movie magic, theme park creators, robotics experts and AI specialists to answer the question: Do the AI-controlled characters in games qualify as robots or some other form of artificial life. Are those creatures who are at the player’s mercy in Lionhead Studio’s Black & White games truly virtual beings?”

Inside the article was a rather worrying quote from self declared futurist Thomas Frey, executive director of the DaVinci Institute,

"In short, our games have indeed evolved into crude life forms," said Frey. "Innovations in the digital world are happening exponentially faster than in the material world, so the digital beings in games will soon become far more lifelike, and will eventually step out of the screens and exist as 3D avatars, interacting with us, much like other people."

I always get a little upset and slightly concerned when people from places like the DaVinci Institute (from their "about us" page: "Launched in 1997 as a non-profit futurist think tank, the Institute has emerged as a centre of visionary thought, attracting both a national and international following of idea junkies and business leaders alike.") start to talk about things like programming and AI.  I always feel like these kind of think tanks highlight a bit of a problem with the development of new technology.

All you learn is that "futurist thinkers" actually have no grasp on the practical implementation of the technology.  I’m all for creative thinking and speculation, but somehow implying that very simple game mechanics are going to develop rapidly and with little to no point into some Skynet like Ai is simply absurd. 

Thankfully the Kotaku article actually asked someone with half a clue (Chris Darken, conference chair for Artificial Intelligence and Interactive Digital Entertainment and an associate professor of computer science at the Naval Postgraduate School) who equated videogame AI to an expert system.

In all honesty it’s a stretch to even call them that.  The problem domain that your average game AI lives in is so rudimentary small that I’d rather use a phrase closer to "novice system".

Game AI is nowhere near close to simulating human behaviour, near all "humans" are scripted, and the most simulated behaviour comes from games like Spore or The Sims where the actual behaviour is so generalised (eat/sleep/mate/die) that any nuance of actual behaviour is lost and what results is little more than a general abstraction to suite the purpose of game mechanics; which is utterly perfect for the task at hand, because honestly, developing something more sophisticated would be a huge undertaking with no practical benefit to the game project.

I’m honestly perplexed as to why some gamers seem to think building “AI” is appropriate for a game.  The term AI is exceptionally misleading and would likely never be appropriate unless you were working on something that wasn’t as strictly defined as your average “regular” game environment.

Imagine playing a game where a key NPC suddenly decides that they just weren’t into the plot anymore and just stopped playing, a “real AI” of this nature just isn’t for purpose.  I’m not suggesting that what we perceive as “AI” in games doesn’t have room for improvement, far from it, I am however suggesting that games will never lead to developing a “true” AI, simply because it’s not an appropriate avenue to approach game design from.

People need to realise that good path finding is not the same thing as intelligence, and that they probably wouldn’t actually enjoy a game where the AI attempted to simulate sentience.  It’s work enough dealing with other players in a multiplayer game, let alone having to contend with a simulated intelligence in a single player oriented experience.

Just a quick note here as I had to do a lot of digging to fix this issue.

Issue: HTC Diamond (potentially other models) not waking up from “sleep mode” when you have an email send/receive schedule. Instead, when you wake the device up it establishes a connection immediately and performs the check.

Problem: It appears the root of the problem are two registry settings that define how long a process is allowed to attempt to wake a device from sleeping before it is terminated by the OS. Evidently checking email takes a number of seconds. I’m not sure what the default value is in a stock ROM, but in a few of the custom ROMs I’ve used this value is 1. 1 seconds generally is not long enough.

Solution: Change the following registry settings to a value in seconds that represents the tasks you’re expecting to wake up your device. I’ve got my device set to 15 and it happily collects email while sleeping and provides a glowing / audible notification.

[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Power\Timeouts]
“BattResumingSuspendTimeout”=15
“ACResumingSuspendTimeout”=15