标签：#programming

I have released version 2026-07-11 of Seed7 . Seed7 is about portability , maintainability , performance and memory safety . There is an automatic memory management without a garbage collection process (which might stop the world). The templates / generics don't need syntax with angle brackets. Seed7 is an extensible programming language. The syntax and semantics of the language is not hard-coded in the compiler but defined in libraries. Seed7 checks for integer overflow . You either get the correct result or an OVERFLOW_ERROR is raised. Unlike Java Seed7 compiles to machine code ahead of time (GRAAL works ahead of time but it struggles with reflection). Unlike Java Seed7 operators can be overloaded . Unlike C, C++, Go, Zig, Odin, Nim and C3 Seed7 is a memory safe language. The standard libraries cover many application areas. Example programs are: make7 , bas7 , pv7 , tar7 , ftp7 , comanche and many more. This release consists of 1029 commits from several contributors (thanks to them). Notable changes in this release are: Many improvements have been triggered by the Seed7 community. Support for the PCX image file format has been added and the support for BMP , TGA , JPEG and TIFF has been improved. Protections against stack overflow and shell injection have been added. Checks for the result and the parameters of primitive actions have been added. Several database drivers have been improved. A detailed change log can be found at r/seed7 or GitHub . This release is available at GitHub and SF . There is also a Seed7 installer for windows , which downloads the newest version from GitHub and SF. The Seed7 Homepage is now at https://seed7.net . There is a demo page with Seed7 programs compiled to JavaScript/WebAssemly. Please let me know what you think, and consider starring the project on GitHub, thanks! submitted by /u/ThomasMertes [link] [留言]

Introduction A Continuation of Shadow SCADA Terminal Velocity begins where Shadow SCADA left off — at the edge where digital audits meet the physical world. In the previous article, we explored how hidden infrastructures reveal themselves through aerial recon, magnetic anomalies, and environmental signals. Now we move deeper: into the physics of sensing, the light‑based pathways of diodes and photodiodes, and the high‑spec tools that transform invisible signals into readable intelligence. Modern audits are no longer limited to dashboards and logs. They extend into light, magnetic fields, environmental distortions, and sensor‑level truth — domains that traditional processes never touch. Section 1 – Diodes and Photodiodes: The First Gate of Physical Signals In modern audits, everything starts at the physical layer — where electricity and light move before any software or dashboard exists. Two tiny components sit at that gate: diodes and photodiodes. They look similar, but they do very different jobs. What is a diode? · One‑way valve for electricity: A diode lets electric current pass in one direction only, like a one‑way street. · Why this matters for security: Diodes are used to make sure information can leave a system but cannot come back in through the same path (for example, in SCADA or critical networks). · Simple image: Think of a diode as a door that only opens outward. You can exit, but nobody can enter through that door. What is a photodiode? · Sensor for light: A photodiode doesn’t control current—it detects light and turns that light into an electrical signal. · Where it’s used: In cameras, light sensors, security systems, and tools that “listen” to the environment through light. · Simple image: Think of a photodiode as a tiny eye that sees light and tells the system, “Something is shining here.” The key difference (in one sentence) · Diode = controls flow. · Photodiode = senses light. Diodes are about blocking or allowing. Photodiodes are about seeing and

submitted by /u/fagnerbrack [link] [留言]

I wanted to make this post because man...tables are way harder than they look. I documented my 1 year journey of optimizations on a stupid table for my Database GUI. I made everything from scratch like an idiot thinking it'd be easy but oh boy was I wrong... The article goes over all the optimizations I made to make my table render data smoothly without lagging. It goes from what data structures I used and the rendering optimizations I did. I used MongoDB Compass as a baseline since they use AG-Grid for their table and I'm pretty happy that my table feels way smoother than that (In my own testing)! But yeah, I never realized that there would be so much depth in making a performant table. PS. I decided not to use AG-Grid because there were a lot of customizations that I needed to do. I wanted column expansions ( if a field as an object or an array it would open columns to the right of it ). I also wanted an embedded text search where you could search for text within non visible columns (because they were in objects or arrays ) and AG Grid didn't really support that behavior so ..yeah. Anyways have a good read! submitted by /u/Fun-Chicken6946 [link] [留言]

submitted by /u/DirtySpartan [link] [留言]

submitted by /u/_shadowbannedagain [link] [留言]

The label that gets the sequence backwards "AI-first" has become a branding exercise....

submitted by /u/fagnerbrack [link] [留言]

There are beginner mistakes. Then there are "I spent three days doing the wrong thing" mistakes. This is one of mine. When I first joined a company as a trainee, I was excited... and completely unprepared for real-world software development. Back in college, our web development classes mostly covered HTML and CSS. We did touch a bit of programming, but if I'm being honest, many of our projects involved copying code, tweaking a few lines, and hoping everything still worked. I graduated knowing how to make things look nice , but not necessarily how professional development teams solved problems. Reality hit pretty quickly. Our First Task A few days into training, my friend and I were assigned our first real task by our senior team lead. He gave us an Excel file. It had two sheets , each with roughly 1,000 rows of data. Every row had around 7 to 10 columns . Then he said something like: "Import all of this into the database." Simple enough... right? Well... Neither of us had ever imported data into a database before. Asking the Wrong Person Instead of asking our team lead for clarification, we asked another trainee who happened to be our former classmate. His advice? "Just make an INSERT INTO script." Perfect. Say no more. Without questioning it, my friend and I started generating SQL INSERT statements. One row. After another. After another. And another. By the end, we had spent almost three days creating what felt like an endless wall of SQL. At the time, we were actually proud of ourselves. "Look at us. Future software engineers." Looking back... We were basically expensive copy-paste machines. The Reality Check Our senior team lead eventually came over to check our progress. He looked at our SQL file for a few seconds. Then smiled and said: "You tricked me, huh? That's not what I meant." My friend and I just stared at him. Confused. We thought, "But... the data is going into the database. Mission accomplished, right?" Wrong. What he actually wanted was a CakePHP scr

Most data engines can answer a query. I wanted one that could also explain, offline and byte for byte, why that answer belongs to a specific durable state. That question led me to build Hyphae , an open-source data engine in Rust with a deliberately small operational footprint: one native binary; one data directory; no required database, cache, cloud service, embedding provider, or LLM; deterministic KV and structured queries; portable result proofs that can be verified offline. If you read my earlier post about provenance over prediction , this is the next and deliberately narrower step. That work began as a cognitive substrate and clarified the provenance thesis. I have since rebuilt Hyphae as a standalone data engine. The research lineage remains, but the current product does not need an AI stack to be useful. Hyphae 0.1.0 is now available on GitHub , through crates.io, and as signed multiplatform archives in the first public release . The problem was not another query syntax The usual path for an application data feature grows surprisingly quickly. A local library becomes a database service. Search adds another service. Caching adds another. Semantic retrieval adds a model provider. Soon, a feature that should be optional controls whether the application can start at all. There is a second problem hiding underneath that operational stack: a successful response is usually just an assertion from the system that produced it. If I receive a filtered, sorted, limited result, how do I check that: the underlying durable state was not corrupted; the query was executed with the declared semantics; matching rows were not silently omitted; the returned result is tied to the state I actually intended to trust? Checksums help with corruption. Signatures can identify a producer. Neither one, by itself, proves that an arbitrary query result is complete and was reexecuted correctly. Hyphae is my attempt to make those concerns part of the engine instead of application glue. What

submitted by /u/ScottContini [link] [留言]

submitted by /u/Blockpair [link] [留言]

submitted by /u/dabluck [link] [留言]

Ever felt like the Next.js App Router is a super cool superpower, but sometimes it feels like we accidentally left a few things behind during the setup? It happens to the best of us! Building with the App Router is incredibly powerful, giving us server first capabilities and an asik developer experience. Yet, with great power comes a few hidden quirks that often sneak past our radar until runtime. Let's dive deep and spot those common pitfalls together, making sure our Next.js apps run smoother than a freshly brewed cup of coffee. The Great Divide Understanding Client versus Server Components One of the biggest paradigm shifts with the App Router is the clear distinction between Client and Server Components. This isn't just a fancy label it dictates where your code runs and what it can access. Forgetting this fundamental difference is a top contender for unexpected errors. Server Components by Default We often forget that, by default, all components in the App Router are Server Components. This is awesome because it means zero client side JavaScript for many parts of our UI, leading to blazing fast initial loads and better SEO. Server Components can directly access server resources like databases, file systems, or environment variables without exposing them to the browser. They run once on the server, generate HTML, and send it to the client. When 'use client' Becomes Our Best Friend The 'use client' directive is like waving a flag saying, "Hey, this component needs to run in the browser!" We use it when a component relies on browser specific APIs like window or document , handles user interaction like click events, or uses React Hooks such as useState or useEffect . The common mistake here is forgetting to add 'use client' to components that need interactivity, leading to build errors or hydration mismatches when the server rendered HTML doesn't quite match what the client expects. We might also accidentally try to import a server side utility into a client compone

