Even One Word

web development Posts

The New Culture of Spam

Feb 03 2011

I realize I’m not the first one to talk about this, (see Cory Doctorow’s thoughts on the subject), but the nature of the internet and spam have changed over the years.

It used to be that you protected your e-mail address as though it were the most secretive information in the universe, next to the last four digits of your social and your weight (and/or age, depending on your gender and personality). But, just like the last four digits of your social, your weight, your age, and even probably about how much money you make, your info is all over the freaking place. But this isn’t just the case on e-mail, it is the case with blogs, forums, and any form of communication which would ever require a turing test. As of right now, I have about 200 comments on my blog, and only 4 of them are legitimate. So how did people fight this?

  1. Obfuscate your e-mail address like name (at) domain (dot) com.
  2. Turn off comments on your blog.
  3. Employ a site admin, moderator, or other full/part-time culler of the wheat from the chaff (or the spam from the real meat, whichever analogy fits your dietary restrictions best).
  4. Use the aforementioned turing test anywhere that allows human input.
  5. Automation.

The problem we have with every one of these is that they are all treatments for symptoms of an underlying disease. As far as which of these symptom treatments works best?
The shortest and last one, of course! The 200 comments on my blog, around 190ish of which are marked spam, were filtered by a plug-in most wordpressers know as Akismet. My public e-mail (nathan@nathanstpierre.com, btw) is in no way obfuscated or filtered, because it goes through g-mail, which has (as far as I’ve seen) the most intricate spam filtering system available to a public mail system. As Mr. Doctorow so intellectually pointed out, these systems exist for exactly this reason, so why not utilize them?

That being said : I still think the underlying disease goes untreated. Unfortunately, this disease is the same one that ruined the old-school forums, social media (MySpace whores anyone?), and even legitimate community tools (buy something from someone who’s not a Nigerian in Craig’s List. I dare you.). It is the chief weakness and strength of the Internet: freedom. The freedom of an open and endless system is that you end up ultimately having to be at the mercy of the demographic that utilizes it.

Great examples of the successes of this philosophy include Open Source (none of us is as smart as all of us), Wikipedia (the nice people who care will ultimately win out over the jerks, because they are not doing the easy thing, they’re doing the thing they care about). The failures of this freedom are pretty much the inverse: Reporting of false information on national TV thanks to the Bogus Blogosphere, entire systems being overrun by spammers (Google groups anyone?) and so forth. So is there a cure?

In the spirit of presenting a solution rather than a problem, I suggest a change. Not a change in software or business models, a change in philosophy. We once thought the internet was too massive and too free to infringe upon, but YouTube shattered that preconception to me when they freaking scanned a video for copyrighted material. Could software ultimately determine what’s spam and what’s legit and be a part of every ISP’s basic network protocol, insta-deleting anything that clutters their domains with horrendous spam? Potentially. But should it?

Honestly that kind of big brother dystopia –which would likely lead to my favorite cyberpunk plots being possible– makes me think that’s the more mechanical answer, which completely ignores the spirit of the issue, which is a cultural question. The culture of the internet has become beneficial to spam.

But this is a blog about web development! you say? How does being a hippie and talking about working for a new society help anything?

Well, algorithms are great, but as Google is finding out, they’re not the answer to everything (or what we call a silver bullet). For more information on an example where someone gamed Google’s algorithm in a seriously negative manner, check out the story of DecorMyEyes. To summarize: a shady businessman discovered that Google ranks things based on how often people mention your site, along with certain search terms. So he discovered that people blasting him on a thousand ripoff sites about his failure to manage their (insert glasses brand name here) order the correct way, would cause his site to show up first for someone looking for (insert brand name here) and/or “glasses.” Google’s response? Essentially, change the algorithm (to see their actual response read here).

… in the last few days we developed an algorithmic solution which detects the merchant from the Times article along with hundreds of other merchants that, in our opinion, provide an extremely poor user experience. The algorithm we incorporated into our search rankings represents an initial solution to this issue, and Google users are now getting a better experience as a result.

