Team.me

teamme

DevOps for Beginners: Navigating the Transition from Traditional Development

148 Stories To Learn About Team Management

Articulating the vision of a 3D immersive virtual world often involves breaking down the complex meaning of the metaverse.  To fully understand what it is, it's helpful to talk to innovators that are pushing the boundaries of technology in the metaverse space. My unyielding curiosity led me to , the co-founder and CEO of SuperWorld – a virtual world mapped onto the physical world– where users can create, discover and monetize content (3D, 2D, audio) in augmented reality. Hrish Lotlikar Through SuperWorld, Hrish is helping to shape what Facebook founder Mark Zuckerberg once described as the future of the internet. Hrish and I recently sat down to discuss the metaverse and his vision of a digital world built on top of it. Read on! 1. Hrish, can you tell us about your background in technology and web 3? My career has spanned experience on Wall Street, in Silicon Valley, and in Hollywood, with many years spent living and working internationally, and my background has uniquely prepared me for our mission at SuperWorld. I started my career in management consulting and worked on Wall Street at UBS Investment Bank and HSBC Securities in New York, starting off in real estate investment banking. I didn’t know at the time that I would help create the category of the virtual real estate covering the real world, but life is funny that way. I definitely was well prepared by my “physical world” real estate experience. Afterward, I became a Vice President at Spencer Trask Ventures, an early-stage technology venture capital fund in New York and then a founding Managing Partner of Eastlabs, an early-stage technology VC fund based in Kyiv, Ukraine.  I was an early employee in my first BD role at Toptal, a talent marketplace backed by a16z, which is now one of the leading companies in the space. I co-founded Rogue Initiative Studios, a Hollywood entertainment studio (partnered with Hollywood director Michael Bay) focused on feature film, TV, gaming and immersive experiences. This experience has given me insight into the intersection of technology and entertainment, which is highly relevant in the Web3 space, where immersive experiences, gaming and entertainment are major use cases for the metaverse and blockchain technology. 2. You were rated by ReadWrite as one of the most influential people in The Metaverse in 2021. How excited were you to share that honor with Mike Winkleman(Beeple)and others? I was truly honored to be recognized as one of the most influential people in The Metaverse by ReadWrite, alongside other notable figures such as Beeple, Neal Stephenson, Matthew Ball, Phil Rosedale, Tim Sweeney, Sebastien Borget, Cathy Hackl and others. The Metaverse is an emerging and rapidly growing industry, and it's exciting to be a part of this transformative moment in history. To be recognized for the work that we're doing at SuperWorld and the impact that we're making in this space is truly humbling. It's an exciting time to be involved in the Web3 space, and I'm looking forward to continuing to drive innovation and growth in The Metaverse and beyond. 3. What is the metaverse all about? I think the significance of the metaverse is that it brings together our physical life with our virtual life enabling us to do things in the physical world and receive virtual benefits from that activity, or vice versa, doing virtual activities that unlock physical experiences. I am an advocate of the open metaverse where interoperability between virtual worlds is paramount and also the utilization of web3 technology that enables anyone to own the virtual space around them and the digital content they are creating. SuperWorld is built onto the real world, and so we are building a metaverse that is focused on enhancing people’s real lives and improving the real world. https://youtu.be/DPC05-rojIY?embedable=true 4. Alphabet, Meta and Microsoft are three of the biggest technology giants that have invested heavily in the metaverse project. Is the metaverse a new tech race? While Alphabet, Meta, and Microsoft are indeed investing heavily in the metaverse project, it is not necessarily a new tech race. The concept of the metaverse has been around for years, and it has been explored in various forms in science fiction and video games. However, with the advancements in mixed reality technology, web3 and AI, it has become more feasible to create a shared virtual environment where people can interact with each other, have the ability to own these spaces and the content created. It’s also worth noting that the metaverse is not a winner-takes-all market. There are multiple metaverse platforms, and different platforms could cater to different audiences and use cases. So, while there is competition among these tech giants to establish themselves as key players in the metaverse space, it is not a zero-sum game. 5. Can you tell us about SuperWorld and your role in co-founding it? SuperWorld is the virtual world mapped onto the real world, allowing users to create, discover and monetize content (3D, 2D, audio) in augmented reality. SuperWorld's virtual real estate platform allows users to buy virtual plots of land anywhere in the world, activate monetization and become a key stakeholder on our platform in those real-world locations. SuperWorld’s mission is to enhance people’s real lives and to leverage metaverse technologies (immersive tech, web3 and AI) to improve the physical world and benefit humanity. The idea came to my co-founder Max Woon and me in 2017, after we saw the massive success of Pokemon Go and thought about how we could empower anyone to be able to create, discover and monetize content in real-world locations on Earth. We also integrated web3 technology to enable anyone to own the digital content they are creating and to be able to own the geospatial locations around them. As co-founder & CEO of SuperWorld, my role has been to drive the vision and strategy of the company while also working closely with our team to build a platform that can provide value to users, brands, and organizations alike. I'm proud of what we've accomplished so far, with new users and partners joining us every day. SuperWorld is passionate about creating a metaverse that is accessible to everyone, and that allows people to interact with the world and each other in new and meaningful ways. I believe that our platform has the potential to transform the way we think about virtual and physical space, and I'm excited to help create SuperWorld into the gateway into the metaverse for the mainstream. 6. One key element of AR is its potential to usher in a "phygital" economy. How long will it take to get there? AR has a bright outlook as we can already see early signs of the emergence of a “phygital” economy. For instance, retailers are already using AR to enhance the shopping experience by allowing customers to try on virtual fashion (Nike, Adidas, Gucci, Warby Parker, to name a few) or preview products in their own homes (Amazon, IKEA, Target, etc.). With AR glasses becoming more accessible and advanced, we can expect to see an increasing number of industries embracing the use of AR to create innovative and engaging experiences for their customers and employees.  These use cases are already here and I expect over the next few years, AR will be commonplace as part of the phygital economy. 7. What are the opportunities that the metaverse will usher in for millions of people across the world? The metaverse is expected to bring numerous new opportunities for people across the world to interact, work, learn and play. It will create new forms of social interaction, allowing people to interact with each other in new and immersive ways. They can also form communities and participate in social activities that were previously impossible or limited by physical barriers.  The metaverse will bring people’s physical lives and virtual lives together. The metaverse will allow people to work and learn in virtual environments that are more engaging and interactive than traditional settings. This could be particularly beneficial for people in remote or underserved areas.  In SuperWorld, we are enabling content to be added to physical locations in the real world, thereby ameliorating our physical experiences as well. The metaverse will enable people to buy and sell virtual goods, services, and experiences, opening up new economic opportunities for individuals and businesses and also unlocking opportunities in the real world. And finally, the metaverse could potentially provide greater accessibility for people with disabilities, allowing them to participate in social activities, work, and entertainment in ways that may not be possible in the physical world. 8. Is the metaverse here to stay? Yes, there are a variety of inflection points that have made the timing ripe for the metaverse. Major tech companies, such as Facebook (now Meta), Microsoft, Google, Niantic, Unity, and Epic have made significant investments in the development of metaverse platforms, infrastructure, and technologies. The gaming industry has already embraced virtual worlds and online multiplayer experiences, with games like Fortnite, Roblox, and Minecraft serving as early examples of metaverse-like environments. The rapid advancement of technologies such as VR, AR, 5G, and edge computing is expected to enable richer, more immersive experiences in the metaverse. Decentralized blockchain-based technologies, like non-fungible tokens (NFTs) and decentralized finance (DeFi), are increasingly being integrated into the metaverse, allowing for new forms of digital ownership and financial transactions. 9. What is the problem with the metaverse? The metaverse's lack of inclusivity can be a significant problem, as it can perpetuate real-world biases and discrimination, creating a virtual space that mirrors the inequalities present in society. This can have serious consequences for individuals and communities, leading to feelings of isolation, marginalization, and discrimination. Our mission at SuperWorld is to build a better world and we want to create a platform that is accessible and inclusive for all. We are committed to promoting diversity and representation on our platform, working to create a space where everyone can feel welcome and valued. By prioritizing inclusivity and promoting understanding and acceptance, we believe that we can create a metaverse that truly reflects the diversity and beauty of our world. 10. Do you have any parting words? I want to express my sincere gratitude for taking the time to interview me and discuss the topics that I’m personally so passionate in talking about. I hope that our discussion has inspired your audience to think more deeply about the possibilities that exist within the metaverse and the potential impact that it can have on our lives. At SuperWorld, we are committed to pushing the boundaries of what is possible in this space and how we can use this technology to improve people’s real lives and enhance humanity.

