text:
JBaruch 🎩 for JFrog
[DevOps Speakeasy Podcast S01E01] Interview with Ant Weiss
#podcast #devops
This is a transcription of a video podcast episode. Watch it on YouTube, listen to it in your podcast app.
In the first-ever episode of the DevOps Speakeasy podcast, we interviewed Anton Weis on DevOps consultancy. These JFrog podcasts are designed specifically to deliver the latest and greatest in DevOps practices while talking with industry experts who share their technological experiences and provide insight into simplifying your organization's operations.
Baruch:
Welcome to the first episode of our DevOps Speakeasy podcast. We have an amazing guest Anton Weiss, an international DevOps Rockstar and a speaker at many conferences including our very own Yalla DevOps. We're going to get to Anton very soon. A couple of words about the Speakeasy and the podcast format. DevOps Speakeasy was born a half a year ago, as a set of interviews that we do with speakers and celebs in the DevOps world. Usually, the interviews are recorded live at conferences where we just grab people on the show floor or find a conference room and just interview them for a very short (8-10 minutes) about one topic.
Even though no one is going to conferences anymore, we still want to speak with awesome people, so we decided to retrofit this format into a podcast because as you know, everybody is podcasting and no one is podlistening, including us. It means not face to face, but in our virtual studios with a longer format. We aim for an hour-long episode, so we have plenty of time to discuss all kinds of things and go into all kinds of topics and we'll see how it goes.
We'll probably have our share of five followers including Anton's mom and a couple of more, but we hope it will be interesting for you. It's for sure going to be interesting for us. Today we have the amazing Kat Cosgrove, a developer advocate at JFrog is here with us. And myself, I'm Baruch Sadogursky, Head of DevOps advocacy at JFrog. And as I mentioned Anton Weiss. So let's get to it. Who are you, Anton?
Anton:
Wow, that's a philosophical question. Well, so who am I? I'm a human being. For the last 30 years, I've been living in Israel and before that, I was born and brought up in Russia. For the last 20 years, and that's what's relevant for the topic of this podcast, I've been dealing with information technology. I started out as a developer writing code in C and C++. Then moved on to a number of different integrations, whatever they were called positions. With time, the things that I was doing started being called configuration management.
And then at a certain point, Patrick Debois invented a new wonderful word, DevOps. Since then that's what I'm all about. For the last four years, I've been doing this for myself, actually doing it for my customers, for my clients. So I'm the head and founder of a boutique consulting company called Otomato Software, where what we do is we help our clients, large enterprise companies and small startups to make DevOps easier. So DevOps Speakeasy makes DevOps easy.
Exactly. And speakeasy about it. With DevOps consulting, I tried to get my head around it. How does it look? What is it about? So how does it work? You come to the company and then you do what? Do you bring DevOps engineers with you?
That's the first thing I do. I come to them and I say, "You shouldn't have any DevOps engineers." And then I take a couple of 1000s bucks and I'm out of the door. So basically that's DevOps Consulting.
So great, are you hiring?
Well, this is hard to sell. Don't be mistaken. I never called this DevOps consulting even though the word DevOps is all around me and I pronounce it many times a day. But still what I do, what I like to say I do, is software delivery optimization.
Organizations create software. They want to make this software usable by their users, so we need to deliver software and they have some hardships on the way. That's where I see our expertise is. To understand where the roadblocks are, where the bottlenecks are, to analyze the whole process and help find the ways to make this thing easier, faster, more fun.
This includes, of course, all of the components; the processes, the tools, the people and the information. We always talk about people, process, tools. We don't talk enough about the flow of information around this thing because it's also not less important. Sometimes even more important because the information is what flows through the pipeline.
But that's super broad. I mean software delivery optimization is everything. Starting with picking up the right programming language, and having good developers, and using the right design patterns, it is the stuff that we almost never associate with DevOps. I think saying, "I'm here to optimize your software delivery, saying I'm here to make your life better. Your coffee brand is wrong." It's everything. But people want tangible goals because they want tangible results and they want to hold you accountable. So how do you even go about it?
Well generally, consulting is a tricky business. So yeah, you assume your customers want tangible results. They don't always do because they have their consulting budget and they are accountable for those budgets. And if you don't deliver the results, then they're accountable to their managers. So sometimes, yeah. They do expect the results, but they don't really want to measure it because if for some reason you don't have the results and the results the consultant gets are not always dependent on the consultant, him or herself.
Because a consultant can only recommend things, a consultant can coach, a consultant can mentor, but in the end, the implementation of the consultant's recommendations is on the part of the client.
That would never fly with our boss, that I can tell you right now. You need to find very specific people that don't care about the results or holding you accountable.
Well, what I'm trying to say is that many people say they want to see tangible results. But when the topic of my talk at Yalla DevOps and many other talks that I delivered in the last couple of years was about how do we measure the results of DevOps. How do we measure the return on investment from DevOps? And the thing I see time after time that there are very few organizations really investing effort in this. So when we do DevOps, we actually want to achieve two things: We want to deliver software faster and with better quality.
You would go faster but things are always broken that we haven't done anything. And if we're achieving good quality, but we can't keep up with the market demand then again, the DevOps isn't working. So we need to be measuring across both speed and quality or as they are also called, "Velocity" and "Stability". How do they call it in the Accelerate book?
Lead time, deployment frequency, failure rate and mean time to recovery.
Right. Okay. So there are four very simple measures. How many organizations out there are actually measuring this?
Well, those to which Nicole Forsgren comes and ask those questions, then I think they start caring about it.
Probably. My guess again is what is the State of DevOps Report based upon? It's based upon self-reporting surveys right? So the question is are they based on data? My guess would be that most people providing answers to the server are saying, "Well it's more or less this." They don't have a penny to that because collecting this data is an investment.
And we don't see organizations really, really investing in doing this because we're very, very busy fixing the deployments. Or we're very busy replacing our current infrastructure with Kubernetes or we're very busy hiring DevOps engineers because they're so hard to find. Because they don't exist. It's very hard to find something that doesn't exist.
I know we got a whole TV show about finding something that doesn't exist. There's a seven season-long show about finding bigfoot. Haven't found him yet. Seven seasons though.
Yeah. The truth is out there. That's another very long-running TV show about finding stuff that might exist. So, you know what? I'm worried now because what you are saying is that everything is smoke and mirrors. There are no actual measurements, there are no actual results.
You come to people, and excuse me, bullshitting them and they buy your bullshit and then no one measures anything. And I'm happy for you. You get their money, everybody is happy. But seriously, I personally thought that it's a serious engineering discipline that we are serious people that deal with data, with numbers, argue with data, measure stuff and have tangible results. What I hear is that none of that is true. You've got me worried. Now you need to calm me down. Seriously, let's talk about it. What you are saying is no one is measuring anything and no one knows what they're doing and the improvement is basically the feeling that we have better about them ourselves.
Now, that was actually the first part of the show, when I get everybody pissed off with me.
No, I'm not saying that nobody measures anything. I'm saying what I see is that, well, again, I'm biased, because when I get called in, I'm usually called in where organizations are in pain. Because if you're not in pain, you usually don't call a consultant. Until the virus breaks out you're saying, "Okay, we can handle this ourselves."
Yeah. I used to work in the data backup industry and that's something we saw consistently there too, that nobody cared about having backups. Businesses didn't care until they got hit with a CryptoLocker virus and they're just utterly screwed. And there's some overlap there, with DevOps now that we've got DevSecOps as a thing. Worrying about security from the very beginning.
Okay, I hear you. So people come to you when they think they are in pain and you sell them this smoke and mirrors that you will be fine.
No, that's not what I'm selling. What I'm saying is I'm providing measurable results. Here is what you need to have in place in order to measure this and here is what we are going to do. An assessment process that we've been doing for the last three, four years with different organizations.
So we sit down with all the players of this delivery game. The developers, the operations, the testers, the project managers, product managers, whoever is in this game, whoever's providing requirements, whoever is implementing requirements, whoever is building the infrastructure, et cetera, et cetera, et cetera.
And even from the very basic mapping, you can realize there are certain bottlenecks. There is the low hanging fruit that everybody knows is there. And many times when I come to an organization, they already know where the pain is. Even though sometimes when we sit down and talk to everybody, we'll find out that's not the real pain.
They say, "Our build takes three hours," but then you sit down with them and you realize it takes them a week to approve a version so you say maybe the three-hour build is not your biggest bottleneck, so after the assessment, we more or less know what we're going to do.
I cannot promise how much better the organization will become because it's a process of continuous improvement. But the first thing that I'm saying is, we need to start measuring this. And they're saying "it's very hard to measure. How do we know when our lead time ends because we have commits at the beginning of the release?" We're still not doing continuous delivery! BTW most organization out there are not doing continuous delivery. So they're saying, "We're not doing continuous delivery yet, so how do we count the lead time? Is this from the time the commit has been pushed until the time the release is out there? Or until the time we roll this out to the staging environment? Or until the time, whatever, a bug has been found?"
So we need to define these things. It's quite okay if each organization defines them differently because the important thing is you start measuring. You define the start point and the end point. And then you can say, "Okay, this the whole thing." And if the whole thing is not getting faster, probably, I'm not optimizing at the right point. Then you start searching for the actual bottlenecks because as the theory of constraints teaches us, optimizing anywhere but not at the bottleneck, is not optimizing anything at all. So that would be the correct approach.
This is how it works in a perfect world. This requires a lot of discipline, this requires not panicking, and this requires you not to be in too much pain. But I said, most of the companies that I start to work with are already in pain. So first of all, they need a cure for the pain. So they would say, "Our production is crashing all the time. We have critical alerts five times a week." So then we say, "I don't care how long your lead time is. The first thing you need to do is to take an aspirin." Let's just sort out your alerts. Let's put all of the focus on your production alerts, let's wake up everybody when an alert occurs, and let's make sure that we're reducing these alerts.
At one company that we worked with, we've created something that we call the pain board. They had a very unstable environment and things were always crashing. Things were crashing because of the same issues that never were fixed because they didn't have the focus in order to fix this. So we started putting them on a board on a large monitor for everyone to see. And we started having daily meetings where we would look at the board and say, "This issue has been coming back for 50 times around. So we need to take care of this first of all because we don't want it coming back anymore." When you work in this way, slowly but surely, you start reducing the amount of issues. You start reducing the noise, you start reducing the pain, and then you can start focusing on the actual delivery problem.
Okay. So the first stage is kind of firefighting mode when you just fix the obvious problems which are obvious for everybody. No need to do any sophisticated analysis and what's not. Every deployment that we do fails, so let's fix that.
Back to the bottlenecks, I wonder if you can name one the biggest bottleneck that you see in the majority of your customers or the organizations you speak with. Or maybe not one, maybe a couple, but the biggest pains that you see.
Well, that's pretty easy. There was this talk that I was supposed to deliver at DevOops, the subject of the talk was DevOps Hero's Journey. So I was taking the hero's journey by
Joseph Campbell. What he did was study the myths of different countries and different people. Things like a story of the myth of Buddha, the myth of Jesus, the myth of Muhammad, whatever. He was saying all of these stories, all of these myths, they follow the a monomyth pattern, they're all the same myth, but some of them have a bit more steps, some of them have some steps missing, but the overall pattern is the same. So you could actually break them all down into the same pattern. The same thing happens in implementing DevOps practices.
Just before we jump into implementing, credit where credit is due. So Joseph Campbell, the book that we all learned from is called The Hero with a Thousand Faces. It's 70 years old, but still super relevant. This is where the theory of the monomyth is laid down. So what you are saying is the DevOps Hero Journey is feeding into this monomyth theory and it's the same journey like the journey of Jesus for that matter.
Sure. So it's a journey to a better life through hardships and the challenges that you see on the way. But when I started to think about what the journey was, I realized that there is always this stage where you realize that no matter how many things you automate, no matter how many tools you replace, at a certain point you start realizing that our biggest bottleneck is human deliberation, human communication.
Well, that's where DevOps started. Let's take the original talk by John Allspaw and Paul Hammond, which actually caused Patrick Debois to invent DevOps. It was about how did they manage to deploy 10 times a day at Flickr. Because their Devs started thinking a bit more like Ops and their Ops started thinking a bit more like Devs. So it was all about a change of thinking, it was all about a change of mindset. Nobody was talking about Kubernetes, excuse my French, at that time.
You completely ditched my question because saying that the problem of everybody is collaboration, is like saying, well, the problem is everybody are humans. While this is true, it's kind so broad that it's not really actionable. Let me ask you again, to the actionable, maybe even technology-related, what are the bigger bottlenecks that you see? For example, you mentioned that the majority of the companies don't do continuous delivery, is that one of them or there are others, or maybe that's not the biggest problem at all?
Technology-related. Well, the biggest problem, technology-related is, of course, managing complexity.
The scale that we work at today in large organizations especially causes so much complexity that it's really very, very hard to manage this, conceptually and technologically. So it's very easy to build a pipeline for one monolith service while it's still small and it has a small number of dependencies. And when we have one, two, maybe three teams, that's easy. The moment we need to manage a couple of dozen microservices with a couple of dozen teams, that becomes hard because even with the tooling that we're building today, we're not resolving the conceptual understanding of this. So the tooling is there, take Kubernetes for example. Kubernetes is a great tool, but in order to manage this complexity, the tool itself has to be complex. Then we as humans find ourselves limited in our ability to manage it.
Kubernetes is really hard. The learning curve is steep there.
Exactly. So this is a technological challenge as well as it is a management challenge because the engineers are dealing with complicated large scale technology that is very complex. That is complex for them to grasp. Nobody has the whole picture. One of the latest projects we're building is a continuous delivery pipeline for data science. So there are those ETL workflows that are running on Airflow. Then we need to understand how to continuously deliver these Airflow dags (directed acyclic graphs) to the production environment. Do we use Airflow itself? Do we use Jenkins? How do these tools interact? None of the continuous delivery engineers understand the complexity that's involved with ETL processes. None of the ETL engineers understand how continuous delivery is done. So how do we make these things work together? No answers, very hard. Now take a manager that tries to make these two teams work together. What does that manager tell them? How does that manager allow them to work together? That's complex.
So it's still a people problem, not strictly a technology problem?
Yes. Well, technology is still undeveloped where the scaling things might be faster than the tooling is developing. As an example, I was thinking about this, there are some pieces of technology that really astonish me. For example, take the automatic suggestions from Google. When you type messages today there are automated suggestions. You can actually see how it's getting smarter every day somehow, whereas two years ago it was really, really stupid.
It was. Another example is the Twitter flashmob that go around where you start a sentence with something predefined like, "I'm quitting tech because ..." and then you let the autocomplete finish it for you. It's turning out some stuff, it's like actual sentences. One of my friends got, "I'm quitting tech to become an artist." Jeez, I know people who have actually done that. That's a real thing.
So what we really need is our delivery, deployment technology to be like that. If I've built a deploy and it's not going to be deployed, the system should be suggesting this to me. Saying, "This, when you roll it out to production is going to be broken." So maybe what you really meant was saying, "I want this to be, I don't know, highly available." You're saying you want a blob storage but actually you're probably meaning to use S3.
We want tooltips. I don't want my deployments to do everything for me because that level of leaving certain security concerns or networking concerns up to an automated wizard makes me a little bit uncomfortable. That's pretty consistently exploitable eventually. But tooltips would be nice. Like, "Hey, are you sure that you really want to do it that way? Because this might be less than ideal." I think some tooling is doing that now. Right? Don't we have configs and patches on the platform?
I think a lot of ChatOps is kind of doing that. One of the examples is Automist. They're giving you hints of what might be wrong and then a very simple way to actually fix it with one pre-canned answer.
A linker for your Ops.
The industry has been moving in that direction. There's also a startup here in Tel Aviv that I've recently been talking to. We're thinking in that direction the incident response. Like they're saying we can find certain patterns in how we fix certain problems or how we debug certain problems.
So what we need is an AI overlord. That's where we're moving towards.
It's not even artificial intelligence, it's more like, machine learning probably. Not a system that thinks for itself, but a system that at least takes into account whatever we humans know.
Baruch, would the ML that handles a fictional system like this, can it be the DevOps engineer?
Oh, that's a good question. It's all about the collaboration again. Why I don't believe that DevOps engineer is a real job because DevOps is about collaboration. Having DevOps engineers doing DevOps all day, it's like having collaboration engineers doing collaboration all day. I mean it doesn't make sense, and this is why we have the empowered teams and the T shaped people who actually know a lot about one topic and a little bit about everything else.
The machine-learned artificial intelligence that we are talking about is probably capable of being an O-shaped engineer and knowing everything about everything. But until we get there, we still need people who specialize in different things and none of it is DevOps as a technical discipline.
Anton, I wanted to get back to what you said about complexity. Because I'm trying to figure out, you as a consultant, you saw it all, you've been through it all. How do you advise people to go around complexity? Because I think there are two scenarios. The one is unnecessary complexity. People just got in love with some architectures invented in the ivory towers and bringing that upon themselves when they don't need it.
That's a sore spot for me. I hate it when people do that.
But the good news is that it's fixable. All you can say is, okay, you throw it all away, you start easy, you start small, you start with your manageable small or monolith and go from there. But I mean, it not easy, but you know how to go about it and the solution is walking away from the complexity. I think the more dreadful scenario is when you cannot walk away from the complexity. When complexity is a necessity as a part of your business requirements or the business situation you're in, what are you doing then?
That's a big question.
You do your best at managing complexity. It may sound a little bit vague, but as a systems thinker, (I like to call myself systems thinker because it sounds so very fancy) I was taught by wonderful folks, for example, Dr. Russell Ackoff, that the complexity doesn't lie in the competence of the system. If we break down the system into a lot of components and make each component simpler. The system as a whole one becomes simpler because the complexity lies in the interaction between components.
So managing complexity basically is managing the interaction between components. Well, I think the first thing you should do is somehow try to outline all the possible interaction between the components in your system and throw the necessary effort at managing these interactions. That's actually what we're trying to do today with the technology that I'm a little bit in love with. That would be service meshes.
All right, that's a very nice segue. I'm loving it. Let's switch gears and talk a little bit about technology. That was a lot about methodology and whatnot. Let's talk about the hardcore stuff. Meshes as an answer for complexity problems. Talk to us.
Well, basically, as I said, the best way to manage complexity is by managing the interactions between components not by making components simpler. We'll let the competence be as complex as they need be and we actually let the interactions be as complex as they need be. But we need to make these interactions understandable, manageable, and for that, we need another buzzword. Observability of those interactions. That's one of the things that service meshes allow having more or less out of the box.
For people who are watching this, who might not be super familiar with the space, can you just go over what a service mesh actually is and what it might look like?
Okay, a very short introduction into service meshes without diagrams. That's actually something that's a little bit hard to grasp without any diagram.
Microservices or any complex distributed system that we might've built cause us macro pain. Because there's a lot of complexity to manage. Our services keep talking to each other and some services that we talk to don't reply in a timely manner. Some services are for some reason not available. Or other services don't provide responses that we expect them to provide.
Sure, it looks like the microservice version of spaghetti code.
Yes. More or less that's what any complex system grows into with time. Now in order to manage all of these challenges, a number of techniques were developed over time in order to manage all the challenges of distributed systems. Like in spaghetti code right here, you have the issues of the spaghetti code of the interaction between the components. But when you start running a microservice system, there is another very important component of the system. That's the network because, in a microservice system, all our components are interacting with each other over the network right?
Sure, yeah.
This network is unreliable. This network can be slow. This network can, for some reason, reject the protocols that we want to talk over this network with. In order to manage all this complexity and a lack of reliability with time, we've developed a number of patterns, things like connection pools in order to have enough connections whenever we need them. All kinds of failure detectors, failover strategies, things like circuit breaking, a balk hitting, exponential back-offs. The load balancers, of course, back pressure techniques such as the rate-limiting, et cetera.
Up until now, we've had a number of companies that would allow us to manage this, but many of those concerns were still managed in the code by the developers. But many of these can be seen as actually operational concerns. This disconnect between developers implementing operational concerns, but then the operators stumbling upon them, it was causing us a lot of issues. That's why in 2016 the folks at a company called Buoyant have created a system called linkerd (which was actually the first-ever service Mesh the world knew). Their creation of this component was based on their experience at Twitter. Twitter is famous for the libraries that they've built specifically for dealing with these issues. Things like Finagle. They took that experience from Twitter and they built it out in a separate component saying we don't want each developer to start integrating with this library. Because managing libraries is also painful.
Let's manage all of this auto process. Let's build a mesh of smart proxies that will be residing next to each one of our services. We'll be able to manage all of these proxies from a centralized location. In this way, we can provide a central solution to all of these distributed system reliability issues and concerns. That's basically what a service mesh is about. Now, the concept has developed largely thanks to Istio. The market leader in implementing the service mesh concept, the service mesh pattern today that was developed by Google in collaboration with Lyft and IBM.
That's basically how it works. Besides Istio, we also have Linkerd. We also have Console Connect right now. Now, what all of them basically do is they put smart proxies next to our services and provide us with a control plane that allows us to manage how these proxies are configured. We can configure them to define all these reliability techniques. To define which traffic is allowed. To define how the traffic is managed. That allows us also to provide security barriers for network communication between services. And that also allows us observability because through that control plane we can also pull data from all these proxies to understand what our services are chatting about.
We're basically externalizing network communication and this allows us to see what's going on and to control what should speak with what.
It's an abstraction layer on top of your distributed systems so that it seems saner. It's more human-readable instead of just being machine-readable.
For the folks who are running Kubernetes, and today basically in 90% of cases, you deploy a service mesh over Kubernetes. On Kubernetes the data plane, the proxies are actually side cards that are injected into each one of your pods. The control plane are components that run somewhere in the cluster and allow to pull data from these proxies and to configure them
Because it's just too much in my opinion, to expect that like every engineer ever is a Kubernetes expert or an expert in any other DevOps tool. You should be an expert in your thing, but you can't also be an expert at Kubernetes. You need something there to make that information still accessible and useful to you. But you don't necessarily need to know how to dive into the cluster and look at each microservice individually and figure out what's wrong with that network.
Right. By the way, coming back to what we talked about earlier, there are also tools for the leading service meshes today that allow you to analyze the configuration on the service mesh and to find possible misconfigurations. Because again, let's say I have a hundred services, they're all communicating with one another. I need to define the security roles for this communication. Who is allowed to talk to whom and what kind of traffic is allowed and whatever. Something's misconfigured, very hard to understand, so we need some smarts in the system that will tell us this is where your problem is.
Yeah, because a computer or a system or an application is only as smart as the person who built it or the person who programmed it. But computers and applications and systems like that don't get tired. They don't get bored and they don't get distracted and people do. So it's easier for us to make mistakes on repetitive things like security settings for a thousand different microservices. Because we get bored or distracted.
In general. It's very easy for us to make mistakes.
Yeah. Okay, so I'm trying to picture this flow diagram for DevOps consultancy and I think I got a grip on it. So basically there are two types of complexity: a necessary one and a not necessary one. And for non-necessary, obviously, you try to convince people to simplify things, to simplify architectures, to maybe migrate from unnecessary microservices, et cetera. And for necessary ones, you try to suggest them having more control by introducing service measures as a solution for managing this complexity by taking control over the communication between the different components.
That could be service meshes. That could be just having healthy API evolution practices so that whenever we are losing your version, we don't break the API for consumers. And that could be managed with the consumer-driven contract testing. There are techniques out there to manage the interactions between the competence of the system besides service measures just one of the examples.
So for API evolution, for example, do you have any methodology that you suggest or maybe some tooling around it? Or you just go and say like make sure that they are versioned? Is there something structured when you talk about the right API approach?
Well, nothing new there. First of all, don't break APIs.
Easier said than done. That's a very broad rule that's probably there are good exceptions to it.
Kate:
What would be a good exception when you should break an API?
I would say major versions you definitely should be allowed to break the APIs.
Yeah. Then the same thing with the evolution of structured databases only add fields and don't remove fields.
But this is how you'll go straight into this complexity hell when you have too much of everything just because you keep adding and never really removed anything. How is this good?
So then when you finally decide to break the API, remove all the redundant fields and make sure to communicate that to every user that you have out there. So basically, it all comes down in the end with all the rules regarding not breaking the API and how to advance the API and how to add fields and never remove fields. That's all about assuming what our users do. If we really want to know what our customers do. We need to have consumer-driven contracts in place.
What are those?
Well, the concept itself was suggested by ThoughtWorks. I think it was Martin Fowler himself or one of the folks at ThoughtWorks. And there's tooling for that today on the market. There's a system called Pact, that basically what it allows you to do is, whenever you build an API, you create a test for that and whenever you call an API, you also create tests for that and you expert the definitions for those tests. So whenever I consume an API, I can expert the definition of whatever my service is expecting from the API and builds mocks. In the test I build mocks and these mocks define the behavior that I expect from my provider. And then somewhere in my CI, if my tests have passed, I take the test definition and I hand it over to the provider and the provider needs to make sure that these tests also run in their CD pipeline. So in this way the provider is responsible for the API not breaking.
That's different. That's cool.
Sure, but this adds a lot of complexity. It is justifiable when you deal with external consumers who obviously have expectations of you providing consistent quality updates. For that, you obviously need a continuous updates pattern when we can trust each other because I need you to take my updates blindly and you need me not to break things. But microservices, I would say, is about having every microservice exposing API and then other microservice consuming their APIs, and if I start doing all that around each and every microservice, that's tons of overhead.
I don't know. I think it's fine to add additional complexity if it gets you an equal or greater amount of consistency and reliability. But that's just me. I will spend a ton of time and effort making sure that as much as something is automated as possible on the front end so that I don't have to deal with it later. But that's me.
Yeah, I agree with you Kat. Basically what they say is you can't really manage complexity with simplicity, so you will have to add complexity in order to manage complexity.
The question is that there are trade-offs for having microservices in the first place and I would say contract-based APIs and all that actually adds a lot of weight to the counter-argument of maybe I don't need them at all.
Well at a certain scale you must have them because a monolith is great until it becomes huge. Because at certain points, there is this issue of gravity. So only last week somebody was telling me about how they're trying to transfer their monolith to Kubernetes without breaking it down into microservices. So they tried to build a Docker image, but they realized that actually right now their system is packaged as a virtual machine image. And when they tried to build that into a Docker image that they received a Docker image that weighs 125 gigabytes, because their system requires something like 500 RPMs to be installed.
Holy crap dude.
But that's a working monolith system. They have customers, they have paying customers, their system works. The only problem with it is it's very, very heavy, so it's hard to deliver. We all know this, that if you have a system that takes hours to build, that takes hours to package, that takes even tens of minutes to get started. There's a lot of time... that time that you spend just staring at your screen.
Yeah, that's a huge waste of time, energy, money, manpower, nobody wants to be responsible for babysitting that. That's not being an engineer, that's babysitting.
That's where the need for microservice arises. You want to make engineers' lives better.
What you are saying is that sometimes there is no escape from the complexity and you just have to accept it and try to deal with the tools that we have.
Exactly. Pretending that there is no complexity is the worst thing that could happen. Actually there is a very nice documentary that I just watched. It's not a new one. It's from 2016 by Adam Curtis is one of my favorite documentary directors making documentaries on BBC. So his last one is called HyperNormalisation and it talks about how the world is becoming ever more complex and how politicians mainly try to make us believe that it's simple. And that they're in control and how that just never goes right. And we're actually witnessing this right now in the midst of something that nobody knows how to control.
Interesting. And that brings me back to what we started with. And that's your consultancy gig and your message that you need to convey to those who hire you. And at the end of the day, I think the message that you come with is not comforting. So basically you cannot say "People, I've got that. I have a silver bullet. I'm going to fix everything for you." That would be just irresponsible and wrong. Instead, you have to admit everything is hard. Everything is horrible. Everything is complicated. I don't have all the answers. And then what?
Well, first of all, I can help you reduce the pain. Okay? And then I will be with you on that journey. I will accompany you on the journey and I will be there to hold your hand and together we can make it better. That's basically the messaging.
Everything sucks, but you're not alone.
Right. Actually one of the things that I, as a consultant, do is studying the industry and the right examples of these processes, making things better. There're examples of these transformations actually bringing gains, profits, happiness, success, whatever. We don't know if it's permanent but even on a temporary basis, if something works better today than it worked yesterday, then that's proof that there are techniques that can be used.
Okay. So with that kind of optimistic message, it will be a good time for us to wrap up.
Thank you, folks. Thank you.
Thank you. Bye.
Why service mesh are necessary today
Anshuman Abhishek - Dec 13 '21
Hosting and Scaling Applications
Mike Levan - Dec 13 '21
Critical New 0-day Vulnerability in Popular Log4j Library - List of applications
Timur Galeev - Dec 13 '21
Self-Hosting Plausible Analytics With Dokku
Kevin Langley Jr - Dec 13 '21
JFrog
Hybrid, Universal, End-to-End DevOps Platform
Free JFrog Cloud Account Sign Up!
More from JFrog
Implementing the JFrog Xray "Summary View" in Slack
#devops #javascript #jfrog #xray
DevOps 101: Package Management
#devops #beginners #packagemanagent
JFrog Platform - Distribution automation using Pipelines
#devops #continuousdelivery #pipelines #distribution


