learning

The Effective Programmer – 3 tips to maximize impact

Posted on by AbdulFattaah Popoola

Effectiveness, (noun) : the degree to which something is successful in producing a desired result; success.

Over the years, I have tried experiments, read books and watched several talks in a bid to improve my effectiveness. After a series of burnout and recovery cycles, I finally have a 3-pronged approach that seems to serve me well.

1. Learn to estimate well

2. Use the big picture to seek opportunities

3. Continuous Improvement

Lets discuss these three.

1. Estimation – the bane of software development

Reliable coding estimates accurately forecast when feature work will be done. But when is a feature done? Is it when it is code complete? Test complete? Or deployed? Most developers wrongly associate code complete with test completion or deployment ready. This explains arbitrary estimates like: “Oh… I’ll be done in 2 hours”; such estimates typically miss the mark by wide margins due to error compounding. Let’s take a simple bug fix scenario at a fictitious software engineering company.

  • Bug is assigned to developer John SuperSmartz
  • John SuperSmartz reads the bug description, sets up his environment and reproduces it
  • He identifies the cause but does some light investigation to find any related bugs (he’s a good engineer)
  • John designs, implements and verifies the fix
  • Gets code review feedback and then checks in

Any of the intermediate steps can take longer than estimated (e.g. code reviews might expose design flaws, check-ins might be blocked by a bad merge, newer bugs might be discovered in step 3. etc). Without such an explicit breakdown, it becomes difficult to properly give estimates. Don’t you now think the 2-hour estimate is too optimistic?

Personally, I use kanbanFlow (I love their Kanban + pomodoro integration) to decompose work into small achievable 25-minute chunks. For example, I might break down some feature work into 8 pomodoros as follows:

  • Requirements clarification – 1 pomodoro
  • Software design and test scenario planning – 2 pomodoros
  • Coding (+ unit tests) – 3 pomodoros
  • Testing and code reviews – 1 pomodoro
  • Check-in + estimation review – 1 pomodoro

Some of the things I have learnt from using this approach:

  • I grossly underestimate feature work – the good side though is that this planning enables me to improve over time
  • I know when to start looking for help – as soon as a task exceeds its planned estimate, I start considering alternative approaches or seeking the help of a senior technical lead
  • Finally, it enables me to make more accurate forecasts – e.g. I can fix x bugs per week…

2. See the big picture

A man running around in circles covers a lot of distance but has little displacement. In optimal scenarios, distance covered equals displacement while in the worst scenario, it is possible to cover an infinite distance and have a displacement of zero.

Imagine working for several days on a feature and then discovering major design flaws that necessitates a system rewrite; a lot of distance has been covered but there has been little displacement. Working on non-essential low-impact tasks that no one cares about is neither efficient nor effective. Sure they might scratch an itch but always remember that the opportunity cost is quite high; the lost time could have been invested in higher priority tasks with a larger ROI.

Whales periodically surface for air and then get back into the water to do their business; so should engineers periodically verify that priorities align with company’s goals. It’s possible to get carried away by the deluge of never-ending feature requests and bugs fixes; an occasional step back is needed to grasp the whole picture. Here are sample questions to ask:

  • Where are the team’s goals?
  • Does your current work align with company goals?
  • Skills acquisition and obsolescence check
  • Opportunities for improvement?

Personally I try to create 3 to 4 high-impact deliverables at the beginning of each week and then focus on achieving these. Of course, such forecasts rely heavily on productivity estimates.

3. Continuous Improvement

Athletes consistently hold practice sessions even if they don’t want to because it’s essential to staying on top of their game. The same applies to pretty much any human endeavor – a dip in momentum typically leads to some loss in competitive edge. The software engineering field, with its rapidly evolving landscape, is even more demanding – developers have to continuously and relentlessly learn to stay relevant.

Staying relevant requires monitoring industry trends vis-à-vis blogs, conferences and newsletters. There are a ton of resources out there and it’s impossible to follow every single resource, rather it is essential to separate the wheat from the chaff and follow a select high-quality few.

