# 5 things I have gained from SICP: Section 1.2

Alhamdulillaah I finally completed section 1.2 of the SICP classic. I was amazed I took almost 150 days to complete 61 pages. I definitely need to sit up! Reading the text was not challenging, the bottleneck was ‘forcing’ getting myself to finish the exercises.

I was going to start on section 1.3 but I felt it would be better to reflect on the knowledge gained first.

1. A deeper understanding of procedures and their processes

Not all procedures are created equal – seemingly recursive procedure can be iterative in execution. Moreover, there is nearly always a way to make a recursive procedure execute in an iterative manner. This can lead to speed gains and also help you handle HUGE data.

Programming is deeper than I thought…

2. Mathematics

My Mathematical forays are usually related to Computer Science or Machine learning however I got to dabble into new fields. First was the Ackermann function; a fascinating recursive function which grows with mind-boggling speed – you have to think hard to grasp this. Next came primality testing and probabilistic approaches to prime number verification.

The Fermat test is good enough however it is fooled by the Carmichael numbers. To be sure, use the Miller-Rabin test.

I do not know how much of these will be useful in real-life but yeah… it is good to know.

3. Algorithms – exponentiation

The rapid exponentiation algorithm was an eye-opener – do stuff twice as fast :). Once you implement the ‘speed-up’ and ‘slow-down’ functions and handle all cases properly, you can take down exponentiation from a O(n) operation to a O(log n) operation. Combining this with a ‘tweaked’ recursive-but-iterative-in-execution procedure leads to ‘tales’ of joy…

It was also interesting to see how minor changes to code could wipe out performance gains made from clever algorithms. Exercise 1.26  showed how easy it was to lose the O(log n) gains from exponentiation by doing irrelevant work. A subtle ‘refactoring’ might have huge implications…

5. Perseverance

I initially find most exercises daunting and struggle to understand the task. I force myself to think about the problem for at most 15 minutes; if I still do not get it, then I allow myself to look at available solutions.

Alhamdulillaah I usually figure out the solution during the time window and then look up existing solutions to see other problem-solving approaches. I have also looked up solutions when I got stuck too – I was seeking ‘inspiration‘ :). It’s great to know we can solve most problems if we only persevere insha Allaah.

And that’s about it! Section 1.3 has about 18 exercises; since I typically solve an exercise in about 2 – 3 days (I have a 25 minute daily study schedule), I hope to be done with this section in about 4 – 6 weeks insha Allaah. Watch out for a new update then insha Allaah.

Here are my solutions on Github.

Here are a couple of my more academic-themed musings

# How to add in programming languages

This is a tongue-in-cheek attempt to expose programming language expressiveness.

1. Scheme

(+ 1 2)
(+ 1 2 3 4)
• Characters needed to add n digits: + 3
• Prefix notation allows passing in multiple operands
• Prefix notation is not popular

2. JavaScript/Python/Ruby/Octave/Matlab

1 + 2
• Characters needed to add n digits: + (n – 1)
• Very simple and generally accepted
• Infix form requires two operands leading to (n – 1) operators

3. Java/C#

//CSharp
class Program
{
static void Main(string[] args)
{
Console.WriteLine(1 + 2);
}
}
• Characters needed to add n digits: N (where N is a largeeeeeeee number 🙂 )
• Too verbose – you need a class to add two numbers

4. SQL

SELECT 1 + 2;
• Characters needed to add n digits: + 8
• Simple but not popular
• Declarative nature can impact clarity

Do you know of any other language examples? Feel free to share in the comments!

Here are a couple of other posts you might also like:

18 Minutes: Find Your Focus, Master Distraction, and Get the Right Things Done

Quite a good read; I especially like the tips on slowing down before reacting, doing less and improving focus. A tip I want to take away is planning my day ahead and fixing times for actions (something I do not currently do). I also like the way the author prunes his to-do list and the end-of-day reviews. Overall, I think this is a good book and I learnt some new tricks Alhamdulillaah.

A Microsoft Life

Doesn’t really teach anything new or technical; some stories about Microsoft, some humour and a lot of strong language. I found some parts off-putting.

