Revv is the self-learning, organized, analytical, and always alert partner that meets the everyday demands of business documentation

Revv.so

revvso

It does not matter what the challenges with building a company are; software is (almost) always the solution. At the start of September 2020, I set out to build with 2 of my co-founders. Every time we encountered a problem statement, there was always a SaaS solution to help solve our problem. Felt like someone in the world thought ahead of us all the time. Their work helped speed ours. The best part? To use those SaaS tools, we did not have to shell out a fortune. The low cost made us favor the buy decision in the 'build vs. buy' argument. Zluri In less than ten weeks of company formation, we see ourselves using more than 28 software subscriptions, and we have only five employees, including three co-founders, and our product is not released yet! Employee: Subscription Software ratio is now almost 1:6. I will be tracking how this ratio skews in the months to come as we expand the number of employees and customers. Like my tech co-founder would say, it is time we should have a 'software hiring, onboarding and exit' plan just like a 'talent-hiring, onboarding and exit' plan that has been in existence for a long time :) Before sharing the software stack that we have deployed or about to deploy, I want to share how we make software buying decisions in the current boot-strapped stage of zluri.com, Software that follows the freemium model based on either employee size or API calls or the number of active users is our first choice. It helps us spend $ only when we scale. Software that is part of the start-up ecosystem and offers a time-based, revenue-based, or funding-based discount is our second choice. Software that follows a 14-day or a 30-day trial-based approach is our third choice. Software that does not allow any trial but wants us to pay just after a demo to use it is not a choice unless we have used the software in the past, and buying decision is a no-brainer. From org stack to tech stack, the details are here. Organization Stack Communication - Slack - (Freemium) https://slack.com/ Email Suite - GSuite - (Previously used) https://workspace.google.com/ Expense Management - Zoho - (Freemium) https://www.zoho.com/expense/ Video conferencing for calls under 40 minutes - Zoom - (Free tier) https://zoom.us/ Marketing and Growth Stack Inbound Marketing – Hubspot - (Start-up plan) https://www.hubspot.com/ B2B Database – ZoomInfo - (Previously used) https://www.zoominfo.com/ Prospect and Talent Reach out - LinkedIn Sales Navigator - (Previously used) https://business.linkedin.com/sales-solutions/sales-navigator Keyword overview and SEO – SemRush - (Previously used) https://www.semrush.com/ Website Analytics – Google Analytics - (Free) https://analytics.google.com/ Adwords – Google Adwords - - (Pay per use) https://ads.google.com/ Content Management System – Netlify - (Freemium) https://www.netlify.com/ Content Correction – Grammarly - (Previously used) https://grammarly.com/ Customer conversation – Intercom - (Start-up plan) https://www.intercom.com/ HR Stack ATS and HRMS - Freshteams - (Freemium) https://www.freshworks.com/hrms/ Centralized Document Management - Revv - (Freemium) https://revv.so/ ESOP Management- Lets Venture - (Freemium) https://letsventure.com/ Healthcare for Employees - Plum - (Start-up plan) https://www.plumhq.com/ Employee Onboarding – Trello - (Freemium) https://trello.com/ Product Management Stack Product Management – ProductBoard - (Free trial) https://www.productboard.com/ Task Management – Asana - (Freemium) https://asana.com/ Tech Stack Project Management – Airtable - (Freemium) https://airtable.com/ Appointment Scheduling – Calendly - (Freemium) https://calendly.com/ Authentication – Auth0 - (Start-up plan) https://auth0.com/ Database – MongoDB - (Freemium) https://www.mongodb.com/ API – Postman - (Previously used) https://www.postman.com/ Tool building – Retool - (Freemium + Start-up plan) https://retool.com/ Application Monitoring – Sentry - (Freemium) https://sentry.io/ Email notification – Sparkpost - (Previously used) https://www.sparkpost.com/ Code review – Github - (Freemium plan) https://github.com/ At the current stage of our growth (or should I say the inception stage?), we set up these software apps. This is not even including the sales stack, customer success stack, and the billing stack that by itself will have 15+ SaaS apps at the minimum. I can already foresee the number of software that we will be using in the next six months to one year and all the hassles that come with managing so many software on my emails and slack! But I got to agree on one thing. If we had not taken this approach of moving to SaaS for our product building and company building, we would have conservatively taken thrice the time to reach where we have got now. In sum, software-first thinking to problem-solving has been empowering to us as an early-stage company, and I can only imagine how world-changing it could be for companies more prominent than ours.

Subscription-based Software (SaaS) is the Panacea for Almost Anything 

It all started out very simply: I was asked to make it possible for users to trade photos in the gallery. What surprised me when I learned that mobile phone browsers don't have drag & drop (DnD) built in? When I looked at the source, my project was the only one that used DnD. And I decided, for some reason, that my job was similar to the one already done. But it wasn't quite that easy. React-beautiful-dnd The previous implementation was for Y-axis DnD, and it doesn’t work well for the grid. But at the moment when I realized this, it was already necessary to implement the feature. And I decided to do it simply, following the example of . In fact, it's just splitting a one-dimensional array into chunks, and then the work goes on as with many one-dimensional arrays. react-beautiful-dnd-grid A short intro to react-beautiful-dnd React's beautiful DND consists of several base components. this is the place where the element is dropped; the component itself is implemented through the render children pattern. Dropzone: is a dragged element; the component itself is implemented through the render children pattern. Draggable a context for handlers (possibly handle several drop zones, etc.) DragContext: Basic usage is with X-axis DnD. My implementation was just an extension of this behavior, split images into chunks, then every chunk is a row (which is ), and every image is When I handle the onDragEnd event in , I just map the row (chunk) index and the index in a row to a one-dimensional array index.: Dropzone draggable. DragContext const originalIndex = destinationChunkIndex * maxItems + indexInChunk + (sourceChunkIndex < destinationChunkIndex ? -1 : 0); Everything was implemented, and the feature has already been under the radar for a couple of weeks, but then it was time for a design review, and they tell me that everything is bullshit. Revert it. In fact, the main problem was that if such a solution looks good with columns, then there are small problems with rows. For example, the fact that photos fly off the screen and, in general, there is no feeling that this is how it should be If you want, you can play on my playground. It’s possible that such a solution will be suitable for your case. https://codesandbox.io/p/github/pivaszbs/image-reordering-beautiful-dnd/draft/gifted-voice So I understand that I need a real grid realization that looks like this, so I decided to continue research. Polyfill realization Next, I implemented the feature on the desktop, and everything was very easy there because of the browser support for DnD, so I thought, why not use a polyfill? https://www.npmjs.com/package/mobile-drag-drop?embedable=true But then a surprise was waiting for me with the fact that the ondragover event was not supported in this polyfill, and I could not swap the pictures when the user moved them without additional implementation or working with it by hand. So I decided to skip this variant to save time. DnD kit It would seem that my existence is in vain and that I will never succeed. But the moment of truth came, and I saw a notification about a wonderful library on one of the channels in Telegram. https://dndkit.com/?embedable=true I was happy, looking at the size of the library and how beautifully the examples are implemented in the documentation. I immediately went to look at the examples on the playground. In addition to DnD support for grids, the library also supports accessibility and is very customizable. A short intro to DnD-kit I don’t want to observe everything, just the things that are needed for understanding my solution to this problem. I will observe , , and but it is an abstraction over primitives. DndContext, useDroppable, useDraggable (familiar words: it looks the same as react-beautiful-dnd but uses hooks instead of the render children pattern). If you want to know about primitives, SortableContext useSortable DragOverlay, useSensors, look at the docs provides information via context that is consumed by the hook. To be honest, it’s just items and sorting strategy (to understand when it’s needed to reorder items on the screen). SortableContext useSortable Hook is an abstraction that composes the and hooks. In my case, I can drop everything everywhere within my image container, and it should be reordered. So here, every rectangle is a place where we can drop an image. useSortable useDroppable useDraggable is a great thing for UX and animations. In my case, it shows the place where I will drop an image. DragOverlay hook for working with an abstraction to detect different input methods in order to initiate drag operations, respond to movement, and end or cancel the operation. In fact, it’s a helper for event handling (touch, keyboard, or mouse). useSensors Real-grid DnD implementation This example was perfect for me, so I could look at the sources. https://codesandbox.io/p/github/pivaszbs/image-reordering-beautiful-dnd/draft/gifted-voice However, it was long and difficult to mess with the sources, so I went back to the board. Step 1 According to the docs I made a small example with pictures. https://docs.dndkit.com/presets/sortable https://codesandbox.io/p/sandbox/react-image-reordering-grid-mobile-forked-w0wlnh?file=%2Fsrc%2FApp.tsx Step 2 Then I realized that the UX without delay is a so-so story and added activation constraints. https://codesandbox.io/p/sandbox/react-image-reordering-grid-mobile-forked-w0wlnh?file=%2Fsrc%2FApp.tsx Step 3 However, it just didn't take off, and a context menu popped up in Safari. So I added user-select: none https://codesandbox.io/p/sandbox/react-image-reordering-grid-mobile-forked-dwi8cb?file=%2Fsrc%2FImage.tsx Step 4 Then I needed DragOverlay in order for the user to understand where his picture would be. https://codesandbox.io/p/sandbox/react-image-reordering-grid-mobile-forked-revjso?file=%2Fsrc%2FApp.tsx Step 5 Next, I decided that it's worth trying to describe how, in the examples, to make the component sortable so that you can reuse abstraction instead of primitives. It was quite hard, but right now it’s better than in examples. https://codesandbox.io/p/sandbox/react-image-reordering-grid-mobile-ssnzd2?file=%2Fsrc%2FApp.tsx Conclusion I am very glad that you have come this far with me. I hope I was able to save you time (it was not an easy but interesting way). I think the future belongs to libraries like dnd-kit, with their small size, good tree-shaking, and customization. I think libraries like react-dnd and react-beautiful-dnd will become a thing of the past. Thank you for your time! Useful links https://dndkit.com/ https://docs.dndkit.com/ https://master--5fc05e08a4a65d0021ae0bf2.chromatic.com/?path=/story/presets-sortable-grid--basic-setup https://github.com/react-dnd/react-dnd https://github.com/atlassian/react-beautiful-dnd https://www.npmjs.com/package/mobile-drag-drop All sandboxes, step by step https://codesandbox.io/p/github/pivaszbs/image-reordering-beautiful-dnd/draft/gifted-voice https://codesandbox.io/p/sandbox/react-image-reordering-grid-mobile-forked-w0wlnh?file=%2Fsrc%2FApp.tsx https://codesandbox.io/p/sandbox/react-image-reordering-grid-mobile-forked-1thxdp?file=%2Fsrc%2FApp.tsx https://codesandbox.io/p/sandbox/react-image-reordering-grid-mobile-forked-dwi8cb?file=%2Fsrc%2FImage.tsx https://codesandbox.io/p/sandbox/react-image-reordering-grid-mobile-forked-revjso?file=%2Fsrc%2FApp.tsx https://codesandbox.io/p/sandbox/react-image-reordering-grid-mobile-ssnzd2?file=%2Fsrc%2FApp.tsx

