Welcome, I'm Paula Nehme, I'm part of the EHF team and it's great to have you here. This is our first session, first workshop of the New Frontiers Digital that we are doing and this is an offering that we are having for the community, a way for the EHF fellows to get to know different people and in the community around the world and for all of you to get to know the fellows. And I'm super excited that we're starting with Boyd, a part of his amazing and he moved here not long ago. His story is really, really cool to hear. So before handing out to you, Boyd, I just want to say a few housekeeping. If you are not talking, please mute yourself. If you see in your own face, like in your window, there is three dots and you can rename yourself. If you can add your location, I think that's a really cool thing to know from which part of the world you are joining us today. Most of us are in Wellington, like the speakers and the host and me and Michelle, but I know there's people coming from different parts of the world and we would love to know from where you are joining us.  Some people will be joining me in a meeting, so we just let them in and mute themselves. And now Boyd, I will go with you. Thank you, Paola. Hi, I'm Boyd. And let's see, I joined the EHF, gosh, about a year and a half ago. Well, at least that's when it officially began. The story begins a bit before that. Let's roll back a couple of years. I had spent a long time at Microsoft and was kind of burned out and really tired and wanted to do a new project. So after we left, the family and I were trying to figure out what we wanted to do. And one of the exercises that we ran was, you know, sometimes you end up in a position in life where you get the pick where you want to build something and where you want to be instead of joining something that already existed. So we said about doing this exercise where she had been studying data science and built a model. We had this long conversation about what are the values that we have in a place we would choose to live and included things like good schools and healthcare and stable government, stable currency, good business law, weather, traffic patterns. You end up sitting down, you write a list of the things that you care about. It ends up being longer than you expect. Probably about 60 criteria that we listed out. And then, you know, just trying to be open minded about where we're going to go. So we started listing countries and cities that we would be interested in. And I'd say 20 or 30 cities in the US and then pick places all around the world. I don't think we actually knew that much about New Zealand at this time. So Auckland was pretty easy to put in the list. And then what the heck was put the capital in? That's Wellington, never heard of it. Australia, Norway, Spain, Finland, all kinds of places were in there. And then you go about collecting as good and neutral data as you possibly can. So we found several sources that had rankings of different metrics about all these different cities. So at least you know that those metrics are normalized against each other, put it all in. And we were really surprised the first time we ran the model because Wellington popped out as the number one city in the world for our set of criteria. Okay, didn't really know anything about the place. And you start dialing knobs and you're changing things in the model. Hey, I'm going to change the waiting factor on traffic. You could see Wellington would drop a couple spots and maybe Auckland would come up. Slightly better weather, definitely worse traffic. But New Zealand had several cities that stayed in the top five pretty much no matter what we did. If you dropped temperature down, you could see Stockholm start coming up, but you know, it gets kind of cold there. So that was an interesting experience. And then like a week later, I saw this thing called Lixey Wellington go by in an article in some newspaper. This is several years ago. And okay, we're under what this is. And they were trying to bring tech people into Wellington. So I ended up finding myself part of that experience and ended up becoming a week in Wellington to just check the place out. And you look around and A, it's gorgeous. This is a really pretty city. A little on the windy side, not as hot as other parts of the country, but absolutely gorgeous. And there's a saying that people here say, which is you can't beat Wellington on a good day, which I totally believe. Anyway, by the end of the week, I was pretty convinced this is a good place to start a business. It's a good place to get work done. It's got a good place to have schools. It's a gorgeous place to live. It's, it's how to put it, it's got culture like it's a big city. But size wise, it isn't that big. It's about a half a million people, but it's compressed in the middle. And you end up with a very dense inner part of the city with lots of restaurants and art and all kinds of things to do. So it feels like it's got the culture of a much larger city. You know, and I'm coming from Seattle. So to me, the cultural aspects of a Seattle and Wellington are pretty similar, even though Seattle is many times the size. Okay, so after that week, it was interesting, I'm talking to people from immigration and talking to people from Wellington. And the weekend ended and it's sort of a typical learning. This is a typical New Zealand sort of attitude. They're like, Okay, this is great. We'd love to have you here to start a business, but we don't have any pieces for you. We'll figure it out later. So it went home, kind of went on with my, with my life and building stuff. And about six months later, I got a phone call from the city saying, Hey, go check out the Edmund Hillary Fellowship, which turned out to be a really good connection. So that began the next bit of learning about about New Zealand and about places to be in, you know, continuing in our journey of what do we want to do? And if you're going to move, and you're moving to a new place, and there's not a lot of people that you know, like my networks of people that I'm super close with are back in Seattle, or Atlanta, right Leonard? I see Leonard there is give me a thumbs up. There's lots of people that I've worked with in the past that are back in the states, but if you're going to pick up and move to a new location, one of the things you have to worry about is how do you rebuild your network and rebuild it quickly? So the the fellowship became a an avenue for that to happen, a way you can come in and you can land you can meet a rather diverse set of people, and some of whom are going to be a lot like you and some of whom aren't and that's a good thing and a bad thing all wrapped up in one. But then you know, you go through a fairly long, a fairly long application process, lots of interviews, and you get in. And we had a we had this moment. This is going to be what about about two years ago, when we got the confirmation that we were in, and that we had this choice. Now, are we actually going to go through with this? Are we actually going to move to New Zealand? I mean, in the fellowship for sure, but do you actually pick your family up and move? Because it's kind of a big deal. So we had this family meeting one night. And, and my wife and I had already talked about it. And we went to each of the kids and said, Okay, we have this opportunity to move New Zealand is going to be a lot of things that are different. There's going to be a lot of things that are the same. But either way, it's a big, it's a big change. And we wanted to know from each of them, what was their opinion? And our oldest immediately said, Yeah, I'm in 100%. And then the middle one, I think she was quiet for a little while, and then she started crying. And she was worried about missing her friends. And then the youngest one said, When you guys get in the airplane, that's when I'll say goodbye. Okay, so roll forward a little bit in time. We've come here, it is uprooting your family. It is uprooting your network. It is good to land in a place where you can rebuild your networks. But it turns out New Zealand is a really cosmopolitan place. And I can't really speak to some of the other cities, but Wellington is especially so. So immediately we started making friends from all over the world. The kids have all got new friends. They're all happy. The youngest one actually settled in the fastest. She's got her new friend group immediately.  So now we're here and busy building a business.  One, if you're if I'm if I was building a business where I was going to be shipping goods all over the world, I'm not sure this is the right place. Right? This is not a geographically located kind of place where you want to put stuff in containers and ship it all over. You're kind of far from everywhere. Now, if you're building things that get built in other manufacturing centers that have really good, they have really good containers and really good shipping, different story, right? But you don't come here to ship from it. This is a great place to build software. This is a great place to build intellectual property. This is a great place to do fundamental research. It's a great place to build products that ship digitally. And whether that's movies, or interesting deep tech software or IP or whatever, that's all super easy because the internet's great. Pretty soon we'll have satellite connections everywhere. And that's just not a barrier. Let me look at my notes. Another interesting thing about landing here is that you quickly realize, at least I quickly realized that each of the major cities has got an economic development agency. And here in Wellington is called RITA, W-R-E-D-A, Wellington Regional Economic Development Agency. And it's not something I was really used to in the States. And like in Seattle, yeah, there's various boards and there's like Chamber of Commerce and there's different things that kind of help businesses get going.  Here, RITA is actively looking out for the economic interests of the whole region. And they ended up being a resource that I found to be really interesting. I still get calls from people in Christchurch who let me know how great Christchurch is as a city. And, you know, every once in a while I get the pictures. So maybe you should move your business down to Christchurch instead of in Wellington. At which point I remind them I've been to I've been to Christchurch twice and both days it rained. So according to my data, it rains 100% of the time there. And I can see some of the New Zealand people are like smiling at that because it's completely not true. The weather is much nicer in Christchurch. But not according to my data. So let's see. I'm going to switch over and share a screen for a second here. Let's get the right one. Okay. What you're looking at is a map of New Zealand. And can you see it correctly? Paul and Nod if you can see it. Okay. So you're looking at a map of New Zealand. And right in the middle, right here, I shouldn't have moved it. Here in the middle where the little red star is, that's Wellington is. It's kind of in the center. It's at the bottom end of the South Island. Temperature wise, up here in the Northland, way up here is quite hot. Every time I go to Auckland, I think it's a nice place. It's too hot for me. And lots of traffic. Hamilton is very rural. Lots of cows. Lots of farming. Rotorua is very nice, especially if you like the smell of sulfur. Let's see. Lake Taupo is up in the mountains. It's basically a big crater lake. Wellington is down at the bottom. It's super interesting. This is the seat of government. This is where the parliament is. This is where the center of all that sort of action is. It's also got a really big software community and a big research community. And that's very interesting. Down in Christchurch, I'm going to say there seems to be a lot of aerospace down there. After the big earthquake in what, 2011, they've been rebuilding that city and they've broken it in the different districts. There's a tech focused district and an education district and a health district. And that's very interesting from a planned perspective. I've never been down to Dunedin. It's on my list. Queenstown is, of course, completely gorgeous. It's up in the mountains. And if you've ever been to Whistler in Canada, it's like that, except prettier. All right. Now, it's one thing to talk about places. This is a official picture of Wellington. You can see it's in the bay. The slide didn't move. No, the slide didn't move. I still see the map. Oh, you still see the map. Okay. Yeah. Let me... Screen sharing is paused. Zoom. Now... You want to see? All right. So here we have an official picture of Wellington. And you can see it's got a nice bay. It's got lots of waterfront. It's a really pretty city. But whenever I see official pictures like this, I ask myself, okay, so what is it really like when you're not from the exact right perfect location? And it's not the exact right perfect day. So about, I'm looking at the time, about half an hour ago, I walked out onto the front porch and held my phone up and took that picture. So Wellington's an interesting place. If you've ever been to Hawaii, it looks like, it's like, I call it cold Honolulu, right? So it's got a bay and the city is compressed into that bay. And behind it are lots of hills and lots of verticality with lots of vegetation. And the people live up in the hills. So almost anywhere you go, you're either, you know, somewhere on a hill, maybe at the bottom of the valley or at the top, but you end up with lots of views like this. Here we are looking away from the water. So this is this would be like a typical Wellington territorial view.  It's going to be, you know, 40 feet higher in the air and you're going to get tons of tons of views. It's just that kind of place. It's kind of weird to drive around because some of the roads are really compressed and it has to curve around the hills. And you think what insane person put a city here? But it sure makes for interesting driving and it's a gorgeous place. A couple of days ago, I walked a couple blocks down the road and this is I was walking the dogs, which is weird because there's no cars and everyone's still in lockdown. And I took this city looking out from the cable car out over the over the over the city. And this is just a gorgeous place. Can't emphasize that enough. And lots of scenes like this, lots of public parks out in the beaches. This one's obviously not a beach, but there's good beaches too. Like this one where my daughter does a lot of what my oldest daughter does a lot of rowing and a huge in the sport here. And if you don't have a sport that you're into there's probably one you've never heard of that they're into. It doesn't have to be rugby or any of those things, which I would personally not for me, but you know, rowing. Yeah, interesting. Just they're very into this kind of stuff. Okay. Other things I've learned about about New Zealand, there's a lot of support from government and from other things that frankly, I'm just not used to. I'm still working at building up my connections with a group called Callahan. But it's a national research organization that is there to support businesses doing research and includes things like grants to help you get your get research done here. They've got labs, they've got equipment and those, you know, so there's a piece of equipment I need for one of the things I'm researching. There's no way I could ever afford it. And even if I bought a really old used one, it would fill the well, it would fill a couple of rooms in the house. So I'm not getting one of these things. My wife said no. But Callahan's got them and they've got the right room set up and they've got people who know how to use these things. So it's a vacuum chamber. They would they were deposition machine. Doesn't matter. They've got one. They've got it set up. You can totally work with them to get these things used. So the point is there's a lot of support and and and agencies and people who are available to help with things that I just wasn't used to having these kinds of things available back in other places. Why don't we take a couple of questions and then I will probably dabble on a little bit more as I as I remind myself of things I wanted to talk about that I forgot.  Yes. And I have a person ask, does the flight connection via Auckland bother you when traveling internationally for work? OK, so does the flight connection through Auckland bother me when traveling internationally? No, I'm going to say no. It's a super short flight to Auckland. It's like slightly less than an hour. So it's like it's like you're commuting up to Auckland, then you have to walk 10 minutes to the other terminal and then it's the flight out of Auckland that bothers me, right? Because you can't get anywhere internationally without sitting on a plane for a minimum of four hours, just going to Australia as a four hour flight. So I'm not going to pretend that it's got it is great from a connections point of view. You're just far away from everything. Right now within New Zealand flying within the country is super easy. I personally like Air New Zealand and there's flights to everywhere and they're pretty frequent and I don't know how to put it. Strangest experience when I first got here. And so we land, we're going through our stuff, we go through our EHF welcome week and then the city of Christchurch had hosted a bunch of the incoming fellows. So this is my first internal flight, right? So we've landed, we rented a car, we drove down to Wellington. So I'm about to get on my first flight and we're running late. This is one of those days when Wellington traffic actually bit us because the tunnel, Victoria tunnel was kind of slow. So I'm running short on time. I have to get to the airport and I have to get my flight to Christchurch and I'm starting to really stress out. It's like the flight's in an hour. And in any airport in the States, you know, you're done. It's not going to work if you get there too close to your actual flight. So I get to Wellington. I get to the airport. I'm running through the airport. I've got my ticket. I'm looking for my flight. It says, OK, it's coming on a gate 19. And I'm like racing, trying to find, trying to find where security to get into it. OK, I'm at gate 19. I show my ticket. They're like, OK, I've run through the thing. I'm on the airplane. Strangest experience. I was so not expecting it for really local flights when you're not on a jet. It was a prop plane. There just wasn't any security. It's like hopping on a bus, right? Because people work they're trusting here. And it's a small community. You're far away from things. It's a different mindset. And I just about fell over that day. Even today, like when I fly to Auckland, that's on a jet. So you do have to go through security, the metal detector and all that stuff. And I'm standing in line. I'm trying to chug my coffee before I get to the metal detector. And the guy's like, just carry it through. OK. Oh, I see. I can just carry my coffee through. Right. So it's slightly lower key. Getting around internally is tremendously easier on the airways than I was expecting. The roads are good so you can drive everywhere. But you know, driving Wellington to Auckland is going to be about eight hours. So but easy flights to get around. And then when you do the international hop, if you're going to Australia, you can go Australia and Singapore and go directly international out of Wellington.  We have a question from there from Ramesh. You started the new businesses before or after you landed in Wellington. Did I start the new business before or after? Both. So the main one I'm pushing, I had started back in the States and had already been working on for a year or two. And it's now getting reformalized here in New Zealand as a New Zealand company. But it's an effort that I've been working on for a while. I've got another one, which is more of a research sort of project. And I'm doing that largely in conjunction with Victoria University. And that's been built here. So that one's been formed here and started from scratch. Starting a company here is tremendously easier than anything I've experienced before. In the States, when I've formed companies there, it usually takes a bunch of work with lawyers and quite a bit of money and a lot of effort to get yourself set up. But you end up with, you know, you end up with a company here. It took about an hour on a government website. And I was in. So that was that was a different experience. Now, I don't know exactly where you wanted to go with that question. So if you have more detail on it, pass along or ask another question. Yeah, I have another question. What are the three things about your move to New Zealand or Wellington that you know that would have saved you some time, stress money if you would have known before? Let's start with schools. The New Zealand school system is. At first glance, it seems a little bit old fashioned. Right? So the schools are generally segregated boys and girls. They generally wear uniforms and they're generally really good. And we could have just not stressed so much about it. So we ended up going through a ton of research and talking to a ton of schools and now a year and a half in we realize now all the schools here are actually pretty good and it's it's hard to go too wrong with it. The separating the boys and the girls that takes a little bit of getting used to everyone's wearing uniforms that definitely took a little bit to get used to. But once you're there, it's actually it's pretty easy. The second thing that would have saved me time and money. I didn't understand what the ACC was. All right. And the second thing that would have saved me time and money. I didn't understand what the ACC was. All right. I don't even know what it's fully stands for. I think it's accident. Accident compensation. I thought the other says yeah. Yeah. Accident. Yeah. Corporation. Yeah. Okay. So the ACC is different from what you see especially in the states. It is a accident insurance program that covers everybody in the country. Right.  Right. That stuff is just not a thing here because the what they've done is it's not just a national accident coverage scheme. It's also major changes to tort law.  A, the ACC is going to cover it and get that person whatever care they need. And B, you're not allowed to sue them. It's just not the same kind of tort law. Right. So that would have saved me a fair amount of just general paranoia in the beginning and worrying I was somehow doing this wrong because I couldn't figure it out. Well, what are you liable for here and what are you going to get sued for and what sort of accident coverage do you need without realizing that they've kind of got that taken care of already. Right. The next one was probably a US centric thing in that, of course, I'm worried about healthcare because it's incredibly expensive and private insurance focused and I'm just not going to go. I can complain about the US healthcare system, but that's not the point. Healthcare here. It's really pretty easy. You don't have to have insurance because there's general coverage. But if you do, it was really easy to obtain and really inexpensive, at least coming from a US perspective. Right.  Right. There's just a bunch of tips that I've been collecting for people who are coming to New Zealand. I'm not getting some, not going to give them all. This goes everything from, look, you're driving on the left. Don't go on the right. There's certain intersections that really look like you want to go on the right. Don't do it. Let's see that tip is if you're on highway one, I want to pause here for a second. In New Zealand, in my mind, there really is only one highway and it's highway one.  And it's not the freeway in the same sense that you would have there. So there's this intersection of highway one where you're taking the exit to Kelburn and it comes off on the terrace and you're on the right. And boy, it feels like you want to turn into the right lane on the right side. Don't do it. Other than that, things to know us crosswalks are super serious. If someone's even about to put a toe under the crosswalk, you stop. There is no right on red, especially true for Americans and Canadians. You're used to taking a right on red. It would be, I guess, left on red here. Don't do it. No one's expecting it. It's not allowed. There's a ton of other ones. And as we talk, I'm sure we'll come up. Yeah, Michelle. Yeah. Another question that's come in is, how do you compare the cost of living between Seattle and Wellington? That's a good question. Cost of living between Seattle and Wellington. It's weird. I'm going to say, lots of people here like the complain about the cost of housing. It's less expensive. All right. Cost of housing here is less expensive than the equivalent housing in Seattle. Even though when you talk to the Kiwis, they're all going to complain about how much the price has gone up. It's still less expensive than the cost of living in Seattle. Food is about the same. Food in New Zealand is set by international transfer pricing. Right. So it's a competitive global market. New Zealand is a food producing country, but they export almost all of it, which means that the prices of it are set on world markets. So milk, cheese, produce, everything is about the same as what we paid in Seattle. Housing is cheaper. Food is the same. Education is a half to a third the price. So I've researched private schools in Seattle. We've got our kids in a private school here. I, I, we got three of them in a private school for the price we would have paid to have one in private school in Seattle. Now let's see cars. Cars are actually kind of expensive and gas is kind of expensive, but the insurance is not. Right. But then again, especially in the city like Wellington, you don't drive that much. Right. Wellington is really easy to walk across. It's got great transportation. It's got good air connections. We pretty much use the car to go to the grocery. So we're spending way less on that. What other types of, let's see, airfare. Similar to what you'd see in the States. I think that's set by fuel prices. Yeah. So I'm going to say similar to Seattle on many things, except housing where it's actually less expensive. Don't ask me about buying a house because I'm not allowed to yet. So by renting, you can tell that is similar. Yeah, I mean, yeah, we dream about it and we think forward. And when you look at house prices, I'm going to say there is significantly less expensive than buying a house in Seattle. But we haven't actually gone through that yet. Okay. Fair enough. I have another question. Yeah. Okay. How are you benefiting from the EHF network of fellows, investors and experts? And how are you planning to scale up your business with their help? Well, the best part about, I mean, the best part about the EHF network is when you land, you don't know anybody. Right. When you're coming here, you don't have a network. You don't know who you're going to, you don't know who you're going to end up working with. And you need to build that network up quickly. And that's something I was super worried about. And that was the single best thing out of the EHF network was rebuilding a new one very quickly. So the business partner I'm founding it with, I met him at an EHF event. A local guy, he came to New Frontiers and we hit it off and, okay, I found my business partner like way sooner than I thought I would. When it comes to the other fellows, I'll say that mostly they're doing their own independent work. So it's, it's more like we advise each other. I see Leonard sitting here sort of like this. And you know, I'm hoping to get your advice Leonard. That's going to happen when he eventually moves out here once the lockdown is down, once the lockdown is over. And I assume that travel plans are all messed up at the moment. No, we should talk about lockdown. Don't let me forget because that's, this has been a very interesting experience. But when it comes to working with the other fellows, it's so far it's been less working with them more advising them more. And I think it's a great opportunity for us to be able to work with each other, telling each other stories that help save time and money later on. The best connections I've gotten through the HF are actually to some of the local Maori leaders, some of the local business leaders. That's been super useful. Has been, I haven't been personally interested in getting investment money. So I can't really speak to that. Yeah, Michelle. I think that's a good question. I think that's a good question. I'm going to get you to your kids and private school. Public schools are pretty much the same quality. Okay. That's a good question. And I'll give you two answers. First one's. Probably the real one is. Is a little bit cheesy. We didn't know where we wanted to live. And when you're moving your family across the, across the world and you're uprooting them. You're not going to move them. You're not going to move them. You're not going to move them. You're not going to move them. It's a big hit to your kids. So we wanted to put them in a school. Where if we chose the wrong neighborhood, we chose the wrong part of town, we wouldn't be forced to move them again. Right. So there are catchments. And depending on what part of the city you live in, that's the set of public schools we're going to go to. And if you pick the wrong one and you move, you're going to switch. Right. So we wanted to be able to have a little bit of freedom. We wanted to make sure that we had a level of freedom. And so our teachers weren't going to do the same quality. They're all very good. There were certain programs at the school that we chose, which really appealed to our kids. And that was a big factor in why we chose those schools. Like Wellington girls is a very, very good school, but you know, the classrooms are going to be about double the number of kids for your teacher. And they've actually got slightly more options than Queen Margaret, student-to-teacher ratios, very, very good scores on the tests, that kind of thing. Another angle on it was we're the ones making a choice to move across the ocean, we're the ones choosing to move our kids out of the US and go to a school somewhere else. I wanted them to be in a school that had an international baccalaureate program, which is recognized by universities all over the world. The public schools are good, they're NCEA, it's a New Zealand set of standards, but it's not necessarily the international standard. So we personally didn't want our choice to move to New Zealand to impact the options our kids had when they leave school. So we decided it had to be a school that had an IB program. And those are the private schools. Thank you. Shall we talk about lockdown for a minute? Yes, I was going to say that. So you talked about lockdown and we have maybe a few minutes as well for all the questions. If someone has any, please post them in the chat window. Yeah, let's just let's just let's just spend a couple of minutes on coronavirus and the lockdown. I'm wildly blown away and impressed with New Zealand's reaction to it. It may have been a little bit of time and coming in that we were reading news about the virus and and situations around the world. But boy, when they decided to do something, they sure the heck did it. So the whole country's been in lockdown for what three weeks now, we got one week to go before and the first initial phase of this thing. And they went all the way. I mean, everything's closed, everyone's home, the schools are down, businesses are down. When you walk the streets with the dogs getting a little exercise, everybody's going out of their way to pass within, you know, to not be within two meters of everyone else. We wave at each other, everyone's real friendly about it. But they took it really seriously. The messaging coming out of the daily meeting. By the way, if you want, at 1 p.m. New Zealand time, every day, there's a meeting from the Ministry of Health where they give the latest numbers. Go see Dr. Ashley Bloomfield, who is awesome. And it turns out there's a huge fan club that's forming here. And sometimes Jacinda's in there, they're really good. They're straightforward. They know their data. They speak to it really well. Jacinda speaks with a lot of compassion. Ashley speaks with a lot of competence. I should call him Dr. Bloomfield, I suppose. But I don't know, I'm falling into it a little bit. I've joined with the Ashley Bloomfield fan club, Twitter thing, and it's getting funny here. Anyway, the point is very competent, very good in a crisis, really good messaging. And it's really interesting to watch. If anyone wants to know what the government here is like and how they take these sorts of things, I highly recommend you sit down and watch any of these daily briefings. Okay, another question. There is no more questions in the chat window at the moment. I completely agree with that. I go for a run and people get away from me and I get away from them. It's super interesting. And that's been happening actually since before lockdown, which is also super cool to see. I have a question here. But before that, I just wanted to say that how I met Boyd, it was like, I have to... So my role in EHF is onboarding the fellows and making sure they apply for their visas and that everything is all good for them to come to New Zealand and come to their welcome experience. I haven't been hearing from Boyd lately. So I was like, what's happening with this guy? Is he coming? What's going on? Is he coming to the welcome experience? And suddenly when they're in the office, this guy comes up at the office in Wellington and says, Hi, I'm Boyd. I'm one of the new fellows. I'm like, what are you doing here? I just moved to Wellington. I already have a house. My family's here. I'm just waiting for the furniture. So that was my first experience with Boyd. So you can imagine how that had an effect in my life because it's been amazing to meet him and hang out with his family as well. So yeah. Okay. I see a couple questions here. I'll just answer them. First, I'll talk a little bit about Welcome Week. This is the EHF specific thing. Welcome Week is really interesting. It's exhausting. I knew it would be a week of talking to other fellows about their projects and their work and I got to share a tent with an awesome guy named Eduardo Martinez. Hi, Eduardo. I see you typing in there. But what you don't expect is that I'd say about half the time in the Welcome Week is getting to know the Māori culture and the Māori people. And that was really meaningful and moving. I don't know if you can hear kids yelling in the background, but they are. There's a lot of depth there and frankly exploring that has been one of the one of the joys I've found of being here. And I say it to people and they hear it, but you don't really get it until you're actually here and spending real time with them. Now there's a lot of knowledge and a lot of talent that is kind of latent there. I see a question about tax laws. My experience about income from the US and New Zealand, everything to do with US tax laws screwed up. I'm not kidding.  I still have to file and pay US taxes no matter where I live in the world and that's not true for almost anyone else. So my experience there isn't really going to apply. Thankfully there's a US-New Zealand tax treaty, which means that money I pay here in New Zealand I get to at least credit against my US taxes. And then as far as filing taxes and dealing with New Zealand tax law, everything's terrible. Like I was talking to my parents this morning on a call and I just filed like several hundred pages of US tax forms and I've got a two-pager that I have to file here in New Zealand. Yeah, everything to do with this sort of thing is just tremendously simple and straightforward and easier to deal with here. And you can mainly do it online, right? Yeah, you can mainly do it online. I know there's countries in Europe where it's easy. I'm looking for it. Let's see here. One, two, three. This is the business taxes. Three pages. Now I'm still going to use EY and Craig Riddle, who is awesome, to make sure I've done good tax planning for New Zealand. I'm not going to completely guess it, but it's just not that complicated. Okay. There's another question there. Boy, do you think both lockdown economic calls for out-of-the-box ideas and innovation? Have you thought of making any changes to your business with the changing global economy? My particular business, no, just because of the nature of it. I'm writing really deep tech software. I don't know if I really, I didn't really talk about it. I'm basically building an operating system here and its parameters don't really change based on the crisis. I know lots of people who are making changes. We don't know what the post-lockdown economy is going to look like. What I feel good about is that because New Zealand lockdown hardened fast, I think it's going to be locked down for less time. So it will bounce back internally a little faster. But if you're an export-focused business, then yeah, this is really a question about the global economy. And how is it going to be affected? How is it going to be affected by the crisis? And that's anybody's guess. Now you're interested in what you do is not need to find new OS code. You want to talk about your business? We'll have like five, a few minutes more. So we'll have some time. All right. So okay. Here's the real brief. Here's the take on it. I spent 18 years at Microsoft, 15 years on the Xbox team. I ran the operating system team for Xbox One. I ran development for Xbox Live and the developer program for Xbox. And you'll learn a couple things in that kind of a program. One, you realize that game consoles are really big, fat, hot, plugged in IoT devices and they've got security issues like IoT devices. Rather, IoT devices have security issues like game consoles. And a lot of the lessons that we learned the hard way are absolutely applicable to IoT. So effectively what I'm doing is I'm building a new operating system. No, it's not UNIX-based. I'm building it on top of a kernel called the secure L4 kernel, which is developed in Australia. And go look it up. It's very small. It's actually the most shipped kernel that no one's ever heard of because it lives in all these Qualcomm chips that are the radios in your iPhones and your Android devices. It's very secure. It's formally proven. It's really hard to program to. So in a way, think of what I'm doing is I'm adding a layer above secure L4, which brings back a lot of the services that you would expect in a larger kernel and makes it easy to code while maintaining the security aspects of secure L4 and the speed. So that's what I'm trying to say. It's actually pretty nerdy. That's great. We have a boy talking about one in John and about his move in one of our orientation days that we organized for, we and the city councils of different cities in New Zealand organized for the fellows to get to know the cities and get to know New Zealand and the different ways each region can support their job of the the work that they are doing. And it was really amazing to hear him. And I think just to finish, boy, I want to ask you your story about dairies and what you can tell us about about the Kiwis line and all of that just briefly. Paula, which story about dairies? I will leave it to you. I'm sure you can choose the best one, but I just remember briefly something that you said and where you find things. I know I was there in New Zealand. Yeah, yeah. Look, there's, there's lots of things that are just similar and yet different. I'll say coming to New Zealand, it's a lot like walking up a flight of stairs. You just know how to do it. It's familiar, except every once in a while, one of those stairs is too high or too low when you trip and you fall on your face. Right? Dairies is one of those. Like I'm talking to my friend, Mahi, and he's, he, we need this notebook or some paper or pencil or something. And so he said he was going to go run down to the dairy and grab one. I'm like, okay, that's kind of weird. And I saw an article in the New Zealand Herald talking about some guy held up a dairy with a knife. And I'm like, imagining what he's going to point the knife at a cow and say, give me all your money or best he gets it. Right? No, no, a dairy is a corner store. Yes, they sell milk there, but they sell everything there. Right? They've got paper and vegetables and wine and beer and baking supplies. Okay. So now everybody in the family, we're all calling it walking down to the dairy to get some toilet paper or whatever, right? So yeah, so dairy is one of those, one of those words that is a very Kiwi thing.  Yes, thank you. I'll save the other dairy story for another time. Yeah, that sounds good. I'll see you later, laughing there. Yeah, he knows what I mean. Thank you so, so much for being amazing to have you and it's amazing to, to. Can I have one more thing? One more dairy thing? Okay, this is a legit surprise. In Seattle, we had found a great brand of yogurt that we fell in love with, like the couple of years before we left. Really good Greek style yogurt. Finally, like the best yogurt I've ever had. And we legit had conversations about how that was one of the things we were going to miss about Seattle. You land in New Zealand. We found the first Greek yogurt we tried. It was a, it was called Puhoi, Puhoi natural Greek yogurt.  This is great. New Zealand has a very strong dairy industry and it's tuned differently than what I'm used to, right? They have actually bred the cows for low water content, high milk solids. And this is like milk that I have never had before. It's all the dairy products are fantastic. The yogurt's fantastic. It's, it's actually really good. And that I know it sounds like a pitch, but it was a legit surprise about coming here, right? Did not expect to find the dairy industry that is here. And this is the other dairy industry, not the one that sells toilet paper. Yes, I agree with that. Okay, sorry. Beautiful. No, that's fine. It's all good. Thank you so much everybody for joining us. It's been amazing and having you here and I just posted on the chat window the new fringes website so you can have a look that we have our coming sessions coming up many different ones and we want to hear from you if it's anything that you want to let us know that we should be looking at to hosting. Tomorrow we have one more brandy commissar which is a new fellow. Next week we have Emily and Eric talking about their, how was for the setting up the business and many more coming. So thank you so much for coming and just to finish, I will show my screen and show you the last things about EHF and different years. So thank you so much. Applications are open until the 1st of June. So it's the last opportunity to apply for EHF this year. So pay attention to that and there's webinars coming up for you as well. Thank you so much and see you in the next session. Bye bye. Ciao ciao.


