by Bozho | Jul 12, 2013 | Aggregated, Developer tips, Opinions
During development you sometimes have a part of the system that is rarely changed, requires a lot of resources, has a lot of prerequisites to run, and/or takes a lot of time to deploy. What do you normally do? Extract that part into a separate application and run it on one or several servers, having developers connect to these services. Examples may be: search engine interface, CPU-intensive operations, 3rd party systems, etc. In a way, you make your system modular. However, there’s a drawback to this modularity – it adds complexity and points of failure. What if the communication between the module breaks, how do you trace and debug issues (they might be caused by either of the two (or more) systems), how do you keep multiple versions of the applications’ public interfaces in sync (and do you need multiple versions to co-exist?), how is deployment of two applications handled at one atomic step, and more. Many times you don’t need to introduce that complexity, but you still need the flexibility during development. An option I sometimes use is to have the subsystem both as embedded and as a standalone module. To do that, you make a thin layer (calling it a layer from architectural perspective; in terms of code it is going to consist of 2 classes and an interface) which handles two types of deployment. There is one interface that defines the operations, performed by the module, and two implementations – one is RESTful, calling RESTful services of a separately deployed application, one is simply wrapping the class that performs the actual operation (or even is the...
by Bozho | Jul 1, 2013 | Aggregated, Developer tips, Opinions
“We must write more documentation”. Have you heard that? I have, many times in many companies. Most people feel guilty for not writing documentation and agree. I don’t. There are two types of documentation – in-code and external. In-code documentation consists of javadoc (or whatever language/tool you are using to describe what classes and their methods do) and comments. External documentation consists of documents or intranet articles describing what the product does. Rule number one of external documentation: it goes out of date. And keeping it in sync is a tedious and time-consuming task. Rule number two of external documentation: nobody actually uses it. Programmers work with code. They are good at reading code. And code makes perfect sense to them. Documenting the core classes and any non-trivial use-case within a method is part of coding best practices, and good programmers do that. It makes understanding the code much easier for other people, and together with writing self-documenting code, it is an entirely sufficient documentation. And it doesn’t need keeping in sync (well, apart from changing a comment above a snippet). So do you need external documentation? Well, yes, some of it. It is important to make a very succinct description of the overall architecture, so that the pieces of code make sense in a broader context. What are the modules and how they interact – that’s enough, one page. It will also go out of sync, but at least it’s easy to support and it might be the duty of the team lead / architect to verify its validity every now and then. And now, if you are...
by Bozho | Jun 11, 2013 | Aggregated, Opinions
Programming is not just writing code – it is working with a huge pile of abstractions. Starting from zeroes and ones, through processor instructions, memory addresses, low-level network protocols, data structures, up to web services, component frameworks and user interface. From low-level, often tedious stuff, to more pleasant to use and maintain stuff. We are categorized as “senior developers”. Which, to some people, automatically means that we are experts in all these level of abstraction. And if we aren’t, then we are not good. I tend to disagree with this opinion. And not only to justify my lack of expertise in all levels of abstraction. It’s basically a tradeoff – you either focus on some of the layers, and become really good there, or you do a little bit of this and that and become no expert anyway. You can argue that at some point you should reach an expert level in most levels, one after another, but this expertise becomes redundant and obsolete with time. If today I put my application design and framework knowledge aside, and plunge into algorithms or TCP programming, in 3 years I may no longer be expert in the former, due to the advancements of technology. Abstractions are there for a reason – to shield you from knowing a huge amount of caveats down the whole stack. If it weren’t for the abstractions, we wouldn’t be able to write decent software at all. And focusing on higher levels is what we are supposed to do, because the lower levels are already handled. This turns low-level programming into some arcane art that is only...
by Bozho | Jun 2, 2013 | Aggregated, Opinions
We read. We watch. We learn. We gain knowledge. What’s the point? The point of knowledge is to allow our imagination to make unexpected connections between more and more elements. In other words, we feed our serendipitous imagination. Then many things may come out of it – ideas, inventions, art. Anything, in fact. Einstein wouldn’t have come up with the theory of relativity if he didn’t know so much about physics. Shakespeare wouldn’t be that great if he didn’t know the rules and techniques of poetry. Great minds amass knowledge and then, out of nowhere, ideas appear. Why it works like that, I can’t tell. But it does. If the amounts of knowledge is so important, then why computers can’t come up with new ideas? Google and wikipedia have all the knowledge in the world. They even make it harder for humans to remember information that is easily verified, because, hey, you can look it up (a.k.a. The Google Effect). The Semantic Web is an attempt to make sense of the interconnected information on the web. But even with all these technologies in place, a computer wouldn’t have been able to generate the string theory, the light bulb, Midsummer’s Night Dream or Beethoven’s 9th. Knowledge is one prerequisite. But you can’t always have all the knowledge, therefore you may need someone else to steer you into the right direction, to complete the missing puzzle of both your knowledge and your pre-hatched ideas. That’s what Steven Johnson is telling us in his RSA talk about ideas. Chance favors the connected mind, he says. I’d say that chance also favors the...
by Bozho | Apr 27, 2013 | Aggregated, Developer tips, Opinions
Your system is probably sending some emails. Sometimes these emails contain links to the public part of the site, sometimes they have links to the authentication-protected part. Either way, if the email is sent to registered users (as opposed to just subscribed emails) you should not make the user type in username and password. Even if it’s the public part of the site, the user may then want to do something that requires authentication with the content you display – e.g. add it to favourites. It’s a bit tricky with public content though, and you might not want to have it there, as users tend to forward “digest” or “best this week” emails, and then the recipients will be able to impersonate them, without even knowing. Anyway, when users click on a link in an email sent by your system, they could be logged in automatically. That’s the product requirement I think many systems should have, and it sounds pretty reasonable. But I’ve rarely seen in. Let’s assume you like it and you want to implement it in your system. How to do that, as there are certainly some security implications? For each email sent, generate a token. The token should be the HMAC of (the user’s email (or username, or id) concatenated with the token generation timestamp) Use an application-wide, configurable per-environment key for the HMAC. Also use a good hash algorithm, like SHA-256 (and not MD5) Append the token to each link in the email. You are probably using an email template, so just have ?emailLoginToken=${token} for each link. Also pass the email and the timestamp as...
by Bozho | Feb 23, 2013 | Aggregated, Developer tips, Opinions
There’s a trivial problem that every project has – keeping the database structure in sync with the application. That is, when your code relies on a new table or column, that table/column must appear in the database. This is especially a problem when there are multiple environments, on which the code gets deployed (production, stage, integration, local), as usually additional steps need to be performed in order to update the database schema. The quickest way to achieve the desired effect is to provide SQL upgrade scripts every time the code needs a new database element (or no longer needs one). But that’s tedious, as these sql scripts have to be executed manually on each environment the code gets deployed to. Automating this process has been achieved by a couple of frameworks, so that you don’t need to do it. Here is a list of options for the Java world. Why do we actually need such a solution? We aim for frequent, one-click deployments to staging and production environments. We can’t do that without an automated way of syncing the database (otherwise there will be missing columns, or obsolete non-null columns will prevent data insertion). And once in a while we may need to revert a release, and we’d have to rollback the database changes accordingly. While you can just drop and recreate the schema while developing locally, you can’t do that in production. Rails developers will rightly say “We’ve had that for a long time, out of the box”. Indeed, rails migrations seem like a perfect implementation of the idea of keeping the application code in sync with the...
Recent Comments