Right. Hello everybody. I think we don't need all the rows at the back, actually. We could just do with one or two rows in the front. I proposed this session because I thought it would be useful to talk to folks or talk with folks who are interested in the longer term economics of clouds. And so I only have initial preliminary thoughts to share and I'm as interested in what you think about this because it will shape how we engage and how we invest over the next year or two. I think we're in the middle of the gold rush, right, which is a kind of crazy time. And so I thought I'd start out with a statement about gold rushes and hangovers. Nothing feels as terrible as the period right after a time that felt so good, you know. And I've been around a little while and seen this through a number of hype cycles, the dot-com bubble and various others. And I think we should be sanguine about the fact that right now we are in a time of irrational exuberance around OpenStack. And that's good because it engineers a lot of creativity, brings a lot of resources and it has negative consequences now as well in terms of sort of the fog of disruption, you know, on the show floor and in the sessions. And it may have bad consequences later as well as the tide recedes. The way I kind of think about this is, you know, if you look at things, when you're getting started with a new kind of way of doing things or a new industry, the first guy in demands a return, right? He sort of says, well, I'm not going to do this unless I understand how it's going to work. So that's not what I meant to do. So if we consider in the cloud industry, you know, Amazon would have felt like they could at least be certain that they were generating a return on capital in the beginning. And as a hit emerges, right, capital becomes really easy to attract. And I think we see that right now, you know, there's lots of signs of venture funding and institutional investments. So capital right now for OpenStack is getting easier and easier to achieve. But correspondingly, the return that people are demanding is plummeting, you know. I see a lot of people saying stuff like, well, you know, we're going to build a cloud and obviously we have to run it at a loss for a while, right? And to me that's a clear sign that we're somewhere in this drop, right? The income expectation is very, very low. People will say stuff like, oh, it's strategic and we have to be there and so on. And I think that's fine.  And very quickly the dynamic changes very, very quickly. Suddenly, capital gets very hard to find because everybody says, well, why are you doing this?  And that can change in two months, three months. And immediately then the situation starts to normalize and income expectations grow again. And in the long run, hopefully you have a nice sustainable industry for those who've survived. That's where I think we are today. I don't think it's peaked yet, but I think we're getting close. And that's when the hangover starts, right? It's when everybody starts saying sure, but we really need to have a sustainable story here. Otherwise there's no point in us being in it. Now, there are some very large players out there. The Amazons, the Googles, the Microsofts of the world who have genuinely profound strategic reasons to be growing in scale. They already operate at tremendous scale. And so, you know, for them it's relatively easy, I think, to stay in the game. But I think there's a much larger collection of organizations and we have to really understand the dynamics that will keep them, keep clouds viable for them. And two kinds of organizations I think about in this regard. One are enterprises who will be operating private clouds and the other are smaller regional or local public service providers. And I think it's really important, I think this is the forum which will decide whether or not that second category of enterprise private clouds and smaller regional and national telco type, service provider type offerings, whether they in fact in the long run have sustainable niches. So the first thing I worry about is cost competitiveness, right? Because of the ability of the very large guys to buy at scale.  It means that nobody else will ever get to scale because they can only buy from smaller providers who ramping up and it's a way of essentially locking new competition out of the market. You know, Apple did that famously with Flash for their iPods and it had a dramatic effect. Consider the CAPEX commitments that Amazon, Google, Microsoft are willing to make. I think there may well be a risk that that essentially has exactly the same effect, whether it's deliberate or otherwise, on supplies of critical components that drive the underlying costs for smaller players, right? If you can't get the next generation SSDs, the next generation. I think we're really starting to see signs of that. You know, there are new classes of SSD coming to the market in non-volatile memory, which I see a lot of signs of the big players essentially saying, well, we're only going to deliver these to the mega data center operators for a period, right? Three contracts could buy up their full supply and it immediately locks out smaller players. So it's not just cost competitiveness, it's also access to the ingredients of a successful underlying infrastructure. I think this is just as important for private clouds as it is for service providers. For the simple reason that private clouds don't have, they face competition from the public clouds, right? If you're an IT guy inside a large institution, you are watching workloads move off into the public cloud and that you're in competition with that public cloud. And I think at some level, IT guys understand that, right? That if all of those workloads were to move, that would be, you know, they would be looking for a job at a public cloud provider. And so this is as important for private clouds as it is, obviously, for service providers who are competing. In this regard, obviously, you know, we, I think, quite famously have taken a very lean approach to the pricing of the services that we provide and it's because of this, right? There's no point in building a model, you know, that depends on input costs to service providers and private clouds that will price them out of the game. And so that's just a hard cap on what, you know, the sorts of engagements we will structure. But the other half of that is revenue models, right? What are the ways in which these service providers and private clouds will generate revenue?  And then there are things that I think are further down the pike but worth understanding and exploring. And I think it'd be interesting to have an open conversation about what those things might be. The obvious thing that an infrastructure as a service provides is capacity, right? Compute capacity, storage capacity, network capacity. But commodities we know, commodities on a global market provided by large institutions with deep pockets, we know that the economics of that are very, very, very brutal, right? It's like airfares. The, you know, as soon as you have 10 airlines flying a particular route, the economics of that are extremely lean. Server capacity, the server industry itself, you know, has very lean margins. We must assume that the cloud market for essentially virtual goods of the same nature is going to be even leaner. And, you know, all of the price wars between Amazon and Google and Microsoft support this. There is something, there is one way to differentiate a commodity like that, which is location. And this, I think, is one of the strongest assets of the smaller players, proximity to a particular audience or a particular customer. And I see this at multiple levels. For example, telcos. I think NV, the Google's their ability to operate at huge scale, very flat infrastructures. But I think telcos have an asset that Google NVs, which is the fact that they have points of presence in so many places close to customers. So, you know, the grass is always greener on the other side. What Google really would like, I think, is lower latency access and higher visibility access to the full pipe, essentially, which is something that telcos have. And conversely, I don't think the telcos will ever be able to compete with a mega data center operator at scale, simply because they're not structured to do that. But they do have this location story. And location is important for data because of regulatory reasons. It's important for latency because many services, and increasingly I think the services that matter are going to be very latency sensitive. The faster you can get that movie streaming, the lower the, you know, the faster the response times on the game that somebody's playing, the better your perceived quality of service. And the combination of those two things, regulatory compliance, data protection and all of that, plus network latency, I think are very, very powerful things to think about. And meaningful ways in which to be able to charge a premium for the otherwise commodity goods, right? You may not be able to compete on price with Amazon for a VM of a certain capacity. But you don't have to, if you can say that your VM is much more valuable because it's closer to a particular thing. The earliest example of that that I can think of is advertising. If you can associate a postcode to a click, it's four times more valuable or it used to be. I think that it's now, you know, that's commoditized a little bit too, but certainly location is an extremely valuable thing if you know how to spin that story, tell that story. So if I look at the strategic questions facing smaller service providers and telcos, national, regional players entering the infrastructure market, I think they have this slightly daunting picture, right? And if you think that you're selling, they're typically selling to a company which is connected to an audience. So if you think you may be hosting the web infrastructure of a news organization or a media organization, they're your customer.  So if you kind of just look at it as global customers, local customers, global audience, regional audience, and you make that map, I think this is what it looks like when you are a national or regional player. If you have a local customer that only has a local audience, I think that's pretty easy, you know. So say you have, for example, a media organization, all of whose channels and radio services and newspaper pages and so on are in a language that's only really spoken in your country, and you're the dominant brand in your country, well then that's easy, they'll come to you and they'll believe that you can serve their audience. So straightforward. But say you're trying to reach, trying to offer services to an international organization that wants to reach your market. So it's all in your language, you are the branded player, you are the local leading hosting company or infrastructure service provider in that market. The problem is that foreign institution doesn't know that. You have a brand problem. You're the leading provider in Turkmenistan, right? Hard to know, right? Maybe someone knows, I don't, right? And so of course, people in that sort of quadrant will say, well, the best I can do is probably Amazon, they're pretty huge, they're pretty everywhere, just go there, right? And Google can tell a pretty good story about being pretty global.  At that stage, they're buying very much on price, they're buying very much on scale and it becomes very difficult. But I think those two, the brand and footprint questions, can be addressed. If you look at the very large players, they have incredible footprint around the world, but it is concentrated, right? They'll have N mega data centers. And if you look at a single regional player trying to compete with that, it's a tricky prospect. But if you were to aggregate many of those, then I think you have a potentially interesting story. You have an interesting story on scale because potentially that represents substantial scale and certainly that would put you into the category of being able to deal direct with the big suppliers, whereas being an individual operator might not, might force you to deal with a regional player or a local reseller. And from an audience point of view, that looks like a much healthier picture. If I choose you as the infrastructure for my service, I could credibly feel that, you know, if I wanted to reach somebody way out in Turkmenistan there, that you have a region in Turkmenistan. So this idea of federation, I think, is very interesting for that important category of players. Let me map out the story. Your service provider in this country starts and builds an open stack cloud and they establish a certain amount of competence in the operations of that and ability to reach the local market. So they're now hitting that first quadrant pretty well, right? Local audiences, sorry, local customers talking to local audiences. In order to reach a broader footprint though, they then start to federate with a variety of other providers. What does that look like to their customers? An announcement that they now have a region in that other market. And so if you were a customer of any of these providers, you would start to see that your cloud, your local cloud provider, now has capacity in a long list of markets, which is quite attractive, right? You're still talking the same API. You're still using the same credentials. You still have one bill. You have potentially common expectations of service across those regions. Although I have to say even the major players do have a certain amount of colorful diversity between the characteristics of their different regional data centers.  And in aggregate, that federated cloud could come to look like something that the global players might choose to engage with rather than one of the mega-data center operators. So that's the theory. Any comments or questions so far? Anybody actively working on these kinds of cross-cloud relationships or thinking about the dynamics of those? So that's keystone-level work. That's at a technical level, essentially.  I'm going to get to identity pretty much now. So that's perfect. Do you want to tell everyone a little bit about what that work entails and what you're doing? Can you pass the mic back? Sure. So it's actually a whole bunch of players. Red Hat, IBM, Rackspace and CERN all working together to introduce federated identity across multiple different clouds. There's a demo later today. There's a talk at about 11 as well about how we do it. But it's using standard protocols. So it could go beyond OpenStack, if you would, using SAML approach. Yeah, that's completely up to the trust in between the identity provider and then the remote cloud being the service provider. There are certain attributes that are actually passed along according to that trust, such as username. But there's no credentials actually being sent over. The service provider doesn't have the user's password, for example. Thank you. I was telling, this is more of a legal issue. Because if you are demanding the middle, you are responsible for the transaction between the user and the provider. So it transcends the technical stuff. What about data confidentiality and protecting the least infrastructure provider from being able to access the data of the user whose workload is being shifted around, for instance? Again, it's a legal issue. It's not a technical issue. That's the main problem. Because this federation think it's wonderful. I'm working actively on this for several customers. But the problems transcend the technology. And that's what we need to think about. Yeah, I think this is not a technical talk. That's why we're having this talk. So my sense is that from a customer perspective, it's very, very clear.  But you're not going to want to have to think about now suddenly, essentially, becoming a customer of another company with all the know your client issues that that entails. The reason I think it's important to talk about this now is because if we just let it happen, we'll get a mess. We'll have different opinions. We'll have different approaches. This is an opportunity for industry to essentially have an opinionated stance and say, no, no, no. We want to federate and to recognize that it's not going to work very well if, essentially, every player demands to know everything about every customer. So the contracts between these players essentially need to be opinionated and with a view to success. So there are regulations. The cloud provider, the remote cloud provider will probably be under pressure to be able to account for everything that's running on their cloud. But as long as their contract back to the other party essentially addresses that, you know, in the event of a law enforcement process, how does that get escalated to the other side and is it appropriately backed? Is the sort of language that we need to be thinking about? If we just stumble into this, it won't work. We need industry to have, I think, a fairly opinionated view on what will work and then go out and build it and deal with any issues that arise. So I think identity is the first issue. I'm not sure if I had... Let's put data privacy, data security into that. I think if you're a remote operator, one of the reasons, sorry, if you're a remote foreign customer, essentially, one of the reasons to want to put infrastructure and data into a place other than latency is compliance with local laws. If that country has said, any data that you hold about our citizens must be held in country, as some countries are starting to do, that means that you have to find a way to put your apps and your databases and so on and so forth in that country. So I think there's mutual incentive here. The customer, the ultimate customer, wants to be in your country, but they want that to be a smooth and seamless process. They don't suddenly want to become a customer of different cloud providers. They don't want an engineer placing a workload in a country to trigger a whole bunch of contract processes, is what it really boils down to. We need to decouple the engineering deployment type discussion from the contract type discussion. What about security? What concerns would people have from a security perspective? For instance, what might concern me or what I can think of might concern customers is that a portion of my data will probably have to leave the premises of the provider that I trust and enter the infrastructure of a provider that I'm not sure I trust or I don't know how much I can trust him. And it's going to be visible not to the other customers in that infrastructure but to the infrastructure provider himself. So it's a difficult thing. So for instance, if I'm doing any credit card processing, those credit cards are going to go into an infrastructure which I don't know if I can trust. So in that case, there will have to be some strict assurances of a feature set that some parts of my data I'm allowing to go and some other feature sets that I don't want my data to go into, for instance. I think it comes down to how to generate this trust. You have to somehow generate this trust. You might get some kind of PCI compliance for credit card processing or you might have some ESO certification, ESO 9001. So these are things to prove and to prove your credibility and you have some kind of quality control in this federated crowd and this is something that we have to work out then. So you have some kind of basic trust to ensure some kind of basic trust. I think it's also kind of what the role the person has so some people are buying and some people are usually selling on the cloud and so if you're a seller, then you have a lot of concerns also versus just being somebody on there buying. If you think of other places where these problems must have been solved, where are you from? Where are you from? From China, in Munich, in Germany. Brilliant. And you, sir? No, not you, sir. You, sir. You're Latvian. Now what would be fantastic is to think like if you exchanged phone numbers and called one another, what would be happening? What's that? Someone would be making money. But think about it. Your cell phone comes from, I assume an operator in Munich, a German company whose course comes from an operator in Latvia, in Skype. I don't be difficult. Between the telco industry, we already have mechanisms for signalling. We already have mechanisms for handover. We already have mechanisms for billing. That call gets routed. It gets placed. Go even further. There's two cell phone base stations. Those might not even be, and all of that's through the local operators as well. There's two base stations. Those may not even be owned by the operators that are showing up on your phone. And yet everybody's getting paid. Law enforcement happens. It's just fine. So we've solved this sort of problem in the telco industry before, out of necessity. And I don't think there's that much difference between placing a call and placing a thread these days. And if we start to think of it in that way, maybe we can build quite a nice fabric for this kind of distributed computing, which is the sort of era that we're going into. Okay, what else? Brand. What are the various... Which was the project called? Congress. Anybody go to that session? If we go a couple of years back to the grid computing that was initiated, I stopped following it for a couple of years, but the original idea of the grid computing was to commoditize compute and storage resources and to be able to share them between multiple infrastructure providers and tenants. So I know that obviously OpenStack and cloud, commercial cloud and open source cloud solutions have taken over most of that public interest from the original grid project. But that's something the original grid project was trying to solve, and mostly succeeded, at least as far as I know, in some aspects of it. So it's a topic that already came up before, but for some reason I don't know if it's just the technology that didn't take off, or if there are other issues that the grid project wasn't able to solve. So maybe we can refer to that and see where we can improve a part. So from a brand point of view, I think the key brands involved in this case are the local brands. I think your buyers are going to be dealing with their closest entry point to such a federated cloud, and they will effectively assume that that's what they want. But there's also going to be a brand associated, I think, with the overall story, and for me this is a little bit like Visa. You get your Visa card from a local institution, but you expect it to work anywhere in the world. So I think there's an interesting analogy there. And perhaps we can look to those sorts of institutions for model templates on how to structure, and they also have trust and data protection type issues, so perhaps we can look to those sorts of institutions for how to structure those relationships. Service definition, how consistent do you think service definitions need to be across those players? And by service definitions I think we mean instance types, performance levels, SLAs, what else might be in that, and how important do you think it is that they be consistent across the various participants? Let me ask you to resale that. We need to unify the service definition first because each service provider will have their own service definition. There is no standard, and in fact this is a great opportunity to create a standard for service definition. And what would you include in that service definition? What are the attributes that you think are important? Is it straight instance types? Is there more to it than that? No, it's more trick than that, and it's the correlation between all the attributes from the different services because for example, just for simple infrastructure as a service you can have 120 different attributes to describe that service, and the permutation between all those attributes it's a huge mess. And if you put on top of that the pause and the size and the security and the networking and so on and so forth, it's a complete mess. So we need to standardize the service definition Who's in... Is anybody here actually representative of one of these... or feels that they would like to be one of the smaller dots on that picture that I had up there? Yeah? How do you feel about having your services standardized by somebody else? Yeah, it's difficult, so we have to comply with the definition from somebody else, and our infrastructure might not fit to this service definition. The tricky thing about that ease of capital access is that everybody who's going out and grabbing that capital is doing it because they say they're going to differentiate. Right? I mean, I see this pattern dramatically, right? Well, we should go raise $20 million to build a cloud and we're going to beat Amazon because we'll be different, but if everyone's different in different ways... You cannot generate trust with the different service levels. Yeah, it's tricky. You can't generate capital if you can't differentiate. It's interesting. Well, you don't necessarily have to differentiate on the service description level. Like, on a basic level, compute resources, even if we have a similar definition of CPU counts per VM type, those might be different CPUs there. So if we agree upon a unit of computing, a unit of memory, a unit of storage, it still leaves enough room to differentiate in different ways to potential investors, like efficiency or data locality or latency. Even if the unit of measurement is the same everywhere, there still should be enough ways to differentiate. What about the search? So actually, if you federate a lot of clouds, the end user from Portugal, for instance, might want to know what kind of services are in the federated cloud. How does it search for a service if there is no standardised in the service attributes? You cannot do that. There's always a way to translate. I think you said it best when you said that you can. It's ultimately just computing storage and connectivity, not even networking. So I think that there should be a way to translate. And the more you standardise, the more time you reach bad compromises and it will drive consolidation in the industry in the same way that it did with the tacos around 3G. So I would be very wary of pushing towards standardisation. I think there is also another problem. Most customers are not even aware of the parameters they need to know. And it's making it difficult to have some standardisation on this because the providers who are really bad on some specific parameters don't want to see them standardised. For example, latency in some VM environment is very bad and very few people talk about this just because they don't know how to solve this, for example. Well said. We can't get stuck on this one. Billing, I'm not going to get stuck on that one either other than to say that no one will be interested unless that's a solved problem. And I think we've got about three minutes left. Solution portfolios. Talked about the other services and the searchability of services. What sorts of solution portfolios do you think will be most compelling for these cloud operators? And is that something that's attractive and useful? Do regional operators feel like they would prefer to be leading and differentiating on solution portfolios or that it's better potentially to have standard portfolios that are accessible everywhere? Do you want to just shout? I don't know. We have time to get a microphone to you and I'm not sure where the microphone is. There it is actually. So yes, it kind of goes back to discoverability of what capabilities in each individual service provider actually has. And I think they'll probably want to differentiate on the portfolios that they offer, saying that they're best for big data workflows or workloads as opposed to web tier workloads. I think that would be very valuable to the customer. Other thoughts? Somehow, IS has been commoditized. So next generation opinion is more really driven by the past platforms. So it just sort of provides their own past platform to attract the local developers to create their own marketplace. Smells like teen spirit. Right. I think that's just about everything we have time for. Any other topics that you folks want to touch on? At the back, do you want to shout? I have a mic. So what happens if the relationship between a big player and a small player becomes broken? So if they went out of contract, what will happen with customers in that case? That's also something that we need to consider. Unminding. Yeah, that's interesting. Any other topics? Very good. Well, let me thank you very much for all of your contributions and ideas. I think this is a very thought-provoking area and certainly an area where we see a good deal of interest between the folks who are raising money and want to have a long-term sustainable view on how that will work. Thank you. Have a great conference.


