Here’s a nice little utility that can be found on a once difficult to navigate but now very much improved website. In case it’s not immediately apparent what I’m referring to, I’m talking about the ‘UrlRewriteFilter‘ featured near the top of the page. This handy Filter implementation allows you to configure mod_rewrite style URL rewriting rules for your J2EE webapp. You can also use this direct link to download ‘UrlRewriteFilter‘ version 3.2.

Sadly some of the information on the official ‘UrlRewriteFilter‘ website pertaining to setup and usage of the filter is incorrect/out of date. This is quite a shame, because ‘UrlRewriteFilter‘ is an excellent little utility and I’m quite tired of seeing people needlessly running multi-server configurations (typically Apache httpd for static content, and something like Tomcat, Resin, Jetty, etc. for dynamic content) out of a desire to use this-or-that particular module that only works with httpd or (even worse) out of the outdated notion that servlet containers cannot efficiently serve static content. So in an effort to save ‘UrlRewriteFilter‘ from obscurity, here is a complete set of instructions for getting the filter to work in your webapp.

First, you will need to ensure that the ‘UrlRewriteFilter‘ JAR file is on your web-application’s classpath. How you do this will depend upon your build process/how you are constructing your webapp(s), but long story short placing the JAR file in your webapp under ‘/WEB-INF/lib’ will do the trick, and if you’ve spent any time at all working with webapps you probably already have a preferred way of doing this. Alternately, you may want to install the JAR file in your servlet container’s ‘/lib’ folder, particularly if you are deploying multiple webapps on your server and you want to have ‘UrlRewriteFilter‘ available to any/all of them automatically.

In any case, once you have the ‘UrlRewriteFilter‘ JAR on your webapp’s classpath, the real setup can begin. Open your application’s ‘web.xml‘ file, and add the following filter configuration to your webapp:

[xml]<!– URL rewriting –>
<filter>
<filter-name>UrlRewriteFilter</filter-name>
<filter-class>org.tuckey.web.filters.urlrewrite.UrlRewriteFilter</filter-class>
<init-param>
<param-name>logLevel</param-name>
<param-value>WARN</param-value>
</init-param>
</filter>
<filter-mapping>
<filter-name>UrlRewriteFilter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>[/xml]

This instructs the servlet container to route every request that the server receives through the ‘UrlRewriteFilter‘. Note that although it is not discussed on the official site, that ‘logLevel‘ parameter is essential. If you omit it, the filter will fail to initialize properly and will yield some very bizarre behavior.

Anyways, once your ‘web.xml‘ has been updated, the final step is to add a ‘urlrewrite.xml‘ file in the same directory as your ‘web.xml‘ file, and configure it to your liking. Here is an example ‘urlrewrite.xml‘ file with a couple basic rewrite rules:

[xml]<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE urlrewrite PUBLIC "-//tuckey.org//DTD UrlRewrite 3.2//EN"
"http://tuckey.org/res/dtds/urlrewrite3.2.dtd">
<urlrewrite>
<!– user-account activation link –>
<rule>
<from>/activate/([a-f0-9]+)?(.*)</from>
<to>/userController?action=activateUser&amp;token=$1&amp;$2</to>
</rule>

<!– default rule included with urlrewrite –>
<rule>
<note>
The rule means that requests to /test/status/ will be redirected to /rewrite-status
the url will be rewritten.
</note>
<from>/test/status/</from>
<to type="redirect">%{context-path}/rewrite-status</to>
</rule>
</urlrewrite>[/xml]

This defines two rules. The first simply rewrites URL’s of the form ‘/activate/######?[params]‘ to something like ‘/userController?action=activateUser&token=######&[params]‘, and the second is the default example rule that comes with ‘UrlRewriteFilter‘ and allows you to see a basic diagnostic page by pointing your browser at ‘[your server]/test/status‘.

That’s about it, and now maybe there’s one less reason to continue running two distinct server instances where one would do just as well.