'The Metaverse Is Not a Zero-Sum Game': Hrish Lotlikar, SuperWorld Co-founder & CEO

Temporal's Samar Abbas believes developers shouldn’t have to even think about losing state. There are just these durable executions that never fail. If you’ve used word processing tools for a long time, you remember the reflexive action of hitting the “save” keyboard shortcut — the fear of losing your work, cursing out loud and bemoaning the amazing work that you just lost. With modern tools (think Google Docs), this worry doesn’t even come up. In the middle of a word and the power goes out? No problem. Everything is saved in the state you left it and you can move on. Samar Abbas and his team at workflow orchestration engine Temporal want to bring this concept to your enterprise workflow. You provide the business logic and they handle all the parts that require specialized expertise like persistence and resilience. was founded in 2019 by Abbas and his colleague Maxim Fateev while they were at Uber. They had created a development platform for the car-hailing app company dubbed “Cadence.” It’s an evolution of the that the duo helped develop when they were colleagues at Amazon in the mid-2000s. Dozens of Uber services and applications adopted . Temporal AWS Simple Workflow Service platform Cadence Abbas and Fateev left to co-found Temporal and build the fault-tolerant workflow engine successor project to Cadence. In the three years since, the company has enjoyed solid success, with companies like Netflix, Instacart and others using Temporal’s open source software code. Earlier this year, the company secured a $103 million Series B round that put its valuation at $1.5 billion. I recently had a conversation with Abbas (you can watch the whole thing ) about how he and Fateev built their wildly successful venture. (His words below are edited for clarity and length). here From Uber to Temporal In 2015, Uber opened an office in Seattle, and I joined their engineering team. Me and Max [Temporal co-founder Maxim Fateev] ended up at Uber within a month of each other. The key project we worked on together was Cadence. At Uber, engineers spent lots of time stitching together low-level queues, databases and to build resilience into their applications. durable timers This is what we were trying to solve with a system like Cadence, where we provided high-level abstraction that was still code-based, but we took certain classes of failures off of engineers’ plates and solved them underneath the platform to allow the engineers to focus on the business logic for the application, rather than building resiliency. That was successful within Uber and, as it was open source, we started seeing a lot of external adoption for the technology. So in 2019, both me and Max decided to take the leap and started Temporal, because we really wanted to focus on the external adoption of the technology. The Temporal Developer Experience People sometimes describe Temporal as a workflow engine, or describe its features, but the key value proposition for us is developer productivity: how fast developers can build applications and get them running in production without spending weeks or months testing all sorts of failure situations that can happen in a cloud-native environment. So the way we think about developer experiences is not just the core aspects of what the technology has to offer; we cover the entire software development life cycle from the get-go, how developers are building their application. For instance, a lot of workflow engines typically go the domain-specific language (DSL) route. We are all code-based. We know developers like writing code, and we want them to write code, but just take away a certain class of concerns, like how to make that code resilient if some underlying infrastructure goes down, or how to make code resilient when a network blip happens. When and How Does Temporal Make a Difference? Money transfers are one of the key use cases where Temporal is used quite frequently. If you are moving money from one account to another account, typically from a user perspective, yes, I debit from account A and then credit to account B. But a majority of the software development time is spent on system failures between those two calls. And this is where basically engineers are spending all sorts of time. This is an example of when a system like Temporal can help big time — it even feels magical. We hear this question a lot: What happens if my application fails at this point? Our response to that question is: Workflows never fail (At Temporal, we call the primitive that we are building a “workflow.”) Then it’s one of those moments when a light switch goes on. We’ve started to call this “durable execution,” where at a high level what we provide is this: Your executions are completely durable. They never fail. The Business Impact of a ‘Fault Oblivious’ Stateful Workflow Back in the 90s when I was in school, we used to type all of our assignments in Microsoft Word. You got in the habit of saving your document every time you wrote a few edits. Yet there was a certain class of failures, like the hard disk going down, where you lost all your work. Now, with Google Docs, kids cannot even relate to this. There isn’t even a “save” button anymore. We believe that there’s a class of stateful applications that are still in this 1990s era, where more than 80% of the code is about handling infrastructure failure to build resiliency for stateful applications. Every time an event happens, you load that state, apply that event, do a bunch of actions and then store that state back. This is where a majority of engineering goes toward: how to make that reliable, fast, and performant and protect it against all sorts of failures and corruptions. Developers shouldn’t even have to think they can ever lose their state. There are just these durable executions that never fail. And I think it’s completely going to change how engineers think about cloud-native systems. Why Managed Apache Cassandra? My co-founder Max and I come from a background of building messaging systems and middleware. Running storage systems is not our strength. So when we started the company as only two people, a key goal for us was to capitalize on our strengths of providing the best developer experience for Temporal users. Temporal has a server component and client SDKs, which most developers out there use for building applications. But how can people run those servers with minimum operational overhead? This is where the majority of the overhead for running Temporal is. We have a pluggable persistence model; we support , MySQL and Postgres as pluggable adapters. Cassandra is one of the adapters that has very nice scalability characteristics. A key value proposition for our users is the fact that they are running , and reliability is the key thing that they are looking for. So we do not take it lightly when we bring a new dependency into the Temporal fold. We ran over a month of evaluation for all sorts of persistence options. It was hands down. Apache Cassandra mission-critical applications DataStax Astra DB Some databases win on some features, others win on other features. But it wasn’t even about the technology in this case; it’s about the people. We believe bugs and failures are a part of life. It’s all about how you respond when an outage is happening. And this is where we believe Astra DB wins. There are so many similarities with the way DataStax treats its customers and the kinds of relationships that they build when it comes to operationalizing their databases. And that gave us confidence that this is a dependency that we want to invest in for a core part of the system. I don’t think we would be in a place where we are today if a technology like Astra was not there for us to capitalize and build on top of. Things like just operationalizing Cassandra, and getting stuff “done” alone would be at least a year-long project, and that is not even part of our core strength. For a company like us, where the key value proposition is reliability, if we cannot figure out a way to run and operationalize your storage in a reliable fashion, we don’t have a business. for Cassandra Forward, a free, two-hour virtual event happening on March 14 dives into all things Apache Cassandra. Register now By Patrick McFadin, DataStax Patrick McFadin is the co-author of the O’Reilly book 'Managing Cloud Native Data on Kubernetes.' He currently works at DataStax in developer relations and as a contributor to the Apache Cassandra project. Patrick has worked as chief evangelist for Apache Cassandra (he’s also a newly minted Cassandra committer!) and as a consultant for DataStax, where he had a great time building some of the largest deployments in production.

Can You Ignore Resiliency When Building Cloud Native Apps?

¿Se puede ignorar la resiliencia al crear aplicaciones nativas en la nube?

Pouvez-vous ignorer la résilience lors de la création d'applications cloud natives ?

क्या आप क्लाउड नेटिव ऐप्स बनाते समय लचीलापन को अनदेखा कर सकते हैं?

クラウド ネイティブ アプリを構築する際に回復力を無視できますか?

Você pode ignorar a resiliência ao criar aplicativos nativos da nuvem?

Bạn có thể bỏ qua khả năng phục hồi khi xây dựng ứng dụng gốc trên đám mây không?

构建云原生应用程序时可以忽略弹性吗？

How We Localized Our Website in 9 Languages in Under a Week — And So Can You

