1.SQL에서 AS 뒤에만 명칭을 넣는 것이 아니라 명칭 AS (SELEC …) 형태로도 가능한가 싶었는데

알고보니 WITH 구문을 쓸 때 가상 테이블을 추가할 때만 사용하는 것 같다.

 

2.문장 도중에 ;가 들어갈 경우 에러가 발생한다.

당연한 내용이지만 FROM xx; 상태로 마무리한 다음

다시 수정할 때 가끔 까먹어서 오류 원인을 못찾을 수 있었다.

 

3.RECURSIVE를 사용할 때는 UNION ALL을 사용해야 하는 것 같다.

WITH RECURSIVE A AS (
    SELECT 1 AS RAN
    
    UNION ALL

    SELECT RAN + 1
    FROM A
    WHERE RAN < 10

)

SELECT RAN
FROM A

 

4.RECURSIVE 내부 값을 Join으로 엮을 수 있는데

해당 값들의 비교를 위해서는 ID 등 내부 값들도 어떤 테이블에서 가져올지 명시해야한다.

WITH RECURSIVE A AS (
    SELECT ID, 1 AS GENERATION
    FROM ECOLI_DATA
    WHERE PARENT_ID IS NULL
    
    UNION ALL

    SELECT b.ID, 1 + a.GENERATION AS GENERATION
    FROM ECOLI_DATA b
    JOIN A a ON a.ID = b.PARENT_ID
)

SELECT COUNT(ID) COUNT, GENERATION
FROM A c
WHERE (SELECT COUNT(ID) 
         FROM ECOLI_DATA d 
        WHERE d.PARENT_ID = c.ID) = 0
GROUP BY GENERATION

 

5.WITH 가상테이블로 여러개 지정이 가능하고

해당 테이블 내용을 사용하려면 JOIN으로 가져와야 하기 때문에 1=1 같은 조건이라도 넣어야 한다.

WITH FRONT AS (
    SELECT SUM(CODE) AS FRONTCODE
    FROM SKILLCODES
    WHERE CATEGORY = 'Front End'
),
C AS (
    SELECT CODE AS CCODE
    FROM SKILLCODES
    WHERE NAME = 'C#'
),
PYTHON AS (
    SELECT CODE AS PCODE
    FROM SKILLCODES
    WHERE NAME = 'Python'
)

SELECT CASE 
           WHEN FRONT.FRONTCODE & SKILL_CODE > 0 AND PYTHON.PCODE & SKILL_CODE = PYTHON.PCODE THEN 'A'
           WHEN C.CCODE & SKILL_CODE = C.CCODE THEN 'B'
           WHEN FRONT.FRONTCODE & SKILL_CODE > 0 THEN 'C'
       END AS GRADE,
       ID, 
       EMAIL
FROM DEVELOPERS
INNER JOIN FRONT ON 1=1
INNER JOIN C ON 1=1
INNER JOIN PYTHON ON 1=1
HAVING GRADE IS NOT NULL
ORDER BY GRADE, ID;

 

6.재귀를 호출할 때 a, b 등 이름 지정을 주의해서 사용해야 한다.

WITH RECURSIVE A AS (
    SELECT ID, 1 AS GENERATION
    FROM ECOLI_DATA
    WHERE PARENT_ID IS NULL
    
    UNION ALL
    
    SELECT b.ID, a.GENERATION + 1 AS GENERATION
    FROM ECOLI_DATA b
    JOIN A a ON a.ID = b.PARENT_ID
)

SELECT ID
FROM A
WHERE GENERATION = 3

 

 

인터페이스 유지보수 요청은 오자마자 짧은 시간에 바로 답변했는데

점점 처리 속도가 빨라지고 있고 프로젝트는 아직 협력사쪽에서 처리중이기 때문에

프로젝트 대기 중 SQL 관련 학습을 하기로 했다.

 

그 와중에 다시 프로젝트 관련 문의사항이 들어왔는데

개발서버에 필드가 부족한건지 왜 인터페이스가 정상 처리되지 않는지 문의가 왔지만

확인해보니 운영/개발 레코드가 일치하지 않는데 운영에 존재하는 Key를 가져와서 발생한 에러였다.

 

다른 프로젝트 관련 인터페이스 정의서를 작성해서 보내고 마무리한 다음

위에 작성한 내용의 SQL을 잠깐 공부하고 있었는데

