반응형
반응형

 

📝Boolean OR절 축약

int areaCode = detail.get("areaCode").asInt();
boolean isAreaCodeValid = areaCode == 1 || areaCode == 2 || areaCode == 31;

 

반응형
반응형
public class SwitchExample {
    public static void main(String[] args) {
        int dayOfWeek = 3;

        String dayType = switch (dayOfWeek) {
            case 1, 2, 3, 4, 5 -> "Weekday";
            case 6, 7 -> "Weekend";
            default -> throw new IllegalArgumentException("Invalid day of the week: " + dayOfWeek);
        };

        System.out.println("Day type: " + dayType);
    }
}

Java17부터 →을 이용해 각각 break를 안 사용해도 되고 가독성을 높여주는 Syntactic Sugar이다

반응형
반응형

const cities = [
    {id: 1, name: "#전체"},
    {id: 2, name: "#서울"},
    {id: 3, name: "#경기"},
    {id: 4, name: "#인천"}
]

function Main() {

    const [selectedCity, setSelectedCity] = useState(cities[0].id);

    const selectCity = (cityId:number) => {
        setSelectedCity(cityId)
    }
    
    return <div>
        {cities.map((city) =>
        <button className={city.id === selectedCity ? "bg-blue-500 hover:bg-blue-700 text-white p-1 rounded-full mx-2" : "mx-2"}
                key={city.id}
                onClick={() => selectCity(city.id)}>
            {city.name}
        </button>)}
    </div>
}
반응형
반응형

📝Point To Point

보내는 사람이 큐를 통해서 메시지를 전달하면 받는 사람이 큐에서 하나씩 꺼내 읽는 방식으로 Point To Point는 서버끼리 연결한 1대1의 상태이다

 

📝메세징 시스템

메시지전송되는 정보의 블록이나 패킷을 의미한다 에를 들면 로그 데이터, 이벤트 메시지 등 API 로 호출할 때 보내는 데이터를 처리하는 시스템입니다

 

📝Kafka

기존 네트워크 방식Point To Point로 서버끼리 연결한 1대1의 상태인데 기능이 늘어나 서버가 늘어나고 각 서버끼리 연결이 많아질수록 복잡해지는 시스템을 가지고 있었다 이러한 네트워크에서는 문제점들이 아래와 같은 문제점들이 존재한다

 

  1. 통합 / 중앙화된 정송 영역이 없음연결이 갈수록 복잡하다
  2. 문제가 발생했을 때 여러 시스템을 확인해야 한다 → 디에서 장애가 일어났는지 문제 해결이 어려워진다
  3. 연결된 시스템 마다 제각기 다른 방법으로 구현 될 수 있다 → 복잡도 증가

이러한 문제점들을 해결하기 위해 카프카 개발팀에서는 다음과 같은 목표를 가지고 있었습니다

  1. 프로듀서와 컨슈머의 분리역할 분리
  2. 시스템 확장이 쉽게 만들기
  3. End To End이벤트 / 데이터 흐름을 중앙에서 관리하는 방식

 

그래서 카프카는 pub/sub 모델을 기반으로 만들어진 메세징 시스템이 됩니다

카프카를 설명하기 위한 용어들이 있습니다

  • Producer
    • 데이터를 생성하고 특정 토픽으로 전송하는 주체 → 메시지(요청 정보 + 데이터)를 카프카 시스템에 보내는 역할
  • Kafka System (Kafka Cluter)
    • 중앙 메시징 시스템으로 메시지를 읽어서 요청한 곳에 보내는 역할 → 주문 시스템에서 주문했을 때(Producer) 해당 처리 시스템(Consumer)으로 보내는 역할
  • Consumer
    • 특정 토픽에서 메시지를 소비하여 처리하는 역할 → 주문 시스템에서 주문 관련 정보를 DB에 넣은 후 다시 카프카로 전달
  • PARTITIONS
    • 파티션은 메세지를 저장하는 물리적인 파일사용자가 요청한 정보들을 의미 (N명이 요청하면 N개)
  • Topic
    • 토픽은 메시지를 관리하는 주체로서, 비슷한 종류의 데이터를 그룹화하는 역할여러개의 파티션을 가질 수 있다 → 카테고리라고 생각하면 된다 "주문 시스템 처리 서비스"가 토픽이 될 수 있다
  • Broker
    • 여러개의 토픽을 가지며 Kafka 그 자체라고 생각하면 된다
  • Zookeeper
    • 브로커 간의 조율과 클러스터의 메타데이터 관리를 위해 Apache Zookeeper를 사용

 

  • 동작 과정
    • 사용자 요청(Partitions)들이 들어오면 Producer로 전달하고 Kafka로 보낸 뒤 Topic에 맞게끔 큐에 쌓인다 그 뒤 역할에 맞게 Consumer로 보내 처리되는 형태이다

 

💗장점

  • 확장성 → 수평 확장이 가능하다
  • 래플리카래플리카로 노드 장애나 데이터 손실에 안정적 운영이 가능
  • pub/sub 구조 → 확장에 더 용이하다
  • 배울 수 있는 환경이 넓음 → 생태계가 구성 됨
  • 빠른 처리 → 카프카는 대량의 메시지를 빠르게 처리할 수 있으며  파티셔닝을 통해 데이터 분산 저장 처리해 높은 처리량

 

💗왜 빠른가?

  • DISK I/O 최적화 → 세그먼트단위로 저장하며 순차적인 디스크 I/O가능하게 한다 [디스크 읽을 떄 이리읽었다 저리읽었다 하지 않음]
  • 클러스터 구성 → 분산처리로 처리 능력 향상
  • 메시지 배치 처리  → 네트워크 및 디스크 I/O 비용 감소
  • Zero-Copy
  • 토픽 파티셔닝 →  토픽 파티션 병렬 처리 지원

 

⚠️단점

  • 시스템이 복잡하다
  • 러닝커브가 필요하다
  • 카프카는 대량의 데이터를 처리하고 저장하기 위해 상당한 자원이 필요 → 오버헤드가 발생할 수도 있음 (DISK I/O) 프로듀서 정보, 래플리카, 컨슈머에서 DISK Read 많은 DISK I/O 발생

 

 

📝pub/sub 모델

  • 중앙에 메시징 시스템 서버(카프카)를 두고 메시지를 보내고(publish), 받는(subscript) 형태의 통신이다
  • 구독을 신청한 수신자만 메시지를 전달받을 수 있다
  • 개체가 빠지거나 수신 불능이 되어도 메시징 시스템만 살아있으면 전달한 메시지유실될 가능성이 없다
  • N:M으로 연결되는 게 아니라 확정성에 용이

 

 

 

 

카프카 적용 예제

📝Haddop

하나의 성능 좋은 컴퓨터를 이용하여 데이터를 처리하는 대신 적당한 성능의 범용 컴퓨터 여러 대를 클러스터화하고 큰 크기의 데이터를 클러스터에서 병렬로 동시에 처리하여 분산처리 저장하는 대용량 처리에 특화된 솔루션입니다

 

📝Hive

데이터 웨어하우스 기능을 제공하는 데이터베이스 시스템으로 SQL과 유사한 Hive Query Language (HiveQL)을 사용하여 대용량 데이터 세트를 쿼리하고 분석할 수 있습니다 (Hadoop 사용시 분산 저장되어있기 때문에 그걸 통합시켜주는 시스템)

 

📝Hue

Hadoop 클러스터와 연동하여 사용자 친화적인 웹 인터페이스를 제공하는 오픈 소스 사용자 인터페이스 (UI) 플랫폼

 

 

🔗 참고 및 출처

https://velog.io/@seungyeon/%EC%B9%B4%ED%94%84%EC%B9%B4-%EB%AC%B4%EC%97%87%EC%9D%B4%EA%B3%A0-%EC%99%9C-%ED%95%84%EC%9A%94%ED%95%A0%EA%B9%8C

https://log-laboratory.tistory.com/144

