HTML5에서의 시맨틱 웹과 시맨틱 태그(Semantic Web, Semantic tag)

시맨틱 웹이란?

구글에 검색했을때 위키백과에 나오는 내용을 그대로 적어보면 아래와 같다.

시맨틱 웹(Semantic Web)은 '의미론적인 웹'이라는 뜻으로,

현재의 인터넷과 같은 분산환경에서 리소스에 대한 정보와 자원 사이의 관계의미 정보를 기계가 처리할 수 있는 온톨로지 형태로 표현하고,

이를 컴퓨터가 처리하도록 하는 프레임워크이자 기술이다.

웹의 창시자인 팀 버너스리가 1998년 제안했고 현재 W3C에 의해 표준화 작업이 진행 중이다.

쉽게 생각하면 첫 줄만 읽으면 된다.

의미론적인 웹은 말 그대로 컴퓨터가 웹사이트를 단순한 코드의 구성이 아닌 의미를 가진 사이트라는걸 알 수 있게 만드는 것이다.

시맨틱 웹의 이상향은, 인터넷에 방대한 양의 데이터를 컴퓨터가 자동으로 해석해 사용자가 원하는 결과값을 정확히 주는 것이다.

여기까지 읽었을 땐 단순히 검색엔진 성능 향상에만 유용하게 쓰일 것 같지만, 찾아보니 암 치료 증진에도 기여할 수 있고, 석유가스 산업에도 응용될 수 있으며, 이외에도 많은 기업에서 사용할 수도 있다고 한다.(어떻게 이런 결과가 도출된건지는 잘모르겠다ㅋㅋ)

크게 생각 했을때 데이터들을 관리하고 통합하는 것이기 때문에 위와 같은 기대를 하는 것 같다.

HTML5에서의 시맨틱 웹

HTML5 이전까지는 시맨틱 태그라는 것이 없었다.

그 때의 대부분의 태그는 <div>로 감싸져 있었을텐데,

개발자의 입장에서는 코드로 사이트 전체 구조를 한눈에 파악하기 힘들었을 것이고, 검색 엔진은 사이트의 의미를 정확히 파악하지 못해 검색 결과값의 정확도가 떨어졌을 것이다.

그래서 나온 대안이 시맨틱 웹이고, 그에 따라서 HTML5에서 시맨틱 태그(Semantic tag)라는 것이 나온 것이다.

예를 들어 설명하면

기존에는 <div class="header">헤더입니다</div> 이렇게 썼던걸,

<header>헤더입니다</header> 이런식으로 쓰는 것이다.

<div>태그, <header>태그 둘 다 구역을 나눌 때 쓰는 껍데기 태그인데 둘의 차이는 의미를 가지고 있는지의 차이이다.

태그 이름 그대로 헤더부분을 <header>태그로 감싸는 것이다.

위와같이 div를 대체할 수 있는 태그로 header, nav, article, section, aside, footer가 나왔고, 각각 의미에 맞게 사용하면 된다.

위 태그들은 HTML5 이전에 div태그에서 클래스 명으로 많이 쓰던 것들을 토대로 만들었다고 한다.

결론

안써도 겉으로 보이기엔 똑같지만 검색 엔진 최적화(SEO)에서 중요한 역할을 하기 때문에 검색결과에서 상단을 차지하고 싶다면, 쓰는것을 습관화 하는 것이 좋다.

끝!

2/159

React??

앞으로 쓰게될 React.js에 대해 아주 늦게 첫 발을 디뎠다

새로운 스택을 익히려 하는데 아무리 글을봐도 이해가 안되는 나의 머리를 탓하며 아주 쉽게 정리해보려 함

혹시라도 이 글을 보시게 된다면, 틀린부분이 있을 수 있으니 한번쯤 의심하면서 보시고

틀린부분은 바로바로 지적해주시면 감사하겠습니다

정리하는 글이기에 반말로 적겠습니다.

리액트란?

