On Boing Boing, there is a post about kids making a sport about out-smarting web filters:

Ryan had apparently set up a so-called Web proxy from his home computer so that when he was at school, he could direct requests for banned sites like MySpace through a Web address at home, thereby tricking the school's filter. (Web, or CGI, proxies can be Web sites or applications that allow users to access other sites through them.)

"I eventually tracked down the (Internet Protocol) address, so that it doesn't work for him anymore," said Don Wolff, tech coordinator in the Phoenix-Talent School District, adding that Ryan didn't face disciplinary action. "It's against our acceptable-use policy, but he's not going to quit trying, (and this way) we can keep learning."

"This is a hot new trend among kids for getting around Web filters," Wolff said.

(original story from c|net)

This is really quite interesting, because it is the nature of the web to be decentralized and difficult fo filter. To me, this seems like a missed opportunity. Certainly school IT departments should try their best to filter out "inapropriate content"—and what a can of worms that is, lets sidestep it—but websites like MySpace can be used within an educational setting, both as a way for students across town to share notes, ideas, and collaborate on school projects. Further, resources could be utilized to explain online preditors and how to avoid them.

Just a few thoughts.

In case you haven't downloaded it, check out The Colorzilla extension for Firefox. Not only is it a groovy color picker, but it reproduces a large chunk of what I use both the web development tool bar and dom inspector for, in one really easy step. Just go download it.

Right click on it and change your status bar to something like "%hex%|%dist%|%element%|%dom-path%" and revel in the webdevy goodness.

Mmmm

Eyedropper Gooey Web Devy Goodness.

Seeing as how I have my web-dev hat on lately, I've been dealing a lot with CSS, HTML, layout issues, and other sundry.

I crave unit testing. Unit testing is a method where programmers can test the results of any code they create, or (especially) modify, to make sure that it conforms to a set of requirements. It is also called a "test harness" which simultaneously brings images of something that saves your life if you slip and fall down a cliff, and something that binds you.

Unit Testing is practically automatic. When you write code, you write some tests that run along side the code, and when you are ready to "push the change upstream" and make your code live, you run the unit-tests first, to be sure that everything is running well. Running the tests is as easy as clicking on a test button, or launching your favourite build utility; they are painless to run and it only takes just a few mindless seconds.

Web Developers don't have that luxury. Instead, when it is time to test, they have to open at least 2 browsers—though quite likely 4-6 and visually inspect the results. This can get downright physically painful (multiple IEs anyone?). Trying to do any effective CSS refactoring is effectively impossible, because there is no easy way to test the results. Something. Must. Be. Done.

A web development unit tester

A web development unit tester would do something like this:

1. Automagickally validate the rendered HTML page (rendered because changes are you are using some kind of ASP/JSP/PHP funkiness) for valid (x)HTML, CSS, broken images and broken links
2. Visually compare the rendered pages against a set of "templates" to ensure that any changes to the stylesheet or underlying markup don't have any adverse effects.

The first requirement is simple. Painless basically. Validators, of the link, css, html and image variety, have existed for ages. All that it takes is the ability to chain them all together, and launch them from a simple button (or command, if you are strong—GUIs are for the weak). The second requirement is the most important and difficult part, especially if unit-testing CSS is to become a reality.

How can unit-testing happen for CSS?

Not Easily.

Essentially what needs to happen is that a visual representation needs to be compared to ensure that everything "looks good". This fuzzy definition really encodes the problem. One solution I have thought of involves opening the page in all of the target browsers rendering engines, rendering the full page directly to an image, and then comparing the images pixel vs. pixel against a known "last-good" result. If the pixels differ, the offending pixels could be highlighted and the developer could choose to specify that the variation is within acceptable bounds and not be warned about it again, or fail the test.

This would be especially helpful when moving style-declarations around a style sheet, for instance, when pushing up a declaration to a parent element, or down to a child element. These kind of refactorings should change nothing in the visual presentation of the page, but should make the stylesheet smaller, easier to read, and easier to parse: for machines and humans.

Who wants to build this?

I've been reading this blog over at sitepoint about Who Gets Rest by PHP heavy Harry Fuecks. It is a fairly link-heavy top level view of what REST is.

Its nice to see more the PHP guys get into REST, as far as PHP guys go, Harry is pretty Heavy. What harry has to say about URI naming schemes (especially in the comment section) really helped to gel a very important part of REST for me:

...another consequence [of removing verbs from the URI] is separating "tools" for working with "resources" from the resources themselves. That might mean to edit a blog entry you might have a URL like http://www.example.com/backend/editor which displays the form you need and POSTs to the resource (URL) to update it.

This really nails the whole "Hypermedia as application state" concept home for me. The GET request to /backend/editor returns a resource representation that can be used to make a POST request to /example.com/entry (or even a PUT request to /example.com/title-of-my-entry-here). The (machine or human) agent travels through the application like pseudo-medieval adventurers through a dungeon; the agent can go backward and forward through the application as they desire.

I'll get into this state-machine-design of a web application in a later entry.

Rasmus wrote about the "No Framework PHP MVC Framework. And so many people missed the point, it becomes almost funny. First of all, there are a bunch of Ruby on Rails wonks who are obviously dismayed by the entire idea that using a framework, especially one with a central controller could actually be harmful. This is something that Avi and I talked about earlier, albeit in a slightly different content.

Railing on Rails

Probably the most annoying, asinine, and missing-the-point-entirely, is an entire blog post that claims to compare the no framework PHP version with Rails. Look, I am not about to rag on Rails. It is obvious that it does something right and good for a lot of people; in fact, installing and playing with rails is very high up on my todo list.

One of the things that bugs me about this comparison it is at the end of each subsection is a running tally of lines of code written, as if that is the be-all and end-all of programming. If it really had to do with how many lines of code we wrote, we'd all agree that a language like scheme is best, and we'd all program in one language.

But really, the biggest thing is this, I'll just quote the relevant authors, and let them speak for themselves:

I don't have much of a problem with MVC itself. It's the framework baggage that usually comes along with it that I avoid. Parts of frameworks can be useful as long as you can separate the parts out that you need. As for MVC, if you use it carefully, it can be useful in a web application. Just make sure you avoid the temptation of creating a single monolithic controller. A web application by its very nature is a series of small discrete requests. If you send all of your requests through a single controller on a single machine you have just defeated this very important architecture. Discreteness gives you scalability and modularity. You can break large problems up into a series of very small and modular solutions and you can deploy these across as many servers as you like. You need to tie them together to some extent most likely through some backend datastore, but keep them as separate as possible. This means you want your views and controllers very close to each other and you want to keep your controllers as small as possible.

--Rasmus

The controller handles the requests of the user. Every request goes through a controller first. The controller uses the model and view to create a response. In this application, one of the tasks of the controller is to load a list of products, using the model. The controller gives this list to the view, which turns it into HTML.

--Jules

The difference is obvious. Rasmus is talking about why using a monolithic controller might not be a good thing, and shows us how one can get round that using his language of choice. Jules is showing us that his language and framework of choice is so much better then ours because his framework writes all his code for him. Glossing over the fact that Rails itself has, just as a guess, several kilo-lines of code. So I guess that means that PHP is better, because it only took PHP a few hundred lines for what took rails thousands.

Now as I said, I don't have it in for Rails. I don't actually believe that a framework is better then a language for writing web applications. I think both have their place.

Object Fascism

The other funny/annoying part of the comments to Rasmus's blog is the OO-Zealots, another great quote:

I think you are doing a lot of damage with this posting. Do you realize what's going to happen if ONE of the 30 programmers in the building I work in find's your post? For years I have struggled convincing fellow programmer's that PHP is NOT a simple scripting language for the gamers and what not, that it actually CAN compete with J2EE and ASP.NET and C# if used where appropiate. To read this from the creator of the language....I'm still shocked

--Jurgan

