CodeSnipers Lives

Hey, if you've come across the site today, welcome! We're out of beta and not everything is working perfectly, but the bulk of it is. Regardless, we have some great content from some great people with a wealth of experience, skills, and knowledge.

You can read Alex's swift kick in the tail about software documentation entitled: We didn't need documentation back then!.

Or, if you're looking for something a bit more technical this morning, you can read Joseph's review of Cross-Platform GUI Programming with wxWidgets.

Or, if you're not the least bit interested in the code and tools but are concerned about representing and helping the users, you can check out Duane's entry on listening to user feedback entitled: Pave the cowpath.

This is just a small sample of the content available here and with a bit of exploration, you'll find quite a bit more. We have some sharp people sharing quite a bit of wisdom.

And don't forget, if you are particularly interested in a contributor here, they have all written introductory entries and you can check out their personal blog.

Cross-Platform GUI Programming with wxWidgets (book review)

If you spend time writing applications targeting several platforms like Windows/Unix/Mac or even embedded platforms like Pocket PC (WinCE) then, no doubt you have come across a open source widget system called wxWigets.

Book : Cross-Platform GUI Programming with wxWidgets
By : Julian Smart, Kevin Hock, Stefan Csomor

Cross-Platform GUI Programmg with wxWidgets, was published recently, on July 25, 2005, and is a must for any cross platform UI developer. The goal of wxWidgets is not to replace UIs such as MFC or Motif even or GTK+, but to work above them. For a cross platform developer, this is a saving grace. I could now build advanced cross platform applications that have a native look and feel on the target platforms.

Perhaps like many, if you are unaware of wxWidgets ,also referred as simply wx, you may think its just another GUI, and the problem with that, is having people to relearn GUIs, which can lead to fustration. Even Joel Spolsky cautions about user fustrations with UI design, from his classic User Interface Design book. Lets face it, mostly everyone has experienced Micrsoft's Windows UI. So we have come to accept and expect certain Microsoft UI formalities. Like expanding a window by moving the mouse to a window edge. For most other UIs like motif, that would just move the window and cause user fustration. So the last thing we need is to re-learn another UI. Wx resolves this by using the native underlining UI on that platform, such as MFC if it were a Windows application, so the end result is an application that really is using MFC but was programmed with wx.

Some problems with new UI is often, that it is incomplete, compared to some UI like MFC. Most UI, don't include networking functions, memory management, database functions, or advance graphic engines. Wx is very complete, with ODBC functions, and OpenGL routines. KICAD is an open source CAD software using wx, how amazing is that!

Overall, this book is a simple read, it is geared towards C/C++ programmers, and if you have any experience with other GUIs as MFC, OWL you will quickly excel in its application. You can also use a variety of other languages such as Python, Perl, Basic, Lua, Eiffel, Java, JavaScript, Ruby, Haskell and C#.

I don't really have too many cons against the book. Other than, its really a beginner to intermediate introduction to wx. If you're a wx expert, you can still benefit from the book, I expecially liked its multithreaded section.

Also what is not covered in the book, is macros in wx which contain really nice features that allow for dynamic classes to be defined on runtime and imported via dynamic libraries and make for some cool plugin technology, for those whom don't wish to make thier application open sourced, and yet, want users to extend the UI of their application, via plugins.

We didn't need documentation back then!

Ever been in that situation? A product has been in development, from the ground up for three to four years. There have been several sales and the product is overall regarded as rather successful. In fact, it grows much bigger than initially expected. An infrastructure forms around it, staffing demands grow, etc. etc. until at some point the company is big enough that an actual HR department is justified. Then, the core developer decides to move on and is off to greener pastures. Ouch.

It gets worse: He or she did in fact never bother to create any elaborate documentation of the architecture or any important design decisions. It's all in his head.

Well.

I overheard a similar description the other day. Interestingly, the speaker concluded his story with the following statement: "We did not need to create documentation for anything back then." Nodding, chuckling ... then the conversation moved on to other subjects.

I could not forget about this though. On the one hand, I do empathize with the spirit: You're having a high tech startup, so you work hard, really hard to get out that product. You have only one or two people hacking away on the code. You're exploring new territory and have to hurry, because the competition could enter your market any moment. You really a) have no time for documenting, b) see no reason, because the application is far from complex at that point, and finally c) only need a minimum of documentation simply because there is not a large team involved and thus pretty few things to be communicated. No time for breaks, because you and your team are busy inventing the future and selling the half-ready program to cash-wielding prospects who would prefer to have the final result tomorrow. It's a pretty exciting environment.

