Hello Guys,

After jumping from one business idea to the other, looking for the perfect one and not finding it, I've decided to return to the land of software development. My Favorite Buzzwords: Python, HTML, Sqlite.

I left the field initially because I felt free software was so abundant that it's hard to come up with a product idea without an open source equivalent. I'm back because I think I have genuine 'passion' for it.

And I want to interact with you guys. I want to learn from you and share my insights with you. Here.

Cheers and Thanks.

Nice decision for moving away from consumer mentality which has been the bain of this country to production stand
Kick-start the journey; we ll follow suit

@Poster: Why Python? Python is not much mentioned in the world of win32 programming; what are the reasons for you using/liking python?( That's a digression anyway)

I was going to say software development as a business requires working with a team, more often than not. The mistake most nigerian software enterpreneurs make is trying to know everything so that they can strike out 'on their own'. It's also one reason why i am not (yet) running my own biz: at the core of it I am a programmer. My User Interface design skills are not the bomb, neither am I a photoshop/flash guru.

@gridlock I also got issues with designing interfaces and all that, even when it comes to web programming.
I prefer to deal with the internal workings, buisness logic and all that. But well its the interface that
attracts people I guess, no ones interested in how fast your code is,
All my former boss was interested in was "where is da home page?"", and how "flashy" it looked.
So if I want to enter the web app buisness, I gotta look for a good webmaster.

In terms of ornamentation of interfaces using graphics leave that to me

Why Python?

Python code is very concise and readable, which makes programming much easier. You don't have to compile your code to run it, which really speeds up iterative/interactive development and testing. If you write a Python program like a C++ program, it's going to be about 10 times slower. But that doesn't matter much outside games, anyway.

Why SQLite?
SQLite is an embedded database, so you can deploy your application without a DBA. It's quite fast, especially when your queries are simple and fast OLTP queries. It even supports ACID transactions, and is 100% free in every way.

Why HTML?
I have observed that the web is much easier to use than most Win32 Desktop applications. Modern browsers come with a lot of useful features that will take decades to implement in one's own code e.g. spell checking, auto-completion, password management, document and image rendering, et cetera. A web-based application built right will require almost no training because it will be as easy to use as the Internet. And the python GUI sucks!

Why C?
In the rare event that I need more speed than what python can provide, I can just build a Python extension module with C. I'm supposed to have used C in the past, so I should be able to pick it up if ever required.

Some popular buzzwords that mean nothing to me: XML, AJAX, (I will update this list later)

@ Seun
You sound good and ready to go places

Some popular buzzwords that mean nothing to me: XML, AJAX, (I will update this list later)

But they all have their different uses.

My software is definitely going to be browser-based.
The big question is whether I will host it myself (on the Internet) or
allow my customers to run the software on their laptops and servers.

Advantages of self-hosting (web-based software) include:
- Not having to worry about piracy.
- Being able to sell my software internationally.
- Not having to support multiple versions of your software.
- Minimal distribution costs since web hosting is cheap.
- Zero installation costs.
- Cost-effective advertising through Google Adwords.

The problems with the web-based hosted approach include:
- Relatively poor performance if customers don't have a very fast Internet link.
- My application is only as reliable as the customer's Internet access and power supply.
- I can't sleep well knowing that I'm responsible for my customers' mission-critical data.

The web-based approach is the better choice if I'm aiming to sell my product Internationally.

The standalone option seems preferable if I'm selling to Nigerians, but then I'd have to deal with piracy which is a big problem here. Nigerians may buy CDs and DVDs, but they don't but software. Nigerians may buy laptops and PCs preloaded with original software, but they don't buy software. This simple fact cannot be ignored! The only way to deal with piracy is to do what the Nigerian movie industry does and sell my software to the pirates.

That seems like a very risky business model, so I'm back to the idea of making my software web-based. That's not so bad, since I'm a webmaster. Right? I hope so! Too bad for people who don't have broadband. My key to making the web perform almost as well as a local or LAN-based application is to reload pages less frequently. Details later.

Here's a discussion I started on another web forum: Help: I Don't Want To Build A Web App.

Seun, sounds like you don't fancy AJAX. How would the web browser maintain communication with the web app without constant refreshes (sounds like you have some magic method up your sleeve: do tell us).

Looking at the pros and cons you have listed, I have this suggestion: develop a desktop app that connects to the server using some kind of RPC. That way, the client can do some work/updating if the connection is down, yet he can't copy or resell your app. Also, the user can choose whether to use the fully-internet-dependent broswer interface, or the partially-internet dependent Desktop GUI. Example: the Jounal editor known as Drivel. What do you think?

You forgot to add Apollo! (now known as AIR) heh heh. I will suck you in yet!

Which one is Apollo or AIR? I thought Flex was Adobe's new initiative. That company needs to make up its mind!!

I was going to say software development as a business requires working with a team,

It doesn't require it, but it's much much better to have a team. I wish I had a team! I'll have one soon enough.

@gridlock I also got issues with designing interfaces and all that, even when it comes to web programming.

Simple interfaces are pretty easy to design with HTML, really.
The problem is when your client wants flashy graphics. HTML forms can't be hard to build.

Gridlock: I have this suggestion: develop a desktop app that connects to the server using some kind of RPC. That way, the client can do some work/updating if the connection is down, yet he can't copy or resell your app.

I love interesting suggestions like this. Thanks. But I think a desktop/server hybrid solution only works for Internet-oriented applications such as email, feed readers, blog editors, CMS's, CRM's, etc.

The architecture of my application is similar to that of a word processor. You type in your stuff through a simplistic UI and my application produces printable documents of a certain type, which you can save for further editing.

Like a word processor, my application does not require the Internet at all. I can't imagine how I would split the features between the server and the desktop client. If the core features are on the desktop, then I can still suffer from piracy. Someone could crack the desktop portion of my software so it works without the server!!

Seun, sounds like you don't fancy AJAX

I don't fancy AJAX, because it's not really faster than full page refresh. I fancy dynamic HTML. What's the difference? I prefer to hide information on a page and then make it instantly visible with DHTML when the user needs it. That is much faster than AJAX. AJAX is not fast because it requires a new HTTP request for each click!

How would the web browser maintain communication with the web app without constant refreshes (sounds like you have some magic method up your sleeve: do tell us).

HTML forms of course. GET, POST. If required, I can use Javascript to submit certain forms automatically.

what can i say.
emm mmm ok

wot of if i disable jscript on ma browser wot happens to ur dhtml

Same thing that happens to your AJAX.

I can't imagine how I would split the features between the server and the desktop client. If the core features are on the desktop, then I can still suffer from piracy. Someone could crack the desktop portion of my software so it works without the server!!

Core features can remain on the server: the UI, icons, (localized) messages, etc will be installed on the client end, but the working area can be a web page made up of both static and dynamic html/web components which can exchange data both ways.

This has an advantage over the browser in that these components can talk to both the app (local, via the static components) and the server (remote, maybe SOAP or JSON or XML-RPC).

Apart from that, the clutter of the usual forward/backward/history buttons on a typical browser are eliminated. The user can save data locally if the webpage-components communicate the required data to the app, which (of course) should then be able to make changes to the filesystem. Look at Norton Antivirus 2003 and higher: almost the entire UI is done in HTML. Now imagine that the scanning engine/heuristics/virus definitions are stored remotely, all you will still see is the html page -> the user doesnt have to know where the engine is.

If there is no internet connection (or, as is more often the case, connection is too slow at the moment), the user can still launch the app. He wont get "this page cannot be displayed" or "connection reset by peer" because you have components which detect these conditions and send appropriate localized messages. He can make and save settings, etc, but the core of the app is not available until the connection is active.

Now that would mean, effectively, those using the full-blown browser-based version actually get less features than the desktop-based version ala offline functions. Just thinking about this, sha. It should work.

Would you use a virus scanner that doesn't work when you're not on the Internet? That has to upload all your files?

Would you use a virus scanner that doesn't work when you're not on the Internet? That has to upload all your files?

Hey, It was just an example . In any case, if that were desired, the program simply identifies the file(s), sends information about each one to the server - rather than upload the entire file - which replies with appropriate action to be carried out on it. (There's security and privacy issues, of course which makes it pretty hard to use an online scanner - i agree with you on that ). _{Mcafee has an "online virus scanning service". I wonder how that works,} Dont mind that, just a digression.

It's easier to get people to sign up for a service than to get them to download a file,
so if one's program only works on the Internet, why not just make it work in a browser?
Why force users to download a large file when a browser-based approach would work?

That's a truly interesting concept, Prodgalson (and Gridlock). I'll keep it in mind. Thanks!

There are several issues with an internet based app , the availability of an internet link becomes a constraint.


Like prodgalson said its possible to obfuscate your code. It'll probably be harder to obfuscate an interpreted language such as python as opposed to, say c.

But even obfuscation has it limits if a person wants access to your process (source code isn't necessary).


In my opinion, Software should be seen as a subscription service, a client pays, not for what you've written but for the ingenious ways your app can aid him. He'll pay you to solve both the problems that he has now and later in short , he pays for support.

Write your software and make yourself invaluable to your customers. The ones that matter will keep coming back.
Most large software outfits have learned this, you can even download fully commercial versions of the software form the net.
They know that for non-trivial use the customer would alway call them , (sometimes )

@Ghengis: I'm 100% in support of the idea of software as a subscription service. Provided users can swallow it! But the idea of operating as a consultant will encourage me to make my software hard to use. That's bad!

One of the side-effects of moving from the desktop platform to the web platform is that I no longer need an embedded database like SQLite. For a web application, installing a database server won't be a problem. For convenience sake, I've decided to stick with MySQL - the friendly database server I'm familiar with. Even though SQLite is lightweight, I can gain far more performance by caching in Python than I can by switching to SQLite.

Many software developers pay little attention to the choice of which program to write, because the act of writing the program is what they find interesting. As a one man business, that's not a mistake I can afford to make. I'm willing to spend months thinking about which program to develop. My Indian friend calls it analysis paralysis, but I think temporary analysis paralysis is better than outright failure. I know what it's like for a business to fail.

The program I'm currently working on seemed to be a very simple one when i settled on it, but I've discovered that it's much broader than i thought. In fact, there are many companies on the Internet specializing on just a tiny subset of my idea. The problem I'm having right now is like the problem I had when i tried to build a universal discussion forum - the idea is just to broad for one person to tackle it perfectly. I may have to choose a smaller niche.

Here's the web site I'm using to choose which niche to target: http://inventory.overture.com/. Good luck!
You might be interested in this page: http://inventory.overture.com/d/searchinventory/suggestion/?term=software

I've been checking out my future competitors' software. Some of them are web-based applications while others are windows-based. The windows-based applications have a steeper learning curve than the web-based ones.

Could it be because:
- As a webmaster, I'm used to the web and so anything outside the web seems hard to me? I disagree.
- Web-based software vendors know that their ADD-stricken site visitors can exit their software at the click of a button, so in order to retain their potential clients they have to make the software very easy to use for a beginner? Whereas, windows-based software vendors know that after going through the trouble of downloading and installing their software, you will be inclined to spend more time trying to learn how it works? This is likely.

The redeeming feature of the windows-based applications is that they are very fast and have lots of features. These advantages are helpful to expert users, but from a sales/marketing point of view are quite useless!

The most difficult problems I have right now is that the product I'm working on is not a product that I truly understand. I don't know how it ended up this way, but I'm not the target customer and I don't know how to reach the target customers without sharing my idea with the entire Internet. Now I'm stuck. Help!!

How I wish i was writing open source software and that I was writing it for software developers!

Thanks so much. I find your comments useful. I've been inspired to reach out to those rich executives!

Even if you think you're rambling, there will always be something I can pick up. Getting no response is worse!!

I've been able to get about 5 potential customers from all over the world to say something about their needs with respect to the application i wanted to develop. It appears that many people use CRM software for the purpose, while others use free resources on the Internet. They seem to be satisfied with their current systems. It appears that to make my application compelling I really have to focus on a more narrow niche.

Meanwhile, I've been working on a kickass embedded http 1.0 server written with python. It does 1800 requests per second on my humble PC without breaking a sweat, and 2000 per second if compiled. I'm sure it can do even better if I run the http client on a separate computer. Funny thing is it's a simple, threaded server. My big question is how can I immediately profit from this little amount of work I've done?

Thanks for the encouraging words. The HTTP server is probably nothing special, really. I could just open source it.

I tried to turn my threaded HTTP/1.0 web server into an event-driven HTTP/1.1 web server and my brain exploded!

@prodgalson:
The easiest way is to just read the sources of a toy http server like the one that's shipped with Python.

Threaded servers are so easy to write compared to event-driven servers. The problem with them is that, unlike an event-driven server that just maintains a few variables for each open connection, a threaded server dedicates a different thread to each connection. You can get good performance from a threaded server, but you basically have to disable the HTTP/1.1 keepalive feature to avoid getting threads tied up by slow clients. However, switching off the HTTP/1.1 keepalive feature limits the percieved speed of your site, and that's just not optimal. (One of the first things you learn when tuning apache is to reduce the keepalive timeout to a useless 3-5 seconds)

You can gain the best of both worlds by putting an event driven 'reverse proxy server' with HTTP/1.1 support (ngnx, lighttpd, varnish, or even squid) in front of your threaded server. That's the sort of system I'm using for this site. But it's not a very pretty solution. A simple http request shouldn't have to suffer the latency of 2 servers!

So yesterday I tried once more to write a simple event-driven server (a cache server, not an http server). My brain didn't explode this time, but it almost did. Debugging is a such nightmare! It sort of worked - I was able to retrieve 30,000 tiny cache entries per second this machine - but it's not as fast as I expect it to be. I've decided to use the filesystem for caching in my future http server designs. Fast file access on a RAM Disk, yay!

Why HTML?
I have observed that the web is much easier to use than most Win32 Desktop applications. Modern browsers come with a lot of useful features that will take decades to implement in one's own code e.g. spell checking, auto-completion, password management, document and image rendering, et cetera. A web-based application built right will require almost no training because it will be as easy to use as the Internet. And the python GUI sucks!

Hello Seun, you've really taken a good step. I want to tell you that I'm so much interested in Software development than any other computer related tasks. because, if u observe very well, the software developers will be at the top of any other computer tasks in some years to come. Your posted articule has encourage me more because I know HTM programing, ASP and some basic SQL which I thiink they are not that good to build a package for organisations. The funiest part of this is that I use these to build web packeges on my system just to play with at home until when the company I was working with got a contract and I told my MD then that I will try to build the Package. The Package cost a lot of money which I can't say.

Then I knew I have missed alot

Now I still need more knoledge on those programming languages

@Adeniyi G: Thanks; I'm glad you found my comments useful. Hope to use your software someday and vice versa!

I envy people like Linux Torvalds (for Linux) and Richard Stallman (eMacs). Their code is their lasting legacy.

Do you want to go commercial?
You may want to look at Dot Net or Java.
I'll pick Dot Net cause it can do anything java can do.
Its not there yet but its heading in the right direction.
Basically you can write programs with a shorter length and time.

HTML is good but not the end, you may want to add XHTML and CSS.
Dont over look XML, its the most predominant format. Its extensible and self describing.

My http server development process, while educative and interesting, was a complete waste of time. The threaded/multi-process version is equivalent to apache+mod_wsgi running behind event-driven nginx!

@somze: you're right, I find .NET very tempting - especially C# and ASP.net. The performance is excellent