Buck Hodges on the introduction to Azure DevOps Services - Episode 001

Buck Hodges on the introduction to Azure DevOps Services - Episode 001

Welcome to the first edition of The Azure DevOps Podcast! Your host, Jeffrey Palermo is joined by guest, Buck Hodges, to announce the global release of Azure DevOps Services. Buck is the Director of Engineering for the Azure DevOps product group and has been at Microsoft for over 15 years.

Azure DevOps Services (previously known as Visual Studio Team Services) aims to help developers ship faster. With Azure DevOps Services comes a full set of services that you can use separately, with other non-Microsoft services, or together as a suite.

In this episode, Jeffrey and Buck dive into all the key differences that come along with the rebranding and new services. Buck also gives a rundown of the system (from how it’s organized to how to mix and match with other devops tools on the market) and many of the new, exciting features available for developers.

Episode Sponsor:

Clear Measure is a software engineering firm and Microsoft Gold Partner empowering development teams to be their best. Clear Measure equips developers with the devops tools, methods, and automation necessary to focus on building their applications rather than wrestling with builds, deployments, or environments. Click clear-measure.com to see whether a devops implementation is right for you.

Topics of Discussion:

[:30] About today’s topic and guest.

[1:00] Buck Hodges announces the new Azure DevOps Services.

[2:44] Buck’s background in DevOps and career progression at Microsoft.

[10:00] Key differences with the rebranding to Azure DevOps, and its 5 main services: Pipelines, Boards, Artifacts, Repose, and Test Plans.

[14:49] Can Jira (and other similar softwares) users adopt Azure DevOps?

[16:48] About Microsoft’s commitment to open source and giving back by offering free use of Azure DevOps to run free builds for open source projects.

[20:02] About the ease of getting started with Azure Pipelines through the GitHub Marketplace, and some of the big users with Pipelines.

[20:49] A word from Azure DevOps sponsor: Clear Measure.

[21:19] About the internal transformation of the Azure DevOps team and what it looks like today.

[24:04] How many developers are part of Buck’s organization?

[24:54] Buck gives a rundown of the system (how it’s organized, how many team projects, how many Git repositories, how many independent services, etc.)

[28:58] Do they build all the services together in the same Git repository or do they split them into different build configurations?

[32:45] What’s coming next for Azure DevOps?

[36:34] Buck addresses some general misconceptions.

[40:00] When will customers be able to get their hands on the new Azure DevOps 2019 server?

[41:30] Where to learn more or get started with Azure DevOps.

Mentioned in this Episode:

Azure DevOps

VSTS

Azure Pipelines

Azure Boards

Azure Artifacts

Azure Repose

Azure Test Plans

Team Foundation Server (TFS)

Jira

GitHub

Visual Studio Code

TypeScript

Dev.Azure.com

Want to Learn More?

Visit AzureDevOps.Show for show notes and additional episodes

Follow Up with Our Guest:

Posts by Buck Hodges on Microsoft Azure

Buck Hodges’ LinkedIn

Jaksot(371)

Philippe Kruchten: Controlling Your Architecture - Episode 195

Philippe Kruchten: Controlling Your Architecture - Episode 195

