shahriarA dreamer, an inventor, a big time procrastinator…

I don’t claim to be a religious person. However I do view religion as a part of my identity, just like my nationality. Just like I won’t tolerate racist behavior against Bangladeshis, I wouldn’t tolerate mistreatment of Muslims either. However the opposite scenario is also true. Just like how I am sickened when I hear about a Bangladeshi doing something stupid to ruin our reputation, I am also ashamed when a fellow Muslim make us all look misinformed. This is really what this rant is all about.

Since the olden days of “Hotmail” people have been forwarding emails containing scientifically inaccurate “proofs” of vague concepts mentioned in the Quran. Even with the advent of social networks, people haven’t changed much. I still see some of my Facebook friends copy and paste statuses that outrageously inaccurate. Here’s one of my recent favorites:

So “all the rays will emit from your brain to earth”, will it? As if electromagnetic waves are like water drops and will drip of your hair when you lower your head? So why I don’t see sunlight coming out of ears when you pray. Or why not the latest episode of America’s got Talent? They are all electromagnetic waves just like mobile signals.

I don’t mind people posting religious content on Facebook. In fact I actually encourage it because social networks are a great way of reaching out to people and I don’t see why religious scholars shouldn’t make use of it. I would just like to see authentic material. Quote something inspiring from the Quran, or a Hadith. Translate it into English or in your mother-tongue so others can understand. Just stop posting this non-scientific nonsense. You guys are all educated people. Just exercise your high-school science skills before copying statuses and spreading religious spam.

And if you would like to go the extra mile, click next to the post and mark it as spam to help stop spread this disease.

It’s not a perfect cinegraph, but she’s adorable nonetheless…

University professors want you to believe that if you are failing to meet your deadlines you are “not managing your time properly”. This is not true for a number of reasons.

In real life people hardly shove deadlines down your throat. The way it usually works is the project manager first lists all the activities that needs to be done. Then all the “owners” of each activity gives an estimate on how long each activity will take. And then, based on the program’s priorities, the PM assigns deadlines for every activity trying to respect the estimated durations as much as possible.

In a way, professors are actually doing more harm to you by giving you deadlines in the first place. The most important skill for a developer working in the real world, is the ability to reliably estimate the duration of work. Deadlines are okay during the freshmen and sophomore years. There isn’t any significant amount of coding in the first two years. But from your third year and onwards, you are faced with 4-6 week long programming assignments. This is something that requires a bit of planning. Depending on the courses you take in your Junior year, the deadlines for your 4-6 week long assignment may not be compatible with your workload from other courses. In real life, you would first look at all your assignments from all your courses, set priorities to them, and then *plan* for a 4-6 week long slot at some point during the semester. This kind of project management skill is vital for a developer to succeed in real life. A pre-determined schedule is not guaranteed to work for every student.

Scenario 1

Alice: But the user selected X, but here the app says Y.

Bob: Ah ! Yes, it’s just a cosmetic error. We’ll fix that in the next release.

Scenario 2

Alice: We have revamped our UI to look pretty, but I think steps 2 and 4 of our check out process are very confusing.

Bob: I appreciate your feedback, but we have budget, resource, and time constraints. We cannot always strive to be perfectionists.

Scenario 3

Alice: I think we can design a better user experience by designing a custom page rather than relying on the templates provided by our BPM software.

Bob: But we paid so much for this BPM software. We must use its out-of-the-box features.

Wish I could say

• A cosmetic error is when you display the right information but maybe the alignment is a bit off.
• If we had spent our budget and resources on making steps 2 & 4 more intuitive, we would have a better product.
• Three words: “Sunk Cost Fallacy”. You cannot get back what you already invested. The least you could do is to stop accumulating further expenses and making the right choices.

In Java, you can do this:

ArrayList<double> list = new ArrayList<double>();
list.add(5);
double d = list.get(0);

Since 1.5 you can assign Doubles to doubles and Integers to ints and so on. Also since the dawn of time you can do the following:

MyClass obj = new MyClass();
System.out.println(obj);

