Category Archives: Rants

Web Apps – The More Custom The Better

I’m a big fan of the WebKit Qt framework integration. It will without a doubt change the face of web based content delivery over the next few decades (previous post). By far the most powerful aspect of this integration is the ability to create custom JavaScript APIs for hybrid web based applications in a browser.

Put simply, browsers can customize the functionally they offer by implementing features into the browser that can be accessed by web content via JavaScript.  Web apps that exercise this functionally must be written to do so, making them “custom” web apps.  Meaning that an app written to utilize features defined in certain browsers will not work without modification in Explorer, Firefox, or Chrome. For example, when GE integrates a web browser into their next generation refrigerators, it would be beneficial to expose an API that allowed an app to check the inside temperature or level of the ice tray.

I’ve been in many debates with other engineers about this option.  Not one engineer has ever agreed with me right off the bat.  Most oppose doing it as it limits were an app can be run and defeats the purpose of web content.  The “purpose” being mass distribution and play-ability on many different standardize browsers.  Most don’t understand why you’d create a web app that can only be executed on a limited number of browsers.  Many also argue that it burdens app developers with having to learn yet another JavaScript API.  Regardless of the objection, this option is widely opposed and not fully understood by most engineers.

The engineering objections are easy to argue against.  First of all, there is no such thing as a standardized browser.  Despite standardization efforts from W3C,  the JavaScript language is a mess.  The big three, IE, Firefox, and Chrome all use a different JavaScript engine and have varying degrees of standardization completeness (some even have features not covered by W3C).  If you want your website to work across the big 3 you already have to add additional code.  I know its a stretch, but this is already a form of web app customization.

The real value add of customized web apps is from a business perspective.  I come from the embedded device world where the number of units sold is the driving factor (compared to the number of hits). By forcing apps to write to your API you are ensuring a certain level of stickiness.  It can be a competitive advantage to limit the devices an app can run on by exposing custom functionality through the browser.  GE won’t want its ice tray level app to run on LG with no modification for the same reason Apple does’t want its apps to run on Android without a rewrite.

Adding a custom JavaScript API to your Qt WebKit browser is easy.  Nokia has a great blog post on its forum here. To illustrate its simplicity I’ve included my own snippet below.

Any C++ object can be complied into the browser and exposed to the JS engine.

class FakeObject
{
public:
	FakeObject(QObject *parent);
public slots:
	posterInternalCommand(QString command, QString data);
signals:
	fakeSignal();
}

FakeObject::FakeObject(QObject *parent)
{

}

bool FakeObject::postInternalCommand(QString command, QString data)
{
	// Do something with data
	return True;
}

FakeObject::emitSignalTest()
{
	emit fakeSignal();
}

After instantiation the object is exposed to the JS engine using a QWebFrame method.

FakeObject* m_pfake = new FakeObject(webView);
webView->page()->mainFrame()->addToJavaScriptWindowObject(QString("fake"),m_pFake);

The exposed object can now be acted on via JavaScript. Public slots are methods that can be called directly from JS. Signals can also be connected to local JS methods making for more asynchronous functionality.

b = window.fake.postInternalCommand("fakeCommand", "fakeData")

function fakeCallBack(){
	x = x + 1
}

window.fake.fakeSignal.connect(fakeCallBack)

Leaders & Teams

I ran across a blog post from a former professor in grad school titled “a reminder for managers and leaders” and contained just the following picture.

I’ve been both a leader and a follower on many teams and have always been surprised when the manager takes credit for the teams success. The team spent months of there life solving the problem, designing the solution, and doing all the grunt work to actually make it happen and the manager ends up taking the credit? In these scenarios, I guarantee the team will not execute nearly as well the next go around. As a manager, it is a fundamental mistake to take credit for the collective actions of your team.

What can a great leader/manager always take full credit for? Failure.

Python – Love / Hate

Hate:

1) Really bad at managing threads.
2) All class properties require “self” keyword.
3) Inheritance is supported but can be difficult to invoke.
4) Private members are difficult to encapsulate.
5) More difficult to deploy then traditional compiled languages.
6) Default timer class is limiting.

Love:

1) Tuples.
2) Keyword parameters.
3) Everything is an object.
4) The “pass” keyword.
5) Generator objects.
6) Method objects.
7) Dynamic code insertion.
8) PEP8.

Git – Free Corporate Code

I find it amazing how much corporate code is still locked down behind bars with CVS. Even though its the least useful reversion control system, its still the most widely used. Don’t get me wrong, 20 years ago CVS was a monumental invention and an absolutely necessary tool for software development teams. The problem is that it tracks files, not content, which makes it a fundamentally flawed tool to manage code.  It wasn’t until I started using Git on a regular basis that I truly understood this distinction.  Let me give my most noticeable observation after making the switch.

In CVS, once you create a file and add content into it, the two are tightly coupled for forever. The file can’t be renamed, moved, or deleted from the repository.  Future iterations, even if done on a branch, are forever burdened with this history. In Git, a file can be moved, renamed, and deleted from the repository without loosing any of the contents history.  This means, I can merge branch B with branch A and move the result into a different directory under a different filename and not loose any of the content history from branch B or A.

This simple difference allows me to iterate freely in a repository. Just today, I reorganized my entire 8 month old repository into different directories with different file names.  Why?  Because good code matures over time. A file that once only contained a data structure definition can evolve into its own thread of control, which for organizational purposes might be stored elsewhere with the other program threads. This isn’t the only improvement over CVS. Its distributed architecture and superior branch management encourages greater developer collaboration. Oh, and its fast… really fast.

Restricting your code prevents iteration which stifles improvement.

Cant learn something new?  Go into retail. Legacy humans can upgrade their firmware with 20 easy commands:
http://www.kernel.org/pub/software/scm/git/docs/everyday.html