Zugg Software :: View topic

Posted: Sat May 13, 2006 6:43 am

Zugg, sounds like you were in "the zone" today. And a little bit of luck doesn't hurt either. I'm looking forward to this tool since there can be some really obscure things that we can't even identify much less resolve.

Hope you and Chiara enjoyed your bit of downtime.

Hasta manana.

Posted: Sun May 14, 2006 2:07 am

Well, today was almost the opposite of yesterday. I feel like I hardly got anything done.

My job today was to get the Preferences cleaned up and get them loading and saving properly from packages. I put this off because I never quite decided how to handle the fact that any package can have it's own preferences. We had a post about this over in the CMUD forum a while back, and something like PhotoShop "layers" was suggested. But the more I got into it, the more it just didn't feel right. It's just overly complicated.

What I'm considering now is just loading the preferences from the main character settings file, and then let other packages override stuff using the new %pref function in their startup event. This would be simple and straightforward for package users and wouldn't add complexity to the user interface. Besides, I think it should be rare to have packages changing the global preferences...to much of a chance to mess things up.

Part of this job was to go through and streamline the preferences. The preferences in zMUD are just way to complicated and intimidating. They have grown and grown over the years with a preference being added for just about everything. Some of those preferences no longer apply. For example, the new docking system will have a completely different set of options...the old "layout" preferences no longer apply. Any non-modal non-toolbar window always gets a taskbar icon so that you can't loose windows, so no more options for that. And a lot of the parser options, like <> and [] just don't appy to the new compiler. The old syntax checker it no longer used, and the new one will use "Styles" which I probably won't implement in the first beta. etc, etc.

I've never really liked the "tree view" of the preferences. When the tree gets collapsed, new users don't see a lot of the preference pages at all (there is even an option to control whether the tree is collapsed or not). The challenge is that there are so many different categories and sub-categories of options that I can't just put them all into a "tabbed" view, since there would be like 4 rows of tabs, and I hate dialogs like that even more than the tree view.

So, I got a bit sidetracked with the user interface for a while, trying different approaches. I finally came across something that I like. I posted a screenshot over in the CMUD Beta forum that you can look at. Basically there are two sets of tabs: A list of categories on the left selects the major preference category. Then, once a category is selected, a set of tab pages along the top selects from the "sub-category". This looks a lot nicer than the tree-view, especially with the theming support, and shouldn't overwhelm new users as much as the zMUD screen does.

I eliminated a lot of preferences that are no longer needed. I'm sure I probably accidentally got rid of something that someone needs, but don't worry...all of the options are still in the code (and accessible via %pref), just not necessarily shown in the Prefs dialog. So it will be trivial to put something back if I need to.

When I was working on the preferences a few months ago, I got this idea to make it totally database driven. I'd have a database of preferences with each record giving the preference name (for the %pref function), the data type, the category and sub-category, and it's position on the screen. With that information, I could build the preference screens "on the fly" using the database information. Yeah, it sounded good back then.

Unfortunately, many of the preference screens are too specialized to use this method. It's good for a plain list of checkboxes, but not for anything more complicated. Also, the speed of bringing up the auto-generated screens was too slow. It's faster to load a form or frame from a Delphi resource than it is to create a bunch of checkbox controls on-the-fly.

So today I abandoned the auto-generated preference screens and went back to my own. Each category screen is a separate Frame in Delphi. The frame is created and loaded when you select a category from the tabs on the left. In zMUD, I had a separate dialog for each *sub* category screen...that was about 30 dialogs! Now in CMUD I only have 11 dialogs, one for each major category. And with just 11 screens, no fancy database is really needed.

I still use the main preference database for the %pref command to associate a preference "name" with it's record number. This record number is what I use to store the preference value in the character settings file (in the package). So this database is still useful, but I no longer use the category and sub-category fields.

It's taken all day just to do the user interface stuff. I still don't have the actual preference values saving and restoring from the character settings. Hopefully that will be an easy task to finish on Monday.

