Author Archive

We survived ÜberConf!

June 17, 2010 Comments off

This NFJS conference was intense with a lot of good speakers. Sean, Brian and I started ÜberConf 2010 in Denver with a relaxing Monday evening of dinner with a KeyNote on Challanges and Directions in Java Virtual Machines by Dr. Cliff Click. Following the keynote was a meet and greet party with delicious Hors d’oeuvre and free beer. It all sounds great and easy? That’s just the beginning.

The real hard work started on Tuesday. The sessions went from 8am – 10pm. Yup, 6 great 1.5 hour sessions in a day. Our brains were overloaded with information and code snippets. Dr Cliff Click finished both of his sessions (The Art of Benchmarking and Fast ByteCodes for Funny Languages) earlier. He offered bonus talks on The Pauseless GC algorithm and Towards a Scalable Non-Blocking Coding Style. Rather than 6 sessions, I had the great opportunity of attending 8 sessions in a day instead.

With so much going on, we could have easily turned into zombies before the evening sessions. However, the two evening sessions (Mike Richard’s session on the Art of Messaging and Venkat Subramaniam’s session on How to Approach Refactoring) that I had attended were gold. The speakers kept the adrenaline going with lots of great jokes (e.g. “Commenting out code during refactoring is like leaving a dead rat on the table”) and interesting titbits.

In a nutshell, funny speakers, great material, delicious food and beautiful weather (29 degree celsius), we can’t complain. Now it’s time to go home, go through the notes to recap what we have learned and use it well.


Should I use PUT or POST for a CREATE operation in REST?

March 16, 2009 1 comment

POST is for CREATE, and PUT is for UPDATE and CREATE. Ok, they both allow CREATE, how should we choose to use PUT or POST for a CREATE? Let’s say we have an animal adoption service. We have /animals to give us a list of all the animals for adoption. Let’s say we allow the user to create a category to group the animals together, such as /animals/dogs/ to list all the dogs for adoptions. Meanwhile, /animals/dogs/{id_of_a_dog} will give us the details of a dog for adoption. Now, we want to create a new category “cats”, which will give us /animals/cats. We want to also be able to add a cat for adoption. Should it be PUT or POST?

The Method Definitions of HTTP says that “The POST method is used to request that the origin server accept the entity enclosed in the request as a new subordinate of the resource identified by the Request-URI in the Request-Line.” And “The PUT method requests that the enclosed entity be stored under the supplied Request-URI.” The document also mentioned an important point “Methods can also have the property of ‘idempotence’ in that (aside from error or expiration issues) the side-effects of N > 0 identical requests is the same as for a single request. The methods GET, HEAD, PUT and DELETE share this property.”

In other words (plain English), we need to ask the following question:

  1. Does the user know the URI? Do we allow them to derive and decide the URI for the object to be created?
  2. What is the effect of the call to be executed twice? Is there no duplicated object created?

If the answer to both questions are true, then we should use PUT to create the categories, which means that we will PUT the request to the desired URI (animals/cats).

