Good noon everyone. Hi. First up, I hope I'm audible. Right. Welcome to the session. You see it's basically me and a shout out to my co-presenter Arun who isn't able to be here today. The agenda of the talk today is largely around how we at Hike Messenger, I hope you guys have heard of us, stumbled across the entire DevOps journey. And now that we've reached a destination, for us it's still an ongoing journey. But the larger focus of the talk is what is it that we really do, how we stumbled upon it, where we felt the need for it, and how did we go around solving for specific challenges that we came across, and what were the generic tool chains and how we ended up using them. All right. A quick intro on who we are. We are a messaging app that's been growing up in India.  We have almost 100 million plus registered users. We have a presence on both iOS and Android, based in both Bangalore and New Delhi. Our primary competitor is in the market and this is exactly where the real meat of the talk comes into the usual big boys. The Whatsapps, the WeChat, the Snaps. Now, as you could see, the kind of competition we have in the market are most of the big boys. Either they are part of firms who have been doing or been in the game of scale for really, really long, much longer than we have been. Or they have been bringing their journeys and their experiences into the same field onto what they're doing in the field of messaging. So we already have the scale. We have the primary problem statement of serving multiple users, like a lot of users at all. The quest for user delight for us becomes a key thing. Messaging as all of you would probably know and even agree to is, I would say a user is a fickle entity over here. I mean, Whatsapp recently launched stories just like Snap did and people didn't really take very well to it. But on Snap, it's a huge hit. Google has been trying its own strategies and everybody's been trying to throw their hat into the frame. Apple has an entire platform that powers messaging. But to be very frank, it's very difficult to crack the holy grail and say this is what flocks the entire user base to us. It's a very social platform. It's an ultra competitive market. User traction is key. And while it's very easy to acquire users, all it takes is an app install. It's very difficult to have user retention. We also had to tackle the problem of a diverse text stack. We are a firm that usually goes ahead and says we don't restrict. We are not particularly a Java shop or a Python shop or you call an object C shop. We dabble in almost everything when it comes to our server backends. We don't even put much of a restriction on what build tools or what utilities we are really using. We have a micro-based services-based architecture. We have more than 100 deployable services in the back-end that come together to present what comes out on the app to the user. And each of these services has obviously the mandate of moving at their own pace. And therein the problem statement depends because you need to have dependency management, you need to have orchestration, you need to have similar problems. The last build is testability. Well, the moment you start talking about the scale, the moment you start talking about the number of services that we have, testing it and making sure that the user experience isn't hampered or isn't broken in itself is a big problem statement. Now, looking for answers to all of this, we kind of stumbled on what is that DevOps would essentially mean for us. Now, to be very frank, for us DevOps might be a very, very different statement altogether than to probably a lot of you guys. Our DevOps machine statement eventually was a very, very simple one. A scalable test-driven vision with no tech bias that allows us to hit market faster to delight our customers. If you look at this statement once again, you realize that most of our problem statements in the last slides are addressed over here. You want a scalable system which is obviously test-driven to ensure that we always deliver the higher quality. There is a needn't be a tech bias. Whatever platforms, systems, tools, methodologies we use need not be tied to a given tool. And we should be able to swap and swap out any particular entity in the entire ecosystem at any given point in time. And we need to hit market faster. I mean, if we have something that we think is really, really going to attract the user base, we need to hit it and get to the market rate much faster than our competitors. Or if our competitors are doing something, we want to probably follow in the same footsteps, we still have to move really, really fast. And delighting customers, as always, I'm pretty sure it's true for most of you in this room as well, is key. So this is what a 10,000 feet view of DevOps looks like to us. For us, DevOps was essentially finding answers or about solving problems in three key spaces. The very first one was around change management, which obviously involves incident management altogether. How do we really take a particular change? Shepherd it all the way to production, making sure that it's not blocking other changes. Also making sure that if it's not right, how do we take it out of the entire pipeline and let the others come in?  For example, how do we maintain a code? How do we maintain versioning? How do different entities in the system actually end up exchanging? Having handshakes with each other is also something we'd like to talk about later. The second bit was test automation. I'm pretty sure I need not speak a lot on this entire scope here because there has been an entire track devoted to test automation in an agile world. Let's just say that our problems weren't very different from what you guys would have been hearing over the past couple of days. But the third part is actually very, very interesting, which is configuration management. Now the reason why we said that configuration management is the third pillar in the entire exercise for us was because when people started testing all of these massive number of services and each wanted to test their own features, we simply said we can't test everything on a single environment. You can't really keep throwing everything on a single environment and say, hey, if it works here, it works here. If it doesn't work here, it means it's broken. There are issues with reproducing a problem that you would find. There are multiple problems. Maintainability of that environment is a problem. It's a single point of failure and so on. Now the need for having multiple environments altogether, the capability to have people provision their own test environments and so on. Also making sure that the wiring of those environments is pretty much as it is in our production environment led us to config management being the third major point here. Now, if you come down one level altogether, this is a broad breakup of what all we really wanted to take a look at. If you look at change management, SCM best practices, like we said, how do we maintain our code? Branching? How do we do our tagging? Our versioning? Everything else over there was something that is very, very instrumental to us. It's the first principle without which no matter how much you think you can, it's very difficult to achieve a higher state. Code cleanup and refactoring, obviously, when we started, we were basically yet another startup. As it happens, people tend to move real fast, accrue tech depth over a period of time and before you realize it's grown so large that other activities become really difficult. Software packaging and versioning, like I said, it's again something which is very, very important to us. We understood that while it's very, very tempting to say, let's just do a git clone on a machine and do it, in a lot of aspects it's not the best thing to do around there. Also, software packaging is very, very key when you try doing environment and configuration management too. The last piece of it is build pipelines. How do you really propagate code from point A to B to C and eventually to production? Do you really have machines doing it for you? Do you really have people doing it for you? Config management, like we said, config as code, which means you cannot have hard-coded entities or hard-coded endpoints in your entire code base. You have to have configuration as another deployable unit that you deploy along with your code.  Configuration cleanup was also a similar activity that we had to do. When you look at code cleanup and refactoring, configuration cleanup was a corresponding activity, which is removing all those hard-coded endpoints, making sure everything is configurable and contextual. When we were doing software packaging and versioning, we realized that config packaging and versioning also goes hand-in-hand. How do you make sure that your deployment is just a code deployment or config deployment or both? We wanted to be very, very sure regarding what does a deployment mean to us. At the end of the day, the puzzle was very, very clear that it's going to be either code or config or both. Build pipelines obviously had to utilize disposable test environments. Every time you have to run functional test cases sometimes, integration test cases, component-level test cases, mocking takes you only so far. As in when you start moving towards the tip of the pyramid, you start realizing that having disposable test environments to offset costs of maintainability, of ownership, of other overheads that come with it becomes a key solution. I'm presuming that most of the folks here are also involved in some amount of testing. How many of you have actually aware of the same test pyramid that does the rounds in any? That's surprising. That's another philosophy that we followed a lot, saying in terms of testing, we want to be bottom-heavy and be as specific as we go to the top. Whenever it comes to your unit or component-level test cases, you're going to have a very high test density. As in when you move upwards the pyramid, you start making sure that while the scope of your test cases becomes wider, the number of test cases has to be short and sweet. That actually allows us to reduce a lot of time when we are looking at UI failures or app UI failures. Third part was, like we said, test automation, unit, component, functional, and integration, which is why I talked about the test pyramid. As in when you move from unit to integration, the test density has to slowly decrease. Test cases have to be more abstract. What they verify has to be extremely precise. I heard somebody speaking in a session today that your test cases are supposed to serve a single purpose. You try to do too many things in a singular test case, you end up with more flaky test cases than more definite ones. What did a toolchain look like? I mean, looking at all of these challenges. Some of these toolchains were pre-existing into the system when we started working on it. Some of them needed a slight tweak, a slight change. Some of them were introduced because we needed them. We primarily use Git. Our source code has always been on Git, obviously a private instance. This is where a lot of our branching mechanisms were forged. We initially had enough discussions. We realized that the standard Git branching model is something we can really exploit, but it's something we weren't using up to its full efficiency. As of today, we do our branching and tagging along with our versioning, but it still does not mean we do Git deploy wherever it's applicable. We ensure that all our deployments are via an artifact. Jenkins is where most of our build pipelines, our build jobs are hosted. It's a fairly standard tool. We did contemplate saying, hey, why don't we go with, you know, Runner or some other tool that's usually available, a hosted tool that we can host our pipelines on and run it. The answer was fairly simple. We first wanted to solve all the problems we would have on first principles. With our first principles, like branching, like a versioning broken, moving to any of their tools cannot solve your problem. And this is one of our key takeaways from our entire exercise. As long as you don't fix your first principles, no tool can help you because any tool you're going to go to will ask you to eventually follow some kind of a pattern. SolarCube is something which we used a lot for doing our code analysis. We did a lot of static analysis, a lot of our test results, both unit integration were essentially hosted there. And actually we built a lot of tools on top of SolarCube as well that allowed us to get a lot of data out of it. It went into a lot of management reports where we could do release, which we could use for release postmortems. We could use it for getting more information out of SolarCube. Not just SolarCube dashboards, but we actually ended up using SolarCube APIs to give us a lot more data. Artifactory is what was our choice for storing artifacts, right? For reasons why we ended up moving to Artifactory was, like we said, we are a diverse tech stack. We have Java, we have Python, and we do dabble with a couple of fancy technologies we'll talk about as well. And we realize that we don't want to have an overhead of maintaining separate repositories. It's easy to have privately hosted repositories, but it's always better to have some kind of a susami knife. Chef is something we still use for config management, especially for deployment to our production systems. It is again something which was a tool that was pre-existing when we started work. We said we are going to let it be, we are going to make sure that the handshake between Artifactory and Chef is as clean as possible. Going with the philosophy of tomorrow, if we do feel the need to replace Chef with another tool, it should not be a problem for us at all. Docker. And that's something that we use a lot today. Around six months ago, we only had one or two teams which were trying to use Docker to have their own test environments. We realized that there's a lot of potential over here. And as of today, we have systems and capabilities that allow people or a developer, beat anybody in the system, to actually generate an entire ecosystem with just one click.   The entire environment is wired exactly in the same way as your production systems are. There is absolutely no ambiguity there. The same point in time, the data management layers, the data processing, everything is simply a clone of what's miniaturized clone of your production environment. Coming to the testing bit, we had a pretty interesting problem there to solve as well. When we started as a firm, we had a lot of people who were into manual testing. And as in when time progressed, we realized that we need to have automated tests. When we started writing automated tests, the challenge was not just to have automated tests. The challenge was also to provide growth to the manual testers whom we had in two reasons. One, they knew the system inside out. They had worked on the system so thoroughly, they knew the system inside out. We wanted to leverage their knowledge and have it converted into automated tests first. Rather than saying, we would want to differentiate between the two. So we ended up writing a small layer of cucumber translation onto standard APM test cases, which allows our manual QAs to actually write cucumber feature files.  And this is something that we actually use for our regular app level automation. STF is something we started using because we maintain our own device lab. For again, reasons which are both old and new and probably org specific. We have our own device lab that we maintain pretty well using STF and the number keeps on growing. I would actually be more than happy to answer questions at any given point in time than wait till the end of the presentation. So if you folks really have questions, we're more than happy. So basically our notion behind this is fairly simple. Along the entirety of a pipeline, you have certain milestones. You have certain milestones, for example, a piece of code moves in from its own feature branch into a mainline. From a mainline, it probably moves into the master branch or the tag. And when it gets built, we want to simply cut off the probability of saying that on a production machine you can actually go ahead and do a git clone using a deploy key that has its own security risks. And then it becomes very cumbersome, especially if you're using languages like Java because you have to compile it all the time.  What we do over here is the Chef recipes and cookbooks that we have, they actually pick up their artifacts from the artifact tree repose. So they pull it from there and what we say is the build pipeline will continue working and at the end of it, it will just go ahead and publish an artifact in the artifact tree. And the Chef recipes are the ones who now basically come ahead and pick it up from the artifact tree and deploy it into whichever environment we feel like. So its artifact tree is just a place for handshake for us. Any other? I wouldn't want to say why Jenkins was not used because to be very frank, if you have Chef recipes, nothing stops you from executing Chef recipes from Jenkins. To be very frank, the subsystems that we have built on top of these technologies, like how do people provision their environments and how do they run a bunch of their test cases, how the pipelines are, it is all based on Jenkins. Like we said, Chef is basically one of our legacy systems that we have, something that we've been using even before a lot of this work was done. So as and when we are moving from a continuous integration world to continuous delivery and deployment, we are planning to actually cover it in one of our maps. Also, like I said, we are also playing with a couple of relatively newer and cooler technologies where we actually have to see which way we want to go. We have integrated it for a few teams. Like I said, the way we look at it is we don't, while we have our broad level rules at the entire organization, teams have a liberty of moving on to the pipelines at their own pace because that is how it moves on a microservices base to it. Any other queries on this? Please. When you talk about deployment servers, are you talking about production deployment or are you talking about non-production? So like I mentioned, most of our non-production deployment happens via Docker because it allows us to have a very, very miniature version without putting in a massive effort. That essentially, so if you look at it, all the hosts on which the Docker containers run are nothing but AWS AMIs. So we are, again, heavily AWS focused like most of the startups in any space. And even with Chef when we do production deployments and we do auto scaling, auto scale ups and auto scale downs, those are largely AMIs that are spun up. But what we make sure is whenever we are running containers, the AMIs are just being used as a base kernel image and that's all. So configuration management and infrastructure as code probably from our perspective are not exactly the same things. For us, configuration management to begin with from where we were, again, like I said, it's in our context, was about removing the hard-coded endpoints and other application configurations outside. So when you're spinning up a Docker instance or when you're spinning up an environment using Chef, all you need to do is supply it a configuration file and that needs to be there.  Infrastructure as code is again something that we are, like I said, we are looking into. That's probably a little towards, I'll talk about a little towards the end of the slides because that's part of our v2 that we are trying to do. And that is moving more towards how do we get rid of everything and have things done very, very quickly and have reproducible environments altogether, whether it is in terms of, like all the way starting from your AWS VPCs to your subnets to your AMIs and then eventually code and not just code. So that's how we usually like to define infrastructure as code whereas it's the entire team. Any other questions or queries around this? I'm more than happy to answer them. So we basically started doing Docker as reproducible test environments for non-production. So again, this is another takeaway we had. Doing it on non-production environment definitely has a lot of benefits without you paying any of the major penalties. But when you're running Docker containers in production at scale, you really have to look at each of your individual services as to whether they are going to be latency issues or not, any other performance issues or not, whether the application in itself is written in a way that you can probably cluster it together. For example, if you look at, I'm not sure if you're familiar with Kubernetes. Perfect. Now, when you look at Kubernetes, Kubernetes, its initial releases said that you have to do it for stateless applications. A stateful application based on a Kubernetes architecture is going to bomb massively. We did have a couple of stateful services in our legacy architecture which we said we can't really take it there. So that's a classic case where you wouldn't want to run Docker in production. It's never going to end well for you. So we wanted to be cool kids. We didn't want to be cool kids with cool age. Any other questions? When you define compilation, we do have Jenkins Slays which do our builds and they intern our Docker slaves. So here's the thing, as it goes with deployable services and containers, they have to be immutable. So what we do is when we form a container, we have the binary inside the container, but you don't have the compile time tools. It also makes your image heavy and you won't want that. They have to be really lightweight. Build agent as well as for our services, test environments. So at any given point in time, the way it usually works is when developers, like I said, we wanted to move towards a very strong test-driven approach. So giving that capability to our developers allows them to spin up an environment for themselves, change their tests there and then pass it on onto a build or then raise a PR request or move on to our test teams. Say, hey, this is at least tested good enough. There are enough unit tests. There are enough functional tests or component tests.  So it's more like environment as a service. I saw your hand. How do you? Thanks for asking that. Like I mentioned, probably would have slipped. We usually don't do tech bias, but when it comes to first principles, we are very biased. Versioning is something we do take seriously. And in multiple places, if you look at versioning, we do semantic versioning more or less. On the app side, it's actually a very easy world for us because the PlayStores and the AppStores of the world allow you to stick to that. You'll be able to submit your apps. On the server side of it, what we usually do is in a lot of ways our branching helps us to automate our versioning too. Now, there's a slight contradiction if you look at from how semantic versioning actually works. The semantic versioning spec says that the developer making the change is the one who actually updates the version. But we try that initially and there's a lot of a few developers weren't very comfortable doing it. They said, you know, we probably don't want to get into it right now. But here is a simple baseline. So what we ended up doing was we ended up using our Git branching model. We ended up implementing versioning. So what happens is we have a mainline on which you will always have a particular version. There's a tag that's always symptomatic what's running in the production. Every time you do a hot fix, you check out the tag. The build server has a job to check out the tag, updates the versioning on the hot fix part of it, does the build, tags it again, pushes it back into mainline and moves on. The same is with feature branches. Every time you actually have to promote it, the build server actually, if you guys know Maven release plugin, that's exactly what we do for all our languages. We have a small version bump thing for Python and other script circles. I saw one more hand going up so far. So is it only for static code analysis? Static code analysis for us is just one of the users of SonarCube. We also end up storing most of our test results over there, along with the data. One of the really good uses we actually have for SonarCube is, I'm not sure how many people have ever explored their APIs. They have very rich API set and we use a lot of that API set for our reporting. A lot of times when we do release post-modems or release retrospections, we pull in a lot of data from SonarCube because it gives you a lot of trending data, not just the dashboard data. So what we do is we actually pull in data from Git APIs, from Sonar APIs, with AnarJira. We combine them together and then we basically use it to derive more and more intelligence and information around our releases. So we have a lot of API level stuff that we associate with SonarCube. Not just static code analysis. Any other questions around this? Great. So this is how it really works with us. Any developer in our ecosystem codes a feature. What we do is we actually integrate SonarCube into all the IDEs. We have that capability. So developers don't really need to submit their code to see what the SonarCube analysis would look like. Every time they just hit Command S or Control S, the SonarCube binding just runs it in their IDE and tells them what are the potent code violations that they would be. That would be there on that piece of code. They also run unit and component test cases, which is something on which we over the time slowly have started having a more and more tight SLA on. They run functional tests for the feature. Now the functional tests over here are largely applicable on the app side of it because we use Roboelectric and a bunch of other tools to do that. Once the local dev deems that the feature is good enough for submission to mainline, a PR is raised. The moment a PR is raised, the build and release infra kicks in. The PR is captured via standard webhook. We run the static analysis on the entire change set. What we do is we take the change set, we merge it onto whatever is there in mainline, we run the static analysis on change set, we run all the unit tests. We do a code review. When we actually posted for code review on GitHub, we post all the static analysis comments and the unit test results on the PR as well, so that the person who is doing a code review has enough statistical data and he or she just has to go through the logical part of it. Once the code review is done and the PR is merged, we basically build the mainline for reality. The earlier part that you are looking at, this is a Fox merge. This is part of your pull request builder that you would have. It does not actually merge and come in the code into your repository. But the other one over here is a post merge job. As soon as you merge it, its job is to build out a release candidate all together. The standard philosophies say every time you merge into mainline, you're supposed to generate a release candidate. That's what we essentially do. Once we do the mainline, we run component insanity tests on instrumented code because we also want a lot of coverage data out there. We run functional test cases on instrument code as well after which we run into a nightly build. Nightly build is where we run full regression and when we say full regression, this is most of our app level test cases because these are your APM suits that take APM slash cucumber suits that take a lot of time and we don't want to run them every time a mainline build is done. Every time we do a nightly build we run a full static code analysis not just on the delta of the code change that's coming in. We also do a lot of benchmarking a lot of perf tests and dynamic analysis which is basically code coverage and other data too. And once all of this is done, thing goes into artifact tree. So what we are saying is that we've essentially broken the entire pipeline into four major steps. The very first step usually lies with your local developer. Because the local developer has the tools to be able to spin up an environment to actually have an application with which he can point to the local environment instead of some other server, the developer can actually essentially debug everything on his or her own box. Once that is merged, the entire build and release pipeline. Now if you look at over here, there is absolutely no mention of any particular language or a build tool because this pipeline holds true for everything that we do inside our ecosystem. And that is what we meant that our choice of tools has to be very very simple and they have to be easy trade-offs. Tomorrow if we decide to replace Jenkins with I don't know Bamboo or some other CI runner tool or probably replace artifact tree with Nexus or any other alternative we don't want the entire pipeline to be impacted. We just want that particular change to be simply swapped and we are done. So this is an interesting way on how our nightly build runs. Now if you look at it from a client perspective, the client essentially needs a server environment which always works. So what happens is we actually have a boundary where we say that the server CI kind of comes in. It has a blue-green kind of a state. There is the last known server build that is essentially running and it is exposed to the client for our nightly builds. And there is a separate server on which we take the latest release candidates and keep running the test cases. If the latest server code which is the RC passes through and we say everything is good, we actually swap the two servers. And the client build and we obviously make sure that it does not happen when the client test cases are running but at any point in the day when the client test cases are not running the engineering deployments keep on happening. So in the nightly whenever the client test cases run it is guaranteed that they are always running against the most stable server environment altogether. Potentially this is what summarizes our entire experience with our exercises. First of all DevOps is a massive cultural shift. The amount of effort we had to put in building all of these systems was nothing compared to the kind of effort we had to put in to convince all our stakeholders. Like with every traditional startup we had the usual questions are will this slow us down no this is a lot of process no this isn't but everything works. Why even move this model? And the answers are fairly clear. Point number one, we don't want to call this process, we call this too late. The idea is whenever you say that people have to go through a repeatable process or a repeatable way of producing software certain first principles come into play which is why initially I said no tools going to solve your problem if you don't fix your first principles.  You can't be a under 10 cricket player and then expect that you'll play international cricket right? The second is legacy is not a blocker for DevOps you will be surprised that a lot of our services which follow this model today and actually work on it probably are not traditional microservices they don't really have that clean abstraction between you know concerns or dependencies which is why as somebody asked do you guys also run containers in production the answer is we are slowly revamping it to say we want to rearchitect them to say we want to run containers and services but does that mean we are not going to do the stuff we can do with them? Absolutely not. You've got to start somewhere you've got to make small progress iterative progress and then eventually hit the overall continuous deployment goal. The last piece is something that I've emphasized a lot upon is decoupling between different pieces of pipeline all the tools that we have essentially have a standard boundary through which they communicate it allows us for better tuning or customization like I said if you're not happy with Jenkins some given day you can always throw it out bring something else you see you like it also allows you to prototype you can always save a bunch of your services can be moved to another tool altogether and if you see that the competitive benefits are worth it you slowly move the or migrate the entire thing in a monolithic fashion right and it's also very mission centric that tool centric we never ever really wanted to build our dependency on one given tool we didn't want to be extremely dependent on one tool to say oh you're like we're done if this tool goes away if this tool doesn't support us and it does did happen with us by the way we were using Appium and Acocombo framework and Apple did funky stuff and they introduced there was a lot of leakage in our iOS test suites and we had to contend with it a lot of time those of you who've been doing iOS automation using Appium would have also faced the same thing of late well luckily it's on a path to be fixed but then we were also jolted the good part was since we didn't have to put all our eggs into one basket we said okay we can all possibly start exploring other options altogether the last bit is metrics like I said you have metrics all over the place if you don't treat them well they'll become rapid noise for you you'll have trouble making sense of them eventually you'll be very tempted to throw all of it out of the window the idea over here is to pick up metrics probably aggregate them depending upon the level at which you're viewing like we said when we sat for release post modem when we said for release post modems we said for release retrospections we do not look at each individual line or each individual day we actually aggregate data using a lot of APIs do a lot of correlation together and then arrive at what is working and what is not it helped us a lot initially to realize that we weren't able to track all the pull requests that were coming in initially why? developers weren't putting a G-R-I-D to it how did we do that? the moment we saw the trend we said in apia builder if you don't attach a G-R-I-D you will not be able to merge the result was pretty much so a bit of friction saying hey this is process but then over a period of time even they realize that it helps a lot especially when it comes to debugging that's pretty much what the session was all about I'll be more than happy to answer questions if you folks have on continuous deployment on devices we do continuous deployment on our test devices right we have actually so we do maintain our own device lab right and we use it we maintain it using stf so we're using stf and other than that we usually use adb heavily for android right for apple we are now slowly starting to look into what's in it sorry oh yes so device failures are one of the things that we run into we had a homegrown solution earlier that helped us to only communicate to devices that were up and running and off late we have started replacing it with stf right like I said when you have a lab you need to be you can actually put in measures to make sure that your devices are always up and tools like stf make sure that they are the perfect routing medium to make that your test cases run only on the devices that are up any other questions it is purely a function of like I said usually they go to the artifact which is on the release release repository after the nightlies but the snapshots are usually available after the third cycle so once you merge right we take we basically build a release candidate depending upon project to project it could be it basically a function of probably let's say 4 or 5 minutes once you merge into mainline to probably a few more minutes but generating RC's is what is the easier part right RC's don't take that much time especially on the server side of things test cases are usually quick there for us when the longest pole is around 30 minutes which is validation of a big chunk of a server side piece it's not something which is completely into a microservices architecture but like I said we work around it we run around 2000 API test cases on it and if it all looks good we basically say the PR is merged the moment you merge it you will have the release candidate there and then all the testing happens on the release candidate next question there are places where we maintain them both as the actual binary format as well as the docker images so what we do with Jenkins is when we actually build it the Jenkins job produces one let's say suppose a jar or a war and the other is the docker image the only place where they are correlated is they are versioned similar they are versioned similar so if you are building 1.1 of a given jar the docker image will also be called 1.1 and that's how versioning really helps well like I said we have our own limitations we are definitely exploring Kubernetes big time and we really like what it gives us like somebody said infrastructure as code Kubernetes is pretty awesome you maintain a YAML and you can reproduce the entire the entire data center level ecosystem your AMI everything gets yes it is just that Kubernetes in itself is solely for containers Terraform is a more open-ended tool you need not use only containers for Terraform Terraform also works with your AWS, AMIs and other so all the internal all the internal artifacts that we generate go on to the internal any other questions of course interesting question so this is exactly where human bias I don't know if it's useful or not right every time so how do you say that a code is reviewed so you've taken your code you've taken your code so this part right so you take your code you run static analysis you make sure that there are no major increments SonarCube again has multiple levels so there are blockers there majors there minors so on we run all the unit test cases they have to pass and then submit it for code review now technically your static analysis and unit test cases right they have to be in a state where if you run them and you don't find any alarms you say this is good enough but a few teams are not very comfortable for it what it takes for us is just one take onto a Jenkins job that says please merge if you find everything okay so we have the capability to do that some teams request us and say hey you know what you might just want a line in code review there are a couple of teams who are actually comfortable with it and say you know if it's if you see a tick just merge it don't come to us right and there's some teams that say hey we still might want a pair of eyes going through it so like we said it's more about comfort yeah precisely so we are not we don't have the capability what we are saying is this is where we basically listen to stakeholders as well right if there is a stakeholder who says hey probably we are for the timing we are more comfortable with the code review we go with the disclaimer saying this will slow you down you would rather invest that time in writing much more better test cases and making sure that you are not really you know causing more violations or anything but then it's all a symptom so they say no we are more comfortable with it for the time being there were a couple of teams who were initially said we are comfortable doing code reviews later they realized they said oh you know what we already have so many unit test cases we have a good coverage we don't we haven't hired any untoward incident or not much of code command set have come in past two releases let's just go ahead and enable it by default so that's where a lot of release retrospection helps us you pull out all that data from github from sonar you put it together team said together say hey what do we do with this data now does this data mean that we can go ahead and automatically merge yes or no so our job is to build systems that can do things but for us most of it is a switch that we can turn on and off I think we are out of time perfect thanks for being an amazing audience it's definitely a pleasure being here have a good day


