Jesus doesn't give them a promise. He only gives them a command. Now think about it. Most of us know there is a power in Jesus's promise. But very few of us know that there is power in Jesus's commands. God's commands, not only His promises, have power. Imagine, Jesus doesn't tell them they will get healed. Jesus only tells them where to go. If I would be a leper, I would say, before we do, what are our chances of getting healed? I don't mind walking, 10 more miles. But I've been walking for the past 25 years, a leper. And I don't need another rabbi telling me where to go. I need to know, do I even have a 50% chance of getting healed? Or do I have 50% of my leprosy be gone? I mean, I can settle for 50%. But I need to know some kind of a promise.  Jesus doesn't give them a hope. I mean, read the Bible. He tells them, go show yourself to the priests. Okay. And they go show themselves to the priests. You know, Jesus's clothes have power. Jesus's spit has power. Jesus said, I would rather take Jesus's spit than Judas' kiss.  God protects us from those kisses in Jesus's name. But Jesus's spit has power. Jesus's garments have power. Jesus's promises have power. But somehow we think Jesus's commands, they force us to do things. Can I tell you something today? Jesus's commands are packed with power. And when they are acted upon, power is released. They bring a cripple man to Jesus, lays on his bed. And Jesus forgives his sin. The man is still crippled. The man is still lame. The man still cannot walk. And Jesus looks at him and says, get up. That's a command. He didn't say you will walk. He didn't say you will get up. He doesn't give him a promise. He didn't say you will get power. He just looks at a man who, the reason why he came to Jesus, he can't walk. And Jesus tells him to do the opposite of what he cannot do. He says, do it. If I would be that man, I would say, well, the problem is the reason why I'm here is because I can't walk. And Jesus says, when I commend you, there is a power that follows the command. And when you try to act on it, my power only then is released. Not when I commend when you act. Many people say, I can't obey God. I can't pray. I can't read the Bible. I can't bring people to Jesus. I can't speak. I can't give my finances. I can't do this. I can't do this. If God tells you to do it, act on it. You may not be able to do it a minute before he tells you. But when he tells you to do it in his command, it's a power for you to do it. And when you act on it and realize God's eyes have power. His breath has power. And if he uttered a word, that means in that word is a power to do it. God will not ask you to do something. He doesn't give you power to do it. And when does he give you power when you choose to act on his command?


The Whales of August tells the story of two sisters who return every year to an old cottage off the coast of Maine to watch the whales. The film takes place during the course of one day when the sisters reflect on their own lives and their future. The movie was shot on Cliff Island and this year there are several events to mark the 25th anniversary of the film's premiere. Brian Knoblock talked with Roger Barely, who worked on the film. Roger, 2012 is the 25th anniversary of the debut of The Whales of August in New York City. It was shot on Cliff Island, a place that's very close to your heart. Talk about that experience on the film when it was made there. You worked on the film itself. I did, Brian. I was innocently sitting in my office in the middle of July, a tiny little office when a whole bunch of people had never met before, and I rushed in on a sultry gray July afternoon and said, we want to make a major motion picture and we need a place for the production, to handle the production support infrastructure. And so I happened to head an organization that owns a ball field, and it was right next to the place where the movie would be filmed. I knew nothing about this. I asked them to describe the movie in brief, and I immediately got very excited. The Whales of August had five stars, and Betty Davis, who has a well-known Portland history, Lillian Gish, Vincent Price, and Southern and Harry Carey Jr., and they would be living on Cliff Island for between three and four months, and immediately I became excited. And so the wheels started to turn. We went through a number of meetings of our nonprofit, which owns this ball field, and so were we worried about people from New York City or Hollywood coming in and bringing high-powered vehicles and drugs and alcohol and all these things that our island likes to think don't exist. So within the next couple of weeks we had a bunch of emergency meetings and it involved a number of other nonprofits on the island because they wanted to show the dailies, the daily rushes of the shots in our community hall. They wanted to be able to do everything in a way that would allow them to get this filming completed by mid-November. And there were a lot of events now coming up, the week of August 10th, a lot of events coming up on Cliff Island and something important as well. The producer, Mike Kaplan, who lives in Idaho, came out to Cliff Island last year and said, hey, it's 25 years since we did this movie. Let's have some fun around this. And he had some other issues on his agenda that he would like to profit by. But the core of this is to have showings of the movie and visitations of the house, tours of the house, and to hear people who were on site in 1986 talk about what the experience was like. And so that's what's happening. So there's one event at the Portland Museum of Art on Friday night. There'll be a showing of the movie and we hope that there will be a reception at the same time. And there may be some, all four of the five stars are deceased. One is in California and has declined the invitation to come join us. But two of the bit players in the movie who subsequently became pretty well known will be here. And then on Cliff Island, the events also start on Friday evening and we'll go through Sunday afternoon. So it's going to be a wonderful re-gathering of our community and the people who were a part of it then and who want to learn about it now. We have a picture here of the whole production cast here of the movie. What was it like having all those outsiders invade that quiet little island for the summer? Invade is the right word, Brian, but we felt we were willing to be invaded but it was still going to be an invasion. There are 50 people in this picture including the stars and all the people who worked on it. But some wonderful things happen. The island kind of quietes down a whole lot after Labor Day. Well, the filming went on to mid-November so it was like summer extending and almost a Thanksgiving and there's a lot of activity, a lot of liveliness. It was just a delight to be able to have this going on to have a focus and to not be sad that summer was over at Labor Day. We used to have a junk car problem on Cliff Island and to some extent we still have a little bit of one, but the movie folks brought about 20 golf carts to the island and we now, most of us who need vehicles, motorized vehicles, use golf carts. So a lot of good stuff happened, a lot of fun, a lot of improvements, a lot of money was left on Cliff Island. So people want more information about the upcoming events and the movie showing, where can they go? They can go to the Portland Museum of Art website or to the Cliff Island website and information on both the mainland and the island issues will be there, available. Great, thanks very much. You're welcome Brian, thank you.


called Dev Structure and we work on configuration management software primarily with the package called Puppet. And we built a tool called Blueprint that figures out what you did to your server so that we can generate Puppet code for you. And I'm here to have a little bit of a survey over a lot of sysadmin-like tools and try to understand why they're written in Ruby and what patterns we can extract from that. So we're going to start with Puppet the thing that I know the most about and tell a little story about Luke, the sysadmin, who was very dissatisfied writing CF engine installations all day every day. So he set out to write a new configuration management system that was data driven and relied less on diffing of files and applying patches and more about managing whole resources. And Ruby ended up winning out as the implementation language because Pearl was already kind of over the hill and Luke couldn't figure out how to get the auto-loading behavior he wanted out of Python. The auto-loading behavior in Puppet is very, very pervasive and works roughly as follows. When you ask for some new, some type or something that's not loaded, it globs over source files and figures out where that is. And each of those source files, as they're executed, uses an internal DSL to register the code blocks or the classes or what have you that it's creating. And it might look a little bit something like this. So this is how the package type is introduced to Puppet and without too much stating the obvious, you call a new type and you give it a block, which is evaluated in the class scope so that it can define methods like INSYNC and there are many others that a type might need to define to do its work. Now, that internal DSL, which is, it exists basically because using const missing wasn't a viable option in, I believe it just in Ruby 1.8 in general for getting the auto-loading behavior where if a type hadn't been seen yet that it would go find it. But by using that DSL and gaining the obvious context of we're introducing a type, we're missing out on the context of exactly what scope we're executing in. So it isn't very clear that this block with nothing else in it is someplace where I can define methods. So I think this is kind of a drawback in one of the things that makes Puppet's internals very hard to deal with. So specifically, I shouldn't have to ask someone or consult documentation as to whether I can define a method someplace. I shouldn't have to think very hard about what the name of a constant I define is. If I define Puppet type, new type package, I shouldn't have to wonder what the end result constant is called. And an extra that comes up a few times is because blocks are being defined at the top level, you can't always return from them. And that can be very frustrating as a programmer that likes to short circuit out of methods. So here's a couple of Puppet resources in Puppet syntax. Puppet is not a Ruby implemented DSL. It is an actual language with a grammar and a parser. And these two resources, a package that's ensuring Ruby is installed and a file that's setting up at ccdl.com. These are orthogonal resources. And so when Puppet executes them by way of auto loading the appropriate types and providers and figuring out what the current state of the system is and how to bring it in line with the desired state, these orthogonal resources don't have any relationship to each other. So Puppet can make a best effort and work through failures. And the problems that come up when you do that, when one code path doesn't cause things to come after it to fail, is that it's very difficult to identify those failures. So Puppet uses a very extensive logging system that's accessed by a number of command line options. If you start to see problems, ask for verbose, if you really see problems, you can get all the way to stack traces in line with the output. Not that they stop the execution, but that at least you can see what's going on. And all the output is tagged using syslog terminology. So you can gradually build up from info only warnings all the way through debug, or turn it all the way down to just seeing errors. And everything gets color coded if you're running interactively. So this is, I think, kind of the Cadillac of logging, that if you need to know what's going on in Puppet, it's easy to pick out the pink error line and work from there. So now I'd like to switch up and talk a little bit about Chef, which maybe more people in the room have experienced with. Chef is a very similar system to Puppet and has a lot of religion on both sides of it. I'm not here to start that religious war again. I am here to make a couple of comparisons. They're functionally very similar packages. Both of them are about systems administration tasks expressed as code, but they have very different philosophies about how to implement it. Chef, in contrast to Puppet, uses an external Ruby DSL, so the Puppet resources I showed before are actually implemented in Ruby. And inside, rather than using a DSL, it's actually implemented as I'm going to call today Ruby Ruby. That is, it's going to use real classes and real methods. So here's a couple of Chef resources. In fact, the exact same resources that set up the Ruby package and set up Sysctl. And obviously, they are Ruby code. It's deval block so that the methods can affect the whole resource. And here's the inside code, which is nice, plain, clean Ruby. Now, the disadvantage here is that the auto loading behavior that's so awesome about Puppet isn't available because of how constant loading works. And if anyone wants to tell me that, I'll give you a drink ticket. Tell me how that works. I'll give you a drink ticket. But it's really nice to be able to know with just a glance at this file that I'm in a class scope that's nested in the Chef resource namespace so I can define methods and constants. And I know what those constants are going to be called when I need to reference the player. So already early in, I want to make a call about a couple of things. The external DSL, whether you have a grammar and a parser or implemented in pure Ruby, I think the point is to do what's right for you that it's not inherently better or worse one way or the other. However, the internal DSL, I would like to think you should shy away from it and stick with the Ruby Ruby implementation. It's not worth my time to kind of reverse engineer someone else's thought process of their internal DSL to figure out how to contribute code to their package. I still think Puppet's better because I like the external interface to it, but they're clearly pros and cons to both of them. And this is my plug for I'd love to talk more about this with anyone who's interested or anyone who's an expert and has different opinions because I'm always open to changing mine. And now I'd like to get back to it. Both of these packages, despite pros and cons, are about codifying systems administration. And this is something that in the old times, people used Perl to do when shell wasn't good enough. And of course, everyone's heard that Ruby is a better Perl. And things like having first class regular expressions and backtake operators and relaxed policy on parentheses makes that a pretty good case. It's a modern take on the idea of a language that you can do most anything in. But then there are features that really make it a better Perl, like blocks, which are clearly so much better than backslashes and subroutine references. And real honest objects with syntax, not the way Perl objects always felt to me, which is a lot like trying to implement object-oriented code in C. And of course, Ruby gems is a lot like C-Pen, with all of its benefits and drawbacks. Because I'd like to dwell on the subject of release management, because there isn't a central feature freeze date for the next iteration of Ruby gems, the way there is for the Debian Archive. And that means that we as package maintainers need to take a little more initiative on that front. So to keep Ruby gems useful and stable and indeed even usable for people who are on call, the release managers for the gems really need to think about regression testing and kind of head-in-hand with that versioning, so that it's very clear when breaking changes are being introduced to APIs, it's also very clear when no breaking changes are supposed to be introduced. Makes it very much easier to test compatibility with existing code bases and gate upgrading of gems on whether it passes our own applications test. And a slow and steady release cycle kind of aids in that as well where we don't have to, well, I'll just tell a story instead of explaining that. Once I wrote the Flickr uploader and I found a bug in it, and the day of the release we found this bug fixed it and released again only to find out that evening we've released an even worse crash level bug. So the slow and steady release cycle along with healthy regression testing is going to make your Ruby gems much easier to maintain and make use of by people who are on call. And that's good. Now, most people build Ruby gems somehow through Rake, and Rake is being a build system, a very common tool used by systems administrators, and it exhibits a couple of patterns that I'd like to talk about. It's an external Ruby DSL coupled to an internal Ruby-Ruby implementation much like Chef is, which is to say I like the pattern that its interface and internals follow. And it came at the time when Ruby was finally the language of choice that was able to implement GNU Make style interface that looks something like this, where you have named tasks that may have dependencies. And Rake's job is to resolve these dependencies and work through them in order. And this dependency programming is a really powerful construct for systems administration because it boils down to convention the order and failure case when you're dealing with a complex system. You give it a goal, say I gave it file.c, and it works out that the prerequisites are file.o, or reverse that. And this dependency tree can be walked out recursively so that if anything fails, we immediately stop and can deal with that. And this works really, really, really well for interactive, fail fast build process type of jobs. And because this is something that's usually used interactively, we don't need the same kind of really aggressive logging that you might see out of Puppet. But then when we take the ideas that started, well it didn't start in Rake, but we're introduced to Ruby in Rake and take them into parallel with Capistrano where we have the same sort of dependency model, but it's being executed on multiple hosts at the same time. And more interesting and subtle failure case comes up. And this is where we kind of resort back to the Puppet style of logging where we make it very clear what could have gone wrong and let the other hosts in parallel continue on.  So the expectation, at least in my experience, is that when you're running Capistrano jobs across a whole cluster, it's very easy to see an anomalous host that's failing for no particular reason versus a catastrophic failure of every single host where everybody's printing the same problem. And this is an aiding in debugging and again is great for use in interactive systems and administration tasks. Then the marionette collective is a package that kind of takes off, takes where Capistrano left off and has taken the sysadmin job interactive sysadmin work to a new level by publishing what work is to be done over a stop server. So all of your agents running a Ruby daemon are listening for jobs to do and are publishing back into the queue what their result is. So this is kind of a more scalable implementation of the same idea and it allows the same sort of anomaly detection as Capistrano does. The pattern here that I'd like to point out is that the author of this tool, Ari Panier, described it initially as a framework, a middleware for systems administration, not a tool in and of itself. And the important thing to note here is that this informs its design in that it's not one monolithic tool, it's not heavily integrated with any particular development workflow or production deployment strategy. It's a bunch of small tools like MC Ping and MC Find Hosts that do one thing well. MC Ping probably obviously sends an echo message over that bus to all of your servers and reports back on what they said. MC Find Hosts allows it to plug into Puppet and select a subset of servers from your infrastructure all based on who replies to the messages on the bus. And these little programs are very useful to compose into larger programs where you grab a list of hosts from MC Find Hosts, ping them to make sure they're up, and then do something totally different and unrelated to MCollective. And this is a wonderful pattern and something that is inevitable when all of your programs start out as scripts, they start out as small, perhaps even interactive commands where you string five commands together as a pipe, and it slowly grows into something more generic and useful to you. And MC Collective started the same way as a simple solution for a problem that SSH in a for loop was not scalable enough for ARRI. So what do I mean by scripts? That they're those small command lines, things that you don't even think about that are so trivial, you don't need to test them. And when they turn into real programs, there's a few things that we can do to make them easier to maintain and more robust. And the first is to think heavily about add-in potents. Any command where you can run it again and nothing bad happens is a good command. Likewise, anything that you can run, notice a failure and run again without argument changes or code changes is a good thing. And for a web analogy, this is thinking about things in terms of puts instead of posts. And in the configuration management world, this is like thinking of managing entire files at once rather than patches and dips against existing files. And that's a particular example of a good API design principle. The principle of least surprise. Additional considerations that I think are important to make when building tools for systems administration are proper namespacing. You saw that M Collective named all of its tools MC, whatever, so that it's very clear by the suffix what's happening and by the prefix how it's happening. And the fact again that it's using a message bus to form the substrate that all of its other actions work on top of is a perfect case for a generic solution that's just generic enough to solve the problem and allows further work to come on top of it without being predetermined. So we've been talking for the past couple slides about shell programs and shell interfaces and command lines. Does this matter to us in Ruby? And I would argue it does. And at this point, this is a slight diversion but I think we'll get back to it. In Ruby, we have say two high level structures of programs, data structures programs or Unix programs. And the spoiler is that Ruby can do both of these well. Unix programs I like to think of as being heavy on file system manipulation and on making system calls either via Ruby, via C or direct kernel code or by the section one manual programs like Jamad that are exposed that basically perform one specific system call from shell code. These kinds of programs work really well in shell are very easy to implement in C. The data structures programs are much more difficult to implement in shell because generally you need more expressive power than the scalar variables you get out of standard POSIX shell. You probably need more than the single level of hierarchy you get out of bashes one dimensional arrays and associative arrays. And you probably want to take advantage of modern code constructs like classes and methods. You might want to do network communication. You probably want to have some notion of concurrency and parallelism. And so you might need these concepts that don't exist in a shell program. Ruby can of course do both of these things and if you're going to write a Unix program in Ruby, you probably should read Unicorn as Unix and you should probably read the documentation for file, dur and file utils which provide a lot of the file system manipulation tools that you might want. And then there's Process and Etsy which provide interfaces into user IDs and permissions as well as Etsy password and Etsy queue entries so that you can fully take advantage of all of the intricacies of Unix users and safety and whatnot like that. Now Ruby editorializes a lot of loopsy and changes, for example, set UID to the setter UID on the process class. So there's a little bit of digging you need to do to map from a manual page to Ruby but once you do it starts to be very, very useful. In data structures land I think it's fairly obvious to any Ruby programmer that hashes and arrays can turn into anything you like and being able to build a class from these allows you to describe your data types in excruciating detail and build them up in whatever level of hierarchy you like. And all of this code that we've built in Ruby be it Unix or the data structures work can be composable just like those M-collective fine host programs can be in shell land. And I think this is a crucial pattern to be able to start solutions, solve one problem and then be able to reuse the core of that to solve another problem later. And there's one thing I'd like to specifically harp on with regard to this and that's that within Ruby code I really think you should declare all inter-file dependencies so that it's very trivial to pull out one file, one particular piece of functionality from any old file. Here is an actual I apologize for this example from a real live running web app. All I wanted to do was use active record and specifically because this was a Rails app that used device I needed device slash ORM slash active record almost at the bottom there. All of this other stuff is because device uses a single entry point and expects everything else to kind of flow from there. This is not a dig device, there are many many other examples but this was the most accessible and was the perfect size for the slide. All I wanted to do was this and I would encourage everybody to go look at every gem they maintained and make sure that I could do this even if it's an implementation detail it's okay if I shoe on myself into not being able to upgrade but the code should stand on its own. That is to say explicit is better than implicit. I apologize for bringing Python into this but I think this is a principle that would be worth stealing. Because when you have a file that depends on some other omnipotent loader to make sure the world is in the right state for it to come into being, then you're in nerdy C.S. terms said to be coupled to that and the coupling behavior is particularly bad in cases where you can't see it unless you execute the code and see the failure. So the more required statements we can put in place to be very explicit about what it takes to have the environment set up for a particular file to run, I say the better. This is a form of magic and magic is a little bit like implicit but a little bit more showing it sparkly. The summary of all of this, magic and the coupling being explicit is that operable maintainable code is easy to look at and understand what it does and this is kind of a form of simplicity and it's really ultimately okay that your code looks like code and has required statements. That's what we're all here to write so it's all good. So I've gone faster than I thought I would but I have a few more interesting notes about the patterns and anti-patterns here and then clearly there will be time for questions. So the external DSLs are I think a great pattern going all the way back to Puppet & Chef where Chef uses an external DSL that's written in Ruby. It's great because of the brevity that it gives you as a user of that package and it can be implemented as we've seen a couple of times today in a very effective way that it's clear what the Ruby syntax does and it's clear what the syntax does within the semantics of the program that's using it. However, the internal DSL I can't speak so favorably of. It tends to obscure what's going on in the Ruby code and it makes it very difficult to jump in quickly and maintain without a lot of time spent reading the entire code base. Dependency programming like we see in Rake and Capistrano is I think a great pattern for very convention oriented failure handling that works especially well in straight line execution of a linear or a tree of dependencies and it works very naturally for an interactive task like a build tool or something that if you squint just right could look like a build tool. Item potence is a great way to think about API design in an environment where sys admins might be up late at night working on trying to fix something if they don't have the fear of running your code over and over again with external changes trying to make things work. It's going to be it's going to be a better time for them and it helps you I think to work within that framework because it forces you to write smaller more clearly defined tools. And of course I'd love to say that magic is a little bit of an anti-pattern that the more intimate knowledge you need to maintain a system the less likely I and anyone else with a kind of operationally focused mind is going to be to use it. The philosophy explicit is better than implicit all about reducing magic and coupling it's all about promoting the reuse of small pieces where appropriate and as Rubyists who have the wealth of Ruby gems at our disposal I think there's even more that we could use from within those gems if they were easy to tease little behaviors out of. And last up the sys admins always looks for the generic solution not the maybe maybe late at night you look for the solution that can make you go back to sleep but in general when looking for stability and long-term and capability generic solutions without lots of special cases are how you're going to get there. So, like I said I went a little bit fast so we got plenty of time Any questions? A comment and a question you were talking about make your library more usable I'd say if you depend on a giant loader to set up all your little pieces maybe some of those pieces should be part of your main gem they should be split out into a separate library so that if they're what appropriate. That is a very excellent point I will repeat it because it's great if you have a giant loader and a large gem that has lots of complicated functionality odds are some of it is at least sort of unrelated so that you can take it apart and packages as separate gems all functionalities available in separate gems Right? He makes a good point Anybody else? Everybody just wants to hear Tenor Love some more


