Rarejob lesson logs

December 23, 2012
And I took article discussion. Today we discussed about this article.http://online.wsj.com/article/SB10000872396390443675404578059311445951162.html

Discussion points are follows.
·What are possible problems that countries may encounter wh
en dealing with each other?
·How can people ensure harmony between nations with different cultures, values, or religions?

We usually have some problems with countries close to us. Japan has territory issues with China. Philippine has other issues with China.
I think that It is difficult to have harmony at political problem but we can do something at citizens level. Chinese people who have never been to Japan might think Japanese people are bad people but ones who live in Japan don't think like that because they knew what is reality. Reality is that most Japanese people are polite and kind. Once they visited Japan and knew reality, they will change his mind. Having chance to know each other is good way to cooperate each other.

December 23, 2012

I took TOEFL interview test for the first time. I was asked to hear following question, prepare answer in 15 minutes and answer for in 45 minutes. It is very hard.

"Some families think that having a pet is important to provide enjoyment to the members. Others think that a pet would only be a burden at home. Which opinion do you agree with and why? Give specific details and examples in your answer"

March 26, 2012
Total 13.5 hours. I used conversation material for intermediate level today.
In today's lesson, my tutor said that her mom loves the movie 'Hachiko the Akita dog' so they call her pet "Hachiko". That is nice.
I asked my tutor "What is your most favorite food?" Her answer is chocolate. Why do every girls like chocolate? I don't understand why because I don't eat it often.

March 18, 2012

Total 11.5 hours. I used conversation material for intermediate level today.

In today's lesson, we talked about my role in my family. It is to show my family outside of home. For example, I take them to overseas. I took them to Taiwan, Switzerland and Germany. Best city to visit is Zurich. I watched Italian opera with English subtitles. It was my first time to watch opera. So I was very impressed. My family is too.

March 17, 2012

Total 11.25 hours. I used conversation material for intermediate level today.

In English lesson, we talked about small family is better than big one. I don't think so. Big family is fun and you can learn social skill. You have to appeal to your parents in big family. That make you social person. In small family, you cannot get that experience.

But for my own family, I want to have small one. Raising many children costs very much in Tokyo. Two children are enough for me. My tutor has same opinion with me. She grew up in big family but she wants to have small family.

The second monthly meeting of the "Test-Driven Development for Embedded C" book club in Tokyo

The second meeting of "Test-DrivenDevelopment for Embedded C" book club in Tokyo took place on March 4th.

We read the three and fourth chapter

At this time, we read the third chapter "Starting C Module" and the fourth chapter "Testing Your Way to Done". We had first TDD session during these chapters. We wrote test code and product code for LED driver then we refactored both of them.

The third and fourth chapters are highlight of the first half of this book. If you start to read this book, I recommend you to try the example of these chapters by yourself.

There are sample codes on my github repository.

• Test code for LED driver
• LedDriverTest.c
• Product code for LED driver
• LedDriver.c
• LedDriver.h

Always make code stable

There are two very informative topics at this time. First one is to make code stable. Author describes TDD work like this:

And I saw this diagram and I found like these:

• There are two stable states of code, which are stable state that passed tests and one that don't pass.
• TDD doesn't make another state of code.

In the stable state that passes tests, there are not refactored code and refactored code. This topic is well known for TDD new comers.

The stable state that doesn't pass tests is a transient state. Compile error, link error, test failure. TDD makes this process obvious. TDD doesn't make unbalance state that passes tests but include incomplete implementation and mistakes.

You might think that you don't need to do such rigorous way. Of course, some people can implement perfect code at a time but most of us can't do it. We make mistakes. So we need way to find mistakes.

Do not care about performance too much at first but care about readability

Second topic is code readability. Here is informative description in the book.

don't let the performance factor outweigh improved design and readability unless there is proof the code is contributing to a specific performance problem.

