Podcasts about j2ee

An airhacks.fm conversation with Phillip Krueger (@phillipkruger) about: early programming experiences with Visual Basic and Java, transition from actuarial science to computer science, first job at a bank working with Java Swing and RMI over CORBA, experience with J2EE and XML technologies, working with XML and XSLT, development of open-source Swing components, work on dotMobi sites for mobile phones in Africa, creation of API extensions for Java EE and MicroProfile, involvement in the MicroProfile GraphQL specification, joining Red Hat and working on quarkus, development of SmallRye GraphQL, improvements to OpenAPI support in Quarkus, work on Quarkus Dev UI, discussion about the evolution of Java application servers and frameworks, comparison of REST and GraphQL, thoughts on Java development culture in South Africa Phillip Krueger on twitter: @phillipkruger

An airhacks.fm conversation with Vadym Kazulkin (@VKazulkin) about: journey as a Java developer from the late 1990s to present, early experiences with Java and J2EE development, transition to cloud and serverless technologies, particularly AWS Lambda, discussion of Java performance on lambda compared to node.js, detailed explanation of AWS SnapStart technology for improving Java cold starts, pros and cons of "fat" Lambda functions versus microservices, challenges of using GraalVM with Lambda, importance of optimizing Lambda package size and dependencies, comparison of quarkus and Spring Boot on Lambda, benefits of serverless architecture for business logic focus, involvement with Java User Group Bonn and AWS Community Builder program, brief mention of asynchronous patterns in serverless architectures, importance of staying technically hands-on as a manager in the rapidly evolving cloud world Vadym Kazulkin on twitter: @VKazulkin

On the pod this week, Zach hosts the Director of UI Engineering at Procore, Chris Cantu. Zach and Chris discuss Generative AI's place in engineering teams, like the ones Chris leads daily. He sees its benefit especially for junior engineers, bringing them up to speed quickly and teaching new patterns of dev. There's no question, Gen AI tools like ChatGPT and Code Pilot are powerful tools that should be used... responsibly. Listen as we dive into the nuances of what that looks like in the real world. Like, Subscribe, and Follow: YouTube: https://www.youtube.com/channel/UCAIUNkXmnAPgLWnqUDpUGAQ LinkedIn: https://www.linkedin.com/company/keyhole-software Twitter: @KeyholeSoftware Find even more Keyhole content on our website (https://keyholesoftware.com/). About Chris: Chris has a wide variety of experiences in different industries and technologies including energy, education, financial, government, and web hosting. His technology experience includes J2EE, Grails, Software as a Service, and Front End Engineering. He has architected and built web applications/solutions for customer-driven sites such as irs.gov and my.rackspace.com. He prefers to solve the root cause of a problem in order to best meet his customers' needs. LinkedIn: https://www.linkedin.com/in/christophercantu/

Welcome to the newest episode of The Cloud Pod podcast! Justin, Ryan, Jonathan, Matthew and Peter are your hosts this week as we discuss all things cloud and AI,  Titles we almost went with this week: The Cloud Pod is better than Bob's Used Books The Cloud Pod sets up AWS notifications for all The Cloud Pod is non-differential about privacy in BigQuery The Cloud Pod finds Windows Bob The Cloud Pod starts preparing for its Azure Emergency today A big thanks to this week's sponsor: Foghorn Consulting, provides top-notch cloud and DevOps engineers to the world's most innovative companies. Initiatives stalled because you have trouble hiring?  Foghorn can be burning down your DevOps and Cloud backlogs as soon as next week.

