by Bozho | Sep 26, 2016 | Aggregated, Opinions
“The decline of Stackoverflow” is now trending on reddit, and I started this post as a comment in the thread, but it got too long. I’m in the 0.01% (which means rank #34) but I haven’t contributed almost anything in the past 4 years. Why I stopped is maybe part of the explanation why “the decline of stackoverflow” isn’t actually happening. The mentioned article describes the experience of a new user as horrible – you can’t easily ask a question without having it downvoted, marked as duplicate, or commented on in a negative way. The overall opinion (of the article and the reddit thread) seems to be that SO “the elite” (the moderators) has become too self-important and is acting on a whim for an alleged “purity” of the site. But that’s not how I see it, even though I haven’t been active since “the good old days”. This Hacker news comment has put it very well: StackOverflow is a machine designed to do one thing: make it so that, for any given programming question, you will get a search engine hit on their site and find a good answer quickly. And see some ads. That’s really it. Everything it does is geared toward that, and it does it quite well. I have lots of SO points. A lot of them have come from answering common, basic questions. If you think points exist to prove merit, that’s bad. But if you think points exist to show “this person makes the kind of content that brings programmers to our site and makes them happy”, it’s good. The latter is their...
by Bozho | Sep 23, 2016 | Aggregated, architecture, Developer tips, Opinions, Restful, spring mvc, web development
When we are building web applications these days, it is considered a best practice to expose all our functionality as a RESTful API and then consume it ourselves. This usually goes with a rich front-end using heavy javascript, e.g. Angular/Ember/Backbone/React. But a heavy front-end doesn’t seem like a good default – applications that require the overhead of a conceptually heavy javascript framework are actually not in the majority. The web, although much more complicated, is still not just about single-page applications. Not to mention that if you are writing a statically-typed backend, you would either need a dedicated javascript team (no necessarily a good idea, especially in small companies/startups), or you have to write in that … not-so-pleasant language. And honestly, my browsers are hurting with all that unnecessary javascript everywhere, but that’s a separate story. The other option for having yourself consume your own RESTful API is to have a “web” module, that calls your “backend” module. Which may be a good idea, especially if you have different teams with different specialties, but the introduction of so much communication overhead for the sake of the separation seems at least something one should think twice before doing. Not to mention that in reality release cycles are usually tied, as you need extra effort to keep the “web” and “backend” in proper sync (“web” not requesting services that the “backend” doesn’t have yet, or the “backend” not providing a modified response model that the “web” doesn’t expect). As in my defence of monoliths, I’m obviously leaning towards a monolithic application. I won’t repeat the other post, but the idea is...
by Bozho | Sep 13, 2016 | Aggregated, Developer tips, Opinions
You’ve probably heard about “the right to be forgotten” according to which Google has to delete search results about you, if you ask them to. According to a new General Data Protection Regulation of the EU, the right to be forgotten means that a data subject (user) can request the deletion of his data from any data controller (which includes web sites), and the data controller must delete the data without delay. Whether it’s a social network profile, items sold in online shops/auctions, location data, properties being offered for sale, even forum comments. Of course, it is not as straightforward, as it depends on the contractual obligations of the user (even with implicit contracts), and the Regulation lists a couple of cases, some of which very broad, when the right to be forgotten is applicable, but the bottom line is that such functionality has to be supported. I’ll quote the relevant bits from the Regulation: Article 17 1. The data subject shall have the right to obtain from the controller the erasure of personal data concerning him or her without undue delay and the controller shall have the obligation to erase personal data without undue delay where one of the following grounds applies: (a) the personal data are no longer necessary in relation to the purposes for which they were collected or otherwise processed; (b) the data subject withdraws consent on which the processing is based according to point (a) of Article 6(1), or point (a) of Article 9(2), and where there is no other legal ground for the processing; …. 2. Where the controller has made the personal...
by Bozho | Aug 21, 2016 | Aggregated, Opinions
Biometric identification is getting more common – borders, phones, doors. But I argue that it is not by itself a good approach. I tried to explain this in a short talk, and here are the slides Biometric features can’t be changed, can’t be revoked – they are there forever. If someone gets hold of them (and that happens sooner or later), we are screwed. And now that we use our fingerprints to unlock our phones, for example, and at the same time we use our phone as the universal “2nd factor” for most online services, including e-banking in some cases, fraud is waiting to happen (or already happening). As Bruce Schneier has said after an experiment that uses gummi bears to fool fingerprint scanners: The results are enough to scrap the systems completely, and to send the various fingerprint biometric companies packing On the other hand, it is not that useful and pleasant to biometric features for identification – just typing a PIN is just as good (but we can change the PIN). I’ve previously discussed the risks related to electronic passports, which have fingerprint images in clear form and are read without a PIN thought a complex certificate management scheme. The bottom line is, they can leak from your passport without you understanding (if the central databases don’t leak before that). Fortunately, there are alternatives that would still guarantee that the owner of the passport is indeed the one it was issued to, an that it’s not fake. But anyway, I think the biometric data can have some future applications. Near the end of the presentation I try...
by Bozho | Aug 7, 2016 | Aggregated, Opinions
In the past year I’ve taken the position of an adviser in the cabinet of a deputy prime minister and as a result of that I had the option to draft legislation. I’ve been doing that with a colleague, both with strong technical background, and it turned out we are not bad at it. Most of “our” laws passed, including the “open source law”, the electronic identification act, and the e-voting amendments to the election code (we were, of course, helped by legal professionals in the process, much a like a junior dev is helped by a senior one). And law drafting felt to have much in common with programming – as a result “our” laws were succinct, well-structured and “to the point”, covering all use-cases. At first it may sound strange that people not trained in the legal profession would be able to do it at all, but writing laws is actually “legal programming”. Here’s what the two processes have in common: Both rely on a formalized language. Programming languages are stricter, but “legalese” is also quite formalized and certain things are worded normally in a predefined way, in a way there are “keywords”. There is a specification on how to use the formalized language and how it should behave. The “Law for normative acts” is the JLS (Java language specification) for law-drafting- it defines what is allowed, how laws should be structured and how they should refer to each other. It also defines the process of law-making. Laws have a predefined structure, just as a class file, for example. There are sections, articles, references and modification clauses...
by Bozho | Jun 17, 2016 | Aggregated, Developer tips, Opinions
There are many ways to work with git. The workflows vary depending on the size of the team, organization, and on the way of working – is it distributed, is it sprint-based, is it a company, or an open-source project, where a maintainer approves pull requests. You can use vanilla-git, you can use GitHub, BitBucket, GitLab, Stash. And then on the client side you can use the command line, IDE integration, or stand-alone clients like SourceTree. The workflows differ mostly in the way you organize you branches and the way you merge them. Do you branch off branches? Do you branch off other people’s branches, which are work-in-progress. Do you push or stay local? Do you use it like SVN (perfectly fine for a single developer on a pet project), or you delve into more “arcane” features like --force-with-lease. This is all decided by each team, but I’d like to focus on one very debated topic – rebasing vs merging. While you can get tons of results discussing rebasing vs merging, including the official git documentation, it has become more of a philosophical debate, rather than a practical one. I recently asked a practical question about a rebase workflow. In short, by default rebasing seems not to favour pushing stuff to the central repo. If you do that before rebasing, you’d always need to force-push. And force-pushing may make it very hard for people that are based on your branch. Two questions that you are already asking: Why do you need to push if something isn’t ready? Isn’t it the point of the “D” in “DVCS” to be able...
Recent Comments