『Legacy Coder Podcast』のカバーアート

Legacy Coder Podcast

Legacy Coder Podcast

著者: Legacy Coder Podcast
無料で聴く

このコンテンツについて

Adventures of a service oriented architect
エピソード
  • German Natural User Group Meeting in November 2018 – Legacy Coder Podcast #7
    2018/11/12
    On November 6th and 7th, the German Adabas and Natural User Group met in Darmstadt at Software AG’s headquarter to learn about new features in the October 2018 release. Let’s find out more in episode seven of the Legacy Coder Podcast. [podcast_ad] German Adabas and Natural User Group Meeting in November 2019 in Darmstadt Overview of the conference Ca. 60 attendees from all over Germany.Again, there were quite a few “young” Natural developers present including my colleague Markus who presented about NatLint, a linting tool for Natural.Currently, 40% of Natural customers work on LUW, 60% still work on the Mainframe. However, according to a different source, only 1/3 of customers are still on the Mainframe. Many different companies attended that run mission critical systems on Adabas/Natural.Hospitals, travel agencies, tax administration, police, banks, insurances, nuclear power plants, microchip factories Hot topics for many attendees Generational ChangeRehosting (e.g. Mainframe to LUW)Cost Reduction (e.g. zIIP)Testing Natural Applications Design Thinking workshop with Software AG’s Adam Egger Process for finding and defining the underlying problem we need a solution for. Come up with crazy ideas to get your brain moving. Introduce restrictions later to validate ideas for solutions.Topic: DevOps and Continuous Deployment with NaturalWhat are the main pain points Natural customers have with deploying Natural applications? Manual testing effortLots of different versions of tools, source, databases etc.Manual deployment effort Adabas gets a new TCP/IP interface Needed to make Adabas ready for containerization.You need a license for Entire Net-Work, if you need more than 4 connections.Non-Natural clients can also use the interface.The TCP/IP interface is as fast as the native IPC interface, if Adabas and Natural run on the same server.Adabas can now be administered via a REST interface. What’s new in Natural and NaturalONE? Due to “NaturalONE and only” Eclipse is now the single editor for programming Natural. Therefore, many missing features had to be added: access to Natural utilities, Error Messages, SYSEXT etc.NaturalONE is now licensed via Natural server. You don’t need any additional license for NaturalONE on the client, no matter how many developers you have.The Ant build files get additional options. Log output while uploading sources to NDV can now be reduced. Modules are cataloged in the correct order (Data Areas first etc.). API management with Adabas/Natural Customers can publish their existing Natural modules as services and re-use them in other applications. No new investments are needed and existing assets can be used.REST Enablement of Natural services is now possible via a restricted version of WebMethods Integration Server that’s shipped free of charge for customers that have an EntireX license.Incoming (e.g. calling a subprogram) and outgoing (e.g. external REST services) calls are possible with this solution.Generating services or service stubs is a matter of seconds and only takes a few clicks. Adabas and Natural on Docker Use Case: Run Natural RPC servers on a scalable infrastructure (Docker and Kubernetes).Adabas is not yet ready to be clustered, but Software AG is working on that. Static code analysis for Natural with NaturalONE and SonarQube My colleague Markus presented the results of his Bachelor’s Thesis about code quality in Natural.He wrote a so called “linter” that checks Natural code for certain code smells, bugs, and security vulnerabilities like unused variables, naming conventions, opening but not closing a work file etc.He uses the Natural parser that’s shipped with NaturalONE.The results of the linting can be viewed in SonarQube but also directly inside NaturalONE.You can also do a few refactorings in NaturalONE with the tool: rename variable, rename subroutine, introduce local variable. What’s next? April 2019: German Adabas and Natural User Group Meeting at ALTE OLDENBURGER AG in Vechta.June 2019: International User Group Conference in Riga. Call to Action Present at a User Group in your country!You don’t have to be “leading edge”! Other customers are also interested in seeing what other companies are doing with Adabas/Natural. Links Permalink for this Podcast episodeRSS feed for the Legacy Coder PodcastSoftware AG’s International User Groups#AdabasNatural2050 at TwitterOfficial Adabas Community Edition for DockerOfficial Software AG Natural Community Edition for DockerGerman Xing-Group: Arbeitskreis Adabas & NaturalSonarQube The post German Natural User Group Meeting in November 2018 – Legacy Coder Podcast #7 appeared first on SOA rocks!.
    続きを読む 一部表示
    38 分
  • Continuous Deployment with Natural – Legacy Coder Podcast #6
    2018/04/09
    After you have automated the build process for your application based on Software AG’s Adabas and Natural it’s time to take the next step and also deploy the changes to production after each push to Git! I’ll tell you how in the sixth episode of the Legacy Coder Podcast. [podcast_ad] Recap: Automating your build process with Continuous Integration Listen to Episode 2 of the Legacy Coder Podcast for an introduction on why you should automate everything from compilation to deployment.What is Continuous Integration? CI is a software development practice. Every developer integrates (i.e. merges) at least daily. Each integration is built and tested automatically.This leads to less integration problems and faster deployment cycles. What can go wrong when manually deploying to production (or the next stage)? Finding all the modules that you need to deploy.NAT0082 Invalid command, or Subprogram does not existNAT0936 Format/length conflict in parameterNAT0933 GDA time-stamp conflict Separating different features in the same modules from each other. Nested functions or other dependent modules can’t be compiled.Compile errors nobody cares about (anymore). Continuous Deployment with Blue/Green Deployments Basic Definitions What is Continuous Delivery? CD builds on top of CI and makes sure that the software can be released at any time. The deployment process has to be fully automated. You just need to push a button to deploy your software to the target environment. What is Continuous Deployment? CD goes even one step further and automatically deploys the software to production if all steps of the deployment pipeline pass. Finally, no more “release days”! What is a Deployment Pipeline? The deployment pipeline defines all the steps (called “stages”) necessary to build and deploy a new version of the software. Usually, there are stages for compiling, testing, packaging and deploying the application. What is Pipeline as Code? Instead of manually creating the deployment pipeline in a CI server like Jenkins you can define all the necessary steps in a domain specific language that the CI server can execute. All the information needed to build and deploy the application are now contained inside the repository. What are Blue/Green Deployments? To be able to deploy to production while users and batch jobs are still using the environment you need another target environment for the deployment process. If everything works as expected you can simply switch to the new environment. Advantages of a fully automated deployment process with blue/green deployments No more missing files, GDA timestamp conflicts, or format/length conflicts.Fast feedback (“Fail Fast”) for the developers, problems are visible immediately.You can reliably and easily roll back to a previous state if something breaks.Interactive tests in the production environment are possible.Running processes and interactive session won’t be disturbed.Deployments don’t need to be done in the evenings or on weekends.No more annoying tasks for the (expensive) software developers. Continuous Deployment for Software AG’s Natural These are the tools we use for our CI/CD process (most are Open Source). Git for version control.Gradle as a wrapper for SAG’s Ant script.Jenkins as a CI server.A custom Java program for compiling Natural on the target environment.NatUnit for unit testing.NaturalONE with additional plugins for NatUnit and staging.Redmine for documentation and communication with subject matter experts.Our former apprentice Jonas built a build lamp with a Raspberry Pi that shows the current state of our Natural build. Implementation at AO AO doesn’t have a single pipeline but 3 different ones for each individual branch: DEV, QA, and PROD. The core stages are identical, but they contain individual steps, e.g. for testing and deployment. DEV: only one target FUser that’s overwritten every time, QA: Blue/Green Deployment with instant switch, PROD: Blue/Green Deployment with nightly switch so the users aren’t disturbed. Before the pipeline can do its job, the developer needs to decide which modules to stage. This is done with Redmine where each changed module is assigned to an issue. An Eclipse plugin developed by ALTE OLDENBURGER searches for all modules assigned to a given issue number and stages them. After a push to Git the pipeline starts. The first stage of the pipeline checks out the latest version of the Natural sources from Git.After that the target Fuser gets erased and recreated from scratch.We use SAG’s Ant script to upload the sources to the target server.We do a full build every time, not an incremental build. Compile errors are formatted as JUnit results so they can be displayed inside Jenkins.We don’t use SAG’s script for that because it doesn’t follow the StepLib chain (for whatever reason). After the compilation additional test data for testing legacy modules that rely on a certain database state are imported...
    続きを読む 一部表示
    50 分
  • What is Legacy Code? – Legacy Coder Podcast #5
    2018/01/29
    This podcast is called “Legacy Coder” but what exactly is legacy code? I talk about my definition of the term in the fifth episode of the Legacy Coder Podcast. [podcast_ad] Legacy Code? What is Legacy Code? Definition by Michael Feathers: “Code without tests.”Code of a certain age. Brown field instead of green field. “Old” languages or platforms. Natural, COBOL, ABAP, Mainframes.But also J2EE. Code that’s hard to change or maintain. You can write “new” legacy code.You can also write legacy code in modern languages like Java or C#. Big Balls of Mud, Monoliths. Duplicated code.Hard to separate into individual pieces of functionality for reuse.Different concerns are bundled together (see title image). Code that lacks certain quality characteristics. Not readable, not modularized, not consistent, hard to understand, deeply nested, similar things are done differently, no patterns. How can you get rid of legacy code? Why would you want to get rid of the code in the first place? “Don’t forget – having legacy software is often a sign of success. Your business was successful to last long enough for your software to become legacy.” [Sam Newman]High maintenance costs, aging/retiring workforce, unable to implement new requirements. A big rewrite is almost never the answer. But sometimes.Gradually improve the quality of your codebase. Introduce tests, e.g. compare log files before/after. Integrate the legacy code base into your modern architecture, e.g. with webMethods and EntireX for Adabas/Natural applications. A short piece of Legacy Code in (pseudo) Natural Here’s how many of the old Natural modules I encounter in my day job look like: DEFINE DATA LOCAL USING DDMVIEW END-DEFINE READ IMPORTANT-DDM BY SUPERDESCRIPTOR IF IMPORTANT-DDM.FIELD EQ 1 ADD 100 TO IMPORTANT-DDM.FIELD UPDATE END TRANSACTION ELSE ESCAPE TOP END-IF INPUT USING MAP 'OUTPUT' END-READ END Database access, business logic, and the presentation of the results to the user (UI) are all bundled together into a single module. This becomes a maintenance nightmare quickly and is very hard to test because the individual concerns can’t be separated for testing. This module could be split up into 5 different modules that only do one thing, can therefore be reused in different scenarios, and can easily be (unit) tested: Reading the database (e.g. subroutine READ-DATA)Processing the data, a.k.a. your “business logic” (e.g. subroutine PROCESS-DATA)Saving data to the database (e.g. subroutine SAVE-DATA)Showing the results to the user (e.g. subroutine DISPLAY-DATA)Orchestrating the individual steps to implement the whole use case (the main program) Here’s how the refactored main program would look like: DEFINE DATA LOCAL USING ARRDATA END-DEFINE PERFORM READ-DATA ARRDATA PERFORM PROCESS-DATA ARRDATA PERFORM SAVE-DATA ARRDATA PERFORM DISPLAY-DATA ARRDATA END Recommended reading (and hearing) In his book Working Effectively with Legacy Code* Michael Feathers shows different ways of introducing automated tests into a legacy code base. He uses C++ in his examples but the underlying ideas can be applied to any other programming language, too. * Robert C. Martin wrote my all time favourite book for software developers: Clean Code*. If you haven’t read it already, grab a copy now and read it from front to back! No matter what programming language you’re using, you will definitely find lots of ways to improve your existing code in here. * In the very first episode of this podcast I talked about how to unit test your Natural application. In my opinion, that’s a very important step in modernizing a legacy code base. Links Permalink for this Podcast episodeRSS feed for the Legacy Coder PodcastMillennials and Mainframes in 2018 and Beyond The post What is Legacy Code? – Legacy Coder Podcast #5 appeared first on SOA rocks!.
    続きを読む 一部表示
    36 分
まだレビューはありません