jspGeek.com

iPad Specs - 카메라가 없당!!!

theclub — Thu, 28 Jan 2010 08:52:26 +0900

원문 :http://www.apple.com/ipad/specs/

Technical Specifications

Size and weight¹

Height:: 9.56 inches (242.8 mm)
Width:: 7.47 inches (189.7 mm)
Depth:: 0.5 inch (13.4 mm)
Weight:: 1.5 pounds (.68 kg) Wi-Fi model;; 1.6 pounds (.73 kg) Wi-Fi + 3G model

Display

9.7-inch (diagonal) LED-backlit glossy widescreen Multi-Touch display with IPS technology
1024-by-768-pixel resolution at 132 pixels per inch (ppi)
Fingerprint-resistant oleophobic coating
Support for display of multiple languages and characters simultaneously

Wireless and Cellular

Wi-Fi model

Wi-Fi (802.11 a/b/g/n)
Bluetooth 2.1 + EDR technology

Wi-Fi + 3G model

UMTS/HSDPA (850, 1900, 2100 MHz)
GSM/EDGE (850, 900,1800, 1900 MHz)
Data only²
Wi-Fi (802.11 a/b/g/n)
Bluetooth 2.1 + EDR technology

Location

Wi-Fi
Digital compass
Assisted GPS (Wi-Fi + 3G model)
Cellular (Wi-Fi + 3G model)

In the Box

iPad
Dock connector to USB cable
10W Power Adapter
Documentation

Environmental Status Report

iPad embodies Apple’s continuing environmental progress. It is designed with the following features to reduce environmental impact:

Arsenic-free display glass
BFR-free
Mercury-free LCD display
PVC-free
Recyclable aluminum and glass enclosure

Capacity³

16GB, 32GB, or 64GB flash drive

Processor

1GHz Apple A4 custom-designed, high-performance, low-power system-on-a-chip

Sensors

Accelerometer
Ambient light sensor

Audio Playback

Frequency response: 20Hz to 20,000Hz
Audio formats supported: AAC (16 to 320 Kbps), Protected AAC (from iTunes Store), MP3 (16 to 320 Kbps), MP3 VBR, Audible (formats 2, 3, and 4), Apple Lossless, AIFF, and WAV
User-configurable maximum volume limit

TV and Video

Support for 1024 x 768 with Dock Connector to VGA adapter; 576p and 480p with Apple Composite A/V Cable, 576i and 480i with Apple Composite A/V Cable
H.264 video up to 720p, 30 frames per second, Main Profile level 3.1 with AAC-LC audio up to 160 Kbps, 48kHz, stereo audio in .m4v, .mp4, and .mov file formats; MPEG-4 video, up to 2.5 Mbps, 640 by 480 pixels, 30 frames per second, Simple Profile with AAC-LC audio up to 160 Kbps, 48kHz, stereo audio in .m4v, .mp4, and .mov file formats

Mail attachment support

Viewable document types: .jpg, .tiff, .gif (images); .doc and .docx (Microsoft Word); .htm and .html (web pages); .key (Keynote); .numbers (Numbers); .pages (Pages); .pdf (Preview and Adobe Acrobat); .ppt and .pptx (Microsoft PowerPoint); .txt (text); .rtf (rich text format); .vcf (contact information); .xls and .xlsx (Microsoft Excel)

Languages

Language support for English, French, German, Japanese, Dutch, Italian, Spanish, Simplified Chinese, Russian
Keyboard support for English (US) English (UK), French (France, Canada), German, Japanese (QWERTY), Dutch, Flemish, Spanish, Italian, Simplified Chinese (Handwriting and Pinyin), Russian
Dictionary support for English (US), English (UK), French, French (Canadian), French (Swiss), German, Japanese, Dutch, Flemish, Spanish, Italian, Simplified Chinese (Handwriting, Pinyin), Russian

Accessibility

Support for playback of closed-captioned content
VoiceOver screen reader
Full-screen zoom magnification
White on black
Mono audio

Battery and Power⁴

Built-in 25Whr rechargeable lithium-polymer battery
Up to 10 hours of surfing the web on Wi-Fi, watching video, or listening to music
Charging via power adapter or USB to computer system

Input and Output

Dock connector
3.5-mm stereo headphone jack
Built-in speakers
Microphone
SIM card tray (Wi-Fi + 3G model only)

External buttons and controls

On/Off, Sleep/wake
Mute
Volume up/down
Home

Mac system requirements

Mac computer with USB 2.0 port
Mac OS X v10.5.8 or later
iTunes 9.0 or later (free download from www.itunes.com/download)
iTunes Store account
Internet access

Windows system requirements

PC with USB 2.0 port
Windows 7, Windows Vista; Windows XP Home or Professional with Service Pack 3 or later
iTunes 9.0 or later (free download from www.itunes.com/download)
iTunes Store account
Internet access

Environmental requirements

Operating temperature: 32° to 95° F (0° to 35° C)
Nonoperating temperature: -4° to 113° F (-20° to 45° C)
Relative humidity: 5% to 95% noncondensing
Maximum operating altitude: 10,000 feet (3000 m)

iPad Accessories

iPad Keyboard Dock

The Keyboard Dock is a dock for charging your iPad, integrated with a full-size keyboard. The dock has a rear 30-pin connector, which lets you connect to an electrical outlet using a USB Power Adapter, sync to your computer, and use accessories like the Camera Connection Kit. And an audio jack lets you connect to a stereo or powered speakers.

View Gallery:

iPad Case

The iPad Case not only protects the iPad, it can be used in various positions. So it’s easy to type, look at photos and slideshows, or watch movies.

View Gallery:

iPad Dock

The iPad Dock lets you dock and charge iPad. The rear 30-pin connector lets you connect the iPad Dock to an electrical outlet using the USB Power Adapter, sync to your computer, and use accessories like the Camera Connection Kit. And an audio jack lets you connect to a stereo or powered speakers.

iPad Camera Connection Kit

The Camera Connection Kit gives you two ways to import photos and videos from a digital camera. The Camera Connector lets you import your photos and videos to iPad using the camera’s USB cable. Or you can use the SD Card Reader to import photos and videos directly from the camera’s SD card.

iPad USB Power Adapter

The 10W USB Power Adapter lets you charge your iPad directly through an electrical outlet. And the 6 foot long power cable allows you to charge it from an even greater distance.

iPad

theclub — Thu, 28 Jan 2010 08:19:43 +0900

[IT수다떨기]모바일 앱스토어 생태계에 ‘풍덩’ 빠져보자

theclub — Mon, 11 Jan 2010 09:43:47 +0900

출처 : http://www.bloter.net/archives/23062

새로운 바람이 분다. 소프트웨어 개발자 사이에 불고 있는 스마트폰용 애플리케이션 개발 바람이다. 부러운 눈길로 쳐다보고 있다.

이번 바람은 기존에 있던 소프트웨어 생태계와는 질적으로 다르다는 점에서 주목할 필요가 있다.

그간 소프트웨어 개발자 지원에 나섰던 IT 업체 담당자들은 더 이상 인재들이 유입되지 않고 있고, 그나마 있던 개발자들도 떠나고 있다고 우려해 왔다. 이같은 상황이 하루 아침에 변하지는 않을 것이다. 오히려 더욱 가속화될 수 있다. 소프트웨어에 대한 가치는 논외로 치더라도 여전히 ‘월화수목금금금’을 감내해야만 한다면 말이다. 정부와 대기업, 중소 소프트웨어 개발업체는 선순환 생태계 마련에 실패했다. 문제를 해결하는 것도 요원하다. 이런 곳에 몸바칠 개발자들이 있다면 오히려 이상할 정도다.

외국 IT기업의 임원들을 만나 우리나라 소프트웨어 산업에 대한 조언을 부탁할 때마다 빠지지 않는 것이 있다. “처음부터 세계 시장을 겨냥해라. 미리 해외로 나가라”라는 말이다. 그러면서 자주 언급하는 나라가 이스라엘이다. 국내 시장 규모 자체가 너무나 작은 이스라엘은 처음부터 해외로 눈을 돌리고 개발할 수밖에 없는 처지인데 우리도 이를 벤치마킹해 보라는 것이다. 하지만 지난 10년간 IT 분야에서 일해왔지만 그런 업체들은 거의 못봤다. 대부분 국내에서 시작해 일단 관공서에 제품을 공급하고 착실히 점유율을 넓힌 후에 민간 시장에 진출하고 그리고 나서 여유가 되면 해외 시장에 눈을 돌렸다.