So, hopefully you're all having a good morning. So let me give you a little bit of background on the topic today. I think we're all sort of managing the deployment of applications on a regular basis and the constraints and the pressures that are being put on it are impents, right? The complexities are getting more and more on a regular basis, right, in the SDLC process. If we think about it, things like cycle times are changing on a regular basis. We're being pushed to put out more of the application, pushing it into a get repo, getting it out in the deployment perspective. And in doing so, we've got to balance out a lot of things, right? Got to balance out the deployment times, think about cost, security. We have to constantly make sure that the deployment of that application is efficient. And that pressure is immense, and in a lot of cases, we think about doing some of the checks that we need to do on a regular basis, sometimes pre and post, and I'll be honest, I think a lot of people will take some, cut some corners if we have to, right? And that's just part of the process. It's, there's a lot of pressure these days. But that leads to us spending more time remediating issues, right? And they will occur, potentially post-deployment. And that really kind of takes a little bit of fun out, right? I like to call it the reduction of my mean time to happy hour, right? Not going to have a lot of time to spend it on actually fixing problems. So the concept of shift left is to help you kind of alleviate some of that. And so start thinking about how to make the process a lot more efficient. And specifically in any of those checks, right, there's lots of things we can do around cost, security, performance, et cetera. And today we'll talk specifically about security and the aspects of shifting left with security into the SDLC process. And we'll talk in general really about what that process is like and getting that started, what collaboration means and how to kind of implement that at a business level, right? And today we have a great panel with us.  And we'll start with you, Jeremy, at the end. So, my name is Jeremy. I'm a solution architect at my data model. It's a company that use small data to generate some predictive model. And this model I use for business experts to help them to know and understand their data. What, how I interact with the SDLC. It's at the specification and the implementation. The whole stack, I expect the first one, the input of the SDLC. So, I have a lot of, sorry. With the shifting left, we prevent flows into the production at the early stage. So, it's a big step for us. Sure. Thank you. Hi everyone. Sorry for that. We're all awake now. Okay, let's adjust the levels. Perfect. Hello everyone. Philippe, I'm a distinguished engineer at GitLab for security and security. I joined GitLab with an acquisition. I was the CEO and founder of Gymnasium. So, this is how I got started with security a few years ago. We were acquired by GitLab last year. And this is actually how GitLab started, there are security features. As for the SDLC, we are dog fooding or features at GitLab. We are drinking our own champagne, as I like to say. So, we are living by the SDLC pretty much every day. We are transforming that. We include security as much as we can, especially since some part of security and defense, so I'm pushing that as hard as I can. Yeah, that's it for me. Sorry. Yes. Hello everyone. My name is Sotir Aixima. I work for Goldman Sachs. My job is to run application security activities. But since the organization is going to more fast delivery of asset in production, we found ourselves to be interacting constantly with the engineers which they have, the DevOps or the DevOps engineer of the organization to introduce these tools. So, day-to-day, my job is to push the security part of DevOps. So, we call that DevSecOps. My primary responsibility is to engineer this solution, to make the solution available to the whole organization given the size of Goldman Sachs itself. Thanks, Sotir. Let me give you a little bit of background on also myself and my interaction with SDLC. I lead a developer advocacy team at VMware and we talked to a significant amount of enterprises. And, you know, I think we all think about what the shift left means and there's always this concept and we'll talk about it today of adding the security bits. One of the things that we constantly see is that there's a lot of day-to-based operations that are occurring that just now we're starting to think about getting added in on the security side. And it's not as obvious. It's also a little bit of a surprise when we talk to them about it. So, we're seeing that also when enterprises now as cloud operations and security and DevOps with security is sort of getting combined, right? And I think we have this general notion of shift left as being dev-centric, right? But I think it's more than that. It's also a little bit of cloud ops. But it now starts specifically with, I think, the developers and getting the teams, whether it's security or development or the operations people, to buy in on that, right?  I think it's interesting to understand, you know, how you thought of that and how did you actually get your development teams to start buying in on that because they have to add more bits now, right? And more components into the process. So, I'd love to hear a couple of examples of what you've sort of been through in convincing the developers to kind of go down this path. At the high level of the security, it's quite simple to convince the dev team because if there is some seniority in the team, they use some best practice at the early stage of the designing or at the early stage of the implementation. So it's quite simple to get buy-ins from this. When you go deeper, it's more complex because if you don't have some skills into the team, no one will have the, or will shift naturally through the security into the design stage. So it's quite complex. During a design meeting or a refinement meeting, we have to decide which one will be the paranoid man and raise some questions about security. So it's an everyday exercise for all of us. So it's a process of getting them to buy-in and that process takes some time, right? So speaking of process, I mean, I guess initiating that process is interesting, right? Once you convince them, you talk about some of the benefits and kind of work through that. In the business, I guess, and at Goldman, I think so too, that you've kind of been through this, right? We'd love to hear a little bit about how you have actually initiated that process, what it's been like setting up that kind of that structure and posted convincing and actually getting that moving and what are the hurdles that you've sort of seen, right? Sure, yeah. So that is really a tough problem to solve. You cannot take the organization of the size of Goldman and deploy a static analyzer tools across everyone overnight and you expect next day the process to work. So what we did inside Goldman is to provide an adoption plan. The adoption plan was generated by a core engineering team and by technology risk team, which is my team, and we tried to inject these small scanners, allow me to call that impurely way, small scanners, sass, dust, dependency checking, in family. We call that in family, meaning we deploy inside TechRish or a small group of engineers and we see they are the problem. We see by deploying a static analyzer, we'll see that the developers will have the problems of that, we'll have false positives, we'll have people complaining or we break the DevOps pipeline. As soon we see this problem, we start to figure out how to resolve each of them before we go into higher scale. So from 10 people we go to 100 people, then to 1,000 people and then film-wide. That is the only way that we can see that adoption and the process to working and we do that for each tool. As you can understand, each tool has different characteristics, different output, people receive that differently. And so now you're, how long is that, just curious, how long is that taken and where are you on that process now? You're still moving through it or? I cannot disclose very much information how we're doing Goldman Sachs, but allow me to say in different way that even if we have a product for static analyzer today, after two years we need to engineer again with a new product that is coming in market for new technologies, new tools, et cetera. So I think that is constantly way of adopting the new processes and the new tools that we do regardless if we have something that we call today, Matthew. Sure, yeah, so you're constantly visiting that and then revisiting it, right? Yeah, yeah. So as that process gets started, I think one of the main questions around this is now, how do we go through and actually pick what some of the security components are that we're going to add into that process? So Philippe, I think it would be interesting to get your perspective on this and what do you pick? What are some of the baseline components that actually should be there initially and then what are some options on top of that? Every business is different, right? And everybody's going to pick what they need, but would be great to get some examples from you. Yeah, sure, so first of all, I think that security should be a shared goal between not only the DevOps team, but the DevOps and the security team. And I think that we are still doing security today as we were doing QA 15 years ago. We are doing security on very specific platforms like a staging or a QA environment. And if you think about that, we were doing exactly the same 15 years ago. We didn't have any CI CD by the time and we created that maybe, I don't know, 12 to 15 years ago. And we started there to automate the process. We started to stop relying on the quality team at that point. And we are doing exactly the same mistake today. We are relying on a security team on a different timeline, on a different SDLC loop, the security team has their own loop actually. They are acting on a different timeline. When they have some results, they have to disrupt and to disturb the DevOps teams. So when it comes to components, I would say that automation is the key there. So as Sodi said, starting with very simple things like SAS, that's dependency scanning, everything that would cover the security checks of the code itself and the code that is shipping to production that your team is not especially writing like all the dependencies. That's something that you definitely need to take care of because most of the security issues that we're seeing are not only coming from the code that we are writing but also from the configuration and everything. And I can also mention someone else from Goldman Sachs who told me yesterday and I really love that code. We are one policy away from being public on the S3 buckets. And that's true if you automate and if you have a security team that is able to really have a deep understanding of what you are doing, you are able to scale that security team. And again, automation is the key there. It's the only way to scale the security team so that they can have more time to deal with that kind of issues. Now that's right. I think I mean, adding that automation is important, right? And I think he says something interesting there, which is I think if we think about adding security components as they've kind of evolved SAS and DAST and doing image verification, sort of comes to the top of the mind a lot of times in the CI perspective. But as you indicated, we're sort of going into public cloud on Amazon, Azure, Google and the ability to also double check. And I think things like, hey, do I have my policy set up in S3 or do I have my policy set up correctly for this user? Are there any issues? We got to start thinking about and I think it's not natural right now, but it needs to be, which is to start checking for those types of issues in your environments that are going into public cloud because they're constantly changing and that's kind of in the CD portion of it, right? So it's a, doing the shift left is actually fairly comprehensive on both, I think the CI and the CD piece, right? And so as we add these, and we talked about some of the pressures that are coming in, in ensuring that we have an ability to kind of deliver rapidly, right? Those pressures change the metrics and one of the issues is how do we now with all of these additions ensure that the metrics around actually delivering the applications is consistent, right? And how do we keep that?  With all these new additions. Sure, so metrics, we definitely take the advantage of having centralized systems and DevOps via GitLab, for example, is a centralized tools for us to look in a single place. We think Goldman will have, or at least I have, two specific metrics. One is the effecting of security controls, seeing every pipeline has or not have scanners from my team and therefore to see the output of the scanners. But there is another metrics that the leadership of organization wants to see from my side. We transit from traditional application security, manual activities, manual penetration test code review, which meaning people doing the work, delivering the outputs to more automated things. So how we can take the output of these metrics, the effectiveness of the security controls and to prove to the business how we save money, how we, now that we have DevOps or better say in DevSecOps in this case, how we can do less code review. And specifically when you go to the organization which you have thousands and thousands of developers shipping code every day. And to Goldman Sachs, this is the two key things that I'm looking after, like the effecting of security controls, thanks to the centralized DevOps solution that we have and small engine or scanners outside GitLab that are integrated with GitLab and then how all of these activities that I'm doing actually can be scalable and can save some money from money or time, however someone want to quantify this, from manual activities that previous was doing. We're still doing, but how we transit to that more continuous DevSecOps. Great. I think we've got a few minutes left. Thank you for that. I'm gonna ask one last question. I think we'll open up for questions with the audience. But Jeremy, it'd be interesting to understand, now that you guys have implemented and you're going through this, what are some of the benefits that you're seeing now with the addition of this? Yeah, the big one is less frustration for the dev teams or for the security teams. More synchronized timeline. But the really big one is less frustration. Sorry, Phillip, you will answer that on the benefit side? Yes, actually, the less frustration that Jeremy say that is really key to us, like we deal, like we went from manual activities into automated activities. So if you had one problem before, now we have 10 problems. And this is really difficult for us to manage. So when we deploy a new tool or a new process, we look very carefully what the engineer organization will tell us to take that feedback as the first citizen feedback rather than what we think in isolation as a security team. Thanks. Phillip, yeah? Yeah, I think that I will agree with Sodi and Jeremy. The main benefit that we are seeing is less frustration from the development team. But also we are seeing the security team scaling really with that. With automation, we are catching the longing fruits and that leaves more space in the end for the security team to deal with the very three key cases like authentication problems or that kind of things. So yeah, it's definitely beneficial for us as well. That's great. Well, I want to thank you guys for some of the questions, but I think we've got a probably a minute left or two, so we'd love to hear any questions from the audience. Anybody? We have one there. I'm interested in the topic of security vulnerabilities and open source libraries, which can be quite buried deep within projects. I'm wondered if this has been an issue for any of you and how you've addressed it. Yes, so sometimes we call that dependency checking or software composition analysis. I think every organization should have that capability, specifically if it's using open source. I think everyone currently is using open source if we don't call that, but facing down a library from outside, whatever language is that, you have to check what the world is saying about vulnerabilities within that. So we have tools to do that. We have automated tools to do that. You know more or less the name. I'm not going to name the big players on that. Also GitLab has the security capabilities to do the dependency scanning and Philip can speak more about that. We take that tools and we try to integrate to the DevOps. So there then we expose these findings back to the developers or the engineers, however you want to call them, to fix that directly or to speak then with my team to find a middle ground if something cannot be fixed. Let's say that we have a latest version of that library and has a vulnerability or zero day, which was we don't, no one have a patch, which is the open source path. So then we find a mitigation solution until a new version with a patch is presented. Philip, do you want to add something on that? I think you covered it well. Dependencies are really a big deal today. We are seeing that, for example, at GitLab directly in the source code, we have 100 first level dependencies in GitLab and when we install GitLab, actually we install more than 1000 dependencies. So that means the portion of the code that we are shipping from GitLab is really tiny compared to the portion of code that we are shipping from the third part is that we don't know. We do nothing about them. So we track down with dependency scanning. This is one of the automated tools that we have at GitLab but we also have the security team being very vigilant to any new dependency that we would introduce. So that's why we have something in our process in the merge request directly. We are showing the new dependencies that would be introduced by a change so that very early in the process we can take the decision if we change something in our dependencies' exposure. Anybody else? Do you have manual eyes on every new dependency so you actually look into the source code or do you rely on third party checkers to check that for you? Can you repeat that? I think we had a hard time hearing. Could you repeat that? Sorry, I did not hear your question. So do you actually manually review the code that you're creating a dependency to or do you rely on third party dependency checkers to check it for you? That's a great question. I would chime in if you don't mind. Two different things. If it's a very regular dependencies I would say we rely on the tools that we have. So it's basically matching the version of the dependency that we're using with our databases. We have a public database of adversaries for all the dependencies in many various languages but when it comes to something very sensible like authentication or that kind of things then we like to have the security team being involved to review the code, review the dependency, review. If the dependency is still maintained, the algorithms, everything related to cryptography and we can just rely on the visitors for that. We need to have a deep understanding of what's going on there because that code again is going to ship to production with our code and running there. Thank you. Thank you. We're out of time but I wanna thank the panel here for the answers and we'll be around for some questions after this. Thank you. Thank you. Thank you. Thank you. Thank you.