A Tale of Suspense and Psychological Horror! Detective Robert Neville has been helpful to Brian Cohn, who is finding himself a potential suspect in a missing child case. But when the opportunity presents itself to shift the suspicion to another person will Brian be able to do it? Particularly since he suspects that he may be a serial killer like his father?


Please chip in to make sure the legal win against the Acland Stage 3 coal mine on the Darling Downs isn't overturned.
The Queensland Land Court recommended that this mine should be refused. The impacts on groundwater will be too severe and the noise and dust impacts on local landholders are too great. You can read a short summary of the Land Court decision here.
But New Hope Coal have appealed the Land Court decision, and they are funding a massive advertising blitz, to try to push the Queensland Government to over-rule the Land Court.
Local farmers and community desperately need support. Please chip in to the fighting fund to defend this unprecedented court win. It's a fight for the Great Artesian Basin and the right to protect groundwater statewide - and we can't afford to lose.


text:
Williams-Sonoma CEO says the company saw tariff hikes coming, hired more US workers
Excerpt: "Alber said it's beneficial to bring jobs back to the United States because "the cost from the freight coming from Asia offsets the costs of the labor," as the company learned after opening its first Sutter Street Manufacturing unit in North Carolina."
Williams-Sonoma CEO Laura Alber said Monday that the company shuffled its operations over the past year in anticipation of high tariffs on imports from China.
[Tyler Clifford | May 13, 2019 | CNBC]
The home goods retailer made adjustments over the past year believing that tariffs on Chinese imports could reach 25%.
"I think that you're better off preparing for the worst," she said in a one-on-one interview with "Mad Money" host Jim Cramer Monday in San Francisco. "Unfortunately that pessimism has come true, and we are more prepared."
Williams-Sonoma shifted some furniture production to Vietnam, Indonesia and the United States after President Donald Trump slapped 10% duties on $200 billion worth of Chinese goods last year. Higher tariffs, at more than double that rate, went into effect Friday. Chinese officials said Monday the country plans to retaliate by raising tariffs on $60 billion of U.S. goods.
In December, Williams-Sonoma announced that it would open a facility in Tupelo, Mississippi, in January and add hundreds of jobs to manufacture upholstered furniture. Alber said it's beneficial to bring jobs back to the United States because "the cost from the freight coming from Asia offsets the costs of the labor," as the company learned after opening its first Sutter Street Manufacturing unit in North Carolina.
The furniture maker owns the Pottery Barn, West Elm and Williams-Sonoma Home brands.
"We looked at opening another unit in Tupelo and then bolstering up our other two West Coast and East Coast manufacturing units," Alber said. "And so we're hiring … 500 people, and we've got 140 right now in Tupelo. We need to hire more, and we need to hire more on the coasts, as well."
The company also renegotiated contracts with manufacturers in that country in order to reduce costs and prices, Alber said. Williams-Sonoma won't be successful in halting all costs for consumers, but price increases will be "selective," she added.
"We've been very careful and studying where we should do that, but more importantly we're reducing costs," she said. "So reducing costs, not just on the cost of goods by moving them, but also in other parts of our company."
Williams-Sonoma reported 3.7% of revenue growth in its fourth quarter earnings report and gave guidance that one Morgan Stanley analyst called "seemingly optimistic." The retailer expects comparable brand revenue growth of between 2% and 5% and earnings per share of up to $4.70 for 2019.
Shares of the San Francisco-based firm are up 8.58% over the past 12 months and 3.59% this year. The stock fell about 5% Monday.

