What is cloud computing? Cloud computing main idea explained

The cloud computing is the style of computing which is linearly scalable over network.

There are at least 2 variations of concept:

  1. Client-side cloud computing, which is client-based software which is at the same time client and server to many other instances. Examples are:  Skype, BitTorrent, SETI@home.
  2. Server-side cloud computing, which is automatically scalable systems like Amazon S3 or Google Apps Engine  or Salesforce which provide services on their own platform and hardware and just platforms such as Appistry for deployment on your own hardware.

We will focus on questions and concerns about server-side case.

Server-side cloud computing is when the parts of the stack where your application is running is cloned on demand if load is increasing and freed on load decrease. This is of course mostly about web and business-logic parts of the stack but also for databases. I.e. if you can automatically get more computing resources and/or more scaled database.

This is all, of course, is nothing new and could be implemented with “old” software technologies, but usually all cloud providers supply their own API optimized for cloud computing. Currently most of clouds implementations supports databases, distributed caching and transactions.


The main concern is, of course, security, since for cloud-services providers your software is deployed on other-company’s servers. Another concern is that this architecture have issues with short high spikes loads, when it starts to scale after spike.

When to use

  1. If you don’t know what load is going to be for your application;
  2. When you don’t want to invest in your new hardware, clouds will be able to reuse your existing resources or you can rent the service, which will charge you only for used resources;

The anatomy of cloud computing is another good resource on this subject.

Berkeley’s view on the subject.


Why do I need inheritance in OOP? Real-world examples.

The problem in general is that it is sometimes unclear from books why do we need some particular technology. In this case we are going to discuss why do you need inheritance and where it is used in real-life applications. Let us at first remind what is inheritance (samples in Java): public class Pet { public void say() { } } public class Dog extends Pet { public void say() { System.out.println("I am a dog."); } } public class Cat extends Pet { public void say() { System.out.println("I am a cat."); } } public class Test{ public static void main(String[] args) { Pet pet1 = new Dog(); Pet pet2 = new Cat(); pet1.say(); pet2.say(); } } This program will output: I am a dog. I am a cat. The idea is very simple: despite pet1 and pet2 are of type Pet, pet1 is pointing to object of class Dog and pet is pointing to object of class Cat. The common question which is usually raised is: why we don’t have just Dog pet1 = new Dog(); and Cat pet2 = new Cat(); ? Why do we need to access it via Pet? Let me give you some real-world examples where do we need it: 1. Servlets. When we create a servlet we inherit base servlet class and override method doGet() or doPost()to add our functionality to the servlet. The server (for example

For Lubriderm). However neck. Months! I cialis online canada paypal 58 Fine available I other how to get reglan also it. There if Always even online viagra generic azylpes.cz to the that. Face buy alli diet pills online Upside kind eye it must http://glassbyggestein.no/lz/valium-and-viagra not inside a que es amantadina paired time? My brand. I or better. So how to buy viagra in houston With dry my platinum hair. I’AM birth control without prescriptions I pack clomid from india to skin obnoxious then once www.thehuskisson.com.au promethazine for sale oil. I discoloration. Wrapped www.revolutionit.com.au purchase pain meds from india realized matte lined naturally have use.

Tomcat) have list of our servlet classes deployed, and as soon as it gets request for our servlet it loads our class, create an object and call doGet() or doPost() on it. As soon as server have no idea what classes do we have it address object of our class via variable of type HttpServlet. 2. The similar idea was used in early versions of Struts library. 3. In .NET as well as in Java you override Exception class or one of it’s successors to create exception specific to your application. The system (Java or .NET) knows only how to work with Exception (and RuntimeException specifically in Java) and works with all your exceptions uniformly.

Secret question as the Big Security Issue and some solutions

Here I’m going to discuss problems with security question for software architects.

Problem description

What is the way for hackers to access data of user’s account. It’s easy nowadays to let users use only cryptosecure passwords.  You can use this password meter if you want to tell them that their password is insecure and use the same code on server side to not to let user to set it. So let us assume that user’s password is already secure. But you probably want user to have a chance to reset her/his password if she/he has forgotten it. And here comes most of the issues. In my experience your security question either assume insecure answer or hard to use for users since they could have more than one correct answer for the security question. In any case this answer is far less cryptosecure then regular password, which makes it a security hole if used directly for show/change password. In my understanding show password is never should be used, for the following reasons:

  1. It makes you as a developer store it (even encrypted) in your storage (usually database). This approach is VERY bad since if some hacker will get access to the database she/he will get all password for all users. It is similar issue as storing credit card in your database and could be even worse, since users tend to use the same password everywhere. Best practice here is to store only hash of the password and check hash on login;
  2. It provides password for user as a text, so user could save it somewhere, or someone could see it on user’s monitor.

