Okay, thank you so much for joining, everyone. Welcome to the DHS2 Android and Web App Development Academy, workshop number one. And my name is Deborah Galeano. I am a developer advocate at DHS2 since January this year. And I will be giving a quick introduction to the workshop and talk about some of the logistics before we get started. And I also have several of my colleagues here on the call as well. And they will be introducing themselves in a couple of minutes. But again, thank you again for joining. I'm really excited, looking forward to learning and building some applications with you. So for the introduction, this is the workshop, like I said, workshop number one, a series of two workshops. The second one will be the advanced one and it will take place in May, but we'll go into more details about this later on. Yeah, so the content of this workshop might be a review for some of you who joined the workshop last year for the web app, but the purpose of the academy is to make sure that as you're building your applications that you're using the tools that are available to you out of the box, whether that's building mobile applications of web apps. And at the end of the workshop, we'll talk more about the project that you will be building as part of the assignment and which will be required for joining us for the advanced workshop in May. But we'll talk about the project tomorrow. And yeah, we have a great course team here, Android and web app. So unfortunately we can't let you all introduce yourselves. We have 70 registered participants, but we would like to introduce the facilitators and instructors for this academy. So again, I'll start. My name is Deborah and I will be facilitating some of this sessions today and tomorrow. And so yeah, I don't know who wants to start. I'm happy to. Just, yes, just really quickly. And then we'll thank you, Austin. Sure. Hi everyone, many of you might know me from the academy last year or various webinars or those types of things. My name is Austin McGee. I am a software architect at DHIS2, working mostly on the application platform and building out the tools for all of you and for everyone that's building applications on DHIS2. I'm really excited to have this workshop again and really, really excited to have Deborah on the team to help us really improve the way that we communicate and work with all of you to make our tools better and make DHIS2 applications better at the global scale, because there's so many of them. So really excited about that. And thank you very much. Looking forward to it. Okay, maybe I can go next if there are no more people from webinar. So hi everyone, I am Jose García. I'm part of the Android management team serving as a technical lead for Android. Very happy to be here. Very happy to be sharing this workshop with the web as well, because we need to work more together for sure. Yeah, hopefully during these two days we are going to learn a lot together and have some fun together for sure. Yeah, Victor, if you would like to go next. Yeah. Hi, hi everyone, my name is Victor García and I'm part of the Android SDK team. So yeah, very happy to be in this workshop and see you all, part of you in the Android SDK track. This, if you want to ask. Yeah, I can continue. Hello everyone, I am Luis Delgado. I work as a software engineer and also at the Android SDK. We have been working for the last three and a half years. I'm also really happy to be here with you guys and I will be leading some of the sessions in the Android track. Marcos, Pablo? Yeah. Hi everyone, nice to meet you all. I'm Pablo Pajuelo. I'm the Android team lead, the Android app team lead. I've been working in the HAES for most four years now. I'm very happy to be here in this first academy with web and Android and I'll be helping in the SDK track with support, leading support. So see you there. I think Jaime and Andrés and Jaime? Sure. Hello everyone, my name is Jaime and I'm part of the Android team. I work very close with Pablo and Victor. I will be on the SDK track if you have any question. Super happy to be here. It's my first academy. Yeah, we are approved today but we are going to meet all of them in the Android session. And the last one, Andrés, are you there? Yeah. Hi everyone, my name is Andrés. I'm also part of the Android team. I will be available for the SDK track and it's also my first academy. So I'm excited to be here and looking forward to learn of all of you as well. Yeah, Ferdi's around as well, right Ferdi? Yes, hi. I'm Ferdi Rodriguez. I've been working in the Android app for around three years and more or less and I'll be helping you in the Android SDK track also. Nice to meet you all. Okay, thank you guys. I'm sorry they were up for the big list. No, thank you. Yeah, yeah, but can we talk to them? Yes, we have Kai. Yes. We have Kai as well I think. Yes. Hey, my name is Kai. I'm on the web development team. I've been on this team for about three months and last year I was a student in this course. So now I'm on the other side as an instructor. I'll be talking a little bit about the UI library. Thank you Kai. So hi everyone, my name is Alice and I am the academic coordinator and I'm based in Oslo. Welcome everyone to the second edition of the web and Android app development. Thank you. Thank you Alice. Hi everyone, my name is Martin. I'm helping Alice here in Oslo with the facilitating for the Zoom call for the developer. Thanks. Thank you. So I think we have everyone, right? Yes. So we would like to do, we would like to hear from you just to say hi and we would like to take a group picture. So if you would like to unmute yourself and say hi just for a few seconds and show your video, we are going to take a few screenshots. Here you go. Okay. So we have 70 participants registered for both tracks. I believe we have 28 for the Android track and 45 for the web app. So it's great to see a large number of people interested in learning more about the HSU web application and Android applications. So most of the sessions will be recorded. So if you miss one session then we will be posting these recordings on the developer portal sites in the coming days. I will show you the developer portal in just a little bit. So like I mentioned, this time the economy will be split in two parts or two tracks. So for web app, you will learn how to get started building your first DHI2 application. So this is for people who never built an application before and want to learn the basics. So for more advanced developers, like I said, we will be hosting a second workshop in May. And for the Android track, you will learn how to use the Android SDK and that's available for all of you to build custom mobile applications. Now this workshops will be taking place at the same time. So we will have two parallel sessions for both web and Android and you will be able to join each track after this introduction. And I'll just go ahead and show you the agenda for the day. So for the web app track, after this, also we'll give an overview of the application development. This will cover most of the concepts, I think that were explained in the last webinar that we had in February. Maybe some of you had attended that webinar. After this, we will go over the CLI installation and I will be facilitating this session. I will have a little break and we will introduce the UI library. And Joe will talk about the design system and Kai will give a presentation on the UI library documentation and give them all the components and I will go over the exercises. So for the web track, just after this, you will stay with me and for Android, I believe that this will be led by Jose, I'm not sure, the first session, but as you see listed there, the other facilitators are also going to help you. We'll actually provide the sessions and you will have to go to this link that you see there that was shared on Slack, also on your channel on Slack, so you can join there after we're done here. So I just wanted to quickly talk about the upcoming events before we wrap up. So again, portion number two in May, but I wanted to talk about the digital, the DHS2 annual conference, which is our biggest annual event and this event will provide an opportunity for the DHS2 community to meet and share experiences with DHS2, learn about the latest developments and innovations and so make sure that you register for this event and as part of the annual conference, we are also opening or receiving submissions for the Web and Android app competition and that line is on June 7th and finalists from both categories will be invited to present their applications during the annual conference and there will be a prize that will be announced later. So, yeah, participants of the advanced workshop, you are welcome to submit your applications after you're done with the Academy and yeah, we look forward to seeing those. And so what's next? Like I said, for the Web app, you are staying with me and for Android, you will join another Zoom meeting and for questions, you are all part of the private channels. We have set up three channels, one is general, one for Android, another one for Web, but this Slack workspace is not just for the Academy, it's for the developer community in general, for the DHIS to the developer community. So this is where we will be posting information on events and things, developments and other information that are relevant to the developer community. So feel free there to ask any questions also even after the Academy. We would like to get to know you and also just to build and foster this community. I wanted to show you the developer portal just very quickly to show you where you will be finding the recordings. If you go to events, the events page, you will see that there's, we already have the recordings of the last webinar that I mentioned earlier that was hosted in February and you can check the links here. The recordings will be posted here after in the coming days and you will be able to check everything there as well. So with that, I think we're on time. Thank you so much again for joining and looking forward to learning with all of you.