Now, at work, I have to deal with a J2EE app. I am not sure if it is a representative sample or not, but let me tell you: if the J2EE/huge-framework method is the right way, then I'll throw my lot in with the bad-guys. Trying to change just one small aspect of this system becomes an exercise in pain. This droplet here, is it configured by the params and oparams in its XML? Or is it configured by its properties sheet? Or is it configured by some other XML configuration file somewhere else? In actual fact, I am also willing to explore the very real possibility that there was a very particular reason for the at-work system being laid out like it is, and I am going to try my very best to learn it as best as I can, without letting my prejudices getting in the way. It isn't going to be easy, but it will be well worthwhile.

Anyway, the central point here is that you can talk till you are blue in the face about how PHP is a perfectly valid language, about how it can be used appropriately, until you are blue in the face. 90% of them will not listen. They don't care. The C# guys spent a fuck-tonne of money becoming certified by Microsoft. They are firmly, and proudly locked in. If they have to admit to the possibility that there is another perfectly valid way of doing things, their house of cards comes crashing to the ground. The same can be said with the Java guys. They love their Bondage and Discipline language, and wear their love proudly. It is so much easier to sneer at a language that challenges what we think of as "good" then it is to actually learn from and learn about that language.

To those guys, I say "So what". Let them spend countless dollars on training and education on broken languages. Go learn Scheme, Haskell or something. Go see what the fuss is about continuations and web programming, so that the next time they start to sneer in your direction, you can retort with something like "Oh, I'm sure glad your language of choice solves every problem. Why aren't we all using Language X for everything? Quick tell the world!". Language advocates are annoying and dumb, and should be treated as such. Don't treat them as people to convince, but people to scorn.

Okay, sorry, this got a little ranty. But language advocates piss me off. There is a big difference between loving a language, and loving a language to the exclusion of all others. I'll finish off by pointing you to this great entry about Java by Steve, titled: Execution in the kingdom of nouns.

It is almost enough to make me consider using a WYSIWYG editor. When you are blogging, or at least, blogging intelligently, you are essentially writing content that will be consumed by 2 to 4 different consumers:

1. HTML, to be consumed by a browser
2. RSS to be consumed by an RSS reader
3. ATOM to be consumed by an ATOM reader
4. XML to be consumed by an XML parser (such as a feed reader, or perhaps a screen scraper, browser in the case of XHTML, etc.)

The implications are however, that youmust be careful about what you write. Now, I guess I should be clear here. If you are one of the few friends whom I have said "You need to start blogging, lemme set you up." I would set you up with a WYSIWYG editor, and leave it at that, so you don't have to worry about character entities messing up your RSS feed.