redpajama_set_name: RedPajamaCommonCrawl


Reduces Chlorine/Taste/Odor (CTO) and certain Volatile Organic Chemicals (VOC) from drinking water using coconut shell carbons for a sweeter taste. Great dirt holding capacity No carbon fines Maximizes carbon capacity & maintains a low pressure drop Removes : Great dirt holding capacity No carbon fines Maximizes carbon capacity & maintains a low pressure drop Removes: Chlorine Bad Taste & Odor Turbidity THMs Dirt Sediment Specifications: Model #: IF-GAC-010BB/3 Micron Rating: 10 Nominal Dimensions: 10" x 4.5" Weight: 3 lb 2 oz Flow Rate: 1.50 GPM Filter Media: Coconut Shell Filter Life: 6,000 Gallons Chlorine Removal Reduces Chlorine/Taste/Odor (CTO) and certain Volatile Organic Chemicals (VOC) from drinking water using coconut shell carbons for a sweeter taste. Great dirt holding capacity No carbon fines Maximizes carbon capacity & maintains a low pressure drop Removes : Great dirt holding capacity No carbon fines Maximizes carbon capacity & maintains a low pressure drop Removes: Chlorine Bad Taste & Odor Turbidity THMs Dirt Sediment Specifications: Model #: IF-GAC-010BB/3 Micron Rating: 10 Nominal Dimensions: 10" x 4.5"