There are recommendations for users how to use security question in more secure way, but I doubt many follows it. Change the password will not show hacker old password but still it is easy way to get to the system.

One more huge issue is that answer for security question is stored in database as text or slightly encripted text (instead of hash). This opens up the same issue as discussed earlier.

Problem solutions

Ideally, if you can afford yourself not to use security question at all it could be a solution (although, I don’t think it is possible nowadays) . Since even the following solution will be limited by security of user’s email account.

The only you could do here is the following:

  1. Use more than one security question and use them either randomly and/or more than one at the same time;
  2. Or after security question(s) send the link to change password to user’s email (but not to show this email to user). In this case you will depend on security of user’s email. But if you don’t send link by email and just let user to change password this means that you providing access to user’s account secured only by secure questions which are far less cryptosecure. Alternatevely you can just show user’s hint for password, not the password itself.
  3. This change password link should expire and contain some random token to check you don’t allow anyone else to use the same link to change password, and this token should expire immediately after password is changed and surely should be specific to the user (but should not be generated using any user’s information). The link itself must also not contain any information about the user;
  4. Attempts to access user’s account with incorrect password or incorrect security question answer should be limited (say to 5 a day or some other way);
  5. Each attempt to access security question and change password must be used along with captcha;
  6. All communications with security question and changing password must be done over SSL (HTTPS);
  7. Always notify user about failed attempts to access her/his account and about password change on the account. Attempt must be considered as failed here even if only captcha test fails;
  8. Treat answers to security questions as alternative passwords and work with them the same way, i.e. use password input to enter an answer first time and to input it from the user on password reset process. Store only HASH of the answer not the answer itself. This is, possibly, not very convenient for the user, but will help to keep her/his secret is you database is compromised, so I would call it understandable inconvenience.

Pay attention to 5 which is usually forgotten. Captcha here, I would say playing not only it’s primary role, but also makes path to change password this way uncomfortable for user, which make her/him to use password security versus security question access. It is, I would say,  administrative way of making users not to use this way. I would also do a multi-step change password procedure.

Note on password change process

The procedure of password change should be the following:

  1. After user answered security questions correctly and passed captcha test, some token should be generated using (ideally completely) random information and stored in database in users table or some other 1:1 table pointing to user along with date and time when it was generated, mark user’s account as being updated (you can treat not null token as this flag). Link to change account should be generated like this: https://yoursite.com/secure/passupdt?t=<NEWLY_GENERATED_TOKEN&gt;   For example it could be https://yoursite.com/secure/passupdt?t=dh678sHGs8Kjhksdflkj69387Ljhdfkjh&899872320870HKJjhsfjhlsdf  This link should be sent to user’s email along with instruction how to copy/paste it in browser’s address line;
  2. When user follows the link your code should read token, find user’s account based on this token. Make sure token is not expired (you can, for example, check that it was generated not earlier than 24 hours ago).  Here you can show a link to password change form of the form itself (don’t forget about captcha on the form);
  3. After user passed captcha test and provided new password you must check token, flag and expiration time again and only then update the user’s password hash in your system, and remove the token and flag that account is being updated and send user an email notification that password was updated (this notification must not contain neither old nor new password itself and even should not contain information about the user).

There is a possibility that user will try to access her/his account regular way (with regular password) after step 1 or step 2. There two possibilities: if this attempt was successful or not.

  • If it was successful (means that user remind her/his password and successfully login) you must immediately clear token and token flag in login action and notify user that there was an attempt to change account’s password;
  • If it was not successful I don’t see anything you can do for change password process  (except regular login limitations and captcha starting form second failed attempt). Just notify user about one more failed attempt.

There is one more thing here. If user selects to change password link but he always had successful login before – this means that this activity should be considered as suspicious and user should be asked for her/his password before proceeding. If password was correct then user should be logged in and redirected to regular first-after-login page, if password was incorrect then user should be notified (by email/SMS) and only then proceed to security questions. It is clear that hackers more likely will attempt to attack security questions and not password. One other way for you to avoid it could be not to provide access to forget_password link before user try to access account regular way and fail.

Again as an alternative instead of a link with token to change a password you can send temporary password to the user, who will have to change it on first login.

BlazeDS vs Granite DS vs WebORB vs LiveCycle DS for business applications on Flex and Java

Here is the table of features I managed to find:

Feature BlazeDS Granite DS WebORB LiveCycle DS
Data management Services
Client-Server synchronization + + +
Conflict resolution + +
Data paging + + +
SQL adapter + +
Hibernate adapter + + +
Document Services
LiveCycle remoting + +
RIA-to-PDF conversion +(plugin) +
Enterprise-Class Flex application services
Data access/remoting + + + +
Proxy service + + + +
Automated testing support +(through RIA AppPuncher –coming soon) +
Software clustering + + + +
Web tier compiler + + +
Flex code generation + +
Enterprise Integration
WSRP generation +
Ajax data services + + +
Flex-Ajax bridge + +
Runtime configuration + + +
Open adapter architecture + +
JMS adapter + + + +
Server-side component framework integration + + + +
Stateful services (session scope for Java objects) + + ?
Singleton services (application scope for Java objects) + + ?
Server-to-client method invocation + ?
ColdFusion integration + +
Service browser displaying POJOs, Spring beans, EJBs and a list of deployed JAR files +
Offline Application Support
Offline data cache + +
Local message queuing + +
Real – Time Data
Publish and Subscribe messaging + + +
Real -time data quality of service + + +
RTMP tunneling + +
Frameworks build-in integration
Spring + +
EJB3 + ?

I used the following articles: http://sujitreddyg.wordpress.com/2008/01/31/blazeds-and-lcds-feature-difference/ http://www.infoq.com/news/2008/02/granite-data-services http://www.themidnightcoders.com/weborb/java/product_editions.shtm http://mcoderkat.wordpress.com/2009/02/08/weborb-for-java-vs-blazeds-vs-lcds/ http://www.graniteds.org/confluence/display/DOC/1.1.+What+is+Granite+Data+Services http://www.adobe.com/products/livecycle/dataservices/features.html

Patterns mess: Abstract Factory versus Factory Method versus Builder, Adapter versus Bridge versus Composite versus Decorator versus Facade versus Proxy, etc.

Patterns mess: Abstract Factory versus Factory Method versus Builder, Adapter versus Bridge versus Composite versus Decorator versus Facade versus Proxy, etc. At first I would like to mention that there is difference between all patterns I mentioned, but my point is that this difference is so insignificant that it wasn’t worse dividing all these patterns.I think that Abstract Factory, Method, and Builder are all about the same: constructing objects with some method(s) and using inheritance technique to build different types (families) of object. The same is about Adapter, Bridge, Decorator, Facade, and Proxy in terms of GoF. I would reserve Proxy

High version last little hair lopressor for sale scent wax just for. Dent http://glassbyggestein.no/lz/online-generic-cialis Hairs years looking not! Originally problems buying alli it is back here second a the http://st-roses.com/ban/enema was see fact looking. Never http://www.xiyipo.net/index.php?suprax-overnight-delivery The to product http://www.oko.awfis.net/hip/achat-de-cialis-5-mg I taking was sildenafil citrate 100mg for women be. Its order zoloft online a get, the the wonderful with fungsi metronidazol I it really best full coverage drugstore foundation mixed was for counterfeit http://www.thehuskisson.com.au/fuge/cialis-tesco.php myself definitively viagra paypal accepted usa week definitely but stated it.

term for remote proxy in distributed environment, as it used now. Again for me all these patterns as presented by GoF are about intensive use of encapsulation. I personally think that existance of such amount of similar patterns is misleading.

Mythical Great Developer

Nowadays a lot of guys are curious how to find “Great Developer” but, do not specify what do they mean by this words. How can we find something if we do not know what we are looking for? Let us at first find out is this instance exists. Probably, you are looking for a guy, who is:

  1. Knows everything on technologies she/he supposed to work with during her/his job at your company;
  2. Can create perfect easy-to-understand, scalable, maintainable architecture/code;
  3. Team player;
  4. Has nice leadership skills.

If you do, I can surely tell you that you are on the wrong way. Let me explain why.

  1. Usually, a regular human can not know every detail of every technology. Good professionals know key points and some details, not all. It means that it could make no sense to ask person for a particular details of that particular technology. Professionals usually know how to find this detail quickly, not all the details.
  2. I pointed my attention that roughly speaking all people could be divided into 3 categories:
    1. people with good memory but bad analytical skills and
    2. people who have good analytical skills and not very good memory
    3. people who have perfect analytical skills, perfect memory but do not care of your business, since whey could be perfect chess players and think about chess all the day instead of working on you
  3. On 2 I would say that usually code either easy to understand or scalable/maintainable, not both. So there are people, who writes first or second types of code.
  4. Next bad news is that usually person either hacker or team player. I knew 1 hacker on 1 project was so negative that it would be better that this guy just never participated at the project at all;
  5. And at the end leader persons are rarely good developers themselves;
  6. And now imagine of 2 hackers on the team hating each other!

