Jan 12, 2014

Auto increment primary key in PostgreSQL

If you want to increment primary key automatically in Postgres, "serial" is a good option.


Please that you do not need to specify a primary key to insert data to your database.

Dec 15, 2013

How to fix an error "Unable to find a $JAVA_HOME at “/usr”, continuing with system-provided Java"

Somehow, I have got this error whenever I run Java command:

$java -version
Unable to find a $JAVA_HOME at "/usr", continuing with system-provided Java...
java version "1.7.0_25"
Java(TM) SE Runtime Environment (build 1.7.0_25-b15)
Java HotSpot(TM) 64-Bit Server VM (build 23.25-b01, mixed mode)

I found the same error as my case at the stackoverflow.

Unable to find a $JAVA_HOME at “/usr”, continuing with system-provided Java

This happens when $JAVA_HOME is not set correctly. In my case, the following works form me.

export JAVA_HOME="$(/usr/libexec/java_home)"

My environment is as follows:
  • OS X 10.9
  • Java 1.7.0_25 (installed by brew)

Sep 12, 2013

Install R with homebrew under Montain Lion (Mac OS X 10.8.X)

You need to install gfortran before R. 
$ brew install gfortran
You might find that you don't have XQuartx. Please download and install it at https://xquartz.macosforge.org.
$ brew install R
Unsatisfied dependency: XQuartz
Homebrew does not package XQuartz. Installers may be found at:
https://xquartz.macosforge.org
Error: An unsatisfied requirement failed this build.
After you install XQuartz, you can install R like this:
$ brew install R


Sep 7, 2013

Ant 1.8 "warning: 'includeantruntime' was not set, defaulting to build.sysclasspath=last; set to false for repeatable builds"

I installed Ant 1.8 and build Java applications with Ant. Then, I found the following message:

warning: 'includeantruntime' was not set, defaulting to build.sysclasspath=last; set to false for repeatable builds
You can find a good explanation of this warning with following link:

http://ant.1045680.n5.nabble.com/warning-includeantruntime-was-not-set-td2639463.html

There were incompatible change on Ant version 1.8. So, you may find the same message if you build old ant file with Ant 1.8.

Please just add includeantruntime="false" to javac task.



Jun 2, 2013

How I did interpretration for TDD workshop by James Grenning at #agilejapan

I did interpretation for TDD workshop by James Grenning, the author of "Test Driven Development for Embedded C" at Agile Japan 2013 on May 24th. This was first time for me to be interpreter at a conference.



This time was good lesson for me. I summarized my experience so that this entry also become good lesson for some other people.

Why did I become one of interpreters for the workshop?

Let me tell you about history that I became interpreter fot the workshop.

I am an organizer of study group for "Test Driven Development for Embedded C" in Tokyo, Japan and I also was a reviewer for Japanese translation of the book. When translation was going to an end, I proposed to Akiyuki Takoshima, a supervisor for translation, that we invited James to Japan for publication party for translation. We thought Agile Japan was the best for it because it was planed to held after publication and organizers of Agile Japan usually invite keynote speaker from foreign country, mostly US. 

I expected that it would be difficult negotiation but the answer from Kenji Hiranabe, one of organizers, was very good. He said "Oh, that's nice idea. I have wanted to invite him to discuss about importance of quality in agile software development". Then Agile Japan organizer started negotiation and I and Akiyuki started preparetion for TDD workshop.

Basics of technical interpretation

Next, I want to tell you about technical interpretation.

You may think interpretation is just word exchange of different languages. I think real interpretation is more than that. In my opinion, we do interpretation as follows:

Maybe this is almost same as what non-native English speaker do when they talk in English...

  1. Understand what speaker said
  2. Understand its intention and digest result of step 1
    • If we don't understand its intention, we have to ask speaker
  3. Just exchange result of step 2 from original language to target language
  4. Change result of step 3 in natural and simplified expression and talk to other people 
    • We do step 3 and step 4 at a time

I think you think that step 3, automatic language exchange, is interpretation but I have to do more because we want to avoid loosing original speaker's intention and to tell it people in an easy-to-understand way.

To do this, we need both language skill and specialized knowledge for target area because we have different terminology each area. If we don't care about that, attendee don't understand what speaker say.

For example, in the case of translation, we often found that reviewers on amazon.co.jp write comment for translation of technical book that quality of translation is very bad.This is because there are problems on either step above.

  • Problem on step 1: translator don't understand original text 
  • Problem on step 2: translator don't have enough knowledge for target area
  • Problem on step 3: translator don't improve quality of translation

Then what do interpreter do during workshop?

