Wow.

How did I ever make music without this tutorial?

The first thing u need to do is download a music program.

I got some lined up for u:

Frooty Loops

Cool Edit Pro

Q-base

Now you need to discover them programs before you can begin
After that u need to have a good basic (Drum and Base)
With that you need some good ritme feeling(if u havent got that u can forget it tongue.gif )
Then you need to ad some really coowl sounds(hi-hats or handclaps)
If you got that right,you need to add some vibe by adding synt-sound(synthesizer)
Just do what your mind thinks of,nothing is wrong.
Just make it sound coowl and u will get some coowl beats.

Now go and good luck with making beats

-- via Shell

This I think is going to be the biggest thing coming out of the Hi/Low REST debate: the understanding that REST is an architectural style. It is a method of designing your web services. Just as you can Design your building(be it a house, mall, skyscraper...) in any style you like, the same goes with how you are going to design your web application.

And because we are talking about an architectural style, it means you are free to break the rules if you like. Do you want to store state as a session ID and throw it around in a cookie? Fine! Go to! Call it "REST+Cookie State" (or perhaps, "REST - statelessness") if you like. But its style, which means the designer has latitude as to how much he or she takes from that style depending on their needs.

So with the concept of REST as an architectural style, lets take a peek at some web services: (Thanks to pwb who gave me the idea in the comments of my entry about Lo and Hi REST)

A RESTful evaluation of some webservices.

this is not a value judgement, but it is rather a way to define REST by talking about which constraints they break, and the implications of breaking each constraint.

When going through these services, it is important to note that all of these services maintain the state of the application on the client. So all of these services are RESTful to some degree.

Flickr

RESTful

• GET and POST are used properly. You must use POST to the flickr.photos.delete method, but you can GET the info of a photo.

RESTless