Personal finance practice problem using OneNote. Stock price calculation assuming constant growth and dividends. Prepare to get financially fit by practicing personal finance. You're not required to, but if you have access to OneNote, would like to follow along. We're in the icon left-hand side practice problems tab in the 12 to 20 stock price calculation assuming constant growth and dividends tab. Also take a look at the immersive reader tool, the practice problems typically in the text area too. Same name, same number, but with transcripts. Transcripts that could be translated into multiple languages either listened to or read in them. We're thinking about investments in stocks, stocks representing an ownership interest in a corporation. Corporations being separate legal entities that have the ownership interest broken out into fixed units of stocks or shares. We're also typically thinking about publicly traded companies. Those traded on public exchanges, allowing more transparency and access to individual investors to things such as the company's financial statements for example. You also wanna keep in mind your investment strategy when investing in individual stocks as opposed to say mutual funds and ETFs. We're focused in on the individual stocks at this point analyzing for example, the trends and the underlying fundamentals of the actual one actual company or corporation. Also, you wanna be thinking about these types of analysis in terms of how they fit into your overall investment portfolio, which again, you might be using say tools like mutual funds and ETFs or if you're using individual stocks, then those individual stocks would need to be thought of in total to think about how they fit in your overall investment strategy. So now we're trying to think about the value of a stock, say the price of the stock or what we think the value of it is so that we can compare it to the current price that's being determined by the market and see if it's over or undervalued possibly helping us out with investment decisions or selling decisions at that point. So we're gonna do so using a strategy similar to what we tried to do with the bonds. What we would like to try to do is think about the future cash flows that are happening, present value them back to the current period to help us to determine the price. It's a little bit more difficult with the common stock and then with bonds to do that because with bonds, everything is set within the fixed income of the bonds meaning we know exactly what the interest payments will be, we know exactly what the maturity date will be, we know exactly what we're gonna get at maturity and then we just have to figure out what we think the appropriate discount rate would be and then discount the annuity of the interest payments and discount the present value at the end of the maturity date and that would be how we can kind of value the price of the bonds. With the stocks, we have two ways that we're expecting to get a return on the stocks, you'll recall. One would be that we're hoping to say get dividends, which would be a return of the earnings in the corporation to the owners with the distribution of dividends which is similar to draws for a partnership or say a sole proprietor for example, except that in say a partnership the different partners could get different amounts for draws and the partner themselves might be facilitating the draw that they would like to have whereas with the corporation, all stocks need to be uniform, no one stock can take a bigger dividend than another stock although one person could own more stocks than another person therefore the stock strategy or dividends to be distributed would be determined by the board of directors and by management by in essence the company. And then we also might get a return for say the increase in the value of the company, possibly they're growing and that would be reflected in the stock price so that we can sell the stock at a larger amount in the future. So remember between those two strategies in a normal business cycle if the company went all the way through the business cycle it would look maybe something like this and more of the growth stocks would be down here where we would expect not to have as much dividends but the growth would be much higher at this point that would be like when Apple was growing and they're not gonna give a lot of dividends but they would be giving a lot of value in the shares going up so that you could sell them at a higher amount. If you're talking about this flat area up here that would be like Apple now possibly or say like a utility company that's well established they don't need to reinvest but they're well established and we would expect dividends to be somewhat more constant up here. So we talked about a situation before that would be a little bit more easy for us to apply this strategy if we make the assumption that the dividends are gonna be somewhat constant and that we're not gonna have as much growth because we have a well established company. If we're looking at companies down here and we're using this strategy to try to value future cash flow streams then we gotta think about dividends way out into the future what's gonna happen once they become established and what will be the dividends so that we can discount back or we try to take into consideration the growth that is happening and that's what we're gonna determine now adding that added level of complexity. Okay, so we're gonna say then that we've got the annual cash dividends are 10 paid each year we're gonna assume that those are constant but we're also gonna assume that there's growth meaning the value of the stocks gonna go up by the 7% the required rate of return for the common shareholders is 20% this is how much for example we think that could be received from other investments of a similar risk nature so that's the rate that we have to kind of clear in order to make it worthwhile for us to be purchasing these stocks. So we're gonna say okay so the annual cash dividend is 10 and this will be our quick calculation then we'll try to understand it with cash flows a little bit more in depth the return after growth so if the required rate of return we need to get a rate of return of 20 and we're thinking that the stable growth rate will be 7% now of course how would we know what this stable growth rate is? We don't right we're looking at the trend we might look at trend analysis in the past and see if we can extend that trend into the future we're gonna say we think the value of this stock is gonna go up the price of the stock for example is gonna go up we're gonna get a return in the value of the stock going up in addition to the $10 per year the $10 per year how do we know what that is again prior dividend policies that have been put in place and the company will most likely want to keep stable dividends into the future or possibly increase dividends they typically don't like to decrease the dividends because it's a bad signal to the market so that means that the 20 minus the seven there's a 13% return that's gonna be related to the dividends so if I take then the $10 dividend divided by the 13 we get to that $76.92 so we're gonna say 10 divided by the 0.13 which is the return we need after considering the stable growth would give us the price of the $76.92 let's see if we can think that through a little bit more here we can try to say okay one way we can kind of think about this and this would be similar to a bond calculation if I was trying to compare this to a bond what we do with a bond is we take the present value of the annuity payments and present value of the amount we receive at maturity and add them together here we have this stable growth so we can't really you know that that's gonna be the growth rate that's already kind of in place so what we're really doing is we can say okay let me try to present value first one way to understand this let's try to present value the $10 that we're going to be receiving using the 13% rate of return so in other words we're already getting 7% taking care of by the fact that we think the stock price is gonna go up let's try to use our present value of the stream of payments which would be similar to the stream of payments for say the interest portion of the annuity calculation for a bond so it would be present value of the rate and so we're using this 13% instead of the 20 so we're using the 13% comma the number of periods again we don't know what the periods are in a bond we would because we would know what the maturity is the maturity date so we're just gonna pick a large number because in theory this could go on forever but again this $10 like a hundred years out into the future discounted back at 13% will be a very small number so that's why we can kind of pick a large number for example then comma the payment is gonna be the $10 and once again we get to that 76.92 now we can also do if I do the present value using the 20% this will be I'll try to make this kind of feed in and see why it kind of makes sense to do this 20 minus seven like if I took the present value of the rate which is at the 20% comma number of periods we're gonna say 100 again and the payment then is gonna be the 10 we would get $50 so keep that in mind we're gonna use that in a second here but let's think about this in terms of breaking out now again you could get more complex than this and say well what if the dividend payments like changed in the future and I think they're gonna go up well you could actually map them out what you think the dividend payments will be in the future for example from year to year and then use the same concept but taking the present value of one of all future cash flow periods for example so that's one way you can build kind of a more complex model using the same kind of assumptions so we're gonna say okay so let's say that for example if I had the total dividends and we'll do the same kind of calculation but we're gonna map out periods or years one through 100 and we're gonna say okay if I took the 10% dividend and we did our present value calculation which I don't have right here but it would be the present value similar to this calculation it would be the present value of the rate which again I'm gonna take at the 10 what was it 13% and then discounting it or number of periods is gonna be one and then it would have two commas cause we're looking for the future value which is gonna be that $10 so if we brought that back then the $10 discounted back at 13% would be at the $8.84 and again if we did that all the way through as we've seen in prior presentations then we could discount two years out $10 would be at the $7.83 about and all the way out if we did that all the way out to the end for 100 years you could see as we saw in a prior presentation when we just did the $10 would be quite small 100 years out very small fraction of a penny right so then so that's why we can sum that up when we get to our $76.92 which we had up here so just another way to do that we can also do that I'm gonna now recalculate this number the $50 so we could say I'm taking the same $10 so it would be the rate is now gonna be the 20% the number of periods is gonna be one this time it would be one and then the future value would be the $10 so now we're discounting the $10 back one year but this time at the full 20% rate of return and we get to of course a smaller number because this one we discounted using the 13% and so that's gonna be the 8.33 if we did that all the way across we get the same thing and again it gets quite small at the end so we get if I sum this up we get the 50 so we've recalculated this $50 now the reason I did that is just try to get an understanding of what we're gonna do with the growth so if we tried to say for example if we started with this $50 that's like let's assume that's the original price with no dividends and then we said that there's gonna be an increase in the value because I'm gonna try to represent in flows this 7% increase so in other words if I start at that 50 that we calculated up top and we said it's gonna increase by 7% each period and we do do this in Excel if you wanna do this in Excel 50 times 0.07 would be another 3.5 and then I'm gonna add that to the 50 which would be 53.5 or I can say okay one or 100 plus 0.07 7% would be 107% or 1.07 times the 50 and that would give us to the 53 about if I take that and I multiply it times 1.07 we get to the 57 about if I take that times the 1.07 you can see the increase that we are getting as we go forward. If I look at the difference then between periods we're gonna say okay the stock price went up from 50 to 53 because there was a 7% increase that's 3.5 which you can get by subtracting these two or you can get it by taking the 50 times the 0.07 right it was a 3.5 if I do that all the way across you can see we have a trend that's different than the dividends that's why this gets a little bit tricky to think about my future benefits here because and remember these are not actually realized it's not cash flow this represents the increase in the price over time which I would only actually receive in cash if I sold the stock. So we could say okay then you can see that's gonna increase and you can see this one actually goes up so you gotta be a little bit careful with this calculation because if it's a large increment of increase this number out into the future can be quite large whereas of course when we were taking the $10 it's the same all the way out into the future so if I discount that stream of value into the future we could say okay let's first I'll do the same thing with the dividends the dividends are at the $10 $10 so that means that basically the benefit into the future then if I add those two up is gonna be for example we had the 3.5 increase in the value of the stock plus the $10.13 and then in year two we got the 3.74 plus the $10 it's 14 and I didn't put the pennies down here but you can see how it you can see how it's gonna basically increase because this number right here is increasing because there's a rate of return of growth whereas this is a fixed dividend that we're assuming is going out into the future okay so then if we calculate then our present value of all the streams of future value that we're receiving at the 20% the full 20% now we got the 13 and the next period we're discounting it back 20% for one year so we're taking that 13 that we're getting in the next year in value part of it being the dividend part of it being the increase in the value of the stock we're discounting it back 20% we get to the 11, 25 and then in period two we're discounting that 14 something and change it's rounded discounting it back 20% for two years we get to the 9.545 and so on and so forth notice that as we get out into the future then of course because of time value of money we're gonna get less value but we can also see that this is increasing at 7% so we've got that kind of a little bit different of an activity if I go all the way out here to 100 time frames you still get a fairly small number because this rate of growth was only 7% but if this rate of growth becomes significantly high like if it was 20% or 50% or something then this number way out here is gonna be is gonna be quite large right because of that and that can kind of skew things out a bit now we're out here way out here saying a 7% increase so meaning before if my value of stock 99 years later was at 40,547 times times 1.07 we got the 43,386 minus the 45,47 that gives us our 2,838 so that's a pretty big number in and of itself but 100 years out it's still relatively small so that means that we can kind of use a similar the same kind of method discounting back here and if I add all that up that gets us to the 76,92 the 76,92 that we calculated up top so that's an attempt to try to see why this kind of simple calculation up top works and is somewhat similar to us trying to trying to look at the future cash flows or future value that we're gonna be receiving not just in cash flow and essence but instead trying to think about the constant growth that we're gonna get in the value of the stock and take into consideration the cash flows and again remember if you use a concept like this then you could get more complex calculations by assuming the dividend's gonna go up periodically I mean maybe it won't go up constantly maybe you're thinking 10 years it's gonna go up or something like that and you have a staggered growth if you break it out on a year by year kind of break out then you can have more complex kind of analysis of these into the future and again this is only one technique that you can use to value stocks obviously you might favor different techniques of the stock valuation and these kind of valuations typically are more solid if you're looking at established companies that have an established dividend because this assumption that there's a stable growth is a large assumption that you'd be based in on past data for example. So there's that.


