About Me

My name is Trevor and I am an enthusiastic software developer based in Devon in the UK.  I have 20 years' commercial experience working on diverse projects using a wide variety of technologies, but I code predominantly in Microsoft .NET.

I spend much of my free time improving my knowledge, development, and diagnostic skills by undertaking recreational development projects, and my AtomicityOS operating system is perhaps the most ambitious of these.  To me, the computer system under my application is not just a black box of mystery that needs to be rebooted when it goes wrong, it has logic and workings and the more I understand those concepts, the better I can investigate and fix it when issues arise.  Lots of people know how to drive, but to me it's important to be able to diagnose the problem if the car won't start.  

I have a Bachelor of Science degree in Maths with Computer Science, and have recently completed training courses in PCI-DSS awareness and secure coding.  I also have strong skills in support diagnostics and customer liaison, as well as documenting and mentoring.

My primary focus and experience is in the following technologies:

  • C#.NET, up to Framework v4.8 and .NET Core 3
  • ASP.NET Web Forms, MVC, and WebAPI
  • Javascript, AngularJS, and Bootstrap
  • T/SQL in SQL Server 2000 and above, EntityFramework version 6
  • HTML, versions 4, 5 and XHTML
  • Git (via BitBucket and Sourcetree) and Microsoft Team Foundation Server
  • Web applications, Winforms, services, and more recently Docker images.

I also have extensive experience with: 

  • Visual Basic, all versions and variants including VB.NET, VBA and VBScript
  • XML, including XSLT and XPath
  • Regular Expressions
  • C, x86 Assembly (specifically GAS and NASM)
  • PL/SQL (Oracle 8i to 10g)

Through the development of these recreational projects, the list of topics I have investigated includes:

  • Encryption including RSA and DES algorithms, TLS, PGP and X.509 certificates.
  • Disassembling compiled code for debugging using ILSpy for .NET and objdump for C.
  • Many file formats, including GIF, PNG, BMP, XLS, MDF (SQL Server), COB, TTF, WAV, JPEG, MDL, MD2, PCX, RTF, ELF and PE/COFF executables.
  • Network protocols including Ethernet, ARP, IP, ICMP, TCP, UDP, TFTP, HTTP, and SMB.
  • Computer graphic techniques including dithering and edge detection algorithms.
  • Bézier curves and other vector graphics primitives and rasterisation.
  • Perlin noise generation and pseudo-random number generation.
  • Compression including Huffman trees, Deflate, LZW and LZMA algorithms.
  • File systems including FAT, Amiga OFS, and ISO9660.
  • Investigated core PC technologies including Interrupts, VGA, ATA, ATAPI, SCSI, PCI, USB, Intel HDA, UART, and IEEE 1284 ports.

What could development in C teach you about .NET?

.NET may be much newer than C, but it is built on exactly the same concepts.  .NET classes (or rather, their instance state blobs) are functionally identical to C structures.  .NET still uses the same stack & heap memory model for local variables and persistent values.  Even the build tool-chain for .NET is heavily based on building C projects where different targets and configurations are stored in the project file ("makefile" in C) and invoked using MSBuild ("make" in C).

Beyond this, my experience in components outside of the code itself is agnostic to the development language used.  TCP/IP connections on-the-wire are the same whether they are made from .NET, Java, C, or Assembly.  On a mobile platform, you'll still be using ESC/P 2 to talk to an attached printer.  File formats aren't worried about what language is reading them.  In general, procedural languages are much more the same than they are different.

Real-World Applications

Below I've listed a few of the more obscure incidents that I have been able to resolve over the years because of knowledge gained through my recreational development. 

  • After deployment of a new Access-based system hosted with Windows Networking, the client complained that the system was extremely slow.  I was able to investigate this using the Wireshark network analyser tool, and found that they were using an older version of the Server Message Block (SMB) protocol which was responsible for the slow transfer speed.  Using an up-to-date version of the protocol resolved the issue.
  • A colleague had been sent an SQL Server database backup by a customer while investigating an issue, except the database wouldn't restore.  With a hex editor, I was quickly able to determine the customer had compressed the file with RAR, while keeping the ".bak" extension.  Decompressing the file allowed it to be restored.
  • During a code review, I noticed that a junior colleague was using "ref" parameters inappropriately.  I was able to clarify to them how they worked with the briefest overview of the stack and heap memory model.
  • A user of one of our web systems reported that the page contained gibberish characters.  By recreating the issue with a custom tool which could show the network traffic as bytes, I was able to determine that an IIS configuration issue had caused it to deliver an uncompressed HTML error page with our GZip-compressed content directly afterwards in the same stream.
  • A customer had sent a spreadsheet file to a colleague, but it could not be opened.  Using a hex editor I was able to determine that the content was encrypted.  Apparently the file had been delivered on an encrypted USB drive which had not been correctly accessed.
  • Many times I have been able to use Wireshark, Telnet, or small custom applications to test and diagnose network connectivity and certificate security issues during deployment of an application.  This saved time by eliminating the need to guess at possible causes then liaise with various parties to test possible solutions.

Would you rather work in C?

Working in C is very freeing in many ways, but there are good reasons that technology has moved on.  The biggest commercial reason is that developer time is expensive, and more advanced managed languages and richer frameworks such as .NET mean development time is reduced, saving companies time and money.

No comments:

Post a Comment