# Defining JavaScript Functions

There are many ways to create functions in JavaScript; some styles are quite popular e.g. the function declaration and function expression while others are not.

//function samples
function declaration () {};
var funcExpression = function () {};
var namedFuncExpression = function named() {};
var fnConstructor = new Function ();

All approaches create a Function object however there are a couple of differences under the hood. Lets take a peek…

1. Function Declaration

The function declaration pattern is one of the most common patterns.

function fn () {
//function body
}

Once a function is defined using the declaration format; it can be used anywhere in the enclosing scope even before the function body. Confusing? It’s all about hoisting.

2. Function Expressions

Functions are first class objects in JavaScript, thus it is possible to have expressions that evaluate to function values; such expressions are appropriately termed function expressions.

Creating a function expression is easy: just declare a function where the parser expects an expression and it automatically becomes a function expression. This includes assignments to variables and/or object properties, placing functions between parentheses (the grouping operator can only contain expressions),or after a unary operator (e.g. !, +, – etc).

//anonymous function expressions
var fnExpr = function () {};

(function fnExpr2() {} );

!function fnExpr3() {}

Function expressions can be named or anonymous; named function expressions (NFE) expose a function name that is available inside the function body but not outside it. See the snippet below:

var namedFuncExpression = function named() {
return named.name;
};

named();
//ReferenceError, named is not defined

namedFuncExpression();
//returns "named"

NFEs help to make debugging nicer (we all know how frustrating it is to keep seeing ‘anonymous’ functions in the debugger). It might also come in handy when you need to retrieve a function name by calling toString() or make recursive functions (although the variable name will also serve the same purpose).

Function expressions are essential to achieve functional programming concepts like currying and partial application in JavaScript.

3. Function Constructor

The last way is to use the function constructor, this constructs a function object and returns it.

There are a few things to note while using this approach: created functions can only access variables in the global scope or in their own scope and it is no possible to create closures. Moreover, the use of the function constructor is slower since the function body has to be parsed every time it is called. And there are potential risks from malicious agents.

var add = new Function('a','b', 'return a + b');

//3

var glbFoo = "global";
function scope() {
var scpFoo = "scoped";,
scop=Function('console.log(typeof scpFoo)'),
glob=Function('console.log(typeof glbFoo)');

scop();
glob();
}

scope();
//logs undefined
//logs string

The parameters to the function are passed in first and then the function body (as a string) is passed in as the last parameter and viola! the function object is returned. The new keyword is optional; it still works without the new.

4. Function expression vs Function declaration

Function declarations and their bodies get hoisted to the top of the scope (no matter where they appear – top, bottom or middle) and are thus available through the scope. However for function expressions, the variable declaration is hoisted while the assignment to the function body only happens at runtime. See the example below:

declared();
//logs declared
function declared () {
console.log('declared');
}

expressed();
//logs TypeError: undefined is not a function

var expressed = function () {
console.log('expressed ');
}
expressed();
//logs expressed

5. Spot the difference? Identifying function expressions and declarations in code

Differentiating between function expressions and declarations can be tricky. According to the ECMAscript specification, function declarations must have an identifier. If functions without identifiers are unequivocally function expressions, how do we distinguish between a function declaration and a named function expression?

Function declarations are only allowed as sourceElements of scripts or functions. They cannot appear in nested blocks because blocks are  only allowed to contain statements and not sourceElements. Expressions on the other hand are expressions… 🙂

//source element examples
var a = 0;
function b () {};
if (false) {
//nested, not source element
var c = 0;
function d () {};
}

//function declaration
function foo() {
//another declaration
function bar() {};

if(true) {
//function expression because
//it is not a source element
function baz() {};
}

//function expression
//expressions expected after unary operator
!function bng () {};
};

6. Finally…

Still reading? Here are some more examples of queer ways to create functions. Don’t do this at home/work/live/staging/etc.

var f = function (str) {
};
eval('f("eval")');

setTimeout('f("timeout")',1000);
};

Remember, don’t do this on live servers…

Did you enjoy this post? Here are a couple more interesting posts:

