Win8 New UI Philosophy

Leave a comment

http://channel9.msdn.com/Events/BUILD/BUILD2011/BPS-1004

Is it still windows, which we are familiar with? Change is the only constant thing in the varying world.

Impossible is nothing, Yeah, Microsoft learn a lot from Apple, not just learn, but also a kind of re-creation. Wooo… That’s why I keep learning the MacOSX, the new world.

Let’s rock out of bottle.

Disable FQDN for Local Server

Leave a comment

  • If your ABAP PI/Netweaver System hasn’t been maintained into Full qualified Domain Name[FQDN], in bsp application, you will receive the following error, during loading BSP.

The following error text was processed in system : The URL contains no complete domain specification (cnst50059090 instead of cnst50059090.<domain>.<ext>).

  • How-to solve, check up with Notes 1088717, 1124553 and 517484

=> Modification with CX_FQND::CHECK

 METHOD check.

  DATA: lv_host    TYPE string,
        lv_port    TYPE string.  “#EC NEEDED

  lv_host = request->get_header_field( name = ‘host’ ).
  IF lv_host NA ‘.’ OR lv_host CO ‘0123456789.:’.
*{   INSERT         PI6K900003                                        1
  IF lv_host EQ ‘<your host-cnst50059090>:<your port-50200>’ . ” for localhost implementation
    exit. “just quit dummy FQDN check-up
  ENDIF.
*}   INSERT
    IF NOT lv_host CS ‘localhost’.
      SPLIT lv_host AT ‘:’ INTO lv_host lv_port.
      RAISE EXCEPTION TYPE cx_fqdn
        EXPORTING host   = lv_host
                  domain = ‘.<domain>.<ext>’. “#EC NOTEXT recommend security group
    ENDIF.
  ENDIF.

ENDMETHOD.

=> String operation : http://help.sap.com/saphelp_nw04/helpdata/en/fc/eb3516358411d1829f0000e829fbfe/frameset.htm

http://indradewaji.wordpress.com/2008/03/12/comparation-between-cs-and-ca-on-abap/

iPhone iPad In Action

Leave a comment

Last Friday, I bought one book called <iPhone and iPad in Action>. Just taking a glance at it, with a full-covered topic for iOS SDK.

In order to find the original version of this book, search in CSDN, and attached into my SkyDrive,

Shared with guys, who are interested with iOS development, iPhone_and_iPad_in_Action [I called it iOS in action].

Honestly speaking, it’s just a manual for taking action, regarding system perspective and API in deep, I think programming guideline and <MacOSX_Internals_A_Systems_Approach>, better!!!

Absolutely, know how-to run, I prefer to know how-is-the-behind. 🙂 Hope you like it.

Cocoa – Using Collection Classes Safely in Multithreaded Applications

Leave a comment

The passage is from apple official programming guideline series – Synchronization of Mufti-Thread Programming.

However, based on some reason of maintenance, Apple move the original Tech Note  TN2059: “Using Collection Classes Safely in Multithreaded Applications.” and replace with Thread Safety Summary. And fortunately, it’s some reference link on the internet, listed as follow:

Now I keep this summary in the next section,  which is the same as the original post of Apple etc.

Technical Note TN2059:  Using Collection Classes Safely in Multithreaded Applications – September 10th, 2002

this technote describes some problems that can occur when using mutable collection classes (arrays, dictionaries, and sets) in multithreaded Cocoa applications, and describes some approaches to solving these problems, including several implementations.

Multithreaded Core Foundation applications may involve the same concerns, since Cocoa and Core Foundation classes are “toll-free bridged.” This note does not address Core Foundation collections explicitly, but most of the principles discussed here apply to Core Foundation as well. For more information on Core Foundation, see Overview of Core Foundation in the References section.

This note doesn’t cover general issues in threading. For an introduction to those, see the Reference section for a list of readings.

Problems with shared data in threaded applications

Whenever two threads share data, they must synchronize access to that data to avoid bugs that can arise when they both work with the data at the same time. In most cases, a thread synchronizes by using a lock to prevent other threads from entering the same code at the same time. For example:

