Ahhh, I think the author mixed up two values here. That value seems to actually be the average over the past 3 months.
const incidents = e.detail.incidents;
// ...snip...
const now = new Date();
const threeMonthsAgo = new Date(now);
threeMonthsAgo.setMonth(threeMonthsAgo.getMonth() - 3);
// ...snip...
var currentFreq = recentIncidents.length / 3; // <- We out here, smoking these guns with our homeboy Claude
// ...snip...
var earliest = null;
for (var j = 0; j < incidents.length; j++) {
var dd = new Date(incidents[j].started_at); // <- eventually incidents[j].started_at is "2016-03-01T07:07:37.000Z"
if (!earliest || dd < earliest) earliest = dd;
}
// ...snip...
document.getElementById('n-since').textContent = earliest
? earliest.toLocaleDateString('en-US', { month: 'long', year: 'numeric' })
: '?';
document.getElementById('n-rate').textContent = Math.round(currentFreq * 10) / 10;
#n-since is going to be either march or feburary. It'll change depending on your timezone because JS's Date object always shifts the date around to match the same instant but in the system's timezone.
#n-rate has nothing to do with the #n-since month, it's just the last trailing 3 months. And even then, it's sort of underbaked? It's moving the date back by 3 calendar months not taking into account differing numbers of days, so it'll under-report short months.
I wouldn't trust the stats here.
Edit: whoops, author updated the template while I was writing this! It now says "Over the last 3 months", though that's still calendar months.
Not sure whether it has been updated since your comment, but the sentence now reads:
GitHub has had 1125 incidents since March 2016. Over the last 3 months, they've averaged 24 incidents per month
edit: although they also have 1.2 days of downtime (in a day) for their 'worst days' of downtime table, which suggests some auto number crunching is not working as expected.
Yes I tweaked it! The number and copy were mismatched and are no longer!
That worst day is likely an overlapping incidents accounting issue; I tried to account for overlapping incidents in another view but probably failed to port it over there.
having worked at the intersection of CAD/CAM automation & actual factories, I'm disappointed with the lack of real information on what their product actually does.
Going from bits to atoms is _hard_ for a ton of reasons, and their example prompt "Prepare this for manufacturing" is a huge red flag IMO. That said, I wish them luck, we need fresh blood in this slow moving industry.
Hey jeremyherman at xfgr.ai we don't pretend about anything, WYSIWYG, and no LLM, only math.
You asked me 10 months ago when we would have something to look at, give our MVP a shot!
Working on seed round now, to train a POC of the actual foundation model I really intend to scale.
I was about to write this. So refreshing, after having looked at hundreds of semi or completely AI-written articles. Even the news look like sterile Claude now. This is so human.
Gemini 2.5 Flash-Lite has been my go to for cheap document processing at scale (especially with 50% off batch mode), but they are really boiling the frog with pricing increases with each version:
gemini-2.5-flash-lite: $0.10 input / $0.40 output
gemini-3.1-flash-lite: $0.25 input / $1.50 output
gemini-3.5-flash-lite: $0.30 input / $2.50 output (a 6.25x increase over 2.5!)
Now watch them deprecate Gemini 2.5 Flash-Lite in the coming months...
After seeing so many *subscription based* transcription apps all wrapping *open source models*, finding Handy was a real delight and I'm happy to see the author keep on building!
Comic Chat has a special place in my heart because it inspired my first startup back in 2008, a comic creation web app called Chogger. The site grew to 30K monthly users, mostly K-12 educators who wanted to give their students a fun way to write stories.
The comic creator app itself was adobe flex (flash), actionscript 3.0 (like a typed version of javascript), and I remember spending so many hours getting the balloon tail dragging behavior just right...
> This machine specs reminds me of how awful '90s laptop screens, based on a passive matrix, were. Definitely something I don't miss from that era.
While the 1991 Apple PowerBook 100 did have a passive matrix display, the machine it was based on, the Macintosh Portable from 1989, had a crisp active matrix running at 640×400 (even higher resolution than the compact Macintosh desktops with 512×342).
Interestingly Apple tasked Sony with designing the PowerBook 100 by taking the Macintosh Portable and slimming it down as much as possible. They shaved over 10lbs by moving away from the lead acid battery, dropping the floppy drive, and moving to a passive matrix display.
This is what I do mainly. I spend more time designing the solution, iterating by hand when it matters and anything that should be automated, let it be.
Yeah, one developer I recently had a chat with on Chatto (recently featured here on Hacker News) actually wrote the core code and project layout by hand before invoking the LLM and found that he had to hand-hold it a lot less because he had given it solid foundation to work from. That design stage you speak of there and the "iterating by hand when it matters" is a big part of what really helps the models do their part of the job a lot better. That's what the "vibe coders" (and often their bosses) don't seem to understand (yet), but they'll figure it out eventually I'm sure. Or maybe not. I guess we'll have to wait and see how it all turns out. In the meantime, we can have fun playing with the new tools they've given us. ;)
> In large-scale combat operations, victory will depend less on which force fields the most advanced weapons and more on which can sustain combat power under persistent attack.
"force fields" had me reading that sentence entirely wrong
1125 incidents / 126 months ≈ 8.9 incidents per month, not 24
still terrible, but why such an obvious error in the first sentence...