Podcasts about technical architecture

Join Andrew Wesbecher (Powered_By) and Michael Krigsman on CXOTalk episode 878 to discuss how AI agents can help small businesses succeed in 2025. Learn from industry experts and discover the benefits of using AI technology for your SMB to stay ahead of the competition!Learn more from www.poweredby.agency===================

Dark Patterns in Recommendation Systems: Beyond Technical Capabilities1. Engagement Optimization PathologyMetric-Reality Misalignment: Recommendation engines optimize for engagement metrics (time-on-site, clicks, shares) rather than informational integrity or societal benefitEmotional Gradient Exploitation: Mathematical reality shows emotional triggers (particularly negative ones) produce steeper engagement gradientsBusiness-Society KPI Divergence: Fundamental misalignment between profit-oriented optimization and societal needs for stability and truthful informationAlgorithmic Asymmetry: Computational bias toward outrage-inducing content over nuanced critical thinking due to engagement differential2. Neurological Manipulation VectorsDopamine-Driven Feedback Loops: Recommendation systems engineer addictive patterns through variable-ratio reinforcement schedulesTemporal Manipulation: Strategic timing of notifications and content delivery optimized for behavioral conditioningStress Response Exploitation: Cortisol/adrenaline responses to inflammatory content create state-anchored memory formationAttention Zero-Sum Game: Recommendation systems compete aggressively for finite human attention, creating resource depletion3. Technical Architecture of ManipulationFilter Bubble ReinforcementVector similarity metrics inherently amplify confirmation biasN-dimensional vector space exploration increasingly constrained with each interactionIdentity-reinforcing feedback loops create increasingly isolated information ecosystemsMathematical challenge: balancing cosine similarity with exploration entropyPreference Falsification AmplificationSupervised learning systems train on expressed behavior, not true preferencesEngagement signals misinterpreted as value alignmentML systems cannot distinguish performative from authentic interactionTraining on behavior reinforces rather than corrects misinformation trends4. Weaponization MethodologiesCoordinated Inauthentic Behavior (CIB)Troll farms exploit algorithmic governance through computational propagandaInitial signal injection followed by organic amplification ("ignition-propagation" model)Cross-platform vector propagation creates resilient misinformation ecosystemsCost asymmetry: manipulation is orders of magnitude cheaper than defenseAlgorithmic Vulnerability ExploitationReverse-engineered recommendation systems enable targeted manipulationContent policy circumvention through semantic preservation with syntactic variationTime-based manipulation (coordinated bursts to trigger trending algorithms)Exploiting engagement-maximizing distribution pathways5. Documented Harm Case StudiesMyanmar/Facebook (2017-present)Recommendation systems amplified anti-Rohingya contentAlgorithmic acceleration of ethnic dehumanization narrativesEngagement-driven virality of violence-normalizing contentRadicalization PathwaysYouTube's recommendation system demonstrated to create extremism pathways (2019 research)Vector similarity creates "ideological proximity bridges" between mainstream and extremist contentInterest-based entry points (fitness, martial arts) serving as gateways to increasingly extreme ideological contentAbsence of epistemological friction in recommendation transitions6. Governance and Mitigation ChallengesScale-Induced Governance FailureContent volume overwhelms human review capabilitiesSelf-governance models demonstrably insufficient for harm preventionInternational regulatory fragmentation creates enforcement gapsProfit motive fundamentally misaligned with harm reductionPotential CountermeasuresRegulatory frameworks with significant penalties for algorithmic harmInternational cooperation on misinformation/disinformation preventionTreating algorithmic harm similar to environmental pollution (externalized costs)Fundamental reconsideration of engagement-driven business models7. Ethical Frameworks and Human RightsEthical Right to Truth: Information ecosystems should prioritize veracity over engagementFreedom from Algorithmic Harm: Potential recognition of new digital rights in democratic societiesAccountability for Downstream Effects: Legal liability for real-world harm resulting from algorithmic amplificationWealth Concentration Concerns: Connection between misinformation economies and extreme wealth inequality8. Future OutlookIncreased Regulatory Intervention: Forecast of stringent regulation, particularly from EU, Canada, UK, Australia, New ZealandDigital Harm Paradigm Shift: Potential classification of certain recommendation practices as harmful like tobacco or environmental pollutantsMobile Device Anti-Pattern: Possible societal reevaluation of constant connectivity modelsSovereignty Protection: Nations increasingly viewing algorithmic manipulation as national security concernNote: This episode examines the societal implications of recommendation systems powered by vector databases discussed in our previous technical episode, with a focus on potential harms and governance challenges.

Technical Architecture for Digital IndependenceCore ConceptSmartphones represent a monolithic architecture that needs to be broken down into microservices for better digital independence.Authentication StrategyHardware security keys (YubiKey) replace mobile authenticatorsUSB-C insertion with button pressMore convenient than SMS/app-based 2FARequires backup key strategyOffline authentication optionsLocal encrypted SQLite password databaseAir-gapped systemsBackup protocolsDevice Distribution ArchitectureCore Components:Dumbphone/flip phone for basic communicationOffline GPS device with downloadable mapsUtility Android tablet ($50-100) for specific appsLinux workstation for developmentImplementation:SIM transfer protocols between carriersData isolation techniquesOffline-first approachDevice-specific use casesData StrategyCloud Migration:iCloud data extractionLocal storage solutionsPrivacy-focused sync servicesEncrypted remote storage with rsyncLinux Migration:Open source advantagesReduced system overheadNo commercial spywarePowers 90% of global infrastructureNetwork ArchitectureDistributed Connectivity:Pay-as-you-go hotspotsMinimal data plan requirementsImproved security through isolationUse Cases:Offline maps for navigationBatch downloading for podcastsHome network sync for updatesGarage WiFi for car updatesCost BenefitsStandard smartphone setup: ~$5,000/yeariPhone upgradesData plansCloud servicesMicroservices approach:Significantly reduced costsBetter concentrationImproved controlEnhanced privacyKey TakeawaySoftware engineering perspective suggests breaking monolithic mobile systems into optimized, offline-first microservices for better functionality and reduced dependency.

