今日已更新 327 条资讯 | 累计 23910 条内容
关于我们

标签:#TC

找到 223 篇相关文章

开发者

Code in my life: A chronicle part 2

This post is a continuation of part 1 During my childhood, I was obsessed with mazes. I would spend hours drawing mazes with increasingly complex rules and I would force my parents and friends to solve them. I wanted to translate this to the computer. Every so often, I would return to the challenge. Most of my mazes were built in Minecraft. Soon though, my mind started to connect the dots. Minecraft had convinced me that computers could be bent to my will. If I could understand how the game worked, maybe I could make my own world. I was convinced understanding the .bat script was the key. Initially, I experimented. I vividly remember trying to rename the script, after which windows would yell out a scary warning about how changing an extension might make the file unusable. I quickly pressed cancel, hoping I did not break my game. The first time I tried opening the minecraft.bat file in notepad, I was overwhelmed. A bunch of nonsensical garbage filled my screen. I did not know it at the time, but the people who shipped the cracked version obfuscated the script. It was not meant to be understood. I borrowed more and more books on programming and computers from the library, slowly building an understanding of how mysterious lines of text made the computer do stuff. I attempted many times to apply my knowledge. Most of my "programming" was copying code from books in notepad, trying to run it but not having the compilers or knowledge to execute my code. My computer was littered with hundreds of little files. maze.py , maze.php , maze.java . Each an attempt to achieve my dream of creating a maze. Each time, I faced disappointment when I double-clicked, and the computer told me that the file I just worked on was unrecognised. However, there was one piece of code I wrote that actually worked. A small little batch script - welcoming me to a new world. echo "Hello World" A short while later the computer I was working on died. Being locked out of a world I had only just starte

2026-06-07 原文 →
AI 资讯

Learn Leetcode daily with Claude code mentor

This is a submission for the GitHub Finish-Up-A-Thon Challenge What I Built After being abandoned for several months, I have come back to build and complete Claude with LeetCode, which is a DSA learning system that automates daily algorithm education with Claude code directly inside GitHub repo. Every time I submit an accepted solution on Leetcode, the Github workflow fetches my Leetcode account data and commit the problem with the solution to the repo. Claude will then run on a fixed schedule and automatically generates a full structured lecture, covering the DSA topic, brute force through optimal solutions in Python, complexity analysis, and a YouTube video packaged in a GitHub Issue. This project means a lot to me because it merges two things I care about daily: now not only can I solve Leetcode problem, my solution is automatically analyzed by a powerful AI agent mentor. Demo Link to my project: https://github.com/Stewie-pixel/claude-with-leetcode.git Link to my application walkthrough: https://youtu.be/ClWdW3v9JJ0 The Comeback Story At first this was only a project to store the Leetcode questions I have solved. The process required manual pushing the problem to the repo and nothing special. Later I have added the automation workflow to fetch data from my Leetcode account, Claude will be prompted like an experienced dsa mentor from Claude and skill.md file to give a thorough analysis on that problem. And at the end of the day, Github Copilot workflow will give a daily summary report to cover my daily progress. My Experience with GitHub Copilot I built a DSA Mentor skill that gives Copilot the full context of what a lecture should contain: topic identification, the brute force to optimal approach structure, complexity analysis requirements, and the YouTube search step. Without Copilot, writing the dsaMentor.js orchestration logic and getting the agent to consistently produce structured markdown output would have taken significantly longer. I then use Copilot cli

2026-06-06 原文 →
AI 资讯

A Beginner-Friendly Mental Model for Bitcoin Transactions

Bitcoin can look simple from the outside: paste an address, choose an amount, send. Under that simple interface are several concepts that are useful for developers and technical beginners to understand. This post is not trading advice and does not discuss price. It is a practical mental model for what is happening when someone sends Bitcoin. 1. A wallet does not "hold coins" the way an app balance does Many beginners imagine a wallet as a container full of coins. That is close enough for casual conversation, but it can be misleading. A Bitcoin wallet manages keys and helps create transactions. The Bitcoin network tracks spendable outputs on the ledger. When you send BTC, the wallet constructs a transaction that spends previous outputs and creates new outputs. You do not need to master every detail on day one, but the high-level idea matters: control of keys controls the ability to spend. 2. An address is a destination, not an identity A Bitcoin address is where funds can be sent. It is not a username and it is not automatically tied to a person in the way a social profile is. Before sending, beginners should check the address carefully. A small copy-paste mistake can be permanent. Malware can also replace clipboard contents, so visually checking the beginning and ending characters is a useful habit. For larger transfers, a tiny test transaction can reduce risk. 3. Fees are about block space Bitcoin transactions compete for limited block space. A fee is not a tip to a company. It is part of the transaction economics that helps miners decide which transactions to include. When the network is busy, low-fee transactions may wait longer. When the network is quieter, confirmations may happen faster. The beginner lesson is simple: do not assume "sent" means "fully settled." Check confirmations and understand that fee choice can affect waiting time. 4. The mempool is a waiting area Before a transaction is confirmed in a block, it may sit in the mempool, which is a pool of u