페이스북에서 만든 사용자 인터페이스 라이브러리

절대적으로 View단을 구성하기 위한 라이브러리이다.

리액트를 만든 이유?

기존 MVC패턴은 확장이 어렵고 거대한 시스템에 어울리지 않는다는 생각을 하게된 페이스북은 새로운 대안으로 Flux라는 데이터 흐름이 단방향인 시스템 아키텍쳐를 만들었다.

이 Flux는 “새로운 패턴이 아니라 MVC의 새로운 이름일 뿐이다” 라는 논란도 일었지만,

둘의 가장 큰 차이는 데이터 흐름이 단방향이라 더욱 직관적이고, 관리하기가 쉽다는 점이다.

리액트의 특징

1.JSX

템플릿을 사용하지 않고 고유의 XML확장 문법인 JSX를 사용한다.

쉽게 이해해 자바스크립트에서 HTML코드를 쓸 수 있게하는 문법이다.

이렇게 작성한 코드는 Babel을 통해 별도의 컴파일 없이 사용 가능하다.

2.Virtual DOM

기존에 DOM을 직접 핸들링하는 제이쿼리는 페이지를 새로고침하면 페이지의 모든 요소를 새로 렌더링하는 반면에,

리액트는 Virtual DOM(가상돔)을 사용해 변화가 있는 부분을 비교해 최소한의 요소만 다시 렌더링하게되어,

보다 빠른 속도로 화면을 보여줄 수 있다.

3.One Way Data Flow

데이터는 위에서 아래로만 흐르기 때문에 구조가 커졌을 때 양방향 바인딩에 비해 데이터의 흐름을 파악하기가 쉽다.

4.Server Side Rendering

클라이언트에서만 렌더링을 하면 HTML, JavaScript, Data, View 순으로 진행하는 시간 소요로 초기구동 속도가 느리고,

자바스크립트를 실행못하는 검색 엔진 봇들은 처음 렌더링 된 빈 HTML만 수집하기 때문에 콘텐츠가 없다고 판단되어 SEO에 취약하므로, 서버 렌더링을 지원한다.

Ruby on Rails에 템플릿 넣기

멋사 하프톤을 하면서 전반적으로 템플릿 삽입에 어려움을 느껴 포스팅 해야겠다 생각함
코드 github 주소
파일 minify하기

가독성이 떨어질 수 있으니 각오하고 볼것!

목표

레일즈는 MVC패턴의 고유한 프로젝트 구조를 가지고 있어 템플릿을 넣을 때 까다로운 부분이 많아 가이드라인을 제시하려 함.

레일즈 빈 프로젝트에 부트스트랩 기반 SPA 템플릿인 GraySclae을 넣어보는 것을 해볼 것!

준비

큰 상관은 없겠지만, Ruby는 2.4.0, Rails는 5.0.3 버전, 루비마인으로 진행

보통 템플릿은 라이브러리 사용시 cdn 대신 vendor 폴더에 다운받아서 경로를 참조하는 식으로 하기 때문에 그대로 적용할 예정

과정

1. 레일즈 프로젝트 생성 및 세팅
   
   
   routes에 index.html을 root로 설정
   
   
   protect 해제
   

   
   

2. 컨트롤러, 뷰 생성
   rails g controller home index로 home컨트롤러에 index페이지를 만들었고, 여기에 템플릿을 적용할 예정
   
   

3. 템플릿의 head부분 옮기기
   템플릿의 head부분을 그대로 복사해 layout > application.html에 붙인다.
   레일즈는 에셋 파이프라인을 이용하기 때문에 우선은 각종 라이브러리(여기서는 bootstrap, font-awesome) 링크를 지우고, stylesheet,javascript link_tag의 data-turbolinks-track을 지우고 자바스크립트를 불러오는 <%= javascript_include_tag 'application' %>는 body태그의 끝으로 보내준다. 끝으로 필요없는 코드를 지우고 정리하면 다음과 같다.
   
   템플릿의 head
   
   
   rails application.html
   

