IT and Patience

There are a dozens of good reasons to start a website.  You've probably thought of some of the typical reasons: establishing your brand, always open for business, gain credibility, improved communication, automated customer service, etc.  These are all good reasons but there are other important reasons which don't get enough pub.  Here are 5 smarter reasons to start a website.

5) It Doesn't Cost As Much As You Think

A typical website needs two things: hosting (space on a server where your site will live) and a domain name (the site's address).   You can get both of these for less than $100 per year.  I've had good experience with FatCow and Yahoo Small Business.  They have tools which make building a website quick and easy.  If you can use Microsoft Word, then you can build a website.  Don't spend a lot of money on a fancy-pants designer at first.  Use other free tools like Google Analytics and Google Webmaster Tools.  Get a Google Adwords coupon code and drive some traffic to your site.

4) Showcase Your Work

I love the part in Office Space where Bob Slydell asks Tom Smykowski, "What would you say ya do here?" and Tom goes off about how he takes the specs from the customers to the engineers and has people skills.  Old Smykowski's problem is that no one knows what he does and therefore no one values his work.  Don't let this happen to you!  You do good work so you should show it off.  Prospects want to see that you have a track record of success.

This tip applies to you all working the 9-5 as well.  Start a blog or a forum and engage people within the company.   Openly discuss your challenges and ideas.  It may take a little effort but soon your boss will be asking everyone to participate and you can take credit for the whole thing :)  Don't violate any company/confidentiality policies though.

3) Be Contact Friendly

Ok, this one is kind of obvious but it still surprises me how many businesses don't have a website.  A business not having a website is like a person not having a cell phone.  Don't be that guy!

2) Content is King

Whether you own a trendy salon downtown or you write tax software in your spare time, the key to gaining clients is to extend your sphere of influence.  You have to participate in your community and the most effective way to do that is to write interesting, relative content.  Start a blog, forum, or wiki.  If what you have to say is valuable/engaging/entertaining, the audience will come and you'll become an expert in their minds.

1) Test Out an Idea Quickly

Ever have a bolt of genius hit in the shower in the morning?  Many people have good ideas but either 1) never follow up on them, or 2) spend a bunch of time/money on the idea without any certainty it will be successful.  A better alternative is to set up a quick website and see what kind of interest you generate.  Are people willing to leave their email address in exchange for more information?  If not, that may be a sign that your idea isn't as brilliant as you thought.  On the other hand, if you get a ton of hits and good feedback; then you can confidently invest further resources.  Don't worry about making the site perfect, just get it in front of some eyeballs and measure the interest.

It's a problem I see way too frequently.  Web designers don't build websites that are portable.  This becomes a problem when one tries to do real-world exercises like changing the directory structure or creating a test site.  Proper planning is the key to avoiding this problem, along with following some DOs and DON'Ts.

What's the big deal?

A web page has essentially two components: data and linked resources.  The data is usually the plain words/text on the page.  Linked resources are usually everything else: images, scripts, style sheets, anchor tags and iframes to name a few.

The crux of the problem is all about the path that the web designer uses to link to these resources.  An inexperienced designer won't spend any time planning how to lay out the directory structure of the website and will use hard-coded paths to the resource.  Let's look at an image for example.  When one wants to place an image in a web page, one uses the HTML 'img' tag with the 'src' attribute to define the location of the actual image file on the server.  An inexperienced designer will create the image like:

<img src='http://www.acme.com/images/pic1.jpg'>

This will work ok but it is very fragile.  If you wanted to change the domain name from acme.com to products.acme.com, you would have to go in and change the path in all the image tags on the site (along with all the linked resources that utilize the fully qualified domain name).  If you wanted to encrypt your content by using https, you would have to do the same thing.  If you want to move all your content to a sub-folder on the server (like if you were creating a test website), it is the same exercise.  You get the idea.  Basically, any time you want to move the site, everything breaks.

Use Relative Paths

