주말에 무심코 벽에달린 월패드를 보다가 저기에도 기능이 꽤 들어있는데 잘 활용하지 못하고 있다는 생각이 들었다. AI와 가능성을 조사하다가 결국 월패드를 뜯어서 어떤식으로 연결되어 있는지 대충 파악하고 결국 연결을 위해서 결국 보드를 하나 샀다. 생각대로 잘 되려나...

let _ = Danuel::new(🌿); · Oct 31, 2026 · 11:11 AM UTC

let _ = Danuel::new(🌿);@_danuel_Oct 31

계산기의 등장으로 계산 자체를 하던 직업군은 사라짐. 그 이상의 고수준 작업을 해야 함.

GeekNews

@GeekNewsHadaOct 31

AI는 SRE를 대체하는 게 아니라 숙련도를 떨어뜨리고 있음 AI가 일상적인 장애 대응을 맡으면 서비스 신뢰성을 관리하는 SRE에게는 드물고 복잡한 장애가 남음. 하지만 로그를 읽고 원인 가설을 세우는 연습이 줄어, 정작 어려운 장애에 필요한 직관은 약해질 수 있음. 자동화가 실패할 때 인간이 더 중요해지지만 개입할 숙련도는 떨어지는 ‘자동화의 역설’ 주니어에게는 기존 능력을 잃는 것을 넘어 기초 역량을 처음부터 쌓지 못할 위험도 있음. 글이 제안하는 대응은 AI를 거부하는 대신, 일부 장애를 수동으로 풀고 인간이 문제 해결에 직접 참여하도록 설계하는 것 news.hada.io/topic?id=36299

AI는 SRE를 대체하는 게 아니라 숙련도를 떨어뜨리고 있음 | GeekNews

AI가 일상적인 장애 대응을 맡을수록 SRE는 드물고 복잡한 장애에 집중하게 되지만, 이를 해결할 직관과 전문성을 연습할 기회는 줄어듦 자동화의 역설은 자동화가 실패할 때 인간의 역할이 더 중요해지는 동시에, 개입에 필요한 숙련도는 실전 경험 부족으로 약해지는 데 있음 로그 읽기, 원…

news.hada.io

463

let _ = Danuel::new(🌿); · Oct 30, 2026 · 11:26 AM UTC

let _ = Danuel::new(🌿);@_danuel_Oct 30

얼마 전에 휘낭시에를 만들어 봤는데 설탕량을 보고 이게 맞나 싶었음. 버터 180g 박력분 54g 꿀 18g 설탕 180g 흰자 180g 아몬드 분말 108g 720g 중 꿀, 설탕은 총 198g... 18개 정도 나오던데 앉은 자리에서 10개 먹으면 대략 100g...

햄메론@area_689Oct 30

아니 진심 취향인데 음료하나에 600칼로리; 당류 90.7g (각설탕1개 3g임...)셔서... 돌아나옴.... 이거먹으면 죽는다....

175

let _ = Danuel::new(🌿); · Oct 30, 2026 · 11:20 AM UTC

let _ = Danuel::new(🌿);@_danuel_Oct 30

바탕화면에 아무것도 없는 새럼 등장!

small but useful@ccoroomOct 30

Replying to @Basix1120

컴퓨터 바탕화면 보여주세요. (전 오만가지 다 펼쳐져 있는 사람)

let _ = Danuel::new(🌿); · Oct 30, 2026 · 10:34 AM UTC

let _ = Danuel::new(🌿);@_danuel_Oct 30

시나브로 모두가 파딱이 된다.

🕯️Ranol☆P 🦋 ranolp.dev

@RanolPOct 30

파딱 팔로워 늘어난다 으아악

let _ = Danuel::new(🌿); · Oct 28, 2026 · 10:06 AM UTC

let _ = Danuel::new(🌿);@_danuel_Oct 28

요런 의도 드러내자고 Effect 개념이 고안 된 거 같은데...

`코헤 아지매`@Cohe010121Oct 28

no-op일 수 있다는 걸 반환 타입에 | undefined로 드러내자

let _ = Danuel::new(🌿); · Oct 26, 2026 · 6:41 AM UTC

let _ = Danuel::new(🌿);@_danuel_Oct 26

영국인으로 살기?

파차🕯@finalchildmcOct 26

심심해서 시각을 UTC 기반으로 생각하는 훈련해 보는 중

let _ = Danuel::new(🌿); · Oct 26, 2026 · 1:10 AM UTC

let _ = Danuel::new(🌿);@_danuel_Oct 26

당했다.

파차🕯@finalchildmcOct 25

오늘은 탕수육 먹을 곳을 알아봐야지

127

let _ = Danuel::new(🌿); · Oct 26, 2026 · 1:11 AM UTC

let _ = Danuel::new(🌿);@_danuel_Oct 26

오늘 저녁은 탕수육이다.

let _ = Danuel::new(🌿); · Oct 25, 2026 · 3:27 AM UTC

