Robots - Robocup2013

Last weekend I went to the Robots event Robocup 2013 in the city Eindhoven, in the Netherlands. I went there together with my wife and 3 kids and it was a bit fun. It was more fun for the participants of the event. There were participants from about 40 countries, including Turkey, Iran, China and so on... As a visitor you can only see the robots from a distance on a stand. So finally it wasn't more than watching to a bunch of robots who try to score with a colored ball. There were different leagues, categorized from small simple robots to artificially intelligent robots.

The more interesting robots are those humanoid robots, these robots look like humans, or they try to be.
Also there's some interaction, that makes a robot always interesting, especially for the kids. We saw the famous autonomous robot Asimo too, but it was very crowded and couldn't see much, so it wasn't a great success, but at least we saw something.

If you see how much research, effort and technology it was needed to build a robot like Asimo, how difficult and knowledge is needed to build a real human? That's why I believe in God as our creator and that there's a reason why we we're built.

I really hope the kids like it and that they're interested in building a robot too :-) Who knows, someday I'll post a robot built with my family.

Java - Mail

How to send mail from Java sourcecode?
First you need to download the library mail.jar from oracle and add it to your Java project.
You can get it on the link below:
http://www.oracle.com/technetwork/java/index-138643.html

Than try out this code:
final String username = "username@gmail.com";
final String password = "password";

Properties props = new Properties();
props.put("mail.smtp.auth", "true");
props.put("mail.smtp.starttls.enable", "true");
props.put("mail.smtp.host", "smtp.gmail.com");
props.put("mail.smtp.port", "587");

Session session = Session.getInstance(props,
  new javax.mail.Authenticator() {
    protected PasswordAuthentication getPasswordAuthentication() {
        return new PasswordAuthentication(username, password);
    }
  });

try {

    Message message = new MimeMessage(session);
    message.setFrom(new InternetAddress("from-email@gmail.com"));
    message.setRecipients(Message.RecipientType.TO,
        InternetAddress.parse("to-email@gmail.com"));
    message.setSubject("Testing Subject");
    message.setText("Dear Mail Crawler,"
        + "\n\n No spam to my email, please!");

    Transport.send(message);

    System.out.println("Done");

} catch (MessagingException e) {
    throw new RuntimeException(e);
}

It's quite easy and it should work, unless your firewall blocks it, in that case open the port 587.
This is working for GMail accounts, but it should work with other accounts too, with just a little modification in the code.
This example code is copied from mkyong's website:
http://www.mkyong.com/java/javamail-api-sending-email-via-gmail-smtp-example/comment-page-4/#comment-135038

Promising gadgets - Apple's Smartwatch vs. Google's Glass

Though smartwatches or smartglasses are not new, just like tablets before the iPads, they're still not a huge success. But Apple and Google are working hard to launch a new success device.

Apple, according to rumors on the internet, is working hard on a smartwatch, while Google is already demonstrating their smartglass called Glass. But which one will succeed?

Smartwatch
The advantage of a smartwatch is it's wearable as an ordinary watch. If you receive an sms or a whatsapp message,  you can simply read it from your watch. Of course, if you just want to know what time it is, use your watch. You can even check photos and other viewing stuff
The disadvantage is it has a small display, so entering a text using your fingers is not a good idea. Also it's not a good idea to take a picture with your watch.

To summarize a smartwatch we could list the advantages and disadvantages as follows:
Advantage:

• easily wearable
• coverable
• readable for messages and notifications
• viewable for photos
• see who's calling
• streaming video (or live video)

Disadvantage:

• small battery size
• small display size
• not useful for entering text
• not useful for taking pictures or recording videos
• not useful for calling session, like talking to your phone and using headphones connected to the smartphone.

Seeing these advantages and disadvantages we can make following conclusions, a smartwatch should :

• work as a client for a smartphone using bluetooth connection to communicate.
• have low energy consumption because of small battery capacity. It would be very annoying to charge your watch everyday.
• an api to write widgets for smartwatches.
• have a side trackpad for vertical scrolling, because of small display size, your finger will easily cover the display and thus not user friendly.
• copy UI from older gsm devices like the Ericsson G700. Cause these UIs were based on small display sizes.

