This article contains a list of LaTeX errors - good to know:
http://www.cs.utexas.edu/~witchel/errorclasses.html
Thoughts?
Wednesday 24 October 2012
(La)TeX resources
Looking for LaTeX online renderer, came across this link that covers quite a few that are good:
http://tex.stackexchange.com/questions/3/compiling-documents-online
Worth taking a look at ;-)
Thoughts?
http://tex.stackexchange.com/questions/3/compiling-documents-online
Worth taking a look at ;-)
Thoughts?
Friday 19 October 2012
Groovy iteration - great resource
Groovy allows you to use "short-written" constructs (such as each or find) to run through lists or easily find one or several items in a list using closures.
Example:
myList.each { item ->
// do something with the item
item.doSomething()
}
This says: for each element in my list, I would like to access it using the variable name "item". If the list is typed, the item will be of the type of the elements in the list and its properties and behaviours will be accessible as such. This is how you access item.doSomething() which is declared in the item's class.
The block in curly brackets is called a closure, it will get precompiled into a separate class file, much as anonymous classes in Java get precompiled into separate classes.
You can also for instance find the first occurrence of something using closures as follows:
myList.find { it.temperature == 165 }
This will find the first item in the list which has temperature 165. it is the keyword that lets you access the current element being iterated. Here we're imagining we are working with a class that store (among other things) a temperature value.
You could do the same and find all corresponding items using:
myList.findAll { it.temperature == 165 }
As in the two previous, examples, the piece of code between curly braces is called a closure and will get precompiled to a separate class file.
If this has wet your appetite, try this resource the covers a much more comprehensive range of iteration operations available in Groovy with clean hands-on examples: http://hanuska.blogspot.be/2008/12/easy-groovy-iteration.html.
As you can see there are some really cool one-liners just waiting to be born.
Thoughts?
Example:
myList.each { item ->
// do something with the item
item.doSomething()
}
This says: for each element in my list, I would like to access it using the variable name "item". If the list is typed, the item will be of the type of the elements in the list and its properties and behaviours will be accessible as such. This is how you access item.doSomething() which is declared in the item's class.
The block in curly brackets is called a closure, it will get precompiled into a separate class file, much as anonymous classes in Java get precompiled into separate classes.
You can also for instance find the first occurrence of something using closures as follows:
myList.find { it.temperature == 165 }
This will find the first item in the list which has temperature 165. it is the keyword that lets you access the current element being iterated. Here we're imagining we are working with a class that store (among other things) a temperature value.
You could do the same and find all corresponding items using:
myList.findAll { it.temperature == 165 }
As in the two previous, examples, the piece of code between curly braces is called a closure and will get precompiled to a separate class file.
If this has wet your appetite, try this resource the covers a much more comprehensive range of iteration operations available in Groovy with clean hands-on examples: http://hanuska.blogspot.be/2008/12/easy-groovy-iteration.html.
As you can see there are some really cool one-liners just waiting to be born.
Thoughts?
Thursday 18 October 2012
Google - LaTeX labs
Want a quick and easy way of rendering LaTeX online? Try out the Google LaTeX labs tool. It's not a Google tool but it does work pretty well as far as I can tell.
Easy steps:
- add the lab to your Google labs
- type in some LaTeX
- in the menu select Compile and hey presto, a whole new world to explore.
Get back to editing mode, by using the "source" button, bottom left of your screen (you can also use the 'Preview' button instead of compiling).
See: http://docs.latexlab.org/docs
Enjoy and let me know your thoughts...
Easy steps:
- add the lab to your Google labs
- type in some LaTeX
- in the menu select Compile and hey presto, a whole new world to explore.
Get back to editing mode, by using the "source" button, bottom left of your screen (you can also use the 'Preview' button instead of compiling).
See: http://docs.latexlab.org/docs
Enjoy and let me know your thoughts...
Wednesday 17 October 2012
Method Object pattern
"The Method Object implementation pattern suggests
turning a
complex method into an object to enable further simplification."
Read more at: http://www.threeriversinstitute.org/TwoMoreImplementationPatterns.htm
Thoughts?
Read more at: http://www.threeriversinstitute.org/TwoMoreImplementationPatterns.htm
Thoughts?
Groovy is full-OO
Unlike Java that hawled us through (and still is) the autoboxing conundrum for primitive types, Groovy simply *is* fully object-oriented. Declare a primitive type such a 2, and you are actually handling an java Integer.
Want to know the really pretty thing about this? You can use stuff like:
def x = 5
def y = 7
and then something like:
def z = x + y
println z => should print 12
or something like:
def z = y.plus(x)
println z => will also print 12
Cool!
Thoughts?
Want to know the really pretty thing about this? You can use stuff like:
def x = 5
def y = 7
and then something like:
def z = x + y
println z => should print 12
or something like:
def z = y.plus(x)
println z => will also print 12
Cool!
Thoughts?
Running *.groovy
Now, this one is interesting. You know how in Java - you call javac, the java or javaw with the classpath to run your *.class (precompiled) file?
Well, Groovy just lets you run the *.groovy file itself. Wow. This means it hides its inner workings, precompiles to Java bytecode for you and then runs the file.
Nifty is what I say.
Thoughts?
Well, Groovy just lets you run the *.groovy file itself. Wow. This means it hides its inner workings, precompiles to Java bytecode for you and then runs the file.
Nifty is what I say.
Thoughts?
Tuesday 16 October 2012
Groovy
As you can see in the previous post, lots of new programming languages are cropping up that will actually run "on" the JVM. In clear, this simply means the code (groovy or whatever) is (pre-)compiled to Java-equivalent bytecode. Why do I say "Java-equivalent" because it may well be some things get optimized that wouldn't normally in Java. Why? Because optimization is often "pattern"-driven (not design pattern, just code pattern), which means languages that offer different constructs, may be able to optimize these in a way that Java cannot.
Cut a long story short... I am currently exploring Groovy, which is both a (pre-)compilable and scripting language. What's great about this, is that you can run along, code some Groovy on the command-line to check it's all working, create a *.groovy file you save to disk containing your logic, and run the file using groovyc for instance, the equivalent of javac for Java. What's really cool about the bytecode thing, is that it means you just take a piece of Groovy code, hand it to groovyc, then to the JVM. The JVM will basically handle it like any old plain piece of Java. So what's the point? might you ask. Groovy offers lots of very handy constructs, working with lists or XML for intance is a breeze, so try it and erm... let me know what you think. Personnaly I am pretty enthusiastic about it :-).
Thoughts?
PS: I nearly forgot... remember to "groovydoc", if you choose to walk that path...
Cut a long story short... I am currently exploring Groovy, which is both a (pre-)compilable and scripting language. What's great about this, is that you can run along, code some Groovy on the command-line to check it's all working, create a *.groovy file you save to disk containing your logic, and run the file using groovyc for instance, the equivalent of javac for Java. What's really cool about the bytecode thing, is that it means you just take a piece of Groovy code, hand it to groovyc, then to the JVM. The JVM will basically handle it like any old plain piece of Java. So what's the point? might you ask. Groovy offers lots of very handy constructs, working with lists or XML for intance is a breeze, so try it and erm... let me know what you think. Personnaly I am pretty enthusiastic about it :-).
Thoughts?
PS: I nearly forgot... remember to "groovydoc", if you choose to walk that path...
JVM languages
Interesting article about Java Virtual Machine languages including Groovy, JRuby and Jython.
http://en.wikipedia.org/wiki/List_of_JVM_languages
Thoughts?
http://en.wikipedia.org/wiki/List_of_JVM_languages
Thoughts?
Wednesday 9 May 2012
Who moved my cheese?
We have all heard of this book by Spencer Johnson, it's just been out for that long and used by so many companies to "help" people cope with (and perhaps even learn to enjoy) usually unwanted change.
It describes the lives of four characters in a maze who are looking for cheese, that represents fullness and happiness - which is what we all hope for right? Through the differences in reaction to change, we see that some people are simply constantly prepared for change, and thrive on it. Others don't expect it, get upset by it, and then get over it. And others... well, read the book and find out for yourself. It makes for a quick, simple read but doesn't delve into the depths, content to remain on the surface, some, as I did, may find that somewhat disappointing.
A few excerpts I found meaningful from The Writing On The Wall in the maze :
"If You Do Not Change, You Can Become Extinct" - Theory of evolution, eh?
"What Would You Do, If You Weren't Afraid?" - Use this with care... fear can be useful
"When You Move Beyond Your Fear, You Feel Free." - True, but also dangerous to a certain extent
It is a simple read - but not a great a read, could leave you feeling simply empty and void. Take a peak and let me know what you think if you can find it free somewhere.
Thoughts?
It describes the lives of four characters in a maze who are looking for cheese, that represents fullness and happiness - which is what we all hope for right? Through the differences in reaction to change, we see that some people are simply constantly prepared for change, and thrive on it. Others don't expect it, get upset by it, and then get over it. And others... well, read the book and find out for yourself. It makes for a quick, simple read but doesn't delve into the depths, content to remain on the surface, some, as I did, may find that somewhat disappointing.
A few excerpts I found meaningful from The Writing On The Wall in the maze :
"If You Do Not Change, You Can Become Extinct" - Theory of evolution, eh?
"What Would You Do, If You Weren't Afraid?" - Use this with care... fear can be useful
"When You Move Beyond Your Fear, You Feel Free." - True, but also dangerous to a certain extent
It is a simple read - but not a great a read, could leave you feeling simply empty and void. Take a peak and let me know what you think if you can find it free somewhere.
Thoughts?
Labels:
books
Monday 30 April 2012
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).
- 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 === 2and
"2" !== 2
2. Same value
if (myObject == null) { /* do something */ }or "same value" unsurprisingly checks whether both values are the same. Thus,
2 == 2and
"2" == 2Taking 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?
Labels:
actionscript,
flex,
null,
undefined
Wednesday 25 April 2012
Git merging
Usually one wants to merge a branch back into the master (or "trunk" equivalent branch).
To do so simply used:
followed by
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
This gives a tree structure similar to this:
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?
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?
Labels:
git
Tuesday 24 April 2012
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:
to checkout a branch and start (or continue) working on it
More information about the difference between merge and commit coming soon.
Thoughts?
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 branchto view all current branches, the star indicates which branch you are currently working in
git branch BRANCH_NAMEto create a new branch
git checkout BRANCH_NAMEto start working in that branch
git checkout masterto revert to the master (main) branch
git merge BRANCH_NAMEto merge BRANCH_NAME into another branch (for instance master)
git rebase BRANCH_NAMEto rebase BRANCH_NAME into another branch (for instance master)
git branch -d BRANCH_NAMEto delete a given branch
git branch -D BRANCH_NAMEto 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?
Labels:
git
Monday 23 April 2012
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:
You can use commands such as:
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?
This way git uniquely identifies :
- blobs (files)
- trees (groups of files and/or other trees)
- commits (a single tree)
among others.
If you type:
gitkyou 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 540991fto view blob content,
git ls-treeto view tree information,
git showfor 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
Thoughts?
Labels:
git
Friday 20 April 2012
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:
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:
You can also add unstaged files to the staging area:
And vice versa
Once you have added all the files you want to the staging area, you can commit your changes:
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?
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?
Labels:
git
Thursday 19 April 2012
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:
If you want to make sure you are up to date simply type:
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_NAMEand then go fetch it:
git svn fetch
If you want to make sure you are up to date simply type:
git svn rebaseand if you want to commit changes centrally use:
git svn dcommitThoughts?
Wednesday 18 April 2012
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?
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?
Labels:
git
Tuesday 17 April 2012
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?
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?
Labels:
calibre,
e-book,
e-learning,
training
Monday 16 April 2012
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?
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?
Labels:
books,
management
Friday 13 April 2012
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.
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?
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?
Labels:
batch,
default,
NT,
programming,
prompt
Subscribe to:
Posts (Atom)