[Main-Project 개발일지]-21

오늘은 이전에는 몰랐지만 백엔드분의 컴퓨터에서 실행하니 깨져보이는 현상을 볼 수 있었다.
깨진 css들은 전부 vw로 너비를 설정했지만 내부 버튼기능들은 텍스트가 들어있기 때문에 일정 크기 이상으로 사이즈가 통일되어있고 그 버튼들의 박스 또한 vw로 구성되어 있었기 때문에
옆으로 긴 모니터를 가진 내가 오른쪽에 콘솔창을 조금 띄워서 맞췄다고 생각했지만
1440같은 해상도를 가지고 계신 분이라면(1920보다 작은건 예상하지 못했다) 깨질 수 밖에 없다는 사실을 알게되었다.

처음에는 글자 크기를 줄이고 버튼의 크기를 vw로 맞춰볼까 생각했지만 그렇게 하면 글자 사이즈가 클 떄도 작아 어색하고 더 많이 작아지면 어차피 글자가 튀어나올 수 있기 때문에 문제가 있다고 생각되었다.

게다가 디자인 자체가 10개의 태그가 글자 길이는 천차만별이지만 버튼의 크기는 통일된 설정이었기 때문에 글자 +padding으로만 버튼을 조절할 수 없어서(일반적 검색용 태그는 padding으로 너비를 결정하는 경우가 많다) 사이즈는 고정시켜야 했기 때문에(figma 기준)

min-width를 통해 최저값을 정해 기준을 정했으며
화면의 넓어 어긋나 보이는 부분들은 max-width를 통해 조절했다.

서버는 아직까지도 합쳐지지 않았기 때문에 로그인시도까지만 가능하지만
그래도 합치기만 하면 기본 구상의 1차완료 느낌은 가능할 수 있을 것 같다.
이번주까지는 재료관리부분까지는 완성을 해야할 것 같다.

회원가입 로그인 부분도 변경된 데이터를 사용할 수 있게 재수정하고
issue를 얼추 관리한 다음 마무리헀다.

저녁에 프론트 팀원분의 연락이 왔는데 
세상에.. 백엔드에서 제공할 것 처럼 하다가 넘어가버린 레시피 api 더미데이터를 관리하고 계셨다.
서버에 태그만 보내면 맞는 데이터가 넘어오는게 정상이라고 생각하고는 있지만 필요한 데이터를 뽑아서 사용하고 싶은데 잘 안된다고 말씀하셔서 같이 객체에 어떤 데이터가 들어있는지 확인하고 내부 데이터들의 규칙을 찾아(이 부분은 팀원님이 이미 xxxxxximg0 +i라는 규칙을 만들어 두셔서 편하게 진행할 수 있었다) 만약 그 값이 ""이 아니라면(이상하게도 규칙을 위해서인지 내부 값들이 없는 ""데이터들이 많았다) 배열에 push하는 방식으로 가공한 다음
mapping 내부에서 삼항연산자를 사용해 끝이 png인 경우(slice(-3)) img 태그 내부에 src{el} 방식을 사용했고 png가 아닌 경우 span 태그 내부 값에 {el}을 작성하는 방식을 통해 이미지, 글, 이미지, 글, 글, 글 (이미지보다 글 숫자가 많으며 매칭될 경우에는 순서대로 매칭되다가 글만 나온다)  형태로 정돈될 수 있게 한 다음 나머지 부분은 css를 관리하시기로 하고 넘어갔다.

솔직히 객체 데이터를 가져오는 것 자체는 부담이 없지만 하나의 데이터에 몇천자가 적혀있는 데이터 1061개를 텍스트 형태로 저장하는 것 자체로도 열어보는데 이런저런 문제가 생겨서(메모장으로 열었다가 몇번 터지고 결국 파일을 지웠다) 백엔드에서 지원할 때까지 미루려고 했는데 만약 프론트 팀원분이 잘 정돈해서 레시피 페이지를 만드신다면 로직을 짜서 레시피 추천 및 이미지 띄우는 것을 해보는 것도 좋은 도전일 것 같다.

 

 

 

CT(1).크리보드라는 문제는 효율적으로 도배할 수 있는 방식을 찾는 문제같았다.
한글자 출력, 전체선택, 복사, 붙여넣기 4가지의 버튼이 있는데 이 부분은 크게 중요하지 않고 출력(1회) => +1, 전체선택,복사,붙여넣기(3회) => *2, 전체선택, 복사, 붙여넣기x회(2+x회) => *(x+1)같은 방식으로 진행된다.
다만 붙여넣기가 4회까지는 최적이지만 그 이상으로 넘어가면 새로 복사 붙여넣기로 하는 것이 더 큰 값을 만들 수 있기 때문에 i-6까지만 체크해야 했으며
i-6으로 점화식을 만들었기 때문에 index 6번까지는 정리해줬다.

let input = 100

let dp = [0,1,2,3,4,5,6]

for(let i = 7 ; i <= input ; i++){
    dp[i] = Math.max(dp[i-1]+1, dp[i-3]*2, dp[i-4]*3, dp[i-5]*4, dp[i-6]*5)
}

console.log(dp[input])

CT(2).3xn타일링은 n-1 *4, - n-2 *1의 점화식을 가지고 있는 문제였지만
100000007로 나눈 나머지를 요구했는데
문제의 3분의1이상이 자꾸 오답이 나왔다.
이유를 곰곰히 생각해보다가 범위가 크면 *4의 수치가 커서 오차가 나오는건가? 싶어서 100번째 값을 넣어보니 -6천만이 나와버렸다.
잘 생각해보면 i-1은 10억이 넘어 작은 수치가 되고 i-2가 9억일 수 있는 상황이기 때문에 기존값에 +1000000007을 한 후 나누는 방식으로 해결했다.

function solution(n) {
    let dp = [1,3,11]
    if(n%2){
        return 0
    }
    for(let i = 3 ; i <= n/2 ; i++){
        dp[i] = (dp[i-1]*4 - dp[i-2]+1000000007)%1000000007
    }
    return dp[n/2]
}

 

CT(3).소수 찾기는 조금은 귀찮은 문제 같았지만 2점밖에 주지 않았다.
0~9로 이루어진 카드 1~7장을 사용해 만들 수 있는 소수의 갯수를 구하는 문제였다.
일차적으로 재귀를 통해 가능한 모든 조합을 만든 다음 new Set을 통해 중복을 제거하고 filter를 통해 소수판별을 한 다음 .length로 갯수를 구해줬다.

function solution(numbers) {
    let answer = []
    let arr = numbers.split('').map(Number)
    
    function recurtion(n,did,num){
        if(n === 0){
            answer.push(num)
        }
        for(let i = 0 ; i < arr.length ; i++){
            if(did.indexOf(i) !== -1){
                continue
            }
            else{
                recurtion(n-1,[...did,i],num*10 + arr[i])
                recurtion(n-1,[...did,i],num)
            }
        }
    }
    function isPrime(num) {
      let sqrt = parseInt(Math.sqrt(num));

      if (num === 1) {
        return false;
      }

      if (num === 2) {
        return true;
      }

      if (num % 2 === 0) {
        return false;
      }

      for (let i = 3; i <= sqrt; i += 2) {
        if (num % i === 0) {
          return false;
        }
      }

      return true;
    }
    recurtion(arr.length,[],0)
    return [...new Set(answer)].filter(isPrime).length;
}