I’m a big fan of Raspberry PI — to the point where I have actually 2 of these little rascals. (I actually use one of them occasionally to run bits of development stuff on it — test things like
groovy scripts etc; and the other one I sort of keep for experimental PI projects, trying to figure out the intensity of the light outside, whether it’s going to rain and all sorts of useless things ) Anyway, I find myself for simplicity I try to keep the 2 of them in sync so to speak — in other words whatever packages Raspberry PI 1 has, I try to keep on Raspberry PI 2, such that I can interchange them easily. (That in itself makes using them so much easier!)
To keep them in sync I normally take an image of the SD Card from one of them on my Mac, then install the image on the other SD Card — which then goes into the other Raspberry PI. This way they both run with exactly the same config and also I get to make a backup of the SD card, which occasionally has been known to be temperamental. (Nothing worse than the card getting corrupted without a backup so you have to re-set it all up )
I use Twitter a lot (see for yourself here if you don’t believe me ) — and as such it annoys me terribly when I see companies using it the wrong way. And by “wrong way” I’m not talking about the contents of their tweets — it’s a free world and everyone has the right to tweet whatever they want as far as I’m concerned. (Whether I will decide to follow them on Twitter and read the content they publish there is a different matter.) I’m talking here about how Twitter is employed to deliver marketing messages to the online users.
Twitter is a very powerful tool for that, with a huge reach, we all know that — and as such in the right hands can generate a lot of user interaction. And also, in the wrong hands it seems to create awful user experiences which (getting back to my point) annoy me terribly!
It is not my intention here to point fingers — which is why in the screenshots below I’ve removed the logo and Twitter handle — rather just point out what’s wrong with this situation so others hopefully can avoid making the same mistake (and generating rubbish user experiences).
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