Twiddling with Yeoman – foray into web design

Been playing with some web design lately, using Yeoman. Yeoman’s a pretty neat workflow build tool. Here’s the results! http://joeltong.org/kulertogpl/

Kuler2Gpl splash

I had some trouble getting grunt to resolve relative resources in the dist directory. After much toying, usemin seemd to be the problem. This worked for me in Gruntfile.js. A mental note!

// Performs rewrites based on rev and the useminPrepare configuration
usemin: {
  html: ['<%= yeoman.dist %>/{,*/}*.html'],
  css: ['<%= yeoman.dist %>/styles/{,*/}*.css'],
  options: {
    assetsDirs: ['<%= yeoman.dist %>', '<%= yeoman.dist %>/images']
  }
}

Using Adobe Kuler swatches in Inkscape / GIMP

Adobe Kuler’s a pretty cool app that matches color combinations. Sadly, Inkscape and GIMP do not support Kuler’s ASE format. And there’s no support for converting from ASE to Inkscape / Gimp’s GPL, in Linux at least.

So here’s kuler2gpl that does just that. kuler2gpl converts whole folders of Kuler ASE files to GPL – in batch mode. It’s based off NodeJS – its pretty cool stuff (you can get node here).

Installation

  1. Ensure you have node installed.
  2. Run the following. Depending on your Node installation, you might need to run this with sudo.

    $ npm install -g kuler2gpl
    
  3. You’re all set! Convert with

    $ kuler2gpl -i /path/to/input/directory
    

Here’s a preview in Inkscape:

inkscape

Haroopad – a Markdown editor

Guys, if you’re looking for a pretty neat Markdown editor with live preview (and a well thought-up UI), check out Haroopad:

http://pad.haroopress.com/user.html

A screenshot:

Haroopad

Found this today. Its pretty neat – it’s cross-platform, apparently uses some kind of Node-implemented stack. And it supports Vim bindings too. Try it!

More Book Review notes

Agile Adoption Patterns: A roadmap to Organizational Success

Amr Elssamadisy

Cover 1

Pretty good and in-depth book covering Agile design patterns. Some foreknowedge of Agile adoption is needed, though. Details the common pitfalls and important notes on Agile development, using a pattern-based approach. A good read – if you have time!

The art of readable code: Simple and practical techniques for writing better code

Dustin Boswell, Trevor Foucher

enter image description here

Not a bad book either, if you’re keen on getting up to speed on writing readable code!

TexPaste – LaTeX snippet bin (LaTeX Github Gists equivalent)

Ever wanted to share LaTeX snippets on the fly? Check out this website: http://www.texpaste.com/

It’s an interesting site that is similar to Github Gists, for LaTeX. Made by someone from the NUS Hackers community.

Looks like I might be using this for PC1432. Blurp. =D

Learn Markdown in 5 minutes

One of the shortest guides you’ll find on Markdown!!

Markdown is a HTML shorthand outlined by John Gruber, popularized by sites such as http://stackoverflow.com and http://github.com. Official specification is found on http://daringfireball.net/projects/markdown/.

Here’s the skinny in 5 minutes.

What is markdown?

Markdown is basically a normal text file, with markdown markup. File extensions typically end with .md or .markdown. Markdown files can be generated into an appropriate html page by various programs / add-on scripts. Code in a typical file looks like this:

Dancing Ponies and unicorns - a curious investigation 
=========================================================

## Preamble

Dancing ponies and unicorns have long intrigued scientists.  In this study, we hope to shed light on their feeding habits.

### History of dancing ponies 