Learning and experimentation with new technologies naturally follows from keeping abreast of developments. A developer might decide to learn more about the software stack his company uses, logic programming or even computer science theory. Even if his interests are totally unrelated to his day-to-day job, independent learning would expose him to new (possibly better) ways of solving problems, broaden his capabilities and might even open up new opportunities. I prefer learning established CS concepts to diving into every new db-data-to-user-moving framework.

Opportunities abound such as learning IDE shortcut keys, terminal commands, automating mundane tasks and so on. Ideally you want to start simple by selecting the area with the highest impact-to-effort ratio and then dedicating a few minutes to it daily. Over time, the benefits start to pay off.

And that’s about it! Do you have other suggestions?

Like this post? Follow me on Twitter here or read some of my top posts.

1. Code is poetry: 5 steps to bulletproof code

2. So you want to become a better programmer

5 things I have gained from SICP: Section 1.2

Posted on by AbdulFattaah Popoola

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

1. Research is hard!

2. Wrangling with HUGE data

3. MOOC Review: Machine Learning

Defining JavaScript Functions

Posted on by AbdulFattaah Popoola

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');

add(1,2);
//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) {
    alert(str);
};
eval('f("eval")');
//alerts eval

setTimeout('f("timeout")',1000);
//alerts timeout after a sec
};

Remember, don’t do this on live servers…

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

1. The JavaScript Function
2. Three Important JavaScript Concepts
3. A peek into JavaScript’s Array.prototype.map and jQuery.map

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

Posted on by AbdulFattaah Popoola

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:

1. The JavaScript Function
2. A peek into JavaScript’s Array.prototype.map and jQuery.map
3. Programming Language Type Systems I

Becoming a Professional Programmer

Posted on by AbdulFattaah Popoola

1. Deliver when you commit

It is extremely bad for your reputation to fail to meet up to your words; if you can’t deliver, please say no or find an alternative way out. How would you feel if an artisan disappoints you for no good reason? I bet you’ll probably never do business with them again.

So before you commit to anything (boring bug fixing, dreary testing or documentation), please make sure you’ll deliver or else do not commit.

2. Stay up to date

Do you know design patterns? Development methodologies? The latest fad in software development? Don’t neglect learning else you’ll wake up one day and realize that you are writing COBOL (OK, this is an exaggeration but you sure do get the hint). Staying up to date is your responsibility and no one else’s.

Dedicate time to make sure you know your field very well, ideally it should be time off work and gains should be measurable. While you are at it, please remember not to burn out, create time for fun things too.

Some employers actually make this easy by training employees or providing libraries – if you are lucky enough to have this, please take full advantage of this :); otherwise, there are tons of free stuff on the Internet that you can leverage – blogs, newsletters etc.

3. Be responsible

You must unconditionally know HOW and WHY your code works; and when testers find a bug, accept it as your doing graciously. This also applies to inherited code – no one wants to know if the code is spaghetti (with some onions and meat included) or written in Japanese. Once you inherit the code, it automatically becomes your code and it’s up to you to know how it works, what it does and how to fix/extend it.

If you are stuck with such bad code, why not try cleaning it up slowly? Every time you open the file, just make a tiny improvement (please no new bugs).

4. Know the domain

Most developers feel that users are not ‘smart’ enough to understand the intricacies of software development. Software development is complex but so are financial accounting, quantum physics , economics and a whole slew of other fields.

Imagine two developers working on a financial accounting product, the first writes software based on the requirements alone while the second makes a conscious effort to learn more about financial accounting. Who do you think will write better software and communicate more lucidly? Who will understand the problems, issues and challenges better?

Admittedly, it is more work trying to understand accounting (or any other field) but in the long run, it’ll pay off because you’ll write code in the problem domain. This also gives you the chance to contribute meaningfully to the project, proffer advice and analyze the competition. Who knows, it could open the door to new opportunities.

5. Work consciously

Most times we do things because we are accustomed to having things work that way – in coding, code design or requirements gathering. Ideally, we should always be thinking of our work – it should not just be the same ol’ thing all the time.

