The resolved bug list in particular is an integral part of the source code history, because it explains the motivation behind the shape of that code.

From my own experience, debugging often means digging into git blame and finding the issues associated with those commits. Having that metadata directly in a repo, not tied to any specific platform, always in sync, is nice.

There is a certain appeal to not depending on more tools, and there is something elegant about the bug list traveling with revisions, if they are closed when the bug is fixed. So at any point you could go backwards and see known bugs at the time.

This also applies to certain project management flows and statuses.

Right, there are advantages of your defect list riding right along with the code repository itself. The history here is more interesting and keeping it connected to git allows portability options (maybe across network divides).

How to write Jev in 25 lines of Python:

  1. draw a circle
  2. import the rest of the owl

>> This site has been online since 2004, previously entirely static (generated by a Perl script). It outgrew that some years ago and I've finally got around to rewriting it in bleeding-edge Rails. Source available on GitLab.

It's an useful resource, I had similar, albeit just a tiny fraction, collection of colors I can pull out of my sleeve when asked for advice, but... why does this page has to be served from "bleeding edge server application" instead of being served as static html files?

The most popular page is the "most popular gradients" page, and previously I had to grep the server Apache logs, insert into a DB, dump and copy the DB locally, regenerate the whole site and upload. Took an hour, I did that once a week or so. Now it's all done on the site without my intervention a few seconds after every download.

And it's bleeding edge because I wanted to get up-to date on recent Rails improvements :-)

[author BTW]

Maybe it's just me, but it seems like a huge waste of time (or to be on a more positive note - potential).

Just the first example "Device type in JS".

"A coarse pointer does not mean “mobile”, and a fine pointer does not guarantee “desktop”. Ask the browser about input capabilities instead of guessing the device from its user agent."

  const input = {
  finePointer: matchMedia('(any-pointer: fine)').matches,
  coarsePointer: matchMedia('(any-pointer: coarse)').matches,
  canHover: matchMedia('(any-hover: hover)').matches,
  }; 

So it doesn't tell me how to identify device type. It doesn't even run the code so I could quickly compare results between my mobile and desktop devices to establish a baseline.

The conclusion is wrong. The point of using these media queries is that:

1) You can only use tiny buttons with precise pointers.

2) You can only use hover popups with pointers that can actually hover.

In practice, much of this is too much work and everyone just designs for touchscreens instead. It's rare to find a website that even bothers with using title="" for tooltips because smartphones are a disaster of UI and lack tooltips.

You’re right: it doesn’t identify the device type, so the title is misleading.

The intended point is that device type is often the wrong thing to detect: a touchscreen laptop may expose both coarse and fine pointers, while a tablet may be connected to a mouse or trackpad. The snippet detects available input capabilities instead, which is usually what the interface should respond to.

I wasn’t particularly careful with the titles, but this one should be "Detect input capabilities". Thanks for the heads-up!

It has all the hallmarks of just telling an agent to scrape MDN and make a website

It wasn’t, but I’d be curious to know what specifically gave you that impression.

> Did you know that we name around 2,000-3,000 new products every year?

It's more likely that the whole product catalog contains 2-3k products. [1][2][3] So no, you don't.

[1] https://www.ikea.com/us/en/cat/products-products [2] https://lar5.com/ikea (~ 2200) [3] https://namingschemes.com/Ikea_Product_Names (~ 1300)

When [3] contains half as many as [2] it should be a good sign to take pause to consider both could be faaaar from exhaustive. [1] is just a link to a page of links, it doesn't really say anything about how many total named products there are. Meanwhile, https://www.kaggle.com/datasets/ranjithpanicker/ikea-global-... claims "34,932 unique global products" and Ikea Canada alone claims ~12k products https://www.ikea.com/ca/en/newsroom/corporate-news/ikea-cana...

Why should we treat a minor wiki page and some dude's personal site (who disagree with each other on totals) as authoritative proof Ikea is wrong about it's own catalog? Especially when it's not hard to find 1st/3rd party sources claiming an order of magnitude more products. Keep in mind, some things will also fall off the catalog over time.

It's been a downward spiral since covid.

Enterprise works ok-ish, but the standard version has daily issue ever since.

Not sure covid was the sole driving force. A combination of MS taking over and deciding to move it to Azure, a massive increase in traffic due to ai usage (not that this should be an excuse for a platform that should be scaleable), and Github going all in on AI usage to write its own code.

They're making it very easy for a viable alternative to pop up and take their lunch - it just wont be Gitlab.

While it annoys me how things have gone downhill, I think you missing one key detail with regards to competition. It's only "very easy" if you feel like throwing enough money at CI compute to power the majority of the open source ecosystems needs. That would be the bare minimum in order to even have a shot of achieving similar levels of network effects as Github.

I don't have data for it, but I have been a Github user since 2012 and have found it to be down often for pretty much that entire time. I always figured it's cultural to a degree–new features always seem pretty buggy/underbaked, and often continue to long term but remain unloved and incomplete.

I has never been so bad as in the couple last years. And it's getting worse.

I never had to wonder if Steam is going to be working today, so I could play my game after work, but it's been an issue with GitHub since covid. At least for me.

Fortunately, due the nature of the service, I can sit out most downtimes. Most of the time at least.

Enterprise here and it's down all the time. Right now and it was down 4 days ago as well.

disclaimer: I haven't seen the code

TS/JS is not the problem.

You can, and you should eject your dependencies and package them with your releases. And I don't understand why it's not a common practice.

You can even bundle your releases with a runtime, but that's not always the best solution. For something like this I'd actually prefer interpreted code I can inspect line by line rather than having a blob of unknown origin.

tangent

Once I've tried one SCM to track every single change to my files, and the other for bulk commits. The result was quite satisfying.

It was some 15 years ago, we just switched from CVS to SVN and everyone thought it was the end of the history, at least for SCMs. Main branch was called master, and we were locking files by simply telling our teammates not to touch them.

At one time I decided I really missed the Eclipse feature which was tracking all local changes to the files, even without an active SCM. Making tiny commits was not an option, because I want it to track every file save, and we haven't yet figured out working with branches.

So I decided to install mercurial and made a hook which made a dummy commit every time I saved a file. Everything mercurial related was ignored by SVN.

Suddenly I was able to teleport myself to a version from before the lunch while SVN history was crystal clear.

Somehow I still miss integrated, per file, timeline in IDE.

Some time ago I found Zed did not have undo-trees (like Emacs and Vim have, possible with plugin). I think DeltaDB is probably going to power undo-trees for Zed.