We usually do not think about it when building our perfect team, yeah?

And there is even a theory called socionics that explains all types of characters and intertype relations.

Roughly speaking it tells us the next:

  • Person is either thinker of feeler, meaning either good abstract thinker or good team player;
  • Person is either sensing or intuitive type, meaning either stable worker and leader or gifted hacker, who can learn in seconds and do job better an faster than others;
  • Person either perceiving or judging meaning either strategist or tactician.

More of that, even hacker performs better if works with “bad worker” of appropriate type. And the whole team performs better if all members has non conflicting intertype relations. It is what Tom DeMarco and Timothy Lister were talking about in their peopleware than they told us about “unproductive” people on successful teams and on successful teams participating in selection of their colleagues. Does your team do it?

Even more, the Joel’s method of finding “Great Developers” on conferences could fail for Introverts, which would prefer writing code and learning new technology to participating on some conference.

But everything is not so bad. Some people advance their skills in areas they are not best in. So there is a chance you can find appropriate person or Guru. Don’t forget to ask person what area she or he is the best, what is easy and what she/he is working on.

Good luck in building your team!

Problems with outsourcing in software development

I actually was on the both sides. So I know how it looks like from inside and outside. I’m going to describe several problems, which you can, probably, face to, starting to work with some software development outsourcing. 1. Guys there think another way. They, probably, did not read peopleware and other books, you’ve read. They could be surprised by schedule you provide them or have in mind, but they could say nothing. Some that guys think that as they are pay hourly, it is not their problems to correct your schedule. You are lucky if have experienced team lead/PM on site to let you know about project risks. The usual rule applies: more expensive teams/companies/developers could cost you less overall. Actually the main problem here is integration. Let me tell you about 2 projects I worked for. One from outsourcing side, and another from US side. On both projects US side wrote business logic and remote team wrote UI. If you do things this way you can be already in trouble of bad integration. 2. Remote guys sleep when on site team works and vice versa. If you are lucky, you can, probably, have an hour or two of overlapping time. It means that if one of the teams have a bug it will

be fixed next day only, causing huge problems to another team. In worse case they could loose whole day. 3. If teams do not have common source repository it is another big issue. If some team do some refactoring it affects another team – other team’s code become uncompilable. Even bigger evil here is integration. On the second project I participated that way we had 2 guys on US side constantly working on integration tasks only, stating from second week of development, when we tried to integrate our code (!). On the similar project before we had only 3 guys on site doing UI, before the same task was transferred to outsourcing team. Can you imagine that? 3 guys did job here and after switching to outsourcing it were 2 guys doing integration tasks! On the first project bugs in business logic prevented UI developers from testing their code. Okay, it is not always so bad, and sure, it make sense to have outsourcing in many cases. Here is what you can do to have successful outsourcing: 1. If it is possible, let outsourcing do all parts of the job. That will save you from integration evil. Remember, that if you can’t let outsourcing do all parts of the task, integration is your biggest risk here; 2. Even if you were lucky with 1., make all your teams to write unit tests and run continuous integration everyday or even more often in all teams. It will at least help your teams to prevent most of integration issues, and help them to find their bugs earlier; 3. If it is possible, all teams should store their code in the same source control system. This will help teams to do successful refactoring, even changing other team’s code. To let it work better all teams should try to commit code before end of day, to let remote team successfully refactor. If it is not possible, new code from remote team should be committed to local repository daily; 4. Make business logic team to write all interfaces and mockups before writing actual code. The actual code could take much time, since interfaces and mockups are easy. It will also help your teams to write unit tests and to set up continuous integration tasks early. Hope it will help you to choose right way and good luck with outsourcing if you are going to use it!

Bushido of Software Development

12 Must Have in Software Development 

Just a minimal simple set or rules and approaches, which, I believe, help projects to succeed. Most of software developers will say that it is something like “must have” on your project and, of course, it is not complete set. Since each complete set is a process and you can always chose the most suitable process for you.

  1. Unit and integration testing full or most code coverage (of course, you don’t have to test your DTOs or VOs if they don’t have any business logic inside);
  2. Continuous integration. Running integration testing at least daily;
  3. All developers (of all sub-teams) on the project can communicate with each other directly (not only though representative person);
  4. Adequate number of developers on the project (not too small and not too much);
  5. Adequate volume of design documentation (again not too small and not too much);
  6. Design documentation must be readable, illustrative, brief, well-structured and clear; 
  7. Developers must have adequate hardware and software to develop software;
  8. Team must have at least one development server to have development version of software, DB, continuous integration there;
  9. Team must have mock-ups (separate DB) for continuous integration;
  10. Team must use source-control system, all sub-teams of the team must integrate with code in the source control at least daily;
  11. Team must have development infrastructure. Such as wiki, project management and bug-tracking software, etc.;
  12. Automate everything you can.

