살아 숨 쉬는 웹

ToDoList는 할일에 대한 리스트업을 하고 우선 순위를 지정 일정 및 작업 시간등
프로젝트 관리에 아주 유용한 툴이라 할 수 있습니다.

ToDoList 같은 프로그램은 많이 있습니다. 위젯 형태로도 많이 제공 되고 있고 MS project 도 아주 좋습니다.
하지만 MS project는 왠지 무거운 느낌이 드는 지라!
좀더 간단하게 사용할 만한 프로그램이 없을까? 하는 마음으로 구글에서 검색을 하다가 찾은 물건 중에 물건입니다.
지금 업무에 이 물건을 사용중인데 정말 좋습니다.
설치형이 아니라 간단하게 사용할 수 있고 또한 프로그램이 아주 가볍습니다.

어제 5.5.4로 버전업 된걸 보면 사용자들의 피드백을 받아 바로 바로 적용해주는 듯 합니다.
plugin 형태로 Calendar도 제공하고 있습니다. 별 기능은 없고 단지 달력으로 Task를 보여주는 정도입니다.
아직은 알파 버전이라서 그런거 같은데 좀더 지켜 보면 MS project에서 지원하는 정도의 Calendar 가 나오지 않을까 기대해 봅니다. (무거원지면 안되는데 --a)

Today Task에 대한 표시를 레드 색상으로 표시해주고 ToDoList를 실행시 자동으로 Today Task만 모아 새창으로 리스트롤 표시 해주기도 하는 기능이 포함되어 있어 아주 유용한거 같습니다.

등록된 Task에 추가 적인 내용입력이 가능합니다.
심플 모드와 리치 모두가 있는데 심플 모두는 간단한 텍스트 입력 방식이고 리치 모드는
위지윅 기능처럼 다양한 텍스트 서식을 적용할 수 있습니다.
(이부분에 약간의 버그가 있는 모양입니다. 내용을 입력하다 보면 프로그램이 뻗어 버리는 경우가 종종 발생합니다. 빨리 패치되어야 할텐데 말이죠..)

좀더 안정적인 버전이 나오길 기대해 봅니다.
너무 좋아~~~!!

Downloads

출처 : 마소

프레임워크의 도움 없이 애플리케이션을 개발한다는 것은 상상하기 힘든 시대가 다가오고 있다. 하루가 다르게 늘어만 가는 각종 프레임워크의 홍수 속에서 자신에게 필요한 최적의 프레임워크를 선별하고 효과적으로 사용할 줄 아는 능력이 개발자들에게 요구되고 있다. 프레임워크는 애플리케이션 개발자들의 오랜 숙원을 해결해 주기 위해 등장한 멋진 도구가 분명하다. 하지만 그것을 적절하게 다루고 사용할 줄 아는 지혜를 가진 자들에게만 그럴 뿐이다.

프레임워크가 무엇이라고 한마디로 정의하기는 쉽지 않다. 사람들 입에 많이 오르내리는 IT용어들은 그 정의가 사실 매우 느슨한 경우가 많다. 프레임워크라는 말은 유행어처럼 점점 많은 곳에서 폭넓은 의미로 사용되고 있다. 그래서 많은 경우에 프레임워크의 개념에 대한 오해로 인해 잘못된 판단을 하기도 한다. 그런 탓에 프레임워크의 활용 방법을 알아보기에 앞서 프레임워크라는 용어의 정확한 의미와 특징을 이해해 두는 것이 중요하다.

프레임워크의 특징
프레임워크에 대해 정확히 이해하려면 프레임워크와 그 특징이 비슷하지만 프레임워크는 아닌 것들과 비교해 보는 것이 좋다. 여기에서는 프레임워크와 혼용되어 사용되기도 하는 라이브러리와 디자인 패턴이 프레임워크와 어떻게 다른 특징을 가지는지에 대해 알아보자.

