THE CONTEXT OF COLOR

Quick tip: Dynamic object properties with Javascript (and Node.js)

Sun, 18 Jul 2010 14:35 -0700

I’ve been working a lot on my Superintendent project lately, and I just ran across an odd solution to a problem I was having. I’ve been writing the agent in Node.js, and I needed a way to get the output of /proc/meminfo into a clean, well-formatted JSON object. The issue I was having was I needed a way to assign object property names based on variables. Here’s what I mean:

var meminfo = new Object();
var someName = "objectPropertyName";

//now, assign an object property based on the variable
//someName's value
meminfo.someName = "some data here.";

You can probably already see the problem. The property that we assigned is called meminfo.someName, but we wanted it to be meminfo.objectPropertyName. How do we solve this? Well, first, let’s take a look at an associative array that would get the job done (albeit with an array):

var meminfo = new Array();
var someName = "arrayPropertyName";

//assign a value to the array with the key being the
//content of the variable 'someName'
meminfo[someName] = "some data here.";

That example would give us the variable meminfo['arrayPropertyName'] with the value some data here.. Exactly what we want, but with an object. So how do we do this? The answer is incredibly simple. Take the second example, but instead of creating a new array, create an object, and access it like an associative array:

var meminfo = new Object();
var someName = "objectPropertyName";

//assign a value to the array with the key being the
//content of the variable 'someName'
meminfo[someName] = "some data here.";

Now check and see of the object property exists; you’ll find that it does. We’ve successfully created a dynamic object property meminfo.objectPropertyName. All we had to do is access the object like an array.

Weird, but it works.

Defending Apache against Slowloris attacks on Ubuntu 10.04

Thu, 08 Jul 2010 21:10 -0700

For anybody who is unaware, all default Apache2 installations on Ubuntu (and most other OSes) are vulnerable to a simple Slowloris DOS attack; any script kiddie with Perl and some free time can bring down major sites with limited bandwidth and resources, due to the way Apache handles half-open connections. Without going into how Slowloris works (that’s detailed on the Slowloris project page) or getting too complicated, here’s a simple way to effectively defend against this type of attack.

Run these commands (as root) and you’ll be good to go.

root:~# apt-get install libapache2-mod-antiloris
root:~# service apache2 restart

That’s it! While this module doesn’t offer complete protection—a sufficiently distributed attacker could probably still defeat this—it will stop most script kiddies and even somewhat determined attackers from using Slowloris on your servers.

New servers, new businesses, new projects

Wed, 07 Jul 2010 11:10 -0700

I’m probably the worst person ever at sitting down and writing about what’s going on; there’s just so much and I really hate writing it all out. But nevertheless, here’s what’s been going on in the last few weeks.

Infrastructure Upgrade

I’ve finally moved away from Dreamhost; not that there was anything wrong with them in my short experience, it’s just… well, it’s SLOW. That’s really the only downfall to using them (I was only with them for a few months, but I never noticed any downtime or anything like that.)

However, I’ve moved on. I’m now running a custom setup on a Linode Xen VPS. It’s still not totally bug-free—more on that in a second—but it’s much faster, and a lot cooler. Which is all that really matters.

Now, for those of you that have read my articles, you know I’m a huge Apache fan. I’ve used it for all of my projects, and I run it on all of my servers. But I was looking for a change, so I thought I’d try something new.

The Cherokee Project

The Cherokee Project was my first choice as an alternate HTTPD. From their site:

Cherokee is a very fast, flexible and easy to configure Web Server. It supports the widespread technologies nowadays: FastCGI, SCGI, PHP, CGI, uWSGI, SSI, TLS and SSL encrypted connections, Virtual hosts, Authentication, on the fly encoding, Load Balancing, Apache compatible log files, Data Base Balancing, Reverse HTTP Proxy, Traffic Shaper, Video Streaming and much more.

What’s not to love?

I set it all up (getting PHP working was quite the fiasco until I realized they had built-in tools for doing such things) and configured a bunch of vHosts, all using different PHP interpreters for a secure multi-user environment. Everything was great, until I tried to move this domain (alax.me) over. It would seem that Cherokee is great for most things, but when you start using a ton of regular expressions in redirects, it chokes itself and brings all the vHosts down. Not good.