But today illustrated one of my problems...I sometimes get too involved in little picky details, like exactly how a particular screen should look. And graphics and User Interface stuff can take a *lot* of time if you aren't careful. I'd make a lousy graphics designer since I'd take waaay to long to finish anything...I'd always be tweaking the details to try and make it "perfect", which isn't really possible since everyone has their own opinions of what they like and dislike. I'm sure there will probably be some people who hate the new preferences screen, even though I really like it myself.

Oh well, not every day can be like yesterday. In fact, days like yesterday are very rare.

Tomorrow is our day off, so I won't post again till Monday. Happy Mother's Day (call your mother!)

Wizard Joined: 25 Mar 2003 Posts: 1113 Location: USA

As someone who has written a lot of thread code for various purposes (network communications, serial data acquisition, GUI handling, background processing, etc), I feel your pain. I haven't worked with Delphi specifically, but I've used threads in about a half-dozen languages and with different toolkits. There are some basic concepts that a developer needs to get down pat before he can handle all the most advanced code, and building on them from examples provided isn't all it's cracked up to be. If you ever need help working out some tricky bit of logic or a race condition, I'd be glad to give what advice I can. (Hint: put a couple mutexes and some access methods in any data class you need to access between two or more threads.)

Magician Joined: 29 Nov 2005 Posts: 482

Posted: Sun May 14, 2006 6:01 am

True, but the improved GUI is actually one of the things that many people are looking forward to. After all, zMUD was already functional. The challenge of CMUD is that it needs to be better than zMUD. Different people will be looking for different things in CMUD. Some will love the much faster scripting speed, some will like the easier scripting and removal of various zMUD "kludges". Some will love the shared package library. Some will love the new graphics and new interface features.

As I've said before, I only get one chance to make a good "first impression" with CMUD. It's not often that I release a new product, and the first impression of a new product is important for the word-of-mouth that I've always depended upon.

So, I believe that it all goes together. I need to work on both functionality *and* useability and interface. It's the combination of both that marks high quality software (well, along with good documentation and support, but that will come later). Working on user interface issues also give me a break from the hard-core coding, so it's a good balance to have. If I hadn't spent time working on the preferences interface, then I would not have bothered cleaning up the various old settings that are no longer needed. And it helped focus my mind on what I really needed to do to store the preferences. Otherwise I would have just spent the day coding some fancy preference "layers" and inheritence features instead of realizing that I should just keep it simple.

That's the drawback with not doing a full design in advance. I tend to design the major features and ideas and then code the rest as I go. It's not the most professional way of programming, but it allows me to encorporate new ideas more quickly. It's also more fun Smile

Wizard Joined: 25 Mar 2003 Posts: 1113 Location: USA

I'll agree with the rough-design-then-play-it-by-ear programming methodology being more fun. I use that strategy at work, too. Sometimes it's nice to have the freedom to do just about anything you want. Other times it would be nice to have a -little- bit of structure.

Posted: Tue May 16, 2006 4:11 am

Man, what a day. I have such a huge headache.

OK, today I started working on a bunch of loose ends. I'm done with the major feature work now and just have those "2 weeks of misc loose ends" that I've talked about in the ETA thread. I went through my list and re-prioritized and removed items that weren't really important for the beta. Then I just started going down the list one by one.

For example, there is a new "flyout" quick-settings panel. It lets you view your settings quickly as suggested by mr_Kent over in the CMUD forum (his "toolbox" panel). I had gotten the hard part of this working a few weeks ago (the tree-view), and today I just needed to finish it by adding the fields for the name and value of the selected setting, and the button for creating new aliases, new variables, etc. This button will eventually call a new "wizard" for quick settings creation, but right now it just adds a record to the tree and lets you fill in the name and value in the fields below.

This should have been trivial. It's all code I've written before in the main settings editor. It was just a matter of copying/pasting code from the main settings editor into the flyout settings editor. But it led to problem after problem...

First, when the cursor was in the Name field, pressing Tab would not move it to the Value field. I couldn't believe this. How in hell could the tab key for moving between fields on a form stop working? This is part of Windows. It can't just stop working like this. Especially when I copied the Name and Value fields from the main settings editor where it works just fine. In fact, it works everywhere else in CMUD, but just not with the fields on the flyout window.

