Reeco

reeco

Skills like coding scare many people. The media has made it seem like writing code is a genius-level activity, as weird symbols race across the screen and techno music blares in the background. But coding is actually pretty easy. I’m not saying this to dismiss the work of brilliant programmers. A skill can simultaneously be fairly easy to get the basics in, while also being really difficult to master. Everyone learns to write, few people learn to write well. There’s no contradiction, therefore, in saying that basic literacy is an “easy” skill to gain (in that the vast majority of us can do it), without dismissing the efforts of talented writers. Nor am I saying this to mock people who are trying to learn to program and find it frustrating. Rather, I say coding is easy because I believe that almost all people, even if they don’t see themselves as particularly smart, can learn to write simple programs. That they don’t be mostly because of some structural barriers than any intrinsic difficulty with the skill itself. My Experience Coding I started learning how to write code when I was 14. I’ve read a couple of O'Reilly books on programming, took even free courses on Coursera and Udemy. Watch thousands of hours on programming-related videos on YouTube. I remember even working through the content of a Computer Science Degree online (which is totally unnecessary if you want to learn to code, by the way). If you inspect, in some ways... my background may seem to disqualify me about making statements on the ease of coding. However, I can say without a single doubt, that subjects like Accounting, Physics, Engineering and even Law are more difficult than programming. Most math you learn in high school is more difficult too, believe it; although you usually get wayyyyy more practice with algebra than writing code, which leads to a misperception which is more difficult. Why Does Coding Feel Hard? Learning to code is hard for a couple of reasons: This is the first activity for a wanna-be programmer. This can create the misperception that programming is really hard because newbies extrapolate the difficulty of getting set up to how it will be every moment after. Installing new languages can be super frustrating. Starting programming is super overwhelming because there are a stadezillion things to learn and you do not know where to start. Also, there are waayyyyyyyy too many languages, frameworks tools, libraries and plug-ins. The first moments of programming are the hardest. Getting set up is annoyingly difficult and often requires learning a new way of working with computers even before you write a single line of code. Consider the instructions for installing most languages: “ Open the terminal or command prompt. Type in a case-sensitive, exact set of instructions to download and install the language. Use GitHub. Homebrew. Versions matter too. Are you running 32 or 64 bit? ‘Cause if you’re not sure, it will crash with a cryptic error message and you’ll feel like an idiot.” These tools are learnable, like everything else, but they reinforce the impression given by the media that coding is mostly using elite tools with weird, unfriendly user interfaces. When people see coding, they imagine parsing the green-streaming letters on computer screens like the movie, The Matrix; whereas the truth is a lot more like following a recipe along with step-by-step. How Do You Get Over the Initial Difficulties of Coding? There are a few ways you can do this. My favourite is to just go to the language or technology official documentation, which will tell you exactly how to set up step-by-step. Alternatively, you can dive into internet tutorials (why do you think platforms like YouTube, Quora exists?), but recognize that sometimes they are aimed at already-proficient programmers, who know what OOP and GitHub are, and are fluent with writing commands into Terminal. If you get one of these, you can try to follow it, but don’t feel bad if you screw it up. It’s frustrating, and it doesn’t mean all coding will be like this. Another option is to avoid setup at all. Just use some coding tutorial website that teaches you to code with no installation. I like this too, but sometimes you can’t actually build the thing you want to build with these apps. However, if you hate the setup, that’s where I’d start. Most important, however, is to remember that I told you this. When you try to learn to code, it will frustrate you to get things running, and just accept that this is a small price to pay. Soon it will be easier and you’ll do stuff that is cool. Don’t feel dumb because you get stuck here. I still do and I’ve been writing code for years. What Coding Language/Framework/Library Should I Start With? This seems like a good question to ask, but, I’d argue, it’s actually the wrong way to think about learning to program. First, although programmers often boast about how many languages they know, recognize that most languages are only superficially different. Yes, I know all about language design, so don’t tell me about scripting versus compiling, or whether a language is strongly or weakly typed. Those things matter, but they’re details. The basics of nearly all languages and tools are the same. These concepts exist in almost all programming languages. If you pick a mainstream language, you’ll learn these in mostly the same way, so it doesn’t matter if you pick Python, JavaScript, C++, Java or even PHP. Variables. Loops. Functions. Pointers. Data Types. OOP. Modules. The place languages matter is you want to use them for. do what Want to write iPhone apps? Swift or Objective-C are the languages of choice. Need to create web pages? JavaScript is going to come in handy. Yes, you can use almost any language for any task if you tinker with it and get the right plug-ins. However, some languages are easier to get started with certain types of projects than others. Therefore, the first question to ask is not: which language should I learn, but which project should I start with? What Should Be Your First Coding Project? I recommend starting your programming adventure, even before you write a single line of code, with a decision about a concrete programming project you’d like to create. This serves a couple of purposes: . Once you know you’re building a website, you’re already leaning towards tools that were designed with that goal in mind. It narrows down the language/framework choices considerably . Transfer of learning is notoriously difficult. Learning directly by building works better than learning something and just hoping it will help you later. Everything you learn is connected to a destination . If you think it would be cool to make an interactive website, do that. If you’d prefer a game, do that. If you’d prefer to automate some tedious work, do that instead. Do what you feel is cool and you’ll be motivated to stick to it. You can work on something you think is cool Smaller is better in projects. Deciding to start with making the next Google is ambitious, but probably will get you stuck in the weeds before you make much progress. If your true ambition is huge, it’s often best to work on a toy project first. Many experienced programmers still do this when they are entering a new territory of programming. Toy projects take the essential ideas of programming, but turn it into something you can do in a few days or weeks, instead of years. Examples of good projects include: No graphics, but still requires learning concepts like loops, variables, input-output processing. A basic terminal text-adventure game. Start with just displaying a static page. Maybe add in comments, users, photos or interactive elements as you learn more. A simple website. What’s something dead-simple you’d like to have on your phone? It can be stupid to start, don’t worry. A simple app. A script for automating a tedious task. Programs are easier when they involve no multimedia content (websites are a bit of an exception), so if you’re making a game, for instance, a text game is easier than one with graphics, if only because making all the graphics can take time. Similarly, different core activities have different difficulties. Arithmetic and simple calculations that are done repeatedly are the easiest. It is more difficult to process text for exact patterns. Processing text for vague patterns is harder still. Processing, speech, photos and video is even harder. If you do end up picking an initial project that turns out to be super difficult, it’s okay to scale back. is much, much easier than It’s often not obvious that this is the case, in the beginning, so don’t worry if you accidentally pick a problem to start with. You can adjust it later to something easier. “Make an application that calculates my mortgage payments” “Make an application that can tell you what someone’s hairstyle is from a photo.” “hard” Which Resources Should You Use to Learn Coding? Once you’ve picked a project, the next step is to get some resources to help. This is a step many people worry over endlessly, but as the language choice, it’s a lot less important (and depends more on your goals) than you think. I won’t list specific resources, because there are so many good ones that my suggestions are going to leave out some of the best. Instead, here are three strategies for finding excellent resources: . Coding, is it really easy? Be a computer section in your city’s bookstore or library, you can just pick any of those. I personally like (they publish the best software development books), but there are lots of good ones. (If you haven’t figured out which language yet, just DuckDuckGo your type of project and look for suggestions.) I read the by , the first time I wanted to learn Python. Get a book that teaches you the language + project you want O’Reilly Self-taught programmer Cory Altoff . , , , , and others all teach computer programming online. Once again, the thing that matters most isn’t the exact class, but whether it teaches the language/project domain you care about. Attend a MOOC Coursera edX MIT Harvard F reeCodeCamp Stressing over which book or course to pick is the wrong thing to worry about. The main thing to do is to use the book or course to learn enough to tinker on your project, not to master programming on its own. Starting your project before you're ready is definitely the way you should feel about it. Do What Real Programmers Do and Ask Google Once you actually get started writing code, you’re going to encounter many, many situations where you either don’t know how to do something, or you learned how to do it before and you’ve forgotten. In these situations, you should do what real programmers do: . This isn’t a shameful activity, but a part of real programming. I’ve been coding for years, but I always forget silly syntactical things and so I find myself duckduckgoing regular expressions over and over again. It’s not bad, it’s just part of the process. ask DuckDuckGo/Google/StackOverflow Once you’ve gotten yourself installed, you’ve learned a bit with your book to know the basics and have started working on your first project, you’ll learn the rest by googling and adding to your library of programming knowledge. Computer science theories, detailed understandings of the language you’re working with or advanced design patterns can wait until you’ve finished a few real projects and feel like you can code something. Notice #1: Don’t Copy-and-Paste The first piece of advice when it comes to this step is to never copy-and-paste. Copy-and-pasting is bad because you don’t try to understand the code you’re copying. If you have to transcribe, in contrast, you naturally ask yourself, Even if you don’t have a great answer immediately, typing things for yourself will open your mind up to the answer whereas copy-and-pasting shuts down thinking. “why this? why not something else?” Notice #2: Try it Yourself Before Looking for a Solution The second piece of advice is to always try to solve something yourself before looking up how someone else does it. Most problems have many, many ways they can be solved. The challenge is that expert programmers often know a particularly concise, clever way, but that often isn’t the way. “obvious” This can lead to a trap where you see a clever solution that employs tricky syntax, think that there was way you would have guessed that solution, and believe you couldn’t have solved it on your own. That’s usually not true, yet it’s an unfortunate side effect of looking up solutions before trying to find your own. no Summary of Advice This has been a long post, so let me reiterate the last points before I go: Learning to code is much easier than most non-coders think, at least to make simple stuff. The main reason it seems hard is that: Setting up is frustrating. There are too many options to start. Early classes are populated with self-taught whiz-kids who make you feel dumb. To teach yourself, you should: Decide what kind of thing you want to make (website, app, game, script, etc.) first, pick the language that fits best with what you want to make. Start immediately with a concrete project to build something small. Books, courses and tutorials should help you get to that point. Learn computer science classes only after making some things on your own. When you get stuck, do what everyone else does and ask Google But don’t copy-and-paste the answers. And try to solve it for yourself first. If you can get through the initial frustration and build a little confidence, anyone can learn to code. Also, it’s a skill you can use throughout your life, even if you never become a full-time programmer.

