혜벌쭉의 퍼블리싱

https://wp-rocket.me

https://nolboo.kim/blog/2013/10/06/github-for-beginner/

$('#ntc_next_btn').click(function(){

$('.ntc_bar .ntc_ul').stop().animate({

top: -15

},function(){

$('.ntc_bar .ntc_ul').css({

top: 0

}).find('li').first().appendTo('.ntc_bar .ntc_ul');

})

})

var auto = setInterval(function(){

$('#ntc_next_btn').trigger('click')

},3000);

/*//공지사항 자동넘기기*/

/*메인 공지사항 넘기기*/

$('.notice_ntc_li .ntc_span').click(function(){

autoSlideNews();

});

function autoSlideNews(){

$('.ntc_li .slide_group').stop().animate({

top: -30.67

},function(){

$('.ntc_li .slide_group').css({

top: 0

}).find('.ntc_p').first().appendTo('.ntc_li .slide_group');

});

}

/*메인 공지사항 넘기기*/

$('.ntc_li .ntc_span').click(function(){

var thisSlidegroup = $(this).next('.slide_group');

var slideHeight = $('.ntc_ul .ntc_li .ntc_p').outerHeight();

thisSlidegroup.stop().animate({

top: -slideHeight

},function(){

thisSlidegroup.css({top:0}).find('.ntc_p').first().appendTo(thisSlidegroup);

});

//alert(slideHeight);

//autoSlideNotice();

});

// $('.news_ntc_li .ntc_span').click(function(){

//

// autoSlideNews();

//

// });

function autoSlideNotice(){

$('.notice_ntc_li .slide_group').stop().animate({

top: -30.67

},function(){

$('.notice_ntc_li .slide_group').css({

top: 0

}).find('.ntc_p').first().appendTo('.notice_ntc_li .slide_group');

});

}

function autoSlideNews(){

$('.news_ntc_li .slide_group').stop().animate({

top: -30.67

},function(){

$('.news_ntc_li .slide_group').css({

top: 0

}).find('.ntc_p').first().appendTo('.news_ntc_li .slide_group');

});

}

http://cubic-bezier.com/#.27,1.16,.96,.98

동기와 비동기방식이란?

동기 synchronous : 동시에 일어나는 이란 뜻으로 요청과 결과가 동시에 일어남 (요청과 결과가 동시에 일어나야하기에 중간에 대기시간이 있움-느림)

-> 생활 속의 예로, 설거지-집안청소-빨래라는 3가지 할 일이 있다.

설거지가 끝나고 나면 집안청소를 하고, 집안청소를 끝나면 빨래를 함

각 업무의 예상소요시간을 1시간씩 잡아도 3가지를 다 하면 3시간이 지나있음.

가장 생각하기 쉬운 방법이지만, 할 일이 많아지면 점점 소요시간(누군가가 나를 기다리는 입장에선 대기시간)이 길어지는 단점이 있음.

[설계가 간단하고 매우 직관적 / 대기시간이 길어질 수 있는 단점 ]

동기방식으로 이메일 바로행하는 프로그램 

-> 만명에게 이메일 보내면 한명, 한명, 한명

비동기 Asynchronous : 동시에 일어나지 않는 뜻으로 요청부터 하고 결과는 동시에 일어나지 않는다는 뜻으로 보면 됌 

Non-blocking input/output

-> 동기식의 예를 들 때와 마찬가지로 설거지, 집안청소, 빨래라는 3가지 할 일이 있을 때

설거지하는 업체에 전화를 해서 설거지를 부탁하면서 끝나면 전화하라고 당부함

집안청소, 빨래까지 각 업체에도 같은 내용으로 통화를 함

3시간이 걸리지도 않은 채 3가지 일을 '시작'했다고 볼 수 있어서 일처리가 동기보다 상대적으로 빠른 편..

하지만 언제 끝날지는 알 수 없음.! 그래도, 동기보단 세가지 일이 병렬적으로 해결이 가능하다.

[맡겨야 하는 과정들이 조금 복잡하지만 / 결과가 주어지는 그 사이 시간 및 자원을 효율적으로 쓸 수 있음]

즉

=> 업무를 볼 때에도 한사람이 4가지 일을 첫번째 끝내놓고 두번째, 두번째 끝내놓고 세번째 해결하는 것보단

