seanmonstar

Sep 30 2013

intel

A couple months ago, I was blagging on about logging libraries in nodejs. After pointing out how annoying it is to use logging libraries with 3rd party modules, I declared that all modules should simply use console.log(), and let applications hijack the console. Then, I looked around the npms, and couldn’t find an excellent example of a logging library that embraced that idea.

So, clearly, that meant I needed to write my own. It’s called intel. Why another logging library? Well duh, cause this one is better.

Loggers get names

Before nodejs, I came from Pythonia. Over yonder, they have an excellent logging module as part of the standard library. It’s glorious. It uses hierarchal named loggers. Winston, the library we currently use in Persona, while being perfectly awesome, doesn’t have support for this. It does allow you to define Containers and Categories, but it’s not as powerful as I’d like.

Specifically, intel adds 2 noteworthy features to Loggers: hierarchy and humane setup.

  1. Loggers use an hierarchy based on their names. Logger foo.bar is a child of foo. So is foo.bar.baz. When a logger receives a log message, after handling itself, it passes the message up to its parents.

    For instance, you could decide that all log messages from foo should go to the terminal. However, your foo/bar.js module has some critical code you want to keep tabs on. You could add a handler to the foo.bar logger that sends all messages of WARN and greater to email. After that handler, foo.bar will hand the message to its parent foo, and also send it to the terminal

  2. Of the other libraries I could fine that supported multiple named loggers, they all required that you instantiate the loggers with all options ahead of time. This adds more friction having a named logger per module in your app. Instead, intel makes it super easy for you get a new named logger.

     var logger = intel.getLogger('foo.bar.baz.quux');
    

    You don’t have to have added any handlers to your newly minted logger. It will just pass the messages right up to it’s parents. The messages will still keep the name of the originating logger, though.

Powerful configuration

Named loggers allow for really powerful yet easy-to-use logging. Combined with a little bit of configuration, and it’s all magical. You can setup a couple root loggers, with various levels pumping messages to various handlers (Console, File, Email, Database, etc). You can see an example in the docs.

Infiltrating the console

The motivating reason I started intel was to do exactly this. I want my apps to have the power to configure logging just the way I want, and I want all my dependencies to play along with my logging rules. So, after you setup your loggers and handlers, you can inject intel into the global console object, and watch as any dependencies that use console.log follow your rules, and automatically get assigned the correct names.

 intel.console();
 intel.getLogger('patrol.node_modules.express').setLevel(intel.WARN);
 // in express.js
 console.log('new request'); // automatically gets assigned to patrol.node_modules.express logger.

intel

I’m starting by a 0.1 release of intel. Any bugs or feature requests can filed in the issue tracker. I don’t want intel to be one of those libraries that is forever sub-1.0. After some use in the wild, with bugs being fixed and possibly APIs being made better, I’d like to get to a 1.0 soon.

So, try swapping out your current logger for intel. Name some loggers. You’ll come around.

Oct 29 2012

An Expandable PC

Recently, there’s been this idea that we’re in a “post-PC” era. That the PC is no longer relevant, it’s all mobile now. I’d argue that the most “PC” PC I’ve ever had is my phone: it’s a computer I have on my person at all times. And while I agree that our PCs are now these hand-held devices, I’ve always loved having my monster desktop ready to crunch all computing challenges I could throw at it.

As computers have gotten smaller, we’ve also seen that desktop computer performance doesn’t need to improve any more. When friends ask me what to look in for a laptop, I tell them the processor and such don’t matter; look for battery life, weight, and quality of input devices (keyboard and trackpad). We just don’t need more power to answer our email, click on Like buttons, watch cat videos, and fill out spreadsheets. The power on hand-held devices, however, is starting to reach that threshold where it’s adequate to do everything as well.

So when I see other people mention the same ideas bouncing around in my head, I’m sure we have to be getting close:

Jeff Atwood:

Our phones are now so damn fast and capable as personal computers that I’m starting to wonder why I don’t just use the thing I always have in my pocket as my “laptop”, plugging it into a keyboard and display as necessary.

David Pierce:

I can drop my Series 7 tablet into a dock, add a Bluetooth mouse and keyboard, and connect a monitor — poof, I’ve got a full-fledged dual-monitor setup going. When I want to go somewhere, I just pick the device up out of the dock, and walk out the door tablet in hand.

This is exactly what I want. I love my smartphone, because it’s always with me. And I love my desktop because it’s so much easier to type on a full keyboard, have decent speakers, and use multiple big monitors. I don’t necessarily need the giant Tower part in the middle1. What if my phone or my tablet was the computer at my desktop, with all the useful peripherals plugged into it?

Microsoft’s Surface and Windows 8 feel like a prime candidate for this experiment. It’s still got Windows, so I can still do my usual work of testing in browsers, writing code, playing with git, and the like. There would be no obstacles to productivity even, since I’ll be using my laptop and monitors. And then, when I’m done, and want to go into the living room, or hang out in Starbucks to get my people dose for the week, I can just pick it up and go.

I realize that many people have been doing that with laptops for years, but I have never been impressed by it. I certainly don’t bring my laptop to the couch to casually use between commercials. And it’s extra space that is needed means I need more space (and a power cord) when I leave the house. Plus it weighs at least double, more like quadruple what a tablet weighs.

