Fixing Firefox Flash Video Sound problem on Ubuntu Dapper
Method 1
sudo ln -s /usr/lib/libesd.so.0 /usr/lib/libesd.so.1sudo mkdir -p /tmp/.esd/sudo touch /tmp/.esd/socket
Method 2
sudo aptitude install alsa-osssudo gedit /etc/firefox/firefoxrc FIREFOX_DSP=”aoss”
Using CruiseControl.NET with MSBuild
Introduction
Originated from Extreme programming, the concept of Continuous Integration has been gradually adopted to other traditional software development methodologies. I think it will bring tremendous value to our .NET based projects so I decided to set up the environment and give it a try.
CruiseControl.NET is one of the most commonly used Continuous Integration tools on the .NET platform. It works well with NAnt to build Visual Studio 2003 based projects, but as of NAnt 0.85-rc 4 there is no support for task for Visual Studio 2005 projects. As a result, NAnt can only compile Visual Studio 2005 solution on a per project basis. By default, unlike VS 2003, Visual Studio 2005 uses a new file structure based Web project, which doesn’t have a project file. This imposes even more problems for NAnt to work with VS 2005 solutions.
Setting up CruiseControl.NET and NAnt to work with Visual Studio 2003 projects is relatively easy, so I will try to set up CruiseControl.NET to work with Visual Studio 2005 projects here. Since Visual Studio 2005 and .NET Framework 2.0, Microsoft introduced a new extensible, XML-based build engine named MSBuild. In fact, the solution files and project files in VS 2005 are all written in MSBuild format. So instead of using NAnt with CruiseControl.NET, we are able to leverage MSBuild for compiling VS 2005 based solutions.
Prepare to install
First make sure the project compiles with MSBuild, by checking out a fresh copy and navigate to the project root directory then issue “msbuild MyProject.sln”
Install CruiseControl.NET
Installing CruiseControl.NET is easy. Simple grab the installer from CruiseControl.NET at Thoughtworks. I also downloaded and installed CCTray. CCTray is used to view and control the build process from client side, it can be installed locally on the build server as well as remotely.
The approach
In this approach, I use CruiseControl.NET to run NAnt scripts which in turn use MSBuild for compiling the Visual Studio 2005 solution. MSBuild is more capable then just compiling, but I am more familiar with NAnt so it’s easier for me to setup NAnt the way I wanted. Basically I use NAnt script to clean up directory, get source code, and call MSBuild executable to compile. I am sure CruiseControl.NET can employ MSBuild directly and MSBuild is able to do things like cleaning up the directory and getting the source code. But I won’t get to that until I actually have time to learn MSBuild.
Files that will be edited/created are as follows:
- NAnt.exe.config – NAnt config file (located in the NAnt bin directory)
- ccnet.config – CruiseControl.NET config file (located in the CruiseControl.NET installation directory)
- cruise.build – NAnt build script (new file created in “C:\ProjectBuild\CruiseControl.NET\server\MyProject\WorkingDirectory”)
Configure CruiseControl.NET
Add settings to ccnet.config file, add project section as follows
MyProject http://localhost/ccnet/default.aspx?_action_ViewProjectReport=true&server=local&project=MyProject
$/MyProjectRoot/MyProject
MyUserName
MyPassword
\\server\vss
C:\ProjectBuild\nant-0.85-rc3\bin\nant.exe C:\ProjectBuild\CruiseControl.NET\server\MyProject\WorkingDirectory cruise.build
run
1200
As aforementioned the configuration didn’t use MSBuild directly, rather it relies on NAnt to define the build tasks.
Configure NAnt
NAnt config file
MSBuild does not come with a XML Logger by default, so I need to use an external logger to get this functionality. I download the dll from here. And then I move the ThoughtWorks.CruiseControl.MsBuild.dll file to “C:\ProjectBuild\CruiseControl.NET\Tools”.
Add MSBuild property to properties section
NAnt.exe.config
value="C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\MSBuild.exe" overwrite="false" />
value="ThoughtWorks.CruiseControl.MsBuild.XmlLogger" overwrite="false" />
value="C:\ProjectBuild\CruiseControl.NET\Tools\ThoughtWorks.CruiseControl.MsBuild.dll" overwrite="false" />
NAnt build file
Finally, this is my NAnt build file
cruise.build
password="MyPassword"
localpath="Source"
recursive="true"
replace="true"
writable="false"
dbpath="\\server\vss\srcsafe.ini"
path="$/MyProjectRoot/MyProject"/>
References
Sharepoint 2007 comes with Blogs, Wikis and RSS
Reading the Applying Domain-Driven Design and Patterns book
I am half way through reading the Applying Domain-Driven Design and Patterns
The Applying Domain-Driven Design and Patterns
My 2 cents on agile development
In Feb 2001, 17 prominent members of the software community came together and created the Agile Manifesto. From that moment on, agile development has gradually become known to the software development world.
I got to know agile development methodology back in 2004, while I was preparing for a Co-op interview. Agile development methods are a collection of development processes including Extreme Programming, Scrum, Crystal, etc. The company was using Extreme Programming (aka XP). I was intrigued by the flexibility that the XP brings to the table. It emphasizes team communication over rigorous design documents. It boasts ideas such as customer involvement, pair programming, test driven development (TDD), and refactoring.
At my first glance, XP seems really, well, Extreme. But when I dug more into it, the whole idea makes sense. It's like that new solar powered air conditioner. Not many people thought about it but when you get to know it. It simply just makes sense.
The classic waterfall methodology and some of its alternatives treat software development process as a traditional engineering process. The development cycle is divided into several phases and executed in sequence, which is seemingly a solid practice. In building construction. Detailed and specific documents were produced and followed. Engineers know exactly what the building is going to look like and how it's going to function. Every step is carefully calculated and measured. Why? Because they have only one chance to build it right. Just like a waterfall, there is no way back.
In my opinion, these methodologies miss some vital and obvious facts:
- Software is Soft. It's flexible and dynamic. It tends to change over its lifetime.
- Software developers are capable of, and usually have to, making ad-hoc decisions during development. Design documents and development rules are hard, if not impossible, to follow and enforce.
- No offense, but customers usually don't know what they want , therefore, it 's impossible to envision exactly what the final product will be.
On the contrary, agile methods are adaptive and flexible. It allows software to evolve by not trying to predict unforeseeable future. Instead, detailed analysis and up-front design are integrated into every step of the coding process. In other words, developers always have the confidence and agility to perfect the design. Unlike traditional methodologies which try to avoid requirement changes, agile methods expect the software to change and grow. From a software developer's perspective TDD and Refactoring are arguably the two most significant strategies in agile development. They raise the confidence level of the developers which in turn allow them to improve design and coding while programming.
Ok, Clearly, I've used too many vague and fancy adjectives to describe agile development. Agile development is a board subject so it's impossible to cover everything in a tiny blog entry especially with a entry labeled "My 2 cents on…". So I decide to end this soulless entry here and I will elaborate on more specific topics like TDD, refactoring, and team management as I continue my endeavor to conquer agile development.