React Image Reordering Grid Drag and Drop (Desktop and Mobile)

F1 Delta Time was a blockchain-based game developed by Animoca Brands that was offered to gamers, firstly in the beta form, between 2019-2022. The game went up in flames in March 2022, to much rejoicing from all NFT haters. But was this hate deserved? How much of a trainwreck was the game actually? This is my hypothetical post-mortem based on online evidence, with the aim to evaluate the value that was added to the game by implementing blockchain technologies. I haven’t played the game myself, and I honestly never cared about it, although I’ve been aware of it since 2019. At that time, I could not believe that a racing game could be built on blockchain. Now I am playing a lot of Hill Climb Racing 2, and I am completely convinced that you can build a racing game as good as Hill Climb Racing, on the blockchain. I urge Fingersoft to not take this as advice. How Exactly Does F1 Delta Time Work? From what is now possible to , F1 Delta Time was a browser racing game that utilized blockchain technology to assign exchange value to game assets. Racing is one of the most fast-paced genres by definition, and the only way blockchain could help was to support its economy. collect from YouTube participation in each race cost a relatively small amount of fungible tokens, akin to inserting a coin into the arcade machine. However, it included a certain element of skill, even if somewhat levelled down with expensive customization that followed a ‘pay-to-win’ trend. The game was ‘pay-to-play’: Initially, F1 Delta Time was built on Ethereum, which . To solve this problem, the game’s own fungible token, . can be used for participating in races and buying cars and car parts on open marketplaces based on Ethereum and Polygon. A part of the supply was airdropped directly to players, while the rest of the ‘monetary reserve’ was allocated to future prize pools and could be earned by winning races and lending out racing tracks to other players to compete. first became unusable in the summer of 2020 REVV, was introduced in September 2020 This token Surprisingly, as compared to many other ‘minor altcoins’, the price of the REVV token during its existence, although it naturally followed major cryptocurrency price trends, as well as major hype-generating events such as big sales in the first year of the game’s existence (Fig.1). has proven to be relatively stable The unique selling point of F1 Delta Time came from the official collaboration with Formula 1® and the value that was associated with the brand. This collaboration made F1 Delta Time a premium product and justified the high costs of its non-fungible tokens that represented Formula One cars and drivers. Several notable purchases have established F1 NFTs among on the already bubbling market. The first one happened in May 2019, long before the official launch of the game and even before the REVV altcoin was introduced. The buyer, then known under the name ‘ ’, , for the equivalent of $69 million from Beeple at Christie’s. the most expensive ones MetaKovan would later be revealed as Vignesh Sundaresan the same person who would later purchase the most expensive art NFT to date Back then, in 2019, MetaKovan paid the equivalent of for the unique race car in F1 Delta Time. The car had its own name ‘1-1-1’ and was all covered in digital diamonds. Notably, in his interview with Jon Jordan for the Blockchain Gaming World podcast, MetaKovan has described one more way to assign value to NFTs, to which we will return in our future cases: the value of a story. $111,000 in ETH The second, even more expensive, the sale happened in December 2020, three months after the game went public. , and he paid 9 million REVV (223,000 dollars at the time) for the token that represented a track segment for the Grand Prix of Monaco. As we already mentioned, the owner of a track segment could generate passive income by collecting a share of the racing fee when other players used this track for a race. Vignesh ‘MetaKovan’ Sundaresan was, again, the buyer There were s later, which broke the record set by MetaKovan, but we will use these two sales as most showing examples of the value of NFTs comes. other major sales of F1 NFT The question we are exploring here is how important the value of a brand is in the world of NFTs. F1 is a unique example of how this value went to zero overnight. Animoca Brands received a crushing blow to its reputation when of the 3-year licensing agreement with Formula 1 on March 15, 2022. they announced the end The game was shut down the next day, although its former players will still be able to swap their F1 Delta Time cars for other assets by July 31, 2022. The PR backlash resulted in at least a month of negative press from every gaming website beyond the crypto corner of the internet. Now, when the dust has settled, it may be that Animoca Brands is still going strong in terms of blockchain gaming - and even the assets that should be considered worthless without the power of a brand are still branded and up for sale after two months since the end of the licensing agreement. Even though the game itself can’t be played - only a line of code shows up in the browser where the playground for most expensive NFTs used to be - branded game NFTs are still available on OpenSea, available for purchase (see Fig. 3). Even the Monaco racing track that belongs to MetaKovan is still listed - to be precise, , now representing nothing but the loss of 9 million REVV, is still worth about $250,000 in May 2022. The image file still remains on the server, though, as well as all other digital images that represent deprecated game assets, and rare transactions still take place on OpenSea. the .png render of the track It may be that the value of a brand does not disappear with the end of licensing agreement. Even more, its role in the valuation of game assets may not have been as important as the critics suggest. What F1 cars and drivers have actually lost - in a rather painful way - is their utility value, that is, the ability to use assets productively in the game. For example, MetaKovan can’t generate passive income by lending out of the Monaco track segment. Of course, this .png will be deleted one day after the server clean-up, - but the same is true for many other unique and premium NFTs in many reputable projects that have, in Bondian terms, no time to die, although they may as well die another day. However, legendary and exclusive cars and drivers still retain potential exchange value: for instance, MetaKovan can still sell his 1-1-1 car on OpenSea. To make it almost actually immutable, the visualization of this car NFT on OpenSea is currently . the .png file an (unlisted) YouTube video Is F1 Really A Failure? It has been definitely painted as such in the media. However, if we look at the game statistics , it appears that the game’s popularity had been fading for many weeks already before the partnership was discontinued. available on DappRadar The number of daily players rarely exceeded 10 since September 2021 - for 6 months already - which would not be enough to continue a costly partnership with Formula 1. Of course, these are only the statistics that are publicly available at DappRadar, and they are already quite buggy, but there is no reason to suggest that the game was more popular than that. In the meantime, Animoca Brand launched its own racing game REVV Racing in August 2021, as the hype around F1 Delta Time was fading. It is very likely that the remaining players of F1 Delta Time have moved to that game even before the closure. In terms of player engagement, by far outpaced F1 Delta Time, although we do not have the data about how profitable it was for the developer or for an average player. REVV Racing As of May 2022, the collection of amounted to 167,000 items that belonged to 59,400 players. This is a success if we compare it to F1 Delta, which , and which belonged to 1,800 players, which is the cumulative number of all players during the lifetime of the game. REVV Racing cars on OpenSea only had less than 4,000 cars This large number of REVV Racing players can be explained by : everybody who had 8,000, 12,000, and 20,000 REVV tokens in their wallets would also get one, two, and three free new cars. Even though these were still considerable investments (8,000 REVV would amount to 1,137 USD at the time of airdrop, July 16, 2021), many free cars would go to the secondary market, and even more new cars would be minted and distributed later. From the viewpoint of an outsider, it looks as if the company moved from monetizing through ultra-wealthy ‘whales’ to a wider, poorer, but also more active and motivated player base. the airdrop rules Why communicate ‘deep regret’, then? The main problem with crypto games today is that, due to the rapid speed of the NFT scene, many of their creators don’t develop long term memory, so they never learn (or maybe, they are just not used to hiring the people who actually do the work of development and marketing, for the real money, on a long term basis). A similar event already happened in 2018 in CryptoKitties - the first popular blockchain-based game that also tried cooperating with sports brands at some point. In early May 2018, the company prepared to launch a marketing campaign CurryKitties, to celebrate their first NFT based on a living celebrity, the NBA player Stephen Curry. The deal was canceled at the last moment about the role of Stephen Curry in the promotional campaign. The basketball-themed kitties were already pre-programmed to be minted by smart contracts, and Stephen Curry was replaced by at the last minute. Although some fallout from the CurryKitties could be observed in social media, it was by far incomparable to the grilling that F1 Delta Time received from all kinds of media in spring 2022. due to a misunderstanding a generic character Swish Based on that, the devil’s advocate in me suggests that Animoca Brands should have communicated smugness, not regret, in their public announcement. Anything along the lines of “Formula 1 is not good enough for us” would please their core player base and provide less food for the trolls. Griefing could be easily redirected at the former partner, whose reputation is by no means squeaky clean. In the end, if the value of a brand does not convert into other types of value in this particular community of players, why keep this brand? How Important Is the F1 Disaster At All? For the company that has the word ‘Brands’ in its name, and describes its mission as bringing premium brands into the blockchain and NFT space, - yes, it is a big screw-up in terms of PR. However, their other game REVV Racing seems to be doing really well on the ‘play-to-earn’ scene, based on publicly available information. There’s no value in that brand, but the main point is that it perfectly communicates the message that sells right now: this is where you can earn minor altcoins by playing a simple racing game. As you can see, upon a very rough calculation, the price of REVV is well correlated with the number of active players. Moreover, as the new crypto winter is coming, we are about to see what will happen to the game if the price of REVV goes down. The number of active players after that will demonstrate how much of REVV’s value is utility value in the game, and how much is exchange value, boosted by speculation, lending, and borrowing, as in . the recent case of Axie Infinity Thank you for reading! We are living in a time when I don’t even want to expose my Ethereum wallet for possible donations because some of you might want to send me an exploding NFT. However, let me know if you want to see this research continued in a more academic manner. It will be even more fun to revisit this case after July 2022, when the migration of former F1 Delta Time players is finished. The statistics here are super basic and only used to illustrate very obvious trends. It would take much more effort to collect better data and produce objective conclusions, and I have to do other things right now. See you when I’m a bloody Doctor of Philosophy in Communications!