I deleted the fields and recreated them (instead of copying them from the main settings editor). No change. Man, I was tearing my hair out on this one. I took a break and came back to look at it fresh. Still couldn't figure it out. Finally, I started doing some *really tedious* low level Windows message debugging. This is a pain because it's so hard to track just the message you want in Delphi. I wanted to trace the KEYDOWN event.

After a long debug session, I finally found the problem. The flyout settings is a Delphi "frame", not a normal "form" like the main settings editor. When processing keystrokes, Delphi checks the Parent Form of a control to see if it intercepts keystrokes. Since the flyout panel is a frame and is docked to the main window, these keystrokes get sent to the main window. And in the main window code, I had some old stuff that would intercept keystrokes and force them to go to the command line.

This was left over from a problem in zMUD with the scrollbars. The scrollbars in zMUD could receive keyboard focus, taking focus away from the command line. So there were some code tricks to force these keystrokes to go to the command line. These scrollbars have been changed in CMUD and no longer take focus away. But the code to intercept keystroke messages was still there.

So the Tab key was getting sent to the command line!! This would only happen with other "edit" controls in frames docked to the main CMUD window. And this is the first time I've tested a docked frame with an edit control.

What a pain that was. OK, so I thought I was done, right? No such luck. I implemented the "New" button on the flyout form for creating a new alias, variable, etc. But something was causing the database to get corrupted sometimes. It was wierd and hard to reproduce. I finally got a consistent procedure to reproduce the crash at CMUD exit time, but all I could tell was that when it was trying to free the in-memory database, some pointer was messed up. And the FastMM memory manager wasn't helping me track down the problem, so it didn't seem to be a memory leak or nil pointer or anything like that.

This one took me FIVE hours to track down. And it shouldn't have taken this long. As you might have guessed, the problem was caused by the new background Thread that is doing the database saving. I should have realized that an intermittent bug that was hard to reproduce and related to the database was caused by this. After all, I know how annoying threads can be. I even took a dinner break in the middle to try and relax a bit. But the background thread still didn't occur to me for a while.

Remember when I implemented the thread and I had to add some code to "fix" the current ActiveBuffer to make it thread safe? Well, my code to do this wasn't quite working right. It was working for the main in-memory data set. But I have several other datasets that "point" to the same physical data. This is a feature of the kdmMemTable components which allow you to "attach" other data sets to the same physical database records. It allows you to have multiple cursors and multiple indexes without duplicating data. It's a great feature and is used a lot in CMUD (I have about 8 datasets attached to the in-memory data).

Each of these "attached" datasets has it's own Active Buffer. The code that I wrote to "fix" the ActiveBuffer was supposed to loop through all attached tables. However, it was checking a flag to see if any datasets were attached, and it turns out that this flag is cleared temporarily during the Update loop. Since this was always false, it was only fixing the primary dataset, and not any of the attached datasets.

Well, the main settings editor uses the primary dataset. But the flyout settings screen uses an attached dataset. So the ActiveBuffer of the attached dataset wasn't being fixed, causing it to get corrupted.

Once I fixed the Update thread to always fix the attached datasets regardless of the attached flag setting, then it worked fine.

These were Really frustrating bugs. So, something that was supposed to take only an hour, ended up taking ALL DAY. Sigh. And of course this happened on a Monday, so now I'm already brain-fried again, with the entire week still left ahead of me. I only hope that tomorrow things are easier.

Wizard Joined: 10 Oct 2000 Posts: 1551 Location: Australia

Yeah threads can be the most annoying things in the world. Sometimes they are arguably one of the most useful things too, but it gets really hard to work out the synchronization and deadlocks and all that jazz. Hopefully that's the last of the issues you have with the saver thread!

Some of the things are so hard to test for too, like what happens if while you are doing a save_to_disk the main thread does an insert_into_table... can be really tricky to sort out.

Posted: Tue May 16, 2006 5:00 am

What's nice about the kbmMemTable is that it has locking support built in. That's what made it relatively easy to use in the Updater thread. Because of the locking mechanisms, there is no way for the main thread do perform an insert while the update thread is busy. Also, only the update thread performs any SQL *output*. The main application thread only works with the in-memory database and doesn't know about any external SQL souces. Only the updater thread has the SQL disk database open and performs the output. The updater thread locks a particular record while the SQL transaction is performed to ensure that the in-memory data can't get changed in the middle of writing it to disk. So it's impossible to output a partial record to the SQL database.

