프로그래머는 어떤 모자를 착용하지 않아야합니까? [닫은]


29

필자의 경험에 따르면 소프트웨어 개발자는 여러 모자를 쓰고 다른 책임으로 여러 역할을 수행하는 경향이 있습니다. 코딩뿐만 아니라 때로는 SQL 작성, 사용자 인터페이스 디자인, 데이터베이스 디자인, 그래픽 조작, QA 테스트까지.

소프트웨어 / 코드를 작성하는 것이 주된 역할이라면 개발자는 어떤 역할을 수행하지 않아야합니까? 거기 아무도 없나요?

이 질문의 목적은 개발자가 다른 역할을 수행 할 수 없기 때문이 아니라 추가 역할을하는 것이 실제로 기본 역할에 반하는 것이 거나 실제로 프로그래밍하지 않은 사람의 전담 역할이어야한다는 것입니다.


20
보닛 ... 아 잠깐만 ..
ChaosPandion

21
IMO 프로그래머는 테두리가 모니터에 계속 부딪 치기 때문에 큰 멕시코 솜브레로 중 하나를 착용해서는 안됩니다.
메이슨 휠러

1
@ 피터 터너 (Peter Turner) : '가장 멋진 프로그래머 모자'는 맥주 캔 2 개를 장착하는 참신한 직업 중 하나입니다. 맥주는 없습니다. 레드 불.
BlairHippo

4
조금도. 그러한 유망한 제목 ...
아무도

4
@Mason, 솜브레로를 모니터 위에 유지하면 광택이있는 화면에 반사되는 것을 막을 수 있습니다. 다시 말하면 기술입니다.

답변:


54

Sysadmin. 소프트웨어 개발 및 IT 인프라 처리는 외부인과 유사한 두 가지 기술 집합입니다. (모두 컴퓨터를 겨냥한 것입니까?) 소규모 회사의 경우 Computer Guy가 사무실의 모든 컴퓨터를 책임지게하는 유혹이 매우 강할 것입니다.

실제로 두 모자를 모두 착용 할 수있는 기술이 있다면 굉장합니다. 그러나 그것은 사람들이 알고있는 것보다 훨씬 더 많은 시간을 허비 할 수있는 것들 중 하나입니다. 만약 당신이 스스로 학습을한다면, 당신은 그것을 잘하지 못할 것입니다.


7
이. 컴퓨터에서 일한다고해서 인프라를 고칠 수있는 것은 아닙니다. 개발자의 시간을 낭비하고 있습니다.
Jaco Pretorius

5
아마추어 시스템 관리자가 입을 수있는 피해량은 +1입니다.
davidtbernal

그리고 sysadmin 모자를 받으면 시설 관리자 모자가 붙어있어 모든 비용을 피할 수 있습니다.
HLGEM

3
OTOH, 저는 무능하고 부진한 IT 부서가있는 회사에서 일하고 있습니다. 내가주지 못할 것이다 단지 ... 내 자신의 방화벽을 변경할 수합니다
게이브 Moothart

1
누군가 내 상사가 차려 입지 않았지만 컴퓨터를 설치하면서 바닥에서 더러워 질 것이라고 말했습니다. 그들은 내가해야한다고 지적했습니다. 나는 거의 책상 위로 뛰어 들어 목을 졸랐지만 커피를 마시고 하드웨어를하지 않는다고 언급했다.
JeffO

35

고용주가 요구하는 모자를 착용하십시오. 그것이 당신을 팀 플레이어로 만드는 것입니다. 그것이 당신을 문제 해결사로 만드는 것 입니다.

사람들은 "개발자", "건축가"또는 "분석가"라는 생각에 너무 익숙해 져 있습니다. 망쳐 문제 해결사가되어야합니다. 코드는 벨트의 도구 일뿐입니다.

문제 해결은 결코 스타일에서 벗어나지 않습니다.

고용주가 기술 지원이나 컴퓨터 구축을 원할 경우 그렇게하십시오. 개발자 급여를 고려하여 돈을 낭비하고 있다고 생각하지만 그것이 사업입니다. 나는 문제를 해결하기 위해 왔습니다. 그러나 나는 그렇게 할 수 있습니다. 그리고 일정 시간이 지나도 내 재능이 낭비되거나 직업 만족도가 원하는 곳이 아닌 것처럼 느껴지면 다른 직업으로 넘어갈 권리가 있습니다.

