Hello and welcome to KoopiFound. Next, we are going to share how to use cloud native service technology in the autonomous driving industry. I'm Benjamin Huo, and together with me is Xiuming Lu from UEC. I'm the senior architect of KoopSphere. I'm also the creator of Open Function. Xiuming is from UEC and the architecture of the autonomous driving cloud platform. Here is the agenda. Open Function is an unclinical fast platform. So the question is why we build such a platform in the first place and how to build it. So following that will be Open Function's introduction, including several components and the early adopters, contributors, the UDMIPE and the build demo. In the end, Xiuming will introduce how to use Open Function in autonomous driving. So why we need an open source kind of native fast platform in the first place? I think in the recent years, we have heard multi-cloud distributed cloud or hybrid cloud more often than ever. I think it is because Kubernetes brings the possibility of cloud agnostic. But as for the fast or service area, it's difficult to be cloud agnostic because each cloud provider has its own fast platform. Usually, these platforms are tightly coupled with each cloud provider's back-end services. So it's difficult to move one cloud from one cloud to another cloud for the service part. So it is possible to build cloud-native and cloud agnostic fast platforms. I think the answer is yes, because the new progress of cloud-native service technologies makes this possible. I think the most famous technology in this area is Kubernetes. But today, I want to talk about another true technology that is Diver and KDA. KDA is a great product to auto-scale applications on Kubernetes based on the different metrics of different even sources. So we can use KDA to decouple the auto-scaling of applications with many, many different even sources, including the open source even sources or the cloud provider's even sources. So this is KDA. We can also use Diver to decouple the distributed application with the underlying back-end services. For example, we can use Diver's PubSum building block to decouple the events and the sub-up events from the underlying messy brokers. So the user can use open source messy brokers such as Kafka or not streaming or they can also use the messy broker from cloud providers such as GCP PubSum or Azure Unibus. So usually for a fast platform, a fast platform should support several languages and they need to communicate with many, many different kinds of back-end services. So suppose a fast platform needs to support five languages and they need to communicate with 10 messy fields. And without Diver, each language has to use different SDKs to communicate with different messy fields. So this ends up with 50 implementations actually. But with Diver, each language only needs to use Diver SDK to talk to Diver and Diver handle the rest communication with other messy fields. So we only need five implementations in this Diver. So it has greatly reduced the complexity of fast platform. So it's like adding an additional layer between the fast and the back-end services. So Diver acting like a unified interface for the back-end services. Actually a couple of weeks ago, we have shared how we are using Diver in Open Function with Diver community. And the two co-founder, Diver Mark and Yaron, they are very glad to see the integration of Diver of Solaris function runtime like Open Function. So finally, what is Open Function? Actually, there are several three components under the function umbrella. The first is build. Now Open Function supports using build packs, cognitive build packs to build function source code into container images. And the other three Docker file relevant build technology can be used to build applications for now. Maybe we can also use them to build functions in the future. The serving part. The serving is the most important part in Open Function. Now we support P-sync runtime and sync runtime. For sync runtime, we currently support using NATIVE as sync runtime, and we are planning to support KDAI ADP as another sync runtime. Actually, we have maintainers contributing to KDAI ADP project. I think the most unique or differentiating feature of Open Function is the async runtime is powered by Diver and KDA. I will explain in more details later. The last component is Open Function events. It's kind of like KDAI event, but actually it is inspired by ARGO events with some differences. I will explain later. Open Function build. Whenever a function is created, it will create a builder, and the builder will create a ship-line build and build run. Together with the build strategy, ship-line will create a tecton task run, and build steps are created in the tecton task run and executed in order. This is how the function subcode is built into a container images. The serving part. As I said, Open Function can support the KDAI sync runtime and the Open Function async runtime. Both the sync runtime and the async runtime can use Diver, and the difference is for sync runtime, we only use the output beta of Diver component because the input is from the ADP. And for the async runtime, we use both the beta of input and the output from the Diver component. And KDAI is used to auto-scale the function, he said. In the future, we are going to support KDAI ADP as another sync runtime. And to speed up the code start, we are also considering using a pod pull method as another runtime. Whenever a function needs to be created, it will take already existing pod in the pod to start the function. So this way, the code start will be very fast. So this is the Open Function serving. This is the Open Function events. It is inspired by Agile events, but the difference is the event bus in Open Function events is decoupled with the underlying message broker by using paper pops up a building block. So user can use Kafka, not streaming, or any code providers, message queue such as GCP pops up, or Azure event bus. Whenever events arrive in the event sources, the event source can call a sync function directly or write the events back to the event bus. Whenever the events are writing to the event bus, it can trigger a sync function directly or user can define a trigger to filter the events they are interested in and trigger a sync function to write the filtered events back into the event bus. So this is in Open Function events. Another important component is the function framework. The function framework, actually this is inspired by Google Cloud Function and we have our own function signature here, both the sync function and the async function can use the same function signature to define their functions. There are several components here. You can see the contacts, plug-in, the runtime, and the framework. The framework, of course, will read the function context and register the plug-ins and create the function runtime. And finally, we will start the function runtime. Whenever a sync function or async function is triggered, the framework will first execute the function free hook and call the user functions and execute the post hooks and finally process the function output. We add, you can find more details in the links below about the proposal and how the function implementations. We add the plug-in mechanism here because we want to support function tracing. Function tracing function performance is important to a fast platform. So let's take an example here. A user sends an HTTP request to a sync function and the sync function will then publish some messages to the Kafka server via a diaper set card. And whenever a message is published to the Kafka server, the async function will be triggered through the diaper set card subscription. So for use cases like this, the user need to know how long the sync function takes and how long the async function takes. So we have, in the last couple of months, we have worked with a skywalking community and user can simply add the tracing like this to the function annotation. You can see there here is the provider is skywalking and the OEP server and some tags. Of course, you can add this tracing configuration into a Kafka mic and that way, the tracing will be valid for all functions instead of all functions. So if you add the tracing configuration to the sync function and async function annotation, you can see a construct in this skywalking UI like this. And you can also see the tracing data here. Below here is the skywalking official site. There is a demonstration of the integration here. Here you can see the function score stack and the tracing data here. So this is the open function tracing. It's already adopted. Actually, one of the major telecom companies in China is using open function to build their fast platform now and UC is using open function to process our high-core data. There will be more details later. And Chunxiang is a local platform and they are using open function to implement the vlogging mechanism. And we have also contributors to writing the download function frameworks. They wrote mine. Next, we are currently going to support the Go function frameworks very well. And next, we are working on the other languages, function frameworks. The UC team is contributing to the Node.js and Python function framework. And we have also planned to adding the Java and download function framework. A few days ago, we have discussed with Dapper and Cookus community. The Dapper community will add the Dapper support to the Cookus environment. After that, we are going to support running Java functions in the Cookus environment. It will be much faster than the ordinary Java function. And also, we are going to support the sync function with KDAGP. Besides the skywalking, we are also planning to add open time which will add another tracing provider. And also, we are going to support the open function console. So this will work well in the future. So this is the load mine. Next, I have two demos. I have two demos here, and for the time reason, I only demonstrated the second demo. The first demo, I can explain it a little bit. Actually, you can use Flambit to forward the Kubernetes log to Kafka server. And we can define async functions to consume the log from the Kafka server. And whenever the async function finds the error, it will send an alert to the slack. So we can take a look at the function code and definition. So the logic is pretty simple. Whenever the 404 error is found in the demo product name space for port or price, whenever this three condition matches, the learn manager alert will be defined and will be sent to the notification manager. And let's see how the function is demo. This is how a function is defined here. You can see here is the build stuff. Here, using these settings, a user can build the function source code into a container images. And you can see the runtime is async. And also, the skill options from KDA can be the main replica or max replica in the cooldown area. So how the skill will behave like this. The most important is the KDA trigger, how the function is triggered. The function will watch for the last topic of this Kafka server. And whenever the consumer lag is over 20, it will increase the replica. Yes. You can see a function has input and output. The input is from the Kafka's receiver. And this is the deeper component defined here. You can see this is the topic we are watching for and the Kafka server and consumer group, et cetera. The output whenever the error is found in the function, it will send the output to the notification manager here. You can see it's just a URL. So this is the first demo. I will now do an actual demo. So let's go directly to the second demo. This is the tracing example standard request to a sync function tracing trigger async function. Let's take a look at the function code. You can see here, it has the same signature context and the payload retrieved the payload here. Whenever the payload is retrieved from the HP request, it will send the payload to the RB, a grading target. Let's take a look at the functions demo. This is a sync function. This is the build part, how the function is built. The scale options, how many marks there are bigger. The runtime is in detail. Because the input is a sync function, the input is from the HP. So it only defined the output. The output is a Kafka server similar to the previous one. The Kafka server is defined as a demo component here. And this is the Canadian stuff. So this is the first function. And the async function, you can take a look here. The Kafka input. Here is the async function code and the same signature here. You retrieve the message from Kafka and just print out the message. So this is the async function. People look at how the async function is defined. The build stuff and the runtime, the async. The key does the scale options here. The same. And trigger. It will watch for the simple, simple topic here from this Kafka server. And this one, async function only has input at this time. The input is also a demo component defined like this. And output is just the SE out. So it's needed to be defined here. So let's take a look. So already define the functions here. You can see here, this is the sync function. This is the async function. You can also take a look at the story. The story is also up and running. And you can watch for the... This is the async function. This is the sync function. They both scale to zero because there are no payload here. So let's trigger some payload on the sync function. You can see here, the sync function is starting now. The sync function is starting now. Let's go start and take a few... The async function always starts now. So we can take a look at it now. Async function is starting now and you can see the message finally. So this is the demo. Okay. Next, I'm handing over to Xiuming and Xiuming. It's yours. Thanks, Ben. Hi, everyone. My name is Xiuming Lu, an architect from UC, and I'm so happy to share a talk in Kubico. The topic I share today is the power of normal driving with cloud-native serverless technologies. Next, thanks. In recent years, the autonomous driving field has been growing rapidly and attracting a lot of attention. Cloud-native came to maturity and prosperity in the same period. It is natural for these two fields to join forces and explore a route for cloud-native to empower autonomous driving. I would like to start my presentation by giving a brief introduction to autonomous driving. Here is a simplified demonstration of autonomous driving interaction where users apply for a car from the app, take a car to the destination, and finally get off. In this classic and simple process, from the user's point of view, it involves vehicle monitoring and commands dispatching within authority framework. From the perspective of the vehicle, it involves a series of AI technologies, such as environmental perception, pedestrian avoidance, youth planning, chasing control, multi-vehicle creation, and so on. We need to ensure high availability, error traceability, scalability, security for our services and media. Next, we will start from the specific perspective of cloud agnostic fast to explain why autonomous driving needs cloud agnostic fast platform. First of all, cloud agnostic, one of the core technologies of autonomous driving is artificial intelligence algorithms and the reliance on data for algorithm enhancement and improvement is so high that the data has a high value and the customers are often reluctant to put data in the public cloud and instead use their own set of private cloud clusters. In addition, the flow domain cloud providers and infrastructure choices bring challenges to the upper layer of development. A cloud agnostic platform can make development smoother and save significant costs in the face of different customer honored server environments and constrained vendors. The second fast an autonomous driving is essentially an extremely complex IoT device with numerous types of sensors and suppliers resulting the need for multiple passing scripts and extremely large number of processing modules handled by multiple development teams leading to the introduction of different libraries and even different programming languages. This post is of text where modules need to be merged and refactored at a later stage. In addition, the amount of autonomous driving data is far beyond the reach of traditional IoT devices and the streaming analysis of large amount of data requires a tool that has great scalability. Finally the rapid development of autonomous driving also means that the logic of data processing changes frequently based on rapid changing industry requirements. Different weather size and business models requires different processing logic and we expect to find a fast-bladed way to replace the computational logic at a small granularity instead of modifying one line of code and requesting time to produce a full CICD for the entire service which always takes the day. In conclusion, we expect to have an open-source fast-platform based on cloud-native technologies for us to quickly get the solution of the ground to have control over the platform itself and to enjoy the convenience of cloud-native technologies. At this point, Open Function came into our view and introduced Dapper and KIDA as part of its foundation into the consideration. Next, we will talk about why KIDA matters. Automatic scaling is an efficient education strategy for results often acting in scenarios where data traffic is erratic which is exactly what autonomous driving needs. Autonomous driving can also be understood as an AI driver who replaces or assists the human drivers to do the job and thus to some extent it retains the work habits of the human drivers resulting in a potentially significant peak and valley effect on traffic. In the dialogue on the bottom right, we can see we have arranged different work patterns for the driver's vehicle according to an 8-hour workday. In some scenarios, the driving taxi is only one part of the customer's business, so there's no need for the vehicle to work 24 hours every day. In other scenarios, the vehicle needs to work 24-7 hours a day to maximize its capability. This brings significant traffic differences. Autonomous driving sensors tend to maintain a high frame rate of data appreciation for safety and data-like sensors generate a large number of data, so a small change in the number of vehicles can also bring out a significant swing in data traffic. Next, we will talk about why Dapper matters. We have already mentioned some of the cross- language requirements due to the many data types and processing modules. As seen in the sketch in the lower right, we wear the data passes through many modules in the car-to-cloud link, and as we talk about the next, Dapper is also very attractive for decoupling. On one hand the choice of mid-west is often limited by the customers, and on the other hand with microservice architecture, the code of establishing connections with mid-wares handling errors adapting to different patterns is written over and over again. Dapper's binding can solve this problem by obstructing into a unified specification. Shadow devices are an obstruction of physical devices in the cloud, and the code often uses shadow instances to complete the monitoring and control of the actual devices. And generally uses an synchronized architecture to handle side effects for performance reasons, and Dapper's PubSub record can also cover these usage scenarios. Next, here is an example of Next, please. Here is an example of using OpenFunction to solve a real-world problem in the autonomous driving field, archiving data with OpenFunction in a customers' private cloud environment. The functions in the diagram are all service functions that we have written and deployed in cloud-native fast platform like demo shows. In this workflow, the ChromeDrop or HTTP request are received as inputs and then passed to the first function, which splits the task and delivers sub-task to the message broker for driving other functions, which are responsible for handling subtext written in different languages. Those functions receive data as input in a byte array form provided by the fast platform. Receive data, including context, info and sub-task description, and then push a zip package to the S3 service after data collection, data masking, and data compression. And finally, exit it. No need to pay attention to the middleware connection, no need to pay attention to the language. It is convenient for each function to use the most efficient OpenSouth library and let programmers finish their job at the minimum level. What is more when data traffic increases, KIDA automatically scales up function instances based on the amount of data in the broker backlog, allowing developers to focus entirely on logic implementation. What is expected from a cloud agnostic fast platform we would like to have the following features. First, tracing and logging and metrics. New data needs to go through hundreds of modules and a dozen network communications before it can be archived in the cloud and errors may occur in any step. Troubleshooting is one of the most important problems in the development of an autonomous driving system. We need to create a unified tracing mechanism within a complex call chain because efficient observability in mechanism saves time and money. Robust system efficient error handling are important aspects of getting autonomous driving on the ground for the safety requirements. The second, plug-in mechanism and package management. This is an important feature to make the platform more powerful and easier to use. The third, alternative on the line technology and easy to use interface wrapper. The former ensures that no upper level development will be nullified due to dependent technology replacement while the latter ensures the efficiency of upper level development. Last but not the least, active and efficient maintenance team. Currently the cloud native service platform is in its early stages and needs a stable and effective maintenance team like open function to make the community more prosperous and to make better open South products. That concludes my presentation. Thank you for the time. Thanks to you. I think that's all our sharing. So if you have any questions, you can ask us online.