We had a great fortune of having MIT's Media Lab fellows come in to speak with our students about life strategies and we called it Media Lab Strategy Day at Automotive High School. It's important for an institution like MIT's Media Lab to reach out to communities all around the country, particularly in underserved communities, because it gives the students an opportunity to interact with great people, with great technology, with the kind of ideas that can make a substantial difference in their lives. Any partnerships between high schools and post-secondary schools are very important because it helps students build a network and it helps also students recognize that there's something outside of high school. Baratunde Thurston spoke to the auditorium about his life and about how he uses comedy as a political activist to make a difference. The very first book I remember as a kid was this, it's called This is a Part-Time. That's something I haven't read for eight years. Ryan Chin spoke to the kids about the future of cities, how electric cars will impact the way we drive and the way we live. This is a story that we designed, it uses in-field electric motors, it's foldable, and I'm going to show you a video of both of them. Can you put it like in a bag? Juliana Rotich spoke about her work in Kenya, bringing technology and expertise to a place in the world that really needs it. Shaka Sengor spoke about his time in prison, the impact of violence in his early life, about how he was able to change his life using writing and how he continues to change the life of others speaking all around the country and the world. Then I had another student came to me and said, Mrs. Stanzik, that man was very interesting and he was referring to Shaka, they were quite taken with Shaka and Bartunda did a great job of waking them up this morning so we were very happy about that. So I believe that it was very, very well received. The event was tremendous, the students walked out, clearly moved, clearly thoughtful and clearly hopeful for their futures and about what they can do to help change the world. I have to on behalf of my students we owe Mr. Ashley a debt of gratitude because he made this possible for us.