This is Christian Buckley doing another Microsoft MVP buzz chat interview. And I'm here today with Martin. Good morning. Good afternoon. Yeah. Good afternoon for me. I'm in the UK. All I do work in US hours. My team are in the US.  Yeah. So yeah. So as you were saying, I'm Martin. I actually work for a managed service provider who are headquartered in the US. They have a presence in Europe as well, called Insono. They work across the full stack of technologies, all the way up from mainframe, doing managed mainframe, private cloud, and then all the way into public cloud. And I sit in the public cloud team, for me specifically on Microsoft Azure and DevOps. They're my main focus areas. And yeah, I work, or the team I work with is based in the US. I'm in the US Consultancy Group. So yeah, my hours are kind of odd, I guess, for anyone that is in the UK. But I basically work early afternoon till late evening. In this era though, we're all working from home and online. That's not so weird anymore. We're all working whatever hours we're working continuously. Yeah. So yeah, I mean, that's basically me. So yeah, the key areas for me, from a technical perspective, Azure as a cloud technology, although as an organization, we actually do AWS as well. So we sit across both of the major players within there and provide managed services around all of those things that I just talked about. But yeah, my primary areas are actually from a technology perspective. And then the very broad and large subject that is DevOps. Well, and I know you just became an MVP. So congratulations for that. Yeah, thank you. So it was a few days before this. So yeah, that's right. Yes. Yeah, new, new brand new. Sorry. So yeah, it's been something that I've been, I would say working towards, because I don't think you really work towards an MVP. It's a recognition for the work you do outside of your day job, right? The key thing about becoming an MVP is it's all about community work. And I think as well as it being a lot of hard work, for you to actually get to the point where you can be, someone can feel like they can nominate you for an MVP. I think it takes the work after that as well to not only get the nod from Microsoft to say, yes, this guy or girl is absolutely worth giving an MVP to. But then you've obviously got to maintain it because you were re-selected every year, basically. So it basically goes to recognize the outstanding contributions that you make to the community. So whether that's speaking engagements, blogging, podcasts, so videos. So basically giving back to the community. But it's stuff that you do on top of your day job.  It's basically that above and beyond stuff that you do. And I think, yes, the work is primarily on me to do, but I want to do that stuff based on the, quite frankly, amazing community that I have the pleasure of working with. And whether that's people that organize user groups. This is actually a good opportunity for me to say thank you to those people who actually want me to speak at their events because without them agreeing for me to speak at those events. And be able to share my knowledge and experience and those kind of things. And then wanting to be able to write blog posts that I know are popular with people and the people that read the blog, the people that have listened and subscribed to the DevOps podcast that I do. Without those people, those are the people that really drive all of the MPPs within the program. Because without people wanting to lay off technical experts and wanting to share that knowledge, and the program really doesn't exist as far as I'm concerned. So it's a really key thing to have in it. It's an absolute privilege and an honor to be included in that still fairly elite group of people and be looked up to someone who is a community leader. So yeah, it's a great privilege to be recognized by Microsoft. Well, I think that's going to be a constant thing that you'll hear from MPPs as well. It's like we'd all do the things that we do regardless of being an MVP. I mean, there's a lot of other benefits. So let's be honest. There are great career benefits to also participating in the community. Again, regardless of MVP status, just getting involved and making connections and helping other people. It's fantastic. So most of us would do what we're doing regardless of that status. As a new MVP, you're going to start fielding these questions. People will come to you and say, well, if I want to become an MVP, well, how do I go and do that? And I think the bigger story is more of looking back at the career of most MPPs. Very few, and I'm not saying it doesn't happen, who are just kind of doing their job and they're doing a little bit, they feel just a little bit in the community and then they kind of, somebody nominates them just because of the help they've provided and they're completely unaware of that. But usually you go back and look at the career trajectory of the individuals, the path that they're on, how they got involved and that speaks so much more to why they've become MPPs. And so you kind of mentioned in the beginning, you've been in tech your entire career. Straight out of university and just kind of went into tech. Kind of, what was your path? How did you get started and lead you to where you are today? Yeah, so I mean career-wise, I actually started off while I was at college in the UK, so UK college. So that's from when you're 16 onwards before university. I actually didn't go to university at all. So I have no degree or diploma, as you might say, from the US perspective. So in a lot of ways, I did it the hard way, but what that did do was give it the ability to, I guess get a head start on others my own age in a lot of ways because while they're leading at university and college, I'm getting practical, real-world experience. And throughout my career, I've been a hiring manager and I will always want to speak to, if I have two people side by side that both look great on paper, I am always going to want to speak to the person that has more career experience because there's going to be less uplift for them to get to the level you want them to be within your organization. So college diplomas and degrees are very important for a lot of roles, but you can still get to where you want to be without doing that. So if you're someone watching this on the fence is to, if you're in the UK and you don't know whether you want to go to university or not, or if you're in the US and you're just the kind of person that's not going to excel at that kind of academic career path, then I could definitely attest from experience that that is not the be-all and end-all of your career. You can still put hardware in and get to where you want to be. I consider myself quite lucky that I was able to be on a senior leadership team within the organization. I mean, now, by the time I was fit, it's a great place to be. Some might argue that there's very few places for you to go after that, but I was still a technical senior leader at the end of the day.  Yeah, that's what I was going to say. It's like in the tech world, there are those opportunities where I would argue that the, I mean, if your career vision is to go up through the executive, the leadership side of things, there are going to be fewer opportunities if you don't have the pedigree for that. It's just a reality, whether that's right or wrong for organizations, I think that way based on, instead based on experience. But within technology itself, it's pretty leveled out based on skill and value derived, as though there are those opportunities. It's, I have my oldest, I've got four children, my daughter who's married and she's just got into her first tech job out of, she finished her master's and she was a STEM kid. So it was a science kid and is in the healthcare industry and where she looked at the various job opportunities after finishing a fellowship after graduate school and saw this job that was in technology. So now she's like, Dad, where's the best place for me to learn about Power BI and the power platform? I'm like, yeah, I can help you child. I can't, she would, she used to send me her papers of like, Dad, can you take a look at those paper? And I'd read half of this where it's talking about different cells. I'm like, I can't pronounce half these words. I can't help. Like, but this I can help with. She said, just like, Dad, these jobs, there's so much more money than the other, in academia and the other jobs. I'm like, yeah. And she's, so she's really excited by that. But I think that's true, career wise. There's so many different opportunities in different industries and different spaces. You can have a passion for healthcare. You can have a passion for other non-technical topics in industries, but then find tech roles within that, to be within the industry and find great opportunity. Definitely. And one of my passions outside of technology is aviation. I'm absolutely, since I've been a child, in the absence of ever becoming a pilot, because it's frankly too expensive to become a commercial pilot. But in the absence of that ever happening, I've always been fascinated with aviation. I actually worked for an airline for a while, just before the pandemic and left there for the opportunity I'm at now. But that was great for me. Not only was it a great place to work from a culture perspective and all of those great things that make a great company, but for me, I was like a kid in a sweet shop again. I got to be around planes, I got to be around other people that understood the same kind of stuff that I decided to learn outside of technology in the aviation world. And I think one of the pinnacles of my time there was getting to spend three or four days outside here for an airport in London. One of the biggest international airports in the world and one of the busiest international airports in the world. I had the privilege of standing feet away from a front wheel of an Airbus A350 or a Boeing Dreamliner. And I have plenty of pictures on my phone to attest for it. They come out at parties to say, look what I did. This is me stood next to an engine. This is me in a cockpit.  I was actually allowed to do that. You were authorized. I had to bank in everything. I was actually allowed to do that. Wow. And it was pretty good because what I was doing, so I went on a tour with our cargo operations team while I worked there. And they had a paper sheet that they used to track the movements of what cargo was due on, when and at what time and what time it needed to be dispatched up and certain documents needed signing. And the day without it was just about a year ago, actually, it was November last year that I did this. And it was raining, obviously. Being in the UK, it was raining, goes without saying. And this piece of paper was obviously getting wet. They come right on it. But what a lot of people probably don't know is that within an airline, a lot of the car work around getting a plane into the sky is actually not done by the airline. It's done by various different partners. So the cargo company that were responsible for loading the aircraft were a Fed party of who I went for. So they, you know, us as an airline, we had no way of using those sheets of paper to say, how was this Fed party, how were they performing compared to what they expected them to do? So I took that sheet of paper back with me. I scribbled some notes on from the operations team there. And I made it into a simple app that they could record the times in electronically and then report on. So I got to go back subsequently, airside, you know, on the tarmac on the apron. Again, I was authorized to be there, thankfully. And we got to test it on an iPad. So, you know, the company used iPads. So there I am. We're testing it. We're making sure it works and we can see what we need to. All of that great stuff.  So, you know, it was really, it was really good working in tech to be able to apply my technical experience to a real business problem. And when it comes to stuff within technology, I think that's one of the real passions I have within my field is applying this, you know, huge amount of technology and services that's available in Microsoft Azure to real-world business problems. And I'm quite thankful that I have that blend of being able to understand the business problem and understand the technology that can fix it. And the automation, you need to get something to work and such like. So, you know, quite often I'm the guy in the meeting that's got the notepad out where someone says a problem that they have. And, you know, I'm the one there thinking, well, if we did this, did this, and did that, that would probably work. And, you know, I never want to take that kind of thing for granted because that's, you know, one of the elements of everyone's individual secret source that ends up making you successful and everyone has that different element that gets them to where they need to be. And if you want to work at something, then, you know, whether it's your ability to afford favoritication, whether it's your ability to get into a certain role, find out the way to get to where you want to. And that's, say, exactly what I've been looking enough to have the opportunity to do and then get to where I am. So, yeah, very, very privileged. You know, it's interesting. So you're working the DevOps space and you've just kind of touched on something that, so I talk a lot.  But is this idea that you are constantly looking for, you solve problems, you're in there in an operations mode, well, then you're going and looking, okay, what is looking at all the data? What's the next area of improvement where we know that, you know, something needs to be done? So, one of the, I have a background in technical project management, kind of where I started my career, and, you know, I would constantly, I'd own all the front-end applications for different systems, and they'd say, well, go in and demo these things, and I remember having a conversation working for a consulting company in Sacramento, California, where they wanted me to go and test out some new software, but they didn't want me to test it on any productions, problems, and areas, because they were production systems. And I remember, I said, well, we can go and do these generic tests. I said, but, you know, we're not really going to see the value, we're really going to understand the solution here. And I just remember when they said, ah, I spent weeks on this, and they made a decision not to go with it, and then they didn't solve the actual business problems, because they were fearful of applying the new technology and testing it on the live system. And kind of what you talked about is understanding what are those real-world problems that we're having, and go in trying to solve those real-world problems makes a big difference. But that's a big part of modern DevOps, is, you know, you're like, everything is running fine, but where can we improve if something, if there's not a break fix that we're looking at, to go get that next to move, we're at 75% efficiency, how do we move it to 80% efficiency and start looking at those different activities? And so it is a constant iterative experimentation. Yeah, we actually, I think at the minute, we actually have some really good examples, you know, unfortunately, it's a global pandemic that's made the situation come about. But, you know, I think, I honestly think technology of all the industries out of the pandemic, and, you know, technology is still doing really, really well. You only have to look at some of the earnings reports recently from the, you know, some of the larger companies that are continuing to make money, and, you know, which is good, you know, someone will always make money in any scenario, you know, we shouldn't put a downer on people for that happening, but the organizations that have these DevOps methodologies and ways of working and best practices ingrained within them, that are in technology at the minute, they're the ones that are coming out at this really well, I think, at the minute. You know, you only have to look at, you know, some of the providers of conferencing software, right, all of a sudden overnight, whether it's WebEx, Zoom, Teams, you know, still Skype for some people, whatever platform it is, the engineering teams and the operations teams that support these platforms, all of a sudden overnight had to cope with hundreds of millions of extra people using their tools and platforms. And a lot of the things that's instilled within us, within DevOps around more collaborative work in better communication and an agile approach to delivering your work and dealing with the technical debt that comes up and those sorts of things really means that those organizations are in a pretty good place when it comes to being able to deal with that demand. And there are other organizations which, you know, you can tell just from what you see and what you hear, some of the problems are with those platforms that they don't do this. You know, I'm not going to name names, but there are some platforms that have not coped well with a rising demand and there are others, you know, specifically thinking about Cisco with their suite of conferencing products, Zoom, Microsoft and Slack and, you know, a number of others. They've all done really, really well. You know, there's been very few outer keys or no outer keys for those providers. They've rolled out updates, still they're providing new functionality, all while sometimes in some cases seeing their user base increase by, you know, at least a hundred percent, literally over in the space of days. So that's really a testament to what value a good implementation of DevOps can bring to your organization. And that's really technologically agnostic. You know, I'm a technologist and I love engineering still. But from a DevOps perspective, it is really not about the technology. It's around the culture of your organization, the people that you have within that organization and the processes that you have in place. All the technology really does is just start to automate those great processes that you already have. And it's that technology on top of there, which then starts to, you know, really start seeing more value again on top of what you've already done because now where instead of running that process, you know, it might be a really lean process from a human perspective. But as soon as you automate that process, we can now run it 10 times an hour, instead of twice an hour. And that's where the value starts to increase, again, on top of that. And it's really clear to see, like I said, when you look at a lot of the organizations today and how they've reacted to the pandemic and how they're able to scale massively, you can tell that they have a good story to tell around all of the call principles, demos. Yep. Well, every time I see like a jump and you'll release some new features and I look at the jump in user numbers around some of the services that you mentioned, having lived in this world for most of my career as well. And I know that there's a lot of people that are not getting sleep during those spikes. Yeah. Activity. But yeah, there's, to talk about opportunity within this space around all of these real-time services, tremendous opportunities for individual growth, career growth within those segments as well. Well, Martin, I really appreciate your time talking today and getting some of the history here. People want to find out more about you, get in touch with you. What are the best ways to reach you, social platforms that you use? Yeah. So I'm a pretty big Twitter user, so you can find me on Twitter. The handle is MrCoups. So that's M-R-C-O-U-P-S. And I also post obviously fairly frequently on my blog as well. And my blog is m12d.com. And then also I do a podcast as well. And the podcast is called DevOp Squad. And it should probably be no surprise that that podcast is all around DevOps. So yeah. Yeah. Yeah. So feel free to check that out on the usual channels where you get your podcasts from. It's on all good providers. So yeah. Those are the three main ways. And one of the things I would add on to that is, if there's something that you think, oh, I really wish I knew how to do, or it'd be really good if I could speak to someone about this or I could see a blog post on how to do this I wish I could talk to someone about this particular subject and feel free to reach out. This is all what the community is about at the end of the day. And I know I speak for everyone in the MVP program, in Microsoft MVP program. And they would all say the same. They would say, if you need help with something, reach out to us. It's free, extremely powerful letters, but we're all still human. We're all still people. And helping people is what we love to do. So don't be afraid to reach out to anyone and ask for assistance. If it's just a chat that you need and you want to do that on Twitter, then that's fine. I see people interacting with MVPs daily. By all means, do that if you want to speak to someone. Again, just reach out. People will be absolutely more than happy to help. Right. And if we, in a common thread as well, because you're well said, is that if we don't know the answer, we definitely know somebody who does know the answer. And so we point you to somebody, you know. And so that is, that's a great point. So don't be shy. Reach out to the MVP community. Absolutely. Well, thanks a lot for your time and have a great rest of your afternoon. Yeah, thanks, Christian. You too.