Hi, I'm Jenny Jennings and I'll be speaking about the benefits of a safe harbor plan design for 401k plans. In short, a safe harbor plan is a type of defined contribution retirement plan design that avoids any limitation on salary deferrals to the plan by highly compensated employees other than the annual cap on the dollar amount of contributions. The primary benefit of a safe harbor 401k plan is that the plan is deemed to satisfy the ADP test.


Summer 17, 40,000 of us jumped in house to open the corridor, 40 miles long, for the British tanks. Market and Garden. Market was the airborne part of the operation, consisting of more than 40,000 troops. Garden was the ground part of the operation, consisting of roughly 50,000 ground troops and armored tanks from the British 30 Corps. The only things this market was selling was air power, fire power, and a whole lot of freedom.


Welcome, I am calling the order, excuse me. Welcome, I am calling to order this meeting of the Arlington Select Board on Thursday, June 9th, 2022. I am Select Board Chair Leonard Diggins and I will now confirm that all members and persons participating on the agenda are present and can hear me. Members, when I call your name, please respond in the affirmative. Pam Mahon. Yes. John Herd. Yes. Steve DeCorsi. Yes. Eric Calmez. Yes. And it's just us tonight and Board Administrator, Ashley Meyer, who is participating, but not as a panelist. Tonight's meeting of the Arlington Select Board is being conducted remotely. Consistent with an Act signed into the law on February 15th, 2022, that extends certain COVID-19 measures. The Act, which includes an extension until July 15th, 2022 of the remote meeting provisions of Governor Baker's March 12th, 2020 Executive Order suspending certain provisions of the open meeting law. The Governor's Order, which is on the town's website in reference with the agenda materials for this meeting, allow public bodies to be entirely remotely as long as there is reasonable public access that allows the public to follow along with the deliberations of the meeting. Before we begin, please note the following. First, this meeting is being conducted via Zoom. It is being recorded and is also being simultaneously broadcast on HCMI. Second, persons wishing to join the meeting by Zoom may find information on how to do so on the town's website. Persons wishing to join by Zoom are reminded that you may be visible to others and that if you wish to participate, you are asked to provide your full name in the interest of developing a record of the meeting. Third, all participants are advised that people may be listening who do not provide comment and those persons are not required to identify themselves. Both Zoom participants and persons watching on HCMI can follow the posted agenda materials also found on the town's website using the Novus Agenda Platform. And finally, each photo tonight will be taken by roll call. So I will now turn to Mr. Helmuth who will motion us into executive session. Thank you, Mr. Chair. I'd like to move that we enter executive session for the purposes of contract negotiations with non-union M-Schedule employees, namely Mr. Sander Pooley, Sandy Cooler and that when we adjourn for the executive session we will adjourn for your select board meeting. Can I get a second? Second. I can. All right, so on a motion from Mr. Helmuth in a second by Mr. DeCorsi. I will be calling the roll call. So Mr. Helmuth. Yes. Mr. Hurd. Yes. Mr. DeCorsi. Yes. Ms. Mohan. Yes, thank you. And I vote yes. So we are now in executive, sorry, executive session.


The COVID-19 pandemic has negatively impacted Italian psoriatic patients treated with biologics during the lockdown period in March to May 2020. A telephone survey was conducted among 226 patients, revealing that 27.9% experienced worsening of their disease due to drug withdrawal, which correlated with increased anxiety, depression and stress levels as measured by HADS, PSS and BRS scores. No correlation was found between worsening of psoriasis and work activity. The study suggests that uncertainty about the safety of biologics and psychological factors can influence the clinical course of psoriasis during the pandemic. This article was authored by Federico Pirro, Giacomo Calderola, Andrea Ciracosi and others.


Good afternoon pastor David. Hey John. Welcome everybody to a random moment with pastor David unfiltered. Well pastor today's the last Thursday of the year. Yeah, and we're getting ready to ring in the new year just to plug in friends and family of our church We have our New Year's Eve service at 7 p.m. We have guest speaker Brendan Bealer and after our time in Bible study We're gonna have a time of fellowship open mic a time for posole So invite your friends and family would be a great way to ring in the new year with the church family with that pastor You know our 2021 has been in some senses a very trying year for a lot of people and at the same time We've also seen God's great hand it work in our church and wanted to get a little bit of your feedback when we reflect Back to this past year and and exciting to see what the Lord's gonna do in 2022 is our new slogan, right? Yeah, I don't know what the Lord's gonna do. I I haven't ever known what he's going to do I've never been able to get him to tell me so all I know is that what I plan on doing until the Lord says to stop is to To just do what I normally do here at the church, which is do my best to give a good Bible study and To shepherd the people that's the best that I can so Who knows that the next year Will be bringing to us John. I don't have a clue. I do know that That the enemy is working overtime To keep this nation in fear. I do know that fear is his greatest weapon You know and that He uses it and His mouthpieces are constantly spewing it and The thing that is concerning to me in this next year is how much more fear is going to be poured out on the people of the United States and The innocent and The naive seem to be giving in to an awful lot of propaganda So I don't know what's going to happen next year. I don't know if churches are Going to continue to be depleted. I Don't know if there may be a great revival. I don't know it may be the onset of a revival in that The churches that are teaching the word of God Even though numbers may not be what they have been in the past. I suspect that God has been purifying those churches Excuse me and I Think that the foundations that are being re-established right now even in our church are Going to have a Beautiful work that is going to be built on it. Yes, because I Was saying this the other day that I Prayed that God would give me a church that loved the word that God would give me a group of people who wanted to please him and we're generous in heart and Had a heart to reach out to the lost and Over the course of this last year. We've seen that We don't have the amount of people that used to show up anymore for a thousand and one reasons but I do know that those who are showing up right now want to be here and Those who are serving want to serve and So this upcoming year, I believe we're going to do more evangelism we're going to do more to try and reach this lost world and I don't know how long the Lord's going to give me to remain here as a pastor. I've Reached an age where I have to begin to wonder if it's a growing to the time where I should be stepping aside and giving it to somebody else I don't know that that's going to happen this year this upcoming year But I'm preparing in the event that it will I'm not planning on stepping aside, but that doesn't mean the Lord Isn't going to move me to do so. So I'm trying to remain Very open to whatever the Spirit of God is saying for us here at the church And so I don't know what 2022 is going to bring But I do know that I want to be prepared for whatever it does bring and I do want to be faithful and I do want to minister to The people that God gave me to minister to and that's about it That's what I'll do. Amen. And you know when leaving looking back past her to this last year. We celebrated 40 years We the milestone that we just celebrated on Monday as a church was your 51st spiritual birthday So we look back at the at the even in the difficult times where it was a difficult year but yet God faithfully had his hand on our church and And looking forward to what he's going to continue to do in our church this upcoming year And so yes, so we can look back and say what a Difficult year, but what a great year and what a great year. Hopefully that's going to come Well, you know, I think it depends on how we go about looking at what is great and what is difficult to be honest with you, John You know, I don't I don't see great necessarily as being Not that you're saying this by the way. I'm just responding to How I hear words sometimes I Don't know what great is in the kingdom of God anymore. You know, I think a lot of people think great is lots of people showing up and Enthusiasm and I think that that's great. I love that but sometimes they They seem to think that great is only when there are a lot of overflows or a lot of excitement And I don't see it that way and I've learned that because we've gone through 40 plus years now in this ministry and I've seen the church's plan expands the point of bringing chairs out and then we've gotten to the point where I have to remove chairs So I don't know anymore John 51 years has taught me that the only gauge I can have for whether God is moving or not Is for me just remain faithful at what I'm called to do and to sow seeds into people's lives and purrfully To see some of those seeds blossom. That's about it.  I Don't I do I do know that What I'm called to do is try and teach people and what I'm called to do is try to have a group of people in my staff That that do the same right so To try and reach the men to try and reach the women, you know to try and care for the children and the single moms and the fatherless little boys and those are the things that we do here and In some people's eyes, that's not very much and that's not enough. It's not exciting enough Other people's eyes. They say that is what the church is supposed to do And so when I think about what God wants to do, I believe that what he wants to do is He wants to work in us that we become more like your son, right? And so my desire is to try and encourage people to see that Not everybody cares anymore, John. Not everybody listens And that that to me is Something I'm concerned about Where people can stand in line to see a movie or go to a concert or stand in line to get on a plane and fly somewhere But when it comes to church, they stay home. They watch a little bit on TV Then they go do whatever it is that they want and say it's because of COVID. I don't know. So we're in a place right now Where I'm evaluating what ministry is and what ministry is here at this church and At this point I Feel that the Lord has done some very sweet things amongst us and But for me the way I gauge it is whether people are engaged with the Lord if whether they're growing Whether they're involved in Bible studies, whether they're serving God Whether they're witnesses in their community whether they have a heart of worship. That's kind of how I gauge those things so You know, I think we have a great group of people. I love them very much and I'm very grateful for them and I would like to see the Lord add to the church I would love to see people with the hunger to know God's Word to show up and We'll see what he does this year. There are a lot of churches in our area. It's not like there's only one or two There are quite a number of churches and I just pray that every church that's teaching the gospel and loving the people will be filled with people that That we can change this society and so this this nation can get back on the right track and May may God bless us this upcoming year to have a heart to reach more people and to train more That's the best I can say amen. Well, thank you pastor and we do look forward for the 2022 year, but you hit it right on the head, you know, what's the greatest desire? What do you want to see as people grow closer to Jesus Christ and Income back to church. Yeah, that'd be nice if they would I mean if they want to right I mean we've got we've got quite a number of people who watch us online and I'm blessed to be able to do that I really am I am so grateful for the online viewers because because they are watching and and I miss them I would love to have them with us and I do pray that this year perhaps they will come home Well, thank you pastor David and and again friends and family want to invite you guys to come out and join us on Chris excuse me New Year's Eve, which is Friday night at 7 p.m We do have a guest speaker and then on Sunday at 8 30 and 10 45 a.m Is pastors taking us through the book of Mark? You're actually taking us through mark chapter 7. Yeah, this upcoming week Yeah, and the encounter with the syrophoenician woman the syrophoenician woman also known as the Canaanite Which is an interesting when you do a little history Which I'll do it makes it more plain why it was So odd that she had come to Jesus. So yeah, that'll be good and so invite your friends and family It's gonna be a great study and and again. Thank you again pastor David for Leading us faithfully as a shepherd this last year and continue that you may lead us again and down the road will continue So thank you again friends for tuning in. God bless you and happy New Year


