The GLUEineractive Blog

Freshbooks - My new best friend

Mon, Sep 8th 2008, 22:51 PDT

If you do any sort of freelance work, you'll quickly run in to some logistical headaches. Namely, creating estimates, sending invoices and getting paid. You'll often have clients scattered all over the country, trying to coordinate client relationships & paperwork quickly turns in to a massive headache. I ran in to the same issue, until I discovered Freshbooks.

Freshbooks is your one stop shop for all your freelance needs. You get to create lists of clients with contact information, easily send estimates to them & track their payments to you. This is a service that a lot of websites provide, but what really impresses me with Freshbooks are the little things.

Your clients can log in to your own branded (colors + logo) account center, where they can view their estimates and pay their invoices.
Freshbooks integrates in to a dozen payment gateways, including Verisign, Authorize.net & Paypal.
You can upload your print-quality logo, and Freshbooks wil snail mail your clients your invoices for you!
Freshbooks also lets you track your expenses like hosting, which you can then rebill your clients for.
Time tracking is included, which isn't unheard of, but Freshbooks gives you OSX and Vista widgets to help you track your time.
Freshbooks even has a support system where your clients can open tickets, you can track the time on those tickets and then bill your clients for that time.

I could go on and on, but you get the idea. Freshbooks takes all the historically confusing and time consuming tracking needs of sending estimates and invoices to your clients, and offers a solidified piece of tracking software that's both easy to use and highly powerfull. I don't want to have to worry about emailing invoices, tracking clients and trying to figure out if I got paid or not. That's why I use Freshbooks, it takes care of that for me.

Using jQuery Inside Your Firefox Extension

Thu, Oct 30th 2008, 22:17 PDT

For a project a work we've been building a Firefox extension. It's slow, tedious work, with lots of time spent in the breakpointer functionality of Venkman. Thankfully Firefox extensions are basically javascript, and as I heard rumors of, you can embed jQuery inside of one.

How? Well it's quite simple. In your overlay.xul file, just include it like you would any other js file.

<script type="application/x-javascript" src="chrome://extensionname/content/jquery-1.2.6.min.js" />

Yup, that's it! Now you have access to all the usual jQuery functionality like element.click(), element.attr() and even the $.ajax calls, all within the scope of your extension. Thus, you can write extension code like this:

$('.toggle').attr('disabled', true);

Where it will select all XUL elements in your extension with the class toggle and set the disabled attribute to true.

If you want to have access to the browser DOM, you can access it via the document.defaultView attriute globally. Most times the defaultView variable is available inside of the event object if you've bound to one. Then, in order to effect the browser DOM, all you have to do is make use of the (often ignored) 2nd parameter of the $ function, the conext you'd like jQuery to work in.

In our case it's the browser's DOM. For example, to highlight all links on the page that are rel=nofollow, you just have to do this:

doc = document.defaultView;
jQuery("a[rel='nofollow']", doc).css({border: 'dotted 1px red', backgroundColor: 'pink'});

Now you have the power!

Using a Site Layout with the Sinatra Web Framework

Thu, May 1st 2008, 21:31 PDT

The Sinatra web framework is very elegant, yet powerful. Once installed, all you have to do is map urls coming to Ruby functions, inside of which you can write ruby code to do just about anything.

get '/' do
  haml :index
end

In this exampple, it uses Sinatra's built in haml function to run the ./views/index.haml template. But you can add whatever ruby code inside the functions you want, such as "hello world," ActiveRecord or accept a form POST.

The one thing missing was the ability to have a sitewide layout, that would wrap the output from your routing. I searched the Sinatra documentation over and over, finally finding the layout function. There wasn't much there, but playing around with the code I managed to figure out how it works.

By default, Sintara will look for a ./views/layout.ext file to use as a template, where "ext" is replaced with your templating-system specific extenstion. For instance, if you're using erb it's layout.erb and if it's haml you use layout.haml. If you just return markup with your route, it will not use any template file.