그러나 기본적인 질문에-당신이 입지 않는 모자는 없습니다. 도대체 그들이 커피를 가져 오길 원한다면 그렇게하세요. 그들의 문제를 해결하십시오. 변경을 원할 경우 다른 직업을 찾을 권리가 있다는 것을 알고 계십시오.


5
@Josh : "새로운 직업 찾기"상황 중 하나라고 생각합니다.
Adam Lear

21
이것에 조심하십시오. 보스는 기꺼이 무언가를하는 사람들을 이용하는 경향이 있습니다. 당신이 올바르게 보상되고 있는지 확인하십시오.
Tony

5
크리스가 "아무것도하지 않는다"고 말한 것은 아닌 것 같습니다. (음, 그는 조금 마쳤습니다. 나도 술을 마시지 않는 사람을 위해 커피를 가져 오지 않을 것입니다), "나는 개발자입니다. "프린터 카트리지를 교체하지 마십시오"라는 메시지가 표시됩니다.
Peter Boughton

10
동의하지 않습니다. 개발자가 요청한 모든 작업을 수행 할 수 있어야한다고 말하는 것은 쉽지만 반드시 그럴 필요는 없습니다. 이러한 상황에서 발생하는 상당한 이해 상충 문제가 있습니다. 프로덕션 시스템에 액세스하고 싶지 않기 때문에 프로덕션 시스템에 액세스하고 싶지 않습니다 ( "오, XXX가 지난 달에 있었기 때문에 관리자가 아닌 개발자가 된 것입니다")
MBonig

7
-1; 여기에는 진실의 핵심이 있지만,이 사고 방식에는이 답변이 인정하기에 충분하지 않은 한계가 있습니다. 진정한 근본적인 문제가 고용주가 인사 관리에 짜증을내는 것은 어떻습니까? 나는 한때 사무실이 무너지는 것을 보았는데, 상류층의 사람들은 지능적이고 유능한 엔지니어들이 미워하고 매우 열악한 역할을하도록 요구했다. "아니요!"라고 말할 때가 있습니다. 본인과 고용주 모두를 위해 할 수있는 최선의 방법입니다.
BlairHippo

29

시험 장치!

필요한 경우 테스터 학교에서 테스터를 바로 보내주십시오!

테스터가 없으면 프로그래머는 테스터이고 매우 똑똑하여 작동해야하기 때문에 모든 것이 박쥐에서 벗어날 것으로 기대합니다.

나는 개밥이 좋은 생각이 아니라고 말하는 것이 아닙니다. 나는 프로그래머이기 때문에 테스터가 매우 중요하다고 생각합니다.


4
우수한 전담 테스터는 확실히 등급이 낮습니다!
Peter Boughton

3
개밥!? 나는 5 개의 랍스터를 요리 할뿐입니다! ... 그래서 무언가를 망 쳤을 때 말해 줄 테스터가 필요합니다. 나는 물건을 만들고 그것이 어떻게 작동하는지 알고 있습니다. UI를 만든 사람은 UI가 작동하지 않는 사람과의 작동 방식이 아니라 작동 방식을 알고 있기 때문에 철저히 테스트 할 자격이 없습니다.
Morgan Herlocker

15
테스터가되는 데 아무런 문제가 없습니다. 자신의 코드에 대한 유일한 테스터가되는 것은 잘못입니다. 프로그래머는 여러 가정을 염두에두고 코드를 작성하며 테스터가 동일한 가정을하는 경우 예상치 못한 부분이 발생하지 않으며 많은 버그가 누락됩니다.
dbkk

5
자신의 코드를 테스트하는 것은 확실히 큰 일이 아닙니다. 프로그래머는 다른 많은 것들을 다룰 수 있지만 자신의 코드에 대한 실제 기능 테스트 (단위 테스트를 수행하지 않으면 프로그래머가 아닐 수도 있음)는 매우 나쁜 생각입니다. 그것으로 개밥을하는 것이 좋습니다.
glenatron

3
+1-프로그래머는 프로그램을 사용하는 방법에있어 비 프로그래머와 다른 점을 생각합니다. "파일-> 저장"메뉴 항목에서 버그를 발견 한 적이 있습니까?

