JavaScript's non-existent relationship to Java

Despite the fact that I can no longer, by any stretch of the imagination, be referred to as a "beginner" where my career is concerned, I sometimes do like to read beginner books on tech. It's oddly soothing. There's also plenty I can learn in terms of how to communicate tech concepts and ideas, from the authors of such books, if not the actual tech itself.

And this is one such book that I picked up from the neighborhood library recently - How to be a Web Developer, by Radu Nicoara.

This book.

Now, this isn't one of my Reference Reviews - I didn't finish reading the book and this would be dishonest. Radu Nicorara probably knows his way around the building blocks of the World Wide Web and has, again, probably done a whole lot more than I have. After all, he published a book. And I give him all the credit in the world for even attempting it.

However...

...once I got to Page 60 (or thereabouts), I encountered a statement that was so egregious that it took me out of reading the book entirely. Not that I ever found the book all that engaging in the first place.

This passage shocked me.

JavaScript is a scripting language (meaning the code is not precompiled) that's derived from the Java programming language, hence the name.

I was in complete disbelief when I saw this. Just to be sure, I sent a photograph of the page to Meta AI, and Meta AI being the nice little bot it was, it described the passage as "a bit misleading".

A bit misleading?! Try "completely false".

The error

For anyone who might be tempted to repeat this, JavaScript is not derived from Java. Aside from the fact that they may both be described as programming languages (coding pedants may insist that in JavaScript's case, it's a loose description) they don't actually have anything to do with each other.

JavaScript began life as a loosely-typed client-side language meant for browsers to interpret. Java was (and still is) a strongly-typed compiled programming language. The names are similar, and the syntaxes are similar. But that's where the similarities end, and even these similarities can't be used as evidence for JavaScript's relationship to Java.

In fact, JavaScript's original name was Mocha. Yes, as in the coffee. It was changed to "JavaScript" as some kind of marketing ploy to mislead people into thinking it was a child of Java. Well, guess it worked!

Fancy a cuppa Mocha, luv?

This reminds me of an encounter on the Clubhouse app where I heard some American woman make the ridiculous claim that in the Chinese language, "the words for danger and opportunity are the same".  John F Kennedy, the 35th President of the USA, was the first to say this back in 1960, and he was wrong. In Chinese, danger is "危机" and opportunity is "机会". Both words contain the word "机", but "机" is also a suffix commonly used to describe machines such as "飞机" (flying machine, a.k.a aeroplane), "手机" (hand machine, a.k.a mobile phone) and "耳机" (ear machine, a.k.a earphones). At the risk of stating the painfully obvious - aeroplanes, mobile phones and earphones have fuck-all to do with danger or opportunity, just as JavaScript has no relation to Java.

Which tells us a couple things - just because two words sound the same or contain subsets of each other, does not make the things they are describing, related. Thus, just because Java and JavaScript both contain the words "Java", it doesn't follow that they're related in any way. The second thing this tells us is, if you don't speak a language, maybe keep the witty quotes to a minimum unless looking stupid brings you deep emotional satisfaction.

As for syntax, both Java and JavaScript's syntax is based on C. Curly brackets, semi-colons, function declarations and so on. But this similarity is not confined to Java and JavaScript. Several other languages such as PHP and C# also have great syntax similarities with Java. In terms of similarity, C# is even closer to Java than JavaScript is.

All in all...

It's not my intention to jump on Nicoara for this error. Whomever his editor was, shares the blame for this. And this glaring factual error aside, what little I read of his book seemed sensible. Therefore, I didn't contact Nicoara and inform him of this boo-boo. What good would it do? It's not like one can un-publish this book.

Besides, I'm not exactly perfect. Early in my blogging days, I probably made my fair share of factual errors. Though, in all fairness, it's not like I'm profiting off my blog, or asking people to pay for it.

All that aside, I used this as a teachable moment. Even if that little piece of programming history I taught was dryer than a nun's coochie.

Java nice day!
T___T

What's the best programming language for beginners?

What should be a programmer's first language?

Often, this is not a deliberate choice, more a matter of circumstance. Perhaps a programmer started on QBasic as a kid. Perhaps, like me, the programmer picked it up in school and was made to learn C++ or Java. I would even venture to say very few programmers start out saying I'm going to begin my programming journey with the best, most modern language out there! To begin with, how would they know what constitutes the "best" programming language, or what even is a good programming language? You don't know what you don't know, after all.

Let's learn!

Also, how suitable a programming language is for your purposes also really depends on what your purpose is. Do you want to crunch data? Write games? Build web portals?

So, obviously, before we can sort out what the "best" programming language is, perhaps it is more useful to figure out what a programmer's first programming language should be. After all, this choice opens different doors.

For that, we should probably look at a few factors. I can only draw upon languages I've coded in before. as examples, obviously.

Syntax

For this, we look at simplicity of writing code in that language. How intuitive the syntax is, and how few extra keystrokes needed to get something done.

For this, my obvious picks would be Python or Ruby. Less of the semi-colons and curly brackets. Anyone picking either Python or Ruby as a first language, I suspect, would be less likely to give up out of frustration.

Code syntax.

C# and Java is probably among the worst for this. Too many namespaces. Overly verbose syntax. I haven't had many projects that needed to be done in either of these languages, and for that I'm truly grateful.

But the one that takes the proverbial cake, in terms of being cumbersome, would be PHP. The function calls structures are wildly inconsistent, and in addition to semi-colons and curly brackets, it also requires a dollar sign preceding every variable name.

As far as syntax goes, the group of programming languages with visually similar styles - PHP, Java, JavaScript, C and its variants - is such that if you pick one up, the learning curve for the others, at least for the simple stuff, isn't so great. Thus, even if PHP is hideously cumbersome in parts, it benefits from being visually similar to other languages mentioned.

Transferable skills

This measures underlying principles or skills that one will pick up while programming in a certain language, that will be useful when transitioning to another stack. It could be something as simple as similar syntax (as mentioned earlier) or strong data typing.

Or it could be something so ubiquitous that no matter what stack you're in, you're almost certainly going to encounter it. A great example of this would be SQL. No matter what kind of programming you go into, the chances of you needing to access a database at some point, are pretty good. I wouldn't go so far as to say that this makes SQL the number one choice for a programmer's first language, but it makes a great case for being a programmer's second, at least.

Data processing.

For a similar reason, if one wanted to go into web development, it's almost impossible not to have to deal with HTML, CSS and JavaScript, but learning JavaScript as a first language just for that, is questionable. As a second language, definitely.

