A lot standard exist; whether they are useful depends on the platform you are targeting and/or the architecture of your product. You've shared nothing about either, so I'll just point you at some general standards that you may find helpful, or as sample design patterns that may bring you closer to your goal.
Check out the OSD specification at the Web Consortium's main site. An XML-based software description language, it's raison d'etre is electronic delivery of software. I know Microsoft used the format at one point, and I know of at least one other company that architected their product to use the OSD language for software installation as well.
An alternative to the OSD model is Sun's Java Web Start, tailored to automatic installation of software for the Java platform.
If you still need to roll your own, may I suggest that you consider the package format used in the Debian GNU/Linux distribution as a good design pattern to follow? Because the format exposes extensive amounts of meta-data in each package, a complete array of tools exist to automatically resolve, download, and install dependencies--one of the major benefits of using Debian as a Linux platform.
Finally, if you are a member of the ACM, their online Digital Library will no doubt have extensive information, as would the IEEE online resources (again, membership required). A free resource similar to those of the ACM and IEEE that I often find helpful is Citeseer.
Hope some of those help!
Just hit the link and it's gone. Only a page indicating that the paper was not yet ready for public consumption.
Even though I suspect I would disagree with the argument that DRM can be beneficial for the end-user, I liked that someone wanted to "play nicely" by using open source.
Judging by the tone of most postings so far, I'm guessing nobody else read it either. Pity, because there could have been an intelligent discussion about this paper.
On my Linux installation, there are several jars in/usr/local/OpenOffice.org1.0/classes. Enabling Java to interoperate with the Universal Network Object (UNO) model that sits at the core of OpenOffice was always a key part of their architecture.
So, the use of Java isn't really news, and any messaging around Java should just be seen as Marketing exploiting the fact that yes, indeed, parts are written in Java.
Let's look at the 802.11x market: the little local guys who used to pull Cat 5 for companies are probably sufferring, because a lot of companies are moving to 802.11x.
Wireless home networks (and public ones, such as at Starbuck's or public parks) are ruining the chances of the major equipment manufacturers to move their existing product lines into homes.
Those same networks are causing broadband providers to fuss about "bandwidth sharing" as if it were a capital offense.
Every week new technologies are announced that extend the reach (and reliability) of wireless networks. Five years ago, only the adventurous would connect a corporate campus using only wireless. Now wireless MANs can connect an entire city.
Let's take another wireless technology, that which makes cellphones possible. AT&T, the grandfather of modern telecommunications, is practically out of the long-distance market. It's wireless division has been going gangbusters for the last 5 years. That means AT&T, who built most of the land-lines in the world, including the last mile to most homes, is still making great money, but not off those decades of investment in cabling.
Oh, one more: we live in a security conscious world. Fear of weak physical infrastructure means the US Government (and military) is continualy looking for ways to remove single points of failure from essential public or strategic infrastructure.
Add it all up? Investment in physical telecom infrastructure is sure loser in the long-term. If Gates wants to "own" the land-lines, so be it. With the continued growth (and interest) in wireless technology, using wires to connect people and machines will become old-fashioned and a specialty need. One can cut a trunk cable to block communications, but you have to be good to block every wireless communication technology under the sun.
Sure, all that investment in last mile cabling and undersea pathways and trans-national networks won't rot overnight. There may always be a need for such networks, but only as a specialty. As time goes on, the need or such networks will be reduced, as the continued evolution of cheap, effective wireless technology makes all of it seem antiquated.
So even if I was paranoid enough to believe Bill Gates could pull off such a feat as owning the Internet (how many billion in cash does Microsoft have right now?), it may not matter for very long.
I respectfully disagree: it's *still* all about algorithms! And, BTW, what comes next I do not wish to aim at you personnaly. Just ignore the rest of this if I'm taking you (and me!) too seriously.;)
<rant>
I've been in IT for over 10 years, and it seems so many times you find people in IT who will happily blather on about the "Visitor" pattern or another such topic (a useful pattern, to be sure), but who for the life of them can't remember any of the basic sort algorithms. It kills me; algorithms are still fundamental component of our toolkit. We can't ignore them
</rant>
<useful_contribution> Are patterns nothing more than new algorithms expressed more conceptually, with natural language instead of a programming language? Sure, a pattern does not have the same strict criteria of finite number of steps, complete in finite time, must have output, etc., but just as algorithms (and Donald Knuth's work) are guides to implementation, are patterns not also guides?
Typically, one can express an algorithm in some form of pseudo-programming language. By choosing a programming language, we are choosing a form of expression with deep mathematical roots (think Godel, Turing, Church, etc.). What are patterns, but guides that we simply have not translated into a pseudo-language template for implementation? The Visitor pattern is a great example: one can express the pattern in a number of languages, quite simply.
So, perhaps we incorrectly differentiate between patterns and algorithms based purely on the language of expression. Perhaps instead we should look for that new language, or expand an old programming language, that can capture the ideas of patterns more precisely and inline in the same code as those code artifacts we have traditionally called algorithms.
And with the expressive power of this new language, what would programming be like? </useful_contribution>
Last time I looked at the OS/2 API (many, many years ago), I walked away with the thought that it was overdone. As an example: the CreateProcess function call had something like 10 parameters!!! It seemed like a function such as that should be simple, since invariably it would be called a lot (e.g., fork!). Of course, then there is the perspective that if there was a simpler function, I could have found it if there developer documentation had been friendlier?
I subscribe to the Unix philosophy of functions doing 1 thing and doing it very well. The amount of overloading on those API calls (due to all the flags and options passed in) could break the bank. And there's a lot of evidence that a simpler design leads to longer-lasting software: Linux, to name just one.
I always thought the complexity of OS/2's APIs scared away developers from the platform. At the time, Win 3.1 (aka Win16 API) had a much simpler API, albeit a much less powerful platform. Heck, another example of the value of simple APIs might have been Win16, since it did last for a long time and introduce a lot of programmers to WIMP programming.
Oddly, the Win32 API introduced by Windows NT echoed OS/2's complexity. CreateProcess still has 10 arguments! So how did it survive? Microsoft marketing, I guess. Or the complexity of the API had nothing to do with OS/2's demise....
I do not follow *BSD nearly enough to make this kind of observation, but I thought I recalled that when Universal Virtual Memory was rolled into NetBSD, it was widely regarded as a good design. Anybody with much more VM design knowledge able to comment on how suitable a design like that one (or other well-regarded VM design from other Unixes) would be for the Linux kernel?
Architect is a temporary role
on
Coder or Architect?
·
· Score: 4, Insightful
As much as I wish I could assure you that you can be an architect for the rest of your career, from my own experience I have to advise you to do otherwise. Like many who are responding to this article, I, too, have been an architect.
Currently, I work at a high-profile software start-up and guess what? No one has the official role of architect. We have a very experienced, very successful development and management team, too; apparently, they do not see granting someone the title "architect" to be beneficial to their success. For the trolls out there: the lack of an official architect will not be a reason a company like mine fails.
Others replying to your article have mentioned that it is important to like what you do. I concur, and that will always be the best compass for your career. But, having said that, I think the role of architect may indicate that you are currently in an anomalous position: chances are good you may merely be smarter or more capable of viewing the big picture than everyone around you. However, what if you were in a different company, or working on a different team? You may find that you are just barely keeping up. I contend that in a different environment, with others who may have skills to match or exceed your own, you may actually be more succesful as a developer than an architect. Therefore, don't pigeonhole yourself unnecessarily.
Further, nearly every successful architect that I have ever seen eventually succumbs to the need to become a manager. It's just part of the natural order of business: in a good company, those who lead and mentor need to become managers because they are best suited to tending to others, to steering the ship. That doesn't mean every manager is good as a leader or mentor (I've met my share of pointy-haired bosses, too), but invariably every good architect finds limits to their influence as an architect--and discovers that bearing a managerial title can actually increase their effectiveness.
Or consider another dimension: maybe it's not what role you should play (developer or architect or manager), but perhaps in what type of industry you work. Architects can often be much happier as a consultant, either for someone else's firm or their own; it is difficult to remain satisfied in a staid, old-line firm where 70% of the challenge is keeping ahead of maintenance.
Having only relatively recently passed through the same dilemma you face, I encourage you to understand the simplicity of the choices as you perceive them to be contextual. I, for example, chose to move on from a role as an architect and individual contributor, to accept a role as a director and department head because I understand that I had too many skills (such as a knowledge of the business, how to work with customers, and project management) that would have evaporated had I not made the transition. Of course, there are other skills I now have the chance to learn, too: how to *really* please customers, not just once, but on a regular basis; how to design an organization; how to architect systems for an entire company rather than for a single application; and (trickiest of all) to motivate, encourage, and develop the careers of my staff, especially when each one of them may have an inkling of their own desire to be an architect!;)
Ultimately, though, I did make my choice because I understand that I can apply the same skills that I honed as an architect (and many others I learned along the way, including some new ones), but on a much larger canvas. It would be a loss to yourself and to both your current and future companies if you only allowed yourself to be an architect. Strive for those positions that allow you to have a stronger impact, if you are really the right one to be making that impact. My decision to become a manager hasn't at all changed who I am or what I like to do. I still architect a great deal, frequently when my own architect is elsewhere deployed.
Remember: try to understand your dilemma may be contextual; that continuing to be happy about what you do is the best guide; and that you owe it your peers to impact your organization in a way commensurate with your actual skill. You are just at the beginning of your career: just wait till you see what happens next.
A big advantage of XML schemas over DTDs, besides providing a richer language to express the structure of a document, is this: a schema is a valid XML document itself. DTDs have their own syntax that does NOT match XML; schemas ensure that you only need 1 type of parser, an XML parser.
Please don't confuse profit with revenue: the reason consulting companies are either going belly-up or shedding their masses is not really about profits. It's just that the revenue stream dried up.
The profit margins on consulting aren't too bad. Think about it: one of the biggest expenses are the expenses of the consultants themselves (travel, hotel, etc.), and all of that is paid for by the client. In some cases, that is often priced at 10-20% of fees--so that's an extra 10-20% *on top of fees* that firms collect to cover their bottom line.
The real problem with consultants (and why Wall Street traditionally shunned them, until the New Economy happened) is the variability of their business. Sure, during the boom of the Net years and Y2K, they were hiring like mad and making money hand over fist, but it's big consulting contracts that get cut first when the belts start tightening.
Having said that, the good firms know how to tailor their business to match the economy. For example, 5 years ago, the trend towards "re-engineering" (aka downizing) was all the rage, and consultants made money by convincing their clients they could *save* them money. Then the Internet thing happened, and they convinced their clients they could help *make* them money.
I've skipped a few fads (supply chain management, ERP, etc.), but you get the gist: consultants make their money through 1 of the 2 approaches above, making or saving their clients money. Give the consulting firm a few quarters to recover from the shift in economic tides, and you'll see them back in the game, this time with a new yet somehow "same ol'" message.
The creator of this language asserts that text is on the wrong medium for communicating program meaning. He implies that Eidola will enable a visual approach to describing programs.
Why the hell isn't he looking at UML?
I put that forward as a comparison, because a *lot* of people have spent time and energy developing the semantics of UML models, and they are beginning to offer a reasonably complete toolkit for describing programs and program behavior. And because UML is a language, it certainly does not dictate how you represent programs or how you use UML: it provides an existensive "vocabulary" for communication, and all it argues for is consistency of use.
Can someone send this guy a book on UML? Amazon ships up to Canada, doesn't it?
I've worked for lots of Fortune 500 companies, so I think I have a good handle on what a CIO does in traditional organizations that understand what the role of a CIO is.
A CIO, who ideally reports to the CEO, is responsible for all information technology that runs the company, all of the technology infrastructure. That means networks, servers, databases, third-party applications, programming staff, project managers, specialized consultants, etc.
A CIO spends much of her time managing a portfolio of projects, each one dedicated to a particular goal, whether it's upgrading the corporate desktops, installing new network equipment, or developing (in conjunction with consultants) a sexy new e-commerce application.
Typically, a CIO has 2 key direct reports: a Vice President of Operations, and a Vice President of Applications. The former maintains the network, the hardware, the data center, and other "static" portions of the CIO's domains, often reporting key metrics such as uptime, throughput, cycles used, etc. The latter oversees the design, development, deployment, and support of all applications throughout the enterprise. The latter emphasizes metrics for estimated time to completion, FTEs, etc.
For the last 10 to 15 years, CIOs have spent a lot of time fighting their way into the executive boardroom and getting the ear of the CEO. They have had to justify why they should report to a CEO rather than the CFO, as happens in some places, and why they can help the business strategically rather than provide mere operational support. Not an easy task, but CIOs appear to be getting their message out. And the longevity of the average CIO appears to be lengthening!
I, too, have a Speakeasy connection, which for me runs at 1.5M (or whatever their top speed). I've never measaured to see what bandwidth I really receive, but I don't think I'm being cheated--I know what a T1 feels like.
There are at least 2 advantages I have found to Speakeasy: their technical support *does* know what they are doing and can explain what's happening when there are network troubles (once in 6 months); and they are very liberal regarding what platforms can be connected to their network. At home I have a gateway router/firewall connected to Speakeasy, and behind that I have a hub with 2 machines hooked up, one Linux and one Windows 98. Very stable.
I originally had Bell Atlantic, but 1) they explicitly did not support Linux or the use of a router to connect multiple devices (Windows NT was barely tolerable to them), and 2) of the 3 months I had an account with them, I experienced an entire MONTH with no service. I spent approximatley 10-20 hours on the phone with their technical support (most of it on hold--3 hours one day), who clearly had *no* background in networking, and were unable to assist me. My best guess is they switched from having an open network to one that required PPPoE, but they didn't know that or what to do about it.
Actually, I don't think I'm confused. You've hit the nail on the head: why create a protocol in the *application* layer, when there are protocols that solve these problems in lower-level layers?
I'm sure there are good reasons to re-implement these in the application layer. But what are they?
I understand the limitations of HTTP (too many connections that are expensive to set up, no multiplexing of channels, not robust or consisent when handling errors, etc.) but why a new protocol--why not just use basic TCP or UDP sockets over IP? After all IP handles packet sizes, TCP manages packet retransmissions, etc. For protocols that don't need TCP services there's UDP.
After all, HTTP has only become overloaded because that's the one protocol that was pretty much guaranteed to make it through everyone's firewall, whether the firewall just blocked ports or actually sniffed packets. It would make sense to have a new meta-protocol, on a standard port or set of ports, so that true Net applications can communicate even through firewalls, but...does it justify a whole new protocol?
I dunno. It seems to me that current firewall designs--valuable though they are--are not a reason to duplicate existing protocols. With all due respect to BXXP's creator, it smacks to me of a case of NIH--building it just because he wanted to write a new protocol.
Especially the bit about requiring a photo of your credit card. Some US domestic sites, when using a bank debit card, will ask for 4 additional digits that are found on the back of most such cards. If one were to send photos including the card's back, this would make it easy for someone to impersonate you (if the site was bogus).
I'm not sure how legitimate such requests for "proof of credit card ownership" really are, the card companies (Visa, MasterCard) tend to have all sorts of rules in their contracts with vendors. For example, in Thailand, I had a travel agent charge me a 2.5% processing fee on a airplane ticket, even though that was against Visa's regulations for vendors, and part of their contract.
Who knows? Maybe asking for photos like this really is allowable by the credit card companies, and perhaps its justified. However, the whole point of a credit card is that the credit card issuer assumes the risk of non-payment in each transaction. Why should a merchant overly much who you are?
Of course, the rules of identity and proof thereof have changed, and perhaps the credit card companies haven't caught up.
Fair enough: you are correct. That's the point of "user mode kernel:" if it's in user-space, it can crap out just like any other user-space app, so the rest of the system is safe.
However, valuable as UMK is for some applications, it's (yet) not in the same league as mainframe partitioning.
1. The OS and system software on mainframe partitions may be upgraded separately without affecting other active partitions. UMKs, too, can be upgraded, but if the real kernel has to be upgraded, the whole machine goes down.
2. How well does the UMK protect the underlying real kernel (and thus other user-space apps) for excessive resource consumption? For example, what if an errant application running in an active UMK (or just buggy code in the kernel used by the UMK) starts spawning threads like crazy, will the UMK protect the rest of the real machine from adverse effects?
3. The UMK kernel, valuable as it is, is still limited in it's ability to differ from the true underlying kernel. For example, can a kernel within a UMK provide a different thread-scheduling policy that the underlying real kernel?
BTW: don't get me wrong, I love UMK and what it can become. It's quite an accomplishment to put such a thing together. Further, I may be incorrect about the completeness of it's operation. However, my whole point is to emphasize how in IBM's mainframe environment complete isolation of distinct partitions is very easy, and it's a feature that the Linux commmunity may wish to emulate as it moves further into enterprise computing territory.
Part of the reason for the "thousands of instructions" is that IBM delivers an _integrated_ product, not unlike Apple: hardware and software specifically designed to work together. Unlike the PC world, where there is a clean delineation between the CPU, the Memory manager, the BIOS, and the OS on top of that, IBM has traditionally delivered a monolithic product that blurs the lines between all of these components.
Having said that, their mainframe products are still the gold standard for speed and reliability in a corporate IT environment.
Sorry, but most fortune 500 shops rely upon IBM mainframes to crunch through the data in their core business applications.
Although Linux is an elegant OS with a bright future, at the moment it suffers from youth and the deficiencies of its original platform: the PC.
1. Raw I/O throughput. The strength of a mainframe resides primarily in its enormous capacity to move data through I/O channels. Separate I/O controllers handle most devices (like the I20 architecture), so the main CPUs are free to focus on computing tasks. The PC is not even in the same league--yet.
2. Advanced enterprise features, such as hierarchical storage management. Although Linux is moving towards LVM (Linux Volume Manager) to handle disk space, the mainframe data management facilities go one further: the OS will automatically migrate unused data from "small," fast hard drives to slower, larger hard drives, and finally to removable tape storage. This means that, unlike Linux where we manage mount points and disk partitions, the OS takes care of moving data around on all of its volumes to ensure best access. To the user (and an administrator), the sum total of all available hard disks and all cataloged tapes represents the complete collection of available data: terabytes upon terabytes of storage!
3. Another advanced feature: machine partitioning. Although incorporation of the User Mode Kernel is a step in the right direction, OS/390 (and high-end UNIX platforms, such as SUN, as well) allow an adminstrator to _partition_ a machine into completely isolated units, or partitions. Not to be confused with the Virtual Machine capability much discussed with Linux on S/390, but a partition is simply a fixed allocation of CPUs, memory, and I/O devices to an instance of a running OS/390 system.
What that means is 1 box may be split into multiple partitions, and each partition may have completely separate disk drives, memory, CPUs, etc. Basically, each partition becomes it's own machine, which can be useful for segregating activities onto different sets of resources (e.g., a test or development partition and a production partition). S/390 can do this because of hardware support, but unfortunately, efforts such as the User Mode Kernel do not achieve quite the same results: the "partitions" or "user mode kernels" still share the same underlying kernel data structures. If one UMK craps out, it could potentially bring down the whole machine.
Of course, give the Linux/Open Source community another 6 months, and it will solve all of these in spades.;)
Tomcat, from The Apache Group, is really the 100% Java reference implementation of Java Server Pages and servlets. The included web server is very simple but effective, since you can throw in just about any logic in a servlet or JSP to customize the processing.
I use to run Jigsaw at home to serve up various documents on my network and to test server-based programming (Perl/CGI, Java servlets, etc.).
As a positive, Jigsaw is a feature rich server.
- Permits configuration of MIME types, content negotiation
- Security-based access to selected resources (not SSL--just standard HTTP USER and PASSWORD authentication)
- A Java-based admin tool suitable for remote administration
- Support for virtual servers
- Enables server-side processing, such as server side includes, CGI (through executables or through interpreters such as Perl), servlets, and a form of page scripting that allowed Java to be embedded in HTML (pre-JSP), among other techniques.
- Conformance to current specifications.
Eventually, I've abandoned Jigsaw, preferring either Apache or Tomcat. Here are my reasons:
- Performance. Although Jigsaw is not abominable, this was never a fast server.
- Frequent hangs. Although it is possible this was a WinNT issue, I found Jigsaw would frequently hang, often while serving images (?) for a document. On NT it would hang so badly Windows Explorer itself would no longer be able to display images for Web Folders unless I rebooted.
- An arcane architectural model. Jigsaw has a very powerful yet very abstract design based upon resources, frames, and filters. Sure, that was great for providing nearly limitless ways of customizing it's behaviour, but it was pretty hard to figure out what type of class to extend in order to customize the server. Frankly, servlets +JSP+all else Java give me just about all the customization I need.
- Slow integration with non-W3C standards. That's definitely a whine, but Jigsaw was usually a fraction of a step behind Sun's latest servlet spec, and took forever to adopt JSP in place of it's own Java-in-HTML service (although I did like their implementation). In fairness, this has been simply because W3C hasn't had resources for more than 1 or 2 people to handle the code, and the original author has unfortunately moved on from the W3C.
So, I haven't found Jigsaw worth running on a regular basis, but I will leave you with this: there's a *heck* of a lot of free code inside that server, so if nothing else one can learn from their design and even borrow some bits (haven't checked the license recently) for other projects. Good source of samples for Java network programming.
The famous 'Internet worm' created by Robert Morris Jr. in 1988 exploited a bug in the standard SENDMAIL program available on practically all *NIX machines. Granted, that was 12 years ago, and the points in the article are well taken, but the case of the Morris Worm should remind us that open source is not completely immune from very strong virus strains.
Slashdot Mirror
A lot standard exist; whether they are useful depends on the platform you are targeting and/or the architecture of your product. You've shared nothing about either, so I'll just point you at some general standards that you may find helpful, or as sample design patterns that may bring you closer to your goal. Check out the OSD specification at the Web Consortium's main site. An XML-based software description language, it's raison d'etre is electronic delivery of software. I know Microsoft used the format at one point, and I know of at least one other company that architected their product to use the OSD language for software installation as well. An alternative to the OSD model is Sun's Java Web Start, tailored to automatic installation of software for the Java platform. If you still need to roll your own, may I suggest that you consider the package format used in the Debian GNU/Linux distribution as a good design pattern to follow? Because the format exposes extensive amounts of meta-data in each package, a complete array of tools exist to automatically resolve, download, and install dependencies--one of the major benefits of using Debian as a Linux platform. Finally, if you are a member of the ACM, their online Digital Library will no doubt have extensive information, as would the IEEE online resources (again, membership required). A free resource similar to those of the ACM and IEEE that I often find helpful is Citeseer. Hope some of those help!
Just hit the link and it's gone. Only a page indicating that the paper was not yet ready for public consumption.
Even though I suspect I would disagree with the argument that DRM can be beneficial for the end-user, I liked that someone wanted to "play nicely" by using open source.
Judging by the tone of most postings so far, I'm guessing nobody else read it either. Pity, because there could have been an intelligent discussion about this paper.
On my Linux installation, there are several jars in /usr/local/OpenOffice.org1.0/classes. Enabling Java to interoperate with the Universal Network Object (UNO) model that sits at the core of OpenOffice was always a key part of their architecture.
So, the use of Java isn't really news, and any messaging around Java should just be seen as Marketing exploiting the fact that yes, indeed, parts are written in Java.
Communications will be all about wireless.
Let's look at the 802.11x market: the little local guys who used to pull Cat 5 for companies are probably sufferring, because a lot of companies are moving to 802.11x.
Wireless home networks (and public ones, such as at Starbuck's or public parks) are ruining the chances of the major equipment manufacturers to move their existing product lines into homes.
Those same networks are causing broadband providers to fuss about "bandwidth sharing" as if it were a capital offense.
Every week new technologies are announced that extend the reach (and reliability) of wireless networks. Five years ago, only the adventurous would connect a corporate campus using only wireless. Now wireless MANs can connect an entire city.
Let's take another wireless technology, that which makes cellphones possible. AT&T, the grandfather of modern telecommunications, is practically out of the long-distance market. It's wireless division has been going gangbusters for the last 5 years. That means AT&T, who built most of the land-lines in the world, including the last mile to most homes, is still making great money, but not off those decades of investment in cabling.
Oh, one more: we live in a security conscious world. Fear of weak physical infrastructure means the US Government (and military) is continualy looking for ways to remove single points of failure from essential public or strategic infrastructure.
Add it all up? Investment in physical telecom infrastructure is sure loser in the long-term. If Gates wants to "own" the land-lines, so be it. With the continued growth (and interest) in wireless technology, using wires to connect people and machines will become old-fashioned and a specialty need. One can cut a trunk cable to block communications, but you have to be good to block every wireless communication technology under the sun.
Sure, all that investment in last mile cabling and undersea pathways and trans-national networks won't rot overnight. There may always be a need for such networks, but only as a specialty. As time goes on, the need or such networks will be reduced, as the continued evolution of cheap, effective wireless technology makes all of it seem antiquated.
So even if I was paranoid enough to believe Bill Gates could pull off such a feat as owning the Internet (how many billion in cash does Microsoft have right now?), it may not matter for very long.
I respectfully disagree: it's *still* all about algorithms! And, BTW, what comes next I do not wish to aim at you personnaly. Just ignore the rest of this if I'm taking you (and me!) too seriously. ;)
<rant>
I've been in IT for over 10 years, and it seems so many times you find people in IT who will happily blather on about the "Visitor" pattern or another such topic (a useful pattern, to be sure), but who for the life of them can't remember any of the basic sort algorithms. It kills me; algorithms are still fundamental component of our toolkit. We can't ignore them
</rant>
<useful_contribution>
Are patterns nothing more than new algorithms expressed more conceptually, with natural language instead of a programming language? Sure, a pattern does not have the same strict criteria of finite number of steps, complete in finite time, must have output, etc., but just as algorithms (and Donald Knuth's work) are guides to implementation, are patterns not also guides?
Typically, one can express an algorithm in some form of pseudo-programming language. By choosing a programming language, we are choosing a form of expression with deep mathematical roots (think Godel, Turing, Church, etc.). What are patterns, but guides that we simply have not translated into a pseudo-language template for implementation? The Visitor pattern is a great example: one can express the pattern in a number of languages, quite simply.
So, perhaps we incorrectly differentiate between patterns and algorithms based purely on the language of expression. Perhaps instead we should look for that new language, or expand an old programming language, that can capture the ideas of patterns more precisely and inline in the same code as those code artifacts we have traditionally called algorithms.
And with the expressive power of this new language, what would programming be like?
</useful_contribution>
Okay, this might be unintentional flamebait...
Last time I looked at the OS/2 API (many, many years ago), I walked away with the thought that it was overdone. As an example: the CreateProcess function call had something like 10 parameters!!! It seemed like a function such as that should be simple, since invariably it would be called a lot (e.g., fork!). Of course, then there is the perspective that if there was a simpler function, I could have found it if there developer documentation had been friendlier?
I subscribe to the Unix philosophy of functions doing 1 thing and doing it very well. The amount of overloading on those API calls (due to all the flags and options passed in) could break the bank. And there's a lot of evidence that a simpler design leads to longer-lasting software: Linux, to name just one.
I always thought the complexity of OS/2's APIs scared away developers from the platform. At the time, Win 3.1 (aka Win16 API) had a much simpler API, albeit a much less powerful platform. Heck, another example of the value of simple APIs might have been Win16, since it did last for a long time and introduce a lot of programmers to WIMP programming.
Oddly, the Win32 API introduced by Windows NT echoed OS/2's complexity. CreateProcess still has 10 arguments! So how did it survive? Microsoft marketing, I guess. Or the complexity of the API had nothing to do with OS/2's demise....
My $.02
I do not follow *BSD nearly enough to make this kind of observation, but I thought I recalled that when Universal Virtual Memory was rolled into NetBSD, it was widely regarded as a good design. Anybody with much more VM design knowledge able to comment on how suitable a design like that one (or other well-regarded VM design from other Unixes) would be for the Linux kernel?
As much as I wish I could assure you that you can be an architect for the rest of your career, from my own experience I have to advise you to do otherwise. Like many who are responding to this article, I, too, have been an architect.
;)
Currently, I work at a high-profile software start-up and guess what? No one has the official role of architect. We have a very experienced, very successful development and management team, too; apparently, they do not see granting someone the title "architect" to be beneficial to their success. For the trolls out there: the lack of an official architect will not be a reason a company like mine fails.
Others replying to your article have mentioned that it is important to like what you do. I concur, and that will always be the best compass for your career. But, having said that, I think the role of architect may indicate that you are currently in an anomalous position: chances are good you may merely be smarter or more capable of viewing the big picture than everyone around you. However, what if you were in a different company, or working on a different team? You may find that you are just barely keeping up. I contend that in a different environment, with others who may have skills to match or exceed your own, you may actually be more succesful as a developer than an architect. Therefore, don't pigeonhole yourself unnecessarily.
Further, nearly every successful architect that I have ever seen eventually succumbs to the need to become a manager. It's just part of the natural order of business: in a good company, those who lead and mentor need to become managers because they are best suited to tending to others, to steering the ship. That doesn't mean every manager is good as a leader or mentor (I've met my share of pointy-haired bosses, too), but invariably every good architect finds limits to their influence as an architect--and discovers that bearing a managerial title can actually increase their effectiveness.
Or consider another dimension: maybe it's not what role you should play (developer or architect or manager), but perhaps in what type of industry you work. Architects can often be much happier as a consultant, either for someone else's firm or their own; it is difficult to remain satisfied in a staid, old-line firm where 70% of the challenge is keeping ahead of maintenance.
Having only relatively recently passed through the same dilemma you face, I encourage you to understand the simplicity of the choices as you perceive them to be contextual. I, for example, chose to move on from a role as an architect and individual contributor, to accept a role as a director and department head because I understand that I had too many skills (such as a knowledge of the business, how to work with customers, and project management) that would have evaporated had I not made the transition. Of course, there are other skills I now have the chance to learn, too: how to *really* please customers, not just once, but on a regular basis; how to design an organization; how to architect systems for an entire company rather than for a single application; and (trickiest of all) to motivate, encourage, and develop the careers of my staff, especially when each one of them may have an inkling of their own desire to be an architect!
Ultimately, though, I did make my choice because I understand that I can apply the same skills that I honed as an architect (and many others I learned along the way, including some new ones), but on a much larger canvas. It would be a loss to yourself and to both your current and future companies if you only allowed yourself to be an architect. Strive for those positions that allow you to have a stronger impact, if you are really the right one to be making that impact. My decision to become a manager hasn't at all changed who I am or what I like to do. I still architect a great deal, frequently when my own architect is elsewhere deployed.
Remember: try to understand your dilemma may be contextual; that continuing to be happy about what you do is the best guide; and that you owe it your peers to impact your organization in a way commensurate with your actual skill. You are just at the beginning of your career: just wait till you see what happens next.
A big advantage of XML schemas over DTDs, besides providing a richer language to express the structure of a document, is this: a schema is a valid XML document itself. DTDs have their own syntax that does NOT match XML; schemas ensure that you only need 1 type of parser, an XML parser.
Please don't confuse profit with revenue: the reason consulting companies are either going belly-up or shedding their masses is not really about profits. It's just that the revenue stream dried up.
The profit margins on consulting aren't too bad. Think about it: one of the biggest expenses are the expenses of the consultants themselves (travel, hotel, etc.), and all of that is paid for by the client. In some cases, that is often priced at 10-20% of fees--so that's an extra 10-20% *on top of fees* that firms collect to cover their bottom line.
The real problem with consultants (and why Wall Street traditionally shunned them, until the New Economy happened) is the variability of their business. Sure, during the boom of the Net years and Y2K, they were hiring like mad and making money hand over fist, but it's big consulting contracts that get cut first when the belts start tightening.
Having said that, the good firms know how to tailor their business to match the economy. For example, 5 years ago, the trend towards "re-engineering" (aka downizing) was all the rage, and consultants made money by convincing their clients they could *save* them money. Then the Internet thing happened, and they convinced their clients they could help *make* them money.
I've skipped a few fads (supply chain management, ERP, etc.), but you get the gist: consultants make their money through 1 of the 2 approaches above, making or saving their clients money. Give the consulting firm a few quarters to recover from the shift in economic tides, and you'll see them back in the game, this time with a new yet somehow "same ol'" message.
The creator of this language asserts that text is on the wrong medium for communicating program meaning. He implies that Eidola will enable a visual approach to describing programs.
Why the hell isn't he looking at UML?
I put that forward as a comparison, because a *lot* of people have spent time and energy developing the semantics of UML models, and they are beginning to offer a reasonably complete toolkit for describing programs and program behavior. And because UML is a language, it certainly does not dictate how you represent programs or how you use UML: it provides an existensive "vocabulary" for communication, and all it argues for is consistency of use.
Can someone send this guy a book on UML? Amazon ships up to Canada, doesn't it?
I've worked for lots of Fortune 500 companies, so I think I have a good handle on what a CIO does in traditional organizations that understand what the role of a CIO is.
A CIO, who ideally reports to the CEO, is responsible for all information technology that runs the company, all of the technology infrastructure. That means networks, servers, databases, third-party applications, programming staff, project managers, specialized consultants, etc.
A CIO spends much of her time managing a portfolio of projects, each one dedicated to a particular goal, whether it's upgrading the corporate desktops, installing new network equipment, or developing (in conjunction with consultants) a sexy new e-commerce application.
Typically, a CIO has 2 key direct reports: a Vice President of Operations, and a Vice President of Applications. The former maintains the network, the hardware, the data center, and other "static" portions of the CIO's domains, often reporting key metrics such as uptime, throughput, cycles used, etc. The latter oversees the design, development, deployment, and support of all applications throughout the enterprise. The latter emphasizes metrics for estimated time to completion, FTEs, etc.
For the last 10 to 15 years, CIOs have spent a lot of time fighting their way into the executive boardroom and getting the ear of the CEO. They have had to justify why they should report to a CEO rather than the CFO, as happens in some places, and why they can help the business strategically rather than provide mere operational support. Not an easy task, but CIOs appear to be getting their message out. And the longevity of the average CIO appears to be lengthening!
I, too, have a Speakeasy connection, which for me runs at 1.5M (or whatever their top speed). I've never measaured to see what bandwidth I really receive, but I don't think I'm being cheated--I know what a T1 feels like.
There are at least 2 advantages I have found to Speakeasy: their technical support *does* know what they are doing and can explain what's happening when there are network troubles (once in 6 months); and they are very liberal regarding what platforms can be connected to their network. At home I have a gateway router/firewall connected to Speakeasy, and behind that I have a hub with 2 machines hooked up, one Linux and one Windows 98. Very stable.
I originally had Bell Atlantic, but 1) they explicitly did not support Linux or the use of a router to connect multiple devices (Windows NT was barely tolerable to them), and 2) of the 3 months I had an account with them, I experienced an entire MONTH with no service. I spent approximatley 10-20 hours on the phone with their technical support (most of it on hold--3 hours one day), who clearly had *no* background in networking, and were unable to assist me. My best guess is they switched from having an open network to one that required PPPoE, but they didn't know that or what to do about it.
So...run out and call Speakeasy!
Actually, I don't think I'm confused. You've hit the nail on the head: why create a protocol in the *application* layer, when there are protocols that solve these problems in lower-level layers?
I'm sure there are good reasons to re-implement these in the application layer. But what are they?
I understand the limitations of HTTP (too many connections that are expensive to set up, no multiplexing of channels, not robust or consisent when handling errors, etc.) but why a new protocol--why not just use basic TCP or UDP sockets over IP? After all IP handles packet sizes, TCP manages packet retransmissions, etc. For protocols that don't need TCP services there's UDP.
After all, HTTP has only become overloaded because that's the one protocol that was pretty much guaranteed to make it through everyone's firewall, whether the firewall just blocked ports or actually sniffed packets. It would make sense to have a new meta-protocol, on a standard port or set of ports, so that true Net applications can communicate even through firewalls, but...does it justify a whole new protocol?
I dunno. It seems to me that current firewall designs--valuable though they are--are not a reason to duplicate existing protocols. With all due respect to BXXP's creator, it smacks to me of a case of NIH--building it just because he wanted to write a new protocol.
??
Especially the bit about requiring a photo of your credit card. Some US domestic sites, when using a bank debit card, will ask for 4 additional digits that are found on the back of most such cards. If one were to send photos including the card's back, this would make it easy for someone to impersonate you (if the site was bogus).
I'm not sure how legitimate such requests for "proof of credit card ownership" really are, the card companies (Visa, MasterCard) tend to have all sorts of rules in their contracts with vendors. For example, in Thailand, I had a travel agent charge me a 2.5% processing fee on a airplane ticket, even though that was against Visa's regulations for vendors, and part of their contract.
Who knows? Maybe asking for photos like this really is allowable by the credit card companies, and perhaps its justified. However, the whole point of a credit card is that the credit card issuer assumes the risk of non-payment in each transaction. Why should a merchant overly much who you are?
Of course, the rules of identity and proof thereof have changed, and perhaps the credit card companies haven't caught up.
</diarrhea of the mouth>
Fair enough: you are correct. That's the point of "user mode kernel:" if it's in user-space, it can crap out just like any other user-space app, so the rest of the system is safe.
However, valuable as UMK is for some applications, it's (yet) not in the same league as mainframe partitioning.
1. The OS and system software on mainframe partitions may be upgraded separately without affecting other active partitions. UMKs, too, can be upgraded, but if the real kernel has to be upgraded, the whole machine goes down.
2. How well does the UMK protect the underlying real kernel (and thus other user-space apps) for excessive resource consumption? For example, what if an errant application running in an active UMK (or just buggy code in the kernel used by the UMK) starts spawning threads like crazy, will the UMK protect the rest of the real machine from adverse effects?
3. The UMK kernel, valuable as it is, is still limited in it's ability to differ from the true underlying kernel. For example, can a kernel within a UMK provide a different thread-scheduling policy that the underlying real kernel?
BTW: don't get me wrong, I love UMK and what it can become. It's quite an accomplishment to put such a thing together. Further, I may be incorrect about the completeness of it's operation. However, my whole point is to emphasize how in IBM's mainframe environment complete isolation of distinct partitions is very easy, and it's a feature that the Linux commmunity may wish to emulate as it moves further into enterprise computing territory.
Part of the reason for the "thousands of instructions" is that IBM delivers an _integrated_ product, not unlike Apple: hardware and software specifically designed to work together. Unlike the PC world, where there is a clean delineation between the CPU, the Memory manager, the BIOS, and the OS on top of that, IBM has traditionally delivered a monolithic product that blurs the lines between all of these components.
Having said that, their mainframe products are still the gold standard for speed and reliability in a corporate IT environment.
Sorry, but most fortune 500 shops rely upon IBM mainframes to crunch through the data in their core business applications.
;)
Although Linux is an elegant OS with a bright future, at the moment it suffers from youth and the deficiencies of its original platform: the PC.
1. Raw I/O throughput. The strength of a mainframe resides primarily in its enormous capacity to move data through I/O channels. Separate I/O controllers handle most devices (like the I20 architecture), so the main CPUs are free to focus on computing tasks. The PC is not even in the same league--yet.
2. Advanced enterprise features, such as hierarchical storage management. Although Linux is moving towards LVM (Linux Volume Manager) to handle disk space, the mainframe data management facilities go one further: the OS will automatically migrate unused data from "small," fast hard drives to slower, larger hard drives, and finally to removable tape storage. This means that, unlike Linux where we manage mount points and disk partitions, the OS takes care of moving data around on all of its volumes to ensure best access. To the user (and an administrator), the sum total of all available hard disks and all cataloged tapes represents the complete collection of available data: terabytes upon terabytes of storage!
3. Another advanced feature: machine partitioning. Although incorporation of the User Mode Kernel is a step in the right direction, OS/390 (and high-end UNIX platforms, such as SUN, as well) allow an adminstrator to _partition_ a machine into completely isolated units, or partitions. Not to be confused with the Virtual Machine capability much discussed with Linux on S/390, but a partition is simply a fixed allocation of CPUs, memory, and I/O devices to an instance of a running OS/390 system.
What that means is 1 box may be split into multiple partitions, and each partition may have completely separate disk drives, memory, CPUs, etc. Basically, each partition becomes it's own machine, which can be useful for segregating activities onto different sets of resources (e.g., a test or development partition and a production partition). S/390 can do this because of hardware support, but unfortunately, efforts such as the User Mode Kernel do not achieve quite the same results: the "partitions" or "user mode kernels" still share the same underlying kernel data structures. If one UMK craps out, it could potentially bring down the whole machine.
Of course, give the Linux/Open Source community another 6 months, and it will solve all of these in spades.
Tomcat, from The Apache Group, is really the 100% Java reference implementation of Java Server Pages and servlets. The included web server is very simple but effective, since you can throw in just about any logic in a servlet or JSP to customize the processing.
I use to run Jigsaw at home to serve up various documents on my network and to test server-based programming (Perl/CGI, Java servlets, etc.).
As a positive, Jigsaw is a feature rich server.
- Permits configuration of MIME types, content negotiation
- Security-based access to selected resources (not SSL--just standard HTTP USER and PASSWORD authentication)
- A Java-based admin tool suitable for remote administration
- Support for virtual servers
- Enables server-side processing, such as server side includes, CGI (through executables or through interpreters such as Perl), servlets, and a form of page scripting that allowed Java to be embedded in HTML (pre-JSP), among other techniques.
- Conformance to current specifications.
Eventually, I've abandoned Jigsaw, preferring either Apache or Tomcat. Here are my reasons:
- Performance. Although Jigsaw is not abominable, this was never a fast server.
- Frequent hangs. Although it is possible this was a WinNT issue, I found Jigsaw would frequently hang, often while serving images (?) for a document. On NT it would hang so badly Windows Explorer itself would no longer be able to display images for Web Folders unless I rebooted.
- An arcane architectural model. Jigsaw has a very powerful yet very abstract design based upon resources, frames, and filters. Sure, that was great for providing nearly limitless ways of customizing it's behaviour, but it was pretty hard to figure out what type of class to extend in order to customize the server. Frankly, servlets +JSP+all else Java give me just about all the customization I need.
- Slow integration with non-W3C standards. That's definitely a whine, but Jigsaw was usually a fraction of a step behind Sun's latest servlet spec, and took forever to adopt JSP in place of it's own Java-in-HTML service (although I did like their implementation). In fairness, this has been simply because W3C hasn't had resources for more than 1 or 2 people to handle the code, and the original author has unfortunately moved on from the W3C.
So, I haven't found Jigsaw worth running on a regular basis, but I will leave you with this: there's a *heck* of a lot of free code inside that server, so if nothing else one can learn from their design and even borrow some bits (haven't checked the license recently) for other projects. Good source of samples for Java network programming.
My $.02
The famous 'Internet worm' created by Robert Morris Jr. in 1988 exploited a bug in the standard SENDMAIL program available on practically all *NIX machines. Granted, that was 12 years ago, and the points in the article are well taken, but the case of the Morris Worm should remind us that open source is not completely immune from very strong virus strains.