let _ = Danuel::new(🌿);@_danuel_Oct 25

컴파일 결과물의 런타임 동작이 얼마나 비슷하려나.

Andrew Gazelka

@andrewgazelkaOct 24

ra-jit (incremental, faster compilation in rust) now compiles most large rust projects. github.com/indexable-inc/ra-…

Image from Andrew Gazelka (@andrewgazelka)

382

let _ = Danuel::new(🌿); · Oct 25, 2026 · 12:09 AM UTC

let _ = Danuel::new(🌿);@_danuel_Oct 25

아이디어는 나쁘지 않지만 나는 부정적. 어떤 건 길이를 어떤 건 문자열 형식을 어떤 건 범위를 어떤 건... 타입만으로는 이런 정보를 인코딩 할 수 없고, 어떻게든 하려 하면 점점 데코레이터 같은 이상한 방향으로 나아가게 됨. 내 생각에는 zod 처럼 구현부까지 포함하는 게 가장 나음.

Jarred Sumner

@jarredsumnerOct 24

what if you could pass a TypeScript type to JSON.parse and it validates the input at runtime?

Image from Jarred Sumner (@jarredsumner)

330

let _ = Danuel::new(🌿); · Oct 25, 2026 · 12:12 AM UTC

let _ = Danuel::new(🌿);@_danuel_Oct 25

fn JSON.parse::<T: Deserialize>(value: Value) -> Result<T, ParseError<T::Error>>; 이런 느낌으로써 parse 함수가 내부에서 T::parse 를 끌어다 쓸 수 있다면 살짝은 나을지도. 단, 이 경우에도 결국은 타입만으로는 세세한 런타임 의미론을 담기가 곤란함.

let _ = Danuel::new(🌿); · Oct 24, 2026 · 3:35 AM UTC

let _ = Danuel::new(🌿);@_danuel_Oct 24

파딱 파딱 온나 <<< 빨리 빨리 소녀

let _ = Danuel::new(🌿); · Oct 24, 2026 · 3:21 AM UTC

let _ = Danuel::new(🌿);@_danuel_Oct 24

파딱파딱!

아구밍 아커만

@aguming_Oct 23

굿모닝얄 죄죄이얄~ㅋㅋ

let _ = Danuel::new(🌿); · Oct 23, 2026 · 1:09 PM UTC

let _ = Danuel::new(🌿);@_danuel_Oct 23

삼권분립이라는 것은 삼권 각자가 독립적이라는 게 아니라 서로 견제하라는 것이라 서로에 대한 침해 또한 견제 방법 중 하나이다. 당연하게도 정도와 명분이 중요하다.

let _ = Danuel::new(🌿); · Oct 23, 2026 · 12:35 PM UTC

let _ = Danuel::new(🌿);@_danuel_Oct 23

손을 거두라는 의미의 거구일지도 모름. 함정이다!

Basix@Basix1120Oct 22

자~ 구독하는사람중에 맞팔하고싶다 거수

let _ = Danuel::new(🌿); · Oct 23, 2026 · 3:31 AM UTC

let _ = Danuel::new(🌿);@_danuel_Oct 23

모랄까... 구냥 상식적인 말 뿐이라 굳이 가이드로 못 박아야 하나 싶은 수준.

ayush🔮👨‍💻🔮

@ayushagarwal027Oct 22

Google's Rust style guide makes some strong choices. A few worth knowing, and why. 🦀 It covers Google's Rust code in places like Android, Chromium and Fuchsia. Some rules apply only to one codebase, and the guide tags those. One goal sets it apart from the public Rust style guide: rules should make large-scale automated refactors easier. Several rules follow from that. Rules that stand out: → Avoid Rc and Arc. Prefer unique ownership and borrowing. Shared ownership is allowed when the alternative would be unreasonably complex, as a judgment call in review. → Don't call panic::catch_unwind. Chrome, Android and Fuchsia all require panic=abort, and catch_unwind only works with panic=unwind. A narrow exception exists as defense in depth. → No glob imports, with a short list of exceptions. They make automated refactors harder and hide where a type comes from. → Prefer pattern matching over check-then-unwrap, so the compiler proves the value is there. When a panic is unavoidable, prefer expect over unwrap, to document the reason. → Prefer an enum over a bool when the meaning of the argument is not obvious. → Don't build iterator chains in a for loop header. Assign the chain to a named variable first. → Unsafe code needs a SAFETY comment and a justification. If the reason is performance, the guide asks whether there are benchmarks. Chromium-specific, so not general advice: no async/await, and prefer sequences over standard library threads. One detail that is easy to miss: API design rules are binding for library code, but only strong recommendations for application code. The guide says application code should favor simplicity and avoid premature generalization. Not every rule will suit every team. But the reasons are stated for each one, which makes the guide useful to read alongside a team's own conventions. 🔗 google.github.io/styleguide/… #RustLang #SoftwareEngineering #CodeQuality #OpenSource

Image from ayush🔮👨‍💻🔮 (@ayushagarwal027)