https://www.google.com/search?q=kafka%20microservices%20architecture&tbm=isch&hl=en&sa=X&ved=0CCsQrNwCKABqFwoTCNifpJiRhIMDFQAAAAAdAAAAABB3&biw=1903&bih=931#imgrc=aOlkJWzaD1FuRM

https://victorydntmd.tistory.com/343

https://goneoneill.tistory.com/48

https://inpa.tistory.com/entry/NODE-%F0%9F%93%9A-Passport-%EB%AA%A8%EB%93%88-%EA%B7%B8%EB%A6%BC%EC%9C%BC%EB%A1%9C-%EC%B2%98%EB%A6%AC%EA%B3%BC%EC%A0%95-%F0%9F%92%AF-%EC%9D%B4%ED%95%B4%ED%95%98%EC%9E%90

https://choonsik-lab.tistory.com/entry/코드-스니핏-Code-Snippet-이란
https://kaki104.tistory.com/809

반응형
반응형

📝인코딩 체계

한국에서는 인코딩 체계는 크게 한글이 포함된 인코딩 코드표를 가지고 있냐 없냐로 나뉩니다 기본적으로 한글이 포함되면 영어 특수문자 등은 포함되기 때문에 신경 안 쓰셔도 됩니다

 

  • 한글이 포함된 인코딩
    • UTF-8
    • UTF-16
    • UTF-32
    • EUC-KR
    • CP949
    • KSC-5601
    • 등...

 

📝화면의 글자가 깨지는 이유

  • 해당 페이지의 인코딩 설정과 웹브라우저의 인코딩 설정이 다르기 때문에 일어납니다 간단히 이야기하자면 종이에 한국어가 적혀있는데 번역기가 영어로 번역해 보여주기 때문에 안 맞는 것입니다

 

JSP 예제

<%@ page language="java" contentType="text/html; charset=EUC-KR" pageEncoding="EUC-KR"%>

 

JSP에서 EUC-KR로 페이지 설정을 해놨는데 웹브라우저에서 다른 언어로 읽으면 깨질 수 밖에 없습니다

 

 

📝파라미터로 넘긴 글자가 깨지는 이유 (GET)

  • GET방식으로 요청시 글자가 깨져서 서버에 들어갔다면 위에 설명한 "화면의 글자가 깨지는 이유"가 있을 수 있습니다

 

간단한 예제를 한번 보시죠

<%@ page language="java" contentType="text/html; charset=EUC-KR"
	pageEncoding="EUC-KR"%>
<html>
<script>
var text = "가";
	
fetch("http://localhost:8080/reqServer?word=" + text, {
	  method: "GET",
	})
	.then(response => response.text()) // 응답을 텍스트로 변환
	.then(data => console.log(data)) // 응답 데이터 출력
	.catch(error => console.error(error)); // 오류 처리
</script>
<body>
	<h1>웹화면에 PDF 출력해보기</h1>
</body>
</html>

GET방식 통신을 이용해 word라는 키에 text를 담아서 보내고 있습니다 reqServer에서 로그를 찍었습니다. 웹브라우저의 인코딩 상태를 EUC-KR로 했을 때 결과"가" 입니다 KO18-U로 설정했을 때는 "╟║" 이상한 문자가 넘어갑니다. 자바스크립트에 적은 하드코딩 한글 때문에 그렇습니다 → 물론 input 박스로 받은 데이터는 잘 넘어갑니다

 

  • URI Encode 설정이 UTF-8이 아닌 경우

이 부분에 대해서는 WAS서버가 역할을 해주는 경우가 많습니다 예를 들면 톰캣이 있겠습니다 server.xml 설정에서 URIEncoding 설정을 UTF-8이 아닌 다른 인코딩 체계로 되어있는 경우 GET방식 통신때 깨져버립니다

 

<Connector connectionTimeout="20000" port="8080" protocol="HTTP/1.1" redirectPort="8443"/>

참고로 톰캣 9.0 부터는 기본적 Default가 UTF-8로 설정되어 있습니다

 

 

