Uh, if you're paying the dudes in India how about *they* deal with the timezone problem (by being up at midnight) instead of *you* dealing with the timezone problem.
I agree with the many previous posters that you should explore hiring a local programmer at a reduced wage before going offshore.
However, if you *have* to work with offshore development there's two concrete strategies my intuition (not experience) says would be useful:
1) Use Test First Programming, where you write the tests and the offshore team writes the code.
2) Have the offshore team work on easy non-core tasks initially to gain confidence that they can get the job done before relying heavily on them. These should have very short schedules one or two days, no more than a week.
I've written many thousands of lines of XSLT code. I've grown to really despise XSLT, and I'll offer these cautionary notes... The more logic you have to write, the more you need to think about your use of XSLT. I've found that it's very easy to write hard-to-maintain code in XSLT.
I've also have had to resort to extensions (written in Java) in a number of cases. Not only was this a pain, but it made my XSLT non-portable between Apache's Xalan and Saxon (let alone non-Java processors).
XSLT is great for small XML transformations (and perhaps especially good for HTML generation -- that's NOT what I was doing) -- where small is referring to the number of XSL templates, and the line count of those templates.
Also: a number of people have mentioned the functional nature of XSLT. It also has many declarative aspects: in particular many of your templates are not explicitly called by name, they are implicitly called by rule matching in the template definition. This is one of the aspects of the language that makes building large applications in XSLT difficult (and yet for small scripts this same feature is powerful!).
The greater your ratio between logic : emitted-fragments (ie. HTML), the more caution you need to use with XSLT (and the greater the likelihood your app is better implemented in a language good XML support, Java, C#, Perl, Python).
Finally, I wrote a ~500 line XSLT script and the equivalent transformation in Tcl (+TclDOM). XSLT with Saxon or Xerces took about 3 or 4 seconds to run, Tcl took about 200 milliseconds! So: be aware of the performance aspects of your XSLT engine.
Now that JDOM (an XML API for Java) has XPath support, I'll be far more likely to use Java for many of my XML transformation needs. The coolest thing about XSLT was the fact that it had XPath... now many traditional scripting and OO languages have XPath support which greatly eases XML processing in those languages (much the same way that adding regexp support to a language makes string processing much easier).
It's perhaps unreasonable to expect a great explanation in a short interview, but for someone who's company is "information transfer" Roger has done a pathetic job of conveying what the software fortress model really is.
All he says amounts to "abstraction" and "seperation". Not very insightful. His fortress metaphor is nowhere near as powerful as he seems to think.
Re:This still won't work!
on
Peek-a-Boo(ty)
·
· Score: 1
What about this for a solution: what if you could get a number of significant sites (Yahoo, Hotmail, Slashdot, CommiesRUs.com) to add an extra piece of meta-data to their index.html?
Surely you could make a good argument that these companies could economically benefit from the potential long-term political consequences (present business loss in China aside).
Then you could obtain a list of nodes (or one of a rotating list of nodes) from a legitate site.
Of course, digital signatures are not going to solve the problem that a repressive government may modify (and then re-encrypt) the pages in question and place fake, trap node addresses to catch users of the Peek-A-Booty (or other) network.
Where can I find information (books, papers) describing building applications for systems of that size (64-way UltraII machines)?
I have no idea how such beasts are used... is there one kernel running on each processor? Do you have to link with special Sun libraries for any application?
Trust ME: walk out as soon as David and his mom go to the forest. I would have much prefered to leave everything else to my imagination because Spielberg's version sucked more than I can possibly articulate.
"The popularity of programming languages and other technologies has next to nothing to do with technical considerations and everything to do with the same instinct that makes 13-year-old girls decide they all like Britney Spears simultaneously."
Damn that's good! Right-on. That makes it into my awesome-quotes file.
http://www.immersion.com/ I tried this out at the Game Developer Conference a few months back. It rocks rocks *rocks*. The demos they have were amazing, it was not just "you hit the side of the screen", you could feel the dynamics of swinging a ball at the end of a rope.
Re:Obselence -- Something to fear?
on
Too Old To Code?
·
· Score: 2
As programmers we face the problem that being highly successful at one company, becoming the guru of all the technologies that make that company successful may not necessarily translate to highly valuable skills outside of that company.
So we're in the continual position of having to assess which new technologies are not only going to be relevant to our company, but the industry as a whole -- this is incredibly difficult.
I'm only 25 and I've already had this happen to me also (was C-guru, but few of the jobs I find exciting are using it); now I'm becoming a Java guru (and if you think that's easy, you're kidding yourself).
You'll never have time to keep up with every new technology that might pan out to be critical to the industry in the future. Can any 40+ developers who feel there careers are thriving provide insight as to what has helped most? Degrees? Certifications? Ability to work with the young'uns?
Slashdot Mirror
Finally, a Sawfish guru: How do I move windows between workspaces using the keyboard?
Uh, if you're paying the dudes in India how about *they* deal with the timezone problem (by being up at midnight) instead of *you* dealing with the timezone problem.
I agree with the many previous posters that you should explore hiring a local programmer at a reduced wage before going offshore.
However, if you *have* to work with offshore development there's two concrete strategies my intuition (not experience) says would be useful:
1) Use Test First Programming, where you write the tests and the offshore team writes the code.
2) Have the offshore team work on easy non-core tasks initially to gain confidence that they can get the job done before relying heavily on them. These should have very short schedules one or two days, no more than a week.
I've written many thousands of lines of XSLT code. I've grown to really despise XSLT, and I'll offer these cautionary notes... The more logic you have to write, the more you need to think about your use of XSLT. I've found that it's very easy to write hard-to-maintain code in XSLT.
I've also have had to resort to extensions (written in Java) in a number of cases. Not only was this a pain, but it made my XSLT non-portable between Apache's Xalan and Saxon (let alone non-Java processors).
XSLT is great for small XML transformations (and perhaps especially good for HTML generation -- that's NOT what I was doing) -- where small is referring to the number of XSL templates, and the line count of those templates.
Also: a number of people have mentioned the functional nature of XSLT. It also has many declarative aspects: in particular many of your templates are not explicitly called by name, they are implicitly called by rule matching in the template definition. This is one of the aspects of the language that makes building large applications in XSLT difficult (and yet for small scripts this same feature is powerful!).
The greater your ratio between logic : emitted-fragments (ie. HTML), the more caution you need to use with XSLT (and the greater the likelihood your app is better implemented in a language good XML support, Java, C#, Perl, Python).
Finally, I wrote a ~500 line XSLT script and the equivalent transformation in Tcl (+TclDOM). XSLT with Saxon or Xerces took about 3 or 4 seconds to run, Tcl took about 200 milliseconds! So: be aware of the performance aspects of your XSLT engine.
Now that JDOM (an XML API for Java) has XPath support, I'll be far more likely to use Java for many of my XML transformation needs. The coolest thing about XSLT was the fact that it had XPath... now many traditional scripting and OO languages have XPath support which greatly eases XML processing in those languages (much the same way that adding regexp support to a language makes string processing much easier).
It's perhaps unreasonable to expect a great explanation in a short interview, but for someone who's company is "information transfer" Roger has done a pathetic job of conveying what the software fortress model really is.
All he says amounts to "abstraction" and "seperation". Not very insightful. His fortress metaphor is nowhere near as powerful as he seems to think.
What about this for a solution: what if you could get a number of significant sites (Yahoo, Hotmail, Slashdot, CommiesRUs.com) to add an extra piece of meta-data to their index.html?
Surely you could make a good argument that these companies could economically benefit from the potential long-term political consequences (present business loss in China aside).
Then you could obtain a list of nodes (or one of a rotating list of nodes) from a legitate site.
Of course, digital signatures are not going to solve the problem that a repressive government may modify (and then re-encrypt) the pages in question and place fake, trap node addresses to catch users of the Peek-A-Booty (or other) network.
And how does CoreFire differ from HDLs like VHDL and Verilog?
I read that as "World's First XP System Solid". I thought they were still a few years from a solid OS.
That was too easy. Mod me down, please.
Where can I find information (books, papers) describing building applications for systems of that size (64-way UltraII machines)?
I have no idea how such beasts are used... is there one kernel running on each processor? Do you have to link with special Sun libraries for any application?
URL???
Trust ME: walk out as soon as David and his mom go to the forest. I would have much prefered to leave everything else to my imagination because Spielberg's version sucked more than I can possibly articulate.
Maybe they could throw a couple of those bad-boys to addresss the problem of their /.ed web site?
After you've read the Maggs article check out the fascinating interview he has with Brian Kernighan... http://www.cs.cmu.edu/~mihaib/kernighan-interview/ index.html
(It was actually posted on /. Sep 2000)
Whenever I click the "buy" button all I get is failure messages from WebObjects. Very professional.
Call it WeThe_MPAA_Are_MotherFuckers.zip
I'd like to see that in all their court documents.
I've just put it on napster as decss_source_descramble.mp3
"The popularity of programming languages and other technologies has next to nothing to do with technical considerations and everything to do with the same instinct that makes 13-year-old girls decide they all like Britney Spears simultaneously."
Damn that's good! Right-on. That makes it into my awesome-quotes file.
64-bit processor I understand (the memory and I/O bus are 64 bits, right?). What makes a 64-bit OS so drastically different from a 32-bit OS?
http://www.immersion.com/ I tried this out at the Game Developer Conference a few months back. It rocks rocks *rocks*. The demos they have were amazing, it was not just "you hit the side of the screen", you could feel the dynamics of swinging a ball at the end of a rope.
So we're in the continual position of having to assess which new technologies are not only going to be relevant to our company, but the industry as a whole -- this is incredibly difficult.
I'm only 25 and I've already had this happen to me also (was C-guru, but few of the jobs I find exciting are using it); now I'm becoming a Java guru (and if you think that's easy, you're kidding yourself).
You'll never have time to keep up with every new technology that might pan out to be critical to the industry in the future. Can any 40+ developers who feel there careers are thriving provide insight as to what has helped most? Degrees? Certifications? Ability to work with the young'uns?