software development

AdaCore's GNAT Pro, CodePeer, QGen and SPARK Pro

James Gray — Fri, 09 Jun 2017 15:54:00 +0000

AdaCore recently announced the concurrent annual release of four flagship products in its portfolio of software development and verification tools for mission-critical, safety-critical and security-critical systems. These include version 17.1 of GNAT Pro, CodePeer, QGen and SPARK Pro.

All products aid organizations with the challenges they face in the development and verification of critical systems, especially when certification against software standards, such as DO-178C or EN 50128, is required. GNAT Pro is a development environment for Ada and C, on native and cross platforms. CodePeer is a deep static analysis tool for Ada that can identify bugs and vulnerabilities both during development and retrospectively on existing code bases. SPARK Pro is a verification environment that brings mathematics-based assurance to high-integrity software, and QGen is a model-based development and verification toolset for Simulink and Stateflow models, which generates code in MISRA-C or SPARK. Each tool in the suite offers its own diverse set of enhancements and improvements in the new version 17.1 release.

Go to Full Article

Brent Laster's Professional Git (Wrox)

James Gray — Mon, 27 Feb 2017 14:51:52 +0000

by James Gray

More than 40% of software developers use the massively popular software development tool Git as their primary source control tool. Those new to the Git fold who are looking for a professional, up-to-date guide to get them rolling have a new resource in Brent Laster's new book Professional Git.

Laster's Wrox-published title is more than just a development manual: it gets users into the "Git mindset". The book offers extensive discussion of corollaries to traditional systems as well as considerations unique to Git to help one draw upon existing skills while looking out—and planning for—the differences.

Connected labs and exercises are interspersed at key points to reinforce important concepts and deepen understanding, while a focus on the practical goes beyond technical tutorials to help users integrate the Git model into real-world workflows. This book instructs users how to harness the power and flexibility of Git to streamline the development cycle.

Go to Full Article

It's about the User: Applying Usability in Open-Source Software

Jim Hall — Tue, 18 Feb 2014 19:34:49 +0000

by Jim Hall

Open-source software developers have created an array of amazing programs that provide a great working environment with rich functionality. At work and at home, I routinely run Linux on my desktop, using Firefox and LibreOffice for most of my daily tasks. I prefer to run open-source software tools, and I think most Linux Journal readers do too. But as comfortable as the open-source software ecosystem can be, we've all shared or heard the same comments about some of our favorite Linux programs:

"___ is a great program, once you figure out how to use it."
"You can do a lot in ___, after you get past the awkward menus."
"You'll like using ___, if you can learn the user interface."

That's the problem. No matter how powerful the program, that functionality is lost if people have to figure out how to use the program in order to unlock its secrets. Typical users with average knowledge should be able to operate a general-purpose program. If a program is hard to use, that suggests the problem is with the program, not with the user.

Usability and Open-Source Software

"Usability" refers to how easily users can learn and start using software, or any similar "information product". Usability is separate from the functionality of the program, and so usability testing is different from unit testing. Instead, usability testing allows us to uncover issues that prevent users from using our programs.

Most open-source software programs are written by developers for other developers. Although some large open-source programs, such as GNOME and Drupal, have undergone usability testing, most projects lack the resources or interest to pursue a usability evaluation. As a result, open-source software programs often are utilitarian, focused on the functionality and features, with little attention paid to how people will use it. Applying usability practices tends to be antithetical to how open-source software is created. Open-source developers prefer functionality over appearance. Although some projects may have a maintainer who dictates a particular design aesthetic, many more do not. In an interview for this article, open-source advocate Eric Raymond commented to me that most programmers view menus and icons "like the frosting on a cake after you've baked it", which is an apt metaphor. Open-source software developers tend to prefer assembling the ingredients and baking the cake, not applying frosting to make it look nice.

So how can open-source developers easily apply usability to their own programs? There are many ways to implement usability practices. Alice Preston described 11 different techniques to evaluate usability in the STC Usability SIG newsletter. These methods run the gamut from interviews and focus groups to heuristic reviews and formal usability tests:

Go to Full Article

Mercurial - Revision Control Approximated

Joey Bernard — Tue, 24 Apr 2012 17:17:51 +0000

by Joey Bernard

A short while ago, an article appeared in Linux Journal implying Git was the be-all and end-all of source code revision control systems ("Git—Revision Control Perfected" by Henry Van Styn, August 2011). I would like to challenge that assumption and declare to the world that the real perfect version control system is here, and its name is Mercurial.