A much better idea is to use relative paths for your linked resources.  If you page is named product.html and its located in the document root, an experienced designer will create the image like:

<img src='images/pic1.jpg'>

Here, the designer is defining the path to the image relative to the html document's location on the server.  This makes movement much simpler because nothing breaks as long as the relative relationship doesn't change.  In the real world, the relative relationship rarely changes, especially if any sort of planning is done.  It is much more likely everything will move all together.

DOs and DON'Ts

• DO use relative paths for linked resources
• DON'T hard code the fully qualified domain name
• DON'T hard code the path from the document root
  

 

Properly plan the site out, use relative paths, and have a little patience.  You will deliver a better product for no extra work.

Communicate Solutions' Data Center

Here at Communicate Solutions, we have a distributed "data center".  I use quotes because it's not like a traditional data center where all our servers are housed in a single climate controlled, key-card secured room in South Carolina. Our machines are actually VPS's, located in different parts of the country and hosted by different vendors.  This works well since we don't have to invest in any specific hardware, get to pick and choose the vendor for the application, and get the traditional advantages of the data center (backup power, redundant data, climate control, etc).  The only hard part is backing up the data from all these machines.  We used to do backups via FTP and boy was that a nightmare.  Custom scripts, password management, security issues, and flaky network connections meant headaches and less than ideal results.  What's a geek to do?

Cue Bacula

Bacula is the Open Source, Enterprise ready, Network Backup Tool for Linux, Unix, Mac and Windows.  It is what we implemented and it has been rock solid.   It's got centralized administration, backup, recovery, data verification, volume management, and messaging to name a few features.  The real advantage is the centralized administration of backing up diverse clients.  From one command prompt, I can backup my Windows and Linux machines.  The data gets encrypted over the wire and stored with compression, which keeps backup small.  Volume management means that I can define a retention policy and old backups are cycled out as new backups are taken.

The Catch

If there's any catch with Bacula, it's that the there needs to be a Linux box where the central console runs.  If you don't run Linux anywhere, sorry, you're pretty much S.O.L.  Other than that, there's a bit of a learning curve with the volume management stuff if you're not familiar with the concepts.  The documentation is exquisite though.

So if you're wondering how you're going to backup your data without losing your mind or spending an arm and a leg, definitely take a look at Bacula.  Because of it I can now sleep peacefully :)

P.S.

As Joel says, make sure you're backups are being tested with restores.  Otherwise its all for not!

 

Chrome has V8 engine

A couple months ago I wrote about how Google may be pushing its new Chrome browser by making changes to google.com.  Having done a lot of work in JavaScript recently, it got me wondering how Chrome intended to actually speed things up.  It turns out the key is their new JavaScript engine, V8.

V8 is the code name of the JavaScript virtual machine shipped with Chrome.  It is named V8 because it is supposed to be powerful like and 8 cylinder car engine.  I did some googling and found a video where the V8 tech lead, Lars Bak, explains how it is fast.

 

Why is V8 fast?

There are primarily three techniques V8 to improve the speed of execution of JavaScript in Chrome:
1. Hidden Objects
If two objects of the same type are created, a third, hidden object is created which links the two child objects.  The key reason for doing this is that it helps generate efficient machine code.

2. Dynamically generated machine code
When V8 parses your JavaScript, it doesn't generate an intermediate byte code as most engines do.  Instead, it generates native machine code (assembly).  This is much faster since there is no interpretation step.

3. Precise garbage collection
Lars says that memory is reclaimed incrementally so there are minimal pauses or hiccups in the browser when using a complex JavaScript application.

 

When is it not fast? 

As Lars explains in a MSDN Expert to Expert video, V8 is optimized for the most common JavaScript programming patterns and operations.  If your JavaScript program uses infrequent operations, V8 could experience very slow performance.  An example of an operation which could slow things down is deleting/re-adding object properties.  V8 is standards compliant, so it will work but it might not be fast.  "If you write that kind of code, we want to penalize you", mentions Lars with a chuckle.  He also goes on to say that this is how it works in the initial version and it could be changed in future version.

 

