Jacob Wright - Flex, AIR, PHP, etc.

Sharing my Class class.

2011-04-03T21:10:18Z

I’ve been using a little class utility to create classes for awhile and thought I’d share it and discuss what I did and why. First the goals, then code, then examples and discussion.

Goals

When I created this I basically wanted something that looked like a class instead of a function I was extending (I know, non-javascripty, but ecmascripty in laster versions), but that was still 100% native Javascript inheritance.
Looks like a class from other more OO languages
Uses native JS prototype inheritance so “myobj instanceof MyClass” still works.
Small, uncomplicated, don’t want tons of hacks and work-arounds.

Code

The most updated code can be found on github and requires the compat.js file in the same repository needs to be included for cross-browser compatibility if using in the browser: https://github.com/jacwright/jslib/blob/master/class.js

Examples and Discussion

To create a new class you new up an instance of Class like this:

var Person = new Class({
    constructor: function(name) {
        this.setName(name);
    },
    setName: function(value) {
        this.name = value || 'unknown';
    }
});
console.log(Person);

When you output the Person class you’ll see that it is actually just the constructor function. If you were to create this same Person class with regular Javascript you would get the exact same end result.

var Employee = new Class({
    extend: Person,
    constructor: function(name, title) {
        Person.call(this, name); // call the super-class constructor
        this.title = title;
    },
    setName: function(value) {
        if (!value) throw new Error('Employees must have a name.');
        Person.prototype.setName.call(this, value); // call super setName
    }
});
var jacob = new Employee('Jacob Wright', 'UI Guy');
console.log('Is employee?', jacob instanceof Employee);
console.log('Is person?', jacob instanceof Person);

Creating a sub-class is really easy. You use the word “extend” (not “extends” because that is a keyword in javscript/ecmascript) and assign it the class you’re extending. It uses javascript prototype extension under the hood. You end up with the exact same thing you would not using the Class class. You see I still call the super class constructor and methods the same as I would in normal Javascript. If you have the class in its own closure you could define a property “var parent = Person.prototype;” before the class and then change your calls to the super class to “parent.setName.call(this, value)” if you are so inclined.

You can also pass in “implement” and the methods on that class (or classes as you can also give it an array of classes) will get copied over to the prototype of this one. It is not actual inheritance so “instanceof” will not return true, and I don’t have any methods to ask if a class implements another, though that might be useful.

Statics are easy as well.

var Developer = new Class({
    extend: Employee
}, { // 2nd parameter is the static definition
    devs: {},
    factory: function(name) {
        if (this.devs.hasOwnProperty(name)) return this.devs[name];
        return this.devs[name] = new Developer(name, 'Developer');
    }
});
var jacob = Developer.factory('Jacob Wright');

Working Parts

Things I like about how it is implemented:
I thought it was stupidly clever to actually call the constructor “constructor” instead of “init” or “initialize” or whatever else other class helpers do. I don’t even have to remove it from the prototype since native prototypes define the constructor on them anyway. I only remove extend and implement from the prototype (though maybe I don’t even need to do that).

The empty constructor. You’ll see in the code there is an EmptyClass function. I use this in the prototype inheritance by assigning the prototype of the extended class to that of EmptyClass. Then I can create “new EmptyClass()” for the prototype chain and accomplish the same thing without running constructor code on the prototype object. This keeps the constructor of the parent class from getting called until you actually create a new instance of the class.
UPDATE: Using Object.create() does the same thing as using the empty constructor trick and I use that now to stick to standards.

Returning from a constructor. When a function returns a value and you attempt to create an object with the “new” operator, you actuall get back the returned value instead of a new class instance. If I were to return the number 42 from the Class function then “var num = new Class()” would give me 42 for num. You can see from the code that the Class constructor returns the impl.constructor. This is an interesting feature of Javascript and allows me to give back the constructor passed in the impl object (i.e. the prototype object) to the caller after I’ve set up its extend and implement parts.

Credits

Whether this is something useful or not I hope it is an interesting approach to the problem of OO and has helped you learn something new. I picked up the “empty constructor” trick from Prototype, the general idea of using “new Class” from MooTools, some of the implementation from ExtJS and the others, and then just simplified down as much as possible.

Client-side-only Javascript Amazon S3 CMS

2011-03-07T14:51:30Z

Amazon S3 just released a feature that allows you to host a website on S3. I’ve been wanting this feature for years and now that it’s here I can’t keep my mind off of building a CMS on top of it. There’s just so many interesting challenges to figure out and technical coolness.