Smartglass
The big advantage of smartglasses is you have your hands free while recording videos with an integrated camera. Because a smartglass is mounted on your head, it works also as a headset. The big disadvantage is, you have to wear a smartglass the whole day and not everybody likes to wear such a device that's not coverable.

To summarize a smartglass we could list the advantages and disadvantages as follows:
Advantage:

• easily wearable
• readable for messages and notifications
• viewable for photos
• see who's calling
• streaming video (or live video)

Disadvantage:

• small battery size
• not useful for entering text
• not coverable

Seeing these advantages and disadvantages we can make following conclusions, a smartglass should :

• work as a client for a smartphone using bluetooth connection to communicate.
• have low energy consumption because of small battery capacity. It would be very annoying to charge your smartglass everyday.
• an api to write widgets for smartglasses.
• have a side trackpad for scrolling.
• have a suitable UI. Cause it's not a touch based device (i.e. a smartphone).

My personal opnion
I think the smartwatch will be a success for normal people, because it's like a watch, but a smart one. Like there was a normal phone before, now you have a smart one. A glass is not an electronic device, wearing glasses is only for necessity (to be able to see better). So I think for the normal people, a Google's Glass won't be a huge success. However, it could be a success in the business industry or in the world of sport and games. For example, a referee of a soccer game could see real life video of an incident before taking real decision. Or in a hospital, a nurse could see a patient's dossier, take a quick picture and send it to the doctor. There are great possibilities with a smartglass, but I doubt it will be successful for the normal people.
My conclusion is, smartwatch will be successful for normal consumers and smartglass will be successful in the business industry.

Soccer - Best soccer player of the world

Every year the FIFA soccer organization announce the best player of the year, the so called Ballon d'Or. It's often Messi, Christiano Ronaldo, Ronaldinho, Iniesta, Xavi and so on... If you see the big names, it's not fair to elect just the attackers. An attacker is not a defender, a defender is not a keeper, so it's not fair that Messi is the best football player of the year. I mean, Messi would not be so great without Xavi or Iniesta around him.

To make a fair election, the award should be divided into different groups. For example:

• best keeper award
• best defender award
• best midfielder award
• best attacker award
• best free kick award
• etc...

Maybe you can add an award for the best player award from the public audience.
However, to me, Messi is NOT the best player of the world, he's the best attacker of the year.

In my opninion Diego Maradona is the best soccer player ever!

Android - When a process gets killed.

According to http://developer.android.com/guide/components/processes-and-threads.html,
the Android OS weighs the relative importance of processes to the user to determine which process is candidate for killing, if system resource (like memory) gets low.

For example, if a process has no visible activity running, it is than assumed to be less important to the user and so likely to get killed, when necessary. So depending on the state of components within a process, the OS makes a decision upon it to kill.

The theory is that Android OS tries to maintain a process as long as possible, but eventually needs to remove or kill old processes to reclaim system resource for a more important process. So the OS somehow holds a list of processes based on importance of components and the state of the components. And so a process with the lowest priority gets killed first and than next and next...

There seems to be 5 levels of importance:

1. Forground process

•     It hosts an Activity that the user is interacting with (the Activity's onResume() method
  has been called).
•     It hosts a Service that's bound to the activity that the user is interacting with.
•     It hosts a Service that's running "in the foreground"—the service has called startForeground().
•     It hosts a Service that's executing one of its lifecycle callbacks (onCreate(), onStart(), or onDestroy()).
•     It hosts a BroadcastReceiver that's executing its onReceive() method.

2. Visible process

•     It hosts an Activity that is not in the foreground, but is still visible to the user (its onPause() method has been called). This might occur, for example, if the foreground activity started a dialog, which allows the previous activity to be seen behind it.
•     It hosts a Service that's bound to a visible (or foreground) activity.

3. Service process

•     A process that is running a service that has been started with the startService() method and does not fall into either of the two higher categories. Although service processes are not directly tied to anything the user sees, they are generally doing things that the user cares about (such as playing music in the background or downloading data on the network), so the system keeps them running unless there's not enough memory to retain them along with all foreground and visible processes.

   
4. Background process

