As with most things in tech, large companies catch on to the power of instant messaging late. Where I work is no exception. They rolled out Microsoft Office Communicator a couple of months ago (as a side note, that is a horrible landing page) and made much of the new and improved power of communication between employees. It’s a great thing that I can finally communicate using instant messaging, but the proprietary software threw a monkey in my desktop setup. After some research I found out how to get my desktop to connect to the Office Communicator server: Pidgin and SIPE.
First, I needed to install Pidgin
sudo apt-get install pidgin
Then, I installed the TLS plugin for Pidgin
sudo apt-get install pidgin-encryption
Now, the important piece of the puzzle was SIPE, which is needed to connect to proprietary server. I initially tried the usual
sudo apt-get install pidgin-sipe
But the version of SIPE available for jaunty was version 1.2-1 and it didn’t work. So, I went with the old school way of compiling my own binary. I got the code from here and followed the simple instructions on the same site. They are as follows:
tar -zxvf pidgin-sipe-1.7.0.tar.gz
cd pidgin-sipe-1.7.0
./configure --prefix=/usr/
make
sudo make install
Once installed, I started up Pidgin and after entering the necessary info connected successfully. You can see the detailed info of what I entered in the pictures below.
We run a large scale and highly visible website. This site is updated frequently, and is very complex. So far the way the site is updated is using subversion where the latest code is checked out into the public servers – after much testing, of course.
A typical release goes something like this:
checkout code from subversion
run a few scripts to modify database and generate intermediate files
generate various connections between site and underlying software
update underlying software
One problem with this approach is inevitably developers tend to push last minute fixes while in testing mode. It’s easy to update the code with a svn co but the code always tends to diverge and one fix usually leads to other bugs! Another issue is that each time a release is made a long list of complicated – and different each time – steps have to be followed. There are many other issues as well that I won’t go into right now, but suffice to say each release is as easy as pulling your own tooth!
So, one idea to cut down on all this trouble is to build a deb package for each release. This essentially locks down development, since each code change involves building a new package. I’m also fairly certain it will make life in the software lifecycle much easier.
And the debianized release would go like this:
apt-get install website package
apt-get install underlying software
Or even simpler if I made the website package depend on the underlying stuff:
apt-get install website package
Now only if I could get the decision makers to agree.