(Enregistré le 31 décembre 2024)Ce 808ème et dernier épisode de l'année 2024 du NFT Morning nous a permis de dresser un bilan complet de cette année qui vient dans s'écouler, dans les écosystèmes crypto et NFT avec en invité de marque le seul et l'unique TheCryptomath.1. Bitcoin au centre de l'attention* L'année a été marquée par un retour en force du Bitcoin, atteignant les 100 000 USD en décembre, notamment après le halving d'avril et l'élection américaine en novembre.* Les ETF Bitcoin, validés dès janvier, ont renforcé la crédibilité et l'attractivité de cette crypto, qui est restée le moteur principal du marché tout au long de l'année.2. NFT et Ordinals* Les Ordinals sur Bitcoin ont continué à attirer l'attention, notamment avec des collections comme les Node Monkeys ou les Quantum Cats. Bien que l'engouement ait connu des hauts et des bas, ils ont bénéficié d'un regain d'intérêt en fin d'année.* Les collections PFP (Profile Picture) traditionnelles, comme Pudgy Penguins, Azuki et Doodles, ont vu un regain d'activité, porté par des airdrops et des stratégies innovantes comme le lancement de nouvelles infrastructures (Ape Chain, Abstract).3. Altcoins, MemeCoins et innovation* Les MemeCoins ont volé la vedette aux altcoins classiques avec des projets comme PEPE, Doge ou encore des tokens issus de la plateforme Pump.fun.* Les agents IA ont également marqué l'année, introduisant une nouvelle dynamique à l'intersection entre utilité et spéculation.4. Une année dominée par les airdrops* 2024 a été l'année des airdrops, avec des événements marquants comme celui d'Hyperliquide. Ces distributions gratuites ont fortement mobilisé les communautés et généré d'importants volumes d'activité.5. Solana et les nouvelles infrastructures* Solana a fait un retour remarquable, dépassant ses anciens records. Le dynamisme des nouvelles blockchains et des Layers 2 (comme Abstract) a créé de nouvelles opportunités, notamment dans le domaine des NFTs.6. Tendances et débats* Une montée en puissance des projets "fair launch" et une volonté de réduire l'influence des VC (venture capitalists) dans l'écosystème.* Des questions restent ouvertes sur la pérennité de ces tendances, notamment autour de la durabilité des MemeCoins et du potentiel des nouvelles infrastructures NFT.Cette room, riche en analyses, a permis de mettre en lumière les dynamiques marquantes de l'année écoulée tout en ouvrant des perspectives pour 2025.La Phrase Clé de l'Épisode"2024, c'était Bitcoin, MemeCoins et airdrops : une année où le pouvoir est revenu aux communautés, loin des VC et des modèles classiques."The Cryptomath.Pour aller plus loin:* Bilan du Bitcoin en 2024 :Un article détaillant la progression du Bitcoin, notamment l'approbation des ETF et l'impact du halving.Bitcoin more than doubles in 2024 on spot ETF approval, Trump euphoria* L'essor des MemeCoins :Une analyse des performances des principales MemeCoins en 2024, y compris PEPE.Dogecoin, Pepe and Other Top Meme Coins Fall as Focus Shifts ... - Decrypt* Ordinals sur Bitcoin :Une exploration de l'architecture technique des Quantum Cats et leur évolution sur la blockchain Bitcoin.The Technical Architecture of the Quantum Cats - Bitcoin Magazine* Airdrops en 2024 :Un rapport sur les airdrops majeurs de l'année, notamment celui d'Hyperliquid.Hyperliquid airdrops over $1.2 billion worth of tokens to users as HYPE ...* Agents IA et innovation dans la crypto :Un guide sur les tokens crypto liés à l'IA à surveiller en 2024.Top AI Crypto Tokens to Watch in 2024 | GamingArena - Medium* Le grand retour de Solana :Un rapport détaillé sur les performances de Solana au troisième trimestre 2024.State of Solana Q3 2024 | Messari* Replay vidéo de ce 808ème épisode This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit www.nftmorning.com

Artificial Intelligence has made extraordinary advancements, but a critical challenge remains: the gap between synthetic data and real human intelligence. In this episode of TARTLECAST, Alexander McCaig and Jason Rigby delve into the concept of the "synthetic ceiling" — the inherent limitations of AI systems reliant on synthetic and scraped data. They discuss how this disconnect, often leading to "synthetic drift," impacts the accuracy, adaptability, and ethical considerations of AI models. The hosts introduce TARTLE's revolutionary approach to bridging this gap using Real-Time Human Feedback (RTHF) and ethically sourced zero-party data. By creating a "Human Resonance Loop," TARTLE allows AI to align with real human behaviors, improving model accuracy, reducing bias, and enhancing contextual understanding. Key Topics Discussed: 1. The Synthetic Ceiling & Synthetic Drift Definition of the "synthetic ceiling": A barrier preventing AI from achieving human-like reasoning. Explanation of "synthetic drift": The gradual disconnection between AI models and real human behaviors due to over-reliance on synthetic data. 2. The Reality Gap in AI Challenges in AI performance caused by the lack of real-world context. The measurable disconnect between test scenarios and real-world applications. Insights into the "Data Vitality Score" as a measure of dataset relevance to human behavior. 3. The TARTLE Difference Introduction to ethically sourced zero-party data and Real-Time Human Feedback. How TARTLE creates a "Human Resonance Loop" to align AI predictions with human intuition. Real-world results: 30% improvement in AI model accuracy and 60% faster development cycles. 4. Technical Architecture of Real Intelligence Integration Foundations of TARTLE's approach: Zero-Party Data: Direct, consent-based user information. Human Feedback Loops: Continuous refinement through dynamic, real-world input. Contextual Enhancement Layers: Incorporating experiential knowledge, emotional context, and cultural nuances. 5. Philosophical Implications of Human-AI Collaboration Why human intelligence cannot be replicated but must be integrated into AI. The ethical necessity of consent in data sourcing. Creating symbiotic relationships where AI enhances human decision-making without replacing it. 6. Future Applications and Scalability The role of TARTLE in creating AI systems that evolve with human behaviors. Scalable solutions for data scientists, AI developers, and ethical businesses. Key Takeaways: AI Needs Real Intelligence: Synthetic data alone is insufficient for achieving true AI potential. Real human data provides the context, adaptability, and emotional resonance needed for advanced AI models. Ethical AI Starts with Consent: TARTLE's approach emphasizes permission-based data sharing, ensuring privacy and trust. Scalable Impact: With TARTLE's platform, AI systems continuously evolve, grounded in the richness of real human input. Quotes from the Episode: “Without consent, AI models hit a synthetic ceiling they cannot break through.” “AI can only achieve neural resonance when it integrates real human feedback.” “TARTLE isn't just about building better AI; it's about redefining human-AI collaboration.” Connect with TARTLE: Website: TARTLE.co Subscribe & Review: Enjoyed this episode? Subscribe to TARTLECAST on your favorite podcast platform and leave us a review! Join the TARTLE Movement: Sign up to share your data ethically and make a global impact: www.tartle.co Stay Tuned: In the next episode, we'll dive into real-world AI applications transforming industries through TARTLE's platform. Don't miss it!

Host Sriram Viswanathan speaks with Andy Lee and Anand Chandrasekaran from Crescendo AI about the transformative impact of AI on the customer service and call center industry. The conversation covers Crescendo's unique approach to integrating AI in business process outsourcing, the dynamics of the sector, and the potential future of human-AI collaboration. Discover how AI is poised to disrupt and enhance the BPO industry, and why Crescendo AI is at the forefront of this technological revolution. Chapters 00:00 Introduction to AI in Customer Service 02:48 Dynamics of the Contact Center Industry 06:09 Crescendo AI: Founders and Vision 08:58 AI's Impact on Customer Interactions 11:54 Technical Architecture of Crescendo AI 15:06 Market Strategy and Customer Experience 17:56 Scaling and Growth of Crescendo AI 21:03 Future of AI in Customer Service 24:00 Conclusion and Future Outlook Links https://crescendo.ai/ https://www.alorica.com/ https://www.generalcatalyst.com/

In this episode of the Business of Laravel Podcast, Matt Stauffer sits down with Matthew Davis, the CTO of Mumsnet, a leading social platform for parents in the UK. They discuss Mumsnet's full-scale transition to Laravel, unpacking the challenges and victories of their ground-up rewrite. They dive into the technical architecture behind their hosting and how they're leveraging machine learning to personalize content for their users. The discussion also covers the nuances of hiring Laravel developers and why finding the right culture fit is crucial for avoiding micromanagement and fostering independence in the workplace. Matthew Davis offers incredible insights on building trust between engineering and product teams and highlights how Laravel can be a game-changer for boosting productivity and driving real business value.Matt Stauffer TwitterTighten WebsiteMatthew Davis Twitter Mumsnet WebsiteMumsnet LinkedInRandical Candor Book Conflicted by Ian Leslie Growth Levers by Matt Lerner Matt Stauffer's Empathy Gives You Superpowers Talk - Laracon EU 2015 -----Editing and transcription sponsored by Tighten.

We're joined by Joyce Peralta to explore McGill's "Web Standards", the key to managing 1,500 sites & transforming their digital landscape. Learn how your organization can benefit too!

From October 11, 2022 - David Leech is a vCISO using his global, operational, program management, and security experience together with leadership skills to drive digital transformation, product innovation, and risk reduction for business growth, involving work across Risk Management, Technical Architecture, Control Frame Works, HIPAA, FFIEC, PCI, HITRUST, FedRamp, and SOC compliance. He has supported clients in multiple sectors, including Finance, Manufacturing, Insurance, Healthcare and GovEd. --- Send in a voice message: https://podcasters.spotify.com/pod/show/virtual-ciso-moment/message

David Leech is a vCISO using his global, operational, program management, and security experience together with leadership skills to drive digital transformation, product innovation, and risk reduction for business growth, involving work across Risk Management, Technical Architecture, Control Frame Works, HIPAA, FFIEC, PCI, HITRUST, FedRamp, and SOC compliance. He has supported clients in multiple sectors, including Finance, Manufacturing, Insurance, Healthcare and GovEd. --- This episode is sponsored by · Anchor: The easiest way to make a podcast. https://anchor.fm/app --- Send in a voice message: https://anchor.fm/virtual-ciso-moment/message Support this podcast: https://anchor.fm/virtual-ciso-moment/support

Discover new ways to think about ethical engineering

A full zero trust architecture goes up and down the stack, bringing in policy and enforcement strategies from the application layer, all the way down into the network. On today's Heavy Networking podcast we discuss zero trust network access, or ZTNA, with sponsor Fortinet. ZTNA is but one part of a robust zero trust architecture, but what a crucial component it is. Alex Samonte, Director of Technical Architecture, joins us to get into nerdy specifics about Fortinet's ZTNA.

A full zero trust architecture goes up and down the stack, bringing in policy and enforcement strategies from the application layer, all the way down into the network. On today's Heavy Networking podcast we discuss zero trust network access, or ZTNA, with sponsor Fortinet. ZTNA is but one part of a robust zero trust architecture, but what a crucial component it is. Alex Samonte, Director of Technical Architecture, joins us to get into nerdy specifics about Fortinet's ZTNA. The post Heavy Networking 647: Fortinet’s ZTNA Differentiation Starts With The OS (Sponsored) appeared first on Packet Pushers.

A full zero trust architecture goes up and down the stack, bringing in policy and enforcement strategies from the application layer, all the way down into the network. On today's Heavy Networking podcast we discuss zero trust network access, or ZTNA, with sponsor Fortinet. ZTNA is but one part of a robust zero trust architecture, but what a crucial component it is. Alex Samonte, Director of Technical Architecture, joins us to get into nerdy specifics about Fortinet's ZTNA.

