I tell ya, I'm thoroughly amazed at how poorly the time-honored Web browser and operating systems of this generation support their users. I mean, seriously, hours of installation on Windows 8 every month, plus arbitrary wiping of home pages by Firefox: with applications like this, who needs malware?
0 Comments
I'm amazed at the amount of time people now dedicate solely to installing security updates from these guys.
With so little CPU time left for actually using the machine, I'm just baffled. Why do people own Windows PCs any more? It's been decades since I've tackled this question for people. Most of the people I work with already realize that Domino is famous for producing results. As a developer though, I can't leave it there.
There are clear reasons why Domino remains, technically, a better platform than any other. I'm serious, too. There are weaknesses in Domino, yes, but they don't hold a candle to some of the silliness that passes for server software in the world today. Now, mindya, I've seen platforms come & go since 1980. I'm in the business ... forever, to young developers. My first encounter with software silliness came during the 4GL and o-o crazes of the 1980s: you've probably heard of one, and not the other. 4GL produced SQL, but was generally a failure. o-o produced ... well, modern programming languages, and was generally hailed as a success. Yet we still have similar problems with software and its development today. It was with this jaded experience that I took my experience with both these, and spacecraft telemetry and controls systems into my first programming encounter with Lotus Notes -- or as the server is known now, IBM Domino. It seemed immensely arcane when I first programmed to Notes in the early 90's. However, I realized quickly how useful the system was. Applications, however arcane and custom, were relatively small, and were quick to complete. It was completely backward from the way I had learned it -- arcane stuff's supposed to be too slow to program. But it wasn't. Later versions of Notes & Domino made the arcane programming simpler. The object model clarified and crossed language boundaries -- and was particularly unpleasant in Java due to some early mistakes, but has been overcome recently by the sophisticated, longstanding developer community (see http://openntf.org for more info) . But I was constantly captivated by the wonder over why my original encounters with the arcane C API in Lotus Notes, why that encounter went so well. It was the data structure. The Notes data structure inspired object-oriented database designs before they existed. It's reiterated in document models throughout Web browsers and servers today. And it's simple and straightforward to expand whenever the developer finds the need: supporting upgrades, or architecture changes, or ... really whatever the developer needs. SQL admins will remark in disgust at this point. But data structures and file structures developers, take notice: the data structure is quick to develop. Often people ask me about "migrating to another platform" as a litmus test of platform flexibility. And yes, the test of a good data system is whether its data can be obtained readily enough to migrate it.
But that's not really true of a good component system. Because if it has the best components -- other component systems are inferior. As a data for-instance: Oracle. I've found Oracle well, arcane and unpleasant when it comes to data migration. I'm not entirely sure why. Maybe it's the utilities that Oracle provides, with its arcane language. Maybe it's that BLOBs, CLOBs, VARCHAR, and VARCHAR2 all have to be changed. And they're most often, text and images. And what is an application without text an images? Oracle Data Migration isn't a lot of fun. But some data systems are downright simple to migrate. They export data in XML, export their data structures in SQL & DDL. That's great. It works. It works well. And it allows you to leverage data export into data communication. The best of data systems make it easy to communicate. Because what's data without communication? It's a trap. All well & good. Data systems and structure are immensely useful to communicate. But component systems? Well, they're best when it's more costly to migrate them. Why? Well, take the building example. You have a steel building, and now you want brick & mortar. How much of the steel building will remain? Do you really want to communicate your components into another building? It doesn't make any sense, does it. A steel building was probably cost effective when you set it up. And now you want brick & mortar. All well & good, that's what you want. But you're not going to transmute steel into mortar. And your software alchemist isn't going to, either. IBM's Domino component model is the same. It's not built to lowest common denominator. It's actually built to fairly high sophistication. So you're going to spend a lot transmuting its advantages onto another platform. But the data ... well, DB2 and Domino are both pretty easy when it comes to extracting data. So I often answer this way: 1. If you want to migrate data then sure, IBM, particularly Domino, can migrate data anywhere you want. 2. But if you want to migrate your code ... um ... you barely coded anything. It's mostly components. So migrating what you coded is pointless. What you wrote was only the mortar in a brick wall of components. That's why it was so inexpensive to get going so fast. And that's why it's always so costly to go to another system. In an earlier post, I mentioned businesses need to be careful of allowing just any selection of software, platform, or technology. The reason for so many technologies is that there's a lot of ignorance of what you need from software development technology. And so sales abound.
Ultimately, if you have special needs this post is not for you (and everyone thinks they have special needs 'til the market proves they're not worth a plug nickel). More important than special needs, you need productive needs -- needs which will keep you from having to engage in constant development of new software that does the same thing for you, on the latest flashy platform. In business you have needs to get a task done now; and to get a task done for a long time into the future. You need software that'll run for five, ten years without demanding you replace it. Now, for generic software like office utility products -- word processors, spreadsheets -- you know how that works. Word processing is the same functional need for a massive part of the world. Everybody pays part of it. The software is produced for the masses. The seller determines upgrades based on their idea of keeping ahead of competitors. Although, there's precious little competition nowadays. There's due deference to backward compatibility, and it's enough to get by to the next upgrade. But how do you achieve productive improvement for non-generic software? 1. You pay developers to make the entire thing. And pay 'em to maintain custom code, til you run out of money. Dang right, it's expensive. Every wheel has been reinvented. (And don't get me started about Struts, Spring, etc. -- when as much code is needed to use an architecture as it takes to develop the same wheel, you've not really gained anything.) 2. You buy a platform which gets you really good pieces of the application (components) -- you can see the pieces and know pretty-much what data you want to drop into those pieces. Then your developers assemble it into something you want. Remember the erector sets, or even Lego models you built as a kid? You can think of it much like a "kit-box" type of configuration. All the useful pieces exist in the box for you to assemble what you want: access control, data services, application components (multi-record handling, individual record handling, data field handling, API, etc.) Frankly, Java APIs & frameworks (like Spring); Javascript Frameworks (like DoJo); and even component systems (like JSFs) are all pitched as if they're exactly this. They aren't. Normally you have to ask quite a bit more about a platform, to assure yourself you're not being handed too much custom work to do. Also, something new and different in the kit-box: you decide you want something custom. The platform allows for custom additions. Finally, it's gotta have a big footprint that's covered, solely by the system. Again, this is not a monolithic, takeover type of system. But the API for it has to be extensive. It's normally reasonably possible to tell if you have a full-featured system. My rule of thumb is to ask about the access control API, for instance. If you have a nice, full-featured system, you can control accesses using programs calling the API, down to the record level, in about 20-50 lines of code. But that's my rule of thumb. Oracle and most database products provide all this, pretty clearly. As long as you're willing to open your database server to the client you're talking to, you can get this set up. Still, it takes some work. Offering users the ability to specify their own access controls on Oracle records, that can be, ah, interesting. I'm not completely familiar with the frontends Oracle offers, either. Being Oracle, they're not going to want to play well with other data systems you might want to migrate to. There's also that disconcerting 4000-byte limit. Extensibility has never been Oracle's strong suit. Microsoft does offer a lot of this stuff. I think the components are pretty slim pickings, so the cost of code development is still going to be pretty high. But it can be done. It has always seemed to me that Microsoft has made such small building blocks, that it takes a lot of coding glue to put 'em together. IBM though, it has some pretty strong background here. Its JSF component model in Domino XPages offers a whole lot of component flexibility. Integration with data sources from the server or from a specialized client, both work. Scripting's available in so many different places that, where you need it, it's likely you can code it. But most significant -- many times you're just scripting around a few components. So the cost of development drops dramatically. Because you're not writing code: you're assembling components. I waited, and waited, and waited for Windows 8 to stop trying to alternately install, then configure, then uninstall their crap. Hours later, I got in.
I disabled everything. MSCONFIG.EXE -- Systems tab. -- Disable all. Apply & close & restart. Clearly Microsoft doesnt know WTF they're doing with their OS. And it shows. I've no idea what mess this causes. I don't give a crap either. When it comes hammering to a close, I'll install Linux and be rid of this stupidity they loosely call an operating system. Windows is clearly dead, if nobody is screaming aloud over this catastrophe. Here I am with a new machine. I think Microsoft has taken it upon themselves to install updates three times. And this third time has been a failure.
Each time it's taken a half hour wait to get the installs, and this time, failure took as long to revert the update as it took to install. Poorly. It confirms to me that I should never buy Microsoft products again. Web Servers have seemed to end users like the key to providing data. But they're not.
Most businesses are very familiar with the high cost of getting and providing data through a Web Server. You pay dues to your developers, every time. "Web services? Well shure!" Only, you're paying developers to create, then update, that Web Service. The reason for this is that the Web Service is a piece of code. It's coded. So it requires a software developer provide support. For the life of the code. Now, yes, you can get some low level of support from a cloud service. That works. You're paying a subscription, and you give up certain rights to your data. Yep, this is all very familiar to someone who's been automating commercial operations for decades. As a small company, you can certainly buy offtheshelf application services, soup-to-nuts, comprehensive (or so they say) services for what every business is doing. You need financial compliance, legal compliance, and so on. The sum of all this software reads like a laundry list of government laws ... because that's what it is. As your company grows, though ... what does your business need? How is your business special? How does it handle your product or services specially, to make you competitive? If your business has a real need to be especially good at handling your product, or customer data, or service, then your business could stand automation. I've done quite a few of these things. I've done automated loan payment monitoring systems, where you need to know when loan repayments fall out of certain guidelines critical to your business. I've done automated scheduling systems, where you're scheduling time with lots of specialties in one bloc, so your customer gets once convenient appointment and everyone's there at appropriate time slots within. These are the kinds of things no standard software will attempt -- because they're not easy, and not generic enough for everyone to use. But once you need to do this kind of stuff -- your data may well be trapped in someone else's cloud service. It's why you need application services at the Web level, sure. But you really need application services that actually provide services everyone realizes, ultimately, that they need. Access control. Data services. Integration services. And of course, sophisticated, mid-level building blocks of applications. Anyone can tell you they have these capabilities. But then, you're trusting someone who won't be there. Or trusting a brand name. Neither is reality. With about an hour's preparation t's actually possible to get a small handle on what you need under the hood, to see if a product fills the need. And I should be able to get to that with my next post. Startup .... then wait, wait, wait for all the security updates.
Is there really that much wrong with the software, that it takes 10 minutes to update every time I have to deal with this sucky OS? What's critical about software is what needs doing, and only then how pretty it communicates.1/5/2014 After decades writing, designing, documenting, and diagnosing software, I guess it's time I sat and wrote what I've found out about it. It's not that I feel so completely capable. I don't I'm not good at writing. But I guess, I've tired of watching people propose more and more outlandish things for developers to attempt.
Development strategies seem to have focused on the architecture. Structured programming was fine, but then object orientation tried to compartmentalize on all the complexity there. Which was fine, but for a smaller subset of development. 4th Gen languages tried to simplify further, but fell by the wayside doing so. UML has has some better success at visualizing the software, but it doesn't seem to have dealt with its complexity. MVC(D) models restricted themselves to the browser model of doing things, again focusing on only a subset of the development that has to be done to get things done. And really, after all -- isn't that what software should do? Get things done? Yet we don't focus on that. We focus today on how we're going to stuff the request to get things done down to the component that gets things done. In doing so, we spend a lot of time communicating the request. But not much time on the work. There are admittedly some great systems for getting this communication across. My particular preference is for IBM Domino. It allows me to spend far less time on the packaging and far more time on the product. But even then, it's easy to get distracted into all the facilities for making a good package. Don't mistake me. It's kind of silly to say you don't need good communication between client and server. You do. You need it badly. But that packaging had better be easy to replicate & reuse for any application, or it's useless. We can't afford to rewrite an interface for every application. It's simply too costly. So I would recommend you find a package that costs a minimum of code and effort to create a user interface. Plus a minimum of effort to send communications to your model. You all know MVC(D) ... that's the VC part of it. You should be able to minimize your time there. It simply shouldn't be hard or long or take time for these pieces. If it does, you're not getting the customer's job done. |
AuthorMikey is a software developer, mechanical engineer, linguistics hobbyist, and politically active ...meaning he'll write about just about anything. Archives
March 2015
Categories |