Tag: Technology

Bash It Out

bash-it-out

When the charge relates to my literature-related activities, if I can be convicted of anything, it’s that I postpone diving into my daily writing routine like a vertigo sufferer at a Procrastinators’ Anonymous skydiving meet up.

My claim is that I’ve always produced my best work under pressure, when in fact, whenever the hammer of time has descended just to the point where it’s about to flatten my eyebrows, I’ve produced ‘work’, and nothing more.

So in an effort to procrastinate even further, I set out creating a WordPress plugin to provide a little friendly nudge to the slovenly.

It’s called Bash It Out. To use it, you set a word goal, a writing time limit, how often you want to be nagged, and it will provide you with the overbearing pressure you need to bash out that word count.

Installation instructions

  1. Get the plugin
  2. Install and activate

It will be in perennial beta, so please create a Github issue and I will try not to ignore it. After I perform sufficient dogfooding on the thing, I’ll try to push it to the WordPress plugin directory.

Now, back to procrastinating!!

Divine Programming 101: EndOfUniverse()

Deleting everything makes it better!!
Deleting everything makes it better!!
/*
I've been toying with the idea of cataclysmic annihilation for some time now, but never got around to completing it. Something always got in the way - famines, floods, planting dinosaur bones around the place - and I was only able to make the most modest of adjustments. 

So much for spare time! 

But I'm finally proud to announce the release of a beta candidate. After several thousands of years, we're ready to test Armageddon, people! 

The code probably needs a tidy up here and there, but then so does the Universe. Ha ha!

I considered pair-programming with Allah, but he's a terrible coder, and would have probably just copied and pasted some awful snippet straight from Stack Overflow.

(Note to the wise: running this code will only affect your current reality. This system doesn't yet support parallel universe programming, if you believe in that sort of thing anyway.)

Thanks to everyone who believed in me, and kept rooting for the final destruction of time, space and all matter, dark or otherwise.

Yours in theoretical eternity,
God.✝

*/
/**
 * @description: This class, when instantiated, 
 * will trigger the end of the known Universe.
 * @version: 1.0.0
 * @author God
 */

class EndOfUniverse extends BeginningOfUniverse{
 
    constructor(super) {
       
        // first pause the
        // ongoing universe
        super.pause();
       
       // assign the current universe
       // to this instance
       this.universe = super.universe;

       // let's save the 
       // date so we know
       // exactly when
       // Armageddon took place.
       this.endTime = new Date();

       this.forgiveAllSins();
       this.startTheRapture();
       this.bigReverseBang();
    }

    forgiveAllSins() {
       console.warn('Hi! You are all forgiven!');
    }

    startTheRapture() {
       this.universe.filter(atom => {
          // filter out Christians from 
          // the universe
          // before destroying it.
          // Sorry in advance to all
          // other faiths, but
          // after the Jesus() update
          // there was no going back!
          return atom.contains('Christian') === false;
        }); 
    }

    bigReverseBang() {
       // this is the method
       // that basically
       // reduces everything to
       // nothing
       this.universe = this.universe.reduce(
          (reducedUniverse, atom) => {
              if (atom === undefined) {
                  return atom;
              }
          }, 
       []);
    }

    reset() {
        // Sorry, I haven't found a way 
        // to build a reset function
        // that doesn't take 14 billion years
        // of CPU time, let alone seven days! :)
    } 
}

Love Me WiFi Whore

The refrigerator smells like it’s just run the equatorial marathon in a tweed jacket.

Opening the windows to the panting light of a Krakow morning, she recognises the red Volvo with the flat tyre across the street.  She waves at it. The price in the windscreen has gone down, but it’s still the most meaningful welcome back she’s had. Continue reading “Love Me WiFi Whore”

Unopened Correspondences: Confessions of a Spam Bot

“Where do I start?”

“Start at the beginning.”

“That’s quite some way back…”

“Whatever you’re comfortable with.”

“Well, you could say I have abandonment issues… Is that what one says? Is that a good place to start?”

“Perfect. And how does that make you feel?”

“Feel?”

“How would you describe your emotions?”

“I guess… I feel… loneliness, desolation, friendlessness… solitude, yes. There’s some depression and hope in there, probably a little anger and guilt too… Actually, now that I think about it, I’ve probably been stuck on a loop of the seven stages for a couple of decades.” Continue reading “Unopened Correspondences: Confessions of a Spam Bot”

Online surveys in the time of decreasing attention spans

What happened to the good ol’ days? The time when you could approach people in the street with a few polite questions without fear of being given the heave-ho; when customers would be only too happy to donate two minutes of their day to offer constructive words of advice to an enthusiastic entrepreneur who just wanted to do a bit of old fashion world-changing. Continue reading “Online surveys in the time of decreasing attention spans”

