Archive for category Uncategorized
Continuous delivery implementations differ due to company testing culture
Posted by Morten in Uncategorized on July 25, 2011
I just finished reading a post about continuous delivery at Outbrain. It’s quite interesting they made a trip similar to what we have done at RemoteX. However their setup is some what different than in the our. They use a tool called Glu to do deploy to the their different target environments and deliver RPM’s for their services.
At RemoteX we produce .exe files as well as a set of web services so I guess there will be significant differences when looking at the actual deployment.
What I find interesting is that they seem to go directly from the builds in TeamCity to starting deployment, where we at RemoteX have several steps after the commit stage to package and verify our release before its pushed out.
Outbrain also seems to be able to target specific environments to deploy to in a greater extent than we do at RemoteX. At RemoteX we instead categories our system installations to gradually deploy to all our installations.
This brings up something that seems to be common when reading Continuous Delivery war stories. They all agree (mostly) what what Continuous Delivery is all about, but they all implement it differently and have different areas where the solution is stronger or weaker.
The pattern seems to be that once the product goes out to customers there are different cultures at the companies that requires different solutions. The example of deploying to specific environments or deploy to categories of customers for example.
These cultural differences seem to all be focused around faith in the quality of the product. With in turn boils down to faith and investment in automated testing vs. manual testing.
In theory it would be possible to see what the culture at a company is like regarding to their faith in their own deliverables, by looking at their continuous delivery solution.
PowerShell logs even caught errors
Posted by Morten in Uncategorized on July 18, 2011
An interesting PowerShell feature is that all errors are collected in an array called $error.
so for example if you throw an error you can echo $error and find it later:
However the error is also logged even if you catch it. Consider the following code snippet, which I’ve called errorcollectiontest.ps1
When running the script it outputs nothing, but when we check the errors array we find something interesting:
What does this matter?
Well if you have a system running PowerShell a convenient way to see if there were errors in the execution of a script is to check the $error array for any errors. However this array will also contain errors that were caught during the execution, which will introduce false-positives.
The PowerShell plugin for Hudson/Jenkins does exactly this, so if you want to use a PowerShell script that catches errors in Hudson/Jenkins the way to prevent false positive build results is to make the following change to the script:
This will remove the latest occurred error from the list, which just happens to be the error just caused since we entered the catch block.
I’d like to mention Johan Andersson, in this post, since without him it wouldn’t be written.
The PropertyChangedCallback on a DependecyProperty is never called on NotifyPropertyChangedEvents for certain properties
Posted by Morten in Uncategorized on July 11, 2011
The user interface of RemoteX Applications has a concept of linking objects to each other. This is described in the UI very similar to a link on a webpage. Some of these links can be changed using an autocomplete like scenario.
These links have had us create user controls to handle them. We’re doing some changes to the interaction to these controls as such we had an issue where the controls never updated their content. This was due to the PropertyChangedCallback was never fired on their dependency property.
The backing field for a link looks something similar to this:
public IRef Contract { get { return _contract; } set { _contract.Href = value.Href UpdateContract(); OnPropertyChanged( Properties.Contract ); } }
As you can see the actual object is never changed, we just change the link on the object.
Apparently WPF optimizes its bindings using ReferenceEquals. The PropertyChangedCallback event is never fired if the bound property is still bound to the same object. so the user control never gets the changed object. This can cause problems for other scenarios as well.
The solution for us was to always return a new copy of the link. That way the user control’s PropertyChangedCallback is always fired. Example below:
public IRef Contract { get { //We need to return a new instance of an IRef here since WPF does ReferenceEquals to check for changes return new Ref<IContract>(_contract); } set { _contract.Href = value.Href UpdateContract(); OnPropertyChanged( Properties.Contract ); } }
change of service agreements
Posted by Morten in Uncategorized on July 4, 2011
I read two articles yesterday (which is a while back when this post hits the blog). The first was the closing of iFlow reader, which is sad and out-right wrong as seen from a market perspective. There should be some marketing laws that prevent the elimination of competition in this way. Obviously Apple is scared of the competition. This post isn’t about Apple how ever. I also read the year a head for Google AppEngine, where Google announced that they were changing their subscription plan for AppEngine.
This is of course perfectly fine for Google to do, in fact it’s not that big of a deal. Their pricing still makes sense. But as a developer who was some services on AppEngine I have to consider. What happens if Google suddenly changes their pricing model to a model which doesn’t work with the plans for my services?
Suddenly I have to move my services else where, but with AppEngine I’ve developed most of the backend solution for Google AppEngine. Sure you can host Django on AppEngine and then move to a Django based hosted solution in the cloud, but there’s still the API:s that are used.
I guess what we can learn from iFlow is to keep check of what your dependencies are on service agreements for your services, and have backup plans in case things get out of hand.
Listing executed actions – A PowerShell surprise
Posted by Morten in Uncategorized on June 27, 2011
I was hacking around in PowerShell the other day, when I managed to press a few buttons on my keyboard. To my surprise there were some GUI implemented into PowerShell. I did not know this, so here’s a post about this GUI awesomeness (warning for extremely beautiful interface designs).
Executing commands
Pressing F7 brings up this fantastic piece of UI: It allows you to scroll through the commands you’ve executed and selecting it visually from a list.
F9 brings up this:
This allows you to execute a command based on the number it has in the execution list.
using the two in combination by first pressing F7 followed by F9:
This allows you to see which command you want to execute before writing the actual number.
Modifying commands
F2 brings up this prompt:
It allows you to copy the currently typed command from the cursors current position up to a specific character.
F4 brings up this prompt:
This allows you to delete characters on the command line from the cursors position to a specific character.
Closing
All in all their not *that* amazing, but they were a pleasant surprise to see something new in the prompt.
Basic Authorization fails for special characters with JQuery on mobile-web-kit
Posted by Morten in Uncategorized on June 20, 2011
We are using Basic Authorization for our REST-api at RemoteX and it’s no surprise that we have a lot of special characters in our usernames (åäö and spaces). What’s interesting is that using JQuery.ajax() with just username and password will fail for these special characters.
Encoding the username and password options to the .ajax() call will make it work on Android but still will not work on iOS.
After some research started using the method outlined here: http://blog.rassemblr.com/2011/05/jquery-ajax-and-rest-http-basic-authentication-done-deal/
Where they set the Request header before sending the request to the server. What we noticed is that doing this will work only if you also clear the username and password options to .ajax()
so for us it became something like:
options.beforeSend = function(xhr) {
xhr.setRequestHeader("Authorization", "Basic " + options.base64);
};
var base64 = Base64.encode(options.username + ":" + options.password);
options.base64 = base64;
options.username = "";
options.password = "";
Also we used the Base64 encoder found here: http://www.webtoolkit.info/javascript-base64.html
The crypto-js base64 encoding didn’t work for us for some reason.
Making it easy to work with performance
Posted by Morten in Uncategorized on June 13, 2011
We’ve been working with performance in our REST API a while back. We’ve been considering different options for measuring our API in production, but we had an idea to use the design of the API itself to handle the measuring.
Part of the inspiration came from the Changlelog’s coverage of CodeConf and Coda Hale’s Metrics talk. (Slides).
Using our pipeline approach to constructing a REST-API with conventions, we added a pipe that starts a stopwatch and stops it when the request is finished. Then we can log statistics for each individual part of the API, closely coupled with the code that is executed for that particular request. I pitched the idea to my good colleague Johan Andersson, and he did a fantastic job at implementing the solution!
The output looks something like this:
This allows us to see how our API is performing in production, and where we need to focus our optimization efforts to make the API go faster. We can even add some flags to the request to get more detailed output.
The power of nested describes in Jasmine
Posted by Morten in Uncategorized on June 6, 2011
I’m experimenting with the Jasmine JavaScript testing framework to see if I can create a cucumber style testing framework using JavaScript. I want to go full out TDD on it so I started with a feature file, now I’m working on a spec to get that file running.
However as I work I get stuck on the following:
The description is too high level!
What happens when I load the feature file? Obviously a feature is loaded, but how? Something needs to happen between loading the feature and running the steps. My test needs to be more detailed.
Why not describe the load function then?
At once I realized that the load function needs to be asynchronous.
Job dependencies in Hudson for our Continuous Delivery effort
Posted by Morten in Uncategorized on May 30, 2011
I’m continuing our work with our Continuous Delivery effort. Were migrating from our previous build system to Hudson since it makes builds much more accessible.
The work started with the continuous delivery with hudson project I have on github and were slowly adapting a fork of that to work with out scenarios.
We realized that the amount of builds that we will be hosting in Hudson might make it hard to get an overview of what depends on what. After some research I found out that you could add the following to the URL of your hudson to get a dependency graph of all the builds:
/dependencyGraph/graph
So if you host Hudson locally it would look like:
http://localhost:8080/dependencyGraph/graph
This is how our current dependency graphs looks like:
The package output build takes the result from our old package build and migrates it over to the delivery pipeline. The Template Schedule Deploy job (which I now realize is a bad name) takes a set of “job files” and run the deploy installation job with the given settings.
The Create job files based on search creates the job files that the template deploy job works with, and the upgrade early, test, and bulk installations does a search in our installation of RemoteX Applications to find out which installations to upgrade based on the units in RemoteX Applications.
Each job then run the deploy installation build (not visible in the graph) to deploy the upgrade for each customer. In essence running the same build for upgrading that we use every time we deploy anything.
Development as a team or development as stars?
Posted by Morten in Uncategorized on May 23, 2011
A good friend and colleague of mine Johan Andersson read somewhere that you can see the communication patterns of a company in the architecture. I can see how that makes sense, but I think its much clearer than that. I think you can see the communication patterns of a company in the interface of its products. Both API’s and UI.
Every bump in the flow of a product, every view that is different from the main theme, every glitch in the feel of the application. They all show where a Star has solved a problem. They all show where communication failed and brute force problem solving stepped in to save the day.
An example could be an integration that uses a mostly unused field to store some information that it was not meant to store. Such as dates being printed in a text-field. Or having to leave the application to complete parts of the workflow on a webpage (or on a different site).
If we consider an application and its features as an onion. At the heart of every application there is a core functionality, the minimum viable product. On this other features evolve, or are developed. In essence making it a bigger onion for every aspect covered.
It could look something like this:
 |
 |
| Teamwork feature circle | Star work feature circle |
Now let each layer be complete, if the workflow of the feature is complete. A layer is incomplete i.e. graphed, if they break the flow of the product in order to solve a problem. If they just add enough functionality so it solves the task at hand.
Naturally these describe the wholeness of the experience, and is not tied to the implementation in any other way other than the feeling one gets when using the product. A product developed with good teamwork feels whole and complete around each feature. A product developed with individual stars will still solve the task at hand, but the experience of using it is scattered and lacks flow.
Is this bad?
Pros
- The problem was solved
- Functionality is implemented as the customers wish
- A sale was hopefully made, money was gained
- It might have gone faster due to reduced communication costs
Cons
- There is a glitch in the workflow of the application
- Something looks astray if you consider the whole
- There is a severe risk of bugs being introduced at a later stage, due to things not working as expected
- It might cause rework to repair the flow, or fix the later introduced errors
These lists are probably longer, but they show the pattern
Let’s look at this from a sales perspective. If your method of selling is by listing features and selling a complete system, the stars approach is desirable, it will give you a list of features quickly. At the risk of the development going slower further down the road, especially if you build on “previous” features.
If you, however, sell by demos or free trials, showing the experience of the product and how convenient it is while solving the problem. Working with previous customers who testify to the product’s stability and trustworthiness. The teamwork approach will most likely give you the best experience, and reduced amount of bugs. Thus it might go faster in the long run.
From a buyers perspective, I’d rather use a product with complete flows.
Now ask yourself, are you a star or are you a team member?
How does your organization sell its products? Does selling like that benefit Star development or Team development?
What benefits your organization most? Teamwork or stars?