by Bozho | Feb 20, 2012 | Aggregated, Developer tips, Opinions
What is “state” in your web application? It’s the data that gets stored (regardless of the destination – memory, database, file-system). The application itself must not store any state in the code. This means your classes should only have fields with objects that are also stateless. In other words – you should not store anything in your services, DAOs or controllers during the program flow. This is a complete “must” for your service layer. Why? Your application needs to be scalable. This means it needs to be run in a cluster, and state is the hardest thing to distribute. If you minimize the places where state is stored, you minimize the complexity of clustering. But state should exist, and here is where it is fine to have it: the database – be it SQL, NoSQL or even a search engine, it’s the main thing that stores state. It is the thing that is supposed to support clustering, or a huge dedicated machine that handles requests from multiple other “code” servers. The code communicates with the database, but the code itself does not store anything for more than one client request; cache – caching is relatively easy to distribute (it’s basically key-value). There are many ready-to-use solutions like EhCache and memcached. So instead of computing a result, or getting it from the DB on each request, you can configure caching and store the result in memory. But again – code does not store anything – it just populates and queries the cache; HTTP session – in web components (controllers, managed beans, whatever you call it). It is very similar to...
by Bozho | Jan 22, 2012 | Aggregated, Opinions
The Dilbert comics is just 2 years younger than me, which means there are thousands of strips. Most of them represent a mocked real-world situation, especially about big corporations and geeks. I have always wondered if managers read Dilbert. I bet they don’t, otherwise they’d say “oh, wait, this thing I’m doing was mocked by Scot Adams, and it is obviously idiotic”. Anyway, regular people like Dilbert could sometimes get a Dilbert attitude and send a comic strip to their managers. And the Dilbert website offers a pretty good search engine for that – just search for “deadline”, “raise”, “new colleague” and you’ll find a lot of good strips to send to your pointy-haired boss. Even if this isn’t going to change the habits of managers, let’s at least make some fun of them. So the next time your company hangs big posters with “Company values”, send this to everyone, cc management. And hope not to get fired. The Dilbert comics is just 2 years younger than me, which means there are thousands of strips. Most of them represent a mocked real-world situation, especially about big corporations and geeks. I have always wondered if managers read Dilbert. I bet they don’t, otherwise they’d say “oh, wait, this thing I’m doing was mocked by Scot Adams, and it is obviously idiotic”. Anyway, regular people like Dilbert could sometimes get a Dilbert attitude and send a comic strip to their managers. And the Dilbert website offers a pretty good search engine for that – just search for “deadline”, “raise”, “new colleague” and you’ll find a lot of good strips to send...
by Bozho | Jan 12, 2012 | Aggregated, Opinions
This is going to be an odd publication, that falls more into the “life tips” or “self help” category, than into “programming”. But bear with me. What is “clean software”? Software that has very few bugs, that has readable and maintainable code, that has good documentation and a lot of automated tests and metrics. How do you get clean software? Each day you fix and improve things. As I wrote a month ago – you should fix bad code as soon as it appears (or in the next sprint/iteration), and you should have code reviews to make sure everything committed is fine. You must write good unit tests, even though it might feel redundant. You must eliminate all bugs before writing new code (one of Joel’s 12 points). You should document everything that you write, so that it’s clear what it does and why. And you should have a project plan (Joel’s test, again). As a programmer you know these things, and you are aware that they make better software. And now the metaphor – the development of your life is like the development of a software system – if you conform to some best practices and principles, it will be better (obviously?). If you apply the “clean software” approach to your own existence, it is likely to improve in the long run. What do I mean: health issues – in case of any discomfort or pain, fix it immediately. Run the “automated tests and metrics” in a hospital, and find out what is it. If you fix it early, it won’t get more complicated to fix later. And...
by Bozho | Jan 3, 2012 | Aggregated, Opinions
Java is too verbose, they say. You can find comparisons of Hello World programs that take 2 lines in ruby and 10 lines in Java, and in order to read a file you need 20 lines in Java and just 1 in php. Even though the examples are often exaggerated (for example counting imports), it is true Java programs requires more lines of code. But this is not a bad thing at all. On the contrary – it is something I actually like. In fact, it is not about the verbosity of the language – apart from anonymous classes-insteadof-closures, there is nothing else that the language is too verbose about. It is about the core libraries. So – I like the way the core libraries are written in terms of verbosity. Two examples: take the java.io. package. Reading and writing files, streams, etc. It is a bit hard to graps, and in the beginning you copy-paste long snippets of code to simply read a file. But it forces you to understand the abstraction of streams and readers. Other languages have simply: var contents = readFile("path") Cool, but you are never forced to understand how the I/O management works. What happens if reading fails? Is partial reading of the file sufficient for you? Can you nagivate the file? Should you close resources or they are automatically closed? You don’t need to answer these questions for a hello world program, but you will need to know about them pretty soon. And the less-verbose languages hide them from you and postpone this “abstraction revelation”. the servlet API. At first it looks to...
by Bozho | Dec 7, 2011 | Aggregated, Developer tips, Opinions
You are working on that fresh project and you see a bad piece of code somewhere. The wrong way to approach it is “nah, that’s someone else’s code, I’m not doing anything about it”, “I don’t have time to fix that – I have other tasks”, “I’ll surely break things if I change this”. The problem is – bad code accumulates. Even if the piece is a small one, it adds up over time and soon enough you have that “big legacy project that was written by some incompetent guys and no one wants to support”. Someone once said that in six months all projects are “legacy”, because they have a lot of accumulated bad code. Or in other words – technical debt. That’s why you should fix it immediately. When you see some piece of crap, or something that’s not exaactly a great practice – fix it. Now. Or it will be too late, because then other code will start depending on that, and new code will follow the same practice (sometimes with copy/paste), and fixing it will be a nightmare. Let’s address the wrong statements above: “nah, that’s someone else’s code, I’m not doing anything about it” – so, what? You are in that project, you have the “right” to modify it. If the other person has written their code in a bad way, it might be that they even don’t know it’s bad – so they won’t fix it. And I don’t think they will get offended if you fix it. They might, but that’s not your problem. “I don’t have time to fix that –...
by Bozho | Nov 23, 2011 | Aggregated, Opinions
You should have a default use case (or a small set of them). No matter what are you making – end-user product, public API, protocol spec, etc. The default use case is the most common thing that your users will do with your product. The focus of your product. And after you define your default use case, you must make sure it is the most obvious and easy thing to do. Yes, this sounds like a very obvious and universal thing, but many products fail to recognize that. Here are a few examples of products that do it right: the default use case of google is searching. They make it pretty obvious – you have one text box and one button (well, two actually). It is the most straightforward thing to do with their interface. Of course that is not the only thing that you can do – you can customize your search, customize your language, you can advertise or visit their side-projects. But all these are options at the side of the screen. The default use case has all the focus the default use case of Amazon is purchasing. Do they make it obvious? Yes – you pick your items and you click the 1-click checkout button. Extremely simple. And the most obvious thing to do. Of course you can customize all the steps in your purchase, you can be a seller yourself or you can write reviews to items, but these are “side-options” that are available if you look for them. But you immediately see the default use case, and it is the easiest thing to do...
Recent Comments