Not creating effective documentation in that early stage of a product is a horrible mistake.

Here are just some reasons for this:

  • As more and more requirements are revealed software tends to gain and not lose complexity.
  • The software (or rather, the code base) will end up being in use far longer than the original developers could possibly anticipate.
  • Teams will grow, requiring a great information overhead. It can be very painful process, trying to discover the existing knowledge about architecture, design or features.
  • People will move on. They may move within the company or sign on somewhere else. Either way, the transition can be quite slow and inefficient. If the former main developer is suddenly busy running the company he won't have much time explaining database table structures.
  • The early knowledge may well be core knowledge, if the early development focused on the most important features of the application.

There is of course no easy answer, because some of those earlier objections may well appear quite valid. For some time anyway. Then, you better have a plan on how to transition smoothly to a good documentation process. Otherwise you might just find yourself in an unlucky scenario five years down the road.

Choose the Right Tool for the job

Over the years, I've worked with a number of systems which aggregate data in some way. These have included simple RSS aggregators, the importation of multiple XML formats, and even interacting with a multiple of bug tracking systems. Regardless of the domain, there is a simple concept here: There are a particular set of actions we wish to perform on the data, but quite often the data sources have a variety of data structures.

For some reason, most people immediately jump to the "simple" solution of building a inheritance heirarchy, each with a distinct class/structure beneath it to a specific data structure. This can work fine for quite a few situations and ends up being quite elegant in patterns such as the Data Access Object and others where you can completely encapsulate the data structure and simply forget about it. Unfortunately, this doesn't work in all scenarios.

For example, I'm involved in a large scale Java system where we are retriving XML data structures from a series of different sources (think aggregation). When we started there were twelve different sources in two different formats and the solution looked simple, we would simply import each of the structures and be done with it.

Since I've been bitten by this before, I proposed a different solution. Instead of doing the import in a single step, we would use a Two-Step Pattern to first convert each data structure into our custom structure and simply import that. We've been able to implement this by building a single importer class and creating a new XML-to-XML XSL transform for each new data source.

Just in time too, within 2 months, we were up to 7 different formats from 237 different sources...

Pave the cowpath

At my alma mater, Ball State University, there is a dirt walkway affectionately known as the cowpath. It is a makeshift shortcut from one of the dorms (er, residence halls) to classrooms on the other end of campus. It emerged out of need and student's tendency to take the shortest line between two points. The cowpath has existed for decades, and unless something has changed in the last five years, it remains a dirt trodden path.

What does any of this have to do with producing and managing software? Put simply, when we observe people wearing a path that we didn't anticipate, like when they use our software in interesting or peculiar ways, we have a few options:

  1. Slap the user's wrist and tell him not to mickey with the software
  2. Analyze if the software's user interface created some confusion
  3. Observe the user closely to understand his motivation

If you do #2 and #3 you will most likely choose to pave the cowpath instead of discouraging the user from doing what he wants to do. While I wouldn't advise retrofitting a spreadsheet into a flight simulator, developers and project managers should keep an open mind about creative ways that people repurpose software. A practical example is the Friendster software product. From presentation notes given by Danah Boyd to the Supernova Conference:

What was successful about Friendster had nothing to do with its original purpose or design [dating]. Instead, users saw it as a flexible artifact that they could repurpose to reflect their social practices. As i learned how people embedded Friendster into their daily lives, i was fascinated by how it manifested itself as so many different tools to so many different people. Some saw it as an information gathering tool, allowing them to learn about friends and strangers. Others saw it as a performance tool and a venting site. It was also used as a gaming device, a distribution channel for the drug dealer, an anti-depressant for the voyeur, a popularity contest. Many also saw it as a cultural artifact necessary for all water cooler discussions.

At first Friendster resisted the use cases they didn't ordain, but gradually they saw value in what their user base wanted from the service. They were fortunate to have a flexible system, which helps. They revised their software in minor ways (pave the cowpath), but mostly they just needed to get out of the way.

The next time your users surprise you with the way they (mis) use your software, consider if the possibility that the user knows something you don't. As a consequence you may tap into new markets for your software, and at the very least, by adapting your software to the needs of the user you will make their experience more pleasant.

Ruby for the PHP Programmer ...

This will be a series of my findings in the syntax and language of Ruby from a PHP perspective.

Displaying and formatting output is one of the first things you need to know when learning a new language.

PHP:

echo Look it up at PHP.net
echo value [,values];
This is not a function, so ( ) is not needed. It is a language construct. Hmm, something I just learned. it will concat the variable for you and display. This might come in handy, sometimes is a pain to always do print $var1 . " " . $var2; Sometimes those periods are easy to forget!

Example:

$first = "Nola";
$last = "Stowe";
echo $first, ' ', $last, "<br>";

print Look it up at PHP.net
print value;
Also not a function but a language construct, so () not needed here as well.

Example:

$first = "Nola";
$last = "Stowe";
print $first." ". $last."<br>";
// or
print "$first $last <br>"";

results in:
Nola Stowe

For more on the differences of print and echo, read: http://www.faqts.com/knowledge_base/view.phtml/aid/1/fid/40

In most cases, I usually use print.

Also availble in php, but I never rarely use:
printf (string format, [, mixed args]); uses a formatting string
sprintf (formats as printf, but reutrns a string rather than printing)
vsprintf (like sprintf, but accepts an array of values instead of a variable number)
vprintf (like printf, but accepts an array of values instead of a variable number)

Ruby:
(which BTW, does not require ; at end of line, local vars don't have $ those are reserved for globals)


first = "Nola"
last = "Stowe"


print first, ' ', last, "<br>"

prints contents of variable test followed by test2

results in:
Nola Stowe

However, it appears some special variables (lookie! a $!!! that means they are global)


$, = " " #displayed between variables in print
$\ = "<br>" #displayed at end of the line

Will set some defaults for the print statement, so once those are set, all you need to do is:


print first,last

To get the same result. Cool, huh?

Also in Ruby I found puts, and putc. I need to do some more investigation on those. Perhaps a reader can shed some light?

So you can see, PHP's echo is most like Ruby's print. That should help us die hard php programmers who normally use print exclusively.
Also in Ruby, which seem to work like the php versions:
printf
sprintf

Introducing Gavin

Hello everyone, and welcome to CodeSnipers. I'd like to start by saying how excited I am to be a part of this, and by thanking Keith for setting the whole thing up. I think this is going to be a lot of fun, I know I'm going to learn a lot by participating in the discussions and reading the posts of all the contributors. I already feel like I'm learning, and all I've done is a quick tour of the blog roll.

My name is Gavin Bowman, and I'm a software developer based in the north of England. While I was heavily into computing at an early age, it was mostly for the games, I didn't really do anything productive with them until I started work. My first job was a general trainee tech support role, but with the help of some great people, a flexible environment, and a lot of personal study time, I was able to spend most of my time catching and incubating the coding bug. When it was time to move on, an offer of some contract work on the side came as a happy coincidence, and without really thinking about it I'd gone it alone. Somehow I've managed to keep myself afloat ever since.

I tried forming a consulting/services company with a long term colleague in 2000, but it gradually morphed into a Micro ISV, and we have spent most of the last 3 years developing and selling our products online. Despite being a programmer first and foremost, I have to spend a large amount of my time on marketing, or trying to learn how to do marketing, and often need to dabble in web design and scripting. My early development adventures were in VB and VBA, but these days I work almost exclusively in C#. You probably shouldn't expect, or wish for, any malloc or vi tips from my posts.

What I think my posts will focus on is the Micro ISV life, occasional C#, and possibly my learning experiences with various web technologies and marketing techniques. I can't wait, and I hope you find something here that helps or entertains.

Whois Rusty Divine?

One night while laying quietly in the top bunk at a medical testing facility and using a pen light to read the university's course manual, my aspirations to be a mechanical engineer like my half brother came to an end. If it wasn't for Dynamics, which I did finally pass after three attempts, but which I'm sure hexed my soul, I may be a mechanical engineer today.

And thank God I'm not, because I can't write one line of code without breaking the compile! Imagine the masses of innocent lives that would have been snuffed out by my bridges, cat walks, and handrails (in that order, as my career spiraled into oblivion) if I hadn't given up on that fateful night! It may be your life I saved.

So what did I discover in that course book? It actually was about as far away from computers as I could get (unintentionally; I have been a computer hobbyist since before puberty). I read about Geology. Man, after spending years in a stuffy engineering department where some of my professors didn't even have necks, the thought of hiking around mountains, camping, and hitting rocks with a steel hammer really appealed to me.

Maybe it was the Prozac talking; or maybe I was low on blood after the 43rd draw of the day, but switching majors turned out to be one of my better life decisions. I met my future wife in the Geology department and have followed her career to our current rookery in Seattle where we live with our two Greyhounds.

My first job after college; well, the week I spent mucking out a glorified stomach deemed "The Digester" for $7/hr that broke down salad dressing waste water in a sandy slurry of bacteria doesn't count (in fact, I try hard to repress that memory...especially the part about the dead rats..); was at an environmental engineering company. I quickly transitioned into the "Database Guy" role, and later the "ASP Web Guy". After that, I bought about 200 pounds of computer books and have spent evenings and weekends constructing electronic fortresses and exploring new territories.

I've worked at environmental consulting companies ever since, and have specialized in ASP.Net with SQL Server. I wear a lot of hats though, from project management, analysis, development, through completion.

I love working in consulting because every few months I get to start a new project where I learn a client's business process and then work to automate and improve it.

I also enjoy reading, writing and arithmitic (expect dynamic arithmitic) and I look forward to sharing my experiences in the consulting world and learning about your reactions and your world views.

<?="Nola's Introduction"?>

Greetings fellow developers! I hope to use this blog to share some things I’ve learned and generate some good discussion. Feel free to point out my flaws and add your thoughts. Although I am stubborn, I do admit when I am wrong… if you succeed in convincing me that is! ;)

