What makes user stories effective in agile projects? This session goes through the reason we use user stories, tips and tricks and about slicing stories and story mapping.
The Whole Story - Mapping, Slicing and Figuring things outGil Zilberfeld
This document discusses user stories and how to write them effectively. It defines stakeholders, goals, and capabilities, and emphasizes that user stories should provide enough context for a productive discussion on implementation. Stories work best when they describe a specific goal from the perspective of a stakeholder. The document also introduces story mapping as a technique to organize user stories and visualize the overall user experience as a set of interconnected stories.
This document discusses building personas to better understand users. It explains that personas are fictional characters representing different types of users of a product or site. The speaker provides tips for creating personas, including giving them names, life stories, likes/dislikes. Attendees are asked to create vampire personas. They then role play interviews with the personas to get inside the user's perspective and identify what is important to them. Building personas and role playing interviews helps ensure products are testing the right things and meeting user needs.
This document provides an introduction to Behavior Driven Development (BDD). It discusses how BDD combines techniques from test-driven development, domain-driven design, and object-oriented analysis and design to facilitate collaboration between teams. It emphasizes that BDD is focused on conversations between stakeholders to understand requirements before automating tests. The document then demonstrates how to identify stakeholders and their goals, prioritize capabilities and risks, write user stories and acceptance criteria, and automate tests using Gherkin syntax with tools like Cucumber or SpecFlow.
This document discusses slicing user stories to make them smaller and more manageable for testing. It recommends slicing stories based on stakeholders, capabilities, acceptance criteria, and edge cases. Stories should be written to describe a desired outcome or capability without rigid templates. The goal of slicing is to have independent, negotiable, valuable, and testable stories that provide short feedback cycles for continuous learning and improvement.
This document discusses estimation techniques for software development projects. It presents different approaches to estimating such as planning poker, using complexity scales to assess confidence, and using historical velocity to project future progress. While estimation is inherently uncertain, having a variety of techniques can help produce realistic targets and control over projects. Recording past performance allows for more statistical projection over singular point estimates. Ultimately, the goal is to make informed decisions rather than predict outcomes exactly.
From the early days of agile, there were discussion on how to do estimations “right”. Although there’s no real mentioning them in the agile manifesto, scrum and other methodologies have put effort into this topic because there seems a need for estimations.
What makes an estimation method work? And what will happen one day if we stop estimating?
In this talk, I’m going to discuss where estimation works, what we do with estimations and if that’s the only way to do it. We’ll talk about how our experience and biases control them, and how the #NoEstimates discussion tries to change the way we make decisions.
The next time people ask us for estimations, let’s consider the process first. Then we’ll give them an answer. Maybe.
This document discusses alternatives to traditional software estimation practices. It suggests that estimates are not good at predicting outcomes and promoting better decision making. Instead, it advocates for techniques like assuming ignorance, planning experiments, breaking work down into small batches, and focusing on complexity assessment and value estimation. The overall message is that careful planning and incremental work can help manage uncertainty and control projects better than reliance on estimates.
The Whole Story - Mapping, Slicing and Figuring things outGil Zilberfeld
This document discusses user stories and how to write them effectively. It defines stakeholders, goals, and capabilities, and emphasizes that user stories should provide enough context for a productive discussion on implementation. Stories work best when they describe a specific goal from the perspective of a stakeholder. The document also introduces story mapping as a technique to organize user stories and visualize the overall user experience as a set of interconnected stories.
This document discusses building personas to better understand users. It explains that personas are fictional characters representing different types of users of a product or site. The speaker provides tips for creating personas, including giving them names, life stories, likes/dislikes. Attendees are asked to create vampire personas. They then role play interviews with the personas to get inside the user's perspective and identify what is important to them. Building personas and role playing interviews helps ensure products are testing the right things and meeting user needs.
This document provides an introduction to Behavior Driven Development (BDD). It discusses how BDD combines techniques from test-driven development, domain-driven design, and object-oriented analysis and design to facilitate collaboration between teams. It emphasizes that BDD is focused on conversations between stakeholders to understand requirements before automating tests. The document then demonstrates how to identify stakeholders and their goals, prioritize capabilities and risks, write user stories and acceptance criteria, and automate tests using Gherkin syntax with tools like Cucumber or SpecFlow.
This document discusses slicing user stories to make them smaller and more manageable for testing. It recommends slicing stories based on stakeholders, capabilities, acceptance criteria, and edge cases. Stories should be written to describe a desired outcome or capability without rigid templates. The goal of slicing is to have independent, negotiable, valuable, and testable stories that provide short feedback cycles for continuous learning and improvement.
This document discusses estimation techniques for software development projects. It presents different approaches to estimating such as planning poker, using complexity scales to assess confidence, and using historical velocity to project future progress. While estimation is inherently uncertain, having a variety of techniques can help produce realistic targets and control over projects. Recording past performance allows for more statistical projection over singular point estimates. Ultimately, the goal is to make informed decisions rather than predict outcomes exactly.
From the early days of agile, there were discussion on how to do estimations “right”. Although there’s no real mentioning them in the agile manifesto, scrum and other methodologies have put effort into this topic because there seems a need for estimations.
What makes an estimation method work? And what will happen one day if we stop estimating?
In this talk, I’m going to discuss where estimation works, what we do with estimations and if that’s the only way to do it. We’ll talk about how our experience and biases control them, and how the #NoEstimates discussion tries to change the way we make decisions.
The next time people ask us for estimations, let’s consider the process first. Then we’ll give them an answer. Maybe.
This document discusses alternatives to traditional software estimation practices. It suggests that estimates are not good at predicting outcomes and promoting better decision making. Instead, it advocates for techniques like assuming ignorance, planning experiments, breaking work down into small batches, and focusing on complexity assessment and value estimation. The overall message is that careful planning and incremental work can help manage uncertainty and control projects better than reliance on estimates.
This document discusses using stories and storytelling techniques in agile development. It will cover simple structures for telling compelling stories, tools and techniques to aid story creation, and skills to increase empathy within agile teams. The workshop will discuss story spines, the story mountain template, using story dice, creating personas, and telling stories incorporating random words. The goal is to use stories and storytelling to help represent users and their goals to the development team.
Zen and the art of Test Maintenance - #TestIL Meetup Tel AvivGil Zilberfeld
Nobody likes it. Everyone has to do it: Maintenance for code and tests. In this presentation we go over a strategy for taking care of our tests, and how to fix the bad ones.
The document discusses the evolution of organizations and processes from the Industrial Revolution to modern times. It describes early scientific management principles that emphasized specialization and quality control. The computer and internet revolutions led to more complex processes to manage risk and uncertainty as competition increased. Lean and Agile principles emerged to better fit an environment requiring rapid change and feedback. The future of work is predicted to involve distributed teams, knowledge retention, and an experimentation mindset.
The document discusses how ROI is an inadequate measure for software projects because the costs and values are difficult to accurately measure. It suggests that instead of ROI, teams should focus on making better decisions through techniques like planning with methods other than estimates that account for uncertainty, evaluating complexity, collecting data, reducing task variance, assuming ignorance, enumerating assumptions, and planning for deliberate discovery. The overall message is that ROI is dead as a measurement and that alternative approaches can help teams feel more confident in their process and level of control.
The classic ALM helped us with the execution part when we understood the requirements.
In a world of uncertainty, when the requirement are merely assumptions. we need better management tools and processes, to support learning.
Fighting the Dark Side of Data-Driven (Form, Function & Class Web Design Conf...Angela Obias
These are the supporting slides from my talk on the watch-outs and potential perils of using data for design.
The talk was for Form, Function & Class 6 - an annual web design conference. This year's theme was the fight for good design - and the talks ranged from web animation, by Rachel Nabors to design systems, by James Cabrera and Brad Frost.
I'm a research practitioner and analyst. So although it may seem weird to present about the perils of data, I also want the design community to understand that having a lot of data doesn't mean that you'll get a "good" design. Something that I feel is critical for us to reflect on, at a time when popular opinion praises "user-centricity" and big data.
FFC is organized by the Philippine Web Designers Organization.
It's time to research our designs better. Here's how. UIUX Conference 2018 - ...Sophie Freiermuth
Slides of the talk I delivered at http://2018.uiuxconf.com on 3rd September 2018 in Shanghai China.
The audience was a mix of Mandarin and English speakers, and was supported by live translation.
Storytelling Mojo: How to Translate New Ideas into Cultural AcceptanceMichael Margolis
This document discusses trends in storytelling and how to use stories to promote innovation adoption and cultural acceptance. It highlights 5 key storytelling trends: 1) humanization of business, 2) giving every product a backstory, 3) democratization of storytelling, 4) tribal and social identity, 5) reinvention. It also discusses why innovation adoption often fails when there is no common story, change is judged, and people can't relate to the story. Storytelling is presented as a way to build new narratives that make existing realities obsolete and drive cultural change.
Digital Strategy And storytelling - District32 business leaders - doyle buehl...Doyle Buehler
Isn’t it cool - it’s the greatest time in history, as we have access to literally billions of people around the world.
Yet, it’s also the worst time in history because we have access to… literally billions of other people around the world.
Competition is fierce; you’re essentially 1-click away from disaster.
It’s never been easier to get your story out there, but it’s also the hardest time because there is so much more noise out there. Isn't business fun?
In the Digital Age, story matters now more than ever. If you have a strategy you can tell your true story. If you don't, you get lost in the noise of everything else.
We were born to tell stories & we know how to listen to them, but rarely how to tell them. The story is what gives your customer clarity & certainty.
It’s not a story about how awesome you are. Nor even how you might be the next “amazing” founder.
Nor how you are going to “change the world”. They’ve heard it all before.
Nothing seems to work in marketing? Can’t figure out who to blame?
Ask yourself, what’s your strategy & how are you telling your story?
Story matters in creating your own certainty, your own future for the real hero, your customers.
This is your strategy. Welcome to digital storytelling.
#digitaltransformation #strategy #leadership
The document discusses how agile development has changed over time. It values individuals and interactions, working software, and customer collaboration over processes, documentation, contract negotiation, and following a strict plan. However, the author notes that agile development may be moving too fast and becoming overcommoditized, risking being "doomed" if these trends continue without care.
This document discusses strategies for test maintenance. It emphasizes the importance of aligning tests with product focus and risks. It provides examples of how to evaluate tests and identifies common issues like uninformative, unreliable, and misleading tests. The document also covers testability, refactoring, behavior-driven development, and techniques like test reviews and pair programming. Exercises are included to help learn test maintenance practices.
Create Content They've Gotta Read: How to Write for Social MediaPaul Gillin
With so many blog posts, so many tweets and so much mindless chatter filling social networks, how do marketers get the message through? They do it by understanding the culture and the medium, knowing what's important to the audience and speaking to the issues that provoke conversation and response.
Writing for social networks is about capturing attention. It's about finding angles, factoids and quotes that intrigue and provoke using words that no one expects you to use. Don't just tell your audience to look at something; make it something they have to look at it.
Each social network has different styles and techniques that work. In this mini-course, we cover Facebook, Twitter and LinkedIn to show best practices for communicating on each.
This presentation covers:
• How to compose messages for the major social networks that conform to the culture and syntax of each community.
• How to find offbeat angles that catch readers’ eyes and entice them to learn more.
• 20 different ways to approach the same topic and create a unique experience.
Create Stuff They’ve Just Gotta Read: How to Write for Social Networks - Paul...Godfrey
Writing for social networks is about capturing attention. It’s about finding angles, factoids and quotes that intrigue and provoke using words that no one expects you to use. Each social network has different styles and techniques that work. In this mini-course, we’ll cover best practices for communicating on Facebook, Twitter and LinkedIn.
Paul is a veteran technology journalist with more than 25 years of editorial experience. He advises marketers and business executives on strategies to optimize their use of social media and online channels to reach buyers cost-effectively.
This document introduces Gil Zilberfeld, the founder of TestinGil, and discusses clean code and clean tests. It provides Gil's contact information and links to TestinGil's website and social media profiles. It also lists some characteristics of clean tests, such as showing intent, being focused, and doing exactly what they say. Finally, it discusses test smells like god classes and methods, comments, uncommunicative names, and embedded constants, and how refactoring can help address these smells.
When you're going to introduce a new process to your team, like unit testing, it's going to be hard. Developers have their own experiences, opinions and even objections (gasp!).
This webinar slides are about what to expect, and how to deal with them. And the developers too.
The document introduces Gil Zilberfeld and his work with unit testing, behavior driven development, and tools like JBehave and Cucumber. It provides Zilberfeld's contact information including his Twitter handle and websites for further information on his intro to the Spock testing framework.
Dependency injection and Why It Matters to TestersGil Zilberfeld
Gil Zilberfeld talks about the dependency injection principle and how it affects testability. He then goes on to discuss how code is too important to leave to developers and testers should be part of the design and coding process.
This document discusses strategies for testing Spring applications. It recommends starting with unit tests that inject mocks and configure test data. Integration tests can use the SpringRunner to load Spring Boot applications in tests. MockMVC allows testing controller layers by calling APIs and asserting responses. The document provides examples of configuring tests, injecting mocks, using in-memory databases, and testing client-side code. It emphasizes managing test code and configurations like regular code.
The document discusses test maintenance and provides guidance on developing a maintenance plan. It suggests starting by understanding what is important to the product, associated risks, and areas of focus. Examples are then given for Facebook and Candy Crush Saga to illustrate how this framework can be applied. The document also provides suggestions for evaluating existing tests, cleaning up test suites, addressing problematic tests, and conducting code reviews to support effective test maintenance.
This document discusses test planning from different perspectives, including the product life cycle, development life cycle, and risk and value. It also covers Kent Beck's concepts of explore, expand, and extract, and how testing roles may differ in each phase. Parameters like existing automation, feedback mechanisms, and technical debt are presented as influencing test planning. The document proposes examining these parameters at different levels, such as development phases or zoom levels. Overall it promotes taking a nuanced, multifaceted approach to test planning that considers various contexts and perspectives.
This document discusses using stories and storytelling techniques in agile development. It will cover simple structures for telling compelling stories, tools and techniques to aid story creation, and skills to increase empathy within agile teams. The workshop will discuss story spines, the story mountain template, using story dice, creating personas, and telling stories incorporating random words. The goal is to use stories and storytelling to help represent users and their goals to the development team.
Zen and the art of Test Maintenance - #TestIL Meetup Tel AvivGil Zilberfeld
Nobody likes it. Everyone has to do it: Maintenance for code and tests. In this presentation we go over a strategy for taking care of our tests, and how to fix the bad ones.
The document discusses the evolution of organizations and processes from the Industrial Revolution to modern times. It describes early scientific management principles that emphasized specialization and quality control. The computer and internet revolutions led to more complex processes to manage risk and uncertainty as competition increased. Lean and Agile principles emerged to better fit an environment requiring rapid change and feedback. The future of work is predicted to involve distributed teams, knowledge retention, and an experimentation mindset.
The document discusses how ROI is an inadequate measure for software projects because the costs and values are difficult to accurately measure. It suggests that instead of ROI, teams should focus on making better decisions through techniques like planning with methods other than estimates that account for uncertainty, evaluating complexity, collecting data, reducing task variance, assuming ignorance, enumerating assumptions, and planning for deliberate discovery. The overall message is that ROI is dead as a measurement and that alternative approaches can help teams feel more confident in their process and level of control.
The classic ALM helped us with the execution part when we understood the requirements.
In a world of uncertainty, when the requirement are merely assumptions. we need better management tools and processes, to support learning.
Fighting the Dark Side of Data-Driven (Form, Function & Class Web Design Conf...Angela Obias
These are the supporting slides from my talk on the watch-outs and potential perils of using data for design.
The talk was for Form, Function & Class 6 - an annual web design conference. This year's theme was the fight for good design - and the talks ranged from web animation, by Rachel Nabors to design systems, by James Cabrera and Brad Frost.
I'm a research practitioner and analyst. So although it may seem weird to present about the perils of data, I also want the design community to understand that having a lot of data doesn't mean that you'll get a "good" design. Something that I feel is critical for us to reflect on, at a time when popular opinion praises "user-centricity" and big data.
FFC is organized by the Philippine Web Designers Organization.
It's time to research our designs better. Here's how. UIUX Conference 2018 - ...Sophie Freiermuth
Slides of the talk I delivered at http://2018.uiuxconf.com on 3rd September 2018 in Shanghai China.
The audience was a mix of Mandarin and English speakers, and was supported by live translation.
Storytelling Mojo: How to Translate New Ideas into Cultural AcceptanceMichael Margolis
This document discusses trends in storytelling and how to use stories to promote innovation adoption and cultural acceptance. It highlights 5 key storytelling trends: 1) humanization of business, 2) giving every product a backstory, 3) democratization of storytelling, 4) tribal and social identity, 5) reinvention. It also discusses why innovation adoption often fails when there is no common story, change is judged, and people can't relate to the story. Storytelling is presented as a way to build new narratives that make existing realities obsolete and drive cultural change.
Digital Strategy And storytelling - District32 business leaders - doyle buehl...Doyle Buehler
Isn’t it cool - it’s the greatest time in history, as we have access to literally billions of people around the world.
Yet, it’s also the worst time in history because we have access to… literally billions of other people around the world.
Competition is fierce; you’re essentially 1-click away from disaster.
It’s never been easier to get your story out there, but it’s also the hardest time because there is so much more noise out there. Isn't business fun?
In the Digital Age, story matters now more than ever. If you have a strategy you can tell your true story. If you don't, you get lost in the noise of everything else.
We were born to tell stories & we know how to listen to them, but rarely how to tell them. The story is what gives your customer clarity & certainty.
It’s not a story about how awesome you are. Nor even how you might be the next “amazing” founder.
Nor how you are going to “change the world”. They’ve heard it all before.
Nothing seems to work in marketing? Can’t figure out who to blame?
Ask yourself, what’s your strategy & how are you telling your story?
Story matters in creating your own certainty, your own future for the real hero, your customers.
This is your strategy. Welcome to digital storytelling.
#digitaltransformation #strategy #leadership
The document discusses how agile development has changed over time. It values individuals and interactions, working software, and customer collaboration over processes, documentation, contract negotiation, and following a strict plan. However, the author notes that agile development may be moving too fast and becoming overcommoditized, risking being "doomed" if these trends continue without care.
This document discusses strategies for test maintenance. It emphasizes the importance of aligning tests with product focus and risks. It provides examples of how to evaluate tests and identifies common issues like uninformative, unreliable, and misleading tests. The document also covers testability, refactoring, behavior-driven development, and techniques like test reviews and pair programming. Exercises are included to help learn test maintenance practices.
Create Content They've Gotta Read: How to Write for Social MediaPaul Gillin
With so many blog posts, so many tweets and so much mindless chatter filling social networks, how do marketers get the message through? They do it by understanding the culture and the medium, knowing what's important to the audience and speaking to the issues that provoke conversation and response.
Writing for social networks is about capturing attention. It's about finding angles, factoids and quotes that intrigue and provoke using words that no one expects you to use. Don't just tell your audience to look at something; make it something they have to look at it.
Each social network has different styles and techniques that work. In this mini-course, we cover Facebook, Twitter and LinkedIn to show best practices for communicating on each.
This presentation covers:
• How to compose messages for the major social networks that conform to the culture and syntax of each community.
• How to find offbeat angles that catch readers’ eyes and entice them to learn more.
• 20 different ways to approach the same topic and create a unique experience.
Create Stuff They’ve Just Gotta Read: How to Write for Social Networks - Paul...Godfrey
Writing for social networks is about capturing attention. It’s about finding angles, factoids and quotes that intrigue and provoke using words that no one expects you to use. Each social network has different styles and techniques that work. In this mini-course, we’ll cover best practices for communicating on Facebook, Twitter and LinkedIn.
Paul is a veteran technology journalist with more than 25 years of editorial experience. He advises marketers and business executives on strategies to optimize their use of social media and online channels to reach buyers cost-effectively.
This document introduces Gil Zilberfeld, the founder of TestinGil, and discusses clean code and clean tests. It provides Gil's contact information and links to TestinGil's website and social media profiles. It also lists some characteristics of clean tests, such as showing intent, being focused, and doing exactly what they say. Finally, it discusses test smells like god classes and methods, comments, uncommunicative names, and embedded constants, and how refactoring can help address these smells.
When you're going to introduce a new process to your team, like unit testing, it's going to be hard. Developers have their own experiences, opinions and even objections (gasp!).
This webinar slides are about what to expect, and how to deal with them. And the developers too.
The document introduces Gil Zilberfeld and his work with unit testing, behavior driven development, and tools like JBehave and Cucumber. It provides Zilberfeld's contact information including his Twitter handle and websites for further information on his intro to the Spock testing framework.
Dependency injection and Why It Matters to TestersGil Zilberfeld
Gil Zilberfeld talks about the dependency injection principle and how it affects testability. He then goes on to discuss how code is too important to leave to developers and testers should be part of the design and coding process.
This document discusses strategies for testing Spring applications. It recommends starting with unit tests that inject mocks and configure test data. Integration tests can use the SpringRunner to load Spring Boot applications in tests. MockMVC allows testing controller layers by calling APIs and asserting responses. The document provides examples of configuring tests, injecting mocks, using in-memory databases, and testing client-side code. It emphasizes managing test code and configurations like regular code.
The document discusses test maintenance and provides guidance on developing a maintenance plan. It suggests starting by understanding what is important to the product, associated risks, and areas of focus. Examples are then given for Facebook and Candy Crush Saga to illustrate how this framework can be applied. The document also provides suggestions for evaluating existing tests, cleaning up test suites, addressing problematic tests, and conducting code reviews to support effective test maintenance.
This document discusses test planning from different perspectives, including the product life cycle, development life cycle, and risk and value. It also covers Kent Beck's concepts of explore, expand, and extract, and how testing roles may differ in each phase. Parameters like existing automation, feedback mechanisms, and technical debt are presented as influencing test planning. The document proposes examining these parameters at different levels, such as development phases or zoom levels. Overall it promotes taking a nuanced, multifaceted approach to test planning that considers various contexts and perspectives.
Gil Zilberfeld introduces himself and provides an overview of DevOps. DevOps emphasizes collaboration between software developers and IT professionals while automating the process of software delivery and infrastructure changes. The document discusses new challenges with cloud, serverless environments, and governance. It also covers DevOps practices like source control, continuous integration, testing, deployment, monitoring, and product validation.
The document discusses challenges and strategies for remote agile teams. It notes that cultural differences, lack of trust, communication issues, and different mental models can make remote work difficult. However, remote teams can still follow agile principles by focusing on individuals and interactions over processes; collaboration with customers; and responding to change. Effective remote tools, methods, and culture are needed. Strategies proposed include developing team culture even remotely, using video conferencing and remote boards, and establishing ground rules for remote meetings.
This document discusses DevOps principles and practices. It introduces DevOps as a culture emphasizing collaboration between software developers and IT professionals to automate software delivery and infrastructure changes. It then covers various DevOps topics like continuous integration, deployment, monitoring and product validation practices. It also provides examples of applications that could benefit from a DevOps pipeline and asks the reader to design such pipelines.
This document provides an introduction to behavior driven development (BDD) and acceptance test driven development. It discusses the history and benefits of test-first development as well as frameworks like Cucumber that use the Gherkin language to write scenarios and acceptance criteria in a natural language format. The document emphasizes that BDD is focused on driving development with conversations between developers, testers, and business stakeholders based on user stories. It provides tips for writing good user stories and examples of scenarios.
This document is a presentation on unit testing that covers: what unit testing is and why it's important; different unit testing frameworks for languages like C++, Java, C#, and JavaScript; techniques for testing legacy code like isolation and mocking; tips for writing unit tests and practicing test-driven development. The presentation emphasizes that unit tests should run quickly, be readable, focused on testing individual units of code, and help enable refactoring of code with confidence.
The document discusses Test Driven Development (TDD) and how to apply it through building a lightsaber and Death Star. It outlines the TDD cycle and benefits like better code coverage and design. Issues include requiring discipline and taking time for great results. The document provides tips for practicing TDD like planning ahead, using small steps, and focusing on the current test. It encourages trying TDD in a team and using behavior driven development. The summary concludes by emphasizing that a Death Star without tests is dangerous.
The document contains tweets and quotes by Gil Zilberfeld on software development topics like simplicity, requirements, coding, tools, quality, projects, risk, and testing. It emphasizes keeping systems and processes simple, prioritizing learning, code reviews, following conventions, limiting backlogs, experimenting, and educating others. Steve Jobs and John Gall quotes are included that promote simplicity and how complex systems evolve from simple ones.
This document contains a series of repeated mentions of the Twitter handle @gil_zilberfeld without any other context or information provided. It is unclear what the intent or purpose of this document is from the limited information given.
SOCRadar's Aviation Industry Q1 Incident Report is out now!
The aviation industry has always been a prime target for cybercriminals due to its critical infrastructure and high stakes. In the first quarter of 2024, the sector faced an alarming surge in cybersecurity threats, revealing its vulnerabilities and the relentless sophistication of cyber attackers.
SOCRadar’s Aviation Industry, Quarterly Incident Report, provides an in-depth analysis of these threats, detected and examined through our extensive monitoring of hacker forums, Telegram channels, and dark web platforms.
Hand Rolled Applicative User ValidationCode KataPhilip Schwarz
Could you use a simple piece of Scala validation code (granted, a very simplistic one too!) that you can rewrite, now and again, to refresh your basic understanding of Applicative operators <*>, <*, *>?
The goal is not to write perfect code showcasing validation, but rather, to provide a small, rough-and ready exercise to reinforce your muscle-memory.
Despite its grandiose-sounding title, this deck consists of just three slides showing the Scala 3 code to be rewritten whenever the details of the operators begin to fade away.
The code is my rough and ready translation of a Haskell user-validation program found in a book called Finding Success (and Failure) in Haskell - Fall in love with applicative functors.
What to do when you have a perfect model for your software but you are constrained by an imperfect business model?
This talk explores the challenges of bringing modelling rigour to the business and strategy levels, and talking to your non-technical counterparts in the process.
Malibou Pitch Deck For Its €3M Seed Roundsjcobrien
French start-up Malibou raised a €3 million Seed Round to develop its payroll and human resources
management platform for VSEs and SMEs. The financing round was led by investors Breega, Y Combinator, and FCVC.
E-Invoicing Implementation: A Step-by-Step Guide for Saudi Arabian CompaniesQuickdice ERP
Explore the seamless transition to e-invoicing with this comprehensive guide tailored for Saudi Arabian businesses. Navigate the process effortlessly with step-by-step instructions designed to streamline implementation and enhance efficiency.
Transform Your Communication with Cloud-Based IVR SolutionsTheSMSPoint
Discover the power of Cloud-Based IVR Solutions to streamline communication processes. Embrace scalability and cost-efficiency while enhancing customer experiences with features like automated call routing and voice recognition. Accessible from anywhere, these solutions integrate seamlessly with existing systems, providing real-time analytics for continuous improvement. Revolutionize your communication strategy today with Cloud-Based IVR Solutions. Learn more at: https://thesmspoint.com/channel/cloud-telephony
When it is all about ERP solutions, companies typically meet their needs with common ERP solutions like SAP, Oracle, and Microsoft Dynamics. These big players have demonstrated that ERP systems can be either simple or highly comprehensive. This remains true today, but there are new factors to consider, including a promising new contender in the market that’s Odoo. This blog compares Odoo ERP with traditional ERP systems and explains why many companies now see Odoo ERP as the best choice.
What are ERP Systems?
An ERP, or Enterprise Resource Planning, system provides your company with valuable information to help you make better decisions and boost your ROI. You should choose an ERP system based on your company’s specific needs. For instance, if you run a manufacturing or retail business, you will need an ERP system that efficiently manages inventory. A consulting firm, on the other hand, would benefit from an ERP system that enhances daily operations. Similarly, eCommerce stores would select an ERP system tailored to their needs.
Because different businesses have different requirements, ERP system functionalities can vary. Among the various ERP systems available, Odoo ERP is considered one of the best in the ERp market with more than 12 million global users today.
Odoo is an open-source ERP system initially designed for small to medium-sized businesses but now suitable for a wide range of companies. Odoo offers a scalable and configurable point-of-sale management solution and allows you to create customised modules for specific industries. Odoo is gaining more popularity because it is built in a way that allows easy customisation, has a user-friendly interface, and is affordable. Here, you will cover the main differences and get to know why Odoo is gaining attention despite the many other ERP systems available in the market.
Everything You Need to Know About X-Sign: The eSign Functionality of XfilesPr...XfilesPro
Wondering how X-Sign gained popularity in a quick time span? This eSign functionality of XfilesPro DocuPrime has many advancements to offer for Salesforce users. Explore them now!
Need for Speed: Removing speed bumps from your Symfony projects ⚡️Łukasz Chruściel
No one wants their application to drag like a car stuck in the slow lane! Yet it’s all too common to encounter bumpy, pothole-filled solutions that slow the speed of any application. Symfony apps are not an exception.
In this talk, I will take you for a spin around the performance racetrack. We’ll explore common pitfalls - those hidden potholes on your application that can cause unexpected slowdowns. Learn how to spot these performance bumps early, and more importantly, how to navigate around them to keep your application running at top speed.
We will focus in particular on tuning your engine at the application level, making the right adjustments to ensure that your system responds like a well-oiled, high-performance race car.
8 Best Automated Android App Testing Tool and Framework in 2024.pdfkalichargn70th171
Regarding mobile operating systems, two major players dominate our thoughts: Android and iPhone. With Android leading the market, software development companies are focused on delivering apps compatible with this OS. Ensuring an app's functionality across various Android devices, OS versions, and hardware specifications is critical, making Android app testing essential.
UI5con 2024 - Keynote: Latest News about UI5 and it’s EcosystemPeter Muessig
Learn about the latest innovations in and around OpenUI5/SAPUI5: UI5 Tooling, UI5 linter, UI5 Web Components, Web Components Integration, UI5 2.x, UI5 GenAI.
Recording:
https://www.youtube.com/live/MSdGLG2zLy8?si=INxBHTqkwHhxV5Ta&t=0
UI5con 2024 - Boost Your Development Experience with UI5 Tooling ExtensionsPeter Muessig
The UI5 tooling is the development and build tooling of UI5. It is built in a modular and extensible way so that it can be easily extended by your needs. This session will showcase various tooling extensions which can boost your development experience by far so that you can really work offline, transpile your code in your project to use even newer versions of EcmaScript (than 2022 which is supported right now by the UI5 tooling), consume any npm package of your choice in your project, using different kind of proxies, and even stitching UI5 projects during development together to mimic your target environment.
15. @gil_zilberfeld
Capability
“An ability to perform or
achieve certain actions or
outcomes through a set of
controllable and measurable
faculties, features, functions,
processes, or services.”
20. @gil_zilberfeld
Ron Jeffries said
As an author of the Agile Manifesto
I want that stupid story format to go away
So that people can get to the essence of user
stories
24. @gil_zilberfeld
Better user stories
◉ Unveil the motive – what is the goal and for
which stakeholder?
◉ Consider dropping the template
◉ Tell the story in a sentence or two
◉ Anchor it – how does it fit with what we have or
know?
26. @gil_zilberfeld
Questions about the stories
◉ Are the stories ready for work?
◉ How complex are they?
◉ Do they fit in a sprint?
◉ Do we need to do a POC?
◉ Does the story have sub-stories?
◉ What alternatives do we have for
implementation?
◉ What will we learn?
35. @gil_zilberfeld
Summary
◉ Identify the stakeholders, their goals, and the
capabilities
◉ Effective stories have enough information to start
discussing working
◉ Story maps give us direction by showing the
whole picture
Drop the template. Like everything, once we have a hammer we start looking for nails. Sometimes the template doesn't fit. That's ok. In that case...
Tell the story in a sentence. Maybe two. When people are presented with a new idea, don't make them read heaps of documents. Sum it up, so they can grasp it quickly. Details can come later. And make sure it's a story, with a beginning, middle and an end. People remember and consume stories better. You can even sing it if you want, that would make it more memorable. Next you want to...
Anchor it. You know the "It's like Uber, but for...?" pitch form every start up is using? Everybody knows Uber, so they have something to reference the new information. In story-land it's how the story fits into the application. "It's like the log-in story from last week, but with extra validation". Or, "Once we've done with the simple path, we can add more informed algorithms". You're showing where we were, where we're going, and where this story fits. Then it gets interesting.
Unveil the motive. Why are we developing this anyway? Who is going to benefit and how? The user may be able to go through registration quicker, and that means more happy users. Or we, the company, gets more money from the dog accessories suppliers, if we're able to connect our users based on their level of pet appreciation. There's a reason we're developing the feature, and it really helps to know the final goal. In some cases, we can debunk it, and choose something better to do with our time. Once people understand the motive...
Make a show. How does it look like? You have prepared some mock-up screens, or sketches, or drawing of a flow, or anything that has more meat, right? Ah, you need to prepare for this, young Padawan. It will help, not just with explaining it, but it's a also the setting for...
Give it context.Now that things begin to materialize, it's time for an example. You can present the flow on those mocked screens. Or how a different application might be using our new API. How future features will be using our back-end calculation results. Context is awesome! We can use it to direct the team towards...
Generalize. Do we start with the example and just implement it? Should we write a more extensive data validation layer, and then test it? Somewhere in between? An example is not enough for development, because we need to know where to stop. And we need to know how to test. This really helps with defining the acceptance criteria. The final step is...
Draw a line in the sand. Some things do not fall into our general rule. VIPs do not need to enter their credentials again. Anonymous users can use the applications, but will go through a separate flow we'll define later. Anything that does not fall within our boundaries, should be presented. Otherwise, we would implement it, and test it, and we will be surprised. And we don't like surprises.
Drop the template. Like everything, once we have a hammer we start looking for nails. Sometimes the template doesn't fit. That's ok. In that case...
Tell the story in a sentence. Maybe two. When people are presented with a new idea, don't make them read heaps of documents. Sum it up, so they can grasp it quickly. Details can come later. And make sure it's a story, with a beginning, middle and an end. People remember and consume stories better. You can even sing it if you want, that would make it more memorable. Next you want to...
Anchor it. You know the "It's like Uber, but for...?" pitch form every start up is using? Everybody knows Uber, so they have something to reference the new information. In story-land it's how the story fits into the application. "It's like the log-in story from last week, but with extra validation". Or, "Once we've done with the simple path, we can add more informed algorithms". You're showing where we were, where we're going, and where this story fits. Then it gets interesting.
Unveil the motive. Why are we developing this anyway? Who is going to benefit and how? The user may be able to go through registration quicker, and that means more happy users. Or we, the company, gets more money from the dog accessories suppliers, if we're able to connect our users based on their level of pet appreciation. There's a reason we're developing the feature, and it really helps to know the final goal. In some cases, we can debunk it, and choose something better to do with our time. Once people understand the motive...
Make a show. How does it look like? You have prepared some mock-up screens, or sketches, or drawing of a flow, or anything that has more meat, right? Ah, you need to prepare for this, young Padawan. It will help, not just with explaining it, but it's a also the setting for...
Give it context.Now that things begin to materialize, it's time for an example. You can present the flow on those mocked screens. Or how a different application might be using our new API. How future features will be using our back-end calculation results. Context is awesome! We can use it to direct the team towards...
Generalize. Do we start with the example and just implement it? Should we write a more extensive data validation layer, and then test it? Somewhere in between? An example is not enough for development, because we need to know where to stop. And we need to know how to test. This really helps with defining the acceptance criteria. The final step is...
Draw a line in the sand. Some things do not fall into our general rule. VIPs do not need to enter their credentials again. Anonymous users can use the applications, but will go through a separate flow we'll define later. Anything that does not fall within our boundaries, should be presented. Otherwise, we would implement it, and test it, and we will be surprised. And we don't like surprises.