标签：#AR

30 React.js Interview Questions You Should Know Before Your Next Frontend Interview ⚛️ Whether you're preparing for a frontend interview or simply want to brush up on your React.js knowledge , this guide covers 30 real-world, scenario-based React interview questions that interviewers frequently ask. The goal isn't just to memorize definitions. These questions are designed to help you understand how and when to apply React concepts in real-world applications . 📌 Bookmark this article and come back to it during your next interview preparation session. 📚 What We'll Cover In this guide, we'll explore questions around: Conditional rendering API calls and side effects Form validation Performance optimization State management Component re-rendering Keys and lists Dark mode Dynamic components useEffect vs useLayoutEffect Large-list optimization And much more... 1. How do you handle conditional rendering in React? Conditional rendering allows you to render different UI based on application state or conditions. You can use standard JavaScript techniques such as: if...else Ternary operators Logical && Example { isLoggedIn ? < Dashboard /> : < Login />} 💡 Interview Tip For simple conditions, a ternary operator or && is usually sufficient. For more complex conditions, consider moving the logic outside the JSX to keep the component readable. 2. You need to fetch API data when a component mounts. What's the best way to do it? 💡 Key Concept The typical approach is to perform the API request inside a useEffect hook when the component needs to fetch data after rendering. A common pattern is: useEffect (() => { // Fetch API data }, []); The empty dependency array indicates that the effect is intended to run after the initial render. Note: In modern React applications, the best approach can also depend on the framework or data-fetching library you're using. 3. How would you handle form validation in React? A common approach is to use controlled inputs and perform validation during even

I’ve been building a side project called OopsCalorie , an AI-powered calorie and meal tracking app. The idea sounded simple enough: User logs or takes a photo of their food. AI identifies the meal. Estimate calories and macros. Save the entry. Done. Simple, right? Well... Then we started testing it with Filipino food. 😂 AI Meets Filipino Food 🇵🇭 One of the funniest parts of building OopsCalorie has been testing the food recognition. At one point, our AI confidently looked at dinuguan and decided: That's champorado. Okay. I can kind of see where you were coming from. Both are dark, both can be served in a bowl... But still. 😂 Then came bagnet . AI: Lumpiang Shanghai. Bro. Not even close. 😂 These bugs are funny, but they also exposed one of the more interesting engineering problems behind OopsCalorie: Image recognition is only the first step. Correctly identifying a meal — especially regional dishes — requires much more context than I initially expected. The Real Problem Isn't Just Calories When I started the project, I thought the difficult part would be estimating calories. Turns out, before you can estimate: You need to know what the food actually is. And food can be surprisingly ambiguous from an image. A photo might contain: multiple dishes sauces hiding ingredients visually similar foods regional dishes that aren't well represented in training data different cooking methods unknown portion sizes ingredients completely hidden underneath other ingredients Even humans sometimes need context. "Is that pork adobo or humba?" "Is that fried pork belly or bagnet?" Now imagine asking an AI to determine that from pixels alone. Building Around AI Instead of Blindly Trusting It This changed how I'm approaching the system. Instead of treating the AI response as absolute truth, OopsCalorie is evolving toward a workflow where AI provides an intelligent estimate while the user still has the ability to provide context and correct it. We're experimenting with things like: Image +

Most people ask: What will my first job teach me? The deeper question is quieter: What does it take to become someone who can finally be trusted with real work? There is a real tension in the first job. One view says it’s just a stepping stone — gain experience, update the résumé, move on. Another says it shapes you in ways that stay long after the job itself is forgotten. Both can be true. A first job can be temporary. What you learn from it may not be. The First Mistake Imagine a young graduate starting on a Monday. By Thursday they have already made a small but visible mistake — the wrong file, a misread requirement, an assumption that turned out wrong. They sit at their desk replaying it. What will my manager think? Did I just ruin my first impression? But the office doesn’t stop. The team keeps working. The next task arrives. Slowly they realize something that rarely appears on any résumé: A mistake doesn’t end a career. You acknowledge it. Fix what you can. Learn. Then continue. That lesson can stay with someone for years. When Nobody Is Standing Behind You College gives instructions. A first job gives responsibility. At some point someone hands you a problem and expects you to figure out where to begin. You may not know the answer. You may not even know the right question yet. That is when the real transition begins. You learn when to ask for help, when to investigate alone, when to admit you don’t understand, and eventually when to decide without waiting for someone else to tell you exactly what to do. Two People, One First Job Imagine two people joining the same company on the same day. Both are capable. Both make mistakes. One treats every task as something to finish until a better opportunity appears. The other starts noticing what each task is teaching — how problems are approached, how decisions are made, how mistakes are handled. Five years later their résumés may look similar. Their instincts may not. The difference isn’t necessarily who had the bette

Last quarter, we ran our production voice AI receptionist — Loquent — across four different TTS engines simultaneously, split-testing real patient calls at dental and healthcare clinics. The results surprised us: the most "natural sounding" engine in demos performed the worst with actual patients. Why We Ran This Test At Autor, we've been running Loquent in production for over a year now. It handles thousands of automated calls per month for healthcare and dental clinics across Canada — booking appointments, answering insurance questions, handling after-hours triage. The voice is the product. If patients don't trust the voice, they hang up, and the clinic loses a booking. When we first built Loquent, we picked our TTS engine the way most teams do: we generated a few sample clips, played them for ourselves, and went with the one that sounded best in a quiet office. That worked fine until we started digging into our call analytics and noticed something weird. Our completion rate — the percentage of calls where patients actually finished the full interaction instead of hanging up or asking for a human — was hovering around 74%. Good, but not great. We suspected the voice itself was part of the problem. So we designed a proper A/B test. Not a demo comparison. A production comparison on live calls. The Setup We tested four TTS engines across 12,247 calls over 8 weeks. Each engine handled roughly equal volume, randomly assigned at call start. All other variables stayed constant: same prompts, same Anthropic Claude backbone for conversation, same Twilio infrastructure, same clinics. The four engines: Engine A : ElevenLabs (Turbo v2.5) — our existing production engine Engine B : OpenAI TTS (tts-1-hd) — the model most teams default to Engine C : Deepgram Aura — optimized for real-time, low-latency use cases Engine D : A newer entrant we'd been evaluating (under NDA, so I can't name it) We measured five things: Completion rate — did the patient finish the full call flow? Time

Hello, I'm Maneshwar. I'm building git-lrc, a Micro AI code reviewer that runs on every commit. It is...

What Is Software Testing? 🧪 Software testing is the process of checking software to make sure it works correctly and does what it is supposed to do. For example, when we use a login page, we can test: Correct username and password Wrong password Empty username Empty password Forgot password option The goal is to find bugs and problems before the software is used by customers. Why Is Testing Important? Testing helps developers and companies: Find bugs Improve software quality Provide a better user experience Prevent problems after release Even a small bug can sometimes cause a big problem, so testing is an important part of software development. Manual Testing In manual testing, a tester checks the application manually without using automation scripts. For example, a tester can open a website, enter different inputs, click buttons, and check whether the expected result appears. Automation Testing In automation testing, we use tools and programming to test software automatically. Some popular tools are: Selenium Playwright Cypress Automation is useful when the same tests need to be performed many times. Conclusion Software testing is an important part of creating reliable software. If you are a beginner, you can start with manual testing , then learn SQL, API testing, and automation testing .

xUnit 4.0.0 makes full test-case parallelization an explicit option. That is useful, but xUnit 4 ParallelMode.All changes a quiet assumption in many suites: tests in the same class, including separate rows of one theory, may now overlap. A static fake, shared fixture, temporary file, or database record that was safe under collection-level parallelism can become a race. I treat this as an isolation change, not a speed switch. Before enabling it across a suite, I want a deterministic failure that proves the risk and a deterministic check for each guardrail. What xUnit 4 ParallelMode.All changes The xUnit.net v3 4.0.0 release notes describe full test-case parallelization as a new feature. The default is still ParallelMode.Collections , so upgrading does not silently enable the broader mode. I have to opt in at the assembly level: using Xunit.Sdk ; using Xunit.v3 ; [ assembly : Parallelization ( Mode = ParallelMode . All , MaxThreads = 2 , Algorithm = ParallelAlgorithm . Conservative )] With Collections , tests within a collection are serialized. With All , every test case is eligible to run beside every other test case. That includes two cases from the same class and two pre-enumerated rows from the same theory. The official parallel test execution guide documents the modes, algorithms, and available opt-out scopes. I set MaxThreads = 2 in the sample so the scheduling condition is easy to inspect. It is a demonstration setting, not a recommendation for CI. The right value depends on available CPU, memory, and the external systems touched by the tests. Before changing the mode, I scan for mutable static fields, IClassFixture and ICollectionFixture implementations, fixed file names, environment-variable changes, test servers bound to fixed ports, and records addressed by shared IDs. I also check theory data sources for objects that rows can mutate. That inventory tells me whether the resource should become concurrency-safe, receive a unique per-test identity, or stay beh

Struggling with burnout? Procrastination? Reaching your goals? Let me share a few methods that help...