여러개의 프로젝트가 할당중이지만 당장에는 일이 없어보여서 또 하나의 프로젝트에 참여하게 됐다.

 

팀 인터페이스 프로젝트쪽에서 하는 일을 지원했던 것 중

테스트클래스가 상대방이 완성하지 않아 미뤄뒀던 부분을 그냥 결과 없이 mock http로 처리했고

드디어 자바서버 관련 프로젝트에 추가 할당이 되었는데

이클립스, jdk, 톰캣 등 이것저것 설치하면서 시간을 보내다 보니 다시 인터페이스가 들어왔다.

 

황당하게도 이전 인터페이스의 반 이상을 갈아엎어야 했는데

사실 기간 협의 도중에 내가 혼자 끝내버린거라 쌍방과실에 가깝기 떄문에

(상대방에서도 정의서만 주고 샘플 데이터 등이 없어서 우리측 정의서에 맞출거라고 생각함)

빠르게 해당 인터페이스를 다시 진행했다.

 

4시쯤 인터페이스 수정 요청이 들어왔기 떄문에

인터페이스 수정 작업을 진행하다 또 멈추기 싫어서 저녁을 먹고 8시가 넘어서 마무리했다.

 

예전같으면 인터페이스 하나 처리할 때 짧게는 3일에서 길게는 2주까지도 걸렸던 것 같은데

확실히 경험이 쌓여서 그런건지 아니면 실력도 향상된건지 이제 금방 처리하는게 느껴져서

예전보다는 뭔가 인터페이스에 자신감이 생겼다.

 

전혀 급한 업무가 아니지만 한번 한건 일정 단계까지 끝내두고 싶어서

인터페이스 업무만 있으면 늦게까지 하다보니 업무가 끝나면 당분간 할일이 없는데

그러면 또 추가 업무를 할당받고 그러면 또 늦게까지 하는게 반복되니 뭔가 이상한 것 같다

 

 

(1).백준 10693번 Abdelrahman은 연결된 컴퓨터들 사이에 불필요한 전선의 개수를 찾는 문제였다.

 

기본 2대는 하나의 선으로 연결된다고 했기 때문에 필요한 전선의 수는 x-1개고

현재 존재하는 전선의 개수는 y개였기 때문에 각각 백틱을 사용해 출력 형태를 맞춰주고

현재 전선의 개수에서 필요한 전선의 개수를 뺀 값을 대입해 출력했다.

const input = `1
4 5`.split('\n')

const result = []

for(let i = 1 ; i < input.length ; i++){
    const [x, y] = input[i].split(' ').map(Number)
    result.push(`Case ${i}: ${y - x + 1}`)
}

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

'회고' 카테고리의 다른 글

[개발일지] - 285(국회의원선거)  (0) 2024.04.10
[개발일지] - 284  (0) 2024.04.09
[개발일지] - 282(주말)  (0) 2024.04.07
[개발일지] - 281(주말)  (0) 2024.04.06
[개발일지] - 280  (0) 2024.04.05

인터페이스 정의서 생성을 위해서 필드와 테이블을 확인하는데

테이블만 26개에 수신 및 발신을 따로 정의해야 했기 때문에

결과적으로는 37개의 정의서 페이지를 작성해야 했다.

 

초반에 공통적으로 들어가야 하는 부분들에 대한 정리를 진행하던 중

Order 관련 오류가 발생했다고 해서 해당 org의 데이터들을 확인하고

인터페이스 로그에 찍힌 오류를 확인해보니 품목 중 하나의 삭제 시도 단계에서 막혔는데

해당 품목은 사실 다른 곳에 엮인 상태로 관리되고 있기 때문에 삭제하면 안되는 것이었다.

 

SQL로 해당 데이터를 찾아서 확인하니 더 명백하게 알 수 있었는데

기존의 수정사항이 있는 경우 LineNum이 변경되어 있고 기존의 값은 null로 처리되어 있는데

변경을 수치 변경이 아닌 삭제 후 추가로 진행하기 때문에

뜬금없는 삭제 시도를 진행하고 연관된 개체가 잠겨있기 때문에 삭제가 안된 것이었다.

 

원인은 파악했지만 해당 내용은 수정하면 안되는 부분이기 때문에

추후 해당 연관 품목들을 먼저 확인할 수 있게 관계 설정을 해주는 것으로 정리했다.