Philippe Kruchten has over 35 years of software development experience. Now retired, his experience focused mostly on large technical systems such as telecommunication, defense, aerospace, and software tools. He also spent 16 years as an educator and researcher in a major Canadian engineering school.   Topics of Discussion: [2:18] Philippe gives some of the highlights of his long career, starting first as a mechanical engineer and then traveling the world as a software engineer. [4:26] How Philippe has seen software architecture change over time and the struggles architects still face. [6:03] Software architects are among some of the most in-demand professions. [7:10] What makes software architecture different from other coding? [9:05] Discussing Building and Evaluating a Theory of Architectural Technical Debt in Software-intensive Systems and the three reasons for architectural debt. [11:31] A major reason for architectural debt in software is not understanding the architecture due to improper documentation. So what is the proper way to document? [17:23] Regardless of the format, each key audience needs a view specific to them, and how to document the decisions. [21:19] Is there a best approach for harvesting or understanding the actual architecture? [23:46] With a big architectural change, using systematic impact analysis and prototyping are ways to carefully approach the shift. [26:48] Some unsolved issues that remain within the industry and what a good software developer looks like, then vs. now.   Mentioned in this Episode: Architect Tips — New video podcast! Azure DevOps Clear Measure (Sponsor) .NET DevOps for Azure: A Developer’s Guide to DevOps Architecture the Right Way, by Jeffrey Palermo — Available on Amazon! Jeffrey Palermo’s YouTube Jeffrey Palermo’s Twitter — Follow to stay informed about future events! “Building and Evaluating a Theory of Architectural Technical Debt in Software-intensive Systems” “A General Model of Software Architecture Design Derived From Five Industrial Approaches” Software Systems Architecture 4+1 Architectural View Model IEEE 1471   Want to Learn More? Visit AzureDevOps.Show for show notes and additional episodes.   Quotes: “I think we’ve made some progress. We understand the role of architecture a little bit better.”— Philippe [4:59] “We’re still hindered by the fact that architecture is hard to grasp; it’s hidden out there in the software, it's not visible at the surface.” — Philippe [5:05] “We’ve come a long way in making architecture a first-class citizen in a few organizations.” — Philippe [5:42] “Architecture, for me, is the set of design decisions you have to make usually early in the life of a system that will actually condition a lot of things in terms of structure and behavior of the system.” — Philippe [7:25] “It’s not programming; although the architecture will end up being code somewhere. The act of developing a software architecture is more about decision-making and understanding the intricate network of decisions and how they relate to each other.” — Philippe [7:58] “Not every software developer needs to be a software architect, but they need to understand what is the software architecture of the system I’m working on.” — Philippe [8:45] “You end up being in a position of architectural technical debt not because you made the wrong decision 10 years ago, but because those decisions are not the right one in the current circumstances. Then there is architectural debt because what you did 10 years ago was just plain stupid!” — Philippe [10:38] “Diagrams are useful for architects to communicate to another audience.” — Philippe [18:59]   Philippe: Website | Twitter | LinkedIn

30 Touko 202232min

Adam Tornhill: Your Code as a Crime Scene - Episode 194

Adam Tornhill: Your Code as a Crime Scene - Episode 194

Adam Tornhill is a programmer who combines degrees in engineering and psychology. He's the founder of CodeScene where he designs tools for software analysis. He’s also the author of Software Design X-Rays, the best-selling book Your Code as a Crime Scene, Lisp for the Web, and Patterns in C. Adam’s other interests include modern history, music, and martial arts.   Topics of Discussion: [2:10] Adam talks about how he got his start in code metrics 25 years ago and why he’s discovered that it’s so hard to write good code. [3:48] What are the other book ideas Adam has to add to his existing four? [4:53] What motivated Adam to write Your Code as a Crime Scene and what is the premise? [9:02] When assembling the data, relevance, as well as quality, are both important. [10:29] Cyclomatic complexity is an old metric, as are many others, that is not quite tangible or relevant. [11:58] Why Adam prefers to look at code health vs. code quality. [13:26] The process is slightly different when looking at code health for existing code vs. writing new code. [15:23] How does CodeScene aid in the pull request process? [18:31] CodeScene integrates with your version control repository and work tracking tools to find where bugs were introduced. [22:22] Is CodeScene meant to be a standalone tool or can it work alongside many of the other tools on the market? [24:57] Adam’s rules of thumb for those getting started in software systems. [28:12] Why Adam’s preferred method of delivering software architecture has changed over the years. [30:36] What are the steps for implementing CodeScene into a codebase?   Mentioned in this Episode: Architect Tips — New video podcast! Azure DevOps Clear Measure (Sponsor) .NET DevOps for Azure: A Developer’s Guide to DevOps Architecture the Right Way, by Jeffrey Palermo — Available on Amazon! Jeffrey Palermo’s YouTube Jeffrey Palermo’s Twitter — Follow to stay informed about future events! CodeScene — Free Community Edition Adam Tornhill on Github Software Design X-Rays Your Code as a Crime Scene Lisp for the Web Patterns in C “Code Red: The Business Impact of Code Quality”   Want to Learn More? Visit AzureDevOps.Show for show notes and additional episodes.   Quotes: “Software development and software code, in particular, are very abstract. There’s no way I can really take a software system and pull it out and turn it around and inspect it for flaws.” — Adam [6:34] “What I’m most interested in is trends; so are we moving in the right direction or the wrong direction?” — Adam [15:14] “My experience, from working with all of these companies, is that pull requests and code reviews, in general, are extremely valuable… but they also tend to become a bottleneck in practice.” — Adam [16:10] “A surprise is simply one of the most expensive things you can put into a software architecture.” — Adam [30:15] “While these mechanics are simple, information is only good when acted upon.” — Adam [31:20]   Adam: Website | Twitter | LinkedIn