Update

Brilliant explanation of the difference between function and Function by Peter van der Zee:

“The `Function` is a global object and a function value, which generates a new function when called. You create new local variables named `Function` but not with `function` “

# Three Important JavaScript Concepts

Statements and Expressions

The MDN documentation defines JavaScript expressions as any valid unit of code that resolves to a value.

a = 1;
3 + 4;

The first expression has value 1 which is then assigned to variable a while the second has value 7 which is not assigned to anything.

Since expressions evaluate to values (numbers, strings, functions etc), they can be substituted anywhere these values are expected. Programmers just have to ensure expressions resolve to expected values because of JavaScript’s weak typing.

Consider the following simple statement:

var x = "statement";

This is a statement and not an expression. Statements do something while expressions evaluate to values.

Dr. Axel has an excellent post which differentiates both: “you can use expressions where statements are expected (these are called expression statements) however you cannot use a statement where an expression (i.e. something that evaluates to a value) is expected”.

To simplify; you cannot use the statement above as a condition for an if branch (which expects an expression or value).

Variable Scope

Scope determines the lifetime of variables and where they can be used. Most programming languages have block scope, i.e. variables only exist within enclosing blocks (usually delimited by braces). However, JavaScript has other ideas… Check the code snippet below.

function JSBlockScope() {
var noBlockScope = "BlockScope";
if(true) {
var noBlockScope = "FuncScope";
}
console.log(noBlockScope);
};

JSBlockScope();
//logs FuncScope

The output is “FuncScope”! Surprised? Block scope implies that declarations inside blocks do not overwrite external variables. JavaScript has function scope and consequently noBlockScope gets overwritten to ‘FuncScope’.

Function scope also means that variables declared inside functions are only available inside those functions, once the function exits, the variables are inaccessible anymore (well, unless you use closures…).

function scopeCheck() {
var functionScope = "inside Func";
console.log(functionScope);
};

scopeCheck();
//logs inside Func

console.log(functionScope);
//ReferenceError: functionScope is
// not defined

The functionScope variable defined inside the scopeCheck function only exists inside the body of the function.

Variables are first looked up in the current scope (i.e. the enclosing function), if not found, then the interpreter continues walking up enclosing scopes until it gets to the global scope. If the variable is not defined still; then the well-known “ReferenceError: variable is not defined” error occurs.

Hoisting

JavaScript has this weird but fascinating concept called hoisting. All variable declarations are hoisted – every variable gets declared immediately even though their values might not be set immediately.

function hoisting() {
console.log(hoistedVar);
var hoistedVar = "hoisted!";
console.log(hoistedVar);
}

hoisting();
//logs undefined
//hoisted!

Explanation

Confused? Well what happens is that all declarations are hoisted to the top before any code execution begins. The above code is totally similar to the one below:

function hoisting() {
var hoistedVar; //undefined
console.log(hoistedVar);
hoistedVar = "hoisted!";
console.log(hoistedVar);
}

hoisting();
//logs undefined
//logs hoisted!

The log statements show ‘undefined’ since this is the default value for uninitialized JavaScript variables. If they weren’t hoisted, the interpreter would have thrown a ReferenceError.

Hoisting also applies to functions (JavaScript functions are values afterall…) however there is a subtle difference between function declarations and expressions. Function declarations get hoisted to the top and are immediately available within the scope while function expressions are only declared and not hoisted (much like the same case for variables above).

function isFunc(fn) {
var isFn = (typeof fn === 'function');
console.log(isFn);
}

function isUndef(fn) {
var ntDef = (typeof fn === 'undefined');
console.log(ntDef);
}

function funcHoisting() {
isUndef(declaredFn); //false
isUndef(hoistedFn);  //true

function declaredFn () {};
var hoistedFn = function () {};

isFunc(declaredFn); //true
isFunc(hoistedFn);  //true
}

funcHoisting();

Declaring variables at the top of functions helps to avoid hoisting surprises.

Conclusion

I was going to write about function expressions vs declarations, however I believe these three JavaScript concepts would significantly make it easier to understand that topic. Insha Allaah I’ll publish the function expression vs declaration post next.

Meanwhile, here are some other posts you might like:

# Maximizing Value: Learning to do less

I have always been concerned with maximizing efficiency for a long time; before, it meant learning everything I could in the shortest time possible. To me then, ‘done’ meant completing a book or series of videos and this blinded me from verifying acquired knowledge. So I mostly went from one book to another without challenging myself to find real-life applications.

The trend continued when I began at Masdar: I tried to read all the library books I had longed to read, signed up for a lot of online courses and took on side projects. I soon got burnt out (I was doing too much at once) and quickly learnt to respect my limits.

The unpleasant burnout experiences also made me review my daily schedule: were all the tasks really completed? I started planning my days, used pomodoro time blocks to improve my focus and abandoned multi-tasking. My ‘completion’ speed dropped however Alhamdulilah I started completing stuff consistently without getting burnt out.

There is a long ever-growing list of fascinating things I want to do however I know I can’t do everything. A couple of days back I started to question my activities: how have I applied the stuff I keep learning? What were the results? Have I been doing the right things? Alhamdulilah I can reasonably follow up on tasks consistently now, so the next challenge is to focus on the right things.

Insha Allaah I hope to improve by aggressively whittling down the fascinating list of to-dos, everything I do should have an impact or align with my goals. Less can actually be more…

Insha Allaah I’ll be asking these four questions:

1. What am I doing?

2. Why am I doing this?

3. Does this align with my purpose?

4. Am I doing it well enough?

Summary (tl;dr)

Know that you can not do everything, know your limits and then do the things you can do excellently. Finally, always remember to pray to Allaah and rely on Him totally as all success is from Him alone.

May Allaah bless all our efforts and grant us all success.

# Memories of Masdar: 2011 – 2013

I wrote a memories of Ife piece after completing my bachelors and it would be just as well to write another post about my time at Masdar. Masdar is a great school, has an international student community, extremely nice people, an awesome nearly unbeatable welfare package and a great beautiful environment.

I arrived at MASDAR in the fall of 2011 as a young naïve man with some basic development experience. Something unexpected happened just before I resumed; that event, which left an unpleasant indelible mark, propelled me to give my all and Alhamdulilah I emerged as a better person in the end.

The first few months were somewhat lonely – it was an unfamiliar emotion as I was used to being alone and far away from family all my life. The feelings of loneliness soon vanished when lectures went into full gear. I had thought everything would be super easy however I soon realized I had grossly underestimated the coursework involved as I struggled to understand some of the material and complete projects.

My interest in socio-mobile computing got me involved in the joint SCAIlab-MIT social fitness project. It involved extending a Pedometer app with social networking support, data collection, accuracy tweaking and influence mechanism design. Although the project was not completed, I got to learn more Android programming as well as Git.

I spent my first break solving Project Euler puzzles (a way to simultaneously hone my new Python skills), polishing my résumé and hunting for internships ( I applied to about 10+ software firms).

During my second semester, I got to learn more about Algorithms, distributed systems (hadoop, Skype, networking etc) and social computing. In my spare time, I learnt vim (and I am glad I did) using the excellent byte of vim book. Alhamdulilah, I spent the summer as a SDET intern with the Microsoft TFS Agile team.

In my last year, I finally took the dreaded software engineering ( got to learn about C, valgrind, make etc.) and sustainability courses. I also had to work extremely hard and at an insane pace to make up for the time I lost duing my internship. My first attempt didn’t turn out well so I had to start afresh.

Gains at MASDAR

Sometimes the loneliness and extreme levels of hard work got to me – the emotional drain and stress were just too much at times. I had to force myself to persevere ( giving up was easy but too costly) and I repeatedly prayed to Allaah to bless my sacrifices and efforts. Looking back, I am glad I got to improve on some of my weaknesses.

I improved my time organization, goal setting and progress tracking skills. I learnt to focus ( after getting burnt out a gazillion times) and also realized that I had a limit and couldn’t do everything. It was good to learn that being consistent was much better than alternating between periods of high and low productivity.