The Quest Begins (The "Why") I still remember the first time I walked out of a coding interview feeling like I’d just lost a lightsaber duel. The problem was a simple array‑rotation task, but I dove straight into typing, eyes glued to the screen, and barely said a word. When the interviewer asked, “What are you thinking right now?” I froze, mumbled something about “just trying to get it done,” and watched the seconds tick away. The feedback later? “Great coding skills, but we couldn’t follow your thought process.” That moment stung because I knew I could solve the problem—I just hadn’t learned how to show my thinking. After a few more silent attempts, I realized the interview isn’t a solo boss fight; it’s a co‑op mission where the interviewer wants to see how you navigate the terrain. If they can’t hear your internal monologue, they have no way to gauge your problem‑solving instincts, communication style, or ability to catch mistakes early. I went on a quest for a repeatable, low‑effort way to narrate my thinking without turning the interview into a monologue. What I found was a three‑step verbal framework that felt like unlocking a new Force power—simple, repeatable, and surprisingly effective. The Revelation (The Insight) The technique I now swear by is State → Plan → Execute . At each stage you say out loud exactly what you’re doing, using a tight, repeatable script. It’s not about over‑explaining; it’s about giving the interviewer a clear map of your mind. Here’s the exact wording I use, broken down by phase: State – Clarify the problem, assumptions, and constraints. “Okay, so we need to rotate an array to the right by k steps. I’m assuming k can be larger than the array length, so I’ll use modulo to normalize it. The array can contain any integers, and we should aim for O(n) time and O(1) extra space.” Plan – Outline the high‑level approach before writing a line of code. “My plan is to use the three‑step reversal algorithm: reverse the whole array, then reverse

When the enemy occupies favorable terrain, don't attack head-on. Let them think they're safe, let...

Disclaimer: NO AI bullshit here. We are in April 2024, I am working in Mexico City and a friend of mine contacts me. She is an architect and she works in Merida. Her and her colleague would like to have a solution to analyze architectural cadastral documents. She told me that she called friend for Mexico and USA and they all say it is impossible. Interested by the challenge I said: "Hold my beer" and I made a POC in 75h of intensive work. However, it was not enough. They had other requirements and getting to this was much more complicated. Complicated but still not impossible. As a Data Scientist, I started to develop a full solution (mostly Computer Vision) to read and analyze automatically specific cadastral documents. I decided to continue working on the project. Hours and hours. There was no money involved. Only challenge. Thanks to that I was able to do everything with the time I wanted. Putting all the passion in my side-project. With time the project grew and grew. But I was prepared for this. I made every part of the code separable, isolated. 6 repositories: aitt-core: core backend + Streamlit app -> Docker image deployment on ECR aitt-core-deploy: service deployment on the server via Ansible aitt-symbol-clf: ML + API -> Docker image deployment on ECR aitt-symbol-clf-deploy: service deployment on the server via Ansible 5 .aitt-infra: Terraform on AWS aitt-platform: Vue.js frontend (private repo) I finally came to a solution for what they needed in more than 625 hours of work. My work contract ended in 2025 in Mexico so I came back to France (I am French, yes I love pain - joke for bilingual). This project made me realized several things: I am capable of doing great things. We all are. The only thing that matters is discipline. This is not some sort of personal development bullshit. This is an advice for life. Einstein said: "I have no special talents. I am only passionately curious." Time is a powerful thing . With time and dedication you can achieve great t

submitted by /u/BrewedDoritos [link] [留言]

submitted by /u/geoffreyhuntley [link] [留言]

submitted by /u/ldelossa [link] [留言]