devopsy.kinsta.cloud

Tag: programming

  • Logging: Turning Good DevOps Teams into Great Ones

    Logging: Turning Good DevOps Teams into Great Ones

    The competition is on for DevOps teams that are expected to rev up production on a multitude of projects, with teams and companies aiming to stay atop the global software product marketplace. The complexity of code creation and the pace of deployment has picked up in recent years, and DevOps managers are starting to face serious challenges of scale and efficiency.

    Constant code generation is the first obstacle. Imagine a team producing millions of lines of code, working for weeks and hoping for a smooth release. But testing time arrives, and there is a total data meltdown.

    Wasting valuable programming hours is not an option, but what if managers had the tool to turn back the time to a version before the mistake happened? Managers or developers may view logging as an incredibly boring activity, but it is vital. It serves like a black box of what went wrong—but also a way to roll back the bad code, and return to a more manageable situation.

    Logging and tracking habits ensure that a DevOps team will not see their code fail in production, and cause expensive breakdowns in service. Logging becomes more than a wishful addition, but a pivotal tool that may save a project.

    Data is proliferating, code is constantly being written to offer innovative products or support existing ones. There is a massive amount of data projected to be generated in 2025, only a few short years away, if the global IT production sector keeps increasing its activity. This amount of data to be kept and logged would be roughly 10 times higher compared to the data generated in 2016. This issue has plagued Silicon Valley, but also worldwide tech centers: how to keep track of what is going on. How do companies such as Instacart, Lime and OpenAI track their changes and ensure viability and awareness of errors?

    There is the new role for DevOps managers: ensure fast, modern and stringent log management. Dedication to logging means generating tight order out of the chaos of code creation. The right tool will be economical, intuitive and fast, ensuring the possibility for control in what could become a runaway data meltdown.

    Logging is one of the pillars in the modern DevOps department, and while now it is important, it will become indispensable, along with metrics and analytics.

    DevOps are already aware of the possibilities of logging, to keep track of multiple avenues in product creation, from databases to server side events, and even the effects and behavior of users.

    Stringent log management means making use of a valuable resource of knowledge and decision making, but also operating with a complex system of data. DevOps managers will need the tools to span the demands of stringent log management, for a multi-step process involving log generation, transmission, analytics, storage, archives and disposal.

    The right logging system can streamline those steps. Inexpensive logging tools and systems can unify log management across teams and simplify the process of logging. More services are appearing each day, either cloud-based or self-hosted, and with varying levels of security. With increasing complexity and the drive to create ahead of the competition, it would be the task of DevOps managers to make the team aware of the tools, and to provide tools intuitive and fast enough for the good habit of logging and log management.

    — Chris Nguyen

  • DevOps Kids Holiday Gift Guide: Giving the Gift of Code

    DevOps Kids Holiday Gift Guide: Giving the Gift of Code

    Any DevOps professional worth their salt inherently understands how inextricably tied the future of work is with coding, scripts and automation. It’s already a development-oriented world out there and is increasingly growing so. As a result, today’s kids need to at least understand the fundamentals of programming if they want to succeed later on in life—even if they have no interest in becoming full-fledged developers themselves. This knowledge is what educational professionals call “computational thinking.”

    Learning this mode of thinking doesn’t have to be a drudge, though! Fortunately, there are tons of awesome STEM toys and games out there to get kids into the coding mindset from a very early age—all while having fun in the process. We’ve gone through the trouble of sifting through the offerings to give the DevOps community a good head start on their holiday gift giving, no matter the age of kids they’re hoping to bring into the fold.

    Preschool

    Code-a-Pillar

    Price: $47

    What’s not to love about a programmable caterpillar? Very young children pick up planning and sequencing skills by experimenting with the way the Code-a-Pillar moves. Each segment of the toy controls its movements such that different segment sequences create a route for it to move.

    Cubetto

    Price: $224

    Inspired by the Montessori emphasis on the accessible simplicity of wooden toys, Cubetto gives little ones the chance to physically manipulate a programming language via a wooden robot. Putting wooden blocks on the Cubetto tells it where to go.

    Robot Turtles

    Price: $20

    Built from a massively popular Kickstarter campaign, Robot Turtles distills the basics of coding into a fun board game tailored for preschoolers on up through grade school kids. Kids learn sequencing and even subroutines by moving the robot turtles around on the board. It’s what the creators call ‘stealth learning.’

    Grade School

    Let’s Go Code

    Price: $27

    Believe it or not, the creators of Let’s Go Code have managed to figure out a way to teach programming principles in a kinetic activity that doesn’t even require a computer. This is a game that has kids use coding precepts to build mazes that they’ve got to hop, skip and jump through—perfect for bubbly young grade schoolers.

     

    Botley

    Price: $52

    Much like the Code-a-Pillar does for younger kids, Botley teaches screen-free coding by having kids create more advanced routing programming for a little robot. This adds more complicated challenges such as creating obstacle courses, looping commands and more to require a higher level of critical thinking for the grade school set.

     

    Kano Computer Kit

    Price: $100

    Get kids well and truly pumped to code with the Kano Computer Kit, a complete box kit that comes with everything they need—including detailed instructions—to build their very own computer and then code on it. The software platform comes built with over 100 coding challenges and teaching tools for kids to create their own games, websites, art and music.

    Middle and High School

    Circuit Playground

    Price: $34

    This handy starter kit comes built in with multicolored LEDs, environmental sensors and more to get kids into experimental embedded programming. The platform runs MakeCode, Circuit Python, Adruino and Code.org CS Discoveries, giving tons of runway to create unique projects. The Playground’s creator has a very extensive online knowledge base and maker community to give teens some ideas to get started.

     

    Space Chem

    Price: $2

    Pick up this design-based puzzle game on Steam for cheap to get older kids into programming in a fun and engrossing format. The game has players acting as a “reactor engineer” in a sci-fi space colony building out chemical synthesizers to transform raw materials into chemical products. As they solve puzzles they start to learn about basics like sequencing, loops, branching and subroutines.

     

    MakeBlock Ultimate 2.0

    Price: $350

    One of the most versatile robot kits for teens on the market, this one comes with more than 160 parts that can be combined into more than 10+ forms that are then programmable via a number of methods. Beginners can use drag-and-drop function blocks, and as they learn more kids can program it using Python, Arduin IDE and NodeJS.

    — Ericka Chickowski

  • Dependency Based Build Promotes the Freedom to Program

    Dependency Based Build Promotes the Freedom to Program

    Whenever I want to be amazed, all I need to do is reflect on the fact that the continuing development of the Linux operating system is done essentially by a community of volunteers. That’s right! One of the most popular and important operating systems is updated and maintained through donated labor. Any programmer anywhere in the world can make a contribution to improve the Linux kernel.

    That such a herculean undertaking is done though volunteer labor is mind-boggling. What’s more amazing is that the software created has an extraordinarily high level of quality. Let’s face it, working on the Linux kernel is not something a kid in high school with a year’s worth of experience programming in C can do. But, any kid in high school can make a contribution to the Linux code base, provided the code passes muster. That it happens is almost magical, in a way. But it does, every day.

    What enables such freedom? To my thinking, it’s the concept of the the pull request.

    The Powerful Elegance of the Pull Request

    The pull request is a simple yet important part of the open source development process. A developer creates a feature branch off the Master branch of the Linux repository, then adds to or modifies the code in that feature branch. Of course, the developer writes tests that verify the new code works. Once the code is complete, the developer sends a pull request to the project, which is typically hosted on GitHub or another popular Git repository platform. The project maintainers, a group of people who have expert knowledge of the code base, review the pull request using tools that are baked into the Git repository platform. Each maintainer inspects the code and, if the code passes inspection, the reviewer votes to approve. If the code has shortcomings, the reviewer makes suggestions for improvement directly in the code using the Pull Request Commenting features, which are available in practically all the Git Repository Platforms including GitHub, GitLab and Bitbucket.

    It’s a simple yet powerful process and one that has changed the way enterprise-worthy software gets created. Any developer can implement an idea any way they want, as long as the implementation is compatible with the code base. It’s up to the developer to figure out how to do what they desire; nobody is dictating anything. The process is straightforward: Figure out how to make your contribution to the code. Make a feature branch. Do your work. Do a pull request. If your contribution is useful and the coded well, you’re in. If not, we’ll try to help you make it better.

    Bringing Git to Mainframe Development Using DBB

    The pull request is a compelling approach to making software—so much so that IBM has made it a central part of software development on the mainframe. And, its product, Dependency Based Build (DBB), streamlines the mainframe pull request process by reducing the work reviewers need to do in the code review process.  [su_pullquote align=”right”]A Dependency Based Build trial is available in the IBM Z Trial Program at zero cost, and with no installation required. The trial environment includes hands-on tutorials.[/su_pullquote]

    Git version control is supported by practically all the modern IDEs. For example, developers can configure Visual Studio Code, JetBrains products and Eclipse to work with remote Git repositories automatically. Once integrated, Git operates behind the scenes, allowing developers to work under version control without having to issue Git commands directly. IBM’s mainframe integrated development environment, IDz EE, provides Git integration as well. This is a big deal, as Git is now part of the mainframe ecosystem. The developer accustomed to using Git version control when working on a standalone x86 Java app now can move over to developing for a mainframe without having to learn a new source control management (SCM) system. But what’s even more impressive that Git is used as the SCM for more traditional mainframe artifacts; for example, COBOL source code.

    Also, Git integration goes beyond developers working on source code; Git is used throughout the mainframe build process—which, by the way, can be controlled by Jenkins. And, Git is a foundational technology used by IBM DBB, a dependency control agent that works with Git to make sure that all files—source and dependencies—in the mainframe build process are current. Again, this is a big deal: Having all the moving parts in the mainframe deployment process, from programming to build to release, use Git as the common code repository allows z/OS mainframe components to be part of a platform-agnostic deployment process. Use of DBB overcomes a significant hurdle between the mainframe and distributed world.

    So, what does this have to do with the power of pull requests?

    Adding Pull Requests and Code Review to the Mainframe Experience

    The pull request review process is more than just “looking at code.” When you have a project that might have millions of lines of code, such as the Linux kernel, no developer is going to pore over each line of code. They’ll read the documentation, run the unit tests, look at the lines of code that have been added or removed and search for blatant problems and inefficiencies. Now, on a PC, compiling something such as the Linux kernel is straightforward—all the code is in the single repository. On mainframes, however, it’s a bit different: The code is more widely dispersed and dependency management can get tricky. DBB takes care of tracking dependency changes in various Git repositories, so when it comes time to do the pull request, the reviewer doesn’t have to waste time resolving dependency issues to get mainframe code to compile. DBB will take care of that. With regard to the pull request, reviewers can do what they are supposed to do: make sure the code works and the quality is such that it can all be merged back into a master branch.

    This might not seem like much, but anybody who has stayed up until 3 a.m. trying to resolve dependency issues understands the importance of having code that builds all the time, any time. This is the power that DBB brings to the table.

    The Freedom to Program

    Programming is a special vocation. It requires an unusual combination of art, science, creativity and engineering discipline. Also, it’s not a vocation that lends itself to well to prescription. Each programming project is special, requiring new ideas. And new ideas come about when developers are free to use their imagination to think differently. The pull request is one of the best ways to ensure developers have the freedom to program in way that produces useful, high-quality code. DBB extends the freedom to program to the mainframe community.

    History has shown that when a developer is given the freedom to code and a community in which to code, the result is great software. Just ask Linus Torvalds.

    — Bob Reselman

  • Automic Helps DevOps Transformation Sparkle

    Automic Helps DevOps Transformation Sparkle

    Working closely with Automic, an international wholesaler and retailer of jewelery transformed a department of project managers, developers and operations responsible for all of the customer-facing websites into a DevOps organization. As a result, project delivery was completed with 90 percent fewer delays, and first customer-facing releases of projects could be delivered in less than half the time. The usability of its websites increased significantly, resulting in more customer traffic, longer average time spent on the sites and increased revenue.

    Haphazard Development

    Prior to the DevOps implementation, new projects were delivered by “waterfall” project management means. The cyclical resource planning process was based on the project portfolio and business priorities. Project managers then planned project milestones working closely with business stakeholders, business analysts and application developers. Analysts created specifications and developers were assigned to work on packages and tasks to implement them.

    Different web technologies were used with varying levels of dev and ops expertise in each technology. The  Operations team members usually fulfilled requests made during the course of a project as part of their overall daily tasks—for example, to provision a new environment, deploy a package or change the environment configuration.

    This approach had a major disadvantage. Delays in one project impacted the overall resource planning and could have a cascading effect on other projects. Delays in projects could be for multiple reasons, such as waiting for business stakeholder impact, frequently changing requirements, unexpected sick leaves of developers or poor estimates. Other frequent causes included delays in operations tasks such as a deployment or provisioning of a new environment. These delays were caused by unaligned planning as well as a mismatch in priorities between projects and operations. Besides delays, some developers were underutilized, which also was exacerbated because they were specialized in a technology or component.

    DevOps Transformation Solution

    Working closely with the customer, Automic restructured dev and ops by:

    1. Switching the development from a project to a product mode (cross-project development teams based on capabilities rather than assignment of individual developers to projects).
    2. Moving project managers from development micromanagement to focus on major milestones and deliverables to the business.
    3. Enabling some project managers as product owners (project management remained necessary).
    4. Providing developers with agile methodologies through initial training plus ongoing coaching (six to 12 months).
    5. Providing ops with an agile methodology.
    6. Organizing both dev and ops into multiskilled teams focused on individual products rather than technologies.
    7. Aligning ops into delivery teams, initially part-time and later full-time.
    8. Giving delivery teams the end-to-end responsibility for their products, including their operations.
    9. Standardizing the technology stacks within teams (but not across them) over time.
    10. Delivering projects into production (or alpha, beta) in slices (releases) instead of just once to get early feedback and improve.

    Results: Fewer Delays, Better Usability

    By standardizing, this customer has transformed its dev and ops teams, creating an agile, scalable environment that can drive the business forward. The company achieved the following specific results:

    • Project delivery are now completed with 90 percent fewer delays. First customer-facing releases of projects now are usually delivered in less than half time.
    • The usability of websites has increased significantly, resulting in more customer traffic, customers remaining longer on the sites and increased revenue opportunities.

    About the Author/Michael Schmidt

    Courtney-Glymph_avatar_1435225162-96x96Michael Schmidt heads DevOps Practice at Automic, a management and technology advisory service established to help Automic customers to prepare for and transform their organizations toward DevOps. Michael spent his carrier as consultant, entrepreneur and in several product-related leadership positions. He has a passion for building lean IT organizations. Michael holds a joint MBA from New York University, London School of Economics and HEC Paris and a Master of Computing Science.

  • Programming: from too hard to too easy

    Programming: from too hard to too easy

    I can still remember how happy I was the first time my friends and I managed to program a Pong alike game on our Texas Instrument calculators. It took us weeks before figuring out the algorithm and months before being able to render something decent, almost playable, with zeros and ones on the screen.

    At that time, we had to understand low level languages that young folks can not even name today. We had no debug tool and the only way to understand why our application crashed was to try to reproduce the case… on paper.

    Later on, I studied in the only university in France that was teaching both Cobol and Java. Their philosophy was that however important Java was becoming (it was the beginning of the two thousands), it was still important to understand the main concepts of IT. They also forced their students to learn the language theory but that was just for the fun. In my last year there, only 6 years after programming my first pong game, we had to produce an OpenGL 3D first person shooter game. It was nothing that we would ever use later on in our lives, but understanding the key concepts of 3D and being able to use complex math was more important than filling up a CV. The whole project took us a couple of weeks.

    With today’s technologies, you can build up a playable level of a single game with the latest lighting and texturing technologies in just a couple of hours, thanks to the power, the diversity and the flexibility of the available tools.

    The same concept applies to pretty much everything that requires coding. We went from writing eighty characters per line with no objects, to defining a variable name and a method call represented by a box.

    Nowadays, most people learn IT the “fast way” that is, with tools that enable auto-completion, give coding advices and have integrated GUI builders based on drags and drops. Creating an application has never been that easy. A couple of clicks here and there, a Google search or two and voila!

    But is time sparing worth sacrificing knowledge? What is the big picture on a long term perspective? What will happen to hardcore experts?

    If programming is that easy, debugging becomes harder. With all that generated code and programming conventions not always being respected, if someone else than the original developer has to read and fix the code, things can become quite hard and costly. How many of us had to fix a code which contained variable names like txtBox1, txtBox2…, or even worse, ex girlfriends’ names? How many hours are spent yearly debugging simple mathematics operations because precedence rules are not respected? Those are just the easy ones, the most common and harder coding mistakes include, but are not limited to: global variables accessed and modified randomly, methods of tens of lines, exceptions being caught but discarded…

    There are tons of resources out there for developers to learn from and many acronyms to discover or to deeper investigate like TDD or BDD (test driven deployment), which is an often mentioned key to high quality softwares, SOLID (Single responsibility, Open-closed, Liskov substitution, Interface segregation and Dependency inversion) which describes the “first five principles” of object-oriented programming and design and so many more. Thanks to the internet, knowledge is only a click away, motivation however, has to be found somewhere else.

    On a long term perspective, without proper training, programmers won’t learn much more about the fundamentals and might become somewhat limited. Their errors’ becoming someone else’s to fix and their lack of knowledge becoming time consuming for others.

    Most companies understand that principle and have found an easy solution, encouraging through different means, their employees to develop their skills through seminars, conferences, classes and basically everything that can potentially make one become better. This tendency has started in most countries that understand that programming can be a career path and not only another step on a stair that leads to management. Unfortunately, training individuals can be costly and not everyone can afford it. That is where dedication and thrive to learn kick in, buying a book and reading it is affordable by most.

    The other problem implied is that as time goes by, experts will become rarer and busier, leaving new programmers to themselves, in charge of their own fixing, eventually leading to chaos and destruction of the world as we know it.

    Already in 1995, Niklaus Wirth stated that “software is getting slower more rapidly than hardware becomes faster”. A variant by David May is even more explicit by doing a corollary with Gordon Moore’s law: “Software efficiency halves every 18 months, compensating Moore’s law”.

    This proves that knowledge is the key to a good programmer and IT, as every single science, always evolves and so should the people working with it.