LavaBlast Software Blog

Help your franchise business get to the next level.
AddThis Feed Button

Upcoming StatCVS/StatSVN Release

clock March 31, 2008 13:40 by author JKealey

locAs you know, LavaBlast develops most of its applications using Microsoft technologies but we like to dabble with other technologies. We're behind the open source movement and have worked on a few open source projects, mainly in Java. One of these is StatSVN, a tool that retrieves information from a Subversion repository and generates various tables and charts describing the project development. It's so great even Eric Kemp used it on SubSonic. The tool uses StatCVS internally and I've recently been promoted to the project admin status on SourceForge (along with Benoit Xhenseval of Appendium). StatSVN has not evolved much in the last year, since the release of v0.3.1, but we've recently done a few enhancements.

Current improvements to both StatSVN and StatCVS

  • StatSVN: Faster diffs.
    • StatSVN now takes advantage of a new Subversion 1.4 feature which allows us to perform one svn diff per revision, instead of one svn diff per revision per file. If you don't have 1.4, the old behavior will continue to work.
    • The Apache project blocked our demo because we were doing too many svn diffs on their servers. Hopefully, this will solve this situation in addition to making everything faster.
    • You can still use the old mechanism by using the -force-legacy-diff command line option, should you encounter any problems with the new feature.
  • Both: Export to XML format.
    • A new -xml option generates XML files instead of the typical HTML reports.
  • Both: Now showing affected file count in a commit.
  • StatSVN: The revision number shows up on the commit page.
  • StatSVN: Added support for -tags-dir as a way to specify 'top' directory where the tags are stored, defaulted to "/tags/".
  • StatSVN: Added support for a -anonymize command line option, to anonymize committer names
  • ... and a few minor things.


*** Download the alpha version ***

We're looking for some outside help

Instead of releasing v0.4.0 prematurely, we'd like to ask you to help us out!

1) Beta testers and benchmarkers

Before going with a full blown release, we want to ensure that the new StatSVN diff works as intended in various contexts. It works on our repositories, but we'd like you to run it on yours. We want to ensure it works well regardless of the operating system, your language, the type of files in your repository, the number of revisions, etc. Ideally, you'd time the whole thing and let us know how much faster it is. Furthermore, if you're a real zealot, you'd compare the line counts computed by both algorithms to ensure they match. (The counts are cached in a local XML file... very easy to compare the results).

2) Minor bug fixing & improvements

We've basically fixed the issues that annoyed us personally, but there are some that remain in both the StatCVS tracker and the StatSVN tracker. You may also be interested in creating new reports, which you think would interest the community.

3) Cool enhancements / external projects.

StatCVS/StatSVN can now export XML. This enables you to create new applications that use the computed data... why not whip up a cool dynamic web application? As a demo, I've imported the XML in ASP.NET and used the Open Flash Chart control we've blogged about in the past.


4) Up for a challenge?

Subversion supports move operations and CVS doesn't. While developing StatSVN, we decided we'd treat moves as a delete-add sequence, for simplicity's sake. However, this does generate inaccurate statistics. If you're in for a challenge, you could tackle this StatSVN enhancement. We prototyped something in the past, but it ended up being too slow for production use.


A few links



Even though StatSVN/StatCVS are Java-based and most of our readers operate in the .NET space, the application itself is platform independent. Personally, I enjoy loading up a recent version of Eclipse and working in Java once in a while because it helps me observe the best in both worlds. I much prefer coding in C# because of the easier string manipulation and the fact that everything is an object so you don't have to explicitly create an Integer object from your int to insert it into a collection. However, when working in VS.NET, I dearly miss the automatic incremental compilation feature that Eclipse runs when you save a file. 

kick it on

Scripting an ASP.NET installation in Win2k3

clock March 27, 2008 08:26 by author JKealey

A month ago, I posted an article on a few console commands for managing ASP.NET applications and IIS. In the weeks that followed, I was contacted by my old friends at iWeb Technologies to help them automate their ASP.NET setup. I spent a couple hours creating the required scripts and I thought I'd post my real world example here!

By the way, iWeb is an exceptional web hoster (1TB of space, unmetered traffic, unlimited domains, $3 a month, and excellent technical support; what more could a web developer want?). I've been with them for nine years already!

Scripting the creation of a new website and configuring it for ASP.NET

