cansto Programming

JAVA SE ; 자바 플랫폼, 스탠더드 에디션 자바 플랫폼 스탠더드 에디션 ( Java Platform, Standard Edition , 약자 Java SE)는  데스크톱  및  서버 , 최근의 고사양  임베디드 시스템 을 위한 표준  자바 플랫폼 으로 표준적인 컴퓨팅 환경을 지원하기 위한  자바 가상 머신  규격 및 API 집합을 포함한다. 따라서  자바 EE ,  자바 ME  등 다른 플랫폼은 구체적인 목적에 따라  자바 SE 를 기반으로 API를 추가하거나  자바 가상 머신  규격 및 API의 일부를 택해서 정의된다. JAVA EE ; 자바 플랫폼, 엔터프라이즈 에디션 자바 플랫폼, 엔터프라이즈 에디션 (Java Platform, Enterprise Edition;  Java EE )은  자바 를 이용한 서버측 개발을 위한 플랫폼이다. Java EE 플랫폼은 PC에서 동작하는 표준 플랫폼인  Java SE 에 부가하여,  웹 애플리케이션 서버 에서 동작하는 장애복구 및 분산 멀티티어를 제공하는 자바 소프트웨어의 기능을 추가한 서버를 위한 플랫폼이다. 이전에는  J2EE 라 불리었으나 버전 5.0 이후로  Java EE 로 개칭되었다. 이러한 Java EE 스펙에 따라 제품으로 구현한 것을  웹 애플리케이션 서버  또는  WAS 라 불린다. WAS(AS) 웹 어플리케이션 서버 웹 애플리케이션 서버 (Web Application Server, 약자  WAS )는 인터넷 상에서  HTTP 를 통해 사용자 컴퓨터나 장치에 애플리케이션을 수행해 주는  미들웨어 (소프트웨어 엔진)이다. 웹 애플리케이션 서버는 동적 서버 콘텐츠를 수행하는 것으로 일반적인 웹 서버와 구별이 되며, 주로 데이터베이스 서버와 같이 수행이...

예전에 정보처리산업기사 자격증을 준비한 적이 있다. 학교를 다니는 와중에 자격증 공부를 겸해야 해서 시간이 별로없었는데, A부터 D까지 출제 비율로 분류되어 있는 교재 덕분에 A, B만 보고도 시험을 합격했다. 이처럼 가장 빈도수가 높은 것부터 공부하고나서, 모르는 것을 추가로 알아가는 것이 효율적이다. Google 트렌드 에서 기간별, 지역별, 카테고리별 트렌드와 검색어 간 비교 분석이 가능하다. 어떤 명령어가 많이 사용되고 어떤 명령어가 덜 사용되는지 구글에서 검색해서 각각 명령어들이 얼마나 많은 결과가 있는지 알아봤다. 커밋이 8퍼셋트로 가장많고 add log diff init status 등 기초 명령어의 비율만 합해도 40퍼센트나 된다. 그런데 기본만으로는 부족할 때는 어떻게 해야할까? 해결 방법을 알아보자. 위는 일반적인 커밋과정( 수정 ▶ 추가 ▶ 커밋 )이다. 파일을 수정하고 커밋한 후 로그를 통해 커밋메시지를 확인했었다. 너무 귀찮다 간단하게 하고싶다 도와줄 사람~? 헬~프~~ 해보자 $ git commit --help //커밋메시지에 대한 도움말을 볼수있음 ※ 참고 $ git commit --help  명령어 실행 시 C:\Program Files\Git\mingw64\share\doc\git-doc 경로에 있는 git-commit.html 문서가 실행됩니다.  하지만 저 문서가 없거나 깨졌다면, 아래 주소로 접속하시면 됩니다.  (확인을 모두 해본것이 아니라서 문서가 같다고 확답드릴 수는 없습니다.) https://www.kernel.org/pub/software/scm/git/docs/git-commit.html 'git-commit(1) Manual Page' 페이지가 뜬다. cmd창에 바로 뜨는 경우도 있다. cmd의 경우 키보드 방...