Learning to Code: Is It Really That Difficult?

My journey is a bit interesting because I went directly from “Hello Mom” to “Hello World”! Let me start with my career timeline- 2012 — Graduated in Electronics. Started prepping for MBA. 2012 — Graduated in Electronics. Started prepping for MBA. 2015 — Joined as a Research Analyst. This one was a dream run. Thridbridge 2017 — Joined as a Senior Analyst. The Smart Cube 2019—Birth of my daughter. (Also read as 6-month career/maternity break) Why did I switch my career and get into tech? The day I held my daughter, the thought of leaving her for work made me introspect my career choices. I started panicking because I realized that if I want to join back the workforce I would have to spend a majority of my time away from her. That’s when I decided that if I have to spend time away from this cute little bundle of joy, then I am only going to work on something I am truly passionate about. No compromises. Can any happiness top this warmth? I joined back my company and was happy with my job but deep in my heart, I knew something was missing. I couldn’t justify the ROI, the growth opportunities, and the much-needed flexibility I wanted in the long run. This is when the tinkering began. I started listing down my interests. Did a few online courses in ‘Excel in MS-Excel’ to supply chain management to product management. This gave me some taste of other related fields. But couldn’t find the right career option. Luckily for me, my father-in-law who is a doctor wanted to develop a website for his clinic. Since I was trying out new things, I decided to help him develop a basic website. I played around with HTML/CSS and boom it was up and running in 2 days. That was my aha! moment. That’s when I realized the impact technology could create. Phase 1: The Decision 🙇‍♀️ To test the waters, I started using the SoloLearn app which has a brilliantly gamified learning experience alongside my full-time job. I did courses in HTML, CSS, Javascript, and SQL. I generally did this for 1 hour after my daughter had slept. After 3 months of trying to read code, I felt that it was time for some serious effort towards actually learning how to code. Little did I know, that I was embarking on one of the toughest professional journeys of my life! The 3 main things that excited me about the technology sector were — — I wanted to build a high-flying career with the flexibility to work from anywhere. This was a non-negotiable for me. Most software engineers today have remote working as an option. And the pandemic has only accelerated the trend. Flexibility — I wanted to be creatively challenged at work and build on ideas that would create a high impact. The tech industry not only gives you an option to create high impact but also helps in doing so in the shortest time. Impact — Because the demand-supply is so skewed in tech, there are very few good software engineers in the country and hence the salary in this sector is quite high comparatively. Money Phase 2: The Leap 🙆‍♀️ Anyone I asked for advice was against me quitting the stable job to explore completely uncharted territory and that too with a child. But eventually, I quit my full-time job. My office desk! Well, yes... I am a minion fan!! During my notice period, I researched a bit on the path I would take, coding boot camp vs self-taught developer route. I decided to teach myself coding without opting for a Bootcamp because: I had enough savings to last me for at least 2 years. I knew I could spend time building a strong foundation by myself. I couldn't justify the high-fees for Bootcamps, although they provide a faster learning experience. I felt with a kid, the Bootcamp experience might be overwhelming for me. P.S. — My mentor/cheerleader during this phase was my husband (Mayur Mundada) who pushed me to find my passion. Phase 3: The Uphill Battle 🤦‍♀️ Let's begin the real coding journey! Also read as, “Why the hell, did you make your life difficult?!” Although some basic ground was covered with SoloLearn but to start hands-on coding I needed to make sure the task wasn't too daunting. The first choice I made was the programming language/framework to learn. So here is my list with my reasoning: Python (Flask/Django Framework) — The language is very simple to understand for beginners and it has good frameworks to support the web development process. Javascript (React.js, Node.js) — Javascript is one of the most in-demand languages of 2021. It's great to know if you don't want to limit your job opportunities. HTML/CSS — Not a requirement but if you aim to become a full-stack developer then it's a must-have in your armor. For the next 4 months, I worked almost 8 hours every day (including weekends). Here is the list of courses I did: f (Cost: Free) reeCodeCamp Responsive Web Design (Cost: Free) freeCodeCamp Javascript Algorithms and Data Structures Certification (Zero to Mastery by Andrei Neagoie) (Cost: Rs. 430) Udemy The Complete Web-Developer (By Jose Portilla)(Cost: Rs. 430) Udemy Complete Python (By Jose Portilla)(Cost: Rs: 430) Udemy Python and Django Full Stack Web Developer While learning to code, I actually had a lot of fun. Every day I felt like I was opening a Pandora’s Box! Here’s the funny bit — as I learned more I started realizing how much I don’t know vs how much I had already covered. In hindsight, this is true for anything you learn in life. Not just coding. So, if you are like me, who has never thought of learning to code, there is a 9 out of 10 chance you will have nightmares. At least, I did. There’s only 1 mantra I followed —  "one step at a time". Photo by Brett Jordan on Unsplash P.S.— My mentor/personal silly doubts solver during this phase was my best friend and Software Engineer@Gracenote (Bhupinder Gulati). Phase 4: The Implementation👩‍💻 The following 2 months, I did some full-stack projects to get a better understanding of everything I had learned so far and also created my portfolio: This was a React.js + Node.js project which I did as a part of the Zero to Mastery course. Facial Recognition Website: This was a Flask(Python) based project that was tracking the global and local daily covid cases. I used BeautifulSoup for web-scraping and the GoogleNews API for news. Covid-19 Cases Tracker: This was a Flask(Python) based project that enabled users to pick a specific YouTube category and discover unexplored videos. Did this using YouTube API. Shuffle: This was a simple Django-based blogging website for personal use. The main aim behind the project was to get an understanding of how to deploy projects using Django. Blog: Space Invader Game: It was a simple gaming application that was built using Pygame. Lastly, I developed my own to showcase my journey. This was fun. Tried getting a wee-bit creative. 😉 personal website P.S. — I just turned 30 and I am finally getting ready to apply for my 1st coding job! Phase 5: Getting out there!🦸‍♀️ After gaining some confidence in my coding skills, I knew I had to get some industry experience. I spent a few days perfecting my resume (days, you read it right!). Then began the dreadful task of applying to 100s of companies and explaining to them how I had 4.5 years of experience in total and an MBA and still wanted to become a software developer. After many rejections during the phone interviews, I had my 2nd round of interviews with a startup based out of the US . It was the worst interview of my life. But with some luck, the company gave me an opportunity to work with them as a paid intern for 6 months. I was ready to gain any experience I could at the time so I jumped at the opportunity! Phase 6: The Software Development Intern From day 1 of the internship, I had imposter syndrome. Although I had learned to program, I was scared of breaking the code or even asking doubts which according to me were silly. My first project was a full-stack project which I was handling alone (perks of working for a startup), the frontend was using React.js and the backend was using Flask framework. With extensive help from google and a few very helpful colleagues, I was able to pull it off including the deployment of the project in 2 months. I couldn't have been more proud of myself. I spent close to 6 months leveraging the basic skill I had learned, “no matter what, don't give up”. Phase 7: The Extensive Interview Prep 💆‍♀️ So after spending 5 months with the company, it was time to chase the final step of breaking the tech stereotype profile. Although I did have an offer to convert my internship to a full-time role, I wanted to focus on working in a bigger setup with more peer learning opportunities. So here I was gearing up to prepare for my software developer interviews. But little did I know — Software Developer Interviews = 45% of Data Structures & Algorithms + 45% OOPs & System Design Concepts + 10% project work I spent close to 3 months along with the internship and 2 months after, doing and redoing Leetcode questions and understanding the basic fundamentals of data structures and object-oriented programming. For interview prep, covering the basics and some advanced concepts of the below topics is important, the number of questions you attempt doesn't matter if the foundation is rock solid. Arrays, Strings and Pointers Linked Lists Heaps Trees Stack & Queues Dynamic Programming Backtracking Graphs Trie I formed a of all the questions I did, it contains all the solutions in the simplest way possible. GitHub repo The other things I worked through were: Class-based Designs System Design Patterns OOPs Concepts Definitions of some of the important terminologies and concepts related to Javascript, Python, and Databases P.S — I heavily leaned on my mentors i.e. Oshin Mundada (sis-in-law/Software Engineer@Microsoft) and Piyush Nahar (brother-in-law/Software Engineer@Facebook) during this phase and bothered them with “WHY Leetcode” incessantly. Phase 8: The Final Exam (Interviews) 👩‍🏫 I knew the application process was going to be long and grueling but since this was literally the last leg of my journey, I pushed through. The pandemic made this step a little bit tough but the silver lining was that since everyone was working from home, I did not have any location constraints. The interview template for most of the companies is the same: 1 Coding Task/Online Coding Test 2/3 Technical Rounds — Based on DS/Algo, System Design and your projects 1 HR Round I applied to some 50 odd companies, gave online tests/tasks for 20 of them, I went through the interview rounds of 10 of them. P.S. —  I also had some really embarrassing DS/Algo rounds which retrospectively is pretty normal but you just have to push through it. Phase 9: The Joy! 🤸🏻‍♀️ I was finally able to bag a Backend Engineer role with an amazing social media startup backed by Anand Mahindra — . GoSocial My wish was granted by the universe here, because: I love the problem they are trying to solve. It focuses on the creator economy by helping creators turn their passion into a business. I have seen this first-hand because my sister has been trying to follow her passion for painting and create a business opportunity for the past year. Since the time I began coding, I have always been inclined more towards backend engineering and I will be able to focus on that now. The startup is remote-friendly which means I will be able to follow my passion achieving the work-life balance I have been aiming for. If there was anything I realized in the whole process, it was: Software development is more of a mindset than just developing a set of rules to guide the machine. It has to do with how you formulate a problem, work towards the solution, keep trying to get a favorable result, and then do your best to optimize the approach! I felt this was very logical and actually can be applied to life in general as well. Cheers to dreaming, failing, achieving. Repeat. 🙌

How I Became a Developer in 7 months After 5 Years of Unrelated Experience

