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

The Myth of Tech Meritocracy

The Android vs iOS debate has been raging on for years, with no end in sight. In each camp, you have devout followers that swear (sometimes very loudly) by their chosen platform.

I have a friend who's a bit of an Apple fanboy, and he absolutely despises Android technology. And I remember one day he was telling me how Android ought to die because its tech is shit.

Die, Android, die!

My opinion was that he wasn't being entirely rational about this - in fact, I was quite positive that he was looking at this from a very emotional point of view. Because things don't work that way in technology. Don't get me wrong - this isn't a debate about which technology is better. Even if, for arguments' sake, I agreed with him that Android technology is shit; Android is not going away. And for his own sake, my buddy should pray that it remains so.

Android, at this point in time, enjoys the largest market share worldwide next to Apple's iOS. What if my friend's wish comes true and Android disappears from the market forever? The void left by Android would not be readily filled, and Apple would reign supreme.

King of the hill

Sounds like a fanboy's wet dream, eh? Just wait - it goes downhill from here.

I think we can all agree that Apple isn't some benevolent mobile tech Santa giving us awesome products for the sheer joy of it. No, like all credible tech companies, Apple is a business, and is motivated by desire for consumer dollars. And its great innovations in recent years was a direct consequence of having to constantly up its game in the face of stiff competition from Android. What happens when that stiff competition is no longer present?

This is what I think happens...

Apple halves its workforce because the amount of talent on their payroll is no longer required.

Apple products slowly become shit, because Apple are now just about the only game in town and if they feel like feeding you shit, you'll eat it and like it.

Apple begins its inevitable decline.

Just a little
competition.

What I'm trying to say is - competition keeps businesses honest. But again, this isn't about Apple or Android - it's about the myth of tech meritocracy.

Let's talk about meritocracy, shall we?

The professional world isn't a perfect meritocracy. Higher management positions could be filled by people who don't deserve to have a job, much less a high-paying one. Less capable and driven folks may get that promotion simply by kissing up to the right people. Pretty girls may get ahead simply because the fellow in charge is a hum sup lou. Less qualified staff could remain employed simply by being better at keeping their jobs rather than actually doing their jobs. The lower echelons of the workforce could be teeming with a serious case of Crouching Tiger, Hidden Dragon.

There's nothing intrinsically wrong with any of that. This is simply how the world works.

Likewise, technology isn't a perfect meritocracy. Tech doesn't die simply because it's inferior. Tech rises to prominence for a variety of reasons, not just quality. And once that tech has entrenched itself as part of the ecosystem, removing it poses several problems, some of which may adversely affect that rival tech you're such a huge sucker for.

More examples

Remember classic ASP, written in VBScript? It was supposed to have been replaced by ASP.NET back in 2003. Where is it now? It's still residing on servers powering legacy systems - huge legacy systems - all over the world. It's not exactly thriving, but until Microsoft's IIS stops supporting classic ASP, no company in its right mind is going to spend money to rewrite a working system to leverage off new and (relatively) untested technology. So classic ASP stays.

Or, hey, look at JavaScript. For many years since Netscape shared it with the world, JavaScript was the only game in town, at least where client-side scripting was concerned. VBScript was client-side scripting too, but it  belonged to Microsoft and ran only on IE. By most yardsticks, JavaScript wasn't a great language. It had its warts, and I'm being generous when I say that. But decades on, it has become so pervasive that its use has expanded to frameworks, libraries and even server-side scripting. Uprooting JavaScript now would be a Herculean task.

For that matter, why are Pascal, FORTRAN and COBOL still around?

In technology, new things catch on fast. But older tech takes a while to go away if it has already entrenched itself - by being introduced at the right time, or filling some niche uncontested.

See how long HTML5 took to become a browser standard? Sure, it's starting to come into its own now, but XHTML is still alive. Because while HTML5 is superior and fixes many of the problems that came with HTML4.0 and XHTML, its introduction cannot undo decades of XHTML-based content overnight.

Such is the tech ecosystem

Tech ceases to grow when people stop using it to make new stuff. But it only truly dies when... well, almost never.

Besides, why should a piece of tech die just because some people (or several) don't like it and think it's rubbish? Technology is a vibrant and multifaceted world because of the variety, not in spite of it.

That's all for now. (ad)iOS!
T___T

