The first part in the creation of an "On this Day..." post is automated: I use pwr.news to, for a given day, see the top news items that were most active and discussed about on reddit and twitter. If you want to find out how exactly this list is compiled, have a look at the infographic on the right.
That's it! Reporting on Ethereum's history a few minutes at a time.
Your favourite app just lost half of its weight, mainly by better packaging and dropping dependencies on old libraries. In other words: faster page loads!
|Fresh page load:||1,9MB → 0.9MB|
|Asset data updates (every 5 minutes):||19kB → 3,8kB|
Use the recently added calendar to jump to specific days, months or years.
Also, dates are now part of the app's url, so you can link to dates or time ranges:
They're here, the MNPI: Much Needed Performance Improvements, or, what some Englishmen like to pronounce as "the SPEEEEEEED".
While developing pwr.news, I have noticed the app is susceptible to a plucky portion of induced demand:
every time I'm proud to say the interface has just become a lot faster or more easily navigatable, the first obvious thing to note is that the back-end can't follow.
Last time's improvements were no exception: zooming out quickly meant you had to wait for ages for news to appear. The culprit on the back-end was the calculation of item scores and activity. Those scores are dependent on all discussions on a certain item, so while filling charts with, let's say 30 items, still thousands of items needed to be fetched from our database.
The theoretical fix for the back-end was easy: use cached scores instead of fetching whole discussion trees and only recalculating things when needed. However, upon implementation, it introduced a lot more edge case bugs than expected.
Going from "stable, but slow", to "fast, but buggy" was easy, but the trenches of development hell needed to be crossed to end up at "stable and fast!"