This document discusses automating a mobile development workflow using Unix philosophy and tools. It proposes building prototypes quickly, making tools that do one thing well, and avoiding proprietary IDEs. Cordova is presented as a way to work on mobile projects using Unix tools and philosophies. The document concludes by offering a demo.
Taming iOS Testing at Square -- JUC West 2015Michael Tauraso
iOS applications have unique constraints that make continuous integration and release automation difficult. We’ll be going through techniques used at Square to scale and measure the effectiveness of our iOS test cluster which is used by dozens of engineers to build a handful of applications. Testing is incredibly important to Square because our mobile applications process payments. We’ve built speedy and scalable OSX infrastructure for builds; written a configuration language for describing iOS builds that separates release code from application code; tamed the iOS simulator; and reduced the overall flakiness of our iOS tests to the 0.5% level.
Taming iOS Testing at Square -- JUC West 2015Michael Tauraso
iOS applications have unique constraints that make continuous integration and release automation difficult. We’ll be going through techniques used at Square to scale and measure the effectiveness of our iOS test cluster which is used by dozens of engineers to build a handful of applications. Testing is incredibly important to Square because our mobile applications process payments. We’ve built speedy and scalable OSX infrastructure for builds; written a configuration language for describing iOS builds that separates release code from application code; tamed the iOS simulator; and reduced the overall flakiness of our iOS tests to the 0.5% level.
The presentation talks about Linux principles and philosophy. The Unix philosophy, originated by Ken Thompson, is a set of cultural norms and philosophical approaches to developing small yet capable software based on the experience of leading developers of the Unix operating system.
Eduards Sizovs - Micro Service Architecture DevConFu
Eduards will talk about micro service architecture - approach to designing software when complex app is broken into tiny, cohesive services which are apps themselves. Anatomy of micro services will be covered with practical implementation advices in Java.
Slides de apresentação realizada no dia 27/10/2016 durante o evento QA Ninja Conf 2016.
Tópicos abordados:
- Dificuldades técnicas na implementação e execução de testes automatizados
- Mocking Test
- Exemplos no Visual Studio 2015
Writing Well-behaved Unix Utilities
A talk given at the London Ruby Users Group in October 2014. It's about what makes a good Unix utility, and how we can use Ruby to write our own.
It covers things like working as part of text processing pipelines, reading from ARGF, handling command-line arguments, and lots more.
Circuit breakers for Java: Failsafe, Javaslang-Circuitbreaker, Hystrix and Ve...Micha Kops
A demonstration of different implementations of the circuit-breaker pattern in Java to implement more resilient applications.
The following libraries are used: Failsafe, Javaslang-Circuitbreaker, Netflix Hystrix and Vert.x.
More details can be found the following blog article of mine:
http://www.hascode.com/2017/02/resilient-architecture-circuit-breakers-for-java-hystrix-vert-x-javaslang-and-failsafe-examples/
Microservice architectures have generated quite a bit of hype in recent months, and practitioners across our industry have vigorously debated the definition, purpose, and effectiveness of these architectures.
In this session, Matt Stine will cut through the Microservices hype and examine some very practical considerations:
• Not an End in Themselves: Microservices are really all about helping us achieve continuous delivery
• Systems over Services: Microservices are less about the services themselves and more about the systems we can assemble using them. Boilerplate patterns for configuration, integration, and fault tolerance are keys.
• Operationalized Architecture: Microservices aren’t a free lunch. You have to pay for them with strong DevOps sauce.
• It’s About the Data: Bounded contexts with API’s are great until you need to ask really big questions. How do we effectively wrangle all of the data at once?
Along the way, we’ll see how open source technology efforts such as Cloud Foundry, Spring Cloud, Netflix OSS, Spring XD, and Hadoop can help us with many of these considerations.
Mockito vs JMockit, battle of the mocking frameworksEndranNL
(Original keynote slides can be found at https://github.com/Endran/PublicSlides)
For years the industry standard of mocking on the JVM has been Mockito. Mockito is a wonderful library that really speeds up your testing by allowing you to create mocks in a very simple way. That being said, it does have its drawbacks, for which different strategies need to be deployed to keep your code testable. The main drawbacks are statics and finals. Final classes cannot be mocked, nor final methods, and also static methods are a no-go. To work with these type of things we need to wrap it, and copy the signature in a non final, non static way.
I have a great adversity against statics, I've devoted an entire post about it, in short; It hides dependencies and brings so little convenience at the costs of its drawbacks. Finals on the other hand have purpose, it helps messaging the goal of a class or method. Java is one of the few languages where classes and methods are open/virtual by default and have to be closed/final by explicit action. In (for example) Kotlin, everything is final by default, if you do not want something to be final, you should use the open keyword.
No matter if you follow the principle of making things final, static or not, if you are using Mockito the decision has been made. This mocking framework demands that everything is non-final, demands that everything is designed to be extended, since it might need to be mocked away. We should be able to improve upon this, and by the name of this post, you should be able to guess which framework will save the day. JMockit will help us with our impediments, and will give some other nifty benefits as well!
(ARC317) Maintaining a Resilient Front Door at Massive Scale | AWS re:Invent ...Amazon Web Services
The Netflix service supports more than 50 million subscribers in over 40 countries around the world. These subscribers use more than 1,000 different device types to connect to Netflix, resulting in massive amounts of traffic to the service. In our distributed environment, the gateway service that receives this customer traffic needs to be able to scale in a variety of ways while simultaneously protecting our subscribers from failures elsewhere in the architecture. This talk will detail how the Netflix front door operates, leveraging systems like Hystrix, Zuul, and Scryer to maximize the AWS infrastructure and to create a great streaming experience.
SCS 4120 - Software Engineering IV
BACHELOR OF SCIENCE HONOURS IN COMPUTER SCIENCE
BACHELOR OF SCIENCE HONOURS IN SOFTWARE ENGINEERING
All in One Place Lecture Notes
Distribution Among Friends Only
All copyrights belong to their respective owners
Viraj Brian Wijesuriya
vbw@ucsc.cmb.ac.lk
Microservices vs. The First Law of Distributed Objects - GOTO Nights Chicago ...Phil Calçado
TALK #2: Microservices vs. The First Law of Object Design
We've been breaking systems and application into smaller components for a long time now. From Component-Based Design to Distributed Objects to SOA to what is today's preferred golden hammer: microservices.
One definition of microservices is that it is a flavor of SOA that emphasizes many specialize services versus a few more generalist ones. Often these microservices are so small that they take care of a single "object". Distributed objects aren't new to this industry, and in 2003, Martin Fowler wrote a classic article where he discusses several problems with this model, and proposes the First Law of Distributed Objects:
"Objects have been around for a while, and sometimes it seems that ever since they were created, folks have wanted to distribute them. However, distribution of objects, or indeed of anything else, has a lot more pitfalls than many people realize, especially when they're under the influence of vendors' cozy brochures. This article is about some of these hard lessons-lessons I've seen many of my clients learn the hard way... my First Law of Distributed Object Design: Don’t distribute your objects!"
Reinventing the wheel is nothing new in our field, but if microservices are meant to be small, how can we avoid the same problems from the past? What are the technologies, architectures, protocols, and practices we need in place to make sure that our microservices architecture isn't just the largest bowl of spaghetti this organization has ever cooked?
SPEAKER: Phil Calçado, Director of Software Engineering at DigitalOcean
Phil Calçado works at DigitalOcean, where he helps build the cloud for developers. Before that, he spent four years building the team and architecture behind SoundCloud's move from a monolith to microservices. He tweets at @pcalcado writes at http://philcalcado.com.
This slide deck dives a bit in history to understand where IT comes from, where we are now and why we are there and what our options are. It starts with exploring the paradigms of the markets companies live in, travels through matching organizational approaches and finally looks at the history and current state of IT.
Based on that and after a quick look at Conway's law the market paradigms and organizational approaches are evaluated with respect to the drivers they imply on IT in general and architecture particularly.
And after all that foreplay (which is necessary to really understand where we are and what the forces are) several architectural styles and technologies are located on the scale that the market paradigms and organizational approaches span. This way sort of an "architectural fitness detector" is provided which helps to make architectural choices based on needs instead of hypes or habits (which are way to often the choice drivers).
The slide deck then finishes up with a few mismatches that are seen quite often in reality and it can be seen how the distance between architectural choices on the presented scale can be used to quickly determine potential mismatches.
As always the voice track is missing but I hope that the slides are still of some help for you.
This slide deck is about the production-readiness of software. First it explains why production-ready is more important than just feature-complete.
Then it takes a quick detour to DevOps. It explains the core ideas of DevOps and how this talks relates to the concepts of DevOps (by simulating the feedback loop from ops to dev while the wall between dev and ops still exists).
After this detour the needs of the administrators from the ops department are briefly described and the challenges that arise from that for developers who want to provide production-ready software.
Based on those challenges a selection of design principles are described (mostly in terms of topics to take care of in the design and implementation process). While not being complete by far, taking care of the topics described on these slides are a huge step towards production-ready software based on my experience.
Of course all the information from the voice track is missing, it is slides only. Even though the slides just carry a fraction of the information, I hope they will still contain some good pointers for you that help you to create better production-ready software.
Designing, building, testing and deploying microservices. A stairway to heave...Codemotion
Microservices are the next hype. Websites are full of introducing posts, books are being written and conferences organized. There’s big promises of scalability and flexibility. However, when you are knee deep in mud as an architect, developer or tester, it’s hard to find out how to get there. Sander Hoogendoorn, independent craftsman and CTO of Klaverblad Insurances, discusses the long and winding road his projects, greenfield and brownfield, have travelled. Sander will e.g. address polyglot persistence, DDD, bounded contexts, modelling HTTP/REST, continuous delivery and many lessons learned.
Thirty months of microservices. Stairway to heaven or highway to hell? - Sand...Codemotion
Microservices are the next hype. Websites are full of introducing posts, books are being written and conferences organized. There’s big promises of scalability and flexibility. However, when you are knee deep in mud as an architect, developer or tester, it’s hard to find out how to get there. Sander Hoogendoorn, independent craftsman and CTO of Klaverblad Insurances, discusses the long and winding road his projects, greenfield and brownfield, have travelled. Sander will e.g. address polyglot persistence, DDD, bounded contexts, modeling HTTP/REST, continuous delivery and many lessons learned.
The presentation talks about Linux principles and philosophy. The Unix philosophy, originated by Ken Thompson, is a set of cultural norms and philosophical approaches to developing small yet capable software based on the experience of leading developers of the Unix operating system.
Eduards Sizovs - Micro Service Architecture DevConFu
Eduards will talk about micro service architecture - approach to designing software when complex app is broken into tiny, cohesive services which are apps themselves. Anatomy of micro services will be covered with practical implementation advices in Java.
Slides de apresentação realizada no dia 27/10/2016 durante o evento QA Ninja Conf 2016.
Tópicos abordados:
- Dificuldades técnicas na implementação e execução de testes automatizados
- Mocking Test
- Exemplos no Visual Studio 2015
Writing Well-behaved Unix Utilities
A talk given at the London Ruby Users Group in October 2014. It's about what makes a good Unix utility, and how we can use Ruby to write our own.
It covers things like working as part of text processing pipelines, reading from ARGF, handling command-line arguments, and lots more.
Circuit breakers for Java: Failsafe, Javaslang-Circuitbreaker, Hystrix and Ve...Micha Kops
A demonstration of different implementations of the circuit-breaker pattern in Java to implement more resilient applications.
The following libraries are used: Failsafe, Javaslang-Circuitbreaker, Netflix Hystrix and Vert.x.
More details can be found the following blog article of mine:
http://www.hascode.com/2017/02/resilient-architecture-circuit-breakers-for-java-hystrix-vert-x-javaslang-and-failsafe-examples/
Microservice architectures have generated quite a bit of hype in recent months, and practitioners across our industry have vigorously debated the definition, purpose, and effectiveness of these architectures.
In this session, Matt Stine will cut through the Microservices hype and examine some very practical considerations:
• Not an End in Themselves: Microservices are really all about helping us achieve continuous delivery
• Systems over Services: Microservices are less about the services themselves and more about the systems we can assemble using them. Boilerplate patterns for configuration, integration, and fault tolerance are keys.
• Operationalized Architecture: Microservices aren’t a free lunch. You have to pay for them with strong DevOps sauce.
• It’s About the Data: Bounded contexts with API’s are great until you need to ask really big questions. How do we effectively wrangle all of the data at once?
Along the way, we’ll see how open source technology efforts such as Cloud Foundry, Spring Cloud, Netflix OSS, Spring XD, and Hadoop can help us with many of these considerations.
Mockito vs JMockit, battle of the mocking frameworksEndranNL
(Original keynote slides can be found at https://github.com/Endran/PublicSlides)
For years the industry standard of mocking on the JVM has been Mockito. Mockito is a wonderful library that really speeds up your testing by allowing you to create mocks in a very simple way. That being said, it does have its drawbacks, for which different strategies need to be deployed to keep your code testable. The main drawbacks are statics and finals. Final classes cannot be mocked, nor final methods, and also static methods are a no-go. To work with these type of things we need to wrap it, and copy the signature in a non final, non static way.
I have a great adversity against statics, I've devoted an entire post about it, in short; It hides dependencies and brings so little convenience at the costs of its drawbacks. Finals on the other hand have purpose, it helps messaging the goal of a class or method. Java is one of the few languages where classes and methods are open/virtual by default and have to be closed/final by explicit action. In (for example) Kotlin, everything is final by default, if you do not want something to be final, you should use the open keyword.
No matter if you follow the principle of making things final, static or not, if you are using Mockito the decision has been made. This mocking framework demands that everything is non-final, demands that everything is designed to be extended, since it might need to be mocked away. We should be able to improve upon this, and by the name of this post, you should be able to guess which framework will save the day. JMockit will help us with our impediments, and will give some other nifty benefits as well!
(ARC317) Maintaining a Resilient Front Door at Massive Scale | AWS re:Invent ...Amazon Web Services
The Netflix service supports more than 50 million subscribers in over 40 countries around the world. These subscribers use more than 1,000 different device types to connect to Netflix, resulting in massive amounts of traffic to the service. In our distributed environment, the gateway service that receives this customer traffic needs to be able to scale in a variety of ways while simultaneously protecting our subscribers from failures elsewhere in the architecture. This talk will detail how the Netflix front door operates, leveraging systems like Hystrix, Zuul, and Scryer to maximize the AWS infrastructure and to create a great streaming experience.
SCS 4120 - Software Engineering IV
BACHELOR OF SCIENCE HONOURS IN COMPUTER SCIENCE
BACHELOR OF SCIENCE HONOURS IN SOFTWARE ENGINEERING
All in One Place Lecture Notes
Distribution Among Friends Only
All copyrights belong to their respective owners
Viraj Brian Wijesuriya
vbw@ucsc.cmb.ac.lk
Microservices vs. The First Law of Distributed Objects - GOTO Nights Chicago ...Phil Calçado
TALK #2: Microservices vs. The First Law of Object Design
We've been breaking systems and application into smaller components for a long time now. From Component-Based Design to Distributed Objects to SOA to what is today's preferred golden hammer: microservices.
One definition of microservices is that it is a flavor of SOA that emphasizes many specialize services versus a few more generalist ones. Often these microservices are so small that they take care of a single "object". Distributed objects aren't new to this industry, and in 2003, Martin Fowler wrote a classic article where he discusses several problems with this model, and proposes the First Law of Distributed Objects:
"Objects have been around for a while, and sometimes it seems that ever since they were created, folks have wanted to distribute them. However, distribution of objects, or indeed of anything else, has a lot more pitfalls than many people realize, especially when they're under the influence of vendors' cozy brochures. This article is about some of these hard lessons-lessons I've seen many of my clients learn the hard way... my First Law of Distributed Object Design: Don’t distribute your objects!"
Reinventing the wheel is nothing new in our field, but if microservices are meant to be small, how can we avoid the same problems from the past? What are the technologies, architectures, protocols, and practices we need in place to make sure that our microservices architecture isn't just the largest bowl of spaghetti this organization has ever cooked?
SPEAKER: Phil Calçado, Director of Software Engineering at DigitalOcean
Phil Calçado works at DigitalOcean, where he helps build the cloud for developers. Before that, he spent four years building the team and architecture behind SoundCloud's move from a monolith to microservices. He tweets at @pcalcado writes at http://philcalcado.com.
This slide deck dives a bit in history to understand where IT comes from, where we are now and why we are there and what our options are. It starts with exploring the paradigms of the markets companies live in, travels through matching organizational approaches and finally looks at the history and current state of IT.
Based on that and after a quick look at Conway's law the market paradigms and organizational approaches are evaluated with respect to the drivers they imply on IT in general and architecture particularly.
And after all that foreplay (which is necessary to really understand where we are and what the forces are) several architectural styles and technologies are located on the scale that the market paradigms and organizational approaches span. This way sort of an "architectural fitness detector" is provided which helps to make architectural choices based on needs instead of hypes or habits (which are way to often the choice drivers).
The slide deck then finishes up with a few mismatches that are seen quite often in reality and it can be seen how the distance between architectural choices on the presented scale can be used to quickly determine potential mismatches.
As always the voice track is missing but I hope that the slides are still of some help for you.
This slide deck is about the production-readiness of software. First it explains why production-ready is more important than just feature-complete.
Then it takes a quick detour to DevOps. It explains the core ideas of DevOps and how this talks relates to the concepts of DevOps (by simulating the feedback loop from ops to dev while the wall between dev and ops still exists).
After this detour the needs of the administrators from the ops department are briefly described and the challenges that arise from that for developers who want to provide production-ready software.
Based on those challenges a selection of design principles are described (mostly in terms of topics to take care of in the design and implementation process). While not being complete by far, taking care of the topics described on these slides are a huge step towards production-ready software based on my experience.
Of course all the information from the voice track is missing, it is slides only. Even though the slides just carry a fraction of the information, I hope they will still contain some good pointers for you that help you to create better production-ready software.
Designing, building, testing and deploying microservices. A stairway to heave...Codemotion
Microservices are the next hype. Websites are full of introducing posts, books are being written and conferences organized. There’s big promises of scalability and flexibility. However, when you are knee deep in mud as an architect, developer or tester, it’s hard to find out how to get there. Sander Hoogendoorn, independent craftsman and CTO of Klaverblad Insurances, discusses the long and winding road his projects, greenfield and brownfield, have travelled. Sander will e.g. address polyglot persistence, DDD, bounded contexts, modelling HTTP/REST, continuous delivery and many lessons learned.
Thirty months of microservices. Stairway to heaven or highway to hell? - Sand...Codemotion
Microservices are the next hype. Websites are full of introducing posts, books are being written and conferences organized. There’s big promises of scalability and flexibility. However, when you are knee deep in mud as an architect, developer or tester, it’s hard to find out how to get there. Sander Hoogendoorn, independent craftsman and CTO of Klaverblad Insurances, discusses the long and winding road his projects, greenfield and brownfield, have travelled. Sander will e.g. address polyglot persistence, DDD, bounded contexts, modeling HTTP/REST, continuous delivery and many lessons learned.
I gave this talk on IEEE Day (October 7, 2014). I covered Introduction to Open Source, Various Projects and Products in Open Source, What students can get from Open Source and various different aspects of Open Source during this talk.
Please feel free to download, modify and use the slides for your talks. Lets keep rocking the Free Web ! :)
Presentation mainly deals with Open Source and how Os projects work? Who does it? Why they do it? Why you should contribute to Open Source? Different ways of contribution.
The Fourth International Workshop on RESTful Design, WS-REST 2013
REST in Brazil - Industry Keynote
On learning REST, and its impact on the design of massive applications in Brazil
Talk from IoT World in Santa Clara, May 12, 2016. How to make IoT objects interoperable and adapble by adding JavaScript. Introduces XS6 open source JavaScript engine optimized for embedded development. Hat tip to Hallelujah the Hills for the epigrams.
Similar to Mobile Knife Fighting at JSConf US (20)
Generating a custom Ruby SDK for your web service or Rails API using Smithyg2nightmarescribd
Have you ever wanted a Ruby client API to communicate with your web service? Smithy is a protocol-agnostic language for defining services and SDKs. Smithy Ruby is an implementation of Smithy that generates a Ruby SDK using a Smithy model. In this talk, we will explore Smithy and Smithy Ruby to learn how to generate custom feature-rich SDKs that can communicate with any web service, such as a Rails JSON API.
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
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!
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.
Neuro-symbolic is not enough, we need neuro-*semantic*Frank van Harmelen
Neuro-symbolic (NeSy) AI is on the rise. However, simply machine learning on just any symbolic structure is not sufficient to really harvest the gains of NeSy. These will only be gained when the symbolic structures have an actual semantics. I give an operational definition of semantics as “predictable inference”.
All of this illustrated with link prediction over knowledge graphs, but the argument is general.
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/
Smart TV Buyer Insights Survey 2024 by 91mobiles.pdf91mobiles
91mobiles recently conducted a Smart TV Buyer Insights Survey in which we asked over 3,000 respondents about the TV they own, aspects they look at on a new TV, and their TV buying preferences.
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
Accelerate your Kubernetes clusters with Varnish CachingThijs Feryn
A presentation about the usage and availability of Varnish on Kubernetes. This talk explores the capabilities of Varnish caching and shows how to use the Varnish Helm chart to deploy it to Kubernetes.
This presentation was delivered at K8SUG Singapore. See https://feryn.eu/presentations/accelerate-your-kubernetes-clusters-with-varnish-caching-k8sug-singapore-28-2024 for more details.
Securing your Kubernetes cluster_ a step-by-step guide to success !KatiaHIMEUR1
Today, after several years of existence, an extremely active community and an ultra-dynamic ecosystem, Kubernetes has established itself as the de facto standard in container orchestration. Thanks to a wide range of managed services, it has never been so easy to set up a ready-to-use Kubernetes cluster.
However, this ease of use means that the subject of security in Kubernetes is often left for later, or even neglected. This exposes companies to significant risks.
In this talk, I'll show you step-by-step how to secure your Kubernetes cluster for greater peace of mind and reliability.
Encryption in Microsoft 365 - ExpertsLive Netherlands 2024Albert Hoitingh
In this session I delve into the encryption technology used in Microsoft 365 and Microsoft Purview. Including the concepts of Customer Key and Double Key Encryption.
8. Unix Philosophy 101
• small well defined tools
• stdin stdout stderr
• ‘pipable’ (think cmd line chaining)
• works with text
• worse is better
9. More Unix Philosophy
• Small is beautiful.
• Make each program do one thing well.
• Build a prototype as soon as possible.
• Choose portability over efficiency.
• Store data in flat text files.
• Use software leverage to your advantage.
• Use shell scripts to increase leverage and portability.
• Avoid captive user interfaces.
• Make every program a filter.
11. problem space
• ios build chain requires a bullshit ide
• android is fairly open, baffling tho
• webos tools are fantastic
• blackberry, bada, wp7 and others are
windows based...
14. Cordova
• unix tools philosophy for mobile project
• works on os x
• likely works on *nix
• apparently can work on windows [see 1]
1.) I don’t care
15. what are we automating?
• create
• build
• debug
• test
• release
• logging
• emulation
20. better
• the ide protects you from bugs
• the ide is a leaky abstraction
• the ide gets you closer to the platform
• the ide locks you into the platform
• the ide has step debugging
• write fucking unit tests for chrissakes