Acquiring a new skill is good but knowing exactly which path to take in advance is best. For every decision taking to learn something new, there is always this “where” or “what” question. Where will I start, what should I do, where will I get material, what so ever be the case there is always a “where” or “what” question. Knowing exactly which path to take as a newbie in technology is almost impossible unless you follow a strict guide from a mentor or any other source. This article is more like a guide through the walk of a self-taught web developer. Some years ago when I started learning python, I asked a friend about a road map to becoming a programmer and what he did was to send me a copy of his computer science curriculum. I wasn’t asking to go back to school, all I needed was a guide on how to become a self-taught developer and not a computer science curriculum. So I decided to come up with something like this to help those who are presently in the same situation that I was. In this article I will be sharing the stages I went through to become a Ruby full-stack developer. Who is this article for? Everybody is not capable of paying for programming classes nor boot camps where they could have the privilege of interacting one-on-one with a mentor or teacher but there is a lot of free information out there that can get you started which is the purpose of this article. I learned programming without spending a dine on online resources, I kept my money for my internet bills. How do you become a self-taught developer? Choose a Programming Language The very first thing you need to address as a newbie is to choose a programming language to focus your energy on. There are a lot of programming languages out there but there is a specific one for you which you need to identify based on the following criteria; Availability of resources: You will not want to choose a programming language that has limited material online. To avoid being stuck all the time, choose a language that has good documentation and a vast spectrum of resources out there. If you have someone who guides you, it will be preferable to start with the language that he does to ensure that you have someone you can turn to whenever you get stuck. Easy learning scope: For people without a programming background, this point should highly be considered. As a biology student who loved programming, I started learning Java and with all my motivation I gave up on programming due to the complexity of the language. Later on, I fell on a Youtube video that listed programming languages based on complexity and salary, Python was the first on the list so I decided to start learning python which I realized was very easy to understand and my motivation was increased. I will recommend languages such as Python, P.H.P, and Ruby for those who are still wondering what programming language to choose. Join an Online Community Creating an online community is a normal exercise that every programming group practices in order to share maximum information about their technology and to help people who get stuck at some point. Every programming language has a community so choose a focused learning community based on your programming language and start contributing as little as you can by asking questions and answering those that you know. When I started programming in Ruby, I studied on a free platform called . It has a very good curriculum on learning full-stack development as a Ruby on Rails developer and a community made up of professionals and learners who are ready to help you whenever you get stuck. Odin Project Presently I am a member of a Ruby group on Facebook and on Linkedin and it is amazing when a good number of people give you feedback on something that you are working on. If you have not yet joint any group, do a Facebook search on the groups that utilize the programming language that interests you, join the group and start participating. Learning Tools There are excellent courses on UDEMY and I wish I had the money to purchase some for myself. For those who have financial limitations as I did, there are many other options out there that we will be discussing here. For visual learners, there is the popular Youtube. There are a lot of videos on Youtube and you should be careful about choosing the course you wish to take. Choose video courses based on the number of views, likes, subscribers and most importantly the publishing date. I will advise you to, first of all, take complete courses before getting into videos explaining specific concepts, this will help to keep you on track so you don't get lost all the time. For learners who love reading, we have platforms like F , , , , etc. I strongly recommend Freecodecamp. They teach by example and also have an online text editor where you can solve exercises and a place where to check for solutions if you are unable to solve an exercise. For Ruby Programmers, I will strongly recommend the Odin project. reecodecamp Codecademy Odin project W3schools After learning data structures, it’s a good habit to practice solving algorithmic challenges. Up till today, I practice algorithms 2 hours a day just to keep my brain active. Remember that your primary duty as a developer is to solve problems and a good practice for your problem-solving skills is to work on algorithmic exercises. Suggested platforms for this exercise include , , and . Hackerrank Leetcode Repl Project-based Learning As a self-taught developer, one of the ways you can evaluate yourself is by working on projects. This is one of the reasons why the Odin project is a unique platform. It provides you with projects that will help you test your understanding of the concepts you learn. I remember the first time I completed a JavaScript course, I was so happy and excited but when I decided to take a project, I realized I did not understand most of the concepts. Before telling people that you know a particular programming language, make sure to have done at least 5 projects using the language if not you will embarrass yourself. Before telling people that you know a particular programming language, make sure to have done at least 5 projects using the language if not you will embarrass yourself. What to do when you get stuck? Don’t be afraid of getting stuck because you can’t escape from it. Even professional programmers get stuck at some point proven that nobody is the master of knowledge. In this last section of the article, we are going to talk about what to do when you get stuck. Asking questions is so important to a developer that I completed a whole project on that. I will limit the scope of this section to revealing some important sites where you can ask questions in case your respective forums are unable to help you but do make sure to read articles on how to properly ask questions, there are even some Youtube videos on that. Before asking a question to a friend or to any forum, make sure that you were unable to find the answer on google. As a programmer, your best friend is Google. Always make sure to google search any difficulty that you have because you can’t be the first person experiencing it. As a programmer, your best friend is Google. I was building an e-commerce app and I got stuck when trying to implement the payment method using a third party API called Monetbil. Nobody knew about Monetbil in my Forum since it is a Cameroonian payment method. The only option left was the support team. I wrote to them and I was surprised to see how fast they responded after I had wasted time searching for solutions in other places. Always contact the support team of a resource you want to consume whenever you get stuck. Always contact the support team of a resource you want to consume whenever you get stuck. There is an important platform for asking questions that you need to know about. It is called . StackOverflow allows you to ask questions and to answer other people's questions with the best answers being upvoted. Most of the questions I google search when I get stuck have answers on StackOverflow since other programmers faced the same difficulty and went ahead and asked. StackOverflow I know it was a very long article and I hope it worth your time. Feel free to contact me If you need any further information that I failed to provide in this article and I am also open to counseling newbies who want to have their way through the tech world but are afraid of a lot of unknowns. God bless you.

The Path of a Self-Taught Developer

How I Created a Social Recommendation Network in Brazil