23 Touko 202233min

Rod Paddock: Application Longevity for Dummies - Episode 193

Rod Paddock: Application Longevity for Dummies - Episode 193

Rod Paddock is the CTO of Dash Point Software, Inc. and the Editor in Chief of CODE Magazine! In 2001, Rod founded Dash Point Software, Inc. to develop high-quality custom software solutions. With over 30 years of experience, some of his current and past clients include Six Flags, First Premier Bank, Microsoft, Calamos Investments, The U.S. Coast Guard, and U.S. Navy. Along with developing software, Rod is a well-known author and conference speaker. Since 1995, he has given talks, training sessions, and keynotes in the U.S., Canada, and Europe. Rod was a guest way back in Episode 111.   Topics of Discussion: [4:19] What was the state of the industry like when Rod started teaching? [6:12] Rod talks about the event that led him to have dinner with Top Gun pilots, and a moment of celebrity fame in an elevator. [10:11] Rod talks about Code Magazine and how it has developed over the years. [11:01] Rod speaks about the state of remote work, and how it’s giving people time back for more creativity. [15:29] What are the important factors and Rod’s process when planning for applications to live a long time? [21:26] Rewriting applications is a lot of times harder than building from the ground up. [23:22] There are a lot of ways to build, and that includes both planning and a little bit of luck. [24:02] When do you know if it’s time to rebuild a current application? [26:08] You have to know where your problems and pain are, and every system has pain. [29:34] Why is laziness a good thing for a software developer? [36:50] People are very resilient and very resourceful, and they will figure out how to make your software do stuff you would never expect.   Mentioned in this Episode: Architect Tips — New video podcast! Azure DevOps Clear Measure (Sponsor) .NET DevOps for Azure: A Developer’s Guide to DevOps Architecture the Right Way, by Jeffrey Palermo — Available on Amazon! Jeffrey Palermo’s YouTube Jeffrey Palermo’s Twitter — Follow to stay informed about future events! Dash Point Software, Inc. A Philosophy of Software Design, by John Ousterhout Software Engineering at Google: Lessons Learned from Programming Over Time, by Titus Winters, Tom Manshreck, and Hyrum Wright Code Magazine — Use Code TADP For Free Subscription The Mythical Man-Month: Essays on Software Engineering, by Frederick P. Brooks, Jr.   Want to Learn More? Visit AzureDevOps.Show for show notes and additional episodes.   Quotes: “I consider myself extremely fortunate in my whole career.” — Rod “Lots of people are getting essentially 20 hours a week back, and just not from commuting, which is pretty cool.” — Rod “Rewriting applications is a lot of times harder than building from the ground up.” — Rod “You have to pay attention to the way you’re building your applications, and that helps the longevity as well, and know the pieces that you can rip out and rebuild.” — Rod “People are very resilient and very resourceful, and they will figure out how to make your software do stuff you never thought it was going to do.” — Rod    Rod: Website | Twitter

16 Touko 202241min

Udi Dahan: Distributed Computing - Episode 192

Udi Dahan: Distributed Computing - Episode 192