Here’s a simple but useful tip if you ever find yourself needing to install the AIR runtime onto an emulated Android device. I’ve got no idea why this process is so poorly documented elsewhere, so I’ll try to keep this as clear and to the point as possible.

Suffice to say, if you want to install the Adobe AIR runtime on an emulated Android device for testing or development purposes without having to wade through a ton of fuss and nonsense, you have two basic options. The first is described briefly here, and basically involves installing the latest Flash/Flex/AIR SDK from the official website and then grabbing the AIR runtime package from ‘<AIR_SDK_ROOT>/runtimes/air/android/emulator/Runtime.apk‘. This file is the AIR runtime that must be installed on the emulator for any apps built with Adobe AIR to function. And this method works fine if you don’t mind downloading and installing the entire AIR SDK (90 MB) just to grab this one file.

You other option is to use this direct link to download just the AIR runtime package (6.1 MB). Note that this is version 2.7 of the AIR runtime, and has been tested with an emulator running Android 3.1 only. I cannot vouch for it working with any other configurations.

In either case, once you have gotten ahold of the the runtime .apk file, installing it on your emulator is a simple process. All you need is the ‘adb‘ utility that is included in the “Android SDK Platform Tools” package (note that this package is not the same as the similarly named “Android SDK Tools” package). If you don’t have this package installed yet, then use your Android configuration manager to install it. Then simply navigate to ‘<ANDROID_SDK_ROOT>/platform-tools‘ and run the following command (while your Android emulator is running):

[text]
adb install /path/to/your/AIR/runtime.apk
[/text]

This will install the AIR runtime on your emulated device, and you can now install and run AIR-based Android apps on your emulator. Quite simple, really. Which only doubles my confusion with respect to why this simple process seems to be so poorly documented online.

Here’s an excellent little project for anyone that creates or works with iOS libraries:

https://github.com/kstenerud/iOS-Universal-Framework

This project provides shell script that will add a new Project Template to Xcode, one that can be used to build universal iOS frameworks. Now this wouldn’t be a big deal (and in all rights, shouldn’t be a big deal), if not for the fact that for some unspecified and frustrating reason, Xcode has no built-in ability to create such frameworks. This means that up until recently if you had an iOS library that you wanted to use across many projects, or that you wanted to distribute for other developers to use in their projects, you had only a few unappealing options:

• Include your source code in every project that uses your library (increased compilation time, hooray!).
• Build two library versions, one for armv6/armv7 and one for x86.
• Screw with the linker to manually create a “fat” library.
• Use the Bundle Hack and hope that it works.

It’s worth noting here that the first three options listed above do nothing to help with the management of any shared header files needed to actually make use of the library code. The fourth option does allow you to include public headers in your build artifact, but the setup to do so is tedious, and the entire thing is basically a giant hack besides. None of these options are really very convenient or useful from the developer’s point of view.

What developers really need, what they should have access to, and what Xcode should have supported at least since the release of iOS 4.0, is the ability to build frameworks that are “real” frameworks in the same sense that UIKit and CoreGraphics are real frameworks. And that’s exactly what the iOS-Universal-Framework utility gives you. Just install it and you get a handy Xcode template that can be used to build universal iOS frameworks. These are real frameworks that include binaries for both x86 and armv6/armv7 in a single package, automatically bundled with your public header files. You (or anyone else) can then use the generated framework inside of other projects in the same way as any other iOS framework; just add it to your “Link With Binary Libraries” build phase, and you’re done.

All told, the iOS-Universal-Framework template is great and works exactly as advertised. Just install it and you’re good to go.

IApps Pty Ltd, an Australian based mobile software developer, is a company assisting large corporations in deploying industrial strength content management systems using the iPad and iPhone, and adding them into their existing infrastructure.

Rick Hoy, the CEO of iApps Pty Ltd said, “we want to encourage larger companies to adopt a content management framework that works in conjunction with todays technology, so we found a niche for developing applications capable of supporting internal, sales, marketing and communications – all from within the one application on one platform.”

