So, I don’t think there is any point in me trying to deal with the problems found in 1.2.4. Instead, I’d rather be involved with getting under the skin of the new version (which should give me more blogging material), and hopefully contribute back towards its development in any way.

For those of you keeping track of this framework, the early documentation for this can be found here.

I was interested in seeing if there was a better way to organise custom HTML template tags in the tags folder, in order to prevent any clashes in my templates. Non of the documentation explicitly explains how to do so; the only references as such only refer to writing custom Tags in Java and annotating with @FastTags.Namespace.

On a hunch, however, I tried creating a child folder in my Tags folder, and treated that as a namespace (as in Java) and it worked! For example:

would look for the HTML Template Tag as

or

Hopefully this helps someone else who comes across this requirement in their project. Note that this might have side-effects that I am unaware of (other than clashes with existing template tags, or custom Java tags). As far as I’m aware, this is an unsupported feature of the template engine, so use at your own risk I suppose.

The Problem

So you have a project that you deploy on AppHarbor. However, you’re almost at launch, and you are now just starting to think about multiple environments, and you have separate development branches in your repository.

Unfortunately, AppHarbor does not support this explicitly out of the box, meaning you will have to work around what they provide; the main thing that AppHarbor doesn’t have at time of writing is the ability to define which branch you want it to build from. This limits what you can do with your repository from the start, meaning that before you are able to build to a “dev” environment, you need to merge that branch with your “master” branch and push that instead.

Or do you?

The Solution

The first part of the solution is simple: set up different applications for each environment you want. You can then set up Environment Variables for each one. For any decent project set up you will want at minimum 2 (development, and production), but this solution can be scaled to fit your needs (nightly’s, staging/UAT etc.).

But then you say “Daryl? You just said that AppHarbor does not support building branches. How is this going to work?”. Well, the answer is we’re still going to “push” to each application’s Git repository, but with a little Git trickery.

What we’re going to do is simply tell our source Repository to push our branch to a different branch on the remote end (in this case, I push my “dev” branch to the “master” branch on the remote end!)

The Magic Commands (execute them on your source repository):

> git push <appharbor-dev-url> +dev:master

What we’ve done here is simply specified a custom “refspec”[1] that pushes our local “dev” branch to the remote’s “master” branch.

If your “dev” branch is not a descendant of the remote’s “master” branch, you may need to force it using the “-f” flag.

With this, you can now have multiple branches for each environment, allowing you more powerful control over your project environments.

Disclaimer: I’m no Git Guru, this is simply how I’ve figured out my way around it. Hopefully a better way comes about when AppHarbor gets to it. Also, I make no guarantees for the safety of your environments, source, and repositories… be doubly sure before making any drastic actions.

1. git push reference
2. git branch reference

I, however, wanted to look further ahead into the future.

It is increasingly certain that neither Facebook nor Google+ is ready to go away without a serious fight, and users in either camp will benefit greatly. However, there is still an area of interest left that could see great innovation thanks to Google’s efforts, and that is in the Mobile space.

Google+ currently does not have the userbase of Facebook, nor the mature feature set that Facebook has built over its years as one of the internet’s most frequented site ever. What it does have, however, is a platform that is quickly becoming a behemoth in the mobile OS space. Because of this, I definitely expect Google to make strong innovative moves once Google+ goes live, and I also expect to see a symbiotic relationship between the two platforms emerge as part of this effort.

What I imagine is not exactly the same as what we have today; Facebook has apps available for installation on all major mobile platforms, and Google+ has plans to do the same. What I hope to see in the future is Google+ integrated into the Android device and its hardware capabilities, and I will list a few ways I believe Google+ might change the way we use our devices.

Photos

Nowadays, it is easy to take a photo and share it with your friends via your preferred social medium. Google+ makes it easy to do so by uploading images you take immediately using Instant Upload.

The problem, though, is that there is only 1 owner of the image, and that is the person who took the image. This owner must then share the image with whoever requests it, which can be a tedious task for many people.

With our Android mobile device, we could possibly detect the mobile devices in the picture, and immediately transfer copies of the image to each individual while the Instant Upload feature also shares the image with them on Google+ in an appropriate circle. No more “please send me the images from last night thanks!” messages the day after, and no more need to tag!

Networking

There have been examples of networking applications, such as Bump, which allows two mobile devices to exchange their contact information just by “bumping” their devices together. However, it does not have the power of a strong social network foundation to build on.

With our Android mobile device, we can have contacts shared between devices as a standard tool. Meet someone new at a party? Immediately follow each other on Google+ and include them in a circle just by “bumping” each other.

Circles of Devices

While Google+ has circles of Friends, Android could have Circles of Devices; a collection of devices between which information can be freely shared. Think of it as a whitelist of paired devices a la Bluetooth.

This opens up many possibilities for App development. Now you could keep track of your friends whereabouts via GPS (of course, subject to Privacy controls), and get notification if one of them happens to be close. This could turn out to be an excellent extension of Google+ Hangouts.

These are just some of the many ways I believe Google+ can revolutionise the Android platform, and provide its App developers with new toys to play with in the future. What other things can you think of? Let me know in the comments below!

What is CQRS

CQRS is an Architecture (for reference, see N-Tier Architecture) basically just a simple set of principles when thinking about your system’s design. As such, any implementation of CQRS is merely a technical detail that should only be considered by the architect after considering the constraints of the environment.

CQRS is essentially made up of 2 parts:

• Commands,
• and Queries

Commands are constructs that model The User’s Intent. So for example, if the user intended to add a new post, the command could be “AddPost”. You will therefore have as many Command definitions as there are Use Cases for your system (see Pros), and each Command encapsulates all the information required to perform that action.

Queries are simple and familiar: they can be anything that retrieves information from your model. Again, this is a mere implementation detail, which I will go into further. To give you an early reference, NHibernate ORM Framework could be an example of a Query implementation.

CQRS simply says these two should be logically separated by their responsibilities. Don’t build the same code to deal with both.

CQRS Objectives And Motivations

The motivation between this logical separation lies with 2 different concepts: collaboration and staleness (http://www.udidahan.com/2009/12/09/clarified-cqrs/, Why CQRS, Udi Dahan). CQRS puts forward the notion that data, by its very nature, is intrinsically stale; when data is pulled from a data source, the source may change at any time. Stale Data makes dealing with collaboration an architecture nightmare. Dealing with Stale Data also reduces the scalability and performance of such a system as it grows, as it introduces bottlenecks at every layer.

CQRS says: let’s simply accept this as the nature of data.

The two parts of CQRS is therefore driven by its single principle, which is to logically separate the retrieval of data from the altering of data. Retrieving data should be simple and fast, with disregard to its freshness. As a result, Commands do not need to Read-Lock the data, making DB performance a lot better.

Implementing any architecture in this fashion forces the it to fall into two distinct subsystems. Furthermore, as each system models different things (Commands/Intent/Action and Queries), there is no code reuse between each subsystem. This makes the two subsystems easily divided and independent.

Potential evolution of a system using CQRS

Let’s see how CQRS can allow an application to EVOLVE.

User A requests a View of a specific Movie in a Rental Database. This View queries the database and the View renders the data. User A then clicks the “Rent” button, which initiates a new Command “RentMovie”, which contains the id of the Movie. Sometime in the future, this Command updates the Database. The User is then redirected to a Confirmation screen.

Meanwhile, User B has also loaded the same View with the same Movie at the same time as User A. However, he clicks the “Rent” button after User A. Again, the Command updates the database. However, the selected movie was already rented, and the User is redirected to a Failed screen as a result.

Lets now imagine Admin A has opened up the same Movie, and wishes to make minor edits to the Movie’s description. He clicks the “Edit” button, which initiates the “EditMovie” command. Due to the nature of the system, this command is considered to be a low-risk command. Therefore, this Command is processed asynchronously from the Admin’s response: he simply gets a message telling him to check back later when the Edit command has gone through.

At this point, this is simply your standard CRUD application, except that we’ve made the distinction between Commands and Queries. Our Commands at this point could simply be methods that are invoked. Now let’s see what happens when we decide to scale our application.

This Rental Database is growing in popularity. But Users are reporting slow responses due to many people attempting to rent a movie. In order to cope with this, we implement a Command Pattern, together with a CommandQueue. All Commands are now inserted into the Queue, in order to regulate the number of Commands being executed at one time.

Users are still reporting that Renting a Movie takes too long. This is because the Queue gets swamped with Commands. Because our Commands are separate from our Queries, the Command Subsystem can now be separated from the Query Subsystem, and placed in a separate high performance application server(s). Additional tweaks can also include a priority Command system in your CommandQueue.

The Rental Database is increasing its library of Movies since its launch; the time it takes to perform a set of queries is increasingly slow. Since we are not worried about the freshness of data, let’s create a separate data source only for queries. In fact, we could have any number of query data sources, since we are not concerned about the consistency of the data with other duplicate sources. Our Query Subsystem can be scaled independently from our Command Subsystem. Now, we just need to keep our Query Data Sources in sync with our original data source.

However, updating each data source synchronously might be too time-consuming, and there really isn’t any need for our Query data store to be so up to date. Lets implement a replication job that grabs a snapshot of the original source every few minutes and push them out to our query data sources over time.

Still too time-consuming? Why not store our Commands in a historical database? We can then use this as a means of updating our query data sources; no need for expensive data replication services. And this also becomes a useful backup of actions that can be used to reconstruct the database.

This is a possible example of a mature application evolving using CQRS principles. There are many architectural changes that are now an option due to how we have structured the system.

Pros of CQRS – or why would you use it

CQRS allows your system to be infinitely more flexible when growing your application, simply because you no longer have common “reused” code for the two distinct set of operations. If you expect your application to have longevity, and want to respond quickly to change, CQRS is a valid option.

From a engineering perspective, Commands map to Use Cases very easily; each Command encapsulates a single use case (Business Analysts rejoice!). This means that Commands and Use Cases have a 1 to 1 relationship that enables people to write Test Cases very easily. This can speed up development of a large scale project.

Cons of CQRS – or why would you not use it?

It could be very difficult to insert into existing architecture. CQRS can be considered a foundation from which to build up on; don’t rewrite all your domain driven design components to fit.

Response to Users also becomes slightly difficult due to the tendency for Commands to become Asynchronous (you can’t have them sitting in a queue forever, especially if you implement a priority system). Therefore, the way your application interacts with users has to be evaluated.

Lastly, if your system does not require longevity, and scaling, or does not require high numbers of collaborative operations, your system may not benefits as much from sticking to CQRS principles.

Closing

CQRS looks to have some great use cases, especially in the Web Application space. It can work with existing frameworks in most cases, and does not require you to implement all of it at the beginning, making it ideal for startups. And remember: CQRS does not need to be complex;it is simply a different way of architecting a system (just like you have different ways of building a house’s foundation)

Definitely consider this if you are starting a new project; I definitely am!

Edits

• Redefined CQRS as a principle, not an Architecture. See link.
• Added paragraph to “Cons” section
• Major editorial changes to multiple sections

After some thought, I decided on the following concept for the assignment: a rural fire warning application for people living in potential bushfire zones in Australia, coupled with current social networking trends.

The concept itself raises several issues.

At first I searched through the Bureau of Meteorology(BOM) for any data that could be consumed for the app’s purposes. However, most of the BOM’s data only deals with weather forecasts; any inclement weather warnings are listed as textual press releases, not in any easily consumable data formats.

This then led me to look elsewhere, which eventually landed me at the department of Geoscience Australia, which provides maps similar to what I was aiming to accomplish with my application. These maps are constructed from data organised by the Sentinel national bushfire monitoring system, which pulls from the latest data generated by NASA’s satellites, namely the Moderate Resolution Imaging Spectroradiometer (MODIS). Unfortunately, these maps were self-contained; again, no data feeds from which I could pull from. MODIS itself was unhelpful; although I eventually did find some data, I still could not make sense out of all the raw data that was available (I’m no meteorologist!).

So I turned to the Country Fire Authority, to see if there were any information I could grab from them. As it turns out, they provide RSS feeds of the latest warnings for public consumption! This was great news; I could use the RSS feed and display them on my application.

As it turns out, it wouldn’t be that easy:

1. The RSS feeds do not provide any clear information, just street names. This means there will be a margin of error narrowing down exact locations to display on a map.
2. Since it wasn’t bushfire season, there was no sample data I could build off. I would have to contact them in order to get a sample.
3. Some feeds only give images; there would be no way of customizing my own maps from data.

Next came a even bigger problem: each state/territory in Australia has its own department for bushfire response (CFA in Victoria, RFS in New South Wales etc.), and each of these departments had their own feeds. This meant it would be nearly impossible to provide a consistent representation for all the data that was available from different states.

There are other resources I have yet to investigate, so I will continue to assess the feasibility of building this application. Stay tuned for Part 2!

At the end of the semester I am required to submit a Major Project. This project is relatively flexible; students are required to develop a iPhone application based on a specific theme (Climate/Weather), however the actual application itself is to be designed by students. It must have at least 3 major features, while utilising a minimum number of advanced iPhone tools(such as MapViews, Multi-View applications, iPad portability etc.).

At the project’s conclusion, students are also required to give a presentation on the project, describing its concept, features, and development. So, I aim to record my progress on this assignment through to its completion, mainly so I may refer to it again when I do my final presentation!

Here’s looking forward to a healthy update schedule once more.

It is with great pleasure that I present to you, on behalf of my team, Gwisher.com.

The premise is simple; guys who have no idea what to get their girlfriend on an important occasion use Gwisher, inputting various information regarding their girlfriend, and Gwisher returns a list of suggestions that he may get for his girlfriend. Our advanced “Gwish” engine processes this information in order to give the best suggestions for the user.

It was definitely a great 12 hours of non-stop frenzy, and I definitely recommend this experience to anyone.

There have also been a variety of reactions to this, from the informed (“I don’t like it, but Apple has every right to do so”) to the very ill-informed (“Flash Sucks!”), so let me state my position in the matter: this whole thing stinks like a dead carcass wrapped in burnt bacon thrown in a washing machine filled with raw sewage.

The Matter

The reports point to a new clause in section 3.3.1 of the iPhone 4.0 SDK, which states

Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited

and the expectation is that Apple has effectively removed any chance of Apps compiled using Flash CS5′s compiler (or any other compiler aside from the iPhone SDK) from entry into the App Store.

There are numerous reasons being cited for this new development (via comments), including:

1. performance is impacted (by Flash)
2. battery life is reduced (by Flash)
3. Apps produced by other tools for cross-platforms do not take advantage of the iPhone’s strengths.
4. This is just to prevent alternative App stores from popping up.
5. Apple does not want people to create apps for free without going through the App store.

However, most of those points are complete and utter troll drivel.

The Facts

Lets be clear on all the facts.

Performance/Battery Life

This has got absolutely nothing to do with performance, or battery life. In fact, it has nothing to do with Flash at all. Flash CS5 is merely the tool that allows you to compile native iPhone applications. So the result is a native iPhone App. There is still no Flash on the iPhone, neither is Flash running on the iPhone at any time. So any complaints about Flash sucking away performance or battery life on the iPhone is completely irrelevant. To categorise Apps compiled on anything other than the iPhone SDK as battery and performance sucking vampires is just short of “Guilty until Proven Innocent” except in this case, there’s no chance to prove an App’s innocence.

Circumventing the App Store

There is no way (bar jailbreaking your iPhone) you can get an App onto your iPhone. Plain and simple. Any claims that say otherwise are simply wrong. I say again: these are native applications compiled for the iPhone, and submitted through the App Store. There will not be new App Stores popping up allowing you to sell Flash iPhone Apps.

The Reason

Lets think about this carefully.

Apple already have control over the Apps that go on the iPhone via the App Store review process. This allows them to reject any Apps that, as those concerned have mentioned, suck away battery life and performance, or Apps that don’t conform to some black-box review requirements. Furthermore there is definitely no way Adobe, or anyone else, will be able to set up a new App Store for downloading new Apps. Nor is Flash running on the iPhone at anytime. And if an App doesn’t take full advantage of the iPhone because of its cross-platform nature, why should this be an impact on the App Store, the store with thousands of Apps that somehow got past Apple’s quality review process. Why would they do this when they already have full control over the iPhone?

Because the only way you can build Applications for the iPhone is by buying a Mac.

Apple doesn’t want anyone without a Mac to compile applications for their flagship mobile products, increasing in market share by the minute (and even more so with the launch of the iPad). So once they realised that people were writing tools to compile for the iPhone on anything other than an OS X, they take steps to stamp it out. iPhone development is one of the big drivers in iMac and MacBook sales, without them you can’t build for the iPhone.

Conclusion

So there you have it. While Apple has every right to do so, it stinks as hell. And I hope someone with some balls and brains has the ability to see that. And, as John Gruber puts it, “[Adobe are] pretty much royally fucked”.

Author’s Note: Apology for the inflamatory language. While I don’t even work with Flash anymore, I hate to see these sorts of things happening, and the people doing it getting away with it.

I’ve mentioned to people before, Adobe is at a critical point here. They can choose to sit on their arses and ignore HTML5, which will steamroll Flash when it does come into play. Or they can choose to do something better with it. Adobe’s strategic advantage will be that they have control over the progress of the Flash platform, and they need to use that to quickly make itself relevant in a HTML5 world.

In the meantime, HTML5 is certain to replace everything else Flash is known for. Video, minimal animations and transitions for websites through CSS3 and Javascript, offline storage and rich applications. Flash needs to find a new niche to remain relevant (not surprisingly it will probably need to solidify its position as a browser gaming juggernaut) and they should be able to do that quickly without the need of a new web standard taking years to ratify, and browsers to uptake. They may even manage to do this without HTML5 gaining significant market share.

Pro-Flash campers need to see this as progress in web technologies and use the right tool for the job, not stick to their hammers for screws.

Anti-Flash campers need to see that Flash can still be a crucial technology on the web, and stop trying to mold HTML5 into something so complex that even it itself becomes a crutch on the internet, in the fool’s hope of crippling Flash with a “Anything you can do, I can do better” charade. K.I.S.S.

In essense, stop this senseless Flash hate. Killing Flash will not get rid of ads, or popup videos, or get rid of browser vulnerabilities. Yes Flash Player is shit on non-Windows systems. Yes it has vulnerabilities. But those can be fixed. Focus your energies on getting Adobe to fix shit, not on Flash.

Anyway If you’re reading this, Adobe, the ball’s in your court at the moment. Show me what you can do.