Lea Verou씨가 Best of Fluent 2012에서 했던 강연 동영상에서 나왔던 내용으로 다음과 같은 것이 있다.

function wordCount(text) {
  return text.split(/\s+/).length;
}
 
// Hex color 
/^#([a-f\d]{3}){1,2}$/i.test(str);
 
// A 6+ letter password with at least: 
// one number, one letter and one symbol 
/^(?=.*\d)(?=.*[a-z])(?=.*[\W_]).{6,}$/i
 
// Any number that's Not divisible by 50 
/\b(?!\d+[50]0)\d+\b/
 
// Anything that doesn't contain "foo" 
/^(?!.*foo).+$/

함께 소개된 RegExp playground 사이트도 웹 브라우저에서 간단한 Regular Expressions를 실험해 볼 수 있는 도구로 안성맞춤이고, 해당 패턴을 tweet으로 공유할 수도 있다.

영상 끄트머리에도 얘기되었는데 정규식 패턴을 짤 땐 그 정확도도 중요하지만, 너무 정확도에 치중한 나머지 실제 적용하면 들인 노력에 비해 그 성능이나 실용성 면에서 별 큰 이득이 없을 수도 있다는 점을 명심해야 한다.

node.js와 함께하는 대표적 NoSQL DB 가운데 하나인 MongoDB를 설치해서 이것저것 실험해보고 있는데, 우연하게 mongodb.log 파일을 열어보니 DB를 실행할 때마다 다음과 같은 경고문을 찍어내고 있었다.

** WARNING: soft rlimits too low. Number of files is 256, should be at least 1000

알아보니, mongod가 적절하게 운용되려면 시스템 자원의 운용과 관련해서 리소스 한계치 설정 값(ulimit settings)을 권장치 만큼 지정해 줄 것을 장려하고 있다.

경고 문구에 찍힌 현 Mac 시스템의 Number of files 값은 터미널에서 ulimit -a 혹은 launchctl limit 명령을 주면 확인할 수 있는데, 기본 설정 값이 명령에 따라 각기 open files와 maxfiles라는 이름으로 표시되며 그 값은 256으로 정해져 있다. (관련 문서 – Where are the default ulimits specified on OS X (10.5)?)

테스트 목적으로 MongoDB를 운용한다면 별 신경을 안 써도 되겠지만, 대용량 DB를 다루면서 빠른 응답속도가 요구되는 production 환경에선 이 시스템 자원의 운용에 관한 설정이 무척 중요해질 것이다.
MongoDB의 Number of files 관련 경고 메시지를 없애는 법(이)란 제목의 글 마저 읽기 →

WordPress에서 장문의 긴 글을 작성했을 때, 만약 해당 글을 index 페이지에선 그 내용을 다 보여주지 않고 글 앞부분의 도입부만을 보여주고 싶을 때를 대비해 more tag로 처리하는 기능을 제공한다. 그런데 이 기능을 그대로 가져다 쓰면 웹 접근성 면에서 문제가 생길 수 있다.

이렇게 해서 자동 생성된 링크 텍스트는 기본적으로 그냥 무의미한 more…로 표시되는데, 만약 글의 앞뒤 문맥을 인지하지 못한 상태에서 해당 링크를 스크린 리더를 통해 접근했을 땐 해당 링크가 어느 곳을 가리키는지 알 수가 없는 것이다. 하지만, 다행히 WordPress의 the_content() 함수를 제대로 쓰면 이 more tag의 내용을 입맛에 맞게 수정할 수가 있다.

the_content() 함수는 일반적으로 WordPress에서 사용되는 The Loop라는 PHP 코드 안에서 쓰이는데, 보통 WordPress 테마 파일의 index.php나 혹은 최신 WordPress에서 기본 제공하는 Twenty Twelve 테마 같은 경우 post의 종류에 맞는 여러 군데의 템플릿(template)에 사용되고 있으며 상황에 맞게 각기 따로 수정해 주어야 한다. WordPress의 more tag 접근성 문제(이)란 제목의 글 마저 읽기 →

거의 막차를 탄 갑작스러운 느낌으로 <main> element가 HTML5 확장 spec의 draft 문서에 추가되었으며, 조만간 HTML 5.1 spec에도 추가될 예정이란다.

이름에서 알 수 있듯이, main element는 문서 혹은 앱의 주요 내용을 감싸는 용도로 사용되는데, 과거에 주로 <div> element에다 id 값으로 ‘content’ 혹은 ‘main’을 줘서 주 내용을 감쌌던 것을 공식적인 main element로 대체하면 되겠다. 이렇게 하면 지원 브라우저에선 WAI-ARIA landmark 중 하나인 role=main으로 자동 인식된다.

사용할 때 주의할 점은, main element는 sectioning content가 아니므로 문서 outline에 어떠한 영향도 끼치지 않으며, 문서에는 하나의 main element만 추가할 수 있고 또 article, aside, footer, header 혹은 nav element 안에 존재할 수 없다.
HTML5의 main element(이)란 제목의 글 마저 읽기 →

가령, CSS3 애니메이션 효과를 적용할 때 미지원 브라우저한테는 대신에 JavaScript를 써서 애니메이션 효과를 대체하려고 할 때 유용한 gist로 jQuery plugin 형태로 다음과 같은 것이 있다.

$.support.cssProperty = (function() {
  function cssProperty(p, rp) {
    var b = document.body || document.documentElement,
    s = b.style;
 
    // No css support detected 
    if(typeof s == 'undefined') { return false; }
 
    // Tests for standard prop 
    if(typeof s[p] == 'string') { return rp ? p : true; }
 
    // Tests for vendor specific prop 
    v = ['Moz', 'Webkit', 'Khtml', 'O', 'ms', 'Icab'],
    p = p.charAt(0).toUpperCase() + p.substr(1);
    for(var i=0; i<v.length; i++) {
      if(typeof s[v[i] + p] == 'string') { return rp ? (v[i] + p) : true; }
    }
  }
 
  return cssProperty;
})();

출처 – Extends the jQuery.support object to CSS Properties

처음부터 무조건 JavaScript를 써서 애니메이션 효과를 주지 않는 이유는, 당연 CSS3 애니메이션 효과를 지원하는 브라우저에선 더 매끄러울 테니까 그렇다.
사용 예: CSS3 Dropdown Menu – CodePen