웹 브라우저 사용기

브라우저 확장 오류 좋았던 점 아쉬운 점 총점
Microsoft Edge 적다. 30개도 안됨. 북마크 동기화. (양쪽에서 지우고 생성하고 했을 때, 새로 임포트해도 추가한 북마크를 막 지움. 심지어 다 지우고 다시 동기화 시도해도 계속 추가하는 북마크를 지워버리는 오동작을 보임.) 성능. 아주 빠르다. 은근히 잘 안되는 웹 사이트가 별로 없음. 부가 기능이 부족. 북마크 오류도 xMarks 확장만 있었어도 해결 됐을텐데…그리고 북마크 탐색과 북마크 추가가 크롬이나 파폭과 다르게 동작해서 불편했다. 88점
Google Chrome 많음. 확장과 앱이 대 다수 잘 동작함. 별로 못 느낌. 무난하다. 백그라운드 기능들이 많아질 수록 무겁다.최대화 상태가 아닐 때, 탭이 컴팩트하게 처리되는 테마나 확장이 없음. (울트라 와이드 모니터를 쓰는 나로썬 꽤나 중요했던 요소.) 95점
Mozilla Firefox 크롬보단 적지만 충분한 수준. 확장은 있지만 앱 기능이 없음. uBlockOrigin이 일부 네이버 웹 페이지들에서 오동작함. (해당 플러그인 문제) 부가 기능들이 있을 건 다 있는 편. 테마가 탭 모양과 사이즈까지 변경 가능해서 선택의 폭이 넓었다. 속도. (멀티 프로세스 활성화 시키니 해결) 95점
Vivaldi 크롬꺼 사용. 확장은 대다수 사용 가능, 앱은 잘 동작하지만 종종 오류가 있으며, (주로 oauth 연동 부분에서 콜백을 못받아가는 버그) 동기화 기능이 동작할 것 처럼 붙어 있어 오류로 보임.크롬 앱이 실행까진 되지만, 바로가기 동작 부분에 버그가 있음. 화면 분할 기능. 컬러풀한 반응형 UI.탭 위치까지 결정 할 수 있는 선택권 동기화 기능의 부재. 자잘한 오류가 아직 많은 편. (북마크 드래그 드랍이 고쳐졌다가 1.9버전에서 재발 함.)사이드 바가 있긴한데… 기능 수가 많지 않으며 동기화가 미동작해서 적극 사용하기 애매. 80점
Naver Whale 자체 스토어는 나온 지 얼마 안되서 10개 정도 밖에 안됨.크롬 앱은 아예 막아 둠. 크롬 확장도 네이버에 있는 기능과 겹치는 확장들은 막음. 별로 없었음. 웨일 스페이스. 사이드바를 통한 네이버 기반 서비스 이용시의 편의 기능 다수 제공. 브라우저가 이쁨. 크롬 확장과 앱을 선별적으로 막아둬서, 내가 원하는 스타일로 브라우저를 사용하지 못하게 됐다. 90점
Opera 많다고 보긴 어려워도 있을 건 다 있다. 의외로 별로 없음. 강력한 사이드바 기능. 의외로 만족도가 높았음. 다만 크롬처럼 컴팩트 탭을 못찾았음. 85점
Opera Neon 없다. 별로 없었음. 이쁘다. 글씨 큼지막하고 신선한 UI 디자인들.사이드바 편의 기능. (사이드바가 있다 뿐 기능은 별로 없긴함)탭이 오른쪽에 있다. 부가 기능이 없음. 아예. 60점

저는 결론적으로 Firefox를 쓰게 됐는데요, 크롬이 최대화가 아닐때도 Compact Tab이 지원됐다면 크롬 썼을겁니다.

지극히 개인적인 기준으로 작성했음을 알려드리며, 버그나 오류도 제가 겪은것 기준으로 2017-05-13 기준 최신 버전에서 확인한 내용입니다.

Ruby vs Python

루비와 파이썬. 2000년대 초반을 후끈 달군 스크립트 언어계의 아이돌인 두 언어.

의외로 두 언어를 다 하는 사람은 별로 없다.

포지션이 비슷해서인걸까?

몇년전 재밌는 블로그 글을 본적이 있다.

루비와 파이썬에서 함수 호출과 함수 참조에 대한 차이

Django VS Rails

PHP vs Python vs Ruby

