Thank you, everyone, for coming along to my little talk this afternoon. I know it's Sunday afternoon, last talk of the conference, and people are fading a little bit. Fortunately, this is not a deep dive, so you don't have to think too hard. My name is Hamish. Unfortunately, I haven't been able to be at the con this weekend of a good friend's wedding on, but it is my honor to come along and talk today. I am a recovering engineer, now product manager at Coordinates, who's here at Coordinates? We do geospatial stuff primarily, and we've got a web app, which hopefully some people have used. A lot of Python and Django is kind of our deal. So I'm going to talk about flags. A bit of a backstory into a little project that I'm going to talk about is sort of had a genesis at Gather conference in 2015, which is a cool sort of conference that ran for several years, which sadly is no longer in existence. Back then, we had this flag referendum going. There was lots of talk about all this flag design stuff, and there were people doing talks about flag design, and it was really interesting, and I thought that was cool, and everyone was submitting their homemade flag designs, like laser kiwi and all that kind of stuff. I'm no vexillologist, but I have Python. So I thought it would be fun to have a look at where it would be possible to actually generate a flag. And so I did, and I came up with this thing called that would basically take a genome and it would generate a flag design. And this is an example. This is one of my favorite ones that came out of it. The first part is a color palette, and the second part is the actual designs that go on there, so we've got an English cross with a diagonal cross on top of it with another cross on top of it, and that's all encoded in that URL. We're in that sort of bit of text, rather. And that's pretty neat, and you could basically generate all these random things and it would generate these flag designs.  So is that super tiny? No, no one can see that. So basically you could go like, if he calls flag.parse, create random genome, flag.show. It's a randomly generated flag. Let's create another one. Hey, that's the same, because I didn't actually call it stunning. Which is, you know, honestly, half, better than half the submissions that we've done. And I also made it that you could evolve the designs, so if we have a look at that one again, it's pretty crazy. But of course, if f2 equals f.evolve, f2.show, that wasn't very dramatic. Okay, so the idea was that you could take a design and you could evolve it and you could create a new design.  And of course, that was impossibly difficult. So I sort of forgot about it. And then a friend of mine who was running an art festival said, hey, would you like to do something? Again, I'm no designer. I'm an artist. But I can do these flag things. So I thought, hey, it would be really fun to make something that was online and interactive. And they thought that was really cool because they had lots of artists making really crazy things, but not a lot of sort of digital stuff. And so I said that I would put something together. And so I thought I'd put that thing online.  We've been using AWS a lot. And I sort of wanted to learn a bit about it. And sort of EC2 was kind of the way to put something online. So I was like, okay, flag and Postgres, you know, that would be dead simple. No, I just need an EC2 instance. And it's going to have to have Ingenix running Gunicorn to run a Flask app that is behind a cloud front thingy. And then RDS, which is the Postgres-like AWS server. And that was pretty cool. It was a bit of a pain to actually set that up. I probably spent more time configuring all that than I did in building the original kind of flag generator thing. But it worked.  So I could run this thing for next to free. And it looked like, hey, get me out. That was random. Of course, I didn't actually test this bit of it. Okay. Running on there so I can grab that. And here we go. So now it's running in a Flask app and it's generating random designs. And it would save the flags into a database and people could then click the button and evolve the design more. And then you could favorite the gallery. And that was all pretty cool. So I was pretty pleased with myself with that. But it was still running in EC2 and RDS. And, of course, I kind of forgot about it. And then your free credits run out. And then you got a bill for $60 a month. Which I hear is a common story with these things.  But that's kind of expensive to actually do that. It's just sitting there. It's almost never being used. And it's just spinning in the cloud and wasting me money. So this year the same friend was organizing another art festival and said, you know, could we do that again? And I thought, yeah, that'd be cool. I can add some new things. I can make it animated. It's going to have stars and circles. Not stars and circles. But I don't really want to do it in EC2 again. So I had to look at if there was another way. And basically, because all I really need is somewhere to host some static content and some way to generate these flags on demand, I didn't actually need all that stuff that was running all the time. And people were talking about serverless stuff. So I thought, hey, maybe that is an ideal way to start learning about it. So what are the pieces that we can use to do all this? The first one is Lambda, right? Who's actually heard of AWS Lambda? Okay, lots of people. So AWS Lambda basically lets you plug in a bunch of code and something will happen and it will return some sort of result, which sounds kind of trivial, but the fact is it's running in AWS's infrastructure. You can call it a million times and it will just happen kind of magically. It also can be triggered by a whole bunch of stuff. So you can trigger it on an API request. You can trigger it on all sorts of events that happen in AWS. So you kind of look at the list of triggers and it's kind of daunting the number of things that you could sort of plug in from one end of it. And then it's got full access to the internet, but it's also got access to all your internal resources. It's got things like Bodo sort of built in as well. So you've got all the power of that particular library to talk to all your AWS stuff. The pricing is interesting. You pay per megabyte memory per second of execution time. And you kind of got to say how much memory the thing is going to use. So at the lowest tier it's 120 megabytes of memory, and you're paying for each second and 100 millisecond intervals. But the pricing is insane. It's at that tier 3.2 million free seconds, which I think is more than a month of just execution time free. And then beyond that, it's 0.000000000000. 0, 0, 0, 0, 0, 0, 0, some numbers, 0, 2, 8, 100 milliseconds. So it's very cheap to actually do all the trivial API stuff that I'm trying to do is essentially free, because if I actually manage to hit 3 million seconds of up time, then I've become sort of an insanely famous artist. And paying the subsequent bill of infinitely small number of cents per millisecond, it would just be irrelevant. So I can actually try and do that. So I'm in ABS Lambda. This is what it looks like. So that's the console.  We can author from scratch. It supports a whole bunch of runtimes, but hey, 3.6. Not that one, this one. You have to give it a roll, which gives you basic execution, which is cool. Test function for fun. Right, and it creates this Lambda function. You can add a trigger. So you can say how it is actually executed. But just for now, we can actually go and create our function. We've got this coded thing here, which is kind of crazy. So we can just sort of save that. You can test it. You can give it all sorts of test data as well. So you can set up sort of like, I guess it's a bit like a unit test for your extra lambdas. You can actually run the test. We can see the result. We can see how much memory was used. We can see the build duration, all that kind of handy stuff. It seems a bit kind of 1995. I'm editing code in a little thing online. It's a bit like uploading zip files to like FTP servers or something at this kind of level. But the fact is I've just created a function that runs in ABS. So that was super easy. If you are doing things more complex, then you can build your virtual environment, and then you can just basically upload the whole thing. It's got a whole bunch of stuff available already, like Boto I mentioned before, and requests. But anything else you want to add, you can package in.  I think it's called Lambda Functions. It's basically a whole bunch of pre-built stuff that you can bring into your project and upload it as well. So we've got a Lambda Function, right? And now we need to have some way to talk to it over the internet. And so I can't remember when Lambda first came out. It was a little bit limited. It had a bunch of functions, but didn't have a lot of ways to actually interface with the functions. And then API Gateway came along.  But it's cool though, because you can set up different resources, different models within API Gateway. Authorizers, so if you want people to be forced to use their sort of two-factor, authenticated AWS account to talk to the API request, you can set that up. If you want it to be publicly available to anyone and anyone, then you can. Different methods. You can set up different deployments. It's got monitoring baked into CloudWatch too. So you can see everything that's happening within AWS's own monitoring infrastructure. Even beyond that, it's got all the business logic that you kind of want around a lot of these things as well, so you can create usage plans. You can generate API keys. You can set rate limits. So you can have a particular set of API keys around a usage plan that have very low rate limits, then you can have a different set of API keys, which have much higher rate limits, for example. What's really cool is you can generate documentation from your API, or you can import APIs to find in Swagger, for example. And again, the pricing is pretty cheap. $3.5 per million, that's US dollars per million API requests. I should expand on that as well. With API Gateway and Lambda, it's per requests, and then the transfer fees as well. So if you're pushing data in and out of US$3, then you're going to pay those transfer costs. Usually, if things are in the same data center, same region, a lot of stuff is free as well. That's pretty cool. So if we go back to our AWS console, then we can actually create an API that talks to that Lambda that we created. So I can go create API, test API. So you can see import from Swagger and all that kind of stuff. We can create a different kinds of methods and resources. So here we can create a get method. So at the root of our API, there's a single get method that we can do. It's going to call a Lambda function. And we are in API Southeast 2, which is a fancy name for Sydney. You just plug in the name of your function, which was test function for fun. Save. OK. It kind of adds the necessary role permissions as well along the way. And here we can kind of see a bit more of the detail of what's going on. When a request comes in, it is then forwarded to the Lambda function. It is processed. The result is then passed out again. And along the way, you can do things like transforming requests and adding headers and adding other tests along the way.  But fundamentally, there's all the usual kind of things you might want to do with an API. You can set up. So here we've talked about gateway responses so if you want to set up all your 500 pages and 400 pages and you can do that all here, you can set up your authorizes, different stages. So at the moment, we've got an API that is going to call our single Lambda function and return something. At this point, we need to deploy the API. So we're going to deploy it to a new stage, which we will call test. And if we open that, it will. So I've just created an API, like it was that easy. It's a trivia API for sure. But you can think of how any little like, you get an idea for a slack bot that you want to create. And then like, ah, but then I need to have a thing that runs a bot server that is going to handle the incoming web hooks and that kind of stuff. Well, now you can probably do this all in the console, just typing things in, hacking around in a couple of hours just for fun. And that's really cool. I really like the way that you can now have a little idea. You can spin it up and test it out almost trivially. And the cool thing about this as well is so you've got a whole bunch of, you can now start adding different types of stages. So you can have like a development stage and your production stage. And you can switch, you can deploy different things. And yeah, it's neat. So we talked about usage plans. So you've got things like usage plans that you can create for different APIs, throttling burst rates as well. So if you're infrastructure, this thing scales more as infinitely, right? So if your infrastructure that your API request is going to call is going to be destroyed by a sudden influx of 1,000 requests, then you can make sure that doesn't happen as well. Quoters, all that kind of stuff. You can also throw them by custom domains as well. So by default, let me have a look at this stage. So that's a pretty crazy URL, but you can put your own custom domains in front of that as well pretty easily, which is neat. Any questions so far? Richard? Yeah. Yeah, so the question is, what do you do when you want to save state? Yeah, you're going to have to connect to a database or any other appropriate service for that. Yeah, RDS is the Postgres black one. So you can connect to that. Or I'll talk about what I did for the flags one in a second. But yeah, that's true, right? All you're getting is compute time. That's what you get. But you've got effectively, infinitely scalable, incredibly cheap compute time. So the other thing about lambdas is when you actually configure them, you are going back to lambda. So you have to say how long you think it's going to run. So you have to give it a maximum timeout, and that maxes out at three minutes. So that's a three minutes or five minutes, one of those. Three or five minutes, I can't remember which. And you've got to say how much memory you expect it to run. If you hit the memory cap, then it's going to get killed. If you add the timeout, it's going to get killed. So that's where things get a little bit different from running your own stuff in EC2 machines, for example. So of course, the last piece of this particular puzzle is S3, in case you're not aware. S3 is Amazon's simple storage service. Big database of objects, where you pay for what you store in access, and it's very cheap. But the other thing that some people might not be aware of is you can also use it as a static web post. So if you give your bucket name, like example.com, call it example.com, and then you point your example.com domain at the S3 path, then it will just start serving content as if it was a static web post, which is a really cool feature. But it also interesting, dots into bucket names causes other people all sorts of pain, if you've ever had to talk to buckets via the API before. So Foflux 2017 uses all of those things. And you can go visit it, so Foflux.nz. So basically what you're looking at is a really cool animated thing. And it is hitting an API, which will then generate the random genomes and send you back the image. So it's generating the flag. It's saving it to S3, and then it's redirecting you to the S3, or returning the S3 URL so you can then display it. It's got stars and circles. Didn't work out that great in the end, but I kept them. And in this case, what it's doing is it's taking the genomes and evolving and giving you images. So this has been running for a while now. It's had a little bit of use, I guess. I'm storing maybe 10,000 different flags. All of these cost me like $0.20 a month. So that's pretty cool. That's really handy. Now the way that I actually got that on there, Zappa. So I think someone mentioned a lightning talk I was told. So you want to see before I was in the ADS console and I was sort of typing in code and then manually setting things up. If you've used ADS in anger, you'll know that everything is behind an API. You can manage everything about ADS via an API, which is what is awesome. It means that you can do all that kind of stuff that I was doing point and clicky. You can do via APIs.  But then you push it to the appropriate serverless services to actually execute it. I haven't looked at many of them. I've only really looked at Zappa and even then not in a lot of depth. And the reason I looked at Zappa was because it seems to be very geared towards Flask and Django deployments, which I was using Flask and so that seemed to make sense. But it's cool. It will build and package your project. It will deploy it into a Lambda function and to an API gateway, configures everything for you. And then it gives you handy CLI for actually deploying and rolling back. So if I go back to here, I'll just close that one. And we go. So at the moment, I've got this hooked up to, so this is the Zappa instance for 5Flags.nz. So I can do things like Zappa Tail. And that will basically talk to CloudWatch and get my logs and give me the most recent activity from the logs there.  So it's not ideal. But there's a whole bunch of combined options for filtering and the kind of stuff. It's also slow. There we go. So you can see all the stuff that you would normally see. Well, you can filter your different log types. You're going to get a lot of internal lambda execution kind of noise in there as well. So you want to filter it down to the things you're actually interested in. You can do Zappa deploy to initially get your stuff out, Zappa upgrade and your stage. So the update dev. So Zappa update dev. So if you make changes, it will then find all the changes, repact them up, deploy it out, and just make it available. So Zappa is really cool. It's, I don't do that on my mobile connection, actually. Yeah, so you can deploy a particular stage. You can update a stage. You can, oh, sure, roll it back to previous stages. Take your logs. It's also got some handy extra features, so scheduling. So you can set up basically scheduled lambda functions really easily with Zappa, which is cool. So you think about all the things you might use salary for, for example. You could look at whether you want to actually use that for lambda functions instead. You know, you might have a whole machine right dedicated just to running salary workers. Do you actually need that spinning all the time? Also, I mean, some of the stuff we do, it is bursty.  And we've had issues in the past where, you know, a large spike in activity can actually lead to real big problems in salary queues. We just wouldn't have that problem with lambda. Of course, unscheduled. So that's pretty neat. Some downsides with Zappa in particular, and I'm pretty sure this is just from what I've had to look around, this seems to be reasonably common. Ease of use is awesome, but you're really papering over a lot of the complexity. And I feel like what you want to do is understand the complexity in a little bit of detail first before relying on one of these frameworks, particularly right to the last point. The default IAM roles that I sort of asked you to set up are really liberal. And it's so easy with AWS to slowly creep your policy to the point where you've got some lambda function role over here that turns out has global read access to history over here, and that credential leaks, and everything falls over. So I feel like there is some danger there and not necessarily understanding how AWS kind of works, how IAM works, all those kind of things. IAM is the user management kind of portion. With Zappa, it kind of cheats. So instead of setting up all the different routes as API endpoints with an API gateway and then a whole bunch of lambda functions that might handle the different Flask methods that you've set up, it kind of just pack it as the whole Flask gap into a single method, into a single lambda function, rather, and it gives you a single API gateway endpoint and just kind of lets those components, particularly the lambda function, kind of handle everything. So I kind of feel it's cheating a little way. So if we have a look again at all my lambda functions, I've got one lambda function for that for Flags app, even though there's five or six different endpoints under the hood. And in API gateway, again, there's sort of five or six different endpoints that you might actually hit. But what it has is just a single proxy thing, which basically takes every request and passes it right after the Flask. So it's kind of cheating in a way, but it works. And it's really great for hacking things together quickly. So I'll talk really quickly. I think we've got 10 minutes left. Is that right? So that was kind of a fun project, right? But one really serious use case that at coordinates we used lambda in particular for recently was a migration project we had going on this year. So coordinates, we had three kind of on premise, sorry, three instances of our whole stack. We had two local kind of on premise type installations, and then we had our own version running on AWS. And we had to merge the three into one. And we had shared identifiers between all three projects. We needed to be able to merge everything while it was running. So there was essentially going to be minimal downtime. We're talking about an evening of downtime. And the particular thing that I was looking at was the analytics system that we had. We had six years of analytics history. Right now we pump in 50 million events a month. All the shared identifiers in that history had to be rewritten to merge all our history into this single project. And it had to happen with no downtime. So one thing that I find this kind of good for is those kind of ETL kind of tasks, the extract transform on load kind of tasks. So in our case, we were using Keen.io. Does anyone use Keen.io for analytics stuff? Yeah. It's really cool for just running usage and kind of thing where you get a million different events happening in your system. And you want to see how many of those events summed up by some dimension based on the user. And then it's kind of like a purpose-built database of event collection that lets you spit out analytics data very quickly. So we had an enormous amount of history of that. And they have this handy feature where they can stream raw event data into S3 buckets for free, which is really neat. So you pump in all your event data. And every five minutes, they push it back out again into an S3 bucket. What's handy is that Lambda can be triggered by S3 puts and posts. So you can trigger Lambdas on all sorts of different events in Navies infrastructure. But S3 puts is a really interesting one. So basically you can tell it to anytime S3 sees a new object, run a Lambda function. And that Lambda function can do anything. So in this case, what we set it up to do was every time one of these buckets of data came in, extract the data, find all the identifiers, change the identifiers to what we know that they need to be now, do some other maintenance along the way as well. So we're like, oh, these things were originally designed sort of five years ago.  The same people still work here, but now we're a lot smarter. So we can fix some things we've always wanted to fix. And then we can push that data into a new Keen project. So what we had was three live running projects that were then streaming all of our analytics data into a new project, but now with non-conflicting identifiers. So that's pretty cool. And what it meant was that come migration day, we could basically point old project, you point the whole system with all the merged data at the new merged analytics system and things just keep working. You know, it's the same data, but all the identifiers in the database have changed, all the identifiers in the analytics system have changed. Users completely aren't aware that anything actually happened. The other part of that was backfill. So, you know, we had half a billion historic events that we had to pull out of the existing projects and do the same transform and load process on. So there's a couple of things we can do there. We can massively paralyze it via Lambda as well. Some of those things we can aggregate. So we're like, well, actually, let's have some special Lambda functions that will actually run queries on our analytics system and take, you know, a day's worth of queries which might be like a million events and then spit out an aggregate of the dimensions we actually care about and so you might get a thousand events on the other side. To actually call that, we can then, we plugged a API gateway in front of it so that we can say, well, I want to migrate this bit of data or this timeframe, hit a button and it will asynchronously go and call it. With API gateway, you can do things synchronously or asynchronously. You can do, so the event, the example that we did just in the console before is like a synchronous one. It's calling the Lambda, it's returning the result of the Lambda. You can also do asynchronous calls where it'll immediately return, yeah, yeah, I've triggered the thing. Now it's up to you to actually make sure it actually happened, which is handy because you know, we're doing things that might take, you know, half a minute and we want to be able to run a whole bunch of them and monitor their progress. Yeah, so we did it, we massively parallelized it and then we got an email from concerned engineers at Keen saying, hey, that's great that you've done the migration but you're damaging our infrastructure because it turns out that actually running thousands of these things at the same time is not being a good citizen.  The other lines are sort of the more normal background activity that was going on at the same time. So basically we backed it off and we said, okay, we can actually run this and it'll take a couple of weeks to actually process all our data but we can do it backwards in time and again, no one's really the wiser that we've made this major transformation under the hood. So just last of all, just some gotchas learning some thoughts from my sort of relatively limited experience for all this. Big gotcha, async lambdas will sometimes fail for mysterious reasons and the policy is they get reached quite twice and then discarded.  Oh, there's some extra data. Where did the starter come from?  Because what happened is it actually did the ETL process and then I suspect what's happened is the system that actually checks that it's run correctly has fallen over and then it goes, okay, I'm gonna try to get in 10 minutes and it's 10 minutes as well.  But then you come back in a quarter of an hour and all your data's wrong. Sorry, I threw out a stick. So you can look at dead-let accused for SQS and SNS for unexecuted things but you do need to handle double execution properly. Latency is a problem. So that faux flags up, I think latency can be about a second sometimes. You're not gonna get the same with that approach. The ECT approach is gonna have better performance. There's a thing called Lambda at Edge now which I think might help a lot. There might be a whole bunch of configuration you do to improve it but generally it seems latency is not great. Of course, if you worry about lock-in, then if your business is built on this, then it's gonna be pretty hard to switch. That said, it is just Python functions talking to gateway routes. So a lot of these frameworks, some of them are designed to be able to cooperate with Azure and all that kind of stuff too.  So you kinda see this with the likes of Keen.io and other sort of API-based companies where I think a lot of them are racing to the value add on top of it. That because you can come in and just build your Slack bots or your analytics platform or whatever without having to deal with Opsbird and that you traditionally would have had to around the same sort of high volume services. All right, so that's me. Any questions? So just give me a second while I try to come up with it. For the production use of Lambda you were talking about, are you using Zappa to manage those, or? Sorry, sorry. For the ETL and the analytics thing, are you using Zappa to manage those, or? Are you using what? Are you using Zappa to manage those? Oh, Zappa, no, no. So no, we did that before, we did that before, they came before the flags thing. I guess also because it's a business use, a little less inclined to like use the thing that has a lot of IAM or permissive IAM role to do something that important. That said, if I was gonna do it again, I would definitely look at actually the proper framework for doing it rather than you build your function and then you zip it up and then you upload it and then you test it, it's very like a Z95 where you're sort of uploading things by FTP. It feels very similar. I do think it's gonna be a little while before the very big list of frameworks is rationalized to the two or three really good ones. Yeah, yeah, I think so. Yeah, I mean, you do have limits, right? So you gotta look at that execute. It depends on the kind of data that you're capturing.  Yeah, you'll need to talk to RDS or something similar, yeah. So the Lambda function, the API response that you're creating has a funny URL. How do I make it pretty? You can plug your own URLs in front of it too, so your own domains. There's stuff in there for doing that and you can also put certificates in there too. So you can make it sort of SSL protected under your domain relatively straightforward. Yeah. Sorry, we've run out of time. Thank you, Hamish.