Udi Dahan is one of the world’s foremost experts on Service-Oriented Architecture and Domain-Driven Design and is also the creator of NServiceBus; the most popular service bus for .NET. Udi joined us back on Episode 32 to discuss Microservices.   Topics of Discussion: [2:47] Udi talks about some of the changes, and similarities, in distributed computing in the last five years as well as generational differences to approach learning. [11:27] Udi defines what a service mesh is and when it’s applicable. [14:46] Udi discusses his concerns regarding using a service mesh and common problems encountered. [22:28] With most of the new generation of programmers using Web service-based programming, what does Udi think they need to hear? [27:50] Why Udi thinks the larger companies and vendors need to take more responsibility and “do more good.” [32:48] Udi shares more on NServiceBus’s offerings and functionality and why developers need to learn more. [36:36] Are there any pieces of NServiceBus that will need more than just a .NET standard support?   Mentioned in this Episode: Architect Tips — New video podcast! Azure DevOps Clear Measure (Sponsor) .NET DevOps for Azure: A Developer’s Guide to DevOps Architecture the Right Way, by Jeffrey Palermo — Available on Amazon! Jeffrey Palermo’s YouTube Jeffrey Palermo’s Twitter — Follow to stay informed about future events! Particular Software — NServiceBus Episode 32 — Microservices   Want to Learn More? Visit AzureDevOps.Show for show notes and additional episodes.   Quotes: “Every generation of programmers needs to relearn kind of the same points over again.” — Udi [3:51] “We’re still essentially coming up with new generations of technologies that are addressing the same category of problems.” — Udi [6:16] “The problem is not rooted in what do they need to hear so much as who do they need to hear it from.”— Udi [23:51] “If you know a thing, if you can help, then you should.” — Udi [29:47] “NServiceBus essentially takes all of the problems that you never want to have, and the challenges that most people don’t know that they’re going to have so they don’t appreciate it until they have it, and essentially prevents them from happening.”— Udi [34:29] “That ounce of prevention is equivalent to a pound of cure.” — Udi [34:46]   Udi: Website | Twitter

9 Touko 202239min

Scott Wlaschin: Domain Modeling Made Functional - Episode 191

Scott Wlaschin: Domain Modeling Made Functional - Episode 191

Scott Wlaschin is an expert on F#, author of the popular F# site fsharpforfunandprofit.com, and a board member of the F# Software Foundation. Known for his non-academic approach to functional programming, Scott is a popular speaker and has given talks at NDC, F# Exchange, DDD Europe, and other conferences around the world.   Topics of Discussion: [2:40] Scott talks about how he got into F#, and the nonlinear path his career has taken. [4:00] Scott walks us through the history of F#. [6:52] What types of applications should developers be looking at F# for? [10:55] What was Scott’s inspiration behind writing Domain Modeling Made Functional? [12:20] Domain-driven design has nothing to do with a particular language. It’s a process. [17:32] As an industry, whether it be literature or art, there’s so much to be gained by observing and reading prior works of others. [19:55] How does functional thinking impact architecture? [20:51] In functional programming, you want everything to be deterministic. [28:34] What are some of the examples of transcription scripts? [31:10] In functional programming, the main thing is the function and not the object.   Mentioned in this Episode: Architect Tips — New video podcast! Azure DevOps Clear Measure (Sponsor) .NET DevOps for Azure: A Developer’s Guide to DevOps Architecture the Right Way, by Jeffrey Palermo — Available on Amazon! Jeffrey Palermo’s YouTube Jeffrey Palermo’s Twitter — Follow to stay informed about future events! F# Software Foundation Domain Modeling Made Functional: Tackle Software Complexity with Domain-Driven Design and F#   Want to Learn More? Visit AzureDevOps.Show for show notes and additional episodes.   Quotes: [3:00] “I started learning functional programming because I sort of felt like I really knew everything there was to know about databases and all that stuff. I thought I wanted something different.” — Scott [8:52] “It really depends on how you like to program. If you like to program in a functional style, and you want to be on .NET, then F# is perfect.” — Scott [12:00] “Don’t focus on the technology, focus on what you are actually trying to build.” — Scott [17:32] “As an industry, whether it be literature or art, there’s so much to be gained by observing and reading prior works of others.” — Jeffrey   Scott:  Website | Twitter

2 Touko 202235min

Heather Downing: Retooling for the Future - Episode 190

Heather Downing: Retooling for the Future - Episode 190