Task: Given a domain name ( and a network/local path (\\fileserver\hosting\\web\ or c:\inetpub\wwwroot\\web\), setup IIS so that ASP.NET works on the root of the domain.

  1. Create an application pool
  2. Create a web site and associate it to the application pool
  3. Ensure both that the www subdomain works ( and should load this website)
  4. Enable ASP.NET v2.0 on this website.
  5. Give ASP.NET read/write access to the folder.
  6. Add default.aspx to the default documents.


I ended up using the ADSUTIL.VBS script for most of these tasks. I used the iisweb command to create the web application, but it doesn't support network paths. I create it using a temp local path and end up using adsutil to change it to a network path. 

My googling skills are what made this task so short. Here are some of my references:

Finally, the IISBatchUtils collection of scripts provided the most help. Here's why. 

I have created batch files to make adding new websites to the server very quick and easy. The only tricky part about setting up new websites from batch file (or the command line) is that Microsoft's ADSUTL utility does not correctly add host headers like it says it does- rather than appending the new headers, it blindly sticks them in and possibly covers existing host headers that might already be set up.

I used both the original adsutil, Josh's modified adsutil, and some of his code to extract the site id from the IIS Metabase by using the site name.

The script

See the actual script for the variable definitions.

REM Step 1 - Create Application Pool
CSCRIPT //nologo %IWEB_ADSUTIL% CREATE w3svc/AppPools/%IWEB_DOMAIN% IIsApplicationPool
REM Step 2 - Create WebServer
iisweb /create %TEMP% %IWEB_DOMAIN% /d %IWEB_DOMAIN% /ap %IWEB_DOMAIN%
REM Step 3- Find new SiteID for further scripting. 
cscript //nologo iisbatchutils/translate.js "%IWEB_DOMAIN%" > siteid.txt
for /f %%I in (siteid.txt) do SET IWEB_SITEID=%%I
REM Step 4 - Add www. to site URL - uses their own custom adsutil because of bug in the normal one. 
cscript %IWEB_ADSUTIL2% append w3svc/%IWEB_SITEID%/serverbindings ":80:www.%IWEB_DOMAIN%"
REM Step 5 - set various website permissions. 
cscript //nologo %IWEB_ADSUTIL% set w3svc/%IWEB_SITEID%/accessread "true"
cscript //nologo %IWEB_ADSUTIL% set w3svc/%IWEB_SITEID%/accesswrite "true"
cscript //nologo %IWEB_ADSUTIL% set w3svc/%IWEB_SITEID%/root/AppFriendlyName %IWEB_DOMAIN%
cscript //nologo %IWEB_ADSUTIL% set w3svc/%IWEB_SITEID%/root/path %IWEB_Path%
cscript //nologo %IWEB_ADSUTIL% set w3svc/%IWEB_SITEID%/root/DefaultDoc Default.htm,Default.asp,index.htm,Default.aspx,index.asp,index.html
REM Step 6 - Cleanup
del siteid.txt


What about setting up IIS to use ASP.NET v2.0?

I did find a link showing me how to change the ASP.NET version from v1.1 to v2.0 using regiis, but later discovered that this stopped & restarted all websites... something catastrophic to do in a production environment. All the hosted websites (not only the new one) would lose their session state, for example. Fortunately, I found that you can change the root website and any new websites created afterwards will inherit the default ASP.NET version. Run the following once:

@echo off
REM will propagate to new sites. 
%windir%\Microsoft.NET\Framework\v2.0.50727\aspnet_regiis -sn W3SVC/
REM does not propagate
REM cscript %IWEB_ADSUTIL% set w3svc/accessread "true"
REM cscript %IWEB_ADSUTIL% set w3svc/accesswrite "true"


Scripting the deletion of a website

Deletion is much simpler, as you can see below.


iisweb /delete %IWEB_DOMAIN%


I had a fun time perfecting my scripting skills while creating a concrete example that solves someone's problem. I discovered that the devil is in the details, but that numerous people have worked on similar problems in the past. I ended up creating another script which runs this one numerous times, according to actions found in a local text file. Simply put, iWeb's PHP system appends operations to a file (create this site, delete that one, create this other site) and mine performs the operation and empties the task list. That way, the script can be run periodically and all the PHP coders need to do is append to a particular file.  

Download the code.

kick it on

Software Startup Lessons (Part 3) - Marketing, Sales & Growth

clock March 25, 2008 08:11 by author JKealey

We invite you to read Part 1 and Part 2 if you haven't done this already. A few days ago, Paul Graham had the following to say about our type of startup:

In an essay I wrote a couple years ago I advised graduating seniors to work for a couple years for another company before starting their own. I'd modify that now. Work for another company if you want to, but only for a small one, and if you want to start your own startup, go ahead.

The reason I suggested college graduates not start startups immediately was that I felt most would fail. And they will. But ambitious programmers are better off doing their own thing and failing than going to work at a big company. Certainly they'll learn more. They might even be better off financially. A lot of people in their early twenties get into debt, because their expenses grow even faster than the salary that seemed so high when they left school. At least if you start a startup and fail your net worth will be zero rather than negative.

Paul Graham

Lesson 10) Listen to your customers

screaming customers Some recent blog posts loudly taunt readers with titles such as I Repeat: Do Not Listen to Your Users. Of course, this is all just a blogging strategy as the end message is simply to spy on users to learn what they are doing with your software, not just listening to what they say they're doing.

Founders At Work informs us that a critical lesson when starting your own software company is to obey your customers, not your thick 75 page business plan. If they repeatedly ask for a module which you didn't plan for, and they're offering you money to build it, do it. It is not uncommon to read about companies starting out with a particular vision, building some internal tools to help them produce the target software, and ending up selling those internal tools instead. The original vision died, but they still built a successful company by being flexible and re-orienting their strategy depending on what the market dictated.

