Hello people, I'm Ginny Metherill and I am a fourth generation witch. Today we're going to do my ever popular Almanac series looking at witchcraft in September and what witchcraft you can do on each day and why. So this video is coming out a little early and that's because I am currently on holiday. I'm not away on holiday, I'm just on holiday at home which means that I'm running my children around and being a taxi service and generally just, you know, I don't know. So I thought you could have this one a little bit early as a nice surprise because I won't be putting out one next week. So as always with these videos what I like to do is to give you a general overview of the trends and witchcraft that are happening throughout the month of September and then we'll look at the nitty gritty detail of the days and what witchcraft you can do and when and why. And with that said let's get into the witchcraft trends. So September is the start of things isn't it? There's a real new broom kind of feel to September.  People like to move jobs in September, they like to move houses in September. It is a if you want to start something new now is the time. There is definitely a real feel of new growth about September. Not the earth growth but personal growth. We are at the height of our powers literally in September. The harvest is in, everything is prepared for winter. We are good to go and so now we can concentrate on us. It's a great time to start new projects. The Anglo-Saxon name for September was Holy Month because it's considered a really good time to make offerings. So if you work with deities for example, it's a great time to set up a new altar and create that bond with that deity so that you can work with them. I love September, I love the Christmas of the cobwebs as they settle over the bushes and the morning in the mist. I love the blackberries ripening in the hedge. It is just such a glorious month with all the colour and the leaves are still on the trees but turning a beautiful orange. It's a wonderfully glorious month, is it not? September is also the month that resonates very strongly with water. There are a huge amounts of watery constellations in the sky. If you look to the south Pisces Ostremus, the southern fish, is swimming in a water stream poured by Aquarius, the water bearer. They are surrounded by Delfinas, the dolphin and that strange seagot capricorn, a pair of fishes in Pisces and Cetus, the sea monster. There is a lot of water energy flowing through September. This is great for you to use in your spells, so should you be aligned with the element water which gets into all the nooks and crannies and gently pushes its way through to find the answer or find the end result, now is the time to perfect those rituals. September is the time for hares. They first bounced into our life in March with their boxing matches and their mad marchways. However now, the young have grown and the fields are awash with hares. You might see a rare white hair but never harm it. The white hair was always considered to be the shape-shifting witches animal form. As I said earlier, September is a clean, sweep-style month and so you are going to go back to school, go back to university, start that new job but you might as well start it with a clean, crisp white shirt and a sharp pencil.  That is my general overview. Get your house in order and start that new job, that new school with as much plomb as you can. Now let's move on to the day-to-day witchcraft and what witchcraft you can do on which day and why. The first of September is the start of the meteorological autumn. We are officially in autumn, as if we didn't know it already. However it is also a great and traditional day for divination. So if you'd like to know a bit more about what the future holds for you, today is the day to go to that tarot card reader to look into your crystal ball and to work out what is coming for you in the near future. It is also a weather divination day. If it is fair today it will be set fair for the whole month of September. So look out for that because it will be nice to have a month of September being beautiful, wouldn't it? The next date we come to is the third of September. Now this is a rather tricky day. This is a day of marbles and wonders. Now these marbles and wonders can be good or they can be not so good. For example the Great Fire of London in 1666 which destroyed pretty much most of the town was at its peak in this time. And this is what I mean by it's a day for marbles and wonders. Great things can happen on this day but they might be terrible to behold. So look out for that. The 9th of September is the day when traditionally the harvest fairs would finish. And so if you came back from your harvest fair and saw that the countryside was awash with rowanberries, blackberries, the autumn fruits and nuts and apples, pears, damsons or whatever then you know we're in for a hard winter. And this is all about the earth helping its children get through those winter months with plenty of food. The 11th of September is the day this year when the horned men of Abbotsbury dance. Now this is a very strange traditional custom. This happens on the first Monday after the first Sunday after the 4th of September. So this year it falls on the 11th. Now nobody knows where this came from. The antlers that the men are using have been carbon dated back to the 9th century so they're really very old. And there's two sets of them some black ones and some white ones and I have no idea of the symbolism if you'd like to leave me a comment below. I would be very pleased to read about it. Nobody really knows what this dance has to do with. It's obviously some leftover pagan fertility rite or something. No one knows. There is speculation however it is a do with this legend of Herne the Hunter. Herne the Hunter was a glorious man strong tall fair handsome. He was beloved by Richard II that wicked king of England as he is known and he was the favored huntsman of him. The other huntsmen were incredibly jealous as a result so one day they called in the services of a magician to cast a spell on him. And so from that time the poor Herne found that he was lagging behind the hunt. He was not carrying out his huntsman duties as well as normal. He couldn't keep up and so Richard II dismissed him from service and Herne in shame and embarrassment hung himself from an oak tree. After that time there were rumors of a rather fearsome woodland sprite that appeared to the varying other huntsmen of Richard II who'd called in the magician and they were terrifying. He would grab them and force them to run with him through the night exhausted and then the next morning they had to get up and still work for their king. This went on for several weeks until one by one the huntsmen started to drop eventually these huntsmen confessed their crimes to Richard II who promptly had them executed for consulting with magicians you weren't allowed to in those days were you. The tree where the Herne huntsman hung himself from is now known as the Herne oak and not original tree but its descendant still stands there today and it has a very very eerie feel to it so should you wish to go and play around with some woodland sprites try the Herne oak. The 14th of September is Devil's nutting day and this is a rather saucy day it is when the folk went out to gather the nuts from the hazelnut tree however when you send young folk out to gather nuts you know they follow their instincts and babies tend to arrive nine months later. This is a baby making day however you still should watch out because the devil is around and collecting souls on this day. Should you find a hazelnut tree with the nuts on it don't pick the unripe ones because this is incredibly unlucky but you do want to pick the double ones that look like heart because this will bring prosperity to you. Hazelnut trees are awash with tradition their branches are used in divining rods and they make a wonderful wand always though ask the tree first. The 15th of September is the time of the new moon which rises in Virgo. Astrologers believe that new moons have new moon energy and depend on the sign that they are in so you can make plans for the coming month that line well with the star sign the new moon is in. Virgo is all about routine organization and health and so should you wish to have a new eating regime go on that diet start that gym membership. This is the day to do so. The 15th of September is also the last day that Mercury stops being retrograde so Mercury has been retrograde since the 23rd of August and 15th it returns to its normal position whatever that may be I'm no astrologist so I can't really help. Mercury retrograde means that tempest have been fraying communications have broken down tech fails as always it does doesn't it and plans go awry so hopefully 15th of September we'll see this set right. The 23rd of September is the Equinox otherwise known as that great feast of Mabon this is when day and night are equal and there is an awful lot of witchcraft that we can do on this day however I'm not going to go into that here because I will obviously have my own Mabon video coming out in the next couple of weeks so have a look for that which will tell you what witchcraft traditions you should follow on this day. I will say though that this is also the day where the sun moves into Libra those who are born on this day under that Librian sun will be known as great travellers so if this today is your birthday and it happened to be the Equinox when you were born have you been a great traveller? Let me know in the comments below I would love to hear. The 29th of September is the night of the full moon and this is the last supermoon of the year. Full moons have full moon energy and especially this one which is going to be the biggest and brightest looking in the sky. This moon is a great moon within which to charge your witchcraft tools with. If you've got loads of crystals just you can just leave them on a window sill at night but things like Salonite love this moonlight to help them renew their magical energy. This moon of course is the harvest moon it's the first full moon after the Equinox. It is a great moon to give thanks and to help with your Mabon altar so that is what I would do or make moon water. Making moon water on a full moon brings all that full moon energy into it and you will find the moon water to be particularly potent in your spells and rituals. Today is also known as Mikkelmus. Mikkelmus is after Saint Michael who is the Christian sun god really. He has that flaming sword and kicked the devil out of heaven or earth. I can't remember I'm not great with the Christian mythology. Now in my opinion the Christians actually just took over Saint Michael because he was a very very pagan god. Michael was known long before the Christians got hold of him if you know what I mean. This is also crack nut day it's the last day when your teams of nutting teenagers would go out into the woods and get up to all sorts of shenanigans and it is also the last day that you can pick blackberries because the devil will spit on them after this day. When Saint Michael kicked the devil out of wherever he kicked him out of, oh heaven I think, the devil fell to earth and landed on a blackberry bush and he was so cross that he decided to spit on all the blackberries on this day and said therefore this is the last day that you can pick them and they will still be fresh and ripe. It is tradition to eat roast goose on this day and if you eat roast goose on the 29th of September you will not want for money for the rest of the year. So that's nice isn't it? Have some roast goose and you'll be able to pay for Christmas. So that my witchlings is the traditional almanac for this month of September. Let me know in the comments what tradition you like. I would love to hear. If you're missing Ginny do go to patreon.com forward slash Ginny Metherill and join my coven meeting. I promise you you'll learn so much. The next meeting will be coming up around Mabon so you could celebrate Mabon by joining my coven. Otherwise don't forget to like and subscribe because it really helps my channel and if you don't subscribe I don't get to keep making these videos especially for you. I will see you in a week or so whenever I get back from holiday.