The Surface is now out, and while it remains to be seen if it is the right fit for this expandable PC, it certainly looks like the closest product yet. We’re not too far away from a time when tablets replace everything.


  1. I do, actually, since I compile code, and run massive test suites, and I don’t want those going any slower than they do. Plus, gaming. 

Feb 21 2012

The Shipyard Mindset

I’ve been working quite a bit on this little JavaScript MVC framework called Shipyard. Those who know me may recall that I used to write a lot about MooTools, and may wonder why I’ve moved off it and am writing my own framework instead. I figured I’d take the time to explain why I felt the need existed for Shipyard, and the goals it tries to accomplish:

  • Being truly modular
  • Command line tests run after each save
  • Easy access to data from various sources
  • Auto-updating views

Let’s get to it.

Modularity

JavaScript has a tendency to turn into spaghetti pretty quickly, what with the callback parties and people saying it’s “just a scripting language”, applications tend to lack structure. MooTools has had a modular design from the beginning, by separating pieces of functionality into individual Classes. This concept has carried over into Shipyard, but Shipyard does so much more.

With other frameworks, such as MooTools or YUI, developers are asked to pick the components that they want to use when downloading the library. The goal is that people only ever download the JavaScript they need for their application. Unfortunately, people usually just download the full “default” build, that contains everything, because they don’t know what they want yet. It’s certainly a pain to try to be smart about your selections at first, and then later realize you need to download a couple more modules (plus all their dependencies) mid-development. So most people download the entire thing, and never chop out the unneeded afterwards.

Shipyard says that you should download the entire thing from the start. Download the entire repo, all the modules. As you write your application, you specify your dependencies naturally in each module (using require), and so you never need to look at a list and pick what you think you might one day sort of use. It’s all there on your computer, and you just use it naturally. When it comes time to ship to production, the build step (you’re already minimizing anways, right?) that comes with Shipyard only bundles the dependencies you specifically used. Shipyard takes an active stance in reducing the amount of wasted bytes that your users will have to download.

Testing

Testing is great. It’s the law. It’d be a good idea. Something like that, right? In many other frameworks, it’s very easy to write test suites for your applications, but JavaScript applications are strikingly absent of tests. Part of the reason is that many test frameworks make it difficult to test. I need to be able to test with the simplest of commands. Even have the possibility to test on a pre-commit hook, or even per save. That means testing needs to be easy, and fast. If it’s not, it just won’t happen.

Automatic tests run after each save in JavaScript, you say? But it’s hard to test JavaScript from a command line, because you need to test in browsers, right? Well, yes, you should do that too, but so much of our JavaScript applications nowadays is code that has nothing to do with the browser. So much of it can be isolated and tested in units. And while you should browser test your application as well, if a test breaks on the command-line, you know it will break in the browser before even having to load the test page. Fail faster.

Shipyard helps do this by makng it’s test runner run with nodejs. With the strict usage of the dom module whenever touching anything global and DOM related, the test runner is able to make the dom module work in nodejs with the help of jsdom. So you can actually test expected DOM behavior from the command line, each time you save your file.

You could even put your JavaScript test suite on CI, similar to how Shipyard’s own test suite runs on travis-ci with every commit.

Model Syncs

Getting into the more MVC part of Shipyard, I had explored this idea of various sync locations with Models before. The idea is that applications have data, and we structure it with Models. The data comes from somewhere, and while it used to only ever come from the host server, increasingly it is coming from various sources. A common example that would benefit from this is an application with offline mode. You need the data of your models to sync with the server, but if the user is offline, you want the data to save locally, perhaps in localStorage or IndexedDB, and then be able to send the data to the server at a later point. Perhaps you want to cache the data in localStorage, and so when the user comes back to your site, you first look there, and then fall back to asking the server for the data.

It should be as simple as:

Recipe.find().addListener('complete', function(recipes) {
    if (recipes.length === 0) {
        Recipe.find({ using: 'server' }).addListener('complete', listRecipes);
    } else {
        listRecipes(recipes);
    }
});

Shipyard makes it so.

Automatic Views

The DOM sucks. It’s powerful, but it’s complicated, and has inconcistencies. I don’t think developers should have to touch the DOM, in most cases. Instead, Shipyard exposes Views. They’re kind of like Elements, but far more powerful. Specifically, Views can be made up of several elements, and not bother you about it. As well, you don’t have to fret over which of those elements needs event handlers, you just listen to events from the View itself.

Even cooler is the idea of binding data to Views. My first foray in JavaScript MVC had me re-rendering entire sections of the DOM when things had changed. Not only is that weak, performance-wise, but it’s boiler-plate that I had to worry about. You can end up with several places in your UI that reflect the same data, shown in slightly different ways, and then you’re left with remembering each place when you offer a new way to alter the data. Of course the UI should update when the data changes, I just shouldn’t have to remember that myself. I am only human, after all. Other frameworks have this (I met it when using Adobe’s Flex Builder), and so does Shipyard.

Choo-choo

If you were nodding when reading the above, then get on the Shipyard train. Development continues strongly, it already powers a big application, and I hope it works out for you.

