Podcast appearances and mentions of David Kramer

Link Ahead with the City of Dublin, Ohio

Play Episode Listen Later Dec 12, 2024 60:26

Eric and Eliot discuss the rapidly unfolding events in Syria and examine the causes and consequences of the collapse of Bashar al Assad's regime in Syria. They discuss the big winners (Turkey, Israel, the Syrian people and to a lesser extent the U.S) and the big losers (notably Russia and especially Iran). They discuss the timing of the Hayat Tahrir al Sham offensive, how to interpret the claims of HTS leader abu Mohammed al Jolani that the group has moderated, the prospects for Russia maintaining its Khmeimim Air Base and its naval base at Tartus, as well as the future of Iranian national security policy. In particular, they discuss whether the Iranians will have incentives to sprint to a nuclear weapon or whether they will temporize and seek to embroil the incoming Trump administration in an endless negotiation over the nuclear program. They discuss the Biden Administration's efforts to polish its reputation in the aftermath of recent events and the waxing and waning of leadership reputations including former President Barack Obama and former German Chancellor Angela Merkel. They consider what effect events in Syria might have on Trump's approach to the war in Ukraine. They also touch on listener criticisms that calling for greater defense spending seems out of touch with today's American political scene. They consider the results of the recent Reagan National Defense Forum survey and the light those results shed on the question of public support for stronger national defense. Eliot's latest pieces in the Atlantic: https://www.theatlantic.com/ideas/archive/2024/12/khamenei-iran-syria/680920/ https://www.theatlantic.com/ideas/archive/2024/12/european-troops-ukraine-war/680928/ Eric & David Kramer's latest in Politico: https://www.politico.com/news/magazine/2024/12/06/trump-ukraine-better-foreign-policy-00192415 Reagan Foundation Study on Public Perception of Defense Spending: https://www.reaganfoundation.org/media/363274/rndf-survey-nov-2024-memo.pdf Financial Times Retrospectives on Angela Merkel: https://www.ft.com/content/0a538c85-27fb-400e-ae8b-f13fb6ce4e72 https://www.ft.com/content/e82af5d9-32ea-444e-93e2-9e457d6a6796 Shield of the Republic is a Bulwark podcast co-sponsored by the Miller Center of Public Affairs at the University of Virginia.

Fiber to the home is here! The timeline, capabilities and what Dublin residents and businesses should expect during installation

Play Episode Listen Later Oct 24, 2024 22:08

The goal to become the most connected community in the U.S. has reached another milestone! Our 'Fiber to Every Home' initiative is underway, and some residents are already connected to this groundbreaking system. Construction began in April of this year and it's really ramping up now. In fact, please be on the look-out for mailers and doorhangers from altafiber because those are definite indicators construction is coming to your neighborhood. Joining Lindsay and Bruce to talk about all the details is Senior Director of Corporate Strategy and Development at altafiber, David Kramer. They discuss the construction timeline, the benefits of fiber optics, the powerful capabilities of this system and costs of various packages for our residents and businesses. As David says, 'nothing beats light over fiber' as next generation broadband with multi-gig internet service is here!

development businesses construction dublin timeline senior director residents fiber installation capabilities corporate strategy every home david kramer

David Kramer is back with a new musical "Orpheus McAdoo"

The Flash Drive with Carl Wastie

Play Episode Listen Later Oct 18, 2024 12:43

David Kramer's new musical Orpheus McAdoo will be presented by Cape Town Opera at Artscape starting today (18 October). The highly anticipated production is an exciting, fresh take on Kramer's hugely successful Orpheus in Africa that premiered in Cape Town in 2015. Orpheus McAdoo marks an exciting first-time collaboration between the Cape Town Opera Company and the legendary David Kramer. His music, inspired by early spirituals, minstrel songs, ragtime, ballads and opera, includes several new songs by Kramer who also directs the show. Kramer joined Brandon Leigh on The Flash Drive to talk about this new production. Orpheus McAdoo runs at Artscape from 18 October to 4 November 2024. Tickets from R200 to R450 can be purchased through Webtickets and Artscape Dial-A-Seat on 0214217695. Discounts are available for groups, students and pensioners.See omnystudio.com/listener for privacy information.

africa tickets discounts cape town kramer orpheus new musicals mcadoo flash drives david kramer r200 artscape

Musical: Orpheus McAdoo

Afternoon Drive with John Maytham

Play Episode Listen Later Oct 17, 2024 5:02

David Kramer's new musical Orpheus McAdoo, will be presented by Cape Town Opera at Artscape this month. Orpheus McAdoo runs at Artscape from 18 October to 4 November 2024. Fiona du Plooy assistant director shares a highlight.See omnystudio.com/listener for privacy information.

musical orpheus mcadoo david kramer artscape plooy

People of Note - David Kramer

People of Note

Play Episode Listen Later Sep 28, 2024 58:39

David Kramer's hugely successful musical Orpheus in Africa is being repeated at the Artscape Theatre and David has reworked it to be produced with Cape Town Opera. It's now called Orpheus McAdoo and stars Brittany Smith and Conroy Scott with the Cape Town Opera Chorus and opens on 18 October. Rodney Trudgeon invited David Kramer into the People of Note studio to talk about this exciting project.

africa orpheus brittany smith david kramer artscape theatre

Jody Abrahams to take to the stage again in a David Kramer musical

Breakfast with Refilwe Moloto

Play Episode Listen Later Sep 20, 2024 7:58

Jody Abrahams has been performing on stage and screen for more than four decades, and will be making a re-appearance soon in Orpheus McAdoo, a first-time collaboration between the legendary David Kramer and the Cape Town Opera company. See omnystudio.com/listener for privacy information.

stage musical abrahams david kramer

#46. Digital Enablement: Customer-led business, Subjective Value, and Empathy with David Kramer

Value Creators

Play Episode Listen Later Aug 29, 2024 61:46

Digital enablement and AI are revolutionizing how companies operate and reshaping the economy. At the core of this transformation remains a fundamental principle: the customer is the boss. In this new era, empathy becomes crucial as businesses strive to meet subjective values and deliver hyper-personalized experiences. Consumers demand instant access, precise responses, seamless order fulfillment, and transparency, while resisting intrusive tracking and data monetization.David Kramer, Founder & Chief Product Officer at Cooperative Computing, joins Hunter Hastings to highlight how AI can enhance creativity while balancing automation and human touch. In this discussion, Kramer shares insights on the digital enablement movement, emphasizing that AI should complement human creativity rather than replace it. He underscores the need for maintaining a brand's unique voice amidst the risk of generic content. As AI advances, businesses must adapt, using it to innovate while preserving the essential human element that resonates deeply with audiences. This approach aligns with the shift towards hyper-personalization, where understanding and delivering what each individual wants becomes the new standard, as exemplified by companies like Nike, which serves diverse customer needs with tailored, transparent experiences.Resources:Connect with Hunter Hastings on LinkedInCooperative ComputingConnect with David Kramer on LinkedInDigital Enablement by Cooperative Computing PDFShow Notes:0:00 | Intro: Vision of the Digitally Enabled Firm01:57 | 5 Key Business Functions: Branding and Marketing03:15 | Second Key: Sales and Commerce03:56 | Digitally Enabled Organization: Third and Fourth Key04:48 | Fifth Key for a Digitally Enabled Organization: Service Delivery Management07:13 | Human Role: Coding OR Evolving Decisions?13:13 | Are We Still Customer-Centric?20:33 | Transition Away From Control25:01 | Customer in this New Digital Environment29:39 | Demand for Transparency and Responsiveness35:34 | Managing Accelerating Digital Change Speed: The Art of Possible40:47 | Stephen Hawking: Cosmology Depends on the Questions You Ask45:38 | Is Competition Still Relevant, and Can Large Firms Adapt?53:52 | Wrap-Up

founders ai digital empathy transparency consumers kramer chief product officer wrap up subjective enablement resources connect david kramer

David Kramer on Affordable Housing

The AFIRE Podcast

Play Episode Listen Later Aug 27, 2024 34:06

How can affordable housing become a reality in cities like New York, whose current blueprint and zoning regulation is not easily suited to modern market-rate and affordable housing development? https://www.afire.org/podcast/202411cast/ In our latest episode of the AFIRE podcast, CEO and host Gunnar Branson speaks with David Kramer, president of the Hudson Companies, a leading developer in NYC, about what it takes to build affordable housing in a city made for anything but. It's a wide-ranging, entertaining conversation about the challenges of living and developing real estate in one of the most vibrant cities in the world—and America's key “gateway” city. Kramer and Branson explore the tension between developer's public profiles, and the realities of trying to build new projects in a sustainable way, while also nurturing a city that is hospitable to people from all walks of life. Kramer also takes down the common misconception that landlords determine rents. In fact, Kramer says that achieving housing affordability starts with increasing the number of units in a given market. “The solution . . . should not be chastising landlords and trying to limit rent increases—it should be increasing the supply.” With decades-worth of insider perspective and a whole host of entertaining analogies, Kramer's interview provides a portrait of a New York developer doing his best to contribute to a city where people love to be—and what other cities can learn from this approach.

america ceo new york new york city kramer affordable housing afire david kramer

Ep. 82 - David Kramer President of Hilton & Hyland

The Deal with Danny Brown

Play Episode Listen Later Aug 21, 2024 40:58

