Help Stop SOPA/PIPA: wp.me/pZhYe-zl

— WordPress(@WordPress) January 10, 2012

Being a Software Developer

There is more to creating Web sites and applications than just drawing them.  The creative vision may, and most likely, not originate from the developer who brings it to life.  It’s our job, as developers, to take an idea and build it.  Many times, the vision brought before us is just that: an idea.  We have to take it and architect the structures and logic, to turn the idea into reality.

Under the pretty layer of the final product is a collection of technologies and languages that, when brought together, make some serious awesome.  One cannot compose a fugue without understanding scales and chords.  A poet cannot create a sonnet without knowing syntax. We cannot develop an application or Web site without at least some basic fundamentals.

First and foremost, I think you should have a very good grasp of symbolism.  If you cannot think abstractly, or apply symbolic scenarios then this will be a fairly complicated venture.  Programming is chock full of text that symbolizes structures, instruction and math.  A background in mathematics is highly recommended but it is not required. 

I would also recommend knowing how the physical components you intend to interact with work. Such as the processors, memory, storage, and the network stack down to the physical layer.  Not required but makes life easier, in my opinion. Don’t let it deter you.

Next, for specifically Web App development, I recommend acquainting yourself with the core technologies of the Web itself: XML(HTML), CSS, and JavaScript.

HTML / CSS / JavaScript

There are three main things to master in web development.  HTML will be the frame for which we build on. CSS is what defines the visual/physical/placement properties of the elements in the Document Object Model (DOM). JavaScript provides the application logic/behavior of the web app we build.

HTML

There are many elements available but most are left unused because for the fact that we use CSS to define meaning and presentation.  Beyond the obligatory doc-type, root, title, meta, link, style, script and body tags, the vast majority of web application user interfaces almost exclusively use: div, span, ol, ul, li, img and a tags.

There are a lot of tutorials over HTML and making static web pages. Making WebApps depends on the foundations of that knowledge, though Web Applications are dynamic and have different design constraints. Keep that in mind and always think for yourself.

Remember: HTML is XML. Treat it as such. Do not mix presentation with data/content. If you are using formatting and presentational HTML tags (such as font, br, p, b, i, s, u, strong etc) you are doing it wrong — or at least making it too hard.  With CSS, any element can look/be anything.

CSS

CSS is what you will use to make it pretty. It’s crucial to know and master this. Web App User Interfaces that don’t fully utilize this will suffer. There are even some behaviors and interactions that are nothing but CSS rules.

JavaScript

JavaScript is the client side programming language of web apps. Your back-end can be written in anything your heart desires, even JavaScript with node.js, but your code that runs on the client will be JavaScript, one way or another.  You can get really deep into this, but don’t be overwhelmed. There are some really good resources that introduce it in a very nice way.  

There are other languages available on the client side, but none of them are completely cross-platform or in the case of Native Client it may not be ready for prime time across all platforms.

Note: Most of the information on the w3schools site is correct, but there have been very public errors from time to time. Any resource could have errors.  If you try something and it doesn’t work, cross check it.  I personally love Stack Overflow (and all related stack sites) as well as QuirksMode.org – a great cross-browser compatibility resource.

• CSS Links:
    * CSS Basics’ Introduction to CSS
    * CSS Zen Garden
    * Zen Elements’ CSS3 introduction
    * HTML5 Rocks
    * A List Apart
    * CSS Beauty
    * CSS3 Info
• HTML
    * Getting started with HTML
    * HTML Introduction – w3schools
    * HTML DOM Introduction – w3schools
    * HTML5 Boilerplate
• JavaScript Resources:
    * Learning Javascript with Object Graphs
    * Learning Javascript with Object Graphs (Part 2)
    * Learning Javascript with Object Graphs (Part 3)
    * Mozilla.org Developer site
    * w3schools Intorduction to JavaScript
• JavaScript Libraries/Frameworks:
    * jQuery
    * Learning jQuery
    * Prototype.js
    * Script.aculo.us – built on top of prototype.js
    * ExtJS
    * Cappuccino
