Impromptu Rides

Feb 28, 2012 in Technology

wpid-impromptu-2012-02-28-10-13.png

Yesterday Cindy and I pushed out the new version of the Day Rides Center web site, now renamed to Impromptu Rides.

This site supports our cycling club’s program for scheduling ad-hoc bike rides. While the club (Rochester Bicycling Club) has a yearly formal schedule of rides, that schedule is put together with a workweek in mind: mostly rides in the weekend and the evening weekday hours once daylight savings starts. But many club members and other local cyclists have time during the week during the day. And so an initiative came about to help coordinate interested riders to suggest, find and join in on rides outside the regular schedule. At first this was an email send-around effort. Then last winter Cindy asked if I could help make a web site to make this easier. My answer: “Sure!”

It was a great excuse to tinker with a few technologies I have wanted to play with and learn but didn’t have a “real world”-enough project to try them out on. These were GWT (Google Web Toolkit) and GAE (Google App Engine). GWT allows one to write the browser portion in Java. GWT compiles the Java source code to Javascript and takes care of the differences between the various browsers. GAE is Google’s cloud computing platform and so that is hosting the backend of the site. GAE is what GWT is to Javascript: I can just write Java without having to worry much, or know much, about server-side computing and Java EE at all.

We launched the first version last March and then during the year added some features, fixed bugs and so on. We used this winter – not many people riding bikes – to redesign the layout, add a bunch new features and I took the opportunity to re-implement a good portion. The latter is the usual software engineering happenstance: I learned a lot about the two technologies during the year and so found better ways to do certain things, the bolting on of new features made some parts a little bloated, and to make doing some of the new things easier it required some rewriting as well.

The backend also gained a new front end client this winter: the Club Rides iOS app now plugs in too to show both the regular ride schedule and the impromptu rides. The ease of doing this shows a benefit of both App Engine and GWT: it’s all just a REST API and so the front end and the back end are nicely decoupled.

This winter I focused on getting feature parity between Impromptu Rides and the Club Rides app. The Club Rides app grabs the RSS feed from the RBC web site to display recent club news. The new version also uses a Google service to grab the weather forecast. This content is also returned as XML. Working with XML, and in general any content over an http connection, is really easy to do in Objective-C. It has always amazed me how hard, comparatively, this is in Java. The built-in parsers are memory hungry and it takes a lot of code to get the content from the http connection and then parse it. For Objective-C there’s a really nice, fast, small open source library to parse XML: TBXML. Delighted I was to discover that Julien Foltz ported it to Java!

Now, all that is needed to ingest the RSS feed is:

try {
    URL url = new URL(http://rbcbike.wordpress.com/feed/);
    TBXML doc = new TBXML(url);
    if (doc != null) {
        TBXMLElement root = doc.rootXMLElement();
        TBXMLElement channel = doc.childElement(“channel”, root);
        TBXMLElement element = doc.childElement(“item”, channel);
        ArrayList> result = new ArrayList>();
        while (element != null) {
            TBXMLElement temp = doc.childElement(“title”, element);
            […snip…]
            result.add(entry);
            element = doc.nextSibling(“item”, element);
        }
        return result;
    }
} catch (Exception e) {
     this.sendEmailReport(“AdminServiceImpl:getClubNews”, e.toString());
}

The browser’s security framework does not allow the opening of URL connections – GWT doesn’t therefore implement java.net.URL – so the above code runs on the server. The client makes a Java RPC call to the server requesting the feed, the server grabs it, parses it and passes it back as a hashmap array to the browser.

Impromptu Rides tries to determine whether it’s being viewed on a computer, a tablet or a phone. In case of the latter it displays a simpler version of the app: just the Find Rides portion. This involves interpreting the user.agent values that the browser reports. Messy stuff. The Android devices, or rather their manufacturers, could be a little nicer and more forthcoming about what category of device they are. In the end I chose to distinguish between “Safari” and “Mobile Safari” which seems to work to draw the line between computers and tablets on one side and phones (and iPods) on the other. At least for iOS and Android devices. I don’t know how Blackberry or other non-Android devices present themselves. The Impromptu Rides site also knows about the regular RBC schedule and so together with the mobile device support this saves me needing to do an Android version of the Club Rides app.

As you can see from the code snippet the server-side code sends me an email when something is amiss. I quite like that. I can leave the application running by itself without needing to keep an eye. When something unexpected happens it sends me a little email.

When I started playing with GWT last year, I had to smile. When Google first released GWT I was working at Sun. We, JavaSoft, were not amused. This was not Java. What Google did was Wrong and Bad, how dare they! Now, as a software developer I find GWT great. Google directly addressed a developer need and a niche in the available tools at that time: writing in a well-known high-level language, no need to learn Javascript, shielded from (most) browser-specific stuff, zero administration and no plug-ins required.

A quick summary of the new features:

–        Elevation profiles for most, known, routes

–        Weather forecast for the starting location

–        Recent club news

–        When scheduling a ride, include a link to MapMyRide, BikeToaster, etc for Garmin Edge bike computers

–        “Remember me” for ride leaders and admin

–        Adjusted layout for iPhones and Android phones

–        and an About page which explains what Impromptu Rides are actually about!

So, have a play with it and join us on some of our rides!

Windows Azure – first impressions

Sep 12, 2011 in Technology

The last few weeks I’ve been exploring Windows Azure, Microsoft’s cloud computing platform.

This turned itself into a learning experience on several levels:
1. I haven’t done Windows software development in years
2. Getting to grips with MS’s development model vis-a-vis Java and iOS/Objective-C
3. Contrasting Azure against my experiences with Amazon Web Services and Google App Engine (GAE)

The second item has been intriguing in its own right. Windows developers – the way they develop software, the way they talk about it – do seem rather different from both Java and iOS developers. Some of that is inherent to the technological differences but part of it is culture. Certainly in Java, but also in iOS, a lot of software development involves pulling in open source software for various plumbing pieces (xml parsing, graphics manipulation, network abstraction, persistence abstraction, what have you). There’s a plethora of public projects to stand on the shoulders of: Ruby on Rails, Tomcat, Glassfish, Spring, Hibernate, KissXML, the list goes on. Many developers use different languages for specific pieces of the overall product: php, python or javascript on the front-end; JRuby, Groovy, Java (of course) on the other tiers. Then there are open source products such as Puppet to help you manage the (virtual) datacenter and the deployment of your product.

On the Windows side there doesn’t seem to be that same rich diversity and choice. I use the verb ‘seem’ on purpose: I may well be wrong and discover that as I spend more time with this platform. But for now it seems that Windows developers are missing out on the cross-pollination and opportunities to learn from each other that I see in the Java environment and even in the equally closed (as compared to Windows) iOS development environment. Maybe that is good blog entry of its own?

But back to Windows Azure itself and my experiences so far.

Most tutorials, books, blogs and sample code I found approach Azure from the perspective of a web site: serving up web pages, storing and retrieving the information that comes along with it. And many assume Windows (a PC, a phone, a server) on both sides of the virtual wire.

Regarding the latter, it is a function of the internet that you don’t know (or should not know/assume) the particulars of what is connecting to you. One entertaining result of this Windows-centric view is that while much of Azure is exposed as REST services, most of the sample code just make .NET method calls. Thus obfuscating the benefits of the platform-agnostic API that Azure does expose.

Regarding the former, that – a web site – is not the context I am looking into Azure for: instead of web pages served up, it is services that need to be served up to which different kinds of mobile devices will be connecting.

Azure distinguishes between web roles and worker roles. A useful simplification is to see a web role (or the collection of web roles in your project) as the web server and the worker roles as the background processes performing the computation, data mining and so on. This distinction is still something I’m getting to grips with: it seems you can do in a worker role what you can do in a web role and vice versa. So what really does this architecture give you?

This brings up a broader point. Design patterns, or best practices. In my project I wanted the mobile devices to communicate with my Azure project through a REST API. I know how to do this in Objective-C, and in Java. But how do you expose a REST API in C#/.NET and how do you receive GET, POST, PUT messages Azure-side? Much reading on MSDN, StackOverlow.com, other developers’ blogs showed that there are many ways to do this: as a WCF service, or use ASP.NET, or ASP.NET MVC, or…
Similarly to the question of where to keep the project’s data, there are many answers: local storage, Azure table or blob services, Azure SQL, or…

I admit that for sure in the first two weeks I had a hard time separating the trees from the forest. Now, a month or so further into the journey I have a much better feel for Azure’s application model but it was not easy arriving there from outside the Windows world.

There are two areas though where I really like to see improvements: deployment and diagnostics.

Currently my project consists of a fairly simple worker role that exposes several entry points via a REST API and maintains two tables. Still, a build & deploy from Visual Studio takes 10 minutes. That’s just an eternity in a develop-build-deploy-test cycle. In comparison, from Eclipse I build and deploy a much larger GWT+GAE project in just a minute or so. I am curious what the deployment time will be once the effort grows to the projected several worker roles, Azure AppFabric bus, certificate store and more.

Sometimes after some development my worker role won’t instantiate and Visual Studio ends up in an endless cycle of creating, starting, stopping, creating, starting, stopping cycle. Yes, I can retrieve information about why it is unsuccessful via diagnostics but I had really expected Visual Studio to be able to just get that for me: it knows the worker role failed to deploy so it should really also be able to get me the failure.

To get trace and other diagnostic information from my Azure project involves sprinkling trace calls throughout my code, configuring and setting up the diagnostics framework, transferring the collected analytic data to storage, and then retrieving that data. In my experience so far this is an error prone process where I sometimes seem to spend as much time trying to have the right data collected and then accessing it as I spend fixing the particular bug I’m trying to use diagnostics for. Together with the aforementioned deployment situation this makes for a slow and rather tedious development/testing experience. I miss the end-to-end debugging I can do with GWT+GAE and I miss the GAE dashboard where I can see in one glance the main issues for my app, its resource usage and its data store.

So far I like that Azure makes much use of standard web methodology – REST most notably – and that existing .NET applications should migrate quite easily to Azure thus gaining cloudiness. But that last point I see also as a weakness: little reason for non-Windows deployments to migrate to Azure, GAY and AWS will feel much more natural.

I’d love to hear your experiences with Azure. I’ll follow up with future entries as the project progresses. Possibly the next installment quite soon as later this week I’m attending the Azure bootcamp in Cambridge, MA!

iOS – Objective-C snippets

Dec 17, 2010 in Technology

wpid-xcode-2010-12-17-11-38.pngA quick collection of code snippets or the joy of navigating a sometimes quirky SDK.

Setting a pattern as background to an UIView, a category method I added to UIViewController:

– (void)makePatternedBackground {
        UIImage *tile = [UIImage imageNamed:@”viewBackground-tile.png”];
        UIColor *pattern = [[UIColor alloc] initWithPatternImage:tile];
        [self.view setBackgroundColor:pattern];
        [pattern release];
}

The png image is a 16×16 pixel pattern created in Photoshop.

Rounded corners for images (or any UIView subclass, really). Don’t forget to import QuartzCore.h:

        UIImageView * icon;
        ….
        icon.layer.cornerRadius = 10;
        icon.layer.masksToBounds = YES;

Improving code reuse in an universal app for iPhone and iPad. This one has been bothering me for a while. Often you’ll significantly change how you present certain information on an iPad with its much larger real estate than on an iPhone. In that case you do your best MVC separation. Table Views are easy: you take care of the differences in your UITableView subclass. But there are some cases when the views will be largely similar. How then to avoid duplicating everything in two nib files and two UIViewController classes? Make a superclass that does most of the work and which contains all the IBOutlet properties that are the same between the two presentations. Subclass the superclass for iPad and for iPhone, and make a nib file for each. The superclass will have all the manipulation code while the two subclasses only have to take care of the small differences in displaying the view on iPad vs iPhone.

Notifications are your friend! NSNotification and NSNotificationCenter really help with code reuse between iPhone and iPad as well. With iPad’s UISplitView you often have both the table and a detail view representing a table cell’s drill-down visible and active at the same time. The delegate pattern breaks down in this scenario: multiple places in your app are interested in some events at the same time: send NSNotification messages from your data model object and have interested parties add themselves as observers.

And one more on improving code reuse: don’t make your UIViewController class the delegate object and datasource object for UITableViews it contains. Instead put that code in a separate object. Then you can set that object as delegate and datasource to the table in your iPad view and in your iPhone view.

stretch mark removal products
Спорт-как способ похудеть ссылка сайт кремлёвской диеты женские сайты диеты как быстро похудеть и накочать мускулы как можно быстро похудеть без проблем рисовая диета для похудения как быстро похудеть, рецепты похудения как похудеть быстро без дееты за 14 дней срочно похудеть с помошью салона красоты в казани как быстро похудеть народные рецепты как похудеть быстро и не мучить себя голодом диеты для снижения веса сайт девчат быстро похудеть на 30 килограмм срочно похудеть на 5 кг. за 10 дней алан кар легкий способ похудеть скачать бесплатно как быстро и безвредно похудеть? как похудеть быстро за месяц 10кг спомощю воды диетхудеем быстро без с упражнениями отзывы средства для похудения хочу быстро легко похудеть быстрый способ похудеть aллен кaрр срочно похудеть за три дня три колограмма быстро похудеть без лекарств худеем быстро после родов ка быстро похудеть делая клизмы сайт диета доктора аткинса легкий способ похудеть от алена карра диета для похудения из куриного мяса танец живота как способ похудеть индивидуальная диета тест худоба ру легкий способ похудеть