Thursday, February 10, 2011

Portable software...

Over the last year and a half I've had the opportunity to work with Qt in software development, and I've enjoyed it greatly.

In a previous job, I looked at what it would take to port our software from being just on Microsoft Windows to also running on Linux, Mac, and various UNIX operating systems. In the course of that research I looked at several options: (i) Qt, (ii) Gtk, and (iii) WxWidget. The problem I ran into then was (a) Qt simply cost too much for the project (due to our budget), and was a security concern - not from the bug aspect but from the aspect that the target market was military and getting Qt certified for the environment would be hard - and a failure there could keep the project from certification as well. WxWidgets and Gtk both has the same security concerns; however, Gtk also had a licensing concern given its LGPL nature and our software was proprietary - Qt provided a great way around that if we could afford it, but we couldn't. So alas I was unable to get into Qt at that time, but as a result I was able to write a good portion of code for doing the same thing - writing my own platform abstraction API.

Now, of the three I loved the ideas and concepts introduced by Qt the best. Gtk, at least at that point, was still very much Message Mapping based from what I could tell. MFC was more than enough of that for me, and was just a pain - everything was determined at compile time and there was little flexibility. One of the great concepts that sold me on Qt was the Signals & Slots system that replaced the message mapping. WxWidgets supported both. Otherwise, all three seemed to be fairly equivalent at that time.

Now, before I go on let me state that I am not trying to convert anyone from Gtk or WxWidgets to Qt with this post. However, if you are using .NET or MFC or anything else (especially on Windows) then you need to start looking elsewhere for numerous reasons which I'll save for another post.

I had written applications in MFC and Win32 for a number of years - both GUI and services. They met the need at the time they were created but are no longer sufficient. .NET, on the other hand, does seem to be vastly updated by comparison but still has quite a few issues - at least patent wise if you want to have portable software.

Now, portable, multi-platform software is going to become ever increasingly important, and unless you are doing certain things that are very tied to a specific environment (e.g. extensions to Windows Explorer or KDE Plasma) then you can reach all your customers on all their platforms with a single code-base using the right tools. WxWidgets, Gtk, and Qt are some of these tools - and probably the best and most portable of all available. They are also Open Source. WxWidgets is completely public domain; while Gtk is solely LGPL. Qt, however, has several licenses - GPL, LGPL, and commercial licenses to choose from, so from a business perspective it makes the best sense - at least, as long as they continue the commercial license program; while from an Open Source perspective all three are really about equal in choice.

All that said, I must certainly say that the creators of Qt have done an excellent job and really gotten the platform right - one that is also continuously improving as well. Perfect just gets better.

So, now why do I say that?

Well, Qt is split into several modules, and they're working on making it more modular yet. Of course, you have to use the core (Qt-core) to use any of it, but the rest is pretty much optional - everything from networking to XML to services (daemons), and more - even in-program scripting. Additionally they also made it very easy to convert from Qt to Standard C++ and back - most all of their classes have functions to convert back and forth where overlapping occurs. The layers make sense and work; consistency abounds throughout the APIs.

So now with a single API you can reach from Linux, to Mac, to UNIX, to Windows; from Desktop to Server to embedded devices (tablets, netbooks, cell phones, specialty devices, etc.). There's not much you'll need a specialized, platform dependent code-base for - which basically comes down to Kernel-land software, and integration environments whose requirements prohibit being able to choose what API set you want to use (e.g. Windows Explorer ala TortoiseSVN). And you get all of it at native performance and looks, with bindings to most languages (e.g. Python, Java, Perl).

Businesses can certainly save themselves a lot of money by using APIs such as Qt, as well as preserve their businesses should anything happen to Microsoft or MS Windows - it's quite a gamble to put all your eggs in one basket, but yet so many software development houses do.

Fixing Health Care

Despite what the Health Care Industry, Congress, and President Obama would like you to think there really is a simple way to fix health care.

President Obama and the Democrats in Congress want you to believe that all the changes in their recently passed, much despised, and soon to be at least partially repealed bill is required to fix health care. However, it really does nothing for you - and it only makes the debts higher, extending entitlements where none are needed.

The Republicans don't have much to offer, but are at least doing right by trying to remove the bill that no one really ever wanted to start with - well, except the Democrats in Congress and Obama since it made them look like they were doing something when they really weren't.

So what's the correct fix?

  1. Insurance companies will be required to accept all properly licensed doctors. E.g. eliminate the whole "out-of-network" thing; it's really just a mess that is completely unnecessary.

  2. Insurance companies will be required to pay what the doctors charge. They must not be allowed to pay out only a portion of the payment, and no refusals to pay.

  3. Doctors will be required to charge only what is necessary - they may not inflate what is charged to the Insurance companies or to individuals.

Insurance companies need to remember what their business is - betting that people will not need the benefits they pay for. However, when people need those benefits they also need to pay out. Doctors are licensed by the American Medical Association, and as such need to be allowed to make the final call, possibly having a second opinion as well, but the AMA should lay out the rules. If people opt out of having insurance they they should have to pay the full amount themselves; but the insurance industry to not and should not depend on 100% participation to work. Simply put, people that are opting in are betting they will need while those opting out are betting they will not.

Doctors ought to be able to charge what they need to. If necessary the AMA or a Federal program can provide oversight to charges - to ensure they stay within reason (e.g. costs plus a small percentage of profit). But what is charged must be payed out in full without the doctors having to appeal or inflate prices just to get what they need to stay in business, and people shouldn't have to chose a doctor based on their insurance but based on the quality of care and services provided by the doctor. As a result, people not using insurance will be charged the same as the insurance companies - and doctor's would have no reason to discount it for them as a result.

So now we've solved the same program, far more effectively, and without intruding on State or Personal rights as granted by the U.S. Constitution.

All we have done, however, is forced Congress to break its ties with the Insurance industry, their associated PACs, etc. and actually represent the people.