NSLock *statisticsLock; // assume this object exists
int statistics;
...
[statisticsLock lock]; // make sure no two threads
statistics += 1; // update 'statistics' at the same time
[statisticsLock unlock]; // release the lock

The use of statisticsLock above ensures that only one thread executes the “+=” operation at a time. Without this, two threads might try to update the same location at the same time, losing one thread’s contribution to the statistics.

Problems with collection classes in threaded applications

When your code works with a mutable dictionary or array, locking the object only during the time the code works with its contents may not prevent all bugs.To see why, consider this code (all the code shown here uses dictionaries, but the same concerns apply to arrays and sets):

NSLock *dictionaryLock; // assume this object exists
NSDictionary *aDictionary; // assume this object exists
NSString *theName;
...
[dictionaryLock lock];
theName = [aDictionary objectForKey: @"name"];
[dictionaryLock unlock];
NSLog (@"the name is '%@'", theName)

This code protects access to the mutable dictionary; however, even if all other parts of the program use the same lock to avoid concurrent use of the dictionary, the code above can fail. Here’s why:
When a mutable collection removes an object, it sends the object a release message. Keeping this in mind, consider the following sequence:

  1. aDictionary contains the name @"Pat" for the key @"name", with a retain count of 1
  2. thread “A” executes the code above: it locks, sends objectForKey:, and unlocks — the variable theName now has a value of @"Pat", with a retain count of 1
  3. thread “B” now locks the lock and updates the dictionary with:
    [aDictionary setObject: @"Sandy"  forKey: @"name"];

    The dictionary sends release to the old value for this key, the string @”Pat”. Since the retain count was 1 to start, this release drops the count to zero, and the string @"Pat" gets deallocated.

  4. thread “A” now tries to use its variable theName in the NSLog(...) invocation, but the variable refers to the string @"Pat" which has been deallocated, leading to a crash or other random results. The above sequence typifies the subtlety of using collection classes in threaded applications, but is not the only concern you need to keep in mind. Let’s briefly consider a second example. Suppose your code adds an object to a dictionary. Since the dictionary retains its values, the code releases the object after adding it. The code looks like this:
    NSString *theName; // assume this exists
     ...
    [aDictionaryLock lock];
    [aDictionary setObject: theName forKey: KEY];
    [theName release]; // since dictionary retains it, we don't need to
    [aDictionaryLock unlock];
    
    NSLog (@"the name is '%@'", theName);

    The risk here resembles the risk in the previous code: Once the code unlocks, another thread may change the dictionary, releasing the value. Again, theName refers to a value that can get deallocated in the short period between unlocking and trying to use it in the NSLog(...).

    The same concerns apply to objects stored in arrays and sets, not just dictionaries: If thread B removes from an array or set an object to which thread A holds a pointer, that object may not remain valid during the scope in which thread A plans to use it.

To sum up:

  • When multiple threads share a collection object, they need to synchronize access to that collection.
  • Collection objects send release to objects as they remove (or replace) them.
  • After one thread adds an object to a collection, or gets it from a collection, a second thread may cause that object to become invalid.
  • Thus, when multiple threads share a collection object, they also share all values contained in the object, even when one thread holds a reference to the value.

Example 1: A faulty application

The following source code illustrates the risks of sharing collections across threads. Even though it uses a lock to prevent simultaneous access to a mutable dictionary, it still crashes consistently.

#import <Foundation/Foundation.h>

static NSMutableDictionary    *aDictionary = nil;
static NSLock                *aDictionaryLock = nil;
@implementation NSMutableDictionary (Churning)
#define KEY        @"key"

- (void) churnContents;
{
    unsigned long    i;
    for (i = 0; ; i++)
    {
        NSAutoreleasePool    *pool;
        pool = [[NSAutoreleasePool alloc] init];
        [aDictionaryLock lock];
        [self setObject: [NSString stringWithFormat: @"%d", i]  forKey: KEY];
        [aDictionaryLock unlock];
        [pool release];
    }
}
@end

