Posts tagged as: ajax

Which programming language will get you a job?

The Indeed.com job site now allows you to graph the percentage of online want ads that contain specific key words. There are many uses for this, but I thought it would be interesting to compare the relative demand for specific programming skills. It looks like they rank as follows: .Net, Java, Perl, PHP, Python, Ajax, and Ruby. Despite the recent hype, Ajax and Ruby are barely visible compared to the better known languages.

But that isn't the whole story. All of the leading languages show fairly steady levels of demand. Ajax and Ruby, on the other hand, show strong growth over the last year. Want ads for Ruby doubled, and Ajax increased six-fold.





These last two graphs also suggest a potential growth market in Ruby and Ajax training. (Via Steve Rubel)

Starting a new blog

Now that I have my Ruby projects planned out for at least a year, I'd like to figure out my next blog. My principal reason for writing these blogs is to learn as much as I can about new Internet technologies. Ruby will likely be my core language for exploring much of this on the server side, but I also need to learn AJAX to handle client-side programming. I had thought about starting an AJAX blog, but that is too limiting. I also want to learn about lots of other stuff:

• APIs
• Map programming and related geocoding techniques. As O'Reilly would say in his incredibly pithy manner, everything having to do with Where.
• Mashing up APIs and maps to create new hybrid apps.
• The various interop technologies, such as REST, XML-RPC, and SOAP.

This next blog will probably be the last one I start for at least a year, so I want it to be inclusive enough to handle all of these issues. I'm thinking that Mashups combine them in a convenient package, so my most likely decision will be to start Mashup.Darwinianweb.com as the new blog. That would leave me with three blogs:

• DarwinianWeb.com: Focusing on general issues of the evolution of the Internet and software.
• Ruby.DarwinianWeb.com: A central clearing house for all my Ruby programming work.
• Mashup.DarwinianWeb.com: A common location for my explorations of the rest of these new technologies.

My wife keeps telling me to just write one blog and combine everything there, but I think that the separate Ruby blog has been a success, because it allows me to cover details about the language and source code listings that would surely chase away any general reader who wasn't programming in Ruby. I think the mashup work requires the same type of separation. I'll make a decision on this in the next day or so. Luckily the code I've written for these blogs makes it easy to start a new one with just an hour or so of effort.

Ruby RSS aggregator is running

My first RSS aggregator written in Ruby is now up at RubyRiver.org. It's still primitive, but it seems to be working OK. My goal in building this is to create a tutorial for new Ruby programmers. I've been publishing the code on my Ruby blog as I've been writing it. The complete code will be available for free download in a day or two, and the tutorial will be posted on RubyRiver as it is developed.

Running multiple blogs has given me an interesting insight into one of the problems of having people read a site through RSS. I've spoken to a number of people who read this blog, and when I mention my interest in Ruby, they usually say "You should start a Ruby blog." When I say that I already write one, they ask how they can find it. That's when I realize that they read the RSS feed and have never seen the link to the Ruby site on my navbar. So how do I solve this? Should I plug everything I do in every blog post? That was why navbars got added to websites.

Is the Web 2.0 frenzy passing?

It may just be the holidays, but it seems like the excitement over Web 2.0 is wearing off. Even the smarky sites are getting tired. Does anyone else notice this? Now don't jump all over me and say it was just hype in the first place. I think what hit everyone last summer was a legitimate epiphany within the computer world that is OK to come out and play again. Maybe people are just busy working on new projects. I know that I've dug myself in pretty deeply with Ruby, I think it may be time for me to add something new to my studies. As soon as I get the first version of my Ruby aggregator going I think I'll start working with Ajax.

Web 2.0 programmers wanted

