10 interesting stories served every morning and every evening.




1 690 shares, 55 trendiness

La Suite numérique

Full list of pro­jects avail­able here.

La Suite numérique (La Suite for short) is a full blown open-source dig­i­tal work­space for on­line col­lab­o­ra­tion and team­work.

La Suite is built by French gov­ern­ment agen­cies DINUM and ANCT. It is also the prod­uct of a close eu­ro­pean col­lab­o­ra­tion with the Netherlands and German state.

Our code base is a 100% open source and MIT li­cenced.

Come say hello on Matrix

...

Read the original on github.com »

2 390 shares, 36 trendiness

We mourn our craft

I did­n’t ask for this and nei­ther did you.

I did­n’t ask for a ro­bot to con­sume every blog post and piece of code I ever wrote and par­rot it back so that some hack could make money off of it.

I did­n’t ask for the role of a pro­gram­mer to be re­duced to that of a glo­ri­fied TSA agent, re­view­ing code to make sure the AI did­n’t smug­gle some­thing dan­ger­ous into pro­duc­tion.

And yet here we are. The worst fact about these tools is that they work. They can write code bet­ter than you or I can, and if you don’t be­lieve me, wait six months.

You could ab­stain out of moral prin­ci­ple. And that’s fine, es­pe­cially if you’re at the tail end of your ca­reer. And if you’re at the be­gin­ning of your ca­reer, you don’t need me to ex­plain any of this to you, be­cause you al­ready use Warp and Cursor and Claude, with ChatGPT as your ther­a­pist and pair pro­gram­mer and maybe even your lover. This post is for the 40-somethings in my au­di­ence who don’t re­al­ize this fact yet.

So as a se­nior, you could ab­stain. But then your ju­nior col­leagues will even­tu­ally code cir­cles around you, be­cause they’re wear­ing bazooka-pow­ered jet­packs and you’re still rid­ing around on a fixie bike. Eventually your boss will start ask­ing why you’re get­ting paid twice your zoomer col­leagues’ salary to pro­duce a tenth of the code.

Ultimately if you have a mort­gage and a car pay­ment and a fam­ily you love, you’re go­ing to make your de­ci­sion. It’s maybe not the de­ci­sion that your younger, more ide­al­is­tic self would want you to make, but it does keep your car and your house and your fam­ily safe in­side it.

Someday years from now we will look back on the era when we were the last gen­er­a­tion to code by hand. We’ll laugh and ex­plain to our grand­kids how silly it was that we typed out JavaScript syn­tax with our fin­gers. But se­cretly we’ll miss it.

We’ll miss the feel­ing of hold­ing code in our hands and mold­ing it like clay in the ca­ress of a mas­ter sculp­tor. We’ll miss the sleep­less wran­gling of some odd bug that even­tu­ally re­lents to the de­bug­ger at 2 AM. We’ll miss cre­at­ing some­thing we feel proud of, some­thing true and right and good. We’ll miss the sat­is­fac­tion of the artist’s sig­na­ture at the bot­tom of the oil paint­ing, the GitHub repo say­ing I made this.”

I don’t cel­e­brate the new world, but I also don’t re­sist it. The sun rises, the sun sets, I or­bit help­lessly around it, and my protests can’t stop it. It does­n’t care; it con­tin­ues its arc across the sky re­gard­less, mov­ing but un­moved.

If you would like to grieve, I in­vite you to grieve with me. We are the last of our kind, and those who fol­low us won’t un­der­stand our sor­row. Our craft, as we have prac­ticed it, will end up like some black­smith’s tool in an arche­o­log­i­cal dig, a cu­rio for fu­ture gen­er­a­tions. It can­not be helped, it is the na­ture of all things to pass to dust, and yet still we can mourn. Now is the time to mourn the pass­ing of our craft.

...

Read the original on nolanlawson.com »

3 310 shares, 23 trendiness

Software Engineering is back

I don’t post a lot. But when I do, it’s be­cause I think few peo­ple are say­ing out loud what I’m notic­ing.

I’ve been build­ing a prod­uct from the ground up. Not the I spun up a Next.js tem­plate” kind of ground up. I mean from net­work con­fig­u­ra­tion to prod­uct de­sign to pric­ing de­ci­sions. Truly end to end. And I’ve been do­ing it us­ing fron­tier mod­els and cod­ing agents for hours and hours every sin­gle day, both on this pro­ject and in my full time work. I’ve been try­ing to stay away from the chaos and the hype, fil­ter­ing hard for what is ac­tu­ally valu­able.

Since December 2025, things have dra­mat­i­cally changed for the bet­ter. Many have no­ticed. Few are draw­ing the right con­clu­sions.

Antirez likes to call it automated pro­gram­ming”, and I re­ally like that fram­ing. It cap­tures the essence far bet­ter than the shal­low, al­most dis­mis­sive la­bel of vibe cod­ing”. Automation was at the core of most of the work and cul­tural rev­o­lu­tions of hu­man his­tory. The print­ing press, the loom, the as­sem­bly line. This one does­n’t dif­fer much.

Most of my work is still there. I still have to deeply think about every im­por­tant as­pect of what I want to build. The ar­chi­tec­ture, the trade offs, the prod­uct de­ci­sions, the edge cases that will bite you at 3am. What’s gone is the tear­ing, ex­haust­ing man­ual labour of typ­ing every sin­gle line of code.

At this point in time, mod­els and tools, when put in a clean and ma­ni­a­cally well set up en­vi­ron­ment, can truly make the dif­fer­ence. I can be the ar­chi­tect with­out the wear­ing act of lay­ing every sin­gle brick and spread­ing the mor­tar. I can de­sign the dress with­out the act of cut­ting and sewing each in­di­vid­ual piece of fab­ric. But I can do all of this with the ex­pe­ri­ence on my back of hav­ing laid the bricks, spread the mor­tar, cut and sewn for twenty years. If I don’t like some­thing, I can go in, un­der­stand it and fix it as I please, in­struct­ing once and for all my setup to do what I want next time.

Automated pro­gram­ming es­pe­cially al­lows me to quickly build the tools I need so fast that every black­smith that ever ex­isted on this earth would envy me deeply. Finally able to re­ally fo­cus on the things they have in mind. Finally ded­i­cat­ing more time of their craft to the art they con­ceive, not the sweat of the forge.

It’s been months now that I have this thought crys­tal­lized in my mind. It is so clear to me that I gen­uinely don’t un­der­stand why every­one is not scream­ing it to the world.

We can fi­nally get rid of all that mid­dle work. That adapt­ing layer of garbage we blindly ac­cepted dur­ing these years. A huge amount of frame­works and li­braries and tool­ing that has com­pletely pol­luted soft­ware en­gi­neer­ing, es­pe­cially in web, mo­bile and desk­top de­vel­op­ment. Layers upon lay­ers of ab­strac­tions that ab­stract noth­ing mean­ing­ful, that solve prob­lems we should­n’t have had in the first place, that cre­ate ten new prob­lems for every one they claim to fix.

Think about what hap­pened. We, as an in­dus­try, looked at the gen­uine com­plex­ity of build­ing soft­ware and in­stead of sharp­en­ing our think­ing, we bought some­one else’s think­ing off the shelf. We wrapped every­thing in frame­works like wrap­ping a bro­ken leg in silk. It looks nice. The leg is still bro­ken.

In my mind, be­sides the self de­clared ob­jec­tives, frame­works solve three prob­lems. Two ex­plicit and one ob­vi­ous but never de­clared.

Simplification”. Software en­gi­neers are scared of de­sign­ing things them­selves. They would rather ac­cept some­one else’s struc­ture, de­spite hav­ing to force fit it into their prod­uct, rather than tak­ing the time to start from the goal and work back­wards to cre­ate the per­fect suit for their idea. Like an ar­chi­tect blindly ac­cept­ing an­other ar­chi­tec­t’s blue­prints and ap­ply­ing them re­gard­less of the con­text, the needs, the ter­rain, the new tech­no­log­i­cal pos­si­bil­i­ties. We de­cided to re­move com­plex­ity not by sharp­en­ing our men­tal mod­els around the prod­ucts we build, but by buy­ing a one size fits all de­sign and ap­ply­ing it every­where. That is not sim­pli­fi­ca­tion. That is in­tel­lec­tual sur­ren­der.

Automation. This is the only point I can ac­tu­ally, more or less, un­der­stand and buy. Boilerplate is bor­ing work. I hate it. And I es­pe­cially hate us­ing li­braries that I then need to study, keep up­dated, be aware of vul­ner­a­bil­i­ties for, just for the pur­pose of re­mov­ing the cre­ation of du­pli­cated but nec­es­sary code. Think about ORMs, CRUD man­age­ment, code gen­er­a­tion, API doc­u­men­ta­tion and so on. The grunt work that no­body wants to do but every­body needs done. Fair enough. But hold that thought, be­cause this is ex­actly the point where every­thing changes.

Labour cost. This is the quiet one. The one no­body puts on the con­fer­ence slide. For com­pa­nies, it is much bet­ter hav­ing Google, Meta, Vercel de­cid­ing for you how you build prod­uct and ship code. Adopt their frame­work. Pay the cost of lock in. Be en­chanted by their cloud man­aged so­lu­tion to host, de­ploy, store your stuff. And you un­lock a fea­ture that has noth­ing to do with en­gi­neer­ing: you no longer need to hire a soft­ware en­gi­neer. You hire a React Developer. No need to train. Plug and play. Easy to re­place. A cog in a ma­chine de­signed by some­one else, main­tain­ing a sys­tem ar­chi­tected by some­one else, solv­ing prob­lems de­fined by some­one else. This is not en­gi­neer­ing. This is op­er­at­ing.

In my opin­ion Software en­gi­neer­ing, the true one, is back again.

I am not speak­ing out of my lungs only. I’ve been de­vel­op­ing this way al­most flaw­lessly for over two years at this point. But the true rev­o­lu­tion hap­pened clearly last year, and since December 2025 this is ob­vi­ous to any­one pay­ing at­ten­tion. From now on it will be even more so.

We have the chance again to get rid of use­less com­plex­ity and keep work­ing on the true and wel­come com­plex­ity of our ideas, our fea­tures, our prod­ucts. The com­plex­ity that mat­ters. The com­plex­ity that is ac­tu­ally yours.

Automation and boil­er­plat­ing have never been so cheap to over­come. I’ve been ba­si­cally never writ­ing twice the same line of code. I’m in­stantly build­ing small tools I need, pur­pose built, ex­actly shaped around the prob­lem at hand. I don’t need any fancy monorepo man­ager. A sim­ple Makefile cov­ers 100% of my needs for 99% of my use cases. When things will get very com­pli­cated, and if they get very com­pli­cated, I’ll think about it. But only then. Not a sec­ond be­fore. This is en­gi­neer­ing. You solve the prob­lem you have, not the prob­lem some­one on a con­fer­ence stage told you that you’ll even­tu­ally have.

Agents are re­ally well pre­pared when it comes to ba­sic tools. Tools that have been around not for months, but lit­er­ally for decades. Bash was born in 1989, just pre­ced­ing me by two months. The most mediocre model run­ning at this time knows bash bet­ter than any per­son in the world. Bash is the uni­ver­sal adapter. It is not a co­in­ci­dence that cod­ing agents are shift­ing from com­plex and ex­pen­sive MCP con­fig­u­ra­tions to a sim­ple agent loop with bash as a way to in­ter­act, lit­er­ally, with the world. The old­est tool turned out to be the most fu­ture proof. There’s a les­son in there if you care to lis­ten.

Really think about it.

Why do you ever need, for most of the use cases you can think of, a use­less, ex­pen­sive, flawed, of­ten vul­ner­a­ble frame­work, and the pa­rade of li­braries that comes with it, that you prob­a­bly use for only 10% of its ca­pa­bil­i­ties? With all the costs as­so­ci­ated with it. From the least” ex­pen­sive: op­er­a­tional costs like keep­ing every­thing up­dated be­cause they once again found a crit­i­cal vul­ner­a­bil­ity in your Next.js ver­sion. To the most ex­pen­sive one: the cost to your Design Choices. The in­vis­i­ble cost. The one you pay every day with­out even re­al­iz­ing it, be­cause you’ve been pay­ing it so long you for­got what free­dom felt like.

If you keep ac­cept­ing this trade off, you are not only los­ing the biggest op­por­tu­nity we’ve seen in soft­ware en­gi­neer­ing in decades. You are prob­a­bly not rec­og­niz­ing your own lazi­ness in once again buy­ing what­ever the hy­per­scalers have de­cided for you. You’re let­ting Google and Meta and Vercel be your ar­chi­tect, your de­signer, your thinker. And in ex­change, you get to be their op­er­a­tor.

The tools are here. The mod­els are here. The rev­o­lu­tion al­ready hap­pened and most peo­ple are still dec­o­rat­ing the old house.

Stop wrap­ping bro­ken legs in silk. Start build­ing things that are yours.

...

Read the original on blog.alaindichiappari.dev »

4 273 shares, 17 trendiness

by Jesper Ordrup

This is a vo­cal tech­nique ref­er­ence cov­er­ing 21 tech­niques across five cat­e­gories. It’s de­signed as a learn­ing com­pan­ion — whether you’re a be­gin­ner find­ing your voice or an ex­pe­ri­enced singer ex­pand­ing your toolkit.

