Learning Notes about Metaprogramming Ruby

1. Metaprogramming is writing code that manipulates language constructs at runtime.

2. Named Arguments allows you to set arguments by names rather than by position.

3. Argument array, the * operator collects multiple arguments in a single array.

def my_method(*args)
   args
end

my_method(1, '2', 'three') # => [1, "2", "three"]

4. Self Yield
When you pass a block to a method, you expect the method to call back to the block through yield.

5. Metaprogramming: design a Domain Specific Language (DSL) and then using that DSL to write your own program.

6. An object's instance variables live in the object itself, and an object's methods live in the object's class. (Objects of the same class share methods but don't share instance variables)

7. A class is just a souped-up module with 3 additional methods---new(), allocate() and supreclass()---that allows you to create objects or arrange classes into hierarchies.

8. Classes are nothing but objects, class names are nothing but constants.

9. Module is to be imported somewhere (or used as a Namespace) and class is to be instantiated or inherited.

10. load() to execute code and require() to import libraries.

11. When you call a method, actually you are sending a message to an object.

12. Symbol is immutable and some operations (such as comparison) run faster on symbol rather than on string. Symbol is used as the name of things, particularly, name of metaprogramming related things such as methods.

13. Black slate, a class that has fewer methods than the Object class itself since removing most inherited methods from your proxies right away.

14. Procs vs. Lambdas
1) In a lambda, return just returns from the lambda.
2) In the way check their arguments, lambda tends to be less tolerant than procs (and regular blocks).

15. Blocks(they aren't really "objects", but they are still callable): Evaluated in the scope in which they're defined.

Procs: Objects of class Proc. Like blocks, they are evaluated in the scope where they're defined.

Lambdas: Also objects of class Proc but subtly different from regular procs. They're closures like blocks and procs, and as such they're evaluated in the scope where they're defined.

Methods: Bound to an object, they are evaluated in that object's scope. They can also be unbound from their scope and rebound to the scope of another object.

16. Around Alias in three steps:
1) You alias a method.
2) You redefine it.
3) You call the old method from the new method.

17. When you learn that, when it comes right down to it, code is just text.

18. A master developer sits on top of mountain, meditating.
You are smart enough to learn, but are you smart enough to forget what you have learned? There's no such thing as metaprogramming. It's just programming all the way through.

19. Trade-off of metaprogramming
Complexity for beginner vs Complexity for experts

Internal Complexity vs External Complexity (By making insides of your code more complex, you make your library simpler for clients.

Complexity by Terseness vs Complexity by Duplication

Complexity for humans vs Complexity for tools

20. Class Extension Mixing turns methods in module into class methods, modules make code easier to understand and change.

21. Metaprogramming code can get complex but you can manage the complexity with unit testing which help you write code clean and error-free.

22. Ruby with Metaprogramming expects you manipulate the language constructs, tweak the object model, reopen classes, define methods dynamically, and manage scopes with blocks. (There's no such thing as metaprogramming. It's just programming all the way through.)

Cracking the Coding Interview reflection

1. When test multiple cases, be careful about resetting global or shared variables for next test case! (i.e. vertex visited or not in problem Search Route In A Graph, previous value in problem Validate Binary Search Tree)

2. Code in Google Java Style, which is widely used in Google Projects
http://google-styleguide.googlecode.com/svn/trunk/javaguide.html

For example,
1) add braces {} for one statement block like if, else, for, while.
2) Class name use UpperCamelCase. Method, Local Variable and Parameter name use lowerCaseCamel.
3) Noun for Class name, verb for method name, adjective for interface name.
4) null is not instance of anything.
5) package files for easy management and name space separation

3. My solution:
https://github.com/yao23/InterviewPreparation

4. OOD
1) Communication with the interviewer to clarify ambiguity for system sketch
2) Abstract objects from scenario, sometimes simplify the case, like corner pieces array in pro 6
3) Extract relationship between objects for inheritance, interface and property
4) Confirm action for methods, use key words in the problem
5) Divide large objects into components (i.e. online reading system into library, user manager and display)
6) HashMap is useful for fields or attribute design, Create/ Read/ Update/ Delete (CRUD) for methods design
7) Focus on core steps in the problem, such as attach edges, remove the edge from open edge lists, find next exposed edge in pro 6
8) use pseudo-code or comment to express ideas, what you did is less important than why you did, discuss trade-off with interviewer
9) use array for frequent searching, linked list for frequent adding and deleting

