I found a hugely insightful article on naming. It encourages concise naming, and lays out really clear principles on how to name variables well.
“A name has two goals:
After a name has accomplished those goals, any additional characters are dead weight.”
https://journal.stuffwithstuff.com/2016/06/16/long-names-are-long/
Here’s a puzzle. Does a “wrapped URL” refer to the wrapped result, or the original URL input that was wrapped?
Language is our tool, but occasionally we can get confused or go in circles over semantics. Find the story of this brain-bender, and how we clarified it, here.
Continue readingHey! Want to be able to open JIRA issues or Wiki pages instantly, without needing to open a bookmark before you can search?
Chrome lets you define custom “search engines” to search JIRA/ Wiki, using only a keyword in your URL bar.
Continue readingNaming is the most important part of design. Concise yet meaningful names are hugely important.
One of my top recommendations to improve legacy code, is to improve & clarify naming. Names should be short and sweet, yet meaningful. For example — Customer.Name.
Continue readingLast week I had to debug some unstable tests, which were only launched externally from Ant (launched from Maven). The tests were largely not directly runnable from the IDE, and did not run equivalently.
Obviously this is outdated practice and not good TDD, but sometimes we need to work with such assets anyway 🙂
Given that, how could I debug & fix these tests? Continue reading
When investigating complex issues with Maven or command-line tools, it is often helpful to capture the output to a file for further analysis.
This tip shows how to capture both ‘stdout’ and ‘stderr’ to capture a complete authoritative output. Continue reading
From the Classic Programmer Paintings blog. Enjoy!
“Operations and Developers agreeing on Git workflow”
Jacques-Louis David, 1796-1799, Oil on Canvas
(collaboration from @rpiaggio )
Software issues in Production can be some of the most demanding challenges a team can face, especially when occurring on a system outside of your control.
Adapted from the OODA loop — a military strategy used to describe the decision cycle of observe, orient, decide and act — this process formalizes an approach to take control, establish facts, and progress towards a resolution for even the most difficult problems.
Logging frameworks have become a standard part of projects, since Servlets and Log4J first emerged. But how should we log? Are we getting the most we can from it?
Many developers see logging & debugging as separate tasks. When confronted with a problem we set breakpoints, step through, inspect variables, and trace through loops – often finishing hours later..
Finding problems this way is hard. Does it have to be so difficult? Could there be a way to get right to the problem area, in just minutes? Sometimes without even needing to step through? Continue reading