Using data from database collections or from a 3rd-party source can be a powerful tool to enhance your site's functionality. However, sending a lot of data to the browser from the server can be a time-consuming operation and negatively affect your site's loading time. Therefore, you want to minimize the amount of data that is sent from the server to the browser.  This article lists a number of approaches you can use, whether you're using a dataset or the Data API, to improve your site's performance. Download Only the Items You Need When retrieving data on a page, you should only retrieve the items that you need. If you need to display a large number of items, you should consider only retrieving some of the items at first and then more items when needed. For example, suppose you want to display items from a collection in a repeater. Instead of showing all the items from your collection when the page loads, you can start by showing only some of the items. If necessary, you can add a way to load more items or to navigate through pages of items. Elements Populated Using a Dataset Limiting the amount of data you retrieve when using datasets is easy. First, set the number of items to show in your repeater using the setting in your . This not only limits the number of items displayed but also limits the number of items retrieved by the dataset at one time. The number of items retrieved at one time is also known as the dataset's page size. Number of items to display dataset's settings If applicable, you should also so it only retrieves the items you need. set a filter on the dataset Next, you can optionally set up a way for site visitors to load more items or navigate through pages of items. This allows you to speed up the initial loading time of your page while still eventually displaying all items your site visitor wants to see. To do so, add a button or buttons to your page and set their click actions to the , , or actions. Load More Previous Page Next Page Learn more: Learn how to connect a button . here Learn more about dataset actions . here Elements Populated Using Code You can also limit the amount of data you retrieve when using code to populate elements. Start by using , such as and , to only query for relevant items. Then you can add the function to your query chain to only retrieve some of the relevant items at first. The limit you set also defines how many items are retrieved in each page of query results. When you need more items later, you can use the various , such as and , to retrieve additional pages of items. filtering functions eq() gt() limit paging functions of the query result hasNext() next() For example, here we populate a repeater with data from a query that only retrieves "active" items. We begin by only retrieving the first six items and show a "load more" button if there are additional items to show. When there are no more items to show, the "load more" button is collapsed. wixData ; queryResults;

$w.onReady( {
  queryResults = wixData.query( )
    .ascending( )
    .eq( , )
    .limit( )
    .find();

  $w( ).data = queryResults.items; (queryResults.hasNext()){ $w( ).expand();
  }
} ); {
  queryResults = queryResults.next(); data = $w( ).data;
  $w( ).data = data.concat(queryResults.items); (!queryResults.hasNext()){
    $w( ).collapse();
  }
} { $item( ).text = itemData.title;
  $item( ).background.src = itemData.pic;
} import from 'wix-data' let async ( ) function await "myCollection" "title" "status" "active" 6 '#myRepeater' if // load more button was set as collapsed on load '#loadMore' export async ( ) function loadMore_click event await let '#myRepeater' '#myRepeater' if '#loadMore' export ( ) function myRepeater_itemReady $item, itemData, index // set up repeater items as they are created "#titleText" "#container" Delay Loading Data Another approach that can be used when you have a lot of data you want to display is delayed loading. When using delayed loading, you first download a small number of items, which will load quickly, and present those items to site visitors. You can then download the rest of the data at a later time. For example, suppose you want to display items from a collection in a repeater. Instead of showing all the items from your collection when the page loads, you can start by showing only the items site visitors see at first. Typically, you want to download enough data to populate what a site isitor sees when the page loads (known as "above the fold"). Additional items, those that a visitor would have to scroll to see (known as "below the fold"), you can download in the background after the page has loaded. Elements Populated Using a Dataset Delayed loading of data when using datasets requires you to change the settings of the dataset and to add a little bit of code to your page. First, set the number of items to show in your repeater using the setting in your . Set it to the number of items that are shown above the fold. This not only limits the number of items displayed but also limits the number of items retrieved by the dataset at one time. The number of items retrieved at one time is also known as the dataset's page size. Number of items to display dataset's settings If applicable, you should also so it only retrieves the items you need.Next, add code to your page that incrementally downloads the rest of the items from your collection one page at a time and displays them in the repeater. set a filter on the dataset This code sets an event handler that runs when the dataset has loaded its first set of data. The event handler checks whether there are any additional pages of data to download. If there is, it downloads a page of data and then checks again, until there are no more pages left. $w.onReady( {
  $w( ).onReady( () => { ($w( ).getCurrentPageIndex() < $w( ).getTotalPageCount()) { $w( ).loadMore();
    }
  });
}); ( ) function '#myDS' async while '#myDS' '#myDS' await '#myDS' Elements Populated Using Code Start by using , such as and , to only query for relevant items. Then you can add the function to your query chain to only retrieve some of the relevant items at first. The limit you set also defines how many items are retrieved in each page of query results. Limit your query to the number of items that are shown above the fold. Once those items are loaded, you can use the various , such as and , to retrieve additional pages of items. filtering functions eq() gt() limit paging functions of the query result hasNext() next() For example, here we populate a repeater with data from a query that only retrieves "active" items. We begin by only retrieving the first six items, which take up all the space above the fold on our site. After those items are loaded, we query the remaining items and add them to the repeater as they are retrieved. wixData ; queryResults;

$w.onReady( {
  queryResults = wixData.query( )
    .ascending( )
    .limit( )
    .find();

  $w( ).data = queryResults.items;

  loadRemaining();
}); { (queryResults.hasNext()){
    queryResults = queryResults.next(); data = $w( ).data;
    $w( ).data = data.concat(queryResults.items);
  }
} { $item( ).text = itemData.title;
  $item( ).background.src = itemData.pic;
} import from 'wix-data' let async ( ) function await "Test" "title" 6 '#myRepeater' async ( ) function loadRemaining while await let '#myRepeater' '#myRepeater' export ( ) function myRepeater_itemReady $item, itemData, index // set up repeater items as they are created "#titleText" '#container' Download Only the Fields You Need When retrieving data on a page, you can retrieve only the specific fields that you need. Often times, you will be retrieving data from a collection or 3rd-party source, but only use a subset of the data you retrieve. On the server, in backend code, you can map the large set of fields to the smaller subset that you actually need, and then send only that smaller subset to the browser. For example, suppose you have a collection that contains a large number of fields. To display the information you have an index page that shows just a bit of information about each item. Then, when a site visitor clicks a link, you display the rest of the data on a page dedicated to displaying one item at a time. When loading the index page, there is no reason to retrieve all of the data that exists in the collection for each item since you will only be displaying part of that data. Instead, for the index page, you can retrieve the collection data in a . Then, in backend code on the server, you can map the retrieved data objects to objects with fewer properties, holding only the data you need. That way, a smaller amount of data needs to make the time-consuming trip from the server to the browser. backend web module { results = wixData.query( ).find(); results.items.map( { { : item._id, : item.title, : item.photo, : item.jobTitle, : item[ ]
    };
  } );
} // in backend/queries.jsw export async ( ) function getTeamData let await "Team" return ( ) => item return "_id" "name" "photo" "jobTitle" "link" "link-Team-title" Now, when you call your backend function from the browser, only the data you need is returned. You can use that data as usual to populate your repeater. {getTeamData} ;

$w.onReady( { data = getTeamData();
  $w( ).data = data;
} ); {
  $item( ).src = itemData.photo;
  $item( ).text = itemData.name;
  $item( ).text = itemData.jobTitle;
  $item( ).link = itemData.link;
} import from 'backend/queries' async ( ) function let await '#teamRepeater' export ( ) function teamRepeater_itemReady $item, itemData, index "#teamImage" "#teamMemberName" "#jobTitle" "#readMoreButton" When loading the item page, you don't need to add any extra code since you'll only be retrieving one item from your collection. Store Downloaded Data Instead of Refetching Sometimes, when a page is loading, it is better to download all the data you will eventually need and store it for later instead of downloading it incrementally as it is needed. This approach is often used when the data that is displayed will change based on a visitor interacting with it. Since you've downloaded all the data upfront, when you need to change the data that is displayed, the page transitions smoothly. If you would have to download new data every time a visitor interacts with the page, the page would react slowly and you might end up downloading the same data several times. To save some of the initial page loading time, you can combine this approach with only downloading the fields you need, as described above. For example, suppose you have an index page that displays a large number of items, but it is filterable, so they are not all shown at once. When a site visitor chooses a filter from a dropdown, the subset of items that you display changes. Here we can download all of the items when the page loads and store it in a global variable. When the filter changes, we don't have to download any new data. Instead, we just pull the relevant items from the data we already downloaded. Switching between filters will be very fast since all the work is done in the browser. Again, we retrieve the collection data in a . Then map the retrieved data objects to get only the fields we need. In this case, we added the field. backend web module department { results = wixData.query( ).find(); results.items.map( { { : item._id, : item.title, : item.photo, : item.jobTitle, : item.department, : item[ ]
    };
  } );
} export async ( ) function getTeamData let await "Team" return ( ) => item return "_id" "name" "photo" "jobTitle" "department" "link" "link-Team-title" Then, when the page loads, we call the backend function from the browser and store the retrieved data in a global variable. Every time we need to get a new subset of the data, we call the function which filters out the data we don't need. We call it once when the page loads and then every time the value in the dropdown element changes. getDepartmentData {getTeamData} ; teamData;

