I guess we'll go ahead and get started. It's 1050, welcome. This is the code-free developer interview. My name is Pete Holliday. You can find me on Twitter as at too much Pete. Feel free to tweet at me during the presentation. I'm sure I'll get the notifications up here and we can have a nice little conversation while the talk is going on. I'm currently a software engineering manager at CallRail. CallRail is a company in Atlanta, Georgia. We make a call tracking analytics platform. And CallRail is one of the companies that I've used these particular techniques at and have a lot of success and had a lot of success with. We've hired, over the years I've hired dozens of engineers using these techniques without having ever seen a single line of code from them before they started. So my goal for this session is, it's a very humble goal, it's a very modest goal, and that is to eradicate all coding interviews. So, thanks Jennifer. But no really, I'm kind of kidding. A more realistic goal is to convince you today that there's a better way to evaluate your potential engineering candidates than making them code for you. But I guess before we get into the meat of it, what even is a coding interview? My definition is a coding interview is any interview practice that requires you to see code that your candidate actually wrote. So, reviewing their code samples are GitHub profiles, which is probably one of the most boring things that I've ever done as a hiring manager.  And live coding or pair programming, those can be incredibly stressful, even for people who don't normally have anxiety issues. But these aren't the only things that you can do that I would classify as a coding interview. It's really anything that relies on seeing code a candidate has written to make an evaluation about their fit for your company. So, why do we do these in the first place? Why do we have this whole list of things? And it's because they're replacing some less great interview techniques. So, whiteboarding, the thing we all know and love.  I'm really not sure why anybody ever thought that would be a good idea for an interviewing question, but people have used it, so. And then language trivia, like, what's the difference between a subclass and an interface? And the reason that these are generally not great is because they're bad. They don't tell you what, they don't have a good ability to predict whether a software engineer is gonna do a good job at your company. They don't really map very well. So that tells us what we came from, but why are we here? Whoops, what is, why interview with code in the first place? The theory is good, right? The idea is that if you're gonna hire a software developer, you should see them develop some software before you give them a job. You should kind of make sure that they can do what they say they're gonna do and what you think they can do on the interview. But the big lie of coding interviews is that they don't actually replicate real work. It's a good theory, but if you think about the way these coding interviews typically go, if we treated our coworkers the way coding interviews tend to treat candidates, we wouldn't have many coworkers left. They're really stressful and they don't map particularly well to the real work and why is that? Well, for one thing, they disadvantage people without a lot of free time. So if you've got a take home test, if it's codility, if it's check out my GitHub, look at your open source contributions, that disadvantages people who might have a really stressful day job or maybe they're taking care of a sick parent at home or maybe they have, maybe they're a single parent and they just don't have time to do your coding challenge in the evenings after work. Live coding and pairing is stressful. It's really difficult to get a good feel for whether or not somebody can do the work when they're constantly worried about the evaluators sitting over their shoulder making sure they don't make a typo. I've been in the industry for 25 years and even I get a little nervous and fidgety when I'm being, somebody's looking over my shoulder while I'm coding during an interview. This is sort of the hidden one. They're difficult to develop and maintain. It is really hard to develop a take home code challenge for example or a pairing session that accurately and accurately evaluates a senior's skill. It's easy to develop a code challenge that will tell you if somebody can program at all but then how do you modify it to allow a senior to show you what they can do in a reasonable amount of time. And then once you have these code challenges you have to maintain them. You've got to make sure that they continue to work that you don't put your candidate into dependency hell on accident or on purpose. Don't do that. And then finally we're in an industry where hiring is hard. It's hard to find good candidates. And if you're trying to poach from companies where people are mostly happy they're just not gonna do your code challenge. And if they do it may take them twice as long to get it done because they've got other stuff going on. And so in the end all of these things make live coding and pair programming and all of these other coding techniques they sort of fight your goals of hiring good people as quickly as possible. Excuse me. So what should we do instead? Now I hate to be the bearer of bad news here but the solution to this problem is to talk to the candidates. I know it sounds a little snarky and it kind of is but I wanna emphasize that the techniques that I'm about to talk to you about they're not the only ways to go. These are not the only things you can do. These are the three that I've had success with but really the core part of this is that you wanna have a conversation with the candidate about technology, about the technology they've built, about the technology that they're interested in and you wanna get to know who they are and what kind of software they build through any means necessary. And so these are just the options that have worked well for me. You might come up with something completely different and if you do I'd love to hear about it so hit me up on Twitter. But before we get to that point and this could be and in fact was earlier an entire talk. What are some general interviewing tips? This will apply to anything, it'll apply to your coding interviews, if you continue to do those, it'll apply to your code free interviews, it'll apply to really anything. Define what you are looking for ahead of time. This is one of the hardest parts of hiring people, deciding what you're looking for in a candidate. But if you walk into an interview and you haven't decided what the criteria are for the hire that you're making, you're going to be hiring almost entirely on your own personal biases. And that works out sometimes and a lot of times it doesn't. Ask all of your candidates a consistent set of questions. This is actually much easier to do when you've defined ahead of time what you're looking for. They flow naturally into one another. And then your interviewers should write down their thoughts before they talk to anybody else.  And the reason for this is that once you get in the room and just kind of put yourself in their shoes, once you get in the room, if you haven't written anything down, the first person starts talking, and they say, yeah, well, I didn't think they were very strong technically. Even if you previously thought they were strong technically, your opinion starts to shift and you start to see things from your coworker or your colleague's perspective. If you've written down, actually, I think they're pretty good. By the time that person is done talking, you might agree with them, but you still have some points to make about, no, well, actually, I thought they might have actually been better than you maybe thought they were because of X, Y, and Z. And that helps you get everybody's real perspective on what it was without the biasing that happens from listening to somebody else talk. And the final point, and this is a big one, interviewing is a skill. It is not a skill that all software engineers have inherently by virtue of the fact that they know how to program. And if you don't practice, if you have 100 engineers on your team and they do one interview a year, they're not probably gonna be very good at it. And so this is something that you have to work at, something that you have to practice, that you have to get better at, and then you have to think about why you're doing what you're doing and how you do it. In the end, if you do that, if you put the work in, you will get better candidates and you will get more of them because I think the thing that people often leave out of talking about interviews and interviewing is that a poor interview process or a poor interview generally is going to cause candidates to think disfavorably about your company. So you think about interviews that you've been to if you thought the interview was kind of weird or you didn't get all the information that you needed or the interviewer asked you kind of some weird questions and you didn't understand how they're related. You're kind of mentally marking off points from the company that you're talking to. And so having a bunch of skilled interviewers can actually help your attraction rate and get more candidates in there. So what are the ways? So we've talked a lot about how and talked a lot about why and sort of how to get started with interviewing in general. But so what are the three techniques? The first one is one that you probably already do to one degree or another. You wanna dig into their experience. Look at their resume, find something on there that you think is interesting or even better once they get in just ask them, hey, can you tell me about a project that you've worked on recently that was particularly interesting or particularly challenging and let them direct you towards the thing that they think best represents their own abilities. That allows you to sort of highlight or allows them rather to highlight what they think is best. If you pick something, be aware that there's a risk that you might pick something that looks great on paper, but then actually it wasn't that great. If you run into that situation, it's fine. Redirect either pick something else from their resume or ask them. And so a lot of this is kind of impromptu like finding the path as you go, but definitely have read their resume before you come into the meeting into the interview. That's a big one. And having some idea what you're gonna ask about once you get there is good. So what are some of the questions that you can ask? Obviously you wanna ask what their role was on the project. I wouldn't put too much weight on this. One of the reasons you might be getting a senior candidate interviewing with you is because they're not being given the opportunities at their current company, but it is good to know like, did you build the entire thing? Were you a code reviewer? Did you help with the architecture and somebody else implemented it? It's good. It colors the rest of the conversations you have. The next thing that I like to do is I like to figure out how it works myself. So act like I'm doing an architecture review or that I'm onboarding onto their team and I have to figure out what is this thing and how does it work if I'm gonna be working on it. So that means asking a lot of really detailed questions. How does the system talk to that system and how do you store that data? And what do you do for backups? And what about the lag time between these two things? Do you have real time or is it just an, or is it a eventual consistency? Really dig in. And you might run into places where people don't remember or they don't know and that's all fine. But really try to get as good of a picture as you can about the project they're working on. And then these next two are ones that I've kind of come up with over the years that I've gotten some really interesting answers to. Where's the worst technical debt in your project and how would you fix it? And why hasn't your team fixed it yet? The last one is interesting because it kind of gives you an idea of whether or not they understand the business concerns of refactoring and technical debt. That's a really important quality for a senior to have in my opinion. And so it's one of the things that I like to figure out from people. The final one that I like to get in is, have you had any outages in production or bugs, big bugs that you want to talk about? Why did it happen? What could you have done ahead of time to catch it? How did the team fix it? How did you respond to it? And this gives you an idea, especially from your more senior candidates, of what's it like when the rubber meets the road? How do they respond when there's problems in the system? And what did they learn from their production outage or their bug? So that's kind of a good way to, it's probably something you're already doing. It's worth linking that up with the questions that you already, with that, the section of going through and figuring out what your criteria are. Link that up with their experience. Try to figure out how you can ask questions that identify those qualities that you're looking for in your software engineers. The next one, and this is if you, excuse me, if you caught the asterisk on the title slide, you might be wondering why there's a qualification there and have them do a code review. So this is not necessarily a code-free interview. It's more of a coding-free interview. But one of the things that I like to do is give them a small amount of code and role-play them reviewing my code. What you get out of this, I'm not in this case trying to replicate them reviewing a 2000 line pull request into one of our major systems. What I'm trying to do is figure out how do you talk to other engineers about their code? What questions do you ask?  Or are you gonna say, why did you choose that particular method to calculate that information? And so one of the hard things when you start thinking about having your candidates do a code review is selecting what code to review. My big number one rule is do not have them review your own production code. And this is not for security reasons, actually. It's really because they will not have the context necessary to really review that code well and it's gonna be super overwhelming for them if you drop them into a 500 line Rails model that controls your entire application. Work as you're coming up with this project or this code sample to review, work to reduce the complexity of it. It really make it as simple as you think you can make it and then make it even a little bit more simple because you don't really need to test whether or not they can read the most complex code in your system, probably. You'll wanna include realistic bugs but do not make this a bug hunt. It is really hard to find bugs in code without being able to run it. It's really hard to just look at code and find a bug especially when it's the first time you've seen it and you're on the spot. But including a couple of realistic bugs in the code will give you an idea occasionally of a candidate who has a particular eye for detail. So I think of these kind of as bonuses but we include a couple and if they don't find them it's no points off, it's fine. So what kinds of things meet that criteria? Completely contrived pull requests into completely contrived repositories. One option if you're currently doing like a take home code challenge, turn that take home code challenge into your code review, open your own pull request into it, have your candidates review that instead of writing the code themselves. Or find an open source repository and fork it and open a pull request into it that has the qualities that you want to see in a code review. The trick with that one is make sure that it's easy to understand what the open source repository does. You don't wanna have to spend 10 minutes of your 20 minute code review time explaining them, okay, well this application does this really complicated thing. So pick something that you think you can convey in a sentence or two so that they understand the larger context. We tend to go with completely contrived but open source repos also can work in a pinch. So now once you've gotten the code review you know what code they're gonna review. What kinds of things are you looking for in this code review? And this can also influence what you put into the code review in the first place. One of the things that we like to have in there is we like for the pull request to contain some kind of bad commit habits, some bad pull request habits.  Maybe commits where one of the commits has a syntax error in it and the next one fixes it but those weren't squashed down into a working commit. Whatever your personal company's commit habits are that you like to have look for those in the developer or in the reviewer. You might look for non idiomatic Ruby code. You might look for things that are not the Ruby way or whatever coding framework you're in. I might give you an idea of whether this person's experience is in Ruby or in something else and that's fine. It might be totally fine to you if they aren't Ruby experts but it's a good thing to point out during the interview or to learn during the interview. I would avoid or I wouldn't avoid. I would look for a reviewer that can find overly complex code and other code smells like confusing variable names, overly architected classes. Any of those code smells are good candidates to put into your code that's being reviewed to see if the reviewer picks up on it and then like I mentioned, actual bugs but be careful. Now, you really wanna run this as best you can like a role play. You want to, this needs to function as if they are talking to you, the developer so that you get a good feel for how they actually talk to somebody who's code they're looking at. We typically tell them this is going to be a role play. Pretend like this is my code and that usually works for most people. They can usually get into character pretty quickly and if they don't, you can redirect.   What would you say to me if it were mine? And the main reason to do that is because you get a really good feel for how they communicate with the code reviewer. This can highlight, if somebody who does really well on this portion, it can highlight that they might be a really great ad to your team, even if the other technical indicators didn't put them in your top two. They might have been your third best technical candidate but they have amazing code review skills and they communicate so well with their colleagues. That person might be a better hire than the two more technical people just because of what they bring to the table in other areas. So that's the code review portion. I encourage you to play with this and run these. All of these, I encourage you to run them internally with people that you know as you're practicing to see if they'll work for you. And this brings me to my favorite one. Collaborative system design. This is not only a really effective way to find out somebody's technical level but it's also fun if you do it well. So what is a collaborative system design? You hypothetically build something so you just talk with the candidate. We're gonna build the tool or a platform or a project or we're gonna build something. We're not gonna write any code, we're not gonna write any pseudo code. You might write on the whiteboard, you might let them write it on the whiteboard. What I like to do is I write on the whiteboard while they talk so I can sort of sketch out what they're describing, how the system works and that helps me make sure that I understand and it helps them make sure that I also understand that's a big part. And the collaborative part is important. So once we get, we'll get a couple more slides and you'll see that there are going to be some places where there's not a right answer necessarily. There are many potential right answers and going back and forth with the candidate, letting them kind of choose the path helps you learn how they think and what they think is important. The big thing that I love about this method is that once you get good at it, you can figure out whether somebody is junior, mid or senior in 15 minutes. It's really not that, it really gets right to the heart of things pretty quickly. And it's not super intimidating for most people. At least that's been my experience. It is a little bit at the beginning like oh gosh, I've gotta do this perfectly but once the conversation gets flowing, people tend to forget that they're in an interview and they're just talking to another technical person about code and that's a really great place to get with your candidates. So again, we're back to a situation where you have to figure out what this is gonna be. It should be easy to understand. It's excellent if your company makes software that everybody understands.  If your company doesn't necessarily isn't that well known or the use case is kind of more complicated, you might have to do something else. And try to make it related to the skills that you're hiring for. So if you're hiring a back end engineer, maybe building some Rails app or building some kind of back end is great. If you're hiring a front end engineer though, those skills might not be as applicable. And so when we interview front end engineers, we're an Angular shop, we actually show them a screenshot of kind of a pared down page on our internal site and say like, hey, how would you, what would be the components in an Angular system? Like how would you build this out? How would you architect it? And I'm not, I don't know very much about Angular, but the people who do our front end interviews say it works really well for them. But tailor it to what kind of thing you're testing. And when in doubt, if your system, if your own thing doesn't do it, pick something generally well known. Like a social media network, Twitter, Facebook, Instagram, what have you. It's something that most people are gonna know about. And if they don't, for some reason, know what Facebook is, you can kind of explain the concept to them in a couple of minutes.  So now once you've picked a project, how does this work? Like I said, this is really quick. You're not gonna build all of Facebook in 20 minutes. And so let them know ahead of time. It's up to you whether or not you tell them how much time they have. We generally just say like, hey, we're gonna start going through this process. We're not gonna get through all of it, but let's just get as far as we can through it. And that gives them an idea that like, if you cut them off at 18 and a half minutes because you've seen enough, it doesn't make them anxious that like, oh God, I was doing so poorly that we just canceled the whole thing. Pre-populate the boring stuff. So the boilerplate sections like auth that you might not find as interesting. So avoid going down rabbit holes. And let the candidate lead. When you have an option, a fork in the road, let them do that. And then the big key, the big key for this one is if the candidate is moving fast or they seem really comfortable with the thing that they're building at this particular moment, that's when you increase the complexity. And that's what really brings value to this particular technique is that it allows you to dynamically scale the challenge level of the interview to the candidate. And that's where you determine whether the person is more junior or more senior. So let's talk about building Facebook. What would we do? CallRail, we really value people's contributions to product and sort of thinking about what our users need. And so we ask them, for starters, like, hey, if we're gonna build Facebook, what's our MVP? What's included here? And so we set them up with, okay, we've got users and they can log in already because we don't wanna spend 20 minutes talking about how you design auth. So what's included in the Facebook MVP? Well, friending, status updates and news feed. When you start getting into things like likes and comments and reactions to likes and reactions to things and pokes and whatever else you have, be careful because that, is that really an MVP? But instead of saying, oh, no, no, no, let's not do that, just ask them why, like, okay, why are likes a really important part of this to you? And don't worry about it because you're not gonna get to them anyway, probably. So then once you have sort of the list, where do we start? What's the thing? Okay, so we're gonna build friending and we're gonna build status updates. What do we build first? So, status updates, let's go there. Okay, so when you implement status updates, you really want to, usually people are going to have a pretty good idea, okay, we're gonna add a table or we're gonna add another model that has status updates in it. Once you get that, like, dig a little deeper. How are you gonna put privacy controls in this thing? Are they just going to just add a field to the status update column or the status update row? And once they're there, well, what about granular privacy controls?  And then once they have that, they've probably chosen some method of handling privacy which is not perfect. And so keep digging. What performance problem does that raise? What method of operating with that does that solve? So if they just have a bunch of fields on the end of the status updates that says who can see it and who can't, well, that's gonna make a really complicated query when we go to build the newsfeed. So friending is the same thing. It's a slightly different situation. But how do we implement friendship status? It's bi-directional. You've got some, do we put one row or two in that join table? How do we implement the friend requests and what happens when somebody rejects it? How do we add blocking? We can kind of go down that rabbit hole. And then once you've got both of these in, if the candidate has done really well, you can put them together and start talking, build, draw that system out on the whiteboard and see how it goes. So should you ever resort to a coding interview? And the answer is, yeah, sometimes. If your interviewer skills are lacking, this can be a temporary solution while people get up to speed using coding. Determining whether entry level candidates can program at all. So this is the Jeff Atwood coding horror versus Buzz use case. It actually works pretty well for that. And then when a very specific programming skill might determine seniority. So if you're kind of on the border between mid and senior and how good they are at Angular, really is the thing that determines whether they're across that line. Sometimes after the interview is over, you might ask them if they could do a short coding example. Another big one is that if your organization mandates pair programming every day, you might wanna see if they can do that or if they're gonna like it or hate it. And then finally, the big one is, now that I've convinced you all that pair programming or that coding interviews are no good anymore, you'll probably wanna do them for a little bit longer as you transition to this method so you can calibrate your situation. I really think that we'll come to see you over the next couple of years coding interviews as an anti-pattern. I hope that I've convinced you of that. I really appreciate your patience and your attention and thank you for coming. I'll be up here to answer questions. Thank you so much. Thank you.


The weird circle. In this cave, by the restless sea, we are met to call from out the past, stories, strange, and weird. Bellkeeper, hold the bell, so all may know we are gathered again in the weird circle. Phantoms of a world gone by speak again the immortal tale, the niche of doom. This top, this constant tapping inside my mind. Yes, I've listened to that same hopeless tapping for days on end. I thought it would stop when I came to this rest home. Here in my room, my husband sits on the edge of my bed, watching me, knowing my thoughts, feeding me horror, tearing at the fabric of my mind as a spider tears the wings of its prey. My husband August Meray, my husband, my torturer, my captor, my murderer. Woman has a right to live, to laugh, to smile and be happy, the right to love and be loved. And I was lonely. I remember the day I was in the patio attending to my tulip bulbs, talking to my maid Rosalie as I spayed at the earth. Oh, madam, the garden looks just beautiful. Yes, it does. I love this garden, Rosalie. It's the one thing in this entire dreary house I can call my own. If the tulip bulbs work as nicely as they did last year, perhaps Monsieur Meray will allow you to enter them the garden contest. I've meant to ask him. Good day, Josephine. How are you feeling today? I feel fine, August. I didn't expect you so early. You may go, Rosalie. Yes, sir. Anything I can do for you, madam? No, nothing, my dear. Yes, madam. You're looking very well, Josephine. Very well. August. You've something on your mind? What is it? August, I was wondering if you'd mind frightfully if I entered my tulip bulbs in the annual country exhibition. Mind? Naturally I mind. You know very well I don't like you making an exhibition of my name in public. August, just entering the tulip. I will not discuss it. But it's so lonely here all the time. Lonely? Nonsense. You've the maid for company? Yes, I've Rosalie. And I manage to spend one evening a week with you? Yes, I know you do. My dear, you should be very grateful that you have the position in life which marrying me has given you. I have everything but happiness, August. Happiness is relative. A girl born in the circumstances in which you were born, a poor, unimportant family, certainly cannot expect everything. But I ask so little, August, just to exhibit the bulbs in the flowers. I thought we were not going to discuss this anymore. You know very well the doctor told me at my age I'm not to allow myself to become excited. Yes, I remember what the doctor said. I'm glad. Please remember it. And now my dear, I really must go over to court. Will you be home this evening, August? I'm never home on Tuesdays, Josephine. Enjoy yourself, my dear. Don't wear yourself out in the patio. Your country girls are always lovely while you're young. But you age so quickly. Age so quickly? He frightened me. I saw all the years of my youth passing me by as I was caged up in a house in the room, Omar. I was only 15 when I married, August. 15 and he was 55 then. Five years of marriage had taught me the meaning of loneliness and tears. A woman has the right to bask in the warmth of her youth. That's why I left the house that day. I wandered out into the garden patio outside my room and I walked down the boulevard to Grinnell's café. I sat down at a table on the sidewalk, intending only to watch the others, to watch life pass by. The waiter was very friendly. What will you have, madame? An ice, a raspberry ice. A raspberry ice. Excellent, madame. Excellent for a warm afternoon. Oh, hangry, this would make August. Sitting all alone, madame? Yes, I... Well, because I wish to be alone. Oh, no, you don't. Not when you have the opportunity to enjoy my company. Please, sir, I shall call the waiter. No, don't please. You're lonely and I'm lonely. Certainly there can be no harm in two lonely people sharing a table for one short half hour. Now, can there? But my husband... Even a jealous husband can't eject. Really, sir? And you are lonely.  Oh, I can see the truth in your face. You see things that are not there. May I, madame? Just for one half hour. Well, there really is no harm in it, is there? None at all. Thank you. Of course, madame, you know that I've lied to you. Lied to me? Your ice, madame. Something for you, monsieur? Oh, same as the lady. Oui, monsieur. Nothing like raspberry ice to start a lifelong friendship. What do you mean you've lied to me? Well, I didn't just have it along just now. I didn't just happen to see you sitting here and come up. I planned everything very carefully in advance. Oh? You see, madame, I live across the way from you. I've watched you gardening in the patio of your home many times. But why, monsieur? Why?  Because I wanted to know you so very much. Because I've seen something in your eyes that I've felt inside myself. You shouldn't, monsieur. You really shouldn't say these things to me. My name's Pierre Plantin. Monsieur, for both our sakes, do leave me now. You've no idea how much trouble this innocent little adventure might cause us later on. Oh, I've waited a long time to meet you, dear lady. Not just a day or a week or weeks, but a year. Very flattered, monsieur Plantin. Pierre's the name. Pierre? You know, the first day I saw you in the garden, I asked my servant who you were. And while I found out you were married, I resolved never to try to see you again, but... Why did you change your mind? I saw your husband. August is a very fine, upstanding man. He told you so himself, eh? I know, I really think so.  Oh. Frankly, my curiosity's aroused. Why did a lovely young girl like yourself ever marry him? Well, I... I loved it. Oh, madame. Please don't cry. Please. If there's one thing that turns my bone to water, it's a beautiful woman's tears here. I'm not crying. Here, use my handkerchief for these non-existent tears, then. Thank you. Now, Josephine, smile. Stop ordering me about. I won't have it. Please smile at me and say I'm forgiven. You're forgiven. Oh, that's better. I promise to be nice. You see, Josephine, believe it or not, I'm very fond of you, against my better judgment. You'd better believe it because I'll haunt you every day if you don't. And that's the way it started. Just a talk in a sidewalk cafe. My first friend, perhaps the only friend I had besides Rosalie, at first Pierre and I thought we were just playing at love. But by the end of the second week, I knew the truth. I loved him. I loved him as deeply and as truly as any woman could. We met in the afternoons in the cafe and in the evenings when August was out, he stole into the patio and we talked. Talked of him and of me and then of us. Of our future together. It was Tuesday two weeks ago that he was supposed to arrive at nine o'clock. Rosalie was helping me dress. You'd better hurry, Madame. You'll be here in half an hour. How do I look, Rosalie? Beautiful. I wish I were as beautiful as you. Oh, Madame, put this brooch in the front of the dress. It sparkles, so. Yes. Yes, I think I will. Rosalie, he's so handsome and so fine. And you really and truly love him? Really and truly. But what will you do, Madame? I don't know. If I could only be honest with August, if I could only tell him and break away.  Yes, I know. He'd be well within his rights. I'm so frightened sometimes. So very frightened. Oh, Madame. Listen, good steps. That's August outside my room. What will you do then? I don't know. Perhaps he'll leave before Pierre. But if he doesn't, then what? Then you must pretend that Pierre is your friend. Well, look at my lovely wife tonight. Dressed up, aren't you, my dear? Good evening, August. If I always dress in the evenings, you know that. No, I didn't. I shall hereafter take more advantage of your loveliness. Flatten me, Malone. I didn't expect you to drop in to see me this evening. Were you expecting someone else? Why, how unfair you are, sir. Unfair? No, I'm... Shall we say more curious than unfair? You may leave, Madame Rosalie. Madame, I... What's the matter with you, girl? Why do you stand there staring like that? Well, it's but... Rosalie's expecting a visitor in my patio shortly, August. A visitor? Rosalie? Yes. Well, it's different. A lover, eh? I suppose you'll be getting married soon, eh, girl? Well, yes. Yes, yes, I... Ah, more as the pity.  No, do my lord. I suppose you'll be leaving Madame and myself shortly. You should have told me, girl. Well, I... You what? I didn't think, monsieur. If you'd told me, I'd have supplied you with a decent dowry. A girl in your position can scarcely afford a trousseau. It's very kind of you, monsieur, to offer me. Well, my dear, no matter what, I shall be generous to you and offer your future husband-affair dowry anyway. What say you, Josephine? Is that not generous? Very generous, my lord. Ah, yes it is. My girl Rosalie, you shall be married in the Marais Chapel at noon Friday. Friday, monsieur? So soon? Three days? Yes, Friday. A girl in love should be delighted at prospect, unless you've lied to me. Lied to you? Oh, never, monsieur, never. I'm delighted, delighted. Yes, of course you are. Well, Josephine, you might help the young lady plan her wedding while I'm gone and make a list of all the necessary items which you'll need. Yes, my lord.  That ought to keep you well occupied. Yes, my lord.  I have to, my dear. You know these Tuesday nights. You know them very well. Good night, Josephine. Give my best to your suitor, Rosalie, and tell him I'll do my best by you. Oh, my dash. Careful. All this can be sly as a fox. Yes, Friday. Yes, Friday. Rosalie, he's very clever. I don't know how he found out the news. At least he suspects. What will we do, madam? I don't know. There he is. Tell him to come up, Rosalie. Is old spider legs gone? Yes. I climbed to my love's balcony. Darling, darling, darling. Here. August is clever. He knows. What? He knows? He told you so himself? He came in this evening while I was dressing. I was afraid he might stay for the evening, so I told him about you. You told him? I said that you and Rosalie were engaged to be married. Oh, so? He insists we get married Friday in the married chapel. He's going to revive my dowry.  Darling, you must leave at once and never return. Leave you and Rosalie to the mer- We'll lie our way out of this. I'll tell him my lover did not like to be rushed and quit me. And he'd believe it just like that? Of course. Never. Never, Rosalie. No, no, that's not the answer. That's not even sensible. Darling, sooner or later we'd have to take our chances and run away. Why not now? Run away? Where? How? To Spain. He'd never find us in Spain. I have no passport. I couldn't even leave the country. And as long as I'm in France, he'd find me and drag me back. We'd find a way to leave the country. Oh, Spain is lovely at this time of year. Beautiful. The trees are heavy with lilac bloom. And you'd like Madrid, Josephine. It's like another world. Madrid? If only... If only what? If only you have the courage? We'll leave at once, pack a few things quickly and we'll hire a coach to take us to the border. Tonight. Tonight, Pierre. Tonight. Now the suitcase is closed, my darling. Where's your coat? In this closet. Oh, let's do hurry. Lovely coat, isn't it? Everything looks lovely on you. Listen. What is it? My husband's footsteps in the hall. That's a pity, Rosalie. And I had such pleasant wedding plans for you. Can't you quickly hide in the closet? Take my coat and suitcase with you. Of course. You take it. Don't be frightened, darling. And she lay down with you. Well, she's probably lonely. I'll cheer her up. Josephine, I'm glad to see you looking well.  I had a bad headache. What's that? Nothing. August, I heard nothing. In your closet. I heard something drop. What could drop in a closet? I don't know.  Of course, my lord. You've so many headaches lately. Come, my dear. You'd best lie down and rest. Of course. Whatever you say, my lord. You may go, Rosalie. Yes, sir. Of course, sir. I hope I didn't disturb your plans for the evening. But the evening began to pawl, so I returned home. Sometimes my friends can prove themselves quite dull. I was thinking of you and your beauty, and I was worried about you. Worried about me? In what way, August? Oh, in the last two weeks, two of my friends have told me that they've seen you walking down the street alone. Unchaperoned. Have they? Not that I listen to idle chatter, my dear. I don't. You know that. People talk. They have so little else to do. Naturally, I understand that. But then, a very close friend of mine was at the Café Grinald a few days ago. He, uh, has told me something that rather puzzled me.  My headache. Naturally, your headache. He said he was sitting in the Café and he noticed a woman who looks remarkably like you. Walk in and sit at a corner table. A woman who looked like me? She sat for a while all alone. Later, a man, a young man, joined her. He sat by her side. Uh, he called her Josephine, your name. Remarkable that a woman who looks like you should have the same name as you. Yes, it is remarkable. Quite coincidental. That's what I thought. Coincidental. I might even have thought that woman was you.  Course, Auguste. For a little while, believe me, I was rather worried. I began to think about the habits and customs of country women and putting that together with your temporary restlessness lately. Well, for a while, my dear, perhaps in your moments of weakness, you had perhaps acquired an admirer. Please, Auguste. But naturally, you haven't? No, I haven't. Then when I walked in your room just now and I saw you looking so nervous, flushed, for a second I thought perhaps your, shall we say, admirer was here in this room with you. Did you? It was just a passing thought, naturally knowing you've a headache. I realized that the flushed expression comes from that. Yes, it does. Then again, when I heard that peculiar clatter in the closet, a strange idea was born. I thought perhaps your friend, the friend you met at the cafe, might be hiding in the closet. You look pale, Josephine. Do I? Is someone hiding in the closet? No. I naturally will take your word. If someone is in that closet, my dear, I should be forced to protect your honor and do away with it. Would you swear to me now on the Bible that there is no one hiding in the closet? Please, August, put away that dueling pistol.  Yes, August. Ring for your maid, my dear. Bye. I said ring for her. Yes, my lord. Oh, fetch me your Bible. You have your Bible in the room, my dear, haven't you? Yes, my lord, it's right here at my bedside. Put your left hand on it. That's right. And swear on the Holy Bible that there is no other man in this room besides myself. Ah, I swear there is no other man in this room besides yourself, my lord. Ah, my mind is much relieved. Much relieved. I did, Rosalie. Do you know where Monsieur de Gorinfo lives? The Mason, monsieur? Yes, the Mason, monsieur. I want to write a little note to him and I want you to deliver it at once. Fetch me paper and a quill, Josephine. Yes, my lord, I have a quill right here. Here's paper. Ah, that's just the thing. You've learned to sharpen quills quite well, my love. Hmm. Dear Monsieur de Gorinfo, I am writing to you all because... Yes. That's what happened on that fatal Tuesday night. I perjured my soul and I've paid for it. How little did I realize how much I had to pay. Rosalie left the room and delivered the note as she was bitten. My lord and I were left alone. He bade me retire to bed as I looked poorly and said that he personally would remain with me until my headache left. I assured him my health was much improved, but he would not have it so. I retired to bed and he sat by my side until... Monsieur Mary. Monsieur Gorinfo is here. Come in, come in, Gorinfo. Ah, I'm done as you bid me, monsieur. I've brought the cement and the paving tools. Good work, Gorinfo. Come, bring them in here. In here, monsieur? In Madame's room? Yes, yes, in here. Why, August, why? Rosalie, go to bed, girl, and get a good night's sleep. You don't have to linger around any longer. Yes, sir. Monsieur Gorinfo, do you see that closet in the corner? Yes, my lord. I wish you to cement it up. The side of it affects my wife quite strangely. August! Please, my dear. But August! You swore to me there was no one in it, my dear beloved wife. And I believe you.  I'll have another one built for you. Put my clothes. I shall buy you new ones. What are you waiting for, monsieur Gorinfo? My lord, at this hour of the night you...  Wait till morning, my lord. I am positive, absolutely positive, my poor Gorinfo. Go to work at once. I will not wait. I am a man of whims. Strange, interesting way. Whim. August knew that my lover hid in there. I didn't think he'd have the heart to go through with what he had intended. So at first I just sat quietly by and watched. Gorinfo laid first one row of bricks, and then another, and then a third, and then a fourth. Pierre was afraid by now. He preferred quick, certain death to slow starvation, and he began knocking on the door and calling out. Please, let me out. Gorinfo petrified, stopped, and he said... Monsieur, monsieur Marais. Go ahead, monsieur Gorinfo. There's no one in that closet. My wife has assured me there's no one there. August! August! And I'm within my rights, monsieur Gorinfo. Proceed at once. Proceed. As you say, monsieur Marais. Yes. He says he was within his rights to do exactly as he pleased. The fifth row slowly fell in place, and the sixth. And then I knew that August meant to see that night's work finished. The seventh. I cried. I wept. I tore at his coat. I pleaded. I am treated. It was all no use at all. Small beads of perspiration shone on Gorinfo as far as he wept, and the rows kept going up one by one until morning, when the entire job was done. Thank you, monsieur Gorinfo. Here is 2,000 francs for your work and your silence. My wife's good name must not be bantered about in public. Thank you, monsieur. Thank you.  The offending closet is sealed up. August, there's a man inside. There is. There is. How can you deny it? You're lying to me, Josephine. You swore there wasn't. I must believe an oath taken on a Bible. Listen, don't you hear him? Yes, but my ears deceive me. He's calling out. August, please take my life. But don't, don't let him die in there. Oh, my dear, there's no one in that closet. Remember what you said? Ring for your maid, Josephine. I said ring for her, not cry out for her. Of course I'll ring for her. August, be human. Please be human. I've been more than human, Josephine. I've been godly. I've accepted your word as absolute truth. Don't come in, Rosalie. I shall see you at the door. Stay right out here, my dear. That's right. Instruct the butler and all the servants that Madame and I will remain in her room for at least a month. And our meals are to be served by my private valet. Yes, monsieur. And otherwise, we're not to be disturbed by anyone. Yes, monsieur. For thirty days and thirty nights. I heard that tapping on the wall. His cries, his moans, his words, his pleas. I heard them there. August was stoned, completely stoned. He didn't care. He just sat and watched me. Watched my face. Enjoyed my terror. Fed me horror, waiting daily for the cries that issued up. August, how can you? How can you be like this? He's there. Pierre is there. He's behind the wall. My dear, you must be ill. Listen to him. He's dying there. Each day his strength grows less.  August. Please, in heaven's name be kind, merciful. Forgive me, let him go. There's no one there. I'll call the maid. You'll need her care. No one there. So ill, poor girl. Please call the doctor, hopefully. My wife is ill. She's going away for a long rest. A very long rest. I sit here in this rest home. Listening to the feeble tapping inside my head. The same feeble tapping I heard on the closet wall of my bedroom at home. That same feeble tapping. Will it never stop? On the time-worn pages of the past, we have brought to you the story of the niche of doom. Well, keepers. To.


