Tuesday, August 28, 2012

Tags in git


Tag a release

Once one is happy with the code and the build, a given commit can be tagged with a proper release tag::

    $ git checkout release

    # Code changes, fixes, build, tests, etc.
    $ git commit -m"Release candidate complete"

    # To view the latest commit hash:
    $ git log
    commit 2e4a6e1a7cc3bf2298055937ab79f72fb58abf1f
    Author: Marco Massenzio
    Date:   Tue Aug 28 22:49:04 2012 -0700

            Release candidate complete

    # Tag it with the appropriate release number
    git tag -m"Rel. 0.6 RC3" rel_0.6rc3 2e4a6e1a

    # Push the commits to origin:
    $ git push origin release

    # The tag will be kept local to the repository, must be pushed too:
    $ git push origin rel_0.6rc3:refs/tags/rel_0.6rc3

When others pull from the remote origin repo, the tag will be pulled too.

Github

A nice feature of github is that it records the tags separately, and clicking on any of them will
cause a download of a 'clean' working directory into a ZIP file or tarball, reflecting the state of
the project at the exact point when the tagged commit was pushed.

Friday, March 23, 2012

Eclipse Juno has a new look!

Just downloaded the latest milestone release (M6) of Eclipse Juno (4.2) and I was quite amazed at finding out it has a brand new splashscreen, which, I must confess, quite rather like!




And Juno brand new UI looks really really neat!

Wednesday, January 18, 2012

Adding a new sudoer in Ubuntu

This is something I have to do from time to time, but not frequently enough that I manage to memorize it - but trivial enough that it annoys me to have to look it up every time.

Here's to future memory:
  1. create a new user `bob`
    sudo adduser bob
  2. check that the `admin` group is the one for the 'sudoers' on the machine
    sudo cat /etc/sudoers
  3. add Bob to the admin group
    sudo addgroup bob admin
done!

We've moved!
Please read the rest of this post on codetrips.com

Tuesday, September 13, 2011

CDT Indexer & Google gtest framework

As I mentioned in a previous post of mine, Eclipse's CDT (C++ Development Tools) has a few issues when used with Google C++ Unit Testing framework, but it generally works.

Where CDT really gets confused is around the 'exclusion' of the unit tests for the non-test build configurations: as mentioned in my other post, one needs to add the G-Test's include/ directory to include search path (-I).

This blog has now been moved to codetrips.com: read the rest of this post here.

Tuesday, September 6, 2011

Android ADK and mbed.org



The 'mbed kit' just landed on my doorstep, sent courtesy of the good guys at ARM (Cambridge, UK).
This gadget supports the Android ADK (http://mbed.org/cookbook/mbed-with-Android-ADK)
which is fully documented here and, to have an idea of the geeky-fun that can be had with these gizmos, I suggest you check out this video.
I fear that my weekends are likely gone for quite a while now....


Just as an example of what is possible, the following snippet will make the LEDs flash, as well as connect to a terminal on the host PC to use as stdout; this is a very basic adaption of the HelloWorld.cpp app, and some tutorials from mbed.org: the point being that it took me less than 30min to get going!

// AlertAvert.com (c) 2011. All rights reserved
//
// The code below has been adapted from tutorials on
// mbed.org - credits should go to ARM Ltd.
//
// Author: M. Massenzio (m.massenzio@gmail.com)

#include "mbed.h"

// USB out to the host PC - from a terminal window access
// using: screen /dev/ttyACM0
Serial pc(USBTX, USBRX); // tx, rx

// Board LEDs
DigitalOut myled(LED1);
DigitalOut yourled(LED2);

bool on = true;
void quit() {
  on = false;
}

void toggle(DigitalOut d1, DigitalOut d2) {
  d1 = !d1;
  d2 = !d2;
}

int main() {
  pc.printf("Starting LED flashing...\r\n");
  Timeout to;
  myled = !(yourled = 1);
  to.attach(&quit, 5);
  while(on) {
    toggle(myled, yourled);
    wait(0.2);
  }
  myled = yourled = 0;
  pc.printf("Exiting now\r\n");
}


And this is what came out of it:

Monday, August 22, 2011

Use a common Tag for all your activities' logging

It is pretty common for any non-trivial Android app to be composed of several Activities which together interact with the user for the furtherance of whatever is the objective of the app itself.


It is also pretty common, especially during the development phase, to have a need to emit logs so that one can check certain events happen when they are supposed to, and invariants, for example, are satisfied.


The Android ADT (Eclipse plugin) has a very nice feature in the form of the LogCat View that shows all the system logs, including those coming from your applications: as there may well be tens of apps running (and logging) at the same time (especially on a live device -- as to why you should use a device for your testing and debugging, you may want to read this) the LogCat enables one to 'filter in' a subset, based on a 'tag'.


The tag used by the LogCat is the value of the string used for the tag parameter in the Log.x() calls:
Log.d("myApp.tag", "All is going well");

It is pretty obvious that, in any given Activity, we would want a constant to use as the tag:
private static final String TAG = "myApp.tag";
but this has the drawback that we would have to either duplicate that same statment across all Activities (and, even worse, keep them all in sync if we decide, for whatever reason to change them) or resign ourselves to use different tags for different activities.


Alternatively, we could use a common 'Constants' class to keep, amongst others, a constant Tag:
public interface Constants {
  public static final String TAG = "myApp.tag";
  // other constants...
}

This is not very friendly, however, as every log statement (and there may well be hundreds in your code) would look something like:
Log(Constants.TAG, "All is going well");
it's only 10 extra characters, but multiply that for several hundrends, and you've a veritable case of carpal tunnel syndrome on your hands (well, ok...).

A much better option is to use Android's mechanism to store common application strings, which also gives the additional benefit that it's dead easy to change the tag in one full swoop, should that ever be necessary: in one of the XML files in the res/values/ directory, have a line of the form
myApp.tag
and in your code, you can do something like:

public class MyActivity extends Activity {
  public static String TAG; // note no 'final' here

  @Override
  public void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    TAG = getResources().getString(R.string.TAG);
    Log.d(TAG, "Starting User Preferences activity...");
    // other initialization follows...
  }
}

This can be done in each and every of your App's activities, and then you can easily create a new filtered view in LogCat so that you can see only your App's logs, from all the activities, also with the reassurance that, should ever want to change that, it's just a one minute edit of the XML file


Saturday, August 13, 2011

HTTP POST for Android (with a twist: Protocol Buffers)

One of this blog's most visited entries (ranking always around the Top 5 Google results for "HTTP POST" too) elaborated on how to send data across to a server from a J2ME Midlet.


I thought it was high time for bringing this into the new Century, and provide an update as to how to do this from an Android smartphone.
It turns out that (a) the code is relatively straightforward and (b) that there is not so much difference after all from writing the same code for a desktop client: credit for this ought to go to the Android Google team who have done such a superb job of adapting the J2SE API to the Android platform...

THIS BLOG HAS MOVED TO codetrips.com


Please read the rest of this post on codetrips.com