Reddit Programming – Telegram
Reddit Programming
211 subscribers
1.22K photos
125K links
I will send you newest post from subreddit /r/programming
Download Telegram
How to Design A Session
https://www.reddit.com/r/programming/comments/1p3uzvg/how_to_design_a_session/

<!-- SC_OFF -->Hi Programmers, I am not a programmer. However, I think the concept of a session is a universial concept. I think the benefit of deliberately designing session is to achieve a greater work-life-balance for many. In six high-intensity hours, you can achieve way more than in day-long slogs. How are you making sure that you create this contrast: Work hard, rest hard. Live long and prosper
Sascha <!-- SC_ON --> submitted by /u/FastSascha (https://www.reddit.com/user/FastSascha)
[link] (https://zettelkasten.de/posts/optimal-concentration-success-recipe/) [comments] (https://www.reddit.com/r/programming/comments/1p3uzvg/how_to_design_a_session/)
The Pocket Computer: How to Run Computational Workloads Without Cooking Your Phone
https://www.reddit.com/r/programming/comments/1p4273w/the_pocket_computer_how_to_run_computational/

<!-- SC_OFF -->I don't know about everyone else, but I didn't want to pay for a server, and didn't want to host one on my computer. I have a flagship phone; an S25+ with Snapdragon 8 and 12 GB RAM. It's ridiculous. I wanted to run intense computational coding on my phone, and didn't have a solution to keep my phone from overheating. So. I built one. This is non-rooted using sys-reads and Termux (found on F-Droid for sensor access) and Termux API (found on F-Droid), so you can keep your warranty. 🔥 It was a pretty technically challenging piece for me to make. I studied physics and wanted to apply it to mobile computing, but real life is messy, and the code quickly became equally complicated. I'm showing my final result, as well as the physics I used to make it, as well as providing a link to the code itself in case you want to see my problem solving methodology. The write up follows, and contains an additional section at the end with more in depth details of the physics I used. What my project does: Monitors core temperatures using sys reads and Termux API. It models thermal activity using Newton's Law of Cooling to predict thermal events before they happen and prevent Samsung's aggressive performance throttling at 42° C. Target audience: Developers who want to run an intensive server on an S25+ without rooting or melting their phone. Comparison: I haven't seen other predictive thermal modeling used on a phone before. The hardware is concrete and physics can be very good at modeling phone behavior in relation to workload patterns. Samsung itself uses a reactive and throttling system rather than predicting thermal events. Heat is continuous and temperature isn't an isolated event. I didn't want to pay for a server, and I was also interested in the idea of mobile computing. As my workload increased, I noticed my phone would have temperature problems and performance would degrade quickly. I studied physics and realized that the cores in my phone and the hardware components were perfect candidates for modeling with physics. By using a "thermal tank" where you know how much heat is going to be generated by various workloads through machine learning, you can predict thermal events before they happen and defer operations so that the 42° C thermal throttle limit is never reached. At this limit, Samsung aggressively throttles performance by about 50%, which can cause performance problems, which can generate more heat, and the spiral can get out of hand quickly. My solution is simple: never reach 42° C Physics-Based Thermal Prediction for Mobile Hardware - Validation Results Core claim: Newton's law of cooling works on phones. 0.58°C MAE over 152k predictions, 0.24°C for battery. Here's the data. THE PHYSICS Standard Newton's law: T(t) = T_amb + (T₀ - T_amb)·exp(-t/τ) + (P·R/k)·(1 - exp(-t/τ)) Measured thermal constants per zone on Samsung S25+ (Snapdragon 8 Elite): Battery: τ=210s, thermal mass 75 J/K (slow response) GPU: τ=95s, thermal mass 40 J/K MODEM: τ=80s, thermal mass 35 J/K CPU_LITTLE: τ=60s, thermal mass 40 J/K CPU_BIG: τ=50s, thermal mass 20 J/K These are from step response testing on actual hardware. Battery's 210s time constant means it lags—CPUs spike first during load changes. Sampling at 1Hz uniform, 30s prediction horizon. Single-file architecture because filesystem I/O creates thermal overhead on mobile. VALIDATION DATA 152,418 predictions over 6.25 hours continuous operation. Overall accuracy: Transient-filtered: 0.58°C MAE (95th percentile 2.25°C) Steady-state: 0.47°C MAE Raw data (all transients): 1.09°C MAE 96.5% within 5°C 3.5% transients during workload discontinuities Physics can't predict regime changes—expected limitation. Per-zone breakdown (transient-filtered, 21,774 predictions each): BATTERY: 0.24°C MAE (max error
2.19°C) MODEM: 0.75°C MAE (max error 4.84°C) CPU_LITTLE: 0.83°C MAE (max error 4.92°C) GPU: 0.84°C MAE (max error 4.78°C) CPU_BIG: 0.88°C MAE (max error 4.97°C) Battery hits 0.24°C which matters because Samsung throttles at 42°C. CPUs sit around 0.85°C, acceptable given fast thermal response. Velocity-dependent performance: Low velocity ( High velocity (>0.001°C/s): 1.72°C MAE, 76,209 predictions Low velocity: system behaves predictably. High velocity: thermal discontinuities break the model. Use CPU velocity >3.0°C/s as regime change detector instead of trusting physics during spikes. STRESS TEST RESULTS Max load with CPUs sustained at 95.4°C, 2,418 predictions over ~6 hours. Accuracy during max load: Raw (all predictions): 8.44°C MAE Transients (>5°C error): 32.7% of data Filtered ( Temperature ranges observed: CPU_LITTLE: peaked at 95.4°C CPU_BIG: peaked at 81.8°C GPU: peaked at 62.4°C Battery: stayed at 38.5°C System tracks recovery accurately once transients pass. Can't predict the workload spike itself—that's a physics limitation, not a bug. DESIGN CONSTRAINTS Mobile deployment running production workload (particle simulations + GIF encoding, 8 workers) on phone hardware. Variable thermal environments mean 10-70°C ambient range is operational reality. Single-file architecture (4,160 lines): Multiple module imports equal multiple filesystem reads equal thermal spikes. One file loads once, stays cached. Constraint-driven—the thermal monitoring system can't be thermally expensive. Dual-condition throttle: Battery temp prediction: 0.24°C MAE, catches sustained heating (τ=210s lag) CPU velocity >3.0°C/s: catches regime changes before physics fails Combined approach handles both slow battery heating and fast CPU spikes. BOTTOM LINE Physics works: 0.58°C MAE filtered 0.47°C steady-state 0.24°C battery (tight enough for Samsung's 42°C throttle) Can't predict discontinuities (3.5% transients) Recovers to 1.23°C MAE after spikes clear Constraint-driven engineering for mobile: single file, measured constants, dual-condition throttle. In-Depth Discussion: PHYSICS MODEL ARCHITECTURE The system combines multiple components to predict thermal behavior: THERMAL COUPLING HIERARCHY Components don't heat in isolation. They follow a coupling chain: CPU/GPU/Battery/Modem → Chassis (vapor chamber) → Ambient Air Each component uses chassis temperature as T_ref, not ambient. Chassis itself uses fitted ambient temperature. This captures real heat flow: die heat conducts to chassis, chassis radiates to air. ZONE-SPECIFIC PHYSICS ENGINE Each thermal zone solves Newton's law independently with measured constants: T(t) = T_chassis + (T₀ - T_chassis)·exp(-t/τ) + (PR/k)·(1 - exp(-t/τ)) The time constant τ determines response speed. Battery (τ=210s) responds slowly to power changes. CPUs (τ=50-60s) respond quickly. This creates prediction asymmetry: battery is most accurate, CPUs are harder. Battery gets simplified model since τ >> 30s horizon: ΔT ≈ (P/C)·Δt Linear approximation is accurate when exponential hasn't decayed significantly. POWER ESTIMATION System power from battery sensor: P_system = V_battery × |I_battery| / 10⁶ [sensor reports μA as "mA"] Subtract known loads: P_thermal = P_system - P_display(brightness) - P_modem(network_type) Distribute remaining power to CPU/GPU zones by velocity ratios: P_zone = P_thermal × (v_zone / Σv_active_zones) Zones heating faster get more power allocation. When all velocities near zero, use typical distribution (CPU_BIG 40%, CPU_LITTLE 50%, GPU 10%). AMBIENT TEMPERATURE FITTING Can't directly measure ambient. Fit from system state using battery-to-coolest delta: T_ambient = T_battery - offset(charging_state, battery_delta) Offset ranges 2-8°C depending on whether charging (heat generation) or discharging (heat dissipation). Battery's high thermal mass makes it stable reference point. VELOCITY CALCULATION Linear regression over last 10 samples per zone: v = ΔT/Δt [°C/s] Used for: - Power
distribution (which zones are heating) - Regime change detection (velocity >3.0°C/s triggers throttle) - Confidence scaling (high velocity = lower confidence) DUAL-CONFIDENCE PREDICTION Each prediction gets two confidence scores: Physics confidence: Based on time constant relative to horizon - Battery (τ=210s >> 30s): confidence = 0.95 - CPUs (τ=50-60s > 30s): confidence = 0.70-0.75 - Longer τ relative to horizon = more accurate prediction Sample-size confidence: Based on history depth - confidence = min(1.0, n_samples / 60) - Ramps from 0 to 1 over first minute Final confidence = physics × sample_size × 0.5 [safety factor] THROTTLE DECISION LOGIC Two independent conditions OR together: Condition 1 - Battery temperature: if T_battery_predicted ≥ 38.5°C: throttle = True Condition 2 - CPU velocity: if v_cpu_big > 3.0°C/s OR v_cpu_little > 3.0°C/s: throttle = True Battery catches sustained heating (responds over minutes). Velocity catches regime changes (responds in seconds). Combined system handles both slow and fast thermal events. OBSERVED PEAK FALLBACK When zone temperature ≥ throttle_start temperature, physics breaks down because throttling changes power assumption mid-flight. Switch to empirical prediction: if T_zone ≥ T_throttle_start: T_predicted = T_observed_peak [from validation data] Example: CPU_BIG at 50°C predicts 81°C peak instead of using Newton's law. Avoids catastrophic under-prediction during throttled operation. COMPONENT INTERACTION Telemetry reads 7 zones at 1Hz Ambient estimator fits T_ambient from battery/chassis delta Power estimator calculates P_thermal from battery current minus known loads Velocity calculator does linear regression on recent samples Physics engine solves Newton's law per zone using chassis as T_ref If zone is throttled, override with observed peak Confidence calculator weights prediction by τ and sample history Throttle logic checks battery prediction and CPU velocities Return prediction with confidence and throttle decision The system is hierarchical: ambient → chassis → components. Power flows down from battery measurement. Predictions flow up from per-zone physics. Throttle decision combines slow (battery) and fast (velocity) signals to catch both failure modes. Phew. Physics. And stuff. <!-- SC_ON --> submitted by /u/DaSettingsPNGN (https://www.reddit.com/user/DaSettingsPNGN)
[link] (https://github.com/DaSettingsPNGN/S25_THERMAL-) [comments] (https://www.reddit.com/r/programming/comments/1p4273w/the_pocket_computer_how_to_run_computational/)
Day 121: Building Linux System Log Collectors
https://www.reddit.com/r/programming/comments/1p4jf18/day_121_building_linux_system_log_collectors/

<!-- SC_OFF --> JSON Schema validation engine with fast-fail semantics and detailed error reporting Structured log pipeline processing 50K+ JSON events/second with zero data loss Multi-tier caching strategy reducing validation overhead by 85% Dead letter queue pattern for malformed messages with automatic retry logic Schema evolution framework supporting backward-compatible field additions System Design Deep Dive: Five Patterns for Reliable Structured Data Pattern 1: Producer-Side Schema Validation (Fail-Fast) The Trade-off: Validate at producer vs. consumer vs. both ends? Most systems validate at the consumer—this is a mistake. By the time invalid JSON reaches Kafka, you’ve wasted network bandwidth, storage, and processing cycles. Worse, Kafka replication amplifies the problem 3x (leader + 2 replicas). The Solution: Validate at the producer with a three-tier approach: Fast syntactic validation (is this JSON?)—100µs avg latency Schema conformance check (matches expected structure?)—500µs with cached schemas Business rule validation (timestamp not in future?)—200µs Dropbox uses this pattern to reject 3% of incoming logs before they hit Kafka, saving 12TB of storage daily. The key insight: failed validations are cheap at the edge, expensive in the core. Anti-pattern Warning: Don’t validate synchronously on the request path. Use async validation with immediate acknowledgment, then route failures to a dead letter queue. Otherwise, a schema validation bug can bring down your entire API. https://sdcourse.substack.com/p/day-15-json-support-for-structured-8ba https://github.com/sysdr/course/tree/main/day121/linux-log-collector https://systemdr.substack.com/ <!-- SC_ON --> submitted by /u/Extra_Ear_10 (https://www.reddit.com/user/Extra_Ear_10)
[link] (https://sdcourse.substack.com/p/day-121-building-linux-system-log) [comments] (https://www.reddit.com/r/programming/comments/1p4jf18/day_121_building_linux_system_log_collectors/)
Floodfill algorithm in Python with interactive demos
https://www.reddit.com/r/programming/comments/1p4no76/floodfill_algorithm_in_python_with_interactive/

<!-- SC_OFF -->I wrote this tutorial because I've always liked graph-related algorithms and I wanted to try my hand at writing something with interactive demos. This article teaches you how to implement and use the floodfill algorithm and includes interactive demos to: - use floodfill to colour regions in an image - step through the general floodfill algorithm step by step, with annotations of what the algorithm is doing - applying floodfill in a grid with obstacles to see how the starting point affects the process - use floodfill to count the number of disconnected regions in a grid - use a modified version of floodfill to simulate the fluid spreading over a surface with obstacles I know the internet can be relentless but I'm really looking forward to everyone's comments and suggestions, since I love interactive articles and I hope to be able to create more of these in the future. Happy reading and let me know what you think! The article: https://mathspp.com/blog/floodfill-algorithm-in-python <!-- SC_ON --> submitted by /u/RojerGS (https://www.reddit.com/user/RojerGS)
[link] (https://mathspp.com/blog/floodfill-algorithm-in-python) [comments] (https://www.reddit.com/r/programming/comments/1p4no76/floodfill_algorithm_in_python_with_interactive/)
Looking for partnership to create multiple micro-SaaS (trial and error, no attachment)
https://www.reddit.com/r/programming/comments/1p4pg4i/looking_for_partnership_to_create_multiple/

<!-- SC_OFF -->Hey guys! I'm a backend developer (Java and Python) and I recently launched a saas that ended up not getting any users. Instead of getting discouraged, I'm trying to regain the desire to test new ideas, without getting too attached to each project (as I did in the last one that I failed) so that the process is light and we can learn quickly with each attempt. The journey alone is very complicated, it's difficult to maintain motivation, focus and speed when you do everything alone, apart from the lack of time to study and keep the system progressing... That's why I'm looking for someone (or some people) to form a pair or small team. The idea is simple: test several microsaas or complete saas ideas, validate quickly, discard without drama and continue. You can be frontend, backend, mobile, designer, marketing… any area that can help. The important thing is to have a real desire to create, launch and test. If you are interested, comment here or send me a DM and we can exchange ideas ;) <!-- SC_ON --> submitted by /u/renanaq (https://www.reddit.com/user/renanaq)
[link] (https://inspiras.me/) [comments] (https://www.reddit.com/r/programming/comments/1p4pg4i/looking_for_partnership_to_create_multiple/)
Alerts: You need a budget!
https://www.reddit.com/r/programming/comments/1p4uvhw/alerts_you_need_a_budget/

<!-- SC_OFF -->No matter the company, the domain, or the culture, I hear devops people complain about alert fatigue. This is not strange. Our work can be demanding and alerts can be a big cause of that "demand". What is strange, in my view, is that there is a general sense of defeatism when it comes to dealing with alert fatigue. Maybe some quick initiative here and there to clean up this or that. But status quo always returns. We have no structural solutions (that I've seen).
So let me try my hand at proposing a simple idea: budgeting. <!-- SC_ON --> submitted by /u/IEavan (https://www.reddit.com/user/IEavan)
[link] (https://eavan.blog/posts/alert-budgeting.html) [comments] (https://www.reddit.com/r/programming/comments/1p4uvhw/alerts_you_need_a_budget/)
Human Capital Management Software (HCM): Why Modern Businesses Can’t Survive Without It in 2025
https://www.reddit.com/r/programming/comments/1p5a6v3/human_capital_management_software_hcm_why_modern/

<!-- SC_OFF -->In 2025, HR operations have officially moved beyond spreadsheets and traditional HRMS tools. Hybrid work, compliance pressure, rapid hiring cycles, and AI-driven workforce analytics are pushing companies toward smarter automation. I put together a complete guide covering: What HCM software actually is Why companies are switching from HRM to HCM Core modules every modern HCM must have How AI is transforming recruitment, performance, and employee engagement Development cost breakdown (basic → advanced AI systems) Why custom HCM is becoming the preferred choice over ready-made tools When to build vs. buy Examples of modern HCM capabilities If you're in HR, tech, software development, or building SaaS products — this guide will give you a clear understanding of how HCM is evolving and why it matters. 👉 Read the full guide : Click on the Link Would love to hear feedback from SaaS founders, HR managers, and dev teams using HCM or building something similar. <!-- SC_ON --> submitted by /u/Big-Click2648 (https://www.reddit.com/user/Big-Click2648)
[link] (https://codevian.com/blog/modern-hcm-software-guide/) [comments] (https://www.reddit.com/r/programming/comments/1p5a6v3/human_capital_management_software_hcm_why_modern/)
Why "Start Simple" Should Be Your Default in the AI-Assisted Development Era
https://www.reddit.com/r/programming/comments/1p5b0z3/why_start_simple_should_be_your_default_in_the/

<!-- SC_OFF -->A case for resisting over-engineered AI-generated architectures and instead beginning projects with the smallest viable design. Simple, explicit code provides tighter threat surfaces, faster debugging, and far fewer hidden abstractions that developers only partially understand. Before letting AI optimize anything, build the clear, boring version first so you know what the system actually does and can reason about it when things break. <!-- SC_ON --> submitted by /u/AWildMonomAppears (https://www.reddit.com/user/AWildMonomAppears)
[link] (https://practicalsecurity.substack.com/p/why-starting-simple-is-your-secret) [comments] (https://www.reddit.com/r/programming/comments/1p5b0z3/why_start_simple_should_be_your_default_in_the/)