The world is a much more connected place than it was 20 years ago. With the change came new expectations. Downtimes can cripple businesses. There is an expectation of privacy and security. If we post on Facebook and the post gets lost due to any kind of issue, people will not tolerate it. Data integrity and durability are more critical than ever. As an organization, we must consider multiple technological tenets—security, availability, latency, durability, integrity, reliability, and privacy. We don’t get to choose from this list; we just sort it by importance based on business needs. Business continuity Disaster can come in many flavors, ranging from natural disasters to hardware failures, misconfiguration, and cyberattacks. The problem with cyberattacks is that we risk having our data stolen and wonder if the rest of the data is trustworthy. Maybe the attack was a sleight of hand, and the primary objective was to introduce malicious data that would haunt the organization forever. After the security incident, we need to recover the data and restore the service to the level our customers expect. One of the issues we face is reconstructing the original picture and configuration. We need to understand how all the pieces work together and their interdependency. Data restoration is more than just restoring a highly scalable web service snapshot. Objective At this point, our primary objective should be to ensure that our services are available and reliable by whatever means necessary. In the context of dependency management, we need to have a comprehensive data and dependency catalog, including the relationships between the entities. This provides us with the necessary insight into what exists. We also need regular operations testing and robust disaster recovery through automation and manual runbooks. We need to cultivate a culture of disaster recovery fire drills and identify fallbacks. Maturity Model Like an individual who enters college goes through freshman, sophomore, junior, and senior years before graduating, businesses need to follow a slow, progressive approach. It’s impractical for a company or organization to go from no disaster recovery to a fully-fledged, perfectly fleshed-out plan. The road to success is incremental, and each step builds on the previous step. Maturity models examine an organization’s current state from any specific perspective, such as disaster recovery, and help the organization reach the desired state or capability. As the organization progresses toward the end goal, it goes through various checkpoints, usually called Levels. Most Maturity Models have four levels, starting from Level 1 up to Level 4. Why are we talking about maturity models? One step in such a disaster recovery maturity model requires that the organization understand dependencies among various entities and data objects. Recovery usually requires restoring the data and bringing back critical systems in a specific incremental manner, Implementation Based on the business needs, understanding dependency and its relationship can be somewhere in the middle levels of the maturity models. In a 4-level system, it is most likely in Level 2 or Level 3. The other approach is to split the Dependency Management into the same number of milestones as the number of levels. Suppose we are using a 4-level maturity model. In that case, we can split up dependency management to span all 4 Levels, starting with the most straightforward steps and going all the way to the most complicated, expensive, and involved steps. Going forward, we will only discuss the dependency management aspect of this maturity model. Level 1 - Discovering and Understanding Dependencies For many organizations, this can be the most daunting task. If dependency management was never considered necessary, there might be no institutional knowledge. We will start by discussing technical dependencies and then discuss process dependencies. Regarding technical dependencies, we need to identify the direct dependencies first. If the code is written in JavaScript and runs on a cloud service, then the direct dependencies might be JavaScript, NodeJS, AWS Lambda, etc. If we use npm for package management, the packages listed in the dependency file are direct dependencies. Next, we have transitive dependencies, which are pulled automatically from direct dependencies. In practice, this forms a directed acyclic graph. Another aspect of technical dependencies is the cloud architecture. Let’s take an example of AWS—we might use EC2, S3, API Gateway, CloudFront, ELB, etc. If the cloud resources were deployed using tools like CloudFormation or CDK, then it would be trivial to determine the dependencies. If the resources were created manually, the dependency diagram must be made manually by reading the source code and drawing conclusions. Process dependency falls under the non-technical category and defines how different stakeholders work together to move forward. It can also outline the release process or runbooks to invoke during an incident. Level 2 - Setup Continuous Dependencies Validation Dependencies can change since there are too many cooks in the kitchen. The organization's continuous integration tool should enumerate and track the direct code and library dependencies. Every time the code is pushed, a snapshot of current pinned dependencies should be saved to recreate the specific circumstances or restore to a known good state. Like the Continuous integration concept, the non-technical aspects should have some automation. Alerts should be created on metric, and using tools like PagerDuty, appropriate people should be notified of issues, and proper escalation channels should be created. It should be tested occasionally to avoid the known problem called Dogs Not Barking - a situation when you wonder if you are not getting any alerts because nothing is wrong or the alerting logic is broken. Some dependencies can be validated by using the Scream test. Under proper notification and preparation, turn off specific dependencies and see what fails. You may find a Load Bearing Mac Mini. Collect all of this configuration and manage it through some kind of provisioning tool like Chef and Terraform Level 3 - Fixing dependencies by adding, updating, or removing Once we have all the dependencies figured out, take some time and pat yourself on the back. Now, back on the issue, the work isn’t done. During the quest, you realize that some dependencies are causing more problems than they solve. One approach would be to update the dependencies. For example, if we are using old versions of OpenSSL, updating them to newer versions can solve many of the warnings raised by the build system and even help us pass any security compliance. Sometimes, the specific versions of two separate packages are incompatible. The solution is to find versions that can work together. This involves changing the version and might involve downgrading one or more packages. Sometimes, just removing a package or dependency solves the problem. It could have been a dead dependency with no further need but causing warnings and spamming the application logs. Under some circumstances, we might have to add a dependency to bring harmony. Suppose a transitive dependency is causing the problem, but we cannot update the direct dependency. In that case, explicitly adding the fixed version of the transitive dependency as a direct dependency can be an acceptable solution. Level 4 - Manual and Automated Disaster Recovery Drills This is the highest form of maturity in disaster recovery. We need runbooks that outline the roles and responsibilities of individuals involved. The runbook should also define the interdependencies and criticality of each step. The disaster recovery process should be practiced regularly by simulating a disaster and identifying possible sources of friction that get introduced when the plan is set in motion. The gold standard should be automated disaster recovery under human supervision. Automating the disaster recovery workflow ensures that humans do not make mistakes that go unnoticed. Automating has an additional advantage in that we can now run stress tests and simulation disasters by turning off certain network parts in a controlled manner to validate whether our automated disaster recovery is performing as expected. Conclusion Dependency management plays a critical role in disaster recovery, which is essential after a security incident. By following a structured and methodological approach, organizations can build their understanding progressively and control the dependencies. Each maturity model level builds on the previous one and strengthens the organization's security posture. While it can be easy to write off dependency management as a superfluous technical exercise, it is primarily about creating a comprehensive framework that brings together computer systems, people, and processes to work harmoniously. The systematic approach ensures that when disaster strikes, even in the form of a security breach, we can safely recover the data and be confident in the integrity of the said data. The world is a much more connected place than it was 20 years ago. With the change came new expectations. Downtimes can cripple businesses. There is an expectation of privacy and security. If we post on Facebook and the post gets lost due to any kind of issue, people will not tolerate it. Data integrity and durability are more critical than ever. As an organization, we must consider multiple technological tenets—security, availability, latency, durability, integrity, reliability, and privacy. We don’t get to choose from this list; we just sort it by importance based on business needs. Business continuity Disaster can come in many flavors, ranging from natural disasters to hardware failures, misconfiguration, and cyberattacks. The problem with cyberattacks is that we risk having our data stolen and wonder if the rest of the data is trustworthy. Maybe the attack was a sleight of hand, and the primary objective was to introduce malicious data that would haunt the organization forever. After the security incident, we need to recover the data and restore the service to the level our customers expect. One of the issues we face is reconstructing the original picture and configuration. We need to understand how all the pieces work together and their interdependency. Data restoration is more than just restoring a highly scalable web service snapshot. Objective At this point, our primary objective should be to ensure that our services are available and reliable by whatever means necessary. In the context of dependency management, we need to have a comprehensive data and dependency catalog, including the relationships between the entities. This provides us with the necessary insight into what exists. We also need regular operations testing and robust disaster recovery through automation and manual runbooks. We need to cultivate a culture of disaster recovery fire drills and identify fallbacks. Maturity Model Like an individual who enters college goes through freshman, sophomore, junior, and senior years before graduating, businesses need to follow a slow, progressive approach. It’s impractical for a company or organization to go from no disaster recovery to a fully-fledged, perfectly fleshed-out plan. The road to success is incremental, and each step builds on the previous step. Maturity models examine an organization’s current state from any specific perspective, such as disaster recovery, and help the organization reach the desired state or capability. As the organization progresses toward the end goal, it goes through various checkpoints, usually called Levels. Most Maturity Models have four levels, starting from Level 1 up to Level 4. Why are we talking about maturity models? One step in such a disaster recovery maturity model requires that the organization understand dependencies among various entities and data objects. Recovery usually requires restoring the data and bringing back critical systems in a specific incremental manner, Implementation Based on the business needs, understanding dependency and its relationship can be somewhere in the middle levels of the maturity models. In a 4-level system, it is most likely in Level 2 or Level 3. The other approach is to split the Dependency Management into the same number of milestones as the number of levels. Suppose we are using a 4-level maturity model. In that case, we can split up dependency management to span all 4 Levels, starting with the most straightforward steps and going all the way to the most complicated, expensive, and involved steps. Going forward, we will only discuss the dependency management aspect of this maturity model. Level 1 - Discovering and Understanding Dependencies For many organizations, this can be the most daunting task. If dependency management was never considered necessary, there might be no institutional knowledge. We will start by discussing technical dependencies and then discuss process dependencies. Regarding technical dependencies, we need to identify the direct dependencies first. If the code is written in JavaScript and runs on a cloud service, then the direct dependencies might be JavaScript, NodeJS, AWS Lambda, etc. If we use npm for package management, the packages listed in the dependency file are direct dependencies. Next, we have transitive dependencies, which are pulled automatically from direct dependencies. In practice, this forms a directed acyclic graph. Another aspect of technical dependencies is the cloud architecture. Let’s take an example of AWS—we might use EC2, S3, API Gateway, CloudFront, ELB, etc. If the cloud resources were deployed using tools like CloudFormation or CDK, then it would be trivial to determine the dependencies. If the resources were created manually, the dependency diagram must be made manually by reading the source code and drawing conclusions. Process dependency falls under the non-technical category and defines how different stakeholders work together to move forward. It can also outline the release process or runbooks to invoke during an incident. Level 2 - Setup Continuous Dependencies Validation Dependencies can change since there are too many cooks in the kitchen. The organization's continuous integration tool should enumerate and track the direct code and library dependencies. Every time the code is pushed, a snapshot of current pinned dependencies should be saved to recreate the specific circumstances or restore to a known good state. Like the Continuous integration concept, the non-technical aspects should have some automation. Alerts should be created on metric, and using tools like PagerDuty, appropriate people should be notified of issues, and proper escalation channels should be created. It should be tested occasionally to avoid the known problem called Dogs Not Barking - a situation when you wonder if you are not getting any alerts because nothing is wrong or the alerting logic is broken. Some dependencies can be validated by using the Scream test . Under proper notification and preparation, turn off specific dependencies and see what fails. You may find a Load Bearing Mac Mini . Collect all of this configuration and manage it through some kind of provisioning tool like Chef and Terraform Scream test Scream test Load Bearing Mac Mini Load Bearing Mac Mini Level 3 - Fixing dependencies by adding, updating, or removing Once we have all the dependencies figured out, take some time and pat yourself on the back. Now, back on the issue, the work isn’t done. During the quest, you realize that some dependencies are causing more problems than they solve. One approach would be to update the dependencies. For example, if we are using old versions of OpenSSL, updating them to newer versions can solve many of the warnings raised by the build system and even help us pass any security compliance. Sometimes, the specific versions of two separate packages are incompatible. The solution is to find versions that can work together. This involves changing the version and might involve downgrading one or more packages. Sometimes, just removing a package or dependency solves the problem. It could have been a dead dependency with no further need but causing warnings and spamming the application logs. Under some circumstances, we might have to add a dependency to bring harmony. Suppose a transitive dependency is causing the problem, but we cannot update the direct dependency. In that case, explicitly adding the fixed version of the transitive dependency as a direct dependency can be an acceptable solution. Level 4 - Manual and Automated Disaster Recovery Drills This is the highest form of maturity in disaster recovery. We need runbooks that outline the roles and responsibilities of individuals involved. The runbook should also define the interdependencies and criticality of each step. The disaster recovery process should be practiced regularly by simulating a disaster and identifying possible sources of friction that get introduced when the plan is set in motion. The gold standard should be automated disaster recovery under human supervision. Automating the disaster recovery workflow ensures that humans do not make mistakes that go unnoticed. Automating has an additional advantage in that we can now run stress tests and simulation disasters by turning off certain network parts in a controlled manner to validate whether our automated disaster recovery is performing as expected. Conclusion Dependency management plays a critical role in disaster recovery, which is essential after a security incident. By following a structured and methodological approach, organizations can build their understanding progressively and control the dependencies. Each maturity model level builds on the previous one and strengthens the organization's security posture. While it can be easy to write off dependency management as a superfluous technical exercise, it is primarily about creating a comprehensive framework that brings together computer systems, people, and processes to work harmoniously. The systematic approach ensures that when disaster strikes, even in the form of a security breach, we can safely recover the data and be confident in the integrity of the said data.

Dependency Management is Critical for Disaster Recovery After a Security Incident

