일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |
- ineer join
- stringbuilder의 reverse()
- 최대공약수와 최소공배수
- islowercase()
- git 컨벤션
- toLowerCase()
- 프로그래머스 레벨1
- 자바 스트링
- Git사용법
- StringBuilder
- 자바 최소공배수
- 스프링환경설정
- 모던자바
- 자바 최대공약수
- 동일성과 동등성
- 자바 유클리드
- 유클리드호제법
- isuppercase()
- replaceAll()
- 스프링뼈대
- 스프링
- sql 데이터형 변환
- string과 stringbuilder
- while과 two-pointer
- 래퍼타입
- addDoc
- string
- 최대공약수
- 최소공배수
- 베주계수
- Today
- Total
주노 님의 블로그
20240719 본캠프 5일차 TIL 본문
본캠프 5일차 내용 간단요약
- 09:00 ~ 09:30 : 아침회의
- 09:30 ~ 11:00 : 개인공부
- 11:00 ~ 12:00 : 코드카타
SQL(54) 알고리즘(40~41) - 이상한 문자 만들기 - 12:00 ~ 13:00 : 점심시간
- 13:00 ~ 13:10 : 회의
- 13:10 ~ 14:00 : 개인공부
- 14:00 ~ 15:30 : 발표
- 15:30 ~ 16:40 : KPT 및 잡담
- 19:00 ~ 20:00 : 웹 특강
- 20:00 ~ 21:00 : TIL작성
아침회의
일정 : 오늘 하루는 모든 팀원이 비슷하게 흘러갈 것 같다
프로젝트 제출 : 회의가 끝나는대로 제출하기로 함
발표 준비 : 순조롭게 진행되고 있음
TIL을 이대로 써도 될까! : 이건 내 질문이었는데 가끔 TIL을 쓰면 길면 2시간 짧으면 20~30분이다
주말에 따로 좋은내용 뽑아서 올리긴 할거지만 이거 시간을 너무 잡아먹는것 같아서 물어봤다.
코드카타 - 알고리즘 이상한 문자 만들기
문자열 s는 한 개 이상의 단어로 구성되어 있습니다. 각 단어는 하나 이상의 공백문자로 구분되어 있습니다. 각 단어의 짝수번째 알파벳은 대문자로, 홀수번째 알파벳은 소문자로 바꾼 문자열을 리턴하는 함수, solution을 완성하세요.
제한 사항
문자열 전체의 짝/홀수 인덱스가 아니라, 단어(공백을 기준)별로 짝/홀수 인덱스를 판단해야합니다.
첫 번째 글자는 0번째 인덱스로 보아 짝수번째 알파벳으로 처리해야 합니다.
입출력 예
처음에는 구현을 split으로 구현했다.
답은 맞는데. 채점을 하면 몇몇 문제가 틀리는 것이다
처음이나 끝에 공백이 있는경우는 가차없이 잘라낸 나
split을 사용했기때문에 다시 뒤집어 엎어야 했다
class Solution {
public String solution(String s) {
String answer = "";
boolean flag = true;
int index = 0, cnt = 0;
StringBuilder sb = new StringBuilder();
while(flag)
{
if(s.length()-1 <= index)
{
flag=false;
}
char ch = s.charAt(index);
if(ch == ' ')
{
sb.append(ch);
cnt=0;
}
else if(cnt%2==0)
{
sb.append(Character.toUpperCase(ch));
cnt++;
}
else
{
sb.append(Character.toLowerCase(ch));
cnt++;
}
index++;
}
answer = sb.toString();
return answer;
}
}
그래서 구현한 결과물이다
변수 설명
answer : 답을 저장할 문자열
flag : 반복문을 제어하는 불리언 변수
index : 문자열의 전체 길이를 따라가는 변수
cnt : 단어의 길이를 따라가며, 짝수 홀수인덱스를 결정하는 변수
sb. : 문자를 추가하여 answer를 만드는 객체.
flag값을 두어, index와 flag가 만나는 지점(끝 너머)가 되면 정지.
공백은 더하고 cnt값을 0로 초기화하였다.
"각 단어의 짝수번째 알파벳은 대문자로, 홀수번째 알파벳은 소문자로 바꾼 문자열을 리턴하는 함수"
라는 단어를 제대로 읽지 않아서 틀렸기 때문이다.
위 코드처럼 작성하면 첫, 끝 문자열에 있는 공백도 처리해준다.
코드카타 - DP와 반복문
한국중학교에 다니는 학생들은 각자 정수 번호를 갖고 있습니다. 이 학교 학생 3명의 정수 번호를 더했을 때 0이 되면 3명의 학생은 삼총사라고 합니다. 예를 들어, 5명의 학생이 있고, 각각의 정수 번호가 순서대로 -2, 3, 0, 2, -5일 때, 첫 번째, 세 번째, 네 번째 학생의 정수 번호를 더하면 0이므로 세 학생은 삼총사입니다. 또한, 두 번째, 네 번째, 다섯 번째 학생의 정수 번호를 더해도 0이므로 세 학생도 삼총사입니다. 따라서 이 경우 한국중학교에서는 두 가지 방법으로 삼총사를 만들 수 있습니다.
한국중학교 학생들의 번호를 나타내는 정수 배열 number가 매개변수로 주어질 때, 학생들 중 삼총사를 만들 수 있는 방법의 수를 return 하도록 solution 함수를 완성하세요.
왜인지는 모르겠지만 나는 슬라이딩 윈도우로 접근하고 있었다
풀다가 생각해보니 DP가 쓸 필요가 없다고 생각됐다
class Solution {
public int solution(int[] number) {
int answer = 0;
for(int i = 0 ; i<number.length; i++)
{
for(int j = i+1; j < number.length; j++)
{
for(int k = j+1; k < number.length; k++)
{
if(number[i]+number[j]+number[k]==0)
{
answer++;
}
}
}
}
return answer;
}
}
그래서 아주 간단하게 해결했다
시간복잡도는 O(n^3)이 되지만, number배열이 13개까지 밖에 없어서 문제는 없어보였다
DP와 반복문은 어떨때 써야하나
반복문, 재귀문 사용의 기준
1. 모든 경우의 수를 고려해야 할 때.
2. 문제의 규모가 작을 때.
3. 단순 계산이 필요할때
DP의 기준
1. 중복되는 하위문제.
모든 경우의 수를 고려해야하지만, 재귀문의 경우 비효율적, 또는 스택오버플로가 발생할 수 있다.
메모이제이션이나, 테이블을 두어 재사용하고, 중복계산을 피한다.
2. 최적 부분 구조.
큰 문제를 쪼개서 작은문제에서 최적해를 찾는 과정
그 중에서 슬라이딩 윈도우 기법은
'연속된' 부분이거나.
고정 크기의 윈도우를 이동시킬때. 계산하는 방법이다
개인 강의
- hunk별로 스테이징하기
내가 수정한 부분을 확인하며 스테이징 영역으로 올리고 싶을때
git add -p
hunk는 파일, 같은파일 안에서도 연속된 수정이 있는경우 그 부분만 add를 할 수 있다.
y : 스테이지에 올린다
n : 올리지 않는다.
-
위에서 manager과 coach를 변경
아래에서 drax와 groot를 변경하지않는다면 - 변경사항을 확인하며 커밋하기
git commit -v
변경된 부분을 알려준다.
git commit -v는 git diff -staged와 git commit를 합친것과 같다.
git diff --staged : 변경된 부분을 알려주는것 - 커밋하기 애매한 변화 치워두기
다른 작업을 하다가 어떤 작업을 먼저 해야할 상황에 기존 작업을 잠시 치워두는것
tomcats의 작업을 먼저 해야할때.
tamcat의 작업만 add한 후
git stash를 사용하면 아래와같이 변하게된다.
스태시 영역에 현재 작업이 저장된다.
다시 가져오려면?
git stash pop
원하는 stash만 가져오고 싶을때
git stash
KPT회고
Keep
팀워크가 잘 이루어졌고, 상시 소통이 원활하게 이루어졌으며, 모르는 내용은 서로 물어보거나 열심히 찾아 해결하려는 태도가 좋았다. 또한, 원하는 목표를 모두 구현하였고, 코드의 형상관리가 잘 되었다.
Problem
각자 발생한 오류를 스스로 해결했다. 이는 긍정적이지만, 매일 아침 회고 시간에 서로 공유하지 않아 아쉬웠다. 오류를 공유하면 다른 팀원이 같은 실수를 피할 수 있을 것이다.
css 네이밍을 나중에 너무 대충 지었다.
Try
매일 아침에 서로 발생한 문제를 알려주며 어떻게 해결했는지 말해주어 다른 팀원이 같은 실수를 방지하게 한다
해당 구역에 맞게 css이름을 관련지어서 작성한다.
'TIL' 카테고리의 다른 글
20240723 본캠프 7일차 TIL (0) | 2024.07.23 |
---|---|
20240722 본캠프 6일차 TIL (0) | 2024.07.22 |
20240718 본캠프 4일차 TIL (0) | 2024.07.18 |
20240717 본캠프 3일차 TIL (0) | 2024.07.17 |
20240716 본캠프 2일차 TIL (0) | 2024.07.16 |