I’ll be speaking at cf.Objective() 2014

by kai on 30/12/2013



It already happened an few days ago, but I’m very pleased to announce that I’ll be at cf.Objective() 2014 in Minneapolis in May 2014 and that two of my three session proposals got chosen for the conference’s agenda.

I’ve been to cf.Objective() 2013 as an attendee (Kudos to Gert @ Railo for throwing me a ticket of their sponsor contingent) and it was a really, really good event. To be honest, that really wasn’t a big surprise as cf.Objective() has a really good reputation for being the major CFML conference, very well organised and generally awesome; and it’s true. Also, the venue (Radisson Blu right at Mall of America) is kind of interesting in a very special way.

Anyway – in case you’re interested in what my sessions will be about… (you can also find them on the cf.Objective() Lanyrd site or the actual cf.Objective() website — the session descriptions are not yet 100% up-to-date on the latter):

1. The JVM is your friend

Both Adobe ColdFusion and Railo are Java-based web development platforms. In layman’s terms that means: Your CFML engine runs on top of a JEE application server or a servlet container and the JVM (Java Virtual Machine).

The latter is pretty much the low-level runtime environment of your CFML application. To make sure your CFML engine operates in a well performing and stable way, you need to have some knowledge about Java memory management and how that can impact the behaviour of your CFML server.

The objective of this talk is to change developers’ mindsets when it comes to the JVM below ACF and Railo. There’s an myth that JVM behaviour and JVM tuning is a “dark art” and that has to stop. It will also equip you with a level of fundamental knowledge that you can use to push back when someone tries to tell you to “just use my JVM settings” or to “use the settings this guy had on his blog”.

We’re going to cover:

  • Foundations of Java memory management and the important bits for CFML developer
  • Java Garbage Collection and various memory cleanup strategies
  • How load generation, load testing and measuring the right data plays into JVM tuning
  • JVM tuning specifics for CFML developers
  • The JVM and the Garbage Collectors in Java 7 and beyond

2. Real-World lessons in jQuery Mobile

“Hey, let’s build a mobile web app!”
“Awww, what an awesome idea – I’ve heard jQuery Mobile is super-easy, bro! Let’s start right away!”

(6 months later)

“Oh my god, this code is a mess – why did I do this thing 4 months ago?”
“How hard can it be to change this jQuery Mobile UI widget just so that it does what I need?”
“Do you know why my icons render distorted on the new {iOS|Android|Windows} device?”
“Why are the page transitions really rough on some of those Android 2.2 and 4.1 devices?”
“The back button navigation is acting weird – I wish we just had built a native app”

Does that sound familiar? jQuery Mobile is a mobile web development framework that’s really easy to get started with. Product Evangelists from big corporates show their tooling around the framework or build their own products using it and it always looks SOOO easy and straight forward in their scripted demos.

There are pitfalls though and a lot of lessons are to be learned along the way – starting from making decisions on how to architect your application (in particular in conjunction with having to incorporate a backend) and ending with bug-fixing discussions like the ones above.

It doesn’t have to be like that – in this session I’m going to talk about a few fundamental architectural concerns when it comes to building a mobile web app (and maybe to wrapping it into a native app later). We’re also going to have a quick look at the pros and cons of using a framework like jQuery Mobile vs. using responsive design and even if and how those two concepts could work together. We’ll discuss some of those common pitfalls and device quirks and things we had to learn the hard way ourselves when we started building mobile apps with a very early version of jQuery Mobile for our clients.

  • Defining a good architecture for a jQuery Mobile application
  • The relationship between jqM and Responsive Design
  • Data handling mistakes to avoid
  • Quirks on certain devices and how to deal with them
  • The pitfalls of tweaking jqM’s UI widgets
  • jqM beyond markup

{ 1 comment… read it below or add one }

Dawesi September 12, 2014 at 7:52 pm

I hear all the time of people moving from jQuery mobile to Sencha Touch due to the messy code… there’s a huge push for micro framework apps, but at the end of the day, I’d rather have one framework minimised and written in one way (using MVC or MVVM), then five to ten microframeworks with different coding styles and redundant functionality and code in my app.

Large media houses such as fairfax, new york times and many others learnt this lesson, and moved to Sencha just on the micro framework hell that conferences spin you into attempting.

Reply

Leave a Comment

Previous post:

Next post: