Monthly Archives: June 2012

[Corona SDK] Game Template with Storyboard

First of all, thank for Radamanthus Batnag (original post is here)
Here is my github repository, https://github.com/alterant-kr/_GameTemplate-with-storyboard

코로나 게임 템플릿으로 상위Top rated에 랭크된 ‘Game Template’은 director 를 사용하고 루비로 된 newgame.rb 을 실행하여 새로운 코로나 프로젝트를 생성할 수 있는데 필자는 이를 최근에 코로나에 도입된 storyboard를 사용하도록 수정하여 깃허브에 올려두었습니다.

여러분들에게 도움이 되었으면 합니다. ^.^

아래는 원본의 README를 일부 수정한 것입니다.

_GameTemplate-with-storyboard
=================================

This is a template project for building games using Ansca Mobile’s Corona SDK (http://www.anscamobile.com/corona/)

ORIGINAL TEMPLATE FROM Radamanthus Batnag
Corona Game Template version 1.0
– (c) 2011 by Radamanthus Batnag
– (c) 2012 by Roman Neo with Alterant, Inc.

아래 그림을 참고하세요.

 

2011 CWE/SANS 가장 위험한 25大 소프트웨어 오류

PDF 문서 보기: 2011_cwe_sans_top25_KR(SANS_Korea)

2011 CWE/SANS 가장 위험한 25大 소프트웨어 오류는 심각한 소프트웨어 취약성을 초래할 수 있는 가장 널리 확산되어 있으며 치명적인 오류를 정리한 목록입니다. 이 오류는 쉽게 찾을 수 있고 쉽게 악용될 수 있습니다. 이 같은 오류가 위험핚 이유는 공격자가 이를 통해 소프트웨어를 완전히 장악하거나, 데이터를 훔치거나, 소프트웨어가 전혀 작동하지 못하도록 하는 경우가 많기 때문입니다.

본 25大 목록은 소프트웨어가 출시되기도 전에 흔히 발생하는 실수를 파악하고 방지함으로써 소프트웨어 산업에 문제가 되어 왔던 다양한 취약성을 프로그래머들이 예방할 수 있도록 교육하고 인식을 확산할 수 있도록 사용할 수 있는 도구입니다. 소프트웨어 고객은 이 목록을 사용하여 프로그래머들이 더 안전한 소프트웨어를 개발할 수 있도록 요구할 수 있습니다. 소프트웨어 보안에 종사하는 연구원들은 이 목록을 사용하여 모두 알려줘 보안 취약점 중에서 한정되지만 중요한 일부 취약점에 초점을 맞출 수 있습니다. 마지막으로 소프트웨어 관리자 및 CIO들은 이 목록을 자사 소프트웨어를 보완하기 위한 노력의 진척 상황을 측정하는 값대로 사용할 수 있습니다.

이 목록은 SANS 연구소, MITRE, 그리고 미국 및 유럽의 여러 유수 소프트웨어 보앆 전문가들이 협력에서 나온 결과물입니다. 여기에는 SANS의 20대 공격 벡터(http://www.sans.org/top20/)와 MITRE의 CWE(Common Weakness Enumeration)(http://cwe.mitre.org/)를 개발했던 경험을 활용하였습니다. MITRE는 미국 국토안보부(DHS) 산하 국가사이버보안국(NCSD)의 지원을 받아 CWE 웹사이트를 유지관리하며 상위 25대 프로그래밍 오류에 대해서 상세한 설명을 제공하며 이를 완화하고 방지할 수 있는 권위 있는 지침과 함께 설명을 제공하고 있습니다. CWE 사이트에는 악용 가능한 취약성으로 이어질 수 있는 800 가지가 넘는 프로그래밍 오류, 설계 오류 및 아키텍처 오류에 대한 자료가 수록되어 있습니다.

2011년도 상위 25대 소프트웨어 오류 목록은 정싞과 목표는 그대로 유지하면서 2010년도 목록을 업데이트할 것입니다. 올해의 상위 25대 항목은 20개가 넘는 다양한 조직에서 각 취약성을 확산 정도, 중요도 및 악용 가능성을 기준으로 평가핚 의겫을 토대로 우선숚위가 정해졌습니다. 최종 결과를 점수화하고 숚위를 정하는 데는 CWSS(Common Weakness Scoring System)가 사용되었습니다. 상위 25대 오류 목록에는 CWE에 의해 문서화된 수백 가지의 취약점뿐만 아니라, 상위 25大 취약점 젂체를 개발자들이 줄이거나 없애는데 도움을 줄 수 있는 몇 가지 가장 효과적인 “주요 완화 방법(Monster Mitigations)”를 망라하였습니다.

Copyright ©2011
http://cwe.mitre.org/top25/
문서 버전: 1.0.2

프로젝트 코디네이터: Bob Martin (MITRE) Mason Brown (SANS), Alan Paller (SANS) Dennis Kirby (SANS), The MITRE Corporation
날짜: 2011년 6월 29일
문서 편집자: Steve Christey (MITRE)
문서 번역자: SANS 코리아(sans@sans.or.kr) http://www.itlkorea.kr

 

[번역] 애플 버그 리포트 완벽 가이드 – INNA

(원본) A Complete Guide to Filing Bugs with Apple – Posted by Inna

모든 소프트웨어는 버그가 있으며 코로나와 애플도 예외는 아닙니다. 코로나 팀원이며 독창적인 프로그래머인 에릭 윙은 전문 버그 리포터입니다. 그의 전 경력을 통해 그는 500개 이상의 애플 버그 리포트를 해왔습니다(일정량 이상 그가 리포트한 버그가 수정되었습니다). 에릭이 작성한 버그 리포트 작성 방법과 팁을 읽어보길 권합니다.

 

애플에 버그와 기능 리포트 하기

여러분은 앱스토어에 iOS 앱을 등록하고 있나요? 애플에 1년에 99달러의 등록비를 내고 있나요? 뭐든 개발하기 위해 Xcode를 사용하고 있나요? 일련의 물음에 한개라도 ‘예’라고 대답했다면 여러분은 애플 개발자입니다.

모든 소프트웨어는 버그를 갖고 있으며 애플도 예외는 아닙니다. 코로나 SDK로 우리는 지원하는 다양한 플랫폼의 버그로부터 개발자를 보호하기 위해 열심히 노력합니다. 그러나 때때로 이것이 불가능합니다. 유일한 해결책은 벤더가 문제를 해결하는 방법뿐입니다.

대부분의 사람들이 애플 개발자로서 절망스럽게 리포트를 작성하지만 애플은 실제로  버그 리포트를 읽고 이슈들을 수정한다는 사실을 주지하십시오. 이는 대부분의 대기업과는 좀 다릅니다. 큰 회사에 버그에 대해서 연락을 취하려고 노력하다 간신히 리포트 제출처를 찾았다해도 그 것이 수정되어 돌아오는 일은 없습니다. 최악의 예를 들자면 몇 년 전 필자는 사우스웨스트 항공에 성가신 버그를 리포트 했습니다. 그 당시 사우스웨스트는 온라인 연락 방법을 제공하지 않아서 편지를 써서 보냈습니다. 필자의 편지가 잘 도착했다는 연락을 받았습니다만 사우스웨스트 항공사는 오늘까지 그들은 그 버그를 수정하지 않고 있습니다.

애플은 독특합니다. 그들이 내부에서 사용하는 버그/기능 트래커 시스템에 대한 외부 개발자의 버그 리포팅 접근을 허가하고 있습니다. 이 시스템을 애플 레이더Apple Radar라고 부르며 애플 팀들의 작업이 리포트된 건에 따라 일정 관리됩니다. 작업이 레이더Radar에 등록되지 않으면 애플 엔지니어는 작업에 착수하지 않으며 버그는 수정되지 않습니다.

버그를 수정하기 위하서는 *여러분*이 버그 리포트를 해야합니다! (다른 사람이 아닌 여러분이…)

“누군가 버그 리포트 하겠지” 또는 “애플은 벌써 이것에 대해 알고 있을거야”라고 여러 개발자들이 자주 이야기합니다. 첫째, 이것은 완전한 오해입니다. 좀 더 자주벌어지는 일은 누구도 버그리포트를 하지 않고는 애플이 그것을 알지 못한다는 사실입니다.

그러나 이것이 사실이라도 상관없는 것은 레이더가 투표/가중치 시스템이기 때문입니다. 레이더는 몇 명의 사람들이 중복된 리포트를 하는지를 추적합니다. 중복이 많이 발생하면 할수록 애플은 해당 버그를 수정 작업의 가중치를 높이게됩니다. 이것이 애플이 알고 있는 버그라도 여러사람들이 버그 리포트를 해야하는 이유입니다.

베타 테스트와 버그 리포트

애플이 베타(시드)를 배포하는데는 이유가 있습니다. 애플은 뭔가가 고장나거나 제대로 작동하지 않는지를 알고 싶은 것입니다. 이것이 바로 재앙을 막는 최고의 기회인 것입니다.

중요한 케이스를 살펴보자면 잘 알려져있듯이 iOS 5.0이 소개될 때 OpenAL에 정말 심각한 버그가 있었습니다. 미연에 방지할 수 있었던 문제이기 때문에 정말 비극이 아닐 수 없습니다. 이 사건으로 우리 모두가 발이 묶였었습니다. iOS 5.0 베타 4에서 애플은 실수로 OpenAL API의 기저 부분의 오디오 코드에 손상을 줘서 오디오 전체가 오동작하고만 것이었습니다. 몇몇 개발자는 실제 이 문제를 베타 4에서 발견했고 애플이 이를 파악했거나 누군가가 버그리포트를 했던 것으로 알려져 있습니다. 하지만 이것은 완전 잘못된 사실입니다. 최종적으로 베터 7에서 우리는 해당 문제를 파악했으며 필자가 버그 리포트를 했습니다. 그러나 너무 늦은 나머지 애플은 이미 해당 코드를 잠궈버렸습니다. 애플은 치명적인 보안 이슈만 패치 릴리즈(예. 5.0.1)에 포함하여 배포했기에 오디오 이슈는 5.1버전까지 수정되지 못했습니다.

한편 우리는 코로나에서 오디오 문제에 대해서 몇 주동안 해결하려 노력했습니다. 우리가 해결 시도하는 동안 이 이슈가 나쁜 성능을 야기하였습니다. 우리는 시도할 방법이 거의 고갈상태였기에 스스로 행운이 따른 것이라 생각했습니다. 또한 우리는 기존에 수정되지 않은 iOS 버그를 막고자 노력하는 동안 또 다른 버그를 발견하게 됩니다.

애플은 이슈를 iOS 5.1에서 수정했으나 iOS 5.0에서 업그레이드 하지 않은 사용자는 여전히 버그에 영향을 받고 있었습니다. 이는 우리가 iOS 5.0이 사라질 때까지 꼼짝없이 갇혀버린다는 뜻이었습니다. (다행히 OTA 업데이트 기능 덕분에 2주 내에 5.1로 대부분의 사용자들이 업그레이드를 해서 우리도 5.0을 훨씬 빨리 포기할 수 있었습니다.)
이 교훈은 누군가 베타4에서 버그를 리포트 했더라면 iOS 5.0 배포 전에 수정이 되었을 것이라는 것입니다.

근사한 버그 리포트 작성하기

애플은 여기에 근사한 버그 리포트를 어떻게 작성하는 지 알려주고 있습니다.

다음은 필자가 제안하는 몇 가지입니다:

  • 가급적 상세한 정보를 담도록 하십시오. 누군가 이미 해당 버그를 신고했을 수도 있지만 여러분은 조금 다른 상황에서 버그가 발생하여 도움이 될 수 있습니다.
  • 문제를 재연할 수 있는 테스트 방법을 제공하십시오.
  • 애플에 가급적이면 어떤 버전에서 처음 문제를 발견했는지와 어떤 OS와 장비를 사용해서 테스트했는지를 알려주십시오.
  • 만약 관련된 버그를 알고 있다면 여러분의 버그 리포트에 해당 버그의 일련번호를 포함시키십시오. (버그 리포트 시 우리는 알고 있는 버그 일련번호를 포함시키려고 노력했는데 이를 여러분의 버그 리포트 내에 참조할 수 있을 것입니다.)
  • 코로나를 사용한다고 주저없이 말씀하셔도 좋고 따라서 어떻게 작동하는지에 대한 상세한 것을 모른다라고 말씀하셔도 좋습니다. 애플은 일정 부분은 여러분의 바이너리로 디버깅을 시도하므로 버그 리포트 시에 여러분의 프로젝트를 포함시키세요. 그리고 여러분이 우리를 애플과의 토론에 포함시켜도 좋습니다. 여러분이 애플에 버그를 보낼 때 또 같은 버그 리포트를 우리에게 보내주셔도 좋습니다. (버그 일련번호를 포함해서 말이죠.)
  • 애플은 더 많은 정보를 원한다면 여러분에게 연락할 것 입니다. 여러분이 그들의 주의를 이끌었으므로 이슈를 계속 따라잡도록 하세요. 만약 애플이 여러분에게 더 많은 정보를 원해서 연락해온 경우 어떻게 제공을 해야할지 잘 모른다면 우리에게 연락하세요. 애플이 원하는 정보를 우리가 제공하도록 노력하겠습니다. 일련의 버그들을 수정하는 것은 우리의 관심사이기 때문입니다.

 

친절하게

필자의 경험으로 애플 엔지니어는 여러분이 그들의 것을 사용할때 그들의 일에 자부심을 갖고 좋아합니다. 그들은 그들의 것들이 작동하길 원하며 근사한 버그 리포트를 받기를 좋아합니다. 용기를 내시되 비난이나 힐난은 삼가세요. 그들도 감정이 있으니까요.

 

버그의 형태 – 애플 혹은 코로나?

여러분은 어떻게 애플 버그인지 코로나 버그인지를 구분하시겠습니까? 때로는 매우 어려운 일이지만 다음에 몇가지 힌트를 드립니다.

퇴행: 여러분의 애플리케이션을 수정없이 동일한 장비에서 구동 하는 경우, 이전 버전의 iOS에서는 잘 동작하는데 새로운 버전의 iOS에서 갑자기 실행이 중단된다면 이를 퇴행 버그라고 부릅니다. 이것은 애플 버그이므로 리포트를 하세요. 최대한 빨리!

장비 관련: 가령 아이패드 1과 2와 같은 장비 사이에서 이상 동작을 한다면 때때로 이는 애플 버그일 수 있습니다. 여러분이 확신할 수 없다면 버그 리포트를 애플과 코로나 양쪽으로 하기를 권합니다.

코로나로 제작하지 않은 앱에 동일한 문제: 코로나를 사용하지 않은 다른 앱에서 동일한 버그를 발견했다면 이는 애플 버그인 경우가 많습니다.

코로나에서 알려드린 애플 버그: 우리는 어떤 이슈가 애플 버그인 경우 찾아낼 수 있습니다. 우리가 그것이 애플 버그라고 말씀드리면 애플에 버그 리포트를 해주십시오. (중요도를 높일 수 있습니다.)

기능 요구: 레이더는 기능을 요구할 때도 사용합니다. 여러분이 시리Siri API에 접근성을 원하는 경우 애플에 공개를 요구할 수 있습니다. 버그 리포트 형태로 말이죠.

개인적 성과

필자는 여러분에게 솔직히 말씀드립니다. 많은 버그들이 수정되지 않으며 여러분의 버그 리포트에 대하여 애플 엔지니어로 부터 상세한 정보를 요구받는 경우도 매우 드문일 입니다. 필자 생각에 놀라운 점은 가볍지 않은 상당한 버그들에 반응하고 수정된다는 것입니다. 필자의 경력을 통틀어 애플에 500개 여개의 버그 리포트를 했습니다. 추측컨데 약 25%의 버그가 수정되거나 해결되었습니다. 구글과 마이크로소프트의 버그 리포트는 전혀 수정되지 않은 것에 비하면 25%는 상당히 높은 비율이라고 생각합니다. 그들이 필자가 작성했던 버그 리포트를 읽기나 했는지 의심스럽습니다.

코로나 사용자들은 버그 리포트를 해야합니다.

여기에 여러분이 리포트할 세가지 버그를 안내해드립니다.

Xcode에서 루아 언어 지원:
Xcode 4에는 Lua 언어의 색상 표현이 지원되지 않습니다 (코드 자동 완성도 마찬가지고요). 필자가 장담하건데 모든 코로나 사용자가 버그 리포트(기능 요구) 한다면 여러분이 중요도를 충분히 높혔기 때문입니다. 오늘 바로 버그 리포트를 해보세요! 여러분의 버그 리포트에 필자의 버그 리포트 원본(rdar://9321859)을 참조하면 애플은 이슈가 중복임(일종의 투표)을 알 수 있을 것입니다.

맥 상에서 레이어를 포함하는 WebView가 깨짐:
맥 상에서 코로나 자연 객체는 애플의 코어애니메이션Core Animation 기술의 레이어 지원 뷰views로 정교하게 기술된 것입니다. 불행히도 웹뷰WebViews는 이런 경우와 2007년에 등장한 OpenGL기술에 있어서 심각한 문제를 내재하고 있습니다.(맞아요. 필자의 버그 원본은 좀 멀리 갔습니다.) 상당한 진전이 있었음에도 코로나 시뮬레이터가 깨지는 현상은 오늘까지도 여전히 존재합니다. 이것이 코로나 시뮬레이터를 사용하는 중에 발생하는 (가장) 성가신 문제의 해결은 가까운 미래에 웹뷰WebViews를 사용하여 맥용 앱을 출시하는 모든 사람이 숙원하는 박수갈채를 받을 일일 것입니다. 이 버그가 당장 해결되기를 기대합니다 (마운틴 라이언Mountain Lion 에서 해결 기대). 필자의 버그 번호(rdar://1326401)를 참조하여 여러분의 버그 리포트를 지금 작성하십시오.

녹음과 재생 전환 간에 순간 정지 현상:
불행히도 iOS 5에서는 한 개 이상의 심각한 오디오 버그가 있었습니다. 또 다른 버그는 녹음모드와 재생모드 사이의 전환 과정에서 앱을 순간적으로 정지시키는 현상을 야기합니다. 여러분이 예제 앱을 보시면 우리가 iOS 5를 위한 Lua 방어코드를 보실 수 있을 것입니다. 방어코드는 강제로 장비로 하여금 재생과 녹음 모드를 동시에 작동하게끔하여 녹음과 재생 모드 전환이 불필요하도록 한 것입니다. 하지만 이로써 부정적인 측면이 생겼습니다. 성능적인 고려를 하다보니 아이폰은 재생 스피커로 내장 스피커 대신 외부 이어폰을 사용하는 경우 전환이 일어나는데 추측컨데 피드백 잡음을 피하기 위해서 그랬을 것입니다. 여러분 중에 재생과 녹음을 동시에 사용하지 않는 분들은 이 방어코드에 대해서 불만을 토로하실 것입니다만 이어폰을 사용하는 것은 애플의 디자인이고 우리 방어코드는 동시 사용할 경우에만 적용됩니다. 본 이슈는 애플만이 수정할 수 있으므로 버그 리포트를 해주십시오. 버그 번호(rdar://1454403)를 참조하십시오.

필자는 일련의 버그를 개방형 레이더Open Radar에 미러링하여 공개해두었습니다.

http://openradar.appspot.com/9321859
http://openradar.appspot.com/radar?id=1326401
http://openradar.appspot.com/radar?id=1454403

개방형 레이더Open Radar

여러분의 선택입니다만 애플 개발자들은 버그 리포트를 발견된 버그와 싸우는 모든 이들과 공유하기 위한 공동체를 시작했습니다. 여러분의 버그 리포트를 개방형 레이더Open Radar에 공유해보는 것을 어떨까요.

무엇을 망설이시나요?

여러분은 개발자 인증을 위해 99달러를 냈습니다. 맥을 샀습니다. iOS 장비도 샀습니다. 버그는 개발 노력과 지원 비용에서 여러분의 시간과 돈을 낭비하게 합니다. 심지어 여러분의 고객을 잃게할 수도 있습니다. 때로는 미래에 부메랑처럼 돌아와 당신을 강타할 수도 있습니다. 여러분의 투자금을 지키고 미래의 두통꺼리를 예방하려면 버그 리포트하십시오!

애플 레이더Apple Radar

애플 레이더Apple Radar에서 버그 리포트 하십시오!