Flex: null vs undefined

This may seem like a non-post but it's actually more important than it seems at first glance.

This is when I learned that actionscript (Flex), like javascript, has both a null value (meaning null) and an undefined value meaning undefined. That totally makes sense both the languages deriving from ECMA-script. I cannot believe how long it took me to make the difference between for instance :

if (myObject == null) { /* do something */ }

and

if (myObject) { /* do something */ }

These are actually two very different things: in the first case we only catch things going wrong if the object is null and don't bother checking whether it is actually defined or not. In the second case, we know the object is both not null and defined - so we can get to work with it.

Erratum 02/11/2021 :

Reading this over several years later, I was surprised by the contents of this post.  So, I went back and checked when strict equality (===) was introduced in ECMAScipt, and realised it goes way back to the late 90s.  Also, I tried to acertain when null == undefined became true, and it certainly already was when the above post was written.  In other words, this article was flawed, and here's the fix (with my apologies).

There are basically three scenarios at play here:

- strict equality

- same value

- thruthy-ness

1.  Strict Equality

if (myObject === null) { /* do something */ }

or "strict equality" checks whether both type and value are identical.  So

2 === 2

and 

"2" !== 2

2.  Same value

if (myObject == null) { /* do something */ }

or "same value" unsurprisingly checks whether both values are the same. Thus,

2 == 2

and

"2" == 2

Taking this one step further, note that by definition:

null == undefined

(and vice versa), whereas

null !== undefined 

(strict inequality).

3. Truthyness

if (myObject) { /* do something */ }

The if predicate verifies whether the value (or value resulting from a condition) is truthy. And it so happens that both null and undefined are falsy. There is a trap of course lying herein: most people use this construct to check whether an object is defined, hence "useable" (i.e. both !null and !undefined). However, there is third case in which a value is falsy: when it is itself a boolean false. In other words the condition

if (something)

checks whether something is !null, !undefined and !false.

Thoughts?

Git merging

Usually one wants to merge a branch back into the master (or "trunk" equivalent branch).
To do so simply used:

git checkout master (for instance)

followed by

git merge BRANCH_NAME

Bare in mind this means you explicitly are not attempting to hide the fact you have branched and that the branch will be committed to the remote repository if you git svn dcommit.

You can then remove the merged branch using

git -d BRANCH_NAME

This gives a tree structure similar to this:

   /----------------\ <- BRANCH_NAME
------------------------------------- <- *master

where / represents the branch out and the \ represents the merge back into the master branch.

This is not very elegant unless you want to share remote branches, if you are just working with your branch locally (as you would be if you are using git over SVN), then rebase is probably the nicer option (see coming post). Thoughts?

Git branches

This is most certainly one of the most powerful features in git compared to tradition CVS/SVN systems.

1. you can branch locally, without affecting the remote directory - that's very cool
2. as we will see in later posts you can either merge or rebase your branch to the trunk (this defines the way your branch will get committed remotely: if you merge, you see the branch as a separate "path" in your remote repository, if you rebase, you can make sure your commit ends up looking like part of the trunk "path") - again very cool

So, here are the basics, use:

git branch

to view all current branches, the star indicates which branch you are currently working in

git branch BRANCH_NAME

to create a new branch

git checkout BRANCH_NAME

to start working in that branch

git checkout master

to revert to the master (main) branch

git merge BRANCH_NAME

to merge BRANCH_NAME into another branch (for instance master)

git rebase BRANCH_NAME

to rebase BRANCH_NAME into another branch (for instance master)

git branch -d BRANCH_NAME

to delete a given branch

git branch -D BRANCH_NAME

to force delete a branch

git checkout BRANCH_NAME

to checkout a branch and start (or continue) working on it
More information about the difference between merge and commit coming soon.
Thoughts?

Git hashes

Git identifies all its objects with a SHA-1 (40 byte) hash identifier.
This way git uniquely identifies :
- blobs (files)
- trees (groups of files and/or other trees)
- commits (a single tree)
among others.

If you type:

gitk

you will be able to see every single commit, their hashes, as well as all the files of each commit and their hashes
You can use commands such as:

git log 540991f 

to view blob content,

git ls-tree

to view tree information,

git show

for information about commits,

And so on and so forth.

Note the git is constructed around the concept that most hashes are very different and that the beginning of the hash is sufficient to identify the complete hash. That's what I did above in the git log command: used the shortened hash, which actually identifies a single blob in my system.

Use git help for more information on command options.


Thoughts?

Working locally with git

Now we have worked out how to interact with an SVN repository, let's see how we can work with git locally.

