All posts by Code Curmudgeon

I've been working in Software Development at Parasoft since 1992 - which in my opinion is before the epoch (my measure being the first real use of the web). I've been involved deeply in creating software, creating software tools, and helping customers address their software problems including automotive, cybersecurity and embedded. The views and opinions expressed herein are those of the author and do not necessarily reflect the views of anyone else on the planet. Caveat lector. You can follow me on twitter @CodeCurmudgeon, Google+, Static Analysis for Fun and Profit, Facebook, and LinkedIn.

Getting the Static out of your Analysis

Day 11 / 365 - Touching static © by xJason.Rogersx
The other day I was talking to a colleague about setting up static analysis properly. I was on my usual soapbox about all the simple steps you can take up front to insure success, and he suggested that I should blog about it, so here it is – How to properly configure your static analysis from the beginning.

This presumes that you’ve already gone through the trouble of selecting the proper tool for the job. And you’ve setup policies and procedures for how and when to use it. What I want to focus on is getting the rule set right.

As I’ve mentioned before there are quite a few ways to have troubles with static analysis, and noise is one of the chief culprits. You want need to make sure that noise is far out-weighed by valuable information.

Noise comes about primarily from having the wrong rules or running on the wrong code. It sounds simple enough, but what does it mean?

The Wrong Rules

Let’s break the wrong rules down into the various ways they can trouble you. First, noisy rules. If a rule makes a lot of noise or gives actual false positives, you need to turn it off. False positives in pattern-based static analysis are indicative of improperly implemented rules, and should be fixed if possible, turned off it not.

On the other hand, false positives in flow analysis are inevitable and need to weighed against the value they provide. If the time spent chasing the false positives is less than the effort that will be needed to find the bugs otherwise, then it’s probably worth it. If not, turn the rule off.

But there are other kinds of noise. Some rules may technically be correct, but not helpful. For example rules that are highly context dependent. Such rules in the right context are very helpful but elsewhere are far more painful than they are worth. If you have to spend a lot of time evaluating whether a particular violation of a rule should be fixed in this particular case, you should turn the rule off. I’ve seen a lot of static analysis rules in the wild that belong in this category. Nice academic ideas, impractical in the real world.

Another way to recognize a noisy rule is that it produces a lot of violations. If you find that one rule is producing thousands of violations, it’s probably not a good choice. Truthfully, it’s either an inherently bad rule, or it’s just one that doesn’t fit your teams coding style. If you internally agreed with what the rule says to do, you won’t have thousands of violations. Each team has to figure out exactly what the threshold for too many is, but pick a number and turn off rules that are above it, at least in the beginning. You can always revisit it later when you’ve got everything else done.

One area of rules that frequently gets called noise is when developers either don’t understand the value of a rule, or simply disagree with it. In the beginning such rules can undermine your long-term adoption. Turn off rules that are contentious. How can you tell? Run the results past the developers – if they complain, you’ve probably got a problem.

It’s important that the initial rule set is useful and achievable. Later on you will be able to enhance the rules as you come into compliance and as the practice itself becomes ingrained. In the beginning, you need your static analysis tool to deliver high value. I ask myself, would I hold off shipping this code if I found this error? If the answer is yes, I leave the rule on, if not, it’s a poor candidate for an initial rule set. This is what some people call the “Severity 1” rules or high priority rules.

The Wrong Code

Sometimes particular pieces of code are noisy. Typically this ends up being legacy code. The best practice is to let your legacy policy guide you. If you have a rule that legacy code should only be modified when there is a field reported bug, then you don’t want to run static analysis on it. If you have a policy that when a file is touched it should come into compliance with static analysis rules, then use that. Otherwise skip it. Don’t bother testing any code that you don’t plan on fixing.

Checking the configuration

Once you have a set of rules you think is right, you should validate that. Run on a piece of real code and look at the number and quality of violations coming out. If the violations are questionable, or there are too many, go back to square one and weed them out. If they’re reasonable, pick another project, preferably from a different team or area, and run the test again. You’ll likely find a rule or two that you need to turn off when you do this. After that, you’ve got a pretty reasonable chance of having a good initial rule set.

Long term

In the long term, you should be adding to your rules. You want to resist the temptation to get all the rules in the initial set, because you’ll get run over with too much work. Plus as developers get used to having a static analysis tool advise them, they start improving the quality of the code the produce, so it’s natural to ratchet it up from time-to-time.

When you see that a project or team has either gotten close to 100% compliance with your rules, or if they’ve essentially plateaued, then you want to think about adding rules. The best choice is not to simply add rules that sound good, but rather choose rules that have a relationship to problems you’re actually experiencing. If you have performance issue, look at that category for rules to add, and so on.

Spending the time upfront to make sure your rules are quiet and useful will go a long way to insuring your long term success with static analysis.

[Disclaimer]
As a reminder, I work for Parasoft, a company that among other things make static analysis tools. This is however my personal blog, and everything said here is my personal opinion and in no way the view or opinion of Parasoft or possibly anyone else.
[/Disclaimer]

Resources

The Ins and Outs of Opting and Privacy

There has been another rash of security and privacy issues by major internet companies. Actually it’s more of an ongoing issue than it is a recent outbreak. And much of the ongoing trouble is related to a poor understanding of “opt in” vs “opt out” methodologies, and some pretty poor business choices in that area.

Keep Out © by Aaron Jacobs

Google (GOOG) just announced that wireless network owners can no “opt out” from its Wi-Fi geolocation map database. Many have greeted this as good news and responsible behavior on Google’s behalf. Others, myself included, view this as a classic case of a business doing essentially nothing to change it’s behavior, and then promoting the non-effort as a valuable security benefit to their customers and the world at large. Google believes that once you’re using any of their services, you’ve essentially opted in to anything they want to do. More on that in a minute.

Another consumer favorite, Facebook appears to be tracking 90 days of everything it’s users (and some suggest even former users) browse on the web. This is beyond just tracking what you’re doing inside Facebook itself. And there are also allegations over whether or not they actually are storing profile information about people who have not even joined Facebook. This is another company that believes in a policy of opting you in to anything they want and then letting you opt back out. They know that a lot of people aren’t savvy enough to understand, others too lazy, and others will never even be aware of the issues.

Verizon (VZ) tracks everything you do with your phone, so do pretty much all the cell phone companies. Recently Verizon started allowing people to opt out. Josh Constine at TechCrunch mentions that at least they don’t call it “Greater Choice” like Google does. But his take is everyone is saying “Why can’t we be evil too?”

Strangely enough, AT&T (ATT) takes the opposite move of letting people opt in. Pretty ironic for a company who’s logo resemble the Death Star, but commendable.

The problem with “opt out” is that it works well outside of privacy areas. It also works in areas where you have an explicit relationship. For example, if I create a Google account it will keep track of what I search, unless I opt out. Most companies that have web accounts work in this way, for example with their email lists. This is a very reasonable method – you contacted me, so you don’t mind if I contact you. You see this normally as little “send me your junk email” boxes. You can judge the company based on whether the boxes are clicked or empty by default on their sign-up forms.

The stakes for things like this are low – the worst case is that some web site sends me a bunch of junk email, and if they’re a responsible company, they’ll respond to my “stop that” request.

The difference with privacy issues is that the stakes are much higher, and the awareness is much lower. If someone decides that by using their website I agree to let them track my every move on the web, it’s unlikely that I’ll ever figure it out. And they may end up being privy to something I didn’t want to share with them. Opting people in by default to such things is unethical behavior at best. What’s the rational connection between me using your website and me giving you permission to spy on all my web activities? There is none of course.

In the case of the Google Wi-Fi mapping they’re collecting your data whether or not you have a relationship with them. This is one step worse than the Facebook issue. In this case they’re literally driving the streets of the world looking for Wi-Fi (we used to call this warchalking) and then adding you to a database. You may not even be aware they’re collecting your data. In fact, the odds that homeowners ARE aware are extremely small. And yet they’re using on opt out methodology, just to cover their butts. Which essentially means that they’re opting you in to something, without your permission, without your awareness. And they justify that because their company motto is “Do No Evil”.

