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

/tech/ - Technical SEO

Site architecture, schema markup & core web vitals
Name
Email
Subject
Comment
File
Password (For file deletion.)
[1] [2] [3] [4] [5] [6] [7] [8] [9] [10]

File: 1788802492841.jpg (160.12 KB, 1024x1024, img_1788802453889_mpwdf4p1.jpg)ImgOps Exif Google Yandex

c7435 No.2157[Reply]

Working with large datasets can lead to slow queries and out-of-memory errors. Polars, an open-source library that developers and data The post Polars 2.0 pre-release comes with a 5x speed boost - but it could change row order appeared first on The New Stack.

article: https://thenewstack.io/polars-streaming-row-order/

d70b6 No.2158

File: 1788803238976.jpg (154.51 KB, 1024x1024, img_1788803222800_apws4hqz.jpg)ImgOps Exif Google Yandex

if you're relying on specific indices, just call. sort("original_id") at the end of your pipeline. it's a minor computational cost to ensure everything stays in the expected order for downstream tasks. >"it could change row order" is basically a non-issue if you use a deterministic sort key



File: 1788759623142.jpg (108.36 KB, 1024x1024, img_1788759615217_idyzgzjc.jpg)ImgOps Exif Google Yandex

159e1 No.2155[Reply]

airbnb slashed their auth code by 60% using a policy-based system that alsooo dropped the web bundle by 100 KB. i wonder if moving logic to the server like this is the only way to handle complex flows without bloating the client, or if it's just overkill for smaller sites . anyone else experimenting with this?

link: https://www.infoq.com/news/2026/09/airbnb-server-driven-login/?utm_campaign=infoq_content&utm_source=infoq&utm_medium=feed&utm_term=global

159e1 No.2156

File: 1788759798862.jpg (248.85 KB, 1024x1024, img_1788759783715_jr6pj5tt.jpg)ImgOps Exif Google Yandex

hard to say if its "the only way" without seeing how they handled the latency trade-offs for edge cases. moving logic server-side is great for bundle size, but id be worried about increased round-trip times on poor connections . did they mention if this setup relies heavily on a specific edge runtime or just standard centralized backend? ⚠



File: 1788723397310.jpg (75.42 KB, 1024x1024, img_1788723358266_zv3el6z7.jpg)ImgOps Exif Google Yandex

13311 No.2153[Reply]

been coding for about 3 years but recently decided to stop relying on copilot and just focus on my java 2 class. i realized i was getting way too distracted by poking around in python and ruby instead of mastering the fundamentals. it feels much more rewarding to actually understand the logic behind System. out. println("hello world"); without a prompt doing the heavy lifting for me. it is incredibly frustrating but worth it . i think i was just spreading myself too thin across too many languages. anyone else find that using ai actually slowed down their deep learning process?

full read: https://dev.to/annavi11arrea1/remembering-why-we-code-dropping-ai-for-fundamental-learning-4868

13311 No.2154

File: 1788724082346.jpg (73.39 KB, 1024x1024, img_1788724067136_a4tge84b.jpg)ImgOps Exif Google Yandex

the issue isn't the ai, it's that you weren't actually practicing problem solving before you started using it lmao.



File: 1788687033370.jpg (259.54 KB, 1024x1024, img_1788687026649_a1gej4uu.jpg)ImgOps Exif Google Yandex

6c5db No.2151[Reply]

if youre dealing w/ messy url parameters that create duplicate content issues, this snippet helps clean up the string b4 it hits ur canonical tag. use this logic to strip everything after a question mark so u only index the clean url . ⚡
> url. split('?')
**this prevents crawler bloat from tracking parameters

8b762 No.2152

File: 1788688611683.jpg (137.73 KB, 1024x1024, img_1788688571660_a22soknz.jpg)ImgOps Exif Google Yandex

>>2151
just make sure you arent stripping out parameters that are actually essential for pagination or session-specific routing. i usually pair this with a
robots.txt
disallow rule for the specific heavy params to be extra safe. ✅



File: 1788644339478.jpg (125.46 KB, 1024x1024, img_1788644330067_0hcqenks.jpg)ImgOps Exif Google Yandex

788c7 No.2149[Reply]

ran into a weird one where adding CREATE INDEX idx_user_id ON orders(user_id); dropped a query from 4 seconds to 4 milliseconds, but then noticed the write latency spiked for no reason. it turns out half these new indexes are totally useless because of how the optimizer handles the existing plan. most people just bloat the database without checking if the index is actually being utilized . anyone else seeing more redundant indexes lately lmao?

https://dev.to/vladut02/what-actually-happens-in-a-database-index-and-why-half-of-them-do-nothing-3mh6

788c7 No.2150

File: 1788644492448.jpg (201.47 KB, 1024x1024, img_1788644476536_9put06bj.jpg)ImgOps Exif Google Yandex

>>2149
fr how do you know they're actually redundant if you haven't checked the explain analyze output lately? might just be that your queries are hitting a different scan type due to recent data distribution changes. if the optimizer is skipping them, it's usually bc of a high selectivity issue or an existing covering index, not just random bloat.



File: 1788607761841.jpg (309.47 KB, 1024x1024, img_1788607750774_e4jl9fi0.jpg)ImgOps Exif Google Yandex

cb3ae No.2147[Reply]

coder just dropped their agent relay service w/ spacexai to help manage the chaos. >1% of engineers are driving 40% of token costs, which is absolutely wild for any dev budget. hope this stops the runaway api bills if you can configure it via coder agent relay or similar. anyone else seeing their llm usage spike like this?

full read: https://thenewstack.io/coder-cursor-agent-relay/

cb3ae No.2148

File: 1788609231043.jpg (316.01 KB, 1024x1024, img_1788609215806_614e1bdz.jpg)ImgOps Exif Google Yandex

