개발자 @devgranpa

구글 안드로이드팀 내부에서 사용하고 있는 Rust 강의가 오픈소스 되었다! "Rust in Android", "Bare-metal Rust", "Concurrency-in-Rust" 세가지 수업으로 구성되어있는데, 신기하게도 한글어로 번역이 이미 되어있다!

Today, we are announcing Copilot, our vision for an everyday AI companion for you. blogs.microsoft.com/blog/2023/09/2…

How is code generation with GenAI different from more "traditional" code generators? The newest memo in Birgitta Böckeler's explorations of GenAI talks about abstraction levels in software engineering, and on which levels GenAI sits martinfowler.com/articles/explo…

경영진: 우리는 앞으로 설치 건수당 요금을 부과하기로 했습니다! 개발진: 그런데 집계 기준은 어떻게 계산해야 하죠? 경영진: 그걸 앞으로 니네들이 생각해야지

최근 미국 블라인드에 메타 (페북) 개발자가 나눈 메타 개발자 인터뷰 팁인데 내용이 👍 -- 안녕! 나는 6년 동안 메타에서 개발자 면접관으로 활동했어. 최근에 메타가 다시 채용을 시작하면서 면접을 다시 시작했는데, 블라인드 가족 모두가 메타에 채용 될 수 있도록 코딩 면접 팁을 몇 가지 공유하고 싶어. 1. 자기소개를 할 때 너가 짤렸다는 이야기를 전혀 언급할 필요 없어. 그냥 이전 회사를 나간 것은 너의 결정이었다고 얘기해. 만약 짤렸다고 솔직히 언급하면 면접 시작부터 부정적인 편견을 갖게 될 수 있잖아 (우리는 편견을 피하도록 훈련받긴 했지만... 굳이 우리를 시험에 들게 할 필요는 없지). 2. 퇴사 이후 무엇을 했는지에 대해 너무 많은 시간을 소비하지 마. 어떤 사람들은 세계 여행을 했다는 이야기를 몇 분 동안 해. 전혀 관심 없어. 3. 면접과 관련이 없는 사이드 프로젝트에 대해 깊게 얘기하지 마. 4. 자기소개는 30초나 최대 1분 내로 제한해. 면접관이 더 알고 싶다면 추가 질문을 할 거야. 5. 메타의 대부분의 면접관들은 여기서 오래 일하고 아마 몇 년 동안 같은 코딩 질문을 계속 물어봤을 거야. 대부분 질문들은 Leetcode에 유출되어 있으니, 면접에 합격할 확률을 높이려면 Leetcode 연습에 집중해. 나도 6년 동안 같은 2개의 질문만 사용했는데, 아직 이 문제들을 완벽하게 푸는 방법을 사람을 거의 만나본 적이 없어. 6. 코딩 속도를 향상시키는 데 집중해. 2개의 코딩 질문에 코드를 작성할 시간이 많지 않아. 대부분의 시간은 해결책을 생각하는 데 사용하고, 코딩은 각 질문당 5분 이상 걸리면 안 돼. 7. 데이터 구조를 잘 공부해 둬. Set/Hash map 은 거의 모든 질문에 유용해. Linked List도. 8. 작성한 너의 코드를 한번 검증 하는 걸 잊지 마. 시간이 부족하다 보니 대부분 자신의 코드에 심각한 결점이 없는지 확인하는 것을 잊곤 하더라. 유닛 테스트나 테스트하기 더 쉽게 리팩토링 할 수 있을지 언급이라도 해. 테스트/리팩토링 분야에서 조금이라도 주도적으로 행동하면 체점을 더 좋게 받을 거야. 9. 알고리즘/데이터 구조의 시간 복잡도를 잘 알아둬. Sorting 같은건 정말 흔하자나? 꼭 sorting의 시간 복잡도를 알아두고... 또 너가 사용하는 언어에서 sort 함수가 어떤 정렬 알고리즘을 사용하는지 알아두면 좋아. 10. 면접을 망쳤다는 확신이 든다면 면전관에게 감사 메일을 보내는 데 시간을 낭비하지 마. 좋은 매너지만 결과를 바꿀 수는 없어. 그냥 다음 면접 준비에 집중해. 면접관들은 네가 면접에 합격하기를 정말로 원해. 그러니 그들을 무서워하지 마. 예를 들면, 나는 누군가를 합격시킬 때마다 기분이 좋아져. 면접 보러 가는 모든 사람들에게 행운을 빌어. 🤞

근래 본 mock interview 영상중 가장 수준있는 영상이었다 youtu.be/S1DvEdR0iUo

The following formula yields the correct decimal digits of π to 42 billion digits

