Ha­ce una se­ma­na mas o me­nos cam­bié de tra­ba­jo re­pen­ti­na­men­te. Me des­pi­die­ron¹ al me­dio­día y me lle­vó has­ta tar­de esa mis­ma tar­de en­con­trar un nue­vo la­bu­ro.²

Per­dí una pro­me­sa de vi­si­ta a las ofi­ci­nas en Lju­bl­ja­na, ga­né una pro­me­sa de vi­si­ta a ofi­ci­nas en Lon­dres, el di­ne­ro ven­drá de un lu­gar di­fe­ren­te, Se va el clon as­ync de Fla­sk, en­tra Djan­go, co­sas así.

No pen­sé en ese mo­men­to que acon­te­ce­ría un cam­bio mu­cho más fun­da­men­ta­l, un cam­bio de tri­bus.³ Aban­do­né la tri­bu en que vi­ví mi vi­da, la ha­bi­tual­men­te GM­T-3 de mi na­ci­mien­to y me uní a Greenwi­ch 0.

Aho­ra me le­van­to a lo que es­tos ex­tran­je­ros a mi al­re­de­dor afir­man que son las 4:45 AM, así lle­go có­mo­do a mi stan­dup dia­rio, que es a mis 9:15. Es­to tie­ne efec­tos in­te­re­san­tes en mis ... to­do.

¿Mi hi­jo no la­vó los pla­tos co­mo se su­po­ne que ha­ce, y pro­me­tió ha­cer­lo "des­pué­s"? Bue­no, si me des­pier­to y los pla­tos no es­tán la­va­do­s, lo des­pier­to a él, y los pla­tos es­tán lim­pios an­tes del ama­ne­ce­r.

Ten­go ~4 ho­ras de tra­ba­jo tran­qui­lo con la ca­sa en si­len­cio, que en es­ta era en­cua­ren­te­na­da es un mon­tón.

Ter­mino de tra­ba­jar pa­ra las 5:30, cuan­do mi fa­mi­lia ju­ra que son las 13:30, así que pue­do al­mor­zar con ellos sin cor­tar el tra­ba­jo que ya ter­mi­né, y des­pués duer­mo la sies­ta, co­mo un gran­je­ro.

Pue­do des­ayu­nar dos ve­ces al día, tres si le pon­go ga­rra.

Me voy a la ca­ma a las 3A­M/11­PM, así que me sien­to un tras­no­cha­do­r, duer­mo 7 u 8 ho­ras al día pe­ro no to­das jun­ta­s. Es­toy con un li­ge­ro je­tlag en es­te mo­men­to, o tal vez en to­do mo­men­to, sin via­jar en el es­pa­cio, so­lo en el tiem­po.

Veo el ama­ne­cer to­dos los día­s.

Los días son lar­gos, co­mo es lar­go el día más lar­go del ve­ra­no, pe­ro en oto­ño. En ve­rano se­rán más lar­go­s, eter­no­s, días no­rue­go­s, 16 ho­ras de lu­z.

¿Có­mo me sien­to al res­pec­to? No sé. Es co­mo una mó­di­ca aven­tu­ra sin de­jar la ca­sa. Es co­mo vi­vir una se­ma­na sin usar la le­tra "M", co­mo co­mer en­sa­la­da ru­sa y no to­car las za­naho­ria­s, co­mo ir a tra­ba­jar a un ba­rrio dis­tin­to don­de to­do el mun­do es­tá dor­mi­do y no hay au­tos y los pá­ja­ros can­tan fuer­te y es de día en la pan­ta­lla de to­dos los otros y ...

Bue­no, no tan Lo­ve­cra­ft, che.

There has been an is­sue open in Niko­la for a lit­tle over four years.

The is­sue ti­tle is "Sup­port tags in pages" ... and I had been in­ten­tion­al­ly not do­ing any­thing about it for a (bad) rea­son.

I did not un­der­stand what the is­sue was.

Sure, support tags in pages ... how? What's that supposed to mean? What happens when you tag a page? Should pages be listed along posts in each tag? How? How does that interact with TAG_PAGES_ARE_INDEXES which turns each tag into a mini-blog?

Well, it was a bad rea­son be­cause it could have been fixed by just talk­ing to user­s. So, I did. And I wrote a min­i­mal vi­able plug­in: tagged_­pages

