'Ruby'에 해당되는 글 10건

  1. 2007.07.23 Cases2.0에 소개된 오라클의 레일즈 사이트 2
  2. 2007.06.17 3차 루비세미나에 다녀왔습니다.
  3. 2006.12.24 Ruby On Rails 와 관련된 cheat sheet 모음
  4. 2006.10.15 Groovy, Grails 그리고 웹2.0 어플리케이션 프레임워크
  5. 2006.09.16 대안언어축제2006 를 보면서... 2
  6. 2006.07.21 Architecture Case Study : Ruby on Rails
  7. 2005.12.17 Rails 1.0 릴리즈
  8. 2005.12.05 Flowing on the Rails
  9. 2005.11.25 Rolling with Ruby on Rails
  10. 2005.11.13 스트립트 언어 (Script Language) 2

Cases2.0에 소개된 오라클의 레일즈 사이트

|
Enterprise (Web) 2.0 을 천명한  Andrew McAfee 교수가 Case Study 을 모아보자고 하더니 SocialText의 도움을 받아서  Cases2.com 이라는 위키기반의 사이트를 오픈했습니다. 여기에까지 2.0 이라는 버전넘버를 붙일줄이야. 이 사이트를 첨에 열때만 해도 5개 회사의 적용 사례만 있었는데 오늘 들어가보니 6개 적용사례가 추가가 되어 11개가 되어 있네요. 얼마지나지 않으면 많은 사례들이 모여서 좋은 참고 사이트가 될 것 같습니다.

그런데, 흥미로은 것은 오라클의 IdeaFactory에 대한 적용사례에 대한 부분입니다. 해당 페이지를 살펴보면 어떻게 IdeaFactory 을 만들었는가에 대한 소개 페이지가 있습니다. Rich Manalang 이라는 친구가  레일즈를 이용해서 이 사이트를 24시간만에 구축했다는 사연(?)이 소개되어 있습니다. 구체적으로 어떠한 플러그인을 사용했는지에 대해서도 구체적으로 설명되어 있습니다. 당장은  MySQL DB 로 구현되어 있지만 Oracle 10g, jRuby등을 고려하고 있다는 코멘트등이 있네요.

또다른 웹2.0 어플리케이션에 적합한 언어 및 프레임워크로써의 루비 & 레일즈에 대한 개발 생산성에 대한 흥미로운 사례인 것 같습니다. 이 친구가 왜 레일즈가 차세대 엔터프라이즈 어플리케이션 프레임워크 인지에 대한 포스팅도 한번 읽어 보시길 바랍니다. 10년 이상 피플소프트웨어 기반의 엔터프라이즈 어플리케이션을 개발한 경험자로써 저와의 생각과도 많이 일치하는 것 같아서 반갑기도 하구요.

분명 레일즈가 엔터프라이즈 어플리케이션 프레임워크로써 적용되기 위해서는 좀더 시간이 걸릴 것입니다. (워낙 엔터프라이즈 시스템 환경이라는 것이 생각보다 보수적이죠) 하지만 레일즈 기반의 많은 웹사이트들이 소개됨으로써 엔터프라이즈에도 적용될 수 있는 웹프레임워크로써의 검증은 끝났다고 보입니다. 또한  XML 과 복잡한 EJB, Spring Framework 등등에 지친 많은 자바 개발자들이 관심을 가지고 있다는 점,  Sun의 개발자가 적극적으로 개발하고 소개하고 있는 jRuby가 등장하면서 검증된 운영환경 (Java VM) 과 강력한 루비라는 언어와 의 결합은 레일즈가 엔터프라이즈 웹 어플리케이션 프레임워크로써 한 자리를 분명히 자리를 차지할 것으로 확신합니다.

전에 우연히 본  jRuby에 대한 세미나에서 시작 전 참석자에 대한 질문중에 다시 J2EE 기반의 어플리케이션 개발을 하고 싶냐는 질문에 많은 개발자들이 원하지 않는다는 표현을 한 장면이 생각나는군요.


And

3차 루비세미나에 다녀왔습니다.

|
토요일 오후 2시에 오픈마루 4층에서 열린 3차 루비세미나에 다녀왔습니다.

