Friday, August 26, 2011

Being agile and technical masturbation

I suggest a great term for those who cannot do without making it more complex than it should be: "technical masturbation". Some people may choose to call it "Over engineering"; however I choose technical masturbation since what they do is satisfy themselves.

This occurs most when people try to make a software too flexible then it should be. Those keep saying they may need to serve in an another format; serve in a different platform/technology; but these never happen.

Requirements and technology changes rapidly; it is our job to be synchronized with them. Business wants development teams to be agile. For this reason, we have been populated our code base with:

  •  interfaces (that has only one implementation and will never change),
  •  design patterns where we do not need them actually (strategy pattern with one strategy)
  •  aspects where actually a simple web filter was enough (debug became harder; great)
  •  targeting high unit test ratios caused unit tests testing only order of method calls with mock objects
  •  useless documents
  •  too many configuration files (that never change)
  •  pages of spring beans; every developer will debug again and again

In order to be agile for business requirements; we should not forget two things:

  •  the language should be agile in nature (see few words on ruby)
  •  the team should be agile which is more important. To make team agile we need to be sure that the code is easily read; understandable by new joiners (where in IT world; recruitment occur more). Sometime it is better to do copy&paste code then a series of design patterns if team says replace all is easier. (and I doubt if it will ever needed.)

Requirements and technology changes rapidly; perhaps a design / software done five years ago is nearly dead and you think it is time to build it again with different technologies. Follow technology and use it; but do not lost yourself inside it; do not be obsess with being too flexible, technology and patterns. Check your old projects; don't you have a great new plan/design for those?


Friday, August 19, 2011

Ruby; Language for Humans

I have been developing with java more than 8 years. I have had implemented many technologies with ejb, spring, struts, hibernate etc.. you name it; I have faced with many technologies in java domain.

It has been few months I have been working with ruby (and ruby on rails). I am surprised how everything is easy to do. I witnessed whoever start programming with Ruby first resisted with some enterprise buzz words but then all ended with same decision: "I will never touch to java". :)

It is really much much easier to achieve what is on your mind with ruby. Once you get used to flexibility of dynamic language; open classes and many other features (once you achieve to change your mindset) it will be very hard for you to go back to java domain.

It is not easy to start a new language; new set of frameworks and you may think that you are throwing away the experience of years with switching to ruby. But calm down; it is fun; do not afraid. You will enjoy it while discovering how it is easy to achieve things. And experience is not lost; it will transform with time.

Of course every language has a place to fit. Java is structural and ruby is a dynamical language. They have both advantages and disadvantages. You can google them. However what I believe is; Ruby is the way to go. It helps me too much to solve problems much more easier. I definitely recommend you to check Ruby; but do not forget; a simple hello world is not enough; you must spend time and a project at least.

Also please check this graph; ratios of languages on github: http://4.bp.blogspot.com/_FsLa1cMTCWU/TGBlqQEs5yI/AAAAAAAAAXM/HkwNFJnohoI/s1600/top_10_github_languages_by_reps.png

Especially Ruby on Rails framework is very successful and I am believe it has a part for Ruby to get popularity. Do not afraid from the change :) http://www.changecycle.com/changecycle.htm

"Because things are the way they are, things will not stay the way they are."
-Bertolt Brecht

Thursday, July 28, 2011

Environment specific logback configuration

Here is an example for an environment specific logback configuration. Unless there is an environment variable with a value of "prd" or "stg", log level is set to debug; otherwise it is set to warn.

Wednesday, May 25, 2011

Chromatic Tuner Code for Samsung Bada on GitHub

I have had created an application called Chromatic Tuner which helps you to tune your instrument. However when I put the application on sale; I received some feedback that it was not very responsive. In fact I knew that however I had no time to improve it. See it in youtube.

Now I am offering it as free on Bada market (since customers are not happy) and I put all the code on github. If you are a new developer on Samsung Bada platform it may help you. Meanwhile it is the only application I have done for Bada; so note that I am not an expert in Bada platform:).

Github address is: https://github.com/yamanyar/Tuner-for-Samsung-Bada

Cheers,
Kaan

Friday, April 15, 2011

A pre-receive hook to check if comitter name and authentication name are equal

Sometimes developers forget to set their user name while committing with git. You may force them by controlling the committer name and the user name used with authentication system. (see gitolite installation.)

Following code also makes use of a ruby script called "geera" to send commit messages to jira issues, check format of commit message etc.

