devise에서 sign_out시 서버가 기절할 경우. (Ruby Or Rails Bug인듯)

내용추가.
이리저리 좀 더 상황을 지켜보니..
Devise의 문제가 아니라 Ruby 1.9.2 or Rails 3.1 의 버그인것 같다.
path를 못찾는 경우 에러를 내지 않고, 끝까지 찾는다. 끝까지!

————

Devise를 붙이고 sign_out을 했는데 반응이 없다.

그러다가 몇초 후 내 맥도 반응이 없다.
Activity Monitor를 띄워보니, ruby 메모리 사용이 1.8G
응?
1.8G?
내눈을 의심하고 다시 봤는데 1.8G
가운데 .(점)만 빼면 욕이 되는 1.8G..
ㅡ.,ㅡ;
처음에는 84MB

 

 

sign_out누르니깐 몇초만에 1GB 돌파!!!

 

 

그대로 내비두면 4GB 메모리를 다 잡수실 기세라서 1GB넘는 시점에서 강제종료 해버렸다.
뭐가 문제인지 이리저리 추적을 해보니..
destroy 액션(sign_out)에서

sign_out_and_redirect

요 녀석이 의심스러워 이리저리 해보니, 역시나 이 녀석이 범인이었다.
문제는 redirect시 :root_path로 redirect하게 될 때가 있는데, 이때 :root_path를 찾지 못해 생기는 버그였다.
해결책은 크게 2가지가 있다.
1. :root_path를 만들어 주는 방법.
:root_path가 없어서 생기는 버그임으로, :root_path를 만들어 주면 된다.
routes.rb에 가서 주석처리된

 

# root :to => ‘welcome#index’

 

을 주석을 풀어주고, :to는 각자의 상황에 맞게 수정을 해주면 된다.

 

root :to => ‘getAway#Hi’

 

2. sign_out과 redirect를 따로따로.

 

sign_out_and_redirect

 

이 녀석이 하자다보니, 이 녀석을 안써버리면 그만이다.
직접 sign_out 시키고 상황에 맞게 redirect 하면 된다.

sign_out
redirect_to “넌 이미 아웃되었다.”

Xcode4 불편한점.

 

1. 단축키가 대거 바뀐점.

아.. 이거 정말 골치아프다.
개발자의 능력중 중요한 요소 하나는 작업 속도이다.
이러한 작업속도를 결정짓는 요소중 하나가 바로 툴의 숙련도인데..
단축키가 너무 많이 바뀌어 버려서, 속도가 확 줄어버렸다.

나중에 시간나면, 바뀐 단축키나 정리해봐야겠다.

2. IB에서 Objects간의 간격이 안나오는 버그

IB로 작업을 하게 되면, Objects간의 간격을 알보는게 꽤 유용하다.
물런 덧셈, 뺄셈해서 작업을 해도 되지만, Objects간의 간격을 보면서 커서로 1px씩 이동을 하면 훨씬 쉽게 작업을 할 수 있다.
그런데.. Xcode4 IB에서는 이게 동작하지 않는다.
예전에 버그 레포팅을 했는데, 과거에 다른 사람이 이미 신고를 했다고 답장이 왔다.
근데 왜 아직까지 디버깅해서 릴리즈 안하는데? ㅡ,.ㅡ;

3. IB에서 Image Copy

Xcode3시절에는 IB에서 객체 복사를 하면, 해당 객체의 속성값들까지 그대로 복사가 되었다.
말 그대로 복사였다.
그런데 Xcode4에서는 Image값을 흘리고 복사가 된다.
예를들면, ImageView를 복사해서 붙여넣기를 해보면, Image(html로 예를들면 src안에 있는 이미지 경로라고 보면 된다.)는 복사가 안된다.
웃긴건.. 다른 속성들은 그대로 복사가 되는데, Image만 복사가 안되는 것이다.
Button도 Image가 복사가 안되긴 매한가지다.

이게 버그인지, 의도적인지는 모르겠다만..
이렇다 보니, 또 다른 속성을 흘릴고 복사가 될지 모르는 불안한 상황.
하…… ㅡ,.ㅡ
그리고 ImageView, Button 전부 하나하나 찍어서 Image값 넣어줘야 하는 불편함.
하…… ㅡ,.ㅡ(2)
(내용추가.어떨땐 Image까지 잘 복사되는걸 보아 버그가 맞는듯 하다.)

Apple 나의 기대를 져버리지 않는구나.

 

Apple 패라고 망치를 그린건 아니겠지..

 

 

[jQuery] interface > sortable 스크롤이 바닥일경우 drag시 스크롤 움직이는 버그

움직일 item을 길게 늘여놓고서..
스크롤을 맨 아래로 놓은 다음
아무 item을 drag할려고 하면, 화면이 움직입니다.

아마도, helper 때문에 item들이 움직이다보니. 그로 인해 생기는 증상인것 같더군요.

이 문제는 아래와 같은 방법으로 해결 할 수 있습니다.

onStart : function(){
$(‘body’).append(“<div id=’autoHeight’ style=’height:20px’></div>”);
}
onStop : function(){
$(‘#autoHeight’).remove();
}

아래에 빈 공간을 만들어 줌으로서 화면이 안움직이게 하는거죠.
여기서 주의할 점은 height를 drag Item의 height 이상으로 해주셔야 한다는 것입니다.

[jQuery] interface > sortable > onChange > SortSerialize Bug

jQuery에 interface 라는 Plugin이 있습니다.
다양한 효과를 내는 Plugin이죠.

이 중 sortable 기능도 제공을 합니다.
근데 이 sortable은 테이블에서 목록 재정렬을 의미하는 sortable이 아니라,
Drag&Drop으로 직접 목록을 컨트롤하는..재정렬이 아닌 “재정의” 개념의 기능입니다. (예제보기)

여기서 목록이 다른 block으로 재정의 되었을때 onChange를 사용하는데, 이 때
처음에 있던 block과, 추가된 block. 즉 변화가 있는 block을 Object로 넘겨줍니다.
이걸 이용해서, 움직인 item이 어디서 어디로 갔는지 알 수 있습니다.

같은 block안에 있을떈 onChange가 실행이 안되어야 하는데 실행이 되는 bug가 있습니다.
그 경우는, SortSerialize를 사용했을 경우인데.
실제로 어디서 어디로 움직였는지 직관적으로 보거나, Ajax를 사용할땐 SortSerialize를 사용해야 편합니다.
그런데 이걸 쓰니, 작동이 안되야 할 상황에서 작동이 돠고, 제대로 된 Object를 넘겨주는게 아니라.엄한 Object를 넘겨 주 더 군요..

어디서 이 Sample Code를 본건지 모르겠지만..Sample Code에서는

function(obj){

serial01 = $.SortSerialize(obj[0]);
serial02 = $.SortSerialize(obj[1]);

}

로 되어 있더군요..
평상시에는 문제가 없지만 언급한대로, 작동이 안되어야 할 상황에서 오작동을 일으키더군요.
해결책은 으외로 간단합니다.

function(obj){

serial01 = $.SortSerialize(obj[0].id);
serial02 = $.SortSerialize(obj[1].id);

}

쩝;;