반응형

Important Considerations When Building Single Page Web Apps

웹앱 제작시 중요고려사항

 

http://net.tutsplus.com/tutorials/javascript-ajax/important-considerations-when-building-single-page-web-apps/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A%20nettuts%20%28Nettuts%2B%29

 

 

Single page web applications – or SPAs, as they are commonly referred to – are quickly becoming the de facto standard for web app development. The fact that a major part of the app runs inside a single web page makes it very interesting and appealing, and the accelerated growth of browser capabilities pushes us closer to the day, when all apps run entirely in the browser.

Technically, most web pages already are SPAs; it’s the complexity of a page that differentiates a web page from a web app. In my opinion, a page becomes an app when you incorporate workflows, CRUD operations, and state management around certain tasks. You’re working with a SPA when each of these tasks take place on the same page (using AJAX for client/server communication, of course).

Let’s start with this common understanding, and dive into some of the more important things that should be considered when building SPAs.


There are numerous points to consider before building a new app; to make matters worse, the expansive web development landscape can be intimidating at the outset. I have been in those unsettling shoes, but fortunately, the past few years have brought consensus on the tools and techniques that make the application development experience as enjoyable and productive as possible.

Most apps consist of both client and server-side pieces; although this article focuses mostly on the client-side portion of an app, I’ll provide a few server-side pointers toward the end of this article.

There is a colorful mix of technologies on the client-side, as well as several libraries and practices that enable a productive app development experience. This can be summarized, using the following word cloud.

Important Considerations - checklist

I will expand on each of the points above in the following sections.


Picking an Application Framework

There are an abundance of frameworks to choose from. Here’s but a handful of the most popular:

Choosing a framework is easily one of the most important choices you will make for your app. Certainly, you’ll want to choose the best framework for your team and app. Each of the above frameworks incorporate the MVC design pattern (in some form or another). As such, it’s quite common to refer to them as MVC frameworks. If we had to order these frameworks on a scale of complexity, learning curve and feature set, from left to right, it might look like:

App Frameworks

Although dissimilar in their implementation and level of sophistication, all the aforementioned frameworks provide some common abstractions, such as:

Just looking at the past five years, there has been an explosive growth in libraries, tools and practices.

  • Model: a wrapper around a JSON data structure with support for property getters/setters and property change notification.
  • Collection: a collection of models. Provides notifcations when a model is added, removed, or changed in the collection.
  • Events: a standard pattern to subscribe to and publish notifications.
  • View: A backing object for a DOM fragment with support for listening to DOM events relative to the DOM fragment. The View has access to the corresponding Model instance. In some frameworks, there is also a Controller that orchestrates changes between the View and Model.
  • Routing: Navigation within an app via URLs. Relies on the browser history API.
  • Syncing: Persisting model changes via Ajax calls.

More advanced frameworks, like CanJS, BatmanJS, EmberJS and AngularJS, expand on these basic features by providing support for automatic data-binding and client-side templates. The templates are data-bound and keep the view in sync with any changes to the model. If you decide to pick an advanced framework, you will certainly get a lot of out-of-the-box features, but it also expects you to build your app in a certain way.

Of all the previously listed frameworks, Meteor is the only full-stack framework. It provides tools not only for client-side development, but it also provides you with a server-side piece, via NodeJS, and end-to-end model synchronization, via MongoDB. This means that, when you save a model on the client, it automatically persists in MongoDB. This is a fantastic option, if you run a Node backend and use MongoDB for persistence.

Based on the complexity of your app, you should pick the framework that makes you the most productive. There certainly will be a learning curve, but that’s a one-time toll you pay for express-lane development. Be sure to carve out some time to evaluate these frameworks, based on a representative use-case.

Note: If you want to learn more about these frameworks from their creators, listen to these videos from ThroneJS.


Client-Side Templates

The most popular JavaScript-based templating systems are Underscore templates and Handlebars.

Some of the advanced frameworks from the previous section offer built-in templating systems.

For example, EmberJS has built-in support for Handlebars. However, you do have to consider a templating engine if you decide to use a lean framework, such as Backbone. Underscore is an excellent starting point, if you have limited templating requirements. Otherwise, Handlebars works great for more advanced projects. It also offers many built-in features for more expressive templates.

If you find that you require a large number of client-side templates, you can save some computation time by pre-compiling the templates on the server. Pre-compilation gives you plain JavaScript functions that you invoke to improve the load time of the page. Handlebars supports pre-compilation, making it worth the time and effort to fully explore.

ExpressJS users can even use the same templating engine on the client as on the server, giving you the benefit of sharing your templates between both the client and server.


Modular Development

Using a preprocessor requires an extra step in your build process.

JavaScript code is traditionally added to the page, via the <script /> element. You typically list libraries and other dependencies first, and then list the code that references those dependencies. This style works well, when you only need to include a few files; however, it will quickly become a nightmare to maintain, as you include additional scripts.

One solution to this problem is to treat each script file as a Module, and identify it by a name or relative file path. Using these semantics, and with the support of libraries, like RequireJS and Browserify, you can build your app using a module-based system.

The module thus becomes a way to identify the functionality within the app. You can organize these modules, using a certain folder structure that groups them based on a particular feature or functionality. Modules help in managing your application’s scripts, and it also eliminates global dependencies that must be included with <script /> elements before the application scripts. For libraries that are not AMD compatible, RequireJS offers a shim feature that exposes non-AMD scripts as modules.

There are currently two types of module-based systems: AMD (Asynchronous Module Definition) and CommonJS.

In AMD, each module contains a single top-level define() statement that lists all required dependencies, and an export function that exposes the module’s functionality. Here’s an example:

1
2
3
4
5
6
7
8
9
10
11
define([
// listing out the dependencies (relative paths)
'features/module/BaseView',
'utils/formatters'
], function(BaseView, formatters) { // Export function that takes in the dependencies and returns some object
// do something here
// An explicit require
var myModule = require('common/myModule');
// Object exposing some functionality
return { ... };
});

CommonJS module names are based on either a relative file path or a built-in module lookup process. There is no define() function in any module, and dependencies are explicitly stated by calls to require(). A module exposes its functionality, via the module.exports object, which each module automatically creates. Here’s a CommonJS example:

1
2
3
4
5
var fs = require('fs'), // standard or built-in modules
path = require('path'),
formatters = require('./utils/formatters'); // relative file path as module name
// Export my code
module.exports = { ... };

The CommonJS module style is more prevalent in NodeJS applications, where it makes sense to skip the call to define() call – you are working with a file-system based module lookup. Interestingly, you can do the same in a browser, using Browserify.


Package Management

Performance should be on your mind as you build and add features to your app.

Most apps have at least one dependency, be it a library or some other third party piece of code. You’ll find that you need some way to manage those dependencies as their number increases, and you need to insulate yourself from any breaking changes that newer versions of those dependencies may introduce.

Package management identifies all the dependencies in your app with specific names and versions. It gives you greater control over your dependencies, and ensures that everyone on your team is using an identical version of the library. The packages that your app needs are usually listed in a single file that contains a library’s version and name. Some of the common package managers for different tech stacks are:

  • Linux: Aptitude
  • .NET: Nuget
  • PERL: CPAN
  • Ruby: Gems
  • PHP: Composer
  • Node: NPM
  • Java: Maven and Gradle

Although package management is more of a server-side ability, it’s gaining popularity in client-side development circles. Twitter introduced Bower, a browser package manager similar to NPM for Node. Bower lists the client-side dependencies in component.json, and they are downloaded by running the bower CLI tool. For example, to install jQuery, from the Terminal, you would run:

1
bower install jquery

The ability to control a project’s dependencies makes development more predictable, and provides a clear list of the libraries that an app requires. If you consider consolidating your libraries in the future, doing so will be easier with your package listing file.


Unit and Integration Testing

It goes without saying that unit testing is a critical part of app development. It ensures that features continue to work as you refactor code, introduce libraries, and make sweeping changes to your app. Without unit tests, it will prove difficult to know when something fails, due to a minor code change. Coupled with end-to-end integration testing, it can be a powerful tool, when making architectural changes.

On the client-side, Jasmine, Mocha and Qunit are the most popular testing frameworks. Jasmine and Mocha support a more Behavior-Driven Development (BDD) style, where the tests read like English statements. QUnit, on the other hand, is a more traditional unit testing framework, offering an assertion-style API.

