While on a literal years-long journey to understanding REST, I happened upon RDF and the semantic web. What a load of crock.

I was absolutely ecstatic when I learned about the semantic web and the idea of having a world-wide machine-readable standard for data, only to realize it had to be tacked onto the current stack of web technology. When was the last time you saw any popular website expose a schema.org web page, or a Hydra endpoint?

The web is an endless morass of ad-hoc RPC endpoints, with nothing governing how you can interact with it, unless they happen to adhere to some bullshit Gooogle standard to enhance SEO.

  • WorkingClassOilBaron [they/them]
    ·
    4 years ago

    The web is an endless morass of ad-hoc RPC endpoints, with nothing governing how you can interact with it, unless they happen to adhere to some bullshit Gooogle standard to enhance SEO.

    As always, the profitable is the enemy of the good.

  • buh [she/her]
    ·
    4 years ago

    Just go into firmware, there’s still all kinds of vendor specific crap but C89 compliance is pretty much guaranteed

      • buh [she/her]
        ·
        edit-2
        4 years ago

        Get an arduino and an electronics kit and make some projects (start with an LED flashing, maybe something that reads from a sensor over ADC or one that has an interface like SPI or I2C and prints the value to an LCD). once you're comfortable with it, get a more advanced MCU dev board, one that lets you interact with the peripherals directly via the registers, and make even more complex projects (for example, a robot controlled over bluetooth or wifi with a smartphone app, or if you want to be super fancy, one steered by a raspberry pi with a camera and computer vision). it might seem stupid at first to intentionally switch to a more cumbersome way of doing things, but it will be very difficult to get a job with only arduino experience, arduinos and similar things aren't used for mass produced commercial products for good reasons (cost, available features, performance). Most people recommend an STM32 kit, I don't have experience with it but all those people can't be wrong. There's also the ESP32 if you want something with built in wifi and bluetooth, which can be set up with the GNU toolchain. The one I've used personally is the MSP430 launchpad, which is good but kind of barebones compared to the other two.

        parallel to that, get really comfortable with C, to the point where you can look at some code and at least vaguely predict what the disassembly will look like and what the memory will look like as it is operated on by code. also (I'm guessing you won't have this problem but it's worth mentioning for others reading), it's worth learning higher level stuff too, like python for automating tests on devices, or app development because some places want someone who can also make the app that interfaces with the embedded devices you make.

          • buh [she/her]
            ·
            4 years ago

            It sounds like you already have a pretty good background. As far as skills go, it varies among companies and even among different jobs in the same company, but broadly I would say they're looking for people who are good with C, can write optimal and robust code, and know how to write code to operate the most common peripherals on a microcontroller (UART, I2C, SPI, DMA, ADC, timers, GPIO), as well as being able to diagnose and fix issues with interrupts, race conditions, and memory. Some companies also look for people with knowledge of protocols like USB, CAN, ethernet, wifi, the TCP/IP stack, the bluetooth stack, or things like sensors and motor control, but I wouldn't worry about trying to learn anything specific, just focus on making projects that employ a decent variety of technologies. I would say a good litmus test for being "employable" would be if you can be given a microcontroller, the datasheet for it, and a minimal template project (a Makefile, main.c with nothing in main(), and a header file that #defines the registers and important bit masks and sets up the interrupt table) and build it up into a moderately complex project with little external help.

            As far as places to work, I wouldn't try to think of it in terms of best cities or regions since embedded software isn't an end in itself but a means to an end, which doesn't lend itself to clustering in certain areas the way jobs like web development or finance has. Just think of what kinds of projects you want to work on, find some companies you are willing to work for who build that, and apply to them. There's probably something in your area right now if you look. If you really insist on pinning down the best areas for job quantity and pay, I'd say go for the Bay Area, Austin, and Seattle. There's also a few areas with niches, like Pittsburgh for robotics, or DC for the "defense" industry.

  • mayor_pete_buttigieg [she/her]
    ·
    4 years ago

    The web is an endless morass of ad-hoc RPC endpoints, with nothing governing how you can interact with it

    Maybe this isn't such a bad thing.