Is this a good solution? Honestly, it’s probably the best solution given the situation. They explain this in the article, but they point out that just blocking this person or using sentiment analysis (filter of good vs. bad reviews) could cause the inverse problem to happen: game the system and post a million bad reviews of Best Buy and suddenly they never show up in Google searches for Best Buy.

But what’s happened pretty recently with them and Microsoft’s Bing makes me think the algorithm isn’t the solution, it’s the problem.
If you haven’t heard the latest news, check out this article from Seattle’s own KIRO TV. Essentially, Google set up a “honeypot” by putting out some completely random result sets for random character searches, and Bing turned up the same results. Now unless they figured out how to steal one of the most carefully guarded algorithms in the tech industry, I highly doubt this would happen as a freak accident. It’s pretty clear Microsoft is doing something sketchy. Whether they are or not, let’s say someone at some point did. This would prove my point: the world ultimately doesn’t care whose algorithm it is. If you can steal it, where’s the incentive not to?

So we come back to the issue: the culture of spam. As YouTube discovered (I’m sure through Google’s technology), there are ways to automatically figure these things out. As I said before, it was probably the best of the options we have at the moment, but we honestly need to find a better way to approach this. For this, I go back to what I mentioned earlier: f*cking Wikipedia and open-source: how do they work?

They work by having the appropriate balance of resources, both personnel and technology. Enough coders are willing to clone your git repository of a new build and try to break it. This is hard and challenging. This scares off spammers, who will try to take the easiest and possibly fastest route through the maze to the cheese. People who are earnestly devoted to a cause will always inevitably find a way over people who are lazily employing practices that work by gaming systems. Why?

Ask the Russians, who spent the entire cold war stealing and duplicating western technology to master and decrypt it just in time to be three generations behind their innovating enemies. The Black Sunday Kill is a better example of this in action in the technology world.

So ultimately, what is the exact mechanism by which we can make search engines, blogs, e-mail and so forth unspammable? I don’t know. Not that I’m incapable of figuring that out, I think someone at less than my skill level can easily figure this out given enough incentive (usually motivation like anger and resources like free time). But the ultimate solution will be counter-acting the current disease: spammers are making money.

Every one of the ads you get that advertise “A bigger Pen15″ makes money, because someone who got that e-mail sent money to someone. Every time a Nigerian princess is ransomed in your e-mail, some gallant fellow cashed out his 401(k) to save her. That one man’s $5,000 is worth orders of magnitude more than the cost of sending out those spams mails, which could vary from a few hundred dollars for millions of e-mails to a dollar for thousands (depending on the location of the servers and the botnet being used). There are lots of resources that discuss this, but my favorite right now is the HowStuffWorks explanation.

So the solution seems simple enough, just keep them from making money! But how do we approach this?

Well, we’ve tried education on massive scale: from teaching your grandparents not to click on spam to educating your children through computer literacy about scamming. We’ve tried blocking those parts of the internet from people to protect them from themselves. We’ve tried spam-blockers, captchas, and every automation system possible. But these ALL address the symptoms. Even trying to legislate against spam has ended up being a pipe dream (and honestly legislation just makes breaking laws more fun for those who’d want to do that in the first place). My proposed solution at this moment?

Make them pay.

Legislation proposes fines, but the problem with legislation is it’s only justifiable if we can prove beyond a shadow of a doubt that suspected perpetrators are in fact perpetrators. I say, we employ the same annoying bastard tactics that we saw in use against the enemies of Julian Assange. Will it be easy? HELL NO.

As we all know, spammers utilize botnets and hordes of zombies, so tracking down all of those spam-emails will most likely lead you to victims instead of perpetrators. On top of this, they often launch attacks such as DDoS or ping-storms to people who attempt to track them down. But these are issues we can address. When these hackers take over a computer, they always leave a back door in order to access it for their various uses. They even come with a kill switch so that they can revert the server/computer/device so others can’t use their system against them. Most of these systems are freely available, and finding the kill switch is just a matter of knowing which attack was launched against your site. They hide their location and just send an anonymous text or e-mail or packet of data to the zombie herd… which makes for a perfectly good honeypot. Intentionally leave a site open to RFI attack, for example, and then monitor any packets that come into the system. When one does, you can find the source. Most likely, it’ll be from behind a series of hops, firewalls, and other zombies, but now you at least know where that came from. Repeat this process enough times, and you find the root. At the very list, you can sniff out the net and either selectively block it, or keep a database of ip addresses logged with what software compromised them so when you find a killswitch, you have somewhere to attack.

