도저히 이해할 수 없지만 오늘은 버스에 사람이 가득했다.

 

사람이 얼마나 많았냐면 버스가 평소보다 3~4분 늦게 올 정도로 많았는데

탑승에 시간이 지체된게 아닐까 싶었다.

 

도로도 평소보다 훨씬 막힌 느낌이었는데

광복절 전날에 다들 휴가를 몰아쓰기로 약속해서

수요일 휴가자가 한명도 없으면 발생하는 일처럼 느껴졌다.

08:35

도착은 35분쯤 했는데 사진 찍는걸 깜빡해서 뒤늦게라도 찍었다.

 

요즘 하나둘씩 잊어버리는게 생기고 있는데

예전부터 꾸준히 부트캠프 디스코드방에 출석을 했었는데

까먹은 뒤로 안한게 거의 2~3주는 지난 것 같고

복지카드 사용내역 기록 또한 까먹고 안한지 2주일이 다되간다.

 

물론 가계부를 쓰고 있기 때문에 얼마를 사용했는지는 알 수 있지만

잔여금액을 확인하기에는 상당히 불편할 것이다.

 

오전에 밖이 하도 시끄러워서

누가 뭘 하시는 것 같아서 도와주러 가봤는데

외벽청소를 하느라 소음이 발생한 것이었다.

외벽청소중

사람은 찍기 그래서 사람이 내려가고 줄을 찍으려고 했는데

한명이 아니고 사방에서 내려오고 있기 때문에 윗사람의 발까지 찍혀버렸다.

 

점심에는 배치, 스케쥴러를 작성했는데

긴 시간이 걸린만큼 이해도가 높아져서 팀장님의 코드 작성 의도를 거의 다 파악할 수 있었다.

 

그전에는 왜 이렇게 복잡하게 작성하셨는지 헷갈렸는데

복잡하게 된 이유 하나하나가 다 존재했고

그 복잡함이 증가한 것 이상으로 안정성과 기능이 상승했다는 것을 알 수 있었다.

 

실제로 해당 부분에 대해 거의 이해했다고 생각했지만

조금 불필요해보이는 코드들이 보였는데

실제로 완성하고 에러가 발생해서 확인해보니

인터페이스를 할 때는 List가 아닌 Map을 사용하는 이유가

히스토리 형태 또는 타입마다 구분되는 데이터베이스가 섞여서 넘어올 경우가 있기 때문에

Map으로 저장해야 에러가 발생하지 않는다는 것을 이해할 수 있었다.

 

누리정 정식(11,000원)

점심은 누리정이 궁금하다고 하시는 분들이 있으셔서

다 같이 또 누리정에 가게 되었는데

확실히 가격은 조금 더 비싸지만 기본 이상의 맛을 가지고 있고

반찬들도 조금 더 더양하기 때문에 햄버거 같은 것을 먹는 것 보다는 훨씬 더 건강한 것 같다.

 

오후에는 스케쥴러 테스트를 진행하다가

구석에 사람들이 모여서 가보니 화분 가지치기와 물주기를 하고 계셨고

마지막으로는 금전수의 가지치기한 부분 중 하나를 키워보겠다는 분이 계셔서

구석에서 수경재배(?)를 시작헀다.

금전수

 

집에 가는 길에 또 새로운게 보여서 기대했는데

집에서 10초 거리지만 안타깝게도 맥주집이다.

대형 HOF 입점..

처음에는 프렌차이즈나 햄버거집 같은 것이라도 아무거나 왔으면 좋겠다고 생각했지만

잘 생각해보면 어차피 점심특선가격이 아니면 먹을 생각도 없고

점심시간에는 회사에 대부분 있기 때문에 큰 의미가 없었다.

 

게다가 롯데리아 같은 몇몇 브랜드를 제외하면

점심특선을 주말에는 하지 않는 경우도 존재하기 때문에

이제 아무거나 들어오든 신경쓰지 않기로 했다.

 