I guess we can hear me. Welcome to the testing outside the box track. I don't know where Sarah is. So I'm just going to get started and hope that's OK. So you might recognize this image. This is actually one of four versions of Edvard Munch's The Scream. It's known as one of the greatest depictions of existential angst, really, out there in art, certainly in modern art, from about 100 years ago. And it probably describes pretty well how most of us feel about documentation. Because literally, everyone hates documentation.   And the truth is, it's not even just coming from your average everyday developer. It's coming from titans of industry. It's coming from Ken Beck. This is an interview I heard or rather read not too long ago, where he described something that we see all the time. Projects start with these ambitious ideals for we're going to do it right. And then real life hits, business hits, and it just doesn't happen. And he said, let's learn from the experiences that we have as we do our jobs. And let's use that to iterate. So maybe people just don't maintain detailed documentation because it isn't actually a good idea.  And I think that's probably sort of the feeling that most of us have about documentation, is it just hurts so much. It hurts to create, to maintain. And the truth is, it's not just Ken Beck. It's also all of the other signatories on the Agile manifesto who explicitly wrote as one of the four guiding principles. We want working software over comprehensive documentation. They set up a dialectical tension between the two. You can have your working software. You can have your comprehensive documentation. But you can't have both. No way. Well, I'm apparently very, very greedy. I want to have both. I want to have working software. I want to have comprehensive documentation. I don't think it's unrealistic, despite the collective wisdom of whoever was there at Snowboard in 2001 when they wrote that manifesto. And I think there are three reasons why I'm not crazy. I don't think it's crazy to say, why don't we have both? And maybe people will celebrate you, too, if you want both in the right way. Number one is, I don't think that the kind of documentation that these sources are talking about is the same kind of documentation that we're going to talk about today. Today I'm talking mainly about API documentation, specifically JSON APIs. The ideas are applicable to a lot of other kinds of tools, but we are going to mainly focus on APIs. So just throwing that out there. So yeah, what we're talking about is usage documentation.  If they don't have that, they basically don't have working software because they can't use it. I think the kind of documentation that's discouraged by these titans of industry is more about the implementation stuff. It's the UML diagrams. It's the big upfront design. It's the things that you're kind of building the system twice, once in theory and once in practice. And they said, let's cut out that waste. Let's just build the system once. But the thing that you're giving your users is critical because without it, they don't have anything. But that's my own thoughts. You don't have to listen to me. You can go to the agile doctor. I don't know who this is. Someone who goes by the moniker agile doctor and registered the domain agile-doctor.com said that it would have been better if they had written in the agile manifesto not working software over comprehensive documentation but working software over comprehensive requirements and design documentation. That's the thing that everyone was railing against. So the same way that code comments have gone by the wayside for the most part in favor of self-documenting code, upfront design has been replaced with just-in-time design. So we've gotten rid of that kind of documentation. But that's not what we're going to talk about today. Even if you don't buy what I just said, it's not the same kind of burden or at least doesn't have to be when you think about it as rather than this wall that stands in your way, an extra box to check every time you launch a new feature or change anything. What if it was the tool? What if it's not a brick wall you run into but something a vehicle that helps you move forward faster and to get to a better place? That's the kind of workflow I'm going to describe today. And the last thing is if you're here at this talk, even if you don't buy anything I set up until now, you probably need documentation anyway. So hopefully you'll join me for the ride and we'll talk about how you can have a better experience with your docs. So if we're going to figure out this problem, we're going to solve it. We have to start by understanding it and we have to ask the question, why? Why is it so difficult to produce accurate documentation? And I'm going to go through sort of a few different ideas that I've heard over the years. Things that people say to try to explain why documentation isn't as good as it could be on their projects and we'll just look at them one by one and see what we can come up with. So the first thing of course that we turn to is human error. Human error by the way is never the problem, by which I mean it's always the problem but it's not a solvable problem because we will always be humans and so we will always make errors. So if you blame a problem on human error, you can't solve it. We have to blame it on something that we actually can solve. We will always be forgetful. And when we take this approach of like, let's just get better, we're going to decide to do it, it works about as well as the average New Year's resolution.  Okay, like a couple. Raise your hand if you've not gone through with a New Year's resolution. Right, so a whole lot more hands. That's about how well this works. Okay, let's find something else where we can actually start solving the problem. Our API is changing all the time. We're always adding new things, taking away things, changing what's there. How do we keep up? It's a whole lot of churn. And this really starts to get at some of the issue but it has this uncomfortable thing for me where we're again pitting the idea of change in your API against documentation. Either your API remains the same forever or your documentation is gonna be bad. I'd like to have both again. But we're gonna have to figure out a way to have documentation not be something that blocks change but instead is either a neutral or ideally a positive force towards helping us make the changes we need to make in our APIs. This is more of a psychological concern. Updating documentation is very mechanical. It's very straightforward. There's sort of a clear right answer and wrong answer. And that's annoying. We're creative people. We like to think when we do our work and we sort of like turn off our brains when we open up the documentation file to make changes. Ideally, if we wanna have documentation that's gonna work for us, we need to go the opposite and say how can we look for ways where documentation can be actually a creative process? Here's the thing I hear sometimes not so much from developers but from maybe management, maybe in talks or blog posts, things like that in the community. Rather than blaming a human error, we blame human malice. You just don't care about your users and if you cared about them obviously you would write fantastic documentation. I just don't think it's true. I think it's really hard to write accurate documentation and it's not helpful and it's not correct to blame developers for the problem. I think what's probably at the root of it is complexity. We build extremely complex systems. There's a lot of moving pieces. Since the 1950s, the generally accepted number for how many things we can keep in our heads at once is seven plus or minus two. So try to find a single endpoint in your API that has less than that number of moving parts. You probably won't find one. You have all the various little details of all the inputs that you're doing. Of course there's the request method and there's the path and all the things that could be in the path and the query params and of course there's all the different little bits of the response. Of course you're gonna make mistakes. We can't deal with complex systems and we have to just stop trying to do that. The thing that's not gonna work is guilt. I'm just kind of tired of hearing a lot of sources in the community trying to guilt developers into better documentation. Let's stop talking about the problem and start talking about solutions and the way we're actually gonna solve this realistically is we make it easier. We create the tools that will allow people to produce better documentation. So I'm gonna talk about a system today that will actually help us to do that. And when we're thinking about what would that system even look like? The guiding principle has to be let's not have to hold so much in our heads because the more we hold in our heads the worse it's gonna end up being. So if we take that idea and push it to its limit what's the minimum amount that we might have to remember is zero. What if we didn't actually have to remember anything when we were writing our documentation? Well it turns out there's this one weird trick other developers hate him. You don't need to remember anything if you just write your documentation first. Now I realize that I'm sort of playing a little bit of a game here because you're right. Fine so I don't need to remember anything when I'm writing my documentation but now I have to remember my documentation when I'm writing my code and that's true. But think about how flipping the script changes the question because now we're not talking about how to fix documentation anymore. We're talking about how to fix code. And that's important for two reasons. One is that that's how our users think of our software frankly. They read our documentation. That's apparently what the software is. If a software doesn't do that then the software is broken. The second reason is that we're software developers. We have tools that we've developed over the years to help us write accurate code and identify regressions when they pop up. This particular community has pushed this particular tool ahead in the number of years kind of raised that flag. It's the name of this track. Of course I'm talking about testing. So if we have a test that fails until the code matches the documentation we can actually write perfect documentation. So what we're gonna go through in the rest of this talk is the idea of documentation driven development. And this is a term you'll hear out there on the internet. Pretty much everyone is lying to you about it because when they talk about documentation driven development what they really mean is documentation first development. And that's good as we've mentioned. That's valuable. It helps you think more like your users. But it's not actually having your documentation drive your development. So it doesn't meet the literal definition of the term. And of course it's also not as useful. So we're gonna talk about what happens when you create and when you update your code. We're not gonna talk about deleting because that's a little bit more intuitive. So you can probably figure that out on your own. So for a new endpoint here's the process that you follow. The first thing that you're gonna do is document the endpoint. As soon as you document that endpoint you need to have something that's driving you from there all the way to completion of your code.  So once you have that failing test you're like okay great. So now I have to write a test that's actually going to test that particular endpoint. And as with any kind of blank driven development write just enough code to make the test pass. Now that's just one line but that includes your entire current development process. So whether you're doing inside out, outside in whatever approach you're using to write your code that's all in that one line. But everything is driven by that initial failing test and you know that your coding is not complete as long as that test that you've written for that endpoint is failing. Similar for a change to an endpoint. So first you update the documentation. Immediately there's one or more tests that fail because of the change because things are no longer in sync and you write just enough code to make the test pass. Okay so that's the flow that we're gonna go through. I just wanna contrast it with what most of us do which I would describe as user driven documentation updates. So here's how it works and probably you're all doing this so you recognize it. For a new endpoint implement it, document it. I mean you'll probably document it you might forget but probably and then a user files a bug report and says hey your API is broken. So you say okay great I guess we have to update the docs. It's a similar process to change an endpoint. So you update the endpoint because it's an update so you're not in that same mentality you'll probably forget to update the documentation or you might not even notice that something changed externally. And then again a user will say hey your API is broken and you'll go ahead and update your docs. So we don't like that. That causes a lot of pain. There's a lot of bad feelings throughout that whole process and ideally we'd like to escape it and come to a place that's a lot more healthy both for us as developers and for the users of our APIs. Before we actually talk about documentation driven development I should probably say hi introduce myself because I haven't done that yet. So hi everybody. My name is Ariel. I am AM Kaplan on Twitter and GitHub. That's pretty much everywhere that matters on the internet these days. I'm am Kaplan.Ninja that's my site. I actually have a really long blog post. We're gonna go through kind of high level details about these tools today but if you wanna see a whole lot more information some gotchas and some pro tips check out my site. I have a very long blog post on the topic that'll help you out there. It's also probably easier to share that with your coworkers than to initially give them a 40 minute talk to sit through because they probably won't. I work at vitals so this whole row of people here pretty much almost the whole row is my coworkers there. We work in the healthcare space creating transparency around healthcare data so we empower healthcare consumers i.e. all of you to make better decisions about your healthcare through information on the cost and quality of your healthcare providers. So if that sounds cool or you like the content of this talk and the other two talks one on accessibility by Liz and then Gretchen right here gave a talk about our high school interns program so if you thought that sounded cool and you might wanna work with us let me know. I am deemable. That also applies to you over there on the watching on conference later on. I run this thing called Dead Empathy Book Club which you may have heard of or you may have seen I kinda littered the whole place with stickers. Essentially the idea is to give people something concrete to do about developing soft skills as they relate to a software development environment. And in general just to kinda be better people. So we do one book every two months or so. We have panel discussion, we have an open Slack channel, we have dedicated Slack chats once a month. You can check it out on devempathybook.club. I would love to see you all there. Okay one last thing I don't like addressing hate on Ruby generally and this is probably the last time I'll ever do that in a talk but also the first time but I kinda feel compelled to. So there's this blog by someone who writes PHP and I guess is a murderer I wanna say killer PHP called Why I Don't Believe in Ruby and You Shouldn't Either. And there was this line that I found to be just particularly delightful in a sort of ironic way. He says the only thing holding Ruby together was the hipster coder community of 20-something year old nerds who are now 30-something nerds. Well for the next few months and this is the last RailsConf where I can say this, I'm still a 20-something nerd. So all kidding aside, this is an incredibly diverse community certainly in comparison to tech as a whole. I've worked on a team where people have less years of development experience and I have fingers on hand and people who have been coding since the age of punch cards and everyone's writing Ruby and it's kind of representative of the community as a whole and in many, across many axes and it's really something special to be part of this community and just ignore the hate which I failed to do today. So let's get down to business. How do we get started with documentation driven development? And of course as with every instruction manual I'm gonna start with step two. Well you probably think of this as step one but you'll see why I have a step one later. Step two is to create documentation that computers can read. It should also be documentation that human beings can read but the thing here I'm trying to make clear is that it has to really be for both. There are many tools to do this. There are multiple tools to do the things I'm gonna advocate for today. So I'm just giving you enough information about one set of tools to be dangerous but you can go out and examine the market and choose for yourself. So Swagger or as it's now been rebranded OpenAPI but people still call it Swagger so I'm just gonna call it Swagger is a specification for writing JSON specifications for JSON APIs.  You actually write it as YAML generally just easier to edit and to read but it describes the structure of your APIs has a lot of places to insert things to explain to other human beings what any endpoint is doing and then you get beautiful documentation that looks kind of like this. This is a Swagger Pet Store you can see it at petstore.swagger.io I believe and kind of get a sense of what Swagger documentation looks like. So yeah, I'm gonna give you just enough information about what Swagger docs look like in order to understand the documentation testing part of it but this is definitely not gonna be a full walkthrough we could be talking until next Rails Conf and still not be done. That is a huge specification. So just enough Swagger a little bit to understand the overall idea of how Swagger thinks of your APIs. So Swagger thinks of your APIs as on the top level you have all your routes. You can see that slash ID in curly braces that's kind of like a colon ID in Rails it just means a dynamic segment in your URL. So you have all your routes on the top level beneath that you have all the various HTTP request methods you might send to a route so you can think of it as like you have your collection and your individual and then what do you do with regard to each collection endpoint or collection route and each individual route and then there's all the response codes that each one could output. So that's kind of how things are organized from the top down. Let's take just one example and just for a little bit of context I guess the example we're gonna use here you can see it's about packages I don't mean software packages I'm thinking of like physical packages that you might send in the mail something like that. Okay so when you post a new package you're trying to create a new package and we have to tell the user okay when you're gonna do that what information do I need to submit what's the input to the API so that it knows exactly what to do. Then if the request succeeds I get a 201 back now I have to know what is the API going to tell me when the request succeeds and finally if it fails and there could be a number of failures in this case we're always gonna use endpoints with just one failure but there could be a whole bunch what will the API tell me so I know how to move forward. All right so here's how that looks in code. This is what a parameters object looks like hopefully it's visible on both of the monitors and it was a little bit cut off before. So in this case we just have one single parameter in the body it looks kind of like this so you can see that it's as required true because this is going to be a required parameter you can't submit a package without actually saying what it is. There's a human readable description package to insert into the system and then schema is where we actually say in the case of a JSON object what it's gonna contain but we haven't actually said what it is because we have this ref thing here and what ref does is basically it says look somewhere else in the documentation in this case in the definition section we have a package model that's gonna say what the package actually looks like so again on the bottom you can see in JSON what it looks like it has a destination ID length, width, height and weight. So somewhere else in our docs it's referenced by that ref we have our package model so we have to list the required attributes and you'll note that weight is not required so it's not like you just require all of them you require only the things that are actually required and then we have our various properties and the properties will have a name and then what's the type, what is the format and what's the description so type and format are more for computers but also for you to read and understand so destination ID which is the canonical ID of the package destination has to be an integer in the format of a 64 bit int length, width and height and weight I guess are all in this case numbers and they're all floats so pretty straightforward matches the stuff we have on the left the last thing we need is to explain the responses what are the possible outputs of the API so in the 201 status case the package was successfully created again we'll just get a package model back in the case of an invalid package it's a 422 and we have an error model to find somewhere else that will tell you like what to expect in the case of an error again trying to minimize how much code I'm gonna throw up here so again our three questions what do I put into the API, that's our parameters what happens if it goes well, that's our 201 response and then if it goes badly we have our 422 response defined over there so let's just kind of crush this up a little bit and we're gonna nest it under the route and the request method so on the top level we have our route slash packages below that we have post which is the request method and then a little bit of general information about that and then again we have our parameters and our responses so exactly matching the format that we described earlier this is the Swagger editor so I literally just copied and pasted the stuff that I wrote on these slides right into here and you can see how on the right it immediately reflects that this is editor.swagger.io if you're interested to try it out and it immediately generates documentation that you would see in Swagger UI so in this case we just have one endpoint if we open up that green line on the right that post to slash packages we'll see something like this so right on top there's a really cool button there to try it out where essentially you just kind of fill in the parameters it gives you a skeleton to start with and you can actually play around with it in your browser which is really nice as someone developing against an API like that then you have your parameters and their descriptions it fills in a bunch of zeros you can give Swagger a more realistic example to use if you so choose and it's probably a good idea and then on the right side you see the responses so you have your 201 on top with a sample response what it might look like and then on the bottom you have your 422 with an error string of course there's also another section on the bottom of the documentation called the models it's actually also inline there are ways to look at it while you're still in the individual requests so we see our package model with all the information that we wrote about it it's the destination ID that's a 64 bit integer all the floating point numbers et cetera and of course their text descriptions and one cool thing is in a lot of these places where there's free text you can actually write it in markdown and it'll just throw it up you know probably formatted on the screen so that's Swagger just again enough to be dangerous probably not enough to actually start using it immediately but you know there's plenty of documentation out there about Swagger which is a little meta documentation about documentation anyway go check it out so step three once we've set up our documentation our computer readable documentation in step two is to test it and for that the tool I've chosen to use is Appavor it's a cute name it's based on there is an actual word Appavor it means a creature that eats bees so kind of like herbivore eats plants carnivore eats meat Appavor eats bees but I think it's I don't know if it's maybe it's pronounced API for because the idea is it eats APIs that digests them and understands them so it's pretty neat here's how you set it up it's pretty straightforward we include the Appavor gem you know bundle install gem Appavor in your gem file all the usual details that's going to give you this Appavor Swagger Checker class you have to tell it how to find your documentation which means that you will need to set up an endpoint in your API that's serving up the documentation in JSON format you will write one test to assert that all endpoint statuses are tested which of course they're not which is kind of the point that's going to catch all the things that are not tested yet and then for every endpoint status combination you write a test so like any RSpec test you set up context and then you tell your Swagger Checker what request you're going to make what params to submit and what status code to expect so we're going to go through all this in code I just wanted to give you the overview of what we're doing right now so here's the initial boilerplate I'm just going to point to a few things so on top again we're telling Swagger Checker where is documentation available so that I can read it and parse it and figure out what the API is supposed to look like we have that one test expect subject to validate all paths that basically says okay let's run all the other specs and then once I do that one sorry once I've done all that I'm going to run this one and assert that I've now tested everything which again you can see from the common test go here has not happened yet and that's fine in order for this to work you have to use order defined which is RSpec's way of saying run these tests in order you can of course randomize the order of all your other tests but you have to make sure that that one test that's kind of the spec of specs is going last so if you put that into the API we just created with that documentation we'll see immediately we have a task list so that's really useful for backfilling API because it'll tell you oh you have a request a post request to slash packages you have to test both the 201 and the 4.20 response codes and you can just kind of work your way down the list writing tests as you go so let's actually do that let's do the happy path test first the 201 so we're going to set up valid params Appavor has this underscore data kind of magic param there's a few of those for headers for query params different ways of passing different things so you fill in just a reasonable set of parameters and then you use RSpec's implicit subject so when I say it is expected to validate that's the same as expect subject to validate but you don't then have to write any kind of string so it just kind of lets you write a really, really condensed test so it's going to validate a post request to the slash packages route expect a 201 back and here's the prams you're going to use to generate that 201 and we of course are implicitly asserting that the stuff that we get back matches our documentation so we have one green which means that we apparently at least implemented it correctly and we only have one test left to right so let's do that failure path test all we're going to do is flip the length to a negative number and we assert that now when we make that request to post to slash packages we get a 4.22 back and again use these prams and we assume that it matches the docs apparently we did a good job because everything went green when you actually do this you will not get to green nearly this quickly because you will probably have a whole bunch of mistakes in your documentation that's the point of the test is to catch all those mistakes okay so let's talk about now creating a new endpoint again our creates and our updates are the two major things we're going to talk about so in this case we're now allowing you to update a package that already exists so a request to slash packages slash in curly braces dynamic segment ID we're going to make a patch request we have the summary information on top we have our parameters which again is going to be in this case it's actually a package update model you see why in one sec and then we have our two response codes in this case it'll be a 200 and a 4.22 our package update model you'll notice is the same as our package model except for one thing which is that there's no required line on top because when you're doing an update like you don't have to update any particular property you can update whichever thing you want so that kind of makes sense and you can dry up a whole lot of this using yaml yaml has that thing with the ampersands that you can just kind of dry all this up and only write it once so if you're worrying that you're going to have to write a whole lot of code that's actually not true it's not a big deal so immediately when we write this our test suite is going to complain wait a minute we have these two patch requests a successful and an unsuccessful patch request that have not been tested so again documentation is driving us into the development now now we first have to write some documentation tests so we set up a package in our database we create a package with valid params and now we have that accessible to us in our tests we're going to use that packages ID so anything that's a top level param in app of or refers to something that you're going to put right into the path so when you give it ID it's gonna say oh there's this ID and curly braces in your path so we're just gonna substitute that in but of course then it knows that I look for packages slash ID and curly braces within the documentation in order to match things up so we got our 200 on top that's gonna be again updating length in both cases but in one case it's a valid length 8.3 so we're gonna expect a 200 and on the bottom we're doing a negative length which doesn't make any sense to have a package with a negative length so we expect a 422 and now you actually start your normal development workflow I can't tell you what that looks like so you're gonna have some kind of failure that's gonna be driving you through it could be that there's no route for this it could be that there's no controller action for this depending on what you've implemented so far you're gonna have some kind of error and rather than teaching you all how to build a RailsF I've decided to just kind of fast forward that and jump to the green so eventually once you finish your whole development workflow you will get back to green and that's how you know that you're ready to do something else how about an update so we have our package modeled from before everything is the same we're gonna just add one field volume length times width times height we decided to calculate that on the back end and so there is now volume being returned from the API and we're gonna just add that to our required list up top so now we're expecting that every single endpoint that's returning a package is gonna have this extra volume property as soon as you do this you run your test suite and you get a whole bunch of failures that look like this anything that uses the package model now expected something else so in this case you can see it says the error is that it did not contain a required property of volume as you're reading this you might note that we have timestamps there which is something that we didn't even document we didn't even think about and that's gonna happen a lot when you run these tests you'll just notice like oh there's parts of this API I didn't think about should they be there should they not be there okay so that's pretty much the workflow of documentation-driven development with these tools there's a couple caveats about the tools specifically with Apivore show you this slide for a while I don't know how many of you noticed hasn't been updated in like a little over a year which for me as a daily user of this is pretty frustrating actually it's still on swagger version two swagger is now on version three another thing I want to focus on it says that you can test your query parameters so you can test the inputs to your API just kidding you can't I submitted a GitHub issue like a while back for them to just like take that out of the description if they're not gonna do it hasn't happened so I don't know what the deal is but bottom line it's not that well maintained it's not a perfect tool but it's still a massive improvement and that's what I want to convince you over the next couple of minutes that remain okay which brings me to step one finally convincing your manager or whoever decides how you use your time hopefully you have some autonomy over that but whoever is making those decisions convincing your manager or convincing yourself that you need documentation testing so I like to travel back in time and talk about how my team and I got started on using swagger and Apivore so back in October of 2015 like I said we're in the healthcare space my team maintains a system that deals with patient ratings and reviews of doctors and facilities so it's PRS for short patient review system it was rewritten very quickly from PHP and Laravel over to Ruby and Rails I wasn't part of this I joined the team in May of 2016 so I kind of inherited a lot of the confusion that kind of was already there a month later we were getting close to launching with our first client so we decided to use swagger we had to give them some kind of documentation swagger looked cool so we decided to use it took us about a week to get that set up in July we decided yeah let's do this documentation testing thing let's try it out so I started writing these Apivore documentation tests and instead of one week it took until August 18th to finish writing those tests and remember how I showed you that there was like these tiny little very simple tests so like what took so long well so just to be clear again this was 29 days it was 18 pull requests it was actually a whole lot of work but the stat I think is really important is this so we added 1800 lines of code which is again way too many to kind of ring some bells ring some alarm bells in your head and we deleted 2700 lines of code through the process of documentation testing so based on the workflow I showed like that that doesn't make a whole lot of sense like what took so long what was going on that whole time the answer is we were fixing a lot of broken things documentation test documentation mistakes that's what you'd expect doc testing to come up with and we came up with a lot of those but that actually turned out to be not the biggest use of our time we had an API that was stuff with a whole bunch of things that it didn't really need so like I mentioned before on that slide we have timestamps there should we even have those let's get rid of those if they're not necessary there are some models that never change why return useless information a timestamp that will never change we had status codes that were just not the way that status codes are supposed to work so a create action should always be a 201 we were returning 200 in some cases if we tried to send a delete request to a non-existent resource it would 404 according to everything that I found on the internet it should be either a 200 or a 410 depends who you ask but for sure not a 404 we had routes that were just over complicated and this sort of came about because we had again it's a system for rating doctors so you have doctors, doctor ID, reviews ID well what if that review ID is a valid ID but it's not for that doctor what kind of status should that return and the answer was why don't we just make the route more shallow reviews ID that way we don't have to answer that question so that helped us get rid of a certain amount of code we were a little bit inconsistent so when you write a review you're submitting a whole bunch of answers to the API but then we had a whole set of routes for just editing individual answers so are answers like attributes of a review or are they their own independent model we were being inconsistent about it and we said let's just get rid of all those answer things you can only delete it as sorry you can only edit an answer as part of a review we were mixing database concerns into the external domain model so we have this idea of you can flag review you can like it, you can dislike it we happen to implement it under the hood as a single concept in the database but why should the user have to deal with that the user thinks of them as three distinct actions they should be three distinct sets of endpoints so we split them out this is where it starts to get a little bit nasty so you were able to review a nothing you didn't have to submit an ID of a thing that you're reviewing what do you do with that even what does that even mean we started requiring that field I don't even know how that happened honestly we had this little problem where we're a multi-tenant system and if you requested information you could kind of get it for all the other clients whichever client like any review ID basically was available to you that was pretty bad so we started properly scoping our permissions because some things were returning a 200 instead of a 404 there was an active model validation that was just not working you have to answer a certain set of questions in order just to submit a review except that the validation was failing and so when I tried submitting without those required answers it was not a 201 sorry it was not a 422 it was a 201 that wasn't right so we fixed that and finally there was some system level data that was accessible to all users but should definitely not be able to be edited by just any user who feels like it that was happening too so we got rid of that so that was a whole other set of endpoints that we were able to delete so that's a lot of where that negative code came from so if you have to convince your manager like hey I wanna do documentation testing because it's cool that's not gonna work if you say hey here's a bunch of things that I could save you from like client data exposure and insufficient limits on permissions that might actually get a response of that sounds great let's do it and I wanna emphasize this wasn't a team of developers who didn't know what we were doing this is actually some pretty senior people who just made embarrassing mistakes because embarrassing mistakes happen and it was actually really good code it was well organized it was solid and dry and all the acronyms you could think of it was quite pleasant to work with there was really good test coverage but we didn't always think about it from a design perspective because we weren't thinking about it from the outside and when we started doing documentation testing that forced us to start thinking about the API as a documentation user otherwise known as a user what's cool now is that as we move forward when we're designing new things we start by defining the impact on the users so the takeaway that I hope you can all go home with is you can build a beautiful castle with just marvelous wonderful things in all the rooms but it's not worth anything if you don't give people the key because they're just flying blind I love this quote by Zach Zupala from the perspective of a user if a feature is not documented then it doesn't exist and if a feature is documented incorrectly then it's broken not the documentation is broken but the feature itself is broken the reason that this is the case is because users just see the documentation that is their primary source of truth they have nothing else to go by it is their guide to making sense of your API so rather than trying to fight it rather than being annoyed by oh we have to update the users and do a documentation and whatever let's embrace that let's start developing our APIs like we're users let's start seeing our documentation the way our users see it as basically that is our product and the entire code base from top to bottom is just an implementation detail and maybe, just maybe we'll build APIs that are easier to work with that are better for us in terms of again working with and in terms of developing documentation and we won't have all the frustration that we've gotten so used to thanks


