Monday, July 28, 2014

A tryst with Message Queues Pt. 3

So once I have called it quits on the R&D, I started work on the integration thing. The problem has grown tenfold by now. The powers that be want to do a lot of messaging stuff and its become a list of at least half a dozen changes where messages are to be introduced. Now, there's another angle. I am serving notice period, the recruitment people are having hard time finding a replacement and its my last three weeks here. I should be doing the handover. Shouldn't be working on these new features - especially things as complex and less understood as this STOMP stuff. But what can you do when the powers that be want to push in code without worrying about the future of that code.
So I sat silently on this wet and cold Monday morning, trying to figure out the integration strategy. Yeah, the code is all C code, so better to keep it all together. Means a single function which connects to server, sends the message and disconnects. What can I pass? We need to fetch in settings from a config file. Alright I'll use the common config. And what parameters to this function? Maybe just the message will do? No, I need to pass the queue name too. Since there are going to be multiple queues.
OK. Plus I need to extern "C" all includes. Lets hope it doesn't screw up the already included stuff.
So I dive in the code. Add the libraries. Modify the build script to build these too.
Then I add support for the new config fields in the common config file. From there I add some more code to read the new configs.
From there I pull together the message sending code from other application which I have been using for R&D, put it all in function. Then I add some #ifdef's around all this code and add the linking and includes to the pro file.
So after messing with this for some time I finally have some messed up code ready to be compiled. Its going to be a nightmare to get this sauce working. But thankfully I have been many such nightmares already. Will be back soon with next part if I manage to get this spaghetti working.
Adios.

Friday, July 25, 2014

A tryst with Message Queues Pt. 2

So far...
I'm sending data to a RabbitMQ broker as messages. These messages get queued up in a user configurable queue. Supposedly a consumer is going to process these. But the consumer is out of my view.
Doesn't matter.
Now there came a feature of receiving notifications from the consumer or some other system. So after some discussion, the powers to be decided that we are going to have a notification queue which the client has to read. And from it we get the notifications to be read. Now the shady part of business was I had no idea what the hell is going on the inside of libStomp. So I ask politely that I don't have any read code. And I get handed over a single stomp_read code snippet. (In whiny voice) They said it works!!! But it doesn't!!! I tried so hard!!! Damn!!!
So I looked into the protocol to understand why the hell I am no getting anything. After reading the protocol, I came to know that the implementation is fucked up in ways more than a few. First STOMP is a message send and receive protocol. Which means when we prepare a CONNECT frame, we are supposed to get a reply as CONNECTED along with server connection settings.
Now the original code sample which I was using for sending the data had all stomp_read calls commented out. And after I tried to run that sample with the read calls uncommented. And there I also ran into the same problem. That meant there could be either a server problem or a client problem.
I didn't have any other verified STOMP server, So I decided to check if RabbitMQ is the culprit. Thankfully at the stomp_ plugin page on RabbitMQ website, they have clearly given this procedure. After trying out the telnet routine I ran into an interesting problem.
At first CONNECT, I got invalid error command. Next any CONNECT worked out. After scratching my head for a while I remembered that putty does active negotiation for telnet connection. So I went into putty settings and tried out passive negotiation. That worked. And it also meant that RabbitMQ server is operating fine.
So the culprit must be libStomp. But even after extended search on the net I didn't get any occurrence of my problem.
Later after going through all the protocol stuff I tried out SUBSCRIBE command and even though RabbitMQ logs suggested that the operation has succeed, there was no response read.
That's the current state of things. I have given up on reading up stuff and instead I am going to integrate the working bits into our product. Later I'll see if the reading is working. Else I am thinking of writing my own STOMP message since its all text anyway.
Let's see!!!

Thursday, July 24, 2014

A tryst with Message Queues Pt. 1

