Thursday, June 4, 2009

Why Windows Mobile?

One of the questions I always get when I present the business concept for JSM Software is "why did you choose Windows Mobile?" Some are even less subtle and ask, "Why not develop for the iPhone instead?" They usually follow up with the story about how a friend of a friend made a lot of money selling some application on the iPhone.

Anecdotal evidence is not a good reason to start a company. I know a friend of a friend that won the lottery. It makes as much sense spending all my time, effort, and money trying to win the lottery as it does trying to make a lot of money creating applications for the iPhone. Both have the same anecdotal evidence.

I am trying to build a company, not win the lottery. I worked for a company that tried to "win the lottery". They came up with wonderful ideas that would change the entire company. None of it ever came to fruition. I want to emulate the conservative playbook of Woody Hayes, "three yards and a cloud of dust". Another description was "crunching, frontal assault of muscle against muscle, bone upon bone, will against will." Paraphrasing Woody Hayes, "a company will not succeed unless they regarded the challenge positively and would agree to pay the price that success demands of a team."

My business philosophy is simple: I want to grow a dedicated customer base by continually creating quality products. Sure I would like to make a lot of money. Everyone does. I will only focus on a market I know will provide adequate compensation for my effort.

One reviewer wrote me, "The iPhone market is so oversaturated with bad games, it's unbelievable." The vast number of cheep bad games put tremendous downward pricing pressure. Rick Storm wrote in his blog The Incredible App Store Hype, "The hype surrounding the iPhone App Store continues to persist." Rick Storm has an application is listed as #34 on the social networking chart. According to his blog that makes him a little over $20 per day. That is a little over $7000 per year if sales continue at that rate. That is not a lot of money to me.

Owen Goss documented his success with his game Dapple on his blog. Owen Gloss wrote about developing applications for the iPhone, "...I suspect we'll see fewer and fewer stories about people getting suddenly very rich." (The Numbers Post (aka Brutal Honesty)). Owen Gloss spent $32,000 developing Dapple and made a total of $535 in revenue. Playing the lottery sounds like it has a lot better odds than that. I fully agree with Owen Gloss, "My hope is that we'll start seeing more developers putting out quality titles in the hopes of gradually growing a sustainable business." Owen Gloss strongly implies developing games for the iPhone is not currently a sustainable business.

This reminds me of a stanza from one of my favorite poems, "The Gods of the Copybook Headings" by Rudyard Kipling:

With the Hopes that our World is built on they were utterly out of touch.
They denied that the Moon was Stilton; they denied she was even Dutch.
They denied that Wishes were Horses; they denied that a Pig had Wings.
So we worshiped the Gods of the Market Who promised these beautiful things.

I hear a lot of people worshiping the Gods of the Market in the form of praising the iPhone App Store.

Before deciding on Windows Mobile I did a lot of research. This is something it appears many jumping into the fray of developing software for mobile devices do not do. Denise Marcus, a friend of mine, always said, "Do the numbers." I have always been amazed at how many people fail to do the numbers.

What are the numbers? According to wmpoweruser.com (Windows Mobile hits 50 million lifetime sales ) Microsoft has sold over 50 million Windows Mobile devices. Of that, approximately 30 million are currently in use. These numbers make sense. According to Gartner, Microsoft has been selling over 4 million windows mobile devices every quarter since 2007 (Gartner Says Worldwide Smartphone Sales Reached Its Lowest Growth Rate). Most mobile contracts are two years long. 4 million per quarter times 4 quarters per year times 2 years equals 32 million. The 30 million number may be a bit low, but it is a reasonable starting point.

According to Entertainment Software Association 36% report they play games on a wireless device such as a cell phone or PDA (Essential Facts About the Computer and Video Game Industry). That means that 10.8 million Windows Mobile Users play games. The Entertainment Software Association also said that 7.6% of people who play games play role playing games. Conservatively the market for the type of games created by JSM Software is eight hundred and twenty-one thousand (821,000). If JSM Software reaches a one half of one percent market penetration, 0.5%, the sales projection is four thousand one hundred units (4,100).

