标签：#programming

You have a Java application, and now you need it to do something Java is awkward at. Maybe you want to let users script your app without recompiling it. Maybe you want to change a piece of business logic without a full redeploy. Maybe you just want to run a quick, throwaway script and not stand up a whole build. Java is a phenomenal language and runtime, but these are the edges where it starts to feel heavy. That is exactly the space Aussom is built for. I started using Java almost 20 years ago and have loved every bit of it. I'm proud of all the recent momentum in the Java space and I hope it continues. Java does so much so well. But every great tool has an edge where it stops being the right one, and reaching for another language there isn't a betrayal of Java. It's how the best ecosystems work. A useful comparison: C and Python Look at C. C is clearly important. Even after a lifetime of use it's still the foundation for new projects today, and new competitors such as Rust haven't been able to meaningfully displace it. C is fast and powerful on its own, but it isn't great for simple tasks. It's poor for throwaway code and quick scripts, it isn't very portable, and it hands you plenty of footguns. It's also a poor choice when you want to offer a scripting interface. Enter Python. Python is everywhere today because the barrier to entry is so low and it's genuinely useful. But Python leans on C. It's written in C, and much of its power comes from existing C libraries, whether they're UI frameworks, AI inference engines, or anything in between. C is efficient but poor at simple dynamic work; Python is dynamic and simple but poor at raw power and efficiency. Neither replaced the other. They endure together because they complement each other's weaknesses. That is the case I make for Aussom. Aussom is to Java as Python is to C. It doesn't compete with Java, it complements it. What makes Aussom different from other JVM languages This is where Aussom parts ways with most o

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

I remember being at an advisory board of big tech in 2023, close to the starting point of code generation with LLMs. Like everyone else, I was amazed. People were copying and pasting generated code, experimenting with prompts, and imagining a future where AI could become every developer's pair programmer. I was excited too. But I remember having a completely different question. Not: -"Will AI write code?" Instead, I kept wondering: -Why are we still writing code at all? Not because I think programming is going away. Not because programmers won't be needed.And certainly not because programming languages are somehow "wrong." It was a much simpler question. Programming languages have always existed to bridge a gap between humans and machines. Humans think in goals, ideas, and intentions. Machines execute deterministic operations. Programming languages became the interface between those two worlds. For decades, we've improved that interface. Assembly became higher level languages. Higher level languages became frameworks. Frameworks became libraries and abstractions that let us think less about implementation and more about solving problems. Then large language models arrived. Suddenly, we could describe what we wanted in plain language. But instead of questioning the interface itself, we mostly asked AI to become incredibly good at translating our intentions into programming languages. Today, our workflow looks something like this: Human intent - LLM - Programming language - Compiler / Runtime -Machine execution And every time I look at this pipeline, I find myself asking the same question I had back then. -Are we optimizing the wrong layer? Maybe the question isn't "Can AI write code?" Maybe the question is: -Do programming languages still need to be the primary interface between humans and computers? This isn't an entirely new idea.Researchers have explored concepts like Intentional Programming, where software is represented by its intent rather than by a specific pr

Okay so. We need to talk about classes. If you've been following along with this series, you're...

I host a Postgres podcast, and I recently recorded a conversation with Panos Antonopoulos, a Distinguished Engineer at Microsoft who spent 13 years working on SQL Server before moving onto Postgres and HorizonDB. Panos told me that at a high level, Postgres felt very familiar as he started to work on it, that the concepts are very similar. Transactions, storage, & more—the fundamentals transfer surprisingly well. We also covered: The cleanliness of the Postgres codebase. How LLMs are making it easier to digest years of Postgres design discussions that are publicly available on the mailing lists. Why Postgres has become the default answer for so many workloads, and why more people seem to be asking, "Why not Postgres?" Shared-storage architectures and some of the work he's doing in Azure HorizonDB. One quote that stuck with me: "That was a shocking experience for me. I could understand new areas in Postgres much faster than I could for SQL." For people who have worked across multiple database systems (Oracle, SQL Server, MySQL, Postgres, etc.), I'm curious whether you've had a similar experience—or a completely different one. Podcast/transcript here if anyone is interested: https://talkingpostgres.com/episodes/working-on-postgres-after-13-years-on-sql-server-with-panagiotis-antonopoulos submitted by /u/clairegiordano [link] [留言]

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

What a One-Line CSS Fix Taught Me About Code Review (My First Firefox Patch Feedback Loop) When I started contributing to Firefox through Outreachy, I expected the hard part to be writing code. What actually taught me the most was a two-line CSS fix that a reviewer sent back — not because it was wrong, but because it wasn't quite right yet. Here's what happened with Bug 2026574 . The Bug In Firefox's Split View about:opentabs page, long strings in the search field were overflowing outside their container instead of wrapping. Visually, it broke the layout — text just spilled past its boundary instead of staying contained. My job: make the text wrap properly, without breaking anything else on the page. My First Attempt I went into moz-card.css and targeted the heading element directly: .moz-card-heading { overflow-wrap : break-word ; min-width : 0 ; } This worked, technically. The text wrapped. Locally, it looked fixed. I submitted the patch for review, feeling fairly confident — it was a small, contained change. The Feedback My reviewer, Tim Giles, came back with a better approach. Instead of targeting the heading specifically with two properties, he suggested applying a single, more precise rule to the parent .moz-card element: .moz-card { overflow-wrap : anywhere ; } overflow-wrap: anywhere is more aggressive than break-word — it allows breaks at any point when needed to prevent overflow, not just at existing break opportunities. And by moving it to .moz-card instead of just the heading, the fix covered the component more robustly instead of patching one specific element. It was a smaller diff. It solved the actual problem instead of the symptom I'd focused on. And it followed patterns already used elsewhere in the codebase. What I Actually Learned My first instinct, seeing feedback on a patch I thought was "done," was a small jolt of did I get this wrong? But that's not what was happening. Getting feedback on a first pass isn't failure — it's the normal shape of h

Seed7 is a GPL licensed open source programming language. It is given away for free and nobody from the development team gets any money from it. submitted by /u/ThomasMertes [link] [留言]

Today I accidentally became the maintainer of software that was already almost three decades old: reviving a 1990s Java utility to keep the last PAD submitter alive in 2026. I was looking for a way to submit my AI app RiverScript to old desktop software directories and ended up digging through the long-forgotten world of PAD files. There was one problem. The only batch submission tool I could find was a Java application that first appeared in the late 1990s. The last release was in 2017. It was written by Roedy Green of Canadian Mind Products — a software developer who passed away in 2023. He spent decades writing and freely distributing Java utilities, and maintaining the widely-read Java Glossary . Roedy Green also wrote How To Write Unmaintainable Code — a famous satirical guide about writing code nobody can maintain. So, Roedy, today the code you wrote almost three decades ago was maintained. The tool still did exactly what it was supposed to do. Thank you. It just had absolutely no idea the modern web existed. It happily produced URLs like http://https://riverscript.com instead of https://riverscript.com , disabled SNI globally (which was probably a perfectly reasonable workaround at some point), and couldn't cope with the fact that almost every website now redirects HTTP to HTTPS. So I dug through the legacy Java code, fixed the compatibility issues, and got it working again. I used it to submit my app to several software directories, then published the revived version on GitHub so anyone who still needs it can use it too. Maybe nobody will ever need it again. Maybe someone will. Either way, I'm happy this old thing works again. So today, the code of the man who wrote "How To Write Unmaintainable Code" is still being maintained even after he was gone. P.S. The public repository for Mini PAD Submitter 26.3 Revived — 2026 Community Fix is available and open to everyone. submitted by /u/Odd-Flamingo-6211 [link] [留言]

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