I need to give some background for this situation.
Its like this: we have a client server product. The server is written in .net and performs analysis on raw data collected from a number of clients and prepares various reports. The client software is written in c++/Qt and it interacts with various hardware controllers/ sensors to get the raw data.
There is a sync program written in .net that runs on the server and it pulls data from all the clients. The data is saved in servers PostgreSQL database for later processing.
Now, the powers to be decided that we need to remove this syncing program ( because it sunk the data into oblivion sometimes! :D ). So what's the replacement? Well, they decided on RabbitMQ as the queuing solution and decided that the clients would sync their own data to the queue and from there it will be fetched by the server.
So we as clients needed to have this functionality in our application. But after looking at the complexity of our own client, we decided to create a simple up sync application which will be completely separate from our client. Its sole responsibility will be to ensure that all data in the database is sent to the message Queue.
The powers that be decided to use RabbitMQ as messageQueuing server platform. Let me tell you, this is one software whose configuration is a headache. The horrible syntax required for the config file gets to you.
But I somehow survived to tell the tale. Anyway, since my domain knowledge about this was absolutely zero, I spent some time reason up the stuff and getting familiar wight the trade lingo.
Then I used the .net client to check out my clueless config and needed few more days to get it to my taste. After that I went on to compile libApr, and libStomp, and then use it all in my own application.
This would have turned out nightmarish but thankfully I got hold of the compilation commands on internet. Then I spent next couple of days writing the database interfacing stuff. Once I furnished that, I went on to integrate libStomp code.
That took few more days and finally I was sending some stuff to RabbitMQ. I didn't know how to check if correct data is going in. Looking around I found info about management plugin. So enabling it let me confirm the data. Some bugfixes later I was pushing thousands of rows successfully.
Mind you though I still didn't know exactly what the hell was happening inside LibStomp. I came to know that.
In next part.

Monday, July 21, 2014

Custom ROMs for ZTE Blade C (v807/889) and caution for flashers

www.needrom.comhas a collection of ROMs for this phone.
The things to remember are:
1. Always backup the existing stuff!
2. Ensure that phone battery is more than 70% and the computer laptop you are trying out the procedure from has sufficient backup power.
3. Ensure that whatever ROM files you get from the net are from reputed sources and are tested previously by multiple person. Flashing incompatible ROM will brick your phone. So big word of caution here.
4. Also don't forget to check MD5SUM/SHASUM of the file to ensure that your downloaded file is fine and not corrupted.

Flashing a custom ROM is dangerous if you are not careful!

Thursday, July 17, 2014

Rooting zte blade c

Zte Blade c (v807/v889) can be rooted by using vroot application. This is a windows program, so you need a windows PC for this.
You can follow this process:
Enable USB debugging mode on phone and connect to PC.
You need to install USB drivers. You can get these from the phone itself. When you connect the phone to PC, you get an option in notifications about connection type. Here if you select CD-Rom, then a mounted CD-Rom appears in your computer which contains the drivers.
Otherwise you have to search on the internet to get the debug drivers. Once the drivers are installed, you will see a MT6513 device in system tray.
Now start vroot, and wait for it to detect the phone. Once phone is detected, clicking on 'root' button will start the rooting procedure. After files are copied to the phone, it will restart the phone and rooting will continue.
Afterwards phone will restart again and load android. You will see a Superuser app in app drawer. If you open root checker, you will get a prompt about root permissions. Once you have given the permissions, root checker will start and show that the phone is rooted.

Saturday, July 12, 2014

Upgraded a Lenovo A1000-T tablet

This tablet belonged to one of my relatives and I took it with me for updating the apps on my home WiFi. Once it was connected, I started updating the apps one by one. Then in between the updates, a notification popped. This was about a system update availability. I was frankly intrigued. Seeing an android update. So i stopped app updating and instead went for the update. It was ~92MB and took some time to download. Then another dialog popped up asking me if i wanted to update now or after some time like 30mins, 90mins. I selected to update now. The tablet rebooted and updated. After it was done, it rebooted. Once we were connected to WiFi, another update popped up. This one saying it was memory related and it will wipe out all user data. So I went through and checked the partitioning. So it had a 512 MB system partition and 2GB internal partition. Ok. So I went through that update.
Now after some time in getting the user account set up, I'm running through so many apps install, but it has raised the system partition size to 1.4GB and shrunk the internal partition to 1.4GB. I guess that means those pesky 'out of storage' errors will vanish now.
Kudos to Lenovo!!!!

Thoughts on ZTE Blade C after a fortnight