$w.onReady( {
  teamData = getTeamData();
  $w( ).data = getDepartmentData( );
} ); { teamData.filter( member.department === dept);
} { department = event.target.value;
  $w( ).data = getDepartmentData(event.target.value);
} {
  $item( ).src = itemData.photo;
  $item( ).text = itemData.name;
  $item( ).text = itemData.jobTitle;
  $item( ).link = itemData.link;
} import from 'backend/queries' let async ( ) function await '#teamRepeater' "Management" ( ) function getDepartmentData dept return => member export ( ) function departmentDropdown_change event let '#teamRepeater' export ( ) function teamRepeater_itemReady $item, itemData, index "#teamImage" "#teamMemberName" "#jobTitle" "#readMoreButton" Pass Data Between Pages Often you use the same data on more than one page of your site. Instead of retrieving the data on each page that you need it, you can retrieve it just once the first time you need it. Then, you can use the API to store the data to be used on other pages. wix-storage For example, here we get some data that will be used on multiple pages. This code can be used on each of those pages, or you can add it to the site code if you need the data on all pages. When the page is loading we check the local storage to see if it already contains data. If it does, we simply parse the string data in a JSON object and store it in the data variable to be used elsewhere on the page. If the data doesn't already exist in storage, we query it from a collection, stringify it, and store it both in the data variable to be used elsewhere on the page and in local storage to be used on other pages. {local} ; wixData ; data;

$w.onReady( {
  data = local.getItem( ); (data) {
    data = .parse(data);
  } { results = wixData.query( ).find();
    data = results.items;
    local.setItem( , .stringify(results.items));
  }
} ); import from 'wix-storage' import from 'wix-data' let async ( ) function "myData" if JSON else let await "myCollection" "myData" JSON In the example above we use local storage. Depending on your site's specific needs, you may want to use another type of storage. To do so, you simply substitute the type you want to use in the import statement. To learn more about the types of storage, see the . API Reference Use Dynamic Pages Sometimes, you create a page with data that doesn't necessarily need to be a dynamic page. Instead, you can use a regular page and add a dataset to it. For example, if you have an index page that shows all the elements from a collection, you can use a regular page with a dataset to retrieve and display your collection data. In such cases, it is often better to use a dynamic page anyway. You can set the dynamic page without any fields added to its URL so it does not filter the data and the page receives all your collection items. Because your page is a dynamic page, it is known that the page expects data and the data is therefore retrieved while the page is being rendered. On the other hand, when you use a regular page, data is retrieved much later. Use Bulk Data Operations When possible, use the bulk operations of the API instead of repeatedly calling the single-item version of the function. wix-data For example, instead of repeatedly calling to add an array of items to a collection one-by-one, you can call and add all of the items at once. insert() bulkInsert() Previously published at https://support.wix.com/en/article/velo-best-practices-for-improving-performance-in-wix-sites-with-data

Velo How-To: On Performance Optimization And Data