Okay, look just look straight ahead Now look to your right look to your left Look up look down look straight ahead Close your eyes really tightly now open them up wide tight again Open them up open up as wide as you can Hold them open as wide as you can and now just relax Now look straight ahead


A detailed review of the current state of art for wind turbine blade design is presented, including theoretical maximum efficiency, propulsion, practical efficiency, HAWT blade design, and blade loads. The review provides a complete picture of wind turbine blade design and shows the dominance of modern turbines, almost exclusive use of horizontal axis rotors. The aerodynamic design principles for a modern wind turbine blade are detailed, including blade plan, shape slash quantity, aerofoil selection and optimal attack angles. A detailed review of design loads on wind turbine blades is offered, describing aerodynamic, gravitational, centrifugal, gyroscopic and operational conditions. This article was offered by Richard J. Crossley and Peter J. Schuble.


In my videos, I always try to share advice that I wish I would have learned sooner in hopes that it will save you months, maybe even years of unnecessary struggle. Struggle may be necessary in the case of growing in the ways that are purposeful, but there are certain myths and I guess you might say limiting beliefs that keep a lot of people struggling unnecessarily. And this one I want to talk about today is around creating. I know a lot of you watching this would love to become professional creators or to create in a way that brings the right clients to you, the right connections to you that give you the professional opportunities and the personal fulfillment. And now that I've created over, actually I've created almost 2,000, I've created well over 2,000 videos. Almost 2,000 of them are currently uploaded on my YouTube. And I have made more than 30 online courses that were launched, each of them were launched by themselves. I know I create a lot and written hundreds of blog posts. I was really stuck in the beginning and throughout the first couple of years, I was kind of stuck with needing to get the right order of topics, of subtopics, the right order of ideas before I started putting myself out there publicly. This is why it took me, okay, I started my business in 2009, just to give you a bit of a timeline understanding here, 2009 I started my business and I didn't start creating content consistently until 2015. That's six years later. And like I said, those years were stuck in my mind. One of the big blocks was, well, I don't have the right sequence of ideas yet. I'm still figuring things out.  I'm still working on my website. I'm still getting my framework clarified. I'm still needing to understand, okay, this must be step one before step two, before step three, before step four, whatever the sequence should be. And I wonder, do you ever feel stuck in that way?  Well, I hope that this video really helps to unblock you. So when I finally got tired of saying I'm done delaying creating content, it's been six years of trying to figure out the right ideas and I was still figuring it out. I don't know about you. Maybe some of you watching this have been trained in a particular method that's supposed to give you the, this is step one. This must be step one before step two to complete transformation and, well, okay. If you have a particular method that you're going with, then you already have your sequence of ideas. Why don't you just start creating now? And yet, even if you've been trained in a particular method, I believe that you're going to keep learning. And probably some of you may have been trained in multiple methods that you're trying to integrate into a whole. That's true for a lot of us who are multi-talented, multi-passionate and just curious learners. So how can you possibly know the absolute truth of what is step one, step two, step three, on the journey of transformation, even in your niche, have you found all the knowledge that you'll ever find in your niche? It's ridiculous to consider that because if you've discovered all the knowledge that can possibly be discovered in your niche, you're done growing. Sorry, you're done learning. And years ago, a professor changed my life when he helped me to understand this. He says, George, I can see that you are passionate to discover the truth, but you keep coming to me, trying to convert me to this particular way of thinking. And the way that you're passionately trying to convert me suggests that you already know all the truth. That's why you're trying to say, this is the one right way of doing things. Well, George, I've lived a few years longer than you. He was way older than me, obviously. He says, you know, I've discovered that in our pursuit of truth, if we are not willing to be open to additional ideas, then we will miss some of the most important truths that are necessary for a more holistic picture of reality. In other words, George, he said. I can see that you are very uncomfortable with uncertainty and you're discomfort with uncertainty and your unwillingness, therefore, to allow yourself to experience some uncertainty is keeping you from more of the truth. It's keeping you from finding even greater understanding of yourself and of reality. So in order to truly discover the biggest truth, the deepest truth, the more comp the most comprehensive truth that we can, we must be willing to experience that feeling of uncertainty, of, you know, this is what I understand right now, but I know that there's probably more to and what I'm going to learn maybe a year from now, maybe 10 years from now, maybe 10 days from now, maybe 10 minutes from now, I'm going to learn something that might call my sequence of understanding into question, meaning, oh, people, my ideal clients should do this before they do this, before they do this, before they do this, that sequence of the transformational journey that you lead your clients on or that you understand for what, how someone should solve a problem or achieve a particular goal, that sequence could be quite destroyed as you learn greater understanding of how people change, number one, but also as society changes, how the transformation journey is different now. So, and as people, you know, as you discover more about human beings and about yourself and about reality, that sequence of ideas is probably going to have to be revised again and again and again and again. So, when I began creating again, when I began creating really content in 2015 consistently, I was reminded of that lesson from my professor of years ago, and I said, ah, I've been stuck for six years believing that I had to get to the right sequence of ideas. I have so many ideas, I have so many ideas and I feel like, oh, maybe my ideas aren't that great. I have to wait until I have better ideas and I have to wait until the formation of my worldview is complete before I can create content consistently because what if I teach something and then I learned a month later, oh, maybe that wasn't the best teaching, that maybe that was wrong. So, I have to wait, I have to keep learning until I'm ready to create. I'm so glad that it only took me six years to get tired of waiting. I don't know how long it's taken you, hopefully less than six years, or some of you may have been 60 years. I don't know, but I learned this important lesson. I remember it was a mind of uncertainty and then I learned this lesson to just begin creating, therefore. Because in the creation, in the speaking of our ideas, the writing of our ideas, the creating diagrams about our ideas, it could even be, comes the clarity and comes the questions also to say, okay, I just said that, but I realized what about this then, or what about that situation? Or what about that idea? And then, like I said, you're going to come across additional brilliance from other people and from yourself in the coming days and weeks and months, which will then call into question your whole framework again. Now, of course, over the years, as you learn more and more, and as you teach or create more and more, and as you get feedback from your audience and from the market about your ideas, you're going to see what resonates the most with people. Right? What actually helps people the most. And then you'll be able to confirm, oh, that's right. This idea was really good. This sequence here in the later sequence is actually good. In the beginning, I'm not getting much good feedback about the beginning sequence yet, but the later one, this part of it, you're going to get feedback that helps you to confirm your ideas. Now, even that's dangerous because you can get ossified with your philosophy and become too certain about your ideas and then kind of stop learning as much as you could. So again, the lesson I learned is to just create what feels true, what I believe to be right today, to just put it out there. Okay? Knowing very well that I could change my mind in a year. I could change my mind in three days or even a day. So it doesn't matter because if I don't change my mind, I'm not really growing and learning. I don't understand those people who go, well, I, you know, I never changed my mind about this. And look, I've been right all along. Now that, I understand that might say something about how good of a judgment you've had all along, but I don't know. I think most of the time, I think it's wiser to say, yeah, I've changed my mind about so many things because I've learned so many things, but I've always shared what I believed along the way. I've always shared, this is what I currently see because what I currently see and sharing with everybody could really give a very important hint to somebody else who's on the journey as well. And sometimes we need to believe certain things and try to live certain things before we're ready to understand something greater that called the previous philosophy into question. You see what I mean? Sometimes someone needs to understand or believe that first before they can understand and believe the thing that you are now more advanced and wanting them to jump to right away. Because they need to experience that earlier stage or you might call earlier stage or just a different stage of development so that they can really know what that's like before they're ready for another stage, perhaps where you are at and things like that. So this is why wherever you are at in your growth, please know there's much, much more ahead of you in knowledge, wisdom, clarity. Okay. And if you don't share what you currently know, you are, you're not giving the benefit to so many others who need that right now. Number one. And number two, the act of creating creates clarity, more clarity, not the other way around. It's not we get clear and then we create.  And I instead hope for you to create a habit and an instinct to say, okay, this today, did I share something? Now I deal and when I was starting to create consistently in 2015, I made a commitment to create every single day. I took the weekend off every week, but I created five days a week. I created and shared and posted five days a week for a year with very little people liking it. And it was just, I knew, because I knew that, okay, my first year of creating, as often as I could, it's me working out my ideas. It's me learning how to be on camera. It's me learning how to write again, because I had writer's block really for all my life. I felt like up to that point. I was always very insecure about my writing. And I was insecure about how I looked on camera also, by the way. So I knew that the first year of creating was working out those muscles, working out those insecurities. And it's a good thing that very few people liked it back then, by the way, right? Because now that I look back and go, oh my gosh, my ideas have definitely changed. I thought that was the truth back then. And now, gosh, I now I've learned more. I've lived more of life. I've experienced more of humanity. And now what I'm saying, obviously, I believe is more of the truth than what I did. And also, I hope that 10 years from now, when I watched this video and other videos of this era, I'll say, oh gosh, wow. That was what I believed back then. And that was what I was authentic about back then. And now I've learned even more. And I've changed my mind about certain things, right? So please, please don't delay. You have to, this moment will not be this moment. Today is unique. What you believe and understand about reality and about life and about transformation and about your work is unique today. So in other words, I have this kind of time capsule mindset, like I got to get this time capsule out there.  Well, every day is a time capsule opportunity. So create first, create now, create today, and then worry about the sequence later. That was actually the main message of this video. And I barely even talked about it. But let me just talk about that as we end this video here. I have written four business books. And you know what? I wrote authentic content marketing. I wrote joyful productivity, authentic selling, and then principles of authentic business. Well, when I wrote my fourth book, number four, as I wrote it, I'm like, oh my God, I should have, I should have published this book first. Principles of authentic business should have come first, not fourth. Right? I should have done principles on authentic business first and probably joyful product to be second and probably authentic content market third. And anyway, I was like, the order is wrong of how I publish my books. Is that the end of my, is it at the end of the world? No. Is that the end of my career? No. Is that, is that embarrassing for my writing career? No. I don't think so. I mean, maybe, maybe you think that's embarrassing and that's fine. But I realized I wouldn't have known that this would have, I probably wouldn't have even created principles of authentic business had I not created so much content along the way to realize, oh yeah, these are more principle based types of content that I should put into that book. You see, I couldn't have them. So it's okay. So what did I do? I simply started creating second editions of each of my books and then I actually created the second editions in the original order, which is not the ideal order, but whatever. I just, you know, it's like, okay, it's been a couple of years since I published second edition. So here it is. There's more of the story is and the same thing with online courses. I taught this course and then that course and then that course. I'm like, oh my gosh, this seventh course should have been the first one. That's okay. Maybe after the next cycle, I'll teach the seventh course first. This is true with blog posts. This is true with videos I make. This is true with, yeah, all the ideas that I share. I'm like, okay, I don't know if this is going to be, this should have been first or, or, you know, 85th idea, but I'm going to share it now. And I've also learned that every piece of content, every course, every book I write, ideally should stand on its own and not have to go, well, reader, you should read this other one first before that one. I mean, I understand some of you might be reading writing fiction and there's a story arc, but even fiction, right? I mean, you've seen certain movies that there was a prequel and like, oh, I didn't see the prequel yet, but I was still very much enjoyed this movie. And now I'm interested in the prequel. The one that came supposedly story arc came before. Every piece of content I recommend to you should stand on its own without saying, please read part one before you read the following, because guess what? People are, especially people who are checking you out and even people who are dedicated loyal fans, they might go, well, gosh, I don't know if I have time to read, go and look for a part. Maybe you linked part one. That's fine. But I still, in my experience, like I said, of creating thousands of pieces of content by now, every piece of content ideally should stand on its own. If you can do that, just assume, you got to assume that the reader has some background knowledge, enough background knowledge and they don't. It can still enjoy what they're seeing. They don't have to understand 100%. They can enjoy what they understand and then let them go and explore other things later. All right. Because people will come to your blog, they'll come to your video channel, they'll come to your social media page and they'll just consume whatever is at the top. Maybe you pin certain things at the top, that's fine. Maybe you pin something at the top and it's really old, it kind of looks awkward too. So just let each piece stand on its own and just create what is your understanding of truth now, today. And then you can sequence later. I hope this is helpful. Thanks for watching.


