Kotlin의 Null Null가능성 nullabilityt는 NPE를 피할 수 있게 만들어짐 -> NPE를 컴파일 시점에서 잡아줄 수 있도록 하기 위함 타입뒤에 ? 을 붙여 널 가능성을 표시 fun strLen(s:String) = s.length -> strLen(null) 호출(컴파일 에러 발생하지 않음)-> 런타임 에러발생 fun strLen(s:String?) : Int = if( s!= null) s.length else 0 -> strLen(null) 호출 -> 컴파일 에러 ?타입 시스템에서는 null체크 이후에만 변수.메서드() 를 호출 할 수 있음 참고 코틀린의 런타임에서는 예를들어 String, String? 모두 같은 타입의 객체임 모든 검사는 컴파일 시점에서 수행된다 -> 런타임 시..
본 내용은 코틀린 인 액션을 읽고 저의 방식대로 정리한 글입니다. 그에따라 틀린 내용이 있을 수 있습니다. 틀린 내용이 있으면 댓글로 알려주시면 감사하겠습니다. 람다식의 문법 책에서 말하길 람다는 값처럼 여기저기 전달할 수 있는 동작의 모음이라고 설명한다. {x: Int, y:Int-> x+y} //파라미터 부분 //본문 값처럼 여기저기 전달할 수 있다는게 잘 이해가 안됐는데, 변수에도 저장할 수 있다는 예시를 보고 이해가 되었다. val sum = {x:Int, y:Int -> x+y} println(sum(1, 2)) //람다가 값이라는 증거 val getAge= {p:Person -> p.age} people.maxByOrNull(getAge) 또한 코틀린에서는 함수 호출시 마지막 인자(파라미터)가..
현재 들어간 회사에서는 코프링이 주 핵심 기술스택이기에 해당 기술스택을 배우고자 코틀린 인 액션 스터디를 진행한다. 아래의 내용은 코틀린 인 액션을 저의 방식으로 정리한 글입니다. 인터페이스 코틀린에서의 override는 자바와 달리 @Override annotaion을 사용하지 않음 인터페이스에 프로퍼티 선언이 가능하다. 자바와 동일하게 하나의 클래스에 대해서만 extends가 가능하며, 반대로 여러개의 인터페이스 가능 코틀린에서는 ":" 으로 상속, 인터페이스화 둘다 가능하다 kotlin에서의 default 메서드 구현은 자바와 좀 다르다 추가로 아래의 코드와 같이 두개의 같은 default method를 상속한다면, 반드시 override가 필수적이다 interface Clickable { fun ..
이전글에서 채팅데이터를 담기 위한 DB로 Mongodb를 사용할 계획이라고 말했지만 , 데브옵스 팀원분께서 다른 의견을 주셨다. 1. 그냥 기존에 사용하는 MYSQL을 사용하는건? 2. NoSql을 사용한다면 관리포인트가 더 늘어나는데 Mongodb랑 DynamoDb중 어떤게 관리포인트 측면에서 좋을까? 3. Redis같은걸 써서 batch transcation을 사용하는건? 4. Kafka는 이전 데이터를 삭제하지 않기 때문에 Kafka를 Db처럼 사용할 수 있나? 결국 내가 채팅 데이터를 DB에 저장하는 이유는 이전에 했던 채팅내역을 그대로 들고오기 위함이다. 해당 내용을 기반으로 글을 작성해볼까 한다. 기존 MYSQL을 사용한다면... 우선 NOSQL이 기존의 RDB보다 더 빠른 읽기 쓰기 성능을 ..
해당 프로젝트에서 채팅 구현을 맡고 있었다. 이전까지는 단지 STOMP프로토콜을 사용해 직접 client에게 메세지르 바로 보내는 것을 구현하였다. 하지만 해당 과정은 synchronize하기 때문에 다량의 트래픽이 몰린다면 문제가 발생될 수 있었다. 이것을 해결하기 위해서 pub/sub 구조인 Message queue를 도입하고자한다. Message queue의 후보지는 2가지가 있다. 1. Kafka 2. Redis 이 두개의 차이점을 비교하고 현재 나의 프로젝트에 맞는 Message Queue를 선택하고자 한다. 또한 DB도 문제이다. 현재는 MYSQL에다 채팅 데이터를 저장하고 있다. 항상 고민됐던게 MYSQL에 트랜잭션도 자주 발생하고 성능도 고려가 된다... 만약 채팅을 위한 DB를 구성하고 ..
이번에 현대자동차 소프티어 부트캠프가 끝났다. 이제 내가 어떠한 방향으로 나아가고 고쳐야할 부분이 있는지 정리하려고 한다. 1주차 1주차에서는 자바만을 사용해서 로또프로그램을 만드는 것을 하였다. 그룹별로 진행하였고 각 그룹 팀원끼리 해당 코드에 대해서 리뷰하는 시간을 가졌다. 또한 다른 그룹간 사람들끼리도 코드리뷰 하는 과정이 있었다. 이렇게 코드리뷰를 하는 과정이 너무 마음에 들었고 해당 과정이 나에게는 1순위로 인상깊었다. 하나의 코드에도 과연 이렇게 하는게 맞는지 이야기하는과정이 재밌었다. 2~4주차 2주차~4주차에서는 웹서버를 직접 구현하였다. 이전까지는 스프링,스프링부트만을 사용하여 웹서버를 구현하였고 해당 프레임워크를 쓰지 않고 웹서버를 직접 구현하였다. 해당 과정을 통해 얻은것이나 신기한것..
우리의 프로젝트는 세션을 통해 사용자 인증을 진행하고 있었고, 해당 값은 프론트에서 쿠키로 저장하고 있었다. 하지만 문제가 있었다 1. 로컬에서는 쿠키가 잘 저장 되었다. 2. 포스트맨에서도 쿠키가 잘 저장 되었다 하지만 백엔드 서버를 EC2에 올리고 프론트는 로컬에서 작업할때 쿠키가 저장되지 않았다. 그리고 해당 문제를 찾아보니 2가지가 있었다. 1. CORS 2. Cookie의 SameSite옵션 들어가기 전에 CORS가 뭔데? 이렇듯 우리가 겪는 모두 CORS 정책을 위반했기 때문에 발생하는 것이다. 사실 CORS라는 방어막이 존재하기 때문에 우리가 이 곳 저 곳에서 가져오는 리소스가 안전하다는 최소한의 보장을 받을 수 있는 것이다. CORS=교차 출처 리소스 공유 교차 출처 리소스 공유? - 다른..
이번 소프티어 부트캠프를 하면서 주유소 검색 기능을 추가해야 했었다 사용자가 입력하는 주유소 이름을 기반으로 18000개의 데이터를 full scan 해야 하는 상황.. 저희는 당연히 redis가 더 빠를것이라 생각해서 redis에 주유소 정보를 모두 저장하였다. 구조는 다음과 같다. 즉 12000개의 주유소의 PK가 Key값으로 저장되고 해당 key는 Object로 GasStation정보를 가지고 있다. Redis로 주유소를 검색하는 경우 요청 받은 이름이 포함되어 있는것은 List에 add 하여 요청이름이 포함되는 주유소 리스틀 보여주는 과정을 API 구축을 하였다. full scan 했을때 3분이 걸렸다.. ㅋㅋㅋㅋㅋ DB(MYSQL)로 주유소를 검색하는 경우 0.3초가 걸렸다.. 결론 왜 이럴까?..