Inlägg, delade länkar och notiser, sida 8

Wacken ställs in igen →

It is with a heavy heart that we have decided that Wacken Open Air cannot take place at the end of July this year. We therefore postpone the festival to 04.08. - 06.08.2022. This decision was anything but easy for us, also because we know that you are already in the middle of the preparations and planning. Like we are, too

Så, äntligen, ställde Wacken in efter flera veckor i ett falskt hopp. Inte ens the Holy ground kan värja sig mot viruset.

Jag hade älskat att återuppleva Wacken igen, då det är något alldeles extra. Bland årets band hade jag mest sett fram emot Judas Priest, Grave Digger, Amon Amarth, Pestilence, Agalloch och Tiamat.

Om att välja tråkiga teknologier →

What counts as boring? That’s a little tricky. “Boring” should not be conflated with “bad.” There is technology out there that is both boring and bad. You should not use any of that. But there are many choices of technology that are boring and good, or at least good enough. MySQL is boring. Postgres is boring. PHP is boring. Python is boring. Memcached is boring. Squid is boring. Cron is boring.

Jag kommer på mig själv med att prata om "boring tech" ganska ofta, särskilt när jag sitter i samtal med kollegor som hittar något nytt och skinande som vore roligt att testa. Den är från 2015, men är verkligen otroligt relevant.

T ex så tar den upp konceptet med Innovation tokens. Den pratar även om unknowns, och unknown unknowns.

When choosing technology, you have both known unknowns and unknown unknowns.

• A known unknown is something like: we don’t know what happens when this database hits 100% CPU.
• An unknown unknown is something like: geez it didn’t even occur to us that writing stats would cause GC pauses.

Även denna tankelek och prov på kreativitet är värd att bokmärka artikeln för, och diskutera med sitt team.

One of the most worthwhile exercises I recommend here is to consider how you would solve your immediate problem without adding anything new. First, posing this question should detect the situation where the “problem” is that someone really wants to use the technology. If that is the case, you should immediately abort.

It can be amazing how far a small set of technology choices can go. The answer to this question in practice is almost never “we can’t do it,” it’s usually just somewhere on the spectrum of “well, we could do it, but it would be too hard”. If you think you can’t accomplish your goals with what you’ve got now, you are probably just not thinking creatively enough.

Mattheten och tröttheten kring frameworks →

The problem with modern web dev summed up in a tweet:

The problem isn't frameworks themselves, but the fervent euphoria around them, where a privileged majority gets to say "this is a best practice, learn it", while ignoring the unsustainable burnout that sort of churn invites.

— Jeremy Wagner (@malchata) May 8, 2021

En tråd som belyser något jag själv känt, men haft svårt att sätta orden på: att det faktiskt kostar något att försöka hänga med på frameworks.

Jag har likt @malchata också rätt många år i yrket, och har flera gånger investerat massor av tid och ork på att lära mig något - bara för att bli tvungen att helt kasta bort kunskaperna och ersätta dem med nya.

Det jag har kommit att eftersträva, och även råda andra att göra, är att ställa frågan Vad gör X som jag inte redan har i verktygslådan? X är i detta fall

• ett nytt ramverk,
• ett nytt bibliotek,
• Ett nytt API,
• En ny paradigm,
• ett nytt programmeringsspråk eller
• En vidareutbyggnad/återupptäckelse av något av ovantående.

En annan viktig fråga att ställa sig är Är det möjligt att lösa problem/behov Y utan att introducera något nytt, och hur svårt är det i så fall? Om X inte har ett tydligt övertag eller glasklar fördel, så är det förmodligen inte värt besväret.

En blandning av magkänsla, fingertoppskänsla och omvärldsbevakning gör att jag avfärdar en majoritet av alla X som trendar. Jag lutar mig tillbaka, iakttar vad som händer och är sällan först på bollen på något - även om jag gärna bekantar mig med X rätt tidigt, så undviker jag att försöka göra riktiga saker med X.

Några exempel.

• Saker jag ägnat tusentals timmar åt, som inte längre är relevant: PHP4-5, ASP, XHTML, tabellbaserad layout, diverse Google-API:er, CSS sprites, CSS sliding doors, ActionScript/Flash, buggar i IE6.
• Saker jag lärt mig från grunden sedan mycket länge sedan, och fortfarande har fördelar av: Progressive enhancement, Prototyp-arv och scopes i JavaScript, CSS Grids, Elixir/OTP, sass, BEM.
• Kunskaper jag vet är på väg bort, men haft stor nytta av att använda mig av: layout med CSS floats, Python 2 unicode, Angular, React+Redux.

Utmärkta exempel på att använda CSS custom properties →

In practice, component definitions have way more styles than just colours. There’s a bunch of box-model properties, maybe a display, and possibly text styling instructions. In any case, a lot of lines of CSS.

If you use custom properties only for those CSS properties that will change you give future CSS developers a much better and quicker insight in how your component works. If the definition uses a custom property that means the property may change in some circumstances. If it uses a fixed definition you know it’s a constant.

CSS custom properties är något som jag själv försöker tillämpa så mycket jag kan i projekt. Denna artikel öppnade några dörrar till och gör det än tydligare att det är skillnad på Sass-variabler och CSS Custom Properties: man ska kombinera dem, inte välja en av dem.

På Twitter-tråden om artikeln kompletterade Sara Soeidan med en egen artikel om att arbeta med CSS custom properties, som också är läsvärd.