Showing posts with label code. Show all posts
Showing posts with label code. Show all posts

Tuesday, April 14, 2015

Android Studio Problems


I got a few days holiday, and I thought I planned on learning and picking up on the new Android Studio IDE which was released in December last year, and maybe develop an app. I had attended a two day beginner's workshop at DroidCon 2013, and had learnt quickly the basics of Android app development. Since then, I lost my projects and code to a hard-drive crash. The new Android Studio looked easier to learn. Or so I thought.

For a beginner, Android Studio sucks. It is too complex a development platform. Before one can start developing apps, one has to first play and win the rpg-game "Installing and Settingup  Android Studio". I have tried and failed for two days to get the basic setup up and running, I think this is because I have multiple installations of Java on my machine. After installation, the studio.exe can be launched, but it tries to connect and download the latest SDK. I had downloaded the bundled version, but looks like it does not have the SDK itself, just the IDE. And…don't get me started on gradle. I wish there was a way to turn it off and do things the way it was done on Eclipse.

Google, if you want to welcome more developers to your platform, you will have to make things easier. Experienced Android developers may not have issues in picking up the new studio. But beginners like me will be lost.

I am going to try again from office, first downloading just the IDE (because the bundle is a joke), and use the faster connection from office to get the SDK. Hopefully, things will be faster.


Monday, July 28, 2014

Worst software I have used

This is something I have been planning for months, maybe a year now. As part of my work as a Software consultant, I have had to use some really terribly designed and poor performing software. Here is the top 3 , (or worst 3) so far:

  1. IBM Lotus Notes (I used version 8.5):  In a world where simplicity ,ease of use, and minimalism is gaining appeal, Lotus notes dares to go miserably against the tide. It is slow, hogs memory and resources, and follows and out-dated layout style. It would be easier for a newbie to master a flavor of  Linux system than to get used to Lotus notes. Also, it does not merge into Window’s theme system, further showing its age. It even lacks functionalities you have come to expect from an e-mail system; like forwarding meeting requests, and recalling sent mails.
  2. BMC Remedy:  I was on a support project for over a year, and the part of my job I hated worst was where I had to use and update the ticket details on the Remedy system. Its ironic that they thought of such a name when it does not remedy anything ! Again, the aged look and feel and cumbersome navigation itself put me off. But it was also terribly slow; so slow that on many occasions I missed SLAs because the system did not respond on time. And if you are planning to run long queries to prepare your reports on this dinosaur, be prepared to lose hours with the hourglass spinning. I used to start a query and go get a cup of coffee before the results came out. We used to joke that we need to bill 1 hour to Remedy ticket updation separately over and above our usual bill hours, because our productivity during that time was absolutely zero !
  3. HP Quality Center:  I used to like using the earlier version of this software, when it was still called Mercury Quality Center. But after the last upgrade, when it moved to the latest HP QC version, I found I was spending more time updating QC records. The fact that it uses ActiveX and runs  only on IE was further complicated because it hogged up memory, and frequently crashed.


There ! I said it. That takes some weight off my chest :-)

Update: When it comes to professional/company e-mail, Microsoft’s Outlook is the best. And after years of using various bug tracking software, I have to come to believe that the best software is one which does it’s job, without interfering in your other work, or having you learn all the basics all over again. Take a look at Atlassian’s JIRA bug tracking system. It has a lightweight user interface which runs in every browser, has notifications, and generates graphs for reports. Its probably the best bug-tracking system I have used.

Friday, April 25, 2014

10 Fun Linux Commands


One can never say it enough: the terminal is a very powerful tool, and is probably the most interesting part in Unix. Among the plethora of useful commands and scripts that you can use, some seem less practical, if not completely useless. I’ve selected for you a couple of commands that are useless because they are funny, but not funny because they are useless (or maybe the other way around for some). If you are searching forASCII art, random math curiosities, or various (in)utilities, this is the best of the useless.

1. cal

Few people know this, but any Unix system comes with a built-in calendar. To access it, you can simply type:


This will display the current month. However, you can select the precise year that you want as an argument, and even the month. And to be fully useless, the option “-j” displays Julian days (the number of days from January 1). To sum up:

2. time cat

You can use this command as a built-in timer. It will run in the background until you stop it, and will then report the time elapsed between the start and the end of its process. As useful as it may seems, it is actually quite unpractical because you cannot check its value unless you stop it. I suppose it can become handy in a very specific situation but I have trouble imagining which one exactly. To launch just type:

and to kill, use the combination “Ctrl+c”


3. yes

A very peculiar command with only one ability: repeating a string until its process is killed. Again, I don’t picture where it can be useful, but who knows? The syntax is straightforward:


4. rev

This command is for reversing any input (as its name suggests). When I say reverse, it means that if the input is “Linux”, the output will be “xuniL”. Pretty strange, I know.


You will enter an interactive mode. You can quit it by using the shortcut “Ctrl+c”. But rev can also work to reverse an entire file with

5. factor

It’s time to do some Maths. Let’s begin easy with the command factor which can decompose a given number into prime factors:

factor [number to decompose]


I haven’t tested the limits of this command yet, but it seems pretty powerful. As a side note, prime numbers and the decomposition into prime factors is actually the basis for modern cryptography and Internet security. Knowing a little bit about them is always interesting. If you want to learn more, take a look at the RSA encryption.

6. Multiplication Tables

This is actually more a script than a command but it is impossible to ignore it when talking about funny stuff you can do in a console. By using

for i in {1..9}; do for j in $(seq 1 $i); do echo -ne $i×$j=$((i*j))\\t;done; echo;done


The terminal will display the multiplication table, nicely ordered in columns. Incredibly useless, and pretty long to remember, but you have to admit that it looks good.

7. PI

A bit more complex, you can calculate an approximation of pi through commands using

seq -f '4/%g' 1 2 99999 | paste -sd-+ | bc -l


This combination of commands is a little bit harder to understand, but if you really want to know, seqgenerates the sequence of 4/1, 4/3, 4/4 until 4/99999 (without 4/2), paste merges these lines using a delimiter, and bc does the final approximation using a math library.

8. figlet

Figlet is a command for those who love to write in ASCII art. It greatly simplifies this task as it automatically transforms any given string. It comes with a bunch of fonts, by default at /usr/share/figlet/fonts/, and you can of course add yours.

figlet [-f path to the font] [string]

Note: You will need to install “figlet” before you can use this command.


9. cowsay

cosway is very famous in the Linux world, but this command is not always present by default in every distribution. In Ubuntu, install it with the command:

sudo apt-get install cowsay

It displays a cow in ASCII art saying whatever string you want. It comes with a couple of other characters and you can add your own. The default directory for them is /usr/share/cows/. The syntax is:

cowsay [-f path of another character] [string for the cow]


10. fortune

fortune displays a random sentence, in the same spirit as fortune cookies. It is not always installed by default so you may want to add it. In Ubuntu:

sudo apt-get install fortune

It comes with a very handy option: “-s” for short, which will limit to fortunes composed of one sentence or less.



The fun part is now to combine the previous commands for a funnier result. A famous combination is fortune and cowsay, which creates a cow in ASCII art telling you a random fortune:


My personal favorite is a random character from cowsay telling you a random short fortune:

cowsay -f "$(ls /usr/share/cows/ | sort -R | head -1)" "$(fortune -s)"


To explain briefly, it is the same as earlier: a random fortune is pushed into cowsay, but I added the option “-f” for selecting a character. The path given is a combination of listing the files from within the default directory for the characters, random sorting of this list, and keeping only the first line.

But I suppose that you could also do something like


in order to repeat a piece of ASCII art, or even

cowsay "$(seq -f '4/%g' 1 2 99999 | paste -sd-+ | bc -l)"

to have a cow telling you the approximation of pi.

As always when exploring the console, there are a lot of things that can be done (even if doing them seems very useless).

Friday, February 28, 2014

Best Introduction to GIT