We're here with James Markarian, who's the executive VP at Informatica, welcome. Thanks for coming on the queue. Hi, thanks for having me, guys. You are non-stop, very impressive. Oh, this is the beginning. This is the beginning. All right, talk to us tomorrow at 4 p.m., but... This is going to be a walk in the park. Yeah, so this is, let's see, the third Hadoop world. Now, you guys were probably here in some way, shape, or form last year, but you didn't have a big presence at the event, right? Right, that's right. So this is your first year sponsoring, is that correct? That's correct, that's correct.  Tell us about, you know, what's that all about? What's going on there with Informatica? Great, thanks. So first of all, it's always very scary to me when people talk about us as a 20-year-old company because I remember when we first started out, when I first joined about 13 years ago, we were this tiny little... I remember that too. Yeah, we were a tiny little nothing that nobody asked about for advice about anything, and now we have all these customers coming to us saying, hey, what should we do about Hadoop and what can Informatica do for us? So this new world of unstructured data processing is pretty interesting and new, and I think we saw some statistics in the keynote the other day this morning that said that a lot of the instances that we're seeing with Hadoop aren't necessarily terribly large, but what they're doing are interesting new things with unstructured information. We have customers that are doing things with social media and lots of blog information, and it wasn't necessarily that you couldn't do these types of things in traditional data warehousing environments or traditional database environments, but it just was either economically infeasible or it was actually just plain difficult to get the types of analytics built that you wanted to. So we think Hadoop is both about big data, of course, but also exciting for unstructured data. So you've made some announcements leading up to the event. I know H-Parsar was one of the announcements we wrote about it. Was that your first foray into this whole Hadoop space? Talk about that a little bit. Yeah, we've been doing a few things around Hadoop. The H-Parsar was only the most recent announcement that we've had in the Hadoop space. We do have some other components that are out there. H-Parsar is kind of an especially cool thing, though, in my view. A lot of what we see happening. Two ETL geeks out there. Yeah. Well, let me give you a chance to be convinced. So what we're seeing on Hadoop, of course, is a lot of processing of unstructured information. And what we're seeing from the developer side is people are writing a lot of hand code, which is very inefficient. Not only the first time you do it, but it's difficult to maintain, difficult to keep up with the changes that are happening in all the different formats, whether it's Omniture logs, JSON formats, XML documents, Swift, HIPAA documents, anything you can think of. And so what this H-Parsar technology allows you to do is really quickly tease apart the different components of these unstructured documents into the components that you want to analyze. And you can access this functionality from Hive, from PIG, and from MapReduce. So it's very quick to deploy, very fast-executing component, and really cuts down the time-to-value for Hadoop. So that is kind of cool. And that's a new territory for you guys. You come from the structured legacy. So talk about what's different in unstructured land and why you have credibility there. Well, I guess those are maybe two different questions. But I'd say unstructured has been around with us for a while. It's getting a lot of attention now. But as Informatica for a long time has been helping customers, like you heard, both Morgan Stanley and more recently, JP Morgan Chase with Larry Feinsmith, we've been helping them handle the processing of their various document formats. Swift processing, Excel spreadsheets, Word documents. So we're just taking some of that same expertise and bringing it to Hadoop. Was it 30,000 databases? Is that what it's? Yeah, that's right. It's a good time to be Informatica when you have customers out there with those sorts of footprints. Yeah, so we're just taking the expertise that we built up in the sort of non-Hadoop world, even around unstructured and bringing it to Hadoop. But I think what's interesting about Hadoop is you're seeing the real economics of information changing. And so we have customers that are doing things like mining their social media influence networks to drive business value. We're seeing customers that are mining things like their survey verbatims, seeing their mine sites like Yelp and Travelocity for feedback on their hotel experiences. And the interesting thing is that a lot of these problems combine unstructured processing with transaction processing because you wanna know who you should really be paying attention to. So I might post some random tweet about something. Should the company that I'm tweeting about actually care what I have to say about it? Did I actually stay at that property? Am I just retweeting effectively something that somebody told me that's not really verifiable? But when you can correlate unstructured information with an actual hotel stay and maybe even an actual hotel room, you bring those two worlds together and then you have really actionable information. That's what Informatica's helping us with. I moderated a panel with EMC down in the Bay Area, talked about big data and just kind of a business crowd. And you guys were on the panel and someone from Informatica, CTO was there. And the conversation was interesting because you had a lot of business people in the world in the room who Hadoop was new to them. So my question is a little bit more of kind of philosophical one. And Mike Olson talked about, this is not about just one island, right? And that Hadoop is not a unification kind of business model where everyone's going to unify. You guys are actually having a huge presence in the market. What are you seeing out there in the legacy side of it that's changing specifically? Because you guys have that business there. What's going on there? How do you see that? Well, I think, first of all, a lot of customers have questions about how Hadoop fits in with everything. And to some extent, my comment about Hadoop is it has to declare its major for really everyone to understand it because you even heard today there's guys that are focusing on the H base side. There are guys that are focusing on the analytics side. So is it a transaction processing system? Like some of the guys we're implying is it a purely analytics environment? So Informatica is really kind of seeing this like everyone evolve. I think that the most natural cases right now are around the analytics. They're not really a substitute for other things that are going on. We're seeing it as a complement to existing analytic environments. Hadoop doesn't yet support the full range of SLAs that you see with some of these traditional analytic environments, but it seems like it's getting there. So I think it's just early days with Hadoop and I'd say that a lot of the people that I talked to at the conference are still just trying to figure out what it is, what it means to them and where it fits in with their IT landscape. Maybe a major in analytics with a minor in transaction processing is that your sort of vision for the future? How do you see that shaping up? Well, I think that, you know, I wouldn't want to presuppose anything about Hadoop right now. I think that it kind of looks that way now. I think that there's nothing but green space or green field ahead of Hadoop. Yeah, very smart guys working on it. Yeah, I think when you look at how Hadoop got started, some of the early papers that came out of both Google and Amazon. Now, it reminded me a lot of how relational databases got really kick-started. So like back in the 70s, cotton date, write a paper, Larry Ellison and Bob Minor read the paper and it's like, hey, I'm reading about the future here. And when you read the seminal papers around Hadoop and MapReduce, it's like, hey, you get a feeling like you're really glimpsing the future of something. And I think like we didn't know exactly how relational databases would evolve at that point, you know, it's a little bit early to tell where Hadoop is going. I think it's going to have a healthy footprint in both transactions.  I mean, they're going to need the Moscone center next.  I mean, and it's not just geeks too. There's business people here, right? So you mentioned SLA. I mean, you have a lot of experience dealing with SLA. I mean, what are the key factors in the SLA kind of component of this that you're keeping an eye on that you guys are watching and developing? Yeah, there's a whole spectrum of things in the SLA that we care about, right? So you even heard Larry this morning in the keynote talk about some uptime and stability concerns. Like, there's some very basic elements of the SLA, like if the system's not available, or if you have to worry about data corruptions. Yeah, that's sort of telling you that we're in an early stage in the market. And also, like you have to start thinking about, well, how business critical is that information if there's some degree of tolerance for those sorts of outages? Then if you go all the way to the other end and talk about from an analyst's perspective, and you think about everything that went into OLAP processing. So relational provided analytics, but it wasn't good enough for a lot of business analysts. They couldn't slice and dice quickly enough. Couldn't really satisfy their fast twitch need for information. And Hadoop, again, is really good at relatively high latency, high scale analytics, but isn't necessarily an environment where this writing on top of vanilla Hadoop, you'd want to sit there and slice and dice information. And that's why we're seeing a lot of the tools build up to build effectively caching and other things on top of Hadoop to provide that sort of SLA for their users. And bring some structure to that Wild West. How about your relationship with Cloud Era? What is, what's going on there? And can you talk about that a little bit? Yeah, sure. So we have a partnership with Cloud Era that was announced several months ago. We have a certified integration with Cloud Era. We have a connector to HDFS, and are gonna be coming out with a connector to HBase, of course. And so we are seeing kind of where things go. And what you see with Hadoop is, it's this kind of big powerful engine, but despite Mike's comments, data doesn't originate in Hadoop. In a lot of cases, data doesn't terminate in Hadoop. And so Hadoop is just like one of many happy stops along the way for data. And Informatica wants to be a part of that process, getting data in and out of Hadoop. And also, you heard about the skills shortages around MapReduce. Everyone had their hiring pitch at the talks this morning. And what we're seeing from our customers is, hey, we don't necessarily want a whole army of MapReduce programmers. We have people that know Informatica. We have people that know SQL. Can they leverage those skills and have that actually be effectively our programming environment for our Hadoop environment? And so our answer to that has to be yes. Talk a little bit about that data origination comments that you made, because you mean data originates in devices and machines, and is that what you're talking about? Yeah, yeah, that's right. So where is data first transacted, right? So just for an example, since we're here a little bit north of the Occupy Wall Street movement, which also does some financial transactions down there, so we have customers that do things like if you look at our messaging business and ultra low latency messaging, we have customers that are transacting at the sub-microsecond level, right? So you have trades that go in and are measured in nanoseconds nowadays, not even microseconds. Those transactions happen very, very fast. They're originated in very high performance, trade execution systems, and then they're actually shipped out to analytics environments like Teradata and like Hadoop. So that data is, it's gonna be a very long time before that data gets originated in something like Hadoop. Like you can't have stability questions when you're taking down a billion trades a second, like in some cases. So that's like one tip of the iceberg. So that's what I talk about when I'm talking about where data really starts. Yeah, yeah, yeah. I mean, is the Kumbaya big data we're here, we've called this Hadoop world, the Burning Man of big data. It's an organic community, it's growing, but the reality is these big businesses are running massively scaled environments. So that's what you're referring to, right? I mean, this is like- Yeah, that's right. Both on the transaction side and also on the analytics side. And it took a lot of time for a lot of smart people to build up transaction environments that could handle those types of volumes. I think it's always tempting to treat, there are forefathers as idiots, like, you know, what were those guys doing is so much easier now, but there's actually something, you know, pretty good technology behind that. This is what's interesting about Hadoop is that the use cases are so diverse, you don't really need to have one unified anything anymore. You could have specific Hadoop instances deployed in those use cases as applicable. Yeah, that's right. And I think also that just the appetite in IT for niche solutions for specific, you know, either persistence or analytics problems is so much higher than it was just a few years ago where you could do anything you wanted a few years ago as long as it was in an Oracle database. And now with the NoSQL movement, with the Hadoop movement, you're seeing, you know, this sort of indifference really to like, you know, brand name, persistent stores and the problems are so big and diverse now that people just want great technology solutions. Yeah, purpose-built. Yeah, yeah, that's the technology. It's not as, it doesn't feel anyway as incremental. I mean, there's some pretty radical things going on and companies are looking around saying, well, I better hop in or I'm going to lose competitive advantage. I mean, the numbers that JP Morgan and Chase showed today were pretty impressive in terms of cost savings and business advantage that they're driving. That's right. And so, and I think that, you know, ultimately have to think about the business drivers behind all of it. So, to some extent, IT is in a position where they have to innovate, they have to take chances, they have to apply the latest technologies if they're going to keep up with the pace of change in the industry. You know, as soon as like Lehman failed, you know, the questions that Larry brought up, like, what's our customer's exposure to Greece, for example, those are questions that are super hard to answer when you think about all the indirect ways in which financial instruments are linked together. And so, they simply have to innovate in order to be able to answer those questions, respond to their board, respond to their shareholders about what their exposure really is. You know, there's a lot of talk about, and I'd love to get your take on this, James, even though it might not be, well, it's related, but not central to what you guys are doing. There's a lot of talk about making it easier for business people to use Hadoop. And we're clearly not there yet, despite what some of the rhetoric is. So, what are your thoughts there and how important in that, how likely is that? Is that a reality in your view in the next, you know, five or seven years? Well, I think one of the principles behind Hadoop, you know, we've had MPP computing for a very long time, but it's always been like the true, like not only the geeks, but the geeks among geeks that have been able to harness the power of, you know, Cray machines or the connection machine back in the day. And it was like this big machine. Yeah, that's right. There was Danny Hillis, that's right. Where is he now? He's probably saying, hey, that was my idea. So, you know, now, you know, the thing that's really interesting about Hadoop is it's sort of putting a lot of compute power in lots of people's hands. So, it's kind of like a democratization of high power computing. And so, I think that there is always going to be this push to move that power higher up in the stack. And to the extent that technologies like, or languages like MapReduce and Pig and Hive, you know, simplify that, I think that's important, but it's not really going to be until, you know, I think like Datamir, for example, is an excellent way to do that. Because what all the business people want to use at the end of the day, they just want a spreadsheet. You have this nice spreadsheet on top of, you know, this 1000 node Hadoop cluster, and you can start getting real-time information across massive amounts of information. I think that's getting us close. The business user's always kind of an elusive thing. Everyone's been talking about this. Like, you know, I guess the question you would end up asking is, have we even solved that, you know, in the traditional BI world? There's certainly companies like ClickTech and Tableau that are saying, you know, no, we haven't. And I think, you know, we're a pretty long way from that happening in Hadoop as well. My last question, James, relates to the whole competitive environment. Last year it was, you know, one horse race, and now you're seeing some choices come about. What are you guys seeing there? What's your take on the whole, you know, Hortonworks enters, you got EMC and MapR doing their thing, and what's your angle on that? I'd be really, really concerned about the Hadoop community if that wasn't happening. You know, if you had one vendor that was the only champion for it, you know, I think that you'd have to look at it as an IT buyer and say, that looks really risky to me.  Well, IBM didn't exactly spring up, but, you know, they were there, Oracle, Informix, Ingress, Sybase, you know, many billion-dollar-plus companies were built around, you know, one very good idea. It was actually very good for the ecosystem. They all pushed each other. They made SQL better. They gave IT buyers confidence that this is a trend that's gonna be here to stay. Even if this company doesn't succeed, I have a standards-based solution. I can migrate my applications over to something else that, you know, will be there, and I think it's a really, really good sign for Hadoop. Great, my final question, that was a great comment, by the way. I think that's right on the money. My final question is we were talking with Kirk Dunn about the concept of cloud-washing, which everyone's been talking about, it's that cloud on it. Is there a Hadoop? We haven't heard that word Hadoop-washing yet, but, you know, it's getting to the point now where it's so frothy, VCs are putting up $100 million, clients are hearing about big data, you know, from all the, out in the external world.  What would we look for? I mean, is that even existing, or is it just so diverse? Yeah, that's a good question. I hadn't really quite considered that.  I think that the Hadoop value proposition makes it itself inevitable. I don't know if everyone's gonna be adding like H onto everything the way they add, you know, like I or this or that for cloud. I think that the thing that you would always look at is, is there a discernible customer business value that's been delivered for whatever, you know, the company is trying to convince you, you know, it has Hadoop applicability. If there's customer value, then it looks, you know, it looks and sounds legit. If there's not that discernible customer value, I think you do have to, you know, wonder whether this is just kind of marketing or whether it's something real. All right, James Mark-Harrion, thanks very much from Informatica for coming on theCUBE. Great story, great guest. Appreciate you taking time out with us. Great.