There are things to try, new (and probably better/more efficient) ways to write code and arcane language features to explore. Always keep asking these questions – why am I doing this? What am I doing now? Is there a better way to do this? It applies to everything – coding, design, maintenance and even meetings! Yes, meetings! 🙂

Did you enjoy this piece? Maybe you’ll also like becoming a better programmer and 5 things I learnt from Code Complete 2.

 

I am language-agnostic

Posted on by AbdulFattaah Popoola

Once upon a time I used to think programming in Java was the best thing anyone could do. All this changed when I started my internship and realised I had to program in PHP whether I liked it or not. PHPwhat?! I didn’t like it and felt that PHP was just not the way to go. Why would I need to learn an interpreted language? What were these $ signs? Surely, I wrongly presumed, only ‘fake’ programmers wrote PHP.

I had no other offers and joined the firm – after six weeks trudging the streets of Lagos; I was pretty much ready to take up anything – I immediately resolved to only use PHP at work and continue learning Java on my own. A routine soon emerged – I would study/code in PHP at work and learn/read/try out Java projects at home/on my way home/ at the weekends.

As I learnt more about web development, I slowly came to appreciate the power of PHP and it eventually became my forte; surprising right? I never quite thought I would turn out this way too; I wanted to be a Java guru when I started. After spending hours developing software and learning new languages, paradigms and patterns, I’ve dropped my language-centric attitude. For me, what really counts now is understanding the underlying principles of software development, having a good grasp of programming basics and using the right language for the problem at hand.

I don’t quite bother myself over language wars anymore; my major concern is using the best-suited language to solve the task at hand. I most likely won’t develop a mobile application using PHP; I’ll consider Java first. If you want to stick to your preferred language because it has a zero learning curve and solves the problem at hand in a good way; then use it and get the job DONE.

S.I.M.P.L.E 😀

What do you think?

Become a better programmer

Posted on by AbdulFattaah Popoola

A lot of people say they want to become programmers and rave and talk about it without ever doing anything. So if you want to become a better programmer you can try these tips.

Learn a lot

Programming is a rapidly changing field with new innovations, discoveries and concepts coming up daily. Change is constant here. So you’ve got to read a lot and keep up to date with the current trends and happenings in the software development world. Always try out new stuff; learn new programming languages, design patterns, development methods. Just keep learning.

Learn several paradigms

Learning a new programming paradigm will force you to think in a new way and expose you to more logic and improve your code writing skills. Learning C, which has no string types but forces you to write them as an array of characters and has pointers too, will stretch your brains; or python/javascript which support functional programming or scheme. Get your juices flowing.

Write code

How do you get better at programming if you don’t practise programming? Write code at every opportunity you’ve got. It’ll enable you to learn more about your language and also improve your modelling skills so you can abstract real life events into software development terms. Always try to improve your code and strive for perfection and improve your algorithms.

Know your tools

Get to know your tools. If you use an IDE, try out some of the features which you always see but never click on. There are there for a reason; the designers made them so they could searve a purpose so try to use them and perfect them. Most IDEs support unit testing, collaboration, FTP and a whole lot of other juicy tools that make your development tasks easier.

Read code

Now to get some subtle tricks, learn from the masters of the trade and pick up experience and know what bad code looks like; you’ve got to read code. So sign up for an open source project or if you’re too lazy for this; read the java source code – yes I’m serious! – read it. Or jQuery source, or PHP, and start from there. you can also get some other projects’ source code for your consumption.

Get mentors

Having mentors will help you to know your weak points and where you ought to improve yourself. They’ll also point out tweaks, tips and tricks to you so you get to accelerate your development skills. Best still, they can tell you when you are on the wrong path so you can always get back on track without straying too far.

Work hard

Yah, You’ve got to work hard; working hard is part of success; you don’t just expect to sit in your house and have the programming skills you so desire transferred to you all of a sudden. So, get up and start writing code, learning, and seeking out mentors.

Happy coding… 😀

Related articles

How it all started

Posted on by AbdulFattaah Popoola

My very first language was FORTRAN; I took a programming course in it in 2006 and was instantly hooked. I didn’t have a computer however I worked in a computer centre so I could program whenever I was free.

