Finally got around to making a (slightly) cleaner UI for creating new cells in #Vizier . Organization is now by data lifecycle stage, and the more commonly-used operations have nice visually distinct icons.
Getting Vizier to run #Python 2.x code again is likely going to be an unmaintainable mess, so this can't be as cool as I hoped to make it. Still, behold what has been wrought: A #Reproducible multi-environment #Notebook ! #Vizier #Programming
#programming #Vizier #notebook #reproducible #python
Slow going on the UX front for #vizier 's #python #reproducible environments. Not much looks changed since my last post, but a lot of the backend goop for managing environments is now hooked up. Spent a disproportionate fraction of today on technical debt: I finally implemented an #akka exception handler and corresponding error notification toast in the UX. Package installs would benefit from a streaming websocket, but that'll have to come later. Next: Making python cells use environments.
#akka #reproducible #python #Vizier
Got a bit of time over the weekend to hack on the UI for #vizier 's new reproducible #python environments feature. Finding the right tradeoff between performance and usability was a real pain, but I think we've hit on a viable versioned dependency management solution. The UX is gradually becoming progressively less rough around the edges... another few days of hacking and I think I'll be ready to call it done.
This is all in the profile, but... Hi, I'm a CS prof, focusing on #databases, #datastructures (https://github.com/UBOdin/jitd-synthesis), and #reproducibility in data science (#mimir : https://mimirdb.info and #vizier : https://vizierdb.info). I occasionally find time to dabble in wildlife and landscape #photography, #home / #homeautomation hacking projects, and #hema / #fencing (I swear I will get through Cappo Ferro one of these days). I also #pun
#pun #fencing #hema #homeautomation #home #photography #Vizier #mimir #reproducibility #datastructures #databases
#vizier 's server is now backed by akka-http rather than Jetty. Getting out of the jetty API mix and match dependency hell is welcome. I'm torn on akka-http's directive-based routing scheme. On the one hand, it is **really** slick how composable routes directives are. On the other hand, it tries to be a little too clever with the typesystem, making error messages a pain to debug. It also doesn't help that there's not a clear pointer to the `extract` directives.
Been fiddling around with akka-http for #vizier and it really strikes me how much of the Scala ecosystem is enamored of Scala's "build a DSL inside the language" capabilities. Scala has DSLs for everything... from reactive programming, to request routing, to build tools. Unfortunately, these DSLs have a tendency to leak implementation details through e.g., error messages, or crazy contortions needed to work around a DSL construct that Scala can't implement.
Finally tracked down a persnickety (and very bad) bug in #Vizier (https://github.com/VizierDB/vizier-scala/issues/196). In general, I love working with reactive frameworks, but when the abstraction breaks, it breaks hard. With the possible exception of Airstream (which I sadly learned of too late), reactive frameworks have no concept of collections with fine-grained deltas (insert, delete, update), nor any way for the user to declaratively provide finer-grained deltas for specific reactive types.
After about three weeks of optimizing startup times in #vizier and making minimal apparent progress, I just happened to rerun a giant 100-cell notebook I'm using for work data vis. Normally this is a terrifying experience, shutting down my ability to do anything for a good minute. Optimization payoff: By the time I realized what had happened, the notebook was done running.
#Vizier 1.1.0 released. Improved support for frozen cells, and a few new cell types, as well as laying the groundwork for Jupyter import functionality.
https://github.com/VizierDB/vizier-scala/releases/tag/v1.1.0
https://www.vizierdb.info