Strongly-typed, class-based languages such as Java and C# would be good choices as a first programming language for learning concepts such as Object-Oriented Programming. (PHP and JavaScript kind of implement OOP as well, but in a way that's a little odd). Python would be the choice if one wanted to have a strong foundation in data structures. However, Python's lack of strong typing might work against it as a first language.

Ease of setup

One of the most daunting tasks of learning a language is setting up the environment for it. Java requires the JRE (Java Runtime Environment). PHP requires an Apache server. Python and Ruby, well, you get the idea.

For this, the most fuss-free option has to be JavaScript, hands down.

All major browsers
run JavaScript.

JavaScript runs on all major browsers. You don't need to install anything you probably don't already have. If you're reading this, unless you're reading it on your phone, you have a desktop browser which you can run JavaScript in. It's almost zero setup. Just write your code, and run it in the browser.

For a Windows environment, VBScript is also almost zero effort. All you need to do is write your script, save it with extension "*.vbs" and you can run it by double-clicking it! Unfortunately, I'm not sure how useful knowing VBScript is.

In essence, in the cases of both JavaScript and VBScript, the environment has already been set up for the programmer.

Popular support

No developer plies their trade without consulting a reference of some sort. Textbooks are a valid source, but for the most updated material, we turn to the internet. Portals and forums provide most of these, with each language having large communities of programmers ready to provide support.

Learn by reading, or
by community.

Which programming language has the largest, or best, communities?

That's hard to say. All communities have their fair share of toxic losers who waste little time being condescending and acting like gatekeepers. At the same time, each community also boasts genuine people. I'm not going to waste time detailing how large each programming language's community is relative to others. Suffice to say, they're all (OK, mostly) large enough to be useful.

Generally, the longer they have been around, the larger they tend to be.

Conclusion

Whatever the choice turns out to be, ultimately, there will be benefits to that choice. That is because no matter what language someone chooses for their first programming experience, the fact remains is that they are still engaging in the activity of programming. It's a start. Some starts are better than others, sure, but it's a step. And hopefully the first of many.

Mind your (first) language!
T___T

Separating Text Editors from IDEs

The acronym "IDE" stands for Integrated Development Environment. There is a little bit of confusion as to what IDEs are, leading to questions like "Is TextPad an IDE?" (Spoiler: The answer is No).

TextPad is a text editor. There are distinct differences between a text editor and an IDE, even though they may look similar to a layperson. Chief of which, a text editor is part of an IDE. An IDE comprises of many components, one of which is a code editor of some sort.

What Text Editors do

Text editors edit text. It could be a block of code, a poem about dinosaurs or a dissertation about why dolphins are such jerks. Think of your text editor as a drum. The thing you beat with a stick so it makes sounds? Yeah, I know, that sounds wrong. But anyway...

Now a text editor isn't exactly a code editor, but it's awfully close. A code editor edits code, which is basically text. It's essentially a specialized kind of text editor, highlighting code structures and syntax errors, autocomplete suggestions and maybe even beautifying it for human eyes.

Now if you think of your text editor as a drum, think of your code editor as a full drum set with cymbals.

Full drum set.

Technically, not all code is text, but for most high-level programming languages, they are. Sublime Text, for example, can edit code for PHP, HTML, Python and a host of other languages. Notepad will edit the text just fine, but won't highlight syntax. That's pretty much the difference between editing code and editing text. Most text editors can edit code in a pinch, and vice versa.

As a web developer, I've had to use text editors to edit HTML, JavaScript and CSS code. And generally didn't encounter many problems. You could still do that for code that needs to be compiled, such as Java or C#, but that would make the process of development way harder than it needs to be.

What IDEs do

IDEs consolidate common developer tools onto one interface, so this potentially eliminates the need to individually configure separate software packages. At the very least, an IDE provides a code editor and an environment for running the code.

Now if following the earlier analogies, think of your IDE as a rock band setup with drums, keyboard, bass guitar and drum set, all in one place!

A full rock band setup.

Some IDEs provide other features, such as:
- file versioning.
- deployment management for DevOps.
- workflow and project management features.
- build automation
- specialized interfaces for mobile development, such as Android Studio.