After getting my laptop, I delved into C; however I  was ‘advised’ to drop C as it wasn’t so popular anymore. So I switched to C++ and it was fun till I got into the murky waters. I remember being puzzled when I started OOP in C++ (similar thing happened when I started learning functional programming); coming from a procedural background, I just couldn’t seem to understand the concept of an object; was it a new data type? Was it something else? Why could I call methods on data? Objects or not, I continued with C++.

A year later, I was learning Java even though I was not quite finished with C++, why? I was taking a course which was being taught in Java. I switched again without having mastered C or C++ and resolved never to leave Java until I mastered it, no matter what anybody said, did or suggested. I stuck with Java; learning stuff, writing programs and just trying out ideas.  I remember trying to implement a Sudoku game in Java – some intensive brainstorming huh? :D.

I discovered PHP/MySQL during my internship; it was the language of choice at my firm and I had to learn it. My boss never took no for an answer and I had to provide solutions whether it seemed possible or not. Initially I thought his demands were harsh however I realised that my attitude was the cause – I gave up too easily; Alhamdulilah, with this realisation, I became a better person. I learnt PHP, wrote some cool algorithms and built a couple of software systems there. I also stumbled upon some neat PHP tricks, JavaScript and  got a lot of hours under my programming belt. After my internship I took up a project in Drupal and started another from the scratch: Gbanjo. Well, Gbanjo is a story for another day.

In my last year at school; I wanted to learn Python and actually started but I decided to focus more on my studies and since I was holding a number of administrative positions; I didn’t want my grades to fall.

Now; I’m outta school presently and I’m programming. This year I have learnt more about PHP, Java, JavaScript and Android. The road has been long but I thank God for helping me and want to learn more. I still have to learn C/C++/C#/python and maybe Ruby, Scala or Scheme. For the present; I’m learning JavaScript and I have to finish this before starting with another language. One of my past mistakes was trying to learn too many things at the same time and not just focusing on one thing and learning it well.

Here are a few facts I’ve learnt from my journey; I’m still learning anyway 🙂

  • Do what you are passionate about
  • Give it all your best; your very best, don’t ever give up!
  • Don’t listen to what people say; God determines success not people
  • Learn to focus; Rome wasn’t built in a day; you can’t learn everything at once
  • Work hard – of course, there’s no gain without pain.
  • Pray harder – I believe in God and He answers prayers

What’s your own story?

learning jQuery

Posted on by AbdulFattaah Popoola

I stumbled upon Rebecca Murphy‘s jqfundamentals and found it to be a gentle introduction to jQuery. Well, I use jQuery a lot – well, let’s just say I copy prefabricated solutions – so I felt it’ll do no harm to learn how to write jQuery itself. So far it’s been lovely, Rebecca’s piece is great and I must confess I’m impressed by JavaScript‘s capabilities.

There are exercises at the end of some of the chapters in the book; I tried out some and got exposed to the raw power of jQuery. One of the tasks involved removing the label for a search input from the DOM and setting that label’s text as the search input’s value. It also involved clearing the search input’s text whenever it was in focus and resetting the text if the user didn’t type in anything.

Here’s my code…

$(document).ready(function () {
var $search = $('#search'); //Get the search form
var $input = $search.find('input.input_text'); // search input
var label = $search.find('label').remove().text(); //remove the label
$input
.val(label)
.addClass('hint')
.bind('focus',function() {
$(this).removeClass('hint').val('');
})
.bind('blur', function(){
if (!$.trim($(this).val())) // Check if the user didn't enter text and reset the text
{
$(this).val(label).addClass('hint');
}
});
});

Well, I know this isn’t much but it’s a start – I’m still a novice.

If you’re interested in learning, do check out her site: jqfundamentals.com. If you’ll like to learn about software engineering; try watching the CS**** videos on Stanford’s YouTube channel -> they’ve got lots of interesting stuff that’ll improve and boost your knowledge.

Next week, I’ll write about what I learnt again insha Allah ( God willing ) 😀