A Tech Professional's Takeaways From Coldplaygate

Everyone's probably heard of Coldplaygate by now; certainly it seems like everyone's talking about it. The scandal involves tech company Astronomer, and its then-CEO Andrew Byron and HR Kristin Cabot. While it does qualify as a tech story in the sense that Astronomer is a DataOps tech company, I've put off talking about it up to now.

Why? Because, well, there were just other, more compelling things to talk about. I mean, the scandal essentially revolves around two high-ranking colleagues Byron and Cabot having an extramarital affair. It's basically two people at the workplace getting into trouble because they couldn't keep it in their pants. Nothing terribly new or original about that, is there?

What happened was that on the 16th of July at a Coldplay concert, frontman Chris Martin was shouting out concert-goers that the Kiss Cam picked up. And the Kiss Cam just happened to fall upon Byron and Cabot in the audience.

It would have been less awkward if the two of them had been in a chest-to-chest bro hug. No such luck; they were in full-on Titanic pose. Byron could have claimed he was giving Cabot the Heimlich, except his hands were entirely too high up, doing his best imitation of a Victoria's Secret underwire product, for that to be a feasible excuse.

The two of them scattered like Flat-earthers confronted with facts, and within twenty-four hours, the Internet identified the two of them as colleagues who were married... to other people.

All in all, a shitshow for Astronomer.

My takeaways to this entire thing aren't moral. Everyone seems to already be on that dog-pile, and there's no real value in me joining in. Also, I'd like to keep this about tech, or at least about the professional space.

Decision-making

Sure, obviously, the entire thing is unprofessional AF. And also kind of dumb.

Cheating on your spouses is one thing; doing it in a packed and very public stadium and expecting nothing to go wrong, is both stupid and reckless. Not exactly the kind of decision-making that inspires confidence in a Board of Directors.

Decisions, decisions.

I'd expect the CEO of a company, whose decisions affect the livelihoods of employees of said company, to make better decisions. Then again, I'm just a software dev, what the hell do I know about decision-making, right? Well, for one, I wouldn't make the decision to put myself in a position where I could be caught live on camera using my hands to keep my sidechick's mammary glands warm.

The faked apology

Soon after the incident, there was an apology posted by a troll account, pictured below. It appeared to be a post from Andy Byron addressing the events of Coldplaygate.

This fooled many people.

This was debunked fairly quickly, but apparently a lot of people were convinced it was real, and it spread like wildfire. Andy Byron was being roundly mocked for being both tone-deaf and an idiot. Unfairly, in this case.

But here's the question: why did it seem so real?

The reason, dear readers, is disheartening. Too many people in positions of authority, when called out for behaving badly, post insincere-sounding apologies like this one. Usually along the lines of "this is not who I want to be" and "I am a work in progress", and even the shade thrown at Coldplay at the end did not appear out of character simply because it happens so often. That level of entitlement is all too real, even if the post wasn't.

The simulation was, if anything, too on-the-nose. There was no AI and deepfake involved in this deception; the troll account wasn't even trying that hard. This is deeply concerning.

LinkedIn Profiles

On Kirstin Cabot's now-inactive LinkedIn account, she described herself as "a passionate people leader known for building award-winning cultures from the ground up for fast-growing startups and multinational corporations. An influential leader and fearless change-agent, I lead by example and win trust with employees of all levels, from CEOs to managers to assistants."

Just reading that made me throw up a little in my mouth. If you want your LinkedIn profile to sound as cringe as possible, you could do worse than take notes from this one.

Word salad.

Can someone say "word salad"? What is the term "fearless change-agent" even supposed to mean to anyone? What's even more disturbing is, this is supposed to be a HR professional. Is this the kind of garbage that impresses HR? Or is it just some kind of SEO for AI-powered recruitment? Either way, if this is the new normal for both job-seekers and hirers, we are so screwed.

Much of the sniggering has been about how someone with such a self-aggrandizing LinkedIn profile could turn out this way, but honestly, I've never held such profiles in high regard. If you're someone that would be impressed by fancy words on a LinkedIn profile that a thesaurus could vomit out, that's on you.

Conclusion

I wouldn't be too hard on Andy Byron. Not everyone can handle being in a position of power. Tends to go to ones head, you know? Both of them, in some cases. Heh heh.

Also, Kristin Cabot. Sure, call her a skank, homewrecker, whatever. But her being HR aside, what's she really done that's so different from every other woman who ever cosied up to the Boss?

Looks like they got (cold)played,
T___T

