Barcamp

This event would also be my first barcamp,  so I was pretty excited about that too. A barcamp is a free, user-generated unconference by means of  open, particapatory workshop-events, whose content is provided by the participants themselves. So, you can summarize this event as an unplanned geek gathering. Hey, if you know most participants only by their Twitter names … But what an experience that barcamp was! I love the small scale. I adore the interactivity. Energizing! A big thanks goes to the sponsors for the first class venue, catering, etc; to the organizers @emich, @steffest, @kodel and @janosizoltan for … well, organizing this event; and to all the speakers for sharing their experience and knowledge.

State of the mobile development art

Now off to mobile apps. Well, this subtitle says it all. That’s what I seem to have learned at #mcbxl. Development for mobile platforms still seems more of an art than craftsmenship. Yes, for mobile apps you have a totally different target audience and medium, so, yes, you should therefore completely realign your apps. This is what @kodel also explains in his presentation on Mobile Interaction Models. But, as proven by @Steffest’s geek’o'tar and his presentation on cross-device development, while a fantastic exploit, it makes one wonder whether the mobile devices are becoming to mobile development what the browsers are to web development: a testing nightmare. The mobile devices apparently have even more variability in features than browsers have bugs. @gregone shares his experiences during his talk on Designing for Touch Screens.

Largest common denominator for mobile applications?

The cases presented at #mcbxl, have fairly specific requirements. Indeed, not everyone wants to write his own keyboard application, isn’t it? However, MobileCamp Brussels wasn’t too clear about what features cross-platform development tools like Titanium offer and up to what point  mobile web applications can take us. @kodel explicitly mentions to stick with native apps for now, forcing you to choose your deployment platform. Hence, he rightfully says to very carefully choose, depending on your audience!

Or limitless possibilities of the mobile devices?

The reason to go native? Remember that a good mobile app takes the user’s context into account for the services offered. Therefore access to the full features of the mobile device are most likely a key requirement. Hence, the need (for now) to choose for native applications … to fully exploit all possibilities of those devices, only limited by our own creativity.

TIY = Try It Yourself

As with everything in technology, you can only thoroughly make up you mind, after you Tried It Yourself. Mobile web, cross-platform or native, MobileCamp Brussels certainly stung my desire to experiment myself. I’ll be rigging my mobile development environment pretty soon.

So please check back once and a while if you are interested to read about my findings. On the other hand, If you yourself have some ideas or experiences to share, please do not hesitate to leave a comment!

I think this is an excellent reference manual for anyone interested in a good overview on Scrum. Even a document  to keep at hand when working with Scrum on a project.

Premise

The premise they start with is that the design of any system is an accident that kicks in at conception. Hence, maximizing the opportunities to make that accidents happen is the key for (product) innovation.

Agility

Thereto, the author(s) define procedures and practices on how to integrate design in your iterative product life cycle. D3 makes the clear distinction between the management, engineering and design aspects of product development. Most current agile practices focus on the former aspects, whereas D3 introduces the latter by integrating design games into the project iteration, nl. at the start of the sprints, where the design games can provide input to the product backlogs.

Design Games

D3 turns the design practices into set of games, which brings different sets of people, skills and experiences together to make design decisions in a collaborative way. D3 describes 11 different design games, which are grouped into five different categories: Startup, Understand, Question, Design and Experience.

But first and foremost, D3 is about focusing on the solution and not the problem. D3  can be as simple as the hilarious example laid out in their blog.

I4

D3 defines 4 fundamental elements of good design:

• Innovation is larger level breakthrough in solving the indented problem
• Interaction is about how software or products behave with the users
• Information is how you arrange the different elements on the screen
• Intelligence focus on little things which can change the usability of an application.

In this way, D3 tries to bring design to the higher level of the solution space, whereas design used to remain at the product’s code and/or architecture level. The solution is the boundary where the product ends and thus where you as a solution builder can have impact. The higher levels of business and life on the other hand need to be impacted by other means.

Design Cube

D3 also recognizes that no process can guarantee a better design. Creating the right environment with the right set of people is the only way to bring innovation and design. Guidelines to this are laid out in the Design Cube, which defines the people, culture and environment aspects which can greatly contribute to build an innovative organization.

Conclusion

The ideas laid out in the D3 approach seem to be very viable. However, they have to be tested into practice to prove if they do bring enough value to the solution development in the form of product innovation. Most certainly, more practical guidelines, best practices, procedures and tools will have to be defined.