Back to Apache

Cherokee was nice to play with, but now I’m back with Apache, and frankly, I should’ve just done that from the start. Multi-user environments are dead simple with mpm-itk (sorry Cherokee, but information sources and PHP-CGI really suck.) and I can count on it to handle as little or as much as I need and not worry. Cherokee was fast, but I need my stuff to work all the time, and Apache has proven itself over and over in that regard. Also, I like configuration files; Cherokee-admin was pretty, but honestly, I’m running a command-line OS; I should be able to do this stuff without a GUI.

Well, that’s enough about my servers for now.

Eluviis

What is Eluviis? It’s my latest project; It’s the name I’ll be conducting my business under from now on, and it’s where I’ll be keeping my grid services. If you click that link, you’ll notice it’s really nothing exciting; I’m actively working on the site (and the servers that power the technology behind it) so it’ll be up soon.

While Eluviis is actively engaged in projects for clients right now, one of the things I’m planning on releasing over there is the Superintendent. It’s still a long way off, but I’ve got some seriously cool ideas that I think people are going to like (instant push notifications? active attack detection and mitigation? yeah.) It’s going to be cool. Here’s hoping my programming skills—and my determination—can keep up with my imagination.

Final Thoughts

I’ve been thinking about posting some tutorials on various things I encounter (like how to run Cherokee as a multi-user server) so I’ll probably get around to posting those sometime soon.

That’s about it. Carry on, then.

Introducing The Superintendent Project

Wed, 26 May 2010 20:16 -0700

In looking for lightweight, simple, and extensible network monitoring systems, I haven’t come across any that really strike me as all three of those (extensible and lightweight are a killer for most).

I’ve decided that writing my own seems to be the best way (for now).

This is the Superintendent Project.

The Idea

I want to be able to get raw stats from the things I need to monitor, and most Linux distros already have great tools for this:

Process Monitoring. The pidof command makes this dead simple; If pidof apache2 returns a bunch of numbers, it’s running, and if the result is blank, it’s not. Couldn’t be easier.
Apache Status. You may or may not be aware of this, but if you visit http://localhost/server-status on any machine running Apache2 with the default config, you’ll get a bunch of statistics about Apache2. Turn ExtendedStatus on, and you get even more information.
Postfix Statistics. Need to know how much mail is in the queue? There’s a command for that, built-in.
Shorewall Status. Run shorewall status. That’s all that needs to be said.

This works for pretty much any program you can think of; if there isn’t a tool, you can always grep the logs.

So, what if I made a PHP script that ran all these commands, and sends the raw output securely to a remote server? That way, if any of the commands change, none of the clients need to be updated, just the server—just the Superintendent.

How It’s Going To Work

It’s really very simple. A PHP script will be running on the server machine that runs all of the commands above (and more) and gets their raw output. This PHP script can either be set to daemonize itself, or be run by Cron.

At the specified intervals (assuming Cron is used) all of the output will be posted to an SSL enabled server using PHP’s CURL functions. The server will then parse the output—meaning that if the clients update, and the command output changes, the clients don’t all need to be updated, just the server—and you can choose to do with it what you want. In my case, it will be output to a web-based interface and a wall-mounted monitor.

In addition, several other techniques will be used to monitor the server; things like ping and response time can be handled by the Superintendent server. If no information is received from a node, it can be assumed down, and other backup checks will occur (check if Apache is still responsive, if it’s responding to ping at all, possibly even parse the status page of the server’s datacenter for possible problems.)

I’m sure I will run into pitfalls in the development of this, but it should be pretty awesome when all the bugs are ironed out. It will be lightweight, cross-platform (as the server accepts raw data), simple, and extensible.

Thoughts on Photoshop CS5 Extended, Snow Leopard, and NMSes

Sun, 16 May 2010 22:05 -0700

It’s been a busy few weeks since my last post, and really not a whole lot of stuff happened that’s worth writing down. However, in my absence I’ve been changing things up a lot. First off, new software.