Hello, I'm Shirai Satoko. It is a great pleasure for me to be here and share with you some of the findings from my field work in the Andrapa language. Here are the contents of this talk. First, I provide some basic information about the language, geography, and culture of the Andrapa people. Next, I will profile features of the Andrapa language. The last section will discuss some of the distinctive linguistic phenomena. In this talk, I will focus on the directional prefixes and related phenomena. OK, the first part is language and people. Andrapa is spoken in these mountainous areas where steep mountains and deep valleys meet. It is located in the western part of Sucram province, China. Andrapa is a Tibetan term for the people who speak this language. In Chinese, it is termed Drapa, pronounced as Drapa in Sucram Mandarin. In their old name, the people is referred to as Drapi, and the language is called Drakke. Drapa is one of the Tibetan-Berman languages which belong to the Sino-Tibetan language family. A number of languages with similar typological features are distributed in the vicinity of Drapa, forming a language area. We call the area as the Chiangik, language area, or the western Sucram ethnic corridor. These languages are also hypothesized to form a genetic branch called Chiangik. In particular, genetic relationships are being established for the gharongik group of languages indicated with the blue triangles. The Chiangik language area is located at the eastern end of the Tibetosphere or the Tibetan cultural area. The Chiangik languages are surrounded by three major languages with a written tradition and numerous speakers, that is Chinese dialects, Tibetan or Tibetan languages, and Ii or Loloish languages. Drapa is one of such minor languages. And in this area, villages are scattered among steep mountain valleys, and so they themselves say each village has its own dialect. According to preceding studies, approximately 10,000 people speaks Drapa as their first language. There is no writing system or traditional writing in this language. Tibetan has been the traditional lingua flanca in this area, and Chinese is now the predominant language. So Drapa has been under the strong influence of these languages. Dialect differences exist even in this small language, and it is considered that there are three dialect groups, northern, southern, and central. In this talk, I will use data from my fieldwork on the metro dialect, the most northern variety. Drapa people live in stone houses as seen in these pictures. They are known for their matrilineal society with so-called walking marriages. They live by cultivating a small field, raising a few livestock, and gathering wild vegetables. Men often go to distant towns to work. This is a traditional kitchen.  Okay, I hope you're interested in them. Then let's move on to the linguistic part. Phonology. This slide shows the inventory of consonants and vowels. In addition to these basic segments, we can find pre-nasalized consonants. For example, belly, all, or pay, ice, and so on. Pre-aspirated consonants, such as abu to learn, dopu to carry, and so on. And other consonant clusters. Drapa has word tones that is distinctive pitch patterns that are carried by phonological words. They are categorized into four tones according to the pitch pattern of the first two syllables. High level, which is realized as high high of the first two syllables. Second is high falling, high falling, and realized as high and low of the first two syllables. Third, low rising, and that is low high in the first two syllables. And low rising falling, which is realized as rising and low of the first two syllables. And the rest of those are realized as low. However, the lexical tone may be overridden by the intonation or post-lexical prosody of the topic or focus. For example, the word for teacher is ge ge. So this is a playing pattern. Lexically, this word has tone three, low rising tone. However, when it comes to the topic position, it may be pronounced as ge ge, as high high. Or it is focused on, if it is focused on, it can be said as ge ge, as tone four, rising and low. From a viewpoint of morphological typology, DRAPA mostly shows a cognitive features. It employs both prefixes and suffixes. For example, verbs can take a directive prefix, a negative prefix, an aspect suffix, and so on. In this example, dotte and ching mo xia, this means nothing other than the harsh harsh have remained. And actually, it means everything has lost. In this case, the word stem is xia, remain. And two prefixes are touched before the stem, no, outward directive, mo, the negative, and suffix, suffixes attached here are is a factual and perfective suffix. Adjective stems can be reduplicated productively and form nominalizations. That is, adjective stems have verbal features, since they can take verbal affixes, but the reduplicated adjectives show nominal features, such as being an argument of a sentence. For example, zo is this stem, that means the sour. And this stem can have verbal affixes, such as oza. This means it has become sour, or it has rotten. And upward directive prefix is attached, and the perfective suffix is also attached. These are verbal affixes. On the other hand, when it is reduplicated as zozo, it is nominalized. So it can take classifier, noun classifier, and it can mean a sour one, something sour. Syntactically, it is a vowel final language. The basic constant order is s, o, v. Grammatical relations are indicated by case markers, and case markers are post-nominal and critiques. So for example, nga mitsu shishiro, this means I am putting a cat. And the subject of transitive verb is not marked, just nga. And the object is marked with wu, mitsu. However, such accusative marker can be dropped if the grammatical relation is clear from the context. But in this case, nga is not marked, and the object mitsu is marked with the accusative marker wu, and then shishiro, the verbal predicate, comes. In the structure of a noun phrase, the head noun can be modified both from before and from after. So there are pre-head modifiers and post-head modifiers. Pre-head modifiers include demonstratives, nouns, and nominalizations. Whereas post-head modifiers include adjectives in the replicated form and quantifiers. And this is an example of a noun phrase, me de kimura ncho loi, one vowel that his mother gave him. So the head noun is this one, ncho lo, a vowel. And mother gave me de kimura. This is nominalized with suffix m, and genitive is attached to this addonominal clause, or maybe this is similar to a so-called relative clause. And this is a verbal-based nominalization, and it modifies the head noun.  And in this case, this classifier means one. So this is one of the quantifiers. And this means one vowel in cho loi that his mother gave me de kimura. There are a number of sentence final particles for mood and modality, like many other East Asian languages have. For example, te is for hearsay, pa is for inferential, mo for conformative, re is for factual or alophoric, a or ra for double-h questions, me or me for polar questions, sa for admirative, and so on. So for example, when they say it is raining, the form with no sentence final particle is used, for example, mok atere. It is raining. This pattern is used if the speaker directly knows the fact. But if the speaker learns about it from someone else, for example, his friend said that it's raining and he now knows it's raining, then he says, mok atere de. The last te is the hearsay sentence final particle. And so this means it's raining, but implies that they say it's raining or I heard it's raining. OK, now let's talk about some linguistic topics. Here I'd like to focus on directional prefixes and related phenomena. First, please take a look at this example. This is a quote from the folklore. In the situation is like this, a rich man and uncle Tempa, a very famous wise man, went out to do business with a lot of grain. And the next night, they stayed at the temple. But the next morning, they found the grain disappeared. But actually, it was uncle Tempa's plan. OK, then the servants of the rich man went everywhere outside the temple to look for the grain. In this part, your plane will be to the chariot. The servants outside look for a go and go. In this part, the verb cho, which means go, takes the prefix do. OK, in the next part. But uncle Tempa went up into the temple and did something. This part, uncle Tempa knows everything. Genbe kebi ochare, temple inside of temple, he went. In this part, the verb cho, go, takes o, prefix o, different prefix than the last part. And then he went down to where the rich man was. Ho, ngoro akutemba, that akutemba. Gebudo achore, as a rich man's place, went. And here, cho, the verb stem, takes a, prefix a. So the verb takes different prefixes in accordance with the context or something like that. OK, these prefixes show the direction of movement. As now you know, they live in the steep mountains and deep valleys. And when they go upward, the prefix o is attached. And this prefix alternated to o in the previous example. Similarly, when they go downward, a is attached before the verb stem. And this vowel is not altered. And upstream or inward, go is used. And outward or downstream, ng is used. And t, prefix t, indicates indefinite or neutral direction. The next example is ngara-niu-niu-pan-japi-at-diare. And in this example, japi, here, denotes the japa region. And the verb takes the upward directional prefix. Since this sentence was uttered in the town of Stau, which is at a higher attitude than japa. Japa is the origin of the movement, upward movement. Japa is lower and Stau is upper. And the directional prefix suggests the direction of movement. It is worth noting that the noun phrase japi do not have a case marker. Of course, in japa, the nominative case marker is zero form. So the subject, gara-niu-niu-pan, do not have any case marker. But japi, the origin of movement, do not take any case marker. Actually, japa do not have proper case marker for the origin of movement or for form in English. But they have directional prefixes. So they know the direction of movement. And they know which of Stau or on japa is located upper position. So they know whether it is the origin or goal of the movement. So if the verb implies a movement, the directional prefixes indicate the direction of movement. So these verbs may take any of the directional prefixes to indicate the direction of movement. For example, basic movement verbs or run, flow, please, push or arrive. Then, what about verbs that can't seem to choose a direction? For example, to eat or to die. They also take one of the directional prefixes, but the connection is fixed. Most verbs are associated, lexically associated with only one of the directional prefixes. Such directional prefixes are obligatory in the perfective and imperative. For example, kotsu is eat the imperative. And this inward directional prefix is obligatory in this case, before the word eatzu. And for example, me dosunda asoare. The mother told the children what they should do later before she died. In this case, the verb she takes the neutral directional prefix and so order or told takes the downward and directional prefixes. These are fixed connections. So for example, eat cannot take, for example, downward the directional prefix. Or die cannot take, for example, upward the directional prefixes. It is fixed in this language. Some semantic shifts are found on the directional prefixes, especially on the outward directional prefix. We consider this was originally the outward directional prefix. For example, ngeuki, give birth or to be born, can take this prefix only. This is a lexically fixed connection. And this is also used for the downstream movement. So, for example, ngeoli means a gentle breeze blows from upstream to downstream, toward downstream. So the prefix nge is used. Since this verb stem, a breeze blows, li is one of the movement verbs. So it can choose any of the directional prefixes in accordance with the direction of movement or blowing. So if they say gali, it means a breeze blows from downstream to upstream. G is inward and upstream directional prefix. However, for a strong wind like a storm, only the outward directional prefix is used, ngechi, a strong wind blows. This verb cannot choose the directional prefix. So this is not directive, but this implies something drastic, drastic movement or drastic event. Nge is often found with such verbs, implies a drastic change or drastic event. Finally, I'd like to point out the area features. Having a set of directional prefixes is one of the area features shared by the languages of the Changi language area. In the Changi languages, a directive marker can fall into the preverbal slot of motion or orientational verbs according to the direction of motion. However, other features vary among languages. For example, drapa shows the feature that it is obligatory in perfective and imperative and semantic shift from outward to drastic. But these features are different in other languages. These are references and more references. Lastly, I'd like to thank the consultants who taught me the drapa language. Thank you all for listening to the end. Akka, thank you in drapa.