A new cringe-worthy craze has taken Singapore by the scruff of her neck for the past month, and consumed the hearts and minds of Singaporeans of all ages, from all walks of life. My Facebook feed and WhatsApp chats are filled with screenshots.
And no, this is not an app review. That would involve me installing and playing it. Hell will freeze over before I install this sucker of memory and battery life on my mobile.
This hellishly addictive app.
Pokémon Go is an augmented reality game created by Niantic, who created the excellent Ingress years earlier. While Ingress is also an augmented reality game and enjoyed a certain amount of success, its reach wasn't as mainstream as Pokémon Go. The cuteness of the monsters and the success of the original Pokémon franchise might have something to do with it, because for the life of me, I can't see what objective there is other than hunt, capture, and hunt some more.
As far as augmented reality games go, Pokémon Go certainly isn't the first. As mentioned earlier, it was preceded by Ingress. One of the earliest forerunners of the genre was SpecTrek which I've tried, but won't be reviewing either. Worthy mentions includeZombies, Run! (which I have installed) and Night Terrors which is next on my install list. Now, those might be worth reviewing. Watch this space!
In the startup I'm currently working for, the tech lead takes us out on Pokémon hunts during lunch break. Oh, the Pokémonity. Other companies aren't as generous, though, with some of my friends reporting that HR has sent out memos explicitly forbidding staff to play the game during their shift.
I recently went out for supper with the guys, and was absolutely flabbergasted when they started showing me their collection. You know things have gotten really sad when a bunch of 40 year olds whom you're supposed to be lepaking with over coffee, now take you on slow drives around the island to find gyms and hunt down these cute little bastards.
I remember the days where my buddies would irritate the living heck out of me by constantly sending me pictures of naked women, or videos of them performing assorted sex acts, through WhatsApp. Not because I have anything against porn - it's a lovely industry and creates jobs! - but because this crap occupies my storage until I take the trouble to painstakingly delete them. Those days are gone and I mourn them - because these same clowns have started sending me Pokémon pics instead. Some are even sending me Pokémon porn pics!
NSFW
Seriously dudes, what the fuck?!
The Silver Lining
It looks like Pokémon Go has at least gotten people to get off their arses and go for brisk walks under the blazing sun to hatch those Pokémon eggs (call me back when this stops sounding weird), though their posture and situational awareness still leaves a lot to be desired.
And that's not even mentioning the sales from Pokémon merchandise such as toys, trading cards and accessories! While I'm on that, check out the Pokeburgs by Hashtag Burgers from the Land Down Under!
The marketing behind the phenomenon is worth a study. We have senior citizens playing this shit, for Chrissake.
With much of the world tuned in to Social Media and mobile apps, it was a matter of time before a movie was made about an app. Nerve is one such movie. More precisely, Nerve is one such novel, written by Jeanne Ryan, and the movie is based off it.
This movie has been compared to Unfriended for its focus on Social Media. However, unlike Unfriended, it's less about cyberbullying and more about how unpleasant people can be when
they're behind a veil of online anonymity.
Warning - mild spoilers ahead
There are a few decent twists in the tale, and let's leave it at that. Nothing particularly clever, but significant enough that revealing them here would ruin the plot.
The Premise
Nerve is a mobile game that promises to be "Truth or Dare, without the Truth". The game is centered around dares. Users of the app choose to be either Watchers or Players. Watchers pay a fee to well, watch the Players carry out dares within a time limit. Players accept online monetary transactions to carry out dares, and have to be filmed doing it. They lose if they give up, or fail to carry out the dare within the stipulated time limit. On a more sinister note, if any user attempts to contact the authorities and warn them about this app, they are punished.
Nerve cannot be shut down because there is no single server - every Watcher is a server unto themselves, and thus as long as even one Watcher is logged on, the game is online.
"Truth or Dare, without the Truth" turns out to be misleading - while the app does deal primarily in the "Dare" part, there's plenty of "Truth" involved as well. The app gathers personal information of the Players such as addresses, bank accounts and relatives, and uses it against them.
The frenetic tale revolves around a student named Vee who becomes a Player for the first time, and another Player known as "Ian", as they embark on an increasingly dangerous and outrageous series of dares orchestrated by the Watchers.
The Characters
Emma Roberts as Venus "Vee" Delmonico. Much has been said about Emma Roberts being too hot to play shy nerd Vee. Don't know about that, I think she did a pretty decent job, though her thick eyebrows were kind of distracting. The sight of her cavorting around in her underwear with "Ian" wasn't exactly repulsive, but "too hot" wasn't really the first thing that came to mind.
Dave Franco as "Ian", looking suave and oozing the kind of charm his older brother James is known for, he was good in the role. The awkward goofiness he exhibited in Now You See Me and Now You See Me 2, and even more pronounced in Unfinished Business, was absent. In one of the scenes where he and Vee clowned around on a carousel, this was quaintly reminiscent of his turn as Jack Wilder in Now You See Me.
Emily Meade as Sydney, Vee's trampy best bud who seems to really enjoy strutting around without her underwear. She played the role magnificently. The facial expressions, ranging from concern to jealousy to fear, to outright bitchiness - she nailed them all.
Miles Heizer as Tommy, Vee's friend, web tech geek and a cautious presence in her newfound recklessness, delivering rather trite truisms such as "we're using only ten percent of the web". Has a not-so-subtle crush on her, and his tech skills feature prominently throughout the movie. Machine Gun Kelly as Ty, the tall scary-looking white dude who comes off as a total psycho Player. Really hammed it up and stole the show in the scenes he was in.
Samira Wiley as Azhar. Gorgeous, and cool as hell. One of the adult tech geeks in Miles's crew who eventually save the day. Maybe it's just me, but her vibe wasn't very techie.
Juliette Lewis as Nancy, Vee's mom - possibly the cast's most billable actress. Haven't seen her since Strange Days and Enough, and my, how she's aged. Still a dependable actress though, as she pulls off businesslike bedside manner as a nurse and frantic concern as Vee's mother with aplomb. Didn't have much to do otherwise.
Kimiko Glenn as Liv. There was something endearingly earnest about this Asian as she played one of Vee's friends in the group.
The Mood
Started out with a dull and mundane environment. As the action heated up and the thrills started, most of the story took place at night amid the bright lights of the city. It was dark and gritty in places, but not overly done.
What I liked
The atmosphere was refreshingly "normal" when required. Nothing glitzed up, no teen supermodels posing as students in the school. They even had chubby cheerleaders. Imagine that!
Even the techie scenes were tastefully done. No over-the-top special effects other than clever camera angles that make the viewer feel like they are the computer interacting with Vee, or the various mobile screens interacting with the Watchers.
Vee delivered an awesome monologue as she and Sydney had a confrontation. The intensity of that scene has to be seen to be believed.
What I didn't
Nerve got a little preachy at times, with Miles and Vee delivering lines (monologues in the latter's case) that were less awesome and more superfluous. I mean, we geddit already. Online anonymous trolls are evil. Don't give out your personal information on the web. Yadda yadda.
Can we get back to the movie please?
Conclusion
Nerve is a cautionary tale against putting too mch personal information online. Or, at least, it tries to be. As a thriller, thrill it certainly does. It's a charming low-budget production, and lots of fun.
As I write this, Singapore is still celebrating the Olympic spirit. In particular, our first Olympic Gold medal ever. Won by a young sprightly lad by the name of Joseph Isaac Schooling, who pipped Michael Phelps to the coveted title in the 100m Butterfly.
Do I have cause to feel proud? Rationally, no. I didn't pitch a cent towards Schooling's endeavor, nor have I been rooting for him since day one. Hell, his name barely registered on my radar (and neither did the Rio Games, for that matter) until he won the race and my Facebook feed positively erupted with the news.
But do I feel proud, nonetheless? Strangely, even though I probably have little right to, yes. This is a momentous occasion for Singapore, the island I was born on, lived on, and will in most likelihood, die on.
Joseph Schooling, like a boss.
Congratulations, Schooling. Well done, young man.
I'll mark this occasion by dedicating the planned web tutorial for this month, to Singapore's first Olympic Gold victory. It's about rollover buttons, and it's been stewing for a little while.
Ahem, so...
One of the most common things on the net is rollover buttons. They've been in effect ever since the first JavaScript snippet. Today, we're going to examine some of the ways they are implemented.
Hold on - some of the ways?
Yes. You didn't think for a moment there was only one way, did you? Hell, no! As technology evolves, so do once-accepted ways of doing things.
For the rest of this tutorial, I will be using some very ubiquitous buttons as examples, ie. Facebook, Twitter and LinkedIn. In particular, we'll use them to link to Joseph Schooling's accounts.
These images should be saved in the "img" directory of your root folder.
rollover_fb0.jpg
rollover_tw0.jpg
rollover_li0.jpg
So, what does a rollover button do?
You move your mouse cursor over the button, and the button changes, showing you that it can be clicked.
Like this - see?
Without further ado, we're going to jump right in!
Using JavaScript and Img tags
For this, we need three more images. These are the images that will be changed to. In animation terminology, both original and new images are known as "sprites". (That's just FYI in case you have a presentation or something and need to sound like you know your shit. Don't worry about it.)
Again, these images should be saved in the "img" directory of your root folder.
rollover_fb1.jpg
rollover_tw1.jpg
rollover_li1.jpg
So we have the original images in HTML, encased in anchor tags. The CSS styling is meant to disable the fugly border thicknesses that sometimes show up on older browsers. (Yes IE, I'm looking at you.)
When we invoke the mouseover and mouseout events in the HTML tags, the URLs of the images are changed accordingly. Not my favorite method. Don't get me wrong, it works. But this is Jurassic-era HTML. There are better ways of doing things now.
Using JavaScript and CSS
Here are the buttons, and some CSS. Note that the buttons aren't images. They're actual buttons. The CSS basically styles these buttons to use the original images as background images.
Not my favorite method either. I'll explain why in a bit.
What's wrong with the above two methods?
Firstly, they use JavaScript, which is always a bad idea if you're paranoid about users turning JavaScript off.
Secondly, that's a shitload of HTML code to write for a few crummy rollover buttons. I prefer to reserve HTML for other things.
Thirdly, they involve loading new images. The first time any of these images are loaded, there's always a certain amount of delay. Subsequent times, the images have been cached, so no more delays occur. You can get around this problem by pre-loading images.
Or you could do this!
Using mostly CSS
This method does not use JavaScript, and does not use separate images for the sprites. These are the images we'll be using.
Did I mention that these images should be saved in the "img" directory of your root folder?
rollover_fb2.jpg
rollover_tw2.jpg
rollover_li2.jpg
Note that these images are joined. Here's the HTML and CSS.
Again, these are actual buttons. Nothing much has changed from the previous method so far, except that a new CSS property has been added - background-position. This may seem utterly unnecessary now given that this is the default setting anyway. But... you guessed it, we're going to change this!
See what we did there? Each element styled with the CSS class rollover has a new specification - the hover. When you move your cursor over the element, the background-position property of the element changes, giving you the new image, or at least appearing to do so. In reality, it's the same image. It's just that the background position has been offset! When you move your cursor off the element, the original settings kick in.
What's so good about this?
Well, for each button, only one image is used. This saves you the trouble of making different CSS classes for them. Right now you have only three buttons. What if you have fifty? Extensibility FTW!
Also, when the page is loaded, the images are loaded too. Different images don't have to be loaded upon your cursor interacting with the buttons.
Since you're not using JavaScript, you don't have to worry about someone disabling it.
Last, but not least, look at the simplicity of the HTML. All the work is being done by the CSS.
Hubris is probably the most misunderstood of all the programmer virtues.
But you're in luck - I'm Teochew, and if anyone understands arrogance,
it's us.
The Virtue of the Great Programmer - Hubris
Developer ego is more commonplace than you'd expect. Any developer with some experience under his belt is going to be rather opinionated about how things should be done. Programming is about bending the will of a machine to our own, and making it churn out the results we want. It is about creating usable objects out of virtually nothing. It is about dealing in languages many people are too intimidated by to even attempt. And getting paid for it. Why wouldn't we be arrogant? Consider the quote below from Robert C Martin, in his book The Clean Coder.
"Programming is an act of creation. When we write code we are creating something out of nothing. We are boldly imposing order upon chaos. We are confidently commanding, in precise detail, the behaviors of a machine that could otherwise do incalculable damage. And so, programming is an act of supreme arrogance."
Robert C Martin seems to be a bit of an extremist in his views, and more than a little verbose. But in this case, he hit home for me right there.
But... but, but.
Why be modest when
you're that good?
In order for hubris to be a virtue, it has to work for you. It has to help you in your development. It has to drive you.
It has to spur you on to create products that people can only praise. Any code attributed to your name has to achieve great things. That arrogance manifests itself as pride in your work.
It has to inspire you to go boldly where no one has gone before. "A hundred programmers have failed? Well, I'll be the hundred and first." "Better men have tried and failed? Bitch, there ain't no better man." In fact, I believe that it is this same audacity to try something different, something unthinkable, that separates great programmers like Bill Gates (daring to succeed despite dropping out of university? The sheer gall.) and Linus "I'm always right" Torvalds from the rest.
How not to be Arrogant
Some forms of arrogance manifest as a belief that one has already learned all that is worth learning, and there is no need to keep exploring. That's arrogant, sure... it's also foolish. Dangerously so. Technology is constantly evolving. As I type this, a few million hackers around the world have figured out newer and more insidious ways to breach web security. New frameworks are threatening to render the ones you use obsolete. New features in your favorite programming language are causing older features to be deprecated. Going down this path is a sure route to ruin. There's a place for arrogance. Not so for complacency.
Refusal to listen to feedback is another dangerous manifestation of arrogance. Sure, not all feedback is created equal. If, for example, you haven't written a line of code your entire misbegotten life and have the audacity to comment on my professionalism, be prepared to be very firmly put in your place. On the other hand, working too close to the product can lead to blind spots, and sometimes - just sometimes - fresh perspectives are helpful even if they are from laypeople. There's also a tendency for a developer's ego to lead to defensiveness - such as refusing to concede an argument or admit that someone else knows more than you do. That is insecurity. If you're confident enough in your own abilities and value, you don't ever need to travel that rocky road.
Then there's the Not Invented Here syndrome. The pragmatic developer understands that there is no shame in collaboration or leveraging off someone else's work. "Real devs code from scratch"? What kind of egoistical rubbish is that? No matter what you do, you're leveraging off the work of Ada Lovelace, mother of the modern computer. Want to be a "real dev"? Go re-invent algorithms!
So...
Are you an adequate, good or great programmer?
This is, as you may have suspected, just my opinion. There are many ways to interpret the words of Larry Wall. In fact, I have no real business telling anyone how to achieve greatness in programming - after all, I'm just about adequate myself, on some days anyway. Like many people, I have my moments. Some days I feel like I'm Neo from the Matrix, and some days I wonder why I'm even employed.
But in general, yes, most developers fall around the "adequate - good" axis, with only the top echelons making it into the "great" category. Still, "adequate" is a good goal, and "good" is a respectable one.
Be virtuous!
Too impatient to sign off properly, too lazy to care.
T___T
Mastered laziness yet? Or at least gotten the correct attitude down? If not, keep at it until you do.
If you have gotten yourself into that correct mindset, read on, you lazy bastards.
The Virtue of the Good Programmer - Impatience
Why is impatience "good", while laziness is merely "adequate"? Because automating tasks is only the first step. Having your solution work is the minimum acceptable outcome. That makes you adequate. In order to ascend to the next level, in order to be considered "good", your code should not just work.
Work harder, slave!
Impatience drives the programmer to further improve his work. The code does not merely run; it has to fly. It cannot only solve that problem; it must solve that problem in spectacular fashion. The impatient programmer always wants more out of his code. Impatience is what you have when you work tirelessly for several nights in a row just to shave off a few milliseconds from the execution time of your code. It's personified by the developer who relentlessly idiot-proofs his system so that all user input is validated and in some cases, even anticipated.
There's a great deal of irony in the fact that in order to exercise impatience where his work is concerned, the programmer has to very patiently improve on his solution.
How not to be Impatient
Testing the solution is often a very tedious process. In order to be done properly, multiple scenarios and edge cases have to be drawn up. Every moving part in the code is a new potential point of failure. Is it any wonder that some people make their living on testing alone? Because not every programmer can do it. Of course, there are those who are so impatient that testing is a waste of time for them. Take note; that is the wrong way to be impatient. In fact, that isn't even being impatient - just stupid.
The wrong brand of impatience can also cause developers to cut corners during the development process - not in terms of quality, but in terms of communication. There have been times during my career where things were moving too slowly for my liking - I badgered colleagues for specifications, took things into my own hands and generally jumped the gun. This resulted in systems that sometimes did not function as expected, and sometimes deviated wildly from user expectation. My mistake was not taking the extra time to check with the users that I had understood their intentions correctly. This resulted in work they couldn't use, and a waste of company time. Sure, I leveled up in the process. Sure, I had fun doing it. But the company wasn't paying me to level up, or entertain myself on their time. It was paying me to get work done. And on that count, I failed. An employer once described me as a race car achieving great speed, but in the wrong direction. That wasn't a compliment.
It probably should also go without saying that the wrong brand of impatience can hurt a programmer who gives up too easily. Things rarely make sense right away, and if a problem isn't yielding a solution right away, approach from another angle. Time spent on understanding something is rarely time wasted.
Larry Wall, creator of Perl, is also the author of Programming Perl. In it, he said something that has inspired me profoundly as a web developer.
"We will encourage you to develop the three great virtues of a programmer: laziness, impatience, and hubris."
Now, there have been numerous interpretations of these virtues. But we're not going to bother with those; I'll be providing my own take on this. (What? Last time I checked, this is my blog.)
So the burning question - why are these virtues? In most other contexts, they would be considered sins. However, not just any lazy, impatient and arrogant SOB can be considered a great programmer. In fact, it takes a special kind of lazy, impatient and arrogant SOB to be a programmer at all. And I humbly submit that these three virtues are stated in that order for a good reason - they separate the adequate from the good, and the good from the great.
The Virtue of the Adequate Programmer - Laziness
If you remember nothing else about programming, remember this: minimum input, maximum output. All programming is about solving problems and automating tasks. Whatever fancy new gimmicks and technological advances the next twenty years throws at you, philosophically, programming does not change. This has been, is, and will always be; the one truth about programming. Whatever languages you use, whatever platform you swear undying loyalty to, it all goes back to this in the end - minimum input, maximum output.
The ultimate aim of any program is to make life easier. Because the awful alternative is more work. Not just more work - more boring and repetitive work which would be better done by machines.
Make the slaves do the work.
Programmers are always looking for the shortest, most direct route from Point A to Point B. They are always looking for a way to reduce that repetitive, monotonous task into a series of processes and outsourcing them for a dumb machine to execute. In other words, programmers are the taskmasters, and computers are the slaves. If that's not lazy, I don't know what is. The question is invariably "can this be automated?" followed by "how much can this be automated?".
Human beings get distracted. They get bored. They get frustrated. Machines don't. And therefore machines are the perfect candidates as slaves to carry out all that mindless work and in the process make life easier for the programmer. Notice how I said "make life easier" twice?
This is virtue numero uno for a good reason - not all programmers have the other two virtues (and therefore not all programmers are good, or great). But all programmers (and their cousins, the web developers) have to embrace this virtue at their core.
How not to be Lazy
Laziness comes in various forms. Not every form of laziness is admirable. If that laziness leads to more work down the road, it's counter-productive.
Copy-pasting code blindly without checking for relevance and room for improvement - that certainly qualifies. It's something I actively avoid.
If the code is going
to be reused in the foreseeable future, invest a bit of time abstracting
it into methods and subroutines so that it's easy to reuse and maintain. The
Don't Repeat Yourself (DRY) principle is applicable here.
Sloppy code, lax security measures, incomplete test cases are all good examples, cases where the programmer couldn't be arsed to close that last loophole. Guilty as charged. Sometimes reality demands that I have to cut corners. It's not an excuse, but sometimes people have to choose between being a bad programmer who delivers, and being a great programmer who's out of a job.
In an age where many great programmers have paved the way for us by writing systems that automate even programming tasks, it's very easy to be lazy in the wrong way. Plenty of developers I know don't bother with the basics because that newfangled framework takes care of it for them. I'm guilty of this too. For instance, garbage collection and memory management is not exactly something I like to concern myself with - though in my defence, as a web developer, my priorities lie elsewhere.
Out of all the job interviews I've ever been subjected to, one interviewing method stands out - the ratings method. Or, to be more specific, the rate-yourself method. That's where the interviewer names several skills - PHP, MySQL, project management, lightbulb screwing, yadda yadda - and the interviewee rates himself from 1 to 10, 10 being absolute guru, and 1 being clueless dolt.
My rating!
This is significant because I find this method of interviewing trite and meaningless, and I've often associated those words with the interviewing methods of non-technical people, such as HR. Unfortunately, this method of interviewing has been conducted by IT professionals. People who should know better.
Here's why I consider this method trite and meaningless.
You can't prove I'm lying!
At least during the interview, anyway. Let's say the interviewee rates himself an 9 out of 10 in C#. He could be lying through his teeth, but how do you prove that? Sure, you could ask him some pointed questions about C# to determine if he's as good as he says, but if you're going to do that anyway, why bother with the ratings? If those ratings are going to play any part in the hiring process, I'm not sure I want to be hired based on that.
Ratings are subjective
What's my 10, and what's your 10? When I asked that question, some interviewers have told me to just rate myself from my point of view. And that's exactly why it's meaningless. The interviewee doesn't even have to lie - he just has to be supremely confident (rightly or wrongly) that he's that good. I mean, some people think their database skills are hot shit just because they know how to join tables. They're not lying when they give themselves an 8 out of 10. They simply suck so much that they don't even know they suck. Classic Dunning-Kruger effect right there.
The goalposts keep moving
If you've spent any time in the web industry at all, you'll understand that things seldom stay still. Every facet of web development is changing, and changing fast. What you know today could be obsolete next week. My 10 now could be a very different 10 in a month's time. Let's say I think someone needs to be able to format text and change colors in CSS in order to get a 10 in CSS. (I don't actually suck that much. It's just an example.) After learning more about CSS and levelling up, I might discover CSS animations and realize that the bar is higher than I originally thought. In fact, the more a web developer learns, the lower he is going to (honestly) rate himself.
Final Thoughts
Is this ratings method going away anytime soon? Your guess is as good as mine. It certainly is a time-saver, if nothing else. Why bother having a long talk with the interviewee and assessing his strengths and weaknesses when you can just reduce it all to a number-guessing game?
Would you say this blogpost deserves an 8/10? 8.5, maybe?
T___T
