Saturday, June 02, 2007
Saturday, June 02, 2007 09:37 PM
comments (0) |
trackback (0) |
Permalink
Apache의 mod_proxy를 사용하여 LAMP 보안성을 크게 향상시킬 수 있다.
Improve LAMP security with Apache Proxy’s directive (mod_proxy)
Posted by:
shinny
Filed under:
Programming,
Linux
Saturday, June 02, 2007 07:44 PM
comments (0) |
trackback (0) |
Permalink
5월 28일 파주 출장 중 자운서원(紫雲書院) 표지판이 눈에 띄어 무작정 찾아가 보았다.
파주 법원리에서 약 2km정도에 위치해 있고, 입구엔 입장료 천원이라고 큼지막하게 써 있던데 평일이라서 그런지, 입장료 받는 곳에 사람이 없어 그냥 들어 갔다.
꽤 더운 날씨임에도 울창한 나무숲이 만들어 주는 그늘과 바람이 참 시원했다.
자운서원은 오천원 지폐에 그려져 있는 율곡 이이 선생을 모시고 제를 올리는 곳인데 특이 하게도 묘지를 둘러보니 율곡이이 선생의 묘지가 가장 높은 곳에 위치해 있고, 율곡의 아버지인 이원수와 어머니 신사임당의 묘지는 율곡의 묘 밑에 있는 특이한 형태였다. 자운서원 옆으로 난 산책로를 오르다보면 약수터도 있어 목을 축일 수 있다.
자운서원 (紫雲書院)
경기도 파주시(坡州市) 법원읍(法院邑) 동문리(東文里)에 있는 서원. 1615년(광해군 7) 이이(李珥)의 학문과 덕행을 기리기 위해 세워졌다. 1650년(효종 1) ＜자운(紫雲)＞이라는 사액(賜額)을 받았고, 그 뒤 김장생(金長生)과 박세채(朴世采)가 추가로 제향되었다. 1868년(고종 5), 흥선대원군(興宣大院君)의 서원철폐령으로 훼철되어, 위패는 매안(埋安)하고 그 터에서 향사를 지내왔다. 이후 1969년에 복원되었고 1975∼1976년에 보수되었다. 팔작지붕으로 된 6칸의 사우(祠宇), 신문(神門), 동서 협문(夾門) 등이 있고, 서원의 밖에는 묘정비(廟庭碑；경기도 유형문화재 77)와 이이(李珥) 및 그 양친의 묘소가 있다. 향사의 기일은 매년 8월 중정일(中丁日；두번째 丁日)이다. 경기도지방기념물 제45호.
율곡(栗谷)
조선 중기 학자·정치가. 자는 숙헌(叔獻), 호는 율곡(栗谷)·석담(石潭). 본관은 덕수(德水). 강원도 강릉(江陵) 출생. 아버지는 이원수(李元秀), 어머니는 사임당 신씨(師任堂申氏)이다. 어려서부터 어머니에게 학문을 배웠고 1548년(명종 3) 13세로 진사시에 합격하였다. 1551년 어머니가 죽자 파주(坡州) 자운산(紫雲山)에서 시묘한 뒤 1554년 성혼(成渾)과 도의(道義)의 교분을 맺고 금강산에 들어가 불교를 공부한 뒤 1555년 하산하여 유학(儒學)에 전념하였다. 1558년 이황(李滉)을 방문하였고, 별시에서 《천도책(天道策)》으로 장원하였으며, 전후 9번의 과거에 모두 장원하여 구도장원공(九度壯元公)이라 일컬어졌다. 1564년 호조좌랑이 된 뒤 예조좌랑·이조좌랑 등을 거쳐 1568년(선조 1) 천추사(千秋使)의 서장관(書狀官)으로 명(明)나라에 다녀왔으며, 부교리로 춘추기사관을 겸임하여 《명종실록》 편찬에 참여하였다. 1569년 《동호문답(東湖問答)》을 지어올리고, 1574년 우부승지가 되었으며 재해로 인하여 《만언봉사(萬言封事)》를 올렸다. 1575년 《성학집요(聖學輯要)》, 1577년 《격몽요결(擊蒙要訣)》을 지었으며, 1580년 《기자실기(箕子實記)》를 편찬하였다. 1582년 이조판서가 되어 《인심도심설(人心道心說)》 《김시습전(金時習傳)》 《학교모범(學校模範)》을 지었으며, 1583년 《시무육조(時務六條)》를 계진하고 십만양병을 주청하였다. 1584년 서울 대사동(大寺洞)에서 죽어 자운산 선영하에 안장되었다. 이황과 더불어 조선시대 유학의 쌍벽을 이루는 학자로 기호학파(畿湖學派)의 연원을 열었다. 정통 성리학적 입장을 견지하면서도 단순히 성리학만을 고수한 것이 아니라, 불교와 노장철학(老莊哲學)을 비롯한 제자백가(諸子百家)의 학설과 양명학(陽明學) 등에 대한 이해도 깊었다. 또한 이(理)는 무형무위(無形無爲)한 존재이고, 기(氣)는 유형유위(有形有爲)한 존재로서 이는 기의 주재자이고, 기는 이의 기재(器材)라는 이기론(理氣論)의 입장을 체계화하여 이통기국설(理通氣局說) 및 기발이승론(氣發理乘論)을 주장하였다. 또한 사단(四端)과 칠정(七情)에 대하여는 이황의 사단이발설(四端理發說)을 비판하고 사단칠정이 모두 기발이승이라고 주장하였다. 그는 철학에만 조예가 깊었던 것이 아니라 정치·경제·교육·국방에 대해서도 깊은 관심과 탁월한 방책을 제시하였다. 동서붕당의 조정을 위한 노력, 보국안민(保國安民)을 위한 양병론(養兵論), 폐법(弊法)의 개혁을 위한 상소, 노예의 속량(贖良)과 서얼들의 통허(通許), 향약(鄕約)·사창(社倉)의 장려, 교육의 쇄신, 경제사(經濟司) 설치의 제안 등은 모두 국리민복을 위한 그의 포부와 국량을 보여주는 것이다. 선조의 묘정(廟庭)과 문묘에 배향되었고, 파주의 자운서원, 강릉의 송담서원(松潭書院), 풍덕(豊德)의 구암서원(龜巖書院), 황주(黃州)의 백록동서원(白鹿洞書院) 등 전국 20여 개의 서원에 배향되었다. 저서에 《율곡전서(栗谷全書)》가 있다. 시호는 문성(文成).
자운서원 입구
서원 내부
역시 서원 내부
서원 내부
서원을 둘러싸고 있는 담장
서원의 가장 안쪽 이곳에서 제를 올린다고 함.
자운서원 묘정비를 한글로 번역한 비문
자운서원 묘정비
서원 내부 전경
서원 내부의 260년된 느티나무
서원 앞쪽에 위치한 호수
율곡 이이 기념관 내 신사임당의 그림으로 만든 병풍
신사임당의 비단 자수 병풍
신사임당의 그림
신사임당 초상화
율곡 이이 초상화
Read Less...
Posted by:
shinny
Filed under:
Blogging
Friday, June 01, 2007
Friday, June 01, 2007 01:15 PM
comments (0) |
trackback (0) |
Permalink
1년 7개월 동안 사무실로 사용하던 오피스텔의 인터넷회선은 KT 엔토피아, 처음엔 속도도 잘나오고 공유기에 물려 컴퓨터 여러대를 잘 사용했었다.
문제는 수시로 접속이 끊어지더니, 근 한달정도를 말썽을 일으켜서 A/S를 받았었고, 오피스텔을 지인이 사용을 원해서 빌려주려고 임대계약을 할 즈음 2~3개월은 접속조차도 되지 않았다. 이런 이유로 3월말 KT측에 해지를 요구했고, 4월 초 담당자 왈 ‘일단 요금이 안나오도록 일시정지를 해 놓고, KT의 라인이상이나, KT 장비의 이상으로 문제가 된 경우라 확인이 되면 위약금이 없이 해지가 가능하며, 확인결과 KT의 과실이 없다면, 1년 7개월 동안(3년 계약으로 할인 받고 있었다.) 감면 받은 금액을 위약금으로 내야한다’ 라고 통화를 했고 해지에 필요한 신분증 사본 등을 보내 주었다.
문제는 5월말 통장 정리를 하던 중, KT에서 101,570원이 빠져나가 버린 것이 었는데, 당장 KT고객센타로 확인해 보니, KT에서 아무런 통보도 없이 위약금으로 고객의 동의도 구하지 않고 통보도 없이 처리를 해 버린 것이 었다.
예전 통화했던 KT 해당 영업소 담당자를 찾아 통화한 내역을 따져 물었더니, KT장비나 라인이상을 확인도 안하고, 위약금 처리를 해 버린 것이었다. 이런 신발놈들, 전화로 1시간을 넘게 옥신각신 한 끝에 환불해 주겠다는 약속을 받긴 했지만, 반복되는 말도 안되는 이야기와 거짓말로 얼버무리는 KT 직원이 안쓰럽기도 했지만, 고객과의 약속을 저버리고, 고객의 통장을 지맘대로 인출한 것은 분명 시정해야 하겠다.
잘가는 모 커뮤니티 사이트에서 KT 해지와 관련된 위와 같은 글을 자주 보았었는데 나에게도 이런 일이 일어날 줄은..... 암튼 KT와는 아래 부가사용료 건과 같은 나쁜 기억만 있다.
황당한 KT의 부가사용료
Posted by:
shinny
Filed under:
Blogging
Wednesday, May 30, 2007
Wednesday, May 30, 2007 11:30 PM
comments (0) |
trackback (0) |
Permalink
5월 11일 이천 출장 중 잠시 들러본 이천 도자기 축제 현장.
이천 IC에서 축제현장인 설봉공원까지 상당한 거리임에도 행사장까지 안내표지판이 곳곳에 붙어 있어 쉽게 찾을 수 있도록 배려해 주었고, 메인 행사장만 아니면 입장료도 무료, 물론 메인 행사장이 아나어도 도자기 축제를 충분히 둘러 보고 체험할 수 있다. 주차장도 상당히 넓은 편이어서 주차 문제도 없고, 평일임에도 의외로 가족단위로 도자기 축제를 즐기는 분들이 많았다.
차를 마시고 도자기를 가져갈 수 있도록한 카페, 도자기 만들기 체험, 다기를 이용한 전통차 체험장, 특색있는 도자기 전시와 판매, 도자기를 이용해 만든 오카리나 공연, 경기 경찰 홍보단의 공연 등등 볼 것도 풍부하고 체험도 할수 있도록 많은 준비를 한듯 보였다.
물론 생각보다 그렇게 큰 규모의 행사는 아니었지만, 올해로 4회째인 점을 감안하면 많은 점수를 주고 싶다.
또하나 아쉽게도 카메라 베터리가 방전되어 멋진 도자기 사진들을 찍을 수 없었다. T.T
Posted by:
shinny
Filed under:
Blogging
Tuesday, March 13, 2007
Tuesday, March 13, 2007 10:52 PM
comments (0) |
trackback (0) |
Permalink
Computers have been playing a role in the business environment for more than four decades. Throughout that time, the roles of the client and server have been constantly evolving. As businesses and their employees have become more comfortable delegating responsibilities to computers, the look, feel, and architecture of computerized business applications have changed to meet the new demands. This evolving process continues today, as businesses are demanding faster, lighter, and richer Internet applications. In this lesson, you will learn about this evolving nature and understand the business requirements that push us to build rich Internet applications (RIAs).
Understanding the Evolution of Computer Applications
In the earliest days of computerized business applications, all processing took place on mainframes, with the client having no role other than to display information from the server and accept user input. This was largely dictated by the high cost of processing power. It simply was not affordable to spread powerful clients throughout the enterprise, so all processing was consolidated, and "dumb terminals" provided the user interaction.
As memory and processing power became cheaper, dumb terminals were replaced by microcomputers (or personal computers). With the added power available, more desktop applications, such as word processors and spreadsheets, could run stand-alone, so no server was necessary. One challenge faced by organizations with microcomputers was a lack of centralized data. Although the mainframe era had everything centralized, the age of the microcomputer distributed everything, adding many challenges for centralizing business rules and synchronizing data across the enterprise.
To help resolve this issue, several vendors released platforms that sought to combine the strengths of the microcomputer with those of the mainframe, which led to the birth of client/server systems. These platforms afforded end users the power and ease of microcomputers while allowing for business logic and data to be stored and accessed from a centralized locationwhich solved the problems of the day. The new challenge introduced with the client/server systems was distribution. Any time changes needed to be made to client applications, IT departments had to manually reinstall or upgrade the software on every single desktop computer. Many companies found they needed a full-time staff whose primary responsibility was keeping the software on the end users’ desktops current.
With the explosive growth of the Internet in the 1990s, a new model for business applications became available. This model worked by having a web browser act as a thin client, whose primary job was to render HTML and send requests back to an application server that dynamically composed and delivered pages to the client. This is often referred to as a "page-based architecture." This model successfully solved the distribution problem of the client/server days; the application was downloaded from the server each time an end user needed it, so updates could be made in a single centralized place and automatically distributed to the entire user base. This model was and continues to be successful for many applications; however, it also creates significant drawbacks and limitations. In reality, Internet applications bore a great resemblance to mainframe applications, in that all the processing was centralized at the server, and the client only rendered data and captured user feedback. The biggest problems with this surrounded the user interface (UI). Many of the conveniences that end users grew to accept over the previous decade were lost, and the UI was limited by the capabilities of HTML.
For example, desktop software as well as client/server applications frequently use the drag-and-drop feature. However, HTML (Hypertext Markup Language) applications almost never use the feature, due to the complexities and lack of cross-browser support for the DHTML (Dynamic HTML), which it requires to implement in a pure HTML/DHTML solution.
In most cases the overall sophistication of the solutions that could be built and delivered was greatly reduced. Although the web has offered great improvements in the ease and speed of deploying applications, the capabilities of web-based business applications took a big step backward because browser-based applications had to adapt to the limitations of the web architecture: HTML and Hypertext Transport Protocol (HTTP).
Today, the demands for Internet-based applications continue to grow and are often quite different from the demands of the mid-1990s. End users and businesses are demanding more from their investments in Internet technology. The capability to deliver true value to users is forcing many companies to look toward richer models for Internet applications; models that combine the media-rich power of the traditional desktop with the deployment and content-rich nature of web applications.
As Internet applications begin to be used for core business functionality, the maintainability of those applications becomes more crucial. The maintainability of an application is directly related to the application’s architecture. Sadly, many web applications were built with little thought about the principles of application architecture, and therefore they are difficult to maintain and extend. Today, it is easier to build a solid architecture for an application by providing a clean separation between the business, data access and presentation areas, with the introduction of elements such as Web Services, service-oriented architecture (SOA) became more feasible for web-based applications.
To meet the demands of businesses, RIAs should be able to do the following:
Provide an efficient, high-performance run time for executing code, content, and communications. In the next section of this lesson, you will explore the limitations of the standard HTML-based applications, and learn that the traditional page-based architectures have a number of performance-related challenges.
Provide powerful and extensible object models to facilitate interactivity. Web browsers have progressed in recent years in their capability to support interactivity through the Document Object Model (DOM) via JavaScript and DHTML, but they still lack standardized cross-platform and cross-browser support. Building RIAs with these tools so they will work on a variety of browsers and operating systems involves building multiple versions of the same application.
Enable using server-side objects through using Web Services or other similar technologies. The promise of RIAs includes the capability to cleanly separate presentation logic and user interfaces from the application logic housed on the server.
Enable use of the applications when "offline." As laptops and other portable devices continue to grow in popularity, one of the serious limitations of Internet applications is the requirement that the machine running the application be connected to the Internet. Although users can be online the vast majority of the time, business travelers know there are times when an Internet connection is not currently possible. A successful RIA should enable users to be productive with or without an active connection.
Breaking away from the Page-based Architecture
For experienced web developers, one of the biggest challenges in building RIAs is breaking away from a page-based architecture. Traditional web applications are centered on the concept of a web page. Regardless which server-side technologies (if any) are used, the flow goes something like this:
1. User opens a browser and requests a page from a web server.
2. Web server receives request.
3. (optional) Web server hands request to an application server to dynamically assemble page or
4. (optional) Web server retrieves static page from file system.
5. Web server sends page (dynamic or static) back to browser.
6. Browser draws page in place of whatever was previously displayed.
Even in situations when most of the content of the previous page is identical to the new page, the entire new page needs to be sent to the browser and rendered. This is one of the inefficiencies of traditional web applications: each user interaction requires a new page loading in the browser. One of the key goals of RIAs is to reduce the amount of extra data transmitted with each request. Rather than download an entire page, why not download only the data that changed and update the page the user is viewing? This is the way standard desktop or client/server applications work.
Although this goal seems simple and is readily accepted by developers taking their first plunge into RIA development, often web developers bring a page-based mindset to RIA applications and struggle to understand how to face the challenges from the page-based world, such as, how to "maintain state." For example, after users log in, how do we know who they are and what they are allowed to do as they navigate around the application?
Maintaining state was a challenge introduced by web-based applications. HTTP was designed as a stateless protocol, in which each request to the server was an atomic unit that knew nothing about previous requests. This stateless nature of the web allowed for greater efficiency and redundancy because a connection did not need to be held open between the browser and server. Each new page request lasted only as long as the server spent retrieving and sending the page, allowing a single server to handle far more simultaneous requests.
The stateless nature of the web added challenges for application developers. Usually, applications need to remember information about the user: login permissions, items added to a shopping cart, and so on. Without the capability to remember this data from one request to the next, true application development would not be possible. To help solve this problem, a series of solutions was implemented; revolving around a unique token being sent back to the server with each request (often as cookies, which are small text files containing application specific identifiers for an individual user) and having the server store the user’s information.
Unlike traditional web applications, RIAs can bypass many of these problems. Because the application remains in client RAM the entire time it’s being used (instead of being loaded and unloaded like a page-based model), variables can be set once and accessed throughout the application’s life cycle.
A different approach to handling state is just one of many places in which building applications requires a slightly different mindset than web application development. In reality, web-based RIAs bear more resemblance to client/server applications than they do to web applications.
Identifying the Advantages of Rich Internet Applications
Unlike the dot-com boom days of the mid-to-late 1990s, businesses are no longer investing in Internet technologies, simply because they are "cool." To succeed, a new technology needs to demonstrate real return on investment and truly add value. RIAs achieve this on several levels: they reduce development costs; and add value throughout the organization.
Business Managers
By making it easier for users to work with software, the number of successful transactions is increasing. This increase occurs across many industries and can be quantified by businesses with metrics, such as increased productivity using intranet applications or increased percentage of online shoppers who complete a purchase. More productive employees can drastically reduce labor costs while growing online sales increase revenue and decrease opportunities lost to competitors.
IT Organizations
Breaking away from page-based architectures reduces the load on web servers and reduces the overall network traffic. Rather than transmitting entire pages over and over again, the entire application is downloaded once, and then the only communication back and forth with the server is the data to be presented on the page. By reducing server load and network traffic, infrastructure costs can be noticeably lower. RIAs developed using sound architectural principles and best practices can also greatly increase the maintainability of an application, as well as greatly reduce the development time to build the application.
End Users
End users experience the greatest benefits of RIAs. A well-designed RIA greatly reduces users’ frustration levels because they no longer need to navigate several pages to find what they need nor have to wait for a new page to load before continuing to be productive. Additionally, the time users spend learning how to use the application can be greatly reduced, further empowering them. Today, there are a number of excellent applications, which would not be possible without the concepts of an RIA, such as the Harley Davidson Motorcycle Configurator and the Kodak EasyShare Gallery applications. These easy to use applications give an excellent example of the ease of use an RIA can offer an end user.
Read Less...
Posted by:
shinny
Filed under:
Programming
절의 처마 끝에 매달아 바람에 소리가 나도록 만든 풍경처럼, 도자기로 만든 종을 매달아 바람에 종소리가 나도록한 조형물인 "소리나무"를 찍고나서 방전되 버린 베터리.........
