Buncha is the milkman, but for your favorite stores

Buncha

buncha

5 Must-Read Books for Cypherpunks and Crypto Enthusiasts

Cryptography can be used to have not only decentralized and private money but also private communications. The activists known as cypherpunks knew this too well, and that’s why not only Bitcoin came out from that mailing list started in the ’90s. A bunch of free and useful cryptographic tools are the legacy of cypherpunks, including the one created by Phil Zimmerman —a remarkable cypherpunk even to this day. Born on February 12, 1954, in Camden, New Jersey, Zimmermann studied computer science at Florida Atlantic University, where he earned his degree in 1978. His career trajectory began with software engineering roles in various companies, including a stint at the nuclear power company, System Simulation Corporation, where he worked on cryptographic security systems. However, the interesting part is that he was also an anti-nuclear activist. It’s known that he was arrested for partaking in an anti-nuclear protest in Nevada, alongside prominent figures like Carl Sagan and Martin Sheen. This commitment to activism underscored Zimmermann's convictions, solidifying his standing within the anti-nuclear movement. Amidst the shifting geopolitical landscape of the early 1990s, Zimmermann's focus pivoted towards cryptography, recognizing its potential to safeguard private communications in an increasingly interconnected world. It was during this period that he would join the cypherpunks and create his ‘magnum opus’. Pretty Good Privacy (PGP) This is a thing even Satoshi Nakamoto used to protect his emails, and it’s still widely used as a standard to achieve private communications. Developed in 1991, PGP is an encryption software designed to secure email messages. Zimmermann's motivation behind PGP was rooted in his concerns about government surveillance and the need for accessible cryptographic tools to protect individual privacy. In his own words: “It's personal. It's private. And it's no one's business but yours. You may be planning a political campaign, discussing your taxes, or having a secret romance. Or you may be communicating with a political dissident in a repressive country. Whatever it is, you don't want your private electronic mail (email) or confidential documents read by anyone else (...) PGP empowers people to take their privacy into their own hands. There has been a growing social need for it. That's why I wrote it.” As for its internal features, PGP uses a pair of cryptographic keys for each user—a public key and a private key. The public key, which is freely distributed, is used by others to encrypt messages intended for the user. Meanwhile, the private key, kept confidential by the user, is used for decrypting these messages. When someone wants to send an encrypted message to a PGP user, they obtain the recipient's public key. Using this key, they encrypt the message, ensuring that only the intended recipient, who possesses the corresponding private key, can decrypt and read it. This process provides confidentiality for the message. Additionally, PGP supports digital signatures, enabling users to verify the authenticity and integrity of emails. By hashing the message and encrypting the hash with their private key, senders create digital signatures that recipients can verify using the sender's public key. After PGP Back then, the US government considered cryptographic tools as weapons, and that’s why Zimmerman was investigated by authorities for the free distribution of PGP. Luckily, they dropped the case in 1996 without charges, and the cypherpunk founded PGP Inc., along with a new release of PGP. The company in charge of maintaining the software was eventually sold to Symantec in 2010. Following the success of PGP, Zimmermann has also been involved in various ventures aimed at bolstering digital security and privacy. In 2012, he co-founded Silent Circle alongside Mike Janke and Jon Callas, focusing on developing secure hardware and subscription-based software solutions. Additionally, Zimmermann collaborated with other key figures from Silent Circle and Lavabit (an encrypted webmail service) to establish the Dark Mail Alliance in 2013, with the objective of creating a new protocol to enhance email encryption, addressing limitations in PGP. Beyond his cryptographic endeavors, Zimmermann extended his influence to social networking platforms, advocating for ethical and privacy-centric alternatives to mainstream platforms like Facebook. His involvement in the social network Okuna, previously known as Openbook, aimed to provide users with a platform that prioritized privacy and democratic values over profit-driven models. Zimmermann's contributions have been widely recognized, with numerous awards acknowledging his pioneering work in cryptography and advocacy for digital rights. From inductions into halls of fame to prestigious accolades such as the Louis Brandeis Award from Privacy International and the Norbert Wiener Award for Social and Professional Responsibility, Zimmermann's legacy continues to resonate within the realms of technology and human rights advocacy. In a world of surveillance There’s a thing called “the Zimmerman law” that refers to his words about technology and surveillance: “The natural flow of technology tends to move in the direction of making surveillance easier (…) the ability of computers to track us doubles every eighteen months.” If the period is exact or not in reality, it doesn’t matter, because today mass surveillance and censorship have become common feats by governments worldwide. PGP can help us to protect our privacy and digital rights, but it’s not the only tool available for that. Obyte, for instance, can also help with private communications and decentralized, fast, and secure financial transactions worldwide. Built on a Directed Acyclic Graph (DAG) structure, Obyte ensures global transactions without the need for miners or any other middlemen. This structure enables Obyte to increase its decentralization and offers a high level of control to its users. In addition to its financial features, where tokenization of any asset is also possible, Obyte integrates private communications functionality directly into its platform. Users can leverage Obyte's built-in messaging system in the wallet to communicate securely and privately, thanks to end-to-end encryption, similar to PGP. This feature enhances user privacy by enabling them to freely communicate without a company or government behind them, thus providing a comprehensive solution for both financial transactions and private messaging. As a result, we can say that Obyte is empowering users with a versatile platform for conducting secure and private interactions worldwide. Read more from Cypherpunks Write Code series: Tim May & Crypto-anarchism Wei Dai & B-money Nick Szabo & Smart Contracts Adam Back & Hashcash Eric Hughes & Remailer St Jude & Community Memory Hal Finney & RPOW Featured Vector Image by Garry Killian / Freepik Photo by Phil Zimmerman Cryptography can be used to have not only decentralized and private money but also private communications. The activists known as cypherpunks knew this too well, and that’s why not only Bitcoin came out from that mailing list started in the ’90s. A bunch of free and useful cryptographic tools are the legacy of cypherpunks, including the one created by Phil Zimmerman —a remarkable cypherpunk even to this day. that mailing list that mailing list Born on February 12, 1954, in Camden, New Jersey, Zimmermann studied computer science at Florida Atlantic University, where he earned his degree in 1978. His career trajectory began with software engineering roles in various companies, including a stint at the nuclear power company, System Simulation Corporation, where he worked on cryptographic security systems. Zimmermann studied computer science at Florida Atlantic University, where he earned his degree in 1978. Zimmermann Zimmermann However, the interesting part is that he was also an anti-nuclear activist. It’s known that he was arrested for partaking in an anti-nuclear protest in Nevada, alongside prominent figures like Carl Sagan and Martin Sheen. This commitment to activism underscored Zimmermann's convictions, solidifying his standing within the anti-nuclear movement. It’s known It’s known Amidst the shifting geopolitical landscape of the early 1990s, Zimmermann's focus pivoted towards cryptography, recognizing its potential to safeguard private communications in an increasingly interconnected world. It was during this period that he would join the cypherpunks and create his ‘magnum opus’. Pretty Good Privacy (PGP) This is a thing even Satoshi Nakamoto used to protect his emails, and it’s still widely used as a standard to achieve private communications. Developed in 1991, PGP is an encryption software designed to secure email messages . Zimmermann's motivation behind PGP was rooted in his concerns about government surveillance and the need for accessible cryptographic tools to protect individual privacy. In his own words : Developed in 1991, PGP is an encryption software designed to secure email messages In his own words In his own words “It's personal. It's private. And it's no one's business but yours. You may be planning a political campaign, discussing your taxes, or having a secret romance. Or you may be communicating with a political dissident in a repressive country. Whatever it is, you don't want your private electronic mail (email) or confidential documents read by anyone else (...) PGP empowers people to take their privacy into their own hands. There has been a growing social need for it. That's why I wrote it.” “It's personal. It's private. And it's no one's business but yours. You may be planning a political campaign, discussing your taxes, or having a secret romance. Or you may be communicating with a political dissident in a repressive country. Whatever it is, you don't want your private electronic mail (email) or confidential documents read by anyone else (...) PGP empowers people to take their privacy into their own hands. There has been a growing social need for it. That's why I wrote it.” As for its internal features, PGP uses a pair of cryptographic keys for each user—a public key and a private key. The public key, which is freely distributed, is used by others to encrypt messages intended for the user. Meanwhile, the private key, kept confidential by the user, is used for decrypting these messages. When someone wants to send an encrypted message to a PGP user, they obtain the recipient's public key. Using this key, they encrypt the message, ensuring that only the intended recipient, who possesses the corresponding private key, can decrypt and read it. This process provides confidentiality for the message. Additionally, PGP supports digital signatures, enabling users to verify the authenticity and integrity of emails. By hashing the message and encrypting the hash with their private key, senders create digital signatures that recipients can verify using the sender's public key. After PGP After PGP Back then, the US government considered cryptographic tools as weapons, and that’s why Zimmerman was investigated by authorities for the free distribution of PGP. Luckily, they dropped the case in 1996 without charges, and the cypherpunk founded PGP Inc., along with a new release of PGP. The company in charge of maintaining the software was eventually sold to Symantec in 2010. Following the success of PGP, Zimmermann has also been involved in various ventures aimed at bolstering digital security and privacy. In 2012, he co-founded Silent Circle alongside Mike Janke and Jon Callas, focusing on developing secure hardware and subscription-based software solutions. Additionally, Zimmermann collaborated with other key figures from Silent Circle and Lavabit (an encrypted webmail service) to establish the Dark Mail Alliance in 2013, with the objective of creating a new protocol to enhance email encryption, addressing limitations in PGP. Following the success of PGP, Zimmermann has also been involved in various ventures aimed at bolstering digital security and privacy. Beyond his cryptographic endeavors, Zimmermann extended his influence to social networking platforms, advocating for ethical and privacy-centric alternatives to mainstream platforms like Facebook. His involvement in the social network Okuna , previously known as Openbook, aimed to provide users with a platform that prioritized privacy and democratic values over profit-driven models. Okuna Okuna Zimmermann's contributions have been widely recognized, with numerous awards acknowledging his pioneering work in cryptography and advocacy for digital rights. From inductions into halls of fame to prestigious accolades such as the Louis Brandeis Award from Privacy International and the Norbert Wiener Award for Social and Professional Responsibility, Zimmermann's legacy continues to resonate within the realms of technology and human rights advocacy. In a world of surveillance In a world of surveillance There’s a thing called “the Zimmerman law” that refers to his words about technology and surveillance: “The natural flow of technology tends to move in the direction of making surveillance easier (…) the ability of computers to track us doubles every eighteen months.” If the period is exact or not in reality, it doesn’t matter, because today mass surveillance and censorship have become common feats by governments worldwide. his words his words “The natural flow of technology tends to move in the direction of making surveillance easier (…) the ability of computers to track us doubles every eighteen months.” mass surveillance mass surveillance PGP can help us to protect our privacy and digital rights, but it’s not the only tool available for that. Obyte , for instance, can also help with private communications and decentralized, fast, and secure financial transactions worldwide. Built on a Directed Acyclic Graph (DAG) structure, Obyte ensures global transactions without the need for miners or any other middlemen. This structure enables Obyte to increase its decentralization and offers a high level of control to its users. Obyte Obyte In addition to its financial features, where tokenization of any asset is also possible, Obyte integrates private communications functionality directly into its platform. Users can leverage Obyte's built-in messaging system in the wallet to communicate securely and privately, thanks to end-to-end encryption, similar to PGP. tokenization of any asset tokenization of any asset in the wallet in the wallet This feature enhances user privacy by enabling them to freely communicate without a company or government behind them, thus providing a comprehensive solution for both financial transactions and private messaging. As a result, we can say that Obyte is empowering users with a versatile platform for conducting secure and private interactions worldwide. Read more from Cypherpunks Write Code series: Read more from Cypherpunks Write Code series: Read more from Cypherpunks Write Code series: Tim May & Crypto-anarchism Tim May & Crypto-anarchism Tim May & Crypto-anarchism Wei Dai & B-money Wei Dai & B-money Wei Dai & B-money Nick Szabo & Smart Contracts Nick Szabo & Smart Contracts Nick Szabo & Smart Contracts Adam Back & Hashcash Adam Back & Hashcash Adam Back & Hashcash Eric Hughes & Remailer Eric Hughes & Remailer Eric Hughes & Remailer St Jude & Community Memory St Jude & Community Memory St Jude & Community Memory Hal Finney & RPOW Hal Finney & RPOW Hal Finney & RPOW Featured Vector Image by Garry Killian / Freepik Featured Vector Image by Garry Killian / Freepik Freepik Freepik Photo by Phil Zimmerman Photo by Phil Zimmerman Phil Zimmerman Phil Zimmerman