Welcome to Data Doctor's video, Suggestion 803, Almost Empty Profile. Suggestion 803 is caused when there is almost no text in the biography, such as equal signs, the name of another site, only one heading, just the unsourced template, or a horizontal bar. There should be a biography heading with a written biography and sources. Here is the Suggestion report for Anna Burgess. There is one Suggestion 803, Almost Empty Profile. The info column shows the number 10. That is the number of characters in the biography. In this case, it's the word deceased. Here is the public view of Anna's profile. The data section has some information. However, the biography section only has the word deceased. We could add the basic unsourced template, biography heading, and sources heading with the references tag below that. But that still leaves an almost empty profile. We need to look for sources. On the top right, hover over Herwicky Tree ID, and on the drop-down menu, click on Research. Root search gives us several sites to choose from. Since Family Search is free, let's start there. Note, you have to be logged into that site first. The first entry is for a 1900 U.S. Census that lists Anna with her father, Chandler Burgess. We have found a source and can now create a biography. Go to Anna's profile and click Edit. In the biography section, remove the word deceased. Add the biography and sources headings with the references tag beneath the sources heading. Write a short biography based on our source. Now, to add the source for the census record, go to the Family Search results, and on the far right, click on the icon. The next screen shows the document. On the bottom right, click on Document Information. Copy the citation that appears. Return to Anna's profile and place your cursor at the end of the sentence. Click the Citation button above. Paste the census source between the ref tags. Click on Preview to check your work. Make sure that the inline citations are properly showing in the biography and sources sections. Go to the middle of the profile page and explain your changes. This is strongly recommended for all Wikitree users and is required for data doctors. For me, I identify myself as a data doctor. Copy the suggestion number and name and explain what I changed. Save your work. Take this opportunity to add relevant sources to this person's relatives profiles. Return to the Suggestions report and on the far right, click on Status. On the Suggestions Status page, make sure your Wikitree ID is showing. There is a related suggestion, 134, which has already been dealt with and is not applicable here. Next, of the five status options, choose one. In this case, correct it. Leave a comment from the comment hints or make one of your own. Click the Update Status button. The last screen shows the status history has recorded your changes and you're done. You are invited to like this video and even leave a comment if you wish. Also, keep up to date with new videos by subscribing to our Wikitree YouTube channel. On behalf of the Data Doctors Project, thank you for watching.