We lived this lesson first hand because our website was visited every day by independent store owners, looking for a particular piece of software. Even if they saw it was a solution for franchisors, they contacted us, wanting to purchase the software. We initially declined, but after thinking it through, we launched a side product targeted at independent stores. For our company, it's easy to spin-off products to target retail stores by cutting off all the integration built into FranchiseBlast. In our eyes, the product doesn't have the same value but, outside of the context of a franchise, it is a viable option.  Who knows, we may branch into software for independent retailers in the coming years (but I prefer our niche :) ) For now, it's a simple sideline to fund our core development. We also confirm the fact that it takes three times as long to develop a product as it does to create it for a single customer.

Furthermore, because we're self-funded, I feel we have a competitive advantage over our VC-funded competition. Our competitors want to skip the flat part of the growth phase and jump directly into the areas of highest ROI. Generally, this means developing one-size fits all software with (if you're lucky) tons of configuration options. We're not attacking the problem in the same way because we're building our architecture organically, refactoring when necessary. In the end, we don't tack on features, we analyze franchisor business processes and produce good solutions for them (both from an engineering perspective and a customer satisfaction perspective). This added personalized touch and desire to adapt to their operating environment is our competitive advantage.

Lesson 11) Software Sales

Because we're a small startup lead by developers, and because we think it's good for us, our developers do a little bit of everything which includes helping out with software sales and marketing. One of our partners is our salesman for the larger projects, but we're still actively involved. We've launched a small software product as a sideline because we had been getting inquiries for it on a weekly basis. It's something we already had and could launch without taking precious resources away from our main focus.

Here are some of our conclusions, from our perspective. Simply put, put yourself in a position where people want to purchase something from you as soon as possible.

Pushing your product is very hard.

Sending emails to potential customers: this generally does not work. We never send out mass mailings; we've spent a few dozen hours navigating hundreds of franchisor websites and picked half a dozen that we feel we could truly help. The experience was enlightening because we could extract patterns from the our potential clients' websites. However, in 2008, getting replies for an email is much harder than it was a decade ago when we first started our web design business. Spam has ruined email for people like us who take the time to write precise, customized emails. Back then, people didn't get that many emails and took the time to reply. Today, most people don't take the time to reply.

Cold calling is an arduous task and although the return on investment varies per product and industry, it is an essential part of business. Anyone can do the job but even professionals find it hard on one's self-esteem. Persistence is key.  For more tips, read this article

The long tail effect is very real, people come to us.

An insightful (and motivating) book is Chris Anderson's The Long Tail. To summarize the book in a sentence relevant to this section, given the negligible stocking/distribution costs of software and the ease of which we can search through the very large selection of different software which can be found on the Internet, it is now possible to create profitable businesses by developing software that targets a very precise niche. Simply put, create quality software that solves a particular niche's problem and people will find you, thanks to the Internet. We've experienced this first hand and confirm it is true.

Reality is a bit more complex than a simple if you build it, they will come, because you need to need to know your niche, work on marketing, getting in the search engines, figuring out the right price, etc. A more precise (yet recursive) statement would be if you build and promote something worth buying, they will buy it. In any case, in our first year, we reinforced our preconception that it is much easier to sell software to someone who comes to you than it is to push your software to someone who's not interested.

Karma: the simple solution for software engineers

Work hard and build a quality product. Assuming you are working on something with a reasonably sound business model, you're number one priority should be your product. There are lots of things to think of concerning marketing and sales, and you'll slowly learn to understand them if you have an open mind. In most contexts, writing good software is much more difficult than learning the ground rules of marketing and sales. Work hard, be honest, be open minded, and good things will happen. (Also, keep an eye out for the many people who don't follow these rules and try to screw you! :))

Lesson 12) Finding Other People