F1 Delta Time: The Value Of A Brand

La necesidad de extraer datos de sitios web está aumentando. Cuando realizamos proyectos relacionados con datos, como el monitoreo de precios, análisis de negocios o agregador de noticias, siempre tendremos que registrar los datos de los sitios web. Sin embargo, copiar y pegar datos línea por línea ha quedado desactualizado. En este artículo, le enseñaremos cómo convertirse en un "experto" en la extracción de datos de sitios web, que consiste en hacer . web scraping con python Introducción El web scraping es una técnica que podría ayudarnos a transformar datos HTML no estructurados en datos estructurados en una hoja de cálculo o base de datos. Además de usar Python para escribir códigos, acceder a los datos del sitio web con API o como son otras opciones alternativas para el web scraping. data extraction herramientas Octoparse Para algunos sitios web grandes como Airbnb o Twitter, proporcionarían API para que los desarrolladores accedan a sus datos. API significa interfaz de programación de aplicaciones, que es el acceso para que dos aplicaciones se comuniquen entre sí. Para la mayoría de las personas, API es el enfoque más óptimo para obtener datos proporcionados por el propio sitio web. Sin embargo, la mayoría de los sitios web no tienen servicios API. A veces, incluso si proporcionan API, los datos que podría obtener no son los que desea. Por lo tanto, escribir una secuencia de comandos de Python para crear un rastreador web se convierte en otra solución poderosa y flexible. Entonces, ¿Por qué deberíamos usar python en lugar de otros idiomas? Como sabemos, los sitios web se actualizan rápidamente. No solo el contenido sino también la estructura web cambiarían con frecuencia. Python es un lenguaje fácil de usar porque es dinámicamente imputable y altamente productivo. Por lo tanto, las personas pueden cambiar su código fácilmente y mantenerse al día con la velocidad de las actualizaciones web. Flexibilidad: Python tiene una gran colección de bibliotecas maduras. Por ejemplo, las solicitudes, beautifulsoup4 podrían ayudarnos a obtener URL y extraer información de las páginas web. Selenium podría ayudarnos a evitar algunas técnicas anti-scraping al dar a los rastreadores web la capacidad de imitar comportamientos de navegación humanos. Además, re, numpy y pandas podrían ayudarnos a limpiar y procesar los datos. Potente: ¡Ahora comencemos nuestro viaje en web scraping usando Python! Paso 1: Importar la biblioteca de Python En este tutorial, le mostraremos cómo scrape las reseñas de Yelp. Utilizaremos dos bibliotecas: en bs4 y en urllib. Estas dos bibliotecas se usan comúnmente en la construcción de un rastreador web con Python. El primer paso es importar estas dos bibliotecas en Python para que podamos usar las funciones en estas bibliotecas. BeautifulSoup request Paso 2: Extraer el HTML de la página web Necesitamos extraer comentarios de “ ”. Primero, guardemos la URL en una variable llamada URL. Entonces podríamos acceder al contenido de esta página web y guardar el HTML en "ourUrl" utilizando la función https://www.yelp.com/biz/milk-and-cream-cereal-bar-new-york?osq=Ice+Cream urlopen() en la solicitud. Luego aplicamos BeautifulSoup para analizar la página. Ahora que tenemos la "soup", que es el HTML sin formato para este sitio web, podríamos usar una función llamada para limpiar los datos sin procesar e imprimirla para ver la estructura anidada de HTML en la "soup". prettify() Paso 3: Ubica y Scraping las reseñas A continuación, deberíamos encontrar las reseñas HTML en esta página web, extraerlas y almacenarlas. Para cada elemento en la página web, siempre tendrían una “ID” HTML única. Para verificar su ID, necesitaríamos INSPECT en una página web. Después de hacer clic en "Inspeccionar elemento" (o "Inspeccionar", depende de diferentes navegadores), podemos ver el HTML de las revisiones. En este caso, las revisiones se encuentran debajo de la etiqueta llamada "p". Entonces, primero usaremos la función llamada find_all() para encontrar el nodo padre de estas revisiones. Y luego ubique todos los elementos con la etiqueta "p" debajo del nodo padre en un bucle. Después de encontrar todos los elementos "p", los almacenaríamos en una lista vacía llamada “review”. Ahora tenemos todas las reseñas de esa página. Veamos cuántas reseñas hemos extraído. Paso 4: Limpia las reseñas Debe tener en cuenta que todavía hay algunos textos inútiles como “ ” al comienzo de cada revisión, “ ” en el medio de las revisiones y “ ” en Fin de cada revisión. “ ” representa un salto de línea simple. No necesitamos ningún salto de línea en las revisiones, por lo que tendremos que eliminarlos. Además, “ ” y “ ” son el principio y el final del HTML y también debemos eliminarlos. Finalmente, obtenemos con éxito todas las revisiones limpias con menos de 20 líneas de código. Aquí hay solo una demostración para scraping 20 comentarios de Yelp. Pero en casos reales, es posible que tengamos que enfrentar muchas otras situaciones. Por ejemplo, necesitaremos pasos como la paginación para ir a otras páginas y extraer los comentarios restantes de esta tienda. O también tendremos que extraer otra información como el nombre del revisor, la ubicación del revisor, el tiempo de revisión, la calificación, el check-in ...... Para implementar la operación anterior y obtener más datos, necesitaríamos aprender más funciones y bibliotecas como el selenio o la expresión regular. Sería interesante pasar más tiempo profundizando en los desafíos del web scraping. Sin embargo, si está buscando algunas formas simples de hacer scraping web, podría ser su solución. Octoparse es una poderosa herramienta de web scraping que podría ayudarlo a obtener fácilmente información de sitios web. Echa un vistazo a este tutorial sobre . Octoparse cómo scrape comentarios de Yelp con Octoparse ¡No dude en cuando necesite una poderosa herramienta de web scraping  para su negocio o proyecto! contactarnos Previously published at http://www.octoparse.es/blog/web-scraping-con-python

