Seven coun­tries now gen­er­ate nearly all of their elec­tric­ity from re­new­able en­ergy sources, ac­cord­ing to newly com­piled fig­ures.

Albania, Bhutan, Nepal, Paraguay, Iceland, Ethiopia and the Democratic Republic of Congo pro­duced more than 99.7 per cent of the elec­tric­ity they con­sumed us­ing ge­ot­her­mal, hy­dro, so­lar or wind power.

Data from the International Energy Agency (IEA) and International Renewable Energy Agency (IRENA) also re­vealed that a fur­ther 40 coun­tries gen­er­ated at least 50 per cent of the elec­tric­ity they con­sumed from re­new­able en­ergy tech­nolo­gies in 2021 and 2022 — in­clud­ing 11 European coun­tries.

“We don’t need mir­a­cle tech­nolo­gies,” said Stanford University Professor Mark Jacobson, who pub­lished the data.

“We need to stop emis­sions by elec­tri­fy­ing every­thing and pro­vid­ing the elec­tric­ity with Wind, Water and Solar (WWS), which in­cludes on­shore wind, so­lar pho­to­voltaics, con­cen­trated so­lar power, ge­ot­her­mal elec­tric­ity, small hy­dro­elec­tric­ity, and large hy­dro­elec­tric­ity.”

Professor Jacobson also noted that other coun­tries like Germany were also ca­pa­ble of run­ning off 100 per cent re­new­able-gen­er­ated elec­tric­ity for short pe­ri­ods of time.

Figures re­leased by the IEA in January show that the UK gen­er­ated 41.5 per cent of its elec­tric­ity from re­new­able sources in 2022 — up 10.5 per cent from the year be­fore.

In Scotland, re­new­able en­ergy tech­nolo­gies gen­er­ated the equiv­a­lent of 113 per cent of the coun­try’s over­all elec­tric­ity con­sump­tion in 2022.

“These record-break­ing fig­ures are a ma­jor mile­stone on Scotland’s jour­ney to net-zero, clearly demon­strat­ing the enor­mous po­ten­tial of our world-class re­new­able en­ergy re­sources,” Claire Mack, chief ex­ec­u­tive of Scottish Renewables, said at the time.

While Scotland’s elec­tric­ity gen­er­a­tion was dom­i­nated by wind power, re­searchers pre­dict that so­lar will come to dom­i­nate global elec­tric­ity sup­plies over the com­ing decades.

There has been sig­nif­i­cant progress in re­cent years with im­prov­ing ef­fi­ciency rates for so­lar cells, pri­mar­ily boosted by the so-called ‘miracle ma­te­ri­al’ per­ovskite.

Commercial costs have also fallen, which led sci­en­tists at the University of Exeter and University College London to claim last year that so­lar en­ergy has reached an “irreversible tip­ping point” that will see it be­come the world’s main source of en­ergy by 2050.

Their 2023 pa­per, pub­lished in the jour­nal Nature Communications, found that tech­no­log­i­cal and eco­nomic ad­vances meant the tran­si­tion to clean en­ergy is not just reach­able, but in­evitable.

“Due to tech­no­log­i­cal tra­jec­to­ries set in mo­tion by past pol­icy, a global ir­re­versible so­lar tip­ping point may have passed where so­lar en­ergy grad­u­ally comes to dom­i­nate global elec­tric­ity mar­kets, with­out any fur­ther cli­mate poli­cies,” the re­searchers wrote in the study.

“Solar en­ergy is the most widely avail­able en­ergy re­source on Earth, and its eco­nomic at­trac­tive­ness is im­prov­ing fast in a cy­cle of in­creas­ing in­vest­ments.”

In 2020, I started mak­ing my own soft drinks, in­clud­ing a sugar-free, caf­feine-free cola! If you’re just look­ing for the cur­rent recipes, you can find them on GitHub. They were in­spired by recipes like Open Cola and Cube Cola.

Otherwise, read on for “log book”-style in­struc­tions and pic­tures of my first at­tempts, which have been adapted from this Mastodon thread.

We start by mak­ing a fla­vor emul­sion from es­sen­tial oils! These oils are ex­tremely strong, and can cause skin ir­ri­ta­tions, so if you want to be safe, wear la­tex gloves for this step!

We also need su­per small quan­ti­ties. In this at­tempt, I’m aim­ing for:

There! In to­tal, we have about 2 ml of es­sen­tial oil. This will lend fla­vor to about 9 L of cola!

But oils don’t dis­solve in wa­ter, right? They would just float on the sur­face!

So what we’ll add next is gum ara­bic, a nat­ural emul­si­fier, that will help the oil form tiny, tiny droplets that stay dis­persed in wa­ter!

Combine 2 g of gum ara­bic, 4 ml wa­ter, and our oil mix­ture with a hand mixer. Keep mix­ing un­til it emul­si­fies, it will take on a milky brown color and the oily phase will dis­ap­pear. This took me about 5 min­utes.

Next, we add: 40 ml of caramel color, which will give the cola its dark ap­pear­ance.

As well as 5 g cit­ric acid, and an ad­di­tional 10 ml of wa­ter. You can also add caf­feine at this point, but one of the main mo­ti­va­tions for me to make my own cola is to have cola with­out caf­feine (it gives me headaches).

Stop mix­ing when it starts smil­ing at you! :D This is our fin­ished cola con­cen­trate. It smells de­li­cious!

Other recipes would now in­te­grate this into sugar syrup made from 1 kg of sugar, but I want to try a vari­a­tion us­ing ar­ti­fi­cial sweet­en­ers, for di­et­ing rea­sons. This is a com­bi­na­tion of sodium cy­cla­mate and sac­cha­rin, which is pretty com­mon in Germany. I’ll use 70 ml.

This gives us about 120 ml of the fin­ished cola syrup! \o/ I’ve been fol­low­ing the Cube-Cola recipe.

Because this is still a very con­cen­trated so­lu­tion and hard to han­dle, I’m di­lut­ing it down to 1 L. In the­ory, this should give a nice cola when di­luted fur­ther in a ra­tio of 1:8. First taste test com­ing up!

It’s good! It’s re­ally good! The sweet­ness is just right for me, and the oil blend tastes nice and cola-y! :)

I like my drinks re­ally sour, so I might add an­other… 10 g of cit­ric acid to this batch. There is a slightly bit­ter af­ter­taste, which I at­tribute to the ar­ti­fi­cial sweet­ener I’m us­ing.

I might also tweak the oil ra­tios to ac­cen­tu­ate the cit­rus fla­vors a bit more in the next batch. And I thought this would be too much food col­or­ing, but it seems pretty per­fect!

What I’d be re­ally ex­cited to try is mak­ing other fla­vors: Orange soda! Cherry soda! Almond & apri­cot soda!

Open Soda (Note: site is no longer on­line as of 2026…) has two pretty weird ones (including a bub­ble gum soda?!), but that’s pretty much all I found. There still seems to be po­ten­tial for re­verse en­gi­neer­ing! :)

And here are two more re­sources I found while prepar­ing my in­gre­di­ents to­day: Jan Krüger’s blog post about tweak­ing cola recipes and Richard Grove’s Notes on Making Cola, which go deeper into food chem­istry!

Made a sec­ond batch of cola syrup with­out caramel color. It’s much weirder to drink than I ex­pected.

I also switched to su­cralose as a sweet­ener, hop­ing that it would have less af­ter­taste. Instead of 1000 g sugar in the orig­i­nal recipe, I used 1.6 g su­cralose, which is ridicu­lous, but it’s still too sweet for my taste. :O

And I made a tool up­grade! It’s im­por­tant to get these small quan­ti­ties right…

This week’s batch: blood or­ange + al­mond + lime (in a 2:1:1 ra­tio), plus as much or­ange food col­or­ing as I dared to put in! :D

I cut the amount of su­cralose in half — still a bit too sweet for my taste. Had to com­pletely guess the oil ra­tios, but I’m happy with how it turned out! My whole apart­ment smells like marzi­pan now.

This time, when I did the mix­ing in a big plas­tic bowl, I no­ticed some float­ing stuff on the con­cen­trate, which I as­sume are tiny plas­tic shav­ings pro­duced by the hand mixer? I fil­tered them out, and might switch to glass or metal con­tain­ers.

In to­day’s cola batch, I re­duced the amount of su­cralose fur­ther to 0.4 g, added 0.07 g vanillin, as well as a bit more cas­sia oil. Good stuff! I call it “Syntez-Cola”, be­cause I com­bined ideas from Cube-Cola and Jan Krüger’s recipe! :)

… this is the point where I should start a blog post, and a Git repo with ver­sion num­bers and a changelog, I guess. :P (Edit 2026: Here you go!)

I found de­caf Coca-Cola in a su­per­mar­ket last week, and could do a di­rect taste com­par­i­son. At this point, I pre­fer my cola by a large mar­gin! Coca-Cola tasted bland, like molten cola pop­si­cles. It had an in­ter­est­ing dry­ness to it, though, which I’m not sure how to repli­cate.

Made a sim­ple or­ange soda to­day, re­ally happy with how it turned out! I put the recipe here, along with my mod­i­fied cola recipe, and the al­mond + blood or­ange drink I in­vented!

blinry al­mond 0.1.1 con­tains less al­mond oil, to high­lights the cit­rus fla­vors a bit more. Find the up­dated recipe here.

One of these two bot­tles is a ver­sion with sugar in­stead of su­cralose. 400 g of sugar seem to be a good re­place­ment for 0.6 g su­cralose. Curious to see whether peo­ple will be able to taste the dif­fer­ence! :) (Edit 2026: They to­tally could!)

blinry or­ange 0.1.1, now with 14% more or­ange! :D Recipe here.

Since these early ex­per­i­ments, I made a hand­ful batches of these recipes with­out mod­i­fi­ca­tion. I still think they’re re­ally nice! Especially blinry or­ange is rather unique.

If you try them for your­self, I’d be happy about feed­back!

And I’m still think­ing what in­gre­di­ents might go into a DIY Mountain Dew, or a DIY Fassbrause…

You can add your com­ment to this post in the Fediverse! Alternatively, drop me a mail at mil@blinry.org.

This is a heav­ily in­ter­ac­tive web ap­pli­ca­tion, and JavaScript is re­quired. Simple HTML in­ter­faces are pos­si­ble, but that is not what this is.

Learn more about Bluesky at bsky.so­cial and at­proto.com. A state­ment re­gard­ing the re­moval of DDLC from the Google Play Store:

In his clas­sic

Programming Perl — affectionately known to a gen­er­a­tion of tech­nol­o­gists as “the Camel Book” — Larry Wall fa­mously wrote of the three virtues of a pro­gram­mer as lazi­ness, im­pa­tience, and hubris:

If we’re go­ing to talk about good soft­ware de­sign, we have to talk about Laziness, Impatience, and Hubris, the ba­sis of good soft­ware de­sign. We’ve all fallen into the trap of us­ing cut-and-paste when we should have de­fined a higher-level ab­strac­tion, if only just a loop or sub­rou­tine. To be sure, some folks have gone to the op­po­site ex­treme of defin­ing ever-grow­ing mounds of higher level ab­strac­tions when they should have used cut-and-paste. Generally, though, most of us need to think about us­ing more ab­strac­tion rather than less.

Of these virtues, I have al­ways found lazi­ness to be the most pro­found: packed within its tongue-in-cheek self-dep­re­ca­tion is a com­men­tary on not just the need for ab­strac­tion, but the aes­thet­ics of it. Laziness dri­ves us to make the sys­tem as sim­ple as pos­si­ble (but no sim­pler!) — to de­velop the pow­er­ful ab­strac­tions that then al­low us to do much more, much more eas­ily.

Of course, the im­plicit wink here is that it takes a lot of work to be lazy: when pro­gram­mers are en­gaged in the seem­ing lazi­ness of

ham­mock-dri­ven de­vel­op­ment, we are in fact turn­ing the prob­lem over and over in our heads. We un­der­take the hard in­tel­lec­tual work of de­vel­op­ing these ab­strac­tions in part be­cause we are op­ti­miz­ing the hy­po­thet­i­cal time of our fu­ture selves, even if at the ex­pense of our cur­rent one. When we get this cal­cu­lus right, it is glo­ri­ous, as the ab­strac­tion serves not just our­selves, but all who come af­ter us. That is, our lazi­ness serves to make soft­ware eas­ier to write, and sys­tems eas­ier to com­pose — to al­low more peo­ple to write more of it.

Ideally, you would want those that ben­e­fit from ab­strac­tions to pay the virtue of lazi­ness for­ward — to use their new-found power to them­selves la­bor on the ab­strac­tions they make. But a con­se­quence of the broad­en­ing of soft­ware cre­ation over the past two decades is it in­cludes more and more peo­ple who are un­likely to call them­selves pro­gram­mers — and for whom the virtue of lazi­ness would lose its in­tended mean­ing.