펼친 글과, 글 말미에 퍼포먼스 이야기가 나오는데, 현재는 상황에 따라 다른 수준으로 따라 잡혀서 큰 의미가 없다. (Python 3.6, Ruby 2.4 기준)

https://benchmarksgame.alioth.debian.org/u64q/ruby.html

내가 직접 측정해본바로는 대다수의 간단한 로직 수행시에 Ruby가 더 빨랐지만, 의미가 있는 수준은 아니었으니 넘어가자.

절대적이라던 패키지 수도 Ruby와 큰 차이가 없다. (Pypi와 비교시에는 Rubygems가 더 많다. 물론 두 언어 모두 node.js 패키지 수와는 큰 격차가 나지만…)

http://www.modulecounts.com/

module count

실제 웹 서버로 게임 서버를 구현해본 결과 유효 패키지 수는 더 적고 아쉬웠다. Python3.x로 개발해서 그런거라고 하지만, 3.x로 넘어오신 분들도 많아진 이때에 그런 얘기는 핑계에 가까웠다고 느껴졌다.

내가 사용해본바로는 indent 강제에 대한 차이, 메소드 네이밍 룰, 용법의 차이 정도라는 결론이다.

언어의 표현력이 생산성과 발상에 영향을 꽤나 크게 준다.

하지만 그에 못지 않게 언어 사용자들의 문화도 언어 선택에 영향을 준다.

클래스에 메소드 확장이 좋은 사례다. https://blog.hongminhee.org/2012/06/30/26202408156/

클래스를 확장하여 메서드를 추가하거나 기존 메서드의 행동을 원하는 형태로 변경하는 것은 좋은 것이다. 적은 변경으로 원하는 목표에 도달하게 해준다.
하지만 그러한 확장이 원하지 않는 범위에서도 적용되어 예기치 못한 부수 효과를 내는 것은 안 좋은 것이다.

Ruby나 JavaScript는 전자의 장점을 취하기 위해 후자의 단점을 감수하는 것이다.
Python은 전자의 장점을 취하고 싶었으나 후자의 단점이 걸려서 문화적으로 쓰지 않는 방향을 제시했다.
Java는 후자의 단점을 막기 위해 전자의 장점을 포기한 것이다.
C#은 전자의 장점을 취하면서 후자의 단점을 제거한 것이다.

자신이 선호하는 성향이 문화로 정착된 언어를 선택하는 것도 꽤나 의미가 깊다. 특히 오픈소스권 문화에서는 기존 코드를 수정하거나 분석해야 하는일이 조금 더 비일비재하다.

이때 자신의 철학과 일치한 언어를 사용하는 것이 여러모로 효율이 더 좋아짐은 당연하다.

또 다른 측면에서 언어를 사용하면서 느끼는 감상이 달랐다.

비슷하면서도 두 언어를 선호하는 이유가 이 부분에서도 갈린다.

두 언어 다 사용해본 입장에서 아래 아티클의 주장에 공감한다.

http://smores.tistory.com/61

ruby: 인간 친화적이냐?
python: 간결함이냐?

나는 두 언어 모두 가볍게라도 접해보길 권한다.

의외로 두 언어의 차이를 체감할때마다 재밌다는 생각도 들었고, 그 과정에서 깨닳은 것도 많았기 때문이다.

스크립트 언어 이야기

나는 프로그래밍을 C언어로 시작했다.

C언어는 정적언어다. 메모리를 다루기 위해 변수의 타입과 크기가 아주 아주 중요한 언어다.

심지어는 C99이전 C언어에서는 (C++을 비롯한 뒤를 잇는 대다수 C 계열언어는 그렇지 않지만) 사용할 변수는 모두 상위에 선언해야 한다.

즉, 계획하에 선언되지 않은 변수는 낭비로 여겨지는 문화권에서 개발을 시작했다는 점이다.

임시 변수도 스택 변수인지, 힙에 할당한 것인지가 중요하게 여겨질 만큼, 변수를 세심하게 다뤘어야 함을 의미한다.

이를 세심하게 다루는데에 실패한다면 크래시나 메모리 부족등의 현상을 겪게 됨은 물론이었다.

동적 타입 기반의 스크립트 언어의 다수는 변수 선언에 자유롭다. 선언 용법 자체가 없는 언어들도 여럿 있다.

언어의 규칙이 코드 작성시에 영향을 크게 준다.

