# techstack

rosy137

프로그래밍 언어 |종류|타입|목적|언어특징|기타| |:---:|:---:|:---:|:---:|:------| |JAVA|정적|일반|객체지향,명령형|| |C#|정적|일반|객체지향, 명령형|'C++' + 'Visual Basic'Microsoft가 .NET 플랫폼을 위해 개발| |VB.NET|정적|일반|객체지향, 명령형|MicrosoftVisual Basic.NET비주얼 베이직의 진화 형태| |C++|정적|일반|순차적, 명령형|C언어에 객체지향의 개념을 더함| |Perl|동적|일반|순차적, 명령형|practical extraction and report language웹 서버 애플리케이션을 작성하는 언어| |COBOL|정적|일반|순차적, 명령형|common business oriented language사무처리용으로 만들어진 언어미국 국방부를 중심으로 결성된 언어1968년 미국 사무처리 언어의 표준| |SQL|동적|데이터 처리|선

rosy137

개발환경 구축 구현 도구 Eclipse, InteliJ, Visual Studio, ... 테스트 도구 xUnit, ... 형상관리 도구 Git, ... 빌드 도구 Maven, Gradle, ... 하드웨어 개발환경 서버 웹 서버 Apache 웹 서버, Google Web Server, ... 웹 애플리케이션 서버 Tomcat, Jeus, ... 데이터베이스 서버 MySql, Oracle, ... 파일 서버 대용량 HDD, SSD 등의 장치 클라이언트 클라이언트 프로그램 설치를 통해 사용자와 커뮤니케이션하는 프로그램 Visual Basic, C# 등으로 개발되어 사용 웹 브라우저 모바일 앱 모바일 웹 소프트웨어 개발환경 운영체제 Windows, Unix(max), Linux(androi

rosy137

JSON(Javascript Object Notation) 속성-값 쌍 또는 키-값 쌍 데이터 오브젝트를 전달하기 위해 텍스트를 사용하는 개방형 표준 포맷 AJAX에서 많이 사용됨 XML을 대체함 표현 자료형 숫자 문자열: "" 배열: 각 요소는 기본 자료형이거나 배열, 객체 [10, {"v":20}, [30, "가"]] 객체: 이름/값 쌍의 집합 {"가":1, "나":"이", "다":true} JSON 문법 이름/값 쌍 { 로 시작하고 } 로 끝 배열은 [ ] 도구 Parser: JSON tex 파일 해석하고 자바 오브젝트로 변환 Renderer: 자바를 text로 표현 Serializer: POJO와 JSON 표현으로 직렬화 (Plain Old Java Object) Mapper: POJO와 JSON을 매핑

rosy137

REST: REpresentational State Transfer 하나의 URI는 하나의 고유한 Resource를 대표하도록 설계 특정 URI(Uniform Resource Identifier)는 그에 상응하는 데이터를 의미 → 데이터에 대한 처리는 HTTP 방식(GET, POST, PUT, DELETE 등)과 같은 추가적인 정보를 통해서 결정 REST 서비스: 특정 URI를 통해서 사용자가 원하는 정보를 제공하는 방식 RESTful: RESTful API: REST 방식으로 제공되는 외부 연결 URI REST와 HTTP methods GET: 리소스 또는 리소스 컬렉션을 얻어옴 POST: 리소스 생성 PUT: 리소스 업데이트 DELETE: 리소스 삭제 @R

rosy137

Front-end HTML CSS Bootstrap JavaScript Back-end ▪︎ Java ▸ Spring 자바 플랫폼을 위한 오픈 소스 애플리케이션 프레임워크 ▸ Spring ↔︎ Oracle JDBC: Java Database Connectivity 🔗Oracle-Connection 자바에서 데이터베이스에 접속할 수 있도록 하는 자바 API MyBatis 개발자가 지정한 SQL, mapping 지원 persistence framework log4J Transaction ▸ Spring MVC 클라이언트의 요청이 Front Controller에게 전달 Front Controller는 해당 Controller에게 위임(delegate) Controller는 적절한 Service 객체를

jewoo

2023년 테크 스택 회사가 아닌 나만의 테크스택 입니다. 추후 변경의 여지가 있습니다. Svelte 사실상 리액트를 실무에서 쓰고 있음에도 이에 대해 굉장히 불만이 많은 상태였다. 리액트를 쓰기 위해 부수적인 라이브러리 설치와 이에 따른 설정과 Boilerplate 작성. JSX를 최적화 시켜주기 위해 나오는 새로운 버젼들의 사항들, 상태관리 라이브러리들 간에 다른 패턴들. 이게 너무 불편해서 리액트 템플릿을 만들었지만 뭔가 시원하게 뻥 뚤리는 느낌은 아니었다. 아니, 에이전시 시절에 제이쿼리로 라이브러리 갖다 쓸때도 이정도는 아니었는데 이게 맞냐? 점점 그냥 백엔드 == 스프링마냥 무지성 프론트 == 리액트화 되는거 같은 느낌이었다. 내가 이상한건가 팀원과 얘기해보니 나만 그런게 아니라 리액트에 대해 다들 어느정도 불만들이 있었다. 그러던 도중