Hey everybody, it's Brian, and we're going to begin learning Yee 2.0. First off, Yee is a framework. It's a PHP framework, and if you Google frameworks, you will see that there are a bajillion frameworks out there. Why would you want a framework? Why wouldn't you just write your own code? I hear that from people all the time. I don't need a framework. I'll write my own code. Well, it's because you'll start writing code to talk to a database, then you'll start writing code to present the information to the user, and then you'll start writing code to let the user modify the information. Essentially, what you're doing is building your own framework. You're reinventing the wheel. So it's just smarter to use a framework that already exists. It's already been tested. It's already been debugged, and it just works. The problem is there's billions of frameworks out there, and each one of them is different. Like Zen framework is really used on a more professional level, but I've heard good things about Larevel, if I'm saying that right, and Coding Knight. Symphony I've heard is pretty good. I haven't heard much about those others, but I actually prefer Yee. I actually went out and did a one-hour walkthrough on each framework, and Yee's the one that really stuck with me. Why? I don't know. It's just personal preference. Everybody's going to have their own preference, so Yee may not be for you. The typical web lifecycle, the user makes a request. The request goes to a server. Server goes to the database, which then builds the web page and sends it back to the client. This is web server 101. I'm just making sure everybody understands the lifecycle. Making the assumption that everybody watching this video understands that whole process, and you know the foundations of PHP enough to make basic web pages, and you're really looking to move more advanced stuff. Yee is a model view controller framework. Now what does that mean? It's an MVC pattern, which almost every popular website out there uses, and for good reason it's very efficient. When the request comes in, the controller, as it is, controls the flow of data. The controller will take the request and analyze it and say, okay, well, I need information from, say, a database. So it grabs a model. Now the model is not a database. It's a representation of the data. The data could be in a database, in an XML file, or just in memory. This depends. So the controller will talk to the model or representation of the data and say, fetch me data. I need this. Or it'll create the data depending on what the request is. The model hands the information back to the controller who says, now that I have data, I need to render a view. So it takes a template called a view and plugs the information from the model into the view. It takes that rendered view and sends it back to the client as the rendered response. So that's the MVC pattern in a nutshell. Congratulations. I just saved you two days of sitting in a computer class listening to theory about MVC patterns. It's really just that simple. Request comes in, talks to the controller who gets a representation of the data, bam, bam, right up to the user. It's that simple. So if you go to Yee Framework, you'll see that it's fast, scalable, and professional. Yee stands for an acronym of yes it is. Is it fast? Yes it is. Is it secure? Yes it is. Well, you get the point. There's a little caveat you should understand right off the bat is there's two distinct versions of Yee. If you go to downloads, you'll see Yee 2.0 and Yee 1.1. Don't be fooled into thinking that 2.0 is just an upgrade from 1.1. They are two totally different frameworks. They worked on Yee and they got to 1.1 and they said, you know guys, this really isn't what we wanted it to be. It doesn't really follow the Yee vision, if you will. So they said, all right, we're going to leave 1.1 up for legacy, you know, in case you've got a website out there and you need the code base. But we're going to scrap everything and start over. So Yee 2.0 is a complete rewrite of the Yee Framework. Oh, yeah, that's a lot to digest, especially if you're like me and you spent a lot of time learning Yee 1.1. 2.0, I actually like it a lot better than 1.1. It's a lot more flexible and it just, once you get it, it just clicks. Now to install 2.0, it's a little tricky. You got to use something called Composer. I don't say you got to. You can actually download the tar GZ and then install it yourself, but it's such a pain I wouldn't recommend it at all. So we'll use something called Composer and I had no idea what Composer was until I actually went to install Yee and I had to read up on it. And if you have no idea what it is, we'll actually talk about it. You can just click here and there's the directions on how to install Composer. I'm not going to get into how to install Composer because, well, it's a little bit beyond the scope and it's just dirt simple. Basically on Linux, I had to install CRL and then I just ran that command and then you just follow the directions and it just runs. You'll know when it's installed because you can go to a command line and type Composer and you get the Composer command line. Now on Windows, it's a little bit different but the instructions are there and it's pretty simple. You literally just call PHP and then read file and then you set it up as a bat so that you can run it and then it just works. So why do you need Composer? I mean, this is a tutorial about Yee. What is Composer? I kind of grumbled and said, I don't want to mess with this Composer stuff until I started really reading about Composer. If you click on Browse Packages and then let's say Image, you see there's, well, of course my cat wants to talk to me while I'm recording. Hi, kitty. You'll see there's 96 pages about images ranging from how to resize an image, how to convert a PDF to an image, how to validate an image, et cetera, et cetera. I mean, just so much code and it's all in PHP. Now this is ready to use code that's already been tested that you can plug right into your web app. Makes it very easy. And you can install all this by, you guessed it, Composer.  You should be embarrassed, kitty. Now there's a cat here floating around. All right, so let's bring up my var, dub, dub, dub, HTML. This is where I, hi kitty, just jumped up on top of me. Get down. Daddy's recording. God, this cat, I swear, he's starved for attention. So here's my directory and we're going to actually run this. Now you should note that the directions on the website don't work for me. They say type in phpcomposer.phr and then all this stuff. If I do that, I get an error message. But if I just type Composer and then the command, it works fine. So just know that your method may or may not work the way mine does. So the first thing you want to do is do the global require. So let me actually go into, make sure I actually did that right. Yep, eh, I cannot type. And you'll see how Composer will sit there and churn away in the background and make sure that all the dependencies are updated. And maybe I shouldn't have done that, but we'll let it run. There we go. Nothing to install or update because I've already done it. Now if you skip that step and you just jump ahead and make a website, your website's not going to work. You need to have that. That's a prerequisite for ye. Now you should note there's two installations here. One for basic and one for advanced. Basic as well, if you guessed it, basic. This is your website, this is your store's website, this is your own little search engine, you know. And when I say basic, you can actually build some pretty advanced websites with this thing. Now if you go with advanced, well, it's exactly what it sounds like. It's advanced. This would be like your amazon.com or your walmart.com. These are massive websites that will have front-ends and back-ends and multiple teams working on them. We're going to cover primarily the basic site because, well, we're at the basic level in this tutorial series. So we're going to grab this. We're going to make sure we're in the correct directory because this was, you know, very directory dependent. And we're going to say composer. And it's going to churn away. And in the background, what it's doing right now is it's installing ye via composer. And it's installing all the prerequisites and doing what it needs to do in the background here. Let me actually move this over so we can see. And hopefully this doesn't take too long or I'll just pause the video. So while that's churning away, let's see, yeah, it's actually created the basic folder. Now this is different in the sense that ye1.1 will create what's called a ye route.  Oh, okay, good, it's done. You see how it's done its change mode, change mode, et cetera, et cetera, so we're done here. Now the basic structure of ye website, this is essentially what it looks like. And I'm going to bring it up in NetBeans. Whoopsie, I've got some code up here. Let me close that. This is like my third take at this video because things just keep going horribly wrong like the cat interrupted me, like the little monster that he is. All right, so this is our basic website. Now I'm using NetBeans, but you can use pretty much any editor. This is the folder structure of a ye2 website. You see how you've got assets, commands, et cetera, et cetera. We're just going to drill through some of these assets. Well, you really won't need to mess with this too much. This uses what's called a bootstrap, which tells you where it needs to go and what it needs to look for. Commands, these would be like your cron jobs. If you don't know what that is, it's basically like a command you make the web server run in the background. Like if you want to make a command that goes through the database and gets rid of all users' accounts who haven't registered after 30 days, that's what it would be. Config, this is kind of the first thing we're going to mess with in future tutorials. This is the configuration. So like DB, that's your database configuration. We'll have to actually set up a database and get it talking with ye. Prams, these are parameters that you see. There's an admin and email. And web, this is your basic parameters for your website. Like you've got your cookie validator, your cache, and you notice how just about everything's in array. If you don't know arrays, you're going to have to stop this video, go find an array tutorial I have one out on my site and learn arrays, breathe arrays, live arrays, because everything you need is pretty much an array. And once you start working with it, you'll understand how much easier it is. Now controllers, see how we already have a pre-generated controller called site controller. The controller is, you guessed it, where the request actually goes. And we'll talk about all this in depth when we get to the controller tutorial. But right now, just understand the concept of a controller is just where the request initially goes and then it controls the flow of information. For example, here's action index. This is index.php. So that's where you would be going. It's not entirely accurate. I'll explain more in the future tutorial, but just for concept, that's what it does. Mail, right out of the box, you can send emails and it can send them in HTML format and it gives you a nice beautiful little template as an example of how to send it. Models, remember a model is the representation of the data. We've got a few models in here right now, a contract form because the website has a contact page which will display in a future tutorial. And you can also make a model off of a database. So you can make a representation of the database. So you can fill in a class and then say save and it'll persist everything to the database and it handles all the SQL code for you. So you don't have to pound out all the SQL code. And then there's a user class and this is really what's called an identity interface. This is how the user logs in and logs out of the website. We're going to cover that in depth in future tutorials. Runtime, you don't need a whole lot. There'll be like debug logs and things like that in there. Test, yes, with codeception because yes, you do do unit testing, don't you? If you don't, you should. Vendors, this is where Composer really shines. This is why you need Composer because, well, as you saw, Yee was actually installed via Composer. All these other things are installed via Composer. So if you're building a website and say, you know, shoot, I need to resize an image dynamically as it's coming in on a form post, well, there's a class for that out in Composer and it's literally one command and poof, it's installed. It's pretty awesome. Views, remember, these are the templates that get rendered out to the end user. Pretty basic at this point because we're looking at the basic site. But you can see how here's our template and in there we're making a form field and we're using the data from the model. Remember the model view controller pattern. And then web. This is the actual guts of the website. Well, that was a lot of talking. That was a lot to absorb. In future tutorials, we're going to really key in on how to build things. So if you found any of this helpful or informative, be sure to visit my website, voidrumbs.com. Gosh, I got to take that picture down. My website actually moved like a year and a half ago. I just never took this picture down because I'm a big Darth Vader fan. But if you click on contact, avoid that sexy, sexy picture. That bald guy is me. If you have questions, comments, concerns, be sure I haven't even emboiled. Visit the voidrumbs Facebook group. There's about 300 of us out there in a group on Facebook called voidrumbs. And we're all about just answering questions. So if you contact me, it's going to sit in my inbox for three months until I can get to it. If you go to the voidrumbs Facebook group, you'll probably get an answer in about 10 minutes because there's literally people that sit on there and just love to answer questions. Alright, that's it. Thank you for watching. I hope you found this educational and entertaining.