Passing an object reference to System.out implicitly calls the toString() method. Even though this is not considered auto-boxing, from a coding perspective they provide the same feature “implicit method calling”. I see why we shouldn’t be able to do this for any class we write. Just as would override the toString() method, I could also override default auto-boxing method.

Welcome to a new series of blog posts dedicated to documenting my attempts at developing a high quality UI in Java. As a case study I am choosing to port the iPad version of the popular Things application to Java. My end result should look something like this:

From the looks of it, Things does not seem to be a very complicated application. The UI is fairly straightforward. The total number of interactions between different components also feels reasonable. But the devil is in the details. Implementing the same functionality in a Java application is a piece of cake, but getting all the subtle visual elements right is the tricky part.

Here are the things I would like to investigate over the next few days:

1. Light to dark gray gradient around the edges.
2. 3D emboss effect of the button
3. Implementing the todo list pane as JTables

I started off, with the first task in my list: trying to mimic the gradient. And this what I got:

Not even close to the iPad version. The gradient has only been applied vertically whereas the original version applies it to all the edges. Moreover, there are visible bands of color instead of a smooth gradient. I read somewhere that this might be due to my monitor. But I have a nice HD screen, so I don’t think this is the case. Hopefully, when I use the LinearGradientPaint class in Java and restrict the gradient to near the edges, this won’t be much of a problem.

1. Write the following piece of code in a F95 file

		/* foo.f95 */

        integer function add2i(x, y)
        integer, intent(in) :: x, y
        add2i = x + y
        end function add2i

2. Create a position independent object file (foo.o)

gfortran -c -fPIC foo.f95

3. Create a dynamic shared library (libfoo.so)

gfortran -shared foo.o -o libfoo.so

4. Write the following piece of C code that invokes the fortran function (test.c)

#include <stdio.h>
#include <stdlib.h>

extern int add2i_(int *x, int *y);

int main(int argc, char *argv[]){
  int x = 3;
  int y = 5;
  int z = add2i_(&x,&y);

  printf("result is %d\n", z);
}

Note that the you must append an underscore ‘_’ to the name of the Fortran function in the prototype. Moreover, Fortran uses a pass by reference mechanism. Therefore the arguments need to passed as pointers.

5. Compile the C code into an object code (test.o)

gcc -c test.c

6. Link the compiled object file with the Fortran shared library and create an executable (a.out)

gfortran test.o -L/path/to/dll -lfoo -Xlinker -rpath /path/to/dll

1. Write the following piece of code in a C file:

/* foo.sh */
#include "stdio.h"
#include "stdlib.h"

int add(int x, int y){
    return x + y;
}

2. Create a Position Independent Code object file

gcc -fPIC -c foo.c

3. Create a shared library from the object file

gcc -shared foo.o -o libfoo.so

4. Create a C header file with the function prototypes of the shared library

/* libfoo.h */
extern int add(int x, int y);

5. Create a SWIG interface file that includes the header file

/* example.i */
%module example
%{
#include "libfoo.h"
%}
%include "libfoo.h"

6. Run Swig to generate glue code

swig -perl5 example.i

7. Compile glue code (example_wrapper.c) against Perl’s own shared libraries

gcc -c -fPIC example_wrap.c `perl -MExtUtils::Embed -e ccopts`

8. Link compiled glue object against our shared library (libfoo.so) and package it into a new shared library (example.so)

gcc -shared example_wrap.o -L/path/to/dll -lfoo -Xlinker -rpath /path/to/dll -o example.so

9. Write a perl script to use the shared library

use example;
my $result = example::add(3,5);
print "$result\n";

We all have our ways of writing comments in our code. Some prefer huge blocks of text at the beginning of a source file. Some prefer a paragraph before every chunk of code. Sometime we sprinkles a few one-liners here and there to explain a cryptic regular expression or two. But no matter how we write comments, they always get in our way of coding. That’s why we end up spending very little time documenting. It makes your code longer. Adding new code in between always messes up the comments and then you have to spend some more time realigning comments. Look at the following screenshot and see if any bright ideas come to mind.

Dual-pane source/comment view