David Kramer is the President of Hilton and Hyland one of the most successful boutique luxury brokerages in the Nation. He sold the infamous Spelling Mansion for $119M in 2019 a record price at the time and had been consistently one of the top performing agents in Los Angeles for the past 3 decades. Hilton and Hyland was founded in Beverly Hills in 1993 by Rick Hilton (Nicky and Paris's dad) and Jeff Hyland, one of the most prolific luxury agents and heralded experts in high end residential real estate in Los Angeles. When the beloved snd iconic Jeff Hyland passed away in 2022 he left impossible shoes to fill. The brokerage reeled through a challenging transition phase and turned to their top producing veteran agent David Kramer for leadership. He rose to the occasion. In this episode David discusses the evolution of his business from $100k condos to $100M estates and his new role as the president of Hilton & Hyland. This is a master class in brokerage with one of the best in the business. Please leave us a comment and 5 star review at ApplePodcast which improves are ratings and spread the word if you love real estate as much as we do. http://instagram.com/davidkramerre You can reach Heather Domi http://instagram.com/heatherdomi.re http://heatherdomi.com You can reach Danny Brown http://instagram.com/dannybrownla http://www.dannybrownla.com

president business los angeles apple podcast beverly hills 100m hilton hyland danny brown luxury homes david kramer

On the couch: Musical Theatre icon David Kramer and actress Jenny Stead talk about their new production

Afternoons with Pippa Hudson

Play Episode Listen Later Jul 23, 2024 12:39

Pippa speaks to musical theatre icon David Kramer and award-winning actress Jenny Stead about their new production of the musical Vêr In Die Wêreld Kittie, which opens this weekend at The Blik in Epping. The show tells the story of South African folk singer Josef Marais and his wife Rosa de Miranda. It has been reworked and extended for this new run at The BlikSee omnystudio.com/listener for privacy information.

theater actress south africans icon couch musical theatre blik stead epping david kramer new production

What the Hell Is Going On: #WTH Russia Eyes Georgia Next. David Kramer Explains

The Ricochet Audio Network Superfeed

Play Episode Listen Later Jun 20, 2024

hell russia western critics tbilisi david kramer next david

#WTH Russia Eyes Georgia Next. David Kramer Explains

What the Hell Is Going On

Play Episode Listen Later Jun 20, 2024 42:44

Georgia's parliament in Tbilisi recently overrode a presidential veto on a “foreign agents” law that sparked an uproar domestically and from the country's Western allies. Critics decried the legislation—which requires any organization receiving more than 20% of its funding from foreign sources to register as an “agent of foreign influence”—as yet another element in the Russian takeover of the small South Caucasian nation. Russia still occupies 20% of Georgia's territory. Why should Americans care about Russian games in a country of 3 million people? Because for Vladimir Putin, Georgia is just the beginning of his ambitions in Europe. And the Georgian people are among the most pro-American in the region, at one point the second largest troop contributor to our war on al Qaeda. Standing up for Georgia now means avoiding conflict later.David Kramer serves as the Executive Director of the George W. Bush Institute. Prior to joining the Bush Institute, he taught at Florida International University's Steven J. Green School of International and Public Affairs, and served as an Assistant Secretary of State for Europe and Eurasian Affairs. David chairs the board of the Free Russia Foundation and serves on the board of the International Republican Institute.Read the transcript here.

Innovating in Entertainment: UTA President David Kramer's Blueprint for Thriving Amid Industry Disruption

ForbesBooks Radio

Play Episode Listen Later May 21, 2024 33:01

In this episode, Joe sits down with David Kramer, President of the leading global talent, entertainment, sports, and advisory company, United Talent Agency (UTA). David shares his remarkable journey from starting in the UTA mailroom in 1992 to rising through the ranks to become President, offering inspiring insights on perseverance, hard work, and never losing sight of your ambitions. David provides a fascinating inside look at the dramatic evolution of the entertainment industry over the past 30 years that he has witnessed firsthand, from the rise of streaming to the blurring of lines between different verticals like film, TV, publishing, podcasting, and more. He discusses the key to longevity and continuous growth in any career: being innovative, entrepreneurial, and embracing change rather than being set in your ways. David shares his strategies for representing top talent and advising clients to maximize opportunities in today's rapidly shifting media landscape. He also weighs in on the streaming wars, industry consolidation, the importance of great intellectual property, and his outlook on the future of entertainment. It's an inspiring conversation filled with wisdom for anyone seeking career longevity and success in any field.

tv president thriving blueprint amid innovating industry disruption david kramer

Automated Economy and its influence on India's growth (feat. David Kramer)

Web and Mobile App Development (Language Agnostic, and Based on Real-life experience!)

Play Episode Listen Later Feb 24, 2024 78:13

In this podcast episode, ⁠Kramer⁠ discusses his recent travels and the evolution of automation in traditional services. He highlights the excitement of witnessing the accelerated adoption of automation in different countries. The conversation then shifts to the most delicious vegetarian food in New Zealand. The hosts recap the previous podcast and set the context for the discussion on solving problems in the automated economy. They explore the changing perspectives on working for large organizations and the importance of passion and curiosity in problem-solving. The value of creativity in finding solutions and the potential of applying solutions from one country to another are also discussed. Takeaways The automated economy is rapidly evolving, with traditional services being hyper-automated and integrated into the digital economy. Entrepreneurs should be passionate about the problems they want to solve and think outside the box to find innovative solutions. Creativity is crucial in problem-solving, even when solutions have been developed elsewhere. Each solution should be tailored to the specific context and needs of the target market. The automated economy offers opportunities for entrepreneurs to solve problems and generate income in ways that were not possible before. The automated economy enables more fluid and efficient economic transactions, allowing entrepreneurs to solve problems and accelerate payment systems. Entrepreneurs can build solutions for other countries without physical presence, leveraging technology and digital enablement. Localization is crucial in building successful solutions, considering cultural norms, economic conditions, and ethical considerations. Understanding the transactional states and evolving solutions based on market conditions are key to success in the automated economy. Long-term business strategy should focus on embracing automation, hyper-personalization, and data-driven decisions. Chapters 00:00 Introduction and Travel Experiences 01:16 The Evolution of Automation in Traditional Services 03:21 Delicious Vegetarian Food in New Zealand 04:41 Recap of Previous Podcast and Context Setting 07:06 Changing Perspectives on Working for Large Organizations 08:01 Identifying Problems to Solve in the Automated Economy 08:30 The Importance of Passion and Curiosity in Problem Solving 09:29 Understanding the Automated Economy and Applying Knowledge 10:22 Solving Problems in the Retail Sales Space 12:18 Taking Solutions from One Country to Another 13:47 Gaining Knowledge and Thinking Outside the Box 15:39 Applying Solutions to Similar Problems in Different Economies 19:10 Solving Problems Locally vs. Being Creative 22:24 The Importance of Passion and Creativity in Problem Solving 23:42 The Nuances of Localizing Solutions 25:29 The Significance of Creativity in Solution Building 28:32 The Value of Innovation in Problem Solving 30:12 The Similarity and Uniqueness of Problems and Solutions 34:52 The Differences in Problem Solving Across Economies 36:45 The Potential of Solving Problems in Different Nations 38:15 Solving Economic Transactions 41:31 Food Delivery in Different Cultures 42:49 Building Solutions Without Physical Presence 44:44 Mitigating Mistakes in Global Business 45:26 Understanding the Transactional States 46:24 Evolving Solutions for Different Markets 47:40 Long-Term Business Strategy in the Automated Economy 48:41 Taking Advantage of Automation 50:07 Ethics and Localization in Building Solutions 53:04 Impact of Automated Economy on Other Industries 56:32 Importance of Localization in Solutions 01:00:32 Automated Economy in India Cooperative Computing: LinkedIn: ⁠⁠⁠⁠David Kramer⁠⁠⁠⁠ ⁠⁠⁠⁠Company Website⁠⁠⁠⁠ "⁠⁠⁠⁠How AI is Disrupting Traditional Business Models⁠⁠⁠⁠" Snowpal's Products: Backends as Services on ⁠⁠⁠⁠⁠⁠⁠⁠⁠AWS Marketplace⁠⁠⁠⁠⁠⁠⁠⁠⁠ Mobile Apps on ⁠⁠⁠⁠⁠⁠⁠⁠⁠App Store⁠⁠⁠⁠⁠⁠⁠⁠⁠ and ⁠⁠⁠⁠⁠⁠⁠⁠⁠Play Store⁠⁠⁠⁠⁠⁠⁠⁠⁠ ⁠⁠⁠⁠⁠⁠⁠⁠⁠Web App⁠⁠⁠⁠⁠⁠⁠⁠⁠ ⁠⁠⁠Education Platform⁠⁠⁠⁠⁠⁠⁠⁠⁠ for Learners and Course Creators

Automated Economy Series (4/N): Impact of Automated Economy on Global Economic Growth (feat. David Kramer)

Web and Mobile App Development (Language Agnostic, and Based on Real-life experience!)

Play Episode Listen Later Jan 20, 2024 89:26

In this episode, Krish and Kramer discuss the impact of the automated economy on global economic growth. They explore the differences in the adoption of automated economy between countries and the role of culture in this process. They also identify the countries that are likely to have the largest impact on the automated economy, including India, African countries, South Asian countries, and Latin American countries. The conversation explores the impact of the automated economy on different countries and regions. It discusses the growth potential of India, Africa, South Asia, Latin America, China, Europe, Australia, and New Zealand. The chapters also highlight the relationship between GDP and the automated economy. They explore the contribution of automated economy to GDP growth and how it is not directly proportional. They also discuss the importance of the percentage of automated economy and its contribution to GDP. Additionally, they delve into the concept of accelerating economic growth through automation and how the growth potential of an economy is directly proportional to the level of automation. Finally, they summarize the key takeaways, including the role of automated economy in driving economic growth and the importance of understanding the cultural and political perspectives. Takeaways The automated economy is driving global economic growth, with the GDP generated from the automated economy increasing from $13.5 trillion in 2018 to $53.3 trillion in 2022. The adoption of automated economy varies between countries, with factors such as disposable income, government support, and cultural readiness playing a role. Countries like India, African countries, South Asian countries, and Latin American countries have the potential for significant growth in the automated economy. The growth of the automated economy is driven by consumer demand for convenience and personalization, as well as the ability of businesses and governments to implement and support automation. India has a high growth capability due to automation and a focus on middle-income growth. Africa has the potential to become a stellar growth region, but disposable income growth may hinder its economic impact. China may struggle with middle-income growth, resulting in a lower impact from the automated economy. Latin America has the economic capability for growth, but cultural adoption may slow down the impact of automation. The growth potential of different countries and regions is not directly proportional to their GDP. The contribution of automated economy to GDP growth is not directly proportional. The percentage of automated economy and its contribution to GDP is an important factor to consider. Automation can accelerate economic growth by increasing the expansion capability of an economy. The growth potential of an economy is directly proportional to the level of automation. Chapters 00:00 Introduction 11:03 Differences in Automated Economy between Countries 19:14 Culture and Automated Economy 35:27 Countries with the Largest Impact on Automated Economy 42:55 The Impact of the Automated Economy on Different Countries 44:20 China's Struggle with Middle Income Growth 45:38 India's Growth Capability Due to Automation 48:01 The Growth Potential of Latin America 53:23 The Growth Potential of Western & Rest of Europe 55:02 The Growth Potential of Australia & New Zealand 58:02 The Impact of GDP & Automated Economy 01:20:03 Accelerating Economic Growth through Automation 01:23:12 Summary Snowpal Products Backends as Services on ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠AWS Marketplace⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠ Mobile Apps on ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠App Store⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠ and ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠Play Store⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠ ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠Web App⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠ ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠Education Platform⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠ for Learners and Course Creators

The Kramer Series (3/N): Education in Automated Economy (feat. David Kramer)

Web and Mobile App Development (Language Agnostic, and Based on Real-life experience!)

Play Episode Listen Later Dec 29, 2023 71:45

The conversation explores the transformation of education and the future of learning. It discusses the role of research and research communities in shaping education. The importance of a well-rounded education and the need to adapt to market needs are highlighted. The conversation also delves into how real-time education will change and the potential disruption of the traditional education system. The role of humans in future education is examined, along with the vision for a more personalized and automated learning experience. An anecdote is shared to illustrate the challenges in traditional education. In this conversation, Krish and David discuss the impact of automation and AI on education. They explore the challenges and benefits of personalization in learning, as well as the potential loss of the human element. They also discuss the importance of building trust with digital entities and the future of education in a hyper-personalized world. They touch on the balance between automation and human interaction, using the example of playing chess. Ultimately, they emphasize the need to embrace change and make choices that prioritize the things that truly matter. Takeaways Education is undergoing a transformation, driven by advancements in technology and the need to adapt to market demands. Research and research communities play a crucial role in shaping the future of education. Real-time education and personalized learning experiences will become the norm. The traditional education system is likely to be disrupted, leading to new models and approaches. The role of humans in education will evolve, with digital technologies and automation playing a significant role. Automation and AI have the potential to dramatically change education, offering personalized learning experiences. While personalization can enhance learning, it may also lead to a loss of the human element in education. Building trust with digital entities is crucial in a hyper-personalized world. The future of education will involve a balance between automation and human interaction. Chapters 00:00 Introduction and Setting the Stage 00:53 Transformation of Education: Research and Research Communities 06:31 Well-Rounded Education and Adapting to Market Needs 11:25 Interacting with Real-Time Education 19:47 Disruption of Traditional Education System 30:49 The Role of Humans in Future Education 41:10 Research, Training, and Execution in Education 46:07 The Vision for Future Education 47:31 Anecdote: Challenges in Traditional Education 48:01 Introduction to Advanced Calculus 49:26 The Challenge of Personalization 50:26 The Potential Lack of Human Element 51:31 Building Trust with Digital Entities 52:29 Interacting with Teachers in a Hyper-Personalized World 53:52 The Future of Education and Personalization 55:25 The Balance Between Automation and Human Interaction 56:52 The Example of Playing Chess 57:22 The Importance of Human Personalization 01:03:17 Finding a Balance in a Changing World 01:06:00 Embracing Change and Making Choices 01:10:42 Prioritizing the Things That Matter Snowpal Products: Backends as Services on ⁠⁠⁠⁠⁠AWS Marketplace⁠⁠⁠⁠⁠ Mobile Apps on ⁠⁠⁠⁠⁠App Store⁠⁠⁠⁠⁠ and ⁠⁠⁠⁠⁠Play Store⁠⁠⁠⁠⁠ ⁠⁠⁠⁠⁠Web App⁠⁠⁠⁠⁠ ⁠⁠⁠⁠⁠Education Platform⁠⁠⁠⁠⁠ for Learners and Course Creators

AI in Automated Economy (feat. David Kramer)

Web and Mobile App Development (Language Agnostic, and Based on Real-life experience!)

Play Episode Listen Later Dec 24, 2023 48:24

In this conversation, Kramer discusses the role of AI in the automated economy and its impact on various industries. He explains how AI can process large amounts of data and make logical decisions, leading to advancements in automation and personalization. Kramer also explores the changing roles in different sectors and the emergence of new roles in the digital era. He highlights the importance of understanding the art of the possible and adapting to the new ways of working. Additionally, he touches on the transformation of education and the need for thought leadership in embracing AI. In this conversation, Krish and Kramer discuss the importance of human-written content and the challenges of finding it in a world filled with automated content. They also explore the value of conversational content and how Snowpals plays a role in content creation. Takeaways AI enables the processing of large amounts of data and logical decision-making, leading to automation and personalization. Roles in various industries will change as AI takes over mundane tasks and humans focus on more specialized and creative roles. The future of education will involve a shift in how knowledge is acquired and certified, with a focus on skills and real-time learning. Understanding the art of the possible and embracing new ways of working is crucial for adapting to the digital era. Human-written content is valuable because it provides a personal connection and unique perspective. Finding human-written content can be challenging due to the abundance of automated content. Conversational content is valuable because it captures authentic and engaging discussions. Snowpal helps create high-quality human-written content for businesses. Chapters 00:00 Introduction and AI in the Automated Economy 04:06 Advancements in AI and Cognitive Capability 10:28 Role Mapping in the Automated Economy 17:08 The Impact of AI on the Restaurant Industry 27:30 The Future of Education in the AI Era 42:16 The Transformation of Education 45:43 Closing Thoughts on Role Definition and Ways of Working 10:30 The Importance of Human-Written Content 20:15 The Challenges of Finding Human-Written Content 30:45 The Value of Conversational Content 40:00 The Role of Snowpals in Content Creation 46:45 Conclusion #snowpal #cooperativecomputing Cooperative Computing: LinkedIn: ⁠David Kramer⁠ ⁠Company Website⁠ "⁠How AI is Disrupting Traditional Business Models⁠" Snowpal Products: Backends as Services on ⁠⁠⁠⁠⁠AWS Marketplace⁠⁠⁠⁠⁠ Mobile Apps on ⁠⁠⁠⁠⁠App Store⁠⁠⁠⁠⁠ and ⁠⁠⁠⁠⁠Play Store⁠⁠⁠⁠⁠ ⁠⁠⁠⁠⁠Web App⁠⁠⁠⁠⁠ ⁠⁠⁠⁠⁠Education Platform⁠⁠⁠⁠⁠ for Learners and Course Creators

Automated Economy: Fundamentals, Key Attributes, and What the future holds (feat. David Kramer)

Web and Mobile App Development (Language Agnostic, and Based on Real-life experience!)

Play Episode Listen Later Dec 18, 2023 69:50

In this conversation, Kramer discusses the role of AI in the automated economy and its impact on various industries. He explains how AI can process large amounts of data and make logical decisions, leading to advancements in automation and personalization. Kramer also explores the changing roles in different sectors and the emergence of new roles in the digital era. He highlights the importance of understanding the art of the possible and adapting to the new ways of working. Additionally, he touches on the transformation of education and the need for thought leadership in embracing AI. In this conversation, Krish and Kramer discuss the importance of human-written content and the challenges of finding it in a world filled with automated content. They also explore the value of conversational content and how Snowpals plays a role in content creation. Takeaways AI enables the processing of large amounts of data and logical decision-making, leading to automation and personalization. Roles in various industries will change as AI takes over mundane tasks and humans focus on more specialized and creative roles. The future of education will involve a shift in how knowledge is acquired and certified, with a focus on skills and real-time learning. Understanding the art of the possible and embracing new ways of working is crucial for adapting to the digital era. Human-written content is valuable because it provides a personal connection and unique perspective. Finding human-written content can be challenging due to the abundance of automated content. Conversational content is valuable because it captures authentic and engaging discussions. Snowpals helps create high-quality human-written content for businesses. Chapters 00:00 Introduction and AI in the Automated Economy 04:06 Advancements in AI and Cognitive Capability 10:28 Role Mapping in the Automated Economy 17:08 The Impact of AI on the Restaurant Industry 27:30 The Future of Education in the AI Era 42:16 The Transformation of Education 45:43 Closing Thoughts on Role Definition and Ways of Working 10:30 The Importance of Human-Written Content 20:15 The Challenges of Finding Human-Written Content 30:45 The Value of Conversational Content 40:00 The Role of Snowpals in Content Creation 46:45 Conclusion #snowpal #cooperativecomputing Cooperative Computing: LinkedIn: ⁠David Kramer⁠ ⁠Company Website⁠ "⁠How AI is Disrupting Traditional Business Models⁠" Snowpal's Products: Backends as Services on ⁠⁠⁠AWS Marketplace⁠⁠⁠ Mobile Apps on ⁠⁠⁠App Store⁠⁠⁠ and ⁠⁠⁠Play Store⁠⁠⁠ ⁠⁠⁠Web App⁠⁠⁠

Mike Perham on Keeping it solo (RubyConf 2023)

Software Sessions

Play Episode Listen Later Nov 21, 2023 51:26

Mike Perham is the creator of Sidekiq, a background job processor for Ruby. He's also the creator of Faktory a similar product for multiple language environments. We talk about the RubyConf keynote and Ruby's limitations, supporting products as a solo developer, and some ideas for funding open source like a public utility. Recorded at RubyConf 2023 in San Diego. -- A few topics covered: Sidekiq (Ruby) vs Faktory (Polyglot) Why background job solutions are so common in Ruby Global Interpreter Lock (GIL) Ractors (Actor concurrency) Downsides of Multiprocess applications When to use other languages Getting people to pay for Sidekiq Keeping a solo business Being selective about customers Ways to keep support needs low Open source as a public utility Mike Mike's blog mastodon Sidekiq faktory From Employment to Independence Ruby Ractor The Practical Effects of the GVL on Scaling in Ruby Transcript You can help correct transcripts on GitHub. Introduction [00:00:00] Jeremy: I'm here at RubyConf San Diego with Mike Perham. He's the creator of Sidekiq and Faktory. [00:00:07] Mike: Thank you, Jeremy, for having me here. It's a pleasure. Sidekiq [00:00:11] Jeremy: So for people who aren't familiar with, I guess we'll start with Sidekiq because I think that's what you're most known for. If people don't know what it is, maybe you can give like a small little explanation. [00:00:22] Mike: Ruby apps generally have two major pieces of infrastructure powering them. You've got your app server, which serves your webpages and the browser. And then you generally have something off on the side that... It processes, you know, data for a million different reasons, and that's generally called a background job framework, and that's what Sidekiq is. [00:00:41] It, Rails is usually the thing that, that handles your web stuff, and then Sidekiq is the Sidekiq to Rails, so to speak. [00:00:50] Jeremy: And so this would fit the same role as, I think in Python, there's celery. and then in the Ruby world, I guess there is, uh, Resque is another kind of job. [00:01:02] Mike: Yeah, background job frameworks are quite prolific in Ruby. the Ruby community's kind of settled on that as the, the standard pattern for application development. So yeah, we've got, a half a dozen to a dozen different, different examples throughout history, but the major ones today are, Sidekiq, Resque, DelayedJob, GoodJob, and, and, and others down the line, yeah. Why background jobs are so common in Ruby [00:01:25] Jeremy: I think working in other languages, you mentioned how in Ruby, there's this very clear, preference to use these job scheduling systems, these job queuing systems, and I'm not. I'm not sure if that's as true in, say, if somebody's working in Java, or C sharp, or whatnot. And I wonder if there's something specific about Ruby that makes people kind of gravitate towards this as the default thing they would use. [00:01:52] Mike: That's a good question. What makes Ruby... The one that so needs a background job system. I think Ruby, has historically been very single threaded. And so, every Ruby process can only do so much work. And so Ruby oftentimes does, uh, spin up a lot of different processes, and so having processes that are more focused on one thing is, is, is more standard. [00:02:24] So you'll have your application server processes, which focus on just serving HTTP responses. And then you have some other sort of focused process and that just became background job processes. but yeah, I haven't really thought of it all that much. But, uh, you know, something like Java, for instance, heavily multi threaded. [00:02:45] And so, and extremely heavyweight in terms of memory and startup time. So it's much more frequent in Java that you just start up one process and that's it. Right, you just do everything in that one process. And so you may have dozens and dozens of threads, both serving HTTP and doing work on the side too. Um, whereas in Ruby that just kind of naturally, there was a natural split there. Global Interpreter Lock [00:03:10] Jeremy: So that's actually a really good insight, because... in the keynote at RubyConf, Mats, the creator of Ruby, you know, he mentioned the, how the fact that there is this global, interpreter lock, [00:03:23] or, or global VM lock in Ruby, and so you can't, really do multiple things in parallel and make use of all the different cores. And so it makes a lot of sense why you would say like, okay, I need to spin up separate processes so that I can actually take advantage of, of my, system. [00:03:43] Mike: Right. Yeah. And the, um, the GVL. is the acronym we use in the Ruby community, or GIL. Uh, that global lock really kind of is a forcing function for much of the application architecture in Ruby. Ruby, uh, applications because it does limit how much processing a single Ruby process can do. So, uh, even though Sidekiq is heavily multi threaded, you can only have so many threads executing. [00:04:14] Because they all have to share one core because of that global lock. So unfortunately, that's, that's been, um, one of the limiter, limiting factors to Sidekiq scalability is that, that lock and boy, I would pay a lot of money to just have that lock go away, but. You know, Python is going through a very long term experiment about trying to remove that lock and I'm very curious to see how well that goes because I would love to see Ruby do the same and we'll see what happens in the future, but, it's always frustrating when I come to another RubyConf and I hear another Matt's keynote where he's asked about the GIL and he continues to say, well, the GIL is going to be around, as long as I can tell. [00:04:57] so it's a little bit frustrating, but. It's, it's just what you have to deal with. Ractors [00:05:02] Jeremy: I'm not too familiar with them, but they, they did mention during the keynote I think there Ractors or something like that. There, there, there's some way of being able to get around the GIL but there are these constraints on them. And in the context of Sidekiq and, and maybe Ruby in general, how do you feel about those options or those solutions? [00:05:22] Mike: Yeah, so, I think it was Ruby 3. 2 that introduced this concept of what they call a Ractor, which is like a thread, except it does not have the global lock. It can run independent to the global lock. The problem is, is because it doesn't use the global lock, it has pretty severe constraints on what it can do. [00:05:47] And the, and more specifically, the data it can access. So, Ruby apps and Rails apps throughout history have traditionally accessed a lot of global data, a lot of class level data, and accessed all this data in a, in a read only fashion. so there's no race conditions because no one's changing any of it, but it's still, lots of threads all accessing the same variables. [00:06:19] Well, Ractors can't do that at all. The only data Ractors can access is data that they own. And so that is completely foreign to Ruby application, traditional Ruby applications. So essentially, Ractors aren't compatible with the vast majority of existing Ruby code. So I, I, I toyed with the idea of prototyping Sidekiq and Ractors, and within about a minute or two, I just ran into these, these, uh... [00:06:51] These very severe constraints, and so that's why you don't see a lot of people using Ractors, even still, even though they've been out for a year or two now, you just don't see a lot of people using them, because they're, they're really limited, limited in what they can do. But, on the other hand, they're unlimited in how well they can scale. [00:07:12] So, we'll see, we'll see. Hopefully in the future, they'll make a lot of improvements and, uh, maybe they'll become more usable over time. Downsides of multiprocess (Memory usage) [00:07:19] Jeremy: And with the existence of a job queue or job scheduler like Sidekiq, you're able to create additional processes to get around that global lock, I suppose. What are the... downsides of doing so versus another language like we mentioned Java earlier, which is capable of having true parallelism in the same process. [00:07:47] Mike: Yeah, so you can start up multiple Ruby processes to process things truly in parallel. The issue is that you do get some duplication in terms of memory. So your Ruby app maybe take a gigabyte per process. And, you can do copy on write forking. You can fork and get some memory sharing with copy on write semantics on Unix operating systems. [00:08:21] But you may only get, let's say, 30 percent memory savings. So, there's still a significant memory overhead to forking, you know, let's say, eight processes versus having eight threads. You know, you, you, you may have, uh, eight threads can operate in a gigabyte process, but if you want to have eight processes, that may take, let's say, four gigabytes of RAM. [00:08:48] So you, you still, it's not going to cost you eight gigabytes of RAM, you know, it's not like just one times eight, but, there's still a overhead of having those separate processes. [00:08:58] Jeremy: would you say it's more of a cost restriction, like it costs you more to run these applications, or are there actual problems that you can't solve because of this restriction. [00:09:13] Mike: Help me understand, what do you mean by restriction? Do you mean just the GVL in general, or the fact that forking processes still costs memory? [00:09:22] Jeremy: I think, well, it would be both, right? So you're, you have two restrictions right now. You have the, the GVL, which means you can't have parallelism within the same process. And then your other option is to spin up a bunch of processes, which you have said is the downside there is that you're using a lot more RAM. [00:09:43] I suppose my question is that Does that actually stop you from doing anything? Like, if you throw more money at the problem, you go like, we're going to have more instances, I'll pay for the RAM, it's fine, can that basically get you out of these situations or are these limitations actually stopping you from, from doing things you could do in other languages? [00:10:04] Mike: Well, you certainly have to manage the multiple processes, right? So you've gotta, you know, if one child process crashes, you've gotta have a parent or supervisor process watching all that and monitoring and restarting the process. I don't think it restricts you. Necessarily, it just, it adds complexity to your deployment. [00:10:24] and, and it's just a question of efficiency, right? Instead of being able to deploy on a, on a one gigabyte droplet, I've got to deploy to a four gigabyte droplet, right? Because I just, I need the RAM to run the eight processes. So it, it, it's more of just a purely a function of how much money am I going to have to throw at this problem. [00:10:45] And what's it going to cost me in operational costs to operate this application in production? When to use other languages? [00:10:53] Jeremy: So during the. Keynote, uh, Matz had mentioned that Rails, is really suitable as this one person framework, like you can have a very small team or maybe even yourself and, and build this product. And so I guess from... Your perspective, once you cross a certain threshold, is like, what Ruby and what Sidekiq provides not enough, and that's why you need to start looking into other languages? [00:11:24] Or like, where's the, turning point, or the, if you [00:11:29] Mike: Right, right. The, it's all about the problem you're trying to solve, right? At the end of the day, uh, the, the question is just what are we trying to solve and how are we trying to solve it? So at a higher level, you got to think about the architecture. if the problem you're trying to solve, if the service you're trying to build, if the app you're trying to operate. [00:11:51] If that doesn't really fall into the traditional Ruby application architecture, then you, you might look at it in another language or another ecosystem. something like Go, for instance, can compile down to a single binary, which makes deployment really easy. It makes shipping up a product. on to a user's machine, much simpler than deploying a Ruby application onto a user's desktop machine, for instance, right? [00:12:22] Um, Ruby does have this, this problem of how do you package everything together and deploy it somewhere? Whereas Go, when you can just compile to a single binary, now you've just got a single thing. And it's just... Drop it on the file system and execute it. It's easy. So, um, different, different ecosystems have different application architectures, which empower different ways of solving the same problems. [00:12:48] But, you know, Rails as a, as a one man framework, or sorry, one person framework, It, it, I don't, I don't necessarily, that's a, that's sort of a catchy marketing slogan, but I just think of Rails as the most productive framework you can use. So you, as a single person, you can maximize what you ship and the, the, the value that you can create because Rails is so productive. [00:13:13] Jeremy: So it, seems like it's maybe the, the domain or the type of application you're making. Like you mentioned the command line application, because you want to be able to deliver it to your user easily. Just give them a binary, something like Go or perhaps Rust makes a lot more sense. and then I could see people saying that if you're doing something with machine learning, like the community behind Python, it's, they're just, they're all there. [00:13:41] So Room for more domains in Ruby [00:13:41] Mike: That was exactly the example I was going to use also. Yeah, if you're doing something with data or AI, Python is going to be a more, a more traditional, natural choice. that doesn't mean Ruby can't do it. That doesn't mean, you wouldn't be able to solve the problem with Ruby. And, and there's, that just also means that there's more space for someone who wants to come in and make an impact in the Ruby community. [00:14:03] Find a problem that Ruby's not really well suited to solving right now and build the tooling out there to, to try and solve it. You know, I, I saw a talk, from the fellow who makes the Glimmer gem, which is a native UI toolkit. Uh, a gem for building native UIs in Ruby, which Ruby traditionally can't do, but he's, he's done an amazing job at sort of surfacing APIs to build these, um, these native, uh, native applications, which I think is great. [00:14:32] It's awesome. It's, it's so invigorating to see Ruby in a new space like that. Um, I talked to someone else who's doing the Polars gem, which is focused on data processing. So it kind of takes, um, Python and Pandas and brings that to Ruby, which is, is awesome because if you're a Ruby developer, now you've got all these additional tools which can allow you to solve new sets of problems out there. [00:14:57] So that's, that's kind of what's exciting in the Ruby community right now is just bring it into new spaces. Faktory [00:15:03] Jeremy: In addition to Sidekiq, you have, uh, another product called Faktory, I believe. And so does that serve a, a similar purpose? Is that another job scheduling, job queueing system? [00:15:16] Mike: It is, yes. And it's, it's, it's similar in a way to Sidekiq. It looks similar. It's got similar concepts at the core of it. At the end of the day, Sidekiq is limited to Ruby. Because Sidekiq executes in a Ruby VM, it executes the jobs, and the jobs are, have to be written in Ruby because you're running in the Ruby VM. [00:15:38] Faktory was my attempt to bring, Sidekiq functionality to every other language. I wanted, I wanted Sidekiq for JavaScript. I wanted Sidekiq for Go. I wanted Sidekiq for Python because A, a lot of these other languages also could use a system, a background job system. And the problem though is that. [00:16:04] As a single man, I can't port Sidekiq to every other language. I don't know all the languages, right? So, Faktory kind of changes the architecture and, um, allows you to execute jobs in any language. it, it replaces Redis and provides a server where you just fetch jobs, and you can use it from it. [00:16:26] You can use that protocol from any language to, to build your own worker processes that execute jobs in whatever language you want. [00:16:35] Jeremy: When you say it replaces Redis, so it doesn't use Redis, um, internally, it has its own. [00:16:41] Mike: It does use Redis under the covers. Yeah, it starts Redis as a child process and, connects to it over a Unix socket. And so it's really stable. It's really fast. from the outside, the, the worker processes, they just talk to Faktory. They don't know anything about Redis at all. [00:16:59] Jeremy: I see. And for someone who, like we mentioned earlier in the Python community, for example, there is, um, Celery. For someone who is using a task scheduler like that, what's the incentive to switch or use something different? [00:17:17] Mike: Well, I, I always say if you're using something right now, I'm not going to try and convince you to switch necessarily. It's when you have pain that you want to switch and move away. Maybe you have Maybe there's capabilities in the newer system that you really need that the old system doesn't provide, but Celery is such a widely known system that I'm not necessarily going to try and convince people to move away from it, but if people are looking for a new system, one of the things that Celery does that Faktory does not do is Celery provides like data adapters for using store, lots of different storage systems, right? [00:17:55] Faktory doesn't do that. Faktory is more, has more of the Rails mantra of, you know, Omakase where we choose, I choose to use Redis and that's it. You don't, you don't have a choice for what to use because who cares, you know, at the end of the day, let Faktory deal with it. it's, it's not something that, You should even necessarily be concerned about it. [00:18:17] Just, just try Faktory out and see how it works for you. Um, so I, I try to take those operational concerns off the table and just have the user focus on, you know, usability, performance, and that sort of thing. but it is, it's, it's another background job system out there for people to try out and see if they like that. [00:18:36] And, and if they want to, um, if they know Celery and they want to use Celery, more power to Faktory them. Sidekiq (Ruby) or Faktory (Polyglot) [00:18:43] Jeremy: And Sidekiq and Faktory, they serve a very similar purpose. For someone who they have a new project, they haven't chosen a job. scheduling system, if they were using Ruby, would it ever make sense for them to use Faktory versus use Sidekiq? [00:19:05] Mike: Uh Faktory is excellent in a polyglot situation. So if you're using multiple languages, if you're creating jobs in Ruby, but you're executing them in Python, for instance, um, you know, if you've, I have people who are, Creating jobs in PHP and executing them in Python, for instance. That kind of polyglot scenario, Sidekiq can't do that at all. [00:19:31] So, Faktory is useful there. In terms of Ruby, Ruby is just another language to Faktory. So, there is a Ruby API for using Faktory, and you can create and execute Ruby jobs with Faktory. But, you'll find that in the Ruby community, Sidekiq is much widely... much more widely used and understood and known. So if you're just using Ruby, I think, I think Sidekiq is the right choice. [00:19:59] I wouldn't look at Faktory. But if you do need, find yourself needing that polyglot tool, then Faktory is there. Temporal [00:20:07] Jeremy: And this is maybe one, maybe one layer of abstraction higher, but there's a product called Temporal that has some of this job scheduling, but also this workflow component. I wonder if you've tried that out and how you think about that product? [00:20:25] Mike: I've heard of them. I don't know a lot about the product. I do have a workflow API, the Sidekiq batches, which allow you to fan out jobs and then, and then execute callbacks when all the jobs in that, in that batch are done. But I don't, provide sort of a, a high level. Graphical Workflow Editor or anything like that. [00:20:50] Those to me are more marketing tools that you use to sell the tool for six figures. And I don't think they're usable. And I don't think they're actually used day to day. I provide an API for developers to use. And developers don't like moving blocks of code around in a GUI. They want to write code. And, um, so yeah, temporal, I, like I said, I don't know much about them. [00:21:19] I also, are they a venture capital backed startup? [00:21:22] Jeremy: They are, is my understanding, [00:21:24] Mike: Yeah, that, uh, any, any sort of venture capital backed startup, um, who's building technical infrastructure. I, I would look long and hard at, I'm, I think open source is the right core to build on. Of course I sell commercial software, but. I'm bootstrapped. I'm profitable. [00:21:46] I'm going to be around forever. A VC backed startup, they tend to go bankrupt, because they either get big or they go out of business. So that would be my only comment is, is, be a little bit leery about relying on commercial venture capital based infrastructure for, for companies, uh, long term. Getting people to pay for Sidekiq [00:22:05] Jeremy: So I think that's a really interesting part about your business is that I think a lot of open source maintainers have a really big challenge figuring out how to make it as a living. The, there are so many projects that they all have a very permissive license and you can use them freely one example I can think of is, I, I talked with, uh, David Kramer, who's the CTO at Sentry, and he, I don't think they use it anymore, but they, they were using Nginx, right? [00:22:39] And he's like, well, Nginx, they have a paid product, like Nginx. Plus that or something. I don't know what the name is, but he was like, but I'm not going to pay for it. Right. I'm just going to use the free one. Why would I, you know, pay for the, um, the paid thing? So I, I, I'm kind of curious from your perspective when you were coming up with Sidekiq both as an open source product, but also as a commercial one, how did you make that determination of like to make a product where it's going to be useful in its open source form? [00:23:15] I can still convince people to pay money for it. [00:23:19] Mike: Yeah, the, I was terrified, to be blunt, when I first started out. when I started the Sidekiq project, I knew it was going to take a lot of time. I knew if it was successful, I was going to be doing it for the next decade. Right? So I started in 2012, and here I am in 2023, over a decade, and I'm still doing it. [00:23:38] So my expectation was met in that regard. And I knew I was not going to be able to last that long. If I was making zero dollars, right? You just, you burn out. Nobody can last that long. Well, I guess there are a few exceptions to that rule, but yeah, money, I tend to think makes things a little more sustainable for sure. [00:23:58] Especially if you can turn it into a full time job solving and supporting a project that you, you love and, and is, is, you know, your, your, your baby, your child, so to speak, your software, uh, uh, creation that you've given to the world. but I was terrified. but one thing I did was at the time I was blogging a lot. [00:24:22] And so I was telling people about Sidekiq. I was telling people what was to come. I was talking about ideas and. The one thing that I blogged about was financial experiments. I said bluntly to the, to, to the Ruby community, I'm going to be experimenting with financial stability and sustainability with this project. [00:24:42] So not only did I create this open source project, but I was also publicly saying I I need to figure out how to make this work for the next decade. And so eventually that led to Sidekiq Pro. And I had to figure out how to build a closed source Ruby gem, which, uh, There's not a lot of, so I was kind of in the wild there. [00:25:11] But, you know, thankfully all the pieces came together and it was actually possible. I couldn't have done it if it wasn't possible. Like, we would not be talking if I couldn't make a private gem. So, um, but it happened to work out. Uh, and it allowed me to, to gate features behind a paywall effectively. And, and yeah, you're right. [00:25:33] It can be tough to make people pay for software. but I'm a developer who's selling to other developers, not, not just developers, open source developers, and they know that they have this financial problem, right? They know that there's this sustainability problem. And I was blunt in saying, this is my solution to my sustainability. [00:25:56] So, I charge what I think is a very fair price. It's only a thousand dollars a year to a hobbyist. That may seem like a lot of money to a business. It's a drop in the bucket. So it was easy for developers to say, Hey, listen, we want to buy this tool for a thousand bucks. It'll ensure our infrastructure is maintained for the next decade. [00:26:18] And it's, and it's. And it's relatively cheap. It's way less than, uh, you know, a salary or even a laptop. So, so that's, that's what I did. And, um, it's, it worked out great. People, people really understood. Even today, I talk to people and they say, we, we signed up for Sidekiq Pro to support you. So it's, it's, it's really, um, invigorating to hear people, uh, thank me and, and they're, they're actively happy that they're paying me and our customers. [00:26:49] Jeremy: it's sort of, uh, maybe a not super common story, right, in terms of what you went through. Because when I think of open core businesses, I think of companies like, uh, GitLab, which are venture funded, uh, very different scenario there. I wonder, like, in your case, so you started in 2012, and there were probably no venture backed competitors, right? [00:27:19] People saying that we're going to make this job scheduling system and some VC is going to give me five million dollars and build a team to work on this. It was probably at the time, maybe it was Rescue, which was... [00:27:35] Mike: There was a venture backed system called IronMQ, [00:27:40] Jeremy: Hmm. [00:27:41] Mike: And I'm not sure if they're still around or not, but they... They took, uh, one or more funding rounds. I'm not sure exactly, but they were VC backed. They were doing, background jobs, scheduled jobs, uh, you know, running container, running container jobs. They, they eventually, I think, wound up sort of settling on Docker containers. [00:28:06] They'll basically spin up a Docker container. And that container can do whatever it wants. It can execute for a second and then shut down, or it can run for, for however long, but they would, um, yeah, I, yeah, I'll, I'll stop there because I don't know the actual details of exactly their system, but I'm not sure if they're still around, but that's the only one that I remember offhand that was around, you know, years ago. [00:28:32] Yeah, it's, it's mostly, you know, low level open source infrastructure. And so, anytime you have funded startups, they're generally using that open source infrastructure to build their own SaaS. And so SaaS's are the vast majority of where you see sort of, uh, commercial software. [00:28:51] Jeremy: so I guess in that way it, it, it gave you this, this window or this area where you could come in and there wasn't, other than that iron, product, there wasn't this big money that you were fighting against. It was sort of, it was you telling people openly, I'm, I'm working on this thing. [00:29:11] I need to make money so that I can sustain it. And, if you, yeah. like the work I do, then, you know, basically support me. Right. And, and so I think that, I'm wondering how we can reproduce that more often because when you see new products, a lot of times it is VC backed, right? [00:29:35] Because people say, I need to work on this. I need to be paid. and I can't ask a team to do this. For nothing, right? So [00:29:44] Mike: Yeah. It's. It's a wicked problem. Uh, it's a really, really hard problem to solve if you take vc you there, that that really kind of means that you need to be making tens if not hundreds of millions of dollars in sales. If you are building a small or relatively small. You know, put small in quotes there because I don't really know what that means, but if you have a small open source project, you can't charge huge amounts for it, right? [00:30:18] I mean, Sidekiq is a, I would call a medium sized open source project, and I'm charging a thousand bucks for it. So if you're building, you know, I don't know, I don't even want to necessarily give example, but if you're building some open source project, and It's one of 300 libraries that people's applications will depend on. [00:30:40] You can't necessarily charge a thousand dollars for that library. depending on the size and the capabilities, maybe you can, maybe you can't. But there's going to be a long tail of open source projects that just, they can't, they can't charge much, if anything, for them. So, unfortunately, we have, you know, these You kind of have two pathways. [00:31:07] Venture capital, where you've got to sell a ton, or free. And I've kind of walked that fine line where I'm a small business, I can charge a small amount because I'm bootstrapped. And, and I don't need huge amounts of money, and I, and I have a project that is of the right size to where I can charge a decent amount of money. [00:31:32] That means that I can survive with 500 or a thousand customers. I don't need to have a hundred million dollars worth of customers. Because I, you know, when I started the business, one of the constraints I said is I don't want to hire anybody. I'm just going to be solo. And part of the, part of my ability to keep a low price and, and keep running sustainably, even with just You know, only a few hundred customers is because I'm solo. [00:32:03] I don't have the overhead of investors. I don't have the overhead of other employees. I don't have an office space. You know, my overhead is very small. So that is, um, you know, I just kind of have a unique business in that way, I guess you might say. Keeping the business solo [00:32:21] Jeremy: I think that's that's interesting about your business as well But the fact that you've kept it you've kept it solo which I would imagine in most businesses, they need support people. they need, developers outside of maybe just one. Um, there's all sorts of other, I don't think overhead is the right word, but you just need more people, right? [00:32:45] And, and what do you think it is about Sidekiq that's made it possible for it to just be a one person operation? [00:32:52] Mike: There's so much administrative overhead in a business. I explicitly create business policies so that I can run solo. you know, my support policy is officially you get one email ticket or issue per quarter. And, and anything more than that, I can bounce back and say, well, you're, you're requiring too much support. [00:33:23] In reality, I don't enforce that at all. And people email me all the time, but, but things like. Things like dealing with accounting and bookkeeping and taxes and legal stuff, licensing, all that is, yeah, a little bit of overhead, but I've kept it as minimal as I can. And part of that is I don't want to hire another employee because then that increases the administrative overhead that I have. [00:33:53] And Sidekiq is so tied to me and my knowledge that if I hire somebody, they're probably not going to know Ruby and threading and all the intricate technical detail necessary to build and maintain and support the system. And so really you'll kind of regress a little bit. We won't be able to give as good support because I'm busy helping that other employee. Being selective about customers [00:34:23] Mike: So, yeah, it's, it's a tightrope act where you've got to really figure out how can I scale myself as far as possible without overwhelming myself. The, the overwhelming thing that I have that I've never been able to solve. It's just dealing with billing inquiries, customers, companies, emailing me saying, how do we buy this thing? [00:34:46] Can I get an invoice? Every company out there, it seems wants an invoice. And the problem with invoicing is it takes a lot more. manual labor and administrative overhead to issue that invoice to collect payment on the invoice. So that's one of the reasons why I have a very strict policy about credit card only for, for the vast majority of my customers. [00:35:11] And I demand that companies pay a lot more. You have to have a pretty big enterprise license if you want an invoice. And if the company, if the company comes back and complains and says, well, you know, that's ridiculous. We don't, we don't want to pay that much. We don't need it that much. Uh, you know, I, I say, okay, well then you have two, two things, two, uh, two things. [00:35:36] You can either pay with a credit card or you can not use Sidekiq. Like, that's, that's it. I'm, I don't need your money. I don't want the administrative overhead of dealing with your accounting department. I just want to support my, my customers and build my software. And, and so, yeah, I don't want to turn into a billing clerk. [00:35:55] So sometimes, sometimes the, the, the best thing in business that you can do is just say no. [00:36:01] Jeremy: That's very interesting because I think being a solo... Person is what probably makes that possible, right? Because if you had the additional staff, then you might say like, Well, I need to pay my staff, so we should be getting, you know, as much business as [00:36:19] Mike: Yeah. Chasing every customer you can, right. But yeah. [00:36:22] Every customer is different. I mean, I have some customers that just, they never contact me. They pay their bill really fast or right on time. And they're paying me, you know, five figures, 20, a year. And they just, it's a, God bless them because those are, are the. [00:36:40] Best customers to have and the worst customers are the ones who are paying 99 bucks a month and everything that they don't understand or whatever is a complaint. So sometimes, sometimes you, you want to, vet your customers from that perspective and say, which one of these customers are going to be good? [00:36:58] Which ones are going to be problematic? [00:37:01] Jeremy: And you're only only person... And I'm not sure how many customers you have, but [00:37:08] Mike: I have 2000 [00:37:09] Jeremy: 2000 customers. [00:37:10] Okay. [00:37:11] Mike: Yeah. [00:37:11] Jeremy: And has that been relatively stable or has there been growth [00:37:16] Mike: It's been relatively stable the last couple of years. Ruby has, has sort of plateaued. Um, it's, you don't see a lot of growth. I'm getting probably, um, 15, 20 percent growth maybe. Uh, so I'm not growing like a weed, like, you know, venture capital would want to see, but steady incremental growth is, is, uh, wonderful, especially since I do very little. [00:37:42] Sales and marketing. you know, I come to RubyConf I, I I tweet out, you know, or I, I toot out funny Mastodon Toots occasionally and, and, um, and, and put out new releases of the software. And, and that's, that's essentially my, my marketing. My marketing is just staying in front of developers and, and, and being a presence in the Ruby community. [00:38:06] But yeah, it, it's, uh. I, I, I see not a, not a huge amount of churn, but I see enough sales to, to, to stay up and keep my head above water and to keep growing, um, slowly but surely. Support needs haven't grown [00:38:20] Jeremy: And as you've had that steady growth, has the support burden not grown with it? [00:38:27] Mike: Not as much because once customers are on Sidekiq and they've got it working, then by and large, you don't hear from them all that much. There's always GitHub issues, you know, customers open GitHub issues. I love that. but yeah, by and large, the community finds bugs. and opens up issues. And so things remain relatively stable. [00:38:51] I don't get a lot of the complete newbie who has no idea what they're doing and wants me to, to tell them how to use Sidekiq that I just don't see much of that at all. Um, I have seen it before, but in that case, generally, I, I, I politely tell that person that, listen, I'm not here to educate you on the product. [00:39:14] It's there's documentation in the wiki. Uh, and there's tons of, of more Ruby, generic Ruby, uh, educational material out there. That's just not, not what I do. So, so yeah, by and large, the support burden is, is not too bad because once people are, are up and running, it's stable and, and they don't, they don't need to contact me. [00:39:36] Jeremy: I wonder too, if that's perhaps a function of the price, because if you're a. new developer or someone who's not too familiar with how to do job processing or what they want to do when you, there is the open source product, of course. but then the next step up, I believe is about a hundred dollars a month. [00:39:58] And if you're somebody who is kind of just getting started and learning how things work, you're probably not going to pay that, is my guess. And so you'll never hear from them. [00:40:11] Mike: Right, yeah, that's a good point too, is the open source version, which is what people inevitably are going to use and integrate into their app at first. Because it's open source, you're not going to email me directly, um, and when people do email me directly, Sidekiq support questions, I do, I reply literally, I'm sorry I don't respond to private email, unless you're a customer. [00:40:35] Please open a GitHub issue and, um, that I try to educate both my open source users and my commercial customers to try and stay in GitHub issues because private email is a silo, right? Private email doesn't help anybody else but them. If I can get people to go into GitHub issues, then that's a public record. [00:40:58] that people can search. Because if one person has that problem, there's probably a dozen other people that have that same problem. And then that other, those other 11 people can search and find the solution to their problem at four in the morning when I'm asleep. Right? So that's, that's what I'm trying to do is, is keep, uh, keep everything out in the open so that people can self service as much as possible. Sidekiq open source [00:41:24] Jeremy: And on the open source side, are you still primarily the main contributor? Or do you have other people that are [00:41:35] Mike: I mean, I'd say I do 90 percent of the work, which is why I don't feel guilty about keeping 100 percent of the money. A lot of open source projects, when they look for financial sustainability, they also look for how can we split this money amongst the team. And that's, that's a completely different topic that I've. [00:41:55] is another reason why I've stayed solo is if I hire an employee and I pay them 200, 000 a year as a developer, I'm meanwhile keeping all the rest of the profits of the company. And so that almost seems a little bit unfair. because we're both still working 40 hours a week, right? Why am I the one making the vast majority of the, of the profit and the money? [00:42:19] Um, so, uh, I've always, uh, that's another reason why I've stayed solo, but, but yeah, having a team of people working on something, I do get, regular commits, regular pull requests from people, fixing a bug that they found or just making a tweak that. that they saw, that they thought they could improve. [00:42:42] A little more rarely I get a significant improvement or feature, as a pull request. but Sidekiq is so stable these days that it really doesn't need a team of people maintaining it. The volume of changes necessary, I can easily keep up with that. So, I'm still doing 90 95 percent of the work. Are there other Sidekiq-like opportunities out there? [00:43:07] Jeremy: Yeah, so I think Sidekiq has sort of a unique positioning where it's the code base itself is small enough where you can maintain it yourself and you have some help, but primarily you're the main maintainer. And then you have enough customers who are willing to, to pay for the benefit it gives them on top of what the open source product provides. [00:43:36] cause it's, it's, you were talking about how. Every project people work on, they have, they could have hundreds of dependencies, right? And to ask somebody to, to pay for each of them is, is probably not ever going to happen. And so it's interesting to think about how you have things like, say, you know, OpenSSL, you know, it's a library that a whole bunch of people rely on, but nobody is going to pay a monthly fee to use it. [00:44:06] You have things like, uh, recently there was HashiCorp with Terraform, right? They, they decided to change their license because they, they wanted to get, you know, some of that value back, some of the money back, and the community basically revolted. Right? And did a fork. And so I'm kind of curious, like, yeah, where people can find these sweet spots like, like Sidekiq, where they can find this space where it's just small enough where you can work on it on your own and still get people to pay for it. [00:44:43] It's, I'm trying to picture, like, where are the spaces? Open source as a public utility [00:44:48] Mike: We need to look at other forms of financing beyond pure capitalism. If this is truly public infrastructure that needs to be maintained for the long term, then why are we, why is it that we depend on capitalism to do that? Our roads, our water, our sewer, those are not Capitalist, right? Those are utilities, that's public infrastructure that we maintain, that the government helps us maintain. [00:45:27] And in a sense, tech infrastructure is similar or could be thought of in a similar fashion. So things like Open Collective, things like, uh, there's a, there's a organization in Europe called NLNet, I think, out of the Netherlands. And they do a lot of grants to various open source projects to help them improve the state of digital infrastructure. [00:45:57] They support, for instance, Mastodon as a open source project that doesn't have any sort of corporate backing. They see that as necessary social media infrastructure, uh, for the long term. And, and I, and I think that's wonderful. I like to see those new directions being explored where you don't have to turn everything into a product, right? [00:46:27] And, and try and market and sale, um, and, and run ads and, and do all this stuff. If you can just make the case that, hey, this is, this is useful public infrastructure that so many different, um, Technical, uh, you know, applications and businesses could rely on, much like FedEx and DHL use our roads to the benefit of their own, their own corporate profits. [00:46:53] Um, why, why, why shouldn't we think of tech infrastructure sort of in a similar way? So, yeah, I would like to see us explore more. in that direction. I understand that in America that may not happen for quite a while because we are very, capitalist focused, but it's encouraging to see, um, places like Europe, uh, a little more open to, to trialing things like, cooperatives and, and grants and large long term grants to, to projects to see if they can, uh, provide sustainability in, in, you know, in a new way. [00:47:29] Jeremy: Yeah, that's a good point because I think right now, a lot of the open source infrastructure that we all rely on, either it's being paid for by large companies and at the whim of those large companies, if Google decides we don't want to pay for you to work on this project anymore, where does the money come from? [00:47:53] Right? And on the other hand, there's the thousands, tens of thousands of people who are doing it. just for free out of the, you know, the goodness of their, their heart. And that's where a lot of the burnout comes from. Right. So I think what you're saying is that perhaps a lot of these pieces that we all rely on, that our, our governments, you know, here in the United States, but also around the world should perhaps recognize as this is, like you said, this is infrastructure, and we should be. [00:48:29] Paying these people to keep the equivalent of the roads and, and, uh, all that working. [00:48:37] Mike: Yeah, I mean, I'm not, I'm not claiming that it's a perfect analogy. There's, there's, there's lots of questions that are unanswered in that, right? How do you, how do you ensure that a project is well maintained? What does that even look like? What does that mean? you know, you can look at a road and say, is it full of potholes or is it smooth as glass, right? [00:48:59] It's just perfectly obvious, but to a, to a digital project, it's, it's not as clear. So, yeah, but, but, but exploring those new ways because turning everybody into a businessman so that they can, they can keep their project going, it, it, it itself is not sustainable, right? so yeah, and that's why everything turns into a SaaS because a SaaS is easy to control. [00:49:24] It's easy to gatekeep behind a paywall and it's easy to charge for, whereas a library on GitHub. Yeah. You know, what do you do there? You know, obviously GitHub has sponsors, the sponsors feature. You've got Patreon, you've got Open Collective, you've got Tidelift. There's, there's other, you know, experiments that have been run, but nothing has risen to the top yet. [00:49:47] and it's still, it's still a bit of a grind. but yeah, we'll see, we'll see what happens, but hopefully people will keep experimenting and, and maybe, maybe governments will start. Thinking in the direction of, you know, what does it mean to have a budget for digital infrastructure maintenance? [00:50:04] Jeremy: Yeah, it's interesting because we, we started thinking about like, okay, where can we find spaces for other Sidekiqs? But it sounds like maybe, maybe that's just not realistic, right? Like maybe we need more of a... Yeah, a rethinking of, I guess the, the structure of how people get funded. Yeah. [00:50:23] Mike: Yeah, sometimes the best way to solve a problem is to think at a higher level. You know, we, the, the sustainability problem in American Silicon Valley based open source developers is naturally going to tend toward venture capital and, and capitalism. And I, you know, I think, I think that's, uh, extremely problematic on a, on a lot of different, in a lot of different ways. [00:50:47] And, and so sometimes you need to step back and say, well, maybe we're, maybe we just don't have the right tool set to solve this problem. But, you know, I, I. More than that, I'm not going to speculate on because it is a wicked problem to solve. [00:51:04] Jeremy: Is there anything else you wanted to, to mention or thought we should have talked about? [00:51:08] Mike: No, I, I, I loved the talk, of sustainability and, and open source. And I, it's, it's a, it's a topic really dear to my heart, obviously. So I, I am happy to talk about it at length with anybody, anytime. So thank you for having me. [00:51:25] Jeremy: All right. Thank you very much, Mike.

Entering Into God's Rest - Hebrews 3:1-4:1 - Sunday, October 8, 2023 - Dr. David Kramer

Seaford Baptist Sermon Podcast

Play Episode Listen Later Oct 9, 2023 51:21

entering hebrews 3 david kramer

Russia's Brutal Failed War with David Kramer

Kremlin File

Play Episode Listen Later Aug 24, 2023 64:53

Kremlin File kicks off season 3 with David Kramer as Mo and Olga discuss the state of Russia's brutal failed war, where Ukraine's allies stand, the signs of Russia's collapse, Wagner's failed coup, and more. Learn more about your ad choices. Visit podcastchoices.com/adchoices

russia ukraine failed wagner brutal david kramer kremlin file

Supreme Court Updates

law harvard court supreme court employment law david kramer

Play Episode Listen Later Jul 17, 2023 29:25

In this episode of Baird Holm Banter, Sarah Huyck talks to David Kramer about two recent Supreme Court decisions and how those opinions directly and indirectly affect employers.

The Pregnant Workers Fairness Act: What Employers Should Know

act workers pregnant employers fairness david kramer

Play Episode Listen Later Jul 11, 2023 18:33

In this episode of Baird Holm Banter, Sarah Huyck joins David Kramer to talk about the Pregnant Workers Fairness Act including its requirements, its prohibitions, and key takeaways for employers now that the Act is in effect.

Daf Yomi Gittin Daf 56 by R' Eli Stefansky

Daf Yomi by R’ Eli Stefansky

Play Episode Listen Later Jul 11, 2023 47:22

00:00 - Good Morning00:04 - MDYsponsor.com01:47 - תשעה באב03:42 - Amud Beis07:14 - Amud Aleph28:31 - Amud Beis46:23 - Amud Aleph46:53 - Have a Wonderful DayQuiz - https://kahoot.it/challenge/001090814--Today's shiur is sponsoredMoshe Banda: To thank Hashem that I am able to thank him for everything that I have&Jeff Rosner: Maaser 2 & remainder Ilui Nishmas Yosef Simcha Chaim Ben Shlomo Yehuda&Lock and Lebovic families Lakewood NJ because torah and achdus are the best segula&לע״נ חיה בת יוסף&Mordy Straus: L'Refuah Shlema Miriam bas Tamar who's receiving a new kidney today&לרפואה שלמה אברהם בן אסתר יוסף נסים בן אסתרשירה בת חמדה&The Braun (matzah) kids: Wishing the best mommy in the world a happy birthday we should always be able to make you proud and happy&Refuah Shelama for Tinok Ben Baila Freidel&Mordechai Ness: Shevach V'hodaah to Hashem for the safety of the girls in Camp Sternberg lightning&David Kramer: אישתי, ילדי, נכדי & all who celebrated my זקנה Bday w me TY rEli & לוי for vid&BRAIN INTACT Unleash your full potential: Should b זוכה2נחת דק and tremendous success in all my Endeavors&Joshua S: In honor of the Szlafrok's. Thank you for your generous hospitality&Kamionski Family: In memory of our Saba, Mordechai Ben Avraham Tzvi Kamionski upon his 18th yortziet---Turning of the dafMordechai Sapoznick: in honor of R' Eli&the MDY Tehillim Group, where we daven for Refuos, Yeshuos and Shidduchim for Klal Yisroel AND for our MDY Family.Join us at Tehillim.8MinDaf.com

turning lock wishing braun bday hashem endeavors tehillim daf yomi gittin david kramer lakewood nj yeshuos

A Week Where Decades Happen

russia supreme court decades ron desantis david kramer steve vladeck bob shrum

Play Episode Listen Later Jun 30, 2023 53:35

Bob Shrum, Steve Vladeck, and David Kramer join the show this week to discuss momentous Supreme Court cases and the tremors out of Russia. Plus, in our highlights/lowlights segment, Damon shares details about how a bloc of right-wing influencers and DeSantis supporters are rallying behind an antisemite. highlights/lowlights Damon's: https://www.rollingstone.com/politics/politics-news/desantis-influencers-defend-unmasked-antisemite-pedro-gonzalez-1234780062/amp/ Bob's: https://apnews.com/article/recession-economy-inflation-jobs-unemployment-2ad91e65f4c0c79ebd2518e351934605 Mona's: https://www.antonybeevor.com/book/russia-revolution-and-civil-war-1917-1921/ Learn more about your ad choices. Visit podcastchoices.com/adchoices

A Week Where Decades Happen

russia supreme court decades ron desantis david kramer steve vladeck bob shrum

Play Episode Listen Later Jun 30, 2023 56:35

David Kramer, George W. Bush Institute: “The most successful global health program in history”

Take as Directed

Play Episode Listen Later Jun 15, 2023 34:15

Twenty years after President George W. Bush signed the U.S. Leadership Against HIV/AIDS, Tuberculosis and Malaria Act of 2003, establishing PEPFAR, David Kramer, the Executive Director of the George W. Bush Institute in Dallas, Texas, discusses the process of establishing the multi-billion dollar program at the Department of State; how ensuring equitable access to health care services for vulnerable and marginalized populations is important for national security; how investing in HIV services and partnering with countries to strengthen health care improves the relationships of the United States with countries overseas; and why it's important that Congress reauthorize PEPFAR later this year.

united states history texas state executive director congress twenty hiv george w bush global health tuberculosis health programs pepfar david kramer bush institute

David Cramer on Application Monitoring with Sentry

Software Sessions

Play Episode Listen Later Jun 14, 2023 76:03

Sentry is an application monitoring tool that surfaces errors and performance problems. It minimizes the need to manually look at logs or dashboards by identifying common problems across applications and frameworks. David Cramer is the co-founder and CTO of Sentry. This episode originally aired on Software Engineering Radio. Topics covered: What's Sentry? Treating performance problems as errors Why you might no need logs Identifying common problems in applications and frameworks Issues with Open Telemetry data Why front-end applications are difficult to instrument The evolution of Sentry's architecture Switching from a permissive license to the Business Source License Related Links Sentry David's Blog Sentry 9.1 and Upcoming Changes Re-Licensing Sentry Transcript You can help edit this transcript on GitHub. [00:00:00] Jeremy: Today I'm talking to David Kramer. He's the founder and CTO of Sentry. David, welcome to Software Engineering Radio. [00:00:08] David: Thanks for having me. Excited for today's conversation. What's Sentry? [00:00:11] Jeremy: I think the first thing we could start with is defining what Sentry is. I know some people refer to it as an error tracker. Some people have referred to it as, an application performance monitoring tool. I wonder if you could kind of describe in, in your words what it is. [00:00:30] David: You know, as somebody who doesn't work in marketing, I just tell it how it is. So Sentry started out doing error monitoring, which. You know, dependent on who you talk to, you might just think of as logging, right? Like that's the honest truth. It is just logging just a different shape or form. these days it's hard to not classify us as just an APM tool that's like the industry that exists. It's like the tools people understand. So I would just say it's an APM tool, right? We do a bunch of things within that space, and maybe it's not, you know, item for item the same as say a product like New Relic. but a lot of the overlap's there, so it's like errors performance, which is like latency and sort of throughput. And then we have some stuff that just goes a little bit deeper within that. The, the one thing i would say that is different for us versus a lot of these tools is we actually only do application monitoring. So we don't do any since like systems or infrastructure monitoring. Meaning Sentry is not gonna tell you when you need to replace a hard drive or even that you need new hard, like more disk space or something like that because it's just, it's a domain that we don't think is relevant for sort of our customers and product. Application Performance Monitoring is about finding crashes and performance problems that users would associate with bugs [00:01:31] Jeremy: For people who aren't familiar with the term application performance monitoring, what is that compared to just error tracking? [00:01:41] David: The way I always reason about it, this is what I tell new hires and what I would tell, like my mother, if I had to explain what I do, is like, you load Uber and it crashes. We all know that's bad, right? That's error monitoring. We capture the crash report, we send it to developers. You load Uber and it's a 30 second spinner, like a loading indicator as a customer. Same outcome for me. I assume the app is broken, right? So we also know that's bad. Um, but that's different than a crash. Okay. Sentry captures that same thing and send it to developers. lastly the third example we use, which is a little bit more. I think, untraditional, but a non-traditional rather, uh, you load the Uber app and it's like a blank screen or there's no button to submit, like log in or something like this. So it's kind of like a, it's broken, but it maybe isn't erroring and it's not like a slow thing. Right. Same outcome. It's probably a bug of some sorts. Like it's what an end user would describe it as a bug. So for me, APM just translates to there are bugs, user perceived bugs in your application and we're able to monitor and, and help the software teams sort of prioritize and resolve those, those concerns. [00:02:42] Jeremy: Earlier you were talking about actual crashes, and then your second case is, may be more of if the app is running slowly, then that's not necessarily a crash, but it's still something that an APM would monitor. [00:02:57] David: Yeah. Yeah. And I, I think to be fair, APM, historically, it's not a very meaningful term. Like I as a, when I was more of just an individual contributor, I would associate APM to, like, there's a dashboard that will tell me what's slow in my application, which it does. And that is kind of core to APM, but it would also, none of the traditional tools, pre sentry would actually tell you why it's broken, like when there's an error, a crash. It was like most of those tools were kind of useless. And I don't know, I do actually know, but I'm gonna pretend I don't know about most people and just say for myself. But most of the time my problems are errors. They are not like it's fast or slow, you know? and so we just think of it as like it's a holistic thing to say, when I've changed the application and something's broken, or it's a bug, you know, what is that bug? How do we help people fix it? And that comes from a lot of different, like data signals and things like that. the end result is still the same. You either are gonna fix it or it's not important and you ignore it. I don't know. So it's a pretty straightforward, premise for us. But again, most companies in the space, like the traditional company is when you grow a big company, what happens is like you build one thing and then you build lots of check boxes to sell more things. And so I think a lot of the APM vendors, like they've created a lot of different products. Like RUM is a good example of another acronym that lives with an APM. And I would tell you RUM is completely meaningless. It, it stands for real user monitoring. And so I'm like, well, what's not real about monitoring the application? Well, nothing's not real, but like they created a new category because that's how marketing engines work. And that new category is more like analytics than it is like application telemetry. And it's only because they couldn't collect the app, the application telemetry at the time. And so there's just a lot of fluff, i would say. But at the end of the day too, like developers or engineering teams, it's like new version of the application. You broke something, let's tell you about it so you can fix it. You might not need logging or performance monitoring [00:04:40] Jeremy: And, and so earlier you were saying how this is a kind of logging, but there's also other companies, other products that are considered like logging infrastructure. Like I, I would think of companies like Paper Trail or Log Tail. So what space does Sentry fill that's that's different than that kind of logging? [00:05:03] David: Um, so the way I always think about it, and this is both personally true, and what I advise other folks is when you're building something new, when you start from zero, right, you can often take Sentry put it in, and that's good enough. You don't even need performance monitoring. You just need like errors, right? Like you're just causing bugs all the time. And you could do that with logging, but like the delta between air monitoring and logging is night and day. From a user experience, like error monitoring for us, or what we built at the very least, aggregates the errors. It, it helps you understand the frequency. It helps you when they're new versus old. it really gives you a lot of detail where logs don't, and so you don't need logging often. And I will tell you today at Sentry. Engineers do not use logs for the most part. Uh, I had a debate with one of our, our team members about it, like, why does he use logs recently? But you should not need them because logs serve a different purpose. Like if you have traces which tell you like, like fast and slow in a bunch of other network data and you have this sort of crash report collection or error monitoring thing, logs become like a compliance or an audit trail or like a security forensics, tool, and there's just not a lot of value that you would get out of them otherwise, like once in a while, maybe there's like some weird obscure use case, but generally speaking, you can just pretend that you don't need logs most days. Um, and to me that's like an evolution of the industry. And so when, when Sentry is getting started, most people were still logs. And if you go talk to SRE teams, they're like, oh, login is what we know. Some of that's changed a little bit, but. But at the end of the day, they should only be needed for more complicated audit trails because they're just not a good solution to the problem. It's just free form data. Structured or not, doesn't really matter. It's not aggregated. It's not something that you can really use. And it's why whenever you see logging tools, um, not even the papertrails of the world, but the bigger ones like Splunk or Cabana, it's like this weird, what we describe as choose your own adventure. Like go have fun, build your dashboards and try to make the logs useful kind of story. Whereas like something like Sentry, it's just like, why would you waste any time trying to build dashboards when we can just tell you when something new is broken? Like that's the ideal situation. [00:06:59] Jeremy: So it sounds like maybe the distinction is with a more general logging tool, like you mentioned Splunk and Kibana it's a collection of all this information. of things happening, even though nothing's necessarily wrong, whereas Sentry is more Sentry is it's going to log things, but it's only going to log things if Sentry believes something is wrong, either because of a crash or because of some kind of performance issue. People don't want to dig through logs or dashboards, they want to be told when something is wrong and whyMost software is built the same way, so we know common problems [00:07:28] David: Yeah. I, i would say it's about like actionability, right? Like, like nobody wants to spend their time digging through logs, digging through dashboards. Metrics are another good example of this. Like just charts with metrics on them. Yeah. They tell me something's happening. If there's lots of log statements, they tell me something's going on, but they're not, they're not optimized to like, help me solve a problem, right? And so our philosophy was always like, we haven't necessarily nailed this in all cases for what it's worth, but. It was like, the goal is we identify an actual problem, like close to like a root cause kind of problem, and we escalate that up and that's it. Uh, versus asking somebody to like go have to like build these dashboards, build these things, figure out what data matters and all this because most software looks exactly the same. Like if you have a web service, it doesn't matter what language it's written in, it doesn't matter how different you think your architecture is from somebody else's, they're all the same. It's like you've got a request, you've got a database, you've got some cache, you've got all these like known, known quantity things, and the slowness comes from the same places. Errors are structured while logs are not [00:08:25] David: The errors come from the same places. They're all exhibiting the same kinds of behavior. So logging is very unstructured. And what I mean by that is like there's no schema. Like you can hypothetically like make it JSON and everybody does that, but it's still unstructured. Whereas like errors, it's, it's a tight schema. It's like there's a type of error, there's a message for the error, there's a stack trace, there's all these things that you know. Right. And as soon as you know and you define those things, you can just build better products. And so distributed tracing is similar. Hypothetically, it's a little bit abstract to be fair, but hypothetically, distributed tracing is creating a schema out of basically network annotations. And somebody will yell at me for just simplifying it to that. I would tell 'em that's what it is. But, same goal in mind. If you know what the data is, you can take action on it. It's not quite entirely true. Um, because tracing is much more freeform. For example, it doesn't say if you have a SQL statement, it should be like this, it should be formatted this way, things like that. whereas like stack traces, there's a file name, there's there's a line number, there's like all these things, right? And so that's how I think about the delta between what is useful information and what isn't, I guess. And what allows you to actually build things like Sentry versus just build abstract exploration. Inferring problems rather than having user identify them [00:09:36] Jeremy: Kind of paint the picture of how someone would get started with a tool like Sentry. Do they need to tell Sentry anything about their application? Do they need to modify their source code at all? give us a picture of how that works. [00:09:50] David: Yeah, like one of our fundamentals, which I think applies for any real business these days is you've gotta like reduce user friction, right? Like you've gotta make it dead simple to use. Uh, and for us there were, there was like kind of a fundamental driving constraint behind that. So in many situations, um, APM vendors especially will require you to run an agent a basically like some kind of process that runs on your servers somewhere. Well, if you look at modern tech stacks, that doesn't really work because I don't run the servers half my stuff's in the browser, or it's a mobile app or a desktop app, and. Even if I do have those servers, it's like an entirely different team that controls them. So deploying like a sidecar, an agent is actually like much more complicated. And so we, we looked at that and also because like, it's much easier to have control if you just ship within the application. We're like, okay, let's build like an SDK and dependency that just injects into the, the application that runs, set an API key and then you're done. And so what that translates for Sentry is we spend a lot of time knowing what Django is or what Rails is or what expresses like all these frameworks. And just knowing how to plug into the right signals in those frameworks. And then at that point, like the user doesn't have to do anything. And so like the ideal outcome for Sentry is like you install the dependency in whatever language makes sense, right? You somehow configure the API key and maybe there's a couple other minor settings you add and that gives you the bare bones and that's it. Like it should just work from there. Now there's a lot you can do on top of that to enrich data and whatnot, but for the most part, especially for errors, like that's good enough. And that, that's always been a fundamental goal of ours. And I, I think we actually do it phenomenally well. [00:11:23] Jeremy: So it sounds like it infers things about the application without manual configuration. Can you give some examples of the kind of things that Sentry knows without the user having to tell it? [00:11:38] David: Yeah. So a good example. So on the errors side, we know literally everything because an error object in each language has all these attributes with it. It, it gives you the stack trace, it gives you a lot of these things. So that one's straightforward. On the performance side, we use a combination of leveraging some like open source, I guess implementations, like open telemetry where it's got all this instrumentation already and we can just soak that in, um, as well as we automatically instrument a bunch of stuff. So for example, say you've got like a Python application and you're using, let's say like SQL Alchemy or something. I don't actually know if this is how our SDK works right now, but, we will build something that's aware of that library and make sure it can automatically instrument the things it needs to get the right information out of it. And be fair. That's always been true for like APM vendors and stuff like that. The delta is, we've often gone a lot deeper. And so for Python for example, you plug it into an application, we'll capture things like the error, error object, which is like exception class name exception value, right? Stack trace, file, name, line number, all those normal things, function name. We'll also collect source code. So we'll, we'll give you sort of surrounding source code blocks for each line in the stack trace, which makes it infinitely easier to consume. And then in Python and, and php, and I forget if we do this anywhere else right now, we'll actually even allow you to collect what are called stack locals. So it'll, it'll give you basically the variables that are defined almost like a debugger. And that is actually, actually like game changing from a development point of view. Because if I can go look in production when there's an incident or a bug and I can actually see the state of the application. , I, I never need to know like, oh, what was going on here? Oh, what if like, do I need to go reproduce this somehow? I always have the right information. And so all of that for us is automatic and we only succeed like, it, it's, it's like by definition inside of Sentry, it has to be automatic. Like if we ask the user to do anything whatsoever, we're failing. And so whenever we design any product or anything, and to be fair, this is how every product company should operate. it's gotta be with as little user input as humanly possible. And so you can't always pull that off. Sometimes you have to have users configure stuff, but the goal should always be no input. Detecting errors through unhandled exceptions [00:13:42] Jeremy: So you, you're talking about getting a stack trace, getting, the state of variables, source code. That sounds like that's primarily gonna be through unhandled exceptions. Would you say that's, that's the primary way that you get error? [00:13:58] David: Yeah, you can integrate in other ways. So you can like trigger our API to capture an, uh, an exception. You can also, for better or worse, it's not always good. You can integrate through logging adapters. So if you're already using a logging framework and you log their errors there, we can often capture those. However, I will say in most cases, people use the logging APIs wrong and the data becomes junk. A good, a good example of this is like, uh, it varies per language. So I'm just gonna go to Python because Python is like sort of core to Sentry. Um, in Python you have the ability to log messages, you can log them as errors, you can log like actual error objects as errors. But what usually happens is somebody does a try-catch. They, they capture the error they rescue from it. They create a logging call, like log dot error or something, put the, the error message or value in there. And then they send that upstream. And what happens is the stack trace is gone because we don't know that it's an error object. And so for example, in Python, there's actually an an A flag. You pass the logging call to make sure that stack trace stays present. But if you don't know that the data becomes junk all of a sudden, and if we don't have a stack trace, we can't actually aggregate data because like there's just not enough information to like, to run hashing on it. And so, so there are a lot of ways, I guess, to capture the information, but there are like good ways and there are bad ways and I think it, it's in everybody's benefit when they design their, their apt to like build some of these abstractions. And so like as an example, when, whenever I would start a new project these days, I will add some kind of helper function for me to like log an exception when I like, try catch and then I can just plug in whatever I need later if I want to enrich the data or if I wanna send that to Sentry manually or send it to logs manually. And it just makes life a lot easier versus having to go back and like augment every single call in the code base. [00:15:37] Jeremy: So it, it sounds like. When you're using a tool like Sentry, there's gonna be the, the unhandled exceptions, which are ones that you weren't expecting. So those should I guess happen without you catching them. And then the ones that you perhaps do anticipate, but you still consider to be a problem, you would catch that and then you would add some kind of logging statement to your code that talks to Sentry directly. Finding issues like performance problems (N+1 queries) that are not explicit errorsz [00:16:05] David: Potentially. Yeah. It becomes a, a personal choice to be fair at that, at that point. but yeah, the, the way, one of the ways we've been thinking about this lately, because we've been changing our error monitoring product to not just be about errors, so we call it issues, and that's in the guise of like, it's like an issue tracker, a bug tracker. And so we started, we started putting what are effectively like, almost like static analysis concerns inside of this issue tracker. So for example, In our performance monitor, we'll do something called like detect n plus one queries, which is where you execute a, a duplicate query in a loop. It's not necessarily an error. It might not be causing a problem, but it could be causing a problem in the future. But it's like, you know, the, the, the qualities of it are not the same as an error. Like it's not necessarily causing the user to experience a bug. And so we've started thinking more about this, and, and this is the same as like logging errors that you handle. It's like, well, they're not really, they're not really bugs. It's like expected behavior, but maybe you still want to keep it like tracking somewhere. And I think about like, you know, Lins and things like that, where it's like, well, I've got some things that I definitely should be fixing. Then I've got a bunch of other stuff that's like informing me that maybe I should take action on or not. But only I, the human can really know at the end of the day, right, if I, if I should prioritize that or not. And so that's how I kind of think about like, if I'm gonna try catch and then log. Yeah, you should probably collect that data. It's probably less important than like the, these other concerns, like, like an actual unhandled exception. But you do, you do want to know that they're happening and whatnot. And so, I dunno, Sentry has not had a strong opinion on this historically. We're just like, send us whatever you want to capture in this regard, and you can pay for it, that's fine. It's like usage based, you know? we're starting to think a lot more about what should that look like if we, if we go back to like, what's the, what's the opinion we have for how you should use the product or how you should solve these kinds of software problems. [00:17:46] Jeremy: So you gave the example of detecting n plus one queries is, is that like being aware of the framework or the ORM the person is using and that's how you're determining this? Or is it at more of a lower level than that? [00:18:03] David: it is, yeah. It's at the framework level. So this is actually where Open Telemetry causes a lot of harm, uh, for us because we need to know what a database query is. Uh, we need to know like the structure of the query because we actually wanna parse it out in a lot of cases. Cause we actually need to identify if it's duplicate, right? And we need to know that it's a database query, not a random annotation that you've added. Um, and so what we do is within these traces, which is like if you, if you don't know what a trace is, it's basically just like, it's a tree, like a tree structure. So it's like A calls B, calls C, B also calls D and E and et cetera, right? And so you just, you know, it's a trace. Um, and so we actually just look at that trace data. We try to find these patterns, which is like, okay, B was a, a SQL query or something. And every single sibling of B is that same SQL query, but sort of removing certain parameters and stuff for the value. So we'll look at that data and we'll try to pull out anomalies. So m plus one is an example of like a fairly obvious anti pattern that everybody knows is bad and can be optimized. Uh, but there's a lot of other that are a little bit more subjective. I'll give you an example. If you execute three SQL statements back to back, one could argue that you could just batch those SQL statements together. I would argue most of the time it doesn't matter and I don't need to do that. And also it's not guaranteed that that is better. So it becomes much more like, well, in my particular situation this is valuable, but in this other situation it might not be. And that's where I go back to like, it's almost like a linter, you know? But we're trying to infer all of that from the data stream. So, so Sentry's kind of, we're kind of a backwards product company. So we build our product from a technology vision, not from customers want this, or we have this great product vision or anything like that. And so in our case, the technology vision is like, there's a lot of application data that comes in, a lot of telemetry, right? Errors, traces. We have a bunch of other streams now. within that telemetry there is like signal. And so one, it's all structured data so we know what it is so we can actually interpret it. And then we can identify that signal that might be a problem. And that signal in our case is often going to translate to like this issue concept. And then the goal is like, well, can we identify these problems for people and surface them versus the choose your own adventure model, which is like, we'll just capture everything and feed it to the user and they can figure out what matters. Because again, a web service is a web service. A database is a database. They're all the same problems for everybody. All you know, it's just, and so that's kind of the model we've built and are continuing to evolve on and, and so far works pretty well to, to curate a lot of these workflows. Want to infer everything, but there are challenges [00:20:26] Jeremy: You talked a little bit about how people will sometimes use tracing. And in cases like that, they may need some kind of session ID to track. Somebody making a call to a service and that talks to a database and that talks to other services. And you, inside of your application, you have to instrument some way of tracking. This all came from this one request. Is that something that Sentry can infer or is there something that the developer has to put into play so that you can track that sort of thing? [00:21:01] David: Yeah, so it's, it's like a bit of both. And i would say our goal is that we can infer everything. The reality is there is so much complexity and there's too much of a, like, too many technologies in the world. Like I was complaining about this the other day, like, the classic example on web service is if we have a middleware hook, We kind of know request response, usually that's how middleware would work, right? And so we can infer a lot from there. Like basically we can infer the boundaries, which is a really big deal. Okay. That's one thing is boundaries is a problem. What we, we describe that as a transaction. So like when the request starts. When the request ends, right? That's a very important boundary for everybody to understand because when I'm working on the api, I care about the API boundary. I actually don't care about what the database is doing at its low level or what the JavaScript application might be doing above it. I want my boundary. So that's one that we kind of can do. But it's hard in a lot of situations because of the way frameworks and technology has been designed, but at least traditional stuff like a, a traditional web stack, it works like a Rails app or a DDjango app or PHP app kind of thing, right? And then within that it becomes, well, how do you actually build a trace versus just have a bunch of arbitrary labels? And so we have a bunch of complicated tech within each language that tries to establish that tree. and then we annotate a lot of things along the way. And so we will either leverage Open Telemetry, which is an open format spec that ideally has very high quality data. Ideally, not realistically, but ideally it has high quality data. Every library author implements it great, everybody's happy. We don't have to do anything ever again. The reality is that data is like all over the map because there's not like strict requirements for what, how the data should be labeled and stuff. And not everything even has that data. Like not everything's instrumented with open telemetry. So we also have a bunch of stuff that, unrelated to using that we'll say, okay, we know what this library is, we're gonna try to infer some characteristics from this library, or we know what maybe like the DDjango template engine is. So we're gonna try to infer like when the template renders so you can capture that block of information. it is a very imperfect science and I would tell you like it's not, even though like Open Telemetry is a very fun topic for people. It is not necessarily good, like it's not in a good state. Could will it ever be good? I don't know in all honesty, but like the data quality is like all over the map and so that's honestly one of our biggest challenges to making this experience that, you know, tells you what's going on in your database so it tells you what's going on with the cash or things like this is like, I dunno, the cash might be called something completely random in one implementation and something totally different in another. And so it's a lot of like, like data normalization that you have to deal with. But for the most part, those libraries of things you don't control can and will be instrumented. Now the other interesting thing, which we'll see how this works out, so, so one thing Sentry tries to do there, we have all these layers of telemetry, so we have errors and traces, right? Those are pretty high level concepts. We also have profiling data, which is very, very, very, very low level. So it's usually only if you have like disc. I like. It's where is all the CPU time being spent in my application? Mostly not waiting. Like waiting's usually like a network call, right? But it's like, okay, I have a loop that's doing a lot of math, or I'm writing a bunch of stuff to disc and that's really slow. Like often those are not instrumented or it's like these black box areas of a performance. And so what we're trying to do with profiling data, instead of just showing you flame charts and stuff, is actually say, could we fill in these gaps in these traces? Like basically like, Hey, I've got a long period of time where the app's doing something. You know, here's an API call, here's the database stuff. But then there's this block, okay, what's that function or something? Can we pull that out of the profiling data? And so in that case, again, that's just automatic because the profile actually knows everything about the application and know it. It has full access to the function and the stack and everything, right? And so the dream is that you would just always have everything filled in the, the customer never has to do anything with one minor asterisk. And the asterisk is what I would call like business context. So a good example would be, You might wanna associate requests with a specific customer or something like that. Like you might wanna say, well it's uh, I don't know, Goldman Sachs or one of these big companies or something. So you can know like, well when Goldman Sachs is having performance issues or whatever it is, oh maybe I should focus on them cuz maybe they pay you a lot of money or something. Right. Sentry would never know that at the end of the day. So we also have these like kind of tagging contextual APIs that will say like, tell us some informations, maybe it's like customer, maybe it's something else that's relevant to your application. And we'll keep that data associated with the telemetry that's like present, you know, um, but the, at least the telemetry, like again, application's just worth the same, should be, there should be a day in the next few years that it's just all automatic. and again, the only challenge today is like, can it be high quality and automatic? And so that, that's like to be determined. [00:25:50] Jeremy: What you're kind of saying is the ideal is being able to look at this profiling information and be able to build a full picture of. a, a call from beginning to end, all the different things to talk to, but I guess what's the, what's the reality today? Like, what, what is Sentry able to determine, in the world we live in right now? [00:26:11] David: So we've done a lot of this like performance detection stuff already. So we actually can do a lot now. We put a lot of time into it and I, I will tell you, if you look at other tools trying to do tracing, their approach is much more abstract. It's like your traditional monitoring tool that's like, we're just gonna collect a lot of signals and maybe we'll find magic anomaly detection or something going on in it, which, you know, props, but that can figure that out. But, a lot of what we've done is like, okay, we kind of know what this data looks like. Let's go after this very like known quantity problem. Let's normalize the data. And let's make it happen like that's today. Um, the enrichment of profiles is new for us, but it, we actually can already do it. It's not perfect. Detection of blocking the UI thread in mobile apps [00:26:49] David: Um, and I think we're launching something in April or May, something around the, that timeframe where hopefully for the, the technologies we can instrument, we're actually able to surface that in a useful way. but as an example that, that concept that I was talking about, like with n plus one queries, the team built something using profiling data. and I think this, this might be for like a mobile app more so than anything where mobile apps have this problem of, it's, you've got a main thread and if you block that main thread, the app is basically frozen. You see this on desktop apps all the time. You, you very rarely see it on web apps anymore. But, but it's a really big problem when you have a web, uh, a mobile or desktop app because you don't want that like thing to be non-responsive. Right? And so one of the things they did was detect when you're doing like file io on the main thread, you know, right. When you're writing a disc, which is probably a slow thing or something like that, that's gonna block the whole thing. Because you should just do it on a separate thread. It's like an easy fix, potentially may not be a problem, but it could become a problem. Same thing as n plus one. But what's really interesting about it is what the team did is like they used the profiling data to detect it because we already know threads and everything in there, and then they actually recreated a stack trace out of that profiling data when it's surfaced. So it's actually like useful data with that. You could like that I or you as a developer might know how to take and actually be like, oh, this is where it happens at the source code. I can actually figure it out and go fix it myself. And to me, like as like I, I'm still very much in the weeds with software that is like one of the biggest gaps to most things. Is it just, it doesn't make it easy to consume or like take action on, right? Like if I've got a, a chart that says my error rate is high, what am I gonna do with that? I'm like, okay, what's breaking? That's immediately my next question. Right? Okay. This is the error. Where is that error happening at? Again, my next question, it, it's literally just root cause analysis, right? Um, and so that, that to me is very exciting. and I, I don't know that we're the first people to do that, I'm not sure. But like, if we can make that kind of data, that level of actionable and consumable, that's like a big deal for me because I will tell you is like I have 20 years of software experience. I still hate flame charts and like I struggle to use them. Like they're not a friendly visualization. They're almost like a, a hypothetically necessary evil. But I also think one where nobody said like, do we even need to use that? Do we need that to be like the way we operate? and so anyways, like I guess that's my long-winded way of saying like, I'm very excited for how we can leverage that data and change how it's used. [00:29:10] Jeremy: Yeah. So it sounds like in this example, both in the mobile app blocking the UI or the n plus one query is the Sentry, suppose, SDK or instrumentation that's hooked inside of your application. There are certain behaviors that it knows are, are not like ideal I guess, just based on. people's prior experience, like your own developers know that, hey, if you block the UI thread in this mobile application, then you're gonna have performance problems. And so that way, rather than just telling you, Hey, your app is slow, it can tell you your app is slow and it's because you're blocking the UI thread. Don't just aggregate metrics, the error tracker should have an opinion on what actual problems are [00:29:55] David: Exactly, and I, and I actually think, I don't know why so many people don't recognize this gap, because at the end of the day, like, I don't know, I don't need more people to tell me response times are bad or anything. I need you to have an opinion about what's good because. The only way it's like math education, right? Like, yeah, you learn the basics, but you're not expected to say, go to calc, but, and then like, do all the fundamentals. You're like, don't get a calculator and start simplifying the problem. Like, yeah, we're gonna teach you a few of these things so you understand it. We're gonna teach you how to use a calculator and then just use the calculator and then make it easier for everybody else. But we're also not teaching you how to build a calculator because who cares? Like, that's not the purpose of it. And so for me, this is like, we should be helping people sort of get to the finish line instead of making them run the entirety of the race over and over if they don't need to. I don't, I don't know if that's a good analogy, but that has been the biggest gap, I think, in so much of this software throughout the industry. And it's, it's, it's common everywhere. And there's no reason for that gap to exist these days. Like the technology's fine. And the technology's been fine for like 10 years. Like Sentry started in oh eight at this point. And I think there was only one other company I recall at the time that was doing anything that was even similar to like air monitoring and Sentry when we built it, we're just like, what if we just go deeper? What if we collect all this information that will help you debug the problem instead of just stopping it like a log aggregator or something kind of thing, so we can actually have an opinion about it. And I, I genuinely, it baffles me that more people do not think this way because it was not a hard problem at the time. It's certainly not hard these days, but there's still very, I mean, a lot more people do it now. They've seen Sentry successful and there's a lot of similar implementations, but it's, it's just amazes me. It's like, why don't you, why don't people try to make the data more actionable and more useful, the teams versus just collect more of it, you know? 40 people working on learning the common issues with languages and frameworks [00:31:41] Jeremy: it, it sounds like maybe the, the popularity of the stack the person is using or of the framework means that you're gonna have better insights, right? Like if somebody makes a, a Django application or a Rails application, there's all these lessons that your team has picked up in terms of, Hey, if you use the ORM this way, your application is gonna be slow. Whereas if somebody builds something totally homegrown, you won't know these patterns and you won't be able to like help as much basically. [00:32:18] David: Yeah. Yeah, that's exactly, and, and you might think that that is a challenge, but then you look at how many employees exist at like large tech companies and it's, it's not that big of a deal, like, , you might even think collecting all the information for each, like programming, runtime or framework is a challenge. We have like 40 people that work on that and it's totally fine. Like, and, and so I think actually all these scale just fine. Um, but you do have to understand like the domain, right? And so the counter version of this is if you look at say like browser applications, like very rich, uh, single page application type experiences. It's not really obvious like what the opinions are. Like, like if, if you, and this is like real, like if you go to Sentry, it's, it's kind of slow, like the app is kind of slow. Uh, we even make fun of ourselves for how slow it is cuz it's a lot of JavaScript and stuff. If you ask somebody internally, Hey, how would we make pick a page fast? They're gonna have no clue. Like, even if they have like infinite domain experience, they're gonna be like, I'm not entirely sure. Because there's a lot of like moving parts and it's not even clear what like, like good is right? Like we know n plus one is bad. So we can say not doing that is the better solution. And so if you have a JavaScript app, which is like where a lot of the slowness will come from is like the render times itself. Like how do you fix it? You, you can't actually build a product that tells you what to fix without knowing how to fix it, right? And so some of these newer and very fast moving targets are, are frankly very difficult for us. Um, and so that's one thing that I think is a challenge for the entire industry. And so, like, as an example, a lot of the browser folks have latched onto web vitals, which are just metrics that hopefully tell you something about the application, but they're not always actionable either. It'll be like, the idea with like web vitals is like, okay, time to interactive is an an important metric. It's like how long until the page loads that a user can do what they're probably there to do. Okay. Like abstractly, it makes sense to us, but like put into action. How do I optimize time to interactive? Don't block the page. That's one thing. I don't know. Defer assets, that's another thing. Okay. So you've gotta like, you've gotta build a technology that knows these assets could be deferred and aren't. Okay, which ones can be deferred? I don't know. Like, it, it, it's like such a deep rabbit hole. And then the problem is, six months from now, the tech will have completely changed, right? And it won't have like, necessarily solved some of these problems. It will just have changed and they're now a completely different shape of problem. But still the same fundamental like user experience is the same, you know? Um, and to me that's like the biggest challenge in the industry right now is that like dilemma of the browser at the end of the day. And so even from our end, we're like, okay, maybe we should step back, focus on servers again, focus on web services. Those are known quantities. We can do that really well. We can sort of change that to be better than it's been in the past and easier to consume with things like our n plus one detections. Um, and then take like a holistic, fresh look at browser and say, okay, now how would we solve this to make sure we can actually really latch onto the problems that like people have and, and we understand, right? And, you know, we'll see when we get there. I don't think any product does a great job these days for helping, uh, solve those problems. . But I think even without the, the products, like I said, like even our team would be like, fixing this is gonna take months because it's gonna take months just to figure out exactly where the, the common bottlenecks are and all these other things within an application. And so I, I guess what I mean to say with that is there's a lot of opportunity, I think with the moving landscape of technology, we can find a way to, whether it's standardized or Sentry, can find a way to make that data actionable want it something in between there. There are many ways to build things on the frontend with JavaScript which makes it harder to detect common problems compared to backend [00:35:52] Jeremy: So it sounds like what you're saying, With the, the back end, there's almost like a standard way of doing things or a way that a lot of people do it the same way. Whereas on the front end, even if you're looking at a React application, you could look at tenant react applications and they could all be doing state management a totally different way. They could be like the, the way that the application is structured could be totally different, and that makes it difficult for you to infer sort of these standard patterns on the front end side. [00:36:32] David: Yeah, that's definitely true. And it, it goes, it's even worse than that because well, one, there's just like the nature of JavaScript, which is asynchronous in the sense of like, it's a lot of callbacks and things like that. And so that already makes it hard to understand what's going on, uh, where things are happening. And then you have these abstractions like React, which are very good, but like they pull a lot of that away. And so, as an example of a common problem, you load the application, it has to do a lot of stuff to make the page render. You might call that hydration or whatever. Okay. And then there's a completely different state, which is going from, it's already hydrated. Page one, I, I've done an interaction or something. Or maybe I've navigated a page too, that's an entirely different, like, sort of performance problem. But that hydration time, that's like a known thing. That's kind of like time to interactive, right? But if the problem is in your framework, which a lot of it is like a lot of the problems today exist because of frameworks, not because of the technology's bad or the framework's bad, but just because it's abstracted and it's really hard to make it work in all these situations, it's complicated. And again, they have the same problem where it's like changing non sem. And so if the problem is the framework is somehow incorrectly re rendering the page as an example, and this came up recently, for some big technology stack, it's re rendering the page. That's a really bad problem for the, the customer because it's making the, it's probably actually causing a lot of CPU seconds. This is why like your Chrome browser tabs are using so much memory in cpu, right? How do you fix that? Can you even fix that? Do you just say, I don't know, blame the technology? Is that the solution? Maybe that is right, but how would we even blame the technology like that alone, just to identify why it's happening. and you need to know the why. Right? Like, that is such a hard problem these days. And, and personally, I think the only solution is if the industry sort of almost like standardizes on a way to like, on a belief of how this should be optimized and how it should be measured and monitored kind of thing. Because like how errors work is like a standardization effectively. It may not be like a formal like declaration of like, this is what an error is, but more or less they always have the same attributes because we've all kind of understood that. Like those are the valuable things, right? Okay. I've got a server rendered application that has client interaction, which is sort of the current generation of the technology. We need to standardize on what, like that web request, like response life cycle is, right? and what are the moving targets within there. And it just, to me, I, I honestly feel like a lot of what we use every day in technology is like beta. Right. And it's, I think it's one of the reasons why we're constantly always having to up, like upgrade and, and refactor and, and, and shift dependencies and things like that because it is not, it's very much a prototype, right? It's a moving target, which I personally do not think is great for the industry because like customers do not care. They do not care that you're using some technology that like needs a change every few months and things like that. now it has improved things to be fair. Like web applications are much more like interactive and responsive sometimes. Um, but it is a very hard problem I think for a lot of people in the world. [00:39:26] Jeremy: And, and when you refer to, to things feeling like beta, I suppose, are, are you referring to the frameworks people are using or the libraries they're using to support their front end development? I, I'm curious what you're, you're thinking there. [00:39:41] David: Um, I think it's everything. Even like the browser APIs are constantly shifting. It's, that's gotten a little bit better. But even the idea like type script and stuff, it's just like we're running like basically compilers to make all this code work. And, and so the, even that they're constantly adding features just because they can, which means behaviors are constantly changing. But like, if you look at a real world example, like React is like the, the most dominant technology. It's very well designed for managing the dom. It's basically just a rendering engine at the end of the day. It's like it's managed to process updates to the dom. Okay. Makes sense. But we've all learned that these massive single page applications where you build all your application logic and loaded into a bundle is a problem. Like, like, I don't know how big Sentry's bundle is, but it's multiple megs in size and it takes a little while for like a, even on fast fiber here in the Bay Area, it takes a, you know, several seconds for the UI to load. And that's not ideal. Like, it's like at some point half of us became okay with this. So we're like, okay, what we need to do is go back, literally just go back 10 years and we need to render it on the server. And then we need some stuff that makes interactions, you know, highly responsive in the UI or dynamic content in the ui, you know, bring, it's like bringing back jQuery or something. And so we're kind of going full circle, but that is actually like very complicated because the way people are trying to do is like, okay, we wanna, we wanna have the rendering engine operate the same on the server and is on as on the client, right? So it's like we just write one, path of code that basically it's like a template engine to some degree, right? And okay, that makes sense. Like we can all get behind that kind of model. But that is actually really hard to make work with a lot of people's software and, and I think the challenge and framers have adopted it, right? So they've taken this, so for example, it's like, uh, react server components, which is basically just like, can we render it on the server and then also keep that same interaction in the ui. But the problem is like frameworks take that, they abstract it and so it's another layer of complexity on something that is already enormously complex. And then they add their own flavor onto it, like their own opinions for maybe what the world way the world is going. And I will say like personally, I find those. Those flavors to be very hard to adapt to like things that are tried and true or importantly in this context, things that we know how to monitor and fix, right? And so I, I don't know what, what the be all end all is, but my thesis on this is you need to treat the UI like a template engine, and that's it. Remove all like complexity behind it. And so if you think about that, the term I've labeled it as, which I did not come up with, I saw this from somebody at some point, is like, it's like your front end as a service. Like you need to take that application that renders on the server and the front end, and it's just an entirely different application, which is annoying. and it just calls your APIs and that's how it gets the data it needs. So you're literally just treating it as if it's like a single page application that can't connect to your database. But the frameworks have not quite done that. And they're like, no, no, no. We'll connect to the database and we'll do all this stuff, but then it doesn't work because you've got, like, it works this way on the back end and this way on the front end anyways. Again, long winded way of saying like, it's very complicated. I don't think the technology can solve it today. I think the technology has to change before these problems can actually genuinely become solvable. And that's why I think the whole thing is like a beta, it's like, it's very much like a moving target that we're eventually we'll get there and it's definitely had value, but I don't know that, um, responsiveness for low latency connections is where the value has been created. You know, for like folks with bad internet and say remote Africa or something, like I'm sure the internet is not a very fun place for them to use these days. Some frontend code runs on the server and some in the browser which creates challenges [00:43:05] Jeremy: I guess one of the things you mentioned is there's this, almost like this split where you have the application running on the server. It has its own set of rules because it, like you said, has access to the database and it can do things that you can't do in the browser, and then you have to sort of run the same application in the browser, but it's not quite the same application because it doesn't have access to the same things in the browser. So you have this weird disconnect, I suppose. [00:43:35] David: Yeah. Yeah. And, and, and then the challenges is like a developer that's actually complicated for you from the experience point of view, cuz you have to know somehow, okay, these things are ta, these are actually running on the server and only on the server. And like, so I think the two biggest technologies that try to do this, um, or at least do it well enough, or the two that I've used, there might be some others, um, are NextJS and remix and they have very different takes on how to do this. But, remix is the one I use most recently. So I, I'll comment on that. But like, there's a, a way that you kind of say, well, this only runs on, I think the client as an example. And that helps you a little bit. You're like, okay, this is only gonna render on the client. I can, I actually can think about that and reason about that. But then there's this thing like, okay, sometimes this runs on the server, only this part runs on the server. And it's, it just becomes like the mental capacity to figure out what's going on and debug it is like so difficult. And that database problem is like the, the normal problem, right? Like of like, I can only query the database on the server because I need secure credentials or something. Okay. I understand that as a developer, but I don't understand how to make sure the application is doing what I expect it to do and how to fix it if something goes wrong. And that, that's why I think. , I'm a, I'm a believer in constraints. The only way you make progress is you simplify problems. Like you just give up on solving the complicated thing and you make the problem simpler. Right? And so for me, that's why I'm like, just take the database outta the equation. We can create APIs from the client, from the server, same security levels. Okay? Make it so it can only do that and it has to be run as almost like a UI only thing. Now that creates complexity cuz you have to run this other service, right? And, and like I personally do not wanna have to spin up a bunch of containers just to write like a simple like web application. but again, I, I think the problem has not been simplified yet for a lot of folks. Like React did this to be fair, um, it made it a lot easier to, to build UI that was responsive and, and just updated values when they changed, you know, which was a big deal for a long period of time. But I feel like everything after has not quite reached that that area, whereas it's simple and even react is hard to debug when it doesn't do what you want it to do. So I don't know, there, there's so gaps I guess is what i would say. And. Hopefully, hopefully, you know, in the next five years we'll kind of see this come to completion because it does feel like it's, it's getting closer to that compromise. You know, where like we used to have pure server rendered apps with some weird janky JavaScript on top. Now we've got this bridge of really complicated, you know, JavaScript on top, and the server apps are also complicated and it's just, it's a nightmare. And then this newer generation of these frameworks that work for some types of technology, but not all. And, and we're kind of almost coming full circle to like server rendered, you know, everything. But with like allowing the same level of interactions that we've been desiring, I guess, on the web. So, and I, fingers crossed this gets better, but right now I do not see like a clear like, oh, it's definitely there. I can see it coming. I'm like, well, we're kind of making progress. I don't love being the beta tester of the whole thing, but we're kind of getting there. And so, you know, we'll see. There are multiple ways to write mobile apps as well (flutter, react native, web views) [00:46:36] Jeremy: I guess you, you've been saying this whole shifting landscape of how Front End works has made it difficult for Sentry to provide like automatic instrumentation and things like that for, for mobile apps. Is that a different story? Like is it pretty standardized in terms of how do you instrument an Android app or an iOS app. [00:46:58] David: Sort of, but also, no, like, a good example here is like early days mobile, it's a native application. You ship a binary known quantity, right? Or maybe you embedded a web browser, but like, that was like a very different thing. Okay. And then they did things where like, okay, more of it's like embedded web browser type stuff, or dynamically render content. So that's now a moving target. the current version of that, which I'm not a mobile dev so like people have strong opinions on both sides of this fence, but it's like, okay, do you use like a, a hybrid framework which allows you to build. Say, uh, react native, which is like arou you to sort of write a JavaScript ish thing and it runs on both Android and mobile, but not really well on either. Um, or do you write a native, native app, which is like a known quantity, but then you may maintain like two code bases, have two degrees of expertise and stuff. Flutters the same thing. so there's still that version of complexity that goes on within it. And I, I think people care less about mobile cuz it impacts people less. Like, you know, there's that whole generation of like, oh, mobile's the future, everything's gonna be mobile, let's not become true. Uh, mobile's very important, but like we have desktops still. We use web software all the time, half the time on mobile. We're just using the web software at the end of the day, so at least we know that's a thing. And I think, so I think that investment in mobile has died down some. Um, but some companies like mobile is like their main experience or one of their driving experience is like a, like a company like DoorDash, mobile is as important as web, if not more, right? Because of like the types of customers. Spotify probably same thing, but I don't know, Sentry. We don't need a mobile app, who cares? It's irrelevant to the problem space, right? And so I, I think it's just not quite taken on. And so mobile is still like this secondary citizen at a lot of companies, and I think the evolution of it has been like complicated. And so I, I think a lot of the problems are known, but maybe people care less or there's just less customers. And so the weight doesn't, like, the weight is wildly different. Like JavaScript's probably like a hundred times the size from an investment point of view for everyone in the world than say mobile applications are, is how I would think about it. And so whether mobile is or isn't solved is almost irrelevant to the, the, the like general problem at hand. and I think at the very least, like mobile applications, there's like, there's like a tool chain where you can debug a lot of stuff that works fairly well and hasn't changed over the years, whereas like the web you have like browser tools, but that's about it. So. Mobile apps can have large binaries or pull in lots of dependencies at runtime [00:49:16] Jeremy: So I guess with mobile. Um, I was initially thinking of native apps, but you're, you're bringing up that there's actually people who would make a native app that's just a web view for a webpage, or there's React native or there's flutters, so there's actually, it really isn't standard how to make a mobile app. [00:49:36] David: Yeah. And even within those, it comes back to like, okay, is it now the same problem where we're loading in a bunch of JavaScript or downloading a bunch of JavaScript and content remotely and stuff? And like, you'll see this when you install a mobile app, and sometimes the binaries are huge, right? Sometimes they're really small, and then you load it up and it's downloading like several gigs of data and stuff, right? And those are completely different patterns. And even within those like subsets, I'm sure the implementations are wildly different, right? And so, you know, I, that may not be the same as like the runtime kind of changing, but I remember there was this, uh, this must be a decade ago. I, I used, I still am a gamer, but. Um, early in my career I worked a lot with like games like World of Warcraft and stuff, and I remember when games started launching progressive loading where it's like you could download a small chunk of the game and actually start playing and maybe the textures were lower, uh, like resolution and everything was lower fidelity and, and you could only go so far until the game fully installed. But like, imagine like if you're like focused on performance or something like that, measuring it there is completely different than measuring it once, say everything's installed, you know? And so I think those often become very complex use cases. And I think that used to be like an extreme edge case that was like such a, a hyper-specific optimization for like what The Warcraft, which is like one of the biggest games of all time that it made sense, you know, okay, whatever. They can build their own custom tooling and figure it out from there. And now we've taken that degree of complexity and tried to apply it to everything in the world. And it's like uhoh, like nobody has the teams or the, the, the talent or the, the experience to necessarily debug a lot of these complicated problems just like Sentry like. You know, we're not dealing with React internals. If something's wrong in the React internals, it's like somebody might be able to figure it out, but it's gonna take us so much time to figure out what's going on, versus, oh, we're rendering some html. Cool. We understand how it works. It's, it's a known, known problem. We can debug it. Like there's nothing to even debug most of the time. Right. And so, I, I don't know, I think the industry has to get to a place where you can reason about the software, where you have the calculator, right. And you don't have to figure out how the calculator works. You just can trust that it's gonna work for you. How Sentry's stack has become more complex over time [00:51:35] Jeremy: so kind of. Shifting over a little bit to Sentry's internals. You, you said that Sentry started in, was it 2008 you said? [00:51:47] David: Uh, the open source project was in 2008. Yeah. [00:51:50] Jeremy: The stack that's used in Sentry has evolved. Like I remembered that there was a period where I think you could run it with a pretty minimal stack, like I think it may have even supported SQLite. [00:52:02] David: Yeah. [00:52:03] Jeremy: And so it was something that people could run pretty easily on their own. But things have, have obviously changed a lot. And so I, I wonder if you could speak to sort of the evolution of that process. Like when do you decide like, Hey, this thing that I built in 2008, Is, you know, not gonna cut it. And I really need to re-architect what this system is. [00:52:25] David: Yeah, so I don't know if that's actually the reality of why things have changed, that it's like, oh, this doesn't work anymore. We've definitely introduced complexity in the sense of like, probably the biggest shift for Sentry was like, it used to be everything, and it was a SQL database, and everything was kind of optional. I think half that was maintainable because it was mostly built by. And so I could maintain like an architectural vision that kept it minimal. I had the experience to figure it out and duct tape the right things. Um, so that was one thing. And I think eventually, you know, that doesn't scale as you're trying to do more and build more into the product. So there's some complexity there. but for the most part you can, it can still

god amazon spotify google hell africa table uber android shifting id mobile ios engineers excited bay area remove saas application treating cto react suite goldman sachs monitoring rabbit metrics api intent stack chrome makes doordash world of warcraft python ui errors aws warcraft java github rum apis javascript detection rails apache kafka versus structured cpu php detecting django s3 sql cuz atlassian frontend sdks cockroach vps sentry gitlab elastic sre cabana splunk json mongo lins hypothetically apm defer jquery datadog mq orm new relic gpl bsd bsl paper trails sqlite nginx linode rabbitmq david kramer nextjs david you inferring david so flutters kibana david yeah david cramer riak david there software engineering radio mssql david thanks jeremy you jeremy so business source license

Daf Yomi Sotah Daf 40 by R' Eli Stefansky

Daf Yomi by R’ Eli Stefansky

Play Episode Listen Later May 8, 2023 49:17

00:00 - Good Morning00:09 - Omer.8MinDaf.com00:16 - US Tour01:36 - Emails09:04 - Sponsor.8MinDaf.com10:51 - Amud Aleph41:18 - Amud Beis48:53 - Have a Wonderful DayQuiz - https://kahoot.it/challenge/007907537--Today's shiur is sponsoredMr Eli Stefansky: L”n Menachem Toporowitz מנחם מענדל ע"ה בן יבלח"א יהושע דב&לע״נ חיה בת יוסף&לע״נ זכריה בן משה&Refuah Shleimah Rav Eliahu Ben Zissel Devorah&L'ilui Nishmas My Father, R' Yisroel ben R' Dov, May today's learning be a Zechus for his Neshama and a source of comfort for the family.Tzirel, Avrohom Mayer, Yisroel Dov & Asher Zelig Farkovits&Arnon Ahronov: In memory of my father in law Rabbi Murry Maseltonר מרדכי בן שפיקה&זכות דניאל בן יעל to surpass his goals at work bekarov BH!&Steve Melnick: Avraham Moshe Ben Shalom A"H&David Kramer: לז״נ יצחק אייזיק בן יעקב סנדר הכהן. Uncle Ira. Who yearned for doing the avoda&Jonathan & Chaya Lasson: In Honor of Rabbi Dovid & Arielle Lasson on the Birth of Twin Girls, Atara & Chana. And...in Honor of Reb Fishel Gross for All He Does for the Baltimore Community---Turning of the dafGreg HaberFor ופרנסה בריאות הצלחה ברכה for my entire family, Rav Eli &everyone learning the daf

birth bh omer dov yisroel neshama sotah daf yomi atara david kramer

Both Victory and Security Guarantee for Ukraine

Play Episode Listen Later Mar 2, 2023 56:03

Eliot and Eric chew over the developments in Ukraine. They consider divisions within and among West European governments, the question of what defeat of Russia and victory for Ukraine means in practical terms, the lingering overestimation of Russian possibilities and underestimation of Ukrainian potential on the battlefield, and the potential role of China providing lethal aid to Russia. They conclude with a discussion about making the U.S. the arsenal of democracy in the West and globally and the use and abuse of historical analogies. Shield of the Republic is a Bulwark podcast co-sponsored by the Miller Center of Public Affairs at the University of Virginia. Email us with your feedback at shieldoftherepublic@gmail.com. HMS Belfast “NATO's Biggest European Members Float Defense Pact With Ukraine” by Wall Street Journal “How Putin blundered into Ukraine — then doubled down” by Financial Times Timothy Snyder's Essay Debunking Vladimir Putin's Essay Written After Consuming Hallucinogens, “How to think about war in Ukraine” Eliot's Article on the False Historical Lessons from World War II, “Military History Doesn't Say What Ukraine's Critics Think” “Every Man His Own Historian” by Carl L. Becker Eliot's Foreign Affairs Essay, “Move Fast and Win Things” Thinking In Times by Ernest May and Richard Neustadt Eric's Article with David Kramer and Vlad Kobets, “Ukraine and Belarus Are Fighting the Same War” Eric's Article with David Kramer and Ben Parker, “Moldova Is Putin's Next Target” “After the Fall. Must We Prepare for the Breakup of Russia?” by Bruno Tertrais Senior Policy Analyst Jewish Institute for National Security of America Learn more about your ad choices. Visit podcastchoices.com/adchoices

Both Victory and Security Guarantee for Ukraine

Play Episode Listen Later Mar 2, 2023 56:03

Does NATO Want Ukraine to Win the War?

ukraine western nato david kramer ap african american

Play Episode Listen Later Jan 27, 2023 54:11

The George W. Bush Institute's David Kramer joins B2D to consider the decision (at last) to send tanks to Ukraine. What does the dithering say about the Western alliance? Also, the regulars discuss Florida's rejection of an AP African American studies curriculum. highlights/lowlights: Damon's: https://www.nytimes.com/2023/01/25/opinion/rural-voters-republican-realignment.html Bill's: https://www.huffpost.com/entry/scientists-welcome-george-santos-science-committee_n_63cacb34e4b01a436386951e Linda's: https://www.nytimes.com/2023/01/26/us/politics/durham-trump-russia-barr.html Mona's: https://www.nytimes.com/2023/01/10/world/europe/finland-misinformation-classes.html Learn more about your ad choices. Visit podcastchoices.com/adchoices

Does NATO Want Ukraine to Win the War?

ukraine western nato david kramer ap african american

Play Episode Listen Later Jan 27, 2023 49:11

Anti-Trust Enforcement and the FTC Proposal to Ban Non-Competition Agreements

competition proposal ftc agreements justice department enforcement antitrust federal trade commission david kramer

Play Episode Listen Later Jan 23, 2023 34:28

Scott S. Moore talks to David Kramer about the activity by the Justice Department, states and the Federal Trade Commission to place greater restrictions on non-competition agreement by employers, including the FTC's recent proposal to ban workplace based non-competition agreements.

Famous Estate Disputes: Lessons Learned

martin luther king jr lessons learned estate robin williams disputes joan crawford thomas kinkade david kramer

Play Episode Listen Later Jan 12, 2023 27:19

In this episode, Krista Eckhoff joins David Kramer to discuss famous estate disputes, including Robin Williams, Prince, Martin Luther King Jr., Thomas Kinkade, and Joan Crawford, and the lessons learned from those estates. Tune in for some interesting stories and tips for your own estate planning.

Episode 10: David Kramer, Director of Sales at Magpul Industries Corp.

Taurus By the Horns

Play Episode Listen Later Dec 2, 2022 72:28

This month, Jessie and KC end the year in true patriotic style from the home of David Kramer, aka, DK. And by patriotic, we mean there are literally 20 U.S. flags adorning his home office alone!For those of you who don't know DK, he boasts more than 30 years of outdoor industry experience and has been a Director of Sales at Magpul Industries Corp. since 2017.Listen in as DK dives deep into his storied career—from his earliest days working in the camping/hunting retail sector to becoming an independent rep for a large portfolio of outdoor brands to his current, most-enviable role at Magpul.DK also discusses his calling as a founder of the Special Operations Care Fund (SOC-F)—a non-profit organization that helps provide medical, financial and other support to SOF families who have given so much for our country and our freedom.

director sales industries corp sof dk david kramer magpul

The World Order

university time ukraine tragedy vladimir putin republic retreat nato shield public affairs negotiate eliot world order bulwark miller center us russian john mearsheimer david kramer stephen walt

Play Episode Listen Later Nov 23, 2022 44:56

Eric and Eliot welcome Georgetown Professor Emeritus Robert Lieber to discuss his new book, Indispensable Nation. They discuss the nature of the "rules-based" international order, the unique role that U.S. policy plays in sustaining the order, the true disruptive challenges to the order, the nature of political opposition to a robust U.S. foreign policy, political "realism" and its flaws, as well as the increasing challenges for teaching of international relations in the academy. Shield of the Republic is a Bulwark podcast co-sponsored by the Miller Center of Public Affairs at the University of Virginia. Email us with your feedback at shieldoftherepublic@gmail.com. Eliot's “Cut the Baloney Realism” or “Stop Talking About Talking" (https://www.theatlantic.com/ideas/archive/2022/11/russia-ukraine-negotations-mark-milley/672198/) Robert Lieber's Indispensable Nation (https://www.amazon.com/gp/product/B0B5MH82TV/ref=dbs_a_def_rwt_bibl_vppi_i0) Robert Lieber's Retreat And Its Consequences (https://www.amazon.com/Retreat-its-Consequences-American-Foreign/dp/1316506711) Team America: World Police Hans Blix Scene (https://www.youtube.com/watch?v=5TEvacFETvM) Andrey Sushentsov and William Wohlforth's "The tragedy of US–Russian relations: NATO centrality and the revisionists' spiral” (https://www.proquest.com/docview/2405756420) John Mearsheimer's Revealing Interview With The New Yorker (https://www.newyorker.com/news/q-and-a/john-mearsheimer-on-putins-ambitions-after-nine-months-of-war) “Yes, It's Anti-Semitic:” Eliot's Review of The Israel Lobby by John Mearsheimer and Stephen Walt (https://www.washingtonpost.com/archive/opinions/2006/04/05/yes-its-anti-semitic/e7de5f13-60d5-4567-9090-8d24c8237801/) Robert Lieber's Review of John Mearsheimer's The Tragedy of Great Power Politics (https://www.psqonline.org/article.cfm?IDArticle=14655) Eric and David Kramer's “Now Is Not the Time to Negotiate with Putin” (https://www.thebulwark.com/now-is-not-the-time-to-negotiate-with-putin/) Eric and David Kramer's “Don't Go Wobbly on Ukraine" (https://www.americanpurpose.com/articles/dont-go-wobbly-on-ukraine/) Learn more about your ad choices. Visit podcastchoices.com/adchoices

The World Order

Play Episode Listen Later Nov 23, 2022 44:56

Class Actions 101 for Businesses

class businesses david kramer

Play Episode Listen Later Nov 8, 2022 29:48

Allie Balus talks to David Kramer about what businesses need to know about class actions—what defending against a class action entails, common types of class actions over business practices, and ways to mitigate risks now for when you face a class action later.

Ukraine Update (David Kramer)

Kremlin File

Play Episode Listen Later Oct 6, 2022 53:10

Olga and Mo are back for season 3 of Kremlin File hosts with returning guest David Kramer for an update on Ukraine. Learn more about your ad choices. Visit megaphone.fm/adchoices

ukraine ukraine update david kramer kremlin file

Imperial Russia, Past and Present (with John Herbst)

university russia ukraine ambassadors republic administration biden administration herbst public affairs eliot bulwark miller center imperial russia orange revolution david kramer darya dugina

Play Episode Listen Later Aug 27, 2022 53:20

Eric welcomes back Eliot from travels and illness to host John Herbst who was the U.S. Ambassador to Ukraine during the Orange Revolution. They discuss Russia's imperial past and present, the Biden Administration's 3 billion dollar military assistance package, the course of the war, the assassination of Darya Dugina, and the prospects for diplomacy and grade the Administration's efforts to manage the Ukraine crisis. Links: Eric's article co-authored with Daniel Fata, David Kramer, and Stephen Biegun The open letter organized by John Herbst and signed by Eric Shield of the Republic is a Bulwark podcast co-sponsored by the Miller Center of Public Affairs at the University of Virginia. Email us with your feedback at shieldoftherepublic@gmail.com. Learn more about your ad choices. Visit podcastchoices.com/adchoices

Imperial Russia, Past and Present (with John Herbst)

university russia ukraine ambassadors republic administration biden administration herbst public affairs eliot bulwark miller center imperial russia orange revolution david kramer darya dugina

Play Episode Listen Later Aug 27, 2022 53:20

Wearing Russian Sanctions like a Badge of Honor (with David Kramer)

Play Episode Listen Later Jun 30, 2022 48:05

Eric and Eliot return with special guest David Kramer, the Managing Director of Global Policy at the George W. Bush Institute and former Assistant Secretary of State for Democracy, Human Rights, and Labor, and who incidentally has just been sanctioned by the Russian government (wear it as a badge of honor David!). They discuss the status of the war in Ukraine, the nature of the Russian regime, the prospects for change in Russia, the economic state of the war, and much more. Email us with your feedback at shieldoftherepublic@gmail.com. Shield of the Republic is a Bulwark podcast co-sponsored by the Miller Center of Public Affairs at the University of Virginia. Learn more about your ad choices. Visit podcastchoices.com/adchoices

Wearing Russian Sanctions like a Badge of Honor (with David Kramer)