📝URLEncoding vs Encode

  • URLEncoding
    • GET방식으로 호출할 때 "키=값"으로 데이터를 전달할 때 값에 한글 및 #, $, %, = 등... 특수문자가 들어가는 경우 비정상적으로 동작(예약어 동작 등...)할 수 있기 때문에 URL 인코딩 과정이 필요하다
  • Encode
    • 데이터를 보내려면 해당 데이터를 이진데이터로 보내는데 UTF-8 체계를 따라 이진데이터로 만들지에 대한 설정을 합니다 간단히 이야기하면 데이터를 2글자씩 끊어서 보내는 것과 3글자씩 끊어서 보내는 느낌이다

 

📝POST 통신후 내려온 데이터가 깨진 경우

  • MIME-TYPE이 일치하지 않아서 발생한다 즉, HTTP 통신시 Header의 Content-Type 불일치로 일어나게 된다
  • Content-Type은 Request와 Response로 나뉘게 된다

 

아래는 POST 방식 통신에 대한 Request 예제입니다

fetch("http://localhost:8080/reqServer2", {
method: "POST",
headers: {
  "Content-Type": "application/json; charset=utf-8"
},
body: JSON.stringify(jsonData),
})
.then((response) => response.text())
.then((data) => console.log(data))
.catch((error) => console.error(error));

(application/json) json형식으로 읽어주세요 + (charset=utf=8)utf-8로 인코딩 되었으니 utf-8로 디코딩해서 읽어주세요

→ 이렇게 해야 백엔드(서버)에서 정상적으로 데이터를 받게 된다

 

 

아래는 POST 방식 통신에 대한 Response 예제입니다

 

 

Servlet 예제

@PostMapping(value = "reqServer")
public void server(@RequestBody HashMap<String, String> bodyVO, HttpServletResponse res) {

    /** 응답 헤더 설정**/
    res.setContentType("application/json; charset=EUC-KR");
    
    /** 응답 헤더 설정값으로 데이터를 화면에 그려준다**/
    PrintWriter out = res.getWriter();
    out.print(responseData);
}

Serlvet의 경우 이러한 형식으로 데이터를 반환해줍니다

 

 

Spring 예제

@PostMapping(value = "reqServer", produces = "application/json;charset=UTF-8", consumes = "application/json;charset=UTF-8")
@ResponseBody
public String server(@RequestBody HashMap<String, String> bodyVO){

  return bodyVO.get("word");
  
}

Spring의 경우 consumes랑 produces라는 옵션이 존재합니다 Request 와 Response의 Content-Type을 설정합니다

  • consumes
    • Request 에 대한 Content-Type 설정 제한합니다 → 어차피 Request Hedaer는 Client에서 하기 때문에 해당 Content-Type외에는 호출 못하게끔 서버에서 막습니다
  • produces
    • Response에 대한 Content-Type 설정을 해줍니다 이 부분에 따라 리턴에 대한 형태가 깨질지 안 깨질지가 결정됩니다

 

※ 웹브라우저 및 JSP인코딩 설정을 EUC-KR로하고 POST방식으로 EUC-KR로 데이터를 보낼 때 깨지는 경우가 있는데 내가 Input 박스 따위에 적은 값이 EUC-KR이 아니라 UTF-8이고 UTF-8이 EUC-KR로 인코딩되어 Request때 깨지는 경우도 있고 Response할 때도 EUC-KR로 내려준다고 선언했지만 실제로는 UTF-8이 EUC-KR로 인코딩 되어서 보내지기 때문에 깨져버리는 경우도 있다

 

 

📝결론

어떤 깨진 글자는 복구가 가능하지만 어떤 깨진 글자는 복구가 불가능합니다 예를 들면 移���이러한 글자는 아무리해도 복구가 불가능합니다 그렇기 때문에 주먹구구식 처리보다는 근본적인 원인을 파악하기 바랍니다

 

