Let's start a blog -
we'll build a community.
We'll throw out ideas
for a world of diversity
We'll build a community -
attract like-minded thought.
For a world of diversity -
they all need to be taught.
We'll throw out ideas
if they refuse to adhere.
Let's start a blog -
is that an echo I hear?
Does Microsoft have a set of guardian angels? Think of all the killer threats they've seen over the years.
Threats came from Ashton-Tate, IBM, Lotus, and Novell
Then free software, open source, and the viral GPL
Oracle, Google, Sun, and Job's Apple
All four of them fought, and are still here to grapple.
There was AOL, Sony, Netscape, Nintendo
Palm and Symbian both reached a crescendo.
There are Linuxes and Unixes - NeXT and OS/X.
Some even say Vista is a suicide hex.
Bay Staters and Iowans both had their day.
So did the EU, Real Player, and the American DOJ.
People included Ellison, McNealy, and Judge Penfield Jackson.
If Microsoft were England, they'd all be Saxons.
There is the Internet, the web, and the network computers.
Don't leave out Java, or Ruby (with its great set of hooters).
XML, Hypertext, and a ubiquitous script.
They've all come together to give Microsoft fits.
If Microsoft does have guardian angels ... they've been working overtime.
We hold many beliefs in software development. We believe the tools we use are better than the tools "someone else" uses. We believe our process is better than the process "someone else" uses.
Too often I see technical people use their beliefs as a sword to attack someone else. Attacks rarely persuade the other party. More often than not, the attack puts the other party into attack mode. They have their own set of beliefs.
Use your beliefs as armor to strengthen your own position.
Don’t tell me what’s wrong with my approach- show me what works with your approach.
Persuade me with elegant solutions and successful results.
In December of 1998, I joined an Internet startup and dove into web development. This was also my first contact with Microsoft tools. I was a stranger in a strange land, having come from the world of embedded systems programming. Although I had written two Windows applications previously, I wrote the applications using Borland tools, and followed the Document-View architecture of Borland's OWL framework.
The startup put together a great team of hardcore C++ programmers, and we built a rich domain model. We didn't use the term "domain model" at the time, but a domain model it was, complete with a commercial, object-oriented database for persistence.
We chose to use classic ASP for the UI. To make our domain model available to ASP, we had to dress up our domain model in COM jewelry. COM provided the binary interoperability for ASP to call into our C++ middle tier. The artificial layer disturbed me and I wondered why we didn't write the entire application in C++. After all, there was this CGI / ISAPI approach we could use to avoid all the COM cruft. Thankfully, my thoughts along these lines never infected anyone else at the company.
Eventually, venture capitalists came along and told us we had to kick our object-oriented database into the street. If we wanted to support millions of users and roll like pigs in a sty full of cash, then we needed to use a scalable database like Oracle. With some homegrown code generation tools, we buried all the relational database cruft underneath our domain model (I've been a fan of code generation ever since). Again, we didn't think of our class hierarchy as a 'domain model', we all assumed this was how software was built. You keep the cruft outside the heart of your application, or the application runs the risk of infarction.
Over the next couple of years, we ripped through $60 million dollars in venture capital and joined a sock puppet in the Internet graveyard. I did some consulting and some video game work, and then ended up back in web development and the Microsoft world.
.NET was an exciting technology to me. The middle tier and presentation layer could use the same runtime, the same string type, and even the same language. No artificial cruft! There was even a clean data access API in the form of ADO.NET. If that sound's crazy, then try to understand my perspective. Based on the majority of my previous work, I expected the following from a software tools vendor:
In other words, I expect a generic tool for building the least common denominator of applications. Visual Studio is more than just a command line compiler - it provides all sorts of designers and wizards, too. I initially found these additions interesting. Then I realized the designers and wizards only make short work of creating an application, which misses the hardest part of software development.
One thing I've learned over the years is that writing the initial code for an application is easy. No matter how much you struggle with language syntax, or thrash around to find the magic incantations for a finicky API – the initial code is easy. At least relatively easy.
The hard part is coming back and changing the initial code. This is an area where many of the designers and wizards in Visual Studio fall flat, or lead developers in the wrong direction. For instance, the typed DataSet generator requires you to fill in all sorts of information about your data source, yet it doesn't detect simple schema changes that can break an application. The declarative data-binding features with embedded SQL commands make drag and drop development simple, but produce a brittle application that is resistant to change. Visual Studio seems headed in the wrong direction for enterprise developers.
When the inevitable changes come, the best weapons I've found to have in place are refactoring tools, unit tests, and a rich domain model. Refactoring tools help you make common changes to a code base, while one of the many benefits of unit tests is that they can ensure those changes didn't break expected functionality. The domain model / business layer is the heart of the application and is what differentiates each software project. Everyone has user interface code, data binding, and XML parsing. These are the easy parts to pick up and maintain from project to project. The business logic is unique, and deserves isolation and maximum clarity.
Visual Studio only provides a unit-testing framework in high level SKUs. Refactoring tools exist in Visual Studio, but are cumbersome. A rich domain model? Don't expect too much help from Visual Studio in this area. The good news is we might be getting closer in the future with an entity framework– or at least we can still hope.
Visual Studio is a far cry from the land of command line compilers, yet it's still far cry away from what we need for non-trivial applications. That's ok - we should never expect a single tool or environment to give us everything we need. Instead, we need to apply thinking, theory and design with a mix of the best tools available for the job at hand.
The good news is there are plenty of resources and tools available outside of Visual Studio. Here are some links to resources and tools I know. If you are only using Visual Studio today, I'm sure you can find something in the list to improve the maintainability of your application.
For years, I've owned a note pad where I jot down thoughts. My note pad is electronic now, but the purpose is the same – capture an idea before the current of the day sweeps the idea away. Keeping an idea journal isn't a new concept. Comedians, scientists, writers, professors, inventors, and others have found inspiration in their notes for centuries. My notes have certainly provided stimulation for this blog.
I have a section in my notebook to store "blog-able thoughts". Over the last year, however, many of these blog-able thoughts haven't seen the light of day. I have time constraints, but I've also had reservations. I began to have reservations when I realized more people were subscribing and reading these posts. I felt like I'd be wasting your time if I write opinion pieces and rants, both of which are cheap and readily available on the Internet. I've also purposefully avoided specific topics because I didn't want to contribute to the echo chamber. This reserved approach has turned blogging into a chore, and chores are no fun – just ask any teenager.
I need to shake this blog up, and clear out my notebook.
The tag line on this blog is "Experiments in Writing". When I started, I intended to write about experiments (by demonstrating code that works (or doesn't work)), as well as experiment with writing (by throwing in the occasional comedy, poem, or piece of art). The time has come for a writing experiment. I just picked up the last music CD I purchased, and I'm going to use the track titles as the titles for my next 13 posts. I'll try to match the titles with thoughts in my notebook for some stream of consciousness writing on software development, ala Jeremy.
This was just a fair warning to anyone who doesn't like wasting time on opinion pieces. You might want to check back in July.
This afternoon I kicked off a Team Build and waited...
.. and waited ...
... and waited...
... and then realized something was terribly wrong with the TFS server. A general sense of panic swept into the office when we couldn't bring up the login dialog box on the server's console. A recent rash of hardware failures made us jumpy and we feared the worst. Just a couple months ago, 2 out of 3 drives in a RAID 5 array died in a single afternoon. What are the odds?
The server came back to life after a hard reboot, but the last build was "stuck". There wasn't any activity on the build server, yet TFS thought the build was still in progress. I couldn't find a way to stop the build in Visual Studio, so I turned to the Internet. My first search brought up KillBill.exe – a utility in the TFS PowerPack that "Stops a Team Build currently running on a build server". Perfect!
Afterwards, I found out you can also stop a build from the command line, but that's not nearly as entertaining as an application that evokes thoughts of a hyper-violent kung-fu cinematic mashup.
The other utility in the TFS PowerPack is the "Work Item Terminator". There is a theme at work in this project, and I like it. I hope future versions include the "Clockwork Orange Build Timer" and the "Check-in policy Robocop".
Note: this sample is now updated to work with Silverlight 1.0
I decided to catch up with the latest Silverlight release. With the WPF/E release last year I dabbled with Conway's Game Of Life, but instead of porting old code I decided to try something new. During my short stint in the video game industry I found Gamasutra to be a great source of technical articles, and the article "Advanced Character Physics" by Thomas Jakobsen gave me an idea. The article describes the verlet integration algorithm used in molecular dynamics models. The subject matter sounds intimidating, but the algorithm turns out to be relatively simple.
Verlet integration (pronounced vehr-LEY (think French)) doesn't track the velocities of each particle in a system. Instead, Verlet calculates a particle's next position using its current and previous positions. The nice feature of Verlet is that enforcing a constraint (like not allowing a particle to move outside of a wall, or not allowing a particle to move too far away from another, attached particle) is almost as easy as repositioning the particle – at least there is no need to calculate a new velocity.
I built a simple, swinging "rope" in Silverlight. The "rope" is composed of 12 Pluralsight logos. Gravity pulls the rope downward, while a left-to-right breeze can blow the rope across the screen. Credit Ian Griffiths for building the Pluralsight eye in XAML . A static screen shot doesn't show the realistic motion ...
... so if you have the Silverlight 1.0 beta install, try the sample here.
You can download the source code here.
Note to Karl Seguin: don't download the code. This was a late night hack on a holiday weekend. If you break into tears then it's not my fault! :)
OdeToCode by K. Scott Allen
Subscribe
Twitter
Search
About
Learn C#