Hello and welcome to NewsClick. Today, we are going to be talking about the leak of the poisonous styrene gas from the LG Polymer India Private Limited plant in Visakhapatnam in Andhra Pradesh and we are joined by D. Raghunathan at the Delhi Science Forum. Raghunathan, so there are a lot of questions that are emerging out of yesterday's incident. And the most important question is that from what we know right now has there been any gap in the security measures, has there been a gap in the safety measures that have been taken? Well, as of now, we don't know all the details, but some things we can definitely note. Styrene is normally stored as a liquid at minus 20 Celsius and it was stored in a fairly large tank. Now, what seems to have happened is that the temperature control systems seem to have malfunctioned and the liquid then vaporized, got converted into vapor, which has escaped from the tank in an explosive manner and has spread into the nearby areas. Now, although literature says that this is not fatal in nature, but if concentrations are very high, like it would have been in the vicinity of the plant, then either directly by asphyxiation, by just suffocation or by overdose at very high levels of concentration, it can lead to fatalities. Now, as for the leakage itself, I would have thought that before starting the operation of the plant, there should have been a preliminary safety drill or a safety audit conducted of the plant and a trial run done before full scale operations are started. Now, we don't know exactly what was done, but it looks as if operation was commenced without a very rigorous safety drill or a trial run. And the other question is that should, is there any basic flaw in the way the plant is set up itself? For instance, it is set up very close to areas of residence, there are a number of hamlets in the vicinity and we do know that also a key water reservoir is just about 2 kilometers away from the plant. So, is all this in some ways also quite dangerous? Well, it is dangerous and this is the deja vu time because it harts back to the bobal gas factory and almost exactly what happened in bobal, the union carbide plant there when it was set up was outside the city limits, but the city gradually expanded so that the union carbide plant then became at the center of a population center, which was a very congested area. Very similar thing has happened in Vizag. When this plant was first set up quite some time back when it was known as Hindustan polymers, it was located in the suburbs of Vizag. But now the suburbs have become part of the city itself. So, it is not that the plant was located in the middle of population centers, but population centers were allowed to expand right up to the vicinity of the plant. So, in that sense it is not a citing problem of the plant factory itself, but a citing problem of the city municipal authorities who have allowed population centers to come up to the plant vicinity. Either that or the municipal authority should have told the plant to shift outside, but to allow population centers to come up in the vicinity of the plant is certainly dangerous. I would also like to comment Prashant on the other regulatory infarctions in this plant. Now, as you know, after the Bhopal gas tragedy, there were a slew of legislations regarding citing of the plant, regarding handling of hazardous materials and so on. It looks as if in this case, there has been violation of all the regulations both on the part of the plant authorities as well as on the part of the state regulatory agencies and of the central regulatory agencies. Let me explain this briefly. The plant was taken over by LG from the previous owners and was a polymer plant known to hold and stock styrene which is a non-toxic substance listed under the Hazardous Substances Act. Now, this plant was found to be in contravention of the rules regarding citing and operation of this plant and of the environmental clearance that the plant had. In an affidavit to the state environment authority in November 2019, barely six months ago, LG admitted that it did not have environmental clearance for operating the plant. It is also true that the plant had applied for expansion of the capacity of the plant, moderation of the plant manufacturing process from 450 to about 650 tons per day. They had made these changes without the necessary permissions and clearances. They applied for this to the state environment authority which is not the appropriate place. They should have applied to the center. The state environment authority transferred the file to the center and again in the end of 2019, the centers in the Ministry of Environment and Forest, there's a portal which lists all the applications for environment clearances and there there is a listing which says, it appears that the project proponent is no longer interested in running the plant. That seems to have been the status barely six months ago and suddenly this plant was restarted without any objection from the center, without objection from the state environment agency or by the municipal authorities or by the state government. Now, I feel these are very serious violations of environmental regulations. Let me conclude by saying that just this morning Muslic has run an article by me on the environment impact assessment notification 2020, which is a draft lying with the center. This draft specifically notes that such violations such as amending the process, increasing the capacity, etc. have been known to take place and what the notification does is not to suggest measures by which these violations could be prevented or punitive action taken, but the notification says when such a violation comes to light, we will levy a fine and allow the plant to continue. So, really speaking, what seems to have happened is knowing that this was likely to be the attitude of the center and of the state, LG has continued functioning in violation of the plant of the environment clearances required to be obtained both from the center and the states and all concerned authorities at the central as well as state level have turned a blind eye. And just to ask sort of add to that question, right now that this leak has happened, what are the options before the government as far as this plant is concerned? Yeah. So, as far as I am concerned, this plant is operating in clear violations of the environment impact assessment notifications of 2006, which is the currently operational notification. Under that, this plant does not have clearance, it lacks clearance for expanding production or for the current mode of production of this organization. So, to my mind, three things come to mind. Firstly, I think the plant should be immediately shut down because it is in violation of all these. Which is the demand of the residents also. Right. But more than that, there should be a judicial inquiry into how this plant was allowed to function both by the center and by the state. And because both the central government and the state government has involved, it should be an independent judicial inquiry not subject to any jurisdiction of the central government or the state government. And third, precisely because these are the kinds of violations that are sought to be papered over under the draft EIA notification 2020, this draft should be put in abeyance until this matter is decided. Right. Thank you so much, Rabu, for talking to us. Thank you. That is all we have time for today. Keep watching NewsClick.


