기준날짜를 대상으로 CONVERT를 이용하여 날짜 형변환

예시

== 추가 예정 ==

Situation

날짜 기준으로 DB 데이터 추출 시 매번 검색하여 쿼리 작성 → 소요시간 증가

데이터베이스에서 처리된 결과를 저장하는 객체로 주로 SELECT문의 결과를 저장합니다.

ResultSet 사용방법

• executeQuery()를 통해 쿼리 결과를 ResultSet객체에 저장합니다.
• res.next()를 통해 SELECT문의 row 1개씩 순회하며 원하는 값을 출력 할 수 있습니다.

try{
    ResultSet = res = null;
    Connection con = DriverManager.getConnection(url, id, pw);
    Statement stmt = con.createStatement();
    String sql = "SELECT * FROM book";

   res = stmt.executeQuery(sql);

  while(res.next()) {
    int bookId = res.getInt("book_id");
    String bookName = res.getString("book_name");
    String bookLoc = rest.getString("book_loc");

    out.print("bookId : " + bookId + ", ");
    out.print("bookName : " + bookName + ", ");
    out.print("bookLoc : " + bookLoc + "</br>");
  }
} catch (Exception e) {
} 

• while(res.next())를 통해 데이터(row)가 있는지 먼저 확인하고 데이터에 접근 하므로 NullException이 발생하지 않습니다.

Situation

중복호출건 혹은 Null값으로 인해 배포 결과가 UPDATE 안되는 현상 발생

SELECT 후 UPDATE 하는 방식이므로 SELECT 되지 않으면 배포 결과가 저장되지 않음

Solution

SELECT 후 결과 데이터를 LOG를 통해 찍어내므로써 중복호출 혹은 NULL 값이 발생하는 현상 유추 가능할 것으로 예상하여

추후 동일한 현상이 발생한 경우 Log 확인을 위해 인터페이스에 ResultSet 결과 출력코드 추가

SQL Server 2016부터 사용 가능

STRING_SPLIT(“문자열“, ”구분자“)

만약 apple, tomato, orange 를 ,기준으로 SPLIT 하면 총 3개의 row가 나옵니다.

1. REPLACE()

REPLACE(‘문자열’, ‘찾을 문자열’, ‘치환 문자열’)

치환할 때는 대소문자 구분없이 모두 치환합니다.

SELECT REPLACE(‘Microsoft SQL Server’, ‘MICROSOFT’, ‘MS’)

=> MS SQL Server

대소문자 구분하여 치환할 경우 Korean_Wansung_CS_AS옵션을 사용해야합니다.

• Korean_Wansung_CS_AS : 대소문자 구분
• Korean_Wansung_CI_AS : 대소문자 구분 없음

SELECT REPLACE(‘Microsoft SQL Server’, COLLATE Korean_Wansung_CS_AS,  ‘MICROSOFT’, ‘MS’)

=> Microsoft SQL Server

2. STUFF()

STUFF(‘문자열‘, ’치환 시작위치‘, ’치환문자열 길이‘, ’치환문자열‘)

특정 위치의 문자열을 치환하고 싶은 경우 사용하며,이름 또는 전화번호 등 개인정보를 식별하지 못하도록 마스킹 처리 할 떄 주로 사용됩니다.

SELECT STUFF(‘오렌지’, 2, 1, ‘0’)

=> 오0지

3.TRANSLATE()

TRANSLATE(‘문자열‘, ’찾을문자 리스트‘, ’치환문자 리스트‘)

찾을 문자열과 치환문자가 통째로 문자열로 인식하는 것이 아니라 순서대로 1:1 매핑으로 인식되어 문자가 치환됩니다.

여러 개의 문자를 각각 다른 문자로 치환하고 싶은 경우 많이 사용합니다.

REPLACE 함수를 사용하면 중첩해야할 경우도 TRANSLATE를 사용하면 쿼리가 훨씬 간결해집니다.

SELECT TRANSLATE('Microsoft SQL Server', 'SQL', 'ⓢⓠⓛ')

=> Microⓢoft ⓢⓠⓛ ⓢerver

Situation

감사 대비를 위해 사용자테스트 관련 데이터 추출을 하는 과정에서 text 형식으로 가지고 있는 테스트 번호들을 STRING_SPLIT()을 이용해 구분하고 싶었다.

Solution

2012년도 버전을 사용하고 있어 STRING_SPLIT()함수가 사용 불가능해서 추출하기 매우 힘들었다. 도중에 데이터 추출이 취소되어서 더이상 진행하지 않았다.

CWE는 프로그램을 실행시키지 않고 분석만으로 코드의 결함을 검출합니다. 즉, 다양한 소프트웨어 언어 및 아키텍처, 디자인 패턴, 설계 단계에 발생 가능한 취약점을 검출합니다.

SQL인젝션, 크로스 사이드 스크립팅(XSS), 버퍼 오버 플로우 등 결함 식별을 위해 결함의 종류 목록을 체계화하여 제공합니다.

CWE-660 : Java에서 정적 분석 도구에 의해 검출되는 오류(74개)

오류 메세지 처리 메소드

• e.getMessage() : 에러의 원인 출력

  For input String: “”

• e.toString() : 에러의 Exception 내용과 원인을 출력

  java.lang.NumberFormatException: For input string: “”

