Each Programming Language and its Influence on Software Development

299601-3524-37There are programming languages we love – and ones we could live without.

Yet, each programming language has made some type of contribution to the software development world. Most of the posts you read about programming languages are rants, or compare and contrast them.

However, Dustin Marx of Java World recently took a different approach. Marx looked at each programming language individually and  how it influenced software development. Here’s a look:

Basic

Most software developers I know have written some code in some form of BASIC(Beginner’s All Purpose Symbolic Instruction Code). I remember, long before public availability of the Internet or even mice on PCs, typing in Basic code from magazines I received in the mail with code listings for various simple games and PC utilities. Like many developers, Basic was the language that attracted my interest at a relatively young age to programming. It was from my Basic programming that I learned firsthand the dangers of the goto.

C

C may be the most influential of all programming languages on today’s software development. In Steve Yegge‘s well-known blog post The Next Big Language, Yegge’s #1 rule for the next big programming language is that it has “C-like syntax.” Many people’s favorite programming languages are themselves (interpreter or runtime environment) written in C and many of these languages provide mechanisms (JNI and XS are two examples) for “escaping” to C for performance gains. C also remains one of the most popular and highly used programming languages in the world despite its relatively old age. Wikipedia even has an entry devoted to C-based programming languages.

Continue Reading

Essential Guide to Mobile App Testing

Major Security Loophole in an Estimated Two-Thirds of Web Servers

Lock backgroundIf you haven’t already heard, today brought a huge piece of security news to the tech world.

Researchers reported that an estimated 66% of the world’s servers have been affected by a real world crypto bug that could expose all types of sensitive data. This hits everything from online retailers, to banks who offer online banking – you name it.

According to Dan Goodin of ARS Technica, the defect is in the cryptographic software library an estimated two-thirds of Web servers use to identify themselves to end users and prevent the eavesdropping of passwords, banking credentials, and other data:

The warning about the bug in OpenSSL coincided with the release of version 1.0.1g of the open-source program, which is the default cryptographic library used in the Apache and nginx Web server applications, as well as a wide variety of operating systems and e-mail and instant-messaging clients. The bug, which has resided in production versions of OpenSSL for more than two years, could make it possible for people to recover the private encryption key at the heart of the digital certificates used to authenticate Internet servers and to encrypt data traveling between them and end users. Attacks leave no traces in server logs, so there’s no way of knowing if the bug has been actively exploited. Still, the risk is extraordinary, given the ability to disclose keys, passwords, and other credentials that could be used in future compromises.

‘Bugs in single software or library come and go and are fixed by new versions,’ the researchers who discovered the vulnerability wrote in a blog post published Monday. ‘However this bug has left a large amount of private keys and other secrets exposed to the Internet. Considering the long exposure, ease of exploitations and attacks leaving no trace this exposure should be taken seriously.’

Continue Reading

Essential Guide to Mobile App Testing

Software Update Fixes Bugs (but cannot kill spiders)

yellow_sacSometimes in software testing you are finding and fixing coding errors, sometimes you are addressing requirement gaps, and sometimes you have to deal with spiders.

Spiders? Exactly. And no, I don’t mean that as a metaphor for some new fancy software issue. I just mean, sometimes you are actually dealing with spiders.

Mazda has recently announced a voluntary recall of 42,000 Mazda 6s, due to… spiders. The yellow sac spider or Cheiracanthium, for those of you that are arachnid enthusiasts, are attracted to hydrocarbons and gasoline. These adorable little guys have taken a liking to Mazda’s vent lines. The webs restrict air flow and can potentially cause cracks in the fuel tank, which ultimately could lead to fires.

