더이상 부담 갖지 않는다! ㅋ

예전에는 게임만 하다 세월 다 보낼거 같아 게임을 잘 안했는데

이젠 게임도 해 주시면셔~ 셔~ 셔~ ㅋㅋ 일할 땐 일하고~ ㅋ 그러지요~

그래서 ~ 준비 했습니다~~ 최근에 제가 틈날때 즐기는 게임들 입니다. ^^

참고로 전 퍼즐류나 아케이드 게임 같은 단순 무식한 게임들을 좋아라 합니다. ㅋ

머리가 안좋은지 전략겜은 나빠요~

1. 스트레스는 가라~ 오락실도 워이~ 워이~
 나나이모가 간다~



얼마전 지스타 전시회 갔을 때 처음 해봤던 넥슨의 새 게임 나나이모~!

처음엔 무지 쉬워 보여서 좋아라 했는데, 요즘에 너무 힘들게 깨고 있다죠 ㅋ

아...~ 게임 하다 스트레스 쌓인답니다.~~ 크흐~ >.<

대체! 딱지는 왜이리 안 모아지는거얏! ㅋㅋ


2. 새로운 레이싱의 강자! 스키~~~드 러쉬!



우연한 기회에 스키드 러쉬라는 게임의 스크린샷을 보고 난 후

바로 수소문 끝에~ 한게임에서 슬며시 CBT를 진행중인 게임을 알게 됐다.

그 이름하여~ 스키드러쉬 ^^

사실 카트라이더가 재밌고 스피드 감도 있지만 워낙 초딩들이 판을 치는지라;;

게다가 카트를 많이 하진 않았지만 하다가 손 놓고 오랫만에 들어 갔더니

너무 실력차가 많이 나는지라, 초딩이라고 놀림을 받을 정도의 한심한 게임

카트... 이건 모; 게임을 하는건지 욕하러 온건지 ;;; ㅉㅉ 넥슨스럽긴;;


이런 느낌을 가지고 있던 레이싱 게임의 새로운 강자나 나타난듯 싶다.

달리는 느낌도 다르고 달려야 하는 이유(?)를 알면서 달리는 기분은

단순 초딩 게임의 수준을 벗어 난다고나 할까 ㅋㅋ

얼마전 부터 오픈베타1, 2 (현재 베타2 진행중)가 순차적으로 진행중이어서

짬날때마다 들어가서 실력을 쌓고 있다. 후후~


3. 사천성

제목 부터 포스가 느껴지나요? ㅎㅎㅎ

중국집 이름이냐구요? 네?... 짜장면 배달 게임요? ㅎㅎ 그건 더더욱 아닙니다.

마작이라고 아시는지요? 가볍게 점심때 한두판씩 하시면 스트레스도 풀리고

재밌답니다. ㅋㅋ 마작을 모르신다구요? 어렵다구요? ㅋ

첨엔 다 그런겁니다. ㅋㅋ 한번 해보세요! 색다른 재미를 느끼 실 겁니다.

오빠 믿지??? (응?! 퍽! >.< )

by Jesse James Garrett

February 18, 2005

If anything about current interaction design can be called “glamorous,” it’s creating Web applications. After all, when was the last time you heard someone rave about the interaction design of a product that wasn’t on the Web? (Okay, besides the iPod.) All the cool, innovative new projects are online.

Despite this, Web interaction designers can’t help but feel a little envious of our colleagues who create desktop software. Desktop applications have a richness and responsiveness that has seemed out of reach on the Web. The same simplicity that enabled the Web’s rapid proliferation also creates a gap between the experiences we can provide and the experiences users can get from a desktop application.

That gap is closing. Take a look at Google Suggest. Watch the way the suggested terms update as you type, almost instantly. Now look at Google Maps. Zoom in. Use your cursor to grab the map and scroll around a bit. Again, everything happens almost instantly, with no waiting for pages to reload.