이제 딱 하나 기대를 해본다면

중형 마트정도만 하나 들어온다면

신선한 야채를 정가에 살 수 있을 것 같다.

 

아침을 먹지 않기 때문에 

집에서는 저녁밖에 먹지 못하고

주말에도 2끼 밖에 먹지 않기 때문에 

1주일 기준 9끼밖에 먹지 않는다.

 

몰아서 해치우지 않는 이상

일반 가정에서 구매하는 단위로 야채를 구매할 수 없고

그렇다고 소규모로 사자니 가격이 두배가까이 올라버린다.

 

어쨌건 오늘도 삼겹살을 먹었지만 

청양고추나 파 없이 먹게 되었는데

삼겹살도 1인분 밖에 남지 않아서 야채를 사기에도 애매하다.

 

이야기가 이상한 쪽으로 흘렀는데

내일 모레에는 회의가 2개나 잡혀있기 때문에

해당 회의 준비를 내일 해봐야겠다.

 

 

오늘도 30분 이상 걸었다.

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

연속 회의  (1) 2023.08.18
한다솥  (0) 2023.08.17
광복절  (1) 2023.08.15
창고정리  (0) 2023.08.14
일반쓰레기와 날파리  (0) 2023.08.13

여태까지는 배열을 넘겨줄 경우 [a,b,c,d]형태로 담아서 넘겨준다고 생각했기 때문에

용량을 많이 차지한다고 생각해서 굳이 문자열 형태로 바꾸거나 map 형태로 담아서 키를 전송했었는데

알고보니 배열을 넘길 떄는 담긴 전체 내용이 넘어가는 것이 아니라 주소값만 넘어가기 때문에

아래와 같은 작업을 진행했을 때 arr의 처리 시간은 160ms

str의 처리시간은 1500ms로 오히려 배열로 처리하는 것이 더 안정적인 것을 볼 수 있었다.

 

사실 더 안정적인지는 정확하게 모르겠지만

str의 길이가 길어질수록 시간이 지연되는 문제는 확인할 수 있지만

arr의 경우 천만개의 데이터가 들어있어도 속도 지연이 현저하게 적다는 것을 알 수 있기 때문에

배열의 값이 아닌 주소를 넘긴다는 것을 확인하는 시간이 되었다.

let startTime = performance.now();

const arr = []
const arrChanger = (arr,num) => {
    arr.push(num)
}

for(let i = 0 ; i < 10000000 ; i++){
    arrChanger(arr,i)
}
console.log(arr.length)

// let str = ''
// const strChanger = (st, num) => {
//     str += num
// }
// for(let i = 0 ; i < 10000000 ; i++){
//     strChanger(str,i)
// }
let endTime = performance.now();
console.log(`걸린 작업 시간은 총 ${endTime - startTime} 밀리초입니다.`);

배치를 작성하던 중 외부 아이디를 확정지어야 했는데

이전에 두개를 외부아이디로 설정했었지만

인스펙터로 확인해보니 첫번째 키는 전부 존재하지만

두번째 키는 3개정도 빈 곳을 볼 수 있었다.

 

결론적으로 저 테이블에서는 첫번째 키를 키로 사용한다는 것을 확신했고

데이터정의서를 보니 그제서야 첫번째 키에 강조 표시가 있다는 것을 볼 수 있었는데

이게 키를 표시해주는 것임을 뒤늦게 인지할 수 있었다.

 

기존에 설정했던 외부아이디 2개 중 하나인 두번째 키를 원래대로 되돌리고

다시 배치를 작성했다.

(보안 문제로 이름을 첫번째 키, 두번째 키로 변경해 어색함이 있는 상태)

 

외부 키를 사용해 upsert를 사용할 경우

upsert upsertDataList externalId형태로 기본 upsert 뒤에 외부 아이디를 추가하면 된다.

 

배치를 작성한 후 스케쥴러를 통해 작업을 진행하려고 했으나

기존에 작성된 스케쥴러가 있었기 때문에 해당 스케쥴러에 추가하려고 했다.

 

하지만 스케쥴러 내부의 작동 방식은 getTriggerId 같은 뭔가로 jobId를 특정하면서 진행하는데

excute 내부나 excute에서 실행한 함수 내부나 동일한 아이디를 가지고 있어서 

두개의 작업을 넣으면 안될 것 같았다.

 

알고보니 Batch를 연달아 배치(?)하는게 아니고

배치가 끝난 후 final 부분에서 실행시키는 것이었다.

 

그리고 배치가 기존 실행과 schedule로 실행되는 것을 구분하는 방법이 있었는데

해당 방식을 내 코드에 적용하고 보니 뭔가 이상했고

final에서 다음 작업을 작동시킬지를 확인하는 것이었기 때문에

이전 스케쥴의 마지막 Batch 작업이었던 Batch 내부에서 설정하고

내 코드는 그냥 호출만 당하는 것이었다.

 

오늘도 좋은 내용을 많이 배울 수 있었고

남는 시간에는 메일을 전부 읽었는데

주어진 일만 하는 것이 아니라 감독하는 입장에서 확인해보니 

사용자의 입장에서 필요한 수정이 생각보다 많았고

그 부분을 정리한 다음 금요일에 있을 회의 전에 개선을 시도하거나

개선 방법에 대해 생각해보기로 했다.

 

 

(1).백준 10807번 개수 세기는 새싹 문제였는데

실수로 클릭한 새싹 문제들을 풀지 않아서 아직 새싹단계인걸로 착각하고 문제를 풀어버렸다.

 

자세히 읽어보니 새싹 문제를 다 풀더라도

이쪽은 새싹 태그의 문제가 모여있어서 새싹등급이 아닌 새싹 태그일 뿐이었지만

혹시 새싹 태그를 다 풀면 다음 단계가 있어서 더 체계적으로 문제를 풀 수 있지 않나 기대를 해본다.

 

갯수 새기는 해당 글자와 일치하는 것의 갯수를 찾는 문제인데

지금 생각해보면 filter와 length를 사용해도 괜찮았을 것 같다.

const input = `11
1 4 1 2 4 2 4 2 3 4 4
2`.split('\n')
const arr = input[1].split(' ')
let count = 0
for(let i = 0 ; i < arr.length ; i++){
    if(arr[i] === input[2]) count++
}

console.log(count)

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

[개발일지] - 49  (0) 2023.08.18
[개발일지] - 48  (0) 2023.08.17
[개발일지] - 46(광복절)  (0) 2023.08.15
[개발일지] - 45  (0) 2023.08.14
[개발일지] - 44(주말)  (0) 2023.08.13

메일 확인을 한 다음 6월부터 진행했던 일들을 정리했는데

어떤 작업을 어느정도 진행했는지 공수를 산정하는 일이었다.

 

매일 일정 계획과 해당 작업 완료시간을 전부 기록했기 때문에 

아래와 같이 어느정도 시간 산정은 가능했다.

각 작업 진행 시간

작업내용은 혹시 모를 보안 때문에 가렸지만

시간만 봐도 어마어마하게 들어갔음을 알 수 있다.

 

작업시간보다 추가 에러 및 개선작업에 시간이 더 오래 걸렸음에도 불구하고

대부분 시작 전부터 잡아둔 공수일자에 8시간을 곱하고 다시 60분을 곱하니

얼추 비슷한 값이 나오는걸 보고 상당히 신기했다.

 

사례 작성은 2시면 끝날거라고 생각했는데 실제 완료시간은 3시 40분이 넘어서 끝나버렸는데

가장 큰 이유는 점심식사 후 1시간 30분 가량 창고청소를 해서 시간이 비어버렸다.

 

점심식사 도중 한분이 창고 너무 정리가 안되어있어서 언제 정리 한번 해야겠다고 하시고