Since leaving the corporate world, and jumping into entrepreneurship I’ve founded three startups. In that time, I’ve seen my fair share of co-founders – both good and bad. Whether it’s in the co-founding teams I’ve built myself, or co-founding teams I meet thanks to the work I do at Altar.io. Through all of these experience, I’ve come to realise that the majority of successful co-founders share several key characteristics: The 8 Key Traits of a Great Co-Founder Technical Hard Skills Leadership Skills Passion & Commitment Zero Fear of Failure Fast Learner Lateral Thinker Alignment & Communication Obsessed with Perfection And while finding someone with all these traits won’t spell success, it will decrease your chances of failure. Throughout this article I’ll dig into these eight traits and share with you why they’re so important. Before I do that, however, I think it’s important to share three vital “ground rules” I’ve used when I need to find a co-founder: Rule #1: Intellectually & Personally Humble People I truly believe this trait is crucial not only when looking for a co-founder. Instead, this trait should be present in all the people we trust. Egocentricity can kill a startup. You need to find people who not only know their strengths but also know their weaknesses. Your co-founder needs to be able to delegate tasks to someone who is better at it than them, as opposed to doing themselves to save their ego. For example, if I’m building an MVP, I’m not going to code it myself for the sake of my ego. I’m going to delegate to someone who knows how to code because that will lead to a higher chance of a successful startup. In my experience, it doesn’t matter if you find a co-founder with all of the other traits I will talk about here. If they don’t have this essential one, they simply won’t work out. The next important point to note is that if you want to find the perfect co-founder, it’s going to take time. Rule # 2: Don’t be in a Rush to Find a Co-Founder –  it’s Not a Summer Date Picture this: you’re excited because of the great two months in front of you. You’re on Ipanema beach with an ice-cold Caipirinha enjoying the sunset and Kygo’s playlist in the background… You meet a good-looking person showing off their dancing skills on the patio. Yes! An expert dancer is exactly the kind of person you wanted to spend the summer with. You start dating, everything is going great, but summer is coming to an end. Naturally, both of you will come back to real life soon. Have you already planned for that? Of course not, great times make you forget any future problems! When it comes to your co-founder you’re in exactly the same position as you would be on that beach in Ipanema (maybe minus the Caipirinha). Everything is exciting, you’re meeting amazing people with great skills. You feel like Zuck Jr. But it’s important to remember that the first “great dancer” you meet may not be the best co-founder for you. Co-founding a startup is less like a summer romance, and a lot more like a marriage. You’re going to spend countless hours working right next to this person. Your relationship needs to weather any storm that comes your way. This brings me to one last important rule before we get to the list: Rule #3: Your Best Friend is Not Automatically the Best Co-Founder I’m not saying don’t launch a business with friends. There are times it can work well. There are some hurdles here to avoid, however. Firstly, if you want to pursue a business relationship with a friend, do they have the right technical skillset? Secondly, be honest with yourself. Can your relationship survive the struggles startups face? If the answer to either of these questions is no, don’t mix friendship and business. Or you may end up harming both. If the answer to both of these questions is yes, great! Just ensure you keep everything professional. Just because they’re your friend doesn’t mean you should ignore the best practices of onboarding a co-founder. In other words, everything still needs to be in writing – . and you should get a lawyer to help you with this Finally, here are the eight traits you need to consider when looking for a co-founder: 1. Technical Hard Skills Any successful startup needs hard-skilled people. It’s vital that you find a co-founder who is great at what they do. The easiest way to find and validate if someone is extremely good is to look for “proven experience.” By “proven experience” I mean the particular set of skills that are essential to create and grow a healthy business. It could be four successful startup exits or three IPOs. Of course, few such people exist out there! More realistically, it could be related to previous experiences in top high-tech firms or other activities successfully carried out in the past: A developer could have developed a game from scratch when he was 17 (bear in mind that tech-wise, specific complex sets of skills depend on the type of business); A marketer could have grown his blog about NBA players from 0 to 50k visitors per month while at Uni; A CEO could have gathered experience as the leader of a successful student association. My point is, you can build any type of house that you want but you need concrete for the foundation. If you don’t find a co-founder with the right hard skills, your house won’t endure the first strong gust of wind. 2. Leadership Skills Not only do you need to find a co-founder who is a rockstar in their field. You need to find a co-founder with the ability to lead. With any luck, it won’t be long before you are building a team. You and your co-founder will be responsible for inspiring and motivating them. Good leadership doesn’t just mean getting the job done. Good leadership also sets the tone of the working culture in your startup. 3. Passion & Commitment Building a startup is rarely smooth sailing. If your co-founder lacks passion, their commitment will wane when the going gets tough. This will lead to a breakdown in communication, resentment and your business will suffer. Therefore,  It’s vital that you find a co-founder who’s as passionate about what you’re going to build as you are (or at least a close second). 4. Zero Fear of Failure The ability to embrace failure is a crucial characteristic of any co-founder. However, to explain this better I first need to define what I mean by  “failure”. You might say that spending months of hard work on a product that doesn’t attract any customers is a failure. That doesn’t mean, however, that it wasn’t a valuable process. There’s always something you can learn from it. “Building a company is like jumping off a cliff and building an airplane on the way down.” – Reid Hoffman Entrepreneurship and startups are all about learning. Building a startup mirrors the behaviour of a living organism: when you’re ill, your body understands there’s a problem and so recreates newer cells. If you find out that your market needs something slightly different you iterate, you adapt. And startups are great at that! You should find a co-founder that behaves the same way. Research. Plan. Execute. Test. If something turns out to be unsuccessful, then iterate until you find the right one. It may sound a bit “techie”, but try to imagine your lives as startuppers as if you were software within the agile approach. Always iterating, always adapting. What if your co-founder makes an unsuccessful decision? Not a problem, as a Fast Learner (as we will see in the next section), they will take their experience into the next attempt, and try something different I believe that accepting failure well is an innate characteristic. Either a person has it or doesn’t. If he/she doesn’t, they should go for a regular job! 5. Fast Learner Now if you fail you learn. If you fail often in small tests, you learn fast and you improve quickly. You should find a co-founder who is comfortable with this process. You will be alone with them, sitting in your office making the main decisions. And believe me, some of them will have to be made quickly. You will need to embrace situations where you feel like you don’t have a clue how to solve certain problems. If you find a co-founder who’s a fast learner, they will have no problem doing this. They will focus on researching and analysing everything possible to find the best answer. There is another added benefit of a “fast learner” co-founder. Your co-founder will most likely be an expert in what they do. However, they should also be able to add insights into the other aspects of your business (technology, marketing, sales, etc.) If they’re a fast learner, they will quickly be able to keep up with the conversation. And before you know it they will have accrued enough knowledge to bring new ideas to the table. 6. Lateral Thinker You want to find a co-founder who is a trendsetter – not a trend follower. You want someone who can evaluate and analyse situations and find new opportunities that can prove fruitful. Just like Henry Ford in 1908. When everyone wanted faster horses, he launched the Model T. Just like Steve Jobs, who created a smartphone with one single button when everyone was still addicted to Blackberry’s keyboard. You want a co-founder that thinks like a customer. Every customer wanted (and still wants) faster ways of transportation. And people still want easy-to-use and powerful smartphones. As says in his article , “We are all consumers. We all know what we need, like and think is cool. One way to be a trendsetter is to think like a consumer. What products or services would you love to see?” Michael Templeman How to Be a Trendsetter 7. Alignment & Communication As I’ve already mentioned, you and your co-founder are about to spend a lot of time working with each other, exclusively. Therefore you need to find a co-founder you can have a conversation with. In the end, your co-founder is your partner – it’s important to connect on a personal level. “Good communication among co-founders is one of the main conditions for startups to live long enough to succeed.” More than this, you need to be on the same page when it comes to the critical aspects of your startup. By this I mean: Product & company roadmap Equity split and salary (for both the founding and future employees) Working/company culture (both now and in the future) Once you find a co-founder, you will both be responsible for these aspects as your company grows. And while I’m not saying you need to agree on everything from day one, you need to be aligned on these high-level factors. This requires trust and transparency. You need to be candid with each other without things descending into an argument. So talk, talk, talk. And then talk some more! If you’ve found the right co-founder, all conversations will be productive, even if you disagree. Talk, talk, talk. And then talk some more. All the discussions will lead to success if there is an endpoint.  If you reach it, as a banker would say – good fundamentals. Expert Tip: Always Issue Equity with Vesting To bypass any uncertainty when looking for your co-founder, there is one best practice I truly prefer: equity with a vesting period that has a minimum cliff. The “vesting period” is a period of time in which a person accrues the pre-agreed equity stake if he accomplishes a certain goal (the goal could just be being fully committed within the company). At the end of this period, the co-founder will be fully vested, meaning he will own the totality of the equity initially granted. The minimum cliff means that the vesting schedule is not enforceable until a certain period of time from whenever it was initially agreed. Let me state a simple example: 31st December 2020 – You have found your CTO and you’re planning to assign him 40% of your company. This 40% has a vesting period of 4 years and a minimum cliff of 3 months. That means that he will be assigned 10% each year and the vesting schedule will start on the 1st of April 2021. If he stays in the company, he will be assigned: 10% on 1/4/202210% on 1/4/202310% on 1/4/2024 The final 10% on 1/4/2025. At the end of the four years, he will own the totality of the equity initially granted. Again I would always recommend getting legal counsel to be on the safe side. 8. Obsessed with Perfection You should find a co-founder who is as obsessed with product/service perfection as you are. The main daily focus for both of you will be the product that you’re building. What do I mean when I say obsessed with perfection? I mean a commitment to making an innovative, disruptive, product that is better than your competitors’ (otherwise why are you doing it?). Customers are increasingly skeptical of lousy services – and can spot them quicker than you think. So, if you do something, be sure that all the aspects (UX, UI, Speed, Customer Service, Marketing) are well thought out beforehand and executed flawlessly. Justine Musk (Elon Musk’s former wife) said: “If you’re not obsessed, then stop what you’re doing and find whatever does obsess you.” Wrapping Up This article does not intend to be the recipe for a successful team because, well, there is no recipe. However, finding a co-founder with the above qualities will undoubtedly increase your chances of success. Just keep in mind that you probably aren’t going to find someone with all these characteristics on the first try. It will take time, and considerable effort. But when you find them, it will pay off, as Steve Jobs said: “Half of what separates successful entrepreneurs from the non-successful ones is pure perseverance.” Good luck! This article was originally published here .

8 Key Traits Of The Perfect Co-Founder