4. 템플릿의 body부분 옮기기
   템플릿의 body부분을 그대로 복사해 index.html에 붙이는데 이때 보면 가장 하단에 script부분이 있는데 이는 모두 지워 application.html의 <%= yield %>의 밑으로 보내준다. 여기서도 마찬가지로 각종 라이브러리 스크립트 태그는 지워준다.
   body태그를 보면 id가 부여되어있는데 이는 페이지 스크롤링에 사용되는 것이다. 지금 만드는 페이지는 싱글페이지이기 때문에 application.html의 body에 id를 적어주면 정상 작동한다.
   
   4번 이후의 application.html
   

5. CSS, JavaScript, img 옮기기
   CSS는 less,sass로도 주어지는데 본인이 쓸줄 안다면 가져와도 되지만, 가장 일반적으로 퓨어 CSS를 쓰기 때문에 grayscale.css을 assets/stylesheets로 가져온다. 이때 이 파일을 수정해야 하기 때문에 min파일과 같이 가져오게 된다면, 수정 후에 둘의 내용이 달라 제대로 효과가 적용되지 않을 수 있다.(중요함!!)
   마찬가지로 grayscale.js도 assets/javascripts에, 이미지파일 3개도 assets/images에 넣어준다.

6. vendor 옮기기
   vendor란? 누군가 만들어 놓은, 예를들면 부트스트랩, 제이쿼리같은 라이브러리파일을 담는곳이고, 위에서 CSS,JS,img를 넣은 assets폴더는 커스텀파일을 담는곳이다.
   vendor폴더에 우리가 필요한(head에서 삭제한) 파일들을 가져온다. 이는 우리가 수정할 필요가 없기 때문에 min파일을 가져오든 둘다가져오든 상관없다.(min이란 minify의 약자로 파일의 공백을 제거해 압축하는것)
   vendor > assets > javascripts에 bootstrap.min.js, jquery.min.js를 넣고, vendor > assets > stylesheets에 bootstrap.min.css를 넣는다. font-awesome은 폰트까지 가져와야해서 그냥 cdn을 썼음(ㅎ) / 4번 이후의 사진 참조

7. asset pipeline 설정
   커스텀파일을 넣은 assets폴더는 application.js와 application.css의 require_tree,require_self라고 입력되어 있는 코드를 통해 알아서 에셋폴더의 파일들을 불러올 수 있지만, vendor폴더는 따로 적어줘야 한다.
   vendor에 들어간 라이브러리 파일명을 각각 js와 css에 맞게 적어준다.
   이때 제이쿼리가 먼저 호출되어야 부트스트랩이 작동하기 때문에 순서에 유의해야 한다.
   
   assets > application.js
   
   
   assets > application.css

   

   
   

8. img url 설정
   grayscale.css에서 cmd + f로 url이라는 단어를 검색해보면 백그라운드 이미지 url이 절대경로로 되어있다. 이때 파일명만 남겨두고 나머지를 지워주면, 레일즈는 알아서 assets/images에서 파일명을 검색해 불러오게 된다.
   
   
   끝! 포스팅이 지저분하긴 하지만 끝까지 참고 만든다면 거뜬하게 완료 / 안된다면 댓글 달아주세요

Github 간편 사용 설명서

목차

1. 새로운 repository 생성
2. 1번 이후 변경 사항이 있을 때
3. branch, merge 사용법
4. 충돌 시 해결 방법
5. 풀리퀘스트 보내기

1. 새로운 repository 생성

Github 페이지에서 새로운 repository 생성 후에 로컬에서 작업한 내용을 올리기 위한 명령어 순서

명령어 입력 순서

1. git init
2. git add .
3. git commit -m “commit message”
4. git remote add origin repostory주소
5. git push -u origin master

1번으로 현재 작업중인 폴더에서 git을 사용할 수 있도록 해주고