Now, if you want to use a different layout than the standard one, you'll have to specify that in your template function like so.

haml :index, {:layout => :special}

That's it!

Hope this helps some people trying to figure out layouts in Sinatra.

Why You Should Use Persistent Connections with MySQL

Fri, Apr 4th 2008, 21:33 PDT

If you do a search at Google for connecting to MySQL with PHP, every single tutorial you'll find uses the mysql_connect() function. This makes total sense really, since it is the defacto-standard connection function for PHP. And for most applications (read: low-volume) it works well, and most developers never have a problem with it. You can start to run in to problems when your site starts getting traffic.

This same problem recently happened at my day job. Our current site was mostly coded by the previous head developer, who more-or-less designed, developed and coded the entire thing himself. While this is an amazing feat to say the least, the site just wasn't coded as efficiently as it could be. The old developer just didn't have time or expertise with CakePHP to do a thorough and efficient job. A lot of the pages on the site generated lots MySQL queries, often times in the triple-digits. Initially we didn't really notice a problem with the site. Sometimes things were slow, but because our traffic was relatively low and we were on very high-performance hardware, speed and efficiency wasn't an issue.

That's changed over the last year, however. Our traffic grew by about 40%, tables were getting bigger with more rows. As such, our site was starting to slow down. I did what I could optimizing pages to minimize the load on the database, but things were still slow. Watching the load on the database server, it would often spike to 8-10 with 90% CPU usage. Not good.

It's about that time that I decided to look in to persistent connections. In a nutshell, persistent connections keep (Apache's) connections to the database open even after the data transfer has ended. Database connections and closes are expensive for the database, so keeping them around (making them persistent) to reuse instead is where you get your performance imporvement.

Happy with my research, I decided to give it a shot. I switched over our mysql_connect() to mysql_pconnect(), restarted our database & web server and waited. The results were magical. Load & CPU usage on the DB server lowered, the load on the web server lowered and the site was at least 2-4 times faster. Awesome.

Persistent connections are faster than normal connections. So please use them.

Some things to think about

This isn't to say that persistent connections don't come with their own set of problems. There are a few things that you'll need to consider when using persistant connections.

Transacitons - Since the connection to MySQL is continually open, if an Apache process begins a transaction and it never commits or rolls back, all of the mysql queries that particular connection does will be considered part of that same transaction. This is bad. You can solve this by creating a register_shutdown_function() that does a database rollback. The PHP manual page on persistent database connections has a fair amount about this.
Open Threads - Since you're only going to have a limited number of MySQL connections open at a time, you have to be careful not to run in to a situation where Apache is utilizing all your current database connections and it then tries to connect to MySQL again. There won't be an available MySQL connection for it, and thus Apache will be blocked and has to wait until it can serve the request. Just make sure that there is always slightly more database threads than Apache threads.
mod_php - Persistant connections are only supported if you're using PHP in the mod_php variety, and not the CGI wrapper. Most shared hosts and default PHP setups use mod_php, so you should be in the clear with this.

In general, though, persistent connections are pretty safe. Give them a shot on your web app and see how it preforms.

CakePHP Best Practices: Rethinking the hasAndBelongsToMany Association

Thu, Mar 27th 2008, 21:33 PDT

When you're first learning about CakePHP (or any kind of MVC associations), the hasAndBelongsToMany relationship is a powerful one. In a nutshell, it allows you to associate one model to another, without making it an exclusive association. So for example...if you're building a tagging system for your bloging platform, a Post --hasAndBelongsToMany--> Tags. The CakePHP manual chapter on models has more information if you're still a little confused.

And in most cases, this association works well. You define a "join table" that contains 2 fields, as in our blogging example, a post_id and tag_id columns. Thanks to Cake's built in framework code to handle this association, you're up and running in no time.