It was also at MASDAR that I started making conscious efforts to improving the quality of blog posts. The goals were quite clear: I wanted to create a knowledge repository for myself (something I can always refer to when I am in doubt), improve my writing and inform people. Now, when I write, I ask the ‘so what?’ question :).

My academic training equipped me with lots of computer science / software engineering knowledge. I got to conquer my fear of public speaking, honed my leadership skills and teamwork contribution. Oh, and I picked up the habit of continuously enrolling in online courses. Learning never ends…

I made a couple of true friends: the camaraderie, the teasing, the play, the talks and the sharing actually enabled me to come out of my shell. I met people who were extremely nice, friendly and wonderful. I couldn’t have asked for better companions and I do hope we’ll keep in touch for life.

It wasn’t all fun at MASDAR though – there were a couple of unpleasant experiences as expected. However I am glad because I learnt from such experiences too. In the end, I think I became more mature and discovered the meaning of self-worth.

I have left MASDAR now (I actually felt bad leaving MASDAR because I had become so attached) however I hope the lessons I learnt there would stay with me, that I have friends for life and have become a better person for it.

# EmberJS: The Rant

So I started on EmberJS some time last year; after spending an inordinate amount of time trying to design a prototype with people located all across the world. Finally, after several dreary demanding iterations and lots of work, we finally agreed on an implementation.

One of the dev members suggested using EmberJS or backbone. Based on his review, backbone was the easier choice: it had more support, good documentation, lots of tutorials, books and thousands of stackoverflow questions (a good measure of  tool/framework/concept popularity).

My own review confirmed these but I stubbornly stuck with EmberJS – I don’t know why, maybe I like challenges or maybe I just wanted to be different. Furthermore, my review revealed a few advantages of using EmberJS over Backbone so I dived into it.

I soon came to regret my decision; after a couple of tutorials, I seemed to be getting no where closer to understanding the framework. The problem was the volatile nature of the EmberJS framework, most tutorials would only work if you used the ‘matching’ framework release. The Ember team was most probably working themselves to the death to get it stable, however, for me, it was challenging, frustrating and annoying to use the framework.

Alhamdulilah I finally got it to work – my first attempt felt ugly and inelegant (add whatever else you like ) but it did work and that was fine enough for me. I soon fell in love with all the extra goodies and automatic help it provided; my colleague was soon inundated by my fawning; most probably he got tired of hearing me say ‘EmberJS is coooooooool’.

Organizing the application proved to be another challenge too; I had a huge ugly proliferation of files – controller, templates, views etc. RequireJS, an AMD loader provided a solution but not before nearly driving me crazy; I inadvertently swapped some parameters in the module specification and had to spent the better part of an hour trying to understand why the login object was a registration object. (Imagine trying to find out why a dog is a cat).

So after weeks of development and finally getting the app nicely running, I got another shocker. There was a new release of EmberJS and guess what? It was not backward compatible! To the credit of the guys though; the new release was awesome, had excellent documentation and was much easier but all I saw was the fact that I’d need to rework everything. All my sweats, efforts and tears were going to go down the drain just like that! No way!! I stuck with the old way and old api – it was much easier for me and upgrades aren’t compulsory.

I have learnt at least two things: one, if you use code that is in rapid flux then you are O.Y.O (ON your OWN) and two, stop testing the waters with your feet, just jump in! If you want to try something new, go get it done!

Back to the story; we did a system redesign again (yes, for the umpteenth time). I believe we are in good shape to do a great job now insha Allaah and yes we are upgrading to the latest EmberJS release – we have some veterans now.

Enough said, I have to get back to work 🙂

# Automate Builds using GruntJS

I already wrote about the awesomeness of GruntJS and here is how to set up your own Grunt system.

#### 1. Installation

GruntJS runs on nodejs so you need that installed first. Once nodejs and npm are installed, use the following command to install Grunt (the -g flag installs it globally).

npm install -g grunt-cli

This installs the grunt cli tool, next you need to create your project deployment. Navigate to your target project directory and type the following commands:

npm init

npm install grunt

