TeamLab Rolls Out Documents Management & More

Not that long ago I published a post called TeamLab vs Basecamp: A Project Management Duel where I looked through the pros and cons of the two project management systems. We all seem to know where Basecamp is heading, but today I’d like to give you a small update about TeamLab.

Just a quick note — TeamLab is a project and business management system developed by a company called Ascensio System SIA based in Latvia. They seem to be growing and definitely working hard on their product which is available in two flavors, self-hosted via the open source version, available on SourceForge and a SaaS solution hosted in the Amazon cloud.

The recent changes to TeamLab included new project templates, a real-time chatting module, some cool additions to the tasks area, and of course their brand new documents module with a neat integration with OpenOffice via a plugin. It doesn’t seem like they’re after the Google Docs market, but managing your documents inside your corporate portal without having to use third-party online and offline applications with files going back and forth is definitely a plus, although I’d personally prefer a full integration with Google Docs.

Quite user-friendly to me, though I can’t remember the last time I had to work with word documents or spreadsheets, heh, it’s all about code these days ;)

Now that they’re done with their Docs part, it seems like they’re after the CRM module, let’s see what they make of that. I had a bad experience working with 37signals’ Highrise API, though the application itself works like a charm. And the reason I thought about the API first rather than the web interface itself, is because I believe that the API is essential to any, especially web-based CRM system out there. I had my good days with SugarCRM, their SOAP API is crap, but it works, done a major website integration there ;) Watch out Salesforce!

Oh and for their next modules poll I voted for SCM integration. I’d really love to see a full-blown Git, Mercurial or Subversion integration. It seems like TeamLab didn’t have this in mind at all, while Basecamp have a big list of such extras already: Basecamp Extras: Software Development.

Cheers and have fun managing your projects!

How To Create a Remote Shared Git Repository

So Github doesn’t work for you? This article is about setting up a private, remote and shared Git repository for you and your team. I’m using Ubuntu 10.10 and 10.04, as well as Fedora Linux (assuming you replace apt-get with yum), anyhow this should work on all other distros with minor modifications.

I’m not going to tell you what Git is, and I’m not going to teach you how to use it. What I will do is guide you through the steps of setting up a Git repository on your VPS and giving you and your team access to that repository over SSH. You have to be familiar with the Git command-line client, so don’t come back and comment if you can’t get it right using TortoiseGit or whatsoever. So, without further ado.

Step 1: Preparation & Accounts Setup

This is one step you wouldn’t like to miss when setting up new repositories. You have to figure out a plan of what you want to achieve and do some initial setup on your VPS (let’s call this the Git server) and your local machines.

Let’s keep it simple for this tutorial — we’ve got small development team: John, Andrew and Robert; and we’ve got a project for which we’d like a git repo. So first of all make sure that john, andrew and robert have SSH access to the Git server. Let’s also keep them in a group called developers — this is the group who’s members will have read and write access to the contents of the repository.

$ sudo groupadd developers
$ sudo useradd -G developers -d /home/john -m -s /bin/bash john
$ sudo useradd -G developers -d /home/andrew -m -s /bin/bash andrew
$ sudo useradd -G developers -d /home/robert -m -s /bin/bash robert

This will create the three users and add them to the developers group. Go ahead and set some initial passwords for your team mates:

$ sudo passwd john
$ sudo passwd andrew
$ sudo passwd robert

And make sure that they can now login to your VPS over the SSH protocol.

Connecting to the Git Server Without a Password

The next step is optional, but really helps you save quite some time. I’m talking about SSH auto-logins, these will prevent the Git server from asking John, Andrew and Robert their passwords every time they’d like to push or pull something. I listed below the code for only John, so you should repeat the same for everybody else on the team. Lines that begin with the hash symbol # are either comments or command line output, you don’t have to type them.

So, get on John’s computer and start by browsing to the .ssh directory and creating an RSA keypair. More about RSA keys in Wikipedia.

$ cd ~/.ssh
$ ssh-keygen -t rsa -C ""
# Generating public/private rsa key pair.
# (text omitted)
# Your public key has been saved in /home/john/.ssh/

Great! Now let’s see the contents of the public key, should look something like the following

$ cat
# ssh-rsa AAAAb4kzaC1 (text omitted) 86n3iEEQ78cPVazr

