Awara Group published an interesting overview of the Russian economy for the last 14 years: “Putin 2000 – 2014, Midterm Interim Results: Diversification, Modernization and the Role of the State in Russia’s economy.” The document contains the analysis of economics and progress made demonstrated with diagrams that quickly show that there is no economic crisis in Russia and that it is not dependent on the gas and oil export. On the contrary, Russian economy made an incredible progress in these 14 years and is going strong.
This study takes aim at disapproving the continuously repeated claims that Russia has supposedly not diversified and modernized its economy. Our report shows that it is especially false to claim that the Russian government has not done anything in this vein, that it would be “relying” on oil & gas rents and lacks an understanding that more must be done. Quite the opposite, the Russian state under Putin’s leadership has devoted all its spare resources to address this problem; the early results are impressive and a lot of effort and strategic initiatives are currently being implemented.
And really, in the last 14 years the food manufacturing in Russia doubled, the industry has been fully modernized and increased output by 50%, export increased five fold while the actual share of gas and oil in the GDP of Russia shrank to only 16%.
So any claims that Russia “relies on oil and gas” for its livelihood or does not develop its economy are completely false and do not have any basis in facts.
Copy of the report: Awara-Study-Russian-Economy-2014.pdf… -->continue reading →
I am convinced that agile software development methods the way they are used now do not work. They are actually a prescription for failure. The problem is that Agile philosophy fails even before starting.
Agile is described in many different ways but when you think about what it tries to achieve you must come to the unavoidable conclusion that it tries to provide a method to develop software with cheaper workforce. That’s the whole idea behind it. The business expects to get the software developed with not-so-brilliant programmers who can be paid a fraction of what the really good people would be paid. And then the good programmers can be also pressured into accepting lower pay for their work.
Well, it does not work. Oh, it does work to pressure the salaries of programmers, that it does. But the software becomes developed in a piecemeal fashion and it becomes really difficult to keep to a single encompassing coherent design. You must use really brilliant programmers to be able to keep the system well-designed, sleek and coherent. Unfortunately, this contradicts the original goal of not using brilliant programmers. And thus the system turns into a patchwork of vaguely connected functions and pieces.
To make a parallel, I think when I see a mechanical product labeled “Made in China” I hardly can expect some brilliant German engineering in it. The same goes here, when I see something coming out of Agile, I do not expect any brilliant engineering either. Agile is the source of cheap, faulty and disposable software.… -->continue reading →
Still, the separation of concern is as actual as it always was. Consider this website design thing. You still have to separate the concerns between the user management and the website content management. These are totally different concerns. And they have different priorities too.
When you manage the content in your application you basically do not care about users at all. You care only to know whether the requester has the right to see (or modify, whatever) this particular content. So you need some kind of identifier as an input to the authorization management, which is another concern. You really do not need any details of the user that is usually kept by the user management.
While you are in the user management, creation, registration, modification, verification etc. require full knowledge of the user details. So you need to have different data on users here.
What happens is that you really need to have two different concepts of users: one for your user management subsystem and one for your website content management subsystem. And those have little in common. Plus, the website content management requires such user information (besides being useful) that can be quickly retrieved and add minimal overhead. On top of that, user information in both must be kept in sync.
Finally, one comes to realize that the database views are invented precisely for this particular problem. So we can have the same user data underneath but present two different views of that same data to the two subsystems of our web application.… -->continue reading →
I had thus silly idea to quickly throw together a website for myself to list up my motorbikes. Well, not “mine” per se, I do own only one, but the ones I have ridden over the years and have an opinion about. Since I like to do things “my way”, I searched for a rapid development framework instead of heading over to a motorcycle website. Silly me. But that’s besides the point.
I looked at the CakePHP framework and it appears a solid piece of engineering I could be happy with. The only problem is that I have been trying to get the user registration and login set up for the better part of two months now (I have a day job too).
There are plugins for doing user management and complete login and registration libraries but all that I looked at share one thing in common (and with CakePHP itself, too): they are written with a frightening disregard for security. Every single one of them. So much for Open Source and crowd-sourcing. I would not use any of them to manage my website. Period.
So, I embarked on a quest to write my own plugin for CakePHP that would demonstrate what you can do with the user sessions security if you really put your mind to it. I have a first draft running now, very simple actions only but it works. So I am confident that once I get my head around the concept of plugins in CakePHP I will be able to provide a plugin with far better security for user sessions.
Some points that come to mind when thinking what has to be done vs. what is usually done:
- The user identifier is usually predictable, allowing often for a user listing. It is either an auto-increment in the database, or a UUID. Neither is unpredictable. A random 64-bit value will be far better, even when the random generator is not all that great.
- The user name is the primary identification. This is, in my personal opinion, passe. The user ID is the e-mail address.
- The confirmation links (registration, password change) are silly MD5 hashes of the current time. I think, again, a 64-128 bit random will be so much better.
- Some send out a new password to the user in an e-mail. Instead of a random token. That is simply not to be done.
- The “remember me” cookie is usually implemented by sending a user name and a password hash to the user browser in a cookie. That is plain silly too. This, again, has to be a random token stored in your database and given to the user.
That’s what I come up with just off… -->continue reading →
That is really something we come across almost every single day – the initiatives and ideas that seemed so good backfire and destroy all they were supposed to improve. One of those things is Agile in software development.
The idea originally was fairly trivial but seemed to have potential to work. The idea was to be able to split the software development into smaller chunks so that even an idiot would be able to write that small piece of code. Then, a company would not need to hire experienced software developments but could settle for inexperienced, inadequately trained and simply stupid developers, often without an engineering degree. That would allow to pay less for the same amount of software produced.
The result? A catastrophic loss of productivity ensues. Yes, it is cheap to get the software developers and make them scrum masters but what then? They are not capable of developing the software anyway. And you drove away all real masters of design already. The amount of time required to write and rewrite all the code and tests shoots through the roof. The productivity falls through the floor. Costs … you guess it.
Software design (as many other engineering disciplines) remains an art to this day. Yes, you can apply agile principles in some dark corners of software development but far from everywhere. And that is something managers still have to understand.… -->continue reading →