Following the specs to the letter without discussion is a sign of either poor pay or poor management. A poor manager is one who gives out specs and expects them to be followed without question. That's not what a (good) developer (or development team) would ever do.. that's what a "programmer" would do. If you're being poorly managed or not paid enough, why argue with the manager.. it's a lot easier just to follow the bad specs and render yourself blameless even if the job turns out bad. Indeed, I'd say at least 50% of development budgets are spent on projects which never see the light of day due to this problem.
Opinion isn't IP though, surely? If you say to someone that "a green shirt would look good on you", and they then buy a green shirt.. you can't sue them for infringing on your ideas, as ideas aren't copyrightable, only distinct implementations. Someone giving a business (or product) suggestions on a weblog would be much the same, I'd guess.
It's been a maxim in customer service for a very long time that a single angry customer cancels out the effect of twenty (or insert some 10 thousands of happy customers, simply because so many people are using the Internet for research now. We had an issue with Acer lately, started a campaign, got some great positions on general Acer related keywords on Google (thanks to a blog), and even ran some Adwords slating them. Hopefully it lost them quite a few sales.
Likewise, I had an issue at a Travelodge motel, and they did not acknowledge my complaint at all. My story (on my blog) was picked up by a newspaper here in the UK and suddenly Travelodge were very apologetic. That said, Travelodge did a very good job of accomodating us, and my faith in them is very much renewed.
But, yes, blogs really amplify opinion, especially if it gets picked up by Google nicely;-) (There was also the case of the lock company whose locks could be picked with a biro pen, they failed to rectify the situation, and the blogosphere hit them hard.)
I actually like the urinal ones. It gives you something more interesting than your own codpiece to look at (as well as your neighbouring urinators). I always appreciate it when restaurants/bars/etc have wacky stuff on the walls near the urinals.
Luckily, coding for FireFox is almost the same as coding for standards. I can't immediately think of any commonly-used features that are FireFox specific, and essential to viewing a site (the moz rounded corners don't count as essential;-))
Perhaps what they're really trying to say is that 10% of the sites are IE-specific, as if a site does not work in FireFox, it is unlikely to work in Safari, Opera, and other browsers. It's not a FireFox specific problem.
This is somewhat similar to the UK self assessment system. No such thing as state taxes in the UK, so it's all just one system.
Many self employed people simply scribble in their earnings, their losses, and their profit.. and if they send it back by September (rather than January) the tax office will work out the tax on your behalf. If your profit is over a certain amount, you also have to fill out a few more boxes explaining what sorts of expenses you had, but it's pretty simple. You can even do it online.
You said RoR was a "programming language".. demonstrating you haven't read the rest of the thread. Not an attack or a flame, but if you're not trolling, it's hard to tell.
"it's a framework around Ruby."
Which. Means. What. ?
If you don't know what "framework" means in relating to coding, this is not the article, book, or topic for you.
Right tool, for the right job, for the right (development) price.
We can agree on that. This is why I use other languages in ancillary systems around some of my Rails applications as Rails has a very specific domain.
It's VERY dependent on what your app does, but if I've guessed correctly, your example would be something like this with Rails.
def cancelAll
TimerCollection.find(:id => params[:id]).tasks.each { |t| t.cancel } end
Find a timercollection with a certain idea, then iterate through each of its tasks and cancel them. Ruby is more wordy than Java 1.5, but this aids readability.
Test-write-test development cycles do this, regardless of the language or development 'style'. What you're saying is that RoR does not *prevent* this dev cycle form being employed. This is good to know, but hardly unique to RoR.
You have clearly never used Rails. Testing is very specifically implemented in Rails, it's actually part of the "way" of doing things.
I understand that RoR is a mature programming language in that it offers layers of abstraction. Get in line behind half a dozen other solutions.
RoR is not a "programming language", it's a framework around Ruby. Now you're just trolling with no knowledge of the subject at hand, so I'll stop.
I'd consider Java slow because, well, it's so involved. It's not a simple download, tweak of Apache, and I'm running.. it's a go through Sun's weird T&Cs, download using some weird download manager, install, do some research as to what a servlet is and how it relates to Java, find out what beans are, then find out there's no mod_java (or similar) for running JSPs (then, again, find out what this means) and that I have to get Tomcat. Work out how to install Tomcat.. and, well, it goes on and on.
With Ruby on Rails, you can type a few lines at the prompt and have a whole database accessible app scaffolded for you, and can work from there. I'm not saying this makes RoR "better" than Java, but it's a whole lot more pragmatic, and I'm a very pragmatic person so is better for *me*, even if it sucks for the enterprise.
And regarding app integration.. Ruby is rapidly becoming a Perl-like language for UNIX-based hackery. Of course, if you're more into developing fully fledged apps, this might not appeal to you.
Rails was originally extrapolated from a Web application called BaseCamp, a project management system written in Ruby. From what I understand, this framework was considered to make Ruby a lot more efficient to develop Web applications.. thereby putting it "on rails", as it were.
You'd be surprised. A lot of supposedly OOP code is written in a horribly procedural fashion even nowadays. I'd guess this is because the most popular OOP languages encourage it, by mixing procedural languages with OOP.. such as VB or Delphi.
The business analysis: If you're working on high-end enterprise apps, or apps that demand a very long term investment, I'd say stick with JSP. Rails isn't there yet. If you're working on Web apps with a small(ish) development team and are mostly concerned with getting something out there that's secure, quick, and full featured quickly then Rails is, really, the only way to go.
The coding analysis: Ruby has a lot of semantic advantages over Java. It's easier to read, has less syntactic salt, and encourages test-driven development a lot more. It's also easier to migrate to from other languages, and most RoR coders are very recent migrants from either Java, PHP or Perl. RoR is easier than Java, and in many cases this would mean "better", but... "better" is highly subjective. I'd still say Java is preferable at enterprise level, but Rails more than has its place, and kicks Java's butt when it comes to rapid, reliable development with a small team.. but Java.. it's all about the enterprise.
The problem is that most incoming developers are coming from TMTOWTDI languages or are not initimitely familiar with OOP. Ruby's flexibility allows you to code in a somewhat C/Perl-esque "by the seat of your pants" fashion if you want, but it heavily encourages doing things in a very object-oriented test-driven way. Books and tutorials are necessary to beat this into the heads of incoming developers. An MVC framework is not a new idea and Rails is by no means the first, but it's the first to be picking up such novice coders. Tutorials are essential. When I started Rails eight months ago, there was no third party documentation or tutorials.. and I'm still correcting my bad habits even now.
And, well, basic documentation is necessary everywhere. People know they shouldn't kill each other or commit adultery, yet billions around the world still keep a Bible/Koran/Torah handy.
That's incorrect. Even if we assume your statement is true, RoR offers "little more" in the same way that C++ offers "little more" over C.
Rails is a flexible framework that allows you to keep your house in order when coding Web applications and which encourages test driven development. Ruby, as a language, makes this all very easy as almost everything in Ruby is an object, so the syntax becomes intuitive. Some people tried to replicate RoR with PHP, and the syntax was vile and full of syntactic salt.
Using Rails to develop Web apps, as opposed to, say, PHP, is like using a language that has garbage collection over one that does not. It removes another level of complexity and lets you focus on the important stuff.
Since 1000 people bought the book within the first week or two, I guess not. We have more than 200 people in #rubyonrails on irc.freenode.net alone, and this makes up a fraction of the community.
Incorrect. If you buy the book now, you'll get the beta PDF and the book when it comes out. Likewise, if you just buy the PDF, you'll get the full PDF when it's all done. You are not just buying a beta in either case.
Acer deserve the bottom place in this experiment. My father's Aspire failed six months after he bought it, and he sent it back. It took almost three months, a gang of lawyers, and an Internet campaign to get it back from them fully repaired.
We rapidly found out that other people had had even worse problems, and that Acer's support system is not to be relied upon to get the job done quickly. As such, I've been put off a manufacturer that had previously seemed decent. Avoid at all costs.
Page 131 is a half-blank page whose top half explains some of what was covered in the previous chapter. There is no code. This is the case in both beta 1 and beta 2 of the book.
I'm really surprised because even though I love OpenOffice and hate Microsoft Office, I've always found OO to be significantly slower to load. Once loaded, it's fine, but Word is significantly quicker to load on the systems I've used.
Following the specs to the letter without discussion is a sign of either poor pay or poor management. A poor manager is one who gives out specs and expects them to be followed without question. That's not what a (good) developer (or development team) would ever do.. that's what a "programmer" would do. If you're being poorly managed or not paid enough, why argue with the manager.. it's a lot easier just to follow the bad specs and render yourself blameless even if the job turns out bad. Indeed, I'd say at least 50% of development budgets are spent on projects which never see the light of day due to this problem.
Yes, I did. I also agree this is very important. I posted some extra posts on my blog about the issue too. (Ditto for the Acer debacle.)
Opinion isn't IP though, surely? If you say to someone that "a green shirt would look good on you", and they then buy a green shirt.. you can't sue them for infringing on your ideas, as ideas aren't copyrightable, only distinct implementations. Someone giving a business (or product) suggestions on a weblog would be much the same, I'd guess.
It's been a maxim in customer service for a very long time that a single angry customer cancels out the effect of twenty (or insert some 10 thousands of happy customers, simply because so many people are using the Internet for research now. We had an issue with Acer lately, started a campaign, got some great positions on general Acer related keywords on Google (thanks to a blog), and even ran some Adwords slating them. Hopefully it lost them quite a few sales.
;-) (There was also the case of the lock company whose locks could be picked with a biro pen, they failed to rectify the situation, and the blogosphere hit them hard.)
Likewise, I had an issue at a Travelodge motel, and they did not acknowledge my complaint at all. My story (on my blog) was picked up by a newspaper here in the UK and suddenly Travelodge were very apologetic. That said, Travelodge did a very good job of accomodating us, and my faith in them is very much renewed.
But, yes, blogs really amplify opinion, especially if it gets picked up by Google nicely
I actually like the urinal ones. It gives you something more interesting than your own codpiece to look at (as well as your neighbouring urinators). I always appreciate it when restaurants/bars/etc have wacky stuff on the walls near the urinals.
Luckily, coding for FireFox is almost the same as coding for standards. I can't immediately think of any commonly-used features that are FireFox specific, and essential to viewing a site (the moz rounded corners don't count as essential ;-))
Perhaps what they're really trying to say is that 10% of the sites are IE-specific, as if a site does not work in FireFox, it is unlikely to work in Safari, Opera, and other browsers. It's not a FireFox specific problem.
This is somewhat similar to the UK self assessment system. No such thing as state taxes in the UK, so it's all just one system.
Many self employed people simply scribble in their earnings, their losses, and their profit.. and if they send it back by September (rather than January) the tax office will work out the tax on your behalf. If your profit is over a certain amount, you also have to fill out a few more boxes explaining what sorts of expenses you had, but it's pretty simple. You can even do it online.
You said RoR was a "programming language".. demonstrating you haven't read the rest of the thread. Not an attack or a flame, but if you're not trolling, it's hard to tell.
"it's a framework around Ruby."
Which. Means. What. ?
If you don't know what "framework" means in relating to coding, this is not the article, book, or topic for you.
Right tool, for the right job, for the right (development) price.
We can agree on that. This is why I use other languages in ancillary systems around some of my Rails applications as Rails has a very specific domain.
It's VERY dependent on what your app does, but if I've guessed correctly, your example would be something like this with Rails.
def cancelAll
TimerCollection.find(:id => params[:id]).tasks.each { |t| t.cancel }
end
Find a timercollection with a certain idea, then iterate through each of its tasks and cancel them. Ruby is more wordy than Java 1.5, but this aids readability.
I don't think Java is given enough credit.
You are probably right there.
Test-write-test development cycles do this, regardless of the language or development 'style'. What you're saying is that RoR does not *prevent* this dev cycle form being employed. This is good to know, but hardly unique to RoR.
You have clearly never used Rails. Testing is very specifically implemented in Rails, it's actually part of the "way" of doing things.
I understand that RoR is a mature programming language in that it offers layers of abstraction. Get in line behind half a dozen other solutions.
RoR is not a "programming language", it's a framework around Ruby. Now you're just trolling with no knowledge of the subject at hand, so I'll stop.
I'd consider Java slow because, well, it's so involved. It's not a simple download, tweak of Apache, and I'm running.. it's a go through Sun's weird T&Cs, download using some weird download manager, install, do some research as to what a servlet is and how it relates to Java, find out what beans are, then find out there's no mod_java (or similar) for running JSPs (then, again, find out what this means) and that I have to get Tomcat. Work out how to install Tomcat.. and, well, it goes on and on.
With Ruby on Rails, you can type a few lines at the prompt and have a whole database accessible app scaffolded for you, and can work from there. I'm not saying this makes RoR "better" than Java, but it's a whole lot more pragmatic, and I'm a very pragmatic person so is better for *me*, even if it sucks for the enterprise.
And regarding app integration.. Ruby is rapidly becoming a Perl-like language for UNIX-based hackery. Of course, if you're more into developing fully fledged apps, this might not appeal to you.
Rails was originally extrapolated from a Web application called BaseCamp, a project management system written in Ruby. From what I understand, this framework was considered to make Ruby a lot more efficient to develop Web applications.. thereby putting it "on rails", as it were.
You'd be surprised. A lot of supposedly OOP code is written in a horribly procedural fashion even nowadays. I'd guess this is because the most popular OOP languages encourage it, by mixing procedural languages with OOP.. such as VB or Delphi.
The business analysis: If you're working on high-end enterprise apps, or apps that demand a very long term investment, I'd say stick with JSP. Rails isn't there yet. If you're working on Web apps with a small(ish) development team and are mostly concerned with getting something out there that's secure, quick, and full featured quickly then Rails is, really, the only way to go.
The coding analysis: Ruby has a lot of semantic advantages over Java. It's easier to read, has less syntactic salt, and encourages test-driven development a lot more. It's also easier to migrate to from other languages, and most RoR coders are very recent migrants from either Java, PHP or Perl. RoR is easier than Java, and in many cases this would mean "better", but... "better" is highly subjective. I'd still say Java is preferable at enterprise level, but Rails more than has its place, and kicks Java's butt when it comes to rapid, reliable development with a small team.. but Java.. it's all about the enterprise.
The problem is that most incoming developers are coming from TMTOWTDI languages or are not initimitely familiar with OOP. Ruby's flexibility allows you to code in a somewhat C/Perl-esque "by the seat of your pants" fashion if you want, but it heavily encourages doing things in a very object-oriented test-driven way. Books and tutorials are necessary to beat this into the heads of incoming developers. An MVC framework is not a new idea and Rails is by no means the first, but it's the first to be picking up such novice coders. Tutorials are essential. When I started Rails eight months ago, there was no third party documentation or tutorials.. and I'm still correcting my bad habits even now.
And, well, basic documentation is necessary everywhere. People know they shouldn't kill each other or commit adultery, yet billions around the world still keep a Bible/Koran/Torah handy.
That's incorrect. Even if we assume your statement is true, RoR offers "little more" in the same way that C++ offers "little more" over C.
Rails is a flexible framework that allows you to keep your house in order when coding Web applications and which encourages test driven development. Ruby, as a language, makes this all very easy as almost everything in Ruby is an object, so the syntax becomes intuitive. Some people tried to replicate RoR with PHP, and the syntax was vile and full of syntactic salt.
Using Rails to develop Web apps, as opposed to, say, PHP, is like using a language that has garbage collection over one that does not. It removes another level of complexity and lets you focus on the important stuff.
Since 1000 people bought the book within the first week or two, I guess not. We have more than 200 people in #rubyonrails on irc.freenode.net alone, and this makes up a fraction of the community.
Incorrect. If you buy the book now, you'll get the beta PDF and the book when it comes out. Likewise, if you just buy the PDF, you'll get the full PDF when it's all done. You are not just buying a beta in either case.
No, the previous article was about how books are now being developed with "beta versions" coming out.. this book being an example of the process.
Acer deserve the bottom place in this experiment. My father's Aspire failed six months after he bought it, and he sent it back. It took almost three months, a gang of lawyers, and an Internet campaign to get it back from them fully repaired.
We rapidly found out that other people had had even worse problems, and that Acer's support system is not to be relied upon to get the job done quickly. As such, I've been put off a manufacturer that had previously seemed decent. Avoid at all costs.
It's missing a single colon, or a colon and quotation marks:
Dell: We'd Sell Mac OS X or Dell: "We'd Sell Mac OS X"
But yeah, it's sloppy.
What are you on about?
Page 131 is a half-blank page whose top half explains some of what was covered in the previous chapter. There is no code. This is the case in both beta 1 and beta 2 of the book.
I'm really surprised because even though I love OpenOffice and hate Microsoft Office, I've always found OO to be significantly slower to load. Once loaded, it's fine, but Word is significantly quicker to load on the systems I've used.
..is how this guy's server is still maxing out my bandwidth while downloading the video, and yet we're more than two posts into the thread. Bravo!