It depends on workshop. I basically think that interpreter there are two tasks.
  • Tell trainer's explanation to attendee
  • Help question and answer
No big deal. That's it.

Tell trainer's explanation to attendee

For this, interpreter see trainer carefully and waits good time to interpret. Then good time come, interpreter tells it to attendee. Trainer sometimes tell us about timing for interpretation but he/she usually want to focus on what he/she say and attendee's reaction . So interpreter should     manipulate timing.

Help question and answer

For this, it is easy. We just hear question from attendee, check its intention and tell it to trainer. When trainer answer then we do opposite.

What do interpreter should prepare? 

(1) acquisition of specialized knowledge for target area

As I wrote above, we need specialized knowledge for target area to interpret. we have to read whole workshop material. We also should read trainer's blog, interview article or movie to understand content of workshop, trainer's way of speaking/pronunciation.. If we do, we can understand what trainer say easily. 

(2) Practice of interpretation

I think shadowing is easy and best for practice of interpretation. There are good books for interpretation. If you are interesting in practice, please refer the books.

Retrospective for this time


Keep(Good point, what I want to continue)


(1) I had enought time to aquire specialized knowledge for target area
Before workshop, I held study group, wrote interview article, reviewed translation of the book and   translated workshop material. I knew everything. No worries about that :)

(2) I had meeting with trainer twice before workshop

I had meeting with trainer 1 week before and 2 hour before workshop. I could solve our question such as timing for Q&A, laptop for demo, etc. 

(3) I could do interpretation without any eye contact

In this time, interpreter manipluated timing for interpretation so that trainer can focus on what he/she say. We sometimes made mistakes but we did good job in general.

Problem


(1) We translated workshop material then trainer couldn't read it

In this time, we are not professional interpreter. So we thought we should show Japanese translation of workshop material so that attendees can understand it easily. But trainer couldn't read it and sometimes didn't know what to speak next. This is not big problem because he had original version of material and we can tell. But this was not good for trainer's cognitive load.

(2) We couldn't interpret jokes

Trainer often said jokes because he want attendees to be relaxed. But joke is difficult to interpret. Sorry James :(

Try(What to improve)


(1) Keep original text on material and add Japanese subtitle

This is good for both of trainer and attendee. Kenji Hiranabe, interpreter of keynote, did this.

(2) Interpret jokes

We need sens of humor? ummm :(

In the End

Thank you Agile Japan organizer for giving me a chance to interpret. It was very good lesson for both of TDD and interpretation. This chance must improve my interpretation skill. It was good experience for my life :)

Thank you Akiyuki-san, supervisor for translation. We did translation of material and interpretation at workshop. He gave me lots of advice. I could do it because he helped me.

Thanks you James. My interpretation was not like professional interpreter. James helped me : ) I have to say thank him for his open mind for my proposal.

If I will have next chance for interpretation, I will do better. I have confidence now :)

Dec 13, 2012

Want an opportunity for programming education? Join the global day of coderetreat!

I join the "Global Day of Coderetreat 2012" on December 9th 2012. I also joined one in 2011. So, this was the second time for me to join it :) In this entry, I explain followings to you:

  • What is Coderetreat?
  • What is the Global Day of Coderetreat?
  • How to maximize your educational effectiveness

What is Coderetreat?


Coderetreat is a retreat for programmers. Most programmers need retreat because they always have to work for next delivery and they don't have enough time to learn basic skills such as programming and testing. The purpose of this event is to give them an opportunity to learn basic skills in a place where there is not delivery date. 

Characteristics of coderetreat are follows:
A single Gosper's Glider Gun creating "gliders"
  • You have 6 pair programming sessions. Each session includes 45 minutes pair programming and 15 minutes retrospective. You change your partner each session.
  • You have to delete your code at the end of session. You write code from the scratch every time. This gives you a chance to try different way of design. Actually you have to think design of code differently because facilitator gives you design constraints each session.
  • You get a chance to learn object-oriented design, pair programming and TDD. Facilitator or other participants teach you by hands-on if you need it. 
  • You can have good chance to learn new languages because your partner may know only languages that you are not familiar with. You may use it for the first time but you will make program with your partner's help. Actually I tried Ruby, Java, Scala and JavaScript despite I usually use C/C++ in my work. 
  •  Free lunch and sweets are provided by sponsors. Yeah! Here are sweets at Tokyo site.


What is the Global Day of Coderetreat?

This time was not just a "Coderetreat" but the "Global Day of Coderetreat" because it held in many countries. You can see city list on the official site. 56 cities? I am not sure how many countries hold but it was global event !