한사람이 4가지 일 중 첫번째를 남한테 맡겨서 스타트를 끊어놓고 두번째를 자기가 하고 있는게 일이 처리되는 효율성은 훨씬 높음

비동기방식으로 이메일 발행

-> 이메일 보내는 별도 시스템에게 만명에게 이메일 보내라는걸 하면!

우선 사용자에겐 사용자에게 전송을 완료했습니다. 메세지 보냄

(전송 시작됐다는 메세지 나오고 뒤에서 이메일을 보내는 중...)

* 우체국에 비유

 - 외부직원 : 싱글쓰레드

 - 손님 : 개별 유저

 - 동기 : 외부직원이 처리할 때까지 손님이 기다림

 - 비동기 : 순번을 예약해놓고, 자신의 차례가 되면 와서 처리, 기다리지 않음.

1. 싱글쓰레드 & 동기

 - 하나의 우체국에 한 명의 직원, 즉 손님1 이 짐을 처리할 때까지, 손님 2,3,4 는 기다려야합니다.

   손님1의 처리가 끝난 뒤, 손님2의 짐을 처리할 수 있습니다. 이게 싱글쓰레드 - 동기 처리입니다.

   따라서 손님 하나를 받는동안 나머지 손님들은 기다리기만 해야합니다. 

2. 멀티쓰레드 & 동기

 - 우체국을 손님수만큼 만든다. 손님이 1000명이라면 우체국을 1000명 만들고, 손님1의 짐은 우체국1이

   손님2의 짐은 우체국2가 처리한다고 한다.  손님들은 기다리지 않아도 되지만, 우체국이 쓸데없이 너무 

   많아지게 된다. 즉 성능이 안 좋아진다. 이 방식이 기존 웹서버의 처리방식이였습니다.

3. 싱글쓰레드 & 비동기

 - 우체국은 1개이나, 손님1이 예약을 하고 집에가서 기다리는 방식. 각 손님2, 3, 4... 들도 예약을 하고, 

   우체국은 각 손님들의 우편이 도착하면, 각 손님들에게 알려주고, 손님들은 기다리지 않고, 바로 자신의  

   짐을 처리할 수 있다. 기술적으로 이런 방식을 멀티플렉싱이라고 합니다.

4. 멀티쓰레드 & 비동기

 - 이 방식은 각 우체국을 손님 수만큼 늘리는 것이 아니라, 위의 싱글쓰레드-비동기 방식에서 처리하는 방식의

   우체국을 10개정도만 늘려서 우체국이 비동기로 처리하는 방식입니다. 기술적으로 상황에 따라 cpu갯수 * 1~4

   퍼포먼스가 가장 잘나옴.

참고하기 좋은 사이트들

① http://hamait.tistory.com/694 (동기와 비동기의 우체국 예)

② https://private.tistory.com/24 (동기와 비동기의 은행 예)

19.03.02 

이직 목적이 아니라도 내 레벨을 증명하기 위한 자료는 항상 구비되있어야한다,,,

사람일은 어떻게 될지 모르니깐 ㅎㅎㅎㅎ 공무원이 아닌 이상 안주해있을 수만은 없는 업계이기도 하고..

2019년의 목표는 프론트엔드 개발자로서 거듭나는게 가장 큰 커리어 목표당

그에 따라 해야할 일련의 과정들을 나열해보고자 한당

1. 포트폴리오 준비

  1) 설치형 CMS 그누보드/영카트/워드프레스 < 개인적으로 그누보드 영카트보단 워드프레스가 더,,, 욕심난단 말이지 이유는 

워드프레스 기반으로 디자인된 사이트들이 넘 예쁜 사례들을 많이 봐가지구 무의식적으로 배우고싶단 욕심이 생겼당)

  2) 회사에서 했던 퍼블리싱 자료들 정리해보고, 원본소스 있음 따로 백업해놓고 그게 곤란할 것 같으면 캡쳐라도 떠놓기)

  3) 새로 배우는 리액트로 진행하는 프로젝트들도 자신있게 실을 수 있도록 최선다해보깅

2. node.js / react.js / vue.js 노드와 프레임워크 학습

3. ES6 자바스크립트 학습

이것조차도 다 할 수 있을진 모르겠지만 무작정 겁먹고,, 안해보는건 쫌 아니니깐 해봐야지,,,