Running your own business is all about contacts (pretty much anything is!). At some point or another, you'll need to hire someone, partner with other companies, and find people to sell your product or services to. The more people you know, the better it is. You need to know people (and people need to know you) to be able to grow. We spent the biggest part of our first year working hard, undercover, and this was one of our mistakes. We weren't really trying to be undercover, but we weren't doing anything for people to know we existed. It took us a while to bother throwing our website online because we were so busy with our projects. Bad decision. The sooner your website is online explaining what you do, the sooner it gets on Google and the sooner people start finding you. Today, our blog (even if our readership is limited) helps us find and collaborate with many other people. We weren't sure what to talk about at first (we still aren't!) but we're having tons of fun.


image We just learned about Coworking last Friday and it's something really interesting!  Here is a quote from the Wikipedia entry that best describes what Coworking is:

"Coworking is an emerging trend for a new pattern for working. Typically work-at-home professionals or independent contractors or people who travel frequently end up working in an isolated way. Coworking is the social gathering of a group of people, who are still working independently, but who share values and who are are interested in the synergy that can happen from working with talented people in the same space."

We have been working from home for the past year and it can sometimes become difficult to spend your days alone.  We are communicating continuously inside the company, but sometimes you need to see people! Here in Montréal, we have Station-C that opened on February 4th 2008!  It is definitely not as expensive as renting your own office and you get to see more people right away, to exchange and make new friends.  When you work from home, the possibilities of making new friends at work are pretty limited even if you have 400 of them on Facebook!


Networking is definitely something every entrepreneur should develop.  Here in Montreal we have the JCCM (Jeune Chambre de Commerce de Montréal  / Young Chamber of Commerce of Montreal).  Software engineers are not renowned for their social skills, but we're still businessmen so we have to make new contacts and meet new people!  What is nice with the JCCM is that you can network with people who are in the same situation: they are starting new businesses and/or are working from home.  You can meet people that have the same problems as you do and can collaborate to help each other.  Furthermore, networking with people of the same age group may help you develop professional relationships that will last throughout your career. Networking is a crucial part of any business and can improve the way you solve problems because you know who to call when something happens. As with anything, finding a good balance is essential (you need to find more experienced mentors!).

Business Plan

Before launching our company, we worked on a short business case and participated in a Technology Venture Challenge. We didn't win, but it was a very beneficial experience because sitting down and thinking about what the hell you're trying to accomplish is a very rewarding process. We wrote the plan for ourselves, but we had the chance to talk to top technology entrepreneurs, investors, and business professionals.  They helped us drill down and learn our strengths and weaknesses. Recently, we wanted to repeat the process and found a local full-length business plan contest. Again, the contest is a simple external motivation to get things done by a particular date but we're doing it for ourselves. Hopefully we'll get to meet more interesting people and it will allow us to grow as businessmen. We strongly recommend writing a business plan, but only if you're going to do it right, for yourself. If you're going to botch the process, don't bother. The most valuable part is the forced introspection; if you skip that, you'll simply produce a useless 50 page document. 


We expect hiring to be our next challenge and are very inspired by Joel Spolsky's book on hiring. We're not too sure how applicable his strategies are in the first years or when you're not located in a metropolis, but it is good to have something to aspire to.  We expect to grow the team at the end of the year, and we're already looking for great candidates. Interested? :)


Conclusion: Infinite Number of Lessons

We could ramble on and on about things we learned during our first year. Simply put, the number of lessons are infinite.  We did perfect our technical skills but we did most of our learning in other areas.

Here are some lessons we could have talked about but chose not to:

  • Keeping up to speed with technological changes
  • How automation/scripting helps you save time
  • Don't forget the legal issues! Contracts, open source licenses, copyright, trademarks, etc.
  • The importance of a great web hoster
  • Versatility is key

We may post other lessons in the future, but for now we plan on creating a few technical posts with sample code. Be sure to let us know what kind of posts you like to see on our blog!

kick it on

Software Startup Lessons (Part 2): Communication and Collaboration

clock March 17, 2008 09:39 by author EtienneT

Welcome to part two of our three part series describing the various lessons we learned during our first year of a software startup.  You are encouraged to read the first part if you haven't already!

Problem Statement

In Part 1, we described our business' context and how we eat our own dog food. Indeed, we use the software we produce on a daily basis, helping us create quality products. A parallel can be made with our distributed team's communication patterns. Simply put, we're not all at the same central office, talking to each other all day. Our structure resembles that of a franchisor with franchisees distributed a several physical locations. The main reason we are distributed is to keep costs down while we develop our core infrastructure, but it does have the interest side-effect of forcing us to use the same communication tools a franchisor would.

Not only do we not work in the same building, we're not even in the same city! Because we work in independent offices, we have a greater control over our environment, which increases our productivity. Spolsky often talks about how developers should have private offices because outside disturbances kick us out of our zone. You can respond to your email every 15 minutes, but you can't make someone wait at your door for 15 minutes while you polish off a complicated algorithm.

In any case, given the fact that most geeks are not social creatures, you probably think that doing the majority of your interactions over the Internet is great, right? In reality, it's not always convenient  but we've started to become really creative (and efficient) with the tools we found to maximize our interactions.

We spend most our time chatting coordinating on Google Talk and move to Skype when voice conversations are required. Over time, we discovered some pretty nice software to communicate and we want to share these tools with you in this article.


  • How do we talk to each other and with people outside our company?
  • How do we exchange files?
  • How do we manage our requirements?
  • How do we demo our software, how do we program in pairs?

Lesson 4) Talking to People

Carrier pigeons might have played a vital part in WWII communications, but we're using more modern techniques.


imageSkype is the obvious choice for voice communication over Internet.  Don't tell us that you haven't heard about this tool before!  Because we are four partners in LavaBlast, we often need to have conference calls. All our meetings are done online via Skype conference calls, at no cost to us. Furthermore, we can call up a client on their regular phone using SkypeOut.  SkypeOut will call the client's real phone and will connect them to our conversation, at very affordable rates. Indeed, for $3 a month, we obtained unlimited outgoing calls to Canada and the US. Setting up a conference call is really easy and the quality is good (most of the time).  You simply need a good microphones and you're good to go.  In addition, if you have a webcam and a good Internet connection, the video quality of Skype is just amazing especially compared to MSN.  Talking to someone who also has a good webcam and a good Internet connection is almost lag free, in my experience.

Having a central phone number for a distributed office