I'm the CTO over at Immunio. I wanted to welcome everyone to Kansas City. I hope everyone's having a good time. It's the third day in the conference, so I'm going to try to keep references to we're not in Kansas anymore and the Wizard of Oz to a minimum. You've probably heard them all. RailsConf has always been a good place for us at Immunio. It's actually, if you remember us here last year, we had a booth in the Expo Hall. We actually launched our company at RailsConf. So our first supported platform and our product is Rails. And yeah, we love you guys. So thanks a lot for that. Speaking of launches, I want to sort of divert at the start here and say, did anyone stay up late last night and watch the launch SpaceX guys? Let's give them a round of applause. That was awesome. This actually isn't a talk on REST APIs. By the way, I used to talk on teamwork, collaboration, closeness. How many of you guys did any of these things today? How many of you did all of these things today? I think I did everything except to have a booth in the Uber E-Tier before, so it's... The last time I did this presentation, I sped through. I sped talk and we got there eight hours. I'll try to get it done in like seven to six hours for you guys. Sound good? I don't feel like there's, like, half a group is like, yes, maybe you're seven hours. The other half is like, why? Is that coming over our speakers? I don't know. So very quickly about me, the reason I'm doing this workshop, I'm an API fanatic. How many people here have used APIs? How many people have used APIs and don't work? Does anyone know what they're talking about? Is it better than my talk? Or poorly document? Or break? How many people like those APIs? Okay.  It makes my life suck, so... Can everyone hear me when I'm talking? Should I just talk over them? Is that fine with everyone? A way that's future-proof, a way it takes advantage of the best practices and modern technologies. Work with me here, we'll try to make it through and not, I wonder if they can hear me though. Interesting, okay. How many guys did this? All of you probably. How many of you guys maybe added some web banking in there? Maybe you arranged a date for the weekend. Maybe some of you right now with laptops are actually sort of like managing your company's network or touching your production servers. All this is happening online through websites. You guys write websites. Other people are out there writing these websites. This is all happening on the web. This is, everyone knows, 10 years ago, 20 years ago, it's just getting more and more stuff online. Government data, sensitive data, your date profile on Ashley Madison, everything's online these days. And the other people who are online are people like this. And of course, this is exactly what they look like. Or this one you've probably seen a lot. And how do we protect ourselves against people like these? Well, we go on the internet and we download padlock images and stick them on the screen. You guys have all seen these, right? Make your site more secure. Maybe another one, a green one in there, shield. And you know, stop. So hopefully, all of you guys are doing this. And all of these other websites that you're visiting and you're trusting to store your data are also doing these fancy techniques here. And that kind of brings up the question, who is actually protecting all my data on the internet? Probably some of you guys are managing sites that are holding my data. Certainly there are other developers who are developing these sites. Because fundamentally, over the past 20 years, say it's become easier and easier to make a website. We're all here this week because we love Rails. That workshop that we were listening in on, they're learning how to make websites. It's really easy. Rails makes it easy. Other frameworks make it easy. But there's still that question of who's actually protecting our data. Who is protecting that data? Is it people in this room? Probably it should be everyone. And are these people doing some of these things? Checking out our framework defaults, making sure things are up to date, maybe getting their code reviewed for security, pen tests, that sort of thing. Looking for new CVE vulnerabilities. Hopefully you're doing maybe some of these things. Maybe you should be doing all of them. Or maybe you're lucky and you've got a pair of magic. Ruby slippers. Sorry, that's the last one, I promise. Because security's hard. All those things I listed are hard. It takes a lot of time, it takes a lot of work. You guys, generally you're focusing on making your site work, making it do cool things. Building features for your customers. Security, everyone wants to be secure, but it's a hard thing to do well. It's difficult. But it can also be really, really interesting. And I hope some of you are here today to get into some of the interesting parts. So really I'm focusing today on three things. Three types of vulnerable code that might be in your applications that you've written or that you're going to write. This code that you write, your application itself, the view logic, that sort of thing, the controllers, the actual app. This is code that you've written and you're responsible for. There's also code written by other people. You use the Rails framework. Rails runs on Ruby. You probably run a ton of third-party gems to add various functionality to your app, to your app. Other people's code that you're now sort of responsible for their security posture. And then code not written at all. So maybe you should have written some additional functionality to protect you against attackers. But again, you don't always have time. So this code not written is also a gap in your apps. Kind of sounds a little bit like the ghost of Christmas past, the ghost of Christmas yet to come, but whatever. So let's look at an attack type that probably everyone's familiar with, I hope, at least you've heard of it, SQL injection. This is a very simple example up here. You've got an SQL query and you're building it by adding some strings together and putting in some user input there. And then a user comes along, one of those shadowy hacker guys with a mask, and says I'm gonna set my username to this in red. It's red because it's from a hacker, of course. Single quote or one equals one. So if you're not familiar with SQL injection, you might look at that and say, okay, what does that do? But what happens is when your query gets put together, it modifies the intent of your query instead of a where clause with one parameter, name equals username, and it has two conditions, name equals whatever or one equals one. And I don't know if your expert's on math, but one equals one is always true. So that's always gonna return true. So instead of giving you back one record that matches your username, it's now going to give back every record in your database. And this is the type of thing that introduces and allows these massive data breaches that you probably read about on the news, where there's millions of credentials floating around on the internet. Some of them might be yours, some of them might be mine. Now SQL was first sort of discussed publicly in 1998. It's really well understood. This is not a new attack vector. It's not an advanced attack vector. So pretty much this is fixed in every app on the internet. Right? It is? Question? Obviously not. Last year, Talk Talk, a big UK ISP or mobile carrier, 157,000 of its customers have their details stolen. They figured after the breach and all the handling of it that they lost around 100,000 customers and about 60 million pounds, probably about, what's that, $100 million US because of this breach. SQL injection, not advanced anything. Just that SQL injection that was first talked about almost two decades ago. Okay, but they're an exception, right? Right. VTEC, anyone with kids, this one's kind of scary. VTEC makes these little kid laptops for children and the children log in, they've got their name, they can put in their birth date and they got breached VTEC and they lost details on 200,000 children along with almost 5 million of their parents with home addresses, passwords, emails, names, et cetera. SQL injection, two decade old vulnerability. And this one, a bit more fun. Weatherspoon's Pub in the UK, they got hacked. Now this one wasn't awful. They only lost around 650,000 customer details and it was only phone numbers, dates of birth and email addresses. So no damage there. Oh, and beer vouchers, that's the one that really hurts me because these now shadowy hackers are drinking free beer on Weatherspoon's, so maybe they deserve it, I don't know. So this age old attack, almost two decades old, should be well solved. You're thinking probably, well, I'm a Rails Dev, I don't write SQL statements like that, I use Active Record, takes care of a lot of this for me. Well, after the talk, go take a look at this website here. If you haven't seen it before, railssqli.org. It's written by actually Justin Collins who's speaking right after me, so stick around to hear his talk. You would be shocked, I think, at some of the things that in Active Record look like they should be very safe. A function that takes a single parameter, like a column name or something like that in the case of pluck. And, but instead it actually internally really just kind of builds up these strings. So you can do, again, lots of arbitrary type of attacks like SQL injection. So it's still a thing after 20 years. This is code that you're writing. Now what about code that other people are writing? So this is a vulnerability that was announced at the start of this year. CV 2016, means it's 2016. There were, I think, four Rails vulnerabilities announced all in the same day with sort of a collection of things. This is credited to John Pullin from Invisium, company that does Ruby on Rails, consulting, security, they're really, really good guys. He's also got a blog where he describes this in depth. I've linked it on the bottom there. And I'm basically just showing you the highlights of his blog post, but it was reported as a possible information leak vulnerability in Rails. And it really, it's an issue if you have something written like this in your app, the render function, and you're rendering well anything where it's coming from like user-supplied input. So the idea here is I've got render params template so that I can have different templates for in this case, my users. Maybe this is the dashboard template. We're looking at the bottom, so you type slash dashboard and you get the dashboard template. If you do slash details, you'd get the details template. So it saves you some time, right? So if you look at the render documentation, it's not super clear what that first parameter is. Is it just the name of a template that then gets looked up along with all my other templates? Or is it a path to the template file within my app? Or as we'll learn, could it be an absolute path to my file system? And of course I'm talking about it because it's this one. So yeah, that same view, you add the percent encoded, but Etsy password, which is the database on my Unix systems that stores all of my user details, and dumps it right out. That's all the contents in there. Okay, so maybe an exception. What about something more Rails specific? What can you do with that sort of secret down there for session initialization? You can do a lot of stuff. You can basically forge any session data in Ruby because you can sign your own cookies. So basically, through this vulnerability, we can read any file on the file system that your web server would normally have access to. They call it a information disclosure, arbitrary file disclosure, or sometimes directory traversal, where we're sort of using these dot dot slash or absolute paths to get into things. And yeah, you can read any file on the system. SSL private keys? Probably something you don't wanna lose. What else do we have here? Secret tokens, secrets.yaml. These things on the bottom, not everyone's aware. Sometimes you put sensitive data into your app through environment variables so you don't need a file on your file system with data. Well, if you can read these proc file systems, you can actually read those environment variables just like a file. So you're not really safe no matter how you do it. If you've got this vulnerability, you're in trouble. Yeah. Okay, so bad. It's really bad, this vulnerability. If you happen to have code like that in your app, and I just did a quick search on GitHub for render params, give it a try sometime, there's something like 50,000 matches. It's not a rare occurrence, this thing, this stuff happens, but it gets worse. So there was another vulnerability in 2014, another CVE 0130, and Jeff Jarmak, I think this is his name, pronunciation, from Matasano, he wrote up an article and kind of dug into this, and it was a similar concept. Basically there was a way that you could convince Rails to load an arbitrary file on the file system. And he said, well, can I take this further and instead of just reading a file, can I actually execute arbitrary code? And of course, you can. And it really comes down to a helpful default behavior in Rails where you can, basically if you load any file with render and it doesn't recognize the extension, it defaults to treating it as an ERB template. So in the example before, when we were Etsy password, what we didn't really see is it was actually rendering that as an ERB template because it didn't know the extension. So for Etsy password is not a big deal, there's no ERB code in there. But if we can put ERB code into a file, like something simple like that, and just using the backtake operators, which executes shell commands, we can get that into a file on the computer and then get Rails to read from it. Then we can execute any arbitrary shell commands on that server that we want to. Who am I tells us the current user, but you can imagine we could put far worse things there in red. And of course again it's red because it's from one of those shadowy hackers. So the basics is we write code into a file and then we ask Rails to execute it for us. So how do we do that? How do we get code into a file in Rails? Well, thankfully that's built into Rails because every request gets logged to your log file, production.log. And I don't know if you guys have looked in it, but by default it's showing all your query parameters. So, great. My code, one, two, three, four. We could change that to something a bit more sneaky. Percent in code, there's our ERB data that we want to get in the file. Make a request and of course it dutifully gets written to production.log. So now if we put this exploit together, the first half, the new vulnerability plus this half the old exploit from 2014, we get the same idea. We get a single request. You feed in arbitrary shell code, send it to a vulnerable server and it executes. Yikes. So, okay, that's a vulnerability. What does that let an attacker do? So this is something that's kind of a bit new over the past maybe year, year and a half. It used to be all this stuff. If you could get files from a file system, you were trying to steal data, personal information. If you could execute arbitrary code, maybe you're trying to steal data as well or use the server to launch further attacks elsewhere or to further explore your infrastructure. But something new that started to come out is this idea of website ransomware. Now you've probably heard of ransomware, the normal kind. This is software that infects your computer and in the background, it goes around, looks at all your files and instead of deleting them like maybe malware used to do in the old days, it encrypts the files with a special key. And it's a key that you don't have. So now when you go onto your computer and try to use it, you can't access any of your files. And it pops up a helpful message that says, pay us $100 in Bitcoin or something and I'll decrypt your files for you. And it's really effective because the price is generally pretty low and people want their files back so they pay. So what started happening end of 2015 last year is the techniques started to evolve to websites. So primarily in WordPress type scenarios where it's the Wild West in terms of security but it's also affecting other apps as well. The ransomware, excuse me, gets in, executes arbitrary code, downloads a payload that encrypts all the files on your website. Maybe even the data in your database. And when you or your customers view your site, you get something kind of like this and it says if you want your website back, pay us the ransom. And like before, generally people want to pay. This is actually affecting hospitals in other types of server malware. It's a big deal, so just be aware that this isn't just people coming in and stealing data from servers. It's not just your customer's data, it's also potentially your revenue and your livelihood, your website. And now the other type of attack I'm gonna talk about is something called credential stuffing or that's what some people call it. And it's similar, basically the idea is some other site gets hacked. Maybe through some technique we just talked about or some other breach and the attacker steals a massive list of user names and passwords. Now chances are, and I think there was a study that said it's around 50% of user accounts are using shared passwords. So the password on your site might be the same as the password in the dump that that hacker just downloaded. And they wanna know which ones match your site. So what they're going to do is they're going to take that big dump, maybe it's a million, maybe it's 100,000 username passwords. And they're going to write a script that will go to your website and try to log in with those details. And when they find them, they know those accounts are active and vulnerable on your site. And if they fail, it's just a failed login, they just move to the next one. Excuse me. So I always like talking about this case because it's a bit interesting in terms of blame. Who's fault is it? Some other website got hacked. You might not be vulnerable at all to these SQL injections or arbitrary code execution. It was somebody else that got hacked. Their website got breached. Those are their user accounts that have been dumped. And it's kind of the faults of the users maybe, like maybe they shouldn't be reusing passwords. It's kind of their fault. They didn't choose strong passwords. Maybe they're that one, two, three, or five, six up there. But fundamentally, they're your users. The ones who these attackers are breaking into, these are your user accounts. So it kind of falls to you guys to protect your users as you're developing sites. How do you protect them? And this isn't just a small problem. It's not just common passwords like this. These are massive breaches with millions and millions of leaks. There was actually one just a few days ago. I really just pasted this for the headline here. This was a site that would actually help you find out if you were in one of these dumps. And then they got hacked. And now there's a consolidated list of what did they say? 866 million user credentials. So this site has hopefully consolidated them and organized them for whoever got them. So just be aware that this is not a problem that's being solved or going away. This was, was it two, three days ago? There's now a new, almost 900 million user names and passwords out there that might be coming to your site any day. And okay, maybe there's a bunch of passwords from this list that match users on your sites.  And maybe you could justify saying, well, we don't really mind if our user accounts get breached a little bit. There's not maybe a lot of sensitive data there or, you know, those users aren't admin. So maybe it's not that big a deal. So I wanted to talk to, through one use case or one attacker use case, I should say, where attackers are using these types of account takeover attacks to directly monetize the result. And it's something called warranty fraud. And this happened to Fitbit a lot in 2015. The basic idea was they used these techniques, the hackers, they got a bunch of accounts. And the first thing they did when they found an account that worked is they went in, they changed their email, they changed the phone number and they changed the address to the point at the attacker. And then they called up Fitbit and said, my Fitbit broke, can you send me a new one? And Fitbit wants to keep their customers happy. So they send out the Fitbit before they receive the broken one. So now the hackers are getting all these Fitbits. They turn around, sell them for half price or cheap on eBay or something. And they've now turned your vulnerable accounts into cash for them, which means they're highly motivated to do this. So there's always a way to monetize these things. So how do we protect ourselves against these attacks? Educating developers, that's probably why you're all here today. You're learning about security, learning more. There's great resources out there. The OWASP top 10 is sort of a quick intro to a lot of this stuff. It's the top 10 vulnerabilities that cause most of these breaches. And it kind of helps people stay up to date. They can see, they update the list every year or most years. So new attack types will bubble up as they become more prevalent and you can focus and learn more about them. There's static analysis. Actually the same guy, Justin Collins, writes Breakman and Breakman Pro. It will scan your Ruby app and tell you if you've got vulnerabilities. It detects the one I talk to right now. And it also detects the one from 2014. So use these tools to scan your code to try to stop these things before they get released. And imagine earlier the manual code review or maybe pen testing. Get other people to try to break your code. It's a good way to get a second opinion, to understand maybe things that you don't know about that someone else does. The big thing I don't like about this list is it's the same list I would be sending out 10 years ago if I gave this talk. Nothing's really changed here. There's no new defensive techniques that are helping people these days. So this is still good. You should still do all these things and they help you produce a secure app. But then once you deploy it, how do you kind of protect it against stuff happening in real time or against new threats that maybe you don't know about? There's a few tools that already exist for this kind of active defense. There's a thing called a web application firewall. You may have heard of it. It kind of became very popular when it became sort of a mandatory requirement for PCI compliance for handling credit cards. But basically it's a box that sits in front of your app and you can kind of see, sorry, it's really small, but you go through every single URL in your app and you tell it all the parameters that you expect to see. You tell it whether they're mandatory or not, how long they should be, what sort of characters you should expect. And you can kind of get from this that it's hard to configure.  It doesn't really know what's going on. It's just applying these rules or signatures. And there are actual books about how to bypass web application firewalls. So it doesn't give us a lot of additional security. There's also kind of a problem with how they're deployed really. So you've got your apps down there on the servers. You've got the internet cloud classic over there. You've got the yellow line, bad stuff being rejected. You've got your web application firewall protecting your app. And that's all great if your deployment looks like this. But more and more these days, our deployments look a bit more like this. It's the app is the thing that you deploy. It's not the infrastructure around it so much anymore.  And you want security to go with the app. And that's where we kind of get into one of the defenses that I'm gonna talk about today is this concept of rasp. Never been a big fan of the acronym, but it stands for runtime application self-protection. The idea that it's part of your app. It gives your application the ability to protect itself in real time. And it's kind of shifts the story a little bit. It's inside the application now. So we kind of get a bit more visibility on what's going on. So if we go back to our attack there, what was the actual exploit that happened in that CVE vulnerability? The vulnerability was that we could convince Rails to load an arbitrary file. But the actual exploit, the malicious intent, what they're doing is they're trying to read files that aren't normally read. Or they're trying to execute shell commands that aren't normally executed. So can we hook into that and instead try to stop that? Move that logic inside the app. And you can see these things happening directly. We're not sitting outside the box trying to guess what might happen when it hits the app. Here's some examples, what you can do. I mean, you shouldn't be reading anything from Etsy Password really. You should only be writing to Virolog and temp. It shouldn't be writing some arbitrary places on your file system. Your app should not be reading your SSH private keys. Shell code execution. Most apps don't actually need to execute system commands. Or if they do, it's usually in just a few spots. Like maybe you need to compile some CSS when your app first starts up. Or maybe you need to shell out to the command line to generate a PDF invoice or something like that. But generally you're not executing shell commands. You're definitely not downloading Perl scripts from Russian IP addresses and executing them. Like you should not be doing that in your app, right? So can we detect these things happening and stop that? So instead of tracing all the individual and trying to chase the vulnerabilities as they're announced, stop the malicious behavior. Same idea applies to those other attack types, SQL injection. We can see the whole SQL query. Can we stop that at the source? So instead of trying to guess at the bad input, look at the full query before it gets sent to the database. Stop that. Same for templates. If we're rendering the template, can we look for cross-site scripting then? Authentication, failed logins. Inside the app we get visibility of all that stuff. And as well, the application, it knows itself, right? It knows which lines of code are running these things. It knows which lines of code are running SQL statements. And if you get an SQL statement that looks abnormal, it knows where that came from in your code so it can work with the development team a lot more closely and help them understand where these vulnerabilities are coming from. This is sort of the general idea of how a rasp can work. This is not all of them work like that, but that's the idea, that you've got your app in blue. And then you add the security logic and it gets a chance to hook into all the various parts of your application. So it can protect against header-based stuff, it can protect against SQL queries, it can protect against authentication failures. And what that lets us do is if we take our old example of the SQL injection and we look at some possible inputs, first one is a good query. Most of the queries from that line of code will look like that. So we can learn that structure. Your where clause should have one condition. And then when the bad input comes in and all of a sudden that line of code is executing a query that has two conditions in the where clause, flag that up as an attack. And of course we know it's an attack because it's red and the other one's green. I actually had somebody tell me, why don't you just stop the red ones instead of all this logic, but that's the idea. And same for things like the authentication. Instead of just blocking failed login attempts and allowing successful ones, we can start to look at the rate of failed logins. Most of your users, if they forget their password, if they're like me, maybe they might have to try, four or five times before they get it right. But they shouldn't be trying a hundred times. And if they cross these thresholds, you should take action to stop them. You can do something like automatically serve a captcha or just block them, whatever you like. So back to these three types of vulnerabilities. Talk through a few examples. These are all, like this provides tools for you to address some of these issues because everybody's writing code, we're all using external code and nobody has time to write all the code that possibly they should be writing. If you can land a rocket on a barge in the middle of the Atlantic Ocean, surely we can make it easier to make websites more secure. Leaving with that, thank you very much.