Now what you have to do is copy the contents of the created file to your clipboard, we’ll have to write it to a file on our Git server. Start by logging on to the Git server as john (assuming it’s, proceed to the user’s .ssh directory and paste your public key into a file called authorized_keys (create it if it doesn’t exist). Save the file and close it, check that the contents have been written to the file and finally disconnect from the Git server.

$ ssh
# Password: ...
$ cd ~/.ssh
$ vi authorized_keys
$ cat authorized_keys
# ssh-rsa AAAAb4kzaC1 (text omitted) 86n3iEEQ78cPVazr
$ exit

If you’ve done everything right, you should now be able to log on to the Git server from John’s computer without having to input a password:

$ ssh
# Linux 2.6.18-028stab069.5 #1 SMP Tue May 18 17:26:16 MSD 2010 x86_64 GNU/Linux

Repeat this for Andrew and Robert, then proceed to the next step.

Step 2: Setting Up a Shared Git Repository

This step should be done by somebody who has sudo access to the server or the root user himself. The latter is more dangerous, although saves you from typing sudo every time ;)

So, let’s assume there’s manager user account with sudo access, and the /home/manager home directory. We’ll create our Git repositories there, the manager will own them while the developers will have read and write access. Start by creating a directory called repositories and another one inside called project.git which will host our first project. Initiate a bare repository with the shared flag inside the project.git directory and then change the group of all the files and directories to developers:

$ cd ~
$ mkdir -p repositories/project.git
$ cd repositories/project.git
$ git init --bare --shared=group
# Initialized empty shared Git repository in repositories/project.git/
$ ls
# branches  config  description  HEAD  hooks  info  objects  refs

Being in the project.git directory use sudo to run the chgrp command to change the group of all the files. Use the -R flag to run this recursively:

$ sudo chgrp -R developers .
$ ls -l
# drwxrwsr-x 2 manager developers 4096 2011-01-19 13:38 branches
# -rw-rw-r-- 1 manager developers  126 2011-01-19 13:38 config
# (text omitted)

Okay, so now all your team mates have read and write access to your repository since they’re all in the developers group. Let’s proceed with setting up symbolic links and cloning the repository to the crew to finally start working.

Step 3: Accessing the Shared Git Repository

As mentioned earlier, everybody in the developers group has read and write access to the project.git repository, and yes, they can go ahead and clone it from where it is right now, i.e. repositories/project.git in the manager’s home directory. Now to make it more convenient, let’s set up symbolic links for all our developers to point to the repository, and later see how they can easily access it from their local machines.

$ sudo ln -s /home/manager/repositories/project.git/ /home/john/
$ sudo ln -s /home/manager/repositories/project.git/ /home/andrew/
$ sudo ln -s /home/manager/repositories/project.git/ /home/robert/

Done, so now John, Andrew and Robert can access the repository without having to move away from their home directories. Now let’s get back to John’s (local) computer and try to clone the project into John’s work directory:

$ mkdir -p ~/work/project/
$ cd ~/work/project/
$ git clone .
# Initialized empty Git repository in ~/work/project/.git/

Let’s go ahead and add a readme file to the list, commit and push it to our server:

$ echo "Hello" > readme.txt
$ git add readme.txt
$ git commit -m "Adding a readme file"
$ git push origin master
# Commit messages ...

So if you’ve reached this step and successfully pushed your first commit to your remote Git server, you have done everything right, congratulations! You can now go ahead and clone the project for Andrew and Robert, I’m pretty sure they can’t wait to start pushing and pulling ;)

One more tip, suppose your username is john, you’re cloning a git repository from, and your username on is john as well, you can omit typing john@ when cloning, so it’s simply:

$ git clone .

This can save you some time if you’re working on several projects and have new ones every day. If your usernames don’t match, you have to prefix the server host with your username followed by the @ symbol. This is more of an SSH trick and not really related to Git, but it’s a good practice to work with Git projects over SSH.


I know there are quite a lot of Git tutorials out there, but what I really wanted to show here is the fact that you can actually save some money. That’s right, save money.

I’ve been working with freelancers and small tech companies all over the world, and yes, everybody simply loves Github. In fact I love it too, but public repositories are not always a solution for some of us. We sometimes work on commercial projects, secret and NDA’yed ones. We sometimes have ideas of our own that we wouldn’t like to share with the rest.

There are private repositories on Github, but they start from $7/mo and you’ll have to get the $12 plan in order to have more than one collaborator, which gives you 10 projects. Yes, hosted is good, you get security and everything, an awesome control panel, issue tracking and much more. But! Sometimes you just don’t care!