Jasmine, Mocha or Qunit run tests on a single browser.

If you want to gather test results from multiple browsers, you can try a tool like Testacular that runs your tests in multiple browsers.

To take testing the whole nine yards, you’ll likely want to have integration tests in your app, using Selenium and Cucumber/Capybara. Cucumber allows you to write tests (aka features) in an English-like syntax, called Gherkin, which can even be shared with the business folks. Each test statement in your Cucumber file is backed by executable code that you can write in Ruby, JavaScript or any of the other supported languages.

Executing a Cucumber feature file runs your executable code, which in turn tests the app and ensures that all business functionality has been properly implemented. Having an executable feature file is invaluable for a large project, but it might be overkill for smaller projects. It definitely requires a bit of effort to write and maintian these Cucumber scripts, so it really boils down to a team’s decision.


UI Considerations

Having a good working knowledge of CSS will help you achieve innovative designs in HTML.

The UI is my favorite portion of an app; it’s one of the things that immediately differentiates your product from the competition. Although apps differ in their purpose and look and feel, there are a few common responsibilities that most apps have. UI design and architecture is a fairly intensive topic, but it’s worth mentioning a few design points:

  • Form Handling: use different input controls (numeric inputs, email, date picker, color picker, autocomplete), validations on form submit, highlight errors in form inputs, and propagating server-side errors on the client.
  • Formatting: apply custom formats to numbers and other values.
  • Error Handling: propagate different kinds of client and server errors. Craft the text for different nuances in errors, maintain an error dictionary and fill placeholders with runtime values.
  • Alerts and Notifications: tell the user about important events and activities, and show system messages coming from the server.
  • Custom Controls: capture unique interaction patterns in the app as controls that can be reused. Identify the inputs and outputs from the control without coupling with a specific part of the app.
  • Grid System: build layouts using a grid system, like Compass Susy, 960gs, CSS Grid. The grid system will also help in creating responsive layout for different form factors.
  • UI Pattern Library: get comfortable with common UI patterns. Use Quince for reference.
  • Layered Graphics: understand the intricacies of CSS, the box models, floats, positioning, etc. Having a good working knowledge of CSS will help you achieve innovative designs in HTML.
  • Internationalization: adapt a site to different locales. Detect the locale using the Accept-Language HTTP header or through a round-trip to gather more info from the client.

CSS Preprocessors

CSS is a deceptively simple language that has simple constructs. Interestingly, it can also be very unwieldy to manage, especially if there are many of the same values used among the various selectors and properties. It’s not uncommon to reuse a set of colors throughout a CSS file, but doing so introduces repetition, and changing those repeated values increases the potential for human error.

CSS preprocessors solve this problem and help to organize, refactor and share common code. Features, such as variables, functions, mixins and partials, make it easy to maintain CSS. For example, you could store the value of a common color within a variable, and then use that variable wherever you want to use its value.

Using a preprocessor requires an extra step in your build process: you have to generate the final CSS.

There are, however, tools which auto-compile your files, and you can also find libraries that simplify stylesheet development. SASS and Stylus are two popular preprocessors that offer corresponding helper libraries. These libraries also make it easy to build grid-based systems and create a responsive page layout that adapts to different form factors (tablets and phones).

Although CSS preprocessors make it easy to build CSS with shared rules, you still have the responsibility of structuring it well, and isolating related rules into their own files. Some principles from SMACSS and OOCSS can serve as a great guide during this process.

Scalable and Modular Architecture for CSS is included, as part of a Tuts+ Premium membership.


Version Control

If you know a hip developer, then you’re probably aware that Git is the reigning champion of all version control systems (VCS). I won’t go into all the details of why Git is superior, but suffice it to say that branching and merging (two very common activities during development) are mostly hassle free.

A close parallel to Git, in terms of philosophy, is Mercurial (hg)–although it is not as popular as Git. The next best alternative is the long-standing Subversion. The choice of VCS is greatly dependent on your company standards, and, to some extent, your team. However, if you are part of a small task force, Git is easily the preferred option.


Browser Considerations

It goes without saying that unit testing is a critical part of app development.