You may define a hook as shown below:

Gitolite - Gitweb Installation and Integration

What is Gitolite ?


Gitolite is used to authorize users to read/write to git repositories (or branched/tags..). Gitolite should be installed to server where apache2 (in our case) is installed to serve git repositories.


Here is an excerpt from pro git book (Please see Pro Git book for full article):


Git has started to become very popular in corporate environments, which tend to have some additional requirements in terms of access control. Gitolite was originally created to help with those requirements, but it turns out that it’s equally useful in the open source world: the Fedora Project controls access to their package management repositories (over 10,000 of them!) using gitolite, and this is probably the largest gitolite installation anywhere too.


Gitolite allows you to specify permissions not just by repository, but also by branch or tag names within each repository. That is, you can specify that certain people (or groups of people) can only push certain “refs” (branches or tags) but not others.


Installing Gitolite


Go to folder where apache2 is serving. For example on Ubuntu and Fedora this is generaly /var/www. If it is different on your server; replace directions according to it. Also perhaps location of "git-http-backend" is different in your system ("/usr/libexec/git-core/git-http-backend" is used in following lines.). You need to locate "git-http-backend" on your system and replace it as well. "git-http-backend" comes with "git" installation.


Run following commands: (Do not forget to replace /var/wwww and /usr/libexec/git-core/git-http-backend{color if they are different on your system)


It will be easier if you run these with a super-user (root) and then modify file/folder permissions according to you system. (For example you may want to change ownership of all /var/www to apache or www-data according to your system).


(This is summarized from Gitolite Docs)


cd /var/www
mkdir gitolite-home
export GITOLITE_HTTP_HOME
GITOLITE_HTTP_HOME=/var/www/gitolite-home
PATH=$PATH:$GITOLITE_HTTP_HOME/bin

cd gitolite-home
git clone https://github.com/sitaramc/gitolite.git gitolite-source

cd gitolite-source
GHH=$GITOLITE_HTTP_HOME
mkdir -p              $GHH/bin $GHH/share/gitolite/conf $GHH/share/gitolite/hooks
src/gl-system-install $GHH/bin $GHH/share/gitolite/conf $GHH/share/gitolite/hooks

$ENV{GIT_HTTP_BACKEND} = "/usr/libexec/git-core/git-http-backend";
    # or wherever you have that file; note: NO trailing slash
$ENV{PATH} .= ":$ENV{GITOLITE_HTTP_HOME}/bin";
    # note the ".=" here, not "="

#gitadmin is an user we determined. you can put there anything;
#however our future examples will depend on that.
gl-setup gitadmin

# your user name might be www-data or anything other depending on your system.
# The folder should be readable,writable and executable httpd. 
# This is not realated with gitolite installation.
chown -R apache.apache $GITOLITE_HTTP_HOME

Now we need to update apach2 configuration. It is up to you to put this configuration. In our tests we created a git.conf file and include it in httpd.conf (on some systems it is called apache2.conf):


Please note that if you used path different then /var/www in the directions mentioned before; you need to replace them here as well.


Config for gitolite that must be included in apache2 configuration:
SetEnv GIT_PROJECT_ROOT /var/www/gitolite-home/repositories
SetEnv GIT_HTTP_EXPORT_ALL
    # please see notes below on ssh+http access
ScriptAlias /git/ /var/www/gitolite-home/bin/gl-auth-command/
    # note trailing slash

SetEnv GITOLITE_HTTP_HOME /var/www/gitolite-home

<location /git>
    AuthType Basic
    AuthName "Private Git Access"
    Require valid-user
    AuthUserFile /path/to/some/passwdfile
</Location>

/path/to/some/passwdfile is a standard password file that is generated with htpasswd.

You must at least add an user for "gitadmin" (remember we had run gl-setup with that username before). Please note that this authentication system will be replaced by LDAP later on).


htpasswd -b -c /path/to/some/passwdfile gitadmin secret123
htpasswd -b /path/to/some/passwdfile kaan secret456

After restarting apache2 you should able to checkout from http with git clone http://user:password@server/git/reponame.git

This configuration will force user to login via http auth. mechanism and if user passes validation (enters correct password); his/her user name will be a cgi variable ($GL_USER) and it will be used by gitolite to determine permissions according to it's own config file.

