All .net developers know that LINQ can be used to conveniently extract and process data from arrays, enumerable classes, XML documents, relational databases, and third-party data sources. These concepts are adopted by other programming languages such as Java, Javascript, Ruby etc.

var cityWiseSalary = from comp in ListCompany 
                     select new { 
                            comp.Name,
                            Emp = (from emp in comp.ListEmp 
                            group emp by emp.Address.City into CityWiseEmp
                            select new {
                                   State = CityWiseEmp.Key,
                                   TotalSalary = CityWiseEmp.Sum(emp => emp.salary) 
                            })
                     };

There is no reason that we can’t port it to Objective-C. By using LinqToObjectiveC, we could write Objective-C code like:

NSArray* input = @[@"Frank", @"Jim", @"Bob"];

NSDictionary* dictionary = [input linq_toDictionaryWithKeySelector:^id(id item) {
    return [item substringToIndex:1];
} valueSelector:^id(id item) {
    return [item lowercaseString];
}];

// result:
// (
//    F = frank;
//    J = jim;
//    B = bob;
// )

Comparing to the old school KVC way:

NSArray *payees = [arrayOfTransactionsArrays valueForKeyPath:@"@distinctUnionOfArrays.payee"];

The API is not so intuitive, and not composable, is it?

iOS is a great app development platform, yet its UI programming model is so 1990s, the UI library is not so productive compared to the html CSS model. After iOS5, UIAppearance did improve such an outdated model and it allows you to modularize UI themes like the follow code:

[[UIBarButtonItem appearanceWhenContainedIn:[UINavigationBar class], nil]
       setTintColor:myNavBarColor];
[[UIBarButtonItem appearanceWhenContainedIn:[UINavigationBar class], [UIPopoverController class], nil]
        setTintColor:myPopoverNavBarColor];
[[UIBarButtonItem appearanceWhenContainedIn:[UIToolbar class], nil]
        setTintColor:myToolbarColor];
[[UIBarButtonItem appearanceWhenContainedIn:[UIToolbar class], [UIPopoverController class], nil]
        setTintColor:myPopoverToolbarColor];

But I would say why stop there? Why don’t we use CSS to stylize our iOS apps? And Pixate took a bold step towards that direction! You no longer need to use Objective-C code to set the themes:

#top-slider max-track {
  background-color: rgba(192, 192, 192, 0.5);
  background-size: 10px 10px;
  background-inset: 0px 5px;
  border-radius: 3px;
}

navigation-bar {
    color: white;
    background-color: #288de3;
}

tab-bar {
    color: #288de3;
    selected-color: white;
    background-color: #288de3;
}

tab-bar-item {
    color: white;
    font-family: "Open Sans";
    font-weight: semibold;
    font-size: 12;
}

Want to support both iPhone and iPad? No problem, use the @media rule:

/* Rule sets apply only when the device is in portrait orientation */
@media (orientation:portrait) { }

/* Rule sets apply if the device's height (ignores orientation)
 is at least 1000 pixels and if the device has a retina display. */
@media (min-device-height:1000px) and (scale:2) { }

/* Apply rules to iPad Mini in landscape mode. */ 
@media (orientation:landscape) and (device:ipad-mini) { }

Imagine how many lines of code can be reduced by using such a great library! How about readability and modularization?

It’s unlikely that we are going to reinvent iOS programming, but I believe by using the correct programming model, we can reduce the code size of a iOS app by the factor of 10.

Objective-C was quite verbose and lack of visual clue, however after Clang 3.5, there are quite a few improvements, these new language features allow us to write more clean code:

The “new” method

[Foo new]

is better than

[[Foo alloc] init]

if you don’t need to use custom init methods.

Object Subscripting

array[i]
dictionary[key]

are better then

[array objectAtIndex:i]
[dictionary objectForKey:key]

since they has more visual clues.

Primitive Literals

 NSNumber *fortyTwo = @42;

is bettern then

 [NSNumber numberWithInt:42]

since the syntax is consistent across int string char bool and enum types.

Container Literals

NSArray *array = @[ @"Hello", NSApp, @(i) ];
NSDictionary *dictionary = @{
    @"name" : NSUserName(),
    @"date" : [NSDate date],
    @"processInfo" : [NSProcessInfo processInfo]
};

Are better then the good old constructors.

By using these new language features, we would experience less cognitive load during programming.

Introducing coding dojo to a new group could be challenging. I facilitated quite a few dojo sessions, here are the rule of thumbs:

• We need at least 90 minutes to 2 hours
• If the audience haven’t tried test driven design before, we need to give them brief  introduction to:
  • red-green-refactor concept
  • 2 roles of pair programming: driver and navigator
• Then we can introduce the dojo procedure
• Ask a participant to start pairing with you
• Each pair work on 1 to 2 red-green-refactor cycles
• Some participant might start writing production code before reaching red bar, or start refactoring in red bar, we need to remind him or her
• Some pair might go stuck for a minute or two, usually it’s a good idea to move to next pair
• The group might or might not finish the kata within time frame (about 50/50) especially the first time

