Posts Tagged Software
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.
Inventory in software
Posted by Morten in Uncategorized on May 5, 2010
I’ve been thinking a bit about all these factory references that occur when discussing software development. So here is an inventory management view, I guess.
Inventory, viewed from a lean perspective is waste. If you can keep your process running with minimal inventory, then you can decrease costs for changing the process.
Software is immaterial, so there is no “inventory” per se. But, there are equivalent cost scenarios.
Here are a few examples of inventories that occur during software development:
- Documentation
- Versions of the same software in production
- Source-code
- Issue tracking systems
I’ll describe the cost scenarios for these examples, there is probably more.
Documentation
As soon as you write your documentation, it starts aging. Documentation, be it help documents or documents describing the system, are like groceries. They go old, and they do so in different rates. Some documentation is more resistant to change while other gets outdate faster than you can write it. This implies a maintenance cost for documentation, either keep it up to date or throw it out. The cost of someone using old documentation could be very expensive.
Versions of the same software in production
A favorite of mine. Every version you have in production has its own personality, it’s own quirks, features, bugs and what not. This implies greatly increased support costs.
Source-code
Source-code is also a sort of inventory. The more code there is the more there is to maintain. Sure you might not change the code all that often, but unless your code is separate products, it interacts. Larger code-bases require more testing (be it automated or manual testing). Good design helps reduce the size of the code base, and from a cost perspective keeping the codebase low is very important.
Issue tracking systems
Issue tracking systems is just an inventory of reported issues. As it grows the cost for maintaining the issues grows. Every release has the potential to solve any issue, which could at worst imply workload on developers to keep, not only the source-code and documentation up to date, but also the issue tracking system. Secondly, if it takes too long between something being entered into the tracking system and it being fixed. Then the people, stakeholders, for that issue have forgotten about it or worked around it in some way. Also most of the time, the act of managing and tracking the issue costs far more than just fixing it.
Reducing inventory
So what to strive for, only keep documentation for which you commit to writing and maintaining. Have one version of the system in production, and get mechanisms into place to quickly update all clients so you can keep it so. Keep your code-base small, strive to solve problems using better design and less code. Think more, code less. Last but not least, fix problems as they occur, strive for zero-defects. If your using Scrum you can handle issues in a sprint, but avoid long-running tracking.
Presenting JS-Analytics
Posted by Morten in Uncategorized on May 4, 2010
With the success we had with EQATEC Analytics at RemoteX I started looking around for something similar, but for JavaScript. I didn’t find anything that satisfied my needs.
Thus I created my own error collecting and analysis tool, and named it JS-Analytics.
You use it similar to how you use Google Analytics, you add a few given script tags to your website and JS-Analytics will try to collect any unhandled JavaScript error that occurs, and send information about it back to JS-Analytics website.
JS-Analytics uses a combination of window events to collect errors. These events aren’t available on all browsers so JS-Analytics will use JQuery to provide cross browser support. This means that cross browser support is only available for JQuery code.
For more information about how it works I recommend this page.
Right now this JS-Analytics provides just some basic analysis. But I felt that it was better to announce it and hopefully get some feedback on it, than to carry on without any feedback.
Measuring defects
Posted by Morten in Uncategorized on May 3, 2010
I was working on performance tuning for the mobile client of RemoteX Applications when I found a tool called EQATEC Analytics. Six month later I added it to our clients for the first time.
EQATEC Analytics is quite interesting, for RemoteX it solves an interesting issue. Error reports are hard to collect from Compact Framework devices, especially since all error messages state that “we’re missing the translation pack to translate these errors, thus you get this crappy errors message instead”.
EQATEC Analytics captures all unhandled exceptions and report them back to a server application for analysis. This means that all crashes are reported so they can be analyzed by us, without involving the user in the information collection process. (no personal information is sent to the server)
The benefits of this enormous. We can see the quality trends of our applications (at least when it comes to crashes), and fix the errors that occur the most.
Traditionally the errors are fixed based on the information received by customers, manual error reports and what not. Relying on this type of information means that you fix the errors that most people report, or the errors you can reproduce. With EQATEC Analytics you, you can get an exact stack trace indicating the problem area, and depending on how you configure it to work you can also request information regarding what was happening during the crash.,
It also provides an excellent way to see if our efforts of improving the quality of the product is helping or not.
Now it also has features to collect information about what kind of system our applications are run on, and also collect statistics of which features are used in the applications.
We’ve used EQATEC Analytics in production since January 2010 and so far we are very happy with the results.
An interesting note here is that the next version of Shuffle will use a similar tool for Android, called Flurry.
Inheritance of features
Posted by Morten in Uncategorized on January 14, 2010
Given my recent combining of Tracks and Shuffle. An interesting thing happened. Something that happens when you combine two products so that they inherit features from each other.
On Shuffle’s issue list there are a few items currently regarding repeating tasks, and the ability to hide a task for a period of time. Tracks has these features, since Shuffle can synchronize with Tracks, Shuffle now also have these features. That is if you choose to synchronize with Tracks.
I’ve done a few integration projects thus far. And the ones that are truly successful are when they take the aspects and features of both applications into consideration, to create a win-win scenario between the two applications.
Here is another recent example. At RemoteX, we recently integrated a system that handles the ordering of materials, goods, equipment etc. In essence this integration feature means that you can go to a retailer, order goods, specify the order they should tag the invoice with. End result, RemoteX automatically adds the goods to the application and if possible attaches a copy of the invoice to the case. Ready to be billed to the customer. Since the other system has integrated with almost all resellers of service equipment in Sweden, the daring customers running this set-up can, at least in theory, eliminates the need for keeping stocks of equipment or goods in house.
If you understand where these synergy effects can show up you can also align the integration so that both applications maximizes the gain of integrating with the other system. This is important to think of when designing an integration, how do we achieve the maximum win-win?
I write laws
Posted by Morten in Uncategorized on October 19, 2009
I went through a business contract, analysing it for weaknesses. I found a not likely case, but still pointed it out.
“You should be a lawyer”, the lawyer says
“I write laws”, I reply.
Now why am I writing this?
Well, there are similarities to developing Laws and developing business systems. Laws are rules in which we humans can work within to achieve value. The value Laws strive for is the value of functional society, a functioning system.
Now developing business software can be viewed in the same way. When developing the software we state the laws in which the users can generate data. The UI is a constraint or law, the business rules are different kinds of laws, and so on. The value we strive for is correct business data, another kind of functioning system.
How it is to live under these governing systems i based on the values they are built upon. A Mac user have different values regarding usability, design, and in some cases “quality” – compared to a Windows user.
Developing software is a team effort. The development team are the legislators of the product they are developing, so which values are governing your software?
Changing the platform of ClickOnce deployed applications breaks automatic upgrade
Posted by Morten in Uncategorized on May 27, 2009
I wrote earlier about and issue with ClickOnce Deployment, where the processor of the deployment manifests need to match the processor the application is compiled for. Naturally of course, it turns out we need to compile for a specific platform.
By compiling for x86 and marking the deployment manifest as x86 we managed to get some applications running on 64-bit machines. These applications have dependencies on assemblies that crashes if they are run on 64-bit machines, but aren’t compiled for any specific architecture.
So we recently changed to x86 on most of our ClickOnce-deployments. This resulted in the following error when upgrading previous versions.
+ The deployment identity does not match the subscription.
Apparently when we change the application to compile using x86 the applications identity is changed. This means that the ClickOnce-deployment doesn’t work when we shift from All Platforms to x86.
Funny piece of C# code I found today
Posted by Morten in Uncategorized on May 26, 2009
Today I found this piece of code in an integration to RemoteX Application.
switch (ConfigurationManager.AppSettings["UsePriority"])
{
case "false":
switch (... )
{
case true:
log.Write ...
break;
case false:
log.Write ...
break;
};
break;
case "true":
switch (... )
{
case true:
log.Write ...
break;
case false:
log.Write ...
break;
};
break;
}
The dotted out code was application logic, so I omited it.
Source control folder anti-pattern
Posted by Morten in Uncategorized on May 21, 2009
I ran into this issue at work today. Another team depends on my teams code to create customer specific solutions. Now they have an issue where they have to keep track of which versions are currently in use, and produce software for the different solutions. Now I have issues with keeping more than one version of working software in production. The administrative cost for this is enormous and it keeps the organization from scaling.
This is one of the problems that could arise from keeping more than one version of the same software in production. The team that creates customer adaptions have to keep references to the different versions of code.
This means that they might have to compile the same code but with two different versions of the software. Either they keep two versions of their software checked in under source-control at two different locations, or they keep two versions of the references checked in, or both.
Using source-control in this way defeats the purpose of using source-control. You do not use the time dimension of the source control system, instead your just using it as a shared folder.
Instead the way to use source-control is to check-in the references for each version they have to support, in order. Keeping them at the same place, this enables them to get the specific version of the reference and compile a custom delivery for that specific version. That way you are working with the time dimension instead of working in parallel to it. Dependency management can become a pain in the rear if you don’t use the tools for what they are worth.
Updating ClickOnce deployment manifest with PowerShell
Posted by Morten in Uncategorized on May 20, 2009
We are automating some of our deployment using powershell. As such we use the command line tool mage.exe for signing our deployment manifests, in effect were creating them using mage.exe as well.
We needed to add the trustUrlParamter setting to one of our manifests. Using mageui.exe you just check the box for allowing the application to see the query string, but with mage.exe this isn’t possible.
What you need to do is modify the XML of the application.deployment manifest, adding the parameter as an attribute to the deployment tag.
<deployment install="true" >
Should become
<deployment install="true" trustURLParameters="true">
As I said, we’ve already automated the process of creating and signing deployment manifests using powershell, now we just need to add the element attribute before signing the manifest. Powershell has some nifty features for updating XML, part 3 of Windows PowerShell in Action: Working With Text and Files in Windows PowerShell (Part 3) demonstrates this.
So just before invoking mage.exe to sign the manifest we add this litle piece of powershell code:
$xml = [xml]( Get-Content $deploymentManifestPath )
$trustUrl = $xml.CreateAttribute("trustURLParameters")
$trustUrl.psbase.Value = "true"
$null = $xml.assembly.deployment.SetAttributeNode($trustUrl)
Voila, the manifest now has the trustURLParameters set.