점심을 먹고 잠깐 정리를 하시길래 도와드리다보니 거의 2시였다.

 

거기에 청소를 끝내고 보니 답신 메일도 와있었는데

해당 부분에 대한 회신을 하다 보니 추가로 시간이 소모되었다.

 

이제 하루 평균 메일 1회는 온다고 봐야 하고

추가로 무슨 일을 해야 할지 모르기 때문에

하루 일과 계획에는 적어도 1시간은 여유를 두고 분산해서 일정을 짜야겠다.

 

사례 작성 후 인터페이스 관련 질문이 있어서 확인하다보니

null 값을 넘겨줄 수 없다고 하시는데 나는 잘 되었던 것이 이해가 되지 않아

코드를 확인해보니 { get; set; }를 사용하면 자연스럽게 처리가 되고

해당 getter, setter를 사용하지 않으면 null값인 경우 에러가 발생한다고 한다.

 

배치를 작성하다가 퇴근시간이 되었기 때문에 수요일에 마무리하기로 했다.

 

 

(1).백준 6190번 Another Cow Number Game는 홀수에는 *3 +1을 진행하고 짝수면 /2를 한 다음

1이 될 때까지 몇번의 연산이 필요한지를 묻는 문제였다.

 

간단하게 while에 조건을 1이 될 때까지 돌게 만들고

내부에서 원하는대로 홀수일 경우 *3  +1 처리를 하고 짝수는 /2처리를 해 count를 출력했다.

let num = 112
let count = 0
while (num > 1) {
    count++
    if(num%2){
        num = num * 3 + 1
    }
    else{
        num/=2
    }
}

console.log(count)

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

[개발일지] - 47  (0) 2023.08.16
[개발일지] - 46(광복절)  (0) 2023.08.15
[개발일지] - 44(주말)  (0) 2023.08.13
[개발일지] - 43(주말)  (0) 2023.08.12
[개발일지] - 42  (0) 2023.08.11

오늘은 라이센스 답변을 위해

커스텀 개체를 사용할 것 같은 분들에게서 답변이 왔는데

해당 개체를 정리하고 실제 운영 서버에서 관련 프로필에서 사용되는 커스텀 개체의 수를 비교한 결과 10개가 넘었던 것을 확인할 수 있었다.

 

하지만 이번에 추가되는 부분만 담당하는 유저들은 10개 미만의 개체를 사용하는 것으로 확인되었기 때문에

해당 필드들의 레이블, api명을 작성해 이런 개체들이 사용됨을 정리했다.

 

중간 과정에서 추가해야 하는 부분들도 내가 감당할 수는 없는 부분이지만 

내용을 확인하고 보고해서 메일들이 처리될 수 있도록 조금이나마 도움이 되려고 노력했고

배치 스케쥴링 프로세스를 위한 작업을 하던 중 연관 회사에서 페이지네이션이 되지 않는 api를 보내줘서

해당 부분의 수정본을 받았지만 알고보니 api의 페이지 처리가 어긋나있었다.

 

그 부분은 총 데이터와 현재 페이지를 가지고 처리할 수 있기 때문에 상관은 없었기 때문에 넘어갔고

배치를 돌리는데 굳이 페이지를 쪼개서 받을 이유가 있는지에 대한 의문이 생겼는데

팀장님이 실제로 수백만개의 데이터가 넘어올 경우 받을 수가 없는 문제가 발생하지만

필드 숫자가 적고 하루 처리 숫자가 소수인 경우에는 전체 페이지를 받는 구조로 해도

오히려 쪼개서 하는 것 보다 안정적일 수 있다고 해주셔서 생각한대로 1회 request에 전체 데이터를 받아오기로 했다.

 

단순 배치 작업이 아닌 마이그레이션, 스케쥴, 배치, 조회 등 여러가지를 한번에 할 수 있으면서도

나중에 유지보수를 위해 확정성까지 남겨둔 코드를 보고

