Category: 웹.이.야.기.

P-Camp 그 두번째 만남 – 서로의 입장을 이해하고 존중하자

두번째 P-Camp 행사가 10월10일 코엑스 컨퍼런스 센터에서 개최됐다. P-Camp란 행사도 낯설고, 주로 토론으로 진행된다고 되어 있어서 토론에 서툰 나로서는 조금 망설여지기도 했지만 요즘 TDD에 관심이 많아서 과감히 신청을 했다. 선착순 300명이 정원이었는데 이미 300명이 차서 대기로 신청을 했는데 신청취소가 좀 있었서 참석할 수 있었다.
 
토론은 다음 이슈를 가지고 소그룹을 정해서 이루어졌다.
1. 웹 환경에서의 테스트
2. Agile 개발 방법론에서의 S/W 테스팅
3. 개발자와 테스터의 효율적이면서 인간적인 관계
4. 게임 산업에서의 자동화 테스팅
5. 국내 S/W 테스터들의 현재 주소와 앞으로의 위치
6. DB컨설턴트들의 경험담
7. 온라인게임에서의 테스트
8. 웹어플리케이션의 테스팅 자동화 방법
9. 임베디드시스템의 테스트
10. 테스트가 제대로 수행될 수 있는 기업 문화
11. 테스트의 중요성을 인식하고 잘 실행되고 있는 사례
12. 패키지 솔루션 기획과 테스트
13. 프로젝트 매니지먼트에서의 리스크 관리
14. 효율적인 교육과 여가활용 방안
15. Agile 개발팀에서의 테스팅의 단계와 적용사례
16. SI업체 속의 애자일문화
17. TDD로 개발을 하였을 때의 이점이 어느 정도 되는가
18. TDD의 실용 적용 방법과 그 과정의 어려운 점

난 8번 “웹어플리케이션의 테스팅 자동화 방법”을 선택했다. 18번을 선택하고 싶었지만 이게 토론인지라 TDD에 대해 아직 얘기할게 아무것도 없기에 마냥 들을 수만은 없어서 그래도 가장 많이 접하는 웹어플리케이션 관련 주제를 택했다.

사용자 삽입 이미지

우리조는 개발자와 QA 테스터 분들로 구성이 됐다. 처음에는 좀 서먹서먹 했지만 좀 지나니깐 많은 얘기들이 오고갔다. 자동화 툴이 어떤게 있으며, 각각의 장단점. 그리고, 원론적으로 자동화 툴이 왜 필요하냐 등….  역시나 서로 처한 입장이 많이 틀리고, 서로 그 입장을 이해하기 위해서는 많은 커뮤니케이션이 필요하다는 걸 다시 한번 절실하게 느꼈다.

회사에 급한일이 있어서 100분으로 예정된 토론을 마치지 못하고 중간에 나오게 되서 좀 아쉬웠다. 다음 DevNight이나 오픈마루 1st DevDay처럼 개발자가 참여하는 행사에만 참석하다가 다양한 도메인에서 일을 하는 분들을 만날수 있어서 좋았고, 처음 접한 토론 문화에 좀 어색하긴 하지만 괜찮은 경험이었다.

구글베이스와 MS Astoria 비교

Dare Obasanjo has done a comparison of two new protocols for accessing database style data via HTTP. These protocols, based on REST, are the Google Base and Microsoft’s Astoria.

The basic concept between the two protocols is the same. URLs are
used in lieu of SQL to specify queries. Relationships and filters must
be encoded as part of the URL and all requests are GETs.

The first difference pointed out by Dare is that Astoria uses a
hierarchical format to represent relationships. For example, to specify
that you wanted the orders for customer key 5 you would have something
like “/Customers[5]/Orders”. Google Base, on the other hand, uses a
flat model where categories and predicates have to be used to ferret
out relationships.

Both support filtering and sorting, but Google Base has a richer
syntax and support for full-text queries across all categories. Google
Base does get a bit carried away however, with support for inline
If/Else constructs.

Astoria does have a really nice feature called expand. It allows the
user to indicate they also want the children nodes for the data they
requested. This eliminates the need to perform 1+N queries to get a
collection of rows and the related child rows. The data comes back as
inline XML under the appropriate node.

Google Base likewise has some features not found in Astoria. For
example one can turn on spelling correction, which works in a manner
similar to Google Search. You can also filter out repetitive
information using the Crowd feature. In the article, Dare requested,
“all restaurants stored within Google Base but show no more than 2 per
cuisine type”.

Dare Obasanjo concludes:

In comparing both approaches there is a lot to like and dislike. I
like the “expand” feature in Astoria as well as the fact that I can
retrieve XML results from multiple paths of the hierarchy. However
there does seem to be a paucity of operators and functions for better
filtering of results.

From the Google Base data API, I love the “crowd” feature and having
a full library of functions for performing tests within predicates.
Also some of the operators such as the ones for finding results near a
certain location are quite impressive although unnecessary for the
majority of RESTful protocols out there. That said, I do think they
went overboard on some of the features such as having if…else blocks
within the URIs. I suspect that some of that complexity wouldn’t have
been needed if they just had hierarchies instead of a flat namespace
that requires complex filtering to get anything out of it.

출처: http://www.infoq.com/news/2007/07/GoogleBase-Astoria

구글도 로봇을 싫어하는군…

구글도 로봇이 날리는 검색에 대해서는 방어를 하고 있다..


The reason behind the “We’re sorry…” message



Posted by Niels Provos, Anti-Malware Team

Some of you might have seen this message while searching on Google, and wondered what the reason behind it might be. Instead of search results, Google displays the “We’re sorry” message when we detect anomalous queries from your network. As a regular user, it is possible to answer a CAPTCHA – a reverse Turing test meant to establish that we are talking to a human user – and to continue searching. However, automated processes such as worms would have a much harder time solving the CAPTCHA. Several things can trigger the sorry message. Often it’s due to infected computers or DSL routers that proxy search traffic through your network – this may be at home or even at a workplace where one or more computers might be infected. Overly aggressive SEO ranking tools may trigger this message, too. In other cases, we have seen self-propagating worms that use Google search to identify vulnerable web servers on the Internet and then exploit them. The exploited systems in turn then search Google for more vulnerable web servers and so on.  This can lead to a noticeable increase in search queries and sorry is one of our mechanisms to deal with this.

At ACM WORM 2006, we published a paper on Search Worms [PDF] that takes a much closer look at this phenomenon. Santy, one of the search worms we analyzed, looks for remote-execution vulnerabilities in the popular phpBB2 web application. In addition to exhibiting worm like propagation patterns, Santy also installs a botnet client as a payload that connects the compromised web server to an IRC channel. Adversaries can then remotely control the compromised web servers and use them for DDoS attacks, spam or phishing. Over time, the adversaries have realized that even though a botnet consisting of web servers provides a lot of aggregate bandwidth, they can increase leverage by changing the content on the compromised web servers to infect visitors and in turn join the computers of compromised visitors into much larger botnets. This fundamental change from remote attack to client based download of malware formed the basis of the research presented in our first post. In retrospect, it is interesting to see how two seemingly unrelated problems are tightly connected.


출처: http://googleonlinesecurity.blogspot.com/2007/07/reason-behind-were-sorry-message.html