•     A process holding an activity that's not currently visible to the user (the activity's onStop() method has been called). These processes have no direct impact on the user experience, and the system can kill them at any time to reclaim memory for a foreground, visible, or service process. Usually there are many background processes running, so they are kept in an LRU (least recently used) list to ensure that the process with the activity that was most recently seen by the user is the last to be killed. If an activity implements its lifecycle methods correctly, and saves its current state, killing its process will not have a visible effect on the user experience, because when the user navigates back to the activity, the activity restores all of its visible state.

5. Empty process

•     A process that doesn't hold any active application components. The only reason to keep this kind of process alive is for caching purposes, to improve startup time the next time a component needs to run in it. The system often kills these processes in order to balance overall system resources between process caches and the underlying kernel caches.

   
But what if you want your service not to be killed by the OS, well there is a trick for that.
To do this, you need to call startForground() method of the Service. You have to pass a notification ID and a notification object. Like this:
startForeground(NOTIFICATION_ID, mNotification);
 
This tells the OS not to kill the service, though the OS will kill it in extreme situation. You can image that when you're listening to music, you don't want the OS to disrupt the music for some reason.

A quick Git tutorial part 3

Link to a well explained git tutorial
gitref.org

git remote
If you clone a project from another machine, Git automatically sets the remote machine as the origin of the project. So when you want to update with the latest updates of the project you simply do:
git pull

With 'git remote' you can list your remote aliases, so this also means you can add remote machines that has the same git repo:
git remote add alias url
 
This way you can push new changes to a specific machine by giving the remote alias argument, for example:
git push yozef

Of course, you can also remove the alias:
git remote rm yozef

To show the remote list with extra information:
git remote -v

You can change url of an existing alias:
git remote set-url origin git://some.remote.machine/repo.git

To remove untracked files and folders after hard reset:
git clean -f -d

A quick Git tutorial part 2

git rm
With 'git rm' we remove a file from the staging index AND from disk. So be careful if you don't want to remove it from disk! If you only want to remove a file from the staging index, you should use:
git rm --cached file

This will remove a file from the staging index and leaves the file on the disk. Sometimes you accidentally added a file you don't wish Git to track it. So the most simple procedure is to perform 'git rm --cached file', than add this file name in the .gitignore file and than finally commit. But what if you have like hundreds of files added in a folder you don't want Git to track them. For this, you can get them out of the staging index like this:
git rm --cached -r folder

Don't forget to add a line in .gitignore file to tell Git to ignore all the files in that particular folder, something like: sources/somefolder/*


git reset
With 'git reset' you actually reset your changes back to the original HEAD (the last commit revision before adding changes). Sometimes you don't know what happened and you get frustrated as everything seems to go wrong. In that case, your last action to the rescue is to go back to HEAD and everything gets wiped out. There is no way in turning back, so be careful.
With 'git reset --hard', the changes in the staging index will be undone and thus completely removed. It's the same as going back to the last commit and no changes are made yet. Notice that HEAD could also be a commit revision. If you want to go back to a previous commit, you could also do:
git reset --hard HEAD^
or
git reset --hard b45ac81

The latter brings you back to the commit with the first seven characters of the sha (in that case ' b45ac81').
If you want to go to a previous commit BUT you want the changes stay in de staging index, than you can do:
git reset --soft HEAD^

With the --soft argument, the changes stays in the staging index.


git stash
Suppose we were editing some files and suddenly a bugfix need to be done. We could create a new branch from the current branch and fix the problem or we can save our work on a stack to get back later. The latter one is called stashing. By performing 'git stash' all the edits will be saved on a stack and you get a message like:
Saved working directory and index state WIP on master: 56490c0 cool stuff with git
HEAD is now at 56490c0 cool stuff with git

You can do some more edits and save this on a stack too. To see what work we have save, we can list them with the following command:
git stash list
result:
stash@{0}: WIP on master: c761ca7 experimenting with git
stash@{1}: WIP on master: 56490c0 cool stuff with git