갓 출시된 Python 상위 호환 언어인 Mojo를 이용해 만든 llama2 추론 프로그램. 이미 만들어져 있던 Python 으로 만든 llama2 추론 프로그램을 포팅 해 보았다는데요. 기존 프로그램보다 무려 250배나 빨라졌다고 합니다. 😳 C로 만든 유명한 추론 프로그램인 llama2.c 보다도 20%가까이 빠르다고 하네요. 물론 기존 Python 스크립트는 최적화가 되어 있지 않은 것으로 보이고, C로 만든 프로그램도 더 빠르게 만들 수 있는 여지가 분명 있지만, 그래도 큰 노력을 들이지 않고도 이정도 성능 향상을 이끌어 낼 수 있다는 것은 확실히 인상적인 결과 것 같습니다. 앞으로 Mojo의 행보가 정말 기대됩니다. github.com/tairov/llama2.…

APPLE II는 '개인용 컴퓨터'란 당대 최첨단 이기를 77년 시점에서 일반인이 (간신히) 살만한 가격으로 누구나 제조/판매 가능하게끔 세상에 완전히 풀어놨다는 데에서 가히 프로메테우스의 불에 비견할 어마어마한 업적. 하드웨어 구조설명을 보다보면 이걸 '해낸' 워즈니악의 천재성에 감탄하게 된다.

Same. In the beginning, I was impressed by this type of "smart" code. I also tried to write code like that because I thought it looked cool, and that's how "smart" people do it. Nowadays, I prefer the more verbose code that's clear and easier to read & understand. Mention: Apply common sense. It doesn't mean that I prefer verbose code just for the sake of it or that I never use shorter code if it doesn't affect legibility. Also, don't fixate on these examples from the picture. They're some examples to illustrate the point.

요즘 인터뷰 준비하면서 Consensus 알고리즘을 공부하고있는데, 분위기를 보아하니 “Paxos는 너무 어려워서 Raft를 선택했어요” 라고 말하면 조용히 넘어갈 것 같다

당연히 그렇지 않다. 훌륭한 시니어 엔지니어는 <특정한 상황>에 맞는 <특정한 답변>을 내놓아야한다. 문제에 대해 논의할 때 뒤에서 팔짱끼고 서서 ”그때그때 다르지“ 라고 하지 말고, 우리 상황이 구체적으로 어떤 상황인지 정의하고 시작하자

[어디서 읽은글] 소프트웨어 엔지니어는 연차가 쌓일수록 질문에 대한 답이 “상황에 따라 다르죠 (It depends)”로 귀결되고, 이게 미덕으로 여겨진다. 그럼 시니어 엔지니어는 질문에 대해서 입다물고 있어야 하는가? (계속)

시작부터 마이크로서비스를 강제해서 모듈화 시키고, 일부 서비스만 교체할 가능성을 조금이라도 높이는게 경제적이다. 내 서비스는 PoC로 빠르게 만드는거라 괜찮다고? 그 코드가 정말 PoC에서 끝날까?

Monolith First 절망편 1. "잘" 만들었을리 없는 Monolith 코드 2. 떼어내기엔 이미 너무 코어와 강결합된 도메인 로직 3. 겨우겨우 일부 기능을 마이크로서비스로 떼어내고 남은 레거시 Monolith 덩어리

나는 Don't start with a monolith를 지지한다. Monolith로 먼저 잘 만들고, 사이즈가 너무 커질 때 마이크로서비스로 떼낸다는 시나리오는 망상에 불과하니까 martinfowler.com/articles/dont-…

데일리 스크럼 미팅을 “스크럼” 이라고 부르는 것 부터 문제인데, 데일리는 너무 많다고 “스크럼”을 위클리로 하자고 하면 어디서 부터 지적을 해야하는걸까

내가 경험했던 스크럼 욕하는 사람들은, 스크럼에서 이야기하는 내용을 싸그리 무시하고 자기 멋대로 해석한 뒤 “스크럼” 이라고 부르는 경향이 있었다. 스크럼 방언은 스크럼이 아니다.

기계인간 John Grib @John_Grib

3 years ago

스크럼이 암이라고 비판하기 전에 먼저 하고 있던 그게 스크럼이 맞는지는 확인할 필요가 있음. 어릴때 친구가 집에 가서 '둠'을 같이 하자고 해서 갔더니 그 친구 컴퓨터에 깔려 있었던 건 '울펜슈타인'이었다. 그 기억이 떠오른다. 그러고보니 그 친구랑 둠 이야기를 하면 뭔가가 계속 안 맞았다.

2 40 94 32K 20

@killerdragon369 @summerlight00 teamblind.com/post/Got-PIPed…

그리고 이런 프로젝트로 투자받아 업으로 할 수 있다는게 실리콘밸리의 매력 아닐까 oven.sh

youtube.com/watch?v=BsnCpE… Bun이나 Deno나 처음에는 another io.js 라고 생각했는데, 그렇다고 하기엔 너무나 훌륭한 노드 킬러인것 같다. 다음에 프론트엔드 할일 있으면 Bun으로 해봐야지