Sunday, November 27, 2011

When should you take performance into consideration?

Before publishing my previous post on rewriting an if, I knew some people would hate it, because the refactored construct is less performant.

Although I think performance is important, relevant performance improvements are, apart from in tight loops, hardly ever to find in language constructs. To put it more bluntly, they are a waste of time. When translating your thoughts into code, you should aim to make your intentions as clear as possible for the person who comes after you. Don't obfuscate your code for an negligible performance improvement.

I'm not advocating readability and pretty code are an end goal, performance and quality still are. But look for optimizations where it counts: optimizations which, after measuring, prove to be make a significant impact on the overall performance of your system. These are most likely to be found in I/O operations, architectures and algorithms. Not in language constructs.

Thursday, November 24, 2011

Rewriting an if

Yesterday I came across an if statement that looked something like this.

if (arg == "a" ||
    arg == "b" ||
    arg == "c" ||
    arg == "d" ||
    arg == "e")
{
    Console.WriteLine(true);
}

An alternative way of writing this could look like this.

if (new [] { "a", "b", "c", "d", "e" }.Contains(arg)) 
    Console.WriteLine(true);

I can't remember in which Github repository I spotted this technique, but I'm sure it was written in something other than C#. I think it works for C# as well though. The language hardly gets in the way, although it would be nice to be able to drop the new.

This is one of these trivial things I tend to geek about. The condition fits on one line now, making the eyes do less work. Also adding a variable is less work; you don't have to enter and indent accordingly. I think it's a win in readability, size and maintenance.

But then I stop and wonder: how do you feel about this construct?

Wednesday, November 23, 2011

Blame no one but yourself


Blame no one but yourself. This is one of the few quotes I remember months after reading this book. Although it's a harsh statement, there definitely is some truth to it.

Once I started observing my own behavior when faced with failure, I caught myself regularly blaming others for failures to which I am - at least - an accomplice.

Think about it. You might be guilty of this too.

Frustrated with management because you missed their too tight deadline? Did you tell your project manager that taking that 'one small' task in between would get you behind on schedule? Dissapointed by your team mate because he messed up the task you asked him to do? Are you sure you gave him all the information and provided enough feedback? Tired of doing the same repetitive task over and over? Why haven't you automated it yet? Not happy with a certain implementation? Did you speak up and propose alternative solutions?

So next time you blame someone else, ask yourself: Did I try everything within my reach to make this work or did I unconsciously sabotage this myself?

Sunday, November 20, 2011

Daydreaming about jQuery Mobile and the WebAPI


I recently blogged about programming for the future of mobile with jQuery Mobile and the WebAPI. You probably heard that jQuery Mobile 1.0 was released earlier this week. Although it will take a while before we will see some actual results from the WebAPI initiative, that shouldn't keep us from letting our minds play with things that might be possible one day using the WebAPI.

The thoughts in this post were provoked by an interesting comment Kristof Claes left on my previous post.
One thing I don't like about jQuery Mobile is that it has this iPhony (pun not intended) look to it.

I have a WP7 device and for some reason I don't want applications to look like I'm using an iPhone. I can imagine the average iPhone user wouldn't be happy when jQuery Mobile used a Metro-like skin.
And I agree, it does look iPhony. Although there already is a themeroller for jQuery mobile, it's limited to changing the color scheme. Like Kristof said, the contrast between the Metro UI and the jQuery Mobile UI is enormous.

Platform specific themes might help to close that gap. I really think this makes sense for mobile, because - compared to desktops - most mobile operating systems do leverage a signifantly different feel. Also, the browser is full screen on most mobile devices, saving space, but also losing the native OS context.

I have been thinking a bit about how this could be implemented. So follow along, and let me know if these ramblings seem feasible.

Serving themes based on the operating system should be doable. A naïve implementation, which only supports Metro, could be as simple as this.
return Request.UserAgent.Contains("Windows Phone OS 7.5") ? "jQueryMobile.Metro.css" : "jQueryMobile.Default.css";            
On my Windows Phone, I can configure the background- and the accent color for the Metro UI. And this is where it gets interesting. Using the SettingsAPI, defined in the WebAPI standards, we might be able to find out those values in our webapplication. Meaning we could make the mobile UI 'experience' completely transparant.

The proposed Settings API standard looks like this.

interface SettingsManager
{
    // List of known settings.
    const DOMString FOOBAR = "foobar";
 
    // Setters. SettingsRequest.result is always null.
    SettingsRequest set(DOMString name, DOMString value);
    SettingsRequest set(DOMString name, long value);
    SettingsRequest set(DOMString name, long long value);
    SettingsRequest set(DOMString name, float value);
 
    // Getters. SettingsRequest.result will be of the requested type if the success event is sent.
    SettingsRequest getString(DOMString name);
    SettingsRequest getInt(DOMString name);
    SettingsRequest getLong(DOMString name);
    SettingsRequest getFloat(DOMString name);
}

So, dynamically modifying the css to comply to the Metro color sheme could be this easy.

var backgroundColorRequest = settingsManager.getString('metro-backgroundColor');
backgroundColorRequest.onSuccess = function() {
    $(".main").css("background-color", this.result);
}
var accentColorRequest = settingsManager.getString('metro-accentColor');
accentColorRequest.onSuccess = function() {
    $(".tile").css("background-color", this.result);
};

Is it just me, or does the WebAPI have some sick potential?

Wednesday, November 9, 2011

Programming for the future of mobile

I have been working on something small on the side lately. I hardly have anything to show for it though, most of it is still being shaped in my head.

Anyhow, a very important part of the front-end is built using jQuery mobile. Although the framework hasn't been released - release candidates are available though -, it's something you should start looking into today. Why? Because the browser is the future of mobile applications. With the Flash and Silverlight bombs that were dropped today, I am even more confident that that future might be nearer than we think.

Built upon the jQuery and jQuery UI foundation, jQuery mobile aims to make mobile web applications seriously cross-platform and cross-device, while optimizing for touchfriendliness. From what I've seen so far, the jQuery team has (once again) succeeded at making the web just work.

To start using jQuery mobile, you just have to add one extra script file and one stylesheet on top of the existing jQuery infrastructure. Once that is done, the framework will already do most of the heavy lifting for you. Depending on your needs, you might want to enrich some elements explicitly in a nice semantic fashion.

For example, this is how you would get some collapsible panel action going.
<div data-role="collapsible" data-theme="c" data-content-theme="c" data-collapsed="@dataCollapsed" id="entriesList">
    <h3>@entryGroup.Date.ToString("dd/MM/yyyy")</h3>                        
  
    <ul data-role="listview" data-inset="true" data-theme="d">        
        @foreach (var entry in entryGroup.Entries)
        {           
            <li>
                @entry.CreatedOn.ToString("HH:mm") @entry.Description                     
            </li>         
        }
    </ul>
</div>  
To give you an idea, this would result in something that looks like this. Clean, right?


Now that these problems are out of the way soon, the only barrier left for mobile web applications is that the browser has no actual hooks in the device itself. But this last barrier can't hold forever... Mozilla initiated a very interesting project not so long ago. They started defining standards for a set of APIs that should give you direct access to the device: a camera API, telephony and messaging API, accelerometer API.. Find everything about the WebAPI initiative here. Subscribe to the mailing list, participate and help pushing the web forward.

I'm fairly optimistic about the future of mobile web applications. It's impossible to put a timeframe on it, but eventually WWW, the Web Will Win.