From the desk of a brilliant weirdo #1: . We’ve all heard of them. Burndown charts They are easy to understand. And make your team effective. But what are their flaws? What happens with a burndown chart when scope creep occurs? What about burnup charts? Find the answers to these questions and alike below. Without further ado: What is a burndown chart? A burndown chart is a measurement tool that displays the amount of work remaining alongside the time you have to wrap it up. The name "burndown" originates from decreasing the number of remaining tasks as you make progress. The "burndown" creates a downward line, a slope, that shows how many tasks are left before the final deadline hits. In an ideal world, the line would be straight; no impediments would have arisen during development. That's, however, rarely the case. A burndown chart consists of a vertical Y-axis and a horizontal X one. The latter displays the timeline whereas the previous shows the amount of work. Typically, the slope starts at the top of the chart glued to the Y-axis and "burns down" until it hits the ground, and all tasks are finished. Two types of burndown charts are available: a sprint burndown chart, focused on the iteration, and a product burndown one, showing the remaining work for the entire project. During a sprint planning session, all tasks are defined and put onto the sprint burndown chart's vertical axis. Instead of tasks, you can inject story points or work hours as well. On the other hand, if you use a product burndown chart, you'll have product backlog items displayed on the Y-axis and the number of sprints on the X-axis. A key reason for using burndown charts among agile teams is that it clearly illustrates work velocity. Velocity means the team's work efforts associated with the user stories or assigned tasks completed during the iteration. To calculate the team's work velocity, simply divide the amount of work completed by the number of days. To improve your work velocity, encourage the team to attend every scrum meeting; it brings team members on the same page. How to read a burndown chart? Step 1: Look at the X-axis Identify whether you have days, weeks, or months shown on the X-axis. Step 2: Now, consider the Y-axis Does it show tasks? Story points? Or work hours? Step 3: Identify the ideal line The ideal line is a projected slope that depicts how the team progress would look like in a perfect world. It acts as a guideline. Step 4: Follow the actual effort line Based on the ideal line, you can tell whether you are moving behind or ahead of schedule by comparing it to the actual effort line. Here are some sprint burndown chart examples: Ideal scenario Such a scenario illustrates a perfectly-organized team. The team isn’t behind schedule nor ahead of it. It wraps up the final task just in time. No adjustments are needed in this case. Still, a good scenario This is quite a common scenario with experienced agile teams. It shows that the team started slowly but eventually caught up. During the scrum retrospective, the team should come up with a solution to the late start so the burndown chart can look more like in the first scenario. Decent scenario This one indicates that the team started slowly and was moving behind schedule. Yet, it managed to finish the sprint in time. During the scrum retrospective, adjustments should be made... be it moving low-priority tasks to future sprints or back to the product backlog. Sh*t. Missed it again. The team has missed the deadline. In this case, the next sprint's capacity should be "burned down" or decreased, so the team can have time to complete tasks or story points from the previous sprint. There’s something wrong... In this scenario, the team might have overestimated the project’s timeline. The should help the team fix the estimations. scrum master That’s odd... This can be quite a tricky scenario. The team’s commitment has either decreased or the PO (product owner) has provided fewer stories than usual. The scrum master plays a vital role here and continually monitors the team’s dedication to the project and asks the PO to add more tasks to the sprint backlog if signs of slacking off appear. Ops, forgot about it. The team is working hard towards meeting the deadline but isn’t updating the burndown chart throughout the process, only at the end. Or perhaps the PO has added an amount of work equal to the completed; therefore the line has stayed flat. What is the average burndown rate? The average burndown rate, also known as the ideal line, guides the team throughout project development. It starts at the top of the Y-axis and ends at the right-most point of the X-axis. It’s worth mentioning that not all tasks might be known at the start of the sprint. The backlog schedule may change, which will reflect the burndown chart as well. Nevertheless, the team should focus on how much they deliver rather than how much work they’ve done. Scenarios exist where teams are only spinning their wheels; try to avoid such. Benefits of burndown charts Burndown charts are easy to understand. You can track your team’s progress only with a glance; no need to delve into complex math-driven scrum diagrams. The burndown chart is updated daily which means the SM (Scrum Master) can identify bottlenecks before they occur and prevent them from happening altogether. Product issues can also be addressed during scrum meetings so they don’t transform into bigger problems. “Being a problem solver, for me a burndown chart's main benefit is that it quickly alerts our teams about any potential bottleneck situations and problems.” - Rorie Devine, Founder and CEO at . GRO.TEAM Burndown charts can keep the team motivated as well. Seeing progress on a daily basis will keep the team dedicated to the project’s success. You can keep clients in the loop without having to chat over novel-long performance reports. Limitations of burndown charts Burndown charts rely heavily on accurate sprint planning. If estimates aren’t accurate, then the progress you make will be nothing short of spurious measurement. That is, if you’ve underestimated time requirements, you’ll constantly be behind schedule. On the other hand, if you’ve overestimated, the team will feel like they are ahead of schedule, even if that’s not the case. “The disadvantage of a burndown chart is that it often distracts teams from understanding what is going on under the surface as they focus on improving the chart itself. It leads to wrongly-prioritized backlog, unclear requirements, unrealistic expectations, and deadlines.” - Thierry Tremblay, CEO & Founder at . Kohezion A burndown chart can use any Y-axis units like work hours, story points, and tasks. It was initially designed with work hours. A tracking system of work hours can be useful but not much. It mostly measures activity rather than accomplishment. Team members don’t like recording their hours of remaining work. It feels like someone is always watching over their shoulder, which adds extra pressure to the already existing. Sometimes, putting stories on the Y-axis instead of tasks can turn out to be quite an ineffective practice. The reason is simple. Each story is different from the others; it requires different amounts of effort to be completed. Therefore, one story can take as twice the time as another story, but the burndown chart won’t indicate it; it’ll leave management confused as to why the team isn’t making any visible progress. Stories are typically larger than tasks and take longer to complete. Try to break your stories into smaller tasks and put those on the burndown chart. Big stories lead to a stair-shaped line that is inaccurate and ugly. “if a developer has a 10-hour task, and has burned 8 hours they might only be 20% complete but the burndown chart will show 80% complete. It gives the project manager an inaccurate view of progress." - Logan Speights, CTO at . Proxxy We know that backlogs change, work gets added, plans rarely go as planned, and teams get discombobulated. As a result, burndown charts fluctuate. They might trend upwards when extra tasks or story points are added, or stay flat. The downside is that management may construe it as slacking off. To avoid such situations, the scrum master needs to bring everybody on the same page by clearly communicating requirements and progress beforehand. Or you can use a burnup chart... What is a burnup chart? A burnup chart scales upward, and it's useful because it shows when more items are added to the sprint backlog whereas a burndown chart doesn't. A burnup chart illustrates the team's completed work compared to the total scope. It also tells whether you are behind or ahead of schedule, or whether any potential impediments are likely to cross your path. The burnup chart's vertical axis shows the amount of work, be it story points or work hours. And the horizontal axis represents the timeline in days, weeks, or months. Besides the ideal and the actual effort line, there's a third one, the scope line, which is flat except when more work is added to the backlog; then it trends upward. The difference between burndown and burnup charts The main difference between a burnup and a burndown chart is that the latter shows you how much work is remaining. In contrast, the previous tells how much work you've completed so far. When, in a burndown chart, scope creep occurs, the actual effort line may stay flat; thus, the client may question whether the team is actually working or idling. A burnup chart won't make clients doubt your team. Yet, if there are no changes in the scope, the simplicity of burndown charts is preferable. Burndown charts are better suited for sprint level projects, whereas burnup charts make more sense for long-term objectives, showing all the work completed so far. Burndown chart software Here you can find some that will help you create beautifully-designed burndown charts to manage your team’s progress effectively. project management tools Codegiant is a simply-designed project management software, mainly advertised to developers due to its extra features such as git repositories, built-in CI/CD, and robust documentation. Codegiant Codegiant’s issue tracker offers both Kanban and Scrum boards. What’s more, it has a free plan for up to 5 team members. Here are some of the features you can explore with Codegiant: Burndown charts + templates. Task status chart breakdown (complete, waiting for review, in progress, open). Task type chart breakdown (feature, hot fix, bug, improvement, blocker) Roadmaps. Sprints. Epics. Analyze your tasks’ performance. Tasks and subtasks. Tags, mentions, and comments. Time estimates. Import projects from Jira with our one-click Jira importer. ClickUp is another great project management tool that boasts a myriad of features. It recently raised $35 million in Series A which means it’ll be adding more features and refining existing ones. ClickUp ClickUp lets you create powerful burndown charts to track and communicate project progress clearly. ClickUp’s burndown charts illustrate a third line, a project progress line highlighting how your progress would look like if you were to continue at the same working pace. Some other features that ClickUp includes are: Burndown chart examples and templates. Sprints. Docs. Tables. Conversations. And more! Hygger deserves a place on this list due to its simplicity and a vast amount of features. Hygger Hygger’s kanban boards come with time tracking, swimlanes, work in progress limits, burndown reports & charts. More importantly, Hygger is designed with burndown charts and velocity reports. With them, you can keep your team on the same page so it can work unwaveringly and unflinchingly towards completion of the project. And here are other features Hygger brings to the table: Burndown templates and metrics. Timeline. Task lists. Kanban boards. Sprint boards. Swimlanes. WIP limits. Jira And, of course, . Dating back to circa 2002, Jira is one of the most recognized project management tools among developers. Due to its initial bug-tracking design, however, it isn’t quite suitable for non-tech folk. Jira Jira comes with robust reports and burndown charts. It’s trusted by more than 65,000 teams across the world. Here are some other features that you may find useful: Risk and release burndown charts. Dashboards. Roadmaps. Customizable workflows. Kanban and scrum boards. 3 Jira versions - Jira Align, suited for enterprises, along with Jira Core and Jira Software, mainly suited for smaller businesses. Mobile version is available as well. Craft If Jira seems a bit heavy for you, a great simplistic alternative to fill you with joy would be . Craft Craft can put your team on the same page as it helps you visualize clearly milestones ahead of you so no second guessing happens in your head. You can create new stories, add story points, custom fields, and effort to plan and prioritize. Other features that Craft offers: Burndown charts. Velocity charts. Learn tabs for user feedback. Roadmaps. User story templates. Product roadmap examples. “With Craft, everyone stays on the same page with clear milestones and sprint backlogs.” - Sam Cohen, CEO at . Gold Tree Way Yet, if you are the kind of person to relish his creations, you can create an Excel burndown chart yourself. you can find burndown chart templates for Excel and steps to follow to create one yourself. Here Conclusion Burndown charts are one of the best ways to track your team progress and make workflow adjustments when needed. You can also use burnup charts if scope creep happens frequently - burnup charts will keep your clients in the loop. Now that you know some cool software tools designed with burndown charts, go sign up for free and tell me what you think. Stay unparalleled

Burndown Charts: What Are They, and What Are Their Limitations?