2번으로 폴더 내의 모든 파일(.이 모든 파일을 의미)을 git의 staging area에 추가

3번으로 커밋과 동시에 -m으로 커밋 메세지 작성

4번으로 원격 저장소, 즉 github repository 주소를 origin 이라는 이름으로 등록

5번으로 origin이라는 원격 저장소에 master 브랜치에 푸시, 이때 -u를 쓴다면 다음번 부터 git push만 입력해도 origin의 master로 푸시가 된다.

2. 1번 이후에 새로운 변경 사항이 있을 때

1번 과정 이후에 변경 사항이 있어 push를 하고 싶을 때 순서

명령어 입력 순서

1. git add .
2. git commit -m “commit message”
3. git push

과정은 1번과 같으나 init과 원격 저장소 등록을 할 필요가 없다

3. branch, merge 사용법

협업을 할 때 많이 쓰는 기능 branch, merge 이름 그대로 가지를 치고, 합치는 방법이다

명령어 입력 순서

1. git branch 브랜치이름설정
2. git checkout 브랜치이름
3. git add .
4. git commit -m “commit message”
5. git push origin 브랜치이름

1번으로 새로운 브랜치를 생성(기존 브랜치는 master)

2번으로 생성한 브랜치로 이동

3번으로 모든 파일 추가

4번으로 커밋, 메세지 작성

5번으로 origin 저장소의 새로운 브랜치에 푸시

브랜치에 푸시까지 완료 한 뒤

1. git checkout master
2. git merge 브랜치이름

위의 과정으로 master에 새로운 브랜치를 merge할 수 있다

4. 충돌 시 해결 방법

pull이나 push를 했을 때 원격저장소의 내용과 로컬폴더내의 내용중 같은 라인에 다른 내용이 있다면 충돌 발생

터미널 로그에 충돌이 난 파일이 표시되니 직접 수정 후 다시 pull이나 push를 실행

가장 좋은 방법은 협업자들끼리 역할을 완전히 분담해 애초에 같은 코드를 건드리지 않는 것이지만, 어쩔 수 없이 그렇게 된다면 항상 작업 전에 pull을 습관화하면 충돌을 최소한으로 줄일 수 있을 것!

5. 풀 리퀘스트 보내기

오픈소스를 만들 때 가장 많이 쓰는 방법

내가 push한 내용을 repository의 마스터 권한을 가진 사람에게 pull 해달라고 요청하는것

우선 참여하고 싶은 repository에 들어가 오른쪽 상단의 fork로 나의 repository에 복사해옴

명령어 입력 순서

1. git clone 원본repository주소
2. git remote add 나의repo이름설정 나의repo주소
3. git remote -v
4. git pull origin
5. git checkout -b 브랜치이름(이슈)설정 origin/master
6. git push 나의repo이름 브랜치이름

1번으로 원본 repo의 코드들을 나의 로컬환경에 클론해온다.

2번으로 포크해온 나의 repo주소를 새로운 이름으로 추가해준다.

3번으로 현재 등록되어있는 원격저장소가 어떤게 있나 확인해본다. 아마 origin이라는 이름의 원본 repo주소와 새로 설정한 이름의 나의repo주소가 있을 것이다

4번으로 혹시 모를 코드변화가 있을 수 있으니 한번 pull해서 확인해준다

5번으로 원본repo에 이슈명이나 키워드로 브랜치를 생성하고 이동한다

모든 작업 후에 6번으로 나의 repo에 푸시한다

위의 과정 이후에 github에서 fork한 나의 repo에서 방금 푸시한 브랜치명을 선택 하면 옆에 Pull request 버튼이 생기고, 절차에 따라 누르면 풀리퀘스트가 진행된다.

여기서도 충돌이 발생할 수 있으니, 코드를 보며 적절히 수정해주면 된다.

마치며

멋사 강의 준비하면서 공부했는데 기초적인 방법은 익힌 것 같아 도움이 많이 되었다!