In case you didn't notice it, my tongue was firmly in my cheek in that last paragraph. I think version control systems are like editors. They are all different and fit people and their work habits differently. There is no one perfect system to rule them all. Git may be the perfect fit for some people, and RCS may fit someone else better. This article describes another option to add to the mix. Mercurial provides some of the features of systems like Git, and some of the features of systems like CVS or Subversion. Hopefully, after reading this article, you'll have enough information to make a rational choice as to what is best for you.

The main Mercurial site contains lots of documentation for end users and developers alike. Several tutorials are available, and they even include a series of work flows that cover how end users can use Mercurial for their development projects. Using those, you can see how you could use Mercurial as a solo developer or as one of a group of developers, or how to work with a central repository like CVS. These work flows are great starting points for you to create your own.

First, let's look at what makes up Mercurial. A Mercurial repository consists of a working directory, which is paired with a store. The store contains the history of the repository. Every working directory is paired with its own copy of the store. This means that Mercurial has a distributed system, much like Git. When you commit a series of file changes, a single changeset is created, encapsulating these changes. Each changeset gets a sequential number, called the revision number. But, remember that each working directory gets its own copy of the store, so these revision numbers may not actually match up. For this reason, each revision also gets a 40-digit hexadecimal globally unique ID.

Figure 1. Here you see that Mercurial repositories are tagged for easy finding.

Figure 2. Right-clicking a file and pulling up the properties gives you lots of Mercurial information.

Go to Full Article

Are You Accessible?

Katherine Druckman — Thu, 20 Oct 2011 00:03:21 +0000

by Katherine Druckman

Accessibility to people with disabilities is an important issue in web and software development, and the folks at Knowbility, Inc. would like your input about how to better educate people about accessible technology.

Knowbility is a non-profit organization whose mission is to support the independence of children and adults with disabilities by promoting the use and improving the availability of accessible information technology. They do this through education and outreach, and the more information they have from those of us working in the IT industry, the better they are able to continue their mission.

So if you have a few minutes, please share your feedback via their online survey at https://www.surveymonkey.com/RU_accessible

Knowbility, a nonprofit advocate, trainer and consultant since 1999 for technology access for people with disabilities, and MicroAssist Inc, a leading software training center since 1988, are seeking input on questions of IT accessibility. Our industry has seen legal mandates for accessibility expanding every year; technical standards from the W3C are in place and updated as technology evolves; and yet access to technology remains unequal. We have had many inquiries about why the state of accessibility remains so dismal. We welcome your input and if we have left something out, please send email to knowbility at knowbility dot org.

P.S. You can enter to win two Southwest Airlines tickets by answering the survey.

Go to Full Article

Cross Compiling Options

Johan Thelin — Sat, 24 Apr 2010 14:10:56 +0000

by Johan Thelin

What is your strategy on cross compilation toolchains? Here we explore a
few options:

DIY - requires you to manually start each step, unless you're comfortable enough to script the process. As each step takes ages, this can be a tedious job. However, it gives you full control and insight into each step.
crosstool [https://www.kegel.com/crosstool/] - a scripted version of DIY + patches. Used to be my preferred tool, but hasn't been updated since 2006. Limited to glibc.
crosstool-NG [https://ymorin.is-a-geek.org/projects/crosstool] - a rewrite of crosstool. Provides a menuconfig configuration interface, which makes it quite easy to use. You can also pass configurations around. Supports glibc, but also uclibc and eglibc.
buildroot [https://buildroot.uclibc.org/] - builds a uclibc-based gcc in the process of building an entire system. The toolchain can be ripped out (you can also force buildroot to use an external toolchain - thus avoiding building the same toolchain over and over again). As the focus is on the entire system, this approach provides little insight of the toolchain, but in my experience, the outcome usually works well.
scratchbox [https://www.scratchbox.org/] - provides uclibc or glibc based toolchains. Approaches cross compilation is a new way - providing an environment where the actual cross part of the compilation is abstracted away. Also provides an emulated target environment, so you can run your ARM binaries on your standard PC from within the scratchbox environment.

The available options are ordered in some sort of control freak factor order, where DIY provides loads of control over every tiny aspect, while scratchbox just makes things work.

Myself? Last time around I used ct-ng, but I've used them all (and will not DIY again unless forced ;) ).

Go to Full Article