Day 19/60: Structured logging
Today's note was about making structured logging improve production behavior, not just local developer comfort. I kept coming back to the same checks: emit logs, config reads, and shutdown signals in a way that tells the real runtime story, make test seams deliberate so handlers and services can be checked without ceremony, and treat observability and operational hygiene as part of the product behavior, not as cleanup.…
Day 19/60: Sorting in JavaScript
Today's note was about keeping the ordering invariant visible so sorting in javascript is more than a library call. I kept coming back to the same checks: keep the sorted and unsorted regions explicit throughout the implementation, use slices and temporary buffers deliberately, and check what work each pass actually removes from the problem.
The failure mode worth watching is naming the sort correctly but losing the ordering invariant inside the loop.…
Day 19/60: Sorting in Rust
Today's note was about keeping the ordering invariant visible so sorting in rust is more than a library call. I kept coming back to the same checks: keep the sorted and unsorted regions explicit throughout the implementation, use borrowed slices and temporary buffers deliberately, and check what work each pass actually removes from the problem.
The failure mode worth watching is naming the sort correctly but losing the ordering invariant inside the loop.…
Day 19/75: Binary search on rotated arrays
Today's note was about protecting the search interval in binary search on rotated arrays so every bound update stays justified. I kept coming back to the same checks: state what the active interval still allows before the first loop iteration, move left and right only when the predicate proves one side is impossible, and test the smallest failing boundary because off-by-one errors hide there first.…
Day 19/365: String Manipulation.
Today was useful because string transformation stopped feeling ad hoc. Longest common prefix, compression, and encode/decode all came down to one shared skill: boundary management. I needed to know where agreement ends, where a run ends, or where one serialized item ends so the next one can begin.
That was the key shift. Once the boundary rule was explicit, the code became much easier to trust and much easier to explain.…
PSA for anyone implementing distributed rate limiting with Redis: INCR + EXPIRE has a race condition. If your process crashes between the INCR and the EXPIRE, that key lives forever and your counter never resets.
Use a Lua script or MULTI/EXEC pipeline to make the increment-and-expire atomic. Or use sorted sets with sliding window logs where each entry self-expires. Either way, test by killing processes mid-request.
#SRE #RateLimiting #Redis #ProductionEngineering #Programming #DevOps #Tech
AWS IAM with Terraform. Security infrastructure work gets calmer when the repo says exactly what changed, which boundary it touched, and where the evidence lives. I want Terraform resources for VPC boundaries, subnet placement, security group rules, instance profiles, encryption, and routing, not optimistic prose. That is the difference between reviewable IaC and drift that waits for incident day. #Terraform #Ansible #Iac #Cybersecurity Keep the state file, pipeline, and recovery path aligned.
Day 19/60: File upload vulnerabilities
Breaking down: Unrestricted file upload, extension bypass, content-type bypass.
Every day I get closer to thinking like a security engineer rather than just following procedures. Today's concepts pushed that shift forward.
#PenTesting #EthicalHacking #InfoSec #BugBounty #Security
On Day 19/60, I explored file upload vulnerabilities in penetration testing, covering Unrestricted file upload, extension bypass, content-type bypass, web shell deployment.
SSH hardening and automation. Bash security works when the script turns host drift and dangerous defaults across Linux systems into something another engineer can verify later. I want evidence from find, stat, chmod, sysctl, and baseline files under /etc, not a magical one-liner. Paths under /etc and /var/log should be obvious, errors should stay visible, and the output should survive copy-paste into a ticket or postmortem without losing context. #Bash #Linux #Cybersecurity #Infosec
Day 19/90: Windows scripting with Python
Built recon scripts using Python's direct access to Windows internals:
- WMI service enumeration to catch unquoted paths and SYSTEM-level services
- winreg autorun key inspection across HKLM and HKCU hives
- win32evtlog Security log parsing for failed logon clustering
- subprocess PowerShell calls with ConvertTo-Json for structured output
All of it runs without installing agents on the target host.
VLANs & trunking. Cybersecurity work gets calmer when the write-up says exactly what boundary changed, what artifact proved it, and what happens next. I want Windows and Linux commands, configuration files, packet views, auth headers, and event data that show what the system is really doing, not vague reassurance. #Cybersecurity #Infosec #Soc #Dfir Good security notes make the next action obvious. The useful lesson is the one you can defend with evidence.…
Day 19/90: Abstract classes & interfaces
Today's note was about using abstract classes & interfaces to make object boundaries and polymorphism easier to reason about. I kept coming back to the same checks: which type owns the invariant, where virtual dispatch is actually needed, and operator behavior that still reads like ordinary code.
The failure mode worth watching is using inheritance or interfaces before deciding which type actually owns the behavior.…
Day 19/90: Iterators and the Iterator trait
Today's note was about using iterators and the iterator trait to express shared behavior without making the type story fuzzy. I kept coming back to the same checks: behavior shared through traits, type constraints that explain intent, and generic helpers that stay readable at the call site.
The failure mode worth watching is adding generic or trait machinery before the shared behavior is clear.…
Day 19/90: File I/O
Today's note was about making file i/o explicit about data shape, encoding, and failure points. I kept coming back to the same checks: name the file, network, or serialization boundary before writing the code that crosses it, keep data shape and encoding format visible so corrupt input is easier to spot, and make cleanup, partial writes, and decode failures part of the design instead of lucky edge cases.…
Day 19/90: Async TypeScript
The useful shift today was making async state and failure explicit. I kept the lesson tied to three checks: decide which work can run in parallel and which work must stay sequenced, make loading and failure states explicit in the type model, and treat cancellation, retries, or backpressure as part of the design instead of afterthoughts.
The mistake worth catching early is treating async code as just syntax sugar and ignoring sequencing or failure propagation.…
Day 19/90: Iterators and generators
Today's note was about using iterators and generators to make object shape, prototype behavior, and method ownership easier to trust. I kept coming back to the same checks: who owns state and lookup behavior, call-site context or iterator contract, and abstractions that stay readable under reuse.
The failure mode worth watching is using classes, closures, or prototype tricks before deciding which object actually owns the state.…
Day 19/420: Datetime, time zones, and timestamps
Today's note was about turning datetime, time zones, and timestamps into something I can explain from the code instead of memorizing from a tutorial. I kept coming back to the same checks: data shapes that stay obvious at a glance, control flow that makes valid states visible, and small units of logic that remain easy to test.
The failure mode worth watching is letting convenience hide where state changes actually happen.…
Day 18/90: Defer, panic, and recover
Today's note was about treating defer, panic, and recover as part of the program contract instead of as cleanup code. I kept coming back to the same checks: decide what the caller should know about a failure before returning any error value, wrap context where it helps debugging and avoid turning every error into a brand new taxonomy, and keep the happy path readable while making the failure path honest about what can actually break.…
Day 18/90: Polymorphism and virtual methods
Today's note was about making polymorphism and virtual methods feel like clear data shaping and control flow instead of syntax trivia. I kept coming back to the same checks: clear value shapes, control flow that makes valid states obvious, and small methods with one reason to change.
The failure mode worth watching is using broad or vague types until the data model stops explaining itself.…
Day 18/90: Polymorphism
Today's note was about using polymorphism to make object boundaries and state transitions easier to trust. I kept coming back to the same checks: constructors that lock in valid state, type boundaries that explain ownership, and abstractions that remove duplication without hiding behavior.
The failure mode worth watching is using inheritance or interfaces before deciding which type actually owns the behavior.…
Day 18/90: Error handling with types
The useful shift today was making runtime truth match the types. I kept the lesson tied to three checks: validate unknown input at the edge and convert it to a typed shape once, write tests around the boundary that is easiest to misunderstand, not just the easiest function to call, and make failures explain which contract broke so debugging starts in the right place.…
Day 18/90: Error handling
Today's note was about making error handling feel like clear values, collections, and function boundaries instead of syntax trivia. I kept coming back to the same checks: errors with context attached, recoverable versus fatal boundaries, and logs that still explain the failing path.
The failure mode worth watching is leaning on coercion or mutation until the value flow stops explaining itself.…
Day 18/420: Useful standard library workflow
Today's note was about turning useful standard library workflow into something I can explain from the code instead of memorizing from a tutorial. I kept coming back to the same checks: data shapes that stay obvious at a glance, control flow that makes valid states visible, and small units of logic that remain easy to test.
The failure mode worth watching is letting convenience hide where state changes actually happen.…
Day 18/60: Testing with testify
Today's note was about making testing with testify improve production behavior, not just local developer comfort. I kept coming back to the same checks: emit logs, config reads, and shutdown signals in a way that tells the real runtime story, make test seams deliberate so handlers and services can be checked without ceremony, and treat observability and operational hygiene as part of the product behavior, not as cleanup.…
Day 18/60: Merge intervals
Today's note was about using a stable invariant so merge intervals feels like a process instead of a trick. I kept coming back to the same checks: name the exact window, prefix, or pointer region each variable owns, reuse prior work instead of recomputing the same range each iteration, and test boundary sizes first because they expose weak invariants quickly.
The failure mode worth watching is moving boundaries before stating what region they actually represent.…
Day 18/75: Binary search on answers
Today's note was about protecting the search interval in binary search on answers so every bound update stays justified. I kept coming back to the same checks: state what the active interval still allows before the first loop iteration, move left and right only when the predicate proves one side is impossible, and test the smallest failing boundary because off-by-one errors hide there first.…
Day 18/365: String Basics.
Today was useful because string work stopped feeling fuzzy. Reversal exposed character access clearly. Palindrome checks made normalization rules impossible to ignore. Anagram checks made frequency state feel natural. Character counting ended up looking like shared infrastructure for later string and sliding-window problems.
That was the key shift: string basics are really about deciding what the data means before scanning it.…
Day 18/60: Rate Limiting Algorithms
Dug into five rate limiting strategies and their production tradeoffs. Token bucket is the industry default because it handles burst traffic without degrading user experience. Leaky bucket smooths output for downstream services with strict throughput limits.
Fixed window has the boundary exploit. Sliding window counter fixes it by weighting the previous window count by overlap fraction. O(1) memory, no boundary problems.…
AWS S3 and CloudFront. Security infrastructure work gets calmer when the repo says exactly what changed, which boundary it touched, and where the evidence lives. I want Terraform resources for VPC boundaries, subnet placement, security group rules, instance profiles, encryption, and routing, not optimistic prose. That is the difference between reviewable IaC and drift that waits for incident day. #Terraform #Ansible #Iac #Cybersecurity Keep the state file, pipeline, and recovery path aligned.
Day 18 pentesting -- CSRF still hits harder than people expect.
The browser sends cookies automatically. That is the whole vulnerability. If `bank.com` processes `GET /transfer?to=X&amount=5000`, an attacker just needs:
```html
<img src="https://bank.com/transfer?to=attacker&amount=5000">
```
Victim visits the page, browser fires the request with their session cookie, money moves.
SameSite=Lax cookies fixed cross-origin POST attacks by default. But GET-based state changes? Still wide open.…
