iPad Orientation CSS (Revised)

It doesn’t take much foresight to anticipate that with the rise of Natural User Interfaces (NUIs) like the iPhone and iPad, UI designers will have a greater responsibility to optimize for orientation-based contexts. As such, it’s quite prescient that today, the folks at Cloud Four demonstrated how to serve up stylesheets based on device orientation.

Since I have a feeling I’ll be using this quite a bit in the future, I wanted to build on Cloud Four’s work and find a way to alleviate the following issues:

1. Extra HTTP requests
2. Not iPad-specific
3. Lack of reusability

So, without further ado, here’s my proposed revision to the iPad orientation CSS:

<!-- css -->
@media only screen and (max-device-width: 1024px) and (orientation:portrait) { 
    .landscape { display: none; }
}
@media only screen and (max-device-width: 1024px) and (orientation:landscape) { 
    .portrait { display: none; }
}

<!-- example markup -->
<h1 class="portrait">Your device orientation is "portrait"<h1>
<h1 class="landscape">Your device orientation is "landscape"<h1>

As you can see, I’ve also changed the markup in a predictable way. An explanation of the changes and the reasoning behind them can be found below.

What Is Google App Engine?

You can serve your app from your own domain name (such as http://www.example.com/) using Google Apps. Or, you can serve your app using a free name on the appspot.com domain. You can share your application with the world, or limit access to members of your organization.

Google App Engine supports apps written in several programming languages. With App Engine's Java runtime environment, you can build your app using standard Java technologies, including the JVM, Java servlets, and the Java programming language—or any other language using a JVM-based interpreter or compiler, such as JavaScript or Ruby. App Engine also features a dedicated Python runtime environment, which includes a fast Python interpreter and the Python standard library. The Java and Python runtime environments are built to ensure that your application runs quickly, securely, and without interference from other apps on the system.

With App Engine, you only pay for what you use. There are no set-up costs and no recurring fees. The resources your application uses, such as storage and bandwidth, are measured by the gigabyte, and billed at competitive rates. You control the maximum amounts of resources your app can consume, so it always stays within your budget.

App Engine costs nothing to get started. All applications can use up to 500 MB of storage and enough CPU and bandwidth to support an efficient app serving around 5 million page views a month, absolutely free. When you enable billing for your application, your free limits are raised, and you only pay for resources you use above the free levels.

Getting Started

• What Is Google App Engine?
• Java
  • Introduction
  • Installing the Java SDK
  • Creating a Project
  • Using the Users Service
  • Using JSPs
  • Using the Datastore with JDO
  • Using Static Files
  • Uploading Your Application

18 Mobile Frameworks and Development Tools for Creating iPhone Apps

There are many different types of tools available to developers, from low-tech stencil kits to high-tech collaborative software. So I’ve rounded up a few of the more popular ones people are using specifically for iPhone development. It’s far from being the definitive list, but it’s definitely a good place to start.

Low Tech Solutions

Notepod

Notepod is a notepad shaped like an iPhone. Each notepod is 100 pages of 60 x 110mm double sided paper. The front has 52mm x 77mm blank space (the iPhone screen), the back is a 6mm grid.

Project Page

iPhone UI Stencil Kit

The iPhone ui stencil kit is a stainless steel, laser cut stencil kit for drawing quick mock-ups and wireframes for iPhone apps. It also comes with a Zebra mechanical pencil.

Project Page

iPhone Sketch Pad

The iPhone Sketchpad works precisely with the iPhone Stencil Kit, with one phone silhouette on the front side and three on the back.

Project Page

App Sketchbook

The App Sketchbook has 50 Double-sided, perforated pages each with 3 actual sized iPhone templates. Each page also has has 20px ruler markings and a ruled section for notes.

Project Page

Vector Images

MetaSpark’s Fireworks Vectors

A collection of vector iPhone UI elements for Fireworks CS3 and CS4.

Project Page

320480 Stencil PSD file

Most iPhone screen elements, sensible layer sets all contained within one PSD file.

Project Page

Graffletopia Stencil Kit for Omnigraffle

Graffletopia’s stencil kit for Omnigraffle. It is for quick sketching of iPhone ideas. Use the outline for printouts so you can hand sketch as well. The symbols are meant as a check list for included features in your app development.

Project Page

MockApp

MockApp is a set of iPhone ui templates and library files put together for use in Powerpoint or Keynote.

Project Page

Firefox Plug-ins

iPhone Prototype

This is a plug-in to browser Mozilla FireFox for prototyping interface of iPhone applications for creating an iPhone mock-up. Currently Alpha – not compatible with FF 3.55.

Project Page

Firefox Pencil

Pencil is a free and opensource tool for making diagrams and GUI prototyping. Pencil runs on the Mozilla Gecko engine, turning the Firefox browser into a sketching tool with just a 400-kilobyte installation package.

Project Page

Fireworks Plug-ins

Unitid

This plug-in combines Fireworks with some jQuery and PHP to give you a prototype you can not only view, but interact with, directly on your iPhone, just as if it’s a live app.

Project Page

iPhone Apps

LiveView

Liveview is an iPhone app that consists of two parts: the ScreenCaster and the Application itself.  ScreenCaster launches a simple iPhone skin on your Mac. From the same network, launch the LiveView app in your iPhone. Whatever the ScreenCaster is highlighting is now seen in the LiveView App. It also interprets touches as mouse clicks, turning it into a two way interactive prototype.

Project Page

Web Based Tools

Mockingbird

Mockingbird is a web based mockup/wireframe tool built using the Cappucino framework, so there’s no flash to wrestle with. While you can’t actually design your mockups from an iPhone (who’d want to?), the tool does have some very handy features. You can drag elements onto the screen, create multiple pages, link to other pages and share directly from the web.

Project Page

Pidoco

Pidoco is a web-based tool that lets you create clickable wireframes via drag & drop ui and then collaborate with remote users on each project. The tool also includes iPhone stencils.

Project Page

iPhone Mockup

iPhone mockup is a web based tool that is currently in Alpha release only. You can design your mockup as a hand sketch or illustration, and mockups can contain user-uploaded images and user-entered text. Your mockups will be accessible via url so they are unsecured.

The developer makes this perfectly clear and warns that he could discontinue hosting mockups at anytime, thereby deleting any work. That makes this a handy tool for quick and dirty mockups you want to print or share with someone on the fly, but not for much more.

Project Page

Protoshare

Protoshare is a collaborative, web-based prototyping tool that helps teams visualize requirements for interactive projects and work together in real-time. It has an iPhone component that can be seen here.

Project Page

iPlotz

With iPlotz you can create clickable, navigable wireframes to create the experience of a real website or software application. You can also invite others to comment on the designs, and once ready, you can then manage the tasks for developers and designers to build the project.

Project Page

Installed Software

CogTool

CogTool is a general purpose UI prototyping tool simply using a storyboard of your design idea with sketches, images or on a canvas. Demonstrate tasks on that storyboard, then press a button to produce a valid cognitive model predicting how long it will take a skilled user to complete those tasks.

Project Page

Balsamiq

Balsamiq mockups is desktop software that is designed to help teams or clients collaborate on wireframes and mockups. There are iPhone specific controls included.

Project Page

OmniGraffle

OmniGraffle is award winning diagraming mockup or graphic design software. Combined with Graffletopia’s iPhone stencil kit, this software is a great addition to any app developers toolbox.

Project Page

Justinmind Prototyper

Justinmind prototyper allows you to create fully functional wireframes for mobile applications and generate your HTML high-fidelity wireframes.

Project Page

iRise

iRise for iPhones gives developers a way to quickly prototype the look, feel and behavior of Apple iPhone applications through pre-defined visualization widgets and templates that can be quickly assembled into a high definition mobile applications.

Project Page

2011.03.26~03.27 강원도 속초 대포항을 다녀왔다. 
토요일 슈슈가 근무여서 아침에 박물관에 출근시키고,  
집에서 쉬다가 올초부터 생각했던 동해에 대한 열망에 속초행을 결심하게 됐다. 
오전에 국립민속박물관에서 지난번에 복원한 "오촌댁"도 구경하고. 
국립민속박물관의 오전은 외국인을 발디딜곳이 없구나. 외국같아.

오후 6시 민속박물관에서 슈슈를 픽업하여, 종로 2가에서 버거킹 햄버거 구매. 
참고로 난 네비게이션이 없다.
덕분에 을지로를 돌아 왕십리를 지나서 강변북로타고 천호대교로. 
토요일 저녁이라 차 엄청 막힌다. 천호대교에서 서울춘천간 고속도로로 이동. 
이제 미시령 터널도 개통이 되어 서울에서 속초까지  엄청 빨라졌다.  
12년 전에 속초를 갔었는데, 머구리들과 함께. 
춘천고속도로를  진입하니 엄청 어둡다. 아니나 다를까 견인차가 막 달리더니
얼마 지나지않아 로드킬을 목격했다. 뭔가 큰 동물을 치어서 차가 한대 서있고 
그 옆에 견인차들이 있었는데, 얼핏 봤지만 뭔가 큰 노루같은... 에고~ 
밤에 어두운 고속도로를 달리는건 쉽지 않은 일이다. 특히 산간도로는 더욱더~ 
새 도로라서인가 금방 동홍천(춘천간고속도로 종점, 곧 양양까지 개통예정)을 지났다.
동홍천을 나오니 국도 분위기의 고속도로 46번 도로를 타고 가는데, 
중간중간 신호가 있어서 나름 시간이 걸린다.
12선녀탕 인근을 지나 한계령과 미시령 사이. 한계령은 양양가는길이고, 속초는 미시령이다.
옛 미시령 도로는 폐쇄됐고, 미시령 터널을 통과한다. 통행료 3000원,. 현금 준비하자.
긴 미시령 터널을 지나면 울산바위전망대 근처인데, 속초의 야경이 한눈에 들어온다.
감탄의 아우성을 지를 준비 하시고 미시령 터널을 나가시기 바란다. 우린 밤 9시 10분경 통과했는데, 아이폰 사진으로는 담을 수 없었다.
한참을 내리막을 가야 하기때문에 기어를 1단에 놓고 내려갔다.
그렇게 속초외곽을 달려 대포항에 도착하는가 했는데, 외옹치항으로 돌아들어가는 길을
네이버지도가 알려준다. 그냥 대포항으로 직진할껄. 외옹치항으로 들어가는 길 진입로에 펜션및 모텔이 있어서 여기에서 숙박을 해결해야 겠다는생각. 
대포항과 얼마 멀지 않아서 방을 잡고 걸어서 가도 될 정도이다. 다음엔 꼭 그렇게. 
외옹치에서 대포항으로 진입하는데, 길이 좁아서 바로 나와버렸다. 
대포항 끝방향이었는데, 뭔가 생선과 조개를 구워먹는 포장마차가 좋아보였다. 다음엔 꼭 먹으리.
예전 대포항 1주차장은 공사중이었는데, 그 옆에 1주차장이 새로 있으니 일단 파킹. 
대포항으로 들어가는 입구에 새우튀김집이 즐비하다. 조금들어가면 줄서서 기다리는 새우튀김집이 있는데, 아마 이집이 맛집인가보다. 튀김은 조명아래에서 더욱 맛있어 보인다.
포장을하면 종이컵하나와 포장간장을 주기때문에 일단 들어갈때 작은 새우튀김으로
한봉지 사서 먹으면서 다니는것도 좋을거 같다. 차 때문에 회집은 들어가지 않고 구경만
쭉 하고, 비단멍게, 새우튀김 큰거, 오징어 순대 하나를 사서 숙소를 찾아서 출발.
1 주차장 맡은편에 편의점이 있어서 미리 먹을거 좀 사갔다.  
외옹치항 입구쯤에 있는 숙소에 여정을 풀고 속초에서의 하루를 마쳤다.

다음날 아침(2011.03.27). 일어나자마자 씻고 나서는데, 설악의 설경이 눈에 들어오는 것이 아닌가. 병풍을 두른것 처럼 속초를 감싸안고 있는 설악이 저 멀리 보이는데, 지난 밤 지나올때는 몰랐다.

일단 인근의 속초 해수욕장을 들러 푸른바다와 모래사장 한번 밟아 주시고. 인증샷!
인근의 진전사지3층석탑과 진전사부도를 보러 가기로 했다. 각각 국보, 보물로 지정.
물치항인근을 지나 올라가는데, 군부대가 엄청 크게 있었다. 신기하다. 
한참을 올라가다보니 진전사지3층석탑을 볼수 있었다. 역시 다녀보면 옛 절터는 정말 풍수지리가 좋다. 지금은 차로 올수 있지만 에전은 오솔길이지 않았을까? 여기 터를 잡은 걸보면 옛선인들의 능력이 참 대단함을 느낀다.
그리고, 조금 더 올라가면 전진서부도가 있는데, 진전사를 복원하고 있는 중이더라. 
왠 하얀개가 와서 반기는 바람에 옷은 흙으로 범범. ㅋㅋ 아직 어린 개같던데 심심한가보다.

다시 미시령으로 향하는 중 대포항 입구의 대게사랑에서 대게해장국과 물회를 먹고.
미시령터널로 이동. 중간에 종합관광안내소에서 안내지도물을 챙겼다.

역시나 가는길은 그렇게 멀게 느껴지지않았다. 미시령을 지나, 백담사 인근을 지나고.
함참을 다가보니 큰 강이 나오면서 38선휴개소라는게 있길래 쉬었더니, 소양강이란다.
정말 크구나하는 생각과 소양강 처녀는 이제 어딨나?

인제를 지나고, 춘천서울간 고속도로 진입. 서울까지는 쭉쭉 가더라. 서울도착 2시.
속초가는게 남해가는것 보다 훨씬 가깝다.
이제 남해를 가야할 차례이다.

소프트웨어 개발의 모든 것(김익환,전규현 지음. 페가수스)를 읽고 나서 중요한 몇 구절을 남겨본다.

요구사항의 중요성
소프트웨어 시스템 구축에서 가장 여려운 부분은 무엇을 구축할 것인지를 정확하게
판단하는 것이다. 그러나. 구현을 시작하기 전에 요구사항을 완벽하게 파악하는 것이
불가능한 경우가 많다. 그렇다고 해서 요구사항 개발에 소홀해서는 안 된다. 시간이
허락하는 한 최대한 많은 정보를 파악하는 것이 좋다.
 잘못된 요구사항은 많은 재작업 비용을 필요로 한다. 재작업 비용은 일반적으로 전체 개발
비용의 30~50%에 이르는 것으로 알려져 있다. 요구사항 오류로 인한 재작업 비용은 전체 재작업 비용의 70~85%에 이른다. 잘못된 요구사항, 부족한 요구사항은 일정을 지연시키며
많은 추가 비용을 발생시킨다.
 완벽하게 상세한 요구사항이 가장 좋은 요구사항은 아니다.
 요구사항은 이해하기 쉽게 간결함을 추구해야 한다. 간결하지만 충분히 설계, 구현할 수
있어야 한다. 그리고 요구사항 문서는 모든 관련자가 충분히 검토해야 한다.
요구사항 오류는 개발 단계가 지나가면 지나갈수록 그 수정비용이 기하급수로 증가한다.
유지보수 단계에서 비용이 더 드는 것으로 알려져 있다. 충분히 검토하여 오류가 없는
요구사항을 만드는 것이 프로젝트를 성공으로 이끄는데 가장 필요한 핵심이다.


SRS Template
1.Introduction(개요)
2.Overall Description(전체 설명)
3.Environment(환경)
4.External Interface Requirement(외부 인터페이스 요구사항)
5.Performance Requirement(성능 요구사항)
6.Non-Functional Reuirement(기능 이외의 요구사항)
7.Functional Requirement(기능요구사항)

코딩자세 : 소프트웨어를 잘 구현하기 위해서는 코딩을 함에 있어 반드시 지켜야 할 것들이 있다.
* 회사의 코딩표준을 철저히 지켜야 한다.
* 버그가 발견되면 그 즉시 버그를 고쳐라.
* 발견된 버그가 재현이 안 된다고 해서 버그가 사라진 것이 아니다.
* 문제 없이 작동하고 있는 코드를 괜히 정리하려고 하지 마라.
* 문제가 해결될 때까지 이렇게 저렇게 마구 고치지 마라.
* 코딩 작업을 작게 나누어서 코딩, 빌드, 테스트를 자주 반복하라.
* 중요하지 않은 버그는 하나도 없다.

회사의 코딩표준을 지켜야 하는 이유.
* 소스코드의 작성법을 통일하여 개발자들끼리 서로 코드를 더 쉽게 이해할 수 있게 한다.
* 개발자가 바뀌어도 빠른 시간 안에 소스코드를 파악 할 수 있게 한다.
* 흔히 저지르기 쉬운 사소한 실수를 방지하여 제품의 품질을 높인다.

품질관리
 소프트웨어프로젝트에서 품질은 소프트웨어가 얼마나 요구사항을 잘 만족시키고
 있는가의 정도이다. 품질은 전적으로 테스트에만 의존하는 것이 아니다.
 잘 만들어진 프로젝트 계획, 잘 분석된 요구사항, 각 단계의 철저한 리뷰,
체계적인 테스트 등 프로젝트 전 과정에 걸친 일련의 활동들이 모여서
제품의 품질을 보장하게 된다.
 많은 개발자들이 소프트웨어의 품질에 큰 관심을 두지 않는다. 현재 프로젝트를 끝내고
빨리 새로운 프로젝트를 하고 싶어한다. 현재의 문제는 유지보수에서 해결할 수 있을
것으로 생각하기도 한다. 이러한 생각은 제품의 품질을 떨어뜨리고, 제품을 제 때에
출시하지 못하게 만들기도 한다. 품질을 포기하고 제때 출시된 제품은 정시 출시에 대한
의미조차  없다. 고객들은 제품의 품질을 계속 기억할 것이고, 추후 더 나은 제품에 대한 기억이 사라지지 않을 것이다. 일반적으로 소프트웨어의 유지보수에 개발 지용의 2~5배가
지불된다고 알려져 있다. 최초에 낮은 품질로 출시된 제품은 유지보수 비용을 지속적으로 증가시킨다.
 유지보수 비용을 간과하면 장기적으로 제품의 수익성에 심각한 저하를 가져올 수 있다.
그럼에도 불구하고 소프트웨어 개발 시에 유지보수에 대해 신경을 쓰지 못하는 경우로
다음과 같은 것들이 있다.

* 당장 프로젝트가 발등에 떨어진 불이라서 유지보수에 대해서는 신경 쓸 겨를이 없다.
* 유지보수는 다른 개발팀이 맡을 것이므로 신경 쓰지 않는다.
* 경험이 별로 없어서 유지보수에 많은 비용이 드는지 몰랐다.
* 유지보수에 비용이 얼마나 드는지 정확하게 따져본 적이 없다.

제품의 품질을 유지보수 기간으로 넘길 것이 아니고, 지금 바로 품질에 대해서 신경을 쓰는 것이 경제적으로 더 바람직하다.

리스크 관리
리스크 계획 중 개발자가 퇴사할 징후가 보일때 다음과 같은 대응책을 마련할 수있다.
* 개발자가 퇴사하지 않도록 노력한다.
* 개발자가 퇴사하더라도 보충할 개발자를 미리 사내에서 물색해 놓는다.
* 사내에서 보충할 개발자를 찾지 못하면, 외부 채용 활동의 준비 단계를 해 놓는다.
   즉, 채용공지를 하고 이력서를 분석하여 채용자 후보를 미리 물색해 놓는다.
* 해당 개발자이 모듈을 다른 개발자와 많은 부분 공유하도록 계획한다.
* 아예 해당 개발자를 프로젝트에서 제외하고 진행한다.

동기 유발 요인 : 프로젝트에서 개발자의 동기를 유발하는 요인에는 다음과 같은 것들이 있다.
* 목표설정, 성취감, 성장가능성, 개인생활의 보장, 포상.

프로젝트 팀이 하는 작업 리스트
* SRS 작성 및 검토
* 소프트웨어 아키텍처 설계 논의
* 소프트웨어 컴포넌트와 인터페이스 논의
* 소프트웨어 설계 리뷰
* 소스코드 리뷰
* 결함 추척 및 해결
* 중요 이슈 논의
* 유지보수

성공하는 팀의 특징
* 훌륭한 기술리더가 있다.
* 도전적이고 실천가능한 목표와 비전을 공유하고 있다.
* 실력 있고 헌신적인 팀원들로 구성되어 있다.
* 팀원들간에 서로 신뢰한다.
* 팀원들간에 의사소통이 원활하다.
* 팀이 적절한 권한과 자율성이 있다.
* 팀워크를 유지하기에 알맞은 팀이다.

실패하는 팀
* 비전이 공유되어 있지 않다.
* 팀원들간에 서로 신뢰하지 않는다.
* 팀원들 간 의사소통이 원활하지 않다.
* 문제 팀원 방치.
 
필자의 경험에 의하면 프로젝트를 망치는 길은 지뢰밭과 같이 많아도
성공하기 위한 비법은 없다. 기본에 충실하고 기초와 문화가
각각 개발자들 몸에 배어서 앞에서 언급된 여러 활동들이 종합적으로
자연스럽게 이루어 질 때 소프트웨어 프로젝트 성공이 좀더 가까워 질 것이다.

개발자들은 가장 먼저
* SRS를 작성해야 한다고 생각하고,
* SRS를 작성하면서 모든 관련자와 철저히 리뷰를 하고,
* 프로젝트 관리자는 개발자들과 함께 1,2일 단위의 상세 일정을 작성하고,
* 테스트팀은 SRS를 보고 테스트 Suite를 만들기 시작하고,
* 개발 리더들은 화이트보드나 종이를 펼쳐놓고 아키텍처에 대해 토론을 하며,
* 구현 시 모든 소스코드는 당연히 리뷰를 하고,
* 개발자는 매일 스스로 일정을 업데이트하고,
* 소스코드 작성은 일일빌드가 깨지지 않으면서 이루어지며,
* 소스코드관리시스템과 버그관리시스템을 효과적으로 사용하며,
* 알파, 베타 단계 별로 모든 프로젝트 관련자들이 유기적으로 움직이며,
* 일정에 맞춰 완성도 있는 품질의 제품을 출시한다.

위와 같은 활동들이 당연하다고 생각되고 몸에 배어야 한다.
이러한 것들을 규칙만으로 통제를 해서는 달성하기 어렵고 한꺼번에 모두 다 습득하기도 어렵다.
하나씩 익혀서 몸에 배었을 때 소프트웨어 프로젝트를 성공하는 원리가 보이기 시작하고,
좋은 제품을 만들 수 있을 것이다.