|
|
|
You'll find vast numbers of books, documentation, and resources on the Web that
often address your particular situation specifically. You'll also find
general books on, for example, Linux administration. The knowledge tools are
out there for those who want to adapt their current proprietary systems to a
more open posture.
This listing will change as new resources are discovered. We start with free
downloads of some of the most important technologies for platform-independent
computing. Books and other paid resources are listed below.
- Downloads (free unless otherwise noted)
- Recommended Books
($linked
to Amazon.com$)
- Linux Books
- Perl Books
- JavaScript Books
- XML Books
- Other Books & Videos
More soon...
Open source consultants, in general, like to play with their
cards stuck to their foreheads (ok, sometimes on their T-shirts). They will be
more than happy to sell you some fish in a bind, but they're just as
prepared
to teach you how to catch your own.
Open source communities are by their nature about leveraging
their craft, the craft they love, in ways that will most help others.
Browser based applications are simply programs that run on web-servers or
browsers and that use a web-browser to present their user interface.
Browser based applications, like any application, can be classified based on
their complexity and information storage requirements.
Simple Database Utilities
Most of the spreadsheet utilities you use in your business that have macros
incorporated into them probably fit into this category. Some examples
of online utilities that fall into this category include
- Our Job Track Utility
This simple job scheduling tool provides a good example
of the kinds of tasks offices would commonly
adapt
from manual
procedures into clumsy spreadsheet/macro systems.
This
application, for example, was
written to replace a spreadsheet system
used by a business with four locations. If you try this
utility, imagine what it would have been like as
a spreadsheet and you may get an idea of why
there is so much to gain by switching from spreadsheet utilities
to web-based systems. Just to give you an example of what it
was like before: whenever
the warehouse guys received some portion of an order at their
location, they would have to call the office
location where
the spreadsheet was maintained so that it could be updated.
The entire spreadsheet with any changes that had been made
the day before would be emailed to them as an attachment each
morning.
- Forums (Bulletin Boards)
This is probably one of the most familiar simple database
utilities on the web. It probably isn't a great example
since there is really no analog to this kind of application
in the world of spreadsheets and document forms. On the
other hand, it makes the point that open systems open up
a whole new world of possibilities to the organization that
adopts them.
Simple Utilities That Don't Require Storage
There are a variety of tasks which perform relatively complex calculations on
a small number of input variables. Tools to perform these tasks can require
users to enter the required variables each time they use the tool, so no
storage is required. Because these require no storage, they can
be implemented completely as client-side scripts, which are
processes written completely in JavaScript, so they run locally on the browser
without using any bandwidth or server processing power. They can also be
written as server based apps. Some examples of this kind of application
include.
- Conversion and transformation utilities
such as our
JavaScript Compressor (JSC)
which transforms user input.
It takes a user's uncompressed JavaScript code as
input, and reduces its size by removing comments
and extra space. It is written entirely in
JavaScript and utilizes local processing power.
CSV to XML,
and
CSV to JavaScript converters
on the other hand,
convert
Comma Separated Value (CSV)
formatted files from a user's spreadsheet
or accounting programs into XML or JavaScript array files.
These
could both have been written in JavaScript to run
entirely on the browser because no information needs
to be stored. These examples however, were written as server based
utilities. This demonstrates the flexibility you have in
choosing where applications run.
- Data analysis and visualization utilities
These are often called calculators or what-if sheets. They
can be quickly
written in JavaScript to make calculations that are
performed often. Sometimes they replace paper based look-up
charts, such as amortization, or engineering tables.
There are many examples of JavaScript calculator programs on
the Web for any kind of calculation you can think of. They
include calculations for such things as
Ocean wave propagation,
as well as all sorts of
medical calculations.
Perhaps you'd like to perform some
flywheel energy storage calculations to test
a great idea you just had for a better hybrid car.
You may also choose from many different
mortgage calulators,
car cost calculators,
and
calorie calculators for the diet conscious.
This should give you
some idea of the types of day-to-day problems these simple
utilities can solve. Oh, by the way, hospitals aren't the
only ones making extensive use of these,
NASA loves them too.
Data visualization often goes hand-in-hand with
calculation functions. These can be written in JavaScript
when the visualization is relatively simple, such as bar
charts that can be approximated using tables, and number
manipulations that are exploded or slowed down to show
the process. More complex visualizations such as 3-D
charts, Pie charts, etc. will have to be done on the
server or with Java.
- Animation and visual information delivery
Mostly just used to present static data in eye-catching
ways, e.g.
But these locally accessed JavaScripts can be combined
in very synergetic ways with server scripts to display
dynamically updated information, such as news scripts, and
stock tickers on statically loaded pages. They can be
written to extend cross-platform functionality to even
the most proprietary of browsers.
Flash:
One of the best uses for animation is the
presentation of animated pictures to clarify procedures,
such as product
training lessons, or work procedures.
such animations
can reduce the steepness
of learning curves for everybody. A
technology
called Flash can greatly reduce the amount
of time and effort required to produce
these types of animations. Because of this Flash should be considered
when there is a real need even though it is proprietary. One
word of caution though, there
is a phenomenon called "flashterbation" out there
which is the process of producing large flash animations
just because they
can be done. People over age 16 or 17 in general,
would rather not take the time
required to watch these
no matter how "cool" they are. Of course, no rule
is without
exception.
Java:
Is a great P-code interpreter system from Sun that
aims to be a completely platform independent environment
so that applications can be written and compiled once and run
everywhere (much like Perl). It includes advanced storage
management
and security features which make it ideal for many enterprise
applications. Is it open?
I believe Sun wants it to be, but many have tried to
add their own proprietary extension to it, so Sun
has had to hold onto some control in order to fend off these
attempts. In my opinion this is a very good thing.
But
what if Sun gets bought out by some folk who aren't
such altruists?
Utilities That Employ Simple Storage to Improve Functionality
These are generally simple utilities as above that perhaps store the last set
of variables plugged into them, or that store each user's preferred starting
variables. [Do you have any example suggestions?]
Complex Enterprise Database Utilities
Most new enterprise level application being produced today are being produced
entirely as web-based applications. Makers of large, well known systems that
were around before the web have put browser-based front-ends (user interfaces)
on their systems and are doing new development entirely in web-centric ways.
Many large applications have been written as pure web-based systems, they
include: CRM (Customer Relationship Management) systems, ERP (Enterprise
Resource Planning) systems, Call Center Management systems, MRP (Manufacturing
Resource Management) systems, Accounting systems of every kind, Workforce
Management systems, Knowledge Management systems, Document Management systems,
and much much more. This list could go on for a very long time in fact.
"Have nothing in your houses that you do not know
to be useful or believe to be beautiful"
-- William Morris
|
A negative statement will sometimes express an idea better than a positive one.
The above quote for example, aside from expressing a philosophy that underpins
many programmers' development styles, also speaks well to the subject of this
paper.
- Avoid adopting new open technology if it does
not clearly
demonstrate an ability to increase operating efficiency, access,
or usability.
Whenever something is described as "the next big thing" by
someone who can't actually tell you, in concise terms, what
it is,
that's probably a good indicator that a sales and marketing type
had a considerable amount of input when making the assessment.
You'll see it stated in many different ways; "it means
different things to different people" is one of my personal
favorites.
Browser-based applications, written say, in Perl, will run on
any web-server with CGI/Perl installed. It's not "slick"
it's not "sexy", it is extremely easy to implement and
produces huge leaping advances in productivity compared to the
technology that was in use before it (macros, spreadsheets, and
bloated applications running on
PCs to access data stored on the LAN).
- Avoid adopting new proprietary technology if it does not
clearly demonstrate
huge advantages over
existing non-proprietary solutions.
There are very real costs associated with locking your systems into
a single provider's solutions. Some of these costs are often
improperly reported in trade journals as the cost of
switching to
the open, platform-independent solution. Don't be fooled.
If you do have to
switch
sometime in the future, it will be because staying with the proprietary
system will be demonstrably less profitable or more risky than
the cost of switching. These costs would not have been incurred if
the proprietary system were not deployed in the first place. Therefore
the cost of switching away from a proprietary system should
be associated with the decision to adopt such a system
in the first place.
- Treat proprietary technology that is "based
on open standards" as you would pure proprietary technology.
Anything that is designed first to "lock in" a customer base
is proprietary, even if it is based on open, platform-independent
standards and technologies. The rules for pure proprietary technology
discussed above should be applied with equal conviction to this class
of technology.
- Look out for a new oxymoron:
proprietary-standards
As of this writing a company called webMethods holds a patent
on some of the
in the SOAP 1.2 "standard". They
are refusing
to give up their right to collect royalties on that patent from
anyone implementing SOAP 1.2.
This new policy of the W3C to allow patented, proprietary, technology
that will require royalties to be collected is ill conceived.
It produces minimal
returns for the salesmen at the companies who collect royalties
from these supposedly open standards, while risking
maximum damage to the information industry in general, and to
the Internet specifically.
Those who feel an obligation to protect
their industry must choose their battles wisely, but should
try to avoid these new marketing devices whenever possible.
- Cautiously, slowly, but deliberately pull back from
consultants who are as dependent on a single provider
as you are.
If you are (for example) a Microsoft shop, you need
consultants who have wrapped themselves in the Microsoft banner,
using all the Microsoft provided tools and educational materials.
They have honed their Microsoft skills to a sharp, efficient point.
The problem with these consultants is that they often
accept the Microsoft "way" without
question in return for the time that would have been required to
gain a truly platform-independent perspective. They will be
truly convinced, for example, that the browser applications they
are building --with Microsoft tools, using Win32 dependent
DLL calls, and requiring Internet-Explorer(I.E.)-- are
platform-independent because they
run on XP, NT, and 200x platforms.
If you are a Windows dependent shop you can't simply turn
away from this type of consultant. But you can recognize
their limitations.
You can also look for consultants who understand
and are comfortable working in the Microsoft "world"
but who
are equally comfortable producing true platform-independent
solutions. These are much rarer than those who have "drank
the Kool-aid". Don't value such consultants because
they are rare though,
value them more highly because
they are more valuable to your company.
There are plenty of groups on the web dedicated to Microsoft bashing.
This article will not be proselytizing for their cause.
In my opinion as someone who's old enough to remember the halcyon days [3] of computing; dirty tricks
or not, Microsoft grew to their current size and market strength because they
sold 'decent' software at reasonable prices. Instead of selling buggy
word-processing systems to a few law firms and medical centers for $20,000 each
(about $45K in 2004 dollars), they had the vision, long before computers were
common in households [1], that
better software could be delivered at much better prices if it were delivered
in quantity.
So when this article says that Microsoft is the McDonald's of software, it does
not say it with contempt, as you might expect from the church of the MS
bashers, but with great respect. Though I'm having trouble warming up to his
"over-the-top" partner, I place Bill Gates in the same league and
company as Ray Kroc, Sam & Bud Walton, and others who saw their fortunes in
improving the lot of the common man.
Does that mean we're members of the church of everything Microsoft here at
Creativyst? No, not at all. Our web servers are Apache running on Linux boxes
and, as you can see, though we often perform work in Visual Basic for our
clients, we prefer platform-independent standards like, Perl, C, and even
JavaScript.
And that is the point of this article. We do not prefer Perl to Visual Basic
because of any religious considerations. We prefer it because a script written
in Perl with an HTML front-end will generally run the same on any platform,
whether it is Windows, Mac, Linux, AS/400, or even main frames. Perl was not
produced to protect any large corporation's business and marketing strategy.
It's there to allow developers to write programs that anyone can
use from anywhere. Not just people who have purchased one particular company's
platform.
While this article mentions Microsoft often, that's only because they are the
overwhelmingly dominant factor in the IT world today. I appeal to all of you
from those other churches of thought to consider your own reality. Most of the
other companies are playing by the same rules; producing platforms and
frameworks that are designed first to protect their corporate
marketing strategy, and second to run usable software.
With this understanding, this paper has tried to explore realistic,
cost-effective ways to turn away from the hype and religious zeal. This
article then, is about finding a new way to think about our craft as IT
professionals. We can start by resolving not to bash anybody.
This article is © Copyright, Creativyst, Inc. 2002 - 2006 ALL RIGHTS
RESERVED.
Links to this article are always welcome.
However, you may not copy, modify, or
distribute this work without first obtaining express written permission
from Creativyst, Inc. Those wishing to obtain permission to distribute this
article or derivatives in any form should
contact Creativyst.
Permissions printed over any code, DTD, or schema files are supported as our
permission statement for those constructs.
Notes:
1. A few geeks, some computer clubs, and, of course, those lawyer's
offices. (back)
2. PHP is also a good choice but it has not been ported to nearly as
many platforms as Perl has.(back)
3. An eight bit processor called the Z-80
was king, Saturday Night Live was funny (and ahem, live), and Gates
publicly wondered why anyone would ever need more than 640K of RAM.
(back)
|
|
