We agree, we subscribe to the philosophy "languages never die". There are new languages added to the mix so things become more complex. It's part of the problem we're trying to solve and help dev #gofaster
This quote is from ActiveState on Twitter. It got me thinking especially because I am -- seemingly forever -- grappling with the idea of which programming language will help my career in the future.
I have been interviewing a lot of candidates for DevOps roles recently. I also interviewed as a candidate for a DevOps role with my upcoming employer. These experiences have taught me many new lessons as well as revived some forgotten ones.
bash (or at least Bourne shell sh) is ubiquitous in the Linux and BSD world. Replacing it with Python will not be easy, painless, or quick. But the plethora of base tools written in Python for Linux distributions testifies to the mindshare Python has gained. I don't expect the likes of FreeBSD, for example, to bring Python into base anytime soon. But we as users can certainly replace our code written in shell with Python.
I have been tinkering with my home network for a while now. Over time I have settled on some requirements:
Ubiquiti EdgeRouter Lite (ERL for short) is a small and lightweight device that fits all these requirements.
I don't work with Seagull anymore. I don't know how to develop in C++. I have absolutely no interest in maintaining this open source project. Yet when you Google seagull linux or seagull protocol my GitHub repo for the project shows up on the first page. How did I end up in this situation?
Judiciary in Pakistan has seldom -- if ever -- appeared to be independent and empowered. All major national events involving the Supreme Court have ended with egg on the faces of justices. From the hanging of Zulfiqar Ali Bhutto to the widespread fraud in 2013 elections, judges have opted to placate the most powerful figures in national politics. Justice makes way for political gain. Is this about to change when the new Chief Justice of Pakistan's Supreme Court takes oath on December 31, 2016?
I have been writing tiny shell scripts for many years now. It was always with the help of DuckDuckGo searches and places like StackOverflow. I never grasped the history, features, syntax, etc. of shells. This all changed when I got serious about learning Unix shell programming.
Any sufficiently large software system depends on a lot of third-party artifacts, from operating systems to libraries to pre-built packages and everything else in between. For example, to deploy a single web server running a Django application requires a developer to pull in a Linux OS, Python, Django, Gunicorn, nginx, etc. Whether this complete package is deployed on a VM under your control or your customers', you want to follow conventions in the entire lifecycle of the application.
I will recount the original CI process and the work that went into refactoring it. Although my role is quality assurance (QA) I had to don my release engineering (releng) hat for a few sprints. I could have let things be as they were but they were a hindrance to my work of testing and test automation. Rather than wait for the DevOps team to tackle the technical debt in our releng processes as time permitted, I decided to take this head-on as "step zero" in the long list of steps needed to make our continuous integration (CI) process efficient and fast.
make is a legendary tool to build software and is equally notorious at the same time. It is really good at what it does and has been forked many times to fix its many flaws and papercuts.
There are alternatives implemented with or without custom domain specific languages (DSL). Some are implemented in Python, such as SCons, pymake, Waf, BuildIt, and Invoke. Some are implemented in other languages like cmake, RAKE, Ninja, and Blur. The question to ask is: which would you use to solve what problems?