devopsy.kinsta.cloud

Tag: Python

  • WTH? We Wanna WFH | DoD Dual-Sources JWCC | More Nvidia ARM Woes

    WTH? We Wanna WFH | DoD Dual-Sources JWCC | More Nvidia ARM Woes

    Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.

    This week: Working from home is de rigueur, JEDI redux, and more about Nvidia/Arm.

    Survey Says: Devs Stay Out of Office

    First up this week: GitHub’s annual survey of developers has some fascinating data on the workplace (ahem) “new normal.” The pandemic has radically changed devs’ expectations of where they can do their jobs.

    Analysis: WFH is SOP

    As with other roles, Dev people want to continue to work from home. But does this pose a threat to your DevOps culture? Make sure you can do Ops with equal flexibility.

    Paul Krill: Dev productivity is back to pre-pandemic levels

    GitHub’s “2021 State of the Octoverse” research … sees signs that work rhythm is returning to pre-pandemic levels. GitHub also found that 46 percent of developers who worked co-located with teammates now expect to work fully remotely or in a hybrid environment.
    …
    Based on data culled from more than four million repositories and surveys of more than 12,000 developers … JavaScript and Python remain the top languages, followed by Java and TypeScript. [And] GitHub found that development team performance can increase as much as 87 percent when reusing code and as much as 43 percent when using … CI/CD.


    Zeroing in on the WFH angle, it’s Richard Speed:

    Respondents who were in the office either full or part-time dropped from 42 percent before the pandemic to a mere 10.7 percent now. … That’s a lot of empty desks.
    …
    Fans of the ctrl-c, ctrl-v combo will be delighted to note that GitHub found that when code reuse was made “frictionless” at work, developer’s performance increased by up to 87 percent. … It’s all splendid stuff.


    But beware of statistical fallacies, thinks Henrik Ingo—@h_ingo:

    #WorkFromHome may have been more common than anyone realized. [But] is the population of GitHub users/respondents somehow skewed toward pioneers/early adopters? … This might be a case of correlation is not causation.

    Defense Dept. Orders New Clouds

    The DoD issued its latest cloud contract opportunity notice, with the snappy title of “Joint Warfighting Cloud Capability” (JWCC). Reading between the lines of the notice, it all sounds very DevOps-cum-Agile.

    The Pentagon has backed away from its previous insistence on a single supplier, and now wants at least two cloud providers.

    Analysis: JEDI redux, because AWS wants a do-over

    JWCC is the follow-on from the aborted JEDI procurement. Amazon Web Services was “disappointed” to have been passed over in favor of Microsoft. Now it appears the DoD wants them to share.

    What can you learn from such a multi-vendor DevOps strategy?

    Jordan Novet: Pentagon asks Amazon, Google, Microsoft and Oracle for bids

    Amazon and Microsoft were the finalists for a single Joint Enterprise Defense Infrastructure. … Microsoft won it in 2019, Amazon filed a protest and the Pentagon canceled the contract in July.
    …
    The new effort [is] known as Joint Warfighting Cloud Capability. … JWCC differs from JEDI because it allows the Pentagon to rely on multiple cloud providers.
    …
    The U.S. General Services Administration … said only two U.S. cloud infrastructure providers, Amazon and Microsoft, appear able to comply with all of the Pentagon’s requirements. … The value of the new contracts is not known, but the Defense Department estimates it could run into the multiple billions of dollars.


    In summary, heed this Anonymous Coward:

    Competing suppliers will try harder than one non-competing supplier. The DoD has had a lot of problems with One-Ring-to-rule-them-all systems like the F-35. … JEDI would have been the same.
    …
    Smaller steps with upgrades while testing/using offers better returns. Done right they can get a better deal by making the companies compete against each other in making sure the products are actually useful.


    But look carefully at the DoD contract opportunity, says bustinbrains:

    They’ll all get contracts. Then DoD will simply use the one that they actually like the best. No one can complain because it’s open-ended with no guarantees.

    Arm/Nvidia Deal on FTC’s Radar

    Last week, we talked about Nvidia’s goal to acquire Arm Ltd from SoftBank, and the regulatory challenges it poses—notably in the UK, home of the chip architect. After we went to press, the other shoe dropped.

    Analysis: Just Give Up Already

    As we said last week, Nvidia can’t be allowed to do this. Not only are ARM chips found in 99% of smartphones, but they’re an increasing fixture in the datacenter—especially places that value “performance per Watt.”

    Richard Waters: What’s next for the tumultuous takeover of Arm?

    Nvidia’s acquisition of UK chip design company Arm from SoftBank has provoked serious opposition on both sides of the Atlantic. … The US Federal Trade Commission had its own worries. China, meanwhile, is waiting in the wings.
    …
    The deal has shone a spotlight on the unique position Arm plays in the chip industry. [Nvidia] offered a guarantee that it won’t block any other companies from licensing Arm’s designs. The offer has fallen on deaf ears, with both the EU and UK ruling it inadequate. … Post-Brexit politics have also come into play.
    …
    At what point might Nvidia and SoftBank call it a day? … A stock market listing [is] the most likely alternative, with the UK a favoured venue.


    How’s it viewed from the inside? Here’s a hint from fivemack:

    I was at ARM when Softbank bought them; it came as a surprise to everybody, because we were absolutely confident that we were unbuyable because anyone interested in us would want to use differential licensing as a weapon against their competitors, and we … were confident that regulators wouldn’t accept that.
    …
    Lots of people went home with a year’s pay check in free money. And not a few people … went home with a decade’s pay check in free money.


    More and more DevOps workloads are running on ARM silicon. Here’s Biophoton:

    The low power expertise of ARM has to be an advantage in the data centre (DC) market. … Plus Linux is available on ARM so architectural lock-in of Intel could be eroded in the DC market.

    The Moral of the Story: You are known by the company you keep


    You have been reading The Long View by Richi Jennings. You can contact him at @RiCHi or tlv@richi.uk.

    Image: Lukas Mann (via Unsplash)

  • Languages and DevOps: Mainframe

    Languages and DevOps: Mainframe

    In true DevOps fashion, I nearly forgot to cover the mainframe after saying it warranted its own blog!

    There is a lot going on right now in the mainframe space, so the question of mainframe language choices has several different answers. We’ve got Linux running on the mainframe, we’ve got cross-compiled open source capable of running on the mainframe natively, we’ve got mainframe-based containers and we even have traditional mainframe tools being ported to other platforms (hello, COBOL on Linux!) so that development can happen on smaller platforms but target the mainframe.

    Taken in the order they came available, we have traditional mainframe development, in languages like COBOL and RPG, right on the mainframe in standard LPARs. This has gotten easier over the years, but is still basically the same development environment that was used in the 1980s, with prettier UIs.

    Then we have Linux LPARs available that allow for development right on the mainframe. There are issues and differences from other Linux development environments, but not as many as you’d think. This approach gives a broad selection of development tools on a Linux platform, making it an appealing choice.

    Next came containers, which can then run Linux in a container with the container offering the interfaces that Linux expects to find. This approach has the benefit of being more like development on other Linux platforms, but interaction with core services can still be platform-specific at times. This approach offers the breadth of open-source languages that came naturally with containers plus the few that have been ported over to z/OS.

    Then came speed porting. The biggest weakness of the above options was that it took too long for vulnerabilities to be addressed and new functionality to be moved over to the mainframe. The fact is that porting a language took time, and wasn’t as rapid as the response for the core Linux kernel. There has been a movement to improve the dev tools that create the ports, and now response time to CVEs or improvements in the kernel is much better. A side effect of this movement has been increased availability of languages and tools that are used by DevOps to get things done.

    Finally, we have recently received support for traditional languages on other Linux platforms. Most notably, given the number of lines of code out there, COBOL is now officially supported on Linux, meaning you can develop on the desktop without a ton of overhead, and then deploy to the mainframe. This has the effect of enabling DevOps processes and mentality for more traditional languages. This is still new, and the differences between developing on one platform and deploying on another will have to be worked out, but it is a step in the right direction.

    So what should you use?

    Mainframes are generally a more controlled environment than most DevOps teams are used to. The work required to support and update a given language, keeping it and its libraries up-to-date is more complex than just a generic Linux system, and that gives rise to very focused shops in the mainframe space. Generally speaking, you will be told what to use, or more to the point, which languages are supported. If you get input into the process, recommend Python, as it has the biggest pool of developers and libraries out there at the moment. But chances are, the mainframe team already has a language in place that they want DevOps teams to focus on, and in that case, use what’s available.

    No matter which language you end up using, API-wrapping mainframe functionality is a time honored tradition at this point, make the mainframe do the heavy lifting and return just what your application needs. Think of it as a big, smart database that can pre-process results for you at high speed, in high volumes.

    And keep rolling.

    Mainframes have been around forever. They’ve been pronounced dead dozens of times, and yet the security, stability and locality of a mainframe keeps them in the mix. Data gravity helps too – the data is there, the routines to do processing on the data are there, handing that data off to another platform for presentation isn’t that big a deal, and the mainframe just keeps ticking along. Because (at this point) generations of developers have made it tick. Keep that tradition alive if you’re in a mainframe shop; they are literally the core of systems in the places they are in heavy use.

  • Languages and DevOps: Network

    Languages and DevOps: Network

    It is fun to discuss the changes in network operations over the last couple decades. We’ve come full circle, and, honestly, ended up in a better place. Network specialists were super command-line wizards who kept us going, with few GUIs in sight. Everyone thought the next iteration would be GUIs, so network operations could be accessible to more than a few command-line specialists. “Everyone” was mostly right; we did head in that direction. It was optional, and many network operations friends pointed out that you could still do more, faster with the command line. Before GUIs had the opportunity to catch up with command lines, though, automation came along. And then DevOps. And finally,* configuration-as-code. Pretty quickly, the ability to do everything through an individual product’s GUI was determined to be a weakness. Network operations personnel were dealing with more vendors to handle the networkification (it is too a word! I just made it up) of common development activities, like some aspects of security. And now, APIs and command lines rule the juncture of DevOps and networking.

    *Finally – so far, at least

    And that shows in languages. Shell scripting and Python run this show, with little competition from any other language. We could get into a massive discussion about whether shell scripting is programming, but we won’t, because at least in networking, it most definitely is considered to be programming.

    One time, when we were tracking down a problem that involved all of IT, I was sitting with the serious network geeks and marveling at their ability to make everything they wanted happen from the command line in an instant, and their ability to parse command output. I’m no slouch when it comes to networking, but they easily put me to shame. I got to chatting with a few of them, and the consensus was that they loved computing but hated programming. Networking made sense to them. This explains why networking DevOps people are continuing to use Shell scripting and adopting Python at the same time.

    Python and Shell

    Shell is a given in networking. There are a lot of extant Shell scripts for doing all sorts of things, and the need to automate to keep up with Agile makes shell scripting a logical choice.

    Python enters the picture because it is “common ground.” It is intuitive enough for most networking people to do what they need to get done, and known or knowable to most developers. When it comes to usage, Python has overtaken Shell; (don’t take my word for it, check out the excellent work of the NetDevOps survey on GitHub, or just glance at the graphic below, created by them) in fact, Shell and Python command so much of the network development space that you are probably better off just making sure you’ve got those down, and focusing your free time on other issues like completely different networking commands, or even skills for data center versus cloud. The ROI would be better.

    But Wait, There’s More

    The key operational changes recently have been around GitOps and reporting back into the DevOps toolchain. People no longer want your appliance or application to have a pretty GUI, they want it to report in to the tools that provide automation and a larger-picture GUI. Many vendors are there already, but many are not yet. That creates a need for tools – products, open source projects, or internally developed – to do that integration while waiting for the vendors to catch up. These, again, are well-served by Python, though other languages that can handle APIs are viable, too.

    We’re headed for a world where systems detect anomalies and react to rectify them, but we’re not there yet – not on a strategic scale, at least. And we probably won’t be for some time, as automating massive network changes is a scary proposition and will take time to use these systems for detection, monitoring what they could have done, before organizations are willing to let them “just do it.”

    Carry On

    Meanwhile, NetDevOps is getting folded into DevOps proper, and in many organizations, using infrastructure-as-code or GitOps, is being deployed and managed like any other part of the life cycle. So we are moving along. For my network peeps, your job will continue to change, but it certainly won’t go away. You’re essential to smooth-running systems, and while the network may become even more virtual, it will still be networking. And under that virtual network will be … a physical network. So keep kicking it, and carving a path from users to apps, while protecting those apps and ensuring they have adequate resources. Oh, and if I spin up another instance at midnight, you’ll hop on and make sure it’s got traffic directed to it, right? RIGHT?!

  • Python Remains Popular in Programming Language Study 

    Python Remains Popular in Programming Language Study 

    A ranking by analyst firm RedMonk reflects on Python’s continued popularity as a leading enterprise programming language for a number of reasons. According to a recent study by RedMonk, JavaScript also remains widely popular as the web development programming language of choice for a significant number organizations. 

    In many ways, Python’s strong showing in the ranking — drawn from GitHub pull requests and Stack Overflow data — indicates its long-term viability among DevOps developers. 

    “One lack of change that is worth surfacing is Python’s number-two spot,” Stephen O’Grady, a RedMonk co-founder and analyst writes in The RedMonk Programming Language Rankings: January 2021. “Java was extremely hot on Python’s heels – and was, in fact, closer to the number-one ranking than to PHP behind it – but Python’s ability to defend its new high ranking is notable.” 

    RedMonk

    Python’s prolonged high ranking is notable because of its versatility, Rachel Stephens, a RedMonk analyst who is responsible for the RedMonk Language Rankings’ design, told devopsy.kinsta.cloud. “The breadth of use cases — and associated libraries that support those use cases — means there are a number of possible entry points for developers. The number of toeholds for the language within the enterprise helps its ubiquity,” said Stephens.

    There also remains much discussion about what accounts for Python’s continued popularity beyond the scope of the study. A popular subject in forums, including Reddit, Python is typically described as highly versatile, relatively easy-to-learn and a simple, yet elegant language. While not cited in the RedMonk study, some software engineers and coders — such as this writer — appreciate how Python can make more intuitive sense, and is also less rigid compared to, say, a classic language such as C++. While JavaScript is largely used for web apps and scripts, of course, Python could arguably be the most popular language outside of the sphere of web development, thus accounting for its second-highest ranking in the study.

    As such, “due to the accretive nature of our methodology, movement within the top-ranked languages is an infrequent occurrence,” Stephens said.  

    “[However], Python overtaking and sustaining its ranking over Java was a big deal. That said, we remain strong believers in the future of Java and the Java ecosystem, and we know there is a vast amount of enterprise Java that isn’t captured in the metrics we use,” Stephens said. “We don’t view Python’s ascendence as a zero-sum gain over the use of Java.”

    For JavaScript, “in spite of all of the competition from up-and-coming languages, all the discussion of fragmentation – and even criticisms of JavaScript the language itself – it remains remarkably popular,” O’Grady said.  

    “Simply put, JavaScript remains – its detractors notwithstanding – a force of nature like no other within the industry, and there are no indications in the data that this is likely to change any time soon,” O’Grady added.

    Meanwhile, in the book Hardcore Programming for Mechanical Engineers, published by No Starch Press, JavaScript trails Python in other rankings, while Python is also more popular than JavaScript for other reasons than those described in the RedMonk study. Python, for example, is cited as the ‘The Most Wanted Language,’ based on a Stack Overflow survey. 

    While Python is not the fastest language, as measured  in benchmarks listed in Hardcore Programming for Mechanical Engineers  — Go consistently outperforms it, for example, in execution times — Python’s popularity remains very high overall, according to the book’s author.

    “These results are not surprising; Python is an extremely versatile and productive language,” author Ángel Sola Orbaiceta wrote. “Writing code in Python is a delight, and its standard library is well-equipped: for just about anything you want to do, Python has something ready to help.” 

     

  • Languages and DevOps: To The Cloud!

    Languages and DevOps: To The Cloud!

    Cloud and DevOps are almost a match made in heaven. Cloud started truly gaining steam in the age of DevOps and Agile, and has adapted – or grown up in it – well, depending on your viewpoint. If not for the combined issues of data gravity and data (im)mobility, we might have gone even farther than we did into the cloudy world.

    While the breadth of possible cloud apps means a wide variety of languages is in use, Node rules this roost. Every conceivable language is used in cloud development – because, in the end, they’re just servers – but Node is the go-to language of today. The broad use and appeal of JavaScript make it an obvious choice for enabling full-stack development, and the pool of developers is larger than any other language today. Other languages are used, but not in the numbers that Node is. Python is the challenger, and a surprising number of PHP sites still exist, but forward-looking development aims at Node or Python. Considering the distance from the hardware, there is less call for C in cloud than there is in other areas of development, but it isn’t gone, since interfacing to the OS is also often done in C.

    Targeting cloud is not so much about language as it is DevOps tooling, though. All of the major Git companies have cloud-centric extensions (this is the core of GitOps) that raise the level of “fully automated.” Cloud environments, by their nature, provide APIs for infrastructure, and the Git vendors (and many, many others) have hooked into those APIs to make deployment an integrated part of DevOps at a level of detail that other environments (with the exception of containers) require a lot of work to match.

    The negative to cloud-centric development is lock-in, of course. Creating an entire DevOps toolchain and process that supports vendor X will not work directly with vendor Y. Tools can help with this issue, but the real solution is in our next installment – container development.

    The part of development that arguably benefits the most from cloud-centric development is testing. It is easier to spin up a test environment as-needed and spin it back down when testing is done – no need for a spare set of hardware or a stand-alone VM server; just redirect the DevOps ecosystem and spin it up, then account for data (scrubbing, copying, etc), and you’re off. Codify the steps for data, and you have a re-spinnable environment for test-on-demand.

    The part of cloud that is arguably the weakest is security. Let’s face it, far more of your infrastructure is publicly (or semi-publicly, if running in a VPC) exposed than in a data center. There are far more places to lock down, and a sometimes-bewildering number of options to secure. But the flexibility of pay-as-you-grow makes it an appealing option, and there are tools to help manage all those lockdown points. Just make sure that you’re not the weak point in the shared security model.

    You. Rock.

    Cloud makes a lot of things easier, and Node makes development of any step in the stack easier by using the same underlying language on the server that is used in browsers and in many mobile development platforms. Node “feels” more right for web development, at least because one connection, one call … even if it makes long-running processes require a bit more work.

    Whatever you choose, pay attention to how deeply invested in the cloud vendor’s proprietary interfaces you are, because, like all technical decisions, one day you or your replacement will have to get around those interfaces. And keep making the software the org needs.

  • Languages and DevOps: Web Development

    Languages and DevOps: Web Development

    Web development has changed a lot since DevOps first hit the scene. The languages used have shifted, where languages are used has shifted, the likely back-end hosting environment has changed – but DevOps has folded these issues in and just kept plugging along.

    We’re going to approach this from two angles – what languages you’re likely to use, and what DevOps offers. This is not a “Best Billion Web Development Languages for 2021!” article; there are plenty of those out there, and you are more than welcome to read them. This is more about using these languages in a DevOps environment, which has become standard for web apps more than any other type of development.

    We’ll start by observing that your web app is, more than likely, going to have at least three parts – HTML, CSS and JavaScript. This is not news to those of you doing it daily, but we’re just setting the bar, here. Other languages may be used to generate or populate any/all of the above, but, in the end, these three languages get sent to the browser, so will be part of the equation.

    Backends add an incredible amount of complexity to this equation. I’ve done Ruby backends that did most of their work in C++ and Java; I’ve done pure Java backends that spit out the required three components; I’ve done Node backends that had very little actual HTML/JavaScript source code, but generated a ton of both – it’s all there. And the hosting environments for backends have changed. When DevOps started, most hosts were virtual machines (VMs) or hardware, whereas now we’re mostly running cloud instances or containers. Those backends have to be configured and managed, too, along with all of the dependencies that your application requires. When you think about it, we really have created quite a messy environment.

    But DevOps has risen to this challenge.

    I’ve long been an Atlassian fan, and find them to be a great tool for managing the agile side of DevOps. Add in Ansible, for the operations side, and you have a good thing going. I recently looked into GitLab, and GitOps – through GitLab – offers a compelling alternative to Atlassian’s offerings; more so since Atlassian made some rather unpopular changes right about the time I was wrapping up my look at GitLab.

    The key is that Git holds all the code. By adding in the scripts to spin up those increasingly complex backends and secure the entire infrastructure, you get an “App in a (virtual) box.” No matter what DevOps toolchain you use, tying this in is simple, because it already works well with Git and associated tools.

    Developers tend to care more about the development side of the equation (imagine that!), so let’s talk a bit about what’s going on out there.

    PHP is hanging on solidly, with a bulk of applications and (perhaps more importantly) libraries to keep it in the running. PHP is one of the original “generate an HTML page” languages, and is slowly being displaced. It isn’t a bad choice for your web projects, but it isn’t the only – or at this point, the most popular – choice.

    Java is still somewhat popular, and while it offers good support for web development, it is … heavy? Is that the word? It’s something for this type of development, and has ceded ground to other languages when it comes to pure-play web development. The skills are transferrable to other targets, so it is a good broad-use language. Like the other serious players in this space, there are web-centric libraries and frameworks that make Java hum. I’m a fan of Spring, but the options are pretty broad.

    JavaScript wins this race today. It is used on both client and server, there are a ton of developers and DevOps people available who can be productive in JavaScript from day one, and it is increasingly used in other contexts – meaning skills could transfer to other projects. Like any language, there are trade-offs, but the portability aspect makes the trade-offs things that many are willing to work to overcome. Libraries and frameworks abound to make JS development faster and more dynamic. Personally, I like Node for server-side development, and Angular for clients that need more than straight HTML/CSS offers (probably because it’s the one I’ve used the most).

    Python is definitely a contender in this space, as it is in most others today. With Django (or whatever your framework of choice), it functions well for web development, and its popularity has given it a host of support libraries to get things done. Developers are easy to find, and skills are broadly applicable, as Python is used in most areas of Dev and Ops at this point.

    Windows aficionados are still using C#, and it does have good hooks into Microsoft DevOps tools, so any Microsoft shop should include it in evaluations. I’ve done C# on Azure for web apps, and for me it was … different, but not broken. In a Microsoft shop, C# will be familiar, and at this point, most developers are familiar with web clients, so merging the two is only a tiny bit of a learning curve, but not a major one.

    Ruby does seem to have ceded its spot to Python. It is unlikely you’ll find a steady flow of ruby developers to fill those positions, but it is a highly intuitive language that you can train Java, and even Python developers in, if necessary. Ruby is well-supported for web development; indeed, it feels more natural using Ruby for web work than command line tools (at least to me, YMMV). There are web frameworks to make Ruby more intuitive in web development, and jRuby offers deep integration with Java to make use of already existing Java classes.

    All in all, JavaScript should be the strong contender for a new project today, but any of these tools will serve the need. They are all well-supported, and DevOps tools start with integration to most of these languages. Do what’s best for your environment, and keep rocking it.

  • Download Rocket Open Source Languages for z/OS Today!

    Download Rocket Open Source Languages for z/OS Today!

    Empower your developers to use their preferred open source languages. We offer many open source languages and tools—including Git, R and Python—that allow any developer to harness the power of the mainframe without spending months learning new skills.

    Git
    Git is a version control system (VCS) for tracking changes in computer files and coordinating work on those files among multiple people. It is primarily used for software development, but it can be used to keep track of changes in any files. The z/OS port of git supports automatic tagging and conversion of text files between ISO8859-1 (ASCII) and IBM-1047 (EBCDIC) character encodings.

    Bash
    Bash is an sh-compatible shell that gives users a command-line interpreter through a traditional interface via text window and a script execution capability. It is the default shell on Linux and Mac OS X.

    Bison
    Bison is a programming utility for creating parsers. It’s commonly used in both build automation and build automation generation, and converts annotated context-free grammar into a C, C++ or Java parser. Bison is used by PHP, Bash, Ruby and many other languages and tools.

    bzip2
    bzip2 is a data compressor for single files (it is not a file archiver). It typically compresses files to within 10% to 15% of the best-available techniques of statistical compressors at rates approximately twice as fast at compression and six times faster at decompression. This version of bzip2 was not written to exploit z Systems architecture; Gzip may work best for these needs.

    cURL
    cURL is an open source tool that can transfer data to and from servers using one of the supported protocols (HTTP, HTTPS, FTP, FTPS, TFTP, DICT, TELNET, LDAP or FILE). This tool can work without user interaction. cURL functionality includes proxy support, user authentication, FTP upload, HTTP post, SSL connections, cookies, file transfer, resume and more.

    Diffutils
    Diffutils is a package of several programs intended to find differences between files. The diff command, for example, shows exact line differences between two files.

    Gzip
    Gzip is a popular data compression/decompression program (our ported tools have been compressed using this utility). This version of Gzip has also been modified to exploit z/OS EDC compression hardware, if present on your system.

    libssh2
    libssh2 is a software library that allows developers to use the SSH-2 network protocol in an easy-to-use, self-contained package. This package only contains LIBSSH2 libraries intended for use by other programs or utilities.

    m4
    M4 is a general-purpose macro processor. Most users require M4 simply as a dependency of Autoconf or Bison, although the language is used in other contexts such as text template re-use, text editing and text-processing applications.

    Make
    Make controls the generation of program executables and other non-source files from the program’s source files. Make allows users to build, install and update packages without knowing the process details.

    Mktemp
    The mktemp utility takes a given filename template and overwrites a portion of it to create a unique filename. Mktemp also manages the creation of temporary files and directories that allow the user to avoid cleaning up files that are not needed permanently.

    OpenSSL
    OpenSSL is a software library used in applications that need to secure communications against eavesdropping or need to ascertain the identity of the party at the other end.

    Pkg-Config
    pkg-Config is a programming tool that assists with compiling applications and libraries. It helps you insert the correct compiler options on the command line without the need for hard-coding values on where to find glib (or other libraries).

    Sed
    sed (stream editor) is a utility for parsing and transforming text. It is typically used for extracting part of a file using pattern matching, or substituting multiple occurrences of a string within a file.

    sudo
    sudo is a command-line utility that allows admins to delegate authority, giving certain users the ability to run commands as a super-user or as another user, while providing an audit trail of the commands and their arguments.

    Unzip
    UnZip is an extraction utility for archives compressed in .zip format. Unzip is also compatible with PKZIP and PKUNZIP utilities for MS-DOS as well as Info-ZIP’s and supports bzip2 compression methods, as well.

    Vim
    Vim is a highly configurable text editor built to make creating and changing any kind of text very efficient.

    Zip
    Zip is a compression and file packaging/archive utility. Zip puts one or more compressed files into a single ZIP archive, along with information about the files.

    zlib
    zlib is a general-purpose, lossless data compression library providing in-memory compression and decompression functions, including integrity checks of the uncompressed data.

    Download Now
    Read more about Rocket Support for Open Source Tools
    Join the FREE Rocket Open Source Tools Forum

  • Best of 2020: Cybersecurity: What Programming Language Is Better for Your Career?

    Best of 2020: Cybersecurity: What Programming Language Is Better for Your Career?

    As we close out 2020, we at devopsy.kinsta.cloud wanted to highlight the five most popular articles of the year. Following is the second in our series of the Best of 2020.

    As a novice developer, you may be thinking about learning a programming language and starting a fantastic career.

    In fact, this question on Reddit inspired the whole article:

     

    Source: Reddit.

    The thing is, programming languages represent certain philosophies of its authors and tailored to certain types of problems, i.e., there is no such thing as “the best programming language.”

    Source: Reddit.

    Every Tool Has Its Time and Place

    In this article, I describe major programming languages according to its popularity, usage, demand and ease of learning. 

    There is market demand and a potential salary range for each language. These are linked to specific personal goals and prior programming experience.

    What Questions Should You Ask Yourself Before Diving in?

    • What kind of projects do you want to work on? If career flexibility is a priority, then learning Python or C++ will allow you to work with different types of programming. If your passion is web development, learning JavaScript or PHP is a smart choice.
    • How much experience do you have? You won’t want to switch to an advanced programming language, such as Rust, if you don’t have previous programming experience. If you’re new to a language, you’ll want to start at a higher level and be intuitive.
    • What are your career goals? Do you want to become a freelancer, working for an existing company or work with a startup? Are you trying to be better in your current role?

     

     

    If you plan to get a job in a large technology company, learn the programming languages they use, e.g., NASA, Google and Facebook use Python.

    Many programming languages have similar syntax and qualities—so if you learn one of them, it will be easier for others. The more languages you know, the more flexibility you have in your career and development projects.

    In the list below, we will look at the best and most popular programming languages for many of the most common uses, including web development, mobile development, game development and more.

    Source: Reddit.

    Top Five Programming Languages to Start Your Career

    Java

    It is probably the best programming language if you are looking for a common language that will be useful in various situations. As for choosing a programming language to learn, there are many resources for people who are thinking about learning Java. Java was released in 1995, which makes it one of the oldest programming languages. It is used on a wide range of platforms and operating systems, including Microsoft Windows, macOS, Linux and Solaris. 

    That means there will always be jobs for Java developers, making it (perhaps) the best programming language to learn.

    Research shows that Java developers can expect to earn between $80,000 and $130,000 per year. If you are thinking about learning your first programming language, think about taking an online course, for example, CodeGym. This course, which contains 40 levels of game-play classes, will teach you all the basics you need to know to start programming in Java. It’s easy to follow—even if you don’t have programming experience—and it is worth checking out.

    It is also best used for back-end web development, mobile development and desktop applications.

    JavaScript

    This programming language works on several platforms. Therefore, it is ideal for websites that will be accessed through various devices and browsers. It is suitable for anyone who designs websites with effects, interactive features, animations and pop-ups—standard features on virtually any brand website these days. If you want to work in a creative environment and add more experience to the user, this is a coding language to learn.

    JavaScript is the number one language on the web. The growth of frameworks such as jQuery, Angular and React JS has made JavaScript even more popular.

    If you just can’t stay away from the internet, it’s better to learn JavaScript sooner than later. I consider this JavaScript Masterclass an excellent place to start. For cheaper alternatives see this list of free JavaScript courses.

    It is also best used for front-end and back-end web development

    Learning PHP

    PHP—another old language, first appeared on the stage of programming around the same time as Java in 1995. It is a general-purpose language widely used for web development from the early days of the web.

    Unlike other languages, which can be quite tricky to use with HTML, PHP can be built directly into the HTML code block. Start and finish instructions are used to enter and exit PHP, making it very easy to use. Although PHP is not as popular as Python or Java, it can be a suitable language to learn because of its simplicity. It is convenient for beginners and you can write your first scripts just a few hours after you start your PHP course.

    Again, the popularity and wide use of PHP means that work opportunities are relatively easy to find. An average PHP developer can expect to earn around $80,000 per year. However, there is potential to make much more as a freelancer.

    Take an advanced PHP course, which will teach you everything you need to know to find your first job as a programmer. It doesn’t matter if you’re studying your first language, or if you’re an experienced developer looking for the best programming language to add to your resume—PHP is a great choice!

    It is best used for back-end web development.

    Python

    Source: Reddit.

    Python is a useful step toward more advanced forms of programming languages. Python provides a high degree of website readability and is used by companies such as Reddit, Google and even NASA.

    It is seen as entry-level programming that does not require too much prior knowledge. It may be ideal for relatively new professionals to help small businesses that want to expand their presence on the internet without having to resort to advanced professionals. Python is a relatively simple programming language that is very easy to pick up if you already have programming experience. That makes it one of the best to learn if you are already working as a developer and want to increase your resume quickly.

    The code on Python is designed to be readable. It uses a lot of white spaces, which makes it a pretty easy language to learn while you’re studying it.

    One of the most useful Python’s features is its compatibility with data analysis systems and scientific applications. It is a popular language in scientific communities and is often used by researchers to write their programs.

    An average Python developer can expect to earn about $100,000 per year. However, there is little room for wage growth.

    If you think Python is the best programming language to further your career, consider enrolling in a BitDegree course. The Python Basics Course includes everything you need to know to start writing programs on Python and contains less than four hours of lecture material.

    It is best used for back-end web development, desktop applications, and data analysis.

    C#

    C# is another object-oriented, general-purpose language based on C. It is considered a suitable programming language for building applications native to Microsoft platforms. Microsoft initially developed it as part of its .NET framework for building Windows applications. C# uses a syntax similar to other languages such as C++. Therefore, it is easy to pick it up if you come from a different C family language. 

    C# is not only a suitable language for developing Microsoft applications, but also a language used by mobile device developers to build cross-platform applications on the Xamarin platform. Besides, anyone interested in VR development should think about learning C# as it is the recommended language for building 3D and 2D video games using the popular Unity game engine, which produces one-third of the best games on the market.

    If mobile application development or virtual reality is your business, consider learning C#. Many mobile device developers use C# to create cross-platform applications on the Xamarin platform. Although it is not the most convenient programming language for beginners. 

    If you are interested in any of the above areas, please see the section “Learning the code when making games – Udemy’s Complete Unity Developer in C#.” I see that more than 200,000 students have enrolled in this course, which indicates its popularity.

    It is best used for mobile and game development.

    What Are the Best Programming Languages to Learn?

     

    Source: Reddit.

    As was mentioned at the beginning, there is no best programming language to learn. The best language for you will depend on your experience, your current knowledge and reasons to learn a new language. 

    While there are many options, you should be able to narrow down your language choice by what you want to learn from it. 

    Remember to consider the following:

    • Programming experience, because some languages, such as Python and Java, are more suitable for beginners who have never programmed before.
    • What you want to do with the language. Different languages are used for different things.
    • How much time do you have? Some languages are much more demanding than others.

    Make your choice based on your interests and the type of software development you want to get into. Here is a brief summary:

    • External web development: JavaScript.
    • Internal web development: JavaScript, Java, Python, PHP.
    • Mobile development: Java, C#.
    • Game development: C#.
    • Desktop applications: Java and Python.

    To Sum Up

    Programming and developer communities are evolving faster than ever.

    Various new programming languages are emerging that are suitable for different categories of developers (beginners and experts) as well as for other applications (web applications, mobile applications, game development, distributed systems, etc.).

    This list simply scratches the surface of existing programming languages. Still, the simple fact is that with the right coding skills, you will be perfectly prepared to offer valuable technical support and become an asset to any organization.

    — Dmitrii Borodin

  • How to Transition to Become a DevOps Engineer

    How to Transition to Become a DevOps Engineer

    You’ve either heard the buzzword or you’ve seen the extensive list of rewarding aspects that come with being a DevOps engineer. Whatever the reason you’re here, this guide should help with taking the right steps toward becoming a DevOps engineer, whether this is your first job after graduating or an opportunity to reskill leveraging your prior industry experience.

    Immerse Yourself

    Learn the fundamentals, practices and methodologies. Understand the why behind DevOps before jumping into the tools. I believe the key goal of any DevOps engineer is to increase speed and maintain or improve quality across the entire software development life cycle, in order to provide maximum business value. Read articles, watch some YouTube videos and go to one of your local Meetup groups or conferences–it’s useful to become a part of the welcoming DevOps community where you’ll learn from the mistakes and successes of those that have been here before you.

    Your Background

    There are likely two key times where you’ll be transitioning into the role of DevOps engineer; either reskilling during your career or as your first job after graduating. You may have prior experience in technology, such as working as a software developer, systems engineer, systems administrator, network operations engineer or database administrator, all of which will bring broad insights and useful experience for your future role as a DevOps engineer. If you’re starting your career, maybe you’ve finished your degree in computer science or any other STEM field which will give you some of the basic stepping stones you’ll need in this transition.

    I think it’s important to breakdown the broad spectrum of what DevOps engineer roles entail. Most enterprise companies today will use DevOps engineers in three different positions.

    • DevOps Engineers, with a Dev Bias: Work in a software development role, building software applications. The key point is they leverage CI/CD, shared repositories, cloud and containers as part of their everyday work, but they are not necessarily responsible for building or implementing tooling. They will understand infrastructure and in a mature environment, will be able to push their own code into production.
    • DevOps Engineers, with an Ops Bias: Could be compared to systems engineers or systems administrators. They understand software development but do not spend the core parts of their day building software applications. Instead, they are more likely to be supporting software development teams to automate manual processes and increase efficiencies across the human and technology systems. This could mean breaking down legacy code and using less cumbersome automation scripts to run the same commands or it could mean installing, configuring or maintaining infrastructure and tooling. They ensure the right tools are installed and available for any teams that need them. They enable teams with learning how to leverage CI/CD and other DevOps practices.
    • SREs (Site Reliability Engineers): Think of site reliability engineering as having software engineers solving operations and infrastructure problems. SREs focus on creating scalable, highly available and reliable software systems.

    In the ideal world, DevOps engineers will understand all the above, which is the norm at some mature technology companies. However, if you knock on the door of top tier banks or many Fortune 500 companies you’ll realize oftentimes these roles do usually have biases towards dev or ops.

    Operating Systems

    Whichever background you’re coming from, you should start with the fundamental technologies you’ll need to use and understand as a DevOps engineer. Linux is most likely the operating system you’ll be using daily, although some of you might be using Windows. This is where everything runs, and fundamental knowledge is important. You can install Linux at home where you’ll be able to break as much as you want and continue learning along the way.

    Scripting

    Next up you’ll need to pick a scripting language. There are many to choose from, such as Python, Go, Java, Bash, PowerShell, Ruby and C/C++. I suggest starting with Python, it’s one of the most popular for a reason, it’s easy to learn and interpret. Python follows the fundamentals of object-oriented programming and can be used for web development, software development, creating desktop GUI apps and even business applications.

    Cloud

    After Linux and Python, my next pick would be cloud, where you could choose from Amazon Web Services, Azure or Google Cloud Platform. I’d start with AWS, as they have an extensive collection of free learning tools available to  take you down any track from learning about AWS as a developer to operations and even the business facing components. In fact, you might even be overwhelmed by how much is on offer when you first get setup with AWS. Maybe start with EC2, S3 and VPC and see where you want to go from there.

    Programming languages

    For those of you with a passion for software development. You should keep on improving your programming skills. Some good languages commonly used in this role include Python, Go, Java, Bash, PowerShell, Ruby and C/C++. You should also become familiar with tools such as Jenkins and Git/GitHub which you’ll be using frequently as part of the CI/CD process. Infrastructure is no longer left to the operations guys so you’ll need to have some exposure to a cloud platform such as AWS, Azure or GCP.

    Containers

    Finally, start learning about containerizing code using tools such as Docker and orchestration platforms such as Kubernetes. All the above have extensive online learning resources for free and most cities will have local Meetup groups where you can turn up and learn from experienced people in a friendly environment.

    For those of you with less experience in development, you can still get involved using your passion for automation, increasing efficiency, collaborating with others and a never-ending desire to improve on your own work. I would still suggest learning the tooling outlined above, but with less emphasis on the coding/scripting languages. It will be useful to learn about Infrastructure as a Service, Platform as a Service, cloud platforms and Linux. You will likely be setting up the tools and learning how to build systems that are resilient and fault-tolerant while writing your own code.

    Reskilling

    If you’re transitioning into a DevOps role during your career, you should start within your company to explore opportunities. Can you reskill by working with an existing team? There might be an option for you to shadow other team members, ask for advice and reskill without even leaving your current job. This might not always be possible and some of you will need to move into another company.

    If you can learn some of the practices, tools and technologies listed above, you’ll be in a good position to demonstrate relevant knowledge during interviews. The key is to be honest and to not set yourself up for failure. Most hiring managers understand you don’t know all the answers but if you can show what you’ve been learning and explain you’re open to learning more, you should be in with a good chance.

    Starting Your Career

    You can apply to direct open opportunities at companies who are hiring junior DevOps engineers. You will often find these companies say they’re looking for more experience and you should apply back in future when you’ve gained some commercial experience. It’s the typical, frustrating scenario of “we want more experience” but nobody is willing to give you the first chance.

    It’s not all gloomy though, there are a few companies focused on training and upskilling graduates directly out of the university. MThree, where I currently work, delivers exactly that. We hire fresh graduates and train them for eight weeks in our Alumni Academy. Training covers everything from theory through to hands-on projects with Python, Jenkins, Git, Ansible, Docker, Kubernetes and AWS. By the end of the training you’ll have some solid exposure to the entire software development life cycle and a good understanding of how this applies in a Fortune 500 environment. The best part is once qualified, our teams then leverage their extensive list of clients to provide job opportunities for junior DevOps engineers. MThree pays these associates on a full-time salary with benefits for the first 18-24 months before they join the client as direct employees at the end of the agreement. This is a great way to bridge the gap from university into your technology career.

    In summary, there are many ways to transition to become a DevOps engineer. This is a very rewarding career route which will likely keep you engaged and challenged as well as increasing your earning potential.

    — Conor Delanbanque

  • Python’s Popularity Continues: Examining the Top Use Cases

    Python’s Popularity Continues: Examining the Top Use Cases

    Python continues to be one of the most popular coding languages in use. In fact, the TIOBE index of programming language popularity named it the 2018 Language of the Year. Its usage and adoption continue to grow and proliferate into additional use cases.

    Python’s popularity and growth are in part because it’s flexible and easy to use. Python has grown from a scripting solution for sysadmins to web development for programmers to the driving force behind machine learning. We’ve observed this growth since 1999, when we began to build engineering Python distributions. As we’ve seen the use cases grow, we’ve examined the top use cases by customers ActiveState has observed.

    Let’s look at the three most popular Python use cases within the traditional tech space: infotech, software and hardware.

    Infotech: IT modernization

    The IT team of a state legislature is challenged to be able to remotely manage thousands of user desktops. Its 147 representatives, as well as its hundreds of supporting personnel, work on-premises and/or remotely. One of the key tools that empowered the team was Windows Powershell. Unfortunately, Powershell is unsupported and no longer works under newer Microsoft operating systems.

    Rewriting any application that’s a cost center is always difficult to justify. As a result, rewrites are rarely budgeted, planned and resourced appropriately. But the alternative was much costlier in terms of capital and resources: dispatch IT personnel to physically install, update and manage each user’s desktop, on an on-call basis.

    It’s famously easy to get started and develop with Python. While there was no way around a rewrite of the desktop management scripts, the IT team could at least minimize the time and resources required. Python allowed Powershell script rewrites to be done incrementally in IT’s spare time. This translated into a significant lowering of costs, and reduction in the risk of a “big bang” rip and replace project.

    Software: Adding Extensibility to Legacy Applications

    A U.S.-based public company has a 30-plus-year history of providing a suite of electronic design automation (EDA) tools to their more than 5,000 customers worldwide. Its suite of tools historically was built in C++ and is packaged for deployment on-premises.

    Because each customer has their own instance, it’s natural for the customer to want to customize the suite of tools to their needs. The U.S. public company used Python to wrap some of its C++ APIs to expose key functionality, making their software solutions more extensible by customers. Ensuring Python was deployed properly at customer sites required including Python within their existing installer, rather than relying on their customers to install Python correctly.

    The company used an OEM distribution Python that added a standard version of Python within their application and deployed it, so all teams can customize and leverage the EDA tools as required. Plus, by deploying a standardized Python version across all customer sites and developer desktops, the company can decrease support costs and speed time to market by eliminating the need for legal department reviews. Further, using a third-party-standardized Python version eliminates the opportunity cost of managing one’s own Python build and can facilitate the discovery of issues, bugs and performance issues.

    Hardware: Automating Network Administration

    A Silicon Valley-based American technology leader develops, manufactures and sells networking hardware. A key enterprise demographic for the company is network administrators, who often are confronted with managing the vendor’s multiple devices across extended corporate networks.

    The challenge: Network admins aren’t typically developers. Yet, they want to improve their efficiency by being able to programmatically make configuration changes to multiple network devices at once. While sample scripts are easy for any network admin to use and modify, the vendor did not want to be held responsible for creating all the scripts its user base might require.

    Python was the solution because it is simple enough for any technical person to learn and start using effectively. The company chose a version of Python that allows their customers to quickly create sample Python scripts to cover the majority of typical network admin use cases.

    This choice also allows network admins to create Python libraries they can leverage to create their own custom scripts to manipulate the configuration, operational state or event data from network devices. Most importantly, the cost of administering enterprise networks is significantly lowered and network admins are dramatically more efficient with programmatic access to physical networking devices and virtual network resources.

    Looking Outside the Tech Space

    Other examples that round out the top 10 use cases for Python include:

    • Consulting services: Bespoke web development.
    • Insurance: Creating business insights with machine learning.
    • Finance: Data mining to identify cross-sell opportunities.
    • Retail banking: Flexible data transformation and manipulation.
    • Aerospace: Meeting software system deadlines.
    • Business services: API access to financial information.
    • Health Care: Predicting disease prognosis.

    Ongoing Innovation

    Python’s usage continues to grow due to its simplicity and flexibility. Developers clearly want to use it for a variety of reasons that surpass its creator’s original intent. To support this usage, organizations need to ensure their developers can do so securely, by overcoming open source vulnerabilities while still iterating quickly. It seems that use cases for Python are limited only to the imaginations of its growing, enthusiastic user base.

    — Bart Copeland