오늘의 목표
오늘은 관통 프젝날이라 열심히 요구사항을 해결하니 4시 25분이 되었다.
플래너를 집에 두고와서 나중에 퇴근하고 회고하듯이 적으려 했는데 살짝 걱정되는 시점이다. ㅎㅎ
1. PS 2문제 이상 풀기
오늘도 기출문제 모음 위주로 풀어보려 한다.
[PCCP 기출문제] 3번 / 아날로그 시계
문제 이해는 어렵지 않다. 특정시간 부터 특정시간까지 흘러갈 때 초침이 분침과 시침을 몇번 만나는지를 출력하는 문제
수학적으로 접근해볼까 하다가
1초가 지나가더라도 분은 60분의 1이, 시는 3600분의 1이 추가되어야 명확한 계산이 나올 것 같아서 완탐으로 돌렸다.
시간이 23시 59분 59초를 초과해서 0시 0분 0초로 돌아가는 경우는 주어지지 않습니다.
이므로, 최악의 경우는 00:00:00 ~ 23:59:59 일테니
23 * 3600 + 59 * 60 + 59 = 86,399 이므로 시간초과가 날리 없다 생각했는데 초과가 뜬다..
아무래도 소수간의 비교가 정확하지 않아서 일 가능성이 커보이는데.
도저히 모르겠어서 코드를 봤는데 너무 명확하게 푼 풀이가 있어서 가져왔다
class Solution {
public int solution(int h1, int m1, int s1, int h2, int m2, int s2) {
// 00:00:00 ~ 종료시간 까지 울린 알람 수 + 00:00:00 ~ 시작시간 까지 울린 알람 수 + 시작시간이 알람시간인경우(+1)
int t1 = hmsToSec(h1, m1, s1), t2 = hmsToSec(h2, m2, s2);
return countAlram(t2) - countAlram(t1) + (alramNow(t1) ? 1 : 0);
}
private int hmsToSec(int h, int m, int s) {
m += h * 60;
s += m * 60;
return s;
}
private int countAlram(int time) {
// 시침은 12시간(43200초)에 한바퀴를 돌며, 같은시간에 초침은 720바퀴를 돈다
// -> 시-초 알람은 43200초 동안 719번 울리며, 43200/719 초마다 1회 울린다
int h_alram = time * 719 / 43200;
// 분침은 1시간(3600초)에 한바퀴, 같은시간에 초침은 60바퀴를 돈다
// -> 분-초 알람은 3600초 동안 59번 울리며, 3600/59 초마다 1회 울린다
int m_alram = time * 59 / 3600;
// 00시 및 12시 정각에는 시-초 / 분-초 알람이 동시에 울려 1회 페널티
int penalty = 43200 <= time ? 2 : 1;
return h_alram + m_alram - penalty;
}
private boolean alramNow(int time) {
return time * 719 % 43200 == 0 || time * 59 % 3600 == 0;
}
}소숫점 계산이 명확하지 않으니, 정수로 바꾼것도 모자라 규칙을 찾아서 합산했다.
내 현재 수준으로는 4시간이 주어져도 못푼 풀이었을 것이고.. 다시 한번 되새기며 다음에 풀어보려 한다.
그래서 제출하지 않고 북마크만 해뒀음.
오늘의 인사이트
많은 기술블로그들을 보면서 어떻게 저런 접근을 할 수 있을까
난 어떻게 더 깨우쳐야하나 라는 생각이 들었고 이를 멘토님들께 질문해봤습니다.
용스
기술블로그에 올라오는 정보들은 필요에 의해 구현된 기술을 중심으로 포스팅 될겁니다. 즉, 기술에 대한 정보에 집중한 글이지, 그 기술이 왜 필요한지는 안나와있는거죠.
기능을 구현하던, 더 좋게 개선하던, 그 행위를 왜 해야하는지가 제일 중요합니다.
결국, 무엇을 왜 해야하는가? 를 먼저 결정하고, objective를 달성하기위해 기술블로그에서 봤던 키워드들을 참조하는건 후순위가 되어야 합니다.
모찌
기업에서 작성된 기술블로그들은 문제 해결의 방법에 좀 더 초점이 맞춰지고
왜 필요한지에 대해서는 잘 안나와 있습니다. 그러다보니 어떻게를 찾기는 좀 힘들어 보여요. 아 기술 블로그가 나쁘다는 얘기는 절대 아닙니다.제가 생각하는건, 기능적인 구현 말고 고려해볼 수 있을 만한 NFR(Non-Functional Requirements) 들이라고 생각해요.
일반적으로 좋아져야 한다고 생각하는건 성능 이죠. 예를 들어, 성능이 5%이상 향상됐다. 이걸 개선했더니 응답시간이 줄었다 이런거요
하지만, 이 외에도 여러 가지들이 많습니다.
예를 들어, reliability - 신뢰성, Security - 보안, 혹은 Usability - 쉽게 사용할 수 있는가?
보통 이런걸 NFR이라고 해서 기능이 아니라 시스템의 품질이나 인터페이스, 제약 사항을 얘기 하는 거죠.
(Software engineering에 자주 등장합니다).보통의 개선점들은 품질을 향상 시키는 것과 일맥상통 한다고 저는 생각하고 있습니다.
그러므로 NFR(Non-Functional-Requirements) 목록들을 쭉 살펴보시고 내 프로젝트에선 어떤 품질을 높일 수 있을까?를 고민해보시고 적용시켜 나가는 것이 좋은 프로젝트를 만들어내고 실력을 늘리는 방법 중 하나라고 생각합니다.
오늘도 싸피셜 분들의 글을 눈팅하다가 인사이트를 얻은 질의응답이 있어서 가져왔습니다
출처 : https://garam-yang.github.io/ssafycial/ssafycial_aut3/
루트
Q. 자소서를 쓰는 과정에서 항상 보는 ‘가장 어려웠던 경험과 해결 과정’에 관한 질문에 대해서 작성 팁을 알고 싶어요.
‘어려움’에 관해서 쓸 때는 크게 2가지로 접근이 가능해요. 하나는 ‘기술적인 측면의 어려움’이에요. 이 경우에 대해서 자소서에 쓸 스토리라인을 대략적으로 말씀드리자면, 어떤 프로젝트를 만들려고 하는데, 기존에 사용했던 경험이 없는 A라는 기술의 메리트가 지금 만들고 있는 프로젝트에 꼭 필요할 것 같아서, 생소했던 A라는 기술을 공부하고 적용시키는데 어려움을 느꼈다는 스토리가 그 예가 될 수 있겠네요. 두 번째로는 ‘협업 측면의 어려움’이에요. 예를 들자면, Coding convention(코드 작성 규칙) 중 naming rule을 지키지 않거나 , 같은 파일을 팀원이 같이 수정해서 발생하는 ‘Code Conflict’ 문제가 대표적이라고 말씀드릴 수 있겠네요. 이 부분에 대해서는 라는 책을 읽어보기를 추천드리고 싶어요.
