Fork me on GitHub
#off-topic
<
2017-09-02
>
qqq10:09:51

@font-face {font-family: AMSRegular; src: url('/kafonts/KaTeX_AMS-Regular.ttf');} how do I translate that line into garden/css ?

dominicm10:09:20

> Please enter the details. Mandatory fields are marked by * (Note: your password will be confirmed to you by email) Well that seems safe > *E-mail (all lower case) Well that isn't compliant

qqq11:09:36

apparnetly the trick is to use "@font-family" to get the @ to appear in css

hmaurer16:09:08

Hi! I’ve a question which I am not sure where to fit, so I will drop it here. Lately I have been feeling sullen about the state of the tools I have been using to build backend applications. Most of my recent projects have been web applications, so I am referring API backends with fairly simple needs (crud, authentication, authorisation, etc). Over the years I have worked with a number of frameworks/languages (PHP/Laravel/Symfony, Ruby/Rails, etc), and some of them were very good at getting things done, but none really satisfied me on a conceptual level. For example, often Authorisation is done at the route level (at least on projects I have touched). I am vaguely familiar with approaches such as using a command bus to take those concerns out of the API layer, but not in depth. Recently I have started to learn Clojure, which has a lot of exciting ideas, but I have yet to find a project which really inspires me on how I should write/structure my backend code. Has anyone had similar feelings and found a solution that they feel happy with?

weavejester16:09:49

My solution is effectively Duct. It’s not yet complete by any means, but it shows the direction I’m going in.

lmergen16:09:52

i am a duct / integrant fan, so i am fully supporting @weavejester in this :)

hmaurer16:09:43

This has been particularly bugging me lately as I have been working with a GraphQL API, where the “point of entry” to your data is a bit less defined than with a more standard REST api.

hmaurer16:09:14

If that makes any sense! Re-reading myself I realise this wasn’t the clearest way to express what’s on my mind

hmaurer16:09:18

Happy to elaborate

lmergen16:09:41

i understand that you want to have a framework that "dictates" how you should do things, like authorisation and other frequent but hard-to-get-right things ?

lmergen16:09:17

the thing is, clojure makes no real assumptions on how you want to do things

lmergen16:09:40

so it's rather up to you how you want to implement such things

hmaurer16:09:42

@lmergen not really a framework. I am young and haven’t seen much in the world; I would like to be aware of how experienced developers structure those things

lmergen16:09:16

to be honest, that's not really language specific but more generally about each of those topics

lmergen16:09:39

so you can probably learn a lot by just looking around on the internet

lmergen16:09:55

any particular topic you want to learn more about ?

hmaurer16:09:45

@lmergen just wondering if there are any decently well known architectural pattern I am missing out on when it comes to structuring fairly simple web backend code (CRUD, with authorisation and validation concerns). It seems to be that those things should be simple but often lead to a lot of incidental complexity

hmaurer16:09:50

maybe I should take a look at Vase

lmergen16:09:01

as @weavejester said, i would recommend to take a look at duct. i think vase is fairly limited in the type of problems it tries to solve (microservices), and duct is a more general architectural pattern.

lmergen16:09:45

i find the things you learn/use with duct are more generally applicable.

qqq17:09:56

in particular, I want to register on-message / on-error listeners