Author: Kevin

Starting up on a Saturday ‘noon

KevinLeave a comment

I had a sudden itch to build something from the ground up. I knew the moment it started to itch that the itch will not be cured until I sink hours into something laborious and intellectually satisfying. I wanted to build a company from the ground up. If a stupid photo-sharing app like Instagram could make so much money despite bringing almost zero utility to the user, I’m pretty sure anything can make money. On hindsight, I realize that I might be just another clueless programmer who can’t figure out how the hell Instagram, vine, yo, and WhatsApp made so much money. I mean come on, did the world really need another texting service? Or another photosharing service when there were facebook, Flickr and a whole ton other services? Don’t even get me started on yo. I admit it. I’m just jealous. I know that Instagram is engineered well.

Anyways, my glorious new “startup” would be called “Use my space”. It’s kind of very very similar to Airbnb but different. I won’t pretend that I came up with an idea that is nothing like Airbnb and serves a completely different user base. That’s not true.

Gist: you get to rent out soccer ground for a weekend brawl with friends, a rusty old shed for your hardware project e.t.c

It’s sunday noon and the infinite pool of passion and vigour that I assumed I had to bring my idea to life is seeming to dry up. I’m already not-optimistic, though not entirely pessimistic. However, I had put together a couple of screens yesterday night to create a UI prototype so that I can pitchto probable co-founders. Oh what a fallacy. Here are the screens. Proof that I was willing to put on the designer hat for the sake of a product.

All screens were made using Inkscape on Ubuntu:

Image attributions:

Assembled a computer

KevinLeave a comment

I was without a computer for a whole year. A whole frigging year. And THIS is my reward:

Christened alduin, after the big black dragon from skyrim

Specs

  1. Core i3 6100 @ 3.7Ghz. Skylake.
  2. 8 GB Corsair vengeance DDR4 2133 RAM. Single stick
  3. Zotac GTX 950 Amp! edition. 2GB VRAM. Entry level graphics card.
  4. Adata 120 Gb SSD
  5. Gigabyte GA H110m motherboard. Micro ATX form factor
  6. Antec X1-T cabinet
  7. Cooler Master Storm Devastator gaming combo – backlit keyboard and mouse.
  8. BenQ G2255 21.5 inch monitor. 1920 x 1080.
  9. APC 600v UPS, an extension cord, a used office chair, a really cheap computer table.

And finally, a 60k (INR) hole in my wallet.

But I’m happy I have a computer and I’m happy that I could assemble it. Most of the parts were ordered from theitdepot.com with the monitor coming from Amazon.in.

Why I chose to assemble a desktop, as opposed to buying a laptop

I had to live without a computer for almost a year. Why? Because the Nvidia 610m GPU in my Asus k53SD laptop died. No, you can’t replace just the video card. You have to buy a whole new motherboard because mobile GPUs come soldered to the motherboard. But can’t you just unplug the video card and use the integrated GPU? No. It doesn’t make sense but apparently, that’s how mobile GPUs work. Did I say that I was asked to pay for a new processor as well? Yeah! Because k53 motherboards have the processor soldered to it. At least that’s the explanation the repair guy told me. So ordering a cheap motherboard without a graphics card from eBay won’t work because you can’t pull out the processor from the damaged board and put it in the new board.

Broken hearted, I agreed to pay the price for a new board and a processor – only to find out that it is difficult to source the motherboard because my 2 year old model is outdated.

If that was a desktop, I could have just pulled out the graphics card and everything would have run fine on the iGPU. Everything except the few games I play.

I promised myself that I would never ever buy a laptop as my primary computer again.

Rant ahead

When I assembled my computer, there were very very few laptops with the latest skylake (6th gen) processors inside. This was in February end and almost 5 months after skylake was made available to consumers. Almost all the laptops listed at amazon and other e-commerce sites were running 4th generation processors. However, I did not see any price drops. An ivy bridge core i3 was listed at the same price as a haswell i3 which was listed slightly below the price of a broadwell laptop – and broadwells were rare. I suppose this happens only in India.

So what laptop will 45k Indian ruppees get you? A haswell mobile (mobile processors are always slower than their desktop counterparts) core i5 with 4 gb RAM and no dedicated GPU. If you are lucky you would get an 8GB SSD where windows would be preinstalled. Yes, 8GB. 720p Screen.

Guess how much my assempled pc would have cost sans the graphics card? 42K. And that’s including the chair and the table.

Hence proved that desktops are more bang for buck if you actually are concerned about performance (A.K.A gaming) and do not mind the lack of portability.

Motherboard refused to power up. By 2.30 A.M I realised that the power connector was loose *sigh*

Pomodoros for Programming

KevinLeave a comment

If you’ve never heard of the pomodoro method, go read this. I might have just saved your life. I’ve been using this neat little technique since college, and now work. Pomodoros for exam prep was easy – you sit in front of the book while the clock is ticking and you go for a walk when it isn’t. But using pomodoros for programming turned out to be slightly more complicated than that. Here’s what I found:

The Don’ts

  1. Do not use pomodoros for debugging. You cannot estimate when you will figure out what is causing that bug. It can take anything between 2 hours to 2 days.
  2. Do not use pomodoros to set up your dev environment. You can install visual studio and SQL server while wading through nonsense at /r/nonsense. Save up your pomodoros for tasks that actually require focus.
  3. Do not try to do 14 programming pomodoros a day. If you can do 8 a day, fantastic – you’ve done a lot of work. 6 Pomodoros, is good. I think anything more than 8 means you will be staying late in the office. That’s okay too. The thing is, manage to tick away more than 6 solid pomodoros despite all the email-replying and chit-chat and gazing-into-the-infinity then it is not a wasted day.
  4. Do not freak out when your pomodoros are interrupted. Instead of losing your shit when people interrupt your pomodoros, avoid interruptions in the first place by setting clear expectations around your maker’s schedule and manager’s schedule

The Dos

  1. Set aside pomodoros for designing systems. This is a good way to force yourself to think hard about a problem before jumping into execution.
  2. Reply to emails on pomodoro breaks. If there are no emails to reply to, take a walk.
  3. It’s okay to extend your 5 minute break by another 2 minutes. When it comes to personal productivity, it is about following the spirit of the law rather than the letter of the law.
  4. I’ve never been able to do those 4 pomodoros in a row and take the bigger 15 minutes break. But do not let that stop you from trying things out until you figure out what works for you.
  5. The real reward of using pomodoros is not (just) that you do more work per day, but that you can now measure how much work you do. If you can’t measure it, you can’t improve it.
  6. kanbanflow is a pretty good tool with a built-in timer. Arguably better than pen and paper. But ticking off pomodoros on a big whiteboard is more satisfying.
Estimated 4 pomodoros and did it in 2. What a wonderful day!

Update

After further experimentation with the technique, I have decided that pomodoros for programming are not my cup of tea. There’s nothing wrong with the technique itself – a good friend and co-worker of mine has been using pomodoros (for programming) for almost a year now and he’s happy with it. It’s just that I am not very productive when there’s the threat of a forced break looming on the horizon.

We have moved!

KevinLeave a comment

Edit: Nah, I’m back on wordpress. Github pages was simply too much work. I did not need all the custom fancy Js that I thought I’d need after all.

Happy to announce that I’ve moved this blog to lonesword.in

It doesn’t have all the bells and whistles of wordpress. And at times it looks drab and very bare. But it is more me. I designed it (and consequently the consequences), and it is hosted at github.com. That means I can try out changes before I publish and I get to make my site the way I make my code. Yes, the custom domain name is nice to have too ^_^

Web design for programmers : A 10 minutes crash course

Kevin2 Comments

I’m not a designer, and I’d rather not be one. However, there are times when programmers who don’t like to design (or draw, for that matter) are forced into that tedious act. I was responsible for designing the front end of a product at a company I interned at for the last 2 months.

Needless to say, html + css was terrifying for me. There were days where I spent entire mornings trying to align the bloody divs. Also, my choice of colors and “ui elements” were not at all pleasing. I had to pull this together somehow. I scoured the web for some intro to design. So here’s what 2 months of front-end taught me :

1. For the love of God, use bootstrap. No matter how promising the control and flexibility of pure css looks, use bootstrap and save the headache – at least when you start out.