March 13, 2020. I’ll remember this day as Charcoal Grey Friday in honor of my Costco sweatpants (thanks mother-in-law) and it being the hardest day of my career at GrowthHit . Please note that this is NOTHING in comparison to what healthcare workers and victims of COVID19 are going through right now.  It’s just a snapshot in time for me to reflect on. … Wife (text):  “I need to lay down.” Me (text): “Getting up. I can watch the girls.” It was noon on a Friday. My legs were weak and I was shivering through my sweatpants. As I sat up in bed, I caught a glimpse of the notification on my phone.  I already knew the email bomb that was waiting for me. But, this breakup email didn’t phase me.  I was immune to them at this point.  Because . . . In the past 48 hours, my growth marketing consultancy ( ) lost $400,000 in ARR (annual recurring revenue). I tested positive for COVID19. And we lost our childcare. GrowthHit LOSING $400,000 IN 48 HOURS How did this happen? Lets start with the money. At GrowthHit, some of our clients are startups that just raised a round of funding or they’re in the process of fundraising. This means their cash runways are short and their budgets are tight. Translation = They’re extremely fragile when the economy comes to a halt. The result: 6 clients paused (or stopped) working with us. 3 clients were cutting all costs 2 clients lost VC funding 1 client went out of business Ouch. Not to mention our pipeline of $300,000 in leads that instantly dried up. We went from almost hiring two people to vetting our P&L to save every last dime. As this is happening, I couldn’t even build up the energy to make a plan for my company. I was huddled under the covers because I was the sickest I’d ever been. But, it wasn’t from the lost business. I tested positive for COVID19. I’M A STATISTIC After two cross-country flights in two weeks, the travel caught up with me in the worst possible way. The exposure to Sea-Tac airport just weeks before Washington became the epicenter of the virus didn’t help. I was self quarantined in my house and away from my family. That was until my wife developed a fever that surpassed mine. Which leads to our immediate crisis. Something that quickly became priority #1 over my business and our health: . Our daycare closed Sh*t. My two daughters (2.5 and 6 months) were now running wild in Seattle. My business was imploding.  I had COVID19. My wife had a 102-degree fever. But that didn’t matter.  We had no childcare.  It was time to step up. DO YOU WANT TO BUILD A SNOWMAN? It was time to be Super F*ing Dad. Technically, it was time to be . (Frozen reference people.)  These little girls deserved some attention that wasn’t Daniel Tiger on a tablet or a box of Goldfish crackers. Prince Hans of the Southern Isles I dragged my unshowered self into the living room and tagged my wife out so she could rest. The oldest (West) was ready to build a snowman and I was going to help her. It was on! Step 1: Zombie-dad (yeah, me) puts the Anna Dress on West (2) Step 2: Dad puts Wests’ hair in a bun with the pink ribbon (not the purple ribbon) Step 3: Dad gives Wren (5 months) a clean-ish teething ring (and some tickles) in her bouncer. Step 4: Fire up FROZEN 2 on the TV. What happened next is what I can only (humbly) compare to the . Michael Jordan flu game West and I went on to deliver what some call the most moving 7-minute reenactment of FROZEN this decade. As my business was failing and my bowels were weakening, I had found myself twirling my 2.5-year-old daughter in the air to “Let it Go”. Oh, the symbolism. But, this is exactly where I needed to be.  Talk about perspective. A toddler’s uncontrollable giggle can cure almost anything. For a brief moment, I forgot that my business was falling apart and my body was about to collapse. After some PB&J sandwiches (no crust), I sipped imaginary tea with West who gave me some life-changing advice: Daddy, your hair smells.” But, what she really meant was: Dear Father, get better and save your company! An hour later, my wife tagged me out and I collapsed under the covers for a Zoom call with my team. They had questions and I didn’t have answers. I couldn’t think. All I could do was rest and hope my fever came down. PLEASE MAKE IT STOP The weight of what was happening was resurfacing. And I wasn’t up for the challenge. Not today. I just wanted this week to be over. I wanted my head to stop throbbing.  I wanted the email bombs to stop dropping. Running a business can be stressful. Especially, when you toss in the added layer of raising young kids.  Balancing client demands and toddler tantrums while trying to stay cool is an art. I can manage that.  But, nothing prepares you for this. Balancing client demands and toddler tantrums while trying to stay cool is an art. I can manage that.  But, nothing prepares you for this. As a bootstrapped founder, you work so hard to build up your recurring revenue so you can reinvest in new hires, site upgrades, SaaS tools & systems. It’s a slow grow compared to the VC model.  But, it’s damn fulfilling to take nothing and turn it into something.  I didn’t take a dollar from anyone to grow this business and I’m proud of that. I’ve never thought about quitting but that day f*ing hurt.  But quitting means that I would have to get a real job.  That ain’t happening. I knew I needed sleep. I knew my team was good. I knew that our clients loved working with us.  I just needed to turn off my phone and go to bed and get better. Surprisingly, I slept like a baby that night. The only good night of sleep I would see for a while. … 30 DAYS LATER Fast forward 30 days from and this feels like a different universe. Charcoal Grey Friday I have experienced 50,000 emotions in that short timeframe. As a paranoid founder, I already work pretty hard but this situation put me into overdrive. Honestly, I couldn’t stop my mind from wandering down a dark path about my business so I channeled that into work. It’s April 14th and my partner just slacked me this: We’re on pace for our best month ever for new clients. We have signed agreements with 4 partners in the past 14 days as we work to replace the business that had to put us on pause or cancel. But, how did we do that when the economy stopped and our lead pipeline dried up. HOW WE CLOSED $250,000 IN 30 DAYS Here’s my summary on how we started getting momentum. Eventually, I want to make this a separate post but here are the cliff notes: I’m extremely conservative with our cash reserves. This means I’m somewhat prepared for a doomsday . . . just not this extreme.  I’ve developed two scenarios based on our cash flow: 1) Dooms day: we lose all clients and 2) Current State: Keep our existing clients w/ no growth. This helped me project the actual runway we have in two scenarios. I felt much more in control of our new landscape after this. Do the Math: I knew I couldn’t do this alone. I tapped the shoulder of founder friends, advisors, and executive coaches to help me tackle this problem. Their input was invaluable. Seek Advice from Advisors: mentor hacking I wanted to lean on the side of taking action. I decided to document and share all my thoughts along the way to my little community. Stopped Consuming, Started Creating: I did daily chats with my COO and was transparent with my team and our sales and pipeline. Now isn’t the time to hide. Instead, enlist your smart people to help. That means giving them the right information. Over-communicate: After losing $400k ARR, we went above and beyond to be strategic partners to our existing clients.  It’s not about margins but being great partners. White-Glove Service for Existing Clients: We decided to double our ad spend and capture more leads. While overall demand is lower and people are pulling back, we decided it’s about . CPMs are lower and there are still companies that need our help. Let’s test. Do the Opposite of the Majority: playing offense Webinars. Paid ads. Free Audits. Those things work for us. We decided to go all in on what’s proven and known. No time for try and stand up unproven tactics. Double Down on What’s Working: I did a growth marketing talk a year ago that seemed like a waste of time. But, luck would have it that one of the attendees was interested. And they just so happened to reach out in April. Hallelujah. Timing & Luck: BUT, I’M STILL PARANOID We aren’t out of the woods yet and this post isn’t to be written as a celebratory final chapter. I am still paranoid as ever.  All of this can change in 48 hours . . . as I have quickly learned. Instead, this post is me capturing a crazy moment in time that I hope to look back on as one that truly paints the picture of what happened.  Too often, you read blog posts about the Monday morning quarterback version of a career. Those stories hide the honest truth, the uncertainty, and the thought process that went behind making decisions in real time. Hope this helps anyone else that’s trying to navigate these crazy times. Please share your story so other people can learn from you and not feel alone. TLDR: Hardest Day of My Career Lost $400k. Got sick. Childcare closed. Frozen duet with toddler. Rest is best. Closed some deals. Still paranoid AF.

I Lost $400k ARR and Tested Positive for Covid-19 on The Same Day