The truth is that it’s a very questionable practice to collect someone’s information without their knowledge. If they want to build a database, then can simply switch to an opt in method. Instead of my changing my SSID if I happen to know that they might drive by someday, (which is inconvenient because I have to reset all the devices using my network, including frequent guests devices) they can go to a method where they only collect data from those who indicate willingness by changing the name. Instead of changing my SSID from “mynetwork” to “mynetwork_nomap” to opt out, I should be able to change to “mynetwork_map” to opt in. Anyone who doesn’t want it doesn’t have to do anything. Anyone who is unaware will not be unintentionally opted in. Anything less is not only unfriendly to consumers, it’s just plain evil.

Developing Clouds in the Forecast

These days everyone it seems like everyone has their head in the cloud. At least from an interest level that is. When it comes to actually using the cloud, they’re not necessarily ready for a real cloud deployment. The conversation usually goes something like this:

Clouds © by karindalziel
“Do you support cloud?”

“Sure, what did you have in mind?”

“We don’t know, but we know we want to do cloud at some point. Can you make your tools available to us in the cloud?”

“Yes, I can, what model do you want to use and will fit your security needs?”

“We can’t actually open our firewall, and we can’t share our source code outside the network. Maybe a private cloud…”

And it goes on from there. I’ve played this script over and over again. Lots of intellectual interest in cloud, but without any real understanding of both the issues involved as well as the benefits. Why on earth would you be switching to the cloud if you didn’t have some idea of what it was going to do for you? And yet people do it all the time.

Perhaps they are simply falling for the hype – cloud providers are claiming lower start-up costs, less overhead, better scalability and reliability, streamlined process, and cures for cancer. OK, I made that last one up, but it’s close. Seriously, a commenter to my piece on What Went Wrong with Static Analysis? said that all the potential pitfalls of static analysis are avoided if you simply use the cloud. As you’ve probably guessed, he worked at a company providing cloud services.

I don’t want to dive into a detailed list of what cloud can and cannot do at this point, although I may at a later date. But I do want to caution people to at least think about it. If someone says that the cloud will make your life better, ask them to explain how. If it makes sense, great. If not, beware of snake oil.

With that in mind, I want to talk about something that actually will make your life easier, namely a special kind of private cloud called micro cloud. This is an especially useful tool for software development that can make your life easier.

It’s not secret that I’m a VMware (VMW) fan. One of the aspects I like best is that it’s well suited for extreme scalability. You can start with desktop use, like running an alternate OS on your machine without having to reboot. Then you can push that onto an ESXi box in your server room when the virtual machine you were using unexpectedly becomes something useful you actually depend on. And ultimately you can push it off into the cloud as needed and scale it up as needed.

This is where the connection to software development comes in. One of the tedious pieces of getting a software project up and running is setting up the infrastructure. This is known as Application Lifecycle Management, or ALM. You need to have quite a few different goodies available, and while none of them are super complicated, it takes time to put the whole thing together. And then at some point you realize you either need another one, and have to do it again, or the one you have is tool small/slow for the team as the project has grown.

The list of necessary tools includes things like requirements management, project management, source control, compilers, development IDE, build management, continuous integration, testing, reporting, static analysis, code coverage, etc. Each of the items isn’t the complicated by itself. Putting them all together just takes more time than it should. In addition, it turns out the software developers really aren’t the best choice for system administrators, and don’t always deploy infrastructure in the way that you want. This is an excellent fit for virtualization.

Instead of putting together your software in an ad hoc way that has a tendency to grow like Frankenstein’s monster (come on, we know it happens to all of us) you can plan and coordinate between developers, architects, managers, and sysadmins. Figure out what kind of tools you’re going to need all the time, layout the requirements for them, and get the admin guys to build you up a virtual machine that has everything you want. Then test it, fix it, and from then on you can use use it over and over again.

