This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2024-04-20
Channels
- # announcements (4)
- # babashka (10)
- # beginners (8)
- # calva (13)
- # cherry (20)
- # cider (9)
- # clojure (11)
- # clojure-austin (2)
- # clojure-europe (3)
- # clojure-norway (3)
- # clojurescript (1)
- # datomic (5)
- # dev-tooling (9)
- # fulcro (5)
- # hyperfiddle (5)
- # instaparse (1)
- # lingy (1)
- # malli (21)
- # matrix (1)
- # missionary (9)
- # off-topic (12)
- # releases (2)
- # ring-swagger (8)
- # scittle (9)
- # shadow-cljs (20)
Anyone still playing around ulisp in 2024? Is it worth to give it a try for simple hardware projects? I'm planning to have a network of simple sensors like temperature, light and alike and i need to a have a simple but reliable way of tracking them. Was thinking of doing my first run with some newer and fancier esp32 prototyping boards that have the risc-v chip on them ...
If you are not familiar with micropython/circuitpython I would check it out before prototyping with anything else. It is very high level and let's you program mcus via saving python files to a USB drive. It feels like cheating. I started my sensor network with pi zero ws coding in common lisp (sbcl), and then moved on to afafruit itsbitsys with a ble radio using circuitpython, and the most recent sensor is a pi pico with a lora radio also running circuitpython.
I'd suggest checking out https://platformio.org/ for small chip projects.
Someone has at least done ulisp+platformio for ESP32s. I want to check that out someday soon to see if I can apply it to some of my projects. https://github.com/ahmetus/esp32-ulisp-with-platformio
I wonder if it'd be possible to get ulisp running on my C128...
> If you are human middleware on the cloud here is some advice: > 1. The best thing you can do is learn basic corporate finance. Low interest rates likely created your job, or at the very least they created the premium on your compensation. Many people who have only ever worked as human middleware on the cloud in their careers have been spoiled by the longest bull market in modern history, and now that times are tight you may want to start understanding how businesses actually operate. It will pay dividends far greater than learning a new language or reading another sea of database documentation. > 2. The next best thing you can do is ignore any influencer trying to sell you some new shiny object to try out and install. Influencers are used for bottoms-up selling, to generate FOMO, and to use you as the product so vendors can pump their Github Stars/install numbers/whatever other growth metric they need in the absence of revenue. They then trade this for valuation increases and in some cases, these founders then trade these valuation markups for cash via secondaries they sell. They can make millions while you struggle to glue their product together along everyone else in whatever “community” you are in. You take the risk, you do this on the balance sheet of your employer, and someone else gets the benefit. Bottoms-up selling to human middleware is going to die down for a bit. Purchasing decisions are going to be going through executives for the near future. > 3. Get to meaningful business value creation ASAP. Do not make excuses about how your boss does this or how you don’t care. This is your career. If you can’t have meaningful conversations about business value with your boss or department leaders or perhaps even with the executive team, then you are in the wrong place or you need to learn how to manage communications better. > When times are tight the ‘I don’t know, I just work here’ guy is the first to go. Don’t be that guy. Know the difference between ant traps and Tupperware. https://medium.com/@laurengreerbalik/against-config-as-a-lifestyle-c6f630d96734
extremely grateful to have written <50 lines of YAML in nearly three years at my current job
on a serious note, I actually find this to be an extremely debatable claim: > When a data engineer has to spend a disproportionate amount of time configuring connectivity among an increasing number of SaaS applications and infrastructure, that person becomes increasingly distant from a P&L outcome at her organization. Instead, she either has to start patching workarounds or she has to open tickets or issues with these vendors or open source projects, and then spend extra time in config land. Arguably, a big part of a SRE position or "Cloud Engineer" position involves exactly this. A skilled person in this role is frequently expected to bring in cost savings to the organization that are more than 10 or 20x their salary. There's undoubtedly plenty of pointless config, but the ability to see the important friction that exists between "an increasing number of SaaS applications and infrastructure" can be extremely valuable, especially in the macroeconomic context that Balik mentions in this article. Of course, this is presuming that the "human middleware" is in a position to do something about that friction - which of course involves those conversations about business strategy she emphasizes.
mentally replacing every "Developer Advocate" or "Developer Relations" job title I see with "Platform Influencer" is also good advice that I took away from this article
There's a great irony here in that many "angry"/earnest software types who write on Medium etc are, by definition, influencers trying to tell you how to do your job 😉
I find it peculiar that writing YAML configs instead of code can also be rationalized as "it's just data" and "declarative is better than imperative".
Not that I reject this Clojure value prop, but there is a tipping point where "declarative" and "just data" turns into writing programs with extra steps, hostile language, and worse tooling. Obligatory read: https://mikehadlow.blogspot.com/2012/05/configuration-complexity-clock.html