It's far from per­fec­t, it's ba­si­cal­ly a copy of the tags plug­in with some stuff re­named, some delet­ed and some re­placed. But it's a start. And now it can be it­er­at­ed on.

So, talk to user­s, I guess.

A few years back when I was work­ing at Canon­i­cal, I made Niko­la pack­ages for the Snap store ... which sad­ly got ne­glect­ed a fair amount af­ter I stopped work­ing there.

SO ... while I don't work there, there is no rea­son for ne­glec­t, so I just fixed the build, up­dat­ed some snapcraft.yml de­tails that had rust­ed from dis­use, checked the au­to­mat­ed build and pro­mot­ed cur­rent git mas­ter to the "stable" chan­nel.

What does this mean for you?

Well, prob­a­bly noth­ing, but if you want to try Niko­la, you can do this:

snap install nikola

At least in Ubuntu, Ubuntu derivatives and Arch derivatives if you have snapd installed, and end up with a working installation of Nikola.

Now, is this the rec­om­mend­ed way to get it? No. This has a num­ber of prob­lems be­cause of the na­ture of snap pack­ag­ing.

• You can't launch bi­na­ries so some fea­tures will just not work (ex­am­ple: niko­la serve -b).

• You can't in­­stall python pack­­ages in­­­to the snap, so if you in­­stall a plug­in with a python de­pen­­den­­cy, it will not work un­­less by chance that de­pen­­den­­cy is there al­ready (I added some!)

• I am not test­ing it much, so there is no guar­an­­tee it works on any giv­en day (But it should!)

If you are us­ing Niko­la as a snap and run in­to any is­sues, ping me via an is­sue. Some­times I may take a while to get to it, but I will get to it.

UP­DATE: Af­ter fix­ing bugs, it turns out the im­prove­ment is rough­ly 25%, not 75%, which is still nice :-)

Im­age gal­leries is one of my favourite fea­tures in Niko­la

I use them in my site and they are awe­some! Just dump a bunch of im­ages in a fold­er and you will have them nice­ly pre­sent­ed. Then you can add a file with a fold­er de­scrip­tion amd so on.

One thing I did not like was that they were pret­ty slow. My site has 3290 im­ages in the gal­leries sec­tion, and I dread­ed pro­cess­ing them be­cause they took for­ev­er, where for­ev­er means around 5 min­utes.

Un­re­lat­ed to per­for­mance, we had a fea­ture re­quest for sup­port­ing mul­ti­ple thumb­nail sizes, which is use­ful for things like pre­sent­ing the ide­al im­age size for your dis­play and such.

Well, to support that someday, a good first step is to have our generic image processor class support more than one thumbnail size. So, just take the scale_image implementation and have it support more than one size and more than one destination path, then loop over those, and that's that. Right?

OTO­H, it turns out we pro­cessed each im­age TWICE be­cause we would clean EXIF da­ta and/or re­size the "o­rig­i­nal" im­ages. Some­times the source im­ages have res­o­lu­tions that sim­ply make no sense on a web­site!

So, since our implementation of scale_image only accepted one destination, we would:

1. read orig­i­nal im­age -> cleanup -> re­size to thumb size -> save
2. read orig­i­nal im­age -> cleanup -> re­size to "large" size -> save

So, since I had now a ver­sion that could do the "re­size" and "save" parts on one cal­l, this be­came:

1. read orig­i­nal im­age -> cleanup
2. re­size to thumb size -> save
3. re­size to "large" size -> save

And the re­al­ly slow part is ... read­ing the orig­i­nal im­age. So this sud­den­ly made the whole process take 25% of the time it took be­fore.

In my spe­cif­ic site, it went down from 356 sec­onds to 112 sec­ond­s. That's a 70% de­crease in ren­der­ing time. Which is big. And in code I first wrote around 2013, that is huge.

So, the les­son is ... I am a crap­py pro­gram­mer, may­be? Or used to be? Or maybe just that even old, ma­ture code could still have large op­por­tu­ni­ties for im­prove­men­t?

Who knows.

[*] Terms and con­di­tions may ap­ply.

Evil tricks to make even your [my] crap­py code faster. How much faster? FASTER.

The eng­lish ver­sion of this talk I al­ready gave like 3 times, but, you know, the talk stays the same, you just need to change the au­di­ence!