자 그럼 이번시간에는  버전관리의 또다른 효용 두 번째인 과거로 돌아갈수있다는 점을 살펴보겠습니다 지금부터 살펴볼 명령은 ' 커밋을 취소하는 명령'인데 좀 어렵고  주의해서 사용하셔야 해요 그래서 이번에는 간단하게 이런게 있다정도만 짚고 넘어가려고 합니다.  $ git reset --hard "버전 id"  // 버전 id로 돌아가는 명령 $ git revert "버전 id" // 버전 id의 커밋을 취소한 내용을 새로운 버전으로 만드는 명령 깃의원리를 아신다음에 다시 이 내용을 보시면 덜 혼란스럽고  덜 위험할 거에요. 교양과목처럼 생각하고 읽어요~ 자, 현재의 로그를 취소해서 과거 돌아가고싶다 (예를 들면 현재 4인데 3으로돌아가고싶다) 크게 두가지 방법이 있습니다. reset VS revert 이 둘은 비슷하지만 달라서 섣불리하면 안돼요. git reset을 했을 때 그것이 3으로 돌아갈 까? 3도 지울까? 나중에 자주 헷갈리는 부분이니 미리 한번 생각해보세요. 4에해당하는 커밋들을 삭제하고 3을 최신상태로 하려고 reset명령을 사용해봅시다. 자 그럼 일단 3의 커밋주소를 카피하고 $ git reset (카피한)[커밋주소] --hard 엔터하면 헤드가 리셋한 주소에 있다고 나옵니다. git log 했을때 어떻게 되었나요? 4가 사라졌어요. 리셋할 때 입력한 커밋주소 이후의 커밋들이 사라지는 거에요 이렇게 커밋이 취소가되면서 동시에 우리는 버전3 커밋에 해당되는 소스코드상태로 돌아가게 되요. 추가로 깃에선 왠만하면 어떠한정보도 삭제하지 않아요. 제가 깃리셋해서 버전 1개를 버린것처럼 보이지만 실제론 버린게 아니라 남아있어요. 다만 우리눈에 보이지 않을 뿐이고 나중에 필요하면 복구할 수도 있어요. 그리고 복구는 깃의 원리를 이해하셔야 쉽게할 수 있어요. 주의사항이 있는데 나중에 원격저장소...

git commit 명령을 통해 버전을 생성했었다. 그렇다면 버전을 만들면 뭐가 좋은지 알아보자. 버전생성의 효용 1. 차이점과 과거시점의 내용을 알 수 있음 2. 과거로 돌아갈 수 있음 깃로그를 하면 지금까지의 로그(역사)가 보인다 깃로그만으로는 뭔가 아쉽다. 깃로그 뒤에 여러가지옵션을 줘서 동작을 바꿀 수 있다. 커밋은 각자 고유한 아이디(값,주소)가 있다 (커밋 주소,커밋 아이디=커밋메시지가 가리키는 버전의 고유한 주소) $ git log [커밋 아이디] // 커밋 아이디 이전의 메시지만 보여준다. (가독성을 위해 아래부분은 잘랐다.) $ git log -p // 각각 커밋(버전)사이에 소스 상의 차이점을 확인할 수 있다 버전 4와 3사이의 diff 부터 7줄이 차이점을 나타낸다. 아래의 +++은 버전4에서의 f1.txt파일을 가리키고 위의    - - -은 버전3에서의 f1.txt파일을 가리킨다 아래의 +초록은 버전4에서 f1.txt의 내용(소스)이고 위의    -빨강은 버전3에서 f1.txt의 내용(소스)이다. $ git diff [커밋 아이디1]..[커밋 아이디2] // 2와 1사이의 파일과 내용의 차이를 보여준다. $ git diff // (파일을 add하기 전에 미리) git add하기 전과 add한 후의 파일 내용을 비교 작업을 할 때 커밋을 하기 전에 작업 전후의 코드 차이를 확인해서 실수 한 것이 없나 확인가능 미리 수정해놓은 f2.txt 파일이 있다. 그 파일을 add 하면 staged 되어서 커밋가능한 상태로 바뀌기 때문에 diff명령을 입력해도 아무것도 출력되지 않는다.

우선 복습을 위해 커밋까지의 과정을 나열해보았다. 기억이 안난다면 다시 공부하도록 하자. 아 참고로, $ cp f1.txt f2.txt f1.txt를 f2.txt에 복사하는 명령이다.

