Since about 2015 or so, it seems like there are always Raspberry Pi’s lying around the place, at work and home, just waiting for some project to come along to put them to use.
One of the Pi’s looking for a job as part of my home lab has found just itself retasked as a Plex Media Server following a very simple process.
A new Operating System was written onto the SDCard, this time out the OS chosen was the Raspberry Pi variant of Ubuntu Server order to have a more consistent experience across systems being used lately.
Once up and running and fully patched, the Plex repo was added and the Media Server installed via apt.
Directories were added to host the media library and the Plex configuration ran. Once complete it was a simple matter of connecting the TV to the new media server via the Plex app and enjoying the content I had that was driving this little endeavour in the first place.
I heard it said recently that a Raspberry Pi with decent enough storage can be purchased for less then the price of running an EC2 instance for a year, so when it fits the use case a Pi can be a great solution and even in the age of cloud there are still times when it’s better to run locally (streaming dodgy media being a classic).
Far too often in home lab situations, where there’s some interesting idea to be explored, efforts get derailed as a result of sinking too much time into the environment setup particularly when something like Oracle Database is involved. Maybe the the initial idea is to play with data migration or to investigate some new feature or just to brush up on skills, but whatever the scenario there’s a need for an environment and then, just like that, a week has passed and you’re just about ready having hunted down all the obscure errors and issues thrown up as the setup has progressed, when you get distracted by something else as the idea you wanted to work on has been crushed by the weight of getting things ready.
It is perhaps unsurprising when you consider the widespread adoption of the framework by development teams around the world that there seems to be almost as many variations of practices as there are teams working under the auspices of Scrum. Over the years since Scrum burst onto the development scene as a new way of organising to deliver complex work, a host of techniques, customs, and habits have found their way into how teams implement Scrum in the real world. Anyone who has worked with different teams in different organisations can tell you how these customs can vary and of the delight that can come with introducing to a team a practice that you saw work somewhere else.
Earlier today I was fortunate to be able to participate in a webinar for Laois and Offaly Education and Training Board on the subject of psychological safety in teams, which is a topic I care deeply about as it’s so essential for cross-functional agile teams to be able to operate well, but beyond that, ensuring psychological safety at work is in my mind simply the right thing to do!
A lot has already been written about the year 2020 and I’m confident that an awful lot more will be written about the impact on society this particular year has had. As the events of the year unfolded and various aspects of life were forced to adapt to the different challenges that were thrown up, it seemed like more and more material for academic papers, theses, policy documents, training materials, and even half decent fiction was being presented on an almost daily basis. From the technology leadership perspective I think 2020 showed that there’s work to be done around how to adapt Agile processes to remote work, but while interesting this isn’t the only area where there’s something to be learned, so in the best traditions of the internet here’s a list of things I consider among the lessons 2020 taught.
As someone who has spent their career working with systems I have come to love a good framework. Taking a systematic approach to how things should operate enables me to conceptualize the tasks at hand and to identify gaps and weak spots so that they can be managed successfully. Identifying the component parts of my new role as Director of Software Innovation with ACETECH and weaving them together into a framework of sorts has helped me in these early stages to approach some difficult topics with confidence as well as quickly establishing where I can add value.
A new opportunity has presented itself to me that is so aligned with my
desired next move that it’s hard to believe. Next week, I start a new role
heading up the software engineering department of a technology company located
in the Irish Midlands; in fact, located about 3 minutes from my home. And this
isn’t a small opportunity, this is the chance to head up the software delivery
aspects of a global player that makes a real impact on people’s lives.
There’s always a lot going on in work and it can be easy to sacrifice essential, foundational activities in order to progress the “real work”, but doing so eventually takes a heavy toll. Just like spending enough time contemplating what’s being done and why and if that’s the right thing to be doing, there is a need to be prepared and thus avoid going into every situation trying desperately to figure out what’s going on and determine your position on the fly, a position that you may regret taking and finding you later need to defend out of not wanting to loose face.
I flip-flop on the subject of whether to use a paper notebook or to use a laptop for everything including note taking in meetings and capturing stray thoughts. My indecision comes from appreciating both sides of the argument for either tool with laptops claiming the higher ground in terms of efficiency but loosing out to things like noise levels, having the opened screen imposing a barrier between you and other people, the issues around battery life, and the distractions that come with the installed apps all clamouring for your attention, usually when you need to be more focused. Continue reading “Notebooks”
There can be many reasons for wanting to explore the use of Chatbots. In situations where collaboration tools like Slack are already in place, introducing a bot is merely another form of automation to support the way people work. In companies that are interested in providing a forum for people to develop technical skills, there are definite possibilities offered through Chatbots, especially as extending their functionality is not overly difficult and actually makes them more useful. For the enthusiast, Chatbots provide a glimpse into a future where interactions with technology are more fluid, based on natural language and conversation, but this is where challenges remain, for despite all the powerful technology that has been used to create Hubot, frankly it isn’t that chatty for a chatbot.
Slack is the latest hip tool that technology teams have come to depend on. Based on an idea eerily similar to Internet Relay Chat (IRC) that was extremely popular back in the mid-nineties, Slack allows teams to collaborate in web and app based chat rooms and is growing in popularity with enterprises as well as the smaller start-up world where it first took off, as larger businesses are realising that Slack provides a very neat audit trail through the log of the chats themselves.
Slack is extremely extensible, and this is where Hubot comes in. Slack is the perfect interface for Hubot as bots can be team members in Slack, appearing in chat rooms and interacting like everyone else.
Finding a good excuse to learn a new technology is something I’ve been interested in for a while particularly as the pace of change and technology adoption only ever seems to be increasing. Knowing that the IT world is in an ongoing state of flux, finding an engaging way to learn about the tech that technologists are expected to know is more than idle curiosity, it’s essential for career success.
Revisiting Chatbots, a topic I encountered through a Wired article from summer 2015, I discovered that getting a chatbot up and running, and more importantly, useful and usable, involved a wide variety of different technologies. As the article was heaped so much praise on Github’s bot, I decided to try it out with a view to having it do some useful tasks around AWS administration, one of the two challenges that had been put up to our 2016 interns.
Employee engagement is a big issue for any company, put simply disengaged employees leads to departing talent, so it’s vital to constantly be looking for ways to develop teams, especially those working with technology, in ways that result in high levels of ongoing engagement.
Oracle very kindly offered to run through a Proof of Concept installation of their GoldenGate replication product with us, and seeing as how we’re not prone to looking gift horses in their mouths, we’ve accepted!
Quiet Friday’s are a nice treat but something too often squandered. This past Friday I found myself left to my own devices as the rest of the DBA team were working from another location. This left me free to get a few things about running our environment straight in my own mind with the most notable being was how to use CommVault for database backup and recovery beyond simply copying RMAN output to tape.
// Data Guard // Database Incarnations // Standby Logs applying in Alert Log but not in V$ARCHIVED_LOG
Over the past week I’ve been getting a great introduction to the practical workings of Data Guard. In the past I’ve worked a lot with Disaster Recovery systems built using Oracle standard edition and therefore not licensed to use Data Guard and in those circumstances a poor man’s version of the system was put in place by using RSYNC to synchronise archive logs between a production database and a DR database. With the logs in place, a script run on a schedule would recover the data from the logs. It turns out that the concept of Data Guard is pretty similar in that it’s basically about getting archive logs to the right place and setting the destination database into a mode where it can read those logs and be ready for when disaster strikes.
The programmatic nature of Oracle’s Recovery Manager tool provides great flexibility but also creates a common problem of insecure scripts being left running on production servers allowing anyone to read critical password details with ease. Continue reading “Securing RMAN Scripts”
Shared Storage systems are very common in enterprise computing but it’s not cheap or easy to get access to the technology for eduction or testing purposes. In this posting I investigate if a system like Openfiler can work in those circumstances, and if it’s worth the effort.Continue reading “SAN Simulation with Openfiler”
My diary today is blank. Of course, the fact that I’ve nothing scheduled to do doesn’t mean that I’ve nothing to do. In the life of a consultant an empty day in the diary can be a Godsend allowing for the all important admin to be done, leading to a day filled with expense claim submission, outstanding paperwork being filed, laptops getting some much needed systems administration attention, personal projects being followed up on (like the in-house test servers I manage), and clients who haven’t been in touch for a while getting a courtesy call to ensure that everything is OK with them. These days are much needed and welcome. But not too often.
An IT Consultant with “nothing in the diary for today”
It can be easy as a consultant, who lives and dies by the contents of the diary, to look at their full calendar for the next few weeks and despair at how busy they’re going to be, overwhelmed by the volume of work coming their way and longing for empty days like today. I like to take a different, more entrepreneurial view of the diary and try not to think of it as merely a calendar of upcoming activities but rather as my order book, as a promise of future work, and that puts the whole thing into a more favourable light.
Regardless of how you look at your busy schedule, the fact is that managing the diaries of multiple people can be a complex task and should be handled with some care as mismanaging it can lead to disaster. With this in mind, here are some of my considerations for managing the diaries and therefore the time of consultants. Continue reading “5 Considerations for Brilliant Diary Management”