Google Suggest and Google Maps are two examples of a new approach to web applications that we at Adaptive Path have been calling Ajax. The name is shorthand for Asynchronous JavaScript + XML, and it represents a fundamental shift in what’s possible on the Web.

Defining Ajax

Ajax isn’t a technology. It’s really several technologies, each flourishing in its own right, coming together in powerful new ways. Ajax incorporates:

• standards-based presentation using XHTML and CSS;
• dynamic display and interaction using the Document Object Model;
• data interchange and manipulation using XML and XSLT;
• asynchronous data retrieval using XMLHttpRequest;
• and JavaScript binding everything together.

The classic web application model works like this: Most user actions in the interface trigger an HTTP request back to a web server. The server does some processing — retrieving data, crunching numbers, talking to various legacy systems — and then returns an HTML page to the client. It’s a model adapted from the Web’s original use as a hypertext medium, but as fans of The Elements of User Experience know, what makes the Web good for hypertext doesn’t necessarily make it good for software applications.

Figure 1: The traditional model for web applications (left) compared to the Ajax model (right).

This approach makes a lot of technical sense, but it doesn’t make for a great user experience. While the server is doing its thing, what’s the user doing? That’s right, waiting. And at every step in a task, the user waits some more.

Obviously, if we were designing the Web from scratch for applications, we wouldn’t make users wait around. Once an interface is loaded, why should the user interaction come to a halt every time the application needs something from the server? In fact, why should the user see the application go to the server at all?

How Ajax is Different

An Ajax application eliminates the start-stop-start-stop nature of interaction on the Web by introducing an intermediary — an Ajax engine — between the user and the server. It seems like adding a layer to the application would make it less responsive, but the opposite is true.

Instead of loading a webpage, at the start of the session, the browser loads an Ajax engine — written in JavaScript and usually tucked away in a hidden frame. This engine is responsible for both rendering the interface the user sees and communicating with the server on the user’s behalf. The Ajax engine allows the user’s interaction with the application to happen asynchronously — independent of communication with the server. So the user is never staring at a blank browser window and an hourglass icon, waiting around for the server to do something.

Figure 2: The synchronous interaction pattern of a traditional web application (top) compared with the asynchronous pattern of an Ajax application (bottom).

Every user action that normally would generate an HTTP request takes the form of a JavaScript call to the Ajax engine instead. Any response to a user action that doesn’t require a trip back to the server — such as simple data validation, editing data in memory, and even some navigation — the engine handles on its own. If the engine needs something from the server in order to respond — if it’s submitting data for processing, loading additional interface code, or retrieving new data — the engine makes those requests asynchronously, usually using XML, without stalling a user’s interaction with the application.

Who’s Using Ajax

Google is making a huge investment in developing the Ajax approach. All of the major products Google has introduced over the last year — Orkut, Gmail, the latest beta version of Google Groups, Google Suggest, and Google Maps — are Ajax applications. (For more on the technical nuts and bolts of these Ajax implementations, check out these excellent analyses of Gmail, Google Suggest, and Google Maps.) Others are following suit: many of the features that people love in Flickr depend on Ajax, and Amazon’s A9.com search engine applies similar techniques.

These projects demonstrate that Ajax is not only technically sound, but also practical for real-world applications. This isn’t another technology that only works in a laboratory. And Ajax applications can be any size, from the very simple, single-function Google Suggest to the very complex and sophisticated Google Maps.

At Adaptive Path, we’ve been doing our own work with Ajax over the last several months, and we’re realizing we’ve only scratched the surface of the rich interaction and responsiveness that Ajax applications can provide. Ajax is an important development for Web applications, and its importance is only going to grow. And because there are so many developers out there who already know how to use these technologies, we expect to see many more organizations following Google’s lead in reaping the competitive advantage Ajax provides.

Moving Forward

The biggest challenges in creating Ajax applications are not technical. The core Ajax technologies are mature, stable, and well understood. Instead, the challenges are for the designers of these applications: to forget what we think we know about the limitations of the Web, and begin to imagine a wider, richer range of possibilities.

It’s going to be fun.

---

Ajax Q&A