Hello everyone, my name is Mr. Sandesh Bharay, I am currently working as an assistant professor in the department of computer science and engineering at Palchen Institute of Technology Solopour. In this session, I am going to cover the topic which is nothing but the mobile application testing. So, the learning outcome is at the end of this session, you will be able to identify the app features which need to be tested. First have a look on the contents which are going to focus in this video. First is need of mobile application testing that is why it is needed. Second is the mobile application testing strategy means the number of types of the application testing and next is the challenges which are faced in the mobile application testing. So, let us start with the first that is the need of mobile application testing. Obviously, the first one is the profit because untested mobile application can fail in the market because some of the inputs, some of the activities regarding the application, if you do not tested it, you do not verified it, then it may get closed or the destroyed. So, it leaves the bad impact about the product and developers also in the market so that developer can create one more problem regarding it, so it should not be happened that is the first reason. And mobile platforms, these are going rapidly in the market one rapidly and third one is the vulnerability to the application failure, it will create chaos in the market that particular product is helpful for the device or the user in the certain matters. And obviously, effect of failure on the good will of the developers reputation. Now, we are exploring the testing strategy that is in that diagram you can see the number of testing strategies are given there in this you can see the functionalities tested, GUI tested, performance, network, interrupt and compatibility, interface, security memory, testing localization and in-app purchase app testing is also performed. So, these mobile application goes through these number of tested, test during its testing procedure and if it passes all these criteria, then it is considered to be a perfect mobile application which should be delivered in the market one. So, we will explore these strategies that the first one is regarding the functionality testing, it means what in this we are going to check whether app is working as per requirement or not, it should be functionally correct or not and second is the GUI testing that is user interface whatever the design on the front end made by the developer, it should be in correct manner and it should be easy so that user can deal with it so easily. It should not be confusing, it should not be complicated so that to perform a certain activity user want if user is dealing with the so much difficulty then obviously, he will prefer some another application and it will create one bad remark on this application so it should not be happen, this is the second criteria which is the GUI testing. Next one is the performance testing, there is slight difference between the functionality testing and the performance testing, functionality is regarding the work it should not be work beyond the requirement, it should be correctly work as per the requirement but in the performance what we are going to check whatever the other software plus the hardware of the device, it should not be hampering to this hardware, means what it should not be consume much more processing power, it should not be consume much more memory, it should not be consume much more battery, so it should not be heavily loaded on the mobile device one. So it should be one adequate one, next strategy is the network testing. As per general talks I discussed with you earlier that it should not be consume much more device hardware for example, memory, processing power and the battery such one more phase is that it should not be consume much more data using the networks, it should not create the connectivity issues, it should be compatible with the all verges of the connections. So this is the testing performed in the network testing and it verifies the message when network is not available on the device on the aeroplane mode also. So the next testing is the interrupt testing. So any application while functioning may face several interrupts like SMS is there, incoming calls are there, so it should be handle these interrupts correctly according to the preferences which is set to the different activities, it should be behave in the correct manner that which notification or the which activity should be given priority and control should be transferred to that particular activity, it should happen in the correct way that in generally called that it should be handle the interrupts in correct way, this is checked in the interrupt testing. So one question is there for you guys, what is exactly the mobile application testing? So it is nothing but one process which is developed application of a mobile device is tested regarding its functionality, consistency and usability. So we are discussing the different strategies, let us get continue to this testings and next testing is nothing but the compatibility testing. So now we are seeing that number of platforms, number of devices and different types of devices are available in the market nowadays and it is growing very rapidly and then different types of network is also emerging and they are provided to the user one. So whatever the application you are developing, it should be compatible with all types of the devices, with its mobile operating systems or the devices, it may have different screen size resolution or whatever. So it should be compatible with all types of the devices, it is checked in the compatibility testing. And next one is the interface testing. In this it is checked whether the particular app is handling the particular errors correctly, it is dealing with the remote enterprise system correctly or not. Whatever the data set provided by the user or the demanded by the user, these are accessed properly or not. So these are some testings which are performed in the interface testing. So the next one is the memory testing and in this what happens that it is checked in the conditions like whenever the memory is very limited and when memory leakage problems is there, at that time also the application should correctly work. So this checking is performed in the memory testing and next testing is nothing but the localization testing. What happens that now are using GPS system, we are using the mobile device that is provided by its position on the globally, it is very important information regarding the providing the services to the user. So user may demand some personalized data while roaming in the world. We have to provide the certain personalized data to him so that it gets better result. So the app should take care of the physical position of the device one so that the personalized results should be provided to the user. So it is checked under the localization testing. Next one is the regression testing. In this what happens that it ensures that it fixes some existing functionality and expected that normally performed by the application as per requirement. And next one is the in-app purchase testing. In this verification of the applications working proper is not regarding the purchasing of any item into the application. Means after debiting the particular amount to the developer then only it should be available to the user one and it is checked that particular versions of the applications are released by the developer after time to time and they are made available to the user and according to the payment done by the user it should be available to the user. So it is happening correctly or not is tested in the in-app purchase testing. And last one is the security testing in which the data which is transfer or the stored these is checked whether the identity of the user is kept private or not it is also test. So regarding all the data privacy, security all issues are handled correctly or not is checked in the security testing. So mainly four challenges are there. Using this testing that is the variety of the mobile platform that is number of available in the market and diversity of the operating systems. And network service providers there are number of the network service providers are there. So it should be correctly work with all of them. And fourth one is the increasing requirement of the futures in the application. So these mainly four challenges regarding the mobile application testing. So these are the some references I use to make this video. Thank you.