I do have some projects on my radar that might be helped by incorporating the ideas of D3. But in the mean time, does anyone have any practical experience with the D3 or other principles on entailing product innovation in solution development?

One of the major decisions to make when designing a ReST interface, would of course be data representation. Numerous options present themselves here, but after some digging and reading, the Atom Syndication Format combined with XML can be a universal data exchange envelope. especially when combined with some extensions like e.g. OpenSearch to support paging and searching. Atom’s extensive use of links with relation attributes, amongst others, make it a natural fit to ReST. Again, great libraries exist to ease the development of such Atom feeds, that even support the needed extendibility for the data envelope. These libraries even integrate nicely with the aforementioned technologies for ReST development.

The most renown use of Atom with XML for ReSTful service data representation would of course be the Google Data Protocol. However, when applying its philosophy to our own ReSTful services using various combinations of development libraries, implementation felt difficult every time, even awkward. At some point, I even considered re-implementing Atom libraries to support the needed extendibility of the generated feeds. Something smelt fishy!

Doing some more research, I came across articles from Atom authorities on how to (Ellias Torres) and how not to (James M. Snell, Rob Yates) extend Atom feeds. They also express their views on GData (Joe Gregorio, Clinton DeWitt).

I got my Aha Erlebnis this week when those guys pointed out where most extensions of Atom go wrong. There is a clear distinction between the data and the envelope. You can extend both, but for different reasons.

To support e.g. OpenSearch, you have to extend the envelope, because you want more intelligent data producing servers and data consuming clients. In developing ReST services, this type of extensions is more static as you will provide the extended envelope information with e.g. the search data, in every feed. So, e.g. you’ll super-class your micro-framework to support this extension once and for all.

On the other hand however, to transport your data, you have to extend you feeds at the data transport layer, which are the entries in Atom parlance. You’ll provide a representation for every entity you whish to ship, that you wrap in an Atom entry as its content. Hence, this wrapping will be a lot more dynamic in your system.

Applying above insights using different development libraries, the pieces of the puzzle fell into place as all libraries supported envisioned feed layouts very naturally. So I ended up choosing those libraries that supported my developments the best, which would of course be POJO style.

As being distributed, large scale platforms, the Hadoop and HBase projects mainly focus on *nix environments for production installations. However, being developed in Java, both projects are fully portable across platforms and, hence, also to the Windows operating system. For ease of development the projects rely on Cygwin to have a *nix-like environment on Windows to run the shell scripts.

Purpose

This document explains the intricacies of running HBase on Windows using Cygwin as an all-in-one single-node installation for testing and development. The HBase Overview and QuickStart guides on the other hand go a long way in explaning how to setup HBase in more complex deployment scenario’s.

Installation

For running HBase on Windows, 3 technologies are required: Java, Cygwin and SSH. The following paragraphs detail the installation of each of the aforementioned technologies.

Java

HBase depends on the Java Platform, Standard Edition, 6 Release. So the target system has to be provided with at least the Java Runtime Environment (JRE); however if the system will also be used for development, the Jave Development Kit (JDK) is preferred. You can download the latest versions for both from Sun’s download page. Installation is a simple GUI wizard that guides you through the process.

Cygwin

Cygwin is probably the oddest technology in this solution stack. It provides a dynamic link library that emulates most of a *nix environment on Windows. On top of that a whole bunch of the most common *nix tools are supplied. Combined, the DLL with the tools form a very *nix-alike environment on Windows.

For installation, Cygwin provides the setup.exe utility that tracks the versions of all installed components on the target system and provides the mechanism for installing or updating everything from the mirror sites of Cygwin.

