Friday, December 27, 2013

I am so tired of Unity

I am an avid Ubuntu user. It has been my primary OS since 2008 i.e for almost six years now. But I am now getting tired of Unity, not Ubuntu, just Unity. For those not familiar with the term, Unity is the desktop environment of Ubuntu. Ubuntu switched to Unity from GNOME a while ago when GNOME 3 was about to be released. I have read that Canonical did not agree with the direction GNOME was heading in and when they were not able to sort their differences with GNOME they decided to create their own desktop environment for Ubuntu and so Unity was created. But this is what I have read on internet and considering how reliable internet is, I am not sure what really happened but the fact remains that Ubuntu switched to Unity.

Unity has its own merits but it has made it difficult for me to perform day to day operations. For example whenever I have to run an app for which I don't have a launcher icon I have to click the home button and then type the app name for it to appear in the app list and then click on it. I don't like that. I also do not like that there is not button to minimize all windows. I also do not like the fact that every program has its menu in the top panel. When I have two windows open side by side and I need to use their menu, I have to first select the window and then move my pointer miles away to top panel to get to the menu. Similarly I like the close button for a window to be in the top left or top right corner of the screen when they are maximized. This makes closing them easy. But with Unity this is no longer possible. There are a lot of other similar issues which are not a big deal them self but together they make it really difficult for me to perform everyday operations.

But this does not mean I am giving up on Ubuntu, I am not ready to go back to Windows, but I have decided to give Kubuntu a try as well and see how I feel about KDE. No matter whom I end up with, KDE or Unity, I will still be using Ubuntu.

Wednesday, September 18, 2013

WebOS and Nokia - I wish

A mobile phone's hardware specifications are important but in today's world its the software (the Operating System) that dictates the user experience. Most high end phones today, from HTC, Motorolla, Samsung, Apple, Nokia and others, have almost the same hardware specs, with little or no differences. What distinguishes them from each other is the software on top of the hardware. And because of that Motorola, Samsung and HTC are no different for me. They try to give an illusion of uniqueness by making their own UI on top of Android but it does not effect most parts of my user experience.

Because of this, I have always been against Nokia making an Android handset. I have always thought that Nokia would be better off maintaining their unique identity. If they started making Android handsets they would be just another handset manufacturer in a long list of companies including Samsung, HTC, Motorolla, Huawei and many other Chinese and Korean and other handset manufacturers. But that would be a disgrace, I mean its Nokia which was once synonymous with mobile phone.

WebOS was the operating system on Palm Pre hand sets. I never got a chance to use WebOS but I have seen a lot of screen shots and read a lot of reviews when it came out and I was very excited about Palm Pre but unfortunately it never came to my country. The reviews for Palm Pre were good but what all the reviewers really liked and were talking about was its operating system i.e WebOS. So when HP bought Palm and later closed it altogether, I wished that Nokia would buy all the rights to WebOS and use it as the main operating system for their handsets. This way they would get a really great mobile operating system which would complement their existing handsets like Lumia nicely and could easily compete with the likes of Android and iOS.


I still wish Nokia would do this but I do not think this is going to happen now, with Nokia now being part of Microsoft and all, but the heart wants what the heart wants :)

Friday, August 30, 2013

Endianity conversion for a 24bit Integer

Recently while working on SSL protocol I came across 24-bit (3 byte) integers. I never thought any one would ever use a 24-bit integer. There are no default types or any type in stdint.h to create such a variable. So the best one could do is use 3 byte arrays and keep typecasting them to int - ignoring most significant byte on read and not writing the most significant byte on write.
The problem I faced was that I had to change the endianity of these 24-bit integers as the data is written to and read from network. I did not want to use a function call so I came up with following macros. They dont seem right to me i.e they are more weird looking and complicated than I wanted to so if someone has a simple solution, please share.

The following macro takes a pointer to 3 bytes containing 24 bit unsigned integer, converts the endianity of the integer value and returns it as int with most significant byte always 0
#define GET_NO_UINT24(src)  ((((*(uint32_t*)src)<<16)|((*(uint32_t*)src) & 0xFF00)|(((*(uint32_t*)src)>>16) & 0xFF)) & 0xFFFFFF)
The next macro takes 2 arguments. The first one is a pointer to 3 byte array for storing 24-bit integer and the second argument is the value to be stored.
#define PUT_NO_UINT24(dst,src) ((((unsigned char*)dst)[2]=(unsigned char)((src))), (((unsigned char*)dst)[1]=(unsigned char)((src)>>8)), (((unsigned char*)dst)[0]=(unsigned char)((src)>>16)))

Tuesday, January 1, 2013

Deploying a Spree application on Heroku

Heroku is a no-hassle hosting solution for Ruby, Node.js, Clojure, Java, Python, and Scala. It helps the developers to focus on the most important thing i.e creating the most amazing web app ever and forget about servers. Your application can be up and running in minutes. All you need to do is create an app on their servers and then push your code to it using git. They provide a handy utility to create and manage applications from command line and it can be installed from www.toolbelt.heroku.com.

Spree is an open source e-commerce platform that is available as a ruby gem for Ruby on Rails framework. It is intended as a foundation over which developers can build their own e-commerce sites.

Running a Spree application on Heroku is easy and can be done using the steps below.

Prerequisites

  1. A working spree application. If you want to know how to create one, read my previous post about creating a spree application.
  2. Working Heroku Account. If you don't already have one, sign up here.
  3. git client. On Ubuntu this can be easily installed using aptitude.

Steps

  1. Install Heroku Toolbelt.
    The toolbelt is a very handy utility for working with Heroku. The most important part of this toolbelt is a command line interface for creating and managing applications on Heroku server. For details and installation instructions please visit the Heroku Toolbelt website.
  2. Add your application to git version control.
    If not already done, add your app to git as this is required for pushing to Herokus servers. This is easily done using following commands:
    $ git init
    $ git add .
    $ git commit -m “initial commit”
  3. Next login to heroku from command line, add your SSH security keys to Heroku and create a new application
    $ heroku login
    $ heroku keys:add
    $ heroku apps:create myapp
  4. Push your changes to heroku
    $ git push heroku master
  5. Initialize your database
    $ heroku run bundle exec rake db:migrate
    $ heroku run bundle exec rake db:seed
And that is it. Your app should now be live at myapp.herokuapps.com. Head over to Heroku developer center for more details about this amazing platform or you can read this amazing book.

Sunday, December 30, 2012

Creating a Spree application


Spree is an open source e-commerce platform that is available as a ruby gem for Ruby on Rails framework. It is intended as a foundation over which developers can build their own e-commerce sites.

Prerequisites

To use Spree you will need to install following:
  1. ruby
  2. imagemagick
  3. nodejs
  4. libxml2
  5. libxml2-dev
  6. libssl-dev
  7. libxslt-dev
  8. postgresql
  9. postgresql-server-dev-9.1
If you are using Ubuntu, you can easily install all of these from repos using aptitude. Imagemagick is required for resizing uploaded images. PostgreSql is selected because it is common in the hosting platforms but if you are not concerned about it, you can simply replace it with sqlite or anything else that you like.

Steps

After installing the above listed softwares, install bundler, rails, rake and spree gem using following command:
gem install bundler rake rails spree
Now create a new rails application. The default database is Sqlite, so we need to specify that we want postgres:
rails new myspreeapp -d postgresql
Edit config/database.yml and add host: localhost to all configurations and also correct database name, username and password. Next, add spree to your app. To do this run following command from withing your applications root directory:
spree install
This will run a wizard which will ask your choices for running migrations, loading seed data and others and perform the required actions. When the wizard ends your spree application is ready and you can now run it on local host using:
rails s
Your basic spree applications is now available at http://0.0.0.0:3000. You will most probably want to customize this application according to your needs. Head over to spree customization guides for a detailed look at customizing spree.

Friday, December 7, 2012

Git: Beware of detached head

In git, every commit is recognized by a 40-character hash known as commit hash. A git repository is essentially a tree of commits, where each commit points to its ancestor(s). In git, a branch head is the last commit in the branch. A Git branch is simply a pointer to this commit, using its commit hash, in the repository. These pointers are kept in .git/refs/heads directory as files. If you look at one of these files you will find that each branch corresponds to a single file which contains nothing but a 40-character commit hash of the commit representing branch's head. So when you have a master branch, there is a file .git/refs/heads/master pointing to head commit of this branch.

There is a difference between a branch head and HEAD. As described earlier, a branch head is the last commit in the branch, whereas HEAD represents your currently checked-out commit. It is also maintained as a pointer in .git/HEAD file. Normally this pointer will point to the head of currently checked-out branch, thus the name HEAD, but it is quite possible for this pointer to point to a commit which is not the branch head. So , for example, if you are working on branch master and you have checked out the head of this branch, the contents of the .git/HEAD file will look like following:
adnan@adnan-laptop: test/> cat .git/HEAD
ref: refs/heads/master
So, in this case, the HEAD points to head of branch master, which then points to a commit. This means that you have currently checked-out head of the branch master. Now if you move one step backward and checkout a commit just before the head commit, you will get a detached HEAD.
adnan@adnan-laptop: test/> git checkout HEAD^
Note: checking out 'HEAD^'.
You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.
If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:
  git checkout -b new_branch_name
HEAD is now at 123fa7b1... my 1st commit comment
A detached HEAD is a situation where the HEAD pointer is no longer pointing to a branch head. In this case the file .git/HEAD doesn't contain a reference to a branch head but instead directly points to the checked-out commit using its commit hash.

If you now check the contents of .git/HEAD file, you will see it contains the hash of the commit you just checked-out.
adnan@adnan-laptop: test/> cat .git/HEAD 
123fa7b17a2d28fced849ee1bb76e7391b93eb12
It is totally okay to work with detached heads but it is very important to understand the situation as any commits made in this situation will not be part of any branch, as you are not at the branch head, and the only way to refer to it later on will be using its commit hash. Also git garbage collection will run occasionally and remove any commits which are not referenced, directly or indirectly, by a branch or a tag. 

Tuesday, November 20, 2012

Its a free world


Disclaimer: I am not a web developer. Although I am a CS grad and understand all the concepts involved and have worked on a few websites in my unversity days and little afterwards, but I am not employed as a webdeveloper and am out of touch with this subject and the technologies and services involved.

Recently, while working on an eCommerce website for a friend, I came across some amazing free services which can really help a start-up reduce its costs. 
The first and most important one is Heroku. Heroku is a no-hassle hosting solution for Ruby, Node.js, Clojure, Java, Python, and Scala. It helps the developers to focus on the most important thing i.e creating the most amazing web app ever and forget about servers. Your application can be up and running in minutes. All you need to do is create an app on their servers and then push your code to it using git. They provide a handy utility to create and manage applications from command line and it can be installed from www.toolbelt.heroku.com. Once you have installed this, all you need to do to make your application live is to run from command line:
heroku apps:create my_amazing_app
git push heroku master
and twalah, your site is up and running at http://my_amazing_app.heroku.com. You can read more about Heroku here

One thing that Heroku lacks is file storage. File system for your app (slug in Heroku's terms) is readonly. So you cant create and write to files on the server. This means that uploading files e.g images wont work. So you will need some cloud storage to store your assets and this is where Amazon Web Services comes in. Amazon S3 is free for you for 1 year. Upon sign-up, new Amazon Web Services customers receive free 5 GB of Amazon S3 standard storage, 20,000 Get Requests, 2,000 Put Requests, and 15GB of data transfer out each month for one year. So you can host your images or other assets on Amazon's servers and stop worrying. More about AWS Free Tier here.

Once your app is ready and running as you want at http://my_amazing_app.heroku.com, the next thing you need is a domain name. Now, there is no way around it. You will need to buy one but you will also need DNS service so that you can point your new domain to your app on Heroku. This is where Zerigo.net comes in. They offer a starter package which is free and gives you 50,000 DNS queries each month, which is more than what I need for now. Its also realy easy to setup Heroku to use Zerigo. All you need is to use Zerigo DNS add on and configure it to redirect www.my-amazing-app.com to http://my_amazing_app.heroku.com. This is easily done using the following commands:
heroku addons:add zerigo_dns:basic
heroku domains:add www.my-amazing-app.com
More on Zerigo add-on here.

The last thing that I needed, and which you may or maynot need, depending upon the web app, is a mail service. For an ecommerce website you need to be able to send emails to your customers. The free mailing functionality is provided by SendGrid.net. They also offer a free/starter package which allows you to send 200 emails per day for free. Similar to Zerigo addon, Heroku provides an addon to enable this functionality. All you need to set it up is the following command:
heroku addons:add sendgrid:starter
Afther that you need to configure your mailer software to use smtp:sendgrid.net and smtp port 587 to send emails. You will also need the login/password for SendGrid.net which you can get from Heroku using command:
heroku config
And thats it. Your app is up and running without paying a dime.
Isnt it amazing? I think it definitely is.