My name is not Bob, as you might have seen already. So a couple of the printouts, I think we switched the talkers and something went wrong. So my name is Etienne. If you were expecting Bob, I'm sorry. Yeah, welcome to the first talk of the day. Plenty of firsts today. So my first time at Foslem, therefore also my first time speaking at Foslem. But more importantly, the first time we're introducing VV8 to the public. And it's a very cool chance for us to speak in front of an audience that is either interested in graphs or is experts on graphs. So that's really, really cool. And we're looking forward to your feedback. VV8 is the decentralized knowledge graph. And we have the vision that any AI related task can be reduced to semantic question answering. And that's what drives us in building VV8. You can also see the word Semi on these slides here. So Semi is a company that sponsors VV8. It is an open source product in the Creative Software Foundation. And Semi is a company that offers enterprise solutions on top of it and supports the open source project. Cool. So for the next 30-ish minutes, I'll give you a bit of an introduction of what VV8 is. What the contextionary is that powers VV8. I'll get to that in a second. What you can do with VV8, how we build it and a quick life demo. So what do you get from it? I would love to spark that desire in you to just try it out. So we have a Docker compose file. You can just do Docker compose up and play around with it. And as I said, I would really love if we could have this targeted audience to get some feedback on both our API decisions on our implementation decisions, et cetera. Cool. So you see a GitHub link here. So if you wanna check it out right now, before I've even told you what it is, feel free and it's Creative Software Foundation slash VV8. On the title slide, we had the official name VV8, the decentralized knowledge graph. Here I've added another word, which is the word contextual. And I'll explain what we mean by contextual decentralized knowledge graph. So to understand the part contextual, I wanna introduce the contextionary. That is an AI based natural language tool that helps add context words. And I think it's best explained if we have an example. So think of the word King. If you have any kind of association, so these are the associations I had while building these slides. King could be a ruler, a monarch, also man and male is somewhat related to the word King. And all kinds of other associations. So we have fancy, royal, could be an oppressor, could be well-spoken, and depending on how hungry you are this morning, could also be hamburgers. But if we take a look at this word King sort of in a vector space and seeing as King of the sum of all of these words that make up the context, then we can perform basic mathematical operations on it. And one that I've done here is taking this man and male and subtracting that and adding the word woman or female. And then we immediately as humans, so I assume you're all humans, we've already established that we have one robot in the audience, I hope the rest of you are human, because then it's very intuitive to us that the word King becomes the word queen if all the rest of the context is the same. And this is something that's traditionally been very hard for computers and the contectionary uses that context to make these kinds of things very easy. So you could of course, when you carry something, you could of course just match for the string if you already know that you're interested in both genders of King or Queen, you could just say King or Queen. But these kind of queries won't scale so well. So if you say you have a relation between one entity, say a King lives in a castle and therefore castle, you have maybe the word Ford, you have these kind of different ors that you have to do and it won't scale so well. Whereas if you have the context, we just match one context to one other context and that makes that much easier and will be extremely helpful if you don't know the anthology or if you're operating on foreign data or if the data quality just isn't as good as you'd hope for. So other examples for how we can use the contectionary. So think of the word location, place, city. For an example, let's say we have three lists of restaurants like the top restaurants in your region or in your country. And these are made by different people and everyone has a different way of saying where the restaurant is located. So the first one says location, the second one says place, so the third one says city. Again, for us humans, it's very easy to see that this is really the same property that they're talking about. But if we're just matching strings, this becomes very, very hard. So by using context, we can very easily identify that this is the same property that we're talking about. Then there's also the opposite. So I have two homonyms here, seal and seal. So we can use the context for disambiguation. So think of seal could be an animal. So we have the mammal or we have the animal, the seal. And you also have the seal as in to seal an envelope. So depending on these different contexts, if you have mammal, ocean, et cetera, you can build the centroid of these words in the vector space. And this is what defines the context. And this is how you can disambiguate between seal the animal and seal the envelope where you would have, sorry, seal the seal as on an envelope where you would have stamp in the context envelope, maybe security protection, these kind of things. Cool, the next word that we had in the definition is decentralized. So in order for something to be decentralized, you need to have many different things that you can then either combine to something centralized or spread out to something decentralized. You can operate VV8 completely standalone, but you can also establish a peer-to-peer network of different VV8s. So why would you wanna do that? One reason is because it gives you the ability to completely own your own data.  If it's private data, if it's customer data, have to think of GDPR protections, et cetera. But you can also still, because it's a network, you could enrich it with other data. So think of Wikipedia, for example, like a lot of human knowledge is very easily accessible, again, to humans on a Wikipedia. But firm machines is not necessarily that easily accessible. Yes, you can parse the text, et cetera, but establishing relationships is a bit more difficult. So you can of course say, okay, if I'm talking about a car in my database, I can add a link to the Wikipedia article of car. But it would, of course, be much nicer if you had that Wikipedia knowledge in some sort of structured graph form and you can get to keep all these kind of relationships. So this is something that's possible with VV8. You just connect your own VV8, your private VV8, where you have your private data, with a public VV8 that has, for example, Wikipedia data. You can also connect several VV8s to combine their different advantages. So I'll get into modularity a bit later on how we use modularity in VV8. But you could, for example, say, okay, I have one VV8 that's built to be very fast. So maybe it has an in-memory database where, yeah, we don't store anything on disk, everything in memory, so it's super fast. But we have another VV8 where we have a data set that's so large that we can't do that. And then by having it decentralized, we could combine those two VV8s to have the best of both worlds, ideally. The next term, and this is one that I already received a question about this morning. So what does knowledge graph mean? And in fact, that's not entirely easy to answer because I don't think there's one agreed upon definition. One very common way to refer to the knowledge graph is the way that Google uses it. So Google calls their knowledge graph the knowledge graph, and this is what Google uses to answer structured questions. So if you ask Google who is the president of, let's not go to that, let's say, who is the chancellor of Germany? That one's a bit safer, I think. Then Google will say, okay, the chancellor of Germany is Angela Merkel, maybe at her age, her education, how she got there, her party affiliation, et cetera. And this info, this related info is of course very easy to retrieve because there's a graph behind it. For us, with VV8, we also focus on the second part very much. So we are in the graph track here. And for us, that means we're building an existing graph technology. So we're building on top of existing graph databases. We're using GraphQL for our API because we think that makes it much easier to use graphs, especially for people who don't have any familiarity with graphs. And additionally, we keep adding like more and more semantic tools to VV8 over time, turning a sort of regular graph into a knowledge graph. So it's very easy with existing graph technologies to query for this kind of related information, but it's not so easy yet to understand these kind of questions. So if you just put a natural language question in, there's two parts basically, the natural language part. And then once we have that in a structured form, there's the graph querying part. And the combination of that is basically VV8. So what can you use VV8 for? So as I said already, you can combine data across industries, but because you have the context sharing, you don't necessarily have to harmonize your ontologies. You don't have to make sure that location is renamed to place. So it's consistent because you have the context. This gives you different abilities in all kinds of business cases. So I think for example, you are a bank and you have bank transactions and you see that people are buying Netflix subscriptions. And based on the price, you can tell that this Netflix subscription includes the 4K feature. So let's say if the bank wants to work together with a retailer, they could now think, okay, is there any kind of correlation between buying the 4K Netflix subscription and actually buying a TV that is capable of displaying 4K content? So that's sort of synergies that can be created there. Another example would be mobile providers have movement data related to postal codes. So let's say there's a specific street and you wanna know how many people from a specific postal area or from a specific area in your city go to that street. And of course, you don't have the individuals there because that would be horrible for privacy concerns, but just groups sort of overall, this many people from this area go there. So this kind of data is very useful for any kind of business that would be in that street. They could say, okay, maybe we have to drop some pamphlets at some other place because we don't get enough customers from this kind of area, even though it's not that far away. Or you could use this for restaurants for example. So let's say you're a restaurant chain and you're thinking about where should I open my new restaurant? So if you have postal codes of people that visit that area, you also have demographic data. So you can say, okay, does my restaurant fit into that kind of demographic? Also a transport sector. So let's say you have two postal codes that are equally as far away from your street that you're looking at, but people are only showing up from one postal code, not from the other one. Maybe there's something wrong with the transportation. So all kinds of insights where it makes sense to combine data from different industries in a decentralized way. You can of course also very easily gain more insights into the data you already have. So you don't have to use VVAD as part of a network. You can also just use it standalone and just have an easy interface onto the data because you don't have to know the ontology so well. You can enrich your data. So this example I had before with Wikipedia for example, you can use that to say find more customers. If you have data about your own customers, identifying who are your most profitable customers, like what are the aspects that make these customers your best customers. You don't wanna share that data of course. You wanna keep that. But additionally it would be very nice if you just had like a database of potential if you're in the B2B sector, like just a list of companies in a structured form that would match your criteria. So you can apply your own criteria of what makes this customer a good customer on that list. Another example would be fraud detection. So typical machine learning example is spam detection. So one of those sort of, if you look into machine learning, one of the first examples, you have a list of bad words and if these words appear in your email, your email is probably spam. With a graph with sort of structured knowledge in a graph, you can take this much, much further. You can say not just matching it for words but maybe have behavior in there and this you can use for fraud detection or any kind of other behavioral analysis. Cool, so let me just drink something and then dive into our first example query. So I said that we're using a graph QL and the reason we do that is because we wanna bring a graph technology to people who don't necessarily even know what a graph is but who we believe could benefit from that. In order to understand that query, let me define a couple of things. So the root query that you see here is a network and we distinguish between local and network. So if you have that standalone mode and you're just interested in the data that you have locally, it would be a local query, whereas a network query would be anything where you tap into your network. We then have things. So things are anything that are things in real life. So it could be cars, could be airplanes, could be persons and actions would be any kind of interaction. So in the context of an airline, the action would be a flight, for example. And then the next word we have here is fetch. So fetch indicates that we're doing something fuzzy. So we have the word get where you do something very explicit. You know what network peer you wanna get the data from. You know exactly their ontology, what you wanna get. And fetch is the opposite. So fetch is if you don't know if you have this kind of fuzzy search that you wanna do. So let me give you a bit of a scenario around this. Let's say we have airports all over your country, all over your region, you have different airports. And these airports have any kind of local airport management system. So you don't really know the exact data. This could be a different system anywhere. But you know that each of these airports has data of what planes are currently on the ground. So let's say we're an aircraft service company, a fictional aircraft service company, like a very mobile one that can just immediately drive to an airport if there's an airplane that needs servicing, don't think it's that flexible in real life that doesn't matter for our example. So now we wanna say, okay, I'm good at servicing airplanes of the type 777, where can I find them? And this is where this query comes in. So we're saying on this where clause here, give me anything where the class is plain with a certainty of 80%. So certainty is one of the constructs that we introduced here to sort of narrow down this fuzziness. And by that we mean anything that is related to plane, but we don't mean where the string is close. So the word planet, for example, with a T at the end would be very close if you compare the strings, but of course not in the context. So in the context which we wanna match for is airplane, aircraft, these kind of things. Then the second one, the second property that we're interested in is the model in this case should equal 777. And again here we don't know if this local airport management system says the model is, or the property is called model or maybe model name or just name, et cetera. So again we try to match this with a fuzzy search here. Then of course the word plane is also another one of those very ambiguous words. So plane could be an airplane, plane could be a sort of two dimensional level or surface in a three dimensional room. Plane could be in woodworking, you have the thickness planer to plane. So we have the ability to add keywords here to make it clear to the machine of what context we're talking about. So in this case we're adding the word airline and airport. And then if you hear these words and the next word you hear is plane, you immediately think of airplane and not of any kind of the other planes. And this context here in this case we're entering it manually in the GraphQL query. But if you think one step further, let's say maybe this question that you got to send to VV8, it didn't come from a GraphQL query but maybe you asked your Alexa on it. Then context could just be like what questions did you ask before? So if you were talking about airports and airlines for the past minute, the next question that you ask about planes is most likely gonna be an airplane and not any other kind of plane. Cool, so now we're transitioning a bit more into the technical part. The first one is here, how is VV8 different from existing graph technology? So VV8 is not a graph database and VV8 does not try to replace existing graph technology in any way. VV8 tries to enhance it, to build on top of it. So if you're sort of faced with the question, should I use VV8 or should I just use any of the existing graph databases? How would they be different? The first one of the USPs would be ease of use. So keep in mind here that we're targeting a demographic or targeting an audience that isn't so familiar with graphs. So I assume people in this room here probably know how to run a gremlin query, a Cypher query, a SQL query, these kind of things. But even if you don't, even if you do, you might say that, okay, these do definitely have a steep learning curve. And we're using GraphQL to make that easier. So with GraphQL, you have the ability to discover your API. So if you don't know the API and if you don't know the ontology, you have to use GraphQL or you can use GraphQL which gives you this sort of auto suggestion of what there is to use. And we think that we can reach a larger audience than with the existing query languages at a cost of courses with any abstraction. Then we have natural language processing and the contextionary. So contextionary, I explained already, natural language processing. This is sort of what we're looking into right now. Like ideally GraphQL would just be sort of the middle layer, but in the end, you can just ask a question, ask it to Alexa or just type it in a way and VV8 will give you an answer. Then the third part is also the modularity of the data store. So VV8 does not depend on any one specific graph database. So we try to make this very modular. The first connector that we've built so far is on Janus Graph, but there's nothing sort of Janus Graph specific. You could also put in a write a connector for Neo4j, Redis Graph would have you. One of the reasons for this could be the cap theorem, for example. So let's say you need high availability, then you have to make that trade-off doing one strong consistency or doing one partition tolerance. And in this way, so we've picked Janus Graph, which we interned back by Cassandra, which is known for its eventual consistency. So we said, okay, we need high availability, we need scaling, but we don't need the strong consistency for the first use cases. So a bit more on the architecture. The user-facing APIs that we have, I've already talked about GraphQL and we think it makes it very easy for users to discover the API. But we also, of course, have a REST API. So for importing, for example, if you have a flat list of your data and references or basically just IDs, then a REST API comes in very handy. So that's the other API that we have. VV8 is built as a microservice. So by that we mean that VV8 has a relatively small concern. We're currently looking into, as I said, these natural languages tools where you can just ask the question. And there we've discovered this is a completely different language stack. So VV8 is written in Go and most of the libraries there are written in Java. So that will probably be its own microservice. So we're benefiting from all the technologies that are out there. We're adhering to 12-factor principles we're using Docker in our everyday development. We're building or we're betting on Kubernetes. Like we're making sure that everything runs on the cloud. That is also one of the reasons why we chose Golang. So we're using Golang 1.11 here. So yay, Go modules for anyone who's using Golang. Because we think Golang has just proven to be a very good language in the cloud environment. It's sort of a good trade-off between stability, ease of use performance. Yes, there might be languages that are a bit easier to use. Yes, there might be languages that perform a bit better. But overall, we think Golang is a very, very good trade-off. Then we're putting a lot of emphasis on the design of our APIs. So we always design them first. In the case of GraphQL, we just have a small prototype which is like completely decoupled from VV8 which we really just use for prototyping and trying to get the API as good as possible. For the REST API, we're using Go Swagger. So that has come in very handy to just write the Swagger document first, then build the API to match it. And we're focusing very, very much on modularity, on plugability, for this I have two more examples. So the first one is, don't worry, by the way, if you can't read this code example here, it's not meant to be read. So for the database connector, I've mentioned this before already, we wanna be able to exchange databases. And one of the reasons I've mentioned already, so the CAP theorem, you might need a consistent database or you might require a database that is safe against partition tolerance. But there's other reasons, of course. So scaling is probably the most motivation for us to start with a Janus Graph. Could also be speed, could be any kind of specific features. So we really, we don't know yet every use case, and this is really something where we're saying, okay, we need to be a bit generic here and we need to be a bit modular. So for a database connector, really that's just an interface in our code and anything that implements that interface is a database connector, which gives us the ability to keep the remainder of the application completely database agnostic. I've already mentioned that the first connector we have is Janus Graph. So Janus Graph interned back by Cassandra for the data store using elastic search for the indexing and we're currently looking into potentially also adding Spark for analysis queries. So the reason for this code snippet over here is we have one empty connector that you can get started with. It's called the foobar connector, very creative naming here. And this code snippet is just to say, so this is the Godoc comment on one particular method that you can implement if you wanna build a connector and what we're trying to indicate with this kind of code example here is that we try to keep it very, very well documented. So here you have an example, GraphQL query that you would have to resolve for this kind of connector, an example return value, et cetera. The second part where we wanna be very modular is our authentication and authorization scheme. So in case anyone is familiar with how authentication works on Kubernetes, it's very much modeled after that. If you're not familiar, don't worry. Authentication is very, very modular there and we also try to keep that modularity. So we can say anything for authentication can be a plugin. So for example, you can just use basic auth for developing in production. You could use open ID connect for example, which in turn sort of gives you the ability to include many different authentication schemes, but also be saying, okay, there might be some obscure enterprise authentication scheme that we've never even heard of. So again, we try to be very flexible. And also here, anything really can be an authentication plugin in VV8 that resolves to is the user authenticated yes or no and also extracts the username or groups so we can then use that for the authorization. In the authorization again, very, very much modeled after Kubernetes. We wanna have a role-based access system. So in this example here, this particular user or group would have permissions to read on write on things asterisk. So on anything in the things API, but therefore in this example, they wouldn't have any kind of permission to read anything or do anything on the actions API for example. If you're interested in that, there's a GitHub link with the full proposal. Cool, so I mentioned Semi on the very first slide and I think in the context of open source, it's also always very important to say who's behind it. We all know that software development is very expensive and who are the people behind it and what do they get out of it? So in the case of VV8, Semi is the company and it's called Semi not Semi. The Semi offers enterprise support and consulting. So for enterprise companies, it's very important to get something like VV8 up and running very, very quickly and to get all kinds of help with the enterprise specific things. Advanced network abilities is also there. So I've mentioned these examples before, like wouldn't it be great if you have a VV8 that has been filled with Wikipedia knowledge for example or a VV8 that has a directory of small and medium businesses. And these examples were not too far fetched. So this is something that VV8 can provide. Another thing is a custom contextionary. So so far I've always talked about the contextionary and in the open source version we have a general purpose contextionary that is again trained based on knowledge or based on content from Wikipedia. But you might have the need for an industry specific contextionary for example and this is something that Semi can then also provide. There's also a playground user interface. It is just a user interface to visualize your graph and visualize your data which is really cool. Unfortunately it's not open source at the moment so that's why it's not the content of here. So next up I would like to give you a very, very quick demo which will be interesting with the handheld microphone here. But before we go to the quick demo part let me just quickly give you the roadmap so that you know what I can demo what is vision and what is already there. So we do have our REST API completed so for importing these kind of things. On the GraphQL API we currently have everything that is related to local queries. On network queries we have the get queries and get meta queries so you can query information that is very specific to one network node. We do have the contextionary completed. What we don't have though is a queries that make a lot of use of it so far. We have a GenesGraph connector so that was the first connector that we decided to build and that is completed. We are currently building the network, these fuzzy requests so this example this is actually something that I started picking up yesterday so this is very much in development right now. Also the authentication and authorization proposal is sort of an accepted proposal but nothing has been implemented yet. And we're currently researching very much this natural language thing so to get closer to our vision to answer any AI related task with a natural language question. Our team member Laura is currently looking into NLP technologies to put this on top of GraphQL basically. Cool so let me demo something for this. I quickly have to switch yeah. Thank you very much. Okay first I have to tell the screen that it should not, it should mirror. Cool. And now we just have to find how cool that worked. Awesome so here we have a GraphQL query. Let's start with the first one. So this is a local get query. We're creating for things in this case. Okay I think I'm missing an example but that doesn't matter. In this case we're saying we want cities and off the city we want the name, we want the population. Then we have a cross reference on the context of graphs. This is an edge onto a property called country and again from this country you wanna get the name and the population. Additionally we have a filter here so this filter says we wanna get any city where the path in country on the property country with the property name does not equal to Germany. So in our huge data set of four cities I think that we have here for demo purposes. We're now only getting the two cities that are in the Netherlands. So we have Rotterdam here with a population of 1.8 million. Amsterdam with also 1.8 million. In the Netherlands with 17 million. So if I then remove this, this where filter, run this query again, then also need to remove this. Then we have all the cities that we have in our database which also adds Berlin in Germany and Düsseldorf. So again the cool thing here because it's GraphQL, you really don't have to know the ontology. You can just rely on GraphQL to basically also autocomplete that. So rely on the typing system. This is something that we think makes GraphQL a very cool tool to put on top of graphs. Then here we also have an aggregate query. So in this query, we're saying, okay, we're aggregating things again and we wanna group our things. So whenever we do an aggregation, we have to group it by something. In this case, we're grouping on a primitive property that we call isCapital. So that's a Boolean property, meaning we get two results. One where this is false, one is true. And then we have just a very simple aggregation here on any non capitals. The largest in our data set is 1.8 million. The smallest would be 600,000. So that's Rotterdam and Düsseldorf. And then for capitals, we have Amsterdam and Berlin. So a 3.5 million and for the minimum 1.8 million. So that's the quick GraphQL demo part. So now I need to get back to my slides, which were here, cool. Thank you very much for holding the microphone. I'm not seeing my speaker view anymore. So please do tell me when we're out of time. I would very, very much be interested now in a bit of feedback from this room here. First of all, for, of course, now, but also later. A bit of contact information. You can contact Semi at Semi.network. That's the homepage. If you have any kind of sales related questions for enterprise services, et cetera, please reach out to either David or Misha. You can, of course, also contact me. Why would you want that? I'm currently one of the core developers of VV8. So if you have any kind of development related things, there's my contact info. There's my homepage, GitHub and Twitter that you can follow. Also my YouTube channel, where I have a couple of software engineering and DevOps related tutorials. So if you're interested in that, please do check it out. But more importantly, now, feedback. So for feedback, we're very interested into any kind of general questions or general feedbacks, but also some specific points. So the API design, so we're saying, okay, we're using GraphQL to try and make it easier to use. What do you think? Is that a good idea or do we strip abilities? Like is there anything that you can only do with Gremlin or can only do with Cypher that we definitely miss here? And very similar on the connectors. Like, do you think it's a good idea to have this kind of abstraction to be modular? Or do you think there's some kind of, let's say, specific features that only Neo4j have that we would benefit from? So this would be one of the other questions. So, feel free. So we have four minutes left for questions. Perfect, first one, yeah, I'll repeat it. Yes, yes, so the question was, is there a way to not just fetch anything specific, but basically the entire graph? Like if you don't know the anthology, but you know you want to query a specific domain, is there a way to just get anything? Yes, on the GraphQL API, we have an introspection function where you can basically do exactly that, saying you are in a network, you know your own anthology in the network, but you don't necessarily know the anthology of your peers, but you do know that, for example, your peers are in one industry, then you can use these kind of queries to just discover what it is in that anthology. Thank you. Other questions? Yes. What does the STL look like, the GraphQL schema for your API? What does it look like? Like how do you mean that? So usually GraphQL APIs are driven schema first, so you write a schema, and then you have the API on top of that, and then just wanted to know, do you have a like a static STL, or is it generated, or how does it look like? Yeah, yeah, no, I understand the question. Yes, so we have a fixed anthology that every VV8 has to have. Fixed in this case doesn't mean it's fixed, sort of it just means you pre-define it, but you can change it all the time, and then we have, in the peer-to-peer network, we basically cache the anthology of every peer, so peers can have different anthologies, and then we create the GraphQL schema of that, sort of in a, yeah, sort of it is cached at the moment you do the query, of course, because that's just how a GraphQL works, but it can change at any time, just have to invalidate the cache and update it. Another question, so the question was when we built the Contectionary, how automated is that process, and sorry, what was the second part of the question, and what kind of data sets can we consume? So the process to train the Contectionary is extremely expensive in sort of machine power, so we run that sort of once-on-one data set, the current Contectionary that we have is run on Wikipedia, so it's basically just text, but anything that machine learning can do can basically use to train the Contectionary, so for industry-specific Contectionaries, if let's say an enterprise company would have documentation on specific machines, for example, and we could use that kind of documentation to train the industry-specific one, and yes, it's automated, but it's not something we can do on the fly, like it just takes spinning up a big cluster somewhere in a cloud and running it for a long time. Another question, I can't say that entirely with certainty. I think not at the moment, but please do reach out to Bob if you're interested. Bob at semi.network, he can tell you more precisely, but I think it's not open source. Cool. Cool, and with that? Perfect, out of time. Thank you very much. Thank you for attending and your feedback.