The sticky bar be­low the ti­tle lets you jump be­tween sec­tions. Each col­ored dot matches its cat­e­gory:

— ways to shape and color your sound

How to read the table

Each row is one tech­nique. Hover the tech­nique name to see a short de­scrip­tion. The dif­fi­culty dots (● ○ ○ ○ ○) show how ad­vanced it is, from 1 to 5.

Some tech­niques show small dashed chips be­neath the name — these are pre­req­ui­sites. The chip color tells you which cat­e­gory the pre­req­ui­site be­longs to. Hover a chip to see what that tech­nique sounds like, or click it to jump straight to its row in the table.

Techniques marked with ⚠️ warn­ings can cause dam­age if done in­cor­rectly. The golden rule: if it hurts, stop. Work with a vo­cal coach for any­thing rated 4–5 dots.

Use EN / DA to switch lan­guage and the theme but­ton to cy­cle through five color schemes: Dark, Light, Midnight, Forest, and Ember. Your choices are saved au­to­mat­i­cally.

Nogle teknikker viser små sti­plede chips un­der navnet — det er forud­sæt­ninger. Chipfarven fortæller hvilken kat­e­gori forud­sæt­nin­gen hører til. Hold musen over en chip for at se hvad teknikken ly­der som, eller klik for at hoppe di­rekte til den i tabellen.

I hope this guide helps you on your vo­cal jour­ney. If you have sug­ges­tions, found a bug, or just want to say hi — I’d love to hear from you.

Check your pos­ture — feet shoul­der-width, shoul­ders back and down, chin level.

Release ten­sion — roll your neck, shrug and drop shoul­ders, shake out your arms.

No cold starts — never belt, dis­tort, or push range with­out warm­ing up first.

Breathing (1 min) — Inhale 4 counts into belly/​sides/​back. Exhale on Sss” for 15–20 sec­onds. Repeat 3x. This ac­ti­vates your sup­port sys­tem.

Lip Trills (1 min) — Blow air through closed lips to make them vi­brate. Slide up and down your range. Keeps every­thing re­laxed and con­nected.

Humming (1 min) — Hum on Mmm” through 5-note scales, as­cend­ing. Feel the buzz in your face (mask res­o­nance). Keep jaw and tongue loose.

Vowel Slides (1 min) — Sing Mee-Meh-Mah-Moh-Moo” on a sin­gle note, then move up by half steps. Opens the vo­cal tract grad­u­ally.

Sirens (1 min) — Slide from bot­tom to top and back on Woo” or Wee.” Full range, gen­tle, no push­ing. This bridges your reg­is­ters.

Straw phona­tion — Sing through a straw (or into a cup of wa­ter with a straw). Creates back-pres­sure that bal­ances air­flow and fold clo­sure. Best warm-up tool avail­able.

Tongue trills — Roll your tongue on Rr” while singing scales. Releases tongue ten­sion (a com­mon prob­lem).

Arpeggios — 1-3-5-8-5-3-1 on Nay” or Gee” to work through your pas­sag­gio (break area).

A dome-shaped mus­cle be­neath your lungs. When you in­hale, it flat­tens down­ward, pulling air in. You don’t di­rectly sing from your di­aphragm” — you use it to con­trol the rate of ex­ha­la­tion. Think of it as an air pres­sure reg­u­la­tor, not a sound source.

Two small folds of tis­sue in your lar­ynx. When air passes through, they vi­brate and cre­ate sound. Thicker vi­bra­tion = chest voice. Thinner vi­bra­tion = head voice. Partial clo­sure = falsetto/​breathy. The space be­tween them is called the glot­tis.

Your voice box.” It can move up (bright, thin sound) or down (dark, warm sound). For most singing, a neu­tral or slightly low­ered lar­ynx is ideal. A high lar­ynx un­der pres­sure = strain. Learn to keep it sta­ble — yawn­ing gen­tly while singing helps find the right po­si­tion.

Abdominals — Control ex­ha­la­tion pres­sure. They don’t push air out — they slow the col­lapse of the rib cage.

Intercostals — Muscles be­tween your ribs. Keep your ribs ex­panded dur­ing singing. This is appoggio” (leaning into the breath).

Back mus­cles — Often for­got­ten. Your lower back ex­pands when breath­ing cor­rectly. Engage it for sup­port.

Stand with feet shoul­der-width apart. Knees slightly bent (not locked). Shoulders re­laxed, back and down. Chest com­fort­ably open. Head bal­anced on top of the spine — not jut­ting for­ward. Imagine a string pulling you up from the crown of your head.

Hydration — Drink wa­ter con­sis­tently through­out the day, not just be­fore singing. Your vo­cal folds need sys­temic hy­dra­tion.

Steam in­hala­tion — Breathe steam for 10 min­utes be­fore heavy singing. This di­rectly hy­drates the folds.

Rest — Your voice needs re­cov­ery time. Avoid talk­ing loudly af­ter in­tense ses­sions.

Din stemmeboks.” Den kan bevæge sig op (lys, tynd lyd) eller ned (mørk, varm lyd). Til de fleste for­mer for sang er en neu­tral eller let sæn­ket strube ideel. En høj strube un­der pres = be­last­ning. Lær at holde den sta­bil — at gabe blidt mens du syn­ger hjælper med at finde den rette po­si­tion.

Common ad­vice that’s mis­lead­ing, in­com­plete, or out­right harm­ful. If some­one tells you any of these, be skep­ti­cal.

You can’t di­rectly con­trol your di­aphragm — it’s an in­vol­un­tary mus­cle on the in­hale. What peo­ple mean is: use your ab­dom­i­nal and in­ter­costal mus­cles to con­trol ex­ha­la­tion. Saying sing from your di­aphragm” is like say­ing digest from your stom­ach.” Technically in­volved, but not how you’d teach it.

Drink tea with honey to fix your voice”

Tea and honey never touch your vo­cal folds — they go down your esoph­a­gus, not your tra­chea. They can soothe throat ir­ri­ta­tion and feel nice, but they don’t fix” or coat” your cords. What ac­tu­ally helps: steam in­hala­tion and sys­temic hy­dra­tion (water, hours in ad­vance).

The sound is­n’t pro­duced in your chest. Chest voice” refers to the thick vo­cal fold vi­bra­tion pat­tern that cre­ates sym­pa­thetic res­o­nance you feel in your up­per torso. The sound is al­ways made at the vo­cal folds in your lar­ynx.

Falsetto is only for men”

Everyone with vo­cal folds can pro­duce falsetto — it’s a mode of vi­bra­tion where the folds don’t fully close. Women use it too, though the tim­bral dif­fer­ence from head voice may be less dra­matic.

They give you a dam­aged voice. The rasp” from smok­ing and al­co­hol comes from swollen, ir­ri­tated, de­hy­drated folds. Healthy vo­cal dis­tor­tion uses the false folds and ary­tenoids — struc­tures above the true cords. One is con­trolled art, the other is per­ma­nent dam­age.