A defining characteristic of Web 2.0 is that it is designed by programmers for programmers, where Web 1.0 was designed by media people and merchandisers for consumers. I know that there is a lot of talk about Web 2.0 being for "the people," but those people are supergeeks. In this first phase of Web 2.0 we are seeing the rapid proposal and adoption of "standards." When the dust settles in a couple of years, we'll have one leading standard and a minority, counter-standard in each area, as always. In the meantime, a lot of programmers are going to get hired to write a lot of new code based on these standards, and that is a good thing. Not just for programmers, but for users, since most of these things will be free. The WSJ (behind a paid subscription) today had a slightly confused article about the proliferation of programming languages, with references to both Ruby on Rails and Ajax. The important point is that the reporter and his editors recognized that programming as a cool activity is rising again in the zeitgeist.

My Web 2.0 stack

I'm not sure when "stack" came to mean a list of languages/technical standards used to build an app, but it is a useful description. It helps convey the logical architecture within a multi-layered development environment. The best example of a useful stack is LAMP (Linux, Apache, MySQL, Perl or Python or PHP), which summed up what most of us used to build Web 1.0. I've spent the last few months reading and skimming as many new technology books as possible, and I've narrowed down the list of things I need to become proficient in to understand how Web 2.0 works. What I still need is a catchy acronym. Here's the list:

• XHTML. This is basically HTML with some really prissy rules, like case sensitivity, and needing to close all tags. There are said to be tools that will make this conversion for you, but I haven't tried any.
• CSS. Once you understand the basic rules, CSS is a fun way to design a site, especially if you start with a pre-written stylesheet, so you can just change things like colors and spacing.
• XML. While XML itself can be understood in minutes, the many, many ancillary standards and protocols make it tough to find a real-world entry point. I've found RSS programming to be a good starting place.
• Ruby. I've been programming with Ruby for a month, and I'm getting to like it more and more. I think it may have the same level of ease and productivity that made the dBASE language so popular in its time.
• SQL. Yes, its still here, and its still the same, which is the problem. The issue will be fitting the object-oriented data structures of XML into the tables of SQL. The consultants will be paying their mortgages on this one for years.
• Javascript. I could say Ajax instead to assure a higher rating on the Web 2.0 Validator, but Ajax really means Javascript that maintains contact with a server without reloading a page.

Frankly, its not as much as I expected when I started researching Web 2.0 this summer. The good part is that it all fits together easily, and none of the parts are particularly challenging. That's when I am most productive. By the time a language gets as richly, and complexly supported as Java, for example, I get bored and confused and move on.

Slashdot review of Ajax in Action

Slashdot has a strong review, which I agree with, followed by lots of funny carping about Ajax.

Deitel catches the Web 2.0 bug

I've bought several of Deitel's computer books in the past, and they always do a very good job. It looks like they know a major wave when they see one. Although they don't have any web 2.0 related books out yet, other than a couple on XML, they have just launched a set of resource centers. These are collections of links for Ajax, Ruby, and Mash-ups. This is a good marketing idea, since it starts building their traffic in these areas in preparation for the books they must be working feverishly on. The other thing I like is that they are based in Maynard, Mass, just a few miles away from me. Maybe they can help jumpstart a New England Web 2.0 community. We sure are behind Silicon Valley on this wave.

Book Note: Ajax in Action

I've read the first two chapters, and this looks like exactly what I was looking for. It is aimed at someone who already knows how to do Web 1.0 type of development, what this book refers to as "classic web development" without any sense of irony. The first chapter is a very clear, executive summary style presentation of why you would want to use Ajax techniques. It addresses the prejudice that many programmers, including myself, developed against Javascript in the late Nineties, and makes a good argument for incorporating it within web applications today. If you are trying to convince your boss or your company to adopt Ajax, this chapter will answer many of their questions.

The second chapter quickly works through all the technologies necessary for Ajax, including CSS, Javascript, the Document Object Model, and XML. It is aimed at experienced programmers who have ignored many of these issues in favor of "classic" server-side web programming. I think the authors realize that there are many people who are either forced by their companies to stick with the older techniques, or like me abandoned web development after the dot-com crash. It is written in a "hello world" style, but it manages to integrate a wide range of key steps. It may be the most ambitious and best written hello world chapter I've ever read.