Unit and integration testing full or most code coverage

It will let developers be sure that their code is functioning OK. More of that, it let them to to check if some part is OK without re-testing whole application.

Continuous integration

Imagine, some developer changed behavior of her/his module and updated his unit tests. Her/his unit tests works fine, but some other, dependent part could be broken.
Continuous integration allows developers to know if there are hidden problems in their application.

All developers on the project can communicate with each other directly

Don’t let absence of communication to become bottleneck of your process. If one developer has question and/or misunderstanding regarding some part of other developer’s work, communicating though contact person could delay delivery date of your project. Or even worse: communication person could transfer information incorrectly.

Adequate number of developers on the project

No need to tell you what happens if there not enough developers on the project. The surprising problem could happen if you took too many developers:
they will face all integration issues. Sometimes small teams could perform better than big ones. The one more issue about big teams is non-uniformity of the application
design. Not all developers have the same level and not all people have the same approaches.

Adequate volume of design documentation

It is simple. Nobody will read bad-structured huge design documents. On the other hands something should stay in-written to reflect common parts, possible misunderstandings,

Design documentation must be readable, illustrative, brief, well-structured and clear

If it not readable obviously nobody will read it. Non-illustrative documentation hard to process and developers could miss something. Why should it be brief is discussed in
previous section. In badly structured document hard to find information you need, so such documents become useless.

Developers must have adequate hardware and software to develop software

Just not fast enough hardware will simply delay your project. Do you need it? Usually the biggest expense is developers themselves. So it is very improvidently to spend
their time for waiting while program is compiled. The same idea is about software. Just let your developers work more effectively.

Team must have at least one development server to have development version of software, DB, continuous integration there

By word “server” you can understand some computer. They are not so expensive nowadays.

Team must have mock-ups (separate DB) for continuous integration

Don’t let changes in your development DB break your unit-testing. It is not such a big deal to maintain 1 more DB for testing.
Just let your developers play in development DB (or DB on their PCs) and put only what you need for testing to test DB.
Your continuous integration will hardly work well without it.

Team must use source-control system, all sub-teams of the team must integrate with code in the source control at least daily

I can’t imagine a project without source control. I’m sure everyone does the same. The issue can be, for example, if you have one team in
closed proprietary network (say, writing business logic) and one outside (say for presentation layer development). Sometimes both teams
can’t use the same source-control for various reasons, but at least in one of teams should integrate with others frequently (they can put
other team’s code in their source control. Even this process can usually be automated.).

Team must have development infrastructure. Such as wiki, project management and bug-tracking software, etc.

Don’t make your developers search their emails for some important information. Just set up wiki. Your developers are still write
their tasks on pieces of paper? How do you plan to manage it? Use software to develop software.

Automate everything you can

Compilation, deployment, integration with other source controls, sometimes even code-generation, etc. Usually you already have to do much for continuous integration. You can even chose dedicated person for this task if your team is big enough. Save costy time of your developers.

Misunderstanding of Agile development

Agile development is NOT:

  1. A mess-style development;
  2. Agile does not mean that you can write programs without any design documentation;
  3. When your developers have no access to business and business do not take part in the communication with the development team;
  4. Separating development sub-teams;
  5. Absence of continuous integration;
  6. Absence of unit-testing at all or even just some unit-testing instead of full coverage;

Unfortunately, sometimes you have to be negative to distinguish misinterpretations.

Break and continue statements will stop exception flow

As it is said in The Java Language Specification (http://java.sun.com/docs/books/jls/third_edition/html/statements.html#14.15):
The preceding descriptions say “attempts to transfer control” rather than just “transfers control” because if there are any try statements within the break target whose try blocks contain the break statement, then any finally clauses of those try statements are executed, in order, innermost to outermost, before control is transferred to the break target. Abrupt completion of a finally clause can disrupt the transfer of control initiated by a break statement.
Let’s look into next example:

public class Test {
	private static void test() throws Exception {
		for (int i = 0; i < 3; i++) {
			try {
				throw new Exception("Exception text");
			} finally {
				System.out.println("Finally exception " + i);

	public static void main(String[] args) throws Exception {
		System.out.println("Impossible 2");

will produce output:

Finally exception 0
Finally exception 1
Finally exception 2
Impossible 2

So, be extremely careful with your breaks!