New Product Release: Mingle 2.1 Available for Download

Mingle 2.1, a new release of Mingle, the project collaboration tool from ThoughtWorks Studios, is available for download now. Mingle 2.1 offers enhanced workflow management capabilities, multi-level access control, a variety of options for complex tracking and reporting and an enriched user experience.

New in Mingle 2.1 | Test-drive Online | Download free trial

Highlights of Mingle 2.1:

  • Access management for enterprises of all sizes and shapes; four levels of access.
  • Seamless workflow management with automated transitions to follow gestures made on Mingle’s card wall views.
  • Expanded functionality for Card Trees and Hierarchies to allow for simple management and visualization of large sets of cards.
  • Enhanced reporting and tracking ability with the introduction of card properties for simple traceability and new macros to enable write-once-reuse-often reports.

Thin The Fast Ruby Web Server

Today Mongrel is the defacto Ruby webserver of choice (watch Zed Shaw's, creator of Mongrel, presentation from QCon London 2007) . But a new experimental solution is now available under the name of Thin. Thin glues together three Ruby web libraries:

  • The Mongrel parser (using Ragel) the root of Mongrel speed and security.
  • Event Machine, a simple event-processing Ruby library that makes it possible to write scalable network I/O process.
  • Rack, a minimal interface between web servers supporting Ruby and Ruby frameworks.
Marc-André Cournoyer made a presentation of Thin at latest Montreal on Rails showing the benefits of Thin.

The performance improvements can be significant with increases up to 25% for requests/s and around 15% less memory used, although the speed is dwarfed by the time spent in Rails.
Since 0.6.1 version in January Thin supports listening to UNIX sockets as well as to TCP/IP sockets, making it even faster.



Thin already supports most Ruby Web Frameworks Rails, Merb, Camping, Sinatra, Ramaze, Vintage, Swiftiply.
Thin is a 3 months old project and it is worth a try before a production release is out.

Today is my birthday!

Today is my birthday. I came to this world on the same day 25 years ago. It was the best day, while it was also the worst day. I can not remember the day, while other people will never forget the day.

Today, I'd like to commemorate the departed saints more than celebrate my own celebration. They went to the better world on the day when I came to the ugly world.


On Oct 18, 1931, Thomas Edison, the greatest inventor in the world, who had invented incandescent lamp, gramophone, cinematograph and other 1090 patents, died at the age of 84.

On Oct 18,2008, Xie Jin, a famous director, who had won lots of honour, died at the age 85.

The Terrestrial Equator Under My Feet!




The grassland, on which I stand, has nothing special. While the line under my feet is extraordinary. Step over it, and I will stand on the other half of the earth -- It is the EQUATOR!

Initially, everything in the world is meaningless. It is we people that put meaning or significance into objects and things. Therefore, thought decides upon pattern, and pattern decides upon significance.

Let's step over the LINE together.

The Agile Coach, from A to Z

| 0 comments

Agile methodologies introduce a newer role, typically called the "Agile Coach" that traditional methodologies will not focus on, or even mention. For those who have been working in an agile way for some time, it may seem like a natural complement, yet for those newer to this way of working it raises many questions like, "What's so important about an Agile Coach: What's wrong with a Line Manager, or a Team or Technical Lead: Why does Monster.com list 54 positions with this title:"

Let's take a quick tour through the alphabet to really understand what an agile coach focuses on, what they do, how they act and, more importantly, why.

The Quick Reference to the A-Z Guide










A is for Advice
B is for Balance
C is for Celebration
D is for Daring
E is for Encouragement
F is for Feedback
G is for Guidance
H is for Humility
I is for Infectious
J is for Jiggle
K is for Knowledge
L is for Listening
M is for Mentor
N is for Naysayers
O is for Obligated
P is for Principles
Q is for Questioning
R is for Retrospectives
S is for Sensitive
T is for Transparency
U is for Unlock
V is for Vocabulary
W is for Welcoming
X is for Xenodochial
Y is for Yarn
Z is for Zen


A is for Advice : "I've seen it done this way and that way before. I feel you might get better results doing it this way."



Traditional managers direct people instead of helping them find their own path. The agile coach prefers less directive approaches, although she will often work in the role of an advisor, stepping in when needed to help teams avoid known pitfalls or steering them in directions that will often end with better results (see Guidance and Mentor).

B is for Balance :"Don't drop the good things."



Teams sometimes get so busy they get caught up in their usual routine. The coach looks for opportunities, working with the team to discover or try new things that may bring the team great benefits. He is also there to make sure that practices that already benefit the team aren't simply replaced and forgotten about, often combining them with new methods.



C is for Celebration : "You guys did a great job last iteration!"



Teams often undervalue the power of success and appreciative inquiry. Iterations help bring closure, developing a rhythm that helps people recognise when they reach their goals (see Feedback). The celebration part of the iteration is often forgotten. Think about the positive impact events have where the entire team is celebrating the end of a project, or some other significant milestone (see Infectious). The agile coach celebrates with the team those little successes every day.



D is for Daring : "I'm about to go out on a limb telling you this, and..."



Introducing change requires a certain level of risk, and the responsible agile coach looks for ways of trying things that bring maximum value with minimum risk. He will often be the first to break the ice with a team, encouraging an atmosphere where everyone on the team feels safe to at least suggest, if not try, different ways of working.



E is for Encouragement : "Keep going! This is amazing stuff!"



Some of the agile practices seem fairly straight forward, yet often easy to get wrong without understanding why they bring what they bring. Often, simply trialling a practice for a decent length of time will give people a feel for the things that worked better for them, and what limitations the practice has (see Questioning). The agile coach provides the support and encouragement to help them through the initial period of trying out a new practice, sometimes helping them work through some of the more difficult parts of that practice.



F is for Feedback : "Did you realise that the team does...?"



All agile methodologies share a common thread incorporating quick cycles of feedback. The agile coach emphasises the importance of feedback mechanisms in all aspects of how a team works – everything from team interactions, processes and practices. Regular feedback helps teams adjust more effectively to their own unique circumstances.



G is for Guidance : "It looks like we have three options: I feel the first two may be better. What do you think?"



The way of the agile zealot is not the same way of the agile coach. Instead of the zealot's command and control, the agile coach often guides teams, helping each person to discover lessons for themselves. He steers the team away from known traps and pitfalls, but he also understands that trial-and-error is a powerful teacher. H is for Humility : "Actually, it was the team that did the work, not me." The agile coach facilitates the team to help them accomplish their work. She should admit when they make mistakes or are wrong, and ensure credit for success goes to the right people. Arrogant coaches never last long on teams.



I is for Infectious : "You have to come and look at this!"



The agile coach brings enthusiasm and energy to teams, encouraging people to find a passion for the things they do, often seeded with his own energy to begin with. He will focus on understanding the limit of how much change a team is willing to accept and how effective his enthusiasm will be, careful not to be confused for the agile zealot. He is also constantly on the lookout for the right time to share his energy and enthusiasm.



J is for Jiggle : "Tweak it a little bit here and a little bit there."



There is rarely one way of doing things effectively, even when a team starts with the same set of practices. The agile coach helps teams adjust their own practices to better suit the team and the environment, based on their previous experiences and understanding of why.



K is for Knowledge : "Have you read the book/article/emailing list for ...?"



The world holds a myriad of information about agile practices and principles, their adoption methods and challenges they present. The agile coach is familiar with a whole set of resources directing people to books, articles, and blog posts for the resources that will be most relevant to them.



L is for Listening : "I hear you telling me that you want to..."



The agile coach needs to listen to the team they're working with to really understand what they are going through, the things they like and the things they dislike. Sometimes it’s also helpful to reflect what she hears back to the team. She listens to each member, to understand what are their needs and fears, adjusting her priorities and activities in response to this. Sometimes this involves sharing it with others, or encouraging people to speak up for themselves.



M is for Mentor : "Making themselves redundant"



The ultimate achievement for the agile coach is to make a team self sufficient and self sustained, capable of fine-tuning their own practices. To this end he will be looking for the right people to mentor and support, in a role that looks similar to the coach's.



N is for Naysayers : "I don't believe you"



Every group may contain someone who's going to be completely opposed to the presence of an agile coach, without any apparent good reason. The agile coach needs to be able to withstand the critics, and understand their needs and why they might be feeling threatened (see Listening, Questioning and Sensitive). She would work with them to make them feel heard, address their needs and to put them at ease. Resistant naysayers need to be encouraged to move on, and this too may be part of the coach’s job.



O is for Obligated : "A part of the team"



It's important to demonstrate that the activities the agile coach suggests are intended to be the best for the team (see Transparency), and it often helps for him to work as a part of the team and experience the same consequences of a decision made.



P is for Principles : "Not just the what. It's also the why."



Seeing beyond the simple execution of practices, the agile coach brings an insight and understanding driven by a set of principles. Practices without principles generally bring little benefit, yet principles without practices are often difficult to achieve (see Guidance). She helps teams live out the principles by guiding them through a set of practices, helping them understand the value these add, and adjusting them to what works for the team and organisation.



Q is for Questioning : "What did you see? How did that make you feel?"



Asking questions is a great way to help clarify heated or difficult situations (see Naysayers). The agile coach will often ask questions to help separate fact from opinion, or to get a better understanding of the situation at hand. Without asking questions, it's easy to jump to a conclusion that will not work for the team in the long run.



R is for Retrospectives : "What have we learned? What would we like to do more? What would we like to do differently?"



Retrospectives are a key practice that the agile coach draws upon to help the team learn about what they have done. Project retrospectives offer wisdom to new projects whilst interim or heartbeat retrospectives help a team respond quickly to an ever-changing environment, to remain and become even more effective. She also benefits from retrospectives with them highlighting what changes have been implemented, or at least bring to light common underlying issues that may repeat themselves time after time (see Listening).



S is for Sensitive : "I wonder if they're ready for ..."



The greatest agile coach respects the culture and environment the team works in (see Listening and Welcoming). She doesn't walk into a team demanding them to change the ways they work; she will first observe the situation before coming up with recommendations.



T is for Transparency : "I'd like you to try this because I feel it will help you do ..."



Being honest helps the agile coach build trust. He explains the reasons he does things to offer them insight to what they might gain by trying something new. When he explains the current situation, its similarity to past experience or a lesson previous learned, people feel safer accepting his suggestions, and are more likely to understand and "own" or internalize them. In some situations, it is also an important way to let them know that he is not trying to implement some hidden agenda or satisfy an ulterior motive.



U is for Unlock : "I didn't know this team could do this!"



Teams often have plenty of potential that remains untapped because of the system they work in. Through careful observation and respect for the current processes, the agile coach often unleashes the team’s potential abilities by helping them identify and remove systemic barriers.



V is for Vocabulary : "YAGNI? Burn up? Muda?"



Every methodology brings with it a set of terms used throughout. The agile coach keeps abreast of terms, acronyms and special words, mapping it back to whatever mental model the team uses. This is especially challenging where the new model and the existing mental model are not compatible, and may call for experiential teaching (see Zen).



W is for Welcoming : "What do you think we should try?"



When the agile coach is successful, the team brings new ideas to the table and actually executes them. An initial step for the agile coach will be trying to welcome and support new ideas that individuals suggest, protecting them from the harsh criticism that typically followed in the past.



X is for Xenodochial : "Friendly to strangers"



Most agile coaches move around from team to team and need to fit in with different groups. Not only do they have to be approachable by different people, but they also have to ensure that what they say and how they act doesn't work to exclude people (see Sensitive). Strangers each come with their own concerns and motivations – the coach must be sufficiently self-aware to remain open to the untapped potential of each one.



Y is for Yarn : "Once upon a time..."



Sharing stories plays a large role in the way knowledge moves between cultures, and is one technique the agile coach often draws upon to help spread knowledge and understanding. Some of the stories might be based on experiences and interactions with previous teams, while others might simply be presented as a metaphor to help explain a concept.



Z is for Zen : "You must find your own way"



Some lessons need to be experienced to help people learn - providing advice isn't as effective as creating a safe environment in which people can make mistakes without dire consequences. To this end the agile coach may use a technique like the Socratic method to help people find appropriate solutions for their own problems.

A Quick Objective-C 2.0 Tutorial

In the interest of getting started quickly, here's a quick tour of new features in Objective-C 2.0 which will probably affect about 80% of the work you do. We'll look at properties, dot syntax, fast enumeration, and garbage collection.

Properties

Properties are a generic way of declaring the data a class provides. In a Movie class, the properties would be things like title, studio, and yearReleased. Here's what the header for the Movie class looks like in Objective-C 1.x:

@interface Movie : NSObject {

NSString* title;

NSString* studio;

int yearReleased;

}

+ (id)movie;

- (NSString*)title;

- (void)setTitle:(NSString*)aValue;

- (NSString*)studio;

- (void)setStudio:(NSString*)aValue;

- (int)yearReleased;

- (void)setYearReleased:(int)aValue;

- (NSString*)summary;

@end



Here's how it looks using Objective-C 2.0 and the new Leopard NSInteger type:

@interface Movie : NSObject {

NSString* title;

NSString* studio;

NSInteger yearReleased;

}

+ (id)movie;

@property (copy) NSString* title;

@property (copy) NSString* studio;

@property (assign) NSInteger yearReleased;

@property (readonly) NSString* summary;

@end



Notice that not everything is a property. There's a class method for generating new objects called +movie. There's no way (or need) to declare this as a property. The format is:

@property () ;

The most-commonly used parameters are copy/retain/assign. You choose one to specify how the setter will be generated for the property. Many Objective-C objects are best used with retain, but since these are strings, we'll use copy.

The assign keyword will generate a setter which assigns the value to the instance variable directly, rather than copying or retaining it. This is best for primitive types like NSInteger and CGFloat, or objects you don't directly own, such as delegates. Keep in mind retain and assign are basically interchangeable when garbage collection is enabled.

The readonly keyword means a setter will not be generated, so it should not be used in combination with any of copy/retain/assign. We're declaring summary as readonly because there's no instance variable for it. Instead, we generate the contents for it on the fly.

Let's take a look at the implementation of this class in Objective-C 1.x:

@implementation Movie

+ (id)movie {

return [[[Movie alloc] init] autorelease];

}

- (NSString*)title {

return title;

}

- (void)setTitle:(NSString*)aValue {

[title autorelease];

title = [aValue copy];

}

- (NSString*)studio {

return studio;

}

- (void)setStudio:(NSString*)aValue {

[studio autorelease];

studio = [aValue copy];

}

- (int)yearReleased {

return yearReleased;

}

- (void)setYearReleased:(int)aValue {

yearReleased = aValue;

}

- (NSString*)summary {

NSNumber* yearAsObject;

yearAsObject = [NSNumber numberWithInt:[self yearReleased]];

return [NSString stringWithFormat:@"%@ by %@, released in %@",

[self title], [self studio], yearAsObject];

}

@end



And here's the Objective-C 2.0 version (with garbage collection enabled):

@implementation Movie

@synthesize title;

@synthesize studio;

@synthesize yearReleased;

+ (id)movie

{

return [[Movie alloc] init];

}

- (NSString*)summary

{

NSNumber* yearAsObject;

yearAsObject = [NSNumber numberWithInteger:self.yearReleased];

return [NSString stringWithFormat:@"%@ by %@. Released in %@.",

self.title, self.studio, yearAsObject];

}

@end



The @synthesize directive generates accessor methods for us and garbage collection means +movie doesn't have to autorelease the object it returns. In addition, we use self.title and self.studio instead of [self title] and [self studio].

Let's see how this looks from the perspective of a client of the Movie class:

Movie* newMovie = [Movie movie];

newMovie.title = @"The Incredibles";

newMovie.studio = @"Pixar";

newMovie.yearReleased = 2004;

NSLog (@"Movie summary: %@", newMovie.summary);

This, of course, prints the following in the console:
Movie summary: The Incredibles, by Pixar. Released in 2004.

You can use either of the two accessor forms in Objective-C 2.0. You're not required to use dot syntax to access properties. You can also use the dot syntax on classes which don't explicitly define properties. For example:

NSString* newString = [textField stringValue];

NSString* newString = textField.stringValue;

The difference between @property and @synthesize might seem a bit unclear at first. Think of @property as declaring a property exists. The @synthesize directive actually implements code for the accessors, if necessary.

Note: By default, synthesized accessors are atomic in that the getter is guaranteed to return a valid value even with multiple active threads. There's no cost for this if garbage collection is enabled. You can disable this behavior with the keyword nonatomic.

Fast Enumeration

In Objective-C 1.x, your main options for loops were the standard for and while loops from C, and NSEnumerators. In Objective-C 2.0, you can use fast enumeration, which looks like this:

NSArray* allMovies = self.movies;

for ( Movie* oneMovie in allMovies ) {

NSLog ( @"%@\n", oneMovie.summary );

}

It's a much simpler syntax, much faster than a for loop, and much safer since trying to modify the collection while it's being enumerated will cause an exception.

Garbage Collection

There's not much to say about garbage collection in a introductory-level tutorial. For the most part, it should "just work" in simple cases. Once you enable it, retain, release, autorelease and the other memory management methods have no effect. The copy and mutableCopy messages, of course, still copy the value of the object.

Garbage Collection is off by default. You enable it by double-clicking a target in your project and changing the "Objective-C Garbage Collection" setting to "Required":

Xcode Enable Garbage Collection


Garbage collection does not collect CF-style objects, such as CGImageRef, and you obviously still need to handle manually-allocated memory with malloc() and free(). There are a number of keywords you can use to get finer-grained control, such as specifying weak references. Those details are outside of the scope of this tutorial.

Keep in mind that the dealloc method is not called when garbage collected is on, but you can implement -finalize for some (though not all) of the same cases. Garbage collection eliminates retain cycles (objects which retain each other and are never released).

A Few Tips

When using properties with the dot syntax, prefix the name with self to use the accessor:

// direct access

value = studio;

studio = value;



// uses accessor methods, sends KVO notifications

self.studio = value;

value = self.studio



Even if you have garbage collection enabled, you should still use the accessor methods in most cases because Key-Value Observing, and Cocoa Bindings depend on these methods being called to synchronize changes across objects.

The NSInteger, NSUInteger and CGFloat types are architecture-safe versions of int, unsigned int and float/double. They'll shield you from the underlying processor-specific issues. If you're targeting Leopard, you should use these instead of the ANSI C alternatives. NSNumber has new methods for these types:

- (id)initWithInteger:(NSInteger)value;

- (id)initWithUnsignedInteger:(NSUInteger)value;

- (NSInteger)integerValue;

- (NSUInteger)unsignedIntegerValue;

+ (NSNumber *)numberWithInteger:(NSInteger)value;

+ (NSNumber *)numberWithUnsignedInteger:(NSUInteger)value;



If you need to access a C struct in an Objective-C object, you may need to explicitly use brackets:

// "bounds" is a C struct. may be too ambiguous for the compiler

CGFloat value = self.bounds.origin.y;

// works reliably

CGFloat value = [self bounds].origin.y

Wrap-up

There's a lot more ground to cover, but this should give you a good start. We can look at more advanced topics in future tutorials. The 64-bit runtime has some features that the 32-bit version does not, such as the ability to synthesize instance variables. All of the hardware Apple currently ships is 64-bit, but we're a ways off from 64-bit being a majority of the installed base.

Remember that all of the new features in Objective-C 2.0 are optional. Aside from some lower-level runtime functions and hacks, anything that was valid code in Objective 1.x is valid in 2.0, as well.

For more information, see the Objective-C 2.0 Overview at Apple Developer Connection.

[E]My First Post

| 0 comments

This is my 1st post!!

Actually, I'd like to call it a test rather than a post.

No matter what it is, this is a good beginning. Keep writing in my poor English...^-^