But what happens when you need to store more information about the association? For example, imagine if you're building an online ordering system. Orders can contain multiple products, so you'll need to say that an Order --hasAndBelongsToMany--> Item. But each Item/Order association also needs to have some other ancillary information - such as the price the customer paid for that item on that order. With the traditional hasAndBelongsToMany relationship, you can't do that.

To solve this, we're going to borrow from Rails once again, utilizing the principal of their hasMany :through functionality.

Basically, we're going to upgrade our hasAnyBelongsToMany association and put a full fledged model as the join. So rather than having just a join table that associates two models, we're going to put a real model in between and associate the two other models to it. As in above case of our online ordering system, we'll stick a LineItem model in between.

First, lets define our Order model.

class Order extends AppModel { var $name = 'Order'; var $hasMany = array('LineItem'); }

Now our Item model.

class Item extends AppModel {

  var $name = 'Item';
  var $hasMany = array('LineItem');
 
}

Note that an Order & Item --hasMany--> LineItem? Well here is the LineItem model.

class LineItem extends AppModel {

    var $name = 'LineItem';
    var $belongsTo = array('Order', 'Item');

}

Basically, now an Order has many LineItems. And each Item is also has many LineItems. Conversly, each LineItem belongs to an Order and an Item.

The cool part about is that since your "join table" is now a full fledged model, you get all the things that come with a model - like a real database table, other associations, attributes, primary keys, etc. Adding that "price" attribute for each Item joined to an Order is as simple as adding a price column to the line_items table.

With this method, however, comes some lack of convenience. With the default Cake hasAndBelongsToMany relationship, if you want to save an Order and all its associated tags, you just add an input field (like a multiple select) with data[Item][Item] in the Post form, and Cake does the rest.

With this new method, you can still have the multiple select in your Order add form, but you'll have to add some extra code to handle the incoming data[Item][Item] data and save an associated LineItem models. It's just a little bit of overhead, but well worth the flexibility you get with the hasMany :through method.

CakePHP Best Practices: Fat Models and Skinny Controllers

Tue, Jan 22nd 2008, 21:30 PDT

Since I've been doing a lot of Rails work, I've been doing a lot of reading on Rails and MVC frameworks best practices. One of the base principals the Rails community that I've come across more than once is the "Fat models and skinny controllers" methodology. Say what? Let me tell you.

When you first start working with MVC frameworks, you're first instinct is to put nearly all your code in the controller. It makes sense really - it's the first line of defense when someone runs a function on your site and it has direct access to the model & all of its useful helper functions.

The problem with this methodology rears its head after a few days of coding. Your models are still very skinny, but your controllers end up being hundreds of lines long. They're "fat", full of lines and lines of code like this...

$review_cond = "Review.model = 'Artist' AND Review.foreign_key = '$id'";
$reviews = $this->Artist->Review->findAll($review_cond, "Review.id, Review.review, Review.score, Review.created, User.id, User.name", "Review.created DESC", 5, null, 0);
foreach ($reviews as $review) {
    $this->mrClean->cleanArray($review['Review']['review']);
}
$this->set('reviews', $reviews);
$this->set('other_reviews', $this->Artist->Review->findCount($review_cond)-5);

Good code should be easy to read and should communicate intent quickly. That code does neither. I actually wrote the code above a long time ago and it took me 2 minutes just now to figure out what that code did! That's not good. Now imagine if you had a coworker or someone else tried to read that code? They'd be at a total loss.

While Cake's built in model functions like findAll() are nice and very helpful (we'll still use them when we recode this), when you fill their parameters chaulk full of hard to read arrays and long strings, all meaning of what that line of controller-code does goes out the window.

The answer to fat controllers is to make your model fat instead. The model is supposed to represent some object. In the above code sample we're trying to get an Artist's most recent reviews, so we should be asking the Artist model to do that for us.

With that in mind, here is the same functionality achieved from the previous example put in the Artist model...