5. Database
1) trade-off between flexibility and complexity
2) Make assumptions. Incorrect assumptions can be dealt with as long as they were acknowledged in both reality and interview
3) Normalized database is designed to reduce redundancy and denormalized  one is to optimize read time with redundancy, but expensive to update and insert, sometimes inconsistent, need more storage

6. Stack can replace array when don't need to store immediate values, like Largest Rectangle in Histogram.

Elements of Programming Interview
1. Approaching the problem
Clarify the question
Work on small examples
Spell out the brute-force solution
Think out loud
Apply patterns(D&C, recursion, DP, graph, hashmap, binary tree, stack, etc.)

2. Presenting the solution
Libraries
Focus on the top-level algorithm
Manage the whiteboard
Test for corner cases
Syntax
Memory management

3. General conversation
Can the candidate clearly communicate a complex idea?
Is the candidate passionate about his work?
Is there a potential interest match with some project?

4. Other advice
Be honest
Keep a positive spirit
Don't apologize
Appearance
Be aware of your body language
Keep money and perks out of the interview

5. Stress interviews

6. Learning from bad outcomes

7. Data Structure
Primitive types, Array & String, List, Stack and Queue, Binary Tree, Heap, Hash Table, Binary Search Tree. (Skip List, Treap, Fibonacci Heap, Disjoint-set data structures, Tries)

8. Algorithm
Sorting, Recursion, Divide and Conquer, Dynamic Programming, Greedy, Incremental Improvement, Elimination, Parallelism, Caching, Randomization, Approximation, State

9. Abstract analysis techniques
Case analysis, Small examples, Iterative refinement, Reduction, Graph modeling, Write an equation, Variation, Invariants

Learning Notes about Agile Web Development with Rails (4)

Rails application --- Depot

Ruby on Rails shines when it comes to dealing with change—it’s an ideal agile
programming environment.

Along the way we will be building and maintaining a corpus of tests. These
tests will ensure that the application is always doing what we intend to do.
Rails not only enables the creation of such tests, it actually provides you with
an initial set of tests each time you define a new controller.

1. Use Cases

A use case is simply a statement about how some entity uses a system. Con-

sultants invent these kinds of phrases to label things we’ve all known all

along—it’s a perversion of business life that fancy words always cost more

than plain ones, even though the plain ones are more valuable.

2. Page Flow

Some folks like to mock up web application page flows using Photoshop, Word,

or (shudder) HTML. We like using a pencil and paper. It’s quicker, and the

customer gets to play too, grabbing the pencil and scribbling alterations right

on the paper.

3. Data

Finally, we need to think about the data we’re going to be working with.

Notice that we’re not using words such as schema or classes here. We’re also

not talking about databases, tables, keys, and the like. We’re simply talking

about data. At this stage in the development, we don’t know whether we’ll even

be using a database.

4. 

Task A: Creating the Application

Iteration A1: Creating the Products Maintenance Application

Creating a Rails Application

Creating the Database

Generating the Scaffold

Applying the Migration (Rake looks for all the migrations not yet applied to the database

and applies them.)

Iteration A2: Making Prettier Listings

Our customer has one more request (customers always seem to have one more

request). 

this code uses %{...}. This is an alternative syntax for double-quoted

string literals, convenient for use with long strings. 

Rails keeps a separate file that is used to create a standard page environment 

for the entire application. This file, called application.html.erb, is a Rails layout 

and lives in the layouts directory

• We created a development database.

• We used migration to create and modify the schema in our development

database.

• We created the products table and used the scaffold generator to write an

application to maintain it.

• Updated an application wide layout as well as controller specific view in

order to show a list of products.

Task B: Validation and Unit Testing

Iteration B1: Validating!

