The actual page title is "The story of a beloved IKEA bag".
Neither the title nor page says anything about a "free lifetime warranty", as the HN title currently claims.
And as far as I can tell, it does not have a lifetime warranty. That seems to be a claim made on some social media posts, but nothing from IKEA corroborates that, either on the product page or warranties page. Maybe your local IKEA might replace one for you, but I assume that would be manager discretion.
> Specs are meta solutions. They describe the general shape of the solutions by refusing to make any technical decision that would leads to incidental problems and thus only needs to focus on the essential ones.
Yes, this is a feature not a bug. Then, code review ensures that the actual code makes the requisite technical decisions in a desirable way. This is much faster.
> Generating code with AI is rolling the dice every time said generation is done. Proper implementation happens because with making decisions and going down a path, backtracking if necessary when it's no longer working. Going with AI is breaking down that continuity because they restart from scratch everytime.
False. You only do the initial code generation an initial time, and then update the spec to specify (at a high level, ideally) the constraints that are missing. But then you have the AI modify the existing code to meet the new spec, not start from scratch. AI does not "restart from scratch everytime", it takes an updated spec plus existing code and updates the code to match the updated spec.
It's still "making decisions and going down a path," which you call proper implementation. That's the whole point.
> Writing and maintaining “specs” in plain english is painful.
The subject of this entire post is development with agents. Writing specs in English is how you do that. If you don't like it, then this is probably not the right article for you to be commenting on.
This is about ensuring that when AI's make future changes, they aren't just looking at the existing code and making assumptions about intent. They should always be pulling the specs to ensure that changes maintain compatibility with the specified intents.
> Otherwise you'll accumulate specs that are right when they ship, wrong in subtle ways 3 months in, and wrong in glaring ways 6 months in. AI doesn't change this dynamic, it amplifies it.
Not if the changes you're making are always to the specs, as opposed to the code. The whole point here is that you don't change the code, you change the specs, then approve the code that the LLM changes as a result. This way the spec should never diverge from the code.
AI absolutely changes the dynamic so that code doesn't converge from the spec. That's the whole point, and the whole point of committing the specs like code.
Automating testing is great too, of course, but that's not the full picture. It ensures formal compliance, but doesn't encapsulate anything about the spirit or purpose of why the design in a certain way. Good specs do. The purpose/motivation sections and engineering guidelines are some of the most important for an LLM. Which is what helps the LLM figure out how to then best modify the existing code when features need to be changed or added.
Disagree completely. The spec is vital so that future changes continue to conform to it. Specs absolutely need to live in the VCS, because they continue to be needed to keep the code conformant. They essentially are a form of code now. And code goes in the VCS.
I really disliked previously, when icon prominence could be wildly different because one icon takes up the full area with a big square, while another is a circle that necessarily has a significantly smaller area within the same extent. Icons from Apple were all nicely balanced in size, but third-party apps could be anything.
Giving equal visual weight to each icon is an improvement. iOS was a step forward in this direction, and now they finally brought the same standard to Mac.
Squircles aren't ugly, they're functional. "Shape" hasn't disappeared as a distinct visual cue, as the area within the squircle is made of, well... different shapes.
And let's not forget the fact that Macs still effectively use icon masks. A smaller icon is harder to click, because clicking on a transparent area... doesn't click at all. I remember icons like a skinny letter "S" that you had to click just right or you couldn't at all.
> Being generally active and eating fruits/vegetables is like 80% of the work for being healthy.
Except for the things that you get from sunlight, not diet.
> If everyone is deficient, then it must not be that important.
But nobody who lives in e.g. East Africa and spends a lot of time outdoors is deficient.
So it's actually pretty reasonable to say that a modern indoor lifestyle combined with long winters would truly lead most people in those regions to being deficient.
There's nothing I personally want to bring, but these would make AMAZING gifts, cool things for your desk/bookcase, etc.
There have got to be so many interesting, educational, and cultural objects you could print like this, and the fact you can "blow up" an object like a insect is even cooler.
Depending on the price, this feels like something that could take off in a big way.
I love swiping for speed, because it's usually faster than tapping and easy to do one-handed, but then there are always a bunch of words that are too similar that it can never get right, it doesn't deal well with doubled vs single letters, etc.
So for the longest time, I've wanted a new keyboard layout specifically designed for swiping. In the same way that Dvorak was optimized for ergonomically typing English words, I want a keyboard layout designed to minimize word overlap/ambiguity when swiping.
It doesn't even necessarily have to have 26 keys, e.g. maybe there could be one key overloaded for v/w/x/z (and you long-press it if you ever want to type a single letter). On the other hand, maybe there need to be separate keys for 'e' and 'ee', or a special key for "double the previous letter".
Because I love swiping, but all my problems with it come from the fact that the QWERTY layout is far from ideal for it. I am 100% willing to learn a new layout if anyone will develop an optimal one for English so that swiping has a 99.9% accuracy rate instead of what currently feels more like 90% or 95%.
Do NOT do this with your manager. The key part of this article is:
> When you have something you want to do and that you feel is in scope for your position, but you want a bit of reassurance or to let the boss know what you are up to, it’s common to reach out and ask them for permission. Don’t. Don’t ask for a yes. Instead, offer a chance to say no, but with a deadline.
If something is not in scope for your responsibility, obviously you must ask for permission.
If something is in scope for your responsibility, then just do the thing.
If it's in some weird edge case where you "feel" it is "in scope for your position" but you "want a bit of reassurance", then pick a lane. Either do the thing or ask for permission. Probably default to asking for permission unless a knowledgeable colleague tells you it's your call.
But setting some kind of deadline for your manager to opt-out is extremely disrespectful. If I ever had a report try to pull a stunt like that, it would be the first thing we'd talk about in our next 1-1.
Because if you have a manager who usually responds promptly, then you can ask for permission and get a quick reply. "Asking for no" is not making it more convenient for your manager, it comes across as trying to usurp their authority. "Hey, I'm going to tell HR you gave approval for a raise unless I hear from you by noon." That's... just not how anything works.
And if you have a manager who often misses e-mails or takes forever to respond, then it comes across as trying to take advantage of that to do stuff they wouldn't approve, in a sneaky way.
This is a bad look in every possible situation. Do not do this.
Like, if you're a journalist telling a source you'll print the story unless you get a correction by a deadline, OK fine. If you're looping in a peer as a courtesy (NOT a manager), then OK. But with your manager? That's crazy.
I think it's quite obvious that the target market has almost zero overlap with interest in the Commodore products from the 80s.
There's nothing wrong with a new company (new as of last year I think?) that owns the Commodore branding, and put out the C64U, to try putting out a new product for a different market.
The glowing Commodore icon just gives it a suitably vintage/retro feel that is aligned with the values of the device. Nothing more, nothing less.
In other words, is for a very specific group of people trying to digitally detox, who like a retro hardware aesthetic, that has nothing to do with C64 enthusiasts.
Automated re-factoring means you can refactor duplicated code only as long as it is exactly duplicate.
Whereas the whole problem is that when somebody changes 3 out of 10 of the duplicate cases in a simple way that they are no longer exactly duplicate, and then somebody fixes a bug in one of the other 7/10 cases, they can update the bug across the 7 "duplicate" cases but they'll miss the 3 that aren't.
The problem with duplicate code is always when some of the instances get changed/fixed but not all of them. And that when somebody edits one instance, they often aren't even aware of all the other instances.
Abstractions are low-risk, because you know where the code is. If it's the wrong abstraction, you can fix that and know what you're fixing. Whereas with duplicated-yet-modified code, you've now lost the connections between them.
I swear to God, I've read the article twice and I've read the comments replying to your question and I still have no idea.
I think the problem is that, for any given sentence, it is unclear whether the author is talking about the fuel a ship is burning to move its cargo, or fuel that the ship is transporting to a destination.
I do understand that the article is making some kind of distinction between the two, but it is so terribly written that it's just impossible to figure out which one it's talking about at which point. Or at least I certainly don't care to waste my time "solving" the article like it's some kind of linguistic puzzle.
I'm not sure I've ever come across an article that needed an editor to improve its clarity more than this one.
A standard iced coffee is just regular brewed coffee that is then put in the fridge. (Which is different from cold brew which is brewed in the fridge.)
This is fascinating from a food technology standpoint.
But the framing of the article around espresso specifically is somewhat bizarre. Most people want their shot of espresso to be piping hot, not room temperature. And most iced coffee is very intentionally not made with espresso (although you certainly can use it if you want).
The text of the article seems to suggest that this is more intended for "making ready-to-drink coffee products at industrial scale". But then that is not single-serve espresso shots that the article shows in several images.
So is this about room-temperature espresso shots (not what most people want) or about industrial-scale concentrated coffee? And if it's the latter, what would those machines look like? It's one thing to use ultrasound at a small scale; but what about in gigantic basins? Does that work, or are there challenges? Is this tech that scales?
> You had to dig. You had to seek out small, specialized record stores or spend time on shady forums. You’d track down obscure distros just to order releases you couldn’t get any other way... Now, it’s completely different... That sense of discovery, of finding a truly underground gem, just isn’t the same anymore. It’s too easy now.
To the contrary, I can now spend months digging into obscure African 70's music that there was just no realistic way for me to access before.
There are 10,000x more obscure gems to find, across the world and across the decades.
You can define your taste in far more granular ways than you ever were able to before, follow the paths of so many more artists, and even put out your own music with infinitely less friction than before.
The author is missing the forest for just this one tree.
Neither the title nor page says anything about a "free lifetime warranty", as the HN title currently claims.
And as far as I can tell, it does not have a lifetime warranty. That seems to be a claim made on some social media posts, but nothing from IKEA corroborates that, either on the product page or warranties page. Maybe your local IKEA might replace one for you, but I assume that would be manager discretion.
https://www.ikea.com/us/en/p/frakta-shopping-bag-large-blue-...
https://www.ikea.com/us/en/customer-service/returns-claims/g...