This is the pro­ce­dure I use to pre­pare for speak­ing at con­fer­ences. It may work for oth­er­s, it may not. It may be good, it may be bad.

1. Be asked to speak

2. Be un­­sure about it for a few days

3. Be asked if you are go­ing to move your ass and do it al­ready

4. Think ti­­tle

5. Send pro­­pos­al at dead­­­line +/- 48 hours

6. Spend the next week or two think­ing of can­­celling

7. Fig­ure out what the ti­­tle means

8. Spend the next N-1 weeks un­til the con­fer­­ence with a con­s­tant di­a­log in your head about what you should talk about

9. Turn that con­s­tant un­or­­ga­nized di­a­log in­­­to a lit­­tle sto­ry

10. Write down the sto­ry head­­ings in slides

11. At­­tend the con­fer­­ence

12. Sit in the back while you pol­ish slides

13. Start talk­ing

14. Show slides

15. Stop talk­ing

Lots of noise re­cent­ly about Jeff At­wood's post about why you should not learn to code. I am here now telling you you should learn to code. But on­ly af­ter you learn a few oth­er things.

You should learn to speak. You should learn to write. You should learn to lis­ten. You should learn to read. You should learn to ex­press your­self.

Richard Feyn­man once de­scribed his prob­lem solv­ing al­go­rithm as fol­lows:

1. Write down the prob­lem

2. Think re­al hard

3. Write down the so­lu­­tion

Most of us can­not do that be­cause we are not Richard Feyn­man and thus, sad­ly, can­not keep all the so­lu­tion in our head in step 2, so we need to it­er­ate a few times, think­ing (not as hard as he could) and writ­ing down a bit of the so­lu­tion on each loop.

And while we who code are un­usu­al­ly proud of our abil­i­ty to write down so­lu­tions in such a clear and un­for­giv­ing way that even a com­put­er can fol­low them, it's ten, maybe a hun­dred times more use­ful to know how to write it down, or say it, in such a way that a hu­man be­ing can un­der­stand it.

Ex­pla­na­tions fit for com­put­ers are bad for hu­mans and vicev­er­sa. Hu­mans ac­cept much more com­pact, am­bigu­ous, and ex­pres­sive code. You can trans­fer high lev­el con­cepts or de­sign to hu­mans much eas­i­er than to com­put­er­s, but al­go­rithms to com­put­ers much eas­i­er than to hu­man­s.

I have a dis­trust of peo­ple who are able to com­mu­ni­cate to com­put­ers eas­i­er than with fel­low hu­man­s, a sus­pi­cion that they sim­ply have a hole in their skillset, which they could eas­i­ly fix if they saw it as es­sen­tial.

And it is an es­sen­tial skil­l. Pro­gram­mers not on­ly run on cof­fee and sug­ar and sushi and dori­tos, they run on hap­pi­ness. They have a fi­nite en­dow­ment of hap­pi­ness and they spend it con­tin­u­ous­ly, like drunk­en sailors. They per­form an ac­tiv­i­ty where jok­ing­ly they mea­sure pro­duc­tiv­i­ty on curs­es per hour, a lone­ly en­deav­our that iso­lates them (us) from oth­er hu­man­s, from fam­i­ly and friend­s.

If a de­vel­op­er can­not com­mu­ni­cate he iso­lates. When he iso­lates he can't co­op­er­ate, he can­not del­e­gate. He can't give ideas to oth­er­s, he can't re­ceive them, he can't share.

And since lots of our com­mu­ni­ca­tion is via email, and chat, and bug re­port­s, and blogs, it's bet­ter if he can write. A de­vel­op­er who can­not write is at a se­ri­ous dis­ad­van­tage. A de­vel­op­er who can­not write to ex­press an idea can­not ex­plain, he does­n't make his fel­lows bet­ter. He's a knowl­edge black hole, where in­for­ma­tion goes to die be­hind the event hori­zon of his skul­l.

So, learn to write. Learn to speak. Learn to read and lis­ten. Then learn to code.

Eng­lish on­ly!

I have not stopped work­ing on Niko­la, my stat­ic site gen­er­a­tor. Here are the plan­s:

1. Fin­ish the theme in­­stal­l­er (so you can get a theme from the site eas­i­­ly)

2. Im­­ple­­ment a theme gallery on the site (same pur­­pose)

3. Fix a cou­­ple of bugs

4. Up­­­date man­u­al

5. Pol­ish a few theme bits

6. Re­lease ver­­sion 3.x (new ma­jor num­ber be­­cause it re­quires man­u­al mi­­gra­­tion)

Af­ter that, I will push on projects Shore­ham (host­ed sites) and Smil­jan (plan­et gen­er­a­tor) and make them more pub­lic. Shore­ham will be­come a re­al web app for those who don't want to have their own serv­er. For free, hope­ful­ly!

Once I have that, I have no fur­ther fea­ture ideas, re­al­ly. So I need more peo­ple to start us­ing it, and that means I have to start an­nounc­ing it more.

So, stay tuned for ver­sion 3.x some­time next week.

Post-Niko­la, I will do a rst2pdf re­lease, and then will get back to work on a book.

This is a short sto­ry, in span­ish, so if you want to read it, click here

One of the eas­i­est ways to per­son­al­ize how your site looks is us­ing col­or and ty­pog­ra­phy. While Niko­la's "site" theme is in­tend­ed to be rather bland and neu­tral, it does­n't have to be that way, and it's easy to change.

To do these changes, you don't even need to know any CSS, HTM­L, or pro­gram­ming!

Here's the trick: Niko­la is us­ing Twit­ter Boot­strap to han­dle its styling. And they pro­vide a handy web form to cre­ate a cus­tom­ized ver­sion, just for you, at their cus­tom­ize page.

So, if you want au­vergine nav­i­ga­tion bars and av­o­ca­do back­ground­s, with couri­er fonts all over the place, that's where you do it. Just change the val­ue in the right vari­able to what­ev­er col­or you wan­t.

Once you have your bootstrap.zip, go to your site's folder, and create themes/mytheme/assets and unzip it in there, so that you have themes/mytheme/assets/css, themes/mytheme/assets/js, etc.

Create a file called themes/mytheme/parent containing the word site.

Then edit your dodo.py (or conf.py if you are using the git master) and change the THEME option "mytheme".

Re­build your site, and voilá, all your cus­tomiza­tions are now in place.

This aw­ful­ness, for ex­am­ple, was done by set­ting just three vari­ables (body­Back­ground, text­Col­or, and sans­Font­fam­i­ly):