The model layer is the gatekeeper between

the world of code and the database. Nothing to do with our application comes

out of the database or gets stored into the database that doesn’t first go

through the model. This makes models an ideal place to put validations; it

doesn’t matter whether the data comes from a form or from some program-

matic manipulation in our application. If a model checks it before writing to

the database, then the database will be protected from bad data.

Iteration B2: Unit Testing of Models

An assertion is simply a method call that tells the framework what we expect to be true. 

Test Fixtures

In the world of testing, a fixture is an environment in which you can run a

test. 

In the world of Rails, a test fixture is simply a specification of the initial con-

tents of a model (or models) under test. If, for example, we want to ensure that

our products table starts off with known data at the start of every unit test, we

can specify those contents in a fixture, and Rails will take care of the rest.

What We Just Did

• We ensured that required fields were present.

• We ensured that price fields were numeric, and at least one cent.
• We ensured that titles were unique.
• We ensured that images matched a given format.
• We updated the unit tests that Rails provided, both to conform to the
constraints we have imposed on the model and to verify the new code
that we added.

Task C: Catalog Display

Iteration C1: Creating the Catalog Listing

Iteration C2: Adding a Page Layout

Iteration C3: Using a Helper to Format the Price

Iteration C4: Functional Testing of Controllers

Both validation and functional tests will only test the behavior of controllers, 

they will not retroactively affect any data that already exists in the database or 

in fixtures.

What We Just Did

We’ve put together the basis of the store’s catalog display. The steps were as

follows:

1. Create a new controller to handle customer-centric interactions.

2. Implement the default index action.

3. Add a default_scope to the Product model to specify the order to list the

items on the website.

4. Implement a view (an .html.erb file) and a layout to contain it (another

.html.erb file).

5. Use a helper to format prices the way we want.

6. Make use of a CSS stylesheet.

7. Write functional tests for our controller.

Task D: Cart Creation

Iteration D1: Finding a Cart

Iteration D2: Connecting Products to Carts

There’s an easy way to remember where to put

belongs_to declarations: if a table has foreign keys, the corresponding model

should have a belongs_to for each.

Iteration D3: Adding a Button

What We Just Did

It has been a busy, productive day so far. We’ve added a shopping cart to our

store, and along the way we’ve dipped our toes into some neat Rails features:

• We created a Cart object in one request and were able to successfully

locate the same Cart in subsequent requests using a session object,

• we added a private method in the base class for all of our controllers,

making it accessible to all of our controllers,

• we created relationships between Carts and Line Items, relationships

between Line Items and Products, and were able to navigate using these

relationships, and

• we added a button which caused a product to be POSTed to a cart, caus-

ing a new LineItem to be created.

Task E: A Smarter Cart

Iteration E1: Creating a Smarter Cart

Iteration E2: Handling Errors

Rails has a convenient way of dealing with errors and error reporting. It defines

a structure called a flash. A flash is a bucket (actually closer to a Hash) in which

you can store stuff as you process a request. The contents of the flash are

available to the next request in this session before being deleted automatically.

Typically the flash is used to collect error messages. 

Iteration E3: Finishing the Cart

What We Just Did
Our shopping cart is now something the client is happy with. Along the way,
we covered:

• Adding a column to an existing table, with a default value

• Migrating existing data into the new table format

• Providing a flash notice of an error that was detected

• Using the logger to log events

• Deleted a record

• Adjusted the way a table is rendered, using CSS.

Task F: Add a Dash of Ajax

Whenever you work with Ajax, it’s good to start with the non-Ajax version of

the application and then gradually introduce Ajax features. 

Iteration F1: Moving the Cart

A partial is simply a chunk of a view in its own separate file. You can

invoke (render) a partial from another template or from a controller, and the

partial will render itself and return the results of that rendering. And, just as

with methods, you can pass parameters to a partial, so the same partial can

render different results.

Rails automatically prepends an underscore to the partial name when looking 

for the file. 

Iteration F2: Creating an Ajax-Based Cart

Ajax lets us write code that runs in the browser that interacts with our server-

based application.

Iteration F3: Highlighting Changes