March 13, 2005: Since we first published Jesse’s essay, we’ve received an enormous amount of correspondence from readers with questions about Ajax. In this Q&A, Jesse responds to some of the most common queries.

Q. Did Adaptive Path invent Ajax? Did Google? Did Adaptive Path help build Google’s Ajax applications?

A. Neither Adaptive Path nor Google invented Ajax. Google’s recent products are simply the highest-profile examples of Ajax applications. Adaptive Path was not involved in the development of Google’s Ajax applications, but we have been doing Ajax work for some of our other clients.

Q. Is Adaptive Path selling Ajax components or trademarking the name? Where can I download it?

A. Ajax isn’t something you can download. It’s an approach — a way of thinking about the architecture of web applications using certain technologies. Neither the Ajax name nor the approach are proprietary to Adaptive Path.

Q. Is Ajax just another name for XMLHttpRequest?

A. No. XMLHttpRequest is only part of the Ajax equation. XMLHttpRequest is the technical component that makes the asynchronous server communication possible; Ajax is our name for the overall approach described in the article, which relies not only on XMLHttpRequest, but on CSS, DOM, and other technologies.

Q. Why did you feel the need to give this a name?

A. I needed something shorter than “Asynchronous JavaScript+CSS+DOM+XMLHttpRequest” to use when discussing this approach with clients.

Q. Techniques for asynchronous server communication have been around for years. What makes Ajax a “new” approach?

A. What’s new is the prominent use of these techniques in real-world applications to change the fundamental interaction model of the Web. Ajax is taking hold now because these technologies and the industry’s understanding of how to deploy them most effectively have taken time to develop.

Q. Is Ajax a technology platform or is it an architectural style?

A. It’s both. Ajax is a set of technologies being used together in a particular way.

Q. What kinds of applications is Ajax best suited for?

A. We don’t know yet. Because this is a relatively new approach, our understanding of where Ajax can best be applied is still in its infancy. Sometimes the traditional web application model is the most appropriate solution to a problem.

Q. Does this mean Adaptive Path is anti-Flash?

A. Not at all. Macromedia is an Adaptive Path client, and we’ve long been supporters of Flash technology. As Ajax matures, we expect that sometimes Ajax will be the better solution to a particular problem, and sometimes Flash will be the better solution. We’re also interested in exploring ways the technologies can be mixed (as in the case of Flickr, which uses both).

Q. Does Ajax have significant accessibility or browser compatibility limitations? Do Ajax applications break the back button? Is Ajax compatible with REST? Are there security considerations with Ajax development? Can Ajax applications be made to work for users who have JavaScript turned off?

A. The answer to all of these questions is “maybe”. Many developers are already working on ways to address these concerns. We think there’s more work to be done to determine all the limitations of Ajax, and we expect the Ajax development community to uncover more issues like these along the way.

Q. Some of the Google examples you cite don’t use XML at all. Do I have to use XML and/or XSLT in an Ajax application?

A. No. XML is the most fully-developed means of getting data in and out of an Ajax client, but there’s no reason you couldn’t accomplish the same effects using a technology like JavaScript Object Notation or any similar means of structuring data for interchange.

Q. Are Ajax applications easier to develop than traditional web applications?

A. Not necessarily. Ajax applications inevitably involve running complex JavaScript code on the client. Making that complex code efficient and bug-free is not a task to be taken lightly, and better development tools and frameworks will be needed to help us meet that challenge.

Q. Do Ajax applications always deliver a better experience than traditional web applications?

A. Not necessarily. Ajax gives interaction designers more flexibility. However, the more power we have, the more caution we must use in exercising it. We must be careful to use Ajax to enhance the user experience of our applications, not degrade it.

Jesse James Garrett is President and a founder of Adaptive Path. He is the author of the widely-referenced book The Elements of User Experience. Jesse’s other essays include The Nine Pillars of Successful Web Teams and Six Design Lessons From the Apple Store.

To get essays like this one delivered directly to your inbox, subscribe to our email newsletter. For more, check out our blog.