Where I Started
I got my first computer when an Uncle gave me his TRS-80 and we hooked it up to a small tv. We plugged in cartridges and played games. In the summer I turned 13, I found a BASIC programming book, learned how to do simple programs, save files to cassette tape and use the 6 inch wide thermal paper printer. I made the screen flash random colors and make math games for my siblings. That was the end of my summers playing outside.

From there, I progressed to a Tandy 1000sx. I discovered Print Shop, and spent hours making big blocky graphics. In fact, I used the printer so much, one day it started smoking! Luckily, it was 1 month before the warranty was up, and I hauled it back to Radio Shack. When I got a color monitor and Photo Shop Deluxe, I was ecstatic. I don’t think I slept for a week. I could make my own fonts and produce fairly crisp graphics. I bought some more Basic programming books and made more simple applications.

Later on, I dabbled in C/C++ and VB. I discovered online BBSs when I was 16. I saw all the shareware available and was very disheartened. Surely nobody wanted anything I could ever write. I still programmed but didn’t have any goals of making anything grandiose applications. I remember a friend of mine going to college around 1996 and asked if I would like a “Homepage.” What’s that I say? He said a page about you for the Internet! I was like, ummm..no. Not having a clue about the Internet. When I got on the Intranet myself about age 18 using my Dads university account, I found out for myself what it was all about using Lynx, Zmodem downloads and gopher!

I thought I would like to do Desktop Publishing, so I took a class then went out to find a job. Nobody wanted to hire some crazy girl marching in saying she knew how to do DTP. So I went to college and majored in Computer Information Systems and minored in Design Studio. I better understood programming languages now, design concepts and databases and found that I was good in web development, since it can include programming AND design. I found my niche in the programming world!

Where I am Now
I work for an international engineering firm, doing mainly intranet programming with PHP and MySQL. On the side, I do contract work for Casey Software on various web development projects and some projects on my own. I have a dedicated webserver where I manage around 14 sites for friends, family and a few businesses. I am interested in OS projects like DotProject, SugarCRM, Smarty, Gallery and plan on being involved in new development where I can assist.

Where I want to go
Never content to just know what I know, I am always learning something and trying new things. I dabble in .NET from time to time, play with VB and Java. I spend most of my time with things like perl (which I know some, but not very well), python and ruby. One of my quests is to write a php class worth of being includedin PEAR.

So thanks "Al-Gore" for "creating" the Internet… it pays the bills now :)

Me in an Austin Powersesque Nutshell [Ben]

I can't help but think of fellow-Canadian Mike Myers curled up on his back swivelling his hands saying "this is me in a nutshell." That is appropriate for a computer programmer stuck inside a (C?) shell, with all the communication problems that entails. My writing is not my strength, I am an observer above all, something signified in my mediocre Anthropology pursuits at the University of Toronto (1988-91), while I pulled my average up with the Computer Science half of my double major. Having an English teacher for a mom, I can put sentences together and spot spelling and grammar errors (especially in other peoples' writing), but that is altogether different from writing something that is a compelling read.

C++, Windows, and MicroISV are going to be regular subjects here. Hopefully I can be of some service, but I expect to learn a lot in the process.

Although I grew up and schooled in Canada, I was born to U.S. parents and when I graduated in 1991 I switched over to the U.S. and started working in Virginia where I have been except for a 15 month stint in the Caribbean. I started firstobject.com in 1999 and started selling a small source code product on the side in 2001. That's me in a very small nutshell, I look forward to introducing myself more through the course of writing articles for this site.