Happy Programmer

금요일까지 일정 관련 답장이 오지 않을 경우 확인을 해야 했기 때문에

해당 키워드로 전체 메일을 확인해서 분류해둔 다음 테스트코드를 미리 정리하기로 했다.

엄청 많이 나왔지만 그나마 클래스와 트리거는 17개로

17개에 맞는 테스트코드 매칭 작업을 시작했다.

5개정도는 이미 테스트코드가 존재했기 떄문에 퍼세트를 기록하는 정도에서 넘어갔고

나머지 2개는 필드 변경으로 인해 작동 자체가 되지 않았기 떄문에

필드 수정 및 추가된 트리거 또는 함수의 테스트를 진행해서 기준치 75%를 넘겼다.

남은 12개의 테스트코드를 하나씩 작성하는데

생각보다 순조롭게 테스트코드를 해결할 수 있었지만

마지막 하나의 테스트에서 문제가 발생했다.

다른 테스트코드 또는 코드에서는 전혀 상관없이 사용하던 특정 상태값에서

상태값 api를 입력했음에도 값이 들어가지 않았다.

생각해보면 테스트코드 외에서만 사용했고 테스트코드 내부에서는 api 코드르 사용하지 않았기 때문에

테스트코드는 pickList에 있는 api를 인식하지 못한다는 의심이 들기 시작했고

대부분의 팁들도 필드 내부에 있는 “선택 목록을 값 세트에 정의된 값으로 제한합니다.”를 끄고 진행하기를 권장했다.

api가 아닌 value를 넣어보기도 하고 하나씩 뺴보기도 했지만

확실히 테스트에서는 api값을 넣어도 pickList가 되지 않는다는 확인만 하게 된 후

필드 내부에 가서 “선택 목록을 값 세트에 정의된 값으로 제한합니다.”를 해제하니

해당 부분은 정상 처리되었지만 에러가 다시 발생했다.

에러의 원인을 보니 다른분이 만든 pdf 생성까지 트리거로 엮여있었기 때문에

특정 상태값이 되면 만들게 되는 것이었고

결국 해당 상태값만 테스트를 제외하니 99%로 통과할 수 있었다.

sfdc에서 home, end 키를 통해서 개체나 필드, 클래스 등을 대량으로 확인해야 빠르게 로딩이 되는데

언제부턴가 home, end 키가 되지 않아서 답답하면서도 그냥 사용하고 있었는데

오늘 참지 못하고 인터넷에 검색해보니 캐럿브라우징이라는 기능이 멋대로 켜져서 그런 것이었다.

캐럿브라우징은 마우스가 없는 환경에서 웹서핑을 할 수 있게 돕는 보조적인 기능이라고 하는데

F7을 눌러서 끌 수 있기 때문에 당장 꺼버리고 home, end 키를 정상 사용했다.

테스트코드를 모두 작성했기 때문에

남은 업무는 PDF 생성(전달 아직 못받음), 인터페이스 오류 탐색(회신 대기), 요청사항 수정(완료 후 연구실 회신 대기) 등 전부 회신 대기 상태였기 때문에

기본 sfdc 개발에도 필수적이면서 인터페이스팀으로서 정말 중요한 SQL 학습을 하기로 했다.

SQL 학습을 시작하면서 충격적인 것을 발견했는데

ORDER BY a , b 형태로 두가지 정렬을 할 수 있는 것이었다.

SFDC의 정렬은 멍청해서 하나로 밖에 되지 않고

두개로 하려면 해당 필드를 다시 재조회 하라는 등의 답변만 봤기 때문에

이런건 처음 알았다고 동기분과 대화하던 중

어? 그거 세일즈포스에서 안돼요?? 안해봐서 모르겠네 라고 하셔서

직접 안되는 모습을 보여드렸는데 황당하게도 잘 됐다.

저번에 자바스크립트로 5~10분이면 해결할 수 있는 것을 apex로 3시간이 걸렸다고 했었는데