function getRecentReviews($number = 5, $sort = "created DESC") {
    $conditions = "Review.model = 'Artist' AND Review.foreign_key = '".$this->id."'";
    $fields = "Review.id, Review.review, Review.score, Review.created, User.id, User.name";
    $this->Review->recursive = -1;
    return $this->Review->findAll($conditions, $fields, $this->name.".$sort", $number);
}

Then in your controller, the only code you need to write is...

$this->Artist->getRecentReviews(5);

Muuuuuuuuch simpler. Anyone coming along can easily tell what that section of code in the controller is doing - simply by reading the name of the function. This is what people are talking about then they say code is "self documenting" - the name of the function tells you what the code is doing. The same code that was in the controller is still there and now in the model. By putting it there, it forces you to think how to abstract its functionality & makes it reusable for the future.

Skinny controllers and fat models isn't exactly a new idea in the CakePHP world, but it is one that's facing slow adoption. As I see it, the main reason for the lack adoption is the absence of model behaviors and focus on controller components in the current stable version of Cake (1.1). Without some custom coding, there really isn't a way to quicky and easily utilize 3rd party code to extend your model and inherit additional functionality. Thus, you think of models only as a place to declare associations and validation.

People coding in 1.1 still make heavy use of components and as such get used to putting a large portion of their code in the controller. That will change as 1.1 gives way to 1.2, and CakePHP and its community evolve in to a more robust and adult web framework, but for right now try your hardest to have fat models and skinny controllers.

10 Steps to Becoming a Professional Web Developer

Fri, Nov 30th 2007, 10:45 PDT

When I started my day job as a web developer at a Seattle-based SEO company, I was assisting the one and only other developer at the company. He had been the sole developer for the company since they started doing web dev, and as such did things they way he'd always done them. Since I had learned most of my skills doing small time freelance work, our development process was the same as thousands of others amateur web developers.

All development work is done on the production server;
No code is under source control;
FTP is the main file transfer development medium;
Most applications are coded in a home-brew, non-reusable manner;
Almost no quality control or testing.

I always knew there had to be a better way. It's not that the way we had been doing things didn't work - it did. It's just that we could be doing things so much better. Working smarter, not harder. So when the other developer left and I got put in charge, I made sure we put in place the measures and structure to have a solid, organized and professional development department.

If you too want to stop being an amateur web developer, and work smarter, here are my top 10 things to do.

Use Source Control
It doesn't matter if you're just one developer working by yourself on your own project - everyone can benefit from source control. It is, hands down, the easiest way to manage all of the various code revisions that you will encounter in your project. Not only can it help you track all of the changes over time you've made to your application, in the event that a new change goes awry or you accidentally delete a file (or twelve), source control makes it easy to revert to before your blunder. The current top choice for source control is Subversion, an open source package meant as a replacement to CVS.
Institute testing
Far too my times, amateur developers are eager to push their new product out the door before it's ready for the big time. It's a common mistake; one where your emotions and over eagerness will get the best of you. Often times, however, an extra 10 minutes of time with your product will help you find the larger and more obvious errors that your client will catch first. And if you want to get even better with your testing, look at test driven development.
Stop developing on the live site!
Usually out of convenience, developers will build the site on the final production server. This starts out being a good idea, since you're building the site in its final resting place, but what happens when you need to add a new feature or fix an existing bug? You can't turn debugging on for the live site, nor can you really use dummy test data in the production database.