Web Scraping con Python: Guía Paso a Paso

[Photo by on ] rawpixel Unsplash A repeatable sales model builds the platform to scale, but it can take experimentation and intensive research before you hit on one that’s truly sustainable. Here’s how to do it. If your business-to-business (b2b) company’s revenue generation is built on converting a few random cold calls into prospects and/or selling the same stuff to the same customers over and over again, it’s time to do something different. You’ll know that you’ve created a scalable sales model when: You can add new hires at the same productivity level as the entrepreneur or the sales leader. You can increase the sources of your customer leads on a consistent basis. You have a sales conversion rate and revenue that can be forecasted consistently. The cost to acquire a new customer is significantly less than the amount you can earn from that customer over time. Customers get the right products in the right place and at the right time. The harsh reality is that the average U.S. company loses about 50% of its customer base which means creating a path forward that must include a plan for repeatable, sustainable b2b sales is no longer a luxury — it’s a must-have. every year, Here are four ways to start doing this today: Define and design your authentic purpose. Every company needs to pin down “why we do what we do.” That’s the company’s North Star, guiding every aspect from recruitment to customer management to product development and sales. A strong purpose drives growth and profitability. For instance, an investment in the (a list of the world’s 50 highest-performing companies) over the past 10 years would have been 400% more profitable than an investment in the S&P 500. Stengel 50 In order to achieve sustainable success, companies must repeatedly reexamine their sense of purpose and make sure the organization serves it well. An authentic and inspiring purpose allows for: A constant, consistent sense of focus A strong emotional engagement both within the company and with its customers and partners Continuous, pragmatic innovation Sales and marketing experts often talk about “unique selling propositions,” or “USP,” which as the “factor or consideration presented by a seller as the reason that one product or service is different from and better than that of the competition.” defines Entrepreneur A company’s authentic purpose gives rise to its USP. When a business has a clear vision, it’s easier to create products and services of value. Revlon founder Charles Revson, for instance, always used to say that he sold hope, not makeup. Start right now by examining your USP. Differentiation comes from packaging your know-how (i.e. your intellectual property) into repeatable products and services that solves critical customer problems. Take an honest look at your current sales process. “You can’t fix what you don’t know is broken,” is a quote found on motivational posters and mugs, and it’s very relevant for B2B companies that want repeatable sales, but that don’t know how to go about getting them. Take an honest look at what you’re doing now, including the last 7–10 deals that closed. Where did the customer come from? What steps were taken to close the deal? How did the customers interact with your company? How long did it take? How much time elapsed between each of those steps? Use the answers to analyze your process and ferret out the gaps (i.e., a lead nurturing and closing process that takes too much time, or not enough regular customer touchpoints). Then, come up with a plan that addresses these issues as a first step in the right direction. Start right now by assessing your current sales process, asking yourself the above questions, and honing your process in a way that better meets customers’ needs while also contributing to your firm’s bottom line. Energize your customer renewal and order upsell process. B2B companies have a stable of customers that they sell the same stuff to over and over again. In many cases, customers don’t even knowthat they could be buying more (and different products/services) from you because they have Unless he’s visiting your frequently-updated (uh-hem!) website on a regular basis, for example, that electrical contractor probably doesn’t realize that your distribution firm recently added kitting services to its lineup. Someone has to tell him, and that step should be part of your firm’s order upsell approach. no idea that you carry them. An often-overlooked aspect of the sales cycle, upsells and renewals are both strategic sales processes that help you grow revenue and gain more market share. Ignore this aspect of your B2B business and it will quickly fall prey to the statistics (50% of buyers exiting annually) and a host of competitors that are pretty good at bundling products, switching up their offerings, and upselling goods and services. Start right now by coming up with a list of additional products and services that can be upsold to customers who are already buying from your firm on a regular basis. Show-and-tell customers that you care about their businesses. Every B2B company is operating in a world where just “providing” products and services isn’t enough to create a sustainable sales channel. Where companies in the past may have been able to get away with putting their needs (e.g. revenue growth) ahead of their customers’ needs (e.g. current state and readiness), this attitude just doesn’t cut it anymore. To truly become your customers’ trusted advisor and partner — and to keep them coming back for more and referring your firm to others — you have to care about their business as much as you do yours (if not more than). When clients pick up on this, their loyalty levels rise exponentially and everyone wins. Start right now by reaching out to a handful of customers to ask them what their biggest pain points, and then think of three ways to either directly or indirectly help them address these issues. Copyright © 2018 by Faisal Hoque. All rights reserved. . . . . . I am an . Founder of and other companies. Shadoka enables entrepreneurship, growth, and social impact. Author of “ ” (McGraw Hill) and “ ” (Motivational Press). Follow me on Twitter @ . entrepreneur and author SHADOKA Everything Connects — How to Transform and Lead in the Age of Creativity, Innovation and Sustainability Survive to Thrive: 27 Practices of Resilient Entrepreneurs, Innovators, and Leaders Faisal Hoque Use the Everything Connects leadership app and Suvvive to Thrive resiliancy app for free.

