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 | May 18, 2013 | Aggregated, Developer tips
A while ago I asked the following question on stackoverflow: “Why would I use a template engine?”. I compared template engines to simple JSP includes. Although I didn’t particularly fancy any of the answer, it was obvious that templating is the preferred way of defining the structure of websites, especially if they are bigger ones. Since then I have used velocty, freemarker, tiles, sitemesh and grails. I hate freemarker, because of its cryptic syntax, its illogical behaviour at times (e.g. only strings as map keys) and because of throwing exceptions when something is null (even if nothing is invoked on the null). I don’t particularly like velocity (apart from using it for email templates) – there’s a learning curve and you don’t get more than a JSP. I didn’t like tiles and sitemesh because they require some external xml configuration that makes navigating through the code harder and they are not exactly very active projects. And while all of these worked and I wouldn’t say “don’t use them” (apart from freemarker), they didn’t feel good. When working with a grails application, I very much liked GSP (groovy server pages) – it is simple but powerful and has decent IDE support. It has all the good parts of JSP combined with simple if/else constructs and with built-in templating and some extra features. Using it in a non-grails application, I thought, would be an issue. It seems that it is possible, and I’d recommend that, although I haven’t used it outside of grails – here’s how to do it. But there seems to be a way to have templates with plain...
Recent Comments