I especially appreciate the authors' sense of just what their target audience would already know and where the gaps might be. Instead of taking the "a memory variable is like a shoebox with a name on it" approach that so annoyed me with Teach Yourself Ruby in 21 Days, they only explain the details that might be new to someone who only knows Web 1.0 techniques. I have only read the second chapter through quickly, but I plan on going back and trying out each of the step-by-step examples in this chapter. To quote Spinal Tap, "There is a fine line between clever and stupid," and the examples in this chapter stay on the right side of that line, while still being simple enough to learn the underlying technique.

Interesting Ajax thread on Slashdot

As you would expect the Slashdotters view Ajax as a massive hack elevated by massive hype. In between the flames, however, there are some useful ideas.

Lots of balls in the air

I've got so many projects ideas that I think I should list them, if only to remind me of where I want to go:

• CSS: Redesign Darwinianweb.com site to use style sheets.
• Ruby: Amazon API based app to determine the best book on a given subject.
• Ruby on Rails: Rebuild the CMS for this blog from the current FoxPro code.
• Ajax: Google API based app using Google Maps.
• Ajax: A stripped down version of TiddlyWiki as a form of self-modifying page.

Book Note: Ajax in Action

Ajax is so bleeding edge that I am reading a book on it from the future. I thought the rule in publishing was that you could use the next year for the copyright if it was printed in late November, but this book arrived November 2 with a copyright of 2006. After yesterday's Microsoft Live demonstration, it is clear that all forces are converging on client side programming with Javascript and DHTML. There have been many blog posts accusing Microsoft of being a follower rather than a leader in this area, but the irony is that Microsoft created the XMLHttpRequest functionality that is the heart of Ajax. Adam Bosworth has an interesting post on this history.

The idea of simulating a desktop app in a browser using DHTML and Javascript goes back further than the XMLHttpRequest. I designed just such a product called GifWorks in 1998. The goal was to create Photoshop in a web browser. It wasn't completely client-side though. The interface runs in the browser, but the image processing is done on a server.

I'm not sure what I will do first with Ajax, but the most likely candidate is some type of mashup with Google maps.

I keep thinking about TiddlyWiki

The idea of a self-modifying webpage is definitely compelling. There are a lot of things about the TiddlyWiki interface I don't like, and it is misnamed, since it is a personal page, not a group editing page, but the idea of writing directly to a webpage without a server has struck a chord. I've been exploring the available resources, and Tiddly Wiki Mania and the Tiddly Wiki Dev discussion group seem like good places to start.

I looked over the Javascript code in the TiddlyWiki page and it seems pretty clean and understandable, although it is 82 pages long. I've been looking for a project to use in learning Ajax, and creating a simple version of a self-modifying page may be something I could have fun with.

Am I too old for this stuff?

I just discovered TiddlyWiki through a post on Ed Sim's Beyond VC blog. TiddlyWiki is a self-contained wiki system in a single web page.You can edit any portion of the page and then save the changes back to the same page. It is built with Javascript, so it is entirely client side. The changes don't go back to the server. You can save it on your own computer or carry it around on a USB flash memory card. I'm not sure how to explain it any further, because I'm not sure my head can hold onto the concepts implied by its use. How do others see the changes? How do I extract the changes from the page? I understood a wiki, because it is basically a client-server database with a user controlled interface, but this is a new kind of beast.

This reminds me of the time in early 1995 when I was first exploring webservers. I put a webserver on my own computer, logged onto it through Netscape, and then downloaded a file from my own computer back to my own computer. I tried to explain to my daughter, who was 12 at the time, that I had just copied a file from my computer in Boston, over the Internet backbone through a route that may have gone as far as Washington and back again in seconds. Her reaction was "So what?" I realized then that I was too fixated on the physical location of data and that my kids would grow up without that concept being so firm. Data to them is just something that is available when they need it, without thinking about "where" it is.

Now with TiddlyWiki I have to break my idea of data being "on" a server and then being displayed "in" a browser. I don't think our language or our minds are changing fast enough to keep up with these kinds of changes.