The Verdict

V8 and Chrome definitely sound cool.  Lars doesn't strike me as an architecture astronaut so the future looks bright.  However, the technology is so new that I wouldn't yet recommend it for most users.  Honestly I haven't tried it out yet myself.  I'm pretty happy with Firefox and especially all the extensions that are available for Firefox.  I am planning to run my web app's test cases in Chrome in the near future... I'll be sure to post the results.

 

Bonus JS Architecture Talk

Can't get enough?  Check out this talk given by Ryan Dahl at the 2009 European JavaScript Conference.  Ryan describes NodeJS, a server-side JavaScript platform built on V8 which features purely asynchronous I/O and event loop concurrency.  The main program never waits on I/O... giggity.

This is Part II of a two-part series on WYSIWYGs.  In Part I, we covered what WYSIWYGs are and how they work.  In this article we'll look more closely at what happens when you save your changes and why they butcher/maim/ruin your code.

As mentioned in Part I, when it is time to save your document, the DOM gets translated to HTML and can then be saved to file or database.  The document is typically an inline frame (iframe) located within another web page.  Let's assume the iframe has the following HTML:

<html>
<body>
    <p>this is a test paragraph 1</p>
        <p>this is a test paragraph 2</p>
</body>
</html>

There's a few different ways to translate the DOM rendered by the browser to HTML which can be saved.  One way is to get the frame's innerHTML. Assuming the WYSIWYG is in the first inline frame, you can use the following javascript:

alert(window.frames[0].document.body.innerHTML);

 

Executing the above javascript in Internet Explorer would show a dialog like the one to the right. 

This method is handy for most situations.  The problems begin when you care about the markup that you originally wrote.  For example, notice any differences between the dialog to the right and the HTML snippet above?  One big difference is the paragraph elements are capitalized in the image even though they weren't capitalized in the HTML.  What the heck?!?  Another difference is the white space gets ignored when getting the innerHTML.  The second paragraph should be indented when compared to the first paragraph.  Annoying!!  Firefox is guilty of changing the markup too.  While Firefox is better at retaining white space, it changes all HTML tags from uppercase to lowercase.

This can be a nightmare.  Image you've spent some time developing a website with an IDE like Visual Studio or Dreamweaver.  Want your clients to be able to update the content themselves?  Well as soon as they do an update with the WYSIWYG, they're going to completely destroy your code's readability.  When you try to look at the code after your client's update, it could be completely different.  This is unacceptable.

I've decided to design a WYSIWYG that is friendly to both technical and non-technical users.  Whenever the client makes a change in the WYSIWYG, the change also gets reflected in the code without messing up the code.  This is done by maintaining a copy of the code along side the WYSIWYG.  Formatting stays the same.  Capitalization stays the same.  The code actually looks the same before the WYSIWYG update as after.  Imagine that?  No patience necessary :)

To see it in action, check out v1.6 of ePortfolio, the CMS for ASP.Net developers (coming soon!).  

Thursday's New York Times' Decoder article struck a cord with me.  In the article, Sergey Brin defends Google's stance on non-search-related topics like scanning out-of-print books, Microsoft, network neutrality, and Chrome.  Google's motto is to "not be evil" but lately I have to question their methods.

Chrome is clearly something that Google is pushing hard.  Google.com is my homepage and I've frequently seen the ads pushing me to try Chrome because it is so much faster.  I use Firefox (v3.5.3) and lately I've noticed that google.com is much slower to load.  In the last few days, it seems like the page is loading differently; the logo and the search box appear immediately and the other links 'fade in' a few seconds later, like after I move my mouse.

I suppose it's possible that Google thinks they are making improvements to google.com.  Maybe it is a better design in the long run.  I'm not sure I buy that though.  Right now it is clunky and annoying.  It seems more likely to me that Google is incorporating fancy (and unnecessary) Javascript into their site and don't care if it runs slowly on Firefox.  After all, supposedly Chrome's big advantage is its Javascript performance, right?  Is this the right way for a company to push its agenda?