Since we have a distributed office, we need to have a central phone number.  The most affordable solution that we found was Skype for business.  Basically you simply need to register a SkypeIn number anywhere in the US (not available in Canada yet) and when people call this number, it calls you on Skype.   The cheapest way to get your incoming phone number is to purchase Skype Pro (at $3/month) and purchase the number for $38 a year (and it was operational within minutes of purchase!). You can forward calls to another user or normal phone and even get voicemail with Skype Pro. Optionally, you may install the business version of the Skype program for additional functionality. Therefore, all the incoming calls go to our main salesperson and, if more technical details are required, the call can be forwarded to us.  Skype for business has a nice business control panel to control Skype credit purchases, phone number assignments, and much more. Additionally, because the phone number is associated to the company, we can redirect it to a new person if an employee is replaced or if someone is on vacation. We could have a 1-800 number, but I don't think we have the kind of call volume that would justify having one just yet.

We found the perfect phone number for LavaBlast: 1-201-467-LAVA (5282).  SkypeIn personal has a nice interface to check if a number is available, but the business panel interface doesn't.  If you want to purchase a specific number, I wish you good luck because you have to generate the numbers one by one!  We wanted a number that ended either with BLAST or LAVA;  we found the number with the SkypeIn personal interface and then tried to regenerate it, one number at a time, in the business panel.  We finally found one that ended with LAVA but couldn't find one that ended with BLAST.  The best way we found to generate multiple numbers was to press Ctrl and click like crazy on the generate button to open new pages in new tabs.  We eventually found the number we wanted!

Lesson 5) Exchanging Files

There are lots of cool startups focusing on better ways to exchange files and we're keeping an eye on them. For now, here's what we're using.


As software developers, we obviously use source control to manage our code. No surprise here. We even deploy our web applications using Subversion.


image We've developed a document repository in our franchisee/franchisor collaboration solution. We post our user manuals and a few other documents on there; it is our distribution center for completed documents.

Microsoft Groove

We use Microsoft Groove which is a party of Office 2007, as our main internal document management tool. Groove is much more than a document repository, but we only use this feature.  Groove is simple to use and install because it distributes the files on all the peers instead of having to setup a complex server. Furthermore, it is better than a shared network drive because it has change notifications plus it can be accessed even when you are offline. There are a few drawbacks, but in general, it's a good simple solution for the low volume of Office documents we work on. 

Lesson 6) Requirements Engineering

The first post on the LavaBlast blog was related to requirements engineering and how we managed our pile of requirements written on the back of (sometimes used) paper napkins. More seriously, we've found it very beneficial to collaboratively define our software requirements with our clients. Constant feedback is the key to writing good requirements, and using collaboration tools is a must.


We've been playing with ScrewTurn wiki as our main wiki over the last year, for both for our internal use and to interact with our clients during the requirements engineering process. It is very easy to install (trivial) and it is very very fast. Editing a page is very pleasant because it is nearly instantaneous when you save a page... it just feels blazingly fast. Furthermore, because it is a free and open source project, you get to spend money on Super Mario Galaxy instead.

During our software engineering capstone project, we used TWiki as our primary requirements engineering tool, a couple years before the strategy was discussed in IEEE Software. Although we've enjoyed ScrewTurn's simplicity during the last year, I think we're ready to revert back to the more feature-rich TWiki. Installation is a pain (less now than before), but the syntax much more natural. Furthermore, we already have the infrastructure in place (using page meta-data) to let us manage our requirements.

Lesson 7) Desktop Sharing

Today, sharing your desktop is an essential operation for any software startup. You can easily demonstrate applications to potential clients or perform pair programming, without having to be at the same physical location.

Lotus Sametime Unyte

Trying to explain something to someone over Skype is not always fun, especially when the client is not a technical person. Because a picture is worth a thousand words, showing software is much quicker!  During most of our first year, we used Unyte to do just that.  With Unyte, you simply have to start the application, decide which window to share (or share the entire desktop) and then send a link to the person (or group of people) that need to see it.  Recipients click on a hyperlink and load up a browser-based Java applet to see the shared windows. It's as simple as that.  The client doesn't have to install anything and it's fast! The host will receive an alert when the viewers can see his screen.  Unyte, used in conjunction with Skype, is really a great mix for meetings and sales demonstrations. We used the version for five people and it worked well, until we found Microsoft SharedView.

Microsoft SharedView

A few weeks back, we discovered Microsoft SharedView while it was still in beta. SharedView is similar to Unyte, but 15 people can participate in a shared session.  The only big drawback is that everyone has to download the software.  So if you want to quickly present something to a client, it's a little bit more complicated if they have to install it.  However, SharedView does allow any participant to share their desktop for the others to see (only one person can share at any given time). During a software demo, we used this capability to have the client show us their current point of sale! Additionally, the software gives other people the possibility to take control of the session and perform operations on the computer that is sharing an application. You can also share documents pretty easily with everyone and send chat messages, but we still use Skype for voice communication. We now prefer SharedView to Unyte when it is a possibility to install software on every participant's computer.

Lesson 8) Blogging!

We've been able to connect with tons of great people thanks to our blog, and have lots of fun perfecting our writing skills. We find that figuring out what to say (and what your audience is interested in hearing) is the hardest task when you start a blog. We still don't know if we should focus on giving away code or writing more experiences pieces like this one. Let us know!