There’s a hands-on workshop on August 29 that builds and benchmarks this properly, end to end, using entirely open models, no API calls involved. Led by Ben Auffarth, AI Consultant and Founder of Chelsea AI Ventures. What it covers: • Hybrid retrieval (vector + keyword, not vector alone) • Reranking to catch relevant chunks that vector search alone misses • Evaluation with RAGAS, so quality changes are measured, not assumed • Guardrails built in from the design stage • Actual cost and performance benchmarking for open-model deployments Link if anyone wants to check it out: https://www.eventbrite.co.uk/e/the-genai-build-lab-build-production-ready-rag-on-a-budget-tickets-1994016271345?aff=rml Happy to answer questions on the methodology or content. submitted by /u/camerongreen95 [link] [留言]

The instructions say Author Year format. But I was wondering if do numbered instead (no space lol), will it be straight desk rejection? Has anyone submitted with numbered format before? How did it go? submitted by /u/confirm-jannati [link] [留言]

The most interesting thing about AI coding agents right now is not that they can write code. It is that they are starting to operate computers. That sounds like a small distinction until you feel it in the workflow. A code generator lives inside a text box. It waits for a prompt, returns a patch, and leaves the rest of the job to you. A software operator can inspect the app, click through the broken flow, read the console, run the server, reproduce the issue, change the code, and check whether the thing actually works. That is a different kind of tool. OpenAI's May 29 Codex update points in that direction. Codex now supports computer use on Windows in the Codex app for eligible users, so it can see, click, and type in Windows applications while testing and refining software. The same release also expands remote control, letting a user steer work from ChatGPT on mobile or Codex on Mac while the Windows machine remains the host for the project files, shell, app server, and local context. I do not think the important part is Windows support by itself. The important part is the new shape of work. Coding Was Never Just Typing For a while, the AI coding story was mostly about generation. Could the model write a component? Could it scaffold an API route? Could it refactor a file without losing the plot? Useful, but narrow. Real software work has always been messier than text generation. You open the app. You notice the layout is wrong. You click a button. Nothing happens. You check the terminal. The dev server crashed. You restart it. The page loads, but the empty state is off. You resize the browser. The mobile nav breaks. You skim the network tab. The request is fine, but the UI state is stale. None of that is "write code" in the pure sense. It is operating the system around the code. That is why computer use matters. It gives the agent access to the loop that human engineers actually live in: observe, diagnose, change, verify. The text editor is only one stop in that lo

Here's what it was like watching a total solar eclipse 90 minutes north of Madrid.

If you’ve been circling around Disrupt, then now’s the best time to lock in your pass and start getting ready to join the rest of the startup community gathering in San Francisco from October 13-15 at Moscone West!

This story originally appeared in The Algorithm, our weekly newsletter on AI. To get stories like this in your inbox first, sign up here. Flock, the police-tech giant known for its network of some 120,000 automatic license plate readers around the US, announced some changes to its platform last Thursday. The updates are meant to prevent…

Higgsfield, founded by former Snap exec Alex Mashrabov, lets users create AI images and videos.

Petlibro says feeders perform scheduled feedings offline. Users report otherwise.

How Linux file permissions actually work under the hood, why symbolic mode is your best friend, and how to stop blindly typing chmod 777. Every Linux engineer has been there. You write a brand-new bash script, try to run it from your terminal, and hit an immediate roadblock: $ ./backup.sh bash: ./backup.sh: Permission denied You open your search engine or ask a chat assistant for help. Within seconds, you find an answer that tells you to run: chmod 777 backup.sh You run the command, hit enter, and the script runs. Problem solved, right? Not quite. In fact, you just opened the digital front door of that file to every single user and background service on the entire operating system. When I started managing Linux servers years ago, permissions felt like a strange puzzle of three-digit math problems. People kept throwing numbers around: 755 for scripts, 644 for web pages, 600 for SSH keys, and 777 whenever something broke and nobody knew why. I memorized those numbers like cheat codes in a video game. But whenever I had to handle a real permission problem, like giving a development team write access to a shared log folder without letting them delete each other's files, memorized numbers fell apart. Here is the secret: you do not need to do binary math or memorize three-digit codes to master Linux permissions. Linux has a built-in, human-readable permission syntax called symbolic mode . Once you understand how Linux looks at files, who owns them, and what actions each permission controls, chmod becomes one of the most intuitive tools in your terminal. Let's break down how it all works step by step. 1. What chmod Actually Does The name chmod stands for change mode . In Unix and Linux systems, every single file and directory has a "mode". That mode determines who is allowed to read it, write to it, or run it. When you run chmod , you are simply updating those access bits inside the Linux filesystem inode. To see the current mode of your files, open any terminal and run ls

