Problem

This library has Javadocs and now they can be compiled correctly ( #15 ) but they are not fully formatted based on general rules like this (e.g., some comments for methods don't start with third-person singular verbs).

What should we do

Let's discuss the rules and summarize them as a wiki or something like that.

I already created a dashboard on Travis, so I'll create .travis.yml later.

I tried to make javados according to README but the following command made many errors.

./gradlew javadoc

なにが必要で何が必要でないかちゃんと考える

I think LineSensor (here) is too specific name for the sensor and propose to replace the name with LightSensor.

Problem statement

Our repository is so big that it takes us a long time to clone. I briefly checked the cause (see this article for more information) and it may be the history of design materials.

Proposal

I'd like to propose to delete the history of design materials. They seem not not be updated and I think JavaDocs can do the role.

I will use the following command to delete them.

git filter-branch --index-filter "git rm -r --cached --ignore-unmatch ${target}" -- --all

Discussion

If you say it is okay, I will do that.

Problem statement

Currently we do not have mock communicator;
users of this library cannot use this without implementing concrete communication means.

For instance, drive cannot run program-execution on an Android emulator because Android emulators do not have the bluetooth function.
For this purpose, a mocking communicator is needed.

Proposal

I'd like to explain my thoughts of the means to resolve this.
I've implemented one class and one interface; MockCommunicator and MachineBackend.

MockCommunicator is a very simple communicator implementation:

• It has a reference of MachineBackend
• It passes input of ICommunicator#write to MachineBackend#write
• It calls MachineBackend#read and returns its return values.

MachineBackend is an interface for concrete classes of this; typical implementations are NxtBackend, Ev3Backend, and PileBackend.
These concrete classes should be able to:

• receive input of write function
• send output via read function according to the request (the argument)
• make state-transition by functions
  (e.g., NxtBackend#setMotor can change its internal state of motors)
• record history of operations

Conclusion

What do you think? Does my proposal make sense?
If you have any questions and opinions particularly for the structure of these classes,
feel free to leave a comment

As @amiq11 suggested in the mailing list, I propose to use CI for auto deploy.

1. We should do the following 3 steps (testing/packaging/launching) AUTOMATICALLY
2. The triggers of them are different
   a. testing occurs after pushing any change [DONE]
   b. packaging occurs after merging (develop -> master)
   c. launching occurs after making a release branch

As for this branch, launching means making a release and 2.b and 2.c can be done at once?