Git has three "areas" you can work in:
- the working area - this is where you program
- the staging area - this is where you store the files that have changed and you would like to include in an upcoming commit
- the repository - this is where everything that has been committed is stored (and when I say everything I mean everything - every single snapshot you have committed is stored here)

The trick with git is to get files from one place to another satisfactorily.

Here are the basic commands to do that:

git status

set a list of changed files, files prepared for commit, and unfollowed files (you can make git ignore changes to certain files like target build files, and so on and so forth).

Once you have the status, you can check differences for any of the files listed in the staging are using:

git diff FILE_PATH

You can also add unstaged files to the staging area:

git add FILE_PATH

And vice versa

git checkout -- FILE_PATH

Once you have added all the files you want to the staging area, you can commit your changes:

git commit -m "my commit message"

You have just created a local commit.

We will see in some of the next posts how the data is stored and the powerful things we can do with local commits before sending them through to the central repository.

Thoughts?

Basic git commands

We'll be using a classic configuration of Git over SVN. In other words, we will be running and "old" SVN repository with Git clients so that we get all the flexibility of Git without having to change the server configuration and migrating all of the source code to Git.

The first obvious thing one wants to do in such a situation is to get hold of some project in the repository. There are several ways of doing this. One simple way is to get oneself into a cosy directory where we want a project to land and initialize the git repository like so:

git svn init -s PROJECT_URL LOCAL_DIR_NAME

and then go fetch it:

git svn fetch

If you want to make sure you are up to date simply type:

git svn rebase

and if you want to commit changes centrally use:

git svn dcommit

Thoughts?

Git overview

We've all heard of CVS, SVN... and now more flexible systems such as Git.

This a quick overview of the power of Git over SVN for instance.

There are several differences between our habitual CVS/SVN versioning systems and Git:
- SVN stores deltas between files that have changed in every commit; Git stores compressed "snapshots" of every commit
- SVN stores its data centrally; Git stores its data both centrally and locally.

These two main differences result in several advantages of Git:
- because everything is stored locally, you can work offline if the network is down
- because everything is stored locally and remotely, you can lose your central server and not lose anything
- because all snapshots are store locally, diffs are really quick, no need to have a working central server, nor to get the files across the network
Thoughts?

Calibre e-book management

A colleague recently suggested using Calibre for e-book management. It seemed like something of a leap to me, quite used to plundering through my PDF files stuffed (and often lost) in categorized directories.

Anyway, I skeptically got hold of the software, tried it and got hooked.

To put it in a nutshell -
Calibre is to e-books, what iTunes is to music
- a living example of KISS at its best and it's free (you can donate of course if you wish).

Enjoy -
http://calibre-ebook.com/

Thoughts?

Behind closed doors: secrets of great management

When I was young (about a year ago), I thought "The one minute manager" was a great read. I still believe it does have something to it - it makes for a quick read and is straight to the point.

But now that I am old (about a year later) and that I have read "Behind closed doors: secrets of great management" by Johanna Rothman and Esther Derby, I have just been ... well enlightened so to speak.

This book does take more than one minute to read but feels like it takes only about two, and is full of healthy material whatever your job description may say. From the bottom of the ladder right to the top, it is full of handy tips on how to coach, create team-spirit and take new team members on board. It is about creating leadership and making sure you tell the right people the right things at the right place and in the right way. Sound easy? Not so. Do you tell someone their behaviour is unacceptable even though they are a good worker? Yes. Ok, but when? In a one-on-one meeting. And HOW? Without getting emotionally involved, without pointing fingers ("you have done this...") - after all the person might not even be aware they have made mistakes in the past period, so avoid emotional cues and train people to learn to accept information without over-reacting. And what do you do when you take on a new team, that's just not really a team but a group of people working together or against each other? Behold the wonders team-meetings, prioritization, one-on-ones, coaching, rumour-killing, gelling, and much much more.

This book will definitely not fall off my bookshelf any time soon.

Thoughts?

Batch programming: defaulting user input

This is a really simple script which sets a variable to a default value if the user doesn't provide input when asked.

set /P val=Please enter value: || set val=default

If the user enters a value, the %val% variable is set to the given value. Otherwise (if the user simply pressed Enter) 'default' is used instead.

Neat :).

Thoughts?

Back from a long hawl

It's been a while one might quite honestly say since I have kept this blog alive... rest assured though that live again it will. I am back with a family, a house, a recent new job and lots of new material to work through. So, look forward to information of all sorts: from Git to Flex through some interesting new reads and much much more!

I should be back publishing regularly shortly, so come back for a peak any time - you know you are always welcome :).

Thanks for your interest and next post shortly!

Elinor