요즘은 거의 UTF-8을 기본적으로 두고 코딩하기 때문에 UTF-8로 맞춰준다는 생각을 하시면 됩니다 물론 프로젝트 특성이 EUC-KR이런 걸 쓰는 곳도 있겠죠

반응형
반응형

 

 

📝알뜰폰 Hub

https://www.mvnohub.kr/user/index.do

 

📝털린 내 정보 조회

https://kidc.eprivacy.go.kr/

 

털린 내 정보 찾기 서비스

알림판 재생 정지

kidc.eprivacy.go.kr

 

반응형
반응형

📝보일러 플레이트(Boiler Plate)

무엇인가를 시작하기 위해 반복적으로 작성해야 하는 표준적이고 일상적인 코드로 Getter Setter 등... 따위를 가르킵니다 이러한 걸 해결하기 위해 스프링에서는 어노테이션 따위를 쓰거나 프레임워크 자체에서 기능을 제공해줍니다

📝코드 제너레이션(Code Generation), 코드 젠(Code gen)

다양한 형태의 코드를 자동으로 생성하거나 생성하는 도구나 프로세스를 가리키며, 개발 작업을 자동화하고 생산성을 향상시키는 데 도움을 줍니다 → 보일러 플레이트 해결

📝TF팀 (Task Force Team)

어떤 과제를 성취하기 위해서 필요한 전문가로 구성된 기한이 정해진 임시조직입니다 간단히 이야기하면 프로젝트 기간내에 모인 팀입니다

📝PWA

PWA란 구글에서 만든 제품으로 프로그레시브 웹 앱(Progressive Web Apps)의 줄임말로 모바일 기기에서 네이티브 앱(Native App)과 같은 사용자 경험을 제공하는 웹 앱입니다

 

💗 장점

  • 사용자가 앱을 다운로드하거나, 업데이트할 필요 없이 웹 브라우저를 통해 앱을 바로 사용할 수 있습니다
  • PWA는 네이티브 앱과 마찬가지로 푸시 알림(Push Notification) 기능을 제공하고, 카메라, 마이크 등 모바일 기기 자체의 기능(네이티브 기능)도 사용할 수 있습니다
  • 스토어에 올라가는게 아니라 웹에서 직접 다운 받아 설치하는 거이기 때문에 앱 심사가 없기 때문에 빠른 운영 적용이 가능합니다

 

⚠️ 단점

  • 요즘은 잘 모르겠는데 이렇게 다운 받는 사람이 그렇게 많아 보이진 않아 보입니다 그 외에 직접 구현해서 배포해보지 않았기 때문에 자세한 이야기는 못하겠네요

🔗 참고 및 출처
https://koreafrom.tistory.com/467
https://yozm.wishket.com/magazine/detail/1969/

반응형
반응형

📝Git

리누스 토르발스가 개발했으며 산형 저장소로 소스를 관리(이력, 소스 Merge, 롤백 등...)해주어서 협업시 작업 후 올리기만 하면 알아서 합쳐지고 추후에는 배포하는 과정까지 같이 이용하게끔 할 수 있다

 

📝GitHub

마이크로소프트의 Git 플랫폼으로 웹에서 Git에서 명령어를 입력해야 볼 수 있는 이력, 관리에 프로젝트 협업 기능까지 넣은 플랫폼이다

 

 

📝Git Workflow

 

Git의 동작은 총 4가지로 이루어져있다

 

  1. Working Directory
    1. 작업할 파일이 있는 디렉토리 즉, 로컬에서 내가 하고 있는 현재 프로젝트
  2. Staging Area
    1. 커밋(commit)을 수행할 파일들이 올라가는 영역 [모든 변경사항을 관리하며 어떤 변경된 파일에 대해서 올릴지 정의]
  3. Local Repository
    1. 커밋된 파일들이 저장되어져 있는 공간 (로컬에서의 Git 관리)
  4. Remote Repository
    1. 커밋된 파일들을 로컬이 아닌 다른 서버에 올리는 공간 (원격에서의 Git 관리) [협업]

 

