Courses/CS 491ab/Winter 2008/Urvishkumar Mehta
From CSWiki
[edit] 491ab generic information
Frameworks, libraries, technologies, tools, and components
When developing non-trivial software is it generally a good idea to make use of existing frameworks, libraries, tools, technologies, and components rather than to develop a similar capability from scratch. To help us get acquainted with what turns out to be a very wide range of available systems, we will explore some of them in this class. The plan is for everyone to report on one each week for the first few weeks.
[edit] Week 1 - January 4, 2008
Introduction class. Started researching existing frameworks on web based applications.
[edit] Week 2 - January 11, 2008
This was the class introduction.
As the 491a is about preparing project, we need to work on research work on what i feel is like we need t search and find out what we dont know about and do some serious work on it and make it unique and intelligent module system. In short introduction to the 419 a which is all about why we are in Computer science and your cultivation and thinking regarding project ideas.
As i did not register for the class, was unable to attend it. Meanwhile i was working and searching on some of the Older version technologies called CGI, PERL and acme to know about the Todays world new and emerging technologies like python, Ruby and ASP are outcome of those basic languages.
At the moment I was leaning towards preparing web application wich is gonna useful to students belongs to specific education center running toefl and ielts english coaching classes. The web would be containing certain online coaching classes and some other stuff like downloading and uploading certain paper work. i think this is gonna be good exepierence of creating web application based on some teaching purpose.
It seems like a good opportunity to work with web programming which interests me more than any other subject in CS. Also, it is something i might want to do in the future as a career option. I am looking forward to exploring other interests, and learning new things having to do with web programming.
[edit] Week 3 - January 18, 2008
This week I continued my work on CGI based application and finding framework and for craeting CGI based application.
Common Gateway Interface
The Common Gateway Interface (CGI) is a standard for interfacing external applications with information servers, such as HTTP or Web servers. A plain HTML document that the Web daemon retrieves is static, which means it exists in a constant state: a text file that doesn't change. A CGI program, on the other hand, is executed in real-time, so that it can output dynamic information.
For example, let's say that you wanted to "hook up" your Unix database to the World Wide Web, to allow people from all over the world to query it. Basically, you need to create a CGI program that the Web daemon will execute to transmit information to the database engine, and receive the results back again and display them to the client. This is an example of a gateway, and this is where CGI, currently version 1.1, got its origins.
The database example is a simple idea, but most of the time rather difficult to implement. There really is no limit as to what you can hook up to the Web. The only thing you need to remember is that whatever your CGI program does, it should not take too long to process. Otherwise, the user will just be staring at their browser waiting for something to happen.
Specifics
Since a CGI program is executable, it is basically the equivalent of letting the world run a program on your system, which isn't the safest thing to do. Therefore, there are some security precautions that need to be implemented when it comes to using CGI programs. Probably the one that will affect the typical Web user the most is the fact that CGI programs need to reside in a special directory, so that the Web server knows to execute the program rather than just display it to the browser. This directory is usually under direct control of the webmaster, prohibiting the average user from creating CGI programs. There are other ways to allow access to CGI scripts, but it is up to your webmaster to set these up for you. At this point, you may want to contact them about the feasibility of allowing CGI access.
If you have a version of the NCSA HTTPd server distribution, you will see a directory called /cgi-bin. This is the special directory mentioned above where all of your CGI programs currently reside. A CGI program can be written in any language that allows it to be executed on the system, such as:
* C/C++ * Fortran * PERL * TCL * Any Unix shell * Visual Basic * AppleScript
It just depends what you have available on your system. If you use a programming language like C or Fortran, you know that you must compile the program before it will run. If you look in the /cgi-src directory that came with the server distribution, you will find the source code for some of the CGI programs in the /cgi-bin directory. If, however, you use one of the scripting languages instead, such as PERL, TCL, or a Unix shell, the script itself only needs to reside in the /cgi-bin directory, since there is no associated source code. Many people prefer to write CGI scripts instead of programs, since they are easier to debug, modify, and maintain than a typical compiled program.
[edit] Week 4 - January 25, 2008
CGI AND COMPARISION OF OTHER LANGUAGES
CGI and SSI (Server-Side Includes) are often interchangable, and it may be no more than a matter of personal preference. Here are a few guidelines:
1) CGI is a common standard agreed and supported by all major HTTPDs.
SSI is NOT a common standard, but an innovation of NCSA's HTTPD
which has been widely adopted in later servers. CGI has the
greatest portability, if this is an issue.
2) If your requirement is sufficiently simple that it can be done
by SSI without invoking an exec, then SSI will probably be
more efficient. A typical application would be to include
sitewide 'house styles', such as toolbars, netscapeised <body>
tags or embedded CSS stylesheets.
3) For more complex applications - like processing a form -
where you need to exec (run) a program in any case, CGI
is usually the best choice.
4) If your transaction returns a response that is not an HTML page,
SSI is not an option at all.
Many more recent variants on the theme of SSI are now available. Probably the best-known are PHP which embeds server-side scripting in a pre-html page, and ASP which is Microsoft's version of a similar interface.
There are too many languages to enumerate - but I'll try and summarise. Briefly, there are several decisions you have to make, including:
* Power. Is it up to a complex task? * Complexity. How much programming manpower is it worth? * Portability. Might you want to run your program on another system?
So here's an overview of the main options. It's inevitably subjective, but may be helpful to someone:
Basic SSI: Simple interface for basic dynamic content. Non-standard - read your server docs.
Enhanced SSI[1]: Suitable for more complex tasks within an HTML page.
CGI: The standardised, portable general-purpose API, not limited to working with HTML pages.
Enhanced CGI-like[2]: Typically gain efficiency but lose portability compared to standard CGI.
Servlets: An alternative API for JAVA, that overcomes the limitation of JAVA not supporting environment variables.
Server API: Generally the most powerful and most complex option.
[1] For example, PHP, ASP. [2] For example, CGI adapted to mod_perl or fastcgi.
About File Permission
Unix systems are designed for multiple users, and include provision for protecting your work from unauthorised access by other users of the system. The file permissions determine who is permitted to do what with your programs, data, and directories. The command that sets file permissions is chmod.
Web servers typically run as user "nobody". That means that, setting aside serious bugs (such as those in certain versions of the Frontpage extensions), your files are absolutely secure from damage through the webserver. It also means that you may have to make explicit changes to enable the server to access them in a CGI context.
There are two ways to run CGI: - by default they run as the webserver user (nobody) For most purposes this is safest, as your programs and data are protected by the operating system from unauthorised access through possible bugs in your CGI. However, when the CGI has to write to a file, that file must be writable to every web user on the system, and is therefore completely unprotected. - setuid, they run under your own userid. This means that files written by your CGI can be secure. On the other hand, any bugs in your CGI could now compromise *all* your programs and data on the server. As an elementary security precaution, scripts (e.g. Perl) are prevented from running setuid by most OSs. The "cgiwrap" program offers a workaround for this.
A third way you should *never* permit CGI to be run is: - as root or setuid root, they can run as any user. This is extremely dangerous, as any bugs could compromise the entire server, including every user's files. Fortunately only the system administrator can install setuid root programs. If you are *at all* concerned about security, make sure that no such programs (in particular Frontpage extensions) are installed, regardless of whether you use them yourself.
For a proper overview, "man chmod". Some modes that may be useful in a typical CGI context are:
- CGI programs, 0755
- data files to be readable by CGI, 0644
- directories for data used by CGI, 0755
- data files to be writable by CGI, 0666 (data has absolutely no security)
- directories for data used by CGI with write access, 0777 (no security)
- CGI programs to run setuid, 4755
- data files for setuid CGI programs, 0600 or 0644
- directories for data used by setuid CGI programs, 0700 or 0755
- For a typical backend server process, 4750
[edit] Week 5 - February 1, 2008
[edit] Week 6 - February 8, 2008
Intorduction.
What's Ruby
Ruby is the interpreted scripting language for quick and easy object-oriented programming. It has many features to process text files and to do system management tasks (as in Perl). It is simple, straight-forward, extensible, and portable.
Features of Ruby Ruby has simple syntax, partially inspired by Eiffel and Ada.
Ruby has exception handling features, like Java or Python, to make it easy to handle errors.
Ruby's operators are syntax sugar for the methods. You can redefine them easily.
Ruby is a complete, full, pure object oriented language: OOL. This means all data in Ruby is an object, in the sense of Smalltalk: no exceptions. Example: In Ruby, the number 1 is an instance of class Fixnum.
Ruby's OO is carefully designed to be both complete and open for improvements. Example: Ruby has the ability to add methods to a class, or even to an instance during runtime. So, if needed, an instance of one class *can* behave differently from other instances of the same class.
Ruby features single inheritance only, *on purpose*. But Ruby knows the concept of modules (called Categories in Objective-C). Modules are collections of methods. Every class can import a module and so gets all its methods for free. Some of us think that this is a much clearer way than multiple inheritance, which is complex, and not used very often compared with single inheritance (don't count C++ here, as it has often no other choice due to strong type checking!).
Ruby features true closures. Not just unnamed function, but with present variable bindings.
Ruby features blocks in its syntax (code surrounded by '{' ... '}' or 'do' ... 'end'). These blocks can be passed to methods, or converted into closures.
Ruby features a true mark-and-sweep garbage collector. It works with all Ruby objects. You don't have to care about maintaining reference counts in extension libraries. This is better for your health. ;-)
Writing C extensions in Ruby is easier than in Perl or Python, due partly to the garbage collector, and partly to the fine extension API. SWIG interface is also available.
Integers in Ruby can (and should) be used without counting their internal representation. There *are* small integers (instances of class Fixnum) and large integers (Bignum), but you need not worry over which one is used currently. If a value is small enough, an integer is a Fixnum, otherwise it is a Bignum. Conversion occurs automatically.
Ruby needs no variable declarations. It uses simple naming conventions to denote the scope of variables. Examples: simple 'var' = local variable, '@var' = instance variable, '$var' = global variable. So it is also not necessary to use a tiresome 'self.' prepended to every instance member.
Ruby can load extension libraries dynamically if an OS allows.
Ruby features OS independent threading. Thus, for all platforms on which Ruby runs, you also have multithreading, regardless of if the OS supports it or not, even on MS-DOS! ;-)
Ruby is highly portable: it is developed mostly on Linux, but works on many types of UNIX, DOS, Windows 95/98/Me/NT/2000/XP, MacOS, BeOS, OS/2, etc.
Ruby on MAC OSX AND Framework:
What's is the package?
Rails is a full-stack framework for developing database-backed web applications according to the Model-View-Control pattern. From the Ajax in the view, to the request and response in the controller, to the domain model wrapping the database, Rails gives you a pure-Ruby development environment. To go live, all you need to add is a database and a web server.
Using Ruby on Rails for Web Development on Mac OS X
The Ruby on Rails web application framework has built up a tremendous head of steam over the last year. Fueled by some significant benefits and an impressive portfolio of real-world applications already in production, Rails is destined to continue making significant inroads in 2006. Simply put, Ruby on Rails is an open source tool that gives you the advantage of rapidly creating great web applications backed by SQL databases to keep up with the speed of the web. And with the release of Rails 1.0 kicking off the new year, there's never been a better time to climb aboard.
It should come as no surprise that Mac OS X is a favored platform for Rails development. Rails and its supporting cast of web servers and databases thrive on the rich Mac OS X environment. A popular text editor used by many Rails programmers is TextMate, a Cocoa application. And all members of the Rails core development team work with Macs.
This article introduces you to Ruby on Rails by building a trivial web application step by step. Consider it a ride on the express train—an overview of what Rails can do, including a look at features new to Rails 1.0. In the end you'll be better equipped to consider the advantages of powering your web application with Rails. Why Ruby on Rails?
First, you might be wondering: Web application frameworks are a dime a dozen, so what's different about Rails? Here are a few things that make Ruby on Rails stand above the crowd:
*
Full-Stack Web Framework. Rails is an MVC web framework where models, views, and controllers are fully integrated in a seamless fashion. That means you automatically get all the benefits of an MVC design without the hassle of explicitly configuring each component to play well with the others. *
Real-World Usage. The Rails framework was extracted from real-world web applications. That is, Rails comes from real need, not anticipating what might be needed. The result is an easy to use and cohesive framework that's rich in functionality, and at the same time it does its best to stay out of your way. *
One Language: Ruby. Everything from business logic to configuration files (there aren't many) are written in the Ruby programming language. With just one language, you hope it's a good one, and Ruby doesn't disappoint. Ruby is a full object-oriented language with clean syntax and it has a way of making programming truly fun. Using one language means you don't have to juggle between multiple languages and dialects as you're building your application. *
Convention over Configuration. Rails works hard to take care of all the repetitive and error-prone chores associated with starting to build a web application, and maintaining it over time. Rails uses simple naming conventions and clever use of reflection to make your work easier with near-zero configuration. *
It's Productive! At the end of the day, Rails is all about helping you stay productive. And in a world where being the first to market and keeping customers happy adds up to increased revenues for you, it pays to pick a tool aligned with those goals. Many real-world applications are already reaping the benefits.
All that being said, the best way to judge Rails is to experience it while building an application. So let's get right to it. Installing Rails
The version of Ruby that shipped on Mac OS X Tiger prior to v10.4.6 did not work well with Rails. If you're running an earlier version of Tiger, you'll need to either upgrade to 10.4.6 or upgrade your copy of Ruby to version 1.8.4 or later using the open source distribution.
And to do any serious Rails development you'll want to install a production-quality web server, database server, and a few other goodies. Thankfully, a golden-path installation guide is already available.
Creating a New Rails Application
We're going to build an online expense tracking application. You could use this for tracking expenditures for your personal budget, a small company, a group or club, etc. Say, for example, our club organizes fund-raising campaigns and we need to make sure expenses are in line with the budget for each event. The old paper and pencil system broke down last month, so we've decided that we need an online web application that everyone can share.
First we need to create the application. All Rails applications have a consistent directory structure so that Rails can find stuff without needing to be told where to look. Create a skeleton directory structure and a set of files for our expenses application by typing
$ rails expenses
Next, open the new project directory with TextMate by typing
$ mate expenses
In the TextMate Project Drawer, shown in Figure 1, you should see the directory structure that the rails command created. DirectoryStructure.jpg
Figure 1: Application Directory Structure (as shown in TextMate)
We'll peek inside these directories a bit later. But first, we're ready to run our application for the first time. Change directory to the expenses directory, then type:
$ script/server
You've just started a web server. If you have the LightTPD web server installed, Rails will attempt to use it by default. Otherwise WEBrick, the pure-Ruby web server that comes with Ruby, will be used. Either web server works well for development purposes.
Now point your web browser at http://localhost:3000. You should see a web page welcoming you aboard Rails. That tells us that the application is running, but it doesn't help our fund-raising campaign. Let's fix that.