Our blogging software, BlogEngine.Net, is simply terrific.  Free, fast, really easy to theme, has some good extensions and integrates really well with Windows Live Writer.  One of the main advantages for us is that it is open source and it is written in .NET, allowing us to perform minor behavior changes as needed.   It still has a few bugs that can be annoying, but from what we have seen so far, it is performing really well.  It supports multiple authors, an important feature for us because we have two people posting on the blog.

Lesson 9) When not to use communication tools

The most important lesson we learned during our first year of operations as a distributed development team wasn't a revelation but rather a confirmation of our expectations. Communication and collaboration tools are great, but technology doesn't solve conflicts. We're a closely knit team and have worked together for a number of years, greatly reducing the number of conflicts we may have. The conflicts we have are generally superficial, but as an example, let's consider an architectural decision where the two decision makers have divergent opinions on the best solution. Although instant messaging is great for efficiency reasons, it is not the best medium to argument on the merits of your solution. Indeed, we've all seen the politically incorrect "Arguing on the Internet is like running in the Special Olympics; even if you win, you're still retarded". The main problem is related to the lack of emotional expressiveness of concise instant messages or emails and since it is discussed in great lengths by very good authors, we'll leave a detailed analysis of the situation to them! As a side note, firing people via email might have seemed like a good idea for RadioShack, but we at LavaBlast shall stay away from such brilliant strategies!


Communication is the most important part of starting a business. Even if you're the only person in your company, you still have to communicate with your customers! We hope that you'll discover at least one cool collaboration tool today! Remember to come back next week for Part 3 of our series.

kick it on  

How I lost my WinDbg virginity

clock March 13, 2008 10:32 by author JKealey

image Jeff Moser's recent post on becoming a grandmaster developer was very inspiring. I'm now consciously forcing myself to work on different, harder, problems on a daily basis. Today, I wanted to tackle a nasty memory leak on FranchiseBlast that had been bugging us for months. Actually, it only made the ASP.NET application restart twice (which has no impact because our session state is kept in the state service), but we've been postponing this bug for months :)

The bug was simple to reproduce. Simply refresh a particular page a hundred or so times and observe the worker process' memory usage continuously increase. dotTrace was not very useful today, because most of the memory was consumed by Strings.

I landed on the If broken it is, fix it you should blog. Reading the blog post and noticing how Tess knows much more than I do about debugging .NET applications, I figured I'd improve my .NET debugging skills by playing with WinDbg. My guess is that many of you haven't played with WinDbg either and that's why I thought I'd write this post. With no previous experience with the tool, I managed to learn enough to be able to solve my bug within a couple hours (learning time included). However, this is a situation where I am grateful to have had the chance to play with the low-level details (assembly language / computer architecture) during my undergrad software engineering studies.

WinDbg Installation

The article says simply run "!dumpheap -min 85000 -stat" to figure out which objects are using over 85k memory. Vaguely remembering doing something similar in VS.NET, I tried the command window, to no avail. After some googling, I understood we wanted to launch WinDbg with the SOS extension (Son of Strike.. not Summer of Sam :)). I managed to get everything running (installed WinDbg, attached to w3wp.exe, ran ".loadby sos mscorwks") and later found setup instructions on the same blog, which would have made my life easier. I still haven't remembered (nor have I looked) how to load SOS inside VS.NET instead of the external tool, but I'm pretty sure it can be done.

Playing around

I played around with various strategies found on the same blog, such as figuring out how much I was caching.  I didn't think caching was my problem, but wanted to play around with the tool.

Attempting to run an interesting command found on the aforementioned blog post, I ran into a syntax error:

.foreach (runtime {!dumpheap -mt 0x01b29dfc -short}){.echo ******************;!dumpobj poi(${runtime}+0x3c);.echo cache size

Of course, this was a blog formatting issue, as the real command was:

.foreach (runtime {!dumpheap -mt 0x01b29dfc -short}){.echo ******************;!dumpobj poi(${runtime}+0x3c);.echo cache size:;!objsize poi(${runtime}+0xc) }

It didn't teach me much :) One command that appeared to be very interesting to me was !dumpaspnetcache. This appeared to be exactly what I was looking for. However, the command is only available in SOS for .NET 1.0/1.1 and I'm trying to debug a .NET 2.0 application. I did lose some time unloading the current SOS and loading the one in the clr10 subfolder (which offers !dumpaspnetcache), but it complained that the command didn't work for .NET 2.0.

The main lesson learned here is that !dumpaspnetcache does not work on .NET 2.0. There is a workaround listed in the comments of the blog post, but I didn't try it out.

Solving a problem

  1. I identified that most of my memory was consumed by strings using !dumpheap -stat.
  2. I ran !dumpheap -min 85000 -stat to a view only the largest strings. I observed only three strings (out of approximately 400,000) and that, in total, they accounted for less than 10% of the memory used by my strings.
  3. I ran !dumpheap -mt 790fd8c4 -min 85000 to view the memory locations of these strings (where the MT 790fd8c4 was in the results of step 2).
  4. I ran !dumpobj 0c6800c0 to display the contents of one of the strings (where the address 0c6800c0 was in the result of step 3.)
  5. I saw the string was a simple ASP.NET AJAX script built by the framework. Repeating for the other objects, I didn't find anything interest. In addition, these were only 3 of my 400,000 strings.
  6. I ran !dumpheap -min 10000 -max 85000 -stat to get a feeling of how many objects were of a particular size. I repeated the exercise for various ranges and ended up discovering that 90% of my strings were under 100 bytes (50% of the memory usage).
  7. I ran !dumpobj 17386ce8 on one of the random 100 byte strings and discovered a country name. Interesting. This means I have a country name in here that is not getting disposed. I only have country names in my address editor, which uses a SubSonic DropDownList.
  8. I ran !gcroot 17386ce8 to look at who was referencing this string and confirmed that it wasn't getting collected by the garbage collector (see below).
  9. I looked at the handles and noticed that I had a user control which was listed as an event listener. Therefore, I discovered that we were registering the UserControl to listen to an event but never broke the link when we were done with the UserControl.
  10. Looking at the code, I saw we were adding the event listener in the Page_Load but never removing it. I now simply remove the event handler during the Page_PreRender event, when listening to events it is no longer necessary in my scenario.
  11. I repeatedly loaded the page and saw memory go up but back down again after the garbage collector does its job. Problem solved! (knock on wood)

Here's the result of my !gcroot command.

17cd3dc4(System.EventHandler`1[[LBBoLib.BO.Utility.GenericEventArgs`1[[System.Web.UI.Page, System.Web]], LBBoLib]])->
173c8e18(System.EventHandler`1[[LBBoLib.BO.Utility.GenericEventArgs`1[[System.Web.UI.Page, System.Web]], LBBoLib]])->