An example of an IDE would be Eclipse (for Java and Python, among others) and Visual Studio (which handles C#, HTML and so on). They are called IDEs because they also run the code in addition to editing it. They can debug the code and point out syntax and (some) logical errors.

In a Nutshell

Text editors basically process and format text. IDEs almost always include a text editor of some sort, but the function of an IDE goes beyond text editing.

Text you later,
T___T

How I Learned Ruby

It was a fine weekend in 2017 when I started learning Ruby. Three years have passed and I wouldn't exactly call myself an expert... but I have reached a certain level of proficiency in it. What's remarkable is that the way I learned it didn't really follow the way I learned ASP back in the 2000s or PHP in 2010. Back then, I picked up a book, started reading, and then started doing. How I learned Ruby was a little less straightforward than simply reading a book.

Why did I pick up Ruby?

You know what, that's an excellent question. I don't know exactly. I was jobless, low on confidence, and needed to distract myself by learning something. Something or other brought me to this site, Try Ruby. I went through their online tutorial and the Ruby syntax was pretty straightforward. It just kind of flowed. It was only a while later that I read a description of Ruby as a programmer's best friend, and by that time I thoroughly agreed.

What the hell, right? It wasn't like I had anything else to do between attending interviews and waiting for replies to my job applications. So I rolled up my metaphorical sleeves and got cracking.

The process

First was the installation of the Ruby server on my aging laptop. It turned out to be a breeze, especially when you consider all the pain I experienced while setting up the WAMP stack for PHP back then. And then in the Command Line Interface, I learned a bit by typing a few commands here and there.

Then I started typing in entire block codes into text files and running them on the CLI. Now, this was something I could get into. After all, I'm doing pretty much the same thing whenever I use QBasic.

That was when I started doing katas. It was easy stuff like the FizzBuzz algorithm, simple calculators, and so on. Stuff that used basic code blocks like inputs, outputs, If-Else, For... you know, the usual suspects. I even picked up this book, Exercises for programmers: 57 challenges to develop your coding skills by Brian P. Hogan, and did quite a few exercises in them using Ruby. One of them resulted in the Ruby Website Template Generator.

And speaking of books, I did eventually get around to reading them, just to see if it could help reinforce everything I thought I'd learned so far. Ruby recipes: a problem-solution approach by Malay Mandal was one of them.

What I did learn was that there was a lot more detail to the Ruby commands and functions that I had been using - stuff I never knew about simply because my use cases never touched them. Interesting. Perhaps not absolutely necessary, but good to know.

I was starting to write Ruby programs that were still rudimentary, but had more moving parts. By this time, I had landed a job at a major tech company that used a lot of C#. Ruby was a non-essential part of my career at this point, but I kept using it now and then in my off-time because it was just such a joy to code in.

Ruby on Rails

But learning Ruby on its own just doesn't cut it these days. If I wanted to get some real value out of that experience, I was going to have to graduate to using its most famous framework - Ruby On Rails. This was done by exploration of the Rails for Zombies portal, which gave me a fun little kick start. I love programming, and I love zombies.

Turns out Ruby On Rails wasn't such a big revelation as I thought it would be. I picked up some more reading from the local library. All things considered, it was pretty dry.

The Rails view: creating a beautiful and maintainable user experience by John Athayde and Bruce Williams

Rails crash course: a no-nonsense guide to Rails development by Anthony Lewis

Editor's Note: I am neither recommending nor not recommending these books. They were well-edited; I just didn't get a whole lot of value out of them and would have been fine not having read them. But that doesn't mean you're going to have the same experience.

After starting up a Rails server and going through all that stuff about Models, Controllers, Views and Helpers, I quickly realized that this was pretty much the same shit I'd gone through with ASP.NET 4.x or even CodeIgniter. I mean, there just doesn't seem to be that many ways to implement MVC, does it?

To test out this theory, I had to build a website. There was this thing my ex-boss implemented - a multi-lingual site that allowed the user to switch languages at will. I had an itch to try it for myself. To make the exercise even more interesting, I implemented the idea in Ruby On Rails.

And it really wasn't that hard. Personally, I feel that if you're having a problem with Ruby On Rails, your problem might be Ruby itself, or the fact that you need to understand MVC. If you've done both, this is a piece of cake.

Epilogue

Years after the fact, I'm still using Ruby. It's great for recreational programming and I'm getting as much use out of it as QBasic, which is a pity because it can be used for so much more. I got into it because I was idle at the time and needed to engage in a nominally productive pursuit. Perhaps that's why I never delved into it the same way I did for PHP - because my professional survival wasn't on the line.

Also, I discovered something strange. While the Ruby syntax was really a delight to use - terse, uncomplicated and smooth as silk - I had trouble memorizing it the way I did for JavaScript and QBasic back then. Maybe my memory's just not what it used to be, or maybe I've just evolved as a programmer. I'm no longer interested in memorizing commands - I want to get stuff done, and I have no compunction against copying and pasting from the internet, and modifying stuff to make it work. And perhaps, psychologically, since there's no longer any real motivation to memorize anything, I simply don't.

But really, if you're looking to pick up an extra language, I couldn't recommend Ruby enough.

Try it. It's a real gem!
T___T

More About Foreign Talent in the Tech Sector

The ongoing Wuhan Coronavirus scare dredged up some rather ugly behavior towards China Nationals in recent weeks. It seemed as though fear and panic had resulted in years of civility being flushed down the proverbial toilet, and human nature reasserting itself in ugly ways.

But that's wishful thinking. That underlying current of xenophobia was around long before we ever heard the name "Wuhan". The simmering resentment that foreigners take well-paying jobs away from Singaporeans. The feeling of superiority over other Southeast Asians. Among so many other things.

This is not, by the way, confined to the Chinese Singaporeans who make up the majority of Singapore's population. I've had an Eurasian Singaporean complain bitterly to me about being the target of racism one moment, and wax lyrical about how all Filipinos are two-faced scoundrels the next.

Common complaints about foreigners

They take well-paying jobs away from locals. Firstly, well-paying jobs in an air-conditioned office are not a God-given right. They're something we have to strive for, and they don't automatically belong to us. All the foreigners are guilty of, is offering employers an alternative. If you only have a job because no one was fighting you for it, that's not much of an accomplishment.

They steal our women. Two things. Firstly, local women don't automatically belong to local men. See my earlier point. Secondly, local women don't belong to anyone period, because they are not cattle. To accuse foreigners of "stealing our women" is both gross and backward. Local lads, be better than this.

Same goes for women who complain that foreign women "steal your men". We're not your men. Level the fuck up and you won't have that problem.

They don't fit in with our culture. What culture? A culture that's been a melting pot of different races, religions and languages for the past fifty-odd years? I see no change in that dynamic.

I see assimilating foreigners as a task akin to contributions into a code repository. The code comes from different developers, continuously, all from different backgrounds and programming styles, and is merged into a coherent whole that is far larger than the sum of all its parts. Programming is a team sport; and - surprise, surprise - so is the exercise of nation-building. Of course, as in programming, you are going to get rubbish code and bugs. But with time and patience, it all eventually gets straightened out and the code base is all the better for it.

They crowd this island. I'll grant you that. On weekends, some of the places I frequent, like the local swimming complexes, are packed with foreigners getting in my way. I put up with it as a natural consequence of attracting foreign talent.

A crowd in sunny Singapore.

There is a common thread to these complaints - that foreigners have the audacity to compete with "True Blue Born-and-bred" Singaporeans for jobs, partners and space. Where you were born and bred is an accident of birth, nothing more. Expecting special treatment simply for having been born on this island speaks of supreme entitlement and smacks of loser-stink. Naturalized citizens are citizens all the same, and I refuse to treat them any different.

I have two grandfathers, both of whom were born in the province of Guangdong, China, though they were from different cities - one Foshan and one Chaozhou. I'm pretty sure neither spoke English when they immigrated to Singapore, and might not have started even on their respective deathbeds. My story isn't unique by any means - there are at most four to five generations of people who can legitimately claim to be "True Blue Born-and-bred Singaporeans".

(Four to five generations, and people want to act like being a "True Blue Born-and-bred Singaporean" is some mark of a great civilization spanning centuries? Really?)

I'm not unfamiliar with these complaints - decades ago, I may have voiced some of them myself. I thought many of the foreigners employed here were shitty and backward. It was only after a period of serious introspection that I realized it wasn't foreigners (shitty or otherwise) that stood in my way. It was my own damn attitude. That was when I put my own ego aside, rolled up my sleeves and got to the serious business of salvaging my career. And the things I learned about both myself and foreigners in the process were not anything I had anticipated.

One caveat, though...

I don't mind that foreigners take up well-paying jobs. I don't mind that many of them earn more money than I do. If they wish to work here and share their expertise with Singaporeans, I welcome it and am grateful for the exchange.

Where my goodwill ends, however, is when foreigners attempt to meddle in my country's politics. I have an absolute zero-tolerance policy on this. The issue of Singapore's Governance is one for Singaporeans to resolve... among Singaporeans. Foreigners are not welcome to tell me, or even suggest, whom I should vote for.

Singaporean politics are
for Singaporeans only.

I do not attempt to tell Americans who they should elect as President. When my Malaysian tenants discussed politics in my house during the 2018 Malaysian General Elections, even though I was none-too-thrilled with the thought of Dr Mahathir resuming power, I never once tried to sway their vote. As a Singaporean, I inevitably had an opinion on that matter; it was however not my place to impose it.

Long story short; I don't interfere in the politics of other countries, and I expect foreigners to return the goddamn courtesy. And since I don't differentiate between "True Blue Born-and-bred Singaporeans" and naturalized citizens, I naturally include ex-Singaporeans in the category of "foreigners". It's only fair.

Foreigners I've worked with

So yes, I've heard plenty of anecdotes about how foreign talents are a bunch of trash. But, as they say, nothing beats personal experience. Here are some of my findings about foreigners I've been privileged (and in some cases, condemned) to work with. My findings, of course, are particular to the tech sector. Your mileage may vary.

Filipinos. Colloquially known as "Pinoys", they have a reputation for being conniving, two-faced and underhanded. I've worked with plenty of Pinoys. A couple of them were really lazy and unmotivated, and there might have been some of them who fit the "underhanded" stereotype to a T. But for the most part, I've found them jovial and boisterous, and fun-loving. And very cheeky. Not bad traits to have. And a fair number of them were actually (gasp!) competent.

Everything I know about SEO, I began with the basics from a Filipino ex-colleague. And she was always obliging when I called her to ask questions, long after our professional relationship had ended.

Foreigners at work.

Indians. Not our local variety, but the ones from the great continent of India herself. People like to further divide them into North and South Indians, but I really couldn't give less of a shit. In the workplace, they're notorious for being bullying, loud-mouthed braggarts who show off every chance they get, but dodge the hard work. I've worked alongside many Indians as well. We have a cordial relationship, and they can be a humorous bunch. Maybe one has conformed to the negative stereotypes, but I wouldn't tar them all with the same brush. And again, while competency ranged from inept to talented, for the most part, they were pretty good.

From Indian blogs, I learned finer points about coding. One Indian ex-colleague helped me level up tremendously in my CSS. I probably know a lot more CSS than he does now, but it was that dude who gave me that leg-up when I needed it.

Burmese. I'm not aware of any stereotypes concerning the Burmese though I've had many Burmese colleagues. Generally, they've always been friendly and willing to share their knowledge. Although, most of them do seem to have a problem getting their point across. Also, I really hate their food.

What did I learn from the Burmese? Mostly, a lot of C#. I also learned the importance of soft skills, because they were terrible at it. Not that they weren't pleasant, but many of them simply didn't inspire confidence in product owners. I like to think of it as a communication gap that needs to be bridged.

Chinese. Not the local variety (like myself) but those hailing from the mainland. People say they're egoistical and lack social graces. I've certainly come across more than a few fitting that description. But almost all of them were very good at what they did. Almost without exception, they were ambitious and driven - both competitive and (usually) competent. And some of them displayed a level of street savvy that left the stereotypical crafty Pinoy in the shade.

Most of the Chinese I worked with were Middle Managerial level. They were the ones I aspired to be like - both able to delegate and technically excellent.

Of all these foreigners I worked with, did some of them exhibit negative traits? Did some of them have the unfortunate tendency to talk out of their arse? Did some of them have habits that annoyed the living Beejeezus out of me? Were some of them so incompetent that I was amazed they remembered how to breathe? Undoubtedly. But those are not racial traits. Those are individual traits and should be taken as such. I've not always been the most competent and conscientious co-worker, and sometimes I appreciate a little bit of understanding and patience from my colleagues.

The thing about stereotypes is, if we're willing to assign them to foreigners, we have to be equally willing to accept stereotypes about ourselves. If I went by the experiences my organization had hiring Singaporeans, we would undoubtedly be pigeonholed as a bunch of incompetent, spoiled and entitled losers who want cushy, well-paying jobs without having the qualifications to do them. Are we? Undeniably, some of us are. But all of us, as a whole? Does that sound rational to you?

If the answer is "no", then we really need to rethink the stereotypes we so readily assign others. For example, stop automatically associating Pinoys with maids, Thais with hookers and Bangladeshis with construction workers. It does everybody a disservice.

Adapt or perish!

Globalization is here to stay. This is an increasingly connected world due to the Internet, and walling ourselves away in silos isn't going to help anyone.

I worked alongside foreigners for years. I took the opportunity to learn my craft from them. My tenants are foreigners, and they add to my already excessive income. I married a foreigner. In short, I accepted the fact that foreign talent is here to stay, and adapted so that the situation worked in my favor.

It's not the first time I wrote about foreigners in the tech sector. My stance hasn't changed; we do need them. Foreigners have flooded this island for the past decade, for good or ill. It is my honest opinion that everyone should adapt to this. After all, if adaptability isn't a particularly strong trait of yours, there is nowhere on God's green earth you would ever be comfortable in.

If you can't adapt, nowhere is home.

Singapore is no isolated backwater no matter what some of us wish. It is a First World Nation, and we, as a people, need to live up to that label.

Your "True Blue Born-and-bred" Singaporean,
T___T

How I Became An Agency Contractor (Part 2/2)

With all my rumination over and done with, I replied expressing interest and the interview was on.

I showed up in my standard interview attire, and to my surprise, I did not get asked any technical questions. Well, not if you think stuff like "how many scopes does AngularJS have?" counts. The interviewer was the guy who would be my team lead for the next year or so. It was relaxed; unremarkable. The interviewer informed me that the company was a tech corporation. And not just any tech corporation - one of the largest tech companies worldwide. Contract position notwithstanding, it would be a huge step up from the usual penny-ante minnows I'd had to deal with the last decade.

Editor's Note: The company shall remain unnamed till I cease to work for them. I'm old-school that way.

A nice shiny business card.

The interviewer also informed me that while I would be doing work on that company's behalf, this would not officially make me their employee. I would, technically, be an employee of the Recruitment Agency. He asked me if that would be a problem, and I was astonished. Why would officially being an employee of that company be such a big deal? Bragging rights? Opportunity for promotion? A nice shiny business card with my name on it? I was 39 years old, and past all that now.

The Negotiation

After the interview, the recruiter informed me that I had passed, and we would proceed to talk about my pay. Initially, I had named a salary figure I considered to be outrageous.

They did me one better. They raised it by five percent.

Instead of trying to bargain me down like some of the cheap bastards I've encountered, they were going to pay me more than what I asked for. This was the first time I truly got the feeling that I was playing for the big boys now.

One very long form.

The recruiter then, to my horror, gave me a fifteen-page form to fill in. He explained that this company was functioning as an onsite vendor to a Government Statutory Board, and that the Contract position was meant for that role. So as per Government regulations, I had to fill up that fifteen-page form, also known as the G50 Clearance. I moaned and whinged about it a fair bit, but you know what? At least they didn't ask for my fucking "O" Level Cert.

In addition to that, I was supposed to go for a second interview, this time to meet with members of that Government Statutory Board. The second interview wasn't too bad. To my pleasant surprise, the interviewers had actually gone through my website, and, I assumed, read the posts and tried the demos. That was one of the very first vindications of my effort in setting it up.

Waiting

Now all that was left to do was wait. The information I had provided on that humongously long-winded form had been sent to the Government Statutory Board, where they would take up to a month to check everything out and determine that I wasn't some spy from ISIS, or something.

Those few weeks weren't spent idle. I swam daily, wrote code and did a lot of reading. Now that I had all this free time, I spent it on honing my craft further in preparation for my new job. I was reading up stuff that wasn't just programming - it was everything else related to development. Code clarity, CSS, Web Typography and Colors for User Interface Design. I even picked up Ruby!

I read a lot.

In addition, I watched online web tutorials, caught up on TV that I hadn't had time to watch (like Silicon Valley!) and basically enjoyed life and capped each day off with midnight walks around the park with the girlfriend. My morale had been simmering as I remained cautiously optimistic, but now it was positively soaring.  It was basically weeks of doing stuff I'd always wanted to try, and never quite found the time. Well, now I had time - in spades.

Starting the job

When I finally began my first day in the office, it actually amounted to more waiting. Apparently the machine supposed to be assigned to me wasn't ready, so I spent time reading up procedures and practices, and getting to know my colleagues. The majority of them were from India, with a few from Burma, Vietnam and Philippines. With a shock, I realized that I was the only Singaporean at that level. Not that any of them noticed - with my complexion, I was actually mistaken as someone of some other nationality. The Indians thought I was Burmese, the Burmese thought I was Filipino... and I'd rather not think about what country the Filipinos thought I came from.

It was rough going at first. Everything was in C# and I was having trouble remembering how to use Visual Studio and Team Foundation Server after more than five years of not touching the stuff. It did eventually come back to me but it was an uphill battle. There were days I felt almost totally worthless, and days I felt at the top of my game. There were people I took to, and people I couldn't stand.

In short, it was great.

I wasn't the smartest man in the room, though I was probably one of the oldest. But I'd left my ego behind from day one, so admitting when I didn't know shit, wasn't at all difficult. Plus, that fat paycheck helped. Getting paid that much while expectations of me remained low? Learning all that useful shit while, again, getting paid? Knowing that they let me in because of what I could do and not because of the color of my passport? Absolute heaven.

Epilogue

All in all, I lasted one year, and then they renewed my contract. I've been here eighteen months now, though my contract's expiring this July. It's been a wild ride.

Have a good work week,
T___T

Plugging those Knowledge Gaps

Programming languages. Frameworks. Databases. Development Methodologies. There's a lot of knowledge out there. Some of which you may have picked up, some of which you use often, much of which you have yet to even discover. One of the biggest mistakes a web developer - or any kind of software engineer, for that matter - can make, is to think that he knows enough. It is not enough. It is never enough. As a dev, you are not a finished product. You are a work in progress. Keep that in mind, and never let that go... because the moment you do, you are done. Finito.

Web technology is constantly in motion, and if you stay still, you will be left behind. That is not a warning. That is a fact.

And above all, don't ever make the mistake of thinking you're accomplished enough that basic knowledge is beneath you. I've encountered developers who thought they were hot shit, and turned their noses up at researching the basics. The end result is that they could write code that somewhat worked... but they pissed off their co-workers by leaving unhelpful comments in the code and writing code that was so ugly it hurt my eyes.

No dev is ever too good to revisit the basics, or improve.

Piecemeal Knowledge

Many experienced web developers don't learn their craft in school. We pick up stuff on the job, learning whatever needs to be learned and improving as we go along. That seems to be the optimal way because web technologies are widely varied, and it's hard to find two seasoned web devs with identical skillsets. Our knowledge tends to be piecemeal. There are too many things that need to be learned, and far too little time to master any one thing. We learn enough to achieve one task, then move on to the next. If - and only if - we have to execute the same task over and over, invariably we learn different ways of doing it, and a certain degree of mastery sets in.

That said, this is the very reason why there doesn't seem to be a standard set of skills any web dev should have. Sure, most if not all web devs know HTML, CSS and JavaScript. But to what extent? Many web devs would be proficient in at least one back-end scripting language, if not several. And probably worked with databases. How deep should that knowledge be? Most web devs would know enough HTML, CSS and JavaScript to build a web page. Not every dev has ever had to deal with shopping carts. Or Social Media widgets. Some have even managed to go through their entire careers without needing to call a single external API. Some will know just enough JavaScript to manipulate the DOM. Some will know just enough CSS to format text and change page backgrounds. Some will know just enough PHP (or Python, or C#, take your pick) to run a few automated tasks and make some calculations.

That is not impossible, or even wrong. It happens.

No one has an answer to exactly how much a web developer should know, other than a very general list of things... and if they do, that answer is invariably incomplete. That is because web technology is used in so many contexts that there is no one skillset that will cover everything, unless one learns everything. And common sense will tell you that it is impossible. Some people will consider you a total noob if you don't know how to BCNF a relational database. Or the difference between an associative array and a hash table. Or all seven layers of the OSI model. But really, practically, how often in a typical web development environment does a developer have to know these things? If you learn these things and don't use them often enough, how long before you forget them? For instance, I always have to look up how to write a simple Switch Case statement in any language - because I use these maybe once a year. Or less. But a Try-Catch or a For loop - now these are on the forefront. But are these examples true for you? Are they true for all devs?

Whack-a-Mole

There are knowledge gaps everywhere. They will always exist. Everyone has them. Plugging these knowledge gaps is like playing that Whack-a-Mole game - as soon as you bop one pesky mole on the head, another pops right up! Because the more you learn, the more stuff you discover that you've yet to learn.

It's an impossible task. It'll keep you busy for eternity. Does it mean that we shouldn't do it?

Fuck, no!

You see, plugging these knowledge gaps is what keeps devs like me going. The nice thing about web development is that there's always something new and fun to learn. The sucky thing about it is that there are only twenty-four hours a day to learn stuff with.

How to plug those knowledge gaps?

As a fellow professional of mine likes to say, "Google is your friend". Every time you come across a term you haven't heard before, look it up. Religiously. Your search may be satisfied right away, or it could lead you down an endless rabbit hole. Either way, this is a good thing.

Every time you make a discovery while tinkering away, confirm that discovery. Search for the countless other people who have undoubtedly trodden the same path. See what they have to say, and add what value you can. Because silence may be golden, but sharing is priceless.

The takeaway

Generally, you need to start having at least a vague idea of what you don't know. It's all right to be an idiot. Just don't be the kind of idiot who doesn't know he's an idiot.

The only thing you can do about knowledge gaps, is to keep on identifying and rectifying them. You can never eliminate all your knowledge gaps - but you can ensure that the knowledge gaps that you have today, aren't exactly the same ones you had last year. 

Keep plugging away,
T___T

War of the Programming Languages

What's the best language for the web?

Is it Java, the Android OS platform's poster boy?

Is it C#, currently Microsoft's darling?

Is it PHP, Python or Ruby? JavaScript, even?

Your guess is as good as mine. Proponents of any language have, and are still, engaging in vigorous debate (I'm trying to be kind here) as to why their language of choice trumps all other languages. On the web, there are ongoing bitter flame wars between fans of Java and C#. C# vs VB. Python vs PHP. And then there's the whole Object-Oriented Programming vs Functional Programming debate. Open-source vs Proprietory. List goes on forever.

This ought to put to rest the myth that techies are ruled by cold, hard logic. Now, if these were some rabid non-techie fanboys screaming about how superior iOS is to Android, that would be infinitely more forgivable. But these are tech people. Why are techies behaving like children, or worse - laypeople?

Watch any of these debaters. They'll bring out all the flaws of other languages, compare it to the amazing awesomeness of their chosen language, and fanboys of all stripes will have a field day - or a hissy fit. And when that happens, I don't see seasoned professionals. I see a bunch of woefully insecure nerds trying to obtain validation in their choices. Heaping disdain on those who choose to do things differently. Scorn. Hostility, even.

To what end? Does this shit make you guys feel clever, or something? Do techies making choices different from yours, somehow threaten you? Has choice of a programming language or platform suddenly become some kind of religion?

There are no blanket solutions

I've repeated this often, because this bears repeating: There are no blanket solutions. Not in many industries, and certainly not in the web industry. As a developer, the greatest disservice you can do to yourself is to willfully and deliberately close your eyes to the possibilities that other platforms and languages bring to the table, and the power they add to your arsenal. There is no programming or scripting language in the world without flaws. Sure, it's good to know the ins and outs of your tools, especially the environments in which they thrive most. But, using it as a justification to use one language to the exclusion of all else, is an exercise in futility. Especially on the web.

At the end of the day, languages are merely tools. Use the correct tool for the correct occasion. Because, as with the Law of the Instrument, when you only know how to use a hammer, pretty soon everything starts looking like a nail. Don't be that kind of developer.

Everything is a nail.

Everyone has invested time, sweat and tears honing their craft. No one wants to feel like they wasted all that effort on learning to use tools that aren't relevant. But no matter how much we'd love to believe in a tech meritocracy where the most objectively superior platform should be dominant, the fact is that things aren't as cut-and-dry as all that.

Some languages, like JavaScript and PHP, came to prominence back then because there weren't many other options, and they've filled their respective niches so well that uprooting them at this point would be more trouble than they're worth. You can't possibly tell people that your chosen language is absolutely superior and expect them not to snigger. There is no absolutely superior language. No such animal exists. Superiority is completely context-dependant.

Also, bear in mind that at the heart of every programming language, is a philosophy. Certain languages enforce certain practices. Certain languages make it a point not to enforce a damn thing. The kind of person you are determines the kind of languages you gravitate towards. There is nothing wrong with any of that. You like what you like. Your choice is perfectly valid, and let nobody tell you different.

It doesn't matter what you know...

Here's another line I'm fond of repeating: It doesn't matter what you know. What matters is what you can do with what you know. It is not your choice of language which you should be obsessing over.

Take PHP, for example. PHP is the go-to whipping boy of nerds who consider themselves "proper" programmers. PHP to scripting languages, is what Donald Trump is to the Presidency of the United States of America. Want to look enlightened? Want to appear clever? Pick on PHP! It's the perfect target. Point out all its flaws, and bemoan the fact that it's even still in use today. Sure, PHP is a badly designed language. Sure, PHP does object orientation poorly. Sure, PHP is a hodge-podge of features that feel tacked on. And yep, PHP enforces bad programming practices through its laxness.

So what?

You know what uses PHP? Flickr, for one. Yahoo! is another. Wikipedia. Goddamn Facebook!

Yes, I know C#, Java and Python have done pretty well too, but this isn't about what others have done using those tools. It's about what you have done using your chosen tools. Using the language of your choice, what have you created that's even half the significance of Flickr, Yahoo!, Wikipedia and Facebook?

Drawing a blank? You've done nothing to champion your chosen language other than talk about it endlessly on the Internet? Hey, this is just a suggestion, but maybe, just maybe, it would be far more productive to STFU, roll up those sleeves and get cracking!

Time to work.

Bjarne Stroustrup said this in his book The C++ Programming Language, and I think it's particularly apt even today.

"There are only two kinds of languages: the ones people complain about and the ones nobody uses."

Or, how about, say, COBOL? What, you've never heard of it and therefore it must not be important? Junior, COBOL has been around since the 1960s, and at the time of this writing, it's still kicking ass in the banking industry. It does more in a day than you've probably ever done in your hipster kiddy-script writing life, and this is not hyperbole.

All I'm saying is, show some respect. The languages you love to rag on, have earned it.

Enough is enough

Dear developers, you're part of an honored tradition that harkens back to the days of Ada Lovelace and the first algorithm. Passion is fine and all, but this empty one-upmanship is beneath you. Stop arguing. Go forth and create.

guys.chillout();
T___T

Bracket Like An Egyptian

Cheesy 80s pop reference, check! OK, on to serious business.

Languages such as C (and all its incarnations such as C++, C#, et al), Java, JavaScript and PHP share very similar syntaxes. And some of the most ubiquitous features in the syntax are curly brackets and semi-colons.

And today, I'm going to discuss curly brackets. Specifically, placement of curly brackets. There are mainly two conventions, and variations on each one. For a more comprehensive listing, check out the Wikipedia entry at https://en.wikipedia.org/wiki/Indent_style. Every coder has a preferred style, regardless of the one imposed by technical specifications in his or her day job.

My personal preference is this, and it's a pretty old style. Some call it the Allman style, after Eric Allman. I have no idea why I prefer it this way, but it's probably more out of habit than anything, and the style I default to when IDEs and technical specs aren't imposing a preferred style on me. In this style, the opening and closing curly brackets are positioned on their own line, on the left.

if (x == y)
{
    //code here
}

The other style is known as the K&R style, named after Brian Kerningham and Dennis Ritchie. Kerningham & Ritchie, geddit?

In this style, the opening bracket is positioned on the same line as the opening control statement (be it an If, For, While or function) while the closing bracket occupies its own line...

if (x == y) {
    //code here
}

...unless there's an Else condition or something.

if (x == y) {
    //code here
} else {
    //code here
}

Fun fact: in such a case, this is known as a Cuddled Else!

Watch the hands!

The K&R style is also known slangily as Egyptian Brackets. Because, if the brackets were hands, the pose would resemble a very stereotypical Egyptian dance pose. It's also the style IDEs such as Eclipse and Visual Studio, and text editors such as Atom and Sublime Text Editor, impose upon its users.

Egyptian Brackets are mostly preferred for a couple reasons.

Left? Right?

Aesthetics - someone I know claims that the way it reads is more natural. The whole right-to-left thing. Personally, I can't see it. But... you know, whatevs.

Look at all the paper you save!

Saving line space - as this style does not involve the opening curly bracket taking up its own line, that makes less lines of code. And while it only saves one line per code block, I guess it all adds up. And a lecturer once told me printing out a hardcopy of code using Egyptian Brackets would ultimately save paper.

Where should the brackets go?

Doesn't really matter to a machine, does it? Ultimately, it winds up in the compiler. Or interpreter. The only real difference style makes is when you're coding within a team and need to maintain consistency. Really, who cares about saving line space these days?

That's all for now. I'll be brack!
T___T

The Case For Stored Procedures

I used to be a big fan of Stored Procedures. They kept me from worrying too much about SQL Injection and kept my code from getting too repetitive.

That's not to say I'm no longer a fan of Stored Procedures. I still love them, and still use them when the need arises. The thing is, I no longer overuse them. Yes, it's possible to rely too much on Stored Procedures. As I'm very fond of saying - there are no blanket solutions in this business. There's a time and place for everything. And Stored Procedures do have their place.

All the example code below is in PHP and SQLServer.

What's so special about Stored Procedures? 

Security? After all, Stored Procedures protect against SQL Injection, don't they? Yes, they do - to a point. However, parameterized queries do the same thing. In fact, the principle is exactly the same. Whether or not you use Stored Procedures, you should always use parameterized queries.

How about speed? Stored Procedures get compiled ahead of time and all that, so there's less time spent on re-parsing the query with repeated use. Well, you get pretty much the same thing with Prepared Statements.

Ease of maintenance? There's something to be said for that. Separating your logic into different tiers could accomplish that. But this is contentious. Sometimes you want all your logic to be in the same layer, ie your code.

With all of the above in mind, I'm going to outline exactly what Stored Procedures can do, that can't be done any other way.

Security 

Forget SQL Injection for a moment. What Stored Procedures do is execute queries on the tables in your database. With this, you can disable SELECT, UPDATE, DELETE access to all your tables, and grant only access to Stored Procedures. You can even specify which users get access to which Stored Procedures. This greatly limits what users can do to the database. And from a security point of view, that is unambiguously a good thing. A hacker can't simply insert an UPDATE or DELETE or even a SELECT statement into your database if all of these permissions are disabled. Only Stored Procedures are allowed, and since these Stored Procedures carry out very specific functions, they can't be used to attack your database.

Of course, if you're suicidal enough to write a Stored Procedure that drops all your tables, all bets are off.

Again, security

Look at this example...

<?php
$serverName = "serverName\sqlexpress";
$details = array( "Database"=>"dbName", "UID"=>"username", "PWD"=>"password");
$dbConn = sqlsrv_connect($serverName, $details);

$x="1";
$y="y";
$z="abc";

$strsql="UPDATE table1 SET field3 =? WHERE field1 =? AND field2=?";
$statement = sqlsrv_prepare($dbConn,$strsql,array(&$z,&$x,&$y));
sqlsrv_execute($statement);
?>

And look at this one calling a Stored Procedure. Unlike the first example, the tables and fields are not exposed to the application programmer. If you're not the database administrator, you don't know that the table you're updating is table1, or that the fields are field1, field2 and field3. You only know you're executing a Stored Procedure named sp_update!

This is excellent if you have different people working on the database and different people working on the server-side code, and want to limit knowledge of the database to a need-to-know basis.

<?php
$serverName = "serverName\sqlexpress";
$details = array( "Database"=>"dbName", "UID"=>"username", "PWD"=>"password");
$dbConn = sqlsrv_connect($serverName, $details);

$x="1";
$y="y";
$z="abc";

$strsql="CALL sp_update(?,?,?)";
$statement = sqlsrv_prepare($dbConn,$strsql,array(&$z,&$x,&$y));
sqlsrv_execute($statement);
?>

Well, if you use Stored Procedures, there's no longer a need to know.

Neatness 

Logical branching statements are possible in Stored Procedures. And this could be vital if you're a big fan of keeping your code lean. Take, for example, adding and updating a record in a table. Let's say your table named tb_students, and contains student information. Normally, one would have an UPDATE statement for updating the table and a INSERT statement for creating a record, like so. This assumes the variable id was obtained from a POST.

<?php
$serverName = "serverName\sqlexpress";
$details = array( "Database"=>"dbName", "UID"=>"username", "PWD"=>"password");
$dbConn = sqlsrv_connect($serverName, $details);

$name="John Smith";
$address="23 King George's Avenue";
$id=intval($_POST["id"]);

if (id==0)
{
    $strsql="INSERT INTO tb_students (name,address) VALUES (?,?)";
    $statement = sqlsrv_prepare($dbConn,$strsql,array(&$name,&$address));
}
else
{
    $strsql="UPDATE tb_students SET student_name =?, student_address=? WHERE student_id =?";
    $statement = sqlsrv_prepare($dbConn,$strsql,array(&$name,&$address,&$id));
}

sqlsrv_execute($statement);
?>

But wouldn't this be neater?

<?php
$serverName = "serverName\sqlexpress";
$details = array( "Database"=>"dbName", "UID"=>"username", "PWD"=>"password");
$dbConn = sqlsrv_connect($serverName, $details);

$name="John Smith";
$address="23 King George's Avenue";
$id=intval($_POST["id"]);

$strsql="CALL sp_updatestudents(?,?,?)";
$statement = sqlsrv_prepare($dbConn,$strsql,array(&$name,&$address,&$id));

sqlsrv_execute($statement);
?>

You could just call the Stored Procedure sp_updatestudents. If creating a record, just pass a "0" into the student_id field, and if updating an existing record, pass the student's id into the student_id field.

CREATE PROC [sp_updatestudents]
    @name VARCHAR(50),
    @address VARCHAR(150),
    @id INT
AS
    IF @id=0
        INSERT INTO tb_students (name,address) VALUES (@name,@address)
    ELSE
        UPDATE tb_students SET student_name =@name, student_address=@address WHERE student_id =@id;
GO

 

Portability between server-side languages 

Imagine if your code was in PHP and you wanted to make a switch to, say, C#. Hey, if your database calls were all in Stored Procedures, no problemo. Whether you're using PHP or C#, you still call the same Stored Procedure. The Stored Procedure still performs the exact same function on your database! But if your database calls were actually in the code itself, now you'd have to change all of them from PHP to C#.

Ouch.

Are Stored Procedures invincible? 

Not by a long shot. There are situations where use of Stored Procedures makes things sketchy (though we won't go into that here). But the reasons above are the strongest ones I have for using them. Your mileage may vary!

Thanks for reading. Stay tuned for the next UPDATE!
T___T

The Quest For Mobile Knowledge (Part 1/2)

Back in 2013, I started experimenting with mobile development after obtaining my first smartphone. I borrowed a copy of Android Application Development for Dummies from the library, downloaded a working version of Android Studio, and got to coding.

I met with mixed results, and my progress was slow. Sure, my code worked, but only because I typed everything from the example faithfully. I had no idea why it was working. All I really gained from the experience was the knowledge that XML supplied the user interface markup and Java did the rest. Self-learning wasn't cutting it. I needed guidance; being told when I was doing it wrong, and when I was doing it right.

It was around this time in 2014 when I finally decided to get off my arse and work towards a third Diploma. I had just turned 37, settled in a new job, and the time seemed ripe. Before that, I had a Bachelor's Degree and Diploma in Information Technology, and a Specialist Diploma in E-commerce Technology. Diversify or die, that had been the mantra since I left the desktop support job back in 2008. One area that really stood out for me was mobile technology. Having been in web development for years now, I knew mobile technology was here to stay. And learning this stuff could only improve my web dev cred in terms of responsive design, front-end work and cross-platform compatibility. So I looked back to my two alma maters in Temasek Polytechnic and Singapore Polytechnic, but for pragmatic purposes, I chose to take up night classes in the latter as it was a stone's throw from my place.

Meet my classmates 

The first day was a little bit of a culture shock. I know that globalization and Singapore's liberal labor laws had increased the percentage of foreign labor, but still I was in for a little surprise when I realized that less than a quarter of the class were local professionals. Roughly half were from India. Burmese, Filipinos and Singaporeans made up the rest. Were my fellow citizens that set against self-improvement? Was that why I was hearing so many complaints about their jobs being taken away by "invaders"?

Even among the local professionals, there weren't many like me - a code monkey looking to expand his skill-set. They were mostly at managerial level trying to gain an understanding of mobile technology, probably so that they wouldn't get gypped by vendors. There were even a couple of network technicians. Now, I'm not disparaging network techs at all; in fact networking was one of the toughest subjects for me back in school and I have nothing but respect for those who are good enough at it to ply it as a trade. However, the fact remains that these guys not only had never done any kind of software development (much less web development), they had never written a single line of code in their careers. It leads me to think that they hadn't really thought this through and all they were doing was trying to cash in on the Government grants for professional development. And that whoever was vetting suitable applicants for the course, had either been snoozing that day, or taken a very liberal view as to what constituted "experience in web or software development".

All in all, my foreign classmates seemed more my kind of people. And so the first semester began...

Term 1

It all started out mostly with basic Java. Having my roots in C++, PHP and JavaScript made this a breeze. Having spent a year using almost exclusively C# back in 2012, sure didn't hurt. I got through the basics fairly quickly; in fact the real value of these lessons lay in using an IDE such as Eclipse for the first time. I gave myself a little test, implementing what I had done for this web tutorial, in Java. It was completed within minutes. I supplemented all this by reading Java SE 7 Programming Essentials by Michael Ernest. It's a good reference and I hope to review it sometime on this blog.

Concurrently, we were learning the theory behind mobile technology, what constituted web applications, native applications and hybrid applications. To further cement what I was learning, I blogged about it. This phase was more about drawing wireframes and mocking up mobile applications. I took special note of the tools used, such as Pencil. They would come in handy during my day job.

Term 2 

Now we were having fun in Java. We learned the basics of Object-oriented Programming in Java, and I began applying those concepts to my work in PHP and JavaScript as well. I'm not sure this actually improved the robustness of my work, but it definitely made it more extensible. And then we started making GUIs in Java, using the Swing library. This turned out to be interesting, and after handing in my project, I decided to embark on my own project - a memory game written in Java. To that end, I needed to use some stuff that wasn't covered by the lessons, such as timer functions for animations. Frequent reference to Oracle's documentation did the trick.

I'd be remiss here if I didn't give a little shout-out to my tenant Zhao from Guangdong, China. He'd been renting my guest bedroom for the past couple years. Sure, he had his little eccentricities that drove me nuts, such as this habit of singing cheesy pop songs in the middle of the night over and over, leaving the bathroom lights on the entire day… but he was also experienced in Java and a great help whenever I hit a wall. We had also begun learning JQuery Mobile, and this meant I was picking up jQuery as well. I practised what I could with jQuery, the results of which you can see in this web tutorial during Easter.


Again, to further drill in the process of creating a Single-page hybrid app in jQuery Mobile and porting it over to mobile using Cordova, I created a few apps in my own time - an expense tracker (which I’m still using to this day), a household chores tracker, and a mobile compass. During an annual medical checkup, my doctor gave me a valuable piece of advice: if I wanted to succeed at something, I had to make it part of my daily routine. In fact, I had to make it a part of me as much as possible. (She was actually referring to the task of lowering my cholesterol levels, but that’s another tale for another day.) That got me thinking. I wanted to manage my expenses better, right? And my household chores. And I wanted to learn how to make mobile apps.

The obvious solution? Make mobile apps to track my expenses and manage my household chores! I had learned all this really cool stuff, now I simply needed to apply it.

Next

A look at Semester 2