Sometimes you’re already running a $30/mo VPS with some hosting company, so why pay more for Git hosting? Right, it may not be too easy running the steps above at first, but once you get used to them, you’ll be init’ing, cloning, pulling and pushing Git repos like crazy ;)

Thanks so much for reading, and of course sharing. Feel free to bug me with questions via the comments section. Cheers!

TeamLab vs Basecamp: A Project Management Duel

Team. Team, team, team.. How good is your team if you can’t manage it? This reminds me of an IT Crowd episode:

Well if you can’t work as a team you’re all fired! .. Hello security? Everyone on floor 4 is fired.

As some of you already know, I run a little web development startup here in Moscow called Frumatic and during the past few months we’ve been struggling to get our project management and collaboration right. I don’t think there’s a reason for me to write about how important project management is and that no good business today could live without a good CRM, PM, SCM and the rest.

Today we’ll speak about two awesome project management systems – Basecamp and TeamLab. Both services are quite cool and look alike in some sense. I’ll try to outline the pros and cons of each app, then give a short tip on how to make your choice between the two. Let’s start off with Basecamp.

Basecamp by 37signals

Basecamp has been developed and launched by 37signals back in 2004. Since then it’s been evolving, new very nice features have been developed, and today, Basecamp is a very powerful project management and collaboration tool, offered as a service (SaaS). Basecamp wouldn’t be complete without it’s sisters Highrise (CRM), Backpack (business organizer) and perhaps Campfire (chat) and of course the Basecamp Extras and the Basecamp API which gives developers the power to mash their software with Basecamp.

Basecamp Pros

Let’s start with a short list of Basecamp pros. I’m sure there are tonnes of others:

  • Web-based and easy to use
  • Fast and secure, powered by Amazon S3
  • Maintaned and supported very well
  • On-going development, enhancements
  • Offers tonnes of extras and a public API
  • Offers time tracking

Basecamp Cons

And here’s a list of Basecamp cons. I found some of these quite annoying, but despite that, I still love Basecamp ;)

  • Quite expensive (good plans start from ~$50/mo)
  • Not very customizable, all you can change is the logo and color scheme
  • Does not offer self-hosted version
  • Does not allow to use your own Amazon S3 account to host your data
  • Quite poor CRM and Business Organizer
  • Basecamp Extras are poor, some of them are even commercial

Yeah, paying for software is not a crime, but in my opinion, Basecamp is slightly overpriced, plus you’ll have to pay extra if you’d like to get Backpack or Highrise (which is quite a poor CRM actually, I found SugarCRM CE, which is open-source, much better than Highrise). Now let’s see what TeamLab is all about.

TeamLab by Ascensio System

I came across TeamLab a few weeks ago and I found it to be quite terrific! TeamLab was launched this summer, somewhere in the beginning of July I guess. It’s based in Latvia, where Russian is quite a popular language by the way ;) TeamLab is written in Microsoft ASP .NET (C#) which makes it quite easy to understand. As it is a startup they haven’t yet implemented their monetization plan, so TeamLab is offered free of charge as SaaS or open source for download. You can deploy TeamLab in the Amazon EC2 cloud and use S3 for file hosting, which is quite wikid!

TeamLab Pros

Below is a list of pros I found for TeamLab. These may change in the future ;)

  • Free and open source, released under GPL
  • Compatible with Amazon EC2 and S3
  • Web-based, easy to use
  • Offers a full-featured Company Intranet and a Wiki
  • Quite active on Twitter
  • Offers import and export

TeamLab Cons

The cons of TeamLab from a php developer’s perspective (ASP .NET is good, but .. well ;)

  • Written in ASP .NET
  • Does not offer time tracking
  • Has some bugs, like any other startup ;)
  • Does not offer extras, mobile or API (maybe it’s only a matter of time)
  • Will not remain free of charge forever (I guess)

The last point may or may not be true. Like any other startup, TeamLab will go commercial at some point. I spoke to the representatives of TeamLab on Twitter and e-mail, and I’ve been told that all the functionality included in TeamLab now will remain free of charge in the SaaS and the open source downloadable package, but new features will require you to pump their back accounts with money. This is very optimistic indeed, as we’ve already seen such trouble with Sugar CRM Community Edition and Mockingbird, which is planned to go commercial on August 15th.

Making the right choice

Personally, I’m using Basecamp, but TeamLab made quite a good impression, and I do have thoughts about switching. What would make switching much easier is .. Import! An Import from Basecamp feature would be awesome, besides they offer all the tools (API) and documentation to do that.