Author doesn't mean that performance is not important. We had same opinion. When we deal with problem on performance, we have to find performance bottleneck with profiler. If you put emphasis on performance and write unreadable code while you don't know where bottleneck is, maintenance time increase and have bad effect on costs.

So here is better way:

• Considering a way to meet consider requirement at architecture design phase
• Finding performance bottleneck with profiler at the beginning of architecture implementation phase
• Refactoring code so that each module becomes more readable

We talked about own attempt

First topic is auto build and test with Eclipse. If you use this function, you can also do static analysis, code format and code coverage as follows. This is very easy.

Second topic is 'AdLint'. This is new open source static code analysis tool. I talked my plan to introduce own environment. I want to show demo next time.

Third topic is auto code formant with code formatting tool such as Artistic Style. You need to care when you use it on build process because it may make unintended code format. Manual execution may be better.

Fourth topic is code coverage tool. 'lcov' is good for gcc.

What's next?

Third meeting will take place on April. We will read the fifth chapter "Embedded TDD Strategy" and the sixth chapter "Yeah, but …".  First one is good to adopt TDD to embedded system development. Second one gives us hints to recommend TDD to other people. 

Is TDD one of the solutions for difficulty of concurrent development of software and hardware?

In my 5 year experience of embedded software engineer, I became to think concurrent development of software and hardware is the biggest risk of embedded systems. I thinks TDD is one of the solutions for the problem. So I held a book club of "Test Driven Development for Embedded C (Pragmatic Programmers)" in Tokyo. Here is my thought on how we fight with difficulty of  concurrent development of software and hardware.


Writing code for uncompleted hardware is so hard : (

General process of embedded software development is as follows:

1. Developing software on own computer
2. Debugging on an evaluation board
3. Testing on a target hardware

At the first step, we don't have the target hardware and have to write code for imaginary hardware that we have never seen. After we got the evaluation board, which is the second step, we try to debug on it to find bugs.

Most of engineers that I have met try to debugging on an evaluation board as quickly as possible, so they tend not to care about testability for unit test. As a result, we get high coupling code.

At the time, we have to advance the development with several risks as follows:

• Own computer, evaluation board and target hardware have a little bit different library and compiler.
• The evaluation board is bad in quality at the beginning of the development.
• There are many mistakes in logic of code
• Software engineer has to resolve underlying discrepancy in specification at the end of development.
• etc.

Problems occur someday. They make debugging time longer and distinguishing cause of bugs more difficult.

If we do agile software development for embedded software system, this will be a bottleneck.


Dual-Target Testing

For this problem, the author of "Test Driven Development for Embedded C (Pragmatic Programmers)" recommend hardware-independent software design and unit test on both of own computer and evaluation board from the beginning. This is called "Dual-Target Testing". If we do it from the beginning, we can eliminate bugs and make test easier.


What do we need for Dual-Target Tesing

At first, we need software design techniques to make software more testable. That is discussed in the books like "Test Driven Development: By Example" written by Kent-Beck or "Working Effectively with Legacy Code" written by Michael Feathers.

Second, we need cooperation with hardware engineers for low layer software development. For example, in the book of "Test-Driven Development for Embedded C ", there is a scene that software engineer and hardware engineer are discussing about design of interface between software and hardware so that software engineer can decide design of Test Double.


What "Test-Driven Development for Embedded C" is doing for this?

There are some code examples in my github. There is product code and test code for LED driver.

Key point of this example is a dependency injection at a constructor. Passing writing port address to constructor makes software independent with hardware. We can do unit test on both of own computer and the evaluation board.

This driver has writing port only. State of LED driver is stored at variable ledsImage once, then write to the port. This was an issue that software engineer and hardware engineer discussed in the book.

You might think that this example is quite simple and there are more difficult examples in real world. I think basic idea is the same as this example, which is interface design between software and hardware and low coupling software design against hardware and other software modules.

I will held the third monthly meeting of "Test Driven Development for Embedded C" book club in Tokyo and see this problem deeply : )