G
↗
Test-first fundamentalism is like abstinence-only sex ed: An unrealistic, ineffective morality campaign for self-loathing and shaming. It didn't start out like that. When I first discovered TDD, it was like a courteous invitation to a better world of writing software. A mind hack to get you going with the practice of testing where no testing had happened before. It opened my eyes to the tranquility of a well-tested code base, and the bliss of confidence it grants those making changes to software. The test-first part was a wonderful set of training wheels that taught me how to think about testing at a deeper level, but also some I quickly left behind. Over the years, the test-first rhetoric got louder and angrier, though. More mean-spirited. And at times I got sucked into that fundamentalist vortex, feeling bad about not following the true gospel. Then I'd try test-first for a few weeks, only to drop it again when it started hurting my designs. It was yoyo cycle of pride, when I was able to adhere to the literal letter of the teachings, and a crash of despair, when I wasn't. It felt like falling off the wagon. Sometime to keep quiet about. Certainly not something to admit in public. In public, I at best just alluded to not doing test-first all the time, and at worst continued to support the practice as "the right way". I regret that now. Maybe it was necessary to use test-first as the counterintuitive ram for breaking down the industry's sorry lack of automated, regression testing. Maybe it was a parable that just wasn't intended to be a literal description of the day-to-day workings of software writing. But whatever it started out as, it was soon since corrupted. Used as a hammer to beat down the nonbelievers, declare them unprofessional and unfit for writing software. A litmus test. Enough. No more. My name is David, and I do not write software test-first. I refuse to apologize for that any more, much less hide it. I'm grateful for what TDD did to open my eyes to automated regression testing, but I've long since moved on from the design dogma. I suggest you take a hard look at what that approach is doing to the integrity of your system design as well. If you're willing to honestly consider the possibility that it's not an unqualified good, it'll be like taking the red pill. You may not like what you see after that. So where do we go from here? Step one is admitting there's a problem. I think we've taken that now. Step two is to rebalance the testing spectrum from unit to system. The current fanatical TDD experience leads to a primary focus on the unit tests, because those are the tests capable of driving the code design (the original justification for test-first). I don't think that's healthy. Test-first units leads to an overly complex web of intermediary objects and indirection in order to avoid doing anything that's "slow". Like hitting the database. Or file IO. Or going through the browser to test the whole system. It's given birth to some truly horrendous monstrosities of architecture. A dense jungle of service objects, command patterns, and worse. I rarely unit test in the traditional sense of the word, where all dependencies are mocked out, and thousands of tests can close in seconds. It just hasn't been a useful way of dealing with the testing of Rails applications. I test active record models directly, letting them hit the database, and through the use of fixtures. Then layered on top is currently a set of controller tests, but I'd much rather replace those with even higher level system tests through Capybara or similar. I think that's the direction we're heading. Less emphasis on unit tests, because we're no longer doing test-first as a design practice, and more emphasis on, yes, slow, system tests. (Which btw do not need to be so slow any more, thanks to advances in parallelization and cloud runner infrastructure). Rails can help with this transition. Today we do nothing to encourage full system tests. There's no default answer in the stack. That's a mistake we're going to fix. But you don't have to wait until that's happening. Give Capybara a spin today, and you'll have a good idea of where we're heading tomorrow. But first of all take a deep breath. We're herding some sacred cows to the slaughter right now. That's painful and bloody. TDD has been so successful that it's interwoven in a lot of programmer identities. TDD is not just what they do, it's who they are. We have some serious deprogramming ahead of us as a community to get out from under that, and it's going to take some time. The worst thing we can do is just rush into another testing religion. I can just imagine the golden calf of "system tests only!" right now. Please don't go there. Yes, test-first is dead to me. But rather than dance on its grave, I'd rather honor its contributions than linger on the travesties. It marked an important phase in our history, yet it's time to move on. Long live testing. Continue down the rabbit hole with Why Most Unit Testing is Waste by James Coplien and my RailsConf keynote on Writing Software: Part 1 (starts at 11:00), Part 2.
R
↗
Hey everyone, We've been building Miu — an embodied AI agent on a Yahboom Raspbot-style platform (Raspberry Pi, mecanum wheels, RPLidar C1, PTZ camera, ultrasonic bumpers). After a lot of wiring and debugging, V2 is working enough that he can autonomously drive around inside a room without us manually joysticking every move. What's working: • LiDAR-based room scanning + obstacle avoidance • Holonomic mecanum control (strafe, not just diff-drive spin-in-place) • Ultrasonic as a "digital bumper" for stuff LiDAR misses (cables, furniture edges) • Live 3D viewer (Rerun) so we can actually see what the robot thinks • Backend orchestration: LLM plans missions, a separate executor drives the motors Nav2 / ROS 2 helped a lot as a reference stack and for A/B testing navigation — though our production path on the Pi is leaner (FastAPI + custom holonomic controller). Nav2 taught us the patterns; shipping meant ripping out a lot of complexity. What almost killed the project (real talk): Too many cooks on cmd_vel — vision pipeline, proximity reflex, room scan thread, teleop, and agent tools all wanted to move the robot at once. Classic race conditions. LiDAR serial lock — Nav2 container + our own LiDAR reader + live viewer polling the same serial port = chaos. Had to enforce one LiDAR reader and stop competing services. Control-loop bug — we were doing LiDAR HTTP calls inside the 10 Hz drive loop. Robot spun in circles after ~2 ticks. Decoupled sensor thread (LidarScanBuffer) from control thread — fixed immediately. Observability nightmare — logs split across Pi journal, movement_log, PM2 JSON (multi-GB…), Discord, activity stream. Couldn't answer "why did it turn left?" until we built a unified observability endpoint. Battery — still an issue. Continuous LiDAR + movement + inference drains faster than we'd like. Low-battery caps on movement duration for now. V2 architecture (what we changed): • One motion supervisor — single authority on motors • Mission FSM — vacuum / explore / find_person / teleop, one active job at a time • Planner vs executor split — the LLM picks what to do; it doesn't fire raw motor pulses every turn Next steps: • IMU + wheel odometry fusion (EKF) → AMCL for proper pose • Persistent room memory (episodes, obstacle map, cascade/EOD summaries) • Click-to-nav in the live viewer • Battery / power management tuning Happy to answer questions about the stack, Nav2 vs custom control, or mecanum on a Pi. Still very much work in progress — would love tips from anyone who's shipped a home robot without it becoming a full-time ROS babysitting job. Stack (rough): Pi 4/5 · Yahboom chassis · RPLidar C1 · FastAPI on Pi · Mac mini backend (Postgres, agent loop) · ROS2 Nav2 (research/A-B) · Python holonomic controller · Rerun for viz submitted by /u/Spinning-Complex [link] [Kommentare]
R
↗
Dr. Ayanna Howard, dean of The Ohio State University College of Engineering, former NASA roboticist and founder of Zyrobotics, explains why both universities and startups are necessary to advance robotics. Universities support foundational research that may not produce a commercial return for many years. Startups take that research and try to connect it to an immediate market need, moving quickly and changing direction when the technology or business model does not work. Howard also discusses the difficulty of building startups within universities because academic incentives are centered on research, publications and grants rather than developing products for customers. She sees the strongest model as faculty providing technical guidance while students lead the work of turning research into a viable company. Full convo: https://www.youtube.com/watch?v=lis9e9L4ScU submitted by /u/Responsible-Grass452 [link] [Kommentare]
L
↗
Standardization of graphical environments has always had a rocky history. Not every vendor provided one in the 20th century on their machines, and those who did generally provided an entirely proprietary solution that was custom built for the given device. Some well known consumer grade examples of the time would include the Macintosh UI, the Amiga Workbench, and who could possibly forget Microsoft Windows. The Unix sphere was in a similar boat for a long time, with window systems like SunView, MGR, NeWS, NeXTStep and many others. Certain graphical environments meant for use across different platforms did exist, like GEM, seeing adoption on platforms like the Atari ST (TOS) and IBM PC (DOS). This provided a level of application portability at the GUI library level, but it was still far from universal due to various architectural differences, as well as being developed exclusively for use in single user sessions local to the machine. The Unix world would see a complete shakeup in the mid to late 80s with the public release of the X11 Window System, which was specifically designed for remote, multi-session use with a client-server model that is entirely architecture independent and is driven by a message queue system. Seeing as how remote operation of different types of Unix machines with multiple users at once was a very common use case at the time, it quickly saw wide adoption by most of the major Unix vendors. X11 has a very simple job: be a family of protocols that provide a way for applications (clients) to create and position windows, draw primitives and bitmaps in those windows, and various other functions that allow a graphical environment to function. What it does NOT provide is a full desktop environment with a suite of applications, or even a window management system. These are all meant to be built on top of X11 and run in an X session provided by an X server. Vendors and independent programmers could develop their own application bundles that would simply run in an X session and interact with one another as needed, which we would see with simple window managers like TWM, VTWM, FVWM or similar, and even full-blown desktop environments like OpenWindows, IRIX Desktop, and others (modern day equivalents would be GNOME, Xfce, KDE, etc.). There was somewhat of a standardization dilemma across the major Unix vendors in regards to application GUI design and development, which resulted in the birth of toolkits like Motif and desktop environments like CDE, which would ensure a common look and fell across entirely different Unix flavors. Even in cases where the remote system was of a different architecture and even different operating system family, you could still run applications as long as they were made to talk with X11. Want to run a GTK application from an x86 Solaris remote host within a local POWER10 AIX system's CDE session? You can do that! Have a dedicated X server application running on a Windows machine? It'll happily display the application too! Times change, and so do common use cases for any given thing. Running graphical Unix applications remotely is now a niche, people for the most part run local sessions with various forms of GPU acceleration in multi-monitor setups with DPI scaling of UI elements on modern Linux or BSD operating systems... and yet, X11 is somehow still around. The fundamental principles of X11 operation remained the same, but many of it's surrounding layers had to change to accomodate modern use cases. Combine this with the age of the protocol and the legacy features that have to stay around, and maintenance becomes incredibly difficult. Multiple times in the 21st century have developers tried to draw a line in the sand and start anew, shedding what came before. You probably forgot many of these attempts ever even happened due to their failure to gain traction, but one has risen above the rest: Wayland. In some ways, Wayland tries to be what X11 isn't. It doesn't provide a level of network transparency, as it's designed to be used locally first and foremost. In other ways it takes X11's principles to their extreme, as it's protocol is even more minimal. This changes the fundamental link between applications and the environment, as now applications must run under a window compositor to be properly displayed. It is not enough to simply have a display server, because the server does not perform compositing. The burden now falls on the graphical environment itself. This doesn't sound too bad at a surface level, but you must realize that Wayland itself is not a standalone system. You don't run a compositor on top of a Wayland host session, the compositor is the Wayland session. "What's the big deal?", you might wonder, "I just have to run a compositor like I would a window manager or desktop environment, and applications developed for Wayland should just work.". This would be the ideal reality, at which point the only real drawback would be the inability to run X11 applications, something that is tackled by the Xwayland server. The actual reality is that it's not even remotely simple. See, there's a reason why Wayland has grown somewhat infamous for it's minimal, security first design at the protocol level: it lacks way too many features for many use cases expected by many in a graphical desktop environment. X11 also has a history of lacking important features in it's early days, but these could be added through the extension system. Once a needed extension was added to the X server, all applications could make use of it, and this would include window managers/desktop environments. Many crucial extensions would end up being added to the reference upstream X11 codebase (which as of the day of writing is X.Org's) over time, and any downstream flavors of the main X11 server would also have it. Better yet, if you're running an X server meant to run remote applications, and your current X server implementation lacks the necessary features, you can always try another one in a matter of seconds. Maybe even run another X server within your existing X session if you don't want to kill it. The Wayland ecosystem doesn't really allow for this. If you're running a given compositor that lacks certain protocols/extensions that your application needs, you're out of luck on that compositor and must switch to another one, since the Wayland "server" and the compositor are one cohesive whole. This right here is where the major pitfalls of Wayland start to show themselves. Since the task of displaying windows and providing many fundamental protocols is the burden of the window managers/desktop environments themselves, they have to provide it one way or another. The two most popular Wayland DEs, GNOME and KDE, commonly end up implementing such features in their own way that is entirely incompatible with one another. Projects like wlroots try to standardize many such extensions, but they are not guaranteed to be implemented by downstream WMs/DEs since they are not part of the reference Wayland implementation. This all sounds like an absolute disaster for the end user that can lead to nothing but severe fragmentation, which in many ways it has, because application developers have to really think about which of the major Wayland compositors they will write for, something that was barely a concern on X11 for a long time thanks to it's fundamental design and the existence of GUI toolkits. Users also have to pick their poison on which features they're willing to sacrifice when picking a compositor, because their Wayland implementation is never guaranteed to cover everything that others might. In spite of this, there's been a major push by Linux distribution makers and large companies in the OSS sphere like RedHat to put X11 in the ground and go forward with Wayland. This is why I called it a trojan horse, as RedHat and similar big players can use their leverage in the Linux userland to push their preferred Wayland-powered desktop environment of choice, which is GNOME. They can use their funding and pool of engineers to add features to the GNOME compositor at a fast pace, which they are not obligated to push to Wayland's upstream in any capacity, and the rest all have to play catch-up. Over time the feature gap between GNOME, KDE, wlroots and base Wayland will grow ever larger, so anybody who wants to start developing a Wayland compositor+window manager bundle will have an ever steepening hill to climb. You might be the kind of person who only really cares to run GNOME or KDE and nothing else. You're probably going to have the smoothest transition in the X11 deprecation process that is underway on several major Linux distributions, although this still isn't 100% guaranteed. The rest of us are going to be shit out of luck. The endgame of such a scenario should be obvious to anyone who has been in the computer sphere for long enough: consolidation. See, if you recall only a few years ago, many FOSS enthusiasts were more than eager to sell you on Linux/BSD because of the "freedom of choice" in the ecosystem, and nowhere did you see this being shown more than in the realm of window managers and desktop environments. From the most feature rich like GNOME/KDE/Xfce/Cinnamon/MATE, through to the minimal like i3/IceWM/AmiWM, to the downright ancient like CDE and WindowMaker. Hell, you might not want to run a WM or DE in any capacity and just want a blank X session, it's all up to you. You really don't have much to choose from in the modern Wayland ecosystem, and all the choices come with drawbacks that very negatively impact application usability. When push comes to shove with the choice of a Wayland environment, what are you gonna go with? How about a grassroots effort like Hyprland, that is currently developed at an incredibly rapid pace and includes the latest features almost immediately, but isn't guaranteed to continue like this long-term, and will inevitably have to play catch-up to GNOME and KDE... mmm those potential negatives don't sound very enticing, now do they? Maybe you want something that's more... "standard" in terms of it's foundations, like the wlroots based Sway? Probably a good choice if you mostly plan to use applications specifically designed to work with wlroots based compositors. If your applications are instead meant to target the two big players though... then you can potentially run into pretty bad issues. If you really hate yourself and want to suffer pain at every turn, there's always COSMIC DE! You see where I'm going with this? With so many complications arising just from your choice of a Wayland compositor, most users who value their time will just throw their hands in the air and go with whatever has the most backing behind it, rationalizing the choice by believing that will result in the highest degree of application compatibility. These choices will naturally boil down to GNOME and maybe KDE. Who benefits the most from this consolidation? Those who actively push for Wayland of course, like the GNOME Foundation and Red Hat. Freedom of choice is the last thing either of these entities (and those close to them) want you to have in your Linux environment, and the aggressive push to kill off X11 in favor of Wayland fits perfectly into their goals of siphoning users into their graphical environments of choice. Keep in mind, I've so far only really talked about the Linux sphere. What about other Unixes? FreeBSD has the Hikari compositor, but I'm willing to bet it has a ton of complications due to lagging behind the aforementioned options. The rest of the BSDs? Tough luck. As for Solaris and OpenIndiana? Not even a blip on the radar. A big reason for this is that Wayland is heavily bound to KMS (Kernel Mode Setting), which is a component of DRM (Direct Rendering Manager). FreeBSD has a clone of DRM, but none of the other modern Unixes do, meaning that they cannot have a working port of Wayland without severe reworks of it's foundation regarding comms with graphics devices. What they do have though is X11. WMs/DEs really only need a little bit of patching (if at all) to compile and run on these systems under X11. Hell, a few years ago trn and I patched bits of CDE to work under OpenIndiana. "Hold on, X11 is still around. X.Org still works on it and it's the reference implementation used across the board.". Well yes and no. It's been a bit of a joke for the past several years that the Xorg display server is under maintenance mode and now purely exists to leverage Xwayland (The X11 compatibility layer for Wayland), which is currently the reality and not just a simple joke. There hasn't been a proper release in over a decade, and the "maintainers" have been very vocal about their desires to retire the Xorg display server in favor of Wayland. They're so willing to move on that they have lately been taking active efforts to pull back any efforts to revitalize the codebase upstream, as well as combating the mere existence of forks that aim to pursue this effort, like X11Libre. If this continues, X11 holdovers on Linux are gonna suffer, and non-Linux users of X11 based environments will essentially be left without a maintained display server of any kind. Now rewind back to the start of this page. Compare the GUI situation prior to X11 and how things are progressing right now. We're looping right back to square one, wouldn't you agree?
