A tres useful link for playing around with JSON parsing and data structures; a design tool if you like; the aptly titled Online JSON Parser.
And a useful library for Java ME. In fact, at the bottom of the landing page for JSON.org, there’s a list of implementations for a host of languages.
So it was an incredibly busy end-of-year (2009) with exams, lifesaving, BlackBerry and .NET projects and family life. And then the festive season came and went; New Year’s slipped by and now we’re this side of 2010 looking forward to another round of whatever may be.
And right off the bat, tax season looms. Registration for university is on the go, lifesaving competitions get into full swing with some major events, followed by mid-year exams and winter. And then 3Nut (sprog #3) arrives and then (allegedly) the exponential busy-ness kicks in. So already, the first half of the year is underway at a pace. Which is New Year’s celebrations have always been foreign to me.
There’s this air of expectation around them like something “new” and exciting will be heralded in and when you wake up the next day and everything is supposed to be “different”. And because it’s New Year, you have a milestone whereby you can mark your life’s progress. Strange. Why wait to do that only once a year?
Every day is filled with new and exciting adventures. Every day is a milestone and an accomplishment. Every day is different and is definitively the last of _that_ day you’ll ever have.
So, today is the day you make a resolution; and if you resolve to do something, it means you do it- not just think about doing it. “Carpe diem” is the old expression (which i strangely don’t hear much anymore?) so seize the carp!
It’s expensive, mentally and resourcefully, but it’s rewarding. It also isn’t easy, which is probably why it’s not advocated by the populous, but it is rewarding. And it’s filled with all sorts of risks and dangers, but definitely rewarding. Rewarding if you get it right.
After months on Rails (web), Python (web), Objective C (iPhone) and C# (web) projects, i’ve settled my teeth into a juicy little BlackBerry project. It’s taken a lot of mental effort to switch, and in particular, switching to the following:
* the language: Java. New syntax, keywords and run-time nuances in memory management
* the frameworks J2ME and RIM: what do they offer where are all the packages
* the IDE (Eclipse): how does it work and how to customize your environment/experience, and then what else does it offer that no other IDE to date has offered
* the BlackBerry device: where, what, how does it do the things it does
* the unit tests (jmunit cross bunit): new language, new platform, new test harness, same procedures (more or less)
* runtime debugging tools with the simulator and component packs
* mobile development: patterns, architectures, design and development principles
* the UI: a whole new playing field where the only place in the world Managers are your friends
* automated building and testing (still getting there)
* code control and IDE integration
Every day is filled to the brim with slow progress punctuated by episodes of breakthrough bubbles, although a the days wear on, the bubbles are more frequent and the productivity increases naturally on a curve on its own.
The end result: another framework, platform, language, set of tools available at my fingertips to enable me to express a solution to a problem and then successfully execute that solution without too much limitation.
Spin-offs include restless nights, lots of “aarrggg’s”, a lot of debugging and a whole lot more muttering which usually starts with “now how do you do that?”. And that right there has been one of the greatest little nuggets- tackling a project like a n00b, a grom; with all the enthusiasm naivety brings, but with experience (ok, age).
ZaFin is the finally born with the first feature arrived: PAYE. (Hey. It’s a start and a natural one at that given it’s history). Now, ZaFin is a long-term project and has been a goal to get going for a long time now. Essentially, it’s the place to post tools which help you reach numbers you need to make informed decisions for yourselves. Given the state of the world economics at the moment, give me one good reason why would I want to get financial advice from “the system”? It’s track record speaks for itself. Neh. Have the courage to think for yourself, right?
So ZaFin is supposed to be that kind of place. A spot where you can, armed with a bunch of quick little nifty calculators, reach and juggle numbers to come up with a reasonable conclusion. You don’t need an advisor for that. I believe, armed with the right information (ie. numbers) most reasonable folk can come make up their own minds. And make pretty good decisions on their own too (and maybe also check in with an honest friend to bounce some ideas off).
There will be more to come, slowly, over time, as time allows; baby steps. Hope you find the first tool useful, and more importantly, simple to use and to the point giving all you need, and only what you need.
It’s the infamous view state again. My my my. I knew there were reasons I really didn’t dig the complexity ASP.NET were trying to cover up. This time though, my sense of amazement reached new heights when the client browser crashed (yip-crashed) because the server picked up some dodgy view state. Read that again. Carefully.
Oh. And you probably might have already guessed which browser does the crashing. No prizes for getting it right, sorry. The correct and predictable, even appropriate response is: “The view state is invalid for this page and might be corrupted” which is what all the other browsers I’ve tested on so far show. On with the experiment…
We’ll start off with a simple ASPX page. Nothing complicated.
<html>
<script language="C#" runat="server">
public void Page_Load(Object sender, EventArgs E)
{
}
public void Submit_Click(Object sender, EventArgs E)
{
}
</script>
<body>
<form id="Form1" runat="server">
<asp:Button ID="Submit" OnClick="Submit_Click" Text="Submit" Runat="server"></asp:Button>
</form>
</body>
</html>
Click on the button and woohoo- no surprises. But now we add a little extra something. We modify the contents of the page after it’s loaded. Nothing special here either really. Standard AJAX behaviour.
<asp:Button ID="Submit" OnClick="Submit_Click" Text="Submit" Runat="server"></asp:Button>
<div id="dynamic_content"></div>
<script type="text/javascript">
//<![CDATA[
window.onload = get_dynamic_content;
function get_dynamic_content() {
//....
}
//]]>
</script>
The JavaScript function get_dynamic_content() will make a request and then proceed to populate the div dynamic_content with some more HTML. The obvious solution is to do something along the lines of:
function get_dynamic_content() {
document.getElementById('dynamic_content').innerHTML = '...some html...';
}
Incidentally, therein lies another rub in that div.innerHTML behaves differently for IE. Take a peek for yourself. And within all those comments, of this article, there lies a hack solution. You can read more about that debate there. Moving along.
So having hacked the little piece of innerHTML magic, you start populating your element with all sorts of dynamic content. Wonderful. Then during a series of development efforts, you get a buggy piece of HTML tagging along for the ride. A second form element- don’t worry, not a server-side form. More about why and why not here if you not too sure about how that fits into the scheme of things. Anyway, so you get an erroneous piece of HTML coming through- a valid bug in the development effort- and your second form contains an extra view state element. By now, you’ve also probably deciphered the design and architecture of this piece of handy work.
And i’ll recount here- this may be a valid bug, but it’s not about the bug. It’s the way the client browser handles a server-side bug.
So let’s assume that part of the payload (simplified) includes the following:
<form> ... <input type="hidden" name="__VIEWSTATE" id="__VIEWSTATE" value="/wEWAgL9hvuOBAK8w4S2BGRm0HOf1YSq2O4B5nwrlp8eUNwR" /> ... </form>
You click on Submit. Is this what you would be expecting?
It’s not even bad HTML. In fact, if the dynamic payload didn’t include the extra form element, just the viewstate ala
<input type="hidden" name="__VIEWSTATE" id="__VIEWSTATE" value="/wEWAgL9hvuOBAK8w4S2BGRm0HOf1YSq2O4B5nwrlp8eUNwR" />
You get the reasonable and correct behaviour. ASP.NET complains about the view state being fudged. Good. But wrap that extra view state input element in a form tag and IE client blows up. WTF? Incidentally, the form wrapper is arguably more correct.
Here’s the full code for your enjoyment. Modify the content variable and element type of dynamic_content and test across all your browsers.
<html>
<script language="C#" runat="server">
public void Page_Load(Object sender, EventArgs E)
{
}
public void Submit_Click(Object sender, EventArgs E)
{
}
</script>
<body>
<form id="Form1" runat="server">
<asp:Button ID="Submit" OnClick="Submit_Click" Text="Submit" Runat="server"></asp:Button>
<div id="dynamic_content"></div>
<script type="text/javascript">
//<![CDATA[
window.onload = get_dynamic_content;
function get_dynamic_content() {
var content = '<form><input type="hidden" name="__VIEWSTATE" id="__VIEWSTATE" value="/wEWAgL9hvuOBAK8w4S2BGRm0HOf1YSq2O4B5nwrlp8eUNwR" /></form>';
//document.getElementById('dynamic_content').innerHTML = content;
swap_content_div(document.getElementById('dynamic_content'), content);
}
function swap_content_div(old_div, content) {
someHtml = content;
var newDiv = document.createElement(old_div.tagName);
newDiv.id = old_div.id;
newDiv.className = old_div.className;
newDiv.innerHTML = someHtml;
old_div.parentNode.replaceChild(newDiv, old_div);
}
//]]>
</script>
</form>
</body>
</html>
The expression “software is hard” (a quote from Donald Knuth if I’m not mistaken) has seen a lot of mileage (yours truly contributing my fair share) over the years because of it’s simple truth. And in that, we’ve all searched and found (or not) some or other holy grail of methodology. And then the methodology wars began…
And with each new spin, a new skirmish emerged on the radar. Even some of the the tool-chain manufacturers got involved, either creating their own style or methodology (i suspect largely to suit their product rather than the process) or adopting their product to try and encompass the latest and greatest in fashionable methodology. Much ado.
Now software is both art and science. And as such, you need a healthy dose of both to get it right. The art demands your imagination and creative skills; the application of your emotional quotient and your ability to think beyond the four-sided. The science demands much the same plus discipline. Art, too, demands discipline (find me a great writer, painter, cartoonist, graffiti-artist, musician who did NOT practise and hone his/her ability each and every day- for hours each day). Art and science are much the same. Discipline is but one of the common threads.
Discipline to sit down each and every day, for hours, and get it right- get it perfect. That doesn’t mean just hours of random throwing paint at the canvas or the random plucking of guitar strings (which is my forte, by the by). And what about the scientist? Does she spend hours each day in the laboratory throwing random chemicals together into a test-tube to see what might happen? Maybe once in a while, that kind of activity is fun- but not a primary activity.
No. They all set themselves down each day, both scientist and artist, and constructively engage their brains, and think for themselves about what they are actually doing- or going to do. They know before the experiment or song or painting is completed- what to more or less expect. Sometimes it doesn’t turn out that way- and the results are either surprising or horrendous. Sound familiar? But by and large, it’s predictable- and it should be. Software is no different.
How you get there, and which methodology you use is largely irrelevant (i say largely, but you need to read the legal copy disclaimers in fine print carefully); as long as you have discipline. Following a set pattern so often that it becomes part of your autonomic nervous system is key. There’s good reason to do it, especially when you add in the one thing that distinguishes software: deadlines. Although, I am sure that in this day and age, professional artists and scientists suffer the same. Deadlines make the job more interesting- and the need for discipline even more critical.
A brief observation of any professional field where life and death are important will reveal the stand-out-in-your-face notion of REPEAT. In fact, it’s the only way we actually ever learn anything. You repeat the excercise over and over again (ad nauseum some might say) until you get it right blindfold. Why? Because when there’s a deadline, you go blind. And the more impossible the deadline, the more blind you become. You don’t have time to think- just time to do. And you need to make sure you are STILL doing it perfectly.
So, HOWTO Do Software. Pick a way. Find a way. Develop a style and method of delivery that embodies rational scientific reason to justify the “why” you do it that way. Don’t do something or end up doing something “just because it’s the way we do it” and not have a valid reason and purpose behind the behaviour (and I’m afraid if you don’t even recognise that, your opinionated delivery is just going to be that- opinionated). Add in your own artistic flair- but above all- be disciplined about it. Not just off beat, whacky, eccentric, random or out there. Notice i said “just”. Which means you can still be off beat, whacky, eccentric, random or out there- just be disciplined about it. Oh- and write quality tests 😉
I stumbled across the Thrift framework not so long ago and have been intrigued ever since because of it’s promises. And it’s easy to fall in love with the marketing and promises of any framework when it tickles and uses the words and phrases you like to hear, not so?
So finally, I have the opportunity to test drive it: in a design that will become a product that will be released into production in the not so far future. So I want to make sure it’s ticking along as I would expect it to, especially if I want to test, implement, debug, deploy, maintain, scale and extend. And so far, i’m tres impressed.
On the server, I have the default Thrift server, Ruby flavoured, running on Mac OS X with a CSharp client on a Windows XP box (same LAN) and all with no extra tinkering; just as is, courtesy of the generator. Luverly stuff! And then, the implemented handler on the server uses ActiveRecord to handle the database lifting. No Rails: just Thrift and ActiveRecord. And it rocks (so far).
I’ll more than likely be documenting this implementation in more detail over time since the combination opens up many more opportunities in the space i love to work play in. And that’s including the spike project source code.
References and gratitude to the following authors/posts which assisted in getting this going:
Morty py is the same Morty that was built using Ruby on Rails as part of a bigger scheme related to the basics of financial learning, specifically the concept of amortisation. Morty py, as it’s creative name suggests, is a Python implementation. Moreover, it’s also hosted on Google’s AppEngine.
In all, the differences between the frameworks and development experience are both varied and the same. It doesn’t really matter which is “better”- that discussion is a moot point. But in summary, i love the RoR implementation for it’s expressiveness in code and coherence of the MVC pattern. But Google’s AppEngine rocks when it comes to functionality and the tool chain. Performance (for this app) is much of a muchness. Python is really nice, and so is Ruby. Granted, getting to grips with Python was much easier, but that’s only because my multi-lingual skills have improved greatly. And being a multi-linguist is so much more satisfying.
Afterall, imagine, in one day, coding the backend in Python, some related services in Ruby, maybe an optimized service in C, with a front end in C#, possibly ASP.NET or WinForms, a mobile front end in Java and then some obligatory JavaScript to boot. Not forgetting the frameworks that come with each of those languages that make them ultimately productive. For me, seventh heaven 😉
Maybe the guys at Nokia have different ideas about concepts such as “target market”, “market segmentation” or “target audience”?
Technocists? Really. This kind of thing should be outlawed. It’s the 21st century! But then again, the money votes always make the biggest difference. Bye, bye Nokia Music Store.
Started working with AppEngine a little bit recently and for the most part, I’m impressed by the ability to just get on with it. It resonated with some of Rob’s post and his idea of “stop thinking, just build” (with the ‘stop thinking’ part given a reasonable and relaxed interpretation on my part). And even jumping into Python again was fairly easy (read ‘nice’). Admittedly, my journey with Ruby has helped big time in overcoming the “who’s-moved-my-cheese” factor when it comes to static typing, intellisense, IDE… well, all the “trappings” if you like 🙂 So, back to AppEngine.
It’s fast, simple and uncomplicated. Some straightforward abstractions and useful mocks (like the user login for example) and even without having to host an app on Google, using the tool chain locally is superb for tracer bullets- even quicker than, dare i say, Rails? 🙂
Once, that is, you get over with the conventions of the platform and language (which is not huge by any stretch of the imagination). And on that note, i just want to state categorically that conventions are great. Not the kind where you drink good coffee and chat much g33k. The kind where you make a whole bunch of assumptions up front and then code everything according to those assumptions (and a further step of faith: you wire those assumptions into the framework). Yes, i know what they say about assumptions making something out of U and ME. A quirky expression- but is that really an absolute truth? And I’ve noted a different kind of assumptions before.
I feel this is where some of the mainstream programming gets lost from time to time (and with good reason mind you). Anything can happen, everything goes- no real conventions: you get to code *everything*. Joy. (All) you have are classes which you can abuse to perform functions and in between you get to do a lot of heavy lifting. Then again, what’s heavy is relative.
And in the web application world, AppEngine does a lot of the heavy. Which is great for just getting on with it. Try it. Go on… 60 minutes is all it’ll take.