So we have this particular meeting, which every Tuesday at 8am, we have every other week We have an Asia friendly call and it doesn't look like we have Nikolai on to discuss. Was anyone on that call earlier today? Yeah, yeah, but it was nothing really important discussed actually, just current situation. Okay, cool. We also participate in the CNCF telecom user group, which occurs every first Monday at 8am Pacific and every third Monday at 3am Pacific. And we also participate participate in the CNCF SIG network, which was currently rebooted and occurs every first and third Thursday of the month at 11am Pacific. We also have had a few major events that have been canceled or postponed. So the go San Francisco, which was supposed to be tomorrow has been postponed until after the COVID-19 problem is abated. The same thing goes for KubeCon, CognitiveCon, New Europe and Amsterdam and NSMCon. So the plan, my understanding is the plan is to still hold an NSMCon. It's just going to be dependent on the new date. Oh, NES has also been postponed. I believe they're going to run it sometime in August is the planned time. We don't have a exact date for that yet either at this point. KubeCon, CognitiveCon, China has been canceled. I do not think they plan to run one this year at all. And so with that, the next set of major events, barring any major issues are going to be the re-negotiated dates for KubeCon, Amsterdam, which will probably happen in August or September. Then we have ONES Europe, which will be in in late September, and then KubeCon and CognitiveCon North America in Boston, which occurs in November. And the CFP for ONES Europe and cloud-native in KubeCon Boston, I believe. Well, sorry. Well, the first one is the CFP is open. The second one, the KubeCon Boston, the CFP is open in April 22nd. And so with that, we have a, as a reminder, we have a project board that we've been tracking things with. So if you'd like to know what's going on or want to know where to get started, please check out the tracking board. And we also see we've already gone over the NSMCon announcement. And so with that, sorry, my system is lagging a little bit. Rather, my documents just crashed. Cool. And we now have an NSM operator, which is hitting the community operators repo. And do we have anyone on the call who has worked on the operator by any chance? Yes, it's me. Hello, everyone. Cool. So, yeah, so was a repo created for you and was that added on or does that? The repo actually is a community repo. So you will find like dozens of operators there. So it's actually will host the NSM operator for OpenShift and also for Kubernetes. And then using your pretty life cycle manager, you can install directly from that repo. So as of now, if you just install an OpenShift cluster, you will see an SM operator on the OpenShift for example. And Kubernetes is on its way. It's already has a PR there. So it should merge by this week as well. Oh, fantastic. So I apologize. I misunderstood. No, that's fantastic. It's getting on to the, this is for operator hub website, right? Yeah, that's it. That's it. If you want to, I can talk a little bit later if you want about it. Cool. And yeah, one thing we need to do is we need to set up that repo for you to push on, push things onto it. So I'll work on that setup thing. Yes, sure. No problem. Cool. So social media, media community team is doing a written update this time. So I'll cover their account unless someone else from football would like to. Okay. So we have some Twitter stats on as of today, we have a 726 followers, so we've added six more. We followed six more. We have added nine more tweets for a total of 1,122. And we've posted information on NSM con and call reminder CNCF weekly webinars and news about CNCF joining Google summer camp of summer camp of 2020. And we've also posted information about LF AI on an ex community virtual. And we also have the information on VMware's open source projects, trending on GitHub. In LinkedIn, we now have 141 followers. And we increase a follower post the same information is on Twitter. Information on NSM con 2020 and similar have been postponed for the moment. Right now we have an empty agenda. Is there anything that anyone would like to discuss? Well, Frederick, if I may, I would like just to explain a little bit about that community repo. And it's really quick. We have two repos. One is the NSM operator repo where you can find the operator itself and the community operators repo just it just holds metadata about the operator. And then with that it is possible to build a hub and to pull the images from the proper repositories and run the operator on the platforms. So if in the near future, we were to move from my private or not private but public repo personal public repo, where the NSM operator is to under the NSM org. This is not a problem because this is the operator itself the bundle that the metadata that is hosted by the community operators repo is to work to the same it is remains the same. And each and every version of the operator will generate a bundle with a metadata that will come into that community operators repo. The cool thing about that is that you will have it available on the operators hub. Both an open shift and Kubernetes if you have an operator lifecycle manager powered Kubernetes platform. That's it. Okay, nice. Yeah, so we'll work on getting that, like good repo up and running. And so in terms of the, so in terms of the repo. How does this thing is similar to Docker hub so like creating a commit against a branch or against master does it automatically update the hub. You mean the the image itself or or the source code. So it's based upon the it's based upon the image and the latest on there right. Yeah, yeah, I actually have also a personal query repo where the image is hosted. And I have source code on a GitHub repo. And the GitHub repo this is kind of confused that it is a GitHub repo that is called the community operators. There we have just metadata the metadata is just saying hey, here we have an operator that does this this this and that's and we have the path for those images so we know how to install it. It's kind of metadata repo only. And one on the image side is it isn't quay.io. It's just like a public image repo. Nothing, nothing special about that. And the code itself is the one I'm eager to kind of move to under the NSM org. And the other two, it doesn't matter if we keep a quay that I always should be like a repo under also than the NSM org, or we can just change the repo for that particular image to something that NSM is already using. Okay, nice. Well, thank you for the, thank you for the quick description on that. You're welcome. Are there any other topics that people would like to to discuss. Okay, if not, we can break earlier this particular week and we can and we'll reconvene next week and we should have Ed back and the scenario will go over all of the variety of updates that we have for ran SM. So thank you everyone for your time and we will see you all again at the same time next week. Thank you. Take care.