In total, I only spent a couple hours fiddling around with WinDbg but I am very happy to have a new tool in my tool belt (and to have solved my bug). I strongly recommend reading the various tutorials on Tess's blog. I also found a WinDbg / SOS cheat sheet, which you might find interesting.

kick it on

Software Startup Lessons (Part 1): The Basics

clock March 11, 2008 08:49 by author JKealey

Jennifer, one of my high school friends living in Montreal, recently started her own hair salon. Her employees live in Boston and Florida whereas her biggest customer is located in New York. The previous declaration makes no sense given the industry, but it does make sense in ours! Software can be produced anywhere and delivered to customers worldwide via the Internet. Furthermore, our increased connectivity helps businesses target very specialized niches which would not be viable on the local market. (For an overview of the subject, please refer to the excellent The Long Tail.) We're pushing it one step further with LavaBlast, which we started about a year ago, because our team is distributed. We can be categorized as a bootstrapped MicroISV (less than ten people producing software products with no outside funding), and we'd like to share some of our experiences.

We love to read about other startups and why they succeeded, such as Jessica Livingston's Founders At Work, but we're even more interested in companies that failed. On one side, it is very motivating to ready books such as Founders At Work and learn how the guys behind Hot Or Not started it all and got lucky with a very simple idea. On the other hand, knowing more about failures helps you learn from other people's mistakes. Books like Facts and Fallacies of Software Engineering helped, but were are not start-up focused. IMG_2940 If you're considering starting your own software startup, do take the time to read up on why startups fail, even if it is not the subject of today's post.

I hope you'll enjoy reading this series of posts and will be unable to resist posting comments and starting interesting discussions. Part 1 focuses on the basics, Part 2 revolves around communication, and Part 3 talks about what we've learned concerning marketing, sales, and growth.

Our Context

LavaBlast Software was started by two recent graduates from the software engineering program at the University of Ottawa in Ontario, Canada. After the bachelor's degree, Etienne moved to Montreal because of an attractive employment opportunity while Jason completed his master's. Both have been programming since their early teens on a wide variety of software systems in their various positions at companies of all shapes & sizes. From tiny web design shops, to medium-sized software firms in the electric industry, to second language schools for civil servants, to large Government departments, the founders had the chance to play with software from two perspectives. One one side we have small software companies who live and breathe software and on the other we have large-scale businesses in which most people are not necessarily computer-savvy (except for the IT departments). Additionally, we sidelined as male strippers at bachelorette parties, to pay for our university studies.

It did not take long to discover that we were so passionate about software that we wanted to start our own software company, not work in corporate Dilbert-reading sweatshops. Of course, this is simply caricature, as we worked on very interesting/challenging systems while in larger companies. There's nothing wrong with working in IT departments, but it wasn't a fit for our entrepreneurial drive. On top of that, we love working on projects where we get direct feedback from our customers, instead of internal company tools.

It was clear we were to start a software company, but did not know what nor when. The original plan had been acquire experience and a monetary cushion to allow us to start working on the next big thing. Before taking the plunge and leaving our day jobs, we wanted to have a good idea. We considered various ideas, but being recent graduates with student loans, going out on a limb and working with no revenue on a magical idea for an undetermined period of time was not a very attractive solution. However, we did find a very attractive business opportunity with people with whom Jason had been working for almost three years, on various web development projects. These partners have franchised their business and have acquired precious experience over the years. They are very knowledgeable and have a clear vision of the various business processes from the point of view of franchisors. After 20-some years in the business, they know what software is required, what to focus on, and how to support it.