My budget for creating a game is about $20,000. That means I need to make about $5 per unit sold. That does not include all the overhead costs in addition to the $20,000 budget. The interesting point is the average price of a role playing game for Windows Mobile on Handango is about $20. After crunching the numbers and using the wonderful spreadsheet provided by SCORE I determined I could make a living if I sold the game for $15 and sold a total of about 4,100 units over the lifespan of the game which I estimated to be one year. I bounced these numbers off of the CEOs of two other game companies. One CEO said my figures were "spot on".

Owen Goss said he needed to sell 9,150 units of Dapple before he would break even. I leave it to the reader to figure out what percentage of the market Dapple would require to break even. I am pretty sure it would be much larger than 0.5%.

The thing that puzzles me the most is why some people are so adamant I should develop for the iPhone? It seems they are trying to evangelize me to the iPhone religion. They believe all the hype and anecdotal stories. My choice to develop for Windows Mobile is an informed decision based on research. I am not embarking on creating a company based on anecdotal stories.

Sunday, May 24, 2009

Problems with Practical Web 2.0 Applications with PHP

I wanted to use the code from Quentin Zervaas's book for a website. There is a lot of good material in the book. Unfortunately, the development environment used by Quentin Zervaas must be very different from my development environment.

I could not get the code to work for days. I kept fumbling around and fumbling around trying to figure out what was wrong. The first problem was the index page code was crashing and leaving no log. It took me a while, but the problem was with the EmailLogger code bye Zervaas.

I am running on a Fedora 10 Linux development server. This is a minimally configured virtual machine running on my under powered VM server. This is not a production server. The first problem comes from the minimal configuration. Zervaas wrote the following code in the file "index.php":

$writer = new EmailLogger($_SERVER['SERVER_ADMIN']);

The code is simple enough it passes the "SERVER_ADMIN" name to the EmailLogger function. On a minimally configured system the value of "SERVER_ADMIN" is "root@localhost".

The EmailLogger function calls Zend_Validate_EmailAddress to make sure the email address is valid. The code is shown below:

$validator = new Zend_Validate_EmailAddress();

The default constructor for the Zend_Validate_EmailAddress only allows DNS hostnames. This means that "root@localhost" is not a valid email address using the default parameters when creating Zend_Validate_EmailAddress. This took a long time to figure out.

The solution is to tell the constructor to allow both DNS and local names. The code to do that is below:

$validator = new Zend_Validate_EmailAddress(Zend_Validate_Hostname::ALLOW_DNS | Zend_Validate_Hostname::ALLOW_LOCAL);

The support site for "Practical Web 2.0 Applications with PHP" does not document the problem with the email validation. The support site did document the next problem I ran into. This was extra slashes at the beginning of each URL. Instead of the URL being "/index" it was "//index". I tracked down the problem quickly. But every solution that made sense to me failed. The support site has two lists of errata for the book. One list is the old and unmaintained list. The other list is the new and maintained list. The new list does not contain the errata listed on the old list.

A more subtle problem is the wording of the errata. The old and unmaintained list of errata states, "When using Zend Framework 1.0.3 URLs will be generated beginning with 2 slashes." What the errata should have said is "When using Zend Framework 1.0.3 or newer URLs will be generated beginning with 2 slashes." I installed the Zend Framework 1.7.8.

I now have a problem with Captcha and image generation. This has been yet another learning experience.

Monday, May 4, 2009

Rounding Error Are an Important Consideration

My background includes a lot of mathematical analysis. I took a lot of numerical analysis at the University of Utah. Many more classes than were actually required because I enjoyed the combination of math and programming. In addition, I was a teaching assistant for the computational physics classes taught as part of the master's of instrumentation program of the physics department. My first job when I left the University of Utah was working on mathematical educational software. My assignment was part of a group creating a system that symbolically solved mathematical problems. I learned a lot. One of the challenges was checking the work of the system. I spent months doing nothing but math. After giving the system a problem it would generate an answer. Often the answer didn't match the solution printed in the book. We had to determine if the computer's answer was actually the correct answer. The system may not have simplified the answer, or not done some trigonometric substitution or maybe the answer in the book was wrong. It was a lot of work. That taught me the importance of mathematical simplification.