A Comparison Between Tables and Divs (Part 2/2)

Divs have been the de facto standard for web layout for over a decade since the advent of CSS. The versatility of divs cannot be overstated, though it is possible (and alarmingly easy!) to overuse them.

Deep levels of nesting.

Any web developer who has ever run into front-end maintenance problems due to multiple levels of nested div tags, will know exactly what I mean. This, of course, naturally leads to the question: Can tables be nested too? The answer is yes, and those seriously disturbed individuals who have attempted this will doubtless live to regret such depravity.

Learning curve

Divs are usually used as containers for HTML elements and content (including other divs) and then styled using CSS. This can lead to a whole ton of nested divs if a web developer is not careful. Again, as with tables, any missing open or closing tags leads to malformed HTML, thus it is important to keep them as simple as possible. Unlike tables, this is actually possible for divs, since the minimum viable HTML for one div is a single div tag.

<div>Content</div>

The learning curve for divs by themselves isn't huge, though CSS is another matter entirely. There are tons of options that can drastically change the visuals of your site. In addition to learning about the CSS Box Model, a web developer also needs to understand the position property if fancier shenanigans are required.

Use cases

Web layout now predominantly uses divs for many reasons, chief of which is mobile layout. Div layouts are easily made to be scalable (due to CSS) and this a site can be easily fitted to whichever screen size is required, without needing to make a lot of changes.

Different devices and
screen sizes.

Divs can also be used for tabular layout with a few interesting options depending on the library used, but this also tends to complicate matters; and in my opinion, does not significantly have less problems than simply using table tags for such use cases.

SEO

The ability to separate styling from content is one of the greatest boons of div tags and CSS. This solves many problems that table-based layouts are prone to.

Crawling the web.

For example, when using div tags for layout, it is possible to position important content in the HTML for web crawlers to pick up first, while visually repositioning the content elsewhere or even hiding it. Not only is it possible, CSS makes it almost ridiculously easy.

Conclusion

Tables and divs both have their place. Divs are ubiquitious. Tables fulfill a smaller, but still vital, place in the HTML ecosystem. It is important to use both for their respective best use cases.

Your div-ine web developer,
T___T

A Comparison Between Tables and Divs (Part 1/2)

With the birth of the Internet, there have been two HTML elements that have often been used to do the same job - namely, the table and div tag. In this blogpost, we will compare the two and their best use cases.

Tables are predominantly a grid-layout element that is best used to present data that can be presented in a spreadsheet. In fact, if you highlight a HTML table and copy it, you can then paste the table in a spreadsheet application.

Spreadsheet data.

Tables can have columns that span multiple rows, and rows that span multiple columns. In this manner, more complex data can be represented.

Learning curve

Tables are not a difficult concept to muster. They can, however, be heinously cumbersome to write, let alone maintain. The table tag does not function on its own; it at the very least requires tr and td elements. thead and tbody are largely optional.

<table>
    <tr>
        <td>Content</td>
        <td>Content</td>
        <td>Content</td>
        <td>Content</td>
    </tr>
</table>

Usage is simple enough even if one throws rowspan and colspan attributes into the mix. Enough repetition and a child could learn it. The real question is whether or not that child would want to.

The problem with too many tags is that if one closing or opening tag is left out, this leads to malformed HTML. And with the nature of tables, this happens all too easily.

Use cases

These days it's not even a contest, but there was a time when using tables for page layout was actually a thing. In some dark corners of the web, table-based layout, along with (gasp!) frames, can be found if one looks hard enough. These days, though, suggesting tables as a site layout would earn you some serious side-eye.

Tables were adequate for layout back when screen sizes did not vary so much. Fixed width-layouts could handily be created with table elements that had the border attribute set to 0. Still not ideal, and smacked of trying to fit a square peg in a round hole, but they worked in a pinch if you weren't planning to make frequent changes or do anything extremely fancy.

You're not fitting that in.

Times have changed, and table layouts for websites are almost completely a thing of the past. Yes, I said almost. Hey, some people enjoy suffering; there's no accounting for taste, is there?

No, tables have now been relegated to carrying out the task they were originally meant for - presenting grid data. And that's a task they perform like no other.

SEO

Now, web crawlers have no problem reading content from tables. However, since tables and content are intrinsically tied together and tabular data is read linearly, this presents a problem if the visual design of the site clashes with the SEO requirements.

For instance, say you have content that you want displayed at the top of a site. However, in terms of importance, some other information takes precedence and you want the web crawlers to read that first. That can't happen in a table element unless you replicate the information at the top of the table and then hide it visually (which is workable I guess, just a huge pain in the butt to maintain).