#define COUNT    10000
static void doGets (void)
{
    long    i;
    for (i = 0; i < COUNT; i++)
    {
        NSObject    *anObject;
        //    Get the dictionary's value, and then try to message the value.
        [aDictionaryLock lock];
        anObject = [aDictionary objectForKey: KEY];
        [aDictionaryLock unlock];
        [anObject description];
    }
}

static void doSets (void)
{
    long    i;
    for (i = 0; i < COUNT; i++)
    {
        NSObject    *anObject;
        anObject = [[NSObject alloc] init];
        [aDictionaryLock lock];
        [aDictionary setObject: anObject  forKey: KEY];
        [anObject release];
        [aDictionaryLock unlock];
        [anObject description];
    }
}

int main ()
{
    SEL        threadSelector;
    [[NSAutoreleasePool alloc] init];
    threadSelector = @selector(churnContents);
    aDictionary = [NSMutableDictionary dictionary];
    aDictionaryLock = [[NSLock alloc] init];
    //    Start the dictionary "churning", repeatedly replacing the sole value with a new one under the same key.
    [NSThread detachNewThreadSelector: threadSelector
                toTarget: aDictionary
                withObject: nil];

#if 1 // because this crashes, you can turn it off to show that doSets() also crashes
    doGets();
#endif
    doSets();

    return 0;
}
Listing 1. main1.m (available in the Downloads section)

Bugs in multithreaded applications may appear only sporadically. So that you don’t have to run it repeatedly to see the problem, this application spawns a thread that sends the churnContents message to a mutable dictionary. This method repeatedly replaces one value in the dictionary with a sequence of objects.

It includes two functions doGets() and doSets(), either of which will crash the application — you can comment out the call to the first function to see the other one crash. The doGets() function repeatedly gets a value from the dictionary and sends it a description message, eventually causing a crash.

The doSets() function puts a value into a dictionary, releases the value on the assumption that the dictionary will retain it, and similarly risks a crash by sending description to the object. (The choice of description has no significance; any method would do the same thing.)

Safeguarding shared objects

How can code safely work with objects it gets from a collection or stores in a collection? One approach is to send the object a retain message and later — when you’re done using it — send it a balancing release message. The net effect of these two actions leaves the object unchanged, but during the interval between retaining and releasing your code lays claim to the object, preventing it from getting deallocated by other threads.

The problem with this approach is that you have to remember to send the release message, or else the object may never get deallocated, and “leak.” Instead of waiting until you’re done and sendingrelease, you can immediately send it an autorelease message, which guarantees that the object will get released when the current autorelease pool gets deallocated.

Think of retain-and-release as asking someone to lend you a dollar and you promising to pay them back. Think of retain-and-autorelease as asking someone to lend you a dollar and them promising to make you pay it back. The latter approach is more conservative, in that it ensures your books stay balanced. (Keep in mind that autoreleasing takes more time and space than releasing, though.)

To make the code above safe, you need to add one line, noted in boldface below, to the code given before Example 1:

NSLock *dictionaryLock; // assume this object exists
NSDictionary *aDictionary; // assume this object exists

NSString *theName;
    ...
[dictionaryLock lock];
theName = [aDictionary objectForKey: @"name"];
[[theName retain] autorelease]; // keep object around for now
[dictionaryLock unlock];

NSLog (@"the name is '%@'", theName);

The combined retain and autorelease may look like it has no effect, but the retain takes effect immediately, while the autorelease undoes the retain later. In the end, the two messages cancel out, but the retain keeps the object from getting deallocated while your code is using it.

Example 2: A corrected application

#import <Foundation/Foundation.h>

static NSMutableDictionary    *aDictionary = nil;
static NSLock                *aDictionaryLock = nil;

@implementation NSMutableDictionary (Churning)
#define KEY        @"key"

- (void) churnContents;
{
    unsigned long    i;
    for (i = 0; ; i++)
    {
        NSAutoreleasePool    *pool;
        pool = [[NSAutoreleasePool alloc] init];
        [aDictionaryLock lock];
        [self setObject: [NSString stringWithFormat: @"%d", i]  forKey: KEY];
        [aDictionaryLock unlock];
        [pool release];
    }
}