You can safely use the defaults suggested during the npm init process; this process creates a package.json file which contains information about the licence, repository, author and blah blah blah. You can also use pre-created package.json files to tell the node package manager what dependencies to install.

Make sure you keep the package.json file safe – it can be used to recreate your project or share project details with other developers. If you get weird errors, try prefixing the commands with sudo.

Type grunt now and if you this error: ‘A valid Gruntfile could not be found…‘; then give yourself a pat on the back! 🙂

#### 2. Using Grunt

Creating a Gruntfile is easy; it’s mostly ‘JSON-y’ syntax; however you’ll need to install dependencies and extra features you need. The location of the Gruntfile does not matter: when you run grunt, it will walk up the directory tree until it finds a Gruntfile. So just drop the Gruntfile in the root of your project and you can grunt happily from any sub-directory.

When installing new plugins, remember to add the –save-dev switch so that your package.json file is updated. For example, to add the requirejs plugin, you’d type something like this:

npm install grunt-contrib-requirejs –save-dev

Next, you need to specify the tasks in the Gruntfile; you set up the plugin’s config options – details such as location of input files, the name and location of its output and some other options depending on the plugin. After this, you register the task with the grunt.registerTask() hook. See the sample config file for a demo.

#### 3. Sample Grunt config

The Gist below shows a sample commented Gruntfile. The default task is run whenever you type grunt at the CLI; however to run other tasks you need to specify the task name; in the sample file below, typing grunt test will run the jshint:js and qunit tasks.

#### 4. What do these tasks mean?

• JsHint: This will run a static analysis check of your code to see if it complies with standards; it helps to spot hidden errors and will save you some pain. It is possible to specify different targets specified which allows you to run different tasks as you wish e.g. against some subset of your development framework.
• Cssmin: This minifies CSS files; the options show how much the size has changed.
• QUnit: Runs qunit tests on the specified directories against the phantomjs headless browser
• compass: Compiles SASS files to CSS; allows you to pick up config options from a .rb config file although you can overwrite them too.

And that’s it! 🙂

There is a lot more than mentioned, so feel free to do some exploration and hey! Remember to tell me about it too!!

To whet your appetite, here is one: it is possible to read values from the package.json file.

# Grunting with GruntJS

I have been working on a team using a diverse tech stack: PHP, MongoDB, EmberJS and requireJS. Since we intend to release the alpha version in a few weeks insha Allaah, I had to bring everything up to production-ready levels. The usual needs: Javascript linting and obfuscation, resource (JS, CSS + images) minification, test automation (unit + functional) and a few others.

One thing I like about the project is that it gives us a chance to explore and try on new technologies – the best way to learn something is to implement in it. From EmberJS for MVC JavaScript to requireJS for AMD (helps to maintain code sanity) and now GruntJS for automation (I have been yearning to try out Grunt for looooooooooooooong).

GruntJS was written by Ben Alman, same guy who wrote tinypubsub. He wrote it because found it difficult to set up his loads of projects easily. It is in the same category of tools like make, maven, ant and rake. Unlike these tools, Grunt is refreshing and a cinch to grasp – the simple ‘JavaScript-y’ approach got me sold. Also, there are an immense number of 3rd-party add-ons that send give programming bliss; I agree it might not be as flexible as other tools (can you grunt Java? Doubt it) but it does what it needs to do and does it well. That’s all I need for now…

My team’s current Gruntfile config includes options for linting, minification, obfuscation, SASS compilation, live reload, qunit testing for unit testing and also casperjs for functional testing. All tests are run against a phantomjs headless browser.

Lessons? Never take on a side project without learning something new. So what else? Here are a couple of reasons why you should consider GruntJS:

1. Standardized interface – it defines a completely repeatable method for defining tasks.

2. Great community – there are one gazillion plugins, tutorials and blog posts on why you should use Grunt.

3. Plugins for nearly every web dev work you’ll do – I personally love the watch tasks that reload the browsers.

4. The learning curve is almost non-existent; I love easy-to-use stuff.

5. Grunt is powerful – it packs a punch!

6. Flexible, I found out that you can actually invoke command line arguments and run new programs.