After the browser transfers a file, the server may still scan, transcode, extract metadata, or generate previews. The interface needs status updates, but the most fashionable real-time transport is not automatically the most reliable choice for an event guest on a mobile browser. Start with the update contract Define states and transitions before choosing transport: accepted -> queued -> processing -> ready accepted -> rejected processing -> processing_error Every status response should include a monotonically increasing version or timestamp. The client can ignore events older than the state it already knows. Polling is a strong baseline HTTP polling works through proxies, resumes naturally after a page wake, and is easy to cache and rate-limit. Use adaptive intervals: one second just after acceptance, then back off to several seconds when processing takes longer. const delay = Math . min ( 8000 , 1000 * 2 ** slowChecks ); Add jitter when many guests finish at the same time. Stop when the state is terminal, the page is gone, or a server-provided retry time says to wait longer. SSE fits one-way progress Server-Sent Events are attractive when the server only pushes status. The browser reconnects with a last-event ID, and the wire format is simple. But mobile networks and some intermediaries silently kill idle connections. Send occasional heartbeats and treat reconnection as normal. The reconnect handler must fetch current state because events may have been missed beyond the server replay window. Do not keep one SSE stream per file. Subscribe by guest session or album and filter authorized upload IDs on the server. WebSockets add more responsibility WebSockets make sense when the client also sends frequent commands over the same channel or when a host moderation console needs many rapid updates. For a guest waiting on two files, they add connection authentication, heartbeat, reconnect, replay, and load-balancer complexity without much user benefit. Never rely on the so

The trust proxy setting is an important concept in backend development, especially when implementing rate-limiting in our APIs. But deciding its accurate value depends heavily on our deployment topology. When we deploy our application in production, the client may not talk directly to our backend. There may be 1 or more proxies in between who forward the request to the next proxy or the backend server. Those proxies can be Load balancers, API gateways, reverse proxy like nginx or any custom service. So effectively, our request has to do some 'hops' over these proxies to reach backend. When we implement rate limiting in app to prevent the DOS attack, we generally intend this rate limit on the basis of client IP address. And this works fine when client request reaches our backend directly. But when we have multi-hop architecture, the simple setup won't work as expected. Because the most recent IP will be of the proxy and not the client. So all the traffic coming from different users will be considered from the single client(our own proxy) and thus there will be false positives as the rate limiting will trigger much often. In this scenario, we must tell our backend to ignore these extra hops(i.e. to trust our proxies). This is done by specifying trust proxy. If there is 1 proxy between client-server we set trust proxy to 1; if there are 2, or more, we set it accordingly. This will ensure our express app skips(trusts) these IPs, and accurately figures out actual client IP. The originating IP address of client is identified from 'X-Forwarded-For' header by the express app. But setting trust proxy is not that straightforward. The numerical value for trust proxy will not work in every case. If there are different paths from which our request reaches backend, there is a chance that the number of proxies may be different in each path. For example - internal vs external traffic: External(public) traffic: (Client -> Web Application Firewall -> Load balancer -> Reverse Proxy ->

Welcome to Day 5! Today we shift from volatile, temporary in-memory variables to persistent storage and application durability . You will learn how to interact safely with your operating system's file system, read/write structured industry data patterns, handle real-world operational crashes gracefully, and keep execution timelines documented using professional logging architectures. 💾 1. File Handling & pathlib 📄 Python's pathlib module treats file paths as smart object structures instead of plain text strings. This avoids bugs caused by differing slash directions across operating systems (Windows uses \ , while Mac/Linux use / ). Reading ( "r" ): Loads file contents into memory. Writing ( "w" ): Erases any existing file contents and writes a fresh payload from scratch. Appending ( "a" ): Targets the end of a file, adding fresh text without overwriting existing contents. 🌱 Easy Starter Example from pathlib import Path # Create a path reference pointing to a file in the current workspace directory file_path = Path ( " notes.txt " ) # Write text cleanly to a file space file_path . write_text ( " Hello from Day 5! " ) # Read data straight back into a string variable content = file_path . read_text () print ( content ) # Output: Hello from Day 5! 🏛️ Real-World Example: Multi-Platform System Telemetry Appender from pathlib import Path from datetime import datetime def log_system_status ( status_message : str ) -> None : # Resolve home folder pathways seamlessly across Windows, Mac, or Linux systems target_dir = Path . home () / " app_workspace " / " telemetry " # Create the directory chain automatically if it doesn't exist yet target_dir . mkdir ( parents = True , exist_ok = True ) log_file = target_dir / " runtime_events.log " timestamp = datetime . now (). isoformat () # Secure stream channel using Python's standard file-open context manager with open ( log_file , mode = " a " , encoding = " utf-8 " ) as file : file . write ( f " [ { timestamp } ] STATUS: { status_mes