Welcome, everyone. Quick note, the session we'll be doing this morning is improving code quality with static analysis. The original talk, which was what type of testing is good for me, has been replaced by this one. So we will be talking about a type of testing that's good for everyone. OK, great. So who am I? I've been part of the PHP community since 2003. I'm a senior developer at Digital Bridge in Chicago and back in the States. Our focus is on making a difference for mid-sized companies in the B2B space, particularly for those who are located in the Midwest area in the States. Therese kind of inspired me with this talk yesterday to call out those who have been an inspiration event part of helping make Drupal great. And so I wanted to make a quick note of appreciation for the people who have played some role in inspiring myself. So thank you. And those who aren't listed, you know who you are, and I appreciate you all as well. So who are you? I expect that you are someone who appreciates quality code or you're someone who maybe you're not fully aware of what exactly is the difference between good and bad code. You're in the right session because we'll be talking a little bit about what good quality code is. And our key takeaway today is going to be what exactly is static analysis? And we're going to talk about ways to change your process to improve the quality of work that you all are doing. Before we begin, I want to tell a quick story. So how many of you use spell checkers? You probably do. Your browser has one baked in. If you see a typo in an email or many typos, you probably wonder why they were creating typos. We tend, as humans, we tend to not trust if there's a whole bunch of typos. We expect like there's something going on or what have you. This picture here shows a parking sign that says private parking only. All others will be towed. The word towed is T-O-A-D, which is, of course, the frog, not actually towing your car. We're pretty forgiving. Like we understand this is probably a joke, or if it was a typo, it's pretty funny. There's sort of a legend called typoglycemia that is kind of on this topic. And the general idea is if you switch the letters in the middle of a word, you can switch those around and we'll still understand what it is you're talking about. As you may have seen some articles online that kind of reference this idea, which is really cool. So I've typed here, who needs a spell checker? But all the words are scrambled. You probably read this and knew exactly what I was saying. Well, the problem here is computers aren't so forgiving. So let's go back to 1962. This was when NASA was preparing for their first interplanetary vehicle launch. At that time, it cost about $18.5 million. Today, there would be about $150 million US. What happened during launch is the guidance system was improperly responding to commands sent from ground control, and it was overcorrecting. So what happened is within five minutes of launch, they had to detonate the vehicle for fear that it would land where boats are passing by or in a populated area. The reason for this was actually a transcribing error. See, this is back in 1962. There were people actually writing down equations by hand. And there was an overbar that was missing from one of the equations. So that overbar basically meant to use a smooth value instead of the raw values. So what was happening was the raw values were being sent, the trajectories being over compensated for, and the rocket went off track. This is known as the most expensive hyphen in history. The problem with computers, they do exactly what they're told. No more, no less. This is also one of the brilliant parts. Now let's fast forward to recent times. Those of you who program, I assume most of you work with code to some degree, this is not PHP code here. This is a bit of code from back in September of 2012. These lines of code here were released in iOS and OS X. This was not fixed until 2014. So it took 17 months for this problem here to be resolved. If you know a bit about code, you would know that this would actually be executed like this. In other words, the lines of code after the second go to fail wouldn't be executed. These lines of code are in the context of validating SSL or TLS connections. So what ended up happening is, while this vulnerability was out there, anyone who understood this bug could perform a man-in-the-middle attack. So they could essentially decrypt any SSL or TLS connection happening on Apple devices. A major security flaw. This is how this ties in to what we're going to talk about today is this bug that we just saw could have been caught by static analysis. Some computers, like computer languages like Golang, they already have some compiler-level errors that will trigger for things like unused variables. Or some of them even have opinionated formatting for code. Like Golang also comes with its own formatter and forces you to use curly braces in some cases. The problem with PHP, as most of you all know, is PHP will execute most anything. JavaScript is even worse so. The point today is if you're not using static analysis, you're wasting time.  So if you all do code review, you might be sending PRs back and forth or in the Drupal issue queue, we're doing trivial back and forth on, oh, here's a space that you need to insert here. Or we might be doing bug resolution for obvious problems, typos of variables, dead code. Dead code is basically in the go to fail example where you have code that's not even executed. Another example of how we're wasting time is the grind on poor code or complex or highly coupled code. The reality is we don't have time for this. And if we focus on training or if we all just configure editors to do this type of configuration, the reality is we're not perfect. We're going to miss something. So today what we're going to talk about is what is static analysis? We'll talk about some of the things that static analysis can find using real examples. And then lastly, we'll talk through how to adopt continuous inspection or how to adopt static analysis on the projects you're working on. So what is static analysis? Static analysis is essentially anything that you can do, anything you can learn from code without executing it, similar to a spell checker. You don't have to know the content of a legal document to understand that TEH was probably the misspelling of THE. Similar to code, we can do things like this. Let's go back to the go-to fail example. If we were running Drupal's code standard and PHP mess detector on this, we would get a couple of violations triggered by those tools. One example would be that the hash handshake utilizes a go-to statement. PHP mess detectors suggest not using go-tos. Inline control structures are not allowed. This is part of our Drupal coding standard, in part for this reason. Because if you had curly braces, it would become much more apparent that any lines of code preceding that aren't going to be executed. Another one is indenting Drupal coding standards we have standards for indentation. So it would have been much easier to spot this second go-to fail. And there's many more checks that are available. So how is this done? The way static analysis works is essentially, it scans your file system for code, and it looks for patterns. So it's not magic. It's simply looking for these predefined patterns. If you're using an editor like PHPStorm or Sublime that's configured with PHPMD or DrupalCoder, you're probably already using this. What we're going to be talking about, though, is how, as a project, we need to make those checks more visible to the whole project. And we'll show what that means and how to do that later. So tools in the PHP world for static analysis checks, there are many. Here's a couple that are pretty popular. PHP code sniffer. If you use Coder, probably many of you have, Coder is built on PHP code sniffer. There's another one called PHPMessDetector. MessDetector is used for looking for things like calls to static variables or access to globals. Copy and paste detector. If you utilize the dry principle, don't repeat yourself. We can have a tool automatically check for this for us. And then there's PHP lines of code and many others. And there's many others in JavaScript and other languages. So let's try this out. Let's look at a couple examples just to get familiar. So one check I mentioned was global variable access. This bit of code here, the bold line, shows access to the globals in PHP. The problem with this is we can't do things like type verification. We also can't verify that this input is clean. Any other code has access to this global state. Another example would be an unused variable or a method parameter. This one's really useful. Four cases like this. The first line in this method does an assignment of the variable entity, but entity isn't used anywhere. So why is this being called? That's really confusing. The idea is that these checks are to help us write better code. Now, what is clean code? I'll go back to advice from Grandma Beck. This is Kent Beck's grandma. There's a book called Refactoring by Martin Fowler. It's an excellent book, highly recommended. One of the chapters is talking about what is clean code and what are these patterns of good design. And one of the things he says is he goes back to his grandma who says, how do you know when to change a diaper? Well, if it stinks, if the diaper stinks, change it. The same principle applies here. Don't get too hung up on the specifics, just as someone who's passionate about code that's maintainable, easy to work with. If it stinks, if it's hard for us to work with, let's change it. So what can these static analysis tools find? Let's start with a general idea of what do we mean by good code. And I'm going to start with a couple general ideas about what these checks are doing. So readability, for example, how easy is it for you have someone coming out of the project. How easy is it for them to pick up the code, read it, and understand it? If you've seen anyone use single character variables, that's hard to read. It's hard to understand what's going on. Maintainability, how easy is it to bug fix and apply updates? If you're a maintainer of a project and you have to make changes based on bugs that people find, if those bugs are really hard to fix, then it's not maintainable. Extensibility, let's say you have projects that you're inheriting, and the client is asking for a new contact form, let's say. If that's really hard to add that contact form to the site, then it's not extensible. These are common things that we need to do. Security, how vulnerable is it to malicious users? Testability, how easy can we test that the behavior of the code is matching our expectations? And lastly, correctness, or in other words, bugs are technical at that. How efficiently does it meet requirements? So it's easy to write code that meets a requirement, but how efficiently does it do that? There's performance considerations in this. Let's go through a couple examples. And I'll pause in each one. If you have any questions, feel free to shout them out. But let's go back to that first example of global variable access. If you're using a global, it's hard to test because you have no control over the global state. So let's say when you set up this class and you execute do-load-multiple, which is probably gonna be accessed through another public method, you may run into a flaky test. What if another test has already changed that variable? Or what if there's code in between you setting it and the code executing it that's changing it? Another is this isn't sanitizing that input. Don't trust global state or extensibility. There's no abstraction here possible. If you want to subclass this value that's being passed here, you can't because it's just a PHP array. Unused variable or a method parameter. We saw this example earlier. You have no idea what this assignment of get entity is. It could be cruft, but also maybe there's some secondary effect that's happening in get entity and there's actually a really good reason why this is here. And by removing it, you introduce a bug into the system. But the reality is you don't know. Correctness. This might be a bug, right? There might be a reason that entity was assigned and we're actually supposed to do something with it in this method and whoever was coding this just forgot to use it. One quick note on this. So these checks are from PHP mess detector. PHP mess detector has a check for an unused method parameter. This is a problem in Drupal because we use hooks and a lot of times a hook parameter you don't use. So PHP mess detector, we'll talk about this later, but I've actually excluded that from the detector config that I'm using. But it's important to note this because that check is for Liskov substitution principle. So the idea is if you have two classes and you subclass them, they should be doing the same behavior. And if you're not using a parameter in one of your subclasses, it might be an indication that you need to better abstract your code in some way. Dead code. This one's pretty obvious. We talked about this one earlier with the go to fail. The problem is it's obvious to us, but actually finding dead code is kind of difficult. This example here, I pulled, I believe I pulled out of Drupal core, Drupal 8 core. This is a private function that doesn't get called anywhere in this class. So you see this and you ask, why is it here? Was it supposed to be protected so that it can be subclassed? Testability, you can't test this. So if you're trying to verify some behavior of this method, let's say code cut test coverage is an objective for your team, you can't do that. You can do it through some weird reflection, but let's not go there. Correctness. Code that isn't executed is usually a bug. Case in point, go to fail. But this is a really good example because there are false positives. If you're using static analysis, there are going to be cases where it throws a check when it's actually fine. The reality of this code sample here, it's actually a, can't remember if it's a subclass or a parent class, so it's actually calling this. So it's actually fine for this method to not be executed in the class itself because it's being called in one of the subclasses. Number of public methods. How many of you have opened up a class and said, whoa, I have no idea what's going on here? The reason number, so this is an entity type, this comes from Drupal core. There's a total of 69 public methods on the entity type. If you've tried to work your way around an entity type, you know why this is hard. It's hard to understand what all these methods are. Over time, you get used to them. But extensibility, it might be confusing. Let's say you wanted to create a subclass of this and maybe be hard to fully understand what exactly you need to be changing or overriding from the parent class. Correctness, if you have so many methods, it might be an indication that your class is doing more than one thing. There are cases where this is useful. It might be useful to have so many methods on the same class because you wanna encapsulate that complexity in your system into one class. Because the reality is, even if you break it apart, you still have that complexity, and it might be nice to keep it all in one class, but go back to the principle of, if it stinks, change it. We as humans can only understand so many problem spaces at once by dividing up a class and isolating the function of the class. It helps us as humans understand. Computer can understand this just fine. Use of statics. Drupal is not very good at this. So the problem with a static is you can't test it because you can't mock or test double. In this example here, workspace type, you can't create a double for that. So if you wanna test this function called add, this method called add, you would have to ensure that the workspace type class, its static method load multiple. If it has any indirect inputs, like inputs from a database, you would have to figure out somehow to provide a stub or test double in whatever its collaborator is. You can't just test double the workspace type class because it's a static. So testability, it's very difficult to stub or create test doubles for statics. In some cases, it's impossible. Extensibility. You can't replace workspace type with a subclass. This can create problems. There might be a case where you want to use a static if you want to control extensibility. So going back to that first slide we were talking about, what is good code? One of those things, extensible code is nice. There are cases where maybe you wanna control that extensibility. So use a static to force no one to be able to create a subclass, for example. Missing.commit. If you're missing documentation, it's a critical bug. This method is coming from, I believe this is coming from multiversion manager. Multiversion is a contrib module in Drupal 8. You don't know what this is doing. Obviously it's calling doReplication, but why in the world would you have a method called update that then just passes the same parameters to doReplication? It's not immediately obvious.  It looks like it's just duplicating effort. So you want to remove it, but you can't accurately, without knowing the author's intent. Extensibility, how do you know, if you want to subclass this, how do you know that you've set up the subclass correctly? Because you don't know the author's intent here. Yeah, document your code. In-path complexity or cyclomatic complexity. I'll pause on this one for a minute because the words themselves can sound kind of intimidating. But the basic idea is pretty simple. The idea of in-path complexity or cyclomatic complexity is how complex is the computation in this function, or in the method, in the lines of code being executed? So cyclomatic complexity, I'll start there first. Basically what you do for cyclomatic complexity is count the number of control structures in a function or in the lines of code. Control structures are like if statements, switches, for each loops. The more of those there are, then the more of different paths through the code there are. In-path complexity is a little different. In-path attempts to understand every single individual path through the code. This method here has a cyclomatic complexity of 15 and an in-path complexity of 420. Computers handle this fine. That's not the problem. The problem is us. The problem is the human element of this code.   Unless you wrote this code, or even if you did write it, and it's a month later, A, you've probably already forgotten your original intention because it's so complex. And B, we might be able to take 420 independent paths. We might be able to hold one or two of those paths in our head, but understanding all 420 at once, nearly impossible, probably impossible. So readability, it's hard to understand so much complexity. It's hard to debug and correctness. If you have so much complexity in a single method, it may be an indication that you're violating the single responsibility principle. So it might be an indication if you see high complexity value, that you may wanna break that code out into multiple methods or functions. Going back to what I said earlier, there might be cases where you wanna encapsulate all that together. I noticed in the Drupal code base, there's an archive tar. If I remember correctly, it's like one file with a whole bunch of code, and it's highly complex. But maybe that's okay, because maybe you just wanna encapsulate all that complexity into one place, because you have it working and you wanna forget about it. Maybe that's the case. But going back to what is good code quality, we have to maintain that. There's eventually gonna be a bug in that archive tar and somebody's gonna have to go and figure out what's happening. It's easier for us to understand if it's not as complex. E-Ferrent and A-Ferrent coupling, I love this metric. Essentially what E-Ferrent and A-Ferrent coupling are is an evaluation of how many other classes know about your class, which is A-Ferrent and then E-Ferrent is how many classes does your class know about? The idea is, take this example here. This is multi-version manager. It knows about 15 other classes. So if any of those, think about it in terms of likelihood of change. If you're aware of 15 classes, there might be a high likelihood that any of those are gonna change. This means that any of those 15 classes might cause this class to have to change its behavior as well. High coupling or close coupling means that anytime you wanna make architecture changes, it's gonna be more difficult because there's more classes that you have to understand how that behavior changes. So extensibility, it's hard to change. Testability, I dare you to try to unit test this. If you try to unit test a class that has 15 other classes, more than likely you're gonna have to create a test double for each one of those classes. And let's say the class has 10 methods that you need to test, that's creating a test double in each of those situations 10 times. That's a lot of work. And correctness, if your class knows about so many other classes, it might be an indication that your class isn't doing just one thing. Now, this is a little unfair because manager classes are kind of the intent for encapsulating some of this complexity. But again, going back to what does code look like that's easy to work with? It looks not like this, it looks like loosely coupled code. So, we've gone through all the examples. There are many more examples we could have gone through, but how do I apply continuous inspection or static analysis to my project? How do you get started today? I recommend a tool out there. It's actually a cloud platform called Code Climate. It's free for open source projects on GitHub. Unfortunately, when they say free for open source projects, what they actually mean is free for GitHub because Drupal, Drupal.org, anything on Drupal.org is GPL, so it's gonna be free open source, but they only support URLs, it's like URL-based, so you have to have a Git URL that's from GitHub, unfortunately. But we'll look at some examples. What I like about Code Climate and the reason I'm gonna use that in some of these examples is because it's just an abstraction of PHPMessDetector, PHPCS, and whatever other static analysis tool you want.  A couple alternatives to Code Climate would be Scrutinizer.  But again, we'll use Code Climate because I think it encapsulates the idea of workflow really well. Quick notes on how to configure Code Climate. Take a look at github.com slash Joseph D. Purcell slash Code Climate and Drupal. We'll look at the example real quick. Basically, you specify what engines you want, in this case, we're using PHPMessDetector, PHP code sniffer, and then there's a rating section. Code Climate has what's called the GPA. The GPA is essentially a weighted value of how many errors do you have per line of code? And then they exclude pass. You probably wanna exclude config. This is an example of a Drupal project, so you wanna exclude Drupal core so that you can focus just on your own custom code. The second thing I've done is, I've created a modified version of PHPMessDetector config. This is also available on the github project. The reason for doing this is, unfortunately, out of the box, PHPMessDetector more than likely is not gonna be a good fit for you. One reason being, it has camel case checks. Not everybody's using camel case, so I've customized it for that as well as static checks, et cetera. So there are two main ways to use static analysis on a project. One is what's called continuous inspection or basically tying checks of code style or security vulnerabilities or what have you into your development workflow. So every time you check in code, some awareness is brought to you about what violations have been introduced. The other would be what's called a code audit. A code audit would be anytime you pause development for a second and run inspection and take a look at what does the code base look like? Where's the complexity? Are there ways that over time we've introduced maybe some architectural incorrectness? Looking at the first one, this diagram comes from Continuous Integration. It's a book written by Paul DeVall. Very good book. Essentially it's talking about at what point you tie in static analysis into your development workflow.  So when you run automated testing, you should also be running inspections. If you're not running static analysis with your tests, then you're missing a critical part of continuous integration and you're wasting time. So what does this look like? Daily workflow would look something like I commit, push my code, automated tests and static analysis run. If the test fail or static analysis has introduced some violations to build fails and whoever was contributing that revises the code. If it succeeds, then code is reviewed and it's merged. Here is a poignant example of why static analysis is so nice. Aidan Feldman over at ATNF, they're using Code Climate on their open source projects. This is what a poor request looks like for him. All checks have passed. This means I don't have to look through any of the code that was introduced for code style violations. I don't have to spend a single second on it because I know that those checks have already been run. That's amazing. Now if there were violations, it would look something like this and you can click on the details button and what's so nice is with Code Climate, it's only showing you violations that were introduced for the code that was committed. If anyone of you have used Gulp or Grunt and tie in ESLint into your build and all those lint violations print out for everybody's code, it can be kind of annoying because somebody else introduced a CSS file that is throwing all these violations. That's not your fault. You're trying to get your work done. What's nice about this is it only shows your violations that you've introduced. So you click on details here and it'll take you and on the right it'll categorize the violations. I mentioned earlier that you're gonna have false positives or yeah, false positives. Code Climate will allow you to silence false positives. Take that dead code example. You could click, there's a button. I think it's the I with the line through it. You can click that and it'll hide that check for all sequential runs. One thing to point out again, the GPA in the top right corner, what's also nice is if someone creates a pull request, you can see a weighted average of how that's affecting your overall code base. I could be a project manager and I look at this and I see that it's decreased our GPA by a whole point. I would throw up my hands and be like, look, like what's going on here? Why is this work that you've done been so incorrect according to the rules that we have established and identified as a development team? So I don't need to, again, like going back to the, I'm proofreading a legal document. I don't need to know anything about the content and if I see a whole bunch of spelling errors, I'll probably ask you about it. Anyone could do this here. So the importance of bringing these static analysis checks out to the whole project team is it's one thing for me to know what violations I've introduced into the code. It's another for us to all be aware of them. The second way that you can use static analysis on a project is a code audit. You might use this for planned refactoring. There's a little bit of a myth that you can iterate from a bicycle to a race car, but the reality is each stage along the way, your architecture, like the fundamentals of the system will need to change. So you might experience high coupling or high complexity in places. Take time on your project to plan for those refactorings. Or you might use this information during sprint retrospectives. So your project manager says, hey, look, I know you guys have been under a lot of pressure. Our GPA is declined by half a point. Can we talk about what it is? Like are they code style violations? If so, maybe we could get an intern to pitch in and help out with those code style. I'm gonna use an example. There's a tool that I haven't mentioned yet called PHP Metrics. Go to phpmetrics.org. Fantastic tool. PHP Metrics will run several, it'll generate several different types of information for you. And it has a really nice graphing tool for you. And they also have some good documentation. If you wanna learn more about these code metrics, PHP Metrics is a good resource for that. I've generated this graph to show a couple of ways in which a code audit might be helpful. On the y-axis or vertical axis, I'm showing cyclomatic complexity. So the further up the y-axis you go, the more complex it is, the harder that code is to understand. Moving along the right on the x-axis, e-frant coupling, this means the more code that this class has to know about. So I've run this on Drupal 8. This is actually a bit dated. I think I ran this several months ago. But what's interesting is, I mentioned Archive TAR earlier. Highly complex, there's no coupling because it's not including any other classes. But if we're gonna talk about places where we might wanna do some refactoring to make it extensible, to make it more readable, that might be a good place to look. How many of you have worked with Entity API? Yes, we have worked with Entity API. How many of you have found it challenging at times? Yes, I assume we have. You know, looking at places where, let's say Drupal 8 has code audits. We can point right here and show where the complexity is. There's several Entity classes right here that come up as they know about a lot of things. Why? Why is that the case? Why is there so much complexity in these methods? These can indicate to us places where we might wanna devote some time. Bring in an architect to dedicate some time. Hey, look, looks like Entity Manager is using 49 other classes. Is there an abstraction we can introduce here? What not to do? Static analysis is, in some ways it's very simple and in other ways it can be really complex. Even just from a human communication point of view. Cause that graph I just showed, if you don't understand what those checks mean, it might be misinterpreted. So, static analysis is only as good as it's configured to be. One of my criticisms of code climate is, at least in my opinion, it doesn't make very clear, don't just run code climate. If you're gonna use code climate, you have to take that code climate YAML and reconfigure it to exclude certain directories and configure the engines to run only the checks that make sense for you and your project. And if you're gonna use PHP Mest Detector or PHP Code Sniffer, take time to edit that config to accommodate whatever your team is, whatever you say is correct code. Static analysis is not a replacement for your brain. Even take complexity, for example. I come to you and I say, hey, there's a complexity of 15 on this method. Go refactor it. No, have a conversation. There might be a really good reason that complexity is there and you may choose to defer that refactoring to another time. You might say, oh, well this sprint, we've introduced that complexity now, we're planning on refactoring later, et cetera. And some indicators are okay. Just because someone creates a pull request and there's 10 new violations, that doesn't necessarily mean it's incorrect code. It means that the checks that you're checking for have been triggered. Now, whether or not those are acceptable, use your brain. Use your own intuition and understanding. Don't compare GPAs of projects that use different configurations. So GPA, again, is kind of like a weighted average of how many errors per lines of code. If two different projects are using different configurations, they're gonna have different violations generated. So those weights are gonna be different. So if you're looking at GPAs, be cognizant of how those GPAs were generated. Don't avoid static analysis because there's too much to tackle. Clean code is hard work. It's hard to take the time and effort to identify something maybe as tedious as writing a code sniffer check for a curly brace. But the reality is, once you've done that work, you can run it repeatedly. It does the heavy lifting for you. We go through a lot of code, especially if you're doing code review if you're a project maintainer. Static analysis is gonna help you in the long run. And don't run static analysis locally. They should be shared just like tests. If you're running automated tests, chances are you have people configured to send alerts to when tests fail. The idea is build awareness of what's happening in the code. Tie in your project manager. They can help you. And hopefully they're supporting you in that if you're under pressure or maybe you're doing some exploratory work, they might be able to help you to give them an indication of you might need more time or maybe you need to change approach. Overall, the cost of owning a mess means that your productivity is gonna decline. So the way that static analysis is gonna help you is it's a tool to help you maintain what is good code for you. This diagram here comes from Robert Martin's book, Clean Code. It's a very good book, I recommend it. The reality is when we write code, there's an entropy to it. Over time, we introduce errors, the architecture of it changes, et cetera. The Linux kernel and Windows server teams are using static analysis on their projects and there was a research paper that was done. And what's interesting, they've found a 50 to 60% correlation between static analysis checks in a given module or file with bug reports that were generated later on. Essentially the idea is these checks aren't just good code, they also have an impact on your users and your stakeholders. The savings of static analysis are you're not wasting time looking for code style. Go back to that poor request example. I didn't even have to look at the code view to know that there weren't any violations introduced. You're not worrying about obvious bugs or typos. You can clean as you go. One of the things that's really difficult in Drupal is we have thousands of tickets open and we want to, you open up a file and there's missing documentation or you change one part of the file to be compliant to coding standards but you're encouraged to not change anything else because you might impact another ticket. Doing something like what code climate is allowing us to do of just checking the one patch can allow us to do clean as you go. And it also exposes during code audits, it exposes the parts that are hard to change. All right, so what's next? I assume you all are excited about static analysis and how it can be of benefit to your projects. There are a couple of things that I see that might benefit us as the Drupal community. One would be agreeing on the static analysis config for D7 and D8 for core, contrived and any projects that are built on Drupal. This is gonna allow us to have, like if we wanted to use GPAs for contrived modules, we could do that. If we standardized on what those PHP mass detector checks are, what is Drupal's threshold for complexity? Our static's okay. Right now, code climate does not support any other domain besides Drupal, or besides GitHub. If they supported Drupal.org, that would allow us to not rely on the Drupal's infrastructure team to have to support this tooling. Code climate could easily do this. Start using static analysis on corn, contrived. There's a ticket out there right now that talks about this. There's not a lot of activity. Go take a look. Add GPAs to compare contrived modules. Right now, when we compare a contrived module, it's usually somebody told you it was a good module or you've used it before and had success or you're just looking at how many downloads it's had and how many open tickets. Using a GPA would be a way, at a glance, we could get some feel for how well does this module adhere to what we're saying is good code in the community. Imagine if every PHP or Drupal vulnerability, security vulnerability, gets a check written for a PHP CS. That's incredible. Automatically, we could run those checks on every module, on every file and core, on every Drupal project that anyone has. We could publish that code sniff and everyone could run it in an automated way to see if their code has a violation. Ruby's Breakman does something similar for this, for the Ruby community. Imagine if we had automated code quality spike tickets for any time it's security vulnerability or project drop below a GPA. This would encourage the Drupal community and projects to pause and take time to go back and maybe decouple code where there's a lot of complexity or you just throw a bunch of classes in a file or in like a manager or something and maybe we could take time to refactor and use these checks in an auto-correct. If you've PHP Storm uses PHP Code Beautifier and Fixer, basically what it does is it takes those very same static analysis checks and in the checks there's a way to say, okay, here's the check and here's how you fix it. So what's kind of cool, imagine down the road, not only could we generate a security vulnerability sniff that goes out, analyzes all of core, all of contrib, all Drupal projects everywhere and it has, here's how you change it. We could do that. Lastly, one idea would be to write a Drupal project analysis engine for Code Climate. I mentioned Code Climate is a platform so you could write your own engines for it. Before we go, static analysis, it's gonna save you time but the reality is, it's up to you to take on the initiative of writing clean code and promoting that. This slide is actually a pitch for another talk that if you know Zendoodles, Andrea Soper, we gave some talks last year on technical debt. It was titled Technical Pollution, Insights from the Lurex. If you know the story of the Lurex, you know the Lurex is talking about, the one story comes in and he's polluting the environment, cutting down all the trees and one of the things he says is the trees have no tongues and the same way Code doesn't have a voice, projects managers, stakeholders, the people who are paying the bills, more than likely they're not understanding the code as well as you are. You are the Lurex. You are the one who's speaking for the code.  Take time to clean up your code. Thank you. Come to the sprints on Friday. The slides are online. If you want help setting up PHP Mestetector or PHP Codesniffer, whether it's on your own editor or setting up on your project, let me know. You can find me on Twitter at josephdpercell.com or josephdpercell. I'd be happy to take time to do that. I'll also be at the sprints on Friday so we could sit down then. The last slide has some references and reading. Are there any questions? All right. Oh, yes, go ahead. Ah, yes, SonarCube. I have not used SonarCube. It sounds really cool. I hear they have a set of checks just for Drupal. So do you worse checking out SonarCube? I personally haven't. I believe it's a pay for service. It's free? Okay. Ah, I see. Yeah. Really? Yeah. So what it sounds like is SonarCube gives some different types of functionality for prioritizing some of these checks that are found. Yeah, that's cool. I'd heard of SonarCube. I didn't realize it was, it's free for... I mean, you can install it on your server. You can install it on your own server? Okay. Yeah. Well, that's cool. Any other questions, comments? Yeah, so the question is essentially you have, like take Drupal's community, you have thousands of tickets open with patches already out there. So what's the cost of making these changes? This is one of the challenges of community-evolved development. I don't know. What is the impact of not making these fixes? The impact is, as I'm sure you all have experienced is you open up a file and it's like parts of it are inconsistent. So what's the cost of that versus going in and fixing it and having 10 other patches updated? I don't know. I think it's worthwhile. I think that the reason it's being used by Linux Kernel and Windows Server, for example, as well as some community projects is because of that, because it provides value longer term. It reduces the time that the people who don't have time, maintainers, doing review, it reduces the time that they have to spend looking for these problems. So I would pause it, it's worth it, but I have no basis for that. That's interesting, yeah. Incremental need. Okay, so the idea is, yeah, we have 20 checks, but let's start with one. Let's update one and go to the next one. I like that. Yes. So on the Git project, I've actually tried CodeClimate on Core 8.1 and 8.2, as well as some various contrived modules. And then I also tried it out on WordPress, and it was kind of interesting. My initial findings, it doesn't look to me like WordPress, here's to its own code style very well. But, yeah. Ah, October CMS, the built on Laravel? Yeah, it's built on Laravel, yeah. Yes. Like 7 is like a 1.5? Yeah. It's like, oh hey. So the commentary is, if you look at October CMS on CodeClimate, the GPA is very low, which goes back to how is it configured? One of the things I noticed looking at CodeClimate is there's all these open source projects that have CodeClimate ratings out there, at least on CodeClimate site. And then it's like, I don't know that they configured, like some of them I looked at, that had very low GPAs, they didn't configure CodeClimate. So going back to, it's only as good as it's configured to be. So in that regard, I've been a little disappointed by CodeClimate, but I know it's a hard balance of providing this great tool for anyone to use, and then they're not taking the time to use it, right? One of the things that, because I had a conversation with one of the folks that CodeClimate is around, a lot of them have Ruby backgrounds, so they have some really good input on Ruby, and what a base configuration makes sense for Ruby, but they're still working on base configuration for PHP. So right now, it runs all of PHP mess detector checks, which as I mentioned before, it checks for camel case. That doesn't apply to some coding standards. All right, I think that's all the time we have. I'll be around, come find me, find me on Twitter, I'll be at the sprints. Thank you all. Hey, thank you. Can I have a PHP phone? Oh, great.