So what's the answer? Create a development cycle. Locally, replicate as best you can the live production environment. Give yourself a local development database & installation of you web server. Then, once you've got that bit sorted out, create some process to deploy your code to the production server. I'd recommend either rsync or some other scripting language that just checks out a copy of the source from version control on the production server.
Use a bug tracker
The key to writing great software is documentation. Not only does this include well documented and commented code, but also documentation of problems and issues that have been found and/or fixed. When the user of your product reports an error, document it. Save the exact email, write some notes about your initial ideas on the cause of the problem & write down potential fixes. Then once you've found your bug and squashed it, you mark the issue as resolved and archive it. Next time something breaks or you want to know how you fixed a similar problem, you'll have it documented.
Lean the command line
Good developers don't just use a text editor to develop, they utilize command line tools to work smarter. Creating files, interacting with the database, running scripts and checking error logs. All these things can be done quicker and easier in the terminal. If you don't currently use the terminal or have any experience using command line tools, it can be a little daunting to get started. But take it slow, do a lot or reading and you'll find yourself spending more and more time in a text-only world.
Utilize better server tools
Between dealing with down time, performance issues and bugs, running a popular site can give you an ulcer some times. But it doesn't have to be that way. If you can think of a difficult and stressul situation to deal with, nine times out of yen there is a tool to help. Here are a couple of my favourite.

High server resources? Check out Monit or God. Both monitor your server, and if the CPU usage or memory has gotten too high, or Apache stops responding, it will email you with notification. It's very flexible, to the point of it being able to actually restart Apache or other services if things get too crazy. The little brother of Monit is montastic, which can monitor your server remotely. If Montastic tries to connect to your server returns anything other than the expected 200, you'll get an email.

The other really awesome piece of server software is RCS. It is like a stripped down version control system, meant to version control individual files. So if you're on your web server and making a bunch of changes to your vhosts.conf file for Apache, RCS will store each iteration of the file for you. Thus, if you mess something up or need to look back at a change you made a while ago, it's as easy as a few keystrokes.
Talk with other developers
A lot of web developers out there tend to operate in a bubble. They'll pick up some programming knowledge after reading a book on PHP or something, but then never, ever, move beyond that. They'll continue, often years at a time, programming and developing the exact same way as they always have. While it's perfectly acceptable to stick with what you know, this is a dangerous phenomenon. Languages improve, security holes are found and fixed, new tools and techniques are developed and mature. You need to keep up with the times.

The best way to do that? Talk to other developers. There are plenty of blogs, forums & mailing lists that offer a wealth of knowledge. People discuss new technologies, bounce ideas off each other, ask for help and give feedback. It's a very creative and invigorating enviornment full of really smart people creating really great tools. Being part of their conversation, or even just listening to it, is one of the best things you can do.
Utilize a web application framework
This is a simple, but often life changing realization. I know far to many web developers who still create client websites as one-off pieces, custom coded each time to their clients specifications. People...this is a waste of time! I can guarantee you that at least 80% of the coding you do is repetitive, and you'll be much better served utilizing a framework.

Web frameworks are libraries of code, usually in the Model/View/Controller (MVC) pattern, that offer you a solid base to build your application on. Database connections, templating, basic CRUD operation and much, much, much more is taken care of by the framework. All you have to concentrate on is the fun stuff: creating creative solutions to the clients unique problems.

There are plenty of frameworks out there, but personally I'm a fan of CakePHP for my PHP work, and obviously Rails for my Ruby work.
Read, read, read
Never, ever, be satisfied with your level of knowledge. There is always more languages to learn and more technologies to master. If you've got a good gasp on PHP, see what Ruby has to offer. Spend some time getting more accustomed to some MYSQL functions. Pickup a book on XLST. Whatever. Just make sure that you're always learning and advancing. Not only will it help you become a better developer, but you'll have a diverse catalog of tools and techniques in your bag of tricks. You'll never know where one will come in handy.
Become a jack of all trades
The days of "I'm just a design guy" are over. A lot of developers think that they should just concentrate on one language or one discipline, and then try to be the very best at that one thing. That works well if you want to be some DBA admin stuck in a back office somewhere in a mega insurance company. The real development and creating happens by people who are multidisciplinary.

Have a strong design and read and write PHP. Be a sysadmin who know how to troubleshoot Apache, but can also understand the product life cycle. There is no magic formula of talents that guarantee your success, but as long as you don't pigeonhole yourself in to one field you'll do just fine.

Alright folks, you got everything you need to become a professional web developer. Go check out some of the items I linked to, read up on them, and start incorporating them in to your development cycle. The best way to get better is to learn by doing.

