That's a sound argument if the the goal is to get them jobs in the first world, but the goal is to enable them to work in their own countries and to do that they need free software that doesn't tie them into proprietary foreign IT products.
There's something of a chicken-and-egg process here, too. Larger companies may prefer to have their software written in Java because Java develoeprs are so numerous; (many) developers drift towards Java because they feel more comfortable having amore job opportunities. Lather, rinse, repeat.
But suppose the $100 laptop included a full developer's tool-set for Haskell, or Ruby, or Lisp (or whatever; something free and open to suit the distributers). Before long, there are large sections of the world where such developers are numerous; companies feel confortable doing projects in @some_other_language because they know they can always get developers. Jobs, then, are nice side effect.
What this basically means is I can take down the "This site would be cool if your browser adopted more standards" message from the IE version of some of my web apps, and instead give a link for IE6 users to Firefox or IE7.
I clicked on about a dozen, and they're all hidden by an ad titled "Learn from the AJAX Masters."
And ads that proclaim James Garrett as "The Father of AJAX" cast doubt on the whole site. Seems the site is intended to drive overpriced conferences.
Re:Which market is most important to us?
on
Ambient Findability
·
· Score: 1
I'm maybe a half through the book, and I might just send it back to the library tomorrow. For a book ostensibly about finding information, I have a hard time finding any in this book.
Yes, there are sme interesting nuggets, but so far it is too much fluff and padding.
I suggest reading some of this in your local bookstore, or grabbing a copy from the library, before plunking down any cash for it.
Re:While we are at it: finding a Ruby group near y
on
Ruby Off the Rails
·
· Score: 1
I think Rails offers more of a "Wow" expereince for people coming from PHP or Java; experienced Rubyists appreciate what Rails offers, but also understand how relatively simple Ruby makes it to do these things on your own, and often it is better to just roll your own rather than wade through the Rails API maze.
Strong, static typing makes it easier to figure out how some (not all) changes will affect other code in a way that Ruby's dynamic typing does not allow. That includes unit test code. This helps a person maintain and change code more easily, especially if the person has not worked on the code before.
On the contrary. Static typing (both Ruby and Java have strong typing) makes it harder to change code, because you are constantly bumping into interface incompatibilities when you simply try to add or modify signatures and object behavior.
If I change a method signature to take String instead of an Integer, Java will bark at me, but it will not tell me if that problem is meaningful. I have to alter all the related code to accept the new data type, and then run my tests to ensure that the behavior is correct, not simply that the compiler gods have been pleased. And that's something people should be doing anyway, and that is what will really tell you what changes matter.
The larger point is that, if you are using unit and functional testing to ensure that code does more than compile without exceptions, then the added benefits of static typing are outweighed by the inconvenience they add in day-to-day coding and refactoring.
Unit tests and comments do far more to improve maintainability than static typing.
Which gets noticed first? Which way would you rather have when you are maintaining the code 6 months from now and have forgotten everything? Maintenance is the topic of the thread.
I'd suggest that, as no language can offer assurance that other developers haven't written moron code, you should have unit tests in place to mkae sure that not only does you code compile and run, but does what you intended.
The unit tests will also go a long way in helping explain what code is supposed to be doing, in the odd chance that developers have neglected to write good, clear comments (very unlikely, I know, but has been know to happen.) And that is key to maintainable code.
Google Suggest and Google Maps are two examples of a new approach to web applications that we at Adaptive Path have been calling Ajax. The name is shorthand for Asynchronous JavaScript + XML, and it represents a fundamental shift in what's possible on the Web.
Defining Ajax
Ajax isn't a technology. It's really several technologies, each flourishing in its own right, coming together in powerful new ways. Ajax incorporates:
As others have noted, a shorthand term comprised of the intials of a series of words, and is itself pronounable as a word, is an acronym. Revisionist hostory not withstanding.
The XML part is typically ignored in AJAX discussions, either because people find XML all scary and complex (and so use html/tag-soup), or because they do not understand the inplications for character encoding and internationalization.
All the Internet is is a bunch of networks hooked together.
Can't recall the source offhand, but there was an article not so long ago by some smart guy who explained that the net was essentially a set of agreements. People agree to send packets around with a known format, and agree to follow certain routing conventions. So while starting a new Net might be a pain in the ass, it is indeed quite feasible, and will ceertainly happen (if it hasn't already, in numerous guises) if and when the current Official Internet goes bad.
All I care about is the fact that we are now finally able to make server side calls whenever we want, and can update a piece of the page instead of redrawing everything.
That sort of thing has been doable for about five years now. XHR makes it cleaner (*Ajax* clean? I crack me up!) than using, say, Java crappelts, or frames, or Flash. The big feature is that Mozilla and others finaly got hip to (gasp) a Microsoft technology that many developers have been using for years.
I personally don't subscribe to the technical view (that it has to be XHR and XML...).
Well, perhaps that helps explain why so many people find the term meaningless at best, and often quite confusing.
Of course, Ruby also has at least one method to do this already... it just isn't part of Rails. Yet.
Ruby already has Og/Nitro, which drives the SQL from the code. Developers can focus on thinking in terms of their object model and object relationships, and let Og, the ORM part, handle the database work.
Many developers find this way of working far more natural than spreading their object definitions over multiple locations (SQL definitions and Ruby code).
Good to hear, though, that Rails continues to pick up advanced ideas from Og/Nitro.
Slashdot Mirror
Something like that but it is definitely NOT a patent application for RSS itself, the main article is ignorant and written by someone really stupid.
Thank you. Nothing in that patent application says MSFT is making a claim on RSS.
There's something of a chicken-and-egg process here, too. Larger companies may prefer to have their software written in Java because Java develoeprs are so numerous; (many) developers drift towards Java because they feel more comfortable having amore job opportunities. Lather, rinse, repeat.
But suppose the $100 laptop included a full developer's tool-set for Haskell, or Ruby, or Lisp (or whatever; something free and open to suit the distributers). Before long, there are large sections of the world where such developers are numerous; companies feel confortable doing projects in @some_other_language because they know they can always get developers. Jobs, then, are nice side effect.
Did you get a community education?
Wrong validator. Try this one.
Being a Ruby app should make the Google rewrite to Python easier.
When did XmlHttpRequest become a standard?
And ads that proclaim James Garrett as "The Father of AJAX" cast doubt on the whole site. Seems the site is intended to drive overpriced conferences.
Yes, there are sme interesting nuggets, but so far it is too much fluff and padding.
I suggest reading some of this in your local bookstore, or grabbing a copy from the library, before plunking down any cash for it.
This may be more active and more complete: http://rubygarden.org/ruby?RubyUserGroups.
I think Rails offers more of a "Wow" expereince for people coming from PHP or Java; experienced Rubyists appreciate what Rails offers, but also understand how relatively simple Ruby makes it to do these things on your own, and often it is better to just roll your own rather than wade through the Rails API maze.
I'm one. I make my living with it.
Right on. Please check out Nitro, Wee, and IOWA, for robust alternatives to Rails.
Each of them supports a different way to think about building Web apps
On the contrary. Static typing (both Ruby and Java have strong typing) makes it harder to change code, because you are constantly bumping into interface incompatibilities when you simply try to add or modify signatures and object behavior.
If I change a method signature to take String instead of an Integer, Java will bark at me, but it will not tell me if that problem is meaningful. I have to alter all the related code to accept the new data type, and then run my tests to ensure that the behavior is correct, not simply that the compiler gods have been pleased. And that's something people should be doing anyway, and that is what will really tell you what changes matter.
The larger point is that, if you are using unit and functional testing to ensure that code does more than compile without exceptions, then the added benefits of static typing are outweighed by the inconvenience they add in day-to-day coding and refactoring.
Unit tests and comments do far more to improve maintainability than static typing.
Nope. 40 was the age mentioned in the write up. Remember?
Complete descontextualized, ageist, useless pseudo tip, just shouting "Look! I did it before I was 40, I am so 3133t"I love the irony.
Anyway, don't be bitter because you've yet to do it; the hostility is unseemly. The real point is simply, Don't wait. Period.
I'd suggest that, as no language can offer assurance that other developers haven't written moron code, you should have unit tests in place to mkae sure that not only does you code compile and run, but does what you intended.
The unit tests will also go a long way in helping explain what code is supposed to be doing, in the odd chance that developers have neglected to write good, clear comments (very unlikely, I know, but has been know to happen.) And that is key to maintainable code.
I understand why people speak like this, and I appreciate a casual writing style, but, like, there's like no reason to like write that way, like.
Some of us say "Fuck it" and go start our own companies.
(And here's a tip: Don't wait until you are 40 to do this.)Google Suggest and Google Maps are two examples of a new approach to web applications that we at Adaptive Path have been calling Ajax. The name is shorthand for Asynchronous JavaScript + XML, and it represents a fundamental shift in what's possible on the Web.
Defining AjaxAjax isn't a technology. It's really several technologies, each flourishing in its own right, coming together in powerful new ways. Ajax incorporates:
As others have noted, a shorthand term comprised of the intials of a series of words, and is itself pronounable as a word, is an acronym. Revisionist hostory not withstanding.
The XML part is typically ignored in AJAX discussions, either because people find XML all scary and complex (and so use html/tag-soup), or because they do not understand the inplications for character encoding and internationalization.
And which one of those is the 'X' in 'AJAX' again?
And if you're still unsure if a site is Web 2.0, pass it through the Official Web 2.0 Validator
Quite true. I suspect the OP was thinking of the modern version, Nu Metal; equally repellant.
Interesting. Some links I dug up while looking for details:
http://www.experts-exchange.com/Web/Web_LanguagesMore/better links welcome.
Can't recall the source offhand, but there was an article not so long ago by some smart guy who explained that the net was essentially a set of agreements. People agree to send packets around with a known format, and agree to follow certain routing conventions. So while starting a new Net might be a pain in the ass, it is indeed quite feasible, and will ceertainly happen (if it hasn't already, in numerous guises) if and when the current Official Internet goes bad.
That sort of thing has been doable for about five years now. XHR makes it cleaner (*Ajax* clean? I crack me up!) than using, say, Java crappelts, or frames, or Flash. The big feature is that Mozilla and others finaly got hip to (gasp) a Microsoft technology that many developers have been using for years.
I personally don't subscribe to the technical view (that it has to be XHR and XMLWell, perhaps that helps explain why so many people find the term meaningless at best, and often quite confusing.
Ruby already has Og/Nitro, which drives the SQL from the code. Developers can focus on thinking in terms of their object model and object relationships, and let Og, the ORM part, handle the database work.
Many developers find this way of working far more natural than spreading their object definitions over multiple locations (SQL definitions and Ruby code).
Good to hear, though, that Rails continues to pick up advanced ideas from Og/Nitro.