How engineering practices help businessAndrey Rebrov
This document provides advice on how to introduce new engineering practices and technologies to a team or business. It discusses several examples of proposed new practices and technologies such as test automation, continuous integration, refactoring, and DevOps. For each, it advises how to demonstrate the benefits through examples and metrics, how to gain buy-in from various stakeholders, and pitfalls to avoid such as claiming a practice is necessary just because a famous person recommends it. The overall message is that new practices must provide clear value and be introduced through demonstration and collaboration rather than dictates.
This document discusses test automation challenges at an investment bank and lessons learned. It outlines problems with lengthy manual regression testing. An attempt was made to use Jameleon for test automation but it caused issues. They identified needs for metrics, definitions of done, and separating test connections. Recommendations include using tools like Selenium and SoapUI with a Jenkins/JIRA setup. While quick wins are possible, separating test connections and fully defining requirements are important for successful test automation.
1) The document discusses test automation challenges at WorkFusion including long test run times, low coverage, and technical debt.
2) It proposes adopting a "feature test" approach between unit and UI tests to help address these issues by mapping manual test cases to automated scenarios.
3) Key steps would be to identify redundant tests, delete obsolete code, start a unit/integration test initiative, and get additional resources to help scale the efforts. Outcomes and lessons learned would be reviewed.
The document discusses the role and responsibilities of a quality analyst (QA). It defines QA as the first level of customers, a guide for overall software quality, and someone who focuses on prevent defects rather than just finding them. Typical QA activities include managing test scenarios and defects, automating test cases, raising quality risks, and establishing client relationships. The document also discusses test automation best practices like the test pyramid and when different types of manual and automated tests should be used. It invites the reader to learn more about a career in QA.
How hard can it be to start a software development project? It can be very intimidating to start at the blank page.
This talk offers some ideas how to make getting started less scary and more enjoyable, from the first keyboard stroke to a working usable system.
1. Old-style testing involved separate roles like user, business analyst, developer, and tester, with testing occurring as a separate phase after development.
2. New agile testing approaches emphasize testing early and often throughout development, with developers writing tests, business analysts providing examples to guide development and testing, and continuous testing of changes as they are checked in.
3. Examples can serve as both specifications to guide development and as tests to validate functionality.
How engineering practices help businessAndrey Rebrov
This document provides advice on how to introduce new engineering practices and technologies to a team or business. It discusses several examples of proposed new practices and technologies such as test automation, continuous integration, refactoring, and DevOps. For each, it advises how to demonstrate the benefits through examples and metrics, how to gain buy-in from various stakeholders, and pitfalls to avoid such as claiming a practice is necessary just because a famous person recommends it. The overall message is that new practices must provide clear value and be introduced through demonstration and collaboration rather than dictates.
This document discusses test automation challenges at an investment bank and lessons learned. It outlines problems with lengthy manual regression testing. An attempt was made to use Jameleon for test automation but it caused issues. They identified needs for metrics, definitions of done, and separating test connections. Recommendations include using tools like Selenium and SoapUI with a Jenkins/JIRA setup. While quick wins are possible, separating test connections and fully defining requirements are important for successful test automation.
1) The document discusses test automation challenges at WorkFusion including long test run times, low coverage, and technical debt.
2) It proposes adopting a "feature test" approach between unit and UI tests to help address these issues by mapping manual test cases to automated scenarios.
3) Key steps would be to identify redundant tests, delete obsolete code, start a unit/integration test initiative, and get additional resources to help scale the efforts. Outcomes and lessons learned would be reviewed.
The document discusses the role and responsibilities of a quality analyst (QA). It defines QA as the first level of customers, a guide for overall software quality, and someone who focuses on prevent defects rather than just finding them. Typical QA activities include managing test scenarios and defects, automating test cases, raising quality risks, and establishing client relationships. The document also discusses test automation best practices like the test pyramid and when different types of manual and automated tests should be used. It invites the reader to learn more about a career in QA.
How hard can it be to start a software development project? It can be very intimidating to start at the blank page.
This talk offers some ideas how to make getting started less scary and more enjoyable, from the first keyboard stroke to a working usable system.
1. Old-style testing involved separate roles like user, business analyst, developer, and tester, with testing occurring as a separate phase after development.
2. New agile testing approaches emphasize testing early and often throughout development, with developers writing tests, business analysts providing examples to guide development and testing, and continuous testing of changes as they are checked in.
3. Examples can serve as both specifications to guide development and as tests to validate functionality.
This document summarizes the evolution of different schools of software testing approaches over time. It describes the Analytic School which focused on testing as a branch of mathematics. The Standard School emphasized managing predictable and repeatable testing to measure development progress. The Quality School viewed testing as protecting users from bad software. The Agile School focused on iterative development of small features and automated testing. The Context-Driven School believes the context is most important and that testing provides information rather than pass/fail results. Overall, the best approach depends on the context and all want quality but nobody wants to pay for testing.
This document summarizes the evolution of different schools of testing and quality assurance from the analytic school to present-day context-driven school. It traces how the field grew from a mathematics-focused analytic school to incorporate standards, quality protection for customers, agile development, and an emphasis on context. The document also briefly outlines typical roles and workflows for quality engineers, noting they provide critical feedback and knowledge of features while protecting users from bad software.
Software development is hard! A common pattern in our field is project starting with the best of intentions and halfway through problems appear. Problems that slow us down, that will cause us to loose speed and flexibility. So, what is Test Driven Development and how it gives us back control over our projects?
[QE 2015] Michał Kordas - Agile testing: Optimizing the feedback loopsFuture Processing
W ostatnich latach nauczyliśmy się, że krótkie pętle sprzężenia zwrotnego, czyli tzw. short feedback loops, mają ogromne znaczenie i są jednym z najważniejszych elementów metodyki agile. Właśnie dlatego zabiorę nas na „wycieczkę” po różnych pętlach, z którymi miałem styczność pracując przy swoich projektach.
Zaczniemy od naiwnego podejścia „test-after”, następnie przejdziemy do „test-first”, TDD, projektowania ewolucyjnego, minimalnej analizy, 3 Agile Amigos, podejścia biznesowego. Na koniec poznamy rozwiązania oparte na technice „outside-in” BDD.
Extreme Programming - to the next-levelLars Thorup
This document discusses taking extreme programming principles to the next level by turning traditional practices "up to 11". It explores several ideas for achieving faster feedback including mob programming, continuous deployment, hypothesis-driven user stories, shared product ownership, monitoring-driven development, and continuous learning. The author asks the reader to consider which ideas may work to implement in their organization this month.
This document discusses test-driven development (TDD). It defines TDD as an evolutionary approach where tests are written before code to verify functionality. The TDD cycle involves writing a test, making it pass by writing code, and refactoring code and tests. Advantages include more consistent testing, clarified interfaces and behavior, and confidence to refactor. An example walks through writing tests for password requirements, developing code to pass tests, and refactoring code and tests.
Agile development relies on feedback loops to continuously improve the development process. Short iterations and frequent delivery of working software allows customers to provide early and regular feedback to identify issues and ensure the project stays aligned with their needs. Feedback also comes from testing and following principles like rapid feedback and short releases where developers seek feedback quickly after each change and deliver new versions frequently to speed up the feedback cycle. The goal is to detect and address problems as early as possible through an empirical process of making changes, learning from the results, and evolving the process.
Learn about the benefits of writing unit tests. You will spend less time fixing bugs and you will get a better design for your software. Some of the questions answered are:
Why should I, as a developer, write tests?
How can I improve the software design by writing tests?
How can I save time, by spending time writing tests?
When should I write unit tests and when should I write system tests?
Presented at the BEACON 2017 conference at Hyderabad, India on December 1 - 3, 2017; this session revisits a presentation originally delivered in 2008 with updated tools reflecting a more up-to-date Agile engineering environment.
This document introduces Behavior-Driven Development (BDD). BDD focuses on defining desired software behaviors and outcomes from the perspective of stakeholders through user stories and scenarios. Scenarios are expressed using a simple domain-specific language called Gherkin that both documents requirements and serves as automated tests. BDD promotes collaboration between teams through examples that are shared to discuss requirements, design code, and implement tests. Its benefits include improved understanding of requirements, increased confidence in refactoring code, and faster delivery of working, tested software.
The document discusses the role of a business analyst in a software project. It explains that a business analyst is involved in requirements gathering and representation. This includes eliciting requirements through preliminary discussions with customers, reviewing requirements with other roles like architects and UX designers, and specifying requirements. Requirements can be represented through user stories, use cases, documents, and other methods. User stories are written from the perspective of users and define what they want to do. Use cases outline interactions between actors and a system. Together, clearly documented requirements help ensure a project delivers business value through the right software solution.
This presentation gives you the evidence as to why unit testing works and a process for how to bring it your team as soon as possible. There's a reason why the growth of unit testing, and automated unit testing in particular, has exploded over the past few years. It not only improves your code, it's faster than releasing code without tests. You'll learn: What, exactly, is a unit test?; The 7 reasons why managers love unit testing; and how to change mindset and processes to start unit testing now.
Code reviews are a great way to build better quality software, help your developers hone their skills, and make a team happier and more productive. Implementing great code review culture takes effort and determination.
This presentation offers some pointers to help run better code reviews.
This document discusses test-driven development (TDD) and unit testing. It defines TDD as a process that involves writing a failing test first, then implementing code to pass that test, and refactoring if needed. Key benefits of TDD and unit testing include reduced bugs, lower maintenance costs, and improved code design. The document provides guidelines for writing good unit tests and emphasizes that tests should be quick, isolated, and answer what behavior was tested and what the expected and actual results were.
Code reviews are a great way to build better quality software, help your developers hone their skills, and make a team happier and more productive. Implementing great code review culture takes effort and determination.
This presentation offers some pointers to help run better code reviews.
The document discusses continuous testing and the role of a tech lead in implementing it. It explains that continuous testing involves testing software continuously throughout development. To be a continuous testing expert, a tech lead should master different testing techniques, identify what code needs testing, set a testing culture, collect and analyze testing metrics, and use insights to improve processes. The document demonstrates continuous testing in action through an automated CI/CD workflow that runs unit, integration and other tests at different stages.
This document presents an overview of agile testing. It discusses how agile testing differs from general testing by following the principles of agile software development and involving all team members, including testers. The document notes that specification by example is used to define desired and undesired behaviors to guide coding. Some benefits of agile testing are more testing time, continuous testing, face-to-face communication, self-organization, less manual testing, and competency development.
Balancing Technical Debt and Clean CodeDave Hulbert
Balancing technical debt and getting things done is one of the hardest problems we have. When should we write beautiful, elegant, clean code and when should we just hammer away blindly at the keyboard until it's done? This talk goes in to why this balance is so difficult and covers everything from estimations to refactoring and testing, with a focus on real world web apps.
Software Defect Prevention via Continuous InspectionJosh Gough
Research and guidance for educing software development risk and cost while improving speed, quality and maintainability by applying review at all levels.
This document summarizes the evolution of different schools of software testing approaches over time. It describes the Analytic School which focused on testing as a branch of mathematics. The Standard School emphasized managing predictable and repeatable testing to measure development progress. The Quality School viewed testing as protecting users from bad software. The Agile School focused on iterative development of small features and automated testing. The Context-Driven School believes the context is most important and that testing provides information rather than pass/fail results. Overall, the best approach depends on the context and all want quality but nobody wants to pay for testing.
This document summarizes the evolution of different schools of testing and quality assurance from the analytic school to present-day context-driven school. It traces how the field grew from a mathematics-focused analytic school to incorporate standards, quality protection for customers, agile development, and an emphasis on context. The document also briefly outlines typical roles and workflows for quality engineers, noting they provide critical feedback and knowledge of features while protecting users from bad software.
Software development is hard! A common pattern in our field is project starting with the best of intentions and halfway through problems appear. Problems that slow us down, that will cause us to loose speed and flexibility. So, what is Test Driven Development and how it gives us back control over our projects?
[QE 2015] Michał Kordas - Agile testing: Optimizing the feedback loopsFuture Processing
W ostatnich latach nauczyliśmy się, że krótkie pętle sprzężenia zwrotnego, czyli tzw. short feedback loops, mają ogromne znaczenie i są jednym z najważniejszych elementów metodyki agile. Właśnie dlatego zabiorę nas na „wycieczkę” po różnych pętlach, z którymi miałem styczność pracując przy swoich projektach.
Zaczniemy od naiwnego podejścia „test-after”, następnie przejdziemy do „test-first”, TDD, projektowania ewolucyjnego, minimalnej analizy, 3 Agile Amigos, podejścia biznesowego. Na koniec poznamy rozwiązania oparte na technice „outside-in” BDD.
Extreme Programming - to the next-levelLars Thorup
This document discusses taking extreme programming principles to the next level by turning traditional practices "up to 11". It explores several ideas for achieving faster feedback including mob programming, continuous deployment, hypothesis-driven user stories, shared product ownership, monitoring-driven development, and continuous learning. The author asks the reader to consider which ideas may work to implement in their organization this month.
This document discusses test-driven development (TDD). It defines TDD as an evolutionary approach where tests are written before code to verify functionality. The TDD cycle involves writing a test, making it pass by writing code, and refactoring code and tests. Advantages include more consistent testing, clarified interfaces and behavior, and confidence to refactor. An example walks through writing tests for password requirements, developing code to pass tests, and refactoring code and tests.
Agile development relies on feedback loops to continuously improve the development process. Short iterations and frequent delivery of working software allows customers to provide early and regular feedback to identify issues and ensure the project stays aligned with their needs. Feedback also comes from testing and following principles like rapid feedback and short releases where developers seek feedback quickly after each change and deliver new versions frequently to speed up the feedback cycle. The goal is to detect and address problems as early as possible through an empirical process of making changes, learning from the results, and evolving the process.
Learn about the benefits of writing unit tests. You will spend less time fixing bugs and you will get a better design for your software. Some of the questions answered are:
Why should I, as a developer, write tests?
How can I improve the software design by writing tests?
How can I save time, by spending time writing tests?
When should I write unit tests and when should I write system tests?
Presented at the BEACON 2017 conference at Hyderabad, India on December 1 - 3, 2017; this session revisits a presentation originally delivered in 2008 with updated tools reflecting a more up-to-date Agile engineering environment.
This document introduces Behavior-Driven Development (BDD). BDD focuses on defining desired software behaviors and outcomes from the perspective of stakeholders through user stories and scenarios. Scenarios are expressed using a simple domain-specific language called Gherkin that both documents requirements and serves as automated tests. BDD promotes collaboration between teams through examples that are shared to discuss requirements, design code, and implement tests. Its benefits include improved understanding of requirements, increased confidence in refactoring code, and faster delivery of working, tested software.
The document discusses the role of a business analyst in a software project. It explains that a business analyst is involved in requirements gathering and representation. This includes eliciting requirements through preliminary discussions with customers, reviewing requirements with other roles like architects and UX designers, and specifying requirements. Requirements can be represented through user stories, use cases, documents, and other methods. User stories are written from the perspective of users and define what they want to do. Use cases outline interactions between actors and a system. Together, clearly documented requirements help ensure a project delivers business value through the right software solution.
This presentation gives you the evidence as to why unit testing works and a process for how to bring it your team as soon as possible. There's a reason why the growth of unit testing, and automated unit testing in particular, has exploded over the past few years. It not only improves your code, it's faster than releasing code without tests. You'll learn: What, exactly, is a unit test?; The 7 reasons why managers love unit testing; and how to change mindset and processes to start unit testing now.
Code reviews are a great way to build better quality software, help your developers hone their skills, and make a team happier and more productive. Implementing great code review culture takes effort and determination.
This presentation offers some pointers to help run better code reviews.
This document discusses test-driven development (TDD) and unit testing. It defines TDD as a process that involves writing a failing test first, then implementing code to pass that test, and refactoring if needed. Key benefits of TDD and unit testing include reduced bugs, lower maintenance costs, and improved code design. The document provides guidelines for writing good unit tests and emphasizes that tests should be quick, isolated, and answer what behavior was tested and what the expected and actual results were.
Code reviews are a great way to build better quality software, help your developers hone their skills, and make a team happier and more productive. Implementing great code review culture takes effort and determination.
This presentation offers some pointers to help run better code reviews.
The document discusses continuous testing and the role of a tech lead in implementing it. It explains that continuous testing involves testing software continuously throughout development. To be a continuous testing expert, a tech lead should master different testing techniques, identify what code needs testing, set a testing culture, collect and analyze testing metrics, and use insights to improve processes. The document demonstrates continuous testing in action through an automated CI/CD workflow that runs unit, integration and other tests at different stages.
This document presents an overview of agile testing. It discusses how agile testing differs from general testing by following the principles of agile software development and involving all team members, including testers. The document notes that specification by example is used to define desired and undesired behaviors to guide coding. Some benefits of agile testing are more testing time, continuous testing, face-to-face communication, self-organization, less manual testing, and competency development.
Balancing Technical Debt and Clean CodeDave Hulbert
Balancing technical debt and getting things done is one of the hardest problems we have. When should we write beautiful, elegant, clean code and when should we just hammer away blindly at the keyboard until it's done? This talk goes in to why this balance is so difficult and covers everything from estimations to refactoring and testing, with a focus on real world web apps.
Software Defect Prevention via Continuous InspectionJosh Gough
Research and guidance for educing software development risk and cost while improving speed, quality and maintainability by applying review at all levels.
What is "Agile"?
Why would someone like to be agile?
What are the 3 pillars for agile software development?
How can you achieve technical excellence in your software teams?
Are developer skills more important than languages, methods or frameworks?
Choosing the right QA strategy for a successful projectThe Software House
- Why is QA the most important factor behind successful software projects? QA helps create high quality products through well-defined processes without shortcuts in development.
- How to develop quality software and not go bankrupt? Choose the optimal QA strategy including the right testing approach, layers, and automation for cost-effective quality.
- Which types of tests will be the best? Consider the Test Pyramid vs Testing Trophy to discuss and decide on the best testing types including integration, unit, and end-to-end tests.
Code Quality Control in a PHP project. GeekTalks, Cherkassy 2020Andrew Yatsenko
When one experienced and 5 junior developers are working on the project, the team leader can monitor the quality of the code manually, using the help of simple static analyzers like phpmd and phpcs.
In this report, we will consider what to do next, with the growth of the team, when there are too many people for manual control, the teams already consist of strong developers. Approaches, methods of automation tools that we use on the open-source B2B eCommerce platform to control the quality of the code.
The document discusses best practices for submitting pull requests, including:
- Using meaningful commit messages that describe the purpose and changes of a commit, rather than meaningless messages.
- Limiting each pull request to one commit or a small number of related commits, rather than including multiple unrelated commits in a single request.
- Ensuring pull requests pass all continuous integration tests before requesting review, and addressing any failures or issues found by CI systems.
- Distinguishing commit messages, which describe changes, from code comments, which explain the code itself.
Agile and waterfall the additional value Lior Israel
This document discusses Agile and Waterfall methodologies. It provides definitions of Agile, describes the author's experience with Agile, and compares advantages of Agile and Waterfall. Key aspects of implementing Agile such as roles, ceremonies, artifacts, and processes are outlined. The document emphasizes delivering working products through collaboration while still using processes and tools.
Pull requests can be analyzed quantitatively to evaluate developer performance. Metrics like cycle time, number of comments, and pull request size are captured from version control systems and used to generate scorecards for both developers and reviewers. Natural language processing techniques like BERT are used to classify comment types which factor into developer scores. This provides an objective way to assess skills and opportunities for improvement within agile teams. The presented approach is currently used for quarterly reviews at a company and has led to focused training and more efficient task allocation.
High Performance Software Engineering TeamsLars Thorup
Based on my experiences building high performance engineering teams, this presentation focuses on the technical practices required. These practices centers around automation (build, test and deployment) and increased collaboration between Engineering and QA (TDD, exploratory testing, prioritization, feedback cycles).
This document discusses the role of business analysts (BAs) in software development projects and testing. It notes that many projects fail due to poor requirements, lack of communication, or an inability to manage changes. The BA plays an important role in eliciting requirements, communicating with stakeholders, and ensuring requirements are tested throughout development in an iterative process. BAs should work closely with developers from the start of a project using techniques like agile development and iterative testing to help address changes and improve the chances of project success.
The document discusses issues that can arise with Agile practices and provides suggestions for improvement. It notes that while Agile principles aim for customer satisfaction, changing requirements, and frequent delivery, some implementations experience problems like a lack of continuous improvement, low code quality, and cultural challenges. The document advocates rediscovering the heart of Agile and experimentation to address these issues, and provides an example of using specification by example to improve collaboration between developers and quality specialists. It concludes by acknowledging Agile is a learning process and that change is needed for progress.
The document discusses testing concepts such as code with tests vs without tests, test-oriented development, and different types of testing including unit testing, integration testing, and acceptance testing. It provides examples of test-driven development (TDD) and behavior-driven development (BDD) processes. The document also discusses tips for testing, including only testing what is necessary and identifying the appropriate types of testing for an application. Frameworks and tools for test automation and continuous integration are also mentioned.
Agile testing focuses on delivering valuable working software through collaboration, feedback, and automation. It involves the whole team taking responsibility for quality. Agile testers provide continuous feedback, prioritize value, and think critically to challenge assumptions and find problems. They collaborate with developers to shift testing left in the SDLC through approaches like specification by example and behavior driven development which define examples of desired behavior to build shared understanding.
Development Projects Failing? What can the Business Analyst Do?CTE Solutions Inc.
This seminar strives to explore why development projects often fail to deliver and what the BA can do about it. Though there are no magic solutions that will fix development challenges, there are industry recognized practices that can help the BA or PM strive to keep the work on track and deliver value to the client on time. The first half of the presentation explores the cause of development project failures and the second half presents practical and applicable solutions that any BA or PM can bring back to their team.
The document discusses the benefits and process of peer code reviews. It notes that code reviews can improve code quality by reducing defects, improve knowledge transfer between developers, and lead to shorter development cycles. However, developers may be reluctant for personal or social reasons, such as hurt feelings from criticism or a desire to avoid scrutiny. The document recommends treating reviews as a learning opportunity rather than personal criticism. It outlines different types of peer reviews and provides tips for conducting an "over the shoulder" review, including using a review tool to track feedback.
This document provides information about an upcoming presentation on effective unit testing in MuleSoft. The presentation will be given by Josh Erney, a MuleSoft Ambassador with over 5 years of experience developing and architecting MuleSoft solutions. The presentation will focus on 5 key steps for effective unit testing: 1) Understanding the value of unit tests, 2) Asserting code meets interface contracts, 3) Writing testable code, 4) Removing noise from tests, and 5) Prioritizing valuable tests over code coverage. The presenter will provide examples and tips for writing high-quality unit tests that reduce maintenance costs and increase development velocity. Attendees will learn how to identify important tests, write testable code, and focus
Code quality and its business value, Nikita BelovCzechDreamin
Very often the importance of the code quality is underestimated especially by business people who usually don’t see the business value of it. In this session we will try to discover all the advantages of well written code and discuss how coding standards, code reviews and static code analyzer can help to maintain the level of quality and bring the business value.
Our trainers will cover both the theoretical and practical side of working with Oro – from configuring the environment to building applications, testing, code review, assurance, and more.
We are going to deep into the search logic of the Oro Commerce, see what are the common features and requirements, and how to implement them using Elasticsearch. We will cover search boosting, synonym management, fuzzy search, and discuss an overall approach for search customization.
Elasticsearch is a very flexible and useful search tool for any application. It helps to store data in multiple scopes, customize search relevance, collect statistics, and improve overall user experience. Let us see how Elasticsearch has been integrated with OroCommerce to improve E-Commerce flows and achieve better results. We will use the OroCommerce application to show real life use cases and how to implement them.
OroPlatform and OroCRM from a developer's perspectiveYevhen Shyshkin
This document provides an overview of OroPlatform and OroCRM from a developer's perspective. It describes the backend and frontend MVC structure, Symfony basics like bundles and dependency injection. It also covers key development aspects like Doctrine ORM, entities and extensions, datagrids, workflows, and the developers environment. The goal is to help developers understand the architecture and main components for developing applications on the OroPlatform.
First we will talk about localization of applications built with Oro Platfrom, how and where use localization on backend and frontent sides and which parts must not be involved into localization process. Then we'll check translation tools and customizations done in Oro Platform and discuss possibilities of their usages during development process.
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!
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
Artificia Intellicence and XPath Extension FunctionsOctavian Nadolu
The purpose of this presentation is to provide an overview of how you can use AI from XSLT, XQuery, Schematron, or XML Refactoring operations, the potential benefits of using AI, and some of the challenges we face.
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.
Liberarsi dai framework con i Web Component.pptxMassimo Artizzu
In Italian
Presentazione sulle feature e l'utilizzo dei Web Component nell sviluppo di pagine e applicazioni web. Racconto delle ragioni storiche dell'avvento dei Web Component. Evidenziazione dei vantaggi e delle sfide poste, indicazione delle best practices, con particolare accento sulla possibilità di usare web component per facilitare la migrazione delle proprie applicazioni verso nuovi stack tecnologici.
Flutter is a popular open source, cross-platform framework developed by Google. In this webinar we'll explore Flutter and its architecture, delve into the Flutter Embedder and Flutter’s Dart language, discover how to leverage Flutter for embedded device development, learn about Automotive Grade Linux (AGL) and its consortium and understand the rationale behind AGL's choice of Flutter for next-gen IVI systems. Don’t miss this opportunity to discover whether Flutter is right for your project.
Microservice Teams - How the cloud changes the way we workSven Peters
A lot of technical challenges and complexity come with building a cloud-native and distributed architecture. The way we develop backend software has fundamentally changed in the last ten years. Managing a microservices architecture demands a lot of us to ensure observability and operational resiliency. But did you also change the way you run your development teams?
Sven will talk about Atlassian’s journey from a monolith to a multi-tenanted architecture and how it affected the way the engineering teams work. You will learn how we shifted to service ownership, moved to more autonomous teams (and its challenges), and established platform and enablement teams.
Consistent toolbox talks are critical for maintaining workplace safety, as they provide regular opportunities to address specific hazards and reinforce safe practices.
These brief, focused sessions ensure that safety is a continual conversation rather than a one-time event, which helps keep safety protocols fresh in employees' minds. Studies have shown that shorter, more frequent training sessions are more effective for retention and behavior change compared to longer, infrequent sessions.
Engaging workers regularly, toolbox talks promote a culture of safety, empower employees to voice concerns, and ultimately reduce the likelihood of accidents and injuries on site.
The traditional method of conducting safety talks with paper documents and lengthy meetings is not only time-consuming but also less effective. Manual tracking of attendance and compliance is prone to errors and inconsistencies, leading to gaps in safety communication and potential non-compliance with OSHA regulations. Switching to a digital solution like Safelyio offers significant advantages.
Safelyio automates the delivery and documentation of safety talks, ensuring consistency and accessibility. The microlearning approach breaks down complex safety protocols into manageable, bite-sized pieces, making it easier for employees to absorb and retain information.
This method minimizes disruptions to work schedules, eliminates the hassle of paperwork, and ensures that all safety communications are tracked and recorded accurately. Ultimately, using a digital platform like Safelyio enhances engagement, compliance, and overall safety performance on site. https://safelyio.com/
2. Who am I?
Yevhen “Gienek” Shyshkin
● 12+ years of dev experience
● 8+ years in eCommerce
Roles
● Developer
● Tech Writer
● Tech Lead
● Team Lead
● Systems Architect
● Trainer
3. What is Code Review?
● Get a code
● Check a code
● Find a bug
● Report a bug
● ???
● PROFIT!!!
5. Why do I need Code Review?
● Better code quality
● Finding defects
● Learning/knowledge transfer
● Increase sense of mutual
responsibility
● Finding better solutions
● Complying to QA guidelines
7. Preparation
● Investigating the review scope
● Listing most common use cases
● Listing possible bottlenecks
● Creating a checklist of steps to
follow
● Discussing critical issues
● Documenting items
8. Commenting
● Simple, intelligible, and brief
● Precise, explicit, explanatory
● Friendly and positive
● Real communication
● Post review discussion
10. Amount / Time
● 200-400 lines is recommended
● 800 lines is maximum
● Up to 2 consecutive hours
● 200-400 lines per hour
● If you need to review more - split
into smaller pieces
13. Functional Review
● Functionality works as described
● Related functionality is identified
and tested
● Manual check throughout the
production environment
23. Tips and Tricks
● Self-review
● Use IDE-integrable tools
● Fix not found issues
● Describe the issue in maximum
detail
● Fix described and related issues