open a new tab in gnome terminal

#!/bin/sh

DB1BUGS="mysql xxx"
DB1HW="mysql xxx"
LiveBUGS="mysql xxx"
LiveHW="mysql xxx"
LocalBUGS="mysql xxx"
LocalHW="mysql xxx"

CMD="gnome-terminal --maximize"

for cmd in DB1HW DB1BUGS LiveHW LiveBUGS LocalHW LocalBUGS
    do  
        eval cmd_str='$'$cmd;
        CMD="$CMD --tab --title $cmd -e \"$cmd_str\""
    done                                                                                                                                                      

eval $CMD

exit

ouath2.0 basics

import

import可以有一下几种形式：

• import A （推荐都使用这种方式)

        将A导入到当前的namespace
        变种可以时 import A.B.C.D 如果是这种情况 ABC必须是Package 而D只能是一个模块 或者时一个Pakcage

• from A import B

        将B导入到当前的namespace 当改变B时 对B作出的修改不会影响到A.B

• X = __import__('X') (运行时才知道X的名称)

• from A import *

        将A中所有的public name引入到当前的namespace public name在这里指的是name明称不以_(下划线)开头的那些name


import vs loading

一个模块不管被imoprt多少次 它只会被load一次 如果有执行代码在这个模块里面 那么只有第一次被加载的时候会运行 之后import则不会去运行未包装的执行代码



What does python do to import a Module?
1, check sys.modules to see if module is already imported, if that's the case, python will use the existing module object as is.
2, otherwise, create a new , empty module object
3, insert that module in sys.modules
4, Load the module code object
5, Execute the module code object in the new module's namespace. All variables assigned by the code will be available via the module object.

Importing * From a Package

The only solution is for the package author to provide an explicit index of the package. The import statement uses the following convention: if a package’s __init__.py code defines a list named __all__, it is taken to be the list of module names that should be imported when from package import * is encountered. It is up to the package author to keep this list up-to-date when a new version of the package is released. Package authors may also decide not to support it, if they don’t see a use for importing * from their package.


If __all__ is not defined, the statement from sound.effects import * does not import all submodules from the package sound.effects into the current namespace; it only ensures that the package sound.effects has been imported (possibly running any initialization code in __init__.py) and then imports whatever names are defined in the package. This includes any names defined (and submodules explicitly loaded) by __init__.py. It also includes any submodules of the package that were explicitly loaded by previous import statements. Consider this code:

import sound.effects.echo
import sound.effects.surround
from sound.effects import *

In this example, the echo and surround modules are imported in the current namespace because they are defined in the sound.effects package when the from...import statement is executed. (This also works when __all__ is defined.)

upgrate bugzilla to 4.2 from 3.6

Today I decided to upgrade my local bugzilla from bz3.6 to bz 4.2, and got lots of errors and headaches for sure. The following are the bugs:

1, xmlrpc support are disabled, this is caused by failed to load required modules, to fix this is very easy, i just ran install all modules, may you are interesting with how i found this, we are using bugzilla xmlrpc for updating our data, after failed several times, and double checked our code, we thought it's bugzilla installation issues.

2, DB schema didn't match, first i delete record in bz_schema table, then ran checksetup.pl, then some errors were emerging, basically they were foreign key constrain issues, so I deleted those foreign keys from related tables, believe me, that's a huge task

3, there were some invalid data in db already, so if that's true, correct those are delete them

opera interview

General:
1, Regular expression
2, how to retrieve the main body of a html page
3, write a B(tree, *, +)
4, how to implement a long HTTP connection if proxy doesn't support connection header


PY related:
1, import details
2, yield details
3, meta programming


Mysql related:
1, mysql index

some key characters about REST

Two important question for classifying web services:
1, The scoping information is kept in the URI. This is the principle of addressability
2, The method information is kept in the HTTP method, CRUD


Restful web service should be stateless, that's every request should contain the required information to make this request. The violation for this is using cookie to maintain the state. E.g. goolge search, i can bookmark the results page 10 of keywords jellyfish as q?search=jellyfish&page=10, server side doesn't need to maintain the page index information for the request, the request contains all the information needed for server to response it.


I'm reading the Restful Web Services' chapter4, and this stateless description makes me double thinking about our Mobile APP's Backend, I'm now using session cookie to authenticate users when he issues a request after logged in, such as updating profile. We are still heavily relying on the cookie based authentication procedure, this is not good to name it as Restful.


One difference between HTTP PUT and POST is that, with PUT the client should know what URI for the new created resource should be, and POST are more likely as operation append. Sometime, we may overload HTTP POST method as a process request to a resource, this method sometimes reduce the complexity(It's RPC style web service, that's  method information creep into other place instead of uniform HTTP Method). 


More words for overload POST, actually, if we stick with PUT to get (Read) information, and POST for modifying, deleting or creating a resource, it's still Restful.


ROA:
for concepts:
1, Resource
2, Their name(URI)
3, Their representation
4, THe links between them


for properties:
1, Addressability
2, statelessness
3, Connectedness
4, A uniform interface

setup a local envrionment for openshift wsgi app

We do want a local development environment for debugging, etc. As my previous posts, we are using Python2.6 Django WSGI as backend for our mobile app, so, it's pretty easy to setup a local environment, actually, it's just a WSGI deployment.

But, since openshift gear using many environment variables, so the key steps here are copy those env vars to your local box, and export them. The another thing that matters a lot is Database setup, with help of Django Framework, i just need to create a database with the same name as it is in openshift, and then run syncdb.

The issue bit me was Selinux settings, so you may need pay some attentions to it. If you have an admin beside you, drop these setup stuff to him, :).


http://code.google.com/p/modwsgi/wiki/WhereToGetHelp?tm=6
https://docs.djangoproject.com/en/1.4/howto/deployment/wsgi/