2. Use a pen and paper to sketch your design. If you don’t like pens or papers, use a wireframing tool such as wireframe.cc. I spent some considerable time building wireframes, and then threw them away when I changed the design. Lesson learned – use pen and paper. Wireframes are useful when you want a more detailed/accurate layout of your web app.

3. Chances are that you are terrible at choosing colors. Use a tool like paletton to find the right colors, and the right combination of colors.

4. Use good fonts. Microsoft’s Segoe UI is now my favourite font. Segoe UI wasn’t featured in even a single article that discussed the “best free web fonts”. Experiment.

5. Don’t use too many colors, and don’t use too many fonts. Try to keep it simple whenever possible.

6. The official bootstrap docs does not contain references of some really useful bootstrap components like “panel” and “panel-default”. So be sure to double check before you decide that bootstrap doesn’t have it already.

7. You can’t come up with a “mind blowing, innovative, revolutionary design” over night. You might, but chances are that you won’t. Always try to build upon designs (please don’t use templates) that already exist. Here are some useful links for you to ‘build-upon’ :

8. Don’t be afraid to rewrite the HTML. I had to design a signup form and my first implementation sucked. The HTML was a mess and I couldn’t even think of modifying it. So I just wrote that page again, from scratch. Not only did I come up with a wonderful new design and styling (hint: tiles and css shadow on hover), the HTML was much much more readable. Break and build, break and build.

Good luck.

Cohen’s clipping algorithms

Kevin1 Comment

Okay this was homework. I searched for a really long time for a javascript implementation of cohen’s clipping algorithms and could find none. Professor said write it in c but its hard to program mouse clicks in c. With javascript, all it takes is a browser.

1. Cohen-sutherland line clipping algorithm in javascript

2. Sutherland-Hodgman polygon clipping algorithm in javascript.

cohen-hogman polygon clipping in action
cohen-hogman polygon clipping in action

I believe the code is pretty readable – I had commented lavishly. Save them as html files, open in a browser, and keep clicking left mouse button.

And yes, the implementation is not perfect. I basically drew over the edges in white to “erase” it and that is why you see a very thin line outside the rectangle in the image.

Sound frequencies with aubio

KevinLeave a comment

Small python script I wrote so that you can yell at the console and see the frequency on the screen. The results can be slightly wrong (incorrect spikes in frequency occasionally) but it was great yelling at the computer with my hostel mates to see who’s got the highest ‘range’ 😀

Link to the github gist.

The code is too small to give an explanation. However, you need to set up a few libraries before running the gist (instructions for linux) :

1. aubio – A fantastic library for analysing audio. Packages libaubio and python-aubio are available in the ubuntu/mint repositories. However, I ran into problems (repos have older versions I guess) and was able to fix them only after compiling the source. So head over to this repo, download the source code, and compile.

To compile aubio, head over to the source directory and type:

./waf configure

That will spew out a list of packages you will need at the end. Make sure you install the dev versions of each package. For example, for sndfile, do

sudo apt-get install libsndfile1-dev

 

Similarly install all the packages that you would need to use with aubio. I did not have a clue as to what I will need so I installed them all.

Now do ./waf build
and then sudo ./waf install

That should install aubio on your linux system. Time to install the python wrappers. ‘cd’ to /python directory in the aubio source.

python setup.py build to build the files and after building,
sudo python setup.py install to install the python wrappers for aubio

 

2. The snippet depends on pysoundcard, which is not available in the repos. Head over here to download the source. Build and install this python package the same way you did the aubio python wrappers

Download (or type) the gist and run it! Happy yelling!

GSoC : Final report

KevinLeave a comment

Putting together a quick report of how I spent my last 3 months on improving varnam, an awesome transliteration project. My task was to implement a stemmer to improve the learning in varnam.
A stemmer is an algorithm that, upon giving a word as the input, gives the base word as the output.

For example, giving മരത്തിലൂടെ as the input would give you മരത്തിൽ and മരം as outputs. മരം is the final output of the stemmer and മരത്തിൽ is an intermmediate output of the stemmer. The algorithm is described here. The stemmer is similar to SILPA stemmer created by Santhosh Thottingal except that my version makes use of an exceptions table and produces meaningful intermmediate words.

A screencast that explains my work is posted above. Make sure you watch it in 720p to clearly see the words being typed.