Years ago I worked on a respiratory therapy patient demographic and therapy management system. The company's core intellectual property was the set of equations modeling the treatment efficacy. The equations took the raw numbers provided by the medical instruments and the patient demography and created a meaningful human understandable diagnosis. My task was implementing those equations on a new system. I took one look at the equations and knew something was wrong with them. My background in numerical analysis told me curve fitting software created the equations. The curve fitting software mathematically matched the curve but did not simplify the equations. I convinced the professor that created the equations I could simplify them. For the next month I proved symbolically and numerically my simplification of the equations was correct. Imagine working on a month long math test. I proved the error analysis of my equations was significantly smaller than the original equations. More importantly, the resulting program ran more than ten times as fast.

What does all that have to do with XAML, hex grids, and user controls? You would think I would know better. I start working on making a hexagon a user control and what bites me? Rounding errors! I should have known that rounding errors would cause problems.

I started working on converting the shaded hexagon from my previous blog into a user control. I needed to work out the coordinates where to put each hexagon to create a hex grid. I created a column of hexagons. They looked good. I then added a second column, a third, and a fourth. Things looked great as you can see below.

Then I zoomed in a bit. Then I noticed that the hexagons did not always touch. I immediately knew the problem: rounding errors. You can see that below.

Hexagons tile the plane. Unfortunately you cannot tile them in XAML because you can only tile using simple rectangular patterns. I could use more precision. That would make the problem less likely to appear. The other option is just to make the hexagon grid as a series of polygons; each one calculated using as much accuracy as possible. You can see that below.

It looks like all is well with the hex grid. Until I made a simple change: I changed the stroke width to zero. You can see the result below.

Rounding errors are still visible. What does that mean? The short answer is you cannot expect to perfectly replicate a hexagon grid.

Sunday, May 3, 2009

No Geometry Resources in Silverlight 2

I wanted to create a hexagon grid. There is a good article on how to draw a hexagon grid using C# code here.

I wanted to create my grid in XAML. I used Excel to do the calculations. I also used Excel to generate the polygon points statement. The simplest hexagon in XAML I could come up is coded like this:

<Canvas
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    Width="480"
    Height="480"
>
    <Polygon Stroke="#000000" StrokeThickness="1" Points="0,35,20,0,60,0,80,35,60,69,20,69"/>
</Canvas>

That looks like this:

My next step was to set up a nice radial fill. I put the fill as a static resource. The resulting code looks like this:

<Canvas
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    Width="480"
    Height="480"
>

    <Canvas.Resources>
        <RadialGradientBrush 
            x:Key="HexRadialFill"
            GradientOrigin="0.5,0.5" 
            Center="0.5,0.5" RadiusX="0.5" RadiusY="0.5">
            <RadialGradientBrush.GradientStops>
                <GradientStop Color="LimeGreen" Offset="0" />
                <GradientStop Color="Green" Offset="1" />
            </RadialGradientBrush.GradientStops>
        </RadialGradientBrush>
    </Canvas.Resources>

    <Polygon Stroke="#000000" StrokeThickness="1" Fill="{StaticResource HexRadialFill}"
        Points="0,35,20,0,60,0,80,35,60,69,20,69"/>
</Canvas>

The resulting image looks like:

I now planned on making the polygon a resource. Unfortunately you can't do that in Silverlight 2. I looked into converting the polygon into a path and then putting that as a geometry resource. Alas, Silverlight 2 does not allow geometry resources.

I have a couple of options. I could make the hex a user or custom control. That would allow code reuse. But at this time, I just want a hex grid. The quick and dirty way is to just write some more macros in Excel and generate the entire grid as a bunch of polygon statements. I could do that probably quicker than it took me to write this blog. However, I am dedicated to quality. I would never allow a developer who worked for me to hack out something quick and dirty like that. That means I need to create a user control and code that up. It will take me longer to code up the user control. The advantage is the resulting code will be reusable (even though I doubt I will reuse it).