codermoon

Thread Thread란 ? 프로세스 보다도 작은 최소 작업 실행 단위이다. 실생활에서의 예를 들면, 하나의 은행이 있다. 그리고 그 은행은 고객들을 응대하기 위해 지점을 각각 세운다. 그럼 그 지점은 프로세스이다. 그리고 그 지점안에 창구가 있다. 창구의 갯수는 각 지점마다 당연히 다르다. 이 때 이 창구 1개를 스레드라고 한다. 보통 은행은 지점에서 2개 이상의 창구를 사용하므로 멀티 스레드, 다중 스레드라고 프로그래밍 관점에서 볼 수 있다. JS와 Thread 일단, 자바스크립트는 싱글 스레드이다. 즉 지점에 창구가 하나 밖에 없다. 그럼 지점에 창구가 하나 밖에 없다는 뜻은 기껏 지점을 하나 세웠는데 창구가 하나 밖에 없어서 고객 1명밖에 응대를 못한다. 기업의 입장에서는 얼마나 쓸데 없으며, 고객들의 입장에서는 얼마나 속이 터지는 것일까, 마찬가지로 프로그래밍의 관점에서 보면 한 번에 하나의 작업밖에 수행을 못하는데 그럼 안 좋은 언어인가? 라는

codermoon

ORM vs Raw Query ORM (Object Relational Mapping) ORM은 사물을 추상화시켜 이해하려는 객체지향 프로그래밍적 사고방식과 DataModel을 정형화하여 관리하려는 관계형 데이터베이스 사이를 연결할 계층의 역할로 제시된 패러다임이다. ORM을 사용하기 전 백엔드 개발자가 DB에 접근하기 위해서는 SQL Query(Raw Query)를 직접 만들어서 보냈다. 흔히 말하는 'DB에 쿼리를 날렸다.' 라고 말하는 것이다. 이렇게 개발하게 된다면 백엔드 개발자는 SQL문법을 알고 있어야 한다. 개발 프로그래밍과 DB 쿼리코드가 서로 종속된다. 이러한 문제점들을 해결하기 위해 ORM이 등장하였고, ORM이 등장함으로서 SQL Query의 문법에서 비교적 자유로워졌고, 개발 코드와 DB를 아예 분리하면서 객체지향의 의도에 적합하게 되었다. ORM 사용의 장점과 단점 장점 프로그래밍의 생산성 향상 선

codermoon

CORS Cross-Origin Resource Sharing (교차 출처 자원 공유) 먼저, 이름의 의미부터 알아보자. 교차(Cross): 다른 곳에서 서로 엇갈린다. 출처(Origin): 시작점, 근원지, 어디에서 시작했는지, 자원(Resource): 프로그래밍, 컴퓨터 상에서의 서비스 가능 한 것 공유(Sharing): 서로 어떤 것인지 알리는 것 및 서로가 가능하게 하게 함 뜻을 잘 조합하여 간단명료하게 만들어보자. > 출처가 서로 다른 곳에서 시작된 자원들이 공유하는 것! 프로그래밍적으로 본다면 뜻을 알 수가 없다. 현실세계에서 비유하자면 출처가 서로 다른 곳에서 시작된 자원들이라고 하면 서로 다른 곳에서 만들어진 자원은 나무, 물, 금속, 광물등이 있다. 그리고 그것을 공유하는 것이라고 하면 광물을 사용하는 곳에서 물도 취급하게 하고, 나무를 사용하는 곳에 금속도 취급하게 하는 것이다. 그러면 프로그래밍적으로 과연 어떠한 상황일 때 `CORS

hipiction

하루 정도 숨을 돌리고 나니 곧장 마지막 프로젝트가 시작되었다. 다행히도 이전 프로젝트와 동일하게 팀이 구성되어 각자가 생각해본 보완점이나 희망사항에 대해 쉽게 공감할 수 있었고, 공유와 적용도 빨랐다. 마지막 프로젝트는 약 관리 애플리케이션인 '약올림'이다. 이 앱은 내가 먹고 있는, 가지고 있는 약의 현황을 등록하고 관리해준다. 시장에 나와있는 To do list나 메모 앱처럼 약을 기록하고 복용 주기 등을 설정하면 외출 전에 약을 챙겨가라거나, 약 먹을 시간이 되었을 때 알람이 울린다. 또 약을 촬영하면 해당 약의 이름을 비롯한 기본정보를 띄워준다. 팀원들이 모두 이미지처리에 관심이 있고 백엔드의 경우 사용해보고 싶은 스택도 겹쳐서 순조롭게 아이디어를 구체화할 수 있었다. 그래서 우리 팀은 첫 번째 프로젝트처럼 곧장 SR문서를 정리하기 보다는 1) 구현하고자 하는 앱의 기능과 특성을 정리하고 2) 그에 맞는 기술스택을 취사선택한 후에 3) 각자 일주일의 공부 시간을