The problem with the ActiveBuffer updates was that the kbmMemTable author didn't use the Lock mechanism during one of his routines that accesses the current record, because the ActiveBuffer is a *copy* of a record. I think he forgot that when versioning is enabled, even the copy of the record shares the same database pointers to the previous record versions. But this is the only crack I've found in his locking code, so hopefully that will be the end of thead issues.

If he didn't already have the locking stuff implemented, I would have never attempted to use it in a thread.

Posted: Tue May 16, 2006 5:49 am

Take heart Zugg.. tomorrow will be easier. We all appreciate the painstaking effort you take to delivering a high quality product.

Posted: Wed May 17, 2006 3:32 am

Today I continued working on the list of "loose ends". I purposely worked on stuff that didn't require a lot of brains since I was still tired from yesterday.

The first task was to finish the new Command/Function help window. This replaces the old Command and Function "wizards" and is the new screen you get when you press F1 on the command line or in the script editor. The new window is another dockable window. By default, it is docked to the right edge of the CMUD window and set to "autohide" to make it a flyout window. Pressing F1 opens this window and sets it to display the help for the command or function under the cursor.

For now it just has the syntax help, similar to the old Command/Function wizard, and description of each parameter. It will eventually tie into the new help system, but I'm not going to put the new help system in the first beta. This all went pretty smoothly. I had built the functionality a few months ago, but it still was using the old DevExpress docking system instead of the new AutomatedQA docking system.

Next, I started doing some dialog conversions for the mapper...

There are lots of dialogs and windows that need to be converted for CMUD. CMUD uses the zApp components, which are based upon the commercial Developer Express components. In particular, CMUD uses the DevExpress "ExpressBars" components for the menus and toolbars. Many of the zMUD windows, especially in the Mapper, used a menu component called Toolbar2000 (and the TBX enhancement). It causes problems to have two different toolbar systems in the same program, so I'm going through and converting forms to use the DevExpress components and toolbar system. Also, converting the forms to use the zApp components is what makes the forms "theme aware".

The Mapper was the last module from zMUD that still had all of the Toolbar2000/TBX stuff. Converting this to ExpressBars is very tedious. Both companies provide tools for converting *from* default Delphi menus, but once it's in Toolbar2000 format, there is no way to convert it back, and no way to convert automatically to ExpressBars.

Part of this is good. A lot of zMUD code, including the mapper, was written before "Actions" became such a big part of Delphi. An "Action" is an object that you can tie to toolbar buttons and menus. For example, if you want to make a toolbar button that makes text in an editor "Bold", you create a Bold Action. This Action has the name (Bold), icon, whether it's checked or not, whether it's enabled, whether it's visible, etc. And it contains the code that is executed when you run the Action. Once the Action is created, you then make your toolbar button and point it to the Action. Then you make your menu entry and point it to the same action. So now the button on the toolbar and the menu item are pointing to the same Action, so they are in synch. If you set the Checked property of the Action, then the menu item gets a checkmark and the toolbar button looks like it is pressed.

This is a great way to encapsulate the code, and separate it from the user interface. I use Actions in my programs all the time now, and the ExpressBars components really work best when using Actions. But none of the old zMUD code using Toolbar2000 was written using Actions. So, for each button or menu item, I had to first create an Action for it. Then, once all the actions were created, I could then go through and add the actual toolbar buttons and menu items to the DevExpress system.

The mapper, along with the Spreadsheet view dialog, had a *lot* of menu items. This has to be done, not only for main menus and toolbars, but also for any right-click context popup menus. It took quite a while to do all of this. In the process, I noticed some problem in the Mapper, but I'm not going to do anything about this right now. I'll wait until I start converting the mapper from ADO to SQL later this summer to tweak the mapper. For now, I've gotten rid of the Toolbar2000 system, converted most of the forms to use the DevExpress components, and made the mapper window dockable using the new docking system.