Granted these are all ideas off the top of my head, but I’m only one man. And none of us is as smart as all of us, so let’s do this. Let’s get pissed, let’s get serious, and let’s change the culture of spam. Honestly, I think it’s about time the white hats did something other than just turn up their noses at software piracy. And I’m ready to help.

New Site!

Nov 07 2010

I’ve been trying to do this for the last few months, and finally saw enough inspiration to convince me to go ahead with the process of updating my blog template and moving back to a fairly standard wordpress install.

Why?

The issue I’ve found myself combating for the last few months is that I haven’t been able to find inspiration to write blogs or work with individual new concepts, and I figured forcing myself to go forward with one would help me grow beyond my current skillset, both in web development and writing. I also needed to work hard to get my skills up in Search Engine optimization, installing Google Analytics and coming up with some new ways of generating traffic. I’d also like to experiment with bringing in some ad revenue, and the best way to do that is to guarantee that you have certain types of traffic, and a new web design can get just that.

How

Overall, at the very basic level, this blog is about dividing my interests into three main categories: music, web development, and writing. I tend to get the most visits for these three topics, and they happen to be my favorite three things to blog about, so it works out doubly in my favor. There will still be rants about politics, philosophy and so forth… but they will not be the primary focus of my blog. Most individual posts in those categories will be organized using tags, and that will allow people to find things that specifically interest them, either by using the tag cloud on the right side bar or by searching for those tags specifically.

What?

This template was built using an html5 template that I developed myself. It validates (as much as you can validate html5) using the html5 validator on validator.nu. It uses a very minimal number of image resources in order to load more quickly and accessibly for most browsers (four images for the nav, one for my portrait, one for twitter and one for rss, and the background). These images are available on all pages so they maximize the cached amount of resources, and I use CSS3 gradients with solid colors and filter gradients as fallbacks. The widths of the site are dynamic, so it loads comfortably in a large variety of resolutions. I have tested it all the way up to 2400 pixels wide and all the way down to my G1′s 640 pixels at wide resolution.

Conclusion

So take a look around, see if you find anything interesting! If you do, comment on it. If you don’t, send me an e-mail or comment on something to let me know you’d like to see more!

CSS Abstraction

Apr 22 2010

This post is being created due to the fact that two things have come up which are new to me.

Point the first

The first is that I’ve never had a meaningful conversation on twitter that needed to elevate to a better, more spacious medium. In most cases, points brought up in 140 chars are often summed or rebutted in just as few, but I’ve actually had my first conversation via twitter that really needed to escalate further. My instinct was to hurriedly write this response and put it up there, but I realized it would be a disservice to all people involved if I didn’t first do extensive research and experimentation.

Point the second

The second point is actually not fully new to me per se, but it’s something that’s constantly on my mind. I’ve used a variety of forms of code abstraction over the years, but the one thing I’ve never wanted to boil into another level of abstraction was basic markup. I never wanted to abstract away the basic layout of my form, including main container blocks and other general markup. My fear was that this would lead to lazy automation and totally jack up the formatting of my actual markup. For example the following code is dynamically created by using an abstraction method (which generates spacing and IDs dynamically):

Dynamically.
Generated.
Content.
Loses.
Semantic.
Meaning.

Here is the same code preserving its semantic nature by hand:

Personally.
Semantic.

This was true in html 4/xhtml 1 due to the fact that so many more or less generic containers with semantically relevant classes/ids were a necessity, and meaningful markup was especially hard to maintain in an abstract manner. As far as the semantic identities, sure you could have easily done those all by hand in the original generated content, but how does that save time or typing? And the first iteration of the markup is actually syntactically more consistent than the second, but the second uses tabs and newlines in a way that provides more semantic detail. Considering the fact that in (well-written) semantic HTML5, you should really be using all of the appropriate semantic tags. And considering that you can’t really loop through or abstract away that information, wouldn’t it be smarter to just write that by hand? Let’s see a possible example of this code in html5 elements…


  HTML5.
