# overlay

soosoorim

(예제) 상품 진열 레이아웃 > 애니메이션 만들기 one-way 애니메이션 혼자 알아서 만드는 법 / 그냥 외우기!!! one-way 애니메이션은 A에서 B로 정지없이 쭉 이동하는 애니메이션을 뜻한다. 시작스타일 정하기 최종스타일 정하기 언제 최종스타일로 변할지 트리거 주기 (대부분 마우스 올렸을 때임) transition 으로 서서히 동작하게 만들기 이런 스텝으로 CSS 코드 짜면 끝. 3번은 :hover 이런거 쓰면 된다는 소리이다. CSS만으로 만들 수 있는 트리거는 마우스 올렸을 때 이 정도가 가장 흔함. 나중에 자바스크립트를 배우게 되면 클릭시, 드래그시, 키 입력시 이런걸 전부 애니메이션

hyeonhee_bee

오늘의 목표 와이어프레임 완성하기 컴포넌트들 정리하기 오늘의 디자인 와이어프레임 페이지별로 정리(기존에 손으로 스케치한것을 figma로 정리한 느낌이다) overlay 설정에 대해 프론트와 소통 오늘의 보완점 - 소통방식을 좀 더 명확히! 사유 문의주신 부분에 대해 준비되지않은 figma 이미지(내가 알아볼수있을 정도로 정리해놓음, 투명도 등을 정확하게 해놓지 않음)로 급하게 설명하려다보니, 말로 설명하게 되는 부분이 있었다. overlay, backdrop 같은 용어에 대한 정확한 정의에 대해 스스로 자신이 없어서 한번 더 묻다보니 한 큐에 소통이 안되는 부분이 있었다. => 대화가 아주 살짝 돌아갔음(모두가 A를 이야기했지만 서로 B를 이야기하는 줄 알았던 느낌) - Foundation을 명확히! 기존에는 감으로 margin, padding을 잡았다. 새롭게 배운건 보통 8의 배수로 margin, pad

agnusdei1207

오버레이 네트워크를 사용하기 위해서는 도커 스웜(Docker Swarm)을 사용하여 컨테이너를 클러스터로 구성해야 합니다. 도커 스웜은 여러 호스트에 걸쳐 컨테이너를 관리하고 오케스트레이션을 할 수 있는 도커의 내장 오케스트레이션 도구입니다. 아래에서 오버레이 네트워크를 생성, 관리, 및 사용하는 예시를 보여드리겠습니다. 1. 도커 스웜 초기화 먼저, 도커 스웜을 초기화합니다. 스웜 매니저와 워커 노드를 설정하고 클러스터를 생성합니다. 2. 오버레이 네트워크 생성 스웜 매니저 노드에서 오버레이 네트워크를 생성합니다. 3. 서비스 생성 및 오버레이 네트워크 사용 오버레이 네트워크를 사용하여 서비스를 생성합니다. 4. 서비스 스케일링 서비스를 여러 레플리카로 스케일링합니다. 서비스를 여러 레플리카로 스케일링한다는 것은 도커 스웜(Docker Swarm) 또는 컨테이너 오케스트레이션 도구를 사용하여 서비스의 복제본(레플리카)을

agnusdei1207

RW 레이어(Read-Write Layer)는 컨테이너를 실행하면서 발생하는 파일 시스템 변경 사항을 저장하는 곳입니다. # RW 레이어는 컨테이너 생성 시 생성되며 컨테이너 내에서 발생하는 모든 쓰기 작업은 해당 레이어에 저장됩니다. # 이렇게 함으로써, 컨테이너 내부의 파일 시스템을 변경하더라도 원래의 이미지는 그대로 유지됩니다. # 컨테이너가 삭제되면 RW 레이어와 함께 삭제됩니다. # RW 레이어는 컨테이너의 변경 사항을 추적하여 필요한 경우 이를 확인하고 원래 상태로 되돌리는 데 사용할 수 있습니다. 오버레이 파일 시스템에 대한 상세 설명: 오버레이 파일 시스템은 컨테이너 이미지의 계층 구조를 유지하기 위해 사용되는 합치기 유니온 파일 시스템입니다. # 오버레이 파일 시스템은 상위 레이어와 하위 레이어를 합친 가상 파일 시스템을 만들며, 원래의 레이어는 변경되지 않습니다. # 컨테이너 시작 시, 오버레이 파일 시스템은 하위 레이어로부터 파일을 조회하고, 해당 파일