For example, in a city like Stockholm, where most people use water-closer toilets, these make use of water that is of drinking water quality standard. So one could actually say that we are shitting in our drinking water. And that might not be a big problem in a city like Stockholm where there is sufficient water resources for the entire population, but in many other parts of the world, these challenges related to water scarcity. And so that's a problem if you have a system that is not utilizing the available water resources in an optimal way. So I think World Toilet Day is an opportunity for us not only to think about how to increase access to safely manage sanitation for those people that do not have access to that right now, but also to think about how we can tweet existing systems, the infrastructure that we have for sanitation in all other parts of the world in such a way that they can not only meet the demands for public health, but also the concerns about environment and the conservation of natural resources.


Hello, from the National Archives Public Programs and Education staff. My name is Sarah Lyons Davis, and I'm an education specialist at the National Archives. Welcome to the National Archives Comes Alive Young Learners Program. Today, we meet Eleanor Roosevelt, humanitarian, civil rights advocate, and the longest-serving First Lady of the United States. Eleanor Roosevelt also made history as a co-creator and delegate to the United Nations. Her work and influence on our nation serves as an extraordinary role model for all Americans. Eleanor Roosevelt is portrayed by Renee Goodwin of the American Historical Theater. The National Archives has many records related to Eleanor Roosevelt. On this slide, for our education-specific resource Docs Teach, you can see an educational activity for Eleanor Roosevelt when she was First Lady. She was married to President Franklin Delano Roosevelt during his Four Terms as President from 1933 to 1945. As First Lady, she traveled the nation and wrote about her travels and adventures in her daily column called My Day. In this 1939 column, she writes about resigning from the Daughters of the American Revolution. In January 1939, the Daughters of the American Revolution denied Howard University's petition to use Constitution Hall for performance by Marian Anderson. On February 26, 1939, First Lady Eleanor Roosevelt submitted her letter of resignation to the DAR President, declaring that the DAR had an opportunity to lead in an enlightened way but had failed to do so. The following day, Mrs. Roosevelt addressed the issue in her My Day column published in newspapers across the country. Without mentioning the DAR or Anderson by name, Eleanor couched her decision in terms everyone could understand, whether one should resign from an organization you disagree with or remain and try to change it from within. Mrs. Roosevelt told her readers that in this situation, to remain as a member implies approval of that action, therefore I am resigning. On April 9, Marian Anderson performed at the Lincoln Memorial. The Easter Sunday event was attended by tens of thousands of fans, and the radio broadcast allowed for millions more to celebrate Anderson's talent and performance. The concert was seen as an early victory in the battle for civil rights. This column and others like it can be found in the Anna Eleanor Roosevelt papers at the Franklin D. Roosevelt Library in Hyde Park, New York. The National Archives has a number of records of Mrs. Roosevelt's dedication and contributions to the United States. Here is a photo of her meeting with Girl Scouts in Lexington, Kentucky in 1934 and meeting with a soldier wounded during World War II in 1943. With her many contributions as First Lady, Eleanor Roosevelt considered her role in creating the United Nations Universal Declaration of Human Rights for greatest achievement. After she left the White House, she focused her energy on work for the United Nations and on President Kennedy's commission on the status of women. In this 1949 photograph taken at the temporary home of the United Nations in Lake Success, New York, you can see her holding the Universal Declaration of Human Rights. And here is a photo of her meeting with President Kennedy in 1962 in support of the President's commission on the status of women in the Oval Office at the White House. She established the President's commission on the status of women through executive order in December 1961. Our programs are brought to you from the National Archives Public Programs and Education Team and the National Archives Foundation. You can find information for free teacher and student programs on the National Archives website, archives.gov, under Archives News, upcoming events, and if you follow the National Archives on social media. So now, let's give a warm welcome to Eleanor Roosevelt. Well, I thank you so much for your kindness and your generous words. I'm so delighted to see that you could come and visit with me today. I always like meeting new people and getting to know about them and letting them know about some of the things that I've experienced. Sometimes I get asked a number of questions and some of the questions are often repeated by other people many times. For example, one of the questions I'm frequently asked, particularly by the younger set, is, did you like school? Well, I know that can sometimes be a controversial subject, but for me, it was not so difficult to answer. You see, after my mother passed away, I had education mostly by tutoring, and I didn't go to formal school until I was living with my grandmother, and I was age 15. And then I was sent off to the Allenswood School for Girls, particularly since my aunt requested that I do that and thought it would be very good for me. And she was so correct. It was a wonderful experience. The headmistress was a woman by the name of Mademoiselle Marie Syvestri. She was quite remarkable. She knew almost everything, and she enjoyed everything. I am fortunate to say that I soon became one of her favorites, and that gave me great privilege to travel with her when she went on various trips. It was interesting in a number of ways, one because I would learn things about places I had only read of, and also because she would take me to places that were not always the kind of places the tourists would go. You see, she wanted me not just to learn about the places, but about the people, about the culture, and see the good things, the way they were living, the gifts they had like many of us have enjoyed, but also to see the challenges. My three years at Allenswood was perhaps the most wonderful time of my life. I was quite sad to see it end. I had made so many wonderful friends that most of whom I kept for the rest of my life. When I finished Allenswood, I returned to New York and had a wonderful coming out party. My grandmother gave me a glorious party at the Waldorf Astoria, lots of pomp and circumstance as they say, but it really wasn't the kind of thing I enjoyed tremendously. So I fulfilled my social obligations, of course, but I decided I wanted to do something more, and so I became a member of the Junior League, and I started to learn that there were things that I could do to make an impact, to make a real effect on the lives of people. One of those things was to teach dancing at the Rimmington Street Settlement House. Oh my, how I enjoyed that, since I've always loved to dance. It was a long about that time that I became reacquainted with someone that I had met quite some time before. His name was Franklin, Franklin Delano Roosevelt. We spent a great deal of time together, and we soon became great friends. But I think I also began to realize that I was becoming quite fond of Franklin. We had a lot of things in common, and I realized that we cared about similar things, the great deal, about opportunities for people, how to improve their lot, the quality of their life, since we were so blessed and had so much. The relationship continued to grow, and eventually he proposed, and we were to be married. I was so surprised. I never thought that he would choose me to marry me. I was very excited. And again, there was a lovely wedding party in New York at my aunt's house. It was a small private reception, but quite lovely, you see. Now it happened to be on St. Patrick's Day, and it was the day of the St. Patrick's Day Parade, where my uncle, the president, was there to give me away. I was pleased that it was on St. Patrick's Day. It added a certain excitement to it. But what did happen was just at that very tender moment when Franklin and I were to exchange our wedding bows, they went marching by the window beneath us, a great large group of men from the Hibernians singing a grand old Irish song with great gusto. Why, I don't think we hurt each other, so no one else in the room hurt us. And then right after the ceremony, Franklin and I were prepared to receive the good wishes from all of our guests. However, Franklin, or rather Uncle Ted, who had had a very busy day, decided he wanted to go and have some refreshments. And when he went into the area where the refreshments were being served, every single guest at the wedding followed him, and we just stood there utterly alone. But nevertheless, it was a wonderful day, and I was so much in love with him. For our honeymoon, we waited until he finished school, and then we traveled extensively that summer throughout Europe. It was a very interesting and educated honeymoon. I enjoyed it a great deal. When we came back, it became soon very clear to me that Franklin had great desire to be in public life, to be a politician. I was not exactly excited about that prospect, but I knew Franklin was very serious and very committed about doing some very good work in this country. So absolutely, I supported him to the best of my ability. When he was elected as the New York State Senator, it really was my full introduction to many people who were working in various phases of politics. I was rather naive at the time, but I did my best to learn. Now one of the requirements is to do proper socializing with certain people. I remember on one particular day, we had invited a number of this group of politicians, let's call them, and they were invited to our house for lunch. Well, it was a big deal for me, particularly since I realized too late that it was Cook's Day off. What could I do? I certainly couldn't be rude and turn them away, so I did the only thing I could do. I took them into the dining room, I got out our chafing dish, and I made them scrambled eggs. Well, they seemed to like it and the day wasn't a failure. It actually went very well. When Franklin was about to run for a second term, he became very ill with typhoid fever.  Louis became just so important to us. He supported both of us. He of course adored Franklin, believed in him, heart and soul, but I also needed educating in how to make presentations, how to speak so that my voice wasn't so dreadfully high that it would be irritating. Hard to imagine that's what it was, but it was. But Louis stood by us all the way and supported Franklin, and he was elected again, and then he was appointed as Assistant Secretary of the Navy, a position he valued very greatly. Time was moving on, and I could see that Franklin's goals and Franklin's desire and energy wanted much more than where he was, and so he ran for the seat of governorship of the state of New York. It was about then that he became very, very ill with polio. We did as much as we could to conceal his condition, and Louis was very instrumental in that. I remember one of the things we had to do was to build an elevator in the House at Hyde Park, and on the elevator, Franklin would help himself get into the chair, and using ropes, he would pull himself up to the second floor. In spite of all that, he did very well, and people seemed to love him a great deal. Meanwhile, while Franklin was ill, I continued to work and learn more, and I traveled around to many locales to take the temperature of the people, what was that they felt was needed for them, education and housing and jobs. After all, times were not as easy as they were for us, for many people. They were struggling a great deal. Franklin was very sensitive to that, and he wanted to help them a great deal. I soon realized that Franklin had even bigger goals in mind. He did run for the position of vice president, but the campaign was lost to another party, so he never did get to be vice president. But that was just as well, because he used some of that time while still recovering from polio to create a facility for others who had conditions like his own. It was in Georgia, in Warm Springs, Georgia, and he devoted a great deal of his time there to give opportunities for people so that they could learn how to use their body and their mind as well. All along, he was grooming himself for higher destiny, which I still was not certain how I felt about it, but as long as it was important to Franklin, I thought we should do that. I thought school was very important, and for a time I actually taught school. I enjoyed that very much, but it got to a point where it was too much for me to do and somehow not appropriate while Franklin was climbing the political ladder. He began building a cadre of friends and politicians who began to see Franklin's political potential. Meanwhile, I didn't mention that I had five children to raise, and that was quite a chore as well. Of course, my mother-in-law was very much a help most of the time. Sometimes she would be a little overbearing, but very kind, always kind, always very generous, and we were always grateful to her for everything that she did for us. She wanted Franklin to succeed. She saw that he struggled with his physical condition, and there were times when he would meet with others, and one of my sons would help him stand up. He never wanted to look like he was a weakling. He always wanted to put his best foot forward, and he always managed to do that with the help of his own perseverance and the help of God and the help of his family, particularly his mother and of Louis Howe. So we were moving along quite well, and I think he finally got to the point where he realized he had to set his sights on being the President of the United States. I was very concerned about that. It's a very difficult job. It's a difficult job for someone with good health, let alone someone like Franklin who had many medical conditions.  I think that began after World War I started. I think he saw that there were going to be international problems for him to deal with. And one of the things we talked about was should women run for office? Well, there were very much opposing opinions on that, but I thought that women could run for office. I thought they could do very well. You see, men have a set of particular talents, and women also have particular talents. I mean, men are strong and determined and oftentimes have very analytical minds, but women are also strong in their own right. And they have characteristics. I mean, after all, they are compassionate. They bring us into the future by giving birth to children and raising them. And they're very adaptable to different situations. After all, they've adapted to men that is not always an easy task. So I think that it is important that women also run for office. And I don't know what your thoughts are. Why don't you share some of your thoughts with me so we can answer your questions? Do you have any questions for me? Thank you so much, Mrs. Roosevelt. It was so interesting to hear what you shared with us. If you have a few extra moments, I do have a question for you. Of course I do. So you mentioned the instance of having company over and making eggs. Is that your favorite recipe or do you have others? Well, it's sort of become my favorite recipe for quite a while, mainly because I never really learned how to cook. It was much later in life that as we were doing more socializing and even though we had help, that I finally learned how to prepare some other things. And I think that was good. But I guess I will always think of scrambled eggs as my first venture into cooking. That's great. And so you mentioned about different contributions you made and your husband made towards the country. How do you think all Americans can make a contribution to their country? First of all, I think that's an excellent question. And I think it's imperative that all Americans make a contribution. It can be done so in many ways. It doesn't necessarily have to be grandiose, although if you choose to run for office, I support you and I applaud you if you decide to go into higher education so that others can learn things. I also applaud you because good teachers are the backbone of this country. But there are other ways, simple ways, helping a neighbor, helping a friend, helping your own family, learning as much as you can about the other cultures and other ethnic groups that may live in your city or your town. Understanding is critical to getting the best out of life for all of us. We must support each other because we are all going through similar difficult times. And when there are challenges to democracy and to our freedom, we must stand tall and support each other and become allies and friends rather than enemies. So it doesn't take massive attempts, huge attempts or kind of attempts that are on the front page of a newspaper. I think simple ways. Sometimes you may belong to a settlement house. For example, when I taught dance at the Ribbington Street Settlement House, that brought joy to those children and it introduced them to an art form or to things they might not have ever learned. So there are ways to do that. There's also going to schools as you get a little older and reading to them, reading books to them that they might not learn in school. They might not choose or they might not have in a library at home, an extensive library. There are so many ways. The important thing is to believe in yourself, to believe in the others, to think that. I once heard a saying that said, if you have the opportunity to be right or to be kind, choose kindness because then you will always be right. I try to remember that and I try to be kind and help people. I hope you will do that too and set examples for others. I'm so pleased to meet you today. I hope to see you and hear you again and we can talk of so many other things and we'll see what happens. Does Franklin make it to be President of the United States? Well, the way things are going now, I suspect he will succeed but time will tell. In the meantime, I just want to say to you, thank you so much. Thank you for following a good example of your parents and of others. God bless you and God bless the United States of America. Well, thank you so much, Mrs. Roosevelt. You've touched on this a bit already, but this is our final question that we ask of all of our speakers and it's our final question for you for today. What advice do you, as Eleanor Roosevelt, have for young people today? Be grateful, show gratitude, be kind, and never underestimate your ability. It's amazing what you can accomplish once you put your mind to it. In fact, there's another saying, don't wish for it, work for it. Choose an area that you find appealing. Do what you enjoy. Love your work, but share it with others because it makes a difference. People learn from one another, not just with your nose and a book. We learn from each other. We learn from traveling. We learn from experiences. So always believe in yourself because you live in America. You have every opportunity that anyone could have on this planet. Do your best and be grateful. Thank you. What wonderful advice and thank you again for spending some time with us today and sharing your story and all of this great advice with us. And now one last look at the Docs teach educational activity related to Eleanor Roosevelt and her creation of the United Nations Universal Declaration of Human Rights. I hope you can join next month for our Young Learners program with Ruth Patrick, botanist, limnologist, and recipient of the National Medal of Science. Thank you for participating in our program today.