When I joined Increo it was an entirely Mac shop. I was the only one who would be developing on a PC. Rather than worrying about potential compatibility issues and setting a development stack up from scratch, it seemed that the best approach would be to use a Virtual Machine running Ubuntu as my development platform.

The Pros of Virtualization:

1) Develop on the same stack as the production

This means that you can avoid running into issues with line endings, cross-platform quirks in parsers, etc. You know that you’re getting the same behavior locally that we will get on the server.

2) Portability: Single setup run from multiple locations

The VM is just a small set of files. You can pick up these files and copy them to another machine (or run them from an external drive) and always have access to your development environment. If you want to work at home on another computer, no problem.

3) Saved state

When you shut your computer down you normally have to close all open windows losing any state (unless the program itself saves it). You can simply shut down the VM and it will save the entire state of the guest OS, meaning next time you open it up, it’s exactly where you left off.

4) Don’t pollute the host OS with dev tools

Your computer stays clean. It doesn’t need a local web server or a local SQL server for development since that’s all on the VM.

5) Cross platform testing on a single computer

You can launch the product and test on either the host OS or the guest OS with a few simple clicks.

The Cons of Virtualization:

1) Lots of RAM needed

You should allocate at least 1GB to the guest OS if you are going to be developing on it. This means you’ll probably want 2GB or more in your computer.

2) Speed, some lag since not running natively

The guest OS isn’t quite as snappy as the host and you always notice a little bit of lag.

3) Mouse support

The back button on the mouse doesn’t work and it took a couple tries at editing config files to get the mouse wheel to be recognized. The mouse doesn’t behave the same way in the host and guest (although tracking speeds are thankfully the same) which can sometimes be frustrating.

4) The VM can’t use multiple monitors

There just isn’t a clean way to have the guest OS occupy two monitors, especially if your monitors aren’t identical. You can avoid this by running a browser, email, and other non-programming tasks on the host OS (on the second monitor) and leave the guest OS to use one screen for coding.

5) Focus can be confusing

Every one in awhile while working in the browser on the host, you’ll probably look over at the VM and see the cursor flashing in a text document and think that it is active. Then you try to type something only to realize that the host OS has focus and the VM does not.

A few days ago, we took a break from developing our own products and participated in SocialText’s Widget Wednesday, a “distributed hackathon for widgets and mashups.” All this means is that SocialText invited companies to participate in a day of coding micro-applications that would make use of their newly released OpenSocial Widget API. SocialText Widgets are simple tools that sit on your SocialText Dashboard, a personalized homepage for your corporate life, and are analagous to Google Gadgets which sit on your iGoogle homepage — in fact, they leverage Google’s gadgets.* API.

The hackathon was “distributed” in that all the participating teams stayed at their respective company locations and communication was done via an IRC chatroom and dedicated conference calls. For goodwill, SocialText organized it as a competition in which the winning team would win a gift certificate toward kiva.org.

After the opening conference call shenanigans, we dove right into coding. Now, I love what I’m currently working on for Backboard, but getting to work on a miniature side-project was very refreshing. I got to play with technologies I hadn’t yet explored and learned how to make and deploy widgets. One of the tricky things about creating a widget is that it doesn’t sit on your site, so we had to do some refining of our own API in order to format and grab the data we wanted to display. After that, the rest was fun and easy: it turns out that making a widget is as simple as wrapping a little HTML and JavaScript in XML file.

At 4:30 pm (the “deadline” to turn in our projects) we dialed back into the conference call to join the show and tell session and presented our three completed Widgets. “My Backboards” is simply a listing of your backboards with recent activity. “Get Feedback” allows you to upload a document, set permissions, and create a backboard all within the widget. “LOLPirates,” Jim’s masterpiece, cycles through incredibly cute pictures of cats dressed up as pirates. Like Fluffy-beard here.

For young ambitious companies, it’s often hard to be the treated as the underdog, but at Increo we draw confidence from the supportive startup community and believe in giving back in any way we can. Our participation in Widget Wednesday was just one example of our philosophy — we fostered relationships with other startups and simultaneously strengthened Backboard and SocialText Dashboard.

This weekend I sat down and tackled the RAM problem: the amount of memory it takes the server to generate a single page of a website.

For Backboard, we have our server set up to allocate just 16 MB of RAM to PHP for the execution of each request. This allows us maximize the number of Apache processes we can run on a single server and thus maximize the number of users we support. To do this, though, means that the site has to be pretty light on its memory requirements.

Backboard, as a CakePHP application, has a theoretical minimum requirement for RAM: namely, the amount needed to execute a base installation of Cake. In our testing, this falls between 4 and 6 MB. The goal, of course, is to minimize anything above and beyond this.

Here are some concrete steps you can take to limit the RAM needs of your site:

Read the rest of this entry »

Over the coming weeks and months, we hope to provide an occasional window into the more technical side of Increo’s products and share some of the more interesting challenges we’ve faced and problems we’ve solved with the greater web developer community.

The topic this week is Flash 10, but please let us know if there is another technical aspect of Backboard that intrigues you and you want to know more about!

Now, to the story:

Starting a few weeks ago, we began hearing some intermittent reports from users that they could no longer create a Backboard by uploading a file. They said they kept clicking the “Select File” button and nothing happened. 

We were understandably disturbed, as the ability to create Backboards is rather critical to the site… but despite numerous attempts, we were unable to reproduce the problem. We were busily working on brand new Backboard functionality, and the reports were infrequent enough that we chalked it up to a potential incompatibility with another browser plugin. Or maybe they just had Flashblock installed and didn’t realize it? Yep, that had to be the problem.

Flash matters because we use the excellent open-source SWFUpload package to handle document uploads on Backboard. This allows us to not only customize the appearance of the upload buttons themselves, but also display informative progress bars as the file is transferred. Being a tight-knit combination of Flash and JavaScript, SWFUpload takes a bit of work to configure and integrate, but the results are well worth it.

A week ago, we located a computer that exhibited the problem, and it was immediately clear that it was an issue we could no longer ignore: the other Flash that we use on the site worked fine, but the Select File button did nothing when clicked.

After a quick check on the SWFUpload forums for news of recent incompatibilities, the cause was immediately apparent. Unfortunately, the solution was anything but…

Read the rest of this entry »