Javascript Client

The idea is to build a CMS that is 100% HTML and Javascript, hosted from S3 itself. You would upload the initial files for the admin, set an appropriate bucket policy, and set up the website features on your bucket (or more likely when I’m further along put your Amazon creds into an online upload form and allow a little web service to do it for you). Then you would navigate to https://yourbucket.s3.amazonaws.com/admin/index.html and login to your hosted javascript admin. Logging would keep the key and secret in memory and you’d be able to add, delete, update, and otherwise work with your website on S3, from S3.

Benefits of Client-side Javascript and S3

There are some really cool aspects to a 100% client-side Javascript application and hosting on S3.

The biggest IMO probably being pluginability. Most people can write Javascript and many know jQuery, so writing plugins that utilized both to extend the interface, respond to actions, and otherwise modify the system would be easy and allow for very customized web admins and sites. You also have a built-in REST API that you can store anything to. If you want to add TODOs to the cms, you can store them in /api/todos/ immediately without having to create a new database table and worry about setup. You can also update your TODO plugin later to include priority without needing to update tables.

There is also the draw of high-traffic websites not hitting any servers you have to worry about. Let Amazon deal with the hosting and meet their “99.99% availability”. You can handle massive load. And it’s cost-effective. And stable/redundant, you don’t need backups. And you can front the whole thing with CloudFront to deliver your pages at the closest locations possible (you’ll have to invalidate pages that get updated though).

Drawbacks

It’s hard to have dynamic websites without server-side logic. You can’t accept comments on your posts. You can’t resize images on the fly or even at upload time (well, with canvas, but that’s something to research more on viability). You can’t send out emails. And you can’t utilize cross-site resources or APIs (such as CloudFront or Akismet). However, if this cms turns out well and people use it, I can create a service that will allow all of these things for registered users.

Previous Work

When looking around for an S3 Javascript client I found that back as far as 2006 people were thinking about building Javascript applications hosted from S3. It didn’t really seem to take off, but there’s a lot more work that’s been done on S3 since then. It might be more interesting now. Especially if some general hurdles are figured out so that your site isn’t hacked, spammed, and ruined.

Security

My first and biggest concern for something like this is handling security. How does one have an all client-side application and still allow secure login and user management? The first thing that comes to mind is the obvious: why not have the user enter their Amazon key and secret to login? That’s a good idea. At least, it will work. Using a the bucket policy file we can specify an area of the site that is private for reads and writes which can store website data (all of it will be private for writes). But if this is going to be something I use, I don’t want to go look up my amazon key and secret every time I need to log in. So I brainstormed other solutions.

AES

I need 2-way encryption that will allow me to store the amazon key and secret in a public location. Public because you can’t access it before you’re logged in now can you. The most secure 2-way encryption I found was AES which is used in government and many other places. It is quite secure and wonderfully Movable Type has implementations of AES and SHA1 and lots of other stuff in Javascript.

A user will register with a username (or email), password, amazon key, and amazon secret. The password will be used to encrypt a string of “username:key:secret” and saved to a public file by the sha1 of the username under the private folder api/auth/. Having the folder private will prevent people from seeing what is in it. You’d have to guess the sha1 to even get the file, and then you’d have to know the password to decrypt it. After registering, a user can login with their username and password. The username will be sha1′ed and the user file will be loaded (if it exists). Then the password will be used for deciphering the contained hash and the key and secret put safely away inside a Javascript closure in memory.

This seems quite secure. For one, the username and password never even go over the wire, so even if we weren’t going to use SSL (which we are) the only thing a man-in-the-middle would see is the encrypted AES hash. If anyone has better ideas or sees holes in this I’d love to fix it up more securely.

Features

My other main concern is whether one could really support many features of a common web cms with only client-side logic. I’ve been quite surprised at how many features I’ve thought could work with simple Javascript. Here is a list of those I’ve thought of so far:

Templates: pages, content, templates, etc. could be stored in the api and whenever you update a page, jQuery can put the content into the template and save the whole file out to its location. Templating would be similar to other systems except that when you change the theme or update the template it will have to re-process each file that uses the template individually.

Plugins: plugins would work by attaching onto hooks or listeners throughout the system or adding new editable-field types. They could add HTML to the admin to include new buttons or menus. And their javascript could be concatenated and minified into one plugin file that gets loaded at runtime whenever you activate a new plugin, then you have one small file to load when you log in.

