Tags related to tag tutorial
Friday, May 5. 2006
How did I ever make music without this tutorial?
The first thing u need to do is download a music program.-- via Shell
I got some lined up for u:
Cool Edit Pro
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
Friday, March 31. 2006
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.
- 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.
- 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.
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
- 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.
- Everything uses GET and URIs are named after methods. This prevents cachability, and breaks the rule of HTTP where GET methods must be safe.
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.
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.
- 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-*)
Nothing I can see. The S3 REST API is an example of a well defined, well documented REST API.
- 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
- 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.
Does not claim to be RESTful, but it mostly is.
Ebay REST API (pdf link)
- 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).
- 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?)
Thursday, March 30. 2006
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...
This is the single biggest thing you can do to improve S9ys speed. APC is my favorite.
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.
Wednesday, March 22. 2006
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.
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.
Wednesday, March 8. 2006
SexXxiest. Presentation. EVAR.
(Spellbound wanted to change SexXxiest to orthodoxies... fun!)
Tuesday, February 21. 2006
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.