How To Make B2B Sales Sustainable

Creating long-term value with limited resources is a huge challenge for entrepreneurs, but it’s hardly a novel one. My grandmother, who lived in a remote village in Bangladesh, was barely five feet tall, skinny as a rod, and very soft-spoken. She could barely read or write and never had a formal education, yet she successfully managed a farming and sharecropping business, overseeing a network of farmers, merchants, and seasonal workers, all while raising nine children and keeping a household in order. To do that, she needed to create long-term value from the work she directed without exhausting the finite resources at her (and her community’s) disposal. Even though circumstances are very different for modern entrepreneurs, the fundamentals of sustainable growth remain the same. Here are seven of them. AUTHENTIC PURPOSE Every company needs to pin down “why we do what we do.” That’s the company’s North Star, guiding every aspect from recruitment to customer management to product development and sales. A strong purpose drives growth and profitability. For instance, an investment in the (a list of the world’s 50 highest-performing companies) over the past 10 years would have been 400% more profitable than an investment in the S&P 500. Stengel 50 In order to achieve sustainable success, companies must repeatedly reexamine their sense of purpose and make sure the organization serves it well. An authentic and inspiring purpose allows for: A constant, consistent sense of focus A strong emotional engagement both within the company and with its customers and partners Continuous, pragmatic innovation Sales and marketing experts often talk about “unique selling propositions,” or “USP,” which as the “factor or consideration presented by a seller as the reason that one product or service is different from and better than that of the competition.” defines Entrepreneur A company’s authentic purpose gives rise to its USP. When a business has a clear vision, it’s easier to create products and services of value. Revlon founder Charles Revson, for instance, always used to say that he sold hope, not makeup. A POWERFUL BRAND If you want to create a scalable business, you have to understand how crucial it is to build brand equity and emotional connections with customers. It’s those attachments that link customers to your products and will keep them returning to you. Building a brand is about developing and sustaining those relationships over time. Here are some basic rules to with your products and brands: connect, shape, influence, and lead . The surest road to product failure is to try to be all things to all people. Choose your target audience . Make your audience feel an emotional attachment to your brand that’s grounded in confidence in your products. Connect with the public . A simple, inspirational message is far more influential than one that tries to highlight too many product features, functions, or ideas. Inspire your customers No marketing plan can rescue a brand identity that isn’t fully formed. Don’t have much marketing budget to speak of? Create compelling content for publisher and social media sites to start generating awareness among target customer bases, and build up. PARTNERSHIP AND COLLABORATION Doing everything yourself can be tempting in the beginning when funds are few and ambitions high. While there’s nothing wrong with a hands-on approach, taking on more than you can handle, especially in areas where you lack experience, can be damaging. In the era of the global freelance economy, it isn’t difficult to find talented expertise, but you have to know where to find them. There are now dozens of that provide specialized resources from design, development, and sales to finance, legal services, and banking. The best part is that you can try small projects at low investments. The trick is knowing exactly what you want done and putting resources towards accomplishing tangible goals. websites and online marketplaces CUSTOMER RETENTION As Emmet and Mark Murphy write in their book , acquiring new customers can cost an organization around five times more than retaining current ones. In fact, a 2% increase in customer retention can have the same effect as decreasing a company’s costs by 10%. To put it another way, reducing customer defection rates by just 5% could by 25% to 130%, depending on the industry. Leading on the Edge of Chaos increase profitability According to the and the : U.S. Chamber of Commerce U.S. Small Business Administration The average business in the U.S. loses around 50% of its customer base every five years. Companies are four times more likely to do business with an existing customer than a new customer. The likelihood of selling to an existing customer is 60–70% whereas it’s just 5–20% for a new customer. Successful retention starts with the initial contact a business makes with a customer and continues throughout the lifetime of the relationship. that for certain industries, a 10% increase in customer retention is roughly equivalent to a 30% increase in a company’s value. Bain Capital has even estimated COMMUNITY A business ecosystem is an economic community of organizations and individuals that interact in countless ways. These ecosystems encourage companies to evolve their capabilities competitively. Sometimes an ecosystem can sprout up around a product, like the range of cases, headphones, and other paraphernalia for mobile devices. Similarly, ecosystem thinking has become a cornerstone of web publishing — a broad swath of unpaid contributors create content for popular outlets in exchange for growing their own readerships and developing personal brands. Ecosystems are crucial to sustainable growth because they provide the structure that surrounds and supports the businesses within them. They spread “stakeholdership” out from the business and into society, like it did for my grandmother with her farming community. REPEATABLE SALES Creating a unique product and brand isn’t enough. It takes repeatable sales processes to create a scalable business. It’s one thing to sign up a few customers; it’s another thing to design and implement sales processes that can be successfully deployed again and again at ever greater scale. You’ve created a scalable sales model when: You can add new hires at the same productivity level as the entrepreneur or the sales leader. You can increase the sources of your customer leads on a consistent basis. You have a sales conversion rate and revenue that can be consistently forecast. The cost to acquire a new customer is significantly less than the amount you can earn from that customer over time. Customers get the right products in the right place at the right time. A repeatable sales model builds the platform to scale. But it can take a lot of experimentation and intensive research before you hit on one that’s truly sustainable. FLEXIBLE, ADAPTIVE LEADERSHIP To continue growing, entrepreneurs, managers, and business owners must become the leader the business needs for each particular stage of growth. And since a company’s needs change at each stage, its leaders need to keep evolving at the right pace. That requires introspection, self-awareness, and a keen sense of strategy — both in the short- and long-terms. I believe that an comes from being mindful. Our individual, adaptive, flexible leadership style interpersonal, and working lives are all interconnected. By being mindful, we understand those relationships and how best to utilize them to create, innovate, and lead. And that allows us to arrange our lives and our organizations in a way that leads to long-term value creation. Indeed, the most sustainable way to create value is to continually invest in our capabilities, both as individuals and as organizations. [Photo: Flickr user Ekaterina ] Original article @faisalhoque.com and @FastCompany . Copyright © 2018 by Faisal Hoque. All rights reserved. I am an . Founder of and other companies. Shadoka enables aspirations to lead, innovate, and transform with its accelerators and solutions. Author of “ ” (McGraw Hill, 2014) and “ ” (Motivational Press, 2015). Follow me on Twitter . entrepreneur and author SHADOKA Everything Connects — How to Transform and Lead in the Age of Creativity, Innovation and Sustainability Survive to Thrive: 27 Practices of Resilient Entrepreneurs, Innovators, and Leaders @faisal_hoque

The 7 Fundamentals Of Sustainable Business Growth

