Opentask plans to publish full-color children’s book series called “Baby Turing”:
- Dmitry Vostokov @ DumpAnalysis.org -
Comments “are not” code.
- Dmitry Vostokov @ DumpAnalysis.org -
Engineers’ source codes “reveal their characters.”
Luc de Clapiers, marquis de Vauvenargues, Reflexions and Maximes
- Dmitry Vostokov @ DumpAnalysis.org -
Faced with the problem to find time to write troubleshooting tools that spring to my mind I devised this process that seems to be a novel way to write software for busy professionals. Its essence is in writing software when presenting it or when presenting software writing topics, for example, software architecture, design and implementation. It has some agile process flavour but magnified by a bigger audience than pair programming has and nicely complements my Reading Windows-based Code series. SIMSIM is an abbreviation for:
Show IMplementation and Subsequent IMprovement
More details will be announced soon.
- Dmitry Vostokov @ DumpAnalysis.org -
The HTML version of the presentation is located here:
Reading Windows-based Code (Part 6)
Contents:
In Part 7 I’m planning to include the following topics:
- Dmitry Vostokov @ DumpAnalysis.org -
The HTML version of the presentation is located here:
Reading Windows-based Code (Part 5)
- Dmitry Vostokov @ DumpAnalysis.org -
Almost finished reading the book and wrote a short review:
Secure Programming with Static Analysis
- Dmitry Vostokov @ DumpAnalysis.org -
The HTML version of the presentation is located here:
Reading Windows-based Code (Part 4)
I had to postpone a detailed overview of Windows specific types and the structure of a typical Windows GUI program for 5th part.
- Dmitry Vostokov @ DumpAnalysis.org -
The HTML version of the presentation is located here:
Reading Windows-based Code (Part 3)
The 4th part coming next week will be about Windows specific types and will describe in detail the structure of a typical Windows GUI program.
- Dmitry Vostokov @ DumpAnalysis.org -
The HTML version of the presentation is located here:
Reading Windows-based Code (Part 2)
This second part is still based on the first chapters from “Code Reading: The Open Source Perspective” book written by Diomidis Spinellis. As I mentioned in the first presentation (slide 2) that book never uses Windows-based code and this prompted me to start Code Reading (The Windows Perspective) series.
The 3rd part coming next week will be mostly about basic data types and introduce some Windows conventions related to them.
- Dmitry Vostokov @ DumpAnalysis.org -
As promised here is the first introductory part of the Code Reading (The Windows Perspective) training. You might need to download and install Microsoft Office Animation Runtime if you don’t have PowerPoint installed:
PowerPoint 2003/2002 Add-in: Office Animation Runtime
The HTML version of the presentation is located here:
Reading Windows-based Code (Part 1)
- Dmitry Vostokov @ DumpAnalysis.org -
This post is motivated by TRAFFIC steps introduced by Andreas Zeller in his book ”Why Programs Fail?”. This book is wonderful and it gives practical debugging skills coherent and solid systematical foundation.
However these steps are for fixing defects in code, the traditional view of the software debugging process. Based on an analogy with systems theories where we have different levels of abstraction like psychology, biology, chemistry and physics, I would say that debugging starts when you have the failure at the system level.
If we compare systems to applications, troubleshooting to source code debugging, the question we ask at the higher level is “Who caused the product to fail?” which also has a business and political flavor. Therefore I propose a different acronym: VERSION. If you always try to fix system problems at the code level you will get a huge “traffic” in all sense but if you troubleshoot them first you get a different system / subsystem / component version and get your problem solved faster. This is why we have technical support departments in organizations.
There are some parallels between TRAFFIC and VERSION steps:
Track View the problem
Reproduce Environment/repro steps
Automate (and simplify) Relevant description
Find origins Subsystem/component
identification
Focus Identify the origin
(subsystem/component)
Isolate (defect in code) Obtain the solution
(replace/eliminate
subsystem/component)
Correct (defect in code) New case study
(document,
postmortem analysis)
Troubleshooting doesn’t eliminate the need to look at source code. In many cases a support engineer has to be proficient in code reading skill to be able to map from traces to source code. This will help in component identification, especially if your product has extensive tracing facility. I have started development of ”Code Reading” training targeted for Windows environments and will post some presentations soon. The first one will be available tomorrow, so stay tuned.
- Dmitry Vostokov @ DumpAnalysis.org -