기본적으로 정의서 내부에서는 통신유형, 연계 방식, 주기, Interfacd Id의 헤더와 Source, Target의 구분을 진행하고 Source, Target 각각 헤더 부분에 System Name, Object(SFDC쪽만), Protocol 등을 정리했고 하단에는 각각의 num, field, type, size, Description 등의 컬럼에 맞춰서 필드를 추가해야 했다.

 

Request, Response 부분을 각각 전부 위의 컬럼대로 정리해준 다음 하단에 EndPoint, Request Body 예시, Response Body 예시를 하나씩 담아주는 방식으로 마무리했는데 하나를 완료하면서 공통적으로 들어가는 방식들을 먼저 마무리하고 그 이후 전체 파일을 복사해서 먼저 37개의 탭을 생성하고 각각 맞는 Interfacd ID, EndPoint, Object Name, Response를 채워줬다.

 

하나의 정의서를 채우는 것에도 여러가지 자료가 필요했는데 기본적으로 Request Sample을 위해서 1회 발송 후 결과를 Response Sample에 넣고 각각 사용하는 필드명이 다르기 때문에 SQL에서 주고 받는 필드명을 먼저 공통 사용하고 SFDC에서 실제로 들어갈 필드의 명칭(CustomObjectName__c, StandardObjectName)등을 넣어야 하는데 해당 값을 찾기 위해 실제로 발송하는 클래스를 찾아서 코드들을 전수조사해야 했고 실제 저장된 값의 타입 및 길이 제한 등을 확인하기 위해 SQL 테이블의 컬럼을 확인해서 Type, Size를 기입했다.

 

apex에서 쉽게 해당 테이블을 찾을 수 있었는데

간단하게 class ObjcetName으로 검색 형태로 전체 검색을 사용하면

해당 클래스 내부에서 재정의 후 내보내는 모습을 볼 수 있었다.

 

인터페이스 정의서를 처음 만드는건 2시간 넘게 걸렸지만

구조를 파악하고 점점 빨라졌는데

안타깝게도 result 부분은 정의해두지 않았기 때문에

복사되지 않아서 결국 모두 새로 추가해줘야 했다.

 

8시 20분쯤 마무리를 했는데

내일 오전 회의가 있기 때문에 회의 전에 마무리할 수 있으면 좋겠지만 안될 것 같아서 아쉽다.

 

 

(1).백준 2750번 수 정렬하기는 예전에 황당하게 틀렸던 문제였는데

이번에도 자꾸 오답이 나와서 이유를 생각해보다가

백준의 질 떨어지는 값 입력 문제가 생각났고

.trim()을 사용해 공백이 포함되는 것을 방지하니 정답 처리가 되는 것을 확인할 수 있었다.

 

문제 자체는 sort 메서드를 사용해 쉽게 해결할 수 있었지만

이런 문제 때문에 초반에 왜 안되는지 답답해했던 기억이 떠올랐다.

 

JS는 정렬 메소드까지 제공되고 있는데 정답률이 26%로 반토막난 가장 큰 이유가 아닐까?

const input = `5
5
2
3
4
1
11`.split('\n').map(Number)
input.shift()
input.sort((a,b) => a-b)
console.log(input.join('\n'))

'회고' 카테고리의 다른 글

[개발일지] - 190(주말)  (0) 2024.01.06
[개발일지] - 189  (0) 2024.01.05
[개발일지] - 187  (0) 2024.01.03
[개발일지] - 186  (0) 2024.01.02
[개발일지] - 185(신정)  (0) 2024.01.01

0.캐싱으로 인한 deploy 지연 해결책은 아래 설정을 끄면 된다.

Setup > Security > Session Settings Enable secure and persistent browser caching to improve performance

1.NVL(a, x)를 사용할 경우 a가 null일 경우 x로 변경하는 집계함수다.

2.Null값은 집계함수에서 무시된다.(그래서 NVL 처리를 할 필요가 생김)

3.Inner Join = 성공한 행만 도출

4.Outer Join = 실패한 행도 같이 도출하며 오라클 등에서는 (+)로 기준 집합을 설정하고

ANSI 조인 문법에서는 LEFT, RIGHT, FULL 등으로 추가할 행의 기준을 잡는다.

5.Cross Join = a, b집합의 각 행을 각각 조합시켜 5, 5의 길이를 가진 집합의 경우 25개의 결과가 나온다.

6.단일 행 함수를 사용하면 행마다 계산이 들어간다.

7.단일 행 함수를 중첩해서 사용할 경우 안쪽부터 계산을 밖으로 진행해나간다.

8.Case의 경우 단일 행을 Case로 시작해서 특정 행이 When일 때 Then으로 변경하는 if return 형태를 띄며 WHEN a THEN a1 WHEN b THEN b1 WHEN c THEN c1 ELSE f처럼 if, else 형태로 사용할 수 있다.

9.Group by가 여러개가 들어간 경우 각각 집합이 되는 것이 아니라 오히려 범위가 줄어든 해당 조건들 기준으로 그룹화된다.

10.DDL - 데이터 정의어(구조) / DCL - 데이터 제어어(권한) / TCL - 트랜잭션 제어어(트랜잭션) / DML - 데이터 조작어(데이터 조작)

11.Unique 조건을 걸 경우 Null 입력이 가능

12.Check()조건을 통해 내부 조건이 true인 데이터만 입력 가능

13.오라클에서는 TRUNCATE등의 DDL을 사용할 경우 Auto Commit이 진행되기 때문에 그 뒤에 RollBack이 있어도 DDL 상단의 내용은 반영이 되며 SQL의 경우에는 RollBack이 된다.

 

인터페이스에 점점 더 깊게 들어가고 있어서 SQL 학습을 진행하고 있는데

겸사겸사 SQLD 준비도 하면 좋을 것 같다.

 

 

(1).백준 21553번 암호 만들기는 공통된 부분이 암호로 되는 것이기 때문에 사실 그냥 결과값을 내면 끝나는 문제였다.

 

하지만 황당하게도 아래 코드는 통과되지 않았는데

.map(Number)를 해도 값은 정상적으로 출력되지만 오답처리가 되었기 때문에

추가 조건이 있는지 6번정도 더 읽었는데 문제 자체의 설명도 난해했고 테스트케이스도 명확하지 않았기 때문에

뭐가 문제인지 고민하다가 .map(Number)를 지우니 통과되는 것을 보고 참 황당했다.

const input = `11299
29`.split('\n').map(Number)[1]

console.log(input)

'회고' 카테고리의 다른 글

[개발일지] - 90  (0) 2023.09.28
[개발일지] - 89  (0) 2023.09.27
[개발일지] - 87  (0) 2023.09.25
[개발일지] - 86(주말)  (0) 2023.09.24
[개발일지] - 85(주말)  (0) 2023.09.23

1.set field level security로 프로필에서 하나씩 추가하지 않고도 새로 추가된 필드의 security를 설정할 수 있다.

 

2.CRM = 고객관리, Salesforce = CRM을 클라우드로 전환한 회사, Sales Cloud = Salesforce CRM 시스템의 일부

 

3.에러로 Save 버튼 사라진 경우 해당 데이터 찾아서 Developer Console에서 생성

ServiceContract scObj = new ServiceContract( 
	Name = '123-456789', 
    AccountId = '0015h00001T1ZrMAAV', 
    StartDate = Date.valueOf('2023-09-22'), 
    EndDate = Date.valueOf('2024-09-22'), 
    Term = 12 
);

insert scObj;

 

4.기본적으로 목록에 없는 그룹 만들기는 비활성화되어 있기 때문에 아래 설정을 해야 한다.

Chatter Settings ->

Allow Records in Groups Check ->

I wnat to enable unlisted groups and understand that i may need to update apxe/Visualforce code in my organization Check

 

5.GROUP BY로 그룹을 만든 후 해당 내부의 count 등의 집계함수로 한 내용을 조회하려면 해당 값을 가져다 쓸 수 있는게 아니라 HAVING을 WHERE처럼 사용해서 진행해야 한다.

SELECT name, COUNT(animal_id) AS count 
FROM animal_ins 
WHERE name IS NOT NULL 
GROUP BY name 
HAVING COUNT(animal_id) > 1 
ORDER BY name;

 

6.null이 아닌 값들 중 중복을 제거해서 가져오라는 문제가 있었는데

Name으로 그룹을 하고 count를 하려고 했는데 그룹을 하지 않고 count를 하는 것과는 무슨 차이가 있는지 모르겠다.

//처음 시도
SELECT COUNT(name) FROM animal_ins GROUP BY NAME HAVING NAME IS NOT NULL

//의도한 수치
SELECT COUNT(name) FROM animal_ins

//정답
SELECT COUNT(DISTINCT name) FROM animal_ins WHERE name IS NOT NULL;

 

 

 

