
레디스의 모든 것 (feat. Node.js)
₩22,000
입문 / Redis, Node.js
5.0
(1)
레디스 A to Z로 레디스 첫 시작을 탄탄하게! 고등학생이 봐도 완벽히 이해할 수 있는 쉽고 재밌는 레디스의 모든 것
입문
Redis, Node.js
안녕하세요! 제 경험을 자유롭게 공유하고 싶습니다.
yongsoocho578@gmail.com 으로 피드백과 의견은 환영입니다.
레디스의 모든 것 (feat. Node.js)
₩22,000
입문 / Redis, Node.js
5.0
(1)
레디스 A to Z로 레디스 첫 시작을 탄탄하게! 고등학생이 봐도 완벽히 이해할 수 있는 쉽고 재밌는 레디스의 모든 것
입문
Redis, Node.js
타입스크립트의 모든 것
₩22,000
초급 / TypeScript, NestJS, Deno
5.0
(12)
Node.js 진영의 표준, TypeScript 어떻게 쓰고 계신가요? 타입 주석만 달고 계신다면 진짜 타입스크립트가 아닙니다. 무엇을 좋아할지 몰라서 다 준비했습니다. 타입스크립트 A to Z를 알아봅시다 :)
초급
TypeScript, NestJS, Deno
질문&답변
systemctl restart redis-study 문제
journalctl 을 함께 보면 좋은데, 현재 에러 메세지로는 conf 파일 문법이 틀린거 같습니다. vi /redis/redis-stable/redis.conf 로 vi 에디터 켜기:2328 입력으로 2328번째 줄로 이동하기 (이동 키는 G 입니다.)주석 미처리, 띄어쓰기, parameter 타입 오류 등... 해결:wq 로 저장 후 다시 시도 해당 방법으로도 안된다면, journalctl 이나 status 상세 옵션으로 로그 부탁드립니다 🙂
질문&답변
BuilderInit 사용 이유
해당 문법은 데코레이터가 실험적기능으로 타입스크립트에 도입되었을 때 문법이라 에러들을 우회하기 위해서 설명한 문법이였습니다. 특히 지금 데코레이터는 4버전 초반대랑 조금 다를 것 입니다. 그래서, 강의의 타입스크립트 버전이 너무 옛날 버전이라 강의를 재촬영을 계획하고 있습니다. 그리고 지금은 Builder를 사용하지 않고 모두 함수를 이용하는 편입니다. 예전에는 디버깅하려고 Builder를 쓰기도 했는데 지금은 보통 쓰지 않습니다. 본 영상의 목적은 Decorator에 이해를 돕기 위한 것 이였으나, 혼란을 드려 죄송합니다.
질문&답변
enum 질문이 있습니다.
맞습니다. 그래서 인터페이스를 주로 사용합니다 :)
질문&답변
색션 2, 데코레이터 개념이 아예 이해가 안됩니다.
안녕하세요. 데코레이터는 사실 Node.js 진영에서 앵귤러나 Nest.js를 제외하고는 잘 쓰이지 않습니다.JS가 코딩 입문언어로 그 외 언어들은 알지 못합니다.그래서 데코레이터가 더 이해가 잘 안되는데요.-> 원래 처음에는 난해한 개념입니다. 대한민국에서 개발자를 하신다면 언젠가는 꼭 자바(Java)를 배우실 날이 올 것 인데요. 그때 자세히 배우고 지금은 이런 것이구나 ~ 하고 개념만 잡고 그때 공부하셔도됩니다.참고할만한 블로그나 기초 개념들을 알려주시면 감사하겠습니다.-> 자바 데코레이터 구글에 검색하시면 됩니다. 파이썬도 데코레이터 많이 쓰긴 하는데, 자바가 공부하기에는 좋겠네요. 아래는 타입스크립트 관련 데코레이터 정리해놓은 링크 두겠습니당.https://typescript-kr.github.io/pages/decorators.htmlhttps://www.typescriptlang.org/docs/handbook/decorators.html아래의 오류가 떠서 뭐가 문제인지 잘 모르겠습니다.-> 에러 메세지는 인자가 잘못 되었을 때 나타나는 메세지입니다.
질문&답변
변수의 타입에 클래스를 지정해준 것과 지정 안한 것 과의 차이가 어떻게 되는지 궁금해서 질문을 남깁니다.
본래 UserInfo 상단에 지정된 인자들의 타입을 한번 더 점검해준다는 뜻인가요??답) 점검하는 목적은 아닙니다. 객체의 메소드와 변수가 안에 들어있다는 것을 보장하기위해, 자동완성 목적으로 타입을 달아줍니다.클래스 타입을 지정해주는 이유는 사실 지금은 느끼기 어렵습니다. 나중에 규모가 큰 프로젝트를 하시다보면 다른 파일에 분명 타입을 달았는데도 타입이 인식되지 않는 경우가 종종 있습니다. 또한, 여러명에서 동시에 개발을 하다보면 무슨 타입인지 들어가봐야 아는 경우도 자주 생기므로 달아주는 것이 좋습니다.
질문&답변
섹션4 예제0 질문입니다.
compilerOption 에서 strict 나 noImplicitAny옵션을 true로 하였는지 한번 확인 부탁드립니다.
질문&답변
제네릭 extends관련질문 있습니다.
질문주셔서 감사합니다 :)object는 객체일 뿐 어떠한 프로퍼티, 메서드도 보장하지 않습니다.interface ITest { hello: any } test예를 들어서 위와같이 타입을 적으면 hi가 없다는 것을 알 수 있습니다.이는 협업에서도 마찬가지입니다.작성자 분께서만 알고 있을 뿐, 같이 일하는 동료가 test를 보면서 test.hi( )를 유추할 수는 없습니다.제가 클래스로 대입해서 설명을 하자면,class ObjectTest {} class Test extends ObjectTest {} const test = new Test(); test.hi();예를 들자면 위와 같은 상황인데 hi()가 있는 인터페이스를 상속해야만 100% 보장된다는 것을 아셔야합니다.타입스크립트 엔진 자체가 100% 보장되는 것을 추구한다고 생각하면 편합니다.뒤에서 배우시겠지만 타입가드를 통해서 100% 타입을 보장해서 써야만 오류가 안납니다.
질문&답변
안녕하세요 정말 좋은 강의 감사합니다
저는 다음과 같은 익스텐션을 사용합니다.Bracket LensBracket Pair Colorization TogglerESLintindent-rainbowMaterial Icon ThemePrettier - Code formatterREST ClientTabnine AI Autocomplete
질문&답변
하나의 인터페이스와 여러 버전의 클래스에 관한 질문
버전이 변경될 때마다 불필요한 리소스를 잡아먹는 작업인 것 같아 옳지는 않은 방향인 것 같아 질문드려요!-> 저도 예전에 똑같은 생각을 갖고 있었습니다. 왜 클래스를 그냥 구현하면 되지 귀찮게 인터페이스를 두지..? 라는 생각이였습니다.일단 이 개념은 컴퓨터공학과(혹은 소프트웨어공학과)에서 배우는 "소프트웨어공학", "객체지향 설계" 등의 과목 중 일부입니다.A 클래스가 B 클래스를 호출한다고 할 때 인터페이스를 통하여 호출하면 B 클래스가 어떻게 생겼는지 안이 어떻게 구현되어있는지 모르지만 정상적으로 호출하고 실행이 됩니다. 여기서 객체지향 설계의 은닉화, 캡슐화 등 여러 개념을 같이 배우게 되는데요. 사실 매우 거대한 개념이고 하나의 강의로 풀어낼 개념은 아닙니다. (파고들면 정말 밑도 끝도 없습니다.) 정리를 하자면인터페이스는 설계도 같은 것 입니다. 웬만해서 크게 변하지 않습니다. 하지만 인터페이스를 꼭 만들어라!!! 는 아닙니다. 100층 짜리 고층 건물을 설계할 때는 설계도가 필요하지만, 작은 모래성을 쌓는데 설계도가 필요하지는 않습니다.A클래스가 -> B클래스(타켓 클래스)를 호출하는데 인터페이스를 통해서 호출하면 A 클래스는 B 클래스가 어떤 구현을 갖고있는지 모르지만 파라미터와 리턴타입 정보만 갖고 호출하고 사용할 수 있습니다. B클래스가 은닉성을 갖으면서 A-B 커플링(객체지향설계에서는 클래스간 의존도를 낮춰야합니다..!)이 낮아지게 됩니다. 지금은 굉장히 비효율적으로 느끼실 수 있는데, 애초에 대규모 애플리케이션에서 많이 쓰는 형태입니다.
질문&답변
!과 타입 단언 (보충) 질문
examples2 type을 object 선언후 as 로 IExam 을 감싸는 이유가 따로 있을까요-> 같은 파일 안에서는 타입추론이 맞지만, 외부 모듈이나 파일이 많아지면 추론이 잘 안될 때도 있습니다. 또한, 웹(document) 에 접근 할 때는 타입이 추론이 잘 되지않아 종종 단언을 합니다 저렇게 했을경우 value 프로퍼티 접근을할경우 빨간줄이 뜨는데 이럴땐 해결하는 방법이 따로 있을까요??-> 위 방법은 "타입 단언"이고 뒤에 "타입 캐스팅"이 나옵니다!