Lanace 블로그

연산자간에는 우선순위라는것이 존재한다. 초등학교때 배웠던 +, -, *, / 에 우선순위가 *와 /가 먼저 연산되고 그 이후에 +와 -를 계산하듯 SQL문에 있는 AND와 OR에도 우선순위가 존재한다. 결론부터 말하자면 AND와 OR사이의 우선순위는 AND가 더 높다 . 큰 차이가 없을것같지만 다음 예시와 함께 보면 그 차이를 느낄 수 있을것이다. 위의 그림과 같이 A, B, C 집합이 있을때 (A and B) or C의 결과와 A and (B or C)의 결과를 살펴보도록 하자  (A and B) or C == A and (B or C) 우선 A and B의 결과는 A과 B의 교집합인 A  ∩ B = {4, 7} 이다 {4, 7}  ∪  C = {7} 인것을 확인할 수 있다. 다음으로 B or C는 B와 C의 합집합인 B  ∪  C = {1, 3, 4, 5, 6, 7}이다. 그리고 A and  {1, 3, 4, 5, 6, 7} = A  ∩   {1, 3, 4, 5, 6, 7} = {4, 7, 6} 인것을 확인할 수 있다. 따라서  (A and B) or C 와 A and (B or C)는 다르다. And와 Or 연산자를 사용할 때 이를 주의해서 사용해야한다. 원하지 않은 결과를 출력할수도있다.

한글문서 쓸일이 있어서 쓰는데 좋은 단축키를 배웠다. alt + Shift + n 을 하면 글자간의 간격이 줄어든다. alt + Shift + w 를 하면 글자간의 간격이 늘어난다. 글자간의 간격차이는 눈에 바로 안들어오기때문에 가끔 티안나게 사용하는것도 좋을것같다. 그리고 표의 높이를 맞출때 원하는 셀들을 선택하고 h를 누르면 높이가 일치된다! 개꿀...ㄷㄷ

ViewPager는 좌우 스와이프를 통해 화면을 넘길 수 있다. 하지만 상황에 따라서는 이 기능을 사용하지 않기를 원할수도 있는데 이때는 다음과 같이 하면 된다. 간단한 해결방법으로는 ViewPager의 SubClass를 생성한다. 그리고 그 Class안에 flag를 하나 둔다. 그리고 단 다음에 onTouchEvent와 onInterceptTouchEvent를 오버라이드 한다. 코드로 살펴보면 다음과 같다. 그런다음 레이아웃 파일에 있는 <ViewPager> 테그를 방금 새로 정의한 <com.package.CustomViewPager> 테그로 변경한다. 참고: http://www.shiftedup.com/2011/08/29/disabling-pagingswiping-on-android

프로젝트를 관리하기위해서 여러가지 방법을 사용하지만 그중에 가장 많이 보이는건 1.0.3 과 같이 숫자 3개를 . 을 이용해 구분하는 방법일것이다. 대표적으로 Node.js의 package.json 에 있는 version이다. 코드를 보면 {   "name": "project-name",   "version": "1.0.3",   "description": "project-description",   "repository": {     "type": "git",     "url": ""   }   ... } 과 같이 표현하고 있는것들을 확인할 수 있다. 또한 많은 오픈소스들이 이와같은 형태로 버전을 구분하고 있다. 가끔 어떤 프로젝트에선 버전업을 적당히 숫자3개중 골라서 올리기도 하지만 그렇게 해서는 버전이 올라간것을 보고 어떻게 변경됬는지 추축할 수 없다. 요즘에 프로젝트를 할때 이것저것 오픈소스를 많이 가져다가 사용하는데 그때마다 버전이 올라가면 의존성이 깨지는지 확인해야한다. 이게 글로만 보면 별거 아닌 문제처럼 보일지 모르겠지만 엄청 귀찮은 문제이다. 따라서 버전만 보고도 의존성이 깨질지 깨지지 않을건지, 어떤 부분이 개선되거나 추가됬는지 알 수 있어야한다. 이러한 문제점을 해결하기 위해서 버전을 3개로 나누고 각각 버전업이 될때 의미를 부여하였다. 일단 버전은 3개로 나뉘는데 다음과 같다. MAJOR  .   MINOR   .  PATCH   MAJOR버전은  기존  버전과 호환되지 않게 API가 수정되면 버전업한다. MINOR   버전은  기존  버전과  호환되면서 새로운 기능을 추가됬을 때 버전업한다. PATCH  버전은  기존  버전과 호환되면서 버그를 수정했을 때 버전...