A full zero trust architecture goes up and down the stack, bringing in policy and enforcement strategies from the application layer, all the way down into the network. On today's Heavy Networking podcast we discuss zero trust network access, or ZTNA, with sponsor Fortinet. ZTNA is but one part of a robust zero trust architecture, but what a crucial component it is. Alex Samonte, Director of Technical Architecture, joins us to get into nerdy specifics about Fortinet's ZTNA. The post Heavy Networking 647: Fortinet’s ZTNA Differentiation Starts With The OS (Sponsored) appeared first on Packet Pushers.

A full zero trust architecture goes up and down the stack, bringing in policy and enforcement strategies from the application layer, all the way down into the network. On today's Heavy Networking podcast we discuss zero trust network access, or ZTNA, with sponsor Fortinet. ZTNA is but one part of a robust zero trust architecture, but what a crucial component it is. Alex Samonte, Director of Technical Architecture, joins us to get into nerdy specifics about Fortinet's ZTNA.

A full zero trust architecture goes up and down the stack, bringing in policy and enforcement strategies from the application layer, all the way down into the network. On today's Heavy Networking podcast we discuss zero trust network access, or ZTNA, with sponsor Fortinet. ZTNA is but one part of a robust zero trust architecture, but what a crucial component it is. Alex Samonte, Director of Technical Architecture, joins us to get into nerdy specifics about Fortinet's ZTNA. The post Heavy Networking 647: Fortinet’s ZTNA Differentiation Starts With The OS (Sponsored) appeared first on Packet Pushers.

Keeping a Drupal site up-to-date can be tricky and time consuming. Host Matt Kleve sits down with three people in the Drupal community who have been working to make that process easier and faster.

Meighan Brodkey is a Director of Technical Architecture at Vorys. With a background in language and religious studies, she had a fairly smooth transition over to coding. She saw it as the technical version of translating numbers and letters.    Today, she not only works in technical architecture but is also heavily involved in the Salesforce community. She works a lot with other women in tech and within the Ohana Slack workspace. She is joining us on the show today to talk about all of these things, Slack integrations, and what she does in her current role.   Show Highlights: Meighan's college journey and first coding experiences. How she got involved with Salesforce and became an architect. Her passion for connecting people. The various communities she is involved with. What got her into Slack and the work she's done with Slack integrations. The basic structure of Slack apps. What the block kit builder is. A quick overview of GDPR.   Links: Meighan on Twitter: https://twitter.com/meighansf Meighan on LinkedIn: https://Linkedin.com/in/meighanbrodkey Meighan on Github: https://Github.com/meighan Meighan's blog: https://meighanrockssf.com Join Ohana Slack: https://join.slack.com/t/salesforceohana/shared_invite/zt-1atj9vqqu-tJvNMMzizu9ZvQ5YQPK0bw

Welcome to episode 4, discussing the architectural developments in EHDEN, within Work Package 4, co-led by Julia Kurps, Team Lead of the Real World Data Team, The Hyve, and Michel Van Speybroeck, Director, Data Sciences, Janssen. We explore the considerable opportunity, challenges and innovation required to develop a central Portal for EHDEN than can support research and collaboration between Data Partners and researchers. Julia and Michel discuss their own unique backgrounds and careers, and then we investigate the work they are co-leading with WP4 colleagues across diverse public and private organisations to build the EHDEN Portal, central to both the sustainability and the use of EHDEN in conducting open science research using OMOP-mapped data at scale for network studies. In the main body of the discussion, Julia and Michel outline what EHDEN is working to achieve with the Portal build, encompassing discoverability via a Catalogue through to standardised analytics (in collaboration with OHDSI) and an Evidence Hub. Furthermore, EHDEN is extending the OHDSI analytical tools, as well as supporting methodological aspects within an integrated framework, while incorporating processes, procedures and governance. Overall, this is within a wider ecosystem of Data Partners and researchers, inclusive of the Portal, but also training support via, e.g., the EHDEN Academy. Innovation, described in the discussion, has to be sustainable, inclusive of a wider and growing community of those who can conduct open science research themselves, with diverse use cases, such as in Health Technology Assessment, Pharmaceuticals, or with Data Partners, all who have specific expectations, requiring a balance within a technical architecture. The views expressed by the participants are personal and not necessarily reflective of their organisations.

Rakesh has 14 plus years rich experience in leading and successfully delivering big data and cloud data analytics multi million dollar programs. He is a senior cloud data architect working in Anthem Inc. creating data design solutions, implementing data platforms on premise and on cloud, managing stakeholders, providing technical mentorship and building teams.