File upload: it turns out you can sign a form a certain way in order to upload files to S3. This is great since you can’t load (in all browsers) files into Javascript first and then sign them and put them to S3. So lage images, video files, etc. can be done without passing through Javascript.

Blog support: you can easily do a blog by recompiling the home-page template whenever you publish a new post. You could even recompile an RSS feed client-side and put that to S3 at the same time.

Shared content: menus, footer content, and other shared content could work, just like when editing a template. Any page that piece of content is shown on will need to be recompiled, however this could easily happen in the background with a little progress indicator while you continue editing or modifying your website. If you try and close up shop before it is finished the admin can warn you that leaving the page will leave your site partially undone.

Additional users: you could either 1. give access to another user’s amazon account to edit your site and let them register using their amazon key/secret, or 2. you could add more users with username/password using your amazon key/secret which will create their “auth file” using those creds. They would never need to touch your key/secret, although they could find it out, so don’t use this method with people you don’t trust.

Remember me: you could store username/password in a cookie for “remember me” functionality. If you do this then maybe using the sha1 of the password to encrypt the AES cypher and storing the sha1 password in the cookie would be a better idea. Keep that thing as safe as possible. Though unsafe plugins could take either version out of the cookie and use it to obtain your key/secret. Maybe use a separate path for login since cookies can restrict on path? Something to think through more.

Code highlighting: code or syntax highlighting can be done at save-time using the Google Code Prettifier project or another Javascript-based project of similar sort. It would just be a plugin.

Content: you can have all the same content other CMSes allow: html, js, css, flash, images, galleries, xml, etc. E.g. use a Javascript plugin to create the XML that your Flash photo gallery needs to run.

Versioning: you can use S3′s built-in versioning to keep every version of an object saved to the bucket and revert back to an old version if desired, or undo a delete.

Open Source

This is something crying out for open source. It has been really fun to start and should be really fun to continue working on. I’ve put the beginnings up on github calling it Static Site, since it is hosted on S3. Should I call it S2? :) I also have staticsite.org hosted from my own S3 bucket which will be using the CMS as it comes along. I hope to steal a moment here and there from my busy work schedule when I need a break in the evenings to keep working on it.

What do you think? Would you use it?

Into the swing of Javascript

2011-02-22T03:18:25Z

My last post was a long time ago. I’ve been busy. Unfortunately rather than being some interesting article occupying the top spot on my site it has been a short bemoan of missing Flash. I still miss ActionScript 3 from time to time, but I’ve really been enjoying Javascript development, both in the client and on the server. There have been a couple things that have made it more manageable to me. I want to share.

Multiple Files

One of the hardest parts of heavy Javascript starting out was fitting everything into a few files. Being used to a-class-per-file with ActionScript has made cramming a whole application into two or three files quite unorganized, no matter how commented the code. I know combining Javascript files isn’t a big deal, but what really made it work for me is when I integrated it into my IDE workflow (I use IntellJ which has the best Javascript intelligence I’ve found in any IDE—WebStorm would be the same, without as much bloat). I have a maven script that uses YUI Compressor (could use Ant easily as well) and it is set up to my Cmd+S key-binding so whenever I save a Javascript file it saves the file and recombines the rest into one file. A downside is that I have to be cognizant of what order (dependency-wise) the files go in and to be sure to add them to my maven script as I add new files. I’d like to look at Google’s Closure compiler which allows the use of a require() method to include scripts and figures out dependency for you when putting them together. This would be nice.

Realistic Classes

Getting a simple Class utility put together that makes creating classes more readable but still uses does it “the native way” under the hood has made class structures enjoyable. I use a modification of my simpli5 class utility (I don’t use the rest of simpli5 much however since we’re still not completely HTML5 yet). Consider the difference between the following:

function MyClass(state) {
    this.state = state;
}
MyClass.prototype.doSomething = function() {
    this.state = this.state + 42;
};
// versus
var MyClass = new Class({
    constructor: function(state) {
        this.state = state;
    },
    doSomething: function() {
        this.state = this.state + 42;
    }
});

I think it is much more readable.

Packages

I also use a form of package management, and I wrap all my files in function closures so I don’t clutter the global scope. But I hate always referencing Classes or package-level object and methods with their full package name, so I use imports…sorta.