Aug 4 2011

Good Things Come to Those Who Ask

Maybe you’ve heard the saying “good things come to those who wait.” That’s all well and good, but I’d like to take some time point out that good things also come to those who look for them. I changed jobs at the beginning of this year, and several people I know were curious as to how I managed it. It’s because I asked. I sought. For months.1

In and Out

Most of my professional life has been like this. At my first job, I happened to work at In’N’Out. I thought I was going to be in the service industry for the rest of my life. It was my living, and every pay raise meant more of a living. It took me 4 months to get 3 promotions. The next promotion took longer only because the skill required was much tougher. There were some other employees around me that would complain and murmur. Most of them had been working there for much longer than I had, and yet I quickly passed them by. They had no idea why I had gotten promoted so quickly.

I asked for them.

In order to get promotions, you had to work on the next skill. You had to be good at it (which only really took hard work), and you had to have a manager write up a review. You needed 4 passing reviews to be eligible for the next promotion. So every day, at a less busy hour, I would ask my manager to put me on the next station, and I would ask for a review. They would often forget to pay attention enough to give me a review, but since I would ask so often, I rather quickly gained all my reviews for each level. The other employees? They just sat around, some working hard, some hardly working, thinking that the manager would one day put them on the next position. They thought they’d get their promotions eventually, by waiting.

Entering the Tech World

Eventually, I started to wonder if I could put my programming knowledge to use in a professional way. I scoured Craigslist, and eventually found a nice listing that didn’t require me to have a degree, instead only requiring that I pass some programming challenges. I showed up and passed all the challenges. However, the CEO was busy, and didn’t pay much attention to my application status. So, I called the executive assistant of the office, and asked to remind the CEO of my application. Every day. Finally, one of those days, the assistant replied back that my persistence paid off: the CEO had considered my application, and was preparing an offer letter.

'Expect to be a slave'

Fast forward a little, and I was at my previous company. I loved it there. The guys rock, and my job was almost always interesting. Only a few things about it killed me. It tried to be a SaaS company, and I had done a lot of work on that application. I love application development. However, since the revenue from the subscriptions revenue was growing too slowly, the company had to revert to servicing clients to pay the bills. That meant my job had largely changed from application development to brochure website CSS development. I personally find that less interesting, and the clients tend to be frustrating. At the same, while we had put a lot of work into the software platform, very few people were using it, and hardly any were appreciating it.

I spoke to someone during the summer of last year about wanting to be in a different place professionally. I had hopes and dreams about how we as a company (myself included) could focus on areas that would make us better, and have more fun at the same time. I was advised that I’m young, and I’ve got several years to go before I should expect to be at a good place. I’m in the years of having to slave away. That isn’t the first time I’ve heard such a notion.

As I left school, and headed into the working class, my father mentioned that right now I should expect to be a slave to my work, so that I could eventually be in place where I don’t have to. Friends, roommates, and colleagues have tried to pound this idea into me ever since, and I’ve just been too stubborn to believe it.

Moving On

After a severe car accident, the combination of the higher bills, my boredom, and uncertainty of my job security got me looking for a different job. I researched companies that I would love to work at, sent out resumes, customized cover letters, and did plenty of phone interviews. After several months of looking, I started to wonder if I should just stay content with what I had, because it takes a lot of effort to continuously job search.

Thankfully, I kept looking and asking, and found a new rockin’ place to work at Mozilla. I started contracting in January 2011, and hired full-time in April. I work on Add-on Builder, so my desire of making an application that many people use is satisfied. I work with very awesome people, and for a company who wants its products to be the awesomest they can be.

Don’t be afraid to ask

I don’t say all of this to brag, or say “look at me”. I want to give an example of how it is possible to get what you want. People who get what they want, get it because they aren’t quiet about wanting it. Don’t be afraid to ask about what you need to do to get to the position you want. Ask your manager what you could improve on to get a promotion. Or ask that company you’ve been eyeing to hire you. You have to assume you are a good fit for the job, and then ask for it2.


  1. What follows is a bit of life story, including only the bits where I asked and asked for something better. 

  2. It should go without saying, but I must say it anyways: you must also be hard working and decent at what you do. 

Sep 29 2010

The Galaxy in Review

I’ve had my Galaxy S (the T-Mobile Vibrant model) for about two months now, and I wanted to spell out my impressions.

The Screen

The screen is gorgeous. Granted, it’s not as bright as the iPhone 4, but I, personally, don’t really notice the difference in the Retina Display that the 4 carries. It’s Super AMOLED screen beautifully renders Avatar that comes on the phone, and the pretty wallpapers that come on the device. Contrary to my wife’s myTouch, I can operate with the brightness at the lowest setting most of the time. I only ever turn it up when I’m outside, and have my sunglasses on. The good thing is, turning the brightness to the max makes it very easy to see everything on the screen while boldly confronting the elements.

It’s also a fantastic 4 inches. Which is, again, great for viewing movies, but also great at viewing websites, or just plain reading. Reading is quite the pleasure on this phone. I’ve picked up a nightly habit of reading from my Instapaper account1 before falling asleep.