ArizonaBear, if you ever come back to the DC area you can see the difference. Places like Wheaton and Silver Spring and parts of Gaithersburg in Maryland are COMPLETELY dominated by illegals. The biggest gang here is MS-13, which consists of illegal Salvadorans. Their signature move is cutting people's hands off with machetes. A few months ago in Virginia illegal immigrants drove into a townhouse community where some of their supposed enemies lived and pocketed a row of homes with over 300 bullets and left graffiti all over the walls and sidewalk. parts of Prince George's County near the border with Northeast DC (Langley Park, Takoma Park) look like Nogales, which I've seen in several movies.
Takoma Park, MD, long a hippie enclave is a publicly declared sanctuary city for illegals. The governor of Maryland, Martin O'Malley, openly supports giving illegal aliens IN-STATE tuition at state colleges and universities, including prestigious schools like Univ of Maryland - College Park (GO TERPS!), UMBC, Frostburg, and Towson University. Gaithersburg now has an illegal labor center built by county tax money. The county executive at a meeting told a man to "shut up" when the man asked him about what he was doing about illegal immigration.
Suburban Maryland is definitely going to hell. Our neighbors in Virginia and even Pennsylvania are serious about cracking down. At the same time we are basically welcoming illegals with open arms and this is all over the local news. This plus how the city leadership in DC is pushing the ghetto (including illegals) out of the city....this area will be a Third World country in 10 years.
There used to be a lot of Americans here who worked in landscaping, gardening, roofing, etc but they have been driven out of business. Now when people need work doen at their house they drive to some 7-Eleven parking lot with dozens of illegals sitting around (or to the new day labor center) and get some illegals. Americans used to do this kind of work but now the illegals ahve driven the wages down so low that its not possible anymore unless you want to live like them.
Right now in so many neighborhoods with illegals, they live 20 to a house. They park so many cars on the street it feels like New York City driving home sometimes. My family chose to live in the suburbs not in NY, LA or Chicago. Their houses are always a mess and their lawns are filled with weed or are just brown and unwatered. One house, thye let their bushes grow as high as their roof....I'm not kidding we can't even see their kitchen window anymore. I once worked with this guy who has gone to Mexico City on business and he tells me even down there the nicer areas are not like the illegal alien parts in the DC.
The illegals who come here are the least educated, least principled and least law-abiding portion of their home country's population. Mexico's elite doesn't want to share their wealth and just wants to dump their trash across the border, this is why they refuse to spot their people from coming here. Regular people living in Mexico in fact don't buy into the "reconquista" crap...that's something invented by liberals and "ethnic studies" professors in the US especially California.
Gee, sounds like Phoenix! LOL. I was just in DC, I didn't see that many Hispanics. I must have not been in the right areas.
Hmmm....I believe West Virginia passed a law making English the only official language there .
I've heard the language used in West Virginia----it may be based on English, but it certainly doesn't sound anything like the "official version".
(U.S. Government Printing Office, 1994).


