Frameworks in Perspective

Frameworks are increasingly becoming the in-thing. From scripting languages (CodeIgniter and Symfony for PHP, Django and Pyramid for Python, etc) to front-end (AngularJS) and now even CSS (Bootstrap), frameworks are here to stay and are fast becoming mainstream, if not already firmly a part of it. Increasingly, firms are now looking for developers who not only know their way around scripting languages, but also frameworks.

What's not to love about frameworks? They take care of the nitty-gritty stuff, speed up development considerably and have great support worldwide. Knowing a framework or two adds glamor to your resume.

But here's the rub: I don't love frameworks.

Sure, I acknowledge that they are getting increasingly popular, for legitimate reasons. I acknowledge their place in the industry. I may even have used a few myself. But, call me old-fashioned, I tend to like getting things done without frameworks. Don't get me wrong, frameworks are great for business. With reduced development times and nifty things like code reuse, projects get completed faster. Deadlines get met and vendors get paid (hopefully!) sooner.

Yes, I'm going to say it again - frameworks are great for business. But I'm not a businessman. I'm a geek.

Here are some reasons why I would prefer to do without frameworks. I call them the three "Overs".

Overuse

This is web development, and there are no blanket solutions. The solution you choose should depend on the context. But some developers forget that. They think they've found this great one-size-fits-all framework and insist on using it for everything.

"I suppose it is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail." - Abraham Maslov

I once worked with a developer who used CodeIgniter for every damn thing - including Contact Us forms! And - get this - a guy who wanted to go ASP.NET MVC for a static website. That's another "Over" right there - overkill.

And seriously, if what you need is a no-frills web application that doesn't have to look pretty or be used on mobile, why would you even bother trying to use Twitter Bootstrap for it? This is insane!

It's like using a hammer to break an egg.

Uh-oh

jQuery, for example, boasts that it will drastically cut the number of lines of JavaScript code you write. Let's assume that I load the jQuery file and now instead of 20 lines per function, I write only 5 lines. If I have 50 functions in there, I would have saved (15x50) 1250 lines of code. But what if I only had 5 functions? I would still have to load the entire jQuery library. Doesn't it, then, stand to reason that I'm only getting enough bang for my buck if I use jQuery for far, far bigger things?

Now replace "jQuery" with the name of any framework out there and you'll why I facepalm at this silliness.

Overhype

As mentioned earlier, frameworks benefit the businesses by speeding up the development process. Consequently, business owners set great store by developers who can develop using frameworks. This can lead to developers thinking they're hot shit simply because they can code using a framework.

And that is sometimes implausibly stretching the truth.

You see, it is entirely possible to learn the framework without learning the foundation behind it. Knowing one does not mean knowing the other. You can learn Django without learning Python the same way one can learn jQuery without learning JavaScript. And some developers do precisely that. They start using the framework as a crutch for all the gaps in their knowledge, and that's where the problem begins.

Don't know about sanitizing input? No worries, the framework takes care of that. Don't know how to prevent SQL Injection? Framework takes care of that too. Don't know about responsive design? No problem, we use a framework!

Excuse me for a minute there, I feel the sudden urge to puke.

Gag. *hurk*

Knowing how to code in a framework is a good thing. But only if your foundation is rock solid. Otherwise, you are merely a tool user masquerading as a developer.

The framework and its source technology are not interchangeable. If you're going to use a framework, for the love of God, please make sure you're not helpless without it. Frameworks are meant to make your life easier. It's a lot like riding a jet ski without knowing how to swim. The slowest jet ski moves a lot faster than the average swimmer, but if the engine ever stalls out at sea, buddy, you are screwed.

Overhead

The overhead. Oh Christ, the overhead. They say that frameworks help you code less - by introducing a lot of predefined code, 10% of which your project may actually use. That's a gross exaggeration, but it's true that not everything in a framework will be of use in the application it's used for.

Getting a little crowded in here, guys.

But really, that's not the issue here. I can live with some wastage. Until it takes on ridiculous proportions.

I've had to use plugins before, while working on Joomla! and WordPress projects. Each plugin invariably installed its own version of jQuery or MooTools. That led to many copies of jQuery at any given time. Seriously, how is this a good thing? Again, call me old-fashioned... but the part of me whose roots came from C++ and having to manage memory, positively recoils in horror.

Or, if you want a serious miscarriage of justice, look at ASP.NET 3.0. You write the code in C# or VB.NET, and the server compiles the code to generate the pages. View the source of the generated pages, and you'll see chunks of server-generated JavaScript, both to preserve state and to simulate the action of the various ASP.NET Web Objects you probably dragged and dropped into the page. Yes, even a humble label is a Web Object!