One little thing that I added to mapper that was really quick and easy is a new Zone combobox. In zMUD there is a label above the main map view that tells you what zone you are in. In CMUD this label is replaced with a ComboBox that still shows the zone name, but you can click on it to display a list of zones to switch to. This provides an alternate way to switch zones that's a bit easier when the zone panel is hidden. And when the mapper is docked on the main MUD display, it's useful to hide the zone/favorites panel, which is now the default, so that you can see all of your map.

So, it was time consuming, but it all went pretty smoothly. I'm getting the hang of the new docking system and it's quite easy to work with. I'm very happy with it. Right now you can manually save and load layouts. For example, there is a default layout in the CMUD.XLY file (it's an XML format file) that determines how the windows are initially docked and laid out (with the quick settings window and command/function help windows auto-hidden as tabs on the right side, and the mapper and status windows hidden completely to start with). It's trivial to save your own layout once you dock the windows how you want. It saves not only the docked positions, but also remembers the size and position of the windows the last time they were floating. It's quite nice.

What I haven't done yet is figured out quite how to handle child windows, since each session can have multiple child capture windows. The AQ docking system is set up to have the possible docked panels defined at design time. Somehow I need to add these panels at runtime. I've gotten some sample code and need to try it out. I think I will make child windows a new "setting" type so that you can set their properties in the settings editor. It actually makes sense to treat a child window like a class or package, since zMUD normally loads a *.MUD file associated with the child window. Anyway, that's something else that is still on the high priority list.

Something else on the list is saving/restoring the toolbar settings. With the DevExpress toolbar system, end-users can completely customize their menus and toolbars. CMUD takes advantage of this and will create toolbar "items" corresponding to your buttons and status-bar items. Then you can drag these items to any toolbar that you want (or create new toolbars, make them floating, whatever).

The trick is saving and restoring these settings. CMUD has two kinds of toolbars: the main toolbars and menus associated with the main window, and then it has toolbars/menus associated with the specific MUD window. For example, the command line is now a toolbar that is part of the MUD window. DevExpress isn't set up to save/load toolbars of this complexity. So I need to look at their existing save/load code and adapt it for CMUD. Then I'll figure out how to store it. I need to store a default global layout, but then also store the MUD-specific layout somewhere in the settings file. Or, I might make it a separate file like the docking system uses.

Those are the two biggest loose ends that I've got right now. The rest of the work is just more dialog conversion and then a bit more testing on a live MUD. I think the end of the month is actually starting to look do-able, but I probably should say that Wink

Posted: Wed May 17, 2006 6:14 pm

Keep the updates coming Zugg...

I know I for one will greatly appreciate that combo-box to switch zone in the mapper. The Action stuff sounds alot like the event model in Java (soon to be in CMUD) and is certainly the right way to go. Just makes for cleaner more maintainable code.

Can't offer much comment on the toolbar savings other than I'm sure you'll sort it all out. As for the child capture windows, should you treat those like standard windows and capture them in the layout file? I'm not sure the advantage of treating them like a class. I haven't done it but i can easily imagine someone wanting apply packages to the child windows that are completely independent from the main window. It also allows, if you're ever inclined to do to make the entire app multithreaded, to have each window have it's own thread. I'm sure you're considering much more than I can think of right now, but just something a bit more for you to chew on.

Posted: Wed May 17, 2006 6:24 pm