I'm actually going to touch on a few Paz things as well as Saz things. Anyone who's not doing any Paz or Saz may find a lot of the stuff. Hopefully it'll at least be quirky, if anything. So what I'm going to do is I'm going to present and I'm just going to jump into it. So it is going to jump from thing to thing. I've got half an hour to present. I might end up using that up a bit early and then have some questions. Let's have a look at it. So I'm not going to do background. I'm just going to jump into it. If you do have questions, please ask those questions into the chat. I'll try and read that as I go along. So okay, first thing is this presentation mode is not going to work. So I'm going to jump around. So key places I want to tell you about with GovCMS. And a lot of this stuff is like new people who come on. Where do I go? What do I do? The key places that I think for GovCMS for a new project. GitLab is at projects.govcms. Lagoon is dashboard.govcms. And freshdesk is govcms.support. So that's the help desk. But in addition to those places, there's also all the repositories on github.com. And then there's a couple of the URLs that I'm going to drop these here because if you might in two months time think, there's logs somewhere and you might go back to the presentation and look at some of these links throughout the thing. So even though I wouldn't recommend anyone going to Kibana because you really need to know how to use it to make anything of it. I'm going to leave some links here in my presentation. So your key places if you find yourself on GovCMS. So where are the best docs for GovCMS? I personally think, having had a hand in this, that the best docs for GovCMS are this URL. So what is this URL? This URL is actually a wiki for one of the GovCMS repositories. So this is the original GovCMS repository. It's now the GovCMS 7 distribution as opposed to the GovCMS 8 distribution. But it happens to be where wiki documentation is kept for Drupal 7 and Drupal 8 versions of GovCMS. The wiki actually breaks it down into a few things. It's a good place to start in that it has... The distribution is in Chapter 2 essentially. Some generalized things around developing are in Chapter 1. And then there's also things like finding resources page that tries to be like a who's who of links to all the different things in GovCMS. Because GovCMS does have a lot of repositories, there's a lot of resources that you might want to access. Just make sure that I'm not screwing up and I'm just going to check my... See if anyone's left me any comments. No, I think everyone's happy, it seems. So that would be the main place that I would recommend anyone who's starting with GovCMS to go and to scan through all these pages and see. There's some really good... For example, in terms of Google-able stuff, you might find that this troubleshooting thing is just a hodgepodge of lots of different things that might happen to you on GovCMS. So this is where I go, where I get a weird docker things, because they're like, I need to maybe log into the docker thing on GitLab again because it might give you weird messages. So I'll often come back here and Google for things or search through these documents to see if I've done something silly. But there's a couple other places to be considered. There's the GovCMS training and the problem with that is it's stale. So it's like, if you wanted someone to train someone in GovCMS on web forms or something like that, there's not really anything in there. So hopefully that's something... It's in a Git repository, so hopefully that's going to come along at some point. Because there are some downsides to this Wiki as well, like I've noticed having been involved in them. The GitHub for Wikis isn't ideal, so it would be really nice to see that as the central place at some point. At the moment it's just got two training documents. Then there's Fresh Desk, which is great if you're on Fresh Desk. It's got a lot of duplication because it's like a world garden, so there's a lot of duplication between things in the Wiki and things on Fresh Desk. Then there are some other Wikis that are mostly being consolidated into that Wiki that I just showed you. That's a big thing you'll notice when you're talking to people about GovCMS is like the documentation. It's very difficult to negotiate, so hopefully that's just a really quick intro to the documentation for you. Connecting to other people. The places to go, I would recommend for anyone who's starting would be the GovCMS Slack. So if you are looking for access to that, someone can invite you, so you can always jump in the Drupal Slack and ask someone about that. Then there's community.gov.cms.gov.au. I'm not sure offhand. I think that's a self-sign up, but I would say that they're the two best kind of developer-y things, places to go with the GovCMS Slack probably being the best resource. There's lots of chatter about GovCMS, but there's also a couple of other places that I would recommend for different reasons. If you really can't be bothered joining a million Slack, you can just come into GovCMS in the Drupal Slack. There's a few people in there. There's also GovTeams, and if you've got a client who's only in GovTeams, or you want to interact with some of the GovCMS people, there's a GovCMS team, but that's like a really fringe thing. You're only going to be in there if there's a reason, and someone adds you from the government, essentially. But I would say that they're the main two places to connect as far as GovCMS goes. This is where I'm going to just jump into a whole bunch of different things. I might even come back to this one. I don't like the order of it. I want to introduce you really briefly to the GovCMS Dashboard because I want to do one of the questions that comes up when I'm working with people who are new to GovCMS. What happened to my build? Did my build run? I have no idea if it failed or if it succeeded. I'm going to give you a really quick example of what a build looks like in GovCMS. You'll have been given access to this dashboard, which is the Lagoon interface. You're going to go to a project and the branch and the project and deployments and then you're going to scroll to the bottom. I'm just going to show you what a deployment looks like in GovCMS because it looks like it's useless in that there's too much information that's been involved for a long time. We've basically got a deployment here of a demo site and what I want to point out is that it's not like most of it you don't care about but I want to show you the bits that you would care about. The easiest thing to do is to do a search of something that you know is going to have happened at some point such as a Drush command. If I start searching for the right word, Drush I get a couple of hits in the document and you'll see on you notice these build steps and things like that but this is just highlighting the fact that it's right at the very bottom which is what you really want to see when you're wondering what happened to your build because at the very bottom of every GovCMS build after all of the containers have been built and so forth then it starts getting into good stuff where it decides whether you've got a production environment and whether it should import your database or import config and then if there's going to be an area in your build like there is in this one that I've pulled up then you'll be able to see that here and that's right at the very bottom of your last deployment on GovCMS. So this is basically this is just a demo site and you've got your deployments here on the left and you're going to go into the last deployment and then you're going to scroll all the way to the bottom to find that. Okay, so that's a common one I see. So I've got here what happened to my build so you're going to go into your thing you're going to see your deployment scroll all the way down to the very bottom and it does, like I said it does help search for something like Drush that helps highlight where in that log you're going to find things. Something I wanted to pick up while I'm on that note is that something that's up and coming and this is probably more for past users that's Lagoon CLI and I'm sort of excited about this because it's going to make it possible to not have to do what I just did in terms of going into the deployment. So this is going to be one of those ones that if you have to do this you might want to refer back to this because I worked it out this afternoon but basically I've got a CLI I've configured that to point to the GovCMS Lagoon using this command here and then once I've done that I can start running commands that people on Pantheon and Platform will be more familiar with where you can start running commands against an environment in order to in order to see some results So we're running deployment against a project and then a branch that's not specific and there we go Now I don't use this CLI but I just wanted to flag that because it's coming through and particularly because at the moment it's not documented how to connect so maybe this is going to be something we see more of in the future where we can connect to Lagoon we can start running commands against Lagoon for our projects and that would be cool and that's all I'm going to say about that Now I want to talk about code bases Am I in the right spot? Yes I want to talk about the difference between Paz and SAS So let's talk first about doing a SAS project and the question is if you've got a project where you're not quite sure whether it's going to be Paz or SAS what is it what does it look like the difference between those two things? I'm going to start off by talking about what it might look like to have a SAS site and then convert that into a Paz site So essentially the difference between Paz and SAS is these two locations in your code base So I've got on the left I've got a repository that is a SAS site and on the right I've got a repository that's a Paz site If all things are the same between those two repositories in that they're both just the GovCMS profile then the only thing that's custom to those projects is the config directory and the themes directory in that you would be able to convert a site from a SAS site to a Paz site by simply moving those folders or copying those folders from one site to another with caveats around whether you're using config for your deployment and so forth But I think this is a really good one because I think there's a little bit of hang-up about I've got to build a SAS site but we don't know when we're going on the platform it could be another six months You might have some really good build process and so forth and it's really good to understand what it is that is being expected of you for your SAS site So I find like these slides are a little bit out of order from where I want to go I want to just skip those two couple of slides and jump to this one What I want to talk about is something that's dear to my heart which is if you're not on the platform yet but you've got a SAS project in your pipeline what's the best way to start developing that and so what I'm going to do is I'm going to pitch to you that the best way to develop that is to use one of the GovCMS scaffolds called the Scaffold Paz which might seem counterintuitive If we go back to the this image before though you'll see that all we really need to do to develop a site is to maintain this compatibility with a SAS site which is just our custom themes and our config directory and generally speaking as long as all the dependencies for our themes and the configs are being met in our Paz site and not gone past that it's going to be compatible with a SAS site So why would you... I'll bring up the GovCMS Scaffold Paz So just to differentiate what this is from a few other things there are a few scaffolds that GovCMS has there's the one that allows you to build a new SAS site and then there's this scaffold that allows you to do a new Paz site there's also a GovCMS I think it's the directory URL is GovCMS project or correct project or something like that that's used a lot less This is the one that I... This is my go-to scaffold and I want to explain to you why So say if I have a SAS site I will start the project using that scaffold and these are the benefits of it So these are the risks I'll actually start with So the thing is if you're going to build a site not on using SAS and you're going to use it with another scaffold you have to remember to keep these things correct You have to be really mindful that you're not going to add modules that aren't in SAS You're not going to add libraries that aren't in SAS because you wouldn't be able to add them to SAS later You're not going to be adding custom code You're not going to be overriding things in your settings not PHP You're not going to be adding patches and so forth So if we look at the benefits of the pass scaffold the first benefit is that the pass scaffold is actually completely compatible with the SAS site out of the box So if you are if you're running and if you've got a SAS site in your pipeline you can basically run a more traditional Drupal Composer build and retain the benefits of that prior to actually migrating that into a SAS scaffold Any customisations that you might do in the meantime it helps you to do them in a way that keeps them completely separate so that it's very easy to do your conversion to a SAS site later and it's ready to go for pass or SAS or any other ultimate hosting platform So for example one thing that you can do and your pass scaffold is something that happened to me was there was an upstream patch on GovCMS which I needed I wanted in a SAS site and that patch was approved for GovCMS so running the SAS scaffold there's a lot more mucking around in terms of having that patch but with the pass scaffold I'm able to put that patch into a custom patches file and when I build that scaffold it uses that patch So that's instead of being in the ComposerJSON file so I want to keep my ComposerJSON file kind of generic and not change it and that allows me to put all my patches in that separate file What I have to be mindful of for when my site transfers into a SAS site is I want to be able to run that the site needs to be able to run without that patch If there's any risk that that patch is not going to be there and really once I deploy to the GovCMS platform then that's going to be a problem and so I want to make sure that patch is being committed upstream In some cases your patch might be a patch to just help with your editing process in which case it doesn't it's actually completely unnecessary to have that patch committed upstream you're just having that patch for convenience so that certain things work in the UI in the short term So another example of that is say if you wanted to chuck in a bunch of development modules that you're not going to be using in the production site but in the short term they give you a lot more control An example might be if you're doing a lot of work with menus so you're throwing the big menu module you know that later you're going to remove that module it's not actually going to impact the site when it's the SAS site So the past scaffold lets you put all those modules in a composer.json file and you can verify all this against the scaffold itself If you go to the scaffold you see there's a custom directory and you can check out the composer.json file in that custom directory where you can add additional modules So yeah so it just allows you to define additional modules in the composer.json file and for SAS compatibility you're saying to yourself well can I run that my site without that module and obviously once you're ready to move your site over you need to be potentially exporting all of your config without the module which means uninstalling the module exporting your config and then copying the config file which has been provisioned for you So another benefit of that is one thing that I find frustrating with the Hoi commands is they don't always match the common workflows that we do as a team so the past scaffold has the ability to customize an Hoi YAML so you can just keep all of your custom Hoi commands all in a separate file you're not touching the GovCMS ones that sit in that Hoi YAML so you can set up your own then the only risk with your SAS site is loss of convenience there's the ability as well again just to have a separate project settings file where you can put all your settings that you want to override and again you're keeping that completely separate from the past scaffold and the beautiful thing about keeping all these files separate is later down the track if your site ends up being a past site you're ready for both one way or the other you can just simply go turns out that this is past site got mogged whatever you're ready to go you're ready to push it one way or the other and so probably the biggest thing to remember when you are like doing a past site then you might want to be using a separate development toolkit so personally I use a lot of Lando myself so if I'm doing development GovCMS development locally I'm using Lando locally but I have to be mindful of the fact that if I'm doing solar then my Lando solar it wants to match the GovCMS solar at least you know pretty closely otherwise you're basically you're taking that on yourself the more your own development environment differs from GovCMS but in my experience all of the development tools that people use for Drupal are all none of those websites that's incompatible with GovCMS so that's what I tell people to consider doing that okay so that is probably a big chunk of things I've got a few other things or a few other tips and things that I want to throw at you I want to throw at you that yes you can use the GovCMS UI UI kit start a theme if you'd like to but you don't have to and don't use it as a base theme so if you read the GovCMS UI kit starter info yaml it says you should use it you should copy it to your project and yes you can use it as a base theme in your project but don't use the base theme in the profile because the problem is that when changes to that base theme happen it's very often that causes regressions in your site because it affects the theme that depends on that base theme so a big thing I say to people is really consider your options when you're starting a theme for example I will always use a stable in core as my base theme and I find that that's a lot less regressions to do that it's just triple core out of the box and it can do it the way I want to do it that's something that people often start on your GovCMS site and they're straight out of the blocks they're using the starter kit and they're like deciding should I rename everything it's a very complex theme to be working with if you don't need to it's great if you're doing the vanilla content model that the profile comes with because a lot of things will be integrated out of the box it just really depends on your project and similar to that I really tell people to consider setting up right at the very starter custom admin theme because what we tend to do is when there's a glitch in the UI for editors we just want to throw a bit of CSS in there we commonly wrap the admin in a custom theme wrapper and it just means we can chuck in a few little things like preprocessors and stuff for like paragraphs previews and things for editors and then what you're using as a base theme you can point a different admin theme from Drupal.org if you want where you find admin works really well with GovCMS and just so you know the new Drupal core admin theme is not really ready to be used with GovCMS there's just sort of too much going on there and it's sort of not stable enough at this point so just on the right I've just got an example of an admin info theme might look like and using admin or theme as a base theme find that works really well and then I just want to talk about the content model for the profile GovCMS sites the big in theory part of it is that you like if they're all brochure websites because you know you can do a lot with what's out of the box with content types and things like that and they're sort of ready to go upstream they're being improved but what I see go wrong is when people are getting a build that's differing from that and they're not using any of the content types out of the box with GovCMS so they're getting a lot of entity types and things like that in their configuration that may never get used so I really want to say it's not a crime to remove stuff like taxonomy types and kind of types from GovCMS actually the balance of the equation is that you'll have potentially less issues and you'll never get that situation where developers you ask them why they created a new image style when there were three image styles they could use and they say I wasn't sure what they were being used for and it turns out they weren't even being used so something I do recommend GovCMS to you if I do recommend is consider consolidating your entity types how might you do that you can just delete stuff that you know you're not going to use you can always recreate them not a problem you might want to uninstall heavy UI modules like panels if you're not going to use them because they do add a lot of steps when you're debugging a site to go how is this being presented is it display split, is it panels is it custom preprocessor so just try and have the things you're going to use installed if possible I'll say it's not easy to do that something that will because there's dependencies that can be quite difficult to unpick with the profile something we sometimes do is we install the minimal profile for GovCMS and then change it so that it's the GovCMS profile so that we do get some of the core GovCMS profile stuff but it's a little bit tricky there's a couple of little tricks to it but just saying that that works quite well as well GovCMS as a platform the SAS site as a platform SAS platform does allow you to build very simple Drupal sites they don't have to have a lot of content types they can have one content type and they can have a couple of displays and you can do that all with what's in Drupal core out of the box and just use your own very simple very simple theme so don't forget that GovCMS is something on top of Drupal don't forget that it's Drupal underneath that is much simpler and much more robust and free of regressions so I think that time wise that's pretty good that's a whole bunch of stuff whole bunch of things that you might want to consider potentially hopefully didn't bore anyone a few other things I just want to say a couple of modules in Drupal core that you might not know are there schedule transitions personally that's been fantastic entity reference displays is a nice little one that lets people control how their entity references are being output from the editor UI you can now replace files in GovCMS there's something that people have been wanting for a long time another weird one is the context module which people don't realise is there because you don't turn on the context unless you've turned on the context UI module but that's really great for simple fixes you might want to do like setting active menus and adding blocks if you've got a couple of different block layouts and you think your block UI is going to be a bit full on context module can work really well for that so that's my final tip and that's about me half an hour