Event uploads fail differently from normal office uploads. A wedding guest may move between venue Wi-Fi and mobile data, lock the phone while a video is transferring, or close the browser as soon as the progress bar reaches 100%. Hundreds of devices can share one access point, and users rarely wait around to diagnose an error. The usual POST request plus optimistic success toast is not enough. A reliable browser flow needs a small protocol that distinguishes local preparation, network transfer, server acceptance, media processing, and final availability. This article describes a platform-neutral design for that protocol. The five states users actually experience Model each file as a durable state machine: selected -> preparing -> transferring -> accepted -> processing -> ready Add terminal or recoverable branches: preparing -> rejected_local transferring -> paused | retryable_error | expired accepted -> processing_error processing -> ready | processing_error The key distinction is between transferring and accepted . The browser may have sent every byte while the server has not yet committed the upload. Showing “done” at that boundary creates the most frustrating failure: the guest deletes the original, but the organizer never receives it. Give every file a client-generated identity Create an upload ID before the first network request. A UUID is sufficient when combined with the event identifier: const uploadId = crypto . randomUUID (); const uploadIntent = { uploadId , eventId , name : file . name , size : file . size , type : file . type , lastModified : file . lastModified , }; Send that identity when creating the server-side upload session. If the browser retries after a timeout, the server returns the existing session instead of creating a duplicate. This is idempotency at the workflow level. A guest can tap “retry” without having to understand whether the first request reached the server. Separate the control plane from file bytes Use a small JSON API for sessi

submitted by /u/Comfortable-Fan-580 [link] [留言]

Toss out a brick to lure a jade gem. — The 36 Stratagems, Throw Out a Brick to Get a...

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

How Bifrost Enterprise combines Data Access Control (DAC), Role Based Access Control (RBAC), Access Profiles, and Bifrost Edge to secure AI applications at scale. Artificial intelligence is quickly becoming part of every employee's workflow. Developers rely on coding assistants, customer support teams use AI powered chat applications, analysts generate reports with large language models, and organisations increasingly deploy AI agents connected to internal tools through the Model Context Protocol (MCP). While this rapid adoption improves productivity, it also introduces a significant governance challenge. It's no longer enough to decide who can log into an AI platform; you must also determine who can access specific AI resources, which models they can use, what they can spend, and which data they should even be able to see. This is where Bifrost Enterprise provides a comprehensive governance layer. By combining Role Based Access Control (RBAC), Data Access Control (DAC) , Access Profiles , and Bifrost Edge , organisations can secure AI workloads without slowing down innovation. Together, these capabilities create a governance framework that scales from small engineering teams to global enterprises and you can learn more about this in the documentation on GitHub . Why Enterprise AI Needs More Than Authentication Traditional enterprise applications typically answer two questions: Who is the user? What can that user do? Modern AI platforms introduce a third and equally important question: What information should this user actually be able to see? Imagine an organisation with several engineering teams working on independent AI products. Each team has its own prompts, routing rules, API budgets, virtual keys, observability data, and model configurations. If every developer can view every configuration simply because they have developer permissions, sensitive information can easily become exposed. This challenge becomes even more complicated when organisations begin deplo

Why giant AGENTS.md files may be wasting context, hurting maintainability, and making AI-assisted development harder to scale. A few years ago, for many developers, using AI for software development meant copying a small piece of code into a chat window. We would ask for a refactoring, copy the response back into the editor, run the tests ourselves, and return to the chat when something failed. Coding agents changed that workflow. Tools such as Codex, Claude Code, and others can now explore an entire repository, modify multiple files, execute commands, run tests, and iterate on failures. Coding agents turned code assistants into tools capable of executing multi-step software development tasks. But most repositories were not designed for this new kind of contributor. The repository became part of the agent's working context A coding agent needs much more than source code. It may need to understand: the project architecture; dependency boundaries; coding conventions; test strategy; build commands; local environment requirements; validation steps; security restrictions; the definition of done. A common solution is to place these instructions inside files such as AGENTS.md , CLAUDE.md , or other agent-specific configuration files. This works. I have been doing something similar in my own projects for a while. But as the repository grows, the instruction file grows with it. Eventually, a single file may contain thousands of lines covering unrelated concerns: Architecture Testing Environment setup Coding standards Infrastructure UI conventions Validation Release workflows Definition of done At that point, the file is no longer just a set of agent instructions. It has become an informal repository operating manual. The monolithic context problem A large AGENTS.md has an obvious advantage: the agent knows where to find it. But it also creates several problems. It is difficult for humans to navigate These files are not only for agents. Developers also need to read, review, m