2026-06-05 原文 →
AI 资讯

Improving My OWASP Authentication Failures Write‑Up Using GitHub Copilot

As part of the GitHub Copilot Challenge, I revisited one of my older cybersecurity notes on Authentication Failures and transformed it into a clear, structured, and SOC‑focused write‑up. This challenge helped me improve my technical writing, organise my thoughts, and explain concepts in a more human, readable way. * BEFORE GITHUB SCREENSHOTS: * AFTER GITHUB SCREENSHOTS: What I Improved I rewrote my entire explanation of authentication failures, focusing on: Token leakage Weak or missing MFA Poor session management Brute force & credential stuffing Misconfigured OAuth / SSO I also added SOC detection examples to make the content more practical and relevant for blue‑team work. How GitHub Copilot Helped GitHub Copilot supported me by: Suggesting clearer explanations Expanding short bullet points into meaningful content Helping me structure the write‑up Improving readability and flow Encouraging a more human, natural tone GitHub Repository Here is the updated write‑up in my repo: https://github.com/sujalavnelavai/Cybersecurity-Notes/blob/main/OWASP-Authentication-Failures/README.md Final Thoughts This challenge helped me understand authentication failures more deeply from a SOC and IAM perspective. It also improved my documentation skills — something extremely important for cybersecurity roles. I’m proud of the transformation and excited to continue building my cybersecurity learning notes.

2026-06-04 原文 →
AI 资讯

Leetcode 150 | Day 2: Remove Element - Naive vs. Optimized

Leetcode 27: Remove Element Leetcode 27 asks us to remove a specific value from an array. The value to be removed is passed in as a parameter to the function along with the array. Just as we did in Day 1, we will cover a naive approach and an optimized approach and discuss the trade-offs between them. I think in the end there's a pretty clear winner. Let's get started. For both approaches we will use the following values: nums = [1, 3, 3, 2, 4] val = 3 Approach 1: Naive (For Loop + Splice) This approach uses a for loop and leverages .splice() for removals. Solution: var removeElement = function ( nums , val ) { let k = 0 ; for ( let i = 0 ; i < nums . length ; i ++ ) { if ( nums [ i ] === val ) { nums . splice ( i , 1 ); i -- ; } else { k ++ ; } } return k ; }; We begin by initializing a variable k to 0. We then enter the for loop. The condition is standard: create a variable i initialized to 0, continue looping while i is less than nums.length to avoid going past the end of the array, and increment by 1 each time through. Each iteration checks one condition: whether nums[i] is equal to val . If true, we call .splice() on the array. The arguments we pass to splice are i and 1 . i is the index at which we want to start removing, and 1 tells splice to remove only that one element. We then decrement i . The reason for this took me some time to wrap my brain around, so I have included a visual below to make it concrete. The core issue is this: when splice removes an element, every element to the right shifts one index to the left. Without i-- , the loop would increment i on the next iteration and skip right over the element that just shifted in. i-- counteracts that by stepping i back, so after the loop increments it, i lands exactly where the shifted element now sits. If nums[i] !== val , we skip the splice and increment k instead. At the end we return k , which holds the count of elements remaining after all occurrences of val have been removed. Time complexity: O(n²)

2026-06-04 原文 →
AI 资讯

Cloudflare Turnstile in Playwright: Why Your Tests Stall and How to Solve It in 8 Lines