너무 무리하게 세운건지 적당하게 세운건지 모르겠지만 ㅋㅋㅋㅋㅋ 

그래도 이렇게 글로서 흔적이라도 남겼으니 행동으로 잘 실천해야겠다.

와 개힘들다 ㅎ

무슨 개발환경 세팅하는데만 이렇게 오래 걸리냐 ㅎㅎㅎㅎㅎㅎ..

우선 설치햇긴 햇는데 이게 맞는건지 모르겟넹 ㅎㅎㅎㅎㅎ

https://www.icelancer.com/2016/11/nvm-nodejs.html

https://gist.github.com/falsy/8aa42ae311a9adb50e2ca7d8702c9af1

아주아주 도움이 됏던 블로그들

출처는 https://velopert.com/3621

-글을 시작하기에 앞서, 본 포스팅은 정보성보단 기록용 성질이 강한 글임을 미리 알려드립니다....-

react 프레임워크를 학습하기 전, 거쳐야하는 단계 개발환경 세팅!

react.js는 자바스크립트 기반 프레임워크이기 때문에, node.js를 설치해줘야한당.

node.js는 ?? -> 나중에 적어야지

node.js를 설치하면서 npm이 자동으로 설치되긴 하는데,

react.js 개발환경을 세팅할 때는 좀 더 개선된 자바스크립트 기반 패키지 매니저 도구로 Yarn을 설치해야한다.

설치해보잣

https://yarnpkg.com/en/docs/install#mac-stable

를 들어가면 

이 화면이 뜬다 신기하게 자동으로 macOS로 설정이 됌 ㅎㅎ

version은 뭔지 모르겠으니 나중에 알아보는걸로 하고^^

우선 보니깐... 터미널에 무작정 brew install yarn을 입력하니깐

명령어가 안먹고 뭘 깔라고 나온다. 앱스토어에서 명령어 입력기 깔라고 자동으로 띄어주길래 깔아주고..

눈치상 homebrew package manager를 클릭해야할 것 같아서 클릭하고 들어가니

https://brew.sh/index_ko 사이트가 떴다.

터미널에 붙여넣기 하라 해서 말 잘들었음 ^^

붙여넣으니깐 패스워드 입력하라 해서 무슨 패스워드? 이러고 있었는데 내 맥북계정 패스워드였당.

입력하고 나니깐 설치가 됌

그러고나서 ~_~

brew install yarn

입력하면 설치된당!!

-끝-

필자는(?) 학원에서 6개월동안 html, css, jQuery를 배우고 수료한 뒤 운좋게 바로 취업한 케이스다.

학원 수료 전, 이왕 돈 주고 배운 기술 잘 써먹고 더 잘키워나가기 위해 공부를 더 할까도 생각 했지만 

학원 선생님도 혼자 애쓰지말구 실무에서 배울게 많으니 취업부터 하라는 입장을 취하셨고

마침 첫 면접을 본 회사에서도 혼자 독학하는 것보단 프로젝트를 쳐나가면서 배우는게 더 나을거라는 조언을 해주셨당.

그렇게 나는 퍼블리셔라는 타이틀을 달고 사회초년생의 스타트를 끊게 되었다.

일한지 고작 일년도 안됐지만 스타트업회사에서 퍼블리셔로 일해본 결과, 알게 모르게 배운 것들은 엄청나다.

하지 않았으면 몰랐을 것들을 더군다나! 스타트업 회사에서 알게 되니 그 효과가 배가 되더라.

사실상 내가 생각하는 퍼블리셔는 지속적으로 이 직군으로 유지하긴 힘들고, 돈도 그냥 저냥 버는 정도, 한마디로 무진장 애매하다.

취업자리도 겉으론 많아보이지만 사실상 메인 업무가 퍼블리셔의 역량을 뽐낼 수 없는 업무일 수도 있고

재수없으면 잡일까지 도맡아해야하는 곳도 있다고들 한다.

여기까지만 보면 뭐야 퍼블리셔 그럼 왜 한거야? 라고 물음표를 띄울 수도 있지만,,,

난 내 직업을 매우 사랑한다^_^ 충분히 발전가능성 있는 직업이니깐!

퍼블리셔는 애매하지만, 프론트엔드 개발자로서 점프업할 수 있고

