[개발일지] - 151

오늘은 출근하자마자 팀장님이 url 하드코딩의 문제에 대해 알려주셨는데

이메일 템플릿 등 일회성 작성이기 때문에 상관없다고 생각했지만

해당 부분을 운영에 배포하게 되면 변화가 생기기 때문에 하드코딩을 사용하면 안되는 부분이었다.

 

아래처럼 링크 부분에 하드코딩이 아닌 메서드를 사용해서 값을 넣어주고

메서드에서는 site에서 id를 찾고 그 id를 통해 SiteDetail에서 DurableId과 매칭이 가능했다.

<a href="{! siteUrlMap['Link'] + '?id=' + objId}">

 

Custom Label이라는 기능이 있는데

컴포넌트를 사용할 수 없는 이메일 템플릿 등에서 사용해야 하는 것으로

이메일 템플릿 등의 html 페이지에서도 호출이 가능하기 때문에

하드코딩 대신 Custom Label 사용을 해야 하며

만약 메서드 내부 사용과 템플릿 사용등이 혼용될 경우에는

Custom Label으로 통일하는 것도 나쁘지 않다.

`<apex:variable var="billingAddress" value="{!$Label.BillingAddress}"/>`

`{!Label.MyLabel}`

 

자동화는 오늘도 에러가 발생했는데

원인 파악 결과 파일만 생성해주고 중간에 있는 서버에서 어떤 파일을 처리했는지 알려주지 않는 문제였다.

 

해당 부분에 대해 문의했지만 SQL 커넥션 관련 문제인 것 같다는 애매한 답변이 왔고

다시 시도한 결과 정상 처리되긴 했지만

새벽에 연결이 불안정하면 또 에러가 발생한다는 의미기 때문에 아직은 불안한 것 같다.

 

첫번째 프로젝트에서 어느정도 필수 기능들은 다 반영된 것 같아서

권한을 설정하면서 필요한 프로필들을 구분해 유저들로 확인하는데

빌더 관련 문제가 발생해서 문의로 시간을 많이 잡아먹었는데

알고보니 잠금처리된 레코드라 데이터가 생성되지 않는 문제였다.

 

다음에는 특정 작업이 진행되지 않는 경우

해당 레코드가 잠금상태인지도 고려해봐야겠다.

기존에는 직군들이 Role로 분류되면서 플랫폼 사용자였는데

해당 사용자들의 플랫폼 일반 사용 프로필에서

해당 프로필을 복제한 다음 각각에 맞는 권한을 추가한 프로필들로 변경하기 전

고객사에 권한이 확장된 프로필로 변경에 대해 문의한 다음

문의 처리해도 좋다는 답변을 받고 프로필 변경 작업을 진행했다.

 

이후 페이지 레이아웃 정리도 필요했는데

레코드 타입이 두가지에 따라 다른 작업이 진행되기 때문에

각각 필요한 필드들을 볼 수 있도록 구분하는 작업을 진행했다.

 

페이지 레이아웃에서는 이미 사용된 필드를 누를 경우

해당 필드로 바로 이동되며 하이라이트 처리가 되기 때문에

해당 필드를 검색한 다음 클릭하는 방식으로 개발서버와 동일한 구성으로 변경했으며

상단에 추가되는 부분을 찾지 못해 고생했는데

상단 레이아웃을 수정하는 방법은

“축소 레이아웃”을 사용해야 하는 것이었다.

 

축소 레이아웃을 생성하고 넣어줄 필드를 선택한 다음

해당 축소 레이아웃을 지정한 페이지 레이아웃에 할당해주면

해당 페이지 상단에 지정한 필드들이 들어간 것을 볼 수 있다.

 

두번째 프로젝트의 템플릿 등에 대해 내일까지 정리해서 보내준다는 내용도 왔는데

자꾸 이상한 요구사항들이 붙어서 불가능한 부분들에 대해 정리해 참고자료로 보냈다.

 

벌써 저녁시간이 되었기 때문에 페이지 레이아웃을 마무리하고 저녁식사를 한 다음

이번에는 레코드페이지에서 component들을 원하는 방식대로 이동했는데

개발서버에는 있는 “활동” 목록이 보이지 않아서 검색해보니

개체를 생성하는 시점에 이미 생성을 했어야 하는 것 같았다.

 

동일한 내용을 가지고 있는게 더 좋을 것 같아서

개체 메인 편집 부분에서 활동란에 체크를 진행했고

레코드페이지에서 활동란을 추가할 수는 있었지만

이유는 모르겠지만 레코드가 존재하지 않는다면서 내용이 뜨지 않아서 그냥 삭제했다.

 

일부 필드는 sold to party와 ship to party의 구분 없이

Account를 기준으로 들어간 부분이 있었는데

운영서버로 와서 보니 그제서야 ship to party 데이터가 존재했다.

 

해당 부분을 바꾸고 싶지만 이미 개발에서 그렇게 적용했고

해당 부분을 ok 받고 운영에 배포가 끝난 상황이기 때문에

해당 필드 변경에 대한 부분은 내일 물어보고 변경해야 하는데

내일 두번째 프로젝트를 빠르게 진행하고 싶었지만

첫번째 프로젝트 마무리에 시간을 좀 더 뺏길 것 같다.

 

 

(1).백준 25641번 균형 잡힌 소떡소떡은 소세지를 의미하는 s와 떡을 의미하는 t의 갯수가 같아야 하는 문제였다.

 

최대한 많이 남긴 상태로 균형을 잡아야 한다고 할 때

왼쪽, 오른쪽 자유자재로 제거가 가능하다고 생각해서 어렵다고 생각했지만

왼쪽에서만 뽑기 때문에 체크해야 할 변수가 상당히 줄어들어서

간단하게 while 내부에서 shift로 왼쪽에서 하나씩 빼며 진행했다.

 

만약 이게 몇천에서 몇만자리까지 넘어가거나

시간제한이 촉박한 문제였다면 reverse를 통해 한번 뒤집은 다음

pop으로 진행해서 시간복잡도를 고려했겠지만

100글자 제한이 있었기 때문에 무난하게 shift로 마무리했다.

const input = `7
sttstts`.split('\n')[1].split('')

let s = 0
let t = 0

for(let i = 0 ; i < input.length ; i++){
    if(input[i] === 's'){
        s++
    }
    else if(input[i] === 't'){
        t++
    }
}
while (s != t) {
    if(input.shift() == 's'){
        s--
    }
    else{
        t--
    }
}
console.log(input.join(''))