Introduction Your program keeps opening transactions. A signup writes a new user row. A checkout debits one account and credits another. A form submission updates three related tables at once. You wrap it all in BEGIN and COMMIT and move on, trusting that the database will handle whatever happens in between. Most of the time it does. But what is it actually promising you when it handles that? And what does it have to do behind the scenes to keep that promise? Say a user transfers ₹1,000 from Account A to Account B. The application runs two updates: subtract 1,000 from A, add 1,000 to B. Now say the server crashes right after the first update runs but before the second one does. Account A: -₹1,000 Account B: +₹0 That money didn't move. It vanished. No error message fixes that, and no user accepts "the server restarted" as an explanation for their missing balance. This is the exact problem a set of guarantees called ACID was built to solve. Most developers can recite the acronym, Atomicity, Consistency, Isolation, Durability, without being able to explain what any of the four words actually promise, or what the database has to do internally to keep those promises. This article tries to fix that. -- 1. What Is a Transaction? Before ACID makes sense, you need to understand what a transaction actually is. A transaction is a group of one or more database operations treated as a single logical unit of work. Either the whole group succeeds, or none of it does. The bank transfer above is a textbook transaction: two updates that only make sense together. In SQL, a transaction usually looks like this: BEGIN ; UPDATE accounts SET balance = balance - 1000 WHERE id = 1 ; UPDATE accounts SET balance = balance + 1000 WHERE id = 2 ; COMMIT ; BEGIN tells the database "everything from here on is one unit." COMMIT tells it "we're done, make it permanent." If something goes wrong in between, a constraint violation, a crash, the application deciding to cancel, the database can issue a RO

Block scope is an important concept in JavaScript. It means that a variable can be accessed only inside the block where it is declared. A block is usually written using curly braces { } . Blocks can be found in if statements, loops, functions, and other parts of JavaScript code. In JavaScript, let and const are block-scoped variables. For example: { let name = " Abishek " ; console . log ( name ); } Output: Abishek Here, the variable name can be used inside the block. If we try to use it outside the block, JavaScript will give an error because the variable is not available outside its block. The same rule applies to const . if ( true ) { const age = 22 ; console . log ( age ); } Output: 22 The variable age can only be accessed inside the if block. However, var works differently. It is not block-scoped . It is function-scoped. For example: if ( true ) { var city = " Chennai " ; } console . log ( city ); Output: Chennai This code works because var can be accessed outside the if block. If we try the same thing with let : if ( true ) { let city = " Chennai " ; } console . log ( city ); Output: ReferenceError: city is not defined This happens because city is block-scoped and cannot be accessed outside the if block. Block scope is useful because it prevents variables from being accidentally used or changed outside the area where they are needed. It also makes code easier to understand and maintain. So, the main thing to remember is: let and const have block scope, while var has function scope. In modern JavaScript, let and const are generally preferred over var .

O contrato do cliente tá numa URL que qualquer um adivinha A tarefa parecia simples: o cliente precisa baixar a nota fiscal dele. Você salvou em storage/app/public/notas/ , rodou php artisan storage:link , mandou o link e foi feliz. https://app.com/storage/notas/nota-1042.pdf . Semanas depois cai a ficha. Aquele arquivo está aberto na internet . Sem login, sem nada. E o nome é sequencial: quem baixou a nota-1042.pdf só precisa de curiosidade e cinco segundos pra tentar a 1041 . E a 1040 . Então você faz a coisa certa: tira do disco público e cria um sistema pra controlar acesso. Tabela download_tokens , model, geração de UUID, coluna expires_at , controller que valida, e um comando no scheduler pra limpar os vencidos. Sessenta linhas depois, funciona. E aí alguém comenta no PR: "por que você não usou uma URL assinada?" O sistema que você não precisava construir // ❌ migration + model + controller + command. tudo isso pra um PDF. Schema :: create ( 'download_tokens' , function ( Blueprint $table ) { $table -> id (); $table -> uuid ( 'token' ) -> unique (); $table -> string ( 'path' ); $table -> foreignId ( 'user_id' ); $table -> timestamp ( 'expires_at' ); $table -> timestamps (); }); public function gerarLink ( NotaFiscal $nota ): string { $token = DownloadToken :: create ([ 'token' => Str :: uuid (), 'path' => $nota -> arquivo_path , 'user_id' => auth () -> id (), 'expires_at' => now () -> addMinutes ( 10 ), ]); return route ( 'download' , $token -> token ); } Não tem nada de errado tecnicamente. O problema é o custo: mais uma tabela crescendo pra sempre, mais um comando no scheduler, mais um caminho pra testar. E você vai manter isso enquanto o projeto existir. O Laravel resolve o mesmo problema com uma assinatura criptográfica na própria URL. Sem estado, sem tabela, sem limpeza. Como uma URL assinada funciona A ideia é bonita de simples: o Laravel monta a URL com os parâmetros que você quer, calcula um hash disso tudo usando a APP_KEY e cola o hash no final. /not