So the Yorubuffs drop in a few days, but there's a specific play that I haven't seen any of the Riot Devs talk about or anybody talk about or mention really regarding the new Yorubuffs, and I wanted to address it. With the current Yorubuffs steps that we have, you can anchor the steps down, and if you stand directly on top of your steps, you can actually set your TP on top of things, which makes for some really good plays. Because this play is, I guess, technically considered a bug, I know they talked about fixing a lot of Yorubuffs before he's dropped, so this play might get removed, I think they should just have it where you can set your TP on top of anything. But it's just something I haven't really seen a lot of people talk about, and I wanted to ask you guys what your thoughts are on it. And if Riot should keep this in the game, or just maybe even make it to where you can just set your TP on top of things without the steps. But what do you think? I'm going for it, Zach. I'm going for it. I'm going for it. I'm going for it. Trigger, Trigger. We're going to start hitting it now. What is that? One's back there too, one's back there too. He's got flashes too. Main, main, main, main, main. I got one, I got one. He's always on it. What? He's so lost, bro. I'm playing, I'm playing, I'm playing.  He's going for it. I just don't get it. She's here, here, here. She's here, here, here. She's backside tagged a little bit. She's not ready now. Oh my god. There's two here, there's two here. I got them. I'm serious, I'm serious, I'm serious, I'm serious, I'm serious. Up top here, here in this corner, in this corner. I got them. Flashing again.


