We use flyway for the biggest monolith database in our company. We also use alembic for some microservices.
Alembic is extra convenient if you're already invested in sqlalchemy.
I've tried yoyo-migrations[1] once, a while ago.
With yoyo, like flyway, migrations are written as SQL queries. However, they're expressed as SQL steps in python files. Might worth a look if you're using python.
Hi, the one I'm trying to build is also an aggregator. I would like to make it as automated as possible. This is something I just built for the heck of it. Periodix looks really cool and has a bigger scope than my site. Thank you for the comment.
Scaling a blog is not a big of an issue these days. Even with Wordpress, caching and other optimizations should not be a hassle. There are also many other alternatives in the static-site realm.
Blogger is not as good an option as it was before. It was an attractive buy for google at the time of the acquisition. But now they have stopped using it even for their own blogs. I wouldn't be surprised if Google decides to shut down blogger in the near future.
I couldn't agree more with you about nesting loops. It seems clever at the moment when you're writing but when you have to come back after a while or worse, another developer has to, it becomes a nightmare.
I would also go a bit further and put nesting if statements. Sometimes it's really required but other times nesting can be avoided. I try to avoid nesting as much as possible.
Quick tip: extract the contents of loops out into functions. That allows you to test the function outside of the context of the loop. It makes it easy to test boundary conditions and other exceptions. Often it is unnecessary to actually test the loop.
This is also true of branches. If you have an if statement (or other branch), consider extracting the contents of each half out. It allows you to test each half independently. If you have nested branches, you need to have 2^n tests (where n is the number of nested branches). If you extract the contents, then you need 2n tests.
This is one of the reason for unit rather than integration tests: you can dramatically reduce the number of tests while still getting full test coverage. Of course the downside is decomposing the structure of the code more than you might be used to. It's always a judgement call.
I wonder how people come up with these insanity. It does not add any value to the article and is so infuriating. Apart from that, I found the article good.
Someone come up with a „brilliant” idea, someone else who doesn’t care implements it. That’s how usually short-lived, standard-breaking solutions are created. I’m seeing more and more often on many websites an ad in this „creatively revealing” image.
I have seen a bastardized version of Django admin used as a quite sophisticated dashboard. This new addition will make it even easier to hack together things like that in a very short time.
One of my first Django projects was to “bastardize” its admin into a Lead/Opportunity management system for a mortgage broker, back in the version 0.96 days. I know that monkey-patching is now frowned upon and reguarded as “the work of the devil” but it really helped me get the job done for that project in a pretty reasonable amount of time. I hope dynamic programming makes a come-back.