Okay, I think we should probably start. Do you want to kick off, Jane? Sure. Can you see the screen? We can. Thank you. Okay. Okay, so here's the survey. So it just goes through the questions. The first question just to ask people to identify themselves. So here we're saying that if you identify yourself with multiple of those personas, then you fill this out multiple times. Do you think this is necessary to separate out to fill this out multiple times? I think if the audience is going to be the end user group, I think that's possibly overkill to do it that way. Okay, so maybe... Because most of these... End users, right? Yeah, okay. Yeah, we also included vendors, but yeah, but I probably it's more for end users. So just remove this. Just say multi-select then. Otherwise it would be too... Yeah, good idea. Too complicated otherwise.  So I think those things are still valid. Okay. Okay, so yeah. And what project... What storage project you are using or contributing to? That's the next question. So here we include storage projects in CNCF. And then the other, if there is a project that is not... Yep. You can specify here, anything here. So first, the first question. Anyone has any comments on this category? So this looks okay. Do we need to add more or is it too much? Or just keep it this way. You can always comment later. Yeah, I think that's fine. Okay. Do you know what would be actually, sorry, just something that occurred to me. It might be useful to have a question at the top to kind of say, have you seen or are you aware of the of the white paper that we did? Because at least... Oh yeah, sure. Might make them look at it. Yeah, sure, sure. That's the question just to say... Oh, that's on here. Yeah. Enscape. Okay, I include the link here. And then what is your experience with the cognitive storage? And the next one. How is your storage solution deployed? So hardware solution, data centers, software components, commodity hardware, public cloud providers. So Quinten has a comment here. Maybe we should add another category. Storage as a service providers that are not primary cloud providers. If they are offering like the database as a service on public cloud or something. So... Yeah, that makes sense. Anything else? Let me just add another. I'll just add another. And what data access interface layer is consumed? So there's a lot of questions. That's cool. Then next is the blog section. So here are the questions if you have blog storage. Here are all the questions. So the first question, basically what is the blog storage system you're using? So Quinten has a comment here that if it is a well-known storage system, then user can just skip all the other remaining questions.  If it's AWS, EPS for this well-known. So should we give any examples here or just let the person to the judgment? Yeah, that's a good point. I think if they're using a well-known vendor or a well-known cloud provider, then it's probably right. I guess a lot of the rest of the questions kind of become... We sort of within the storage working group anyway, we should be able to determine the rest of the stuff. Do other people have any comments on that? Do we want to list some names? I think I would struggle if we were to... Maybe just leave it to the person whoever is filling this out as you decide. And then if they give a name, then if we don't know, then we can always do some research and we reach out to the person who answered the question. Okay. And then the protocols and also whether it's a local remote or distributed. A lot of those can probably be skipped if it's a well-known. And also, most of these questions, we also added a don't know at the end if it's probably sometimes people don't really know. And the storage of topology, centralized, just beauty-shotted, hyperconverged. Is that something specific to block or should we...? So basically, the problem is if we just... I have this question in every category. So for file, we have this one as well. So if you're only using block, then you just answer this one. You skip the whole file section. But if we just make this one question, then I just... I mean, how do we differentiate? That's why I kind of... So kind of those questions are repeated actually for block and file. So we can go through this and maybe decide do we want to take this out or because they could be using distributed block, distributed file, right? So this could be different. Those are in both sections. I think that we would probably know the answer to that based on... Yeah, so basically, a lot of those can be answered already. They just say what is the storage system you're using, right? Yeah. But probably not all of them. There are so many storage systems. I mean, yeah, if it's just like AWS, and those we probably know, but I just can't say that for every sort of system. So here they say, okay, if you already... That's the name. Maybe you can just skip all of those questions if you want to. Yeah. I mean, let's leave them in for now. Okay. Okay, yeah. It's probably... Can you see there are too many questions? Basically, those questions are repeated for each blog and file. So we can, yeah, go through this and then maybe we can talk at the end. I think question eight and question nine are probably sort of, in my mind, they're question marks. I think whatever products they say they're using will probably understand the answers to those questions. Okay. Yeah. So they can probably just skip all of those if we already know the correct name. I think question 10 and question 11, those are interesting to understand because if lots of... We might actually end up having some use case scenario or maybe some focus on perhaps, I don't know, snapshots or encryption or erasure coding or something. So those are probably words... Those are probably words asking because different systems can support multiple things generally. Mm-hmm. Okay. Okay. And then the fiscal layer. Yeah. I agree with Quentin. That's probably not that important. Mm-hmm. Okay. So just leave it to know or they don't have to fill out this one? Sure. Okay. And, okay, the next file system is pretty much very similar to the blog section basically. So if you answered what is the file system you're using, then you can probably skip everything below. Mm-hmm. The same, you know, the... Okay. I don't have this one because we have a table. I don't know if this is maybe too complicated. So I just added, don't know here. What is the underlying storage layer for the file system? Mm-hmm. This is the... Yeah, we have this table in the white paper, right? So... Yeah. It's kind of complicated. Maybe people wouldn't pay that much attention to all the details, but we don't know here. Clint, I think that table was something you had put in. Do you think that's worth collecting from the end users? Sorry, one more time, Alex. The question 14, I think that table was something you might have put together. I was wondering, do you think we need to collect that information from the end users? I think that this came after describing that there is essentially the complexity under the file system, like there's different ways of running the underlying storage. And I don't actually... I think the audience is probably ready to answer this more generally. I think it's a pretty... It's a more complicated question. Okay. What does everybody else think? Yeah. For what is right. We can remove this one then. I'll just remove this. I'll remove this. Okay. So the protocols. I don't know if it's worth asking this. Clint says maybe all of this are hidden. So I do add it. I don't know here. Sure. And then the storage topology. And so all of those are the same as before. Data protection. Yeah. I think similar to block. I think question 16 is probably not so important, but question 17 and 18 are probably useful. 17 and 18. Okay. Okay. We'll move after we're done with this. Should we remove some of this or still keep them? Okay. And then still have this last one. The same. Yeah. I think question 19 probably isn't needed again. Probably should just remove this one. Yeah. Okay. Unless anybody thinks it's important. Okay. So for object store. Basically it's just. Mainly just answer what object store you're using. And then you can skip this one. But I'm thinking so that's kind of the thing. But if you are setting this up yourself. It's like a local object store. Or swift. Then you may be still. We'll be looking at this layer. So. So here's okay. If you are using up just for our public operators keep. This one. Otherwise they can still answer this. I don't know. What do you guys think? This is not, not that important. We should just to get rid of this question. Okay. So, so I think. If we're looking at this in terms of. What's useful to us in terms of what to focus on next. And which projects to look at on that kind of thing. I'm not sure that. I'm just trying to think. I don't know that that actually gives us information to. Okay. I mean, it's, it might be an interesting to this thing to kind of say. Okay. 50% of our end users are doing so this day versus. But I don't know that it's actually something we can use. Okay. So probably maybe just need to just remove this one for every, because we also have this one. For the blog and just remove this one for. Yeah. Okay. All right. I also have this one foot. This one basically it just listed all the key battle stores. This is far in the white papers. Those are our reference in the white paper basically. So I don't know if there are other well known ones that we want to list here. Okay. So I'll just remove this question here. And. So, so the database, do we want to list any. Well known databases or just let the user answer this. That's a good question. It was some of this actually I was. So like some of those, right? Some overlapping assets like Cassandra. I thought I was thinking it. You should belong here, but it's actually here. But we can list a few. You know, I mean, that's a good point because Cassandra, for example, is often. And conqueror should be, for example. Yeah. Yeah, this one too. Yeah, those, both of those I thought it would belong here, but it's actually, because it also has the key value APIs. That's why it's actually listed in the white paper. So that's why I put them here, but they could be here too. So. You can be in both places. Then those maybe. Cassandra and. Okay. So do we want to list anything here or no? It's. What do the other people think? Do we want to list a set of databases or just have them? I think the other option would capture them. Thank you. Somebody wants to specify them as key value stores. I'm sorry. The other option would capture Cassandra and. You know, other databases if they're using them as key value stores. Right. Understood. Okay. So we can do it with the purpose of this, just to round out our knowledge of what the most popular ones are. Or what's the. Like are we, are we asking in context to like, who's running it on Kubernetes or. And what's. What do we have. Okay. Okay. So maybe we should add some questions. In here. So, so we do have, we do have this oxygen section, but Kubernetes or what content orchestration system do you use? And we do have those sections here. And then the plugins. Some questions about plugins. So we do have it here. But, but on 21, 24, we. When we're trying to understand where people are, I mean, I think we can find out the popularity of databases. In a ways. We're trying to understand if they're being used in cloud native ways or what. Well, so the. So we're going to send this question. They are to the, the end, the CNCF and the user. Group, right? So. We assume they are using them in the quality way or how do we, how do you phrase those questions? So. If I'm trying to, if I try and capture those, those tools for a second. So I think. We want to get a little bit of an understanding. So. We're going to send this question. They are to the end the CNCF and the user group. Right. So. We. Assume they are using them in the quality way or how do we. How do you phrase those questions. So. We want to get a little bit of an understanding. As to. What. The end users are actually using. Because. We might see, oh, I don't know. 60% of them are using cockroach to be in there for maybe a. Use case on cockroach to be beautiful. So. We might also find that they're using some. Projects which. Maybe as a candidate for. Becoming a CNCF project that isn't one yet, for example. So, so finding out. What, what those end users are focusing on might be an interesting might provide us with some interesting data, but I do also agree with Clint. I think it's probably like having a question, a more generic question. Maybe in the orchestrator section where we say, okay, I don't know. I don't know. I don't know. I don't know. I don't know. I don't know. I don't know what orchestrates are using. But then with what's thankful workloads. Oh yeah, that's a good point. Okay. Okay. Add this. Like what workload. What workload. What. Workload. What type. See you running. Okay. And I think it's okay to keep that to narrow. But I think there might be a way to make it a little more useful. By setting context that. You know, out of these, out of these database technologies. Which ones are you challenged by? Like, which ones are you thinking about? Operating differently. Like, you know, which ones are you interested in? Yeah. Maybe, maybe we can do that as, as, as questions. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. So if we say, what's the full workload? So you're running today. And then the next question could be like in three months time. What do you want to do in six months time or something? Does that make sense? Yeah. Yeah. I think in other issues, people may use these databases or key value stores. And they may use Kubernetes, but they may not use them together. Do we want to. So, yeah. That's kind of tricky. How, how do we separate those? Because yeah, so they, they may be thinking about, okay, they will be today they're running this, maybe not on Kubernetes, but they are maybe wanting to move them to Kubernetes. In a few months or something, right? So how do we. So maybe do we want to phrase the question as. What types of workloads are you running on the container registration system and then have another question to say what workloads are you consuming from the container reconstruction system or something like that. So, so we sort of differentiate what they're consuming externally to Kubernetes. Yeah. That would be interesting. If you've bought actually. Because I kind of suspect there must be quite a lot of people who are consuming stateful work. They might be running applications that are using states, but the thing that's storing the state might be outside of Kubernetes. I guess that would be a very common use case. So what type of workloads are you running that this will be include both or not on containers or should we just say. Not on containers. Or. That this include both. And then, and then specifically, what are you running on containers and what do you want to run in the future or something. Or perhaps we freeze the question along the legs of. Do you currently run. Database and key value stores inside Kubernetes or outside Kubernetes. And then do you plan to run databases and key value stores. In the next three months or six months or something. Outside of. Like. What is. We can say. No. Not something like it's not not on containers or something. Or. Maybe you should come up with a list of application categories and then reuse the same list for. On containers off containers. I don't know how you want to get in that list either. I mean, the. Detailed would be stateful or stateless and that's all the description, but you could drill down into specific things like. I don't know Kafka. MongoDB. If you wanted to get that detailed. I think at the very least to be useful, it might be say transactional databases. Key value stores and just put some broader categories. But maybe we want to get more specific. Yeah. I think the problem. With most of these services. If they're very, very long. You know, we might struggle to get. Yeah.  Arguably you'll leave somebody out and it just gets interminable. So I think maybe putting it, but just the two categories of stateful and stateless. Aren't. Enough detailed to be enlightening. So something in between. I mean, what, what, what, what, what if we say, what if we say. Do you run. Stateful workloads. In your orchestrated environment. And in brackets. Put it like example. Databases and message buses. And I don't know, you know, just, just, just give maybe a couple of examples of classes of stuff. That could be considered stateful. Maybe you want to add in production because. If you just want to know what people are doing, I think you can just go to Docker hub, which sorts by popularity and download. And you get a pretty good clue of what people. Are at least playing around with. Doesn't mean they're putting them in production though. So. Yeah. Okay. Okay.   Okay. So could do that. Just to get some. From there. Okay. Should we cover the rest of the questions then. Okay. So this is actually the, the end basically just. Yeah. Extraction. You know, the plugins. What type of plugins are using what sort of system. So the last question, maybe we can just, just to remove it. This is what are the frameworks and tools in addition to the plugins. But they probably already answered that in, in the beginning. Say, what are the projects that you are using or something. Yeah. Okay. Okay. So, okay. So. Okay. So if, if we can, if we can tidy this up. And get it to, and get it to Cheryl. She'll have a quick review and then forward it on to the, to the end users. And, and then she's also going to show you a session where we can, where we can attend. One of their meetings probably because I believe it's, it might be in two weeks time. So we can, we can then sort of prep over email for that session. Okay. Yeah. Sure. Okay. So I think we, okay. Let me just go through this one again because we talked about, okay. So I'll remove this question for all. And so we'll keep 10 and the 11. So for the rest of them, you think we can just remove them. Because it's, maybe obviously. Okay. And this one too, since you feel. Select it. If you give an answer and then we should, we can figure out. And. Yeah, it's probably this can go to. Okay. So that will make this simpler. Yeah. And then they can still skip if they want to. So we still ask, ask them if they want to skip this too. We just want to keep. Then only two questions. The body can say, which is a little bit there. Yeah. Yeah. It's only not that many anymore. Okay. Okay. So we'll do the same thing for the, for the file systems, which is, which is, you know, you know, you can get rid of all of this. Just to keep data production and data services. Okay. Okay. And. Okay. And then, okay. So I need to do some. Search on the doc hop to get a list of. Things people are using. Okay. So when you're, when you're done, if you can send it to the. To the mailing list, then I guess, you know, anybody can present any final comments. Okay. Those are the sort by popularities. Postgres is number one. Interesting. Yeah. Even though it says database, there's key value stores, like Redis is in there as numbers. Okay. So it's partly okay. We don't have to really differentiate. I would just put those names there just say, and then people can. Yeah. Okay. I don't know. Great. Okay. Okay. Good. Okay. Just to use this one, I think it's simple then. Those are okay. So this is database. They do, they probably, okay. So they, they kind of put everything together. So this includes the key values. Okay. They didn't really differentiate those two. It makes sense. I think the people post these images self-classify. So it's just whoever published it gets to. Pick their own category. You can see a category list over on the left. So. Okay. Some of these have gone in under. Arguably bad categories. I don't know. I don't see. There's no key value. I think they probably included key value in as part of database, which is fine. I think on this list. So that's, that's, that's clearly a key value store. Right. I suspect we're overthinking it. We just need a few examples. Really. Just to get going and then they can free form type the rest. Okay. All right. From my point of view, I had a quick update. I was prepping the white paper to publish it onto the, the storage working group could help page similar to what the serverless working group did. It was a bit difficult to convert the Google doc and to mark them. I think I'm just about done now. So I'll get that PR into the year tomorrow. And then we can throw a line under that. Great. Thank you. Thank you. Did, did anyone else want to raise any other things? Or in that case, I think we're done for today. Okay. Thanks everyone. Thanks. Bye. Thanks. Bye guys.