If the answer to both questions are false, then we should use POST to create (in this case the cat for adoption), which means that we will POST the request to the parent URI (animals/cats), in which case the response shall give us a new URL (e.g. http://somehost/animal/cats/{id_of_the_cat} ) to identify the cat that we have just created. Executing the POST again with the same request will end up creating an entry for the second cat to be adopted.

Of course, rules can be bent under certain circumstances, but we should remember “the principle of Least Astonishment” as mentioned by Scott Meyers in his  “Better Software – no matter what” talk given at SDWest, which is to strive to maximize the likelihood that user expectations about an interface are correct.

By: Nyik San Ting


March 12, 2009 Comments off

PersonasOn behalf of Todd (there were 2 UE related talk at the same time), I went to the “Personas, Profiles, Actors, & Roles: Modeling Users to target Successful Product Design” by Jeff Patton. Being a newbie in this area, I found the idea to be refreshing and powerful. Using the funny video clip on Spinal Tab’s stonehenge, he illustrated the importance of understanding the context of the product that we are building, rather than blindly following specification from the clients/users.

A software product is shaped by business strategy, users, legacy code, regulatory constraints, product usage … Being agile, we can have a bloated backlog. A good way deal with that issue is to identify the different types of users that is relevant to the product design and prioritize them accordingly to the targeted audience that we care most. We can have many different way of categorizing the user, such as according to their computer skills, their goals (broker vs agent vs buyers vs press…),  first time user, returning user, user with different domain understanding level (agent just got into real estate business vs agent who has years of experience)….  We can come up with lots of different users with their own characteristics, but some users may not make a difference in how the product should function, hence we can group them together. After having distincts personas, we can prioritze them taking into account of the business goals, then we can priortize the different feature/design according to the characteristics. Personas make user data more tangible, ensure we didn’t miss the different aspects and gives clue about the proper UE design. The distinct personas show who are the targeted audience and become the design imperatives to keep us focus.

By: Nyik San Ting

Test and production code maintainability are equally important

March 12, 2009 Comments off

Yesterday, I attended the sessions of “XUnit Test Patterns and Smells; Improving Test Code and Testability Through Refactoring” by Gerard Meszaros and “Design Patterns Explained from Theory to Practice by Scott L Bain”. Gerard went through a few test smells and patterns, it’s nice to be able to identify the test patterns we have been using in Point2 and associate it with a proper test pattern name like Expected Object, Humble Object.

So far Scott’s session is one of my favorite sessions. His great explanation on the different designs of the Command and Lunar modules of the spacecrafts in Apollo program is so very interesting! 😛 Ok, the spacecraft designs is interesting, but more importantly he provided an innovative way of looking at the Design Patterns in practice. He recapped the guidelines from “Design Pattern: Elements of Reusable Object-Oriented Software” (the book that Scott said “Lots bought, little read, few understood”) by the Gang of Four:

  • Design to interfaces
  • Favor object aggregation over class inheritance
  • Encapsulate the concept that varies

Each design pattern is an example of a design that follows those general advices in the given context. Using the different designs of the spacecraft, Scott illustrated the importance of domain analysis to identify the “forces” (the contextual constraints) and achieving the goal of design by context. He showed how the designs should evolve and emerge as the forces/requirements grow over time by following these guidelines. Good design should have strong cohesion, proper coupling, no redundancy and encapsulation. He pointed out that a developer who knows about design patterns doesn’t mean he/she is pattern-oriented. He mentioned the design pattern repository on the Net Objectives website that is maintained by the community. For each of the design pattern in the repository, there is also a section about testing issue and cost-benifit regarding each pattern.

Scott emphasizes the importance of TDD to enforce the “design of interface by nature” and the importance of production code maintainability, while Gerard emphasizes the importance of the test code maintainability. In a nutshell, we should have a maintainable, good quality code in all aspects of the code base. “Refactoring”, “good patterns” and “clean code” should apply to both test and production code. Just like what Uncle Bob said in his “Clean Code III:Function” session today: “Rules for unit tests are no different than production code”.

By: Nyik San Ting

Day 1 at SD West

March 10, 2009 Comments off

So here we are at the SD West conference! We arrived last night and it has been awesome. Between the 4 of us we have attended 8 sessions today J Here’s a list and some detail of the sessions we attended today:

  • Better software – No Matter What by Scott Meyers
  • From Stories to Automated Acceptance Tests by Brett Schuchert
  • Extreme Programming: After 10 years, Why are we still talking about it? Keynote address by Robert C. Martin
  • Test-Driven Development with Junit by Robert C. Martin
  • Agile Model Driven Development (AMDD): Techniques for Scaling Agile Software Development by Scott Ambler
  • Set your User Stories Free with Groovy’s easyb by Andrew Glover, Rod Coffin
  • Is SOA dead? Keynote address
  • Life inside LinkedIn Engineering: The Architecture, the Processes, the Lessons by Rusian Belkin and Nicholas Dellamaggiore
SD West 2009

SD West 2009

From most of the talks we have attended today it appears that Agile, Scrum, TDD, Stories were topics that all the speakers are talking about, and we are proud to be part of Point2 where these are employed on a daily basis.

To view more photos, please go to:

More updates will be coming tomorrow!!!

By: Nyik San Ting