neuroid

I don't know anybody that would do a sequential scan over a file in production

Well, that's pretty much how one would try to crack a password using a wordlist.

EDIT: If the goal is to crack a bunch of properly hashed (PBKDF2, scrypt, etc.) and salted passwords then a lookup table is not very practical.

There is another theory suggesting otherwise [1]:

Saturn’s mid-sized moons are like the monsters in late-night horror movies. Smash them into tiny pieces, and they glue themselves back together as new versions of the old moons. This new finding contradicts a theory that Saturn’s rings were caused by moons colliding.

[1] https://www.newscientist.com/article/2132906-saturns-moons-c...

Screenshot from our management console.

This looks like an amazing tool.

The first commit of a repository can not be rebased like regular commits

That's not necessarily true. This can be done with:

  git rebase -i --root

The issue mentioned in the blog post was fixed over a year ago [1]. However, the issue reported by Tavis Ormandy [2] is new.

[1] https://blog.lastpass.com/2016/07/lastpass-security-updates....

[2] https://bugs.chromium.org/p/project-zero/issues/detail?id=88...

Why should, say, pip packages have any problems with each other as long as they aren't imported directly in a python sourcefile.

Are you suggesting that package versions should be explicitly provided as part of import statements? Or that import statements should be mangled depending on the versions specified in setup.py?

Reported in https://github.com/OpenTSDB/opentsdb/issues/781

There is nothing magical about computing (unless you use Source Mage [1]). But, I have to agree with the author: people tend to use the word magic if they cannot immediately grasp the meaning of a piece of code. This code might use a language construct we are not familiar with, or implement a complex O(log N) algorithm, or it might use a magic number [2]. In most cases, however, it is worth to spend time to understand such code.

[1] https://en.wikipedia.org/wiki/Source_Mage

[2] https://en.wikipedia.org/wiki/Fast_inverse_square_root#Overv...

Even though we had pinned all our dependencies (with requirements like package-x==1.2.3), pip would still reach out to PyPI before before deciding which version to pick.

Another solution for this would be to build wheels for all dependencies and invoke pip with --no-index -f https://url.to.wheels.

Just out of interest, what were the main challenges you faced when using Celery?

Celery is a task queue. Pika could definitely be used to build a task queue (similarly to how Celery is built on top of Kombu), but I can't think of many good reasons why that would pay off. Unless your use case was not a task queue...

I had a quick look at the transcript of Ben's talk, and it seems that one of his main issues with microservices which share the same code base (and therefore dependencies) is the overhead of upgrading their dependencies. I do understand that in some cases this might be problematic. However, if the microservices are written using the same language (or runtime), there is a huge benefit of reusing some abstractions. These might include things like validation schemas, serialisation formats, etc. These are the things that most likely would need to be created anyway for every microservice written in a new language. As usual, there has to be some balance in the amount of coupling between microservices. But there is nothing inherently wrong with reusing code between them. I think the most important factor in a microservice ecosystem is having well defined protocols and APIs.

This. Using setup.py for specifying min versions (and occasionally max versions) is definitely the way to go.

However, manually maintaining a requirements file in addition to setup.py is quite tedious in the long run. It is much better to freeze requirements during the build process and use the generated requirements file for deployments. But, decent test coverage is key here.

Paperless Receipts | http://ereceipts.co.uk | London, UK | Full Time | ONSITE

Our eReceipts platform enables retailers to capture vast quantities of transaction data and provides the insight to help them garner a deep understanding of their customers. We work with companies that include Argos, Halfords, Debenhams, Maplin and French Connection, among others. Our receipt count is currently at 236M and increases by roughly 3.7M receipts per week.

We are looking for a talented software engineer to help us expand our SaaS platform and introduce new and exciting features.

Most of our code base is written in Python, therefore strong Python skills are a must, but experience with Java, C#, and Lua would also be useful.

Our backend stack includes Pyramid, Celery, MySQL, MongoDB, InfluxDB and Elasticsearch, and is hosted at Rackspace on a number of Debian VMs. Our development process is built around Git, Review Board, Buildbot and a couple of thousand tests. We deploy with Ansible.

If you are interested, or have further questions, drop an e-mail to jobs@ereceipts.co.uk.