Monster Oasis

覺得累就是進步的開始!

阿毛介紹的: http://mobilepress.co.za/

裝好後它會偵測 user 的 user agent 若是 mobile 就會把頁面換成 ‘手機’ 版.

Share on Facebook

http://amos-lee.blogspot.com/2010/05/10.html

http://www.mockflow.com/

http://www.balsamiq.com/builds/mockups-web-demo/?q=demos/mockups/Mockups.html

Share on Facebook

這隻程式會展現一個地圖, 並以目前定位的座標為中心點, 及一個按鈕,按下按鈕會把座標及UDID傳送到 server , 由 server 端的程式記錄下來, 並且 server 端亂數送出一個水果名回傳給 iPhone client 端, iPhone client 端再把這水果名 show 在 iPhone screen上.

底下是片斷程式碼:

FirstViewController.h :

#import 
#import

#import 

@interface FirstViewController : UIViewController  {
  IBOutlet MKMapView *mapView;
  CLLocationManager *locationManager;
  CLLocation *currentLocation;

}

- (IBAction) updateLocation;

@end

FirstViewController.m :

- (void)viewDidLoad {
  [super viewDidLoad];

  if (locationManager==nil) {
    locationManager = [[CLLocationManager alloc] init];
    locationManager.delegate = self;
  }

  [locationManager startUpdatingLocation];

  [mapView setMapType:MKMapTypeStandard];
}

- (void)locationManager:(CLLocationManager *)manager
  didUpdateToLocation:(CLLocation *)newLocation
       fromLocation:(CLLocation *)oldLocation {

  NSLog(@"Location : %.6f , %.6f", newLocation.coordinate.latitude , newLocation.coordinate.longitude );

  MKCoordinateRegion region = [mapView region];

  region.center = newLocation.coordinate;

  MKCoordinateSpan span;
  span.latitudeDelta = 0.01;
  span.longitudeDelta = 0.01;
  region.span = span;
  [mapView setRegion:region animated:TRUE];

  //
  if ( currentLocation != nil) {
    [currentLocation release];
    currentLocation = nil;
  }
  currentLocation = [newLocation copy];

}

- (IBAction) updateLocation {

  if(currentLocation==nil)
    return;

  UIDevice *device=[[UIDevice alloc] init];

  NSString *URLString=[[NSString alloc] initWithFormat:@"http://z.monster.tw/save_location.php?lat=%.6f&lng=%.6f&id=%@"
             ,currentLocation.coordinate.latitude
             ,currentLocation.coordinate.longitude
             ,device.uniqueIdentifier];

  [device release];

  NSLog(@"%@",URLString);

  // Send Request
  NSURLRequest *request=[NSURLRequest requestWithURL:[NSURL URLWithString:[URLString stringByAddingPercentEscapesUsingEncoding:NSUTF8StringEncoding]]
                       cachePolicy:NSURLRequestReloadIgnoringCacheData
                     timeoutInterval:20.0]; 

  NSData *returnData = [NSURLConnection sendSynchronousRequest:request returningResponse:nil error:nil];
  NSString *returnString = [[NSString alloc] initWithData:returnData encoding:NSUTF8StringEncoding];

  NSLog(@"%@",returnString);  

  // Display AlertView
  UIAlertView *alert = [[UIAlertView alloc] initWithTitle:returnString message:@"Thanks!"
                           delegate:self cancelButtonTitle:@"Close" otherButtonTitles: nil];
  [alert show];
  [alert release];  

  [returnString release];
}

Share on Facebook

Share on Facebook

Oracle doc PDF URL : http://dn.monster.tw/my/docs/oracle/MAA_10gR2_Streams_Configuration.pdf

Oracle® Streams Advanced Queuing User’s Guide and Reference
10g Release 2 (10.2) – http://download.oracle.com/docs/cd/B19306_01/server.102/b14257/toc.htm

sample memo: http://www.monster.com.tw/archives/2565

Oracle Maximum Availability Architecture – Overview – http://www.oracle.com/technology/deploy/availability/htdocs/maaoverview.html

Share on Facebook

在 Database 那格用這種格式: IP_ADDRESS/SERVICE_NAME

Share on Facebook

From URL : http://anyall.org/blog/2009/04/performance-comparison-keyvalue-stores-for-language-model-counts/

memcache 的測試值跟我測得的數據接近(我用 100K 的 data測)

為了避免該資料不見, 搜藏/節錄一下重點:

More details on the options:

• Python dictionary: defaultdict(int) is the simplest and most obvious implementation. It’s the baseline and the fastest. This is the best option for many types of experimental NLP code, since it can just be serialized to disk for use later. Only if you want many processes to build it concurrently and incrementally, or want many processes to access the model but not have to hold it in their own process space, do the other options start becoming relevant.
• BerkeleyDB: a well-known key/value store that I’ve used for a while. Unfortunately it’s been removed from the Python distribution, and there are often version hell issues every time I see people try to use it. (Every Linux/Unix seems to carry a different version, and they’re all not compatible with each other.)
• Tokyo Cabinet is a newish key/value store that has some impressive benchmarks. I just learned about it from Leonard’s post, and I also found it to be excellent. If Cabinet keeps being so awesome, I might never use BerkeleyDB again. (Though installation issues are worse than BerkeleyDB since it’s new enough to not be a common package; e.g. I found it on MacPorts but not Debian.)
• Memcached: The most standard in-memory key/value for use over sockets. Usually used for caching results from database queries for web applications — because in-memory caching is way faster than hitting disk on a database query. All data in a Memcached disappears if you turn it off. Clients talk to it via a plaintext protocol over sockets.
  • The fact it was slower than the dictionary or BDB or Cabinet means that the communication overhead was high. The nice thing about Memcached for keeping running counts like this is that it should distribute well: have lots of different processes/machines processing data and asking a central Memcached cluster to increment counters. It might be a little unfair to compare Memcached performance to BerkeleyDB or Cabinet, since it’s designed for the situation of communicating with many clients at once. It’s usually considered a win if Memcached is faster than a parallel-ly accessed RDBMS, which is very much the case.
  • I wonder how this architecture would compare to a Hadoop/HDFS/MapReduce for batch-job term counting performance. Jimmy Lin & other Maryland folks wrote an interesting report (2009) about using Memcached during a Hadoop job in a similar way for, among other things, this same language model use case. In general, lots of machine learning algorithms really don’t parallelize very well in the MapReduce architecture; parameter updates in Gibbs sampling, EM, and any online algorithm (e.g. SGD) are other examples. (An earlier paper on a better-than-mapreduce approach for EM parameters: Jason Wolfe et al. 2008; slides, paper.) A Memcached-like system could be a component of more client-server-ish parallel processing models for these use cases.
  • Note of warning: there are actually 3 different Python libraries to talk to Memcached: (1) memcache.py aka python-memcached; (2) cmemcache which wraps the C library libmemcache, and (3) cmemcached.pyx aka python-libmemcached write wraps a different C library, libmemcached. For each one, the X in import X correlates quite poorly to the project’s name. Bleah. Option #3 seems newest, or at least has the best-maintained websites, so I used that.
• MemcacheDB is a BerkeleyDB-backed, Memcached-protocol server. Initially I had hoped it was just Memcached over BDB. Unfortunately this is clearly not the case. Its name is so similar yet its effectiveness is so different than Memcached! As Leonard points out, there are lots of half-assed solutions out there. It’s easy for anyone to create a system that works well for their needs, but it’s harder to make something more general.
• Tokyo Tyrant is a server implemented on top of Cabinet that implements a similar key/value API except over sockets. It’s incredibly flexible; it was very easy to run it in several different configurations. The first one is to use an in-memory data store, and communicate using the memcached protocol. This is, of course, *exactly* comparable to Memcached — behaviorally indistinguishable! — and it does worse. The second option is to do that, except switch to an on-disk data store. It’s pretty ridiculous that that’s still the same speed — communication overhead is completely dominating the time. Fortunately, Tyrant comes with a binary protocol. Using that substantially improves performance past Memcached levels, though less than a direct in-process database. Yes, communication across processes incurs overhead. No news here, I guess.

I can’t say this evaluation tells us too much about the server systems, since it’s all for a single process, which really isn’t their use case. It is interesting, however, to see that memcached’s plaintext protocol causing a big performance hit compared to a binary one. There’s a lot of talk and perhaps code for a binary memcached protocol, but I couldn’t find any docs suggesting whether it currently works. Tyrant seems to work great.

The biggest takeaway is that Tokyo Cabinet is awesome. It has very complete English language documentation — something sadly lacking in many otherwise fine Japanese open-source projects — and appears to be highly performant and very flexible. This presentation by its author (Mikio Hirabayashi) shows a pretty impressive array of different things the suite of packages can do. At the very least, I’ll probably abandon BerkeleyDB if Cabinet keeps working so well; and hopefully, distribution and remote access will be easy to add via Tyrant.

Final note: it’s interesting how many of these new low-latency datastore systems come out of open-sourced projects from social network companies. Tokyo Cabinet/Tyrant is from Mixi, a large Japanese social networking site; Cassandra is from Facebook; and Voldemort is from LinkedIn. (Hadoop HDFS, approximately from Yahoo, is another open-source non-rdbms distributed datastore, though it’s not really low-latency enough to be comparable.) Then there are lots of commercial low-latency and distributed systems for data warehousing (oracle greenplum vertica aster…) but all these large web companies seem happy open-sourcing their infrastructure. This is great for me, but sucks to be a database company.

Share on Facebook

license page : http://172.30.0.49:1158/em/console/license

(more…)

Share on Facebook

Share on Facebook

Share on Facebook