평소 신경 써오던 부분을 신경써야되거나, 신경쓰지 않아도 되는 상황이 되는데, 스크립트 언어 사용 초기엔 이 부분에서 괴리감이 들었다.


나의 경우에는 스크립트 언어로 주로 서버 머신 제어 및 모니터링, 로컬 머신 업무 지원 유틸리티용으로 JScript 와 Batch Script로 스크립팅을 시작했다.

동적 타입언어를 처음 사용하게 된 게 JScript 였다고 볼 수 있는데, 철저히 계획하에 그리고 정적 타입언어의 엄격한 규칙과 컴파일러의 감시하에 해오던 코딩이, 수많은 런타임 오류 환경에 놓여졌을 때의 막막함…

가장 막막했던 것은, 늘어난 런타임 오류였다.

과연 스크립트 언어가 생산성이 좋다는 것은 누가한 얘긴가…!!

궁시렁 거리며, 작업을 하다보니 자연스레 조금 더 계획하에 프로그램을 작성하게 됐다.

어라? 이게 스크립트 언어의 장점인가???

당시 고민에 빠졌지만, 돌이켜 생각해보면 그건 아닌거 같다.

정적 타입 언어를 써도 계획하에 잘 짜는 것은 당연히 중요하다.


그렇다면 스크립트 언어의 장점은 무엇인가?

빌드 & 배포 자동화던, 배포만 자동화던 스크립트 언어도 마찬가지로 손이 간다.

그 과정에서 빌드는 아주 작은 과정에 불과하기 때문에 이것도 아주 큰 장벽은 아니었다. 빌드가 10분이 넘어가는 경우에는 이것도 단점이 되긴 했으나…대개 작은 프로그램으로 구성되는 유틸리티 프로그램이 빌드가 재앙의 원인이 될만큼 크진 않았다.

그게 아니라면 왜 나는 스크립트 언어를 배우고 사용하는가?

우선 나는 문자열을 다루기 쉽다는 점을 아주 높게 평가했다.

당시 내가 주로 다루던 C, C++의 문자열 다루기는 곡예사같은 수준이어야 했기 때문에 이 장점이 컸다.

물론 C#은 문자열 다루기가 아주 쉬운 편이지만… C++은 여전히 쉽지 않다

C++에서의 문자열 다루기도 std::string만 써도 조금 낫고, 유틸리티 함수를 만들어놓고 사용하면 그럭저럭 쓸 수 있을 정도가 되지만, 여타 언어에 비할바는 아니다.

스크립트들 다수는 perl을 비롯해 문자열 다루기가 아주 아주 유연하다. 위에 언급한 쉬운편인 C# 문자열 다루는게 불편해 보일 정도니 말 다했다.

문자열을 다루기 쉬워지면 자연스레 컨텐츠 코딩이 쉬워진다.

파일, 폴더 다루기를 비롯해 다른 프로그램과의 연동 등 다양한 작업이 문자열 기반이다.

이 작업이 쉽고 유연해지면 자연스레 작업시간이 줄어든다. 작은 기능을 구현하게 될 수록 오류도 줄어들기 마련이고.

실제 스크립트 언어의 주 역할이 연동 작업이나 간단한 기능이었던 것도, 스크립트 언어 자체가 복잡한 요구사항을 수행하기 보다는 간단한 기능을 개발하는 것에 좀 더 적합하다는 판단에서 였다고 생각한다.

메인 스트림 언어 하나를 알면, 다른 언어를 배우는 것은 일주일 내외라는 말은 쉽게 동의하기 어렵다.

내가 본 다수의 뛰어난 프로그래머들도 언어 적응에 시간이 꽤 들었고, 나역시 꽤나 많은 시간 사용해보고 나서야 해당 언어가 익숙해졌다는 표현을 할 수 있었다.

그렇기에 더더욱 다양한 언어를 써봐야 하는데, 그 계기가 나에겐 스크립트 언어에 대한 적응부터였던 거 같다.

JScript를 그럭저럭 서버 운용 및 유틸리티 스크립트 언어로써 사용할 수 있게되자, 그제서야 다른 언어들에 대한 거부감과 진입 장벽에 낮아진 느낌이다.

아직 스크립트 언어에 익숙해지지 못했다면, 혹은 스크립트 언어만 사용해봤다면 패러다임이 다른 언어를 접해보는 건 어떨까?