A quick aside: I was browsing the Joel On Software site ( http://www.joelonsoftware.com ) today because someone told me that there was a reference to zApp that I needed to respond to. While I was there I took a quick look at the latest articles and found one that really hit home: http://www.joelonsoftware.com/articles/DevelopmentAbstraction.html

Gee, no wonder I have so much trouble. Chiara and I are doing *everything* ourselves. Yes, I worry about our air conditioner and I worry about our network and I had to set up Subversion all by myself (well, with a bit of help from all you people in these forums). Chiara handles the phone calls, the food, the house, and pretty much everything else that doesn't involve my computer. We don't have time for marketing or sales, and even documentation takes a back seat. I guess I should be happy that we are still in business at all after 10 years!

Too bad his article doesn't mention a solution. He doesn't mention what magic "management company" a poor programmer like myself can sign up with to instantly sell 10 times more product. If I could be convinced that a bigger company could take over and help me sell more, then I might consider it. But what I really believe is that I'd just loose control over the product, and even though I'd be selling 10 times more, I still wouldn't see that increase personally since it would take so many other people with a cut of the profits. And customers would stop getting what they want and would no longer be able to influence the design because there would be this whole layer of "customer support" (probably outsourced) shielding the customers from me so that I wouldn't get "distracted" from my programming.

I don't want to be big. I *like* directly interacting with customers. OK, so I don't like having to be my own sysadmin, spending a whole day installing updates and new virus software instead of programming. And it would be nice to have a talented graphics artist as part of the "company" to make stuff look better so that I didn't have to spend time doing it myself. But mostly I like our small two-person business. I guess that means Zugg Software will never be "successful". We'll just keep doing what we've been doing and keeping our customers happy, and maybe in another 10 years I'll look back and wonder what it really means to be "successful".

Magician Joined: 29 Nov 2005 Posts: 482

As someone who runs his own business zugg. There is always a middle ground. I know with my business i ended up with all kinds of solutions. As an oncall repair/custom web solutions company, I have had to create positions to help myself from being so busy i couldnt even live life. This is what they call "Quality of Life". Every job, whether your own company or a 9-5 job, needs a "Quality of Life". That in and of itself is worth something.

What i did was took a few people around that i could trust, some family some employees. Put them in key positions where i knew they would be best suited and allowed them to take part of the burden off while keeping the things that meant the most to me. I am still involved with every facet of my company but at this point its not all consuming either. I have people i can trust in the middle ground. The other good feature of doing it this way besides the trust factor is its usually reasonably inexpensive. Almost like internships used to be when people still did them. I still do 2 internships a year, course now i have the time to handle it.

What i would suggest of you in every area of your business. Figure out where YOU would feel comfortable stepping back a bit and letting someone else handle. When you figure that out then in turn figure out if its a possiblity with people you currently have and trust. Was part of my suggestion about having a "PR Rep". This allows good word to get out, bad word to be handled properly without inflaming the person more and most importantly takes a burden off of your back that while you might want to hear about it, your attention isnt fully required either. Granted its just an example every business has their own model.

I have signed on a total of 4 people besides myself, but you would be amazed the difference in how i feel. I am no longer 24/7 working. The customers still get the same personal touch i give them as i refuse to remove myself from the custom built pc aspect of my business and i refuse to remove myself from the oncall support aspect. So im still busy taking calls, building pcs/web apps and providing personal support. However many of the "Administrative" functions are handled by those 4 people. Routing calls, Assigning Jobs, Backend paperwork, Filing and payroll etc. While i oversee them all, I dont need to be worried about it and am sure that if a problem arises ill be the first to hear about it. it frees up a big portion of ME for other things :) .... Like playing with ZMUD and posting here which i have been doing for the last 8 1/2 years. Post count fool you not :P Sniff someone made me change my information when they put in that store system including my forum account :P i even had lost my zmud beta forums access when that happened. ROFL.

Wizard Joined: 10 Oct 2000 Posts: 1551 Location: Australia

Just on the topic of the mapper, what I would really like to see is the 'room properties' window as a flyout window attached to the bottom of the mapper, and then the ability to dock the mapper to the main window and still have the room properties visible or not. I find when I'm mapping a new area I need to keep the room properties window open to add parameters like 'door is locked' etc to each room and it's always annoyed me that I haven't been able to dock the window.

And yeah, layouts, toolbars, etc should definately be saved in the package too if possible... I mean, we'll be using these toolbars for our buttons and guages too yes? So they will definately need to be in there somehow to support those custom packages distributed by MUD admins, etc. It would be really nice to be able to distribute a package which had the MUD logo, all related tool buttons, triggers, separate chat window, etc so that we can send down a single package and it becomes a 'total conversion' for the MUD.

So yeah that brings up another point - is there going to be a way to store images inside a package so we can have custom icons on our buttons etc which also transfer over?

Site Admin Joined: 29 Sep 2000 Posts: 389 Location: USA

Posted: Thu May 18, 2006 12:08 am