@end
#define COUNT    10000
static void doGets (void)
{
    long    i;
    for (i = 0; i < COUNT; i++)
    {
        NSObject    *anObject;
        //    Get the dictionary's value, and then try to message the value.
        [aDictionaryLock lock];
        anObject = [aDictionary objectForKey: KEY];
        [[anObject retain] autorelease];
        [aDictionaryLock unlock];
        [anObject description];
    }
}

static void doSets (void)
{
    long    i;
    for (i = 0; i < COUNT; i++)
    {
        NSObject    *anObject;
        anObject = [[NSObject alloc] init];
        [aDictionaryLock lock];
        [aDictionary setObject: anObject  forKey: KEY];
        [anObject autorelease];
        [aDictionaryLock unlock];
        [anObject description];
    }
}

int main ()
{
    SEL        threadSelector;
    [[NSAutoreleasePool alloc] init];
    threadSelector = @selector(churnContents);
    aDictionary = [NSMutableDictionary dictionary];
    aDictionaryLock = [[NSLock alloc] init];
    //    Start the dictionary "churning", repeatedly replacing the sole value with a new one under the same key.
    [NSThread detachNewThreadSelector: threadSelector
                toTarget: aDictionary
                withObject: nil];

    doGets();
    doSets();

    return 0;
}
Listing 2. main2.m (available in the Downloads section) The above source code changes only a couple of lines from the previous example, but no longer crashes.

In this version the doGets() and doSets() functions add or change code to protect themselves. ThedoGets() function temporarily retains the object it gets from the dictionary, then balances that retention with an autorelease. The “sets” function changes its release to an autorelease.

Notice that the thread that “churns” the dictionary has the same code as before. It doesn’t retrieve an object from the dictionary, and it doesn’t use the value it stores in the dictionary.

Why not put the burden on this thread to safeguard the data? Why not have it retain-and-autorelease the object it’s about to remove? The answer lies in the fact that each thread has its own autorelease pool. If the “churning” thread sends retain-then-autorelease to the object, that autorelease will take effect when the churning thread frees its autorelease pool — that might happen while another thread is still using it.

To sum up:

  • Retain-and-release works to temporarily prevent an object from getting deallocated, but you must make sure that release gets sent.
  • Retain-and-autorelease works better, because the autorelease pool remembers to send therelease for you.
  • The thread that wants to protect the object must do the autorelease; other threads might wind up releasing the object at the wrong time.

Example 3: A category to simplify safety

The above example works, but each piece of code that uses the dictionary has to perform the same steps to use it safely. To make it easy for developers to write safe code, you can encapsulate the functionality for them. One way to do this is to add a category to NSMutableDictionary, adding methods that do most of the work for you.

The three methods are:

- (id) threadSafeObjectForKey: (id) aKey  usingLock: (NSLock *) aLock;
- (void) threadSafeRemoveObjectForKey: (id) aKey  usingLock: (NSLock *) aLock;
- (void) threadSafeSetObject: (id) anObject
            forKey: (id) aKey  usingLock: (NSLock *) aLock;

For example, if your old code was:

[aDictionaryLock lock];
anObject = [aDictionary objectForKey: KEY];
[[anObject retain] autorelease];
[aDictionaryLock unlock];

After adding the category, you can change this to one statement:

anObject = [aDictionary threadSafeObjectForKey: KEY
        usingLock: aDictionaryLock];

The following source code includes the interface declaration and the implementation for this category, along with the revised application code. (You’ll usually put a category’s interface in its own .h file and implementation in its own .m file. This example puts everything in a single file for conciseness.)

#import <Foundation/Foundation.h>

////////////////////////////////////////////////////////////////
////    NSMutableDictionary CATEGORY FOR THREAD-SAFETY
////////////////////////////////////////////////////////////////

@interface NSMutableDictionary (ThreadSafety)