이것만 알았어도 apex로도 10분이면 해결할 수 있었는데 확실히 아는 것이 힘인 것 같다.

sql을 학습하는게 오히려 업무시간 효율성이 더 빠르게 증가한다는 사실을 바로 체감할 수 있었기 때문에 조금 더 집중해서 sql 학습을 할 수 있을 것 같다.

sql 학습 게임 같은게 없냐고 하시긴 했는데

학습이라도 게임으로 하고 있는건 조금 눈치가 보일 것 같아서

그냥 프로그래머스의 sql 문제를 쉬운 것 부터 차근차근 풀기로 했다.

1.fieldName as changeName 형태로 출력 필드명을 변경할 수 있다

2.Count(fieldName) as ChangeName 형태로 출력 숫자 이름을 변경할 수 있다.

3.Like로 검색을 할 때는 중간일 경우 ‘%a%’형태로 해야 앞뒤 공백까지 검색이 된다.

4.IFNULL(fieldName, value)로 할 경우 해당 필드가 null인 경우 value로 변하게 된다.

5.IFNULL 형태로 할 경우 해당 값이 그대로 필드명이 되기 때문에 AS newFieldName으로 변경해줘야한다.

6.ORDER BY 로 진행할 경우 ORDER BY a ASC, b DESC 처럼 여러개를 지정할 수 있으며 앞순번부터 진행된다.

7.날짜 포맷을 지정할 경우 DATE_FORMAT(fieldName, '%Y-%m-%d') AS fieldName 형태로 한다.

4시쯤 다시 한번 문의를 했는데 해당 부분에 대해 확인을 할 수 있었고

고객사의 요구사항을 드디어 만족시킬 수 있었기 때문에

해당 리스트의 권한 체크를 각 프로필 계정으로 로그인해서 진행한 다음

고객 요청사항이 끝났기 때문에 내용을 정리해서 메일을 보냈다.

이번에는 조금 더 가독성이 좋게 하기 위해서

대제목은 bold로 크기를 키웠고

알 수 없지만 n번 밑에 n번이 있는 구조인 것은

중간에 위치한 n번은 사이즈를 조금만 더 키우고 bold 처리했다.

그리고 처리가 불가능한 부분이거나 처리는 됐지만 주의사항이 있는 부분들은 빨간색 처리했고

담당자에게 전달한 부분은 노란색으로 처리했다.

SQL은 2시간도 못했는데 

진작 2시간치만 학습했어도 벌써 3시간은 절약할 수 있었을 것 같다.

원래는 자바스크립트 자격증이나 dp2를 취득하려고 생각했는데

이사님이 신기하게 마구 사용하시면서 쿼리만으로 데이터 정보를 취합하는 모습을 보고

저런 사용법도 있구나 하면서 맛만 봤는데 

쿼리 실력도 세일즈포스에 적용이 생각보다는 많이 될 것 같아서

내일도 시간이 남으면 sql 학습을 같이 해야겠다.

(1).백준 15178번 Angles는 주어진 각들을 체크해서

합이 180도가 되는지 확인하고 출력해야 하는 문제였다.

number type으로 변경해야 하기 때문에 가져온 값을 구조분해할당으로 가져오고

합이 180도인지 확인해서 check / OK인지 기존 input값에 더해줬다.

const input = `10
59 60 60
42 68 70
65 65 50
120 31 28
61 61 58
78 61 41
85 85 9
64 82 35
29 102 49
120 30 30`.split('\n')

const result = []

for(let i = 1 ; i < input.length ; i++){
    const [a, b, c] = input[i].split(' ').map(Number)
    result.push(input[i] + ' ' +((a + b + c) === 180 ? 'Seems OK' : 'Check'))
}

console.log(result.join('\n'))

Chapter1. GraphQL
  1.GraphQL의 개념과 특징에 대해 이해합니다.
  2.GraphQL이 왜 자료구조로 Graph를 선택했는지에 대해 이해합니다.
  3.GraphQL과 REST API의 차이에 대해 이해합니다.
  4.GraphQL의 장정 및 단점에 대해 이해합니다.