더 나아가 백엔드 개발자, 풀스택 개발자까지 점프업할 수 있는 발판이 될 수 있단 점에서 참 매력있는 직업이다.

물론 점프업하는 과정이 꽤나 힘들겠지만 힘든 만큼 더 달콤한 성취감을 맛볼 수 있는 기회가 너무나도 많은 직업이니만큼

앞으로 실무에서 하는 것들이 내 역량에 좋은 영향을 끼칠만한 것들이여야 한다.

그러니 회사에서 공부하라고 권한 react.js, vue.js 프레임워크들을 학습하면서

프론트엔드 개발자로서의 역량을 다져나가봐야징 ㅎㅎㅎㅎㅎㅎㅎ

내년 이맘 때는 프론트엔드 개발자를 시작하게 된 이유라는 글을 올리고싶다. 빠이팅

https://webdir.tistory.com/428

1. Can I Use 를 사용하자 (front-end 개발자 분들은 Can I Use 방문 할때마다 애드센스 광고 한번씩 눌러주는 습관을 가져봅시다. 이 사이트를 구축해준 분들도 정말 고마운 분들이고, 지속적으로 업데이트 하는 수고를 하고 계십니다.)

http://caniuse.com/#search=indexDB

사용방법은 간단합니다. 사이트 상단의 검색창에 내가 사용하고 싶은 css 나 javascript 명을 넣으면, 어떤 브라우져에서 작동되는지, 작동되지 않는지를 알려줍니다.

indexDB 를 검색해보면,

IE8 에서 아예 작동을 하지 않고, 엣지 (Edge) 브라우저와 사파리 브라우저, 사파리 모바일 브라우져에서는 partial support (부분적인 작동) 이 됨을 알수 있습니다.

그리고 아래 하단에 상세적인 추가 정보도 얻을 수 있습니다. 내가 작성하려는 javascript 나 css 가 모든 브라우져에서 작동하는지 확실히 기억하지 못하겠으면 Can I Use 부터 확인하는 습관을 들이는게 좋습니다.

2. 버그리포트를 자주 참고하자

Github 에는 여러가지 버그관련 정보가 공유됩니다. 요즘 flexbox 를 많이 사용해서 stackoverflow 에도 flexbox 관련 질문이 많이 올라오는데, 아래 페이지는 flexbox 버그 리스트를 모아둔 것 입니다.

https://github.com/philipwalton/flexbugs

Estoque 님도 얼마전 티스토리 테마를 다시 만드시면서 flexbox 버그 때문에 IE 에서 문제를 일으켜 고생하셨다고 하셨는데, 코딩을 하기전, 어떤 버그들이 존재하는지 정확히 인식하고 있다면 쓸데 없는 시간낭비를 하지 않아도 됩니다.

4. 브라우져 트랜드를 간파하고 있자

내가 주로 개발용으로 사용하고 있는 브라우져가 현재 어떤 위치에 있고, 어떤 추세이고, 어떤 흐름인지 인식하고 있는 것 은 매우 중요하다고 생각합니다.

파폭을 개발용 브라우져로 쓰고 계신분들 중, 아직도 파폭에 가장많은 css3 와 html5 feature 들이 탑재되어 있는 줄 아시는 분들이 적지 않습니다.

마찬가지로 사파리를 개발용 브라우져로 쓰고 계신분들은, 사파리가 얼마나 뒤쳐진 브라우져인지 인식하지 못하는 분들이 계시더라구요.

각 브라우져들의 기능 평가도를 보면 현재 크롬과 오페라가 가장 높은 점수를 보여줍니다. 엣지 (Edge 혹은 IE13) 도 점수가 많이 올라온 상태 입니다. 오히려 파폭과 사파리가 점수가 높지않아, 사이트 개발시 가장 신경써서 확인해야 하는 브라우져가 되어버렸습니다.

5. 브라우져 대응순서

가장 점유율이 높은 브라우져 부터 확인하는게 좋습니다.

http://gs.statcounter.com/#browser_version_partially_combined-KR-monthly-201506-201606

한국의 경우 현재 크롬의 점유율이 가장 높고, 그 다음이 IE11 로 나타납니다.

그럼 크롬부터 확인하고 두번째로 IE11 을 확인하시면 되겠죠?