oasis444

overlay란? overlay는 기존 View 위에 다른 View를 추가하는 데 사용됩니다. 추가된 View는 기존 View와 겹쳐지며, 추가된 View의 크기와 위치는 기존 View와 상대적입니다. 사용 예시 Hierarchy로 View를 살펴보면 아래와 같습니다. ZStack vs overlay View 위에 다른 View를 추가하는 데 사용하는 것이라면 ZStack과 차이점은 무엇일까요? 아래의 코드를 통해 알아보겠습니다. ZStack은 z 축으로 View를 쌓기 때문에 각각의 V

parkheeyeun

이렇게 마우스를 오버했을 때 글자가 나타나는 효과를 부여할 것이다. 소개를 써줄 p태그와 이미지를 넣을 img태그를 사용한다. 마우스를 오버했을 때 설명이 보여야 하므로 overlay라는 클래스로 설명을 감싸준다. overlay는 일단 안보이게 할 것이다. css구조는 다음과 같다. container에 position: relative를 주어야 설명이 이미지 위에 올 수가 있다. container에 넓이와 높이를 설정한 후 img에는 그 속성을 이어받도록 한다. overlay클래스에 무언가 좀 많다.... position: absolute로 설명을 이미지 위에 띄우고 위치를 설정한다. overlay도 넓이와 높이를 상속받도록한다. display:flex를 준 이유는 글씨 때문

gomiseki

⚙ 자잘한 버그들 &nbsp RIOT API나 LCU에는 자잘한 버그들이 있다. 예를들면 솔랭 데이터를 가져오는데 있어 챔피언의 공식 이름이 다른 경우 (Fiddlesticks -> FiddleSticks), LCU에서 추출한 participant에는 gameName과 name이 둘 다 있는데 이게 같을 때도 다를 때도 있었고, 전 시즌 티어에 대한 데이터는 줬다가 안줬다가 property가 오락가락한다(이게 사실상 매우 치명적이었다). 그리고 API에러도 상당히 빈번하게 발생한다. &nbsp API상태가 정상이라면 이런 에러가 발생했을 때 같은 요청을 계속 수행할 수 있도록 이전에 짜놓은 코드를 응용해 api call메소드를 다시 만들었다. 우리가 잘 아는 페이지들에서 유사한 방식을 쓰지 않을까(?) 생각해 본다. &nbsp 또한 프로젝트 시작할 때는 몰랐던 Promise.all을 API Call에 적용했고 멀티서치 시 엄청난 속도 향상을 맛봤다....

gomiseki

리팩토링 시작 🤔 Electron이거 어떻게 돌아가는거지? &nbspElectron 공식문서를 보면 근본적인 동작과정을 파악할 수 있다. 기본적으로 electron 설치 후, package.json에 main으로 동작할 스크립트를 지정해주고, electron 스크립트를 실행하는 것이 전부라고 할 수 있다. 이런 식으로 작성하고 main.ts에 콘솔 스크립트 입력 후 npm start를 해보면 콘솔이 찍히는 것을 확인할 수 있다. React나 Vue 같은 프레임워크를 얹을 때에는 main 스크립트에 BrowserWindow API를 이용해 빌드된 웹뷰를 띄워준다는 개념이 정리되어있다면, 프론트엔드 스택에 구애받지않고 electron앱을 구성할 수 있을 것이다. 이전에 Electron forge + react + ts +

gomiseki