Less than ideal
for the blind.

Also because tabular data is linear in nature, content readers for the visually impaired would totally mess it up if they were reading table-based web layout.

Next

We examine the div tag.

The differences between Posts and Pages

Post or page? Users of blogging platforms such as WordPress or Google blogs will have encountered this problem. There is a fair amount of confusion over what constitutes a post or a page. And today, I will be breaking all this down.

Posts or pages are generally interchangeable in use, but they have specific use cases that apply in certain contexts.

Time-sensitivity

When you have content that is transient in nature, posts are the better option. What does "transient" mean in this context? Well, when you have information that is time-dependent, you generally use a post. Examples include an event happening this week, breaking news, a limited-time special offer and so on.

Time-limited offer.

But when you have information that is static or timeless and not likely to change anytime soon, a page is preferred. Examples include a contact page, an About Us page, or something like Terms And Conditions.

This is also why time-related information such as publish date and last updated date are relevant to posts, but not for pages.

Structure

Pages can be a list of other pages, or posts. You can also use posts for that, though that would be a little weird.

A page can be a sub-page of another page. There is no such thing as a sub-post. A post is pretty much a leaf node.

Navigational menu code.

As mentioned previously, pages are for static or "timeless" content. Therefore, links to pages are usually part of your site's main navigation and will appear no matter where on the site the user is on. Links to posts, on the other hand, typically only appear in very specific contexts. For example, on the site's landing page, links to recently published posts would appear. When reading a post, links to related posts might appear at the bottom of that post.

Features

Posts, being time-sensitive, should be leveraged to bring traffic to the site. One of the ways to do that is to add a comment section to a post.

Blog comments.

Generally, one does not have a comment section in a page. It's certainly possible, but who really wants to comment on things like your company address?

Similarly, if you assign categories or tags to posts, they are more easily searchable and this is a boon for SEO, assuming you enable that option on your site. But this features does not make sense to use on pages. One might even argue that all pages are a special kind of category by themselves.

In Conclusion

There is no hard and fast rule. Do what makes sense for your site or blog. However, all that I have outlined above are good rules of thumb.

Page me, I'll keep you posted!
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

When to avoid AJAX

I love AJAX. I really do.

It's a tool that has brought me countless joy even as I built complicated pages that require tons of functionality. It can be great for HCI (Human-computer Interaction), and the like. But like all tools, it can be overused. And misused. I know from first-hand experience.

A supervisor once sent me a memo to "remove all unnecessary AJAX". As far as I was concerned, that would entail removing just about every occurrence of AJAX. Because very little about AJAX is "necessary". Most things work fine without AJAX. AJAX just adds on certain little perks - like  not needing to reload your entire page to get new information. Your application isn't going to die without it.

So here are some of the situations where you should seriously consider not using AJAX.

Having a hard
time searching?

 

You need your stuff to be search-friendly

Search robots trawl HTML that has been generated by web servers. AJAX bypasses the HTML generation process, filling in content in the HTML placeholders only after the HTML has already been generated by the web server. As such, search engines are only able to pick up the HTML of the pages before the AJAX-generated content has been filled in.

If, for example, you're running a news blog and your articles are generated by AJAX, all robots are going to pick up are the generic HTML templates that's used to house your AJAX content. Kind of like getting the donut without the jelly. Hardly ideal if you're going for Search Engine Optimization and a good web presence. Not a concern if it's an in-house web application..

The conventional way,
and the newfangled way.

 

The conventional way works just fine, or better

AJAX, by design, breaks up the traditional flow of the web. Back, Forward and Refresh buttons do not work in expected ways. That can be a good thing, and it can be a terrible thing. Sometimes, you need your pages to be synchronous.

Let's say you have a very long article that has been broken down into 5 different pages. Being able to use the browser's Back and Forward buttons on this one, would be invaluable, but impossible if the 5 pages of content are served by AJAX. And bookmarking each page would be an exercise in futility because the bookmarks would all point to the same URL.

By the same token, you may want to avoid AJAX if your page lacks refreshable content. By "refreshable" content, I mean dynamic content that needs to be updated periodically while the user is accessing the page. This may apply to news feeds, user-posted comments and user notifications. It makes no sense to apply AJAX to a page with only a header, content body and footer. Try to avoid overkill. Remember, at some point, people are going to have to maintain the page.

The entire point is to give users what they want with a minimum of fuss.