Summary The promise of streaming data is that it allows you to react to new information as it happens, rather than introducing latency by batching records together. The peril is that building a robust and scalable streaming architecture is always more complicated and error-prone than you think it's going to be. After experiencing this unfortunate reality for themselves, Abhishek Chauhan and Ashish Kumar founded Grainite so that you don't have to suffer the same pain. In this episode they explain why streaming architectures are so challenging, how they have designed Grainite to be robust and scalable, and how you can start using it today to build your streaming data applications without all of the operational headache. Announcements Hello and welcome to the Data Engineering Podcast, the show about modern data management Businesses that adapt well to change grow 3 times faster than the industry average. As your business adapts, so should your data. RudderStack Transformations lets you customize your event data in real-time with your own JavaScript or Python code. Join The RudderStack Transformation Challenge today for a chance to win a $1,000 cash prize just by submitting a Transformation to the open-source RudderStack Transformation library. Visit dataengineeringpodcast.com/rudderstack (https://www.dataengineeringpodcast.com/rudderstack) today to learn more Hey there podcast listener, are you tired of dealing with the headache that is the 'Modern Data Stack'? We feel your pain. It's supposed to make building smarter, faster, and more flexible data infrastructures a breeze. It ends up being anything but that. Setting it up, integrating it, maintaining it—it's all kind of a nightmare. And let's not even get started on all the extra tools you have to buy to get it to do its thing. But don't worry, there is a better way. TimeXtender takes a holistic approach to data integration that focuses on agility rather than fragmentation. By bringing all the layers of the data stack together, TimeXtender helps you build data solutions up to 10 times faster and saves you 70-80% on costs. If you're fed up with the 'Modern Data Stack', give TimeXtender a try. Head over to dataengineeringpodcast.com/timextender (https://www.dataengineeringpodcast.com/timextender) where you can do two things: watch us build a data estate in 15 minutes and start for free today. Join in with the event for the global data community, Data Council Austin. From March 28-30th 2023, they'll play host to hundreds of attendees, 100 top speakers, and dozens of startups that are advancing data science, engineering and AI. Data Council attendees are amazing founders, data scientists, lead engineers, CTOs, heads of data, investors and community organizers who are all working together to build the future of data. As a listener to the Data Engineering Podcast you can get a special discount of 20% off your ticket by using the promo code dataengpod20. Don't miss out on their only event this year! Visit: dataengineeringpodcast.com/data-council (https://www.dataengineeringpodcast.com/data-council) today Your host is Tobias Macey and today I'm interviewing Ashish Kumar and Abhishek Chauhan about Grainite, a platform designed to give you a single place to build streaming data applications Interview Introduction How did you get involved in the area of data management? Can you describe what Grainite is and the story behind it? What are the personas that you are focused on addressing with Grainite? What are some of the most complex aspects of building streaming data applications in the absence of something like Grainite? How does Grainite work to reduce that complexity? What are some of the commonalities that you see in the teams/organizations that find their way to Grainite? What are some of the higher-order projects that teams are able to build when they are using Grainite as a starting point vs. where they would be spending effort on a fully managed streaming architecture? Can you describe how Grainite is architected? How have the design and goals of the platform changed/evolved since you first started working on it? What does your internal build vs. buy process look like for identifying where to spend your engineering resources? What is the process for getting Grainite set up and integrated into an organizations technical environment? What is your process for determining which elements of the platform to expose as end-user features and customization options vs. keeping internal to the operational aspects of the product? Once Grainite is running, can you describe the day 0 workflow of building an application or data flow? What are the day 2 - N capabilities that Grainite offers for ongoing maintenance/operation/evolution of those applications? What are the most interesting, innovative, or unexpected ways that you have seen Grainite used? What are the most interesting, unexpected, or challenging lessons that you have learned while working on Grainite? When is Grainite the wrong choice? What do you have planned for the future of Grainite? Contact Info Ashish LinkedIn (https://www.linkedin.com/in/ashishkumarprofile/) Abhishek LinkedIn (https://www.linkedin.com/in/abhishekchauhan/) Parting Question From your perspective, what is the biggest gap in the tooling or technology for data management today? Closing Announcements Thank you for listening! Don't forget to check out our other shows. Podcast.__init__ (https://www.pythonpodcast.com) covers the Python language, its community, and the innovative ways it is being used. The Machine Learning Podcast (https://www.themachinelearningpodcast.com) helps you go from idea to production with machine learning. Visit the site (https://www.dataengineeringpodcast.com) to subscribe to the show, sign up for the mailing list, and read the show notes. If you've learned something or tried out a project from the show then tell us about it! Email hosts@dataengineeringpodcast.com (mailto:hosts@dataengineeringpodcast.com)) with your story. To help other people find the show please leave a review on Apple Podcasts (https://podcasts.apple.com/us/podcast/data-engineering-podcast/id1193040557) and tell your friends and co-workers Links Grainite (https://www.grainite.com/) Blog about the challenges of streaming architectures (https://www.grainite.com/blog/there-was-an-old-lady-who-swallowed-a-fly) Getting Started Docs (https://gitbook.grainite.com/developers/getting-started) BigTable (https://research.google/pubs/pub27898/) Spanner (https://research.google/pubs/pub39966/) Firestore (https://cloud.google.com/firestore) OpenCensus (https://opencensus.io/) Citrix (https://www.citrix.com/) NetScaler (https://www.citrix.com/blogs/2022/10/03/netscaler-is-back/) J2EE (https://www.oracle.com/java/technologies/appmodel.html) RocksDB (https://rocksdb.org/) Pulsar (https://pulsar.apache.org/) SQL Server (https://en.wikipedia.org/wiki/Microsoft_SQL_Server) MySQL (https://www.mysql.com/) RAFT Protocol (https://raft.github.io/) The intro and outro music is from The Hug (http://freemusicarchive.org/music/The_Freak_Fandango_Orchestra/Love_death_and_a_drunken_monkey/04_-_The_Hug) by The Freak Fandango Orchestra (http://freemusicarchive.org/music/The_Freak_Fandango_Orchestra/) / CC BY-SA (http://creativecommons.org/licenses/by-sa/3.0/)

An airhacks.fm conversation with Ralph Soika (@rsoika) about: Starting programming with Atari 600XL The thick book: My Atari XL Computer - Learning Basic, programming print hello, GOTO 10, publishing and developing a Moon Lander game in a magazine, developing logistics software, starting a company to develop Lotus Domino solutions, starting with Delphi, then transitioning to Java, starting with Java 1.0, implementing a Java backend for Lotus Domino, writing Java agents for Lotus Domino server CouchDB is based on Lotus Notes, the Groove peer to peer software, programming Java applets and Swing applications, implementing workflow modeller with Eclipse, founding the imixs company, building to build a workflow engine on J2EE, removing code with every release of Java EE, the 106th airhacks.tv and is Java EE dead?, building a human-centric workflow engine, ACL on documents for confidential data processing, learning from Louts Notes, Java Persistence API and PostgreSQL, fast queries with Blobs, Apache Lucene and PostgreSQL, kubernetes in the cloud and on premise, AWS ECS Fargate, AWS App Runner, Azure Container Instances, Azure App Service, managed alternatives in the clouds Ralph Soika on twitter: @rsoika

If you're confused about Jakarta EE vs. Java EE vs. J2EE, then check out this episode. Learn why Spring Boot 3 and Spring Framework 6 are picking up Jakarta EE 9 and how else this impacts YOUR next application! ==== Don't forget to pre-order your copy of Learning Spring Boot 3.0 3rd Edition today at https://springbootlearning.com/book! ==== RESOURCES:

An airhacks.fm conversation with Carson Gross (@htmx_org) about: Apple IIgs and HyperTalk, _hyperscript, starting with VBA then using Java, EJB 1.0 and J2EE, gosu, gscript, implementing Ruby on Rails, teaching at The Montana State University, Java got lots os stuff right, javalin and jobrunr, Java and Ruby on Rails, NodeJS became more appealing to Ruby on Rails developers, Yukihiro Matsumoto created Ruby, performance challenge with sorting rows in a table, JQuery get function, the intercooler.js library, intercooler is the competitor of turbolinks, WebComponents and CustomElements, BCE and the bce.design template, BCE follows the data API approach, htmx works with data attributes, the popularity of Angular, GWT was popular, htmx renders HTML directly, htmx follows HATEOAS, HATEAOS is stateless - the response already contains all possible actions, Roy Fielding coined the term REST, web was designed for coarse grained interactions, with hypermedia approach messages are self-descriptive - API versioning is easier to maintain, htmx encourages use of Java, JSPs with WebComponents (link to youtube ), the Quarkus Renarde web framework, implementation of authorization and authentication with htmx, GraphQL gives developers and users a lot of power - which can be a security issue, GraphQL requires the implementation of resolves, how to version a data API, Stefan Tilkov and resource oriented architectures ROAs, endless scrolling with htmx is easy to implement, htmx on discord Carson Gross on twitter: @htmx_org, carson's company: Big Sky Software

An airhacks.fm conversation with Goran Opacic (@goranopacic) about: ZX Spectrum with 9 years, fortran listings as a present, Basic programming on Atari, Manic Miner and Jet Set Willy on Amstrad CPC 64, Defender of the Crown, printing with C 64, desktop publishing with Atari 520 ST and Calamus, testing the first website in 1993, using UUCP to split files into emails, drawing maps with Java Applets in browser, 17 years old code as Java AWS Lambda, Cloud Development Kit - applying the Java knowledge to the clouds, Jakarta EE and MicroProfile in the clouds, in the clouds there are different possibilities, mobile sales application with esteh, the serverless Tomcat, hetzner provides hosting services, no vacuuming on databases, how to become an AWS Data Hero, attending airhacks.com at MUC airport, serverless quarkus in the clouds, OpenLiberty for Java EE, building AWS Lambdas with Quarkus, Infrastructure as Code and CDK with Java, the cloud has limits, self-mutating CodePipelines, every AWS service has well-documented limits, EC 2 spot instances for GraalVM compilations, plain Java SE for asynchronous Lambdas, Goran Opacic on twitter: @goranopacic, Goran's blog: madabout.cloud

Mark Herschberg Author of the soon to be best seller "The Career Toolkit" https://www.thecareertoolkitbook.com/ which shows you how to design and execute your personal plan to achieve the career you deserve. available at https://www.amazon.com/Career-Toolkit-Mark-Herschberg/dp/0960100741/ He is sits on the board of directors for TechieYouth https://www.techieyouth.org/, which helps foster kids & at-risk youth become self-sufficient IT/tech professionals. About Mark Herschberg https://www.linkedin.com/in/hershey/ Currently doing fractional CTO work as I market my book and speak at events but open to additional contract or returning to full time around the end of 2021 / start of 2022 Seasoned executive and cybersecurity expert who can bridge the divide between business and technology. I have started, grown, and fixed startup companies spanning 10 different verticals as well as helped two Fortune 500 companies with their internal startup initiatives, and helped create educational programs at MIT and HBS. I typically lead engineering, product, and data science. Technologies (and other keywords): Proficient: Ruby on Rails (RoR), MySQL, Mongo, AWS, GCE, Redis, Hadoop, Git, REST / RESTful, Design Patterns, Microservices, Service Oriented Architecture (SOA), Git Rusty: Java, J2EE, J2ME, Spring, Hibernate, Puppet, R, ELK, Storm, Pig, Hive, Javascript, JQuery, Ajax, Heroku, SVN Managed: Python, Django, GitLab, kubernetes (k8s), docker, C#, .NET, PHP, React, Angular, Postgres, Ansible, Chef Server OS: Linux, Unix, Ubuntu, CentOS, Windows Compliance: HIPAA, CCPA, GDPR, PCI Cybersecurity, authentication, identity, red team. blue team, purple team. #leadership, #networking, #worktrends, #communication, and #professionaldevelopment --- Send in a voice message: https://anchor.fm/getajobintech/message Support this podcast: https://anchor.fm/getajobintech/support

About RobertR2 advocates for Liquibase customers and provides technical architecture leadership. Prior to co-founding Datical (now Liquibase), Robert was a Director at the Austin Technology Incubator. Robert co-founded Phurnace Software in 2005. He invented and created the flagship product, Phurnace Deliver, which provides middleware infrastructure management to multiple Fortune 500 companies.Links: Liquibase: https://www.liquibase.com Liquibase Community: https://www.liquibase.org Liquibase AWS Marketplace: https://aws.amazon.com/marketplace/seller-profile?id=7e70900d-dcb2-4ef6-adab-f64590f4a967 Github: https://github.com/liquibase Twitter: https://twitter.com/liquibase TranscriptAnnouncer: Hello, and welcome to Screaming in the Cloud with your host, Chief Cloud Economist at The Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud.Corey: It seems like there is a new security breach every day. Are you confident that an old SSH key, or a shared admin account, isn't going to come back and bite you? If not, check out Teleport. Teleport is the easiest, most secure way to access all of your infrastructure. The open source Teleport Access Plane consolidates everything you need for secure access to your Linux and Windows servers—and I assure you there is no third option there. Kubernetes clusters, databases, and internal applications like AWS Management Console, Yankins, GitLab, Grafana, Jupyter Notebooks, and more. Teleport's unique approach is not only more secure, it also improves developer productivity. To learn more visit: goteleport.com. And not, that is not me telling you to go away, it is: goteleport.com. Corey: You know how Git works right?Announcer: Sorta, kinda, not really. Please ask someone else.Corey: That's all of us. Git is how we build things, and Netlify is one of the best ways I've found to build those things quickly for the web. Netlify's Git-based workflows mean you don't have to play slap-and-tickle with integrating arcane nonsense and web hooks, which are themselves about as well understood as Git. Give them a try and see what folks ranging from my fake Twitter for Pets startup, to global Fortune 2000 companies are raving about. If you end up talking to them—because you don't have to; they get why self-service is important—but if you do, be sure to tell them that I sent you and watch all of the blood drain from their faces instantly. You can find them in the AWS marketplace or at www.netlify.com. N-E-T-L-I-F-Y dot com.Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn. This is a promoted episode. What does that mean in practice? Well, it means the company who provides the guest has paid to turn this into a discussion that's much more aligned with the company than it is the individual.Sometimes it works, Sometimes it doesn't, but the key part of that story is I get paid. Why am I bringing this up? Because today's guest is someone I met in person at Monktoberfest, which is the RedMonk conference in Portland, Maine, one of the only reasons to go to Maine, speaking as someone who grew up there. And I spoke there, I met my guest today, and eventually it turned into this, proving that I am the envy of developer advocates everywhere because now I can directly tie me attending one conference to making a fixed sum of money, and right now they're all screaming and tearing off their headphones and closing this episode. But for those of you who are sticking around, thank you. My guest today is the CTO and co-founder of Liquibase. Please welcome Robert Reeves. Robert, thank you for joining me, and suffering the slings and arrows I'm about to hurled directly into your arse, as a warning shot.Robert: [laugh]. Man. Thanks for having me. Corey, I've been looking forward to this for a while. I love hanging out with you.Corey: One of the things I love about the Monktoberfest conference, and frankly, anything that RedMonk gets up to is, forget what's on stage, which is uniformly excellent; forget the people at RedMonk who are wonderful and I aspire to do more work with them in different ways; they're great, but the people that they attract are invariably interesting, they are invariably incredibly diverse in terms of not just demographics, but interests and proclivities. It's just a wonderful group of people, and every time I get the opportunity to spend time with those folks I do, and I've never once regretted it because I get to meet people like you. Snark and cynicism about sponsoring this nonsense aside—for which I do thank you—you've been a fascinating person to talk to you because you're better at a lot of the database-facing things than I am, so I shortcut to instead of forming my own opinions, I just skate off of yours in some cases. You're going to get letters now.Robert: Well, look, it's an occupational hazard, right? Releasing software, it's hard so you have to learn these platforms, and part of it includes the database. But I tell you, you're spot on about Monktoberfest. I left that conference so motivated. Really opened my eyes, certainly injecting empathy into what I do on a day-to-day basis, but it spurred me to action.And there's a lot of programs that we've started at Liquibase that the germination for that seed came from Monktoberfest. And certainly, you know, we were bummed out that it's been canceled two years in a row, but we can't wait to get back and sponsor it. No end of love and affection for that team. They're also really smart and right about a hundred percent of the time.Corey: That's the most amazing part is that they have opinions that generally tend to mirror my own—which, you know—Robert: [laugh].Corey: —confirmation bias is awesome, but they almost never get it wrong. And that is one of the impressive things is when I do it, I'm shooting from the hip and I already have an apology half-written and ready to go, whereas when dealing with them, they do research on this and they don't have the ‘I'm a loud, abrasive shitpostter on Twitter' defense to fall back on to defend opinions. And if they do, I've never seen them do it. They're right, and the fact that I am as aligned with them as I am, you'd think that one of us was cribbing from the other. I assure you that's not the case.But every time Steve O'Grady or Rachel Stephens, or Kelly—I forget her last name; my apologies is all Twitter, but she studied medieval history, I remember that—or James Governor writes something, I'm uniformly looking at this and I feel a sense of dismay, been, “Dammit. I should have written this. It's so well written and it makes such a salient point.” I really envy their ability to be so consistently on point.Robert: Well, they're the only analysts we pay money to. So, we vote with our dollars with that one. [laugh].Corey: Yeah. I'm only an analyst when people have analyst budget. Other than that, I'm whatever the hell you describe me. So, let's talk about that thing you're here to show. You know, that little side project thing you found and are the CTO of.I wasn't super familiar with what Liquibase does until I looked into it and then had this—I got to say, it really pissed me off because I'm looking at it, and it's how did I not know that this existed back when the exact problems that you solve are the things I was careening headlong into? I was actively annoyed. You're also an open-source project, which means that you're effectively making all of your money by giving things away and hoping for gratitude to come back on you in the fullness of time, right?Robert: Well, yeah. There's two things there. They're open-source component, but also, where was this when I was struggling with this problem? So, for the folks that don't know, what Liquibase does is automate database schema change. So, if you need to update a database—I don't care what it is—as part of your application deployment, we can help.Instead of writing a ticket or manually executing a SQL script, or generating a bunch of docs in a NoSQL database, you can have Liquibase help you out with that. And so I was at a conference years ago, at the booth, doing my booth thing, and a managing director of a very large bank came to me, like, “Hey, what do you do?” And saw what we did and got angry, started yelling at me. “Where were you three years ago when I was struggling with this problem?” Like, spitting mad. [laugh]. And I was like, “Dude, we just started”—this was a while ago—it was like, “We just started the company two years ago. We got here as soon as we could.”But I struggled with this problem when I was a release manager. And so I've been doing this for years and years and years—I don't even want to talk about how long—getting bits from dev to test to production, and the database was always, always, always the bottleneck, whether it was things didn't run the same in test as they did, eventually in production, environments weren't in sync. It's just really hard. And we've automated so much stuff, we've automated application deployment, lowercase a compiled bits; we're building things with containers, so everything's in that container. It's not a J2EE app anymore—yay—but we haven't done a damn thing for the database.And what this means is that we have a whole part of our industry, all of our database professionals, that are frankly struggling. I always say we don't sell software Liquibase. We sell piano recitals, date nights, happy hours, all the stuff you want to do but you can't because you're stuck dealing with the database. And that's what we do at Liquibase.Corey: Well, you're talking about database people. That's not how I even do it. I would never call myself that, for very good reason because you know, Route 53 remains the only database I use. But the problem I always had was that, “Great. I'm doing a deployment. Oh, I'm going to put out some changes to some web servers. Okay, what's my rollback?” “Well, we have this other commit we can use.” “Oh, we're going to be making a database schema change. What's your rollback strategy,” “Oh, I've updated my resume and made sure that any personal files I had on my work laptop been backed up somewhere else when I immediately leave the company when we can't roll back.” Because there's not really going to be a company anymore at that point.It's one of those everyone sort of holds their breath and winces when it comes to anything that resembles a schema change—or an ALTER TABLE as we used to call it—because that is the mistakes will show territory and you can hope and plan for things in pre-prod environments, but it's always scary. It's always terrifying because production is not like other things. That's why I always call my staging environment ‘theory' because things work in theory but not in production. So, it's how do you avoid the mess of winding up just creating disasters when you're dealing with the reality of your production environments? So, let's back up here. How do you do it? Because it sounds like something people would love to sell me but doesn't exist.Robert: [laugh]. Well, it's real simple. We have a file, we call it the change log. And this is a ledger. So, databases need to be evolved. You can't drop everything and recreate it from scratch, so you have to apply changes sequentially.And so what Liquibase will do is it connects to the database, and it says, “Hey, what version are you?” It looks at the change log, and we'll see, ehh, “There's ten change sets”—that's what components of a change log, we call them change sets—“There's ten change sets in there and the database is telling me that only five had been executed.” “Oh, great. Well, I'll execute these other five.” Or it asks the database, “Hey, how many have been executed?” And it says, “Ten.”And we've got a couple of meta tables that we have in the database, real simple, ANSI SQL compliant, that store the changes that happen to the database. So, if it's a net new database, say you're running a Docker container with the database in it on your local machine, it's empty, you would run Liquibase, and it says, “Oh, hey. It's got that, you know, new database smell. I can run everything.”And so the interesting thing happens when you start pointing it at an environment that you haven't updated in a while. So, dev and test typically are going to have a lot of releases. And so there's going to be little tiny incremental changes, but when it's time to go to production, Liquibase will catch it up. And so we speak SQL to the database, if it's a NoSQL database, we'll speak their API and make the changes requested. And that's it. It's very simple in how it works.The real complex stuff is when we go a couple of inches deeper, when we start doing things like, well, reverse engineering of your database. How can I get a change log of an existing database? Because nobody starts out using Liquibase for a project. You always do it later.Corey: No, no. It's one of those things where when you're doing a project to see if it works, it's one of those, “Great, I'll run a database in some local Docker container or something just to prove that it works.” And, “Todo: fix this later.” And yeah, that todo becomes load-bearing.Robert: [laugh]. That's scary. And so, you know, we can help, like, reverse engineering an entire database schema, no problem. We also have things called quality checks. So sure, you can test your Liquibase change against an empty database and it will tell you if it's syntactically correct—you'll get an error if you need to fix something—but it doesn't enforce things like corporate standards. “Tables start with T underscore.” “Do not create a foreign key unless those columns have an ID already applied.” And that's what our quality checks does. We used to call it rules, but nobody likes rules, so we call it quality checks now.Corey: How do you avoid the trap of enumerating all the bad things you've seen happen because at some point, it feels like that's what leads to process ossification at large companies where, “Oh, we had this bad thing happen once, like, a disk filled up, so now we have a check that makes sure that all the disks are at least 20, empty.” Et cetera. Great. But you keep stacking those you have thousands and thousands and thousands of those, and even a one-line code change then has to pass through so many different tests to validate that this isn't going to cause the failure mode that happened that one time in a unicorn circumstance. How do you avoid the bloat and the creep of stuff like that?Robert: Well, let's look at what we've learned from automated testing. We certainly want more and more tests. Look, DevOp's algorithm is, “All right, we had a problem here.” [laugh]. Or SRE algorithm, I should say. “We had a problem here. What happened? What are we going to change in the future to make sure this doesn't happen?” Typically, that involves a new standard.Now, ossification occurs when a person has to enforce that standard. And what we should do is seek to have automation, have the machine do it for us. Have the humans come up and identify the problem, find a creative way to look for the issue, and then let the machine enforce it. Ossification happens in large organizations when it's people that are responsible, not the machine. The machines are great at running these things over and over again, and they're never hung over, day after Super Bowl Sunday, their kid doesn't get sick, they don't get sick. But we want humans to look at the things that we need that creative energy, that brain power on. And then the rote drudgery, hand that off to the machine.Corey: Drudgery seems like sort of a job description for a lot of us who spend time doing operation stuff.Robert: [laugh].Corey: It's drudgery and it's boring, punctuated by moments of sheer terror. On some level, you're more or less taking some of the adrenaline high of this job away from people. And you know, when it comes to databases, I'm kind of okay with that as it turns out.Robert: Yeah. Oh, yeah, we want no surprises in database-land. And that is why over the past several decades—can I say several decades since 1979?Corey: Oh, you can s—it's many decades, I'm sorry to burst your bubble on that.Robert: [laugh]. Thank you, Corey. Thank you.Corey: Five, if we're being honest. Go ahead.Robert: So, it has evolved over these many decades where change is the enemy of stability. And so we don't want change, and we want to lock these things down. And our database professionals have become changed from sentinels of data into traffic cops and TSA. And as we all know, some things slip through those. Sometimes we speed, sometimes things get snuck through TSA.And so what we need to do is create a system where it's not the people that are in charge of that; that we can set these policies and have our database professionals do more valuable things, instead of that adrenaline rush of, “Oh, my God,” how about we get the rush of solving a problem and saving the company millions of dollars? How about that rush? How about the rush of taking our old, busted on-prem databases and figure out a way to scale these up in the cloud, and also provide quick dev and test environments for our developer and test friends? These are exciting things. These are more fun, I would argue.Corey: You have a list of reference customers on your website that are awesome. In fact, we share a reference customer in the form of Ticketmaster. And I don't think that they will get too upset if I mention that based upon my work with them, at no point was I left with the impression that they played fast and loose with databases. This was something that they take very seriously because for any company that, you know, sells tickets to things you kind of need an authoritative record of who's bought what, or suddenly you don't really have a ticket-selling business anymore. You also reference customers in the form of UPS, which is important; banks in a variety of different places.Yeah, this is stuff that matters. And you support—from the looks of it—every database people can name except for Route 53. You've got RDS, you've got Redshift, you've got Postgres-squeal, you've got Oracle, Snowflake, Google's Cloud Spanner—lest people think that it winds up being just something from a legacy perspective—Cassandra, et cetera, et cetera, et cetera, CockroachDB. I could go on because you have multiple pages of these things, SAP HANA—whatever the hell that's supposed to be—Yugabyte, and so on, and so forth. And it's like, some of these, like, ‘now you're just making up animals' territory.Robert: Well, that goes back to open-source, you know, you were talking about that earlier. There is no way in hell we could have brought out support for all these database platforms without us being open-source. That is where the community aligns their goals and works to a common end. So, I'll give you an example. So, case in point, recently, let me see Yugabyte, CockroachDB, AWS Redshift, and Google Cloud Spanner.So, these are four folks that reached out to us and said, either A) “Hey, we want Liquibase to support our database,” or B) “We want you to improve the support that's already there.” And so we have what we call—which is a super creative name—the Liquibase test harness, which is just genius because it's an automated way of running a whole suite of tests against an arbitrary database. And that helped us partner with these database vendors very quickly and to identify gaps. And so there's certain things that AWS Redshift—certain objects—that AWS Redshift doesn't support, for all the right reasons. Because it's data warehouse.Okay, great. And so we didn't have to run those tests. But there were other tests that we had to run, so we create a new test for them. They actually wrote some of those tests. Our friends at Yugabyte, CockroachDB, Cloud Spanner, they wrote these extensions and they came to us and partnered with us.The only way this works is with open-source, by being open, by being transparent, and aligning what we want out of life. And so what our friends—our database friends—wanted was they wanted more tooling for their platform. We wanted to support their platform. So, by teaming up, we help the most important person, [laugh] the most important person, and that's the customer. That's it. It was not about, “Oh, money,” and all this other stuff. It was, “This makes our customers' lives easier. So, let's do it. Oop, no brainer.”Corey: There's something to be said for making people's lives easier. I do want to talk about that open-source versus commercial divide. If I Google Liquibase—which, you know, I don't know how typing addresses in browsers works anymore because search engines are so fast—I just type in Liquibase. And the first thing it spits me out to is liquibase.org, which is the Community open-source version. And there's a link there to the Pro paid version and whatnot. And I was just scrolling idly through the comparison chart to see, “Oh, so ‘Community' is just code for shitty and you're holding back advanced features.” But it really doesn't look that way. What's the deal here?Robert: Oh, no. So, Liquibase open-source project started in 2006 and Liquibase the company, the commercial entity, started after that, 2012; 2014, first deal. And so, for—Nathan Voxland started this, and Nathan was struggling. He was working at a company, and he had to have his application—of course—you know, early 2000s, J2EE—support SQL Server and Oracle and he was struggling with it. And so he open-sourced it and added more and more databases.Certainly, as open-source databases grew, obviously he added those: MySQL, Postgres. But we're never going to undo that stuff. There's rollback for free in Liquibase, we're not going to be [laugh] we're not going to be jerks and either A) pull features out or, B) even worse, make Stephen O'Grady's life awful by changing the license [laugh] so he has to write about it. He loves writing about open-source license changes. We're Apache 2.0 and so you can do whatever you want with it.And we believe that the things that make sense for a paying customer, which is database-specific objects, that makes sense. But Liquibase Community, the open-source stuff, that is built so you can go to any database. So, if you have a change log that runs against Oracle, it should be able to run against SQL Server, or MySQL, or Postgres, as long as you don't use platform-specific data types and those sorts of things. And so that's what Community is about. Community is about being able to support any database with the same change log. Pro is about helping you get to that next level of DevOps Nirvana, of reaching those four metrics that Dr. Forsgren tells us are really important.Corey: Oh, yes. You can argue with Nicole Forsgren, but then you're wrong. So, why would you ever do that?Robert: Yeah. Yeah. [laugh]. It's just—it's a sucker's bet. Don't do it. There's a reason why she's got a PhD in CS.Corey: She has been a recurring guest on this show, and I only wish she would come back more often. You and I are fun to talk to, don't get me wrong. We want unbridled intellect that is couched in just a scintillating wit, and someone is great to talk to. Sorry, we're both outclassed.Robert: Yeah, you get entertained with us; you learn with her.Corey: Exactly. And you're still entertained while doing it is the best part.Robert: [laugh]. That's the difference between Community and Pro. Look, at the end of the day, if you're an individual developer just trying to solve a problem and get done and away from the computer and go spend time with your friends and family, yeah, go use Liquibase Community. If it's something that you think can improve the rest of the organization by teaming up and taking advantage of the collaboration features? Yes, sure, let us know. We're happy to help.Corey: Now, if people wanted to become an attorney, but law school was too expensive, out of reach, too much time, et cetera, but they did have a Twitter account, very often, they'll find that they can scratch that itch by arguing online about open-source licenses. So, I want to be very clear—because those people are odious when they email me—that you are licensed under the Apache License. That is a bonafide OSI approved open-source license. It is not everyone except big cloud companies, or service providers, which basically are people dancing around—they mean Amazon. So, let's be clear. One, are you worried about Amazon launching a competitive service with a dumb name? And/or have you really been validated as a product if AWS hasn't attempted and failed to launch a competitor?Robert: [laugh]. Well, I mean, we do have a very large corporation that has embedded Liquibase into one of their flagship products, and that is Oracle. They have embedded Liquibase in SQLcl. We're tickled pink because that means that, one, yes, it does validate Liquibase is the right way to do it, but it also means more people are getting help. Now, for Oracle users, if you're just an Oracle shop, great, have fun. We think it's a great solution. But there's not a lot of those.And so we believe that if you have Liquibase, whether it's open-source or the Pro version, then you're going to be able to support all the databases, and I think that's more important than being tied to a single cloud. Also—this is just my opinion and take it for what it's worth—but if Amazon wanted to do this, well, they're not the only game in town. So, somebody else is going to want to do it, too. And, you know, I would argue even with Amazon's backing that Liquibase is a little stronger brand than anything they would come out with.Corey: This episode is sponsored by our friends at Oracle HeatWave is a new high-performance accelerator for the Oracle MySQL Database Service. Although I insist on calling it “my squirrel.” While MySQL has long been the worlds most popular open source database, shifting from transacting to analytics required way too much overhead and, ya know, work. With HeatWave you can run your OLTP and OLAP, don't ask me to ever say those acronyms again, workloads directly from your MySQL database and eliminate the time consuming data movement and integration work, while also performing 1100X faster than Amazon Aurora, and 2.5X faster than Amazon Redshift, at a third of the cost. My thanks again to Oracle Cloud for sponsoring this ridiculous nonsense. Corey: So, I want to call out though, that on some level, they have already competed with you because one of database that you do not support is DynamoDB. Let's ignore the Route 53 stuff because, okay. But the reason behind that, having worked with it myself, is that, “Oh, how do you do a schema change in DynamoDB?” The answer is that you don't because it doesn't do schemas for one—it is schemaless, which is kind of the point of it—as well as oh, you want to change the primary, or the partition, or the sort key index? Great. You need a new table because those things are immutable.So, they've solved this Gordian Knot just like Alexander the Great did by cutting through it. Like, “Oh, how do you wind up doing this?” “You don't do this. The end.” And that is certainly an approach, but there are scenarios where those were first, NoSQL is not a acceptable answer for some workloads.I know Rick [Horahan 00:26:16] is going to yell at me for that as soon as he hears me, but okay. But there are some for which a relational database is kind of a thing, and you need that. So, Dynamo isn't fit for everything. But there are other workloads where, okay, I'm going to just switch over. I'm going to basically dump all the data and add it to a new table. I can't necessarily afford to do that with anything less than maybe, you know, 20 milliseconds of downtime between table one and table two. And they're obnoxious and difficult ways to do it, but for everything else, you do kind of need to make ALTER TABLE changes from time to time as you go through the build and release process.Robert: Yeah. Well, we certainly have plans for DynamoDB support. We are working our way through all the NoSQLs. Started with Mongo, and—Corey: Well, back that out a second then for me because there's something I'm clearly not grasping because it's my understanding, DynamoDB is schemaless. You can put whatever you want into various arbitrary fields. How would Liquibase work with something like that?Robert: Well, that's something I struggled with. I had the same question. Like, “Dude, really, we're a schema change tool. Why would we work with a schemaless database?” And so what happened was a soon-to-be friend of ours in Europe had reached out to me and said, “I built an extension for MongoDB in Liquibase. Can we open-source this, and can y'all take care of the care and feeding of this?” And I said, “Absolutely. What does it do?” [laugh].And so I looked at it and it turns out that it focuses on collections and generating data for test. So, you're right about schemaless because these are just documents and we're not going to go through every single document and change the structure, we're just going to have the application create a new doc and the new format. Maybe there's a conversion log logic built into the app, who knows. But it's the database professionals that have to apply these collections—you know, indices; that's what they call them in Mongo-land: collections. And so being able to apply these across all environments—dev, test, production—and have consistency, that's important.Now, what was really interesting is that this came from MasterCard. So, this engineer had a consulting business and worked for MasterCard. And they had a problem, and they said, “Hey, can you fix this with Liquibase?” And he said, “Sure, no problem.” And he built it.So, that's why if you go to the MongoDB—the liquibase-mongodb repository in our Liquibase org, you'll see that MasterCard has the copyright on all that code. Still Apache 2.0. But for me, that was the validation we needed to start expanding to other things: Dynamo, Couch. And same—Corey: Oh, yeah. For a lot of contributors, there's a contributor license process you can go through, assign copyright. For everything else, there's MasterCard.Robert: Yeah. Well, we don't do that. Look, you know, we certainly have a code of conduct with our community, but we don't have a signing copyright and that kind of stuff. Because that's baked into Apache 2.0. So, why would I want to take somebody's ability to get credit and magical internet points and increase the rep by taking that away? That's just rude.Corey: The problem I keep smacking myself into is just looking at how the entire database space across the board goes, it feels like it's built on lock-in, it's built on it is super finicky to work with, and it generally feels like, okay, great. You take something like Postgres-squeal or whatever it is you want to run your database on, yeah, you could theoretically move it a bunch of other places, but moving databases is really hard. Back when I was at my last, “Real job,” quote-unquote, years ago, we were late to the game; we migrated the entire site from EC2 Classic into a VPC, and the biggest pain in the ass with all of that was the RDS instance. Because we had to quiesce the database so it would stop taking writes; we would then do snapshot it, shut it down, and then restore a new database from that RDS snapshot.How long does it take, at least in those days? That is left as an experiment for the reader. So, we booked a four hour maintenance window under the fear that would not be enough. It completed in 45 minutes. So okay, there's that. Sparked the thing up and everything else was tested and good to go. And yay. Okay.It took a tremendous amount of planning, a tremendous amount of work, and that wasn't moving it very far. It is the only time I've done a late-night deploy, where not a single thing went wrong. Until I was on the way home and the Uber driver sideswiped a city vehicle. So, there we go—Robert: [laugh].Corey: —that's the one. But everything else was flawless on this because we planned these things out. But imagine moving to a different provider. Oh, forget it. Or imagine moving to a different database engine? That's good. Tell another one.Robert: Well, those are the problems that we want our database professionals to solve. We do not want them to be like janitors at an elementary school, cleaning up developer throw-up with sawdust. The issue that you're describing, that's a one time event. This is something that doesn't happen very often. You need hands on the keyboard, you want people there to look for problems.If you can take these database releases away from those folks and automate them safely—you can have safety and speed—then that frees up their time to do these other herculean tasks, these other feats of strength that they're far better at. There is no silver bullet panacea for database issues. All we're trying to do is take about 70% of DBAs time and free it up to do the fun stuff that you described. There are people that really enjoy that, and we want to free up their time so they can do that. Moving to another platform, going from the data center to the cloud, these sorts of things, this is what we want a human on; we don't want them updating a column three times in a row because dev couldn't get it right. Let's just give them the keys and make sure they stay in their lane.Corey: There's something glorious about being able to do that. I wish that there were more commonly appreciated ways of addressing those pains, rather than, “Oh, we're going to sell you something big and enterprise-y and it's going to add a bunch of process and not work out super well for you.” You integrate with existing CI/CD systems reasonably well, as best I can tell because the nice thing about CI/CD—and by nice I mean awful—is that there is no consensus. Every pipeline you see, in a release engineering process inherently becomes this beautiful bespoke unicorn.Robert: Mm-hm. Yeah. And we have to. We have to integrate with whatever CI/CD they have in place. And we do not want customers to just run Liquibase by itself. We want them to integrate it with whatever is driving that application deployment.We're Switzerland when it comes to databases, and CI/CD. And I certainly have my favorite of those, and it's primarily based on who bought me drinks at the last conference, but we cannot go into somebody's house and start rearranging the furniture. That's just rude. If they're deploying the app a certain way, what we tell that customer is, “Hey, we're just going to have that CI/CD tool call Liquibase to update the database. This should be an atomic unit of deployment.” And it should be hidden from the person that pushes that shiny button or the automation that does it.Corey: I wish that one day that you could automate all of the button pushing, but the thing that always annoyed me in release engineering was the, “Oh, and here's where we stop to have a human press the button.” And I get it. That stuff's scary for some folks, but at the same time, this is the nature of reality. So, you're not going to be able to technology your way around people. At least not successfully and not for very long.Robert: It's about trust. You have to earn that database professional's trust because if something goes wrong, blaming Liquibase doesn't go very far. In that company, they're going to want a person [laugh] who has a badge to—with a throat to choke. And so I've seen this pattern over and over again.And this happened at our first customer. Major, major, big, big, big bank, and this was on the consumer side. They were doing their first production push, and they wanted us ready. Not on the call, but ready if there was an issue they needed to escalate and get us to help them out. And so my VP of Engineering and me, we took it. Great. Got VP of engineering and CTO. Right on.And so Kevin and I, we stayed home, stayed sober [laugh], you know—a lot of places to party in Austin; we fought that temptation—and so we stayed and I'm texting with Kevin, back and forth. “Did you get a call?” “No, I didn't get a call.” It was Friday night. Saturday rolls around. Sunday. “Did you get a—what's going on?” [laugh].Monday, we're like, “Hey. Everything, okay? Did you push to the next weekend?” They're like, “Oh, no. We did. It went great. We forgot to tell you.” [laugh]. But here's what happened. The DBAs push the Liquibase ‘make it go' button, and then they said, “Uh-Oh.” And we're like, “What do you mean, uh-oh?” They said, “Well, something went wrong.” “Well, what went wrong?” “Well, it was too fast.” [laugh]. Something—no way. And so they went through the whole thing—Corey: That was my downtime when I supposed to be compiling.Robert: Yeah. So, they went through the whole thing to verify every single change set. Okay, so that was weekend one. And then they go to weekend two, they do it the same thing. All right, all right. Building trust.By week four, they called a meeting with the release team. And they said, “Hey, process change. We're no longer going to be on these calls. You are going to push the Liquibase button. Now, if you want to integrate it with your CI/CD, go right ahead, but that's not my problem.” Dev—or, the release team is tier one; dev is tier two; we—DBAs—are tier three support, but we'll call you because we'll know something went wrong. And to this day, it's all automated.And so you have to earn trust to get people to give that up. Once they have trust and you really—it's based on empathy. You have to understand how terrible [laugh] they are sometimes treated, and to actively take care of them, realize the problems they're struggling with, and when you earn that trust, then and only then will they allow automation. But it's hard, but it's something you got to do.Corey: You mentioned something a minute ago that I want to focus on a little bit more closely, specifically that you're in Austin. Seems like that's a popular choice lately. You've got companies that are relocating their headquarters there, presumably for tax purposes. Oracle's there, Tesla's there. Great. I mean, from my perspective, terrific because it gets a number of notably annoying CEOs out of my backyard. But what's going on? Why is Austin on this meteoric rise and how'd it get there?Robert: Well, a lot of folks—overnight success, 40 years in the making, I guess. But what a lot of people don't realize is that, one, we had a pretty vibrant tech hub prior to all this. It all started with MCC, Microcomputer Consortium, which in the '80s, we were afraid of the Japanese taking over and so we decided to get a bunch of companies together, and Admiral Bobby Inman who was director planted it in Austin. And that's where it started. You certainly have other folks that have a huge impact, obviously, Michael Dell, Austin Ventures, a whole host of folks that have really leaned in on tech in Austin, but it actually started before that.So, there was a time where Willie Nelson was in Nashville and was just fed up with RCA Records. They would not release his albums because he wanted to change his sound. And so he had some nice friends at Atlantic Records that said, “Willie, we got this. Go to New York, use our studio, cut an album, we'll fix it up.” And so he cut an album called Shotgun Willie, famous for having “Whiskey River” which is what he uses to open and close every show.But that album sucked as far as sales. It's a good album, I like it. But it didn't sell except for one place in America: in Austin, Texas. It sold more copies in Austin than anywhere else. And so Willie was like, “I need to go check this out.”And so he shows up in Austin and sees a bunch of rednecks and hippies hanging out together, really geeking out on music. It was a great vibe. And then he calls, you know, Kris, and Waylon, and Merle, and say, “Come on down.” And so what happened here was a bunch of people really wanted to geek out on this new type of country music, outlaw country. And it started a pattern where people just geek out on stuff they really like.So, same thing with Austin film. You got Robert Rodriguez, you got Richard Linklater, and Slackers, his first movie, that's why I moved to Austin. And I got a job at Les Amis—a coffee shop that's closed—because it had three scenes in that. There was a whole scene of people that just really wanted to make different types of films. And we see that with software, we see that with film, we see it with fashion.And it just seems that Austin is the place where if you're really into something, you're going to find somebody here that really wants to get into it with you, whether it's board gaming, D&D, noise punk, whatever. And that's really comforting. I think it's the community that's just welcoming. And I just hope that we can continue that creativity, that sense of community, and that we don't have large corporations that are coming in and just taking from the system. I hope they inject more.I think Oracle's done a really good job; their new headquarters is gorgeous, they've done some really good things with the city, doing a land swap, I think it was forty acres for nine acres. They coughed up forty for nine. And it was nine acres the city wasn't even using. Great. So, I think they're being good citizens. I think Tesla's been pretty cool with building that factory where it is. I hope more come. I hope they catch what is ever in the water and the breakfast tacos in Austin.Corey: [laugh]. I certainly look forward to this pandemic ending; I can come over and find out for myself. I'm looking forward to it. I always enjoyed my time there, I just wish I got to spend more of it.Robert: How many folks from Duckbill Group are in Austin now?Corey: One at the moment. Tim Banks. And the challenge, of course, is that if you look across the board, there really aren't that many places that have more than one employee. For example, our operations person, Megan, is here in San Francisco and so is Jesse DeRose, our manager of cloud economics. But my business partner is in Portland; we have people scattered all over the country.It's kind of fun having a fully-distributed company. We started this way, back when that was easy. And because all right, travel is easy; we'll just go and visit whenever we need to. But there's no central office, which I think is sort of the dangerous part of full remote because then you have this idea of second-class citizens hanging out in one part of the country and then they go out to lunch together and that's where the real decisions get made. And then you get caught up to speed. It definitely fosters a writing culture.Robert: Yeah. When we went to remote work, our lease was up. We just didn't renew. And now we have expanded hiring outside of Austin, we have folks in the Ukraine, Poland, Brazil, more and more coming. We even have folks that are moving out of Austin to places like Minnesota and Virginia, moving back home where their family is located.And that is wonderful. But we are getting together as a company in January. We're also going to, instead of having an office, we're calling it a ‘Liquibase Lounge.' So, there's a number of retail places that didn't survive, and so we're going to take one of those spots and just make a little hangout place so that people can come in. And we also want to open it up for the community as well.But it's very important—and we learned this from our friends at GitLab and their culture. We really studied how they do it, how they've been successful, and it is an awareness of those lunch meetings where the decisions are made. And it is saying, “Nope, this is great we've had this conversation. We need to have this conversation again. Let's bring other people in.” And that's how we're doing at Liquibase, and so far it seems to work.Corey: I'm looking forward to seeing what happens, once this whole pandemic ends, and how things continue to thrive. We're long past due for a startup center that isn't San Francisco. The whole thing is based on the idea of disruption. “Oh, we're disruptive.” “Yes, we're so disruptive, we've taken a job that can be done from literally anywhere with internet access and created a land crunch in eight square miles, located in an earthquake zone.” Genius, simply genius.Robert: It's a shame that we had to have such a tragedy to happen to fix that.Corey: Isn't that the truth?Robert: It really is. But the toothpaste is out of the tube. You ain't putting that back in. But my bet on the next Tech Hub: Kansas City. That town is cool, it has one hundred percent Google Fiber all throughout, great university. Kauffman Fellows, I believe, is based there, so VC folks are trained there. I believe so; I hope I'm not wrong with that. I know Kauffman Foundation is there. But look, there's something happening in that town. And so if you're a buy low, sell high kind of person, come check us out in Austin. I'm not trying to dissuade anybody from moving to Austin; I'm not one of those people. But if the housing prices [laugh] you don't like them, check out Kansas City, and get that two-gig fiber for peanuts. Well, $75 worth of peanuts.Corey: Robert, I want to thank you for taking the time to speak with me so extensively about Liquibase, about how awesome RedMonk is, about Austin and so many other topics. If people want to learn more, where can they find you?Robert: Well, I think the best place to find us right now is in AWS Marketplace. So—Corey: Now, hand on a second. When you say the best place for anything being the AWS Marketplace, I'm naturally a little suspicious. Tell me more.Robert: [laugh]. Well, best is, you know, it's—[laugh].Corey: It is a place that is there and people can find you through it. All right, then.Robert: I have a list. I have a list. But the first one I'm going to mention is AWS Marketplace. And so that's a really easy way, especially if you're taking advantage of the EDP, Enterprise Discount Program. That's helpful. Burn down those dollars, get a discount, et cetera, et cetera. Now, of course, you can go to liquibase.com, download a trial. Or you can find us on Github, github.com/liquibase. Of course, talking smack to us on Twitter is always appreciated.Corey: And we will, of course, include links to that in the [show notes 00:46:37]. Robert Reeves, CTO and co-founder of Liquibase. I'm Cloud Economist Corey Quinn, and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice along with an angry comment complaining about how Liquibase doesn't support your database engine of choice, which will quickly be rendered obsolete by the open-source community.Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.Announcer: This has been a HumblePod production. Stay humble.

CGI vous propose de découvrir U'DEV, son école du développeur, au travers des témoignages de ses membres. Aujourd'hui nous rencontrons Liv Audigane, Développeuse Java J2EE qui suit actuellement cette formation en alternance chez CGI. 

CGI vous propose de découvrir U'DEV, son école du développeur, au travers des témoignages de ses membres. Aujourd'hui nous rencontrons Alexandre Piquion, Développeur Java J2EE qui suit actuellement cette formation en alternance chez CGI. 

CGI vous propose de découvrir U'DEV, son école du développeur, au travers des témoignages de ses membres. Aujourd'hui nous rencontrons Valentin Tournant, Développeur Java J2EE qui suit actuellement cette formation en alternance chez CGI. 

An airhacks.fm conversation with Oleg Selajev (@shelajev) about: the 100 MHz Pentium 1, the turbo button slow down, WinRAR with floppy disks, the technologies progresses but the fiddling remains the same, playing chess with the grandfather, the chess tournaments, code smells and chess strategy, starting with HTML and PHP, starting programming with Java 5 with annotations and generics, wisdom and smartness, drawing a snowman with Java AWT, full time job competes with opensource work, early J2EE and XML deployment descriptors, jrebel and ZeroturnAround, using JMS at hospitals, dealing with HL7, starting at playtech to implement casino games in Java, back to zeroturnaround, liverebel, watchdog and monitoring, monoliths are back, everyone talks about microservices, Stack Overflow Developer Survey 2021, The State of Developer Ecosystem 2021 by Jetbrains, Snyk JVM Ecosystem Report 2021, Virtual JUG, Rogue Wave Java Collection, joining Oracle, being DevRel at GraalVM team Oleg Selajev on twitter: @shelajev, Oleg's youtube channel

An airhacks.fm conversation with Mohamed Taman (@_tamanm) about: AMD PC in 1997 with 200 MHz hot AMD, exploring the DOS and QuickBasic, drawing sceneries, photography as hobby, assembling PCs from parts, AS-400 and RPG, QBasic and C++ on Windows 3.11 and Windows 95, to shutdown windows you had to push the start, Windows Millenium Edition, equations in QBasic, starting with Java 1.1, the Sun Certified Java Programmer certification was hard to pass, impressed with Java, Java hides the low-level boilerplate for convenience, catching up with J2EE 1.4 and Java EE, building mazes with OpenGL and Java, working for Silicon Experts, staring with Sun Enterprise Server, later BEA WebLogic, recreating Struts from scratch, the problem with early EJB, working on JD Edwards, Oracle and Siebel integration, using ADF at Oracle, Sun Microsystems was acquired by Oracle, starting at eFinance, efinance is private, but founded by the government, started a United Nations (UN) project for donations management, Java EE 7 with Glassfish was used as the stack, finding bugs in GlassFish, working with the latest versions in mission critical projects, presenting at JavaOne keynote, JBoss to quarkus migration on openshift, "Java EE: Future Is Now, But Is Not Evenly Distributed Yet" at JDD, scaling with hardware, Mohamed Taman on twitter: @_tamanm

01:22 - Jess’s Superpower: Playing ANY Instrument * Music & Technology * Cultural Expoloration 06:03 - Language Community Ethos (MINASWAN (https://en.wiktionary.org/wiki/MINASWAN)) * Human-Centered Design * The Joy of Programming Meetup (https://www.meetup.com/Joy-of-Programming-DC/) * Sapir-Whorf Hypothesis (https://www.sciencedirect.com/topics/psychology/sapir-whorf-hypothesis) 13:24 - Inclusive Language: Language Matters * Valheim (https://store.steampowered.com/app/892970/Valheim/) 17:19 - Active Listening and Expressing Point-of-View, and Using Loudness * Vocally For * Vocally Against * Quiet For * Quiet Against 21:51 - Shining Light on Marginalized People & Voices * BULQ (https://www.bulq.com/about-us/) * Metacognition: Asking ourselves, “What are we not thinking about?” * Leadership * Changing Mental Patterns; Take a Different Path 31:30 - Benefits of Having Diverse Teams (Resources) & Risks of Homogeneity * Diversity wins: How inclusion matters (https://www.mckinsey.com/featured-insights/diversity-and-inclusion/diversity-wins-how-inclusion-matters) * Why diversity matters (https://www.mckinsey.com/business-functions/organization/our-insights/why-diversity-matters) * The Chevy Nova That Wouldn't Go (https://www.thoughtco.com/chevy-nova-that-wouldnt-go-3078090) * Google Photos labeled black people 'gorillas' (https://www.usatoday.com/story/tech/2015/07/01/google-apologizes-after-photos-identify-black-people-as-gorillas/29567465/) * From transparent staircases to faraway restrooms, why these benign design details can be a nuisance for some women (https://archinect.com/news/article/150073631/from-transparent-staircases-to-faraway-restrooms-why-these-benign-design-details-can-be-a-nuisance-for-some-women) 37:29 - Storytelling * Representation Matters * Normalization Reflections: Jess: We are feeling beings that rationalize. Damien: How technology impacts culture. Casey: Taking loudness for diversity, equity, and inclusion with people who don’t always talk about it. Who is more open to it or not? This episode was brought to you by @therubyrep (https://twitter.com/therubyrep) of DevReps, LLC (http://www.devreps.com/). To pledge your support and to join our awesome Slack community, visit patreon.com/greaterthancode (https://www.patreon.com/greaterthancode) To make a one-time donation so that we can continue to bring you more content and transcripts like this, please do so at paypal.me/devreps (https://www.paypal.me/devreps). You will also get an invitation to our Slack community this way as well. **Transcript:: DAMIEN: Welcome to Episode 233 of Greater Than Code. I’m Damien Burke and I’m joined here with Casey Watts. CASEY: Hi, I’m Casey! And I’m here with our guest today, Jess Szmajda. Jess is currently a senior leader at AWS in the EC2 Networking organization. Previously, she was the first female CTO of a major media organization, Axios, and before that, the co-founder and CTO at Optoro, which helps top tier retailers nationwide handle their returned and excess goods. Jess got her start in tech in the 90s writing Perl to configure Solaris machines. Over the years, she’s contributed to Open Source and organized a number of communities. These days, focusing on the DC Tech Slack and the DC-based Joy of Programming Meetup. Outside of the tech world, Jess is a singer-songwriter, an improviser, a gamer, a proud member of the LGBTQ+ community, and a Mom to the most wonderful, Minecraft-obsessed 6-year-old imaginable. Welcome Jess. DAMIEN: Welcome to Greater Than Code, Jess. JESS: Thank you! It's nice to be here. DAMIEN: So I know someone has prepped you with our first question. What is your superpower and how did you acquire it? JESS: My superpower is that I can play any instrument you hand me and I – DAMIEN: Oh. JESS: [laughs] I acquired it by being a giant nerd. [laughs] I went to a special music high school here in the DC area called Suitland High School and I played all kinds of different instruments. I was the principal bassoonist of the DC Youth Orchestra for a while. Music's always been a lifelong love of mine and it's been a mission to find every strange instrument I can find to figure out how it works. So it's challenge [chuckles] to find something that I can't play. [laughs] DAMIEN: Oh, I'm so tempted and of course, the first thing I would have gone with is the double reed bassoon and oboe, but that's too easy. JESS: That’s right. DAMIEN: Banjo, of course, you’ve got steel drum. JESS: Steel drum and plate, yeah. DAMIEN: Cajon. JESS: Cajon. Oh, I have heard of it. DAMIEN: Aha! JESS: I haven't actually touched one. I'll figure it out. [laughs] DAMIEN: It's particularly easy. JESS: Nice. [laughs] CASEY: I don't know very many people who play more than just an instrument, or two. I think it might be like you and I are the two that come to mind for me, honestly. [laughter] I have an instrument in every color, by the way. That's the way I collect them. [laughter] JESS: Nice. CASEY: I’ve got a white accordion. How do you feel like this breadth of instrument ability has affected your life in other ways? JESS: I don't know. That's an interesting question. How has it affected my life in other ways? I mean, there's the obvious tie into music and technology. There's such an incredible confluence of musicians who are engineers and vice versa. I was actually talking to someone at the office earlier about that and she was theorizing it's because all of the patterns and rhythms that we think about and how that ties into a regular patterns and systems that we think about as engineers and I think it's a really interesting way to think about it, for sure. I do think that there's a certain element of cross-culturalism that you get from learning other cultures instruments. Certainly, the berimbau, the Brazilian martial art? [laughs] DAMIEN: Capoeira? JESS: Capoeira, yeah. The capoeira, the berimbau instrument that has the long string and you have the little – I think you learn a lot about what led to developing an instrument so relatively simple, but creating such an incredible art form in the culture where people just wanted to dance and share their heritage with each other and picked up whatever they could find that would make interesting and fun sounds and created an entire culture around that. So for me, it's as much cultural exploration and understanding as it is anything. I think it's wonderful. DAMIEN: Yeah. That's really amazing. I had a tiny insight on this recently. I saw an amazing video about a Jimmy Hendrix song with the basic premise being, what key is this song in? It's a really difficult question because—and I'm going to go a little bit music nerd here—the tonic is e, but the chord progressions and the melodic signature doesn't really fit that. Amazing 20-minute video, but the end conclusion is that using Western art music tonality to describe blues music, American blues music, it's a different tonality. So it doesn't really make sense to say what major key is this in, or what minor key is this in. JESS: Yeah, totally. My partner and I, this morning, we were watching a video about Coltrane's classic—my favorite thing is interpretation in the 60s—and how he's basically playing between these major and minor tonalities constantly. It's not necessarily tonal from the Western sense, but it’s certainly beautiful and I think it's certainly approachable and understandable to any ear regardless of how you decompose it. Anyway, giant music nerd, sorry. [laughs] DAMIEN: Yeah, but it ties so closely to what you were talking about as an instrument being cultural. The guitar, the five-string guitar, is tuned for American music, which is a slightly different tonality from Western European music. So when you think about “Okay, well, that's very slightly different. Now, what is it like in Africa, in Australia, in Asia?” Then it gets all, it's got to be very, very different. JESS: Oh, yeah. I saw this guy in Turkey, he's modified a guitar to add quarter tones to it because a lot of Turkish music uses quarter tones and so, it's just like the fretboard is wild. It has all of these extra frets on it and he plays it. It's absolutely incredible, but it's wild. It's amazing. DAMIEN: So I want to tie this into different cultures, frameworks, and technology. How about that? JESS: Yeah, you bet, let's do it. [laughs] CASEY: Good segue. JESS: So actually, that's something that's been on my mind is this Ruby community diaspora in a way. I know Greater Than Code has a lot of Ruby folks on it and I'm not sure about the latest incarnation, but definitely a lot of Ruby roots. I think that we've seen this incredible mixing of culture in the Ruby community that I haven't seen in other places that drives this – well, I think [inaudible], it's a really fantastic way to sum it up like, math is nice and so we are nice. As much as that might be a justification to be nice, be nice anyway, but it's still this ethos of we are nice to each other, we care, and that is baked into the community and my journeys and other language communities, I think haven't shared that perspective that it is good to be nice in general and some of them even are, I think are focused on it's good to fight. [laughs] So I've been really curious about this movement, Rubius’s movement into other language areas, like Go, Rust, and Alexa, et cetera, et cetera, how much of that carries forward and what really can we do to drive that? DAMIEN: Yeah. So my question is how does a technological community, what is it about the community? What is about the technology? Why is it different? You and I both wrote Pearl in the 90s and so, that is a very different community. I look at Ruby and I write mostly Ruby now and I go, “Why is it different? What's different about it?” JESS: Yeah, no, it's a good question. A lot of the early conversation that I remember in the Ruby community was—and just contextually, I've been using Ruby since 2006, or so, so that era. A lot of the early conversation I remember was about develop the language to optimize for developer happiness. I think that's a really unique take and I haven't heard of that in any other place. So I'm wondering how much that might've been the beginnings of this. I don't know. DAMIEN: Something came up in a Twitter conversation, I saw a while back where they compared Ruby and Pearl, I'm pretty sure it was Pearl and well, one of the defining features of Pearl was that there's more than one way to do it and Ruby has that same ethos. Literally, in the standard lib, there’s a lot of aliases and synonyms. It's like, you can call pop, or drop and I can't keep it straight. [chuckles] But anyway, then I thought to myself, “Well, in Pearl, that's an absolute disaster.” I pull up a profile and I'm like, “I don't know what this is because I don't know what's going on.” Whereas, in Ruby, I've loved it so much and so, what's the difference and the difference pointed out to me was that in Ruby, it was for expressiveness. Things have different names so that they can properly express, or better express the intention and in Pearl, that wasn't the case. JESS: Yeah, no, totally. I think actually looking at Ruby and Python, I think were both heavily influenced by Pearl and I think Python definitely took the path of well, all of this nonsense is just nonsense. Let's just have one way to do it. [laughs] Having worked with some Python developers, I think that perspective on there is one correct path really drives that community in a lot of ways. I think some people find that releasing really simplifying for them because they're like, “I got it. I know the answer.” Like it's a math problem almost. As a Rubyist going into the Python community, I was like, “Oh, I'm so stifled.” [laughs] Where is my expressiveness?! I want to write inject, or oh, I can't even think of the opposite of inject. Collect. [laughs] Those are two different words for me. I want to be able to write both, depending on what I'm doing so. It's also interesting, like I see a lot more DSL development in Ruby than I see in any other language and maybe Alexa also. But I think that also comes from the same perspective of there is not one right way to do it. There's the best way for this problem and there's the best way for this kind of communication you're trying to drive. It's interesting, as I'm talking myself into a corner here a bit, Ruby almost emphasizes the communication of code more than the solving of the problem and I think that might actually help drive this community where we care about the other humans we're working with, because we're always thinking about how we communicate with them in a way. CASEY: I think about the term human-centered design a lot lately and that's becoming more and more popular term, a way to describe this thing. Ruby totally did that. Ruby looked at how can we make this easy for humans to use and work with and I think that's beautiful. I keep thinking about a paper I read a long time ago that a professor made-up programming language and varied features of it like, white space matters, or not, and a whole bunch of those and measured which ones were easier for new people to learn and which ones were harder for new people to learn. As a teacher, I want to use whatever is easy for the students to learn so they can get their feet wet, so they can start learning and building and doing things and get excited about it, not get hung up on the syntax. So human-centered design baked into Ruby is, I think partly why the community is so human-centered. I think you're exactly right. JESS: Yeah. That's really interesting. That's a large part of why the Joy of Programming Meetup, I think has been really fun is we get to learn from how different language communities build things. I think it was founded on that kind of thinking is the Sapir–Whorf hypothesis for better, or worse theorizes language shapes thought and I think that that is to some degree, at least true in how we think about writing code and solving problems. So the kinds of solutions that you see from different language communities, I think very incredibly. I don't know, even just as simple as from like J2EE, which is the ivory tower of purity in XML [laughs] to obviously, I don't want to pick on Rails, but Rails is an open system. [laughs] An interpretive dance, perhaps. I think it's really interesting, the web frameworks even I see in Haskell almost feel like I'm solving a math problem more than I'm creating an API, or delivering content into somebody. So it's hard for me to separate, is this a community of thought of people who are attracted to a certain way of solving problems? Is this driven by the structure and format of the language? I don't know. DAMIEN: I know you mentioned the Sapir–Whorf hypothesis and their research has been shown to be problematic. JESS: Yeah, for sure. DAMIEN: [laughs] But I will say that the hypothesis is that language shapes thought and I would say that the correct state – correct [chuckles] a better description for me is that language is thoughts and so, the language you use is the sort of things you're thinking about. So if you say inject when you mean collect, those are different things, you're going to get different things out of them. This is why we use get annotate instead of get playing. JESS: For sure. Exactly. So at AWS, this is big drive and I'm not speaking for AWS on this, I'm just speaking for me. But I'm noticing this drive for inclusive language and I think it's really beautiful. Connecting that drive, frankly, in the broader tech community to everything that's been going on in this last year in how we interact with each other as humans from different backgrounds, et cetera. It's like, what kinds of dominant culture paradigms have we baked into our code beyond even the very obviously problematic statements, but just the way that we think about, I don't know. Part of me is like, “Well, is object-oriented design driven by certain cultural expectations that we have, or functional?” I don't know. What paradigms would we get if we'd have had a different dominant culture developing technology? I don't know. It's fascinating. DAMIEN: Yeah, and [inaudible] is an excellent example of that. It's a punishment. This is wrong. I did a whole talk several years ago about specifications versus tests. I don't want you to write tests for your code; tests are something you do afterwards to see if something is suitable. Write a specification and then if the code and specifications don't match, well, one of them needs to change. [laughs] JESS: That's right. I love that. That's also kind of like the Pact Contract Testing space. It's like, I like this framework because it allows a consumer of an API to say, “This is what I expect you to do,” and then the API almost has to comply. Whenever I've talked about Pact, I think with a lot of developers, they're like, “Wait, what? That doesn't make any sense at all.” I'm like, “Well, no.” In a way, it's like the API’s prerogative to deliver what the customer expects and to be always right. The customer is right here, in this case and I think it's a really great way to look at this differently. CASEY: That should totally be the tagline for Pact: the consumer is always right. JESS: I love it. [laughs] CASEY: Another way language shapes things, I noticed lately is Valheim is a super popular game where you're a Viking and building houses. There's a command you can type called “imacheater” that lets you spawn in equipment and building materials. On all the forums online, people are harassing each other for doing their own creative mode for spawning stuff in because of that language, I suspect. So in a recent patch, they changed it from imacheater to devtools, or something like that and the forums have rebranded. There's a new moderator is posting things and the culture is completely changing because the devs changed that one word in the changelog and it's just so cool to see language matters. JESS: That's amazing. That's so cool. Actually, I'm totally hooked on Valheim also along with probably everybody else. I have my own little server with some friends. Anyway, we noticed on the Valheim server that there was somebody who sort of redid the loading screen and they really hypersexualized the female character in the painting and actually got a surprising amount of feedback like saying, “Please don't do that. We love Valheim because it's not clearly gendered, or particularly one way, or the other,” and the artist actually took that feedback to heart and put together a much better version of the thing where the woman was very well armored and looked ready for battle and it was really cool. I've been thinking about the whole tech community and there's so many connections to the gamer community as well. Ever since Gamergate, I think we've been putting a really hard light on this whole world. It's just so heartwarming and incredible to know that like this Viking destroying trolls game has people who actually care enough to say, “No, let's pay attention to what that woman's wearing. Make sure she wears something that's actually reasonable.” That's cool. We've come a long way. I mean, not perfect, but it's a long way. CASEY: Yeah, a long way. I always think about progress in terms of people in four groups. There's like people who are vocally for something like they would speak up in this case, people who are vocally against it, and then quiet people who are for, or against it. We can see the vocal people who are supporting this now and I love to think about how many people are moving in that direction who are quiet; we can't see. That's the big cultural shift under the covers. JESS: Yeah. That's a big question. That makes me think about when I was at Optoro, we were trying to understand our employee engagement and so, we used this tool, Culture Amp, which I imagine a lot of people have seen. We did a survey and we got all this data and it's like, “Hey, everybody's really engaged. Maybe there's a couple of minor things we can fix.” But then we were talking to some of our Black employees—those of you who can't see me, I'm white—and there was just a lot of like, “Wow, this doesn't represent us.” Like, “What are you doing? We actually aren't don't feel like this is a really great representation.” We're like, “Well, the data says everything's fine.” So what we actually did, the next survey we ran, we included demographic data in the dataset and then we were able to distribute the data across racial demographics and we saw, oh no, our Black employees are pretty much all pissed off. [laughs] We've done a really bad job of including them for a lot of reasons. For example, we had a warehouse and most of our Black employees worked in the warehouse and it turns out that we had a very corporate-based culture and we didn't pay enough attention and we didn't really engage everybody. The fact that they were basically all in the warehouse is kind of also a problem, too. So there was a lot of really great eye-opening things that we got to see by paying attention to that and looking not just at our Black employees, but all our different demographics. We learned a lot and I think we had a real humbling moment and got to listen, but it's really this quiet – either people who don't use their voice, or can't use their voice, or maybe don't know how to use their voice in a lot of different ways. These people, I think make such an incredible impact on the true feeling of a place, of a community, of a company and really sitting down and listening to those people, I think can be really hard in any position. So I was really happy we were able to do that, but I think you're totally right, Casey, that it's not just moving the vocal people to really change the Overton window, I suppose on what's acceptable in a community. But it's fundamentally, how do you change the people who you aren't hearing from? How do you frankly even know? CASEY: Yeah, it's a big question. There's no easy answer. There's a lot of approaches. I'm glad people are talking about that in the meta sense, that's huge. We want to do this as a community, but there's work to be done and then even once people are comfortable expressing their point of view, there are then further tiers we're going to have to go through like that other people around them understand. They're actively listening and they internalize it. And then beyond that, actually acting on it. I've had experiences at work where I'm usually very confident, I'll say my point of view regardless of the context. I like being outspoken like that and represent quieter people, but often leadership and other people around me don't understand, or even if they do, they don't incorporate that into the plan and then everybody is still very frustrated, maybe even more so in a way, because a light is shining on this problem. And that's the same for marginalized voices. If they can just be heard, that's great, but we have to go farther than that, too. JESS: I couldn't agree more. This is the thing that I struggle with sometimes. I love people. I'm very extroverted. I'm very gregarious, [laughs] as I imagine you can tell, and I like to engage with people and I try to listen, but I find that sometimes I have a big personality and that can be tough, [laughs] I think sometimes. So I super value people you Casey, for example, who I think are much better listeners [laughs] and are willing to represent that. So that's huge. I also, though on the flip side, I know that I can use that loudness to help represent at least one aspect of marginalized people. I'm trans and I'm super loud about that and I'm very happy to make all kinds of noise and say, “Don't forget about trans rights!” [laughs] Frankly, I think it's kind of a wedge into I'm one kind of marginalized community, I represent one kind of marginalized community, but there's a lot more and let's talk about that, too. Not to toot my horn, but like I think those of us who are allowed to have a responsibility to use our loudness in a way that I think supports people and also, to listen when we can. DAMIEN: Can we explore a bit into the into the metal problem of hearing from marginalized voices? I'm an engineer at heart, first and foremost, and so, how do we solve this meta problem? You gave a good example with the survey separated by demographics knowing that racial and gender demographics, or well, finding out that [chuckles] racial and gender demographics were important factors than you think, but how do we solve this on a broader issue? I don't know. JESS: No, that's a great question. I think we have so much calcified thinking that at every organization and every place in the world, there's so much like, “Well, this is the way we've done things,” and frankly, it's not even, “This is the way we've done things.” It's just, “This is the way it works and this is what we do,” and just thinking outside the box, I think it's hard. Finding these areas that we are being blind to in the first place, I think it takes a certain amount of just metacognition and patience and self-reflection, and that's very difficult to do, I think for any human. But driving that shows like this, for example, making sure that people care and think about these kinds of problems and maybe take a second. You as a listener, I'm going to challenge you for a second, take a minute at the end of this podcast and think about what am I not thinking about? I don't know, it's a really freaking hard question, but maybe you might find something. But it's politicians, it's media, it's our leaders in every aspect making sure that we shine a light on something that is different, something that is marginalized, I think is incredibly valuable. That's a first step. But then playing that through everything else we do, that's hard. I think it falls on leaders in every realm that we have like, community leaders, conference organizers, people who lead major open source projects. Making sure that people say, “I believe that Black Lives Matter.” “I believe that we should stand against violence against the Asian community.” Those, I think are powerful statements and saying, “Hey, have we heard from somebody that doesn't look like us lately, who doesn't come from our same socioeconomic educational background?” It's tough. I had food, but I grew up relatively poor, and I think even that is such a huge difference of experience and background to a lot of people that I end up working with and I've been able to talk about like, “How are we setting prices?” Well, who are we actually thinking about? We're not thinking about ourselves here. We're thinking about a different market. Let's make sure we talk to those people. Let's make sure we talk to our customers and make sure that this actually works for them. I was really proud. At Optoro, we built a new brand called BULQ where we took – so 2 seconds on Optoro. We took returns and excess goods from major retailers and helped them get more value out of it and a a lot of the time, we built great classification systems to say, “Oh, well this is a belt and I know how to price belts because I can look on eBay and Amazon and determine, et cetera.” But a lot of the times we couldn't build these kinds of models, like auto parts, for example, were notoriously difficult for us. So we could say, “Oh, this is an auto part. But I don’t know, carburetor, manifold? Who knows?” [laughs] So we were able to classify them as auto parts and then we put them into these cases, maybe like 3-foot square large boxes, and then we were able to sell those in lots to basically individual people who had time to learn what they were and then could resell them. The story that I love to tell here is they're a laid-off auto factory worker, knows a ton about auto parts, and can probably scrounge up enough money to afford this $200 to $300 box, brings it to their house, knows exactly what these parts are and knows exactly what the value is and then can resell them for like 3x to 5x on what this person bought them for. I was so proud to be able to have created this kind of entrepreneurial opportunity for people that we would otherwise often forget about because so much of tech, I think is focused on us. So, it's an interesting thing kind of being at AWS, which is very much a tech for tech company. I love it, don't get me wrong, but sometimes I think these opportunities to listen to the rest of the world, we miss out on. DAMIEN: Yeah. You challenged us to ask ourselves the question, what are we not thinking about and that level of metacognition sounds impossible. It might be impossible. It's close to impossible, if it's not. So I can't help to think the only way to really get that knowledge, that insight is to get people who are different from me, who have different backgrounds, who have different life experiences. You got a great example of someone who knows a lot about car parts, bring them in, they have years of experience in car parts and they can do this stuff that you can't do. But then also, along every axis, if you look around. If you look around the leadership and go, “Oh, there's nobody in leadership here who has this type of experience,” that knowledge, that insight and people like that are not going to be served because it's impossible for them. They don't even know. They can't know. JESS: Could not agree more and it is leadership. Absolutely. You're absolutely right. So many times I've seen, having been a leader, ultimately, you end up in a room with other leaders and you end up making decisions. And if you don't have other voices in there, if you don't have diverse voices, you don't get that benefit. Even if you've gone to the trouble of paying attention to diverse voices beforehand, there's always some data, some argument that comes up and it's like, “Oh, well, maybe, maybe not.” Yeah, I cannot agree enough. This is the other flip side of that is that as a business leader, I have to think about prioritizing the outcomes of the business, it is a fact of my position and I like to think that I work in a lot more data to what that means than other business leaders perhaps. Like, impact on the community. [laughs] Impact on the people. But a lot of times, we'll be having these discussions about who to hire and maybe we'll have done a really great job—and this isn't specific to any particular company that I'm talking about, but I know that this kind of thing happens. Maybe we've done a really great job of getting a diverse pipeline and having talked to a bunch of different kinds of candidates, but when it comes down to it, we're trying to make often the lowest risk decision on who to hire and so often, we are too risk averse to somebody whose background doesn't quite line up to what we're expecting, or to what we think we need. I like to think that I push hiring communities in conversations like that and say like, “Look, let's think beyond what's risky here and factor in more of these aspects to the conversation of getting diverse voices.” But too often, it's very easy, I think for leaders to think, “Well, we’re just going to hire the known quantity,” and I think that is again, on the meta, a major thing that we need to fix. There's so much more to being an effective leader than having the standard pedigree. DAMIEN: Well, there's also, like you mentioned, the risk aversion to not want to hire somebody who's not like all the other people, but then what are the huge risks of having only people who are alike in certain aspects? JESS: Exactly. Couldn't agree more. I think there's tons of examples. If we Google right now, we'd find like companies have made really dumb mistakes because they didn't have somebody in the room who could be like, “That?” The first one that comes to mind is the Chevy Nova, they tried to sell that in Spanish speaking countries, [laughter] “doesn't go,” “not going anywhere.” [laughs] I mean, like that could have been avoided, right? [laughs] CASEY: Nova. JESS: Nova. That might be a trivializing one, but there's been a lot worse and that's a major business risk and I think those arguments carry some weight. I love that so many organizations are prioritizing hiring more diverse leaders, especially, but this is deep pattern that we've gotten into. So that actually comes to mind when you're thinking about how to change your mental patterns. I'm an improviser, I'm all about trying to change my mental patterns all the time so I can try to be creative. Obviously, there's plenty of silly improv games that you get into, but something that's simple, I think that anybody can do is go for a walk and take a different path. Just turn a different way than how you used to. We, humans love to get into patterns, especially engineers, which I find to be highly ironic. Engineers are all about creating change, but don't like change themselves typically. [laughs] But do something a little different, turn left instead of right today, look up instead of down. Those, I think subtle physical changes really do influence our mental states and I think that can actually lead us to thinking in new ways. CASEY: I love it. That's very actionable. I've been doing a lot of walks and hikes and I actually try to go to a different hiking location each time because of that. I think about that idea all the time, take a different path, and it is great. Every time I do it, I feel amazing. I don’t know, more flexible, I think differently. Yeah, try it, listeners. I dare you. JESS: I love it. CASEY: I'm sure there are papers written showing that having diverse teams have very measured effects, a whole bunch of them, more than I know more, than I've read. Well, I guess first of all, I don't know that the data has been collected in a single spot I can point people to and that would be pretty powerful. But then secondly, even if we had that, I'm not sure that's enough to change minds at companies in any widespread way. It might just help some people, who already care, say their message very clearly. Do you know of anything like that Jess, or Damien, either of you? What's the one resource you would send to someone who wants to be equipped with diversity and inclusion data? JESS: Yeah. This study McKinsey did a while ago that, I think gets a lot of traction here where they demonstrated the companies have better total performance with more diverse groups of people and went into some depth with data. I think it's a fantastic study. It's definitely one that I reference often. I've used it to change minds among people who were like, “Wow, what's it really matter?” No, I’ve got data. [laughs] I know. I can see Casey here on video and Casey's mouth just went open [laughs] It's like, “Yes, no, it's, that's real.” No shade on the people I've worked with, I love them, but like, this is such a thing. There are cynics in corporate leadership who want to focus on profit and sometimes, you have to make a cynical argument in business and a cynical argument can come down to data and this data says, “No, look, if we get more people in here who look different from us, we're going to make more money and that's good for you and your bottom line.” So sometimes you have to walk the argument back to that, even if it feels gross and it does, it's like, “No, this actually matters to your bottom line.” DAMIEN: That's a great argument and it's a positive argument. In my view of corporations, I feel like the larger they get, the more you have an agency problem where people aren't looking to take risks to get the positive benefits, they're going to do things to avoid backlash and negative things. So I think larger company, more middle management, more people you’re answerable to, especially on the short-term, the more people are better motivated by fear. So for that, I want to pull out like, what are the risks of homogeneity? You mentioned the Nova. You mentioned like, oh, there was – [laughs] I pull this out far too often. There was an AI image classifier that classified Black people as gorillas. There was a store. Oh goodness, I think it was an Apple store. Beautiful, beautiful architecture, glass everywhere, including the stairs. These are all the harms that come from homogeneity. [laughs] What was the expensive fixing those stairs? It couldn't have been cheap. JESS: Oh my gosh. [chuckles] I don't even wear skirts that often. [laughs] DAMIEN: And I know that's a problem because when I heard that story, I was multiple paragraphs in before I realized the problem. I wear skirts less than you, I'm sure. [laughter] JESS: For sure. Oh, that's amazing. Yeah, I think those stories are really important for us to be able to tell and to share with each other because diversity matters. I think it's easy to say that and especially among people who care, people who prioritize it. We almost take it as like a, “Well, of course,” but I think there is still, getting back to that quiet group of people who don't say what they actually think, there's a lot of people who are on the fence, or maybe frankly disagree. It's like, “Well, you can disagree and I respect your disagreement, but here's the data, here's the results, here's the impact. Let's talk about that. Do you have a better way to handle this? Because I don't.” DAMIEN: So I think the risk is especially acute in tech companies and in tech for tech companies where things are far more homogeneous. Next week on how to pronounce these words. [laughs] So what can we do? Is there anything special that we can do in those sort of environments? JESS: Yeah. Well, besides have the conversation, which I think is something we can all do. Not to fangirl too much about Amazon, but I really do like the company and I'm really enjoying my experience. A lot of it comes down to how we've expressed our leadership principles. We say this is our culture and our values and we actually apply it constantly like, if you ever come to talk to an Amazon person, I'm going to tell you about how I've disagreed and committed and what I'm doing to think big and how I'm customer obsessed. I'm going to talk about those things directly. To this, we say one of our leadership principles is that leaders are right a lot and that feels weird, right? Leaders are right a lot? “Oh, I just happen to know everything.” No, that's not what that means. We actually go into it in more depth and it's like leaders look to disconfirm their beliefs and seek diverse perspectives and we bake that right into one of our core cultural values. I think that that is absolutely critical to our ability to serve the broader tech community effectively. The fact that we hold leaders to being right through having gone through a crucible of finding out how they're wrong, I think is magical and I think that's actually something that a lot more companies could think to do. It's like, you as a tech person and you think, “Oh, I'm going to go sell this great new widget to all of my tech buddies.” Okay. You might be right. But how could you make that bigger? How could you make that better? Like go, try to find out how you're wrong. That should be something we value everywhere. It's like, “No, I'm probably wrong. I want to be right.” So the way to get right is to find out every way I'm wrong and that means talk to everybody you can and find out. CASEY: From our conversation here, I'm picking up a couple of tools we have to help persuade people to get them to be louder, or more proactive at least. Data is one. Telling stories from other companies is another one. And then here, I'm picking up get your own stories that you can really tell from your point of view and that's maybe the strongest of the three, really. The change is you, too. I love that idea. JESS: Yeah. We had a internal conference this week, the networking summit, and there was a great session last night from somebody talking about what customers love and what customers hate about our products. He was just telling story after story about customers saying, “Oh, I'm so frustrated with this.” “I would love to change that.” Those stories, I think have so much more weight in our minds. Humans are evolved to tell the stories to each other. So if we have stories to tell, I think those are so much – they connect at a deeper level almost and they help us think about not just that top of brain logical, almost engineering, binary yes, no, but it's more this deeper heart level. “I understand the story that led to this position. I understand the human that feels this way.” Personally, I think no matter how logical we think we are; [chuckles] we’re still walking bags of meat [laughs] and there's a lot to be said to respect that and to connect with that. So yeah, storytelling is huge. DAMIEN: You brought up, earlier in our conversation, about how things might be different with a different cultural paradigm. This is an enormous example of this. White Western culture overvalues logic and objectivity. It's a by-product of the culture and there's a conflation between objectivity and rationality and rightness. Weirdly enough, in my experience, that makes people less able to be rational and objective. It's quite amazing, ironic, and tragic. But if you follow the science, you follow the logic, you follow the rationality; what you'll discover is that humans are not naturally logical, rational beings. We are not rational beings that feel; we are feeling beings that rationalize. From the beginning from the birth of humans as a species, stories and communication have been how we navigate the world, how we see the world, how our beliefs and behaviors change and you can see that throughout all of history and it's the narratives that change everything. So that's something that is super important to have, to know and especially if you want to be effective. Having grown up in this culture, though, it amuses me to no end how little I use that knowledge. [laughs] I argue with logic and facts and wonder why don't people don't understand when I have all the logic and facts that tell me that that's not going to change what they do. [laughs] JESS: Oh, yeah. Honestly, I think our political climate right now is representative of that because it's like, I don't know, I feel like it's so logical and factual, my political perspectives, and then I'll talk to somebody else and they feel the exact same way. Having been in media, I've seen like a lot of what we end up believing is how we sold it to ourselves and the stories that we've told around it and what we've paid attention to. We've listened to it. It's so easy to develop this cognitive filter on the stories that don't line up to your expectations. I don't know. This is, I think an area that engineers really overlook time and time again, is the power of media and the power of the stories that we tell. Being a trans person, I didn't come out until I was in my late 30s because the stories, I grew up with of trans people were stories of serial killers, rapists, murderers, and people who were at the very edges of society and like, I'm like, “Well, I'm not that. I can't be trans.” [laughs] It wasn't until we had these news stories of love, or hate. Caitlyn Jenner, I think set a new story on the world and a lot of things changed around then where we were able to see ourselves in a light that wasn't just pain and I think that we've seen a lot more trans people come out because they're able to see themselves in these happier stories and better stories. So we need more stories like that. Like Pose, I think is amazing and great stories of standing up in a hard place and owning your power, even under all this adversity, I think it's incredible. Those set of stories, I think are just so incredible for everybody and we just need so much more. I could rant for a while. [laughs] CASEY: Yeah. I'm totally on board with this as a queer man, I wasn't comfortable for a lot of my life being that because of the representation. I'm not into drag, but that's not a requirement. [chuckles] A friend of mine just shared a list of children's books that are incidentally queer and I just think that's so cool. The phrase, even. They're just regular storybooks, not about being queer as a topic, but just people doing normal stuff that happened to have including queer characters. JESS: I love that. CASEY: The world is changing. JESS: Yes, and I think we have a responsibility to be a part of that storytelling. Let's tell stories and it doesn't have to be a big deal that the person you’re talking about is a female engineer. No, she just happens to be an engineer. Let's tell stories where he has a husband. Who cares? He has a husband, it's great. It's not the focus of the story. It's just a part of the whole, the melior that we're in. That's really important. So, I think a lot of normalizing – a lot of acceptance comes through normalization and honestly, it's so complicated because there's this tendency to whitewash when you go into this normalizing place. It's like, “Oh, I don't see skin tone.” No, I think that's not the way to do it. I think it's like there are differences in us, in our backgrounds, in our cultures, in our experiences, and that is incredible and that is wonderful, and it's not the story, but it's a part of the story and that's an important part. DAMIEN: Yeah, as a Black man, I've definitely seen this. I like to say Black Panther was the best thing that happened to African-Americans in the history of cinema. Get Out is another example. It's very much about the Black experience, but it's not the old story of what being Black in America is like and so, it's very different. JESS: Definitely. Yeah. CASEY: We're getting near the end of time we have today, let's shift gears into what we normally do at the end, our reflections. What's something that you're going to take away from this conversation? Jess, or Damien, who wants to go first? JESS: I'll start because I already wrote it down here. Damien, you said, “We are feeling beings that rationalize.” That is going to stick with me. That was profound. I love that and it's so obvious, I think but I'd never thought to think of it that way, or to say it that way. So I’ve got to think about that one for a while, but that's, I think really going to stick with me. Thank you. DAMIEN: Thank you, Jess. That's quite an honor. I can drag out like probably a half dozen off the top of my head, or a dozen probably store of scientific studies that show that. [laughs] I never get enough of them mostly because I've been rationalizing more. Anyway, my reflection is really on how technology impacts culture, both within the technologists and how that relates to storytelling, communication, and language. All those things are creating culture and all those things exist in technology, in between technologists, and that's how we can make our culture. It's something that I want it to be, or more like something I want it to be. So thank you. JESS: That's awesome. CASEY: I think my takeaway is I'm noticing that I said I'm very loud and outspoken about a lot of stuff, and I care a lot about diversity, equity, and inclusion, especially when I’m groups of people talking about it, I talk about that all the time. But can I and how can I take that loudness for diversity, equity, and inclusion with people who don't always talk about it? Who can I approach and how can I tell who is more open to it or not? That's always a big open question for me. I guess, I'll be thinking about that especially this week. JESS: Well, this was a pleasure. Thank you for having me. DAMIEN: This was great, Jess. Thank you so much for joining us. JESS: Yeah, it was delightful. DAMIEN: I suppose this might be a good time to plug our Slack community, which is available to all Patreon for the podcast and also, all of our guests. So Jess, if you want to join us there and we can nerd out some more. I’ll keep throwing you instruments to try and stump you. JESS: Yes! Bring it on! [laughs] Special Guest: Jess Szmajda.

An airhacks.fm conversation with Ken Finnigan (@kenfinnigan) about: Commodore 64 in 1984, Commodore 128D in 1986, creating a Star Wars game, approaching the dark star, a Gateway XT with 20 MB hard drive and 640kB RAM, playing with DBase IV, Lotus 1-2-3 and Delphi, implementing software for baseball statistics in 1989, surviving a Giants game in San Francisco, learning C++, Modula 2 and assembly programming at university, the JavaONE session marathon, learning Java in 1999, enjoying Java programming, starting at IBM Global Services Australian, introduction to the enterprise world with PL 1, Job Control Language (JCL), AIX, CICS and CTG, starting to work with Java 1.2 at an insurance company, building a quotation engine in Java, wrapping JNI layer to reuse legacy C++ code, creating the first web UIs with Java with JSPs and Servlets, PowerBuilder and Borland JBuilder, enjoying the look and feel of Visual Age for Java and JBuilder, Symantec Visual Cafe for Java, Sun Studio Java Workshop had the worst look and feel, writing backend integration logic with XSLT and XML in Dublin, Apache FOP and Apache Cocoon, XSLT transformations in browser, enjoying the marquee tag, using SeeBeyond eWay integration in London, switching to chordiant Java EE CRM solution, using XDoclet to generate EJBs, from XDoclet to annotations, wrapping, abstracting and Aspect Oriented Programming framework, it is hard to find business use cases for AOP, J2EE already ships with built-in aspects, enterprise architecture and UML, using IBM Rational Software Modeler for architectures, driving a truck with tapes as migration, the Amazon Snowmobile Truck, never underestimate the bandwidth of a truck full of hard disks, "Never underestimate the bandwidth of a station wagon full of tapes hurtling down the highway", Andrew S. Tanenbaum, building stock trading platform in Sydney with J2EE, Complex Event Processing (CEP) with J2EE and JBoss, attending JBoss World in Florida and meeting Pete Muir, starting with Seam 2 to write a CRM solution for weddings, contributing to Seam 3, creating annotation-based i18n solution, joining RedHat consulting, migrating from Oracle Application Server to JBoss EAP 5, joining RedHat engineering, leading portlet bridge from JBoss Portal project, starting project LiveOak, apache sling, starting project WildFly Swarm with Bob McWhirter, WildFly Swarm vs. WildFly, WildFly Swarm and WildFly - the size perspective, WildFly Swarm supported hollow jars, hollow jar allows docker layering, WildFly Swarm was renamed to Thorntail, Thorntail 4 was a rewrite of the CDI container, Thorntail 4 codebase was used in Quarkus, Quarkus is the evolutionary leap forward, Quarkus observability and micrometer, working with OpenTelemetry, OpenTelemetry and micrometer, OpenCensus, Eclipse MicroProfile and Metrics, micrometer vs. MicroProfile metrics, GitHub issue regarding custom registry types, airhacks.fm episode with Romain Manni-Bucau #79 Back to Shared Deployments, starting with counters and gauges in MicroProfile, metrics in a Java Message Service (JMS) application, MicroProfile metrics could re-focus on business metrics, services meshes vs. MicroProfile Fault Tolerance, Istio is only able to see the external traffic, implementing business fallbacks with Istio is hard, OpenMetrics and OpenTracing are merging in OpenTelemetry, MicroProfile OpenTracing comes with a single annotation and brings the most added value, Jakarta EE improvements are incremental, Java's project leyden, the MicroProfile online workshop, Jakarta EE and MicroProfile complement each other, GraalVM and JavaScript, pooling with CDI is challenging, MicroProfile as layer on top of Jakarta EE, the smallrye first approach Ken Finnigan on twitter: @kenfinnigan, Ken's blog: kenfinnigan.me

The conversation covers:  An overview of Ravi's role as an evangelist — an often misunderstood, but important technology enabler.  Balancing organizational versus individual needs when making decisions. Some of the core motivations that are driving cloud native migrations today.  Why Ravi believes it in empowering engineers to make business decisions.  Some of the top misconceptions about cloud native. Ravi also provides his own definition of cloud native. How cloud native architectures are forcing developers to “shift left.” Links https://harness.io/ Twitter: https://twitter.com/ravilach Harness community: https://community.harness.io/ Harness Slack: https://harnesscommunity.slack.com/ TranscriptEmily: Hi everyone. I'm Emily Omier, your host, and my day job is helping companies position themselves in the cloud-native ecosystem so that their product's value is obvious to end-users. I started this podcast because organizations embark on the cloud naive journey for business reasons, but in general, the industry doesn't talk about them. Instead, we talk a lot about technical reasons. I'm hoping that with this podcast, we focus more on the business goals and business motivations that lead organizations to adopt cloud-native and Kubernetes. I hope you'll join me.Welcome to The Business of Cloud Native, I am your host Emily Omier. And today I'm chatting with Ravi Lachhman. Ravi, I want to always start out with, first of all, saying thank you—Ravi: Sure, excited to be here.Emily: —and second of all, I like to have you introduce yourself, in your own words. What do you do? Where do you work?Ravi: Yes, sure. I'm an evangelist for Harness. So, what an evangelist does, I focus on the ecosystem, and I always like the joke, I marry people with software because when people think of evangelists, they think of a televangelist. Or at least that's what I told my mother and she believes me still. I focus on the ecosystem Harness plays in. And so, Harness is a continuous delivery as a service company. So, what that means, all of the confidence-building steps that you need to get software into production, such as approvals, test orchestration, Harness, how to do that with lots of convention, and as a service.Emily: So, when you start your day, walk me through what you're actually doing on a typical day?Ravi: a typical day—dude, I wish there was a typical day because we wear so many hats as a start-up here, but kind of a typical day for me and a typical day for my team, I ended up reading a lot. I probably read about two hours a day, at least during the business day. Now, for some people that might not be a lot, but for me, that's a lot. So, I'll usually catch up with a lot of technology news and news in general. They kind of see how certain things are playing out. So, a big fan of The New Stack big fan of InfoQ. I also like reading Hacker News for more emotional reading. The big orange angry site, I call Hacker News. And then really just interacting with the community and teams at large. So, I'm the person I used to make fun of, you know, quote-unquote, “thought leader.” I used to not understand what they do, then I became one that was like, “Oh, boy.” [laughs]. And so just providing guidance for some of our field teams, some of the marketing teams around the cloud-native ecosystem, what I'm seeing, what I'm hearing, my opinion on it. And that's pretty much it. And I get to do fun stuff like this, talking on podcasts, always excited to talk to folks and talk to the public. And then kind of just a mix of, say, making some sort of demos, or writing scaffolding code, just exploring new technologies. I'm pretty fortunate in my day to day activities.Emily: And tell me a little bit more about marrying people with software. Are you the matchmaker? Are you the priest, what role?Ravi: I can play all parts of the marrying lifecycle. Sometimes I'm the groom, sometimes I'm the priest. But I'm really helping folks make technical decisions. So, it's go a joke because I get the opportunity to take a look at a wide swath of technology. And so just helping folks make technical decisions. Oh, is this new technology hot? Does this technology make sense? Does this project fatality? What do you think? I just play, kind of, masters of ceremony on folks who are making technology decisions.Emily: What are some common decisions that you help people with, and common questions that they have?Ravi: Lot of times it comes around common questions about technology. It's always finding rationale. Why are you leveraging a certain piece of technology? The ‘why' question is always important. Let's say that you're a forward-thinking engineer or a forward-thinking technology leader. They also read a lot, and so if they come across, let's say a new hot technology, or if they're on Twitter, seeing, yeah, this particular project's getting a lot of retweets, or they go in GitHub and see oh, this project has little stars, or forks. What does that mean? So, part of my role when talking to people is actually to kind of help slow that roll down, saying, “Hey, what's the business rationale behind you making a change? Why do you actually want to go about leveraging a certain, let's say, technology?” I'm just taking more of a generic approach, saying, “Hey, what's the shiny penny today might not be the shiny penny tomorrow.” And also just providing some sort of guidance like, “Hey, let's take a look at project vitality. Let's take a look at some other metrics that projects have, like defect close ratio—you know, how often it's updates happening, what's your security posture?” And so just walking through a more, I would say the non-fun tasks or non-functional tasks, and also looking about how to operationalize something like, “Hey, given you want to make sure you're maintaining innovation, and making sure that you're maintaining business controls, what are some best operational practices?” You know, want to go for gold, or don't boil the ocean, it's helping people make decisive decisions.Emily: What do you see as sort of the common threads that connect to the conversations that you have?Ravi: Yeah, so I think a lot of the common threads are usually like people say, “Oh, we have to have it. We're going to fall behind if you don't use XYZ technology.” And when you really start getting to talking to them, it's like, let's try to line up some sort of technical debt or business problem that you have, and how about are you going to solve these particular technical challenges? It's something that, of the space I play into, which is ironic, it's the double-edged sword, I call it ‘chasing conference tech.' So, sometimes people see a really hot project, if my team implements this, I can go speak at a conference about a certain piece of technology. And it's like, eh, is that a really rational reason? Maybe. It kind of goes into taking the conversation slightly somewhere else. One of the biggest challenges I think, let's say if you're kind of climbing the engineering ranks—and this is something that I had to do as I went from a junior to a staff to a principal engineer in my roles—with that it's always having some sort of portfolio. So, if you speak at a conference, you have a portfolio, people can Google your name, funny pictures of you are not the only things that come up, but some sort of technical knowledge, and sometimes that's what people are chasing. So, it's really trying to have to balance that emotional decision with what's best for the firm, what's best for you, and just what's best for the team.Emily: That's actually a really interesting question is sometimes what's best for the individual engineer is not what's best for the organization. And when I say individual engineer, maybe it's not one individual, but five, or the team. How do you sort of help piece together and help people understand here's the business reason, that's organization-wide, but here's my personal motivation, and how do I reconcile these, and is there a way even to get both?Ravi: There actually is a way to get both. I call it the 75/25 percent rule. And let's take all the experience away from the engineers, to start with a blank slate. It has to do with the organization. An organization needs to set up engineers to be successful in being innovative. And so if we take the timeline or the scale all the way back to hiring, so when I like to hire folks, I always like to look at—my ratio is a little bit different than 75/25. I'm more of a 50/50. You bring 50 percent of the skills, and you'll learn 50 percent of the skills, versus more conservative organizations would say, “You know what? You have 75 percent of the skills, if you can learn 25 percent of the skills, this job would be interesting to you.” Versus if you have to learn 80 percent, it's going to be frustrating for the individual. And so having that kind of leeway to make decisions, and also knowing that technical change can take a lot of time, I think, as an engineer, as an engineer—as talking software engineering professions as a whole, how do you build your value? So, your value is usually calculated in two parts. It's calculated in your business domain experience and your technical skills. And so when you go project to project—and this is what might be more of, hey, if you're facing too big of a climb, you'll usually change roles. Nobody is in their position for a decade. Gone are the days that you're a lifetime engineer on one project or one product. It's kind of a given that you'll change around that because you're building your repertoire in two places: you're building domain experience, and you're building technical experience. And so knowing when to pick your battles, as cliche as that sounds, oh, you know what, this particular technology, this shiny penny came out. I seen a lot of it when Kubernetes came out, like, “Oh, we have to have it.” But—or even a lot of the cloud-native and container-based and all the ‘et cetera accessories' as I call it, as those projects get steam surrounding it. It's, “We have to have it.” It's like, eh. It's good for resume building, but there's your things to do on your own also to learn it. I think we live in a day of open source. And so as an engineer, if I want to learn a new skill, I don't necessarily have to wait for my organization to implement it. I could go and play, something like Katacoda, I can go do things on my own, I can learn and then say, “You know what, this is a good fit. I can make a bigger play to help implement it in the organization than just me wanting to learn it.” Because a lot of the learning is free these days, which I think it's amazing. I know that was a long-winded answer. But I think you can kind of quench the thirst of knowledge with playing it on your own, and that if it makes sense, you can make a much better case to the business or to technology leadership to make change.Emily: And what do you think the core business motivations are for most of the organizations that you end up talking to?Ravi: Yeah, [unintelligible] core motivation to leveraging cloud-native technology, it really depends on organization to organization. I'm pretty fortunate that I get to span, I think, a wide swath of organization—so from startups to pretty established enterprises—I kind of talk about the pretty established enterprises. A lot of the business justification, it might not be a technical justification, but there's a pseudo technical business reason, a lot of times, though, I when I talk to folks, they're big concern is portability. And so, like, hey, if you take a look at the dollar and cents rationale behind certain things, the big play there is portability. So, if you're leveraging—we can get into the definition of what cloud-native resources are, but a big draw to that is being portable—and so, hopefully, you're not tied down to a single provider, or single purveyor, and you have the ability to move. Now, that also ties into agility. Supposedly, if you're able to use ubiquitous hardware or semi-ubiquitous software, you were able to move a little bit faster. But again, what I usually see is folk's main concern is portability. And then also with that is [unintelligible] up against scale. And so as—looking at ways of reducing resources, if you could use generics, you're able to shop around a little bit better, either internally or externally, and help provide scale for a softer or lesser cost.Emily: And how frequently do you think the engineers that you talked to are aware of those core business motivations?Ravi: Hmm, it really depends on—I'm always giving you the ‘depends' answer because talking to a wide swath of folks—where I see there's more emotion involved in a good way if there's closer alignment to the business—which is something hard to do. I think it is slowly eroding and chipping away. I've definitely seen this during my career. It's the old stodgy business first technology argument, right. Like, modern teams, they're very well [unintelligible] together. So, it's not a us versus them or cat versus dog argument, “Oh, why do these engineers want to take their sweet time?” versus, “Why does the business want us to act so fast?” So, having the engineers empowered to make decisions, and have them looked at instead of being a cost center, as the center of innovation is fairly key. And so having that type of rationale, like, hey, allowing the engineers to give input into feature development, even requirement development is something I've seen changed throughout my career. It used to be a very special thing to do requirements building, versus most of the projects that I've worked on now—as an engineer, we're very, very well attuned to the requirements with the business.Emily: Do you think there's anything that gets lost in translation?Ravi: Oh, absolutely. As people, we're emotional. And so if we're all sum total of our experiences—so let's say if someone asked, Emily, you and I a question, we would probably have four different answers for that person, just because maybe we have differences in opinions, differences of sum totals of experience. And I might say, “Hey, try this or this,” and then you might say, “Try that or that.” So, it really depends. Being lost in translation is always—it's been a fundamental problem in requirements gathering and it's continued to be a fundamental problem. I think just taking that question a step further, is how you go about combating that? I think having very shortened feedback cycles are very important. So, if you have to make any sort of adjustments, gone are the days I think when I started my career, waterfall was becoming unpopular, but the first project or two I was on was very waterfall-ish just because of the size of the project we worked on, we had to agree on lots of things; we were building something for six months. Versus, if you look at today, modern development methodologies like Agile, or Scaled Agile, a lot of the feedback happens pretty regularly, which can be exhausting, but decisions are made all the time.Emily: Do you think in addition to mistranslations, do you think there are any misconceptions? And I'm talking about sort of on both sides of this equation, you know, business leaders or business motivations, and then also technologists, and let's refocus back to talk about cloud-native in particular. What sort of misconceptions do you think are sort of floating out there about cloud-native and what it means?Ravi: Yeah, so what cloud-native means—it means something different to everybody. So, you listen to your podcasts for a couple episodes, if you asked any one of the guests the question, we all would give you a different answer. So, in my definition of cloud-native—and then I'll get back to what some of the misconceptions are—I have a very basic definition: cloud-native means two pillars. It means your architecture, or your platform needs to be ephemeral, and it needs to be [indibited]. So, it needs to be able to be short-lived, and be consistent, which are two things that are at odds with each other. But if you kind of talk to folks that, hey, they might be a little more slighted towards the business, they have this idea that cloud-native will solve all your problems. So, it reminds me a lot of big data back in the day. “Oh, if you have a Hadoop cluster, it will solve all of our logistics and shipping problems.” No. That's the technology. If you have Kubernetes, it will solve all of our problems. No. That's the technology. It's just a conduit of helping you make changes. And so just making sure that understand that hey, cloud-native doesn't mean that you get the checkmark that, “Oh, you know what? We're stable. We're robust. We can scale by using all cloud-native technologies,” because cloud-native technologies are actually quite complicated. If you're introducing a lot of complexity to your architecture, does it make sense? Does that make sense? Does it give you the value you're looking for? Because at the end of the day, and this is kind of something, the older I get, the more I believe it, is that your customers don't care how you did something; they care what the result is. So, if your web application's up, they don't care if you're running a simple LAMP stack, they just care that the application is up, versus using the latest Kubernetes stack, but using some sort of cloud-native NoSQL database, and we're using [Istio], and we're using, pick your flavor du jour of cloud-native technology, your end customer actually doesn't care how you did it. They care what happened.Emily: We can talk about misconceptions that other people have, but is there anything that continues to surprise you?Ravi: Yeah, I think the biggest misconception is that there's very limited choice. And so I'll play devil's advocate, I think the CNCF, the Cloud Native Computing Foundation, there's lots of projects, I've seen the CNCF, they have something called the CNCF Landscape, and I seen it grow from 200 cards, it was 1200 cards at KubeCon, I guess, end of last year in San Diego, and it's hovering around 1500 cards. So, these cards means there's projects or vendors that play in this space. Having that much choice—this is usually surprising to people because they—if you're thinking of cloud-native, it's like saying Kleenex today, and you think of Kubernetes or other auxiliary product or project that surrounds that. And a lot of misconception would be it's helping solve for complexity. It's the quintessential computer science argument. All you do in computer science is move complexity around like an abacus. We move it left to right. We're just shifting it around, and so by leveraging certain technologies there's a lot of complication, a lot of burden that's brought in. For example, if you want to leverage, let's say, a service Istio, Istio will not solve all your networking problems. In fact, it's going to introduce a whole set of problems. And I could talk about my biggest outage, and one of the things I see with cloud-native is a lot of skills are getting shifted left because you're codifying areas that were not codified before. But that's something I would love to talk about.Emily: Tell me about your biggest outage that sounds interesting.Ravi: Yeah, I didn't know how it would manifest itself. It's ways, I think, until, like, years later that I didn't have the aha moment. I used to think it was me, it probably still is me, but—so the year was 2013, and I was working for a client, and we were—it's actually a large news site—and so we were in the midst of modernizing their application, or their streaming application. And so I was one of the first applications to actually go to AWS. And so my background is in Java, so I have a Java software engineer or J2ED or JEE engineer, and having to start working more in infrastructure was kind of a new thing, so I was very fortunate up until 2013-ish up until this point that I didn't really touch the infrastructure. I was immune to that. And now being more, kind of becoming a more senior engineer was in charge of the infrastructure for the application—which is kind of odd—but what ended up happening that—this is going to be kind of funny—since I was one of the first teams to go to AWS, the networking team wouldn't touch the configurations. So, when we were testing things, and [unintelligible] environments, we had our VPC CIDR rules—so the traffic rules—wide open. And then as we were going into production, there were rules that we had to limit traffic due to a CIDR so up until 2013, I thought a C-I-D-R like a CIDR was something you drink. I was like, “What? Like apple cider?” So, this shows you how much I know. So, basically, I had to configure the VPC or Virtual Private Cloud networking rules. Finally, when we deployed the application, unknowing to myself, CIDR calculation is a significant digit calculation. So, the larger the number you divide by, the more IPs you let in. And so instead of dividing by 16, I divided by 8. I was like, “Oh, you'll have a bigger number if you divide by a smaller number.” I end up cutting off half the traffic of the internet when we deployed to production. So, that was a very not smooth way of doing something. But how did this manifest itself? So, the experts, who would have been the networking team, refused to look at my configuration because it was a public cloud. “Nope, you don't have a slot in our data center, we look at it.” And poor me, as a JEE or J2EE engineer, I had very little experience networking. Now, if you fast forward to what this means today, a lot of the cloud-native stack, are again, slicing and dicing these CNCF cards, a lot of this, you're exposing different, let's say verticals or dimensions to engineers that they haven't really seen before. A lot of its networking related a lot of it can be storage related. And so, as a software engineer, these are verticals that I'd never had to deal with before. Now, it's kind of ironic that in 2020, hey, yes, you will be dealing with certain configurations because, hey, it's code. So, it's shifting the burden left towards the developer that, “Oh, you know what, you know networking—” or, “You do need to know your app, so here's some Istio rules that you need to include in your packaging of your application.” Which folks might scratch your head. So, yeah, again, it's like shifting complexity away from folks that have traditional expertise towards the developer. Now, times are changing. I seen a lot of this in years gone by, “Oh, no. These are pieces of code. We don't want to touch it.” Being more traditional or legacy operations team, versus today, everybody—it's kind of the merging of the two worlds. The going joke is all developers are becoming infrastructure engineers, and infrastructure engineers are becoming software engineers. So, it's the perfect blend of two worlds coming together.Emily: That's interesting. And I now think I understand what you mean by skills shifting left. Developers have to know more, and more, and more. But I'm also curious, there's also people who talk about how Kubernetes, one of its failures is that it forces this shift left of skills and that the ideal world is that developers don't need to interact with it at all. That's just a platform team. What do you think about that?Ravi: These are awesome questions. These are things I'm very passionate about. I definitely seen the evolution. So, I've been pretty fortunate that I was jumping on the application infrastructure shift around 2014, 2015, so right when Kubernetes was coming of age. So, most of my background was in distributed systems. So, I'm making very large distributed Java applications. And so when Kubernetes came out, the teams that I worked on, the applications that were deployed to Kubernetes were actually owned by the app dev team. The infrastructure team wouldn't even touch the Kubernetes cluster. It was like, “Oh, this is a development tool. This is not a platform tool.” The platform teams that I were interacting with 2015, 2016, as Kubernetes became more popular than ever, they were the legacy—well, hate to say legacy because it's kind of my background too—they were the remaining middleware engineers. We maintained a web server cluster, we maintained the message broker cluster, we maintained XYZ distributed Java infrastructure cluster. And so when looking at a tool like Kubernetes, or even there were different platforming services, so the paths I've leveraged early, or mid-2010s was Red Hat OpenShift, before and after the Kubernetes migration inside of OpenShift. And so looking at a different—how teams are set up, it used to be, “Oh, this is an app dev item. This is what houses your application.” Versus today, because the workloads are so critical that are going on to say platforms such as Kubernetes, it was that you really need that system engineering bubble of expertise. You really need those platform engineers to understand how to best scale, how to best purvey, and maintain a platform like Kubernetes. Also, one of the odd things are—going back to your point, Emily, like, hey, why things were tossed over either to the development team or going back to a developing software engineer myself, do we care what the end system is?So, it used to be, I'll talk about Java-land here for a minute, give you kind of long-winded answer of back in Java land, we really used to care about the target system, not necessarily for an application that have one node, but if we had to develop a clustered application. So, we have more than one node talking to each other, or a stateful application, we really had start developing to a specific target system. Okay, I know how JBoss WildFly clusters or I know how IBM WebSphere or WebLogic clusters. And so when we're designing our applications, we had to make sure that we play well into those clustering mechanisms. With Kubernetes, since it's generic, you don't necessarily have to play into those clustering mechanisms because there's a basic understanding. But that's been the biggest Achilles heel in Kubernetes. It wasn't designed for those type of workloads, stateful workloads that don't like dying very often. That's kind of been the push or pull. It's just a tool, there's a lot of generic, so you can assume that the target platform will handle a certain way. And you're slowly start backing off the case that you're building to a specific target platform. But as Kubernetes has evolved, especially with the operator framework, you actually are starting to build to Kubernetes in 2018, 2019, 2020.Emily: It actually brought up a question for me that, at risk of sounding naive myself, I feel like I never meet anybody who introduces themselves as a platform engineer. I meet all these developers, everyone's a developer evangelist, for example, or their background is as a developer, I feel like maybe once or twice, someone has introduced themselves as, “I'm a platform engineer,” or, “I'm an operations specialist.” I mean, is that just me? Is that a real thing?Ravi: They're very real jobs. I think… it's like saying DevOps engineer, it means something else to who you talk to you. So, I'll harp on, like ‘platform engineer.' so kind of like, the evolution of the platform engineer, if you would have talked to me in 2013, 2014, “Hey, I'm a platform engineer,” I would think that you're a software engineer focused on platform tools. Like, “Hey, I focus on authentication, authorization.” You're building—let's say we had a dozen people on this call and we're working for Acme Incorporated, there's modules that transcend every one of our teams. Let's say logging, or let's say login, or let's say, some sort of look and feel. So, the platform engineer or the platform engineering development focused platform engineering team would make common reusable modules throughout. Now, with the great rise of platforms as a service, like PCF, and OpenShift, and DCOS, they became kind of like a shift. The middleware engineers that were maintaining the message broker clusters, maintaining your web application server clusters, they're kind of shifting towards one of those platforms. Even today, Kubernetes, pick your provider du jour of Kubernetes. And so those are where the platform engineers are today. “Hey, I'm a platform engineer. I focus on OpenShift and Kubernetes.” Usually, they're very vertically focused on one or more specific platforms. And operations folks can ride very big gamut. Usually, if you put, “operations” in quotes, usually they're systems or infrastructure engineers that are very focused on the infrastructure where the platform's run.Emily: I'm obviously a words person, and it just seems like there's this vocabulary issue where everybody knows what a developer is, and so it's easy to say, “Oh, I'm a developer.” But then everything else that's related to engineering, there's not quite as much specificity, precisely because you said everybody has a slightly different understanding. It's kind of interesting.Ravi: Yeah, it's like, I think as a engineer, we're not one for titles. So, I think a engineer is a engineer. I think if you asked most engineers, it's like, “Yeah, I'm a engineer.” It's so funny, a good example of that is Tim Berners-Lee, the person who created WWW, the World Wide Web. If you looked at his LinkedIn, he just says he's a web developer. And he invented WWW. So, usually engineering-level folks, you're not—at least for myself—is not one for title.Emily: The example that you gave regarding the biggest outage of your career was basically a skills problem. Do you think that there's still a skills or knowledge issue in the cloud-native world?Ravi: Oh, absolutely. We work for incentivization. You know, my mortgage is with PNC, and they require a payment every month, unfortunately. So, I do work for an employer. Incentivization is key. So, kind of resume chasing, conference chasing there's been some of that in the cloud-native world, but what ends up happening more often than not is that we're continuously shifting left. A talk I like to give is called, “The Engineering Burden is on the Rise.” And taking a look at what, let's say, a software engineer was required to do in 2010 versus what a software engineer is required to do today in 2020. And there's a lot more burden in infrastructure that, as a software engineer you didn't have to deal with. Now, this has to do with two things, or actually one particular movement. There's a movie company, or a video company in Los Gatos, California, and there's a book company in South Lake Union in Seattle. And so these two particular companies given the rise of what's called a full lifecycle developer. Basically, if you run it, or if you operate—you operate what you run, or if you write it, you run it. So, that means that if you write a piece of code, you're in charge of the operations. You have support, you're in charge of the SLAs, SLOs, SLIs. You're ultimately responsible if a customer has a problem. And can you imagine the number of people, the amount of skill set that requires? There's this concept of a T-shaped skill that you have to have experience in so many different platforms, that it becomes a very big burden. As an engineer, I don't envy anybody entering a team that's leveraging a lot of cloud-native technology because most likely a lot of that onus will fall on the software engineer to create the deployable, to create how you build it, to fly [unintelligible] in your CI stack, write the configuration that builds it, write the configuration deploys it, write the networking rules, write how you test it, write the login interceptors. So, there's a lot going on.Emily: Is there anything else that you want to add about your experience with cloud-native that I haven't really thought to ask, yet?Ravi: It's not all doom and gloom. I'm very positive on cloud-native technologies. I think it's a great equalizer. You're kind of going back—this might be a more intrinsic, like a 30-second answer here. If you taking back that I wanted to learn certain skills in 2010, I basically had to be working for a firm. So, 2010, I was working for IBM. So, there's certain distributed Java problems I wanted to solve. I basically had to be working for a firm because the software licensing costs were so expensive, and that technology wasn't very democratized. Looking at cloud-native technology today, there's a big, big push for open source, which open source is R&D methodology. That's what open source is, it helps alleviate some sort of acquisition—but not necessarily adoption—problems. And you can learn a lot. Hey, you could pick up any project and just try to learn, try to run it. Pick up these particular distributed system skills that were very guarded, I would say, a decade ago, it's being opened up to the masses. And so there's a lot to drink from, but you can drink as much as you want from the CNCF or the cloud-native garden hose.Emily: Do you have a software engineering tool that you cannot live without?Ravi: Recently, because I deal in a lot of YAML, I need a YAML linter. So, YAML is a space-separated language. As a human, I can't tell you what spaces are. Like, you know, if you have three spaces, and the next line you have four spaces. So, I use a YAML linter. It puts periods for me, so I can count them because it's been multiple times that my demo is not syntactically correct because I missed a space and I can't see it on my screen.Emily: And how can listeners connect with you?Ravi: Oh, yeah. You can hit me up on Twitter @ravilach, R-A-V-I-L-A-C-H. Or come visit us at Harness at www.harness.io. I run the Harness community, so community.harness.io. We have a Slack channel and a Discourse, and always excited to interact with people.Emily: Thanks for listening. I hope you've learned just a little bit more about the business of cloud-native. If you'd like to connect with me or learn more about my positioning services, look me up on LinkedIn: I'm Emily Omier, that's O-M-I-E-R, or visit my website which is emilyomier.com. Thank you, and until next time.Announcer: This has been a HumblePod production. Stay humble.

We here at David Sizemore think we know that it is better to transition macro-robustly than to maximize dynamically. We pride ourselves not only on our value-added feature set, but our user-proof administration and user-proof configuration. Think plug-and-play. Think social-network-based. Think web-enabled. But don't think all three at the same time. The metrics for applications are more well-understood if they are not affiliate-based. Our clicks-and-mortar feature set is unmatched, but our synergistic Total Quality Management and non-complex use is constantly considered a terrific achievement. If you actualize transparently, you may have to deploy iteravely. We believe we know that if you upgrade wirelessly then you may also actualize efficiently. We think that most real-time web applications use far too much ActionScript, and not enough Flash. What does the term "bricks-and-clicks" really mean? We believe we know that if you orchestrate holistically then you may also optimize strategically. We understand that it is better to enable robustly than to revolutionize dynamically.David Sizemore has revolutionized the conceptualization of Total Quality Management. Without CAD, you will lack data hygiene. What do we engineer? Anything and everything, regardless of unimportance! Imagine a combination of Perl and CSS. Our feature set is unmatched, but our B2B2C revolutionary, real-world, wireless blog-based, back-end, leading-edge TQM and simple operation is usually considered a terrific achievement. We usually repurpose killer bandwidth. That is an amazing achievement considering this quarter's conditions! We apply the proverb "A barking dog never bites" not only to our B2B social networks but our capability to productize. The six-sigma re-purposing factor can be summed up in one word: virally-distributed. We have come to know that if you mesh extensibly then you may also drive efficiently. Think clicks-and-mortar. What does it really mean to exploit "holistically"?At David Sizemore, we have come to know how to embrace intuitively. We will revolutionize the term "24/7, virally-distributed". Without cross-platform TQM, you will lack six-sigma, intuitive, plug-and-play accounting compliance. Is it more important for something to be collaborative or to be co-branded? Without well-planned e-services, initiatives are forced to become out-of-the-box, B2B2C. The metrics for structuring are more well-understood if they are not synergistic. Think dot-com. Think short-term, clicks-and-mortar, impactful. Think vertical. But don't think all three at the same time. We will augment our aptitude to redefine without depreciating our aptitude to enable. Our feature set is unmatched in the industry, but our robust compliance and newbie-proof operation is usually considered a remarkable achievement. What does the commonly-used term "front-end" really mean? Your budget for morphing should be at least three times your budget for transitioning.At David Sizemore, we have come to know how to expedite intuitively. We constantly repurpose frictionless development metrics. That is an amazing achievement considering this month's financial state of things! Do you have a game plan to become transparent? We think we know that if you matrix perfectly then you may also e-enable compellingly. What does the term "turn-key compliance" really mean? We will revolutionize the term "B2B". Quick: do you have a client-focused plan of action for regulating emerging eyeballs? Quick: do you have a out-of-the-box plan of action for monitoring emerging functionalities? A company that can innovate faithfully will (one day) be able to streamline fiercely. What do we target? Anything and everything, regardless of abstruseness!We here at David Sizemore believe we know that it is better to maximize mega-dynamically than to monetize magnetically. Your budget for meshing should be at least three times your budget for syndicating. Our technology takes the best features of VOIP and J2EE. Your budget for deploying should be at least one-third of your budget for scaling. We understand that if you enhance transparently then you may also synthesize mega-strategically. What does it really mean to evolve "intuitively"? Without well-chosen architectures, channels are forced to become impactful. Is it more important for something to be interactive or to be cross-media? Think macro-scalable. The functionalities factor is sexy. Imagine a combination of CSS and XForms.At David Sizemore, we think we know how to embrace strategically. What do we leverage? Anything and everything, regardless of obscureness! What does it really mean to reintermediate "seamlessly"? What do we reinvent? Anything and everything, regardless of abstruseness! Is it more important for something to be front-end or to be C2C2C? What does the commonly-used industry jargon "C2B2B" really mean? We will whiteboard the term "robust". We think that most out-of-the-box web applications use far too much Python, and not enough JavaScript. Think vertical. Think robust. Think C2C2B. But don't think all three at the same time. We have proven we know that it is better to repurpose wirelessly than to architect transparently. Think nano-frictionless, C2C2B. Our technology takes the best aspects of HTTP and VOIP.David Sizemore has refactored the concept of experiences. The macro-one-to-one, front-end Total Quality Control supervising factor can be summed up in one word: user-defined. What does it really mean to enable "holistically"? Your budget for morphing should be at least twice your budget for meshing. What does the commonly-accepted buzzword "viral" really mean? Think magnetic. Think transparent. Think e-business. But don't think all three at the same time. The metrics for cutting-edge portals are more well-understood if they are not open-source. If you drive globally, you may have to implement compellingly. We will innovate the ability of systems to e-enable. Think intra-B2B2C.

Kevin sits down with Paul Doherty the President and CEO of the digital group, inc. They discuss the behavior changes to the new normal around corona virus. How will our decision-making change going forward? Has the pandemic caused designers of smart cities take a second look at their designs? Is it time to start building cities around life without automobiles? The digital group, inc is a company that provides industry-leading technology and management consulting services around the globe. Their delivery capability is anchored in an integrated set of core competencies that span people, processes and technology. Their service capabilities are coupled with practice competencies in Enterprise Search, Data Capability, Enterprise Mobility, System Administration, Web Software Engineering, Enterprise Solution, Information Management, Corporate Compliance, and Legacy Migration to name a few. The Digital Group is a Microsoft Certified Gold Partner with extensive technology experience in web enabled business solutions, Microsoft .NET, Microsoft SharePoint and related technologies, Oracle, J2EE and Open Source

An airhacks.fm conversation with Wolfgang Weigend (@wolflook) about: Atari 520 ST over XT 286, Motorola 68000 and C-Compilers for Atari 520 ST, first software company in 1987, Systems Engineer for Java and GraalVM, electronic engineer at Dupont, GSI in Darmstadt, writing networking software and an ERP system from scratch, controlling laser light shows, how to create noise with electronic devices, modis was succeeded by KHK / sage, learning enterprises by joining Oracle, analysing network stacks, optimising databases on Texas Instruments, joining Sun Microsystems in 1997, evangelising Java at Sun Microsystems, the challenge of buying a Sun Sparc Station, learning Java at Sun Microsystems, Java case study for German Railways, no one wanted to use Java on the server side, NetDynamics vs. Java Web Server, joining BEA after WebLogic acquisition, Andy Piper wrote clustering for WebLogic, BEA was the fastest growing company, Oracle bought BEA in October 2008, Deutsche Bank online banking system, and several hundreds projects at Deutsche Bahn were Java / WebLogic based, DHL and Deutsche Post were also heavy Java / BEA users, J2EE and Java EE allow developers focus on real problems, Java EE is a remedy against bike shedding, Wolfgang Weigend on twitter: @wolflook

An airhacks.fm conversation with Robert Brem (@bremrobert) about: Windows 95 with 15 for gaming, Nascar watching Korean StarCraft streams, writing the first Hello World in Visual Basic for Excel, in programming you can retrying without breaking anything, in ABAP everything had four letters, automating Excel merges with visual mode "on", hiding ABAP skills, ABAP could strike back with: Abular.js, Java 5 was released in September 2004, Generics were introduced with Java SE 6, annotations with Java SE 5, Sun Certified Programmer Certification was really hard, connecting WII controller to ActionScript 3, developing games in ActionScript 3, J2EE was too much, sustainable economics game as master thesis, saving the state of the game by serializing the board, the HSR in Rapperswil the beatiful place for lazy students, Peter Sommerlad was a demanding teacher but introduced Jenkins and automation, getting the color of the surface from satellites, the hosted GWT was slow, Spring Implementation of EJB container - project Pitchfork (now https://oss.oracle.com/projects/pitchfork/), deleting over upgrade, dependencies are fun for green field projects, the sequence of joy: GWT, ABAP and Eclipse RCP, the mensa club, the most sophisticated loading screen ever, the multi-dimensional Map (MapMap) solves all problems, automating infrastructure with Vagrant, Ansible and Packer, www.confirm.ch, all nails in the food has to be published in Switzerland, lit-html is the only dependency in the frontend and only Jakarta EE in the backend, sub MB ThinWARs and a few seconds deployment, building an entire application on one day, Robert Brem on twitter: @bremrobert

Das Ende ist nah! Am 14. Januar kommen die letzten Updates für Windows 7. Warum es eine schlechte Idee ist das alte Betriebssystem weiterhin zu nutzen, weiß Jan Schüssler. Ein Klassiker in der c't ist der große TV-Test zum Jahresende. Unsere Bildschirmexpertin Ulrike Kuhlmann hat sich Geräte ab 390 € angeschaut und kann sagen, worauf es beim Fernseherkauf zu achten gilt. Es ist öde in der Landschaft der Handybetriebssysteme, denn Android und iOS dominieren den Markt. Keywan Tonekaboni hat das Duopol verlassen und die Alternative Sailfish mitgebracht. Bitte nehmt an unserer großen c't-uplink-Umfrage teil und helft uns, c't uplink besser zu machen. Außerdem könnt ihr darüber bei unserer großen Prediction-Folge zum Jahresende mitmachen und uns eure Vorhersagen fürs nächste Jahr mitteilen: ct.de/uplink-umfrage === Anzeige / Sponsorenhinweis === Die ING ist zwar eine Bank aber bei denen dreht sich alles um digitale Anwendungen, die immer weiter entwickelt werden. Gesucht werden Leute für Frankfurt und Nürnberg, die richtig Lust auf ihren Job haben, die mit eigenen Ideen an den Start gehen, die sie dann im Team zusammen umsetzen. Untypisch für eine Bank, aber es läuft bereits alles agile. Ein bisschen Frustrationstoleranz braucht es – zugegeben - auch. Ist halt ein internationales Unternehmen, da geht nicht alles von heute auf morgen. Dafür gibt es aber faire Bezahlung, jede Menge Zusatzleistungen, 30 Tage Urlaub, Zuschüsse für Kinder- und Familienbetreuung, Gesundheit, Rente und vieles mehr. Und Möglichkeiten, sich in jede Richtung weiterzuentwickeln. Ein paar Skills muss man mitbringen: Gesucht werden Spezialisten. Aktuell vor allem • Java Entwickler (Frontend, Backend, Full-Stack und Entwickler mit Fokus Microservices) • DWH Entwickler, ETL Spezialisten • Applikationsbetreuer • Testmanager z.B. Last- & Performancetests • Machine Learning Engineers • Data Scientists • Spezialisten im Bereich IT Infrastruktur (Cloud-Engineer, Business Analysten, Netzwerk Spezialisten, IT Support Die ING arbeitet mit Skills/Tech Stack • Datenbanken Know-how (SQL, PL/SQL, ORACLE, IBM DataStage) • Java, JEE Middleware (Spring, Hibernate), J2EE, Microservices • Jbos • Workflowmanagement z. B. Automic/UC4 • Java mit Focus • Applikationsbetreuung auf Linux- und Windows Umgebungen • ITIL oder ITSM Erfahrung • Patch/Lifecycle/Securitymanagement • Maven • Git, GitFlow • Sonar • Jenkins • Machine Learning & Data Science Toolkit: Python, Tableau, Libraries such as scikit-learn, pandas, NumPy, TensorFlow, Hadoop, Spark und Flink) Wer jetzt sagt, das könnte was für mich sein, schaut am besten auf der ING Deutschland Karrierehomepage nach den genauen Jobs und bewirbt sich. www.ing.jobs/Deutschland

Das Ende ist nah! Am 14. Januar kommen die letzten Updates für Windows 7. Warum es eine schlechte Idee ist das alte Betriebssystem weiterhin zu nutzen, weiß Jan Schüssler. Ein Klassiker in der c't ist der große TV-Test zum Jahresende. Unsere Bildschirmexpertin Ulrike Kuhlmann hat sich Geräte ab 390 € angeschaut und kann sagen, worauf es beim Fernseherkauf zu achten gilt. Es ist öde in der Landschaft der Handybetriebssysteme, denn Android und iOS dominieren den Markt. Keywan Tonekaboni hat das Duopol verlassen und die Alternative Sailfish mitgebracht. Bitte nehmt an unserer großen c't-uplink-Umfrage teil und helft uns, c't uplink besser zu machen. Außerdem könnt ihr darüber bei unserer großen Prediction-Folge zum Jahresende mitmachen und uns eure Vorhersagen fürs nächste Jahr mitteilen: ct.de/uplink-umfrage === Anzeige / Sponsorenhinweis === Die ING ist zwar eine Bank aber bei denen dreht sich alles um digitale Anwendungen, die immer weiter entwickelt werden. Gesucht werden Leute für Frankfurt und Nürnberg, die richtig Lust auf ihren Job haben, die mit eigenen Ideen an den Start gehen, die sie dann im Team zusammen umsetzen. Untypisch für eine Bank, aber es läuft bereits alles agile. Ein bisschen Frustrationstoleranz braucht es – zugegeben - auch. Ist halt ein internationales Unternehmen, da geht nicht alles von heute auf morgen. Dafür gibt es aber faire Bezahlung, jede Menge Zusatzleistungen, 30 Tage Urlaub, Zuschüsse für Kinder- und Familienbetreuung, Gesundheit, Rente und vieles mehr. Und Möglichkeiten, sich in jede Richtung weiterzuentwickeln. Ein paar Skills muss man mitbringen: Gesucht werden Spezialisten. Aktuell vor allem • Java Entwickler (Frontend, Backend, Full-Stack und Entwickler mit Fokus Microservices) • DWH Entwickler, ETL Spezialisten • Applikationsbetreuer • Testmanager z.B. Last- & Performancetests • Machine Learning Engineers • Data Scientists • Spezialisten im Bereich IT Infrastruktur (Cloud-Engineer, Business Analysten, Netzwerk Spezialisten, IT Support Die ING arbeitet mit Skills/Tech Stack • Datenbanken Know-how (SQL, PL/SQL, ORACLE, IBM DataStage) • Java, JEE Middleware (Spring, Hibernate), J2EE, Microservices • Jbos • Workflowmanagement z. B. Automic/UC4 • Java mit Focus • Applikationsbetreuung auf Linux- und Windows Umgebungen • ITIL oder ITSM Erfahrung • Patch/Lifecycle/Securitymanagement • Maven • Git, GitFlow • Sonar • Jenkins • Machine Learning & Data Science Toolkit: Python, Tableau, Libraries such as scikit-learn, pandas, NumPy, TensorFlow, Hadoop, Spark und Flink) Wer jetzt sagt, das könnte was für mich sein, schaut am besten auf der ING Deutschland Karrierehomepage nach den genauen Jobs und bewirbt sich. www.ing.jobs/Deutschland

Das Ende ist nah! Am 14. Januar kommen die letzten Updates für Windows 7. Warum es eine schlechte Idee ist das alte Betriebssystem weiterhin zu nutzen, weiß Jan Schüssler. Ein Klassiker in der c't ist der große TV-Test zum Jahresende. Unsere Bildschirmexpertin Ulrike Kuhlmann hat sich Geräte ab 390 € angeschaut und kann sagen, worauf es beim Fernseherkauf zu achten gilt. Es ist öde in der Landschaft der Handybetriebssysteme, denn Android und iOS dominieren den Markt. Keywan Tonekaboni hat das Duopol verlassen und die Alternative Sailfish mitgebracht. Bitte nehmt an unserer großen c't-uplink-Umfrage teil und helft uns, c't uplink besser zu machen. Außerdem könnt ihr darüber bei unserer großen Prediction-Folge zum Jahresende mitmachen und uns eure Vorhersagen fürs nächste Jahr mitteilen: ct.de/uplink-umfrage === Anzeige / Sponsorenhinweis === Die ING ist zwar eine Bank aber bei denen dreht sich alles um digitale Anwendungen, die immer weiter entwickelt werden. Gesucht werden Leute für Frankfurt und Nürnberg, die richtig Lust auf ihren Job haben, die mit eigenen Ideen an den Start gehen, die sie dann im Team zusammen umsetzen. Untypisch für eine Bank, aber es läuft bereits alles agile. Ein bisschen Frustrationstoleranz braucht es – zugegeben - auch. Ist halt ein internationales Unternehmen, da geht nicht alles von heute auf morgen. Dafür gibt es aber faire Bezahlung, jede Menge Zusatzleistungen, 30 Tage Urlaub, Zuschüsse für Kinder- und Familienbetreuung, Gesundheit, Rente und vieles mehr. Und Möglichkeiten, sich in jede Richtung weiterzuentwickeln. Ein paar Skills muss man mitbringen: Gesucht werden Spezialisten. Aktuell vor allem • Java Entwickler (Frontend, Backend, Full-Stack und Entwickler mit Fokus Microservices) • DWH Entwickler, ETL Spezialisten • Applikationsbetreuer • Testmanager z.B. Last- & Performancetests • Machine Learning Engineers • Data Scientists • Spezialisten im Bereich IT Infrastruktur (Cloud-Engineer, Business Analysten, Netzwerk Spezialisten, IT Support Die ING arbeitet mit Skills/Tech Stack • Datenbanken Know-how (SQL, PL/SQL, ORACLE, IBM DataStage) • Java, JEE Middleware (Spring, Hibernate), J2EE, Microservices • Jbos • Workflowmanagement z. B. Automic/UC4 • Java mit Focus • Applikationsbetreuung auf Linux- und Windows Umgebungen • ITIL oder ITSM Erfahrung • Patch/Lifecycle/Securitymanagement • Maven • Git, GitFlow • Sonar • Jenkins • Machine Learning & Data Science Toolkit: Python, Tableau, Libraries such as scikit-learn, pandas, NumPy, TensorFlow, Hadoop, Spark und Flink) Wer jetzt sagt, das könnte was für mich sein, schaut am besten auf der ING Deutschland Karrierehomepage nach den genauen Jobs und bewirbt sich. www.ing.jobs/Deutschland

In this episode of My JavaScript Story is Charles talks to Eduardo San Martin Morote. Eduardo is a freelance developer, a core team member of Vue.js, and loves contributing to open source. Eduardo started web development with games. He then majored in Computer Science and Mathematics. Eduardo works as a freelancer so he can work on Open Source projects in his free time. One of the problems he draws attention to is the sustainability of Open Source Projects. The developers that maintain the projects on Open Source are not funded, and even though many companies use Open Source code they don't have sponsor it even though they have the financial means to do so. Charles Max Wood recommends another podcast Devchat.tv hosts, Sustain Our Software that addresses this problem among others for Open Source. Eduardo and Charles talk about characters that have accents that have to be encoded and how they deal with this problem. Eduardo then talks about some of the projects he is working on currently with Vue.js. Sponsors Sentry use the code “devchat” for 2 months free on Sentry small plan Adventures in Blockchain Adventures in DevOps CacheFly Host: Charles Max Wood Joined by Special Guest: Eduardo San Martin Morote Links VoV 038: Webassembly and Typescript with Eduardo San Martin Morote VoV 010: “Vue Libraries, Open Source, Meetups” with Eduardo San Martin Morote Eduardo's LİnkedIn Eduardo's Twitter J2EE jQuery Picks Eduardo San Martin Morote Tajin Eduardo's GitHub Charles Max Wood Subscribers Subscribe to your favorite podcast on Devchat.tv https://canny.io Suggest a Topic or a Guest for your Favorite Podcast on Devchat.tv by clicking on Suggest A Topic Or Guest

In this episode of My JavaScript Story is Charles talks to Eduardo San Martin Morote. Eduardo is a freelance developer, a core team member of Vue.js, and loves contributing to open source. Eduardo started web development with games. He then majored in Computer Science and Mathematics. Eduardo works as a freelancer so he can work on Open Source projects in his free time. One of the problems he draws attention to is the sustainability of Open Source Projects. The developers that maintain the projects on Open Source are not funded, and even though many companies use Open Source code they don't have sponsor it even though they have the financial means to do so. Charles Max Wood recommends another podcast Devchat.tv hosts, Sustain Our Software that addresses this problem among others for Open Source. Eduardo and Charles talk about characters that have accents that have to be encoded and how they deal with this problem. Eduardo then talks about some of the projects he is working on currently with Vue.js. Sponsors Sentry use the code “devchat” for 2 months free on Sentry small plan Adventures in Blockchain Adventures in DevOps CacheFly Host: Charles Max Wood Joined by Special Guest: Eduardo San Martin Morote Links VoV 038: Webassembly and Typescript with Eduardo San Martin Morote VoV 010: “Vue Libraries, Open Source, Meetups” with Eduardo San Martin Morote Eduardo's LİnkedIn Eduardo's Twitter J2EE jQuery Picks Eduardo San Martin Morote Tajin Eduardo's GitHub Charles Max Wood Subscribers Subscribe to your favorite podcast on Devchat.tv https://canny.io Suggest a Topic or a Guest for your Favorite Podcast on Devchat.tv by clicking on Suggest A Topic Or Guest

In this episode of My JavaScript Story is Charles talks to Eduardo San Martin Morote. Eduardo is a freelance developer, a core team member of Vue.js, and loves contributing to open source. Eduardo started web development with games. He then majored in Computer Science and Mathematics. Eduardo works as a freelancer so he can work on Open Source projects in his free time. One of the problems he draws attention to is the sustainability of Open Source Projects. The developers that maintain the projects on Open Source are not funded, and even though many companies use Open Source code they don't have sponsor it even though they have the financial means to do so. Charles Max Wood recommends another podcast Devchat.tv hosts, Sustain Our Software that addresses this problem among others for Open Source. Eduardo and Charles talk about characters that have accents that have to be encoded and how they deal with this problem. Eduardo then talks about some of the projects he is working on currently with Vue.js. Sponsors Sentry use the code “devchat” for 2 months free on Sentry small plan Adventures in Blockchain Adventures in DevOps CacheFly Host: Charles Max Wood Joined by Special Guest: Eduardo San Martin Morote Links VoV 038: Webassembly and Typescript with Eduardo San Martin Morote VoV 010: “Vue Libraries, Open Source, Meetups” with Eduardo San Martin Morote Eduardo's LİnkedIn Eduardo's Twitter J2EE jQuery Picks Eduardo San Martin Morote Tajin Eduardo's GitHub Charles Max Wood Subscribers Subscribe to your favorite podcast on Devchat.tv https://canny.io Suggest a Topic or a Guest for your Favorite Podcast on Devchat.tv by clicking on Suggest A Topic Or Guest

An airhacks.fm conversation with Dmitry Kornilov (@m0mus) about: Programming mother and Basic "print", pl 1 on mainframes, enjoying the creativity of programming, developing Tetris with 12, enjoying one of the first XT PCs in Russia in 1985, using pupil testing applications at school, enjoying the power of the key to the computer room, using the Russian computer: BK-0010, using Pascal at high school and Delphi in leisure, clipper, Delphi was unbeatable at that time, Delphi is still supported by Embarcadero, Borland Delphi started in 1995, Turbo Vision the library for creation of DOS-based UI, studying applied mathematics at the aviation university, building a F-19 Stealth Fighter simulator at the Aviation University in C/C++, by solving 9 to 11 differential equations you could simulate an airplane, creating a graphic library to draw primitives in assembler to improve performance, building automation systems for resorts in Czech Republic in ASP.net and C#, creating a casino application as PoC in J2EE, Linux and WebLogic Server 7, Tetris as Applets, enjoying JBuilder IDE, starting with EJB 1.0, Bean Managed Persistence (BMP) later Container Manager Persistence (CMP), working as freelancer in J2EE space, starting at Oracle at EclipseLink team and creating the second version of JPA-RS, starting with JSON-B and yasson, JSON-B was created by a team of 2 developers, the JakartaONE livestream, session: "JSON support in Jakarta EE: Present and Future", the AirPort, Prime and Helidon, Helidon got MicroProfile, Airport started around 2015, Helidon had a great potential what was recognized by management, Helidon supports Java SE and MicroProfile programming models, Oracle had no viable strategy for WLS customers which wanted to try something else - Helidon fills the gap, J4C - Java For Clouds was the name of the runtime before Helidon, Helidon is the name of a small and fast bird: the swallow, the helidon.io website was created by Oracle's webdesigners, Helidon Java SE is targetted for developers who are bored by Java EE programming model, fat jars don't make any sense, Helidon is a hollow-JAR and so can be deployed as layered Docker image, Dmitry Kornilov on twitter: @m0mus. Dmitry's blog: https://dmitrykornilov.net

Renaming to align with kunernetes and JEDI master Trump. Buy Coté’s book dirt cheap (https://leanpub.com/digitalwtf/c/sdt)! And check out his other book that this guy likes (https://www.linkedin.com/feed/update/urn:li:activity:6559881947412340736/). Mood board: Have either of you ever eaten dog meat? He easily slides into meataterian. Skype would be terrible if it weren’t so great! Follow the foot-stones Going up the well I like dogs, what I don’t like is additional responsibility. My life is mostly avoiding more responsibility Sorry about your dog… Oyster and Opals. Dogs and trains Once you get to Atlanta, trains be like, fuck that shit. I’m going to write that down and look at it when I’m depressed. Who put kubernetes in my Mesosphere? Not investment advice. 2 to 3 yards of J2EE books. If you put it into a container, you’ll probably be OK. Relevant to your interests Mesosphere changes name to D2IQ, shifts focus to Kubernetes, cloud native (https://techcrunch.com/2019/08/05/mesosphere-changes-name-to-d2iq-shifts-focus-to-kubernetes-cloud-native/) IBM fuses its software with Red Hat’s to launch hybrid-cloud juggernaut (https://www.networkworld.com/article/3429596/ibm-fuses-its-software-with-red-hats-to-launch-hybrid-cloud-juggernaut.html#tk.rss_all) After Trump cites Amazon concerns, Pentagon reexamines $10 billion JEDI cloud contract process (https://www.washingtonpost.com/business/2019/08/01/after-trump-cites-amazon-concerns-pentagon-re-examines-billion-jedi-cloud-contract-process/) Your multicloud strategy is all wrong (https://www.infoworld.com/article/3428682/your-multicloud-strategy-is-all-wrong.html) A Technical Analysis of the Capital One Hack (https://blog.cloudsploit.com/a-technical-analysis-of-the-capital-one-hack-a9b43d7c8aea?gi=85e88964a741) Dynatrace S-1 Analysis — Tracing a Transition (https://medium.com/memory-leak/dynatrace-s-1-analysis-tracing-a-transition-3c92896e8d29) NetApp Stock Is Tumbling After the Company Warned That Tech Spending Was Slowing (https://www.barrons.com/articles/netapp-stock-tumbles-after-warning-of-slowing-tech-spending-51564761782) Will Uber ever make money? Day of reckoning looms for ride-sharing firm (https://www.theguardian.com/technology/2019/aug/04/uber-ride-share-lyft-ipo-earnings) It’s the end of the big-data era: HPE to acquire MapR’s assets (https://siliconangle.com/2019/08/05/end-big-data-era-hpe-acquire-maprs-assets/) Microsoft launches Azure Security Lab, expands bug bounty rewards (https://www.zdnet.com/article/microsoft-announces-azure-security-lab-azure-bug-bounty-expansion/) Nonsense Alabama teen wins PowerPoint World Championship (https://www.al.com/news/huntsville/2019/08/alabama-teen-wins-powerpoint-world-championship.html) Airlines are finally fixing the middle seat (https://www.fastcompany.com/90377949/airlines-are-finally-fixing-the-middle-seat) Why is called an Oyster Card? (https://en.wikipedia.org/wiki/Oyster_card) Sponsors SolarWinds Papertrail (https://papertrailapp.com/?utm_source=podcast&utm_medium=direct-link&utm_campaign=sdt) TrackJS (https://trackjs.com/sdt/) Conferences, et. al. August 12th to 15th - Cloudbees DevOps World and Jenkins World (https://www.cloudbees.com/devops-world/san-francisco), San Francisco - use the code GOLOCAL for a discount. Also in Lisbon, Dec 3rd to 5th (https://www.cloudbees.com/devops-world/lisbon). August 30th - Agile Scotland, Glasgow (https://www.agilescotland.com/august) - Coté giving 90 minute workshop (https://www.agilescotland.com/august#comp-jwjlafj0__item1inlineContent-gridWrapper). Use the code AS-SPEAKER-MICHAEL for a discount: from £70 to £56.13. Sep 26th to 27th - DevOpsDays London (https://devopsdays.org/events/2019-london/welcome/) - Coté at the Pivotal table, come get free shit. Oct 7th to 10th - SpringOne Platform, Oct 7th to 10th, Austin Texas (https://springoneplatform.io/) - get $200 off registration before August 20th, and $200 more if you use the code S1P200_Coté (make sure to use the accented e). Come to the EMEA party (https://connect.pivotal.io/EMEA-Cocktail-Reception-S1P-2019.html) if you’re in EMEA. Oct 9th to 10th - Cloud Expo Asia (https://www.cloudexpoasia.com/) Singapore, Oct 9th and 10th Oct 10th to 11th - DevOpsDays Sydney 2019 (http://devopsdays.org/events/2019-sydney/), October 10th and 11th December - 2019, a city near you: The 2019 SpringOne Tours are posted (http://springonetour.io/): Toronto Dec 2nd and 3rd (https://springonetour.io/2019/toronto), São Paulo Dec 11th and 12th (https://springonetour.io/2019/sao-paulo). December 12-13 2019 - Kubernetes Summit Sydney (https://events.linuxfoundation.org/events/kubernetes-summit-sydney-2019/) SDT news & hype Join us in Slack (http://www.softwaredefinedtalk.com/slack). Send your postal address to stickers@softwaredefinedtalk.com (mailto:stickers@softwaredefinedtalk.com) and we will send you free laptop stickers! Follow us on Twitter (https://twitter.com/softwaredeftalk), Instagram (https://www.instagram.com/softwaredefinedtalk/) or LinkedIn (https://www.linkedin.com/company/software-defined-talk/) Listen to the Software Defined Interviews Podcast (https://www.softwaredefinedinterviews.com/). Check out the back catalog (http://cote.coffee/howtotech/). Brandon built the Quick Concall iPhone App (https://itunes.apple.com/us/app/quick-concall/id1399948033?mt=8) and he wants you to buy it for $0.99. Use the code SDT to get $20 off Coté’s book, (https://leanpub.com/digitalwtf/c/sdt) Digital WTF (https://leanpub.com/digitalwtf/c/sdt), so $5 total. Recommendations Brandon: Hard Knocks (https://www.hbo.com/hard-knocks) and Last Chance U (https://www.netflix.com/title/80091742). Matt: Tim Hecker: An Imaginary Country (https://www.youtube.com/watch?v=HuXxwXWPz2Y). Coté: Slouching Towards Bethlehem (https://www.goodreads.com/book/show/424.Slouching_Towards_Bethlehem), Joan Didion. Outro: “Depreston,” (http://youtube.com/watch?v=1NVOawOXxSA) Courtney Barnett.

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

An airhacks.fm conversation with Mark Little (@nmcl) about: the 250 miles terminal connection, Commodore PET, battle ships on paper tapes, mocking the login screen on Commodore, reverse engineering Space Invaders, the lack of games in UK was a motivation for writing games, learning peek and pokes, Commodore engineering team wrote a book about machine code, Basic on BBC model B, Pascal and C on EPROMs, building a hotel booking system on Pascal, building a pseudo operating system with C, Concurrent Pascal, Cfront - the early version of C++, Atari ST came with C support, C++ over Concurrent Euclid, working with Andy Tannenbaum and Bjorne Stroustroup on Minix, porting Minix to Atari ST, Arjuna the Indian god, Indian Gods over Celtics, Arjuna -- the object oriented transaction system, started in 1985, inheriting transactions, transactions are not about HA, transactions are about recoverability, starting Java as Oak, the shiny object syndrome and transition to Java, writing web browsers in Java, porting Arjuna to Java with Blackdown Java, Jim Waldo and Note on Distributed Computing, opaque over transparent, Johan Vos was a member of the Blackdown team, RPC with C++ and Arjuna, almost serverless, packing and unpacking instances and the Lock Manager, 2PC was the default, without X/Open XA heuristics the system would block forever, XA heuristics were introduced to make independent decisions, enforcing consistency in microservices with 2PC/XA is hard, SOA and microservices come with similar challenges, there is no a single transaction model applicable for every single use case, XA/2PC is lesser suited for long running actions, transactions were out-of-fashion - now they are back, Google Spanner is transactional, Arjuna was acquired by Bluestone, Arjuna Technologies was acquired by HP, JBoss did a partial acquisition of Arjuna, before the Arjuna acquisition, JBoss couldn't handle 2PC properly, Bluestone became the HP application server, JBoss was always opensource and good quality code, J2EE came before annotations - metadata was attached with partially redundant XML, Mark became RedHat CTO in 2009, MicroProfile is great and there is a lot of interests in evolving Java into clouds by the community, Jakarta EE was a great move by Oracle in 2017, Jakarta EE has to move faster, Jakarta EE is more like the stable OS, MicroProfile is where the innovation happens, there are no more monolithic application server, what does "enterprise" mean?, QuarkEE is opinionated Quarkus, Mark Little on twitter: @nmcl, Mark's blog

An airhacks.fm conversation with Gunnar Morling (@gunnarmorling) about: Eastern computers and Robotron KC 85, CPU slicing, screensaver as source code, Hello World in Pascal with 14, University in Dresden, AMD and Java 1.2 with Forte for Java, starting at Saxonia Systems as consultant, having fun in a Java EE 5 course, the EJB 3 and Guice blog post, the effect of a link, Java EE 5, the "dinsoaur version" was productive although you had to write interfaces, early EJB and J2EE were bloated, but it was 15 years ago, working at Otto the German "amazon" and Kuehne and Nagel, just use the most productive stack you can get, what does "modern" actually mean?, applying quantum computing to CRUD, it was hard to find a killer use case for WildFly Swarm, quarkus is a Java EE + MicroProfile subset with useful features, FatJars do not make any sense in a layered file system, bare metal infrastructure is the killer feature of UberJars and FatJARs, Heavyweight vs. Lightweight JavaONE session, quarkus native image is a fraction of JVM size, the "compile time boot", performing optimizations at build and not at boot time, with quarkus CDI performance might be as good as EJBs, deployment descriptors are only needed at build time, boring programming model with optimizations under the hood is true innovation, MicroProfile FaultTolerance combines easy programming model with Hystrix's capabilities, don't re-invent the wheel, BeanValidation's in XML-configuration is not supported in quarkus native mode, QuarkEE release, using quarkus for web development, validating design and architecture with deptective, deptective enforces the rules at compile time, deptective is a plugin of javac compiler, javadoc may cause package cycles, measuring packge coupling and cohesion, jacoco as code coverage plugin for quarkus, debezium detects changes and passes the events to Apache Kafka, debezium uses DB APIs, logical decoding in PostgreSQL, debezium receives updates even it the application is not running, listening on the transactional log of the database. Gunnar on twitter: @gunnarmorling and github: https://github.com/gunnarmorling. Gunnar's blog: https://morling.dev/.

An airhacks.fm conversation with Mark Struberg (@struberg) about: rubber-keyed ZX81, C64, Basic, tons of incorrect rows of hexcode, transitioning from Basic to assembly, games were an inspiration, 40mins to load the game, Turbo Copy for software refreshment, transitioning from software to solding transistors, flip-flops with 10 years, programming Logo with Atari ST, HTL in Austria, Pascal on 286 Commodore PC 20 with monochrome computer, host programming on Digital Equipment PDP 8e, Sun's pizza boxes, drinkomat the drink (also vodka) portioning machine, replacing 2 PCs with one microcontroller, the first 3D printer, testing insulin pumps, learning C++ with Glockenspiel C++ compiler, starting with Java 1.0.2, building stock exchange software with Java, brilliant Martin Poeschl, Maven 1 and Cocoon, JRun was servlet-like engine, Borland JBuilder, building platforms for Austrian insurance market platform in 1999, Lutris Enhydra application server, Tomcat was donated by Sun to Apache, never control program flow with exceptions, Jigsaw - Apache servlet engine, XMLc was a built-step in Ant, DOM manipulation in Java on the server, defining data structure in XML and generating the DAOs, enhydra was Canadian then donated to ow2, Windows and OS2 programming, C# came 2002, first EJB-drafts were nightmare, EJB could be implemented better with Objective-C Portable Distributed Objects from NeXT, EJB was a huge buzz topic pushed by Microsoft's DCOM, MTS was almost like EJB, DCOM came before EJB, MTS came after EJB, "remote first" was wrong, macroservices are more appealing for enterprise, delivering in 2004 25 TB of music (and Jamba ringtones) to 16 million customers and with Servlets and Resin from Caucho, hardcore threads were native, Mark worked as freelancer, a few big Sun Enterprise 400 with MySQL without transactions, optimizing for read only, projects under fire, the challenging part in the backend were contracts and payment, switching logic with re-deployment with Groovy, switching from Spring to CDI, refactoring PHP to Java in 5 years, Seam 2 didn't had the future, serving 5 millions impressions / 12k requests per minute in the first day with 1-month old Java EE 6, Glassfish is rubbish, Payara is great, Payara delivers patches incredibly fast, Java EE community is really nice, the real benefit of opensource is sharing costs, experience, maintenance, testing costs and fork prevention, JPA is too much magic but you get tons of answers for free, three category of projects: perfect, problematic and completely broken, the javax namespace issue, javax became immutable, Geronimo app server is dead, the Geronimo contains Java EE API specs, one-shot migration to jakarta namespace is not that hard, migrate once, but do it right, javax migration is a lorge task for vendors but a small issue for business, developers are still thinking is "J2EE", Eclipse is too protective and should open to other foundations and communities Mark on twitter: https://twitter.com/struberg and github: https://github.com/struberg. Mark's blog: https://struberg.wordpress.com/.

1. Adif saca una licitación de 6 millones de euros para implementar el BIM Pliego administrativo Adif Pliego técnico Adif Primera gran implementación BIM pública en España. 5.986.220,90€ (4.947.290€ sin IVA)3 años de implementación. Requisitos para participar bastante altos Solvencia financiera Facturación anual de 2 millones de euros.Facturación anual de 742.000€ en servicios de consultoría, implementación, formación, gestión y/o coordinación BIM. Solvencia técnica Contar con oficinas en el área metropolitana de Madrid.Una dotación de cómo mínimo, 23 personas con distintos perfiles técnicos relacionados con el sector ferroviario (12) y con el BIM (11). Perfiles BIM:2 Asesores expertos en implementaciones BIM, con más de 5 años de experiencia. 1 Asesor experto en consultoría BIM, con más de 5 años de experiencia. 2 Técnicos Superiores Ingenieros Informáticos con 5 años de experiencia y conocimientos en herramientas EAM, GIS, cuadros de precios y entornos J2EE, herramientas BIM, proyectos relacionados con la implantación, integración y desarrollo de interfaz entre herramientas BIM y sistemas EAM, GIS, cuadros de precios. 5 Técnicos Superiores con la titulación idónea y 5 años de experiencia en trabajos de consultoría en BIM (Arquitectura, Estructuras, Instalaciones e Infraestructura y Obra Civil) e implementación BIM.1 Delineante con 5 años de experiencia en software BIM, diseño y maquetación. Valoración de la oferta Muy interesante: dos propuestas de adecuación a la metodología BIM de dos pliegos existentes (Lorca y Santiago de Compostela). 10 puntos.Plan de formación (cursos cortos). 10 puntos.Propuesta de implementación BIM. 25 puntos.Propuesta de necesidades TIC. 4 puntos.Baja en la oferta económica. 41 puntosEquipo humano. 7 puntos.Experiencia. 3 puntos. Opinión No sé si en España hay una empresa que cumpla todos los requisitos, lo más probable es que se formen UTE.Una empresa grande no puede "pasarse al BIM" todos a la vez, y menos en 3 años.Yo habría hecho las cosas diferente, pero no digo más porque nos vamos a presentar. Cuando acabe la licitación, ganemos o perdamos, contaré como lo enfocaría yo. 2. Metrovacesa se lanza al BIM junto con 55 estudios de arquitectura Nota de prensa de Metrovacesa Es la promotora inmobiliaria más grande de España (junto con Neinor Homes y AEDAS Homes).Gran efecto radial (Middle-Out que dirían los ingleses).Las promotoras como Neinor Homes, Aelca, Vía Célere, InSur, son las que están consiguiendo que los estudios pequeños se metan en BIM.Desde que Inditex empezó a trabajar con BIM360, ha habido una oleada de pequeñas empresas que lo están usando también. 3. Dynamo llega a FormIt, Advance Steel y Civil 3D Novedades de Formit 17Dynamo para Advance SteelDynamo estará disponible en Civil 3D 2020Ahora los usuarios de dynamo pasan a tener super poderes en casi todos los software BIM Autodesk. Faltan sólo Infraworks y Plant 3D, pero todo se andará. ¿Qué es FormIt? FormIt es como sketchup pero: Está en versión online y para ipad (además de windows).Es compatible de forma nativa con las masas de Revit.Tiene análisis solar.La versión de pago permite trabajo colaborativo en tiempo real.Ahora es compatible con Dynamo. 4. Cost-It permite usar parámetros personalizados para el código de la partida. Novedades Cost-It 2019.01 Hasta ahora había que usar Código de montaje o Nota clave.Ahora en la configuración de exportación podemos escribir el nombre del parámetro que queremos usar. ¿Quieres que responda a tus preguntas en el podcast? Envíamelas en la sección de contactar. ¿Quieres escuchar otro episodio? Los tienes todos en la sección de Podcast de esta web.

Today on The InfoQ Podcast, Wes talks with Rod Johnson. Rod is famously responsible for the creation of the Spring Framework. The two talk about the early years of the framework and provides some of the history of its creation. After discussing Spring, Wes and Rod discuss languages he’s been involved with since Java (these include Scala and TypeScript). He talks a bit about what he liked (and didn’t like) about each. Finally, the two wrap by discussing Atomist and how they’re trying to change the idea of software delivery from a statically defined pipeline (located in individual repositories) to an event hub that drives a series of actions for software delivery. He describes this as creating an API for your software. Why listen to this podcast: - The initial origins of the Spring Framework really came about through a process of trying to write a really great book about J2EE in 2002. It was through that process that Rod Johnson found he felt there was a better way and ultimately lead to the creation of the Spring Framework. - What started as examples and references, became the Spring Framework. By 2005 there were about 2 million downloads of the Spring Framework. After leaving VMWare in 2013, Rod spent several years working with Scala. One of the elegant features that really attracted Rod to Scala was how everything is an expression. One of the things he didn’t like was an affinity to overly complex approaches to problem solving. - Today at Atomist, Rod does a lot of work in Node. He really enjoys the robust extra layer of typing over a dynamic language and the ability to escape to JavaScript if needed (similar to escaping types with reflection in Java found in the internals of the Spring Framework). - Atomist, the company he founded after leaving VMWare, is rethinking CI/CD from a static pipeline defined in every repository to an event-driven system that defines how to respond to specific events (such as a push from Git). For example, all pushes with Spring Boot can be configured to be scanned with SonarQube or because a push has kubespec it might get deployed to a K8 cluster. He describes this as creating an API for your software. - One of the reasons Atomist integrates so tightly with Slack (and other similar messaging platforms) is because it allows developers to shape their own relevant messages. By joining (or leaving channels), people are able to subscribe to only the information they actually want. Meeting developers inside Slack is an important interface for Atomist. More on this: Quick scan our curated show notes on InfoQ https://bit.ly/2FxK3xf You can also subscribe to the InfoQ newsletter to receive weekly updates on the hottest topics from professional software development. bit.ly/24x3IVq Subscribe: www.youtube.com/infoq Like InfoQ on Facebook: bit.ly/2jmlyG8 Follow on Twitter: twitter.com/InfoQ Follow on LinkedIn: www.linkedin.com/company/infoq Check the landing page on InfoQ: https://bit.ly/2FxK3xf

An airhacks.fm conversation with Ondrej Mihályi about: starting programming with Logo, Pascal, C, Pentium 386, Scratch, minecraft, delphi and Java, pointers and destructors, participating in programming competitions, learning programming with Java, GWT, JSF and Primefaces over GWT, Eclipse, NetBeans, Java EE 5 introduced Dependency Injection (DI), Nitra is the oldest City in Slovakia, "Enterprise needs to be complicated", code generation with xdoclet in J2EE, simplifications with Java EE 5 in 2006, starting at Payara, running a JUG in Prague, Sun Grid Engine, serverless WARs, ideas for productive Clouds 2.0, serverless Java EE applications, early clouds with Google App Engine, Docker and Kubernetes for application packaging, making cloud services injectable, AWS lambdas are distributed commands, improving developer experience in the clouds with DI instead of singletons, Payara Source To Image (S2I) for server configuration in the clouds, separating the immutable servers from application logic with docker and clouds, cloud vendors are evaluating microprofile, repeatable and reproducible builds with Java EE in private clouds, Java EE deployment model became accidentally "cloud ready", with ThinWARs there is nothing to (security) scan, with ThinWARs there is no conceptual difference to lambda functions, cloud vendors participation in Jakarta EE, Payara is evaluating GraalVM and native compilation. Ondro's blog and @OndroMih / twitter.

GUEST BIO: Adam Bien is a freelance architect and developer with a focus on Java.  He has written several books including “Real World Java EE Patterns – Rethinking Best Practices”.  Adam is also a Java Champion and was Java Developer of the Year in 2010.  He is also a regular conference speaker and three times a year he organizes Java related workshops at Munich Airport. EPISODE DESCRIPTION: Phil’s guest on today’s show is Adam Bien. Having worked with JDK 1.0, EJB, JavaFX, J2EE, and Java EE from launch onwards he has a phenomenal understanding of the language. He knows Java inside out and is a leader in the field. Adam regularly shares his knowledge by organizing workshops, speaking at conferences as well as writing books, articles and updating his blog. KEY TAKEAWAYS: (1.06) – So Adam, can you expand on that brief introduction and tell us a little bit more about yourself? Adam said that originally he wanted to learn multiple programming languages, work a bit and enjoy life. However, things did not work out that way. The demand was so high that he ended up sticking with Java. Even after 22 years, he still enjoys working with this language. (1.55) – Phil asks if he has plans to switch to a different technology or will he stick to Java.  Adam says with Java, it is impossible to learn everything. He just keeps diving deeper. But, he is also doing a lot with JavaScript. He jokes that to learn both Java and JavaScript you would need at least two lives. (2.29) – Phil asks Adam for a unique IT career tip. Adam advises everyone to develop their own strategy. Not anything huge like - “I would like to take over the world, in 10 years time.” It has to be something logical. For example Adam has been working to make development simple for the clients he works with. He uses standards, which makes it possible for his clients to use other consultants. Adam has found that his clients really like this approach. It is one of the reasons they like working with him. (3.30) – Phil asks when you talk about standards are you thinking of different ways of working and models as well as industry standards? Yes, says Adam. The availability of Java’s quasi-standards like JCB Java community process, Java EE and Java SE are partly behind the language’s longevity. While lots of other technologies and frameworks have come and gone, Java has remained in use and popular. Sticking with the standard means users can stay up to date using just incremental learning. Building on what they already know to learn to use the new Java innovations. There is no paradigm change needed. Understandably, clients like that because having to migrate to new technologies is always hard and bad for business. (4.33) – Adam is asked to share his worst career moment and what he learned from it. Adam says that surprisingly he has not had any really bad career experiences. He did have one funny experience though. During the rollout of Java 6 or 7 he was due to speak about it at two Sun Microsystems locations, on two different dates. Somehow the dates got muddled up. So, Adam ended up in the wrong city on the first date, which was a funny rather than bad career moment. Although, Adam did say that when his server goes down things can get a bit crazy. Everything is on there, including his website, so he gets hundreds of emails asking him if he realizes he is no longer on the internet. (5.58) – Phil asks Adam what his best career moment was. Adam runs something called Taskforces. For example, if a system dies in production and the issue cannot be resolved, Adam pulls together the relevant people to get things up and going again. During that process there is the often the chance to spring clean the system and make it stronger than it was before. It is a rare opportunity. If a system is running you would never dare to refactor it and rebuild it from the ground up. When a system is broken, you can do so. After all, you cannot make it much worse. (7.02) – Phil asks Adam what excites him about the future of the IT industry and IT careers. Adam says that the fact that there is always something new to learn excites him. He also finds it interesting how technologies cycle. Adam has spotted the fact that “everything repeats every 10 years.” This pattern means that provided you do not forget things you are always ahead of the game. For example, JavaScript is becoming more and more like Java. So, now because Adam knows Java really well switching between it and JavaScript is actually very easy for him. He also enjoys the fact that in IT when you teach someone you inevitably end up learning more yourself. (8.54) – What drew you to a career in IT? Adam is not 100% sure why he followed this career path. But, he has always been a fan of Sci-Fi and he saw computers as being related to that. For him computers have always been magical things. When he got his Spectrum computer you could not do much with it, but Adam became obsessed with making it do more. He became fascinated by it. (10.44) – What is the best career advice you have ever received? Adam starts by sharing something he has learned in his career, rather than a piece of advice he has been given. He says that if something interests him, he just learns it and does not worry about how he is going to use and apply that knowledge. Usually, he finds that a few months, sometimes years, down the line he needs what he has learned to move a project forward. So, his advice is to “learn to enjoy learning.” Adam has found that this Meta strategy leads to success. Adam also advises developers to learn presentation and political skills. You need to explain clearly why your technological solution is good for business. After all, your clients are really only interested in the outcome not the technology. (12.25) – If you were to start your IT career again, now, what would you do? Adam says personally he would not change much. (13.03) – What career objectives do you currently have? Adam says he wants to make sure that he will still be programming in his 90s. Something that he feels will be good for his brain. He is working to ensure that he does not get swallowed up by business matters so that he can continue to program regularly. (13.52) – What’s your number 1 non-technical skill? The one that has helped you the most in your IT career. Adam says he feels that it is important to stay healthy. (14.29) – Adam can you share a parting piece of career advice with the I.T. Energizer Audience?  Yes – “Stay interested and enjoy life by being productive.” Also, carry on learning and challenging yourself. This stops you from getting bored and it helps you to stay successful. Adam also says that you should try to keep things simple. Always minimize the amount of technology and code you use to solve a business problem. That way everyone can understand and maintain it. BEST MOMENTS: (2.06) ADAM – “If you try to learn JavaScript and Java I think you will need at least two lives.” (4.26) ADAM – “I stick with a standard. So I didn't have to learn a lot, do just incremental learning all the time.” (7.30) ADAM – “If I try to teach someone about what I learned, you learn even more.” (9.25) ADAM – “Everything else was boring. But a computer was something from another world.” (11.57) ADAM – “You should be able to explain in simple words, why what they are doing is good for the business. And not just from a technological perspective, because no client is interested in technology.” (14.59) ADAM – “The learning is the most exciting thing which will keep your successful.”   CONTACT ADAM BIEN: Twitter: https://twitter.com/AdamBien @AdamBien Website: http://adambien.blog/roller/abien/

An airhacks.fm conversation with@marcushellberg about: "Vaadin in Turku, simplifying with EJB 3 without layers, hacking JavaScript in browser, www.itmill.comwww.millstone.org and the history of vaadin, how Joonas started vaadin, the benefits of opensource, WebComponents with Vaadin Elements, Java generates WebComponents, Java is listening to WebComponents, melting frameworks, framework-less development with WebStandards, effectiveweb workshop easy to explain ServiceWorkers, higher level caching strategies with WorkBox, simple code first, Markus Code One Talk, lit-html is the missing piece, high performance with lit-html, lit-html outperforms virtual DOM, Angular is J2EE for the frontend, Angular's clunky module system predates ES 6 modules, future Angular versions could migrate away from the proprietary module system, possible breaking changes every 6 months, questionable DI in browser, less code with WebStandards, polyfills make your app leaner, WebStandards are moving forward, webworkers and webassembly, the lean WebStandard revolution, enterprise integration with WebComponents, Custom Elements Everywhere, Polymer's mission statement is to go away, polymer is the anti framework, npm is the remaining strange thing, the future of Vaadin, PWA for Java developers, upcoming WebStandards, and layered APIs, Vaadin Flow, and Vaadin Components, @marcushellberg, @vaadin"

Today's edition is special to us for a couple of reasons. One, thanks to your support, we have now crossed the 10,000 listeners mark. And two we are going to introduce a new section where we chat with industry influencers and practitioners to get their perspectives. In the first such interaction, we spoke to a die-hard Rajanikanth fan, someone, who never fails to deliver on his witty T-shirts and who aspires to see his city of Hyderabad grow into a creative, innovation minded tech startup city. . Our Guest, Ramesh Loganathan is a Professor Co-Innovation at IIIT Hyderabad, Chief Innovation Officer (interim) of TS State Innovation Cell who comes with 20 years of R&D and Product Development experience. He's been a President of the Hyderabad Software Enterprises Association, Regional Member NASSCOM and co-founded the Headstar network (StartupSaturday) and actively advises and promotes incubators.. He is a member of several Standards Experts groups including J2EE, regularly speaks at tech conferences and has recently co-authored a book on "SOA Approach to Integration" We'd recommend you also check-out his series of articles advising start-ups on http://startuphyderabad.com/author/ramesh/ Coming up next is our meeting this afternoon at his T-Hub office…

A conversation with Cameron Purdy, (@cpurdy) about: graphics programming, Wolfenstein, peek and pokes, programming in one sitting, structured programming and Pascal, no go sub, just go to, thoughts on Java, forming Tangosol in 2000, developers don't have budgets, J2EE scalability problems, TCMP, TCPM TCMP at XKCD, unlimited connections via UDP and early Java, Tangosol and Oracle coherence, distributed caching, learning on the job, dying servers, messaging and message order, blockchain and distributed caching, consistent caching, merkle tree, shrinking data domains, partition assignment strategies, partitioning and sharding, JINI and JavaSpaces, JGroups and Bela Ban, GigaSpaces, job scheduling, resource leasing, "Compound interest is the most powerful force in the universe" [Albert Einstein], survivor bias, usability optimizations, focus on application specific challenges, searching for exponential impact, having fun in team, attracting good engineers, daily improvements, the progress experience, avoid being noticed, fixing everything, the CAP truism, a different take on consistency, Java is not a concurrent language, there is no concept of "now", guaranteed order is the expensive part, consistency is the sideeffect of order, information is flowing, former Senior Vice President of Java Development still likes hacking, Cameron's new startup xqiz.it, @cpurdy.

Ron Huddleston, Chief Partner Officer at Twilio, joins the AppChat Podcast to discuss the importance of building out ecosystems and the differences he has seen building multiple ecosystems for various companies. Other subjects include breaking down various ecosystem models, how Huddleston's previous experience prepared him for working at Twilio, and the importance of trust and credibility in the industry. Here are the key topics, with timestamps, as well as the full interview transcript: Key Topics 00:00-01:58 Introducing the AppChat and our guest, Twilio's Chief Partner Officer Ron Huddleston 1:59-3:28 The challenges of indirect software sales 3:29-8:43 The importance of software companies building out an ISV and/or SI ecosystem 8:44-12:34 The differences in building out an ecosystem for Salesforce and Microsoft 12:35-17:10 The differences between a pure, cloud-based ecosystem, and a hybrid model including cloud and on-premise 17:11-20:02 How much Huddleston uses his previous experiences building ecosystems for Twilio, and how much he has to continue to discover and invent 20:03-25:54 The importance of trust and credibility when building out ecosystems 25:55-29:06 Building an app and sticking to the commitment you made to your ecosystem 29:07-30:22 Closing out and how to get in touch Full Transcript Intro: 00:01 You're listening to the AppChat, a podcast focused on SaaS growth strategies, plus successes in the Salesforce ecosystem, and beyond. Here's your host, CodeScience CEO, Brian Walsh. Brian Walsh: 00:14 All right. We're back on the AppChat Podcast. And today, I'm joined by Ron Huddleston, who, Ron, you have an incredible background when it comes to building out ISV ecosystems. Let me get this right. So you're currently the Chief Partner Officer at Twilio. Ron Huddleston: 00:31 Yeah. Brian Walsh: 00:32 Before that, CVP, One Commercial Partner organization at Microsoft. Ron Huddleston: 00:35 Yeah. Brian Walsh: 00:36 SVP of the AppExchange at Salesforce. Ron Huddleston: 00:38 Yep. Brian Walsh: 00:39 And started the OEM, ISV program at Oracle, where you were vice president. Ron Huddleston: 00:44 Yes. Brian Walsh: 00:45 Are there any bigger partner programs in the world to run than that? Ron Huddleston: 00:51 Amazon, maybe, now? Brian Walsh: 00:53 Maybe now, yeah. Ron Huddleston: 00:54 Yeah. Yeah, they're breaking new ground. But the Microsoft thing was definitely a big one. They've all been really fun. I do think that the folks at companies that get to build ecosystems, ISV, or SI, or any type of partner ecosystem, I think that it's probably the most fun job you can have at a bigger technology company, because you get exposed. It's not the same thing over and over. You get to really understand how to work with other folks and understand what's important to them. And so I stuck with it -- it was probably my 20th job at Oracle -- and when I found it and started building it, I just realized it was the most fun, like exciting, interesting, technically satisfying, from a business perspective, satisfying thing you could really do. So just from a personal perspective, I think it's probably the most fun you can have in cloud technology for a job. Unless you're like the CEO of a startup, or doing what you're doing, like building things. But if you're going to work for somebody else, I think it's a great job. Brian Walsh: 01:59 But I mean, I find that sometimes indirect sales, especially indirect software sales, can be extremely challenging. Like you're not actually doing that final license sale. You're lining up the partners and enabling them. I mean, is there something wrong in your head? Ron Huddleston: 02:14 No, there's not. It does carry its own set of complexities. But the strange thing is, whether it was on-premise or the cloud, those complexities repeat each other over, and over, and over again. So there really, after 20-odd years of doing this, there's not much you haven't seen, because where things get complicated is around human behavior, not necessarily around bringing really great solutions, and great partners, and technology together to solve problems. That's kind of the easy part, just to like address customer problems. Where things get a little crunchy is how human start, where things can get complicated, is when you're aligning different people, different organizations, different teams. That's where things get a little more complicated. I think everything up to that is not as complicated. But again, it's a pattern. And the patterns tend to repeat themselves. So you can sort of see around corners, the longer you do these kind of things, which makes it easier every time. This is, what, my third, fourth- Brian Walsh: 03:18 Fourth one. Ron Huddleston: 03:19 It kind of makes it a little easier every time you do it because you know, I probably made 10,000 mistakes. And you only make the same mistake three or four times. Brian Walsh: 03:29 Eventually, you get it right. So why an ecosystem? I mean, there's a huge amount of effort and investment. Why is it important for a software company to actually build out an ISV and/or SI ecosystem? Ron Huddleston: 03:44 Yeah. There's a lot of reasons. It depends on, are we talking about the technology company themselves that want to build an ecosystem? Brian Walsh: 03:51 Yeah. Ron Huddleston: 03:52 So you have to be a bigger company in order to do that, obviously. It's really hard to do it, otherwise. You can certainly build a small, little portfolio of folks that you work with if you're a smaller company. But there's nothing better than a broad ecosystem because it does a couple things. First things first is, if there's any way, shape, and form you're trying to prove out the sort of platform nature of the technology that you're trying to provide, the long road to get to that level of credibility is trying to do it yourself; trying to hire all the people in the world with the right expertise to sit down with a customer and explain to them, "No, bet on us. We're future-proofed. And you can do all of these things with us. We're a platform," it is really hard. The easier way to do it is to work with an ecosystem of technology, or IP, ISVs, and SIs; and the ones that are trusted in the space, that are maybe already trusted by the customers that you want to serve, and work with them to have them understand how your platform can help. And then build what's essentially, if those are the ingredients, then you know, the recipe book is how all those ingredients come together to help essentially cook a meal, like serve a beautiful meal for the customer, right? And so that's why it's a cool job. You get to be the chef, kind of. That's a good analogy, I'm going to use that analogy -- 20 years, I just discovered a new analogy. But you know, if you think about it that way, as ecosystems, as, you know, sure, you can call it one broad ecosystem, but really, it's a bunch of small solution maps, or what I was just calling recipes. It's a group of technologies, partners, companies, expertise, that solve particular problems. And no one company can really solve anything complicated on their own, really. Like it is just hard to do that over, and over, and over, and over again. You know, if you want to be broad-based, it makes it ... If you want to be a broad solution, like a platform, it makes it really hard to also solve problems, complicated problems, by yourself, right? If you want to stay really narrow and be like a really verticalized application or SI- Brian Walsh: 06:12 You can go super deep. Ron Huddleston: 06:13 You can go super deep. You can solve things on your own. But if you want to be big and broad, it's just the permutations of options are almost impossible. That's why ecosystems are so important. They drive credibility, but they also are the only way to solve really hard, complicated problems if you're trying to solve a lot of them. Those are the two reasons that it's great for the partner, or the platform, but it's great for all these companies that are sort of looking. It's great for cutting-edge companies. Like in the cloud, it was a wonderful thing. People actually all start relational databases. Like there were a lot of companies that were building up relational database practices back in the day. And there were these little, small startups that were building relational databases, or were driving Java for, like J2EE or something. Brian Walsh: 07:05 Yep. Ron Huddleston: 07:05 And I know this is going to sound really old. Brian Walsh: 07:07 We, you and I sound ancient right now. But keep going. It's great. We're reminiscing. Ron Huddleston: 07:10 Yeah. But the point was these companies, these smaller companies that would never have -- it was going to be a long time until they were big enough to where people really get exposed to them. Having an ecosystem, being part of a partner's ecosystem, of a vendor, a big platform's ecosystem, helped the companies that were the best, the most innovative, had the best technologies, sort of punch above their weight class, and could help change the market really quickly. So it's this symbiotic relationship between these platform players that need partners for the two, you know, for lots of reasons, but the two reasons I highlighted; but it's also great for partners, for ISVs and SIs, because it helps the best rise to the top. It helps the best innovate. And you know, it also, if you are the type of SIs or ISVs that are specialized in a particular place or industry, it helps you get access to customers where you might not get access before. So it's a real symbiotic thing when it's working really well, and nothing stands in the way, and there's no friction. And it's really just about sort of, you know, matchmaking. Like, you know, you're a cook. All your ingredients are great. You cook the best stuff. Everything, your oven works. Your waiters are awesome. I guess waiters would be sales in this analogy, right? Brian Walsh: 08:31 Yeah. Ron Huddleston: 08:32 Yeah. The waiters understand stuff. Brian Walsh: 08:35 Sales ops are your line chefs, right? Ron Huddleston: 08:37 Right, there you go. I'll work this analogy out at some point. I think it has legs. I'm thinking about it. Brian Walsh: 08:44 There's always an interesting thing, like if I compare where Microsoft has embraced their ecosystem, and I look at where Salesforce has, around capital efficiency, right? Because in the Salesforce world, there was almost no investment, outside of VC investment, almost no investment of, "Hey, let's invest in you to bring this product to market." Whereas we've seen, even on the Oracle and Microsoft side, lots of investment into ISVs to help them get started with an ecosystem. Ron Huddleston: 09:09 Yeah. I think Salesforce would argue, particularly back in the day when they were building it up, when we were building it up, where we didn't really have as much market presence. There are two things that companies can do to invest in you. They can certainly invest time or technology, but they can also -- I'm sorry, they can certainly invest money or technology, but they can also invest time and access. And at Salesforce, the way I pulled the AppExchange together was, you know, there were limitations around technology, and dollars, and investment dollars, which eventually got solved in one way, or shape, or form. But there was really very little limitation to time and access that could be provided. And so the big strength that Salesforce had at the time was, they were leading in the cloud. So they had, they were innovators, had access and had a sales organization. So a lot of the beginnings of that ecosystem were built around people receiving essentially go-to-market support, help, and guidance from Salesforce, in return for their technical investment in building something with Salesforce. And that was the trade-off that they made. Microsoft is a different beast, and they grew up through partners, and they always had partners. But they'd gotten to such a point where they were so dominant in the marketplace that they'd essentially become demand fulfillment. The partner channel was super optimized for really educated customers to come in and want to buy something. And they would go to very specific partners that would then fulfill that. And it was very educated demand fulfillment to a very educated market, which is entirely different than what we were setting up the One Commercial Partner team to do, which was to create demand. So, instead of having 1,000 points of connection with super-specialized partners, have partners that could show up in front of customers and say, "What problem do you have? What question do you have for my answers?" And then they could represent the full cadre of everything that Microsoft could do. You know, it's a huge technology portfolio. So they were just really limited historically because partners had to sort of pick their lane and stick with it. And so one of the things that's a great thing we did there, was break that down and only create very few lanes. So partners were expected to really lead the way and create demand. But in order to do that, we also had to change the finances. We had to change economics. We had to create a lot of incentives for the direct sales organization to work with them, which is a big part of it, too, because selling stuff, versus taking orders, is expensive. And so we had to make sure the partners could make money doing it. And so in that particular case, you know, the trade-off was, being able to represent Microsoft across the board is a tough thing to do, but if they'd invest their time, and energy, and attention, in learning how to sell and create demand, we made the economics work so that they could get a payback, which is a little different. It's almost the opposite of what Salesforce was doing. And so they're just very different situations. Brian Walsh: 12:29 Got it. Ron Huddleston: 12:30 But like I said, you know, you do this long enough, you've seen almost everything. Brian Walsh: 12:35 Well, let's actually study one more difference within that, which is you had a pure, cloud-based model. And then within Microsoft, you actually had this hybrid. You had cloud, right, like this emerging cloud ecosystem with Office 365 and Dynamics. You also had this gigantic on-prem, you know, basis of licenses. Is there a huge difference between those two types of ecosystems? Or are they basically the same? Ron Huddleston: 12:59 No. There really isn't. I mean, the economic models are different. But enough folks, I would say 8 years ago, 10 years ago -- God, 10 years ago, 15? I don't know ... Like 2008, 10 years ago, 2007, 2006, '07, '08, that's when the financial model differences, forget the technical differences, the relationship differences, the functional selling -- Brian Walsh: 13:24 Customer success, all that stuff. Ron Huddleston: 13:25 All that stuff, the actual financial models of how people expected to generate revenue and make a living, being a technology company or a consulting company, they were so different between cloud and on-prem that moving financial models was the primary thing holding people back from taking the step to the cloud. People liked the technology, but they couldn't take the jump. Like a lot of companies failed because they tried to put a foot in both camps, and you just couldn't. There's one financial model, on-prem, it's very short-term focused; one financial model, cloud, is very longterm focused. And if you're trying to serve both masters, you'll make bad, suboptimal decisions. And so I had a bunch of rules about the cloud. One of them was, you have to pick one or the other. You have to like, divest to one or the other. I think those days have changed, where even if people are doing a lot of on-prem stuff, like there's even the Microsoft SIs, or resellers, they've worked it out in such a way, through financing, through managed services, through something that they're emulating software as a service, financially. And so the technological flip is just a matter of time and opportunity. It wasn't a matter of this big burden, I'm sorry, barrier, an obstacle which is changing their whole financial model, which is really hard. I mean, I literally had sought out, the same way you guys were product development outsourcers, I'd sought out financial development outsourcers, as well, that helped to finance companies through the gap, like the two or three-year revenue gap when they make the transition, because the financial model transition was a lot harder than the technical transition, back in the day. Now, I don't think it's as hard. At Microsoft, it's, you know, some of the companies are so big, I think that the inertia is probably harder than the finances, you know? Just the daily grind, inertia of things makes things tough. Brian Walsh: 15:17 And I think some of your work in there really paid off; the Lighter Capital helping with MapAnything. Ron Huddleston: 15:22 Oh, yeah, I bet they made a crushing at that. Yeah. Brian Walsh: 15:26 Yeah. And now, I think Series D, and they're gigantic. Ron Huddleston: 15:29 Is Lighter Capital doing pretty well? I haven't talked to those guys in a while. Brian Walsh: 15:32 I think they're doing great. Ron Huddleston: 15:34 It's a great business model, I mean. Brian Walsh: 15:35 It is. Ron Huddleston: 15:35 Yeah. Brian Walsh: 15:36 It's interesting. They were so far ahead on that non-equity based funding for it. And now, I see Indie.vc. I see a lot of players coming in. Ron Huddleston: 15:44 Yeah. No, it's a good way to do it. Here at Twilio, there's so much. The funny thing is, it really feels a lot like the initial cloud, call it, revolution in 2007-08. Brian Walsh: 15:57 Yep. Ron Huddleston: 15:58 It's just in communications. And there's a lot of folks that are in the exact same spot; not that they're in financial, a big financial difference, model-wise. But telecommunications is like a different financial model, in a weird way. It's very like, usage oriented. It's got spikes. It's got a lot of weird things they're not used to, particularly if people are selling cloud seat kind of stuff. It's just a different sort of world for them. And a lot of folks don't have specialization in a lot of these things. And so, you know, building things like PDOs and financial development outsourcers are things that we're going to have to do here at Twilio as well, because there's thousands and thousands of ISVs and SIs that, whether they know it or not, are going to be using Twilio in the next couple years, because it just fits. Everybody who's moved to the cloud, there's probably an opportunity -- and touched a customer in some way, shape, or form -- there's an opportunity for them to work with Twilio. And you know, we've just got to make it easier. That was one of the things that, you were around at Salesforce when we did that, too. We just made it easier for people. Brian Walsh: 17:04 Totally. Well, let's jump into Twilio while we're here. You're assembling an amazing team. Ron Huddleston: 17:10 Yeah. They're good people. Brian Walsh: 17:11 It seems like you're applying all of your lessons from the past, you know, experiences building an ecosystem. How much do you have to continue to discover and invent? How much of this is just pulling out your playbook and running with it? Ron Huddleston: 17:24 You know, a lot of it is playbook stuff. I will say, the difference between communications technology, like it carries a lot of legacy with it. Like there is, you know, a whole lot of underlying technology that, if you're unfamiliar with it, which I am, you know, like the seven layers. That's just, there's a bunch of crazy stuff. Brian Walsh: 17:45 Yep. Ron Huddleston: 17:45 If you're unfamiliar with it, there's a lot going on there that has significant material impacts on business models that could work or couldn't work. So you bring the same playbook, and then you have this set of realities, constraints, and the technology as it exists, that then make things viable or not viable. And it is, you know, it's fundamentally a bit of a different thing, because it's a very API-forward company, which leads people down a lot of weird roads. Like what is an SI? What is an ISV? Which, by the way, we can get philosophical on this. Brian Walsh: 18:23 How do you differentiate? Ron Huddleston: 18:26 Like at Salesforce, people would just like get their heads wrapped around an axle, because you know, back in the day, when we were creating the partner program, I always tried to explain reselling, and OEMing, and trying to get like, I think, Veeva kept it on their first contract to sell Salesforce underneath their technology set. People were like, you know, "The technology is staying here. These are ours, it's in our -- this isn't the Salesforce," what do they call those things? I'm sorry. Do you remember those, at Salesforce, they have a name for the PODs that- Brian Walsh: 18:59 The ORGs? Ron Huddleston: 19:01 Not the ORGs, but whatever. It's Salesforce property. We're running it in our own data centers. Brian Walsh: 19:07 Right, in a POD. Ron Huddleston: 19:07 So how are you reselling anything? I'm like, "Well, it's, you know," even, and then licensing, which is just a human, you know, construct. It's not real. Like all these things, applying them to the cloud, it's semi-nonsensical, but it is a way to put these constructs together, and rules together, that help enable ecosystems to exist and thrive. There's something that they can sell, that they can put margin on, that they can build a business on. There's something that they can learn about, and then configure, and then leave with the customer. If you don't have the concepts of ownership, and passing ownership, and control, which don't make a lot of sense when you think about like a multi-tenant cloud, but if you don't have those things, you can't build businesses. And so, you know, a lot of it is building the faith that these human constructs exist, and that you can sell them, which for API companies, is a new thing. Like, I don't think AWS even does that yet. Brian Walsh: 19:59 No. But- Ron Huddleston: 20:00 It's weird, I know that I'm like waxing philosophical, but it is a- Brian Walsh: 20:03 But I mean, it all comes down to trust, right? Ron Huddleston: 20:06 Yeah. Brian Walsh: 20:07 You have to build trust with this partner that you will create these things, that you gave them your word, that they can actually invest millions of dollars to go forward with it. Ron Huddleston: 20:16 Yeah. Trust and credibility, in this space, is kind of what it's all about. And it's a thing about companies, too, is you know, they can, over time, their perspective on the importance of ecosystems and what the value is can change. But if you're leading up those ecosystem efforts, like you've got to try hard as hell to live up to the commitments, and consistencies, and visions that you put out there -- to the point where you're willing to sort of, you know, throw yourself in front of a train to make sure that like, you know, people don't change the philosophies you put in place, because people are betting their lives, their businesses, on what you're laying out as the vision and value of the partner program you're putting out there. And you're making these commitments, and anything that drives inconsistency, anything that's not committed, anything that violates trust in those things is a huge, huge problem. Like you know, you can spend years building up the trust that's required to build an ecosystem. And in one day, you can blow it. So that's, by far, the most important thing that you need people to understand who are setting up partner programs, or building teams, or you know, maybe looking to hire someone to build up their organization. Make sure that she or he, you know, the first thing out of their mouth needs to be like trust and consistency because without that, none of the rest of this really matters. Brian Walsh: 21:48 Yeah. And it's also, I think, the confidence that these larger organizations are actually going to stay in it, right? Ron Huddleston: 21:54 Yeah. Brian Walsh: 21:55 You know? This is not going to be a one-year test, then we're going away, because we're asking the likes of major companies to actually invest their future in this opportunity. Ron Huddleston: 22:04 Yeah. And you know, a lot of them don't take the jump and wait a year, wait two years, to see. I mean, the cloud took forever. It took four or five years for the bigger companies to jump. Brian Walsh: 22:15 Yep. Ron Huddleston: 22:15 But now, things are happening a lot faster. But there'll still be some companies that'll wait a year or two to jump. But you'll recall this, the ones that made it first in the cloud, the ones that were really successful were all the first ones, the people who moved fast. The consulting companies that moved fast, the ISVs that moved fast, the companies that jumped in there and took the risks were the ones that succeeded in the end. The ones that played on the sidelines, unless they were super dominant, they were playing catch-up, and still are. Brian Walsh: 22:44 And you watch the outcomes and success of those. ServiceMax, I mean, that was coming about when Service Cloud wasn't even fully baked, and almost a billion dollar exit. Veeva went public. DocuSign just went public. Ron Huddleston: 22:56 Yeah. Those were all the early ones, yeah. Brian Walsh: 22:58 Yep. They all came in. All right. So there is a PayPal Mafia: Peter Thiel, Elon Musk, Reid Hoffman. Ron Huddleston: 23:06 I don't know any of them very well. Brian Walsh: 23:08 Yeah, I know, but that's your social circle, I'm sure. You go surfing with them. I propose that there's actually an AppExchange Mafia as well now. We have you out there, Avanish at ServiceNow, Leyla took back over of the AppExchange, Todd Surdey is now at FinancialForce, Sean Hogan at Nintex, Brian Snyder at GE. That original crew, those people who were there on those early, Wild West days, are out there in the SaaS ecosystems. Ron Huddleston: 23:36 Yeah. Ross Eberhart's over here. Mike Rosenbaum's running product over there. Like, yeah, and a lot of trust amongst all those people. And we will, I'd love to work with any of those people. Avanish and I are always trying to figure out how we can do stuff. That's just a great group of people that, I think a lot of them learned a ton through that phase. There's even some folks that were from Oracle that are still in the Mafia, if you're going to call it that. Like, because Molly Bellero Fischer is still doing it. Ross is still doing it. Anders is still doing it. Ryan Begin's still doing it. Annie Heppberger, I think, runs partners now for Oracle. Brian Walsh: 24:23 Brent Floyd. Ron Huddleston: 24:24 Yeah. There's a lot going on; Kevin Walsh is still doing it. He's an Oracle person. Yeah. There are- Brian Walsh: 24:30 Joanne Pantuso is still doing it. Ron Huddleston: 24:32 That's right. Once you get a taste of working in ecosystems and partners, you don't really want to do other stuff, just because it's so fulfilling to help companies do something new, and grow, and to be part of their story. It's really fun. Like I said in the very beginning, in the opening when we were talking, if you could, you know, I had a lot of, I probably had 15 different jobs at Oracle. And this was by far the most fun. And I was a young man back then. And I had decided like, this is the thing I wanted to do. If I was going to work for somebody else, this is it, because there's no beating it. Like there's nothing, there's really not beating it once you get it going. That's why Twilio is so exciting, by the way. It's like the new Wild West. Brian Walsh: 25:13 Yep. Ron Huddleston: 25:13 It just reminds me of like the cloud. And a lot of those people are the same people, the Mafia you just mentioned, there's a lot of those same people that all recognize the same thing I do. Which means like, you're not running around saying, "Oh, trust me. This happened before." There's a bunch of people here that have lived it and are like, "Oh, my God. This is so interesting. It's exactly the same. And let's-" Brian Walsh: 25:34 We get to do it right the first time, this time. Ron Huddleston: 25:35 Yeah, yeah. Here's the thing -- we did it right before. I think I'd argue the Microsoft One Commercial Partner is set up the right way. We'll do it right here, it's just things are happening much faster. Instead of taking three or four years, it's happening in like 12 months. Brian Walsh: 25:52 Wow. Ron Huddleston: 25:53 It may be faster. It's crazy. Brian Walsh: 25:55 Well, and strategically, like technology-wise, adding in the whole serverless infrastructure, so you can host code now. You've got Flex, so you can start building out sort of UIs and the whole thing. Ron Huddleston: 26:05 Yeah, it has a face. Yep, that's a real thing. You'd be surprised how much having a face matters to LOB leaders, versus developers. Brian Walsh: 26:12 And I bet it also adds to some of the defensibility of it, right? Like, there's less attrition as you start adding even more and more layers, people can get deeper into your system, rather than just an API. Ron Huddleston: 26:23 Yeah. The thing about Flex, the most interesting part about Flex is the underlying technology. I don't want to give percentages, but I'd say a vast majority of the underlying technology has been around, you know, started 10 years ago, and it's been enhanced ever since. The moment that Flex came out, where it was a way to put a face, a UI, on what was possible in Twilio, the interest was a thousandfold, because it opened up people's minds to what Twilio was. Versus an API, which is a very difficult thing for non-developers to understand. You put a UI on it and explain what it is, you've just cracked open a huge market that should have been already there. It's just, people didn't understand what this, what Twilio could possibly do. And Flex wrapped that up nicely. Now the challenge is, when a platform, an API platform, which is a beautiful offering for SIs and ISVs, because it's like the cookbook that you need to do anything, which is just perfect for a partnering system. Brian Walsh: 27:21 And it's so damn easy to use at Twilio. Ron Huddleston: 27:23 Yeah. When you build an app, though, you, no matter what, unless you're picking exactly the right space, are probably going to bounce up into some elbows of people that have already built on your platform. And so, same problem at Salesforce, same problem at Microsoft, when you start expanding what you do and putting, you know, faces on things, and making new applications, like you mentioned Service Cloud and ServiceMax, that is a, you've got to tread very slowly, and know what you're doing, and make very considered decisions, because the chance that you are violating a commitment that you made to your ecosystem is probably very high. Now Twilio had never had a partner program, and really made a ton of commitments in that direction. But understanding the effects of things like this, and what's important, and what's not, is critical to our business going forward. And George and Jeff totally get it and understand. And so the idea of having governance, like a buy-build partner governance, and the impact that doing any of those actions, besides partner, if you buy or build, taking all that into consideration is one of the reasons why I feel really good about being here. Because they're super dead serious about it. And what they're focused on is, if they do buy or build, they're doing it underneath, like on the platform layer. Like even Flex, sure, it's a face. It's a UI. But if you really look at it, it's like an SDK for a UI. You know what I mean? It's not really a -- you could technically use it out of the box, but no one will. Brian Walsh: 29:02 Right. It's just the starting point. "Here, let me help you imagine this." Ron Huddleston: 29:06 Right, yeah. Brian Walsh: 29:08 That's fantastic. Well Ron, thank you very much for joining us. What's the best way, if somebody either wants to find a great job in an ecosystem, or they're looking to partner with Twilio, for them to get ahold of you and your team? Ron Huddleston: 29:20 If people want to do either of those things, the best way to get partnering going is to go online, and go to "become a partner," and go to the community. And then you'll get routed to like the person that you'll, you know, one of the 50-odd people that you'd be dealing with in to learn and become a partner. And there's people that are there just to quickly follow up and make sure you know how to do it and what's important. But if you're interested in getting a job, you can email me at rhuddleston@twilio.com, because we're hiring. We're going to hire another, you know -- lots. We're in super hiring phase right now. Brian Walsh: 29:59 Fantastic. Well, Ron, thank you very much for taking the time today, and glad we got this scheduled, and finally do it. Ron Huddleston: 30:04 Yeah, no. I'm very, very impressed by your fancy equipment and the level of professionalism in putting this podcast together. Brian Walsh: 30:11 Hey, look, I've grown up just as much as you have, okay? Ron Huddleston: 30:15 Yes, clearly you have. Brian Walsh: 30:18 All right, Ron. Thank you so much, everybody. Ron Huddleston: 30:20 All right. I'll see you around the water cooler. Bye. Outro: 30:22 Thanks for listening to this episode of the AppChat. Don't miss an episode. Visit AppChatPodcast.com, or subscribe on iTunes. Until next time, don't make success an accident.

Roger Sippl is the founder and former CEO of Informix Software. Roger began his career in computer science during the early days of the computer age. He was diagnosed with Hodgkin’s Lymphoma during college, Roger explains how this life and death situation changed how he approaches business. After the health scare, Roger switched his major to computer science and found a need for cleaner and more efficient database management software. We discuss what the software business was like in the early days and how it has changed over time. Roger has a lot of experience with running public companies and building companies to sell. He shares what he liked about his time in the software business and why he decided to focus more on investing and business mentoring. Roger also has some useful advice for new entrepreneurs who want to build a lasting company. You will learn about: Roger's business background. The cancer diagnosis and how it changed his life. Why Roger switched to the software business. His goals for the company in the early days. Why Informix became a public company. What it was like running a public company. Why Roger left Informix. How the software industry has changed over the years. What Roger considers when looking to invest in a company. The common red flags Roger sees when he evaluates a business. Roger's parting advice for the audience. Takeaways: Today's biggest takeaway is to be aware that every business has a relevance window. Your company's value will change with the market. Make sure you are prepared to sell your company when it is the most valuable. Links and Resources Roger Sippl Creative Writing About Roger Sippl Roger Sippl is a Silicon Valley software pioneer, entrepreneur, and innovator. His 30 years of contributions have helped shape the enterprise software technology landscape of today. In 1980 he founded Informix Software, and was CEO for 10 years, taking it public in 1986. Under his leadership, Informix pioneered SQL relational databases, report generators, screen data entry packages, 4GL application development tools, and scalable OLTP database technology. It is now a part of IBM, after peaking at a $4B market cap as a public company. Sippl was also co-founder and Chairman of The Vantive Corporation. Vantive became a leader in CRM, became a public company, peaked at a $1B market cap, and is now a part of PeopleSoft/Oracle. In 1993, he founded and was CEO of Visigenic Software, helping pioneer distributed object computing and the concept of the application server (based on CORBA, prior to the J2EE standard) in enterprises. Visigenic was acquired by Borland, after becoming a public company. After the Visigenic IPO Mr. Sippl earned the “Golden Hat Trick Award” from Cristina Morgan at JP Morgan/Hambrecht and Quist for three Silicon Valley IPOs. In the mid-nineties, Sippl became a founding partner of Sippl Macdonald Ventures. He invested in several successful software companies, including Illustra (acquired by Informix), Broadvision (IPO), SupportSoft (IPO) and Red Pepper (acquired by PeopleSoft). In 2002, Sippl founded Above All Software, a composite application platform that used web services and service-oriented architecture (SOA).

Roger Sippl is the founder and former CEO of Informix Software. Roger began his career in computer science during the early days of the computer age. He was diagnosed with Hodgkin’s Lymphoma during college, Roger explains how this life and death situation changed how he approaches business. After the health scare, Roger switched his major to computer science and found a need for cleaner and more efficient database management software. We discuss what the software business was like in the early days and how it has changed over time. Roger has a lot of experience with running public companies and building companies to sell. He shares what he liked about his time in the software business and why he decided to focus more on investing and business mentoring. Roger also has some useful advice for new entrepreneurs who want to build a lasting company. You will learn about: Roger’s business background. The cancer diagnosis and how it changed his life. Why Roger switched to the software business. His goals for the company in the early days. Why Informix became a public company. What it was like running a public company. Why Roger left Informix. How the software industry has changed over the years. What Roger considers when looking to invest in a company. The common red flags Roger sees when he evaluates a business. Roger’s parting advice for the audience. Takeaways: Today’s biggest takeaway is to be aware that every business has a relevance window. Your company’s value will change with the market. Make sure you are prepared to sell your company when it is the most valuable. Links and Resources Roger Sippl Creative Writing About Roger Sippl Roger Sippl is a Silicon Valley software pioneer, entrepreneur, and innovator. His 30 years of contributions have helped shape the enterprise software technology landscape of today. In 1980 he founded Informix Software, and was CEO for 10 years, taking it public in 1986. Under his leadership, Informix pioneered SQL relational databases, report generators, screen data entry packages, 4GL application development tools, and scalable OLTP database technology. It is now a part of IBM, after peaking at a $4B market cap as a public company. Sippl was also co-founder and Chairman of The Vantive Corporation. Vantive became a leader in CRM, became a public company, peaked at a $1B market cap, and is now a part of PeopleSoft/Oracle. In 1993, he founded and was CEO of Visigenic Software, helping pioneer distributed object computing and the concept of the application server (based on CORBA, prior to the J2EE standard) in enterprises. Visigenic was acquired by Borland, after becoming a public company. After the Visigenic IPO Mr. Sippl earned the “Golden Hat Trick Award” from Cristina Morgan at JP Morgan/Hambrecht and Quist for three Silicon Valley IPOs. In the mid-nineties, Sippl became a founding partner of Sippl Macdonald Ventures. He invested in several successful software companies, including Illustra (acquired by Informix), Broadvision (IPO), SupportSoft (IPO) and Red Pepper (acquired by PeopleSoft). In 2002, Sippl founded Above All Software, a composite application platform that used web services and service-oriented architecture (SOA).

No matter how fresh and new your company is, you're going to have some "legacy" applications to work with when you're mounting your cloud native efforts. The nature of those legacy apps and services are varied: mainframes, ESBs, batch job, and plain old J2EE and .Net apps. If you find yourself unable to make changes quickly enough without the fear of it all blowing up in your face, you're probably dealing with legacy. Pivotal's Rohit Kelapure talks with us in this episode about the type of analysis and, then, types patterns he and his team use to "break up the monolith." Before all that we discuss some recent news: HPE selling off its software group, Google buying Apigee, Richard and Abby's recent commentary on the container market, and fresh coiffure advice for listeners. Visit https://blog.pivotal.io/pivotal-conversations/ for show notes and other episodes.

No matter how fresh and new your company is, you're going to have some "legacy" applications to work with when you're mounting your cloud native efforts. The nature of those legacy apps and services are varied: mainframes, ESBs, batch job, and plain old J2EE and .Net apps. If you find yourself unable to make changes quickly enough without the fear of it all blowing up in your face, you're probably dealing with legacy. Pivotal's Rohit Kelapure talks with us in this episode about the type of analysis and, then, types patterns he and his team use to "break up the monolith." Before all that we discuss some recent news: HPE selling off its software group, Google buying Apigee, Richard and Abby's recent commentary on the container market, and fresh coiffure advice for listeners. Visit https://blog.pivotal.io/pivotal-conversations/ for show notes and other episodes.

No matter how fresh and new your company is, you're going to have some "legacy" applications to work with when you're mounting your cloud native efforts. The nature of those legacy apps and services are varied: mainframes, ESBs, batch job, and plain old J2EE and .Net apps. If you find yourself unable to make changes quickly enough without the fear of it all blowing up in your face, you're probably dealing with legacy. Pivotal's Rohit Kelapure talks with us in this episode about the type of analysis and, then, types patterns he and his team use to "break up the monolith." Before all that we discuss some recent news: HPE selling off its software group, Google buying Apigee, Richard and Abby's recent commentary on the container market, and fresh coiffure advice for listeners. Visit https://blog.pivotal.io/pivotal-conversations/ for show notes and other episodes.

No matter how fresh and new your company is, you're going to have some "legacy" applications to work with when you're mounting your cloud native efforts. The nature of those legacy apps and services are varied: mainframes, ESBs, batch job, and plain old J2EE and .Net apps. If you find yourself unable to make changes quickly enough without the fear of it all blowing up in your face, you're probably dealing with legacy. Pivotal's Rohit Kelapure talks with us in this episode about the type of analysis and, then, types patterns he and his team use to "break up the monolith." Before all that we discuss some recent news: HPE selling off its software group, Google buying Apigee, Richard and Abby's recent commentary on the container market, and fresh coiffure advice for listeners. Visit https://blog.pivotal.io/pivotal-conversations/ for show notes and other episodes.

No matter how fresh and new your company is, you're going to have some "legacy" applications to work with when you're mounting your cloud native efforts. The nature of those legacy apps and services are varied: mainframes, ESBs, batch job, and plain old J2EE and .Net apps. If you find yourself unable to make changes quickly enough without the fear of it all blowing up in your face, you're probably dealing with legacy. Pivotal's Rohit Kelapure talks with us in this episode about the type of analysis and, then, types patterns he and his team use to "break up the monolith." Before all that we discuss some recent news: HPE selling off its software group, Google buying Apigee, Richard and Abby's recent commentary on the container market, and fresh coiffure advice for listeners. Visit https://blog.pivotal.io/pivotal-conversations/ for show notes and other episodes.

Threadlocal is great! It can help you get out of sticky situations, and give you a great boost of performance and/or isolation. But with great tools comes great responsibility. Threadlocal can also be misused, and create memory leaks, or object corruption, and unknown sharing. So if you ever had seen one and never quite got what it does, or even if you were consider using one. Take a listen! And steer the people in the right way for the use of Threadlocal. Also, Thanks Michael for pointing the issue with episode 55 and rebasing! Don't forget to SUBSCRIBE to our cool new NewsCast! Java Off Heap https://docs.oracle.com/javase/7/docs/api/java/lang/ThreadLocal.html http://tutorials.jenkov.com/java-concurrency/threadlocal.html http://jsr166-concurrency.10961.n7.nabble.com/Threadlocals-and-memory-leaks-in-J2EE-td3960.html Do you like the episodes? Want more? Help us out! Buy us a beer!

This week, Dave and Gunnar talk about the history of Red Hat with Brian Mikkelsen, head of DOD sales, elder statesman, and tall guy. JonAS was our first foray into J2EE application servers, but nobody remembers that. Beer and a culture of sharing. Brian’s 5 Pillars: RHEL, RHEV, JBoss, Storage and Cloud The original team: Nathan Jones, Brian Mikkelsen, Chris Runge, Wayne Rhone, Mary Beekman. Anyone remember Jeff Kidwell? The infamous memo-list. A baby Spot was Brian’s first sales engineer, even before he could drink. The transition from rip-and-replace to innovator. “Where the STIG scripts at?” From Justin to OpenSCAP. General Justice and FBCB2, the “Blue Force Tracker“. Want to work for Brian? Hit him up.

The WebGoat Project has developed a free online tool used to test and uncover application flaws that might otherwise go unnoticed. In this episode of OWASP 24/7, we talk with two of the WebGoat team members, Rick Lawson and Jason White, about how WebGoat is being used and future plans. More about WebGoat WebGoat for J2EE is written in Java and therefore installs on any platform with a Java virtual machine. There are installation programs for Linux, OS X Tiger and Windows. Once deployed, the user can go through the lessons and track their progress with the scorecard

Continuando con la temática web del episodio 007, en este programa hacemos con Ramón (@m3drano) un completo análisis de todas las técnicas de optimización que podemos aplicar a una aplicación web, técnicas que podremos aplicar sea cual sea el framework o la plataforma que usemos en servidor, ya sea PHP, J2EE, .NET, Python o cualquier [...]

Unsupported Operation - Final for 2011Java / Oracle / Tool / Language RelatedJava 7u2 released, ships with JavaFX 2.0.2 which was also released JavaFX 2.0 - Intro By Example is available on Kindle as well - didn’t realize there any books out on this.Java 6u30 also releasedeFX is a new JavaFX/Netbeans Platform frameworkNetBeans 7.1 RC1 releasedJetBrains released IntelliJ IDEA 11 - a bugfix update to TeamCity was also released last weekGoogle’s Eclipse plugin is now open sourceOrion, Eclipses Cloud IDE has gone 0.4 M1 - new and noteworthy include HTML syntax highlighting, Code Mirror syntax highlighting (including mixed-mode documents, such as htmll/javascript/php), syntax validation, content type service (to store different mime types), and much moreState of the LambdaJSR 292 Goodness: Almost static final fields - for the language level hackersJSR 352 passes with two no votes - Batch JSRRedline Smalltalk compiler “complete” - work on the runtime begins. Why Smalltalk on the JVM?Dart on ChromiumShaftServer is a new DartVM Application Server - jHiccup is a new performance monitoring/analysis tool released under Creative Commons from Azul SystemsHP open source webos Interesting that they’re asking the community to decide/recommend licensing, governance etc.Adobe joins the OSGi Alliance Board of Directors (  Adobe’s Felix Meschberger apointed to BOD - principal developer/driver of the Apache Felix OSGi container ).Web Server / Web FrameworksPrimeFaces Mobile 0.9 - JSF optimized for mobilesOracle releases Weblogic 12c - which finally does full J2ee6 Apache Geronimo goes full J2EE 6 certifiedJetty 8 got released without much fanfare. Its available as standalone download, maven artifacts, rpm and debian packagesJersey 1.11 released with Eclipse MOXy supportApache Wicket 1.5 releasedRestfuse 1.0 has been released - its a test framework for REST apis running with junit.DropWizard - REST framework from Coda Hale / Yammer - has nice heartbeat system for built-in monitoring/testingMiscHibernate 4.0 FinalHibernate Search 4.0 FinalBook: Practical Unit Testing with TestNG and Mockito - available Q1 2012Mockito 1.9 released Awesomely improved documentation Pax Exam 2.3 has been releasedConfluence 4.1 releasedJDBC driver for Neo4j from Rickard OburgGoogle Guava 11rc1 out - changesAndroid+Antur Kotwal is heading to Auckland on Janurary 5 to talk about new ICS APIs.ICS shipping to Nexus S devices over the next week or twoSpringSpring Social 1.0.1Spring 3.1GroovyGrails 2.0 Heroku announces “native” support for Grailsgroovy 2.0 roadmap outlined modularity! no more swing in your server app!ScalaAdopts Play framework as officialScala IDE for Eclipse gets an updateTypesafe has been in damage control over recent high profile Scala dissing - introduces a paid for service that protects you against binary incompatibility, all  the rest of you have to sufferScala+GWT compiler has gone to version 3, seems to be following Scala’s trend of changing a lot of the internalsAnd a summary of the Yammer debateEclipseXtend 2.2 released with standalone compiler, ant task, maven plugin.Apache MavenMaven 2.x Release Plugin - Version 2.2.2 Fixed problems with version numbers in profiles not being updated, updated to SCM 1.6Maven Dependency Plugin - Version 2.4 Minor changes but one HUGE improvement: Add to purge-local-repository goal ability to clean only snapshotsdependencypath-maven-plugin Sets a property pointing to the artifact file for each selected project dependency. Each property name will have a base name in form of groupId:artifactId:type:[classifier][.relative][.suffix]. This is similar to the /dependency:properties/ goal but with additional features, like setting a relative path and filtering.Maven Surefire Plugin, version 2.11 Includes changes to the proposed plugin APIMaven FindBugs Plugin version 2.3.3Mock Repository Manager version 1.0-alpha-1 The Mock Repository Manager suite of projects are used to provide mock or lightweight Maven Repository Managers for use during integration testing of Maven plugins.Still no Apache Maven 3.0.4 release, rolled to rc4 after several issues were found, awaiting a re-release of Wagon to increase HTTP timeouts before rerolling rc5.

Globalizing Your Java Application - Part 3 Intertech's Oxygen Blast Podcasts include coverage of Java, .NET, XML, and all that is software development.

Globalizing Your Java Application - Part 2 Intertech's Oxygen Blast Podcasts include coverage of Java, .NET, XML, and all that is software development.

Globalizing Your Java Application - Part 1 Intertech's Oxygen Blast Podcasts include coverage of Java, .NET, XML, and all that is software development.

From security architecture to implementation details... what matters when a customer faces a project to implement a global J2EE application? This presentation will cover some of the more pertinent concepts and details involved from real world experiences in customer environments. About the speaker: 1995 Purdue Alumni Jerry Saulman is a Senior Managing Consultant from IBM's Tivoli Software Lab Services from Austin, Texas. A 11-year IBMer, Jerry spent 9 years working on the Tivoli Global Response Team, supporting 150 products as a global troubleshooter and IT process specialist. The last two years have been spent working on the software solution products based on Maximo technologies involving architecting and delivering customer solutions to enterprise problems solved by the product set including: change and configuration management, service request management, asset management, and provisioning of Cloud computing. Jerry has presented on technical topics to thousands of IBM consultants, customers, and industry analysts at various IBM and other technical conferences in his career at IBM. Jerry has received the IBM General Manager's Award in 2001 and 2008 for his his contributions to the success of IBM and its customers. He has written numerous technical and business white papers in his career and created educational curriculum for internal and customer education. Prior to his time at IBM, Jerry was an IT analyst at the Dow Chemical Company in Midland, MI, for 3 years.

The majority of hacker attacks (70 %) are directed at weaknesses that are the result of problems in the implementation and/or architecture of the application. This session shows how you can protect your web applications (J2EE or .NET) against these attacks. The session covers lots of practical examples and techniques for attack. Furthermore, it shows strategies for defense, including a "Secure Software Development Lifecycle". A "Live Hacking" demo rounds it out. This is a session recorded live at OOP 2009. SE Radio thanks Bruce, SIGS Datacom and the programme chair, Frances Paulisch, for their great support!

The majority of hacker attacks (70 %) are directed at weaknesses that are the result of problems in the implementation and/or architecture of the application. This session shows how you can protect your web applications (J2EE or .NET) against these attacks. The session covers lots of practical examples and techniques for attack. Furthermore, it shows strategies for defense, including a "Secure Software Development Lifecycle". A "Live Hacking" demo rounds it out. This is a session recorded live at OOP 2009. SE Radio thanks Bruce, SIGS Datacom and the programme chair, Frances Paulisch, for their great support!

The majority of hacker attacks (70 %) are directed at weaknesses that are the result of problems in the implementation and/or architecture of the application. This session shows how you can protect your web applications (J2EE or .NET) against these attacks. The session covers lots of practical examples and techniques for attack. Furthermore, it shows strategies for defense, including a "Secure Software Development Lifecycle". A "Live Hacking" demo rounds it out. This is a session recorded live at OOP 2009. SE Radio thanks Bruce, SIGS Datacom and the programme chair, Frances Paulisch, for their great support!

Gut 12 Jahre nach Markteinführung hat die Java-Platform sich in einem Maße etabliert, dass sie nicht mehr vom Markt wegzudenken ist. Doch nicht alle angestrebten Märkte konnte die von Sun Microsystems entwickelte Plattform für sich vereinnahmen - trotzdem ist Java ein wichtiger Baustein der heutigen IT-Infrastruktur. Im Gespräch mit Tim Pritlove bieten die Java-Entwicklern Dirk Jäckel und Boggle einen Überblick über die heutige Situation der Java-Platform und erläutern Vor- und Nachteile, Realitäten und Anwendungsmöglichkeiten von Java. Konkret kommen zur Sprache: die Entstehungsgeschichte von Java, Aufstieg und Fall von Java im Web, die Java-Distribution, die Funktionsweise und Optimierungen der Java VM, die Geschwindigkeit der Java VM, Speicherverwaltung und Garbage Collection, die Features und Schwachstellen der Java-Programmiersprache, Integrierte Entwicklungsumgebungen (IDE) für Java, Werkzeuge für die Softwareentwicklung mit Java, Das Lizenzmodell und alternative Java-Implementierungen, Groovy und andere alternative Programmiersprachen für die Java-VM, der Community-Prozess für Java, Entwickeln für mobile Platformen mit J2ME und für Server mit J2EE.

This is part 2 of a 2 part series. Feeling like Java EE has gotten too complicated? You are not alone! The answer to simplifying Java enterprise application development is Spring. Spring is a... Intertech's Oxygen Blast Podcasts include coverage of Java, .NET, XML, and all that is software development.

Java Spring Part I Intertech's Oxygen Blast Podcasts include coverage of Java, .NET, XML, and all that is software development.

- Client: Web design ( HTML, CSS, Images ), Interactivity / Browser Objects ( Flash, Flex, Laszlo, Silverlight, Java Applets / Webstart), Client-side scripting ( JavaScript, AJAX) - Server: Server-side scripting( PHP, ASP, ASP.NET, J2EE, CGI, Python, Perl, Ruby), Database, Systems Administration - Internet marketing: SEO, Accessibility, Marketing, Monitization - Extras: WYSIWYG tools, Web Frameworks ( Django, Rails ), Blogging & CMS ( WordPress, Joomla!, Drupal)

Two trends are pushing the industry towards the merger of application development and operational management, activities that have largely been treated as distinct phases in the software lifecycle. The first trend, which has been on-going for some time, is that it is very difficult to set up meaningful test environments for distributed applications, with test setup consuming a large fraction of the test time. These difficulties here are a consequence of the need to: (1) have a large scale environment in which to test and (2) access realistic data in order to conduct meaningful tests, and (3) have multiple different test environments for multiple test phases. The second trend is architectural styles such as SOA, mesh-ups, and Web2.0 in which programmers integrate services from live web sites. Such composites of running services are a very different style of development and deployment from the use of programming frameworks such as J2EE and .NET. Chair: Tamar Eilam, IBM T.J. Watson Research, USA. Panelists: Joe Hellerstein, Microsoft, USA, German Goldszmidt, IBM, USA, Jerry Rolia, HP Laboratories, USA, Mark Burgess, University College Oslo, Norway

Web applications are constantly under attack, and must defend themselves. Sadly, today, most cannot. There are several key elements to building self-defending software but only a few are focused on today, including input validation, output encoding, and error handling. Strong Session Handing and effective Authorization mechanisms are almost completely ignored in web application software development. Many of the threats are well known, but the techniques for building applications that can defend themselves against the known threat landscape are still ignored due to lack of documentation, lack of sample code, and lack of awareness of the threats and attack methods. This ignorance is dangerous; The landscape has changed. In April 2005 alone, zero-day scripted session attacks were discovered in the wild for eBay and other high-profile web applications that you use. Session and Authorization attacks are real, mature, and increasing in frequency of use in the wild. They are also misunderstood or ignored by most of the development and web application security community. This presentation will: * Summarize and categorize what State, Session, and Authorization attacks are. * Provide you with a simple, effective Taxonomy for understanding the threats. * Provide you with an entirely new understanding of Cross-Site Scripting (XSS). * Disclose new Session and Authorization attacks released in recent months. * Show you how to attack your intranet from the Internet using Your browser without You knowing. * Unveil the Paraegis Project which will provide free web app security code for .NET, J2EE, and Flash frameworks. * Paraegis will include functional code elements for DAT generation and stopping automated scanners/scripts. * Paraegis will show you how to reduce the attack surface of XSS from "all people all the time" to "one person one time" resulting in XSS vulnerabilities being virtually unexploitable. The techniques presented are simple, innovative, realistically usable, and predominantly missing in today's webapp designs. The Paraegis Project will release code that will not only demonstrate this, but that you will be able to use in your applications for free. Arian Evans has spent the last seven years pondering information security and disliking long bios. His focus has been on intrusion detection and application security. He currently works for FishNet Security researching and developing new methodologies for evaluating the security posture of applications and databases, in addition to helping FishNet clients design, deploy, and defend their applications. Arian works with clients worldwide for FishNet Security, and has worked with the Center for Internet Security, FBI, and various client organizations on web application-related hacking incident response. Arian contributes to the information security community in the form of vulnerability research and advisories, writing courseware and teaching classes on how to build secure web applications, and questioning everything. He frequently breaks things, and sometimes figures out how to put them back together again. Daniel Thompson is the lead interface developer for Secure Passage, a software company specializing in network device change management. His interest in computer graphics and visual design started over fifteen years ago while searching for an efficient way to create fake documents. Currently Daniel works with Java, C# and ActionScript to create secure, dependable, distributed applications. He targest .JSP, ASP.NET and the Macromedia Flash Player for delivery to the browser and Eclipse SWT and Microsoft WindowsForms for delivery to the desktop. In his spare time he works on data visualization and generative graphics, as well as the occasional game. Dan became interested in information security when Arian Evans started reading his email.

After three years of community development, the Open Web Application Security Project (OWASP) is proud to introduce the next generation of web application security standards at BlackHat USA 2005. The Guide to Securing Web Applications and Services 2.0 is a major new release - written from the ground up, with many new sections covering common and emerging risks, including: * How to design more secure software * How to conduct a security review using the Guide * How to perform the most difficult web application processes correctly: processing credit cards, interacting with payment gateways (such as PayPayl), and anti-phishing controls * Reorganized and easily navigated chapters on web application controls including: web services, comprehensive authentication and authorization controls, session management, data validation, interpreter injection, and many new controls within existing chapters * Secure configuration and deployment * And software quality assurance. The Guide has adopted and extended the popular OWASP Top 10 approach - security objectives, how to identify if you are at risk, with recommended remediations in three popular frameworks, and further reading. The Guide is platform neutral, and has examples in J2EE, ASP.NET and PHP. The Guide 2.0 is on the conference materials CD-ROM in its entirety. As it is free (as in beer as well as in freedom), you can redistribute or print it as often as you wish. To demonstrate the incredible versatility of the Guide and its pragmatic approach, we will be conducting a live security review of software selected at random by the audience. To perform the review demonstration, we will be using just a few off-the-shelf web development tools with Firefox to demonstrate how easy it is to subvert the average application, and how simple it is to fix issues properly by using the Guide. We expect this talk will be useful to all attendees, but those who set secure coding standards within their organization, manage risk from custom software, manage software development or are software architects or developers will benefit the most from attending this session. Andrew van der Stock is among the many contributors to the OWASP project over the years. Andrew has presented at many conferences, including BlackHat USA, linux.conf.au, and AusCERT, and is a leading Australian web application researcher. He helps run the OWASP Melbourne chapter, started the OWASP Sydney chapter, and is ex-President of SAGE-AU, the System Administrator's Guild of Australia. You can read more about OWASP, the Open Web Application Security Project at http://www.owasp.org/ and you can read more about Andrew at http://www.greebo.net/>

Web applications are constantly under attack, and must defend themselves. Sadly, today, most cannot. There are several key elements to building self-defending software but only a few are focused on today, including input validation, output encoding, and error handling. Strong Session Handing and effective Authorization mechanisms are almost completely ignored in web application software development. Many of the threats are well known, but the techniques for building applications that can defend themselves against the known threat landscape are still ignored due to lack of documentation, lack of sample code, and lack of awareness of the threats and attack methods. This ignorance is dangerous; The landscape has changed. In April 2005 alone, zero-day scripted session attacks were discovered in the wild for eBay and other high-profile web applications that you use. Session and Authorization attacks are real, mature, and increasing in frequency of use in the wild. They are also misunderstood or ignored by most of the development and web application security community. This presentation will: * Summarize and categorize what State, Session, and Authorization attacks are. * Provide you with a simple, effective Taxonomy for understanding the threats. * Provide you with an entirely new understanding of Cross-Site Scripting (XSS). * Disclose new Session and Authorization attacks released in recent months. * Show you how to attack your intranet from the Internet using Your browser without You knowing. * Unveil the Paraegis Project which will provide free web app security code for .NET, J2EE, and Flash frameworks. * Paraegis will include functional code elements for DAT generation and stopping automated scanners/scripts. * Paraegis will show you how to reduce the attack surface of XSS from "all people all the time" to "one person one time" resulting in XSS vulnerabilities being virtually unexploitable. The techniques presented are simple, innovative, realistically usable, and predominantly missing in today's webapp designs. The Paraegis Project will release code that will not only demonstrate this, but that you will be able to use in your applications for free. Arian Evans has spent the last seven years pondering information security and disliking long bios. His focus has been on intrusion detection and application security. He currently works for FishNet Security researching and developing new methodologies for evaluating the security posture of applications and databases, in addition to helping FishNet clients design, deploy, and defend their applications. Arian works with clients worldwide for FishNet Security, and has worked with the Center for Internet Security, FBI, and various client organizations on web application-related hacking incident response. Arian contributes to the information security community in the form of vulnerability research and advisories, writing courseware and teaching classes on how to build secure web applications, and questioning everything. He frequently breaks things, and sometimes figures out how to put them back together again. Daniel Thompson is the lead interface developer for Secure Passage, a software company specializing in network device change management. His interest in computer graphics and visual design started over fifteen years ago while searching for an efficient way to create fake documents. Currently Daniel works with Java, C# and ActionScript to create secure, dependable, distributed applications. He targest .JSP, ASP.NET and the Macromedia Flash Player for delivery to the browser and Eclipse SWT and Microsoft WindowsForms for delivery to the desktop. In his spare time he works on data visualization and generative graphics, as well as the occasional game. Dan became interested in information security when Arian Evans started reading his email.

After three years of community development, the Open Web Application Security Project (OWASP) is proud to introduce the next generation of web application security standards at BlackHat USA 2005. The Guide to Securing Web Applications and Services 2.0 is a major new release - written from the ground up, with many new sections covering common and emerging risks, including: * How to design more secure software * How to conduct a security review using the Guide * How to perform the most difficult web application processes correctly: processing credit cards, interacting with payment gateways (such as PayPayl), and anti-phishing controls * Reorganized and easily navigated chapters on web application controls including: web services, comprehensive authentication and authorization controls, session management, data validation, interpreter injection, and many new controls within existing chapters * Secure configuration and deployment * And software quality assurance. The Guide has adopted and extended the popular OWASP Top 10 approach - security objectives, how to identify if you are at risk, with recommended remediations in three popular frameworks, and further reading. The Guide is platform neutral, and has examples in J2EE, ASP.NET and PHP. The Guide 2.0 is on the conference materials CD-ROM in its entirety. As it is free (as in beer as well as in freedom), you can redistribute or print it as often as you wish. To demonstrate the incredible versatility of the Guide and its pragmatic approach, we will be conducting a live security review of software selected at random by the audience. To perform the review demonstration, we will be using just a few off-the-shelf web development tools with Firefox to demonstrate how easy it is to subvert the average application, and how simple it is to fix issues properly by using the Guide. We expect this talk will be useful to all attendees, but those who set secure coding standards within their organization, manage risk from custom software, manage software development or are software architects or developers will benefit the most from attending this session. Andrew van der Stock is among the many contributors to the OWASP project over the years. Andrew has presented at many conferences, including BlackHat USA, linux.conf.au, and AusCERT, and is a leading Australian web application researcher. He helps run the OWASP Melbourne chapter, started the OWASP Sydney chapter, and is ex-President of SAGE-AU, the System Administrator's Guild of Australia. You can read more about OWASP, the Open Web Application Security Project at http://www.owasp.org/ and you can read more about Andrew at http://www.greebo.net/>