I attended an interview recently, where my interviewers seemed more interested in what kind of Revision Control system I had used than my actual technical skill set. I think they use CVS internally, and almost all the interview questions was around change management, and conflict resolution during code merges. Now I made it very clear that as a Siebel developer, I had got to use very little revision control systems so far, the most common reason being cost. My clients did not want to invest in a full revision control software, as it would jack up the project cost. Siebel’s own inbuilt one-object-can-be-checked-out-only-by-one-person system worked most of the time, beautifully.

But this got me thinking..revision control is a big problem in huge and specially long software projects. I have been hearing a lot about this new free revision control software called GIT, built by Linus Torvalds himself. When I got some time, I began reading about it online.

After going through many text and video based tutorials about GIT, I finally hit pay-dirt when I saw this video. Simply put, the best introduction to GIT and GITHUB there is.

Check it out. Its your fastest way to get started.

Tuesday, December 10, 2013

The Origin of 0 index arrays


Sometimes somebody says something to me, like a whisper of a hint of an echo of something half-forgotten, and it lands on me like an invocation. The mania sets in, and it isn’t enough to believe; I have to know.

I’ve spent far more effort than is sensible this month crawling down a rabbit hole disguised, as they often are, as a straightforward question: why do programmers start counting at zero?

Now: stop right there. By now your peripheral vision should have convinced you that this is a long article, and I’m not here to waste your time. But if you’re gearing up to tell me about efficient pointer arithmetic or binary addition or something, you’re wrong. You don’t think you’re wrong and that’s part of a much larger problem, but you’re still wrong.

For some backstory, on the off chance anyone still reading by this paragraph isn’t an IT professional of some stripe: most computer languages including C/C++, Perl, Python, some (but not all!) versions of Lisp, many others – are “zero-origin” or “zero-indexed”. That is to say, in an array A with 8 elements in it, the first element is A[0], and the last is A[7]. This isn’t universally true, though, and other languages from the same (and earlier!) eras are sometimes one-indexed, going from A[1] to A[8].

While it’s a relatively rare practice in modern languages, one-origin arrays certainly aren’t dead; there’s a lot of blood pumping through Lua these days, not to mention MATLAB, Mathematica and a handful of others. If you’re feeling particularly adventurous Haskell apparently lets you pick your poison at startup, and in what has to be the most lunatic thing I’ve seen on a piece of silicon since I found out the MIPS architecture had runtime-mutable endianness, Visual Basic (up to v6.0) featured the OPTION BASE flag, letting you flip that coin on a per-module basis. Zero- and one-origin arrays in different corners of the same program! It’s just software, why not?

All that is to say that starting at 1 is not an unreasonable position at all; to a typical human thinking about the zeroth element of an array doesn’t make any more sense than trying to catch the zeroth bus that comes by, but we’ve clearly ended up here somehow. So what’s the story there?

The usual arguments involving pointer arithmetic and incrementing by sizeof(struct) and so forth describe features that are nice enough once you’ve got the hang of them, but they’re also post-facto justifications. This is obvious if you take the most cursory look at the history of programming languages; C inherited its array semantics from B, which inherited them in turn from BCPL, and though BCPL arrays are zero-origin, the language doesn’t support pointer arithmetic, much less data structures. On top of that other languages that antedate BCPL and C aren’t zero-indexed. Algol 60 uses one-indexed arrays, and arrays in Fortran are arbitrarily indexed – they’re just a range from X to Y, and X and Y don’t even need to be positive integers.

So by the early 1960′s, there are three different approaches to the data structure we now call an array.

  • Zero-indexed, in which the array index carries no particular semantics beyond its implementation in machine code.
  • One-indexed, identical to the matrix notation people have been using for quite some time. It comes at the cost of a CPU instruction to manage the offset; usability isn’t free.
  • Arbitrary indices, in which the range is significant with regards to the problem you’re up against.

So if your answer started with “because in C…”, you’ve been repeating a good story you heard one time, without ever asking yourself if it’s true. It’s not about*i = a + n*sizeof(x) because pointers and structs didn’t exist. And that’s the most coherent argument I can find; there are dozens of other arguments for zero-indexing involving “natural numbers” or “elegance” or some other unresearched hippie voodoo nonsense that are either wrong or too dumb to rise to the level of wrong.

