Posterous theme by Cory Watilo

Filed under: Programming

Dennis Ritchie

“Pretty much everything on the web uses those two things: C and UNIX,” Pike tells Wired. “The browsers are written in C. The UNIX kernel — that pretty much the entire Internet runs on — is written in C. Web servers are written in C, and if they’re not, they’re written in Java or C++, which are C derivatives, or Python or Ruby, which are implemented in C. And all of the network hardware running these programs I can almost guarantee were written in C. Ritchie lived in a very different time and worked in a very different environment than someone like Jobs. It only makes sense that he wouldn’t get his due. But those who matter understand the mark he left. “There’s that line from Newton about standing on the shoulders of giants,” says Kernighan. “We’re all standing on Dennis’ shoulders.”

Are RESTful APIs replacing the term Web Services?

Recently Leonard Richardson, co-author or RESTful Web Services, has been wondering why people no longer appear to be referring to Web Services anymore ...

[...] I noticed that nobody uses the term "web services" anymore. Everyone talks about "APIs"

Now it is stretching things to say that "nobody uses the term" any more, when in fact there are still lots of occurrences, ranging from Cloud and mobile, through Cloud IDEs and including Social Networking. But Leonard's point is that the term is perhaps not being used as much as it once was.

The change I noticed is just that the terms used to be used interchangeably, and now "web service" has pretty much died out. When I say "web service" people know what I'm talking about, but I feel like I'm speaking out of a phrasebook, or doggedly saying "free software" in an "open source" world.

He wonders if this subtle change is indicative of something more fundamental and important going on within the industry? It is also true that the term "web service" used by REST proponents was never the same as the SOAP use of the same words. So is this something that is applicable only to the REST community? Is the apparent drop in use of the term in the SOAP community simply tied to the apparent downturn in the use of WS-*?

But Leonard wonders if this change is a problem?

[I believe] that there's a reason people might have stopped saying "web service" around 2007, but that using "API" as a generic term leads to products that are worse than they could be [...]

So is it really true that the term "web service" is dying out and being replaced by "API"? If so, why and what are the potential implications? Does this lead to poorer implementations due, presumably, to confusion arising around the term "API" as it applies to the Web? As one of the commenters on his original article states:

My understanding is that APIs don't self-describe. Obviously not all web services do either, but at least there exist standardized formats dedicated to description. As an anecdotal data point, though, we had a client hire us recently to write an app using their web service (not their API). It's SOAP, baroque and hideous, which probably has something to do with why they call it that. But I've certainly seen plenty of sites boasting about their APIs in the wild.

What is Ruby and Ruby on Rails (RoR)?

What is Ruby?

Ruby is a pure object-oriented programming language with a super clean syntax that makes programming elegant and fun. Ruby successfully combines Smalltalk's conceptual elegance, Python's ease of use and learning, and Perl's pragmatism. Ruby originated in Japan in the early 1990s, and has started to become popular worldwide in the past few years as more English language books and documentation have become available.

What is Rails?

Rails is an open source Ruby framework for developing database-backed web applications. What's special about that? There are dozens of frameworks out there and most of them have been around much longer than Rails. Why should you care about yet another framework? What would you think if I told you that you could develop a web application at least ten times faster with Rails than you could with a typical Java framework? You can--without making any sacrifices in the quality of your application! How is this possible? Part of the answer is in the Ruby programming language. Many things that are very simple to do in Ruby are not even possible in most other languages. Rails takes full advantage of this. The rest of the answer is in two of Rail's guiding principles: less software and convention over configuration. Less software means you write fewer lines of code to implement your application. Keeping your code small means faster development and fewer bugs, which makes your code easier to understand, maintain, and enhance. Very shortly, you will see how Rails cuts your code burden. Convention over configuration means an end to verbose XML configuration files--there aren't any in Rails! Instead of configuration files, a Rails application uses a few simple programming conventions that allow it to figure out everything through reflection and discovery. Your application code and your running database already contain everything that Rails needs to know!