556 karma · joined December 24, 2020
The only useful place for learning anything is from reading the forums for each exercise. Naturally Duolingo has since shut down the forums thus removing one of the only really useful outlets for asking questions and getting clarification on things.
Perhaps the worst thing of all though is the huge reliance on idioms. There are translations which are entirely idiomatic and have little do to with what’s actually on screen. I find this to be actively sabotaging to learning because you’re not actually learning what’s being said, you’re just being taught that “X means something like Y” even though none of the words or grammar really lines up.
I could go on and on about the low quality of the Japanese lessons. It doesn’t seem like other languages are quite this bad on Duolingo but it definitely makes me think twice about renewing my membership.
I like to joke with my boss and program managers that when they are in meetings, they are getting work done but when I’m in meetings, I’m not getting work done.
Jokes aside I do agree with the general premise that meetings can be valuable and that sometimes getting everybody together in a room (or on a call) helps a lot more than everybody in a silo for a week and not getting the right things finished. The problem is that by and large people just don’t know how to run meetings effectively.
Case in point is that where I work we have a rule about starting meetings 5 minutes after the hour to give people time between meetings to use the restroom, get coffee, or whatever. It’s a nice thought in theory but in practice it just means meetings now all run 5 or 10 minutes late because everybody is determined to fill that buffer. I often asked why instead of starting meetings 5 or 10 minutes later we couldn’t just end them 5 or 10 minutes earlier and never got a good answer.
But that’s just a symptom of a deeply rooted problem with meeting culture. All too often I’m booked into meetings with no agenda or no real explanation about why it’s worth my time. Meetings that could be scheduled for 30 or 15 minutes get an hour slot. Meetings with an agenda go off the rails and nobody speaks up to put a stop to it. Stand-up meetings turn into design meetings. Too many people, or the wrong people get invited to meetings which causes derails or wastes others time. My “favorite” are “pre-meetings” to talk about upcoming meetings. It becomes self-parody sometimes. People’s calendars get so packed with meetings that the only way to get time with certain people is to attend unstructured “office hours” style meetings. You have people who absolutely refuse to engage in discussions over email or IM so it ends up requiring a 30 or 60 meeting for something that could be solved in 5 minutes over a chat. It’s just ridiculous.
So I’d argue it’s not that meetings don’t have value and aren’t “work”, it’s that people don’t know how to run them effectively and they just waste a bunch of people’s time. Whenever I schedule a meeting I always try to schedule for the least amount of time necessary, describe what it is and why I need people there in the invite, and have an agenda that I mercilessly try to stick to. I really try to be respectful of others time. It’s not really hard but it seems like these simple things are so hard to do.
You can use local storage to save recordings by connecting flash storage to the hub, but it’s only really useful a backup. You can’t view it in the app (you have to sneaker-net the storage to a computer), and it can only save triggered recordings.
Basically if you don’t care about storing and saving recordings for future use and only plan to stream from the cameras, then it’ll continue to work (as long as Arlo’s web services work of course).
In other words, unless you’re going to take the time to reverse engineer all of it, you’re completely at their mercy.
Even if you opt for local storage you’re still beholden to their black box hub because that’s the only thing the cameras will talk to, and their app because that’s the only thing that will talk to their hub. (HomeKit and other integration exists but it doesn’t provide the full functionality you get from the app, and still requires their hub.)
I also can’t emphasize enough just how much of a difference an application flux makes. I spent years struggling with sloppy solder work and thinking I was just doomed to be bad at it. Using flux made a massive difference. I was no longer having to constantly clean up bad joints or deal with solder blobbing where I didn’t want it. Just recently I was able to effortlessly hand-solder a bunch of tiny SMD components onto a board. Something I never thought I’d be able to do.
When I was learning to solder I really wish the importance of flux use was taught to me. It would have saved me a lot of cursing and frustration.
In my experience there is rarely ever a “next time” and “fix it later” becomes “fix it never”. It’s always cheapest to fix worst practices up front rather than letting them metastasize into a huge pile of technical debt later. It’s also rare to find anybody interested in or willing to go back and fix old stuff when priorities often involve chasing the next shiny thing.
11 seems to have stumbled out of the gate and it doesn’t feel to me like any of the even most basic complaints I have will ever be addressed. The taskbar for one still has piss-poor usability and represents a huge (and completely unnecessary) backslide from previous versions of Windows. I also hate that I can’t turn off rounded corners. (Yes it’s a minor thing but it really irks me.)
I’ve looked a lot at its source code and it relies on an incredible amount of hackery to actually work. A lot of what it does is injects itself into various parts of the OS and shims in its own behavior. It’ll do things like redirect API calls to older DLLs or even modify data structures on the fly. It’s how it can do all kinds of cool stuff that your typical “Windows tweaked” apps that only rely on registry changes can’t do. (Not surprisingly the kind of things it does can look a lot like malware to heuristic analyzers.) It’s an incredible piece of reverse engineering but it shouldn’t even be necessary to get back such basic things like squared corners and old taskbar behaviors.
I really hate Windows 11. It doesn’t run on several of my computers due to its system requirements and for those that it does run on I find the UX to be such a huge step backwards that I find myself continually fighting with the shell rather than actually getting work done. So, I’ve been steadfastly sticking to Windows 10 on machines where I need Windows.
There’s so many things completely artificially gated to Windows 11. The new Apple Music Preview which is gated to 11 can be easily patched to run on 10 just by editing the manifest. I’ve found many other “Windows 11 only” things to be entirely “paper” limitations. I tried to hack WSA onto 10 a while back but quickly realized it was more than a manifest change and lost interest because it wasn’t important enough to me to pursue further.
I’m glad someone took the time to figure it out and I tip my hat to the folks that took the time to debug and reverse engineer this solution. The relative simplicity of the resulting hack to run WSA on Windows 10 shows that it seems to be more of an unwillingness to backport some new APIs rather than any sort of deep technological changes in the OS.
Using an ESP32, i2c joystick controller, and i2c 128x64 OLED display I was able to cobble together a device that could control the robot and perform all its functions, as well as get telemetry from Bluetooth LE and show it on the display along with displaying controller inputs.
It wasn’t simple - it took months of work to get to a point where I had a mostly working prototype. That work including reverse engineering the device software and firmware, POCs running on my computer and then my phone before even starting on the standalone ESP32 version.
Pretty much from the start I was impressed with the capability of the ESP32. I had quite a bit of past experience doing hobby projects with Arduino and its ATmega 328 but the ESP32 was a whole new world. It was quite a learning curve at times. While I could use Arduino libraries which helped accelerate a lot of my progress, the multi-core nature of the ESP32 also meant that I ran into many interesting issues and incompatibilities with things I would do on the Arduino. Interrupt handling was completely different, for instance. i2c in particular was very challenging with lots of new and exciting issues to contend with.
Any sort of concurrent operations against the i2c bus would cause a crash, so I had to ensure I had careful synchronization of reads/writes. The speed of the ESP32 also meant I could easily saturate the i2c bus. This became a problem as I was trying to read inputs from the joystick, and output data to the display from both Bluetooth LE messages and the controller state. The ESP had the speed handle this no problem of course, but not the i2c bus. I had to write a rudimentary frame queue to control display output without saturating the bus since dropped frames weren’t as big a deal as not quickly processing joystick inputs. I also found many bugs in various Arduino libraries where they made bad assumptions on ESP32 hardware. I’d contribute fixes wherever I could. Most of my HW and libraries were from Adafruit, and they in particular were great about accepting my fixes into their repositories for the various issues I found.
One saving grace throughout any challenges I had was I found much of Espressif’s documentation to be very good - far better than I’m accustomed to from embedded hardware vendors. The community was also really vibrant which meant answers were often easy to find.
There was no serial debugging so I had to get a JTAG-capable device to save my sanity. Thankfully a cheap FT232H board in JTAG mode made a good enough debugger.
After lots of trial and error, I ultimately settled on Platform IO with Visual Studio Code for my development environment. It worked pretty well, although I ran into some really nasty bugs in Platform IO when debugging that would cause it to quickly drain my laptop battery (which they still haven’t fixed as far as I can tell).
Eventually the delisted software that inspired this whole project came back for download and I was able to get it back on all my devices and I kind of lost interest after that. However, the time I spent working on it was definitely a rewarding learning experience and made me a big fan of the ESP32.
I’ve also found Espressif’s documentation to be exceptionally good which has been a big help.
If you’re doing any ESP32 dev work I strongly recommend getting a FT232H which can be used as a JTAG debugger if you don’t have a board with native capabilities otherwise debugging is really, really painful.
It’s well worth a visit if you’re in the Seattle area and are into aviation or space stuff.
All too many things like this either dive straight into the deep end inundating you with superfluous details when all you want is a primer, or provide so little information as to be nearly useless.
The writers on this did a great job.
Windows has something similar called Time Travel Debugging[1] but in my experience the dump files it creates can be enormous and be a pain to analyze as a result. (It also relies on WinDbg which while being extremely powerful and capable, has a huge learning and usability cliff. I’ve been using it for over a decade and I still need a cheat sheet from time to time. The revamped WinDbg Preview[2] improves the UI a lot, but ultimately it’s still WinDbg.)
[1] https://docs.microsoft.com/en-us/windows-hardware/drivers/de...
[2] https://docs.microsoft.com/en-us/windows-hardware/drivers/de...
Finding what I want can be very difficult if the text isn’t clearly visible in the cover art or if it’s not art I’m very familiar with.
Even the fact that it’s sorted A-Z doesn’t help because it often sorts titles starting with “The” under “T”. Sigh.
UI designers: just give me a list view option. Please.
Just last week I was on the verge of literally ripping my hair out trying to figure out a frustrating bug that never occurred when running in the debugger. After a lot of frustration I had an idea: rather than starting the application in the debugger, I’d attach later. When doing this, I began to see a huge amount of interesting first-chance exceptions (this was managed C# code) that clued me into the root cause of the issue and I was finally able to solve the problem.
I came to learn that an underlying library I was using had some code that ran on startup that actually detected if a debugger was attached and would turn off the problematic code path in this case! I came to learn that this was an intentional optimization the initialization of this code caused a bunch of noise during regular debugging (lots of first-chance exceptions that were ignorable). Unfortunately, this also meant that the interesting failure case I was running into was now completely hidden.
Given my non-traditional background and keen awareness of my blind-spots, I really struggle with impostor syndrome. I also fear the interview process because I don’t want to look stupid and come to realize my past success was driven by chance rather than smarts. I also know how much of a grind the entire process can be and how it seems like many interviewers are more interested in making themselves look smart rather than honestly assess a candidate.
All of these things are probably more of a function of projection and insecurity rather than reality, but they all feel real to me.
That being said, you don’t want to use that oven for food purposes anymore. Lots of toxic chemicals will off-gas in the reflow process.
ETA this reminds me of the Xbox 360 “red ring of death” fiasco. One DIY repair technique was to wrap the entire Xbox in towels blocking all the ventilation. The theory was the resulting overheating would reflow the failing BGA solder joints. I don’t know if this really worked or was anecdotal but it was one I remember seeing a lot.
That being said, reading this thread I’m realizing how many great options there are for these kind of scenarios on macOS.
(Of course more often than not people have empty/useless linked work items, and PRs with useless titles and descriptions but that’s a whole different kind of problem.)
Even the greats can succumb to this. The Beach Boys’ Brian Wilson got caught in this trap when working on the band’s Smile album in 1966. He intended it to be a entire album in the modular cut/paste vein that Good Vibrations used (which was still pretty novel at the time). He spent nearly a year experimenting, tinkering, and retooling to the point of creative paralysis. Having to release something, the entire project was scrapped and the original project became something of legend among aficionados. It wasn’t actually “completed” until 2004 when Wilson was finally able to revisit the project. Funnily enough the big motivator to finish the project was a deadline — just like the article recommended. In Wilson’s case, it was a commitment to perform the material at a series of sold out live shows.
While I’m not a musician, I certainly understand the desire for some measure of perfection in my software or hardware projects — many times to the point of creative paralysis and eventual abandonment. It’s said that “shipping is a feature” and sometimes you just have to settle for “good enough” if you ever want to share your creations with others.
I have an expensive robotic cat toy that the manufacturer stopped supporting and I’ve been working on reverse engineering the firmware in my free time to better understand how it works. I have no background in reverse engineering so I’ve been learning a lot about identifying hardware, reading data sheets, and of course fumbling through Ghidra to disassemble the firmware.
After getting your bearings it becomes pretty easy to recognize the patterns of various standard C library functions like strlen, memcpy, etc. Others can be more challenging. Of course, with bespoke embedded hardware it can be much more difficult.
Ghidra really is an amazingly useful tool (clunky, yes — but very powerful and of course it’s free.) It makes me curious about commercial offerings and if they are worth buying as a hobbyist.
Back in the day when I had a Windows phone, I used Microsoft’s Zune player to sync it - but I used iTunes for my actual library management. This was a problem because all my playlists and ratings were in iTunes and there was no clear migration path. I’m pretty obsessive about organizing and cataloging my media files so this was something I couldn’t let stand. Unfortunately while iTunes had a decent SDK, Zune had none (at least not a public one).
I basically had to reverse engineer Zune’s APIs to figure out how to synchronize things like playlists and star ratings between the two platforms. It was all a big ugly hack — on the one side using iTunes’ documented but limited COM APIs, and on the other using Zune’s completely undocumented but thankfully also COM-based APIs so I could at least try to infer some functionality behind them via reflection. It was a precarious hack as well. When it worked, it worked well enough, but any time the Zune client software updated, parts of their API would change or break and I’d have to try to figure out how to hack around them again.
All these years later, iTunes still has a COM SDK but it hasn’t been updated since 2004 so it’s stuck only supporting some of the most basic iTunes features for automation.
I can still use it for some CLI tools that I have where I can use keyboard shortcuts to set star ratings on songs without having to manually go in iTunes while using it. That way if I have a playlist going in the background I can just press one of a set of programmable keys to launch this little CLI tool to rate a song on the fly without otherwise interrupting what I’m doing. Sadly the SDK doesn’t support the newer heart ratings, or things like checking/unchecking songs from playlists.
I guess what I’m discovering from writing this post is I seem to spend a lot of time trying to automate all my weird scenarios around media management.
Lately I’ve been working on a project in my spare time to control a BLE-based robotic cat toy. The company that made it stopped supporting it and delisted their applications. This was a very expensive toy that I didn’t want to stop working because of the whims of the company. It was a big challenge - I had to reverse engineer their protocols, reverse engineer their applications, and write something new to replicate the functionality. Just to amp up the difficulty I also decided to build a standalone ESP32-based device that I can use to control the robot without even needing a phone. It’s been a big challenge working with lots of unfamiliar technology but it’s also been a lot of fun learning and experimenting with these new (to me) things.
It’s actually a _really_ common vector to exploit poorly written installers by dropping your own file (like a malicious dll or exe) into that directory as a low rights user in the hope that the high rights installer process will then load that code. That’s presumably what’s happening in this case.