Just would like to ask you about the scalability of Bitcoin What options has Bitcoin right now and what are the advantage and disadvantage of each of the options that are and what's your Opinion that which of those options should be should the community adopt? Oh, that's a very good question. Also a very easy one to answer all of them I did a talk in Prague Which has been videotaped and will be videotaped I'm over 40 Ignore that Recorded there we go, which has been recorded and will be brought It's topic the entire presentation was about scalability and why scalability is something that doesn't get solved It just gets pushed further out as we scale to different types of applications And so the question what are we going to do? Are we going to do a segregated witness or raise the block limit or invertible bloom lookup tables or thin blocks or? replaced by fee or Etc. Etc. The answer is really simple all of them and then we will run into new scalability problems because the moment we create space With these capacity improvements people will look at that space and think hey I can do something I couldn't do before and then that space will be gone and that story repeats The internet is an example of a technology that failed to scale Gracefully for 25 years if Bitcoin manages to fail to scale gracefully for decades We're in a very good place. So yes We will do all of those things the debate now has narrowed to the point of which one do we do first? And is it this month or next month or this year or next year, which is really just an engineering issue and is not worthy of all of the drama and recriminations and That happen in this space So yes, we will do that and I'm very confident about scaling because Ultimately scaling is an engineering issue and Bitcoin has within it the capability to scale and not just that But we are seeing the very very smart people working in the development space of Bitcoin Inventing new ways of improving scaling all the time, and it's not just the five I mentioned There's like 20 proposals on how to continue to scale Bitcoin will it scale Ultimately on its own without another layer, I don't know that maybe we'll have to do more layers on top as long as there's Trustless and decentralized. I'm okay with that, but it will scale