• The URI. Everything is handled through a single URI with a query string (like http://www.flickr.com/services/rest/?method=flickr.photos.delete). The URIs need to change to /services/rest/photo/photoid /services/rest/person/personid, etc. In doing so, the results of GET interactions could be cached by clients and proxies properly.
• HTTP Status. Errors return a 200 response code. Preventing proper caching of resources.

Notes

Sticking with POST and GET would still work for flicker, but obviously a DELETE to /services/rest/photo/photoid makes more sense then POST /services/rest/photodelete/photoid

del.icio.us

RESTful

• Good URIs; not great, but good. (http://del.icio.us/api/posts/get). del.icio.us still has the problem of the URI specifying the verb when it doesn't need to.
• Standard use of the HTTP auth.

RESTless

• Everything uses GET and URIs are named after methods. This prevents cachability, and breaks the rule of HTTP where GET methods must be safe.

Notes

No longer claims to be restful, but did at one point. I'm not the first one to point this out either. Delicious makes some use of HTTP status codes (503 if you hit the server too hard), but other times does not.

s3 (amazon)

Pure electric REST sex baby. Not surprising really, Amazon hires some smart people.

Also, Amazons documentation is a perfect example of how to properly document a REST web service.

RESTful

• Proper HTTP status codes
• Proper URIs (http://s3.amazonaws.com/bucket/object)
• Proper verbs on resources (GET, PUT, DELETE on buckets)
• Proper authentication using HTTP auth, and a bonus for exposing that on the query string if the client needs it.
• Excellent use of meta-data in the response header, including E-Tags, and special amazon extensions (prefaced with x-amz-*)

RESTless

Nothing I can see. The S3 REST API is an example of a well defined, well documented REST API.

Bloglines

• Proper use of HTTP status codes
• Proper URIs (http://rpc.bloglines.com/listsubs)
• All actions are retrieval only, and therefore follow the rule of proper verbs on resources (everything with GET)
• Authentication using HTTP auth

RESTless

• The http://rpc.bloglines.com/getitems resource has the potential to mark items as unread when passed a parameter to the query string. Ideally a POST request would be used to mark items unread, and a GET would not. Alternately, a PUT request could be used with a list of items to mark items unread.

Notes

Does not claim to be RESTful, but it mostly is.

Ebay REST API (pdf link)

RESTful

• Semi Proper URIs (http://rest.api.ebay.com/restapi), the URI really only counts for one resource, a set of search results.
• Proper Verb on the Resource (GET).

RESTless

• There is no mention in the documentation as to whether or not the Ebay API properly returns HTTP status codes, but my guess is that it does not. (Does anyone have any information on that?)

Having spent some time in the deep guts of s9y (though perhaps not as much as Garvin for example) looking for potential optimizations, I have a few suggestions for users if they want to tweaking out their s9y install to get it going faster:

If you run S9y on a hosting service or similar

Your optimization options are somewhat limited, but there are still some things you can do:

Don't use many markup plugins

The less markup plugins the better. Consider using a WYSIWYG editor instead, and use the markup plugings sparingly. Emoticate is a particularly nasty markup plugin.

If you do use markup plugins, use the cache if you can.

The entry properties plugin allows you to cache the output transformation of entries, which can be a big bonus. It isn't compatible with some other plugins, so you will have to experiment, but the potential savings could be quite something, especially if you depend on some of the heavier transformation plugins.

Optimize the stylesheet

I go into details about this Here. It does take some massaging, and if you add a new plugin, sometimes you have to edit your main stylesheet or everything goes wonky. The chief benefit here is that you can get some cache benefits from including static stylesheets through @import, and plugins that parse the stylesheet to add their own styles have significantly less text to parse through.

But if you are a control freak...

Opcode Cache

This is the single biggest thing you can do to improve S9ys speed. APC is my favorite.

Cache Control

Use the apache modules for cache control and set it up to cache css and image files in your templates directory, and perhaps even your uploads directory.

Assuming that you are using the Expires module for apache 1.3, you would want something like this:

    ExpiresActive on
    ExpiresDefault "now"
    <Directory /var/www/jonnay.net/blog/templates>
        ExpiresByType image/gif  "access plus 4 days"
        ExpiresByType image/jpeg "access plus 4 days"
        ExpiresByType image/png  "access plus 4 days"
        ExpiresByType text/css   "access plus 4 days"
    </Directory>

The "access plus 4 days" really depends on your needs, you might want to change that to 2 weeks, or even 2 months. It depends on how often you re-design, and when you plan on a redesign next.

Just because your application handles PUT and DELETE doesn't mean your application is even remotely restful. Even allowing for OPTIONS doesn't necessarily mean that your application is RESTful. Being a RESTafarian doesn't mean that you know how to make server-side-software-x handle a PUT request.

In fact, there seems to be some rather big confusion about what REST is. This isn't too surprising, as the barrier to entry as a RESTafarian guru is pretty high. You have to be able to read and understand Roy Fieldings essay.

The RESTful waters are muddying, two new terms are being created: Hi-Rest and Lo-Rest.

...REST is a fairly subjective (and sometimes divisive) term. To get a more accurate picture of what we've done so far, I'll break this category in two: Lo-Rest, which is the use of HTTP GET (or equiv) for information retrieval/query, and Hi-Rest, which is characterized by the use of HTTP PUT and DELETE (or equiv) for doing update.

--Don Box

This is all very confusing and wrong. Thankfully Dimitri Glazkov has started coming out to say so, and I'll add my voice to his choir. Lo-Rest is just barely good HTTP, and is no where close to being RESTful. REST in fact is not a subjective term, it is very much an objective term. REST is a set of architectural constraints to a system. It should contain a specific set of features as laid out by Chapter 5 of Fieldings dissertation.

In Short, REST, whether, high, low, medium, or super-powered should contain the following features:

• Statelessness - communication should be stateless, so that each request from the client must contain all the information necessary for the server to understand the request. Note that the server still may make use of state information to (for instance) validate a request, etc. The important thing is that the client does not have to depend on the server for context of the request.
• Cacheability - Each resource transfered to and from the client and server should be marked as cacheable, or non-cacheable (at the very least).
• Uniform interface - A RESTful system will provide a Uniform interface with the following features:
  • Identification of resources A RESTful system will contain one or more Resources, being a conceptual identifier of the target of the service. (The weather at Calgary International Airport; the price, description and other features of the book "American Gods" by Neil Gaimen, etc.) an URIs for the resources, Universal Resource Indicators, being the location of each resource.
  • Manipulation of resources through representations A representation consisting of a series of bytes (a plain text number of the degrees in centigrade, a JPEG image of the book cover, an XML document containing all the weather information, or even an XHTML fragment containing an XOXO list of book attributes). Note that there does not have to be a 1 to 1 relationship between the representation of the resource, and the resource itself. The resource is decoupled from its representation.
  • Self-Descriptive Messages Meta-data, pure and simple. A representation of a resource will have meta-data like its content-type. A resource will also have meta-data that may be independent from its representation, such as alternate representations. There may also be meta-data about the connection, (cache control information and authentication come to mind.)
  • Hypermedia as the engine of application state If applicable, there should be some kind of link to the next state of the application within the current representation sent to the client. The most obvious example might be that a POST request that creates or modifies a resource should return a pointer to a representation of that resource, either in the form of an HTML page containing a link, or even just a HTTP 302 Found, or more semantically, a HTTP 303 (see also).
• Layered - Each layer inside of a REST system cannot see beyond the layer it is connecting to. For example, the "client" that our RESTful service is talking to, might not be a client at all, but might be another server, such as a proxy, instead. As architect of the RESTful service, we don't care, we just treat it as a client and act on the request.
• There is an optional constraint to the REST style, and that is that a REST system may also be constrained by code-on-demand. Which is to say, you can make it a feature of your system that code is to be downloaded and executed by the client (Java, Flash, Javascript, etc.) as part of the representation of the resource.

Thats it.

That is what it means to be restful. All this jazz about HTTP error messages, methods beyond GET and POST, its all just good HTTP baby. It has very little to do with actual restfulness or not. All the HTTP conformance in the world wont mean a thing if your application stores client state on the server. You still won't be RESTful.

Hopefully this helps.

Javascript is the most maligned, misunderstood language out there.

This should clear up any confusion. It is a series of slides from a talk about Javascript by Simon Wilson. Basically it is pure, unrelenting Javascript enlightenment inside of 111 well designed slides, occasionally punctuated with title-slides exhibiting excellent photography. It is delightfully focused on the language, and how to get stuff done with it. You won't find tutorials on how to make Javascript rollovers here. Instead, you will find tutorials on making Javascript LOVE... I mean... closures.

SexXxiest. Presentation. EVAR.

(Spellbound wanted to change SexXxiest to orthodoxies... fun!)

Okay, the title is a bit of a misnomer, because what I am about to explain to you isn't deep, let alone voodoo if you have any kind of experience with a language like scheme or you know what "first class functions" and "higher order functions" are. This entry is monsterous, so instead of filling up my main page full of PHP ranting, I am going to use the super-awesome-Serendipity-read-more-feature.

Ryan Tomayko Explains REST to his wife, and enlightenment ensues.

If you are at all interested in the web, this is a good read. It is non-technical, yet edifying.