26

사무용 하드웨어 문제를 해결 하는 데주의를 기울여야 합니다 . 여기에는 PC 문제 해결, 서버 관리자, 백업 및 전화 시스템 작업이 포함될 수 있습니다. 이전의 하드웨어 경험을 언급하는 실수를 저질렀으며 결국 하드웨어 / 문제 해결 업무가 프로그래밍 업무와 심각하게 충돌했습니다.


범인에게 당신의 상사의 허락이 필요하다고 말하고, 이것에 사용 된 모든 시간을 등록하십시오.

@Thor 상사로부터 온 하드웨어 작업에 대한 지시. 사무실에는 도움이되었지만, 그 시점에서 내가 원하는만큼 프로그래밍에 경력을 집중할 수 없었습니다.
Jon Onstott

@Jon, 사장님이해야한다고하면 잘해야합니다. 그런 다음 이것이 만족 스러운지 아닌지 그와 논의 할 수 있으며, 합의에 도달 할 수 없으면 떠나야 할 때입니다.

+1 나에게도 같은 일이 일어났다. 그들은 제가 코드를 작성할뿐만 아니라 네트워크 벤더와 함께 네트워크 문제를 다루기를 원하기 때문에 많은 스트레스를 받았습니다.
Rich

16

프로그래머가 자신의 코드에 대한 유일한 테스터 가되어서는 안됩니다 .

개발자는 일련의 가정으로 코드를 작성합니다. 테스터들이 동일한 가정을 가지고 있다면, 그 범위 밖에서 예상치 못한 기능을 수행하지 않을 것이며, 많은 문제들이 발견되지 않은 채 남아있을 것입니다.

더욱이, 앞으로 나아 가기 위해, 개발자는 테스터가 (아마 잠재 의식이있는 수준에있는 동안) 일을 중단하려고 시도하지 않습니다.

이것은 dev 테스트가 쓸모 없다는 것을 의미하지는 않습니다. 정반대의-좋은 개발자 테스트를 통해 테스터는 더 깊은 문제를 찾는 데 집중할 수 있습니다. 그러나 개발 테스트는 전담 테스터를 대체하지 않습니다 .


10

나는 박쥐에서 바로 생각할 수 있습니다.

  1. 기술 지원. 고객이 새 사이트를 통해 작업하거나 기능을 사용하는 방법을 가르치도록 여기에 없습니다.
  2. 프로세스의 다양한 시점에서 클라이언트와 인터페이스해야 할 수도 있지만, 관리 프로그래머가 아니라면 실제로 기능 및 디자인 구현에 대해 직접 통신해서는 안됩니다.

CSS / UI 개발은 프로그래밍 "영역"외부에 있다고 말할 수 있지만 내 경험상 오늘날 필요한 기술입니다. 테이블을 피할 수 없으며 다른 사람에게 의존하여 올바르게 구현할 수 없습니다. 디자인을 구현하거나 새 디자인을 처리하기 위해 코드를 변경하는 것을 좋아하지 않을 수도 있지만 이는 작업의 일부입니다.

쿼리 작성은 양호하고, Q / A 테스트는 양호합니다 (그리고 IMO 프로그래머가해야합니다. 외부 부서를 찾아야하지만 먼저 테스트해야합니다). 서버 관리는 약간 회색 영역입니다. 프로젝트의 규모에 따라 또는 전용 서버 관리자가있는 경우 필요하거나 필요하지 않을 수 있습니다.


7
포인트 2와 관련하여, 코드를 작성하는 사람이 고객과 직접 대화해야한다는 설립 원칙을 가진 회사가 적어도 하나 있습니다.
Frank Shearar

10

일반적으로 대부분의 프로그래머는 사용자 인터페이스의 모양과 느낌을 개발해서는 안됩니다 .UI를 개발할 수는 있지만 프로토 타입 또는 개념 증명을 작성할 때 UI를 개발할 수는 있지만 휴먼 팩터 사람에게 맡기는 편이 좋을 것입니다 (소규모 회사에서는 화면 레이아웃을 수행하고 설명서와 브로셔를 만드는 그래픽 아티스트입니다).

또한 개발자는 QA 테스트를 수행해서는 안됩니다. 즉, QA 부서 (내가 근무하는 회사는 내장 의료 기기를 제조하므로 별도의 부서에서 테스트를 수행해야합니다)입니다.