Let me start by saying that I'm delighted to be with you today, but I'm very sorry that I'm not with you in person. I'm in fact going to New York in the next couple of days, but simply couldn't be there today. I'm delighted to have this opportunity because I think we're at a crucial moment in the development of a process relating to migration, which really needs to be pursued by the global community, a global community which comprises the United Nations and its various arms and its various parts, and IOM. I think let me start by saying that we're fortunate today in having in Bill Swing somebody who to me epitomizes all that is best in the whole area of multilateral responses to a crisis of enormous proportions. I need hardly go through with you the dimensions of that crisis, nor need I identify in advance some of the deficiencies in the structures that enable us or should assist us in the institutional responses that we need to this crisis. It is a crisis that is born out of terrible events, particularly in Syria, but elsewhere also, which have driven a flood of refugees across the Mediterranean and indeed in other parts of the world, like the Andaman Sea. And it's a crisis which demands a global response, which has not always been forthcoming. On the other hand, opportunities often arise historically as a result of crises, not always, and we can't be complacent about the crises that we're suffering today in respect of migration, driving the type of change that is necessary. But a crisis can be an opportunity, and if there is a moral response to the appalling affront to the rights of man that is available for us to see daily on our screens as people take to the seas in dangerous conditions to escape persecution, then this is one of those occasions. We have to make choices as a global community, and member states of the International Organization of Migration and of the UN more generally, have to deliver not merely financial resources, but also commitments to resettle or relocate migrants who are leaving their countries in dreadful circumstances. We also have to recognize that the issue of migration is a complex one. It doesn't just relate to refugees. The broad constituency, often described as economic migrants, also have rights. They have rights in the context of human rights more generally, but also they have a right to concern of the global community and can be driven by events just as destructive and dangerous as those which drive refugees. On the positive side, last year the inclusion of migration in the sustainable development goals and in the 2030 agenda for those goals was a triumph. When I think of where we started from, we can recognize that much has been achieved. In the past, migration was not recognized as a powerful tool and force for development. Now it is. I think attitudes have changed in this context. Over three long years of advocacy, we made an indisputable case. Many of us in particular IOM played a role in this for the inclusion of migrants and migration in the SDGs. We succeeded. Now we have an inclusive, ambitious SDG agenda. This agenda promises not to leave migrants or refugees behind and it recognizes the benefits that migration can bring both to those migrants, the broad constituency of migrants and to the societies from which they come and to which they go. Migration, therefore, is an important factor for inclusive, sustainable growth. At the same time, it highlights that forced displacement threatens to erode development goals and gains. The potential of migration is now part of an agenda and we have to ensure that that agenda is complied with. Member states have agreed and taken on commitments to facilitate safe, orderly and regular migration and also to promote decent work for migrants, including migrant women. And for an example, to reduce the costs of remittances, which we all know can make a substantial difference to the overall receipts of development support in countries of origin. In addition, in the Addis Ababa Action Agenda, the pledge of states to reduce recruitment costs, promote social security, portability, something that many states do not allow currently, to improve skills recognition and promote access to financial services for migrants is now part of an agenda that has to be actionable and delivering on these commitments will meaningfully improve the lives of millions of migrant workers. Words are cheap. Action is now demanded. We're still at the level of rhetoric. We don't know how this will translate into widespread change. The situation on the ground remains dire. We have today over 60 million men, women and children who are displaced, 20 million of whom are refugees, tens of millions more migrants are victims of human traffickers, smugglers and rapacious employers and exploitative recruiters more generally. The sum total of their suffering is vast. Something has to be done about it. The need for the international community to adopt a coherent, clear and defined agenda and in its approach to migration is obvious and it's also morally imperative. Nonetheless, the failure of states to act is blatantly clear in the devastating images of migrants that we can see in our television screens almost nightly, tales of destitution with bodies lying on beaches in the Mediterranean, in the deserts of the Sahel or in South Central America. For far too long, governments have taught that safeguarding their sovereignty means going it alone. It doesn't. We live in an interdependent world where moral responsibility does not seeks at one's borders. As we've seen in the Mediterranean, an approach of this kind, even if it weren't morally wrong, is self-defeating. It leads to paper-thin sovereignty. The reality is it doesn't work, apart from being morally repulsive to simply close one's borders and forget the rights of refugees or those escaping from a vulnerable situation in societies around the world. Rather than burden shifting, we need to put into practice the global public good of responsibility sharing. I've said many times that proximity doesn't define responsibility, yet 60% of all refugees are hosted by just 10 countries. 86% incidentally are hosted by developing countries. We have been championing a greater role for the UN in addressing the current crisis. The UN, I think, is now set to host a series of conferences that may be of considerable importance. Earlier this month, we had the International Community Conference in regard to raising money for the Syrian crisis, and over 10 billion was pledged. We began a paradigm shift. The international community now must move on, whereby we'd have to deal with issues relating to and for an example, resettlement. We need more in terms of commitments in this area. Then we have the World Humanitarian Summit, following the meeting on the 30th of March in Geneva, which should get greater commitments in regard to resettlement. The World Humanitarian Summit in May will try to create long-term blueprints for many new approaches. Humanitarian admission should also incidentally be part of what happens on the 30th of March, including areas like student visas, family reunification, and so on. Then in September, on the 19th of September, the Secretary General will host a high-level meeting in the General Assembly. I hope this will lead to a sharing of responsibility, which is palpable and clear, and part of the global responsibility to address large-scale movements of refugees and migrants. Together, these various efforts and these various conferences should generate commitments to greater global responsibility sharing and safer pathways for refugees and other forced migrants. They should also enhance the UN's capacity on migration, including a commitment, I hope, to work towards the inclusion of IOM in the UN family. We really need this. It also should allow us to strengthen capacities of national migration and asylum systems and bring in new actors, including from the private sector. All of this would demonstrate real progress towards a key commitment that governments agreed last year with the SDGs. It will take bold political leadership, facing down many of the xenophobic and indeed racist responses that are to be found in various parts of the world to the current crisis. It's time, therefore, for political leaders to rise above the type of debate which in many countries has paralyzed constructive engagement with a very difficult crisis, a crisis that challenges our generation as earlier generations have been challenged by other horrible events. Thank you for listening to me.


aren't actually good evening, but I say the afternoon is quarter of nine. Eastern timing is definitely not afternoon. My had time flies when you trade. Anyways, here's Twitter. I thought I'm gonna go over this. This is Melissa with the stockswish.com. Basically, 134. Look at that. Look. That's crazy. 134 million shares we're trading this today. It's pretty wild, isn't it? And that is wild. Let's take a Twitter. Here's a stock. The IPI opened last year. The exact date of it actually was November 7th. They priced this a lot better than they did Facebook. The stock broke a little teeny weeny bit after the IPO price opened, but lifted itself almost immediately and rally. And actually the way this broke was not a bearish gap like Facebook. If anybody remembers this, I did a video on Facebook a long time ago. This broke the low of the IPO price on the second day, but it actually didn't gap that way. So it held, okay? Held to the buy set up here. Rallying, rallying. It made new highs very quickly. The stock price basically doubled almost from the IPO price. It pretty much did. Now, this was a good place actually to sell out of this here with some profit. If you were long with stock, it had a lot of opportunity in here to continue higher. It didn't do it. Here it could have continued higher. It didn't do it. Now remember the market has been coming in somewhat. So the fact this was coming wasn't like the end of the world. I didn't like this gap here. I think this was the earnings and I just wasn't crazy about it. I didn't even give it a little bit of a thought. I didn't really like it that much. Today though, when I got up and saw this gap here this morning, I said, oh, this is good. Now, let's go look at this chart. Look at this move today. The dream target on Twitter today was $33. It, far as exceeded that, it went all the way down to looks like $31.72. It went $1.30 more than the dream target. I mean, this is exactly what can happen when these stocks want to roll over. Sometimes it's unbelievable. If you shorted every one minute rallying this today, probably a state of this trade until the low, but really $33 was enormous from their first move. But it went way past that. That's another reason why sometimes you just, you know, every once in a blue moon, you'll be in a trade and you let it follow it down. And the market did help this today. That's probably why I pushed down more than a dollar. I just, you know, it's really, really one of these things where you have to predict the market movement right to get something late in the afternoon to stay with it if that's what you want to do. Now I'm going to put something out on this. Here's the trade I called here. It was very reasonable. Entry was $35.61. And again, it went huge from there. It went $4 from this move. But I want to point something out here, which was the open. When I reviewed the Twitter in the morning, it had, I think, 8 million shares pre-market. That's a lot. And I actually thought it should rally first and then set up. And I thought if it set up immediately without rallying that it wouldn't hold, would possibly get stopped out and then set up again. I know it worked no matter what. I just didn't know the way it was going to formulate itself here under the open. The fact that this, I want to just, I just want to look at this bar here right now. Just look at this bar. This is the open of the price. It's almost 2 million shares into the open. That is almost unbelievable. It's almost like the best thing I've ever seen. And I'm going to have to put this actually in the gap class. Because this, this is 60 seconds. 60 seconds, 2 million shares almost came into this stock in 60 seconds and held. This didn't rally. The next bar wiped it out massively down through itself and crushed it like a sandwich. Now, this happened here. It doesn't matter. This is still an unbelievable short here. And this is, I can't say enough. When I saw this this morning, I was almost like, because I missed really the volume that came in here when I called this. If I had seen this, I would have called it earlier. But actually, this was valid. But this, I mean, this is like, I mean, the stock did this and held. I mean, I can't tell you what that means to have 60 seconds worth of that volume going up. Okay, so here's the resistance to push up and hold itself like this did so quickly, so much volume. That is incredible. I've actually never seen anything like it. I mean, I've seen this set up over and over and over and over and over again. But this is the most volume I've ever seen in this type of setup. It's almost shocking. Because remember, there was 8 million people for the open pre-market. So 2 million come in here. That's like 25% of the initial people. And that's what I was concerned about. The people will be shorting it, covering to the open, and then it would break. Instead, 25% of the people covered it, 75% didn't, found it through to the downside selling, selling, selling, selling, selling, selling, which is what pushed this down here in the first place and made the gap by the way. More selling came in. And then the shorts came in and then the stock fell over. And it just wasn't even getting any lift here. I mean, it was this couldn't rally to save its life at all in the morning, not at all. I don't even think there's three green bars in a row here. Let's look. Here, the only three green bars in a row, and this is a baby green bar, is after 10 o'clock, the stock didn't have three green bars in a row to rally in the one minute chart until 10 after 10am. That's really something. So just to review, this is a huge sign of weakness. If you don't know what I do, you wouldn't notice see this. And at the time I saw it called the train, but it could have been called even more aggressively. I didn't I didn't I didn't see the volume here in this initially. And then I saw it after the fact and I was like, Oh, my Lanta. So new is to say, you know, this is definitely lower. I mean, this, this is real. This is real. Twitter is no longer in uptrend. Twitter is now in a downtrend. The downtrend and Twitter is going to continue. It could drop off a plan in here even tomorrow. I don't know if that's going to happen. But I wouldn't put it past this actually getting in tomorrow as a continuation gap. If it doesn't, it may back off for a day or so. But you know, this is a problem here for the Twitter now, it's it's lower. And what are you going to do? I mean, it's a short. It's a short is a defined short. And it's a short now until otherwise noted, Twitter is officially in a downtrend after the day. And I think it's very important to notice this. You know, and who could have guessed? I mean, but it didn't. And I knew it as soon as I saw it. You know, I was talking about this to somebody today. When you are a trainer and you learn what to do, you develop yourself through your eye, your eye tells you now I write the gaps and go through the process and do what I do every day. I follow my system, I follow my structure. But lots of times I can see something. And my eye just sees it. I see it. I just I see it. I see it before it even does it. And that's kind of how I saw us today. You know, and, and there's many, many days that happens. And I think if you train your eye to read socks correctly, you can do the same thing. Of course, you have to know what to look for.  In fact, many people are training their eye to do things that are not right. But, you know, once you learn how to train and know what's right, your eye gets trained and then becomes instinctual. And you go through the process and it confirms it and then you train your eye and you get better and better and better and better and better at it. And that's why I can call some of these things ahead of time before they even do it. And, you know, Twitter is kaputzi now and this it's in a downtrend and I don't see any recovery for this anytime soon. This downtrend Twitter could last as long as it wants to last. We'll have to see. Could it flip? Yes. Have we seen that happen sometimes in socks? Yes. Is it likely to happen on this 50-50 but probably not because this relationship happened? Okay. And particularly, I'm just going to point this one thing out and let everybody go, because the gap down here failed. I wasn't crazy about this and it was not a short this day. But the gap down here failed. Gap down failed on Twitter here. So if it wanted to support itself and it wanted to hold, if it didn't want to create a problem for itself, it could have done this then on the gap down failure and rally and forget the market for a minute. That's not the reason this gap worked today. It helped it to go to some crazy target I didn't even ever written down. But it would have worked anyways. This would have worked anyways no matter what the market did today. And that's the great thing about gaps. That's a wonderful, beautiful thing about gaps. So this is Melissa with thestockswitch.com. Have a great evening. Everyone have a fabulous night. I'll see you all tomorrow. The Golden Gap class is this weekend May 10th and 11th. If you're interested in signing up, email me at Melissa at thestockswitch.com. Thanks to everybody. Have a great day.