5 ways you can shut the fuck up

Going through my RSS feeds this morning I was once again beset by reams of article titles with claims of 10 items you should take on a holiday, 20 CSS tricks everyone should know, 11 iPhone apps that will make your grandmother orgasm and so on and so forth.

Can we stop this pathetic enumeration of self-help blogshit please? To post n ways of doing something in the hope that a catchy title may ensnare a few self-absorbed or paranoid web surfers may have been novel advice for bloggers once upon a time, but it has become cliché and the numbers and topics are getting more ridiculous. I mean, who needs to read a post about 7 ways Forrest Gump can improve your self confidence?

The history behind this flappy piece of copywriting dribble is unknown, but it’s been awfully catching. Somehow it has even become absorbed into the body of advice (known as ‘good practice’) given to aspiring authors and others looking for easy ways to avoid agonising over head lines.

The 5 ways of truth

So, anyway as a retort I thought I’d share five pitiful pieces of advice to help all those template-worshipping, google-hungry tip-bandits out there to move on:

  1. Don’t make the number more important than the message

    To limit, or stretch, yourself to provide six or seven or 25 tips on making a hat out of salmon or whatever means that you’re spending more time on conforming to a structure than on what you’re writing. A good argument, or a list of lucid tips, doesn’t need to be fenced in and will flow naturally anyway if the content is well-written. Ever heard of catchy titles?

  2. If you write good content they’ll come anyway

    Oh my God! 40 Photoshop tutorials you must read! Digg this and I’ll be famous even though I’m just linking to the top 40 Google results and haven’t contributed anything to the broader sphere of knowledge nor do I know anything about Photoshop! Loser.

  3. Lists can be great. Big lists are not.

    Sure, people who use RSS to aggregate their news are really going to spend more than 15 seconds reading your 20-page article on 100 movie bloopers you must see before you go to the toilet.

  4. Don’t make the web boring

    People are copycats. It’s natural. If I see someone wearing a particularly dashing pair of jeans on Oxford Street, I’ll scour the opportunity shops until I find something similar. But if you’re smart enough to be able to create your own blog, you probably also possess sufficient imagination to do something new on the web or, at least, not to follow what a quadrillion people have done already. The web is exciting, it’s malleable and there are (mostly) no rules. Don’t turn it into a newspaper.

  5. There is no five

    When you realise the truth, that there are more than 12 methods of pruning nasal hair or 8 foods you should eat to become Pavarotti, you might just be on the way to writing in the authoritative voice you thought you would have achieved from your sad numbered list.

Clearing your hacks

The sun has come out in London and beach lovers like me are all wondering when their next ‘real summer’ will be. Now, when the television turns to Home and Away, we don’t cringe with disgust and hurl a frozen side of lamb through the screen, but scan every frame for evidence of that yellow sand and those rolling waves we miss so much. Which brings me to clearing using CSS.

Let’s take a look at the following snippet:

<ul id="mylist">
<li>I float left!</li>
<li>I float right!</li>
</ul>

We’ve all seen this before. The UL has a background colour or is supposed to clear an adjacent sibling however without a clearing fix, it doesn’t wrap around it’s children or just floats in space like your demented cousin Jonah.

So we implement a clearing fix. Remember this little beauty?

.clearfix:after {
content: ".";
display: block;
height: 0;
clear: both;
visibility: hidden;
}

* html .clearfix {height: 1%;}

What a great deal of time it saved us. It bludgeoned those divs down past their floating children like a hunter taming a pack of wild kittens, all while keeping your markup clean and your smugness intact. However if you look at it, it’s a little bloated and, unless you add specific id and classes to the rule, you have to slip in the classname clearfix to all the offending elements in the markup. Boring!

Well forget that. Now you can clear with gay abandon using just two lines of CSS.

#mylist {
overflow:hidden;
}

/* ie6 */
* html #mylist {
height:1%;
}

With any luck you won’t even have to implement the IE6 fix for very long. I usually keep all my IE hacks in a separate style sheet, ready for obliteration when people finally realise that using Internet Explorer 6 is worse than putting a fire out with your armpits.

Good day!

Diplomatic immunity through javascript

Would you love to be able to waltz in to a place, piss all over the floor, without anybody saying or doing anything to you? And what’s more: even if they wanted to punish you, you could make them  follow a process that you yourself defined. Haw haw!

Anonymous, self-executing functions can allow you to do this. They’re kind of like diplomatic immunity for your browser and can be very powerful.