I’m one of those people who doesn’t break his stuff: none of my previous phones broke, and I only have a small handful of scratches from dropping my Sidekick once or twice. So, therefore, I don’t have a screen protector. The screen still has no scratches at all. Nothing. According to more abusive readers, it seems to stand up to a lot of punishment.

Multi-Touch

As with all Android phones since Google turned on multi-touch support, the Galaxy supports it. And from the videos I’ve seen of it on the Nexus One, it seems like the Galaxy does it better. The Nexus showed some issues with tracking multi-touch when your fingers crossed axes. No hiccups here. Pinching and pushing feels like gliding.

Touch Buttons

So far the touch buttons seem to work out just fine. I don’t have the same issue that Nexus One owners have reported where sometimes touching near the bottom of the screen triggers the touch buttons. My only gripe, is that sometimes, mostly when reading at night, the LEDs turn off after no input for a few seconds, and I need to touch the main screen before they reappear. I fail too often when guessing that I’ve clicked a button when the LEDs are off. But I guess I can’t call that much of a complaint.

Otherwise, they’ve been perfect.

Size

Again, with the 4 inches, it feels great. It doesn’t feel too big; it feels just right. Picking up an iPhone 4 feels just a little too small. I can’t imagine typing on a smaller screen.

It’s also ultra thin, only 0.4 inches. It fits perfectly in my pocket.

Weight

The Galaxy weighes a mere 4.16 ounces. According to Apple, the iPhone 4 is only 0.6 ounces heavier, but I recently compared both at the Apple store, and it felt sufficiently heavier. Granted, the iPhone also feels more solid. Some people really like that, but of the two, I enjoy a lighter device, and have no worries about breaking my Galaxy.

TouchWiz

TouchWiz is what Samsung is calling their custom UI. While I don’t understand why hardware companies are trying to write software better than a software company, this one isn’t too terrible. They have a cool gesture in the Contacts list to swipe left on a contact to call and swipe right to text. The way the application drawer works is pretty neat as well, where it has multiple pages of apps instead of one giant scrollable view.

That’s all the positive words I can muster. I said it wasn’t terrible, but I almost immediately switched to a different home launcher.2

I’m not the biggest fan of the entire UI being given a blue theme, but I don’t hate it that much either. That’s mostly just minor aesthetic taste. Yet, with their questionable surgery, they’ve ruined some of the core Android applications. Contacts no longer has a Favorites tab. Instead, they have an Updates tab. They also ruined the Calendar app. I mean, it’s not horrible, but the way they show full day events is hard to notice, and in the stock calendar, you could tap on an event in the week to reveal a small tooltip of the title. Samsung decided you should skip that tooltip.

Speaking of the Updates tab, it seems that most manufacturers feel the need to make the Android UI integrate more with social media. It makes me die a little with each new “custom UI”. Maybe less nerdy people than myself will just setup the Feeds & Updates widget to pull in Facebook and Twitter, but I find it ugly and irrelevant. I don’t need my social media bleeding through every orifice of my phone. When I want Twitter, I’ll launch the Twitter app.

They also stupidly took away several of the default widgets in favor of their own concoctions. They suck hard. Most importantly, I miss having the stock calendar widget, which shows you in an attractive way the next event on your calendar. In its place is the abbysmal Daily Briefing, where, alongside your recent calendar events, it also pulls in weather from AccuWeather, stocks from whatever, mobile news from Yahoo, and looks terrible to boot. Crazier still, these widgets are only available from the TwLauncher3. Having switched to ADWLauncher, I still don’t get the stock Android widgets, nor Samsung’s crappy replacements. I had to download a simple calendar widget, and I honestly couldn’t find one that looked similar to the stock calendar widget.

Crapware

The phone comes with a lot of Crapware installed by default. Some applications are free trials that want you to buy the full version; some are just free apps that I don’t particularly need. None of them can be deleted. And yet, it doesn’t bother me that much , because I’ve found work arounds, and I hardly pop open the Applications Drawer anyways.

Ease of Rooting

For some, part of the appeal of Android is gaining root access and doing whatever you want with your device. This isn’t something that a casual consumer would do, but considering that some phones try vigorously to prevent rooting, it’s worth noting that rooting a Samsung Vibrant is beyond easy. It’s almost as if Samsung was fully expecting people to do so.

Google Suite

Gmail is my portal to all my email; I see all the email from all my various email accounts in Gmail. So I’m very excited that Gmail integrates so well in Android. Gmail’s list view is excellent and looks nice to boot. The email view leaves something to be desired, though. Specifically, the reply and forward buttons are very weird to use: they don’t look or feel like buttons, and tapping them doesn’t feel smooth. Yet, I can’t stress how pleased I am with my phone’s integration with Gmail. My previous phone, a Sidekick 2008, tried to connect through IMAP to my Gmail account. It tried like the Little Engine That Could, or rather, like the Sidekick That Couldn’t. Even with IMAP, it constantly would not sync my read and deleted mail from my computer, so I would have to deal with it on my phone and on the computer. With the Galaxy, even though my phone fetches the email immediately, it also immediately removes it if I dealt with it on my desktop computer. Update: It seems with Android 2.2 and a new version of Gmail, the message view is much more pleasant.

