Tag: programming language

  • The Bedrock of Digital Transformation

    The Bedrock of Digital Transformation

    Trends come and go. I’m old enough to have been persuaded, twice, about the good sense of flared jeans. I had a space hopper. I had a Betamax video player. Fads and cool ideas are a constant white noise, vying for our attention. Some will stick, some won’t. And that’s true in technology. No-one admits to owning a C5, but plenty of us built PowerBuilder and Delphi apps. A few of us tinkered with Smalltalk.

    But genuinely smart, enduring ideas find a way of sticking, of evolving, and adapting. No-one these days thinks of a phone as a wired device stuck to a wall which you could only use if you asked someone to connect you. And no longer do you have to employ anyone to run in front of you with a flag as you drive your motor car. Like cars and phones, good ideas endure and in the world of computers and IT, the COBOL language is no exception.

    Very few organizations of any size are not being impacted by today’s digital era and the seismic changes being seen in the market place. Entire industries have been disrupted beyond all predictions in the last decade or so. Indeed 88% of the Fortune 500 have dropped off that list in the last 50 years, as those who fail to keep up with the pace of change are being replaced by those who can adapt.

    But adapting isn’t easy. Making fast progress toward new digital objectives is often hampered by practical barriers that are individually difficult to solve, particularly in the case of the existing technology landscape already in place. Things such as vendor lock in, complex business processes, interdependent apps and data, inefficient delivery processes, technical constraints and skills issues.

    Additionally, the technology landscape is forever changing, but only growing in complexity. Today, large global enterprise businesses typically run a hybrid environment, which is a consequence of adopting multiple waves of technological advancements over time. Each individual advancement offered opportunity and progress, but eventually results in a highly complex and inefficient technology environment. Most organizations are pursuing digital transformation programs with a view to reduce complexity, create better flexibility and reduce total cost of ownership.

    There has been tremendous value created in business applications and data and there is a lot to be gained in digital transformation by leveraging that value as much as possible, in transforming it with the minimum cost and risk. Much of this value is encapsulated in systems built some time back, and which have evolved with the business. Oftentimes, using COBOL technology. COBOL was invented way back when, but has adapted to support ongoing business technology demands and rigors.

    Having an appreciation for where your organization is today, along with an awareness of what needs to be achieved in regard to the required updates, the process used and the infrastructure considered, can assist with plotting the pragmatic steps to develop a plan that delivers transformational value. With some of the most critical systems being written in COBOL, these core systems continue to power a variety of fundamental processes in modern business.

    The risks of ripping and replacing systems are measured as an average IT project failure rate of 71%, which amounts to a $1.7tr cost in a single year. These are dreadful numbers and no organization wants to waste that sort of time and money and reputation. There is now a growing realization, from many years of experience in those more radical transformation projects, that their success rate is relatively low, planned costs and timescales typically grow exponentially, and the risks to successfully continue business during such a transformation are unacceptably high.

    Enter stage left a more pragmatic approach: modernization. This concept prioritizes on protecting the value of what companies already have, exploiting advancements in technology to deploy and integrate applications in new ways and to surface and integrate data in new ways, with the minimum change to what already exists. Creating portability and operational independence for applications and data is becoming recognized as the fastest and most future proofed path to building a platform for digital transformation. Market influencers such as Gartner and IDC have commented on it, and most of the global systems integrators are industrializing their modernization practices to support companies successfully transform. So what is the underlying technology acting as the catalyst for this modernization and transformation?

    COBOL enters its seventh decade of helping run great chunks of the world’s largest IT systems entirely thanks to its staying power; its adaptability.

    COBOL’s endurance owes a lot to its original design that make it readable and portable, meaning it can be picked up by new staff quickly, and deploy wherever it is needed. What kept it in such demand owes more to the ongoing evolution of the language itself, and the tooling surrounding it. COBOL works alongside, integrates with and supports containers, cloud, JVM, .NET, JSON/REST, micro services, modern IDEs and other technology typically associated with more contemporary names. COBOL technology plugs directly into a DevOps toolchain that is adopting continuous delivery practices for some of the economies’ most important IT systems.

    COBOL is, in fact, a 2019 technology; just with a 60-year heritage.

    Next time you pick up your mobile to make a call, or sit in your car to drive to work, ask yourself how you feel about how old that idea is.

    — Derek Britton

  • Pivotal Software Embraces OpenJDK

    Pivotal Software Embraces OpenJDK

    Pivotal Software has officially thrown its weight behind OpenJDK, the open source version of the standard edition of Java, by adding support for OpenJDK to the Pivotal Spring Runtime on its Spring framework.

    At the same time, Pivotal announced it is extending its commercial support for open source Apache Tomcat servers in addition to providing commercial support for all the major open source Spring projects, including Spring Framework, Spring Boot, Spring Cloud and Spring Cloud Dataflow.

    Since 2011, Oracle, IBM and SAP have been making a case for employing OpenJDK. Ryan Morgan, vice president of engineering for the application platform at Pivotal, said that while other languages have become increasingly popular, the primary workhorse for building back-end applications in the enterprise remains Java. Now that Oracle has formally relinquished control over Java source code to The Eclipse Foundation, research and development into the legacy programming environment should accelerate. Oracle retains licensing rights to the name Java, but versions 8 and higher of Java Enterprise Edition are being converted to an open source platform known as Jakarta.

    Morgan said much of the work going forward would be focused on modernizing monolithic Java applications to make it either to turn them into microservices or at least make it easier for microservices developed in other languages to make calls via application programming interfaces (APIs) to those back-end applications. As enterprise IT organizations make the shift, they increasingly will rely on DevOps processes to manage the transition. The effort should accelerate the extent to which many organizations will need to rely on modern best DevOps practices.

    As both OpenJDK and Jakarta continue to move forward, Morgan said Pivotal is committed to continuing investment in the Spring framework, which has done much to make developing Java applications a much more agile endeavor. The most immediate benefit, of course, is the reduction of licensing fees associated with employing Java platforms. Many IT organizations that have mandated open source code-first and adopted alternative programming languages now may want to reconsider their options, especially when the number of developers who know how to write applications in more modern languages is comparatively small.

    Of course, it will take many years for enterprise IT organizations to fully make this transition. In the meantime, many of them will continue developing applications in Java simply because they have large teams that have mastered a programming construct that has been in place for three decades or more. Many of those same organizations may be making greater use of rival programming constructs, but Java and its descendants will play a major role in the enterprise well into the next decade. The primary challenge Pivotal will face is maintaining dominance of the frameworks employed to build new applications based on Jakarta and OpenJDK, in addition to updated existing Java applications.

    — Mike Vizard

  • DevSecOps: Fortanix Adds Open Source Rust SDK to Build Encrypted Apps

    DevSecOps: Fortanix Adds Open Source Rust SDK to Build Encrypted Apps

    There’s a lot of focus these days on DevSecOps as part of an effort to fix what’s generally acknowledged as a broken cybersecurity paradigm. But instead of trying to ensure every potential vulnerability is addressed before an application is deployed, another idea is gaining momentum among the DevOps community: Build applications that are secure in the first place, using modern programming languages.

    Fortanix, at RSA Conference 2019, launched an Enclave Development Platform (EDP) based on an open source software development kit (SDK) written in Rust. The SDK is optimized for Intel Software Guard Extensions (SGX), which are extensions to Intel instruction sets that define private regions of memory, dubbed enclaves, that prevent data to either be read or saved by any process outside the enclave. Intel SGX is required to be on by default in the latest generations of Intel processors.

    Company CEO Ambuj Kumar said Fortanix has been advocating the adoption of a runtime platform that makes it possible to process encrypted data in memory without ever having to expose it as plain text. By partnering with Intel to create a Rust-based SDK, the company wants to make it easier for developers to take advantage of an inherently secure programming language to invoke the Fortanix runtime.

    Fortanix, which also provides access to a self-service key management service for managing encryption, recently received an additional $23 million in funding led by Intel Capital.

    Kumar said Rust is gaining in popularity as a programming language because it is designed to include guardrails that prevent cybercriminals from injection attacks by corrupting code running in memory. In fact, Kumar noted that one of the reasons why cybersecurity professionals are now against deploying applications written in C or C# is because there are no such guardrails available.

    The combination of Rust and Intel SGX doesn’t eliminate the need for organizations to define a set of best DevSecOps processes. But it does take a significant amount of pressure off developers who choose to build applications using a modern programming language to create applications that are not as easily hacked.

    Naturally, it will take some time for developers to give up tools based on legacy programming languages that many of them have been using for years. But Kumar said Rust adoption is already spreading like wildfire because developers are looking for a way to eliminate cybersecurity issues that many are now being held accountable to resolve once they are discovered in a production environment.

    Of course, billions of lines of legacy application code are not going to disappear overnight simply because a new programming language has come into vogue. But enhancing cybersecurity may very well become a compelling reason to rewrite some of those most mission-critical legacy applications, especially if they wind up improving the performance. After all, those legacy applications are targeted because that’s where the organization’s most valuable data resides. Of course, Intel is betting it won’t make sense to deploy those rewritten applications on processors that don’t support SGX. But whatever the rationale, the amount of time developers have to devote to ongoing cybersecurity issues is clearly limited.

    — Mike Vizard

  • Best of 2018: The Beauty of the COBOL Programming Language

    Best of 2018: The Beauty of the COBOL Programming Language

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

    Well-written code is a work of art. Always has been, always will be. A programmer pulls a thought pretty much out of nowhere and transforms it into a working idea that can be used by others. It’s abstract expression made real. Computer programming requires a depth of creativity and discipline of logic that is hard to find elsewhere. Maybe architecture and the theoretical sciences come close, but computer programming stands apart. Computer programming is special and I love it!

     

    Thus, I am always interested to learn a new programming language. Every programming language offers a new way to expand my thinking. It’s always time well-spent.

    Recently I decided to learn COBOL, for no other reason than the fact that there are a lot of mainframe installations out there and it’s the mainstay language for many of them. Mainframes are critical to the operations of many banks, insurance companies, transportation systems and governmental agencies. Learning COBOL been on my Bucket List for while.  So I took the plunge.

     

    What does the term, COBOL stand for? Common Business-Oriented Language

    Working with COBOL in a Modern IDE

    The first thing I needed in my journey to learn COBOL was an IDE. I am a big supporter of coding in an integrated development environment (IDE). I like being able to write, test and run code all in one place. Also, I find the support features that an IDE provides, such as visual code structure analysis, code completion and inline syntax checking, allow me to program and debug efficiently.

    The IDE I found is an open source product, OpenCobolIDE, as shown below in Figure 1.

    Figure 1: OpenCobolIDE provides many tools to make COBOL programming easier

    OpenCobolIDE allows me to write, compile and run code all in one place, without having to go out to the command line, which is very good because I am the world’s worst typist!

    Programming COBOL in the Real World

    When it comes time to do real world, mainframe based COBOL programming, you will do well to look at the IDEs that IBM provides. The tools are designed to go about against its Z Systems environment seamlessly as a set of Eclipse plugins. These tools allow COBOL developers working in the mainframe environment to code, debug, unit test and do problem determination.

    Having set up my development environment, the next thing to do was design my first project.

    Designing My First COBOL Program

    Typically when learning a new language I like to start small and work my way up into more complex tasks. I did the typical Hello World program. You write the code to display string, Hello World, to standard output. Every developer does one. It’s a trivial program, as shown below in Listing 1

    beauty-of-cobol-listing-01
    Listing 1: A Hello World program written COBOL

     

    While the Hello World required that I learn about the concept of a DIVISION, which I will discuss in detail below, in the scheme of things, I needed more. I wanted to write a program that would force me to learn how the following:

    • How to create and use variables.
    • How to structure data into a hierarchy.
    • How to structure code into encapsulated procedures.
    • How to do some basic arithmetic.
    • How to accept user input and then do some manipulation around that input.

    Thus, I create the program, RESEL-WORLD, as shown in Listing 2, below.

    beauty-of-COBOL-Listing-02

    Listing 2: The COBOL program, RESEL-WORLD accepts and manipulates users’ input

    The user input and program output is shown below in Figure 2.

     

    Figure 2: The RESEL-WORLD COBOL program asks a user for first name, last name and age, then manipulates the input

    The RESEL-WORLD program taught me a lot about COBOL and how to program in the language. In the spirit of giving, I am going to share what I learned from writing the program. However, before I delve into the details, please be advised that the information I’m presenting is but a high-level overview. As with any programming language, it takes about a year of consistent coding to become an entry-level professional. My sincere hope is that the information I provide gives the reader a good sense of the language and enough motivation to want to learn more. As I mentioned early, learning COBOL is worth the effort.

    COBOL is Code in a Structured Document

    The most important thing to understand when learning COBOL is that is very strict in terms of code layout. The layout rules relate to the use of columns and characters. Also, the format uses a hierarchical outline structure. The following sections describe the details of layout specification.

    The COBOL Column Specification

    In COBOL a line of code can be no longer than 80 columns in length. You can also think of a column as a character. Columns are segmented into groups, with each group serving a particular purpose. The columns groups are as follows:

    Columns 1-6 is the group in which a programmer defines a sequence number. A sequence number is similar to a line number.

    Column 7 is reserved for special characters. Asterisk (*) starts a line of comment. Hyphen (-) indicates line continuation and slash (/) is form feed.

    Columns 8-11 is called Area A. Area A is the group of columns in which you start a DIVISION, PARAGRAPH and SECTION. We’ll talk more about these below in the next section, The COBOL Structural Hierarchy.

    Columns 12-72, also known as Area B, is where you write code statements.

    Columns 73-80 is reserved for developer use. You can write poetry in there, if you so desire. Just make sure you don’t go past column 80.

     

    Figure 3, below illustrates the columns grouping described above.

    Figure 3: Each column in a COBOL file is specified to serve a specific purpose

     

    COBOL is a compiled language. When it’s time to run your code, the compiler will check to make sure that the code layout adheres to the column grouping specification. If there is a violation, the compiler will error.

    Understanding Performance in Terms of Compilation and Compilers

    COBOL is a compiled language, as are others such as Java, C# and C++. Compilation is the process of taking textual source code and converting into a binary format that the computer can understand.

    There’s a lot of variety in the COBOL world when it comes to compilers, particularly when it comes to cost and performance efficiency. For example, how a compiler orchestrates the way numbers are loaded and then computed in memory matters a lot! A good compiler will make code run really fast.

    IBM has been in the COBOL business for a long time and has a keen understanding about making compilers that are fast and cost-effective. For example, the z14 System compilers improve efficiency by taking advantage of almost 24 new low-level instructions. As a result, computation speeds improve dramatically.

    As you work more with COBOL, you’ll come to appreciate the power that an industry-leading compiler such the IBM Z Systems brings to the coding experience.

    The COBOL Structural Hierarchy

    The concept behind the file format of a COBOL program is based on the structure of a document outline, with a single top-level heading followed by subordinate levels. The organizational units that make up the hierarchy are PROGRAM, DIVISION, SECTION, PARAGRAPH, SENTENCE, STATEMENT and CHARACTER. Figure 4 illustrates the hierarchy.

     

    Figure 4: The structural hierarchy of COBOL program entities

    PROGRAM is the root level of the COBOL code hierarchy. PROGRAM represents the unit of code that the mainframe job scheduler, the JCL, loads into memory to run. The program is identified by the PROGRAM ID statement in the IDENTIFICATION DIVISION. The IDENTIFICATION DIVISION is part of the next level of hierarchy that descends from PROGRAM. PROGRAM must contain the IDENTIFICATION DIVISION.

    There are other DIVISIONs that can be included. These other DIVISIONs are: ENVIRONMENT DIVISION, DATA DIVISION and PROCEDURE DIVISION,  which occur after IDENTIFICATION. Also, these subsequent DIVISIONs must appear in the order defined: ENVIRONMENT, DATA and then PROCEDURE. You can read a detailed description of each DIVISION here. DIVISION names are terminated with a period, for example,

    DATA DIVISION.

    The next organizational level down from DIVISION is SECTION. (Please see Figure 5.) Each DIVISION will contain SECTIONs that are special to it. For example, the DATA DIVISION can contain FILE SECTION, a, WORKING-STORAGE SECTION and/or the LINKAGE SECTION. You can read the details about DIVISIONs and SECTIONs here.


    Figure 5: A COBOL program is structured in a hierarchical manner

    A SECTION name is terminated with a period, for example:

    WORKING-STORAGE SECTION.

    A SECTION contains zero or many PARAGRAPHs. (Typically a SECTION will have at least one PARAGRAPH.) A PARAGRAPH name is terminated with a period, similar to a DIVISION and a SECTION.

    A PARAGRAPH contains SENTENCEs or STATEMENTs. A SENTENCE is a group of STATEMENTs. Usually a PARAGRAPH contains one or more STATEMENTs. A STATEMENT is a line of execution. A STATEMENT is made up of CHARACTERs. A CHARACTER can be an alphanumeric symbol or a special character. CHARACTER is at the bottom of the COBOL code format hierarchy.

    Variable and Data Types

    COBOL allows you to declare variables in a variety of data types. Special to COBOL is the concept of a variable level as represented by a level number. A level number defines a variable in terms of being or having a parent variable. (You’ll see more about this in the section, COBOL Supports Hierarchical Data, later on.)

    The following statement, which will be declared in the WORKING-STORAGE SECTION of the DATA DIVISION, is the declaration of a variable, WS-QUANTITY. WS-QUANTITY will hold a numeric value.

    01  WS-QUANTITY PIC 9(2) VALUE 12

    The expression above above declares a variable , WS-QUANTITY to be a two-digit value with an initial value of 12. Also, the variable is declared to be at level 01, which is the highest level possible. The variable has no parent. The way we know that WS-QUANTITY is a variable for a two-digit value is due to the PIC (Picture) clause. You can think of a PIC clause as a type declaration. Table 1 provides a high-level description of the various PIC clause symbols.

    Symbol Description Example Declaration Sample Value
    9 A numeric value where each occurance of 9 represents a digit 99 or 9(2) 35
    a Alphabetic aaa or a(3) “Bob”
    x Alphanumeric xxxx or x(4) “R2D2?”
    v Implicit decimal* v(3) .175
    s Sign s9(2) -76
    p Assumed decimal* p9 .6

    Table 1: Symbols for a PIC Clause

    *COBOL has a special way of storing numbers such that the numeric conversion take place when the characters are loaded into memory. For example, a variable with a PIC of p9(2) will be stored as 56 and loaded into memory as .56. For a more detailed discussion of usage and the PIC clause, go here.

    COBOL Supports Hierarchical Data

    Storing data in a named group of variables makes programing easier. For example, in the C programming language, we can use a struct to name a group of variables, as shown below in Listing 3.

    struct User { 
      char  first_name[10]; 
      char  last_name[10] 
      int   user_id; 
    };

    Listing 3: A simple structure in C

     

    One of the real nice things about COBOL is that it allows you to organize data according to a named group of values similar to that of a C struct. What’s interesting in a historical sense is that COBOL has had this capability well before Kernighan and Ritchie created the C programming language.

    The way COBOL accomplishes named data grouping is with construct called a record. Figure 6 below shows a graphical representation of a record named, WS-USER.

    Figure 6: The record, WS-USER contains subordinate variable, WS-FIRST-NAME, WS-LAST-NAME, WS-AGE

    The code snippet in Listing 4, which is from the RESEL-WORLD program at the start of this article, shows the COBOL code that declares the record, WS-USER.

     

    beauty-of-COBOL-Listing-04

    Listing 4: The record, WS-USER contains 3 subordinate elements, WS-FIRST-NAME, WS-LAST-NAME, WS-AGE

    Notice in Listing 4 above the there are two levels of data variables in play: 01 WS-USER and 05  WS-FIRST-NAME, 05 WS-LAST-NAME, 05 WS-AGE. The variable, WS-USER is a parent to the subordinate, level 05 variables, WS-FIRST-NAME, WS-LAST-NAME, and WS-AGE.

    Assigning variable to a numeric level is special to COBOL. The declaration logic is that a record variable (the root of the record) has a level number of 01.  Levels 02 to 49 are used to declare subordinates elements. (You can think of a element as a member of the record.)

    You use the reserved word OF to access an element of a record. Listing 5 below shows two statements. The first asks a user to input their first name. The second statement takes the value entered and assigns it to the element, WS-FIRST-NAME of the record, WS-USER.

    DISPLAY "What is your first name?".
    ACCEPT WS-FIRST-NAME OF WS-USER.

    Listing 5: Accessing an element of a record in COBOL

     

    It make sense that records were part of COBOL from the start. COBOL was intended to be a language used for business application. Businesses have been organizing values according to named groups since before the customer form was created. COBOL was designed to reflect business needs. It’s interesting that the fundamental needs of businesses in terms of logical data structures have been surprisingly consistent over time.

    COBOL Has a Natural Language Syntax

    Expressing a statement in COBOL is very similar to the way a person speaks naturally. Listing 6 below shows the statement that adds together the values of the two variables, WS-AGE-DELTA and WS-AGE (from the record WS-USER), and stores the result in the variable, WS-NEW-AGE.

    
    ADD  WS-AGE-DELTA WS-AGE OF WS-USER TO WS-NEW-AGE.

    Listing 6: Adding two integers, WS-AGE-and DELTA WS-AGE, then storing the sum in the variable, WS-NEW-AGE

    Notice that the statement in Listing 6 is very close to saying, “Add WS-AGE-DELTA and WS-AGE from WS-USER to WS-NEW-AGE.”

     

    What I find pretty astounding is that many modern programming paradigms try to capture the ease of natural language expression that COBOL has had for years. What comes to mind immediately is the use of natural language expressions in the NodeJS Chai package. Chai is used in NodeJS unit testing to express BDD assertions. Here’s a Chai expression that checks a variable, myVar to assert that it’s a string.

    expect(myVar).to.be.a('string');
    
    FAST FACT: Is COBOL a case-sensitive language?

    No. COBOL will consider a variable named WS-FIRST-NAME to be the same as one named ws-first-name.

    COBOL supports DRY

    For programming language to be really useful, it needs to support DRY. DRY is an acronym for Don’t Repeat Yourself. Most programmers don’t want to write the same code over and over again, nor should they. What you want to do is to encapsulate code in to a single area of execution that can be called repeatedly. Being able to program by DRY is common for most languages—BASIC, Java, C#, Javascript, Python, to name a few and … you guessed it: COBOL.

    COBOL supports code segmentation and reuse in a variety of ways. One way is through linkage, calling routines between programs. Another way is to segment code inline under a PARAGRAPH in the PROCEDURE DIVISION and then call that PARAGRAPH. (See Figure 7.)

    Figure 7: You can make code reusable in COBOL PARAGRAPHs

    The little RESEL-WORLD program I wrote uses the inline PARAGRAPH technique. Before I go in to the details of calling code encapsulated into a PARAGRAPH, it’s important that you know that in COBOL the entry point of execution into a program is the first line of code after the declaration of the PROCEDURE DIVISION, as shown below in Listing 7.

    beauty-of-COBOL-Listing-07
    Listing 7: COBOL supports reusable code by using PARAGRAPHS to segment execution

    Notice the PERFORM statements right after PROCEDURE DIVISION. These four statements are calling PARAGRAPHs. (For those of you familiar with JavaScript, you can think of each PARAGRAPH as a function definition.) Essentially what the code is saying is, “Execute the code at the paragraph named, GET-DATA, then perform the code at CALC-DATA, SHOW-DATA and then FINISH-UP.”

    Encapsulating code into STATEMENTs within a PARAGRAPH prevents code from become spaghetti that is hard to maintain. Also, the encapsulation enforces the sensibility of DRY. Any language worth its salt needs to support some sort of encapsulation. COBOL meets the need with room to spare.

    An Expressive Language for Now and the Future

    The more I learn about COBOL, the more I like it. The language continues to evolve to meet the needs of our fast-changing times, with revisions as recent as 2014. Since its inception there have been a dozen enhancements to COBOL including a continuing stream of formal standards.

    Today’s COBOL supports modern programming paradigms such as object orientation. The IDEs have grown to keep pace with the demands of modern users. And, given the immense installation base out there, there is a lot of money to be made doing COBOL programming. To quote Wikipedia:

    In 2006 and 2012, Computerworld surveys found that over 60% of organizations used COBOL (more than C++ and Visual Basic .NET) and that for half of those, COBOL was used for the majority of their internal software.

     

    What’s even more amazing to me is the cleverness of engineering the language has promoted. COBOL developers addressed problems in the past that still vex many today. We modern developers can fall prey to thinking that before we came along, there was no cool stuff. It’s like the young, aspiring guitarist who thinks thinks he has his chops down and can shred to the top of the heap. Then one day his music teacher gives him a 1936 recording of Django Reinhardt playing guitar, and playing with only two functional fingers on his left hand! At that point the young artist realizes that virtuosity transcends era and that creativity has no bounds. This is what it’s like for me as I learn COBOL. It’s a beautiful, expressive language that was cool then and is very cool now. Learning it is making me appreciate how much amazing thinking went on back then and continues to emerge. There’s a lot of rich opportunity at hand to make great code for mainframes using COBOL. It’s only a matter of mastery, creativity and discovery.

    Special Thanks

    If I have seen further it is by standing on the shoulders of giants.

    —Isaac Newton, Letter to Robert Hooke, February 5, 1675

    Learning any programming language is hard work. Years ago, when I wanted to learn a new language, I would get a few books on the topic and then hunker down to spend the hours necessary to absorb the required knowledge. If I had the time, I might take a course. Maybe I had an expert friend I could call up when I hit a wall or needed real-world guidance.

    We’ve come a long way since that time. The internet is a game-changer. Online tutorials, videos and interactive, digital books make things a whole lot easier than in earlier times. My experience learning COBOL testifies to the value of these modern benefits. But still, as I’ve been learning, I’ve hit more than one wall that required professional guidance and review. Allan Kielstra and Roland Koo at IBM (who also wrote this great article) provided the expertise that made my learning COBOL not only less difficult, but also fun. I am in their debt. Their enthusiasm for COBOL was infectious. Their commitment to technical excellence is inspiring.

    — Bob Reselman

  • Using Open Source Languages Effectively in the Enterprise

    Using Open Source Languages Effectively in the Enterprise

    Open source languages are part of almost every business these days. In fact, according to Opensource.com, open source will be the driving force behind a great number of technology innovations due to its pervasive use. From development to quality assurance (QA) to DevOps, all kinds of coders have embraced open source languages. In doing so, though, enterprises have given up easier-to-adopt, general-purpose languages in favor of more niche-oriented languages.

    Those who are enthusiastic about open source languages have been contributing to open source language projects and building versions of languages including Perl, JavaScript, Go, Tcl, Ruby and Python. There has been a massive shift in the adoption of open source languages and genesis of new ones in the last 20 years. Even large corporations such as Microsoft, Google and IBM contribute to open source projects that are hosted on GitHub, and Spotify, Dropbox and Reddit are among the big names that use Python.

    This mainstream adoption speaks to the enormous popularity of open source languages. This has brought about the proliferation of new languages co-existing with older languages, which creates more and more challenges for various stakeholders in the software development life cycle (SDLC)—and more tension.

    The tension between these two groups exists because of the gap between their needs. Addressing this tension requires a convergence of the needs of two specific stakeholder groups: coders and the enterprises for which they work. There are ways to fulfill what both coders and enterprises need, create better experiences for coders and make things easier for all stakeholders in the SDLC.

    Enterprises require security, control and compliance. Coders need speed, want to create and crave a frictionless environment. Roadblocks and restrictions need to be removed for coders while ensuring the needs of the enterprise are being met.

    Strength in Uniformity

    What would it look like if you could gain all of the potential benefits of open source languages while still fulfilling coder needs and resolving your enterprise requirements? What if uniform tooling could be provided across open source languages? And what if enterprises could use a single uniform tooling set regardless of open source language? It would solve needs for the coder and the requirements of the enterprise.

    Using uniform tooling, an enterprise’s open source languages can be compiled and installed; dependencies found and installed; and code written, tested and updated complete with security and license compliance needs being addressed. However, tooling currently isn’t uniform across open source languages. And the maturity and best practices of tooling wildly vary. Enterprises create a workaround by creating policies to mitigate for deficiencies in tooling. This workaround is sub-par because it happens too late in the SDLC after threats and issues are introduced into your code.

    Establishing a Single Ecosystem

    The quality that makes open source so useful—its openness—and its lack of controls makes it something of a digital wild west. Fewer restrictions enable faster innovation, but they come at the cost of quality and cohesion for the enterprise. Many of your installed libraries have holes and security threats. Enterprises are faced with time-consuming license reviews to ensure adherence to third-party license rules as well as internal policies restricting certain types of licenses. In addition, license reviews happen at one point in your code’s life cycle versus in an ongoing, automated way. Enterprises are burdened with high administrative overhead and stale information.

    However, there is a different scenario possible. What would it look like for a company to have a uniform and high-standard ecosystem for their package management, with no vendor lock-in, all based on open source? What if a company could be guaranteed the same quality and types of packages for every language they use? What if a company could easily have visibility for what is being used across all of their environments, from concept to development to testing to production? It would be easier for the coder and fulfill the requirements of the enterprise.

    The wild west quality of open source language ecosystems makes them somewhat unreliable; updates and deletions can occur. And there are different package management solutions with differing degrees of sophistication, complexities and required expertise to use. Today an enterprise can easily end up with multiple package management solutions and have different packages of the same open source programming language. There is no single or consistent source of truth. 

    Working with a technology provider is an effective way to mitigate your open source language risks and solve your coder need for speed. A provider can offer more than just support, inlcuding:

    • The appropriate licenses based on usage and policy requirements
    • The right packages for each specific application
    • The best notification and remediation based on Common Vulnerabilities and Exposures (CVE) security threats
    • The indemnification that fits, based on usage
    • The expertise to build you the language distros you need based on usage, environment, security and compliance requirements and applications.
    • The right builds, standardized for all of your teams and ready to go out of the box

    Thriving in the Wild

    Sometimes, using the “right tools” for the job involves coders building many programming languages in an environment. The resulting “polyglot” situation creates benefits as well as challenges. Better products are made, and products are shipped faster, but it’s difficult to build a core competency in a particular programming language. And it’s impossible to centralize support and difficult maintenance requirements.

    What’s needed is a single, uniform tooling set that can work across multiple languages. This makes open source languages easier to use and implement in the enterprise, addressing the needs of developers as well as those of the enterprise. Working with an expert advisor will help you not just survive but thrive in the wild and woolly world of open source.

    — Bart Copeland

  • The State of the Kotlin Programming Language in 2018

    The State of the Kotlin Programming Language in 2018

    Pusher, the communications and collaboration API provider, recently released the findings of its “State of Kotlin 2018” research report. Over the past 24 months, adoption and use of the Kotlin programming language among developers has seen tremendous growth. Pusher has seen this growth firsthand, with more developers using Kotlin while building applications with the company’s products.

    Earlier this year, Pusher surveyed more than 2,500 developers to get a better understanding of the ecosystem, specifically around usage, features and demographics.

    Key report findings:

    Kotlin is used both in work and personal projects, as confirmed by 60 percent of respondents. Kotlin is even more prominent in side projects, as they tend to be smaller, easier to convert and more experimental.

    Android is hugely popular across the board, used by professional developers and students alike. However, when it comes to backend applications, Kotlin’s users tend to be more experienced developers.

    Most Kotlin developers come from a Java background, or also work with Java. More than 87 percent of respondents have migrated existing Java code to Kotlin. However, more than a quarter of respondents who migrated Java to Kotlin needed to revert back due to both technical and organizational reasons. Tools that use reflection or generate code were mentioned most often as technical reasons to revert to Java.

    Null safety is the favorite feature for 80 percent of respondents, whereas co-routines and multi-platform support are the least important.

    The report concluded that Kotlin is overwhelmingly popular in the Android circles. This raises the question, Will Kotlin break into communities outside Android?

    “We expect to see new generations of developers taking their first steps into programming with Kotlin,” said Pusher Developer Evangelist Zan Markan in an email. “It’s a modern, versatile, cross-platform language that can cross between OO, functional, scripting, and declarative paradigms with ease. This could mean that Kotlin will affect the wider programming language landscape by becoming a benchmark for what a programming language should be able to do.”

    Read the full report here.

    — Malia Powers

  • How Python is Transforming the DevOps Landscape

    How Python is Transforming the DevOps Landscape

    DevOps is the combination of operations and software development which reduces or almost eliminates the disconnect between systems administrators who run the infrastructure and software developers who develop applications.

    During software development, when the Agile methodology is utilized properly, a bottleneck often occurs during the frequent operations and deployment phases. New fixes and updates are produced so rapidly in every sprint that the infrastructure teams can be swamped with deployments. To eliminate few of these issues, the operations personnel and application developers are asked to work closely to automate the code delivery to production from deployment.

    As DevOps is an approach for handling change and agility, engineers must master multiple languages. The Python programming language is one of the most crucial components of the DevOps toolchain. Many DevOps teams utilize it for building web applications for visualizing custom data, building custom utilities and more.

    Ansible and other tools are written in Python, which means you can build custom scripts or modules to automate your tasks, for example, or do other things.

    Reasons for Using Python for DevOps

    The accessibility and flexibility of Python are reasons why it is a preferred language for the DevOps toolset. If you are working in the role of DevOps, you must require an adaptable skillset; you must know how to work with multiple languages. For anyone looking to explore new tools and languages, and are curious about technology, the language can form a solid foundation, as it doesn’t require the commitment levels that a specialist language requires.

    In addition, it is a great scripting language, and scripting refers to automation. A few major configuration management tools, including SaltStack and Ansible, are written in Python underscores. This shows how useful the language is when it comes to orchestration and infrastructure automation.

    Python and Ruby are compared often, and with good reason: Both are highly accessible and utilized in applications developed by many organizations. They also feature in the DevOps toolset. We can do almost all the things with Ruby that we do with Python. But, when it comes to syntax, Python gains the upper hand, as it is much more direct than the syntax of Ruby.

    In the realm of learning to debug problems and code, Python has the advantage over Ruby, as it takes a much more direct approach to programming. Its directness and simplicity are invaluable if you are working in DevOps environment and agility is highly important.

    Conclusion

    As a growing number of engineers and developers take on decision-making responsibilities, Python can be the stabilizing language. And not only for DevOps—the language also can be used for developing blockchain, which is the underlying technology for various cryptocurrencies such as bitcoin wallet. As it can be utilized in various ways, it enables you to be open to broad range of technical possibilities. Python is the go-to programming language for the DevOps landscape.

    — savaramravindra

  • 5 Resources for JavaScript Developers

    5 Resources for JavaScript Developers

     Javascript (JS) is one of the most widely used and beloved programming languages in history. This can be attributed to its fairly light learning curve and impressive functionality. Designed by Brendan Eich in 1995, the language has seen steady gains in use for more than 20 years.

    JS itself is a high-level and weakly typed language, which means it is powerful and less prone to errors than other coding languages. It achieved early success and is now integrated on both the client side and server side.

    Most applications and OSs come pre-built with JS development capability. It has become ubiquitous in the web development market and continues to be the strongest and most popular web language out there.

    With that in mind, here are five resources for JavaScript developers:

    Codecademy

    Codeacademy is one of the most invaluable resources a programmer can have. It offers tutorials and lessons on hundreds of topics and provides copious amounts of examples to bolster your programming skills. JS has its own page at Codecademy filled with lessons and coding tests to hone your skills and promote better learning.

    Codewars

    If there is anything that can hone your programming know-how in real-life situations, it’s Codewars. This handy website has weekly challenges to conquer in JS submitted by real people. It puts JS developers in the hot seat and allows them to deal with situations that they may find in real-life work environments.

    It also challenges the knowledge of experienced programmers and enhances their practical skills. Troubleshooting assistance is another big help for programmers just starting out, as it helps identify the small mistakes that can prevent compiling code.

    MDN

    The Mozilla Developer Network (MDN) is a remarkable resource for all JS programmers as it continually updates with the best practices for coding. It has a gargantuan community and is constantly evolving to fit the needs of newer applications.

    For developers, MDN provides unique and incredibly detailed documentation on everything from developing for traditional web to mobile web development. The MDN Web Docs has no equal when programming JavaScript, as it guides you from beginner to expert effortlessly, it seems.

    Libraries

    This is where JavaScript really comes into its own as a powerful platform and highly functional language. JS has a library for everything from GUI to to form applications.

    The most popular library is JQuery, which is a DOM (Document Object Model) manipulation framework designed to make all parts of a webpage customizable. JQuery, like the other libraries, seeks to simplify syntax and provide greater readability across the platform. This makes JS an incredibly customizable language that makes coding easier without losing the functionality of the language.

    Code-Alongs

    One of the most underutilized tools in the programming field, code-alongs make coding much easier than trying to teach yourself from a book or learn from a lecture. During code-alongs, programmers will code live and share their thought processes as they do certain things.

    This especially helps new developers who stare at a screen and can’t figure why that goes there. For experienced developers, it can offer an insight to different strategies that they might not know otherwise. Regardless, code-alongs are incredible tools made by individuals for the sole purpose of fostering a love for programming.

    Conclusion

    Programming jobs today usually require a knowledge of various languages, but almost always JavaScript is a requirement. Its usefulness make it one of the must-learn languages for all coders hoping to make a living. To make life a little easier, and JS a little stronger, there are many resources that can be utilized.

    JavaScript is an incredible programming language entirely deserving of its recognition. It is also a necessary tool for programmers of all styles and philosophies. To that end, resources abound for JS and should be used to their fullest. The true usefulness of JavaScript is its amazing community and incredibly involved developers that make JS the programmers dream. If there is any language you should learn now, it’s JavaScript.

    — Josh Althauser

  • DevOps Challenges in C/C++ Projects

    DevOps Challenges in C/C++ Projects

    “C++ is not only the most powerful language in terms of performance, but it’s also a great language! It has true generics, it is expressive, and one of the most loved languages out there by programmers.”

    — Diego Rodriguez-Losada, SW Engineer at JFrog and creator of Conan.io

    This very powerful language that has unbeatable performance continues to be used and favored in all industries. However, while DevOps has become pervasive in other major domains of software development such as Java, implementing modern C and C++ DevOps hasn’t been easy, despite solutions out there that can actually help.

    Let’s take a look at the challenges C/C++ developers face, and then see how they can be solved.

    tl;dr

    C and C++ are are favored by many developers for many great reasons. However, implementing modern DevOps and continuous integration in C and C++ projects isn’t easy. It is still challenging due to the nature of the C/C++ programming languages and ecosystem. Today, we have the knowledge and experience to identify the requirements we need to meet today’s DevOps needs for C and C++. And I’ll demonstrate with the below case study that this is possible.

    Building C and C++ Projects

    Ideally, we want the CI/CD flow from the developer changes to production to be as smooth and fast as possible. However, when compared to other development languages, C/C++ developers face greater challenges:

    • Long build times: This is not because C and C++ compilers are slow. In fact, they are blazing fast and some of the most advanced and brilliant pieces of technology in the whole IT world. But, C/C++ have the problem of headers and the preprocessor basically copying every included file again and again in each translation unit, bloating the lines of code that they have to compile. There are some mechanisms as pre-compiled headers that can partly alleviate the issue for second and subsequent rebuilds. Also, C/C++ languages are used many times for huge projects compared with other languages, with millions lines of code (MLoc)—a typical AAA game has 20 MLoc.
    • Diverse platforms and ecosystems, different build systems: C and C++ are ubiquitous. They are used in computers, embedded devices, mobile devices and more. But in every platform they will use different compilers (such as MSVC cl.exe in Windows, GCC in Linux, apple-clang on OSX) and with many different build systems. CMake, MSBuild and Makefiles or autotools are widely used, but companies are also using many other build systems, even developing their own custom solutions.
    • Binary compatibility: C and C++ are built to native/binary code, but binaries compiled with a certain compiler version are not compatible with other compilers, or even with the same compiler of a different version. This problem is known as ABI (Application Binary Interface) incompatibility, which other languages don’t have to deal with. ABI incompatibilities can result in link errors, which are easy to catch at build time, but oftentimes can produce runtime errors.
    • Code inlining and embedding: Shared libraries directly embed native code of static libraries they are linking. But not only that, even static libraries might embed code declared in headers from another library. This means it might be necessary to rebuild binary artifacts from source code libraries that have not been modified at all, just because some of its dependencies have changed.
    • Lack of standard for OSS: OSS libraries can host their source code in GitHub, GitLab or Bitbucket, but that doesn’t make them ready to use. Users need to build binaries from sources (which can be painful), retrieve prebuilt binaries from a system package manager (which may be obsolete and in any case different for each platform) or by using other installers or precompiled modules (which must be downloaded from a website). After that, they typically also require different tweaks to the consumer build system, which is also different for each platform.

    Modern DevOps Requirements for C and C++

    Given the above list of challenges, what are the modern DevOps practices and tool requirements for C and C++ projects?

    • Manage and reuse binaries: Building from sources every time is very expensive, error-prone and doesn’t scale for large projects. Reusing binaries should be consistent for different platforms, and deal with the ABI compatibility issues.
    • Manage all binaries in a single repository or server: Creating and maintaining packages in several systems (such as apt in Debian, rpm in RH, nuget/choco in Windows and pkg in OSX) is very costly for developers or DevOps engineers. Being able to store, manage and retrieve binaries from the same location is a great simplifier of infrastructure and flows, thus a big time saver.
    • Adapt to any build system, platform and tool, from legacy to latest: Creating good CI and package management would be much simpler if everyone was using a single build system. But thinking projects can migrate to a build system is plainly naive. The cost of migrating some libraries or projects to a new build system is a huge investment that can take months. Processes and tools must be able to adapt to to deal with any build system and existing legacy tool.
    • Have good integrations with other tools: Not only build systems, but tools must integrate as simply as possible with other kinds of tools. For example, continuous integration platforms such as Travis and Appveyor cloud services for Linux/OSX and Windows, popular for being free for OSS projects, as well as Jenkins, which is the de facto standard in the industry for proprietary code. Also tools must integrate well with popular IDEs such as Visual Studio or XCode and testing, coverage, static analysis, multiple control version systems, etc.

    Conan C/C++ Package Manager Case Study

    Conan is a free OSS C/C++ package manager. It is decentralized, portable, and multi-platform, running on many operating systems, such as Windows, Linux, Mac, BSD and Solaris, but targeting any possible target of C/C++ applications.

    Here’s how Conan addresses the above requirements:

    • Conan is able to build, upload, and share binaries for any number of different configurations. It manages binaries, retrieving the correct one for each corresponding platform as needed, and is also able to build from sources when necessary, minimizing ABI incompatibility issues.
    • Conan packages and pre-built binaries can be uploaded to a server and shared within They can be shared privately within a team or companywide, using the OSS conan_server or JFrog Artifactory Pro. If desired, Conan packages can be distributed worldwide using JFrog Bintray either with private or public repositories, completely free for OSS projects. All different binaries for all supported platforms can be uploaded and managed in the same server with exactly the same interface.
    • Conan works with any build system. It includes built-in integrations with CMake, Visual Studio, Makefiles, SCons, QMake and more. It also has good user-side extensibility to support any other build system, using “generators.” This means extensions can be developed to translate the Conan dependencies model to any build system format and generate files that can be read by those build systems.
    • Conan integrates well with different CI systems, with specific tools and helpers for Travis, Appveyor and GitLab, and also features custom DSLs in the Jenkins Artifactory Plug-in.

    Conan package recipes are written in Python, so they can be used to easily customize behavior to a great extent with standard Python syntax, allowing users to easily plug-in many different tools that were previously mentioned in this article: static analysis, testing, code coverage, and more.

    Let’s take a look at a typical flow, from a DevOps perspective, to illustrate how Conan works. First, a developer makes some source code changes to a specific library (LibB), committing and pushing these changes to the shared version control system server (Git Repo).

    Diagram: CI Cycle example for C/C++ with Conan, Artifactory and Jenkins (build systems: CMake, VS, MakeFile)

    Then the CI system will listen to the Git repository, ideally with Git hooks since polling is not recommended, and fire a job for it (Jenkins). Below is an example of how this would be defined with a Jenkins pipeline:

    The first stage in the above example is straightforward. The second stage invokes the package creation that is internally split into the two subtasks:

    1. The LibB dependencies are retrieved in binary form, to avoid rebuilding them from sources and wasting time.
    2. The dependency graph for all transitive dependencies is built and one or more files are written. In this example, LibB uses CMake as the build system and Conan generates a “conanbuildinfo.cmake” file that includes all of the dependencies information to enable LibB find and correctly link to them. Conan will then call the LibB build system to generate a binary package for it. And finally, in the last Jenkinsfile stage “Upload packages,” the generated binary is uploaded to the Conan package server (JFrog Artifactory). The LibB binary package is immediately available for consumption by developers or other CI jobs.

    This example illustrates a build configuration for a 32-bit architecture as specified in the  “conan create” command with the “-s arch=x86” argument. Note that many additional configurations can be built in parallel using parallel tasks and jobs for different compilers, OS, architectures and more.

    Conclusion

    C and C++ have extra challenges compared to other programming languages in development. This also makes it more challenging when trying to implement modern DevOps, but not impossible. C/C++ has been overlooked and it’s time we update the tools to meet the needs of developers. What DevOps principles and practices are you implementing with your C/C++ projects?

    About the Author / Baruch Sadogursky

    Baruch Sadogursky is the Developer Advocate at JFrog. For a living he hangs out with JFrog’s tech leaders, writes code around the JFrog platform and its ecosystem, and then speaks and blogs about it all. He has been doing this for the last dozen years or so, and enjoys every minute of it. He also is a professional conference speaker on DevOps, Java and Groovy topics, and is a regular at the industry’s most prestigious events including JavaOne (where he was awarded a Rock Star award), DockerCon, Devoxx, DevOps Days, OSCON, Qcon and many others.  His full speaker history is available on Lanyrd. Follow him on Twitter @jbaruch on Twitter, or read his blogs here and here.

  • NodeSource, AppDynamics Ally for Node.js DevOps

    NodeSource, AppDynamics Ally for Node.js DevOps

    The prevalence of Node.js as the most widely deployed instance of JavaScript is putting a lot of pressure on DevOps teams to find ways to automate the management of Node.js applications. To provide the visibility needed to achieve that goal, NodeSource has announced it has integrated its N|Solid development environment with the application monitoring tools developed by AppDynamics.

    Pravin Halady, product manager for NodeSource, says one of the things that differentiates N|Solid, which is based on Node.js, most is the amount of telemetry data NodeSource is able to collect from Node.js applications. The alliance with AppDynamics provides a mechanism for DevOps teams to now tap into that data to better manage those applications alongside the panoply of existing applications they need to support and manage, says Halady.

    AppDynamics already supports Node.js. But Halady says the alliance with NodeSource provides deeper visibility into, for example, asynchronous activity. Advanced metrics can be used to augment the basic Node.js metrics that AppDynamics currently provides to better ensure service level agreements (SLAs) are both achieved and maintained, Halady says.

    Adoption of Node,js exploded across the enterprise once it became feasible several years ago to deploy JavaScript code on both the client and the server. That capability in many ways fulfilled the early promise of Java in the eyes of many developers. But DevOps teams have been slow to include support for JavaScript applications within their DevOps processes, mainly because of a lack of visibility. Now that the base of Node.js applications in the enterprise has reached a level of critical mass, tools vendors such as AppDynamics are looking to provide that visibility by expanding the scope of support they provide for Node.js.

    Halady says NodeSource chose to partner with AppDynamics in part because in the wake of AppDynamics being acquired by Cisco Systems, it’s clear that NodeSource needs to participate in the end-to-end visibility platforms that larger companies are starting to build. Cisco has already made significant investments in a Cisco Tetration analytics application in addition to committing to imbuing the IT infrastructure environment it provides with machine-learning algorithms. That data will then be combined with data about applications collected by AppDynamics to identify the source of any potential performance issue faster. NodeSource, adds Halady, will look to foster similar agreement with other providers of application monitoring tools.

    In the meantime, DevOps team can take heart in the fact the Node.js Foundation is making providing visibility into DevOps environments a higher priority. The number of Node.js applications in the enterprise is only expected to increase. There’s a high correlation between usage of Node.js and containers that collectively are being used to facilitate the development of microservices. As those microservices bgin to replace monolithic applications developed originally developed in languages such as Java, the size and scope of the DevOps challenge exponentially increases.

    Application development in the enterprise is going to be polyglot well into the next decade. Today there are more programming languages being actively used in the enterprise than any time in history. In fact, the days when IT operations could mandate what technologies developers can employ are long over.

    — Mike Vizard