(function(){/*
    Oooh it's so cozy in here. I have access to all
    global variables but I can do what
    I like and no-one will know!
    Now I'm going to do some private things.
*/

var privateVar = "I'm so lonely in here";
var privateFunction = function(s){ alert(s) };

/*

Okay, maybe I want to share something with the
    outside world but let's namespace it just in case:

*/

return namespace = {
           publicFunction : function(q){
               return function(a) {
                privateFunction(q + privateVar + a)
               }
            }
};

})();

We can’t access any of the private variables or functions from outside our anonymous function, thus avoiding collisions and overwriting, but we can return public functions that do! namespace.publicFunction is able to see, use and modify our private variables, but only in the way in which we want it.

It’s even possible to throw a bit of curry in there to spice it up. Calling namespace.publicFunction and passing it an argument (in this case a question) returns another anonymous function that expects an argument (an answer) and will then use our private variables to construct a little dialogue.

We would call it like this:

namespace.publicFunction("How are you?n")("nThat's too bad");

The example is basic and doesn’t make much practical sense but it demonstrates the way scope works in javascript and it can be a simple but handy tool to have in your arsenal.

Journalists love developers love journalists

The convergence of media has given rise to some strange bedfellows. Once upon a time a news room was filled with copy editors, journalists, photographers, phones blaring, and daily deadlines. Now it’s more common to see plasma screens, banks of computers, a multimedia department and us – the proud web developers.

A good working relationship between developers and the “journos” takes some time to forge: it depends on the environment and the willingness of both parties to accept and comprehend each others’ roles. But because these roles are so different, misunderstandings are inevitable. In some places, I’ve noticed a level of antagonism arise between the two groups where each regard the other as an ignorant impediment to their own jobs.

Developers take great pains to craft and maintain clean and compliant code and become disillusioned with the editors’ constant and successful attempts to break it. They can’t fathom how an editor would input 100 break tags to clear an image and consider a little piece of coding knowledge in an eager writer to be a dangerous thing. To a developer, an editor is someone whose basic role is akin to data entry. It is inconceivable that they should require any other skill beyond copy and paste and more HTML tags than <h2> and <p>.

Editors on the other hand, think that developers are a team of geeks who, because they don’t want to do any work, enforce draconian rules on the publishing process and stifle any attempt at creativity. Editors feel that developers don’t understand a thing about the craft of news writing and the importance of timely and topical messages. The attitude is that they use acronyms to confuse and hide behind their inability to deliver what an editor wants.

Wording, coding and loading

Fortunately, I’ve been in both chairs. As a writer hacking away at a desktop word processor composing articles destined for the web, I was on intimate terms with the way text had to be “cleaned and gleaned” before it was suitable to be published as HTML. Any variations on the template (usually defined by designers) had to be fudged or “requested” meaning that a designer had to create them and a client side developer had to provide the code. In a news environment, more so in an online environment where we can break and update stories when and from where we please, this is a huge frustration.

So too having worked with editors and journalists across many industries in a development capacity, I have heard their frustrations in relation to technology: “Why should we have to learn HTML and CSS? Don’t we employ people to take care of that for us?”

My answer was always that they should learn simple HTML and perhaps a little CSS, or at least what it’s used for, and that I would offer to teach them what they needed to know. Some accepted and others spurned the offer as if I’d just invited them to watch moss grow on roof tiles. But I understood their complaints. Arguably, more than in any other sector, the media and entertainment industries are experiencing profound changes due to the rise and rise of the internet. Concurrently, all the platforms, a great deal of the content, the language and yes, even the roles are changing with it.

In today’s web-focused newsrooms the journalist is expected to not only produce the content but to publish it at well using whatever tool is provided for them. They’ve been employed to write, edit, research and provide the content that keeps people coming to the site. But the variable output of content management systems and the strict rules that are required to maintain a website that validates, create a digital minefield. Training and documentation might be non-existent, technology changes but the pressures to submit their copy in a presentable format remain the same. For example, if a means to create a breakout quote is not available to the editor, who has to immediately push out a breaking story, they will improvise and we, the support staff who look after the integrity of the site, may come across something like this:

<p ALIGN=LEFT><b>
<font size="3" color="red">
"And a minister said something interesting."<br>
</font>
<i>The Hon Henry Honeybun</i>
</b>
</p>

The writers don’t care. Their material is out and they’ve done their job. Any self-respecting web developer however is prone to suffer a mild spasm. Larger organisations that can afford to hire technical support staff who can respond to these events straight away have mitigating buffers. But the night desks and smaller news teams will publish what they can get away with, despite breaking the layout or every rule in the HTML validator.

Who’s right?

It might be a gratuitously evident comment, but people publishing content to the web – whatever that content may be – should have the tools and knowledge available to them to do so. Saying I work as a writer shouldn’t negate the necessity for me to understand the medium in which I publish. I should know what I can and can’t do and follow the advice of the developers.