Heather is a passionate coder and entrepreneur. She has experience working with Fortune 500 companies building enterprise-level voice, mobile, and C#/.Net applications. She focuses on external thought leadership, encouraging fellow programmers to present on topics outside of the office and in the community. She is also an international technical speaker, recently speaking at NDC, an early adopter of technology, and a conference organizer at KCDC, the Kansas City Developers Conference.   Topics of Discussion: [3:00] Heather talks about her deep dive into her local community to figure out how we learn and how different generations are discovering content. [3:12] We now have a multigenerational community and it’s important to consider that there are now four different groups of people that learn completely differently. [5:40] With so many people from different cultures and backgrounds, Heather thinks that if we’re not accommodating, we’re not going to be able to replace ourselves. [8:23] Heather explains the importance of every developer finding their favorite documentation. [12:29] The great equalizer is that we all want to solve problems. Heather talks about the importance of letting beginners ask the right questions, and giving them the space to problem solve. [14:36] Heather describes the reality she sees from university programs and boot camps, along with the importance of having basic people skills. [18:27] Heather describes how time boxing and The Pomodoro Technique can provide a structure for productivity and can help you accomplish more without overwhelm. [21:36] The book Atomic Habits was a powerful read for Heather and she wishes she had read it before! One of the takeaways is that anything that is broken down seems more digestible. When you focus on just getting one percent better at something every day, your goals start to get more manageable. [24:24] Resiliency is key in software. [24:49] Sometimes what you’re trying to get better at is not software coding at all, but communication and really listening. [24:50] Heather gives her take on if you need to have a University degree to go into software, and where she thinks the engineering field will end up. [34:42] Heather’s advice for young developers looking at older work — keep in mind that it’s possible that they did the best they could have at the time. Plus, one day that will be you, so try to have some grace and understanding.   Mentioned in this Episode: Architect Tips — New video podcast! Azure DevOps Clear Measure (Sponsor) .NET DevOps for Azure: A Developer’s Guide to DevOps Architecture the Right Way, by Jeffrey Palermo — Available on Amazon! Jeffrey Palermo’s YouTube Jeffrey Palermo’s Twitter — Follow to stay informed about future events! Charisma University Atomic Habits: An Easy & Proven Way to Build Good Habits & Break Bad Ones Kevlin Henney, Medium Kevlin Henney, NDC London   Want to Learn More? Visit AzureDevOps.Show for show notes and additional episodes.   Quotes: “You have to be able to think about how you want to solve this problem, but also communicate it and if you can’t do that, it will limit you. You can be amazing, but if nobody knows what you’re talking about, because you never mention it or you never speak up, that’s going to limit you.” “With so many people from different cultures and backgrounds, I think if we are not accommodating, we’re not going to be able to replace ourselves.” — Heather [5:15] “I feel like every developer needs to just sit down and find their favorite documentation that they’ve learned from and see if they can at least mimic that.” — Heather [8:23] “If you’re not enjoying something, maybe you can suggest a different way instead of just quitting.” — Heather [12:04] “You aren’t guaranteed to succeed. But you are guaranteed to struggle, struggle well.” — Heather [23:24] “Maybe it really just takes a slight adjustment or retooling instead of blowing it away and building something completely from scratch again.” — Heather [34:00]   Heather: Website | Twitter

25 Huhti 202236min

Mark Seemann: Code That Fits In Your Head - Episode 189

Mark Seemann: Code That Fits In Your Head - Episode 189

