@alterationx10.com
Scala enthusiast. Expert mispeller of things. Things I will likely ramble about: Working on a zero-dependency framework for fun at https://github.com/wishingtreedev/branch and building fun, simple apps with it at https://github.com/wishingtreedev
I’ve had great success lately, and with agent tools that incorporate feedback automatically (like compiler warnings, failures). Personally, I think it’s at a turning point now that more focus is being put on development workflows, than chatting about one source file in particular, etc…
Scala code
I had been struggling to find the right incantation to automatically make a literal union type from the fields of a case class in #Scala, but I finally worked it out!
@rockthejvm.bsky.social has released the #Scala macro/metaprogramming course! t.co/JSzxkOWPmM
Very excited for scalafix integration in scala-cli!
Thanks!
The #Scala dogfooding of my library has come full circle! From the library, I used my CLI and Mustache template engine modules to build a markdown based static site generator tool (named blarg)- and now I have replaced mdbook with it for the projects documentation site! branch.wishingtree.dev
Wrote a GitHub action for #Scala cli to check for dependency updates, open a PR if there are changes, run the tests, and auto merge/close the PR if the tests pass/fail. (easy to disable the latter, if you just want it to open a PR).
github.com/wishingtreed...
Finally stopped being lazy, and updated my handle here to my domain name.
In other news, did you know that if you use the GITHUB_TOKEN, your action to create a PR on dependency updates can't trigger the action to run (on: pull_request) PR tests?
Working on a #Scala Mustache template engine, and I *really* enjoy that I can load up the official spec files, and loop through the tests without writing them out.
It also helped me find a couple issues in my JSON library 😅
Oh, that will be nice! At work that's definitely a feature we use all the time (via tapir).
Very cool! You have some very nice examples and documentation as well!
I built a layer over top of the java httpserver in my framework github.com/wishingtreed... (it's the spider package/module). The code for this app is here github.com/wishingtreed...
Still having fun with my zero-dependency #Scala library - I built + deployed my first app with it! It's a good-habit bingo-sticker chart game for kids habit.wishingtree.app Not much much visual style on it yet, but it's a start! Storage is SQLite, frontend is pico css + htmx , deployed on fly.io
I mean, it makes plenty of sense, given how everything else is distributed in the ecosystem. Maybe I feel like my small apps aren't worthy of the eternity of maven central 😆
😁 I'm going all-in on scala-cli , but even I don't want to pass args through `scala-cli run` all the time. I think the default `scala-cli package` command will even download a JVM, but I could be remembering that wrong - perhaps it will download the appropriate JVM assuming one is already installed.
I was thinking this could be a good option as well, but I think that still requires publishing an artifact to central / some repository - which I don’t want to do for an app (but that’s just me, haha). Also, making sure users have/use coursier is one more hoop to jump through 🤔
In this context, probably cli apps with no gui. I’ll be deploying things with gui as web apps, and libraries via central. I don’t imagine I’ll have many users anytime soon (or ever 😁), but I believe in lowering the barrier to entry. That’s why I’m leaning to prebuilt apps on GitHub releases.
Wondering what's the least effort I should put into making it easy to install #Scala applications built with scala-cli. As a user, would you 1. Download it from GitHub and build it yourself 2. download a pre-built thing from GitHub releases page 3. install from homebrew
Laziness for sure.
Very neat!
That’s certainly nice, though I feel like they are doing a disservice to the project by prefacing “it’s not a build tool” every place they make something 10x easier than sbt. It’s ok to switch tools when the time is right, and starting with “but probably just use sbt” isn’t going to drive adoption.
I agree, but doing less with more can often expand your view on simplifying things and focusing on what matters (at the time). Perspective is more important than where the code lives for a short while, imo. scala-cli may be the most powerful “not a build tool” out there 🤣
They do not! (Or should not - I’d switch back if they did). Scala-cli also has a neat directive where you can identify a file as only being for test scope, which makes building reusable test components easier.
I'm trying a new #Scala code base layout by keeping test and source files together (Thanks, scala-cli!). Maybe it's the novelty, but I think I like this set up - would you ever re-locate your tests in your Scala project?x
We're looking for a Scala Developer — join our amazing team! Fully remote.
whisk.bamboohr.com/careers/103
Very cool article! That’s a very nice summary of novice to master. This is also a handy book, and the chapters are free online www.dspguide.com
I'm working on a simple #Scala Actor System for my no-dependency framework project this weekend. It's coming along better than I expected 😆 I built some cool stuff a decade ago with Akka, and have loved the Actor model ever since. What cool Actor things have you built in Scala?
A eurorack system from ALM with lots of patch cables routed
Was tempted to get a new M4 MacBook, but then found out ALM just dropped a new system!
Woohoo! More #Scala people have joined the 🦋! A ~month ago, I thought it'd be fun to make a zero-dependency Scala framework (I'm sure it will only ever be used by me, haha), and have been having a blast re-inventing wheels! github.com/wishingtreed... What fun #Scala things have you been working on?
Oh, I didn't realize it was something you were working on building! Very cool! So much fun stuff to learn where software meets the hardware.