Worse, the ex­tra­or­di­nary pro­duc­tiv­ity al­lowed by mod­ern ab­strac­tions has given rise to an em­pha­sis on a kind of false in­dus­tri­ous­ness. Pejoratively, this was the

rise of the bro­gram­mer, with the virtue of ironic lazi­ness and ham­mock-dri­ven de­vel­op­ment dis­placed by

hus­tle porn about crush­ing code.

Onto this dry tin­der has struck the light­ning bolt of LLMs. Whatever one’s dis­po­si­tion is to soft­ware cre­ation, LLMs al­low that to be ap­plied with (much) greater force, so it should be of lit­tle sur­prise that LLMs have served as an­a­bolic steroids for the bro­gram­mer set.

Elated with their new-found bulk, they can’t seem to shut up about it. Take, for ex­am­ple, bro­gram­mer-of-note

Garry Tan, who has been par­tic­u­larly in­suf­fer­able about his LLM use, brag­ging about his rate of thirty-seven thou­sand

lines of code per day (and “still speed­ing up”):

If lazi­ness is a virtue of a pro­gram­mer, think­ing about soft­ware this way is clearly a vice. And like as­sess­ing lit­er­a­ture by the pound, its fal­lacy is clear even to novice pro­gram­mers.

As for the ar­ti­fact that Tan was build­ing with such fre­netic en­ergy, I was broadly ig­nor­ing it. Polish soft­ware en­gi­neer Gregorein, how­ever,

took it apart, and the re­sults are at once pre­dictable, hi­lar­i­ous and in­struc­tive: A sin­gle load of Tan’s “newsletter-blog-thingy” in­cluded mul­ti­ple test har­nesses (!), the Hello World Rails app (?!), a stow­away text ed­i­tor, and then eight dif­fer­ent vari­ants of the same logo — one of which with zero bytes.

The prob­lem here is­n’t these is­sues per se (which are all fix­able!), and it is­n’t even the be­lief that the method­ol­ogy that cre­ated them rep­re­sents the fu­ture of soft­ware en­gi­neer­ing (though that is cer­tainly an­noy­ing!).

The prob­lem is that LLMs in­her­ently lack the virtue of lazi­ness. Work costs noth­ing to an LLM. LLMs do not feel a need to op­ti­mize for their own (or any­one’s) fu­ture time, and will hap­pily dump more and more onto a lay­er­cake of garbage. Left unchecked, LLMs will make sys­tems larger, not bet­ter — ap­peal­ing to per­verse van­ity met­rics, per­haps, but at the cost of every­thing that mat­ters. As such, LLMs high­light how es­sen­tial our hu­man lazi­ness is: our fi­nite time forces us to de­velop crisp ab­strac­tions in part be­cause we don’t want to waste our (human!) time on the con­se­quences of clunky ones. The best en­gi­neer­ing is al­ways borne of con­straints, and the con­straint of our time places lim­its on the cog­ni­tive load of the sys­tem that we’re will­ing to ac­cept. This is what dri­ves us to make the sys­tem sim­pler, de­spite its es­sen­tial com­plex­ity. As I ex­panded on in my talk

The Complexity of Simplicity, this is a sig­nif­i­cant un­der­tak­ing — and we can­not ex­pect LLMs that do not op­er­ate un­der con­straints of time or load to un­der­take it of their own vo­li­tion.

This is not to say, of course, that LLMs won’t play an im­por­tant role in our fu­ture: they are an ex­tra­or­di­nary tool for soft­ware en­gi­neer­ing, but — as out­lined in our

guide­lines for LLM use at Oxide — they are but a tool. We can put them to use tack­ling the non-ironic (and non-vir­tu­ous!) as­pects of pro­gram­mer lazi­ness — help­ing us take on thorny prob­lems like tech­ni­cal debt —  or

use them to pro­mote our en­gi­neer­ing rigor, but it must be in ser­vice of our own vir­tu­ous lazi­ness: to yield a sim­pler, more pow­er­ful sys­tem that serves not just our­selves, but the gen­er­a­tions of soft­ware en­gi­neers to come af­ter us.

The ma­cOS Dock is built around apps, not win­dows. Multiple dis­plays and desk­tops make it hard to track what’s open where. bor­ing­Bar keeps win­dows or­ga­nized by desk­top, with in­stant pre­views, one-click desk­top switch­ing, and pinned apps within reach.