Mazda first addressed this “more common than you’d think” problem a few years ago with a mechanical solution, aimed at keeping the spider out of the lines. However, they proved to be persistent and continue to breach the Mazda’s security. So Mazda has now turned to new software. They offer the free upgraded software to Mazda owners which regulates the pressure level and notifies the owner if there is a problem. True, it is not an actual solution to the spider problem; however it is great to see that Mazda is looking to software proactively to ensure the safety of their customers. It should also be noted that although the problem has persisted for a few years, no injuries or fires have been reported as a result of pressure build up related to spider webs.

Continue Reading

Essential Guide to Mobile App Testing

Why Mobile Apps Testing is Different from Desktop and Web

download (1)Ever since the first cell phone hit the commercial market in 1983, the mobile market has rapidly innovated from a handset that weighed over 2 pounds and could only make one phone call at a time, to a modern-day smartphone that weighs barely 5 ounces and can hold enough apps to practically run your entire life. In this course, uTest guest author Anand Ramdeo outlines ten ways that testing mobile apps differs from desktop and web testing, and points out the complexities and nuances that make mobile testing a unique skill for testers.

We have witnessed transition from desktop to web and are witnessing another transition from web to mobile. Before I delve deeper into the subject – it is important to understand how testing mobile applications is different from testing browser / desktop applications. If we understand the distinction and challenges of testing mobile apps, it will be a bit more easier to tackle them.

1. Supported platforms and devices mean you have more combinations to test.

Desktop apps were usually targeted for specific platforms and it was relatively easy to access those platforms. Web based applications made it a bit more challenging by adding another dimension: browsers.

Mobile applications take complexity of supported platforms to the next level by adding devices. Ensuring that mobile apps are working on all type of devices (smartphone, tablets, and phablets) supplied by major brands (various models from Samsung, Sony, Nokia, HTC, Apple, etc.) and on all the platforms (iOS, Android, Windows, BlackBerry, etc.) is challenging. On top of that, new devices are hitting market so often that it becomes impossible to cover all the major devices.

In the mobile world, it is important to create something on the lines of graded browser support used by Yahoo to ensure that major platforms are covered.

Continue Reading

Essential Guide to Mobile App Testing

How Testers Can Help Regain the Trust of Users

trustStop me if you’ve heard this before: Users are becoming increasingly uneasy with the way in which apps collect, store and share their personal information. It’s a story we’ve discussed a lot here on the uTest Blog over the years (and more recently, on the Applause Blog), but it’s a story that isn’t going away anytime soon unfortunately.

Late last week, MEF Global Chairman Andrew Bud penned a thoughtful guest post for VentureBeat on this very topic, where he argued that trust in apps is on a downward trajectory. In his view, it all has to do with personal information.

In many ways, the apps economy runs on personal information. It’s the currency – the lifeblood – and the main reason why apps can succeed with a freemium model. As Bud argues, it’s also the reason why trust is quickly declining. He writes:

What underpins this transactional relationship is consumer trust and it follows that, for the mobile industry, this should be the watchword for how mobile businesses build and retain customers.  The less confidence people have in their mobile device, the less they will use it and the apps on it. That’s bad news for everyone.

Yet for almost as long as apps have been on the market, consumers have been bombarded with stories in the press and across social media platforms that raise privacy concerns about the way apps gather and store and use personal information.  As an industry we have a long way to go.

He backs his opinion with some hard figures from a recent MEF/AVG Technologies study, which found that:

40 percent of consumers cite a lack of trust as the reason they don’t purchase more via their mobile — by far the most significant barrier. And it’s getting worse. In 2012, 35 percent named trust as an obstacle compared to 27 percent in 2011.

Second, 37 percent claim a lack of trust prevents them from using apps once they’ve installed them on their phone. Third, 65 percent of consumers say they are not happy sharing their personal information with an app.

Hard to argue with numbers like that. So what’s to be done? While Bud places a small amount of the burden on users – arguing that they should be more aware of the threats – he places most of it on the industry as whole: marketers, developers, publishers, aggregators, executives and so forth.

And to that I would add software testers.

Continue Reading

Essential Guide to Mobile App Testing