API17 이후에서 layout_margin까지 쓰고 자동완성을 보면 left, right, top, bottom등이 나오는데 start와 end도 보인다. 각각을 적용해보면 marginStart는 left에, marginEnd는 right에 margin이 들어가는것을 확인해 볼 수 있다. 그렇다면 left와 Start의 차이점과 right와 End의 차이점은 무엇인가? 찾아보니 언어를 읽는 방식에 대한 차이인듯 하다. 한국어를 포함해서 대부분의 언어는 왼쪽에서 오른쪽으로 읽는다. 따라서 Start를 왼쪽에서, End을 오른쪽에서 한다. 하지만 오른족에서 왼쪽으로 읽는 언어( Arabic , Hebrew, etc )와 같은 경우엔 Start를 오른쪽에서, End를 왼쪽에서 한다. 자세한 내용은 https://developer.android.com/about/versions/android-4.2.html#RTL 에서 확인하면 좋을것같다.

주위사람들이 괜찮은 글이라면서 추천해준 포스팅이 있는데 몇가지 적용시키면 괜찮을것같은 내용이 있어서 남겨놓는다. 원본글은 https://item4.github.io/2016-11-01/How-to-Write-a-Git-Commit-Message/ 이다. git의 commit message가 왜 중요한지는 다들 알고있을꺼라 생각한다. 해당 링크에서는 commit message가 왜 중요한지를 요약해서 설명하니 한번쯤 읽어보고 공감해보는것도 좋을것같다.  본 내용에 들어가면 훌륭한 commit message를 작성하는 7가지 방법을 설명하는데 다음과 같다. 1. 제목과 본문을 빈 행으로 분리한다 2. 제목 행을 50자로 제한한다 3. 제목 행 첫 글자는 대문자로 쓴다 4. 제목 행 끝에 마침표를 넣지 않는다 5. 제목 행에 명령문을 사용한다 6. 본문을 72자 단위로 개행한다 7. 어떻게 보다는 무엇과 왜를 설명한다 우선 나는 git IDE를 사용한다. 주로 Sourcetree를 쓰고 요즘엔 gitkraken로 갈아타려고 한다. 그리고 대부분 그렇겠지만 github를 이용한다. 그럼 위의 7가지를 하나씩 살펴보자 1. 첫번째로 제목과 본문을 빈 행으로 분리한다.  링크에서는 여러가지 git 명령어를 통해 제목만 볼 수 있기때문이 가장 큰것같다. 내가 생각하는 제목과 본문을 나누는 이유는 github에 있는데, 아래의 이미지를 보면 제목만 나와있고 본문을 보려면 우측에 `...` 을 클릭해야 볼 수 있다.  이와같이 제목과 본문을 빈 행으로 구분해주면 github에서 쉽게 본문과 제목을 나눠서 볼 수 있기 때문에 나는 본문과 제목을 빈 행으로 분리시킨다. 사실 이런걸 의식해서 나누지는 않았었는데 sourcetree나 gitkraken을 사용하면 자동으로 적용되는 내용이다.  gitkr...

간단하게 설명하면 Git은 리눅스개발커뮤니티가 자체 도구를 만들었다. 전에 BitKeeper라는 상용 DVCS를 사용하고 있었는데 서로 갈등이 생겨서 개발하였다고 한다.  전에 사용하고 있던 BitKeeper를 기초로 다음과 같은 목표를 가지고 개발하였다. 빠른 속도 단순한 구조 비선형적인 개발 완벽한 분산 대형 프로젝트에서도 유용 지금도 위와 같은 목표를 가지고 개발이 이루어 지고 있다. Git은 다른 시스템과는 다른 차이점이 존재한다. 바로 데이터를 저장하는 방법인데 이를 자세하게 살펴본다.