Hey friends and welcome to my channel. I am Yoshida and this is Norris Cove. If you're interested in becoming a part of the Cove and would like to see more content from myself please hit the subscribe button also hit the notification bell so that you are notified whenever I upload content. So today let's just dive right in. This is in my Fobonichi. I've been wanting to do diamonds and I'm really stuck. I've drawn this out as you can see I have not filled it in but I'm just not filling it. I don't know I'm I'm not filling it. Let me show you last week and I got to make sure that it's and I even have as much as at first I like last week I started not to like it. This is last week. Got a lot of love on it but I just didn't like it. I mean it was okay as you can see I just haven't done anything in it. I did do some things. I didn't come in here Monday and Tuesday. I did not do a beauty video Wednesday. So this is pretty much here. Let me explain some things if you're new to my channel. This is my video ideas. Let me back up a little bit. This is my video ideas note and I keep it here because this is my social media and this is like my filming order and I was not on my filming order this week and actually I do my Fobonichi first. It's kind of out of order. I need to move that there. So normally I do my Fobonichi's. I start working on my spread on my Tuesday or Wednesday. Today is Friday because I just was stumped on what to do with it. So I had this diamond idea because I'm not using a lot of space so this was gonna be Monday Tuesday Wednesday Thursday Friday Saturday and Sunday and then here was gonna be my notes and stats but I'm not filming it because I cannot. This side came out okay it looked like flying paper to me. I mean this is my opinion and it just really didn't come out in the diamond form and then I finally found a stencil and it had the smaller diamonds but it still again looks like paper to me. So what I'm gonna do I'm just gonna hold on to this and I think I'm just going with stickers today. I'm gonna tell you guys I know what it is. Let me tell you what it is. Next week I'll be back on the track okay and next week I'll have it together. This is not the week. I just remember every month and I'm if it ain't too much TMI but every month when it's that time of the month I get like a pregnancy brain or brain fart and I cannot create. I cannot be creative at all. I don't know I don't know what that's about. So I tried though I tried so but we have these beautiful hearts. I'm debating if I want to use those. I don't want to use the hearts. I did circles last week. So I'm just gonna put in these stickers because you all I I'm just not there today and it's like that sometimes. Sometimes you just have days like that so I just had to be truthful with myself and just be like girl and of course that's crooked so Jesus let this come up. Yeah and I had to like what is going on like why I can't think of anything why can't I get these measurements right and to be honest with you it just dawned on me it just dawned on me and I was like that's it that's it. I know a little TMI but it that's just is what it is and I don't know why I don't like placing them I guess because I'm like kind of unconventional in some things but I don't never like them to be like everything like it staggered I don't know why I like it staggered and it's still a little off but you know what I just had an idea though so maybe I'm not I just had an idea when I had it to the side it reminded me kind of like a TV like the old-school TVs maybe I should do that and thinking of old-school TV that would be a great idea. Like what are some of your favorite shows I was saying in my last video but I wanted to speak and through it is that I'm not a big TV person and I like a lot of the old shows so hope I got some more of these. I see I think I bought an extra one of these books I really do I think I did so I have an extra book it's all good yeah that would be cute but the antennas am I saying it right? So they kind of look like TVs. Look at here. Let me go into my other book. Well no I don't necessarily need to. This will be first stats. I promise y'all today is Friday I will be at the doctors on Monday so you won't hear me hacking again. So yeah tell me some of your favorite old television shows. Mine believe it or not I love Golden Girls I love Sanford and Son. Now let me tell you I used to look at I used to look at each love good times I can't do good times anymore I just realized how angry James was and I understand his frustration okay I get it but I just was like you know what this is this not good I'm he getting on my nerves so I could so now when I see good times I can't do it I just cannot I just don't look at it but you put some golden girls on I'm on it all day every day I can do and believe it or not I love Andy Griffith I love Colombo and let me explain something Colombo comes on my Thursday Colombo comes on I'm not moving if it's a marathon oh my god and we have like we have fire escape we have direct TV but we have files internet and some people get the Hallmark movie channel well you have to pay for our Hallmark movie channel and sometimes I guess we just get free and it'll be on so I'll record it and I will sit there look at the same shows I've been watching since the 80s and 90s all over again oh I made a mistake Monday Tuesday Wednesday Friday Saturday I didn't do Sunday so I'm gonna have to go take all of these out the good thing is it could be fixed we'll put these at the bottom because I kind of already know they're gonna fit so yeah tell me something your favorite older television shows so we that's what we might do I think we're gonna turn these into TVs so we can get another box so I gotta find my other journal and sticker books so hold tight you guys I knew I boarded I'm like I know I got another journaling book because when I ran out of something I was like I need to have yeah so this is what it is this week because I'm telling my brain matter of fact just said I was gonna turn the TV see I'm talking about I'm having a time yeah so let's turn those into TVs that crooked I think I turned the pages crooked so yeah as much as I'd like to do these I just don't like it I don't love it I want to do diamonds but I would basically have to write put the dates there I don't know and then I thought about the colors so I'll come back to that when I don't have the truck bring so we got so let's draw out some okay yeah I'd love to think that I am a artist but I'm not how hard could that be remember and tell us and I say the right cuz I'm a little country so I may say and tell us and they might be in and we gotta make some okay I'm just gonna trace those in black I'm just drawing here we go so I like we go with this pretty girl I wanted something that can kind of be on the screen of the TV and I was so upset cuz I ordered these wrong wrong stickers from wrong wrong actually before they came out with the collab and I was like I wished I wouldn't have done that so I have some little minis here like hungro here this one I really like I got this from capital chic design I like her so I just think dolls will be really cute some stickers so add her here with the blonde hair use all little short little people you know what I have one of my daughter so much of this actually capital chic designs is having a sale a 43% off sale if you're interested so like they on TV darling okay let me go get my daughter hold on one second okay so I pointed these for an order and as you can see they got lines running through so I was so upset so I got to I just have to keep these for myself so I'm using them that's my baby girl and okay another story when my daughter was about four a commercial came across the radio oh you want your child to be a star like the Disney stars you see on TV bring your child down to such a such so I you know made the appointment or whatever and it was gonna be a casting call for Disney and my daughter has to me always had like character like she's just she was something else and she could read at four so I was super excited and we all think you know our daughter or our child are the best all right so I took her down there honey and she read the lines and they were so excited and shook and what have you put her here the girl with the money I'm putting her here between goals and stats that's why I like her and then I need to put I know another breaking up I got two of my so anyway yeah so she read and oh she did good and da da da da and I'm sorry I was just running but that was when he went anyway they were like yeah she made it and you gotta pay the five it was like at that time it was three or five hundred dollars a month for her coaching I said I was very on the board about to do it but something was like you know what this this is a gimmick so I didn't think anything else about it and I just like nah she's fine because if she's meant to be on TV she'll be there and sure enough y'all a commercial came on again a commercial came on again and I said oh this is what they do I'm like they just you know they do this all the time so they just getting people I was never so hot in my life so yeah so it was like pretty much like I mean it was like the nerve I'm taking down twice but I'm put some light it with this painting just reminds me of she reminds me of these little people so yeah so and look at it we fast forward she did get to be on TV with college so there's that so you guys I'm done it's probably been a long so you can see and I'm done I'm just gonna leave it like that I like this so pretty oh we got to do our stats I'll do my stats off camera they're coming along I've reached a hundred subscribers thank you all who played a wonderful part in getting me to a hundred subscribers to a lot I know to some I know that doesn't seem like a lot but to me it's a lot because that means 50% of those people tune into my channel and enjoy the content that I'm creating or all a hundred enjoy the content that I'm creating and I do appreciate you guys so so much you subscribing you commenting you know just allows me to keep coming back every week and not giving up and consistency is my word and you're helping me with my consistency whether you know it or not so I do do appreciate you so thank you again so much for watching if you're new to my channel you enjoy today's video you want to be a part of the Cove go ahead and hit that subscribe button also hit that notification bell and I will see you guys in my next video