Photoshop CS5 Extended

All I have to say is pure awesome. Seriously. It loads up insanely fast, it’s 64-bit from the ground up, and it even has a new splash screen. What’s not to love? (besides the fact that I really hate the new icon).

Also, I need to make sure that people are aware: Content-Aware Fill is pure magic. Seriously. There is no way half the stuff I’ve used it for recently is even possible, and yet it makes it happen right before my eyes. My friend Todd really had the best explanation of how this wizardry works (I was editing a photo of a tree):

You see, as soon as you click the button, Adobe goes out to that exact same spot, digs up the tree, fills the hole, replants the grass, and fixes the rest of the landscape. Then, they set up the camera at the exact same position, time-warp to the time of day you took the photo, take the photo, and send it back. It’s actually quite simple, really.

That’s definitely how it works.

Snow Leopard

I’ve been running Snow Leopard since the beta stages on my MacBook Pro, and I have to say, I’m less than pleased. It’s a fantastic OS, but the RAM consumption has been out of control. Every time I fire up MainStage (an amazing program, by the way) it shows all 4Gb of RAM completely used. MainStage uses about a gig by itself with all my patches loaded; where is the other memory being used? It’s the only program running, aside from Dropbox and GlimmerBlocker in the background.

I re-installed in a vain attempt to regain some of this lost memory; honestly, that was just a huge waste of time and the RAM consumption is back to ridiculous levels.

Ahh, well. This is why I love Linux.

Network Management Systems

I’ve been looking into all sorts of network management systems lately for an upcoming project, and again, I have to say I’m displeased. I’ve looked into Hyperic, Zenoss, Nagios, OpenNMS, and many, many others; all fall short in one of these areas:

Too much RAM consumption. All you do is monitor my other systems, and yet you won’t even start up with less than a gig of ram. Not acceptable.
Not extensible enough. Most of these solutions are great, but they don’t offer the extensibility I need. I want to be able to pull stats from their interfaces into my own 10-foot user interface which is on a wall-mounted monitor. That way, I can glance over and know if something is wrong, and then use the more complicated system interface to find/troubleshoot/fix the problem.
Just plain ugly. This may sound superficial, and it kind of is, but I don’t do ugly UIs.

If there is one solution that can do/doesn’t have all of those, somebody, anybody, please let me know.

Quick tip: Handling NULL in MySQL Joins

Sat, 17 Apr 2010 11:09 -0700

This is just something I ran into, and thought might be helpful to someone. (note this is from a project I’m currently working on, which is why there are articles and games, and no explanation. The concept should be fairly self-explanatory though)

Normally, when I do JOINS in MySQL, I use WHERE clauses, like so:

SELECT article_title, game_title FROM articles, games WHERE articles.game_id = games.game_id

Now, this works beautifully—but only if articles.game_id actually references a game_id. What if the article doesn’t reference a game (meaning, it’s NULL)? That query will only return results for articles that have a game_id set.

Here’s what to do:

SELECT article_title, game_title FROM articles LEFT JOIN games ON articles.game_id = game.game_id

That query will return all articles, including ones that have a game_id set and ones that don’t.

Why XHTML is better for the web

Fri, 09 Apr 2010 00:09 -0700

With the rise of HTML5, it’s left developers wondering what happened to XHTML; it would seem that the XHTML2 spec is dead in the water. Why does this matter? First, let’s get some basic concepts down.

XHTML vs. HTML

XHTML and HTML are very similar in terms of coding, but they do have some major differences. XHTML requires you to close all tags, and HTML does not. This is because XHTML is handled like XML; the entire document must be well-formed and valid in order for it to parse at all. HTML, on the other hand, will just keep going if it finds a broken tag, attempting to resolve errors itself. While this functionality is quite nice from a developer’s point of view—errors in your code won’t mess up your whole site—it’s bad for the web as a whole.

Benefits of XHTML