The ex­act op­po­site. High notes re­quire less air, not more. Pushing more air at higher pitches forces the folds apart and cre­ates strain. Think less air, more com­pres­sion” — let the folds do the work.

Artificial vi­brato (jaw wob­ble, di­aphragm pulse) sounds un­nat­ural and cre­ates ten­sion. Real vi­brato emerges nat­u­rally when breath sup­port is solid and the throat is re­laxed. If you don’t have vi­brato yet, the fix is bet­ter tech­nique — not man­u­fac­tur­ing it.

You’re ei­ther born with it or you’re not”

Singing is a mo­tor skill. Some peo­ple have nat­ural ad­van­tages (vocal fold length, res­o­nance cav­ity size), but tech­nique, pitch ac­cu­racy, tone qual­ity, and range are all train­able. Most natural” singers prac­ticed ob­ses­sively as chil­dren.

Your vo­cal folds are tis­sue. They need in­creased blood flow and grad­ual stretch­ing be­fore heavy use — just like any other mus­cle. Cold singing is the fastest path to strain, nod­ules, and he­m­or­rhages.

Pain means dam­age. Unlike skele­tal mus­cles, vo­cal folds don’t grow stronger from mi­cro-tears. Pain, burn­ing, or per­sis­tent hoarse­ness = stop im­me­di­ately. Rest. If it lasts more than a few days, see an ENT spe­cial­ist.

Du kan ikke di­rekte kon­trollere dit mellemgulv — det er en ufriv­il­lig muskel ved in­dånd­ing. Det folk mener er: brug dine mave- og in­terkostal­muskler til at kon­trollere udåndin­gen. At sige syng fra mellemgul­vet” er som at sige fordøj fra maven.”

This guide uses tra­di­tional vo­cal ter­mi­nol­ogy (chest voice, head voice, mixed voice, etc.) be­cause it’s the most widely un­der­stood frame­work world­wide. However, the most sci­en­tif­i­cally val­i­dated sys­tem is Complete Vocal Technique (CVT), de­vel­oped by Cathrine Sadolin at the Complete Vocal Institute in Copenhagen.

CVT is built on laryn­go­scopic imag­ing, EGG mea­sure­ments, and peer-re­viewed acoustic re­search. Here’s how the two frame­works re­late.

CVT clas­si­fies all singing into four modes based on vo­cal tract con­fig­u­ra­tion — not felt vi­bra­tion:

Support — Coordinated ab­dom­i­nal, waist, so­lar plexus, and back mus­cle en­gage­ment to con­trol air pres­sure and air­flow. (This guide: Breath Support)

Necessary Twang — Narrowing the epiglot­tic fun­nel for clearer, more ef­fi­cient sound. CVT con­sid­ers this foun­da­tional for all healthy singing, not just a style. (This guide: Twang)

Avoid pro­trud­ing jaw & tight­ened lips — These trig­ger un­con­trolled vo­cal cord con­stric­tion, es­pe­cially in up­per reg­is­ter. (Not ex­plic­itly cov­ered in this guide)

Overdrive” in CVT is a clean mode, not dis­tor­tion

Vowel rules: CVT re­stricts spe­cific vow­els per mode. Traditional ped­a­gogy uses gen­eral vowel mod­i­fi­ca­tion. Both work, but CVT is more pre­cise.

Metal & Density: CVT uses degree of metal” (0–100%) and density” (fuller vs. re­duced) as pa­ra­me­ters. Traditional ped­a­gogy does­n’t have these con­cepts.

Overdrive” means dif­fer­ent things: In this guide, over­drive = heavy vo­cal dis­tor­tion (like gui­tar over­drive). In CVT, Overdrive = a clean, shouty vo­cal mode.

Learn more: com­plete­vo­calin­sti­tute.com

Look for ex­pand­able an­no­ta­tions on tech­nique cards through­out this guide.

The fun­da­men­tal modes of vo­cal fold vi­bra­tion. Every sound you make lives some­where on this spec­trum. Master these be­fore any­thing else.

Ways of us­ing your reg­is­ters to cre­ate spe­cific sounds. These de­fine gen­res and artis­tic iden­tity.

Textures and col­ors you add to your base tone. These are the sea­son­ing — use them de­lib­er­ately, not as de­faults.

Decorative tech­niques that add flair, per­son­al­ity, and mu­si­cal­ity to your phras­ing.

The foun­da­tion every­thing else rests on. Control here is the dif­fer­ence be­tween am­a­teurs and pro­fes­sion­als.

...

Read the original on jesperordrup.github.io »

5 193 shares, 13 trendiness

Drivers over 70 to face eye tests every three years

Rebecca Guy, se­nior pol­icy man­ager at the Royal Society for the Prevention of Accidents, said: Regular vi­sion checks are a sen­si­ble way to re­duce risk as we age, but the pri­or­ity must be a sys­tem that sup­ports peo­ple to drive safely for as long as pos­si­ble, while en­sur­ing timely ac­tion is taken when health or eye­sight could put them or oth­ers in dan­ger.”

...

Read the original on www.bbc.com »

6 175 shares, 25 trendiness

Jonathan Whiting

I am an un­usual beast. All my solo pro­ject games I’ve been mak­ing re­cently have been writ­ten in vanilla’ C. Nobody does this. So I think it might be in­ter­est­ing to ex­plain why I do.

Dry pro­gram­ming lan­guage opin­ions in­com­ing, you have been warned.

There’s some things which are non-ne­go­tiable. First of, it has to be re­li­able. I can’t af­ford to spend my time deal­ing with bugs I did­n’t cause my­self.

A lot of my games were writ­ten for flash, and now flash is dy­ing. I do not

want to spend my time port­ing old games to new plat­forms, I want to make new games. I need a plat­form that I am con­fi­dent will be around for a while.

Similarly I want to avoid ty­ing my­self to a par­tic­u­lar OS, and ide­ally I’d like to have the op­tion of de­vel­op­ing for con­soles. So it’s im­por­tant that my pro­gram­ming lan­guage is portable, and that it has good portable li­brary sup­port.

The strongest thing on my de­sired, but not re­quired list is sim­plic­ity. I find look­ing up lan­guage fea­tures, and quirky clever’ api’s in­cred­i­bly tir­ing. The ideal lan­guage would be one I can mem­o­rize, and then never have to look things up.

Dealing with bugs is huge cre­ative drain. I want to pro­duce less bugs, so I want strict typ­ing, strong warn­ing mes­sages and sta­tic code analy­sis. I want bugs to be eas­ier to find, so I want good de­bug­gers and dy­namic analy­sis.