🔧 구현 가능성을 봤다면....리팩토링.... &nbsp개인 프로젝트를 할 짬이 많지는 않았는데 간만에 조금 짬이 생긴 것 같다. 이 프로젝트 목표는 >- 어딘가 공개할 만한 퀄리티의 코드 인스톨러 까지 꾸며서 배포 Riot API Production Key를 Proxy Server로 제공하여 key보안성 강화 였는데, 정신없이 기능 구현에만 몰두하고 보니 영 품질이 좋지 못하다. 또한 코드 퀄리티와 포매팅에 큰 신경을 안썼는데, 정신차리고 보니 남들에게 선보일만한 것이 전혀 못된다는 생각이 들었다. &nbsp또한 프로젝트 규모가 커짐에 따라 확실히 기본세팅된 웹팩 환경에서는 빌드나 개발모드가 속도면에서 영 좋지못한 경험을 안겨줬다. Electron forge를 이용해 프로젝트 빌딩을 해왔는데, Electron 숙련도가 낮다면 좋은 방법이 될 수 있겠으나, 사실상 검색하면 나오는 프로젝트들 중에 Electron을 처음 사용해보는

gomiseki

😎 Data Dragon을 활용한 유저 정보창 꾸미기 &nbsp롤에서는 공식적으로 게임asset들을 무료로 제공하고 있다. 유저 아이콘이나 챔피언 초상화 같은 것들이다. 하지만 공식적으로 제공하는 asset들은 다소 한정적이고, 비공식적으로 거의 모든 asset들을 이용할 수 있는 Community Dragon같은 사이트들이 있다. &nbsp디자인에는 영 감각이 없다는걸 자각하고있지만...ㅋㅋ 오버레이 화면 작업전에 일단 기본 페이지부터 작업하고 있다. 미완성이지만 롤 클라이언트 실행시 다음과 같은 홈화면을 볼 수 있다. 🥨 커스텀 알고리즘 설정 페이지 &nbsp 플레이어의 위험지수를 나타내는 알고리즘을 사용자가 커스텀 할 수 있도록 설계 중이다. 여러가지

gomiseki

💫 styled-components에서 테마 팔레트, 폰트 공급 &nbsp일단 전역적인 테마 팔레트와 폰트를 DefaultTheme으로 공급했다. 디자인에는 영 재능이 없는 듯 하다. 별거 아니지만 typeScript 관련해서 재밌는 오류가 있어서 작성한다. &nbsp벨로퍼트님의 리액트 강의를 보면 다음과 같은 코드가 있다. &nbsp이를 타입스크립트에 적용하면, theme.palette[color] 부분에서 오류가 발생한다. 타입스크립트에서는 오브젝트 인덱싱을 위해 string literal type만을 허용하는데,string literal type은 string보다 좁은 의미의 타입으로 불변하는 read only string에만 시스템이 부여한다. 위 코드의 color는 매개변수로 언제든 변하는 sting이므로 default theme에 index signature 속성을 부여하면 된다. style.d.ts 💭 Ready 컴포

gomiseki

💬 RIOT API Hook, Module 만들기 &nbspIPC통신이 매끄럽게 해결된 이후로 폭주해서 본격적으로 API를 이용하기 위한 hook과 모듈들을 짜기 시작했다. 꽤 시간 잡아먹은 오류 중에 기억에 남는 건 >This expression is not callable. Not all constituents of type 'boolean | any[] | ((data: any) => void)' are callable. Type 'false' has no call signatures. 이런 것이었는데, 원인은 커스텀 훅의 리턴 배열 순서에 있었다. useRiotAPI(작성중) &nbsp마지막 부분의 리턴값이 원래 배열이었는데, 계속 수정하다보니 작성 순서대로 리턴하지 않게되었다. 그 경우 함수를 호출할 때 에러가 생긴다. 그래서 항목이 적을 때는 array, 많을 때는 object를 추천한다는 글을 봤다.

gomiseki

📚 Electron IPC > 갑자기 생각난건데 드디어 &nbsp를 외웠다. 나는 문단 처음이 띄워지지 않으면 굉장히 화가나던데 아무도 그런데서 불편함은 없나보다. 자동으로 첫 스페이스에 넣어줄 순 없는걸까..... &nbsp아무튼 이전에 나는 다른 프로세스들과 상호작용해야 하는 기능들()을 메인프로세스 코드(index.ts)에서 작성했다. 이전에 설정한 LCU코드에의해 픽창에서는 이벤트가 발생할 때 마다 정보가 찍힌다. > ** data 일부** &nbsp위에서는 지웠지만 우리 팀 정보에도 summonerId가 다 존재한다. 이제 이 정보들을 main프로세스에서 renderer프로세스(React component)로 옮겨서 riot API에 의해 전적이 불려오도록 가공해야한다. 따라서 main프로세스와 renderer프로세스의 통신(Inter Process Communication) IPC가 필요하다. &nbsp리액트는 렌더러 프로세스 위