You can immediately checkout *gitolite-admin.git*, change authorization settings (add new users to config; let users/groups new repositories/branches etc. see [Gitolite Configuration|http://progit.org/book/ch4-8.html] for details.), commit and push to activate/flush changes.

Please note that users in gitolite configuration must exists in http auth. mechanism (in our case htpasswd file, for future ldap).


Gitweb Installation and Gitolite Integration


This is pretty easy to setup .

First of all you need the gitweb source. You may already have it try to locate it on your system by command locate "*gitweb*" or clone it from git clone git://git.kernel.org/pub/scm/git/git.git. For ubuntu you can install it via synaptics.

When you locate "gitweb" copy it under "/var/www/gitweb". (Again this may change according to your system).

Include following lines in your apache configuration file. Again the exact file changes according to your system.

<virtualhost *:80>
ServerName gitserver
DocumentRoot /var/www/gitweb
<directory /var/www/gitweb>
Options ExecCGI +FollowSymLinks +SymLinksIfOwnerMatch
AllowOverride All
order allow,deny
Allow from all
AddHandler cgi-script cgi
DirectoryIndex gitweb.cgi
AuthType Basic
AuthName "Private Git Access"
Require valid-user
AuthUserFile /path/to/some/passwdfile
</Directory>
</VirtualHost>

With this setting gitweb uses the same http auth. mechanisim that gitolite uses. They both use "/path/to/some/passwdfile" htpasswd file. If you change httpd auth. (for example to ldap); you need to change both settings for gitolite and gitweb. Now we must ensure that after http auth., gitweb should only list and serve the repositories (or branches/tags) for the user logged in according to gitolite permissions configuration:


Find "gitweb.conf" config file and make sure that project root is showing correct repositories (the repositories where the gitolite is serving).:


Please note that there are two gitweb.conf files. One of them is coming with gitweb; this is what we are referring to now. The other one comes with gitolite installation and we refer it with full path "/var/www/gitolite-home/gitolite-source/contrib/gitweb/gitweb.conf". We will include this in gitweb.conf


$projectroot = "/var/www/gitolite-home/repositories"; 

At the end of same file you must include a configuration that exists in gilolite path (this was already there with gilolite installation). This include will make gitweb to serve repositories only visible to users who has permissions:


Last line of gitweb.conf

require "/var/www/gitolite-home/gitolite-source/contrib/gitweb/gitweb.conf"; 

And you must be sure that:


gl_home is showing right place.}
# HOME of the gitolite user
my $gl_home = $ENV{HOME} = "/var/www/gitolite-home"; 

Tuesday, February 1, 2011

Samsung Bada & Global Challenge

I had joined "Bada - Global Developer Challenge" and I was one of the Simulator Phase Winners and I would like to share my experiences with Bada.

The application I had developed was chromatic tuner. Watch it on youtube if you like.

What is Bada? Here is the answer from Samsung: "Samsung bada is a smartphone platform released in 2010. The word “bada” means “ocean” in Korean. Samsung Wave is the first bada-powered phone."

In other words Samsung Bada is something like Google's Android or Apple's iOS.

In Bada, you do your development in C++. I am a Java expert and I am used to do programming in clean world with conventions, no-pointers, no memory concerns. However in Bada, you have an excellent c++ api under Bada namespace with good documentation so it is not complicated after one or two hours. It is still not very clear as Android API but you must keep in mind that it is in C++ and you have the native power. So if you are a java developer, don’t worry, C++ syntax knowledge will be enough you to start development in Bada platform. I can not repeat same sentence for Symbian C++ development for example.

Unlike Google, Samsung does not force you to be in an allowed country to sell applications. And it does not require any fee like Google or Apple. Although Samsung does not require any fee; they do a good testing. My application rejected two times due to various bugs that I have never thought. However I am not the only guilty one on those bugs, the API might not be fully bugless yet (see here if you wonder my problem, may be I am the only guilty one). Another good issue is, as far as I know (correct me if i am wrong) Apple sends checks by mail to pay you. However Samsung does it by a bank transfer; which is cool if you think mail might be lost.

There were some problems with delivering of mobile phones on Global Challenge. For example I didn’t receive a mobile phone due to custom (duty) policies in my country. However I was waiting those to be handled by local Samsung branches but unfortunetly I was wrong. Samsung is not guilty of course; however my expectation for a world-wide company like Samsung was bigger: If they sell Samsung here, they can handle to let me have one.

I really enjoyed developing with Bada. Samsung has similar phones delivered with Android. Android and iPhone has a big market share. However I believe Bada will get bigger share If Samsung keeps supporting it as today.