- (id) threadSafeObjectForKey: (id) aKey
    usingLock: (NSLock *) aLock;

- (void) threadSafeRemoveObjectForKey: (id) aKey
    usingLock: (NSLock *) aLock;

- (void) threadSafeSetObject: (id) anObject
    forKey: (id) aKey
    usingLock: (NSLock *) aLock;

@end

@implementation NSMutableDictionary (ThreadSafety)

- (id) threadSafeObjectForKey: (id) aKey
    usingLock: (NSLock *) aLock;
{
    id    result;
    [aLock lock];
    result = [self objectForKey: aKey];
    [[result retain] autorelease];
    [aLock unlock];
    return result;
}

- (void) threadSafeRemoveObjectForKey: (id) aKey
    usingLock: (NSLock *) aLock;
{
    [aLock lock];
    [self removeObjectForKey: aKey];
    [aLock unlock];
}

- (void) threadSafeSetObject: (id) anObject
    forKey: (id) aKey
    usingLock: (NSLock *) aLock;
{
    [aLock lock];
    [[anObject retain] autorelease];
    [self setObject: anObject  forKey: aKey];
    [aLock unlock];
}

@end

////////////////////////////////////////////////////////////////
////    TEST PROGRAM
////////////////////////////////////////////////////////////////

static NSMutableDictionary    *aDictionary = nil;
static NSLock                *aDictionaryLock = nil;

@implementation NSMutableDictionary (Churning)

#define KEY        @"key"

- (void) churnContents;
{
    unsigned long    i;
    for (i = 0; ; i++)
    {
        NSAutoreleasePool    *pool;
        pool = [[NSAutoreleasePool alloc] init];
        [self threadSafeSetObject: [NSString stringWithFormat: @"%d", i]
            forKey: KEY  usingLock: aDictionaryLock];
        [pool release];
    }
}

@end

#define COUNT    10000
static void doGets (void)
{
    long    i;
    for (i = 0; i < COUNT; i++)
        //    Get the dictionary's value, and then try to message the value.
        [[aDictionary threadSafeObjectForKey: KEY
        usingLock: aDictionaryLock] description];
}

static void doSets (void)
{
    long    i;
    for (i = 0; i < COUNT; i++)    {
        NSObject    *anObject;
        anObject = [[NSObject alloc] init];
        [aDictionary threadSafeSetObject: anObject
            forKey: KEY
            usingLock: aDictionaryLock];
        [anObject release];
        [anObject description];
    }
}

int main ()
{
    SEL        threadSelector;
    [[NSAutoreleasePool alloc] init];
    threadSelector = @selector(churnContents);
    aDictionary = [NSMutableDictionary dictionary];
    aDictionaryLock = [[NSLock alloc] init];
    //    Start the dictionary "churning", repeatedly replacing the sole value with a new one under the same key.
    [NSThread detachNewThreadSelector: threadSelector
                toTarget: aDictionary
                withObject: nil];

    doGets();
    doSets();

    return 0;
}
Listing 3. main3.m (available in the Downloads section)

These methods require you to specify the lock that controls the dictionary. You’d usually choose to use one NSLock instance for each dictionary.

A variation on the above approach is to have the category supply simpler methods, such as threadSafeObjectForKey:, which supply the lock themselves. This technique has problems because either it uses a single lock for all dictionaries or it has a data structure mapping each dictionary to its respective lock. The data structure will need its own lock, so either way a single lock can become a bottleneck for all threads.

To easily associate each dictionary with a lock, you can subclass the dictionary class. The next example describes in detail how to do this.

Example 4: A subclass of NSMutableDictionary

Instead of adding methods like threadSafeObjectForKey: in a category, and requiring all developers working on an application to use that method, another technique is to create a subclass of NSMutableDictionary, overriding methods like objectForKey: and replacing them with thread-safe implementations.

NSMutableDictionary is part of the NSDictionary class cluster. Subclassing within a class cluster is somewhat complicated, and you shouldn’t do it without good reason. For an introduction to both class clusters and ways to subclass them, see the primer on Class Clusters.

