mikeywaites

Vizibl | Front end | Full Time | REMOTE | https://www.vizibl.co/careers

Vizibl is seeking a front-end developer to join our remote team to help change the way companies work together. If you're looking to work as part of a team that loves autonomy, openess, flexability and collaboration then please read more.

Vizibl | Front End Engineers, Product Designers | London United Kingdom | REMOTE | www.vizibl.co

At Vizibl, we’re on a mission to help every company work together, better. We want to help all companies make a difference in the world by revolutionising the way they work together, empowering them to reach their full potential.

2019 is a critical year of growth for Vizibl and we're hoping to expand our product and engineering teams. We're looking for

2x Front End engineers - https://vizibl.workable.com/jobs/991167

2x Product Designers - https://vizibl.workable.com/jobs/991737

Children of time[1] is a remarkable piece of writing. I wish I could unread it just so I could read it for the first time again

1. https://www.goodreads.com/book/show/25499718

Vizibl | Lead Front End Engineer | London United Kingdom | Remote (UK/Europe) | Full-Time | vizibl.co

Vizibl is a SaaS platform being used by some of the worlds biggest organisations. We're on a mission to enable every company in the world to be able to connect and work together in better ways by building an eco-system that transforms the business relationship

We're currently looking for.

Lead Front End Engineer - https://vizibl.workable.com/jobs/928300

Hi detaro.

Thanks for the reply. I can't disagree with your points. I should be clearer about my usage of the cookiecutter template right from the start over my poor attempts at being funny :D

I'll have a think about re-shuffling the content.

Thanks again

We released Arrested (https://arrested.readthedocs.org) a few weeks. This is a follow up post covering the basics and marks the beginning of series of weekly posts covering lots of different topics relating to RESTFul API design in Python.

If you have any questions please ask!

There are some great Python REST frameworks out there, but we wanted something un-opinionated and easy to get started with but flexible enough to customise.

We’ve previously released our serialization/marshaling framework Kim (https://github.com/mikeywaites/kim), and Arrested includes built in integration for it. If you’d prefer to use another serializer, it’s easy to customise Arrested to do so and we’d love to receive a PR for it.

To get started quickly, there’s a cookiecutter (https://github.com/mikeywaites/arrested-cookiecutter) and quick start documentation (http://arrested.readthedocs.io/en/latest/).

If you have any questions please ask!

Thanks so much for this Voidfiles. We were under no illusions that we weren't the most performant library out there (yet)

This is a great start for us understanding where we need to get to! We've got some work to do :)

Hey that's really great to hear. (that you're keen to use Kim) WTF-Forms and Marshmallow both solve problems and they do it well but it seems like us you wanted something that offered just a bit more flexibility. That's totally the idea behind pipelines in Kim. They are like tiny little computer programmes and are really capable of anything (providing it's possible in Python of course :D )

It's great you asked this question as we noticed part of the documentation was actually broken. here's a link to a pretty basic example of adding extra validation "pipes" to a pipeline

http://kim.readthedocs.io/en/latest/user/advanced.html#custo...

We'd be more than happy to discuss how to solve more complex requirements if there's something specific you had in mind though.

Thanks for the message!

absolutely. Im a bit annoyed at myself that I hadn't got round to that yet but thanks for raising it.

One of the engineers from our team is going to be there for sure. Im certainly keen to go so fingers crossed.

Hey Dowwie!

That's a great point and an important distinction to make. As I mentioned in some of the other comments, we have certainly been focussed on features over performance so far but we are actively working on dramatically improving the performance of Kim.

I guess it's almost important to pick the right tool for the job. Thanks for sharing the link to asphalt too. I'd not see that before.

Thanks for expanding on that mhneu. So our primary focus with Kim has certainly been around serializing/marshaling JSON though we've used it for plenty of other uses cases.

It's great to get a view of other problems people are experiencing.

Now we've finished wrapping up 1.0.0 we're going to be spending some time on the roadmap of new features. I personally feel variation in use cases from our own is only going to help make Kim better so we'll defo look into this problem some more in the near future. Right now though i couldn't say for sure what Kim would have to offer when working with Pandas etc as we've simply never tried.

One of the things we felt very strongly about when developing Kim was that Simple things should be simple. Complex things should be possible. To that end the Pipeline system behind the Field objects really does allow anything to be achieved. Wether thats producing values from composite fields or handling unique or non standard data types.

it would be great if you can share some ways that you specifically need serialization to work for something like pandas, or better yet, some ways existing solutions don’t work with pandas. We’ve had some pretty unique requirements ourselves and have not found any blockers yet.

Thanks for the message.

Hey Amelius,

thanks for the message. Gonna be honest, I'm not sure what you mean by cycles. Can you elaborate a bit?

Hey. It's a great point and something we will certainly look to add to the documentation. To be honest the docs were the major thing that held up the release of Kim. We made the mistake of leaving them until last so in the end we opted for quality over quantity to get them finished.

A great suggestion though, thanks!

Hi Siddhant,

We've not really dug into performance yet, though if you look at the last patch (1.0.2) we yielded a 10% speed up by removing an erroneous try/except block.

We've really focussed on features initially and performance is something we're actively researching now. Perhaps we can get some initial benchmarks together and share them with you this week. They will be useful no doubt as we start to plan a release focussed on speed ups.

Thanks for reaching out!