문제링크 https://leetcode.com/problems/palindrome-number/

문제 접근

먼저, Palindrome은 앞으로 해도 이효리, 거꾸로 해도 이효리 인 글자, 숫자 기타 등등을 의미한다. 이 문제는 Reverse Integer 문제와 똑같은 로직을 사용했다. 10을 이용해서 나눗셈의 몫과 나머지를 이용해서 연산했다. 단, 이번 문제에서 음수는 false를 반환한다.

Pseudocode

1. 변수 생성
• 입력받은 정수를 저장할 변수 생성
• 결과를 저장할 변수 생성
2. 로직
• 입력받은 정수가 0이 될 때까지 반복
• 결과를 저장할 변수 = (자기 자신 X 10) + (입력받은 정수 % 10)
• 입력받은 정수 = 자기 자신 / 10
• 입력받은 정수와 결과를 저장한 변수가 일치하는지 체크
• 결과 리턴

bool isPalindrome(int x) {
    long _first = x;
    long _check = 0;

    if (x < 0)
      return false;

    while (x != 0) {
      _check = _check * 10 + x % 10;
      x = x / 10;
    }

    return _first == _check;
  }

결과

최종결론

확실히 똑같은 로직으로 한번 문제를 풀어보니, 비슷한 로직을 만났을 때 접근방법이 빠르게 보였었다. 그리고 저번과 다르게 이번에는 문제를 꼼꼼히 읽었다. 앞으로도 계속 이래야 할 텐데.... 이번 문제에선 Palindrome 단어의 뜻을 알게 된 게 가장 유익한 것 같다,, ㅎ

문제 링크 https://leetcode.com/problems/reverse-integer/

문제 접근

입력받은 정수를 순서를 뒤집어서 정수 형태로 반환하는 문제이다. 단, 음수일 경우 그대로 음수로 반환하고, 0일 경우 0을 반환한다. 그리고 끝자리가 0인 경우는 끝에서 2번째 숫자부터 시작한다. 즉, 10을 가지고 입력받은 정수를 계산하여 값을 도출한다.

Pseudocode

1. 변수 생성
• 결과를 저장할 변수 생성
2. 로직
• 입력받은 정수가 0이 될 때까지 반복
• 생성한 변수 = (자기 자신 X 10) + (입력받은 정수 % 10)
• 입력받은 정수 = 자기 자신 / 10
• 32-bit 정수 길이를 만족하는지 검사
• 결과 리턴

내가 삽질한 부분

나는 문제 파악을 빠르게 했고, 로직에 자신이 있어서 빠르게 접근했다. 하지만, 이런 행동이 내가 이번 문제 푸는 과정에서 오류를 만들었다.

If reversing x causes the value to go outside the signed 32-bit integer range [-2^31, 2^31 - 1], then return 0.

나는 이 부분을 제대로 읽지 않고 지나쳤다. 그래서 처음에는 변수를 int형으로 선언하고 계산을 했고, 그 결과 이 Runtime Error 를 보게 됐다.

runtime error: signed integer overflow: 964632435 * 10 cannot be represented in type 'int' (solution.cpp)

나는 문제점을 바로잡기 위해서 int 자료형 대신 long 자료형을 사용했다.

  int reverse(int x) {
    long result = 0;

    while (x != 0) {
      result = (result * 10) + (x % 10);
      x = x / 10;
    }

    if (result > INT_MAX || result < INT_MIN) result = 0;
    // INT_MAX 와 INT_MIN 은 <limits.h>에 정의되어 있다.

    return result;
  }

결과

최종결론

문제를 제대로 읽지 않고 틀리는 실수는 아직도 반복하고 있다는 걸 다시 느끼게 됐다.. 실수를 반복하면 실력이랬던가,,,, 이런 실력은 필요 없는데 말이다,, 문제 난이도가 쉬워도 영어공부 한다고 생각하고 천천히 문제를 읽고, 모든 요구사항을 제대로 파악하자. 그리고 자만심은 절대 NEVER !!

문제 링크: https://leetcode.com/problems/longest-substring-without-repeating-characters/

문제 접근

이 문제는 Two Pointers 알고리즘을 이용해서 풀었다. (Two Pointers 개념은 따로 정리해뒀다.)

문제의 목표는 입력받은 문자열에서 반복하지 않으면서 가장 긴 단어의 길이를 찾는 것이다. 나는 총 2가지의 방법으로 문제를 접근해봤다. 첫 번째 방법은 unordered_set을 이용해서 문제를 해결했고, 두 번째 방법은 정수형 배열을 이용해서 문제를 해결했다.

unordered_set 방법

unordered_set 을 사용한 이유

unordered_set 은 이름 그대로 값들이 정렬이 되지 않는 상태로 저장이 된다. 그리고 set 과 map 처럼 find, insert, erase 함수도 지원해주고, 그 속도는 O(1)으로 수행된다. 사실, 공부하고 있는 컨테이너라서 한번 사용해봤다...ㅎㅎ

pseudocode

1. 변수 생성
• 시작점과 끝점을 가리키는 포인터를 만든다.
• 시작점과 끝점 사이의 캐릭터들을 보관할 캐릭터형 unordered_set 을 만든다.
• 배열의 길이를 저장할 정수형 변수를 만든다.
2. 로직
• 시작점과 끝점이 문자열 길이보다 작은 경우에만 반복
• 끝점이 가리키는 캐릭터를 unordered_set에서 검색
• 만약, 검색이 안 된다면 캐릭터를 unordered_set 에 추가하고 최댓값 정의 후 끝점 한 칸 증가
• 검색이 된다면 시작점이 가리키는 캐릭터를 unordered_set 에서 삭제 후 시작점 한 칸 증가
• 최댓값을 리턴

#include <iostream>
#include <string>
#include <unordered_set>

int lengthOfLongestSubstring(std::string s) {
    unordered_set<char> arr;
    int result   = 0;
    int left  = 0;
    int right = 0;

    while (left < s.size() && right < s.size()) {
      if (arr.find(s[right]) == arr.end()) {    // find함수는 해당 값을 찾지 못하면 end를 리턴한다.
        arr.insert(s[right]);
        result = max(result, right - left + 1);
        right++;
      }
      else {
        arr.erase(s[left]);
        left++;
      }
    }

    return result;
 }

결과

비록 unordered_set 을 사용해보겠다는 패기로 사용했지만, 결국 Two Pointer만 연습하고, 내장 함수의 기능의 도움을 많이 받은 코드였다..ㅎ 역시 내장 함수 짱👍

정수형 배열 방법

정수형 배열을 사용한 이유

아직까지도 나에게 가장 익숙한 것은 기본 배열이다. 그리고 비록 문자열을 입력받지만, 알파벳도 아스키코드값을 가지고 있기 때문에 충분히 가능성 있다고 생각했다.

pseudocode

1. 변수 생성
• 시작점과 끝점을 가리키는 포인터를 만든다.
• 시작점과 끝점 사이의 캐릭터들을 보관할 정수형 배열을 만든다.
• 배열의 길이를 저장할 정수형 변수를 만든다.
2. 로직
• 문자열을 순환할 인덱스가 문자열의 길이보다 작은 경우에만 반복
• 배열 속 캐릭터의 아스키코드 값의 자리를 하나 증가 후 끝점 한 칸 증가
• 만약, 해당 캐릭터의 아스키코드 값의 자리가 1보다 크면 시작점의 아스키코드값의 자리를 1 감소
• 그리고 시작점을 한 칸 증가 후 끝점은 한 칸 감소
• 만약 끝점이 최대댓값보다 크면 끝점을 최댓값으로 정의
• 최댓값 리턴

int lengthOfLongestSubstring(std::string s) {
    int arr[125] = {0};
    int max      = 0;
    int left     = 0; 
    int right    = 0;

    for (int i = 0; i < s.size(); i++) {
      arr[int(s[i])]++;            // 아스키코드 값의 자리를 1 증가
      right++;                // 끝점을 한 칸 이동

      while (arr[int(s[i])] > 1) {            // 반복되는 캐릭터를 찾았다는 의미
        arr[s[left]]--;                
        left++;
        right--;            // 최대값을 정의하기 위해서 1 감소
      }

      if (right > max)
        max = right;
    }

    return max;
  }

결과

비록 unodered_set 을 사용했던 코드보다 런타임 속도나 메모리 사용량에서 좋은 결과를 보여줬지만, 코드를 구현하는데 몇 번의 시행착오를 겪었다. 특히 반복되는 캐릭터를 찾은 조건에서 while을 써야 하는 이유를 찾는데 오래 걸렸다. while 을 쓰는 이유는 중복된 캐릭터가 시작점이 아닌 중간에 있는 경우가 있을 수도 있기 때문이다. 그리고 배열의 크기는 소문자 z의 아스키코드 값보다 조금 더 여유 있게 줬다. 참고로 z의 아스키코드값은 122이다.

최종 결론

사실 나는 아직 알고리즘 문제를 많이 풀어본 게 아니기 때문에, 런타임 속도와 메모리 사용량을 신경 쓰면서 문제를 푸는게 익숙하지 않다.. 예발자,,,ㅠ 그리고 시간 복잡도도 신경 쓰면서 하기에는 아직 너무 어렵다.. 그래서 그냥 Two Pointers의 개념을 이해하고 문제를 풀어나가는데 집중했었다. 그리고 여러 방법을 사용하면서 푸는 것도 연습해봤다. 계속 문제를 풀면서 런타임에 걸려도 보고 메모리에도 걸려보면서 계속 경험을 쌓아야 할 것 같다. 그래도 Two Pointers에 대한 개념은 어느 정도 자리 잡힌 것 같다. ! 무~ ㅇㅑ 호!

개인적으로 공부한 내용을 정리하였습니다. 틀린 부분은 피드백을 주시면 감사하겠습니다. - JAY -

두 알고리즘의 공통점과 차이점

먼저, 나는 두 알고리즘은 서로 굉장히 비슷한 알고리즘이라고 생각한다. 개인적으로는 Sliding Window가 Two Pointers와 아주 유사하다고 생각한다. 두 알고리즘은 길이가 N인 배열 속에서 순서대로 값들을 이용해서 목푯값을 찾아낸다. 그 과정에서 두 알고리즘은 두 개의 포인터를 사용한다. 하지만!!! Sliding Window 는 항상 구간의 넓이가 고정되어있고, Two pointers 는 구간의 넓이가 조건에 따라서 유동적으로 변한다. 그리고 두 알고리즘의 시간 복잡도는 O(N)이다

아직 시간복잡도에 대한 개념이 정확하지 않아서, 참고했던 블로그를 아래에 첨부한다. https://blog.chulgil.me/algorithm/

개념 정리를 도와줄 예제

길이가 9인 정수 배열 속에서 정수들의 합이 5인 조합을 찾아보기로 하자.

arr[9] = {1, 2, 3, 4, 5, -4, 3 , 1 ,1}

Two Pointers 방법

전제조건

• 시작점과 끝점을 가리키는 두 개의 포인터 사용 -> st_ptr , end_ptr
• 맨 처음에는 둘 다 0을 가리킨다.
• st_ptr < 9 일 때까지 반복한다.
• 항상 end_ptr >= st_ptr 이여야 한다.
• 만약 구간의 합이 5 이상, 또는 end_ptr 가 배열의 끝에 도달했으면, st_ptr++
• 그렇지 않다면 end_ptr++
• 구간의 합이 5이면 count 개수를 하나 추가한다. 원래 처음 시작은 두 포인터 모두 0을 가리키고 있는데, 그 부분은 생략됐다. Two pointers는 그림처럼 두 개의 포인터의 구간은 조건에 따라서 유동적으로 변한다. 즉, 두 포인터는 조건에 맞춰서 배열의 처음부터 끝까지 증가하면서, 특정 구간의 값들의 합이 5가 되는 경우를 세는 것이다.!!

Sliding window 방법

전제조건

• 시작점과 끝점을 가리키는 두 개의 포인터 사용 -> st_ptr , end_ptr
• st_ptr 과 end_ptr은 구간의 처음과 끝을 가리킨다.
• 구간은 정해진 크기만큼 배열의 끝에 도달할 때까지 한 칸씩 증가한다. (구간의 크기는 3이라고 가정한다.)
• 구간의 합이 5이면 count 개수를 하나 추가한다. 원래 처음 시작은 두 포인터 모두 0을 가리키고 있는데, 그 부분은 생략됐다. 구간의 크기는 고정된 상태로 배열의 끝까지 증가하면서 목푯값인 5를 찾으면 count 개수를 추가하였다. 아래 그림을 보면 현재 구간의 합은 이전 구간의 합과 겹치는 부분이 있다는 규칙을 찾아낼 수 있다. 이 규칙은 나중에 sliding window 알고리즘 문제를 풀 때 계산하는 식을 조금 더 간단하게 구현할 수 있을 것 같다.

최종 결론

두 알고리즘의 개념이 크게 어렵지 않아서 이해하는데 어려움은 없었다. 하지만, 많은 문제를 풀어보면서 내 것으로 만드는 노력은 당연히 필요할 것이다.

나는 어제저녁 문득 블로그를 만들어야겠다고 생각했다.

그래서 난 바로 개발자들은 무슨 블로그를 사용하고 있는지 구글링을 시작했다.

나는 아직 예발자 (예비 개발자) 이기 때문에 개발자분들의 경험을 따라 하는 게 나에게 옳은 길이다.

1. 왜 갑자기 블로그를 만들려고 할까

나는 이 쪽 계통으로 처음 발을 딛으면서 C언어를 배웠다.
당연히 비전공자인 내가 C를 배우는데, 그것도 영어로 배우니까 어려움이 너무 많았었다.
그래서 난 아이패드에 내가 수업시간에 배운 개념을 다시 한글로 노트 정리를 하면서 복습해오고 있었다.

내가 정리한 노트이기에 내가 읽을 때 가독성은 매우 뛰어나고 이해도 명확하게 된다.
하지만, 점점 수업의 난이도는 올라가고, 배우는 것은 더 많아지니까 손으로 정리하는데 한계를 느꼈다.
특히 이번 학기에 CPP을 배우면서 단순히 개념만 정리하기엔 부족해서 코드 예시를 같이 정리하는데 점점 가독성이 안 좋아졌다.
이전에는 함수가 헷갈릴 때 내가 정리한 노트를 보면 바로 정답을 찾았는데,
요즘은 내 노트를 봐도 한 번에 해결이 안 돼서 구글링을 같이 병행하는 경우가 잦고 있다.
심지어 학교 과제와 퀴즈의 늪에 빠져 하루하루 서바이벌이고, 자연스럽게 노트 정리는 뒤쳐지고 있었다.
그러던 중 학기 말이 다가오면서 점점 늪에서 빠져나와 시간적으로 조금 여유가 생겼다.
그래서 노트 정리를 하려고 펜을 든 순간 블로그가 떠 올랐다.
매일 나도 모르는 함수, 알고리즘을 구글링 해서 찾으면서 왜 정작 난 손으로 정리를 하려고 할까 하는 의문이 생겼다.
그래서 난! 바로 뒤도 돌아보지 않고 개발자 블로그에 대해서 검색하기 시작했다.
정말 많은 블로그들이 있었고, 난 여러 개발자들이 비교한 글을 읽으면서 나만의 기준에 맞춰서
후보군을 추려나갔다.

2. 나에겐 총 4개의 블로그 후보군이 남았다

Github.io || Tistory || Velog || Medium

나의 블로그 조건은 조금 단순했다.

일단, 먼저 이뻐야한다.!

나의 선입견이겠지만, 개인적으로 블로그가 이쁘고 깔끔해야 가독성이 올라간다.

그리고 두 번째로는 쓰기 편해야 한다.!

나는 블로그로 구독자를 모으거나, 수익을 창출할 생각이 없다.

그냥 내가 공부한 코딩을 기록하고, 실수를 기록하기 위함의 노트일 뿐이기 때문이다.

단 두 가지의 조건을 두고 4가지의 후보군을 가지고 어젯밤에 고민한 결과!

char candidate[4] = {github_hub, tistory, velog, medium};

for (i = 0; i < 4; i++) {
  if (cadidate[i] == '이쁘냐?' && candidate[i] == '편하냐?') {
      cout << cadidate[i] << "너로 정했다 !!!";
      break;
  }
}

3. 4개의 블로그 후보군을 정밀 비교 분석!

모든 건 나의 개인적 의견이다.. -JAY-

Github

Github.io의 가장 큰 장점은 그냥 간. 지. 🔥
내가 하나부터 열까지 제작해야 하고, 기본적으로 git에 대한 지식을 가지고 있어야 한다.
기본 지식이 있다면 jekyll이나 Hexo 등 여러 이쁜 테마로 커스텀도 할 수 있다.
또 github과 연동이 되어 나의 잔디밭을 채울 수 있다는 점이다.
내 코딩 삽질들을 기록하면서 잔디밭을 가꾸는 일. 일석이조 아니겠는가.
그리고 자연스레 git에 대해 익숙해지고, 공부도 하게 될 것이다.
이렇게 보면 github.io는 장점이 꽤 많은 블로그가 될 것처럼 보인다.
하지만, 나는 쓰기 편해야 한다. 그냥 나의 삽질과, 일상을 쉽게 끄적일 수 있는 블로그가 필요할 뿐
너무 전문적으로 블로그를 만들어나갈 시간이 부족하다.
현생은 과제와 퀴즈와 공부의 늪에 빠져있기 때문에...

Tistory

사실 Tistory는 내가 공부하면서 GOD Stack overflow 다음으로 많이 접하는 블로그 중 한 곳이다.
그만큼 많은 개발자들이 사용하고 있다는 것 아니겠는가. 이 점이 Tistory의 장점이다.
뭐 예전엔 초대장? 이 있는 사람만 할 수 있었다는데,, 지금은 아니니까 ^^ 나도 사용할 수 있다.
그리고 뛰어나신 분들이 무료로 이쁜 스킨들도 배포해주시고, 심지어 그 스킨을 내가 직접 커스텀도 할 수 있다.
감사합니다. 🙇‍♂️

Velog

나는 Velog를 이번 연도에 공부를 하면서 처음 알게 됐다. 처음 봤을 때 그 느낌은 이쁘다 깔끔하다 였다.
이걸 Velopert님이 개발하셨는데, 역시 세상엔 대단하신 분들이 많다..
이번에 결정하기 전, 테스를 하기 위해서 나도 대충 글을 써 봤는데, 확실히 정말 편했다.
Velog 역시 Github.io 나 Tistory처럼 마크다운도 지원해서 코드를 입력하는데도 편리했다.
하지만, 사이드바엔 태그 목록만 제공하고 시리즈는 따로 탭으로 구분되어 있는 점이 조금 아쉬웠다.

Medium

해외에서 유명한 Medium. 그래서 다 영어로 되어 있는 Medium.
해외에서 공부하고 있는 나에겐 어떻게 보면 더 필요한 블로그가 아닐까 싶었지만,
글을 작성하는 게 마크다운 형식이 아니다. 그리고 코드를 삽입하는 방법도 조금 번거로웠다.
Medium 역시 블로그 자체는 깔끔하고 글을 작성하는데 편리했지만, 나에겐 코드를 작성하는 것도
중요했기 때문에 아쉬웠다.

4. 최종 나의 선택

비록 나는 2가지 조건을 두고 고민을 했지만, 장단점을 찾아보고 직접 써보며 (Github.io 빼고) 비교해 본 결과 Tistory로 결정했다.!!! 이유는 대단하신 분들께서 무료로 이쁜 테마를 배포해주시고, 나는 그 테마를 나의 입맛에 맞게 수정도 할 수 있다.
나도 실력이 점점 쌓이면 내 입맛에 맞게 수정할 수 있을 거라고 믿는다 ^^
또 마크다운도 지원해서 글을 작성하는데 편리하다. 솔직히 마크다운에 익숙하진 않지만, 꼭 다룰 줄 알아야 하는 문법이라고 생각해서 자주 쓰려고 노력 중이다.
나는 지극히 내 개인적인 관점에서 나에게 필요한 조건만 두고 비교를 했다.
다른 개발자분들은 조금 더 기술적인 면에서 접근하셨었다. 보통 검색엔진에 노출이 많이 되는지,
광고수익을 창출할 수 있는지 등 여러 측면에서 비교하시면서 결정하셨다.

5. 하지만, 난 내 후보군을 버릴 수 없다.

나는 나의 블로그를 결정했음에도 불구하고, 이 놈의 결정장애 덕분에 나의 후보군들을 버릴 수 없게 되었다.
그 결과 난 아직은 안 보이지만, 곧 나에게 다가 올 미래를 후보군들을 가지고 대비를 하였다.

먼저, Github.io 는 github와 연동이 되면서 나만의 사이트를 구축할 수 있다는 장점을 이용해서
나의 포트폴리오 페이지로 제작할 예정이다. 포트폴리오를 만드는 과정에서 더 많은 공부를 할 수 있을 테고, 또 내가 구상하는 대로 페이지를 구축할 수 있다는 점도 굉장히 큰 장점인 것 같다.
그리고 Tistory는 지금 계획처럼 코딩을 하면서 한 삽질을 기록하고, 또 새롭게 배운 알고리즘이나, 내가 푼 알고리즘 문제를 기록할 것이다. 이 모든 것들이 다 나의 지식이 될 것이다.

그렇게 된다면 나중에는 내가 헷갈리는 함수를 구글링이 아닌 내 것들을 참고해서 코딩하는 날도 올 것이다.
마지막으로 Medium 은 해외에서 많이 사용하는 블로그인 만큼 Tistory에 기록하는 기록들을 Medium에 영문판으로 기록하려고 한다. 해외에서 공부하고, 취업까지 목표로 하고 있는 만큼 나는 코딩만큼이나 영어에도 익숙해져 야하기 때문이다.
또 이 나라 면접관들은 내 Tistory를 보더라고, 내용은 이해를 못할 가능성이 99% 이기 때문에, 양쪽으로 남기는 것을 도전하려고 한다.

6. 블로그에 대한 고민의 최종 결과

그래서 난!

Github.io를 이용해서 나의 포트폴리오를 만들고 그 안에 Tistory와 Medium 링크를 걸어두고,  
내가 꾸준히 나만의 개발노트를 작성해왔다는 성실함을 어필하려고 한다.

이게 좋은 쪽으로 작용할지 아닐지 모르겠지만, 내가 성실하게 하는 게 일단 중요할 것 같다.

7. 나의 인생 첫 블로그를 마치며

평소 난 매일 일기를 쓴다. 일기를 쓴 지 벌써 9년이 넘어가는데, 그 시간 동안 나는 손으로 글을
쓰는 것에 재미를 느끼고 있었다. 근데 막상 인터넷에 글을 쓴다고 생각하니까 처음엔 이상했다.
매일 나 혼자 볼 수 있는 노트에 글을 적은 걸 누가 볼 수 있다고 느껴졌다.
그 느낌은 뭔가 민망하고 쑥스러웠다...
하지만 생각보다 블로그에 쓰는 게 재미다고 느껴졌다. 처음엔 대충 글을 쓰고 기록만 하자 식으로 접근했는데, 막상 쓰다 보니까 욕심이 생기고, 조금이라도 더 가독성 있게 쓰고 싶어 졌다,
혹시나,, 만약에,, 누군가가 본다면 그래도 한 줄이라도 읽는 글이 됐으면 좋겠다는 욕심이 났다.
데일리 루틴으로 자리 잡히긴까진 시간이 필요하겠지만,, 개발자가 되려면 해보자.
이만 끝..