by Bozho | Oct 23, 2015 | Aggregated, Opinions
The first Microservices talk I attended was a year and a half ago. My first reaction was “why is that something new?”. Then I realized it is already getting overhyped, so I listened to some more talks, read a bit more articles, so that I can have a good reason not to like the hype. What are microservices is probably defined here or by Martin Fowler, or at any of the first google results for “microservices”. It is basically splitting up your functionality into separately deployable modules that communicate with each other in order to complete a business goal, and each microservice is limited to just a small, well-defined scope. Product purchasing is one microservice, user registration is another microservice, “current promotions” is another microservice, and so on. Or they can be even more fine-grained – that appears to be debatable. And whenever I encounter a new “thing”, I try to answer the questions “what’s the point” and “does this apply to me”. And I’d like to point out that I’m not the person that rejects anything new, because things can be done “the old way”, but there’s a fine line between a good new technology/architecture, and hype. And besides, microservices is nothing new. I remember several years back when we had an application split into several parts that communicated with web services. When I joined, I refactored that into a single monolith, which improved response times by around 20%. It turned out we never needed the split. And that’s why I’m going to write about – that you probably don’t need microservices. And Martin Fowler has phrased this...
by Bozho | Oct 12, 2015 | Aggregated, Developer tips
In every project that I’ve worked on, there’s always a need of a certain piece of functionality: retrying an operation. Normally it’s about calls over the network that can fail once, but then succeed. It can be about a lot of other stuff, mostly including communication with another system (be it over the network or not). It is functionality that you absolutely need in most applications, especially if you want them to be highly available (as pointed out here, for example). And every time I have to introduce this functionality in a project, I check the standard libraries we have imported, and there’s no such thing. So I always end up copy-pasting the same piece of code from previous projects of mine. I don’t even remember when was the first time I introduced it, but it’s “traveling” with me ever since. So here it is: /** * Class that provides retrying functionality. Example: * <p></p> * <code> * Callable<String> callable = new Callable<String>() {..}; * String result = RetryableOperation.create(callable).retry(5, IOException.class); * </code> * * @param <T> the return type of the operation */ public class RetryableOperation<T> { private Callable<T> callable; private Runnable runnable; private boolean exponentialBackoff; private int backoffInterval = 500; /** * Create a retryable operation based on a Callable instance. The return * type of retry(..) is the type parameter of the Callable instance. * * @param callable * @return * a new instance of RetryableOperation */ public static <T> RetryableOperation<T> create(Callable<T> callable) { return new RetryableOperation<T>().withCallable(callable); } /** * Creates a retryable operation based on a Runnable instance. In this case * the retry(..) method always...
by Bozho | Oct 2, 2015 | Aggregated, Opinions
Due to an upcoming referendum in Bulgaria about whether we want “remote electronic voting”, I, as a technical person, and at the same time, as government adviser, argue a lot about electronic voting. A year and a half ago I’ve given a very brief overview of what I think has to be done and is doable. But now I’d like to ask a more general question – why all this fear in electronic voting? I have heard literally hundreds of versions of the same bunch of arguments: anonymity is not guaranteed, someone can change everything with one command, I can’t be sure what happens to my vote, it’s a black box, someone may easily compromise everything with a virus, you’ll be DDoSed, etc. This for example is one giant strawman video. Every single bit it in, spoken very quickly and very assertively, is wrong. Votes can be anonymous, you can verify your vote, there are ways to prevent massive result changes, there are ways to protect even the clients (hardware keypads, virtualized voting environments), and good operational security gives you, ontop of the essential security, a way to detect every attempt to attack the system, and there are ways to prevent DDoS. And horribly few people have actually read anything on the topic. I recommend, for example, reading this 136 pages report. And these papers: paper, paper, paper, paper, paper, paper. But you won’t, will you? Because you are sure that it cannot ever be secure, the ballot secrecy cannot be guaranteed, and you can’t be sure whether your vote is counted. Even though the literature hints otherwise. Let...
by Bozho | Sep 17, 2015 | Aggregated, Developer tips, Opinions
A few months ago I spoke on a conference (jPrime) about common sense driven development (and what it isn’t). Here’s the video: And here are the slides: Common Sense Driven Development from Bozhidar Bozhanov As you’ll see, I am not a very good and engaging speaker. I hope at least the content is meaningful, although this time it felt a bit chaotic. Nevertheless, the points I’m trying to make are still worth...
by Bozho | Sep 10, 2015 | Aggregated, Developer tips
Your users have profiles on your web application. And normally you should give them a way to delete their profiles (at least that’s what the European Court has decided). That “simply” means you need to have a /forget-me endpoint which deletes every piece of data for the current user. From the database, from the file storage, from the search engine, etc. Apart from giving your users at least partial control over their own data (whether you can have it or not is their decision), it is also a benefit for developers. Apart from your isolated unit tests, containing a lot of mocks, you have other sorts of tests – integration test, acceptance tests, Selenim tests. All of these need a way to leave the database in the same state that it was before they were executed. In some cases you can use read-only transactions (e.g. with spring-test you get that automatically), or you can use an in-memory database and hope it will work the same way as your production one, or you can drop the database and recreate it on each run. But these are partial solutions with some additional complexity. The best way, I think, is to just reuse the “forget me” functionality. From your acceptance/selenium tests you can call the /forget-me endpoint at the end of the test (tearDown), and for your integration tests y. If you distribute client-side APIs (or a third-party is building them against a test deployments of your system), you can again call the forget-me endpoint. That, of course, doesn’t cover non-user-related data that you need in the database. If you have such...
Recent Comments