글쓰기 메뉴

Rails4, Elasticsearch
관계 모델 및 Method 인덱싱

searchkick 이나 tire(retire) 등을 사용하지 않고 elasticsearch-model 을 사용하는 경우 mapping 을 사용해 인덱스를 설정할 수 있다.


내 경우엔 다국어 사용을 위한 store 컬럼들과 관계모델의 컬럼들, 그리고 일부 메쏘드를 인덱스에 포함시켜야했다. - 아마 모두가 비슷하겠지.


간단하게 as_indexed_json 을 오버라이드하고 인덱스 재성성 ㄱㄱ


def as_indexed_json(options = {})
    as_json(
        only: [:title, :content, :brand_id],
        include: { 
            brand: { only: [:title, :address] },
            place: { methods: [:geostring] }
        },
        methods: [:published, :nickname] 
    )
end


해시와 배열이 뒤섞여 있어 좀 거지같아 보이지만 직접 해보면 이해가 쉽다.


다른 글들
1 1

Encoding
UndefinedConversionError

URL 에 한글 제목을 추가한 뒤로 페이스북 공유 시 500 Internal error 가 자꾸 발생하는거지. Facebook 디버거에서 해당 URL 복사해서 스크랩해보면 문제없이 긁어지고... 인코딩에러는 Ruby 1.9 때 지겹게 겪었고 이젠 관련 에러를 만나기 힘들정도로 두루두루 안정적인 상태인데 이렇게 불현듯 재회.
아무튼 고치긴 고쳐야지. 에러로그 첫 5줄을 보니 이렇더군.
구글에 대고 이렇게 검색 "active support json encode UndefinedConversionError"
검색결과 첫 글이 레일즈 이슈 티켓. 올커니 제대로군! 클릭하고 살펴보니 activesupport-json_encoder gem gem 을 설치하라더군
설치했더니 만사 OK!
이거 작년 Rails 4.1.0 부터 있었던 이슈인데 난 왜 오늘에야 만났을까...
1 0

레일즈, 엘라스틱서치 필드 값 유무 쿼리

특정 필드의 값이 있거나 없는 조건을 쿼리할 때 _missing_ 과 _exists_ 를 사용할 수 있다.
title 값이 있고 published_at 값이 없는 질의를 Query String 으로 짜면 아래와 같다.
0 0

Rails 모든 연결 SSL 로 변경하기 + Nginx Redirect

Let's encrypt 와 EFF 그리고 여러 스폰서들과 개인기부자들 덕분에 간단하게 SSL 을 적용했으니 이제 모든 http 연결을 ssl 로 돌려보자.
Rails 에서는 Controller 단위에서 force_ssl 을 사용할 수도 있고 보다 와이드하게 전체 설정에서 다룰 수도 있다.
씬디는 https 변경에 다른 별 이슈가 없기때문에 config/environments/production.rb 에 force_ssl 을 설정했다.
이렇게 설정하면 route 룰을 포함해 모두 ssl 연결로 변경된다.
NginX 나 Apache 등을 리버스 프락시로 구성하여 백단에 서버들에게 넘겨준다면 다음의 헤더를 반드시 포함시켜야한다.
Rack 서버는 1) 443 포트로 연결되었는지 2) ENV['HTTPS'] 값이 "on" 인지 3) X-Forwarded-Proto 헤더가 "HTTPS" 인지 3 가지를 보고 판단하기 때문에 리버스 프락시 뒤에 있는 puma 나 unicorn 등은 443 포트가 아닌 다른 포트나 유닉스소켓으로 통신하기 때문에 HTTPS 연결인지 확인하지 못하고 계속 리디렉션 시키게 된다.
NginX 나 Apache 단에서 301 리디렉션으로 연결 프로토콜을 변경할 수도 있겠다.
80 포트를 수신하는 서버 설정을 넣고 해당 설정에서는 http 를 https 로 변경하여 리디렉션시키면 443 을 리스닝하고 있는 아래의 설정이 요청을 수신하게 된다. 
끝.
0 2

Rails4, MySQL 4바이트 유니코드
(아이폰 특수문자 등의 Emoji) 지원 설정

MySQL의 utf8 문자셋은 3-Byte UTF-8 Unicode Encoding 을 지원하지.
3 bytes 면 사실 대부분의 글자가 다 표현되거든. 한중일, 중동, Latin 및 특수문자 다 포함해서 말이야.
그런데 원래 UTF-8 은 4 bytes 까지 기록할 수 있어. (그보다 더 옛날 스펙은 6 bytes 까지)
하지만 별로 쓸일도 없고 해서 MySQL 같은 몇몇 소프트웨어는 UTF-8 을 3 bytes 까지만 지원하는겨.
꽤 오랫동안 별 문제없었지만 아이폰의 특수문자 - Emoji 가 4 bytes 유니코드라서 이거 지원 안되는 DB에는 데이터가 제대로 안들어가는 문제가 생긴거지.
아이폰 사용자도 많고 이모지 사용도 꽤 잦기 때문에 - 인스타그램 이딴건 글자보다 이모지가 더 많아! - 이제는 우리도 4 bytes 유니코드를 지원해야 하는거지.
지금 서비스에서 이모지가 저장되는지 아닌지는 다음 문장을 복사해서 저장해보면 알 수 있지.
제대로 저장이 안된다면 이제 설정을 시작해보자.
준비물
MySQL 버전 5.5.3 이상!
차사고와 DB 사고는 항상 일어날 수 있지. 한 백번쯤 백업해놔.
1. database.yml 에서 인코딩 등 수정
2. MySQL 인덱스 길이 수정
3. 데이터베이스 재생성 또는 테이블 수정
이제 긴장 좀 때리자.
3-1 디비를 전부 삭제하고 다시 만들어도 되는 경우
3-2 디비 재성성이 불가능한 경우
1) 데이터베이스 수정
2) 테이블 수정
3) 컬럼 수정
3-3 점검걸고 데이터 백업하고 디비 재성성 후 restore
이거 편하긴하겠지만 무슨일이 생겨도 난 책임 못 진다.
진짜 책임 못 진다. 백업 백번하고 로컬 PC랑 다른 서버에 여기저기 보관해라.
뭔지 잘 모르겠으면 그냥 하지마라.
1) 일단 데이터만 백업
2) 디비 재생성
3) 데이터 리스토어
끝!
2 5

SYND 바란다#2

1. 비공개 글의 경우 메타 로봇 설정으로 noindex 처리 필요
2. 해더스타일을 좀더 쉽게 사용 할수 있게 스타일속성에서 밖으로 나왔으면.
3. 해더 스타일에 따라 자동으로 H* Tag로 마크업 처리 필요
0 0

MiniMagick jpg 저장 시 알파채널 검게 나오는 문제

MiniMagick 이나 ImageMagick 에서 jpg 포맷으로 알파채널이 있는 png 등의 이미지를 저장시킬 경우 투명부분이 검게 저장되지.
일부는 코맨드로 convert 를 사용할 경우 background 만 흰색으로 지정하면 문제가 없다고 하던대 MiniMagick 은 mogrify 를 사용해서 그런건지 BG 지정만으로는 안되고 아래처럼 background 를 지정하면서 알파 채널을 삭제하면 되더군.
그리고 중요한점! 반드시 format 을 변경하기 전에 해당 코맨드가 들어가야 정상적인 결과가 나오더군
1 2

다른 삶살아보기

 나는 흑역사도 실수로 인한 트라우마도 많다. 또 분명 좋은 추억이긴했으나 이랬으면 더 좋지 않았을까 생각 한 적도 많다.
 그럴 때 정말 한가하면 나는 '다른 삶살아보기'를 실행시킨다. 내 상상 즐겨찾기 어플에 있는 이 앱은
나를 끝없는 상상속에 빠지게 한다. 내가 아닌 다른 삶이 아닌 나지만 다른 삶 즉, 내가 했던 선택들을 바꾸어 다른 생활을 하는 장면을 보는 것이다. 꼭 다른 선택 뿐만아니라 내가 선택할 수 없는 성별 등도 바꾸어가며 다른 삶을 살 수도 있어 좋다.
(부모님 바꾸는 거 놉!, 재산도 놉!)
 다른 상상 어플과는 달라서내가 애용하는 앱이지만 한가지 치명적인 부작용이 있다. 내 삶과 너무나도 달라서 아니면 그렇게 할 걸 하고 죄책감을 느껴서 사용하고 나선 평소랑은 차원이 다르게 우울해진다. 그렇기에 우울해지는걸 예상하며 앱을 조심히 사용해야 한다.
 옛날엔 그냥 푹빠져서 했는데 지금은 하고있을때 엄마가 앱을 중지시키는 경우가 있다 좀 짜증나긴 하지만 좋은걸수도?
4 1
Square

[3분 복붙] 기사면 랜딩 PV 2배로 올리기.
브라우저 뒤로가기 제어.
이딴거 만들지 말자.

대부분의 서비스가 보다 많은 활동 사용자를 목표로 함은 분명하다.
하지만 얼마나 많은 활동 사용자가 있는지를 가늠할 수 있는 지표에 대한 목표설정은 좀 다른 얘기라고 생각한다.
심지어 그 목표의 달성을 위한 실현 과정이 사용자들을 열받게 만든다면 이 얼마나 근시안적 추태인지...
PV (Page View, 페이지 조회수) 에 대해 강한 집착을 보이는 국내 언론사들이 근래 "뒤로가기"가 실행되는 경우 이전 페이지로 보내지 않고 메인페이지로 이동되도록 하는 기능을 속속 도입하고 있더라. (좀 됐지.. 내가 잠수였던거지..)
사용자 입장에선 개빡치는 UX. 
그렇지만 남들이 한다니까 자기들도 해달라는 클라이언트의 등장은 당연지사.
해당 기능을 도입한 사이트들을 둘러보니 대부분 광고대행사 등이 제공한 스크립트를 사용하는 것 같더라.
메인페이지를 거치는 것도 짜증나는데 그 중간에 광고까지 껴있으니 개짜증..
이딴거 누가 안만들면 좋겠는데 일개 개발자가 뭘 할 수 있겠냐 고민하다가...
클라이언트에게 만들어준 간단한 스크립트를 모두에게 제공하고 너도나도 다들 도입해서 더 많은 사용자들이 더 빠르게 빡돌게 만들면 슬슬 이딴 쓰레기 같은 기능을 버리지 않을까라는 골때리는 결론에 도달했다.
0.
jQuery 를 사용하고 있다고 가정한다.
1.
아래의 코드를 기사 페이지 등 기능이 동작될 페이지에서 로드되는 js 파일에 추가한다.
3번 라인 정규식 패턴안의 synd\.kr 부분은 자신의 도메인으로 변경한다.
2.
기능이 동작될 페이지 HTML 코드 사이에 아래의 코드를 삽입한다.
완성!
코드는 단순해서 쉽게 이해할 수 있겠지만 몇몇 부분을 설명해보자면...
1. pushState 이후에 replaceState 를 다시 콜하는 이유.
pushState 만으로 history 를 조작할 경우 firefox 에서 백버튼이 골때리게 반복된다.
external > page > main > page > main > external
replaceState 를 다시 콜하면 아래와 같이 의도한대로 동작된다.
external > page > main > external
2. popState 이벤트를 사용하지 않고 hashChange 를 사용하는 이유
페이스북 앱 등 in app browser 를 사용할 때 해쉬가 없는 경우 뒤로가기 실행시 popState 이벤트가 발생되지 않음
해쉬를 추가해야 뒤로가기 실행 시 기존 URL (해쉬없는) 로 페이지 변화없는 이동이 발생하고 이 타이밍에 hashChange 가 콜 됨.
또한, Safari 9버전 이하에서 popState 가 지멋대로 fire 됨.
3. 이건 좀 쓸데없는 설명이지만 location.href 는 history 에 기록되고 location.replace 는 history 에 남지 않기 때문에 replace 를 사용해야함.
지원브라우저
웹이고 모바일이고 html5 history api 를 지원하는 브라우저 (http://caniuse.com/#search=history) 에선 기본적으로 모두 동작된다고 기대할 수 있으나 아이폰 크롬에서 동작안됨.
그 외 페이스북 앱 등 인앱에서 웹뷰를 사용하는 경우도 정상 동작.
Tested.
Microsoft Edge.
Microsoft IE 11.
Firefox 52.x (Windows)
Firefox 47.x (Linux)
Firefox 52.x (Mac)

Firefox 52.x (Android)
Firefox 6.x (iOS)
Chrome 57.x (Windows)

Chrome 48.x (Linux)
Chrome 56.x (Mac)

Chrome 57.x (Android)
Chrome 57.x (iOS) *동작안됨
Safari 10.x (Mac)
Safari 10.x (iOS)
Android 6 browser 4.x
Facebook App
자 이제 자리에서 일어나서 팀장이든 부장이든 상사에게 "저희 PV 를 2배로 올리겠습니다!" 라고 보고하고 보다 많은 사용자들의 빡을 돌려(?) 주삼. 
0 0

목소리를 내어도 전해질 수 없는

목소리를 내는데 전해지지 않는건 주로 일을 하면서 묵살되는 경우겠지. 후...답답하다
0 0

미소

진짜 좋아서 나는 것보단
억지로 만드는 경우가 많은,요즘
1 1

Trix Editor 변경 작업 중단

누가 궁금할까 싶지만 에디터 변경을 예고한 적이 있고 작업을 중단했기 때문에 글을 남겨놔야지.
Trix 로 에디터 변경을 원했던 이유는 당연히 안정적인 입력을 위해서였지만 약 3일에 걸친 작업 끝에 다음과 같은 이유로 작업을 중단했다.
1. 2bytes 입력에서 몇가지 문제가 확인됨. 
- Trix 는 라인브레이커로 br 을 사용하고 div나 pre, figure 등의 블럭 엘리먼트가 들어오면 새로운 "블럭"을 만드는데 새로운 블럭의 첫 단락에서 확정적으로 자모음이 깨진다.
- Trix 는 contentEditable 을 사용해 IME 의 입력내용을 캐치하고 Trix::Document 를 생성하는데 2bytes 의 경우 한 글자를 위해 여러번의 키스트로크가 발생할 수 있기 때문에 글자의 순서가 변경되는 문제가 간혹 발생한다.
- 같은 이유로 입력된 글자를 contentEditable에 재출력할 때  다른 블럭으로 캐럿이 점프되는 경우가 있다.
2. 기존 사용하던 에디터의 안정성이 확보됐다.
- 사용 중이던 에디터가 갑자기 엄청난 숫자의 버그들을 쏟아냈으나 약 2달에 걸쳐 대부분의 버그가 수정됐다.
- 입력된 콘텐츠가 날아가는 치명적인 문제가 남았지만 원인을 찾을 수 있었고 소스 핵을 통해 해당 부분 스킵. 발생되는 사이드 이펙트는 서버단에서 저장 시 처리하도록 코드 수정.
Trix 의 개발은 계속 팔로우 하겠고 의미있는 버전업이 생기면 다시 개발을 고민해봐야겠다.
0 2

스팸 및 댓글에 대한
의견을 구합니다.

안녕하세요.
광고글과 광고댓글로 몸살이었던적이 있었죠.
제 관리나 기능으로 해결하지 못하고 지저분함에 사용자들이 떨어져나가자 효과없음을 느낀 스패머가 더 이상 활동하지 않았던건죠.
다른 공격적인 사용자라면 음담패설이나 모욕적인 댓글을 남기는 사용자가 있었구요.
아무튼 해결해야 하는 문제임은 분명하죠.
아래의 옵션 중에 투표를 해주시거나 다른 방안을 댓글로 알로주시면 작업 기일을 공표하고 진행토록하겠습니다.
1) 신고 기능
댓글이나 글이 특정횟수 이상 신고 될 경우 블라인드처리되거나 삭제되도록
2) 자신이 작성한 글 (손님글은 제외) 에 달리는 댓글은 적성자가 블라인드(삭제아님) 처리할 수 있는 권한 부여
3) 관리자가 24/7, 365모니터링 ㅋㅋㅋ
기타 의견이나 아이디어 있으시면 댓글 남겨주세요!