We connected to India last year. We chat what was going on both site. I was very excited that we were doing same activity with global scale! 

How to maximize your educational effectiveness

You spend whole day for this event. You should make this event meaningful.

But how to do it? I think that it is better to try different way, learn from everyone and broaden your eyes. 

Here are my activity list for this time.

1. Use different language and testing framework from usual one.

I am embedded software engineer and I usually write C/C++ code. I sometimes write Visual Basic or Python code. I don't have opportunities to use other languages in my work but I am interested in other languages.

For C/C++ programmer, sometimes other languages and frameworks have good features and concepts. Learning new language cultivate your programming style. But it is little bit difficult for us to start learning by ourself because we don't know where we go at first. So ask your partner about language is better way to learn.

In my case, I had fun with Ruby and RSpec, testing framework for Ruby. You can write code with your intuition without deep understanding of language specification. That's really comfortable for beginners. And you can struct your test code by elements such as "description" and "context". Your test code will be easy to read.

Features of Ruby and RSpec are quite new to me and quite different from C/C++ world. You can't everything of other languages but you may be able to bring essence into your work. Your work will change.

2. Design your code with different way as usual

The purpose of this event is to give participants new experience. We should try little bit different way. 

For example, if you don't do modeling or object-oriented design during your work, you might design your code with array. But I recommend you to try object-oriented design. You might think:
  • What kind of object do we need? 
  • What responsibilities does each object have?
Thinking about these questions make your design better.

In my case, we tried different one. I used map and filter to overcome several constraints such as no if statements and no loop. With this idea, I could write shorter and smart code.

3. Try technical practice in ideal situation

Coderetreat is not real job. Even if you don't complete, no one gets angry. You can try any practice as you want.

For example, if you know TDD but you have never tried it, then try it in coderetreat. You will discover how it works.

I tried double test loop that is introduced in "Growing Object-Oriented Software, Guided by Tests". In this practice, we write end-to-end acceptance test first and write code for inside module with TDD to pass acceptance test.

I often see that many participants tend to focus on detail of components and end up with perfect components and incompletion of whole game. If you do this in your work, your project will collapse.

If you write acceptance test for one scenario and write code with TDD to pass acceptance test, you get a system that works for certain scenario early. There is another benefit. You found considering points for architecture design early. You can avoid some risks in your project.

4. Share what your were interested in during retrospective

At the end of each session, every pair do retrospective, wrote own thought about session on stickies and put them on the board to share your experience.

Facilitators usually pick up topics to share but you can ask them to share your topics. You will receive many feedback from other participants.



5. Communicate with participants in other countries

At this time, we have two tags for twitter. "#gdcr12" for global and "#gdcr12ja" for Japan. I tweeted for "#gdcr12" then @jbrains from Canada respond me quickly! It was really quicker response than I expected! It was very helpful. 


Thanks to @jbrains and @haradakiro, I found the video that introduce "Verbs instead of Nouns". Byt there isn't much information about that :( I don't understand what happens with that activity yet.

Conclusion

In this entry, I introduced coderetreat and how to maximize your educational effectiveness. This event is well structured and worth to join. If you want to get an opportunity to learn basic skills of programming and testing, this is good way for you:) Please join next time!

Oct 8, 2012

Book review: Test Driven Development for Embedded C

I wrote Japanese article to introduce “Test Driven Development for Embedded C” for embedded software developers in Japan last month. This entry is English version of it.

----------

As you can see with the title, this is the book about Test Driven Development for embedded software with C language. The author, James Grenning, is training, coaching and consulting agile software development or TDD over the world. He is also the inventor of agile estimation technique “planning poker” and one of the authors of agile manifesto.

Must read book for embedded software developer


Recently Japanese TDD passionates like @t_wada are holding TDD boot camp in major cities of Japan. This is an event for TDD beginners to have an exercise of TDD. People get together at one place, make pair for exercise and do TDD with specific problems.

Thanks to them, we can have more chance to exercise TDD and people are becoming to discuss practical topic about TDD on their blog or social media. TDD is not majority in the industry yet but I am feeling TDD is becoming common technique for us.

On the other hand, most of embedded software are left out of boom of TDD boot camp. They think that they have nothing is to do with TDD because every article on book or blog is written about enterprise or web system. They are things on other planets.

This is a book for you, embedded software developers :) This book deals with typical example of embedded software and C/C++ testing framework and explain how to do TDD with very tiny step of carefully. It also can be good textbook for module design of C code.

Why embedded software developer need TDD?


Embedded software developer might think why they need TDD. The author answer the question in the chapter 5 “Embedded TDD Strategy” of the book. He explain the we can solve “the target hardware bottleneck” problem, which is common for embedded software development.