Rethinking Code Reviews With Stacked PRs This post explores shift-left principles and suggests that stacked PRs will become increasingly useful. The peer code review process is an essential part of software development. It helps maintain software quality and promotes adherence to standards, project requirements, style guides, and facilitates learning and knowledge transfer. Code Review Effectiveness While the effectiveness is high for reviewing sufficiently small code changes, it drops exponentially with the increase in the size of the change. To sustain the necessary level of mental focus to be effective, large code reviews are exhausting. Usually, the longer the review duration gets, the less effective the overall review becomes: So why can’t we just restrict the size of the pull requests (PRs)? While many changes can start small, suddenly a small two-line change can grow into a 500-line refactor including multiple back-and-forth conversations with reviewers. Some engineering teams also maintain long-running feature branches as they continue working, making it hard to review. So, how do we strike the right balance? Simple. Use stacked PRs. What Are Stacked PRs? Stacked pull requests make smaller, iterative changes and are stacked on top of each other instead of bundling large monolith changes in a single pull request. Each PR in the stack focuses on one logical change only, making the review process more manageable and less time-consuming. We also wrote a post last year explaining how this help represents instead of breaking things down by files or features. code changes as a narrative Why Stacked PRs? Other than building a culture of more effective code reviews, there are a few other benefits of stacked PRs: Early Code Review Feedback Imagine that you are implementing a large feature. Instead of creating the entire feature and then requesting a code review, consider carving out the initial framework and promptly putting it up for feedback. This could potentially save you countless hours by getting early feedback on your design. Faster CI Feedback Cycle Stacked PRs support the practice because changes are continuously integrated and tested, which allows for early detection and rectification of issues. shift-left The changes are merged in bits and pieces catching any issues early vs merging one giant change hoping it does not bring down prod! Knowledge Sharing Code reviews are also wonderful for posterity. Your code changes are narrating your thought process behind implementing a feature, therefore, the breakdown of changes creates more effective knowledge transfer. It’s easier for team members to understand the changes, which promotes better knowledge sharing for the future. Staying Unblocked Waiting on getting the code reviewed and approved can be a frustrating process. With stacked PRs, the developers can work on multiple parts of a feature without waiting for reviewers to approve previous PRs What’s the Catch? So, why don’t more developers use stacked PRs for code reviews? Although this stacked PR workflow addresses both the desired practices of keeping code reviews manageable and developers productive, unfortunately, it is not supported very well natively by either Git or GitHub. As a result, have been developed across the open-source community to enable engineers to incorporate this stacking technique into the existing Git and GitHub platforms. But stacking the PRs is only part of the story. several tools Updating As we get code review feedback and we make changes to the part of the stack, we have to now rebase and resolve conflicts at all subsequent branches. Let’s take an example. Imagine that you are working on a change that requires making a schema change, a backend change, and a frontend change. With that, you can now send a simple schema change for review first, and while that’s being reviewed, you can start working on the backend and frontend. Using stacked PRs, all these 3 changes can be reviewed by 3 different reviews. In this case, you may have a stack that looks like this where , and represents the 3 branches stacked on top of each other. demo/schema demo/backend demo/frontend So far, this makes sense, but what if you got some code review comments on the schema change that requires creating a new commit? Suddenly your commit history looks like this: Now, you have to manually rebase all subsequent branches and resolve conflicts at every stage. Imagine if you have 10 stacked branches where you may have to resolve the conflicts 10 times. Merging But that’s not all, merging a PR in the stack can be a real nightmare. You have 3 options , , and to merge a PR. Let’s try to understand what goes behind the scenes in each one. squash merge rebase In the case of a commit, Git takes changes from all the existing commits of the PR and rewrites them into a single commit. In this case, no history is maintained on where those changes came from. squash A commit is a special type of Git commit that is represented by a combination of two or more commits. So, it works very similar to a commit but it also captures information about its parents. In a typical scenario, a merge commit has two parents: the last commit on the base branch (where the PR is merged), and the top commit on the feature branch that was merged. merge squash Although this approach gives more context to the commit history, it inadvertently creates a that can be undesirable. non-linear git-history Finally, in case of a and merge, Git will rewrite the commits onto the base branch. So, similar to the commit option, it will lose any history associated with the original commits. rebase squash Typically, if you are using the commit strategy while stacking PRs, your life will be a bit simpler, but most teams discourage using that strategy to keep the git-history clean. That means you are likely using either a or a merge. merge squash rebase And that creates a merge conflict for all subsequent unmerged stacked branches. In the example above, let’s say we squash merge the first branch into the mainline. It will create a new commit that contains changes of and . demo/schema D1 A1 A2 Since Git does not know where came from, and is still based on , trying to rebase on top of the mainline will create merge conflicts. D1 demo/backend A2 demo/backend Likewise, rebasing after rebasing will also cause the same issues. So if you had ten stacked branches and you squash merged one of them, you would have to resolve these conflicts nine times. demo/frontend demo/backend We are still just scratching the surface; there are such as reordering commits, splitting, folding, and renaming branches, that can create huge overhead to manage when dealing with stacked PRs. many other use cases That’s why we built stacked PRs management as part of Aviator. Why Aviator CLI Is Different Think of Aviator as an augmentation layer that sits on top of your existing tooling. Aviator connects with GitHub, Slack, Chrome, and Git CLI to provide an enhanced developer experience. Aviator CLI works seamlessly with everything else! The CLI isn’t just a layer on top of Git but also understands the context of stacks across GitHub. Let’s consider an example. Creating a Stack Creating a stack is fairly straightforward. Except in this case, we use CLI to create the branches to ensure that the stack is tracked. For instance, to create your schema branch and corresponding PR, follow the steps below. av av stack branch demo/schema
# make schema changes
git commit -a -m "[demo] schema changes"
av pr create Since Aviator is also connected to your GitHub, it makes it easy for you to visualize the stack. Or if you want to visualize it from the terminal, you can still do that with the CLI commands: Updating the Stack Using the stack now becomes a cakewalk. You can add new commits to any branch, and simply run from anywhere in the stack to synchronize all branches. Aviator automatically rebases all the branches for you, and if there’s a real merge conflict, you just have to resolve it once. av stack sync Merging the Stack This is where Aviator tools easily stand out from any existing tooling. At Aviator, we have built one of the most advanced MergeQueue to manage auto-merging thousands of changes at scale. Aviator supports seamless integration with the CLI and stacked PRs. So to merge partial or full stack of PRs, you can assign them to Aviator MergeQueue using CLI or by posting a comment on GitHub: . av pr queue /aviator stack merge Aviator automatically handles validating, updating, and auto-merging all queued stacks in order. Now when the PRs are merged, you can this time run to update all PRs and clean out all merged PRs. av stack sync --trunk Shift-Left Is the Future Stacked PRs might initially seem like more work due to the need to break down changes into smaller parts. However, the increase in code review efficiency, faster feedback loops, and enhanced learning opportunities will surely outweigh this overhead. As we continue embracing the shift-left principles, stacked PRs will become increasingly useful. The Aviator CLI provides a great way to manage stacked PRs with a lot less tedium. The CLI is and completely free. We would love for you to try it out, and share your feedback on our . open-source discussion board At Aviator, we are building developer productivity tools from first principles to empower developers to build faster and better.

Stacked PRs: Rethinking Code Reviews

Relaciones públicas apiladas: repensar las revisiones de código

RP empilés : repenser les revues de code

स्टैक्ड पीआर: कोड समीक्षा पर पुनर्विचार

積み重ねられた PR: コード レビューの再考

PRs empilhados: Repensando as revisões de código

PR xếp chồng lên nhau: Suy nghĩ lại về đánh giá mã

堆叠 PR：重新思考代码审查