bor­ing­Bar also gives you a search­able app launcher, scroll-to-switch desk­tops, full win­dow ti­tles on chips, and a cleaner work­space when you hide the Dock. As a bonus, it makes ma­cOS feel more fa­mil­iar if you’ve just switched from Windows or Linux.

Shows only the win­dows on the ac­tive desk­top for that dis­play, so you stay fo­cused on what is in front of you.

Jump to any desk­top on the cur­rent dis­play with one click, and see how many win­dows are open on each one.

Search and launch apps from a sin­gle list, then open it in­stantly with a con­fig­urable global short­cut.

Hover a chip to pre­view win­dows be­fore switch­ing, so you can pick the right one faster.

Unread badges from ma­cOS ap­pear di­rectly on chips, so im­por­tant up­dates stay vis­i­ble.

When an app needs your at­ten­tion, its chip gives a sub­tle pulse so you no­tice it right away.

Scroll up or down on the bar to move be­tween desk­tops. Direction is con­fig­urable.

Choose small, medium, or large. Pick the size that suits you best.

Collapses mul­ti­ple win­dows into one chip, with a count badge.

Hide app name text on chips while keep­ing icons and win­dow count badges.

Show full win­dow ti­tles in chips, or just the app name for a cleaner look.

Keeps the Dock out of the way while you use bor­ing­Bar, then brings it back when you turn the fea­ture off.

Mirror bars across mul­ti­ple mon­i­tors, in­clud­ing se­tups where the sys­tem set­ting “Displays have sep­a­rate Spaces” is off.

Right-click the bar and choose Show Desktop, or click the rib­bon at the far right edge to re­veal the desk­top.

Right click on any app in the bar to pin them to the bar it­self or to the top of the ap­pli­ca­tion menu.

bor­ing­Bar re­quires two ma­cOS per­mis­sions. Accessibility is used to ob­serve and in­ter­act with win­dows, desk­tops, and apps on your be­half. Screen Recording is used solely to fetch win­dow thumb­nail pre­views and is not used for any­thing else. You can ver­ify this your­self: the pur­ple dot in Control Center only ap­pears when thumb­nails are be­ing fetched, and you will not see it from bor­ing­Bar at any other time.

Yes. You can down­load and try bor­ing­Bar free for 14 days with all fea­tures un­locked. A li­cense is re­quired to con­tinue us­ing it af­ter the trial.

Personal li­censes come in two fla­vors:

Perpetual — a one-time $40 pur­chase cov­er­ing 2 de­vices, with 2 years of sup­port and up­dates in­cluded. The soft­ware keeps work­ing af­ter that; you just won’t re­ceive fur­ther up­dates.

Yearly — a sub­scrip­tion start­ing at $7.99/year for 1 de­vice, with ad­di­tional de­vices at $2/year each, up to 5.

Business li­censes are billed an­nu­ally, start at 6 users, and use vol­ume pric­ing, so the per-user cost drops as your team grows:

For ex­am­ple, a 6-user busi­ness li­cense is $20.99/year, a 20-user li­cense is $69.99/year, and a 50-user li­cense is $144.99/year.

What is the dif­fer­ence be­tween a per­sonal and busi­ness li­cense?

Both li­censes give you ac­cess to the same fea­tures. A per­sonal li­cense is for in­di­vid­ual use and comes in two fla­vors: a one-time per­pet­ual pur­chase cov­er­ing 2 de­vices, or a yearly sub­scrip­tion cov­er­ing up to 5 de­vices. A busi­ness li­cense is an an­nual sub­scrip­tion in­tended for use within a com­pany or or­ga­ni­za­tion and in­cludes vol­ume pric­ing.

Can I use my li­cense on mul­ti­ple Macs?

Each li­cense seat is linked to one de­vice. A per­pet­ual per­sonal li­cense in­cludes 2 seats; a yearly per­sonal li­cense cov­ers 1 to 5 de­vices. For yearly per­sonal and busi­ness li­censes, make sure to pur­chase the ap­pro­pri­ate num­ber of seats up­front, as seats can­not be added to an ex­ist­ing li­cense. If you need more later, you can pur­chase a sep­a­rate li­cense. Multiple users on the same ma­chine share a sin­gle seat.