Cypherpunks Write Code: Phil Zimmerman and PGP

সাইফারপাঙ্কস কোড লিখুন: ফিল জিমারম্যান এবং পিজিপি

Cypherpunks schreiben Code: Phil Zimmerman und PGP

Código de escritura de Cypherpunks: Phil Zimmerman y PGP

Cypherpunks écrivent du code : Phil Zimmerman et PGP

साइफरपंक्स कोड लिखें: फिल ज़िमरमैन और पीजीपी

サイファーパンクがコードを書く: フィル・ジマーマンと PGP

사이퍼펑크의 코드 작성: Phil Zimmerman 및 PGP

Cypherpunks escrevem código: Phil Zimmerman e PGP

Шифропанки пишут код: Фил Циммерман и PGP

Şifrepunklar Kod Yazıyor: Phil Zimmerman ve PGP

Cypherpunks viết mã: Phil Zimmerman và PGP

密码朋克编写代码：Phil Zimmerman 和 PGP

THE PILGRIMS.

Everything You Need to Know About Account Based Marketing 

অ্যাকাউন্ট ভিত্তিক মার্কেটিং সম্পর্কে আপনার যা কিছু জানা দরকার

Alles, was Sie über Account Based Marketing wissen müssen

Todo lo que necesita saber sobre el marketing basado en cuentas

Tout ce que vous devez savoir sur le marketing basé sur les comptes

खाता आधारित मार्केटिंग के बारे में वह सब कुछ जो आपको जानना आवश्यक है

アカウントベースのマーケティングについて知っておくべきことすべて

계정 기반 마케팅에 대해 알아야 할 모든 것

Tudo o que você precisa saber sobre marketing baseado em contas

Все, что вам нужно знать о маркетинге на основе учетных записей

Hesap Tabanlı Pazarlama Hakkında Bilmeniz Gereken Her Şey

Mọi điều bạn cần biết về tiếp thị dựa trên tài khoản

关于基于帐户的营销您需要了解的一切