The target hardware bottleneck is a problem that target hardware could be a bottleneck disturbs software testing. Generically, target hardware is different from host computer that is used to develop software. And we can have these situation:
  • The problems leads to delay or increasing of working hour for software testing
    • Target hardware are not ready till the end of project
    • Target hardware is expensive and we can’t prepare enough number of target hardware 
    • It takes long time to build and upload software to target hardware 
  • The problems leads to difficulties to find bugs
    • It is difficult to identify where bugs are because the target hardware also have bugs in the beginning
    • Compiler for target hardware is different from one for host computer. Then we find unintentional behavior of software on the target hardware
To solve the target hardware bottleneck problem, the author recommend these approaches:
  • Ensure quality of software by TDD on host computer before testing on the target hardware
  • Do same tests on both of host computer and target hardware to find bug that are happend because of different between them.

And the author recommends TDD cycle for embedded software development as follows:


The book focuses on the stage 1 on the cycle. It doesn’t explain stage 2 to 5 in detail but you can find more information about step 5 on the author’s paper (PDF) “Scenario Testing with Executable Use Cases”.

I also write this cycle on my blog entry.

How is the book organized


The book consisted of three part.

In the first part “Test Driven Development”, the author introduces the process of TDD when we develop LED device driver. He also introduces why embedded software developer need TDD, test cycle including TDD and testing framework for C, Unity and CppUTest.

The second part is about technique to replace dependant module to test with C. It is very difficult to replace module with C, the only ways we can do are link substitution, preprocessor substitution and function pointer substitution. It also explains C++ mocking library “CppUMock” to test complex interaction with dependent module.

In the third part “Design and Continuous Improvement”, knowledge and technique to improve design continuously such as SOLID principle, test for legacy code and test patterns are introduced. If you are not familiar with object oriented design and programming, it is very difficult to understand. You need to read the books about object oriented design and programming first.

Please refer to the full table of contents on the official site.

How to read the book


For those who wants to know characteristics of TDD for embedded software


When I introduce the book to my coworker and he asked me “What is the difference between TDD for embedded and the others?” I think that basic points are same. For example, there is no difference between dependency to module and dependency to hardware.

I think that the most biggest difference is language constraint. Comparing to object oriented language, you need more technique to make test doubles, which is module to replace dependent module. In order to understand the technique, please refer to the chapter 7 “Introducing Test Doubles”, the chapter 8 “Spying on the Production Code” and the chapter 9 “Runtime-Bound Test Doubles”.

On the other hand, there is special bonus for embedded software developer. As I wrote before, we can solve the hardware bottleneck problem. Please refer to “Benefit for Embedded” at the chapter 1 and the chapter 5 “Embedded TDD Strategy”.

For those who wants to try TDD with example


To put TDD in practice, you need not only knowledge but technique. You must acquire technique by doing exercise. You can read the process to test and refactor your code for example of LED device driver in the chapter 3 “Starting a C Module” and the chapter 4 “Testing Your Way to Done”.  Try them.

Example in the chapter 3 and 4 is quite simple. You need test doubles in actual development. You can read about test doubles in the chapter 7 ”Introducing Test Doubles”, the chapter 8 ”Spying on the Production Code” and the chapter 9 “Runtime-Bound Test Doubles”.

For those who wants to know better C module design


TDD covers not only design and implement activity but also continuous improvement to better design by refactoring. You need to know what is better design to improve design of your software.

The chapter 11 “SOLID, Flexible and Testable Designs” introduces better design principles and implementation with C. You can understand how to design low-coupling module design with C.

There is also explanation to eliminate piles of if / switch-case statements by implementing polymorphism in the object oriented design concept with C. The code is tricky and it is very difficult to understand if you don’t understand object oriented design. In the case, you need to read object oriented software design book such as “Agile Software Development” first.


How Japanese readers say about the book


In conclusion, I introduce comments from the members of “Test Driven Development for Embedded C” studying group.

  • It is very helpful to understand how TDD master think and do because every tiny step and design decisions are written at the beginning of the book.  
  • I read the book and solve some exercises, then I could understand basic rhythm of TDD. 
  • I was wondering how to apply object oriented design to C code before I read this book. Thanks to the book, I understood how to do it.
  • I think that it is very difficult to understand the book at first if the readers understand object oriented design and test. Example of C code is not enough for beginners.
  • This book is very good as index of modern software testing. It includes TDD, test for legacy code, SOLID principle and refactoring, xUnit Test Patterns. Every embedded software developer should read this!