How do you find these kind of jobs? That’s something I think I would enjoy to do but I’m not sure where I would start looking for customers. Is it world of mouth?
Most of those were projects from when I worked for an engineering services company. The first one was a freelance opportunity I found online. Probably on reddit: it was about 4 years ago.
It's still true that people, out of convenience and familiarity, used Raspberry Pi for tasks where a microcontrollers would have been perfectly adequate
There was definitely usecase overlap due to the presence of the GPIO, but huge numbers of Pis ended up doing things a microcontroller can't - stuff like the PiHole and Retropie projects, and never used their GPIO pins at all.
Thinking of any of the early Pis as microcontrollers ignores a huge amount of the ways in which actual end users interacted with the thing, and even the way it was sold and marketed. Upton was trying to replace early hacker-friendly home computers like the BBC Micro/Apple II, for a new generation.
> but huge numbers of Pis ended up doing things a microcontroller can't
Mate you know full well it was multiple things... Marketed to education as an actual computer, to the maker demographic as a microcontroller, as a way to learn coding but also robotics etc
>Thinking of any of the early Pis as microcontrollers ignores blah blah blah
This just clarified something for me. I've always been annoyed when I see a Pi with nothing connected to its GPIO header; why not just use a cheap thin client? Or an old laptop, for that matter? But that's missing the point. Here's the point:
Pre-Beagleboard-and-Pi, if you wanted an programmable thing to work with GPIO, you used an Arduino or a BASIC Stamp, or just a plain old PIC. But they wouldn't run a real OS.
Pre-Beagleboard-and-Pi, if you wanted an embedded Linux box, you used a WRT54G or a Soekris or an old laptop. But getting GPIO out of them was a PITA. (And often involved lashing an Arduino to the side.)
The Beagleboard (released in 2008), could finally do both. It had gobs of I/O and first-class support for it under Linux. It was pretty affordable. Then the Raspberry Pi came out in 2012, with a similar amount of GPIO, but demolished the price point to where it made sense to use it in place of a microcontroller.
That's really the magic of the Pi. You can keep one cheap gizmo around, and use it to solve (a large fraction of) two classes of problems. It doesn't fully replace everything a PIC or a PC can do, but it replaces an awful, awful lot of them.
> I've always been annoyed when I see a Pi with nothing connected to its GPIO header; why not just use a cheap thin client?
There have also been times when Pi's were cheap enough and x86 idled so power-inefficiently that you'd save money over a reasonable time horizon if you couldn't run your old laptops at full throttle.
Absurdly extreme example, but at one point I decided to replace a couple (maybe 3) RPi's with a single old Dell rack server off Ebay plus replaced my router with one running pfsense. I knew it would be mostly idle, that thing had 2 Xeon processors to replace 3 cheap ARM processors.
Between the 2 rack servers, my power bill went up by enough to buy a new Pi or two every month. It was like $80/month extra in power bills.
A $2 Chinese ESP32 dev board is more stout in many ways than the first Pentium machine I had, which sure did feel fast-enough to run the whole world with at that time. :)
In this amazing world full of such inexpensive choices, it seems so bizarre to me to demonize any of them. They're all excellent in some way, and it's OK that there's more than one.
This isn't football, handball, American politics, or Highlander: There can be more than one. It's OK.
This is what I keep repeating in many threads about ESP32, the little thing is actually quite powerful, especially for those of us that experienced MS-DOS PCs.
A bit light on details but nevertheless interesting.
As someone who’s done a fair amount of coding with Helix via ssh on my phone while riding the train I find fascinating reading about other people’s setups. For sure not having to type the code makes everything easier
I think people used similar prefixes for a long time. For example, Haskell has had `unsafePerformIO` since the 90's... and MSFT's Hungarian notation was also similar, though it used abbreviations for things like "unsafe" (not "dangerous"). Perhaps React was the most famous case of using "dangerously" though.
"unsafe" seems quite different from the "dangerously [...]" phrasal template. I don't think it's a stretch to suppose it was inspired by React. Still waiting for this one to catch on:
This is sometimes exposed in front end browser code and I had an actual (non technical) end user email our support team last month asking if it was something they should be concerned about! God knows how they found it, I suspect everyone is now an AI-enabled expert at these things…
Oh I've stumbled upon it myself while coding. You can ctrl/cmd-click into any React type and it will take you to its explicit source definition. I'm not sure if it's still the case but they used to have all of the types organized into a single file. Since I was the go-to TypeScript person at one job I had I made sure to familiarize myself with every type (less than you'd expect)
The point of that scary flag name was the stance that source maps should never be deployed in production.
There are stances that say they should, browse a large SPA with complex working source maps enabled, DevTools open, cache disabled and a long session (relevant because of HMR in dev), and you can see why this matters.
Browsers only fetch and process source maps in a development environment in production, that's why this flag name exists.
That being said, I still have a hobby project with an (in my opinion) sensible (at the time) Webpack configuration, and glossed over this being in the minified bundle, after 1-2 days at the time.
But if my hobby project would have been something production-relevant, I'd have continued to hunt down this artifact.
I think, with Vite et al this should not appear anymore in current JS bundles ready for prod, so the name is apt.
But the underlying problem is still a neverending source of frustration: minification is (by definition, when it's statically verifiable), not equipped to change object property names without provoking breakage.
In Webpack times, early React 18 days, manual config, "ejected" and adjusted from CRA, I did have it in my production bundle.
I just gave up checking on why after a couple hours because it was a hobby project.
Haven't seen it in a long time since then, but there are many overlapping factors here.
As far as I know, Vite/Rollup tree shaking is strictly better than what Webpack + Terser did, but I'm wondering where the difference comes from.
Maybe it's even a JSDoc annotation or something else that is esoteric.
Because tree-shaking all property names in JS without making static analysis arbitrarily complex, is still not possible.
So, if the change was not on React's side, I'd guess it is in bundler minifying heuristics or a backwards-compatible change that makes the property name inaccessible and erasable by other means.
In my experience without search I end up with an hallucination fest more time than not. In one sense that might be more interesting but I'm not sure that's what you mean :)
I wouldn’t call it a hallucination fest. If you’re using the models for anything other than a juiced up google search then turning search off, at least until it’s actually needed, is better in my opinion.
Expertise is more important if you care about a good end result. People pushing for AI often don't care about the end result at all. They care about quantity over quality.
This can be really frustrating for someone who spent time getting experienced. They get hit twice. First they don't get a chance to do a job because "AI replaced you, sorry". Then they look at the result and what they see is low quality slop.
reply