솔직히 ikspres 님을 제외하고는 거의 처음보는 분들이라서 서먹할 것 같았는데 미투의 코디안님도 뵐 수 있었고 deepblu 님도 볼 수 있었고, 직접 얼굴을 대면하고 이러저러 얘기를 하다보니 정말 젊음과 꿈과 정열을 느낄 수 있었습니다. 사실상 저는 옵저버에 가까운 입장이긴 하지만 워낙에 Rails 라는 것에 일찍부터 관심을 가지고 있다보니 이렇게 처음으로 오프라인에서 여러분들을 만나게 되어서 너무 반가웠습니다.

최근에 루비와 레일즈에 대한 관심이 높아지고 있는 것은 사실이지만 현실적으로 이를 기반으로 안정적으로 밥벌어먹고 살기에는 아직은 시기상조라는 생각이 들었습니다. 그럼면에서 오픈마루의 개발자분들은 아주 운이 좋았다고 할 수도 있겠죠. 어떻게 본다면 미투와 더불어 이분들이 개발하신 스프링노트 및 이후의 레일즈 기반의 웹서비스들이 성공을 거두게  된다면 루비와 레일즈에 대한 관심이 더욱 커질 것이라고 생각됩니다.

여하튼 이번 자리를 통해서 확인할 수 있었던 것은 레일즈를 기반으로 웹서비스를 준비하고 있는 회사들이 여럿있더군요. 올해말 쯤 되면 이러한 회사의 프로그래머들을 중심으로 좀더 내실있는 커뮤니티가 될 것입니다.

그리고 제 블로그에서 몇번 언급하긴 했지만, 루비든 레일즈든 하나의 도구라고 생각될 수도 있겠죠. 하지만 자바 이후에 사실 이렇게 관심을 끈 프로그래밍 기술도 흔치 않았고  하나의 현상으로까지 보여지기 때문에 웹 개발자라면 관심을 가지고 스터디를 반드시 해보셨으면 합니다.
And

Ruby On Rails 와 관련된 cheat sheet 모음

|
한 인도 개발자(Dmytro Shteflyuk)의 블로그에 우연히 들어가게 되었는데 레일즈(Rails) 개발을 위한 Cheat Sheet들을 깔끔히 정리해 두었네요.
http://kpumuk.info/internet/ruby-on-rails-related-cheat-sheets/

에 가보시면 그 밖의 웹개발과 관련되어 한두페이지로 요약한 Cheat Sheet을 보실 수 있습니다. 리퍼러로그를 보다보면 구글에서 레일즈 관련해서 제 사이트를 검색해서 들어오시는 분들이 있어서 올려봅니다.
And

Groovy, Grails 그리고 웹2.0 어플리케이션 프레임워크

|
자바기반의 소프트웨어를 개발하시는 분들은 그루비 (Goovy) 에 대해서는 많이 들어보셨을 겁니다. 파이썬, 루비, 스몰토크의 영향을 받은 스크립트라고 할 수 있지요. 아직 그루비에 대해서는 자세히 몰라서 그루비사이트의 튜토리올을 잠깐 보았는데 루비,자바, 파이썬등등이 (사실상 이러한 언어들도 서로서로 영향을 받았다고 할 수 있지요. 아마도 스크립트적인 요소는 펄에서, 객체지향적인 요소는 스몰토크에서 가장 많이 차용한 것으로 생각됩니다.) 뒤섞여 있다는 생각이 듭니다. 제가 그루비에 관심을 가지게 된 것은 사실 Grails 라는 즉 루비언어 기반의 Rails 어플리케이션 프레임워크가 그루비 기반으로 만들어져 사용되고 있다는 점 때문입니다. 아직은 주류로써의 어플리케이션 프레임워크로 자리잡지는 못하고 있지만 사실상 데이터기반의 웹어플리케이션 프레임워크로써만이 아니라 개발방법 자체에도 큰 변화를 주고 있기때문에 현재의 전파속도와 분위기로 봐서는 루비류 , Rails류의 언어와 프레임워크는 기존의 프레임워크를 보완하거나 대체할 것이 분명합니다. 그러한 측면에서 그루비는 기존의 자바개발자들이 접근하기에 좋은 객체지향 기반의 스크립트 언어라고 할 수 있습니다. 자기개발 시간이 충분한 개발자라면 루비도 배우고, 파이썬도 배우고 하면 좋겠지만 그렇지 못하다면 조금이라도 시간을 절약하기 위해서는 자바을 바탕으로 자신의 경력을 쌓아온 개발자의 경우 그루비에 관심을 가져보는 것도 좋지 않을까 생각됩니다. 여하튼 최근 몇년사이에 기존의 웹어플리케이션 프레임워크에 지친(?) 개발자들 사이에서 붐을 일으키고 있는 이러한 기조를 따라가주는 센스와 관심은 늘 가져야 한다고 봅니다.