Search engines dominate information retrieval, but iAsk AI is redefining what’s possible. In a groundbreaking achievement on the GPQA Diamond benchmark, iAsk AI’s advanced model, iAsk Pro, has set new records in accuracy for complex, graduate-level scientific problem-solving. This isn’t just a technical milestone — it’s a reimagining of how AI can understand, process, and answer challenging questions with human-like depth and precision. What is the GPQA Benchmark? GPQA (Graduate-Level Google-Proof Q&A Benchmark) is one of the most rigorous tests for AI models, designed to challenge them in fields like biology, physics, and chemistry. These are not typical questions; they demand knowledge and nuanced, multi-step reasoning that can stump even PhD-level experts. Remarkably, iAsk Pro achieved a record-breaking 78.28% accuracy on the GPQA Diamond subset — comprising the benchmark’s most challenging 198 questions — outperforming leading models like OpenAI’s GPT and Anthropic’s Claude 3.5. This accomplishment sets a new standard in AI’s capacity to tackle the toughest, most intricate queries. Unlike general benchmarks, GPQA focuses on “Google-proof” questions that resist simple answers. These questions require advanced reasoning, the kind that rivals human experts. The complexity is so high that even specialized professionals typically average around 65% accuracy. iAsk Pro’s breakthrough accuracy reflects its unique ability to mirror the depth of human cognitive processing, setting it apart in the AI landscape. How iAsk AI Achieves Unmatched Accuracy Unlike standard search engines that rely heavily on keyword matching, iAsk Pro’s approach goes far deeper. It uses Chain of Thought (CoT) reasoning to deconstruct intricate, multi-layered questions step by step. This method mirrors human logic, enabling iAsk Pro to deliver responses that are both highly accurate and contextually relevant. Users receive well-rounded, clear answers instead of vague references, underscoring iAsk Pro’s dedication to precision. Unlike standard search engines that rely heavily on keyword matching, iAsk Pro’s approach goes far deeper. It uses Chain of Thought (CoT) reasoning to deconstruct intricate, multi-layered questions step by step. This method mirrors human logic, enabling iAsk Pro to deliver responses that are both highly accurate and contextually relevant. Users receive well-rounded, clear answers instead of vague references, underscoring iAsk Pro’s dedication to precision. The GPQA benchmark was specifically designed to test AI models beyond surface-level knowledge, demanding advanced reasoning. iAsk’s choice to focus on this challenging benchmark was strategic, showcasing its capabilities in fields like academia, research, and other data-driven domains. With its high GPQA accuracy, iAsk Pro is poised to drive breakthroughs in areas that require deep scientific insight, establishing itself as an invaluable resource in advanced knowledge fields. The Future of AI-Driven Knowledge with iAsk Pro For professionals, academics, and anyone who values precision, iAsk Pro heralds a new era of AI-powered inquiry. Its record-breaking performance points toward a future where technology not only aids information retrieval but actively advances collective understanding. From supporting scientific discoveries to offering users a reliable source of accurate knowledge, iAsk AI is reshaping the role of search technology in our lives. iAsk Pro’s success represents a step toward AI that can work alongside individuals as a problem-solver, capable of addressing the depth and complexity of human inquiry. This article is published under HackerNoon’s Business Blogging program. Learn more about the program here. Search engines dominate information retrieval, but iAsk AI is redefining what’s possible. In a groundbreaking achievement on the GPQA Diamond benchmark, iAsk AI’s advanced model, iAsk Pro, has set new records in accuracy for complex, graduate-level scientific problem-solving. This isn’t just a technical milestone — it’s a reimagining of how AI can understand, process, and answer challenging questions with human-like depth and precision. What is the GPQA Benchmark? What is the GPQA Benchmark? GPQA (Graduate-Level Google-Proof Q&A Benchmark) is one of the most rigorous tests for AI models, designed to challenge them in fields like biology, physics, and chemistry. These are not typical questions; they demand knowledge and nuanced, multi-step reasoning that can stump even PhD-level experts. Remarkably, iAsk Pro achieved a record-breaking 78.28% accuracy on the GPQA Diamond subset — comprising the benchmark’s most challenging 198 questions — outperforming leading models like OpenAI’s GPT and Anthropic’s Claude 3.5. This accomplishment sets a new standard in AI’s capacity to tackle the toughest, most intricate queries. iAsk Pro iAsk Pro Unlike general benchmarks, GPQA focuses on “Google-proof” questions that resist simple answers. These questions require advanced reasoning, the kind that rivals human experts. The complexity is so high that even specialized professionals typically average around 65% accuracy. iAsk Pro’s breakthrough accuracy reflects its unique ability to mirror the depth of human cognitive processing, setting it apart in the AI landscape. How iAsk AI Achieves Unmatched Accuracy How iAsk AI Achieves Unmatched Accuracy Unlike standard search engines that rely heavily on keyword matching, iAsk Pro’s approach goes far deeper. It uses Chain of Thought (CoT) reasoning to deconstruct intricate, multi-layered questions step by step. This method mirrors human logic, enabling iAsk Pro to deliver responses that are both highly accurate and contextually relevant. Users receive well-rounded, clear answers instead of vague references, underscoring iAsk Pro’s dedication to precision. Unlike standard search engines that rely heavily on keyword matching, iAsk Pro’s approach goes far deeper. It uses Chain of Thought (CoT) reasoning to deconstruct intricate, multi-layered questions step by step. This method mirrors human logic, enabling iAsk Pro to deliver responses that are both highly accurate and contextually relevant. Users receive well-rounded, clear answers instead of vague references, underscoring iAsk Pro’s dedication to precision. The GPQA benchmark was specifically designed to test AI models beyond surface-level knowledge, demanding advanced reasoning. iAsk’s choice to focus on this challenging benchmark was strategic, showcasing its capabilities in fields like academia, research, and other data-driven domains. With its high GPQA accuracy, iAsk Pro is poised to drive breakthroughs in areas that require deep scientific insight, establishing itself as an invaluable resource in advanced knowledge fields. The Future of AI-Driven Knowledge with iAsk Pro The Future of AI-Driven Knowledge with iAsk Pro For professionals, academics, and anyone who values precision, iAsk Pro heralds a new era of AI-powered inquiry. Its record-breaking performance points toward a future where technology not only aids information retrieval but actively advances collective understanding. From supporting scientific discoveries to offering users a reliable source of accurate knowledge, iAsk AI is reshaping the role of search technology in our lives. iAsk Pro’s success represents a step toward AI that can work alongside individuals as a problem-solver, capable of addressing the depth and complexity of human inquiry. This article is published under HackerNoon’s Business Blogging program. Learn more about the program here. This article is published under HackerNoon’s Business Blogging program. Learn more about the program here . here

iAsk AI Breaks Accuracy Records on AI’s Most Challenging Benchmark

iAsk KI breek akkuraatheidsrekords op KI se mees uitdagende maatstaf

iAsk AI ukax AI ukan juk’amp ch’amäki uka Benchmark ukanx Registros de Exactitud ukar p’akinti

iAsk AI bat rècords de precisió en el punt de referència més desafiant de l'IA

iAsk AI rompe récords de precisión en el parámetro de referencia más desafiante de la IA

iAsk AI kraze dosye presizyon sou referans ki pi difisil AI a

Az iAsk AI pontossági rekordokat döntött meg az AI legnagyobb kihívást jelentő referenciaértékén

iAsk AI、AIの最も難しいベンチマークで精度記録を更新

iAsk AI bije rekordy dokładności w najtrudniejszym teście porównawczym AI

iAsk AI thyen rekorde të saktësisë në pikën më sfiduese të AI

иАск АИ обара рекорде тачности на најизазовнијем мерилу АИ

iAsk AI AI-iň iň kyn görkezijisinde takyklyk ýazgylaryny döwýär

iAsk AI AIning eng qiyin mezonida aniqlik rekordlarini yangiladi