• e.printStackTrace() : 에러의 발생근원지를 찾아서 단계별로 에러를 출력

  java.lang.NumberFormatException: For input string: “”
    at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
    at java.lang.Integer.parseInt(Integer.java:580)
    at java.lang.Integer.valueOf(Integer.java:766)
    at makingArt.MakingArt.main(MakingArt.java:17)

런타임 시 오류가 발생한 시점부터 호출한 클래스 및 메소드가 순차적으로 출력되어 구조를 유추할 수 있습니다.

해결방법

외부에 노출될 경우 공격의 빌미를 제공하므로 반드시 보완해야합니다. 최소한의 정보만 제공할 수 있도록 재정의 하거나 아예 삭제하는 방법이 있습니다.

Situation

배치 코드의 e.printStackTrace()가 BigLook 에 걸려서 소스코드 취약점 조치경과 받음

Solution

기간계와 연관된 배치는 아니었으므로 단순삭제로 조치함.

간단히 설명하자면 여러 UTF 인코딩 파일의 타입을 구분하기 위해 파일의 앞부분에 구분 코드를 추가하는 것입니다.

BOM은 UTF-16의 BE(빅엔디안)과 LE(리틀엔디안) 모드를 구분하기 위해 탄생했습니다. BE(빅엔디안)과 LE(리틀엔디안)의 차별점은 메모리에 저장되는 방식입니다. 두 방식이 다르다는 것을 명시하기 위해 유니코드 문서의 첫 번째에 값을 삽입하여 구분합니다. 이런 방식을 BOM 이라고 합니다.

UTF-8 vs UTF-8(B)

기본적으로 UTF-8은 UTF-16과 달리 인코딩 방식이 1개이므로 BOM이 필수적이지 않습니다. 있으나 없으나 동일하게 인코딩되어 디코딩 하는데도 문제가 없죠.

Unix 계열에서는 UTF-8을 기본적으로 사용하여 별 문제가 없지만, Windows의 기본 내장 프로그램(메모장 등)에서는 UTF-8(B)를 기본으로 사용하고 있습니다.

만약 UTF-8로 저장되어 있는 문서를 메모장을 이용해 열고, 수정하여 저장했다면 그 파일은 이제 UTF-8(B)로 저장됩니다.

Situation

사용하던 PMD 룰셋에서 신규 룰셋을 추가하고, 기존의 룰셋을 변경해 적용시키는 과정에서 오류 발생

Caused by: org.xml.sax.SAXParseException; lineNumber: 1; columnNumber: 1; 
프롤로그에서는 콘텐츠가 허용되지 않습니다.

Solution

기존의 Windows의 메모장에서 수정하여 저장했던 것을 방식을 변경하여 이클립스에서 파일을 열어 수정하고 저장하니 기존과 동일하게 UTF-8로 저장되었으며, 정상적으로 PMD 룰셋 적용도 되었다.

장장 한달만의 PMD 룰셋 변경 및 추가 개발이 끝났다. 이 과정에서 PMD 업그레이드가 필요하다는 사실도 알게 되어 기한이 더욱 촉박하게 되었지만, 그래도 일단 큰 산 하나를 넘은 것 같아 뿌듯하다.

회사에서 개발자로써 근무한지도 벌써 1년 6개월이 됐다.

컴퓨터관련 학과에 입학해 자연스럽게 졸업하면 개발자를 해야겠다고 생각했다. 마침 IT 관련 학과에 대한 관심도 급증했고, 모두가 원하는 직업이 되었기에 더욱 당연하게 생각했던거 같다.

개발자가 되고 싶다는 욕심으로 필수 교양을 제외하고는 모두 전공을 수강했고 중간중간 스터디도 하고, 인턴도 하고, 알고리즘 공부도 열심히 했었던거 같다.

졸업과 동시에 취업을 하고 싶어 막학기를 남기고 휴학해 취업 준비를 시작했다. 하지만 약 1년반동안 취업준비를 했지만 면접은 커녕 코딩테스트도 합격하기 쉽지 않았다. 취업 준비를 시작했을 때는 네이버, 카카오 등 IT 서비스 기업들의 대규모 채용이 많았지만 코로나가 시작되고 시장이 급격하게 얼어붙으면서 점점 기회가 사라져갔다.

짧은 시간에 분위기가 급변하는 모습을 보고 기존의 원했던 IT 서비스 기업이나 스타트업이 아닌 금융권이나 대기업을 가야겠다는 생각이 들었다. 하지만 금융권이나 대기업은 학력이 중요하고 알고리즘 외에도 인적성 검사를 봐야했기 때문에 더욱 힘들어졌다.

취준 기간이 길어지면서 자존감도 많이 떨어지고, 심리적으로 불안한 시간들을 보냈다. 점점 채용시장이 좁아지고 있었기에 이번이 정말 마지막이다! 라는 생각으로 열심히 했다.

졸업 직전 취업에 성공하여 목표했던 졸업 전에 개발자로서 회사를 다닐 수 있게 됐다.

워낙 내향적인 사람이고 인턴을 했을 때 너무 힘들었었던 경험이 있어 회사생활에 적응하는데 1년 6개월이나 걸린 것 같다.

앞으로는 회사생활을 하면서 새로 알게된 것이나 기존에 알았지만 정리하고 싶거나 상기하고 싶은 것들을 이 공간에 차곡차곡 쌓아나가고 싶다.