작업한 내용을 버전으로 만들어서 저장하려한다 저장하면 이전으로 돌아갈수있고 파일의 변경사항의 이력을 볼수도있다 버전이 무엇인가 버전은 의미있는 변화를 뜻한다 버전은 어떤작업이 있으면 완결된 상태를 뜻한다 너무 이런거에 집착 ㄴㄴ 버전을 만들기 전에, 처음에 딱 한번 해야되는 일이 있는데 그건 바로 만들버전들이 누가만든것인지 알기위해 이름을 세팅해야한다 처음 git bash를 처음 켰다고 생각하고 진행하겠다.(이전의 내용 복습겸) $ pwd $ cd document $ ls -al $ git status git commit을 치면 빔이 실행된다 이런 화면이 뜨면, 맨 윗줄에 현재 버전의 메시지를 적으면된다 메시지란 이변화가 음.. 어떤변화를 담고잇는지? 이파일들이 왜변경되엇는지? 그 이유를 적는 것이 버전 메시지(커밋 메세지)다 입력할라면 i 알죠? f1파일이 새로운 버전이 되엇다는 뜻임->최초로 버전생성한거임 $ git log //현재 버전이 잘 만들어젓는지 확인 숫자1이라는 버전메시지가 들어잇는 버전이 생성된것을 볼수잇음 버전작성자와 그사람의 이메일, 날짜를 확인할 수 있다. 다시 버전을 만들어보자 한번더 모디파이드 빨간색 수정되엇다고 나온다 f1.txt라는 파일을 git add f1.txt해서 다시 버전관리에 add시켜야한다. 깃에서 어떤새로운파일 이 생겻을때 그파일에대한 버전관리를 깃에게 명령할때 그리고 버전관리가 되고있는 파일이 수정되고 버전을 생성할 때 둘다 애드해야함 즉, 최초로 추적할 때도 add, 파일이 수정되서 버전을 만들 때도 add git commit하면 커밋메시지를 작성할 수 있는 화면이뜨고 i누르고 2쓰고 esc누르고 :wq하고 엔터 하면 뭐라 나오는데 모르겟고 git log하면 방금 우리가 커밋할 때 작성한 커밋메시지 '2'가 있고, 밑에는 아까 커밋한 메시지 '1...

이전 포스팅에서 "우리가 프로젝트 폴더를 버전관리 하겠다" 라고 깃에게 알려줬습니다.  이제 파일을 생성해서 그 파일이 버전관리 되는 모습을 봐야겠죠. 그래서 저는 이제 아주 간단한 파일을 만든 후, 버전관리해보도록 하겠습니다. (여러분은 저 파일들이 굉장히 복잡하고 여러개의 파일을 지금 관리하고 있다고 상상해주세요.) 현재 디렉토리에 파일 하나를 생성할 때 'vim'이라는 에디터를 쓸겁니다. 이 에디터는 명령어 시스템에서 대부분 설치되어 있기 때문에 어디서나 쓸 수 있다는 장점이 있지만 사용하기 까다로워요 이제 'f1.txt' 라는 파일을 만들고 그 안에다가 숫자 '1' 을 써보겠습니다. $ vim f1.txt // 'vim' 이라는 프로그램으로 'f1.txt' 라는 파일을 편집(생성)하겠다 이런 화면이 뜹니다. 입력모드가 아니기 때문에 아무것도 입력되지 않아요. 알파벳 'i' // 입력할 수 있는 상태로 전환되며, 하단에 ' INSERT(끼워넣기) '라는 것이 뜹니다 souce : 1 입력 후 'esc' 버튼 을 누르면 이제 다시 입력 할 수 없는 상태 가 됩니다. :wq // 작성한 내용을 저장(w)하고 동시에 이 프로그램을 종료(q) ('w'는 write고 'q'는 뭐 quit 겠죠?) $ ls -al 명령으로 확인하면 'f1.txt' 파일이 생성되어있어요 그러면 이제 보시는 것처럼 'f1.txt' 파일에 'source : 1' 이라는 내용이 저장되 있는 것을 볼 수가 있는 것이죠. $ cat f1.txt // 파일 내용 보기 $ vim f1.txt /...

적당한 곳에 프로젝트 폴더를 만들어보자. 나는 document를 프로젝트폴더로 사용할 것이다 (프로젝트 폴더 : 자신이 하고있는 프로젝트에 사용될 파일들을 모아놓을 폴더) 디렉토리가 document로 변경된 것을 확인할 수 있다. $ pwd //path working directory :  현재 작업중인 디렉토리를 알려줌 $ cd //change directory :  작업할 디렉토리 변경 document 디렉토리의 파일 목록을 확인할 수 있다. 이전에 연습할 때 만들어놓은 'gitfth' 디렉토리가 있다. gittt 디렉토리를 생성한다. $ ls -al //  현재 디렉토리의 파일목록을 보여준다 . $ mkdir // make directory :  디렉토리 만들기 'gittt' 디렉토리가 생성된 것 확인 우리가 버전관리를 하려고 하는 디렉토리를 깃한테 알려줘야 한다 . 먼저, 프로젝트를 진행할 'gittt' 디렉토리로 변경한다. $ git // 사용할 수 있는 깃명령어의 리스트와 설명을 보여준다 깃명령어 중 git init 명령어를 통해 깃 저장소를 생성했다. $ git init //" 현재 디렉토리에서 작업 ( 버전관리 ) 을 시작 ( 진행 ) 하겠다 ." 라고  깃에게 알려주는 기능 //Initialized empty Git repository in C:/Users/user01/document/gittt/.git/ // 비어있는 깃 저장소를 ~ 에 만들었다 .( 초기화했다 ) '.git'  디렉토리가 생성된 것을 확인할 수 있다 . '.git...