TeamLab does though offer import and export, but from their own system and that’s good to go, especially since you can have your own self-hosted TeamLab, which would be preferred by large companies, as they do not usually trust third-party services.

So, if you’re worried about security, need time tracking and CRM integration, then yes, Basecamp is definitely your choice. But if you’re willing to play around and build solutions on top of, then go with TeamLab, as you will always be able to have your own extras running inside TeamLab Open Source. This will also save you some cash ;) Thanks for reading!

The Web Development Cycle Explained

If you’ve ever been to software development classes you probably already know about the software development cycle: Pre-alpha, Alpha, Beta, Release candidate (Gamma, Delta), Release to Marketing and finally, General Availability. Well it goes pretty much the same in the web development world, except that there are a few other parties involved in the whole process, and today, in the dynamic era of the Internet, web development corporations, small and medium businesses and tiny web development groups often work from different places.

I’ve been working freelance for quite a long time, and most of my projects were solo or perhaps two or three people at max, leaving me as the leading developer. Since January this year I’ve been working on a few projects with a team of over 5 people and high-demanding standards. This raised the problem of project managing and a completely different view of the web development cycle. In this article I’d like to outline the major steps of the software development cycle and how they could be applied to the web development business.

Development: Pre-alpha Stage

As we all hopefully know, each web application starts from a project overview written by both the client and the web development company. After this overview has been approved, the designers start to sketch, the programmers start to write code blocks, and the content managers gather keywords and start writing short subjects, while the client sits back and gets ready to mock anything that is sent their way. This is probably the pre-alpha stage, sometimes called wireframing or mocking up (in general, not only design terms).

Development: Alpha Stage

This, perhaps, is the stage where the design layouts are shown to the client, some text is revealed by the content managers, and something gets approved by the client. In most cases this stage takes the majority of time dedicated to the whole project. It’s pretty difficult sometimes to convince clients why certain designs look better than others, especially if they have a bad, or no taste at all. Practice shows that it’s often a good idea to:

Present the client with two variants to pick from – a really aweful one that in general terms could be used, but with a probability of at least 95% that it wouldn’t; and a really good one that you and your company placed the bet on.

Sure there’s a chance that your client goes with the first choice and you’ll end up working on something that makes you sick, but hey, this doesn’t work all the time ;)

Development: Beta Stage

After everything has been approved by the client, the Beta development stage is where coders have some fun. There’s no reason to expect that they get it right from the first time, especially when working on a big project. This is where I suggest you use the three environments method – development, testing, production. Some modern IDEs such as RubyMine (for Ruby on Rails) have built that in, allowing you to switch from one environment to another with a click of a mouse. But unfortunatelly the browser problem persists.

Web Development Cycle

I came across a really useful Firefox addon a few weeks ago, it’s called SwitchHosts. At first sight it’s something that is unnecessary – development environments could be switched to different subdomains – and, finally the production address – This, in my opinion, is something that’s really difficult to tackle when working with software that stores options, etc into databases. For instance – WordPress, where the database is tied to a certain domain.

Sure you could go ahead and use your text editor’s Search and Replace function but:

  • Would you really like to do it every single time?
  • Would you like to teach your other employees to do that?
  • What if there’s an error checking algorithm involved? For instance WordPress widgets disappear after a Search and Replace run.
  • It’s so much easier to keep track of a single database dump than three.

Convinced? Okay but why do you need SwitchHosts to keep one domain tied to three different addresses? Couldn’t you just use the hosts file for that? Well, sure, but then again, try to explain to your employees (I’m talking about the less coder-fellows) how to work with the hosts file, then of course they’ll forget to flush their DNS cache as soon as they’ve added that extra line. They’ll end up making changes to the production server, and you wouldn’t like that, would you?

With SwitchHosts for Firefox you could switch to as many hosts file as you setup in only a couple of clicks. Besides, it’s always there in your status bar, showing which hosts file is currently active which, believe me, solves plenty of problems. One more feature I love in SwitchHosts is that it flushes your DNS cache automatically as soon as you switch from one environment to another.

Make sure that you’ve setup version control systems (such as Subversion) on each of the environments. It’ll make it much easier when replicating from development to testing and back to development, as well as from testing to production.

The Beta Development Stage is probably the most important part to return back to when your client is not satisfied with the results, or perhaps would like to add a few minor changes to the layout, text or pictures. Of course they should be charged extra for this, and it’s extra work for you, but hey, it’s their money they’re wasting ;)

Testing: Release Candidate