On this subject, I say ok.   As a website developer, Javascript performance is important to me and this may be Google's way of forcing the issue.  The point is that there clearly is an agenda here which needs to be scrutinized and shouldn't be overlooked because of their friendly motto.

In today's article, I'll begin a two-part series on WYSIWYGs.  In part I, I'll explain what a WYSIWYG is and how they work.  In Part II, I will explain a shortcoming of the current implementation and my goal of improving the WYSIWYG for my content management system. 

What is a WYSIWYG?

WYSIWYG stands for What You See Is What You Get.  Pronounced wiz-ee-wig, it is a control which is used for creating rich text documents.  When you make a change to the document, that is how the finished document will look.  You don't have to write any code to make the document look like you want.  Almost all WYSIWYGs claim to have an interface similar to Microsoft Word.

Most WYSIWYGs are found on websites.  Even if you didn't know what a WYSIWYG was, you've almost certainly used one.  Most web-based email clients like Gmail, Hotmail, and Yahoo mail have WYSIWYGs for creating email.  

WYSIWYGs Under the Hood

Most web-based WYSIWYGs store the document as HTML code.  They make heavy use of javascript to manipulate the document DOM.  For example, when you highlight a word with your mouse and click the Bold icon, essentially what is happening internally is that the WYSIWYG finds that word in the DOM, removes it, and creates a new child node for the bolded text.  You can think of it like this:

Before:
<p>This is some text in my paragraph</p>

After:
<p>This is some <b>text</b> in my paragraph</p>

Of course you don't have to worry about the <p> and <b> tags, the WYSIWYG does it all for you.  You just type, click, highlight, and format to get the content to look how you want.

When you're finally done editing, you need to save the document.  As I mentioned above, the WYSIWYG stores the document as HTML code.  So, what happens is that the DOM gets translated to HTML.  To do this in Internet Explorer is to use the innerHTML property.  This property returns an element's inner HTML.  The HTML can be written to file or database.  The next time one wants to edit the document, the HTML gets rendered into the DOM and we are back where we started.

HTML to DOM, DOM to HTML.  This cycle can be repeated as needed.

That's it!

WYSIWYGs allow people to quickly and easily create content without having to write code.  Now that we know what a WYSIWYG is and how it works, we can talk about strengths and weaknesses.  Tune in next time for Part II where I'll discuss why this implementation won't due and how we're trying to improve it for ePortfolio.

Check It Out

As I've mentioned before, marketing is not my strong point.  It would be an understatement to say that marketing is Seth Godin's strong point.  Seth's blog is very highly regarded.  The topics of the daily posts about marketing and the way ideas spread are really insightful.  They always make me think.  Definitely addicting and worth it :) 

It's been a while since I posted but I promise I have some good excuses.  I got married (!), went to the Dominican Republic with my beautiful new wife, and took some additional time off to work on my golf game :P  While my golf isn't anything to write home about, I'm definitely excited to get back to work.  It feels good to have recharged batteries! 

I'm happy to report that the number of ePortfolio downloads has steadily increased since we last spoke.  Sales are sluggish but I am still encouraged.  We've got some great feedback that will keep things going in the right direction.  First and foremost is implementing a full-fledged WYSIWYG.  It seems like an obvious missing feature in hindsight.  Here's a link to a Stack Overflow post that lists the most important features of a content management system.

Finally, I'm going to try write about some of the more interesting articles related to this blog's content.  I'll start off with an author my co-workers are probably sick of hearing me quote.  Joel Spolsky, of Fog Creek Software, started writing a blog back in the early 2000's called joelonsoftware.com.  One article that I've used in real life countless times is the Joel's guide to hiring.  I love it.  I don't copy his process word-for-word but the high level objectives are spot on.  This is highly recommended reading for technical people responsible for participating in the hiring process.