Web Developer Articles

File Storage

Thu, 03 Nov 2011 13:22:58 +0000

The next thing you should know and consider after codding and building website is deciding which storage are safer and cost more economical. Why? because safety is something comes on priority, any virus or someone hacking into your code, then everything you have done will be in vain.

There are many storage are offers, starting from conventional offline storage media such as cd, dvd, hdd, etc, and online storage media that are widely spread on the internet.

For a conventional offline storage media we all know that the media are quite limited into its size, but of course you could adding the size by adding new storage.

In order to solve the size problems, you could use other alternative such as DVD Ripper Ultimate, it could compact your file into smaller size but got the same quality as the original, especially if you’re converting audio or movie files. As for Mac user, you could use Mac DVD Ripper.

The online storage media that are widely offers in the internet are considerable as alternative online storage. Why? because its more simple, and you don’t have to carry all your storage media all around, just by remembering user name and password and log on to the server, you could get your desire files. Its more organize and easier.

These days technology are quite helpful for us especially in media storage, both offline and online storage are quite safe, just make sure you do know how to retrieve the files.

Ruby on Rails and PHP

Thu, 21 Jul 2011 16:22:54 +0000

What’s the difference between them? Lets find out more about it. Which one is better? Ruby or PHP? The answer is relative, its all depends on the developer, which one they like the most. Among all website builder, all of them have their own strength and weakness.

Ruby has been designed from the ground up as an object oriented language, and has a well thought out syntax. While has a much more extensive library of extensions and modules, and it’s object oriented model has been implemented over time.

Ruby’s community and as well as libraries are growing, but it is no where near the number of PHP’s. As a language Ruby is slower than PHP, but this is a bottleneck that can be worked around. The real issue is with Rails and its tightly coupled architecture.

Rails is a framework – a contract on how an applications architecture’s base will be implemented. 9 times out of 10 Rubiest think framework first ( Rails ) vs Language first; they were introduced ruby via rails. 9.9 times out of 10 perl,php, and python people think language first. The success of Rails has brought about an implementation of it MVC structure to perl, php, and python which has enabled perl,php, and python use to ADOPT BEST PRACTICES via Frameworks like symfony,zend,cakephp, django, joomla framework ( not the cms ).

Now because Rails is such a “turn keyish” type of framework, issues start to occur when sites start to grow, and what happens is that because so much was done for you at the framework level, meaning “Oh, look in Rails you don’t have to worry about X, it is handled automatically”, that when issues start to occur you are not familiar thoroughly with the architecture ( internals of RAILS) that is becomes extra work to handle high loads.

These issues are also in CakePHP which is the closest implementation of Rails in PHP, they even copied the mistakes! Symfony, Zend, and Joomla Framework are much more loosely coupled, with Zend coming out as the loosest. To deal with very high traffic, TWITTER had to start scrapping away RAILS in certain parts and start developing with scala and even c++. Many Rails fanboys started crying when this happened.

In all, there are very competent Ruby programmers out there that aren’t tied to Rails, but nowhere near the amount of PHP. Either with Ruby on Rails or PHP or any other programming language, its easier when you got basic knowledge about it, its would help you on creating website.

Permalinks

Wed, 09 Mar 2011 12:03:10 +0000

A permalink is an attribute of a Story, so we’ll need to modify our schema so that one can be stored for each story. We’ve already seen migrations in action each of our existing migrations was generated when we created a new model. Now we need to expand an existing model, so that we can add a permalink attribute to the Story model.

To add a migration without adding a new model, we use the generate script, passing migration as the first parameter:
$ ruby script/generate migration AddPermalinkToStories

This code generates a single migration file by the name of db/migrate/003_add_permalink_to_stories.rb. Edit this file so that its contents reflect the following:

class AddPermalinkToStories < ActiveRecord::Migration
def self.up
add_column :stories, :permalink, :string
end
def self.down
remove_column :stories, :permalink
end
end

Unlike our previous migrations, here we’re modifying the structure of an existing table, rather than creating a brand new one. The add_column function fills this role nicely:
add_column :story, :permalink, :string

The syntax of the add_column function is almost identical to that of the create_table function we’ve used before we just need to pass it the name of the table we want to modify, and the name and type of the column we want to add.
In this case, we’re adding a column with the name permalink, of type string, to the stories table.
In previous migrations, we haven’t needed to modify the self.down method, but this time we’ve added a line to it:
remove_column :stories, :permalink

When this migration is reversed, we want to remove a single column, rather than drop the entire table (which would be extremely bad news). As with add_column, remove_column takes symbols as its parameters. These symbols represent the
table that’s being modified, and the name of the column that we’re removing.
We don’t need to specify the column type when we’re removing a column, so this isn’t included as a parameter.
Go ahead and apply this migration using the rake tool:
$ rake db:migrate

This will add the new column to the stories table, the output of which is shown below:

To finish off this little exercise in altering our app’s infrastructure, we need to populate our newly added permalink column with a value for each of the stories that have already been added to our database.

From the Rails console, fetch a single Story. Update its permalink attribute using the update_attribute method:
>> s = Story.find(:first)
=> #
>> s.name
=> “My shiny weblog”
>> s.update_attribute :permalink, ‘my-shiny-weblog’
=> true
>> s.permalink
=> “my-shiny-weblog”

As you can see, the permalink I created for this entry is loosely adapted from the name of the Story: spaces have been replaced with dashes, and uppercase letters with lowercase letters.