From the ever-changing landscape, a new trend has come up: Micro SaaS. Saas This is a concept that started around 7 years ago but has grown in popularity since the pandemic. Now more and more people are taking their ideas and turning them into valuable Micro Saas ventures. It is expected that . There are opportunities for all of us in this rapidly growing industry. SaaS revenue will reach $369.4 billion by 2024 And if you’re thinking “but what is a micro SaaS?”. That’s what we’ll explore in this article. We’ll start with a definition of how it differs from a regular SaaS and then we’ll look at practical ways to build one. If you’re ready, Let’s jump in! What is “Micro SaaS”? As its name suggests, a micro SaaS is a small-scope SaaS. Instead of thinking about a tool like ClickUp, think more about a Clickup plugin (which is called a “ClickApp”). Tyler Tringas, the founder of Storemapper, popularized the term online. : He describes it as “ .” A small SaaS company from a solo entrepreneur or a small team that’s typically bootstrapped and going after a niche market. It’s also prioritizing profits and business sustainability as opposed to growth As you can see, it’s very similar to a regular SaaS business except that the creator of a micro SaaS isn’t trying to apply for Y Combinator or build “the next big thing”. This is a business model that is more in tune with the way indie builders work. A micro SaaS can start as an experiment or a way to capitalize on a specific need from a niche. The idea here is to solve the need in the best possible way while making the most out of the available resources. Where traditional startups are all about growth and scaling, micro SaaS companies focus on consistent profits, a loyal group of users, and a lean business operation. It’s a much more “beginner-friendly” approach to building a SaaS product without taking on too many of the risks that a traditional startup would have. Experts like Rob Wailing recommend this as a first step into the world of SaaS. As opposed to going all-in on a big endeavor that may or may not work. And how is it different from a regular SaaS? Both types of SaaS have a similar structure, focused on solving user needs through a software product. But one of the main differences between the two is the . scope Traditional SaaS companies create software products that offer many solutions and try to address a wide range of users or clients. A Micro SaaS company creates product that solves need for a specific market niche. one one But while that’s the main difference, there are other ones we can talk about. For example… Target market Micro SaaS: Focuses on specialized and niche markets. For example, document management for family lawyers. Regular SaaS: Caters to broader market segments that have many users or clients with well-known use cases. Product scope Micro SaaS: A simple and straightforward product that offers a particular service. Think of an auto-DM app for Twitter as opposed to a social media scheduler. Regular SaaS: A bigger product that has many features and provides different solutions. You might use a couple of them but it’s likely that you don’t use everything the platform offers. Funding Micro SaaS: Is bootstrapped or self-funded and doesn’t require outside investments. The costs associated with building or marketing the product are kept low. Regular SaaS: Needs a substantial amount of funding for the product, marketing, sales, founding team, customer support, and so on. Competition Micro SaaS: They operate in untapped markets with limited competition, This is because of their particular niche. Regular SaaS: They experience much more competition and fight for a “piece of the revenue pie”. Think about project management or note-taking tools. Customer support Micro SaaS: Oftentimes the founder is the person who talks directly with the users. This helps to develop relationships and prevent churn. Regular SaaS: Has a dedicated person who handles this process or outsources it to another company that specializes in customer service. Potential Growth Micro SaaS: Can scale to thousands of users and bring in big revenue but it’s not concerned if the growth stalls as long as it keeps the users and the profits coming. Regular SaaS: Faces constant pressure to increase month-to-month growth due to investors and external stakeholders. Profitability : Being bootstrapped they can’t spend more than they have. This affords better control over expenses and profits. Most micro SaaS are profitable or at break even. Micro SaaS : Doesn’t turn a profit in the first months and survives purely on VC funding. Proper allocation of funds is key so that it can start generating revenue from the product as soon as possible to avoid bankruptcy. Regular SaaS They’re quite different, huh? Practical steps to start building a Micro SaaS Now that you understand what a micro SaaS is and how it’s different from a traditional one, we can look at some steps for you to start your journey in the micro SaaS space. Niche identification The first step is to identify particular problems or pain points in niches that are related to your interests/areas of expertise. You’ll do better making Shopify or WooCommerce plugins if you have ecommerce knowledge, rather than making a Twitter AutoDM product. Take a look at industries that are growing rapidly or going through many changes. These present great opportunities for building a micro SaaS that can serve unmet needs. Demand validation Even though a micro SaaS is not as risky as a regular SaaS, you cannot omit this step. Make sure there’s a significant group of people that have the need that you’re trying to solve. You don’t need to get too fancy here. Browse through online groups and subreddits in a particular niche and see what people are talking about. You can also strike up conversations with potential clients and gather insights you wouldn’t get otherwise. MVP creation Now is the time to prove that the problem is worth your time. The way to do it is to build an that people can use (and pay for). Since time is a key factor, you can build something with code boilerplates or no-code tools. MVP The main focus here is to do a good job solving the primary pain point even if the rest looks barebones. Make sure that you put out something that early adopters can use and get value from. Constant iteration This is the step that most people miss or don’t pay enough attention to. You want to have a direct channel of communication with your early adopters because they’ll be the best source of insights for improving and refining the product. Embrace the “beta” status and keep improving. Whether it is the onboarding, the user experience, or the actual functionality to support more users, #AlwaysBeImproving. Support & retention Micro SaaS companies have a unique advantage when it comes to customer support. Since they have a small user base, they can communicate directly and develop relationships with the users. When you talk to customer support, most of the time it is the founder (or founders) themselves. There’s the opportunity to turn users into raving fans that would do marketing for the product because they like it and find it so useful. Also, issues with the product are an opportunity to show that there’s a real person on the other side who’s open to feedback and willing to change according to the user’s needs. If you follow all these steps in order, you have much better chances of building something that specific people will find very useful and they’ll thank you for making it. Making something that’s valuable and solves other people’s needs is awesome. And it is even better when you get paid for it on a recurring basis. Once you have enough funds, you can invest in making the product better, adding one more team member, and expanding your market reach. Here are some Micro SaaS ideas you can try : You can build a plugin that integrates with WordPress sites and makes it easy to translate or localize the content for a particular group of people, say Germans or Russians. You can also look into other sites that have marketplaces like Shopify and build the plugin for their sites. Translation plugin for WordPress : The key here is to build a chatbot that caters to specific professionals (like the ones mentioned before) and can provide specific answers to customers' questions. This is what will differentiate you from the bunch of generic business chatbots out there. Customer-facing chatbot for chiropractors or defense attorneys : You can move over from the WordPress ecosystem to modern sites built on Webflow. The idea here is a plugin that will offer much more advanced features to make handling SEO easier for sites of business owners. And you can go even more niche and work with just a specific group(s) of people. Plugin to better manage SEO on Webflow sites : There are many more startup accelerators and seed funding programs now than there were 5 years ago. And most of them use some sort of integration between Notion, Airtable, Google Sheets, and the like. Applicant tracker for startup accelerators Your tool can seamlessly integrate with existing tools and then move into handling the data entry itself so everything is together in one place and gives people a broad overview of how their programs are doing. : If you think about it, this would be a very useful tool and I can’t believe something like this doesn’t exist already. Most pricing pages come by default from the payment provider that the business uses (Stripe most of the time). Plugin for pricing pages with analytics and A/B testing But none of these providers have such a service yet. They don’t allow displaying prices with different currencies or helping see if a $20/month price is better than a $19.99 one, or any other kind of experiments with analytics to see the difference. Those are just a few ideas that you can take and get started with the steps I shared before. (And I saved you the work of doing the first step, you’re welcome.) Conclusion There you have it! You now know what a “micro SaaS” is and why it has become so popular for solopreneurs, bootstrapped founders, and indie creators alike. You also know what steps to take if you want to get your feet wet in the world of SaaS and a couple of ideas to do so. Remember to gain a thorough understanding of the needs of the people in the niche you want to serve. Be a part of that niche so you can gauge the demand, and keep iterating on your product. That way you’ll have much better odds at building a successful product. The good thing about micro SaaS is that you can keep your costs low and can build more than one product. That way you will be able to diversify your portfolio of products and de-risk your building journey. So, go ahead, unleash your creativity, develop your skills, and make an impact in your chosen niche with your own micro SaaS venture! Thanks for reading. Hope you found it useful. Don’t forget to so you don’t miss future articles. subscribe on Hackernoon

Micro SaaS: What It Is and How to Build One

Computer vision has captured the interest of entrepreneurs all over the world, and for good reason: the capabilities of modern AI tech makes previously impossible ideas into real products. Detecting and classifying objects in photos and videos has found applications in many different areas and hundreds of systems — from security cameras with built-in facial recognition and detection of diseases based on x-ray scans to simple mobile apps. But enough with the intro, in this article I wanted to share the ‘behind the scenes’ of how a computer vision product is developed, especially a complex one. I have had an opportunity to work on Birdsy — a bird recognition app for people who want to see who visits their backyards while they are not looking. Birdsy is a complex, AI-powered app with real-time object detection and classification that needs to be able to run on weak hardware, detect bird types and sex with high accuracy. Given all that, the road from the initial idea to publishing the app in app stores was complicated — and captivating at the same time. We have faced many hurdles — both from the business and development side of view — that I’ve decided to share in one place to hopefully help entrepreneurs and AI developers who might be facing the same project. The task at hand Birds have had millions of years of evolution to blend in perfectly with their environment to avoid predators and, in this case, bird watchers, making it harder for them to admire wildlife. While observing certain bird species face to… beak can be problematic, monitoring them through a video camera from the comfort of your home is a lovely way to enjoy our winged friends, especially if AI removes the need for looking through hours of video footage and sends you alerts when a bird has entered the camera’s view, automatically detecting what bird species it is. There are two parts to Birdsy: Object detection — a neural network in charge of detecting the presence of a bird or a mammal Object classification — a neural network in charge of determining which bird or mammal species was captured Low-quality cameras for object detection To make the service more approachable and easy to use, any camera can be used for bird watching. This is where we ran into the first problem: low-quality cameras as they are the most affordable and the most widespread. While the ‘no camera limit’ is great for users, it presented a challenge for us, as the object detection model runs using the camera chipset. Where someone gets a good deal, others get the short end of the stick, in this case ‘others’ being our CV developers. Working with a cheap camera means working with a cheap chipset which makes it impossible to use the default neural network architecture. Compared to a top-of-the-line, gold standard of computer vision video cameras (NVIDIA Jetson Nano) which allows using around 120 layers of default YOLO v4, the cameras we had to work with allowed only for 22 layers. Where a full YOLO v4 neural network provides great recognition results, a stripped-down version performs poorly. We have tested both and were unpleasantly surprised with how low the model depth was when running it using a cheap chipset. Testing default YOLO v4 vs Reduced We started with training the default YOLO v4 model and testing it on the customer’s dataset The results we achieved were satisfactory - 95% mAp, which in the world of computer vision is more than enough to launch a model into production. After retraining the model to fit the camera’s parameters, the detection quality dropped significantly. But where machines fail humans advance. We have tested the neural network on test data and visually evaluated false positives and false negatives. This highlighted where the network lacked knowledge and where it made the most mistakes. We ain't nothin but mammals, or false positives The network was eager to detect people, especially people’s hands, as animals (and we don’t blame it, humans ARE animals after all). While, from a biological point of view, this is correct, the end-user is more interested in looking at birds than their neighbors, so we had to work on teaching the network to ignore people and focus on birds and mammals instead. To do this, we have added negative examples, including pictures of people at various angles as well as human hands. What lurks in the dark The cameras have two modes: regular daytime mode which produces full-color images, and nighttime infrared mode, which produces black and white images. When the camera switched to infrared, the model produced a lot of false positives: tree leaves moving in the wind insects, like moths, that are attracted by a warm camera fountains Users would be less than happy to be woken up by a notification, get excited to look at an owl or a fox, but end up looking at a recording of a moth banging its body against a camera lens. In order to reduce sleep interruptions only to a minimum, we collected instances of false positives in nighttime settings and marked them by hand. Instagram vs Reality Ever heard of social media being called a ‘highlight reel’ where people present the best version of themselves? Who knew the same could be true for wild animals. Photos of birds that can be obtained from open sources, like Google Images and Youtube videos, are usually high quality, very sharp, and depict specimens at their best, looking at the camera or at least positioned front on, with nothing in between the bird and the camera obstructing the view. Reality is not always as pretty. Cameras produce low-quality images that can make it hard to understand what’s going on even for a human eye, bad weather conditions like rain, snow, or dust can obstruct the view, and we are sure birds sense when someone wants to capture them and position themselves in the most ridiculous way possible. The dataset that the client provided (consisting of shart images found on the Internet) was not of very much use for this project. We needed to collect a set of images of birds in real conditions using the client’s cameras to show the model what birds look like, and not how they are presented on social media. really What we have now So, after doing all of the above: manually going through every instance where the network was wrong teaching the network to ignore people and not detect them as birds or mammals working with black and white images and false positives collecting a dataset of birds in real-life conditions, under various angles, and in different weather conditions We have managed to achieve a 97,5% mAP for object detection. This is a very high result for a computer vision model as the unwritten rule for any CV model going into production is to have over 94% mAP. Achieving perfection (almost) While the results we have achieved now are more than enough to be used in the final product, there’s still room for improvement. the network mistakes flowers for birds birds’ view from the back is still sometimes a mystery birds partially covered by random objects birds close to the camera After enough images for each group are collected, we expect the mAP to increase and reach 98,5%. Image classification model The next step in getting to know your backyard visitors is to pass the image with a bird to an object classification model. Its goal is to recognize the bird species and its sex. As some bird species live exclusively on certain continents, we have decided to create two models - one for those who live in North America, and one for those in Europe. One step at a time: a lesson in multistage neural networks Initially, the problem of object classification was solved using a ‘head-on’ approach: the network was shown photos of all the different species, both males and females, from which it tried to learn what they look like and how they differ from each other. This resulted in very poor accuracy scores, in other words, the network made a whole lot of mistakes when identifying bird and mammal species. The network was trying to learn too many aspects at the same time. Many bird species look very similar to each other and differ from one another by a single patch of differently colored feathers or a differently shaped beak. Retaining all of this information, along with what different sexes of the same species look like, is too difficult under given circumstances. The network would often mix up bird species while determining the more broad bird type correctly. For example, the difference between a hooded warbler and a kentucky warbler in a patch of black feathers: The network would label a hooded warbler as a kentucky warbler, producing a wrong result, but being generally correct: both ARE warblers. For the sake of time, the client decided it was more important to detect the overall bird type rather than its particular species, so that’s where we started. After model evaluation, we have decided to implement a multistage approach: all bird species were grouped into more general categories: eagles, sparrows, crows, pigeons, etc. the network would first determine the overall bird type the second step is to detect which species it is the last would be to determine if the bird is male or female By grouping the bird species, we have managed to decrease the number of classes from 98 to 49, which greatly improved the accuracy score as the network simply didn’t have as many classes to choose from. Practice makes perfect, even for machines When you come across a new concept, you read books or watch educational videos to grasp it. If you fail, you ask your friend to explain it to you or you visit a seminar on the topic. In other words, you try to accumulate more information about it to understand it better. The same goes for neural networks. The better you need one to understand what a warbler looks like, the more images of warblers you need to show it. The more data it has looked at, the better accuracy scores will be. The multistage approach we’ve chosen not only improved the accuracy of the object classification model but also made it possible to analyze the dataset and determine where the network lacked learning data. The ugly duckling problem After the object classification model was launched, we were surprised to receive results that were much worse than what the tests showed us: the model could not determine the bird species or type correctly. The problem ran deeper than this: our computer vision developer in charge of the whole project, who has learned all of the bird species himself while working on it, also failed to determine what the birds were when he received the images incorrectly labeled by the network. It turned out that July is not the best time to launch a bird classification model as it is the time where teenage birds learn to fly and leave their nests. Remember the ugly duckling story? Well, it’s true for most birds, fledglings look nothing like adult birds, and it is hard to know what bird you are looking at if it’s still young. We have collected images of young birds over the summer and plan on training the classification network to determine the different bird species at different ages. Teamwork makes the network work Birdwatchers are a passionate bunch, they know how to identify a bird by the shape of its single feather. They possess knowledge that our classification network dreams of having, so why not bring the two together and form a bird-loving alliance the world has never seen before? Currently, the classification network doesn’t just tell the user the bird species, it shows the degree of confidence along with other guesses. The user can confirm the network’s guess or correct it, thus helping us train it - one bird at a time. After running the user feedback system for 3 months, we have collected over 20 thousand images. This data is invaluable to us since the photos are made in real-life conditions (bad weather conditions, at night, etc.) and are marked up by experts. When you stare into the abyss, the abyss chirps back at you It is worth noting that during this project, we have become the bird experts ourselves. Looking at birds all day long, while essentially educating a virtual child on all the little differences between different types of sparrows, makes one an instant platinum member of the birdwatching community. If all else fails, our CV team members can easily find themselves in ornithology. On a serious note, looking through thousands of images of birds, be it for dataset markup or analyzing where the network makes the most mistakes, we have delved deep into this project and came out the other end not only with a bunch of bird knowledge but a better understanding of how complex image recognition and classification systems work, how to best implement them, how to analyze a large dataset and find its weak points. This project was invaluable for us as an opportunity to research and work with the latest computer vision technologies, work with real-time customer feedback, and polish our problem-solving skills when working with outdated code.

