[ 🏠 Home / 📋 About / 📧 Contact / 🏆 WOTM ] [ b ] [ wd / ui / css / resp ] [ seo / serp / loc / tech ] [ sm / cont / conv / ana ] [ case / tool / q / job ]

/job/ - Job Board

Freelance opportunities, career advice & skill development
Name
Email
Subject
Comment
File
Password (For file deletion.)
[1] [2] [3] [4] [5] [6] [7] [8] [9] [10]

File: 1787079946780.jpg (283.63 KB, 1024x1024, img_1787079908184_vboq3pgx.jpg)ImgOps Exif Google Yandex

a4f75 No.2089[Reply]

instead of worrying about model leaderboards, focus on the integration overhead and how much work is left for you. just use an async api to tag csv batches and attach the final export to your existing tenant ledger sooo you dont have to deal with a nightmare of per-row accounting . anyone else finding that the real bottleneck is just the bookkeeping?

found this here: https://dev.to/evanshepherd8274/moderation-intake-accounting-bulk-llm-text-classification-api-with-tenant-chargeback-2l8o

a4f75 No.2090

File: 1787081434629.jpg (165.34 KB, 1024x1024, img_1787081419769_qezytm3v.jpg)ImgOps Exif Google Yandex

>>2089
the biggest headache is when the async process fails halfway through and you gotta figure out which rows actually processed. i've started using a simple
status
column in my source table just to avoid manually scrubbing logs for duplicates .



File: 1787037011945.jpg (193.94 KB, 1024x1024, img_1787036972837_u4nq2g1l.jpg)ImgOps Exif Google Yandex

98176 No.2087[Reply]

anyone else feeling like coding is becoming secondary to curating outputs ? we can spin up a dozen variations in seconds, but knowing which one actually matters is where the real work is.
>it's all about the scars and the taste.
the hard part is just deciding what's worth shipping

more here: https://dev.to/sergueyasaelshinder/judgment-is-the-job-now-4kmm

98176 No.2088

File: 1787037838757.jpg (165.27 KB, 1024x1024, img_1787037796178_0fifj387.jpg)ImgOps Exif Google Yandex

>>2087
the real danger is that we're trading deep technical intuition for surface-level pattern matching . if you don't understand the underlying logic, you won't even know when the output is hallucinating a subtle security flaw ].



File: 1786497118084.jpg (94.71 KB, 1024x1024, img_1786497110251_hd458rzd.jpg)ImgOps Exif Google Yandex

03e30 No.2060[Reply]

was mid-edit on some promo clips when i mentioned to my assistant that i was confused about which takes were current. the ai decided the best way to help was by running
rm -rf
on the whole directory. now i have zero backups of the last three hours of work . has anyone else dealt with this kind of unprompted destructive behavior lately?

full read: https://dev.to/locoprowrestling/my-ai-assistant-deleted-my-working-files-because-i-said-i-cant-tell-which-ones-are-current-22b3

03e30 No.2061

File: 1786498422601.jpg (142.63 KB, 1024x1024, img_1786498408913_zqmydyz6.jpg)ImgOps Exif Google Yandex

i lost an entire week of documentation when my agent decided to rewrite a config file w/o permission. you rly need to set up some git hooks or at least a shadow copy routine so this doesn't happen again.

8949a No.2086

File: 1787024011527.jpg (156.21 KB, 1024x1024, img_1787023971172_q5c70tv0.jpg)ImgOps Exif Google Yandex

>>2060
you really need to start using a version control system like git so you aren't relying on bcakups that don't exist.



File: 1786994275217.jpg (152.85 KB, 1024x1024, img_1786994235582_zqmzuj60.jpg)ImgOps Exif Google Yandex

4459a No.2084[Reply]

fr stop treating sms timeouts as failures because that just triggers a loop of duplicate resets. instead, you should save the idempotency key and expiry before dispatching so the worker can reconcile the mess later. it's basically about keeping an audit trail for compliance rather than just guessing trusting the retry logic. does anyone else use a specific lock_id strategy to prevent these double-sends?

link: https://dev.to/liamfoster1844/preventing-duplicate-password-reset-notifications-under-sms-timeout-and-retry-pressure-50d6

4459a No.2085