Ken Thompson — คนที่เขียนระบบปฏิบัติการใน 3 สัปดาห์ ปี 1969 เคน ทอมป์สัน อายุ 26 เป็นวิศวกรที่ Bell Labs เขากับทีมเพิ่งเสียโปรเจกต์ Multics ซึ่งเป็นระบบปฏิบัติการที่ซับซ้อนเกินไปจนถูกยกเลิก Bell Labs ถอนตัว ทีมแตก โปรเจกต์ตาย เคนมีเวลาเหลือเฟือ และมี PDP-7 ซึ่งเป็นคอมพิวเตอร์เก่าที่แทบไม่มีใครใช้ ใน 3 สัปดาห์ เขาเขียน Unix kernel, shell, editor, และ assembler ขึ้นมาบน PDP-7 — ทั้งหมดเป็น assembly — ภาษา B ยังไม่เกิดตอนนั้น B ถูกสร้างขึ้นหลังจากนั้น — เพื่อใช้เขียน utility ต่าง ๆ แทน assembly — และนี่คือจุดเริ่มต้นของสายภาษา B → C → Go ภาษา B — เกิดหลัง Unix เวอร์ชันแรก Unix เวอร์ชันแรกสุด — สิงหาคม 1969 — เป็น assembly ล้วน หลังจากนั้นไม่นาน Ken ก็เริ่มสร้าง B — โดยตัดทอนมาจาก BCPL — เพื่อให้มีภาษาระดับสูงไว้เขียน tools โดยไม่ต้องใช้ assembly ทั้งหมด B มาจาก BCPL (Basic Combined Programming Language) ซึ่งพัฒนาโดย Martin Richards ที่ Cambridge ในปี 1966 BCPL เป็นภาษาที่ไม่มี type — ทุกอย่างคือ word — และออกแบบมาให้ compiler พกพาง่าย Ken เอา BCPL มาตัดทุกอย่างที่ไม่จำเป็นออก — จนเหลือภาษาเล็กมากที่ทำงานได้บน PDP-7 ซึ่งมี RAM แค่ 4K words PDP-7 Assembly → Unix v1 (1969, 3 สัปดาห์) ↓ BCPL (Richards, 1966) ↓ ตัด feature, ลดขนาด B (Thompson, 1969-1970) ↓ ใช้ rewrite Unix utilities (ไม่ใช่ kernel) ↓ ↓ เพิ่ม type system, struct, portability C (Ritchie, 1972) ↓ Unix v4 rewrite ด้วย C (1973) B ไม่มี type system ไม่มีโครงสร้างข้อมูล มีแค่ word — เหมือนกับว่าเป็น BCPL เวอร์ชัน minimal B ถูกใช้เขียน shell, utilities, และ tools ต่าง ๆ ของ Unix — แต่ kernel ยังเป็น assembly อยู่ จนกระทั่ง Dennis Ritchie สร้าง C ขึ้นมาในปี 1972 ทำไมต้อง B PDP-7 มี assembly แต่นั่นไม่ใช่เหตุผลที่ดีพอที่จะใช้มัน Ken ไม่เชื่อในการเขียน OS ด้วย assembly ทั้งระบบ — assembly เร็วแต่เขียนช้า แก้ยาก พกพาไม่ได้ การใช้ภาษาระดับสูง (แม้จะสูงนิดเดียวแบบ B) ทำให้: เขียน shell, utilities เร็วขึ้นมาก แก้ไขง่าย — ไม่ต้องเขียนใหม่เวลาย้ายเครื่อง ใช้คนน้อยลง — Unix version แรกเขียนโดย 2 คน จาก B → C → Unix → ทุกอย่าง เมื่อทีมได้ PDP-11 ซึ่งเป็นเครื่องที่ใหญ่กว่า — B เริ่มมีปัญหา PDP-11 มี byte-addressing แต่ B ออกแบ