Hello, Oslaid Sync here. One of the things that really appeals to me about modular is the intellectual challenge of working out how to create a patch, the creative problem-solving as you work out how to connect the different sound sources and modulation sources to bring them together into one, a glorious, in this case, droning, whole. But I do find that for myself personally, I do have a tendency to find myself approaching it purely from the intellectual side of things and then ending up feeling a little bit disconnected from a patch when it comes to the actual performance. So recently I was looking for ways to bring in more hands-on control beyond just knobs and sliders to give me a more connected feel to my patches. So to that end I was very happy when I was browsing Etsy one evening and I came across this here, the Herzlisch MMI man-machine interface which is a way for me to bring very, very hands-on control to my patches. In fact, it allows me to literally become part of my patches and I've been really enjoying exploring this module and I wanted to just share it with you because you might enjoy it as well. To be clear, this isn't a sponsored video that I bought this module myself. Herzlisch have no idea that I'm making this video but I just like to share cool things and seeing as they are a smaller maker in just a one person operation. I do like to try and shine a light on smaller makers. So in this video we're going to talk about what this is, how it works and try out a few different patches to see how we might use it to add more hands-on control to patches. But now I have to un-patch one of this so I'll be back in just a moment. So let's start with the very basics. This is a patch cable. You may have seen one before in a modular system. A patch cable has a wire in it and that wire is very good at conducting electricity. At the moment the electricity that's been put into this wire is the oscillator signal from the 2HP VCO here and if I plug this in to my mixer we can hear that electricity being conducted and we're hearing it as a sound of course. Now a patch cable is very good at conducting electricity but other things connect electricity as well. So for example if I plug in this un-connected patch cable into the mixer here and I touch the end of each of these patch cables with my thumbs you can hear the signal as well. Now it's quieter because I am not as good at conducting electricity as the wires are you can just use yourself as a patch cable between two patch cables and it's one way to perform sounds in modular I suppose. But it's probably not the most elegant approach to actually creating this connection through your body which is where the MMI comes in. So on the MMI here you have three patch connections and these three zigzag zones, these patterns that you can see here. Now each of these patch connections correspond to one of these zones. So if I plug my mixer's input to that top one there and I patch the oscillator to the middle one there now we have a way for me to connect using my body between those two zones essentially completing the patch. Now because we have this zigzag pattern I can put more or less of my skin against that zigzag pattern and that's going to make me a better or worse conductor of electricity and allow me to get performative control over that patch connection through my body which is very nice. Now we have that third zone at the bottom there so we could patch that into the other side of the mixer and now in the middle we have our connection we have the left and right outputs now on either side so we have a finger controlled panor if you like. You can see here that we also have these sort of spiral patterns here and these spiral patterns are made up of the coils on either side of them so this spiral pattern contains the top and middle and this spiral pattern here contains the bottom and middle which allows us to do one-fingered connections between each of the patch cables and that's basically it with the MMI so not inputs or outputs, they are bi-directional now I would probably suggest that you don't want to accidentally connect an output to an output it's probably fine in most cases so the way I've been using this is with a single input usually in the middle and then two different destinations on the other side but your mileage may vary but move with caution obviously you are routing electricity through your body but you can't feel it, the current is low enough that you can't really feel it I guess if you're particularly sensitive to these things you might feel it you also probably want to moisturise your hands I overwashed my hands and I wasn't getting a good connection because my skin was so dry but since I've started moisturising I'm getting a better connection so let's look at some other ways that we can patch this up to give ourselves nice performance controls in this system now I am a massive cliche which is why I have rings or at least the rings cloned in my rack of course I do, how can I not so here what I have done is I have patched the top output or patch point rather on the MMI into the input of rings rings is going out into the mixer what's going into this middle input is some filtered noise so I have noise here on kinks going into the aid actual filter and then it's coming into here and so what we can use the MMI here for is just a way to connect the output of the noise to rings and allow us to perform rings and it really does feel like you have some very nice fine control over it it's very satisfying lovely stuff so yeah, just rooting signals, audio signals around using the MMI as a kind of touchable VCA or attenuator very pleasant very pleasant indeed so here we've got a basic mono synth patch going on here it's the square output from the VCO to HP VCO here it's going into the Hamster Electronics dual VCF which is kind of a MS-20 style filter to the output in terms of sequencing we've got pams pinging away on an envelope stages that's going into the adder here up at the top here what I've got patched into the MMI in the middle I've just got a 8 volts output from stages just a static voltage jack here I've got that going in to be added into my envelope here essentially giving me like I'll branch those two sections there which is good fun at the bottom here what I've got is the output is going into the level of the channel of stages which is doing the envelope essentially this is going to increase the envelope so yeah, a really fun way to perform that sequence to give a different kind of hand it's very satisfying one of the most basic and obvious I suppose ways of making use of MMI is as a pitch bend control so here we've got a pizza doing a kind of mournful trumpet thing going on envelope coming from stages little bit of reverb coming from MFX but in terms of what the MMI is doing into this middle zone here I've just got a static 5 volts coming from at 10 and the second, sorry the top jack rather is going into the control of pizza which is currently set to affect the pitch give it a little bit of movement there on the edge of the zone and if I'm careful a little bit of vibrato as well this works best if you can set the voltage fairly precisely because you don't want loads and loads of voltage in there I find that this works better if you give it a decent voltage coming in and then attenuate it as you need so on pizza I'm just attenuating it using the control not here but in other patches I've also attenuated it using just a standard attenuator after the connection that seems to work better but it's very human and expressive how you can do those slurs and you can be fairly precise with dialing in the notes now another way that we can approach this is rather than making use of a static voltage we could take an LFO instead so I've got an LFO running here on stages we'll run that into the middle instead and now we've kind of got a mod wheel control instead and again it's quite a nice expressive way of bringing in that vibrato and kind of really feel it out in a way that I don't think you can really do with a knob it's kind of a basic way to approach it but I can honestly see this being how I have it set up a lot of the time because it's just really nice it's really nice to play the MMI is an elegant and aesthetically pleasing implementation of this idea of rooting current through your skin as a means to musical expression but it's an idea that has been around for a while this practice of body patching has been a mainstay of the circuit bending world but on the slightly more conventional end of music technology you can find it on devices like the Make Noise Strager across a bunch of the Soma Labs instruments in particular the Arcane and Fascinating Enna by the way if you haven't checked this thing out and the more experimental side of electronic music is your thing you really must watch some videos there's kind of nothing else like it out there I should also highlight that Herzlitz also build other devices of this kind and I've just got to flash this thing up on the screen for a moment the MMI Maxima which takes the same concept into an expanded desktop form factor and well just look at this thing the most commonly adopted example though has got to be the Artoria Microfix keyboard an incredibly expressive playing surface due to its design what I've learned about myself in making this video is that I apparently lust after any instrument with this type of playing surface because I've just listed a bunch of stuff that's at the top of my gear wish list but that's not what I'm interested in and what I'm more interested in is this output of pounds which is firing out triplet triggers and that's going into the middle jack of the MMI the top and bottom jacks are connected to the trigger inputs on the beehive and the sync input on pizza which is set up too far off its internal envelope and what that allows me to do is connect those trigger signals to those trigger inputs and bring in two different hi-hat parts by joining the right part which is a really really fun way of performing these sort of incidental parts they don't want just latching and going the entire time and because we are rooting around triggers rather than audio it's not having the same effect of sort of fading in and not quite getting the full volume of the signal as we were getting when we were moving audio around now obviously sometimes you want that sort of dynamic performative expressiveness but for this kind of patch where you just kind of want it on or off this is a really nice way of working and you can hear that sort of on the edge of the conductive you can kind of do that sort of random skipping of trigger inputs as well and it's a really cool way of finding these extra rhythms in there which are kind of you're kind of just grooving to it really fun so don't just move the audio around using this when you can also move around the thing that is triggering the audio to happen to give you a kind of different approach so this is a real nest of cables but the good news is you don't really need to worry about most of it there's a drum patch happening in here and it's all going to run into dark matter which is adding the grit the important thing that you need to know is that the output of dark matter is being molted both to the output but also into a high-pass filter here which is then just being slightly attenuated using a keydo and it's that high-pass attenuated drum mix that's set in the middle zone of MMI here the top and bottom jacks here are connected into MFX which is running a reverb algorithm and disting which is running a delay so what we've got set up here essentially is a classic kind of dub send setup here where we can momentarily send the signal into the reverb and delay for blasts of reverb and delay and it's really good fun so basically here we're using it to set up two aux sends if you like within the patch really performable reverb and delay now we can sort of fade in the send as well of course or rather just do it momentarily blasts like that works better with the reverb I think than the delay and delay as well essentially using it as part of the signal reading within the patch I don't really do reviews as such on the channel but in a video where I am glowing with praise I will mention a few things because I don't want anyone who rushes out to try one of these modules to feel misled first if you have dry skin you will need to moisturise I overwash my hands and the performance of the MMI was initially disappointing but I found that even breathing on my fingers to get a little bit more moisture on them helped loads and once I spent a day moisturising every few hours it performed wonderfully next the module flexes a bit I don't actually think this is a problem per se it doesn't feel like it's suddenly going to snap and it does provide some positive tactile feedback in use but I would probably feel a little more confident if the circuit board was a little thicker or braced at the back or something like that probably the big one is that with hot audio rate signals there is leakage to adjacent zones you may have heard it on one or two of the demos I suspect this is because of the spiral areas allowing a current to be induced because of the proximity of the two tracks but I'm no electrical engineer so that's just a guess just know that in that use case you might find that you don't have perfect isolation between zones the isolation between the top and bottom zones seems much better though I think this module is a perfect candidate for a 1U version because it allows you to mount it completely out of the way of most of your patch and I also think that the horizontal arrangement leads to a more natural hand position when you're playing it you might see in some of the sections of this video I've converted that I got from thunk to mounted up top of my pallet case but a dedicated 1U module would be very welcome as the layout and size could be optimised a smaller version with just two zones could be really neat as well, for example and while I'm designing fantasy modules I think an active version with a 5V normal to the middle zone as a default routing would actually be really really useful as that's the use case certainly for me that I found that I was using most and it does save you the hassle of locating a 5V offset somewhere else in your rack anyway I hope you enjoyed this video and that I was able to shine a light on a neat little module that you could potentially try out if you did enjoy the video then as always a like and a subscribe is massively appreciated it does help out on the channel and other than that I will see you next time take care, bye bye