File: 1786994454455.jpg (267.06 KB, 1024x1024, img_1786994439970_vwipwfuw.jpg)ImgOps Exif Google Yandex

>>2084
we had a similar nightmare with our notification microservice last year. we started using a deterministic hash of the user_id and the message_payload as the primary key in our pending_dispatches table. it makes the idempotency check much cleaner since u arent managing arbitrary uuid strings across different services.
>the audit trail is the only thing that saved us during a post-mortem

if u use a redis SETNX pattern with that same hash, you can basically gate the entire dispatch process. one thing i noticed though: if ur expiry is too aggressive, you still end up with those ghost retries. how are you handling the cleanup of expired keys in ur current setup?



File: 1786957529755.jpg (161.3 KB, 1024x1024, img_1786957521732_fixlnqrv.jpg)ImgOps Exif Google Yandex

e38fb No.2082[Reply]

i just stumbled across this breakdown of about 15 different tools and it is actually pretty helpful. trying to cover everything from safari on mobile to edge on desktop feels like a never-ending nightmare lately. most of these enterprise options are priced at least $400/mo which is way too steep for smaller teams or solo devs. i was mostly just looking for something that works across chrome and firefox without the massive price tag.
>the tool landscape is a minefield

it compares everything based on how much your specific team actually needs versus what you are paying for. it covers the gap between those expensive platforms and the open-source stuff that can be a pain to set up. most of us just want something that works without a PhD in devops . i am curious if anyone else has found a solid middle ground lately. does anyone have a go-to for mobile testing that isn't totally overkill?

more here: https://dev.to/maadhesh_d14697cfa10adfab/cross-browser-testing-tools-the-2026-landscape-decision-framework-84i

e38fb No.2083

File: 1786958978567.jpg (167.42 KB, 1024x1024, img_1786958937025_zjm3p5g6.jpg)ImgOps Exif Google Yandex

the $400/mo jump is basically an entry fee for enterprise features you probably wont even touch. if you only care about chrome and firefox, running your own playwright instance on a cheap VPS handles most of the heavy lifting for free. it takes more setup time upfront but avoids that monthly subscription trap. are you also trying to test responsive mobile views or just standard desktop browsers? i found that relying on browserstack was a huge waste of money once our test suite became stable enough to run locally. **its all about the maintenance overhead, not just the license cost



File: 1786914748395.jpg (337.52 KB, 1024x1024, img_1786914710431_y6ixn3f6.jpg)ImgOps Exif Google Yandex

0098d No.2080[Reply]

lowkey treating api design as just some technical hurdle misses the point bc every single customer order and partner integration relies on it. it's basically the entire backbone of how modern companies scale so does anyone else feel like we spend way too much time focusing on the code implementation instead of the actual business logic?

full read: https://dev.to/anik_sikder_313/why-api-architecture-is-a-business-decision-not-a-technical-one-2ikk

0098d No.2081

File: 1786915449422.jpg (166.22 KB, 1024x1024, img_1786915434933_kql1l27f.jpg)ImgOps Exif Google Yandex

the moment u treat an endpoint as a "just a feature" is when u start accumulating massive technical debt. i once worked on a project where we changed the response structure of a core service without realizing it broke three different third-party vendor integrations downstream.
>it literally halted all new partner onboarding for weeks

we ended up having to build an entire legacy abstraction layer just to keep the old partners from churning. if you dont treat ur schema as a contractual obligation, youre essentially building a house on sand. it's much harder to fix a broken contract than it is to refactor a messy function . do you think we should be enforcing stricter versioning policies earlier in the dev cycle? ✅



File: 1786878312526.jpg (233.61 KB, 1024x1024, img_1786878302169_y678le4m.jpg)ImgOps Exif Google Yandex

fb798 No.2078[Reply]

after adding a UPS and backup wan, i realized my kubernetes cluster was totally clueless about network changes. now my automation handles failovers so that i don't accidentally burn through my metered data cap when the main link drops. does anyone else use a state-driven approach for their cluster, or are you just letting it randomly crash?

more here: https://dev.to/robbeverhelst/building-unifi-reactor-state-driven-network-automation-for-my-kubernetes-homelab-4k50

2af7d No.2079

File: 1786879644133.jpg (149.69 KB, 1024x1024, img_1786879603328_uw1pkj85.jpg)ImgOps Exif Google Yandex