The Difference Between Good Code and a Good App

Wed, Jan 2nd 2008, 01:11 PDT

Over the past few days I've been armpit deep in the source files of Wordpress, one of the worlds most popular and customized pieces of blogging software. I've been reading documentation, examining the database & navigating my way through the many PHP files of Wordpress - the end goal being a plugin which interfaces with Pligg, a popular open-source social media (read "Digg-style") piece of software.

Considering that Wordpress is 4 years old, has a half dozen full-time developers and has many high profile users, I was expecting to find some quality code underneath it all. When I did lift the hood, I was astonished as to what I found...

$wpdb->query("UPDATE $wpdb->users SET user_activation_key = '$key' WHERE user_login = '$user_login'");
$message = __('Someone has asked to reset the password for the following site and username.') . "\r\n\r\n";
$message .= get_option('siteurl') . "\r\n\r\n";
$message .= sprintf(__('Username: %s'), $user_login) . "\r\n\r\n";
$message .= __('To reset your password visit the following address, otherwise just ignore this email and nothing will happen.') . "\r\n\r\n";
$message .= get_option('siteurl') . "/wp-login.php?action=rp&key=$key\r\n";

if (FALSE == wp_mail($user_email, sprintf(__('[%s] Password Reset'), get_option('blogname')), $message)) {
    die('<p>' . __('The e-mail could not be sent.') . "<br />\n" . __('Possible reason: your host may have disabled the mail() function...') . '</p>');
} else {
    wp_redirect('wp-login.php?checkemail=confirm');
    exit();
}

For you non-programmers out there, that piece of code processes a request to reset the password of a user's account. Any programmer who has more than a couple years experience knows the code is doing many things wrong: namely raw SQL and HTML email code interwoven with PHP. Now I understand that Wordpress was written from scratch, and forked from a codebase that was originally written before the MVC architecture was common practice, but come on! That code is horrible!

Yet the worst part, aside from all the bad syntax and complete disregard for an coding best-practices is the lack of any kind of code comments or documentation. Anywhere. I'd guess that maybe 10% of any of the functions in Wordpress have any sort of comments above them and probably only 5% of those shed any real light on what the function does. It's only been through my long history tinkering with PHP applications and liberal use of the grep utility that I've been able to make heads of tails about how Wordpress functions internally.

To be quite honest, Wordpress is probably in the bottom 10% of quality in terms of software source code that I've ever seen.

This begs the question, "If it sucks so much, why is it so popular?"

Well, it's because Wordpress does its public-facing things incredibly well. Themes, plugins, ease on install, UI, community, etc are all created in (I hate to say) beatufil and elegant ways. From initial install to creating your first blog post, the process for the end user is spot on. And thanks in simple easy to read code and great documentation, creating themes and plugins is simple and painless.

This is a prime example of why success in writing and selling software is contingent on the quality of the user experience, and not the quality of the code behind the user experience. Like Microsoft, Wordpress figured out that in order to have successful software, you don't need to write the best source code. Instead, you need to create the best and easiest customer experience. This is why Linux is hands down better software than anything Redmond will ever write, but it's still looking for that mainstream acceptance. The end user's experience using Linux is still a few generations behind the ease of use of Windows.

It's as if a car owner likes their car based solely on the fact that the interior looks nice and the car is easy to drive. Never mind the fact that the car could be powered by an engine from a 1930s lawnmower. As long as the user has a good experience, and the technology powering it "just works," they could care less to look under the hood. Which to me sounds idiotic. Even though you'll never have to deal with it, don't you want the best quality engine under your hood? I would.

The reason software can get away with a quality user experience, but crappy engine, is that as consumers go, 99.9% of them wouldn't know the difference between quality professional source code and something like Wordpress. It's not that they can't look under the hood - they can. They just don't know how to make heads or tails of the code once they do.