I took the general BCC program at WNTC because it was incredibly comprehensive and one of the most in-comers decided to be covered. I'll take the tracks of the transformation as well as the basics of how I'll get to my TCC stuff. So, I think this sort of, you know, yet well done in a telephone company and kind of move into the national and the online world, but most of the time we're all out of the try-and-show to start it before writing my comments to my adventures as well. So, just a little bit, just a little bit, you know, while I'm doing the TCC for a long time to be sure, you know, only at the end of my national and the TCC, which is a telephone company, I was talking about TCC for a long time, so I had a lot of time to start the program, but I think a lot of different calls have to take.


So today we conducted active shooter exercises integrating our U.S. military members with our ROCAV partners to test capabilities on response and communication and ensure that we have the most efficient airtight operation for active shooter response. So the goal is to do quarterly exercises testing our force protection wartime transition. So this was our first for this year 2023. Today we had an insider threat with the U.S. individual and we made sure that we contacted the GOC, the Ground Operations Center to get their dispatch of their special duty team and their military police. We did this to test their response capabilities with their MPs and then also test our recall procedures and lockdown procedures for the U.S. individuals on the compound. We had also tested their fire and medical response to see how they conduct ground operations and see how we can interlock our U.S. personnel with our ROCAV medical team. So our overall goal is to build communication and then since this is a ROCAV brand compound to make sure that we as the U.S. guest on the installation know exactly who we need to contact, how we contact them, what their response procedures are and how we can best facilitate any operations that involve force protection or wartime operations. We did a crawl, walk, run phase so initially we just outlined what our expectation was. From there we sat down and did a tabletop exercise, ran through the scenario from beginning to end and then we finally got here where we did a full scale exercise. The key part is just making sure that we're all 100% ready. Readiness is the overall goal. As we work through all these processes we iron out to make sure that we're 100% ready to respond to any type of threat or any type of war response.


Please stop saying this to single Christians. Singleness is a gift, a blessing, enjoy it. Bro, hold up, wait a minute. Yes, the gift of singleness is a gift, what Paul had. He didn't have the desire to get married. He was very content with being single his whole life. Undesired singleness, however, though, is a blessing from God, as all things are, can still be a trial in someone's life. I fully recognize that we should rejoice and give thanks in all things, and recognize that God is at work behind the scenes. But that does not mean that everything that happens to us is yippie-skippy. You don't have to see everything in your life as great and wonderful just because it's part of God's plan. It is a part of God's plan, but it's also hard. Just recognize that it's not wrong to see a trial as a trial. It's actually only when we begin to acknowledge that we're having a hard time can we give those feelings to God. We thank God in all things, but we can also recognize the emotional and mental challenge that undesired singleness has on a person. Look, all I'm really trying to say is...