Facilitated or participating in a coding dojo could be a challenging yet fun and rewarding experience if we do it the right way.

Traditionally, in order to test both Android and iOS apps, we need to:

1. Create a test case document.
2. Translate the test document to automation scripts for Android and iOS.

As a result, we need to maintain 1 document and 2 scripts for each user story. But now, there is a less painfulway. All we need is to create a Cucumber test for each user story like the follow:

Feature: Rating a stand
  Scenario: Find and rate a stand from the list
    Given I am on the List
    Then I should see a "rating" button
    And I should not see "Dixie Burger & Gumbo Soup"
    And take picture

    Then I touch the "rating" button
    And I should see "Dixie Burger & Gumbo Soup"
    And take picture

    When I touch "Dixie Burger & Gumbo Soup"
    Then I should see details for "Dixie Burger & Gumbo Soup"

    When I touch the "rate_it" button
    Then I should see the rating panel

    Then I touch "star5"
    And I touch "rate"
    And take picture

And the script can drive both Android & iOS apps. Since the test script is more readable then Robotium or UI Automation scripts, so the PO or tester can understand and modify it by themselves. We create and maintain only 1 document instead of 3.

Overall, Calabash is a more cost effective tool to express executable specification on Android and iOS platform.

What is Code Kata?

Code kata is a concept that proposes to hone programmer’s skill by doing small problems many times trying to improve the code at each iteration.

Code Kata Plus?

But as a programmer, we are not programming in a vacuum. We use tools, commands, IDE etc. Start paying attention to these things during your kata sessions:

1. How many key strokes or mouse clicks does it take to:
   • Locate a compilation error
   • Reformat your code
   • Run a test
   • Refactor a piece of code
   • Trace a function
   • Pull up a shell in the current directory
   • Commit to version control
   • Locate mismatch parentheses
   • Switch between test code and production code
   • Auto complete with code snippets
   • Arrange windows in the right position and size
2. What’s the right color theme, font and font size for your eyes?

Don’t just improving yourself, improve you tools, it’s a more holistic approach. If you are not constantly programming your programing environment you are not taking full advantage of your own skill. Try to improve a few things, you’ll see the difference in your next iteration.

In traditional CI workflow, if you checked in something and broke the build, you would block the whole team. You might end up checking in less frequently. Or the team need to enforce some kind of check in policy. These do not make any sense to me. CI is supposed to give me rapid feedback, and broken builds are also good feedback!

By using the Git plugin for Jenkins to monitor all the branches on the local repository. Whenever a developer pushes to to repository, Jenkins will see the changes and try to merge it into the stable branch. And if you apply feature branching workflow in your team, broken build are on longer a blocker for the team, they are only a blocker for the developer working on the feature branch.

And if you integrate Sonar in your CI process, you will be able to use sonar to verify each feature branch before merging to the stable branch! Don’t you think that’s the right way of doing CI?

You can use Sonar or IntelliJ IDEA to write better Java code. But both tools have their good and bad.

Sonar

The Good

• Macro metrics, e.g. Complexity / method, you can get a overall sense of the code quality of the whole code base
• CI integration by triggering a build failure, you can’t ignore Sonar’s opinions
• Time machine, you can see the trend over time, are we getting better or worse?
• Hot spots, it’s a good tool to analysis legacy code, you know where should you start fixing
• Visibility, everybody can see what’s going on, there is no way to hide bad code.
• Offline review, reviewer can write comments from browser.

The Bad

• The feedback is not real time, I have to wait for x minutes to get the report
• Maven, you can’t live with it can’t live without it

IntelliJ IDEA

The Good

• The feedback is real time, and in place, it’s a better way to learn programming
• You can fix violations by applying refactoring, it gives you a better alternative

The Bad

• Micro metrics only, you can get the big picture
• Programmers can ignore its warnings
• You have to use IntelliJ which you might have x reasons not to.

The Solution?

Use both.

Just in case learning

JIC learning is the old fashion way of learning; you take courses, read books, and do exercises then hope you might be able to apply the skills/knowledge you learned someday.

Unfortunately, the shelf lives of technologies are getting shorter & shorter. New technologies emerge every week. As a result, people in the IT world started the 2nd phrase of learning:

Just in time learning a.k.a. Googling

Leveraging Google & Stack Overflow, solutions are just few clicks away as long as you can ask the right question and able to weed out lamp solutions. And the ability to ask right questions are depends on your learning matrix level:

Learning Matrix Has 4 Levels

Level 1: Unconscious Incompetence (You Don’t Know that You Don’t Know)

Level 2: Conscious Incompetence (You Know that You Don’t Know)

Level 3: Conscious Competence (You Know that You Know)

Level 4: Unconscious Competence (You Don’t Know that You Know – It Just Seems Easy!)

If you are in Level 1 or you are ignorant to part of the solution space, then you might come up with poor questions, and therefore sub-optimized solutions.

