I’ve written before on this blog about the importance of naming “things” in a tech platform/framework and I feel this deserves a bit more attention, so here is a follow-up.
Previous post saw me discussing naming class member data as well as database fields — these can wreak havoc amongst your users (be them developers or simple customers running reports). Not to mention that it can end up confusing even your own team further down the lines, when the memory of the reasons for choosing a name has faded away!
That’s not the only place where naming can hit you! Naming components in your system wrongly can have disastrous effects. (And by components I mean anything from a simple class or collection of classes, a library in your framework to actual standalone server software components running in your infrastructure.)
OK, so I’ve decided to blog, amongst all the other stuff I publish on my blog, about some of the experiences I’ve been through or remember from “ole Romania”: the pre-1989, communist, Romania — or RSR (The Socialist Republic of Romania as it was known to us). I’ve realised recently, talking to people “from the West” that a lot of these experiences are absurd and funny to them and people have no idea about some of the things that used to happen in the Eastern Block in Europe. Even more so, they quite likely don’t realise that a lot of these things happen still in countries like China and the likes!
So with that in mind, I’ve set off to reveal some of the things that I remember — having been through all of these and come out (relatively) normal and alive, these all seem funny nowadays; however, these are things which affected entire generations and left an imprint on a lot of lives and destinies. Therefore, as much as the memory of some of these things amuse me nowadays, they are not to be taken lightly!
As a side note, for those of you unaware of the history, Wikipedia has a pretty decent coverage on the Romanian Revolution of 1989 which has overthrown the communist regime. I was 14 when this happened and still remember some of them — enough to blog about them!
This one is another good find from the maven “gotchas” archives. Good enough at least to make it onto my blog
I brief, I’ve been pulling my hair for the best part of yesterday trying to figure out what’s going wrong with my maven-based project, which used to work otherwise fine until recently. It used to compile without problems, package and deploy like a dream. And then yesterday, as I found out, the release process sort of worked … but not quite the way it used to do! More to the point, it did the packaging, did the revision increment and github tagging — but it only deployed the SNAPSHOT version!
For those of you who keep an eye on my blog, I write quite a bit about technology and about software engineering — that’s because by trade I am a software engineer and quite passionate about a few areas in this segment. I write code and as such I blog a lot about coding. I wrote a lot of code lines in my life and I’ve encountered various things (good and bad) and sometimes I feel I need to share some of my experiences and the knowledge I’ve gained going through them. And today is such a day: I’ve just looked over some code recently, doing a sort of a technical audit for a friend and found myself confused at times about something that is overseen quite often: naming conventions!
And I’ve realised that naming is often perceived as such a small aspect to the point that no one really cares about it that much — and this leads often to confusions and errors. Whether it’s naming of variables in the code, of fields in databases or on reports or even naming of system components, this is hardly ever looked upon as a serious matter. “Just get it done and deploy it so we can move onto the next piece of functionality” seems to be the approach — and as such components such as “email validation engine” make their way into production and code ends up written around it, only to surface later on (typically due to some production outage) that the component doesn’t actually validate email addresses, but instead checks that the string provided “looks like an email address and has an @ and something which looks like a domain“. By that point you find out you have a lot of wrong email addresses of your customers in and you have no way of contacting them now… You get the picture!
I’ve decided as such to share a few of my experiences when it comes to naming “things” in software engineering — hopefully these will help others avoid mistakes made in the past.
Quite a while back, (and I mean quite a while back, that’s been enough water under the bridge so I can now tell the story ) I used to work for this guy who quite frankly was way out of his depth in the position he was in. He was my (and others’) boss nevertheless and as such we had to work with him and for him. And in a lost of cases we had to work despite him too — which I’m sure paints a bit of a picture about the guy by now
Bottom line, for whatever reason — and I think he didn’t know that either towards the end — he found himself being our boss, and the thing is he realised I’m sure deep down inside he was way out of his depth there. This realisation though, rather than comfort him made him very insecure, which had a huge negative impact on the team. Rather than thinking: “Great, I have a team here who can cover all bases, all I need to do is help them set up the roadmap and prioritize their own work and these guys can do it all while I sit back and let them all do their magic”, he actually started micromanaging every single one of us and trying his best to show all the way to us and everyone else that he is better than each and every one of us at everything we did.
I’ve been using the aws-maven plugin for a while now to deploy Maven artifacts to S3. Typically I’ll use the Maven Archiver plugin to package the projects in some sort of tarball then use aws-maven to upload this to S3. From there on regardless of the deployment tools I use on our production servers I can simply use some script to download the tarball and unpackage it on the server — and maybe even run some (packaged) scripts — to install the software in production.
And also typically in this scenario I’ll use the archiver and aws-maven in the context of the Maven Release plugin — so after all tests have passed and I’m ready to release a version I simply use
mvn release:prepare and
mvn release:perform — this packages the software (via Maven Archiver) and then copies the tarball to S3 (via aws-maven).
Trying to become a foodie is not easy
Believe it or not this antique saw me learning Basic back in the day — a few centuries ago
I still have it — well, my parents do — and it’s still working!!!
Though I haven’t got a tape player nor do I have any of the programs I worked on — or the games I used to play on the old Sinclair Spectrum
To my shame I couldn’t remember the keystrokes to change in between symbols, caps, keywords and graphics entirely — took me a while … CAPS + 9 switches to graphics as it turns out And also I had to remember the usage of GOTO statement