> Personally I'd love to go to the Arctic or Antarctic as a civilian as it would be an interesting challenge.
This is actually possible! Friends of friends have done it (with NSF I believe).
Research expeditions to the arctic sometimes take civilians as support (janitors, IT, cooks, medics, etc). It can be a cool way to spend a few months aboard a boat in the arctic.
My previous phone was a second-hand iPhone SE for which I had screen, power button, big button and battery replaced at various times. I think the battery was third-party & new, but the other parts were also 2nd+ hand. I don't know about newer models, and presumably there are other things that are more "fair" about the fairphone, but it doesn't have a monopoly on repairability in my experience.
You did all those repairs to your iphone yourself? I imagine that was significantly more technically difficult than repairing a Fairphone, which is made to be _user_ serviceable.
Original iPhone SE is relatively easy to work on, two pentalobe screws and a suction cup will get you into it. It’s not waterproof so there’s no glue seals to warm and melt, it’s still mostly screwed together inside, only the battery has glue strips holding it in.
From there I’ve swapped the battery, moved the logic board and home button to a new chassis, taken the camera module out and tried to clean it, had the screen+top chassis off. It’s not for everyone but it’s not technically complex with many specialist tools, it just needs a battery replacement kit, tiny screwdrivers, workspace, and patience.
I've never tried, but the original SE I'm talking about is contemporaneous with the iPhone 5 chassis and iPhone 6 internals. The 13 is 5-6 generations and years newer, and likely more hostile or complex in at least some ways.
No, I went to a local electronics shop. I don't have a pile of decommissioned phones in my house, nor the eyesight or hand-steadiness for fixing things that small. User-serviceable is definitely a distinction, but I suspect family members would expect me to be their technician anyway, and I'd point them to the electronics shop due to physical issues above, and fear of bricking their devices.
If your family members ever had to mount an ikea furniture or equivalent, they'll probably have an as easy or easier time replacing a part on a fairphone. Especially for the battery. At least for version 3 and older. I don't know for later models. If you know how to swap batteries in a tv remote, you know how on this phone.
> static code analysis which by definition does not find runtime bugs
I'm not sure if there's some subtlety of language here, but from my experience of javascript linting, it can often prevent runtime problems caused by things like variable scoping, unhandled exceptions in promises, misuse of functions etc.
I've also caught security issues in Java with static analysis.
The usefulness of using static code analysis (strict type systems, linting) versus not using static code analysis is out of the question. Specifically JavaScript which does not have a strict type system benefits greatly from using static code analysis.
But the author claims that you can catch runtime bugs by letting the LLM create custom lint rules, which is hyperbole at least and wrong at most and giving developers a false sense of security at worst.
Catch or prevent - linting only covers a tiny (depending on programming language sometimes more sometimes less) subset of runtime problems. The whole back pressure discussion feels like AI coders found out about type systems and lint rules - but it doesn’t resolve the type problems we get in agentic coding. The only „agent“ responsible for code correctness (and thus adherence to feature specification) is the human instructing the agent, a better compiler or lint rule will not prevent massive logic bugs LLMs tend to create like tests testing functions that have been created by the LLM for the test to make it pass, broken logic flows, missing DI, recreating existing logic, creating useless code that’s not being used anywhere yet pollutes context windows - all the problems LLM based „vibe“ coding „shines“ with once you work on a sufficiently long running project.
Why do I care so much about this? Because the „I feel left behind“ crowd is being gaslighted by comments like the OPs.
Overall strict type systems and static code analysis have always been good for programming, and I‘m glad vibe coders are finding out about this as well - it just doesn’t fix the lack of intelligence LLMs have nor the responsibility of programmers to understand and improve the generated stochastic token output
This sounds like an engineering quality problem rather than a tooling problem.
Well structured redux (or mobx or zustand for that matter) can be highly maintainable & performant, in comparison to a codebase with poorly thought out useState calls littered everywhere and deep levels of prop drilling.
But the popularity of Redux especially in the earlier days of react means there are quite a lot of redux codebases around, and by now many of them are legacy.
"We'll build a big centralised store and take slices out of it" still feels like something you should eventually realise your app now needs rather than a starting point, even in libraries which do it without as much ceremony and indirection as Redux.
> The library seems to be an antipattern of indirection.
Auto-generated actions from slices are a codified way to do what was once considered an antipattern: Tying an action directly to a single reducer, instead of actions being an action the user could do on a page (which multiple reducers could respond to).
I really can't understand how someone would make 30 redux actions for a simple use case, as someone has implemented the exact same thing. But yes, not a fan of Redux myself
Many years ago, I used Redux to build real time streaming data processing layer. Basically I need to receive, merge, and process multiple data streams into a single realtime data pool. After that,consuming the realtime data becomes dead easy.
Even now I am not sure I could find a better tool to deal with real time data and synchronization. But for simple crud Redux is mostly overkill
you got to the crux of it. Redux became a trend, surfing on its popularity at a time React wasn't providing the reactive piece it needed, plus the time machine demo just amazed everyone. The author got his job at Facebook. It carried millions of developers to use that lib, the author even said it isn't necessarily the go to mechanism, but hiring manager stuck with the idea that all projects redux magicians, since all projects needed React.
For the anecdote, I remember my manager admitting we can't fix the legacy app, but we can put lipstick on the pig with React.
I was making a point that whether you graduate or not has little correlation with your capacity of handling higher abstractions and complexity, because neither bootcampers nor engineering graduates have the experience of building complex systems, let alone under time, tech leadership and management pressure.
It is likely that the original authors may have found themselves in a situation where they were tasked to build a trivial form with technologies they were not accustomed to at the request of some superior and they ended writing a soup.
Yep, the Pi 5 is an ARM though and you have to license the architecture to use it. RISC-V is open source, but currently sucks in pretty much all aspects compared to any other. This is still way in the early dev and build support phase.
For integer workloads it seems closer to 60% of RPi 5 performance. There are some benchmarks that depend on vector support or dedicated CPU instructions for good results, and they skew the results.
It was somewhat of a joke;) He completed Kennedy's term and and was only only elected once. He refused to run for a 3rd. Given the immense ego's of these guys one might assume it was because he was unlikely to win. Peeing on people is unlikely to win you a lot of friends.
When I first read it I thought wait, 3% of 6 is 0.18, but then I realized no I'm a dork because 6 is the age of the kid, whereas the number 100 is written as a word hundred, hence I decided to write "HN poster responds:" with quotes around my first non-coffee aided thought because I thought it was funny. I guess I should have just made that full statement, but I do have a tendency to rather oblique communication strategies.
on edit: basically because I thought hah, this is the kind of mistake I always see poor tired folks make on HN and making the dumb comment and here I am making it!! This is a classic moment!
Whatever happened to just firing up a calculator app that's already on the device you were using? Or bashing "100/3" into the search box in your OS or browser?
Do you ask ChatGPT how long to cook spaghetti instead of reading it off the package you just took the spaghetti out of? Honest question.
Would a good library allow developers to ignore internals and get on with higher-level stuff?
reply