Tessa Hadley's novel The Past, uses the English countryside, with its wide open fields, dark forests and dilapidated houses, as a backdrop for a story that explores desire and fulfillment across two generations of a family.
The novel takes place in the family home in Somerset. The first and third sections of the book are set in present day and titled The Present. Four siblings, Alice, Harriet, Roland and Fran, with Fran's children Arthur and Ivy, Roland's daughter Molly and his wife Pilar, and Alice's ex-boyfriend's son Kasim, gather for three weeks to decide the fate of their grandparent's house. In the middle section, titled The Past and set in 1968, the siblings' mother Jill and three of the children come to her parent's house when Jill leaves the children's father.
her, with everything to play for.
The novel echoes this dream in scenes between the Molly and Kasim, as they strike up a youthful romance, Harriet and Pilar, as Harriet experiences a surprising attraction, and Jill and an old school mate Mikey, as Jill struggles to figure out what do about her marriage.
with the water, although of course I knew it might be poisonous.
The writing stops short of magical realism as characters feel called to walk the countryside, are enchanted by the ramshackle remains of a cabin (home to several pivotal scenes), and seek to lose themselves in the wilderness.
The book is satisfying, as it confirms that suspicion we all have that we carry the sins of our parents and grandparents that we are in some ways replaying the roles they played as we move forward into the future shadowed by the past.
Ellen Birkett Morris's author interviews and book reviews have appeared in Ploughshares, Prairie Schooner, Electric Literature, The Rumpus, The Courier-Journal, Best New Fiction and Authorlink.