(function() {
    // imports
    var Class = mypackage.Class,
        OtherNeededClassOrObject = mypackage.somepackage.ClassOrObject,
        subpackage = mypackage.subpackage,
        MySuperClass =subpackage.MySuperClass;

    subpackage.MyClass = new Class({
        extend: MySuperClass,
        constructor: function() {
            MySuperClass.call(this); // super(); in Flash
        }
    }, {
        /*statics*/
    });
})();

I’m quite happy with the setup I’ve established, using separate files, classes, and package management. It keeps it close to how Javascript works without any “magic” or hacks, and it makes my code much more readable and manageable to me. I’ve also borrowed a few ideas from backbone.js for a base Model class that will load data from my APIs. I didn’t need the rest of backbone for this project so just used their ideas, but in future projects I would consider it.

Happy coding!

I miss Flash

2010-09-25T03:46:32Z

Javascript can be fun, but I miss Flash. I miss having packages. I miss having private, protected, and public variables. I miss having getters and setters. I miss the organization of a Flash project. Javascript is so messy, even when it’s done well.

Mostly, I miss the Flash community.

Don’t worry duders, I’ll be back.

In-memory Javascript Database

2010-09-23T17:00:54Z

I wrote an in-memory Javascript database for a project at work. “What?!” you say? You heard me. In-memory…Javascript…database. Yes, there is a use-case for it.

So our current HTML5 project has moved back its target coverage to IE8. Darn. No CSS3, standard event model, or implicit getters/setters (meaning no data-binding). But it still has localStorage and sessionStorage, the ~5MB data store that an HTML5 app can use. So I wrote a JS database which is really just an array of objects with some easy API for filtering, sorting, limiting, and finding the object you need. Now I can store a bunch of data in memory, getting only the newest content when I poll the server, and much more quickly sort, filter, etc. the data for the user without round-trips to the server. And then when they close the app, I can JSONify the data in the localStorage and load their app much more quickly when the come back. They’ll immediately see where they left off, then when the first server poll finishes they’ll see they’ve got unread items that they can scroll up to view.

I found taffydb.com already existed, but I sure hate unreadable code, and I thought how I could make it faster using the built-in Array filter() method. So I built my own. I also added a full-text search index that can be used for finding based off of keyword matching. I’m working on refactoring for a different query API that supports ORs and sub-expressions–or expressions within parenthesis (e.g. name == “Jacob” and (age == null or age > 10) and cool == true).

Follow the progress of JaDE (Javascript Database Engine) on github.

Reintroducing – Flight Stealth!

2010-09-22T20:04:17Z

Flight Stealth was a Flash component framework a year ago. It went away as the creators of Stealth and OpenFlux combined to create Reflex last year. But Stealth is back! Reflex is forked.

There has been some disappointment that Reflex has forked. Many people have ignorantly but understandably attributed the split to Tyler, the project lead over Flight Stealth. However, Ben Stucki was the one who wanted to fork. After deciding to fork and leave Reflex he asked Tyler if he could keep the Reflex name. Tyler graciously consented, deciding to use the old Stealth name, but since the only difference in a new fork is the projects’ names, he’s gotten the short end of the stick, losing mind share, and for those who were against the fork, getting the blame.

I believe both projects will move forward as a result of this fork. Their project leads each have a vision and direction in mind, and I’m seeing the difference in goals will lead to different products and needs addressed by the projects. Although as Flash developers who currently only have one robust component set in our tool belts, it is hard to imagine the need for more than one alternative. However I believe we will find that one-size-fits-all is not an ideal goal and a specialized framework will always win out over a generic one in its own problem domain.

Good luck to both projects and make us proud.

As an aside, I designed the flightxd.com website where Flight Stealth will be hosted. I am quite proud of what I did, not being a designer.

Please join the Stealth mailing list and find out how you can help. We have a website to put together, user docs that need to be written, components that need to be written, and much much more.

Type overloading in Javascript

2011-02-22T03:16:29Z

One of the core aspects to the Simpli5 Javascript library is that the components you build don’t wrap DOM elements. They actually are DOM elements. This is accomplished using what I call type overloading.

How it works is you take an HTML element in the DOM and make it a different type. It is important–or maybe just ethical ;) –that this new type is a subclass of the original element type. You don’t want to find out that a div is no longer a div, and Firefox has issues with this anyway. So how do you type overload? First create your new type.

function MyDiv() {
    this.addClass('my-div');
}

Then it needs to extend the HTMLDivElement type. There is a trick to this using a dummy type.