The implementation below uses the “composite object” technique described in the class cluster documentation. It defines an object which includes both a real mutable dictionary and a lock. It also implements each of the “primitive” methods in NSMutableDictionary.

#import <Foundation/Foundation.h>

////////////////////////////////////////////////////////////////
////    NSMutableDictionary SUBCLASS
////////////////////////////////////////////////////////////////

@interface ThreadSafeMutableDictionary : NSMutableDictionary
{
    NSMutableDictionary    *realDictionary;
    NSLock                *lock;
}

@end
@implementation ThreadSafeMutableDictionary : NSMutableDictionary
//  Primitive methods in NSDictionary
- (unsigned) count;
{
    //  I believe we don't need to lock for this.
    return [realDictionary count];
}

- (NSEnumerator *) keyEnumerator;
{
    NSEnumerator    *result;
    //    It's not clear whether we need to lock for this operation,
    //    but let's be careful.
    [lock lock];
    result = [realDictionary keyEnumerator];
    [lock unlock];
    return result;
}

- (id) objectForKey: (id) aKey;
{
    id    result;
    [lock lock];
    result = [realDictionary objectForKey: aKey];
    //    Before unlocking, make sure this object doesn't get
    //  deallocated until the autorelease pool is released.
    [[result retain] autorelease];
    [lock unlock];
    return result;
}

//  Primitive methods in NSMutableDictionary
- (void) removeObjectForKey: (id) aKey;
{
    //    While this method itself may not run into trouble, respect the
    //  lock so we don't trip up other threads.
    [lock lock];
    [realDictionary removeObjectForKey: aKey];
    [lock unlock];
}

- (void) setObject: (id) anObject forKey: (id) aKey;
{
    //    Putting the object into the dictionary puts it at risk for being
    //  released by another thread, so protect it.
    [[anObject retain] autorelease];
    //    Respect the lock, because setting the object may release
    // its predecessor.
    [lock lock];
    [realDictionary setObject: anObject  forKey: aKey];
    [lock unlock];
}

//    This isn't labeled as primitive, but let's optimize it.
- (id) initWithCapacity: (unsigned) numItems;
{
    self = [self init];
    if (self != nil)
        realDictionary = [[NSMutableDictionary alloc] initWithCapacity: numItems];
    return self;
}

//    Overrides from NSObject
- (id) init;
{
    self = [super init];
    if (self != nil)
        lock = [[NSLock alloc] init];

    return self;
}

- (void) dealloc;
{
    [realDictionary release];
    [lock release];

    [super dealloc];
}

@end

////////////////////////////////////////////////////////////////
////    TEST PROGRAM
////////////////////////////////////////////////////////////////

static NSMutableDictionary    *aDictionary = nil;

@implementation NSMutableDictionary (Churning)

#define KEY        @"key"

- (void) churnContents;
{
    unsigned long    i;
    for (i = 0; ; i++)
    {
        NSAutoreleasePool    *pool;
        pool = [[NSAutoreleasePool alloc] init];
        [self setObject: [NSString stringWithFormat: @"%d", i]  forKey: KEY];
        [pool release];
    }
}

@end

#define COUNT    10000
static void doGets (void)
{
    long    i;
    for (i = 0; i < COUNT; i++)
        //    Get the dictionary's value, and then try to message the value.
        [[aDictionary objectForKey: KEY] description];
}

static void doSets (void)
{
    long    i;

    for (i = 0; i < COUNT; i++)
    {
        NSObject    *anObject;
        anObject = [[NSObject alloc] init];
        [aDictionary setObject: anObject  forKey: KEY];
        [anObject release];
        [anObject description];
    }
}

int main ()
{
    SEL        threadSelector;
    [[NSAutoreleasePool alloc] init];
    threadSelector = @selector(churnContents);
    aDictionary = [ThreadSafeMutableDictionary dictionary];
    //    Start the dictionary "churning", repeatedly replacing the
    //    sole value with a new one under the same key.
    [NSThread detachNewThreadSelector: threadSelector
                toTarget: aDictionary
                withObject: nil];

    doGets();
    doSets();

    return 0;
}
Listing 4. main4.m (available in the Downloads section)