Cloudflare Turnstile in Playwright: Why Your Tests Stall and How to Solve It in 8 Lines If you're running Playwright or Selenium against any site behind Cloudflare, you've already met Turnstile. It's the new "managed challenge" widget Cloudflare started shipping in 2023, and it now appears in front of login flows, contact forms, signup pages, and increasingly the entire site root. Here's the part most teams miss: Turnstile doesn't always show a checkbox. A lot of the time it just sits invisible, runs its scoring loop, and either issues a token silently or stalls forever. Your test doesn't crash. It just times out at the next page.click("button[type=submit]") . The CI log says "element not interactable." Nobody knows why. I work on CaptchaAI. I'm going to show you exactly what's happening, then drop in 8 lines that fix it. The real scenario You have a Playwright suite that runs every PR. One day a test starts failing on the signup flow. You re-run it. It fails again. Locally on your laptop it passes. On CI it doesn't. What's actually happening: Cloudflare flagged your CI runner's IP block (GitHub Actions, GitLab runners, Hetzner, OVH, DO — all of them are on Cloudflare's "elevated risk" list). Turnstile decides to switch from invisible mode to "managed challenge" mode. Now there's a widget in the DOM that needs a real token before the form submit will accept. Your test never interacted with the widget because last week it didn't exist. Why retries don't help The instinct is to add a retry: 2 and move on. Don't. Cloudflare's scoring is per-IP-per-fingerprint, and each retry from the same runner makes the next challenge harder, not easier. After ~3 attempts you'll get full block pages instead of the widget. The right move is to solve the widget once, inject the token, and submit normally — exactly what a human user does, just faster. How Turnstile actually issues a token The widget renders an iframe pointing at challenges.cloudflare.com . Inside the iframe it runs a fi

2026-06-04 原文 →
AI 资讯

F# vs C# 3 — Conclusions

What can I say. Anyone claiming that F# is good mostly for finance and data processing and C# for everything else, has probably never written a single line of practical F# code. In previous two parts of the article, I tried to demonstrate that with F# you can achieve the same goals as with C#, but with less verbose, repetitive, structural code. How it started. At some point, developers realized that global state with unrestricted data access causes many side effects, producing insecure, error-prone, and hard-to-maintain code as software grows larger. That is when the idea emerged to bring data and the code operating on it together into a single unit, restricting direct access to the unit’s internal state and making software more secure and predictable. This is how data encapsulation was born. Alongside encapsulation, abstraction was introduced — the process of hiding how behavior works. Encapsulation ( hiding data ) and abstraction ( hiding behavior ) remain two foundational pillars of Object-Oriented Programming. And that is how OOP has worked ever since — developers bring data and behavior together ( classes ) and define abstractions for them ( interfaces ). For example, for C# developers — including myself — this has become a daily routine. And we rarely question it, because OOP languages like C# leave us little choice but to structure code this way. But if you ask yourself whether this repetitive routine is always necessary, the answer is — no. You don’t need OOP concepts to build stateless, streamlined request–response, data-processing pipelines, because in such systems there is no long-lived state to hide and protect. You have a request, and almost immediately you have a response. After that, everything is gone. That is what I tried to demonstrate in the first two parts of this article by applying FP concepts. And even if you have a classical desktop application, you don’t always need to approach it in an OOP way. Functional programming handles side effects no

2026-06-03 原文 →
AI 资讯

Leetcode 150 | Day 1: Merge Sorted Array - Naive vs. Optimized

There's been no shortage of debate lately about whether grinding Leetcode still makes sense in the age of AI. I think it does. AI is a powerful tool, but it was built by humans; which means it inherited our strengths, our blind spots, and our biases. Leaning on it entirely without understanding what's happening under the hood is a risk. A mentor once told me: those who refuse to use AI are not hireable. But neither are those who rely on it entirely. Learning deeply is how you stay on the right side of that line. This is my journey into just that - learning deeply. Day 1 Leetcode 88: Merge Sorted Array This is an interesting problem. You begin with 4 pieces of data — 2 arrays and 2 integers: nums1 : a sorted array whose length equals nums1.length + nums2.length . The first m elements are valid numbers; the remaining indexes hold 0 s as placeholders. nums2 : a sorted array containing only valid numbers, with a length of n . m : the count of valid numbers in nums1. n : the count of valid numbers in nums2. The objective is to merge both arrays into sorted order in place . Since nums1 is already sized to hold every valid element from both arrays, it's where the final sorted result will live. Approach 1: Naive (Splice + Sort) This solution is 2 lines of code. That's it. It's a testament to how much ES6 advanced JavaScript. nums1 . splice ( m , n , ... nums2 ); nums1 . sort (( a , b ) => a - b ); Here's how it works. We start by calling .splice() on nums1. While .splice() has many use cases, here's what each argument is doing in this context: m : the index where we start deleting elements. Since m is the count of valid numbers in nums1, starting at index m puts us right at the first placeholder 0 — exactly where we want to be. n : the number of elements to delete. Since n equals the length of nums2, we're deleting exactly as many placeholders as we have values to insert. ...nums2 : the values we want to insert in place of the deleted elements. The ... is the spread operato

2026-06-02 原文 →