1. 1

    I really like that there is support for pie/radial menus and it’s demonstrated in the README.

    1. 10

      Or you might just use for example a ClojureScript wrapper for React, which simplifies usage quite a bit (taking advantage of the immutable persistent data structures for automatic and efficient diffing), enjoy all the benefits of Google Closure, have a single build tool (for back & frontend if you use Clojure on the server side), and be done.

      Honestly though, I’m not sure if it’s a great idea to advocate for vanilla JS. Sure, if all you want to do is register some click handler to send an XHR or make the background change color based on the time of day – basically the little bits of interactivity JS was initially designed for – then go ahead and use the bare minimum of what’s necessary. But if you’re planning to do a slightly more complicated “web app” I’d say there’s a reason why all those technologies exist and more often than not you add a feature here, expand something there, and find that your application has grown beyond its initial scope (OK, the proper thing to do would probably be to do a complete rewrite using what you’ve learned thus far, but that’s seldom what gets actually done).

      1. 6

        This is exactly what we’re doing, and my experience is that the apparent complexity as a dev working in cljs/om is far less than using ad-hoc jquery on top of some arbitrary templating language like erb or haml. We have a full fledged, well-designed application for our frontend, and the only language I write is clojure(script).

      1. 7

        Still working on stuff for the final sequence of the book.

        Rolling things around in my head for monitoring and logging for the production AWS deployment I got setup for $dayjob. Currently thinking about Prometheus & Elasticsearch/Kibana.

        Somewhat unhappy so far with Ansible, though I have beaten it into place. Malcontent is from knowing what convergence in config management could/should look like. Wondering if I should pick Puppet back up or look into Chef. Or something else entirely - Propellor is Haskell, for example, but not entirely different from Ansible. Talking me down from this ledge is welcome, but what I really want is a config management system that:

        1. Uses the type system to prevent unforced errors in your deployment & provisioning

        2. Can self-bootstrap or do one-off deploys like Ansible without obligating you to manually provisioning a client for a server-client setup (a la chef zero)

        3. Has an optional “plan” mode like Terraform for letting you know what it would change, ideally runnable from the dev’s computer. Ansible’s dry-run is not good enough.

        Keep trying to think about alternatives to LaTeX, but there really isn’t anything better as far as I can see. I’ve given Prince XML a try, but it’s not better.

        1. 1

          Have you had a look at Scribble? I can’t speak from experience but it might be something to look into.

          1. 1

            Scribble’s a documentation tool, not typesetting. I had to do a lot of work to make the Haskell book look professional and using something like Scribble drops all that on the floor.

            The other problem I’m having is that anything capable of equivalent or better fidelity (InDesign, Framemaker, Scribus) is either proprietary, not available on Linux, or not very automated.

        1. 4

          Maybe this will make http://gridstylesheets.org/ more viable. Would be nice. (Although I’d still love to see native support)

          1. 18

            Howdy all.

            Been a month since I posted. Sometimes it is just hard to find the energy to write given how much I have to get done. But lately, I’ve been finding it useful to write to help me think through decisions or to make notes to remind future-me of what I was thinking now. Along those lines, I wrote GraphQL beyond the web and Finding a User Interface Library this week. The GraphQL post is essentially a follow up to a post from last week, Querying OS Information.

            In related areas, I’ve been working on fixing up some stuff in Ant Design, a UI library for React. (No, I don’t speak or read Chinese, but there’s no reason to let that stop me.) I’m hoping to help them with a translation of their documentation and web site into English.

            I’m still doing a lot of work on Open Dylan as well. I helped someone out with their UUID library last week and did some further improvements to my libsodium bindings. I need to improve the libsodium bindings a bit more so that I can get further with my implementation of macaroons.

            I’ve also been spending a lot of time with my 5 year old daughter, reading to her, helping her read, and teaching her about some of the fun sides of math. Also had another beautiful skink visit our yard.

            1. 2

              At one point I was thinking about using GraphQL to implement an interface to the Docker daemon API. It’s nice to see exploration in similar areas.

              1. 2

                Thanks for the link to Ant Design, that does look interesting. I’m sad that there isn’t a HTML standard for a datepicker, so something like this might be the next best thing.

                1. 1

                  If you want their date component, but without all of their style and other stuff, it is available as a separate component from react-components/calendar. But I like the Ant look, so I’m happy to get it all in a single package. :)

                2. 2

                  I was thinking of writing an interface to query OS info through SPARQL. But haven’t found the time and necessary motivation and tech to build upon yet. GraphQL is syntactically cleaner IMHO, but I think there is tremendous value in having a high level query language for those sort of things at all (and SPARQL has been around for some time).

                  1. 2

                    Hello!

                    I thought about that too and talked about it some with @coreload who is a big proponent of SPARQL and related technologies.

                    I ended up coming down to the issue that GraphQL is just so much easier and lighter weight to implement and it lets me do exactly what I need in this case, and I’m able to do it in a bit of C that can run on almost any device. I didn’t know of any implementation of SPARQL that would allow me to do the same. Further, if I wanted the capabilities that SPARQL offered, I’d probably want them in whatever front-end I was writing and just by the nature of having my data in a structured format (ala JSON / JSON-LD), I’d be able to pump that into a more capable system when needed.

                1. 3

                  I’ve been working some on my Clojure + ClojureScript implementation of the card game Hanabi, which I released recently.

                  I’ve got reordering cards working, although it is somewhat counter intuitive, as you cannot drag a card between two other cards to reorder them but need to drop it on another card which swaps them. The problems is with HTML5 drag n drop, in that I need a drop target (which currently is the other card). I haven’t found any ClojureScript drag'n'drop libraries that would allow more intuitive reordering (there is dragula, but that’s JS). Additionally I plan to draw the hands with SVG eventually to allow a more flexible and realistic appearance (fanned cards?), so I might have to write my own anyways :(

                  The game is overall in a quite early stage, but fully playable and I appreciate any form of feedback!