HONG KONG, Singapore, London, and Dubai, Global, October 22nd, 2024/Chainwire/--Scroll, the leading zero-knowledge rollup for Ethereum, announced the launch of its native token, $SCR today. With the introduction of $SCR, Scroll recognizes its global community of contributors for their ongoing support and aims to provide everyone, everywhere with opportunities to participate in the decentralized future of Scroll. $SCR will be distributed to Scroll contributors through thoughtfully designed allocations to maximize impact in creating opportunities for a decentralized global community. Initial distribution of $SCR will include an airdrop to participants who contributed to onchain activities, projects that have built on Scroll, industry contributors (such as technical contributors, zero-knowledge researchers, open-source developers, public goods organizations, and educational data providers) as well as broader global community organizers, hackathon winners, Road to DevCon and Ethereum translators. The design of this first airdrop recognizes the importance of Scroll contributors’ participation, involvement, and community support. In addition, Scroll will be introducing the next generation of reward programs, to generate new ways of fostering innovation and elevating support for the Scroll community. Scroll Open, a new program designed to reward the most innovative, creative, and fast-growing builders on Scroll will provide retro grants with a potential allocation size of US$100 million. Using advanced zero-knowledge technology, Scroll has the fastest finality among all rollups, making it a cornerstone of the platform’s security and interoperability. This innovation transforms finality from a mere technical milestone into a vital feature that will drive the resilience of the entire network, further enhancing the utility of $SCR within the ecosystem. “The launch of $SCR embodies the momentum of our protocol’s evolution,” said Raza Zaidi, Head of Growth for Scroll. “This token aims to help decentralize governance while enhancing our technical infrastructure. Our commitment to a fully decentralized ecosystem ensures that $SCR will play a critical role in driving the future growth and resilience of our platform.” “Scroll’s mission is to build a more scalable and secure decentralized world. The launch of $SCR is a significant milestone in realizing this vision, as it empowers our community with greater control and rewards their contributions,” said Sandy Peng, Co-Founder of Scroll. “By decentralizing governance and incentivizing participation, we are creating a robust and resilient ecosystem. This launch marks the beginning of a new chapter for Scroll, where our community drives innovation and growth.” About Scroll Scroll is the leading zero-knowledge rollup. Leveraging fast finality and high throughput, Scroll is creating a more accessible, and secure onchain future for everyone. Our mission is to provide an easy-to-use, developer-friendly environment to scale Ethereum for good. Scroll empowers builders to ascend beyond today’s limitations and drive real-world impact. For more information, users can visit scroll.io. Contact Head of Communications Ryan Dennis Scroll press@scroll.io This story was distributed as a release by Chainwire under HackerNoon’s Business Blogging Program. Learn more about the program here. HONG KONG, Singapore, London, and Dubai, Global, October 22nd, 2024/Chainwire/--Scroll, the leading zero-knowledge rollup for Ethereum, announced the launch of its native token, $SCR today. With the introduction of $SCR, Scroll recognizes its global community of contributors for their ongoing support and aims to provide everyone, everywhere with opportunities to participate in the decentralized future of Scroll. $SCR will be distributed to Scroll contributors through thoughtfully designed allocations to maximize impact in creating opportunities for a decentralized global community. HONG KONG, Singapore, London, and Dubai, Global, October 22nd, 2024/Chainwire/--Scroll, Initial distribution of $SCR will include an airdrop to participants who contributed to onchain activities, projects that have built on Scroll, industry contributors (such as technical contributors, zero-knowledge researchers, open-source developers, public goods organizations, and educational data providers) as well as broader global community organizers, hackathon winners, Road to DevCon and Ethereum translators. The design of this first airdrop recognizes the importance of Scroll contributors’ participation, involvement, and community support. In addition, Scroll will be introducing the next generation of reward programs, to generate new ways of fostering innovation and elevating support for the Scroll community. Scroll Open, a new program designed to reward the most innovative, creative, and fast-growing builders on Scroll will provide retro grants with a potential allocation size of US$100 million. Using advanced zero-knowledge technology, Scroll has the fastest finality among all rollups, making it a cornerstone of the platform’s security and interoperability. This innovation transforms finality from a mere technical milestone into a vital feature that will drive the resilience of the entire network, further enhancing the utility of $SCR within the ecosystem. “The launch of $SCR embodies the momentum of our protocol’s evolution,” said Raza Zaidi, Head of Growth for Scroll. “This token aims to help decentralize governance while enhancing our technical infrastructure. Our commitment to a fully decentralized ecosystem ensures that $SCR will play a critical role in driving the future growth and resilience of our platform.” “The launch of $SCR embodies the momentum of our protocol’s evolution,” said Raza Zaidi, Head of Growth for Scroll. “This token aims to help decentralize governance while enhancing our technical infrastructure. Our commitment to a fully decentralized ecosystem ensures that $SCR will play a critical role in driving the future growth and resilience of our platform.” “Scroll’s mission is to build a more scalable and secure decentralized world. The launch of $SCR is a significant milestone in realizing this vision, as it empowers our community with greater control and rewards their contributions,” said Sandy Peng, Co-Founder of Scroll. “By decentralizing governance and incentivizing participation, we are creating a robust and resilient ecosystem. This launch marks the beginning of a new chapter for Scroll, where our community drives innovation and growth.” “Scroll’s mission is to build a more scalable and secure decentralized world. The launch of $SCR is a significant milestone in realizing this vision, as it empowers our community with greater control and rewards their contributions,” said Sandy Peng, Co-Founder of Scroll. “By decentralizing governance and incentivizing participation, we are creating a robust and resilient ecosystem. This launch marks the beginning of a new chapter for Scroll, where our community drives innovation and growth.” About Scroll Scroll is the leading zero-knowledge rollup. Leveraging fast finality and high throughput, Scroll is creating a more accessible, and secure onchain future for everyone. Our mission is to provide an easy-to-use, developer-friendly environment to scale Ethereum for good. Scroll empowers builders to ascend beyond today’s limitations and drive real-world impact. For more information, users can visit scroll.io . Scroll Scroll scroll.io scroll.io Contact Head of Communications Ryan Dennis Scroll press@scroll.io This story was distributed as a release by Chainwire under HackerNoon’s Business Blogging Program. Learn more about the program here. This story was distributed as a release by Chainwire under HackerNoon’s Business Blogging Program. Learn more about the program here. here . here

Scroll Launches $SCR Token To Recognize Global Community Contribution And Decentralize Its Ecosystem

Scroll lanza el token $SCR para reconocer la contribución de la comunidad global y descentralizar su ecosistema

A Scroll elindítja a $SCR Tokent, hogy elismerje a globális közösség hozzájárulását és decentralizálja ökoszisztémáját

Scroll-ը գործարկում է $SCR Token՝ ճանաչելու Համայնքի համաշխարհային ներդրումը և ապակենտրոնացնելու իր էկոհամակարգը

Scroll は、グローバルコミュニティの貢献を認識し、エコシステムを分散化するために $SCR トークンを発行します

Scroll បើកដំណើរការ $SCR Token ដើម្បីទទួលស្គាល់ការរួមចំណែករបស់សហគមន៍សកល និងធ្វើវិមជ្ឈការប្រព័ន្ធអេកូឡូស៊ីរបស់វា

Scroll глобалдык коомчулуктун салымын таануу жана анын экосистемасын децентралдаштыруу үчүн $SCR Токенин ишке киргизди

Scroll wprowadza token $SCR, aby docenić wkład społeczności globalnej i zdecentralizować swój ekosystem

Scroll lança token $SCR para reconhecer a contribuição da comunidade global e descentralizar seu ecossistema

Tembeza Inazindua Tokeni ya $SCR Ili Kutambua Mchango wa Jumuiya ya Kimataifa na Kugawanya mfumo wake wa ikolojia

Scroll เปิดตัวโทเค็น $SCR เพื่อรับรู้ถึงการมีส่วนสนับสนุนของชุมชนโลกและกระจายอำนาจให้กับระบบนิเวศ

Scroll 推出 $SCR 代币，以表彰全球社区贡献并实现生态系统去中心化

I-Scroll Yethula Ithokheni ye-$SCR Ukuze Ubone Igalelo Lomphakathi Womhlaba Wonke Futhi Uhlukanise I-Ecosystem yayo

Imagine you're a developer, and a tester brings you a bug that was found during regression. You want to fix this bug, so you ask for a ticket to be created. You’re already imagining how you’ll pick it up, link pull requests to it, and add estimates so that the product manager won’t have any questions. Some time passes, and a new ticket appears, but inside, there are only a couple of lines and a screenshot. With a sigh, you try to reproduce the bug using this information, but there’s no error. You try several times, but in the end, you write to the tester that the bug cannot be reproduced, and a new round of clarifications begins. You’re spending time that could have been used to work on new tasks, fix other bugs, or even watch anime refactor the code. My name is Evgeny Domnin; I’m a QA, and I’ll try to share my view on what makes a good bug report. Sorry for the long introduction—let’s get started. Title Try to answer three questions in the ticket title: Where does it happen?
What happens?
Under what circumstances? An experienced developer will only need to glance at the title to understand the issue. For example: Login Page: The field is not highlighted when entering an incorrect password Environment I’ve often seen testers forget to specify in the ticket which environment the issue occurred in. This is especially relevant in UI-related tickets, where the website address or network request isn’t visible. Always specify this. If there’s a separate field in the ticket, great, put it there. If not, mention it in the reproduction steps, for example: Log in to the staging environment with an admin account. Speaking of steps... Reproduction Steps One of the most important sections is the bug reproduction instructions. I’ll highlight two parts to focus on: the formatting of the steps (visual) and the content (data inside). Visual Part Maintain structure There are different variations of bug reports, but classically, they should contain the following sections: Steps
Expected result
Actual result Use this structure, and stick to it always. This is one of those cases where uniformity will help organize your thoughts when describing the issue. Use a numbered list Break down the steps using a numbered list. Sometimes, testers write detailed descriptions, but as a continuous block of text. Don’t do this. It will be much easier for everyone to read if the steps are separated. Whenever possible, write without grammatical errors. Now, let's move on to the content of these steps. Common Sense in Descriptions You don’t need to break down every single action into a separate step if it’s not crucial for reproducing the bug—this is hard to read and use in practice. Don’t be afraid to include multiple actions in one step. What do I mean? Bad: Go to test.com/login


Click on the login field


Enter the login


Click on the password field