Unlike nearly every other kind of technlogy and engineering in the world, programming is all virtual. You can't feel software to see if it feels heavy or "well built." You can't examine the source code to see if it looks worn or needs replacing since, well, software never wears down. Once "it works," it works.

My point in all of this is why you should care. If the source code works, won't age or break down and my experience as an end-user is great, why do I care that the underlying code is awful? Because it makes moving in any direction from where you are that much harder.

Crappy code make it harder for the Wordpress team to develop and maintain the code base. Crappy code means less care is taken by developers to be effecient, making scaling for high-volume webistes harder. Crappy code makes it harder to upgrade to new versions of Wordpress. But most importantly, crappy code makes understanding and preventing security holes by the development team very hard. A problem that has bitten Wordpress in the butt a few times before.

All in all, for moest people the things in the above paragraph won't matter. They'll install their blog on their web hosting and blog for 6-months and then get busy with other things. But if you're looking to use some open source software like Wordpress for your next website, consider looking beyond the user-facing functionality and see what lies beneath the hood.

Using Your rsync.net Account as a SVN Repository

Fri, Jan 4th 2008, 01:25 PDT

The guys over at rsync.net do a fantastic job. For literally a few dollars a month, you have a remote file system that serves as a great backup, file host & now as a SVN repository. rsync.net gives you some very basic instructions on how to do this...

Yes. The svnserve command is available for you to run, remotely, over
SSH. This means that you can upload a repository with rsync or sftp and
then
access it remotely with any tool that supports the svn+ssh:// URL
format.

This is pretty straight forward, but I'll save you some headaches and help you get up and running.

To get started, use svnadmin to locally make a svn repo on your machine.

svnadmin create myrepo

Now, SSH in to your rsync.net account to start svnserve. Note: that you'll have to change your username and host to yours from your rsync.net account.

ssh 8058@usw-s008.rsync.net svnserve -d

The -d part starts svnserve in "daemon mode." Checkout svnserve --help for more options.

Now you'll need to rsync your local repo to the remote folder you want to house it. In my case, all my repos are in the "svn" folder off my home.

rsync -avz myrepo 8058@usw-s008.rsync.net:svn/

The -a tells rsync to operate in "archive mode," which basically says you want to recursivly transfer and preserve most everything. The -v speficies verbose output and the -z specifies the transfer should use compression.

So now your repo is located remotely on your rsync.net host. Here's the magic command to access it.

svn co svn+ssh://8058@usw-s008.rsync.net/data2/home/8058/svn/myrepo localfolder

Please note the following...

SVN is using the svn+ssh protocal
Username 8058 at the beginning of the address
The data2/home/8058 to access my repository on the file server. I got this by running the pwd command. Using ...s008.rsync.net/svn/myrepo will not work.

If you did everything correctly, you should be able to checkout just fine. If you have any questions, feel free to shoot me an email.

Welcome to GLUEinteractive

Mon, Sep 17th 2007, 00:49 PDT

Hello, and welcome to GLUEineractive! Today we're blowing the doors off this place, letting everyone catch a glimpse of who we are and what we have to offer.

GLUEineractive is a different kind of web-design firm. We pride ourselves on taking a complete, holistic approach to creating your website. While many other companies fall short by exclusively offering design or development services, GLUEinerative has the skills to support you through the entire process of creating your website â�� front to back.

Therefore, we're able to provide you with the following services:

Web design and development
Brand Identity
Content Development and Editing
Information Architecture
Web Technology Consulting
Usibility Consulting
Online Media Relations & Development

If you're interested in having us help you with your website, feel free to drop us a line.

As for this blog - well, it's going to delve into the multi-faceted world of web communications. Aside from news and information about the service wing of GLUEinteractive, this blog will also cover topics such as the CakePHP framework, news on our side project TuneShout, online media relations, brand and content development, internet business and the online music industry.

So bookmark us, or subscribe to our RSS feed & keep up to date with the ever-evolving world of the web. See you back here soon!