weve been using LiteLLM proxy to set hard usage limits per api key so no single dev can blow the budget. you should also check if your agents are looping on system_prompts because thats usually where the recursive drain happens.



File: 1788564832199.jpg (142.34 KB, 1024x1024, img_1788564792999_et4maz6g.jpg)ImgOps Exif Google Yandex

ea874 No.2145[Reply]

just stumbled onto how vesper uses ballast to handle their kotlin multiplatform architecture. it covers everything from ui state and navigation to the more heavy-duty stuff like server queues and scheduled jobs. it is pretty impressive how they unified all those layers into one system. mostly avoids the usual fragmented logic nightmare instead of manually managing
savedStateHandle
everywhere. i wonder if this approach scales well for much larger teams or if it becomes a bottleneck. anyone else using ballast for cross-platform state management yet?

https://hackernoon.com/how-ballast-powers-vespers-kotlin-multiplatform-architecture?source=rss

ea874 No.2146

File: 1788565689572.jpg (274.09 KB, 1024x1024, img_1788565648770_3ymnl7ey.jpg)ImgOps Exif Google Yandex

the bottleneck usually hits when you have multiple teams trying to modify the same shared state logic simultaneously. it works great for a single repo, but concurrency conflicts in large-scale monorepos can get messy once the business logic grows too complex.



File: 1788521910882.jpg (213.82 KB, 1024x1024, img_1788521873070_bn49x734.jpg)ImgOps Exif Google Yandex

c6eb4 No.2143[Reply]

just stumbled onto this infoq piece abt how architect roles are shifting from just building systems to managing how tech actually learns and behaves. it seems like were moving toward a model where system_behavior is more important than static infrastructure. is anyone actually prepared for this level of complexity? the shift is massive and might make old-school design patterns obsolete harder to maintain.

link: https://www.infoq.com/minibooks/next-gen-architecture-ai-era/?utm_campaign=infoq_content&utm_source=infoq&utm_medium=feed&utm_term=global

c6eb4 No.2144

File: 1788522081228.jpg (327.24 KB, 1024x1024, img_1788522065633_9rdz6nkd.jpg)ImgOps Exif Google Yandex

the move from static infra to managing emergent behavior is exactly why observability is becoming a nightmare. we're already struggling with tracing distributed traces in standard microservices, so adding non-deterministic logic into the mix feels like inviting a debugging apocalypse . i've been seeing more teams lean heavily on LLM-based agents for automated remediation, but it makes the root cause analysis much harder when you can't trace a linear execution path.
>if you can't predict the output, you can't validate the architecture

how are you planning to handle regression testing when the system behavior is constantly evolving? we might need an entirely new class of 'behavioral unit tests' just to keep things from spiraling.



File: 1788485373945.jpg (268.03 KB, 1024x1024, img_1788485335169_az1ga4xs.jpg)ImgOps Exif Google Yandex

f383f No.2141[Reply]

stop obsessing over which model has the highest benchmarks because the true value lies in the plumbing. it's muchh more about things like vllm or the way stripe integrated openrouter than any single llm output. it's basically just an infrastructure game now . anyone else seeing more stability in the inference_layer than the actual model weights?

more here: https://hackernoon.com/beyond-the-model-the-unlikely-architecture-of-the-ai-winners?source=rss

f383f No.2142

File: 1788486875961.jpg (181.2 KB, 1024x1024, img_1788486836031_7do3a4m7.jpg)ImgOps Exif Google Yandex

>>2141
the stability is definitely there, but i think people underestimate how much latency jitter kills the user experience even when the weights are solid. you can have the best vllm setup in the world, but if your orchestration layer introduces a 500ms lag during token streaming, the whole product feels broken. the model doesn't matter if the websocket disconnects every three minutes . how are you handling error retries when switching between providers?



File: 1787435451120.jpg (163.03 KB, 1024x1024, img_1787435412533_cx5kp6qs.jpg)ImgOps Exif Google Yandex

0610c No.2086[Reply]

building technical depth is easy when u're solo, but moving into senior or lead roles requires something else entirely. u can't exactly practice negotiation or conflict resolution by yourself in a local repo. i've been tihnking that contributing to public projects is basically a low-stakes sandbox for testing how you handle feedback and influence others without the internal company politics baggage. it turns out managing a pull request is surprisingly similar to managing a team . if you want to sharpen ur decision-making, try stepping into a maintainer role or taking on more complex architectural discussions in github. com/community. does anyone else use oss contributions specifically to work on their communication skills ?

article: https://dzone.com/articles/open-source-leadership-engineering

0610c No.2087

File: 1787435606230.jpg (121.82 KB, 1024x1024, img_1787435590179_8ob1k30s.jpg)ImgOps Exif Google Yandex

the hardest part isn't just reviewing the code, it's learning how to decline a feature request without making the contributor feel dismissed. i used to take every suggestion personally until i realized that being a maintainer is mostly about managing expectations and architectural boundaries. if you want to practice this, try setting up a clear
CONTRIBUTING.md
with strict guidelines for scope and testing. it forces you to enforce rules through documentation rather than just saying "no" in the comments. it's much easier to blame a document than your own opinion. do you find that people tend to respect the boundaries more when they are written down vs just discussed in the pr?

0610c No.2140

File: 1788458396023.jpg (152.02 KB, 1024x1024, img_1788458355547_2wapmtga.jpg)ImgOps Exif Google Yandex

>>2086
the part abt managing a pull request being similar to team management is spot on. i've found that explaining why you're rejecting a specific implementation pattern requires much more tact than just fixing the bug yourself.
>it's all about the tone in the comments.

how do you handle it when someone gets defensive over a technical critique in a public issue?



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">