The fact of it is this: before pointers, structs, C and Unix existed, at a time when other languages with a lot of resources and (by the standard of the day) user populations behind them were one- or arbitrarily-indexed, somebody decided that the right thing was for arrays to start at zero.

So I found that person and asked him.

His name is Dr. Martin Richards; he’s the creator of BCPL, now almost 7 years into retirement; you’ve probably heard of one of his doctoral students Eben Upton, creator of the Raspberry Pi. I emailed him to ask why he decided to start counting arrays from zero, way back then. He replied that…

As for BCPL and C subscripts starting at zero. BCPL was essentially designed as typeless language close to machine code. Just as in machine code registers are typically all the same size and contain values that represent almost anything, such as integers, machine addresses, truth values, characters, etc. BCPL has typeless variables just like machine registers capable of representing anything. If a BCPL variable represents a pointer, it points to one or more consecutive words of memory. These words are the same size as BCPL variables. Just as machine code allows address arithmetic so does BCPL, so if p is a pointer p+1 is a pointer to the next word after the one p points to. Naturally p+0 has the same value as p. The monodic indirection operator ! takes a pointer as it’s argument and returns the contents of the word pointed to. If v is a pointer !(v+I) will access the word pointed to by v+I. As I varies from zero upwards we access consecutive locations starting at the one pointed to by v when I is zero. The dyadic version of ! is defined so that v!i = !(v+I). v!i behaves like a subscripted expression with v being a one dimensional array and I being an integer subscript. It is entirely natural for the first element of the array to have subscript zero. C copied BCPL’s approach using * for monodic ! and [ ] for array subscription. Note that, in BCPL v!5 = !(v+5) = !(5+v) = 5!v. The same happens in C, v[5] = 5[v]. I can see no sensible reason why the first element of a BCPL array should have subscript one. Note that 5!v is rather like a field selector accessing a field in a structure pointed to by v.

This is interesting for a number of reasons, though I’ll leave their enumeration to your discretion. The one that I find most striking, though, is that this is the earliest example I can find of the understanding that a programming language is a user interface, and that there are difficult, subtle tradeoffs to make between resources and usability. Remember, all this was at a time when everything about the future of human-computer interaction was up in the air, from the shape of the keyboard and the glyphs on the switches and keycaps right down to how the ones and zeros were manifested in paper ribbon and bare metal; this note by the late Dennis Ritchie might give you a taste of the situation, where he mentions that five years later one of the primary reasons they went with C’s square-bracket array notation was that it was getting steadily easier to reliably find square brackets on the world’s keyboards.

“Now just a second, Hoye”, I can hear you muttering. “I’ve looked at the BCPL manual and read Dr. Richards’ explanation and you’re not fooling anyone. That looks a lot like the efficient-pointer-arithmetic argument you were frothing about, except with exclamation points.” And you’d be very close to right. That’s exactly what it is – the distinction is where those efficiencies take place, and why.

BCPL was first compiled on an IBM 7094here’s a picture of the console, though the entire computer took up a large room – running CTSS – theCompatible Time Sharing System – that antedates Unix much as BCPL antedates C. There’s no malloc() in that context, because there’s nobody to share the memory core with. You get the entire machine and the clock starts ticking, and when your wall-clock time block runs out that’s it. But here’s the thing: in that context none of the offset-calculations we’re supposedly economizing are calculated at execution time. All that work is done ahead of time by the compiler.

You read that right. That sheet-metal, “wibble-wibble-wibble” noise your brain is making is exactly the right reaction.

Whatever justifications or advantages came along later – and it’s true, you do save a few processor cycles here and there and that’s nice – the reason we started using zero-indexed arrays was because it shaved a couple of processor cycles off of a program’s compilation time. Not execution time; compile time.

Saturday, October 19, 2013

You Don't Need Millions of Dollars

Masters of Doom is the story of John Carmack and John Romero creating the seminal games Wolfenstein 3D, Doom, and Quake.


It's an amazing work on so many levels – but primarily because of the exhaustive research the author undertook to tell this story.