A subclass like this entails several concerns:

    • the time to perform locking may hurt performance
    • on top of that, any subclass may not be as fast as Apple’s “concrete” implementation, which is typically highly optimized
    • each object is implemented with two underlying objects, using more memory
    • you need to make sure that the dictionary is instantiated from the subclass — notice that in this final version, the dictionary gets created with this code:
aDictionary = [ThreadSafeMutableDictionary dictionary];

To sum up:

  • Categories provide a simple way to encapsulate new functionality on existing classes.
  • Subclassing provides another way to add functionality, but by overriding methods instead of adding them.
  • Subclassing within a class cluster requires special attention.

随笔

Leave a comment

很久没有心情来写些与工作无关的文字了,可能这一年确实太忙了,人来人往,更多的时间放在了为以后打基础了。有些事情是要做到前面的,水到渠成。

今晚难得的可以把自己放空,听听陌生的电波,这种抽离的感觉很舒服。太忙了,心也就死了。。。看看大街上来来往往的人群,开着车不愿等待的人群,20岁出头的人恨不得一夜成为首富。

《源代码》里面的主人翁,俯拾皆是

中文的博大就在,简单的几个词就很容纳一切,“舍得”。什么都想要,什么都得不得到;什么都想急切的得到,什么都无法急切的得到。

老子讲:“欲有为者,必先无为”。无为不是无所作为,而是不在不适当的时机做不适当的事,讲究作势,而不简单做事。就如,将处于悬崖之颠的巨石,不动而威,千钧之势。

最近读了,中国人为steve,jobs做的一本自传,很难想象这样的一个人居然笃信禅宗。

禅的本意,就是随性而为,本真自我,只是很少有人真正做到而已。当有人做到极致的时候,往往更容易出众,更容易成功。欲出世者,反而更胜工于心计之人。

桌前的书上了很多,只有三类.Net【WPF,WCF,Essential】,objective-c,还有两本薄薄的编程珠玑。

心里也清空了很多,舍得,舍得,不舍怎得

Cocoa Windows Rectangle warning

Leave a comment

  • Issue descriptions : http://stackoverflow.com/questions/1797857/apple-interface-builder-warning-this-windows-content-rectangle-dows-not-lie-enti
  • Solution : for windows position of application, if there is no default position, cocoa framework runtime will run by default, However, the building framework will give warning.

Other available software for screen-shot : http://www.mac52ipod.cn/post/CaptureMe-Skitch-Jing.php

  • If video driver has some issues[for instance, on virtualbox system, it mayn’t save correctly on the desktop]

VSTemplate&MSBuild Category

Leave a comment

Unload VSPackage Project, then add MSBuild XML setting: http://msdn.microsoft.com/en-us/library/5dy88c2e.aspx

<!– To modify your build process, add your task inside one of the targets below and uncomment it.
Other similar extension points exist, see Microsoft.Common.targets.
<Target Name=”BeforeBuild”>
</Target>
–>
<Target Name=”AfterBuild”>
<ItemGroup>
<!– Mashup and WebService of Authoring Category, Orlando, 2011-08-18 –>
<AuthoringZipItemFilesToCopy Include=”.\$(BaseIntermediateOutputPath)$(Configuration)\HtmlMashupAuthoring.zip” />
</ItemGroup>
<Message Text=”Copying Zip Files to runtime folder”>
</Message>
<!– Mashup and WebService of Authoring, Orlando, 2011-08-18 –>
<Copy SourceFiles=”@(AuthoringZipItemFilesToCopy)” DestinationFolder=”..\$(Configuration)\Templates\ItemTemplates\MashupWebService Authoring” SkipUnchangedFiles=”true”>
</Copy>
</Target>
<Import Project=”$(MSBuildExtensionsPath)\Microsoft\VisualStudio\DSLTools\v10.0\Microsoft.DSLTools.targets” />
</Project>

Refer to :

Older Entries Newer Entries