These days we should think critically about how we do things in programming. We need to apply the engineering approach to our processes. We, the software engineers, are confident in discussions about abstract classes and pure functions. On the other hand, we run away when there is a need to discuss "managerial" things. My favourite widely spread programming process that has an enormous amount of flaws is code review. This story will look at it from different perspectives and propose improvements. The first significant fact I read about software inspections was in the "Facts and Fallacies of Software Engineering" book by Robert Glass. It claims the following: Rigorous inspections can remove up to 90 percent of errors from a software product before the first test case is run. I couldn't determine if these words were solely about the code review. I treat them as referred to different kinds of inspections, which I will describe later. . Michael Fagan formulated the idea of inspections in 1976 in his article "Design and code inspections to reduce errors in program development". Uncle Bob Martin helped me to discover the roots of our modern reviews I discovered three following types of inspections there: Design inspection, Code inspection before unit testing, Code inspection after unit testing. Fagan's work doesn't propose a new approach to code but documents the already existing phenomena and argues for it. However, the article is the earliest written sign of inspections I've found. Code inspections look like our modern code reviews. Why do we miss other types of inspections today? Why There Are Only Code Reviews Today: Some Assumptions The popularity of code inspections and the almost inexistence of other types of inspections today comes from our tools. GitHub, BitBucket, or GitLab all have built-in code reviewing instruments, and they naturally fit in Git flow, GitHub flow, and other approaches. What tool do you use for design activities? It's not about the UI/UX. It is about the structure of the code you will build. You might have heard of CASE or UML tools. I haven't seen them seriously used in any company I worked for, and I have worked for seven. On HackerNoon, the " " search query results in just two relevant results. So there is no place to introduce the design inspection when there is no tangible solution design process. In the team I lead, we used Miro for interface design. The process could have been more satisfying: as with other diagramming tools, you soon start drawing instead of solving your problems.
We can be independent of our tools. Here is a little quote to support this from the "Investments Unlimited" book: UML ...if we just do what the tools can do — then we will always be limited to the capabilities of our tools. What Flaws Do the Existing Code Reviews Have? Let's look at the process in its classic form from different perspectives. Each of them shows significant problems. BPMN Perspective BPMN is a business process model and notation. It describes processes with actions, events, logical gateways, messages and other means. I even recommend using it if you want to develop an algorithm, as it is more descriptive than a flowchart. Let's depict the code review process for a single reviewer with this notation and analyze it. I've used a text-based tool to generate . There is a little glitch on it with many returning letters. the upcoming diagram It all starts with a PR creation, and nothing is notable here. The next step is to notify a reviewer, which is a simplification of all different means available to say: "Hey, my PR is waiting for you!👋"
What's important here is the freeing from the current activities. Here the PR waits for an unknown duration. Then the reviewer dives into the task and conducts the review. There is a chance that a PR will get merged right away. However, the opposite could happen: a few comments requiring fixes would appear. The code's author might be already in the next task, and there is one more wait time of an unknown length. Also, coming back requires context restoration, the interpretation of the comments and their fix. The next step is the notification of the reviewer. Haven't we already been there? Yes, you are right. We've just finished our first iteration of the potentially infinite loop. Yes, infinite. There is always a chance that new comments will appear. Or that one of the waiting periods would last forever. Do we want the potentially infinite loop as a part of our daily operations? I'm not sure, as having faster delivery is usually preferable. Solution Vision Perspective Sometimes, we have senior developers or architects in our teams as reviewers. They wish to have a consistent codebase, stick to some methods and patterns and avoid others. They have a vision. Developers also have their idea. Usually, they are not aware of the intent of their seniors. It requires consistent broadcasting or an auxiliary environment, which rarely happens. Let's have a look at the following picture. You can see how the two visions of code review participants differ. After the first iteration, they begin alignment, but there is still a way to go. The reviewer adjusts one's vision, and the code author moves according to the interpretation of the proposals. We can use the "imagine you've asked for a house and then surprise! It's not the one you expected" metaphor. Or we can look at its core. Imagine you've asked a person to achieve something. Then you come back and see the results, but you become surprised by the set of decisions the achiever has made. Don't be surprised, as you didn't require a particular decision-making framework. Interpersonal Perspective The image says for itself. Would you ask your fellow engineer to fix the design issue after spending many days on the task? Imagine that your sprint ends, and the ticket was the cause of some tension on a standup. You'll help your colleague merge it as fast as possible. On the other hand, there could be a senior engineer reviewing the junior's code. He could ask him to go a long way to fix the decision made in the beginning. However, is this the right time to give such advice? So many decisions stand on the wrong choice already. Lean manufacturing has yet to influence programming. However, we already have a tool from the "Lean Software Development" book by Mary Poppendieck and Tom Poppendieck. This tool is the seven software development wastes: Partially done work, Extra features, Relearning, Handoffs, Delays, Task switching, Defects. Classic code review wins 6 out of 7!🎉 . A task in the review is abandoned most of the time. I usually treat this stage of development as a queueing rather than one where the action is. Creating a review also has an interesting psychological effect: "The task is ready, and it's not my job anymore!" Code review is the "no one's responsibility land", which is why we often see it escalate to the upper levels. Partially done work . You can see the relearning on the BPMN diagram above. Restoring context is relearning. Relearning . If we are honest, this is not a waste here. It's the core mechanics. Handoffs . Code review design contains two types of delays we've discussed earlier. What's even scarier is their loop. Delays . People pause their tasks to give some attention to a review. Task switching . Review is good for finding cosmetic problems but not design flaws, which would harm the most. The mentioned above lack of motivation to ask fellows for significant changes leads to substantial defects in the project. Defects We've covered the problems of code reviews from many sides. What can we do to fix this process? Redesigning Code Review In this section, we'll cover the same topics as the previous one but from the fixing viewpoint. Fixing the Process Structure Here we have a code author waiting for a review to complete and a pair programming session after a reviewer's overview. In the proposed process, we can see several significant changes compared to the previous one: No more potentially infinite review loop; Single waiting time of the unknown duration, we'll handle it also; No need to restore context or interpret feedback for the code author. Comments now serve as reminders for the pair. What are the core prerequisites for this process to happen? Now a team needs an additional role. It implies that someone does the auxiliary activities, e.g., handles the technical debt, or fixes bugs of a lower priority. When code review appears on the radar, this person immediately drops the current task and jumps into the arrived PR. If you have ever wondered why you need some slack in the structure of your work, this is an example. If everyone is occupied with the top-priority features, you'll have them delivered later. Fixing the Vision Divergence What do we discuss on code reviews? The decisions made during the development. We made some of them an hour ago and others a week ago. Our choices stand on top of each other and are not independent. How enjoyable do you find an opportunity to question one of the first decisions on which the next several hundred stand? You may be unhappy about the opportunity. The most appropriate time to discuss the design decisions is when they appear. We need one additional type of review: design review. Sometimes when the problem is challenging, it's good to spend some time on the plan and discuss it with your knowledgeable colleagues. There is a famous military adage: No battle plan survives contact with the enemy. If we translate it into the language at systems, we'll get something like: "System will certainly need to adjust its behaviour when the first feedback arrives". In the case of programming, the feedback would be the problems we face when trying to implement the design into our system. Some of the decisions need to be revised. We would need to change them and again diverge in our visions with a reviewer. Adam Thornhill, in his overwhelming "Software Design X-Rays" book, proposed a method: That's why I recommend that you do your initial code walkthrough much earlier. Instead of waiting for the completion of a feature, make it a practice to present and discuss each implementation at one-third completion. Focus less on details and more on the overall structure, dependencies, and how well the design aligns with the problem domain. Of course, one-third completion is subjective, but it should be a point where the basic structure is in place, the problem is well understood, and the initial test suite exists. At this early stage, a rework of the design is still a viable alternative and catching potential problems here has a large payoff. I've coined a term for my team to have a convenient language: skeleton review. I hope it helps to reflect the idea behind the activity. Lean Perspective on the Proposed Process The proposed process eliminates or significantly addresses the discovered wastes. . Switching to another task during the anticipation time for a code author is not allowed, so there is no user-significant partially done job. Partially done activities of a less priority are the trade-off. Partially done work . No relearning occurs as little time passes between coding completion and pair programming. Relearning . We've significantly shortened the code reviewer's delay and eliminated the author's. Delays . No longer allowed for an author and managed for a reviewer. Task switching . Now fixing design defects becomes cheaper, and the most important of them, design defects, become fixed. Defects Additional Thoughts We've reviewed the code review approach for a single author and a single reviewer. When more reviewers appear, problems multiply. So, unfortunately, not all bugs become shallow if you add people lately to look at all the decisions you've made. You'd instead make your code merge later. Two of the most challenging problems I faced when trying to introduce the proposed process were the following: Developers treat the review stage as a job done. Managers get horrified when proposing to introduce redundancy into daily work. It's great they don't manage the firefighters' teams. The cure to the first problem is repetition and speed. The second problem is more complicated. Here I want to quote the "Actionable Agile Metrics for Predictability" book by Daniel Vacanti: There are a lot of strategies that FedEx employs, but the one that is probably most important is that at any given time FedEx has empty planes in the air. Yes, I said empty planes. That way, if a location gets overwhelmed, or if packages get left behind because a regularly scheduled plane was full then an empty plane is redirected (just-in-time it should be said) to the problem spot. At any given time FedEx has "spares in the air"! If you are a manager, consider this the next time when planning for utilization maximization. Are we satisfied with the update? Yes, it looks better than what we have now. Can we do better? Yes, we can. The target is to eliminate code review at a time when we can guarantee that all the necessary quality is already in the code. To achieve this, we need to build an auxiliary decision-making framework to help developers apply what's treated as a good practice and avoid the bad one. I have never heard of such a framework, but in-IDE linters are a step towards it. Thank you for reading! Write a comment if you want to discuss the described ideas.