It is far more strict. XHTML requires the developer to make well-formed code; it’s not a suggestion, like with the HTML5 spec, it’s a requirement. It simply won’t parse at all if it’s malformed—this is assuming you’re actually using XHTML, served as application/xhtml+xml. Even if you’re sending it as text/html (which would mean you’re actually telling the browser to parse your page as invalid HTML 4.01), XHTML still requires better coding practices, though it will behave like HTML in these cases.

It requires consistency. XHTML requires all tags to be lowercase. While this seems a simple cosmetic feature, it unifies the look of the code, which is never a bad thing, though not necessarily a benefit. It also requires that all attributes be quoted, and that all inline elements must be contained within a block element (meaning you can’t link a div using an anchor.)

I’ve heard many arguments that using XHTML is a waste of time; some developers state that HTML doesn’t need these “ridiculous” requirements on the code, that “HTML parsers are meant to handle things like omitted tag closes.” While these are valid points, I can’t see why encouraging better coding practices is a bad thing. If we can code better, why shouldn’t we?

So, what can I do?

Since XHTML2 is effectively dead, three options are available for writing modern code, but all have benefits and downfalls.

Stay at XHTML1.0/1.1 This provides the benefits we’ve all become accustomed to; well formed code, lowercase tags, etc. The only problem is that it is quickly becoming outdated, and no new work is being done on it. Sticking to a dead standard is never a good idea in the long run.

Switch to HTML5. This is the option that I’m currently using for all of my sites. HTML5, like it or not, is the future of the web—even if it is a future filled with ugly, invalid code trees and UPPERCASE TAGS THAT PRACTICALLY SHOUT AT YOU. It recommends that you code like HTML, i.e. don’t close your empty elements, but it allows you to code like XHTML. So even though it doesn’t enforce good coding practices—in fact, it recommends against them—you can still use them.

Switch to XHTML5. This is the best option in terms of standards, but probably the worst in terms of compatibility. It will definitely confuse older browsers, due to the fact that the doctype must be omitted to be valid, and it must be served as application/xhtml+xml. However, if setup correctly, it will have all the requirements of XHTML1.1 with all the benefits of HTML5. Valid, current code. Awesome.

My thoughts on HTML5

Personally, I’m kind of upset with HTML5. While it provides a ton of awesome new features, it takes a huge step backwards in terms of standards. Let’s face it, even though <br> is easier to code than <br/>, one makes way more sense. Why shouldn’t you close empty tags? At best, you have to make sure your parser can understand non-closed empty tags, and doesn’t screw up and make every subsequent element a child.

Seriously guys, what part of this is a good idea?

Let’s enforce well-formed code, not recommend against it.

Content, content, content

Tue, 06 Apr 2010 17:55 -0700

When it comes to site design, there are several things I love doing: headers, footers, and the overall encompassing frame of the design. However, there are parts that I hate. The number one thing?

Content Layout & Design

I absolutely loathe content layout; there might be a more official term for it, but it’s what I call the area that actually holds the text, the area you’re reading from right now. It’s the only part of the design that feels cookie cutter on every site; even my site has nothing new about it.

Having similar looks isn’t necessarily a bad thing, but when you strive for creativity in every area of the design, it’s a huge drain on productivity. I can’t even begin to name the amount of time I’ve spent trying to get unique and good-looking content. For the designers out there, you know how much of a pain getting the correct line height, letter spacing, and alignment can be, especially with all the inconsistencies between modern browsers (I’m looking at you, IE). So, while it’s hard to be different in this area, we might as well be good-looking.

So, what do we do?

There are a few incredibly basic principles I’ve come to follow when it comes to content layout. These are probably pretty common knowledge, so don’t get upset if there’s nothing new here. Also, I don’t claim to be an expert on all of this, so don’t get upset if I’m completely wrong. That being said, I have used these techniques quite a bit and it always helps contribute towards a good-looking design.

Text

Line height should always be at least 1.5 times the size of your text. It makes it much, much easier on the eyes and much nicer to read. In CSS, simply add this to your element of choice to get on your way:

line-height: 1.5;

However, make sure you never go over 2 times the size of your text, unless your intent is to make it appear double spaced or you just like making your writing incredibly hard to read (note that this doesn’t apply everywhere; if you’re going for a typographic look, for example.) Making your line height double the size of your text visually separates your content, subconsciously informing your reader that your current thought has ended, and you are starting a new one. Definitely not what you want, especially mid-sentence.