그런데 ‘처음부터 세계시장을 겨냥’할 수 있는 분야가 탄생했다. 바로 모바일 앱스토어 생태계다. 가트너는 지난해 1억8천만 대 가량 판매된 스마트폰이 올해는 2억7천만 대 가량으로 늘어날 것으로 예측했다. 또 스마트폰 운영체제는 심비안과 안드로이드, 리서치인모션, 아이폰, 마이크로소프트 윈도우 폰 등 상위 5대 제품이 전체 시장의 93.9%를 차지할 것으로 내다봤다.모바일 생태계의 선순환 구조를 만들어 낸 애플은 지난 6일 아이폰용 응용프로그램 다운로드가 30억 회를 돌파했다고 밝혔다. 이런 성과가 불과 18개월 만에 나온 결과라는 점에서 전세계 개발자들과 소비자들이 이런 선순환 생태계를 환영하고 있다는 걸 잘 보여주고 있다.

애플이 신호탄을 쏘아올린 모바일 앱스토어 생태계는 국내 소프트웨어 개발자들에게 새로운 돌파구를 마련해 줬다. 기존 패키지 소프트웨어 업체들이 갔던 길을 그대로 따라가지 않아도 된다. 또 이동통신사에 제품을 제공하기 위해 수많은 시간과 노력과 돈을 허비하지 않아도 된다. 대기업의 횡포도 없다. 오로지 자신의 능력 하나로 전세계 수많은 사용자에게 직접 다가설 수 있게 됐다. “처음부터 세계 시장을 겨냥”할 딱 들어맞는 분야가 바로 모바일 앱스토어 생태계다. 어디에 좌판을 깔지 스스로 결정하기만 하면 된다.

1인 창업자들이 쏟아지고 있고, 앱 전문 회사들도 대거 등장할 조짐이다. 시장 변혁기에는 언제나 거품이 끼기 마련이지만 이번 거품은 걱정보다 기대가 크다. 전세계 사용자들의 입맛에 맞는 제품을 만들기 위해서는 기술 못지 않게 사용자들에 대한 분석이 필요하다. 우리나라 개발자들이나 전문 개발회사들은 모바일 애플리케이션을 개발해 가는 과정에서 전세계인들과 소통하기 위해 노력할 것이기 때문이다. 어떤 제품이 인기를 끌고 있는지 발빠르게 파악하고 대응할 것이다.

우리가 이전에 만나보지 못했던 새로운 유형의 개발자들이 탄생할 것이다. 성공 신화도 만나게 될 것이고 실패 사례도 만날 것이다. 하지만 해외 시장 개척을 위해 ‘눈물 젖은 빵’을 먹어가며, 읍소를 밥먹듯이 하며, ‘월화수목금금금’ 일만 해 왔다는 선배 세대의 성공담은 더 이상 이 분야에서 듣지 않을 것 같다. “즐겁고, 재미나게 만들다 보니 이렇게 됐어요”라는 말들이 더 많아질 것이다.

기존 산업계는 더욱 긴장을 해야한다. 이미 보유한 인재들을 잡아놓기 위한 방안도 마련해야 하고, 새로운 모바일 앱스토어 생태계를 활용해 새로운 기회를 잡기 위해 머리를 싸매야 한다. 유행처럼 번지는 분야에 사람과 돈이 몰리는 것은 당연하다. 친구따라 강남도 가는 마당에 친구따라 해외 소비자들에게 좌판깔고 지갑을 두둑히 할 수 있는 일에 안 나설 이들이 누가 있겠는가?

새로운 도전에 걸림돌도 많지만, 올 한해 멋진 도전을 시작하시라. 도전 자체만으로 이미 이전과는 다른 자신을 발견할 것이다. 기술을 가진 이들이 부러운 새해 벽두다.

Spring JTA TransactionManager config: Supporting both Tomcat and JBoss

theclub — Fri, 25 Dec 2009 18:54:26 +0900

출처 : http://stackoverflow.com/questions/117751/spring-jta-transactionmanager-config-supporting-both-tomcat-and-jboss

I have a web application using JPA and JTA with Spring. I would like to support both JBoss and Tomcat. When running on JBoss, I'd like to use JBoss' own TransactionManager, and when running on Tomcat, I'd like to use JOTM.

I have both scenarios working, but I now find that I seem to need two separate Spring configurations for the two cases. With JOTM, I need to use Spring's JotmFactoryBean:

<bean id="transactionManager" 
 class="org.springframework.transaction.jta.JtaTransactionManager">
    <property name="userTransaction">
        <bean class="org.springframework.transaction.jta.JotmFactoryBean"/>
    </property>
</bean>

In JBoss, though, I just need to fetch "TransactionManager" from JNDI:

<bean id="transactionManager" 
 class="org.springframework.transaction.jta.JtaTransactionManager">
    <property name="transactionManager">
        <bean class="org.springframework.jndi.JndiObjectFactoryBean">
             <property name="resourceRef" value="true" />
             <property name="jndiName" value="TransactionManager" />
             <property name="expectedType" 
               value="javax.transaction.TransactionManager" />
        </bean>
    </property>
</bean>

Is there a way to configure this so that the appropriate TransactionManager - JBoss or JOTM - is used, without the need for two different configuration files?

New Features and Enhancements in Spring 3.0

theclub — Fri, 18 Dec 2009 10:19:19 +0900

출처 : http://static.springsource.org/spring/docs/3.0.0.RELEASE/reference/html/new-in-3.html

2. New Features and Enhancements in Spring 3.0

If you have been using the Spring Framework for some time, you will be aware that Spring has undergone two major revisions: Spring 2.0, released in October 2006, and Spring 2.5, released in November 2007. It is now time for a third overhaul resulting in Spring 3.0.

2.1 Java 5

The entire framework code has been revised to take advantage of Java 5 features like generics, varargs and other language improvements. We have done our best to still keep the code backwards compatible. We now have consistent use of generic Collections and Maps, consistent use of generic FactoryBeans, and also consistent resolution of bridge methods in the Spring AOP API. Generic ApplicationListeners automatically receive specific event types only. All callback interfaces such as TransactionCallback and HibernateCallback declare a generic result value now. Overall, the Spring core codebase is now freshly revised and optimized for Java 5.

Spring's TaskExecutor abstraction has been updated for close integration with Java 5's java.util.concurrent facilities. We provide first-class support for Callables and Futures now, as well as ExecutorService adapters, ThreadFactory integration, etc. This has been aligned with JSR-236 (Concurrency Utilities for Java EE 6) as far as possible. Furthermore, we provide support for asynchronous method invocations through the use of the new @Async annotation (or EJB 3.1's @Asynchronous annotation).

2.2 Improved documentation

The Spring reference documentation has also substantially been updated to reflect all of the changes and new features for Spring 3.0. While every effort has been made to ensure that there are no errors in this documentation, some errors may nevertheless have crept in. If you do spot any typos or even more serious errors, and you can spare a few cycles during lunch, please do bring the error to the attention of the Spring team by raising an issue.

2.3 New getting started tutorial

There is now a new getting started tutorial for developing a basic Spring 3.0 MVC web application. This tutorial is a separate document that can be found at the Spring Documentation page.

2.4 New module organization and build system

The framework modules have been revised and are now managed separately with one source-tree per module jar:

org.springframework.aop
org.springframework.beans
org.springframework.context
org.springframework.context.support
org.springframework.expression
org.springframework.instrument
org.springframework.jdbc
org.springframework.jms
org.springframework.orm
org.springframework.oxm
org.springframework.test
org.springframework.transaction
org.springframework.web
org.springframework.web.portlet
org.springframework.web.servlet
org.springframework.web.struts

We are now using a new Spring build system as known from Spring Web Flow 2.0. This gives us:

Ivy-based "Spring Build" system
consistent deployment procedure
consistent dependency management
consistent generation of OSGi manifests

2.5 Overview of new features

This is a list of new features for Spring 3.0. We will cover these features in more detail later in this section.

Spring Expression Language
IoC enhancements/Java based bean metadata
General-purpose type conversion system and field formatting system
Object to XML mapping functionality (OXM) moved from Spring Web Services project
Comprehensive REST support
@MVC additions
Declarative model validation
Early support for Java EE 6
Embedded database support

2.5.1 Core APIs updated for Java 5

BeanFactory interface returns typed bean instances as far as possible:

T getBean(Class<T> requiredType)
T getBean(String name, Class<T> requiredType)
Map<String, T> getBeansOfType(Class<T> type)

Spring's TaskExecutor interface now extends java.util.concurrent.Executor:

extended AsyncTaskExecutor supports standard Callables with Futures

New Java 5 based converter API and SPI:

stateless ConversionService and Converters
superseding standard JDK PropertyEditors

Typed ApplicationListener<E>

2.5.2 Spring Expression Language

Spring introduces an expression language which is similar to Unified EL in its syntax but offers significantly more features. The expression language can be used when defining XML and Annotation based bean definitions and also serves as the foundation for expression language support across the Spring portfolio. Details of this new functionality can be found in the chapter Spring Expression Language (SpEL).

The Spring Expression Language was created to provide the Spring community a single, well supported expression language that can be used across all the products in the Spring portfolio. Its language features are driven by the requirements of the projects in the Spring portfolio, including tooling requirements for code completion support within the Eclipse based SpringSource Tool Suite.

The following is an example of how the Expression Language can be used to configure some properties of a database setup

<bean class="mycompany.RewardsTestDatabase">
    <property name="databaseName"
        value="#{systemProperties.databaseName}"/>
    <property name="keyGenerator"
        value="#{strategyBean.databaseKeyGenerator}"/>
</bean>

This functionality is also available if you prefer to configure your components using annotations:

@Repository 
public class RewardsTestDatabase {

    @Value("#{systemProperties.databaseName}")
    public void setDatabaseName(String dbName) { … }

    @Value("#{strategyBean.databaseKeyGenerator}")
    public void setKeyGenerator(KeyGenerator kg) { … }
}

2.5.3 The Inversion of Control (IoC) container

2.5.3.1 Java based bean metadata

Some core features from the JavaConfig project have been added to the Spring Framework now. This means that the following annotations are now directly supported:

@Configuration
@Bean
@DependsOn
@Primary
@Lazy
@Import
@ImportResource
@Value

Here is an example of a Java class providing basic configuration using the new JavaConfig features:

package org.example.config;

@Configuration
public class AppConfig {
    private @Value("#{jdbcProperties.url}") String jdbcUrl;
    private @Value("#{jdbcProperties.username}") String username;
    private @Value("#{jdbcProperties.password}") String password;

    @Bean
    public FooService fooService() {
        return new FooServiceImpl(fooRepository());
    }

    @Bean
    public FooRepository fooRepository() {
        return new HibernateFooRepository(sessionFactory());
    }

    @Bean
    public SessionFactory sessionFactory() {
        // wire up a session factory
        AnnotationSessionFactoryBean asFactoryBean = 
            new AnnotationSessionFactoryBean();
        asFactoryBean.setDataSource(dataSource());
        // additional config
        return asFactoryBean.getObject();
    }

    @Bean
    public DataSource dataSource() { 
        return new DriverManagerDataSource(jdbcUrl, username, password);
    }
}

To get this to work you need to add the following component scanning entry in your minimal application context XML file.

<context:component-scan base-package="org.example.config"/>
<util:properties id="jdbcProperties" location="classpath:org/example/config/jdbc.properties"/>

Or you can bootstrap a @Configuration class directly using AnnotationConfigApplicationContext:

public static void main(String[] args) {
    ApplicationContext ctx = new AnnotationConfigApplicationContext(AppConfig.class);
    FooService fooService = ctx.getBean(FooService.class);
    fooService.doStuff();
}

See Section 3.11.2, “Instantiating the Spring container using AnnotationConfigApplicationContext” for full information on AnnotationConfigApplicationContext.

2.5.3.2 Defining bean metadata within components

@Bean annotated methods are also supported inside Spring components. They contribute a factory bean definition to the container. See Defining bean metadata within components for more information

2.5.4 General purpose type conversion system and field formatting system

A general purpose type conversion system has been introduced. The system is currently used by SpEL for type conversion, and may also be used by a Spring Container and DataBinder when binding bean property values.

In addition, a formatter SPI has been introduced for formatting field values. This SPI provides a simpler and more robust alternative to JavaBean PropertyEditors for use in client environments such as Spring MVC.

2.5.5 The Data Tier

Object to XML mapping functionality (OXM) from the Spring Web Services project has been moved to the core Spring Framework now. The functionality is found in the org.springframework.oxm package. More information on the use of the OXM module can be found in the Marshalling XML using O/X Mappers chapter.

2.5.6 The Web Tier

The most exciting new feature for the Web Tier is the support for building RESTful web services and web applications. There are also some new annotations that can be used in any web application.

2.5.6.1 Comprehensive REST support

Server-side support for building RESTful applications has been provided as an extension of the existing annotation driven MVC web framework. Client-side support is provided by the RestTemplate class in the spirit of other template classes such as JdbcTemplate and JmsTemplate. Both server and client side REST functionality make use of HttpConverters to facilitate the conversion between objects and their representation in HTTP requests and responses.

The MarshallingHttpMessageConverter uses the Object to XML mapping functionality mentioned earlier.

Refer to the sections on MVC and the RestTemplate for more information.

2.5.6.2 @MVC additions

A mvc namespace has been introduced that greatly simplifies Spring MVC configuration.

Additional annotations such as @CookieValue and @RequestHeaders have been added. See Mapping cookie values with the @CookieValue annotation and Mapping request header attributes with the @RequestHeader annotation for more information.

2.5.7 Declarative model validation

Several validation enhancements, including JSR 303 support that uses Hibernate Validator as the default provider.

2.5.8 Early support for Java EE 6

We provide support for asynchronous method invocations through the use of the new @Async annotation (or EJB 3.1's @Asynchronous annotation).

JSR 303, JSF 2.0, JPA 2.0, etc

2.5.9 Support for embedded databases

Convenient support for embedded Java database engines, including HSQL, H2, and Derby, is now provided.

url-pattern에서 / 와 /*의 차이점

theclub — Wed, 09 Dec 2009 19:48:41 +0900

Spring framework이 유행하고 REST Style URL이 유행하면서 직면하는 문제가 하나 있다.

다음과 같은 url로 서비스를 한다고 가정해보자.
/article
/article/1
/article/add

음 갈끔한 URL이다. ㅋ

그러면 web.xml에 다음과 같이 url-pattern을 설정하게 된다.

<servlet>
    <servlet-name>dispatcher</servlet-name>
    <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
</servlet>
<servlet-mapping>
    <servlet-name>dispatcher</servlet-name>
    <url-pattern>/*</url-pattern>
</servlet-mapping>

REST Style의 url을 가져야 함으로 url-pattern은 /* 처럼 걸어야 한다.
.do와 같은 확장자를 가져서는 안된다. <-- 촌스러... ㅋㅋ

아 물론 viewResolver는 간단히 아래처럼 걸었다. 물론 default다. 흐


<bean id="viewResolver"
    class="org.springframework.web.servlet.view.UrlBasedViewResolver">
    <property name="viewClass"
        value="org.springframework.web.servlet.view.JstlView" />
    <property name="prefix" value="/WEB-INF/jsp/" />
    <property name="suffix" value=".jsp" />
</bean>

이렇게 하고 /article을 호출하면, 다음과 같은 에러를 만나게 된다.

경고: No mapping found for HTTP request with URI [/WEB-INF/jsp/article.jsp] in DispatcherServlet with name 'dispatcher'

흐... RequestMapping를 타고나서, jsp를 호출하려고 하였더니, /* url-pattern에 걸려들어 에러가 나는 것이다.

이를 어쩌란 말인가??? 흐

여기서 등장하는 것이 우리의 servlet spec이다.

SRV.11.2 Specification of Mappings 를 보면 아래와 같이 나와 있다.

In theWeb application deployment descriptor, the following syntax is used to define mappings:
1. A string beginning with a ‘/’ character and ending with a ‘/*’ suffix is used for path mapping.
2. A string beginning with a ‘*.’ prefix is used as an extension mapping.
3. A string containing only the ’/’ character indicates the "default" servlet of the application. In this case the servlet path is the request URI minus the context path and the path info is null.
4. All other strings are used for exact matches only.

1, 2, 4는 알겠는데, 3번은 좀 그렇다. ㅋ 우리의 주인공은 바로 이 3번이다. 3번을 보면 '/'만 딸랑 있을 경우에는 default servlet를 탄다고 한다. 아 그런데 그래서 뭐? default servlet이 먼데? 뭘 어쩌라는 거야?

ㅋ, 아! 톰켓을 참조하도록 하자. 톰켓의 conf/web.xml를 열어서 default servlet을 찾아보자. 그러면 주석에 이런 말이 나온다.







It processes all requests that are not mapped to other servlets with servlet mappings

이런 말이 있다. 이 default servlet은 servlet mapping에 하나도 걸리지 않는 녀석들을 처리한다고 한다. 온갖 mapping을 통과해 버린 녀석들을 말하는 것이다. 그러면 뭐가 남을까? 바로 jpg, html 등 정적인 리소스만 남게 된다. 톰켓만으로도 이미지를 보여 줄 수 있는 것은 이 default servlet이 있기 때문이다.

흐하하하하하하~ 여기서 살짝 잔머리를 굴려 보자.. ㅋㅋ

일반적으로 web과 was를 분리해서 쓰니까, jpg나 html 등 정적인 리소스는 web 서버가 맡아서 해야한다. 그리고 나머지들은 was로 넘어 와야 한다. 위의 상황의 문제는 *.jsp가 DispatcherServlet를 타면 안되는 상황이다. ㅋ, jsp는 was에서 처리를 해야 하는 것이지만 /* url-pattern에 의해서 DispatcherServlet를 타면 안되는 상황이다.

ㅋㅋ 원래 default servlet의 목적을 살짝쿵 바꿔 버리는 것이다.

그런데, SRV.11.2.1 Implicit Mappings에 나와 있는 것처럼, *.jsp는 이미 mapping되어 있다. 톰켓안에 벌써 되어 버려 있다. 물론 이 conf/web.xml 파일 안에 말이다. ㅋㅋ

그러므로 *.jsp는 톰켓에 걸려 있는 servlet을 타면 되고, 이를 통과한 /article은 default servlet을 타면 된다는 것이다. 이야... 쥑인다!!!!!

앗 그런데, conf/web.xml에 이미 default servlet이 설정되어 있다. 앗.. 어쩌지? ㅋㅋ SRV.11.2.1 Implicit Mappings(If a *.jsp mapping is defined by the Web application, its mapping takes precedence over the implicit mapping.) 에 나와 있는 것처럼 해당 web application에 재정의를 하게 되면, implicit Mapping 보다 우선적으로 적용된다고 한다. 흐흐.

이렇게 해서 *.jsp를 제외하고 Spring의 DispatcherServlet을 태울 수 있는 것이다. 아래처럼 url-pattern만 /* 에서 /로 바꿔 버리면 된다. 아래처럼.. 흐

<servlet-mapping>
    <servlet-name>dispatcher</servlet-name>
    <url-pattern>/</url-pattern>
</servlet-mapping>

Java 7 chapter 1: The Virtual Machine

theclub — Tue, 08 Dec 2009 10:26:52 +0900

주소 : http://harals.blogspot.com/2009/12/java-7-chapter-1-virtual-machine.html

To prepare for the arrival of the Dolphin, I will indulge in some research entitled "What's new in Java 7". The story will consist of 5 chapters: the vm, the language, the core, the client and the Web. First came the change to the virtual machine.

CompressedOops
OOP is an “ordinary object pointer”, and it’s length is usually similar to the length of the native operating system pointer. Increasing the length from 32 to 64 bits will cause the heap in a 32-based program (running on a 64-bit system) to expand by 50%. Memory is cheap, but bandwidth and cache is expensive, and it is should not be very costly to port applications a new platform. Using a 64 bit vm and the UseCompressedOops flag will keep addressing overhead similar to that of 32 bit systems at the cost of cpu cycles.

Garbage First GC (“G1”)
Replacement for Concurrent-Mark-Sweep GC, but still “generational”. CMS divides memory into young generation (eden, survivor) and and old generation. Move live object into a more “persistent” generation. Stops the world to do complete collections. G1 divides memory into small “regions”, and these are labeled “young” or “old”. During a GC, those objects who are “live” in a region, will be compacted with other “live” objects in another region, depending on their age. Each region has a “remembered set”, which contains all external references to this region. This reduces the need to pause the world to mark.

G1 is a server-style garbage collector, targeted for multiprocessor- and large memory systems. It aims at being more predictable than CMS. It’s also available in 6u14.

JSR 292: The Da Vinci Machine Project
The JVM should be extended with general support of languages other than Java, and in particular dynamically typed languages. Such language implementers have observed a range of painful aspects of the byte code language, and this projects aims to remove those in a general manner. The noteworthy suggestions is: dynamic invocation, continuations, tail-calls and interface injection. The JSR specifically targets dynamic invocation and hot class modification. Today dynamic languages produces a lot of different options for signatures that all have to be stored in permgen space. This is very inefficient, and one should be able to narrow down these options at runtime.

Hibernate Vs JDBC Performance Comparison

theclub — Mon, 30 Nov 2009 16:16:24 +0900

주소 : http://itspice.net/cms/enterprise-java/hibernate-vs-jdbc-performance-comparison

The Hibernate advantage over JDBC

Concurrency Support

In JDBC there is no check that always every user has updated data this check has to be added by the developer. Hibernate maintains this concurrency check using a version field.It checks this version field in the database table before every update operation.

So, if two users retrieve data from the same table and modify it and if one of them saves the modification, the version gets updated. Now when the second user tries to save his data hibernate doesn’t allow it because the data he retrieved was modified and his version doesn’t match with the version in the database.

Caching and Connection Pooling

In JDBC, caching and connection pooling is maintained by hand-coding. Hibernate provides excellent caching support and connection pooling for better application performance.

Transaction Management

In JDBC one has to explicitly handle transaction management in the code. Hibernate provides injected transaction management.

Programming Overhead

In JDBC one has to do a lot of coding in the form of SQL queries to handle persistent data in database. In Hibernate there is no need to write code in the form of SQL queries to save and retrieve the data, thus reduces programming overhead and development time.

Maintenance Costs

Applications using JDBC contain large amounts of code that handles database persistent data. This code is subjected to changes whenever there is a change in database table structure leading to high maintenance cost.

In Hibernate the actual mapping between database tables and program objects is done in a XML descriptor file. So any changes to a database table will only need a change in the XML file resulting in centralized maintenance and reduction of maintenance costs.

Pinaki Mukherjee

A tenacious and successful Software professional with full project life cycle and consulting experience in real-time and non-real-time finance, telecom and government projects.

An Oracle certified professional with extensive java experience and now a certified ScrumMaster.
Also experienced in product promotion and pre-sales consulting.

Implementing HTTP sessions for Web Applications spread across multiple physical servers (or JVMs)

theclub — Mon, 30 Nov 2009 16:06:00 +0900

주소 : http://itspice.net/cms/web-internet/how-to-implement-session-for-a-web-app-spread-on-multiple-servers

Say your Web Application is spread across multiple physical servers (or may be on the same server, but using different JVMs which is of course a rarity) which might have been done to balance the load of your application OR may be the requirement is such that separate physical servers is a need than a luxury. Whatever be the case, in such a scenario if a user say log into one of the machines (JVMs to be specific) and then s/he is taken to some other Servlet/JSP running on some other server (JVM) to fulfill the client request. Now if that Servlet/JSP also requires authentication (which it would in most of the practical scenarios) then the user would be prompted to enter his/her credentials once again which s/he would of course not like. It’s the applications responsibility to transfer the credentials from one server (JVM) to another)… right?

Using Persistent Sessions, we can easily achieve a solution to this complex problem. This approach requires the session to be saved in a data source which can easily be accessed by any of the scattered servers (JVMs) and the client gets a feeling that his application is virtually running on a single server (JVM). It’s a better practice to have a completely separate data Source just for the purpose of session persistence and not to integrate session data with the application data source(s) for the obvious reason of making the overall implementation loosely coupled and hence better maintainable and more scalable.

기존 개발팀이 모바일로 이행하기 위한 플랫폼 비교

theclub — Wed, 25 Nov 2009 17:42:28 +0900

주소 : http://blog.daum.net/effortless/7864583

스마트폰이 세상을 바꿔 놓을 것이라고들 하는데, 우리팀에서도 뭔가 해야 하는거 아냐?라는 불안함이 있다면 참고하시기 바랍니다.

기존 서버/웹/일반응용/SI 개발하던 사람들에게 모바일은 참 낯선 환경입니다.

혼란을 좀 줄여 보고자, 한두달 검토한 내용을 정리해 봤습니다.

1. 우리팀이 모바일 개발을 할 때, 아이폰으로 갈까?

구분	설명
장점	단일 사용자 인터페이스 - 해상도/UI가 거의 동일하다. 해상도가 달라서 생기는 UI개발상의 어려움이 거의 없다.
	단일 H/W 서포트 - 하드웨어 제작사가 Apple 한 회사여서, 하드웨어 때문에 말썽 피우는 일이 없다.
	개발 툴킷 통합성 - XCode/Objective-C/Apple/iTunes로 대변되는 툴킷 및 환경은 매우 훌륭하다.
	마켓의 성숙성 - 활발하고 거래가 잦은 앱스토어가 있다. 대박의 가능성이 있다.
단점	개발자 진입 장벽 - 국내의 대부분의 개발자들은 Apple 및 XCode상의 개발을 해 본적이 없다. 완전히 새로 배워야 한다. 일단 개발하려면 비싼 맥북부터 구입해야 한다.
	애플사의 정책 - 애플사는 앱스토어에 올릴 때, 엄격한 검사를 하는데, 애플의 검사를 통과하지 못하면 앱스토어에 올리지 못한다. 이것에 대해서 불평이 상당하다. 앱스토어에 올리는 비용도 제법(?) 든다.
	치열한 경쟁 - 이미 레드오션이나 다름없다. 개인들이 취미로 개발할 것이 아니고, 팀 단위 이상의 수익성을 바란다면, 상당한 개발력을 투입하여야 (적어도3~4M/M) 하며, 그게 수익을 가져다 줄지는 아무도 보장해 주지 못한다. 이미 완성도가 높은 애플릿들로 넘친다.
	국내시장의 낮은 점유율 - 국내에서는 잘나가도 50만대, 무지 크게 잡아도 100만대 수준에서 멈출 것이다. 전체 시장의 5% 미만이라는 뜻이다. 기업이 기대할 수준의 수익을 가져다 주기에는 너무 작은 시장이다. 개인이 취미로 하자면, 큰 문제가 없을 것이다.
대응방안	개발할 대상에 따라 다른 것 같다. - 낮은 국시장 점유율에서라도 수익을 낼 수 있을 것 같으면, 아이폰이 적당하다. 국내용이 아니고, 세계 시장에 팔 수 있는 것이라면, 아이폰은 환상적인 플랫폼이다. 좀 럭셔리하고(?), 여유있는(?) 개인 개발자라면, 아이폰 만큼 좋은 취미생활이 따로 없다. 단 돈은 바라지 않는 게 좋다. 아마 개발하면서 먹은 햄버거와 콜라 값 정도나 간신히 나올 것이다. 어쩌다 운 좋아서 2~30만원을 넘겨도 그걸로 끝이다. 세계에 팔 수 있는 능력이 있는지 한번 테스트해 보기 바란다. 아마 그럴 수 있다면, 굳이 아이폰에서 개발 않고, 자기 블로그만 으로도 비슷한 수익을 만들 수 있을 것이다.
대응방안	솔루션 개발사라면, 5%도 안되는 아이폰 고객들의 등쌀에 못 이겨, 어떤 식으로든 자사 솔루션에 대한 아이폰 인터페이스를 만들어 내야 할 것이다. 안그러면 솔루션 자체가 안 팔릴 테니까… 이때는 수익보다는 개발비용 감소에 초점을 맞춰야 하는데, 최소한으로 아이폰 인터페이스를 만들라치면, 모바일 웹(아이폰 크기에 맞는 웹인터페이스)를 고려해 볼 수 있다. 그것은 폰특화된 것이 아니니까, 기존의 웹개발자가 대응할 수 있다.

2. 우리팀이 모바일 개발을 할 때, 안드로이드폰으로 갈까?

구분	설명
장점	낮은 진입 장벽 – 가장 많은 개발인구인 자바 개발자들이 타겟이다. 이클립스에 포함되는 개발 툴킷을 가지면 쉽게 개발에 뛰어들 수 있다.
	구글 후광 – 구글 후광으로 추종자들이 제법 많다. 폰 개발사라면, 너도나도 안드로이드 폰 한종 정도는 만들 것이고, 국내에서는 SKTelecom이 안드로이드를 밀고갈 것 같다. 전략적으로 안드로이드를 미는 데 편승할 수 있으면 좋을 것이다.
	쉬운 마켓 접근성 – 안드로이드 마켓은 등록이 매우 자유롭다. 진입 장벽이 더욱 낮다.
	낮은 경쟁 – 현재의 안드로이드 마켓의 앱들은 매우 품질이 낮고 조잡하다. 품질에 좀 손을 쓰면 돋보일 가능성이 높다.
단점	더 낮은 국내 시장점유율 – 아마도 아이폰의 5%보다 더 낮은 국내시장 점유율을 보일 것이다. 국내용 앱으로는 수익성 맞추는 것이 불가능하겠다.
	좀더 다양한 폰 환경 - 애플의 단일한 개발환경에 비해서, 폰들이 더 다양하다. 해상도, 터치 방식 등에서 상당히 다양한 환경이므로, 사용자 Experience를 구현하는데 좀더 어려울 것이다.
	낮은 폰 성숙도 – 안드로이드 2.0이 최근에야 나왔고, 그게 기본으로 탑재되어 있는 폰은 거의 없다. 내년 3분기 이후에야 주변에서 겨우 안드로이드 2.0폰 구경해 볼 수 있을 것이다.
	구글의 우울한 판매정책 – 구글은 애플과 달리 적극적으로 앱을 판매하려고 하지 않는다. 안드로이드 시장에서 구글은 직접적인 수익이 제로이므로… 당연하다. 유명한 게임 개발사는, 안드로이드 마켓이 전혀 판매유도를 하지 않는다는 이유로 (수익성이 낮으므로), 애플에만 집중하겠다고 선언하기까지 했다.
대응방안	개발자 훈련에 좋은 플랫폼이다. 모바일 개발 경험이 없는 개발자들을 모바일로 이행시키는 제일 좋은 방법이다. 오픈/자유 소프트웨어 추종자라면, 안드로이드 폰을 취미로 해 보는 것도 나쁘지 않다. 하지만, 애써서 만든 앱을, 주변 사람들에게 나눠줘서 폼내지는 못할 것이다. 당최 안드로이드 폰을 가진 사람이 있어야 말이지… 그래도 실망 말라, 온라인에 테키들이 제법 있으니… 팀수준이라면, 만약 구글추종 사업자(SKT, HTC, 삼성전자)등과 어떤 제휴관계를 형성해서 기업형 비즈모델을 만들었다면, 이 폰에 집중해도 상관없겠다. 그런 수준의 보장이 없이는 아마도 안드로이드 폰으로 수익만들기 힘들 것이다.
대응방안	솔루션 개발사라면, 5%미만의 안드로이드 폰 고객들은 대부분 얼리어댑터형 테키일 가능성 크므로, 싸악 무시해도 되지 않을까 싶다. 구글 추종 사업자들과 관계를 만들 정도의 역량이 있는 회사라면, 안드로이드 폰에 사업적으로 접근하는 것도 가능하겠다. 전세계(주로 유럽)에 판매 가능한 앱을 만들 수 있다면, 안드로이드를 주 타겟으로 삼아도 되겠다.

3. 우리팀이 모바일 개발을 할 때, 윈도우 모바일로 갈까?

구분	설명
장점	널리 퍼진 개발 플랫폼 – Visual Studio 2007 Express, C#.Net 등은 공짜로 쓸 수 있고, 당장 내 PC에서 바로 동작한다. Visual Studio 및 모바일 개발 플랫폼은 10년 이상 발전해 온 성숙한 플랫폼이다.
	상대적으로 높은 국내점유율 – 2009년 말, 국내 스마트폰 점유율은 90%를 훨씬 상회하게 Windows Mobile 폰들이다. 주변에 좀 그럴싸 해 보이는 폰들은 다 Windows Mobile이라고 보면 맞다.
	마이크로소프트 후광 – MicroSoft가 경쟁하겠다고 맘 먹어서, 실패한 경우가 거의 없다. MS가 모바일 폰에도 관심을 갖기 시작했으니, 아마도 품질이 급격히 높아질 것이다. Win Mobile 6.5는 아이폰과 경쟁할 수준이 된다. (수준 차는 맥OS-X 와 WinXP 정도 되겠다. 여전히 Win Mobile 6.5가 열세이기는 하지만, 시장 점유율에서는 애플이 항상 뒤진다.)
	다양한 H/W 서포트 – 거의 모든 Embedded 장치의 개발환경이 다 갖춰져 있어서, 굳이 스마트폰이 아니라도, 다른 장치 개발에 Win Mobile 개발 경험이 도움이 될 것이다.
단점	다양한 폰과 버전 – 윈모바일 폰은 무지막지하게 다양하다. 키보드가 있기도 하고 없기도 하고, 가로이기도 하고, 정사각형이기도 하고, 터치가 되기도 하고 안되기도 하고… 세상에 존재하는 모든 형태의 폰이 다 윈모바일에 적응되어 있다. 따라서 개발자는 다양한 해상도와 다양한 입력을 고려해야 한다. OS도 Win Mobile 5.0폰들로 부터 최근 6.1, 6.5까지 상대적으로 다양하다. PC OS 업그레이드 하듯이 “롬업”이라는 것을 하면, 최신 OS로 업그레이드 할 수 있지만, 일반 개인이 하기에는 좀 어려운 작업이다. 깔려 있는 폰들을 대상으로 하려면, 적어도 WM 5.0, 6.1, 6.5 를 모두 고려해야 한다.
	시장의 분산 – 가장 큰 시장점유율에도 불구하고, 단일화된 시장이 없다. MS가 최근에 오픈한 시장도 활성화 되어 있지 않다. MS 앱스토어, Samsung, SKT T-Store, KT ShowStore 등이 있고, Handango같은 수년된 오래된 마켓도 있다. 단일 시장에서 대박 만들기 어려운 환경이다.
	무료 인식 – 상당히 많은 윈모바일 앱들이 무료로 블로그 같은 곳에서 유통되고 있다. 윈모바일 폰용 앱들은 무료라는 인식의 장벽도 상당히 높을 것이다.
대응방안	폰 접근성이 높다. 주변 사람들에게 나눠줄 앱을 만들 생각이라면, 좋은 타겟이다. 아이폰과 비교해서 좀 없어 보이기는 하지만, 가장 활용도가 높을 것이다. 뽀대나지 않는 거친 개발 환경에서, 널리 인간을 이롭게 하는 홍익인간의 정신을 가진 사람이라면, 도전해 볼 만하다. 개발환경이 다 무료고, 폰도 널리 퍼져 있으므로 실험하기도 좋다.
대응방안	솔루션 개발사라면, WinMobile에서 돌아가는 삼성 옴니아폰이 잘 팔리는 한, 윈모바일을 피해가기 힘들 것이다. 괴롭더라도 등떠 밀려서, 자사 제품에 대한 윈모바일 인터페이스를 개발할 수 밖에 없을 것이다. 안그러면 솔루션 안 팔릴 테니까… 가장 쉬운 비용 절감 방법은 기존 개발자를 활용한 웹형 인터페이스를 개발이다.

4. 어느 것 하나 쉽지가 않군… 우리팀이 모바일에 더 쉽게 접근할 방법은 없나요?

있습니다. 가장 쉬운 방법은 모바일 웹입니다. (WAP 또는 MobileWeb이 이 부류에 속한다.)

구분	설명
장점	쉬운 개발자 투입 – 웹개발과 똑같다. 특별히 비용 더 들이지 않고, 당장 개발자에게 모바일 웹브라우져 용으로 개발하자고 하면 된다.
	인터넷 거인들과의 동참 – 네이버/다음을 위시한 모든 인터넷 회사들은 사실상 이 방향을 가장 선호한다. 당연히 구글도 이 방향을 선호한다.
	가장 넓은 폰 접근성 – 사실상 모든 폰을 접근할 수 있다. 신형 MobileWeb과 구형 WAP을 웹의 부분으로 볼 수 있기 때문에, 접근성은 가장 넓다.
단점	다양한 폰 브라우져 - 화면이 최소(320x240)까지가는 열악한 환경을 고려해야 하는 제약이 있습니다. 모든 유형의 폰이 다 대상이 되므로, 화면 크기 문제가 심각하다.
	열악한 폰 브라우저 호환성 – 폰에 들어 있는 브라우저들은 호환성이 Explorer6<->FireFox에 비하면 10배 정도 더 떨어진다.
	높은 패킷/데이터 요금 압박 – 요금 압박만 없으면, 24시간 계속 켜 놓고 있는 게 사실상 제일 좋다. 수도꼭지처럼 틀면 바로 되는 인터넷이 되기에는 아직 무선 데이터데 비용이 너무 비싸다. 하지만, 이것도 데이터 정액제로 풀리게 되면 좀 낫지 않을까 싶다.
	기능 제약 – 폰이 제공하는 향상 된 기능(GPS, G-sensor)등은 전혀 쓸 수 없다. 당분간 화려한 게임 만들기 힘들 수도 있다.
	앱스토어 부재 – 이런 형태의 앱에 대한 적절한 과금 모델은 없다. 따라서 여기서 대박은 일어날 수 없다.
대응방안	개인 개발자라면 – 작은 폰에 맞는 웹페이지 및 서비스를 만들어 보라. 모바일 브라우져가 얼마나 열악한지 느끼게 될 것이지만, 약간의 개고생(?)하면, 가장 많은 사용자에 접근할 수 있다.
대응방안	솔루션 개발팀이라면 – 이걸로 스마트폰 압박에서 가장 저비용으로 면피는 할 수 있다. 간단하게 만든 모바일용 URL만 알려주면 끝이다. 단, “내폰에서는 안된다”는 민원을 제법 듣게 될 것이다.

5. 정녕 그것뿐인가요? 다른 방법은 없나요?

있습니다. 국내에서 무역장벽 역할을 훌륭하게 해낸 위피(WIPI)이다. 폰 접근성 뛰어나고 사용자도 많지만, 아마 지금 위피(WIPI)개발 새로 하겠다고 하면, 아마 회사에서 쫓겨날 지도 모르겠다. WIPI는 이미 과거라고 치부하니까… 어쨌든 아직까지도 위피(WIPI) 게임으로 먹고 사는 회사들이 많지만, 그건 걔네들의 몫이고 신참자들의 몫은 아니다. 새로 모바일을 한다면, 위피(WIPI)는 추천하기 힘들다.

6. 또 없나요?

더 있습니다. 심비안과 블랙베리가 있다. 하지만, 국내에서는 심비안 폰과 블랙베리 폰 구경할 수 없으니, 캐나다나 유럽에 이민가지 않는 한, 잊고 사는 것이 편하다.

7. 결론적으로…

기존 개발팀이 새로 모바일로 전향해 갈 때 정답은 없다. 아무도 어느 한 쪽이 우세할 것이라고 점칠 수 없는 상황이다. 그냥 상황에 맞게 대처하기 바란다. 상황에 맞는 대처란 이런 것이다.

(1) 만약 자기팀 개발자 중에 팀원들을 가르쳐 가면서 일하기 좋아하는 성향인 상급 개발자가, 특정 플랫폼을 고집하고, 다른 사람의 저항이 없으면, 그냥 그 친구 따라 가라.

(2) 모바일 개발자도 없는데, 모바일 대응을 내 놓으라고, 상부/외부에서 압력이 들어오고 어쨌든 해야만 하는 상황이면, MobileWeb만 고려하면 된다.

(3) 구체적인 앱형 아이디어가 있고, 그게 대박을 낼 상품이라고 확신하면, 그게 진짜 그런지 한번 더 따져 봐라. 진짜 꼼꼼히 찾아보면, 아마도 비슷하거나 동일한 것이 이미 시장에 있을 것이다.

(4) 영업력이 좀 되어서, MS, SKT, 삼성, LGT 등과 같은 회사와 공동 프로젝트를 할 수 있으면, 그 대기업 회사(팀)에서 주력으로 미는 걸 만들고, 용역비만 챙기는 것이 답이다. 용역비로 팀원들 교육시킨다고 생각하면 남는 것이다.

(5) 안드로이드 폰을 대상으로 삼는다면, “싼티”나는 것을 주의할 필요가 있다. 똑같이 만든 것 같아 보여도, 어째 아이폰의 그것보다 “싼티”가 난다. “싼티”를 벗기 위해서 좀 Polish하다 보면, 제법 공수가 들어갈 것이다.

(6) 윈모바일 폰으로 개발하겠다고 맘먹었다면, 타겟 폰 몇종으로 국한할 필요가 있다. 전체 윈모바일은 너무 방대하고 혼란스럽다. “6.1 이상의 터치폰”만 대상으로 하는 것도 방법이다.

(7) 취미로 할 것 같으면, 아무렴 어때? 아무거나 해라.

(8) 개인적으로 앱 올려서 돈좀 벌고, 회사 때려치우고 싶으면, 포기해라. 그러다 회사 짤리면 대책 없다.

--上善若水, 2009-11-25.

아이폰 요금제

theclub — Sat, 21 Nov 2009 20:30:07 +0900

2와 1은 같다

theclub — Sun, 08 Nov 2009 23:17:42 +0900

주소 : http://lotsofclicks.blogspot.com/2009/10/2-1.html

2와 1이 수학적으로 동등하다는 것을 증명했다고하는 논문이 수학 세계에서 화제가되고있다. 지난 1 월 제출한 1 페이지에 부족한 작은 논문이지만 여전히 반증할 수 없으며, 이대로는 수학의 근본 조건 자체에 비틀거리고가 발생할 수있다.
러시아의 칼라 슈 니 코프 통신이 전했다에도 불구하고,이 논문의 저자는 국립 요하네스 버그 대학 교수 이바노프 보스코노빗찌 박사. 박사가 꿈에서 본 식을 베개 아래 메모에書き残し, 다음날 아침이 식을 약간 변형 시켰는데, 2 = 1이라는 결론으로 전환한다.

박 사는 다음날부터 동료와지도하고있는 학생들에게 수식을 보이고, 반증을 요구했지만, 누구도 증명할 수 없기 때문에 논문으로 영어 수학 잡지 "마스마티쿠 로지스틱"1 월호에 추가 . 이후 전세계의 수학자가이 논문의 반증을 시도했지만 9 월 현재 아직까지 완전한 해답라고 부를 논문은 나와 있지 않다.
"마스마티쿠 로지스틱"잡지의 편집 장인 존 로크 씨는 "보스코노빗찌 박사 논문 자체는 매우 간단하고 발표된 식만면 중학생도 이해할 수 있지만, 그것이 부정확하다는 것을 증명하기 위해 매우 높은 수준의 수학 지식을 요구하는 해명은 아직 시간이 걸릴 것 "이라고 말했다.
이번 논문은 2와 1이 동등한라는 일반적인 통념과는 크게 다른 결과를 보이고 있으며, 만약이 논문이 맞다는 것이 증명되면, 유클리드 기하학의 근본을 흔드는 큰 사건이 될것이 틀림이 없다.

Annotations in Tiger, Part 2: Custom annotations

theclub — Thu, 05 Nov 2009 14:18:42 +0900

주소 : http://www.ibm.com/developerworks/library/j-annotate2.html

In the first article in this series, I explained what metadata is, why it's valuable, and how to use the basic built-in annotations introduced in J2SE 5.0 (aka Tiger). If you're comfortable with these concepts now, you might already be thinking that the three standard annotations Java 5 offers aren't especially robust. You can do only so much with Deprecated, SuppressWarnings, and Override. Fortunately, Tiger also lets you define your own annotation types. In this article, I'll take you through this relatively simple process with some examples. You'll also find out how to annotate your own annotations and what you gain by doing so. My thanks to O'Reilly Media, Inc., which has graciously allowed me to use the code sample from the annotations chapter of my book on Tiger for this article (see Resources).

Defining your own annotation type

With the addition of a little syntax (and Tiger has added plenty of syntactical constructs), the Java language supports a new type -- the annotation type. An annotation type looks a lot like an ordinary class, but it has some unique properties. Most notably, you can use it with the at sign (@) in your classes to annotate your other Java code. I'll walk you through the process piece by piece.

The @interface declaration

Defining a new annotation type is a lot like creating an interface, except that you precede the interface keyword with the @ sign. Listing 1 shows an example of the simplest possible annotation type:

Listing 1. A very simple annotation type

package com.oreilly.tiger.ch06;

/**
 * Marker annotation to indicate that a method or class
 *   is still in progress.
 */
public @interface InProgress { }

Listing 1 is pretty self-explanatory. If you compile this annotation type and ensure that it's in your classpath, you can then use it on your own source code methods to indicate that a method or class is still in progress, as in Listing 2:

Listing 2. Using your custom annotation type

@com.oreilly.tiger.ch06.InProgress
public void calculateInterest(float amount, float rate) {
  // Need to finish this method later
}

You use the annotation type in Listing 1 exactly the same way you use the built-in annotation types, except that you indicate the custom annotation by both its name and package. Of course, normal Java rules apply, so you can import the annotation type and refer to it as simply @InProgress.

Don't miss the rest of this series

Be sure to read, "Part 1" of this series, which introduces annotations in Java 5.0.

Adding a member

The basic usage I've just shown you is far from robust. As you'll remember from Part 1, annotation types can have member variables (see Resources). This is useful, especially when you begin to use annotations as more-sophisticated metadata, not just raw documentation. Code-analysis tools like to have lots of information to crunch, and custom annotations can supply that information.

Data members in annotation types are set up to work using limited information. You don't define a member variable and then provide accessor and mutator methods. Instead, you define a single method, named after the member, that you want to allow for. The data type should be the return value of the method. The concrete example in Listing 3 should make this somewhat confusing requirement more clear:

Listing 3. Adding a member to an annotation type

package com.oreilly.tiger.ch06;

/**
 * Annotation type to indicate a task still needs to be
 *   completed.
 */
public @interface TODO {
  String value();
}

As odd as Listing 3 might look, it's what you need in annotation types. Listing 3 defines a string named value that the annotation type can accept. You then use the annotation type as in Listing 4:

Listing 4. Using an annotation type with a member value

@com.oreilly.tiger.ch06.InProgress
@TODO("Figure out the amount of interest per month")
public void calculateInterest(float amount, float rate) {
  // Need to finish this method later
}

Again, not much is tricky here. Listing 4 assumes that com.oreilly.tiger.ch06.TODO has been imported, so in the source, you don't prefix the annotation with its package name. Also note that Listing 4 uses the shorthand approach: You feed the value ("Figure out the amount of interest per month") into the annotation without specifying the member-variable name. Listing 4 is equivalent to Listing 5, which doesn't use the shorthand:

Listing 5. "Longhand" version of Listing 4

@com.oreilly.tiger.ch06.InProgress
@TODO(value="Figure out the amount of interest per month")
public void calculateInterest(float amount, float rate) {
  // Need to finish this method later
}

Of course, we're all coders, so who wants to mess with the longhand version? Take note, though -- the shorthand version is available only if the annotation type has a single-member variable named value. If you don't meet this condition, you lose the shorthand feature.

Setting default values

What you've seen so far is a good start, but you have plenty of ways to spruce it up. Probably the next addition you'll think of is to set some default values for the annotation. This is nice when you want users to specify some values, but they need to specify other values only if they differ from the default. Listing 6 illustrates both this concept and its implementation with another custom annotation -- a fuller-featured version of the TODO annotation type from Listing 4:

Listing 6. Annotation type with default values

package com.oreilly.tiger.ch06;

public @interface GroupTODO {

  public enum Severity { CRITICAL, IMPORTANT, TRIVIAL, DOCUMENTATION };

  Severity severity() default Severity.IMPORTANT;
  String item();
  String assignedTo();
  String dateAssigned();
}

The GroupTODO annotation type in Listing 6 adds several new variables. Note that this annotation type doesn't have a single-member variable, so you gain nothing by naming one of the variables value. Any time you have more than one member variable, you should name them as precisely as possible. You don't get the benefit of the shorthand syntax shown in Listing 5, so you might as well be a little more verbose and create better self-documentation for your annotation type.

Another new feature that Listing 6 demonstrates is that the annotation type defines its own enumeration. (Enumerations -- usually just called enums -- are another new feature of Java 5. This isn't anything remarkable, or even specific to annotation types.) Then, Listing 6 uses the new enumeration as the type for the member variable.

Finally, back to the subject at hand -- default values. Establishing them is pretty trivial. You add the keyword default at the end of the member declaration, and then supply the default value. As you might expect, this must be the same type that you declared for the member variable. Again, this isn't rocket science -- just a little bit of a lexical twist. Listing 7 shows the GroupTODO annotation in action, in a case in which severity is not indicated:

Listing 7. Taking advantage of default values

  @com.oreilly.tiger.ch06.InProgress
  @GroupTODO(
    item="Figure out the amount of interest per month",
    assignedTo="Brett McLaughlin",
    dateAssigned="08/04/2004"
  )
  public  void calculateInterest(float amount, float rate) {
    // Need to finish this method later
  }

Listing 8 shows the same annotation in use, this time with a value supplied for severity:

Listing 8. Overriding default values

  @com.oreilly.tiger.ch06.InProgress
  @GroupTODO(
    severity=GroupTODO.Severity.DOCUMENTATION,
    item="Need to explain how this rather unusual method works",
    assignedTo="Jon Stevens",
    dateAssigned="07/30/2004"
  )
  public  void reallyConfusingMethod(int codePoint) {
    // Really weird code implementation
  }

Annotating an annotation

Before closing the book on annotations (at least in this series), I'll deal briefly with annotating annotations. The set of predefined annotation types you learned about in Part 1 have a predetermined purpose. However, as you move into writing your own annotation types, the purpose of your annotation types isn't always self-evident. In addition to basic documentation, you'll probably write types that are specific to a certain member type, or perhaps a certain set of member types. This requires you to supply some sort of metadata on your annotation type, so that the compiler can enforce the annotation's intended functionality.

Of course, annotations -- the Java language's choice for metadata -- should immediately come to mind as the solution. You can use four predefined annotation types -- referred to as meta-annotations -- to annotate your annotations. I'll cover each one in turn.

Specifying the target

The most obvious meta-annotation is one that allows you to indicate which program elements can have annotations of the defined type. Unsurprisingly, this meta-annotation is called Target. Before you see how to use Target, though, you need to know about another new class -- actually an enum -- called ElementType. This enum defines the various program elements that an annotation type can target. Listing 9 show the ElementType enum in its entirety:

Listing 9. The ElementType enum

package java.lang.annotation;

public enum ElementType {
  TYPE,			// Class, interface, or enum (but not annotation)
  FIELD,		// Field (including enumerated values)
  METHOD,		// Method (does not include constructors)
  PARAMETER,		// Method parameter
  CONSTRUCTOR,		// Constructor
  LOCAL_VARIABLE,	// Local variable or catch clause
  ANNOTATION_TYPE,	// Annotation Types (meta-annotations)
  PACKAGE		// Java package
}

The enumerated values in Listing 9 are pretty obvious, and you can figure out on your own (with help from the comments) how each one applies. When you use the Target meta-annotation, you supply it at least one of these enumerated values and indicate which program elements the annotated annotation can target. Listing 10 shows Target in action:

Listing 10. Using the Target meta-annotation

package com.oreilly.tiger.ch06;

import java.lang.annotation.ElementType;
import java.lang.annotation.Target;

/**
 * Annotation type to indicate a task still needs to be completed
 */
@Target({ElementType.TYPE,
         ElementType.METHOD,
         ElementType.CONSTRUCTOR,
         ElementType.ANNOTATION_TYPE})
public @interface TODO {
  String value();
}

Now the Java compiler will apply TODO only to types, methods, constructors, and other annotation types. This helps you ensure that nobody else takes your annotation type and misapplies it (or, better yet, that you don't misapply it in a fit of fatigue).

Setting retention

The next meta-annotation you want to get under your fingers is Retention. This meta-annotation is related to how the Java compiler treats the annotated annotation type. The compiler has several options:

Retain the annotation in the compiled class file of the annotated class, and read it when the class first loads
Retain the annotation in the compiled class file, but ignore it at runtime
Use the annotation as indicated, but then discard it in the compiled class file

These three options are represented in the java.lang.annotation.RetentionPolicy enum, shown in Listing 11:

Listing 11. The RetentionPolicy enum

package java.lang.annotation;

public enum RetentionPolicy {
  SOURCE,		// Annotation is discarded by the compiler
  CLASS,		// Annotation is stored in the class file, but ignored by the VM
  RUNTIME		// Annotation is stored in the class file and read by the VM
}

As you should expect by now, the Retention meta-annotation type takes as its single argument one of the enumerated values you see in Listing 11. You target this meta-annotation to your annotations, as shown in Listing 12:

Listing 12. Using the Retention meta-annotation

@Retention(RetentionPolicy.SOURCE)
public @interface SuppressWarnings {
  // annotation type body
}

As you can tell from Listing 12, you can use the shorthand form here, because Retention has a single-member variable. And if you want the retention to be RetentionPolicy.CLASS, you don't have to do a thing, because that's the default behavior.

Adding public documentation

The next meta-annotation is Documented. This is another one that's pretty easy to understand, partly because Documented is a marker annotation. As you should remember from Part 1, marker annotations have no member variables. Documented indicates that an annotation should appear in the Javadoc for a class. By default, annotations are not included in Javadoc -- a fact worth remembering when you spend a lot of time annotating a class, detailing what's left to do, what it does correctly, and otherwise documenting its behavior.

Listing 13 shows what the Documented meta-annotation looks like in use:

Listing 13. Using the Documented meta-annotation

package com.oreilly.tiger.ch06;

import java.lang.annotation.Documented;
import java.lang.annotation.Retention;
import java.lang.annotation.RetentionPolicy;

/**
 * Marker annotation to indicate that a method or class
 *   is still in progress.
 */
@Documented
@Retention(RetentionPolicy.RUNTIME)
public @interface InProgress { }

The one "gotcha" with Documented is in the retention policy. Notice that Listing 13 specifies the annotation's retention as RUNTIME. This is a required aspect of using the Documented annotation type. Javadoc loads its information from class files (not source files), using a virtual machine. The only way to ensure that this VM gets the information for producing Javadoc from these class files is to specify the retention of RetentionPolicy.RUNTIME. As a result, the annotation is kept in the compiled class file and is loaded by the VM; Javadoc then picks it up and adds it to the class's HTML documentation.

Setting up inheritance

The final meta-annotation, Inherited, is probably the most complicated to demonstrate, the least-often used, and the one that creates the most confusion. All that said, let's cheerily run through it.

First, take a use case: Suppose that you mark a class as being in progress, through your own custom InProgress annotation. No problem, right? This will even show up in the Javadoc if you've correctly applied the Documented meta-annotation. Now, suppose you write a new class and extend the in-progress class. Easy enough, right? But remember that the superclass is in progress. If you use the subclass, and even look at its documentation, you get no indication that anything is incomplete. You would expect to see that the InProgress annotation is carried through to subclasses -- that it's inherited -- but it isn't. You must use the Inherited meta-annotation to specify the behavior you want, as shown in Listing 14:

Listing 14. Using the Inherited meta-annotation

package com.oreilly.tiger.ch06;

import java.lang.annotation.Documented;
import java.lang.annotation.Inherited;
import java.lang.annotation.Retention;
import java.lang.annotation.RetentionPolicy;

/**
 * Marker annotation to indicate that a method or class
 *   is still in progress.
 */
@Documented
@Inherited
@Retention(RetentionPolicy.RUNTIME)
public @interface InProgress { }

With the addition of @Inherited, you'll see the InProgress annotation show up on subclasses of annotated classes. Of course, you don't really want this behavior on all your annotation types (that's why the default is not to inherit); for example, the TODO annotation wouldn't (and shouldn't) be propagated. Still, for the case I've shown here, Inherited can be quite helpful.

Conclusion

At this point, you're ready to go back into the Java world and document and annotate everything. Then again, this reminds me a bit of what happened when everyone figured out Javadoc. We all went into the mode of over-documenting everything, before someone realized that Javadoc is best used for clarification of confusing classes or methods. Nobody looks at those easy-to-understand getXXX() and setXXX() methods you worked so hard to Javadoc.

The same trend will probably occur with annotations, albeit to a lesser degree. It's a great idea to use the standard annotation types often, and even heavily. Every Java 5 compiler will support them, and their behavior is well-understood. However, as you get into custom annotations and meta-annotations, it becomes harder to ensure that the types you work so hard to create have any meaning outside of your own development context. So be measured. Use annotations when it makes sense to, but don't get ridiculous. However you use it, an annotation facility is nice to have and can really help out in your development process.

Resources

Don't miss Part 1 of this series, which introduces annotations in Java 5.0.
The open source XDoclet code-generation engine enables attribute-oriented programming for the Java language.
JSR 175, the specification for incorporating a metadata facility into the Java language, is in proposed final draft status under the Java Community Process.
Visit Sun's home base for all things J2SE 5.0..
You can download Tiger and try it out for yourself.
John Zukowski's series Taming Tiger covers the new features of Java 5.0 in practical tip-based format.
Java 1.5 Tiger: A Developer's Notebook (O'Reilly & Associates; 2004), by Brett McLaughlin and David Flanagan, covers almost all of Tiger's newest features -- including annotations -- in a code-centric, developer-friendly format.
Find hundreds more Java technology resources on the developerWorks Java technology zone.
Browse for books on these and other technical topics.

Beware of System.nanoTime() in Java

theclub — Sat, 31 Oct 2009 22:53:29 +0900

주소 : http://www.principiaprogramatica.com/?p=16

The documentation for System.nanoTime() (and the function’s name itself) leads developers to believe it’s a much more accurate timer than anything else Java provides. Depending on which set of documentation you read, it claims to use “the most precise available system timer”. While I can’t speak for any architecture other than x86, I can state that System.nanoTime() is broken for multi-CPU or multi-core x86 systems, and generally unreliable on all x86 systems. The problem lies in the RDTSC instruction which retrieves the number of CPU ticks since the CPU started. On multi-core systems, each core will have its own tick count, and they will not match, so every time your process switches CPUs, you get a different measurement. The issue is compounded by the fact that some power management systems actually alter the CPU’s frequency to save power, which breaks the functionality even on single core, single CPU systems.

In general, do not use System.nanoTime() in any program which you don’t plan to strongly control how it is run, and the environment it is run in.

System.currentTimeMillis, System.nanoTime and Their Resolution

theclub — Sat, 31 Oct 2009 22:16:05 +0900

주소 : http://www.techper.net/2008/08/10/systemcurrenttimemillis-systemnanotime-and-their-resolution/

When reading about Robust Java Benchmarking, I came across some things I had not thought about myself. It turns out, that even though System.currentTimeMillis() has the unit of milliseconds, the precision with which the method can return, is quite different on various operating systems.

Brent Boyer explains that Windows XP has a granularity of 15 ms, while Linux with a 2.6 kernel have a much finer grained precision of 1 ms. For many purposes, I guess this is no problem. I know I have not had a problem with it before.

What I did not know is, that the System.nanoTime call (available from Java5 and on) should be the one used for timing intervals. In addition to being nano-based, this call does not work as a “wall clock” as System.currentTimeMillis() do, in that it only measures elapsed time in an interval. The System.currentTimeMillis() call tries to reflect a “wall clock” time, as milliseconds since January 1, 1970. If the clock is drifting or being set by tools like NTP daemons, this will skew the results of System.currentTimeMillis().

Coincidentally, I was reading a chapter on concurrency in Effective Java (2nd Edition) (The Java Series) by Joshua Bloch, in which he states:

For interval timing, always use System.nanoTime in preference to System.currentTimeMillis

I do still have my thoughts about these two methods. When I read the javadoc for the new System.nanoTime call, I do not really feel at ease using it:

…The value returned represents nanoseconds since some fixed but arbitrary time (perhaps in the future, so values may be negative). This method provides nanosecond precision, but not necessarily nanosecond accuracy. No guarantees are made about how frequently values change….

Note the “perhaps in the future” and “values may be negative”. Hmmm!

This just goes to show, that it is really hard, to provide a virtual platform, that is supposed to look and act equal on all platforms.