기사 보기

첫째로 부패에 대해서, 막말이나 갑질에 대해 단호한 분,
두번째로는 이분법적 사고를 가지지 않으신 분, 낡은 진보 청산에서 순혈주의, 폐쇄주의, 온정주의, 우리 편만 봐주는 이중잣대를 가지지 않으신 분이 필요하다
세번째로 합리적이고 개혁적인 보수가 아니라 수구적인 보수 편에 서신 분들이면 곤란하다. 수구 보수적인 편에 서지 않는 분이면 어떤 분과도 함께 손을 잡고 나갈 생각

안철수가 말한 같이 정치를 하고 싶은 사람들이다. (인재 영입 3원칙)

내가 안철수에 대해 가졌던 기대는 보수로 부터도 거리가 멀고 민주로 부터는 더더욱 거리가 먼 새누리당의 수구 세력들로부터 합리적인 보수를 구해내 주는 것이었다.

기본적으로 현재 한국의 양당은 지역주의를 기반으로 나뉘어졌고 새누리는 겉으로만 보수를 내걸었지 실질적으로는 반헌법 수구 세력이 기득권을 잡고 있다.
그리고 보수라고 할 수 있는 사람들은 비겁하게 그 수구 세력들에 꼬랑지 흔들며 밉보이지 않음으로서 자신의 정치생명을 구걸하는 것이 보편화 돼 있다.

반면 민주당은 개혁적인 이미지를 가지고 싶어 하지만 실질적으로는 이 수구 세력에 반대하는 보수들 + 경상도 정권에 반대하는 사람들 + 진보를 추구하는 세력들의 짬뽕이다.
또한 자신이 진보적 입장이라고 생각하는 자들 중에서도 내편 네편 갈라서 내쪽은 옳고 상대편은 그르다는 단순 논리를 전개하는 반 공화적인 행태를 보이는 사람들도 많다. (나는 이것이 반 공화 세력에 대항하다가 그 괴물을 닮아버린 낡은 진보의 구린내로 느껴진다)

내가 안철수에 가졌던 기대는 새누리당 안에 있는 자괴감에 빠진 합리적인 보수들이 수구세력과 결연히 갈러서고 나와서 갈 수 있는 정치적 토대를 만드는 것이었다.
그러면 더불어서 경상도 정권에 반대하기 때문에 들어온 민주당의 보수 세력들도 같이 참여할 수 있을 것이다.

그럼으로서 수구로부터 결별한 보수 세력이 제대로 서야 그에 대응하는 진보세력이 지역주의라는 굴레속에서 더렵혀진 본연의 모습을 제대로 찾을 거라고 믿는다.

그렇기 때문에 나는 정치적인 위치는 진보쪽에 서겠지만 안철수에게 제대로 된 보수 정치 세력을 기대하고 있는 것이다.
이것은 진보세력이 독자적인 힘으로는 지역주의와 수구 이념주의를 헤쳐나올 능력을 못 보여줬기 때문이다.

그래서 나는 안철수가 민주당에 있는 것이 몸에 맞지 않는 옷을 입고 있는 사람을 보는 것 처럼 껄끄러웠다.

내가 보기엔 안철수는 보수에 가장 큰 방점을 찍고 있다.
그렇기 때문에 그는 현장에 없었다. 집회에 참가한 국민들 옆에 그는 없었고 세월호 가족들이 도움을 호소할 때도 그는 없었고 거기에 대해 한마디도 언급한게 없다.

그래서 안철수 주위에 뭔가 진보적인 위치에 있는 사람들이 꼬이는 걸 보고 머뜩치 않아 했다.
기본적으로 그는 보수주의자인데 왜 진보를 내세우는 자들이 꼬이는가..
새정치를 바라는 국민의 여망에 자기 숟가락 얹을려는 꼼수에 지나지 않는다.
오히려 MB 진영 출신이 그 옆에 있는게 훨씬 더 자연스러운 모습니다.

안철수가 두번째로 방점을 찍고 있는 부분은 합리적인 경제 구조에 대한 것으로 보인다.
이 부분은 안철수가 말한 인재 영입 3원칙에는 나오지 않는다.
그 만큼 현재의 한국 정치판이 국민들의 먹고 사는 문제 (경제) 보다는 자기들의 정치적 기득권 싸움에 혈안이 돼 있기 때문이 아닐까 싶다.

하여간 그는 재벌들이 독식함으로서 중소기업들의 다양한 도전과 성공을 가로막는 현재의 재벌 편향적인 경제구조에 반대를 해 왔다.

이 것은 보수 대 진보의 정계개편이 이뤄지면 그 둘이 함께 개혁해 나갈 수 있는 공집합이 될 수 있다고 본다.