To support installation, the setup.exe utility uses 2 directories on the target system. The Root directory for Cygwin (defaults to C:\cygwin) which will become / within the eventual Cygwin installation; and the Local Package directory (e.g. C:\cygsetup that is the cache where setup.exe stores the packages before they are installed. The cache must not be the same folder as the Cygwin root.

Perform following steps to install Cygwin, which are elaboratly detailed in the 2nd chapter of the Cygwin User’s Guide:

1. Make sure you have Administrator privileges on the target system.
2. Choose and create you Root and Local Package directories. A good suggestion is to use C:\cygwin\root and C:\cygwin\setup folders.
3. Download the setup.exe utility and save it to the Local Package directory.
4. Run the setup.exe utility,
   1. Choose the Install from Internet option,
   2. Choose your Root and Local Package folders
   3. and select an appropriate mirror.
   4. Don’t select any additional packages yet, as we only want to install Cygwin for now.
   5. Wait for download and install
   6. Finish the installation
5. Optionally, you can now also add a shortcut to your Start menu pointing to the setup.exe utility in the Local Package folder.
6. Add CYGWIN_HOME system-wide environment variable that points to your Root directory.
7. Add %CYGWIN_HOME%\bin to the end of your PATH environment variable.
8. Reboot the sytem after making changes to the environment variables otherwise the OS will not be able to find the Cygwin utilities.
9. Test your installation by running your freshly created shortcuts or the Cygwin.bat command in the Root folder. You should end up in a terminal window that is running a Bash shell. Test the shell by issuing following commands:
   1. cd / should take you to thr Root directory in Cygwin;
   2. the LS commands that should list all files and folders in the current directory.
   3. Use the exit command to end the terminal.
10. When needed, to uninstall Cygwin you can simply delete the Root and Local Package directory, and the shortcuts that were created during installation.

SSH

HBase (and Hadoop) rely on SSH for interprocess/-node communication and launching remote commands. SSH will be provisioned on the target system via Cygwin, which supports running Cygwin programs as Windows services!

1. Rerun the setup.exe utility.
2. Leave all parameters as is, skipping through the wizard using the Next button until the Select Packages panel is shown.
3. Maximize the window and click the View button to toggle to the list view, which is ordered alfabetically on Package, making it easier to find the packages we’ll need.
4. Select the following packages by clicking the status word (normally Skip) so it’s marked for installation. Use the Next button to download and install the packages.
   1. OpenSSH
   2. tcp_wrappers
   3. diffutils
   4. zlib
5. Wait for the install to complete and finish the installation.

HBase

Download the latest release of HBase from the website. As the HBase distributable is just a zipped archive, installation is as simple as unpacking the archive so it ends up in its final installation directory. Notice that HBase has to be installed in Cygwin and a good directory suggestion is to use /usr/local/ (or [Root directory]\usr\local in Windows slang). You should end up with a /usr/local/hbase-<version> installation in Cygwin.

This finishes installation. We go on with the configuration.

Configuration

There are 3 parts left to configure: Java, SSH and HBase itself. Following paragraphs explain eacht topic in detail.

Java

One important thing to remember in shell scripting in general (i.e. *nix and Windows) is that managing, manipulating and assembling path names that contains spaces can be very hard, due to the need to escape and quote those characters and strings. So we try to stay away from spaces in path names. *nix environments can help us out here very easily by using symbolic links.

1. Create a link in /usr/local to the Java home directory by using the following command and substituting the name of your chosen Java environment:

   LN -s /cygdrive/c/Program\ Files/Java/<jre name> /usr/local/<jre name>

2. Test your java installation by changing directories to your Java folder CD /usr/local/<jre name> and issueing the command ./bin/java -version. This should output your version of the chosen JRE.

SSH

Configuring SSH is quite elaborate, but primarily a question of launching it by default as a Windows service.

1. On Windows Vista and above make sure you run the Cygwin shell with elevated privileges, by right-clicking on the shortcut an using Run as Administrator.
2. First of all, we have to make sure the rights on some crucial files are correct. Use the commands underneath. You can verify all rights by using the LS -L command on the different files. Also, notice the auto-completion feature in the shell using <TAB> is extremely handy in these situations.
   1. chmod +r /etc/passwd to make the passwords file readable for all
   2. chmod u+w /etc/passwd to make the passwords file writable for the owner
   3. chmod +r /etc/group to make the groups file readable for all
   1. chmod u+w /etc/group to make the groups file writable for the owner
   1. chmod 755 /var to make the var folder writable to owner and readable and executable to all
3. Edit the /etc/hosts.allow file using your favorite editor (why not VI in the shell!) and make sure the following two lines are in there before the PARANOID line:
   1. ALL : localhost 127.0.0.1/32 : allow
   2. ALL : [::1]/128 : allow
4. Next we have to configure SSH by using the script ssh-host-config
   1. If this script asks to overwrite an existing /etc/ssh_config, answer yes.
   2. If this script asks to overwrite an existing /etc/sshd_config, answer yes.
   3. If this script asks to use privilege separation, answer yes.
   4. If this script asks to install sshd as a service, answer yes. Make sure you started your shell as Adminstrator!
   5. If this script asks for the CYGWIN value, just <enter> as the default is ntsec.
   6. If this script asks to create the sshd account, answer yes.
   7. If this script asks to use a different user name as service account, answer no as the default will suffice.
   8. If this script asks to create the cyg_server account, answer yes. Enter a password for the account.
5. Start the SSH service using net start sshd or cygrunsrv --start sshd. Notice that cygrunsrv is the utility that make the process run as a Windows service.
6. Confirm that you see a message stating that the CYGWIN sshd service  was started succesfully.
7. Harmonize Windows and Cygwin user account by using the commands:
   1. mkpasswd -cl > /etc/passwd
   2. mkgroup --local > /etc/group
8. Test the installation of SSH:
   1. Open a new Cygwin terminal
   2. Use the command whoami to verify your userID
   3. Issue an ssh localhost to connect to the system itself
      1. Answer yes when presented with the server's fingerprint
      2. Issue your password when prompted
      3. test a few commands in the remote session
      4. The exit command should take you back to your first shell in Cygwin
   4. Exit should terminate the Cygwin shell.

HBase

If all previous configruration is working properly, we just need some tinkering at the HBase config files to properly resolve on Windows/Cygwin. All files and paths referenced here start from the HBase [installation directory] as working directory.

1. HBase uses the ./conf/hbase-env.sh to configure its dependencies on the runtime environment. Copy and uncomment following lines just underneath their original, change them to fit your environemnt. They should read something like:
   1. export JAVA_HOME=/usr/local/<jre name>
   2. export HBASE_IDENT_STRING=$HOSTNAME as this most likely does not inlcude spaces.
2. HBase uses the hbase-default.xml file for configuration. Some properties do not resolve to existing directories because the JVM runs on Windows. This is the major issue to keep in mind when working with Cygwin: within the shell all paths are *nix-alike, hence relative to the root /. However, every parameter that is to be consumed within the windows processes themself, need to be Windows settings, hence C:\-alike. Change following propeties in the configuration file, adjusting paths where necessary to conform with your own installation:
   1. hbase.rootdir must read e.g. file:///C:/cygwin/root/tmp/hbase/data
   2. hbase.tmp.dir must read C:/cygwin/root/tmp/hbase/tmp
   3. hbase.zookeeper.quorum must read 127.0.0.1 because for some reason localhost doesn't seem to resolve properly on Cygwin.
3. Make sure the configured hbase.rootdir and hbase.tmp.dir directories exist and have the proper rights set up e.g. by issuing a chmod 777 on them.

Testing

This should conclude the installation and configuration of HBase on Windows using Cygwin. So it's time to test it.

1. Start a Cygwin terminal, if you haven't already.
2. Change directory to HBase installation using CD /usr/local/hbase-<version>, preferably using auto-completion.
3. Start HBase using the command ./bin/start-hbase.sh
   1. When prompted to accept the SSH fingerprint, answer yes.
   2. When prompted, provide your password. Maybe multiple times.
   3. When the command completes, the HBase server should have started.
   4. However, to be absolutely certain, check the logs in the ./logs directory for any exceptions.
4. Next we start the HBase shell using the command ./bin/hbase shell
   1. Create a simple table using command create 'test', 'data'
   2. Verify the table exists using the command list
   3. Insert data into the table using e.g.

      put 'test', 'row1', 'data:1', 'value1'
      put 'test', 'row2', 'data:2', 'value2'
      put 'test', 'row3', 'data:3', 'value3'

   4. List all rows in the table using the command scan 'test' that should list all the rows previously inserted. Notice how 3 new columns where added without changing the schema!
   5. Finally we get rid of the table by issuing disable 'test' followed by drop 'test' and verified by list which should give an empty listing.
   6. Leave the shell by exit
5. To stop the HBase server issue the ./bin/stop-hbase.sh command. And wait for it to complete!!! Killing the process might corrupt your data on disk.
6. In case of problems,
   1. verify the HBase logs in the ./logs directory.
   2. Try to fix the problem
   3. Get help on the forums or IRC (#hbase@freenode.net). People are very active and keen to help out!
   4. Stopr, restart and retest the server.

Conclusion

Now your HBase server is running, start coding and build that next killer app on this particular, but scalable datastore!