Framing the Issue

So there you go. Do I hate frameworks? Not really. They have their place. Frameworks are not really to blame here. They're a tool like any other... and sometimes a blooming annoyance. The real issue is with the people who use them. Think about it: Is it the fault of a framework if an overenthusiastic developer decides to use it for every damn thing? Is the framework to blame if developers use it to cover up their own inadequacies? OK fine, overhead is a framework's problem, but is it really fair to blame frameworks for the other problems I've listed?

Technology's fine. It's people who suck.

Over and out.
T___T

The Difference Between Web Developers and Programmers

It's occurred to me that I use the terms "web developer" and "programmer" rather interchangeably. This is purely out of habit. Actually, there's no difference in the sense that both web development and programming are part of software development.

Well thanks
a lot, Mr Obvious.

Indulge me; I'm about to get a bit more specific. Web development is really a subset of software development - a subset that specializes in web technology. Web applications are software just like any other. Software runs on operating systems. Web applications run on web browsers, which in turn run on operating systems.

However, web developers and programmers don't appreciate being lumped together as "IT people".

The average web developer considers web technology a highly specialized field and calling him a "programmer" would net you the proverbial eye-roll-face-palm treatment. I once had a boss who continually told us "You have to step up your game. You're not just a programmer. You're a web developer!" He had a point: web development involves more than programming logic. Much more.

Programmers, on the other hand, consider programming a domain in which web developers are mere pretenders to the title. I'll concede that the average programmer is probably streets ahead of the typical web developer, especially since a healthy percentage of web developers aren't trained to code.

Muddying the waters

If you add mobile app developers and game developers to the mix, and the waters get even muddier. So I won't.

But yes, there are differences. We'll examine them as we go along.

Diversity in web developers
and programmers.

Diversity

Web developers have extremely diverse backgrounds. Back in my day, there was no specific field known as "web development". Web developers were mostly self-trained and hailed from a variety of professions, not necessarily IT. People like myself started off as trained programmers but branched into the web. Then there were graphic artists who started designing for the web. And later, we had marketing specialists crossing over to do SEO. 

Programmers tend to all come from similar technical backgrounds. People from business or engineering crossing over isn't unheard of, but that's usually as diverse as it gets.

One's pretty, one just works.

Form and Function

The common misconception is that programmers make things work, while web developers make things look pretty. It's not a complete lie, but it is a misrepresentation. The people who make things look nice are either graphic designers or web designers. Web developers, of course, need to be concerned with the user experience and how things look on the Internet. Because, y'know, sites are open for public viewing, and all that. That's one of the reasons people put websites on the internet, right?

I'm not saying programmers have it easy. But things tend to be a lot more straightforward for them. If the output is correct and overhead is kept to a minimum, everything's usually peachy. A web developer's output is reviewed by the public, and where aesthetics are concerned, there is no pleasing everyone. A web developer's output is, by its very nature, never 100% correct.

All these devices, and more.

Operating Environments

Software developers may need to ensure that their software runs on different platforms.

Web developers need to ensure that their websites run on a plethora of different browsers, different versions of those browsers, and the mobile version of those browsers! And when you consider that these browsers are updated every few months... yes, ouch.

Programmers often criticize web developers for not being thorough enough and being too willing to take shortcuts in order to get the job done, and lack of long-term vision. That's not wrong, but look at the context. Software is made to last, therefore programmers are allowed - encouraged, even - to do a proper, complete job. The Internet? Websites don't last very long, at least not in their current form Users get bored with the look-and-feel. Content needs to be updated often. Requirements change just like that. We wish we were given the same latitude, but that is the nature of what we do. Nobody has time for us to do a "proper, complete job".

Basically the same skillset,
but with different focus.

Skillsets

Think of this in terms of dance. Programming is analogous to classical ballet - strict rules, respected tradition. Web development is breakdancing - fuzzy rules, relative newcomer to the scene, lots of improvisation required. That's because programming revolves around logic - and logic is immutable. Web development is as much user experience as it is logic. And user experience is subjective.

Programming forms only part of a web developer's expected repertoire. As such, attention is often diverted to other areas, such as internet threats, search engine visibility, cross-browser compatibility, web compliance and aesthetics.

Programmers, in contrast, do programming exclusively and specialize in it. Memory management, data structures and algorithms? That's the programmer's domain.

All that said...

The us-vs-them mentality is unnecessary. We're all making an honest living and ultimately, our work revolves around solving problems. It's simply that the problems we are tasked to solve, have evolved. Let's wear our respective hats with pride.

Web Developer: <p>Goodbye, world!</p>
Programmer: System.out.println ("Goodbye, world!");
T___T

Web Tutorial: Asynchronous File Upload