Serifs should be determined by the design, not concerns of readability. It’s a wives tale of design that I’ve fallen for myself; should I use this sans-serif font so it’s easier to read? The answer is no. There have been several major studies showing that there is virtually no difference in the readability (not legibility—if a font is illegible, it’s never going to be readable, but a readable font can be made illegible) of sans-serif fonts vs. serif fonts. Some designers might reference the studies of Sir Cyril Burt, a man who conducted a psychological study of typography, saying that his studies show that serif fonts are indeed more readable; however, Burt has since been accused of forging his results, and there have been studies arguing the better points of both types of fonts.

But wait! There’s more. It is true that sans-serif fonts are generally more legible at smaller sizes—especially on the web—due to the pixelation that comes from being displayed on a computer screen. It’s also usually true that if you’re using fonts this small, you’re not worried about readability.

All this to say, if your design looks better with one type of font over another, there is no academic proof that because of serifs readability will be affected. Choose what looks best, as long as the font is legible to start with. If you’re unsure, just choose Helvetica. Everybody loves Helvetica.

Readability dramatically varies based on line width. There are many studies on this topic, but it basically comes down to this: for a 12 point font, try to keep the line width (the distance from one end of text to another) between 400px and 500px. I’ve broken this rule multiple times for the sake of a design, but if at all possible, try to stay within that range. Your readers will thank you.

If you want to see how much of a big deal this is, go to Wikipedia, look up any article, and then stretch the browser window the full width of your screen. See how much harder to read it is? Now, take that browser window and make it ridiculously small. Difficult, right? 400px to 500px. It’s a wonderful thing.

Spacing

Spacing isn’t quite as cut-and-dried as text styles—not that they’re simple either—and it really comes down to individual design. Here are some principles you can use if you’re unsure as to spacing between elements; in most cases, these will look good and make adequate visual sense.

Paragraphs should be spaced no further than double the line height. If your line height is 15px, a good top margin would be 30px. That way, your paragraphs still appear connected, while informing the reader visually that you’ve moved onto a new thought.

Headings should be spaced no further than triple the line height. Double the line height works well too, due to the fact that headings are visually different themselves. Try to avoid less than your paragraph spacing, because you don’t want to give the impression that the heading is tied to that paragraph, but rather all the paragraphs under it until the next heading.

No text related margins should ever be greater than the space between articles. This one is a no brainer, but I thought I’d include it just in case. If your headings are further apart than your articles, how is the reader supposed to know when the article is over? Or that it hasn’t already ended?

The basic principle here is you want to connect content while separating ideas.

Wrapping Up

While this article definitely wasn’t extensive, hopefully it gets someone on their way to making more beautiful and more visually sensible content.

A fresh start with Symphony

Tue, 30 Mar 2010 15:30 -0700

I’ve finally moved away from Tumblr and switched to a new system called Symphony. Tumblr lately has been incredibly slow during peak hours, and Symphony was just too awesome to pass up.

Welcome to Symphony

Symphony is a CMS unlike any I’ve tried; It can do pretty much anything you’d like, straight out of the box. For those that don’t know, even though I work with WordPress a lot, I really don’t like it. I feel like the code has become too bloated as it tries to be everything for everyone, and the multiple security breaches it has become famous for have deterred me from using it anywhere important. Drupal is powerful, but it’s extremely ugly, and I just can’t work with ugly.

Then I found Symphony.

Everything about Symphony is beautiful, from the backend management to the templating system. XSLT was rather difficult for me to grasp, but once I did I realized templating shouldn’t be done any other way. It’s really that good. However, my XSLT is incredibly rough and as such, this site is probably going to break all over the place. If it does, please let me know using the contact page. The code was thrown together to get it all to work; I will be revising it over the coming weeks.

There’s a lot more coming (stuff that might be actually useful, unlike on my Tumblr account), this post is really just so that the homepage isn’t blank until I can get around to writing something useful.