4/21/2013

Continuous Delivery - Part 6 - Backward & Forward Compatibility

Filed under: — Aviran Mordo

Previous Chapter: Startup - Self Test

One very important mind set developers will have to adopt and practice is backward and forward compatibility.

Most production system do not consist on just one server, but a cluster of servers. When deploying new piece of code, you do not deploy it to all the servers at once because part of Continuous deployment strategy is zero downtime during deployment. If you deploy to all the servers at once and the deployment require a server restart then all the servers will restart at the same time causing a downtime.

Now think of the following scenario. You write a new code that requires a new field in a DTO and it is written to a database. Now if you deploy your servers gradually you will have a period of time that some servers will have the new code that uses the new field and some will not. The servers that have the new code will send the new field in the DTO and the servers that not yet deployed will not have the new field and will not recognize it.

Continuous Delivery - Backward & Forward Compatibility

One more important concept is to avoid deployment dependencies where you have to deploy one set of services before you deploy the other set. If we’ll use our previous example this will even make things worse. Let’s say you work with SOA architecture and you have now clients that send the new field and some clients that do not. Or you deploy the clients that now send the new field but you have not yet deployed the servers that can read them and might break. You might say, well I will not do that and I will first deploy the server that can read the new field and only after that I’ll deploy the client that sends it. However in Continuous deployment as easily as you can deploy new code you can also rollback you code. So even if you deploy first the server and then the client you might now roll back the server without rolling back the client, thus creating again the situation where clients send unknown fields to the server.
(more…)

4/17/2013

Tip: How to remove / disable metro UI windows 8

Filed under: — Aviran Mordo

For those of you who installed Windows 8 and don’t like the new Metro UI there is a simple way to revert back to the old familiar look of Windows 7. Here is how you do it:

Open the Regedit by typing regedit or by pressing the Windows Key + R combination and type regedit and click OK.
Navigate to HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer
Find the key RPenabled and change the value from 1 to 0.

4/14/2013

Continuous Delivery - Part 5 - Startup - Self Test

Filed under: — Aviran Mordo

Previous Chapter: A/B Testing

So far we discussed Feature Toggle and A/B testing. These two methods enable safe guards that your code does not harm your system. Feature toggles enable to gradually use new features and gradually expose it to users, while monitoring that the system behaves as expected. A/B testing on the other hand let you test how your users react to new features. There is one more crucial test you as a developer should write that will protect your system from bad deployments (and also be a key to gradual deployment implementation).

Self-test sometimes called startup test or post deployment test is a test where your system checks that it can actually work properly. A working program does not only consist of the code that the developer write. In order for an application to work it needs configuration values, external resources and dependencies such as databases and external services it depends on to work properly.

When an application loads and starts up its first operation should be Self-test. Your application should refuse to process any operation if the self-test did not pass successfully.
(more…)

4/9/2013

Microsoft: Google unfairly using Android to promote Google’s products

Filed under: — Aviran Mordo

About a decade ago, if we were to tell you that Microsoft is part of a group who is filing a complaint against another software giant who they feel is unfairly using its own software to promote it’s own products, you would have thought we were crazy. But that is exactly what is happening today in the EU as Microsoft, Nokia, and a few other companies are accusing Google of unfairly using its own Android software to promote Google’s products and services.

Sound familiar? It should, it’s a similar complaint that Microsoft faced many years ago that resulted in the browser ballot that you see today and also the N versions of the Windows platforms in Europe. The NYTimes is citing a lawyer for Fairsearch, Thomas Vinje, who filed the complaint, that represents these large corporations by stating that Android software is “a deceptive way to build advantages for key Google apps in 70 percent of the smartphones shipped today”.

This is kind of typical to large companies, if they can’t compete they try to buy you, if they can buy you they’ll sue you. Microsoft and Nokia don’t believe Windows 8 can compete with Android and gain market share, the same way Android competes with iOS and eventually won ?

4/4/2013

Continuous Delivery - Part 4 - A/B Testing

Filed under: — Aviran Mordo

Previous chapter: Continuous Delivery - Part 3 - Feature Toggles

UPDATE: We released PETRI our 3′rd generation experiment system as an open source project available on Github

From Wikipedia: In web development and marketing, as well as in more traditional forms of advertising, A/B testing or split testing is an experimental approach to web design (especially user experience design), which aims to identify changes to web pages that increase or maximize an outcome of interest (e.g., click-through rate for a banner advertisement). As the name implies, two versions (A and B) are compared, which are identical except for one variation that might impact a user’s behavior. Version A might be the currently used version, while Version B is modified in some respect. For instance, on an e-commerce website the purchase funnel is typically a good candidate for A/B testing, as even marginal improvements in drop-off rates can represent a significant gain in sales. Significant improvements can be seen through testing elements like copy text, layouts, images and colors.

Although it sounds similar to feature toggles, there is a conceptual difference between A/B testing and feature toggles. With A/B test you measure an outcome for of a completed feature or flow, which hopefully does not have bugs. A/B testing is a mechanism to expose a finished feature to your users and test their reaction to it. While with feature toggle you would like to test that the code behaves properly, as expected and without bugs. In many cases feature toggles are used on the back-end where the users don’t not really experience changes in flow, while A/B tests are used on the front-end that exposes the new flow or UI to users.

Consistent user experience.
One important point to notice in A/B testing is consistent user experience. For instance you cannot display a new menu option one time, not show the same option a second time the user returns to your site or if the user refreshes the browser. So depending on the strategy you’re A/B test works to determine if a user is in group A or in group B , it should be consistent. If a user comes back to your application they should always “fall” to the same test group.
(more…)

Powered by WordPress