some text here with some *cool* highlighting like **here**.  Oh, and `a cool `unicorn.do()` markup here.


## Methodology

    var foo() {
        for (unicorn in unicornSet) {
            // tell the unicorn to do stuff 
            unicorn.do();
        }
    }

What’s great about markdown?

It’s real fast to write HTML pages. And with HTML, comes the benefits of separating design from the actual content, via CSS. i.e. standardization is real need.

This blog post was written in markdown. You get the idea.

The skinny of markdown

HTML H1 – H6 headers

Generating HTML title headers is easy. Like so:

# A large H1 header 

## A small H2 subheader 

### A smaller H3 subsubheader, and so on...

Main header

The large big title 
===========================

Writing paragraphs

here is one paragraph.  

Here is another paragraph.

Here is yet another paragraph,
which ignores the newline in 
the second and third lines.

Formatting text

I can write text in `verbose`, *italic* and **bold** like so.

Formatting code blocks

function foo() {
    var a = 3;
    if (a === 2) {
        // do something

    } else {
        return;
    }
}

Quoting from text

> "A true friend freely, advises justly, 
> assists readily, adventures boldly, 
> takes all patiently, defends 
> courageously, and continues a friend 
> unchangeably." 
> 
> - William Penn

Lists

Enumerated lists:

1. some entry 
2. some entry 
3. some some entry 

OR 

1. some entry 
1. another entry 
1. Another entry 
- Different bullet 
- But its the same
    - This will be sub-enumerated as well

Bulleted lists

- some entry 
- another entry 
- another entry here

Horizontal rules

---------------------------------------

Inserting HTML tags

Write them normally, like such:

<img src="unicorns.jpg" />
<br>

Escaping symbols

\# This generates a normal pound.

Conclusion

So here you are! Markdown in 5 minutes.

The Clean Coder – A code of conduct for professional programmers – A book review

The Clean Coder book snapshot

I’m just done with reading The clean coder by Robert C. Martin. In this
book, Martin touches on the professional ethics a programmer should have, in
addition to individual and team dynamics. This book serves as a good primer
to professional software development, in a team.

Interesting points from the book:

Learn to say no. Be firm about it.

Mean what you say. Do not commit to tasks which cannot be delivered. Learn to
be firm about it.

What is commitment?

  1. You say you’ll do it.
  2. You mean it
  3. You do it

Learn to say yes.

When you say yes, you are fulfilling it through commitment.

Avoid the The Zone.

Martin defines the The Zone as the periods of high concentration that coders enter while programming. Being in The Zone apparently narrows one’s perspective of the larger project – that being said, its good for learning new concepts and languages. Program in pairs. Which brings us to the next point…

Pair, pair, pair. It works.

Avoid slipping into The Zone by working in pairs! Two is better than one -
it coerces programmers to be social as well. Two is indeed better than one!

Avoid all distractions – including music

Might work for some of yall.

Test-Driven Development (TDD). Yes it works.

Some Agile terminology we have here. Develop in a language that supports
continuous testing, low recompilation time, etc. (e.g. C++ V.S. Java). Write
tests. Continually run these tests. Rerun them when done. Do tests first,
fulfill these tests later. Use Acceptance tests. Test, test, test – you
won’t want to ship something broken.

Oh and, automate these tests.

What kinds of tests are there?

  1. Exploratory tests
  2. System tests
  3. Integration tests
  4. Component tests
  5. Unit tests

Some testing tools

  • C++ – CppUTest
  • Java – JUnit
  • Ruby – RSpec
  • Clojure – Midje

Decline meetings which / are likely to be unproductive.

Be good stewards of your employer’s time.

Don’t hoard your code.

Refrain from building walls around your code. Pair-programming helps prevent
this.

Use Continuous Build tools.

Example given: jenkins.

Do coding practices in languages you’d want to keep

Martin calls this kata. Oil those gears – try coding 10-minute exercises
regularly.

Or try something like wasa, with another coder. One sets unit tests; the
other attempts to code to fulfill those unit tests. Then, swap.

Another way suggested: Try contributing to open-source code projects.

Get this book – its a pretty good primer. Saves you some hassle too.

15 essays on code development – Review of Ka Wai’s book

enter image description here

Lately, I’ve been reading “The Developer’s Code – What real programmers do” by Ka Wai Cheung. Its pretty interesting; each point is an essay in itself, and is decoupled from other essays, making for easy reading. To y’all developers out there, grab this book!

The developer’s code – What Real Programmers Do
Ka Wai Cheung

http://www.amazon.com/The-Developers-Code-Wai-Cheung/dp/1934356794

Some snippets:

#1 – Define the goals of your application (#40)

When your client justifies feature requests with other explanations irrelevant to the project, it could mean you’re off track. Put the project first – everything will fall into place.

#2 – Plan enough, then build (#2)

Plan. Plan well. Avoid overplanning.

#3 – Launch is just the first release (#3)

Don’t overstress on launch. Build, refactor, and release gradually. Recall agile web development? (http://sixrevisions.com/web-development/agile/)

#4 – Throw away your old code (#5)

Avoid hoarding / commenting out old code. Trash them regularly. Something that should be taken with a pinch of salt?

#5 – Be imperfect (#10)

Nobody’s perfect. Move to the next task!

#6 – Work outside your bedroom (#13)

The office is for work, the bedroom for sleep. You need sleep. Enjoy the outdoors!

#7 – First impressions are just that (#14)

First impressions do not necessarily define your code – a negative first impressions could stem from unfamiliarity.

#8 – Constrain all your parameters (#18)

Having resources (time, funding, money) does not imply you have to spend them. Resources are finite – use them wisely.

#9 – Improve your product in two ways daily (#20)

Set 2 milestones for your project daily. No more, no less (again, to be taken with a pinch of salt?)

#10 – Keep a todo list (#22)

Started this yesterday.

#11 – Work in small, autonomous teams (#24)

Small and close teams understand each other. They deploy faster. Work with those whom you can work with well.

#12 – Eliminate the “we” in productivity (#25)

Be specific. The book attributes this to Social Psychology – what is termed the “Bystander Effect”.

#13 – Sniff out bad complexity (#26)

K.I.S.S. – Keep it Sound and Simple. ’nuff said.

#14 – Know when to refactor (#31)

Identify what needs refactoring. Then, work on it. There is a time and place for everything, including design patterns.

#15 – Lie to Simplify (#36)

Teach students the generic rules. Apply exceptions later, for effective teaching.

Hmm. Some stuff to chew on.