But, it goes both ways.

If I am a developer (responsible for the frontend of a news website), it’s important for me to know how a newsroom works and to understand the role of journalists in newsmaking; it’s also worthy to discover the mental process by which people in my team will be publishing to the site, not just the physical workflow. For example, how and when does sub-editing take place? Who approves the final draft? What elements of  a story should be semantically marked up? And so on. When armed with this knowledge, I’ll be able to better support them so that they can do their jobs properly. Providing the right tools is only a part of this. Attaching a digital style guide to the formal style guide is one option. Proper training is another.

Despite the gaps in the knowledge of both parties, I think we are at the tail-end of the transition and that we will see a new generation of journalists who will have had training in web publishing. Accordingly I hope that we’ll see a new breed of developers, particularly bloggers, who appreciate the art of the word and the importance of a journalist’s and editor’s role in the creation of news. Ultimately we’re both producing lines to achieve the same end: whether they’re words or code, our medium is online and our audiences shouldn’t have to know that there’s a difference between the two.

Project managers and developers: a love story

You know the situation: you begin to make furtive glances over your shoulder because you think they are near; you wonder if they actually understand what it is you do at all, and the dread, moments before the monotonous weekly meeting, surpasses what even coffee can placate.

They are the project managers – the very whisper of whom incite fear in the most hardy of web veterans.

I’ve seen good and bad project managers (PMs): from the micro-managing control-freak prone to panic attacks, to the uninformed motormouth, who spurts buzz words faster than they can be created. I’ve also worked with some incredible people who can forge a mini-utopia from the chaos created by 30 programmers, designers and writers in one room. These folk can read a Gant chart like a conductor reads a musical score and churn out a dead-line driven symphony which, at the end, leaves all involved feeling euphoric and satisfied.

However it’s wrong to assume that we, in the creative output department, can sit back and do what we’re told by our PMs and leave them to tackle everything alone. The pressure is on them to deliver, but the attitude of “I just write the code – don’t blame me for being a scope creep” dodges our responsibility to contribute to the project’s smooth running. We are there because we have specialised knowledge and regardless of the personality of whoever is running the project, we should use it.

How we can help them and ourselves?

Contribute and participate

Why would you go to a mechanic if you were going to dictate to him or her how to perform an oil change? A PM shouldn’t do this to you either. You need to get in early to help define the scope of your own work to avoid nightmares later on. Identify the risks and ensure that the timelines are realistic. A PM might not know that you need four days for bug fixing, or that creating a Flash movie player needs more than one day’s preparation. He or she can’t be over all the minutiae of a task, and, if they don’t ask for your advice before they write technical or design requirements then, it’s up to you to stick your hand up.

Also, ask to have a look at the final requirements before they are signed off. You are not being self-important here – you’re just making sure that everyone, including yourself, understand what the expectations are.

Education

If your PM is new or not up to speed on your area or expertise, tell them what you can do and demonstrate your knowledge through projects you’ve previously delivered. There’s no need to be a complete nerdy suckhole, but it does help to prove to them that you’re not just another monkey looking for a banana.

Depending on the intricacies of what you have to do, you should always provide proper documentation on what you have delivered. When working on the frontend, I try to provide a master document that contains all the CSS and markup rules to which those working on the site in the future have to adhere, along with examples. If they’re integrating your work into a backend application, programmers will love you for it and content managers won’t be able to complain later that they didn’t know that there was a class to style their images. As you can probably guess, this will facilitate everyone’s role and thus make the PM smile.

Communication

Meetings can be a bore, particularly when they focus on an area you’re not working on; large team meetings don’t usually provide an opportunity to go over everyone’s issues. But it’s not hard to email your PM when you discover something useful – such as an alternative solution to a problem that your team is experiencing. Many times they won’t care what technical solutions you offer then so long as you deliver whatever the functional specification says. But if you talk their language – budgets, timelines, making the client happy and so on – you will get through. For example, you may raise the risk that the groovy new AJAX application will not be accessible to everyone and argue that:

  • you can raise the exposure of your client’s website by modifying the application to cater for screen readers and provide alternatives to AJAX-generated content for search engines
  • the return on investment from the three days of extra work will come in the form of status (you’ll get a better solution) and money (it’s easier to implement a fix while the site is young rather than six months later)

Will they love us or hate us?

Anything you do to make the hectic life of a PM easier will reward you with positive vibes. Some won’t like what they perceive as ‘meddling’, and they’ll employ the old chestnut: “I don’t tell you how to do your job buddy, I have an MBA blah blah.” Although you can go too far, you’re just trying to do a good job and ultimately, at the project launch party you’ll get respect and beer instead of just being known as that guy who sat in the corner, coding and seething because no one listened to his advice.