jducoeur

My technical blog is very Scala-centric, so not too many of the folks here are interested in it.

But for the programmers in the audience: I just finished posting a long-simmering series of articles about testing Scala services that some of you may find fun. It's somewhat heretical, including premises like:

Unit tests are mostly a waste of time for idiomatic Scala services.
You should focus on "scenario tests", that hammer the APIs and stub all externalities.
100% test coverage is the only meaningful number, and you should get there.
Your code should be designed specifically to be testable, including hooks as needed to expose internal events to the test harness.

Not all of it applies to other languages and situations, but a fair amount of it does. So if you are curious about the topic, give it a read -- I'd love to get some conversation going about the topic, either there or here.

Yesterday was the Scala Love Conference. While it's fresh in my mind, here's a braindump. (Including a bit of compare-and-contrast with NE Scala last month.)

(Note: I was a "track owner" -- basically moderating and managing one of the tracks for three hours -- but wasn't core staff on this one.)

First, the name. Yes, I'm sure that some people will snicker, but it's quite intentional. Scala Love, both as an organization and as a conference, is very determinedly positive. The tracks were named "Joy" and "Happiness"; when the conference filled up, they added a new track named "Harmony". In a time of crisis, keeping a good attitude matters, and I think that helped influence a determinedly friendly and open conference.

The conference was entirely online, of course. We used several technologies:

The presentations were done as Zoom Webinars.
The breakouts and Q&A were done with Zoom Rooms.
The livestream was via Twitch.
Text chat before, during, and after the conference happened in Slack.

I'm increasingly of the opinion that no one system is really much good at all the different modes needed for an online conference. The best experiences, at least for anything serious, usually involve several different systems.

(Heck, even our D&D table has wound up involving Discord, D&D Beyond, Roll20, and Google Meet. Each does one aspect well, so we just combine them all to suit our needs.)

Scala Love 2020 was thrown together astonishingly fast -- as far as I can tell, they started working on it after NE Scala (five weeks and a geologic eon ago). Despite that, they sold out a thousand tickets (limited by the maximum capacity of the Zoom Webinar plan we were on), plus a bunch more folks joining via livestream, pulled together a truly remarkable speaker lineup, and wound up probably being the important conference for this community this year. There are logistics involved in running something like this online, but they can be juggled much faster than for a face-to-face (f2f) conference.

The conference was free, with an optional donation: I'm not sure whether it broke even, but it wouldn't surprise me. So another lesson is that while doing something serious online does cost some money, it is vastly cheaper than a real-world site, catering, A/V and so on typically are.

The conference was pretty much worldwide, officially starting in Central European Time and finishing in Pacific Time -- 14 continuous hours -- with speakers joining us from, I believe, four continents. Since the conference was free, and folks didn't have to travel, that meant that we largely had people joining on their own time and their own dime, rather than requiring their employers to send them. The result was that this was very much an enthusiast's conference, not needing corporate sponsorship and the like.

Having a public livestream was great, and something you can do when you don't need to recoup a ton of money. In practice, it appeared that even a large fraction of the ticket-holders decided to watch via Twitch instead of Zoom, probably because it's much easier if you're mostly just watching. (Anecdotally, we seemed to usually have 30-70 people attending each track via Zoom, and 200-400 on Twitch at any given time.)

An important general observation: audience members like to talk. This is something I've observed at both NE Scala and Scala Love. At a f2f conference, you have to shush the room so that everybody can hear the panelists, but online you have text chat available, and people use that. You wind up with discussions of the topic happening in the background, people asking each other questions, and even just occasional general snark: the result is a lively environment, in a way that you don't get f2f.

NE Scala used Slack for text chat, where Scala Love used to Twitch chat attached to each livestream channel -- IMO, Slack worked better, simply because it's a richer chat environment. (Zoom's own chat feature is notably terrible, not least because you can't see anything that was said before you entered the room.) But I strongly recommend encouraging this, albeit with somebody keeping an eye on it for possible abuse.

The text chat is especially important, since that's where the audience can provide feedback. Lacking the immediacy of applause, both conferences did it via chat. NE Scala officially encouraged emoji-based applause in one of the Slack channels (I found an animated "inclusive clap" multi-skin-tone emoji that worked really nicely); at Scala Love, we mostly had impromptu cheering in the Twitch chat. Either way, it's important for helping the presenters feel appreciated.

Having a moderator overseeing each session is especially important when you are running something like this. They need to do a bunch of things, including:

Help the presenters get their tech set up, do sound checks, and so on.
Pay attention to all the various commentary channels (in this case, Zoom Chat, Zoom Q&A, Twitch Chat and Slack), to see if folks have questions.
Keep an eye on the time.
Generally emcee the session.

One of the really smart innovations at Scala Love was to have breakout rooms, officially assigned to match the webinar rooms. At the end of each presentation, the track owner's job was to shoo everyone -- presenter and audience -- over to the appropriate breakout room. This allowed us to emulate the way that, at a f2f conference, a bunch of people usually want to congregate around the presenters, ask questions, and discuss the subject further. It made the event much more participatory and friendly. And as an added bonus, it got everyone out of the main webinar, so that we could start setting up the next presentation.

These breakout rooms do want, if not moderation per se, at least someone keeping half an eye on each one, making sure everyone plays nice and reminding everyone when the next session is going to start. This takes some people points, but seemed like a good idea.

Since most people aren't used to the tech yet, Scala Love held several practice sessions in advance, and asked all of the track owners and presenters to attend at least one if possible. This was a really good idea, letting us iron out most of the kinks in advance and helping things run well day-of.

Overall, it was impressively great: a solidly good conference by any metric, and an astonishingly good one for a "let's build a barn!" project thrown together in a month. Yes, it didn't have quite the same vibe and hallway chatter of a f2f conference, but it was vastly cheaper and easier to run, just as professional and informative, friendlier and more welcoming than the official ScalaDays conferences that it effectively replaced this year.

The main takeaway is that I think, even when the current crisis is over, online conferences are here to stay, and even f2f ones should be thinking seriously about how to run in a hybrid mode. It loses some things, but it definitely gains others. And it is not crazy-hard, so give it serious consideration...

As of a few minutes ago, NE Scala 2020 wrapped up. There's still some cleanup to do (Ryan and the NYC crew still have 200 t-shirts to mail out), but we seem to have survived the experience. Moreover, it turned out to be a solidly good conference despite the travails of moving all-online at the last minute.

Ryan, the con chair (who did the lion's share of the work) has put together a good debrief here -- I commend it to anyone facing similar challenges. It's a useful proof of concept for folks to learn from.

We were helped by being able to throw some money at it: while we likely aren't going to get full refunds from all of the vendors (some of whom are suddenly facing a bad year), many were willing to give at least some of our money back; in some cases, all of it. So we could afford to, for instance, suddenly set up a reasonably serious Zoom plan for our needs.

We lost some of the social aspect, unsurprisingly -- it's hard for online to substitute for breaking bread in person. But having several Zoom "rooms" open during and after-hours meant that folks could socialize in a reasonably unstructured way, making up for some of that. We also encouraged chatter on Slack, with just a little bit of structure, which also helped.

We've had a focus on Diversity for the past couple of years, and that's starting to pay off, especially on Day Two: we had six women on "stage" across eleven sessions, which is way better than most conferences and starting to look halfway reasonable. We also had a presentation on prejudice and bias on Day One (the Typelevel Summit), and a roundtable on "Bringing Scala to a Diverse Group of Students" on Day Two (NE Scala proper), so the topic itself was given some appropriate focus. It's great to feel like the conference is being a positive force in the industry, in its small way.

And as always, the technical content was excellent -- a wide variety of talks about Scala-related topics, some of them really fun. I'll particularly call out "Functional Error Handling with Cats", which managed to discuss error management in terms of a fairy tale, and "Comonads and the Game of Life", for introducing the wonderful term "Copoetics". I think all of us learned a good deal. Many of the slides can be found at https://nescala.io/#schedule-day-1 and we'll post recordings as soon as they're ready.

Overall, I think it was a solid success: more fun than many events manage, and still one of the highest-quality tech conferences around, despite the challenging circumstances. Questions welcome, if folks are trying to navigate these waters for other gatherings...

ETA: Here's the writeup over on my professional blog.

Today was All Stress, All the Time. Pardon a grouse, but I have to let off some steam because I am vibrating from tension right now.

This Thursday-Saturday is NE Scala: a tiny but really cool Scala conference that is always a highlight of my year. I've been attending for six years, and this time around I'm core concom. (It runs more like a small science-fiction convention than a typical professional conference -- all volunteers, nobody making any money, cheap tickets. I'm going to be con chair next year.)

Of course, this is a craptastic time to be running a conference, and things have been accelerating at truly amazing speeds over the past few days. We've gotten a gradually-building tidal wave of speakers and attendees (and even many of the organizers) who have been asked by their employers not to travel and not to attend conferences for the time being, so we've been scrambling to make live-streaming a solid option. My own company didn't order to me stay home, but some of our other folks did get strongly leaned on to do so.

Just to make things worse, this year's conference is in Brooklyn -- and greater NYC has become one of the major areas of concern, with a part of Westchester declared a "containment zone". Even I started getting a little freaked-out by that.

This afternoon was spent in intense discussion, as we realized that the physical conference was starting to lose viability. Over the course of the day, I found my own opinion swinging from "Of course we're going to tough it out" to "This is starting to look irresponsible".

So we just sent out the announcements, that we're going to do this online-only for this year. We'd already been making the plans for remote participation anyway; now we're just going to focus on that, and make it as good an experience as we can.

Some folks are unhappy (heck, I'm unhappy, and I was one of the people involved in the decision); I think it's the right call, but it truly sucks to have to make it. It's one of those no-win scenarios that you never want to hit when running an event.

Sigh. We'll get through it -- we still have a fabulous lineup of speakers, and I think most folks will roll with the online-only thing. And it'll be a fine testbed for providing good remote access in future years. But I really wish things had waited just one more week to get to this crisis point...

Well, that's kind of neat. Rally Health (my dayjob) just relaunched its company Engineering Blog, with a new article by me.

It's strictly for the programmers, showing how to build a Redis serializer/deserializer using typeclasses in Scala. If you're interested in how programming works in a more modern way, I recommend checking it out -- it's a good illustration of how this technique (which came from Haskell, but is now central to Scala and spreading to other languages) works. Questions more than welcomed here: I enjoy teaching this stuff...

I haven't been posting much lately, because I've been crazy-busy. But I should pause for a moment before bed, and celebrate the little victories:

On Sunday, we held the second ScalaBridge Boston. As the site says,

This workshop is intended to reach out to women, people of color or anyone who identifies as belonging to a group that is underrepresented in tech who is interested in learning Scala.

It's one of those opportunities to be nerdy and socially-helpful at the same time. We had about ten mentors (including me) and about forty students, and it felt like at least many of the students got something out of it. This was a wide range of folks (mostly but not entirely women), including long-time programmers who are trying to stay current with the industry, as well as folks who have never written a line of code in their lives but want to explore a mid-life career change. (I wound up doing a bit of impromptu career counseling in between nerding about programming.)

Overall, I thought it was great: upbeat, fun, collaborative, with just enough structure for the students to choose their path for the day, but allowing everyone to find their own lane. I think we really accomplished something, and I hope we continue doing this at least once a year.

At the other end of the scale, tonight was the latest session of the Boston Area Scala Enthusiasts Meetup. This was an intermediate-level talk, aimed at folks who already know Scala well and want to up their game by getting into some current functional-programming techniques.

I've been in charge of the Meetup since the beginning of the year, and it's starting to feel like it's really working. It had fallen semi-moribund, and I've been slowly reviving it -- this time we got 63 RSVPs and 44 attendees, which is nice and solid for a slightly niche Meetup. Boston has a whole bunch of companies and organizations using Scala, mostly all by their lonesome; I think folks are enjoying getting out of their silos and realizing that there's a larger community out there.

(That said, I'm getting really annoyed with Meetup, which charges an obscene amount of money for a fairly crappy service. I'm increasingly thinking of building my own version in Querki, because seriously: there is nothing hard here. I suspect I can do about as well with about three hours' work, and better with a bit of time and thought.)

Finally, let us light a candle and pray that the MacOS Catalina upgrade that got pushed today solves some of the horrible ways in which 10.15 broke my laptop. So far, it feels like Bluetooth is actually working again, which would be nice: both my keyboard and Magic Trackpad have been responding so slowly for the past few days that it's felt genuinely nightmarish...

No, I haven't been posting much here lately. That's mostly because life has reached a pretty good pinnacle of crazy-busy.

Obviously, Querki continues to dominate my thoughts a lot. The project that we were going to do for Arisia didn't happen this year (since Arisia got Complicated), but has rather suddenly turned much more serious for next year, with a lot more people on board and the system likely because fairly central to Team Arisia.

I just got a new client at my dayjob. (Actually the same client I had for most of last year, but a different group -- last week involved a bit of amusing chaos as they shipped me an underpowered laptop, I pointed out that I needed something beefier, and then they figured out that my old laptop hadn't been wiped yet, and would I like it back?) So I'm in heavy ramp-up there.

After about 18 months of officially being the deputy of the Boston Scala Meetup, the founder finally recognized that he was a bit burned out, and he formally handed that off to me. So I ran a small survey of the community there, created a new Slack group as a result (and am now trying to get people to actually use it), and am starting to work out this year's Meetup schedule.

And today's new fun? I've had a talk accepted at a conference for the first time!

For all that I've been teaching Stuff (SCA dance most notably) for decades, and have been teaching Scala and presenting at Unconferences for several years now, I've never really done the conference circuit before about four years ago, and I've never done a talk before.

In this case, it's the Typelevel Summit, so I've dived into the deep end here. NE Scala is my "home" conference, a joint production of the Boston, New York and Philadelphia Scala Meetups -- this year is in Philly. But it's really three conferences joined at the hip: the Typelevel Summit, NE Scala proper, and the Unconference. The Summit is in some ways the bigtime: a gathering of the Scala-functional-programming hardcore, members of a growing group that encourages and collaborates on FP-centric Scala libraries. It includes a lot of the heavy hitters of the Scala world.

So I'm a tad intimidated, but also rather excited. My talk is specifically intro-level, and is about my own journey to finally building a pure-FP system for the first time -- in this case, Querki's new API-level test harness. The resulting code is some of the prettiest I've ever written, so I'm going to burble a bit about how that code evolved, and show off the relevant FP concepts that make it possible.

All of which goes to explain why I haven't had a lot to say about SCA, Fandom and stuff like this -- right at the moment, programming is dominating my brain, so I've mostly been posting over in my professional blog, which has wound up very Scala 3-centric for now. But I'll try to find some time to at least diarize and do some reviews here...

I was just reminded that I've never shared publicly the document of Useful Scala Resources that I put together for Scalabridge a few months ago. Here it is, if anybody is interested.

Note that this is just an outline, but it's an outline with a considerable amount packed into a few pages. If anybody's interested in more info, I'm always happy to chat about this stuff...

For the programmers: I've just published an article illustrating some of the new features coming to Scala.

(For programmers only.)

Over in my Scala blog, I've got a writeup on my understanding of the "transparent" keyword that has been proposed for Scala 3. Programming-language geeks might want to take a look; feel free to ask questions here...

Following up on this: the first release of Accessible Scala is out. This is a Scala plugin for screen readers that reads out the code semantically, instead of literally, to make it possible to actually follow it. The linked webpage has links, including a link to an online demo. (The voice for the demo is terrible, but it's a wonder the bear dances at all.)

I'm sure it needs a good deal more TLC before it's really good for the purpose (and the project needs help providing integrations), but it's an excellent step forward, and I'm proud to see the Scala Center driving this forward.

Just a quick shout-out to the Scala Center -- the group that shepherds the Scala language -- for their new accessibility initiative. They're exploring how to get the compiler working in a usable way with screenreaders, so that sight-impaired folks can actually make use of it.

(See the linked article and the SCP behind it for a bit more info, but the heart of the point is that literally rendering Scala code to speech produces nigh-incomprehensible results. So they're starting to study how to express the concepts in a way that can be understood through speech.)

For the relatively serious programmers, I commend the article Asynchronous Programming and Scala. It's somewhat dense stuff, and as written is entirely in Scala, but the principles are pretty generic. It's all about how to think about asynchronous programming, and makes some important high points:

Asynchrony is not the same thing as Parallelism, although they are closely related.
Callbacks are a wretched way to deal with async, since they don't really compose. (I have learned this one through much pain.)
Futures and Promises are less wretched, but still problematic.
If you really want to do this stuff right, proper functional-programming techniques rock.

Of course, this is largely a rationale and advertisement for the Monix Library, which is a more or less state of the art library for "doing it right" -- but it's a pretty compelling rationale.

None of this is easy: he's summarizing stuff that's taken me four years to really internalize. (One of my medium-term but relatively challenging goals is to rewrite the pipeline for the QL language inside Querki from being Future-centric to Monix-centric: the result would be vastly more efficient and reliable.)

But it's important material, especially if you're designing systems. I encourage you to read and absorb it. Feel free to ask me "what the heck is that bit talking about?" questions, or even questions about the syntax and functions in the examples -- I always enjoy burbling about programming in general and Scala in particular...

[Continuing the previous story, basically. Again, only interesting to the Scala-using crowd. None of this is rocket science, but since I had to piece it all together from scattered info I might as well post it. Note that this is stream-of-consciousness notes, as I develop this test harness.]

Next step: can we run our browser-based functional tests "headless"? This is awfully useful: Selenium is great, but it is *very* distracting to have a browser window suddenly pop up in front of you and start doing things by itself. (And that simply won't work in a truly headless environment, such as an automated test server.)

Fortunately, this also proves to be easy, if poorly-documented. This answer on SO works perfectly fine for ScalaTest + Play. The key is the useful little program xvfb -- the X Virtual Frame Buffer. Basically, it's a program that lets you set up a "virtual" window that doesn't actually exist, which you can then point your tests at.

So first, you need to install xvfb, which on Ubuntu is:

sudo apt-get install xvfb

Then you run it, like this:

Xvfb :1 -screen 5 1280x1024x8 &

(Note the capital "X" in Xvfb.) That is, run a virtual screen in the background (that "&" at the end), creating display number 1 and screen number 5, with the specified virtual resolution. That kicks the screen off as a background process (you can find it with "ps").

Finally, say this:

export DISPLAY=:1.5

This tells the processes in this shell that, if they're trying to show something in X, they should use display 1, screen 5 -- your new virtual screen.

Now you can run sbt and your ScalaTest + Play functional tests as documented. The browser will start and run as directed, but you won't see anything, since the "display" is all going to xvfb's bit-bucket.

A nice side-effect of this approach is that the xvfb stuff is completely external to your test. You can write this into your standard shell environment for normal use, but you can also turn it off when things are going wrong, or if you simply want to be able to observe the proceedings while you are coding up your tests.

[Very Typesafe-stack-specific, but having spent the time figuring it out...]

Nothing to brighten my day than managing to solve what briefly looked like an intractable problem.

I'm trying to get full-stack functional tests running for Querki. (Not before time, I know.) To do this, I'm using ScalaTest + Play, which seems to be the approved solution. This is built on top of Selenium, the long-standing standard toolset for driving a browser for testing.

Problem was, when I wrote my first trivial test, ScalaTest refused to run it, claiming "Was unable to create a Selenium ChromeDriver on this platform". This was mysterious -- I have Chrome installed on this (Ubuntu) machine, and it works fine. A brief round with Typesafe suggested that the problem might be my X windows setup, which was a tad depressing, but I decided to get stubborn, rip the lid off the code and see what was actually going on.

It turns out, if you look at the relevant code in scalatestplus-play, that ScalaTest is intentionally flattening all exceptions from Selenium's ChromeDriver into a simple "that doesn't work here" cancellation. This is useful -- it's how you can write an all-browsers test suite in ScalaTest, and have it just quietly suppress the ones that don't make sense on this platform (eg, trying to run an Internet Explorer test on Ubuntu, or a Safari test on Windows). But it also loses what turn out to be some extremely helpful and informative exceptions that are raised by ChromeDriver.

So I added and ran this pseudo-test:

class DriverTests
  extends WordSpec
  with Matchers
  with ChromeFactory
{
  "I should be able to get a decent error" in {
    import org.openqa.selenium.chrome.ChromeDriver
    new ChromeDriver()
  }
}

That gave me what I was looking for: the actual exception was

[info]   java.lang.IllegalStateException: The path to the driver executable must be set by the webdriver.chrome.driver system property; for more information, see http://code.google.com/p/selenium/wiki/ChromeDriver. The latest version can be downloaded from http://chromedriver.storage.googleapis.com/index.html
[info]   at com.google.common.base.Preconditions.checkState(Preconditions.java:200)
[info]   at org.openqa.selenium.remote.service.DriverService.findExecutable(DriverService.java:105)
[info]   at org.openqa.selenium.chrome.ChromeDriverService.createDefaultService(ChromeDriverService.java:75)

It turns out that, as it says, you need to manually download the relevant native drivers, install them, and point to them. Oddly, I haven't found this documented anywhere.

Anyway, fixing that produced *another* helpful exception, telling me that ChromeDriver required Chrome >= version 46, and mine was too old. I updated that, and *poof* -- it all works.

So: if you are having trouble getting ScalaTest's browser drivers working, I recommend the above little pseudo-test, so you actually get the underlying exceptions. And note that you need those drivers...

For those who might be interested, I'm giving a talk next Wednesday at the Boston Scala Meetup, titled "End-to-End Scala: a Case Study in Integrating Akka, Play, Scala and Scala.js". It's going to be a fast dive into Querki's architecture and code, using that to illustrate how you can use the modern Scala ecosystem to build an entire huge application in a single language, with the front end, back end and APIs all written in pure Scala, within a minimum of boilerplate in the middle.

If you're at all interested in this stuff, I commend it to you. IMO, it illustrates one of Scala's "killer apps" -- the fact that I can add a new entry point to the system in *minutes*, fully reliable and type-checked, even with strongly-typed Exception propagation from the back all the way to the UI with essentially no hand-coded translation layers. It's amazing stuff, and lets me develop faster that I've been able to in any other environment, while still working more or less natively in the JVM on one end and JavaScript/DOM on the other.

And hey -- there's free pizza. What's not to love? Hope some of you can join us...

[For the programmers, particularly for the architects.]

One of the trends that has happened so fast that I suspect most folks haven't even noticed it yet is the sea change that is occurring in Big Data processing right now. The short version is that, relatively recently, some folks from the Scala world pointed out that while Hadoop is a lot better than traditional RDBMS methods for dealing with data at scale, it still kind of sucks for many use cases. So a project got started to rethink the approach to Big Data around a streaming model. That became Apache Spark, and it is taking over the world with remarkable speed.

TypeSafe has posted a blog entry summarizing the benefits of Spark: it's fairly brief, and worth reading if you have any scaled-data requirements, to understand the strengths of the system. It includes a very concise tl;dr summary at the end. (Note, though, that it is written by Dean Wampler, who isn't exactly objective: his talk at NE Scala a few weeks ago kind of bragged about his self-described trolling of the Hadoop community getting the ball rolling in the first place.)

Querki isn't using this stuff *yet*, and probably won't for a year yet -- I have to focus on more critical-path issues for now. But I suspect I'll be adopting Spark before long, for things like automatic abuse catching. (I already know some of the obvious ways that wikispammers are going to try to game Querki, and a combination of event stream and graph analysis is probably going to be helpful to tame that.) And one of Querki's most game-changing features, App Communities, is going to be all about what happens when you combine Querki with Big Data. I suspect that almost any large-scale JVM-based system is likely to find this stuff useful in some fashion...

[I really need a Scala icon for these posts.]

I'm going to start pushing a lot of my case-study posts, talking about Scala in the context of Querki, over to the Querki Development Journal. Today's post is one of those. It is *very* Scala.js-specific, but kind of insanely cool regardless. The tl;dr is that I spent today figuring out how, when doing a client/server RPC call, to throw an Exception in my server-side Scala code, and catch it in my client-side Scala code, with no boilerplate.

Being able to do end-to-end strongly-typed programming was cool enough to begin with; being able to throw strongly-typed Exceptions across that boundary is kind of fabulous. Every day that I work with Scala.js, I'm loving it more...

One of the things I learned about myself many years ago is that, if and only if I believe in something to the tips of my toes, I am a really great salesman. That is, if I am truly, passionately enthusiastic about a subject, I am really good at communicating that enthusiasm.

So the primary lesson of the day is that, somewhere along the line, I became a Scala.js true believer.

Yesterday and today were the Northeast Scala Symposium. It was my first Scala conference, and a total blast: I learned a lot, and got to know more folks in the Scala community, including quite a number of folks who I've been reading and chatting with online.

Today was the "unconference": three tracks of smaller sessions, planned semi-spontaneously this morning. I wound up delivering one of the last sessions of the day -- I took the 75 minute presentation that I gave at the Boston Scala Meetup a few months ago, compressed it to an intense 30-minute speed through the slides, added a few nicely controversial assertions about where the ecosystem should evolve, and managed to spark half an hour of lively Q&A -- with not a little argument about my projections. I deliberately over-simplified the assertion (hence the argument), but stand by the heart of my point: that between Scala.js, Autowire and akka-http, I'm starting to want a web framework that is simply about client/server Scala programming, and mostly treats HTTP as a configuration detail.

Anyway, it was totally great: I'm still buzzed enough to be vibrating. (Admittedly, partly due to quite a bit of pre-presentation caffeine.) I definitely miss that; I suspect I need to seek out more opportunities to burble like that...

I've burbled here about Scala.js, the increasingly-mature Scala-to-Javascript compiler that I am currently rewriting Querki in. (And I owe a writeup of my rant on the subject from a couple of weeks ago.)

One thing that Scala.js has lacked heretofore is a really solid *book*. There's a decent tutorial and a bunch of other useful information on the main website, and a growing body of community knowledge, but getting started looks a bit daunting, which is unfortunate: it's not actually a terribly hard technology to get started on, especially if you already know some Scala.

To help with that, Li Haoyi (one of the primary library-authors for Scala.js) today released a draft of Hands-on Scala.js, an online book aimed right at this problem. I'm just starting to read it myself, but at a quick skim it looks like just what the community needed. It starts off assuming only a fairly modest knowledge of Scala, Javascript and web development, and walks you through the rest: the rationale for using Scala.js, how to set up an environment, tutorials for various kinds of webby applications, and a final chapter going into depth on various major Scala.js topics.

As these sorts of books go it's pretty short (not having a publisher pushing up the page count helps), but it's still a book rather than an article: expect to take a while going through it. And please note that this a draft, albeit a late one: it's akin to a late-stage MEAP, so don't be surprised by an occasional typo.

Recommended reading to anyone who wants to keep their skills sharp and is interested in Web programming. IMO, Scala.js is one of the most important parts of the Scala ecosystem, and very much a tool whose time has come. Having a good guide for getting started in it should only make that better...

S	M	T	W	T	F	S
		1	2	3	4	5
6	7	8	9	10	11	12
13	14	15	16	17	18	19
20	21	22	23	24	25	26
27	28	29	30	31

A Philosophy of Testing

Scala Love Conference Debrief

Mischief Managed

Yeah, the current environment is getting tough...

Let's Build a Codec!

Little Wins (all tech edition)

Still finding new ways to get myself in a little over my head...

Useful Scala Resources

Let's unpack some (proposed) Scala 3

The proposed "transparent" keyword in Scala

Accessible Scala

Accessible Programming

Asynchronous Programming and Scala

Running headless browser tests using ScalaTest

Getting Chrome working under ScalaTest

Presentation by me -- End-to-End Scala: A Case Study

Big Data, Scala and Spark

Enabling strongly-typed Exceptions with Autowire

Man, that was fun; or, lessons from a conference session

Hands-on Scala.js

Profile

July 2025

Syndicate

Most Popular Tags

Page Summary

Active Entries

Style Credit

Expand Cut Tags