I like personal branding and use a lot of branded items. Besides my obvious Code Cop business cards, I use "Code Cop approved" buttons and stickers as giveaways. I wear my Code Cop shorts and hoodies when meeting new clients and when speaking at conferences. I enjoy keeping track of my reading progress using my Code Cop hand crafted book marks. What else could there be? After the embroidery prototype I was looking for something new to add to my branding toolbox.
Branding Iron
I have no memory of how I ended up with the idea, but I got a Code Cop branding iron. No I do not own any cattle or sheep which I need to mark, but at least "branding iron", gives a new meaning to "developer branding". My branding iron, see its picture on the right, needs to be plugged into electricity to warm up and after ten minutes it is ready. I have no idea how I will use it professionally - I am not selling anything in wood crates that could be marked - but I have a lot of fun marking everything in the house: For example, all my Escrima sticks and tool handles are clearly Code Cop's now.
Medallion
Later, after watching Netflix' The Witcher, I toyed with the idea of a Code Cop medallion, like Geralt is wearing. The Witcher's medallion is pretty large and has a raised and relief design, which means part of the silver wolf's head has a 3D effect. I searched online shops for some month for custom pendants. Most places offer two dimensional ones, using vector graphics to drive the cutting or engraving machine. I tested one such design with a simple pattern. The pendant was fine but it was too thin and flat for me. That was not what I had envisioned.
Eventually I found Lucas from Valeria Custom Jewellery who offered similar custom pendants. He 3D printed a mold and casted silver to create the three dimensional form on top of a large medallion. He sent me several work in progress images to check. During the whole process the cost went over the top, as I wanted a certain (too) large size, then shipping and tax for goods from overseas added on top. The total cost makes me wary to wear it. Further my wife keeps reminding me that I am not a rapper with their oversized and lavish jewellery ;-) While I am not wearing it, my Code Cop medallion is my most favourite branded item, sitting on my work desk right in front of me.
To make my medallion more "magic" like Geralt's one, I fancy some engraving at its flat, smooth back. Maybe some piece of source code that is of general significance? Which code would that be? Surely code like the Apollo-11 guidance system or the first Linux kernel are relevant. There are some collections like Computer History Museum's source code. Usually these are many pages of assembly. As the medallion is small compared to that, the code would have to be really short, a few statements at most. Maybe I will go with Greg Walsh's famous Fast Inverse Square Root calculation from Quake III source code: 0x5f3759df.
19 August 2023
1 August 2023
Shut up and write a test!
Due to the hype around ChatGPT I wanted to create this text with it. I failed. I tried several versions of different prompts, and also asked the Bing variant, but it failed to create any text I liked. It could not simulate my personal style. I should have to train a model with all my blog posts ... It seemed easier to use with the good old method of writing my texts myself.
Should I Write a Test?
Around ten years ago I stumbled upon a diagram if and when to write a test. This was a repeating question in trainings, when should you write tests? Before or after writing the code? Only when you have time? Only when you feel like it? I loved the diagram because there was only one end state. Whatever the reason or excuse would be, just shut up and write a test! It does not matter if you are tired, or if it is a little change, it should be tested. Such a rule is helpful when you want to adopt Test Driven Development, as there are plenty of excuses why to skip it.
The original diagram was created by Gemma R Cameron, a software engineer and event organiser from Manchester. She was inspired by a similar diagram about skating. Recently, when I was asked again when to test, I wanted to share the diagram and could not find its page. I thought it lost and planned to repost the diagram here. Eventually I discovered Gemma's page again, it had moved from a
Java Version
The original version of the diagram was for Ruby, indicated by the use of Automock. What was bad with Automock? It provided some support for automated mocking of Rails application and is dead since 2016. Here I present a slightly modified version for Java, replacing Automock with PowerMock. And I do know what is wrong with PowerMock. It is a powerful mocking tool which uses a custom class loader and bytecode manipulation to enable mocking of static methods, constructors, final classes and methods, private methods and more. It is useful to bring legacy code under test, before seams can be introduced. The bytecode manipulation makes it slow compared to regular mocking. If used often, the whole test suite will run much longer than needed. Further, if code is hard to test, I change its design to make it testable by applying SOLID principles or by creating seams as outlined by Michael Feathers in his WELC book. Using PowerMock for tests does not improve the design. (I am not inherently against PowerMock, it is extremely powerful and as such dangerous. I needed something to replace Automock.)
Download and print the Java version of the Shut up and Write a Test Diagram. The fact that there are versions of this diagram for both Ruby and Java is a testament to the universality of its principle: Shut up and Write a Test! The Code Cop approves, and I am sure your future self will too.
Should I Write a Test?
Around ten years ago I stumbled upon a diagram if and when to write a test. This was a repeating question in trainings, when should you write tests? Before or after writing the code? Only when you have time? Only when you feel like it? I loved the diagram because there was only one end state. Whatever the reason or excuse would be, just shut up and write a test! It does not matter if you are tired, or if it is a little change, it should be tested. Such a rule is helpful when you want to adopt Test Driven Development, as there are plenty of excuses why to skip it.
The original diagram was created by Gemma R Cameron, a software engineer and event organiser from Manchester. She was inspired by a similar diagram about skating. Recently, when I was asked again when to test, I wanted to share the diagram and could not find its page. I thought it lost and planned to repost the diagram here. Eventually I discovered Gemma's page again, it had moved from a
.me
to a WordPress domain. I am glad that the original source is still available. You can find it here.Java Version
The original version of the diagram was for Ruby, indicated by the use of Automock. What was bad with Automock? It provided some support for automated mocking of Rails application and is dead since 2016. Here I present a slightly modified version for Java, replacing Automock with PowerMock. And I do know what is wrong with PowerMock. It is a powerful mocking tool which uses a custom class loader and bytecode manipulation to enable mocking of static methods, constructors, final classes and methods, private methods and more. It is useful to bring legacy code under test, before seams can be introduced. The bytecode manipulation makes it slow compared to regular mocking. If used often, the whole test suite will run much longer than needed. Further, if code is hard to test, I change its design to make it testable by applying SOLID principles or by creating seams as outlined by Michael Feathers in his WELC book. Using PowerMock for tests does not improve the design. (I am not inherently against PowerMock, it is extremely powerful and as such dangerous. I needed something to replace Automock.)
Download and print the Java version of the Shut up and Write a Test Diagram. The fact that there are versions of this diagram for both Ruby and Java is a testament to the universality of its principle: Shut up and Write a Test! The Code Cop approves, and I am sure your future self will too.
Labels:
adoption,
diagram,
getting started,
test-driven,
unit testing
Subscribe to:
Posts (Atom)