Podcasts about jvms

An airhacks.fm conversation with Volker Simonis (@volker_simonis) about: discussion about carnivorous plants, explanation of how different carnivorous plants capture prey through movement, glue, or digestive fluids, Utricularia uses vacuum to catch prey underwater, SAP's interest in developing their own JVM around Java 1.4/1.5 era, challenges with SAP's NetWeaver Java EE stack, difficulties maintaining Java across multiple Unix platforms (HP-UX, AIX, S390, Solaris) with different vendor JVMs, SAP's decision to license Sun's HotSpot source code, porting Hotspot to PA-RISC architecture on HP-UX, explanation of C++ interpreter versus Template interpreter in Hotspot, challenges with platform-specific C++ compilers and assembler code, detailed explanation of JVM internals including deoptimization, inlining, and safe points, SAP's contributions to openJDK including PowerPC port, challenges getting SAP to embrace open source, delays caused by Oracle's acquisition of Sun, SAP's extensive JVM porting work across multiple platforms, development of SAP JVM with additional features like profiling safe points, creation of SAP Machine as an open-source OpenJDK distribution, explanation of Java certification and trademark restrictions, Hotspot Express model allowing newer VM components in older Java versions, Volker's move to Amazon Corretto team after 15 years at SAP, brief discussion of ABAP versus Java at SAP, Volker's recent interest in GraalVM and native image technologies Volker Simonis on twitter: @volker_simonis

The big story this week is the continued fallout from Salt Typhoon. The US government is feeling the heat from the exposure of so many telecom companies and they want answers. FCC Chairwoman Jessica Rosenworcel has announced a proposed set of rules that would require companies that participate in the Communications Assistance for Law Enforcement Act (CALEA) to have a yearly requirement to certify their cybersecurity risk management plans to prevent hackers from getting in. Senator Ron Wyden of Oregon has gone even further and proposed a draft bill to secure telecom networks with the FCC implementing specific requirements instead of simple certifications. 0:00 - Welcome to the Rundown 1:21 - StormForge Rightsizes JVMs 4:11 - Cisco Switches Vulnerable to Verification Exploit 7:29 - VMware by Broadcom Welcomes Partners Back to the Top 11:16 - Google Stabilizes Quantum Qubit for an Hour 16:49 - Open Source Flooded by Bad AI Bug Reports 21:52 - Salt Typhoon Storms the Government 32:57 - The Weeks Ahead 34:19 - Thanks for Watching Hosts: Tom Hollingsworth: https://www.twitter.com/NetworkingNerd Stephen Foskett: https://www.twitter.com/SFoskett Follow Gestalt IT Website: https://www.GestaltIT.com/ Twitter: https://www.twitter.com/GestaltIT LinkedIn: https://www.linkedin.com/company/Gestalt-IT #Rundown, #SaltTyphoon, #JVMs, #Cybersecurity, #QuantumQubit, #OpenSource, @VMware, @Broadcom, @Cisco, @StormforgeIO, @Google, @GoogleCloud,

An airhacks.fm conversation with Roni Dover (@doppleware) about: previously Roni on airhacks.fm "#252 BDD: Bug Driven Development vs. Continuous Observability", discussion about the Java community and its focus on innovation, Digma and Java, Digma's growth and user feedback, observability as a tool for early issue detection and better code design, the importance of continuous observability and reducing mental effort, Digma's elevator pitch and data science approach, the changing testing pyramid and the benefits of test containers, "#103 Unit Testing Considered Harmful", the cost and value of different types of tests, optimizing lambda costs and performance, linking System Tests to traces from quarkus JVMs, Digma's architecture and deployment options, recent features and improvements in Digma, the impact of observability on productivity and shorter feedback loops, AWS Lambda Power Tuning, the limitations and potential of large language models (LLMs) in generating tests and code, the importance of understanding the client and writing maintainable code, the challenges of complex code generated by LLMs, the potential of feeding runtime data to LLMs for code generation and optimization, the Java community's vibrant and innovative nature Roni Dover on twitter: @doppleware

An airhacks.fm conversation with Gil Tene (@giltene) about: starting with hacking adventure games on a VAX-11/780 as a teenager, building computers and making money in high school, providing access to Usenet, early programming experiences with Pascal and C/C++, moving to Silicon Valley in 1994 and witnessing the rise of Java, working on fault-tolerant computer systems at Stratus Computer, co-founding Azul Systems and developing the Vega appliances to virtualize Java applications, the technical details of how Vega appliances worked by running JVMs on specialized hardware, the evolution of Azul to focus on pure software solutions such as Zing and supporting openJDK, Gil's continued involvement in coding and maintaining open-source libraries Gil Tene on twitter: @giltene

An airhacks.fm conversation with Sascha Moellering (@sascha242) about: Schneider CPC, starting programming with C-16, enjoying Finger's Malone, upgrade to C-128, playing Turrican, Manfred Trenz created Turrican and R-Type, publishing a Pommes Game, programming on Amiga 1200, math in game development, implementing a painting application, walking through C pointer and reference hell, from C to Java 1.0 on a Mac 6500 with 200MHz, using Metrowerks JVM, using CodeWarrior, CodeWarrior vs. stormc, Java is a clean language, working on SpiritLink, using Caucho Resin, starting at Accenture, from Accenture to Softlab, building a PaaS solution with JBoss for Allianz, managing hundreds of JVMs with a pizza team, implementing a low latency marketing solution with Vert.x, starting at Zanox, an episode with Arjan Tijms "#184 Piranha: Headless Applets Loaded with Maven", starting at AWS as Account Solution Architect, using quarkus on lambda as a microservice, using POJO asynchronous lambdas, EJB programming restrictions and Lambdas, airhacks discord server, Optimize your Spring Boot application for AWS Fargate, Reactive Microservices Architecture on AWS, Field Notes: Optimize your Java application for Amazon ECS with Quarkus, Field Notes: Optimize your Java application for AWS Lambda with Quarkus, How to deploy your Quarkus application to Amazon EKS, Using GraalVM to Build Minimal Docker Images for Java Applications Sascha Moellering on twitter: @sascha242

Java Virtual Machines (JVMs) impact Apache Kafka® performance in production. How can you optimize your event-streaming architectures so they process more Kafka messages using the same number of JVMs? Gil Tene (CTO and Co-Founder, Azul) delves into JVM internals and how developers and architects can use Java and optimized JVMs to make real-time data pipelines more performant and more cost effective, with use cases.Gil has deep roots in Java optimization, having started out building large data centers for parallel processing, where the goal was to get a finite set of hardware to run the largest possible number of JVMs. As the industry evolved, Gil switched his primary focus to software, and throughout the years, has gained particular expertise in garbage collection (the C4 collector) and JIT compilation. The OpenJDK distribution Gil's company Azul releases, Zulu, is widely used throughout the Java world, although Azul's Prime build version can run Kafka up to forty-percent faster than the open version—on identical hardware. Gil relates that improvements in JVMs aren't yielded with a single stroke or in one day, but are rather the result of many smaller incremental optimizations over time, i.e. "half-percent" improvements that accumulate. Improving a JVM starts with a good engineering team, one that has thought significantly about how to make JVMs better. The team must continuously monitor metrics, and Gil mentions that his team tests optimizations against 400-500 different workloads (one of his favorite things to get into the lab is a new customer's workload). The quality of a JVM can be measured on response times, the consistency of these response times including outliers, as well as the level and number of machines that are needed to run it. A balance between performance and cost efficiency is usually a sweet spot for customers.Throughout the podcast, Gil goes into depth on optimization in theory and practice, as well as Azul's use of JIT compilers, as they play a key role in improving JVMs. There are always tradeoffs when using them: You want a JIT compiler to strike a balance between the work expended optimizing and the benefits that come from that work. Gil also mentions a new innovation Azul has been working on that moves JIT compilation to the cloud, where it can be applied to numerous JVMs simultaneously.EPISODE LINKSA Guide on Increasing Kafka Event Streaming PerformanceBetter Kafka Performance Without Changing Any CodeWatch the video version of this podcastKris Jenkins' TwitterStreaming Audio Playlist Join the Confluent CommunityLearn more with Kafka tutorials, resources, and guides at Confluent DeveloperLive demo: Intro to Event-Driven Microservices with ConfluentUse PODCAST100 to get an additional $100 of free Confluent Cloud usage (details)   

Over the years we learned how to optimize the performance of our JVMs, our CLRs or our databases instances by tweaking settings around heap sizes, garbage collection behavior or connection and thread pools.As we move our workloads to k8s we need to adapt our optimization efforts as they are new nobs to turn. We need to factor in how resource and request limits on pods impact your application runtimes that run on your clusters. Out of memory problems are all of a sudden no longer just depending on the java heap size alone!To learn more about k8s optimization best practices we have invited Stefano Doni, CTO of Akamas. Stefano walks us through key learnings as the team at Akamas has helped organizations optimize the performance, resiliency and cost of their k8s workloads. You will learn about proper memory settings, CPU throttling and how to start saving costs as you move more workloads to k8s. To learn more about Akamas go here: https://www.akamas.io/If you happen to be at KubeCon 2022 in Detroit make sure to visit their boothShow Links:Stefano on Linkedin: https://www.linkedin.com/in/stefanodoni/A Guide to Autonomous Performance Optimization with Dynatrace and Akamas: https://www.youtube.com/watch?v=i7MuEjeOvX0

Akka is a toolkit for building scalable, resilient, and resource-efficient applications on the JVM in Java or Scala. With Akka, you can build applications composed of a single JVM to a fleet of JVMs distributed across a cluster of servers. We will tour Akka from the humble actor up to the systems level and how Akka is used by some of the world's most recognized brands to build distributed clustered systems composed of clusters within clusters for optimal customer experiences. 

Bruno Borges joins Scott Hanselman to talk about Java development with Microsoft. Like many of our customers, Microsoft is a Java shop with lots of systems that rely on Java and its ecosystem. We employ thousands of Java engineers, run millions of JVMs, and process terabytes of data every day, to deliver the services everyone loves. We also built tools and services specifically designed for Java developers and applications. Chapters 00:00 - Introduction 02:53 - Java usage at Microsoft 04:55 - Microsoft Build of OpenJDK 07:18 - Modern Java at Microsoft (Java 17) 09:11 - Microsoft tools for Java 12:53 - Build on your terms 14:19 - Build or migrate Java apps 16:19 - Wrap-up Recommended resources Java on Azure Azure is the home for your enterprise Java applications Microsoft Build of OpenJDK Create a Pay-as-You-Go account (Azure) Create a free account (Azure) Connect Twitter: Scott Hanselman | @SHanselman Twitter: Bruno Borges | @BrunoBorges Twitter: Azure Friday | @AzureFriday

Bruno Borges joins Scott Hanselman to talk about Java development with Microsoft. Like many of our customers, Microsoft is a Java shop with lots of systems that rely on Java and its ecosystem. We employ thousands of Java engineers, run millions of JVMs, and process terabytes of data every day, to deliver the services everyone loves. We also built tools and services specifically designed for Java developers and applications. Chapters 00:00 - Introduction 02:53 - Java usage at Microsoft 04:55 - Microsoft Build of OpenJDK 07:18 - Modern Java at Microsoft (Java 17) 09:11 - Microsoft tools for Java 12:53 - Build on your terms 14:19 - Build or migrate Java apps 16:19 - Wrap-up Recommended resources Java on Azure Azure is the home for your enterprise Java applications Microsoft Build of OpenJDK Create a Pay-as-You-Go account (Azure) Create a free account (Azure) Connect Twitter: Scott Hanselman | @SHanselman Twitter: Bruno Borges | @BrunoBorges Twitter: Azure Friday | @AzureFriday

An airhacks.fm conversation with Benjamin Marwell (@bmarwell) about: Recent airhacks.fm episode with Ben: "#180 Trombones, Java, Large Scale WebSphere Liberty Deployments and 50.000 JVMs in Production" security library and authentication and authorization framework, using Apache Shiro for CLI applications, the Apache Shiro security manager, the Shiro realm is the source of information for login credentials validation, the "hello, world" Shiro application requires a single dependency, WebListener is used for authentication, the killer use cases of Apache Shiro are permissions, a role comprises multiple permissions, wildcard permissions are a colon-separated list, comparing Shiro to AWS permissions, Sonatype Nexus is using Shiro, using multiple realms at the same time with Apache Shiro and realm chaining, Shiro means Castle in Japanese, realms in Shiro and Jakarta EE, Apache Shiro Jakarta EE integration, Shiro is easier to use than JAAS or jaspic, Stormpath was started by Apache Shiro committers, MicroProfile secret injection with Apache Shiro, Jakarta Security Compatible Implementation: Soteria, Benjamin Marwell on twitter: @bmarwell, Benjamin's blog: https://blog.bmarwell.de

