What do you mean by "jj clone" ? I assumed it was possible to start using jj on an existing Git repository, and continue using Git (and jj) afterwards. Isn't this the case ?
It is. I assume they just mean an existing repo that hasn't had jj bootstrapped in it. Which is trivial, but maybe you just don't want to do it for whatever reason.
(OP here.) This is true to a good extend but a library such as blaze-html can't offer at least two things I've in mind. One is the very lightweight syntax. You can for instance have a look at the reference page source code[1]. Writing that in blaze-html is a lot more verbose.
Two, although it's possible to introspect a blaze-html -generated tree, you can't easily have tooling to, say, list HTML fragments, where they are used, which one are full HTML documents (i.e. starting with a doctype)... One of my goal with Slab is to have a "refactorable" language to write "large" HTML code bases (I'm mainly thinking of design systems reference implementations). Having a tool that can "see" the tree structure, the fragment calls, the list of files, ... opens new tooling opportunities.
I'm one of those people that says syntax doesn't matter; we should talk about semantic instead (and thus just adopt s-expressions for syntax). Yet, in this case, I think that a very lightweight syntax that maps clearly to HTML, in particular for non-programmers (e.g. designers), is very valuable.
Note also that I make available a statically-linked `slab` binary that makes super easy to start using Slab. You don't need a programming environment with a compiler and so on. (I'd like to try to create a Cosmopolitan[2] binary in the future.)
The `slab` binary also has a "watch" feature that rebuilds pages and reload the browse as you edit `.slab` files. I guess I mean that having an integrated tool can offer a very good developer (or designer ?) experience.
(OP here.) Indeed, Slab is a templating language, just like Pug or Haml are. Slab was initially a reimplementation of Pug, but it evolved a bit.
In particular, I tried to respect a principle often found in programming languages: user-defined elements (fragments) are no different than builtin ones. For example notice how `page` (which is user-defined) is used in the same way as as `body` (which is builtin) in the first code snippet of the introduction[1].
(In the future, I hope that instead of providing builtins, Slab will instead use libraries of elements. There is an undocumented feature to define elements[2].)
In Pug, to reuse bits of HTML, you can define mixins, but they are called with a `+` sign in front of their name. I also believe mixins can have expression arguments, but not other blocks of HTML. To pass blocks of HTML as "arguments", Pug provides the `extends` keyword, but I think it can only be used at the toplevel of a template. In Slab, the concept of fragments is a bit more uniform: a fragment can be used with expression arguments, and block arguments.
SEEKING WORK | Belgium | Remote & On-Site in Belgium
+15 years of professional experience mainly with Python
+4 years of hands-on technical leadership
I'd love to work with Haskell and Nix (my side projects use them), although I've been using Python professionally for about 10 years. I like to get my hands dirty and have always worked with things like CI/CD pipelines, provisioning VMs, and so on (for example, I've been using Docker since 2013). I'm used to complicated code bases that need serious improvement.
20 years ago, on December 24, 2002, it was decided to replace the paper version of the Belgian official journal by its online version, starting in 2003. Here is how Belgian citizens can access theirs laws and other official texts: http://www.ejustice.just.fgov.be. (It's also available in HTTPS.)
I believe it looks exactly the same since 1997, when that site was originally introduced, and wanted to share it. The text can be searched using a form where you have to first click the "Search" button, then the "List" button to actually go to the result page. On a given result, you can download its PDF version by clicking the "Image" button.
It looks like the site is a bunch of Perl CGI scripts but I have no idea how documents are authored, or how the PDF generation is done.
It's available only in French, Dutch, and German. While German is an official language in Belgium, the German version is only a translation, not an official text.
I'm looking for a Markdown editor that can save directly to GitHub, with the ability to make drafts (feature branches and possibly PRs) and reviews (accept the PR or merge to main) directly from the editor and hide as much as possible the complexity of Git. The idea is this could be used by non-technical persons to edit Markdown files in a Git repository that is turned into a static site by whatever means technical people could come up with (Jekyll, Pandoc, whatever).
I have started to write some notes[1], and even some code to try to better understand how the game was created (I'm pretty sure I've made some mistakes though). I have listed some additional references there if you like this.
What prompted me to do so was that the Wikipedia page in french mentioned a VM running multiple threads, which I thought was very interesting for 1989.
While working on my own implementation of the bytecode interpreter last year I wrote a tool to inspect the polygon files [1].
It did help to find some bugs in my renderer code :)
The tool needs unpacked data files like the ones found in the 20th Anniversary edition, but the files extracted from the BANK files works fine as well.
May I ask why you want to switch out of zendesk ? I'm reluctant to use it where I am (we have so many badly integrated third party software already...) but some people are pushing a lot for it.
We have modest needs from a ticketing system, no desire for customer chat - just email to ticket workflow. Zendesk works, but is a bit oversized for our ticketing needs (and slightly overpriced, perhaps - but not by an order of magnitude, so to speak).
We have a lot of history in our zendesk - and some of our customers are acquainted with the workflow.
I would probably not introduce zendesk as a new tool, but I do not have a clear recommendation on what should replace it.
At a previous work place we were quite happy with Trac - and I was a bit disappointed ttha Apache Bloodhound seemingly died off (it was in many ways an opinionated Trac setup/distribution).
On the other hand, if the other choice was a monstrosity like jira, I'd probably prefer zendesk.
I do think it's important to realise that support ticket (sub)systems are not issue trackers/scrum tooling - and vice-versa. Not all tickets are issues, and many issues are not tickets.
But if the two sub systems have some easy integration, that can still be beneficial. Just don't fool yourself into thinking that it can (should!) all be automated. Good support ticket handling provides real value both for customers and the development team.