My wife and I share our various calendars through Google Calendar. The stock Android calendar, which my wife gets to use, is great. It has a pleasing aesthetic, shows a tooltip when you tap an event for a summary, and has a decent widget. For mine, however, Samsung seemed to think they could do better. So they inverted the colors (the background is now all black), removed the tooltip summary, and made all-day events harder to recognize. Sigh.

The other Google apps work as expected: I’ve been using GTalk more and more, and had been using Google Voice as my business line for a while. Android offers to easily manage all your regular voice mail through Google Voice as well, and automatically uses Voice if I make an international call. Awesome.

Maps is maps. And, boy, is it maps. I tend to keep my printer dry of ink, just to prove that I don’t need to print as much as I think I do, so I hated having to look up directions, then copy and paste the directions into an email and send it to my Sidekick. Sometimes, my Sidekick wouldn’t sync the new mail until I had painfully found my way to my destination through trial and error. Now with my Galaxy I can get directions to anywhere, at anytime. More importantly, I prefer to look at the map view, since I’m a visually oriented guy. Directions are too abstract; I like to see where I am. Ta-da.

Calculator

This is really minor, but I noticed it when I was out with some friends that have iPhones. We had gotten a bill after eating some excellent sushi, and they both pulled out their phones to split the bill. They both, in that short minute of calculating, cursed the iPhone Calculator app. In contrast, I pulled out my phone, intrigued by their grief, and checked on the calculator that came with my Galaxy. It was more than I could ask for. I’m used to most basic calculator apps providing numbers, 4 operators, and a single display of the most recently outputted number. To my delight, this app contained a scrolling output area to show previous calculations, and listed the entire equation out similar to when I used a TI-83 in calculus class. Turn the phone horiztonal, and the Calculator goes all Scientific Mode on you.

Android

I think iOS is a great piece of software. The iPhone really is an awesome device. Yet, now that Android hardware can compare to Apple hardware, I’m also glad that my phone runs Android. Why? Is it because of the famed “openness”? Well, not primarily.

The Android platform is certainly more open. Not 100% open, but far more open then the Apple App Store. I like that I can side load apps without jailbreaking or rooting, because Google lets me. I’m glad that developers can create apps that compete with default Android applications, providing me with possibly better choices than default, like a better SMS client, or a browser with tabs. More so, I’m glad that I can write my own software for my phone, and not worry that some overlord is going to deny my hard work, nor do I have to pay a developer license to do it. Yet, as I said, the openness isn’t what I like most about Android.

I actually love how the Android OS allows applications to be used by the user. Here’s the things that really shine to me:

  • Notifications: Everyone always mentions Android notifications in a good light, and that’s because they work great. They’re out of the way, only in the top status bar, and can be accessed from inside applications by just pulling down from the top of the phone. While I like the red pills in iOS, the notifications in Android let you peek at the title of the notification and clear them out if they turn out to be not as important. In iOS, you have no such liberty.

  • The Activity Stack and Back: In iOS, it’s up to the application developer to add a Back button to any given screen. And usually, it doesn’t truly mean “Back”, but more like “Up One Folder”. Worse still, is that if an application opens another, like Safari or Mail, there is no “Back” to the previous application4. On Android, the Back button goes to previous applications and Activities. This is because in Android, every action is an Activity. Activities can start new ones, and they get added on top of the Activity stack, until an Activity has finished. Pressing Back will finish the current Activity and head to the previously active one.

  • Apps can communicate with Intents: Providing a generic way for applications to send messages to each other via Intents means that no matter what RSS Reader application you use, and whether you use Instapaper or ReadItLater, they can talk to each other on your phone. So if you use something a little less popular, you aren’t doomed to never having other applications support it.

  • Real honest-to-goodness multi-tasking: It can really multi-task. No, not that fake crap iOS claims to do. Real multi-tasking.

I love the Galaxy.


  1. I currently access my articles through the Hard Copy app, from Tony Cosentini

  2. I don’t need 7 home screens, so I dropped down to 3, but the programmers determine the middle as screen 4, no matter what. Did no one ever teach them how to find the middle of something? 

  3. TouchWiz default launcher. 

  4. In iOS 4, if the application has been re-compiled to use fast-app switching, you can switch back to an app now. 

Aug 5 2010

PHP Error Suppression Performance

Sometimes, a function might cause a warning, like when you’re messing around with files. It might be tempting to just prepend an @ to the function, and live on. But being curious, I researched if this does much harm besides being sloppy/lazy. It turns out there are performance costs for doing so as well.

I first built a simple test that would loop a million times accessing a variable with and without the suppression operator prepended. The differences were small, yet noticeable. Using the suppression operator ended up taking 40% longer to execute. Interesting, but then an article by Vegard Andreas Larsen pointed out something I failed to test:

[The] assertion that it is the act of the @ operator that is very slow, is wrong. It is in fact the actual triggering of the error or warning by itself.

His tests show that while the suppression operator does add a little overhead, when an actual error1 occurs, you see a bigger cost. When using the suppression operator, you’re writing in a style that let’s you cause errors and not care, which decreases performance. The same thing applies to setting error_reporting to ignore notices or warnings. Just because their ignored, doesn’t mean PHP doesn’t try to throw them first.