gomiseki

📚 Layout 우선 레이아웃 처리부터 했다. 다음과 같은 코드로 롤 클라이언트에 프로그램을 붙이고, >overlayWindow.attachTo(mainWindow, 'League of Legends') html과 body 100%를 줘보니 롤 클라이언트는 1280x720로 되어있었다. 픽창에 맞춰 픽셀단위로 컨테이너를 설정하고 absolute포지션을 줬다. 픽에 방해가 되지않게 클라이언트 창의 남는 부분을 최대한 활용하고, 세부정보는 모달로 띄워서 보여주기로 계획했다. 📋 LCU Library &nbsp롤에서 쓰이는 API는 크게 두 갈래이다. 라이엇 디벨로퍼에서 자체 제공하는 게임데이터를 제공하는 Riot APi와, 롤 클라이언트에서 소켓 통신

gomiseki

☕ 배경 주저리 &nbsp난 초보 주제에 100라인 당 롤 세판을 주기적으로 해줘야 에너지가 공급되는 쓰레기 개발자다. 그정도로 롤에 진심이기에 라이엇 API를 사용한 프로그램 짜기는 내 오랜 염원이었달까... 일례로 OPGG 데스크톱 앱이 출시되기 전 클로즈 베타테스터 모집때도 '일렉트론으로 개발 될 것 같은데 만들어지는 과정이 궁금해서 뽑아주세요'라고 적었고, 당시 디스코드에서 여러 의견도 내어봤다. &nbsp그 중 하나 기억에 남는 것은 '오버레이로 픽창에서 전적검색이 용이하게 해주세요'라는 제안이었는데, '검토해보겠다'는 답변을 받았지만 이루어지지는 않았다. 별도의 창에서 전적검색을 일일이 확인하는 것은 다소 불편하다. 별개의 창에 시간을 뺏기면 상대 픽을 확인하고 룬 스펠을 고민할 시간이 그만큼 줄어들기 때문이다. 그래서 오버레이 형식의 전적 검색이 있었으면 했는데, 받아들여지지 않은 것은 일렉트론에서 오버레이에 대한 레퍼런스가 적고 기존 프로그램

broccolism

발단: 이거 밑에 레이어가 있어야 해요 > 🧑🏻‍🎨 자동 완성 검색창이에요! 검색어 입력하면 실시간으로 밑에 키워드가 나오고, 그 아래 레이어에 결과가 보였으면 좋겠어요. > 👩🏻‍💻 그러니까 구글이나 네이버 검색창 같은거 말씀이시죠? > 🧑🏻‍🎨 네 맞아요! Stack을 사용해서 아래쪽에는 검색 결과, 위쪽에는 자동완성 키워드를 보여주자! 그런데 stack을 사용하면 전체 페이지를 아래쪽, 자동완성 키워드 목록을 위쪽에 놓아야 하는데... 이렇게 하지 말고 검색바 + 자동완성 키워드 목록 세트를 단일 위젯으로 분리시킬 방법은 없나? => 플러터에서 제공하는 위젯만 잘 써먹으면 스택을 사용하지 않고 구현할 수 있다. 1. Overlay로 위에 쌓기 Overlay는 Stack의 일종이다. Overlay에게 전달된 child 위젯은

drv98

1. main 태그 아래에 문장 제목 넣기 h2 2. img 태그 본문에서 첫번째 문장 뒤에 넣기 이미지는 원하는 것으로 넣어도 된다. 픽사베이 언스플래시 3. img 태그 CSS 위치는 body 아래에 넣기 4. div( img 태그 + div( 겹쳐질 문장 ) ) 5. CSS 하기 CSS 6. 이미지 배너와 사이드 바가 겹치게 ![](https://images.velog.i