반면에 개발자가 데이터베이스를 디자인하고 SQL을 작성할 수없는 이유는 없습니다.


2
+1 그것을 작성한 개발자의 QA 테스트가 목적을 무너 뜨린 것에 동의했습니다.
spong

2
@JoshK 일부 QA 테스트는 개발자가 수행 할 수 있지만 기본 QA 테스트는 다른 사람들이 수행해야합니다. 작성한 자신의 앱을 테스트하면 잠재적 인 문제를 잠재 의식적으로 다룰 수 있습니다. 요점은 개발자가 찾을 수없는 문제, 즉 말하는 새로운 종류의 눈을 발견하는 것입니다.
spong

2
@JoshK @ChaosPandion 동의합니다. 개발자의 사전 테스트를 수행해야합니다.하지만 신뢰할 수 없어서 개발하지 않은 사람들에 의해 QA 테스트를 분리해야합니다.
spong

5
-1 : 프로그래머가 GUI를 디자인해서는 안된다는 것에 동의하지 않습니다. 저는 소규모 회사에서 8 년 동안 일했으며 모든 사용자 인터페이스를 디자인했습니다. 저는 항상 Microsoft의 우수한 설계 지침을 따르고 HMI 설계 서적을 읽었습니다. 외부 일러스트 레이터에게만 그래픽을 아웃소싱했습니다.
Wizard79

3
여기서 나를 귀찮게하는 한 가지는 그래픽 디자이너가 UI를 디자인하는 프로그래머보다 더 적합하다는 의미입니다. 그래픽 아티스트가 인터페이스를 디자인하는 데는 능숙 할 수도 있지만, 일반적으로 틀에 박힌 프로그래머로부터 얻을 수있는 혼란스럽고 거의 쓸모없고 추악한 인터페이스와 달리 혼란스럽고 사용할 수없는 예쁜 인터페이스로 변질 될 수 있습니다.
David Thornley

8

기술 지원

기술 지원 전화를 받으면 하루의 대부분이 낭비됩니다.

인기있는 것들은 다음과 같습니다.

  • "계정이 잠겨 있습니다"또는 "암호를 잊어 버렸습니다"
  • "[전화 | 키보드 | 마우스 | 컴퓨터]가 작동하지 않습니다"
  • "컴퓨터 속도가 느립니다. 비정상적인 점이 있습니까?"
  • "이 버튼을 클릭하면 X가 발생하는 이유는 무엇입니까? Y를 수행해야합니다."
  • "이 팝업이 계속 나타납니다 ...."또는 "바이러스가 있다고 생각합니다"
  • "이 사람은 더 이상 여기 있지 않습니다. 모든 것을 비활성화 할 수 있습니까?"
  • "새 직원이 있는데 로그인, 보안 카드, 전화 내선 번호, 이메일 등으로 설정할 수 있습니까?"

6

그를 관리하게 만드는 모든 역할. 소규모 팀에서는 종종 선임 개발자 중 하나를 프로젝트 관리자로 만드는 경향이 있지만 프로그래머로 팀에 유지하는 경향이 있습니다. 프로그래머로서이 사람은 기본적으로 관리되지 않기 때문에 모든 종류의 문제가 발생합니다. 그는 모든 작업을 다른 팀 구성원에게 위임하는 대신 많은 작업, 특히 가장 어려운 작업을 자신에게 할당하려는 유혹을받습니다. 따라서 가장 어려운 작업, 문제를 일으킬 가능성이 가장 높은 작업은 프로그래머로 50 % 만 사용할 수있는 사람에게 할당되고 아무도보고하지 않습니다. 다른 팀원이 엉덩이를 걷어 차지 않고 전달할 수없는 경우, 프로젝트 관리자로서 성공을 책임지고 가장 안전하게 수행 할 수있는 방법은 자신의 임무를 수행하기 때문에 작업을 수행하려고합니다. 그렇지 않습니까?


5

개발, 배포 또는 유지 관리에 어려움을 겪지 않았으며 주요 변경 사항에 대한 교육을받지 않았으며 최신 정보를받지 못한 기술에 대한 기술 지원. 내 업무의 일부는 인터넷이 작동하지 않는 이유에 대해 전화하는 고객에게 전화를 받고 있습니다. 나는 그 사업의 절반을 다루지 않기 때문에 그들에게 아무 것도 말할 수 없다.

