sipXconfig
Thursday, December 06, 2007
Things people are eager to tell you...
Damian: I noticed that if one writes on the list "I am going to do this and this"
Damian: it's better than "what should I do?"
Kevin: ok
Kevin: people are always eager to tell someone they are a moron, but not as eager to answer questions :)
Damian: it's better than "what should I do?"
Kevin: ok
Kevin: people are always eager to tell someone they are a moron, but not as eager to answer questions :)
Powered by ScribeFire.
- posted by Damian @ 12:56 PM 1 comments
| permalink
Wednesday, November 07, 2007
Sketches of Frank Ghery
Coding is not like building houses. The two are often compared. However, this comparison usually results in all kinds of design recommendation that effectively prohibit producing any usable software.
If you want to see that metaphor reversed make sure to watch Sketches of Frank Ghery movie. It shows the architect who design buildings the way that software should be written. There are of course beautiful buildings to watch: Disney Concert hall, Bilbao Guggenheim.
It's a movie about architecture, but more than that it's a movie about design process: iterative modeling, refactoring, debugging - it is all there. Gehry is definitely into refactoring. And into small iterations. It's fun to watch when Gehry and his team apply programming terminology to the models they create. Sidney Pollack could not possibly make a movie about a coders, but only because bunch of geeks arguing on the list or looking into Eclipse IDE is not as photogenic. But in our day to day job I find myself arguing about the same things as people in this movie.
There is a question of recognizing good and bad design: knowing that you got it right, Admitting that you got it wrong. I do not care what people say but we all go by some sense of internal beauty here. You say that code is elegant or (more often) messy. You say that something feels right. That's exactly how people in the movie talk about their experience.
In some way we - coders - have it easy: we work in a medium that translates directly into the resulting product. Software compilation is handled by computers; your design is expressed in code. You work in a strictly defined - and some say limited - vocabulary, but if you follow syntax rules you do not have to worry that someone misinterprets your vision. Not so much for architects, if they do not find a proper way to express themselves through drawings, models and design documents the resulting building might not be what they imagined. They show one of such buildings in the movie: it still looks great to me (but I did not "code" it).
Architectures - like programmers - are hired help. The interesting thing is that in both cases frequent interactions with customers actually result in a better end product. It's not a one way street, but a learning process were vision shapes the expectations and expectations shape the vision. There is even a similar feeling of an establishment pressure. It's not easy to propose and build something different. Gehry's buildings are like Linux in Windows world. (And yes I have to say it: some of those buildings do not have windows - at least not in a traditional sense)
Similarly to coding, in architecture one can do very little alone. You have to have a team of people. Organizing such team, making sure that people are motivated and happy to work on the same project is an art in itself. And in architecture - as in coding - you need to have proper tools. It's kind of sad that probably architects are better than us at using computers to develop their ideas. The stuff that they do with computers is amazing. We live in the world of primitive editors, outdated version control system and sink under the code that has not been automatically tested.
If you code for living this is a film for you. Even if you do not care for this obvious 'architecture is like coding analogy', even if you will not like the amazing buildings that it shows, you will appreciate the live demo of what computers can be used for. And you will feel proud that you are in this business.
- posted by Damian @ 7:51 AM 0 comments
| permalink
Saturday, August 18, 2007
The last laptop I'll ever have?
Recently I was changing laptops with a head spinning frequency. My old trusted Dell Latitude D600 decided to finally quit on me: with a whimper not with a bang. The relationship lasted 3 years so I was not really surprised. It took me about 30 seconds to put my disk in a similar laptop, which unfortunately decided to quit as well. Than I found a HP Pavilion that weights about as much as baby elephant and makes sound similar to that of the starting jet engine. Applying adjective 'portable' to this beast is probably a text book example of unintended irony. Finally I got a new HP Compaq nc8430. This wild ride made me realize couple of things.
I take it for granted now that I can take my hard drive, pop it into completely different machine and my Fedora will wake up, dutifully discover everything and will start working. I might get suboptimal video or my wireless might be missing, but everything else will just be there. And whenever I cannot take the hard drive (apparently the standard changed when I blinked) I can take my trusted home directory.
It sounds normal but when I mentioned it to my Windows based colleagues they were certain that grieving the loss of my Dell confounded my sense of reality. Everybody apparently knows that switching laptops can take weeks if not months of painful reinstalling, countless migrations application and hours on the phone with your friendly customer support transferring your software licenses. Why exactly people put up with it is beyond me.
I am proud user of nv8430 these days. Switching to HP is a company mandate. I cannot really full-heartedly recommended it for daily hacking. Screen is gorgeous, but ATI video card does not really run well unless you install proprietary driver. No Beryl fun to be had, so I cannot show off to my Windows friends. The fan never switches off and runs quiet only if I set ARI card in a power saving mode. And apparently 'business class' is marketingese for 'ugly'. But with its dual core it's noticebaly faster than Pentium M Dell. Cuts sipXconfig the compilation time to about 70%, and I can run infamous sipXconfig's 'ant precommit' target (which cleans, compiles and run all kinds of tests, including database and UI tests) in about 5 minutes (used to be more than 10 recently). The battery life is decent too: measured in hours not in minutes.
I am yet to figure out how to put it to sleep or hibernate. Out of the box Gnome's sleep option makes X to go away and text console spitting some garbage (I am blaming the proprietary video, but I have noo proof yet).
I certainly hope my hard drive changing behavior would soon become a norm. I will stop carrying laptops altogether. I will just carry my a flash disk with favorite Linux installation. There will be a powerful, generic diskless station in the office where I plug in my hard drive and after 10 second boot procedure I will have my familiar environment. And even that will be a short-lived fad because the internet will make it possible to store OS image on-line.
So this might be the last laptop I'll ever have. I should be nicer to it.
I take it for granted now that I can take my hard drive, pop it into completely different machine and my Fedora will wake up, dutifully discover everything and will start working. I might get suboptimal video or my wireless might be missing, but everything else will just be there. And whenever I cannot take the hard drive (apparently the standard changed when I blinked) I can take my trusted home directory.
It sounds normal but when I mentioned it to my Windows based colleagues they were certain that grieving the loss of my Dell confounded my sense of reality. Everybody apparently knows that switching laptops can take weeks if not months of painful reinstalling, countless migrations application and hours on the phone with your friendly customer support transferring your software licenses. Why exactly people put up with it is beyond me.
I am proud user of nv8430 these days. Switching to HP is a company mandate. I cannot really full-heartedly recommended it for daily hacking. Screen is gorgeous, but ATI video card does not really run well unless you install proprietary driver. No Beryl fun to be had, so I cannot show off to my Windows friends. The fan never switches off and runs quiet only if I set ARI card in a power saving mode. And apparently 'business class' is marketingese for 'ugly'. But with its dual core it's noticebaly faster than Pentium M Dell. Cuts sipXconfig the compilation time to about 70%, and I can run infamous sipXconfig's 'ant precommit' target (which cleans, compiles and run all kinds of tests, including database and UI tests) in about 5 minutes (used to be more than 10 recently). The battery life is decent too: measured in hours not in minutes.
I am yet to figure out how to put it to sleep or hibernate. Out of the box Gnome's sleep option makes X to go away and text console spitting some garbage (I am blaming the proprietary video, but I have noo proof yet).
I certainly hope my hard drive changing behavior would soon become a norm. I will stop carrying laptops altogether. I will just carry my a flash disk with favorite Linux installation. There will be a powerful, generic diskless station in the office where I plug in my hard drive and after 10 second boot procedure I will have my familiar environment. And even that will be a short-lived fad because the internet will make it possible to store OS image on-line.
So this might be the last laptop I'll ever have. I should be nicer to it.
Powered by ScribeFire.
- posted by Damian @ 5:52 AM 0 comments
| permalink
Friday, July 20, 2007
Hold the Secret Sauce please
Brian Rigss wrote a small piece on Nortel and SIPFoundry. It's an interesting news for all VoIP fans and it's a very good news for SIPFoundry community.
I was slightly surprised that open source hackers now apparently roam in loose-knit bands. It is a quaint image evoking sorely missing sense of adventure. As charming images go, this one has little to do with reality and is easily dispelled by subscribing to any devel list - including sipX one - and counting the references to my boss and my company.
I cannot resist having some fun with his secret sauce metaphor. To quote Brian:
[...] VoIP software has been sacrosanct. It’s the secret sauce. It’s the way IP PBX developers ensure that their customers have access to the most advanced sets of call features. It’s how they add value to their product, differentiate from competitors, generate the majority of their revenue, and transform themselves from providers of monolithic PBX cabinetry and into communications software developers of the future.
I happen to think that Secret Sauce turned out to be not what people hoped it to be. Actually, I think that it's not a sauce at all but a trans fat., which - at least according to wikipedia - is neither required nor beneficial for health.
If I were running a corporation, I would be suspicious of my communication system being dependent on a secret sauce. What happens if I get hooked and secret sauce provider goes out of business, what if their secret sauce does not mix well with the secret sauce of the other guy. Do I really want to take this risk?
I prefer my secret sauce provider to start making money on something that I actually want to pay for: developing more features, faster and better than their competition. Without hiding behind a secret recipe.
In several US states overactive legislatures banned trans-fats. I wonder if the Secret Sauce is next on the agenda.
I was slightly surprised that open source hackers now apparently roam in loose-knit bands. It is a quaint image evoking sorely missing sense of adventure. As charming images go, this one has little to do with reality and is easily dispelled by subscribing to any devel list - including sipX one - and counting the references to my boss and my company.
I cannot resist having some fun with his secret sauce metaphor. To quote Brian:
[...] VoIP software has been sacrosanct. It’s the secret sauce. It’s the way IP PBX developers ensure that their customers have access to the most advanced sets of call features. It’s how they add value to their product, differentiate from competitors, generate the majority of their revenue, and transform themselves from providers of monolithic PBX cabinetry and into communications software developers of the future.
I happen to think that Secret Sauce turned out to be not what people hoped it to be. Actually, I think that it's not a sauce at all but a trans fat., which - at least according to wikipedia - is neither required nor beneficial for health.
If I were running a corporation, I would be suspicious of my communication system being dependent on a secret sauce. What happens if I get hooked and secret sauce provider goes out of business, what if their secret sauce does not mix well with the secret sauce of the other guy. Do I really want to take this risk?
I prefer my secret sauce provider to start making money on something that I actually want to pay for: developing more features, faster and better than their competition. Without hiding behind a secret recipe.
In several US states overactive legislatures banned trans-fats. I wonder if the Secret Sauce is next on the agenda.
- posted by Damian @ 1:13 PM 0 comments
| permalink
Sunday, May 27, 2007
subversion: overdue good-bye?
I discovered subversion before it got to 1.0. I convinced people working with me then to switch. At that time we were using ClearCase. Simplicity and speed of subversion was in comparison exhilarating. I even wrote couple of simple ruby scripts to bridge official ClearCase and our subversive repository. Even the name was perfect. Let's just say that even my undeniable sense of humor and personal charm failed to mend strained relations with Release Engineering group (yeah - it was a big company).
When I started working in Pingtel sipx developers already had been using subversion. Since it was about the time we needed to create our first real branch I took upon myself figuring out how to use svnmerge. We never looked back.
If that was not enough Producing Open Source Software that Douglas made me read at one point practically defined the way I think about my job. And it's written by Karl Fogel - yes - the subversion Karl Fogel.
I am writing all that to prove that I really like subversion. So it saddens me to realize that my favorite tool is most probably no longer the best tool.
As a part of my daily job I am committing patches sent by contributors. From time to time I create branches for people who want to experiment with sipx without breaking mainline. And slowly I begin to think that my job would be easier with a different tool. And that with a different tool sipXconfig and sipx would get more contributions and better contributions.
With subversion - or any other centralized SCM - there are always two categories of people: those with commit access and everybody else. Committers and patch senders. In-crowd and followers. Eloi and Morlocks.
As a patch sender you have to create your working copy, make your changes, send the patch - and - never use this working copy again. At least not until someone with commit access actually commits your patch. If the patch gets not accepted in its original form and you want to fix it, you are losing the history. You cannot somehow save your changes locally and than make changes on top of your changes. At least if you only have one patch you can keep updating the working copy and track the mainline. If you have more than a single patch however you are doomed. Subversion does not make life easy for you. I wonder how many useful contribution sipx is losing just because it's too hard to contribute anything more than a simple patch.
But even once you get commit access the problems do not stop. Before you get commit rights your every step is watched, every patch reviewed, every extra space corrected. Once you do not have to send patches for approval anymore it changes. It's not about becoming sloppy. It's about the lack of feedback. Even if someone does review your commits, and people do, once you check something in, it's in. Official. With good chances to survive forever without being looked at. One of the biggest benefits of open source, constant peer code review, is not the default option.
I started thinking about it after reviewing several patches last week. I took some. I rejected some. I sent comments or my own fixes on top of those patches for review. I knew what I was doing with subversion all the time but somehow it felt like I am working around my SCM rather than using it.
I thought of darcs which I discovered when trying out buildbot (sipx nightlies are courtesy of buildbot). That lead me to git, mercurial and others. It quickly became obvious I was not alone. Mozilla chose Mercurial over Bazaar (both distributed). They did not even shortlist subversion. Linus with his usual flair refers to subversion as the most pointless project ever started. He has a point. Open source project should never use anything but distributed SCM.
Source Control Management history follows the script leading to more freedom to modify and experiment: "lock-modify-commit" gets replaced by "copy-modify-merge-commit" (no locking) which in turn morphs into "pull-modify-commit-push" (no central repository).
If only I could figure out how this tailor thing works, I would set up mercurial mirror of sipx and encourage contributors to use it. Exciting.
When I started working in Pingtel sipx developers already had been using subversion. Since it was about the time we needed to create our first real branch I took upon myself figuring out how to use svnmerge. We never looked back.
If that was not enough Producing Open Source Software that Douglas made me read at one point practically defined the way I think about my job. And it's written by Karl Fogel - yes - the subversion Karl Fogel.
I am writing all that to prove that I really like subversion. So it saddens me to realize that my favorite tool is most probably no longer the best tool.
As a part of my daily job I am committing patches sent by contributors. From time to time I create branches for people who want to experiment with sipx without breaking mainline. And slowly I begin to think that my job would be easier with a different tool. And that with a different tool sipXconfig and sipx would get more contributions and better contributions.
With subversion - or any other centralized SCM - there are always two categories of people: those with commit access and everybody else. Committers and patch senders. In-crowd and followers. Eloi and Morlocks.
As a patch sender you have to create your working copy, make your changes, send the patch - and - never use this working copy again. At least not until someone with commit access actually commits your patch. If the patch gets not accepted in its original form and you want to fix it, you are losing the history. You cannot somehow save your changes locally and than make changes on top of your changes. At least if you only have one patch you can keep updating the working copy and track the mainline. If you have more than a single patch however you are doomed. Subversion does not make life easy for you. I wonder how many useful contribution sipx is losing just because it's too hard to contribute anything more than a simple patch.
But even once you get commit access the problems do not stop. Before you get commit rights your every step is watched, every patch reviewed, every extra space corrected. Once you do not have to send patches for approval anymore it changes. It's not about becoming sloppy. It's about the lack of feedback. Even if someone does review your commits, and people do, once you check something in, it's in. Official. With good chances to survive forever without being looked at. One of the biggest benefits of open source, constant peer code review, is not the default option.
I started thinking about it after reviewing several patches last week. I took some. I rejected some. I sent comments or my own fixes on top of those patches for review. I knew what I was doing with subversion all the time but somehow it felt like I am working around my SCM rather than using it.
I thought of darcs which I discovered when trying out buildbot (sipx nightlies are courtesy of buildbot). That lead me to git, mercurial and others. It quickly became obvious I was not alone. Mozilla chose Mercurial over Bazaar (both distributed). They did not even shortlist subversion. Linus with his usual flair refers to subversion as the most pointless project ever started. He has a point. Open source project should never use anything but distributed SCM.
Source Control Management history follows the script leading to more freedom to modify and experiment: "lock-modify-commit" gets replaced by "copy-modify-merge-commit" (no locking) which in turn morphs into "pull-modify-commit-push" (no central repository).
If only I could figure out how this tailor thing works, I would set up mercurial mirror of sipx and encourage contributors to use it. Exciting.
Powered by ScribeFire.
- posted by Damian @ 6:58 AM 4 comments
| permalink
Monday, May 21, 2007
Sometimes it's just better to let go
Contrary to what many people think open source applications are not created by a bunch of crazy, willing to work for free volunteers. At least not only by them. Read Linus's biography to find out more. Often open source contributors are engineers employed by big and small corporations.
There are many reasons why a for-profit corporation might consider sponsoring or developing open source projects. Ensuring support for a project that is outside of company's core strategic interest and assuring the customers that they are not vendor-locked are the most commonly cited ones. Another reason - probably not so often discussed - is cooperation with your business partners.
Software companies often engage in shared deals, shared developement, strategic partnerships. It's a not-so-well kept secret that deals like that often fail, generating little more than several widely discussed press releases. It's usually the clash between corporate cultures and internal politics that prevent even reasonable deal to go forward.
The situation changes when companies cooperate within the realms of on an open source project. Especially, if it is a well established project with wide community of users and developers. First of all the rules of cooperation are commonly understood, established and transparent. The roles of sponsors, contributors, reviewers, project coordinators are well defined. It's really no that different from having a standard API interface - only these times it gets applied to people and processes not to software components.
Simple things that can take ages to establish like 'how I can get your source code' and 'what format is your documentation' are already resolved.
The biggest improvement though is in the area of day to day communication. Engineers and product managers are forced to discuss their ideas openly to get them implemented. The usual management structures that in closed source world lead to exchanges like 'tell your boss to talk to my boss before talking to me' expose their absurdity under the open source light.
No side of the deal is afraid that the other side is going to steal IP. Reciprocate licenses eliminate the false temptation of competive advantage that can be allegedly achieved by stonewalling.
This is what big bosses like best: you reduce your risk by outsourcing your communication and product management to someone who just does it better than yourself. In this case it's an open source community.
There are many reasons why a for-profit corporation might consider sponsoring or developing open source projects. Ensuring support for a project that is outside of company's core strategic interest and assuring the customers that they are not vendor-locked are the most commonly cited ones. Another reason - probably not so often discussed - is cooperation with your business partners.
Software companies often engage in shared deals, shared developement, strategic partnerships. It's a not-so-well kept secret that deals like that often fail, generating little more than several widely discussed press releases. It's usually the clash between corporate cultures and internal politics that prevent even reasonable deal to go forward.
The situation changes when companies cooperate within the realms of on an open source project. Especially, if it is a well established project with wide community of users and developers. First of all the rules of cooperation are commonly understood, established and transparent. The roles of sponsors, contributors, reviewers, project coordinators are well defined. It's really no that different from having a standard API interface - only these times it gets applied to people and processes not to software components.
Simple things that can take ages to establish like 'how I can get your source code' and 'what format is your documentation' are already resolved.
The biggest improvement though is in the area of day to day communication. Engineers and product managers are forced to discuss their ideas openly to get them implemented. The usual management structures that in closed source world lead to exchanges like 'tell your boss to talk to my boss before talking to me' expose their absurdity under the open source light.
No side of the deal is afraid that the other side is going to steal IP. Reciprocate licenses eliminate the false temptation of competive advantage that can be allegedly achieved by stonewalling.
This is what big bosses like best: you reduce your risk by outsourcing your communication and product management to someone who just does it better than yourself. In this case it's an open source community.
Powered by ScribeFire.
- posted by Damian @ 6:48 AM 0 comments
| permalink
Monday, May 07, 2007
AudioCodes gateways support is here
I am kind of relieved that AudioCodes gateways support achieved the stage when it's actually useful. To tell the truth I had my doubts it would ever happen. Also the more I work on those blue boxes the less I understand how one can configure them without sipXconfig. There is so many settings that have to be set in a very specific way for the entire setup to work. Simplicity clearly was not a goal here.
The good news is now you do not have to do that anymore. There is some bootp/DHCP magic that I am going display on wiki, but once you configure that it becomes a plug-and-play affair. So call you proverbial mothers to setup your VOIP networks. See wiki for more info.
The good news is now you do not have to do that anymore. There is some bootp/DHCP magic that I am going display on wiki, but once you configure that it becomes a plug-and-play affair. So call you proverbial mothers to setup your VOIP networks. See wiki for more info.
Powered by ScribeFire.
- posted by Damian @ 7:49 AM 0 comments
| permalink