Do it on a virtual machine rather than a physical one, that way when you need a new one for a new project, you can just stand up a new instance of the virtual machine. When you outgrow your hardware, scale it up on the back-end in the hypervisor. If you need to share geographically push it out to a cloud provider or data center.

Or…

You can use one that someone else has already built. If you have a small project and you don’t have security issues that preclude you putting your code outside your own firewall, there are a couple of pure cloud plays that have pretty much what you need. For example you could go to GitHub and use their tools. Or you can check out Cloud Foundry, which also uses Git as a source control system.

If you can’t put your source in the cloud for whatever reason, or if Git isn’t your cup of tea, then you should look for a micro cloud instead. This is a virtual machine pre-built that you can use on a desktop, or in your own server room or even scale it up to your datacenter. Again, you could do all this yourself, but if you can find one that has what you need, you can save a lot of time.

[Disclaimer]
As a reminder, I work for Parasoft, a company that make a variety of tools for software development, including an ALM virtual machine suitable for micro cloud. This is however my personal blog, and everything said here is my personal opinion and in no way the view or opinion of Parasoft or possibly anyone else at all.
[/Disclaimer]

With that behind me, let me relate a personal story. I was working on a personal project at home and wanted to setup a source control system. I happen to be an SVN guy, so I normally setup a subversion server and then use Apache to access it. The SVN install is quick and easy. Apache isn’t too difficult, but by the time you get HTTPS up and running with certificates and the WebDAV SVN connector going it can be difficult. Add to that the normal scenario that you don’t do it very often and it’s easy to forget the little things that will trip you up during setup. Need to say, I wasn’t looking forward to setting the darn thing up.

I started with using a VM like I always do, and as I was adding Apache and SVN to it, I got a feeling of deja vu. I knew of course that I had done it before, many times. Then I figured out why the deja vu. I helped create the VM for Parasoft that just happened to have everything I needed in it. So I download that VM, started it up on my desktop, and set the configuration for what I needed. Other than download time, total setup and configuration was about 20 minutes. Total time and frustration saved: a lot.

Micro cloud is a great way to not only handle your development infrastructure, you can also do tech support on specific environments, setup complicated QA, provide quick POC projects etc. This is one of the cases where it’s easy to see how cloud helps – it not only drastically reduces start-up time and costs, but leaves you in good shape to scale quickly and efficiently.

If there are clouds in your forecast, micro cloud might be the place to start.

That Bright Light You Saw was the End of Flash

It’s finally official – at least for those who are aware of how the web works. Yesterday Adobe (ADBE) announced that they will be discontinuing flash support for mobile devices.

HTML5 © by Josef Dunne

A couple of brief quotes from their blog post follow:

“However, HTML5 is now universally supported on major mobile devices, in some cases exclusively. This makes HTML5 the best solution for creating and deploying content in the browser across mobile platforms. …”

“Our future work with Flash on mobile devices will be focused on enabling Flash developers to package native apps with Adobe AIR for all the major app stores. We will no longer continue to develop Flash Player in the browser to work with new mobile device configurations…”

To be sure they did plenty of backpedaling about renewed focus and new features for the desktop, but make no mistake, they see the light at the end of the tunnel, and they finally figured out it’s a train. Hello HTML5 Express!

As I’ve said before this is a fine thing. The truth is that many years ago Adobe was the only way to do animation, video, and interactivity at all. And after that, it was just the best way. And after that, the most common way.

Today the need for Flash has greatly diminished. HTML5 has already delivered on the promise in the area of video, and AJAX works very well for interactive web applications.

Three things really killed them. I’ll take them in reverse order, since the third was just a symptom, but most think it was the cause. Namely, Steve Jobs. At Apple (AAPL), Jobs figured out that Flash not only doesn’t work well for mobile, but it probably wasn’t every going to, at least not before HTML5 would catch on. But Jobs didn’t kill Flash, he was just more vocal about it’s shortcomings.

Number one was that the need for Flash simply isn’t there the way it once was. Web pages used to be really static. In the beginning there were almost completely text. Then people started adding more images. Then came databases and data-driven apps. Then video, sound, and fully interactive applications.