There are a variety of browsers that we must support. Libraries, like jQuery and Zepto, already abstract the DOM manipulation API, but there are other differences in JavaScript and CSS, which require extra effort on our parts. The following guidelines can help you manage these differences:

  • Use a tool, like Sauce Labs or BrowserStack to test the website on multiple browsers and operating systems.
  • Use polyfills and shims, such as es5shim and Modernizr to detect if the browser supports a given feature before calling the API.
  • Use CSS resets, such as Normalize, Blueprint, and Eric Myer’s Reset to start with a clean slate look on all browsers.
  • Use vendor prefixes (-webkit-, -moz-, -ms-) on CSS properties to support different rendering engines.
  • Use browser compatibility charts, such as findmebyIP and canIuse.

Managing browser differences may involve a bit of trial and error; Google and StackOverflow can be your two best friends, when you find yourself in a browser-induced jam.


Libraries

There are a few libraries that you might want to consider:


Minification

Before deploying your application, it’s a good idea to combine all of your scripts into a single file; the same can be said for your CSS. This step is generally referred to as minification, and it aims to reduce the number of HTTP requests and the size of your scripts.

You can minify JavaScript and CSS with: RequireJS optimizer, UglifyJS, and Jammit. They also combine your images and icons into a single sprite sheet for even more optimization.

Editor’s Note: I recommend that you use Grunt or Yeoman (which uses Grunt) to easily build and deploy your applications.

Tools of the Trade

Twitter introduced Bower, a browser package manager similar to NPM for Node.

I would be remiss if I did not mention the tools for building SPAs. The following lists a few:

  • JsHint to catch lint issues in your JavaScript files. This tool can catch syntactic issues, such as missing semicolons and enforcing a certain code style on the project.
  • Instead of starting a project from scratch, consider a tool, such as Yeoman to quickly build the initial scaffolding for the project. It provides built-in support for CSS preprocessors (like SASS, Less and Stylus), compiling CoffeeScript files to JavaScript and watching for file changes. It also prepares your app for deployment by minifying and optimizing your assets. Like Yeoman, there are other tools to consider, such as MimosaJS and Middleman.
  • If you’re looking for a make-like tool for JavaScript, look no further than Grunt. It is an extensible build tool that can handle a variety of tasks. Yeoman uses Grunt to handle all of its tasks.
  • Nodemon for auto-starting a Node program each time a file changes. A simliar tool is forever.
  • Code editors, such as Sublime Text, Vim, and JetBrains WebStorm.
  • Command line tools ZSH or BASH. Master the shell because it can be very, effective especially when working with tools like Yeoman, Grunt, Bower and NPM.
  • Homebrew is a simple package manager for installing utilities.

Performance Considerations

CSS preprocessors make it easy to build CSS with shared rules.

Rather than treating this as an after-thought, performance should be on your mind as you build and add features to your app. If you encounter a performance issue, you should first profile the app. The Webkit inspector offers a built-in profiler that can provide a comprehensive report for CPU, memory and rendering bottlenecks. The profiler helps you isolate the issue, which you can then fix and optimize. Refer to the Chrome Developer Tools for in-depth coverage of the Chrome web inspector.

Some common performance improvements include:

  • Simplify CSS selectors to minimize recalculation and layout costs.
  • Minimize DOM manipulations and remove unnecessary elements.
  • Avoid data bindings when the number of DOM elements run into hundreds.
  • Clean up event handlers in view instances that are no longer needed.
  • Try to generate most of the HTML on the server-side. Once on the client, create the backing view with the existing DOM element.
  • Have region-specific servers for faster turn around.
  • Use CDNs for serving libraries and static assets.
  • Analyze your web page with tools like YSlow and take actions outlined in the report.

The above is only a cursory list. Visit Html5Rocks for more comprehensive performance coverage.


Auditing and Google Analytics

If you plan on tracking your app’s usage or gathering audit trails around certain workflows, Google Analytics (GA) is probably your best solution. By including a simple GA script on each page with your tracking code, you can gather a variety of your app’s metrics. You can also set up goals at the Google Analytics website. This fairly extensive topic is worth investigating, if tracking and auditing is an important concern.


Keeping up With the Jones