An airhacks.fm conversation with Benjamin Marwell (@bmarwell) about: C64 with 3.5 years, enjoying Pitstop, Pharaoh's Curse and Lady Tut, starting to program in Basic from a manual, modifying the game source, starting with Pascal and Visual Basic, storing the universe into an Excel file, automating a space game with Delphi, implementing a web crawler in Delphi, the "King of Galaxy Wars" and OGame, playing trombone in the army, starting at Finanzinformatik the datacenter for the German saving banks, studying in Hameln business informatics and learning Java 6, programming with 31-bit computing with IBM assembly, starting with 0xCAFEBABE, switching to monitoring department and using BMC Patrol, the web and application servers department, deploying a few hundred applications to WebSphere Liberty, using Apache FreeMarker to generate 'WebSphere Liberty configuration, microservice deployment with WebSphere Liberty, Apache Maven and Apache Shiro Committer, building JavaFX application with jlink, contributing to JLink, creating sprites for Legend of Zelda, podcasts with Robert Scholte "#25 Maven Commitment" and "#28 More Conventions with Maven.next", using Apache Shiro for permission checks, combining security with Bean Validation - a podcast with David Blevins "#156 Bash, Apple and EJB, TomEE, Geronimo and Jakarta EE", Nexus is using Apache Shiro Benjamin Marwell on twitter: @bmarwell, Benjamin's blog: https://blog.bmarwell.de

2021-04-20 Weekly News - Episode 100Watch the video version on YouTube at https://youtu.be/1GOdVcQgfyc Hosts: Luis Majano - Owner of Ortus SolutionsGavin Pickin - Software Consultant for Ortus SolutionsEric Peterson - Senior Developer for Ortus SolutionsBrad Wood - Software Consultant for Ortus SolutionsThanks to our Sponsor - Ortus SolutionsThe makers of ColdBox, CommandBox, ForgeBox, TestBox and almost every other Box out there. A few ways  to say thanks back to Ortus Solutions:- Like and subscribe to our videos on youtube. - Sign up for a free or paid account on CFCasts, which is releasing new content every week- Buy Ortus’s new Book - 102 ColdBox HMVC Quick Tips and Tricks on GumRoadPatreon SupportWe have 36 patreons providing 83% of the funding for our Modernize or Die Podcasts via our Patreon site: https://www.patreon.com/ortussolutions. If you love our podcasts and all we do for the #coldfusion #cfml community considers chipping in, we are almost there!https://www.ortussolutions.com/blog/we-need-your-help News and EventsWe made it to 100 Episodes!!So to thank our supporters, we decided to do a little raffle giveaway.To enter the raffle, answer 5 Ortus Trivia questions on the google form, and we’ll be giving away 5 boxlife swag packages.To those watching live in chat, if you complete the form today, you’ll go into the draw for the first 2, and then everyone until we record next week’s episode to have a chance at the remaining 3https://forms.gle/SKFLZHbQR1g2caKQ9 Congrats to Mark Takata, the new Adobe CF Technical EvangelistLet’s all offer a hardy welcome to our new Adobe ColdFusion Technical Evangelist, Mark Takata.  It’s great to see Adobe creating (recreating) that position.https://coldfusion.adobe.com/2021/04/congrats-mark-takata-new-adobe-cf-evangelist/ ColdBox 6.4.0 Released - Welcome to the land of Scheduled TasksColdBox 6.4.0 is more of a major than a minor release due to the amount of work we have done to bring you one of the most revolutionary features of this framework: Scheduled Tasks.  https://coldbox.ortusbooks.com/intro/release-history/whats-new-with-6.4.0 TLSv1 and TLSv1.1 Disabled by Default in Java after April 20 2021The OpenJDK Crypto Roadmap states that TLSv1 and TLSv1.1 will be disabled in OpenJDK releases by default after April 20, 2021. I assume this change also applies to Oracle, and all the JVMs that are derived from OpenJDK.https://www.petefreitag.com/item/916.cfm Spreadsheet Library v2.18.0 releasedFinally added support for header/footer images, also external/internal hyperlinkshttps://github.com/cfsimplicity/lucee-spreadsheet Adam Cameron is joining the CFML Slack again - be warned :)A week or so ago I started to talk to Easy Direct Debits Ltd, and this has worked out well for me (and hopefully them…. I'm starting today - I'll clock-on in about 15min - as "Technical Team Lead". it's with a CFML shop. I'm a wee bit rusty with my CFML, hence giving myself some exercises this last week. And my boss has given me more to do today. Ha. I will also be maintaining my focus on TDD, automated testing, and code quality. This is a big part of my role there. And this is excellent.I'll be rejoining the CFML Slack community shortly. Apologies in advance to everyone there ;-)https://blog.adamcameron.me/2021/04/why-ive-been-looking-at-cfml-again.html Need testing for CommandBox 5.3.0 before releaseDevelopment is closed down for CommandBox 5.3.0 and just waiting on some final testing before I release.  Please give it a look now and make sure it's kosher.https://downloads.ortussolutions.com/#/ortussolutions/commandbox/5.3.0-alpha/ #CFML #ColdFusionhttps://twitter.com/bdw429s/status/1384544487591063556 ICYMI - VS Code Live Stream - VS Code Notebooks: A Deep DiveThursday 15th at 8am PSTVS Code is adding Notebooks as a core concept in the API, on top of which extensions like the Jupyter Notebook are being built. Join Tanha to explore the capabilities of Notebooks in VS Code. We'll also look under-the-hood at the new APIs to build custom notebooks and visualizers, and how you can use them to build new extensions.https://code.visualstudio.com/livestream?WT.mc_id=devcloud-18509-cxa Recording: https://www.youtube.com/watch?v=D-AXZZDTQhM Adobe Webinar Series - API Creation and ManagementNext Webinar:  4/28/21ColdFusion Developers, do you want a first hand look at publishing APIs securely and at scale? Then mark your calendars for Brian Sappey’s upcoming webinars! This seven-part series will give you a 360 degree view of the API Manager and teach you how to build RESTful APIs with Adobe ColdFusion. Everything from securing, publishing and monitoring APIs, will be covered with hands-on examples, and easy discussions.Dates: 3/24/21, 3/25/21, 4/28/21, 4/29/31, 5/12/21, 5/13/21, 5/24/21Information: https://coldfusion.adobe.com/2021/03/webinar-series-api-creation-management/ Registration: https://coldfusion-api-management-solution.meetus.adobeevents.com/?fbclid=IwAR2q7aEI9u1ibBKrneeDvAhKWWW7V78bB_P1rTzWAh8x4e20q68gXLeMVrMRecordings: https://t.co/ZQc637BSkv ICYMI - Online CF Meetup - "To the future with cbFutures!", with Luis MajanoThursday, April 15, 20215:00 PM to 6:00 PM CDTIn this session we will explore the asynchronous and parallel programming constructs built into the ColdBox 6 Async Package. Java has supported a robust and functional approach to asynchronous programming since JDK8 and now it is available to us all in the Coldfusion (CFML) ⚡ World! To the future!https://www.meetup.com/coldfusionmeetup/events/277112459/Recording: https://cfcasts.com/series/ortusian-talks/videos/to-the-future-with-cbfutures!-with-luis-majano Ortus Webinar - Building modern web apps with ContentBox Modular CMS with Luis MajanoApril 23, 2021 Time: 11:00 AM CTContentBox is a professional open source modular content management system powered by ColdBox HMVC and ColdFusion. In this session, led by Luis Majano, we will get an overview of this CMS platform and how you can leverage it to not only deliver content based applications, but any modern web application thanks to its powerful headless API and ColdBox services.https://www.ortussolutions.com/events/webinars Reminder: New Book from Luis Majano 102 ColdBox HMVC Quick Tips and TricksNow Available on Gumroad - $29http://gum.co/coldbox-tips CFCasts Content Updateswww.cfcasts.com CFCasts site updates!Just Released- Ortusian Talks    - To the Future with cbFutures with Luis Majano https://cfcasts.com/series/ortusian-talks/videos/to-the-future-with-cbfutures!-with-luis-majano - CommandBox Zero to Hero (https://cfcasts.com/series/commandbox-zero-to-hero)    - Additional Server Information    - JVM and JavaComing up soon- More CommandBox Zero to Hero- More What’s new with ColdBox 6- Up and Running with Quick- LogBox 101- Using DocBoxSend your suggestions at https://cfcasts.com/supportConferences and TrainingICYMI - VueConf - Virtual Vue LoveApril 14th - Online - FreeHosted by Evan YouLive Video with Chat Q&A with speakersAttendee Lightning TalksLive DJVirtual Partyhttp://vueconf.us/ Videos coming soon on https://www.vuemastery.com/conferences/ RedisConf 2021Virtual: Apr 20-21 TODAY AND TOMORROWRediscover the power of real-time data. Join us at RedisConf 2021 to hear from the Redis community, customers, and industry experts. Dive into the latest product experiences, get hands-on training, network with other Redis pros, and show off your skills by participating in a $100,000 hackathon.https://redislabs.com/redisconf/ Atlassian Teams 21Apr 28-30 Better teams starts with being better teammates. Check out Atlassian’s vision for Team 2021, formerly Summit.https://events.atlassian.com/team21 AWS Summit Online - AmericasMay 12-13Online and Free AWS Summit Online is designed for developers and IT professionals looking to learn how to build and innovate at scale using AWS Cloud. Hear the very latest from AWS executives, attend breakout sessions featuring customer stories, and engage with AWS experts to get your questions answered. Enhance your skills with hands-on labs and workshops, learn from inspiring demos, and discover what AWS and our Partner Solutions can do for your business.This free online conference is designed to educate you about AWS services; and help you design, deploy, and operate infrastructure and applications.https://aws.amazon.com/events/summits/online/americas/ DockerConMay 27th 2021DockerCon 2021 is a free, one-day virtual event that is a unique experience for developers and development teams who are building the next generation of modern applications. If you want to learn about how to go from code to cloud fast and how to solve your development challenges, DockerCon 2021 offers engaging live content to help you build, share and run your applications.Call for Speakers open until Midnight April 1sthttps://www.docker.com/dockercon-live/2021 Ortus Workshops - Dates coming soonMore Workshops dates to come- CommandBox Zero to Hero- ColdBox Zero to Hero- ColdBox Hero to SuperHeroOrtus’s Possible Conferences for 2021Dates subject to changeDue to Online conference overload, we are thinking about not expanding the number of events, but more content in more timezones with a different format.ITB - Developer Week Style?? - (please be in-person!!!)With some European Timezone Friendly slots from our European Community MembersSeptember 2021Call for speakers coming soonITB LatamDecember 2021More conferencesNeed more conferences, this site has a huge list of conferences for almost any language/community.https://confs.tech/CFML Is now on the list - https://confs.tech/conferences/new Blogs, Tweets and Videos of the Week Blog - Luis Majano - Ortus Solutions - ColdBox 6.4.0 Released - Welcome to the land of Scheduled TasksToday we released ColdBox v6.4.0 but it feels more like a major release than a minor one. We are introducing tons of new features in this release, especially our anticipated: ColdBox Scheduled Tasks feature set.https://www.ortussolutions.com/blog/coldbox-640-released-welcome-to-the-land-of-scheduled-tasks Blog - Ben Nadel - Using The URL As The Source Of Truth During Search In AngularJS 1.2.22As of late, I've been building-out a number of Search-style pages at InVision in our legacy AngularJS platform. These search pages tend to include an open-ended keyword search in addition to several discrete filters that can be applied in parallel. As I've been wiring these pages together, I've been using the URL as the "source of truth" for the search state. This certainly isn't the first time that I've talked about using the URL to store state during search; but, I think what makes this demo interesting is that all of the additional discrete filters are powered by HREF attributes that need to be updated as the state of the search evolves. As such, I wanted to put together a small demo in AngularJS 1.2.22.https://www.bennadel.com/blog/4029-using-the-url-as-the-source-of-truth-during-search-in-angularjs-1-2-22.htm Blog - Adam Cameron - Why I've been looking at CFML again recentlyA week or so ago I started to talk to Easy Direct Debits Ltd, and this has worked out well for me (and hopefully them…. I'm starting today - I'll clock-on in about 15min - as "Technical Team Lead". it's with a CFML shop. I'm a wee bit rusty with my CFML, hence giving myself some exercises this last week. And my boss has given me more to do today. Ha. I will also be maintaining my focus on TDD, automated testing, and code quality. This is a big part of my role there. And this is excellent.I'll be rejoining the CFML Slack community shortly. Apologies in advance to everyone there ;-)https://blog.adamcameron.me/2021/04/why-ive-been-looking-at-cfml-again.html Blog - Adam Cameron - How (not to) apply a feature toggle in your codeI've had these notes lying around for a while, but they were never interesting enough (to me) to flesh out into a full article. But feature toggling has been on my mind recently (OK, it's because of Working Code Podcast's coverage of same: "018: Feature Flags (Finally!)"), so I figured I'll see what I can do with it.BTW you don't need to listen to the podcast first. It doesn't contextualise anything I say here (well maybe one thing down the bottom), it was just the catalyst for the decision to write this up. But go listen anyway. It's cool.https://blog.adamcameron.me/2021/04/how-not-to-apply-feature-toggle-in-your.html Blog - Adam Cameron - Adding TestBox, some tests and CFConfig into my Lucee containerOn Fri/Sat (it's currently Sunday evening, but I'll likely not finish this until Monday now) I started looking at getting some CFML stuff running on Lucee in a Docker container. If you like you can read about that stuff: "Using Docker to strum up an Nginx website serving CFML via Lucee" and "Repro for Lucee weirdness". This article resumes from where I got to with the former one, so that one might be good for some context.Full disclosure: I spent all today messing around in a spike: experimenting with stuff, and now am finally happy I have got something to report back on, so I have rolled-back the spike and am going to do the "production" version of it via TDD again. I just say this - and it's not the first time - if yer doing TDD it's OK to spike-out and do a bunch of stuff to work out how to do things without testing every step. Especially if yer like me and start from a position of having NFI what you need to do. However once yer done: revert everything and start again, testing-first as you go. What I've done here is save all my stuff in a branch, and now I'm looking at a diff of that and main, as a reference to what I actually need to do, and what is fluff that represents a dead end, or something I didn't need to do anyhow, or whatever.https://blog.adamcameron.me/2021/04/adding-testbox-some-tests-and-cfconfig.html Blog - Ben Nadel - Returning Search Filters Along With Search Results In Lucee CFML 5.3.7.47At InVision, I'm building an experimental search page for a customer that has an abnormally large amount of data. And, as I've been working on this feature, I started using a technique that I've come to really like: returning the search filters (ie, the input parameters) alongside the search results in the response payload for the client-side AJAX request. I'm finding this to be especially helpful when I have a higher chance of overlapping AJAX responses. As such, I thought I would share a quick example in Lucee CFML 5.3.7.47.https://www.bennadel.com/blog/4028-returning-search-filters-along-with-search-results-in-lucee-cfml-5-3-7-47.htm Blog - Adam Cameron - Using Docker to strum up an Nginx website serving CFML via LuceeOK so this is not the blog article I expected to be writing, had you asked me two weeks ago. But here we are. I'll go into the reason why I'm doing this a bit later.This will be a CFML-oriented version of the "VueJs/Symfony/Docker/TDD series":- Nginx website.- Proxying for Lucee as the CFML-processing application layer.- Running inside Docker containers.- TDD the whole enterprise.If I have time (and any will-to-live remaining), I will add this lot into the mix:- Work out how Forgebox works, which seems to be CFML's equivalent of Composer / NPM- Use that to install Testbox (CFML-based Jasmine-ish testing framework)- And also install CFWheels, a CFML-based framework akin to Ruby on Rails.https://blog.adamcameron.me/2021/04/using-docker-to-strum-up-nginx-website.html Blog - Adam Cameron - Repro for Lucee weirdnessI'm just having to install Lucee on my machine, and have got its Docker version up and running, but I'm seeing some weirdness with it. I was just wondering if someone else could take the time to try a quick experiment for me, and report back.The comments are where the real gold is with this.https://blog.adamcameron.me/2021/04/repro-for-lucee-weirdness.html Blog - Pete Freitag - TLSv1 and TLSv1.1 Disabled by Default in Java after April 2021The OpenJDK Crypto Roadmap states that TLSv1 and TLSv1.1 will be disabled in OpenJDK releases by default after April 20, 2021. I assume this change also applies to Oracle, and all the JVMs that are derived from OpenJDK.https://www.petefreitag.com/item/916.cfm Blog - Charlie Arehart - CF Portal - Congrats to Mark Takata, the new Adobe CF Technical EvangelistLet’s all offer a hardy welcome to our new Adobe ColdFusion Technical Evangelist, Mark Takata.  It’s great to see Adobe creating (recreating) that position.https://coldfusion.adobe.com/2021/04/congrats-mark-takata-new-adobe-cf-evangelist/ CFML JobsSeveral positions available on https://www.getcfmljobs.com/Listing over 70 ColdFusion positions from 44 companies across 47 locations in 5 Countries since Dec 1st.0 new jobs this weekForgeBox Module of the WeekFRAPISDK by Brad WoodFusionReactor API SDK. A simple CFML library for some common FRAPI functions. I have a CFC I've used in a few projects now including CommandBox & REST-over-STOMP that provides a simple wrapper to the Fusion Reactor FRAPI java classes. I've finally stuck it in a package on ForgeBox. Doesn't require ColdBox.https://www.forgebox.io/view/FRAPISDK VS Code Hint Tips and Tricks of the WeekWakaTimeWakaTime is an open source VS Code plugin for metrics, insights, and time tracking automatically generated from your programming activity.https://marketplace.visualstudio.com/items?itemName=WakaTime.vscode-wakatime Thank you to all of our Patreon SupportersThese individuals are personally supporting our open source initiatives to ensure the great toolings like CommandBox, ForgeBox, ColdBox,  ContentBox, TestBox and all the other boxes keep getting the continuous development they need, and funds the cloud infrastructure at our community relies on like ForgeBox for our Package Management with CommandBox. You can support us on Patreon here https://www.patreon.com/ortussolutions- Bronze Packages and up, now get a ForgeBox Pro and CFCasts subscriptions as a perk for their Patreon Subscription.- All Patreon supporters have a Profile badge on the Community Website- All Patreon supporters have their own Private Forum access on the Community WebsiteDon BellamyEric HoffmanDavid BelangerGary KnightGiancarlo GomezJonathan PerretMario RodriguesJeffry McGee - Sunstar MediaJohn Wilson - Synaptrix Yogesh MathurJoseph LamoreeBen NadelBrett DeLineCarl Von StettenCharlie ArehartDan CardDaniel GarciaDidier LesnickiEdgardo CabezasJan JannekJason DaigerJeff McClainJeremy AdamsJonas ErikssonJordan ClarkKai KoenigLaksma TirtohadiLeon SeremelisMatthew DarbyMatthew ClementeMingo HagenPatrick FlynnRoss PhillipsScott SteinbeckStephany MongeSteven KlotzYou can see an up to date list of all sponsors on Ortus Solutions' Websitehttps://ortussolutions.com/about-us/sponsors ★ Support this podcast on Patreon ★