But if you are like me, and you find the most flexible thing to write your blog entries is lightly transformed HTML (essentially I have every new line being turned into a <br/> tag), then you need to be careful, specifically in the case of entities (" and & especially). This little exercise in feed validation has exposed 2 of my blind spots:

1. Embedding javascript inside of blog posts
2. using & when I should be using &amp;. (particularly on the URL)

So what to do? For now I am going to run each posting through an XHTML validator, that should fix about 80% of my problems, which is good enough for me.

Thanks again to Sam Ruby for catching my validation issue.

Whoah. Lots and lots of action is happening in the blogosphere about the division between Hi REST and Lo REST (which I argued is completely bunk, and still do).

First off, I should mention Koranteng Ofosu-Amaah who, like me, is all about the Elevator Pitch of REST, which he puts a whole lot more succinctly then I did. Good on him.

Mnot also talks about the false choice, but then we go right back into the conversation about which HTTP verbs to use.

Avatars and Definitions

I'd like to respond to someone on the "other side" of the discussion who is making a lot of waves, and, while I may not agree with what he has to say is zeroing in on some good stuff. Ryan Tomayko in his entry TitledThe Highs and Lows of Rest says:

Not being able to distinguish which of these subsets of applied REST one is referring to is hurting our ability to have meaningful conversations about this stuff. For example, consider the following conversation; I’ve seen it hundreds of times now:

Restafarian: 80% of developers use the XXX REST API because they find it easier to deal with.
Tool Vendor: That’s not really REST. It only uses GET and POST and breaks rule #5034
Restafarian: Oh yea, well SOAP/WS-* sucks.
Tool Vendor: Go write some PHP you dirty hippie!

I’d like that to stop happening.

But I don’t think adopting wrong or ambiguous terminology is going to help either. I’d like to register my nits with the few sentences that Dare provided and see if anyone else is thinking along similar lines.

To which there are a few things to say. The first of which, why is the RESTafarian a PHP writing dirty hippy? Have I become some kind of RESTafarian avatar?

Enough funning. The real part that merits a response is that having meaningful conversation about REST Is hard, because there is a real disconnect between what REST means and what people think REST means. In fact, I don't so much have a problem with the idea of splitting REST into a high and low version. What I take issue with is where the split is taking place. For instance, I could see a situation arise where cookies would be used to store an applications state, and this could still be RESTful, and we could call that Lo-REST. I would even go so far as to say that we could break one of RESTS constraints and we can call that Lo-REST. But the point is, that in order to make this Hi and Low REST distinction, we have to be talking about REST, not HTTP. In fact, One could argue that one doesn't need to use HTTP to be RESTful, and it seems to me that Fielding suggests as much in his dissertation when he talks about REST being applied to URI and HTTP.

Another excellent thing that Ryan brings up is the fact that the response entity of the server does not have to be XML for it to be rest. In some cases, a text/plain will be a perfectly valid, and usable resource representation. He also brings up Microformats as a good resource representation (AHAH is what this is called, and it is quite nice actually).

Web services as objects

Apparently my previous entry resonated with Sam Ruby as well, and through checking out his blog, I suddenly got transported into the world of Duck Typing and other misc goodness. Go check it out, you won't be wasting your time, he is on my feedlist. Sam Ruby makes the web-service to object analogy, which I like a lot more then the REST/CRUD analogy, but it still doesn't fit right with me.

I guess as an analogy it works really well with SOAP, since SOAP started out as the Simple Object Access Protocol after all. But I think that the analogy can be carried further, and perhaps expressed differently in the case of REST to promote more understanding (which is not to imply that Sam Ruby doesn't understand REST). When you GET /resource?my&query&string&here, what you are really doing is $myRepresentation = new Resource($my, $query, $string, $here)... and at about this point the analogy starts to break down. POSTing to a resource will perhaps alter the resource itself (thus changing the class), or it may just alter the representation of the resource (changing an instance, and all future instances that "look like it"), or, it may just initiate an action leaving the state of the resource unchanged, but otherwise modify or act on another resource. If you perform a DELETE on a resource, one of the actions that may happen is that a representation of the resource disappears, likened to unset($myRepresentation). But another thing that might happen is that the resource itself will disappear. The only analogy here is that you undefine a class (which only makes sense in a world where classes are first-class entities).

It is in the breakdown of the analogy that (hopefully) promotes more understanding. Essentially what I am saying is that with REST you don't want to think about methods on objects, you don't want to think about storage and retrieval of documents, you want to think about Actions on Universal Resource Indicators, that may contain a representation of a resource, that may return a representation of a resource. From Fielding:

What distinguishes HTTP from RPC isn't the syntax. It isn't even the different characteristics gained from using a stream as a parameter, though that helps to explain why existing RPC mechanisms were not usable for the Web. What makes HTTP significantly different from RPC is that the requests are directed to resources using a generic interface with standard semantics that can be interpreted by intermediaries almost as well as by the machines that originate services. The result is an application that allows for layers of transformation and indirection that are independent of the information origin, which is very useful for an Internet-scale, multi-organization, anarchically scalable information system. RPC mechanisms, in contrast, are defined in terms of language APIs, not network-based applications.

Notice that Fielding himself makes the HTTP vs. REST distinction here. (For clarity, what makes my above description RESTful is this talk about representations of resources.)

Cleaning up communication

It really is all about clarity of what REST is. REST is a general set of constraints that happen to be really well applied to HTTP. I happen to be working with an application server that is about 70/30 REST, its protocol has nothing to do with HTTP. However, it contains some (but not all) of the architectural constraints that are laid out by Fielding's dissertation.