Welcome traders to another tickmail chart hit with me Patrick Munnally. We're on the four-hour time frame here and we're looking at the Dollar Swiss. We have now potentially completed the initial impulse move off the January lows here subdividing nicely in a five-wave pattern and this fifth wave has now developed to ultimately test into the target area of the 9450 zone that I talked about in previous reviews and we're now seeing potential here for a bearish rejection candle and what I've been looking for is a breach of the trendline support here through 9410 to set up a move to ultimately test the fourth wave low back to 9218. We've also got some nice momentum divergence supporting this trade thesis. So watch for the break 9410 and stop just above the highs. As always traders plan the trade, trade the plan and manage your risk.


Military Sealift Command has two storekeeper positions on board. These individuals are responsible for the proper performance and administration of all supply department functions, assigned in accordance with directives and programs. You'll be responsible for the day-to-day operations and maintenance of records, correspondence, reports, returns, and obligation records for all material housed on board or needed for our customers. More importantly, you are responsible for proper receipt, stowage, distribution and transportation of fleet cargo, mail, freight, personal effects, and unaccompanied baggage, as well as tracking all shipboard hazardous materials, receipts, issues, and stowage. Knowing where everything is is a big responsibility. Are you up for the challenge?


I didn't hear a bad joke, so I'm going to make some of my own. All right, so let's talk about choosing your own abstraction, specifically iterating on developer experience. I'm Rosemary Wong. I'm a former platform engineer. Now I talk to a lot of platform engineers and developers trying to find the right kinds of interfaces for a platform. In recent years, we've really focused on the right platform interface. This turns out to be really complicated. It's a long discussion that ends up across like two weeks, three weeks. At one point, I think it took four months for me to work with a team to find the right platform interface. And eventually, the first iteration of a platform tends to be infrastructure as code. So you'll choose some kind of tool that creates your infrastructure as code somewhere, and now everybody has to learn it. But then you hear this terrible statement that makes your blood curdle, I don't want to learn it. And it's a fair statement. Sometimes, as developers, you don't really want to be learning a different domain-specific language, or you don't want to be learning a different programming language that you're using to create infrastructure or platform resources. And it turns out that, well, we have a solution for that. In years past, we've used the UI or CLI approach just to make it better. So this could be the form of a service catalog. This could be a form of any UI or CLI. And the idea is that you can onboard your developers to the platform. This comes at a price, though. The higher level your interface, the more standardization you get, but you don't get the customization. So if you have certain use cases that can't use a UI or CLI, or have some specific needs, you still have to learn some infrastructure as code. However, you still get to handle the 80% of use cases that someone's going to use to provision a platform. And so that's where Backstage comes in. Most folks now are looking at some kind of UI CLI that provisions a set of templates somewhere, a GitHub repository, all of the components you need. And if you want to bundle a database with it, you can provision the database using infrastructure as code and a bunch of templates. But what about updates? This is the place where everything sort of falls apart. No matter how many times I've helped folks build a platform, we always forget about updating the platform for some reason. And it turns out the right platform interface has to account for updates as well. And that's where now we've thought about GitOps, right? The idea that we can continuously deliver any changes to our platform with some kind of declaration or manifest using some Kubernetes interface. And this kind of makes it easy because you can make changes with a familiar interface. If your developer knows Kubernetes or some kind of Kubernetes interface, they can make changes through the GitOps mechanism. So any framework you use will continuously deploy those changes, reconcile, and see if there are differences or drift, right? And GitOps has become this middle ground for the right platform interface because now you get the customization and standardization, but then now there's a common interface for developers and platform to understand. And so in this case, maybe I'll show something like RGOCD, but in any GitOps framework that you're using, you'll often find that day two operations involve some kind of break glass scenario. That means that anytime you need to make a significant change and you're kind of worried about it, you probably don't want to continuously deploy it. And so you'll look at your GitOps framework and assess what the blast radius or criticality of the resources you have. If they are extremely critical resources, you'll turn off any automatic synchronization, you'll pause it, and then you'll have to go back and reconcile it. So in this case, right, I'm going to keep things out of sync until I make changes somewhere, and then I'll come back and synchronize it so that it's all updated and everything is the correct version that I expect. So this works pretty well. Except what happens when there's the absolute disaster scenario. So forget like day two, but maybe it's day three and it's exploding, right? This is where the escape hatch becomes more important. When no matter which way you choose, no matter which interface you choose, you need an escape hatch and guess what, it's version control. So anytime you go in and you make a change to version control, that as it's sort of lowest level interface should cascade to every other interface that you have. And this is kind of complicated, but for the most part, I think we've all established that we've done everything as code, whether you're doing it through Kubernetes, some in infrastructure as code, or any other programming language, we're all doing it in version control by now, and we're able to push those changes out. Now there are some nuances. If you're making some changes and you need to make break glass and you need to go to a console, you have to go back all of your layers of reconciliation so that everything in automation makes sense and you don't have that drift anymore. So in the end, you have abstractions with options, right? You have many different options in the form of a platform interface and you can choose whichever one you want. But at the end of the day, I hate to tell you this, but you have many, many, many of them that you'll have to support. So whether it's infrastructure as code, to GitOps, to UICLI, a lot of the ecosystem you see now has all of them for you to use and for your developers to be happy. Thanks.