As far as statistics go, see this thread to know how much the learning has improved. This is not the final result, as the number of words learned is of no consequence if the stemmer does not improve transliteration accuracy. Transliteration accuracy tests before and after the tests are yet to be done thoroughly. Judging by the number of new words in the word corpus alone, varnam saw an improvement of 63% in learning when tested with 408 words.See the above thread for the exact results and the word corpus used.

GSoC : Memory heap corruption and code rewrite

KevinLeave a comment

This week I’ve been busy rewriting the stemmer and debugging some memory heap corruption. My first implmentation of the stemmer used to crash ibus whenever certain words, like “ദൂരെയാണ്” and “വിദൂരമായ” were typed. I could not locate the problem, and the only error message I got was “free() – invalid next size” when ibus crashed. Some searching revealed that it might be due to a memory heap corruption. I used valgrind memcheck to debug the memory corruption. It was difficult to make sense of valgrind’s output, and that eventually lead me to ask a question at stackoverflow. However, before all this, I was convinced that I made some serious mistake somewhere along the development path and decided to sit down and rewrite the whole project. I thought that I made a mistake by not testing with ibus early on. I discovered what I was doing wrong to merit the memory corruption soon after (even before the guy came in and gave his answer at stackoverflow.com). However, I realised that a rewrite would do the project much good. To start with, I could then run valgrind as I went with the rewrite to make sure that I plugged all the possible memory leaks. Also, I was able to look into some unnecesary function calls among other things. In short, I cleaned the code and is ready for a code review.

Here’s a changelog:

1. Tried implementing the “improvement scheme”, as I had suggested in this thread. The results were far worse than expected. 60% of the words after suffix appending were not meaningful. Any further attempts along this path would require much more careful planning and reasearch of the malayalam language.

2. Located and avoided [did not stonewall it] an annoying memory corruption. Filed it under issue 51.

3. Removed the level hierarchy. All stemrules are now grouped into one. Splitting the stemrules into 3 levels serve no real purpose, and complicates stemming by needing to check each level seperately. Also, removal of the level system has improved the code readability a lot.

4. Replaced some function calls with inline expansions. Made all the functions more defensive and freed memory wherever valgrind reported memory leaks.

5. Libvarnam ibus requires a clean build every time libvarnam.so changes. It seems that libvarnam-ibus has its own version of libvarnam or something. Should look into this. Ibus not reflecting the changes I made to libvarnam was a real headache – no amount of debugging could solve the issue. Tried recompiling libvarnam-ibus and things started to work.

6. Eliminated recursive calls to varnam_learn(). In the first implementation, varnam_learn() would call varnam_stem() which calls varnam_learn_internal(). This was bad design. Now varnam_stem() returns a varray to varnam_learn(), and varnam_learn() iterates over this varray to learn all the stemmed words.

These changes are not final. Some of it, like doing away with the level system, was done without consulting my mentor and would be reintroduced if he thinks that removing it was a bad decision. You can see all my changes here and make suggestions.

To do :

1. More tests
2. Make sure stemmer works well with other languages
3. Enable varnam to stem from the command line interface

GSoC : Code review 1, almost.

KevinLeave a comment

Before more thorough testing of the stemming algorithm and its effect on varnam’s learning, my mentor and I decided that it would be a good idea to do some code review. So this week I fixed some problems with the stemming, tested how the stemming works with ibus input method, checked if learning is improving at all, and wrote some unit tests.

Stemming with IBus works, though with some bugs. Let us consider a case that works. The learnings database is now empty and we are starting with the blank state. Varnam does not know anything other than the symbols specified in the scheme file.
The below video demonstrates varnam learning a word with Ibus as the input method. The next time the user starts to type the same word, you can see that its stemmed forms are available in the suggestions.


Right now the only cause of concern with the suggestions is that incomplete words are suggested first, and the user has to go through the suggestions list to find the intended word. Also each time varnam learns a stemmed word, all its prefixes are learned as well. This will eventually lead to the incomplete prefixes coming up first on the suggestions list and the user will have to look through the list to find the word she is looking for.

There are some bugs, like some words dissappearing when I choose them from suggestions. The varnam_stem() function is possibly modifying some things that it isn’t supposed to. I’m also getting errors when I’m using free() – invalid next size(fast). Maybe the upcoming code review will expose my mistakes.