Iteration F4: Hiding an Empty Cart

Whenever we want to abstract some processing out of a view (any kind of view),

we should write a helper method.

What We Just Did

In this iteration we added Ajax support to our cart:

• We moved the shopping cart into the sidebar. We then arranged for the

create action to redisplay the catalog page.

• We used :remote => true to invoke the LineItem.new action using Ajax.

• We then used an RJS template to update the page with just the cart’s

HTML.

• To help the user see changes to the cart, we added a highlight effect,

again using the RJS template.

• We wrote a helper method that hides the cart when it is empty and used

the RJS template to reveal it when an item is added.

• We wrote a test which verifies not only the creation of a line item but also

the content of the response that is returned from such a request.

First, if you plan to do a lot of Ajax development, you’ll probably need to get familiar with your browser’s Java Script debugging facilities and with its DOM inspectors, such as Firefox’s Fire-
bug, Internet Explorer 8’s Developer Tools, Google Chrome’s Developer Tools,
Safari’s Web Inspector, or Opera’s Dragonfly. And, second, the NoScript plug-
in for Firefox makes checking JavaScript/no JavaScript a one-click breeze.
Others find it useful to run two different browsers when they are developing—
have JavaScript enabled in one, disabled in the other. Then, as new features
are added, poking at it with both browsers will make sure your application
works regardless of the state of JavaScript.

Task G: Check Out!

Iteration G1: Capturing an Order

Iteration G2: Atom Feeds

Iteration G3: Pagination

What We Just Did

In a fairly short amount of time, we did the following:

• We created a form to capture details for the order and linked it to a new

order model.

• We added validation and used helper methods to display errors to the

user.

• We installed and used a plugin to paginate the list of orders.

• We provided a feed so that the administrator can monitor orders as they

come in.

Task H: Sending Mail

Iteration H1: Sending Confirmation E-mails

Iteration H2: Integration Testing of Applications

Unit testing of models

Model classes contain business logic. For example, when we add a prod-

uct to a cart, the cart model class checks to see whether that product is

already in the cart’s list of items. If so, it increments the quantity of that

item; if not, it adds a new item for that product.

Functional testing of controllers

Controllers direct the show. They receive incoming web requests (typ-

ically user input), interact with models to gather application state, and

then respond by causing the appropriate view to display something to the

user. So when we’re testing controllers, we’re making sure that a given

request is answered with an appropriate response. We still need models,

but we already have them covered with unit tests.

The next level of testing is to exercise the flow through our application. In many

ways, this is like testing one of the stories that our customer gave us when we

first started to code the application. For example, we might have been told

that A user goes to the store index page. They select a product, adding it to their

cart. They then check out, filling in their details on the checkout form. When they

submit, an order is created in the database containing their information, along

with a single line item corresponding to the product they added to their cart.

Once the order has been received, an e-mail is sent confirming their purchase.

This is ideal material for an integration test. Integration tests simulate a con-

tinuous session between one or more virtual users and our application. You

can use them to send in requests, monitor responses, follow redirects, and so

on.

(When you create a model or controller, Rails creates the corresponding unit or

functional tests. Integration tests are not automatically created, however, but

you can use a generator to create one.)

What We Just Did

Without much code, and a few templates, we have managed to pull off the

following:

• We configured our development, test, and production environments for

our Rails application to enable the sending of outbound e-mails.

• We created and tailored a mailer which will send confirmation e-mails in

both plain text and HTML formats to people who order our products.

• We created both a functional test for the e-mails produced,

Task I: Logging In

Iteration I1: Adding Users

Iteration I2: Authenticating Users

Iteration I3: Limiting Access

Rails filters allow you to intercept calls to action methods, adding your own

processing before they are invoked, after they return, or both. In our case, we’ll

use a before filter to intercept all calls to the actions in our admin controller.

The interceptor can check session[:user_id]. If set and if it corresponds to a user

in the database, the application knows an administrator is logged in, and the

call can proceed. If it’s not set, the interceptor can issue a redirect, in this case

to our login page.

Iteration I4: Adding a Sidebar, More Administration

What We Just Did

By the end of this iteration, we’ve done the following:

• We created a virtual attribute representing the plain-text password and

coded it to create the hashed version whenever the plain-text version is

updated.

• We controlled access to the administration functions using before filters

to invoke an authorize method.

• We saw how to use rails console to interact directly with a model (and dig

us out of a hole after we deleted the last user).

• We saw how a transaction can help prevent deleting the last user.

Task J: Internationalization

Iteration J1: Selecting the locale

Iteration J2: Translating the Store Front

Iteration J3: Translating Checkout

Iteration J4: Add a Locale Switcher

What We Just Did

By the end of this iteration, we’ve done the following:

• We set the default locale for our application, and provided a means for

the user to select an alternate locale.

• We created translation files for text fields, currency amounts, errors, and

model names.

• We altered layouts and views to call out to the I18n module by way of the

t helper in order to translate textual portions of the interface.

Task K: Deployment and Production

Iteration K1: Deploying with Phusion Passenger and MySQL

A deployed Rails application works a bit differently. We can’t

just fire up a single Rails server process and let it do all the work. Well, we

could, but it’s far from ideal. The reason for this is that Rails is single-threaded.

It can work on only one request at a time.

The Web, however, is an extremely concurrent environment. Production web

servers, such as Apache, Lighttpd, and Zeus, can work on several requests—

even tens or hundreds of requests—at the same time. A single-process, single-

threaded Ruby-based web server can’t possibly keep up. Luckily, it doesn’t

have to keep up. Instead, the way that we deploy a Rails application into pro-

duction is to use a front-end server, such as Apache, to handle requests from

the client. Then, you use the HTTP proxying of Passenger to send requests

that should be handled by Rails to one of any number of back-end application

processes.

SQLite is not recommended for high-volume, high concurrency web sites with large

datasets. 

There are plenty of alternatives to SQLite, both free and commercial. We will

go with MySQL. It already is included in OSX, is available via your native

packaging tool in Linux, 

Iteration K2: Deploying Remotely with Capistrano

Iteration K3: Checking Up on a Deployed Application

What We Just Did

We covered a lot of ground in this chapter. We’ve taken our code that ran locally

on our development machine for a single user and placed it on a different

machine, running a different web server, accessing a different database, and

possibly even running a different operating system.

To accomplish this, we used a number of different products:

• We installed and configured Phusion Passenger and Apache httpd, a pro-

duction quality web server.

• We installed and configured MySQL, a production quality database server.

• We got our application’s dependencies under control using Bundler and

Git.

• We installed and configured Capistrano, which enables us to confidently

and repeatably deploy our application.

Learning Notes about Agile Web Development with Rails (3)

Basic Ruby programming language knowledge

1. Ruby Names

Local variables, method parameters, and method names should all start with
a lowercase letter or with an underscore: order, line_item, and xr2000 are all
valid. Instance variables begin with an “at” sign (@), such as @quantity and @product_id. The Ruby convention is to use underscores to separate words in a multiword method or variable name (so
line_item is preferable to lineItem).

Class names, module names, and constants must start with an uppercase
letter. By convention they use capitalization, rather than underscores, to dis-
tinguish the start of words within the name. Class names look like Object,
PurchaseOrder, and LineItem.

Rails uses symbols to identify things. In particular, it uses them as keys when
naming method parameters and looking things up in hashes.

2. Methods

You don’t need a semicolon at the end of a statement as long as you put each

statement on a separate line. Ruby comments start with a # character and

run to the end of the line. Indentation is not significant (but two-character

indentation is the de facto Ruby standard).

Ruby doesn’t use braces to delimit the bodies of compound statements and

definitions (such as methods and classes). Instead, you simply finish the body

with the keyword end. The keyword return is optional, and if not present, the

results of the last expression evaluated will be returned.

3. Strings

This previous example also showed some Ruby string objects. One way to cre-

ate a string object is to use string literals, which are sequences of characters

between single or double quotation marks. The difference between the two

forms is the amount of processing Ruby does on the string while constructing

the literal. In the single-quoted case, Ruby does very little. With a few excep-