기술 지원을 할 필요가 없으며 아무런 문제가 없습니다. 사물을 개발하는 동안 비서 / 기술 지원 담당자가되고 있습니다.

하루 종일 불평하는 사람들의 말에 귀를 기울이고 아무 말도 할 수 없어야합니다. 모든 비용을 피하는 것이 좋습니다.


그렇습니다. 하루 종일 성격을 여러 번 바꿔야하는 것은 과세입니다. 끊임없이 중단 될 때 집중이 필요한 작업을 수행하는 것은 어렵습니다.
Rich

5

판매 .

일부 불량한 버거가이를 수행해야하지만 개발자가 아니어야합니다.


4

나이가 들어감에 따라 개발자가 자체 배포를하지 않으면 이것이 최선이라는 것을 깨달았습니다. 선택 권한을 제외하고 프로덕션 데이터베이스에 대한 권한이 없어야합니다. 우리의 코드는 버그가 훨씬 적었습니다 (그리고 변경 사항은 prod에서만 이루어졌고 나중에 dev 배포가 다시 덮어 썼기 때문에 동일한 코드가 여러 번 자르지 않았습니다. 서두르고 헹구고 반복하여 prod에서만 수정) 배포가 타인에게 배포를 시작해야했고 배포가 적절하지 않기 때문에 생산 수정을 신속하게 수정할 수 없었습니다. 또한 우연히 "표의 모든 레코드를 변경 한 where 절이 강조 표시되지 않은"문제가 발생하는 것을 중지했습니다.


예, 그렇습니다 개발자에게 프로덕션에 대한 액세스 권한을 부여하지 말고 스테이징에 대해 매우 제한적이며 바람직하지는 않습니다. 다른 것이 없으면 노출되는 스트레스를 줄입니다.
ElGringoGrande

1
예! 저는 개발자 이며이 모든 프로덕션에 액세스하고 싶지 않습니다 . 다른 사람들이 소프트웨어 배포를 수행하는 경우 배포 프로세스를 한 번 더 테스트합니다. (그리고 아마도 desaster 복구뿐만 아니라이 밖으로 향상시킬 수 있습니다.)
싫증이 나다

3

아티스트사용자 인터페이스 디자이너 .

대부분의 프로그래머는 예술가가 매우 좋지 않지만 회사는 아티스트가 제품에 대한 이미지와 아이콘을 그리기 위해 비용을 지불하지 않고 "프로그래머 아트"를 사용하여 무시 무시한 결과를 낳습니다. (Windows Vista까지 이것은 Mac과 PC의 가장 즉각적인 차별화 요소였습니다. Mac은 아름답고 친근 해 보였고 PC는 눈에 띄지 않았습니다)

비슷한 방식으로 많은 프로그래머가 사용자 인터페이스에 관심이 많지 않습니다. 주로 코드에 관심이 있습니다. 단순히 멤버 변수의 내용을 일부 편집 가능한 필드에 직접 노출 시키며, 종종 단추와 필드를 양식에 넣는 위치에는 신경 쓰지 않으며, 이것이 충분하다고 가정하면 소프트웨어를 사용할 수 없게됩니다. (아이폰이 당신에게 실제로 사용하기 좋은 전화 UI를 만들 수 있음을 보여주기 위해 도착할 때까지 전체 휴대 전화 산업은 매우 유죄였습니다)

Lotus Notes는 전문 디자이너가 프로그래머를 도와주지 않으면이 두 가지가 얼마나 나쁜지를 보여주는 훌륭한 예입니다.


2
"대부분의 프로그래머는 artwook에서 매우 열악합니다"및 "많은 프로그래머는별로 관심이 없습니다"는 "프로그래머가 관심이 없다"및 "모든 프로그래머가 나쁘다"와 같지 않습니다. 나는 실제로 그것을 잘하는 부부를 알고 있습니다.
MIA

1
@ 짐 레오나르도 : 실제로. 그렇기 때문에 "모두"가 아니라 "가장 많이"와 "많이"라고했습니다. :-)
Jason Williams

3