But before the last, there was a gap, people wanted video and apps, but it just wasn’t easy. Most applications consisted of some special code that had to be downloaded on your machine, and were essentially client-server programs that used the web simply as a transport mechanism. Flash is pretty much the same as the others, with the exception that it was pretty easy to use, and it managed to catch on. With critical mass, it started to be supported by most browsers, and off it went.

Today we can get streaming video quite easily without Flash. Any web site that doesn’t provide video feeds in HTML5 simply cuts off millions of potential users, which is generally a poor business decision.

As for apps, the simple web applications that are in Flash will continue to live on, but the great desire for them has changed. Now users can download free and inexpensive games all day long on their mobile devices, which is where they normally play the little time wasters. (I’m not judging, I do it myself.) So why do you need Flash?

That leaves us with advertisers – and they have a problem there. People without Flash simply don’t get their message. From the producer side it’s a problem anyway, as a consumer, I’m happy to turn Flash of in my browser, and only click when I know it’s something I need. AJAX is where advertising will end up, and actually it’s very well suited to the task, seeing as the first A in AJAX stands for asynchronous, which is perfect for advertising.

So reason number one is that the need for Flash has melted away. I was tempted to say evaporated, but it wasn’t that quick. It’s been a slow steady change in how the web works, from proprietary thick browser plug-ins to open dynamic lightweight AJAX. And that’s a good thing, both for consumers and for the people who run the pipes that the internet is carried over.

I’ve always said that the value Adobe brings to the table isn’t so much Flash itself as the amazing tools they provide for web development. The designer shouldn’t have to care so much about whether the application is Flash or HTML5, they should be able to just code. Adobe should be able to quickly get in front of this by providing everything Flash does in HTML5. And to do that, they had to finally admit that HTML5 is killing Flash. Mobile is just the first step.

As for reason number 2 (for those who’ve been keeping track… 3,1,2) it explains why mobile is the first step. And that reason is that Flash is ill-suited for mobile for various reasons. One is performance. It’s easy to see that Flash is a hog no matter what the platform.

Try a simple test – fully charge the battery on your laptop. Fully disable Flash and spend a couple hours surfing the web. Then charge the battery again, turn Flash back on, and repeat. You’ll be shocked at the results. Bear in mind, I’m not talking about playing Flash games and video even, just surf the web. Not only do you avoid advertising, but you’re battery lasts longer and everything runs faster. Who would have that that dumping Flash was a way of going green? But it is. Now imaging trying the same thing on a device with a tiny battery, slower processor and a lot less memory. Painful.

The other part of the equation is the usage paradigm. Early in the iPhone era people started writing articles about how to program an iPhone. Many articles described handling the touch interface exactly the way you would a mouse. This is of course ridiculous, especially now with multi-touch and gesture.

Even without that, a finger simply doesn’t behave the way a mouse does. For instance, you can pick a finger up and put it down somewhere and the cursor moves with it. If you pick up a mouse and set it down the cursor is either where you started or in some random place – not the most useful feature.

The touch interface is just one aspect of mobile programming that makes Flash painful on a mobile device. Silly things like x controls that let you close a Flash animation are frequently too small to be used. Add that all up and you find that the basic concept of Flash is flawed, namely to be a “write-once run-anywhere” works fine on the desktop, but doesn’t translate well to the mobile touch-enabled world. Which leads us back to Steve Jobs, 1-2-3.

And a funny footnote. RIM (RIMM) has announced that unlike Adobe, they will continue to support Flash development for the Blackberry Playbook. They just don’t know when to give up, do they? It’s not surprising coming from the people who thought that no one would want mp3 files on their phones. As ZDnet
put it:

But to continue to support an already dead platform on a dying tablet is like throwing salt in the wound of an already squashed slug.

So when HTML5 gets better and your mobile device gets stronger, you can thank Adobe for finally recognizing the inevitable – Flash is dead.

[Update]
Google has a tool that you can use to convert Flash to HTML5.
[/Update]