[개발일지] - 62

페이지 레이아웃에서

기존 사이트와 유사하게 내용을 변경하고

관련됨 페이지를 상세 정보 페이지와 통합했다.

 

SAP와 관련된 정보를 요청했지만

해당 부분에 대한 매칭이 전혀 안되기 때문에

해당 부분은 추가 문의를 진행할 예정이고

validation들을 걸어준 부분의 기능은 테스트가 끝났지만

사용자가 flow 에러가 발생한 경우 관리자에게 문의하라는 내용만 나오기 떄문에

flow 내부에서 어떤 기능으로 사용자에게 해당 에러에 대한 추가 정보를 줄 수 있는지 확인하다가

Error가 발생한 경우 분기 처리가 가능하다는 것을 알 수 있었고

validation이 발생하는 부분에 에러핸들링을 만들었다.

 

flow에서 자체적으로 제공하는 flow error message도 존재했기 때문에

해당 값을 화면에 display text로 띄워줬는데

아쉽게도 메일에 전송되는 내용 형태 그대로 나왔기 때문에

해당 validation 경고문만 보여줄 수 없다는 부분의 완성도는 떨어졌다.

 

그렇다고 해당 에러 예외처리 부분만 떼서 진행하려면

추가로 class를 생성해서 작성해야 했는데

테스트클래스도 작성해야 하고 시간도 추가로 들어가는데

요청사항도 아닌 부분에 굳이 시간을 더 소모할 필요성은 느끼지 못해서 이정도로 마무리했다.

 

두번째 프로젝트의 Form을 생성하는 부분으로 넘어왔는데

Sites 부분에서 게스트들이 접속할 수 있는 페이지를 만드는 것과

작성한 Visualforce page와 연동시키는 것 까지는 무리없이 진행할 수 있었고

해당 게스트 유저의 프로필에 들어가서 권한을 부여하는 것 까지는 이전처럼 순조롭게 진행했다.

 

하지만 권한을 하나씩 부여해도 게스트유저에 제대로 데이터가 표기되지 않았는데

알고보니 sharing rull 부분에서 privatie으로 되어있었다.

 

이전에 다른 게스트 페이지 RMA 관련해서 작성하시던 분이 계셨기 때문에

당연히 이 권한 부분은 진행하셨을거라고 생각했는데

전체 공유 부분의 권한이 되어있지 않은 것은 의아했지만 추가로 설정을 완료했다.

 

그렇게 진행해도 일반적으로는 값이 들어오지 않았고

without sharing으로 진행해도 줄 수만 표현되고 내부 값들은 채워지지 않아서 당황했다.

 

원인을 곰곰히 생각해보다가 Item 부분에서 개체에 대한 권한은 부여했지만

필드의 세부적인 부분에 read 권한을 채워넣지 않았기 때문에

해당 레코드에는 접근했지만 필드의 값은 가져오지 못했다는 사실을 깨달을 수 있었고

Item 개체의 필드들에 read 권한을 부여하니 드디어 제대로 값을 받아올 수 있었으며

without wharing을 제거해도 정상적으로 값을 가져왔다.

 

이제 input으로 값을 가져와서 넣어주는 작업과

헤더에 들어가는 값들을 매칭만 진행하면 일차적으로는 완료되고

이 페이지를 전송할 수 있게 이전 단계에 고객에게 체크하는 페이지와

해당 체크를 할 경우 연계적으로 메일까지 발송하게 만드는 프로세스가 필요했다.

 

Input의 값을 넣어주는 단계에서 생각보다 시간을 많이 잡아먹었는데

개체 사용 자체가 문제인 것 같아서 새로 String으로 변수를 할당한 다음

해당 값에 input-text와 연동하고

update를 하기 전 개체의 해당 필드에 string을 넣어주니 문제가 해결되었다.

 

input의 레이아웃을 조금 더 신경써주고

실제로 작동하는지 테스트한 다음 헤더 부분의 데이터가 정의되지 않았는데

어느정도 맞을 것 같은 필드들을 매칭시켜서 값이 출력되는걸 확인하고