So I am using the ZTE Blade C as my daily driver now. It's almost a fortnight since I started using it. The main point for me to go for this one instead the latest crop of cheap chinese kitkat phones from Micromax/Karbonn/Xolo etc or Moto E was the price it was offered. The price was INR4000 i.e. ~$68. Thats dirt cheap. And whatever features it provided are more than enough for me.
When compared to my previous android phone - Karbonn S1 Titanium - INR7600 /~$127, the blade c actually shines. The Karbonn handset had following shortcomings:
1. It's touch response was sub par. The capacitive keys were terrible. Plus it's touchscreen used to go crazy when it was charging. Also there was a bad touch spot which made typing slightly painful.
2. The 5MP/720p camera was average, even though it was touted as a main feature.
3. It's chipset is Qualcomm S4 play - not the best when it comes to power consumption. And it's couple generations old by the time I got the phone.
4. The display is bright and colourful but its viewing angles are not much. So watching videos on the 4.5" screen is not even an average experience.
On the plus side, it has 1GB of RAM and that was it's only saving grace.

Coming to the ZTE, I noticed following points:
1. The display is kind of dim. So sunlight legibility is low. But indoors it works fine.
2. The touch response is superb. I don't mind holding home button to get recent app list here. And the vibration is perfectly synced with the OS response.
3. 512MB RAM hurts the phone. it's just not enough. You start some game or demanding app and have mp3's playing in background, expect to have the music player killed automatically. Also when you quit the game, then the homescreen will take 3-4 seconds to load. Thats because of less amount of RAM.
4. The interface is smooth. There is no unnecessary lag anywhere except where intense memory operations are happening like App loading/ resume etc. The various effects and transitions are smooth and the interface feels very responsive. This could be due to better touch response too.
5. Battery life is good. The phone lasts about 12Hrs. My typical use includes about half an hour of calls, couple of hours of web browsing (mostly while I am in transit), coulpe of hours of Whats app, and an hour of gaming (It's candy crush saga these days :D)

I guess looking at all these points, I got a good deal. Happy customer ZTE. 

Friday, July 4, 2014

[Android] Finally shifting to Android from WP7.8

I have been a WP user for last two and half years. The samsung omnia was my first smartphone and it has been wonderful hardware so far. Even after so many years of rough use the phone still feels solid in hands. And the software has been great too.
But all software ages. And so has the old WP7. Mind you, its still has the performance. The UI smoothness is there, the OS is responsive as ever. The hardware is solid, the phone has not rebooted of its own accord. And whatever features it provides it excels at them. For me though the first blow was losing gmail support after upgrading to WP7.8. And recently Whatsapp outage was something else I could say was most significant for me to start considering something else. But the problem was I had sunk almost INR16,000 in this one back then. Thats about $320 back then.
And right now I am weary of sinking so much hard earned dough into a smartphone. But thankfully the smartphone prices have also come down dramatically. I was looking for a killer deal and I knew what my requirements are. So when I came across this ZTE Blade C - going for just INR4000, thats about $67, I jumped on to the opportunity. The phone is one full generation old and is very entry level with a 1GHz cortex-a9 dual core processor and 512MB Ram. So when Antutu produced a score of 8000+ that was a startling thing for me. Because I had a Karbonn Titanium S1 which had a 1.2 GHz Qualcomm S4 play quad core chipset and 1GB Ram. But it managed to score only about 10000 points.
Anyway lets get back to the point of shifting to Android. I had to make following preparations for the actual shift.
1. Contacts: Create hotmail contacts export as csv and import them in gmail.
2. Apps: List down the required apps and hunt their equivalents in Android. Thankfully I dont use the phone for anything else than calls, email, little bit of web surfing, and slight gaming. Oh and the Whatsapp. I got hold of most of the stuff right away. Some like skype I had to drop, because Blade C doesnt have front cam. No problem. I am not a heavy skype user.
3. Performance: The phone has been zippy and has been able to handle almost everything I could throw at it. The battery performance is not consistent though. It drops once in a while very fast. And then it will sit quiet. Must be some issue with battery calibration. I dont mind as long as I get decent battery backup. If the phone can make 8 hrs without dying, thats good enough for me.
So lets see how things go. Ill be posting stuff about the ZTE here as things happen around.