Mat's Blog

I have to start with the caveat that this is just the typical flow I have seen and I've used myself. I'd love to hear about your experiences developing for iOS in larger groups.

Development would first begin in interface builder by adding the UI component(s) that are required. I try to do as much in interface builder as possible and keep the controller lean.

Then you would go back to the controller and implement the appropriate commands. Ideally you would want to test that you've connected the view with the controller properly. I usually use the debugger to test this but in a larger project we would want to build an automated test here following good TDD practices.
The rules for where to go from here diverge a bit and become less clear. Depending on the task you might have to modify the core data model or perhaps there are some communication components that have to be called. Every developer will have their own preference on what step to do next and the steps are less prescribed.

Here are a few tips for smoother development

• test often and commit whenever you have a working copy. by testing after every little change you'll find that you'll save yourself a lot of time in debugging later.
• aim for a simple solution to a problem. if it looks like it's getting complicated step back and reexamine your approach. there is often a better way and this is the time you should ask others around you for their ideas.
• get something working and then proceed to refactor the code. don't forget the refactoring step as it is really important.
• if you have to make a large change to the model I would suggest discussing it with other members and perhaps even the product owner. the product owner will often have insight on future additions to the app that might affect how you would design the schema.


When it comes to code quality a developer always wants to follow these rules
• you want code to be readable and easy to understand. above everything this reduces complexity and will reduce bugs.
• unless you break readability you want to reduce the amount of code possible. Typically the longer the code the more bugs it will have.
• remove duplication in code. This is still reducing the amount of lines of code but it does more in that it allows for reuse of code and separation of similar logic which usually improves readability.
• Read Refactoring by Martin Fowler and follow those principles. Chapter 2 explains the reason we want to do all the things mentioned here.

I haven't posted anything to my Blog in a while and I thought a little evangelistic blog post about agile development was a good place to start.

I wanted to make a few comments about the Scrum Master role.

In agile development the goal is to have small iterations that can be delivered earlier to the customer. Scrum helps to achieve that goal by creating three roles a product owner, scrum master and team members. The role of the Scrum Master may seem simple on paper but it is actually fairly complex and requires lots of attention in order to do it well. The primary goal is to make sure that work gets 'done' without any roadblocks. This in itself is difficult because the definition of done imposes a threshold of quality that is expected for the sprint. It's important to have done defined and to follow it faithfully. The longer features have to wait before being delivered the less value we are providing, and bugs and defects in the product will cost everyone much more in the long run, especially when you account for how bugs affect customer satisfaction.
The Scrum Master also has the role of trying to facilitate continuous improvement in the team. This can be everything from delivering more features or improving quality to improving the working conditions or dealing with certain individual needs. It is important to remember that the Scrum Master is a facilitator and it is the team that needs to participate and self organize to do better.
Whenever we have issues in delivering the high quality product we want and delivering it on time it is an opportunity for change. We want to be able to deliver a product after any or every sprint. Until we are able to do that with confidence we are not done.

The most important time in the sprint for me has always been the retrospective. It's the time to reflect on what can be done to be more effective.
"Why did that bug sneak through?," or "why was that story rejected" are questions you should be asking and the whole team should be trying to find solutions.
Don't go overboard either, try and solve and focus on one or two things and try to address them immediately in the next sprint. If you focus on too many things during the retro then you also have the problem that nothing gets addressed properly. Also make sure you review the changes you made last week.

I was reading an article yesterday about Opera making it to the iPhone store. I am extremely pleased by this decision because it shows that Apple is ready to allow 3rd party apps that replicates their apps if they are done well.

Of course the Opera mobile does have the extra benefit of doing pre-compression before it makes it to the phone.

Congrats!!!

It's officially released. Go and download the latest versions of Document Courier and Document Sync.

Now you can upload full folders with one easy step.

Document Sync and Document Courier

This was an error that had me banging my head against the wall for a while.

If you are using an XMLHttpRequest you might get the following error.

JavaScript - widget://682251721593684393281251651206/index.html
Event thread: _index
Error:
name: Error
message: Security violation
stacktrace: Line 118 of linked script widget://.../script/script.js:
http.send(null);

If you are like me you read the Article from opera about ajax and widgets. This applies to Unite as well.
Opera Widgets and Ajax: connecting to multiple servers

The one thing they don't mention here is that you need to enable network access for your app.
This is how you do so.

<widget network="public private">

So our reign has finally ended. There is a new file uploader with pretty much the same features except it allows you to manage your files from the interface and not only from the operating system.

I had some issues running it on my mac not sure why but feel free to download whichever suits your fancy.
Once I have a bit more free time (it is summer after all) I am planning on doing something cool with it.
So you might want to stick around.

Haven't blogged in a while, but that's because we are nearing
a deadline at work and that is keeping me busy.

However we did get some work done and were able to push up a new version.
You should see it soon.

The one thing that I find hard in Unite is to do the testing.
I am referring to unit tests and functional tests.
Because it is sand-boxed it is really difficult to test apart from inside the unite system.
I am thinking I might be able to create another config file to load my js file with my code.

I haven't blogged in a while but I will later this weekend. Expect a post about running a background task this weekend.