분명 그루비와 Grails는 J2EE 프레임워크와 공존하면서 상호보완을 해나갈 것입니다. 그전에 많은 실험과 사례들이 등장하겠지만 기업들의 오픈소스 진영의 기술 도입 속도가 매우 빨라지고 있고 더욱 적극적으로 이를 활용하고 있기 때문에 이러한 변화는 생각보다 큰 영향을 미칠 것이고 소위 말하는 Web 2.0 의 주요 플랫폼으로 자리잡겠지요. 아니, 이미 성공적인 웹2.0 기업들은 이러한 프레임워크를 적극적으로 수용하고 있습니다. 우리나라 기업의 경우 오픈소스의 프레임워크를 쉽게 수용하지 못하는 형편이기 때문에 J2EE 기반의 웹어플리케이션을 많이 사용하고 있는 우리나라의 상황을 고려해보면 이러한 환경에서 자연스럽게 그루비 와 Grails을 검토하고 준비하는 것은 어떨까 하는 생각을 하게 된 것이 이 글을 쓰게된 계기라 할 수 있습니다. 그리고, jRubyOnRails 도 당연히 있겠지요. Sun의 jRuby개발자가 발표한 슬라이드도 참고하시길 바랍니다.

여담이지만 자바 VM 밑 닷넷프레임워크의 CLR 위에 기존의 스크립트 언어들을 포팅하는 것은 오픈소스의 또다른 경향이라고 할 수 있지요. jython (자바기반의 파이썬), IronPython( 닷넷기반의 Python), jRuby 등은 그러한 예라고 할 수 있습니다. 사실상 파이썬의 경우 펄을 잇는 스크립트의 대세로 잡은지 오래되었구요. SW 개발자라면 자신있는 스크립트 언어 한두개 정도는 가지고 있어야 하지 않을까요?

개발능력을 상실한 개발자의 말이라 좀 설득력이 떨어지는 군요. -.-
And

대안언어축제2006 를 보면서...

|
아직도 저는 이러한 활동들을 볼라치면 가슴이 두근거립니다.
마음뿐이고 머리의 지적능력의 한계로 인한 좌절도 함께 느끼게 되지만요.

대안언어축제 2006/후기



개인적으로 이번 대안언어축제에서 튜토리얼을 진행한 언어중에서 실무에 사용해보았던 언어는 1990년도에 사용한 Lisp이네요. 정말 멋진 언어이지만 이론적 뒷받침이 약했던 관계로 정말 AutoCAD의 스크립트 수준으로만 (AutoCAD에는 AutoLisp이라는 스크립트언어를 기본적으로 제공하고 있었지요. 지금도 그런지는 잘 모르겠네요) 사용해서 개발했던 기억만 나는군요. 제가 입사해서 하게된 최초의 프로젝트였고 AutoCAD의 데이터포맷을 다른 형태의 데이터포맷으로 변환하기 위해서 사용하였었죠. 당시 신입사원이라고 6개월의 개발기간을 잡고 시작했었는데 한달만에 일을 끝내서 팀장께서 깜짝 놀래셨죠. Lisp과 관련한 재밌는 에피소드가 있는데 1986년도에 제가 대학교에 입학하자마자 무조건 컴퓨터에 대해서 공부해보겠다고 서점에 가서 산 책이 Lisp 교재였습니다. 물론 영어였구요. 당시에 컴퓨터에 대한 지식이 전무한 상태에서 Lisp이 인공지능과 관련된 언어라는 것만 알고 무조건 사본 책입니다. 믿기 힘들겠지만 입학식 하기 직전 고등학교 마지막 겨울방학때 억지로 읽은 기억이 납니다. 물론 전혀 이해하지 못했습니다. 다른 책은 오래되어서 다 버렸지만 그 책은 아직도 버리지 않고 보관하고 있답니다.

그리고 객체지향공부해보겠다고 MS-DOS에서 동작하던 Smalltalk 을 어렵사리 구해서 사용해보았던 기억도 있구요. 아마 1990~91 년도쯤인가 싶습니다. 당시에는 전혀 이해하지 못했습니다. 먼소리인지 알게된건 1993년도쯤인가 객체지향에 대해서 독학하면서 C++로 프로젝트를 하면서 의미를 이해하게 되었습니다. 그리고 기본적으로 그래픽환경을 제공해야 하기 때문에 더욱이 개발환경 자체를 구축하기 힘든 면도 있었지요.

넥스트스텝 해보겠다고 Objective-C도 좀 본것 같은데 샘플 프로그램이상 돌려본적은 없네요. 그저 Smalltalk 와 C을 절묘하게 짬뽕시킨 언어인데다가 당시 넥스트스텝의 개발환경에 완전히 감동을 했었지요. 지금의 OS X의 개발환경도 이 당시의 환경을 근간으로 하고 있을 것입니다. (최근에 본적이 없어서 자신할 수가 없어서.) 하지만, 실무에는 전혀사용하지 못하였습니다.

Python은 그 문법과 간결함이 너무 좋아서 공부하다가 친구녀석의 범죄(?) 행위를 도와줄 때 잠시 사용해본 적이 있습니다.

Ruby는 작년부터 관심을 가지고 보고 있는 언어입니다. 언어보다는 Rails 에 더 관심이 있어서 보게 된 언어인데 Perl 과 Smalltalk을 짬뽕시킨 언어(그밖에도 Python, Lisp 등 가장 여러가지 언어적 특징이 뒤섞인 듯 하고..) 라고 생각됩니다. 아무튼 객체지향 언어에 있어서 Smalltalk 의 영향을 받지 않은 언어는 없는 듯 합니다.

그렇다고 제가 이러한 언어들을 능수능란하게 사용하는 것은 전~~혀 아닙니다. 그저 관심을 가지고 있다는 것이지요. 하지만 아마 SW 개발하시는 분들은 C, C++, Java, C# 등 주류언어로만 개발을 하시는 분은 없으실 겁니다.

아, 그리고 글을 쓰다보니 한가지 더 생각이 났습니다. 스크립트언어중에서의 가장 주류를 이루고 있는 언어는 자바스크립트가 아닌가 싶습니다. 의외로 이 스크립트 언어에 대해서 깊은 이해를 하고 있는 개발자들을 많이 보지 못했습니다. 남이 짜놓은 것을 가져다가 동작되는 것을 보면서 활용하는 경우가 많은 것 같더군요. 최근 AJAX 가 부각되면서 이 언어자체에 대해서 다시 한번 들여다보고 이해할려는 움직임이 뒤늦게 일어나고 있다는 생각이 들더군요. 그래서 기초를 튼튼히 해야 한다고 하는데 그러지 못하는 현실도 있기에.

갑자기 예전 생각들이 나서 그냥 링크만 걸려고 했는데 글이 길어졌네요.
And

Architecture Case Study : Ruby on Rails

|
늘 Rails에 대한 관심을 가지고 있는데 Rails의 아키텍쳐에 대해서 케이스 스터디 한 문서가 있네요. 요즘 Rails을 기반으로 하는 Web 2.0 사이트들도 늘어나고 있는 것 같고, 국내에도 많은 관심들을 가지고 계신 것 같은데 관련 서적들이 한글판으로 번역된 책이 아직 없는 것 같습니다. 최근 Rails 에 대한 책도 2판이 나왔고 하니 어느 분이 나서서 번역을 하면 국내에도 Rails에 대한 저변이 넓어지지 않을까 생각이 듭니다.


출처 : Software Architecture Case Study : Ruby on Rails (PDF)
And

Rails 1.0 릴리즈