text:
Written by Tyler Thursday, 28 September 2017 15:24
The year was 1781. At Yorktown, Virginia, the British General Cornwallis had surrendered to American Commander in Chief George Washington. The War for Independence had been won, the British defeated, and a new nation established… or so most Americans thought.
It was true that the war of fife, drum, musket, and cannon was over. Yet the fruits of victory could still be squandered by terms of the treaty yet to be signed. America remained surrounded by potentially hostile adversaries. Spain controlled much of the Mississippi on her western frontier, and an important piece of property (Florida) to the south. England still dominated the ocean on the east. And both France and England commanded forts and controlled waterways in the west and in Canada.
It was clearly possible that, in the wake of military victory over England, the newly United States could nevertheless have their hard won independence stripped away by the ambitious and quarrelsome nations that surrounded them. The eventual outcome would largely depend on the post-war pact to be signed with England.
The defeat of Cornwallis at Yorktown in 1781 was not the end of the struggle for independence, but rather a new beginning. The American treaty-makers had to safeguard the battlefield triumph. The Continental Congress had assigned some of its ablest men to protect the new nation's interests in negotiations, including Benjamin Franklin, John Jay, and Arthur Lee. But the one who proved to be the most astute and successful of them all was Massachusetts statesman John Adams.
Adams appeared to have attributes of the diplomats of the day. In the European tradition, diplomacy was viewed as an intricate and duplicitous game played by those most adept at social grace, political intrigue, and saying one thing while intending another. John Adams seemed peculiarly unqualified for the role. He was restless and outspoken by temperament, eager to push forward with the business at hand and hopelessly incapable of concealing his true motives and honestly held opinions.
It was not difficult for sophisticated politicians to read Adams' mind, but it quickly became evident to them that he could not be bullied, outmaneuvered, or bribed. He was shrewd at assessing character and had a sharp mind finely honed by a deep understanding of history and law. Arriving in Europe as the representative of a financially exhausted infant nation of loosely united colonies, his dignified and confident bearing gave the impression that he represented one of the world's great powers. Biographer John T. Morse describes his diplomatic acumen in these words:
"Had the business of the colonies been conducted by a diplomatist of the European school ... endeavoring to meet art with wiles, and diplomatic lies with professional falsehood, valuable time would surely have been lost, and smaller advantages would probably have been gained; but Adams strode along stoutly, in broad daylight, breaking the snares which were set for his feet, shouldering aside those who sought to crowd him from his path, unceremonious, making direct for his goal, with his eyes wide open and his tongue not silent to peak the plane truth. Certainly this trans-Atlantic negotiator excited surprise by his … untraditional conduct among the ministers and envoys of the European cabinets; but in the end he proved too much for them all; their peculiar skill was of no avail against his novel and original tactics: their covert indirection would not stand before his blunt directness. So he carried his points with brilliant success."
Under Adams' leadership, the United States wrestled from England each of the concessions it most wanted, and which the British least wanted to give. Boundary lines were drawn in the Americans' favor. All that England could reasonably be asked to grant concerning navigation on the Mississippi River was agreed to. A British demand that all Tories and loyalists be reimbursed for their losses during the war whittled down to a meaningless stipulation that Congress would use its influence with the states to minimize legal obstacles in the collection of debts. Fishing rights off the eastern coast, which were crucial to the economy of New England (but also coveted by Britain and France), were granted to the Americans. And perhaps most important of all, England's negotiators agreed to recognize the new nation as just that - a full-fledged nation, not merely 13 disobedient colonies.
The persistence and boldness that characterized his efforts to win the treaty-making battle had enabled Adams score an earlier victory in the critical area of finance. During the war, money was desperately needed to equip the Continental Army. France had partially answered the American plea for help, but more was needed. Adams was convinced, however, that the additional funds should come from another source, lest the colonies become so obligated to France that they could be compelled to bow to French demands after the war. There was the very real prospect of losing independence by becoming little more than a puppet of Paris, and thereafter being dragged into endless European wars and intrigues.
After carefully analyzing the situation from his diplomatic post in France, Adams decided to approach the bankers and moneylenders of Holland. He sought to be received as the American minister, which would have meant diplomatic recognition of the United States and the opening of doors to loans and trade agreements between the two countries. But as he began his tour of the Netherlands in 1780, he ran into a wall of ignorance and indifference. Few of his hosts seemed to know or care about the existing plight, or potential prosperity and trade potential, of the new American nation.
As usual, Adams' dedication to his country and her needs overruled his personal pride and impatience. He had a goal in mind and intended to work toward it with all of the energy and ability at his command. The most viable solution seemed ominous: he would have to become a combination journalist, teacher, and writer - a one-man educational army who could prove America's worth to the Netherlands.
It was a prodigious undertaking, entailing a struggle against Dutch ignorance and the diplomatic intrigue of both France and England. The French, anxious to increase America's dependence on them and preclude the new nation from developing cordial ties with other European countries, apparently instructed their Dutch representative to do everything possible to undermine Adams' efforts. Only after Adams bluntly warned the conniving diplomat that neither his advice, nor that of higher French officials including the King himself, could deter him did the diplomatic obstruction recede.
For its part, Britain flexed its military muscle at Holland, intimidating the war-shy nation to the point that no merchant or banker of any influence would even acknowledge that an American agent was in the country.
Undeterred, Adams continued to write, talk, and teach.
Eventually, England's bully behavior led to a wave of Dutch indignation. Coupled with that reaction came news that Cornwallis had surrendered at Yorktown. Adams perceived that the time was ripe to press for recognition as United States minister. It was a gamble that, had it failed, might have branded him a reckless man whose bad judgment had led to failure. But Adams, placing what he perceived to be his country's best interests ahead of concern about his personal reputation, plunged ahead.
Holland's leaders met his bold request with the timid claim that they would have to consult the voters. Adams was delighted, since he felt certain that his educational efforts had molded public opinion in his favor. He was right. On April 19, 1782, Holland formally installed the Massachusetts statesman as minister representing the United States of America. The desperately needed loans and trade agreements quickly followed.
Few of his fellow citizens realized the full import of Adams' monumental triumph (he would later look back on it as his greatest achievement). It represented, as he termed it, a "barrier against all dangers from the house of Bourbon [France]" and "present security against England."
Like George Washington, Adams was gifted with keen insight and the ability to perceptively analyze and understand complex issues. In the early stages of the struggle for independence, when others were entertaining thoughts of reconciliation with England, the young Boston lawyer realized that the growing friction between the mother country and her colonies could not be reduced short of war. He was saddened by that conclusion, but as a knowledgeable student of history, he knew that it could not be avoided. Realist that he was, he undoubtedly foresaw the hardships that lay ahead, yet he never hesitated to do that which his country asked of him.
It was his strong sense of right and wrong that drew him into the battle and kept him there until his death at age 91. Following the "Boston Massacre" in 1770, when a small force of British soldiers, driven by fear and panic, opened fire on an angry mob of Boston citizens, killing three (two others died later) and wounding eight. The British governor sought to place Adams on the spot by asking him to defend the Redcoats at their trial. Without hesitation Adams' agreed to do so on grounds that it was "right" to provide the accused with a good defense and "wrong" – no matter how politically expedient - to refuse to do so.
John Adams' career of public service cost him years of separation from his beloved wife Abigail, his children, and the family farm in Braintree south of Boston. As a member of the Continental Congress, his hours were long, his problems seemed unending, his pay was scant, and criticism was constant. When sent to Europe on his diplomatic missions, the workload increased, the pay became even more uncertain, and the criticism increased. But through it all, he expressed only one complaint: he was often homesick. He longed to return to his family on the New England farm. The rich court life of France, which Benjamin Franklin so relished, had little appeal for Adams. He preferred the simple virtues of the New World rather than the sophisticated intrigues of the Old.
Much more could be said about the life and accomplishments of John Adams, including the role he played in the Congress that declared independence, his tour of duty in England following the War, and his years as Vice President and President. But such events pale in importance to the diplomatic victories he achieved in England, France, and Holland during the critical years of America's infancy. His honesty, wisdom, candor, and persistence combined to raise the newborn nation from its war-weary knees to its feet, then send it marching toward its destiny. Without Adams' bold and principled statesmanship, it is possible, even likely, that America would have fallen victim to European intrigue and snares.
Adapted from the Family Heritage Series, a project of The John Birch Society's Movement to Restore Decency.
Picture courtesy of Wikipedia.


