ramnes

I mean, yeah, it's just like code. The most secure code is the one that doesn't exist!

Have been using it in a Go project lately, wonderful library! Ended up with jd after trying a few others that couldn't handle edge cases, such as creating a diff between `[]` and `{}`. Love the diff format as well.

Go help the folks working on Focalboard!

I'm writing a Python client right now, 99% copied from their JS implementation, if anyone wants to join the fun!

https://github.com/ramnes/notion-sdk-py

I hope they will release an OpenAPI specification file soon so that code maintenance between different clients is kept to a minimum. :)

Eh, what a fail!

That one will work: [email protected]

numberly | Software Engineer | Paris, France | FULL-TIME | VISA | ONSITE

At numberly, we help our customers collect, analyze and leverage their data across all marketing channels. To do this, we are more than 100 engineers (a quarter of numberly) divided into teams with a human dimension, where we make sure that each one develops a positive influence and can be autonomous. Our sustained growth pushes us to constantly challenge our technical and organizational choices.

Due to our wide range of interconnected products, our technical issues are very varied and often complex. Our daily missions are to process thousands of queries per second, distributed around the world, operate multiple petabytes databases (Big Data™), automate our entire bare-metal infrastructure, and build tomorrow's digital marketing interfaces.

Our ideal candidate profile:

• Significant IT culture and technical curiosity

• Thorough knowledge in at least one back-end and/or front-end stack

• Interest in databases, the world of open-source, and/or DevOps culture

• Good communicator, able to popularize work, defend ideas but also listen to others

• Willingness to progress and to help others progress, technically (meetups, internal training) and humanly

• Good experience using Python and/or Javascript is a plus

• Daily use of Linux is very preferable but not required

• Professional English (our teams are international)

Today, I'm particularly looking for a proficient Front-End Software Engineer to join my team and help us build our new projects on our new Vue.js stack, as well as moving our aging Angular interfaces to shiny Vue.js micro front-ends.

Feel free to reach me out for any question or application: [email protected] / ramnes (irc.freenode.net)

More informations on https://www.numberly.com

PS: we don't do "whiteboard" interviews.

Yes! It's functools.wraps*, though. :)

See my comment above. And yes, the preconditions could be written with a lambda, which would be much cleaner than using eval.

Annotation and registration are indeed common and proper uses of decorators.

What I dislike are mostly the inputs 8, 9, 13, 14, and 23 that could give nasty ideas to an inexperienced developer, while a more experienced developer wouldn't need them to understand that a decorator is just a syntactic sugar and that, yes, "applying a decorator d to a function x [is] the same as writing the definition of x, then x = d(x)" (which the author seems to refute).

I understand that those examples are solely intended to show that "it works", but they aren't educational to me.

This notebook should be named "how to abuse decorators". Honestly, there is very little here that you want to use in a real project.

I completely agree in that saying "a decorator is a function that takes a function and returns a function" isn't technically correct since you can do much more than just that; but for readability, maintainability and other real world purposes, you might want to keep to that definition.

Funny: https://github.com/ramnes/trotter

Awesome!

Since the goal is a low VM footprint, rather than install a X on the VM, I'd rather use Emacs as my kernel init process and simply use my host web browser when needed.

> I also see no way this would work for branching. You would have to change all your submodules.

`git submodule foreach`