...most of the coders who write OS software do so to escape the litany of the design-by-committee approach they're used to at their day jobs. More coders means more design meetings, more arguments, and less time for the coding that makes it fun.
I've been a developer at Sun for about a year and a half now. I started when I was going to school in Worcester, Mass and commuting to Chelmsford. Soon enough though, they kicked all us developers out and moved us to Nashua, about an hour away. So 4 months ago I packed up and moved up here. Now we're being moved back right near Worcester, and I asked about the iWork program. I was basically told no, and here's why.
The idea is basically that people who work in sales and marketing and stuff like that who travel a lot were using the predecessor of the iWork office, called simply a drop-in, more often then their "real" office anyway, so why bother reserving them space for a "home" office"? It's a nifty idea for them, but not for us. As developers, we need to be near the people we're developing with. I kinda aggree, but I still hate the commute, not to mention paying Mass taxes...
Finally, a clear, consise tutorial on XML namespaces. Just goes to show what a simple, easily understood, efficient and applicable technology XML is...
I'd heard that IBM was basically running Linux inside of an AIX VM, as opposed to directly on the hardware. Is this true, and if so, what do you have to watch out for in terms of performance tuning in order to deal with the vastly different set of latencies presented by a VM, rather than bare x86 metal?
Oh, please. Most people don't love their jobs. They perform them because the money they're paid is worth the effort they invest to get it. Picking a job in a promising field is a "good idea". It's supply and demand, and people who fight against it frequently get the short end of the stick.
Besides, these type of "hot jobs" lists can serve as inspiration to someone looking for a new path. You can't really know if you'd like it until you try.
Why are classes like Integer so weird? It is such a pain to, for example, increment them...
It's because they're immutable wrappers, just like String is.
[T]here is no way to pass an int by reference.
There's a kinda lame way: int[] intReference=new int[1];
One (public) class per file.
It's so you can swap implementations of individual classes in and out without disturbing the rest of a project. Given, of course, that the class signature doesn't change...
I used to do quite a bit of RMI programming. It was a pain in the butt. For any problem of non-trivial complexity, RMI becomes somewhat burdensome. Then I moved on to J2EE, mostly JSP/Servlet stuff with some JDBC, no EJB, and it was a breath of fresh air. It's like the difference between Java 1.0 AWT and 1.1 AWT. Then recently one of our projects called for data sharing between different webapps, and despite my objections RMI was dragged out, and it I found that little has changed. Classpath problems are probably the biggest offenders, even in the JDK 1.2+ "no-classpath" era. It's just not a well-designed spec. It's a shallow OO wrapper over old-school RPC, and, IMHO, is not worth the hassle.
A while back someone told me about Mojo Nation and it seemed pretty nifty. The idea is that users get "mojo" for contributing to the network as a whole, which they cam then "spend" on services that other users provide. It's trying to solve the problem of "freeloaders" on networks such as Gnutella who use lots of bandwidth with searches but basically bog the network down. Capitalism meets P2P. It's kinda-sorta decentralized in that files that are shared are broken down into little (redundant) bits that are stored for retrieval on lots of hosts. Again, neat idea, but the problem I had with it was that it cost mojo to share files! It costs mojo to do anything that uses bandwidth, basically, so users are implicitly discouraged from sharing. Oy vey.
I'd be interested to see how the BSA is planning on getting around that nasty old 4th ammendment issue. I'd love to see an entire city get together and ignore them, and watch the BSA try and get thousands upon thousands of search warrants.
C# has built-in XML parser support. Java has any number of semi-standard packages for XML parsing, like IBM's XML4J. Eh. As a Java developer (yes, working for McNealy's cohort) I can tell you that the real focus has been on the enterprise/web developemnt stuff like J2EE, and a big part of its selling power is that it's a pretty open standard. You can pick and choose your app server, database software, or darn near any other software (or hardware) component, and it should still work. The Java language itself is tres cool, but that's not why business build solutions on it. It's close to the ubiquity and platform-independence of Perl, close to the performance of native code, and close to the code scalability of a pure-OO language. It's a nice compromise, but there will always be languages/environments that do certain things better.
I had an online journal for a while, and the problem that I had with it was that it was difficult being honest in it. I mean, if your life involves the people who would most likely read your journal, you can't exactly be completely up-front, can you? I'd write, sometimes not the most flattering things, and they'd get pissed. Private journals have their merits, too...
Slashdot Mirror
...most of the coders who write OS software do so to escape the litany of the design-by-committee approach they're used to at their day jobs. More coders means more design meetings, more arguments, and less time for the coding that makes it fun.
I've been a developer at Sun for about a year and a half now. I started when I was going to school in Worcester, Mass and commuting to Chelmsford. Soon enough though, they kicked all us developers out and moved us to Nashua, about an hour away. So 4 months ago I packed up and moved up here. Now we're being moved back right near Worcester, and I asked about the iWork program. I was basically told no, and here's why.
The idea is basically that people who work in sales and marketing and stuff like that who travel a lot were using the predecessor of the iWork office, called simply a drop-in, more often then their "real" office anyway, so why bother reserving them space for a "home" office"? It's a nifty idea for them, but not for us. As developers, we need to be near the people we're developing with. I kinda aggree, but I still hate the commute, not to mention paying Mass taxes...
Finally, a clear, consise tutorial on XML namespaces. Just goes to show what a simple, easily understood, efficient and applicable technology XML is...
I'd heard that IBM was basically running Linux inside of an AIX VM, as opposed to directly on the hardware. Is this true, and if so, what do you have to watch out for in terms of performance tuning in order to deal with the vastly different set of latencies presented by a VM, rather than bare x86 metal?
Oh, please. Most people don't love their jobs. They perform them because the money they're paid is worth the effort they invest to get it. Picking a job in a promising field is a "good idea". It's supply and demand, and people who fight against it frequently get the short end of the stick.
Besides, these type of "hot jobs" lists can serve as inspiration to someone looking for a new path. You can't really know if you'd like it until you try.
...a good reason to use an Applet.
Why are classes like Integer so weird? It is such a pain to, for example, increment them...
It's because they're immutable wrappers, just like String is.
[T]here is no way to pass an int by reference.
There's a kinda lame way: int[] intReference=new int[1];
One (public) class per file.
It's so you can swap implementations of individual classes in and out without disturbing the rest of a project. Given, of course, that the class signature doesn't change...
When in doubt, quit your job.
"Now I guess I'll just have to guess where the threshold will be. Anything more than email? Active gamer? Graphic artist?"
...Porno movie fanatic?
I used to do quite a bit of RMI programming. It was a pain in the butt. For any problem of non-trivial complexity, RMI becomes somewhat burdensome. Then I moved on to J2EE, mostly JSP/Servlet stuff with some JDBC, no EJB, and it was a breath of fresh air. It's like the difference between Java 1.0 AWT and 1.1 AWT. Then recently one of our projects called for data sharing between different webapps, and despite my objections RMI was dragged out, and it I found that little has changed. Classpath problems are probably the biggest offenders, even in the JDK 1.2+ "no-classpath" era. It's just not a well-designed spec. It's a shallow OO wrapper over old-school RPC, and, IMHO, is not worth the hassle.
A while back someone told me about Mojo Nation and it seemed pretty nifty. The idea is that users get "mojo" for contributing to the network as a whole, which they cam then "spend" on services that other users provide. It's trying to solve the problem of "freeloaders" on networks such as Gnutella who use lots of bandwidth with searches but basically bog the network down. Capitalism meets P2P. It's kinda-sorta decentralized in that files that are shared are broken down into little (redundant) bits that are stored for retrieval on lots of hosts. Again, neat idea, but the problem I had with it was that it cost mojo to share files! It costs mojo to do anything that uses bandwidth, basically, so users are implicitly discouraged from sharing. Oy vey.
I'd be interested to see how the BSA is planning on getting around that nasty old 4th ammendment issue. I'd love to see an entire city get together and ignore them, and watch the BSA try and get thousands upon thousands of search warrants.
C# has built-in XML parser support. Java has any number of semi-standard packages for XML parsing, like IBM's XML4J. Eh. As a Java developer (yes, working for McNealy's cohort) I can tell you that the real focus has been on the enterprise/web developemnt stuff like J2EE, and a big part of its selling power is that it's a pretty open standard. You can pick and choose your app server, database software, or darn near any other software (or hardware) component, and it should still work. The Java language itself is tres cool, but that's not why business build solutions on it. It's close to the ubiquity and platform-independence of Perl, close to the performance of native code, and close to the code scalability of a pure-OO language. It's a nice compromise, but there will always be languages/environments that do certain things better.
I had an online journal for a while, and the problem that I had with it was that it was difficult being honest in it. I mean, if your life involves the people who would most likely read your journal, you can't exactly be completely up-front, can you? I'd write, sometimes not the most flattering things, and they'd get pissed. Private journals have their merits, too...