by Bozho | Sep 15, 2012 | Aggregated, Opinions
Programmers are people who create computer programs. (I’ll skip the discussion whether it should be “programmer”, “developer”, “engineer”, “coder” or whatever. You know what I’m talking about). What makes programming different than most professions is that it’s way more diverse – you can do new things every day, because new technologies emerge all the time. Not only that, but programming is actually a creative job – given a couple of rules and foundations you can build whatever you like – something nobody else has built. Just like the poet starts with words, metric and rhyme rules and comes up with a poem. Or the compose starts with notes and the rules of harmony and comes up with a song. The good thing about programming is that there are always new things to start with and different rules to adhere to. So, programming is a well-paid, creative profession that gives you the opportunity to do a lot of different things. Not exactly. Programming has another feature – it has to be practical, to serve a business purpose. That’s why many programmers tend to do the same thing over and over again – website after website, ERP customization after ERP customization. Then they change jobs to do a very similar task. Partly because they are already experienced with a given technology or process and other companies want them because of that experience, partly because most companies do the same – they build websites for clients, they build or customize ERPs, or they have their own online service that has to be supported/created, but which is essentially the same as what you...
by Bozho | Aug 23, 2012 | Aggregated, Developer tips, Opinions
The other day I read this Arstechnica article and realized how tragic the situation is. And it is not this bad because of the evil hackers. It’s bad because few people know how to handle one very common thing: authentication (signup and login). But it seems even cool companies like LinkedIn and Yahoo do it wrong (tons of passwords have leaked recently) Most of the problems described in the article is solved with bcrypt. And using salt is a must. Other options are also acceptable – PBKDF2 and probably SHA-512. Note that bcrypt is not a hash function, it’s an algorithm that is specifically designed for password storage. It has its own salt generation built-in. Here are two stack exchange questions on the topic: this and this. Jeff Atwood has also written on the topic some time ago. What is salt? It’s a random string (series of bits, to be precise, but for the purpose of password storage, let’s view it as string) that is appended to each password before it is hashed. So “mypassword” may become “543abc7d9fab773fb2a0mypassword”. You then add the salt every time you need to check if the password is correct (i.e. salt+password should generate the same hash that is stored in the database). How does this help? First, rainbow tables (tables of precomputed hashes for character combinations) can’t be used. Rainbow tables are generated for shorter passwords, and a big salt makes the password huge. Bruteforce is still possible, as the attacker knows your salt, so he can just bruteforce salt+(set of attempted passwords). Bcrypt, however, addresses bruteforce, because it is intentionally “slow”. So, use...
by Bozho | Aug 16, 2012 | Aggregated, Opinions
Remember when we used to download and install software? We do that rarely these days. Every tool that we need has also a web version, which is cooler and doesn’t have “virus alert” written all over it. However, for many small businesses, it is still an inconvenience (more of a psychological one) to use a service hosted elsewhere. “They have my data!!”. And these people can’t install and manage the whole stack needed for running a small software locally. On the other hand writing desktop software is tedious (especially in Java). People want to build cool web apps, because that’s where innovation happens. All desktop applications have got in the past decade is a fancier default theme from the OS. Fortunately, the innovation in the web front has now allowed us to build desktop applications as web pages. Sounds odd, I know, but I have already seen some tools (primarily monitoring and development tools, but it’s a start) that are purely html5 and javascript, and run in a browser. So instead of installing an exe file (“I swear, no viruses, checked by 3 companies you’ve never heard of, and it also might change your registry but don’t worry”), people can download an html file and double-click it. It will open in a browser, which is something they are familiar with. And it will do everything a regular application can do. Also, this type of software can be used as client to some UI-less services providing just APIs. I am not talking about OS utilities, or low-level stuff here – just applications for personal finance, small business inventory, notebook, etc....
by Bozho | Jul 30, 2012 | Aggregated, Opinions
You wanna be in the cloud? You have plenty of options. I’ve evaluated or used many of them, so here are a few words about each. (I will include some Java-related comments, as I’m using Java, but most of the things apply to all (supported) languages). But before I go into a bit more details for each service, let me summarize what “the cloud” actually means when it comes to hosting your applications: auto-scaling – if there is an increased demand, you automatically get more resources (more virtual machines in most cases) to handle the requests. For the regular application this is rarely useful, but it’s nice to have it and be sure that your service never dies because the load is too high pay what you use – simply put, this is in fact the option to choose small servers when you are small, and bigger servers when you are big. The “cloudy” thing here is that you can do that easily, rather than reconfiguring some remote machines cloud infrastructure – this is fancy talk for “we deploy these services and take care that they are working”. So instead of installing and configuring a message queue on your machines, you hook up to an already installed and managed message queue. Or database, email service, or cache. management tools – you get consoles, command-line tools and web UIs for handling your installations. This is both a plus (the tools are higher level than working with native commands), and a minus (there’s a learning curve) load balancers – all services offer these, and you rarely care what’s the software and...
by Bozho | Jun 19, 2012 | Aggregated, Opinions
We are starting a new project and we have to choose the web framework. Our default choice is grails, because the team already has experience with it, but I decided to give Play! and Scala a chance. Play! has a lot of cool things for which it received many pluses in my evaluation, but in the end we decided to stick with grails. It’s not that grails is perfect and meets all the requirements, but Play! is not sufficiently better to make us switch. Anyway, here’s a list of areas where Play! failed my evaluation. Please correct me if I’ve got something wrong: template engine – UI developers were furious with the template engine used in the previous project – freemarker, because it wasn’t null-safe – it blew up each time a chain of invocations had null. Play templates use scala, and so they are not null-safe. Scala has a different approach to nulls – Option, but third party libraries and our core code will be in Java and we’d have to introduce some null-to-Option conversion, and it will get ugly. This question shows a way to handle the case, but the comments make me hesitant to use it. That’s only part of the story – with all my respect and awe for static typing, the UI layer must use a simple scripting language. EL/JSTL is a good example. It doesn’t explode if it doesn’t find some value. static assets – this is hard, and I couldn’t find anything about using Play! with a CDN or how to merge multiple assets into one file. Is there an easy way...
by Bozho | Jun 9, 2012 | Aggregated, Opinions
I just got a couple of comments on stackoverflow that the links in my answers are broken. They were all about spring answers, and it appeared spring have changed the URL structure for their documentation. I don’t know when exactly this had happened, but it has. Now, that’s a dumb thing to do if you are even a remotely popular framework/product. Especially with the existence of stackoverflow, “one does not simply change their documentation URLs”. @SpringSource did you change the URLs of the documentation, thus breaking every stackoverflow answer about spring? — Bozhidar Bozhanov (@bozhobg) June 9, 2012 This is not just about documentation of softhware products – it’s about all static resources (this is used for assets like js and css, but here I mean documentation, descriptions, etc.). People link to these things in their comments in forums, Q&A sites and bookmark them. So you should not return 404 for a page that once worked. Now, this is not possible for every page, of course. But the pages that people are most likely to link to have to remain accessible via the original URL. It lives on the internet. By the way, it is good to have /latest documentation, otherwise we will be stuck on old versions in the top google results (Java 1.4 still appears on top). Some may say “But my original URL structure was stupid”. Fair enough, then 301 to your new page. And if you don’t do 301, each time you change a URL of something “linkworthy”, consider the link rot you are causing. And if you do it, you should be like that:...
Recent Comments