(1).백준 6030번 Scavenger Hunt는 인수들의 조합을 모두 나열해야 하는 문제였는데

범위가 겨우 6000까지였기 때문에 for문을 돌면서 인수들을 배열에 담은 다음

첫번째 숫자를 기준으로 두번째 숫자의 인수들을 먼저 나열하는 방식으로 진행했다.

const [a, b] = '24 2'.split(' ').map(Number)

const arr1 = []
const arr2 = []
const result = []

for(let i = 1 ; i <= a ; i++){
    if(a % i === 0){
        arr1.push(i)
    }
}

for(let i = 1 ; i <= b ; i++){
    if(b % i === 0){
        arr2.push(i)
    }
}

for(let i = 0 ; i < arr1.length ; i++){
    for(let j = 0 ; j < arr2.length ; j++){
        result.push(arr1[i] + ' ' + arr2[j])
    }
}

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

'회고' 카테고리의 다른 글

[개발일지] - 86(주말)  (0) 2023.09.24
[개발일지] - 85(주말)  (0) 2023.09.23
[개발일지] - 83  (0) 2023.09.21
[개발일지] - 82  (0) 2023.09.20
[개발일지] - 81  (0) 2023.09.19

~08:40 일정 정리 완료 09:30

(주간 업무보고?로 인한 지연)

(인터페이스 에러, 싸토리우스 운영 배포, RFHIC 배치 등)

~10:30 RFHIC Account Batch 완료 10:36

~11:00 RFHIC 회의 준비 완료 11:00

~11:30 RFHIC 회의 완료 12:15

~12:30 점심시간 완료 13:13

~13:00 싸토리우스 Order 채번 배포 완료 14:26

(30분???? 사라짐 포트원이랑 이것저것 인터페이스 관련 대화로)

~14:00 사례 정리 완료 15:31

@김지은차장 요청 마이그레이션 DK 진행 견학 완료 17:01

@핫도그 먹고 에어프라이어 청소 완료 17:21

 

Error: Field must be grouped or aggregated

SELECT OrderId, COUNT(Id) Counts FROM OrderItem GROUP BY OrderId ORDER BY COUNT(Id) DESC LIMIT 100

Failed to save 'ERP_IF_EveryHour_BatchJob_sc.cls': The content of the file is newer. Please compare your version with the file contents or overwrite the content of the file with your changes.

 

sql convert, join left right

 

출근하자마자 사례(케이스)를 작성하려고 정리하는데

오늘은 팀장님이 미국에 다녀오셔서 시차 이슈로 일찍 출근하셨다.

 

팀장님이 안계셨던 저번주에 있었던 일들에 대해 보고드리고

유사한 이름으로 전체 인터페이스가 존재해서 낚여서 거기에 배치를 달았었는데

알고보니 다 갈아엎고 새로 만든 곳에 연결해야 해서 

다시 배치를 연결하면서 예전 기억을 떠올리며 복습할 수 있었다.

 

배치를 끝내고 곧바로 회의 준비를 했는데

아직까지는 세번째 프로젝트에 업무는 확실하게 배정받은건 아니라

조금 여유있게 내용만 훑어봤다.

 

회의는 금방 끝날 것 같았지만 전반적인 내용 설명을 해주셨고

확인해야 할 부분들에 대해서 이것저것 따져보다보니 회의가 예상보다 40여분 더 진행되었다.

 

이전에 사용자가 일부만 적용시킨 numbering을 순차로 적용시키는 코드를 작성했었는데

팀장님이 오셨기 때문에 운영서버에 바로 배포시켰고 딱히 문제는 아직 발견되지 않았다.

 

추가적으로 진행할 인터페이스에 대해서 이야기도 나왔는데

팀장님은 초반 보안 auth2에 대해서만 알려주시고 나머지는 알아서 진행할 것 같았다.

 

주간 진행한 사례를 전부 정리하고 등록하고 SQL 학습을 하려고 했는데

마이그레이션 요청을 팀장님이 import로 해결하는 모습은 보여주셨기 때문에 

1시간 30여분가량 뒤에서 배운 후 퇴근시간이 되어버렸다.

 

SQL에서는 convert나 join left, right inner 등 특이한게 많이 보였는데

SOQL이 아닌 SQL을 프로그래머스에서 겨우 3시간 가량 했기 때문에