Enter the password Good: Go to test.com/login and log in with any account We’re not breaking down the steps into things the developer will naturally do while following the standard flow. When I was starting out, I used to think that every single action needed its own step, but it’s not necessary. Avoid ambiguity Always supplement the steps with the specific request to check at each step, and write the specific button to press (especially if there are buttons with the same name). Include test data Provide login data if the error is related to your account, and don’t hesitate to include test payloads that help reproduce the bug. Review your steps again Sometimes, you write the steps immediately after encountering the bug, but it may turn out that you’ve missed a step for full understanding or the bug can’t be reproduced later. In that case, more precise steps may need to be found. Expected Result A separate section is the expected result, where we describe (unsurprisingly) the result that is expected when the steps are followed. There aren’t many special recommendations here other than that this section must exist—the developer needs to understand what behavior the functionality should lead to. Phrases like “everything should work fine” don’t cut it—write the specific behavior. Actual Result Here, we write what actually happened when we followed the steps. Specificity is important here too. Don’t just write “everything broke” (even though that’s probably what happened). Describe the indicators that show everything broke. For example: A 500 error is returned on the GET /accounts request, and the UI is blocked. The user cannot exit the page or click on elements. Refreshing the page triggers the request again and leads to the same error. In other words, describe the actual effect and how it impacts the user’s flow. Additional Files This is a separate section worth mentioning. It’s where you attach additional information that describes the bug. I know some developers who aren’t fans of reading reproduction steps and go straight to the actual result and additional materials that explain it. Screenshots of the Error It’s better to see it once than hear about it a hundred times. This is a great way to visually show what’s happening and where. Always try to attach a screenshot. Request If there’s a request where the error occurred, it should always be included in the ticket. However, requests contain many different parameters. I highlight the following as important to include: Error URL – the request itself, which you can get from the Network section in the browser where the testing is being done. Method – GET, POST, TRACE, OPTION, etc. There are many methods, just like there are requests with the same URL but different methods. Don’t forget to specify it in the ticket. Error code – another important point. You probably won’t forget it, but don’t forget to note what code was returned from the server. Payload – this is the data we sent in our request to the server. This isn’t present in every request (e.g., HEAD or GET don’t have it), but it might be the cause of the error. Response – the server’s response. Sometimes, it contains the full error, even showing where it occurred, while other times it’s just a default placeholder that’s set up on the backend for that type of error. Make sure to include this—it will save the developer a lot of time. Console Logs Sometimes, errors are found in the console, and these can be added to the ticket. Maybe you’ve already been doing this, but I’ll just note that a large block of text can always be saved as a .log file and added to the ticket. This improves the readability of both the logs and the ticket itself. This Is All Well and Good, But... This is all well and good, but where will we find the time to make everything look this nice? Deadlines are looming, the manager is getting angry, there’s a blocker in production, and I’m being asked to sit and write everything out? I’ll just message the developer directly, and that’s it. This is a logical argument that may arise. I don’t harbor any illusions about the perfect world of a tester, where ample time is allocated for testing, everything goes by process, and thorough and high-quality documentation is maintained. I understand—often, it’s a time crunch, burning... well, eyes, and a race to get everything done in time. Small errors tend to pile up, take more time due to context switching, and lead to poor practices. If we start gradually implementing improvements and monitoring how they work, we’ll be able to create a process that’s more stable, standardized, and predictable for all participants. The project manager will understand what’s happening with the product without needing to pull everyone for updates, the developer won’t have to ask the tester for clarification on reproduction conditions and won’t pull them away from testing, and stakeholders will, in turn, have a clear view of the product’s progress. This article is more aimed at beginners who are starting or have already begun their path in testing. I believe that small steps lead to big results, and the recommendations in this article will lead to higher-quality bug reports. If you have any questions, suggestions, disagreements, or complaints, feel free to leave them in the comments—I’m interested in hearing your opinion! Imagine you're a developer, and a tester brings you a bug that was found during regression. You want to fix this bug, so you ask for a ticket to be created. You’re already imagining how you’ll pick it up, link pull requests to it, and add estimates so that the product manager won’t have any questions. Some time passes, and a new ticket appears, but inside, there are only a couple of lines and a screenshot. With a sigh, you try to reproduce the bug using this information, but there’s no error. You try several times, but in the end, you write to the tester that the bug cannot be reproduced, and a new round of clarifications begins. You’re spending time that could have been used to work on new tasks, fix other bugs, or even watch anime refactor the code. watch anime My name is Evgeny Domnin ; I’m a QA , and I’ll try to share my view on what makes a good bug report. Sorry for the long introduction—let’s get started. Evgeny Domnin QA Title Title Try to answer three questions in the ticket title: Where does it happen? What happens? Under what circumstances? Where does it happen? Where does it happen? What happens? What happens? Under what circumstances? Under what circumstances? An experienced developer will only need to glance at the title to understand the issue. For example: Login Page: The field is not highlighted when entering an incorrect password Login Page: The field is not highlighted when entering an incorrect password Environment Environment I’ve often seen testers forget to specify in the ticket which environment the issue occurred in. This is especially relevant in UI-related tickets, where the website address or network request isn’t visible. Always specify this. If there’s a separate field in the ticket, great, put it there. If not, mention it in the reproduction steps, for example: Log in to the staging environment with an admin account. Log in to the staging environment with an admin account. Speaking of steps... Reproduction Steps Reproduction Steps One of the most important sections is the bug reproduction instructions. I’ll highlight two parts to focus on: the formatting of the steps (visual) and the content (data inside). Visual Part Maintain structure Maintain structure There are different variations of bug reports, but classically, they should contain the following sections: Steps Expected result Actual result Steps Expected result Actual result Use this structure, and stick to it always. This is one of those cases where uniformity will help organize your thoughts when describing the issue. Use a numbered list Use a numbered list Break down the steps using a numbered list. Sometimes, testers write detailed descriptions, but as a continuous block of text. Don’t do this. It will be much easier for everyone to read if the steps are separated. Whenever possible, write without grammatical errors. Now, let's move on to the content of these steps. Common Sense in Descriptions You don’t need to break down every single action into a separate step if it’s not crucial for reproducing the bug—this is hard to read and use in practice. Don’t be afraid to include multiple actions in one step. What do I mean? Bad : Bad Go to test.com/login Click on the login field Enter the login Click on the password field Enter the password Go to test.com/login Go to test.com/login test.com/login Click on the login field Click on the login field Enter the login Enter the login Click on the password field Click on the password field Enter the password Enter the password Good : Good Go to test.com/login and log in with any account Go to test.com/login and log in with any account test.com/login We’re not breaking down the steps into things the developer will naturally do while following the standard flow. When I was starting out, I used to think that every single action needed its own step, but it’s not necessary. Avoid ambiguity Avoid ambiguity Always supplement the steps with the specific request to check at each step, and write the specific button to press (especially if there are buttons with the same name). Include test data Include test data Provide login data if the error is related to your account, and don’t hesitate to include test payloads that help reproduce the bug. Review your steps again Review your steps again Sometimes, you write the steps immediately after encountering the bug, but it may turn out that you’ve missed a step for full understanding or the bug can’t be reproduced later. In that case, more precise steps may need to be found. Expected Result Expected Result A separate section is the expected result, where we describe (unsurprisingly) the result that is expected when the steps are followed. There aren’t many special recommendations here other than that this section must exist—the developer needs to understand what behavior the functionality should lead to. Phrases like “everything should work fine” don’t cut it—write the specific behavior. Actual Result Actual Result Here, we write what actually happened when we followed the steps. Specificity is important here too. Don’t just write “everything broke” (even though that’s probably what happened). Describe the indicators that show everything broke. For example: A 500 error is returned on the GET /accounts request, and the UI is blocked. The user cannot exit the page or click on elements. A 500 error is returned on the GET /accounts request, and the UI is blocked. The user cannot exit the page or click on elements. Refreshing the page triggers the request again and leads to the same error. Refreshing the page triggers the request again and leads to the same error. In other words, describe the actual effect and how it impacts the user’s flow. Additional Files Additional Files This is a separate section worth mentioning. It’s where you attach additional information that describes the bug. I know some developers who aren’t fans of reading reproduction steps and go straight to the actual result and additional materials that explain it. Screenshots of the Error It’s better to see it once than hear about it a hundred times. This is a great way to visually show what’s happening and where. Always try to attach a screenshot. Request If there’s a request where the error occurred, it should always be included in the ticket. However, requests contain many different parameters. I highlight the following as important to include: Error URL – the request itself, which you can get from the Network section in the browser where the testing is being done. Error URL – the request itself, which you can get from the Network section in the browser where the testing is being done. Error URL Method – GET, POST, TRACE, OPTION, etc. There are many methods, just like there are requests with the same URL but different methods. Don’t forget to specify it in the ticket. Method – GET , POST , TRACE , OPTION , etc. There are many methods, just like there are requests with the same URL but different methods. Don’t forget to specify it in the ticket. Method GET POST TRACE OPTION Error code – another important point. You probably won’t forget it, but don’t forget to note what code was returned from the server. Error code – another important point. You probably won’t forget it, but don’t forget to note what code was returned from the server. Error code Payload – this is the data we sent in our request to the server. This isn’t present in every request (e.g., HEAD or GET don’t have it), but it might be the cause of the error. Payload – this is the data we sent in our request to the server. This isn’t present in every request (e.g., HEAD or GET don’t have it), but it might be the cause of the error. Payload Response – the server’s response. Sometimes, it contains the full error, even showing where it occurred, while other times it’s just a default placeholder that’s set up on the backend for that type of error. Make sure to include this—it will save the developer a lot of time. Response – the server’s response. Sometimes, it contains the full error, even showing where it occurred, while other times it’s just a default placeholder that’s set up on the backend for that type of error. Make sure to include this—it will save the developer a lot of time. Response Console Logs Sometimes, errors are found in the console, and these can be added to the ticket. Maybe you’ve already been doing this, but I’ll just note that a large block of text can always be saved as a .log file and added to the ticket. This improves the readability of both the logs and the ticket itself. .log This Is All Well and Good, But... This Is All Well and Good, But... This is all well and good, but where will we find the time to make everything look this nice? Deadlines are looming, the manager is getting angry, there’s a blocker in production, and I’m being asked to sit and write everything out? I’ll just message the developer directly, and that’s it. This is all well and good, but where will we find the time to make everything look this nice? Deadlines are looming, the manager is getting angry, there’s a blocker in production, and I’m being asked to sit and write everything out? I’ll just message the developer directly, and that’s it. This is a logical argument that may arise. I don’t harbor any illusions about the perfect world of a tester, where ample time is allocated for testing, everything goes by process, and thorough and high-quality documentation is maintained. I understand—often, it’s a time crunch, burning... well, eyes, and a race to get everything done in time. Small errors tend to pile up, take more time due to context switching, and lead to poor practices. If we start gradually implementing improvements and monitoring how they work, we’ll be able to create a process that’s more stable, standardized, and predictable for all participants. The project manager will understand what’s happening with the product without needing to pull everyone for updates, the developer won’t have to ask the tester for clarification on reproduction conditions and won’t pull them away from testing, and stakeholders will, in turn, have a clear view of the product’s progress. This article is more aimed at beginners who are starting or have already begun their path in testing. I believe that small steps lead to big results, and the recommendations in this article will lead to higher-quality bug reports. If you have any questions, suggestions, disagreements, or complaints, feel free to leave them in the comments—I’m interested in hearing your opinion! If you have any questions, suggestions, disagreements, or complaints, feel free to leave them in the comments—I’m interested in hearing your opinion!

How to Write Good Bug Reports: Recommendations

ጥሩ የሳንካ ሪፖርቶችን እንዴት መፃፍ እንደሚቻል፡ ምክሮች

Sådan skriver du gode fejlrapporter: anbefalinger

Cómo redactar buenos informes de errores: recomendaciones

نحوه نوشتن گزارش اشکال خوب: توصیه ها

Hyvien virheraporttien kirjoittaminen: suosituksia

Ինչպես գրել լավ սխալների մասին հաշվետվություններ. Առաջարկություններ

良いバグレポートを書く方法: 推奨事項

राम्रो बग रिपोर्टहरू कसरी लेख्ने: सिफारिसहरू

Imaynatataq allin pantasqa willakuykunata qillqana: Yuyaychaykuna

วิธีการเขียนรายงานจุดบกพร่องที่ดี: คำแนะนำ

Paano Sumulat ng Magandang Ulat sa Bug: Mga Rekomendasyon

Ndlela Yo Tsala Swiviko Leswinene Swa Swihoxo: Switsundzuxo

Using AWS Rekognition to Power Object Detection for Recommendations and Content Moderation