tions, what you type into the single-quoted string literal becomes the string’s

value.

In the double-quoted case, Ruby does more work. First, it looks for substitu-

tions—sequences that start with a backslash character—and replaces them

with some binary value. The most common of these is \n, which is replaced

with a newline character. When you write a string containing a newline to the

console, the \n forces a line break.

Second, Ruby performs expression interpolation in double-quoted strings. In

the string, the sequence #{expression } is replaced by the value of expression.

4. Arrays and Hashes

Ruby’s arrays and hashes are indexed collections. Both store collections of

objects, accessible using a key. With arrays, the key is an integer, whereas

hashes support any object as a key. Both arrays and hashes grow as needed

to hold new elements. It’s more efficient to access array elements, but hashes

provide more flexibility. Any particular array or hash can hold objects of dif-

fering types; you can have an array containing an integer, a string, and a

floating-point number, for example.

You can create and initialize a new array object using an array literal—a set

of elements between square brackets. Given an array object, you can access

individual elements by supplying an index between square brackets, as the

next example shows. Ruby array indices start at zero.

In Rails, hashes typically use symbols as keys. Many Rails hashes have been
subtly modified so that you can use either a string or a symbol interchangeably
as a key when inserting and looking up values.

nil is an object, just like any other, that happens to represent
nothing. nil means false when used in conditional expressions.

5. Regular Expressions

A regular expression lets you specify a pattern of characters to be matched in

a string. In Ruby, you typically create a regular expression by writing /pattern/

or %r{pattern}.

6. Block

Code blocks are just chunks of code between braces or between do...end. A
common convention is that people use braces for single-line blocks and do/end
for multiline blocks.

A method can invoke an associated block one or more times using the Ruby
yield statement. You can think of yield as being something like a method call

that calls out to the block associated with the method containing the yield. 

You can pass values to the block by giving parameters to yield. 

7. Exceptions

Exceptions are objects (of class Exception or its subclasses). The raise method

causes an exception to be raised. This interrupts the normal flow through the

code. Instead, Ruby searches back through the call stack for code that says it

can handle this exception.

Both methods and blocks of code wrapped between begin and end keywords

intercept certain classes of exceptions using rescue clauses.

rescue clauses can be directly placed on the outermost level of a method defi-

nition without needing to enclose the contents in a begin/end block.

8. Modules

Modules are similar to classes in that they hold a collection of methods, con-
stants, and other module and class definitions. Unlike classes, you cannot
create objects based on modules.

Modules serve two purposes.
First, they act as a namespace, letting you define methods whose names will not
clash with those defined elsewhere.
Second, they allow you to share functionality between classes—if a class mixes in a
module, that module’s instance methods become available as if they had been
defined in the class. Multiple classes can mix in the same module, sharing the
module’s functionality without using inheritance. You can also mix multiple
modules into a single class.

Helper methods are an example of where Rails uses modules. Rails automat-
ically mixes these helper modules into the appropriate view templates.

9. YAML

YAML is a recursive acronym which stands for YAML Ain’t Markup Language.
In the context of Rails, YAML is used as a convenient way to define config-
uration of things such as databases, test data, and translations.

10. Marshaling Objects

Ruby can take an object and convert it into a stream of bytes that can be stored
outside the application. This process is called marshaling. This saved object
can later be read by another instance of the application (or by a totally separate
application), and a copy of the originally saved object can be reconstituted.

There are two potential issues when you use marshaling. First, some objects
cannot be dumped. If the objects to be dumped include bindings, procedure or
method objects, instances of class IO, singleton objects, or if you try to dump
anonymous classes or modules, a TypeError will be raised.
Second, when you load a marshaled object, Ruby needs to know the definition
of the class of that object (and of all the objects it contains).

Rails uses marshaling to store session data. If you rely on Rails to dynam-
ically load classes, it is possible that a particular class may not have been
defined at the point it reconstitutes session data. For that reason, you’ll use
the model declaration in your controller to list all models that are marshaled.
This preemptively loads the necessary classes to make marshaling work.

11. Ruby Idioms