Holy Radical Randomizers, Batman!

Hey, good morning.

Just a little technical snippet which, as usual, may or may not be useful. However, I believe most seasoned programmers already have something like that in their arsenal.

In previous web tutorials such as The Ngerng Effect and The Random Quote Google Gadget, I used a line of code to generate random numbers. It worked. But it was hellishly difficult to read. And that kind of gets in the way if you're trying to explain a concept.

What we need to do here is make a function for it. I'm going to demonstrate this using JavaScript first. The line for creating a random number is, according to W3Schools:

Math.floor((Math.random() * x)+y)

x is the maximum number you wish to generate, and y is the minimum.

So if we make a function like so...

function generaterandomno(x,y)
{
    return Math.floor((Math.random() * y)+x);
}

Now I can just call a random number without all the technical mumbo-jumbo. Here, I use JavaScript  to create a varianble randomno and assign a random value between 1 to 100 using the generaterandomno() function.

var randomno=generaterandomno(1,100);

However, this formula is flawed. It's perfect if the value of x is 1 or 0, meaning, you only want to generate a random number with a minimum value of 1 or 0, like a random number from 0 to 100, or 1 to 100. Anything greater than 1, and the formula falls flat.

Thus, if you want a random number from, say, 10 to 100, what you really should be doing is generating a number from 0 to 90, and then adding 10 to the result.

Which also means the formula is more like this.

Math.floor((Math.random() * (x-y+1))+y)

The additional +1 is supposed to compensate for the Math.floor() function, which rounds down. Math.random() gets a number between 0 and 1, which is a floating point. And Math.floor() turns the result into an integer.

Note that this probably doesn't handle cases where the value of x and/or y is a negative number. And until I have a reason to find out, we're not going there.

In other languages...

The principle is similar, though the quirks vary from language to language. Generally, the older langugaes seem to have the problem outlined above while newer languages simply get that out of the way.

In, PHP, this is how I'd do it. That's because PHP already kindly provides just such a function. Apparently someone in the open-source community decided to simplify the process.

$randomno=rand(1,100);

In C/C++

int generaterandomno(int x, int y)
{
    srand (time(NULL));
    return (rand() % (y-x+1)) + x;
}

int randomno=generaterandomno(1,100);

In Java (sans import utility and class notations)

public int generaterandomno(int x, int y)
{
     Random rnd= new Random();
     return rand.nextInt(y - x + 1) + x;
}

int randomno=generaterandomno(1,100);

In C# (sans import utility and class notations)

public int generaterandomno(int x, int y)
{
    Random rnd = new Random();
    return rnd.Next(x,y);
}

int randomno=generaterandomno(1,100);

In ASP

function generaterandomno(x,y)
    Randomize
    generaterandomno = Int((rnd*(y-x+1)))+x
end function

Dim randomno=generaterandomno(1,10)

In QBasic

FUNCTION generaterandomno(x AS SINGLE,yAS SINGLE)
    RANDOMIZE TIMER
    generaterandomno = INT(RND * (y-x+1)) + x
END FUNCTION

DIM randomnogeneraterandomno(1,10)

There it is, a list of randomizer functions in some of the languages I remember. A useful list if I ever need to generate random effects.

y still confused? Didn't I x-plain it well enough? (heh heh)
T___T

Your AJAX Starter Kit (Part 1/2)

AJAX stands for Asynchronous JavaScript And XML, and is a technology that marries the front-end capabilities of JavaScript with the back-end code of other scripting languages such as PHP, C# and ASP.

