Bad link, remove the trailing slash
78 karma · joined March 18, 2016
One disadvantage is you can't use wsgi middleware, but after rewriting our middleware to components they ended up being much neater. I'm a fan of the bottom up approach where you define the components you want in a route. We have some routes which just returns the database query and with a custom renderer it will get rendered in the json format we expect
I've started using an generated offline cache and PIP_FIND_LINKS to remove the dependency of pypi for known installs in one project as well, will be interesting to see if it turns out to be a good idea or not.
[1]: https://www.kennethreitz.org/essays/a-better-pip-workflow
This is funny, I've actually inherited a project where the original developer had this idea, he used the same function to encrypt everything: even the news posts available on the front page were encrypted. The passwords were using the same encryption functions and needless to say not using a one way hash so fully decryptable...
At work we make heavy use of version controlled configuration management where we can recreate any machine from just rerunning the ansible playbook and duply backup for databases and other storage.
While duply was trivial to set up, nice to work with, and much more stable than any other solutions that we were using previously if I were to do it again with more than a handful of machines I would have likely looked into reversing the flow with a pull based backup just to have a better overview since I don't trust a `duply verify` monitoring to catch all possible issues.
Cloud backup is managed by a server fetching the data and then backing it up with duply.
We also run a rsync of all disk image snapshots from one DC to another (and vice versa) but that is more of a disaster recovery in case our regular backups fail or were not properly set up for vital data since it would take more effort to recover from those backups
That being said we currently use docker for some of our production databases, mainly for almost-idle services (mongodb for graylog, zookeeper for kafka), but I have had no problem using them for some moderately sized services with a couple thousands writes per second on redis/kafka (which is nothing for them).
We're still using non-containerised versions of the databases that needs dedicated bare metal servers mostly because I don't see the risk-benefit being worth it, but I'd love to hear someones war stories about running larger scale databases in docker.
For development, I don't think there's anything better for databases, it beats manual setup, vagrant boxes, and shared development servers by a long shot. I feel that educating everyone on your team in how to use it is well worth the investment. docker-compose makes setting up even a fairly complicated development environment a breeze.
Not to mention the battery impact of poorly written javascript SPA's or advertisements.
[1]: https://bugs.chromium.org/p/chromium/issues/detail?id=52663
If you need a version and don't care about following the spec just use a timestamp or datetime, replace it where required with a sed command and move on but please don't claim to use semver if it's just an arbitrary number for you
1) Encounter unexpected behaviour with standard features
2) Ask irc for help
3) Response: shrug must be a compiler bug
1: https://wiki.archlinux.org/index.php/Arch_Linux#Principles
[1]: https://developer.mozilla.org/en-US/docs/Web/API/HTMLMediaEl...
Most browsers store their passwords in plain-text, this means there's applications that can fetch all your stored passwords from all browsers and send them to an undisclosed location in seconds given user level privileges on the machine.
By upgrading to lastpass you have reduced that attack surface by using a secure passphrase and encrypted data-store but you have increased your attack surface to anything accessing lastpass servers and application bugs.
With all these attack vectors one might think that it's better to just not save passwords and just remember them, while this is true in theory in practice it's impossible to remember a sufficiently unique password for each website you are registered to which leads to password reuse which is another much greater attack vector where your leaked passwords from one site can be reused on other sites.
In general I would advice you to use a password manager that generates and encrypts passwords (Lastpass is one of them), use a secure passphrase and don't reuse passwords. Password reuse will likely make you less secure than writing your passwords on a post-it by your computer (don't do that either)
I would also consider looking into using proper 2-factor authentication for sensitive login (document storage, email, password manager) but I don't want to bore people with the details there so I'll defer you to do some independent research
TLDR
* Store passwords encrypted (Lastpass is fine)
* Don't reuse passwords on different sites
Giving someone a weekend to fix something doesn't exactly sound like responsible disclosure. I understand if you get excited because you found a flaw but if you find something like this please be more responsible with publishing your findings.
The learning curve to git is not great but as far as I know nobody has publicly released an option that's improved enough over git to motivate the cost of switching technology. If it's not working for you the only advice I can give is either learn it until it is actually working for you rather than being in the way or try to find a better workflow.