1) lambda

The lambda operator converts a block into a object of type Proc. 

2) require File.dirname(__FILE__) + ’/../test_helper’

Ruby’s require method loads an external source file into our application.

This is used to include library code and classes that our application relies

on. In normal use, Ruby finds these files by searching in a list of direc-

tories, the LOAD_PATH.

Learning Notes about Agile Web Development with Rails (2)

Chapter 3 1. MVC architecture The model is responsible for maintaining the state of the application. Some- times this state is transient, lasting for just a couple of interactions with the user. Sometimes the state is permanent and will be stored outside the appli- cation, often in a database. A model is more than just data; it enforces all the business rules that apply to that data. (The model acts as both a gatekeeper and a data store.) The view is responsible for generating a user interface, normally based on data in the model. Although the view may present the user with various ways of inputting data, the view itself never handles incoming data. The view’s work is done once the data is displayed.  Controllers orchestrate the application. Controllers receive events from the outside world (normally user input), interact with the model, and display an appropriate view to the user. The MVC architecture was originally intended for conventional GUI applica- tions, where developers found the separation of concerns led to far less cou- pling, which in turn made the code easier to write and maintain.  2. Rails processing flow 1) In a Rails application, an incoming request is first sent to a router, which works out where in the application the request should be sent and how the request itself should be parsed.  2) The routing component receives the incoming request and immediately picks it apart.    3) Controller interacts with model 4) Controller invokes view 5) View renders next browser screen 3. Why need a framework such as Ruby on Rails?  The answer is straightforward: Rails handles all of the low-level housekeeping for you—all those messy details that take so long to handle by yourself—and lets you concentrate on your application’s core functionality. 4. Object-Relational Mapping Relational databases are actually designed around mathematical set theory. Although this is good from a conceptual point of view, it makes it difficult to combine relational databases with object-oriented (OO) program- ming languages. Objects are all about data and operations, and databases are all about sets of values. Operations that are easy to express in relational terms are sometimes difficult to code in an OO system. The reverse is also true.   So, an ORM layer maps tables to classes, rows to objects, and columns to attributes of those objects. Class methods are used to perform table-level oper- ations, and instance methods perform operations on the individual rows. Active Record Active Record is the ORM layer supplied with Rails. It closely follows the stan- dard ORM model: tables map to classes, rows to objects, and columns to object attributes. It differs from most other ORM libraries in the way it is configured. By relying on convention and starting with sensible defaults, Active Record minimizes the amount of configuration that developers perform.  Active Record relieves us of the hassles of dealing with the underlying database, leaving us free to work on business logic. But Active Record does more than that. Active Record integrates seam- lessly with the rest of the Rails framework. If a web form sends the application data related to a business object, Active Record can extract it into our model. Active Record supports sophisticated validation of model data, and if the form data fails validations, the Rails views can extract and format errors. Active Record is the solid model foundation of the Rails MVC architecture. 5. Action Pack: The View and Controller When you think about it, the view and controller parts of MVC are pretty intimate. The controller supplies data to the view, and the controller receives events from the pages generated by the views. Because of these interactions, support for views and controllers in Rails is bundled into a single component, Action Pack.      6. View Support In Rails, the view is responsible for creating either all or part of a response to be displayed in a browser, processed by an application or sent as an email. At its simplest, a view is a chunk of HTML code that displays some fixed text. More typically you’ll want to include dynamic content created by the action method in the controller. In Rails, dynamic content is generated by templates, which come in three flavors.  1) The most common templating scheme, called Embedded Ruby (ERb), embeds snippets of Ruby code within a view document, in many ways similar to the way it is done in other web frameworks, such as PHP or JSP.  2) XML Builder can also be used to construct XML documents using Ruby code— the structure of the generated XML will automatically follow the structure of the code. 3) Rails also provides RJS views. These allow you to create JavaScript fragments on the server that are then executed on the browser. This is great for creating dynamic Ajax interfaces. 7. Controller! The Rails controller is the logical center of your application. It coordinates the interaction between the user, the views, and the model. However, Rails handles most of this interaction behind the scenes; the code you write concentrates on application-level functionality. This makes Rails controller code remarkably easy to develop and maintain. The controller is also home to a number of important ancillary services: • It is responsible for routing external requests to internal actions. It han- dles people-friendly URLs extremely well. • It manages caching, which can give applications orders-of-magnitude performance boosts. • It manages helper modules, which extend the capabilities of the view templates without bulking up their code. • It manages sessions, giving users the impression of ongoing interaction with our applications.

Learning Notes about Agile Web Development with Rails

Ruby on Rails two philosophy:
1. DRY, don't repeat yourself.
Modulize the program, remove duplication. Ruby does very well basically, Rails was written in Ruby.
2. Convention over configuration.
Follow convention, write less code than use XML in Java.

Agile development core ideas:
1. Individuals and interactions over processes and tools
2. Working software over comprehensive documentation
3. Customer collaboration over contract negotiation
4. Responding to change over following a plan

Rails is agile itself! Elegant, faster, programmer-friendly.

Basic concepts in Computer Vision and Machine Learning

Attribute: a semantic way to describe objects, human defined most times, like color, type, etc.

Feature: a piece of information which is relevant for solving the computational task related to a certain application. More specifically, features can refer to:

1. the result of a general neighborhood operation (feature extractor or feature detector) applied to the image

2. specific structures in the image itself, ranging from simple structures such as points or edges to more complex structures such as objects.

Other examples of features are related to motion in image sequences, to shapes defined in terms of curves or boundaries between different image regions, or to properties of such a region.

The feature concept is very general and the choice of features in a particular computer vision system may be highly dependent on the specific problem at hand.

http://en.wikipedia.org/wiki/Feature_%28computer_vision%29

Bag-of-words (BoW model): can be applied to image classification, by treating image features as words. In computer vision, a bag of visual words is a sparse vector of occurrence counts of a vocabulary of local image features.

The first step is to extract features, the second one is to represent features.

The final step for the BoW model is to convert vector represented patches to "codewords" (analogy to words in text documents), which also produces a "codebook" (analogy to a word dictionary). A codeword can be considered as a representative of several similar patches.

One of notorious disadvantages of BoW is that it ignores the spatial relationships among the patches, which is very important in image representation.

Furthermore, the BoW model has not been extensively tested yet for view point invariance and scale invariance, and the performance is unclear. Also the BoW model for object segmentation and localization is not well understood.

http://en.wikipedia.org/wiki/Bag-of-words_model_in_computer_vision

Scale Invariant Feature Transform (SIFT) is a feature detector and descriptor algorithm notable for incorporating robust scale and rotational invariance to feature descriptions.

Histogram of Gradient (HOG):

k-means clustering: a method of cluster analysis which aims to partition n observations into k clusters in which each observation belongs to the cluster with the nearest mean. This results in a partitioning of the data space into Voronoi cells.

http://en.wikipedia.org/wiki/K-means_clustering
https://www.youtube.com/watch?v=aiJ8II94qck
https://www.youtube.com/watch?v=0MQEt10e4NM

k-nearest neighbor (k-NN): a non-parametric method for classifying objects based on closest training examples in the feature space.

https://en.wikipedia.org/wiki/K-nearest_neighbors_algorithm

regression: a statistical technique for estimating the relationships among variables. It includes many techniques for modeling and analyzing several variables, when the focus is on the relationship between a dependent variable and one or more independent variables. More specifically, regression analysis helps one understand how the typical value of the dependent variable changes when any one of the independent variables is varied, while the other independent variables are held fixed.

https://en.wikipedia.org/wiki/Regression_analysis

AdaBoost: several weak classifier to construct strong classifier

Support Vector Machine (SVM): classifier

Reduce dimensionality

Principal Component Analysis (PCA): align data along the directions of greatest variance (retain directions of large variance, but large variance is not always best for classification)

Linear Discriminant Analysis (LDA): project onto a subspace of best discrimination by maximizing the separation between classes relative to separation within classes  (take into account the actual classes, ratio about the distance between classes and the one within classes)

Deformable Part Model (DPM):