In any web interface, there will come a time when you'll need to upload files. Maybe it's for a gallery, or a form submission portal. Whatever the case may be, you may also have come across the trickiness of making this file transfer asynchronous.

Why is it necessary? 

It's not necessary, per se. An asynchronous file upload merely saves you the hassle of managing yet another page load. If you're fine with the classic synchronous way of doing it, hey, no sweat. But if you want to upload a file without having to reload your current page or go to a new page, read on.

Is this AJAX? 

No, this is not AJAX. It's definitely asynchronous though, in the sense that you don't reload the current page or go to a new page. But this doesn't return anything to your browser by way of a AJAX object either; so, no, it's not AJAX.

There is a way to do this using AJAX. It's possible now with HTML5. See the example at this link.

But until these specifications become more mainstream, you may want to use the workaround, which this web tutorial is all about! For this, you need a front-end HTML file and a back-end scripting file, which, for the purposes of this tutorial, will be written in PHP.

Here's the front-end code.

tt_afu.html

<!DOCTYPE html>
<html>
    <head>
        <title>Asynchronous File Upload</title>
    </head>
    <body>
        <form id="frmUpload" name="frmUpload" action="tt_afu.php" method="POST" enctype="multipart/form-data" target="">
                <label for="flUpload">File</label>
                <input type="file" name="flUpload" id="flUpload">
                <input type="hidden" name="hidUploadSize" id="hidUploadSize" value="50000000">
                <input type="submit" name="btSubmit" id="btSubmit" value="Upload!">
        </form>
    </body>
</html>

The front-end is supposed to look like this:

The file element is all you need to select whatever file you wish from your file system. The form tag has the following attributes:

action = "tt_afu.php" - this says that you are sending data to the tt_afu.php page.
method = "POST" - this tells the client that you are sending data via POST.
enctype= "multipart/form-data" - this tells the client that you are sending non-text data.
target = "" - this will come in handy later

And this is the back-end code for handling the file.

tt_afu.php

<?php
$strmessage="";
    
if (basename($_FILES["flUpload"]["name"])!="")
{
    $uploadsize= intval($_POST["hidUploadSize"]);

    $filetype = pathinfo($_FILES["flUpload"]["name"],PATHINFO_EXTENSION);
    $filetype=strtolower($filetype);
   
    if ($_FILES["flUpload"]["size"] > $uploadsize)
    {
        $strmessage = "Error was encountered while uploading file. File cannot exceed " . ($uploadsize/1000)  .  "kb";
    }
    else
    {
        $filecode=strtotime("now").rand();
        if (move_uploaded_file($_FILES["flUpload"]["tmp_name"], "uploads/" . $filecode . "." . $filetype))
        {
            $strmessage = "File successfully uploaded.";
        }
        else
        {
            $strmessage = "Error was encountered while uploading file.";
         }
    }
}
else
{
    $strmessage="No file selected.";
}

echo $strmessage;
?>

A brief explanation of what the code does, is in order. First we set a variable  $strmessage. This variable will be altered as the script is executed, and then its value displayed at the end of it. Now, the script checks for the uploaded file, which is stored in PHP's superglobal array $_FILES when the HTML form sends the selected file.