Mark Seemann is a Danish software developer based in Copenhagen, Denmark. His professional interests include functional programming, object-oriented development, as well as software development in general. Apart from writing two books, he has also written numerous articles and blog posts about related topics. Despite being a mostly .NET developer, Mark takes most of his inspiration from sources across a wide range of technologies, including Haskell and lots of pattern books. Originally poised to become a rock star or (failing that) graphic novelist (in the European tradition) he one day found himself with insufficient talent for either, a master's degree in Economics, and a desire for working with computers. He has been doing the latter intermittently since 1995.   Mark is the author of two books so far: Author of Dependency Injection .NET as well as Code That Fits In Your Head.   Topics of Discussion: [4:55] Mark talks about the thought process behind writing Code That Fits In Your Head. [10:10] Why doesn’t Mark like software projects? [13:06] Yes, we want to create value for the businesses when we write code, but we also have to have a longer view on things as well. [17:11] Mark shares three of the most things for getting started with a new application. [19:46] Mark walks us through the process of automating a build. [22:42] Most compiler warnings indicate that you have problems with your code. [28:29] What are some of Mark’s resources and pieces of advice for younger programmers? [35:31] In Denmark and Scandinavian cultures, you often feel like the CEO is within close reach and someone that you could easily have lunch with. Mark talks about overcoming resistance in long-time developers when learning something new that may cause some anxiety or insecurity.   Mentioned in this Episode: Architect Tips — New video podcast! Azure DevOps Clear Measure (Sponsor) .NET DevOps for Azure: A Developer’s Guide to DevOps Architecture the Right Way, by Jeffrey Palermo — Available on Amazon! Jeffrey Palermo’s YouTube Jeffrey Palermo’s Twitter — Follow to stay informed about future events! Code That Fits In Your Head   Want to Learn More? Visit AzureDevOps.Show for show notes and additional episodes.   Quotes: “We’re the odd types that find it fun to type characters that sometimes test the reaches of the keyboard, and just tell the computer what to do.” — Jeffrey [4:20] “Treat all warnings as errors.” — Mark [18:40] “Nowadays, it’s not so much from the management that the resistance exists, but actually from other people.” — Mark [37:40]   Mark: Pluralsight.com/authors/mark-seemann

18 Huhti 202243min

Derek Comartin: A Software Architect’s Mindset - Episode 188

Derek Comartin: A Software Architect’s Mindset - Episode 188

Derek Comartin is a software developer with two decades of professional software development experience. He has written software for a variety of business domains, such as distribution, transportation, manufacturing, and accounting. Derek also has a very active blog and YouTube channel (CodeOpinion.com) that focuses on Software Architecture and Design.   Topics of Discussion: [3:21] Derek’s mentor was an accountant who gave him more insight into business processes and changed his way of thinking. [9:42] How can we better relate processes in the real world to the solutions we are writing? Derek gives an example of reservation patterns and how that can translate to different places in software. [13:23] A conversation that is often lacking is that if you’re writing software for business, are you really understanding what the business is trying to do? [20:10] You can be an individual contributor, even if your communication is just with your team. [28:22] A good question to ask is why you have this problem in the first place. [29:53] When software does something, who actually does it? [37:31] The best developers Derek has talked with or worked with have a unique combination of technical skill and business acumen.   Mentioned in this Episode: Architect Tips — New video podcast! Azure DevOps Clear Measure (Sponsor) .NET DevOps for Azure: A Developer’s Guide to DevOps Architecture the Right Way, by Jeffrey Palermo — Available on Amazon! Jeffrey Palermo’s YouTube Jeffrey Palermo’s Twitter — Follow to stay informed about future events!   Want to Learn More? Visit AzureDevOps.Show for show notes and additional episodes.   Quotes: “If we’re talking about an individual team, I think everybody can have or share some of the responsibilities. I think everybody can play a part in understanding what you’re trying to accomplish.” — Derek [23:25] “One thing that I’ve seen hurt programmers’ trust is getting frustrated if somebody doesn’t think like them.” — Jeffrey [24:53] “The best developers I’ve talked with or worked with have this unique combination of technical skill, and this business acumen or knowledge.” — Derek [32:08]   Derek: CodeOpinion

11 Huhti 202244min

Suosittua kategoriassa Politiikka ja uutiset

rss-ootsa-kuullut-tasta
aikalisa
ootsa-kuullut-tasta-2
politiikan-puskaradio
rss-podme-livebox
rss-vaalirankkurit-podcast
otetaan-yhdet
et-sa-noin-voi-sanoo-esittaa
linda-maria
the-ulkopolitist
rss-raha-talous-ja-politiikka
rikosmyytit
positiivista-poditiikkaa-huff-lindgren
rss-lets-talk-about-hair
rss-mina-ukkola
rss-polikulaari-humanisti-vastaa-ja-muut-ts-podcastit
rss-fingo-podcast