In this episode of The Outspoken Podcast, host Shana Cosgrove talks to Fred Fauth, Vice President at Nexxis Solutions, about his current professional role and the varying architecture for his current and past companies. We get to hear about his side businesses including renting out properties, One Project Closer, and the benefits and experiences he has gained from them. Fred also speaks on growing up, college,  and how it all led him to a life around computer science. QUOTES "If an employee feels like, ‘I go into work everyday and I make a meaningful contribution to the world, to this customer space,' and the customer comes out and says, ‘I love the people, I love the engineering, I love the results I get from this small business,' that's a match that is really unparalleled." - Fred Fauth [14:56] “Our thought process around this is, if you do what's right for your customers and your employees, and that relationship is killing it, and you're being really thoughtful about the fiscal aspects of the business so that you're making good decisions, that should leave a lot left over to make a big difference in the local community.” - Fred Fauth [16:13] Word of mouth is one thing - 'yeah you should come in and meet this person.' But it's really great if it's 'You should come in and meet this person, and by the way go check out the website and you'll see everything you need to know about working for this place.' It's all about multiple brand impressions and building relationships with folks through multiple venues.” - Fred Fauth [27:29] TIMESTAMPS  [00:04] Intro [01:32] Meet Fred Fauth [01:56] Capture and Meeting Shana [06:05] Role at Nexxis Solutions [07:52] Small Companies [10:44] Hiring Expert Support [13:06] Architecture for Praxis vs. Nexxis [16:59] Shana and Fred's First Lunch [20:09] Technical Architecture [23:43] Working from Home [25:31] Nyla Technology Solutions [26:06] Website Development [28:43] Growing Up [34:34] College [36:09] Booz Allen [37:59] Fred's Wife and Children [41:23] Side Businesses [49:13] Being Busy in a Relationship [50:35] Wrap-Up Questions [53:21] Outro RESOURCES https://www.praxiseng.com/ (Praxis Engineering) https://www.boozallen.com/ (Booz Allen Hamilton) https://slack.com/ (Slack) https://www.squarespace.com/ (Squarespace) https://www.loyola.edu/ (Loyola University Maryland) https://www.airbnb.com/ (Airbnb) https://www.amazon.com/Simple-Path-Wealth-financial-independence/dp/1533667926/ref=sr_1_1?crid=1PAK86DL0KBD3&dchild=1&keywords=the+simple+path+to+wealth&qid=1623039732&sprefix=the+simple+pa%2Caps%2C173&sr=8-1 (The Simple Path to Wealth) by J L Collins RELEVANT LINKS https://www.linkedin.com/in/ffauth/ (Fred Fauth on LinkedIn) https://www.nexxissolutions.com/ (Nexxis Solutions) https://www.oneprojectcloser.com/ (One Project Closer) https://nylatechnologysolutions.com/ (Nyla Technology Solutions)   I'd love to hear from you -- your feedback is important to me and I read all of it. If you enjoyed the podcast, I hope you'll give us 5 stars. I'll be sure to thank you via email. If not, let me know what you think we should do differently. Don't forget to hit “subscribe” so you'll receive notifications about guest interviews and other topics that drop every Tuesday. Live well, Shana

We had 4 speakers in Technical Architecture and Leadership roles! Perfect opportunity for some technical talks from Black women in the industry. Details of speakers to follow! Speakers * Nana Fifield | VP of Engineering | Depop * Akua Apeagyei | Cloud solution Architect | Microsoft * Adiba Maduegbuna | Lead Android Engineer & Creative Technologist | Startups, ANIM Sessions * LaBrina Loving | Senior Software Engineer | Microsoft ---- Talks ---- Akua Apeagyei: Authenticating Users On Mobile Apps With Azure B2C Insight into Azure B2C and how it can be used to authenticate users. Adiba Maduegbuna: Mobile First to Creative Tech : 9 years onwards This talk is an overview of some of the most interesting projects I've worked on at different stages of my career. It covers the technical side of building prototypes and products for mobile devices, wearables & immersive experiences. Participants will leave with a better technical understanding of app development and augmented reality. LaBrina Loving: Leading Technical Solutions from Behind As a black female in tech, you are often met with bias and assumptions about your technical skills. As soon as you walk into the room, you invoke surprise followed by doubt about your abilities. This bias grows 10x when you ascend into more senior technical roles. In this talk, I will discuss some of the approaches I've learned over the years to build authentic trust and leadership among colleagues even when you start from behind. ---- Details of Speakers ----- Akua Apeagyei Cloud Solution Architect @ Microsoft, Speaker and founder of Anomaly's Views , a platform where I share my tech journey and all of the in-betweens to encourage people to pursue their career aspirations. Adiba Maduegbuna Adiba is an Android Engineer and creative technologist with industry experience across various corporations and startups. She holds a BSc in Computer Science from University College London. In 2019 she founded ANIM Sessions, a creative studio specialising in interactive virtual experiences. She also enjoys Djing and writing code in Kotlin. LaBrina Loving LaBrina Loving is a Senior Software Engineer and Cloud Architect at Microsoft with over 20 years of experience. In her role, she is focused on helping organizations migrate to Azure and modernize for cloud. She works with them to leverage the cloud for cutting edge technologies like Serverless, Containers, and DevOps. LaBrina is a speaker doing conferences and user groups all over the world and enjoys volunteering with many STEM organizations such as Black Girls Code. She has recently started a Podcast "Disrupting the Cloud" that highlights the journey of cloud newbies and professionals in cloud computing, especially women and BiPOC.

This episode is a conversation led by Greg Nokes, a Product Manager with Salesforce, Dan Mehlman, a Director of Technical Architecture for Salesforce, Mike Rose, a Director of Technical Architecture for Salesforce, Jack Ziesing, a Technical Architect with Salesforce. They're interviewing Nick Sawhney, a college student who saw an opportunity to make his friends laugh and built something that grew beyond his wildest dreams. At the 2021 US Inauguration, a single shot of Bernie Sanders sitting in a chair captured the hearts of many on the Internet. People everywhere were photoshopping him in the unlikeliest of places. Nick utilized his Python skills and quickly built a Heroku app that would allow users to place Bernie anywhere in the world, by adding him to any image available on Google Street View. To say the app was a success was an understatement. Inundated by tweets and distracted by press requests, Nick couldn't devote the time needed to keep the app stable and operational. He sent out a desperate tweet for help, only to be picked up by no less than Dan and Michael, who recruited Jack to help Nick with his operational issues. They paired together in a number of ways, optimizing Jack's Python code, securing its authentication logic, and autoscaling dynos in order to handle the waves of traffic. All of these rapid changes allowed Nick to step back and engage with fans on where they'd like to take Bernie next. In addition to a newfound gratitude towards Heroku's team, Nick learned a few lessons from this experience. He was really humbled by the availability of the engineering community to donate their time and knowledge to help his issues. It's also inspired him to create videos to teach others how they can mitigate scaling issues in their architecture before it becomes a problem. He's also hoping to create some open source tools that to monitor things like server costs and availability issues for other small projects.