The world of web development changes quickly. Just looking at the past five years, there has been an explosive growth in libraries, tools and practices. The best way to keep tabs on the web’s evolution is to subscribe to blogs (like this one), newsletters and just being curious:


Operations Management

The client-side, although looking like a large piece of the stack, is actually only half of the equation. The other half is the server, which may also be referred to as operations management. Although beyond the scope of this article, these operations can include:

  • continuous integration, using build servers such as TeamCity, Jenkins, and Hudson.
  • persistence, data redundancy, failover and disaster recovery.
  • caching data in-memory and invalidating the cache at regular intervals.
  • handling roles and permissions and validating user requests.
  • scaling under heavy load.
  • security, SSL certificates, and exploit-testing.
  • password management.
  • support, monitoring and reporting tools.
  • deployment and staging.

Summary

As you can see, developing an app and bringing it to production involves a variety of modern technologies. We focused primarily on client-side development, but don’t forget the server-side portion of the app. Separately, they’re useless, but together, you have the necessary layers for a working application.

With so much to learn, you wouldn’t be alone if you feel overwhelmed. Just stick with it, and don’t stop! You’ll get there soon enough.

반응형
반응형

 최후까지 살아남는 사람들은 가장 힘이 센 사람이나 영리한 사람들이 아니라, 변화에 가장 민감한 사람들이다. - 찰스 다윈 -

It is not the strongest of the species that survive, nor the most intelligent, but the one most responsive to change.
- Charles Darwin -

반응형
반응형

듣고 또 듣고,
부르고 또 부른다.
음악은 그저 내 삶이고 생활이다.
음악이 없었으면 나도 존재하지 못했다.
어린 시절 부모님 덕분에 음악을 많이 듣고
자랐다. 오래된 팝송도 자주 들었다. 조금 큰
뒤에는 레코드판을 사모으는 것이 일이 되었다.
수백장의 앨범이 내 방 한구석을 차지했다.
그 앨범들을 들으면서 꿈을 키웠고
결국 꿈을 이루었다.


- 임윤택의《안 된다고 하지 말고 아니라고 하지 말고》중에서 -


* '울랄라세션'의 리더.
그가 책을 내고, '반복의 힘'을 설파하고 있습니다.
단순히 기계적인 반복이 아니라 어제보다 더 좋아지도록
노력하는 반복입니다. 여기서 진정한 예술가가 탄생되고
챔피언이 나옵니다. 그 어렵다는 게티즈버그 연설도
백 번, 천 번만 혼을 담아 듣고 또 듣고, 외우고
또 외우면 어느 순간 '무의식의 무기'가 되어
꿈을 키우고 꿈을 이룰 수 있습니다.

반응형

'생활의 발견 > 아침편지' 카테고리의 다른 글

찾습니다  (0) 2013.01.26
창밖의 눈  (0) 2013.01.25
한 시간 명상이 10 시간의 잠과 같다  (0) 2013.01.23
정신적 우아함  (0) 2013.01.22
차가워진 당신의 체온  (0) 2013.01.21
반응형

유태(인)식 세미나에서는 이렇게 가르친다.
‘자기 현실에 비추어 볼 때 말도 안 된다 싶은 것을 상상하라고’.
자기에겐 조금 벅찰 수도 있는 비현실적인 목표를 세워서
그것을 어떻게 이룰 수 있는지 그 실제적인 방법에 대해
생각하라는 것이다.
그렇게 하면 모든 게 가능해진다.
-‘천재가 된 제롬’에서

 

 

가야금 명인 황병기 선생님도 ‘불가능성의 매력’을 중요시합니다.
가능한 것을 가능케 하는 것은 아무것도 아니고,
불가능한 것을 가능하게 만들어야 비로소
감동적인 것이 나올 수 있다는 주장입니다.
물방울로 바위에 구멍을 내는 정도의 불가능해 보이는 일에
도전하는 사람들이 많아지길 기대해봅니다.

반응형
반응형

예제 중심의 Python 파이썬: 쉽고 재미있는 프로그래밍 언어
 - 인피니티북스/최용 저

 

예제 중심의 Python 파이썬
국내도서>컴퓨터/인터넷
저자 : 최용
출판 : 인피니티북스 2011.11.21
상세보기

 

Yes24 : http://www.yes24.com/24/goods/5983602?scode=032&OzSrank=7

 

시쿨리
 - 윈도우/맥/리눅스 JRE 1.6 이상
 - Sikuli X


안드로이드 스크립팅
 - 안드로이드폰
 - Python 2.6.2

자이썬
 - Jython 2.5

[목      차]

Chapter 1 파이썬 맛보기
Section 01 파이썬 소개
Section 02 파이썬 다운로드와 설치
Section 03 여러 가지 파이썬 쉘
Section 04 파이썬 기초

Chapter 2 시쿨리
Section 01 시쿨리 다운로드와 설치
Section 02 지뢰 찾기
Section 03 아이튠즈
Section 04 시티빌

Chapter 3 안드로이드 스크립팅
Section 01 안드로이드폰에 파이썬 설치하기
Section 02 안드로이드폰에서 코딩하기
Section 03 파일과 폴더 관리
Section 04 사진 찍어 트윗하기
Section 05 비밀번호 생성기 Oplop
Section 06 단어장
Section 07 휴대용 웹 서버

Chapter 4 파이썬
Section 01 파이썬 2와 파이썬 3
Section 02 영화 출연진 집합
Section 03 스페인어로 숫자 읽기
Section 04 모듈(Module)
Section 05 텍스트 파일 편집
Section 06 건축무한육면각체의 비법

Chapter 5 파이썬 꾸러미 활용
Section 01 파이썬 꾸러미 색인
Section 02 외래어 한글 표기 - 한글라이즈
Section 03 파이썬 이미지 라이브러리
Section 04 순서도(Sequence Diagram)
Section 05 Pexpect로 시스템 관리
Section 06 파이썬 구글 차트

Chapter 6 자이썬
Section 01 자이썬 설치
Section 02 안녕, 자이썬

Chapter 7 파이썬, 그냥 재미로
Section 01 지금 바로 시작하기
Section 02 컴퓨터 이해하기
Section 03 응용 분야 탐구
Section 04 파이썬을 더 깊이 공부하기
Section 05 다른 언어 들여다보기
Section 06 소프트웨어 개발 과정 이해하기
Section 07 외국어 공부  

반응형
반응형
Can Python be embedded in HTML like PHP and JSP?

파이썬은 PHP JSP처럼 HTML에 포함 할 수 있습니까?

 

 

Use a template engine, such as:

The python wiki also has an article on this topic, with many more suggestions.

 

Yes, I recall there was a python ASP plugin from activestate that works this way.

 

 

 Template

 django  https://docs.djangoproject.com/en/dev/topics/templates/
 jinja2  http://jinja.pocoo.org/docs/
 mako  http://www.makotemplates.org/
 cheetah  http://www.cheetahtemplate.org/
 Cog  http://nedbatchelder.com/code/cog/

 

 

반응형
반응형

자바스크립트 소수점 보여주기

 

var tempAvg = 4.436;

 

Math.ceil(tempAvg) : 올림

 

Math.round(tempAvg) : 반올림

 

Math.floor(tempAvg) : 내림

 

parseInt(tempAvg) : 내림(정수)

 

parseFloat("123.4567") : 소수점있는 문자열을 숫자(float)로 변환

 

parseInt("13456") : 문자를 숫자(int)로 변환

 

parseFloat("13456") : 문자를 숫자(float)로 변환

 

var tempAvg = 5.0;

 

소수점 1자리 보여주시 : tempAvg.toFixed(1); -> 5.0

 

소수점 2자리 보여주시 : tempAvg.toFixed(2); -> 5.00

반응형
반응형

표준프레임워크 - http://www.egovframe.go.kr/

 

표준프레임워크 소개

등장배경 및 목적
개발프레임워크는 정보시스템 개발을 위해 필요한 기능 및 아키텍처를 미리 만들어 제공함으로써 효율적인 어플리케이션 구축을 지원합니다.“전자정부 표준프레임워크”는 공공사업에 적용되는 개발프레임워크의 표준정립으로 응용 SW 표준화, 품질 및 재사용성 향상을 목표로 합니다.이를 통해“전자정부 서비스의 품질향상”및“정보화 투자 효율성 향상”을 달성하고 대중소기업이 동일한 개발기반 위에서 공정경쟁이 가능하게 됩니다.