My Thoughts to Protect Privacy A mask designed to deny AI-based facial recognition from all angles. I have always been a pretty private person, but lately, the weight of it feels as unbearable as ever. I just can’t seem to get out with a feeling of people watching me every time. It is no paranoia but just the plain reality of living in a place where face recognition has become an easy technological tool. And when you turn around, the shiny lenses of cameras pop up everywhere-from street corners and shop windows to public events. It is as if my face has become a commodity something that is catalogued and analyzed. I remember when I first heard about AI facial recognition systems. It was a news update, on a cold autumn evening. I was holding hot tea, covered by a blanket, scanning my phone as it scrolled its screen. The anchor spoke confidently about such systems wherein one could identify a person in seconds, revealing his personal history and preferences without ever knowing him or her. Shivers run through my spine. Over time, it had nothing to do with cameras; it’s who I am, my preferences, and -sold to the highest bidder. Already Available on Amazon Yelo Pomelo Anti Surveillance Neck Gaiter, Anti Facial Recognition Mask and Headband, Face Protest facial recognition tech by wearing this anti-surveillance neck gaiter. The more you know, the more you feel that you are one rat in an experiment into which you certainly have yet to sign up. Every day, you hear stories of people whose lives have been picked apart by algorithms because they happened to pass in front of surveillance cameras. I could envision my face torn into pieces. All the wrinkles and blemishes would be magnified, and reduced to mere data points. It was like living in some science fiction dystopia where the government and corporations pulled all the strings. Everything I said would not matter. Somehow it pierced my life: the thought of being checked on all the time. I stopped walking around places, and wouldn’t even go to the park with “intelligent” cameras installed; instead, only shop from small stores where no security footage was even installed. It was draining. I would consider changing my appearance completely by getting a new hair color and wearing different hats and sunglasses just so I’d feel like I ain't being exposed so much. Deep down, however, I realized that wasn't just a Band-Aid on a much bigger issue. Something appeared on the internet one afternoon: a mask designed to evade facial recognition. I read through all the details about it greedily: special confusing materials for algorithms, interesting patterns distorting features, and even changing colors with light. This is something straight out of a future film, and my heart skips a beat. Perhaps this was my chance to get my private life back. I told them I wanted one. And when it came, I ripped open the package and looked at it with eagerness and skepticism. It didn’t resemble anything I’d ever worn before, this psychotropic swirling look and shape. I put it on and looked into the mirror. It felt marvelous wearing something that was a symbol of resistance against constant surveillance. Finally a semblance of confidence after months, and this mask of theirs that’s now my defense against a world turned mad on breaking into one’s life. The next time I dared to go out, I wore the mask with pride. My head held high, I went to step out into the streets, feeling to myself that I was at least free to do as I pleased. Even so, passing by familiar buildings did not still the nagging doubt in the back of my head. What if this attracted more onlookers? Perhaps it would have made people start wondering about me. It was a time of empowerment and fear reminding me I was fighting a battle uphill against something invisible. I knew that something in the air around me had shifted because people looked at me with that unmistakable gaze; some stared while others whispered behind each other’s ears. There was no feeling of being safe anymore but exposed in a whole new way, for the mask became a beacon and a declaration of wariness of the world around me, and that alone seemed to be drawing attention. I realized at that moment that it wasn’t about staying secret, but rather about being seen. Not to attention to myself but just to walk around the world and not automatically be placed under the spotlight for others’ exhibitions. And I knew that although the mask protected me from recognition by AI, it could not save society from judgment and shame of my uniqueness. So, I tried to balance my two states of being. Less and less was I wearing the mask. In its place, a simple scarf or oversized sunglasses became my new accessory. My scope narrowed down to small things that helped keep my privacy: change messaging apps to encrypted services, block location-sharing features on your devices, and tell your community to ask for stronger privacy laws. Each movement, in its way, was a token of regained agency, but each battle seemed impossible to win. One night, over a cup of coffee in a café, I heard a group of friends grappling with the same fears as me. They talked about not feeling right with surveillance on them and began gathering stories of moments when they felt viewed in locations where they probably shouldn’t be viewed. A relief-it wasn't just me. Ideas on how to deal and we spoke about the potential of obliterating technology rather than our rights. I realized through that conversation perhaps that I was suffering in a state of isolation, while a movement was growing of people who shared similar concerns. Maybe the future wasn’t as dark as I thought. The more people began talking about the need for private lives, the more this would breed an awareness of the need for solutions, perhaps like the anti-facial recognition mask, and then the change. I still fear to open my private life to the public, and my mask continues to remain within that journey. It is a reminder of where the battlefield lies-between liberties and technological surveillance. I cannot possibly destroy it from within, but I can fight for my right to exist without people watching me all the time. In such a digital world, it feels like such a heavy struggle to fight for privacies, but every little one counts. So, for now, I will continue to find more ways to protect my identity as I form bonds with people who share my concerns, hoping together we can make privacy not just a choice but something that is owed. My Thoughts to Protect Privacy A mask designed to deny AI-based facial recognition from all angles. I have always been a pretty private person, but lately, the weight of it feels as unbearable as ever. I just can’t seem to get out with a feeling of people watching me every time. It is no paranoia but just the plain reality of living in a place where face recognition has become an easy technological tool. And when you turn around, the shiny lenses of cameras pop up everywhere-from street corners and shop windows to public events. It is as if my face has become a commodity something that is catalogued and analyzed. I remember when I first heard about AI facial recognition systems. It was a news update, on a cold autumn evening. I was holding hot tea, covered by a blanket, scanning my phone as it scrolled its screen. The anchor spoke confidently about such systems wherein one could identify a person in seconds, revealing his personal history and preferences without ever knowing him or her. Shivers run through my spine. Over time, it had nothing to do with cameras; it’s who I am, my preferences, and -sold to the highest bidder. Already Available on Amazon Yelo Pomelo Anti Surveillance Neck Gaiter, Anti Facial Recognition Mask and Headband, Face Protest facial recognition tech by wearing this anti-surveillance neck gaiter. Yelo Pomelo Anti Surveillance Neck Gaiter, Anti Facial Recognition Mask and Headband, Face Protest facial recognition tech by wearing this anti-surveillance neck gaiter. The more you know, the more you feel that you are one rat in an experiment into which you certainly have yet to sign up. Every day, you hear stories of people whose lives have been picked apart by algorithms because they happened to pass in front of surveillance cameras. I could envision my face torn into pieces. All the wrinkles and blemishes would be magnified, and reduced to mere data points. It was like living in some science fiction dystopia where the government and corporations pulled all the strings. Everything I said would not matter. Somehow it pierced my life: the thought of being checked on all the time. I stopped walking around places, and wouldn’t even go to the park with “intelligent” cameras installed; instead, only shop from small stores where no security footage was even installed. It was draining. I would consider changing my appearance completely by getting a new hair color and wearing different hats and sunglasses just so I’d feel like I ain't being exposed so much. Deep down, however, I realized that wasn't just a Band-Aid on a much bigger issue. Something appeared on the internet one afternoon: a mask designed to evade facial recognition. I read through all the details about it greedily: special confusing materials for algorithms, interesting patterns distorting features, and even changing colors with light. This is something straight out of a future film, and my heart skips a beat. Perhaps this was my chance to get my private life back. I told them I wanted one. And when it came, I ripped open the package and looked at it with eagerness and skepticism. It didn’t resemble anything I’d ever worn before, this psychotropic swirling look and shape. I put it on and looked into the mirror. It felt marvelous wearing something that was a symbol of resistance against constant surveillance. Finally a semblance of confidence after months, and this mask of theirs that’s now my defense against a world turned mad on breaking into one’s life. The next time I dared to go out, I wore the mask with pride. My head held high, I went to step out into the streets, feeling to myself that I was at least free to do as I pleased. Even so, passing by familiar buildings did not still the nagging doubt in the back of my head. What if this attracted more onlookers? Perhaps it would have made people start wondering about me. It was a time of empowerment and fear reminding me I was fighting a battle uphill against something invisible. I knew that something in the air around me had shifted because people looked at me with that unmistakable gaze; some stared while others whispered behind each other’s ears. There was no feeling of being safe anymore but exposed in a whole new way, for the mask became a beacon and a declaration of wariness of the world around me, and that alone seemed to be drawing attention. I realized at that moment that it wasn’t about staying secret, but rather about being seen. Not to attention to myself but just to walk around the world and not automatically be placed under the spotlight for others’ exhibitions. And I knew that although the mask protected me from recognition by AI, it could not save society from judgment and shame of my uniqueness. So, I tried to balance my two states of being. Less and less was I wearing the mask. In its place, a simple scarf or oversized sunglasses became my new accessory. My scope narrowed down to small things that helped keep my privacy: change messaging apps to encrypted services, block location-sharing features on your devices, and tell your community to ask for stronger privacy laws. Each movement, in its way, was a token of regained agency, but each battle seemed impossible to win. One night, over a cup of coffee in a café, I heard a group of friends grappling with the same fears as me. They talked about not feeling right with surveillance on them and began gathering stories of moments when they felt viewed in locations where they probably shouldn’t be viewed. A relief-it wasn't just me. Ideas on how to deal and we spoke about the potential of obliterating technology rather than our rights. I realized through that conversation perhaps that I was suffering in a state of isolation, while a movement was growing of people who shared similar concerns. Maybe the future wasn’t as dark as I thought. The more people began talking about the need for private lives, the more this would breed an awareness of the need for solutions, perhaps like the anti-facial recognition mask, and then the change. I still fear to open my private life to the public, and my mask continues to remain within that journey. It is a reminder of where the battlefield lies-between liberties and technological surveillance. I cannot possibly destroy it from within, but I can fight for my right to exist without people watching me all the time. In such a digital world, it feels like such a heavy struggle to fight for privacies, but every little one counts. So, for now, I will continue to find more ways to protect my identity as I form bonds with people who share my concerns, hoping together we can make privacy not just a choice but something that is owed.

An Anti-Facial Recognition Mask: Fighting for Privacy

Stories, News & Mentions about REECO

Reeco’s Stories on HackerNoon