In this episode we chat with Pallavi Hanson, Head of Software Engineering Flexential, about the state of the technical architecture in 2021. Pallavi shares her tips around seamless cloud migration, the value of understanding the customer lifecycle and how to navigate through changing tech trends. Hosted by Amna Omer, Global Communications Manager, Tkxel. --- Send in a voice message: https://anchor.fm/bettertech/message

Want a better strategy when it comes to your content for social media? Yes! Well, look no further as we are joined by Gary Evans on this episode. Gary is a fountain of knowledge when it comes to being online and how to attract an audience. He has a background in IT from System Engineering, Solutions and Technical Architecture and Web Design, and from there Gary founded Feedalpha and YourWeb.ie.   So if you want some real content strategy nuggets listen to this episode today.

James is the Chief Technology Officer Asia-Pacific at SEEK, the massive online job board. This episode was recorded on 5 June 2020 Hastened digitisation thanks to Covid-19 means the decisions CTOs make affect how everyone will work. Behind that is corporate coding culture, expected to become more like open source coding culture without the office. It's also a culture based on explaining yourself in the form of proposed changes to code rather than theoretical diagrams and strategies. James says this "levels the playing field greatly." Suggestions for topic or guest Contact the show - hello@postpandemic.xyz The 7 questions for every guest 1. What will be different about after the pandemic? 2. What do you think will become obsolete? 3. What will be different in your daily life? 4. What positives do you see coming from COVID19? 5. How do you think you’ll describe the pandemic to someone in the future that didn't experience it? 6. If you were to write a book, film or TV series about the global pandemic what would you call it? 7. What should we be paying attention to now that will affect life after the pandemic? Post Pandemic is hosted by Courtney Carthy Production by Nearly Media Cover artwork by Studio Baker Theme music created by Alex ShulginSee omnystudio.com/listener for privacy information.

John Daniel, who joins to talk about Unit Of Work, is a Salesforce MVP, Technical Architecture, Open-source active contributor. John was on show #13, talked about Monolithic to Modular. Main Points John’s self-introduction The definition of UoW How does UoW handle DMLs in a transaction? What would happen if the DMLs in UoW fail partially? How does UoW make the code cleaner and more business-oriented? What to do when we find bugs when using the open-source libraries? What is the benefit to convince the team to use Apex Common library where UoW is included? Are there situations where multiple UoW The post 55. Unit Of Work Design Pattern | John Daniel appeared first on SalesforceWay.

Rob Pinna is a 30-year high-tech veteran who is the Chief Product Officer at IronCore Labs. His passion is protecting the privacy of data stored in the cloud. Pinna says we shouldn’t build software and then make it secure. Instead, you want to bake privacy and security into the technical platform. That way the system is designed so that developers automatically just do the right thing. The conversation covers how complex it is to both provide security and privacy early and often, as well as deliver at a large enterprise. Accenture | SolutionsIQ’s Leslie Morse hosts at Southern Fried Agile in Charlotte, NC. The Agile Amped podcast is the shared voice of the Agile community, driven by compelling stories, passionate people, and innovative ideas. Together, we are advancing the impact of business agility. Podcast library: www.agileamped.com Connect with us on social media!  Instagram: https://www.instagram.com/agileamped/ LinkedIn: https://www.linkedin.com/company/solutionsiq/ Twitter: https://twitter.com/AgileAmped  

The W3C Technical Architecture Group (TAG) published a set of Ethical Web Principles on May 30, 2019 in order to provide an ethical framework when

In this # VDDD meetup, we will talk with Ora Egozi-Barzilai and Evelyn van Kelle about their experience with socio-technical architecture. Socio-technical refers to the interrelatedness of social and technical aspects of an organization. Specific for this meetup we will discuss how teams affect the boundaries between bounded contexts and vice versa. These effects will give challenges in the way we design software architecture and organize teams around software to be highly aligned with business goals.

Mike and Matt gather a fleet of Lullabots to talk the ins and outs of continuous integration (CI) in 2019.

Matt and Mike talk with Angie "Webchick" Byron, Nathaniel Catchpole, and Gábor Hojtsy about the next year's release of Drupal 9.

Albert Lopez is a USMEX fellow and Ph.D. candidate in History, Theory, and Criticism of Architecture at MIT. This seminar was recorded on February 20, 2019. For more information on USMEX events click here.

Neil Cattermull is a global Cloud technology influencer and leading independent analyst, who consults, educates, and delivers Cloud strategies for vendors and client organizations. His specialties include: Service Delivery Management, Business Continuity Management, Technical Architecture, Management Consulting, and Cloud Computing. He’s held multiple Director level positions at international banks and financial service delivery firms, such as IBM, Olivetti, ADP Telerate, Thomson Financial, Merrill Lynch, and West LB. He has created many startup technology firms and is ranked in the Top 50 for the technology market. Contact Neil: Twitter: @NeilCattermull LinkedIn: https://www.linkedin.com/in/neilcattermull/ Contact Avrohom: Web: https://asktheceo.biz Twitter: @avrohomg Instagram: @avrohomg INTERVIEW HIGHLIGHTS: 01:06 Recently, IBM was in the news regarding their merger with Red Hat. As someone who specializes in Corporate Mergers and Acquisitions, help us understand, why did IBM acquire Red Hat? 02:40 IBM Cloud PaaS is also built on open source technology. 03:32 What is Hybrid Cloud, and why are people interested in it? 04:52 For the layperson, what is the difference between Hybrid Cloud & Public Cloud? 07:21 Is IBM looking to compete with AWS with the Red Hat acquisition? 09:05 How to avoid Cloud sticker shock when migrating to IaaS / PaaS! 11:43 One of the reasons cited for IBM’s acquisition of Red Hat is their Kubernetes distribution. What is Kubernetes? What is Red Hat doing with it? And why is IBM interested in it? 14:02 Let’s talk about Mergers and Acquisitions in general. Why would a company want to acquire or merge with another company? 33:15 You need multiple lines of defense for Internet Security and Cybersecurity. 34:54 When starting a business, always start with the end in mind. QUESTIONS FROM THE AUDIENCE: 18:20 Neville Huang – CEO Neurozo Innovation, New Taipei City, Taiwan - It's said that IBM acquiring RedHat will have a significant impact on Cloud services. In your opinion, how will the prevalence of Cloud impact Cybersecurity? 20:40 Neville Gaunt - Founder MindFit Ltd, UK - What large corporate merger or acquisition has ever given 1+1 is greater than 2? 23:37 Jan Barbosa - Brand Ambassador at beBee Inc., Puerto Rico – Can you name two recent good mergers, and two really bad ones? 28:27 Paul Colmer, Digital architect, coach, and trainer with ALC Training & Consulting in Brisbane, Australia - Does the acquisition mean we'll see IBM hit the IoT consumer market....ala Alexa / Google Home? 30:55 Ken Herron - CMO UIB, Orlando, FL - For those of us who create Internet of Things Solutions for our customers, in 2019 what are the 3 top things we should be looking out for to improve the security of our solutions?

