Course code: WEB-11
Years with company:
Primary programming language:
Other programming languages:
C++, Java, C#, various scripting languages
Unit test harnesses:
Googletest, Cpputest, AceUnit, Catch, JUnit
My work with Cryptomathic has been primarily focused on developing support software (desktop) and firmware modules (embedded) for Hardware Security Modules used by most of Cryptomathic's products. HSM's are tamper resistant modules which holds and operates with cryptographic key material which must never be available in clear for anyone. HSM's are usually used with banking systems and for generating digital signatures.
My passion lies in automation and optimization. Both in life in general and at work.
Test practice now:
Depends on the project at hand, for newer projects we generally try to use a TDD approach or at least add unit tests. For legacy code, we try to add unit tests for new code when feasible, yet we still only have functional tests for most of the code, if there are tests at all. This means a lot of code requires hardware to be available for tests to be executed, and since the hardware is expensive this is a scarce resource. Thus many tests are postponed to "release test periods".
Multiple brands of hardware security modules supporting custom firmware loading. 32 bit PowerPC or ARM, ~2MB-128MB RAM depending on brand. On-target debugging is not available.
Visual Studio for non-hardware specific code, software emulation and executing tests. Vendor specific toolchains (mostly GCC). Make, ant, jenkins for build automation.
We try to follow the standard used in the specific project, but otherwise do not impose a specific coding standard.
Function too long:
If it can't fit on a single screen :-) if the function tries to do more than one thing, possibly at multiple layers of abstraction. Sadly, we are still left with plenty of those.
We use code reviews for most of the developed code including tests. The primary purpose is to share knowledge of the source code and to spot misunderstandings. We try to rely on tests for finding subtle bugs.
Favorite thing about dev:
I like the challenge it is to solve a programming problem in an elegant fashion, no matter the tools available. Automating tedious tasks and optimizing code.
And I, of course, love the feeling when something I have built starts working :-)
Least favorite thing about dev:
Manual testing. Using third party API's that is either undocumented, or does not work as specified leading to countless hours of trial and error and support requests.
I have read the TDD for embedded C book, which is when I first tried using TDD. I still struggle to apply the TDD approach for some scenarios, especially for higher level functionality.
Why are you attending:
I want to be able to develop better quality software faster and with less frustrations.