벌써 2007년 이네요. ^^ 하루 하루 시간이 후쩍 가는군요 ^^

얼마전 2006년 씨애랑 송년회때 종로를 갔었드랬쬬 ^^

사실 회사 팀 송년회랑 시간이 겹치는 바람에 못 갈뻔 했는데, 다행히 그날 회사 종무식과 겹쳐

일찍 송년회를 마치고 올 수 있었다죠 ㅋㅋ

아마도 오비모임 안 갔으면 무척이나 아쉬웠을뻔 했는데... 정말 다행이었어요 ㅋㅋ

그동안 못 뵈었던 선배님들도 한번씩 뵙고.. 크흐...

이게 오비모임인지 분간을 할 수 없을 정도의 재학생 러쉬도 ㅋㅋ

좋았드랬죠~ ㅋㅋ

지난 2주간 대만과 중국에서 열심히 일한 회포를 풀기위해 술자리를 가졌다.

첨엔 인엽씨와 간단하게 맥주한잔 하자고 했던일이 계기가 되어 ㅋㅋ

대만지원 하면서 알게된 전혜씨가 합류했고,

GT팀의 명국씨와 태정(?)씨.. 까지 ㅋ

대만 지원할 때 새롭게 알게된 동료. 전혜씨~ 전보다 훨씬 ~ 날씬해 진거라며 사진까지 보여 주시다니 ㅎㅎ
나도 살빼려면... 술도, 밥도... 간식도 못 먹을거야... 아놔;; 나 그냥 먹고 살텨 ㅋㅋ

대만지원 때 일로 티격태격 하며 분위기 쏴해지신 두분 ㅋㅋ; 일 얘기는 그만~~ ^ㅡ^



두 분이 심각하게 대화를 나누는 동안 우린... 치킨과의 사투를 ㅎㅎㅎ



호오~ 역쉬.... 치킨을 좋아 한다는 태정씨... 후라이드 2마리와, 양념 한마리를 후딱 해치웠음 ㅋㅋ
아... 저날 저녁을 먹고 가는게 아니었는데 -_-;... 야근하다 가는 바람에 저녁을 먹고 일했더니
술자리에서 술을 제대로 못 마셨어요.. ㅠ.ㅠ

음... 역시 살은 빼고 봐야... ㅋㅋ
회사에서 젤 먼저 친해졌다고 해야 하나.. ^^ GT팀의 최인엽대리님..

아.. 나이와 달리 동안이시라.... 냠..
담부턴 사진 같이 찍음 안되겠어 >.<


1차를 대충 마무리 하고 2차까지 가서 달렸던 우리들 ㅋㅋ

역시 술자리는 2차까지는 기본이져? ^^

앞으로도 잘 부탁드립니다~~ ^ㅡ^*

어제밤부터 조금씩 내리던 눈이 어느새 수북히 쌓였네요.

일이 있어 회사에서 철야를 하고 새벽에 나오는데 눈이 내리는게 너무 좋길래.

바로 양재천으로 달려 갔습니다. ^^

전에 양재천 따라 산책을 한번 가본적이 있는데 그때 분위기가 너무 좋아 가끔씩 기억을 떠올리는데

눈이 덮힌 양재천 모습도 예술이었습니다. ^^


눈발은 날리고 손은 시렵고.. 아... 가뜩이나 떨리는 손이 오늘따라 더더욱 떨리더군요 ㅋ

양재천 산책로를 따로 조금 걷다 보니 운동화며 바지가 전부 젖어 버렸더군요. ^^;

오랜만에 눈덮인 풍경을 따라 걷다 보니 철야의 피로가 싸악~ 잊혀 드는 기분이었습니다.

이글이 티스토리에 첫번째 남기는 포스트인데.... 눈내리는 풍경까지 옵션으로 올리게 되어

좋습니다. ㅎㅎ 사진 조금 더 둘러보고 쓸만한(?) 사진들 정리해서 다시 올릴께요 ^ㅡ^*