• Generaly Awesome Links:
    * Stack Overflow
    * QuirksMode.org

So, with Jasmine downloaded, I began playing with it and trying its examples. I loved it. Pure JavaScript solution with no external dependencies; I could simply hit the test page and off the tests go. I’m sure with a little more digging it would work in a offline/build/cli environment with PhantomJS or node.js. The only hurdle I had left was how (and what) I wanted to test. Not every file/class in this UI stand alone, or the application state. How would I want to simulate the server? So many things to sort out before I was satisfied that I had a solution.

Then I had an idea. What if the tests ran under their own version of Ext.Application? My main app.js file was simple: it defined the “Application”, its namespace, its path, the controllers and the launch method, which, for me, only initiated the login sequence. Basically, my idea was to copy the app.js to app-test.js, then copy index.html to test.html (this application is using the ExtJS4 MVC project layout).

So, here’s my folder structure. It will look a little familiar as I’ve based this example on the documentation’s example layout.

Folder Structure

So, we have the jasmine package under app-test/lib, and mock data under app-test/mock and all the test suites (“specs”) under app-test/specs.

index.html and test.html look very similar, except that test doesn’t include the loading markup and loads the jasmine scripts and app-test.js instead of app.js.

Those familiar with either ExtJS or Jasmine can probably see where I’m going with this. Jasmine doesn’t start automatically. It has a bootstrap method that you call to run the tests and show the output. The Jasmine examples always show the test-runner.html with a script block in the body that runs as soon as the browser hits that block. This isn’t what we want for this application. Not all of the resources and code will be loaded, at least not consistently at this point. So we have the app-test.js define the Application in “test mode.” Maybe a visual is better in this case.

This is the main entry point and the app.js.

<html>

<head>
    <title>App</title>
    <link rel="shortcut icon" href="resources/favicon.ico">
    <link rel="stylesheet" type="text/css" href="extjs/resources/css/ext-all-gray.css">
    <link rel="stylesheet" type="text/css" href="resources/css/main.css">
</head>
<body>

<div id="loading-mask"></div>
<div id="loading">
    <div class="loading-indicator">Loading...</div>
</div>

<script type="text/javascript" src="extjs/ext-debug.js"></script>
<script type="text/javascript" src="app.js"></script>

</body>
</html>

Ext.application({
    name: 'App',
    appFolder: 'app',

    controllers: [
        'Session'
        /*... all your controllers here...
         * they will include your views, models, etc
         */
    ],

    launch: function() {
        setTimeout(
            function clearMask(){
                Ext.get('loading').remove();
                Ext.get('loading-mask').fadeOut({remove:true});
                resizeBlocker(Ext.Element.getViewWidth());
            },
            100);

        /* This is this application's kickstart... this shows a login
         * form if not logged in and opens the Viewport once logged in.
         * If a login/session is detected on reload, it will just open
         * the viewport.
         */
        App.controller.Session.login();
    }
});

Now this is what goes into test.html and app-test.js:

<!--
This is a Jasmine test runner. please see the wiki on how to write tests.

https://github.com/pivotal/jasmine/wiki

-->
<html>
<head>
    <title>App - Jasmine Test Runner</title>
    <link rel="shortcut icon" href="resources/favicon.ico">
    <link rel="stylesheet" type="text/css" href="app-test/lib/jasmine-1.1.0/jasmine.css">

    <!-- all your framework code here -->
    <script type="text/javascript" src="extjs/ext-debug.js"></script>

    <!-- Jasmin code here -->
    <script type="text/javascript" src="app-test/lib/jasmine-1.1.0/jasmine.js"></script>
    <script type="text/javascript" src="app-test/lib/jasmine-1.1.0/jasmine-html.js"></script>

    <!-- include specs here -->
    <script type="text/javascript" src="app-test/specs/example.spec.js"></script>

    <!-- test launcher -->
    <script type="text/javascript" src="app-test.js"></script>
</head>
<body></body>
</html>

/*
 * Define mock framework objects here
 */
var AppConfig = {host: 'test:'};

var io = {} //socket.io mock?...