A common example is when checking for properties of an object. When ignoring notices, you might do something like this:

if($obj->prop) { 
    do_stuff($obj->prop); 
}

If the property is undefined, a notice will be thrown, and then ignored. Performance penalty. Turns out that isset is quite important, after all. Another instance could trying to call file without first calling is_file. I used to think, So what, it’s a dynamic language, it’ll be just fine. Now, I’ll be littering my code with isset everywhere.

Just to be sure, I altered my original test to check the differences between using a conditional test with isset versus just suppressing the notice. The difference was that suppressing the notice (a notice!) took 100% as long as just checking if it existed first. Try it yourself.

<?php

function no_suppress() {
    $a = 0;
    $b = new stdClass;
    $a = (isset($b->asdf) ? $b->asdf : null);
}

function suppress() {
    $a = 0;
    $b = new stdClass;
    $a = @$b->asdf ? $b->asdf : null;
}

function do_test($suppress = false, $loops = 1000000) {
    if($suppress) {
        echo "starting suppress...\n";
        $start = microtime(true);
        for($i = 0; $i < $loops; $i++) {
            suppress();
        }
        $end = microtime(true);
    } else {
        echo "starting no_suppress...\n";
        $start = microtime(true);
        for($i = 0; $i < $loops; $i++) {
            no_suppress(true);
        }
        $end = microtime(true);
    }
    echo "ended: " . ($end - $start) . "\n";
}

Now, this might not be the biggest thing in the world. But it’s enough for me to change my ways, since it affects me once to write it, and my users an infinite amount of times having to execute. Since I believe in optimizing for users instead of developers, that’s how it’s going to be.


  1. I use the term error to mean any message thrown. It includes errors, warnings, notices, etc. 

Apr 1 2010

Enthusiasm Starts at the Top

Some people can get super excited about their projects, and others can’t wait till it’s done. That attitude, that enthusiasm, bleeds into everyone else on the project. Some people might try to argue that everyone controls their own attitude, and to a degree, they’d be right. But this isn’t about whether individuals can overcome a dominant attitude. That’s not the issue at stake. The issue is that by being glum or not-caring about your project will affect others working on it, and why would you bet on them being able to overcome your apathy?

Clients that don’t care

When you get a client manager that just doesn’t care about his project, that project is going to suffer. When that person doesn’t care about details, the workers don’t care about details. When he doesn’t care about deadlines, the works don’t either. When he doesn’t bother to explain expectations at all, the workers don’t want to try to guess at them either.

Basically, if you’re not willing to care about your own project, why should we? And don’t tell me it is our job to care, cause thats bah-log-na.

When the top guy cares

When the manager or owner of a project really cares about it; when he really thinks it’s an awesome idea and that so much of it will be so grand; that enthusiasm filters down to the workers on the project and makes them excited too. When you have someone higher in the company come by and say “Ooohh” and “Aaahh” at your newest implementation or refinement, you get excited about your work. Or before you start, if said person shows how important he thinks this feature will be, and how much better we’re going to do it that anyone else, that rubs off onto you.

Take a look at Steve Jobs. He thinks his products are brilliant. They’re the absolute best. Everything else is crap. He’s excited about his new products, as the come out, like the iPhone and the iPad. And I’m certain that his attitude about how awesome he thinks his products are, and how great the next version will be, is half the reason why Apple’s stuff really is so good. The engineers and designers there start to think they’re making the best gadgets in the world, and so they try harder to make sure it really is.

Britt Selvitelle from Twitter told a similar story:

I remember from years ago at school a professor of mine got down on his knees and spread his arms to the whole classroom of college students and said “I love Algorithms!” and it really stuck in my mind.

—Britt Selvitelle from Twitter Talks About Passion

I’m sure that professor influenced many of the students to care more about algorithms than they previously might have, and came out of that class with higher scores and deeper appreciation of how awesome algorithms truly are.

My boss cares so much

My boss loves our product. He thinks it’s the best website manager in the world. You can’t tell him differently. And you know what? Because he thinks so, we all think so also. He’s always showing new people our product in his office, and we can hear him down the hallway, saying how awesome this is, and how much better that is, and next release, it’s going to do something else even cooler!

If you have project, and you want it to succeed, make sure you think the world of it. Because your enthusiasm will rub off onto your workers, and even onto your customers.

Mar 23 2010

The Relevance of SEO

A few people in the web world have started an argument about whether websites need to invest in SEO. I understand why website owners would be confused about the topic, but it should be pretty straightforward for web designers. This article was a long time coming, they just provoked me to sit down long enough to fill up a page of my opinion. Actually, I think these people are trying to say what I’ll be saying: make a good website, and the rest will come.

The SEO That Doesn’t Matter

Many people think they get their website built, and then spend time and money on getting it search engine optimized by stuffing keywords anywhere they can. And they watch their rank go up a space or two, and then try to stuff relevant keywords anywhere else they can. Sometimes, there might be an analysis of keywords in regards to competitors’ sites, and then trying to pick better and more keywords than they do.

I’m not saying this kind of stuff does nothing. If you fit in relevant keywords where they should go (read: don’t stuff everywhere), and make sure you use keywords that customers are searching for, you can see a bump in ranking. But it’s miniscule compared to what really matters. And the amount of money you’ll spend getting such a tiny bump makes this matter even less.