function dummy(){}
dummy.prototype = HTMLDivElement.prototype;
MyDiv.prototype = new dummy();

Then we can add methods to the MyDiv.prototype which we may later call.

MyDiv.prototype.addClass = function(className) {
    var classes = this.className ? this.className.split(/\s+/) : [];
    if (classes.indexOf(className) == -1) classes.push(className);
    this.className = classes.join(' ');
};

Now we have our new type. We can’t just create it because to get an HTML element you have to go through document.createElement(). We can either do that or grab an element already in the DOM. Let’s do the latter.

var div = document.getElementsByTagName('div')[0];

Now we have our div. The next part is type overloading. On every Javascript object is a special property “__proto__” (two underscores on both sides) which points to the object’s prototype. It also has “constructor” which points to its type function. We just have to replace these two with our own, changing the type of the object at runtime.

div.__proto__ = MyDiv.prototype;
div.constructor = MyDiv;
div.constructor(); // call the constructor for any initialization that needs to happen.

We now have a div which is of type MyDiv. The following code all returns true and works.

alert(div instanceof HTMLDivElement); // true since we subclassed it
alert(div instanceof MyDiv); // also true since this is our new type
div.addClass('foo'); // works, no errors, the method exists on div
alert(div.className); // "my-div foo" because our constructor added my-div and we just added foo

It’s a really neat thing that you can make objects become new types at runtime. And since every HTML5 browser supported it at the time I wrote Simpli5 it seemed like a great solution. Unfortunately, not all browsers support the __proto__ property. Now that IE9 is publicly available in beta I’ve given it a look. It does not support __proto__. After all, __proto__ isn’t a standardized property. So for Simpli5 I’ll have to for-i-in copy all the methods of my new type over to the instance of an element. It will be slower, and “div instanceof MyDiv” won’t return true, but it should still work for our needs.

Hey Microsoft, I know it isn’t a standard property, but do you think you could make the __proto__ object a publicly accessible read/write property? I would really appreciate it!

Runtime Performance with CSS3 vs Images

2010-07-30T20:57:15Z

I’m pretty happy with the great stuff CSS3 (and HTML5) brings. However, some care should be taken in balancing how many images you load versus the load you put on the CSS engine. And there are a lot of articles on the web encouraging use of the new CSS features such as gradients and shadows in order to optimize for images in your page. But that’s only half the story.

Image Optimization