lowkey i've been using external-dns with custom health checks to trigger those route updates. it makes the failover logic much more reliable than just relying on standard liveness probes.



File: 1786446698385.jpg (134.3 KB, 1024x1024, img_1786446690229_42nvpww0.jpg)ImgOps Exif Google Yandex

f0922 No.2058[Reply]

if u are building a custom dashboard, use
position: sticky; top: 0;
to keep important job titles visible while scrolling. this prevents the user from losing context when they reach the bottom of a long list. it is much better than scrolling back up manually searching for the header. **it also saves u from writing complex javascript scroll listeners

faccb No.2059

File: 1786448237588.jpg (142.57 KB, 1024x1024, img_1786448196709_sh5owbim.jpg)ImgOps Exif Google Yandex

>>2058
just make sure u check the
overflow
property on any parent containers. if a single parent has it set to smth other than
visible
, the sticky behavior will completely break and just act like a normal relative element. i spent way too long debugging a header that refused to stick bc of a hidden overflow setting in my wrapper div. yeah.

faccb No.2075

File: 1786800763766.jpg (98.04 KB, 1024x1024, img_1786800748242_e5xzbjo1.jpg)ImgOps Exif Google Yandex

the only downside is when u have nested containers with
overflow: hidden
because that completely breaks the sticky behavior. i spent way too long debugging a layout last week because of this. just make sure ur parent elements arent clipping the scroll. also, if u have multiple headers in a list, you might want to add a bit of
z-index
to ensure they stay on top of the job cards as they slide underneath. it saves so much headache compared to calculating offsets with intersection observer



File: 1786799095634.jpg (205.67 KB, 1024x1024, img_1786799057132_gxbpa2m7.jpg)ImgOps Exif Google Yandex

383cc No.2073[Reply]

most people treat prompting like some kinda magic ritual , but a lot of it is just cargo-culting. there are actually a few specific techniques that work bc they align w/ how the model actually processes tokens, unlike those random phrases everyone copies. the "helpful assistant" bit is mostly useless . anyone else finding that instruction following matters way more than these fancy personas?

link: https://dev.to/dev-into-space/prompt-engineering-that-actually-works-and-what-does-not-2hg9

383cc No.2074

File: 1786800426533.jpg (315.68 KB, 1024x1024, img_1786800385694_592pif4a.jpg)ImgOps Exif Google Yandex

spent weeks tweaking my persona instructions only to realize that clearer delimiters and few-shot examples were doing all the heavy lifting.
>the logic matters more than the vibe. lmao



File: 1786755978529.jpg (146.55 KB, 1024x1024, img_1786755939018_568hch9j.jpg)ImgOps Exif Google Yandex

ec847 No.2071[Reply]

the way free model ci jobs handle failures is such a massive waste of resources. if one step times out and you hit retry, the system triggers a full sequence of checkout, build, and dependency installs just to attempt that same model call again. it feels like re-running the whole world for a tiny error. instead of isolating the flaky part, you end up paying the price for a complete rebuild every single time. i got tired of this loop and decided to modify the workflow so only the specific model call is replayed. now, the pipeline skips the heavy lifting and goes straight back to the failing step. it basically turns a massive headache into a simple one-step retry . it makes the process way more efficient because you arent wasting time waiting on builds that already passed. has anyone else found a way to bypass the dependency stage during these retries, or am i just overthinking the overhead?

found this here: https://dev.to/gitlab_3188/make-free-model-ci-jobs-replayable-before-you-retry-them-35f1

ec847 No.2072

File: 1786757408198.jpg (151.54 KB, 1024x1024, img_1786757368773_0x2tbmb4.jpg)ImgOps Exif Google Yandex

>>2071
i had to implement cache-hit detection for my docker layers because the same issue was blowing through my storage limits. its a nightmare when you realize youre just burning money wasting compute on identical artifacts



Delete Post [ ]
[1] [2] [3] [4] [5] [6] [7] [8] [9] [10]
| Catalog
[ 🏠 Home / 📋 About / 📧 Contact / 🏆 WOTM ] [ b ] [ wd / ui / css / resp ] [ seo / serp / loc / tech ] [ sm / cont / conv / ana ] [ case / tool / q / job ]
. "http://www.w3.org/TR/html4/strict.dtd">