What Really Improves Your Site Traffic

The things that really matter are the easiest things to do right. In short, be awesome, and get others to agree with you. Being awesome includes having web pages that describe what you do and how you do it so well. Then, spread the word, and having them “agree with you” by telling the web they should visit your web pages.

Be Awesome. Oh, and some content, too.

First of all, if you’re not awesome, then no one wants to read about you versus the people that are awesome. The whole point of Google Search is for Google to try to provide searchers with the most relevant and best information for their query. So whatever it is you’re awesome at, you need to make a couple pages explaining about said awesome topic.

In doing so, make sure your pages are well structured. The title tag should be a phrase that describes the page; not a place to fit 15 keywords. Something you would want to read in the SERPs and would be motivated to click on. Go ahead and make your heading tags (h1-h5) relevant sub-topics of your title. Make sure you provide a few good paragraphs and/or pictures about the topic at hand. Yes, you can use relevant keywords, but keep the text feeling natural. And, you’ll be getting a great benefit from having a “pretty” URL. Forget the query string cryptic mumbo-jumbo. You can likely just lowercase and dashify your title. This is everything Google themselves tell you to do.

Creating compelling and useful content will likely influence your website more than any of the other factors discussed here. Users know good content when they see it and will likely want to direct other users to it. This could be through blog posts, social media services, email, forums, or other means. Organic or word-of-mouth buzz is what helps build your site’s reputation with both users and Google, and it rarely comes without quality content.

Google’s SEO Starter Guide

These kinds of things are what a web design company and a copywriter will help you do.

Something that I’m always suggesting to any website owner that asks me about increasing their traffic, I always always always suggest something like blogging. Continuing to create quality content only does good for your website. Each new post you create, is another landing place for visitors. It can be about a specific topic, so you start to gain traffic for that topic from Google. Likely, if the topic is specific enough, you’ll be one of the best ranked pages for that search query.

For instance, since I’ve started blogging, I get traffic I wouldn’t otherwise get for topics like “basic password hashing”, “mootools tabs”, “css 3d effect”, and “javascript date math”.

Links, or Getting Others to Agree

After you’ve written your amazing content, and made so super useful to visitors, you need to get other people to agree with you. Google openly states that one of the biggest factors in whether they will link to you is if other websites link to you. Those other links are proving to Google “I felt this is page relevant and useful for the topic it is about”. Google is essentially trusting the web community to promote the good content above the mediocre.

So you promote your site in places that would want to know. Comment on other blogs with a link back to your blog/site. Join in on discussion boards about the topic, proving your knowledge. Your signature can contain a link back. Or, after a few selfless offerings of information, perhaps you can fit a link back to an article your wrote into one of your answers, where it is relevant.

You can leave a link in your email. And when you get an email asking about a topic you’ve already written about, you can provide the link in your email answer. Some people will eventually put links to you on their own website. Eventually, even bigger websites will do the same. As this happens, you get not only the traffic from that link, but Google increases their trust in you, and will raise you accordingly in their search results.

These things will make the biggest impact on your traffic. Anything anyone else offers might help, might hurt, but nothing will do as much for your website as providing awesome content, and getting people to share it with others.

Mar 3 2010

A Less-Random Generator

In game development, it’s very common to want a random number. Maybe you want to determine damage done, if there was a critical, or what slot on the board to insert your piece at. And surprisingly (or perhaps, not), programmers are often looking to make this random number a little less… random.

Less Random, you say?

Yea, seriously. We really don’t want a real random number, because random is too random. Backgammon players rage on about how un-random virtual dice rolls are, and programmers can go to extreme circumstances to provide the right kind of random.

Role playing games have to overcome this too-random problem as well. In an RPG, you might be getting a random number to determine if the player character hit the monster. And considering the situations you find yourself in when playing an RPG, this dramatic but randomly generated experience can really suck:

A blade spider is at your throat. It hits and you miss. It hits again and you miss again. And again and again, until there’s nothing left of you to hit. You’re dead and there’s a two-ton arachnid gloating over your corpse. Impossible? No. Improbable? Yes. But given enough players and given enough time, the improbable becomes almost certain. It wasn’t that the blade spider was hard, it was just bad luck. How frustrating. It’s enough to make a player want to quit.

—Randomness without Replacement

It’s really quite interesting how much we really don’t want real randomness. Because real randomness is not biased. Pure randomness doesn’t care if that’s your 20th “1” in a row. It can lead to frustration, and cause people to blame the game for sucking, when really it was just a bad sequence of random numbers.

How We Perceive Random

It turns out, when we say random, as a player, we actually mean controlled random. Compare these images of dots plotted on a grid:

Which picture looks like the random we want? Apparently, the first is too random for humans. What I mean is, it doesn’t look random. We quickly identify patterns in the truly random picture. We see groupings and think there must have been numbers that were favored to get that result. We want to believe that randomness will evenly distribute it’s results across the spectrum. No patterns, no missed numbers, no repeats. Even.

The truth behind these 2 images is that the left image is a true random plot. The image on the right was controlled.