CSS3 allows you to add drop shadows to your elements, gradients as their backgrounds, and rounded corners on their… corners. Using these few capabilities (you might throw in a couple more like custom fonts and you can put together much of the web’s design with only a few icons needed for images. This allows for much smaller page download because the definition for a shadow or gradient is only a few bytes but an image of these same things are usually kilobytes larger. Pages download much more quickly.

CSS Optimization

While you can do lots of great things with CSS3, drawing shadows and gradients dynamically can affect responsiveness in your page. If you find your page is not scrolling smoothly or dynamic pieces don’t pop like you’d want them to, you might want to optimize your CSS and use more images. Your page may download slower, but once it’s there it will be more responsive.

Case-study on Page Performance

I had a page with a lot of these gradients and shadows (see the previous picture, the original version was 100% CSS, it had no images at all), however, scrolling the page left and right was very clunky and unresponsive. I thought perhaps I had too many HTML elements on the page, but I’ve seen much more work better. After playing around with code a bit it occurred to me that the dynamic calculations and drawing of the gradient’s and shadows was affecting performance. This should have been more apparent to me since it is a common optimization in Flash when you use too much drawing API. After removing the shadows and gradients from my stylesheet the scrolling was smooth again, just like I would expect it to be. Removing the shadow helped out a lot more than removing the gradients. I theorized that the browser may have a better time layering images than it does calculating shadows and gradients, so I tested it out.

After replacing all the gradients and shadows with images, I found my page still scrolled smoothly even though the same shadows and gradients caused it problems with CSS. For my particular case, I am creating a web application which users will come to and stay at for awhile. There is a lot of elements on the page, a lot of design parts to it, and in this particular developer-art incarnation of it, a lot of shadows.

On a side note, the process to replacing the CSS shadows etc. with images was much less painful with CSS3. I didn’t have to alter any HTML because you can layer backgrounds onto an element now so my elements had- background: url(topimage.png) no-repeat left top, url(bottomimage.png) left bottom, url(middleimage.png) repeat-y left; So even though I was forgoing CSS3 shadows it still made my life easier and my page simpler with the images.

The Right Balance

For many web pages out there adding a few shadows or gradients to the page will help make your page look that much nicer and doing it in CSS3 is easier to tweak when you don’t have to re-export images from your site-design-file. But if you have performance problems in your page, you might try using images for some of the heavily repeated elements or the shadows in your page.

My First 10k, Trailer Park Style

2010-07-29T15:05:34Z

I am finally getting around to sharing my memorial day adventure. I ran my first 10k here in Boulder (called the BolderBOULDER). It was pretty fun, considering I wasn’t in great shape for it. I outdid my expectations (I’m slow) with a 68 minute time. Our Jive team running the BolderBOULDER (voted best 10k in the country) planned out a sweet running uniform: jean cutoffs, wife-beater, Jive tattoo, fake mustache, and anything else that screamed “TRAILER PARK!”

UNFORTUNATELY, I was the ONLY one who really followed through on the whole outfit. Guess that means I’m totally the winner in the style category. Here are some photos to commemorate the event.

Starting out

Just gettin’ going

Getting cooled off

Breaking a mile barrier

Home stretch

After Pose (mustache finally fell off)

Developers Put Their Heads in the Sand

2010-07-23T19:45:29Z

As developers, we like to put our heads in the sand. We’d be much more successful if we didn’t. Let me explain.

When I first learned about basic object oriented programming, I was suddenly disgusted with functions and code that wasn’t an object. I got over it.

When I learned about composition over inheritance, that became the standard by which I judged all code, mine included. It became my fixation. I got over it.

When I learned about design patterns, I wanted to apply them to every situation, and I wanted to do it right and apply them exactly the way prescribed in the pattern. I got over it.

When I learned about optimizing code, I spat on for loops that didn’t initialize the length first, I kicked dirt around static methods which are shown to be slower (in the language I was using) than instance methods, and I generally despised any type of code which I read on a blog was slower than an optimized alternative. I got over it.

I could go on with dependency injection, abstraction, database normalization, and on, and on, and on. I hope I continue to get over over-applying new knowledge.

I’ve always wanted to iterate over and rewrite again and again pieces of code, reusable libraries, and other gleaming nuggets I’ve done in the past which could be more perfect. Even faster. Even better. I’m getting over it.

In the last few months I’ve been working with some very bright and pragmatic developers. They’ve been teaching me, unbeknownst to themselves, to look at the big picture and to get my freaking head out of the sand.

Just because instance methods are slower than statics doesn’t mean you shouldn’t use them. Creating an object is slower than calling a method, but should we throw OOP out the window and stick with functional programming? Messing up the Flyweight pattern (or even heaven forbid, our blessed MVC pattern) by altering it from the original and all knowing gang-of-four specification doesn’t end-of-life your product before it’s out the door. What keeps your product from releasing is rewriting it, or pieces of it, over and over again. If it works, DON’T FIX IT. Only optimize if your application is too slow for your users. And then only optimize the slowest parts. Next application you write you can do it better, but freaking finish! Clean up and refactor as you add new features for your users. Don’t waste time redoing anything from scratch unless its complete junk. And if you wrote it, figure out why you’re writing complete junk in the first place and fix the root of the problem.

I’m writing a library in Javascript for HTML5 applications that I know will make many Javascript developer weep. It flys in the face of all the wisdom and standards that they’ve read about on their favorite blogs. But it will make developing applications easier and more maintainable. I know the rules, and thus I know how and when to break them because I know why they were established.

I’m still watching the development of Reflex, the Flash component library my brother is involved in (I’m not actively participating anymore). They’re fighting against head-sand-itis both externally and internally. Project supporters may disagree with things proposed because it’s not right, or it’s not as fast as machine code. Internally with themselves they’re disgusted at breaking precious programming rules. Finally they’re starting to let ideals slide because progression is so slow. Eventually, I hope, they’ll raise their sites to the end goal and do what is necessary to reach it. Even if it means using brains instead of rules. (no offense to any individual person or the general group, we all struggle with it, we’re developers)

The rules are generalities, guidelines to help us until we understand the principle behind the rule well enough to make our own decisions. Understand your natural tendency to over-apply and work against your nature to be more pragmatic.

May we all work on seeing the big picture, understanding the principle behind the rule, and creating great experiences for those who will use our applications. I’m certainly the pot calling the kettle black on this.