On change and jellyfish.
I’m on vacation with my family at the Curonian Spit in Lithuania. This is a breathtakingly beautiful place – a thin stripe of sand dunes and pine woods washed by the Baltic Sea on one side and the Curonian Bay on the other. There are bike routes running through the whole length of the spit, an endless sandy beach, and plenty of wild birds and animals. The food is cheap and the Lihuanians are friendly. We all had a lot of fun biking, walking and bathing in the cold waters of the Baltic. For me this is also a nostalgic experience – I’ve spent most of my childhood summers on the Baltic Sea. But it’s been more than 20 years since I last tasted its lightly-salted waters (compared to the intense saltiness of the Mediterranean). So the first plunge really brought back memories.The taste didn’t change. But other things did.…
How I get inspired by my kid.
My kids are my source of inspiration. Children in general are bursting fountains of innovative ideas. Some of them make us laugh, yet others annoy the heck out of us, but most of them are exciting. Especially when it’s your own kid who comes up with an idea 🙂 But this time it wasn’t an innovative idea that got me inspired. It was the entrepreneurial spirit and execution of my elder son, Eran. The kid is hooked on a computer game. Which in itself is nothing special. Though the game is quite interesting. He and his friends play Minecraft. Now, I’m always very curious about what excites my children. And I’m the ops guy at home, helping everyone with their tech needs. So I started looking at the game, helping Eran with installing game mods and reading up on the game history and ecosystem. I loved the whole story of the game starting…
How To Hire for DevOps
About the image – I originally thought naming this post “How to Hire Ninjas” but then realised I don’t honestly like the analogy. DevOps people are not ninjas – they don’t work in disguise and aren’t trained from the very childhood. Moreover – this heroical ninja image is actually harmful. It only contributes to the DevOps identity crisis as outlined by Baron Schwartz and lies at the very heart of the problem that I’m trying to suggest a solution for here. It’s no secret that the tech workforce market is starving for DevOps. (I know, I know – DevOps is not a job title, it’s a mindset.) The cloud, BigData and modern software delivery standards all produce the need for professionals who know how to get those complicated systems built, deployed and running. The demand keeps growing and the supply just doesn’t seem to catch up. More and more organisations…
Learning Ansible by Packt Publishing: the review
I got the offer to review this book on Ansible user group in LinkedIn. My previous experience with Ansible dated back about 1.5 years ago and the documentation on Ansible site was quite sufficient to get me up and running. So I was curious to see if the book would offer any substantial added value. I feel like the book’s title is misleading. If you’re looking just to learn Ansible – you’ll probably be better off using the official Ansible docs and walk-throughs. But – this book covers much, much more – e.g: using ServerSpec to test your configuration, building Docker containers, monitoring playbook execution with Nagios, etc. Thus – it provides you with a much bigger picture regarding where Ansible fits into your DevOps ecosystem. And – it can be a reference for all kind of things you might want to do with Ansible in the future – after…
It’s all about trust: from Continuous Integration to Continuous Integrity.
The introduction of Continuous Delivery systems and processes (when implemented correctly) brings four basic values to software development lifecycle: Structure Transparency Efficiency Quality While all of those are very important, today I’d like to put some more focus on just one of them which is sometimes overlooked or not understood correctly – that is Transparency . In fact there’s another ‘T’ word which results from transparency –Trust, and I tend to think it’s the most important quality of a CD process. Automated software delivery systems come to replace and improve the execution of multiple manual tasks involved in releasing quality software to end users. The benefits of automation are clear: create a repeatable process, eliminate human errors, replace expensive human time with cheaper machine time, streamline the tasks and there’s more… But what we must never forget is that there are some perils too. Perils related to putting all the processes under the hood of…
HowTo: Install VirtualBox guest additions on Fedora
1. Configure yum to use the RPMFusion repository: su -c ‘yum localinstall –nogpgcheck http://download1.rpmfusion.org/free/fedora/rpmfusion-free-release-$(rpm -E %fedora).noarch.rpm’ 2. Install guest additions: Fedora19: sudo yum install VirtualBox-guest-4.2.14-1.fc19 Fedora20: sudo yum install VirtualBox-guest-4.3.14-1.fc20
Maven Revisited
I was asked to deliver a Maven training for a team of Java developers. This was both a nice opportunity to refresh my Maven knowledge and to finally give Prezi ( http://prezi.com) a try. I realize that slides without the presenter aren’t worth much but still – feel free to use and share. Maven Revisited by Anton Weiss
Devops Enablers vs. DevOps Engineers
A lot has been said and written in these last 3 years in an attempt to define what DevOps really stands for. One thing most of us agree upon is that DevOps is not a job definition – it’s a culture, a mindset, a software manufacturing practice which is focused on breaking the walls between the developers and the operations. And it is a very cool and hip practice, one that everybody likes and everybody wants a piece of. So job postings for “DevOps engineers” pop up each day like mushrooms after a summer rain. And we adapt ourselves to the new realities and start calling ourselves DevOps engineers, even though half a year ago we were called CM, or integrators, or system engineers, or whatever. I myself just signed a new contract for “DevOps” role. And yes – I’m going to do DevOps. But I know that if we…
profiling:invalid arc tag ( iOS unit tests )
We’re running unit tests in the CI flow for our iOS products. One day the CI builds started failing with hundreds of lines of the following: profiling:invalid arc tag (0x0000000c) profiling:invalid arc tag (0x43555b2d) profiling:invalid arc tag (0x0000000c) profiling:invalid arc tag (0x43555b2d) profiling:invalid arc tag (0x0000000c) profiling:invalid arc tag (0x614d534e) profiling:invalid arc tag (0x5f787863) profiling:invalid arc tag (0x00000000) profiling:invalid arc tag (0x00000000) ** TEST FAILED ** But there were no actual failures in any of the tests.Turns out the thing to do is to clean out the derived data folder ( default: ~/Library/Developer/Xcode/DerivedData ) Problem solved 🙂 //