“Our company seeks to empower internal organizations and field sales units by delivering crucial information in a way that is dynamic, whilst still being able to support clear and defined administrative and business communications”.

“By accelerating the distribution of the correct information within a controlled environment, mobile technologies are quickly replacing the older and more ad-hoc systems. By utilising systems that can easily communicate between different areas of the business ,workers and management can make quicker and better business decisions” said Mr Hoy.

By implementing these particular solutions, companies around the world are realising the immediate benefits of mobile technology, with companies such as Hyatt Hotels using the iPad to improve their hotel operations as an example.

Chief Technical Officer of iApps Pty Ltd, Andrew Longhorn said, “our company employs a more consultative approach with all our clients, finding out exactly what their challenges are, and then we find and develop a solution that is 100% tailor made to drive results. We’re an enterprise for enterprises; so we enjoy deploying systems that help position Australian industries to better compete both locally and internationally.

Both sisters lived on the Sunshine Coast and the tragic events happened at a time when Dr Glassop was considering leaving the world of academia where she lectured in business management.

“I felt the academic world was a bit too bureaucratic and not for me, and also that I was a bit too entrepreneurial for that world,” she said.

Entrepreneurial is an understatement for the 55-year-old.

She grew up in Sydney and trained as an accountant before honing systems development skills in IT during the 1980s.

She made up for not finishing high school by earning an MBA and a PhD in Philosophy.

“I always felt a bit inadequate in terms of my education and I hit the big corporate glass ceiling. I felt the only way to get past that was to get some formal education,” she said.

“The PhD was multidisciplinary and it had a systems theory slant, so it was about developing theoretical models and modelling how you want to work.”

Dr Glassop and her two sisters have formed a company called Kodus (sudoku spelled backwards with the U dropped), and partnered with local company iApps to create Karenji, a sudoku-based multi-player app.

The trio had played around with the idea of a sudoku board game as a distraction from the funeral of Dr Glassop’s niece years before.

“I was a naive entrepreneur in a sense, because you think you can just walk in and say ‘I’ll have an app please’,” she said.

“But I had business knowledge and we had to register a business structure, a trade name, organise a patent, a budget, an accountant and a lawyer.

“I force my two sisters to have business meetings with minutes. We attempt some formality.”

Dr Glassop has also researched family business for past KPMG surveys.

“I have a very broad understanding of how to run a successful family business. It’s about communication and having a degree of formality – have meetings, record everything, don’t rely on hearsay or a feeling. You also need to know that you don’t know everything,”

Not long ago Atlassian released version 1.0 (now up to 1.0.7) of their Jira Mobile Connect plugin. This is a plugin for Jira (obviously) that aims to simplify testing, error-reporting, and feedback collection/management for iOS applications. Assuming that you are doing iOS software development and have a Jira server instance running (which you really should if you are doing any nontrivial amount of development work of any variety) then using this plugin in your apps is really a no-brainer. Jira Mobile Connect includes a number of very cool features, such as the ability for users to attach annotated screenshots/images to their feedback reports, to record audio to attach with their feedback, and even to chat back and forth with the developer(s) working on their issue/ticket . And of course it does basic crash logging and reporting, as well.

Previously if you wanted a free/open-source crash reporting framework for iOS your options were basically limited to QuincyKit, which is a serviceable but basic solution. Sadly, the backing architecture used by the QuincyKit server is not well designed and scales very poorly with the number of crash reports in the system. Once you have around 5,000 you’ll notice the server slowing down significantly, and go much beyond 10,000 that and the system grinds to an unusable halt. With a day or so of database and code refactoring, these scalability issues can be resolved, creating a system performant enough to track millions of error logs or more. But that’s a subject for another time. The point for today is that despite its basic level of functionality and flawed server architecture, there are a few key areas in which QuincyKit blows the default implementation of Jira Mobile Connect out of the water:

1. Automatic grouping of crash reports.
2. Automatic symbolication of error logs.