Here are the things you can do to stay away from this trap:

1. Don’t dive in and start solving your problem.
2. Come up with a list of questions / problems you want to solve in this domain. If you cannot articulate your question you are definitely in level 1.
3. Survey the whole solution space, go breath first. What are the tools, terms etc. Make a list of them.
4. Rephrase you questions, see if you can articulate them based on the stuff you collect in last step. At least, you know what you don’t know.
5. Start implementing you first solution by Googling once you reach level 2.

Conclusion

So instead of asking “How to do X in jQueryMobile?”, you might be able to ask:

• What are the differences between jQueryMobile and Bootstrap?
• What’s the best way to handle cross browser/ device?
• How to do BDD in javascript?
• Can I integrate JSLint in my IDE?

It’s very common nowadays to use multiple tools in our development environment, we use:

• Subversion for version control
• Sonar for static analysis
• Selenium for web testing automation
• Hudson for continuous integration
• Maven for build management
• etc.

You get the idea. In order to use these tools, constant context switching is required, I need to use:

• Outlook to check our build notifications
• Command line to kick start local build
• Chrome browser to check the sonar stats
• IDE to edit & check in code
• Remote desktop to the dev sever to check the error log

We all know that context switching is bad for productivity, I think the root cause is these tools are not well integrated and self centered.

The Solution?

The ideal development environment should be project centered, most of the things we need should be one command or one click away from us. One great example is the Ruby on Rails environment:

• Want to create a new project? Just one command away:

  rails new blog

• Start to server? No problem:

  rails server

  and you have the site running, no need to edit a 147 line maven xml file.

• Generate a new model/controller? Easy:

  rails generate model/controller

And the Java community is also starting to embrace this concept in Play Framework:

• Edit a java file & hit reload and see the results immediately! No need to compile, deploy or restart the server.
• Want to test your app? Just type:

  play test

  and you can run all unit tests functional tests & selenium tests from your browser:

Start your development environment refactoring!

You might say I don’t use RoR or Play Framework. I don’t use them either. But we all can start improving our development environment, one bash script at a time.

At Xerox PARC, a company, they had a slogan: “Point of view is worth 80 IQ points.”

It was based on a few things from the past, like how smart you had to be in Roman times to multiply two numbers together; Only geniuses did it. We haven’t gotten any smarter, we’ve just changed our representation system. We think better generally by inventing better representations; that’s something that we as computer scientists recognize as one of the main things that we try to do.

I’m not sure if I have 180+ IQ points, but some point of views do effect the way I look at things in my daily work. These 2 videos are quite thought provoking:

Simplicity Ain’t Easy by Stuart Halloway

Simple is not compound

Most of the solutions in software we create are compound solutions, they are not simple. By understanding what’s simple and what’s compound, you will have a higher chance of creating simpler designs and solutions.

Simple Made Easy by Rich Hickey

Simple vs. Easy

Simple is the opposite of complex. A thing is simple if it has no interweaving, if it has only one purpose, one concept, one dimension, one task. Being simple does not imply one instance or one operation: it’s about interweaving, not cardinality. Importantly, this means that simplicity is objective.

Easy is the opposite of hard, or difficult. A thing is easy if it’s near to hand, if it’s easy to get at (location), if it’s near to our understanding (familiarity) or skill set or if it’s within our capabilities. This means that ease is relative.

Focusing on ease and ignoring simplicity means that you’ll go really fast in the beginning, but will become slower and slower as the complexity builds.

Focusing on simplicity will mean that you’ll go slower in the beginning, because you’ll have to do some work to simplify the problem space, but making sure that you only have intrinsic complexity means that your rate of development will remain at a high constant.

Author Ronald Mai    GDC  Architect

Gitlab is a self hosted git management system, or the poor man’s Github. And this is my opinionated review on it:

Differences with Github

1. All projects are system level, you can’t create project under your account. As a developer, you can only create branches in the repository.
2. Issues are not related to commits, in order to fix an issue, you need to submit a merge request, and then close that issue.
3. Gitlab can be integrated with LDAP, user can sign in via LDAP. Every LDAP user can create 10 projects by default.
4. All projects are private, the project owner need to assign other developers to his/her project.
5. Small code snippets can be shared via Snippets tab.
6. You can deploy it on your own server.
7. It’s free & open source.

Due to these differences, our workflow needs to be adjust accordingly:

My Gitlab Workflow

1. Create a new project
2. Protect the master branch
3. Ask the developers to log in via LDAP if they haven’t done so
4. Assign them to the project
5. Developers create feature branches
6. Developers submit merge requests from feature branches to master
7. I merge them to the master branch

My Release Management Workflow

1. Create a release branch
2. Protect that branch
3. Developers create bug fixing branches
4. Developer submit merge request from bug fixing branches to release branch
5. I merge them to release branch & master

Conclusion

Gitlab is suitable for small scale collaboration, if you want to deploy it throughout the whole organization, the “all projects are private” setting could be cumbersome.