아직 그 단계까지는 가지 못해서 이론적으로만 이해하고 사용은 아직 못할 것 같았다.

 

혼자 카운팅 관련 쿼리를 날려보다가 아래와 같은 에러와 다른 에러들을 발견했는데

이런 에러들은 카운팅 한 뒤 필드를 잘 집어넣으라는 것과

쿼리 사이즈가 너무 크다는 문제였기 때문에 limit을 걸어주니 정상 출력되는 것을 볼 수 있었다.

Error: Field must be grouped or aggregated

SELECT OrderId, COUNT(Id) Counts FROM OrderItem GROUP BY OrderId ORDER BY COUNT(Id) DESC LIMIT 100

 

또한 배치 작업을 할 때 발생한 오류로 아래와 같은 에러를 확인할 수 있었는데

이런 문제는 retrive를 해오는 과정에서 저장을 하지 않은 상태였다가 저장을 해서 뭔가 꼬였다는 것으로

retrive를 다시 받아온 다음 수정된 내용을 적용해서 deploy하면 해결되는 모습을 확인할 수 있었다.

Failed to save 'BatchClassName.cls': The content of the file is newer. Please compare your version with the file contents or overwrite the content of the file with your changes.

 

 

(1).백준 25815번 Cat’s Age는 사람에 비교했을 때 고양이의 나이를 구해야 하는 문제였다.

 

단 나이처럼 깔끔하게 계산하는 것이 아니라 개월수를 통해 몇살 몇개월인지까지 구해야 했는데

1살이 될 때까지는 15배의 속도로 

2살이 될 때까지는 9배의 속도로

그 이후부터는 4배의 속도로 나이를 먹는다고 가정했기 때문에

가중치를 개월수로 비교한 다음 최종적으로 Math.floor와 %를 통해 년, 개월을 계산했다.

const input = `20 11`.split(' ').map(Number)

let month = input[0] * 12 + input[1]
let human = 0

if(month <= 12){
    human += month * 15
}
else if(month <= 24){
    human += month * 9 + 72
}
else{
    human += month * 4 + 192
}

console.log(Math.floor(human/12), human%12)

'회고' 카테고리의 다른 글

[개발일지] - 82  (0) 2023.09.20
[개발일지] - 81  (0) 2023.09.19
[개발일지] - 79(주말)  (0) 2023.09.17
[개발일지] - 78(주말)  (0) 2023.09.16
[개발일지] - 77  (0) 2023.09.15

오자마자 일정 정리를 했는데

남은 업무가 거의 없기 때문에 테스트케이스 작성 및 주석처리를 하기로 했다.

 

작업에 들어가기 전 에러메일을 확인했는데

어제 퇴근 전에 보냈던 요청사항 수정사항을 보시고

수정되었는지 일부러 테스트를 해보셔서 Validaion 오류가 발생한 것 같다.

 

가독성이 괜찮은지 어제 작성한 요청사항 처리사항을 다시 읽어보고

테스트클래스 상단 주석처리에 들어갔다.

 

파일명, 테스트클래스, 작성자, 버전, Description 등을 작성하는데

대부분 작성은 되어있는게 기본이지만

테스트클래스를 작성하기 전에 만들었기 때문에 테스트클래스 등이 비어있었고

매칭되는 클래스를 찾아서 넣어줬다.

 

어제 하나 빼먹은 인터페이스 테스트클래스도 작성했는데

하다보니 점점 익숙해져서 테스트클래스 수정도 진행했다.

 

운영에 바로 반영하기 위해 75%가 필요한데

당일 처리하다보니 76%로 마감된 테스트케이스 또한 100%로 증가시켰고

테스트케이스 내부에 들어갈 데이터 생성에도 익숙해졌다.

 

연구실에서 ListBuilder 관련 테스트 문의가 들어왔기 때문에

해당 부분에 대해 시연을 진행했는데 첫번째 문의는 정상적으로 변경이 완료되었다.

 

다른 연구실분이 오셔서 테스트를 해달라고 하셔서 진행했는데

기존에 고객사에서 테스트할 수 있도록 권한부여까지 끝난 탭을 지워달라고 하셨기 때문에

슬프지만 이미 권한부여가 끝났다는 사족 없이 바로 지우고 새로 생성해봤는데

이전과 동일한 에러가 발생해서 아쉽지만 권한만 새로 작성해야 했다.

 

그래도 의미있는게 이전에 발생한 에러는 중복 명칭 때문이었고