Rainchild, I think I'll need to start a post over in the CMUD Beta forum about windows, toolbars, graphics and packages. That's all stuff for a later beta version, and I don't want to get too distracted. Also, I have *lots* of plans for the mapper and it's user interface. Having gotten a break from it for the last couple of years, I'm amazed at how poor the interface is now that I'm looking at it again. So yes, lots will change. But not today.

edb6377: a couple of things. First is that if you have a previous forum name/info, I'm sure we can get you reconnected with it. I assume you already emailed me about this, but if not, send me a note. You shouldn't have had to create a whole new account unless something was really messed up. And since we don't delete anything, your old forum account is probably still around.

But back to today's topic. Every other Wednesday is our "chore" day. We take Sundays off and totaly relax...watch movies, read, play video games, etc. But every other Wednesday, Chiara and I do other jobs that just need to get done somehow. Whether it's yard work or cleaning, or tax stuff, or even learning more about running a business. Today I had various house chores to do, but when I was done I came back to this Joel article that I already mentioned. It led me to a book called "Micro-ISV: From Vision to Reality" by Bob Walsh. Went out and got the book at the local book store and have been reading through it.

We've been in business for almost 10 years now and have learned a lot, and most of what I've learned is already in the book. Too bad this book didn't exist 10 years ago! If you are thinking of starting your own one-person software company, this book is a must read. Most of it is stuff I already knew about, but I'm picking up some good new info, especially since the book is very up-to-date.

But edb6377, one of the problems I have with hiring other people right now is simply money. Hopefully CMUD sales will take care of that in the coming years. For now I'm stuck with the hard facts of life and Chiara and I have to handle the work ourselves. Fortunately, Chiara handles a *lot* of the stuff that I don't like to do and don't have time for. Internships are an interesting idea and something I'll probably consider in the future. Assuming I can find anyone who is interested.

Fortunately, we have been careful to build a business with very little overhead. We don't ship anything physical, and we don't do telephone support. When our business line rings, it's usually a credit-card fraud related problem. We don't do tech support over the phone (email and web based support is much better and less expensive for everyone).

I'd love to find a good "PR" person. I agree with what you've said about this, although I also believe direct interactions with customers is important. However, I've really been burned by this in the past. I hired someone who was considered one of the top Shareware marketing people and spent nearly $5000 and it was a complete waste of money. It's partly my fault since I didn't make my expectations as clear as I could have, and apparently $5000 just isn't enough money to spend, even though it was a lot for me. Honestly, I get better results just talking to people directly in these forums and getting their word of mouth.

If you have more concrete suggestions on how to find a PR person who is worth the money, drop me a private email. I'd love to find someone who played a lot of different MUDs and could promote CMUD, who posted on lots of different web boards and blogs, and stuff like that. But it's hard to determine what to pay for that and how to pay for it and to find someone I could trust.

Anyway, I have more reading to do. Taking a "chores" day to work on non-programming stuff is something I used to do once a week, but with all of the coding to finish the beta I've put it down to once every two weeks. But it's still an important part of maintaining the entire business...all of that work other than the actual coding.

Magician Joined: 29 Nov 2005 Posts: 482

many ways to do marketing. The more advanced the more expensive. but you can get the word out for far less by targetting groups and sites that cater towards what you are doing. I will email you a bit of information later that i have used myself to help with that.

Wizard Joined: 10 Oct 2000 Posts: 1551 Location: Australia

Just ordered that book from Amazon, so early June it should turn up on my doorstep... /pace /pace /pace

Posted: Thu May 18, 2006 4:40 am

Just finished reading most of the book. The last third consists of interviews with various Micro-ISVs, and I'll save that for casual reading later. As I mentioned, many things that are mentioned I've already been doing. And I liked the fact that when it came to marketing, he emphasizes things such as discussion forums and blogging and points out that traditional advertising is much too expensive for Micro-ISVs. That's what I've learned myself from the posts and blogs that I've made over the years.

One thing that I think I'll use with marketing CMUD is direct email. Later this summer when there is about one month left in the beta, I think I'm going to actually send out an email to everyone who has ever bought zMUD. This will be over 60,000 emails, and a huge percentage are going to bounce. And I'll need to follow the legal anti-spam requirements and set up a way to opt-out of any future emails and then keep track of the "active" email list. I probably also need to add an option to the online store to allow people buying the product to initially opt-out of the mailing list.

