- Mybatis 사용시 쿼리문에 문자열 비교연산자나 부등호를 처리할 때가있습니다.
그러면 < 와 같은 기호를 괄호인지 아니면 비교연산자 인지 확인이 되지않아요.
이외에도 특수문자 사용하는데 제한이있습니다.
이럴때 사용한것이 <![CDATA[ 입니다.
CDATA 안에 들어가는 문장을 문자열로 인식하게 합니다.
이렇게 사용하면 SQL안에 특수문자가 들어가도 문자열로 인식하기때문에
문제를 해결할수있습니다.
금주 진행할 업무
- trade (front<->API Server)
- 이용내역 확인 API 분석(front<->API Server)
- 블록체인 동영상 강좌(블록체인 001 - 005) 듣고 정리하기.
- 그 외 슬랙의 자료 참고하여 개념 익히기.
질문할 것
- ResponseEntity 를 쓰는 이유.
- API를 보면.. Integer.valueOf(String)는 String이 Integer.parseInt(String)한거랑 똑같이 해석됩니다. 그러나, valueOf(String)은 new Integer()으로 객체를 반환하고 parseInt(String)은 int 기본 자료형을 반환합니다.
Integer.valueOf(int)로 어떤 효율적인 코드를 작성하고 싶으시다면 아래같이 눈에 거슬리는 코드를 짜야됩니다. Integer k = Integer.valueOf(Integer.parseInt(“123”))
결론적으로 문자열을 변환할때 기본 자료형이아닌 객체로 받아오고 싶을때는 valueOf(String)을 쓰시면 되고. 그게 아닐경우는 parseInt(String)을 쓰시면 됩니다.
출처: http://javacpro.tistory.com/5 [버물리의 IT공부]
-
BigDecimal : 이건 왜 이걸로 받을까요?? –> public BigDecimal getAmountPossible(Map paramMap);
- 방금 테이블에 insert한 pk를 다른테이블에서 사용할시, mybatis에서는 ~~ 이런식으로 사용한다.
-
id가 autoincrement인 pk일 경우, insert된 행의 id값을 가져오게 된다.
-
- 보안등급 체크하는 부분 (이메일 인증, 휴대폰 본인 인증)
- 보유하고 있는 금액에 대한 데이터 tran과정 (pub, sub로 이해하기)
- redis 를 통해 publish데이터가 요청 (웹소켓) - node쪽
- 웹소켓은 마켓이 있을때마다 발생해야함.?
- tick은 실시간으로 써주는 데이터(redis를 통해 들어오는 데이터). job
- Map 사용, 왜 이렇게 받는 걸까? :
- context.xml같이 디비 설정 파일은 따로 있는건지? : templates 폴더의 properties파일들.
- target폴더는 뭐하는 용도인지?(pom.xml이 따로 또 있음.) : 중요하면서도 중요하지 않게 다루어도 되는 폴더입니다.
Maven 으로 빌드하면 생기는 jar 파일을 저장하는 것이 주용도. 커밋시 제외되어야할 폴더.
산출물과 소스코드를 대조 :
기본적인 돌고있는 DI구조 :
CRUD흐름과 빈도 높은 클래스 구조 :
뷰단에서 쓰고있는 스크립트 라이브러리 : vue,
yaml
- XML, C, 파이썬, 펄, RFC2822에서 정의된 e-mail 양식에서 개념을 얻어 만들어진 ‘사람이 쉽게 읽을 수 있는’ 데이터 직렬화 양식이라고 합니다. (WIKI 참고)
이 양식은 JSON에 포함되며 계층적인 설정 데이터를 정의하는데 매우 편리한 문법을 가지고 있습니다.
출처: http://kingbbode.tistory.com/10 [개발노트 - kingbbode]
https://www.google.com/recaptcha/api2/userverify?k=6LfOpkcUAAAAAG4JscMvBbFfTpRHbPaUJQcE4WYE
Request Method: POST
소스분석 참고 글…(by 오픈튜토리얼즈)
써니의 오픈소스 분석 가이드 (참고만 하세요~)
한동안 접고 살던 Spring framework오픈 소스를 다시 꺼내 분석한다면 나는 어떻게 할까? 일단 생각해보고 정리를 하자니…
장강의 뒷물의 앞물을 밀어낸다고 - 이게 아닌가? 아무튼 생각이 유실될 우려가 있어 그냥 냅다 적어보기로 한다.
남의 소스를 분석한다는 것은 남의 생각 속을 여행하는 것에 비유할 수 있다. “여행”을 하려면 무엇이 필요한가?
아니, 길을 잃지 않기 위해서는 무엇이 필요한지 생각해보자. “GPS”과 “지도”가 필요할 것이다.
그리고, 내가 가야할 길은 아직 가보지 않은 길이기 때문에 욕심 부리지 않는 ‘자세’를 준비하자.
항해(navigation)를 시작하기 전에 준비물이 잘 갖추어 있는지 확인해 보자.
- GPS (Global Positioning System)
프로그래머에게 필요한 GPS는 당연히 실제 물리적인 장치가 아니다. 소스를 분석할 때, 내가 어떤 소스를 분석하고 있으며,
다음으로 어느 소스를 분석해야 하는지를 판단하는데 필요한 도구이다.
내가 생각하는 소스 분석에 필요한 GPS 도구들은 다음과 같다. 프로그래밍 언어론에 대한 기초 지식 혹은 프로그래밍 언어 문법에 대한
정확한 지식이다.
언어를 모르는 사람이 소스를 분석하겠는가 라고 반문하겠지만, 남의 소스를 분석하다 보면 평소에 모르던 키워드나 연산자 혹은 문법을
마주치는 법이 생기게 마련이다. 막다른 골목에 다다르는 것과 같은 현상이 벌어진다.
즉, 머리속이 하얗게 지워진다. 이전까지 분석한 게 다 머리 속에서 지워지고 만다. goto 명령어는 자바에도 있다. 안쓸거라고 생각지 마라.
다중 루프에서 고속으로 탈출하기 위해 사용되는 경우도 간혹 있다. final 이 클래스에 붙어 있을 때 그 의미를 파악하지 못하거나,
public 수식어가 없는 클래스의 의미를 모르면 오픈 소스 설계자의 진의를 절대 파악할 수 없다.
문법 공부할 때 뒷장은 건너뛴 사람은 분석하다가 오도가도 못하는 신세에 빠지는 경우가 많다.
언어의 문법을 일부만 알고 오픈 소스를 분석하는 것은 단어 몇개만 배우고,
사전도 없이 뉴욕 한복판에서 엠파이어 스테이트 빌딩을 찾는 것과 같다.
다음으로 상속과 합성에 대한 개념이다. 상속과 합성은 이정표에 해당한다.
객체지향이건 절차지향이건 간에 소프트웨어는 항상 ‘부품’들이 조립되는 방식으로 구축된다.
그런데, 상속과 합성의 개념을 제대로 모르면 위아래로 이동해야 하는지, 좌우로 움직이야 하는지 모르게 된다.
그리고 코드를 따라가다가 어떻게 되돌아 가야 하는지 모르게 된다. 미로에 빠지고 말 것이다.
그냥 상속만 익히면 된다고 생각지 말라. 인터페이스와 구현체 간의 관계 등을 모르면
지나쳐도 되는 코드와 코드들의 집합인 모듈 단위를 전혀 알아 볼 수 없게 된다.
코드는 단순히 작은 메소드들의 무수한 나열이 아니다.
작은 단위들이 모여 큰 단위를 이루고 작고 큰 구조를 표현하기 위해 인터페이스 상속과 패키지 개념들이 있는 것이다.
모르고 보면 아무리 보고 또 봐도 까만 건 코드, 하얀 건 배경일 뿐이다.
리팩토링은 몰라도 된다. TDD도 필요 없다. 다만, 디자인 패턴은 알아야 한다.
패턴을 이해하는 것은 운전 면허 시험을 배울 때, 교차로와 순환로 등 다양한 도로 형태를 배우는 것과 동일하다.
사람은 익숙한 지형이나 형태를 보면 깊이 생각할 필요도 없이 반사적으로 움직일 수 있다.
소스 분석도 이와 같다. 패턴을 모르면 그만큼 분석하는데 드는 시간이 기하급수적으로 늘어난다.
이클립스 혹은 IntelliJ 같은 IDE 사용 방법에도 능숙해야 한다.
탐색기를 이용해서 소스를 하나씩 열어보거나, notepad++ 로 수많은 소스를 열어 본다면? 노가다로 시간 낭비하지 말자.
상위 클래스, 하위 클래스, 참조 위치 등등 단축키만 알면 아무리 멀고 먼 위치도 워프(warp) 할 수 있는
순간이동 능력을 갖출 수 있게 된다. 다만, 앞서 말한 상속과 합성 개념이 머리에 박혀있지 않으면 금새 지나온 길을 잃어 버리게 된다.
API와 라이브러리에 대한 경험… 코드를 따라가다 보면 자칫 너무 깊이 파서 땅속으로 파고 들 수 있다.
궁금하다고 클릭하다 보면 어느새 JDK 소스를 보고 있다는 사실 조차 모르게 된다.
럴리 없다고 생각지 말라. JDK를 설치하면 소스도 따라온다.
IDE에 decompiler를 설치해두면 클릭 한 번에 지하세계로 떨어진다.
라이브러리도 마찬가지인데, 자칫 내가 프레임워크를 분석하고 있는 건지 라이브러리 코드를 분석하고 있는 건지 혼란에 빠지게 된다.
더 심하면, 프레임워크가 의존하고 있는 라이브러리와 프레임워크를 구분하지 못하는 일체의 경지에 빠지게 된다.
- 지도 (map)
무턱대고 서울 간다고 지도도 없이 나서면, 어느 산골 구석이나 경찰서 유치장에서 발견될 수도 있다.
오픈소스를 막무가내로 이해하려는 개발자라면, 소프트웨어에 대한 환멸을 느끼고 IT 업계를 영영 떠날 수도 있다.
가급적 분석하고자 하는 오픈소스에 대한 설계에 대해 많은 정보를 제공하는 책을 구해야 한다.
오픈소스를 창작자가 서술한 책이면, 창시자의 철학을 옅볼 수 있기 때문에 가장 좋고, 없다면 가장 두꺼운 책을 사야 한다.
두꺼울수록 다루는 부분이 많기 때문에 분석하면서 낯선 코드를 만나는 경험이 줄어든다.
책을 통해 큰 흐름과 전체 얼개를 파악하면 많은 시간을 절약할 수 있다.
책을 사기 싫다면 해당 오픈 소스의 홈페이지의 introduction, user’s guide,
그리고 각종 reference 문서를 최대한 많이 읽어두면 좋다.
책도 안사고, 홈페이지에도 안 가 봤다면 분석을 포기해라. 당신이 수재 이상의 머리를 가지고 있지 않다면…
샹 폴리옹인가? 그럼, 구글 가라.
영어가 싫다면 해당 오픈 소스에 대해 언급된 국내 블로거들의 글을 최대한 검색해서 많이 읽어라.
그 어떤 책이나 블로그 글도 오픈 소스 전체를 설명할 수는 없지만, 부분에 대한 이해만 해도 길을 찾는데 큰 도움이 될 것이다.
그리고, 사전에 해당 오픈 소스에서 많이 쓰이는 클래스/ 메소드 명칭에 익숙해지면 좀 더 소스가 자연스럽게 읽힌다.
인간의 두뇌는 익숙한 것일수록 해석 속도가 매우 빨라지기 때문이다.
마지막으로 종이와 연필을 준비해라. 소스를 분석하면서 눈에 띄는 소스 파일 명칭과 메소드 명칭들을 적고,
클래스 다이어그램과 시퀀스 다이어그램을 그려본다. 직접 지도를 만들라는 것이다.
종이에 적으라는 이유는 우선 컴퓨터 화면에는 소스만 띄워놓아야 집중이 잘되고 덜 산만하다는 것이고,
사람 머리는 손으로 무언갈 쓰거나 할 때 논리회로가 잘 돌아간다.
참고로 Robert C Martin 선생님이 말씀하시길 UML을 그리는데 있어서 가장 좋은 도구는 종이와 연필이라고 했다.
내가 선호하는 오픈 소스 분석 방법은 디버거(debugger) 혹은 로그 분석을 해보는 것이다.
어플리케이션을 디버그 모드로 실행하면서 stack trace을 추적해보거나,
분석하고자 하는 위치에 break point를 걸어둔 후에 정지 시키고 나서 해당 위치가 실행되기 이전과 이후를 분석한다.
때로는 일부러 예외를 발생시킨후에 로그를 분석하기도 한다.
대다수의 오픈 소스는 debug, trace 로그 출력을 제어할 수 있기 때문에 상당히 긴 로그를 분석할 각오가 되어 있다면,
로그 출력 수준을 높이고 (TRACE 레벨) 프로그램을 실행시켜 보는 것도 한 방법이다.
당연히 log4j 혹은 logback 환경 설정을 선행하는 것은 필수 작업이다.
