Friday, May 8, 2015

How to submit a form using javascript in ATG

Today I spent lots of time to figure out how to submit a form in ATG platform. I tired many times and with the help of Google, I finally find the solution,

1. make sure to set type="hidden" to the input field of the formHandler  handleXXX method, like this:

<dsp:form id="myForm">
   ....
  .....
   <dsp:input type="hidden"  bean="MyFormHandler.handleMethod" value="" />

</dsp:form>


2. in  your javascript method, you just need to call:

$(#myForm).submit();


I found when I typed type="submit" for the input field, and  the handleXXX method is never called when the form is submitted through the javascript.

Resources:
1. https://community.oracle.com/thread/2471843
2. http://stackoverflow.com/questions/29300501/atg-formhandlerneed-to-set-some-values-before-calling-the-handle-method
3. http://www.mkthakral.com/j2ee/oracle-atg/atg-formhandler-ajax-call-using-jquery-json/

Wednesday, May 6, 2015

How to mock a for loop using mockito

Today when I tried to use mockito to write unit test cases, I found I need to mock the for loop operation. Then I found the solution from here in stackoverflow: the basic idea is to mock the iterator class and collection class, and base on your situation, you need to set the expectation of iterator.hasNext() and iterator.next() method.

The following code is copied from the above link:

Saturday, May 2, 2015

Groovy's powerful collection methods

Recently I just realize Groovy provides some handy methods for collections.

Permutations

Combinations

Subsequences
Intersect

Friday, May 1, 2015

Review of the talk: "Complexity is Outside of the Code"


Broadcast live streaming video on Ustream


Yesterday I watched the video: "Complexity is Outside of the Code" by Dan North and Jessica Kerr at craft conference 2015.  Here I summarize what I learned.

Learning
  • Learning is a first class task.
  • Follow the process: explore, evaluate, familiarize, understand and validate
  • Lean startup's "build-measure-learn" cycle, nothing should be built without any reason.
business impact <- learn <- measure <- test <- code
Dan uses the Kanban's pull based concept to describe the above concept: for example test pulls the code, business pulls the learn. This drives me to think more about TDD, in TDD we believe we should never start coding without a failing test.(Uncle Bob's 3 laws of TDD),  which is quite similar with the lean startup concept: "nothing should be built without any reason",  in TDD, the failing test is the only reason for coding, which means the failing tests pulls the code, Bingo! Now I understand why Kent beck said TDD is Kanban for code


The Goal of software development
The goal of software development is to sustainably minimize lead time to business impact

Develop a supportive community
  • Nurturing a supporting team is vital within software development
  • It is OK to point out bad things and not have a solution
  • Reduce specialist silos, encourage becoming generalist
  • Developing a supportive community, contribute open source to other teams

Resources
http://www.ustream.tv/recorded/61439914
http://www.infoq.com/news/2015/04/north-kerr-complexity-code
http://www.slideshare.net/jessitron/complexity-is-outside-the-code

Wednesday, April 29, 2015

Regular expression: you should not use dot to match any character in Java/Groovy

Recently I just realize that in if you want to match "any character" in  Java/Groovy, you should not use dot match (.).

The reason is: dot match only works for single line text, will not work for line breaks.  For the multiple lines text matching, the solution to match any character is using [\s\S].

Please refer this article for details.

For example, following code snippet is used for stripping the javascript code in the text

Source code:

Learning Scala 1: swap array elements

Here posted my solution for the exercise 2 and 3 of Chapter 3 of page 39, in the book "Scala for the impatient".

Exercise 2.  Write a loop that swaps adjacent elements of an array of integers. For example,
Array(1, 2, 3, 4, 5)  becomes Array(2, 1, 4, 3, 5) .

Solution:
Exercise 3.  Repeat the preceding assignment, but produce a new array with the swapped
values. Use for /yield.

Solution:
Note: I realize you can not write java style for yield statement, like if ( i%2 ==0 ) yield s(i+1)

Monday, April 27, 2015

What I learned from Agile Engineering training

Last week I took the 3-day "Agile Engineering Training" in TELUS, thanks a lot to our trainers from LeanIntuIt - Shawn Button and Declan Whelan.  I learned a lot from them.  The course covers TDD, Simple Design, SOLID principles, refactoring and dealing with legacy code.  The fun part is there are a lots of coding Kata, like Bowling Game, Gilded Rose, etc.  I am so glad to have an opportunity to learn those stuff, even actually I learned them since 10 years ago, this time I feel  this training is a kind of a review of what I learned since I decided to be a software craftsman.

Here is the mind map summarized of what I learned.


Add some thoughts:
  1. TDD/SOLID principles/Refactoring skills become more critical and in an Agile/Scrum team,  you have to be great, to be better so that you can deliver faster,  your code will be easier to change, easier to maintain;
  2. Simple Design -  it is summarized by only 2 points: fixing names and removing duplication. Combining with TDD's Red/Green/Refactoring cycle,  it means just repeating this 2 things with test cases, your complex code logic design phase will turn into many tiny steps which just renaming and removing duplication; if you can do it fluently,  the effort of thinking hard before hand becomes simple physical typing movements - which means you can design the code without thinking too much. This conclusion is so striking.
  3. Refactoring -  When I tried the Kata Gilded Rose (a simpler version which have all the tests before),  I really sense the power of simple design - refactoring by doing renaming and extract methods, then the business logic gradually emerged, and design pattern is emerged. For me it means as long as you have all the test cases, then you can refactoring the code without need to understand the business logic, and business logic will be more clear after you refactored.  That is another aha moment for me. Looks like code quality is a separate attribute beside the domain knowledge. If we apply this to code review, it means the good code should be enough understandable without understanding the business background first.

Resources:
  1. Four Elements of Simple Design, by JBrain
  2. Kata: Gilded Rose, this is a great Kata about refactoring, it worth trying more times