그 노력이 당장은 아닐지라도 몇년 후에는 꽤나 큰 차이를 가져다준다고 믿는다.

ElasticSearch

ElasticSearch

목적

  • 검색을 위해 색인을 만들고, 색인을 바탕으로 빠른 검색을 위한 어플리케이션.
    • 엘라스틱서치를 색인 기능이 추가된 NoSQL DBMS라고 생각하면 이해하기 쉬울 수도 있다.
  • 장점
    • 분산 시스템
      • 엘라스틱 서치는 여러 개의 노드로 구성되는 분산 시스템
      • 노드는 데이터를 색인하고 검색을 수행하는 단위 프로세스
      • 기존 노드에 새 노드를 실행하여 연결하는 것만으로 확장 가능
      • 데이터는 각 노드에 분산 저장
      • 복사본을 유지하여 각종 충돌로부터 노드 데이터 보호
      • DISCOVERY를 내장하여 별도의 분산 시스템 관리자 불필요
    • 높은 가용성 (HIGH AVAILABILITY)
      • 엘라스틱 서치는 하나 이상의 노드로 구성
      • 각 노드는 1개 이상의 데이터 원본과 복사본을 서로 다른 위치에 나누어 저장
      • 노드가 종료되거나 실행에 실패할 경우 다른 노드로 데이터 이동 항상 일정한 데이터 복사본의 개수를 유지하여 높은 가용성과 안정성 보장
    • 멀티 테넌시 (MULTY TENANCY)
      • 데이터는 여러 개로 분리된 인덱스들에 그룹으로 저장 (인덱스 = RDBMS의 데이터베이스에 대응)
      • 서로 다른 인덱스의 데이터를 하나의 질의로 검색하여 하나의 출력으로 도출 가능
  • 기본 개념과 용어
    • 인덱스/타입/문서(index/type/document)
      • 엘라스틱서치의 데이터 계층이다. MySQL로 치면 database/table/row에 대응하는 개념이다. REST API 에서 문서를 표현할 때는 /news/article/10000 과 같이 표현한다. 이 때 news가 인덱스, article이 타입, 10000이 문서다.
    • 필드(field)
      • 엘라스틱서치 문서는 JSON이다. JSON의 각 프로퍼티를 엘라스틱서치에서 필드라고 부른다. MySQL로 치면 column에 대응하는 개념이다.
    • 매핑(mapping)
      • 인덱스/타입/문서의 규칙을 정의한 것이다. 사용자가 마음대로 정의할 수 있다. MySQL로 치면 스키마다. NoSQL에도 스키마가 있냐고? 물론 있다.
    • 색인(index)
      • 엘라스틱서치가 문서를 검색할 수 있도록 색인 데이터를 만들어두는 과정을 말한다. 데이터 계층의 index와 동일한 단어인데 문맥에 따라 다르게 쓰이므로 주의
    • 색인(index)
      • 위의 index의 명사형. 명사형으로 쓰일 때는 색인 작업을 거쳐 만들어진 색인 데이터를 가리킨다. 엘라스틱서치가 다루는 실제 저장된 데이터라고 할 수 있다. index 한 단어가 3가지 의미로 쓰이는 셈이다. 한국어 교재에서는 문맥에 따라 인덱스(데이터 계층)와 색인(색인 과정, 색인 결과)이라는 두 개의 단어로 구분하고 있다.
    • 클러스터/노드(cluster/node)
      • 여러 대의 서버를 묶어서 구동하기 위해 사용되는 개념이다. 각 서버가 노드, 서버의 묶음이 클러스터.
    • 샤드/복사본(shard/replica)
      • 엘라스틱서치는 색인 데이터를 하나의 물리적 데이터 공간에만 저장하는 게 아니라, 여러 개의 저장공간에 나누거나 복사할 수 있다. RAID0, RAID1과 비슷한 개념이다. shard는 성능향상을 위해 데이터를 여러 물리적 공간에 나눠 저장하는 것이고, replica는 한 노드가 실패했을 때도 검색서비스 제공이 가능하도록 데이터를 여러 물리적 공간(그리고 노드)에 복제해 두는 것이다.
    • QueryDSL
      • JSON으로 표현되는 엘라스틱서치의 검색 문법이다.

소개

Plugin

LogStash

ASP.NET CORE 사용법

ASP.NET CORE

Database

xlsx

xUnit

json