I now know what it was like to work for me. I am somewhat of a demanding manager. I want things done the right way with no quick and dirty solutions. Now I can say I apply that standard even to my own work.

Thursday, April 23, 2009

In Praise of Multi-Boot

I use a tool named System Commander to allow multi-booting. I recently ran into an interesting reason why multi-booting is very useful. I have heard comments that virtual machines make multi-booting almost unnecessary. I disagree. I have a PC that I upgraded numerous times. It started out as a 486 to give you an idea of how long I have had this. I don’t think anything is left of the original Gateway 486. As disk drives became less and less expensive I copied the images of the operating system over to new drives. I configured the system with three separate operating systems: Windows 2000, Windows XP, and Windows Server 2003. Using System Command the computer normally boots up into Windows XP but I have the option of booting up into old Windows 2000 or into Windows Server 2003. On a side note, when I boot up Windows 2003 I then run VMware server and have several VMs. Sometime last summer, the sound out of the system started to act a little strange. There were pops, clicks, and stutters when playing music on Windows XP. I believe two different things causes issues with the sound system. First the sound card may have started to die. Second, one of Window XP innumerable updates may have cause the problem. True to form, the sound completely died. I swapped out the sound card with another slightly different one. After reinstalling the drivers on all three operating systems, I have great sound on two of them: Windows 2000 and Windows Server 2003. But Windows XP still has pops, clicks, and stutters. This means the problem is not with the sound card, but with Windows XP. It does not solve the problem, but it eliminates one possibility. Besides being able to switch operating systems, System Commander has the ability to repartition many disk formats. It is interesting that only Windows XP is affected. I considered installing Windows Vista. But I did not have the disk space.

Monday, April 20, 2009

Converting Campaign Cartographer Files to XAML

ProFantasy created a program named Campaign Cartographer. The program allows the quick creation of very high quality maps for role playing type of games. I was working on a logo for the company I am trying to start. I wanted to create a Silverlight XAML file for the logo. I knew that Campaign Cartographer could quickly and easily create a piece of the Logo. Now for the challenges in getting that file into XAML. Campaign Cartographer has only a limited number of vector output options. I could easily create a bitmapped graphic in a variety of formats, but I wanted to stay in the vector space. The logical place to start is as a Windows Metafile (.wmf or .emf). I exported the metafile and tried using one of the freeway tools EMFtoXAML. This produces basically produces an empty file. EMFtoXAML does not support any of the drawing commands used by Campaign Cartographer. I then tried reading the .emf file into Adobe Illustrator CS 1 (the most recent version I own). The result is very low quality. My next step was Corel Draw 12 (the most recent version I own). Again, the result was awful. I gave up on .emf files. Now to try another vector format: AutoCad .dxf. Now the fun begins. The current release of Campaign Cartographer is version 3. On my system, Campaign Cartographer 3 crashes when trying to export a .dxf. I then fire up an old PC that has Campaign Cartographer version 2 installed. This program exported the DXF without problem. Then went back to Adobe Illustrator CS 1 to try and import the .dxf file. Again, Adobe Illustrator did not render the import usable. My next step was back to Corel Draw 12. Corel Draw 12 imports the .dxf. The result of the import into Corel Draw is not perfect. The import removes most but not all of the color. At least the outline is clean. Corel Draw can export an Adobe Illustrator file or .ai file. I installed the preview version of Expression Blend 3.0 from Microsoft. Expression Blend 3.0 is supposed to be able to import Adobe Illustrator files and create XAML. I fired up Expression Blend and created a Silverlight project. Expression Blend disables the menu options to import an Adobe Illustrator file when you create a Silverlight project. After fumbling around for a while I tried creating a WPF project in Expression Blend. That allows importing Adobe Illustrator files. I did some searching on the web, and nothing mentions you can only import Adobe Illustrator into WPF projects. I tried importing the Adobe Illustrator file created by Corel Draw 12. Expression Blend 3.0 Preview says it cannot understand the file and cannot import it. I then go back to Adobe Illustrator. I open up the file created by Corel Draw in Adobe Illustrator and save the file back as another .ai file. It is interesting to note the Adobe Illustrator's default name for the file adds the word "[Converted]" to the file name. I open Expression Blend 3.0 back up to my WPF project. Finally I can import the .ai file and the image appears in Expression Blend. The colors are gone, but at least I have the XAML file I can work with. I hope that someday ProFantasy will add the ability to export data directly into XAML.