표준프레임워크는 기존 다양한 플랫폼(.NET, php 등) 환경을 대체하기 위한 표준은 아니며,java 기반의 정보시스템 구축에 활용하실 수 있는 개발·운영 표준환경을 제공하기 위한 것입니다.


 

특징
  • 개방형 표준 준수
    오픈소스 기반의 범용화되고 공개된 기술의 활용으로 특정 사업자에 대한 종속성 배제
  • 상용 솔루션 연계
    상용 솔루션과 연계가 가능한 표준을 제시하여 상호운용성 보장
  • 국가적 표준화 지향
    민.관.학계로 구성된 자문협의회를 통해 국가적 차원의 표준화 수행
  • 변화 유연성
    각 서비스의 모듈화로 교체가 용이하며 인터페이스 기반 연동으로 모듈간 변경영향 최소화
  • 편리하고 다양한 환경제공
    Eclipse 기반의 모델링(UML,ERD), 에디팅, 컴파일링, 디버깅 환경 제공


 

적용 가능 시스템 조건
아래 세가지 조건을 모두 만족하는 경우 표준프레임워크 적용 가능
자바 기반의 웹 응용 시스템(WAS가 존재하는 경우)
② JavaEE(J2EE) 5 혹은 JDK1.5 이상의 환경
③ 신규 개발시스템으로써, 기존 시스템과 물리적 혹은 논리적으로 구분되는 경우
실행환경 내 모바일 표준프레임워크의 사용자 경험(UX) 지원 기능은 프레임워크와 개발 언어 종류에 상관없이 활용가능 (javascript 기반)




적용 효과
정보시스템을 개발하거나 운영할 때 필요한 기본 기능을 미리 구현한 것으로 이를 기반으로 추가 기능을 개발하여 조립함으로써 전체 정보시스템을 완성할 수 있습니다.
적용효과는 건설/건축분야에서 핵심자재를 모듈화하여 비용 및 공사기간을 단축하는 기법과 유사함
※ 건설/건축분야에서 핵심자재를 모듈화하여 비용 및 공사기간을 단축하는 기법과 유사

『표준프레임워크 적용 전/후 비교표』
표준프레임워크 적용 전 표준프레임워크 적용 후
정보화사업별 동일한 기능들의 중복 개발 공통컴포넌트 재사용으로 중복 예산 절감
기술 종속으로 인해 선행사업자 의존도 높음 표준화된 개발기반으로 사업자 종속성 해소
프레임워크 미 보유업체는 경쟁 불리 프레임워크 무상제공으로 중소기업 경쟁력 향상
정보시스템간 상호 연계 시 많은 기간과 인력이 소요 표준화된 연계모듈 활용으로 상호운용성 향상
개발표준 미흡으로 유지보수가 어려움 개발표준에 의한 모듈화로 유지보수가 용이


표준프레임워크 1.0의 관련 환경 변화
표준프레임워크 1.0이 빠른 속도로 보급 및 확산됨에 따라 관련환경에 많은 변화가 발생하였으며, 이에 대한 분석을 통해 다음과 같은 표준프레임워크 차기 버전(2.0)의 개선 시사점을 도출하였습니다.


 



개선시사점으로 다양한 수준의 개발자 사용지원, 다양한 규모 및 형태의 사업지원, 새로운 트렌드의 기술 반영, 버전업된 오픈소스 반영, 적용현황 파악 도구 및 방안지원임


 

표준프레임워크 2.0의 개선 방향
표준프레임워크 1.0의 관련환경분석으로 다음과 같은 개선전략을 도출하였습니다.


표준프레임워크 2.0 개선 항목 도출은 오픈소스 업그레이드, 경량화 최적화, 표준준수 및 지원, 모바일 표준프레임워크임


표준프레임워크 2.0 기능 확장 방향
표준프레임워크 1.0의 관련환경분석으로 다음과 같은 개선전략을 도출하였습니다.


표준프레임워크 1.0의 관련환경분석하여 개선전략으로 모바일 프레임워크를 추가하였음

반응형

+ Recent posts