text:
Long Bay Prison Governor: Trust everyone "Just don't trust the Devil within"
By Jordan Grantham, 10 October 2017, Canonisation of Saint Maximilian Kolbe
Patrick Aboud, Governor of Long Bay Correctional Complex. Image: Diocese of Parramatta
The Governor of Australia's largest prison had a Parramatta childhood centred on the family fish and chip shop, the Parramatta Eels rugby league team, Parramatta Marist High School, St Patrick's Cathedral, Parramtta and then, Our Lady of Lebanon Co-Cathedral, Harris Park.
Pat Aboud is now Governor of Australia's largest prison, Long Bay Correctional Complex, protecting civilians and reforming almost 1300 inmates with his trademark toughness and concern for the well-being of others.
"Trust everyone," Governor Aboud advised, "but don't trust the Devil within."
Governor Aboud has seen the worst of human nature. While most public defenders temporarily engage with criminals, Corrective Services NSW staff members deal with murderers, terrorists, paedophiles and violent offenders on a daily basis.
"And that's just to name a few," Governor Aboud said. "We face what the public fears."
Danger and death are constant possibilities in this high-pressure job, which takes a serious toll on Correctional Officers and all staff.
"I'm proud of all the hardworking and decent staff we have with in corrections," Governor Aboud said.
"Family, friends, colleagues and the job keep you going," he said. "You need an outlet."
"There are deaths in custody, there could be the possibility of losing a staff member, through depression, hostage siege, riots, and/or a critical incident" he said.
RELATED: Bishop Vincent washes the feet of prisoners
RELATED: Catholic Prison Chaplains National Gathering
RELATED: 'Reaching Out, a Message for Prisoners' during the Year of Mercy
RELATED: Bishop Vincent celebrates Mass with prisoners
Corrective Services NSW holds a Remembrance Day each November for officers and staff who made the ultimate sacrifice. This year the day is on Friday 24 November.
One officer the day commemorates is Geoffrey Pearce, who died at 29 years of age in 1997, after being stabbed with an HIV infected syringe at Long Bay Prison eight years prior.
It might seem a far cry from young Pat Aboud's Parramatta childhood of family, faith and footy. The stereotypical images of altar boy and prison Governor could not be more different.
"Yeah, I loved Parramatta," Governor Aboud said.
"We went to St Patrick's Church with Mum and Dad and older and younger brothers."
"Dad would lock up the shop and go to St Patrick's."
"Our Lady of Lebanon came online and we started going there. After the first year it opened, I was an altar boy at the first year procession."
"I think society has lost that. The time of having family time, people sitting around the dinner table is gone. I've instilled with my kids."
"We had footy every Sunday and I played on Saturdays for St Patrick's Primary [Parramatta] and Parramatta Marist. I'm a staunch Parramatta supporter. We had that for 30 years there."
"Church was the only time we'd all be together, apart from dinner each night."
"On top of that as they got older if their friends are around, they would come around, all have dinner on a Sunday night. And I say 'put that time aside'."
"It's your faith at the end of the day, and the people you mix with, who get you across the line," Governor Aboud said.
"You have bad days, good days. This is not an easy gig at the end of the day. You're dealing with all facets of correctional management."
"That's one thing I learned, that family and friends are everything and I try to instill that now with my adult children."
What is his advice to youth in the Diocese of Parramatta today?
"Respect society. Respect the law. Respect your elders. Strive for success. Don't have the entire 'new beaut' things, all the bells and whistles. Be true to yourself, your roots, your upbringing," he said.
Governor Aboud is still a parishioner in the Diocese of Parramatta, and continues to achieve all of the above. He has made his family, Corrections and the community incredibly proud.
Next week: Fighting crime takes a team: Corrections NSW's unsung heroes
Catholic Corrections OfficersCatholic HeroesCorrections NSWGovernor Patrick AboudLong Bay PrisonOur Lady of Lebanon Co-CathedralParramatta Eels rugby league teamParramatta Marist High Schoolst patrick's cathedral
Jordan Grantham


text:
Q: React/MaterialUI - Change case on button click I am trying to create a Switch where a user selects a gender and then gets the appropriate form. The forms have been created as components and render fine when I set the gender manually. Where I am stuck is getting the gender variable to update when a user clicks a button. I understand this is probably not the right way, and I should use State, but my google-fu is failing me, so I am asking you experts. Here is the code:
import React, { Component, constructor } from "react";
import MaleHormone from "../components/maleHormone"
import FemaleHormone from "../components/femaleHormone"
import { Button, Grid, Typography } from "@material-ui/core";

var gender = ""

export default class Hormones extends Component {

  genderSwitch(gender: any) {
    switch (gender) {
      case "Male":
        return (<MaleHormone />);
      case "Female":
        return (<FemaleHormone />);
      default:
        return (<Grid
        container
        spacing={6}
        style={{
          textAlign: "center",
          padding: 20,
          paddingTop: 100,
          justifyContent: "center",
        }}>
          <Typography variant="h4" color="primary">
            Please select your gender
          </Typography>
          <Grid
            container
            spacing={6}
            style={{
              textAlign: "center",
              minHeight: 20,
              padding: 20,
              paddingTop: 30,
              justifyContent: "center",
            }}
            >
            <Button id="male" value="Male" variant="contained" color="secondary" size="large" style={{marginRight: 20}}>
              Male
            </Button>
            <Button id="female" value="Female" variant="contained" color="secondary" size="large">
              Female
            </Button>
          </Grid>
      </Grid>);
    }
  }

  render() {
      return (
      this.genderSwitch(gender)
    );
  }
}

A: import {TouchableOpacity, Text} from 'react-native';
export default class Hormones extends Component {
    state = {gender: "Male"}

    ...

    render () {
        return (
            <>
                <TouchableOpacity onPress={()=> {
                    this.setState(
                      {
                          gender: this.state.gender==="Male"?"Female":"Male"
                      });
                    }
                >
                    <Text>Switch Gender</Text>
                </TouchableOpacity>

                this.switchGender(this.state.gender);
            </>
        );
    }
}

A: Here you go,  this should work:
import React, { Component } from "react";
import MaleHormone from "../components/maleHormone"
import FemaleHormone from "../components/femaleHormone"
import { Button, Grid, Typography } from "@material-ui/core";

export default class Hormones extends Component {
  state = {
    gender: ""
  };

  genderSwitch(gender: any)
  {
    switch (gender)
    {
      case "Male":
        return <MaleHormone />;

      case "Female":
        return <FemaleHormone />;

      default:
        return (
          <Grid
            container
            spacing={6}
            style={{
              textAlign: "center",
              padding: 20,
              paddingTop: 100,
              justifyContent: "center"
            }}
          >
            <Typography variant="h4" color="primary">
              Please select your gender
            </Typography>
            <Grid
              container
              spacing={6}
              style={{
                textAlign: "center",
                minHeight: 20,
                padding: 20,
                paddingTop: 30,
                justifyContent: "center"
              }}
            >
              <Button
                id="male"
                value="Male"
                variant="contained"
                color="secondary"
                size="large"
                style={{ marginRight: 20 }}
                onClick = {() => this.setState({gender:"Male"})}
              >
                Male
              </Button>
              <Button
                id="female"
                value="Female"
                variant="contained"
                color="secondary"
                size="large"
                onClick = {() => this.setState({gender:"Female"})}

              >
                Female
              </Button>
            </Grid>
          </Grid>
        );
    }
  }