Personal li­cense hold­ers re­ceive an ac­ti­va­tion key by email af­ter pur­chase. Business li­cense hold­ers need to add each team mem­ber from the Business License Management page first. In the bor­ing­Bar app, that team mem­ber then en­ters their email ad­dress and re­ceives a one-time code to con­firm and ac­ti­vate their li­cense.

bor­ing­Bar can hide the Dock for you while it is run­ning, but it will still be vis­i­ble in Mission Control. When you turn the fea­ture off or quit the app, the Dock comes right back.

Enter the email ad­dress as­so­ci­ated with your busi­ness li­cense to sign in.

We sent a 6-digit code to

Enter the email ad­dress as­so­ci­ated with your per­sonal li­cense.

This web­site re­quires javascript to prop­erly func­tion. Consider ac­ti­vat­ing javascript to get ac­cess to all site func­tion­al­ity.

Oooooh boy. Let’s get this out of the way first. Email sucks.

Now to the how and the why. We’re builders. We love mak­ing tools to help de­sign­ers and de­vel­op­ers live a lit­tle bit eas­ier. We’re pretty good at it. Marketing, though? We do our best, but the truth is, we don’t like to bother peo­ple.

Like a lot of small soft­ware com­pa­nies, we use SendGrid to de­liver our emails. We try our best to fol­low email best prac­tices. We even have a 99% rep­u­ta­tion score in SendGrid. Gold star. A+ stu­dent.

Gmail, how­ever, did not get the memo.

Right be­fore we hit send on our an­nounce­ment emails for our new Build Awesome Kickstarter cam­paign, we took a deeper look at some of our re­cent email sends. Things had gone quiet. Not bounc­ing. Not throw­ing er­rors. Just… dis­ap­pear­ing into Gmail’s spam folder like a ’possum slip­ping into a vent.

In our re­cent crash course, here’s what we’ve learned about Gmail de­liv­er­abil­ity: it runs its own rep­u­ta­tion sys­tem that has ab­solutely noth­ing to do with any­one else’s opin­ion of you. If you don’t do cer­tain things “correctly” (meaning Gmail’s own de­f­i­n­i­tion), you get marked as spam.

Now, there are def­i­nitely folks who will choose to mark some of what we send as spam. And for them, rightly so. We get that. But this is not that. We’ve en­tered a black hole for Gmail de­liv­er­abil­ity. And since 90% (literally) of our email list goes to Gmail ad­dresses… the re­sults aren’t pretty. It looks like this has been hap­pen­ing to us for a while. We’re a small com­pany of just over 20 peo­ple, and can’t watch every­thing all the time. We’d rather be mak­ing you new icons. So some of you may have missed things we were gen­uinely ex­cited to share. That’s a big bum­mer.

But here’s the part that re­ally gets us. At our CORE, our in­stinct is to only email folks when we ac­tu­ally have some­thing fun to share. A big re­lease, some­thing we’re ex­cited about, news worth your time. That’d prob­a­bly be every cou­ple of months, if that. Respectful. Low noise. How we want to be treated. Like, gen­uinely, if we could, we would only very oc­ca­sion­ally send a big email blast to our cus­tomers.

Turns out, the email gods hate that. To keep a send­ing IP “warm” and main­tain de­liv­er­abil­ity, you’re ex­pected to send con­stantly. Like… all the time. Which means the sys­tem ac­tively pun­ishes com­pa­nies for re­spect­ing their cus­tomers’ in­boxes. It’s a gen­uine catch-22: send too many emails and your rep­u­ta­tion drops from com­plaints. Send too few and it drops from in­ac­tiv­ity. Try to do the right thing and you get pe­nal­ized ei­ther way. And. It. Is. Frustrating.

We’re work­ing to fix our is­sues by culling old ad­dresses, slow­ing our sends down, and mak­ing sure all of our i’s are dot­ted and t’s are crossed. It’s not a fast fix.

So if you haven’t heard from us re­cently… or if you’ve heard TOO MUCH from us re­cently, that’s why. We’re work­ing on it. And we’ve got a lot of good stuff to catch you up on. In the mean­time, please help spread the word about Build Awesome. It’s a gen­uinely cool prod­uct, and we hope you’ll like it. At the very least, watch the video.

See the Build Awesome Kickstarter

P. S. If you sus­pect you might’ve missed some emails from us, mind do­ing a quick fa­vor? In your email client, search for from:hello@m.fontawes­ome.com in:spam and click the lit­tle “Report Not Spam” but­ton. You’re awe­some.