SLS - Steve's Last System
On January 5th, 2006, a decision was made to design build and implement a new system for our own business, and install it into the businesses of our customers. As time permits, specifications, the running system, and the source code will be published on this site. All the open source tools will be included, including operating system components.
Reference to reasons why one may chose to use certain commercial tools like Microsoft FrontPage or Macromedia HomeSite will be made to explain the reason, why one may choose not to use an open source solution, and to buy a tool to use instead, to maintain certain portions of your system. Reasons why one may choose not to use other comercail products like, QuickBooks QuickBase, and instead use open source solutions will also be explored most completly. There is more than one way to skin the bear. I'm trying to explore the best way, which I'm also convinced will turn out to be the most bang for your buck.
Some of the products I still use are old. I do sometimes use telnet/ssh and vi. It's not Eclipse, but it works. It's ok. I'm old too. I'm 60. But I believed for certain situations and the type of editor I need, HomeSite could not be beat. But it looks like I may be able to find the time to evaluate HomeSite+. It may be that this new tool is better than the old version of HomeSite which I love. I'll let you know what I think as time goes on. But one thing is sure. When a product is done correctly. As time goes by, it becomes more and more difficult to improve that product, without adding more complexity which may ultimately detract from the inherent beauty of a product done right.
I'm working with OpenSRS now, so I'll try to create a blog, and monitor it so that gurus along with mere mortals will be allowed to critique what we are doing. Anything we do wrong, or mistake I may make will be changed right away - as soon as possible. The design of this system should allow it's continued use in business for at least the next 10 years - through until about the year 2015.
This latest project arose out of the intense dissatisfaction with the application software which has been produced in the last 5 year. Can't even use their software in my business any more. Things have just changed that much. Mostly because of the Internet, http://sourceforge.net/ and http://freshmeat.net/. Application software developers are doing it wrong. Sometimes you have to just wonder - who is advising these people - the software communication systems are really that bad - in fact horrid. For some unknown reason (really don't know why this is) people have come to expect junk. Constant crashing, getting stuck and unable to do even simple things. Or turn your head upside down to get something done. It is such a joke. Error messages and machines crashing all over the place when all you want to do is work. In my considered opinion in fact, the developers all have made only two mistake. Huge mistakes, but still only two mistake. Not one company. Almost every company has made and continues to make at lease one of these same two mistakes. I call them fatal flaws in a system.
The first mistake is they have implimented client side solutions instead of server side. What a joke. What were these people thinking. Using odbc drivers or Samba, NFS or Windows file sharing in a production system, with drive mapping? It is just way to sick to even talk about. There are better ways. Ways that work over the internet. This idea that a system will work local, but dies remote is nonsense. Will never work. It is just crazy. You can not try to turn a server side solution into a client based solution with file shareing. Period. Never have been able to. Never will. This is not even a good patch job for testing, but it surely can never be a rock solid production system. You must be rock solid if you ever hope to win. And you must be fast. Ligting fast. Time is money. Look at the clock.
This is part of how you do it right. All the logic stays on the server. The code is generated and on the fly only generated Java, cgi, html etc is sent to the client. The PHP self destructs and all is gone. Then it all works. Quick, simple. cheap and easy. Maybe exactly the same thing can be down with .netx, Active Server Pages or Java Server Pages. But this is not rocket science. Have no idea how people ever allowed things to get so screwed up. It has just made me angry. Nobody likes me when I'm cross. And seems I've been grumpy a lot lately. So I'm going to fix it. I'm going to use every piece I can find, to save me time, so this system can get up and in service quickly. The application software problem is interfering with my own ability to even get my own work and the work of my own company done. And for my customers, I'm just fearful it will become even a more serious problem as time goes on.
What we do is incredibly simple. We just collect web junk. Your people type it in. We put it in a data base - that's it. We don't do anything with it. It just sits there. We know what were doing. The keys are right. The edits are there. We do use triggers. Business logic and edits are segregated. Information sits there. And we send some information back and forth, different places. That's it!
We do not even do reports. Well we do have a check register. And we have a very, very few edit reports. But reports must be done in Crystal Reports. We do not do reports. If what you want is not in the library, then you have to pay someone else to have that report written, or get a Crystal guy in house. We do not recommend you stay with Quick Books QUI version.. You can start there but, but islands of information are not good in the long run. We need to integrate solutions. When we are done Quick Books is gone. It's ok. Everybody has to start somewhere. In fact I've seen such a mess that moving to the old QuickBooks GUI desk top version, even in one or two user mode, did save the day. But long run, it's not good anymore -- not the best thing.
Everything runs in almost any web browser. MAC's are no problem. And we even love BSD Unix. Backup servers are on site if needed and we test um. We do not use replication. We sync in batch, periodically. We use LAMP which is Linux, Apache, MySQL and PHP. We use file and record locking. If two stage commit is needed we use Postgres SQL . We also run on Windows 95, Windows 98, Windows Me, Windows NT 4.0, Windows 2000, or Windows XP. Our software is runs on MS-SQL, Windows 2000 Microsoft-IIS/5.0 and Windows 2003 Microsoft-IIS/6.0. We can run Apache on Windows if you like. I'm familiar with Sybase on Windows and I'm evaluating Sybase on Linux. That product is also looking really very good.
We are not yet tested on MS Vista. We support all other operating systems now. We plan to support all future operating systems. Standard versions do run in character mode and are available for DOS, CPM and dumb terminals using characters and run in character based browsers, cell phones and some PDA's Only NUI interfaces are widely available, GUI is not recommended, and implemented only in very special cases using Citrix and/or Terminal Services, which will eliminates the GUI delay. We don't need much power on the desktop, but the faster your PC is the happier you and your people will be.
About 5 or 6 years ago someone told us PC's were getting faster. In an effort I guess to "save" money they said, Wow! It's coming. Let's get ready for it. Let's use all this power. Lets give those thousand of PC's, out there in our business, something to do. Then they will all be working and our servers will not get overloaded. And our servers can even go down and they can still work Yieks!! How wrong is that plan!! God invented disaster recovery. Backup systems are designed to work, but clearly they must be tested. No working contingency plan means you are down. How do you know if there could be a problem? You turn stuff off. Oh my gosh. You turn off one switch -- walla! You are down. That means you have a single point of failure. The design was wrong. So you fix that. It's just that simple. That is part of what we do. We get you up. We keep you up. Your people run your business. Period. Lets be honest here. That's all any business man wants.
The abuse of Java is so wide spread I shudder to think how many people are going to loose their jobs when the companies find out. You can easily get sucked into a bottomless pit. Now it is true that client side Java is good for some things. It is good to write tools. It is great for animation - flames, dancing girls, live charts and graphs -- that kind of stuff. I don't do that. Just don't build those kind of systems. Of course I use Java for my mouse overs but they never break. Why? I don't write 'um. They are generated using tools that do not screw up, like PHP and Zend, and a fabulous little program called HomeSite. The first rule of Java is do not ever use it. The second rule of Java is when you have to have it, never write it - generate it with PHP or Macromedia tools, so well provided, such that things can be done faster without problems.. Get a college kid, or work with your children if you have to save money. Do not even think about telling me these tools are expensive. If you do not buy the tools, or you and your people do not have the time or can not learn to use the tools, contract the work out to someone that has the tools and knows how. Or learn how to use them yourself, and then decide what to do in the future.
When client side Java is generated, not written, that module you can use - a module that will not break. Lets face it. People all over the world are writing Java that no one can read. If you can not read the code you can not write it - absolutely. You must not. How can you be sure. It's so easy. You give 'um a project. It always takes longer than you think. You keep 'um happy. Lots of Mountain Dew. You slide whole pizzas under the door. Then you say. how ya coming? Oh great. Almost done. Just cleaning it up. Finally its done. Goes into production works. Now you ask for a change. You know! A simple change. That happens. But then a very funny thing happens. The guy looks at the code and he does not want to touch it. If it's someone else code for sure. Even if it's his own code, if its been several months, no way. What do programmers do. They either hack it up and break it. Or more likely they want to write a new program.Reminds me of RPG programers that had 600 sales reports. What did they do when someone asked for a change to the report. They wrote a new RPG program to make the required change, but in a new report. How sick is that. You give three Java programmers the same job. A problem at school. All three programs are indistinguishable from each other. There is no standard way to do simple things. There are a myriad of ways to do any one thing. So the programs are completly different, even though they have been worked on, until they all do the same thing. Now ask them to swap programs. Then request they make a change. Then you see it. Work stops while you try to figure out what the other guy did. For some reason, that's not yet understood, with PHP the programs all sort of look alike. People read the code. Then they make a change. The change works. With big groups of large java programs, it is so easy to break the code, that even a small change can result in no output. Boom! You are forced to use your IDE and drop down to a debugger. That is just crazy. Now don't get me wrong. Everything does not work, exactly the way you want, every time with PHP. But at least it runs. You get output. If it is not what you want you change it. That simple.
This is the beauty of server side. You take a PHP program example problem. You give it to three programs. They write it. They all look the same - if they are done right. Now how can that be? Why is that? I'duno. Sometimes, when I'm working, I'm wishing somehow we could get back to the old days, of procedural programming. You got a problem, you put in a display. You see the problem. You comment out the display, and fix it. Can't do that now. It runs all the time. The code is constantly looping. Waiting for a mouse click here, a flash up menu there. The way I see it - you write the modules - you clone them - you use them in source generators. You simply do not use code you can not read or change. But weith every code gnerator i've ever used, I feel like I'm not playing with my bat and ball. It's all a mystery. That's not right. So hear I am, looking for a generator, and if the right one does not pop up soon, I'll have to write it.
I've never seen a PHP program that I could not read expect one that was generated with names that were letters and numbers that were random generated. What did I do. Put it in my favorite editor. Did mass replaces on the stupid names. Wala! Easy to then see what was wrong. Did not re-write it. In fact I fixed the templates so the new generated code no longer had the stupid names. And the new generated code worked first time every time.
Now please do not get me wrong, and misunderstand. A PHP program does not always do what you want. But it does always run. And the HTML does not always look like you want. But it does always execute. It does something. And you look at the output. Then you fix it. With a Java program you can make a change and nothing comes out. Then you are in the debugger. I pray that somewhere there will be help for someone that writes code that can not be fixed without a debugger. Remember - I never write in C. Maybe dash off a few lines for a driver but that is absolutely it. The C language is great for writing operating systems and some types of tools. But heaven help you if you're writing application software in C. Get a life. It has all the same power, and lack of ease of use, as assembly language, only much more complicated. And then there is C++. Worse. If you need an object oriented language with polymorphism, encapsulation and complexity hiding, there is SmallTalk. Much better than C++ for applications. Let C stay in the system software.
When writing in Cobol you need 21 reserved, words. In progress 43. In PHP, you can generate with only 19. I just don't use them all. But with Java I need a manual. Can you believe that. And I say what is this? Oh that's a sort. A sort all on one line. Oh ya! Look how clean that is. It started out 20 lines.But I cleaned it up.. I can't figure out how it works. It can't be modified. And all these new classes. Functions and procedures there is no end to them. Thousands. How is that going to help. It hurts. It hurts a lot! When you say, why are you using this construct. Oh I was trying it out. Three months ago you were trying it out. Yes, I got it out of the manual. Have you ever used it since. No. I rest my case.
If your version control is checking out applets and downloading the latest version you are in deep, deep trouble even with multiple T1's or DS3 SONET rings. Heaven help you if you are limited to 56k to 384k. Huge mess. Don't let anyone snooker you into thinking it can be done. It can't. Source Code Management is critical. It absolutely has to be done right, and the last time I saw it done right was with SCUMS and also with an old proprietary system used by Cobal Programs at the old American Hospital Supply, that I think now may be part of Baxter Travenol Labs. Made to check out, test and merge into production, over 100,000 thousand programs - most with over 5,000 lines. Programmers worked on the same program at the same time, by more than one person on the same program. Trust me on this. It is thought out and done right -- else it is done wrong. Progress sites also have several implementations to test roll in and roll out production code that is fully maintainable using a test and production database and directory search order changes in the profile. Do not drop in, in your spare time and fake this. It is no less important then restart and recover or a two stage commit if you have to have that. You have recovery or you are dead meat. Then you test it.
The second mistake is they wrote the code. Not good. Big mistake. People are human. They make mistakes. The mistakes can be hard to find. Make love, don't write programs. Programs must be created with tools.
So what is wrong. What has prevented people from doing it right. Why don't they change. They know that what they are doing is not working. Well it's really quite simple. They don't know what they are doing. They are students. They are learning. They could no more lay down 5000 lines of clean debugged and documented code a day then the man in the moon. And they all seem to be under the impression that they can not use a generator. Well of course you can not it if you do it wrong. So then how do you do it right.
First you decide who the generator is for. Is this for end users. Is this for anybody to use? If it is you loose. For 38 years people have tried and failed. Visual Basic is close, but it is not going to save this world. It must not be easy to solve this problem, or someone would have done it. So what do you do. The answer is you need shoes for the shoemakers children. You need tools for the programmers. Not the crackers. Tools for the best programmers in the world. Now what is wrong with many of the generators out there. The answer is flexibility and speed are lacking. Can you see the module in 10 seconds. The right module? Can you make the change and test it on the spot? Where are the templates. Can you change them? Can you read the code. If you make a change to the source code, but then regenerate, do you loose your change? Not good. How can you fix that. It is so easy. You must have copy libraries and include files in the templets. If you have to have a two line edit you put it there. Now you add a field or even a file and fields to the screen and regenerate. There you have it. Your change is not gone. There is no other way. Honest. Think about it. I've thought about it all my life. If there was any other way, I think I'd know it.
Now you use the process of cloning. You need to be clear that the only thing you can do is view without change, add, change and delete. But it is even way easier than that. Think about it. You only have to programmatically do a change and delete. It it's not there it is an add. It's automatic.
Every program is the same. That's good for you. It's good for them. (I don't like to call them users for fear they will call me a pusher or a drug dealer. They are the employees and contractors that need the system to be able to do their jobs.)
You decide the things you need to have done and a wonderful thing happens. All the things are the same. Don't belive me? Think about it this way. The biggest problem with the systems being build today is they don't work the same way. They don't have exactly the same look and feel everywhere. That's a big problem. Huge. How do you fix it. Modules and cloning. Good for us, good for them. So your break up everything you do into the pieces you need.
The smartest design I've seen, in the last 30 years, was shown to me by a doctor. And from that design sprung an incredibility wonderful system. What he did then is exactly what you do now. You make a plan. A detailed written plan. And then you build it just like you would build a house.
The pieces are all the same. You say no? How is a vendor master any different than a customer master? They are the same. Name addresss city state zip phones. Oh my gosh! One has a credit limit on how much they can run up on recievables. How is that any defferent then the credit limit you may have with the vendor that says that is how much you can spend. Wouldn't you want your customer master maintance to work the same way your vendor master maintence did. Of course you would. But what about banks, employees, friends and family, your Christmas card list. What is the best way to handle those things.
Ok. So you have vendor invoices and customer invoice. Or patients, or dealers or whatever brings you money. They may be ebills but same thing. What about a retail point of sale receipt, or a pick ticket or a bill of lading or a purchase order or an order acknowledgement or a quote. how are these any different. There are not really different. In fact they are exactly the same. But do we build them the same way. Well I can tell you a lot of people are not doing that.. Wrong. You build them all the same way.
So how do you solve this problem about building very large systems with hundreds of files with ten to fifty fields in each. Well the answer is with a little thought. If there are going end up being more than 500 reports or 5000, you need to be ready.
Of course you need screen generators, and of course you need editors and of course you need a message control system with transaction based routing and menus in systems that are fast and easy to build and change and maintain. Where do you get these kinds of things? Do you write your own? Buy them? Get them at Zend or Fresh Meat or Source Forge?. That's all good. But what is a network definition language and why would you even need it. The answer is simply you do not need it, but I do.
So hang in there and please keep coming back. I'm doing it all right here. And then for my customer's to use in their business.