Ext.application({
    name: 'App',
    appFolder: 'app',

    controllers: [
        'Session'
        /*... all your controllers here...
         * they will include your views, models, etc
         */
    ],

    launch: function() {
        hookAjax();

        //include the tests in the test.html head
        jasmine.getEnv().addReporter(new jasmine.TrivialReporter());
        jasmine.getEnv().execute();
    }
});

Next, what about those pesky server calls? Lets reroute those to our mock directory. In my application all Ajax calls use a url in a config for the host. This allows us to change the host without deploying to a new server. So, because of this, its super easy to detect a server call: its prefixed with the config value of the host and I’ve set the mock config object above to have the host set to “test:”, so here is my hook:

function hookAjax()
{
    Ext.Ajax.request_forReal = Ext.Ajax.request;
    Ext.Ajax.request = function test_ajax(o){
        if(/^test:/i.test(o.url)){
            o.url = o.url.replace(/^test:/i, './app-test/mock');
        }
        this.request_forReal.apply(this, arguments);
    };
}

In summation, what does this get us? We now have a way to isolate anything we want in the application and test the heck out of it. We can test integration of components/controllers/models, or individual components.

Bam. *mike drop*

Around the beginning of the second quarter of this year, I was invited to join a few colleagues that had left the company to start a new company, and I couldn’t resist the opportunity to start something – something BIG.  It was just too enticing.

I’ve been working at NextThought for several months now. Primarily focused on a UI design implementation for the desktop/web browser, I can’t even begin to explain how much fun this has been.  I started by playing with any and all UI toolkits & frameworks I could find.  I even began to build a UI from scratch, but why reinvent the wheel?  And time is of the essence when you’re trying come up with the “next big thing,” staying ahead in this big technology game is the only way to come out on top.  I concluded that to achieve the timely deadlines and quality of experience, I had to switch gears and go with a framework.  Re-enter ExtJS. I scrapped my first month’s efforts and rebuilt it in ExtJS in about an hour.

Poke'n around… this was fun: Ext.panel.Panel.override({render:function(){this.callOverridden(arguments);console.log('render!');}});

August 8, 2011 9:47 pm via Twitter for MacReplyRetweetFavorite

@jsg2021

Jonathan Grimes

Anyway, I don’t want to say too much now, but keep an eye on us. Good things will be coming from NextThought.  Promise.

I’ve also been busy — VERY busy — entertaining my lovely wife. In May, my wife, her parents and I went to England for two weeks.  Now, going to England with your wife = fun.  Going to England with your wife, her parents to visit her Cambridge scholar little brother = exhaustingly educational.  These people travel like they’re never leaving their house again!  This trip was so planned out and itemized, we had “breathe” built into the itinerary.  Literally.  It said “breathe” right after “arrive at Stonehenge” right before “35 minutes at Stonehenge.”

We arrived in to London on Day One, and didn’t stop touring until we got on the plane and headed home. We saw as much as we could with the help of Sam, my brother-in-law, who had been living in England for the 2010-2011 school year.  I really enjoyed all the ruins, like Stonehenge and the ruins in Bath.  Sam and Carl (my father-in-law) prefer their ruins not ruined, but I like the mystery of it all.  The castles and gardens were beautiful, spectacular really.  They should make calendars out of them.

My mother-in-law, sweet woman — she wanted to find something that I would find interesting, because she feared I would be bored with all the Medieval stuff (she couldn’t have been more wrong, I had a blast) — took us to Bletchley Park, home of the WWII Codebreakers. She certainly succeeded in finding something that piqued my interest.  Bletchley Park is the place where the Enigma machine was cracked (repeatedly, as the Germans kept modifying it), and a keystone in the history of the field of computer science, my own field of study.  Very fascinating spot. If you are into computer science or cryptography, it’s a must visit.

Sound busy? And that’s just the highlight reel.

This is enough of this detour from the normal tech/car talk. I’ll return to the normal programming in the next post.

Thanks, Carl, Nancy, Sam and my wife, Caroline, for the best “first-adventure-overseas” a guy could ask for!