We're going to be talking a little bit about the full process of making a migration. For the most part, I think this talk will go between sort of business topics, lessons learned, best practices, more of a consulting and how to in executing a large project than it is a technical. Are we doing okay on audio? How's that? Is that working now? Okay, great. All right, we'll pass back and forth. Okay, we'll do a game show style. So we're going to mix it up a little, make it fun. All right, cool. So we've already done introductions so I don't feel the need to belabor this point. But I do want to talk a little bit about what a migration is. But before I do that, a note about our slides. We have a very talented designer on our team who doubles on the weekends as a character artist. So she's done a great job of illustrating all of our slides. They're all custom drawings from her. It's really cool what she's able to do. So first of all, a migration. So one of the things that we struggled with a little bit is what do we mean by migration? What we really mean is what anybody in a large sense is doing in most of these sort of big Drupal platform builds, which is take some set of assets, some set of property that they have intellectual property and a business model and moving it from one platform to another. There are technical aspects of that. There's literal content migration. There are business aspects of that. There's stakeholders. There's project processes. There's communication. And we're going to talk about all that stuff. And so when we say migration, we mean it's literally a migration like moving the whole herd of cattle from one pasture to the next. So just some of the things we're going to cover. One of the things we'll talk about is the people associated with the project team. So who do you involve in migration? Who are the stakeholders? What is the makeup of a project? What's the partner landscape or the other vendor landscape that you're working on in a project? We're going to talk a little bit about how you set expectations around what a migration is going to entail, the needs of the migration, and what you really have to get done. This is on both sides. We want to look at both the client side and also the vendor side. We're going to talk about preparedness. This is a little bit more of the nitty gritty around what you do to get ready for it. The process, so how you take people through it when it happens from the initial idea of, hey, we're going to go launch a new Drupal site to launch day. And then we'll talk specifically about the launch a little bit and the transition that that entails.  So one of the things that we want to make sure that we clarify with this is that when you're talking about people in a migration, you're not talking about just engaging one person or engaging one aspect of the team. We're talking about engaging an entire organization. There is no single migration that should ever take place with just a project team being involved. You need to talk to your stakeholders. You need to talk to your other vendors. You need to work very intimately and make sure that you're talking about how you engage with the entire group and get a really good picture of everybody involved in the migration and who it impacts. So we're going to go through a few of those roles. Okay, so first role to consider in any migration like this is the content maintainers. Content maintainers can take a lot of different forms. As these projects get larger and larger with Drupal, you need to not assume that a content maintainer is someone who is sitting there with the Drupal interface, editing interface open and working within the WYSIWYG. In a lot of the larger configurations that we're working with today, you've got upstream content maintainers, people that are responsible for content channels that they're putting into another system that are being imported into Drupal or large-scale content repositories that are sitting behind Drupal. And Drupal is interacting through an API with those. And you also need to think about these people as owning a channel of content that's potentially multi-channel downstream as well. So these people aren't just interested in necessarily putting stuff into a Drupal website that's going up, a Drupal editing interface that's going up to a website. They're interested in how that's going to show on mobile or how that stuff is going to be consumed as through a feeder and API downstream. So these people are very concerned with the asset that is inside of our content management system, which is content. In a lot of cases, they have a lot of consternation about this move. To them, this is moving all of their property to a new house and they're very concerned about that house and whether their property will be maintained well there. So they're very important people to consider in terms of your coddling. You need to make sure they're comfortable with the content that they understand how this is going to go. And at the end of the day, you have to deal with the fact that ultimately these are some of the most important stakeholders and they may not be entirely pleased with the interface that you provide them initially, but your goal is to improve their business in terms of how that content is going to serve its purpose. So they may have a little issue up front with using the Drupal interface, but remember that downstream it's really about improving their ability to deliver that content to a wider audience. The next group is technical owners. Technical owners used to be the traditional group of people we thought about when we talked about site migrations. We were always all about, are we going to be able to work with the IT departments at large organizations to be able to cut over from one system to another? That's not really the case anymore. It's a lot wider than that. The function of IT is more about risk mitigation and vetting of technology than it is about owning a CMS project. And in most organizations, that's a really good thing. You want the technical people to be there to make recommendations about technical things and to mitigate the technology risk associated with the platform move. So you're no longer asking these people, like, do you like Drupal? Most of the time, they won't even really have a strong opinion about Drupal. To them, it's one component of a much larger solution and you need to be able to speak to them in terms of mitigating the risk for an organization. There are some other things here in terms of development and nuance if you're dealing with an internal project team. That might be under the IT department. We're also seeing it happen more and more frequently. The developers are actually working for marketing because marketing are the people that are controlling those sorts of CMS builds. But oftentimes, you will interface with IT on the development side of things, specifically around DevOps and pure integration. And really for IT, it's about making them understand what is comfortable about this CMS move and also painting the broader picture of how this fits into a much wider solution. Okay. Who's the sort of the bad guy in this scenario? We call them the saboteur. And the saboteur may be known or the saboteur may be unknown.  So keys to this are understanding who those people may be. Some cases, these are people who have a vested interest in, say, job security. In the open source world, we do a lot of moving people off of licensed software. Well, guess what? Those licensed software vendors were pretty smart.  They have a vested interest in making sure that your project fails so that it stays on their platform that they're certified on. That's one type of saboteur. A different type of saboteur is someone inside the organization who might not agree for whatever political reason with your project stakeholder. And they don't want to see their career succeed by virtue of having a successful project. So they may love Drupal, but they may hate the idea that your project's going to work and make their nemesis look good. So your job in any internal group as a project manager or as an external consultant, particularly if you're an external consultant, is to try to identify these saboteurs early and try to mitigate the risks that they have on the project. How do you do that? Well, you do it by ensuring that you understand what their hot buttons are, what their issues, what their needs are, and that you're catering to those effectively in terms of making them feel comfortable. Your job is to get them to buy in. It's not to alienate them from the project. They can make more trouble from the outside than they can from the inside. So what you really want to do is figure out what aspects of the project they would try to sabotage and try to get them to buy into it. Think of their interests. It's very important that you get buy-in from these people as well. This is actually my favorite one. The project champion is a really interesting concept. So a project champion is that person who's usually highly invested in the project. They have a lot of skin in the game. They're likely either putting their reputation or their career on the line. They've had a lot of input into the selection process and they really believe, they need to believe that they've chosen the right people and the right technology to implement for business.  But they can also be almost as damaging as the saboteur. And a lot of it is because they set unrealistic expectations of what you're able to accomplish. In addition, a project champion might not actually have buy-in from everybody inside of the organization. There could be political rifts. There could be fiefdoms. Oftentimes, I know Jeff has had this happen to him. He's walked in a project ready to start developing and the project champion says, yeah, I'm really sorry, but our board said that we can't do this project. That's been known to happen. And oftentimes, these people are running in surgencies, right? Large organizations don't think about technology in terms of we're picking Drupal to do every site that we're ever going to do ever. Oftentimes, you have a project champion that's like, I'm going to take these five handful, this handful of five sites that I own as a part of this greater 1,000 site company and I'm going to make these Drupal. And they don't oftentimes have the buy-in. They need to really make that happen. So you have to really be careful of project champions. You want to build them up. You want to make them feel like they're doing the right thing and you want to make them feel again comfortable about their choices and the fact that they have skin in the game. You want to be aware of being dishonest with them and you want to help them set expectations inside of a company. And by dishonesty, I mean, you want to make sure that you're very upfront about where potential problems might be coming from because these people are putting so much of their own investment in it that they're often blind to things that might be happening in the project. And I guess the last thing with that is, you know, when it comes to these folks, they tend to have a lot of pride in the type of work that they're doing and what they're trying for the company. And you want to build them up as people that look good in the organization. Be willing to step back and let them lead. When you reach a major milestone, let them present it to their company as, look, this is my success and you share in that success together. And that's a great way to forge a relationship with these people. Yeah, in terms of setting expectations, I want to go back. That picture says it all, right? Expectations can be set for the better and the most important aspect of setting expectations is determining globally amongst everybody in the project what the success criteria are. And those stakeholders need to be accountable for those things. You need to be able to go back to a list of things and say, this project will be successful or determined to be successful by management when dot, dot, dot, these five things have occurred. And if you have that buy-in, then you do a much better job of setting expectations amongst the whole project team. So the other way we do it is with roles and responsibilities. So the key to roles and responsibilities is knowing the swim lanes of every single person on the project. And what I need by swim lanes is literally think about who's doing what in parallel with each other and making sure that they're not crossing over. You don't want roles and responsibilities that are ambiguous because you end up with project churn. You end up with things that are being done maybe ineffectively by more than one person on the team. The key to doing that is upfront being very, very critically clear on what everybody's doing. A set of bullets under each person's name that says, I'm this on the project. These are my responsibilities. This is how I will be judged in terms of success on this project is very, very important. And another key aspect of that is making sure that there's a good understanding between the stakeholders or the people on the project and their roles and responsibilities, what their deliverables are to each other. Remember, dependencies within a project are often as damaging to the schedule as dependencies outside the project. So if I'm the themeer and I'm waiting on the information architect to provide me wireframes and it's a week late, that affects me and impacts me. And the damage that it does to the schedule is bad. The damage that it does to our working relationship responsible or accountable for my own failure can be even worse. Maybe later on it stirs this sort of sense of intrateam competitiveness or backstabbing or something like that which can really endanger the project. So ensuring that those roles and responsibilities are defined and actually written down in the project charter upfront helps cut through a lot of that tension between those people. So let's look at some elements of a project team. These are some very high level roles. Project teams can be a varying size but you almost always have at least these four roles represented. You want to have a project manager that's capable of liaising with clients that does that management of a client and also oftentimes will liais with a counterpart on the client side of things. So you oftentimes have project managers that are really the glue of everybody within a particular project. They're really the ones that own a lot of the end work product but they also typically don't have a lot of control over the actual development of resources. They're not the ones that are going to be sitting there typing code into a project. They're going to be the ones that are talking to the client about the progress, about the updates. I kind of like the idea of a project manager being the one responsible for everything but the master of none of them. And that's a very interesting role to play in a project. The project manager relies most probably on the functional and technical architects. There's two sides to this. The functional side is the person that gathers requirements, that talks about the business requirements behind a project. They're typically in an analyst role or they're typically the ones that are engaging more strategically with a client about the big picture ideas of what do you want to do. Tell me about your vision and what it's all about. That's a good question. That feeds very much into the technical folks. The technical folks tend to be the systems architects. The people that are saying, let's take this vision that we have and these functional requirements and let's figure out how we're going to build a system that meets those needs. And then the last piece and this is often really overlooked is compliance. When we talk about compliance we talk about a lot of things that companies like Akwia there's code audits, there's reviews of different aspects of the project to make sure that they're actually meeting what a client has said. User experience design reviews, user testing. Oftentimes there's independent verification and validation through a third party company, but that compliance role has to be filled and it's a really key role. I think it's supposed to be a Mountain Dew, but I'm not sure, yeah. Well, the project manager would have a bottle of scotch in that case. The other side of the coin is the stakeholders. This can be a really diverse group of people. These are the people that you're ultimately responsible to and it's their domain knowledge that you're there to represent. They're the ones that have that vision and it's their vision that gets translated into technology. Oftentimes you have people that are independent project owners. They're the senior vice president of blah, blah, blah, or they're the director of technology for blah, blah, blah. There's all sorts of different groups that might be represented here, but you usually have a senior manager that represents that project ownership. Typically you also have somebody in marketing or more the business side of development. This person is responsible for ensuring that the business needs of an organization are met and they're usually relied upon by the project owner to represent things like content editors, to represent things like branding, the mission of a particular technology project. And then lastly you have editorial and editorial means multiple different things. Editorial if it's a new site can mean the content owners. Editorial if it's a simple site or a social site can actually be representative of a much wider larger group of people. These people are community managers. So you have these different aspects represented in the stakeholder group that you're ultimately there to have a high level of communication with, define success criteria with and serve as part of the development of this project. The last group you really have to take a good look at as partners and there's a reason why the images are the same here. Partners oftentimes are very representative of stakeholder groups because they're another piece of a project that has domain knowledge. In very large projects, it's really unlikely that one single company is going to be able to deliver all the services required of a major organization. And so you're going to be working with partners. And one of the things you want to be very, very careful with these folks is not creating contentious relationships. You want to nip that in the bud. You want to understand that you can't do everything for a particular client and you need to have a positive relationship with these people. They may have similar project teams to you. They may be of similar size. They may be a subcontractor to you. You might be a subcontractor to them. You may have a very tight working relationship where you may be very disparate in terms of what your responsibilities are. But you have to make sure that you work with them because that holistic vision of a project is really important. And it gets back to the stakeholders in a large way too in that having good vendor relationships, being able to present that unified front of we understand the total technology picture to a stakeholder group is going to help ease conflict with them as well. Yeah, so let's talk a bit about how to prepare for a big migration. One of the most important aspects is communication and planning. So it's absolutely essential up front that you establish some kind of a communications plan amongst everybody on the team that stipulates not only how you're going to communicate amongst the project team members but who communicates with whom. Now, in a lot of cases, projects in the beginning tend to become a bit of a mess communications wise. The first 20 to 40% of a project is where the vast majority of the miscommunication occurs. And that's incredibly important because if you end up with the wrong people talking to the wrong people in the beginning and you allow that process to stick throughout, you're going to end up with too many communication channels that potentially don't keep the project going in the right direction. So how do you do it? Well, first and foremost, you rely on tools. Establish up front what are the ground rules around IRC, chat, instant messaging? Do you want people, project stakeholders, instant messaging the developers? Or is it crucial to your project that developers remain totally independent for those people in terms of real time communications for distraction purposes? We've seen it, we run it both ways. There's pros and cons to both. The key is that you establish that jointly amongst everyone up front in the project before it just becomes something someone starts doing halfway down the road and someone else isn't. It's also incredibly important that you don't rely on email. Everybody gets too much email. It's a really bad habit to have anything about a project at all done via email. If you have to send an email about something, you should be referencing a link in a Wiki or in a communications portal or something like that where you have a canonical place that everyone can reference for that piece of information because these days people aren't gonna go back through their email and look for that thing the project manager sent them five weeks ago. It's gonna get lost, it's gonna get buried, particularly when people are working on projects that are outside their regular job. So what we recommend, what we do in our organization, we use Open Atrium, which is a distribution that we maintain on Drupal, which we are by the way moving to Drupal 7 since everybody keeps asking that question and it's up on the website but they don't know it. Anyway, something like that, Basecamp is a perfectly good tool that does the exact same thing, very inexpensive, you can set up an account right away. The key to doing this is not necessarily what tool you have or what features it has. It's about where that information resides and the fact that all the information surrounding any one note or piece of information is about your project. It's not mixed in with a message from your boss about expense reports or something like that. You need that kind of clarity when you're working on the project. Other things have a lot to do with in-person versus phone calls versus Skype versus Google Hangouts. It's very important that you establish the manner in which you're gonna communicate with all the people that Chris was referring to, the stakeholders and all those partners and all those people. Establish all that in communications plan up front. Expect that it's gonna change but at least agree on it and agree to change it as the project proves that those aren't the best methods. Other very important tools obviously include ticket management. So we used JIRA from Atlassian which is a tiny little company here in Australia that you may not have heard of but that's a joke but nobody lasts though. Anyway, we did start working with JIRA actually about 2003 so we watched them grow from maybe 15 people or something when we were using it and now it's a fantastic tool. Whether you use that or Red Mine or Bugzilla or something else, open source doesn't matter. The key is that you have some place in which people can actually have some transparency and some visibility into what tasks everybody on the team is working on and that helps a lot with the communication amongst the team because people tend to understand when someone else is swamped or busier, better when they can see a backlog for them than just feeling like they're picking up on their stress or something like that. So communications and planning, probably the most important aspect up front, communications plans, tools and team agreement on how you're gonna communicate with each other. One last thing on the communication front. You know, I talked a little bit earlier about stakeholders. Your communication is your way of reaching higher up in the organization to make sure you're not working with somebody that hasn't secured buy-in from their boss. Having that communication be able to reach upward inside of an organization is your pathway to making sure that you're working on the right project and that you're defining success criteria that are representative of the organization, not just the needs of that project owner. That's a really key piece of the communications plan. Estimating. Estimating is a really, really big topic. It could be an entire presentation and often is. And I would recommend that you, if you're in the position where you're doing project management or you're doing consulting to a client, take advantage of some of the great talks that have been given at Drupalcons and Drupalcamps around this. What I will say is running a professional services organization for the last 12 years that we've been in business, our ability to estimate as it's matured has contributed directly to our ability to mature the professionalism and growth of the company. And that's because essentially, that's how we set our price. We set our price by estimating a project in many ways, whether it's time and materials or it's fixed price bid or something like that. It doesn't really matter.  So it's absolutely essential. I will say that even if you're working inside an organization, I think it's equally important. One of the things I've seen contribute to project failure a lot is professional services organizations like ourselves come in and we have a high degree of rigor and expectation around how we estimate everything from the ticket level where we insist that the developer or the person doing the work is actually doing the estimate and we're rolling all these up, sort of a ground up process. We often also do a top down. So we do two things to meet in the middle and get two data points. We have a project manager do it from the top. Developers and everyone else on the team do it from the bottom, it gets rolled up. And the third data point is often a related project. So we go into our project repository and say, what project have we done in the last five years that looks most like this? And not what did we estimate that at but what did it actually take? And now we have a real data point and those three data points, if they're correlated around something give you a pretty good sense of where things are gonna end up. What we've seen contribute to projects failure is the internal team, the internal group that's working on the project doesn't have the same rigor and customs and culture around doing estimates. As a result, what happens is their estimates tend to be driven more by what their project stakeholders and their project manager thinks is gonna take. It's just a top down. So they get out the Gantt chart and the project manager says, we think we can do it in this long and they push that down to the developers. And developers don't get a chance to estimate their own tickets and bring that back up for a reality check. So if you're dealing with a project where maybe your estimation processes has a lot of rigor but the other side of the group doesn't, watch out, that's a sign for failure as well. So when you talk about migrating this site, what are you talking about? There's all sorts of things and it's not just content. It can be everything from the actual nodes in a site to a bunch of documents in a repository. It can be multiple different databases that are all having to change over as a part of a site build. It can even be something like, we're moving from SVN to Git and we need to migrate all of this code data from one sort of repository to another. There's also lots of different proprietary data formats and things that you have to think about when you're doing a site build. The other part of this that isn't really listed here is social. So what happens to all those Facebook comments that are tied to something in Campfire? What are all, or wildfire, excuse me, what about all of the tweets that referenced old articles? What about all of these things that you've done to publish this content across the web? How do you take that into a new site? This sort of inventory process is really important because it's a two-stage thing. You first wanna say, all right, let's look at everything that we possibly can move and then you wanna pair that down to what do we need to move to make this successful? And so that's where the inventory side of this becomes a really important part. Once you have that, you also wanna do a second step which is refreshing and reorganizing. Jeff actually came up with a really great analogy for this. When you are moving houses, so you're taking all your furniture, all your possessions, and you're going from one house to another, do you arrange the furniture the exact same way in the new house as you would in the old? You know, do you give it an opportunity, do you take everything with you or do you give an opportunity to have a yard sale and sell off some of the stuff you maybe don't want anymore, maybe it doesn't fit in the new house? It's really important that you take the time once you do that content inventory to decide what you need to move and also to make modifications to the types of content that you want to change when you get to the new site. So again, I'm getting all the topics that could be their own presentation. Architecture, and this is not a technical talk, so keep in mind architecture to us is as much about business architecture and business logic as it is technology stack. Architecture is an incredibly important activity that tends to get rushed through or tends to be done by the wrong people. The people doing architecture ought to be the most experienced people in the project. If they're not, something's wrong. Your tech lead, your most senior person needs to be involved and in our case, all the way to the CTO is gonna have an oversight and a review of that architecture for every single client because that right there is your reputation. That is the moment of purity that you're providing to that client in terms of technical thinking and it has to be right. And if it's not right, that's okay but you have to have a process to modify it and fix it along the way. The way I think of architecture is you have to completely understand the future requirements as well as the current requirements to get it right. And that means really understanding what aspects of it need to be flexible, what parts need to be modular, and don't just assume that the tool set that you have, the way that other people have used it is the right way. Look around and find out how other people have used that tool set to make sure that there aren't better ways to set it up. Yeah, or I said delivering to the client, really not selling to the client, but yeah. So it's great to have all these things that we need to think about when we're doing it but what's really the process for getting from that inventory stage all the way to a pre-launch? So these are kind of a quick series of slides of packaging those things that we talked about in the previous section into a more cohesive process for going live. I think that this sort of speaks to very similar topics to what we've covered but it'll show a way of implementing these in a real chain of events to get to an end result. So moving data in most larger enterprise integrations, this is gonna be an automated process. Hopefully you've got people on the team or a person on the team at least who's capable of scripting stuff, understands database schemas and structures, and understands Drupal and how to use the Drupal API. There are good modules out there. Again, I get every topic that could be a full presentation but this one, no, this is good, I like it. Given the CEO, all the tech ones. So in our shop, we use things like the Migrate module which allow you to help migrate content into Drupal. We also do a lot of database scripting. We do a lot of cleansing along the way so cleaning up content, I'll talk about that in a minute. But consider this to be a vital thing, a vital decision that you're gonna make. We have had, I don't know how many clients tell us, you know what, don't worry about that. It's expensive, it's difficult, it's risky. We don't wanna pull that off. We're just gonna re-enter the content ourselves. Bullshit, they're not.  So whether or not you think this is gonna be a part of your process, plan for it to be part of your process. If you don't have the skillset in-house to do it, go out and get someone that can do this process. Don't assume that the content owners are actually gonna re-enter the content by hand. They're just not gonna do it. Again, just like Chris said earlier, use it as an opportunity to clean up. A lot of times content that you're bringing over isn't just coming over from one platform, it's coming over from three platforms ago. And that stuff might have been late 90s. It may have had a lot of embedded HTML stuff that you wanna clean out. It could have been scraped off of word documents and been dropped through WYSIWYG's in which all kinds of nasty, nasty, proprietary encodings has been dropped into the database. That can cause you a lot of problems and a lot of pain. And again, as Chris said earlier, this is your opportunity to clean it up. So look at transformation processes, look at cleansing, script out the JavaScript stuff that's in there, out. Get any bad tags and things that WYSIWYG's and word processing programs and stuff have put in there out during this process. And for God's sake, make sure your content is just as clean as possible. Yeah, so once you have that content up there, you wanna make sure that you take a look at it. Have a keen critical eye to what's gone up there. A big part of this is context, right? When you have new content in a new system in a prototype way, you wanna be able to take a look at this content then in context and understand what it's gonna look like in the new site. And that's really what the review is all about. Engagement around the entire organization is again really important at this phase because you don't want content to just look good to editors. You want it to look good to users and other folks that are going to be interacting with the site. So if anyone that saw Dries's keynote, you know, or most of you probably already know from firsthand experience, Drupal has some difficulties in terms of the way that the deployment process works. Again, this isn't a technical talk, so I'm not gonna talk around sort of how Drupal 8 may fix that or what tools are available. But if you are responsible for planning or managing any kind of project in which you're gonna be using Drupal in any kind of large scale, understand that A, you're gonna need different environments, so you're gonna need to direct your content people at a specific environment that's dealing with just content. You're gonna have some kind of a staging or maybe an integration environment for your developers.  Understanding what these different environments are, how they're used, how they're procured upfront and educating your whole project team on how to use them effectively is a really important part of limiting the friction on the project. Can't tell you how many times people are just testing on the wrong server, putting content in the wrong server, something like that. And it's just a really painful part of sort of the friction of the project that you wanna try to eliminate. It's very important that you think about that upfront and you come up with the scheme that your project is gonna use to manage the deployment process. That goes as far as potentially having automated continuous integration processes and things like that. If your project is mature and you have that kind of software maturity in your organization, you're gonna wanna do that. If you don't, you need to make that decision up front and decide if you're gonna do it the old fashioned way, get on the same page so that you don't have those arguments down the road at three quarters of the way through the project. There's another piece of this too, social integration. This is a huge, passionate thing that I have here. When you talk about content these days, you're not talking about consuming content in a well browser. You're talking about consuming it on mobile devices and mobile apps. You're talking about looking at it in terms of feeds and Facebook and LinkedIn and Twitter. All of these different channels that we look at for our content now are incredibly important to understand when you're about to migrate a site. If I am going to publish an article, what does that article look like when I tweet about it? How does it get into Facebook? Do I have micro data and metadata formats? Am I needing to consider the semantic web stuff when I look at this? There's all sorts of aspects of integration here that are very often overlooked, and this is what the web is becoming.  Can't say enough about the importance of code review. This is about quality, it's about having a process internally within the team to determine when code is okay to go into a production environment. On our teams, we tend to have a hierarchy, so we have multiple people looking at code. We'll do random checks, we'll do planned code reviews. We use tools like Crucible and FishEye, also from Atlassian, to make this part of our process. So this is all integrated with our JIRA tickets and things like that. It's incredibly important that you establish upfront how that's gonna happen, and you filter that down to all your developers so that if you've got two or three different developers with different skill sets, that they each understand how their code's gonna be reviewed and what kind of feedback and what kind of expectations are gonna be put upon them by more senior people on the team. More and more larger enterprises are dealing with proprietary customer information. You have various compliance laws in the United States. We have stuff like FISMA and HIPAA and all these other large sets of compliance standards that we have to meet in order to protect people's information. A website hack on a scale that releases a tremendous amount of people's personal health care information is something that as a business you don't really recover from. It's something that damages your credibility and your ability to even work in that space again. Security is a paramount concern for enterprise and it's one of those things that if you don't have an independent verification and validation process, get one immediately. It's incredibly important that you use outside people to independently verify your assumptions around security. I cannot stress enough the need to understand how to write secure code and moreover to have somebody else that is not a part of your team tell you that yes that code is secure. It's a really critical piece of making sure that you have a successful site launch. Now we're gonna talk a little bit about the transition itself. So how do you go from all these different pieces into a new live site? The plan is pretty simple. You go through all that content preparation stuff. You have that QA feedback, verification side of things. We've talked about most of the pieces of those two aspects of this plan. What we really wanted to focus a little bit more on is the people prep side of things. So once you have this idea of my content's ready, my code's ready, how do I get my people ready for this site to transition? And then right leading up to site launch, what are the tasks that you have to do to ensure that you're going to have a successful launch? Content prep right before launch is an amazingly important aspect of making people feel comfortable and happy about the launch. It's really actually kind of funny. When you launch hundreds or thousands of websites, you watch and you think well, this thing's gonna be up here for years and every single day there's a decision on what's gonna go on the homepage. But that first day, oh my God, is it important because the whole world is watching, right? So be sensitive to that, understand that that may not seem, especially as a technical person, like the most important thing, you know that there's other things that need to happen to go live. But for those content maintainers in particular, this is a very important first step to feeling comfortable with the launch of the site. You also have to look at a QA and feedback process.  Because you've got a launch deadline that's a week away, don't compromise your QA and feedback process. Make sure that you have the right people reviewing things. Make sure that you get those final sign-offs. Make sure that you look at those success criteria you talked about earlier and that you hit every single one of them. It's really important that you not compromise this. It's much better to move a site launch than it is to launch with a site that's not gone through the process of QA and validation that you've set up as a part of the project. This is not an official statistic, but I'd say over the last 10 years, we've launched literally thousands of Drupal sites. And I'd say maybe somewhere between 60 and 70% of our launches are pushed back by the client. And I remind my team that all the time, for not because I want them to slack on the deadline, but because I want them to pay attention to that last slide, which is don't compromise your quality to meet a deadline that the client's gonna move anyway. Do a good job. And if you end up going live that day, you're gonna be happy for it. If it ends up getting pushed, you're gonna be glad that you didn't cut corners to hit a deadline that didn't happen. Oh, I get to talk about training, cool. All right, training, yeah, is a huge topic that you could do a whole presentation on. The training is an enormous part of what happens with any CMS build. A lot of it is about the psychology of getting people to understand the new system. It's some button pushing. We talk a lot about the interface in Drupal and how it's not always client friendly, but guess what, you can change a lot of that. If you have that built into your project and you've got the time, you can modify aspects of the administrative screens to be whatever you need. It doesn't matter at the end of the day if people aren't fundamentally comfortable with it well before you go live. So if you start that training process and you even integrate it in as sort of testing training, it's okay to mix those two on the content side. If you're dealing with contenters, it's okay to do iterative reviews very early on and just tell them, hey, this is me teaching you how to use the system and you telling me what's wrong with the system and we'll just mix it all together and we'll just make tickets as we go. Start early, do it often, don't wait to the end and have this big training process. Because guess what, rest assured, guaranteed if you do it waterfall and at the very end, before you go live, if you do one big set of trainings, you will find so many bugs, so many problems in that process. You will be kicking yourself so hard. So it's better to mix them up. I know it sounds like it's not a good process. It's kind of like why would you mix testing and training? Well, really honestly, it's so that you get feedback earlier in the process and you get them sort of gradually accustomed to it. It's better to get sort of slowly accustomed to the temperature change than it is to sort of do it all at once. It's the same philosophy. So I think training as many aspects to it, that's the one I feel is most important and relevant for this presentation. But if you wanna talk more, we can talk for days about that alone. This is one of the most interesting things because people think about launch day as walking into mission control during the moon landing. And they've got 25 people all in rows saying check, check, everything's good, everything's good. The reality is that the planning for that day starts well before launch date. You wanna pick a date that's reasonable, that's something that you're sure your team can be prepared on. You wanna have a launch checklist. You don't wanna get into the habit of setting expectations around a launch before you have any idea if you're actually gonna reasonably able to attain that goal. Lots of people look at, I have a site build that's gonna take a year and I'm gonna launch January 1st, 2014. Sitting here today, we would have no idea if that's a realistic date or not. We can say that we can take the project to a point but requirements change, things change with clients, things change with the way that you move forward with things. I would say very much try as hard as you can not to set a launch date in stone because if you're building a project to a date, you're always ultimately compromising what you wanna deliver. If you're basing a date based on what you're able to deliver, you're going to have better client satisfaction of better launch and things are gonna go much more smoothly. All right, so the launch itself, done, easy. What do you really need to do? From a technical perspective, you need to prepare for traffic. But that's also a business user thing. So having a really good picture of what you expect to happen on launch day and post launch in terms of visitors is really important. So are you gonna get a whole bunch of new authenticated users because now you're offering a login mechanism that wasn't there? Is that the kind of profile that you're gonna have for launch day? Or is it gonna, something that your PR department or marketing group or somebody's gonna manage to get into mainstream media and your traffic spike is gonna be 200% your normal day? And you didn't know about that because nobody told you that marketing was gonna get that out into some mainstream media circle. Those are really important things to understand because you may have designed this site to handle a certain amount of users, but they really, really have a way of blowing it up on day one. Some sites are quite the opposite. You've got a real slow launch. It's really important to you guys, but the rest of the world is just a random Tuesday. So I think it's very important that you understand that profile. There's a lot of things that you need to do technically, obviously. You need to be thinking about caching, technologies and CDNs and all that to manage that. But really that launch day is the most important time to handle your traffic because you can go down six months from then for four hours and you won't get smacked as hard by your client or management as you will if you go down for four seconds on launch day. And congratulations. You've made it. You've launched a site. You know, it's a great feeling when a project goes well and it's a really terrible feeling when it doesn't. And you want to make sure that you follow the techniques and the things that we've talked about in order to have more positive launch days. You want to have that confidence to hit that button. And that's really what this talk is all about. You know, a successful launch leads to client satisfaction, referral work, more projects down the line and success stories that you can tell for your company. And that's what you're trying to build. Never plan a project that ends on launch day. Think about that for a second. Never. It's the absolute worst end to a project plan. Every project plan should end at some point after launch day. Maybe it's two days, maybe it's a week, two weeks, two months. But what happens immediately after launch is just as important as immediately prior launch because that's when all those new content, those content editors we were talking about are actually using the system for real. And that's also when they're gonna discover the 25 things they never understood about the training process. It's when all those traffic patterns that we talked about are gonna start to become apparent. It's when the CEO finally looks at the website that you've asked him to review 10 times prior to going live.  So, you know, it's really about understanding your true endpoint and your endpoint with any website is never, right? It's always gonna be an improving thing. But your project can't end the day of the website a lot. You know, launches. It's gotta be some point thereafter. And I think it's a really important thing for all of us to remember. But obviously it will continue from there as well. So that's just a different part of this and we don't have time for it. So, questions. So the question for the recording and for those that couldn't hear is having specific, I think, to phase two, right? Having done a lot of builds over the years. Do we have some kind of a custom admin interface that we use that handles the way we do the content process and things like that? The answer is no. We've done a lot of different custom content interfaces. We don't tend to reuse them a lot even when the client's given us permission or is willing to contribute them. And the reason is that they were typically done with something unique to that organization. We did one for the Thompson Reuters Olympic site. So on Reuters.com, we did the Olympics process. They were adamant that the users don't have to know or think about or understand Drupal and they didn't want them to see the Drupal interface. They wanted them to see an interface that looked Reuters-ish as if they had built it themselves. So we changed colors and styles. We changed workflow and layout. We used the Workbench module. We tend to use Workbench. That's one answer, I guess, to your question. Which allows for a better content administrator sort of queuing process and things like that. But we made it look more like Reuters and it was orange and they called it drop which was a code word for Drupal and it even had the Drupal logo.  What's Drupal? And then going through that process, they just wanted to obscure a lot of that to avoid the politics. In other cases, we have distributions that we use and those distributions have, in many cases, tended to alter the admin interface a little bit for certain functions. But typically, it's different for every project. Other questions? We didn't open enough subjects for questions. It's like, why don't we just touch really lightly on a lot of things that could be a talk? Xena? Yeah, yeah, sure. Yeah, so we have people in-house, oh, I'm sorry, your question is have we had a lot of success with getting people either internally or externally on a retainer basis that can do content transition? Okay. Right, so internally, have we had success finding someone who could do the content migration, right? We've done content migration a lot of different ways. We tend to have kind of a rotation amongst our development team so that no one person is like the go-to, you know, always has to be the content migration person. We think it's a skill set that everybody on the, you know, all the developers should have so they understand a lot about the content. We have clients who have trained people in-house to do it. I'll be really honest, it typically fails. I mentioned earlier, if a client tells you that they're gonna move the content themselves and don't bother with content migration, there's like a 90% chance they're gonna change their mind.  We just don't tend to see people that haven't done Drupal and haven't done large migrations even if they understand database stuff and schemas and all that, they just typically aren't successful in doing it. It's a shockingly technical and tedious process, I think. You know, it's deceptively hard. Yeah. Okay, I guess I get all the questions today. There's a good rant on this one. Yeah. Yeah, the question is, if we've had any experience going from SharePoint to Drupal, we have and we're expecting a lot more of it. We're gearing up to have that experience. It's my personal contention that the wave of proprietary CMS is being destroyed by Drupal on public facing websites that Dries was referring to in his keynote. It's my personal contention that that same wave will occur on the internet side and eventually SharePoint will be deposed by Drupal and others. We are steering actively our open atrium distribution into that space so that it would be a flexible replacement to a SharePoint instead of more or less a base camp. We want a tool that will do that because we think that that will happen. Our experience on SharePoint has been good in that users are typically more satisfied with what we can build these days on Drupal because keep in mind, it's not a fair fight because you're dealing with usually a SharePoint implementation that's five years old at this point so it's kind of crappy to begin with. It's not like they just decided it yesterday but when they come off of that, they typically have a much better experience. They really enjoy a lot of the interface things we can put into Drupal. The downside tends to be A, in any kind of weird custom integration stuff they've done with other Microsoft, things like calendaring or contacts or active directory or other binary file stuff that they do. So that kind of Microsoft's got its chocolate and its peanut butter mixed up. Do they have that in Australia? Do they have those commercials in the 70s? Reese's Pieces or Reese's Peanut Butter Cups? All right, never mind, never mind. Are you American? No. Okay, yeah, yeah, yeah, all right, all right. Yeah, I mean, at the end of the day, SharePoint's probably using SQL Server, right? And you've got a relational database scheme and you can script it out of there and move it. I'm quite certain that the times we've moved stuff out, we've done it in an automated fashion. I can't remember specifics of a project on that but yeah, we have. The other thing I was gonna point out about that is it does come back, most of the places we've seen, particularly US government, it does come back a lot to that sort of job security thing and licensing. So typically once people get the bug to move, they do it but there's a lot of resistance internally based on that allegiance to a platform like DBAs and SQL Server or people who've been MSC trained or whatever. Now I'm hoping that Jeff and Chris will be able to stick around after this session a little bit for potentially for more questions. I'm sorry, we ran out of time for questions. Is that okay with you guys? Fantastic, yep. In fact, I'm thinking that we should maybe have another conference next week and you can expand on each of those topic areas for us with a session each. Yeah, yeah, yeah. So would you please welcome Chris and Jeff. Thank you very much, fellas. Let's show them our appreciation. Thank you.