📝Git 용어

  • Branch
    • 나뭇가지라는 뜻으로 독립적으로 어떤 작업을 진행하기 위해 따로 분기시켜 작업 이력을 관리하는 것을 의미한다 예를 들면 Master에는 배포하는 완벽한 제품이기 때문에 완전한 기능이 나올때 Master에 올려야한다 그 외의 작업은 기능별로 Branch라는 걸 만들어서 작업한 후 Merge하게 된다
  • Merge Conflict
    • Merge한 Branch에서 같은 파일을 변경했을 때 충돌이 발생 예를 들면 A라는 사람이 10번라인 수정하고 B라는 15번라인 수정할 때 자동적으로 Merge가 되면 좋지만 그렇지 않을 경우 Git에서 충돌이나서 합칠 수 없다는 에러 사항이 발생하게 된다. 일반적으로 같은 파일을 동시 작업하지 않아야하며 작업할 경우 Commit주기 및 Push 주기를 짧게 가져가야한다
  • commit
    • 변경사항을 로컬에 저장
  • push
    • 변경사항을 원격 저장소에 저장 및 업로드
  • pull
    • 원격 저장소에서 변경된 내용을 로컬 저장소로 가져온다

 

 

📝Git 파일 종류

  • .git
    • 커밋과 브랜치 등 관리되는 파일의 정보들이 모두 .git 안에서 관리
  • gitignoire
    • 커밋하지 않을 파일에 대한 정의가 적혀있다

 

📝Git 변경 이력

  • origin
    • 원격 저장소를 의미
  • master
    • 로컬 저장소 마스터 브랜치
  • lalala
    • 로컬 저장소lalala이름의 브랜치
  • head
    • 현재 어떤 작업 공간에 있는지 알려준다
  • origin/master
    • 원격 저장소의 브랜치
  • origin/lalala
    • 원격 저장소lalala이름의 브랜치

 

📝Git 명령어

  • 커밋 이름 변경
    • git config --global user.name "Mona Lisa"
  • 커밋 이름 확인
    • git config --global user.name
  • 이력 보기
    • git log
    • git reflog
  • 변경된 파일 Staging Area로 보내기
    • git add
  • .git 파일에 staging 파일 저장 (커밋) [Local Repository]
    • git commit
  • commit 파일 중 변경 사항 비교
    • git diff

 

 

🔗 참고 및 출처

https://docs.github.com/ko/get-started/getting-started-with-git/setting-your-username-in-git
https://moondol-ai.tistory.com/m/106
https://tecoble.techcourse.co.kr/post/2021-07-08-dot-git/
https://velog.io/@m2nja201/Git-Hub-%EC%99%95-%EA%B8%B0%EB%B3%B8-%EC%82%AC%EC%9A%A9%EB%B2%95-1-%EC%82%AC%EC%A0%84-%EC%A7%80%EC%8B%9D%ED%8E%B8
https://velog.io/@augus-xury/github-%EC%82%AC%EC%9A%A9%EB%B2%95-%EA%B0%84%EB%8B%A8-%EC%A0%95%EB%A6%AC

반응형
반응형

📝Media Query

출력 장치의 여러 특징 가운데 일부를 참조하여 CSS 코드를 분기 처리해 하나의 HTML 소스로 여러가지 출력장치 크기에 따라 맞춤형으로 보여줄 수 있는 기능을 제공한다

 

  • mobile
    • 320px ~ 480px
  • tablet
    • 768px ~ 1024px
  • desktop
    • 1024px ~

 

@media (조건문) {실행문} 순서로 작성이 가능하다.

 

가장 많이 쓰이는 부분을 하나 정리해주자면 넓이에 따라 반응형을 많이 만들기 때문에 min-width, width, max-widht [뷰포트 기반]를 사용한다 참고로 아래 참고 및 출처 사이트에 상세히 작성되어있으니 참고하면 좋다

 

See the Pen gradient progress bar by Lee (@mondaymonday2) on CodePen.

 

 

 

🔗 참고 및 출처

https://naradesign.github.io/media-query.html

반응형