More countries warn about terrorism in Russia after Moscow plot thwarted. More countries have joined the United States in warning their citizens in Russia to avoid crowds over an imminent terrorist threat shortly after Russian officials said they thwarted an attempted attack on a Moscow synagogue, according to Newsweek. A security alert issued warned that the U.S. Embassy in Moscow was monitoring reports that extremists have imminent plans to target large gatherings in Moscow to include concerts and U.S. citizens should be advised to avoid large gatherings. The British Embassy in Moscow quickly shared the warnings while advising U.K. nationals to avoid all travel to Russia. At least six other nations had joined in warning their citizens about the alleged threat including Canada, Germany, Sweden, South Korea, Latvia and the Czech Republic. While the nature of the threat was nonspecific, Russia's Federal Security Service said in a statement that it had prevented an attempt by an Islamic state terror cell to commit a terrorist act against one of the Jewish religious institutions in Moscow according to Russian state media agency TAS. Active search measures established that they were militants of an international terrorist organization preparing an attack on the congregation of a synagogue with the use of firearms, the FSB statement reads. During an operation to detain them, the terrorists put up armed resistance to Russian FSB staff and as a result were neutralized by return fire. It continues. It was unclear whether or not the purported synagogue attack plan was tied to the threat that the U.S. Embassy claimed soon after. The U.S. State Department spokesperson told Newsweek that there was no higher priority than the safety and security of U.S. citizens overseas, but declined comment on any potential connection pointing out the department's policy of avoiding the disclosure of information on intelligence matters.