URLs

Wed, 09 Mar 2011 11:58:00 +0000

In terms of viewing our sites, our users currently only have access to a page that displays a random story. To address this issue, we’ll add a new action that displays a single story, along with all of its details, before we implement the voting actions themselves. The story page will serve as a reference point for any given story on the site, as it will contain a range
of information voting actions, voting history, and so on about the story. Before we dive into the creation of our story page, let’s take a quick but important detour. The development of a story page such as this provides the perfect opportunity for a discussion about clean URLs.

Rails translates URLs of a certain format into actions that are invoked on a controller class. The translation, known as routing, is performed by the Rails Routing module.
Consider a URL that has the following format:

http://domain.com/story/show/1

Since most web applications operate on a single domain, we can ignore the domain part of the URL for now. That leaves us with a path that contains several components, separated by forward slashes:
/story/show/1

By default, the Routing module operates as follows:
? The first part of the URL is mapped to the corresponding controller. In this example, /story would route to our StoryController controller.
? The second part of the URL routes to the action name. In this case, the show action would be invoked.
? The third part is used to populate the id entry in the params hash. In our example, the value of params[:id] would be set to 1.

The end result of this routing is that the show action of the StoryController class would be called, and params[:id] would receive a value of 1. This is all well and good, and such a URL structure is certainly neater than many of the more complicated URLs out there on the Web. But an id of 1 isn’t exactly meaningful to our users—they’re more likely to remember the title of a story. Even if the title was slightly modified (with special characters removed, escaped, or replaced), it would still make for a more usable URL.

As I mentioned, converting a title to a URL like this will require a little work on our behalf (setting all characters to lowercase, and replacing spaces with dashes, in this case). But from a usability perspective, it’s quite obvious that the URL relates to the story, so this idea is definitely worth implementing.
To do so, we’ll modify the configuration of the Rails Routing module to support clean URLs like the one above. The routing configuration is stored in the file config/routes.rb, and (once all of the comments are stripped out) looks like this:

ActionController::Routing::Routes.draw do |map|
map.connect ‘:controller/service.wsdl’, :action => ‘wsdl’
map.connect ‘:controller/:action/:id’
end

The two calls to map.connect are Rails routes rules that specify how a URL should be mapped. Routes are read from top to bottom; the route with the lowest priority is the one at the very bottom of the list. In almost all cases, this will be the default route, which, as we learned above, is responsible for mapping a controller name, an action name, and an id:
map.connect ‘:controller/:action/:id’

To implement clean URLs for stories, we’ll insert the following line between the two existing routes:
map.story ‘story/show/:permalink’,
:controller => ‘story’,
:action => ‘show’

This newly added route will match any URLs of the following form:
/story/show/my-shiny-weblog

In this route, we’ve explicitly named the controller and the specific action that should handle a URL in this format. As a result, a URL of this form will always be handled by the show action of our StoryController. The permalink (an abbreviation
of permanent link) that appears at the end of the route is the part of the URL that will be placed in the arams[:permalink] hash area.

The syntax for matching the URL is absolutely identical to that used in the default route: any string prefixed with a colon (with the exception of the :controller and :action reserved words) ends up as a value in the params hash, thus becoming
available to both the controller and its views.

But why are we using map.story instead of the default, map.connect? Well, because we can—what we’re defining here is a named route. A named route is a custom alias for matching an incoming request’s URL. Requests with a URL that matches the defined pattern are directed to a specific page within our application (in this instance, the show action for our StoryController). Assigning the name story to this route makes sense, because we’re directing requests that relate to Story objects. Named routes are available from both controllers and views, and provide an easy way to direct requests to common pages within our application.

Now, all we need is a permalink value. Check out next articles.

Creating a View

Wed, 09 Mar 2011 11:48:46 +0000

After creating a model and a controller, then its time for us to create a view. We can use two approaches to build views for our Rails application. One is to make use of scaffolding; the other is to “go it alone.” We’ll look at scaffolding very briefly, but we won’t be using it much in the development of our Shovell application. I’ll introduce just enough to give you a taste
of this topic, then leave it up to you to decide whether or not you find it worthwhile in your own projects.

Generating Views with Scaffolding
In the early days of Rails, scaffolding was one of the features that the Rails community used as a selling point when promoting the framework. Ironically, this feature also received a considerable amount of criticism, though this was
largely due to critics failing to understand fully the intended uses of scaffolding.
Scaffolding is a tool that quickly creates a web interface for interacting with your model data. The interface lists the existing data in a table, and provides an easy way to add new records and manipulate or delete existing ones.

There are two approaches to using scaffolding:
Temporary scaffolding
Temporary scaffolding, which is simply a one-line addition to one of your controllers, is a technique for generating code that’s not intended to be built upon. Much like its construction namesake, temporary scaffolding is intended to support a primary structure, not form part of it. Once the primary structure has been completed, the scaffolding is taken away.

Permanent scaffolding
Permanent scaffolding, as you might have guessed, is intended to be extended, modified, and built upon. It uses the generate script which we’ve experimented with in this chapter to create fully working template code that can be modified over time. Features provided by the template code can then be tweaked or implemented in a different manner, and code that doesn’t suit your project can be removed.

Regardless of which approach you use, you should keep in mind that scaffolding is a tool designed for quick interaction with models, and should only be used as such. It is by no means intended to be a fully automated tool for generating web
applications (or even administration interfaces).