내가 판단하는 안철수는 이런 정치/경제 적인 마인드를 가지고 있는 사람이다.
그에게 남북문제 즉 우리 민족이 나아갈 방향 이라던가 세계를 바라보는 정치철학 같은 것은 보이지 않는다.
정치 능력을 봤을 때 그는 그렇게 썩 훌륭한 정치인이 될 기본 토대는 못되는 인물인것 같다.

우선 순위는 진짜 보수대 진보의 정치 프레임을 만듬으로서 반헌법 수구 세력과 전혀 공화적이지 않은 야권 세력에 매달려 있는 정치발전 저해세력들을 아웃사이더로 만드는 일일 것이다.

거기에 있어서 안철수는 아직 중요한 역할을 해 낼 가능성이 있다.
나는 거기에 기대를 건다.

이번에 안철수가 말한 인재 영입 3원칙이 나의 그 기대를 앗아갈 만한 내용이 아니라서 오히려 반갑다.

그런데 동시에 내년 총선과 다음 대선을 보면 답답하기도 하다.

아침부터 너무 정치에 시간을 많이 빼앗겼다.
이제 남은 시간은 그런거 잊고 오늘 할 일이나 열심히 해야겠다.

What a QA engineer does
QA 엔지니어가 하는 일

    Write test plans from the requirements, specifications and test strategies
    Use versioning systems to code test scripts
    Create and perform test campaign whenever it is necessary to fit in the overall planning
    Use bug tracking database to report bugs
    Analyses test results
    Reports results to the QA manager
    Raise an alert when an important issue is likely to put in jeopardy the whole project
   

    요구조건, 명세서 그리고 strategy 에 근거해 Test Plan을 만든다.
    test script를 코딩할 때 versioning (형상관리) system (CVS) 을 사용한다.
    전체 계획에 맞게 각 개발 단계마다 테스트 업무를 생성하고 진행한다.
    버그를 보고 하기 위해 버그 tracking database를 사용한다.
    테스트 결과를 분석한다.
    QA manager에게 결과를 보고한다.
    전체 프로젝트에 악영향을 끼칠만한 주요한 문제가 발견 되면 신속하게 보고하고 대처한다.

    What makes a good QA Engineer
무엇이 좋은 QA 엔지니어를 만드는가

Broad understanding of the product
제품에 대한 넓은 이해

To test efficiently a product, the QA engineer must know it well enough. This sounds obvious must unfortunately, this is often under-estimated. Knowing well the product includes also knowing how end-users expect it to work. Again this may sound obvious but remember that the biggest part in testing is black-box testing. The QA engineer must have a "customer-focus" vision.


제품을 효율적으로 테스트하기 위해서 QA엔지니어는 그 제품을 잘 알아야 한다. 당연하게 들릴 지 모르겠지만 불행히도 이 사실이 종종 과소평가된다. 제품을 잘 안다는 뜻은 최종 소비자(일반 사용자)의 기대치를 잘 이해하는 것도 포함된다. 너무나 당연한 얘기이지만 꼭 기억해야 할 것은 테스트 중에 제일 큰 부분이 블랙 박스 시험이라는 것을 기억하라. QA 엔지니어는 "고객에게 맞춘" 시선을 가져야 한다.

  But a good QA engineer must also know how the product is designed because the more you know the product, the better you're able to test it. However, the QA engineer will have to analyse the design only after his black-box testplan is completed. Indeed, knowing the design can widely influence the test strategy. It is better to first write the test plan with a high-level vision, then getting more and more information to refine the testing.


좋은 QA 엔지니어는 제품이 어떻게 디자인 되었는지 알아야 한다 왜냐하면 제품에 대해 더 잘 알수록 그것을 더 잘 테스트 할 수 있기 때문이다. QA 엔지니어는 그의 블랙박스 시험 계획이 완성된 후에 디자인을 분석해야 한다. 실제로, 디자인을 아는 것이 시험 전략에전반적인 영향을 미친다. 높은 레벨의 관점에서 test plan을 먼저 쓴 다음에, testing을 refine 하기 위한 좀 더 많은 정보들을 얻는 것이 좋은 방향이다.

Effective communication
효과적인 커뮤니케이션


Communication is an extremely important skill for a QA engineer. Of course, meetings (stand-up etc.) and status reports are part of the communication but more importantly, a QA engineer must be particularly efficient in the following tasks:

커뮤니케이션은 QA엔지니어에게 너무나도 중요한 기술이다. 당연히, 회의(stand-up 등)나 상황 보고는 커뮤니케이션의 일부인데, 더 중요한 것은 QA 엔제니어는 밑에 적힌 것들에 특히 더 능률적이어야 한다.    

    Direct communication with both Development and Product definition teams
    Capability to communicate with technical and non-technical people
    Having the diplomacy to say "no" when a bug is considered as not fixed
    Having the diplomacy to communicate about a bug without "offensing" the developer. Developers may often feel offensed when a bug is submited. This is 100% natural. This is why the QA engineer must have the ability to "criticize without offensing"
    Do not rely on "bug tracking" database for communication! there is nothing better that a bug tracking system to create "misunderstanding" between Development and QA teams


    개발, 제품 정의 팀과 직접적인 소통
    기술자들과 기술자가 아닌 사람들과 소통하는 능력
    버그(오류)가 고쳐지지 않은 것으로 간주될 때 "안된다(고쳐지지않았다)"라고 말할 수 있는 외교능력
    버그에 대해 이야기 할 때 개발자를 공격하지 않고 소통하는 외교능력.
    오류가 발견되었을 때 개발자들은 기분이 좋지 않을 수 있다. 이건 100% 자연스러운 일이다. 이것이 바로 QA 엔지니어가 (남을) 깎아내리지 않으면서 비평할 수 있는 능력을 가져야 하는 이유다.
    소통할 때 버그 추적 데이터베이스에 의지하지 마라! 버그 추적 시스템은 개발자와 QA 팀 사이에 오해를 만들기에 더 없이 좋은 시스템이다.



Creativity
창의성


Testing requires a lot of creativity. Bugs are often hidden and just performing the obvious positive tests will have only a few chances to actually find bugs. Hence, the QA engineer must use its creativity to figure out all the scenarios that are likely to detect a bug. In other words, the QA engineer must be able to "see beyond the obvious".


시험은 많은 창의성을 요구한다. 버그는 종종 숨어있을 때가 많고 positive test만을 실행하면 실제로 버그를 찾을 확률은 적어진다. 그러므로, QA 엔지니어는 그들의 창의성을 이용해 버그를 발견할만한 모든 시나리오를 알아내야 한다. 다른 말로 하면, QA 엔지니어는 "see beyond the obvious" 할 줄 알아야 한다.

Development knowledge
개발 지식


Quality Assurance requires knowledge about software development for two basic reasons:

품질 보증은 두가지 이유로 소프트웨어 개발에 대한 지식을 요구한다.    

    Development capabilities are required to eventually code automated tests
    If you know how to develop, you have better ideas on what is "dangerous" to code, so what to test more thoroughly


    automated tests를 코딩할 때 개발 능력이 필요하다.
    개발할 줄 알면, 코드화할 때 무엇이 위험한지를 좀 더 잘 이해할 수 있다. 그래서 무엇을 더 철저하게 테스트 해야하는지 알 수 있다.

Driving for results
결과를 위해 노력하기


A good QA engineer never forgets that the ultimate goal is not only to find bugs but also have them fixed. Once a bug has been found and has been "acknowledged" by the development team, the QA engineer may be required to "convince" people to fix it.


좋은 QA 엔지니어는 최후 목적이 버그를 찾는 것만이 아니라 그것을 고칠 때 까지 관리해야 하는 것이다. 버그가 발견되어 개발팀이 알려주면, QA 엔지니어는 사람들에게 그것은 고쳐야 되는 것이라는 것을 계속 고지시켜야 한다.

     Additionally, getting a nice automation framework with smart tools does not bring anything if it does not find any bug at the end.


또한, 아무리 좋은 툴이 겸비된 자동화 프레임워크이라도 그것이 버그를 찾을 수 없다면 아무 의미가 없다.

    Ask yourself if the automation is going to help to find more bugs and when
    Prioritize your testing tasks on the only important criteria
        How many bugs is this likely going to find?
        How major will be the found bugs (detecting thousands of cosmetic bugs is irrelevant/useless - and often easy - until all major/show-stopper bugs have been found)?


    자신에게 이 자동화(自動化)가 더 많은 버그를 찾는데 도움이 될것인지 물어보라. (언제발견될지도)
    당신의 testing 세부 task 들을 중요한 분야별로 나누어 우선순위를 정하라
        이것이 얼마나 많은 버그를 찾을 것인가?
        발견된 버그가 얼마나 중대한(큰) 것인지(자잘한 버그를 수천개 찾는 것보다 크고(중요하고) 시급한 버그를 찾는 것이 더 의미 있다)

카산드라에서 사용되는 주요 개념들 정리해 보겠습니다.

Key concepts and data model

Key concepts

The following concepts are important for understanding Cassandra:

Cluster
    A group of nodes where you store your data. In this guide, you create a single-node cluster.
   
    데이터를 저장하는 노드들의 그룹이다.

   
Replication

    The process of storing copies of data on multiple nodes to ensure reliability and fault tolerance. The number of copies is set by the replication factor.

    여러 노드들에 데이터의 복사본을 저장하는 프로세스. 이렇게 함으로서 안정성과 fault tolerance (내고장성 耐故障性)을 보장할 수 있다. 복사본의 수는 replication factor에 의해 세팅된다.

   
Partitioner

    A partitioner distributes data evenly across the nodes in the cluster for load balancing.

    partitioner는 로드발란스를 위해 클러스트에 있는 노드들에 데이터가 고르게 분산되도록 조절한다.

   
Data Center
   
    A group of related nodes configured together within a cluster for replication purposes. It is not necessarily a physical data center. In DataStax Enterprise, the term related nodes refers to the type of node: transactional, analytics, search. Each type of node must be contained in its own data center.
   
    replication을 위해 클러스트 안에 설정된 연결된 노드들의 그룹이다. 꼭 물리적인 데이터 센터로 구분될 필요는 없다. DataStax Enterprise에서는 transactional, analytics, search 등의 노드 타입과 관련된 노드들을 가리킨다. 각 노드의 타입은 속해있는 데이터 센터에 포함돼 있어야 한다.

   
Links to related information in Cassandra

• Cassandra key features
• Cassandra Architecture

   
The data model distilled


Cassandra is a partitioned row store. It is an open-source, distributed-database system that is designed for storing and managing large amounts of data across commodity servers.

카산드라는 분할된 행의 저장공간이다. 오픈소스이며 범용서버에서 대량의 데이터를 저장하고 관리하기 위해 디자인된 분산 데이터베이스 시스템이다.


You design the data model

    The design of the data model is based on the queries you want to perform, not on modelling entities and relationships like you do for relational databases.

    데이터 모델의 디자인은 실행하고자 하는 쿼리에 기반한다. modelling entity 와 relationship에 기반한 관계형데이터베이스와는 다르다.

   
Column family
   
    In general, the term Table has replaced Column family. A Cassandra database consists of column families. A column family is a set of key-value pairs. Every column family has a key and consists of columns and rows. You can think of column family as a table and a key-value pair as a record in a table.
   
    일반적으로 얘기하는 Table은 카산드라에서는 Column family 가 그 역할을 한다. 카산드라 데이터베이스는 이러한 column family들로 구성된다. column family는 key-value pair들로 구성 돼 있다. 각 column family는 key와 column/row 들로 구성돼 있다. 이 column family는 관계형데이터베이스에서의 table 이라고 생각하면 된다. 그리고 key-value pair는 테이블의 record라고 생각하면 된다.
   
    Note: In CQL 3 (the latest implementation of the Cassandra Query Language), column families are called tables. The Cassandra CLI client utility (deprecated) , API classes, and OpsCenter continue to use column family.
   
    Note : CQL3에서는 column family를 table 이라고 부른다. Cassandra CLI client utility (deprecated) , API classes, 그리고  OpsCenter 에서는 계속 column family라고 부른다.

   
Table
   
    The definition of a table depends on the version of CQL:
   
    table에 대한 정의는 CQL 버전에 의존한다.

   
        In CQL 3, a table is a collection of ordered (by name) columns.
        In previous versions of CQL, a column family was synonymous, in many respects, to a table. In CQL 3 a table is sparse, which means it only includes columns for rows that have been assigned a value.

        CQL 3에서는 name에 의해 정렬된 column들의 집합이다.
        그 이전 버전의 CQL 에서는 column family는 table 과 거의 동의어로 사용됐다. CQL 3 에서 table은 값이 할당된 row들에 대한 column들을 포함하고 있다는 의미가 들어있다.

     
Keyspaces
   
    The outermost grouping of data, similar to a schema in a relational database. All tables go inside a keyspace. Typically, a cluster has one keyspace per application.
   
    outermost grouping of data 로 관계형 데이터베이스의 Schema 와 비슷하다. 모든 테이블들은 keyspace 안에 있게 된다. 일반적으로 어플리케이션 당 하나의 클러스터는 하나의 keyspace를 갖는다.
   

http://www.slideshare.net/planetcassandra/apache-cassandra-and-datastax-enterprise-explained-with-peter-halliday-at-wildhacks-nu

   
Snitches
   
    Snitch는 어떤 데이터센터와 rack 에 write 하고 read 할 것인지 결정한다.

   
Gossip = Internode Communications
   
    매 순간 어떤 노드와 정보를 exchange 할 것인지에 대한 peer to peer communication protocol
    카산드라는 이 gossip을 카산드라 클러스터에 있는 다른 노드들에 대한 위치와 상태정보를 알아내는데 사용한다.


Vnodes (Vertual Nodes)   

    각 노드가 single token range를 가지는 대신 Vnode는 각 노드를 많은 range (256) 로 나눈다.

그리고 회의 하다가 나온 얘긴데 Spark 을 사용하면 테이블 간 join 사용 효과를 낼 수 있다고 합니다.
   
Apache Spark

        테이블간 join 할 수 있도록 해 준다.