전체보기

순수 노드 백엔드에서는 create서버 안에 if문을 이용해서 메서드와 url을 확인했다면 express 프레임웤을 이용하면 app의 get, put, delete 콜백을 정의하고 listen만 하면 되어 매우 편해진다. express 메서드의 기본골격은 app에서 get 메서드를 작성하고 뒤에 URL/Path, 실행될 콜백함수 그리고 req, res, next)로 이루어진다. 이에 대해 좀더 알아보자.Express는 기본적으로 라우팅, 미들웨어, 요청 및 응답 처리라는 세 가지 핵심 요소로 구성된다.   1. 라우팅(Routing)Express의 가장 기본적인 기능은 클라이언트 요청을 특정 경로(path)와 연결하여 요청을 처리하는 것이다. app.get('/path', (req, res) => {....

문제 상황 플러터 웹을 구현하던 도중 애니메이션 효과가 너무 무거웠다. iOS의 경우 animation을 줄 때 비동기 프로그래밍으로 계산을 처리하기 때문에 여기서 아이디어를 얻어 isolated 를 써서 다른 스레드에서 작업을 돌리려고 했다. 하지만 애니메이션 효과는 영원히 나타나지 않았고 디버그 모드로 다시 실행시켜보니...  플러터 웹은 isolated를 지원하지 않는다고 한다....;;;; 아무리 모바일보다는 덜 사용하는 플러터 웹이지만 대부분 프레임워크에서 거의 필수적으로 들어가는 동시성 프로그래밍이 안된다는게 너무 이상해서 구글링을 해보았다. 다행히 isolate가 아닌 다른 방법으로 멀티프로세싱을 구현할 수 있었다. Flutter Web에서 멀티 프로세싱하기 Flutter 웹에서 Isolat..

하이퍼바이저란? 하이퍼바이저는 물리 서버 위에서 여러 가상 서버 인스턴스(VSI)를 만들어내는 소프트웨어이다. 하이퍼바이저(Hypervisor)의 어원을 살펴보면 "하이퍼-" 는 "초월적인" 또는 "더 높은 단계의" 라는 의미를 가지고 있어 하이퍼바이저가 물리적인 하드웨어 위에서 가상 시스템을 관리하는 소프트웨어임을 나타내고 "바이저(Visor)" 는 "관리자" 또는 "감시자"라는 뜻으로, 하이퍼바이저가 물리적 자원을 감독하고 가상 머신이 이 자원을 잘 활용하도록 관리하는 역할을 한다는 것을 알 수 있다. 즉 하이퍼바이저는 물리적 자원을 초월해 여러 가상 머신을 관리하는 상위 관리자라는 의미를 내포하고 있다. 컴퓨터 부팅될 때 물리적 하드웨어에서 시작해 운영체제가 메모리에 올라가고 프로그램들이 실행되는데..

ㄴ

문제 상황분명 아무런 패딩값도 주지않고 탭바와 리스트뷰를 Column으로 수직배치했는데 리스트뷰는 위와같이 정상적으로 나왔지만 탭바부분이 이상하게 왼쪽 간격이 들어가있었다.    문제 해결isScrollable 속성 때문이었다.  isScrollable가 true로 설정되면, 각 탭은 자신의 내용에 맞춰 크기를 갖는다. 예를 들어, "Home"이라는 텍스트가 있는 탭은 "Settings"라는 텍스트가 있는 탭보다 더 좁을 수 있다. 이렇게 정해진 화면 너비 대비 계산이 아닌 주어진 텍스트 기반으로 너비를 정함으로써 탭의 개수가 많아서 화면에 모두 표시될 수 없을 때, 사용자는 수평 스크롤을 통해 나머지 탭으로 이동할 수 있다. 각 탭이 자신의 내용에 맞게 배치되기 때문에 스크롤이 가능해지는 것이다. is..

1

1

1

1. 어떻게 하면 if문을 최소화할 수 있을까에 대한 고민 하나의 함수 내부에서 if문이 계쏙해서 나오는 것은 가독성이 안좋은 코드라고 판단했다.    2. Sign in 과 Sign up 의 차이 https://chaeyeon-chaeyeon.tistory.com/66 Log in 과 Sign in은 뭐가 다른 걸까? (+ Sign up)접근을 얻기 위해 시스템에 자기 자신을 증명하는 것, 이것을 국내에서는 '로그인'이라고 부르고 있습니다. 국내가 아닌 다른 곳은 어떨까요? 국내에서 서비스하고 있지 않거나 국내와 더불어chaeyeon-chaeyeon.tistory.com Login : 유저의 첫입장을 "기록" -> 영미권에서 익숙하지 않은 표현이라함SignIn: 로그인SignUp: 회원가입  3. Sa..

절차형 코드를 선언형으로 리팩토링해보기 절차형프로그래밍 코드도 선언형으로 리팩토링 해보았다.  은닉화된 메서드를 전부 Function 타입으로 프로퍼티화해버리고 외부 노출 메서드만 함수 선언부로 두면 객체 역할이 명확히 드러나지 않을까?재정의 된 함수들은 선언형으로 깔끔하게 선언이 잘 되었는데 은닉화 메서드들이 있다는게 먼가 지저분(?)해 보였다. 그래서 내부로직을 담고 있는 녀석들을 프로퍼티화 해버리면 깔끔해지지 않을까 라는 생각이 들었고 바로 시도해보았다. 결과는 폭망이었다. 프로퍼티로 선언해야하다보니 어쩔 수 없이 앞에 타입을 명시해주어야만했고 코드가 훨씬더 읽기 힘들어졌다. 생각해보니 함수형을 지향한다면 역으로 프로퍼티 선언을 최소화하고 전부 함수 선언으로 돌려버리는게 맞지 않을까라는 생각도 들었다.