[개발일지] - 462

홈페이지 이전 관련해서 Form 데이터 전체 수신 방식 변경으로 인해 수동 인터페이스를 하고 있는데

협력사에서도 귀찮은건지 링크 전송방식으로 인터페이스를 하기를 강하게 희망했고

고객사에게 되도록 그 방향으로 하게 설득하겠다는 느낌의 메일을 수신했다.

 

사실 링크 방식으로 했으면 저번주에 다 끝내고 다른 업무를 처리하고 있었겠지만

상식적으로 파일이 존재하지 않으면 미리보기 기능도 없고

다른 곳에서 참조하거나 넘어갈 때도 링크를 넘기기 위해 따로 필드를 파야 하고

하나의 개체에 여러가지 링크들을 따로 관리하려면 링크 개체를 따로 파야하고

일도 복잡해지고 고객이 보기도 힘들기 때문에 이제 파일 전송 방식을 거의 확정지었는데

협력사에서는 이제와서 링크쪽으로 하고 싶어하니 당황스러웠다.

 

파일 생성에 대해 확인하고 있는데 팀장회의에 들어가셨다가 돌아오신 팀장님이 회의를 여셨고

뭔가 문제가 있나 싶었는데 다행히 팀 관련 문제는 아니고 전반적인 회사 분위기 개선쪽이었다.

 

현재는 점심시간을 상당히 프리하게 사용하는 분위기긴 했는데

점심시간을 1시간으로 맞춰서 사용해야 한다는 내용과

야근 식대의 경우 야근을 하지 않는 경우에는 청구하지 않아야 한다는 내용이었다.

 

당연한 내용이라 그냥 그런가보다 했는데

제일 중요한건 데이터클라우드 관련 내용이 인터페이스 팀 전원에게 넘어와버렸고

이제는 다 같이 데이터클라우드에 대한 압박을 받게 되어버렸다.

 

저번 금요일에 추가로 업무가 넘어갈거라고 했던 것과 다르게

팀장님께서 업무 강도에 대해 전달을 하신건지 더 넘어오는건 없었고

사실 넘어오는게 아니라도 자격증 공부할 여유 없이 이것저것 할 업무가 많이 줄서있긴 했다.

 

파일 생성 부분은 어떻게 잘 마무리했기 때문에

이번에는 파일 다중 생성 방식을 테스트해봤는데

여러가지 방식을 사용해도 다중 생성은 불가능해보였다.

 

물론 실제 코드로 진행하면 어떻게 다중생성도 별일은 아닐 수 있겠지만

postman으로 예시를 작성해서 보내줘야 하는데 너무 시간을 뺏기는 것 같기도 하고

파일 전송 방식으로 확정도 되지 않았기 때문에 단일 파일 전송으로 하기로 했다.

 

이후 blob방식으로 전달하려고 했는데

문득 SFDC 내부에서 PDF 처리를 할 때 base64 등으로 변경할 때 문제가 발생했었고

hex 변환을 통해서 간신히 파일 변환처리를 했던게 생각났기 때문에

pdf로 파일 변환 테스트가 필요하다는 생각이 들었고

pdf를 base64로 변환한 글자를 구해보려고 했는데 찾을 수가 없었다.

 

결국 파일을 base64로 변환하는 html을 만든 다음

해당 내용에 pdf 등 여러가지 파일을 넣어서 대용량으로 만들고

해당 파일들을 아래와 같이 postman으로 sfdc rest api로 전송했는데

모두 정상적으로 파일이 생성되는 것을 확인하고 해당 내용에 대해 협력사에 전달했다.

{
    "Title" : "TestFile",
    "PathOnClient" : "TestFile.pdf",
    "FirstPublishLocationId" : "0035g000007GALTAA4",
    "VersionData" : "base64 data"
}

 

일단 정의서 예상 방식에 대한 힌트를 먼저 주고

파일 전송방식이 이런 절차로 구현된다는 내용에 대해 설명한 다음

고객사에서 여러 처리를 하려면 링크가 아닌 파일 전송이 필요할 것 같다는 내용을 공유했다.

 

중간에 팀원분이 다른 자리에서 뭔가 열심히 하다 오시길래

뭔가 확인해보니 인터페이스 발송 시점을 못찾고 있어서 같이 봤는데

의외로 꽁꽁 숨겨진건지 작동시키는 class, trigger 등 여기저기를 찾아도 볼 수 없었고

결국 개체까지 들어갔지만 관련 flow들도 전혀 상관없는 내용만 진행되고 있었다.

 

일단 스케쥴 플로를 의심할 수 있는 상황이긴 한데

어디서 시작되는지 고객사랑 연락도 안되는 상황이라고 하시고

다음에 연락되면 다시 문의주신다고 하셔서 그냥 인터페이스 정의나 마무리하기로 했다.

 

Lead 관련 Form 인터페이스만 기존에 11개가 존재했고

협력사쪽에서는 8개 통합, 3개 별개로 4개 인터페이스로 생성을 요청했지만

Lead 하나로 들어가기 때문에 유지보수나 class 확인 등 어려움이 있어보이기 때문에

전체 필드들을 다 엑셀에 정리해서 비교한 다음

각 Form 인터페이스마다 사용되는 필드들을 체크해서 정리해주고

Lead 관련 인터페이스는 하나에서 전체 필드값을 수신하고

null값들은 넣지 않는 방식으로 처리하기로 정리 후 정의서를 작성했다.

 

Lead 관련 정의서를 마무리하고

다른 정의서들에 있는 내용들 중 API 명칭 외에 Label명도 추가해주면 좋을 것 같았고

기존 워드프레스에서 사용되던 Label을 Description에 다 정리해준 다음 마무리하고 퇴근했다.

 

 

(1).백준 2810번 컵홀더는 좌석 규칙에 따라 컵홀더를 쓸 수 있는 사람의 숫자를 구해야 하는 문제였는데

사실 커플석이 추가되면 1명씩 뺏기는게 정상이고 

양 사이드에 1개씩이라 +1개가 있기 때문에 두번째 커플부터는 1개씩 부족하게 증가한다고 계산하면 되는 문제였다.

 

LL여부를 먼저 체크해주는 변수를 만들어주고

전체 순회하며 S인 경우 1씩 증가시키고 넘어가고

L인경우 당연히 LL이기 때문에 i++로 2 증가시키면서

처음 LL인 경우에는 2 그 외에는 1씩 증가시켜주는 방식으로 해결했다.

const input = `9
SLLLLSSLL`.split('\n')[1]

let checkLL = false
let count = 0

for(let i = 0 ; i < input.length ; i++){
    if(input[i] == 'S'){
        count++
    }
    else if(checkLL){
        count++
        i++
    }
    else{
        checkLL = true
        count += 2
        i++
    }
}

console.log(count)