I’m not in­ter­est­ing in high-def re­al­ism, but I do still care a bit about per­for­mance. Having more cy­cles avail­able broad­ens the palette of things you can do. It’s par­tic­u­larly in­ter­est­ing to ex­plore what is pos­si­ble with mod­ern, pow­er­ful com­put­ers if you aren’t per­su­ing fi­delity.

Even more than that I care about the speed of the com­piler. I am not a zen mas­ter of fo­cus, and wait­ing 10+ sec­onds is waste­ful, yes, but more im­por­tantly it breaks my flow. I flick over to Twitter and sud­denly 5+ min­utes are gone.

I am not an OOP con­vert. I’ve spent most of my pro­fes­sional life work­ing with classes and ob­jects, but the more time I spend, the less I un­der­stand why you’d want to com­bine code and data so rigidly. I want to han­dle data as data and write the code that best fits a par­tic­u­lar sit­u­a­tion.

C++ is still the most com­mon lan­guage for writ­ing games, and not with­out rea­son. I still do al­most all of my con­tract work in it. I dis­like it in­tensely.

C++ cov­ers my needs, but fails my wants badly. It is des­per­ately com­pli­cated. Despite de­cent tool­ing it’s easy to cre­ate in­sid­i­ous bugs. It is also slow to com­pile com­pared to C. It is high per­for­mance, and it of­fers fea­tures that C does­n’t have; but fea­tures I don’t want, and at a great com­plex­ity cost.

C# and Java have sim­i­lar is­sues. They are ver­bose and com­plex beasts, and I am search­ing for a con­cise, sim­ple crea­ture. They both do a lot to rail­road a pro­gram­mer into a strongly OOP style that I am op­posed to. As per most higher level lan­guages they have a ten­dency to hide away com­plex­ity in a way that does­n’t ac­tu­ally pre­vent it from bit­ing you.

I like Go a lot. In many ways it is C re­vis­ited, tak­ing into ac­count what has be learnt in the long years since it was re­leased. I would like to use it, but there are big road­blocks that pre­vent me. The stop-the-world garbage col­lec­tion is a big pain for games, stop­ping the world is some­thing you can’t re­ally af­ford to do. The li­brary sup­port for games is quite poor, and though you can wrap C libs with­out much trou­ble, do­ing so adds a lot of busy work. It is niche enough that I worry a lit­tle about long term rel­e­vance.

It would be nice to make things for the web, but it feels like a ter­ri­fy­ingly fast mov­ing en­vi­ro­ment. It is par­tic­u­larly scary with the death of flash. I re­ally dis­like javascript, it is so loose that I mar­vel that peo­ple are able to write big chunks of soft­ware in it. I have no in­ter­est in try­ing.

Haxe feels much more promis­ing than most al­ter­na­tives. If I do web stuff again I’ll be div­ing in here. There is some good li­brary sup­port. I am a lit­tle con­cerned by its rel­a­tive youth, will it last? I don’t much have else to say about it though, I’ve only dab­bled with the sur­face.

Some peo­ple just say screw it, I’ll write my own lan­guage, the lan­guage I want to use. I ad­mire this, and some­times I toy with the idea of do­ing the same. It feels like too much to throw away all ex­ist­ing li­brary sup­port, and tak­ing full re­spon­si­bilty for fu­ture com­pat­i­bil­ity. It is also very dif­fi­cult, and when it comes down to it I would rather be mak­ing games than pro­gram­ming lan­guages.

C is dan­ger­ous, but it is re­li­able. A very sharp knife that can cut fin­gers as well as veg, but so sim­ple it’s not too hard to learn to use it care­fully.

It is fast, and when it comes to com­pi­la­tion I can’t think of any­thing faster.

It can be made to run on just about any­thing. Usually this is rel­a­tively easy. It is hard to imag­ine a time when this won’t be the case.

The li­brary and tool­ing sup­port is strong and on­go­ing.

I say this with some sad­ness, but it is still the lan­guage for me.

I ab­solutely DO NOT mean to say hey, you should use C too”. I full appe­ci­ate pref­er­ences here are pretty spe­cific and un­usual. I have also al­ready writ­ten more vanilla’ C code than most, and this cer­tainly is part of my com­fort.

So yeah, that’s it :-)

...

Read the original on jonathanwhiting.com »

7 169 shares, 11 trendiness

Scheme on WebAssembly — Spritely Institute

Hoot is a Spritely pro­ject for run­ning Scheme code on Wasm GC-capable web browsers, fea­tur­ing a Scheme to Wasm com­piler and a full-fea­tured Wasm tool­chain.

Hoot is built on Guile and has no ad­di­tional de­pen­den­cies. The tool­chain is self-con­tained and even fea­tures a Wasm in­ter­preter for test­ing Hoot bi­na­ries with­out leav­ing the Guile REPL.

...

Read the original on www.spritely.institute »

8 159 shares, 6 trendiness

How we made geo joins 400× faster with H3 indexes

…but at scale they can be­come the query that ru­ins your day.

Geospatial func­tions are ex­pen­sive, and they of­ten force a loop join that starts to feel qua­dratic as your ta­bles grow.

The core idea in this post is sim­ple: we’ll see how Floe au­to­mat­i­cally rewrites this kind of query and takes ad­van­tage of H3 in­dexes for dra­matic speedup.

A geo join is any join whose ON clause is a spa­tial pred­i­cate:

Why it hurts at scale

Modern data­bases make joins fast by turn­ing them into hash joins over keys. If you can hash-par­ti­tion both in­puts on the join key, each worker com­pares only its share in­stead of com­par­ing every­thing to every­thing. If the data is nicely dis­trib­uted, this de­creases the com­plex­ity from qua­dratic to lin­ear.

Spatial pred­i­cates don’t give you a clean join key. So you end up in a ter­ri­ble sit­u­a­tion:

you have to com­pare every value with each other (the qua­dratic com­plex­ity)

plus an ex­pen­sive pred­i­cate on each can­di­date pair

That’s the sit­u­a­tion we want to es­cape.

H3 (originally from Uber) par­ti­tions the Earth into a hi­er­ar­chy of mostly hexag­o­nal cells.

Two prop­er­ties mat­ter for us:

Hierarchical res­o­lu­tion: you choose a res­o­lu­tion from coarse to fine.

Compact keys: each cell is a BIGINT, so it be­haves like a nor­mal join key: hash­able, sortable, dis­trib­utable.

Most im­por­tantly, it lets us rep­re­sent a ge­og­ra­phy as a set of cell IDs that cov­ers it.

If two shapes in­ter­sect, then their H3 cover sets share at least one cell.

That gives us a path to rewrite do these shapes in­ter­sect?” into do these two sets over­lap?” which a data­base can ex­e­cute as a plain equi-join.

Cell cov­er­age is an ap­prox­i­ma­tion of the ex­act geom­e­try:

It’s OK to keep ex­tra can­di­dates (false pos­i­tives): they’ll be re­moved by the ex­act pred­i­cate.

It’s not OK to miss true matches (false neg­a­tives): if we drop them in the pre-fil­ter, no later step can re­cover them.

So we gen­er­ate cov­er­age so it over-ap­prox­i­mates the shape (the cov­er­age con­tains the shape).

Deduplicate can­di­dates (the same pair can match on mul­ti­ple cells)

Run the ex­act pred­i­cate on can­di­dates only

What the data­base gets for free”

WITH

a_­cells AS (

SELECT

a.id,

a.geo,

c.cell

FROM A a

JOIN h3_­cov­er­age(a.geo, /* res­o­lu­tion */ 3, /* full cover */ true) c

ON TRUE

b_­cells AS (

SELECT

b.id,

b.geo,

c.cell

FROM B b

JOIN h3_­cov­er­age(b.geo, 3, true) c

ON TRUE

can­di­dates AS (

SELECT DISTINCT

a_­cells.id AS a_id,

a_­cells.geo AS a_­geo,

b_­cells.id AS b_id,

b_­cells.geo AS b_­geo

FROM a_­cells

JOIN b_­cells USING (cell)

SELECT *

FROM can­di­dates

WHERE ST_Intersects(a_geo, b_­geo);

With this rewrite, the heavy work be­comes an equi-join on (cell):

It’s nat­u­rally dis­trib­utable → you can hash-par­ti­tion on cell across work­ers.

The ex­pen­sive pred­i­cate be­comes a cleanup step in­stead of the main event.

Three ques­tions read­ers al­ways ask

Isn’t that ap­prox­i­mate?” Yes — the H3 step is an ap­prox­i­ma­tion used as a pre-fil­ter. Correctness is pre­served by the fi­nal ex­act pred­i­cate recheck.

Won’t that cre­ate false pos­i­tives?” Yes, and that’s ex­pected. The goal is to re­duce the can­di­date set enough that ex­act checks be­come cheap.

How do I pick a res­o­lu­tion?” Resolution is the trade­off knob: higher res­o­lu­tion usu­ally re­duces false pos­i­tives but in­creases the num­ber of cells gen­er­ated per shape. (We’ll cover how to mea­sure and choose this in the Numbers sec­tion later.)

When a user en­ters a sim­ple query to join coun­tries with the cities they con­tain, the plan­ner au­to­mat­i­cally ap­plies the rewrite:

EXPLAIN ANALYZE SELECT * FROM world_c­ities JOIN coun­tries ON ST_Intersects(world_cities.geo, coun­tries.geo);

Planning time: 2.291 ms

rows_ac­tual node

142141 SELECT

142141 FILTER WHERE ST_INTERSECTS(MAX(MAX(world_cities.geo)), MAX(MAX(countries.geo)))

geo­join fil­tered rows ra­tio: 99.62%

199848 GROUP BY (countries.rowunique, world_c­ities.rowu­nique)

199848 DISTRIBUTE ON HASH(world_cities.rowunique),HASH(countries.rowunique))

199848 GROUP BY PARTIAL (countries.rowunique, world_c­ities.rowu­nique)

224075 INNER HASH JOIN ON (COALESCE(h3_coverage_geodesic.h3_coverage_geodesic , $1 , const ) = COALESCE(h3_coverage_geodesic.h3_coverage_geodesic , $0 , const ) )

147043 |-DISTRIBUTE ON HASH(COALESCE(h3_coverage_geodesic.h3_coverage_geodesic , $0 , const ) )

147043 | LEFT OUTER FUNCTION JOIN H3_COVERAGE_GEODESIC(world_cities.geo, 3, t, t) ON true

147043 | SCAN world_c­ities

17223 |-BUILD HASH

17223 DISTRIBUTE ON HASH(COALESCE(h3_coverage_geodesic.h3_coverage_geodesic , $1 , const ) )

17223 LEFT OUTER FUNCTION JOIN H3_COVERAGE_GEODESIC(countries.geo, 3, t, t) ON true

256 SCAN coun­tries

142141 rows re­turned

Read: 16.92MiB, Distributed: 5.85GiB, Network: 8.00GiB

Database: yel­low­brick­_test_utf8

Execution time: 1220.118 ms, End time: 2025-12-16 14:00:50

Without the rewrite, the join would face ~`256 * 147043 = 37.6 mil­lion` coun­try×city pairs.

Instead, we’re do­ing 199848 calls to ST_Intersects, of which we keep 142141 pairs, a 99.6% re­duc­tion.

A pos­si­ble ap­proach is to ma­te­ri­al­ize an in­dex table (row_id → list of H3 cells) and main­tain it. This avoids the some­what ex­pen­sive step of com­put­ing H3 in­dexes.

We chose a dif­fer­ent route: com­pute cov­er­age at query time as part of the rewrite

Works over views, CTEs and sub­queries, not just base ta­bles.

This makes it easy to play with data clean­ing di­rectly in the query:

with cleaned_c­ities as

(select dis­tinct st_re­du­ce­pre­ci­sion(geo, 100) geo from world_c­ities) — Dedup cities that are less than 100 me­ters apart

se­lect count(*) from coun­tries join cleaned_c­ities on st_in­ter­sects(coun­tries.geo, cleaned_c­ities.geo);

Let’s look at some num­bers.

We’ll use a join be­tween 256 poly­gons rep­re­sent­ing coun­tries and points rep­re­sent­ing world cities:

In this dataset, coun­tries.geo is a poly­gon or mul­ti­poly­gon with 418 ver­tices on av­er­age.

We ran these tests on a clus­ter with 15 work­ers, each with a Xeon E5-2695 (16 cores @ 2.10GHz) and 1 TB of mem­ory.

First, let’s look at the ef­fect of H3 res­o­lu­tion.

Each time we in­crease the res­o­lu­tion by 1, the av­er­age size of a cell de­creases by ~6×.

Baseline is the time the query takes with­out H3 in­dex­ing. (459 sec­onds)

GeoJoin is the time the query takes with the rewrite.

Increasing it too much makes in­dex­ing and the (cell) join too ex­pen­sive.

At best, at res­o­lu­tion 3, the geo join takes 1.17 sec­onds — a 400× im­prove­ment.

...

Read the original on floedb.ai »

9 141 shares, 15 trendiness

StrongDM Software Factory

We built a Software Factory: non-in­ter­ac­tive de­vel­op­ment where specs + sce­nar­ios drive agents that write code, run har­nesses, and con­verge with­out hu­man re­view.

The nar­ra­tive form is in­cluded be­low. If you’d pre­fer to work from first prin­ci­ples, I of­fer a few con­straints & guide­lines that, ap­plied it­er­a­tively, will ac­cel­er­ate any team to­ward the same in­tu­itions, con­vic­tions1, and ul­ti­mately a fac­to­ry2 of your own. In kōan or mantra form:

* Why am I do­ing this? (implied: the model should be do­ing this in­stead)

* Code must not be writ­ten by hu­mans

* Code must not be re­viewed by hu­mans

* If you haven’t spent at least $1,000 on to­kens to­day per hu­man en­gi­neer, your soft­ware fac­tory has room for im­prove­ment

On July 14th, 2025, Jay Taylor and Navan Chauhan joined me (Justin McCarthy, co-founder, CTO) in found­ing the StrongDM AI team.

The cat­a­lyst was a tran­si­tion ob­served in late 2024: with the sec­ond re­vi­sion of Claude 3.5 (October 2024), long-hori­zon agen­tic cod­ing work­flows be­gan to com­pound cor­rect­ness rather than er­ror.

By December of 2024, the mod­el’s long-hori­zon cod­ing per­for­mance was un­mis­tak­able via Cursor’s YOLO mode.

Prior to this model im­prove­ment, it­er­a­tive ap­pli­ca­tion of LLMs to cod­ing tasks would ac­cu­mu­late er­rors of all imag­in­able va­ri­eties (misunderstandings, hal­lu­ci­na­tions, syn­tax, ver­sion DRY vi­o­la­tions, li­brary in­com­pat­i­bil­ity, etc). The app or prod­uct would de­cay and ul­ti­mately collapse”: death by a thou­sand cuts, etc.

Together with YOLO mode, the up­dated model from Anthropic pro­vided the first glim­mer of what we now re­fer to in­ter­nally as non-in­ter­ac­tive de­vel­op­ment or grown soft­ware.

In the first hour of the first day of our AI team, we es­tab­lished a char­ter which set us on a path to­ward a se­ries of find­ings (which we re­fer to as our unlocks”). In ret­ro­spect, the most im­por­tant line in the char­ter doc­u­ment was the fol­low­ing:

Initially it was just a hunch. An ex­per­i­ment. How far could we get, with­out writ­ing any code by hand?

Not very far! At least: not very far, un­til we added tests. However, the agent, ob­sessed with the im­me­di­ate task, soon be­gan to take short­cuts: re­turn true is a great way to pass nar­rowly writ­ten tests, but prob­a­bly won’t gen­er­al­ize to the soft­ware you want.

Tests were not enough. How about in­te­gra­tion tests? Regression tests? End-to-end tests? Behavior tests?

One re­cur­ring theme of the agen­tic mo­ment: we need new lan­guage. For ex­am­ple, the word test” has proven in­suf­fi­cient and am­bigu­ous. A test, stored in the code­base, can be lazily rewrit­ten to match the code. The code could be rewrit­ten to triv­ially pass the test.

We re­pur­posed the word sce­nario to rep­re­sent an end-to-end user story”, of­ten stored out­side the code­base (similar to a holdout” set in model train­ing), which could be in­tu­itively un­der­stood and flex­i­bly val­i­dated by an LLM.

Because much of the soft­ware we grow it­self has an agen­tic com­po­nent, we tran­si­tioned from boolean de­f­i­n­i­tions of suc­cess (“the test suite is green”) to a prob­a­bilis­tic and em­pir­i­cal one. We use the term sat­is­fac­tion to quan­tify this val­i­da­tion: of all the ob­served tra­jec­to­ries through all the sce­nar­ios, what frac­tion of them likely sat­isfy the user?

In pre­vi­ous regimes, a team might rely on in­te­gra­tion tests, re­gres­sion tests, UI au­toma­tion to an­swer is it work­ing?”

We no­ticed two lim­i­ta­tions of pre­vi­ously re­li­able tech­niques:

Tests are too rigid - we were cod­ing with agents, but we’re also build­ing with LLMs and agent loops as de­sign prim­i­tives; eval­u­at­ing suc­cess of­ten re­quired LLM-as-judgeTests can be re­ward hacked - we needed val­i­da­tion that was less vul­ner­a­ble to the model cheat­ing

The Digital Twin Universe is our an­swer: be­hav­ioral clones of the third-party ser­vices our soft­ware de­pends on. We built twins of Okta, Jira, Slack, Google Docs, Google Drive, and Google Sheets, repli­cat­ing their APIs, edge cases, and ob­serv­able be­hav­iors.

With the DTU, we can val­i­date at vol­umes and rates far ex­ceed­ing pro­duc­tion lim­its. We can test fail­ure modes that would be dan­ger­ous or im­pos­si­ble against live ser­vices. We can run thou­sands of sce­nar­ios per hour with­out hit­ting rate lim­its, trig­ger­ing abuse de­tec­tion, or ac­cu­mu­lat­ing API costs.

Our suc­cess with DTU il­lus­trates one of the many ways in which the Agentic Moment has pro­foundly changed the eco­nom­ics of soft­ware. Creating a high fi­delity clone of a sig­nif­i­cant SaaS ap­pli­ca­tion was al­ways pos­si­ble, but never eco­nom­i­cally fea­si­ble. Generations of en­gi­neers may have wanted a full in-mem­ory replica of their CRM to test against, but self-cen­sored the pro­posal to build it. They did­n’t even bring it to their man­ager, be­cause they knew the an­swer would be no.

Those of us build­ing soft­ware fac­to­ries must prac­tice a de­lib­er­ate naivete: find­ing and re­mov­ing the habits, con­ven­tions, and con­straints of Software 1.0. The DTU is our proof that what was un­think­able six months ago is now rou­tine.

* Principles: what we be­lieve is true about build­ing soft­ware with agents

* Products: tools we use daily and be­lieve oth­ers will ben­e­fit from

Thank you for read­ing. We wish you the best of luck con­struct­ing your own Software Factory.

...

Read the original on factory.strongdm.ai »

10 138 shares, 7 trendiness

Unseen Footage of Atari Battlezone Cabinet Production

Note: I’ve seen some on­line chat­ter about the pos­si­bil­ity that the footage shared in this post could be AI gen­er­ated (which is pretty de­press­ing, but here we are I sup­pose). I just wanted to clar­ify that it is not. It would be pretty daft of me to know­ingly post AI gen­er­ated footage on a blog that I’ve worked hard to keep on the up and up. The footage was cap­tured by a CBS news team, I as­sume to use as B-roll in a news seg­ment. The same reel fol­lowed up with an in­ter­view of a se­nior Atari em­ployee (keep an eye out for that in a fu­ture post). Same goes for the im­ages — they’ve been around for a few years in one for­mat or an­other, but clearly were taken at around the same time. I haven’t quoted sources, be­cause its al­most im­pos­si­ble to know where this stuff orig­i­nated, or if there’s any ac­tual ownage” af­ter all this time. I agree, the footage is re­mark­ably clear — the only post-edit­ing I did was a lit­tle up­scal­ing on ex­port from the edit­ing soft­ware I used to clip out some ir­rel­e­vant parts. Hope this clar­i­fies — en­joy!

Well, its been a hot minute since I’ve up­dated the blog. Life de­cided that it had other plans for me over the past 18 months or so.

The good news though, dear reader, is that we are back and I have lots in store for 2026!

So let’s kick things off the right way here. I have some in­cred­i­ble and pre­vi­ously un­seen footage of Battlezone cab­i­nets be­ing built at Atari from late sum­mer/​early fall 1980.

There’s some­thing end­lessly fas­ci­nat­ing about watch­ing a clas­sic Atari ti­tle come to­gether — not so much the de­sign doc­u­ments or the mar­ket­ing ma­te­ri­als, but the phys­i­cal act of build­ing the thing. Battlezone is one of those games where the de­vel­op­ment story and the cab­i­net it­self are so in­ter­twined that it’s hard to sep­a­rate the two.

Ed Rotberg’s work on the game is well doc­u­mented: a vec­tor‑dri­ven tank sim­u­la­tion that pushed Atari’s hard­ware and de­sign phi­los­o­phy into new ter­ri­tory. Rotberg was able to make a first‑per­son tank sim­u­la­tion at a time when the hard­ware barely wanted to co­op­er­ate.

Rotberg pushed Atari’s vec­tor tech­nol­ogy harder than any­one had be­fore, adapt­ing lessons from ear­lier games like Lunar Lander and Asteroids but steer­ing them into en­tirely new ter­ri­tory. He fought for a unique con­trol scheme that felt weighty and de­lib­er­ate, in­sisted on a vi­sual style that con­veyed depth and mo­tion through noth­ing but glow­ing vec­tors, and worked closely with the in­dus­trial de­sign team to en­sure the periscope‑style viewfinder was­n’t just a gim­mick but an in­te­gral part of the ex­pe­ri­ence.

The re­sult was a game that felt im­pos­si­bly im­mer­sive for 1980 — a tech­ni­cal gam­ble that only came to­gether be­cause Rotberg was will­ing to chal­lenge both the hard­ware and the ex­pec­ta­tions of what an ar­cade ma­chine could be.

The cab­i­net it­self, was its own en­gi­neer­ing chal­lenge. The dis­tinc­tive periscope viewfinder was­n’t just a styl­is­tic ad­di­tion — it was a de­lib­er­ate at­tempt to im­merse the player in a way raster games of the era sim­ply could­n’t match.

The in­dus­trial de­sign team had to fig­ure out how to make that idea man­u­fac­turable at scale, and the re­sult is one of the most recog­nis­able cab­i­nets of the golden age.

Mike Querio, one of the in­dus­trial de­sign­ers who worked on the cab­i­net’s de­sign had the fol­low­ing to say when I asked him about Battlezone:

There were some who did not like my periscope vi­sion de­sign. In fact my orig­i­nal de­sign did not even in­clude the acrylic win­dows on ei­ther side. The pro­ject man­ager, Morgan Hoff and oth­ers wanted them added so I mod­i­fied my plas­tic bezel de­sign. I de­signed a step to ac­com­mo­date shorter play­ers and made it re­mov­able to re­duce the ship­ping size of the cab­i­net. It stored ver­ti­cally in­side the cab­i­net.

The video I’m shar­ing to­day comes from in­side Atari’s Coin-Op Manufacturing Facility at Sunnyvale, California, and al­though there’s no nar­ra­tion, it does­n’t need any. The footage speaks for it­self.

What you see is the real, day‑to‑day pro­duc­tion process be­hind Battlezone cab­i­nets. The footage shows the later stages of the as­sem­bly line, the fin­ish­ing touches, and pack­ing and ship­ping. It’s a rare look at how these ma­chines were ac­tu­ally built.

Some 13,000 Battlezone up­rights rolled off of Atari’s pro­duc­tion lines dur­ing the pro­duc­tion sched­ule that lasted from August 1980 to March 1981.

One of the first things that jumps out at me, is just how flu­idly the work­ers are able to move the cab­i­nets around. Anyone who’s ever tried to shift a full‑size Atari cab on their own knows they’re not ex­actly feath­er­weight. But in the fac­tory en­vi­ron­ment, you see op­er­a­tors slid­ing them across the floor, piv­ot­ing them into po­si­tion, and lin­ing them up with a kind of ca­sual con­fi­dence that only comes from do­ing it hun­dreds of times a week.

The real high­light comes at around the 3 minute 50 sec­ond mark. If you’ve ever won­dered how Atari man­aged to ship these things in vol­ume with­out de­stroy­ing half of them in tran­sit, this is the bit you’ll want to pay at­ten­tion to. Two work­ers ap­proach a fin­ished cab­i­net with large in­dus­trial suc­tion cups — one on each side. They at­tach them and then, al­most ef­fort­lessly, lift the en­tire cab­i­net off the ground. No straps, no dol­lies, no awk­ward tilt­ing. They swing the cab­i­net over to a wait­ing pal­let, lower it into place, and re­lease the cups.

Once the cab­i­net is on the pal­let, the pack­ing process be­gins. Cardboard spac­ers, pro­tec­tive wrap, and fi­nally the outer car­ton — all de­signed to keep the ma­chine safe on its jour­ney to ar­cades around the world.

Anyway — enough chat from me — en­joy the video be­low:

Battlezone shared the pro­duc­tion line with Missile Command, it­self re­leased at the same time — sadly, we don’t see any MC cab­i­nets in the back­ground in the footage which is a shame. But you can see the two cab­i­nets in this im­age:

What I love most about this video is that it cap­tures a mo­ment in time when Atari was fir­ing on all cylin­ders. Battlezone was­n’t just an­other ar­cade cab­i­net re­lease — it was a state­ment piece. A game that blended cut­ting‑edge hard­ware with bold in­dus­trial de­sign, and a cab­i­net that de­manded at­ten­tion on the ar­cade floor. Seeing it built by hand, re­minds us that these ma­chines weren’t ab­stract prod­ucts. They were phys­i­cal ob­jects, crafted by teams of peo­ple at the cut­ting edge of in­dus­trial and tech­ni­cal de­sign.

Anyway — I ap­pre­ci­ate your pa­tience here. Its good to be back and up­dat­ing Arcade Blogger again. I have more to come in the weeks ahead.

If you like what you see, please share this ar­ti­cle on your so­cials!

...

Read the original on arcadeblogger.com »

To add this web app to your iOS home screen tap the share button and select "Add to the Home Screen".

10HN is also available as an iOS App

If you visit 10HN only rarely, check out the the best articles from the past week.

If you like 10HN please leave feedback and share

Visit pancik.com for more.