with changing the world but no one things of changing oneself. Hi people, welcome to my channel and I was just reading a quote by Leo Tolstoy and I find this quote so relevant in today's scenario as well and that's what the beauty of literature is all about.  Okay, so in this video we're going to talk about five major Russian writers that you must read if you're preparing for UGC Nets English Literature. Okay, so let's start. The first important writer is Fyodor Dostovsky. Now, Fyodor Dostovsky has written Crime and Punishment which is a very, very important work from Net Point of View. You must read the summary. What is important in Crime and Punishment is that he must remember that nihilism and Christian symbolism are the major themes. Also, at the same time we find that, you know, there have been references about Napoleon so much in this work. At the same time, if we look at the second important work by Fyodor Dostovsky, we would find that it is Brother Kharamazov. Now, it is the last novel so it is also important just because it was the last work by Fyodor Dostovsky. At the same time, the plot of Brother Kharamazov is that there's this father who is being murdered by two sons. Okay, so two brothers plot together to murder their own father. Other important works by Fyodor Dostovsky is Idiot and Demon. So, you must remember them. Now, let's move on to the second important writer, my favorite, Lyotolstoy. Now, Lyotolstoy, Anna Kirinana is very, very important. Now, when you look at Anna Kirinana, you must remember that, you know, it portrays the hypocrisy of the Russian society, the double standards that they have for man and woman. At the same time, we find that, you know, there's this very, very important work, War and Peace. In the epilogue of War and Peace, you'll find a description about determinism and pre-will. So, you must keep this in mind. This was a question in UGC Net exam that in which of the works by Lyotolstoy is a description about pre-will and determinism. So, that was War and Peace. Other than that, he has written this non-fictional work, Kingdom of God is within us. This work has inspired Mahatma Gandhi. Okay, and that is why somewhere down the line, when you look at Mahatma Gandhi, you'll find that several times he has referred to Lyotolstoy in his works, in his autobiography. Other than that, Lyotolstoy is quite well known for his short stories. Two very prominent short stories are one is family happiness and the other is how much land does a man need. How much land does a man need? It's just a two-page story and I would recommend that even if it is not so important from a net point of view, you must go and read it. It's a beautiful, beautiful short story and at the end, you know, we realize that after we die, actually if we need something, we just need that six-speed tall coffin. That's it. Apart from that, all the things we run behind and this materialistic things that we look for, that is actually having no purpose in our life. The third important writer is Alexander Pushkin. Now, Alexander Pushkin has written these two important works. One is Eugene Onigine. Now, this is basically a work which has Byronic Hero in it, so it becomes important. Also, this work is, this play is written in verse, okay? And the verse is known as Pushkin verse, okay? So, that is important. You must keep that in mind. Also, do go and read a summary of this work. If you are not so much interested in reading summaries from different places, you can subscribe to my online classes. We'll give you detailed notes about all the important points that are relevant for that author or that writer, all the summaries that are important. All important questions that have been asked in previous year related to that writer. So, we make notes keeping all these things in mind and all relevant points from net point of view. So, coming back to Alexander Pushkin, we've already discussed one work that is Eugene Onigine. The second important work is Boris Gordanov. Now, Boris Gordanov is basically, it might be a question in next net exam that, you know, which of the Alexander Pushkin's play is written, is a closed play, okay? So, you must know that it is Boris Gordanov. Now, moving on to the fourth important writer is Anton Chikov. Now, Anton Chikov has famously said this thing that medicine is my lawful wife, but literature is my mistress, okay? He was basically a doctor and then he used to write as, because he was so much passionate about writing. So, he has written this quote and this was a question in Eugene's net exam. So, must keep this thing in mind. There are three very important plays written by Anton Chikov. The first being Cherry Orchard. There have been questions about Cherry Orchard every year since 2014. So, it is a very important play. They've asked about which character dies at the end of the play, so that the name of the character is first. At the same time, he has written these two important work. One is Uncle Vanya and the other is Three Sisters. So, the play Three Sisters, it revolves around these Three Sisters and their life. So, that is also very important. So, at least if you're not able to read the other plays, do read Anton Chikov's Cherry Orchard. Very important to Eugene's net point of view. The fifth important writer is Maxim Gorky. Now, Maxim Gorky is very important for Russian literature because kind of Maxim Gorky was inspired by other writers. So, he was using their references, they are not in his own work. Okay? So, if we look at Maxim Gorky, four major works that you must study is the first being 26 Men and a Girl. So, it is basically about 26 prisoners who are being visited by a girl every week, okay? At the conversation that these people have with the girl. The second important play is Children of the Sun. The third important play that you must, must read is Mother. It is a play which has close link with Bertolt Brecht's mother. Okay? So, Bertolt Brecht has a lot of influence on Maxim Gorky. Also, at the same time, he has written this beautiful, beautiful work which was inspired by Anton Chikov. Okay? Because Anton Chikov died in the same year when he wrote Summer Focus. So, Summer Focus is a play which is inspired by Anton Chikov and is written by Maxim Gorky. So, you must read these works. So, I have tried to make these five important Russian writers clear and I have tried that, you know, you are, I am able to give you a blueprint about how you can study. If you want to know about all other Russian writers which are important from the net point of view, you can go to my website and you can find a list of all important writers on the website. At the same time, do subscribe to my YouTube channel because every Saturday and every Sunday I post new videos. You can like my Facebook page because every day I post a Go Net quiz, okay? Questions to help you keep yourself on top and questions that might be asked in the next net exam. So, do like my Facebook page for that. You can also drop a WhatsApp message on the number displayed below so that we can keep you updated about the recent changes in the UGC net pattern and we can keep you updated about the videos that we are posting on YouTube. At the same time, if you like, share this video with other net aspirants because everyone is looking for guidance. Do comment if you have any questions, any doubt or you want me to make videos on any other topic. Okay, so till the time I post my next video. Bye-bye. Happy learning and keep loving literature.


But of course, it's not just about new concepts It's also about having a good look at the standard again from the perspective of usability from perspective structure And one of the things we also added to the standard for those of you who've downloaded the book that you might already have noticed That we start off in a different way by showing how the standard builds up from models and concepts and elements So we have added an upper-level Generic metamodel to describe the structure of the standard and this is just one picture out of that Generic description showing how this this language is built up. So a model consists of concepts We have three different kinds of concepts elements Relationships and then relationship connectors, which are a special kind and then these elements are subdivided again into behavior elements structure elements motivation elements and composite elements And then you can go down structure elements We have passive and active structure elements, etc. And this is this regular structure is now explained in the standard in a much better way So that's for the the framework of the standard and for the structure So that's being improved as well It also helps people who want to implement the language because they have the background now and they can find it in there