|
Release Candidate 가 나온지 얼마안되었는데 그새 1.0이 릴리즈가 되었군요. 업데이트해서 3주전쯤에 스터디하면서 간단히 구현해본 프로그램을 돌려보니, 한글이 깨지는 군요. 인코딩문제이겠지요. 또 멀 손대놓은 것인지. 웹에서 한글 인코딩은 정말 머리가 아프군요. 개발환경이 설치된 오에스에서부터 실제 운영될 오에스나 환경에 따라서 거기다가 DB의 인코딩까지 신경쓸려면 늘 헷갈립니다. (머리가 나쁜탓인지도.) 여하튼 속도도 빨라지고, 좀더 안정성이 좋아졌을 거라고 생각이드네요.제가 비주류인 Rails에 관심을 가지고 있는 것은 지금 대부분의 웹어플리케이션 프레임워크들이 너무 복잡해서입니다. 닷넷보다도 J2EE가 너무 복잡해지고 있다는 느낌입니다. 최근에 다시 여러가지 대안이 나오고 있다는데 관심을 가지고 있지 않아서 자세한 내용을 모르겠습니다. (음,이것도 시간을 내어서 살펴보아야 겠군요.) LAMP도 그런면에서 대안이 되는 것이구요. 좀더 냉정하게 기술을 봐야 할 시기인 것 같습니다. 다른 얘기입니다만 자바와 닷넷 그리고 기타 비주류 환경이나 프로그래밍언어등을 생각해볼때 우리나라의 경우엔 너무나도 한두가지 플랫폼과 프로그래밍 언어에 치중하는 경향이 더욱 크기에 경계를 해야한다고 봅니다. 어떠한 것을 선택하든 균형 감각을 가지고 전체를 이해하고 적절한 것을 선택할 수 있어야 할텐데 말입니다. 현실적으로는 사실 매우 어렵지요. "언어가 뭐가 중요해 다 익숙해지면 마찬가지고 필요할 때 적절한 것을 선택하면 되지" 라고 말하는 천재 프로그머들의 말에 평범한 저로써는 쉽게 동의하기 힘들죠. (물론 그러기 위해서 노력하는 것은 다른 문제입니다만) 특히 다양한 기술과 성격과 능력을 가진 구성원으로 이루어진 조직에서는 말이죠. 얘기가 완전히 다른데로 샜군요. ^^

http://www.rubyonrails.org
And

Flowing on the Rails

|
MVC Pattern을 충실히 지키는 웹프레임워크 Rails의 데이터 플로우를 설명한 자료입니다. J2EE 에서도 흉내는 내지만 직관적으로 MVC 패턴을 적용하기 위해서는 상당히 복잡하고 힘들지요. 그런면에서 매우 맘에 듭니다. 직관적인 툴과 환경이 말이죠. 참고로 툴과 환경이 최적으로 결합된 ASP.NET 2.0과는 비교될 수 없지만 적어도 오픈소스기반의 웹프레임워크에는 향후 Rails의 영향력이 상당히 커질라고 믿습니다. 반면에 우리나라에서 많이 쓰이기 위해서는 더 많은 시간이 필요할 것으로 생각됩니다만, 파이썬이 그랫듯이 향후 많은 개발자들이 참여할 것으로 생각됩니다.

Model:Active Record , Contoller : Action Controller,View : Action View

Active Record
Connects business objects and database tables to create a persistable domain model where logic and data is presented in one wrapping.


Action Pack
Routes incoming requests through controllers with one method per action and lets view rendering happen using Ruby templates.


Action Mailer
Consolidates code for sending out forgotten passwords and invoices for billing in easy-to-test email service layers on top of smtp or sendmail.





Source: http://www.enomaly.net/ruby_on_rails.1013.0.html
And

Rolling with Ruby on Rails

|
Ruby라고 하는 언어로 만들어진 웹어플리케이션 프레임워크입니다. 프로그래밍 언어에 관심이 많다보니 알게 되었는데 여러분들도 한번 즐겨보시길 바랍니다. 아래의 링크에 가셔서 주~욱 따라가 보세요. 마이크로소프트웨어에도 관련 기사가 있으니 보시구요. MVC 모델을 충실히 따른 프레임워크 및 Agile 프로그래밍 환경이라고 생각이 듭니다. 아래는 오릴리 사이트에 올라와 있는 튜토리얼입니다.


