>> 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 :-)
I have to make a confession. I've been using different version control system for the last 25 years, but everytime I'm doing anything more complicated than basic commit/push I feel absolutely overwhelmed and terrified that I'm about to break something.
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."
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!
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.
I’m going to guess that a good chunk of products are named but never released. I’d love to know what products IKEA develops but decides to not release.
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.
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.
I've been saying this for years - the best way to wrap your head around AI and LLMs are to think about them as "a whole internet wrapped into a single zip archive, with immensely clever solution to query the data".
That's it.
Once you accept this mental model the implications are staggering.
AI is not "thinking", and it doesn't know the answer to your question because it's smart, but because it has been asked thousand of times over the internet, and it simply provides you with an already existing answer. That code it made for you? It already lived somewhere on GitHub.
But then you have to ask yourself - if we surrender to the AI, who will produce new content 10-15 years from now? If we all pivot from programming to prompt engineering, who will come up with novel solutions?
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.
A good moment to remind everyone that if we took the promise for granted, that AI will in fact prevail and prompting is the one skill that will rule them all... we'll lose all domain experts in one generation.
It's less of "signaling expertise" and more about actually having said "expertise".
In my experience with LLMs it's not uncommon to be having a deep conversation about making pasta, only to be told, after asking for a sample recipe, to get a bucket of paint and a bag of concrete. Of course these hallucinations are way more subtle and easy to miss for someone who doesn't have deep domain knowledge.
It's easy to make a good call, but it's really hard to stick with it.
The main financial advice I'm giving to all relatives is to write down their decisions before buying anything. Or, if you're looking for a long term investment - asking someone close to change the password on your account without letting you know.
The major problem with investing is that most people will commit to 2-5y strategy, and panic on the first dip.
If you did your due diligence and you believe that this particular asset will grow within 5 years - when it starts dipping after few months, and nothing major has changed in your predictions - you should buy more instead of selling.
> If you did your due diligence and you believe that this particular asset will grow within 5 years...
This assumes that most people know how to do "due diligence" and that their "predictions" are accurate. Most people don't actually have the knowledge and skill to evaluate the investment vehicles (stocks, bonds, etc.) available to them so their predictions are inherently limited and flawed.
> ... when it starts dipping after few months, and nothing major has changed in your predictions - you should buy more instead of selling.
One of the biggest mistakes average people make is selecting investments with risk profiles and durations that are mismatched to their needs and objectives. This is why, for most people, it's much better to use a properly-selected model portfolio than to try to pick individual stocks.
I've learned this applies to a lot of life. Being a good manager, tech lead, consultant, etc, advisor, parent, friend, etc, is sometimes just half being a good therapist and helping them regulate.
I've watched a lot of "not officially financial advice" finance videos on YouTube (the solid people, not grifters), and while the financial theory side is interesting, when they talk about pragmatic investing and patterns of client behavior they have dealt with professionally, a large part of it is emotion management. Convincing clients to stick with a solid plan even when this month is abnormally bad, or avoid going all-in on the latest hotness, etc.
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?
reply