Dans cet épisode désordonné mais complet, Antonio, Guillaume et Emmanuel parlent de JVM sur Kubernetes, des datacenters OVH, de Spring Native, de Flutter, de Saga, d’Open Source et de salaire. Enregistré le 12 mars 2021 Téléchargement de l’épisode LesCastCodeurs-Episode–251.mp3 News Infrastructure Un data center d’OVH en feu Strasbourg data center entierement détruit recommande d’activer les protocoles de disaster recovery impacte aussi d’autres data centers : SBG1, SBG3 et SBG4 (electricite coupée et une partie des salles serveurs) Autre article couvrant l’évènement 3,5 millions de sites down, les backups aussi? 18% des adresses IP attribuées à OVH remedarrage (sauf SBG2) la semaine prochaine touche la partie hosted private cloud quelques jours avant annonce de mise en bourse Améliorer le temps de démarrage des JVMs sur Kubernetes JIT etc, temps de demarrage relativement lent rajouter des pods et faire deu deployment graduel (3x coût) script de chauffe avec le readiness probe utilisant initialDelaySeconds mais pas d’amelioration massive (rejoue les URLs de prod) et ralentit l’auto scaling changer les heuristiques de la JVM : 2x CPU request et limit puis 3x => probleme disaparait, CPU throttling ; mais coûteux et plus difficile de positionner les pods utiliser des pods “burstable”, limit > requests Bon articles pour ceux qui sont en phase d’apprentissage de Jave et Kubernetes. Attention, leur modèle peut faire crasher un noeud en cas de probleme et de reboot de pods excessifs puisque la charge théorique nécessaire est de 3x. Mais ce n’est probablement pas pire que leur problème initial Front Sortie de Flutter 2.0 poste plus technique niveau production pour le support du Web Sound Null Safety qui permet d’éviter les null pointer exception le support du desktop est aussi en mode stable de nouvelles widgets Meilleur support dans IntelliJ et Visual Studio Code Filio une app exemple pour etre progressive et belle sur tous les supports Fultter fix pour faire evoluer le code “500,000 Flutter developers across a growing number of platforms” wow Librairies Hibernate Reactive 1.0 CR arrive Spring Native est en béta Micronaut 2.4 est sorti Ajout et support des annotations jakarta.inject comme alternative à javax.inject Ajout d’annotations @NonNull et @Nullable propres à Micronaut, car différents outils et frameworks proposent aussi des annotations nullables qui rentrent parfois en conflit les unes avec les autres Nouvelle annotation @InterceptorBean pour appliquer des interceptors à des beans, qui remplacent les annotations AOP existantes Support plus fin des erreurs de réponse, avec des content type plus fins Diverses améliorations de Micronaut Data, dont par exemple le support des records de Java 14+ Support de Oracle Coherence CE pour Micronaut Data Outillage Gradle explique l’impact de la disparition de JCenter sur les builds Gradle telechargement des dependences et des plugins publications vers bintray beaucoup d’exemples utilisent jcenter + Gradle, donc verifier vos fichiers de build => jcenter() déprécié reco: enlever jcentral du build et verifier que ca continue de tourner troubleshoot les dépendances qui ne sont que sur jcentral spécialement à risque Android Gradle Entreprise dans le build scan on sait d’où vient chaque dépendance les plugins peuvent ajouter des repository à vos projets dependance encore sur jcenger uniquement (attendre le maintainer, migrer vers une autre librairie, copier le jar attention au confusions de dependances et collision de namespace risque potentiel activation de verification des dependance ( true false) Architecture InfoQ article sur le pattern Saga, le outbox pattern et change data capture outbox pattern, evite l’écriture double DB/queue. Il ecoute les changements de la base de donnée dans une table dédiée qui est transformée en message dans une queue apr le composant de change data capture (modifié) cela evite tout besoin de XA ou autre synhcronization distribuée Saga, transaction métier large. utilise des compensations pour anuler partiellement ou totalement la transaction 2 approches choereographie: passage des messages d’un service a l’autre orchestration: un swervice coordonne les autres et fait les appels dual write: inconsistence si un ou l’autre des envois (DB tx ou message) echoue Article ensuite decrit comment implementer une saga entre 4 services via the outbox pattern en utilisant Kafka et Debezium Thoth un framework event sourcing de la Maif Méthodologies L’état des lieux du Dev Java par jaxcenter 49% de Dev java et le reste team lead architect et consultants 69% Java 8, JavaScript at 40%, Java 11 at 36% (note that they were allowed to select more than one programming language of choice). 16% Java 12 or newer, and 15% Java 7 or older. 66% convertissent ou utilisent microservices , 13% ne l’envisagent pas, 70% moins de 10 microservices App servers 6h% tomcat 19%wildfly 18 weblogic 15 jetty 14 web sphere Spring boot 62% (83 l’année dernière) drop wizard 8% Quarkus 6% Idea 65% eclipse 48 vscode 27. Netbeans 13 59% oracle JDK 22 adopt et 10 corretto Macen 67% (50% l’année dernière Docker 57% (74 en 2020) kube 42 VMware 27 Jenkins 61 76% utilisent un cloud AWS 39 azure 24 Google 18 Douleurs de Dev 54% temps de réponse Redeployment 59% 4 mins 20% 10 mins D3.js 10 ans d’open source ; les leçons apprises apprendre aux autres >> code en terme d’impact ; exemples sont puissants (modifié) Le support expose les problèmes de l’outil très rapidement pour aprendre les choses a maéliorer. Mais dès que cela arrête d’être constructif pour vous, arrêter et ne vous sentez pas mal. visualisation utile pour l’exploration et l’explication mais ce sont deux cas d’utilisation différents ne commiter pas sur une forme de visualisation (camember, barres etc) avant d’avoir vu votre data dessus. 90% des bugs suir 10% des fonctionalités: choisissez bien vos batailles Internet va vous faire sentir mal ne pas y aller seul Essayer d’avoir du bon temps Salaire égal pour tous dans la société 175k pour tous y compris les fondateurs Évite d’avoir à quantifier la performance de chacun Et le Risque incentividation individuelle != team (modifié) Transparence du modèle Plus bas salaire pour certains si ils travaillaient ailleurs mais c’est une valeur qui permet de vivre correctement avec enfants (jugé et testé par les fondateurs) Paie basée sur le travail et non les coûts de l’employé -> pas de différence géographique Scale probablement pas mais une start up peut se le permettre (ils ne prennent pas de junior pour l’instant Carrière != compensation par rewards Mais pour les parts dans la boîte ils le font en fonction du risque du premier risque au dernier pas risque Loi, société et organisation Un autre renvoie d’une personne du groupe ethic AI chez google après qu’elle ait téléchargé avec un script des infos concernant la première employée renvoyée Elle a exfiltre des milliers de docs vers des comptes externes Met en doute le commitment du ethical ai chez Google Mais comment répondre à une personne ex filtrant des docs privés ? Mitchell qui annonce qu’elle est virée Ethique vs lanceur d’alerte ? Conférences Mix-It (virtuel) les 18, 19 et 20 mai 2021 10 talks de 30 mn + 20mn de Q&A + 10 mn de pause https://www.devoxx.fr/2021/02/25/preparation-du-programme-de-ledition–2021/ reprend une partie du CfP de l’année dernière. Nous contacter Soutenez Les Cast Codeurs sur Patreon https://www.patreon.com/LesCastCodeurs Faire un crowdcast ou une crowdquestion Contactez-nous via twitter https://twitter.com/lescastcodeurs sur le groupe Google https://groups.google.com/group/lescastcodeurs ou sur le site web https://lescastcodeurs.com/

Dans cet épisode désordonné mais complet, Antonio, Guillaume et Emmanuel parlent de JVM sur Kubernetes, des datacenters OVH, de Spring Native, de Flutter, de Saga, d'Open Source et de salaire. Enregistré le 12 mars 2021 Téléchargement de l'épisode [LesCastCodeurs-Episode-251.mp3](https://traffic.libsyn.com/lescastcodeurs/LesCastCodeurs-Episode-251.mp3) ## News ### Infrastructure [Un data center d'OVH en feu](https://www.phonandroid.com/ovh-un-incendie-detruit-completement-le-data-center-des-services-impactes.html) * Strasbourg * data center entierement détruit * recommande d'activer les protocoles de disaster recovery * impacte aussi d'autres data centers : SBG1, SBG3 et SBG4 (electricite coupée et une partie des salles serveurs) * [Autre article couvrant l'évènement](https://www.journaldunet.com/web-tech/cloud/1498567-incendie-chez-ovh-3-6-millions-de-sites-web-hors-ligne/) * 3,5 millions de sites down, les backups aussi? * 18% des adresses IP attribuées à OVH * remedarrage (sauf SBG2) la semaine prochaine * touche la partie hosted private cloud * quelques jours avant annonce de mise en bourse [Améliorer le temps de démarrage des JVMs sur Kubernetes](https://tech.olx.com/improving-jvm-warm-up-on-kubernetes-1b27dd8ecd58) * JIT etc, temps de demarrage relativement lent * rajouter des pods et faire deu deployment graduel (3x coût) * script de chauffe avec le readiness probe utilisant initialDelaySeconds mais pas d’amelioration massive (rejoue les URLs de prod) et ralentit l’auto scaling * changer les heuristiques de la JVM : 2x CPU request et limit puis 3x => probleme disaparait, CPU throttling ; mais coûteux et plus difficile de positionner les pods * utiliser des pods “burstable”, limit > requests * Bon articles pour ceux qui sont en phase d’apprentissage de Jave et Kubernetes. * Attention, leur modèle peut faire crasher un noeud en cas de probleme et de reboot de pods excessifs puisque la charge théorique nécessaire est de 3x. Mais ce n’est probablement pas pire que leur problème initial ### Front [Sortie de Flutter 2.0](https://developers.googleblog.com/2021/03/announcing-flutter-2.html) * [poste plus technique](https://medium.com/flutter/whats-new-in-flutter-2-0-fe8e95ecc65) * niveau production pour le support du Web * Sound Null Safety qui permet d’éviter les null pointer exception * le support du desktop est aussi en mode stable * de nouvelles widgets * Meilleur support dans IntelliJ et Visual Studio Code * Filio une app exemple pour etre progressive et belle sur tous les supports * Fultter fix pour faire evoluer le code * "500,000 Flutter developers across a growing number of platforms" wow ### Librairies [Hibernate Reactive 1.0 CR arrive](https://in.relation.to/2021/03/08/hibernate-reactive-1/) [Spring Native est en béta](https://spring.io/blog/2021/03/11/announcing-spring-native-beta) [Micronaut 2.4](https://micronaut.io/blog/2021-03-09-micronaut-2-4-release.html) est sorti * Ajout et support des annotations jakarta.inject comme alternative à javax.inject * Ajout d'annotations @NonNull et @Nullable propres à Micronaut, car différents outils et frameworks proposent aussi des annotations nullables qui rentrent parfois en conflit les unes avec les autres * Nouvelle annotation @InterceptorBean pour appliquer des interceptors à des beans, qui remplacent les annotations AOP existantes * Support plus fin des erreurs de réponse, avec des content type plus fins * Diverses améliorations de Micronaut Data, dont par exemple le support des records de Java 14+ * Support de Oracle Coherence CE pour Micronaut Data ### Outillage [Gradle explique l’impact de la disparition de JCenter sur les builds Gradle](https://blog.gradle.org/jcenter-shutdown) * telechargement des dependences et des plugins * publications vers bintray * beaucoup d'exemples utilisent jcenter + Gradle, donc verifier vos fichiers de build => `jcenter()` déprécié * reco: enlever jcentral du build et verifier que ca continue de tourner * troubleshoot les dépendances qui ne sont que sur jcentral * spécialement à risque Android * Gradle Entreprise dans le build scan on sait d'où vient chaque dépendance * les plugins peuvent ajouter des repository à vos projets * dependance encore sur jcenger uniquement (attendre le maintainer, migrer vers une autre librairie, copier le jar * attention au confusions de dependances et collision de namespace * risque potentiel * activation de verification des dependance ( `true false`) ### Architecture [InfoQ article sur le pattern Saga, le outbox pattern et change data capture](https://www.infoq.com/articles/saga-orchestration-outbox/) * outbox pattern, evite l’écriture double DB/queue. Il ecoute les changements de la base de donnée dans une table dédiée qui est transformée en message dans une queue apr le composant de change data capture (modifié) * cela evite tout besoin de XA ou autre synhcronization distribuée * Saga, transaction métier large. utilise des compensations pour anuler partiellement ou totalement la transaction * 2 approches * choereographie: passage des messages d’un service a l’autre * 2. orchestration: un swervice coordonne les autres et fait les appels * dual write: inconsistence si un ou l’autre des envois (DB tx ou message) echoue * Article ensuite decrit comment implementer une saga entre 4 services via the outbox pattern en utilisant Kafka et Debezium [Thoth un framework event sourcing de la Maif](https://maif.github.io/thoth/) ### Méthodologies [L’état des lieux du Dev Java par jaxcenter](https://jaxenter.com/java-development-2021-173870.html) * 49% de Dev java et le reste team lead architect et consultants * 69% Java 8, JavaScript at 40%, Java 11 at 36% (note that they were allowed to select more than one programming language of choice). 16% Java 12 or newer, and 15% Java 7 or older. * 66% convertissent ou utilisent microservices , 13% ne l’envisagent pas, 70% moins de 10 microservices * App servers 6h% tomcat 19%wildfly 18 weblogic 15 jetty 14 web sphere * Spring boot 62% (83 l’année dernière) drop wizard 8% Quarkus 6% * Idea 65% eclipse 48 vscode 27. Netbeans 13 * 59% oracle JDK 22 adopt et 10 corretto * Macen 67% (50% l’année dernière * Docker 57% (74 en 2020) kube 42 VMware 27 * Jenkins 61 * 76% utilisent un cloud * AWS 39 azure 24 Google 18 * Douleurs de Dev * 54% temps de réponse * Redeployment 59% 4 mins 20% 10 mins [D3.js 10 ans d’open source ; les leçons apprises](https://observablehq.com/@mbostock/10-years-of-open-source-visualization) * apprendre aux autres >> code en terme d’impact ; exemples sont puissants (modifié) * Le support expose les problèmes de l’outil très rapidement pour aprendre les choses a maéliorer. Mais dès que cela arrête d’être constructif pour vous, arrêter et ne vous sentez pas mal. * visualisation utile pour l’exploration et l’explication mais ce sont deux cas d’utilisation différents * ne commiter pas sur une forme de visualisation (camember, barres etc) avant d’avoir vu votre data dessus. * 90% des bugs suir 10% des fonctionalités: choisissez bien vos batailles * Internet va vous faire sentir mal * ne pas y aller seul * Essayer d’avoir du bon temps [Salaire égal pour tous dans la société](https://oxide.computer/blog/compensation-as-a-reflection-of-values/) * 175k pour tous y compris les fondateurs * Évite d’avoir à quantifier la performance de chacun * Et le Risque incentividation individuelle != team (modifié) * Transparence du modèle * Plus bas salaire pour certains si ils travaillaient ailleurs mais c’est une valeur qui permet de vivre correctement avec enfants (jugé et testé par les fondateurs) * Paie basée sur le travail et non les coûts de l’employé -> pas de différence géographique * Scale probablement pas mais une start up peut se le permettre (ils ne prennent pas de junior pour l'instant * Carrière != compensation par rewards * Mais pour les parts dans la boîte ils le font en fonction du risque du premier risque au dernier pas risque ### Loi, société et organisation [Un autre renvoie d’une personne du groupe ethic AI chez google après qu’elle ait téléchargé avec un script des infos concernant la première employée renvoyée](https://www.cnbc.com/2021/01/21/margaret-mitchell-google-investigating-ai-researcher-awu-concerned.html) * Elle a exfiltre des milliers de docs vers des comptes externes * Met en doute le commitment du ethical ai chez Google * Mais comment répondre à une personne ex filtrant des docs privés ? * [Mitchell qui annonce qu'elle est virée](https://twitter.com/mmitchell_ai/status/1362885356127801345?s=21) * Ethique vs lanceur d’alerte ? ## Conférences [Mix-It (virtuel) les 18, 19 et 20 mai 2021](https://mixitconf.org/fr/) * 10 talks de 30 mn + 20mn de Q&A + 10 mn de pause [https://www.devoxx.fr/2021/02/25/preparation-du-programme-de-ledition-2021/](https://www.devoxx.fr/2021/02/25/preparation-du-programme-de-ledition-2021/) * reprend une partie du CfP de l’année dernière. ## Nous contacter Soutenez Les Cast Codeurs sur Patreon [Faire un crowdcast ou une crowdquestion](https://lescastcodeurs.com/crowdcasting/) Contactez-nous via twitter sur le groupe Google ou sur le site web

Red Hat expert Jim Garrett joins us to work through the ins and outs of Red Hat's Quarkus, a full-stack, Kubernetes-native Java framework that's made for Java virtual machines (JVMs) and native compilation, optimizing Java specifically for containers and enabling it to become an effective platform for serverless, cloud, and Kubernetes environments.By the end of the episode, you'll know what that means and you'll have learned about the advantages that serverless computing brings to your business operations and your bottom line.

An airhacks.fm conversation with Daniel Kec (@DanielKec) about: Java / Jakarta API for JSON Binding (JSON-B), Java / Jakarta API for JSON Processing (JSON-P), yasson, Java / Jakarta Architecture for XML Binding (JAXB), Eclipse Jersey, Jason's Binding (logo), Sun's spirit and the first day at Oracle, Oracle Internet File System, Running Java in the database: Oracle and the Aurora JVM, Oracle Database Lite on Palm Pilot, IBM alphaworks, Java Developer Connection from Sun, the first day at Oracle, fixing Metro bugs, meeting Jaroslav Tulach in the kitchen, episode with Jaroslav Tulach, listening to Nanowar, implementing a Helidon - Apache Kafka integration, MicroProfile Reactive Messaging, Incoming and Outgoing, implementing MicroProfile Reactive Operators for Helidon, Java 9 reactive flow API, Reactive programming in Java, Reactive Streams for JVMs specification, David Karnok, https://twitter.com/akarnokd, the reactive manifesto, helidon implements the reactive messaging for MicroProfile spec, episode with SAP: How to Deal With Java Dependencies helidon and Java's Project Loom integration, MicroProfile emitter, Java 9 SubmissionPublisher and MicroProfile PublisherBuilder, quarkus reactive implementation: mutiny, mutiny attempts to be more user friendly, Project Loom and reactive programming, reactive programming is practical for messaging, episode #108 about CORBA, gRPC, OSGI, vert.x, mutiny, Reactive Programming and Quarkus with Clement Escoffier, helidon runs on Netty, one event loop should be enough, helidon also supports reactive Java Messaging Service (JMS), Oracle Cloud Infrastructure Streaming, Oracle Advanced Queue (AQ), helidon WebSocket integration, using WebSockets for reactive communication, Reactive streams programming over WebSockets with Helidon SE, helidon integrates conveniently Java API for RESTful Web Services JAX-RS / Jakarta RESTful Web Services Jersey with Server-sent events (SSE), Daniel Kec on twitter: @DanielKec, helidon's blog: medium.com/helidon

An airhacks.fm conversation with Markus Kett (@MarkusKett) about: "What was your first computer?" - Markus was introduced in the episode #36, storing graph of Java objects with microstream, no annotation, not XML required, lazy subgraph loading, database support, coherence and cloud block storage (e.g. S3) are supported, microstream relies on key-value stores, using flat files, microstream relies on custom Java serialization, Java serialization challenges, microstream and security, microstream is not based on Java serialization, code execution during deserialization of Java objects is not avoidable, hackathlon with OracleLabs, Helidon and GraalVM, abstracting JVMs object ids, working with persistent Java objects directly, using getters for object traversal, working with Java object directly in memory, microstream can be orders of magnitudes faster than Java Persistence API, (JPA), accessing persistent object in microseconds, avoiding the JDBC IO- overhead, using Java's off-heap memory, persistent RAM and Intel's Optane, keeping Java object in RAM forever, thinking as Java developers, using Java collections as persistent objects, caffeine - the concurrent cache for Java, reasons for opensourcing microstream, long term support comes with commercial support, running microstream on GraalVM in native mode, polyglot persistence with GraalVM helidon is obsessed with performance, microstream on helidon on GraalVM, combining microstream and Kafka, kafka connector for microstream comes in the next release, microstream - redis integration, custom serialization formats, CDC and debezium, NoSQL database on top of microstream, object graph in Java is a multi-model database, the Java application becomes the database system, authorization on JPA object level, JPA security, the MicroStream, Helidon and GraalVM hackathlon, JAVAPRO magazine - the first free Java magazine, JCon is organized by JavaPRO, Markus Kett on twitter: @MarkusKett

Some of the highlights of the show include The diplomacy that's required between software engineers and management, and why influence is needed to move projects forward to completion. Driving factors behind Ygrene's Kubernetes migration, which included an infrastructure bottleneck, a need to streamline deployment, and a desire to leverage their internal team of cloud experts. Management's request to ship code faster, and why it was important to the organization.  How the company's engineers responded to the request to ship code faster, and overcame disconnects with management. How the team obtained executive buy-in for a Kubernetes migration. Key cultural changes that were required to make the migration to Kubernetes successful. How unexpected challenges forced the team to learn the “depths of Kubernetes,” and how it helped with root cause analysis. Why the transition to Kubernetes was a success, enabling the team to ship code faster, deliver more value, secure more customers, and drive more revenue.  Links: HerdX: https://www.herdx.com/ Ygrene: https://ygrene.com/ Austin Twitter: https://twitter.com/_austbot Austin LinkedIn: https://www.linkedin.com/in/austbot/ Arnold's book on publisher site: https://www.packtpub.com/cloud-networking/the-kubernetes-workshop  Arnold's book on Amazon: https://www.amazon.com/Kubernetes-Workshop-Interactive-Approach-Learning/dp/1838820752/ TranscriptAnnouncer: Welcome to The Business of Cloud Native podcast where we explore how end users talk and think about the transition to Kubernetes and cloud-native architectures.Emily: Welcome to The Business of Cloud Native. My name is Emily Omier, and I am here with Austin Adams and Zack Arnold, and we are here to talk about why companies go cloud-native.Austin: So, I'm currently the CTO of a small Agrotech startup called HerdX. And that means I spend my days designing software, designing architecture for how distributed systems talk, and also leading teams of engineers to build proof-of-concepts and then production systems as they take over the projects that I've designed. Emily: And then, what did you do at Ygrene? Austin: I did the exact same thing, except for without the CTO title. And I also had other higher-level engineers working with me at Ygrene. So, we made a lot of technical decisions together. We all migrated to Kubernetes together, and Zack was a chief proponent of that, especially with the culture change. So, I focused on the designing software that teams of implementation engineers could take over and actually build out for the long run. And I think Zack really focused on—oh, I'll let Zack say what he focused on. [laughs].Emily: Go for it, Zach.Zach: Hello. I'm Zack. I also no longer work for Ygrene, although I have a lot of admiration and respect for the people who do. It was a fantastic company. So, Austin called me up a while back and asked me to think about participating in a DevOps engineering role at Ygrene. And he sort of said at the outset, we don't really know what it looks like, and we're pretty sure that we just created a position out of a culture, but would you be willing to embody it? And up until this point, I'd had cloud experience, and I had had software engineering experience, but I didn't really spend a ton of time focused on the actual movement of software from developer's laptops to production with as few hiccups, and as many tests, and as much safety as possible in between. So, I always told people the role felt like it was three parts. It was part IT automation expert, part software engineer, and then part diplomat. And the diplomacy was mostly in between people who are more operations focused. So, support engineers, project managers, and people who were on-call day in and day out, and being a go-between higher levels of management and software engineers themselves because there's this awkward, coordinated motion that has to really happen at a fine-grained level in order to get DevOps to really work at a company. What I mean by that is, essentially, Dev and Ops seem to on the surface have opposing goals, the operation staff, it's job is to maintain stability, and the development side's job is to introduce change, which invariably introduces instability. So, that dichotomy means that being able to simultaneously satisfy both desires is really a goal of DevOps, but it's difficult to achieve at an organizational level without dealing with some pretty critical cultural components. So, what do I spend my day on? The answer to that question is, yes. It really depends on the day. Sometimes it's cloud engineers. Sometimes it's QA folks, sometimes it's management. Sometimes I'm heads-down writing software for integrations in between tools. And every now and again, I get to contribute to open-source. So, a lot of different actual daily tasks take place in my position.Emily: Tell me a little bit more about this diplomacy between software engineers and management.Zach: [laughs]. Well, I'm not sure who's going to be listening in this amazing audience of ours, but I assume, because people are human, that they have capital O-pinions about how things should work, especially as it pertains to either software development lifecycle, the ITIL process of introducing change into a datacenter, into a cloud environment, compliance, security. There's lots of, I'll call them thought frameworks that have a very narrow focus on how we should be doing something with respect to software. So, diplomacy is the—well, I guess in true statecraft, it's being able to work in between countries. But in this particular case, diplomacy is using relational equity or influence, to be able to have every group achieve a common and shared purpose. At the end of the day, in most companies the goal is actually to be able to produce a product that people would want to pay for, and we can do so as quickly and as efficiently as possible. To do that, though, it again requires a lot of people with differing goals to work together towards that shared purpose. So, the diplomacy looks like, aside from just having way too many meetings, it actually looks like being able to communicate other thought frameworks to different stakeholders and being able to synthesize all of the different narrow-focused frameworks into a common shared, overarching process. So, I'll give you a concrete example because it feels like I just spewed a bunch of buzzwords. A concrete example would be, let's say in the common feature that's being delivered for ABC Company, for this feature it requires X number of hours of software development; X number of hours of testing; X number of hours of preparing, either capacity planning, or fleet size recommendations, or some form of operational pre-work; and then the actual deployment, and running, and monitoring. So, in the company that I currently work for, we just described roughly 20 different teams that would have to work together in order to achieve the delivery of this feature as rapidly as possible. So, the process of DevOps and the diplomacy of DevOps, for me looks like—aside from trying to automate as much as humanly possible and to provide what I call interface guarantees, which are basically shared agreements of functionality between two teams. So, the way that the developers will speak to the QA engineers is through Git. They develop new software, and they push it into shared code repositories, the way that the QA engineers will speak to people who are going to be handling the deployments—or at management in this particular case—is going to be through a well-formatted XML test file. So, providing automation around those particular interfaces and then ensuring that everyone's shared goals are met at the particular period of time where they're going to be invoked over the course of the delivery of that feature, is the “subtle art,”—air quotes, you can't see but—to me of DevOps diplomacy. That kind of help?Emily: Yeah, absolutely. Let's take, actually, just a little bit of a step back. Can you talk about what some of the business goals were behind moving to Kubernetes for Ygrene? Who was the champion of this move? Was it business stakeholders saying, “Hey, we really need this to change,” or engineering going to business stakeholders? Who needed a change. I believe that the desire for Kubernetes came from a bottleneck of infrastructure. Not so much around performance, such as the applications weren't performing due to scale. We had projected scale that we were coming to where it would cause a problem potentially, but it was also in the ease of deployment. It had a very operations mindset as Zack was saying, our infrastructure was almost entirely managed—of the core applications set—by outsourcing. And so, we depended on them to innovate, we depended on them to spin up new environments and services. But we also have this internal competing team that always had this cloud background. And so, what we were trying to do was lessen the time between idea to deployment by utilizing platforms that were more scalable, more flexible, and all the things that Docker gives with the Dev/Prod Parity, the ease of packaging your environment together so that small team can ship an entire application. And so, I think our main goal with that was to take that team that already had a lot of cloud experience, and give them more power to drive the innovation and not be bottlenecked just by what the outsourcing team could do. Which, by the way, just for the record, the outsourcing team was an amazing team, but they didn't have the Kubernetes or cloud experience, either. So, in terms of a hero or champion of it, it just started as an idea between me and the new CTO, or CIO that came in, talking about how can we ship code faster? So, one of the things that happened in my career was the desire for a rapid response team which, that sounds like a buzzword or something, but it was this idea that Ygrene was shipping software fairly slow, and we wanted to get faster. So, really the CIO, and one of the development managers, they were the really big champions of, “Hey, let's deliver value to the business faster.” And they had the experience to ask their engineers how to make that happen, and then trust Zack and I through this process of delivering Kubernetes, and Istio, and container security, and all these different things that eventually got implemented.Emily: Why do you think shipping code faster matters?Austin: I think, for this company, why it mattered was the PACE financing industry is relatively new. And while financing has some old established patterns, I feel like there's still always room for innovation. If you hear the early days of the Bridgewater Financial Hedge Fund, they were a source of innovation and they used technology to deliver new types of assets and things like that. And so, our team at Ygrene was excellent because they wanted to try new things. They wanted to try new patterns of PACE financing, or ways of getting in front of the customer, or connections with different analytics so they could understand their customer better. So, it was important to be able to try things, experiment to see what was going to be successful. To get things out into the real world to know, okay, this is actually going to work, or no, this isn't going to work. And then, also, one of the things within financing is—especially newer financing—is there's a lot of speed bumps along the way. Compliance laws can come into effect, as well as working with cities and governments that have specialized rules and specialized things that they need—because everyone's an expert when it comes to legislation, apparently—they decide that they need X, and they give us a time when we have to get it done. And so, we actually have another customer out there, which is the legislative bodies. So, they have to get the software—their features that are needed within the financing system out by certain dates, or we're no longer eligible to operate in those counties. So, one of it was a core business risk, so we needed to be able to deliver faster. The other was how can we grow the business?Emily: Zach, this might be a question for you. Was there anything that was lost in translation as you were explaining what engineering was going to do in order to meet this goal of shipping code faster, of being more agile, when you were talking to C level management? How did they understand, and did anything get lost in translation?Zach: One of the largest disconnects, both on a technical and from a high level speaking to management issue I had was explaining how we were no longer going to be managing application servers as though they were pets. When you come from an on-premise setup, and you've got your VMware ESXi, and you're managing virtual machines, the most important thing that you have is backups because you want to keep those machines exactly as they are, and you install new software on those machines. When Kubernetes says, I'm going to put your pods wherever they fit on the cluster, assuming it conforms with the scheduling pattern, and if a node dies, it's totally fine, I'm going to spin a new one up for you, and move pods around and ensure that the application is exactly as you had stated—as in, it's in its desired state—that kind of thinking from switching from infrastructure as pets to infrastructure as cattle, is difficult to explain to people who have spent their careers in building and maintaining datacenters. And I think a lot—well, it's not guaranteed that this is across the board, but if you want to talk about a generational divide, people that usually occupy the C level office chairs are familiar with—in their heyday of their career—a datacenter-based setup. In a cloud-based consumption model where it really doesn't matter—I can just spin up anything anywhere—when you talk about moving from reasoning about your application as the servers it comprises and instead talking about your application as the workload it comprises, it becomes a place where you have to really, really concretely explain to people exactly how it's going to work that the entire earth will not come crashing down if you lose a server, or if you lose a pod, or if a container hiccups and gets restarted by Kubernetes on that node. I think that was the real key one. And the reason why that actually became incredibly beneficial for us is because once we actually had that executive buy-off when it came to, while I still may not understand, I trust that you know what you're doing and that this infrastructure really is replaceable, it allowed us to get a little bit more aggressive with how we managed our resources. So, now using Horizontal Pod Autoscaling, using the Kubernetes Cluster Autoscaler, and leveraging Amazon EC2 Spot Fleets, we were only ever paying for the exact amount of infrastructure that was required to run our business. And I think that is usually the thing that translates the best to management and non-technical leadership. Because when it comes down to if I'm aware that using this tool, and using a cloud-native approach to running my application, I am only ever going to be paying for the computational resource that I need in that exact minute to run my business, then the budget discussions become a lot easier, because everyone is aware that this is your exact run-rate when it comes to technology. Does that make sense? Emily: Absolutely. How important was having that executive buy-in? My understanding is that a lot of companies, they think that they're going to get all these savings from Kubernetes, and it doesn't always materialize. So, I'm just curious, it sounds like it really did for Ygrene.Zach: There was two things that really worked well for us when this transformation was taking place. The first was, Ygrene was still growing, so if the budget grew alongside of the growth of the company, nobody noticed. So, that was one really incredible thing that happened that, I think, now having had different positions in the industry, I don't know if I appreciated that enough because if you're attempting to make a cost-neutral migration to the Cloud, or to adopt cloud-native management principles, you're going to probably move too little, too late. And when that happens, you run the risk of really doing a poor job of adopting cloud-native, and then scrapping that project, because it never materialized the benefit, as you just described, that some people didn't experience. And the other benefit that we had, I think was the fact that because there were enough incredibly senior technical people—and again, I learned everything from these people—working with us, and because we were all, for the most part, on the same page when it came to this migration, it was easy to have a unified front with our management because every engineer saw the value of this new way of running our infrastructure and running our application. In one non—and this obviously helps with our engineers—one non-monetary benefit that helped really get the buy-in was the fact that, with Kubernetes, our on-call SEV-1 pages went down, I want to say, by over 40 percent which was insane because Kubernetes was automatically intervening in the case where servers went down. JVMs run out of memory, exceptions cause strange things, but a simple restart usually fixes the vast majority of them. Well, now Kubernetes was doing this and we didn't need to wake somebody up in order to keep the machine running.Emily: From when you started this transition to when you, I should say, when you probably left the company, but what were some of the surprises, either surprises for you, or surprises for other people in the organization?Austin: The initial surprise was the yes that we got. So, initially I pitched it and started talking about it, and then the culture started changing to where we realized we really needed to change, and bringing Zack on and then getting the yes from management was the initial surprise. And—Emily: Why was that a surprise?Austin: It was just surprising because, when you work as an engineer—I mean, none of us were C suite, or Dev managers, or anything. We were just highly respected engineers working in the HQ. So, it was just a surprise that what we felt was a semi-crazy idea at the time—because Kubernetes was a little bit earlier. I mean, EKS wasn't even a thing from Amazon. We ran our Kubernetes clusters from the hip, which is using kops, which is—kops is a great tool, but obviously it wasn't managed. It was managed by us, mainly by Zach and his team, to be honest. So, that was a surprise that they would trust a billion-dollar financing engine to run on the proposal of two engineers. And then, the next ones were just how much the single-server, vertical scaling, and depending on running on the same server was into our applications. So, as we started to look at the core applications and moving them into a containerized environment, but also into an environment that can be spun up and spun down, looking at the assumptions the application was making around being on the same server; having specific IP addresses, or hostnames; and things like that, where we had to take those assumptions out and make things more flexible. So, we had to remove some stateful assumptions in the applications, that was a surprise. We also had to enforce more of the idea of idempotency, especially when introducing Istio, and [00:21:44 retryable] connections and retryable logic around circuit breaking and service-to-service communication. So, some of those were the bigger surprises, is the paradigm shift between, “Okay, we've got this service that's always going to run on the same machine, and it's always going to have local access to its files,” to, “Now we're on a pod that's got a volume mounted, and there's 50 of them.” And it's just different. So, that was a big—[laughs], that was a big surprise for us.Emily: Was there anything that you'd call a pleasant surprise? Things that went well that you anticipated to be really difficult?Zach: Oh, my gosh, yes. When you read through Kubernetes for the first time, you tend to have this—especially if somebody else told you, “Hey, we're going to do this,” this sinking feeling of, “Oh my god, I don't even know nothing,” because it's so immense in its complexity. It requires a retooling of how you think, but there have been lots of open-source community efforts to improve the cluster lifecycle management of Kubernetes, and one such project that really helped us get going—do you remember this Austin?—was kops.Austin: Yep. Yep, kops is great.Zach: I want to say Justin Santa Barbara was the original creator of that project, and it's still open source, and I think he still maintains it. But to have a production-ready, and we really mean production-ready: it was private, everything was isolated, the CNI was provisioned correctly, everything was in the right place, to have a fully production-ready Kubernetes cluster ready to go within a few hours of us being able to learn about this tool in AWS was huge because then we could start to focus on what we didn't even understand inside of the cluster. Because there were lots of—Kubernetes is—there's two sides of it, and both of them are confusing. There's the infrastructure that participates in the cluster, and there's the actual components inside of the cluster which get orchestrated to make your application possible. So, not having to initially focus on the infrastructure that made up the cluster, so we could just figure out the difference between our butt and the hole in the ground, when it came to our application inside of Kubernetes was immensely helpful to us. I mean, there are a lot of tools these days that do that now: GKE, EKS, AKS, but we got into Kubernetes right after it went GA, and this was huge to help with that.Emily: Can you tell me also a little bit about the cultural changes that had to happen? And what were these cultural changes, and then how did it go?Zach: As Austin said, the notion of—I think a lot—and I don't want to offer this as a sweeping statement—but I think the vast majority of the engineers that we had in Seattle, in San Jose, and in Petaluma where the company was headquartered, I think, even if they didn't understand what the word idempotent meant, they understood more or less how that was going to work. The larger challenge for us was actually in helping our contractors, who actually made up the vast majority of our labor force towards the end of my tenure there, how a lot of these principles worked in software. So, take a perfect example: part of the application is written in Ruby on Rails, and in Ruby on Rails, there's a concept of one-off tasks called rake tasks. When you are running a single server, and you're sending lots of emails that have attachments, those attachments have to be on the file system. And this is the phrase I always said to people, as we refactor the code together, I repeated the statement, “You have to pretend this request is going to start on one server and finish on a different one, and you don't know what either of them are, ahead of time.” And I think using just that simple nugget really helped, culturally, start to reshape this skill of people because when you can't use or depend on something like the file system, or you can't depend on that I'm still on the same server, you begin to break your task into components, and you begin to store those components in either a central database or a central file system like Amazon S3. And adopting those parts of, I would call, cloud-native engineering were critical to the cultural adoption of this tool. I think the other thing was, obviously, lots of training had to take place. And I think a lot of operational handoff had to take place. I remember for, basically, a fairly long stretch of time, I was on-call along with whoever was also on-call because I had the vast majority of the operational knowledge of Kubernetes for that particular team. So, I think there was a good bit of rescaling and mindset shift from the technical side of being able to adopt a cloud-native approach to software building. Does that make sense?Emily: Absolutely. What do you think actually were some of the biggest challenges or the biggest pain points? Zach: So, challenges of cultural shift, or challenges of specifically Kubernetes adoption?Emily: I was thinking challenges of Kubernetes adoption, but I'm also curious about the cultural shift if that's one of the biggest pain points.Zach: It really was for us. I think—because now it wouldn't—if you wanted to take out Kubernetes and replace it with Nomad there? All of the engineers would know what you're talking about. It wouldn't take but whatever the amount of time it would to migrate your Kubernetes manifests to Nomad HCL files. So, I do think the rescaling and the mindset shift, culturally speaking, was probably the thing that helped solidify it from an engineering level. But Kubernetes adoption—or at least problems in Kubernetes adoption, there was a lot of migration horror stories that we encountered. A lot of cluster instability in earlier versions of Kubernetes prevented any form of smooth upgrades. I had to leave—it was with my brother's—it was his wedding, what was it—oh, rehearsal dinner, that's what it was. I had to leave his rehearsal dinner because the production cluster for Ygrene went down, and we needed to get it back up. So, lots of funny stories like that. Or Nordstrom did a really fantastic talk on this in KubeCon in Austin in 2017. But the [00:28:57 unintelligible] split-brain problem where suddenly the consensus in between all of the Kubernetes master nodes began to fail for one reason or another. And because they were serving incorrect information to the controller managers, then the controller managers were acting on incorrect information and causing the schedulers to do really crazy things, like delete entire deployments, or move pods, or kill nodes, or lots of interesting things. I think we unnecessarily bit off a little bit too much when it came to trying to do tricky stuff when it came to infrastructure. We introduced a good bit of instability when it came to Amazon EC2 Spot that I think, all things considered, I would have revised the decision on that. Because we faced a lot of node instability, which translated into application instability, which would cause really, really interesting edge cases to show up basically only in production.Austin: One of the more notable ones—and I think this is the symptom of one of the larger challenges was during testing, one of our project managers that also helped out in the testing side—technical project managers—which we nicknamed the Edge Case Factory, because she was just, anointed, or somehow had this superpower to find the most interesting edge cases, and things that never went wrong for anyone else always went wrong for her, and it really helped us build more robust software for sure, but there's some people out there with mutant powers to catch bugs, and she was one of them. We had two clusters, we had lower environment clusters, and then we had production cluster. The production cluster hosted two namespaces: the staging namespace, which is supposed to be an exact copy of production; and then the production namespace, so that you can smoke-test legitimate production resources, and blah blah blah. So, one time, we started to get some calls that, all of a sudden, people were getting the staging environment underneath the production URL. Zach: Yeah.Austin: And we were like, “Uh… excuse me?” It comes down to—we eventually figured it out. It was something within the networking layer. But it was this thing, as we rolled along, the deeper understanding of, okay, how does this—to use a term that Zack Arnold coined—this benevolent botnet, how does this thing even work, at the most fundamental and most detailed levels? And so, as problems and issues would occur, pre-production or even in production, we had to really learn the depths of Kubernetes. And I think the reason we had to learn it at that stage was because of how new Kubernetes was, all things considered. But I think now with a lot more of the managed systems, I would say it's not necessary, but it's definitely helpful to really know how Kubernetes works down in the depths. So, that was one of the big challenges was, to put it succinctly, when an issue comes up, knowing really what's going on under the hood, really, really helped us as we discovered and learned things about Kubernetes.Zach: And what you're saying, Austin, was really illuminated by the fact that the telemetry that we had in production was not sufficient, in our minds, at least until very recently, to be able to adequately capture all the data necessary to accurately do root cause analyses on particular issues. In early days, there was far too much root cause analysis by, “It was probably this,” and then we moved on. Now having actually taken the time to instrument tracing, to instrument metrics, to instrument logs with correlation, we used, eventually, Datadog, but working our way through the various telemetry tools to achieve this, we really struggled being able to give accurate information to stakeholders about what was really going wrong in production. And I think Austin was probably the first person in the headquarters side of the company—I'm not entirely certain about some of our satellite dev offices—but to really champion a data-driven way of actually running software. Which, it seems trivial now because obviously that's how a lot of these tools work out of the box. But for us, it was really like, “Oh, I guess we really do need to think about the HTTP error rate.” [laughs].Emily: So, taking another step back here, do you think that Ygrene got everything that it expected, or that it wanted out of moving to Kubernetes?Austin: I think we're obviously playing up some of the challenges that we had because it was our day-to-day, but I do believe that trust in the dev team grew, we were able to deploy code during the day, which we could have done that in the beginning, even with vertically scaled infrastructure, we would have done it with downtime, but it really was that as we started to show that Kubernetes and these cloud-native tools like Fluentd, Prometheus, Istio, and other things like that when you set them up properly, they do take a lot of the risk out. It added trust in the development team. It gave more responsibility to the developers to manage their own code in production, which is the DevOps culture, the DevOps mindset. And I think in the end, we were able to ship code faster, we were able to deliver more value, we were able to go into new jurisdictions and markets quicker, to get more customers, and to ultimately increase the amount of revenue that Ygrene had. So, it built a bridge between the data science side of things, the development side of things, the project management side of things, and the compliance side of things. So, I definitely think they got a lot out of trusting us with this migration. I think that were we to continue, probably Zack and I even to this day, we would have been able to implement more, and more, and more. Obviously, I left the company, Zach left the company to pursue other opportunities, but I do believe we left them in a good spot to take this ecosystem that was put in place and run with it. To continue to innovate and do experiments to get more business.Zach: Emily, I'd characterize it with an anecdote. After our Chief Information Officer left the company, our Chief Operating Officer actually took over the management of the Technology Group, and aside from basically giving dev management carte blanche authority to do as they needed to, I think there was so much trust there that we didn't have at the beginning of our journey with technology and Ygrene. And it was characterized in, we had monthly calls with all of the regional account managers, which are basically our out-of-office sales staff. And generally, the project managers from our group would have to sit in those meetings and hear just about how terrible our technology was relative to the competition, either lacking in features, lacking in stability, lacking in design quality, lacking in user interface design, or way overdoing the amount of compliance we had to have. And towards the end of my tenure, those complaints dropped to zero, which I think was really a testament to the fact that we were running things stably, the amount of on-call pages went down tremendously, the amount of user-impacting production outages was dramatically reduced, and I think the overall quality of software increased with every release. And to be able to say that, as a finance company, we were able to deploy 10 times during the day if we needed to, and not because it was an emergency, but because it was genuinely a value-added feature for customers. I think that that really demonstrated that we reached a level of success adopting Kubernetes and cloud-native, that really helped our business win. And we positioned them, basically, now to make experiments that they thought would work from a business sense we implement the technology behind it, and then we find out whether or not we were right.Emily: Let's go ahead and wrap up. We're nearing the top of the hour, but just two questions for both of you. One is, where could listeners find you or connect with you? And the second one is, do you have a can't-live-without engineering tool?Austin: Yeah, so I'll go first. Listeners can find me on Twitter @_austbot, or on LinkedIn. Those are really the only tools I use. And I can't really live without Prometheus and Grafana. I really love being able to see everything that's happening in my applications. I love instrumentation. I'm very data-driven on what's happening inside. So, obviously Kubernetes is there, but it's almost become that Kubernetes is the Cloud. I don't even think about it anymore. It's these other tools that help us monitor and create active monitoring paradigms in our application so we can deploy fast, and know if we broke something. Zach: And if you want to stay in contact with me, I would recommend not using Twitter, I lost my password and I'm not entirely certain how to get it back. I don't have a blue checkmark, so I can't talk to Twitter about that. I probably am on LinkedIn… you know what, you can find me in my house. I'm currently working. The engineering tool that I really can't live without, I think my IDE. I use IntelliJ by JetBrains, and—Austin: Yeah, it's good stuff.Zach: —I think I wouldn't be able to program without it. I fear for my next coding interview because I'll be pretending that there's type ahead completion in a Google Doc, and it just won't work. So, yeah, I think that would be the tool I'd keep forever.Austin: And if any of Zach's managers are listening, he's not planning on doing any coding interviews anytime soon.Zach: [laughs]. Yes, obviously.Emily: Well, thank you so much. Zach: Emily Omier, thank you so much for your time.Austin: Right, thanks.Austin: And don't forget Zack is an author. He and his team worked very hard on that book.Emily: Zack, do you want to give a plug to your book?Zach: Oh, yeah. Some really intelligent people that, for some reason, dragged me along, worked on a book. Basically it started as an introduction to Kubernetes, and it turned into a Master's Course on Kubernetes. It's from Packt Publishing and yeah, you can find it there, amazon.com or steal it on the internet. If you're looking to get started with Kubernetes I cannot recommend the team that worked on this book enough. It was a real honor to be able to work with people I consider to be heavyweights in the industry. It was really fun.Emily: Thank you so much.Announcer: Thank you for listening to The Business of Cloud Native podcast. Keep up with the latest on the podcast at thebusinessofcloudnative.com and subscribe on iTunes, Spotify, Google Podcasts, or wherever fine podcasts are distributed. We'll see you next time.This has been HumblePod production. Stay humble.

In this Lightbend podcast, Akka expert Hugh McKee (Developer Advocate) is questioned by non-Akka expert Oliver White (Chief Storyteller) about some of the new features in the latest release of Akka 2.6.4. We talk about why distributed systems require thinking differently about how message delivery works compared to traditional monolithic systems, and how it all works with Akka to ensure reliable delivery of messages as massive scale across JVMs, nodes, clusters, and even data centers. For more information, visit http://akka.io/blog

Hi Spring fans! In this installment of a Bootiful Podcast Josh Long (@starbuxman) talks to Twitter's Chris Thalinger (@christhalinger) about Graal VM; JITs; Compilers; Hawaii, USA; Sao Paolo, Brazil; and so much more. Chris Thalinger on Twitter: @christhalinger GraalVM: https://www.graalvm.org/

Hi Spring fans! Welcome to another installment of a Bootiful Podcast! In this week I'm joined by my old friend, Azul CTO, Gil Tene as we discuss Java, JVMs, garbage collection, and a ton more in this extra packed 90 minute-plus episode.  * Gil on Twitter - http://twitter.com/GilTene * Azul Systems - https://www.azul.com/ * Zing - https://www.azul.com/products/zing/

Welcome to the History of Computing Podcast, where we explore the history of information technology. Because understanding the past prepares us for the innovations of the future! Today we're going to look at Java. Java is an Indonesian island with over 141 million people. Java man lived there 1.7 million years ago. Wait, wrong java. The infiltration of coffee into the modern world can really trace its roots to ancient coffee forests on the Ethiopian plateau. Sufis in Yemen began importing coffee in the 1400s to make a beverage that would aid in concentration and as a kind of spiritual intoxication. Um, still the wrong java… Although caffeine certainly has a link somewhere, somehow. The history of the Java programming language dates back to early 1991. It all started at Sun Microsystems with the Stealth Project. Patrick Naughton had considered going to NeXT due to limitations in C++ and the C APIs. But he stayed to join Stealth, a secret team of engineers led by a developer Sun picked up from Carnegie Mellon named James Gosling . Stealth was formed to explore new opportunities in the consumer electronics market. This came up when Gosling was writing a program to port software from perf to vax and emulating hardware as many, many, many programers had done before him. I wonder if he realized when he went to build the first Java compiler and the original virtual machine code that would go on to write a dozen books about Java and it would consume most of his professional life. I wonder how much coffee he would have consumed if he had. They soon added Patrick Sheridan to the team. The project was later known as the “Green” project and with the advent of the web, somewhat pivoted into more of a web project. You see, Microsoft and the clones had some runaway success but Apple and other vendors were a factor in the home market. But Sun saw going down market as the future of the company. They added a few more people and rented separate offices in Menlo Park. Lisa Friendly was the first employee in the Java Products Group. Gosling would be lead engineer. John Gage would direct the project. Jonni Kanerva would write Java FAQ1. The team started to build C++ ++ —. Sun founder Bill Joy wanted a language that combined the the best parts of Mesa and C. In 1993, NCSA gave us Mozilla. That Andreessen guy was on the news saying the era of the desktop was over. These brilliant designers knew they needed an embedded application, one that could even be used in a web browser, or an applet. The language was initially called “Oak,” but was later renamed “Java” in 1995, supposedly from a list of random words but really due to massive consumption of coffee imported from the island of Java. By the way, it only aids in concentration up to a point. Then you get jumpy. Like a Halfling. It took the Java team 18 months to develop the first working version. It is unknown how much Java they drank in this time. Between the initial implementation of Oak in the fall of 1992 and the public announcement of Java in the spring of 1995, around 13 people ended up contributing to the design and evolution of the language. They were going to build a language that could sit on top of the operating systems on the market. This would allow them to be platform agnostic. In 1995, the team announced that the evolution of Mosaic, Netscape Navigator, would provide support for Java. Java gave us Write Once, Run Anywhere platform independence. You could run the code on a Mac, on Solaris, or on Windows. Java derives its syntax from C and many of the object oriented features were influenced by C++. Several of Java's defining characteristics come from—or are responses to—its predecessors. Therefore, Java was meant to build on these and become a simple, object-oriented, distributed, interpreted, robust, secure, architectural neutral, portable, high performance, multithreaded, and dynamic language. Before I forget. The "Mocha Java" blend pairs coffee from Yemen and Java to get a thick, syrupy, and highly caffeinated blend that is often found with a hint of cinnamon or clove. Similar to all other computer language, all innovation in the design of the language was driven by the need to solve a fundamental problem that the preceding languages could not solve. To start, the creation of C is considered by many to have marked the beginning of the modern age of computer languages. It successfully synthesized the conflicting attributes that had so troubled earlier languages. The result was a powerful, efficient, structured language that was relatively easy to learn. It also included one other, nearly intangible aspect: it was a programmer's language. Prior to the invention of C, computer languages were generally designed either as academic exercises or by bureaucratic committees. C was designed, implemented, and developed by real, working programmers, reflecting how they wanted to write code. Its features were honed, tested, thought about, and rethought by the people who actually used the language. C quickly attracted many followers who had a near-religious zeal for it. As such, it found wide and rapid acceptance in the programmer community. In short, C is a language designed by and for programmers, as is Java. Throughout the history of programming, the increasing complexity of programs has driven the need for better ways to manage that complexity. C++ is a response to that need in C. To better understand why managing program complexity is fundamental to the creation of C++, consider that in the early days of programming, computer programing was done by manually toggling in the binary machine instructions by use of the front panel or punching cards. As long as programs were just a few hundred instructions long, this worked. Then came Assembly and Fortran and then But as programs grew, assembly language was invented so that a programmer could deal with larger, increasingly complex programs by using symbolic representations of the machine instructions. As programs continued to grow, high-level languages were introduced that gave the programmer more tools with which to handle complexity. This gave birth to the first popular programing language; FORTRAN. Though impressive it had its shortcomings as it didn't encourage clear and easy-to-understand programs. In the 1960s structured programming was born. This is the method of programming championed by languages such as C. The use of structured languages enabled programmers to write, for the first time, moderately complex programs fairly easily. However, even with structured programming methods, once a project reaches a certain size, its complexity exceeds what a programmer can manage. Due to continued growth, projects were exceeding the limits of the structured approach. To overcome this problem, a new way to program had to be invented; it is called object-oriented programming (OOP). Object-oriented programming (OOP) is a programming methodology that helps organize complex programs through the use of inheritance, encapsulation, and polymorphism. In spite of the fact that C is one of the world's great programming languages, there is still a limit to its ability to handle complexity. Once the size of a program exceeds a certain point, it becomes so complex that it is difficult to grasp as a totality. While the precise size at which this occurs differs, depending upon both the nature of the program and the programmer, there is always a threshold at which a program becomes unmanageable. C++ added features that enabled this threshold to be broken, allowing programmers to comprehend and manage larger programs. So if the primary motivation for creating Java was the need for a platform-independent, architecture-neutral language, it was to create software to be embedded in various consumer electronic devices, such as microwave ovens and remote controls. The developers sought to use a different system to develop the language one which did not require a compiler as C and C++ did. A solution which was easier and more cost efficient. But embedded systems took a backseat when the Web took shape at about the same time that Java was being designed. Java was suddenly propelled to the forefront of computer language design. This could be in the form of applets for the web or runtime-only packages known as Java Runtime Environments, or JREs. At the time, developers had fractured into the three competing camps: Intel, Macintosh, and UNIX. Most software engineers stayed in their fortified boundary. But with the advent of the Internet and the Web, the problem that the portability of software between platforms suddenly got important in ways it hadn't been since the forming of ARPANET. Even though many platforms are attached to the Internet, users would like them all to be able to run the same program. What was once an irritating but low-priority problem had become a high-profile necessity. The team realized this pressing need and later made the switch to refocus Java from embedded, consumer electronics to Internet programming. So while the desire for an architecture-neutral programming language provided the initial spark, the Internet ultimately led to Java's large-scale success. So if Java derives much of its character from C and C++, this is by intent. The original designers knew that using familiar syntax would make their new language appealing to legions of experienced C/C++ programmers. Java also shares some of the other attributes that helped make C and C++ successful. Java was designed, tested, and refined by real, working programmers. Not scientists. Java is a programmer's language. Java is also cohesive and logically consistent. If you program well, your programs reflect it. If you program poorly, your programs reflect that, too. Put differently, Java is not a language with training wheels. It is a language for professional programmers. Java 1 would be released in 1996 for Solaris, Windows, Mac, and Linux. It was released as the Java Development Kit, or JDK, and to this day we still refer to the version we're using as JDK 11. Version 2, or 1.2 came in 1998 and with the rising popularity we had a few things that the burgeoning community needed. These included event listeners, Just In Time compilers, and change thread synchronizations. 1.3, code named Kestrel came in 2000, bringing RMI for CORBA compatibility, synthetic proxy classes, the Java Platform Debugger Architecture, Java Naming and Directory Interface in core libraries, the HostSpot JVM, and Java Sound. Merlin, or 1.4 came in 2002 bringing the frustrating regular expressions, native XML processing, logging, Non-Blocking I/O, and SSL. Tiger, or 1.5 came in 2004. This was important. We could autobox, get compile time type safety in generics, static import the static part of a class, annotations for declarative programming, and run time libraries were mapped into memory - a huge improvements to how JVMs work. Java 5 also gave us the version number change. So JDK 1.5 was officially recognized as Java 5. JDK 1.6, or Mustang, came in 2006. This was a big update, bringing monitoring and management tools, compiler access gave us programmatic access to javac and pluggable annotations allowed us to analyze code semantically as a step before javac compiles the code. WebStart got a makeover and SE 6 unified plugins with webstart. Enhanced XML services would be important (at least until he advent of son) and you could mix javascript up with Java. We also got JDBC 4, Character Large Objects, SwingWorker, JTable, better SQL datatypes, native PKI, Kerberos, LDAP, and honestly the most important thing was that it was stable. Although I've never written code stable enough to encounter their stability issues… Not enough coffee I suppose. Sun purchased Oracle in 2009. Wait, no, that's one of my Marvel What If comic book fantasies where the world was a better place. Oracle bought Sun in 2009. After ponying up $5.6 billion dollars, Oracle had a lot of tech based on Sun products and seeing Sun as an increasingly attractive acquisition target by other companies, Oracle couldn't risk someone else swooping in and buying Sun. With all the turmoil created, it took 5 years during a pretty formative time on the web, but we finally got Dolphin, or 1.7, which came in 2011 and gave us compressed, 64-bit pointers, strings in switch statements, the ability to make a binary integer and use underscores in literals, better graphics APIs, more cryptography algorithms, and a new I/O library that gave even better platform compatibilities. Spider, or 1.8, came along in 2014. We got the ability to Launch JavaFX application Jars, statically-linked JNI libraries, a new date an time API, annotation for java types, unsigned integer arithmetic, a JavaScript runtime that allowed us to embed Javascript code in apps - whether this is a good idea or not is still tbd. Lambda functions had been dropped in Java 7 so here we also got lambda expressions. And this kickstarted a pretty interesting time in the development of Java. We got 9 in 2017, 10 and 11 in 2018, 12, 13, and 14 in 2019. Of these, only 8 and 11 are LTS, or commercial Long Term Support releases, basically meaning we got the next major release after 8 in 2018 and according to my trend line should expect the next LTS in 2021 or 2022. JDK 13, when released later in 2019, will give us text blocks, Switch Expressions, improved memory management by returning unused heap memory to the OS, improves application class and data sharing, and brings back the legacy socket API. But it won't likely be an LTS release. Today there are over 45 billion active Java Virtual Machines and java remains arguably the top language for micro service, ci/cd environments, and a number of other use cases. Other languages have come. Other languages have gone. Many are better in their own right. Some are not. Java is not perfect. It was meant to reduce complexity. But as languages evolve they become more complex. A project with a million lines of code is monolithic and probably incorporates plugins or frameworks like spring security as an example, that make code even more complex. But Java is meant to reduce cyclomatic complexity, to allow for a language that is simple enough for a professional to pick up quickly and only be as complex as the quality of the code being compiled. I don't personally love Java. I respect it. And I adore high-quality programmers and their code in any language. But I've had to redo so much work because other languages have come and gone over the years that if I were to be starting a new big monolithic web-app today, I'd probably use Java every time. Which isn't to say that Java isn't useful in micro-service architectures. According to what's required from the contract testing on a service, I might use Java, Go, node, python or even the formerly hipster Ruby. Although I don't love drinking PBR… If I'm writing an Android app, I need to know Java. No matter what the lawyers say. If I'm planning on an enterprise webapp, Java needs to be in the conversation. But usually, I can do the work in a fraction of the time using something like python. But most big companies speak Java. And for good reason. Because of the write once run anywhere approach and the level of permissions a JRE needs, there have been security challenges with running Java on desktop computers. Apple deprecated Java on the Mac in 2010. Users could still instal lications and is the gold standard for those. I'm certainly not advocating going back to the 90s and running Java apps on our desktops any more. No matter what you think of Java, one thing you have to admit, the introduction of the language and the evolution have had a substantial impact on the IT industry and it will continue to do so. A great takeaway here might be that there's always a potential alternative that might be better suited for a given task. But when it comes to choosing a platform that will be there in a decade or 3, getting support, getting a team that can scale, sometimes you might end up using a solution that doesn't immediately seem as well suited to a need. But it can get the job done. As it's been doing since James Gosling and the rest of the team started the project back in the early 90s. So thank you listeners, for sticking with us through this episode of the History of Computing Podcast. We're lucky to have you.

An airhacks.fm conversation with Dimitris Andreadis (@dandreadis) about: Amstrad CPC 484, but Commodore had better games, learning BASIC driven by lack of games, hacking game loaders, C is the favourite language, with C you have the full control, C is concise, ISO DEE, writing ISO network layers in Ireland, writing reactive code in 1994, beautiful C code, processing bibliographic data with DSLs, maintaining passion and fun at indexdata.dk, enjoying the time at navy, clueless mainframe operators, writing programs in COBOL instead of queries, PDP 11 as simulator for naval training, writing application servers in C++ for telecom, EJB-like components in C++, Java UIs in 1998, Java should be good enough for writing service provisoning platforms, accidental discovery of Java Management Extension (JMX), first Java impression was not as good, JBoss was a heavy JMX user, JBoss was always manageable because of JMX, Rickard Öberg was a genious, dynamic kernel with dynamic extensions, Marc Fleury started JBoss, JBoss 2 was a rewrite, JBoss 2 kernel was the base for project "Junction" renamed to Action Streamer, JBoss became more interesting than the day job, core JBoss developer since 2004, CORBA / CSIv2 skills were needed for J2EE certification, transferring transactions and security context with CORBA extensions, JBoss was the first J2EE certified server, Dimitris was project lead for JBoss 4 and 5, later manager, now responsible for Thorntail, Vertx and Quarkus, in JBoss CORBA objects were dynamically generated, the paper: "The JBoss Extensible Server" from brazilian professor, Thrift, gRPC and Co. are CORBA, just reinvented, CORBA network layer is very efficient, EJBs killed CORBA, JBoss unified the web container and EJB container in a single JVM to prevent remote communication, microservices are distributed, sometimes unnecessarily, EJBs and WebContainers had to split into separate JVMs back then as well, Quarkus is the exact opposite of WildFly, Quarkus and WildFly also have different goals, the WildFly.next discussions at RedHat, Jason Greene and Bob McWhirter had WildFly discussions, Emanuel proposed a single runtime for everyone, the one base runtime for everyone prototype, SubstrateVM produced the best native code, Hibernate on Quarkus was a break-through, Quarkus is a collective, interdisciplinary effort at RedHat, Quarkus started in spring 2018, Quarkus pushes the Java EE deployment model further and the optimisations are collateral, Quarkus looks and feels like Java EE or MicroProfile, Quarkus does not require proprietary imports, Quarkus went for native optimization, and optimized HotSpot JVM as well, Quarkus build makes code less memory hungry at HotSpot, Quarkus takes have of the memory with fast startup time, Quarkus comes also with runtime improvements in HotSpot and native mode, the idea for build-time optimizations started at WildFly, with pre-computing the deployment model, Quarkus extension model allows the integration of 3rd-party code for native compilation, Quarkus development mode comes with scripting-like experience, Quarkus FatJars aren't fat, nor self-contained, Quarkus runner-jars are optimized for Docker and so clouds, Quarkus offers imerative and reactive APIs, Netty, Vert.x and Undertow are unified inside Quarkus, Panache ORM is an experiment, but could become a MicroProfile or Jakarta EE standard, working with standards is difficult, Quarkus pushes standards further, developers hack the code first, then standard comes, writing Kubernetes operators with Quarkus Dimitris Andreadis on twitter: @dandreadis, an dandreadis.blogspot.com

NHL-Tugg avsnitt 49! I dagens program är Anders tillbaka och bildar full panel med Tomas och Andreas. Vi pratar om de senaste nyheterna, JVMs första matcher, delar ut utmärkelser halvvägs in på säsongen, delar ut julklappar, diskuterar vart Jack Hughes hade passat bäst, talangkollen och mycket mer! 

In this session, we discussed advances on cloud deployed JVMs with respect to hardware acceleration (GPUs, FPGAs) and lightweight AOT deployments.

I samband med JVMs avslutning satte vi oss ner och snickrade ihop ett nyt avsnitt Eldebrink. Håll till godo! Ladda ner: Laineing up a check Speltid:90 min, Storlek:80 Mb Medverkande: Anton Bjurvald, Henrik Kaveryd, Björn Lager

This “weeks” argument was recorded on the Back to the Future day, and then eventually edited and published a long overdue time later… That’s time travel. Garbage Collection in Go Java Garbage Collectors Adding Rusts Ownership model to Java? Java 9 - State of the Java Module System Java 9 and Beyond with Jigsaw and JLink “Layers” for supporting different versions of modules during a JVMs lifespan. Described in the State of The Modules. Ceylon uses JBoss Modules - “ceylon war” generates a war file containing all of your modules. maven-dependency-plugin - Dependency Convergence SemVer is a fail.