Creating a Bird Detection AI: From Ideation to Product Launch

একটি পাখি সনাক্তকরণ এআই তৈরি করা: আইডিয়া থেকে পণ্য লঞ্চ পর্যন্ত

Erstellen einer Vogelerkennungs-KI: Von der Idee bis zur Produkteinführung

Creación de una IA para la detección de aves: desde la idea hasta el lanzamiento del producto

Créer une IA de détection d'oiseaux : de l'idéation au lancement de produit

बर्ड डिटेक्शन एआई बनाना: विचार से उत्पाद लॉन्च तक

鳥検出 AI の作成: アイデアから製品発売まで

조류 감지 AI 만들기: 아이디어 구상부터 제품 출시까지

Criando uma IA de detecção de pássaros: da idealização ao lançamento do produto

Создание ИИ для обнаружения птиц: от идеи до запуска продукта

Kuş Algılama Yapay Zekası Oluşturma: Fikir Geliştirmeden Ürün Lansmanına

Tạo AI phát hiện chim: Từ ý tưởng đến ra mắt sản phẩm

创建鸟类检测人工智能：从构思到产品发布

How to Hire for No-Code Development: Finding the Right Talent

Cómo contratar para el desarrollo sin código: encontrar el talento adecuado

Comment embaucher pour le développement sans code : trouver le bon talent

नो-कोड विकास के लिए नियुक्ति कैसे करें: सही प्रतिभा ढूँढना

ノーコード開発に雇用する方法: 適切な人材を見つける

Como contratar para desenvolvimento sem código: encontrando o talento certo

Cách tuyển dụng để phát triển không cần mã: tìm đúng tài năng

如何招聘无代码开发：寻找合适的人才

Sometimes taking a new job means taking a lot of unexpected trouble with it. That happened to me once. What promised to be tough, but mostly hassle-free work nearly turned out to be a Mission Impossible task. The good news is that even humble humans can sometimes hold the sky from falling in an Atlas fashion. I wanted to share my story to show that ultimately no task is impossible. You don’t have to be James Bond himself: if I did it, you can probably do it as well. “So, 007... Lots to be done” Like many good thriller movies, this episode of my career started peacefully, without any suspense. In June 2021 I was hunted down by a big company that grew out of a mobile telecom provider. With time it turned into a nationwide tech major by building a diverse digital ecosystem. One of the ecosystem’s pillars was enterprise . The company has already had a strong IaaS and data center arm for a while. Additionally, about two years before my arrival it acquired the market’s oldest virtualization provider for over 30 million euros. The next step was to gather all cloud assets on a new platform built into a ‘unified provider’ concept. The vision was that any business could get all imaginable cloud services at a universal hub. cloud services The new platform was being built by a remarkable team, led by the same guy who hired me (sticking to the 007 tradition, let’s call him M). He was an avid promoter of horizontal dev structures and ‘bubble escalation’ principles. That basically meant that in his team there were no bosses and all issues were supposed to be resolved by consensus. If a problem was complex enough to expand beyond one product or team cell, owners of the products or teams involved were engaged. If no effective solution was found, the problem would be escalated until a common link for the conflicting products was found in the management chain. So the team was good and progressive, the company was big and getting even bigger. All of that promised a comfortable experience with decent perspectives. My role as a Lead Engineer was to identify services that were unique to the recently acquired provider and lead their migration to the new hyper scaler cloud hub. The task was big and challenging but looked quite manageable. Well, at least it did until hell broke loose… My onboarding paperwork was not completed yet and I didn’t even visit the to claim my duty PPK, oh, I mean my corporate laptop, when M summoned his entire team for an emergency meeting. He had bad news and good news. The bad news was that the legacy platform’s dev lead was leaving the company all of a sudden. And so were the majority of his backend and frontend developers. We had just two or three weeks to transfer the entire knowledge about the platform to our team. The good news was that this task was assigned to me. Or was it the good one? quartiermeister “The whole office goes up in smoke and that bloody thing survives” Well, that bloody thing had to survive, no options. The legacy platform generated a hefty revenue servicing over 2,500 paying corporate users and operated half a dozen data centers. I had to keep that system working, hastily hire, onboard and train the missing personnel AND also plan and execute the initial migration task. What assets did I have on my side? Well, I finally had my laptop. Also, I had all that was left of the legacy dev team: a junior developer, just recently promoted and retrained from a tester role; a brand new outsource frontend developer; and yet another outsource developer, who has been working on the project for four years and later on proved to be one of our saviors. Luckily, the turmoil did not affect the support, virtualization, and network teams. My biggest nightmare was losing the knowledge and experience accumulated by the legacy team over the last eight years. This could obviously result in downtime, hamper inefficiency, scare off clients and dry out the cash flow. We wobbled on the edge of disaster for about four months. By the end of summer, the product owner was gone and we had a new one that previously did marketing. As if the situation was not difficult enough, we were tasked with supporting the manual sales billing system. Being critically understaffed, we now had to have a dedicated specialist to do this job. Finally, in autumn, after countless interviews, we managed to forge a new team hiring three dev ops specialists and five backend developers. Just as the new team got assembled, there came the first battle trial: our platform came under attack. It took us one sleepless night to figure out what was going on. Code errors, server overload, and malware were ruled out one by one, but the problem persisted. Finally, we discovered a plethora of unfinished IIS network connections to our servers, which was an indication of a attack. DDoS The solution was simple: we just put the platform under the cloud-based protection service, which was actually one of our own products. That sentinel still stands, although it is not perfect. Once, as we altered the platform’s framework and server responses, it mistook our entire traffic for DDoS activity and tried to block it. A single call to tech support was enough though. Counters were reset, cache was cleared and the problem was solved. “- Well, everybody needs a hobby. - So what's yours? - Resurrection.” Dealing with legacy systems often means mastering and replacing outdated technology. This was exactly the case. The eight-year-old platform was heavily relying on older versions of .NET and it was a pain to source experts on that technology to document all the platform’s key points like billing and server creation. Luckily, I got help from two colleagues from the parent company. Then the platform was transferred bit by bit to a newer .NET framework version and service-oriented architecture. Next, the user password generation algorithm was far from modern cryptographic standards. We replaced it with a more robust one and recommended users to use SSH keys. Also, the legacy platform had a monolithic architecture that became a bottleneck for performance and scalability. Tackling this issue, we broke it down into microservices with their own databases and caching, improving speed and flexibility. Creating new client servers took about 15 minutes, which was way too much. To reduce this time to 3-5 minutes, we created a pool of preconfigured machines that could be modified to customer needs on the go. We modified deployment pipelines. We transitioned from IP to DNS-based infrastructure. We discovered a bunch of undocumented processes. Finally, we settled down on a new technical infrastructure by early 2022, after six months of 24/7 work. Finally, what seemed like a bust in June 2021 turned out to be a success in 2022. Despite being understaffed, outdated, and in continuous transition, the platform maintained a 99.96% SLA adherence. Our client base grew. Transition to a new framework reduced infrastructure costs by a whopping 50%. Our revenue increased by 126% year-on-year in 2021 and by a further 102% in 2022, amounting to about 2.8 million euros. What’s more, our platform was ranked second in the national IaaS Enterprise rating in 2021, our most difficult year. Two years later we were ranked #1. “Hold your breath and count to ten” The major lesson I learned from this experience is that you only grow when you do things you thought you were not qualified to do. Most miracles are done by holding your breath and doing the job. Also, there is some practical advice I would like to share: is essential, especially for long-lived projects. : too much paperwork will be hard to maintain so parts of it will inevitably get outdated. It is crucial to document all business requirements, every bit of business logic, deployment sequences, and solution descriptions. That way you (or your successors) will be spared from the nightmare of reverse engineering an uncharted product in search of logic and reason. Documentation But keep it reasonable and can be an advantage. However, it is crucial for people to listen to their colleagues and communicate with them. Toxicity should be tabooed. Horizontal no-hierarchy teams consensus-based decision-making because you have to find a fine balance between specialization and a risk-posing ‘bus factor’. Task distribution is an art with all the underlying DevOps and reversible deployment infrastructure. Testing in near-real conditions will save you many hours and a lot of nerves, especially when it comes to integration and shifting to a newer framework version. You should always have a testing environment . They deserve explanations of what is happening and why. Do your best to speak their language and, most importantly, to comprehend their goals. Keep connected with the business stakeholders Thanks for reading and good luck! The lead image for this article was generated by HackerNoon's AI Image Generator via the prompt "surviving skyfall"