Rolling with Ruby on Rails
http://www.onlamp.com/pub/a/onlamp/2005/01/20/rails.html

http://www.rubyonrails.org/ 그런데 회사에서는 이 사이트가 접속이 안되네요. 집에서는 잘 접속이 되는데.
And

스트립트 언어 (Script Language)

|
비록 개발은 하지 않지만 저는 프로그래밍 언어에 관심이 많은 편 입니다. (같은 열정으로 영어공부를 했다면 ... 흑.)원래 HP-UX에서 개발을 시작해서 그런지 Korn Shell 에는 많이 익숙해 있었지요. 요즘 리눅스에서는 Bash을 많이 쓰고 있더군요. 이 얘기를 할려고 한 것은 아니고 사실 99년쯤에 Python을 알게되었습니다. C/C++을 가지고 뭐하나 개발할 때마다 makefile 일일히 만들어서 컴파일하고 빌드하다가 이 언어를 보는 순간 너무 맘에 들었었죠. 물론 Perl 도 있었지만 남이 짜논 걸 보는 것은 정말 고역이였고 특히 변수마다 붙은 $기호는 왠지 혼란스럽더군요. 나중에 PHP도 $가 붙는 다는 이유로 스윽 보고는 별로 관심을 가지지 않았었지요. 반면 Python은 들여쓰기(탭) 를 이용해서 코드블록을 잡아준다는 점과 이미 제공되는 라이브러리들이 너무 편했습니다. 큰 프로그램을 짜지는 않았지만 간단한 네트워크 클라이언트 프로그램을 개발할 때는 정말 편리하더군요. 문자열 처리나 데이터처리들이 너무 간단해서 예전에 Lisp(정확히는 AutoCAD에서 제공되는 AutoLisp) 을 이용해서 프로그램 개발하던 때가 생각이 나더군요. 소스의 심미안적인 측면에서는 Python이 아마 가장 좋다고 생각됩니다. 코딩이 끝나고 나면 자연스럽게 정리되어 있는 소스코드를 보면서 기분이 좋아지죠. 들여쓰기를 제대로 지키지 않으면 동작하지 않는 언어이니까요. 요즘에 Konfabulator 덕분에 JavaScript에 대한 책도 한번 볼 기회가 있었고, 최근에는 Rails 라는 웹 애플리케이션 프레임워크 때문에 Ruby 라는 언어에 관심이 생겼습니다. Ruby는 100% 객체지향 언어이면서 Perl의 특징을 슬쩍 버무려놓은 듯 합니다. 하지만 이 Ruby라는 언어보다는 Rails 라는 웹 애플리케이션 프레임워크가 더 흥미를 끄네요. 덕분에 이번주말은 Rails에 대한 책을 보았습니다. Ruby 라는 언어가 제공하는 동적인 객체지향 특성을 잘 살린 것 처럼 보이더군요. 그리고 지저분한 XML로 된 설정파일도 보이지 않고.그러고보니 PHP 을 이용해서 Rails 프레임워크를 구현하는 프로젝트도 있네요. Rails 라는 말을 그대로 흉내내기 싫었던지 Trax로 바꾸어서 PHP onTRAX 이라고 부르는 군요. ^^ 혹 관심이 있으신 분들은 올해 마이크로소프트웨어의 Ruby와 Rails에 대한 기사를 찾아보시길 바랍니다. 혹시나 Visual Studio 2003.2005 같은 개발환경을 쓰시는 분들은 Shell에서 개발하는 이러한 프레임워크에 대해서 생산성이 낮다고 말할지 모르시겠지만 실제 이런 환경에서 한번 개발해보시면 생각이 달라질 수도 있으 실겁니다. 그래도 이번에 얼핏 본 Visual Studio 2005의 ASP.NET 개발환경은 개발자를 좀 바보로 만들정도로 강력하다는 생각이 들더군요.

http://www.ruby-lang.org/en
http://www.rubyonrails.org/
http://phpontrax.com/

프로그래밍도 읽기만 되고 쓰기는 안된다는...
And
prev | 1 | next