Discussions ensued, and LavaBlast was formed. We produce industry-specific software solutions for franchisors. All our products are integrated via FranchiseBlast, which cuts down franchisor/franchisee costs at the same time as favoring re-use from a software engineering aspect. We have a base product offering which we tailor to our customer's specific business processes. In a sense, we sell software products with a side order of software services.

In summary:

  • No outside funding.
  • Small distributed team.
  • A mix of products and services.
  • We eat our own dog food.

Lesson 1) The Great Idea

Simply put, chances are you won't think of the next big thing. Even if you do, you probably won't have the resources, experience, or contacts, to turn your idea into billions. We were not expecting miracles but were on the lookout many months in advance. One thing we learned while reading Founders At Work is that many software startups are formed without the faintest clue of what the product/service will be. The most important part of the company is not the idea but the people. A small and closely knit team of people who've worked together in the past is a recipe for success, regardless of the idea. Indeed, execution is key! Partnering with people who have a track record of bringing ideas to reality is, in our opinion, the most important part of the business.

We are very happy that we did not wait on having a brilliant breakthrough idea and started our company immediately. We evaluated opportunities and picked the one that made the most business sense, knowing we can adapt along the way. Having made the plunge early in our careers, we felt we didn't have anything to lose because we didn't have that many constraints such as leaving a high paying job, a mortgage and student loans to pay, kids to feed, etc. The more acquainted you get with stable employment, the harder it is to leave. Still, it is worth mentioning that while we were very comfortable with our technical skills, our network of contacts is not as large as it would have been if we had been under someone else's employment for 5-10 years. On the bright side, we don't have 10 year of accumulated bitterness to carry around and we're in the best phase of our development careers (from a production standpoint).

Simply put, talk to people around you and reflect on what pieces of software would scratch your itch. There are business opportunities all around you... all you need to do is decide on what's the best fit for your current situation! Are you smart and can get things done? Are you able to adapt to your environment and pursue different opportunities when they present themselves? If so, don't wait for an idea that may never come and enjoy the ride!

Lesson 2) Eating your own dog food

It's been said time and time again, you need people using your software in order for its quality to reach high standards. Here at LavaBlast, we're fortunate to be able to develop UsWare because we're involved in our partner's the day-to-day franchise operations. As developers, we proactively solve problems before anyone reports them because we feel like we are part of the franchise. Furthermore, since we built our infrastructure to be re-usable, we recently launched SupportBlast as a clone of our FranchiseBlast solution. SupportBlast is basically our mini-CRM and we've integrated our software registration and license key generator in there. Although the strategy does have its limitations, using our own products helps us boost our software quality. Furthermore, for our kind of software, it would have been impossible to develop anything coherent without actual customers.

It takes ten years to build a great software product and it also takes ten years to become a software grandmaster.  You understand that quality takes time and effort and you'll only discover your software's weaknesses by listening to critique. It's better to be harsh on yourself than listening to someone scream over the phone, don't you think? 

Lesson 3) Mix of products and services

As stated previously, our company has currently received no outside funding (nor have we invested millions from our personal fortunes). We doubt angel investors or venture capitalists would be interested in our company because we're not aiming for a 100:1 return on investment. We could change our strategy and go for an all-or-nothing gamble, but we're more interested in growing our company organically. We know our company can be profitable using our current strategy, but we understand that we are not going to be the next FaceBook and my guess is that your company might fall into this same category. More importantly, we agree with Spolsky's model of company growth, and aim to be profitable from day one.

The main question for our type of company is how can we pay the bills while developing our product? The holy grail for return on investment in our business implies no additional work on the developer's part to support a new customer. Microsoft doesn't need to make adjustments to Word to sell it to a new customer and FaceBook allows its users to change the content of their personal pages themselves. On the opposite end of the spectrum, a good web design firm will create interfaces from scratch, adjusted to the needs (and tastes) of each of its clients. In the end, we want to be a product company but we need to build good products (and accumulate a critical mass of customers) before it pays the bills. We wanted to start our business immediately, not work on it on weeknights and during weekends for a couple years. Because of this, we decided our main interest was our product line but we'd perform services on the side as short-term an income generator.

We were open to external contracts, but did not end up doing any work outside of our product line. We're very happy of this fact because the solution managed to sustain its development without having to dilute our efforts with side-contracts (such as bachelorette parties).


Have fun but expect a bumpy ride. If you're not happy in your own company, doing what you want to do, you have a problem. Still, as with anything, you'll have some good days and some bad. In a startup, expect a roller coaster of emotions because you'll certainly get very excited by a certain situation but crash & burn when it doesn't materialize. In addition, not all work is exciting. You're starting a company and you have to do everything yourself. Doing accounting at 11PM on a Saturday night is not my idea of fun. Generally, however, it is very gratifying to build your own company from scratch and if you're fit for the challenge, I encourage you to try it out! The worst thing that can happen is that you will fail, lose some cash, gain valuable life lessons, and go back to working for someone else (or start over with a new idea :)).

Come back next week for part 2!

kick it on

Month List


The opinions expressed herein are my own personal opinions and do not represent my employer's view in anyway.

© Copyright 2017

Sign in