Surviving a Skyfall: A Lead Engineer’s True Story

Does Your SaaS Have a Positioning or Messaging Problem?

আপনার SaaS এর কি পজিশনিং বা মেসেজিং সমস্যা আছে?

Hat Ihr SaaS ein Positionierungs- oder Messaging-Problem?

¿Su SaaS tiene un problema de posicionamiento o mensajería?

Votre SaaS a-t-il un problème de positionnement ou de messagerie ?

क्या आपके सास को पोजिशनिंग या मैसेजिंग की समस्या है?

あなたの SaaS にはポジショニングまたはメッセージングの問題がありますか?

SaaS에 포지셔닝 또는 메시징 문제가 있습니까?

Seu SaaS tem um problema de posicionamento ou mensagens?

SaaS'ınızda Konumlandırma veya Mesajlaşma Sorunu Var mı?

SaaS của bạn có vấn đề về định vị hoặc nhắn tin không?

您的 SaaS 是否存在定位或消息传递问题？

Last week, I had the distinct pleasure of being on my buddy Todd Sharp's live stream, Streaming on Streaming. You can watch the recording of that session here: https://www.twitch.tv/videos/1811192764?embedable=true Todd is the principal developer advocate for Amazon Interactive Video Service (IVS), or, more simply, a way of taking the power of the Twitch platform and putting it in your hands. gives you: incredible IVS The ability to create channels for your content. Multiple ways to broadcast your content, from web-based to more powerful tools like OBS. Multiple ways to display your content, including a pretty simple web SDK. Super detailed reporting. And deep integrations into the stream that allows for things like transcriptions, Lambda-based chat moderation, and more. This is a commercial service, but like pretty much everything in AWS, there's a free tier that lets you test things out and see if it makes sense for you. In the session I had with Todd, he wanted to put their own documentation and console through a "first-time developer's experience." So first off, thinking about and really caring about the initial developer experience with your product is probably one of the most important things you can do. I know in my own career in developer advocacy, it's near impossible for me to try something new without constantly examining and commenting on the developer onboarding. Todd deserves respect for doing this live on his stream. mad I'm kinda well known for breaking things, doing things wrong, and generally just being your worst nightmare when it comes to DX, so that was quite brave on his part. (And to be clear, we didn't preplan any of this stream. I wasn't given anything in advance, and the only real knowledge I had was reading his blog posts and general chat.) As you can imagine, something like "roll your own IVS" is going to be really complex, but in our one-hour session, we got my channel set up, I broadcasted from OBS and a web tool and was able to build a simple web page to display the stream. I thought I'd share some of the highlights from that here as the idea of supporting streaming in the Jamstack sounds incredibly compelling. This will be somewhat high-level, but the are pretty thorough and will give you more detail about the particulars. docs You will also want to start off with the guide. Getting Started With that in mind, here's a basic outline of how simple this is to get started. Step One - Get AWS I'm just going to skip this. I mean, I guess I'm not as I'm calling it out, and you should never assume anything, but as a large percentage of folks already use AWS, my assumption is that you already have an account. I did and used my root one, but if you follow the link I shared above, they have you set up a user with more restricted access, which is The Right Thing to Do, and We Always Do The Right Thing in tech. Ahem. getting started Step Two - Make Your Channel The next thing you'll do is define a channel in the IVS portion of the AWS console: As a reminder, the search box on tox of IVS does a good job of finding stuff. AWS can be a bit overwhelming, but their search has made things a lot easier lately. really I kind of assume most folks know about streaming and get the basic idea of a channel, but if I were to start streaming, I'd probably only have one channel for myself. If I wanted to add streaming to my company's website, I could imagine having a channel for things like training, external events, and so forth. At the bare minimum, one channel is needed. When creating a new channel, the bare minimum is the name: Note that one of the options is automatically storing the streams to S3. I didn't enable that on the stream with Todd, but it's really nice that it's that simple to enable. Obviously, there's going to be a cost in storing large video files, but I appreciate how simple it is to enable. Step Three - Figure Out Your Broadcaster The getting started docs concerning cover using their SDKs, OBS Studio, or FFmpeg. I've used OBS Studio in the past, so during the stream with Todd, I used that. I'll warn folks though that if you've never used it before, it can be quite overwhelming. setting up your streaming It definitely was for me (heck, I still barely know what I'm doing). Instead, let me share another option Todd shared with me later in the stream, . This is a web-based streaming solution that you can use to test IVS. stream.ivs.rocks Open the page in your browser (note that it says Edge is not supported, but I had no issues with it), and click the gear icon to get to your settings. You'll want to specify your "Ingest endpoint" and "Stream key", both of which you can find in the AWS console in your channel details. Don't make the same mistake I did - the "Ingest server" is NOT the same as the "Ingest endpoint", you'll want to open and expand "Other ingest options" to see that. Once you've done that, you can click the "Start streaming" button below, and literally, that's it! While this is not something you would do for a "real" stream, it's simpler and quicker to set up. much Once you're streaming, go back to the AWS console, click on "Live channels", and you can see your stream in action: If you go to the channel details, it's also displayed there as well: By the way, while there, and in the future, you can view past streams and all kinds of cool metrics about the stream. A lot of this used terminology I'm not familiar with, so that's something to keep in mind if your new to streaming (and is something I shared with Todd as feedback), but if you like stats, AWS has got you covered. Step Four - The Front End Actually viewing the stream requires figuring out you're going to do so. Considering I'm a web guy, and this post is about doing it on the Jamstack, the on their documentation is where you would want to go next. Once again, the initial implementation can be very simple. where web guide Here's an entire implementation: <!DOCTYPE html>
<html lang="en">
<head>
	<meta charset="utf-8">
	<title></title>
	<script src="https://player.live-video.net/1.18.0/amazon-ivs-player.min.js"></script>
	<style>
	video#video-player {
		width: 800px;
		height: 450px;
	}
	</style>
</head>
<body>

<h2>My Stream</h2>
<video id="video-player" playsinline controls autoplay></video>

<script>
const pbURL = 'https://e0e6ec1c389e.us-east-1.playback.live-video.net/api/video/v1/us-east-1.100330257216.channel.4tjprROF5ZWE.m3u8';
document.addEventListener('DOMContentLoaded', init, false);
async function init() {
	if (IVSPlayer.isPlayerSupported) { 
		const player = IVSPlayer.create();
		player.attachHTMLVideoElement(document.getElementById('video-player'));
		console.log('player made');
		player.load(pbURL);
		player.play();
	} else console.log('u stink');
}
</script>
</body>
</html> Let's break it down. You've got a script tag up top loading their SDK. Next, I've got my HTML with the important bits being the tag and my CSS to properly size it. <video> The JavaScript creates an instance of the and attaches it to the DOM. The value comes from the AVS channel config: IVSPlayer pbURL And here it is in action! Now, before getting too excited, note that this is the simplest code you can use, but is not very bulletproof, in fact, and you'll definitely run into this while testing, if you aren't streaming, you get an error trying to load the stream. That makes sense, so better code would handle that. absolutely I took a quick look at the , and I see event support, so you should be able to have it listen for a stream beginning; either load at that point or do something in the DOM to let the person viewing the web page know that a stream began. web reference That's It! Ok, sure, that's not very production-worthy, but I literally had a streaming solution done in an hour. Now, this isn't going to be free, so that's something to keep in mind, but I'm really blown away by how quickly you can get started, as well as how much power you get out of the box. And with AWS handling everything, it's a great fit for the Jamstack. There are server-based APIs you could integrate as well, and that would be where I'd use something like Netlify Functions. So again - check out the . There's going to be a lot to digest, but there's a lot more there than I've touched on here. docs Next, check out Todd's , where he's shared a bunch of examples. Most recently, he demonstrated a and then followed up with an example of . posts on dev.to real-time multi-host video chat in the browser multiple hosts and live streaming, again the browser His posts involving chat and the power you have to moderate there is my favorite, I think. I'll also recommend the one he wrote on as being especially cool. creating your own "LoFi" radio station