하나의 기능만 간신히 해서 나중에 뜯어고쳐야 하는 내 코드를 보다 보니

자꾸 왜 저렇게 돌아가는지 공부하게 된다.

 

하지만 두세개의 기능이 아닌 동시에 연관된 개체들까지도 업데이트하는 복잡한 부분이었기 때문에

현재 위치의 코드는 이해했지만 다른 곳 까지 넘어가면서 학습하기에는 현재 일처리를 해야 해서 넘어가기로 했다.

 

오늘은 메일 답변도 하고 배치 학습도 했지만

실제 코드작성은 많이 하지 못해서 아쉬웠다.

 

 

(1).백준 23802번 골뱅이 찍기 - 뒤집힌 ㄱ은 @를 ㄱ 모양으로 찍어야 하는 문제였다.

 

글자의 사이즈가 커진 것 처럼 두께가 가로, 세로로 두꺼워져야 했기 때문에

줄 숫자를 표현할 때는 각 줄마다 input의 길이만큼 추가했으며

하나의 @였던 길이의 확장을 나타내기 위해서 repeat을 사용했다.

const input = 1
const result = []
for(let i = 0 ; i < input ; i++){
    result.push('@@@@@'.repeat(input))
}

for(let i = 0 ; i < input * 4 ; i++){
    result.push('@'.repeat(input))
}

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

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

[개발일지] - 44(주말)  (0) 2023.08.13
[개발일지] - 43(주말)  (0) 2023.08.12
[개발일지] - 41  (0) 2023.08.10
[개발일지] - 40  (0) 2023.08.09
[개발일지] - 39  (0) 2023.08.08

금요일과 무슨 관계가 있는지는 모르겠는데

오늘은 버스에 사람이 너무 너무 너무 많아서 탑승조차 하지 못했다.

 

물론 집에서 출발하는 버스가 아니라 환승버스긴 했는데

왜 금요일에만 사람이 이렇게 더 많은지는 모르겠다.

 

2층 버스가 가까이에 있는데

아직 한번도 탑승해본적이 없어서 신기해서 찍어봤다.

2층 버스

결국 버스를 놓치고 다음 버스를 타니 평소보다는 조금 늦게 출근할 수 밖에 없었다.

08:43

오전에는 고도화 회의를 진행했는데

생각보다 많은 수정사항과 추가 기능들이 있었는데

그 중에서는 아직 힘들어보이는 것도 있었다.

 

해당 부분은 기능적으로 문제가 있어보여서 질문헀는데

세일즈포스 롤업기능으로 해결할 수 있는 부분이라 생각보다는 간단할 것 같았다.

 

점심을 먹으러 지하로 내려갔는데

이전에는 식당쪽만 찍었는데 편의시설도 많이 있어서 추가로 사진을 찍었다.

지하상가 1층 편의시설, 음료/스낵

점심은 오므라이스를 먹으러 갔는데

칠리소스라고 하는데 살짝 케챱맛이 강해서 

새콤한 맛 때문에 조금은 아쉬웠다.

에그퐁당 칠리오믈렛(8,000원)

 

 

오후에는 뭘 할지 잠시 고민했는데

오전에 진행한 회의에서 일을 많이 받긴 했지만

다음주 금요일 회의까지 끝내라는 이야기는 아니었기 때문에

진행하던 프로젝트의 배치부분을 마무리했고

해당 부분 테스트 후 다시 전체 데이터를 삭제하고

로그를 남기는 부분을 추가했다.

 

도중에 api가 잘못된 부분이 발견되서 해당 부분을 수정하고

수정한 취소기능에 필요한 필드를 넣지 않아서 문제가 된 부분이 있었는데

해당 부분의 입력값도 변경하는 등의 소소한 수정들도 진행했고

무난하게 개발자스러운 일들을 많이 진행하고 실제로 작동에 영향을 주는 업무를 해서 만족도가 높았다.

 

오늘은 특히 이것저것 주의할 점들을 많이 배웠는데

보안 문제가 있기 때문에 개발용으로 사용하는 서버가 아닌 토큰을 사용하는 주소값을 전달해야 하고

기능을 완성하면 그걸로 끝내는게 아니라 사용할 시나리오를 가지고 여러 방법으로 테스트를 진행해야하며

api를 만든 경우 필드가 수십개가 넘는 경우 일부 값들이 잘못 들어가거나 누락될 수 있기 때문에

세부 값과 실제 요청/정의서값과 동일한 유형이 맞는지 확인해야 한다는 점들을 느낄 수 있었다.

 

다음주부터는 오늘 회의에서 받은 일들을 바쁘게 처리할 것 같다.

 

 

오늘도 30분 이상 걸었다.

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

벌써 힘든 클래스  (2) 2023.07.30
대청소  (0) 2023.07.29
사진관 확인  (0) 2023.07.27
교통안전교육 접수  (0) 2023.07.26
BHC 치킨  (0) 2023.07.25

오늘은 방화벽 관련 문제에 대한 실수를 했는데

방화벽은 고객사에서 담당해야 하는 부분이고

협업사가 부분 인터페이스를 담당하는데

인터페이스 에러가 난 부분을 고객사에게 전달했다.

 

인터페이스 에러가 났다는걸 볼 수 있다는 것 자체가 방화벽이 잘 되었다는 것으로

조금 더 생각해보고 메일을 보냈다면 실수하지 않을 수 있던 부분이라 아쉽다.

 

해당 부분은 정의서 및 메일을 전부 읽어보고

고객사에게 보내긴 했지만 참조에 협업사도 포함되어 있었기 때문에 

의미는 전달되었다고 보고 넘어가기로 했다.

 

배치를 학습하다가 일단 배치로 자료를 뽑아봤다.

 

배치도 이제 좀 적응이 돼서 자신감이 생겼는데

마무리하며 마이그레이션을 하기 전 다른 프로젝트에서 추가 기능 요청을 해서

해당 부분 전화도 내가 받고(결정권한이 없어서 금방 토스했다)

해당 부분 수정도 내가 직접 진행하고

해당 부분 정의서도 내가 작성하고

종료 후 메일까지 보내고 나니 전문 백엔드 개발자 같은 느낌이 막 들었다.

 

배치나 마이그레이션에 대한 고민도 많이 했지만

그건 어차피 읽는 사람도 없고 중간중간 보안부분 수정도 귀찮기 때문에 노션에만 남겨두기로 했다.

 

 

(1).백준 6889번 Smile with Similes는 글자를 매칭시킨 다음

as를 붙여서 출력해야 하는 문제로

앞부분을 for문의 i로

뒷부분을 for문의 j로 고정하고

i만큼 반복해 ixj형태로 돌릴 수 있었다.

const input = `3
2
Easy
Smart
Soft
pie
rock`.split('\n')

const first = Number(input[0])

for(let i = 2 ; i < 2 + first ; i++){
    for(let j = 2 + first ; j < input.length ; j++){
        console.log(`${input[i]} as ${input[j]}`)
    }
}

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

[개발일지] - 29(주말)  (0) 2023.07.29
[개발일지] - 28  (0) 2023.07.28
[개발일지] - 26  (0) 2023.07.26
[개발일지] - 25  (0) 2023.07.25
[개발일지] - 24  (0) 2023.07.24

보안적인 문제로 인해 그냥 일지 자체를 중단했었는데

지나간 코드를 블로그에 검색할 수 없어서 예전에 해결한 문제와 비슷한 경우 다시 시간이 걸리는 단점이 생겨버렸고

이로 인해 보안적으로 문제가 되는 부분들은 지워버리고 세일즈포스적인 부분만 남겨서 참고하기로 했다.

(변수명, 변수값 정도만 지운다는 이야기)

 