The top of the stack is 0 and the stack is a LIFO.
WIP could mean Work In Progress, seems logic to me, but it could mean something else.
The master means the master branch, so the message is quite clear.
Anyway, now we want to get the edits back we saved earlier, as we solved a bugfix, this is how we do:
git stash apply
This will get the 'changes' back where we left off. We could also use:
git stash pop
The difference is that the latter one will remove WIP from the stack, while the first one keeps the WIP on the stack. After putting back the saved WIP, we can remove it from the stack with:
git stash drop
This will remove a WIP from the top. If you want to remove them all, you could also issue the following command:
git stash clear


git commit --amend
Oops, you wrote a wrong message for a commit and you want to change that?
git commit --amend -m "my new message"


git cherry-pick
This commands can be useful if you want to add a commit from another branch to your master branch. You can imagine that while you're working on a separate branch, you already want to commit some of the work already done and not waiting until you finished your big changes on the separate branch.
We can do this by 'picking' a commit from another branch and 'insert' it in the master branch.
So suppose we are in a branch called 'test' and we've already done some commits and we're still busy doing some edits in some files. We can merge the last commit that's already done to the master branch. So we switch to the master branch:
git checkout master
Than we pick a commit, i.e. '93e8ab7', from the 'test' branch and insert it in the master branch like this:
git cherry-pick 93e8ab7

You can do this multiple times, but chances are you'll get conflicts if the same files will be committed again. To solve this, we 'git rebase' the branch on to the master branch. It's like making a custom branch compatible with the master branch. You will see that the commit hashes are changed after a rebase. From there on, you can switch to the master branch and merge the commits from your custom branch to the master.

To rebase, you go to your custom branch and do the following:
git rebase --onto master 1234abcde^
where 1234abcde^ is the commit from where you want to rebase to the master branch.
After that, you'll notice that commit sha's from 1234abcde to the last commit, will be changed, so it fits to the master branch. Now, if we switch back the master branch and do: git merge custombranch
Than all the changes will be merged to the master branch.
Play with it, cause it's a bit confusing and you better should avoid cherry-picking if not necessary.

git format-patch, git apply
When developing with a team on a project, there is often the case that you have one central source repository (based on Git) where the latest source codes maintains. It would be a mess if all developers of the team starts pushing the new codes and bugfixes. To keep the situation organized, there should be some kind of source code maintainer who checks the new codes and bugfixes before it updates the repository. What you get is developers are forced to send patches of codes to the maintainer and the maintainer checks whether it's ok or not, this way you get a controlled process of developing on a project with a team.
Well, to create a patch in Git, it's best to create a seperate branch and do your editing there. If you made a little fix, or added a new feature and you tested well, you finally create a patch, to do this you do as follows (assuming you're on a different branch):
git format-patch master
This means, make a patch from the difference between master branch and the current branch.
We could also do this:
git format-patch HEAD^^...HEAD
This means, make a patch from two previous commits ago to the last commit.(^  means previous).
We could also use commit revisions instead of HEADs.
Often you want to give a patch a name, so others have an idea what the patch is about:
git format-patch master --stdout > fix_bug_123.patch

On the other side, if you want to apply a patch in your master branch, it's just simply this (assuming you're on the master branch):
git apply fix_bug_123.patch

Understanding difference between cherry-pick and merge
When you have a custom branch to do some edits on it, you might have made multiple commits. So when you're satisfied with the final result, you want to merge it to the master branch. So you switch to the master branch and do 'git merge custombranch'. What happens is all the commits are copied to the master branch, you can see them with 'git log --oneline'. If you want to cherry-pick a commit, you actually want to copy the changes of one commit to your master branch (or whatever branch you are). So you get a new commit based on the 'changes' of your custombranch which is a different hash!
I'll add some images to get a better understanding, as there is a saying "a picture says more than thousand words".

git diff
To show what files have changed, 'git diff' shows the content of the changes, for example:
git diff
this will show the difference between the last commit and the added changes that are NOT added in the staging index
To show the changes in the staging index, do this:
git diff --cached
If you want to show both of the changes, meaning the changes in your working directory, do this:
git diff HEAD

To show the difference between two commits:
git diff HEAD^ HEAD
Note that the HEAD's could also be the sha's of the commits.