> Two things. One, please prove that the Debian patches are of > sub-quality. I doubt you will be able to because its simply not true.
One: you can't read. I said that the patches are of questionable quality. Others in this thread have amply proven that Debian makes changes that have destabilized Firefox on Debian. I read the original thread entirely in the Debian bug tracking system. The Mozilla team has definitely looked at some of the differences and found them wanting (the Debian team has, for example, changed how the branding is done rather than using the branding switch that the Mozilla team provided for this very reason).
> Second, the problem Debian is having with it is the fact that they > thought they had already dealt with it. A representative of Mozilla > already came to them and they thought they had a deal where they could > use the name but not the logo and everything would be fine. Now > Mozilla is coming along, very close to the release of Etch, and saying > that that deal doesn't mean anything and now Debian must change. Thats > the hole story.
Yet... if Debian doesn't fix this now, they're breaking trademark issues for years after, given that Debian releases so rarely.
> And saying that Debian is doing a piss-poor job with no proof is really > not right at all.
Except that it's not my claim. It's the claim of the Mozilla developers -- and a lot of people on this very thread.
Debian takes that right very seriously, and it has the right; Mozilla doesn't have a problem with that. However, their unmodified images are part of the branding, and the use of the name with the logo is mandatory as part of the branding. Mozilla's lawyers indicated to them (by my reading of the original thread) that while they *could* trademark the Firefox logo and make it under a modifications-allowed license, they would greatly risk their ability to police and enforce the Firefox logo as a trademark. Similarly, Debian's patches are of questionable quality and necessity and allowing the use of the "Firefox" name with these questionably patched versions would potentially damage the quality of the Firefox mark.
Debian just can't expect to get a free ride for doing a half-job. Or even, as the case appears to be, a quarter-job.
As has been pointed out: Debian takes its image and mark very seriously, too. Why the bitching by Debian supporters when they have to make changes for the very sort of thing that they do themselves?
A fit? No. But Ruby isn't untyped; it is, in fact, very strongly typed. It's just that we don't restrict variables to a single type. We don't even restrict objects from changing their type at runtime (although their class inheritance won't change at runtime...mostly;). In Ruby, a String is always a String and can't be coerced into something else. Converted, yes. Coerced, no.
You're not misunderstanding. ActiveRecord will automatically add those columns. However, unless your application *uses* them, your Rails app will ignore their existence.
If you're arguing about 10% of total coding effort, then why are you arguing this point at all?
As yet, I have not needed to drop down to Ruby's C-level API to implement any of my basic logic. I *have* used interfaces to libraries that others have written (mostly interfaces that have been written for the core, e.g., zlib and syck/YAML), but I have yet to need to write a C-level implementation of code, especially because of speed concerns.
For that 10% of code, you may be right. But that 10% of code doesn't generally involve web applications. At least in my experience.
You may fundamentally disagree that data is king in business. The fact that businesses survived for centuries without computers indicates that your fundament is disagreeing with reality. It is mostly when data has been lost without any way of reconstructing the processes surrounding the data that companies have run into trouble.
If you give me data in a usable form, I can *always* build or rebuild processes and code around that. If you give me code, it will take me far longer to build the data. Your fundament happens to be wrong here. If it's wrong on that, it has a good chance of being wrong elsewhere.
Note that YARV/Rite isn't about JIT for Ruby. If you actually paid attention to Ruby development, instead of spreading FUD and untruths, you might actually know that.
The speed issue is important in Ruby. But don't tell me that Ruby is slow -- I've got experience that indicates otherwise. I won't be programming 3D engines in it any time soon, and I might not want to manipulate a terabyte of data in it, but for many applications, it is more than sufficient. If it takes me an hour to write a Ruby script and three hours to run it, as opposed to five hours to write the same logic in a different language and an hour to run it, I'm still ahead with Ruby.
This isn't a matter of hand-waving. It's a matter of knowing when it's appropriate to apply which performance measures, which your moronic statement "Ruby is slow" can't even approach.
Your statement is completely false and therefore FUD.
Ruby does prize programmer productivity, but nothing says that it doesn't prize a sturdy interface or prize execution speed. I challenge you to actually prove your FUD as fact.
FWIW, if you're following SQL conventions, you shouldn't need to rename your columns. If you're using MySQL as a convention, you'll need to rename your columns. Good practice leads to good portability. MySQL leads to poor portability.
People who don't really know anything about
data modelling and relational theory tend to prefer class-> table
interpretation. People who understand data modelling tend to prefer
table-> class interpretation.
I have to fundamentally disagree here. Even Oracle, who
have a huge vested interest in relational theory, are putting a huge
amount of work into class->table interpretation with projects like
TopLink.
Only because of people who don't know better--which appears to
include you. Class models are inherently tied to a single
application or a small class of applications. Database models are
far more flexible *and should be*. Any monkey can design a class
model that can be used in a single application. It takes someone
with real skill to design a reusable database that can be used in
ways that aren't expected.
Businesses would much rather keep their data
than their programs. Good thing, too. It's the data that makes the
business run, not the programs. (I've known a lot of people who
manage to make things work well with Excel spreadsheets,
clearly indicating that it's the data that's more important.)
I've worked on enough large systems to know this. I've also seen
a series of incompetent idiots try to redesign one system from the
class model first -- and then wondering why the application
was 90% slower than the one I worked on which designed the
database first and then modeled the classes after the
database tables.
This is a straw-man. Ruby most
emphatically is not slow.
It emphatically is! Try
benchmarking something like XML processing (which is an important
part of many current website situations, such as SOAP and Axis).
This does not matter in most situations, but there are occasional
situations where performance matters. Denying this will not help
Ruby.
Ruby is most emphatically not slow. Simply calling Ruby slow
doesn't make it so. Running benchmarks means squat. Ruby's XML
performance varies depending on the library you're using. If you're
using REXML, then *of course* it's going to be a bit (or much)
slower than if you're using the available interface to libxml2.
IIRC, there's several similar problems in Python.
There are definitely things that can be done to improve
the performance of Ruby, and many of these things will be done. Of
that, I have no doubt. But having used Ruby for the last three
years, Ruby is (more often than not) fast enough to do what I need,
and doesn't bring the pain that is involved in writing in a compiled
language or Perl or Python.
Again, I'm not denying that Ruby's performance can be improved.
If you read that out of what I've said, you're clearly trolling and
FUDding. But I also know that the development velocity I have with
Ruby is much higher than that which I have with any other
language, just as Perl was faster for me before I discovered
Ruby.
Rails, on the other hand, is probably
appropriate for small-to-medium database-backed web
applications.
Quite the reverse. Only with a decent
mapping layer can it be robust enough for medium or large-scale
use.
It has a robust mapping layer, or weren't you reading? (I
suspect the latter.) It also doesn't make you create your
databases from scratch (but it means a bit more code configuration
to make that happen), which is what class->table systems require by
and large. Rails is appropriate for small-to-medium database-backed
web applications. I wouldn't call the number of hits received by
43places or 43things insignificant. Neither would you, if you
actually bothered to read what the developers of these
applications -- who are accomplished developers who have used many
other frameworks and environments in the past -- have had to say
themselves.
As with everything, that depends on what you're doing.
There are things that one can do where Ruby outperforms both Python and Perl.
This isn't saying that Ruby can't be faster, but making it clear that simply saying "Ruby is slow" or "Ruby is slower..." isn't necessarily true.
One also has to compare development costs (high) with deployment costs (variable). If I can develop several times faster with Ruby, the cost difference may be significant.
There is no downside
to using ruby on rails. Closest thing to a silver bullet since the web
came out.
There are several significant downsides to
using Ruby on Rails.
Firstly, the way that ActiveRecord works by
default - generating classes at run-time based on database tables - is
considered by many (well, me at least!) to be a very backward step, as
it makes code vunerable to changes in those tables, and also makes
portability of code between different databases non-trivial. There are
far better ways to do this - the Python ORM Dejavu (in in which the data
model is expressed as classes) is an example. Almost all modern
development languages work this way - with the exception of
RoR!
Expressing the data model as classes can be done using Og (or Nitro+Og), and I believe that Og can
be used as an alternative interface to Rails with just a bit of work.
However, Rails does this (mostly) the right way, since
your data is always more valuable than your
application. Where this approach falls down is based on a couple of
things:
Rails uses MySQL as its “correct” database. MySQL is
not and never has been good, just ubiquitous. There are some
very broken concepts in ActiveRecord because of this assumption.
Migration is difficult, as it is done externally to the
application.
People who don’t really know anything about data modelling and
relational theory tend to prefer class->table interpretation. People who
understand data modelling tend to prefer table->class interpretation.
There’s room for both, but the preferred method—and the
more portable method—is to treat the database as the
authoritative model for the application, not the other way around. (Yes,
reading the database model is more portable than creating the database
from the application. Especially with a dynamic language like Ruby.)
Secondly, Ruby is slow. There may be future JIT
systems that help deal with this, but they are not there
yet.
This is a straw-man. Ruby most emphatically is not
slow. It is also not the fastest performer. But for what RoR does, it is
generally fast enough. If you’re using the MySQL adapter,
you definitely want to make sure that you’re using the
native adapter, not the pure Ruby
adapter. I’m developing one of the more complex
applications/libraries in Ruby (PDF::Writer) and
while I won’t pretend that it’s a speed demon, it’s
impressively fast for what it does do, complete with
rollback for the layout handling. Ruby’s performance is more than
adequate for most applications, especially most database-backed web
applications.
Thirdly, Ruby is changing, and it is likely
(from what I read) that the next version will not be fully compatible,
so any major project developed now in Rails will have upgrading
issues.
Probably not. I suspect that there will be 80% or more compatibility,
based on the currently submitted RCRs that have positive response. I
also expect that the RoR community will make sure that Rails runs well
on whatever the current version of Ruby is. I believe that some
work has been done to make sure that RoR works well on Ruby 1.9, which
is the test bed environment for most of the syntax changes that will be
coming with Ruby 2.0.
So Ruby on Rails is very far from a silver
bullet. It may a neat way to get small (in terms of code) websites up
quickly.
I agree with your first sentence. I disagree with your second, at
least partially. RoR—and Ruby in general—makes a lot of code
smaller and easier to maintain. Ruby isn’t the
1. I don't believe your SOAP comment is correct. Remember, ROR doesn't provide SOAP per se; it's SOAP4R that does. ROR may provide basic SOAP4R capabilities, but that in no way means that it's using 100% of the features. The ROR team may have decided that the typical use of SOAP with a ROR site is likely to be 25% of the SOAP capabilities. You can *still* do the full SOAP support -- you just have to work a bit harder on it.
2. Yes, but J2EE is an overblown, overladen framework to begin with. When people need queueing and remoting technologies with ROR, it will be added. In fact, the remoting technology -- at least in part -- is already there through DRb (if you haven't looked at it, you should) and Florian Groß's breakpoints code. I would strongly disagree with your assertion that the J2EE components for these are "comprehensive" and especially "unified."
3. Again, you *can* do field name mapping, but it's a bit more work to do so. There's no reason you can't create aliases, e.g.:
Field name mapping is easy; not as easy as simply following the Rails model, but it's *easy*. SOAP is a bit harder, and other stuff maybe a bit harder still. It's all still easier than trying to pick up all of J2EE.
Full disclosure: I don't particularly like the Rails way of doing things with databases, because it bases its data interaction semantics as if MySQL were a good (rather than an "easy") database.
That said:
Ruby has SOAP capabilities and it's built into the core of Ruby (SOAP4R). Just because someone has not yet seen fit to mix ROR and SOAP doesn't mean it can't be done.
Ruby can do RMI/remote invocations through DRb or other mechanisms. Of course it can't do Java RMI without a JNI connector, but those JNI connectors are available -- and there's even a nascent JWDP connector for additional interaction with Java.
There is some queueing technology available for Ruby. I haven't had a need for it, but it's available. Or buildable.
ROR prefers you to design the database from scratch, but it certainly doesn't prevent you from using an existing database and doing a bit of extra coding to make it Just Work. The good thing about ROR is that it uses sane defaults to make the common brain-dead simple. You can manually implement a mapping. There might be room for an easier mapping mechanism in cases like this (rather than defining self.table_name and self.primary_key), but as ROR is still an evolving framework, that's not a big deal.
The assessment on the Rails blog is, I think better. The numbers are impressive but meaningless -- there are tweaks that can be done in any case. The real point is that this shows that Ruby Isn't Slow and that Rails (or any other application environment) can be used in a production environment.
Oy. You answered without answering or understanding.
I don't actually like placing the restrictions of the GPL on my software, most of the time. I put it out there to be used. My preferred restrictions are captured in the BSD or MIT licences: don't pretend that you wrote my software, but use it as you wish; don't come looking to me when it blows up, though, because I'm not offering any warranty on my software. I would *like* credit, but I don't need it.
I would *like* people to continue sharing derivatives of my software, but I don't need them to do so -- because my original software remains available.
Even when I want to place such restrictions, I prefer not using the GPL because it is a political document more than it is a usable licence; other licences capture the essence of the GPL (or in the case of the MPL, a better concept than the GPL) without political garbage that I neither want nor need in my licences.
> The GPL is in no way different from the BSD licenses when you don't > modify and distribute the (compiled) source code. The GPL grants the > freedoms that RMS considers important for software and in my opinion > - "The freedom to take source code and redistribute it in a form that > does not grant freedom" is not an important freedom at all. So the > GPL is perfectly free. Additionally it enforces freedom for derived > works.
Bullshit and you know it. This is the sort of DoubleSpeak that I was talking about. The GPL is an encumbered license. This is not a bad thing, as some people think that the restrictions offered by the licence (e.g., ensures the availability of the source to downstream recipients of binaries) is a good thing -- and I agree for many things. On the other hand, that's a *restriction*, not a *freedom*, inherent in the licence. Don't pretend that it is "free"; make it clear that it's a subversive restrictive licence.
Saying anything else about the GPL's restrictions is outright lying. It's the number one reason I don't like GNU/zealots -- they see nothing wrong with being deceptive and duplicitous about this very important semantic matter.
I don't use the GPL as a preferred licence primarily because I don't want to place restrictions on the use of my software -- any restrictions. I prefer the MPL or the CC ShareAlike licence because they, at least, don't include a pseudo-communist manifesto that I don't particularly want to promulgate as if I agreed with it because I like the aims of the licence involved.
"Great" modern philosopher? Visionary? I don't think either applies. I think that Stallman has provided and still provides a useful service, and while I won't personally use the GNU GPL exclusively on any of my software (unless, of course, I have inherited it), the only issue I have with the GNU GPL is the insistence that it is a "free" licence. (Which it is NOT! It's a heavily encumbered licence that ensures a particular level of source code access to downstream users of the software. This is not a bad thing in and of itself and it can be a very good thing, but the one thing that it is not -- without going into DoubleSpeak -- is free.)
Stallman hasn't outlived his purpose, but a great modern philosopher he is not.
I have adapted a PDF library (cPDF) into a pure-Ruby solution. It is still in alpha stage (I have a lot more work I want to do on it), but it will improve (I'm working on another project briefly).
Becausen PHP is an abomination for writing clean code. I'm not saying it can't be done, but it's as common to find clean PHP code as it is to find clean OO Perl code.
Earlier this year, I helped review this book during the publication process. At one point, the question was raised whether Ruby was the "ideal" language for this. In my opinion, the answer is "absolutely yes." Ruby -- and Python, if you can get past its syntactic oddities that I can't get past -- is "executable pseudo-code."
I think that's a sideways swipe at my own comment regarding the poor choice of default licence.
I was quite specific that I prefer to source my own code BSD, MIT, or MPL -- none of which could happen if I used a single snippet from this resource. As I said: the GPL isn't "open" in the sense of most OSS licences; it is "free" in the doublespeak sense of the FSF. It's a licence that makes sense, from a perspective, but is most effective against other open source licences.
Commercial licensors are either going to use the code without reporting it, they have another way of making their money, or they're going to find other code that doesn't interfere with their licence of choice. It's the rest of the open source community that suffers when tiny but useful bits of code or libraries are put under the most restrictive "open source" licence.
So the submitter of the story is probably more at fault than you are (as I said, I don't like the name because it's not quite true) because this site won't help *open source* developers; it will help the so-called "free software" developers.
Make it easier by letting people select the licence as an attribute on the snippet itself, and make it so that any of the OSI approved but GPL-compatible licences are allowed. Then I think you'll actually have "OpenSnippets".
I don't mind if they called it "GPLedsnippets.com"; I mind that they call it "opensnippets.com". As I've said many times, the GPL works most effectively against open source (e.g., non-GPL/FSF licences) projects, not closed source projects.
I did a little bit of searching on their site and they really haven't done their homework. They say that they accept PD, GPL, or LGPL only -- but those aren't the only licences compatible with the GPL. They could have easily gone through and found the "approved/compatible" licences from the FSF and listed those. Not only that, they don't actually give a place to *specify* the snippet's licence, leaving the assumption of the tagline on the website itself: "GPLed snippets, served daily."
Sorry, but it's not open if it's GPLed. If I can't use it in a less restrictive context, it's not open. It might be what the person wanted -- and I fully support that -- but don't tell me that it's "OpenSnippets.com" when it's really "GPLedSnippets.com".
The default licence assumed is apparently GPL, which isn't open -- it's GPL. I can't use GPLed snippets in my code that I wish to make BSD or MIT or MPL licensed.
Slashdot Mirror
> Two things. One, please prove that the Debian patches are of
... if Debian doesn't fix this now, they're breaking trademark
> sub-quality. I doubt you will be able to because its simply not true.
One: you can't read. I said that the patches are of questionable
quality. Others in this thread have amply proven that Debian makes
changes that have destabilized Firefox on Debian. I read the original
thread entirely in the Debian bug tracking system. The Mozilla team has
definitely looked at some of the differences and found them wanting (the
Debian team has, for example, changed how the branding is done rather
than using the branding switch that the Mozilla team provided for this
very reason).
> Second, the problem Debian is having with it is the fact that they
> thought they had already dealt with it. A representative of Mozilla
> already came to them and they thought they had a deal where they could
> use the name but not the logo and everything would be fine. Now
> Mozilla is coming along, very close to the release of Etch, and saying
> that that deal doesn't mean anything and now Debian must change. Thats
> the hole story.
Yet
issues for years after, given that Debian releases so rarely.
> And saying that Debian is doing a piss-poor job with no proof is really
> not right at all.
Except that it's not my claim. It's the claim of the Mozilla developers
-- and a lot of people on this very thread.
What a moron.
./configure switch that will not use the official branding or name.
Firefox is free. The marks are not. Firefox *apparently* has a
Firefox is plenty free, and is easier to release from trademark issues than even Debian.
Debian takes that right very seriously, and it has the right; Mozilla doesn't have a problem with that. However, their unmodified images are part of the branding, and the use of the name with the logo is mandatory as part of the branding. Mozilla's lawyers indicated to them (by my reading of the original thread) that while they *could* trademark the Firefox logo and make it under a modifications-allowed license, they would greatly risk their ability to police and enforce the Firefox logo as a trademark. Similarly, Debian's patches are of questionable quality and necessity and allowing the use of the "Firefox" name with these questionably patched versions would potentially damage the quality of the Firefox mark.
Debian just can't expect to get a free ride for doing a half-job. Or even, as the case appears to be, a quarter-job.
As has been pointed out: Debian takes its image and mark very seriously, too. Why the bitching by Debian supporters when they have to make changes for the very sort of thing that they do themselves?
You make that sound like a bad thing.
(IMO, it's the GPL which is incompatible with other, more sensible licenses.)
They're broken, anyway. Try something else, like a two-phase signup process.
A fit? No. But Ruby isn't untyped; it is, in fact, very strongly typed. It's just that we don't restrict variables to a single type. We don't even restrict objects from changing their type at runtime (although their class inheritance won't change at runtime...mostly ;). In Ruby, a String is always a String and can't be coerced into something else. Converted, yes. Coerced, no.
You're not misunderstanding. ActiveRecord will automatically add those columns. However, unless your application *uses* them, your Rails app will ignore their existence.
...
If you're arguing about 10% of total coding effort, then why are you arguing this point at all?
As yet, I have not needed to drop down to Ruby's C-level API to implement any of my basic logic. I *have* used interfaces to libraries that others have written (mostly interfaces that have been written for the core, e.g., zlib and syck/YAML), but I have yet to need to write a C-level implementation of code, especially because of speed concerns.
For that 10% of code, you may be right. But that 10% of code doesn't generally involve web applications. At least in my experience.
You may fundamentally disagree that data is king in business. The fact that businesses survived for centuries without computers indicates that your fundament is disagreeing with reality. It is mostly when data has been lost without any way of reconstructing the processes surrounding the data that companies have run into trouble.
If you give me data in a usable form, I can *always* build or rebuild processes and code around that. If you give me code, it will take me far longer to build the data. Your fundament happens to be wrong here. If it's wrong on that, it has a good chance of being wrong elsewhere.
Note that YARV/Rite isn't about JIT for Ruby. If you actually paid attention to Ruby development, instead of spreading FUD and untruths, you might actually know that.
The speed issue is important in Ruby. But don't tell me that Ruby is slow -- I've got experience that indicates otherwise. I won't be programming 3D engines in it any time soon, and I might not want to manipulate a terabyte of data in it, but for many applications, it is more than sufficient. If it takes me an hour to write a Ruby script and three hours to run it, as opposed to five hours to write the same logic in a different language and an hour to run it, I'm still ahead with Ruby.
This isn't a matter of hand-waving. It's a matter of knowing when it's appropriate to apply which performance measures, which your moronic statement "Ruby is slow" can't even approach.
Your fundament is wrong.
Your statement is completely false and therefore FUD.
Ruby does prize programmer productivity, but nothing says that it doesn't prize a sturdy interface or prize execution speed. I challenge you to actually prove your FUD as fact.
FWIW, if you're following SQL conventions, you shouldn't need to rename your columns. If you're using MySQL as a convention, you'll need to rename your columns. Good practice leads to good portability. MySQL leads to poor portability.
As with everything, that depends on what you're doing.
There are things that one can do where Ruby outperforms both Python and Perl.
This isn't saying that Ruby can't be faster, but making it clear that simply saying "Ruby is slow" or "Ruby is slower..." isn't necessarily true.
One also has to compare development costs (high) with deployment costs (variable). If I can develop several times faster with Ruby, the cost difference may be significant.
Expressing the data model as classes can be done using Og (or Nitro+Og), and I believe that Og can be used as an alternative interface to Rails with just a bit of work. However, Rails does this (mostly) the right way, since your data is always more valuable than your application. Where this approach falls down is based on a couple of things:
People who don’t really know anything about data modelling and relational theory tend to prefer class->table interpretation. People who understand data modelling tend to prefer table->class interpretation. There’s room for both, but the preferred method—and the more portable method—is to treat the database as the authoritative model for the application, not the other way around. (Yes, reading the database model is more portable than creating the database from the application. Especially with a dynamic language like Ruby.)
This is a straw-man. Ruby most emphatically is not slow. It is also not the fastest performer. But for what RoR does, it is generally fast enough. If you’re using the MySQL adapter, you definitely want to make sure that you’re using the native adapter, not the pure Ruby adapter. I’m developing one of the more complex applications/libraries in Ruby (PDF::Writer) and while I won’t pretend that it’s a speed demon, it’s impressively fast for what it does do, complete with rollback for the layout handling. Ruby’s performance is more than adequate for most applications, especially most database-backed web applications.
Probably not. I suspect that there will be 80% or more compatibility, based on the currently submitted RCRs that have positive response. I also expect that the RoR community will make sure that Rails runs well on whatever the current version of Ruby is. I believe that some work has been done to make sure that RoR works well on Ruby 1.9, which is the test bed environment for most of the syntax changes that will be coming with Ruby 2.0.
I agree with your first sentence. I disagree with your second, at least partially. RoR—and Ruby in general—makes a lot of code smaller and easier to maintain. Ruby isn’t the
1. I don't believe your SOAP comment is correct. Remember, ROR doesn't provide SOAP per se; it's SOAP4R that does. ROR may provide basic SOAP4R capabilities, but that in no way means that it's using 100% of the features. The ROR team may have decided that the typical use of SOAP with a ROR site is likely to be 25% of the SOAP capabilities. You can *still* do the full SOAP support -- you just have to work a bit harder on it.
s e.html for more information.
2. Yes, but J2EE is an overblown, overladen framework to begin with. When people need queueing and remoting technologies with ROR, it will be added. In fact, the remoting technology -- at least in part -- is already there through DRb (if you haven't looked at it, you should) and Florian Groß's breakpoints code. I would strongly disagree with your assertion that the J2EE components for these are "comprehensive" and especially "unified."
3. Again, you *can* do field name mapping, but it's a bit more work to do so. There's no reason you can't create aliases, e.g.:
def deg_f=(fahrenheit)
write_attribute("celsius", (fahrenheit - 32) * 9 / 5.0))
end
def deg_f
(read_attribute("celsius") * 5 / 9.0) + 32
end
See http://ar.rubyonrails.com/classes/ActiveRecord/Ba
Field name mapping is easy; not as easy as simply following the Rails model, but it's *easy*. SOAP is a bit harder, and other stuff maybe a bit harder still. It's all still easier than trying to pick up all of J2EE.
-austin
Full disclosure: I don't particularly like the Rails way of doing things with databases, because it bases its data interaction semantics as if MySQL were a good (rather than an "easy") database.
That said:
The assessment on the Rails blog is, I think better. The numbers are impressive but meaningless -- there are tweaks that can be done in any case. The real point is that this shows that Ruby Isn't Slow and that Rails (or any other application environment) can be used in a production environment.
Oy. You answered without answering or understanding.
I don't actually like placing the restrictions of the GPL on my software, most of the time. I put it out there to be used. My preferred restrictions are captured in the BSD or MIT licences: don't pretend that you wrote my software, but use it as you wish; don't come looking to me when it blows up, though, because I'm not offering any warranty on my software. I would *like* credit, but I don't need it.
I would *like* people to continue sharing derivatives of my software, but I don't need them to do so -- because my original software remains available.
Even when I want to place such restrictions, I prefer not using the GPL because it is a political document more than it is a usable licence; other licences capture the essence of the GPL (or in the case of the MPL, a better concept than the GPL) without political garbage that I neither want nor need in my licences.
> The GPL is in no way different from the BSD licenses when you don't
> modify and distribute the (compiled) source code. The GPL grants the
> freedoms that RMS considers important for software and in my opinion
> - "The freedom to take source code and redistribute it in a form that
> does not grant freedom" is not an important freedom at all. So the
> GPL is perfectly free. Additionally it enforces freedom for derived
> works.
Bullshit and you know it. This is the sort of DoubleSpeak that I was talking about. The GPL is an encumbered license. This is not a bad thing, as some people think that the restrictions offered by the licence (e.g., ensures the availability of the source to downstream recipients of binaries) is a good thing -- and I agree for many things. On the other hand, that's a *restriction*, not a *freedom*, inherent in the licence. Don't pretend that it is "free"; make it clear that it's a subversive restrictive licence.
Saying anything else about the GPL's restrictions is outright lying. It's the number one reason I don't like GNU/zealots -- they see nothing wrong with being deceptive and duplicitous about this very important semantic matter.
I don't use the GPL as a preferred licence primarily because I don't want to place restrictions on the use of my software -- any restrictions. I prefer the MPL or the CC ShareAlike licence because they, at least, don't include a pseudo-communist manifesto that I don't particularly want to promulgate as if I agreed with it because I like the aims of the licence involved.
"Great" modern philosopher? Visionary? I don't think either applies. I think that Stallman has provided and still provides a useful service, and while I won't personally use the GNU GPL exclusively on any of my software (unless, of course, I have inherited it), the only issue I have with the GNU GPL is the insistence that it is a "free" licence. (Which it is NOT! It's a heavily encumbered licence that ensures a particular level of source code access to downstream users of the software. This is not a bad thing in and of itself and it can be a very good thing, but the one thing that it is not -- without going into DoubleSpeak -- is free.)
Stallman hasn't outlived his purpose, but a great modern philosopher he is not.
I have adapted a PDF library (cPDF) into a pure-Ruby solution. It is still in alpha stage (I have a lot more work I want to do on it), but it will improve (I'm working on another project briefly).
-austin
Becausen PHP is an abomination for writing clean code. I'm not saying it can't be done, but it's as common to find clean PHP code as it is to find clean OO Perl code.
-austin
Earlier this year, I helped review this book during the publication process. At one point, the question was raised whether Ruby was the "ideal" language for this. In my opinion, the answer is "absolutely yes." Ruby -- and Python, if you can get past its syntactic oddities that I can't get past -- is "executable pseudo-code."
-austin
I think that's a sideways swipe at my own comment regarding the poor choice of default licence.
I was quite specific that I prefer to source my own code BSD, MIT, or MPL -- none of which could happen if I used a single snippet from this resource. As I said: the GPL isn't "open" in the sense of most OSS licences; it is "free" in the doublespeak sense of the FSF. It's a licence that makes sense, from a perspective, but is most effective against other open source licences.
Commercial licensors are either going to use the code without reporting it, they have another way of making their money, or they're going to find other code that doesn't interfere with their licence of choice. It's the rest of the open source community that suffers when tiny but useful bits of code or libraries are put under the most restrictive "open source" licence.
So the submitter of the story is probably more at fault than you are (as I said, I don't like the name because it's not quite true) because this site won't help *open source* developers; it will help the so-called "free software" developers.
Make it easier by letting people select the licence as an attribute on the snippet itself, and make it so that any of the OSI approved but GPL-compatible licences are allowed. Then I think you'll actually have "OpenSnippets".
-austin
That's the GPL essentially.
I don't mind if they called it "GPLedsnippets.com"; I mind that they call it "opensnippets.com". As I've said many times, the GPL works most effectively against open source (e.g., non-GPL/FSF licences) projects, not closed source projects.
I did a little bit of searching on their site and they really haven't done their homework. They say that they accept PD, GPL, or LGPL only -- but those aren't the only licences compatible with the GPL. They could have easily gone through and found the "approved/compatible" licences from the FSF and listed those. Not only that, they don't actually give a place to *specify* the snippet's licence, leaving the assumption of the tagline on the website itself: "GPLed snippets, served daily."
Sorry, but it's not open if it's GPLed. If I can't use it in a less restrictive context, it's not open. It might be what the person wanted -- and I fully support that -- but don't tell me that it's "OpenSnippets.com" when it's really "GPLedSnippets.com".
-austin
The default licence assumed is apparently GPL, which isn't open -- it's GPL. I can't use GPLed snippets in my code that I wish to make BSD or MIT or MPL licensed.
Great idea, lousy default licence choice.
-a