Software Development

E-Book 관리 시스템

4 댓글 / Software Development / /

KeKe군과 대화中, 현재 소장하고 있는 E-Book들을 제대로 활용하기가 힘든 이유 중 하나가, E-Book들의 메타 정보가 부족하고, 검색이 힘들기 때문이라고 생각이 들었다.
그래서 구상한 E-Book 관리 시스템의 functionality들을 적어보면…
 
1) E-Book의 commit 시스템.
 
E-Book을 파일 이름을 기반으로 아마존에서 해당 ISBN을 찾아냄.
(E-Book들의 파일 이름은 일반적으로 책의 제목으로 되어있다는 가정)
이 과정에서 human intervention이 있을 수 있으나, 여러 ISBN 중 맞는 것을 선택하는 것 외의,
대부분의 작업은 자동화 가능.
 
2) ISBN을 기반으로 해당 E-Book의 (아마존에서) 메타 정보를 얻어와서 cache.
 
3) E-Book 파일과 메타 정보의 효율적인 추가/삭제.
 
4) E-Book을 검색할 수 있는 웹 인터페이스.
 
구현의 대부분은 특정 DB와 아마존 Web Service API,
E-Book의 메타정보를 나타낼 XML 정도로 가능해보인다.
 
기능들은 단순하지만, 이런 정도의 시스템만 있어도,
여러곳으로 산재되어 관리하는 E-Book들을 지인들끼리 모아서,
다른 여러가지 시너지 효과를 기대할 수 있을 듯.
 
—
 
언제나 불편한 것들에서 아이디어들은 많이 생각해내지만, 실제로 완전히 구현하는 일은 드물다.
(나는 기획자적인 인간인가? -_-)
대체로 GUI의 벽이 가장 크다고 볼 수 있는데, 이 벽을 깨내는 방법이 없을까. >.<
최근에는 XUL을 통해 타개할 수 없을까 고심中.
 
Amazon Web Service
http://www.amazon.com/gp/browse.html/104-5247989-7236768?node=3435361
 
 

E-Book 관리 시스템 더 읽기"

Let Java Go

댓글 달기 / Software Development / /

얼마전에 Eric S. Raymond가 Sun에게 쓴 open letter. 현재의 Sun이 “The open-source model is our friend”라는 정책을 표명하고 있지만, 부족하다고 생각하며, 특히 Java code에 대해서는 control 하려는 경향이 강해서 Java는 open-source community에의 acceptance를 잃고 다른 language에 자리를 내주고 있다는 얘기를 하고 있다. 마지막으로, Java 개발을 open source community에 내주자는 주장을 하고 있다. 이에 대해 Simon Phipps는 답장에서 Java는 지금도 충분히 open source의 요건을 만족하고 있다고 하면서, 사실상 ESR의 요청을 거절했다.
 
Open letter to Sun: Let Java Go
http://www.catb.org/~esr/writings/let-java-go.html
 
Sun’s Simon Phipps Answers ESR’s Call to Open Source Java: Doesn’t Hold Water
http://news.osdir.com/article451.html

Let Java Go 더 읽기"

Hypertransport 2.0

댓글 달기 / Software Development / /

지난 9일, PCI-Express에 mapping되는 AMD 진영의 대체 PCI bus인 Hypertransport 2.0 spec이 나왔다. speed capacity가 2.0-2.8 Giga Transfers/second이고 maximum aggregate bandwidth가 22.4 Gb/s란다.
 
아래의 Inside PCI Express 기사에 의하면, Hypertransport가 실용화되고 있는 시점에서 PCI Express가 어떻게 Hypertransport를 대체할 것인지에 대해서 잘 모르겠다고 평가하고 있다. 그리고 PCI Express가 process-to-process 또는 processor-to-north bridge간의 connection으로 활용될 경우, PCI Express가 채용하고 있는 serial interconnects (rather than pararrel interconnects in Hypertransport)는 latency가 높아질 수 있다고 한다. 그 외에도 MP design에 있어서의 cache coherent protocol의 지원 미비에 대해서도 언급하고 있다.
 
소비자인 나로서는 Hypertransport가 PCI Express와 용호상박이라는 것이 즐거울 수 밖에.
 
HyperTransport Consortium
http://www.hypertransport.org/
 
HyperTransport Consortium Announces High-speed Release 2.0 Specification
http://www.hypertransport.org/pr_020904.htm
 
HyperTransport Technology Overview
http://www.hypertransport.org/docs/ht-overview.pdf
 
PCI Express
http://www.pcisig.com/specifications/pciexpress
 
Intel Developer Network for PCI Express Architeture
http://www.intel.com/technology/pciexpress/devnet/
 
What is PCI Express?
http://www.intel.com/technology/pciexpress/devnet/docs/WhatisPCIExpress.pdf
 
PCI Express Architecture Initiative Overview
http://www.intel.com/technology/pciexpress/devnet/docs/PCI-Express-Overview-Oct2003.pdf
 
High-Performance Buses and Interconnects
http://www.extremetech.com/article2/0,3973,27302,00.asp
 
Inside PCI Express
http://www.extremetech.com/article2/0,3973,522303,00.asp
 

Hypertransport 2.0 더 읽기"

We Are Morons: a quick look at the Win2k source

댓글 달기 / Software Development / /

We Are Morons: a quick look at the Win2k source
http://www.kuro5hin.org/story/2004/2/15/71552/7795
 
항상 내가 하던 짓이라 공감도 가고, 재미있기도 하고,
또한 감동적이기도 하다.
 
—>8—
In the struggle to meet deadlines, I think pretty much all programmers have put in comments they might later regret, including swearwords and acerbic comments about other code or requirements. Also, any conscientious coder will put in prominent comments warning others about the trickier parts of the code.
—>8—
 
—>8—
From the comments, it also appears that most of the uglier hacks are due to compatibility issues: either backward-compatibility, hardware compatibility or issues caused by particular software. Microsoft’s vast compatibility strengths have clearly come at a cost, both in developer-sweat and the elegance (and hence stability and maintainability) of the code.
—>8—

We Are Morons: a quick look at the Win2k source 더 읽기"

Secure Your Web Services

1개의 댓글 / Software Development / /

 .net magazine august 2003에서 발췌, 요약.
 
Secure Your Web Services
 
Using currently available technology
 
1. SSL/TLS
 
Secure Socket Layer/Transport Layer Security (SSL/TLS)나 Windows Integrated Security를 사용하는 방법이다. TLS란 SSL의 대체물로 SSL 3.1로 불리기도 한다. TLS와 SSL은 호환성이 없으므로, 새로운 프로젝트에는 TLS를 사용하는 것이 좋을 것이다.
 
Web services message는 Web services provider에게 secure SSL/TLS channel을 통해 전달된다. 이 secure channel은 interaction’s outset에서 handshake에 의해 형성된다. 각각의 message들은 encrypt되어있고 digitally sign되어있고, 따라서 message의 confidentiality와 integrity를 보장한다.  initial handshake 중에는 single, dual-sided authentication이 일어난다. Web service provider는 항상 CA로부터 발급받은 certificate를 가지고 있다.
 
SSL/TLS solution은 매우 secure하지만, 매우 resource-intensive하기 때문에 scale하지 않다.
 
2. Windows Authentication
 
authentication만을 지원. (not encryption) provider와 client 사이의 정보는 clear text.
 
3. SOAP header
 
SOAP header는 fully extendable하기 때문에 authentication을 위한 credential을 포함하는 header를 만들 수 있다. 이러한 solution은 client와 service 양측에 대한 control이 가능할 때 가장 적절한 solution이다.
 
적절한 de facto or official standard 없이는 여러 partner간에 secure infrastructure를 일반화하고 유지하는 것은 불가능하다. 위의 방법들은 Web services를 위해 설계되지 않았기 때문에 한정된 환경 (constrained environment)에서 잘 동작하는 단기적인 해결책이다.
 
WS-Security specification from OASIS
 
– enhancements to the SOAP messaging protocol: authentication & security token
– XML digital signatures: integrity
– XML encryption: confidentiality
 
Web services architeture usage scenarios에서 W3C는 specification들에 관련된 Web services의 requirement를 정리하고 있다.
 그러한 specifications들 가운데 기본적인 개념 하나는 미래의 Web services message들은 claim을 가질 것이란 것이다. claim이란 name, key, 또는 permission 그리고 authorization이다. Web services의 security policy는 필요한 claim들의 집합을 명시할 수 있다. Web service는 필요로 하는 claim을 가지지 않은 message를 무시하거나 거부할 수 있다. Web service client는 security token을 message에 포함함으로써 claim의 증명을 제시한다.
 
Web services message는 parsing, authentication, authorization에 필요한 모든 정보들을 가지고 있을 것이다. messages가 destination에 도달할 때까지 여러 intermediaries를 거치게 되므로, 이 원칙은 매우 중요하다.

 
이러한 시나리오에서 message의 recipient가 모든 인증된 claim을 가지고 message의 originator와 항상 직접 interact하는 것은 불가능하다. message가 필요한 claim 없이 destination에 도달할 경우, requestor나 requestor에 해당하는 intermediaries는 다른 Web services로부터 필요한 claim과 security token을 얻어올 수 있다.
 

 
 
 
 

 
 
 
 
 
 
 
 
 
 
 
Prepare for Web Services’ Future
 
Web services는 서로 다른 vendor들의 system을 연동하는 glue이다. 따라서 capable least common denominator가 시급하게 필요하다. 소프트웨어, 하드웨어 산업의 모든 key player들이 노력을 쏟고 있는 현실에서, 앞으로 Web services의 확산은 불가피한 것 같다.
 
Resources
 
Microsoft XML Web Services Developer Center Home:
http://msdn.microsoft.com/webservices/
 
OASIS
http://www.oasis-open.org
 
OASIS Web Services Security TC
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wss
 
W3C Web Services Architecture Usage Scenarios
http://www.w3.org/tr/2002/wd-ws-arch-scenarios-20020730/
 
developerWorks Web services
http://www-136.ibm.com/developerworks/webservices

Secure Your Web Services 더 읽기"

Slashdot Today

댓글 달기 / Software Development / /

2.4 vs 2.6 Linux Kernel Shootout

FyRE666 writes “Infoworld are currently running an interesting comparison of the 2.4 series kernel against the new 2.6 release on Xeon, Opteron and Itanium …
Source: http://slashdot.org/article.pl?sid=04/01/31/1915227
 

IETF Approves XMPP Core as Proposed Standard

hystrix writes “As long expected, the IESG has approved the Extensible Messaging and Presence Protocol (XMPP): Core (draft-ietf-xmpp-core-22.txt) as a Proposed …
Source: http://slashdot.org/article.pl?sid=04/01/30/1346237
 

UserLinux Will Support KDE

kollum writes “Bruce Perens has revealed that UserLinux will now support KDE commercially. It seems there is a demand for a KDE plan afterall.”
Source: http://slashdot.org/article.pl?sid=04/02/01/1551242
 

Slashdot Today 더 읽기"

xbelgen

3 댓글 / Software Development / /

XBELGen

Description

  • IE Favorites로부터 XBEL format의 xml을 생성하는 python script.

Requirements

  • Python 2.3.3
  • CJKCodec
  • PyXML
    • 이상하게 Python 2.3.3에 기본으로 들어가있는 xml.sax.saxutils.XmlGenerator로는 한글 쓰기가 안된다. (utf-8로 하는데도!!!)

Download

Example

External Links

— JosephJang – 23 Jan 2004
 
http://www.lastmind.net/tWiki/bin/view.pl/Main/XbelGen

xbelgen 더 읽기"

Comparing and introducing Ruby

댓글 달기 / Software Development / /

http://www.ntecs.de/old-hp/s-direktnet/rb/ruby.pdf

 
Ruby가 어떤 점에서 다른 language 들(esp. Python, Perl)에 비해 뛰어난지를 설명하는 article이다. syntax로부터 library까지 여러가지 내용이 있지만, 인상깊었던 것들만 요약하면 다음과 같다.
 
What is Ruby?
 
– modern, interpreted and object-oriented programming language
– Ruby > (Smalltalk + Perl) / 2
– developed, having Perl, Python, Smalltalk and Eiffel in mind
 
Easy to learn
 
– has good tutorial
– easy syntax
– clean, readable but short
 
Syntax
 
– variables only contain references to objects
– all constructs have a value (e.g. if-construct)
– variable name convention defines characteristics of variable (capital letter, small letter, $, @)
(Perl use my, local, …)
– iterator, blocks with method
– exception model support post-condition (begin-rescue-ensure-end)
– dynamic type checking
 
OO Features
 
– instance variables (member variable in C++) are only accessible from insdie the class (maybe getter-, setter- methods)
– attr_accessor function of module Module dynamically creates a getter- and setter- method for each parameter
– extend existing class in adding a whole class
– support only single inheritance
– support mix-in (alternate multiple inheritance): every module can be included into a class
 
Library
 
– Perl-like Regular expression
– DB access (MySQL, Msql, PostgreSQL, Interbase, Oracle)
 
Language Extension
 
– C/C++ extension
– Ruby/Python

Comparing and introducing Ruby 더 읽기"