점유율이 0.5%도 안되는 사파리 브라우져는 사실 확인 안하셔도 됩니다.

한국에서 사파리 브라우져 사용자는 어짜피 작동안되는 사이트에 익숙해져 있기때문에 사이트가 작동안되면 자신들이 알아서 IE 나 크롬 같은 브라우져로 사이트를 재방문 합니다. 어짜피 결재도 안되요. 애플은 exe 가 작동 안하거든요. 그래서 애플 사용자들은 신경 안써도 됩니다. (ActiveX 를 없앤다고 했지 exe 를 안쓴다고는 안했다. ㅋㅋㅋ)

그렇기도 하고, 0.5% 점유율도 안나오는 브라우져는 원래 “무시해도 된다.” 는 불문율이 존재합니다.

IE 와 사파리의 다른 점

각 버전마다 따로 놉니다. 크롬이나 파폭, 오페라 처럼 항상 최신버전 하나만 사용되느게 아니라, IE8,9,10,11,12,13 이런식으로 여러버전이 존재합니다.

그래서 IE 하고 사파리는 모든 버전을 확인해줘야 합니다. 골때리죠? 네, 예네들이 좀 골때리는 브라우져들 입니다.

참고사항 : jQuery 는 1.X 까지만 IE8을 지원합니다. jQuery 2.X 부터는 IE8 지원이 되지 않습니다.
이제 ES6 시대인데 jQuery 를 버려야 겠어 라고 생각하시는 개발자 분들이 조금씩 보이는데, 아직은 시기상조 입니다.

https://kangax.github.io/compat-table/es6/

지원안되는 ES6 스크립트들이 아직 상당히 많습니다. 물론 자스 작성이 예전보다 상당히 간결해졌고 편해진게 사실입니다. 특히 IE9 이하 지원을 안해도 되면 매우 간결한 스크립팅이 가능합니다. 그런데, 정말 로딩속도/성능에 신경쓴다면, css3 를 적극 사용합시다. fadeIn 같은것도 jQuery 로 구현하나 바닐라 javascript 으로 구현하나, 속도면에서 css3 를 따라오지 못합니다.

el.classList.add(className)하고 css3 로 opacity 넣어주는게 그렇게 번거스럽나요? 귀차니즘에서 벗어나세요. 아무리 내 오너가/상사가 막장이고 미워도 인간적으로 이정도는 해줘야 하지 않을까요?

참고사항2: 크롬과 오페라는 동일한 브라우져라고 봐도 됩니다. 엔진뿐만 아니라 shell 까지 거의 동일합니다. 그럼에도 오페라를 확인하는 이유는 adblock 때문입니다. 오페라에는 기본적으로 adblock (광고 표시되지 않게 하는 기능) 이 장착되어 있습니다.

그래서 이 adblock 을 busting (깨는) 스트립트를 적용할때 내가 작성한/ctrl c+v 해온 adblock busting 스크립트가 제대로 작동하는지 확인할 때 매우 유용합니다.

권유사항: 하위버전 대응할때 대충하세요. 레이아웃만 안깨지면 그냥 넘어가세요. IE8/9 에서 border-radius 안먹는다고 PIE.htc 가져다 쓰지 마세요. 다른 polyfill 들도 그렇고, 이런 제품들은 사이트 로딩속도를 많이 느리게 만듭니다. 방문자에게 border-radius 로 돌린 레이아웃을 보여주는 것 보다, 빠르게 사이트를 접속할 수 있게 해주는게 더 큰 배려 입니다.

(IE8 같은 브라우져를 쓰는 방문자의 컴퓨터는 하드웨어 사양도 매우 낮다는/오래되었다는 뜻 입니다. 컴퓨터 성능에 따라 로딩속도 도 영향을 받습니다. 물론 낮은 컴퓨터 사양을 사용하는 방문자는 그만큼 구매능력도 낮다는 뜻이라서 돈이 되는 트래픽도 아닙니다. 그러니까 하위버전 브라우져 대응은 대충대충 하면 됩니다.)

출처: https://hackya.com/kr/%ED%81%AC%EB%A1%9C%EC%8A%A4-%EB%B8%8C%EB%9D%BC%EC%9A%B0%EC%A7%95-%EC%B4%9D%EC%A0%95%EB%A6%AC/\