This project looks interesting! I have used a similar project called tsoa [1] and have appreciated that it generates an OpenAPI spec that can be consumed readily by many other clients, even outside the JS ecosystem. Does TRPC have plans for a similar feature set?
The page loads within 500ms for me without cache, fonts and all. It doesn't show animations, flashing content, mailing list modals, etc. Navigating between pages is near-instant. The site isn't collapsing under its own weight.
Compare the site to sf.funcheap.com which I unfortunately use to learn about things to do here in SF. Yes, it renders without JavaScript enabled, but the two pages take the same amount of time to load in my browser, and Funcheap still tries to load resources from two domains blocked by uBlock Origin even with JS disabled (15 with it enabled). Is that really any better? There are so many miserable experiences on the web, most made particularly maddening by poorly applying JavaScript in the hopes of driving conversions on some metric. This site ain't it though.
Sure, the first load could include the initial brush of content in its markup. In 2022, this is a trivial change to sprinkle onto a front-end.
The author [1] was somewhat recently featured on Hacker News [2] for their Fishdraw [3] project, if you're wondering why their name might look familiar. Always a treat to see what they come up with next!
The author mentions, “Watch out for HPIB-only plotters!” — I forgot to take that advice when I bought a plotter from a scrap shop a few years back and thought I was completely out of luck. Spent a fair amount of time googling, and I ended up building an HPIB-to-serial bridge using an Arduino to get life out of the machine. Works just fine now! I’ve been meaning to write up how that works in case anyone’s in a similar disposition.
I've seen these warnings before, including from this article from when I read it before, but I'm not sure I understand the aversion of them. From what I understand, HPIB is no different than GPIB, and from what I can tell, USB GPIB controllers aren't that expensive. And controlling something serially over GPIB is really not that different from doing it over RS-232. So if the price is right on a GPIB-based one, I don't see the issue.
HPIB and GPIB are the same thing (IEEE-488 standard), and USB-GPIB interfaces are indeed available. The catch is getting software to talk to the GPIB interface drivers. There are many programs that will send arbitrary data to a virtual serial port, but not as many that can use the GPIB drives. If you're writing the software yourself, it's easy in some languages, such as Python (PyVisa works fine), but in others it might be harder.
Also, I'm not sure if the drivers for the interfaces are available for anything but Windows.
I rarely comment on HN, but I'm happy to come out of the woodwork to second this!
Django was my first exposure to Web development also around the 0.96 days. I couldn't have found my way into what has become a career without the friendly folks in the Django channels. What an incredible resource for newcomers.
I remember pasting full dumps of my models.py files into djangosnippets.org with vague descriptions of problems I was having, and folks I had never met before patiently sorted through possible solutions with me. Sometimes they'd nudge me away from an approach or suggest an alternative framing but they never judged me for what was probably pretty ridiculous code, considering I had no idea what I was doing.
Now that you mention pasting things into #django-dev, one thing that stuck with me was https://dpaste.com/
I think it was more closely branded as a "paste service for django community to use" than it is now, but I keep using it because it just works perfectly, without any captchas, ads, complicated UIs or other unnecessary fluff, the domain name is easy to remember and it's been up every time since around 2007 when I discovered it. Just paste, submit and share the link, and it always works as you expect.
Completely unrelated to maps, but I really enjoyed your talk about the origins of the "else" keyword at !!Con West a few months back! Thanks for picking that topic. Really got me thinking.
Hey! Author here. After talking to folks who have taken on similar projects at their jobs, I realized there wasn't much discussion around how to happily pull off a UI refresh or redesign, and I wanted to share the philosophy we used to make ours a success!
I'm happy to chat and compare notes about how folks have executed similar projects.
I've done some somewhat similar efforts in the past. One thing to point out is that on the something.original.css and something.refreshed.css to avoid code duplication: since y'all were already using LESS as a build process, code duplication shouldn't be a huge problem with LESS importing the original from the refreshed. I found the LESS compiler to be quite good at coalescing complicated overrides of imported base styles to a final, simpler final build output.
Though the last time I did this sort of thing I definitely couldn't have used CSS Variables. That seems like a good solution for modern browsers with or without a compiler like LESS.
That sounds like a reasonable approach! Thanks for the note.
To be honest, we use LESS fairly simply for the things it provides like variables, mixins, and nested selector syntax. We otherwise haven't had a need to make our stylesheets much more sophisticated. So when project planning came around, we didn't ideate much on LESS-based approaches, and I bet we could have and found an ergonomic approach there.
Hey! Author here. After talking to folks who have taken on similar projects at their jobs, I realized there wasn't much discussion around how to happily pull off a UI refresh or redesign, and I wanted to share the philosophy we used to make ours a success. Happy to chat and compare notes about how folks have executed similar projects.
Happy they designed the robot with a replaceable battery! I received an Ollie as a gift back in 2014, and the battery is flat-out dead. Wish I could still fiddle with it.
I’m a bit surprised Sphero is using Kickstarter for this campaign — they’re a large company now with access to plenty of cash, I assume. Pre-orders have usually been a part of their independent product launches (i.e. the products that aren’t Lightning McQueen), so I could see this as an extension of that strategy with a maker/hacker/DIY aesthetic. Crowds out Kickstarter and makes it harder for the smaller operations to get discovered though.
In general (and take this with a grain of salt because I don’t know robots, only familiar with Sphero’s history), I think Sphero accidentally positioned themselves super well for building out products like these. They started with a robot-in-a-ball. Literally a two-wheeled robot driving like a hamster in a ball. In order to support a user-friendly driving experience with the original Sphero, they invested in the accelerometer and gyroscopic sensors and the way they provide feedback to the drive system. So even when the wheels would slip inside the ball, the robot would detect the change in heading and adjust to suit the driver’s original intent. They mention briefly in the video how this RVR bot can hold its heading on bumpy terrain, and I assume that’s the same platform at work. It’s neat to me because this feedback mechanism sounds like the kind of thing that’s hard to patch onto a robotic platform produced at scale and get it right, to the extent that folks won’t bother. They kinda got that one “for free” by validating that folks will buy a ball, and it looks like it’s been a solid platform for other variations on driving robots. (But again, I don’t know much about robots. This could be standard practice for all I know.)
[1] https://tsoa-community.github.io/docs/