Wednesday, April 8, 2009

Windows Forms versus Web-Based Technology

A friend asked a question: "I have a question...curious about what you know about web-based system architecture design. Specifically, use of Windows Forms (.net framework) versus Frames Technology." The short answer to your question is web-based systems run inside a browser, and windows forms based applications run as applications on your PC. But things are a bit more complicated. Web-based systems use a variety of standards: HTML, XHTML, XML, and CSS. Developing a web based application requires testing on a variety of browsers (Internet Explorer, FireFox, etc.). You can access a web-based systems can from mobile devices like a BlackBerry, iPhone, and so on. Because they run in a browser, web based application also run on Macs and other operating systems besides Windows. In general, web based systems do not need to be installed on the computer. To run a web based application you just open up the browser and point it to the URL for the application. The downside is that Web-based systems have limitations on what data they can store or access on your local computer. A well designed web based application allows changing the "skin" of the application easily. Someone can change the colors, fonts, or layout used in an application without the need to recompile or reinstall the entire program. You must have a connection to the network for a web-based application to run. The phrase "software-as-a-service" or SAAS is usually associated with web based applications. Web-based applications run from a server. Changing the application on the server changes the application for every user at the same time. Windows forms based applications only run on a PC. You must install windows forms based applications. This means the application can take full advantage of any hardware you have on your PC. The application can access and store data on your local hard drive. To change the fonts, colors, or layout of the application usually required a new build of the application and a new install. (There were tools to support "skins".) Things are ever more complicated. Technology continues to innovate. Windows forms technology is old. Microsoft replaced Windows forms with Windows Presentation Foundation or WPF. Another name for this technology is Silverlight. WPF makes it easy to change the graphics, layout, fonts, and colors used by an application. This technology allows developers to use a component based development methodology. Developers just click and drop the components they need on the form and connect them. Another name for component based development is rapid application development or RAD. Customization of the application to make it look pretty no longer requires a developer. By the way, this was a huge issue at one company I worked for. I remember one project where the developer finished the functionality of the application in about two weeks. Then the developer spent the next nine months continually changing the colors, fonts, and layout to make the application pretty enough. (I used to get into nasty arguments about the time wasted on changing the colors, fonts, and layout.) Silverlight applications run inside most browsers. The server (or servers) must be up and running twenty four hours a day, seven days a week, three hundred and sixty five days a year for Web-based or Software-as-a-service based applications. If the server or network goes down, everyone is down. You install windows based applications on each PC. If the PC is working the application usually works. However, if the application requires access to a database, then the application only works if the database server is up and running. The biggest headache to windows based applications is the release of new versions of the software. Technology continues to change. Perhaps the best example is the game World of Warcraft. This is an application you install on your local PC that talks to a set of servers. World of Warcraft automatically installs new versions when you log in. The game won’t run if you don’t have an Internet connection. World of Warcraft uses your graphics card to the max. Performance of the game is generally limited by your PC and not by the server. This does put a bit of a strain on some network connections. If you need to make the decision on which technology the first question is: "will the individual computers always have a connection to the network and/or Internet?" If the answer is "no", then in general you want to stay away from a web-based solution. (I did manage a project that embedded a web server inside the application, but that is a complicated solution.) If the answer to that question is "yes", then you need to think about the type of computers each person who runs the application has. If you have a combination of PCs and Macs, then you should go with a web-based solution. If one of the stakeholders places the esthetics of the application very high, then go with a web-based solution. If you plan on changing the application frequently, it is easier to change a web-based solution. On the other hand, if you need to get performance out of the local PC, go with a windows based solution.