그 문제를 해결하시고 나서도 처음에 보였던 에러코드가 발견된 것이기 때문에

이번에는 해당 앱 이름과 문제를 이슈로 작성해달라고 하셔서 연구실에 이슈를 남겼다.

 

도중에 고객 요청사항 중 개선사항이 생각나서 연구실분에게 질문드리니

그게 왜 안되요? 하시면서 보시다가 원래는 지원하는 기능인데

패키지를 업그레이드하면서 문제가 발생한 것 같아서 이것도 이슈로 올려달라고 하셨다.

 

클래스 상단의 Title 느낌의 주석이 아닌

각 메서드별로 넣어주는 주석을 진행했는데

인터페이스팀에는 특성상 메서드가 아닌 Wrapper 클래스들과

get, post등의 이름만 봐도 기능을 알 수 있는 몇개의 메서드로 이루어져있기 때문에

메서드별 주석이 달린 것을 볼 수 없었기 때문에 여태 잊고있었다.

 

클래스에서 주석을 넣는 것에 대한 의견을 점심시간에 회사분들에게 물어보니

기분이 좋으면 넣고 나쁘면 넣지 않는데 대부분 넣는게 맞다고 하셨고

다른분은 스니펫으로 편하게 내용만 작성할 수 있다고 알려주셔서

스니펫 사용법을 배웠다.

 

이름부터도 Snippet인 vscode 익스텐션을 다운받고

vscode 하단의 Manage에 들어가 User Snippets를 클릭해 사용할 수 있었다.

 

처음 어떤 타입으로 할지 설정한 다음

내부에 아래처럼 JSON 형태로 처리하면 된다.

"Debug": {
	"prefix": "ddd",
	"body": [
	"System.debug('■■■■ ========== ${TM_FILENAME_BASE} :: @@@@ $1 ==> \\n' + $2);"
	],
	"description": "debug.log"
},

 

prefix를 통해서 호출할 수 있는데

좌판이 한글로 되어있는 경우 가끔 ddd 대신 ㅇㅇㅇ가 나갈 수 있기 때문에

“Debug2”, “Prefix”:”ㅇㅇㅇ” 형태로 두개를 만들어주면

한/영 신경쓰지 않고 편하게 불러올 수 있다.

 

SQL학습을 오늘도 진행하려고 했으나

개인정보보호교육 때문에 1시간 가량 교육을 받았고

그 이후 여신관련 메일을 작성한 다음 SQL을 다시 시작했다.

 

1.쿼리 내부 ROUND(NumberTypeField, 0) 형태로 반올림을 할 수 있다. 웃긴건 CEIL이나 FLOOR는 되지 않는다.

 

2.b의 특정 정보를 가져와서 비교하고 싶은 경우 WHERE 부분에서 b를 쿼리할 때 b 내부 WHERE에서 비교필드 = a.비교필드 형태로 a의 필드값을 가져올 수있다.

SELECT flavor FROM first_half WHERE total_order > 3000 AND (SELECT ingredient_type FROM icecream_info WHERE flavor = first_half.flavor) = 'fruit_based'

 

3.쿼리 내부 IF를 사용해 조건에 따라 출력 값을 변경할 수 있다. IF(end_date - start_date >= 30 , "장기 대여", "단기 대여") 날짜의 차이는 지 멋대로 진행되는 감이 있는데 자세히 결과를 비교해보니 2022-09-01이라면 20220901라는 숫자로 인식해서 10월1일이 되면 100이 증가하는 것이었다.

SELECT history_id, car_id, DATE_FORMAT(start_date, '%Y-%m-%d') AS start_date, DATE_FORMAT(end_date, '%Y-%m-%d') AS end_date, IF(end_date - start_date >= 29 , "장기 대여", "단기 대여") AS rent_type, (end_date - start_date) AS date, DATEDIFF(END_DATE, START_DATE) AS date2 FROM car_rental_company_rental_history WHERE start_date LIKE '2022-09-%' ORDER BY history_id DESC

 

 

(1) 백준 21022번 Three Points for a Win는 승리시 3점, 무승부시 1점을 얻을 수 있을 때

최종적으로 몇점을 획득하는지를 계산해야 하는 문제였다.

 

간단하게 input을 Number type으로 변경하고

해당 길이에 맞게 for문을 순회하며 비교해 점수를 result에 저장하는 방법으로 해결했다.