Bitcoin mining and Bitcoin difficulty, so the sort of first explanation that I give to people, the explanation that I give to my mom, the highest level of abstraction, is simply to say that it is necessary for some computer, somewhere, to do a lot of math to make sure that transactions are honest, to make sure that nobody sends the same bitcoins twice. And that usually suffices, and most people understand, okay, I can see that some computers have to do math. And then I say that to incentivize, the network needs to incentivize people to do this, so it was set up so that new bitcoins arrive on the network approximately every ten minutes, and the computers which are successfully doing this math are rewarded for their efforts, are rewarded for their electricity, and that's called Bitcoin mining. You set up your computer to run and verify transactions, and you may get awarded with these new bitcoins that are arriving approximately every ten minutes. If you get a little bit deeper than that, you can see the real genius of Bitcoin, and this is just amazing to me. It's like finding out that anybody can edit Wikipedia. So what type of math are the miners doing? They are solving what are called proof-of-work problems. So a miner sits on the network and gathers transactions, and then wants to add these transactions to the official ledger, which is called the blockchain. And to do that, to add this block of transactions to the blockchain, a miner just needs to find a number that has a very special relationship with that block of transactions. The block of transactions, like anything in computers, can be expressed as a gigantic number, and it finds the number of the block plus this other number when you feed it through a hash function called SHA-256, it'll come out with a really small number. It's called a really special number. And that's it, and that's amazing. The miner is just saying, look, here's the proof that I spent a lot of time thinking about this block. Let's add it to the blockchain, and that's it. And the difficulty speaks to how small the result of the SHA-256 hash function is. In other words, the block I want to add plus my special number fed through the SHA-256 algorithm comes out with a very small number. So the difficulty, if when the difficulty is in, they increase the difficulty by saying the number needs to be this small. Back in the early days, the number only needed to be that small. And that's how the difficulty is adjusted. The difficulty number, I'm not going to go into how it's calculated, but I guess it's just important to note that it has a linear relationship. It's a linear, so a difficulty of 40 is twice as hard as a difficulty of 20. I suppose I should add one thing. A miner by itself cannot add to the blockchain. I mean, it's required for all other miners to accept this block. And if the miners see the block and agree with all those transactions, meaning that they see them as well or don't see anything that contradicts them, then all the other miners will say, okay, the block I was working on, I didn't manage to find a special number first, so we'll put this block and here's the next bunch of transactions. I'll start working on that one. That's if the miner accepts the block proposed by the winning miner, the miner that first found that special number. If the miners do not accept those transactions, if they say, hold on, these don't look like honest transactions, they're just going to keep working. So a dishonest miner, somebody who reprogrammed the miner to insert fraudulent transactions, they have to get lucky to first find a special number first, and then they have to beat the competition again to put another block on top of their block, and all the miners will revert to the longest chain. But if it's just one dishonest block, then all the miners will keep working on theirs without throwing theirs away. And I should note that economics is on the side of honesty, because if somebody has that much hashing power that they can win the race a couple of times in a row and insert double transactions, then they will be more profitable simply using their hashing power to mine bitcoins honestly and make money that way. And even, okay, so let's say someone else gets control of all this hashing power who just wants to ruin bitcoin. Like even then, it's not that big a deal. Like even if they start, I mean it is a big deal, but there's recourse. It's not like the blockchain is obliterated. People still see what the ledger was before those corrupt transactions started entering it. So they could just fork from an old block in the blockchain, say throw away these blocks and we'll revert to this old ownership, or they could patch the code or they could start excluding certain miners. There's all kinds of solutions. So it's not a showstopper. Oh, and the other thing I just wanted to give a shout out to one of the more interesting altcoins called PPCoin.  You don't need to run all those computers. Really fascinating, really innovative, worth looking into. And that's all. Have a great day.