  render() {
    let genderForm = this.genderSwitch(this.state.gender);

    return genderForm;
  }
}

redpajama_set_name: RedPajamaStackExchange


French actress Sophie Bernard (the incomparable Monica Bellucci, in one of her most complex and demanding roles) has agreed to make a movie in Montreal, taking on a role deliberately sculpted to mirror events in her personal life. Sophie's real focus, however, is on attempting reconciliation with her adult son Thomas (Aliocha Schneider), who lives in Montreal and has not seen his mother in three years, their estrangement owing in part to Sophie's refusal to reveal to Thomas the identity of his father. Thomas' distress over his mother's visit is compounded when he witnesses a stranger's attempted suicide on the night of Sophie's arrival.
Meanwhile, paramedic Pierre and ER nurse Marie (the extraordinary Pascale Bussieres), the responders to the suicide incident, are immersed in unspoken distress of their own. Pierre is a veteran suffering from undiagnosed PSTD, while Marie has a history of loss that she stifles through over-work. All four characters will become entangled in a moment that will force them to confront those past events that each have taken pains to ignore.
PRECEDED BY A CONVERSATION WITH MONICA BELLUCCI, BY DIRECTOR GUY ÉDOIN.


This blog has been on my mind a lot lately. I'm hoping I'll have the time to update what life has looked like the past few months and where I find myself today. It's been quite the wild ride. I'll leave that story for another day and stay focused on my one goal, get a Five Minute Friday post up!
Contributing to Five Minute Friday has been a goal of mine all year. I often write on the prompt and then it never makes it to the blog. However today, I've got my eye on the prize!
I'm a big fan of First5 and have been doing their studies for the past two and a half years. They started the book of Mark two weeks ago, and I'm a little late to the game and started this week. Had I approached getting caught up as I typically do, I would have blown through each day, being caught up in no time. However, a friend messaged me this morning saying she stumped across my blog and mentioned my "When God Gives You A Plant" blog post. I reread it and once again reminded of my default ways, and it was just the right dose of conviction to approach getting "caught-up" differently this time around.
When I study my routine usually consists of journaling first thing, reading the chapter of the day, completing the experience guide and then reading their teaching. I decided to skip journaling this time and went straight to reading. After reading, I was processing so much I ended up journalling about just one verse. It just so happened I was able to have my journaled page match the Five Minute Friday prompt for this week. A page in my journal takes me just about five minutes so here it is! Five minutes of writing inspired by the word only.
At first, reading the words "don't be afraid" sounds demanding. My rebel heart wants to take offense and think how dare you to tell me what to do. (Yuck. My heart is so ugly.) It's like a parent telling a toddler not to do something for the fifteen-thousandth time. They say it with love and good intention. However, those instructing words fall on deaf ears because the rebel heart wants to have its way.
The book of Mark points to Jesus' authority. In that day, they had been under Roman rule and had only seen authority abused. Jesus brought a new level of authority and his kingdom a different type of rule. Looking at this verse through that lens, knowing just how much Jesus loves us, I can see a deeper meaning, helping me to redefine the way I see this verse.
You see, fear is focused on self and faith is focused on Jesus. In this verse, he's calling us to look not inward but upward. This ties directly into what I'm learning in the book, Free of Me. I hope to dig more into that, but for now, in summary, she explains our self-centered society treats everything around us as a mirror. For example, in relationships, things are good for me, if that relationship reflects back good things. If there is something off in the relationship, and things aren't going well, due to our mirror tendencies, it reflects on me, and then my life is no longer "good" based on how I think it should be. This truth carried a lot of weight for me and can see how it relates to this verse.
When we live in this self-focused way, treating everything around us like a mirror, we give the power to others to completely alter our days and ultimately our lives. The answer she proposes to our self-focus nature is self-forgetfulness. Since I'm only a few chapters in, I'm looking forward to learning more about what that term means. For what I understand it to be, it's what Jesus is saying here in this verse. Stop focusing on yourself, and just focus on me.
God gives us himself in human form for us to keep our focus on. How great and amazing is that! He also gives us his word which is alive and active to help us focus on him. We lack no short supply of ways we can direct our heart to him, and it's something he invites us to do daily.
So this verse written thousands of years ago is applicable more now than ever. In the Free of Me book, she points to the fact our self-help generation is the most self-focused generation and at the same time, and we're the most anxious and fearful generation to date. We desperately need this truth from Jesus to go deep into the marrow of our bones.
So today, read this verse and hear Jesus saying, don't take the road of fear and self-absorption. Stop looking to yourself for strength and power. Instead, look to me as your source, you only need to believe.
To check out other Five Minute Friday posts or to join in on the fun click the image below to learn more!


We use a number of assessment techniques including summative and formative assessment to measure your child's learning. The following are included in your child's assessment.
NAPLAN - Students in years 3 and 5 take part in the National Program of Literacy and Numeracy assessment (NAPLAN).
Your child's progress is reported both informally and formally.
Report Cards are issued at the end of each semester. These have been designed to meet government regulations in regard to reporting. Formal teacher interviews are held twice yearly.
You are welcome to discuss your child's progress with the class teacher at any stage of the year. We recommend that you make an appointment to ensure teacher availability and that you brief the teacher of your queries before the interview.
Other forms of reporting that occur at the school are "Celebrations of Learning." These happen towards the end of a unit of work and are an opportunity for parents and interested parties to view samples of the student's learning. These are interactive by nature and showcase the child's presentation. Teachers use these celebrations as a form of assessing and reporting.


text:
(-) Technology and data
Is it possible to use the digitisation of the NHS to reach the furthest first?
The health and care system has historically been reliant on paper for sharing information about patients. Digitisation is inevitably changing that, but what impact does that have on those who are marginalised?
By Annie Whelan - 13 February 2019
A significant moment for general practice
A new five-year contract for general practice has been announced, with an increase in funding and plans to transform GP services. Beccy Baird and Anna Charles give their take on the key things you need to know.
By Beccy Baird, Anna Charles - 1 February 2019
The NHS long-term plan: five things you need to know
The NHS long-term plan has been launched and long it indeed is, in every sense of the word, clocking in at a weighty 120 pages. Here's my take on the top five things you need to know.
By Richard Murray - 8 January 2019
Social prescribing: a part of something bigger
Beccy Baird highlights how social prescribing must fit within a well-connected and sufficiently-funded system if it is to be successful.
By Beccy Baird - 18 December 2018
Using technology to build a partnership of trust with patients
Chris Ham explores how technology can enable positive clinician-patient relationships and support patients to take an active role in their health and wellbeing.
By Professor Sir Chris Ham - 7 September 2018
How can community involvement reduce health inequalities?
Can community involvement in Morecambe Bay help reduce health inequalities that have existed over decades?
By Andy Knox - 5 September 2018
The NHS app: will it work?
Matt Honeyman considers the opportunities and challenges ahead for the NHS's national app due by the end of 2018.
By Matthew Honeyman - 26 July 2018
Planning for a national centre for arts and health
Sarah Gregory explores the issues around co-producing a plan to establish a national centre for arts and health.
By Sarah Gregory - 18 July 2018


corelle square dinnerware sets clearance home improvement cast now.
modern entertainment center ikea rustic gray 2 piece modern entertainment center home improvement cast 2018.
nicole miller home kids miller kids miller home bedding goods table lamps medium size of kids best bedroom interiors home improvement loans.
keurig 16 oz coffee maker oz coffee maker brewing system machine w cup carousel 2 oz stoneware coffee mug oz coffee maker find home improvement stores near me.
small entryway stool image 0 home improvement cast angela.
sleep number kids i visited the sleep number store to test the kids bed my little one home improvement wilson fence.
frozen bedding set twin size frozen bedding set twin size new sets home improvement stores 2 home improvement contractor license nyc.
exterior wood finishes comparison color chart home improvement wilson meme.
kids road carpet kids road carpet home improvement contractor home improvement license nj.