Cheap boxes, linux and software that produces web app front ends (php, servlets, jsp, asp, etc.) are forcing many companies to move a lot of traditional middle tier stuff forward into the web tier. It makes good business sense to distribute web app stuff -- since it is proving increasingly stable -- across scads of cheap linux boxes, and have them communicate with a handful of heavy duty Sun hosts running enterprise apps rather than building one giant and absurdly expensive middle tier to manage both content generation and enterprise logic. Doesn't it?
Linux/Apache/dynamic presentation engine (tons of open source at this tier) ---- Solaris/App Server/ORBs/Big Expensive Enterprise Apps (virtually no open source at this tier) ---- RDBMS/Legacy System (Oracle and IBM own this final most expensive and least distributed of tiers).
Large Java-based sites often make use of advanced app servers such as WebSphere and WebLogic, which hide many of the grittier concurrency issues from the app developer, but some probably obvious rules still apply:
Simple rules are to avoid using http sessions as data structures, use object pools as much as possible (not just for database connections), try and keep things as stateless as you can possibly get away with, pay attention to the hardware on which your web app will be deployed (for instance, if your db host dwarfs your middle tier by ten orders of magnitude it might not make sense to cache SQL results in the middle tier after all), and try to keep the presentation layer clean and relatively code-free for the designers (who will otherwise cost you tons of time in mistakes and inane questions). There are other more specific tips, such as refer to values via references to existing data structures rather than instantiating new Strings to hold such values.
When I began working form home a couple of years ago, friends were certain I'd never actually work. Too many distractions, too much sleep, etc.
The opposite was true. I was suddenly never away from work. I couldn't sit on my couch anymore and watch a movie with my wife without thinking of work -- because I was in the office all the time. I lost my home, really.
Part of the reason for this is that I had no separate office. My desk was in the bedroom, so even while I slept my 19-inch monitor stared at me, disappointed at my laziness.
So I guess my advice would be to try and carve out a separate work space if you're going to work at home full-time. Treat it as separate. Keep track of your hours -- not only for billing purposes, but to help enforce a delineation between your home life and your office hours. May sound silly in a world where our work IS life, but nevertheless it could help save a tiny corner of sanity and permit you to goof-off without feeling guilty.
Using XML to hold configuration data is sleek, but the possibilities for extending such translation to widget and component creation are even more promising:
What if there were to be some XML processor built into the OS XML engine that parsed tags for creating windows, creating layout managers, and painting buttons, menus, etc. Assuming such components manage their own event processing and are truly modular (such as javabeans), one could script the creation of an entire UI or application. Maybe other API's could be mapped through XML processors and DTD's -- for instance, a series of XML tags mapped to OpenGL calls could be pretty spectacular.
Granted, this is what scripting languages really already do: interpret chains of characters and map them to native machine functions. XML is the ultimate scripting language, though, because instead of choosing between perl, python, or even C, and being limited to their specific API's and syntaxes, we could simply use XML and choose different processors and DTD/controllers to accomplish the necessary mappings to specific syntaxes and API's. A single XML-crafted application could actually map to several languages if necessary, blending Java, C, perl, etc.
Of course, a very talented team of brains would need to create the API-mapping-stylesheet-DTD pieces for these XML app developers to use, not to mention the XML processors (which would in effect become a virtual machine).
Apparently Sun crafted a patch to help bridge the gap between Solaris and Linux threads, but they haven't shown any indication of adding that code to the Blackdown tree.
At the risk of treading on etiquette, here's a snip from a post made by one of the BlackDown contributors on a Sun mailing list:
Well, as I said in another mail, it looks at least a lot like they started out with the results of 4(?) years of Blackdown porting efforts. You need to have been on board in order to get a feel for the awful amount of work necessary to convert Solaris' threading to Linux' threading, etcetera. That this results in a comparatively small patch file does not mean that they weren't 90% jumpstarted by the Blackdown effort, and indeed only added a couple of patches and a few bits of functionality.
Of course, the really great thing is that a) we (Blackdown) were unaware of this effort, and b) we still have to see these fixes contributed to Blackdown. Not that it is really necessary, because the first team member already resigned so I think Sun and Inprise can maintain the port all by themselves in the future. I certainly won't lift a finger anymore to debug the Intel port...
Here in Manhattan, there is surprisingly little pure product-based software development. Instead, most software engineers work either at new media companies (Silicon Alley, web-based startups, advertising agencies, etc.) or on Wall Street (investment banks, brokerages, etc.). The former category pays less, but offers the typical bushel of options and some very interesting projects; the latter category pays sometimes absurd salaries, but often offers fairly dull projects.
Salary-wise, for mid-level fairly experienced coders I see new media companies offering around $55-70k annually, and Wall Street offering $80-90k. In my experience, DBA's make slightly more. Senior level coders make about 20% more than that. These are obviously rough estimates, and another engineer in Manhattan may have a different perspective and experience.
There are also a ton of consultants and contractors, who sort of float down Silicon Alley and Wall Street and back up again. The salaries of these folks are hard to figure, and I wouldn't want to embarrass myself by hazarding a guess as to their income.
What's your response to the notion that the web's reliance on centralized Certificate Authorities for secure commerce is ultimately flawed? There are those, like the Meta Certificate Group, who feel that a hierarchical chain of certificates leading back to only a couple of elite organizations won't hold up in the distributed envirionment of the Internet. The entire framework of e-commerce seems to stand on the private keys of Verisign and Thawte. Do you feel this is a danger, and will there be viable alternatives.
One social barrier to common crypto usage is the lack of a secure yet informal key storage and retrieval mechanism. But just lately I've seen folks tackle this issue through distributed systems -- smart cards using dynamic networks, embedded systems plugged in to corba and jini backbones, etc. What do you envision for the future of distributed key management specifically, and the use of crypto on embedded devices in general? Do any particular protocols, languages, or vendors seem to hold special promise in this area?
Thanks, and best of luck with Twofish in the next AES round.
The Enterprise Java Bean architecture is a standard that will let you use any specific protocol (CORBA, RMI, vanilla socket, etc.) with any server (relational dbs, web servers, object oriented dbs, orbs, etc.). It encompasses all these other specifics in a distributed transaction framework that hides the details from developers who wish only to deploy apps.
Using this standard, you can write the logic of your app and use the app server's tools to deploy it, and not spend time worrying about partial failures, network synchronization, how fine grained access control is managed, and all the other problems associated with distributed programming. And it doesn't mean you have to be a java fanatic -- the latest ejb spec isn't even based on rmi, it aims for iiop compliance instead.
A couple of open source ejb app servers to consider: EJBoss JOnAS
Also take a look at the ejb-friendly xml work at Enhydra and of course, the world's greatest servlet engine, Apache JServ.
It's not exactly like comparing apples and oranges, but Solaris and Linux aren't exactly sighting the same target. Linux is tiny compared to the sheer mass of a Solaris install, making Solaris a questionable fit for a personal x86 environment. Sun's never shown much interest in that environment anyway. Their free developer version of Solaris (for Sparc and x86) is very nice (with an acceleratedX server and a lengthy visit to www.sunfreeware.com), but it doesn't aim at the comfort level of a flashy Gnome/kde bedecked linux dist. Linux on portable devices -- sure thing. Solaris? No way.
Unless I am totally off the mark about how this stuff is functioning, it would seem easy enough to write something that scrambles your typing according to pseudo-randomly-generated key bindings. It also seems that the more commercial and governmental entities push snoop stuff for shadowing their employees (all in the name of protecting shareholder value or national defense, depending on your sphere), the more room there will be for us to challenge with privacy-protecting code of our own.
As a relevant aside, I have heard of some proprietary monitoring software implemented in Lotus Notes at a regional bank that actually did record how much time employees spent perusing emails and company memos (I suppose to see whether they were actually paying attention or in need of a possible attitude adjustment, a la Snow Crash).
This would all be more frightening if the would-be big brothers were less naive and if I were less confident in the talents of the open source community.
It's fine to be cynical of Sun's marketing of java, but it's silly to by cynical of the enterprise changes it's undergone over the past year. When will people talk about the actual apps, and not just lump all java stuff together because they're written in the same tongue?
Anyway, java is highly useful for things like quickly developing complex object and service distribution. For example, encapsulating a service (like a printer in Bangkok, say, wrapped in a java object referenced as an interface), sticking it in a naming directory (could be iiop-based, could be rmi-based, could be something similar to ldap -- java can do it all in a very similar way), and then obtaining a reference to that object and calling its methods from ANY client (an embedded applet on a cellphone, for example) -- this is very cool stuff, and lumping it into the same category as tickertape applets just because they're both java is annoying and ignorant. Should we lump all C stuff together just because it's done in the same language?
The primary advantage of doing all this in java is not platform independence as much as extremely rapid (thus less costly) development.
All this is not to say that any of this will run across linux -- based on Gosling's comments here last week, java will run with these legos and on Palm Pilots better than any linux port for the foreseeable future.
Slashdot Mirror
Linux/Apache/dynamic presentation engine (tons of open source at this tier) ---- Solaris/App Server/ORBs/Big Expensive Enterprise Apps (virtually no open source at this tier) ---- RDBMS/Legacy System (Oracle and IBM own this final most expensive and least distributed of tiers).
Simple rules are to avoid using http sessions as data structures, use object pools as much as possible (not just for database connections), try and keep things as stateless as you can possibly get away with, pay attention to the hardware on which your web app will be deployed (for instance, if your db host dwarfs your middle tier by ten orders of magnitude it might not make sense to cache SQL results in the middle tier after all), and try to keep the presentation layer clean and relatively code-free for the designers (who will otherwise cost you tons of time in mistakes and inane questions). There are other more specific tips, such as refer to values via references to existing data structures rather than instantiating new Strings to hold such values.
A decent Java book on concurrent design is: Concurrent Programming in Java: Design Principles and Patterns.
The opposite was true. I was suddenly never away from work. I couldn't sit on my couch anymore and watch a movie with my wife without thinking of work -- because I was in the office all the time. I lost my home, really.
Part of the reason for this is that I had no separate office. My desk was in the bedroom, so even while I slept my 19-inch monitor stared at me, disappointed at my laziness.
So I guess my advice would be to try and carve out a separate work space if you're going to work at home full-time. Treat it as separate. Keep track of your hours -- not only for billing purposes, but to help enforce a delineation between your home life and your office hours. May sound silly in a world where our work IS life, but nevertheless it could help save a tiny corner of sanity and permit you to goof-off without feeling guilty.
What if there were to be some XML processor built into the OS XML engine that parsed tags for creating windows, creating layout managers, and painting buttons, menus, etc. Assuming such components manage their own event processing and are truly modular (such as javabeans), one could script the creation of an entire UI or application. Maybe other API's could be mapped through XML processors and DTD's -- for instance, a series of XML tags mapped to OpenGL calls could be pretty spectacular.
Granted, this is what scripting languages really already do: interpret chains of characters and map them to native machine functions. XML is the ultimate scripting language, though, because instead of choosing between perl, python, or even C, and being limited to their specific API's and syntaxes, we could simply use XML and choose different processors and DTD/controllers to accomplish the necessary mappings to specific syntaxes and API's. A single XML-crafted application could actually map to several languages if necessary, blending Java, C, perl, etc.
Of course, a very talented team of brains would need to create the API-mapping-stylesheet-DTD pieces for these XML app developers to use, not to mention the XML processors (which would in effect become a virtual machine).
At the risk of treading on etiquette, here's a snip from a post made by one of the BlackDown contributors on a Sun mailing list:
Well, as I said in another mail, it looks at least a lot like they started out with the results of 4(?) years of Blackdown porting efforts. You need to have been on board in order to get a feel for the awful amount of work necessary to convert Solaris' threading to Linux' threading, etcetera. That this results in a comparatively small patch file does not mean that they weren't 90% jumpstarted by the Blackdown effort, and indeed only added a couple of patches and a few bits of functionality.
Of course, the really great thing is that a) we (Blackdown) were unaware of this effort, and b) we still have to see these fixes contributed to Blackdown. Not that it is really necessary, because the first team member already resigned so I think Sun and Inprise can maintain the port all by themselves in the future. I certainly won't lift a finger anymore to debug the Intel port...
Salary-wise, for mid-level fairly experienced coders I see new media companies offering around $55-70k annually, and Wall Street offering $80-90k. In my experience, DBA's make slightly more. Senior level coders make about 20% more than that. These are obviously rough estimates, and another engineer in Manhattan may have a different perspective and experience.
There are also a ton of consultants and contractors, who sort of float down Silicon Alley and Wall Street and back up again. The salaries of these folks are hard to figure, and I wouldn't want to embarrass myself by hazarding a guess as to their income.
Cheers,
psn
Thanks again,
PS Neville
One social barrier to common crypto usage is the lack of a secure yet informal key storage and retrieval mechanism. But just lately I've seen folks tackle this issue through distributed systems -- smart cards using dynamic networks, embedded systems plugged in to corba and jini backbones, etc. What do you envision for the future of distributed key management specifically, and the use of crypto on embedded devices in general? Do any particular protocols, languages, or vendors seem to hold special promise in this area?
Thanks, and best of luck with Twofish in the next AES round.
PS Neville
Using this standard, you can write the logic of your app and use the app server's tools to deploy it, and not spend time worrying about partial failures, network synchronization, how fine grained access control is managed, and all the other problems associated with distributed programming. And it doesn't mean you have to be a java fanatic -- the latest ejb spec isn't even based on rmi, it aims for iiop compliance instead.
A couple of open source ejb app servers to consider:
EJBoss
JOnAS
Also take a look at the ejb-friendly xml work at Enhydra and of course, the world's greatest servlet engine, Apache JServ.
As a relevant aside, I have heard of some proprietary monitoring software implemented in Lotus Notes at a regional bank that actually did record how much time employees spent perusing emails and company memos (I suppose to see whether they were actually paying attention or in need of a possible attitude adjustment, a la Snow Crash).
This would all be more frightening if the would-be big brothers were less naive and if I were less confident in the talents of the open source community.
Anyway, java is highly useful for things like quickly developing complex object and service distribution. For example, encapsulating a service (like a printer in Bangkok, say, wrapped in a java object referenced as an interface), sticking it in a naming directory (could be iiop-based, could be rmi-based, could be something similar to ldap -- java can do it all in a very similar way), and then obtaining a reference to that object and calling its methods from ANY client (an embedded applet on a cellphone, for example) -- this is very cool stuff, and lumping it into the same category as tickertape applets just because they're both java is annoying and ignorant. Should we lump all C stuff together just because it's done in the same language?
The primary advantage of doing all this in java is not platform independence as much as extremely rapid (thus less costly) development.
All this is not to say that any of this will run across linux -- based on Gosling's comments here last week, java will run with these legos and on Palm Pilots better than any linux port for the foreseeable future.
There is a book called "The Science of Star Trek" which is pretty good if you are interested more in this type of stuff.