const input = `4
3 0 2 4
1 1 2 3`.split('\n').map(el => el.split(' ').map(Number))

let result = 0
for(let i = 0 ; i < input[1].length ; i++){
    if(input[1][i] === input[2][i]){
        result += 1
    }
    else if(input[1][i] > input[2][i]){
        result += 3
    }
}

console.log(result)

'회고' 카테고리의 다른 글

[개발일지] - 79(주말)  (0) 2023.09.17
[개발일지] - 78(주말)  (0) 2023.09.16
[개발일지] - 76  (0) 2023.09.14
[개발일지] - 75  (0) 2023.09.13
[개발일지] - 74  (0) 2023.09.12

오늘은 출근하다가 버스 시간표가 보여서 찍어봤다.

 

여기가 어딘지는 모르겠지만 공통적으로 가장 가까운 시간대는 7시 40분이기 때문에

대략 7시 50분 전에 도착한다고 치고(사실 볼 것도 없다)

가장 가까운 시간대는 거의 30분 전이기 때문에

7시 38분에 출근할 생각이 아니라면 이전 버스는 무리인 것 같다.

 

7시 38분에 출근하고 5시 퇴근이 가능하고 

7시 20분 버스에는 승객이 얼마 없다면 고민해볼만한 것 같기는 하지만

7시 10분쯤에 버스 노선을 봤을 때는 022B가 카카오맵에 보이지 않는데

왜 그런지는 잘 모르겠다.

 

오늘도 적당히 일찍 출근했고

이제 적응된 왼쪽 모니터 기본세팅

아몬드브리즈를 먹었는데 살짝 두유 같은 맛이 났던 것 같다.

 

오늘은 옆자리 디자이너분이 만방위를 가셨기 때문에 조금 더 심심했고

조금 더 쉬울 것이라고 생각했던 Visual force 부분은 쉽지 않았다.

 

구조적으로는 프론트엔드였기 때문에 어려운 부분이 거의 전혀 없다고 봐도 됐지만

거기에 들어갈 모든 자료를 "내가" 불러와야했다.

 

또한 거기에 공급할 컨트롤러를 만들어야 하는데 그 컨트롤러도 "내가"만들어서

나에게 주고 그걸 받아서 다시 데이터를 넣어야 하는 구조였다.

 

그렇다.. 백/프론트의 문제가 아닌 풀스택으로 진행되는 개발이었다.

 

구조적으로는 다 알겠지만 방법을 알려주지 않고 자료를 불러다가 쓰라고 하는데

공식문서에도 제대로 나와있지 않고 답답하게 학습을 진행할 수 밖에 없었다.

 

그래도 난이도가 어려운 것은 아니었고

이 부분에 뭐가 들어가야되는지는 분명히 아는데

뭘 적어야 그게 불러와지는지 키워드(메서드?)를 모르는 상태라서 

자주 들어가는 부분들만 정리하더라도 크게 막힘없이 진행할 수 있을 것 같다.

(햄버거 주문하려고 외국 가게에 들러서 속재료를 다 알지만 고를 수 없는 그런 답답함)

 

허리가 아프다는 이야기를 했더니 코어 문제라는 이야기가 나왔는데

요새 추위를 타는 것도 근육이 부족하면 그럴 수 있다는 의견이었다.

 

코어운동도 하루 루틴에 넣고 싶지만

자세가 중요하다고해서 쉽게 선택하기는 어려운 것 같고

평일에 따로 시간내서 알아보기에도 시간이 너무 없다.

 

내일은 한 주간 한 일에 대해서 간단하게 발표하고

그 이후 할 일에 대한 계획을 구두로만 발표하라고 하시는데

개인별 면담을 원래는 진행했다고 했는데

이번에는 신입이 4명이나 되서 한번에 몰아서 보는 느낌이 있는 것 같다.

 

과제를 하기 위한 필수적인 학습 진행도 SQL 부분 때문에 막혔는데

원활한 진행을 위해서는 SQL을 학습하는걸 추천받고 있어서 당황스러웠다.

 

주말에는 아무래도 SQL학습을 자체적으로 진행해야 할 것 같다.

'일기' 카테고리의 다른 글

짧은 주말  (2) 2023.04.15
에어프라이어 vs 오븐  (2) 2023.04.14
행군 끝  (2) 2023.04.12
고난의 행군  (2) 2023.04.11
apex와 soql  (4) 2023.04.10

+ Recent posts