You can learn more about the superglobal $_FILES here. (http://php.net/manual/en/reserved.variables.files.php)

If a file is present, we extract the file extension from the $_FILES array.

Next is an If-else statement to check if the file size exceeds the limit provided in the hidUploadSize text box. If there's no problem on that end, a random filename is generated using strtotime("now").rand(). This is completely arbitrary on my part, and you should feel free to modify it.

Now the script attempts to transfer the file into the sub-directory "Uploads", using the extsting file extension and the newly generated filename. The value of $strmessage changes depending on whether or not it succeeds.

Your code, when executed by uploading a file through tt_afu.html, should look something like this. Nothing fancy, just black text on white background.

All right! You have the front-end and back-end. What's next?

First - you test. Make sure you have the "Uploads" sub-directory created. Run your code. Does your file get uploaded? If not, do the appropriate error messages appear? So your code is working. But remember - you want it asynchronous. Which also means it's time to make a few changes!

Don't worry, the changes are small. First, modify your front-end like so.

<!DOCTYPE html>
<html>
    <head>
        <title>Asynchronous File Upload</title>
    </head>
    <body>
        <form id="frmUpload" name="frmUpload" action="tt_afu.php" method="POST" enctype="multipart/form-data" target="ifrm_upload">
                <label for="flUpload">File</label>
                <input type="file" name="flUpload" id="flUpload">
                <input type="hidden" name="hidUploadSize" id="hidUploadSize" value="50000000">
                <input type="submit" name="btSubmit" id="btSubmit" value="Upload!">
        </form>

        <iframe id="ifrm_upload" name="ifrm_upload" style="display:none">

        </iframe>
    </body>
</html>

This creates the ifm_upload iframe, whose display property is set to none, effectively hiding it from the user's eyes. Then in the form tag, set the form to post data to the iframe, using the target property. Told you it would come in useful!

Test your code again. Does it still work? You'll notice that your file gets successfully uploaded, but now error messages no longer work. Don't sweat it. They're still there, but since they're now within the ifm_upload iframe which is hidden, you won't see them. Go on, change the code, upload another file and see what happens.

        <iframe id="ifrm_upload" name="ifrm_upload" style="display:block">

        </iframe>

Now take a look. Now that your iframe is visible, the messages appear! It's pretty ugly though.

Unlike AJAX, this method does not return data to the front-end. We need a workaround. So what we do is modify the back-end with some JavaScript!

<?php
$strmessage="";
    
if (basename($_FILES["flUpload"]["name"])!="")
{
    $uploadsize= intval($_POST["hidUploadSize"]);

    $filetype = pathinfo($_FILES["flUpload"]["name"],PATHINFO_EXTENSION);
    $filetype=strtolower($filetype);
  
    if ($_FILES["flUpload"]["size"] > $uploadsize)
    {
        $strmessage = "Error was encountered while uploading file. File cannot exceed " . ($uploadsize/1000) .

"kb";
    }
    else
    {
        $filecode=strtotime("now").rand();
        if (move_uploaded_file($_FILES["flUpload"]["tmp_name"], "uploads/" . $filecode . "." . $filetype))
        {
            $strmessage = "File successfully uploaded.";
        }
        else
        {
            $strmessage = "Error was encountered while uploading file.";
            }
    }
}
else
{
    $strmessage="No file selected.";
}
?>

<script>
    parent.document.getElementById("pnlMessage").innerHTML="<?php echo $strmessage;?>";
</script>

parent, in this case, refers to your tt_upload.html file. And of course, this means you now have to create the pnlMessage div in your front-end, to hold the error message (if any). Turn your iframe invisible again as well.

<!DOCTYPE html>
<html>
    <head>
        <title>Asynchronous File Upload</title>
    </head>
    <body>
        <div id="pnlMessage" style="color:#FF0000">&nbsp;</div>
        <form id="frmUpload" name="frmUpload" action="tt_afu.php" method="POST" enctype="multipart/form-data" target="ifrm_upload">
            <label for="flUpload">File</label>
            <input type="file" name="flUpload" id="flUpload">
            <input type="hidden" name="hidUploadSize" id="hidUploadSize" value="50000000">
            <input type="submit" name="btSubmit" id="btSubmit" value="Upload!">
        </form>

        <iframe id="ifrm_upload" name="ifrm_upload" style="display:none">

        </iframe>
    </body>
</html>

Run the code one more time. Does the message appear in red above your form?

Congratulations! You have an Asynchronous File Upload!

It's a cheap and dirty fix. Almost like cheating, really, but it works. And it's been working for a very long time. Until you feel like doing it the HTML5 way, this is a great fallback!

Confused yet? Worry not, it'll sync in.
T___T

Romance and the Web Developer (Part 2/2)

And here, is how web development is different from dating.

Huat!

Hedging your bets

Let's say you're unhappy with your job. Whatever the reason, you're on the lookout for better prospects. What do you do, quit and then look for a new job? Oh, hell no. Web developers gotta eat too, right? Conventional wisdom dictates that you hang on to your current job, get paid as usual, and when that new job offer comes along, snap it up. Au revoir, sucky old job!

Now try applying that logic to a relationship you're unhappy in...

Nothing's working out. The romance is long gone, and you can't communicate, etc etc blah blah. So do you hang on to this woman till a more desirable option comes along? Buddy, that's neither sensible nor clever. End the relationship, then move on to greener pastures. That's what us mature, responsible adults do. We don't selfishly use another person as a placeholder while looking for someone better to come along. It's just not cool.

Put those differences aside!

Discrimination

When you're at work, keep your prejudices to yourself. Your colleagues may be Pakistanis, gay, obscenely fat, Methodists, Liberals, chain smokers or what-have-you. If you have to work together, you damn well better put those personal preferences aside, because they have no place whatsoever in a professional environment.

The story's different when you're dating.

You could be the most prejudiced cow in the world, and it would still be your right to decide what kind of person you want to be with. Slim, beautiful, big boobs? At least a Bachelor's Degree? Has to be Caucasian? Wear a Rolex, drive a Lamborghini? Has to support the same football club, hold the same political views, practice the same religion? Star signs have to be compatible? That's entirely OK. You want what you want. This is your personal life and you can have all the ridiculous, lame requirements your heart could wish for. Go for it.

Two-timing FTW

More the Merrier

Web developers, especially those on the lower rungs of the organization, tend to take up little jobs outside of work. It could be an EDM, a quick Drupal setup  or some CSS tweaking. Or even something that can be worked on, over the weekends, like a full site. That's peachy. As long as it doesn't interfere with the day job and you're not working for a competitor, what the hell, who gives a shit? In fact, these little assignments can help with the day job. You'd be honing your craft by doing, and we all know what practice eventually makes. You could be working on something else and discover a better way to do what you're doing in the office.

But, for the love of God, be advised that this reasoning is unlikely to hold water where your date(s) is/are concerned. "Honey, I am dating someone else on the side because I wanna know you better." I don't really have to explain this recipe for disaster, do I?

Have your meltdown
somewhere else, sweetheart.

For Better Or Worse...

There's this quote going around the internet, dubiously attributed to Marilyn Monroe.

"I make mistakes, I am out of control and at times hard to handle. But if you can't handle me at my worst, then you sure as hell don't deserve me at my best."

This one's been debated fiercely, but the gist of it is that if you're dating someone, you need to be able to tolerate the each other's flaws.

Do not make the mistake of thinking that this applies to your career, unless expectations are shockingly low at your workplace, you own the company, or are blowing the stakeholders regularly (and are staggeringly good at it). This attitude isn't going to get you very far. You'll be seeking new employment faster than I can say "get the fuck off my lawn, bitch". Sure you may not have to give hundred percent all of the time, but you'd better believe that employers are not emotionally invested in having you around. If your presence no longer makes any kind of business sense, your presence is no longer required. Keep your temper or lose your job. Your choice.

The Climatic Conclusion

Those are my thoughts on how web development compares to dating. In all honesty, the subject's very much deeper than this. But I'm a techie, not a philosopher. This is not me giving anyone dating advice.

Choose wisely! Dating can be a matter of wife and death. (heh heh)
T___T

Web Tutorial: Remembering Paris

Bon jour.

I'd like to interrupt the regularly scheduled broadcast to bring you the news that the EU will be holding a moment of silence today at noon, for Paris.

For those not in the know, a rash of terrorist attacks were carried out in Paris over the course of Saturday, 14th November. Facebook became awash in a sea of blue, white and red as users changed their profile pictures in a show of solidarity.

I'm just going to get into the act here, and show you how to slap an entire overlay of the blue-white-red on your website.

Take this HTML and the "lorem ipsum" text as your Average Joe website.

<!DOCTYPE html>
<html>
    <head>
        <title>Paris Demo</title>

        <style type="text/css">

        </style>
    </head>

    <body>
    <p>Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.</p>

    <p>Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.</p>

    <p>Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.</p>

    <p>Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.</p>

    <p>Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.</p>
    </body>
</html>

Now add this div, and the paragraph. Google Translate tells me that it means "we are united". I'll have to take Google's word for it because my French is absolument merde.

    <body>
        <div id="paris_wrapper">
        <p>#NousSommesUnis</p>
        </div>

    <p>Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.</p>

Modify as follows. This ensures that the overlay goes away upon being clicked.

        <div id="paris_wrapper" onclick="this.style.display='none';">
        <p>#NousSommesUnis</p>
        </div>

Next, of course, is styling. Add the paris_wrapper CSS. Its width and height properties have been set to 100% to fill the entire screen. top and left are set to 0 for the same reasons. position is set to "fixed" to ensure that this overlay follows even if you scroll. That's for the layout.

For the rest of it,
cursor:pointer ensures that the user knows the overlay is clickable.
text-align:center justifies the text.
background-color:rgba(252,252,254,08.8) sets the white part of the overlay, semi-transparently.

        <style type="text/css">
            #paris_wrapper
            {
                width:100%;
                height:100%;
                top:0;
                left:0;
                position:fixed;
                cursor:pointer;
                text-align:center;
                background-color:rgba(254,254,254,0.8);
            }  
       </style>

Next, we add another specification to style the text in the overlay. Mostly cosmetic. Modify as you see fit.

        <style type="text/css">
            #paris_wrapper
            {
                width:100%;
                height:100%;
                top:0;
                left:0;
                position:fixed;
                cursor:pointer;
                text-align:center;
                background-color:rgba(254,254,254,0.8);
            }

            #paris_wrapper p
            {
                margin-top:10%;
                color:#888888;
                font-size:5em;
                font-family:arial;
                font-weight:bold
             }
         </style>

Now, we add the blue and red parts of the overlay.

            #paris_wrapper p
            {
                margin-top:10%;
                color:#888888;
                font-size:5em;
                font-family:arial;
                font-weight:bold
             }

            #paris_wrapper::before,#paris_wrapper::after
            {
                content:"";
                display:block;
                width:33%;
                height:100%;
                position:absolute;
                top:0;
            }   

            #paris_wrapper::before
            {
                left:0;
                background-color:rgba(0,0,254,0.5);
            }

            #paris_wrapper::after
            {
                right:0;
                background-color:rgba(254,0,0,0.5);
            }   

This basically adds two block-level elements to your paris_wrapper div, both with a width of 33% (because one-third of 100% is roughly that) and a height of 100%. They are then colored blue and red respectively and positioned.

Here you go. Hope this is helpful for your moment of silence.

Vive la francais,
T___T

Romance and the Web Developer (Part 1/2)

People often say working is like dating. Your career is like a relationship that needs to be cultivated, nurtured and maintained. They're not all wrong, but after a bit of rumination, I've stumbled upon more pieces of the puzzle. There are both similarities and differences. If you treat your career like your relationship, it might take off gloriously, or you might crash and burn.

Why this topic?

See, recently I met this woman through one of these newfangled mobile dating apps. We met a couple of times, hung out, and talked. Her company was all right, though I had no intention of taking it further. Somewhere along the way, she revealed that she was seeing someone, who was a married man. She wasn't altogether happy with the arrangement, and dropped heavy hints that she would be open to another guy rescuing her from this situation.

That's when I pulled the hand-brake.

Fine, I may not be much. Average looks, average figure, very average paycheck. But I have enough self-respect not to allow myself to be part of this distasteful monkey business. Even if I were interested in her (and no, I wasn't), I would still not have engaged in the whole knight-in-shining-armor-rescuing-the-simpering-damsel charade.

However, it occurred to me that if this was paralleled in a professional environment, I would have absolutely no problem with it. I would even encourage someone not to quit his job before looking for a new one. Is this hypocrisy? Double standards? Not at all. That's because working and dating, while eerily similar in places, are inherently different.

And that's where I got to pondering this topic - how is web development and dating the same, and how are they different? Let's begin with the similarities.

All shapes and sizes

Not all are equal

Not all jobs are made equal (even in the same industry), and neither are women. They're all unique in their own ways.

One of my previous jobs dealt with the business end of development, whereas the one before that dealt exclusively with the technical portion. I adapted, but it was a struggle. Instead of spending my days in a cramped room churning out code, my hair and stubble all over the place and wearing clothes that had seen better days; I now had to get a decent haircut and shave, put on a shirt and tie and nice shoes, spray on the cologne and gargle that mouthwash, and generally make myself pretty. It required some adjustment. Mere technical proficiency just didn't cut it anymore.

As for the women? Some wanted romance. Some wanted the devil-may-care dude with the shit-eating grin. Some wanted respectability and financial stability. One even felt that financial stability wasn't quite enough, and wanted someone ambitious enough to start his own business. Some just wanted a good time in the sack. And some, regrettably, didn't even know what they wanted.

Different jobs demand different things from you, and so do women. It's a good thing - it stretches your repertoire. You have to tailor your approach, and take nothing for granted.

Some lines can't be crossed.

Certain things go without saying

That said, some things should be assumed. Ever have your boss tell you "you're too experienced to make a mistake like this" or a woman say "I can't believe you've learned nothing from dating that many girls."? I have. And it's especially galling because they're right.

You don't go AWOL from work. You don't work for the competition, or steal your boss's clients. If you're given enough time to do a job, you don't write sloppy code just to meet the deadline.

When you're dating... be nice to her friends. And when she asks you if her ass looks fat in that dress, the correct answer is not "yes". ("Yes, and boy does it turn me on" might be acceptable, but try that at your own risk.)

With each job or woman that you pursue, over time, there are certain rules of thumb (a.k.a universal rules) you may have developed. The above are just a few examples.

"Me" time

Time off

People need some time off from their jobs once in a while. It's only healthy. I hate the term "work-life-balance" - it's so overused and trite - so I'll just call it "letting the brain cells regenerate". Spend too much time on a piece of code and you end up getting tunnel vision. Taking a break, even if it's only in the form of eight hours' rest, is good for your job, and good for you.

Likewise, relationships need that. Couples need time apart. Either to hang out with other people, or just some good old-fashioned "alone time". Know when to give the intense lovin', and when to give people their goddamn space. Taking a break, even in the form of a day or two, is good for her, and good for you.

See the pattern here?

It helps to step back and breathe. And when you return to either your job or your date, you see things with a renewed clarity.

Put your back
into it, buster.

You get what you put in

Oh, scrub your filthy mind.

Sure, the world's an unfair and unpredictable place. Some people graduate and have their careers mapped out for them from the get-go. Some people are genetically blessed and have interested romantic parties throwing themselves at them every damn day. But privilege aside, nothing good comes easy. Whether it's a career or a date, you need to put your back into it.

Ever tried to write a web application? A fair amount of work goes into it - planning, coding, testing. You need it to look good. You need it to work. You need it to be secure. The list goes on. Now imagine having to put in that much work throughout your entire career - and more. And that's not including client relations and office politics.

Dating needs work, too. It ain't all sunshine and roses, and if you still believe that love will strike at first sight and you'll naturally end up meeting some woman at the altar some time later; dude, why are you up so late? Don't you, like, have school tomorrow?

Next

We examine the differences. This should be interesting.

Steve Jobs: Love What You Do

It was early one morning when the company had a gathering in the conference room. We were shown a video, of Steve Jobs making a speech at Stanford College. Apparently this was meant to be an educational experience for the staff.

During the video, Jobs said this.

"Your work is going to fill a large part of your life, and the only way to be truly satisfied is to do what you believe is great work. And the only way to do great work is to love what you do."

No, I have no problem with what Jobs said, whatsoever. In fact, I concur.

What was interesting was when our Office Manager used that quote to illustrate her own behavior. She told us she loves what she does - and that's why she comes in early and leaves late. It's true - she does that, and I offer no argument to the contrary.

What did pose a problem, however, was that the entire exercise was meant to inspire staff to work harder and put in that extra mile. I'm afraid it could very well have been taken the wrong way.

Love what you do.
LOVE IT!

The staff seemed to be being fed the concept that loving what you do means spending more time in the office.

Dead wrong. On so many levels. But I'll address the most pertinent one - that you don't have to be in the office, or even part of your current company, in order to love what you do.

Yes, spending more time in the office can be a result of loving what you do. But loving what you do should never be confused with loyalty to the company. At some point in your career, your company and you are going to part ways. Bank on it. But you will remain who you are, what you are.

I am a web developer. I write scripts, code and test. I design layouts and systems. I set up databases.

I love what I do.

I love it so much that I leave the office on time whenever possible, so that I can continue honing my craft once I reach home.

I love it so much that the insane amount of competition flooding this little island has not deterred me one bit.

I love it so much that even though I could feasibly be making more money doing something else, this is what I want to do.

So much that most of my waking hours I spend doing just that, on my weekends and vacations. And I will continue to love it even if, one day, I no longer work for this fine company. Because I would be doing what I love somewhere else.

That is what it means to love what you do.

Much love,
T___T

Five Employer Bullshit Lines

Morning, long-suffering readers.

Have you ever felt like your employer was trying to pull wool over your eyes? Give you some textbook pep talk designed to put your nose even more firmly to the grindstone? Grease you up for some heinously degrading/difficult/thankless/all three task?

Well, wonder no more. In my years of web development, I've come across some real doozies. Even fallen for a few of them. Here, I'll list five of the stinkiest bullshit lines I've ever heard an employer utter.

1. The Post-probationary Bait

"We'll pay you this much first, and review your salary after you pass your probation."

Subtext: Bite, sucker. Bite hard!

This line has happened three times in my professional life. The first time, I laughed out loud and abruptly left the interview. The second time, I got laid off as soon as my probationary period was up. The third time, the employer actually increased my salary... by thirty-three dollars. Per month.

Such overwhelming generosity!!!

I've seen it happen to others too. Promises are easy to make, but somehow after you've made it through the months of your probationary period, getting a raise is like getting blood from a stone.

In short, anything that isn't written in your contract is just so much hot air. And if it is written in your contract, the probability of you getting fired after your probationary period just went up by 20%. No, when I apply for a job, I want my raise right away, and I want it to be worth the hassle of switching jobs in the first place.

2. The Dummy Promotion Carrot

"We're looking to promote. We need to evaluate your performances these coming months."

Subtext: We already know who we're going to promote, and it's not you. But what the hell, let's see how hungry you are.

This is when your employer has already decided who he's going to give that promotion to. The rest of you just aren't working hard enough for his liking. In his eyes, you'll never qualify for promotion - you're either not skilled enough, not pretty enough, not eager enough. But hey, you don't have to know that. A little bit of  motivation will go a long way, right?

This isn't for you, but you're
not supposed to know that.

The idea here is to dangle that carrot. You'll put in the performance of your life, and meet with certain disappointment. They'll imply that you simply weren't up to the mark, but the fact is, that carrot was never meant to be yours.

My humble opinion? Don't do it for a promotion. Give your best because it's who you are and what you do.

3. The Reverse Psychological Ploy

"You're probably not up to it, so no pressure."

Subtext: Prove yourself.

Good golly, I hate this one. Especially since I've been suckered by it time and again. I suspect the employer who used this on me, especially since he's a computer geek as well, knew how well it would work on me because it's worked on him before.

Basically, here the employer implies that this is such an awesomely difficult task that you might not be good enough. And if you fall for that one, you'll work extra hard just to prove otherwise.

Challenge accepted,
motherfucker.

Back in the day, I could never let this challenge to my huge developer's ego pass unaccepted. If the boss even hinted that something was too difficult for me, I absolutely had to prove him wrong. This led to very long workdays, slaving away on weekends and loads of intense effort. Fortunately, in the process, I leveled up.

Still a bullshit line, and one of the dirtiest tricks in the book.

4. The Burnt Bridge Gambit

"If you tender your resignation to your current company today, you can come over this evening and sign your appointment letter with us."

Subtext: We really hope you're dumb or desperate enough to swallow this one.

So you've gone for an interview. The boss seems to like what he sees, and he's prepared to make you an offer. All he needs you to do is sign the appointment letter. Of course, there's the small matter of tendering your resignation to your current company. Not a problem, right?

But then the boss throws a spanner in the works. He needs you over ASAP, so he's going to put the date of your appointment as exactly one month (or whatever your contractual notice period to your current company is) from today, not tomorrow. Which means you have to tender your resignation before going over to sign the appointment letter.

Don't burn your bridge before
signing.

This is a dick move, no doubt, but please tell me you're not actually stupid enough to do it. What if the terms and conditions in the contract are different from what you discussed earlier? What if the pay suddenly isn't as attractive, the job scope seems to have doubled and there are more strange clauses you weren't aware of earlier? You just burned the bridge behind you, dude.

5. The Butter-up

"I like you because..."

Subtext: The task I'm about to entrust to you is something even interns are too dignified to do.

Insert more bullshit after the "...".

I like you because you take responsibility for your actions. Like, whose actions should I take responsibility for, yours?

I like you because you see things through. Like I have a choice here?

I like you because I know you'll rise to the occasion. Kiss my ass. Oh hold up, you already are.

Christ Almighty. Just how trite can bosses get?

Fake and overdone praise.
Who needs it?

It's some shit job they need someone to do, and you just got arrowed. Fine. No need to sugarcoat it. What's that flattery supposed to accomplish, enthusiasm? Lame.

What a load of poo...

Phew! Even typing all this down makes me feel filthy. Some employers really don't understand subtlety, do they? If you're just such an employer, may I suggest you try something a little less insulting to the intelligence of your employees? Employees need a little encouragement now and then, sure. You want your subordinates to sweat for their measly wages, understandable. But if your lines stink like you pulled them freshly out of your arse, perhaps it's time to put a little sincerity into it.

Sincerity, like, y'know, a big fat bonus paycheck.

Yours excrementally,
T___T

Google's Logo Switcheroo

Holy pixellated pictograms, Batman! Google has changed their logo! Again!

Google: Before and after

If you're like me and a little slow on the uptake, you might have noticed the change now, when it actually took place two months ago. It's not that I never noticed; it's more that the change never fully registered in my mind until now. I mean, come on, this is Google. Ever so often, they change their home search page for shits and giggles, and sometimes, that involves changing the font and styling of the word "google". This felt like one of those changes.

Take a look at some of these. (Check out more at Google Doodles!)

And I'm suppose to blink when I encounter this?

That aside, check out Logopedia and you'll see that Google has changed its logo no less than five times since it burst on the scene in 1997. The last change took place in 2014 where the "l" in "google" was shifted by a few pixels. If nothing else, this tells you just how anal detail-oriented the branding team is. As they should well be - Google's brand is pretty damn strong and one of their main assets.

Google's been evolving since Day One. It's associated with change, in a constant state of flux; which is perhaps why it still feels fresh and perky despite having lasted more than a decade. Which is also why I saw the new logo two months ago and thought little of it. Hey, this is Google, right?

The Trend

Two other web companies that changed their logo these past few years - Microsoft and Yahoo!. It's worth noting because the changes, including Google's, reflect a trend. Note the transition from fancy lettering and kerning to simpler non-serif fonts. In Yahoo!'s case, the vertical alignment has also been altered to be less radical.

Yahoo!: Before and after

Microsoft: Before and after

All to what end? Well, you may have noticed that the changes seem to have been made to allow their logos to be better viewed on small screens, ie. mobile phones and tablets. Mobile devices have influenced yet another aspect of our lives. This is the new normal. Embrace it!

When will Google next change their logo? Hey, search me.
T___T