Chapter2. GraphQL 다루기
  5.GraphQL의 데이터를 조회하는 방법인 query를 작성하는 법을 이해합니다.
  6.GraphQL의 데이터를 수정하는 방법인 mutation을 작성하는 법을 이해합니다.
  7.GraphQL의 스키마와 타입에 대해 이해합니다.
과제
  8.GraphQL의 쿼리를 작성하여 데이터를 조회하는 방법이 어렵지 않습니다.


1.그래프 형태로 자료구조를 관리하는 것으로 각 노드간의 간선을 통해 특정한 순서에 따라 그래프를 재귀적으로 탐색할 수 있으며 아래와 같은 특징들이 있다.

1.GraphQL은 HTTP를 통해 API 서버로 요청을 보내고 응답을 받는다.
2.응답을 받을 시, 데이터 결과를 JSON 형식으로 받는다.
3.GraphQL은 서버 개발자가 작성한 각 필드에 대응하는 resolver 함수로 각 필드의 데이터를 조회할 수 있다.
4.GraphQL은 GraphQL 라이브러리가 조회 대상 schema가 유효한지 검사한다.

2.GraphQL에서는 모든 데이터가 그래프 형태로 연결되어 있다고 전제하고 Graph 형태를 선택했다고 생각한다.

3.REST API는 특정 데이터를 요청할 때 하위 주소값까지는 들어갈 수 있지만 그 데이터의 모든 양을 받아오기 때문에 Overfetch의 문제를 겪으며 하나의 엔드포인트로는 충분한 데이터를 다 받아오지 못하는 Underfetch의 문제도 겪기 때문에 데이터 낭비를 감수하거나 여러번의 요청을 보내야 하지만 GraphQL은 요청사항을 정리해 한번에 원하는 데이터만 받아올 수 있다.


4.GraphQL는 하나의 엔드포인트에서 필요한 정보만 가져올 수 있으며 playground(사실 postman과 유사)라는 테스트 도구가 있으고 서버에는 영향을 주지 않는다는 장점이 있으며

학습에 어느정도의 시간이 필요하며 캐싱이 REST API보다 훨씬 복잡하고 고정된 요청/응답에는 REST API보다 더 많은 크기의 요청을 사용할 수 있다는 단점이 있다.

5.playground의 이름들을 참조해서 클릭하면서 필드, 전달인자, 별명 등의 필요한 부분을 작성한 후 복사하는 방식으로 기초를 익힐 수 있고 원하는 부분의 이름을 변경해 필요한 데이터값만 받아올 수 있다.

6.mutation이라는 키워드를 사용해 쿼리와 유사하게 사용할 수 있다.

7.스키마에 있는 대부분의 타입은 객체 타입이며 모든 스키마는 쿼리 타입을 가지지만 뮤테이션 타입은 가질 수 있고 가지지 않을 수 있다.

8.단순한 데이터 조회 자체에는 어려움이 없이 진행할 수 있었지만 토큰을 발행하고 적용하는 부분에서 어려움을 겪었다. token을 사용할 때는 'token 토큰키' 형태로 넣어주자

오늘은 지나치게 설명이 적어서 그런지 유튜브 강의와 페이지와 여러곳을 탐방했는데 대다수는 fetch에 대한 이야기가 많아 explorer에 대한 실습을 제대로 하지 못한 것 같다..

결국 spaceX인가 하는 배열을 받아서 적용하는건 성공했지만 토큰을 'token 개인토큰'으로 넣지 않고 '개인토큰'으로 요청해서 401오류같은것만 계속 받아보다가 시간이 끝나버렸다.

실습이 주가 되야 하는 과정일 것 같은데 굳이 이걸 이렇게 부실하게 했어야 했나 싶지만

세션 때 설명이 좋았기 때문에 보충이 됐다.