If you have any experience whatsoever with supporting multiple high-volume iOS applications you will instantly realize that these are features that you want. They might even be features that you want more than annotated screenshots, audio feedback, user chat, or seamless integration with Jira and all the awesomeness that Jira brings. In short, Jira Mobile Connect’s lack of support for these two key features may cause serious developers to pass it over in favor of other solutions.

Without grouping every single crash will be creating a new ticket in Jira that you need to track and resolve. Multiple instances of the same crash will have to be manually flagged as duplicates within Jira. And without symbolication trying to actually map back from an error log to the line of code that caused it is an exercise in futility, or at best, tedium.

In any case, rather than abandon the excellent potential shown by Jira Mobile Connect I decided that instead I would attempt to patch it up and add the missing features myself. It’s all open-source code, after-all, and if the tangled mess of PHP that is QuincyKit server can provide these features then they can’t be that difficult to implement. Unfortunately I had to change too many files in too many different places to show the code here, but if you want the short version of it I was able to implement both grouping and symbolication, and you’re welcome to view the complete diffs on bitbucket:

https://bitbucket.org/aroth_iapps/jiraconnect-ios-iapps/compare/..atlassian/jiraconnect-ios (client/native iOS code)
https://bitbucket.org/aroth_iapps/jiraconnect-jiraplugin-iapps/compare/..atlassian/jiraconnect-jiraplugin (server/Java code)

One interesting side-effect of adding groups was that it became possible for multiple client UID’s to be associated with a single Jira ticket. This had an important implication for feedback notifications/chat in that the reference implementation allowed only a single UID to be associated with each Jira ticket. Since the UID is used for determining what notifications/updates to send to the native client, this restricted update notifications to a single user per ticket. Not too useful if you have a common crash that thousands of users have experienced. The implementation above extends the data model to allow multiple UID’s to be stored against a single Jira ticket, allowing each UID to be updated when new feedback is posted by the developer on a ticket. In essence, implementing grouping also required the implementation of group feedback/chat.

There is one caveat with my server implementation, in that it assumes the existence of the ‘symbolicatecrash‘ utility on the system’s runtime PATH. This means that it will only work if your Jira server is hosted on a Mac, with the proper XCode developer tools installed (and with your application’s .app and .dSYM files copied to the local filesystem). This is of course a requirement regardless if you want automatic symbolication to work on any sort of system; somewhere there needs to be a Mac with ‘symbolicatecrash‘ available. In any case, it is a fairly simple matter to either turn this off or otherwise make it more intelligent, if your Jira server is incapable of running ‘symbolicatecrash‘.

Also note that the native iOS code has been restructured to build a universal iOS framework as opposed to an architecture-specific static library. This is done using Karl Stenerud’s excellent XCode4 Project Template. You will need to install this template in order to actually build the modified code. Or you can just refactor it back to build a static library again, but why would you want to do that?

When using the iOS framework, be aware that you will need to set the ‘-all_load‘ linker flag and also include all the images and nibs in the framework’s ‘/Resources‘ folder as part of your build. You will probably also want to include the ‘JMCLocalizable.strings‘ file in the same folder as well, to provide proper text and labels on Jira Mobile Connect’s UI elements.

Regardless, if you do a lot of iOS development and are already using Jira (like you should be) then I encourage you to check this out. This is the Jira Mobile Connect plugin, now with automatic grouping and error log symbolication.

RIP Steve Jobs.

1955 – 2011

An example being Burlington High School near the city of Boston, being one of the forerunners in this transition. Every student in Burlington High is to be issued iPads by the school. At price of $500 to $600 this may seem costly, however as a long term investment, the principle of the school believes that it will be well worthwhile.

In the case of some schools like Brookfield High in Connecticut, they believe that it spends just as much on textbooks yearly. Not only are these schools benefiting from convenience, but also from interactive programs that work with problem solving in mathematics, scratchpad features for note-taking and also the sending and receiving of homework.