Does stuff need to run on the
older platforms?

 

Backwards-compatibility is an issue

If JavaScript is disabled or very old browsers are being used, there goes your AJAX. There are, of course, times when I'm tempted to say "to hell with it" and do it anyway. But understand that you're taking a very real risk here of alienating that portion of your intended audience. If your content can be served just fine without AJAX and you really need as many people to see it as possible, go retro.

A good example would be pages with content that does not need to be dynamic and isn't expected to change very often, such as a technical document.

Remember this!

Being the exciting tool that it is, developers get tempted to use AJAX just because they can. And that is usually a bad idea. There are no blanket solutions in this business - not AJAX, not nothing.

Don't overdo anything. Don't be A-JAX-ass.
T___T

How I first learned PHP (Part 2/2)

The Demo

While practicing PHP, I had given myself a project to work on. This was necessary because some job ads asked for a portfolio or work sample. In the absence of any actual work done, I reasoned that a working demo on my laptop would do just as well.

But what kind of site could I make? The answer came swiftly. I love football (well OK, I love watching football). I love making websites. Make a football website!

As luck would have it, a call arrived from the boss of a tiny web development firm, and he asked for a work sample. This time, I was ready. After he viewed the screenshots, we arranged for an interview. Coincidentally, this workplace was a block away from the girlfriend's apartment. She made me promise that if I landed the job, I'd go to her place every evening and eat her tomato and scrambled eggs for dinner. (Scrub your filthy minds, I was referring to an actual dish!)

Screenshot 1

Screenshot2

Screenshot 3

The Interview

The technical portion went well. I was quizzed on web development concepts, not PHP specifically. Those questions were easy enough and went without a hitch. He was testing my foundation, and I was responding like a pro.

The trickier part came when he asked me how long I would take to write a login sequence. This sounded like a trick question. A login sequence? I was fairly sure it could be done in maybe 15 minutes, but didn't want to look overconfident. Therefore, I carefully replied, "If I took my own sweet time, maybe 45 minutes?"

His response startled me. "Excellent. When can you start work?"

That was it? My befuddlement must have shown, because he went on to explain that the other candidates he'd interviewed had given their answers in days, not minutes, and this, in his mind, showed that they didn't know PHP as well as they claimed. The irony of the moment was not lost on me. Shit, I didn't know PHP as well as I claimed.

Negotiation

We went on to talk about money. He didn't want to pay what I was asking for. Fair enough, I was trying my luck anyway. But he named me a ridiculously low figure. I laughed. He then promised to raise it after my probationary period. This made me laugh harder. I stood up, exchanged a handshake with him and said, "Thanks for your time. I appreciate it, and I'll certainly consider your kind offer."

The tone of my voice made it quite apparent that I would not be considering any such thing.

With that, I left and put this interview behind me, mentally preparing myself to go back to the metaphorical drawing board. Outwardly I appeared unconcerned, but inwardly I was wondering if I should have simply swallowed my pride and accepted.

Four hours later, he called back and raised his offer by 25%. And told me the condition was that I had to start on Monday. In other words, ASAP. I was only too glad to oblige.

The Takeaways

Up to this point, if I had harbored any doubts whatsoever about my ability to get back on my feet, they were banished once and for all. No income for ten months straight? No marketable relevant skillset? Cry me a river, sunshine. When the alternative is to roll over and die (or worse), you'll be surprised at the actions you're willing to take in order to achieve your goal.

Once I formulated that plan to learn PHP, no possibility of failure was entertained. There was nothing to fall back on other than desktop support, and it was determined early on that this was not a viable option. With clarity of purpose, I was able to focus on the various little milestones I had set, ie.get a server up, get some sample code working, and develop a sample  PHP website for showcasing purposes. And meanwhile, keep sending out my CV. The plan was simple enough, the goals achievable enough. I couldn't control market forces, but I could certainly work with them.

Patience. It'll come.

The greatest lesson learned during this time was probably this - patience.

I had stopped putting pressure on myself to ace every interview. In fact, I took every interview as good practice for the next one. And there was always a next one. When the pressure's off, you naturally get better. The anxiety and air of desperation were no longer there. In my case, I even found the audacity to simply walk away during negotiations when the terms were unfavorable.

Patience.

Belief that I was on the right track, faith that I would eventually make it, and security in the knowledge that success would not be an overnight thing. I had gone ten months without income. And before that, I had squandered five years of my life on desktop support. What was another week? Another month?

Epilogue