How to Add Streaming to Your Jamstack Site in Minutes

কিভাবে মিনিটে আপনার জ্যামস্ট্যাক সাইটে স্ট্রিমিং যোগ করবেন

So fügen Sie in wenigen Minuten Streaming zu Ihrer Jamstack-Site hinzu

Cómo agregar transmisión a su sitio Jamstack en minutos

Comment ajouter du streaming à votre site Jamstack en quelques minutes

मिनटों में अपनी जैमस्टैक साइट पर स्ट्रीमिंग कैसे जोड़ें

数分で Jamstack サイトにストリーミングを追加する方法

몇 분 안에 Jamstack 사이트에 스트리밍을 추가하는 방법

Como adicionar streaming ao seu site Jamstack em minutos

Jamstack Sitenize Dakikalar İçinde Yayın Nasıl Eklenir?

Cách thêm luồng vào trang Jamstack của bạn trong vài phút

如何在几分钟内将流媒体添加到您的 Jamstack 站点

Smart Contract Security in Solidity

সলিডিটিতে স্মার্ট কন্ট্রাক্ট সিকিউরিটি

Intelligente Vertragssicherheit in Solidität

Una encuesta de 2023 sobre seguridad de contratos inteligentes para la solidez

Une enquête 2023 sur la sécurité des contrats intelligents pour la solidité

सॉलिडिटी के लिए स्मार्ट कॉन्ट्रैक्ट सिक्योरिटी पर 2023 का सर्वे

Solidity のスマート コントラクト セキュリティに関する 2023 年の調査

Solidity의 스마트 계약 보안

Uma pesquisa de 2023 sobre segurança de contratos inteligentes para solidez

Sağlamlıkta Akıllı Sözleşme Güvenliği

Khảo sát năm 2023 về bảo mật hợp đồng thông minh cho sự vững chắc

2023 年 Solidity 智能合约安全性调查

130 Stories To Learn About Dotnet

The Hidden World of Firmware: Exploring Your Computer's Boot-Up Process

ফার্মওয়্যারের লুকানো জগত: আপনার কম্পিউটারের বুট-আপ প্রক্রিয়া অন্বেষণ করা

Die verborgene Welt der Firmware: Erkunden Sie den Startvorgang Ihres Computers

El mundo oculto del firmware: explorando el proceso de arranque de su computadora

Le monde caché du micrologiciel : exploration du processus de démarrage de votre ordinateur

फ़र्मवेयर की छिपी हुई दुनिया: आपके कंप्यूटर की बूट अप प्रक्रिया की खोज

ファームウェアの隠された世界: コンピューターの起動プロセスを探る

펌웨어의 숨겨진 세계: 컴퓨터 부팅 프로세스 탐색

O mundo oculto do firmware: explorando o processo de inicialização do seu computador

Firmware'in Gizli Dünyası: Bilgisayarınızın Önyükleme Sürecini Keşfetmek

Thế giới ẩn giấu của phần sụn: Khám phá quá trình khởi động máy tính của bạn

固件的隐藏世界：探索计算机的启动过程

Storybook V2 Comic Book Builder: Part 2, The Document Generator

White Boy

Chico blanco

Garçon blanc

गोरा लड़का

白人男子

Rapaz branco

Cậu bé trắng

白人男孩

GROWTH INVINCIBLE

Unemployment Insurance Fraud Rose During the Pandemic 

