외할머니 휴대폰에 노래방 앱을 깔아드렸는데, 바로 노래를 부를 수 있는게 아니고 노래방 계정을 만들어야 했다.
계정 생성 과정에서 생년월일에 1941-xx-xx을 입력했더니 잘못된 패러미터라는 경고창이 뜨면서 진행이 안됐다.
혹시나 싶어서 1970-xx-xx으로 바꿔봤더니 회원가입이 되었다...
너무 완벽한게 다국어 처리(게임 내 텍스쳐까지 달라진다)와 Service Worker 대응까지 되어있다.
README는 말할 것도 없이 훌륭하고 소스코드도 현대 JS 생태계와 기능을 충분히 활용하는 데다가 주석에 타입 어노테이션까지 해놓으셔서 IDE에서 타입추론이 된다.
이 분 정체가 너무너무 궁금함;;;
중첩된 배열을 뒤집는걸(e.g. [1, [2, 3, [4, 5]]] -> [[[5, 4], 3, 2], 1]) 코딩테스트로 오랜기간 사용했었는데 개인적으로 신기했던 지점.
- 이미 이력서로 한차례 걸렀는데도 이 문제 하나로 또 절반 이상이 걸러짐
- 중첩된 배열을 뒤집는 방법이 내가 생각했던 것보다 훨씬 다양했음
다들 자만추 한다는게 나는 여태껏 '살다보면 알아서 만나지는거 추구'인 줄 알았는데, 사실은 그게 아니라 '(그들에게는) 자연스러운 인싸생활중 만남 추구'라는 것이라는걸 나이 30이 돼서 깨달았고, 나한테 그 인싸생활은 매우 의도적으로 열심히 해야 겨우 그들을 따라잡는 것이었다.
이거 런타임이랑 관련 없다.. 그래서 "숫자 처리 매커니즘" 이런거랑 상관없는 파싱 문제다.
number 리터럴이 '.' 문자까지 먹기 때문인데, js 문법 덕후가 아니면 실무 잘하는 사람중에 이거 모르는 사람 많다.
차라리 에러가 발생한 코드가 있는 개발 머신을 주고 직접 디버깅 해보라고 하는게 낫다.
이거 런타임이랑 관련 없다.. 그래서 "숫자 처리 매커니즘" 이런거랑 상관없는 파싱 문제다.
number 리터럴이 '.' 문자까지 먹기 때문인데, js 문법 덕후가 아니면 실무 잘하는 사람중에 이거 모르는 사람 많다.
차라리 에러가 발생한 코드가 있는 개발 머신을 주고 직접 디버깅 해보라고 하는게 낫다.
이거 런타임이랑 관련 없다.. 그래서 "숫자 처리 매커니즘" 이런거랑 상관없는 파싱 문제다.
number 리터럴이 '.' 문자까지 먹기 때문인데, js 문법 덕후가 아니면 실무 잘하는 사람중에 이거 모르는 사람 많다.
차라리 에러가 발생한 코드가 있는 개발 머신을 주고 직접 디버깅 해보라고 하는게 낫다.
사람들이 책임, 신기술 도입 책임, 의사결정 책임, 책임지기 싫어서 가만히 있었다, 등 다양한 책임 이야기를 할때마다 회사에서 대체 책임을 어떻게 지라고 하길래 다들 그렇게 두려워하는건지 궁금하다 화형이라도 시키는것인가
그리고 아무것도 안하는것의 리스크와 책임은 왜 언급되지않는거지
사실 말도 안 되는 요구사항은 말이 되도록 정리한다는건 불가능하다.
비슷한 효과를 가진 말이 되는 "다른" 요구사항으로 바꿔야 한다.
일을 제대로 하려면 먼저 상대방을 설득해야 하지만, 어떤 사람들은 자기 멋대로 해석한 요구사항대로 구현해버린 다음 이게 본래 당신이 요구한 것이라고 한다.
이거 진짜야....A회사에서 가장 유능한 놈이 좋은 회사B로 이직 > 걔의 추천으로 B사에 자리났을때 거기 들어감 >B사에서 C로 이직한놈의 추천채용으로 C사에 입사...
이짓을 대략 5번정도 해서 연봉을 3천대에서 5천대로 올린 지인이 있으며(문과)
3천에서 1억으로 올린 지인도 있음(개발자)
1년 정도 리액트 아닌걸 하다가 최근에 다시 리액트(with next.js)로 돌아왔는데, 10년전 브라우저도 지원해야 하거나 수십 kb에 모든걸 우겨넣어야 하는 제약조건 같은게 있는게 아니라면 이제 거의 모든 면에서 최적에 가까운 선택지를 제공해주는 프레임웍 아닌가 싶다.
잡지식을 체크하는 질문으로는 면접관보다 지원자 수준이 훨씬 높을 때 면접관이 그걸 알아볼 수 없는 문제가 있는데다 (지원자가 꺼내는 저수준 용어들을 들어본 적도 없으니 헛소리 하는 걸로 간주), 실무적으로 뛰어난 지원자여도 하필 그런 사소한걸 몰라서 떨어지게 만들어버릴 위험이 있다.
한글코딩 어쩌고 얘기 도는데 식별자에 한글 쓰는건 자동완성 잘 안되고 불편함.
객체리터럴의 key에 한글넣는 정도면 따옴표치는 시점에 후보가 뜨니 ㅇㅋ
그리고 요즘은 유니코드라 한글 문제없다는 얘기가 보이는데 유니코드는 맥에서 한글파일이름 복사해다 붙일때 정규화 이슈가 있다.
진지하게 얘기하자면 잘 알려진 이메일 서비스 도메인과 비슷한 주소를 적으면 경고를 보여주면 된다.
cli에서는 오타를 치면 "이걸 의도한 거니?"를 보여주는게 일반적인 프랙티스인데 이건 웹쪽이 미진한 사례.
인풋을 나눠놓아도 "직접 입력"을 누른 다음 오타를 치면 여전히 똑같은 문제가 발생함.
좋은 코드의 조건은 여러가지겠지만 그 중에 버그가 얼마나 적게 발생하는지를 중요한 지표로 본다면, 정적 타입 검사를 도입하는 것 만으로 프로덕션에서 발생하는 버그 중 15%는 코드가 배포되기 전에 감지할 수 있게 된다. 널체크 조차 겨우 되기 시작하던 ts2.0시절 연구
좋은 코드의 조건을 거론하는 책이나 이론에서 코드에 타입이 명시되야 한다고 주장하는 경우는 극히 드물다. 리팩토링의 나쁜 냄새에도 없다. 그럼에도 불구하고 동적 타입 언어를 쓰다가 정적 언어로 바꾸면 갑자기 코드의 유지보수성이 마법처럼 올라갈 거라고 믿는 사람들이 있다.
많이 안 바라고 온전한 원시타입들(u8...64, ...), 임의정밀도 정수와 소수, 코드포인트 단위로 처리되는 문자열, 레코드 와 투플 그리고 불변컨테이너들, 이터레이터, gc, 람다와 클로저, 파이프라인 연산자, 문장 = 표현식, 모듈, 타입, 패턴매칭, 이펙트, 매크로 정도만 기본으로 있으면 만족할텐데
lodash
- `_` 쓰는게 `$` 같아보여서 jquery같이 느껴지는 라이브러리
- 사용하면 패배한 느낌 드는 라이브러리
- 디펜던시에 넣어두면 꽤 많은 귀찮은 문제들이 간단하게 풀린다는건 알지만 안 넣는 것
- 한참 고민하다가 결국 디펜던시 한 줄 대신 src/util.ts 만드는걸 선택하게 되는 것
그러고보니 2016년쯤에 스포카에서 next.js 1 썼을때 내가 이거 너무 덜익어서 못써먹겠다고 하니까
@m11c_
아저시가 그럼 언제쯤 쓸만해질거 같냐고 했을때 농담으로 버전 10정도 되면 쓸만해질거 같다고 했었는데 지금 버전이 10이고 지금 프론트엔드 선택지 중에서 이거만한게 없다.
자주 있는 일이긴 한데 가까운 사람이 얽혀있는 일에 편들기로 보일까 말 얹기가 주저된다.
어느쪽이든 행위를 가지고 의도를 과하게 넘겨짚지 않았으면 좋겠고, 행위가 적절한지에 대해 얘기하고 있는데 행위자의 평소 행실이 어떤지로 딴 소리를 하지도 않았으면 좋겠다.
눈살 찌푸려진다.