Tom Sliker started Broadstreet Consulting more than a decade ago, and has made Drupal a family affair. We dragged Tom out of the South Carolina swamps and into DrupalCamp Atlanta to get the scoop.

As a software engineer, it's your responsibility to write a good design doc so that your team knows how to solve the problem you're addressing. But what makes a design doc good, what should you include, and how should you write it? Angela shares all her tips so you can make your design docs as effective and helpful as possible. Written by Angela Zhang: https://twitter.com/zhangelaz Read by Abbey Rennemeyer: https://twitter.com/abbeyrenn Original article: https://fcc.im/2vAL4io Learn to code for free at: https://www.freecodecamp.org Intro music by Vangough: https://fcc.im/2APOG02 Transcript: As a software engineer, I spend a lot of time reading and writing design documents. After having gone through hundreds of these docs, I’ve seen first hand a strong correlation between good design docs and the ultimate success of the project. This article is my attempt at describing what makes a design document great. The article is split into 4 sections: Why write a design document What to include in a design document How to write it The process around it Why write a design document? A design doc — also known as a technical spec — is a description of how you plan to solve a problem. There are lots of writings already on why it’s important to write a design doc before diving into coding. So all I’ll say here is: A design doc is the most useful tool for making sure the right work gets done. The main goal of a design doc is to make you more effective by forcing you to think through the design and gather feedback from others. People often think the point of a design doc is to to teach others about some system or serve as documentation later on. While those can be beneficial side effects, they are not the goal in and of themselves. As a general rule of thumb, if you are working on a project that might take 1 engineer-month or more, you should write a design doc. But don’t stop there — a lot of smaller projects could benefit from a mini design doc too. Great! If you are still reading, you believe in the importance of design docs. However, different engineering teams, and even engineers within the same team, often write design docs very differently. So let’s talk about the content, style, and process of a good design doc. What to include in a design doc? A design doc describes the solution to a problem. Since the nature of each problem is different, naturally you’d want to structure your design doc differently. To start, the following is a list of sections that you should at least consider including in your next design doc: Title and People The title of your design doc, the author(s) (should be the same as the list of people planning to work on this project), the reviewer(s) of the doc (we’ll talk more about that in the Process section below), and the date this document was last updated. Overview A high level summary that every engineer at the company should understand and use to decide if it’s useful for them to read the rest of the doc. It should be 3 paragraphs max. Context A description of the problem at hand, why this project is necessary, what people need to know to assess this project, and how it fits into the technical strategy, product strategy, or the team’s quarterly goals. Goals and Non-Goals The Goals section should: describe the user-driven impact of your project — where your user might be another engineering team or even another technical system specify how to measure success using metrics — bonus points if you can link to a dashboard that tracks those metrics Non-Goals are equally important to describe which problems you won’t be fixing so everyone is on the same page. Milestones A list of measurable checkpoints, so your PM and your manager’s manager can skim it and know roughly when different parts of the project will be done. I encourage you to break the project down into major user-facing milestones if the project is more than 1 month long. Use calendar dates so you take into account unrelated delays, vacations, meetings, and so on. It should look something like this: Start Date: June 7, 2018 Milestone 1 — New system MVP running in dark-mode: June 28, 2018 Milestone 2 - Retire old system: July 4th, 2018 End Date: Add feature X, Y, Z to new system: July 14th, 2018 Add an [Update] subsection here if the ETA of some of these milestone changes, so the stakeholders can easily see the most up-to-date estimates. Current Solution In addition to describing the current implementation, you should also walk through a high level example flow to illustrate how users interact with this system and/or how data flow through it. A user story is a great way to frame this. Keep in mind that your system might have different types of users with different use cases. Proposed Solution Some people call this the Technical Architecture section. Again, try to walk through a user story to concretize this. Feel free to include many sub-sections and diagrams. Provide a big picture first, then fill in lots of details. Aim for a world where you can write this, then take a vacation on some deserted island, and another engineer on the team can just read it and implement the solution as you described. Alternative Solutions What else did you consider when coming up with the solution above? What are the pros and cons of the alternatives? Have you considered buying a 3rd-party solution — or using an open source one — that solves this problem as opposed to building your own? Monitoring and Alerting I like including this section, because people often treat this as an afterthought or skip it all together, and it almost always comes back to bite them later when things break and they have no idea how or why. Cross-Team Impact How will this increase on call and dev-ops burden? How much money will it cost? Does it cause any latency regression to the system? Does it expose any security vulnerabilities? What are some negative consequences and side effects? How might the support team communicate this to the customers? Discussion Any open issues that you aren’t sure about, contentious decisions that you’d like readers to weigh in on, suggested future work, and so on. Detailed Scoping and Timeline This section is mostly going to be read only by the engineers working on this project, their tech leads, and their managers. Hence this section is at the end of the doc. Essentially, this is the breakdown of how and when you plan on executing each part of the project. There’s a lot that goes into scoping accurately, so you can read this post to learn more about scoping. I tend to also treat this section of the design doc as an ongoing project task tracker, so I update this whenever my scoping estimate changes. But that’s more of a personal preference. How to write it Now that we’ve talked about what goes into a good design doc, let’s talk about the style of writing. I promise this is different than your high school English class. Write as simply as possible Don’t try to write like the academic papers you’ve read. They are written to impress journal reviewers. Your doc is written to describe your solution and get feedback from your teammates. You can achieve clarity by using: Simple words Short sentences Bulleted lists and/or numbered lists Concrete examples, like “User Alice connects her bank account, then …” Add lots of charts and diagrams Charts can often be useful to compare several potential options, and diagrams are generally easier to parse than text. I’ve had good luck with Google Drawing for creating diagrams. Pro Tip: remember to add a link to the editable version of the diagram under the screenshot, so you can easily update it later when things inevitably change. Include numbers The scale of the problem often determines the solution. To help reviewers get a sense of the state of the world, include real numbers like # of DB rows, # of user errors, latency — and how these scale with usage (remember your Big-O notations?). Try to be funny A spec is not an academic paper. Also, people like reading funny things, so this is a good way to keep the reader engaged. Don’t overdo this to the point of taking away from the core idea though. If you, like me, have trouble being funny, Joel Spolsky (obviously known for his comedic talents…) has this tip: One of the easiest ways to be funny is to be specific when it’s not called for [… Example:] Instead of saying “special interests,” say “left-handed avacado farmers.” Do the Skeptic Test Before sending your design doc to others to review, take a pass at it pretending to be the reviewer. What questions and doubts might you have about this design? Then address them preemptively. Do the Vacation Test If you go on a long vacation now with no internet access, can someone on your team read the doc and implement it as you intended? The main goal of a design doc is not knowledge sharing, but this is a good way to evaluate for clarity so that others can actually give you useful feedback. Process Ah yes, the dreaded P-word. Design docs help you get feedback before you waste a bunch of time implementing the wrong solution or the solution to the wrong problem. There’s a lot of art to getting good feedback, but that’s for a later article. For now, let’s just talk specifically about how to write the design doc and get feedback for it. First of all, everyone working on the project should be a part of the design process. It’s okay if the tech lead ends up driving a lot of the decisions, but everyone should be involved in the discussion and buy into the design. So the “you” throughout this article is a really plural “you” that includes all the people on the project. Secondly, the design process doesn’t mean you staring at the whiteboard theorizing ideas. Feel free to get your hands dirty and prototype potential solutions. This is not the same as starting to write production code for the project before writing a design doc. Don’t do that. But you absolutely should feel free to write some hacky throwaway code to validate an idea. To ensure that you only write exploratory code, make it a rule that none of this prototype code gets merged to master. After that, as you start to have some idea of how to go about your project, do the following: Ask an experienced engineer or tech lead on your team to be your reviewer. Ideally this would be someone who’s well respected and/or familiar with the edge cases of the problem. Bribe them with boba if necessary. Go into a conference room with a whiteboard. Describe the problem that you are tackling to this engineer (this is a very important step, don’t skip it!). Then explain the implementation you have in mind, and convince them this is the right thing to build. Doing all of this before you even start writing your design doc lets you get feedback as soon as possible, before you invest more time and get attached to any specific solution. Often, even if the implementation stays the same, your reviewer is able to point out corner cases you need to cover, indicate any potential areas of confusion, and anticipate difficulties you might encounter later on. Then, after you’ve written a rough draft of your design doc, get the same reviewer to read through it again, and rubber stamp it by adding their name as the reviewer in the Title and People section of the design doc. This creates additional incentive and accountability for the reviewer. On that note, consider adding specialized reviewers (such as SREs and security engineers) for specific aspects of the design. Once you and the reviewer(s) sign off, feel free to send the design doc to your team for additional feedback and knowledge sharing. I suggest time-bounding this feedback gathering process to about 1 week to avoid extended delays. Commit to addressing all questions and comments people leave within that week. Leaving comments hanging = bad karma. Lastly, if there’s a lot of contention between you, your reviewer, and other engineers reading the doc, I strongly recommend consolidating all the points of contention in the Discussion section of your doc. Then, set up a meeting with the different parties to talk about these disagreements in person. Whenever a discussion thread is more than 5 comments long, moving to an in-person discussion tends to be far more efficient. Keep in mind that you are still responsible for making the final call, even if everyone can’t come to a consensus. In talking to Shrey Banga recently about this, I learned that Quip has a similar process, except in addition to having an experienced engineer or tech lead on your team as a reviewer, they also suggest having an engineer on a different team review the doc. I haven’t tried this, but I can certainly see this helping get feedback from people with different perspectives and improve the general readability of the doc. Once you’ve done all the above, time to get going on the implementation! For extra brownie points, treat this design doc as a living document as you implement the design. Update the doc every time you learn something that leads to you making changes to the original solution or update your scoping. You’ll thank me later when you don’t have to explain things over and over again to all your stakeholders. Finally, let’s get really meta for a second: How do we evaluate the success of a design doc? My coworker Kent Rakip has a good answer to this: A design doc is successful if the right ROI of work is done. That means a successful design doc might actually lead to an outcome like this: You spend 5 days writing the design doc, this forces you to think through different parts of the technical architecture You get feedback from reviewers that X is the riskiest part of the proposed architecture You decide to implement X first to de-risk the project 3 days later, you figure out that X is either not possible, or far more difficult than you originally intended You decide to stop working on this project and prioritize other work instead At the beginning of this article, we said the goal of a design doc is to make sure the right work gets done. In the example above, thanks to this design doc, instead of wasting potentially months only to abort this project later, you’ve only spent 8 days. Seems like a pretty successful outcome to me.

Mike shares more first impressions of Qt, the surprising places we’ve found QML in the wild, and why or why not to use Qt. Plus we answer some questions, share some travel hacks, and discuss the top programing languages of 2018, as declared so by the IEEE.