It's been since the infamous DAO hack that shook the entire web3 world. The one where we witnessed more than 3.5 million Ether being stolen away due to a bug in the smart contract. 6 years, 3months, and 25 days This hack introduced us to one of the most dangerous attacks, possible in a smart contract. The Re-Entrancy attack, Since then there have been enormous improvements and attempts to mitigate the risk of introducing such attack vectors in smart contracts. Automated testing tools started including warnings about re-entrancy bugs, smart contract auditors became particularly cautious with codes dealing with external calls, and loads of blogs as well as video content were created ( ) explaining the re-entrancy attack. and are still being made However, if you have observed the exploits in the past few years, along with all other new attack vectors, re-entrancy exploits are still a major concern and can be seen as a considerable bug behind many smart contract exploits. In fact, the latest re-entrancy exploit that I read about was just a few weeks ago when with the exact same very well-known re-entrancy bug & $830,000 were lost. Stader’s NearX smart contract was exploited Well, this isn’t just about re-entrancy bugs in smart contracts and neither is the blog going to explain re-entrancy bugs ( ). not again Re-entrancy attacks are just one of the many well-known attacks that the smart contract dev community is well aware of but we find traces of such bugs in smart contracts even today, which leads to incredibly massive exploits. Now the question is — WHY? Despite having enormous tools, libraries, and educational content around such common bugs and attack vectors in solidity, why do we still witness such well-known attacks time and again? This is undoubtedly one of those that might have multiple narratives or answers. broad or open-ended questions However, after being involved in multiple smart contract security audits now, interacting with quite a few smart contract devs, and being part of some really active smart contract developer communities, I came across 2 extremely simple but imperative reasons behind this. Most importantly, these reasons revolve around the very basics of how we approach Smart Contract development and learn Solidity, especially in the initial stages. mindset 1. The “ ” Security-is-NOT-my-job It can unquestionably be stated that the majority of the developers in the web3 space believe contract development and smart contract security to be two different things, which is true, to some extent. However, completely denying any correlation between these two things is probably a mistake. The rationale behind this is the fact that, at the very heart of it, the process of smart contract development broadly includes 3 most significant steps: Design & Development Optimizations Security Validations of the Contract While we are quite well aware of the first two steps, we most often forget, or even worse, do not consider to be part of the contract development procedure at all. Security Validations It’s concerning because even if we consider a basic fact about smart contracts, i.e., their immutable nature after on-chain deployment, we can quite clearly see the significance of adding as a mandatory step in the smart contract development process. security checks and validations The fact that you cannot change a line of code in your contract even if you found a major bug just seconds after deployment, is daunting in itself. Well, just in case you think you can always upgrade your smart contracts or upgradeable contracts are extremely secure, let me stop you right there. 🛑 and think again. Read about the Wormhole Proxy Bug Upgradeable contracts can have bugs too. 🪲 What should you do? In very simpler terms, consider as an imperative part of any smart contract you develop, and learn at least the basics of smart contract security if you haven’t already. security checks & validations Once you consider this, you can no more rely on just writing test cases for your smart contracts. Test scripts are undoubtedly helpful, however, they are more inclined towards ensuring the contract functions execute as intended while the security of a contract is much more than that. Even as a smart contract developer, you should definitely be good with at least one of the following ( ) security tools to validate the security of your contract: actually more than just 1 These tools effectively help you identify any well-known smart contract bugs that you might have in your contract. Static analysis tools like , Slither , Mythril . Mythx help identify potential exploit scenarios or contract execution failures by throwing random & unexpected data into your contract. Fuzz Testing tools like Echidna or Harvey , which is an amazing runtime verification tool by that allows you to annotate a solidity smart contract with crucial properties. Scribble ConsenSys While auditing complex & bulky smart contracts, the one thing you need the most is a , and that’s exactly where comes in. It provides an incredibly simplified version of all crucial details about a contract’s structure including call graphs, inheritance graphs, etc. visualization tool Surya extension is an extremely helpful tool that provides security-oriented syntax as well as semantic highlighting and quite a few other tools that make the secure development of contracts easier. VS Code visual auditor My favorites → . Slither, Surya, VS Code visual auditor, and Echindna Why should you do it ( )? If you can get smart contracts Audited Well, to begin with, no one will ever care about the security of your smart contracts more than you ( ). The very first person responsible for the security of your code should be . and your team YOU Secondly, the smart contract audit industry has been ( ) in a “ phase. and still is “ High Demand & Low Supply of good security auditors This basically means there are just a handful of extremely experienced auditors and relying on just a few of them won’t really be scalable enough for the web3 world to expand its boundaries exponentially. Additionally, there is a huge line of projects waiting for their contracts to get audited, which is why, when it's your turn you need to be ready with the right set of contracts, adequate test cases, coverage reports, and most importantly, the crucial discussion points you might want to have with your security auditor. However, you won’t really be capable of having any effectual discussion with smart contract security experts if you yourself don’t understand, at least, the basics of smart contract security. The inclusion of the step in your smart contract development journey allows you to filter out all the well-known bugs beforehand with the help of static analysis tools. security validations This allows security auditors to specifically concentrate on the more important potential threats of the contracts instead of identifying and reporting the ones that could be easily found with the tools mentioned above. Therefore, performing your own security checks before an audit doesn’t just shorten the lengthy audit durations, it helps achieve an adequate & better result out of the whole procedure. This is a concept that the brilliantly defines as which intends to prepare your contracts before an audit to ensure that the outcome from the security audit is comparatively better and effective. Secureum community CARE ( Comprehensive Audit Readiness Evaluation ) It’s important to note that including security as a part of your smart contract development process isn’t a substitution for an audit of your contract, but a preparation for an adequate security audit. 2. Avoiding Mistakes & Experimentations with Solidity ( ) and the lessons that come from them Alright, while the first point was for developers already familiar with solidity( ), this part is more inclined towards those starting out with learning solidity or the ones in the very early phases of smart contract development. and basics of smart contract security Here is a quick tip for you: Along with learning and developing simple solidity smart contracts, don’t be scared of experimenting and making mistakes while learning solidity. Since its inception or smart contract development, in general, has been incredibly interesting but daunting as well as difficult for many developers at the early stage because of some very obvious reasons: Solidity The immutable nature of Smart Contracts and the idea of getting almost everything right in one single shot before on-chain deployment. The open-source nature of smart contracts and the fact that every single line of code is accessible/readable by anyone. The whole concept of programming and storing money within Smart Contracts and the security risks that come with it. Solidity still being at a very nascent stage and the difficulties in keeping up with the rapidly changing/evolving language. Now, the concerns and risks associated with making mistakes while developing a smart contract can’t be overlooked. However, these have an adverse effect on the journey toward learning smart contracts effectively. With so much at stake, it becomes harder for developers to experiment with Solidity or make mistakes on their own. The popular idea of “ stops developers from exploring different concepts of solidity and thus limits their potential with smart contract development, as a whole. Not reinventing the wheel or trying something new, to avoid introducing new bugs in the contract” In fact, it is now considered a lot safer to simply fork an already existing audited contract instead of writing one from scratch. While this definitely does minimize the risk of contracts having bugs in production, it does stop developers from dealing with all the complications one might( ) go through while developing the same. And, therefore, keeps us from deep-diving into solidity concepts more often than not. and should While simply following a blockchain development course or consuming online content on smart contracts might help you get started with any specific topic, it won’t let you dive in deep and learn the fundamentals. Not unless you get your hands dirty with the same. Most importantly, not experimenting with Solidity smart contracts also keeps us from learning about the various kinds of security vulnerabilities a contract might have and the plethora of ways a contract can be broken. For instance, going back to the re-entrancy example: Every smart contract developer might have heard, read, or discussed the reentrancy attack vector, but how many of us actually went ahead and tried to experiment with the same on some dummy contract, just to understand what happens behind the scenes? This is precisely where smart contract security-based war games or CTFs like also play such a significant role in learning smart contract development and security. They allow you to directly interact with a contract directly, make mistakes and eventually figure out the vulnerabilities. Ethernaut or Damn Vulnerable Defi Now, there are definitely some smart contract developers who experiment with Solidity and smart contracts a lot and therefore are becoming the best in the industry ( ). check the Underhand Solidity Contest winners or their , for instance Challange Submissions However, as I previously mentioned, for the web3 world to expand its boundaries and scale with utmost security measures, we cannot simply rely on a handful of experts in the space. Instead, every smart contract developer should aspire to learn more and dive in deep by not simply learning the basics but experimenting, making mistakes, learning from them, and then sharing them with the community. Because, quite similar to life in general, the best learnings in software development also comes from mistakes. every smart contract dev should have at least once: Mistakes or Learning Experiences If you are just starting out with Solidity, there are a bunch of mistakes/experiments you can ( ) do while learning. and should Dropping off some of them from the top of my head. Solidity 101 mistakes/learnings: Using keyword instead of and then realizing you never really stored the crucial contract states permanently on the contract. memory storage Relying on blog time stamps for random calculation and realizing how they can be manipulated by the miners is therefore a bad practice. More details are . here Storing secret information on smart contract state variables with a private visibility modifier only to find out that nothing is private on a smart contract. Every state variable value can be seen by anyone. Read more about this in SWC-136 You will always believe that a contract with no payable function ( ) will never receive any ether unless you learn how or payable fallback function selfdestruct can forcefully fund such a contract with ETH. Failing to provide required in functions & realizing how this can lead to unwanted scenarios any invalid arguments can be passed without proper validation. ( ) input validation SWC-123 Gas Optimization & Security mistakes/learnings : 5. Writing expensive loops only to find out how this could lead to a issue and fail the complete transaction. for block gas limit 6. Violating and realizing how this could lead to the classic Rentrancy attack. check-effects-interaction patterns 7. Using delegate calls between two contracts with different storage layouts and realizing why storage layouts must be exactly similar for delegate calls to work. It's extremely important to ensure storage layout between two contracts involved in a is exactly the same. Otherwise, this leads to storage collisions. Read more about storage collisions . delegatecall() here 8. Including inadequate access controls for imperative functions of the contract and realizing how this could lead to any bad actor executing transactions without approval. covers this topic quite adequately. SWC-105 9. Trying to send ether from one contract to another using the function only to find out that it always sends a hard-coded gas only. This will help you realize the significance of the function which allows adjusting the gas to be sent with a transaction. Read more about why transfer 2100 .call.value(…)(“ ”) . . call() might be better than transfer() 10. Realising how tricky it is to delete mappings values in struct or in general and learning the right way to do it. 11. Trying to swap with using Uniswap and being vulnerable to sandwich attacks. This might help you realize the dark side of transaction order dependencies and MEVs and the Token A Token B DARK Forest of Ethereum . While these are just some examples, there are way more interesting topics in smart contract development, from basic solidity to advanced deep dives in EVM Opcodes, that one can learn and experiment with. Wrapping it UP 😊 Web3 has come a long way in a very short span of time, however, the security of smart contracts is still a major concern. The two ideas discussed above aren’t gonna make it all sunshine and rainbows at one go. There is undoubtedly a lot more we need to do to make Web3 a safer place. However, imagine a whole generation of developers that includes the two ideas mentioned above while learning or developing smart contracts, prioritizes learning the basics of security, experiments with Solidity, learn from their mistakes, and then shares those learnings with the community. That will, slowly but surely, lead us to a much safer and more secure web3 world than what we have now. All it takes is some commitment be to consistent, the will to learn more from mistakes and experiments, and the aspiration to be the better version of the smart contract developer that you already are. About myself Who am I? 🙋🏻‍♂️ 𝙃𝙞, 𝙄 𝙖𝙢 𝙕𝙖𝙧𝙮𝙖𝙗 👋🏻 A Smart Contract Engineer and Dev Team Lead at . Push Protocol I work on smart contracts development as well as security audits of smart contracts. Drop a ‘HI’ and Get in Touch 🤝 My Socials |Follow my Weekly Newsletter |My Web3 Speech & Presentations Also Published Here

Another Re-entrancy Attack  -  What's Stopping Us from Being a Better Smart Contract Developer?

Stories, News & Mentions about BUNCHA

Buncha’s Stories on HackerNoon