For more on AJAX. follow this link. (https://en.wikipedia.org/wiki/Ajax_%28programming%29)

There's plenty you can do with AJAX. With it, you can make your web application perform like a desktop application, eliminating (or at least suppressing) many of the limitations of traditional web applications.

What I'd like to do here today is assemble an AJAX Starter Kit - basic components of AJAX that a web developer can use to make his very first AJAX-driven application. What we need is the following:

- A HTML placeholder for content.
- A back-end script for producing said content. (Example will be in PHP)
- JavaScript to combine the HTML with the back-end script.

Bear in mind that everything here is a bare-bones example. Your AJAX code would ideally be more complicated than this, otherwise you wouldn't really need AJAX, would you? These are just the building blocks. They're meant for you to expand on. There is actually a lot more to AJAX than what I'm about to show you. But as a start, well, you could do worse.

Here's the HTML.

ajax_test.html

<!DOCTYPE html>
<html>
    <head>
        <title>AJAX Starter Kit</title>
        <script>
            function ajax_frontend()
            {

            }
        </script>
    </head>
    <body onload="ajax_frontend();">
        <div id="ajax_placeholder" style="border:1px solid #000000;width:200px;height:100px;">

        </div>
    </body>
</html>

Here, I've set the function ajax_frontend() to fire off when the body loads. Feel free to change the name of the function, or set it to fire off on some other event such as a button click.

The div with an id of ajax_placeholder is exactly what it says - this div is a placeholder for your ajax-driven content. Again, feel free to change the id of this div.

This is what the front-end looks like when run on your browser.

And here's the back-end.

ajax_backend.php

<?php

if (isset($_POST["user"]))
{
    echo  $_POST["user"] . " says ";
}

echo "Hello, world!";
?>

This may seem overly simplistic. "Hello, world"? Really? But bear in mind that this is just an example. You could make your back-end script access a database for records or perform some calculations. The end result is, the text output of your code should appear in the ajax_placeholder div.

This is what your output should look like when you run it from the server.

Because there's nothing posted to the script, it says only "Hello World". Later, your AJAX code will send a value for your back-end script to use.

Easy so far?

Of course, this is just a front-end file and a back-end file. The whole point is to link them together. And that's the part that bears close examination.

Next

The AJAX call.

How I first learned PHP (Part 1/2)

The Year of the Goat approaches.

This is a special time for me. Not so much because it's the holiday season, but because it's a reminder of grimmer days where I would be dreading the coming of the Lunar New Year.

In fact, it had just turned 2010 when I found myself looking for a new job. The company I was working in had gone bust. I'd just been working the past ten months without pay, trying to finish the company product, an ambitiously-scoped MIS developed in classic ASP.

But before I continue...

The Short Version

I learned PHP from a book.

The Long Version

For the backstory and all, read on.

Being unemployed

It was no fun. While I hadn't been paid the past ten months, I had still been working, hoping to turn a corner. Now I was without a job and worse, without work. Other than send out resume after resume, I hadn't much to do to distract me from the growing anxiety. Just a month into it, and I was feeling more dead than alive. My temper was growing short. I was getting antsy. My parents and I were raising our voices at each other all the time, and at some point one of them remarked that I was really difficult to live with when I had nothing to do.

Then I landed a job.

It was in a fairly big company, and they were in need of someone with web development experience. The catch was, this was a technical support job. Yes, this had deja vu written all over it. But I was desperate enough to take it.

After a week, they told me to go.

I guess I hadn't done a good enough job of hiding my distaste for the desktop support portion of the job. I'd never been fired before. Boy, did that suck. But it did increase my determination to never again take up a desktop support job.

The problem was, I didn't want my folks to know. I was too goddamn old to have my parents worry about me. And I just couldn't handle another day of their well-meaning but frustrating attempts to help. My mother had a lot of useful advice. That is, advice that would have been useful back in the 90s when she was still part of the workforce. And as for my father, he kept trying to hook me up with some contact or other that he claimed would give him face and employ me. Yes Dad. I know you're a big shot businessman and your reach is wide. But your son isn't so fucking useless that he needs you to secure a job for him!

Compounding the problem was that the main item in my skillset, classic ASP, was on its last legs. People were asking for ASP.NET now. The other popular keyword that kept coming up at that time, was "PHP".

Well, I needed to keep up the appearances and make it look like I still had a job. And I needed to look into PHP. So what did I do? I put on my shirt and tie every day, wore my good shoes, and headed out in the morning as if there was still an office to report to. And hit the library, where I would take refuge till 5pm.

My first PHP textbook

The First Look at PHP

I picked up a few books, and spent some quality time looking through them. And my mind was blown. I had a foundation in C++, honed by proxy with frequent practice in JavaScript. The syntax was similar to these languages. Hell, it was almost identical. If I practiced the syntax diligently, I would have no trouble replicating what I already knew how to do in classic ASP. As I read on, I felt a sense of growing excitement. I could totally do this shit.

The next part, after all that reading, was doing. For this, I called in a favor. An ex-classmate ran his dad's company, Pan Greatways Technology. He kindly allowed me to occupy a small corner of his office daily and use his power supply and internet connection.

Where my comeback began.

There, I painstakingly set up my first WAMP stack, installing and tinkering with Apache, MySQL and PHP. My coding was done in Notepad. For my server, I was running a beat-up IBM Thinkpad.

It was madness. It was frustrating. I fucking loved it. My fate was back in my grubby little hands, and there is no feeling more liberating, and consequently intoxicating.

A week later, an opportunity arrived.

Next

How I landed my first PHP job.

How I Became a Web Developer (Part 1/2)

I just turned thirty-seven two weeks ago. It's been almost fifteen years since I embarked on this journey. Warning: long story ahead, make yourself comfortable!

Some Background

It was 2001 and I had just graduated with a Bachelor's Degree in Information Technology. The possibilities were endless. The problem was, in the face of a slumbering economy and lack of job opportunities, I soon wound up taking odd jobs. Basic computer literacy training. Small websites.

And in the course of building one of those small projects that had been outsourced to me from a vendor, I visited his shophouse office in Little India. He took me around and introduced me to his team. It was a tiny dingy room with precious little furniture. Four PCs in the room, and a big smoldering ash-tray in the middle. The air reeked of sweat and old cigarette smoke.

It was heaven to my young eyes. These Indians, were, to me, the epitome of cool. This was what I was going to do for the rest of my life. I was hooked.

I didn't become a full-fledged web developer right away. It took years of screwing up to get to this point. In retrospect, perhaps my dreams could have been a little bit bigger.

But, for better or worse, this is what I am. This is what I do.

And after that day...

The path towards becoming a web developer turned out to be slightly more complicated.

Somehow I landed a job as desktop support in a legal firm. My first full-time job ever. It wasn't where I envisioned myself being, but it would do for a start. I would leech whatever experience I could from this, and move on in maybe three years.

At least, that was the plan.

It started out interesting. I was brimming with youthful enthusiasm after going from temp job to temp job. Because some in-house development was needed, I picked up a book on my desk, and learned ASP from there. It wasn't too difficult for someone with a Visual Basic background.

I learned all my ASP from this!

The first year was filled with wonder. Friendships were forged, some of which are still ongoing today. I honed my web scripting skills, which, as it turned out, would prove invaluable down the road. In fact, as much as I eventually grew to hate the job, there's no denying that the experience hardened me. Whenever someone complains to me about user stupidity, I tend to go "You think that's stupid? I've seen worse. I spent six years in desktop support".

By the third year, my enthusiasm waned. There was only so much development I could do, and the other aspects of my job were less than thrilling. Networking was one of my least favorite subjects in school, and having hands-on experience with it didn't remove my distaste for it. And as for desktop support...

What can I say about desktop support that won't sound overly uncharitable? It involved moving PCs from location to location, setting up email accounts, tending to all the little problems that users seemed to encounter all the time. It wasn't exciting to begin with, but by the third year it had become positively tedious. There's only so much stupidity a man can take before he goes nuts.

Someone once described desktop support to me as "the IT equivalent of leading a man to the urinal and holding his dick while he takes a piss". He was being kind. It's way worse. Lack of computer savvy I could forgive. One gets those users all the time - without them, desktop support would not exist. And then there was the other kind of user - entitled, obnoxious and utterly inept. Special breeds of stupid who thought desktop support automatically extended to all things electronic such as microwave ovens, paper shredders and phones. Special strains of asshole who thought nothing of interrupting a man at his toilet break just because there was a printing problem. I was being ordered around by people who, in soccer parlance, weren't good enough to carry my boots.

I was a university graduate, dammit. I deserved better. Or so I thought.

The truth is, a man deserves exactly what he will accept. Each time my pay got raised or I received my annual bonus, I looked the other way and delayed moving on. And here's the thing about the annual bonus in that company - it was divided in two and each half was doled out at intervals of six months.  People who felt that the bonus was their own money and were entitled to it, would delay their departure by another half-year to avoid forfeiting it. It was genius. A brilliant maneuver to keep unambitious, unmotivated 9-to-5ers slaving away. Do I blame the company? In retrospect, no. They dangled that carrot; I was the fool who took it.

Next...

How I got out.