하지만 프로젝트를 들어가면서 조금 더 세밀하게 일정과 기록이 관리될 필요성을 느끼는데

보안적인 문제가 있어서 옵시디언을 사용해야 할 수도 있을 것 같고

만약 옵시디언으로 정리하게 된다면 일기는 몰라도 회고의 필요성이 점점 줄어든다는 생각이 든다.

 

1.배치 200 -> 1로 줄여서 여러개 테스트해보기

2.배치 넘길 때 Database.Query 말고 다른 방식 찾아보기(Iterable<String>)

3.스케쥴러를 익명함수가 아닌 클래스로 추가해서 배치 작동시키기

 

1.배치 생성 완료 

public class LeadProcessor implements Database.Batchable<sObject>, Database.Stateful {
    public Integer recordsProcessed = 0;
    public Database.QueryLocator start(Database.BatchableContext bc) {
        return Database.getQueryLocator(
            'SELECT ID, Company FROM Lead'
        );
    }
    public void execute(Database.BatchableContext bc, List<Lead> scope) {
    // process each batch of records
    List < Lead > leads = new List < Lead > ();
    for (Lead lead : scope) {
        lead.Company = lead.Company + '1';
        leads.add(lead);
        // increment the instance member counter
        recordsProcessed = recordsProcessed + 1;
    }
update leads;
}
public void finish(Database.BatchableContext bc){
    System.debug(recordsProcessed + ' records processed. Shazam!');
AsyncApexJob job = [SELECT Id, Status, NumberOfErrors,
                           JobItemsProcessed,
                           TotalJobItems, CreatedBy.Email
                      FROM AsyncApexJob
                     WHERE Id = : bc.getJobId()];
    // call some utility to send email
    EmailUtils.sendMessage(job, recordsProcessed);
}
}

 

2.배치 생성 후 원하는 값 start -> execute 전달은 Database.Query가 되지 않음 Iterable<String>으로 해결

 

3.배치 생성 후 api 가져오기 Too many callouts 문제 Database.AllowsCallouts으로 해결

 

4.배치 200 -> 1로 줄여서 실행해보기 ApiBatchProcessor batchClass = new ApiBatchProcessor(); Database.executeBatch(batchClass,1); 형태로 , num 형태일 경우 해당 수치만큼 쪼개진다.

 

5.배치 endpoint 미등록 setting -> Security -> Remote Site Settings -> New Remote Site 등록 후 진행 성공

배치