해당 필드와 레이블, 목적 등을 정리한 다음 사진과 생성한 Form 페이지 링크를 고객사에 전달했다.

 

아마 내일이면 해당 필드의 매칭이 되서 올 것 같은데

오전 중에는 input form을 마무리하고

추가로 email template 부분까지 하나의 포맷으로 마무리한 다음

오후에는 오후에 진행할 회의 준비를 진행해야겠다.

 

저녁식사 후 7시 40분쯤 슬슬 form 페이지를 마무리해서

다른 페이지를 미리 만들고 퇴근하려고 헀는데

메일을 확인하니 운영서버에 오류가 발견되었다는 내용을 볼 수 있었다.

 

충격적이게도 이전에 내가 작성한 인터페이스에서

두 필드가 바뀐채 배포되어서 거꾸로 들어갔다는 내용이었는데

개발서버도 아니고 운영서버에 배포된 코드의 필드가 거꾸로라 큰 충격을 먹었다.

 

개발이 적용된 후 사용할 필드기 때문에 아직 실제 사용은 하지 않지만

그래도 에러가 발견되었기 때문에 빠르게 수정해야 할 것 같아서

바로 문제 해결에 들어갔다.

 

인터페이스 필드 중 두개만 순서가 바뀐 것이기 때문에

해당 필드를 수정하고 개발서버에서 운영서버로 배포를 진행했다.

 

아웃바운드에 올린 다음 인바운드로 받아서 테스트를 하고 배포하는 단계인데

테스트 부분에서 전체 테스트, 로컬 테스트, 지정 테스트(값 없음), 지정 테스트(테스트 케이스 제대로 넣음)의 4번의 시도 끝에 배포를 성공할 수 있었다.

 

배포를 통해 정상 처리는 가능하게 했지만 값은 바뀐 상태였기 때문에

이전 배포 시간을 확인하고 해당 시간 이후에 변경된 모든 데이터를 확인했다.

 

변경된 데이터라고 하지만 두 필드만 수정하면 되기 때문에 큰 무리는 아니었지만

해당 데이터를 변경하던 도중 필수 지정된 값이 있었는데

해당 필수를 잠깐 풀고 값만 바꾸려고 들어가보니 개체의 필드는 필수 지정이 되어있지 않았다.

 

왜 이런 말도 안되는 일이 벌어졌는지 생각하다가

9시가 다 되어가는 시점에도 작업중이시던 회사분에게 질문하니

레이아웃 페이지에서도 페이지 필수 지정이 가능하다고 알려주셨고

해당 부분에 확인하니 진짜 필수가 지정되어 있어서 해당 필드 필수 지정을 임시로 해제하고

변경된 모든 값들을 원래대로 돌린 다음 필수 지정을 복구했다.

 

내일 해도 될 것 같지만 에러 자체의 해결은 빠를수록 좋고

내가 만든 에러였기 때문에 확실하게 처리하고 싶어서 처리하고 나니 9시가 넘었는데

정리된 내용으로 메일도 보내고 일정을 마무리하니 9시 20분쯤에 퇴근할 수 있었다.

 

 

(1).백준 17614번 369는 해당 숫자까지 369 게임을 진행할 경우

몇번의 박수를 쳐야 하는지를 묻는 문제였다.

 

각 자릿수에 3이 들어갈 경우 박수를 쳐야 헀기 때문에

333의 경우 3번을 6666의 경우 4번을 치는 등 3의 배수 체크가 필요했는데

모든 문자열을 합친 다음 3,6,9에 필터를 걸고 길이를 측정하는 방식으로 진행했다.

 

천만까지의 숫자를 처리하더라도 1초도 걸리지 않는 것을 확인하고

100만까지의 제한이라 부담 없이 제출했는데

간단한 문제라 그런지 엄청 많은 테스트케이스를 돌리는 것 처럼 보였는데

대략 1~2분정도 돌아간 끝에 통과했다.

const input = 1000000
let str = ''
for(let i = 1 ; i <= input ; i++){
    str += i
}

console.log(str.split('').filter(el => el === '3' || el === '6' || el === '9').length)