Each Release Candidate should probably be located on the remote testing server, unlike the development, which should be kept locally for the developers. Of course it’s easier to do local testing, but:

  • All tests should be held in environments as close to the real world as possible, thus a remote machine, preferably on the same hosting plan as you production server. Don’t confuse “same hosting plan” and “same server” – your testing and production units should have different IP addresses.
  • Your content managers will need to polish their work, would you really like to educate them to install server software and deploy the project on their local machines, nah! ;)
  • After all our testing environment couldn’t be located on the same machine as the development. Wha? Run two different copies of Apache?

So, the RC is where you show off to the project manager, who asks the content managers to review their work on a working website. They could do this online themselves, or they could send reports to the developers.

Release to Marketing (from the general software development cycle) should be in the middle of this stage, where a decision is usually taken to go on and show the results or return back to beta development.

So if Marketing approves the whole thing, the end of the RC stage is where you should show the results of you work to the client. Of course they’ll need some hosts-file hi-jacking, and perhaps with the SwitchHosts addon it wouldn’t be as dirty as it usually is. If the client has good reasons not to do this, then of course you should drive it over to a sub-domain. But I really don’t recommend you showing off on the production server, especially if there’s an old website working there – clients don’t like their old websites to be taken down before the new one is 100% approved. Some of them don’t understand that there’s an option to restore their old website ;)

And when the Boss says yes …

Production: General Availability

This is the victory stage. It’s where both parties yell “Wohoo!”, drink champagne and drunk coders deploy the project to the production server overnight. What could possibly go wrong? Often takes less than a minute:

svn checkout svn/tags/1.0 .
mysql -uname -ppass db < include/db.sql

Great! Well this doesn’t mean that you can go ahead and delete everything you’ve done at the development environment. Yes, testing server can go to rest, but you should always keep a copy of all your work, preferably in an archived Subversion repository. Why?

  • The client could return in two weeks and say: hey, remember you showed me that second version before this third? Could we return to that if payed you some extra cash?
  • Your client could ask you for a backup copy of the work you’ve done. You shouldn’t have problems handing it over or restoring the website if they broke it within a few weeks. Keep a good reputation.
  • Parts of it (even those which were rejected) could be quite useful in future projects.
  • If clients are satisfied with the work you’ve done, they will probably return to you when they’ll need to add a few extra functions to the website that you made.

Well, that’s about it. Of course if you’re a solo-freelancer you wouldn’t need any of this stuff. You wouldn’t need version control systems at all, as all your work is done by you. A project backup is simply a copy-paste issue. Though it’s sometimes useful to imitate teamwork. After all, you can’t be sure that you’ll be coding solo for the rest of your life ;)

There are tonnes of free and open source tools out there to help you out in version control – Subversion; and in project management – The Trac Project (P.S. check out these 5 Really Useful Trac Reports).

This was the web development cycle outlined based on my experience. Sure some individuals and companies work using modified versions of this cycle, some use a completely different model. But, whichever one is picked, it all comes down to three major phases – development, testing, production. So, what’s your case? Which model is used by your company and why do you prefer to work that way? Feel free to give a word in the comments area below.

5 Really Useful Trac Reports

For those of you who are not familiar with the project management software called The Trac Project please proceed to the Trac Guide. I’ve been working with this project management tool for quite some time now and the latest upgrades are just awesome. I believe the solution for private projects’ RSS feeds has been found a few months ago somewhere here. The iCalendar issue remains, but it’s probably solved the exact same way – http authentication, although not all iCalendar clients and RSS aggregators support that yet. My favourite Feedly doesn’t.

Before showing off the snipets that I wrote for Trac Reports I’d like to give you one little hint if you’re running Trac on an old (but stable) OS version, such as Fedora Core 8. Amazon EC2 still ships the Fedora 8 operating system as default for Linux-based EC2 instances, and a simple yum install trac will get you version 0.10.x, which is outdated. The trick here is to install:

yum install python-setuptools
yum install python-setuptools-devel

Which include a package called easy_install. Since you’ve got an old version of Trac installed, use easy_install to update it, like this:

easy_install -U trac

Bam! Wasn’t that easy? One more situation where you can use easy_install is to install Trac plugins directly from their repositories (instead of the old way by uploading source files).

Okay, now back to the reports. I made these with a little experimenting with the Trac database. It’s structure is pretty much transparent and obvious, so if you’re an SQL genius then go ahead and write your own. Here’s my most useful list …

Continue reading