I originally wasn't going to do this. I didn't want to deal with all of the bounced messages. But it occured to me that there might be a lot of people out there who used zMUD a few years ago and got out of MUDding and might be reminded how fun MUDding was and come give it another try with CMUD. And sending the email a month before the public version would give people the opportunity to take advantage of any discounts they might be eligible for. Someone might actually go ahead and buy CMUD for the 50% discount even if they don't plan to use it right away, just to take advantage of the discount before the public version is released.

And I'd guess that most zMUD customers are interested in hearing about CMUD, so I doubt most people would consider the email to be spam. Most will probably welcome the announcement.

----
I also got a better introduction to David Allens "Get Things Done" (GTD) methodology. The introduction has raised my interest enough that I think I need to take more serious look. I'm pretty guilty with hundreds of items in my "Inbox" that I've never bothered to clear out. And I could certainly use a lot of improvement in my time management, especially during these stressful periods around release time. Of course, I'd have to budget the time for this. For now it's going to have to be something that I read more about in my off time or on my chore days.

----
All in all there are many links to various web sites that I'll need to go back and look at online. I'm more interested in the FogBugz bug tracking software from Joel, and there was a link to a flash demo creation tool that I want to look at. Also, he talks about the AutomatedQA Test Complete program for user interface testing, which is something I need to check out later this summer during the beta process. I already use several other AutomatedQA tools and I like their stuff. Even the author's own MasterList software for software scheduling might be interesting to try since it builds upon the simple Excel method from Joel that I'm already using.

As usual with "chore" days, I've learned some new stuff and left myself even more new stuff to look into. While I was at the book store I even looked through a couple of Ajax and "Ruby on Rails" books and can tell that someday, in my copious spare time, there is lots of exciting stuff to learn about.

But tomorrow...back to the programming slave pit.

Posted: Thu May 18, 2006 4:47 am

The article is quite insightful and frankly very true. It does make me wonder if such a magic company can exist; and even more importantly be a viable business model. There are several incubators that offer small subsets of these features.. But I know of none that encompass them all.

[Edit]This is what happens when you forget to hit submit until soo much later[Edit] Very Happy

Posted: Thu May 18, 2006 4:53 am

For bug tracking/help desk I would also recommend

Axosoft's Ontime - http://www.axosoft.com/

HelpSpot - http://www.userscape.com/products/helpspot/

These two combined with FogBuz are probably the best ones for microISVs. The guy that makes HelpSpot is a JoelOnSoftware denizen. Out of all 3, HelpSpot will probably integrate with this site the easiest.

Posted: Thu May 18, 2006 5:46 am

Do me a favor and count the bounces if you can ;)

Posted: Thu May 18, 2006 5:59 pm

bortaS, thanks for the links. The Axosoft solution doesn't look like it's intended for a linux server with PHP and MySQL. HelpSpot looks interesting and certainly has a similar set of features to FogBugz. I'll have to look into both of them when I get a chance. Hopefully I can spend some of my non-programming time looking into this, because I probably need *something* set up to handle the load of beta problems.

The mantis system that I set up for zMUD just isn't cutting it. I need something easier to use and faster and something that both Chiara and I can use. Chiara actually handles more support email, and a system that can process this email too would be ideal. And both FogBugZ and HelpSpot seem to support some nice integration with emails that could be very helpful.

Mainly I need to set something up that can handle all of the automatted crash report sending that I'm expecting to get in the early CMUD versions, and to be able to categorize them and organize them so I don't get too swamped.

Posted: Thu May 18, 2006 10:39 pm

FogBugz does support direct integration with Subversion, via hook scripts. Joel has a writeup on how to do that. His support people are pretty good. A couple others are:

Trac - http://www.edgewall.com/trac/
BaseCamp - http://www.basecamphq.com/

For crash reports check out this thread at the JoelOnSoftware forums:

http://discuss.joelonsoftware.com/default.asp?design.4.341656.8

As you can imagine, my browser bookmarks are huge. Cool

Plus I use Surfulator (another Joel forum microISV) to capture whole articles.