public class ApiBatchProcessor implements Database.Batchable<String>, Database.AllowsCallouts {
		public Iterable<String> start(Database.BatchableContext bc) {
		// 여기서는 외부 API를 호출하여 데이터를 가져옵니다.
		String requestBody = //보안상 입력 형태 삭제
		HttpRequest request = new HttpRequest();
    request.setEndpoint('<https://url>' //보안상 입력 형태 삭제);
    request.setMethod('POST');
    request.setHeader('Content-Type', 'application/json');
    request.setBody(requestBody);

    Http http = new Http();
    HttpResponse response = http.send(request);
	List<String> cardNames;
    if (response.getStatusCode() == 200) {
        // API에서 가져온 데이터를 가공하여 List<Object> 형태로 보관합니다.
        Map<String, Object> jsonResponse = (Map<String, Object>) JSON.deserializeUntyped(response.getBody());
        List<Object> apiData = (List<Object>) jsonResponse.get('result');
        XXXXs = new List<String>();

        // API에서 가져온 데이터를 가공하여 XXXX 값을 추출합니다.
        for (Object data : apiData) {
            Map<String, Object> dataMap = (Map<String, Object>) data;
            String xxxx = (String) dataMap.get('XXXX');
            XXXXs.add(xxxx);
        }
        // 가공된 데이터를 반환합니다.
        return XXXXs;
    } else {
        return null; // API 호출에 실패한 경우, 처리할 데이터가 없으므로 null을 반환합니다.
    }
}

public void execute(Database.BatchableContext bc, List<String> scope) {
    // execute 메서드에서는 가공된 데이터를 사용하여 처리 작업을 수행합니다.
    List<Lead> leads = new List<Lead>();
	System.debug(scope);
    for (String xxxx : scope) {
		System.debug(xxxx);
        leads.add(new Lead(LastName = 'test', Company = xxxx));
    }
	System.debug(leads);
    insert leads;
}

public void finish(Database.BatchableContext bc) {
    // 배치 작업이 완료된 후에 추가적인 마무리 작업을 수행합니다.
}

}

6.스케쥴러로 배치를 작동하지 않고 implements Schedulable를 배치에 추가해 진행 => 실패 스케쥴러 생성 후 스케쥴러 내부 배치 실행 방식으로 변경 후 성공 

public class ApiBatchScheduler implements Schedulable {
    public void execute(SchedulableContext sc) {
    ApiBatchProcessor batchClass = new ApiBatchProcessor();
        Database.executeBatch(batchClass, 1);
    }
}
    String jobName = '배치 실행 스케줄러';
    String cronExpression = '0 0 * * * ?';
    ApiBatchScheduler batchScheduler = new ApiBatchScheduler();
System.schedule(jobName, cronExpression, batchScheduler);

 

7.클래스 추가 후 클래스 내부에서 작동시키기

public class ApiBatchScheduler implements Schedulable {
	public void execute(SchedulableContext sc) {
	ApiBatchProcessor batchClass = new ApiBatchProcessor();
	Database.executeBatch(batchClass,1);
	}
	public static void registerScheduler() {
	    String jobName = '배치 실행 스케줄러';
	    String cronExpression = '0 30 * * * ?';
	    ApiBatchScheduler batchScheduler = new ApiBatchScheduler();
	    System.schedule(jobName, cronExpression, batchScheduler);
	}
}

익명함수에서 ApiBatchScheduler.registerScheduler();로 작동

로그쌓기 진행하기(하단 미공개)

 

내일 모레가 당장 시험이라 노션에서 복사해서 옮기는게 조금엉망진창으로 정리된 느낌이지만

이것도 많이 무리한 것 같은데 아마 내일 회고록은 문제만 올라오고 수정되거나

그냥 기존처럼 수정없이 문제만 있을 수 있을 것 같다.

 

 

(1).백준 17944번 퐁당퐁당 1은 사람들이 모였을 때 주어진 사람 숫자의 2배만큼의 숫자까지 오르락 내리락하는 게임이었다.

 

처음 생각으로는 간단하게 사람 수를 기준으로 게임을 %처리해 쉽게 해결할 수 있을 것 같았는데

2n이라는 것을 가볍게 읽고 넘어가버려서 n 기준으로 작성하고 코드가 꼬여서 수정하는데 조금 헷갈렸다.

 

결과적으로는 1~2n까지의 증가 후 다시 1까지 감소해야 하는데

1은 새로운 시작이라고 보면 1~2n -> 2까지로 2n으로 4n번이 아닌 4n-2번 이동한다는 것을 확인해야 했고

그걸 다시 n이 아닌 2n을 기준으로(people * 2) 처리해야 하는 것을 깜빡하지만 않는다면 쉽게 해결할 수 있는 문제였다.

 

n 기준으로는 금방 풀 수 있을 것 같은데

2n으로 설정되고 -2처리까지 붙었다고 10분 가까이 걸려서 조금 당황했다.

const [people, game] = `5 20`.split(' ').map(Number)
const oneCycle = 4 * people - 2
console.log(game % oneCycle > 2 * people ? 2 * people - (game % oneCycle) % (2 * people) : game % oneCycle)

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

[개발일지] - 22(주말)  (0) 2023.07.22
[개발일지] - 21  (0) 2023.07.21
[개발일지] - 19  (0) 2023.07.19
[개발일지] - 18  (0) 2023.07.18
[개발일지] - 17  (0) 2023.07.17

+ Recent posts