프레임워크 vs 라이브러리
프레임워크의 가장 대표적인 특징 중 하나는 그 안에 클래스 라이브러리를 가지고 있다는 것이다. 혹자는 프레임워크를 반제품이라고 설명하기도 한다. 개발해야 할 애플리케이션의 일부분이 이미 만들어져 있다는 뜻이다. 프레임워크를 이용한 개발은 결국 그 기반이 되는 이미 존재하는 부분을 확장하고 이용하는 것이라고 볼 수 있다. 윈도우즈 환경의 대표적인 GUI 애플리케이션 프레임워크인 마이크로소프트의 MFC(Microsoft Foundation Classes)와 볼랜드의 OWL(Object Windows Library)는 그 이름 그대로 클래스 라이브러리로 구성되어있다. 자바기반의 대표적인 애플리케이션 프레임워크인 스프링프레임워크는 수 천 개의 클래스기반 API 라이브러리를 포함하고 있다. 또 .NET 프레임워크는 CLR, ASP.NET과 함께 프레임워크 클래스 라이브러리가 그 핵심구성요소이다. 이렇듯 프레임워크는 라이브러리와 유사하게 생각할 수도 있다.

하지만 프레임워크는 라이브러리와는 분명히 다르다. 그 차이는 프레임워크를 사용하는 사용자코드와 라이브러리를 사용하는 코드를 비교해보면 쉽게 알 수 있다. 프레임워크는 주로 프레임워크 쪽에서 사용자의 코드를 호출하는 구조로 동작한다. 즉 실행의 흐름에 대한 제어를 프레임워크가 담당하게 된다. 많은 프레임워크는 템플릿 메소드 패턴 기반으로 만들어진 클래스를 서브 클래싱해서 사용하도록 되어있다. 결과적으로 사용자의 코드는 프레임워크 클래스에 이미 설계되어있는 흐름구조에 따라 동작하게 된다. 그래서 프레임워크의 동작원리를 그 제어흐름 일반적인 프로그램 흐름과 반대로 동작한다고 해서 IoC(Inversion of Control)이라고 설명하기도 한다. 반면 라이브러리는 유저의 코드가 라이브러리를 호출해서 사용하는 구조로 되어있다. 즉 코드의 흐름을 유저코드가 관장하고 있는 것이다. 또 프레임워크는 오브젝트간의 연동구조를 미리 정의하고 있다. 이렇듯 같은 클래스 라이브러리이지만 프레임워크와 라이브러리는 그 것을 사용하는 유저코드의 작성방식이 판이하게 다르다.

프레임워크 vs 디자인 패턴
프레임워크는 애플리케이션의 구조와 디자인을 결정하는 요소를 가지고 있다. 디자인 패턴과 마찬가지로 프레임워크는 반복적으로 발견되는 문제를 해결하기 위한 특화된 솔루션이라고 이해할 수 있다. 구조적인(architectural) 디자인 패턴인 MVC 패턴 (Model-View-Controller Pattern) 기반의 애플리케이션을 손쉽게 만들 수 있도록 설계되어있는 대표적인 프레임워크가 스트럿트 프레임워크이다. 스트럿트는 GUI기반의 MVC 패턴을 웹 애플리케이션 개발에 적용할 수 있는 더 특화된 구조적 패턴을 가지고 있다. 테스팅 프레임워크의 대표 격인 xUnit 프레임워크들은 커맨드패턴과 콤포짓 패턴으로 설계되어있다. 따라서 그 프레임워크를 기반으로 만드는 애플리케이션의 구조도 자연스럽게 이 두 가지 패턴의 영향을 받게 된다.

디자인 패턴은 프레임워크의 핵심적인 특징이고 프레임워크를 사용하는 애플리케이션에 그 패턴이 적용된다는 특징을 가지고 있다. 하지만 프레임워크는 디자인 패턴이 아니다. 디자인 패턴은 애플리케이션을 설계할 때 필요한 구조적인 가이드라인이 되어 줄 수는 있지만 구체적으로 구현된 기반코드를 제공하지 않는다. 그 패턴을 어떤 식으로 적용하고 어떤 클래스로 만들 것인가는 그 패턴을 사용하는 개발자의 책임이다. 하지만 프레임워크는 디자인 패턴과 함께 그 것이 적용 되어진 기반 클래스 라이브러리를 제공해서 프레임워크를 사용하는 구조적인 틀과 구현코드를 함께 제공한다. 결국 개발자는 프레임워크의 기반코드를 확장하여 사용하면서 자연스럽게 그 프레임워크의 패턴을 적용하게 된다.

프레임워크 = 디자인 패턴 + 라이브러리
프레임워크는 이렇게 디자인 패턴과 그것이 적용된 기반 라이브러리의 결합으로 이해할 수 있다. 이 두 가지가 프레임워크의 모든 특징을 다 설명해줄 수는 없다 하더라도 이 두 가지 관점에서 프레임워크를 관찰하는 것은 프레임워크를 이해하는 좋은 출발점은 될 수 있다. 때론 자신이 사용하고 있는 프레임워크에 적용된 패턴이 어떤 것인지 의식하지 않고 개발할 수 도 있다. 하지만 그 패턴을 이해하는 것은 프레임워크 기반의 개발이 잘못된 방향으로 나아가지 않도록 해주는 가이드라인이 되어 줄 수 있다. 또 프레임워크의 라이브러리를 살펴볼 때도 그 적용된 패턴을 주목해서 살펴본다면 그 구성을 이해하기가 매우 쉽다. 특히 프레임워크를 확장하거나 커스터마이징 할 때는 프레임워크의 패턴에 대한 이해가 꼭 필요하다.

프레임워크 활용의 지름길
라이브러리에 대한 분석과 이해도 매우 중요하다. 많은 프레임워크들이 실제 그 기능의 10~20%이하만 사용되고 있다는 보고가 있다. 프레임워크의 일부 기능만 필요해서 그랬다면 상관없지만 때로는 프레임워크에서 이미 제공되고 있는 기능과 클래스를 몰라서 똑같은 기능을 가진 코드를 직접 개발해서 쓰는 경우도 적지 않다는 점이 문제다. 프레임워크 개발자들이 자주 하는 이야기는 사용자들이 요청하는 새로운 기능의 많은 부분은 이미 다 구현이 되어 있는 것들이라고 한다. 숙련된 프레임워크 사용자 일수록 오히려 자신이 오랫동안 써 온 기능 외에는 관심을 두지 않아 유용한 라이브러리 기능을 놓치는 함정에 빠지기 쉽다. 레퍼런스 매뉴얼과 API/클래스 문서를 꾸준히 살펴보고 유용한 라이브러리의 기능에 대한 지식을 쌓는 것이 프레임워크를 잘 활용하기 위한 지름길이다.

프레임워크의 종류
프레임워크는 다양한 방법으로 구분되어 질 수 있다. 모두 프레임워크라는 이름으로 불리지만 하이버네이트와 루비 온 레일즈(RubyOnRails) 그리고 .Net 프레임워크는 사실 용도와 사용목적, 적용방식에 많은 차이가 있는 다른 종류의 프레임워크이다.

프레임워크의 도입을 고려할 때 가장 먼저 생각할 것은 어떤 종류의 프레임워크를 적용할 것인가이다. 프레임워크가 애플리케이션의 전체 구조를 결정하도록 하려면 애플리케이션 프레임워크 또는 애플리케이션 개발 프레임워크(ADF)를 살펴봐야 한다. .Net 프레임워크는 일반적인 프레임워크의 범위를 넘어서는 매우 방대하고 범용적인 플랫폼으로 활용될 수 있는 애플리케이션 개발 프레임워크이다. 루비 온 레일즈는 웹기반이면서 데이터베이스를 사용하는 애플리케이션을 개발하는데 사용되어질 수 있도록 개발된 웹기반 애플리케이션 프레임워크(WAF)이다. 이러한 애플리케이션 프레임워크 외에 애플리케이션의 일부 기술과 기능을 구현하는 부분을 위해 프레임워크를 사용하려면 그 기술과 기능을 위해 특화된 프레임워크를 찾아야 한다.

하이버네이트는 자바기반의 애플리케이션에서 관계형 데이터베이스(RDBMS)를 사용하고자 할 때 적용할 수 있는 ORM 프레임워크이다. 또 보안이나 로깅, 테스팅, 리모팅, UI, 캐싱과 같은 애플리케이션의 기술적인 부분을 담당하는 프레임워크들도 다양하게 존재한다. 이런 프레임워크들은 애플리케이션 전체 구조와 코드에 영향을 주기 보다는 일부분에만 적용된다. 이러한 기술적인 부분을 담당하는 프레임워크는 일반적으로 애플리케이션 프레임워크와 함께 사용되어질 수 있다. 애플리케이션 프레임워크를 통해서 구성된 커다란 틀 안에서 보조적인 프레임워크로서 역할을 담당하게 된다. 물론 애플리케이션 프레임워크를 사용하지 않고 일부 기술프레임워크만 도입하는 것도 가능하다.

프레임워크는 사용하는 프로그래밍 언어와 사용 환경에 따라서 구분할 수도 있다. 많은 프레임워크는 단일 언어 기반의 프레임워크이지만 한 가지 이상의 언어를 지원하는 버추얼머신에서 동작하는 프레임워크도 있다. CLR기반에서 동작하는 .NET 프레임워크는 VB, C#, C++ 등의 여러 가지 프로그래밍 언어로 개발이 가능하다. 또 자바의 JVM을 사용하는 스프링프레임워크는 최근 릴리즈 된 2.0 버전부터는 JVM에서 동작하는 다양한 스크립팅 언어를 함께 사용해서 애플리케이션을 개발할 수 있도록 지원하고 있다. 이에 따라 루비(Ruby), 파이썬(Python), 그루비(Groovy), 자바스크립트(JavaScript　)와 같은 스크립팅 언어와 자바를 동시에 사용해서 개발할 수 있는 것이다.

프레임워크와 아키텍처
일반적으로 개발팀에서 프레임워크를 선정하고 도입하는 것은 아키텍트의 역할이다. 그 이유는 프레임워크가 애플리케이션의 아키텍처에 미치는 영향이 매우 크기 때문이다. 프레임워크는 애플리케이션의 구조를 결정하기 때문에 아키텍처의 일부분을 차지하게 된다. 따라서 프레임워크의 선택에 따라서 아키텍처 설계가 달라질 수 있다. MVC 기반의 웹 프레임워크를 사용하려고 한다면 그에 맞게 Model2 아키텍처를 사용해야 한다. 반대로 아키텍처가 정해져 있다면 그 아키텍처에 맞는 프레임워크를 선별해야 한다. 3-Tier기반의 분산형 아키텍처를 설계했다면 C/S를 위한 프레임워크를 사용할 수 없다. 만약 리치 클라이언트(Rich Client) 아키텍처 기반이라면 Ajax 프레임워크 등의 도입을 고려해야한다. 따라서 프레임워크와 아키텍처는 서로 깊은 연관관계가 있다. 따라서 프레임워크를 선정할 때에는 항상 아키텍처 적으로 미치는 영향을 잘 판단해야 한다.

문제는 모두 같은 프레임워크라 하더라도 사용하는 패턴에 따라서 각기 다른 아키텍처적인 특성을 가지게 된다는 점이다. 또 한 개 이상의 프레임워크를 사용한다면 어떤 방식으로 조합하느냐에 따라서 아키텍처의 설계에 미치는 영향이 다를 수 있다. 따라서 어떤 프레임워크를 사용할 것인가 뿐만 아니라 그 프레임워크를 어떤 식으로 사용할 것인가도 고려해야만 한다. 결국 최종적으로 완성되는 아키텍처는 사용하는 프레임워크의 종류와 그 사용전략이 결합되어 결정된다고 볼 수 있다.

<그림 1> 스프링프레임워크의 다양한 활용방법에 따라 달라지는 아키텍처 비교

아키텍처 관점에서 매우 제한적인 프레임워크가 있는 반면에 다양한 아키텍처를 지원하는 유연한 프레임워크도 있다. 필자는 최근에 아키텍트로 참여하고 있는 프로젝트에서 개발하고 있는 애플리케이션에 적용된 아키텍처를 대폭 수정하는 작업을 진행했다. 전통적인 계층형 아키텍처(Layered Architecture)에서 사용하는 서비스계층 중심의 아키텍처를 리치 도메인 모델(Rich Domain Model)을 사용하는 DDD(Domain Driven Design)스타일의 아키텍처로 변경하게 되었다. 애플리케이션 구조적으로는 매우 큰 변화이지만 이 과정에서 기존에 사용하던 애플리케이션 프레임워크는 변경할 필요 없이 그대로 사용할 수 있었다. 단지 프레임워크에서 사용하지 않던 기능 일부를 적용하고 사용방식을 변경했을 뿐이다. 프레임워크를 잘못 선택해서 문제가 생기는 많은 경우는 아키텍처적으로 매우 제한이 심한 프레임워크를 도입했을 때 많이 일어난다. 따라서 프레임워크 도입 시 아키텍처적인 유연성을 따져보는 것도 중요한 일이다.

프레임워크를 정확히 분석하고 검증하기 위해서는 앞서 말한 프레임워크에 대한 세 가지 이해가 반드시 필요하다. 프레임워크의 특징과 그 종류를 파악해야 하고 그 프레임워크가 아키텍처에 미치는 영향을 이해해야 한다. 이러한 프레임워크에 대한 이해를 기반으로 프레임워크 선정과 도입에 필요한 상세한 전략에 대해서 살펴보자.

프레임워크의 선택과 도입 전략
프레임워크의 종류는 갈수록 늘고 있다. 웹 개발을 위한 언어인 PHP만 해도 이미 70여개의 프레임워크가 나와 있다. 가장 프레임워크를 활발하게 사용하고 있는 자바는 프레임워크의 종류와 수를 헤아리기 조차 힘들다. 대표적인 자바개발자 포털 사이트인 TSS에는 거의 매일 끊이지 않고 새로운 프레임워크를 소개하는 뉴스가 실리고 있을 정도이다. 때론 프레임워크가 그만 나왔으면 싶은 생각이 들 때도 있을 정도이다. 이렇게 다양한 프레임워크 중에서 개발에 필요한 적절한 프레임워크를 찾고 검증하고 도입하는 것은 매우 어렵고 번거로운 작업이다.

프레임워크를 선택하는 것이 중요한 이유는 한번 선택한 프레임워크는 쉽게 바꾸기 힘들다는 데 있다. 프레임워크는 애플리케이션 개발의 구조를 좌우하기 때문에 이미 개발이 어느 정도 진행된 후에 프레임워크를 변경한다는 것은 애플리케이션의 구조도 함께 바꿔야 한다는 부담을 동반한다. 또 프레임워크의 라이브러리에 의존적으로 만들어진 코드를 수정하려면 최악의 경우 그 동안 개발한 것을 버리고 새로 개발하는 것이 나을 만큼 큰 작업이 될 수 있다. 프레임워크가 가진 결함이나 한계를 미리 파악하지 못하면 결국 프로젝트가 실패하게 되는 위험을 맞을 수도 있다. 따라서 프레임워크의 선택은 매우 신중해야 하고 충분한 시간과 검토가 필요하다. 프레임워크를 잘 적용하면 생산성을 높여 개발기간을 단축할 수 있다. 따라서 프레임워크 없는 개발보다 상당한 시간적인 여유를 가질 수 있다. 그렇다면 개발초기의 시간을 프레임워크 분석과 선정에 넉넉하게 투자할 줄 아는 지혜가 필요하다.

프레임워크 도입의 목적
프레임워크 도입을 위해서 가장 먼저 생각해야 할 것은 도입의 목적이다. 프레임워크를 사용하려는 이유와 그로 인해 얻어야 하는 결과가 있어야만 그 기준에 부합하는 프레임워크를 선택할 수 있다. 하지만 많은 개발자들이 단지 요즘 유행하는 유명 프레임워크이니까 한번 써보려는 생각에 도입 목적은 뒷전으로 하고 특정 프레임워크를 선택하는 실수를 하기도 한다. 범용적으로 쓰이는 프레임워크가 있기는 하지만 모든 경우와 모든 목적에 맞는 프레임워크란 있을 수 없다. 프레임워크 도입의 목적은 크게 두 가지로 생각할 수 있다. 첫째는 생산성이고 둘째는 품질이다.

생산성
프레임워크에는 이미 애플리케이션 개발의 상당 부분이 만들어져 있다. 또 아키텍처나 구조적인 부분도 어느 정도 결정되어있다.

코드의 구성이나 흐름에 대한 표준도 정해져 있는 덕에 생산성을 높일 수 있는 것은 자명한 일이다. 공통적으로 반복되는 코드들은 프레임워크 내부에 감춰져 있어 개발자는 애플리케이션의 핵심 로직에 집중해서 개발할 수 있다. 하지만 프레임워크가 생산성을 높여주는 것은 단지 기반코드가 미리 작성되어있어서 개발해야 되는 코드의 양이 줄어들기 때문만은 아니다. 프레임워크는 애플리케이션 코드를 심플하게 작성할 수 있도록 도와주기도 한다. 필자가 POJO 기반의 투명한 영속성(Transparent Persistence)을 지원하는 ORM 프레임워크를 쓰면서 가장 좋았던 점은 SQL 문장을 직접 편집하지 않아도 된다거나 Connection, Statement 등을 관리하는 코드를 작성하고 close 여부 따위를 신경 쓰지 않아도 된다는 부분이 아니었다. 가장 좋은 점은 만들어진 비즈니스 로직 코드가 매우 심플해졌다는 데 있었다.

이전에는 레이어 구분 없이 비즈니스 로직과 데이터 로직 그리고 API를 호출하는 코드들이 스파게티처럼 얽혀 있게 마련이었다. 또 DAO 패턴을 적용해서 만들었다 하더라도 DB 관련 액션이나 트랜잭션에 대해서 비즈니스 로직을 작성하거나 검토하는 중에도 같이 신경을 써야하던 것을 프레임워크가 해결해 준 것이다. 결국 POJO로 설계된 모델오브젝트 만을 다루게 되니까 자연스럽게 모든 개발 작업이 비즈니스 로직을 구현하는데 집중하게 되고 결과적으로 복잡한 로직을 매우 간결하게 처리하는 심플한 코드로 깔끔하게 마무리 할 수 있었던 것이다. 이런 면에서 프레임워크의 도입목적에는 생산성이 큰 비중을 차지한다. 루비 온 레일즈와 같은 프레임워크는 초기 프로토타입을 매우 빠르게 개발할 수 있도록 해준다. 만약 고객에게 짧은 시간 안에 개발능력을 보여주고 검증을 받아야 한다면 그런 RAD 개발이 가능한 프레임워크의 도입을 먼저 검토해야 한다. 물론 생산성의 문제는 뒤에서 다룰 개발팀의 수준과 프레임워크에 대한 숙련도에도 영향을 받는다.

품질
품질과 관련된 부분도 많은 경우에 중요한 도입목적이 될 수 있다. 품질은 여러 가지 관점으로 생각해 볼 수 있는데 우선 결함이 없거나 적은 애플리케이션이라는 면에서 생각해보자. 프레임워크는 개발자가 반복적인 작업에서 실수하기 쉬운 부분들을 프레임워크 내에서 처리해줌으로써 버그발생의 가능성을 최소화 한다.

한동안 JDBC 기반의 DB개발을 하는 개발자들에게는 Connection/Statement의 정확한 리소스 반환 문제의 원인은 단순하지만 시스템을 오랜 시간 운영시키기 전에는 쉽게 발견하기 힘들다. 또 그 위치를 추적하기가 매우 어렵기 때문에 큰 고민거리였다. 사실 테스트 시에 잘 드러나지 않는 결함을 해결하기 위한 다양한 팁과 솔루션이 있었지만 사실 가장 손쉬운 해결책은 퍼시스턴트 프레임워크를 사용하는 것이다. 각종 ORM이나 iBatis, JPA 등의 프레임워크를 사용하면 DB 관련 리소스의 처리로 인한 결함에 대한 걱정을 덜 수 있어 결함이 적고 품질이 뛰어난 애플리케이션을 만드는데 큰 도움이 된다. 그 밖에도 프레임워크가 기존 개발에서 많이 등장해서 문제가 되었던 개발상의 고질적인 문제들을 손쉽게 해결해

azki

4년전 PHP와 GD를 갖고 노가다?로 그래프를 그랬던 일이 생각나네요..
세상 참 좋습니다 :[) 2008/05/20 09:50
1. 블루비
  
  4년 전에도 오픈된 PHP GD 차트 라이브러리가 있었을텐데 노가다 하셨었나 보네요.. ^^
  직접 해보는것이 배움에 많은 도움이 되긴 하지만 일이라는것이 시간 싸움이다 보니 오픈소스를 많이 이용하게 되더군요..
  
  이제는 요놈 가지고 어딘가에 적용 좀 해봐야겠습니다. 2008/05/21 11:01
2. azki
  
  그때도 있었습니다 당연히ㅋ 근대 뭔가 마음에 안들었었나? 이유는 생각나지 않으나.. 쓰지 않고 노가다를-ㅁ-
  돈받는 일로써 한 프로젝트가 아니라서ㅋ 나름 공부도 하고 재미있었습니다 (GD 노가다가 별로 사는데 도움이 되진 않은 것 같습니다만
  
  요새는 정말 너무 좋은것들이 많아서 더 어려워지기도 합니다
  이것도 알아야 하고 저것도 알아야하고ㅋ 매일 쏟아져나오는 업데이트와 ㅡ.ㅡ 새로운 라이브러리들ㅋ
  에공 공부좀해야 될텐데 너무 안하는 것 같네요ㅎㅎ
  휴 당장은 떨어진 일부터 해야겠군요ㅎㅎ 그럼수고하세용// 2008/05/22 10:26

살아 숨 쉬는 웹 - 블루비 :: Web Developer

'2008/05'에 해당되는 글 16건

CSS(Cascading Style Sheets) hack Table

TRACKBACK :: http://blueb.net/blog/trackback/1239

[Flex] ActionScript 3 Mysql Driver - asSQL

TRACKBACK :: http://blueb.net/blog/trackback/1238

[행경] 리더는 많이 알아야 한다.

리더는 많이 알아야 한다.

촌철활인

TRACKBACK :: http://blueb.net/blog/trackback/1237

프로젝트 관리 유틸 ToDoList

TRACKBACK :: http://blueb.net/blog/trackback/1235

Open Flash Chart

TRACKBACK :: http://blueb.net/blog/trackback/1234

플래시 차트(오픈소스)

[도서] 조엘 온 소프트웨어 : 유쾌한 오프라인 블로그

조엘 온 소프트웨어 : 유쾌한 오프라인 블로그

TRACKBACK :: http://blueb.net/blog/trackback/1233

[행경] 성공의 비결은?

성공의 비결은?

촌철활인

TRACKBACK :: http://blueb.net/blog/trackback/1232

[마소] 성공적인 프로젝트를 위한 프레임워크의 재발견