For Kant's categorical imperative, you act only on that maxim which you can will into universal law. In effect, what this means is that you're deciding on a set of rules by which everybody would behave. So here's a question. What would the world be like if everyone acted like you?


How's it going guys? You're right. It's Mark And I thought I would make this video because if I or if someone had told me this when I first started trading It would have been massively helpful and would have saved me from Losing kind of a lot of money to start off with before we got to where right now. So and that is Never using more than 2% of your equity of your account or 2% of the money that you have in one particular trade So there's quite a few reasons and for that when I first started out I was kind of using 30 40 50 60% of my account on one trade and then the trade goes bad And you lose all your money and then to try and get back to where you were It is pretty pretty difficult and I get it because when you you know when you first start out trading You're kind of swinging for the fences. I mean trying to get rich quick He sees people on Instagram and all these foreign traders are like, yeah I trade folks from my laptop in my Rolls Royce and But I think quite frankly 99.9% of that is all bullshit and I think it's just a lot of kind of referrals and and so on but anyway And that's something else. So just a few facts for people right for when you're losing money on your account That I've found so if you lose 25% of your account, right?  If you used to lose 50% So if you use 50% of your account on the trade and you lost it You would need to make a hundred percent on the rest of your account to be back where you started And then if you lost 75% you would need to make 400% to be back where you started I mean if you use 90% in trade you would need of your account You'd need to make a thousand percent to be back to where you started. So, you know, basically what I showed you is losing Losing money and then trying to make it back is massively difficult Whereas if you only risk 2% of your account and I'll just show you here. So you can see I've got You know, I think I've got them. Let's have a look just double check I've got what's the most I've got invested in one stock is Looks like 15% with Tesla, but this is all broken down into, you know 1% trade you can see I'm using 0.95% of account and at the time when I buy it's always 1% That's that's the number that I use And so basically it just helps you first of all helps you manage manage your risk, right?  I'm kind of what you're doing and use that as a kind of a learning experience And also by only using 1 or 2% of your account it helps you kind of keep a level head so for example these trades that Let's have a look that I'm down on right Because it's only so Activision for example, I'm down 30% but it's only 2% of my account So whereas if that was 90% of my account, oh my god, but I need to try to cut my losses And and kind of call it the end here. I can have a little bit of composure, right? I can take a look at the chart I can see right, okay You know, obviously we've had a pullback and But over the long term the stock is is pretty good, right? You can see that it's been trending up You see it's curling into the the EMA is below the SMA blah blah blah and I can I have a proper analysis with a level head Because I mean it's only 2% of my account And I'm it's not going to break the bank and it also gives me a little bit of flexibility In terms of of you know kind of moving forwards. I've still got equity there So, yeah, I just I just thought that I would share this if you in fact if you take the time if you take a look at Some of the e-toro Profiles, right if you just jump on your newsfeed and just take a look at how common I'm not gonna do it now because it obviously I don't know. I don't put any video But if you just take a look at how many people are using way more than 2% per trade And how that ties up a lot of equity Gives you a little lot less flexibility The risk is a lot higher and you know, I think I hope I've kind of articulated that especially if you're starting out You don't want to be risking, you know a massive amount of trade especially leveraged positions as well where there's a lot more volatility so I hope that helps. I hope it wasn't just kind of a ramble and didn't really make any sense If you found it helpful, like something in the comments, let me know if you'd like other videos like this And if you have any questions at all I'd be more than happy to answer in that or if you want to DM me on Instagram We can have a proper conversation there and kind of like takes back and forth It'd be a bit easier if that's if you want to have a conversation It's Mark Freeman official would be in the link down in the description And yeah, I think that's everything so thanks for watching guys if you enjoyed it like And subscribe and then comment and so on and share it but apart from that I will catch you guys and we've update videos and so on moving forwards. Thanks. Cheers. Bye