Code Review Is Inherently Flawed. Here’s How to Fix It

Las revisiones de código son inherentemente defectuosas. Aquí está cómo solucionarlo

La révision du code est intrinsèquement défectueuse. Voici comment y remédier

कोड समीक्षा स्वाभाविक रूप से त्रुटिपूर्ण है। यहां बताया गया है कि इसे कैसे ठीक करें

コード レビューには本質的な欠陥があります。これを修正する方法は次のとおりです

A revisão de código é inerentemente falha. Veja como corrigi-lo

Đánh giá mã vốn dĩ là sai lầm. Đây là cách khắc phục

代码审查天生就有缺陷。这是解决方法

Code reviews can be painful. Software engineers often complain that the review process is slow, delays downstream tasks, and leads to context switching as you navigate back and forth between an open pull request (PR) and your next task. Code reviews can also be full of nitpicking and bikeshedding, making it a poor experience for everyone involved. To remedy this problem, some engineers have even gone as far as suggesting we get rid of pull requests and code reviews altogether. While that may work for small teams at startups, I don’t think this is the right solution for everyone, especially enterprise-level companies. Rather, there are plenty of ways we can make the code review process a better experience for both the code author and the code reviewer. Let’s consider seven of these best practices together. #1: Keep Pull Requests Small Every engineer dreads reviewing pull requests that have 1000+ lines of code changed. These reviews can take hours to complete, and oftentimes what ends up happening is that the reviewer begins to skim over the code rather than carefully review it. The solution is to keep your pull requests small. Small PRs are easier and quicker to review because the reviewer doesn’t need to spend as much time building up a mental model of how all the changes work together. There is also less code changed, which hopefully equates to fewer errors, fewer comments, and fewer rounds of back and forth between the author and the reviewer. Keeping your PRs small may seem difficult at first, but it can be done if you break down your work into small tasks and stay focused. Don’t do major refactors while also implementing new features or fixing bugs. Use feature flags in your code so you can merge small parts of new features into the master branch without it showing up in the production app. Keep your PRs small. Your reviewers will be grateful. #2: Use Pull Request Templates Another annoyance is being asked to review a pull request without any context. When a PR is dropped in your lap with no explanation, you’re often left wondering, “What is this PR for? What issue is this solving? Is there a related task for this? Why was this particular approach taken?” A is a small, configurable form you can set as the default text on every new pull request. The PR template prompts the code author to provide relevant details for their PR. Typically, a PR template would ask for a brief description of what you’ve done and why, a link to the task ticket, and a test plan for validating the changes. pull request template Good PR templates also usually include a short checklist for the code author to go through to ensure that they haven’t missed any of the basics. This checklist might include items like unit tests, docs, internationalization, cross-browser support, and accessibility. Below is an example pull request template that I like to use for all of my repos: #3: Implement Response Time SLAs If you’re finding that pull requests sit unreviewed for longer than you’d like, now is a good time to set expectations as a team for how quickly a new pull request should be reviewed. In other words, what is the maximum amount of time a PR can exist before it must be picked up? One hour? Two hours? 24 hours? Your answer to that question will likely depend on the size of your team. You may also have a different answer for internal pull requests from your team versus external pull requests from other teams. When choosing a response time SLA (service level agreement), you’ll want to find the right balance. It’s not reasonable to expect everyone to immediately drop whatever they’re doing and review your code when you post a new PR, but you also don’t want PRs to stay unreviewed for hours on end. Find the right balance that allows your teammates to get into a flow state. They should be able to work on their own code and then review PRs at natural stopping points throughout the day. Personally, I like having a two-hour response time SLA for internal team PRs and a 24-hour response time SLA for external team PRs. Regardless of what you and your teammates decide, having a team agreement allows you to hold each other accountable. If everyone has agreed to a specific SLA and that time has elapsed for one of your PRs, you know it’s ok to start bugging people about it. #4: Train Junior and Mid-Level Engineers Training opportunities are everywhere. Mentoring less experienced engineers includes more than just teaching them about the technologies and languages they’re working with. It also includes teaching them soft skills like how to do an effective code review. Teach your teammates what you look for during a code review. Help them understand what’s important and what’s not. Teach them how to communicate effectively in their , like by prefixing non-blocking suggestions with “nit.” code review comments There are plenty of great resources on how to be a more effective code reviewer. Google’s is worth reading in its entirety. The guide has excellent advice for both the code author and the code reviewer. For a more cheeky resource, is easily some of the best (and entertaining) advice for developers creating pull requests. Code Review Developer Guide How to Make Your Code Reviewer Fall in Love with You #5: Set Up Continuous Integration Pipelines Code reviews become tedious when most of the comments are things like “Missing semicolon” or “Indentation seems off here.” Don’t spend time during code reviews on things that code formatters and code linters can take care of for you. Let computers automate the trivial stuff so that you can focus on the important things that require a human. For JavaScript projects, it’s simple to configure a formatter like and a linter like for your repo. You can then set up continuous integration for your repo using something like , , , or . Prettier ESLint Travis CI CircleCI GitHub Actions GitLab CI/CD Your CI pipeline will run these formatting and linting tasks for you along with your unit tests. If the CI pipeline fails at any step on a pull request, it will block that pull request from being merged. Now, you’ve automated several important parts of the code review, saving you hours. #6: Use Pull Request Review Apps Sometimes it’s necessary not just to review the code in a pull request but also to manually view the changes in the app to verify that things look good. For apps with complex setup steps, pulling down someone else’s code and running it locally on your machine may take anywhere from five minutes to an hour. What a headache! are used to automatically deploy your code to a short-lived test environment any time a new PR is created. This allows reviewers to easily inspect UI changes without having to pull down the code and run it locally on their machine. Not only does this save time, but it also nudges reviewers to be more thorough in their reviews by making it easy. Pull request review apps #7: Generate Diagrams to Visualize Your Code Changes When reviewing code in GitHub or GitLab, the files are typically shown in alphabetical order. For relatively small PRs, this may not be a problem. But when there are dozens of files involved in a PR, sometimes it’s helpful to see those changes grouped together logically so you can see how they fit together in a bigger picture. help you visualize what files were changed and how those changes affect their upstream and downstream dependencies. They integrate with GitHub to automatically post a comment and a diagram on your PR. You can even create interactive tours of your code to help guide your code reviewers. Best of all, CodeSee Maps are free to open-source organizations and their public repositories. CodeSee Review Maps Conclusion: 7 Ways to Dramatically Reduce Your Time in Code Review To recap, here are seven tips for dramatically reducing your time in code review: Keep pull requests small. Use pull request templates to provide all the context a reviewer would need. Implement response time SLAs. Train junior and mid-level engineers on the key things you look for during a code review. Set up CI pipelines to run linters, formatters, and unit tests. Use pull request review apps so you can easily inspect UI changes. Generate diagrams to visualize your code changes using a tool like CodeSee Review Maps. Thanks for reading, and happy coding! Also published here

Stories, News & Mentions about REVVSO

Revvso’s Stories on HackerNoon