Will fornet add cars? If so, when? Fornet cars are coming on July 21st. We know this is accurate because an epic employee confirmed it. What types of cars are drivable and where do they spawn? There will be four sides, small, medium, large, and truck. The styles are police, taxi, sports cars according to fornetinsider.com. A major problem with the cars they're adding is that you have to refuel them every time you run out of gas. Fuel can be found at gas stations or from chests in for loot. Where do cars spawn? Basically anywhere you see cars right now, like near roads, garages, and streets. I don't think it will be at parking lots like this because it's gonna be a little hectic there. The mechanics of the car would probably be the same as the golf car from season 5 but faster. I still don't know how many seats each car will get, but I'm guessing from 2 to 4 depending on the car. I think this is a good update from Epic in a while. What do you guys think?


So let's try this, this is law, so it's similar to the last one, except for, instead of solving for the delta H of the reaction, the standard heat of the reaction, we're now solving for one of these heats of reaction up here, okay, so not the one that we're looking for, but actually one of the ones that added up to get the one that we got now. So anyways, recall what we do in order to do this, we have to make sure that everything we've got on this side of the equation is present down here, everything that we have on this side of the equation is present down here, and everything on both, that is on both sides of the equation gets cancelled out, okay. So, I think like Katelyn was saying, this one's pretty straightforward, because if we count the hydrogens, there's two plus one and that equals three. The nitrogens is one, so that equals one, and there's this hydrazine here. That's, well, this is gas, too, I guess, I think, quite good. But, and it didn't, right here and there, okay. So, but that hydrazine, it's cancelled out, and then if we look, we've got two ammonia gas, two ammonia gas, okay. So, these two equations add up fairly nicely to get the delta-heated reaction. So, remember Hess's law is delta-heated reaction is delta H1 plus delta H2, so on and so forth, okay. So, we're solving for delta H1 in this case. So, it's going to be change of H of the reaction minus delta H2. And we have both of those numbers. So, we get 92.2 kilojoules minus 187.6 kilojoules. So, minus, minus, that's a plus, right? 95.4 kilojoules. What is it? Sorry. 95.4 kilojoules. Okay, thanks. 95.4 kilojoules, and it's going to be delta. Is this reaction up here, delta H1, that is showing delta H1? Is that an exothermic or endothermic reaction? Endothermic, right? Because this is actually plus 95.4. So, I know it doesn't ask, but so that means you have to input heat, okay. Are there any questions on this one? Fairly straightforward. Pretty straightforward example that passed this law.