As it turned out, this wasn't a bad place to work. Sure, the surroundings were sleazy and the building was old. Sure, the pay had a nasty habit of arriving late. Sure, I was working 12 hours a day, almost 7 days a week, public holidays included. The girlfriend was less than thrilled, and eventually called time on our relationship.

But I was getting paid. And I was learning. The boss turned out to be a database guru. He taught me how to optimize my queries, make them leaner and faster. And from my colleagues, my CSS got bumped up another level. I taught myself to AJAX my code. Learned a bit about SEO. Since this was such a tiny set-up, occasionally I was tasked with door-to-door sales and client meetings. The time I spent here was rife with opportunities to learn.

Eventually, I left the job for greener pastures. But landing this job was a good memory, and gave me a world of confidence. My journey was still far from done, but it was good, solid career progress.

Oh dear, this story got a bit long, didn't it? Here, have some patience!
T___T

To the Strong and the Bold

With the introduction of HTML5, there has been a fair bit of confusion regarding the tags <strong> and <em>. Many developers have regarded these tags as replacements for <b> and <i> respectively. Even HTML Editors such as CKEditor and Adobe Dreamweaver have introduced these as defaults. Click on the  button in either of these applications and you're likely to get a <strong> instead of a <b>. Likewise, click on the button and you'll get <em> instead of <i>.

What people don't realize is that, unlike certain tags like <font> and <center>, <b> and <i> have not been deprecated. That's right, they are part of the HTML5 specification.

HTML5 Specs for the STRONG tag: http://www.w3.org/TR/html5/text-level-semantics.html#the-strong-element
HTML5 Specs for the EM tag http://www.w3.org/TR/html5/text-level-semantics.html#the-em-element

What exactly are these tags for?

We'll start with the difference between <strong> and <b>. Once you understand this, <em> and <li> should follow quite easily.

On the surface, to the human eye, there is no difference. <strong> and <b> both turn text bold, as shown below.

This text is <b>bold</b>
<br />
This text is <strong>strong</strong>.

This text is bold.
This text is strong.

The difference is that <b> is purely cosmetic, while <strong> has semantic significance. You use <strong> when you want to put some extra weight on a word, to increase its importance. You use <b> when you only want to make text bold.

With semantic significance, you can change the entire meaning of a sentence.

He didn't say he stole her jewels.
He didn't say he stole her jewels.
He didn't say he stole her jewels.
He didn't say he stole her jewels.
He didn't say he stole her jewels.
He didn't say he stole her jewels.
He didn't say he stole her jewels.

Contrast this to the code below. The headers are rendered with the <b> tag, not because they have any special significance, but because it would look nicer to have them in bold.

<table>
   <tr>
                <td><b>Header A</b></td>
                <td><b>Header B</b></td>
                <td><b>Header C</b></td>
                <td><b>Header D</b></td>
   </tr>
   <tr>
                <td>Data</td>
                <td>Data</td>
                <td>Data</td>
                <td>Data</td>
   </tr>
   <tr>
                <td>Data</td>
                <td>Data</td>
                <td>Data</td>
                <td>Data</td>
   </tr>
</table>

Result:

Header A	Header B	Header C	Header D
Data	Data	Data	Data
Data	Data	Data	Data

Of course, one could argue that we could just solve this thing with CSS (and you'd be quite right), but CSS is not the subject matter here. Just to be pedantic, the CSS descriptor font-weight:bold is also purely cosmetic.

Yes, to the human eye, this still makes no difference. <strong> and <b> will still appear as bolded text. It will, however, make a great deal of difference to a machine. The builders of the HTML5 specification probably intended for semantic markup to play a part in SEO (Search Engine Optimization). Thus, the separate tags even though they both look the same to you. Because if everything in bold was important, that would lead to a lot of cranky search results!

New fun stuff!

Apparently, you can also nest <strong> tags.

<strong>He never said he stole <strong>her</strong> jewels.</strong>

To the human eye, this does nothing more than bold the entire block of text. When a machine reads this, however, it's supposed to place importance on the sentence, and even greater importance on the word "her" within that sentence.

What about <em> and <i>?

So now, apply everything I just said about <strong> and <b>, and apply it to <em> and <i>.

What does this mean for future development?

Well, at this point in time, until everyone gets used to the idea and starts applying this standard, you could probably get away with using the tags interchangeably. But looking to the future, you're advised to adapt. Heaven knows when HTML5 syntax will finally stop fluctuating though, so take your time.

Until then, fortune favours the <b>, so go get <em>!
T___T