The document discusses clean coding practices for Java developers. It covers topics such as choosing meaningful names for variables, methods, and classes; writing code that is easy for others to understand; breaking methods down into single logical steps; and using fluent APIs to make code more readable. The presentation provides examples of clean code and ways to refactor code to follow best practices.
A summary of clean code concepts and tips along with some examples and good practices.
These are the slides translated in English from my talk on Clean Code to my coworkers back then
Presentación para la charla sobre el libro de Robert C. Martin, Clean Code.
Esta presentación la impartí en CyLicon Valley, aquí tenéis el video con el audio de la charla => https://www.youtube.com/watch?v=1Fss1jBfc3g
A summary of clean code concepts and tips along with some examples and good practices.
These are the slides translated in English from my talk on Clean Code to my coworkers back then
Presentación para la charla sobre el libro de Robert C. Martin, Clean Code.
Esta presentación la impartí en CyLicon Valley, aquí tenéis el video con el audio de la charla => https://www.youtube.com/watch?v=1Fss1jBfc3g
Clean Pragmatic Architecture - Avoiding a MonolithVictor Rentea
Talk built based on several of my trainings: http://www.victorrentea.ro/#training
Covers: Clean/Onion/Hexagonal Architecture, Domain Entities, Value Objects, Repository, Extract When it Grows Principle, Dependency Inversion Principle, Clean Code and Design Patterns.
These are the backing slides of the talks given at JPoint 2017 and Devoxx PL 2017: https://www.youtube.com/embed/4-4ahz7zDiQ
All 3 Clean Code presentations provide great value by themselves, but taken together are designed to offer a holistic approach to successful software creation. This first session creates the foundation for the 2nd and 3rd Clean Code presentation on Dependency Injection, as it explains expected base knowledge. Why writing Clean Code makes us more efficient Over the lifetime of a product, maintaining the product is actually one - if not the most - expensive area(s) of the overall product costs.
Writing clean code can significantly lower these costs. However, writing clean code also makes you more efficient during the initial development time and results in more stable code. You will be presented design patterns and best practices which will make you write better and more easily maintainable code, seeing code in a holistic way.
You will learn how to apply them by using an existing implementation as the starting point of the presentation. Finally, patterns & practices benefits are explained. This presentation is based on C# and Visual Studio 2012. However, the demonstrated patterns and practice can be applied to every other programming language too.
Note: Moving forwards this presentation will be updated with the latest version of the slides for the last event I did the presentation instead of creating new separate slide decks here on SlideShare.
Presentation dates and locations:
2015-10-03 Silicon Valley Code Camp, San Jose, CA
2015-06-27 SoCal Code Camp - San Diego, CA
2014-11-14 SoCal Code Camp - Los Angeles, CA
2014-10-18 Desert Code Camp - Chandler, AZ
2014-10-11 Silicon Valley Code Camp, Los Altos Hills, CA
Slides of the talk held at JEEConf, Kiev and jPrime, Sofia. A personal view on the classic topics from the Uncle Bob's Clean Code bible, with some personal additions and tips&tricks. This topic actually represents the core of the training sessions that I provide as an independent trainer (www.victorrentea.ro)
Presentation on writing clean and maintainable good. I have present really simple steps to write high quality code and share many more benefit of writing clean code.
We like the architecture of our applications to revolve around the business logic, not around technical details (and especially not around the database).
In my team at Sky Network Services we use the Clean Architecture and it has given us a great deal of benefits: the business logic is explicit, we are free to change our technical decisions, the app is easy to test, working on it is faster and scalable, it’s hard to do the wrong thing, and many more.
But it comes at a cost, of course. In this talk I’ll tell you the story of our experience with Clean Architecture and give you some tips to get the most out of it.
Example Project
https://github.com/mattia-battiston/clean-architecture-example
Downloads
Online: https://goo.gl/DTxftJ
PDF: https://goo.gl/ZAtdBN
Powerpoint: https://goo.gl/D54wdZ (but you need to install these fonts to see it properly: https://goo.gl/iH8SO5)
How should a professional software developer behave in code? What guidelines should one follow? How should we name our constructs? What about OOP principles? What's their real use?
This classic training module in my training curricula is the cornerstone of my professionalism. These are my conduit guidelines at work. I've held this training > 10 times, including at Voxxed Days Bucharest 2016 and at a Bucharest Java User Group meetup.
Vladimir Romanov - How to write code that is easy to read and change? What should you do when you see a piece of code written years ago which is hard to understand? In my experience, this boils down to 4 principles that I would like to share along with some examples in Apex
In this Meetup Victor Perepelitsky - R&D Technical Leader at LivePerson leading the 'Real Time Event Processing Platform' team , will talk about Java 8', 'Stream API', 'Lambda', and 'Method reference'.
Victor will clarify what functional programming is and how can you use java 8 in order to create better software.
Victor will also cover some pain points that Java 8 did not solve regarding functionality and see how you can work around it.
Rule 1: Follow a consistent coding standard
Rule 2: Name things properly, long variable and function names are allowed
Rule 3: Be expressive, write code as you speak and be optimally verbose
Rule 4: Max indent per method should be 2, in case of exceptions 3
Rule 5: Avoid creating god object and long methods
Rule 6: Keep the method in one place, inject the class and call it, DRY
Rule 7: Avoid in-line comments (comment with code), put comments in the method doc
Domain Driven Design (DDD) is a topic that's been gaining a lot of popularity in both the Java and .NET camps recently. Entities, value types, repositories, bounded contexts and anti-corruption layers -- find out what all the buzz is about, and how establishing a domain model can help you combat complexity in your code.
Richard Dingwall is a .NET developer and blogger with a passion for architecture and maintainable code.
He is currently working at Provoke Solutions as lead developer on a six-month project introducing test-driven development (TDD) and domain-driven design (DDD) to a large ASP.NET ERP system.
An hour-long talk given at Wellington .NET user group, Sept 23 2009.
Clean Pragmatic Architecture - Avoiding a MonolithVictor Rentea
Talk built based on several of my trainings: http://www.victorrentea.ro/#training
Covers: Clean/Onion/Hexagonal Architecture, Domain Entities, Value Objects, Repository, Extract When it Grows Principle, Dependency Inversion Principle, Clean Code and Design Patterns.
These are the backing slides of the talks given at JPoint 2017 and Devoxx PL 2017: https://www.youtube.com/embed/4-4ahz7zDiQ
All 3 Clean Code presentations provide great value by themselves, but taken together are designed to offer a holistic approach to successful software creation. This first session creates the foundation for the 2nd and 3rd Clean Code presentation on Dependency Injection, as it explains expected base knowledge. Why writing Clean Code makes us more efficient Over the lifetime of a product, maintaining the product is actually one - if not the most - expensive area(s) of the overall product costs.
Writing clean code can significantly lower these costs. However, writing clean code also makes you more efficient during the initial development time and results in more stable code. You will be presented design patterns and best practices which will make you write better and more easily maintainable code, seeing code in a holistic way.
You will learn how to apply them by using an existing implementation as the starting point of the presentation. Finally, patterns & practices benefits are explained. This presentation is based on C# and Visual Studio 2012. However, the demonstrated patterns and practice can be applied to every other programming language too.
Note: Moving forwards this presentation will be updated with the latest version of the slides for the last event I did the presentation instead of creating new separate slide decks here on SlideShare.
Presentation dates and locations:
2015-10-03 Silicon Valley Code Camp, San Jose, CA
2015-06-27 SoCal Code Camp - San Diego, CA
2014-11-14 SoCal Code Camp - Los Angeles, CA
2014-10-18 Desert Code Camp - Chandler, AZ
2014-10-11 Silicon Valley Code Camp, Los Altos Hills, CA
Slides of the talk held at JEEConf, Kiev and jPrime, Sofia. A personal view on the classic topics from the Uncle Bob's Clean Code bible, with some personal additions and tips&tricks. This topic actually represents the core of the training sessions that I provide as an independent trainer (www.victorrentea.ro)
Presentation on writing clean and maintainable good. I have present really simple steps to write high quality code and share many more benefit of writing clean code.
We like the architecture of our applications to revolve around the business logic, not around technical details (and especially not around the database).
In my team at Sky Network Services we use the Clean Architecture and it has given us a great deal of benefits: the business logic is explicit, we are free to change our technical decisions, the app is easy to test, working on it is faster and scalable, it’s hard to do the wrong thing, and many more.
But it comes at a cost, of course. In this talk I’ll tell you the story of our experience with Clean Architecture and give you some tips to get the most out of it.
Example Project
https://github.com/mattia-battiston/clean-architecture-example
Downloads
Online: https://goo.gl/DTxftJ
PDF: https://goo.gl/ZAtdBN
Powerpoint: https://goo.gl/D54wdZ (but you need to install these fonts to see it properly: https://goo.gl/iH8SO5)
How should a professional software developer behave in code? What guidelines should one follow? How should we name our constructs? What about OOP principles? What's their real use?
This classic training module in my training curricula is the cornerstone of my professionalism. These are my conduit guidelines at work. I've held this training > 10 times, including at Voxxed Days Bucharest 2016 and at a Bucharest Java User Group meetup.
Vladimir Romanov - How to write code that is easy to read and change? What should you do when you see a piece of code written years ago which is hard to understand? In my experience, this boils down to 4 principles that I would like to share along with some examples in Apex
In this Meetup Victor Perepelitsky - R&D Technical Leader at LivePerson leading the 'Real Time Event Processing Platform' team , will talk about Java 8', 'Stream API', 'Lambda', and 'Method reference'.
Victor will clarify what functional programming is and how can you use java 8 in order to create better software.
Victor will also cover some pain points that Java 8 did not solve regarding functionality and see how you can work around it.
Rule 1: Follow a consistent coding standard
Rule 2: Name things properly, long variable and function names are allowed
Rule 3: Be expressive, write code as you speak and be optimally verbose
Rule 4: Max indent per method should be 2, in case of exceptions 3
Rule 5: Avoid creating god object and long methods
Rule 6: Keep the method in one place, inject the class and call it, DRY
Rule 7: Avoid in-line comments (comment with code), put comments in the method doc
Domain Driven Design (DDD) is a topic that's been gaining a lot of popularity in both the Java and .NET camps recently. Entities, value types, repositories, bounded contexts and anti-corruption layers -- find out what all the buzz is about, and how establishing a domain model can help you combat complexity in your code.
Richard Dingwall is a .NET developer and blogger with a passion for architecture and maintainable code.
He is currently working at Provoke Solutions as lead developer on a six-month project introducing test-driven development (TDD) and domain-driven design (DDD) to a large ASP.NET ERP system.
An hour-long talk given at Wellington .NET user group, Sept 23 2009.
Workshop slides from the Alt.Net Seattle 2011 workshop. Presented by Wes Dyer and Ryan Riley. Get the slides and the workshop code at http://rxworkshop.codeplex.com/
REX about JavaFX8 used in SlideshowFX. This presentation covers concept from JavaFX as well as technologies like OSGi, Vert.x, LeapMotion, nashorn and friends in order to make them communicate inside one application developed in JavaFX.
This presentation was made at the ElsassJUG
Poche chiacchiere e tanto codice per cercare rendere la nostra vita di
sviluppatori più divertente.
Parleremo di JAX-RS, le annotazioni, l'MVC che mette a disposizione e
l'integrazione di Jersey con Guice.
Useremo AOP per gestire log, transazioni e con l'aiuto di Infinispan
limiteremo le chamate concorrenti sul nostro cluster.
Learn how to write scripted load tests in PHP to run against your system without breaking the bank. Jason will cover not only the importance of load testing, but share stories of how load tests uncovered problems that would otherwise not have been discovered until production. Also, learn how to use load testing to learn how to deal with large traffic sites without needing to be employed by a large scale site first. We’ll be using RedLine13, an almost free load testing tool that is at the same time inexpensive, easy, and effective.
Лаконічні та елегантні автоматизовані тести? Безболісний (майже) тестовий стек для UI веб-додатків? Більше часу, щоб випити кави/пограти у Cuphead/ подивитись у порожнечу?
Ми поговоримо про Lombok, Vavr, Owner, чому вам варто використовувати готові рішення та як зробити тести більш лаконічними та читабельними. Вам знадобиться Vaper та/або гіроборд.
Written specs are easy to read but hard to write. Even with an understanding of the principles and tips for writing good Gherkin, it can be very hard to keep scenarios clean, informative and readable.
These slides are from a workshop given by John Ferguson Smart and Tom Roden, where they take a practical look at some real-world Gherkin scenarios, investigate what makes them smell and practise how to improve them. Discover some powerful refactoring patterns to help make your own specs a joy to read.
It was the time of Da Vinci and Michelangelo. It was also the time of Machiavelli and the Medici. Artists working on timeless masterpieces crossed paths with mercenary captains, contracted to do a very specific job.
In this keynote talk, John Smart will address important questions with deep implications for any IT team, or any organisation trying to make a difference, or simply to get the most value out of their IT projects.
Who is your real customer? Is there a cost to quality? Are you building an artwork that will last, or simply fulfilling a contract?
An inspiring and entertaining talk that will take attendees on journey from the Italian Renaissance to Silicon Valley and the City of London, and see what lessons can be learned about cultures, attitudes and work ethics today.
Discover how you can multiply your team’s productivity and innovation by engaging the creativity of your whole team from the outset. Drawing from his long experience helping teams deliver better software faster and more effectively, John will discuss the latest practical techniques leveraged from Behaviour Driven Development, Lean Enterprise, DevOps, and Test Automation, combined with research in Psychology and Team Performance, to show you how to get the best out of your teams.
Learn about the new roles of business analysts, developers and testers in the future of software development, where testers can play a vital role in not only detecting defects but preventing them. Discover how you can make test automation happen during, not after, the sprint, and how to engage the creativity of the whole team right from the word "go".
his talk will present the core concepts of Exponential Business Agility, or XBA. XBA is a set of patterns for organising value streams around self-organising, autonomous teams, and is part of the XSCALE approach to scaling agile. XBA combines the Spotify model with practice patterns drawn from the Iroquois Confederacy, the most successful and longest-lived holarchy in history.
Learn how Throughput Accounting optimises the contribution of each business function to top line throughput rather than blindly attempting to minimise operating expense.
And discover how Self-Propagating Transformation avoids pushing change into pre-existing teams, programs or silos, but generates agile capability by grafting the kernel of a new culture onto the trunk of the old.
Be a pod of dolphins, not a dancing elephant. Don’t try to scale agile. De-scale your organisation instead.
As projects get faster and teams get leaner, the need to write high quality automated acceptance criteria quickly and efficiently has never been greater. Engineers in Test simply cannot afford to spend time maintaining brittle tests. And yet, without solid test automation strategies, this is what many teams find themselves doing. In this workshop, you will learn a better way. You will learn how to write clean, clear and maintainable tests using the Screenplay Pattern, an innovative new approach to writing BDD-style automated acceptance tests that are easier to understand, easier to extend and easier to maintain. The workshop will be a practical demonstration of the principles of good automated test design. There will be live coding of real-world BDD automated acceptance tests in abundance, using Java, Serenity BDD and Cucumber. We will go from requirements and BDD-style Acceptance Criteria in Cucumber right through to automated acceptance tests and living documentation.
Writing good acceptance criteria is one of the keys to effective software delivery. But it’s hard. In this workshop, you will learn about Feature Mapping, a new technique and easy that can help teams write higher quality acceptance criteria more easily. Feature Mapping is an excellent way to build a deep shared understanding of a story's requirements and clear a path to a smooth implementation of automated acceptance tests.
International speaker and author of “BDD in Action” John Ferguson Smart shows how you can multiply your team’s productivity and innovation by engaging the creativity of your whole team from the outset. Drawing from his long experience helping teams deliver better software faster and more effectively, John will discuss the latest practical techniques leveraged from Behaviour Driven Development, Lean Enterprise, DevOps, and Test Automation, combined with research in Psychology and Team Performance, to show you how to get the best out of your teams. Learn about the new roles of business analysts, developers and testers in a DevOps world, and how testers can play a vital role in not only detecting defects but preventing them. Discover how you can make test automation happen during, not after, the sprint, and how to engage the creativity of the whole team right from the word "go".
IT teams today are under constant pressure to deliver more value sooner, and Behaviour Driven Development (BDD) is one of the more effective ways to help teams deliver the high quality software that their business needs. When they adopt BDD, many teams look to tools like Cucumber to help them. But BDD isn’t simply about picking up a new tool.
In fact, there is a lot more to BDD than Given/When/Then and tools like Cucumber, and both can be misused. In this talk, we will take a step back and look at the bigger picture, and learn why using Gherkin at the wrong time, or for the wrong purpose, may be holding you back.
IT teams today are under constant pressure to deliver more value sooner, and Behaviour Driven Development (BDD) is one of the more effective ways to help teams deliver the high quality software that their business needs. When they adopt BDD, many teams look to tools like Cucumber to help them. But BDD isn’t simply about picking up a new tool.
In fact, there is a lot more to BDD than Given/When/Then and tools like Cucumber, and both can be misused. In this talk, we will take a step back and look at the bigger picture, and learn why using Gherkin at the wrong time, or for the wrong purpose, may be holding you back.
The changing role of testing and test automation in the increasingly fast-paced world of continuous delivery and automated acceptance testing. Learn how, in a DevOps environment, testing activities start with requirements discovery and definition, playing a vital role in not only detecting defects, but preventing them, and ensuring not only that the features are built right, but the right features are built. And learn how test automation needs to happen during, not after, the sprint, and how you can achieve this.
Despite rumors to the contrary, the role of the tester is not diminished with the arrival of automated DevOps, with its ultra-rapid deployment cycles and its emphasis on automation. On the contrary, testers play a vital role in ensuring that the code that gets deployed ten times a day is worth deploying.
Learn how to write robust and articulate tests using the Screenplay Pattern, an innovative approach to writing BDD-style automated acceptance tests that are easier to understand, easier to extend and easier to maintain.
The essentials of Cucumber-JVM and Spock - a handbook written for the BDD/TDD Masterclass (https://johnfergusonsmart.com/programs-courses/bdd-tdd-clean-coding/)
Every test tells a story, but some tell a better story than others. Every test illustrates a specific path through the system to achieve a specific goal, but some paths are clearer than others. Valuable tests are the ones that both tell a compelling story, and can stand the test of time, providing value not only as acceptance tests but also as living documentation and easily maintainable regression tests.
In this session, John will invite you to come on a journey of discovery to learn how to write clean, clear and maintainable tests using the Journey Pattern, an innovative new approach to writing automated acceptance tests that are easier to understand, easier to extend and easier to maintain. You will also witness a demonstration of these principles in action, with live coding of Serenity BDD automated tests.
Learn how to plan, prioritise and deliver higher value features by thinking of deliverable features not in terms of what they cost, but of what they can deliver.
XScale is a set of practices based on BDD that enables a product team to efficiently define, budget and prioritise a roadmap or backlog.
It’s also a way to answer some questions Agile has traditionally avoided:
- How much will a set of features cost?
- How do we trade off different feature sets?
- How do we know a feature is ready to ship?
In this workshop, we outline several key practices and practice using a few of them. The main practices we cover include:
- Feature Points, a way to reconcile budgets with story points
- Backlog Bingo determines the dollar investment and relative return for a set of products and services
- Royal Cod applies Backlog Bingo to prioritize a Breadth-First Roadmap
- Release Refactoring enables product owners to make rational trade-offs between feature-sets.
Behaviour Driven Development is a powerful collaboration technique that can empower teams to deliver higher value features to the business faster and more effectively. But although Behaviour Driven Development is based on a number of simple principles, it can go dramatically wrong in a myriad of different ways.
In this talk we discuss twelve BDD anti-patterns we frequently encounter in real-world BDD projects, anti-patterns that can dramatically reduce the effectiveness of BDD as a practice, and that can even cause BDD adoption to fail entirely. Looking at everything from insufficient collaboration practices to poor use of test automation tooling, from teams that test too much to teams that forget the most important scenarios, we will look at the many different ways that BDD can go wrong, and how it should be done.
We will use real-world examples to illustrate each of these anti-patterns. You will learn how to spot these issues in your own projects, and more importantly how to avoid them in the first place.
Every test tells a story, but some tell a better story than others. Every test illustrates a specific path through the system to achieve a specific goal, but some paths are clearer than others. Valuable tests are the ones that tell a compelling story.
Come on a journey of discovery to learn how to write such tests, and witness a demonstration of these principles in action, with live coding of Serenity BDD automated tests.
Behaviour-Driven Development (BDD) is a game changer for the whole team! Behaviour Driven Development is a powerful collaboration technique that can empower teams to deliver higher value features to the business faster and more effectively. More than just a testing technique, BDD is both a collaboration and a verification tool, and a vital step on the road to Continuous Delivery.
Think BDD is just for web sites? Think again! In this talk, we rethink traditional software testing strategies in the context of micro-services and Behaviour-Driven Development. We will see how traditional testing approaches are both inadequate and poorly targeted for micro-services development. We will learn how to use BDD techniques to discover, describe and document micro-service requirements, and tools like Cucumber and Serenity to turn these requirements into automated acceptance tests and living documentation. We will see how Consumer-Driven Contract tools help ensure that micro-services play well together, and how you can implement the details with the help of unit-testing tools like Spock and REST-Assured.
Behaviour Driven Development is a powerful collaboration technique that can empower teams to deliver higher value features to the business faster and more effectively. But although Behaviour Driven Development is based on a number of simple principles, it can go dramatically wrong in a myriad of different ways.
In this talk we discuss twelve BDD anti-patterns we frequently encounter in real-world BDD projects, anti-patterns that can dramatically reduce the effectiveness of BDD as a practice, and that can even cause BDD adoption to fail entirely. Looking at everything from insufficient collaboration practices to poor use of test automation tooling, from teams that test too much to teams that forget the most important scenarios, we will look at the many different ways that BDD can go wrong, and how it should be done.
We will use real-world examples to illustrate each of these anti-patterns. You will learn how to spot these issues in your own projects, and more importantly how to avoid them in the first place.
Behaviour Driven Development is an increasingly popular Agile practice that turns testing on its head, and involves a major shift in the role testers play in a project. Although popularly associated with automated acceptance testing and tools like Cucumber, BDD actually has much broader applications. In this talk, we will look at how Behaviour Driven Development radically changes the traditional tester role in Agile projects, and empowers them to tangibly contribute much more to the successful outcomes of the project. We will see how collaboratively discussing and defining acceptance criteria help reduce assumptions and errors in the early phases of the project, and help ensure that the features being built are well understood, testable, and valuable to the business. We will look at ways to write more effective, easier to maintain automated acceptance criteria, that free testers to do more productive testing tasks such as exploratory testing. And we will see how automated and manual acceptance test reporting can be combined to provide valuable progress, product documentation and release preparation reporting.
Software Delivery At the Speed of AI: Inflectra Invests In AI-Powered QualityInflectra
In this insightful webinar, Inflectra explores how artificial intelligence (AI) is transforming software development and testing. Discover how AI-powered tools are revolutionizing every stage of the software development lifecycle (SDLC), from design and prototyping to testing, deployment, and monitoring.
Learn about:
• The Future of Testing: How AI is shifting testing towards verification, analysis, and higher-level skills, while reducing repetitive tasks.
• Test Automation: How AI-powered test case generation, optimization, and self-healing tests are making testing more efficient and effective.
• Visual Testing: Explore the emerging capabilities of AI in visual testing and how it's set to revolutionize UI verification.
• Inflectra's AI Solutions: See demonstrations of Inflectra's cutting-edge AI tools like the ChatGPT plugin and Azure Open AI platform, designed to streamline your testing process.
Whether you're a developer, tester, or QA professional, this webinar will give you valuable insights into how AI is shaping the future of software delivery.
Builder.ai Founder Sachin Dev Duggal's Strategic Approach to Create an Innova...Ramesh Iyer
In today's fast-changing business world, Companies that adapt and embrace new ideas often need help to keep up with the competition. However, fostering a culture of innovation takes much work. It takes vision, leadership and willingness to take risks in the right proportion. Sachin Dev Duggal, co-founder of Builder.ai, has perfected the art of this balance, creating a company culture where creativity and growth are nurtured at each stage.
Essentials of Automations: Optimizing FME Workflows with ParametersSafe Software
Are you looking to streamline your workflows and boost your projects’ efficiency? Do you find yourself searching for ways to add flexibility and control over your FME workflows? If so, you’re in the right place.
Join us for an insightful dive into the world of FME parameters, a critical element in optimizing workflow efficiency. This webinar marks the beginning of our three-part “Essentials of Automation” series. This first webinar is designed to equip you with the knowledge and skills to utilize parameters effectively: enhancing the flexibility, maintainability, and user control of your FME projects.
Here’s what you’ll gain:
- Essentials of FME Parameters: Understand the pivotal role of parameters, including Reader/Writer, Transformer, User, and FME Flow categories. Discover how they are the key to unlocking automation and optimization within your workflows.
- Practical Applications in FME Form: Delve into key user parameter types including choice, connections, and file URLs. Allow users to control how a workflow runs, making your workflows more reusable. Learn to import values and deliver the best user experience for your workflows while enhancing accuracy.
- Optimization Strategies in FME Flow: Explore the creation and strategic deployment of parameters in FME Flow, including the use of deployment and geometry parameters, to maximize workflow efficiency.
- Pro Tips for Success: Gain insights on parameterizing connections and leveraging new features like Conditional Visibility for clarity and simplicity.
We’ll wrap up with a glimpse into future webinars, followed by a Q&A session to address your specific questions surrounding this topic.
Don’t miss this opportunity to elevate your FME expertise and drive your projects to new heights of efficiency.
Elevating Tactical DDD Patterns Through Object CalisthenicsDorra BARTAGUIZ
After immersing yourself in the blue book and its red counterpart, attending DDD-focused conferences, and applying tactical patterns, you're left with a crucial question: How do I ensure my design is effective? Tactical patterns within Domain-Driven Design (DDD) serve as guiding principles for creating clear and manageable domain models. However, achieving success with these patterns requires additional guidance. Interestingly, we've observed that a set of constraints initially designed for training purposes remarkably aligns with effective pattern implementation, offering a more ‘mechanical’ approach. Let's explore together how Object Calisthenics can elevate the design of your tactical DDD patterns, offering concrete help for those venturing into DDD for the first time!
State of ICS and IoT Cyber Threat Landscape Report 2024 previewPrayukth K V
The IoT and OT threat landscape report has been prepared by the Threat Research Team at Sectrio using data from Sectrio, cyber threat intelligence farming facilities spread across over 85 cities around the world. In addition, Sectrio also runs AI-based advanced threat and payload engagement facilities that serve as sinks to attract and engage sophisticated threat actors, and newer malware including new variants and latent threats that are at an earlier stage of development.
The latest edition of the OT/ICS and IoT security Threat Landscape Report 2024 also covers:
State of global ICS asset and network exposure
Sectoral targets and attacks as well as the cost of ransom
Global APT activity, AI usage, actor and tactic profiles, and implications
Rise in volumes of AI-powered cyberattacks
Major cyber events in 2024
Malware and malicious payload trends
Cyberattack types and targets
Vulnerability exploit attempts on CVEs
Attacks on counties – USA
Expansion of bot farms – how, where, and why
In-depth analysis of the cyber threat landscape across North America, South America, Europe, APAC, and the Middle East
Why are attacks on smart factories rising?
Cyber risk predictions
Axis of attacks – Europe
Systemic attacks in the Middle East
Download the full report from here:
https://sectrio.com/resources/ot-threat-landscape-reports/sectrio-releases-ot-ics-and-iot-security-threat-landscape-report-2024/
Connector Corner: Automate dynamic content and events by pushing a buttonDianaGray10
Here is something new! In our next Connector Corner webinar, we will demonstrate how you can use a single workflow to:
Create a campaign using Mailchimp with merge tags/fields
Send an interactive Slack channel message (using buttons)
Have the message received by managers and peers along with a test email for review
But there’s more:
In a second workflow supporting the same use case, you’ll see:
Your campaign sent to target colleagues for approval
If the “Approve” button is clicked, a Jira/Zendesk ticket is created for the marketing design team
But—if the “Reject” button is pushed, colleagues will be alerted via Slack message
Join us to learn more about this new, human-in-the-loop capability, brought to you by Integration Service connectors.
And...
Speakers:
Akshay Agnihotri, Product Manager
Charlie Greenberg, Host
GraphRAG is All You need? LLM & Knowledge GraphGuy Korland
Guy Korland, CEO and Co-founder of FalkorDB, will review two articles on the integration of language models with knowledge graphs.
1. Unifying Large Language Models and Knowledge Graphs: A Roadmap.
https://arxiv.org/abs/2306.08302
2. Microsoft Research's GraphRAG paper and a review paper on various uses of knowledge graphs:
https://www.microsoft.com/en-us/research/blog/graphrag-unlocking-llm-discovery-on-narrative-private-data/
Kubernetes & AI - Beauty and the Beast !?! @KCD Istanbul 2024Tobias Schneck
As AI technology is pushing into IT I was wondering myself, as an “infrastructure container kubernetes guy”, how get this fancy AI technology get managed from an infrastructure operational view? Is it possible to apply our lovely cloud native principals as well? What benefit’s both technologies could bring to each other?
Let me take this questions and provide you a short journey through existing deployment models and use cases for AI software. On practical examples, we discuss what cloud/on-premise strategy we may need for applying it to our own infrastructure to get it to work from an enterprise perspective. I want to give an overview about infrastructure requirements and technologies, what could be beneficial or limiting your AI use cases in an enterprise environment. An interactive Demo will give you some insides, what approaches I got already working for real.
UiPath Test Automation using UiPath Test Suite series, part 3DianaGray10
Welcome to UiPath Test Automation using UiPath Test Suite series part 3. In this session, we will cover desktop automation along with UI automation.
Topics covered:
UI automation Introduction,
UI automation Sample
Desktop automation flow
Pradeep Chinnala, Senior Consultant Automation Developer @WonderBotz and UiPath MVP
Deepak Rai, Automation Practice Lead, Boundaryless Group and UiPath MVP
The Art of the Pitch: WordPress Relationships and SalesLaura Byrne
Clients don’t know what they don’t know. What web solutions are right for them? How does WordPress come into the picture? How do you make sure you understand scope and timeline? What do you do if sometime changes?
All these questions and more will be explored as we talk about matching clients’ needs with what your agency offers without pulling teeth or pulling your hair out. Practical tips, and strategies for successful relationship building that leads to closing the deal.
Dev Dives: Train smarter, not harder – active learning and UiPath LLMs for do...UiPathCommunity
💥 Speed, accuracy, and scaling – discover the superpowers of GenAI in action with UiPath Document Understanding and Communications Mining™:
See how to accelerate model training and optimize model performance with active learning
Learn about the latest enhancements to out-of-the-box document processing – with little to no training required
Get an exclusive demo of the new family of UiPath LLMs – GenAI models specialized for processing different types of documents and messages
This is a hands-on session specifically designed for automation developers and AI enthusiasts seeking to enhance their knowledge in leveraging the latest intelligent document processing capabilities offered by UiPath.
Speakers:
👨🏫 Andras Palfi, Senior Product Manager, UiPath
👩🏫 Lenka Dulovicova, Product Program Manager, UiPath
9. Choose
your
names
well
"What's in a name? That which we call a rose
By any other name would smell as sweet."
Romeo and Juliet (II, ii, 1-2)
Really?
10. Use
a
common
vocabulary
getCustomerInfo()
getClientDetails()
getCustomerRecord()
...
Which one do I use? Are they the same?
getCustomer()
Choose one and stick to it
11. Use
meaningful
names
int days;
What does this represent?
int daysSinceCreation;
int daysSinceLastModification;
int durationInDays;
These are all more meaningful choices
12. Don’t
talk
in
code
class DtaRcrd102 {
private Date genymdhms;
private Date modymdhms;
private final String pszqint = “102”;
...
} Huh?
class Customer {
private Date generationTimestamp;
private Date modificationTimestamp;
private final String recordId = “102”
...
}
13. But
don’t
state
the
obvious
List<Client> clientList;
Is ‘List’ significant or just noise?
List<Client> clients;
List<Client> regularClients;
List<Client> newClients;
14. In
short:
Don’t
make
me
think!
What does this do?
Clearer parameter name
More explicit method name
What are we counting?
Method call rather than
boolean expression
16. High-Level
Methods
should
be
small Refactoring
public void generateAggregateReportFor(final List<StoryTestResults> storyResults,
final List<FeatureResults> featureResults) throws IOException {
LOGGER.info("Generating summary report for user stories to "+ getOutputDirectory());
copyResourcesToOutputDirectory();
Map<String, Object> storyContext = new HashMap<String, Object>();
storyContext.put("stories", storyResults);
storyContext.put("storyContext", "All stories");
addFormattersToContext(storyContext);
writeReportToOutputDirectory("stories.html",
mergeTemplate(STORIES_TEMPLATE_PATH).usingContext(storyContext));
Map<String, Object> featureContext = new HashMap<String, Object>();
addFormattersToContext(featureContext);
featureContext.put("features", featureResults);
writeReportToOutputDirectory("features.html",
mergeTemplate(FEATURES_TEMPLATE_PATH).usingContext(featureContext));
for(FeatureResults feature : featureResults) {
generateStoryReportForFeature(feature);
}
generateReportHomePage(storyResults, featureResults);
Code hard to understand
getTestHistory().updateData(featureResults);
generateHistoryReport();
}
17. High-Level
Methods
should
be
small Refactoring
public void generateAggregateReportFor(final List<StoryTestResults> storyResults,
final List<FeatureResults> featureResults) throws IOException {
LOGGER.info("Generating summary report for user stories to "+ getOutputDirectory());
copyResourcesToOutputDirectory();
private void Object> storyContext = new HashMap<String, Object>(); storyResults) throws IOException {
Map<String, generateStoriesReport(final List<StoryTestResults>
storyContext.put("stories", storyResults);
Map<String, Object> context = new HashMap<String, Object>();
storyContext.put("storyContext", "All stories");
context.put("stories", storyResults);
addFormattersToContext(storyContext); stories");
context.put("storyContext", "All
writeReportToOutputDirectory("stories.html",
addFormattersToContext(context);
mergeTemplate(STORIES_TEMPLATE_PATH).usingContext(storyContext));
String htmlContents = mergeTemplate(STORIES_TEMPLATE_PATH).usingContext(context);
writeReportToOutputDirectory("stories.html", htmlContents);
Map<String, Object> featureContext = new HashMap<String, Object>();
}
addFormattersToContext(featureContext);
featureContext.put("features", featureResults); Refactor into clear steps
writeReportToOutputDirectory("features.html",
mergeTemplate(FEATURES_TEMPLATE_PATH).usingContext(featureContext));
for(FeatureResults feature : featureResults) {
generateStoryReportForFeature(feature);
}
generateReportHomePage(storyResults, featureResults);
getTestHistory().updateData(featureResults);
generateHistoryReport();
}
18. High-Level
Methods
should
be
small Refactoring
public void generateAggregateReportFor(final List<StoryTestResults> storyResults,
final List<FeatureResults> featureResults) throws IOException {
LOGGER.info("Generating summary report for user stories to "+ getOutputDirectory());
copyResourcesToOutputDirectory();
generateStoriesReportFor(storyResults);
Map<String, Object> featureContext = new HashMap<String, Object>();
addFormattersToContext(featureContext);
featureContext.put("features", featureResults);
writeReportToOutputDirectory("features.html",
mergeTemplate(FEATURES_TEMPLATE_PATH).usingContext(featureContext));
for(FeatureResults feature : featureResults) {
generateStoryReportForFeature(feature);
}
generateReportHomePage(storyResults, featureResults);
getTestHistory().updateData(featureResults);
private void updateHistoryFor(final List<FeatureResults> featureResults) {
generateHistoryReport();
} getTestHistory().updateData(featureResults);
}
19. High-Level
Methods
should
be
small Refactoring
private void generateAggregateReportFor(final List<StoryTestResults> storyResults,
final List<FeatureResults> featureResults)
throws IOException {
copyResourcesToOutputDirectory();
generateStoriesReportFor(storyResults);
generateFeatureReportFor(featureResults);
generateReportHomePage(storyResults, featureResults);
updateHistoryFor(featureResults);
generateHistoryReport();
}
20. High-Level Refactoring
Methods
should
only
do
one
thing
Too much going on here...
public String getReportName(String reportType, final String qualifier) {
if (qualifier == null) {
String testName = "";
if (getUserStory() != null) {
testName = NameConverter.underscore(getUserStory().getName());
}
String scenarioName = NameConverter.underscore(getMethodName());
testName = withNoIssueNumbers(withNoArguments(appendToIfNotNull(testName, scenarioName)));
return testName + "." + reportType;
} else {
String userStory = "";
if (getUserStory() != null) {
userStory = NameConverter.underscore(getUserStory().getName()) + "_";
}
String normalizedQualifier = qualifier.replaceAll(" ", "_");
return userStory + withNoArguments(getMethodName()) + "_" + normalizedQualifier + "." + reportType;
}
}
Mixing what and how
21. High-Level Refactoring
Methods
should
only
do
one
thing
Chose what to do here
public String getReportName(final ReportType type, final String qualifier) {
ReportNamer reportNamer = ReportNamer.forReportType(type);
if (shouldAddQualifier(qualifier)) {
return reportNamer.getQualifiedTestNameFor(this, qualifier);
} else {
return reportNamer.getNormalizedTestNameFor(this);
}
}
The how is the responsibility of another class
22. Encapsulate
boolean
expressions
for (TestStep currentStep : testSteps) {
if (!currentStep.isAGroup() && currentStep.getScreenshots() != null) {
for (RecordedScreenshot screenshot : currentStep.getScreenshots()) {
screenshots.add(new Screenshot(screenshot.getScreenshot().getName(),
currentStep.getDescription(),
widthOf(screenshot.getScreenshot()),
currentStep.getException()));
}
}
}
What does this boolean mean?
for (TestStep currentStep : testSteps) {
if (currentStep.needsScreenshots()) {
...
public boolean needsScreenshots() {
return (!isAGroup() && getScreenshotsAndHtmlSources() != null);
}
Expresses the intent better
23. Avoid
unclear/ambiguous
class
name
for (TestStep currentStep : testSteps) {
if (currentStep.needsScreenshots()) {
for (RecordedScreenshot screenshot : currentStep.getScreenshots()) {
screenshots.add(new Screenshot(screenshot.getScreenshot().getName(),
currentStep.getDescription(),
widthOf(screenshot.getScreenshot()),
currentStep.getException()));
}
}
}
Is this class name really accurate?
public List<Screenshot> getScreenshots() { Too many screenshots!
List<Screenshot> screenshots = new ArrayList<Screenshot>();
List<TestStep> testSteps = getFlattenedTestSteps();
for (TestStep currentStep : testSteps) {
if (weNeedAScreenshotFor(currentStep)) {
for (ScreenshotAndHtmlSource screenshotAndHtml : currentStep.getScreenshotsAndHtmlSources()) {
screenshots.add(new Screenshot(screenshotAndHtml.getScreenshotFile().getName(),
currentStep.getDescription(),
widthOf(screenshotAndHtml.getScreenshot()),
currentStep.getException()));
}
}
}
return ImmutableList.copyOf(screenshots);
Using a more revealing class name
}
And a clearer method name
24. Encapsulate
overly-‐complex
code
public List<Screenshot> getScreenshots() {
List<Screenshot> screenshots = new ArrayList<Screenshot>();
List<TestStep> testSteps = getFlattenedTestSteps();
for (TestStep currentStep : testSteps) {
if (currentStep.needsScreenshots()) {
for (ScreenshotAndHtmlSource screenshotAndHtml : currentStep.getScreenshotsAndHtmlSources()) {
screenshots.add(new Screenshot(screenshotAndHtml.getScreenshot().getName(),
currentStep.getDescription(),
widthOf(screenshotAndHtml.getScreenshot()),
currentStep.getException()));
}
}
}
return ImmutableList.copyOf(screenshots);
What does all this do?
}
public List<Screenshot> getScreenshots() {
List<Screenshot> screenshots = new ArrayList<Screenshot>();
List<TestStep> testSteps = getFlattenedTestSteps();
for (TestStep currentStep : testSteps) {
if (weNeedAScreenshotFor(currentStep)) {
screenshots.addAll(
convert(currentStep.getScreenshotsAndHtmlSources(), toScreenshotsFor(currentStep)));
}
}
}
return ImmutableList.copyOf(screenshots); Clearer intention
25. Encapsulate
overly-‐complex
code
public List<Screenshot> getScreenshots() {
List<Screenshot> screenshots = new ArrayList<Screenshot>();
List<TestStep> testSteps = getFlattenedTestSteps();
for (TestStep currentStep : testSteps) {
if (currentStep.needsScreenshots()) {
screenshots.addAll(
convert(currentStep.getScreenshotsAndHtmlSources(), toScreenshotsFor(currentStep)));
}
}
return ImmutableList.copyOf(screenshots); What we are doing
}
private Converter<ScreenshotAndHtmlSource, Screenshot> toScreenshotsFor(final TestStep currentStep) {
return new Converter<ScreenshotAndHtmlSource, Screenshot>() {
@Override
public Screenshot convert(ScreenshotAndHtmlSource from) {
return new Screenshot(from.getScreenshotFile().getName(),
currentStep.getDescription(),
widthOf(from.getScreenshotFile()),
currentStep.getException());
}
};
}
How we do it
26. Avoid
deep
nes;ng
public List<Screenshot> getScreenshots() {
List<Screenshot> screenshots = new ArrayList<Screenshot>();
List<TestStep> testSteps = getFlattenedTestSteps();
for (TestStep currentStep : testSteps) {
if (currentStep.needsScreenshots()) {
Code doing too many things
screenshots.addAll(
convert(currentStep.getScreenshotsAndHtmlSources(), toScreenshotsFor(currentStep)));
}
}
return ImmutableList.copyOf(screenshots);
} Break the code down into
public List<Screenshot> getScreenshots() { logical steps
List<Screenshot> screenshots = new ArrayList<Screenshot>();
List<TestStep> testStepsWithScreenshots = select(getFlattenedTestSteps(),
having(on(TestStep.class).needsScreenshots()));
for (TestStep currentStep : testStepsWithScreenshots) {
screenshots.addAll(convert(currentStep.getScreenshotsAndHtmlSources(),
toScreenshotsFor(currentStep)));
}
return ImmutableList.copyOf(screenshots);
} Remove the nested condition
27. Keep
each
step
simple!
public List<Screenshot> getScreenshots() {
List<Screenshot> screenshots = new ArrayList<Screenshot>();
List<TestStep> testStepsWithScreenshots = select(getFlattenedTestSteps(),
having(on(TestStep.class).needsScreenshots()));
for (TestStep currentStep : testStepsWithScreenshots) {
screenshots.addAll(convert(currentStep.getScreenshotsAndHtmlSources(),
toScreenshotsFor(currentStep)));
}
return ImmutableList.copyOf(screenshots); Too much happening here?
}
public List<Screenshot> getScreenshots() {
List<Screenshot> screenshots = new ArrayList<Screenshot>();
List<TestStep> testStepsWithScreenshots = select(getFlattenedTestSteps(),
having(on(TestStep.class).needsScreenshots()));
for (TestStep currentStep : testStepsWithScreenshots) {
screenshots.addAll(screenshotsIn(currentStep));
}
return ImmutableList.copyOf(screenshots); This reads more smoothly
}
private List<Screenshot> screenshotsIn(TestStep currentStep) {
return convert(currentStep.getScreenshotsAndHtmlSources(), toScreenshotsFor(currentStep));
}
29. Use
Fluent
APIs
Complex domain object
Lots of variants
Object tree
FundsTransferOrder order = new FundsTransferOrder();
order.setType("SWIFT");
Party originatorParty = organizationServer.findPartyByCode("WPAC");
order.setOriginatorParty(originatorParty);
Party counterParty = organizationServer.findPartyByCode("CBAA");
order.setCounterParty(counterParty);
order.setDate(DateTime.parse("22/11/2011"));
Currency currency = currencyTable.findCurrency("USD");
Amount amount = new Amount(500, currency);
order.setAmount(amount);
Complex code
...
Need to know how to create the child objects
30. Use
Fluent
APIs
More readable
No object creation
Easier to maintain
FundsTransferOrder.createNewSWIFTOrder()
.fromOriginatorParty("WPAC")
.toCounterParty("CBAA")
.forDebitor("WPAC")
.and().forCreditor("CBAA")
.settledOnThe("22/11/2011")
.forAnAmountOf(500, US_DOLLARS)
.asXML();
34. Replace
Constructors
with
Crea7on
Methods
Too many constructors
Business knowledge
hidden in the constructors
Which one should I use?
35. Replace
Constructors
with
Crea7on
Methods
Private constructor
Static creator methods
One implementing class
36. Replace
Constructors
with
Crea7on
Methods
Communicates
the
intended
use
be5er
Overcomes
technical
limits
with
constructors
Inconsistent
object
crea<on
pa5erns
37. Encapsulate
Classes
with
a
Factory
High-Level Refactoring
Only this interface should
be visible
Many different
implementations
Which implementation
should I use?
38. Encapsulate
Classes
with
a
Factory
High-Level Refactoring
Helpful factory methods
Easier
to
create
the
right
instances
Hides
classes
that
don’t
need
to
be
exposed
Encourages
“programming
to
an
interface”
Need
a
new
method
when
new
classes
are
added
Need
access
to
factory
class
to
customize/extend
39. Plenty
of
other
refactoring
pa2erns...
But
know
why
you
are
applying
them
48. lambdaj
– DSL for manipulating collections in a functional style
– Replace loops with more concise and readable code
Functional constructs in Java
49. LambdaJ support many high level
collection-related functions
filter aggregate
sort
convert
extract index group
50. Find all adult ages filter
List<Integer> adultAges = new ArrayList<Integer>();
for(int age : ages) {
if (age >= 18) {
adults.add(age);
}
}
List<Integer> adultAges = filter(greaterThanOrEqualTo(18), ages);
51. Find all adults filter
List<Person> adults = new ArrayList<Person>();
for(int person : people) {
if (person.getAge() >= 18) {
adults.add(person);
}
}
List<Person> adults = filter(having(on(Person.class).getAge(), greaterThanOrEqualTo(18)),
people);
52. Find all the sales of Ferraris filter
List<Sale> salesOfAFerrari = new ArrayList<Sale>();
for (Sale sale : sales) {
if (sale.getCar().getBrand().equals("Ferrari"))
salesOfAFerrari.add(sale);
}
List<Sale> salesOfAFerrari = select(sales,
having(on(Sale.class).getCar().getBrand(),equalTo("Ferrari")));
53. Sort sales by cost sort
List<Sale> sortedSales = new ArrayList<Sale>(sales);
Collections.sort(sortedSales, new Comparator<Sale>() {
public int compare(Sale s1, Sale s2) {
return Double.valueOf(s1.getCost()).compareTo(s2.getCost());
}
});
List<Sale> sortedSales = sort(sales, on(Sale.class).getCost());
54. Index cars by brand index
Map<String, Car> carsByBrand = new HashMap<String, Car>();
for (Car car : db.getCars()) {
carsByBrand.put(car.getBrand(), car);
}
Map<String, Car> carsByBrand = index(cars, on(Car.class).getBrand());
55. Find the total sales
aggregate
double totalSales = 0.0;
for (Sale sale : sales) {
totalSales = totalSales + sale.getCost();
}
double totalSales = sumFrom(sales).getCost();
56. Find most costly sale
aggregate
double maxCost = 0.0;
for (Sale sale : sales) {
double cost = sale.getCost();
if (cost > maxCost) maxCost = cost;
}
double maxCost = maxFrom(sales).getCost();
57. extract
Extract the costs of the cars as a list
List<Double> costs = new ArrayList<Double>();
for (Car car : cars) costs.add(car.getCost());
List<Double> costs = extract(cars, on(Car.class).getCost());