The plot on the right is […] composed of 64 smaller squares, each of which has 4 points placed at random. People don’t like the leftmost plot because it has several clumps of points that seem non-random. In fact, true randomness consists of a mixture of clumps and non-clumps. Randomness is different from homogeneity.

—Warning Signs in Experimental Design and Interpretation

A programmers solution

The way to handle controlled randomness is actually pretty simple. It’s commonly called a shuffle bag. The principle is that you take a bunch of tokens and put them in a bag. Then when you need another value, you pull a token out of the bag, and use that. Once the bag is empty, you fill it back up again.

You can control the percentage of a positive or negative result by setting the ratio of tokens you insert into the bag. You can also control what sort of “sprees” you can get from you bag by inserting duplicate values.

For example, with 1 hit value and 1 miss value, you have a 50% (1/2) chance of hitting. You also have the possibility of getting 2 misses or hits in a row. If you changed that to contain 5 hits and 5 misses in the bag, you could possibly end up with 10 in a row.

import random
class ShuffleBag(object):
    def __init__(self, values):
        self.values = values
        self.list = None
    def next(self):
        if (self.list is None) or (len(self.list) == 0):
            self.shuffle()
        return self.list.pop()
    def shuffle(self):
        self.list = self.values[:]
        random.shuffle(self.list)

The usage would be pretty simple. If I want a 20% chance of getting a critical hit on a damage roll, I would implement that like so:

bag = ShuffleBag([1, 0, 0, 0, 0])
while attacking:
    is_critical = bag.next()
    if is_critical:
        dmg = MAX_DMG
        doDmg(dmg)

Who’d have thought that you needed to do something special just to get “fun” random numbers? I think the root of it has to do with how statistics are all just a lie.

Feb 12 2010

Make the DOM Update Faster

We’ve already learned that to make our Javascript load faster, we should be listening for a domready event instead othe window onload event. However, sometimes, you can actually make too much Javascript reliant on that sacred event. And when you do that, you can get quite the jump or flicker in older browsers.

We use a proprietary text replacement program instead of sIFR or Cufon or anything else out there. We call it Typostream. On one of my recent projects, we had several features of the web-site requiring extra Javascript functionality, along with a good portion of text being replaced. Originally, I had all of this Javascript being executed on DOM ready event, as best practices recommend. However, viewing the site in Internet Explorer revealed some amazingly laggy results.

Doing a lot at domready can suck

In IE (even IE8), the time it took to execute all the Javascript was way too long, in the realm of a several seconds too long. Now, the ultimate cuplrit was that we had over 100 elements on the page that needed to be swapped out for images of the same text. Eventually, we wear able to alter the design to require only a couple parts of the page to be replaced. But I discovered a more immediate fix for such a big flicker of content.

LOG: Total: 244, Since Last: 244
LOG: Total: 1992, Since Last: 1748

The timer was started at the top of of the Javascript file. The first profile call was at the start of the DOM ready event, and the second call was after the Typostream call.

Basically, with some logging, I found out where the big beasty functions were. On the inside, the common mechanism for dom ready implementations, is that every function you add as a “listener” to dom ready, just gets pushed into an array. Once dom ready fires, it loops through the array and executes all the functions. So basically, the dom ready event firing can become one giant function that needs to finish.

var $log = function() {
	if(window.console && console.log) {
		for(var i = 0; i < arguments.length; i++) {
			console.log(arguments[i]);
		}
	}
};
var $profile = (function() {
	var _start = new Date(),
	_last = new Date();
	return function(msg) {
		var now = new Date();
		msg = (msg || '') +' ,';
		$log(msg + 'Total: '+  (now - _start) +', Since Last: ' + (now - _last));
		_last = now;
	};
})();

This was my method of profiling. You could also use console.time and console.timeEnd, but this works in a pinch (and in older browsers).

Now, many things we do in Javascript are setting up event listeners and timers, so the major work at dom ready is usually fairly small. But the amount of work that was needed to swap out all those elements (and having to do slow selector lookups in the older versions of IE) was all trying to execute at dom ready. And while the DOM was being accessed and changed during that time period, the Javascript hadn’t given up its execution to allow the browser to update the DOM.

The DOM was only able to update itself after that Javascript had executed. So even the smaller part at the start, like collapsing an accordion, wasn’t happening until several seconds later. The solution was to remove how much Javascript was happening on the DOM ready event. I wanted to break it up, giving the DOM the ability to do all the changes for the accordion and modal boxes, before trying to do the heavy lifting of running up and down the DOM tree a hundred times.

Well, then move out of current execution

Along comes setTimeout. By wrapping the typographical replacement into a timeout call, I gave the browser an opportunity to run other browser stuff. It does its thing (like fixing most of the page immediately), and then calls my big function afterwards. Sure, that big function will still take a couple seconds to execute, making the text flicker, but at least its not as glaring as the section navigation collapsing 5 seconds in. And like I said above, we were able to drastically reduce the number of elements to change, thus fixing the problem even more.

But it’s useful to know that you can actually clog up your domready event, and how to clean it out again. If you had a ton of things that needed to happen, you could probably set up a simple queue system that will execute everything you want in order, but setting a timeout for each one. Or you could try out web workers, if that fits your bill.

Page 1 of 3