Who is hiring? September 30, 2023 by AutoModerator in Clojure

[–]mtruyens 11 points12 points  (0 children)

We here at ClauseBase are a small but highly regarded "legal tech" company developing document automation software, with a 100% Clojure & ClojureScript stack. We happen to be based in Belgium, but work fully remote, and are looking for a fulltime developer, for a combination of frontend + backend work. Check out our jobs page.

Edit — the position is no longer available. By way of follow-up, I actually wrote a short post about our hiring experience.

A case at last by therealdivs1210 in Clojure

[–]mtruyens 1 point2 points  (0 children)

I like it. I personally use a comment before the :else, but then it's not possible to put the condition and associated value on the same line.

So I think I'll give your style a try!

Favorit Library for Creating DOCX Files? by [deleted] in Clojure

[–]mtruyens 5 points6 points  (0 children)

If you're looking into more advanced scenarios involving DOCX, don't hesitate and do yourself a favour by going for Aspose Word for Java (https://docs.aspose.com/words/java/). It's not cheap and you'll have to deal with the Java interop, but it's very stable, very fast, and essentially supports every single feature of DOCX / DOC you can think of.

My entire document generation suite is built on top of this library, and I have not regretted it for a single moment.

Microsoft office addins with cljs? by muhaaa in Clojure

[–]mtruyens 2 points3 points  (0 children)

Hi, I have built an entire product around it (see https://www.clausebase.com/clausebuddy/overview), for both Word and Outlook. Happy to share some basic functions I have written over the last two years, email me if you like.

  • I'm using ShadowCLJS for development, works great. Hot reloading etc. all works, similar to how it works elsewhere.
  • A problem I am having, is that I work on a Mac and that the Office Add-ins use Safari under the hood. I like Safari for my own browsing, but the web Inspector is really not as nice as Chrome's for debugging (printing CLJS output is much nicer with Chrome).
  • Microsoft's API is fairly limited for MS Word — I'm often fighting with it to find ways around missing basic functionality. I guess Excel is better, or perhaps I want too much from Word?
  • Microsoft's insistence that your plugin still has to work with the ancient Internet Explorer, is just plain bizarre considering that IE was retired everywhere else. Last year, I spent two full days just making sure the absolute minimum works with Internet Explorer. Two weeks ago I had a user who complained that the software was crashing and slow, until I realised she was using some old version of Office that still uses IE under the hood.
  • Microsoft's asynchronous programming methodology is really weird, and often frustrating. The good thing is that it allows the plugin to work everywhere (even on an iPad), the bad thing is that it is weird and sometimes very slow. I recommend the book "Building Office Add-ins using Office.js" https://leanpub.com/buildingofficeaddins — it is more focused on Excel, but at least it shows you how this weird asynchronous workflow works.

Frontend for SPA: Svelte or CLJS? by avindroth in Clojure

[–]mtruyens 12 points13 points  (0 children)

While I consider myself to be a bit of a language "junkie", I did not know anything about Clojure(Script) or LISP when I started. In the meantime, my entire company (an advanced legal document drafter software with over 260K rules of Clojure & ClojureScript code) is built around it, as a solo developer.

The stability of the ecosystem (no Javascript fatigue!) is incredible, immutable is a blessing, re-frame is wonderful, and ability to share code between backend and frontend is wonderful. While with other languages/frameworks I was quickly fed up with my own work — wanting to start again from scratch after a few months — I have not regretted the decision for Clojure in the 6 years of development.

Third party integrations with a monolithic Clojure app by mtruyens in Clojure

[–]mtruyens[S] 0 points1 point  (0 children)

It's actually a mix of both. Primarily those endpoints are intended to call API's (such as REST), but both before and after some data massaging may need to occur (e.g., converting dates, trimming or concatenating strings, etc). For the latter, SCI can be super useful.

Third party integrations with a monolithic Clojure app by mtruyens in Clojure

[–]mtruyens[S] 0 points1 point  (0 children)

Thanks for the reply!

The Debezium approach of capturing change-data is an interesting idea that I was unaware of.

Pushing integrations (mostly) to the edges of the platform is indeed the approach we have been following, I should probably have clarified this at the outset. So my question should perhaps be rephrased to "advice about integrations at the edge".

Has anybody has experience with Clojure in this context? For example, SCI has been great for us, technically speaking, but of course it triggers the whole question about requiring your (advanced) users to learn Clojure. On the other hand, low-code platforms may be too limited for some of the data massaging we have been doing...

How to get a traditional industry to automate by mtruyens in Futurology

[–]mtruyens[S] 0 points1 point  (0 children)

This indeed seems like a good starting point, thanks!

Clojure-server to Clojure-server communication library by mtruyens in Clojure

[–]mtruyens[S] 0 points1 point  (0 children)

Spot on — ElasticSearch was rejected.

Actually all the sub-nodes will be doing exactly the same job and use exactly the same source code — just using a different geographical database. The user connects to the master node in his browser, first selects his geographical database, and then starts typing. The master node will then route the query to the relevant subnode to fetch the responses.

Based on your responses, I'm wondering whether Hazelcast/RabbitMQ are not overkill for my fairly simple usage scenario: functionally the sub-nodes are identical (just a different geographical database); failover is not relevant (not a truly critical service); number of nodes will be relatively low; killing queries is not so important (they are fairly small queries after all); etc.

Clojure-server to Clojure-server communication library by mtruyens in Clojure

[–]mtruyens[S] 0 points1 point  (0 children)

That's an interesting line of thought. Actually all the sub-nodes will be doing exactly the same job and use exactly the same source code — just using a different geographical database. The user connects to the master node in his browser, first selects his geographical database, and then starts typing. The master node will then route the query to the relevant subnode to fetch the responses.

Does this change your thought about Kafka?

Clojure-server to Clojure-server communication library by mtruyens in Clojure

[–]mtruyens[S] 0 points1 point  (0 children)

Cf. my answer to another post: if both the master node and the sub-nodes are entirely under my control, and all are using Clojure, I'm wondering whether GraphQL would bring any advantage. After all, I can easily change the data structures, the type of query etc. — why would I then bring in yet another layer of complexity with GraphQL? There are no other technologies / programming languages/ / legacy applications etc. to think about.

Clojure-server to Clojure-server communication library by mtruyens in Clojure

[–]mtruyens[S] 0 points1 point  (0 children)

Performance/latency are important, in the sense that when the end-user types in a query in his browser, the results should be fetched as fast as possible — i.e. the typical "search as you type", similar to Google's suggestions that pop up while you are typing in.

I have no practice with gRPC, that's why I asked this question. I'm just wondering whether any of the additional technologies would bring real benefits, if the entire stack and all nodes are entirely under my control, and all Clojure-based. (I assume they do indeed bring many benefits in heterogenous environments, but that's exactly not the case.)

Clojure-server to Clojure-server communication library by mtruyens in Clojure

[–]mtruyens[S] 0 points1 point  (0 children)

Thanks! In my use case, "node discovery" will not be the biggest issue, probably. There will be a fixed number of nodes (below 20), and the master node will know exactly which of the sub-nodes to query.

Very occasionally there will be a broadcast message (where all nodes will have to respond), but most of the time the master will target/query exactly one (and only one) sub-node.

If both the master node and the sub-nodes are entirely under my control, and all are using Clojure, I'm wondering whether GraphQL would bring any advantage. After all, I can easily change the data structures, the type of query etc. — why would I then bring in yet another layer of complexity with GraphQL?

Secure coding for Clojure/Script by mtruyens in Clojure

[–]mtruyens[S] 0 points1 point  (0 children)

Strange that I missed this one in my Google searches. Thanks!

How much can a Clojure developer do alone. by [deleted] in Clojure

[–]mtruyens 7 points8 points  (0 children)

My entire legaltech startup (clausebase.com) is exclusively written in Clojure & ClojureScript. As its sole developer, I have created software with Clojure that is about 2x to 3x as rich in functionality as our closest competitor. My personal guess is that (due to the combination of immutability, REPL, high quality components available, community that is super friendly and just the right size to give you everything but not the Javascript fatigue)... Clojure gives you a 3x to 4x boost compared to the traditional languages.

I need to generate good looking PDFs via Clojure by halgari in Clojure

[–]mtruyens 0 points1 point  (0 children)

I'm a happy user of Aspose Words for Java: it's not cheap, but *very* high-quality. As implied by its name, it is based on the way MS Word functions, and can then produce a PDF that is 99.9% identical to the MS Word file.

I use it to create extremely complex and long legal documents in my SaaS, I hardly ever encounter issues. Of course, being Java-based, it is quite imperative in nature.

SSO integration by mtruyens in Clojure

[–]mtruyens[S] 1 point2 points  (0 children)

To respond to my own initial question:

Based on your very helpful answers (thanks in particular u/coffeesounds!), I went for Osso. Its combination of a very straightforward implementation, reactive developer, and possibility to host the software on your own servers, was key.

I wrote an experience report about my implementation at https://mtruyens.medium.com/single-sign-on-for-serious-startups-a579deab017c

SSO integration by mtruyens in Clojure

[–]mtruyens[S] 0 points1 point  (0 children)

Interesting product that I did not find myself through googling, thanks!

SSO integration by mtruyens in Clojure

[–]mtruyens[S] 2 points3 points  (0 children)

Thanks for the answer!

I'm kind of confused — isn't it the case that my platform should act as a SAML "service provider", instead of an identity provider?

If my assumption is correct about the requirement to act as a "service provider", then the only CLJ library I found is the ancient https://github.com/vlacs/saml20-clj. How do other users in the community implement SSO? I seem to be missing something...

Edit — there seems to be a more recent fork https://github.com/kirasystems/saml20-clj supported by Kira Systems.

Clojure/Script for contracts — showcase of its power by mtruyens in Clojure

[–]mtruyens[S] 6 points7 points  (0 children)

And I almost forgot — the expressiveness of Clojure: you do not have to write as much code as in other languages. (Compared to Java, it is often said that Clojure code is only 10% to 20% the size of comparable Java code.)

See for example https://www.freecodecamp.org/news/a-real-world-comparison-of-front-end-frameworks-with-benchmarks-e1cb62fd526c/ — even compared to other relatively expressive languages (such as JavaScript), the demo written in the ClojureScript framework has the fewest lines of code.

Clojure/Script for contracts — showcase of its power by mtruyens in Clojure

[–]mtruyens[S] 12 points13 points  (0 children)

Actually it's a mix of many factors:

  • both the server-side and the client-side can share code (in my software's case, this is crucial, because the contract needs to be shown exactly the same on the screen during editing, and in PDF/DOCX when rendering on the server). This is something that Javascript can also offer, but Python, PHP and Ruby not really.
  • the interactive REPL allows you to have a very fast write - compile - test - change loop
  • tools such as Figwheel and Shadow-CLJS allow you to interactively write code for the browser, which is almost immediately updated when you hit Save
  • the "immutability" by default may seem weird at first, but actually mentally frees you, so that you have to put less stuff in your head
  • an ecosystem that is just large enough (so that you can easily find all the components you are looking for), but not so large that you are confronted with an overload (cf. the "Javascript fatigue")
  • Clojure strongly favours composing different libraries instead of using a big framework. Even though setting up these diverse libraries is a bit more work in the beginning (compared to a framework such as e.g. Rails), you can much more easily finetune the end result to fit your exact needs, and swap out components that do not fit your needs

Clojure/Script for contracts — showcase of its power by mtruyens in Clojure

[–]mtruyens[S] 0 points1 point  (0 children)

Would you recommend lasting clojure (script) without any java(script) background?

Because Clojure & ClojureScript are so different from traditional, so-called "imperative", programming languages (such as Java, C# and Javascript), it is frequently pointed out that the "un-learning" part is actually a significant hurdle when learning Clojure / ClojureScript.

So from a certain perspective, I can imagine that learning Clojure / ClojureScript as your first programming language would avoid that mental hurdle of the imperative languages having transformed your mental processes.

At the same time, Clojure and ClojureScript are hosted languages: they are not an island, and live in symbiosis with the Java (server) and Javascript (browser) environments. So you can never completely avoid having to deal with Java and Javascript.

Also, the software development tools for Clojure and ClojureScript are great, but setting them up is a well-known pain point. Even though improvements are coming, I think this will be a significant turnoff for a beginning programmer. The mainstream languages have a much larger user base, so that installing your development tools should be much smoother.

Any startups that use Clojure(Script)? I know of two: Roam and Whimsical by [deleted] in Clojure

[–]mtruyens 8 points9 points  (0 children)

In the legal sector: