Hackaday Podcast 068: Picky Feeders, Slaggy Tables, Wheelie Droids, And Janky Batteries

Hackaday editors Elliot Williams and Mike Szczys ride the rails of hackerdom, exploring the sweetest hacks of the past week. There’s a dead simple component feeder for a pick and place (or any bench that hand-stuffs SMD), batteries for any accomplished mixologist, and a droid build that’s every bit as cool as its Star Wars origins. Plus we gab about obsolescence in the auto industry, fawn over a frugal microcontroller, and ogle some old iron.

Direct download (~60 MB)

Places to follow Hackaday podcasts:

Episode 068 Show Notes:

New This Week:

Interesting Hacks of the Week:

Quick Hacks:

Can’t-Miss Articles:

2 thoughts on “Hackaday Podcast 068: Picky Feeders, Slaggy Tables, Wheelie Droids, And Janky Batteries

  1. Mike & Elliot, if you have a zoom link to the recorded session, please post it!

    Shelter-In-Place virtual conference MakerFaire sessions really showcase the software state-of-the-art. True to life, if you aren’t there at 11am on the dot, sorry you weren’t there and you lose. People who used youtube or facebook live streaming get to watch afterwards, or the parts missed. People who use zoom or meet.google are the crowd that didn’t have a ticket or couldn’t get past the bouncer. We all should slam zoom and google for making it really hard to hold recorded events for anytime viewing. I know for zoom at least it’s possible, but then when you go to the links it says “Waiting for the host to let you in” on an event that’s past– you need a special link and maybe password.

    While trying to participate at MakerFaire, sometimes the schedule shows all sessions, sometimes not. I waited for the end, and now I get an infinite loop spinner, “Please Wait While We Load Your Virtually Maker Faire Experience”. (Ithat is my makerfaire experience). Having a simple static html page would have been really fast and efficient, but no, they have to do an ajax javascript app that is full of bugs and slow painful experience. Now I get nothing for the schedule.

    COVID-19 seems to highlight just how good the video communications is now, but also how really bad it is at usability, at least if you try to hit the pause or access at an alternative time. The sites don’t even respond with a reasonable message if the event is over (on Google or Zoom), just a bug.

    COVID also seemed to highlight the reason why web 4.0 (or whatever it is these days with Angular/React/jquery javascript data viewiers) is fundamentally off course. I tried to view health stats from Santa Clara County (Silicon Valley) at https://www.sccgov.org/sites/covid19/Pages/dashboard.aspx

    A new record in dysfunctional UX. I only have a 6Mb DSL FTTN link, I used the network debug to benchmark a one-page stats at 53.83MB/11.97MB transfer, 8.93min to finish loading (that’s right 9 Minutes!) What took the longest was just getting a few numbers displayed (totals came after graphs). The base DOM loaded in 19.69s and page load was 51.52s, then spinners were shown for the next 8 minutes. I suppose it was “real-time” but data only gets updated once a day.

    How could anything think this is a good idea? Download 50MB of javascript and wait 9 minutes to render? The county needs to give info to a few million people, of which maybe only 100K might try to view, But why download 12MB to 100K users when you could download 100-1000X faster for exactly the same appearance. I doubt 100K waited like me. (At first I just let it load in another tab while watching a youtube video, then I decided to measure it.)

    In good old web 1.0, they would have updated the text in a static web page once per day, and pasted in a GIF (not PNG) for the graphs. People on a 56Kb modem would have been able to view in a few seconds. Now, we have to download complex viewer javascript with ajax DB access, all to get data that changes less than once per day. On the day I tried an access, the updated data hadn’t arrived, so was still the prior days data.

    Sorry for the ramble, but web X.0 seems to be such a major downgrade, and especially front end developers have lost sense of practicality and mission. For Google and Zoom front end developers– please add a check to see if the even is over before telling the user they are waiting for the event to start.

    There were lots of sessions on people building masks etc. for COVID, but if I’d known, I would have built a web 1.0 downgrade app to convert the county web site page to render in 2sec instead of 10 minutes. We needed the COBOL cowboys to help old government systems deal with unemployment filing apps. So now we need the C/Perl cowboys to help save governments from the new millenial-designed javacripit web apps?

    1. The reason is that when you have a week to implement something, you just throw the entire toolbox at it because you don’t have the time to build the minimum solution from the ground up. It takes too long to pare down the stuff to the bare essentials that you actually need.

      Everything has to be done yesterday and it has to cost nothing, so the solutions look like this:

      https://s3.amazonaws.com/images.gearjunkie.com/uploads/2013/10/largest-multi-tool.jpg

      Won’t fit your pocket, works very poorly, but it does have the right blade for that job.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.