전반적인 테스트 및 테스트 계획 작성 진심으로, 나는 내 자신의 테스트 계획을 작성할 수 있지만, 그것은 물건을 쓰는 동안 내가 잘못 이해, 잘못된 가정 및인지 실수를 제품에 굽는 것을 의미합니다. 내가 일한 한 회사에 대해 내가 싫어 한 것은 유일한 것이었다. 내가 지금있는 곳에서는 최소한이 리뷰를 할 코드 리뷰가 있습니다.


그러나 대부분의 테스트는 코드를 작성하기 전에 사양과 함께 작성해야합니다. 개발자가 만진 것에 대한 지식을 기반으로 추가 테스트를 추가하도록하는 것은 나쁘지 않습니다.
Peter Boughton

3

개발자가 A 또는 B를 하지 말아야한다는 말을함으로써 홀 개발자에게 비둘기를 주려고 시도하는 것은 합리적으로 처리 할 수있는 것보다 더 많은 "모자"를 착용하지 마십시오 . 훌륭한 UI 디자이너는 프로그래머가 UI.

하루가 끝날 때마다 모든 사람은 서로 다른 강점과 약점을 갖게되며 훌륭한 관리자 / 감독자 / 팀장은 인재를 적절하게 사용하도록 그들을 위해 일하는 사람들을 지시하는 가장 좋은 방법을 알아야합니다. 마찬가지로 UI를 디자인하거나 최종 사용자를 다루는 데 불편한 경우 팀에 알리면 해당 영역에서의 역할을 최소화 할 수 있습니다. 그러나 다른 영역에서 추가 작업을 수행 할 준비가되어 있어야합니다.

또한 너무 많은 모자를 착용하는 경우 (예 : 프로그래머, UI 디자이너, 테스터, 비즈니스 분석가 등) 모자 중 일부를 제대로 수행하지 않거나 타 버릴 수 있습니다. 처리 할 수있는 모자 수를 알고 작업 수준을 그 주위로 유지하십시오.

그 외에도 개발자가 그 역할을 능가하는 기술을 보유하고 있다면 착용해서는 안되는 "모자"는 없습니다.


1

다음과 같은 경우에만 나에게 던져지는 직업을 취하는 경향이 있습니다.

  • 나는 나의 기술 수준과 가능한 의미에 대해 미리 경고하고 상사는 그것이 수용 가능하다고 결정합니다
  • 예상치 못한 것을 다루는 데 도움을 줄 수있는 전문가 수준의 사람이 있습니다.
  • 일부 문서를 읽고 온라인으로 질문 한 내용 등을 읽으십시오.

이 방법으로 나는 대부분 상사에 대해 보험을 받고 누군가 잘못되면 최소한 고칠 수 있습니다.


1

개발자는 상황에 대한 이해 관계자 (고객, 소유자 등)이므로 의미있는 직업을 기대할 권리가 있습니다. 내 의견으로는, 그것은 당신의 강점 을 가지고 일할 수있는 기회를 의미합니다 .

따라서 개발자는 활력을 잃지 않고 개인 성장에 기여하며 최고의 성능을 발휘할 수있는 모자를 착용해서는 안되며 이러한 작업을 수행하는 "모자"로부터 시간을 빼앗아서는 안됩니다.

자신의 코드를 테스트하는 유일한 사람이 아니라는 것만으로도 "모자"가 모자를 쓴 개발자에게 의미있는 일이라면 괜찮습니다.


1

"디자이너"또는 "크리에이티브 녀석". x_x를 알기 전에 다음 온라인 광고 캠페인을위한 마케팅 텍스트 작성 또는 "오른쪽"파란색 음영에 대한 끝없는 토론에 이르기까지 응용 프로그램 인터페이스 모형을 무심코 조합하는 것부터 시작합니다.


0

짚으로 옆에 맥주 캔이 달린 모자. 당신이 잡히면 나쁜 생각.

편집하다:

여기 내가 싫어하는 모자가 있지만 큰 보상이 있습니다.이 일이 망가지면 그것이 당신의 잘못이라고 말하는 큰 표시입니다 .... 아, 그러나 그것이 좋다면, 당신은 내 아들이 우리를 잘 아는 아들입니다. -지하실로 돌아가서 ... 좋은 소년 ... 그게 다야.

비난 모자.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.