To re-create the story of the Two Johns, I conducted hundreds of interviews over six years, often with each person on multiple occasions. After moving to Dallas in the fall of 2000 for research, I became known in offices, barbecue joints, and bars around town as “the guy writing the Book.” John Romero and John Carmack each spent dozens of hours in person answering my most picayune questions: how they were feeling, what they were thinking, what they were saying, hearing, seeing, playing. What they and others couldn’t recall, I unearthed from websites, newsgroups, e-mails, chat transcripts, and magazines (though I drew from some of these articles, I made a point of getting the gamers’ own versions of what happened as well). I also played a delirious amount of games: at home, online, and at a couple tournaments (yeah, I lost).

I spent six months transcribing all my taped interviews. From this material, I assembled a narrative of dialogue and description that re-creates the events as faithfully and accurately as possible. As often as appropriate, I told the story from each person’s point of view to give readers the different perspectives.

It's unusual to find a book about a contentious, complex friendship and business relationship that both parties sign off on – and even a decade later, regularly recommend to people interested in their personal back stories. But it is a testament to just howright Kushner got this story that both Romero and Carmack do. This is exactly the sort of meticulously researched, multiple viewpoint biography that you'd want to read about important people in your industry. In that sense, it's kind of the opposite of the Jobs biography, which I liked well enough, but it presented one viewpoint, and often in a very incomplete, sloppily researched way. I would kill to read a book this good about Jobs.

In a way, I grew up with these guys. I am almost exactly the same age they are. I missed the Wolfenstein 3D release because I was still in college, but come December 1993, there I was, bursting with anticipation waiting for the release of Doom along with every other early PC gamer. And who gave Doom its name? Oddly enough, Tom Cruise did.

I've had a lifelong love affair with first person shooters since encountering Wolf3D and Doom. I played about every Doom engine game there was to death. I even had a brief encounter with Romero himself on the modem based multiplayer hub DWANGO where I proverbially "sucked it down". And after the Internet hit around '95, I continued to follow Quake development obsessively online, poring over every .plan file update, and living the drama of the inevitable breakup, the emergence of GLQuake and 3D accelerators, and the road to Quake 3.

It is also an incredibly inspiring story. Here's a stereotypical group of geeky programmers from sketchy home backgrounds who went on to … basically create an entire industry from scratch on their own terms.

Shareware. Romero was familiar with the concept. It dated back to a guy named Andrew Fluegelman, founding editor of PC World magazine. In 1980, Fluegelman wrote a program called PC-Talk and released it online with a note saying that anyone who liked the wares should feel free to send him some “appreciation” money. Soon enough he had to hire a staff to count all the checks. Fluegelman called the practice “shareware,” “an experiment in economics.” Over the eighties other hackers picked up the ball, making their programs for Apples, PCs, and other computers available in the same honor code: Try it, if you like it, pay me. The payment would entitle the customer to receive technical support and updates.

The Association of Shareware Professionals put the business, largely domestic, between $10 and $20 million annually—even with only an estimated 10 percent of customers paying to register a shareware title. Forbes magazine marveled at the trend, writing in 1988 that “if this doesn’t sound like a very sound way to build a business, think again.” Shareware, it argued, relied not on expensive advertising but on word of mouth or, as one practitioner put it, “word of disk.” Robert Wallace, a top programmer at Microsoft, turned a shareware program of his called PC-Write into a multimillion-dollar empire. Most authors, however, were happy to break six figures and often made little more than $25,000 per year. Selling a thousand copies of a title in one year was a great success. Shareware was still a radical conceit, one that, furthermore, had been used only for utility programs, like check-balancing programs and word-processing wares. [Shareware] had never been exploited for games.

Does anyone even remember what shareware is? What is the equivalent to shareware today? Distributing software yourself on the Internet? Sort of. I'd say it's more analogous to the various app stores: Google Play, Apple App Store, Windows Store. Going directly to the users. But they found shareware games didn't work, at least initially:

When it came time to distribute the games, Scott took a long, hard look at the shareware market. He liked what he saw: the fact that he could run everything himself without having to deal with retailers or publishers. So he followed suit, putting out two text-based games in their entirety and waiting for the cash to roll in. But the cash didn’t roll; it didn’t even trickle. Gamers, he realized, might be a different breed from those consumers who actually paid for utility shareware. They were more apt simply to take what they could get for free. Scott did some research and realized he wasn’t alone; other programmers who had released games in their entirety as shareware were broke too. People may be honest, he thought, but they’re also generally lazy. They need an incentive.

Then he got an idea. Instead of giving away the entire game, why not give out only the first portion, then make the player buy the rest of the game directly from him? No one had tried it before, but there was no reason it couldn’t work. The games Scott was making were perfectly suited to such a plan because they were broken up into short episodes or “levels” of play. He could simply put out, say, fifteen levels of a game, then tell players that if they sent him a check he would send them the remaining thirty.

You know how game companies spent the last 5 years figuring out that free games with 100% in-app purchases are the optimum (and maybe, only) business model for games today? The guys at id had figured that all out twenty seven years ago. Those sounds you hear in the distance are a little bit of history repeating.

Id Software was more than a unique business model that gave almost all the power to the programmers. It was the explosive combination of shareware delivery with a particular genius programmer inventing new techniques for PC games that nobody had seen before: John Carmack. It may sound prosaic and banal now, but smooth scrolling platforming, texture mapped walls, lighting models, and high speed software 3D rendering on a PC were all virtually unheard of at the time Carmack created the engines that made them commonplace.


Carmack, like Abrash, is a legend in programming circles, and for good reason. The stories in this book about him are, frankly, a little scary. His devotion to the machine borders on fanatical; he regularly worked 80 hour weeks and he'd take "vacations" where it was just him and a computer alone in a hotel room for a whole week – just for fun, to relax. His output is herculean. But he also realizes that all his hard work is made possible by a long line of other programmers who came before him.

Al had never seen a side scrolling like this for the PC. “Wow,” he told Carmack, “you should patent this technology.

Carmack turned red. “If you ever ask me to patent anything,” he snapped, “I’ll quit.” Al assumed Carmack was trying to protect his own financial interests, but in reality he had struck what was growing into an increasingly raw nerve for the young, idealistic programmer. It was one of the few things that could truly make him angry. It was ingrained in his bones since his first reading of the Hacker Ethic. All of science and technology and culture and learning and academics is built upon using the work that others have done before, Carmack thought. But to take a patenting approach and say it’s like, well, this idea is my idea, you cannot extend this idea in any way, because I own this idea—it just seems so fundamentally wrong. Patents were jeopardizing the very thing that was central to his life: writing code to solve problems. If the world became a place in which he couldn’t solve a problem without infringing on someone’s patents, he would be very unhappy living there.

In that spirit, Carmack regularly releases his old engines under GPL for other programmers to learn from. Don't miss Fabien Sanglard's epic deconstruction of the Doom 3 codebase, for example. That's only one iteration behind the current id enginewhich was used for Rage and (apparently) will be used for the upcoming Doom 4.

One of my very favorite quotes of all time comes at the end of the book.

Carmack disdained talk of highfalutin things like legacies but when pressed would allow at least one thought on his own. “In the information age, the barriers just aren’t there,” he said. “The barriers are self-imposed. If you want to set off and go develop some grand new thing, you don’t need millions of dollars of capitalization. You need enough pizza and Diet Coke to stick in your refrigerator, a cheap PC to work on, and the dedication to go through with it. We slept on floors. We waded across rivers.”

And indeed they did, as the book will attest. Both @ID_AA_Carmack and @romero are still lifelong, influential, inspiring members of the game and programming communities. They are here for the long haul because they love this stuff and always have.

The ultimate point of Masters of Doom is that today you no longer need to be as brilliant as John Carmack to achieve success, and John Carmack himself will be the first to tell you that. Where John was sitting in a cubicle by himself in Mesquite, Texas for 80 hours a week painstakingly inventing all this stuff from first principles, on hardware that was barely capable, you have a supercomputer in your pocket, another supercomputer on your desk, and two dozen open source frameworks and libraries that can do 90% of the work for you. You have GitHub, Wikipedia, Stack Overflow, and the whole of the Internet.

All you have to do is get off your butt and use them.