Computer Science is a study of math, not computers. Computers are the the tool that enables you to carry out the algorithms that Computer Scientists discover.
If you're saying math is entirely man-made, that's a bit of a stretch. The properties of numbers, the algorithms are out there, we just have to discover them.
Telescopes are not necessarily the only to view space. Computers aren't the only to find the results of an algorithm. They're the best tools for the job, but they aren't the only ones.
A salesman (not for Dell obviously) once told me that Dell sometimes uses refurbished parts in new machines, and that it's mentioned in their Terms of Sale. Sure enough, the terms contained this:
> Dell will ship products that have the functionality and performance of the products ordered, but changes between what is shipped and what is described in a specification sheet or catalogue are possible. The parts and assemblies used in building Dell products are selected from new and equivalent-to-new parts and assemblies in accordance with industry practices. Spare parts may be new or reconditioned.
So how suspect is this? I have a feeling the salesman was blowing smoke because he couldn't match Dell's price. I haven't been able to find many complaints about this clause anywhere on the net.
It's simple physics... The car MUST absorb all of the impact in a crash. If it doesn't, then the passengers will take all of the impact. There's no way around it.
Do scientists get paid to work these kinda tongue-in-cheek problems? Or do they work on these when they're bored and put them out for fun and a little publicity?
Almost did a spit-take when I read the subject. Struts was great 4 years ago, but I'd hope that people have moved on by now (at least for new projects).
Why did you pass on Ruby on Rails? As far as MVC goes, RoR offers pretty much the same abstraction, but without all tedious elements (configuration and the awful ActionForm class). Plus it includes a great database abstraction.
As others have suggested, be VERY suspicious if it isn't an incremental switchover. I have a feeling that won't happen for you, and the offshore company is going to enjoy your company's money a lot.
When it all goes wrong, please do a little write up of the events and submit it to The Daily WTF.
So what if one of your workers gets sick, pregnant, or life just gets in the way somehow? No bonus for them even if they did work hard while they could?
Rarely do things like this get done if you just talk about them... If the higher ups are ignorant of the benefits, you aren't going to convince them with words. Set up bug tracking/version control and use it. Don't speak up about it, but don't hide it either. Eventually, you'll be asked about it or you'll find an opportunity to say why these things are making life better, and that's when you do the convincing.
> In the end, Ruby is just a MVC and ORM web framework, along with a little bit of code generation to get you started.
Don't forget about testing... The testing framework is probably the best part of the framework, and not enough people are talking about it.
But int the end, Rails is more than just MVC + ORM + Code Generation + Testing. Rails is greater than the sum of its parts. Having all of those thing in one cohesive framework is much better than cobbling together a stack of tools to do the same thing.
Well, it's not really a standalone server... FastCGI in external mode isn't like Tomcat where you have a fully functional server. You still need Apache or lighttpd, but FastCGI/Rails itself is running in a separate process from httpd, and it isn't managed by httpd.
I'll give you the quick version of the configuration. Start with a working FastCGI/Apache configuration. In your httpd.conf, you'll have a FastCgiServer directive somewhere... That gets changed to a FastCgiExternalServer directive that looks like this:
The -host bit is important - it tells apache where you're running the external server. In this case, it's running on localhost, port 9036. (You can also communicate over a socket, which is probably better if the external server is running on localhost.)
Then you to start your FCGI external server... It's pretty easy, you just need a wrapper script for the cgi-fcgi command. My current one looks like this:
FastCGI is actually pretty nice when you use it in external mode rather than static or dynamic. When running in external mode, you don't have to run your app as apache (or nobody or whatever the webserver's user is). You can run it as a different user account and connect it with Apache (just like I can do with Tomcat).
Unfortunately, there's no mention of this option in the rails documentation, and there's only a few hints & tips out there for getting it set up. I'm still playing with the configuration myself, but I plan on writing something up once I've got it down.
There are other Tomcat features that you don't get with fcgi, but I don't really miss them.
But what about bringing the database to a known state before your test? Then you need another tool, something like DBUnit.
And if your functional tests are running Cactus and hitting a database, those tests are gonna be slowwww... They need to be fast if we want them to be run frequently, so now we need to add a mock object framework too...
Rails has all of this taken care of already. If you'd rather put together a stack of tools yourself, that's fine. But that's another X days to add to the start of your project. And when you hire someone new, expect it to take longer to get them on the same page.
Code Complete by Steve McConnell The Pragmatic Programmer by Andrew Hunt and Dave Thomas Refactoring: Improving the Design of Existing Code by Martin Fowler The Mythical Man Month by Fred Brooks
The are a few off the top of my head that any programmer should read. I'm sure there are a few others. Most things after that are probably specific to certain areas and interests.
... in different situations. Or maybe I just have different expectations for different types of beta products.
As an example, look at a free web app. It should be easy to deploy new features quickly. It should be easy to fix bugs and release them to the user quickly. An extended "beta" period is okay as long as there's constant improvement and the number of defects is kept low. Users will tolerate a bump in the road every once in a while.
With a desktop app where the vendor doesn't have control over the users machines, you can't deploy a new version of your app instantly. That changes everything. I'm expecting a beta release to feature complete (mostly). I'm expecting more defects, but I'm also expecting the focus to be on removing defects, and not adding new features. An extended beta period is bad because it tells me that new bugs are always popping up. But development is proceeding like in my first example (new features and low number of defects), then calling your product a beta may be sending the wrong message.
Then again, if you're continuously adding features and keeping defects low, then "beta" is probably a bad way to describe your product. It's beta, but with a wink or an asterisk at the end.
Stewart bitchslapped Hitchens? I think you need to rewatch that interview. Stewart may have asked him a couple tough questions, but Hitchens answered them. I don't agree with Hitchens, but no bitchslapping took place.
>It's got nothing to do with IP, it's got everything to do with the fact that you've just given away for free a feature that that customer would have almost certainly payed for.
Do you think the company refunded the client for the overestimated hours?
If you have six weeks to get a project done, the only thing you control is your own behavior. Will you get six weeks' worth of work done or less? You can't control others' expectations. You can tell them what you know about the project so their expectations have a chance of matching reality. My terror of deadlines vanished when I learned this lesson. It's not my job to manage someone else's expectations. It's their job to manage their own expectations. It's my job to do my best and to communicate clearly.
Slashdot Mirror
What kind of service requires an SSN? You shouldn't need to give that out for your internet service, for example.
Computer Science is a study of math, not computers. Computers are the the tool that enables you to carry out the algorithms that Computer Scientists discover.
If you're saying math is entirely man-made, that's a bit of a stretch. The properties of numbers, the algorithms are out there, we just have to discover them.
Telescopes are not necessarily the only to view space. Computers aren't the only to find the results of an algorithm. They're the best tools for the job, but they aren't the only ones.
He made that claim, but did little to back it up.
When you are at your peak of efficiency with your preferred language/framework, are even close to that efficient? That should be the yardstick.
A salesman (not for Dell obviously) once told me that Dell sometimes uses refurbished parts in new machines, and that it's mentioned in their Terms of Sale. Sure enough, the terms contained this: > Dell will ship products that have the functionality and performance of the products ordered, but changes between what is shipped and what is described in a specification sheet or catalogue are possible. The parts and assemblies used in building Dell products are selected from new and equivalent-to-new parts and assemblies in accordance with industry practices. Spare parts may be new or reconditioned. So how suspect is this? I have a feeling the salesman was blowing smoke because he couldn't match Dell's price. I haven't been able to find many complaints about this clause anywhere on the net.
It's simple physics... The car MUST absorb all of the impact in a crash. If it doesn't, then the passengers will take all of the impact. There's no way around it.
Does this method affect your night vision? (The LASIK method can negatively affect night vision.)
Do scientists get paid to work these kinda tongue-in-cheek problems? Or do they work on these when they're bored and put them out for fun and a little publicity?
DynaValidatorForm is worse! Well, maybe not, but it's still a pain if you don't like to use BeanUtils.copyProperties.
You should check out RoR on the side... At the very least, it will make you a better Struts programmer.
Almost did a spit-take when I read the subject. Struts was great 4 years ago, but I'd hope that people have moved on by now (at least for new projects).
Why did you pass on Ruby on Rails? As far as MVC goes, RoR offers pretty much the same abstraction, but without all tedious elements (configuration and the awful ActionForm class). Plus it includes a great database abstraction.
As others have suggested, be VERY suspicious if it isn't an incremental switchover. I have a feeling that won't happen for you, and the offshore company is going to enjoy your company's money a lot.
When it all goes wrong, please do a little write up of the events and submit it to The Daily WTF.
> There's nothing rails does that I can't do in as few lines and with better performance using code that I have to hand.
Then release it.
So what if one of your workers gets sick, pregnant, or life just gets in the way somehow? No bonus for them even if they did work hard while they could?
Rarely do things like this get done if you just talk about them... If the higher ups are ignorant of the benefits, you aren't going to convince them with words. Set up bug tracking/version control and use it. Don't speak up about it, but don't hide it either. Eventually, you'll be asked about it or you'll find an opportunity to say why these things are making life better, and that's when you do the convincing.
> In the end, Ruby is just a MVC and ORM web framework, along with a little bit of code generation to get you started.
Don't forget about testing... The testing framework is probably the best part of the framework, and not enough people are talking about it.
But int the end, Rails is more than just MVC + ORM + Code Generation + Testing. Rails is greater than the sum of its parts. Having all of those thing in one cohesive framework is much better than cobbling together a stack of tools to do the same thing.
Well, it's not really a standalone server... FastCGI in external mode isn't like Tomcat where you have a fully functional server. You still need Apache or lighttpd, but FastCGI/Rails itself is running in a separate process from httpd, and it isn't managed by httpd.
/path/to/railsapp/public/dispatch.fcgi -host localhost:9036
I'll give you the quick version of the configuration. Start with a working FastCGI/Apache configuration. In your httpd.conf, you'll have a FastCgiServer directive somewhere... That gets changed to a FastCgiExternalServer directive that looks like this:
FastCgiExternalServer
The -host bit is important - it tells apache where you're running the external server. In this case, it's running on localhost, port 9036. (You can also communicate over a socket, which is probably better if the external server is running on localhost.)
Then you to start your FCGI external server... It's pretty easy, you just need a wrapper script for the cgi-fcgi command. My current one looks like this:
#!/bin/sh
PORT_NUM="9036"
NUM_SERVERS="1"
export RAILS_ROOT="/path/to/railsapp"
export RAILS_ENV="production"
export RAILS_HOST="myvirutalhost.com"
cgi-fcgi -start -connect localhost:${PORT_NUM} $RAILS_ROOT/public/dispatch.fcgi $NUM_SERVERS
That works for me currently... But I'm working on improving the scripts.
The big win is that now you moved the process from apache to a user account. I find that makes automating deployment a lot easier.
FastCGI is actually pretty nice when you use it in external mode rather than static or dynamic. When running in external mode, you don't have to run your app as apache (or nobody or whatever the webserver's user is). You can run it as a different user account and connect it with Apache (just like I can do with Tomcat).
Unfortunately, there's no mention of this option in the rails documentation, and there's only a few hints & tips out there for getting it set up. I'm still playing with the configuration myself, but I plan on writing something up once I've got it down.
There are other Tomcat features that you don't get with fcgi, but I don't really miss them.
But what about bringing the database to a known state before your test? Then you need another tool, something like DBUnit.
And if your functional tests are running Cactus and hitting a database, those tests are gonna be slowwww... They need to be fast if we want them to be run frequently, so now we need to add a mock object framework too...
Rails has all of this taken care of already. If you'd rather put together a stack of tools yourself, that's fine. But that's another X days to add to the start of your project. And when you hire someone new, expect it to take longer to get them on the same page.
Code Complete by Steve McConnell
The Pragmatic Programmer by Andrew Hunt and Dave Thomas
Refactoring: Improving the Design of Existing Code by Martin Fowler
The Mythical Man Month by Fred Brooks
The are a few off the top of my head that any programmer should read. I'm sure there are a few others. Most things after that are probably specific to certain areas and interests.
LOLarious
In fact, it is hilarious enough that the trend may be copied and played out to the point where any posts in this style will be marked as a troll.
... in different situations. Or maybe I just have different expectations for different types of beta products.
As an example, look at a free web app. It should be easy to deploy new features quickly. It should be easy to fix bugs and release them to the user quickly. An extended "beta" period is okay as long as there's constant improvement and the number of defects is kept low. Users will tolerate a bump in the road every once in a while.
With a desktop app where the vendor doesn't have control over the users machines, you can't deploy a new version of your app instantly. That changes everything. I'm expecting a beta release to feature complete (mostly). I'm expecting more defects, but I'm also expecting the focus to be on removing defects, and not adding new features. An extended beta period is bad because it tells me that new bugs are always popping up. But development is proceeding like in my first example (new features and low number of defects), then calling your product a beta may be sending the wrong message.
Then again, if you're continuously adding features and keeping defects low, then "beta" is probably a bad way to describe your product. It's beta, but with a wink or an asterisk at the end.
Ummm... I think that JIT depends just as much on the VM as it does on the compiler (probably more).
Stewart bitchslapped Hitchens? I think you need to rewatch that interview. Stewart may have asked him a couple tough questions, but Hitchens answered them. I don't agree with Hitchens, but no bitchslapping took place.
>It's got nothing to do with IP, it's got everything to do with the fact that you've just given away for free a feature that that customer would have almost certainly payed for.
Do you think the company refunded the client for the overestimated hours?