by Bozho | Nov 13, 2015 | Aggregated, Opinions
Last week I gave a talk on the OpenFest conference about (remote) e-voting (or internet voting/i-voting). The talk was not in English, but here are my translated slides: I’ve addressed some of the topics from the presentation in a previous post. Overall, it’s a hard problem, with a lot of issues to be addressed and it must be treated seriously. However, we must do it, sooner or later, as it will allow for a more dynamic and direct...
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 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 7, 2015 | Aggregated, Opinions
What is a software engineer? And what is a senior software engineer? Many companies define a “senior software engineer” as a person who has spent more then 6 years as a programmer. And that’s not always correct. The other day I was asked whether I recommend becoming a “generalist” or a “specialist”. Whether one should stay focused on one particular technology and become really proficient with it, or do a little bit of everything. I once wrote that if you do a little bit of everything, you become no expert at all. And while I still partially hold that view, it needs to be elaborated. The software engineer mindset never results in narrow specialists. But it doesn’t mean you don’t “drill” into a particular technology. In fact, you drill into many particular technologies/frameworks/levels of abstractions. You become proficient with them, then you move on to the next one. Probably with side projects, probably as transitioning from one job to another, where something unfamiliar is used alongside the known bits. Over time, you gather enough experience that each new technology is familiar and you get get into it pretty quickly. On the other hand, staying focused on one particular technology for a long time doesn’t let you see the full spectrum of possible solutions to a problem. So no, doing mostly jQuery/Rails/Spring/Android/… for 15 years doesn’t make you a “senior software engineer”. The software engineer mindset is about solving the problem. The more senior you are, the faster you are in finding simpler solutions. The more technologies you are familiar with, the more non-localized solutions you are able to produce...
by Bozho | Aug 22, 2015 | Aggregated, Opinions
The Twelve-Factor App is a recent methodology (and/or a manifesto) for writing web applications that hopefully is getting quite popular. Although I don’t agree 100% with the recommendations, I ‘ll quickly go through all 12 factors and discuss them in the light of the Java ecosystem, mentioning the absolute “musts” and the points where I disagree. For more, visit the 12factor.net site. Codebase – one codebase, multiple deploys. This means you must not have various codebase for various versions. Branches is okay, different repos are not. I’d even go further and not recommend Subversion. Not because it’s not fine, but because git and mercurial do the same and much more. You can use git/mercurial the way you use SVN, but not the other way around. And tools for DVCS (e.g. SourceTree) are already quite good Dependencies – obviously, you must put as many dependencies in your manifests (e.g. pom.xml) as possible. The manifesto advices against relying on pre-installed software, for example ImageMagick or Pandoc, but I wouldn’t be that strict. If your deployments are automated and you guarantee the presence of a given tool, you shouldn’t spend days trying to wrap it in a library of your working language. If it’s as easy as putting an exetuable script in a jar file and then extracting it, that’s fine. But if it requires installation, and you really need it (ImageMagick is a good example indeed), I don’t think it’s wrong to expect it to be installed. Just check on startup if it’s present and fail fast if it’s not. Config – the most important rule here is – never commit...
Recent Comments