Formatted.
Semantic.

As you can see here, the need for classes and IDs is more or less nonexistant, and styling these elements would additionally be simple.

The Necessary Qualifications and Apologies

Keep in mind, I’m only saying this for the large markup elements. I fully agree with the programming concept of DRY (Don’t Repeat Yourself), and thus hand-writing a thousand-line table that would loop through and dynamically retrieve all of the data from your database and place it neatly in a tabular markup format would be a waste of time and effort. But for the sake of these large elements, adding an additional layer of abstraction could very well put me beyond my abstraction point, not due to my inability to abstract my understanding that far back, but the added cost of maintenance and conversion could end up being a net loss.

So, I was digging around and stumbled upon a really neat website. Colin Fahrion actually uses a form of CSS abstraction called SASS, which stands for Syntactically Awesome StyleSheets. I looked into it, and (perhaps a bit hastily) concluded that while it was powerful and had the ability to do some interesting things, it was really like most Ruby/rails abstraction tools and just provided a way for other languages to look like Ruby. So, I made an admittedly regrettable bon mots on twitter in which I proposed that “#sass is basically CSS for people who hate brackets.” A flurry of tweets flooded my ChromedBird, and for the most part people accused me of not being able to grok the concept of abstraction, specifically CSS abstraction.

I can understand that point, and I realize my original post came off that I seriously thought abstraction was a waste of time. I don’t have a clip, but it reminded me very much of an episode of Family Guy…

Peter: Chris, I’m just as serious as when I saw Paul Reiser do stand-up.

(Flashback to Paul Reiser stand-up)

Reiser: So what’s the deal with airline food? Is this stuff bad or what?

Peter: Aw, that’s not nice; those chefs work really hard.

Reiser: And what’s with those Starbucks, huh? They’re everywhere.

Peter: Uhh…a lotta people want coffee; that’s supply and demand, it’s the foundation of our entire economy Paul…

Reiser: And who do I talk to about those long lines at the atm? That’s what I wanna know.

Peter Not me, Mr. Reiser. Someone who has time to fritter away, but not me.

One of the first responses I gott was from Chris Eppstein, who linked me to his blog post. In it, he discusses a variety of methods of abstraction, specifically SASS, and another framework that he works on called Compass. When I brought up the fact that CSS has built-in ideas of inheritance and specificity, he linked me to his next blog, CSS Class Inheritance: Abstracting Selectors. To be fair, I was tweeting on ground that had been much more extensively blogged before me, so I came off a little snide, and for that I apologize. So I’ll go into further detail here, specifically on the issues that have kept me from using stylesheet abstraction so far.

Variables

SASS:

!article_font_color = #333
.article p
  color= !article_font_color
.widget .article-snippet
  color= !article_font_color

CSS:

.article p {
  color: #333;}
.widget .article-snippet {
  color: #333;}

Analysis

Now to be fair, this might not be a great example, but looking at this, it seems to be a good deal of extra work for the use of a variable. The argument, I’m sure, is that it’s easier to maintain if the client decides all instances of the color #333 need to be replaced by #111 (a darker shade of grey), and in this case, it would definitely save you the trouble of a find/replace. But keep in mind that there are other instances in which this would actually create more work for you: specifically the case in which you decide that you don’t want all the instances where you used !article_font_color to actually be that color. So now you have to go and change the variable name, and create a new variable to represent that other color, and then call it in the appropriate places.

Again, I’m sure this is arguable, specifically by the fact that it’s a question of your existing workflow and changes you’d have to make to your methodologies. There is also the argument that even if it’s more work, this becomes more maintainable by a group because !article_font_color is more human readable than #333. But: that’s based on the assumption that you already know the business requirements or nomenclature of your existing page setup, which basically means you’re trading one learning curve for another. I’d rather look and see what color the element is than see another symbol that contains no color data. !article_font_color means less to me without context than #333 or #111 or even #2da9ee (which is a common shade of blue that I use, so it is quickly recognizable to me).

Conclusion

I think in the event that your design is already fleshed out to the point you have identifiable variable structures (in which !article_font_color would be more than meaningless), and you are working with at least a small team of developers, variables could save you some headaches. However, I’ll argue that they trade those headaches for other ones, and in this case would actually frustrate me because I’d have to do the same amount of searching in the file to keep verifying what colors I’m coming across. Especially due to the fact that inspecting these stylesheets in the browser will show that color code, so I’ll have to do some backwards references to the source code to find out what those colors are stored as in my variables.

Functions

The next example he gives is the following:
SASS

!base = #60A
!highlight = lighten(!base, 33%)
!shadow = darken(!base, 33%)
div.box
  background-color= !base
  border:
    width: 2px
    style: solid
    colors= !highlight !highlight !shadow !shadow

Ruby Definition

# Darken a color by 0-100%
def darken(color, amount)
  hsl = Compass::Colors::HSL.from_color(color)
  hsl.l *= 1.0 - (amount.value / 100.0)
  hsl.to_color
end

CSS Result

div.box {
  background-color: #6600aa;
  border-width: 2px;
  border-style: solid;
  border-color: #a41bff #a41bff #440072 #440072; }

Analysis

So here is something that is a fundamental argument for pretty much any language’s abstraction. In this case, you’re creating new functions that aren’t currently supported by CSS. I can’t really argue against the utility of a function in general, although this particular example brings up the point of maintenance again.
The function in this case was written pretty well, giving you the option to specify percentages so you can tweak the result. Extracting a hypothetical in this case yields the following issue: the client changes their background color to the same color as this border so it becomes invisible. Naturally, you cogitate that “okay this saves me time because all I have to do is change the base color, and the rest is done for me, huzzah!”
The problem in this particular scenario would be that you need to pick a color that was not only a good contrast for the background color, but one that was capable of range so that darkening and coloring would actually provide a visible effect. In the event that they didn’t, now you need to go back and alter the function, possibly the amounts of each percentage of those function calls. And again, if you’ve applied this function in multiple places but now those colors have changed to different values, you have the same amount of work to do, if not more.

Conclusion

Functions are very useful, and to be honest, I think this is the most useful method of abstraction available in SASS (though others would argue that “mixins” are the basic unit of abstraction in SASS). However, –and this is my main argument against CSS abstraction in general– not all aspects of presentation are quantifiable. Automating and abstracting away things like sizes of elements into the appropriate form is definitely useful. You can calculate a Fibonacci series of elements by ratio without having to hard-code those calculations. But a majority of aesthetic aspects of presentation are so subjective you can’t really trust a program to appropriately automate things like readability and contrast ratio. Again, this is a personal preference, and I’m saying this because I’ve spent 3x as long trying to get algorithms to behave than just trusting my eyes and making adjustments to a cleanly formatted stylesheet.

Mixins

As Chris describes them, mixins are the “contents of the selector without the selector.” Here’s an (awesome) example:
SASS:

// Cross Browser Transparency (Yuck!)
=opacity(!opacity)
  :o pacity= !opacity
  :-moz-opacity= !opacity
  :-khtml-opacity= !opacity
  :-ms-filter= "progid:DXImageTransform.Microsoft.Alpha(Opacity=" + round(!opacity*100) + ")"
  :filter= "alpha(opacity=" + round(!opacity*100) + ")"
ul.nav
  li
    +opacity(0.75)
    &:hover
      +opacity(1)

CSS Result:

ul.nav li {
  opacity: 0.75;
  -moz-opacity: 0.75;
  -khtml-opacity: 0.75;
  -ms-filter: progid:DXImageTransform.Microsoft.Alpha(Opacity=75);
  filter: alpha(opacity=75); }
  ul.nav li:hover {
    opacity: 1;
    -moz-opacity: 1;
    -khtml-opacity: 1;
    -ms-filter: progid:DXImageTransform.Microsoft.Alpha(Opacity=100);
    filter: alpha(opacity=100); }

Analysis

This is arguably the coolest feature of SASS. I think to be honest if there were any reason to switch, it’d be this. Especially given the fact that in our current css3 universe, you need to be able to support a variety of different sets of parameters if you want to use the latest effects (gradients and shadows are the most obvious case). By utilizing this, you actually save yourself a lot of time in general, and this definitely makes things more maintainable.

Conclusion

Again, this is a matter of opinion, but I think the real thing that most of this brings up is that browser-specific logic needs to be contained in browser-specific code. A lot of people would argue that you should use JavaScript to find which browser is being used and style accordingly. A great example of this is Chris Coyier’s article on jQuery CSS Abstraction. In his second example he makes the jQuery equivalent of this fix…

//just works
//also alternate CSS syntax
$("#thing").css({
  opacity: 0.5
});

Now what’s wrong with this? Obviously, someone will have to point out that if you have scripts turned off, or if your scripts have failed (God forbid that {sarcasm}unlikely event{/sarcasm} ever occurs), your styles are useless. So would some CSS that was generated via abstraction be a better idea?
In this case, I think it would. I think this example proves that SASS is worth something, specifically in this evolving world of HTML5 and CSS3.

Grand Conclusion

So what do I think? I repeal my earlier comment, I think that I was pretty well humbled by the community in this case… which happens. This is not just an alternate syntax of CSS, it is an abstracted language, and it provides a lot of ways to speed up your creation and maintenance of pretty well-designed stylesheets.

That being said, however, I will argue (in the spirit of Fred Brooks) that there is No Silver Bullet. In his blog, Chris Eppstein points out that there is definitely a learning curve, and a few other negative issues.

The ones he didn’t point out were the ones that I think are really arguments against abstraction in general, and I’ve mentioned them in this blog but will summarize them now.

  1. Abstraction does not always make your code more maintainable. Now you have to maintain the abstracted code and the generated code. If you need to debug, you need to see why your abstraction is off by viewing the source of your generated code. Now if the browser simply UNDERSTOOD this abstracted code, it would add yet another layer of debugging, when you have to make sure your SASS engine was parsing correctly. So the argument is essentially that standards exist for a reason. Changing the standard is tricky, especially when you use one platform to do it.
  2. Automating visual elements usually requires even more tweaking than stipulating those things individually. I won’t argue that there’s never a good reason to do it, but I will argue that you can’t say that you’ll save time in all cases when you attempt to automate multiple visual elements.
  3. Abstraction of markup in general (both html and css, or xslt and xml in other cases) tends to cause additional confusion, as content and presentation are supposed to be as semantic and specific as possible. At the same time, you lose some of the value of implicit styling when you are creating a stylesheet that essentially creates an explicit language out of your selectors, especially when you may have intentionally used non-intuitive methods to achieve specificity.

Do I think abstraction will save the world? No, especially not of markup. But do I think it could help certain people out in certain situations? Absolutely, and I think that if you’re a ruby coder, and you develop sites that would need these specific examples of markup, you’re hurting yourself by at least not checking this out.

More reading

There are some abstraction methods that I think would be just fine in maintaining implicit structure, namely the Zen Coding format (specifically ZenCSS), which only simplifies the basic elements of the language, doing away with a majority of redundant sigils.

As always, A List Apart beat everyone to the punch and wrote (arguably) a definitive guide on this back in 2007.

Keep from losing your mind with SVN

Apr 01 2010

There are a lot of version control systems out there, and to be honest, most of them have pretty useful guides on how to get them working. But over the years, I’ve had a lot of web people (namely designers, content writers, and SEO folks) ask me how to set up SVN on their systems, and in most cases those guides go right over their heads. This is not an insult to people who are too busy to learn the intricacies of version control, it’s a statement of the fact that most people who geek out about this kind of thing have a hard time speaking in simple English without a variety of jargon that makes the explanation more complicated than the question. So let’s get straight to it!

WTF is SVN?

There are a variety of version control systems, but SVN is SubVersioN, a system first developed by CollabNet Inc. The way the fundamental system works, you need a centralized server that runs a version of the SVN server application. The idea is that all of your code is stored on that server, so any number of developers can “check out” their code. This code is stored in what is called a “repository”, which stores not only the latest version of all the files, but every version that someone has ever “checked in” to the repository. This means that multiple people can work on the same source code without over-writing each other, and if you lose every single file on both your live site and your home site, it’s all safely stored in the repository.

There are a lot of different sites that collect the different services you can use. The best guide I’ve found so far is this one at Straw Dogs, that has the 10 best free available svn systems. I personally choose beanstalk, which is actually $15 a month if you want to do more than one repository, but it’s really easy to set up multiple users and you can actually view your files very simply through a web interface.

Note: there are other version control systems such as CVS and Git, but SVN is much more commonly integrated in the tools that I often see the aforementioned groups using, so this is the only system I’m going to describe here.

Make it Work

Now, assuming you’ve gotten yourself an SVN server set up, it’s time to integrate with your chosen application. In Dreamweaver, you’ll need to go where your sites are set up (you’ll need the advanced tab).

Here is the screen you should see:

As you can see, it only supports subversion, but your repo can be in a variety of protocols (http, https, svn, svn+ssh), so just make sure that you make it match the setting that your chosen service uses.

Now, as you modify files from the file manager, you will see a green check by a file when it is “checked out” for editing. After you’ve made the changes to your satisfaction, you can “check them in” to the repository, which will make a version of the file in the system. You have a small window to type a commit message, which is usually very useful for describing to other developers what you’ve done (eg, initial checkin, updating or changing systems).

Is that it?

For most developers in the range I had specified earlier, this is enough for your needs. Most of the time these developers are only changing files on a server that is not live, and once the site goes live, any changes are made as tweaks. This works fine, as you can upload your files to make sure they work, and then check them in once you’re happy with them. But there are systems that I think are more useful for managing changes.

Multiple environments

SVN is most useful when you’re using it to commit changes from a staging server of some kind. In my personal environment, I’ve set up XAMPP to create a virtual apache installation on my local machine. Then, the local versions of my files are in the directory that serves up the files from http://localhost/ so that I can make sure it works on my local machine before uploading to the dev server. This is especially useful when you need to make changes to the site and don’t want to see them on the live server until you’re sure they work. In this case, you work completely locally and check in and out all the files from there. Then you can upload them to the live site.

Auto-Push

I won’t go into the details of how to do this here, but there are a variety of methods that you can use to actually push files automatically from a repository to a live server. This allows you to develop in potentially three environments (which the standard for most serious application developers). In this version, you make all your changes and so forth on your local machine or a machine you’ve got ready for development. Then, when you feel like you’ve got a decent product, you can send it to the staging server, where your clients/testers can see a demonstration of the site. Once they’ve decided that what they’re seeing is what they wanted, you can commit those changes to the repository, which will update the files on the live site.

I feel like this is the best way to go, especially for sites with dynamic content in a database. In those cases, you can check out the changes on the staging server first. This is helpful, because in a lot of cases if you have a wordpress or other database-driven site, it’s fairly hard to synchronize database changes between different servers.

Ultra Meta

Mar 29 2010

Why Leon Paternoster doesn’t like Tumblr & Posterous – Monday By Noon.

This article taught me about Press This, which I am then using to post the link to that article. My brain hurts.

Voodoo Management

Mar 21 2010

This topic has come up a lot of times in conversation, and it just came up again when I was discussing something with my wife. I don’t know if this is actually an idea that exists in management training or concepts of leadership, but if it is, it’s related to “voodoo economics.”

The idea is that, like in voodoo, you experiment by trying a variety of things, mostly at random. For example, you try adding people to a department, or change various things. When you get results that you like, you stop changing, and write down that process, because now, that process is magic. That’s a spell (or grisgris, in the terms of voodoo). If you want to duplicate that level of success, you just imitate that process again, and hope the results turn out the way they had before.

The exact terminology is escaping me at the moment, but there’s a term for this particular type of thinking. It was observed in the natives of the various islands that the Americans inhabited during World War II. The Americans built their various bases on the islands, and gave them an unprecedented level of prosperity by paying them to use their land, and then at the end of the war they packed up and left. The natives used a variety of implements like native woods and housing materials to build structures very similar to the World War II era aircraft, because they had formed a logical connection between the physical representation of success and the success itself.

In short, I’m trying to make two points:

Just because you drive a really nice car, doesn’t mean your company is doing well.

Just because things are going well, doesn’t mean you shouldn’t think about changing them.

Keep these lessons in mind. A bubble is only formed when no one stands back long enough to say “hey what happens when we put too much air in this thing?”

Graceful Degradation or Progressive Enhancement?

Feb 26 2010

The HTML5 Spec is trudging slowly (yet inevitably) closer to completion, and CSS Level Three is being picked up by Mozilla at a rate almost equal to their Webkit equivalents. What does this mean for those of us who make a living building websites?

Simply put, we’re not all getting the same internet. As argued by the anonymous and yet ingenious Do Websites Need to Look Exactly the Same in Every Brower.com, different browsers will provide a different appearance of the same overall content and presentation. So we have essentially three choices.

  1. Screw the new features and stick with what we know will work across the board.
  2. Use the new features and ignore the old browsers, people on IE will just have to deal.
  3. Make a site that works on both new and old browsers, but provides a different experience for each

So Where Does That Leave Us?

A majority of the web is moving towards option number 3. This honestly makes a lot of sense, as CSS 3.0 may be delayed even further, and IE9 may just decide to only support a small margin of the features. HTML5, for that matter, might take another decade to be fully supported by any one browser, let alone all of the market share. So now the question becomes the following: do we design for older browsers and then add neat features that are supported by the newer browsers, or do we design for newer browsers and then let an “acceptable” level of compatibility fall to the older browsers?

This defines the current argument of the web community, and there are official terms for each side. A degradable design is one that has fallback features for older browsers, but is truly optimized for newer and more standards compliant ones. A progressively enhanced design is one that is built with the less standards-compliant browsers in mind, and then steadily adds non-essential components for newer browsers.

In My Opinion, The Argument Is Perhaps A Bit Premature.

As a musician and sound engineer of some years of experience, I was constantly asked to “mix for headphones” or “master this so it sounds good in the car.” Just like most musicians who have pulled a majority of their hair out in the vain attempt for the “perfect mix,” I can tell you with some level of authority (and with a hairline to prove it) that this holy grail does not exist.

That’s not to say we can’t strive to achieve it, but one way or the other, our product is going to inevitably be slightly different on some viewing platforms. Is this the end of the world? To quote my earlier resource… NO!

So What Do We Do?

For now, the internet is creeping towards a new standard, and it has (widely accepted) old standards upon which to fall back. I say that as of today (February 22, 2010), if your target audience is the majority of the internet (something like 62% of the market share), design your sites to be html 4.01 and xhtml 1.0 compliant, and use as much CSS Level 2 as possible. This doesn’t mean be lazy, or slack on the layout and semantic value of your content. it means simply do your best to make a decent, accessible website. Then, you can add text shadows, gradients, rgba colors, whatever you like to your stylesheets so that more technically savvy users are rewarded with a slightly “improved” look. Think of it as making your site accessible to people who haven’t upgraded. Treat IE6 like a screen-reader. If people can see it, and it makes sense, it’s good enough.

That being said, if you’re someone who only plans to impress the users who are on the latest version of their Gecko, Webkit, or Opera-powered browser, go full hog as soon as possible with the new features. The sooner we push the browser manufacturers and users, the sooner they’ll be forced to adopt the latest technology. Besides that, if you end up learning all of the advanced functionality of the new web technology a month late, you’ll be a year behind the curve in developing it.

So Wait, You’re Saying Both Sides Of The Argument Are Right?

Like anything else, I think this argument needs a healthy dose of perspective. Who are your clients? Who is their target audience? Who are you trying to impress?

If you don’t know the answers to these questions, find out as soon as possible! This is your due diligence as a digital marketer. If you’re hiring an interactive agency to do this for you, get this information to them as soon as possible. Give them your branding guides, your technical requirements, and any documentation that you have lying around immediately. Then, you can decide together whether your site should degrade gracefully across the spectrum of technology, or whether it should be enhanced progressively in order to provide the highest level of accessibility.