How we stopped memory intensive queries from crashing ElasticSearch At , we make heavy use of Amazon-hosted ElasticSearch for real time log analysis — everything from finding the root cause of production errors to analyzing the lifecycle of API requests. Plaid The ElasticSearch cluster is one of the most widely used systems internally. If it is unavailable, many teams can’t do their work effectively. As such, ElasticSearch availability is one of the top SLAs that our team — the Data Science and Infrastructure (DSI) team — is responsible for. So, you can imagine the urgency and seriousness when we experienced repeated ElasticSearch outages over a two-week span in March of 2019. During that time, the cluster would go down multiple times a week as a result of data nodes dying, and all we could see from our monitoring was JVM Memory Pressure spikes on the crashing data nodes. This blog post is the story of how we investigated this issue and ultimately addressed the root cause. We hope that by sharing this, we can help other engineers who might be experiencing similar issues and save them a few weeks of stress. What did we see? During the outages, we would see something that looked like this: Graph of ElasticSearch node count during one of these outages on 03/04 at 16:43. In essence, over the span of 10–15 minutes, a significant % of our data nodes would crash and the cluster would go into a red state. The cluster health graphs in the AWS console indicated that these crashes were immediately preceded by JVMMemoryPressure spikes on the data nodes. JVMMemoryPressure spiked around 16:40, immediately before nodes started crashing at 16:43. Breaking down by percentiles, we could infer that only the nodes that crashed experienced high JVMMemoryPressure ( ). Note this graph is unfortunately in UTC time instead of local SF time, but it’s referring to the same outage on 03/04. the threshold seemed to be 75% In fact, zooming out across multiple outages in March (the spikes in this graph), you can see every incident we encountered then had a corresponding spike in JVMMemoryPressure. After these data nodes crashed, the AWS ElasticSearch auto recovery mechanism would kick in to create and initialize new data nodes in the cluster. Initializing all these data nodes could take up to an hour. During this time, ElasticSearch was completely unqueryable. After data nodes were initialized, ElasticSearch began the process of copying shards to these nodes, then slowly churned through the ingestion backlog that was built up. This process could take several more hours, during which the cluster was able to serve queries, albeit with incomplete and outdated logs due to the backlog. What did we try? We considered several possible scenarios that could lead to this issue: Were there shard relocation events happening around the same time? (The answer was no.) Could be what was taking up too much memory? (The answer was no.) fielddata Did the ingestion rate go up significantly? (The answer was also no.) Could this have to do with data skew — specifically, data skew from having too many actively indexing shards on a given data node? We tested this hypothesis by increasing the # of shards per index so shards are more likely to be evenly distributed. (The answer was still no.) At this point, we suspected, correctly, the node failures are likely due to , causing nodes to run out of memory. However, two key questions remained: resource intensive search queries running on the cluster How could we identify the offending queries? How could we prevent these troublesome queries from bringing down the cluster? As we continued experiencing ElasticSearch outages, we tried a few things to answer these questions, to no avail: to find the offending query**.** We were unable to pinpoint it for two reasons. First of all, if the cluster was already overwhelmed by one specific query, the performance of other queries during that time would also degrade significantly. Secondly, queries that did not complete successfully wouldn’t show up in the slow search log — and those turned out to be what brought down the system. Enabling the slow search log from * (all indices) to our most popular index, so that when people ran an ad-hoc query on Kibana that only really needed to run on a specific index, they wouldn’t unnecessarily hit all the indices at once. Changing the Kibana default search index . We did a major upgrade from r4.2xlarge instances to r4.4xlarge. We hypothesized that by increasing the available memory per instance, we could increase the heap size available to the ElasticSearch Java processes. However, it turned out that based on , so our r4.2xlarge instances with 61GB of memory were more than enough and increasing instance size would have no impact on the heap. Increasing memory per node Amazon ElasticSearch limits Java processes to a heap size of 32 GB ElasticSearch recommendations So… how did we actually diagnose the problem? As it turned out, finding the root cause required accessing logs that weren’t available in the AWS console. After filing multiple AWS support tickets and getting templated responses from the AWS support team, we (1) started looking into other hosted log analysis solutions outside of AWS, (2) escalated the issue to our AWS technical account manager, and (3) let them know that we were exploring other solutions. To their credit, our account manager was able to connect us to an AWS ElasticSearch operations engineer with the technical expertise to help us investigate the issue at hand (thanks Srinivas!). Several phone calls and long email conversations later, we identified the root cause: . When these queries were sent to the ElasticSearch, the cluster tried to keep an individual counter for every unique key it saw. When there were millions of unique keys, even if each counter only took up a small amount of memory, they quickly added up. user-written queries that were aggregating over a large number of buckets Srinivas on the AWS team came to this conclusion by looking at logs that are only internally available to the AWS support staff. Even though we had enabled error logs, search slow logs, and index slow logs on our ElasticSearch domain, we nonetheless did not (and do not) have access to these warning logs that were printed shortly before the nodes crashed. But if we had access to these logs, we would have seen: [2019–03–19T19:48:11,414][WARN][o.e.d.s.a.MultiBucketConsumerService] and will throw an error in future versions. You should update the [search.max_buckets] cluster setting or use the [composite] aggregation to paginate all buckets in multiple requests. This aggregation creates too many buckets (10001) The query that generated this log was able to bring down the cluster because: We did not have a limit on the # of buckets an aggregation query was allowed to create. Since each bucket took up some amount of memory on the heap, when there were a lot of buckets, it caused the ElasticSearch Java process to OOM. We did not configure to correctly prevent per-request data structures (in this case, data structures for calculating aggregations during a request) from exceeding a memory threshold. ElasticSearch circuit breakers How did we fix it? To address the two problems above, we needed to: Configure the so individual queries have capped memory usages, by setting indices.breaker.request.limit to 40% and indices.breaker.request.overhead to 2. The reason we want to set the indices.breaker.request.limit to 40% is that the parent circuit breaker indices.breaker.total.limit defaults to 70%, and we want to make sure the request circuit breaker trips before the total circuit breaker. Tripping the request limit before the total limit means ElasticSearch would log the request stack trace and the problematic query. Even though this stack trace is viewable by AWS support, it’s still helpful to for them to debug. Note that by configuring the circuit breakers this way, it means aggregate queries that take up more memory than 12.8GB (40% * ) would fail, but we are willing to take Kibana error messages over silently crashing the entire cluster any day. request memory circuit breakers 32GB Limit ElasticSearch will use for aggregations, by setting search.max_buckets to 10000. It’s unlikely having more than 10K buckets will provide us useful information anyway. the number of buckets Unfortunately, AWS ElasticSearch does not allow clients to change these settings directly by making PUT requests to the_cluster/settings ElasticSearch endpoint, so you have to file a support ticket in order to update them. Once the settings are updated, you can double check by curling _cluster/settings. Side note: if you look at_cluster/settings, you’ll see both persistent and transparent settings. Since AWS ElasticSearch does not allow cluster level reboots, these two are basically equivalent. Once we configured the circuit breaker and max buckets limitations, the same queries that used to bring down the cluster would simply error out instead of crashing the cluster. One more note on logs From reading about the above investigation and fixes, you can see how much the lack of log observability limited our abilities to get to the bottom of the outages. Dear AWS ElasticSearch engineers, if you are reading this, we’d love to get more control and visibility into our clusters so we can be better equipped to maintain our clusters. Until then, for the developers out there considering using AWS ElasticSearch, know that by choosing this instead of hosting ElasticSearch yourself, you are . This will significantly limit your ability to troubleshoot issues, but it also comes with the benefits of not needing to worry about the underlying hardware, and being able to take advantage of AWS’s built-in recovery mechanisms. giving up access to raw logs and the ability to tune some settings yourself If you are already on AWS ElasticSearch, — namely, error logs, search slow logs, and index slow logs. Even though these logs are still incomplete (for example, AWS only publishes ), it’s still better than nothing. Just a few weeks ago, we tracked down a mapping explosion that caused the master node CPU to spike using the error log and . turn on all the logs immediately 5 types of debug logs CloudWatch Log Insights Thank you to , , , and for proactively jumping in and driving this investigation. Giving credit where credit is due, this blog post is really just a summary of the amazing work that they’ve done. Michael Lai Austin Gibbons Jeeyoung Kim Adam McBride Want to work with these amazing engineers? We are hiring ! If you like this post, follow me on Twitter for more posts on engineering, processes, and backend systems.

Stories, News & Mentions about TEAMME

Teamme’s Stories on HackerNoon