Software Development

There are 89 posts filed in Software Development (this is page 8 of 9).

Working with callbacks in Javascript

I am playing with the sample code for Dave Winer’s feedRead Github repo, and wanted to refactor one of the examples. I have seen multiple examples of a callback function source code included in a call to another function, but I wanted to have it be a separate function. Here is the example code:
[cc lang=”javascript”]
feedRead.parseUrl (urlTestFeed, timeOutSecs, function (err, theFeed) {
if (err) {
console.log (err.message);
}
else {
console.log (“It took ” + utils.secondsSince (whenstart) + ” seconds to read and parse the feed.”);
console.log (“theFeed.head == ” + utils.jsonStringify (theFeed.head));
console.log (“theFeed.items [0] == ” + utils.jsonStringify (theFeed.items [0]));
for (var i = 0; i < theFeed.items.length; i++) {
console.log (“Item #” + utils.padWithZeros (i, 2) + “: ” + theFeed.items [i].title + “.”);
}
}
});
[/cc]
After some experimenting, I figured out that all I needed in the feedRead.parseUrl call was the function name (with no parameters, even though it had parameters), and then the function could be factored out:

[cc lang=”javascript”]
feedRead.parseUrl (urlTestFeed, timeOutSecs, myparser);

function myparser (err, theFeed) {
if (err) {
console.log (err.message);
}
else {
console.log (“It took ” + utils.secondsSince (whenstart) + ” seconds to read and parse the feed.”);
console.log (“theFeed.head == ” + utils.jsonStringify (theFeed.head));
console.log (“theFeed.items [0] == ” + utils.jsonStringify (theFeed.items [0]));
for (var i = 0; i < theFeed.items.length; i++) {
console.log (“Item #” + utils.padWithZeros (i, 2) + “: ” + theFeed.items [i].title + “.”);
}
}
}
[/cc]

Note that the function does not have a semicolon at the end, but the call to feedRead.parseUrl does…

References:

https://codeburst.io/javascript-what-the-heck-is-a-callback-aba4da2deced

https://javascriptissexy.com/understand-javascript-callback-functions-and-use-them/

How embedded software projects run into trouble

Jack Ganssle has written articles for his top ten list of how embedded software projects run into trouble. Most of this could apply to any software project! Here are the links:

  1. Unrealistic schedules
  2. Quality gets lip service
  3. Poor resource planning
  4. Writing optimistic code
  5. Weak managers or team leads
  6. Crummy analog/digital interfacing
  7. Bad science
  8. The undisciplined use of C and C++
  9. Jumping into coding too quickly
  10. Not enough resources allocated to a project

 

Read The daily

Is there something you do every day that builds an asset for you? Every single day? Something that creates another bit of intellectual property that belongs to you? Something that makes an asset yo…

When I read this, I decided to start working on the asset that is my weblog. I will strive to post something daily, even if it is only a link….

The debt metaphor in software development

In a new post, Ward Cunningham shares his thoughts on the “debt metaphor” in software development. One of the points he brings out is that programming can be thought of as making decisions now on the functionality of the program and deferring others to a later time (debt), with the understanding that as the program matures, refactoring can occur to make the program more efficient/better (paying back the debt).

In my experience in avionics software development, the creation of software is driven by approved requirements. As requirements change or are refined, the software is updated to be consistent with those requirements. One type of “debt” I see is when functionality is not completed on time, and gets deferred to a later software release (cost increase). Another type is when a problem is found (requirements, source code, tests, documents), but addressing the problem is deferred to a future time (the problem does not impact the functionality of the requirements, source code, or tests, or is deemed not  a safety issue). This type of debt (typically called “open problem reports” (OPRs) is getting more scrutiny by aircraft certification agencies and OEMs (Bombardier, Boeing, etc.), since they see increasing numbers of OPRs as an indicator that the overall “health” of the software may not be as good as it should be, and that there should be as few OPRs as possible (in other words, fix your problems as you find them).

For myself, I prefer to fix problems when they come up. However, when you work as a member of a team, sometimes business decisions dictate otherwise….