AOP 핵심

[Advice]
무엇을 할 것인가?
 
[Point-Cut]
어느 동작에 Advice를 적용할 것인가?

[Join-Point]
Point-Cut의 어느위치(시점 ex> 전/후/전.후/중간 )에서 Advice를 동작 시킬 것인가?

E Hacking News


http://www.ehackingnews.com/

검색 엔진에 대해 학습할 기회를 가졌습니다. 검색 엔진은 왜 필요 했을까?

그렇다면 검색엔진의 특징을 어떻게 식별하며 검색엔진의 정의를 어떻게 내릴 것 인가?

간단하게 의견 중 하나를 옮겨 적습니다.

What is a search engine?

• A search engine is a service that utilizes a computer program to search the Internet and identify items that match the characters and keywords entered by a user.

Why use a search engine?

• Search engines are useful for finding information on organizations, groups, and personal web pages related to a topic. They can also be used for finding articles, but it can be difficult to narrow down results, find relevant material, and assess the legitimacy of information found on the Internet. It is especially important to be wary when using Internet sources, as there is are no quality control mechanisms that verify the validity of information on individual web pages.

1교시 => 14페이지까지 작성, 2문제 1페이지씩, 8문제 1페이지 반씩 작성

1. 소프트웨어 아키텍처 정의, 세가지 주요요소 중심으로 기술
=> 아키텍처 정의, 필요성, 3가지 주요요소는 4+1뷰, 스타일, 한가지가 생각나지 않아 그냥 specification으로 썰을 품...

2. 디자인 패턴과 아키텍처 스타일 차이 설명
=> 디자인 패턴의 생성, 구조, 행위로 구분 설명, 아키텍처 스타일은 Shaw/Garlan(맞나?) 5가지 스타일 중 3가지 정도 기술, 둘 사이의 비교표 작성

3. GPL, BSD 개념 비교 설명
=> 공개소프트웨어 라이센스 개념 설명, 필요성, 종류(GPL, LGPL, BSD, MPL), GPL, BSD 비교표

4. 전자상거래 보안 4가지 원칙
=> 전자상거래 보안 필요성, 4가지 원칙은 기밀성, 무결성, 부인방지, 인증으로 썰을 품, 각각의 주요 기술 추가..

5. 데이터베이스 트랜잭션 정의, 특징
=> 트랜잭션 개념(직렬화로 썰을 품), 필요성, ACID로 특징 설명..

6. UCC 용어 및 개념 정의, 종류
=> 웹2.0 트랜드로 썰을 품, 종류는 동영상, 블로그 등으로...

7. 사용자 인터페이스 테스트, 기능테스트, 비지니스단 성능 테스트, WAN 구간 성능 테스트
=> 테스트 개념, 필요성, 각각의 테스트에 대한 설명...적당히 썰을 품...

8. DBA 정의, 주요직무, 필요기술, 주요역할
=> DBA 정의, 필요성, 주요직무(DB관리, SQL 최적화, 모니터링, 디스크 관리 등으로 썰을 품..)

9. 요구사항 애매모호성 제거 규칙 예
=> 요구사항 애매모호성 제거를 위한 요구공학, XP에서의 SPIKE, 형상관리 베이스라인 등 잡다구리하게 섞어서 썰을 품..

10. WRML 배경, 구조
=> 제낌

11. 지능형 네트워크 로봇 구조
=> URC의 정의, 등장배경, 구성도, 구성요소

12. 차세대 이동통신 종류, 특징
=> 제낌

13. 수석감리원, 감리원 자격기준
=> 제낌

2교시 => 12페이지 위 2줄정도까지 작성, 모든 문제 품.

1. 프로젝트 정의, 프로젝트 관리 정의, 프로젝트 수행 업종, 업의 특성/개념, 위험관리
=> 프로젝트 특성(목표지향적, 일시적, 시간제한적, Rolling Plan 등)으로 썰을 품.. 업종은 건설업, 항공기 제작으로, 업의 특성은 프로젝트 특성을 다시 응용, 위헙관리는 말 그대로..

2. 정규화
=> 괜히 건드렸다 망했음...

3. 5-Force, 7S, SWOT 분석 기법, 연결 절차
=> 제낌

4. 기술사법 내용, 쟁점, 정보통신공사업법 개정내용, 제도개선 방향
=> 제낌

5. 소프트웨어 품질평가 기술 유형, 비교설명, 유형별 대표적 표준/모델, GS인증 유형
=> ISO 9126으로 품질 속성 썰을 풀고, ISO/IEC 14598, ISO/IEC 25000, ISO/IEC 15408로 잡다구리하게 썰을 품..GS인증은 여러 표준을 섞어 한국형 모델로 만들었다고 썰을 품..GS인증 활용방안 추가

6. SOA, 웹2.0, 비교
=> SOA 기본 개념(서비스요청자, 브로커, 서비스 제공자), 웹서비스 개념, 웹2.0은 Long Tail, OpenAPI, Mesh-up, UCC, 블로그, Collaboration으로 썰을 품, 둘 사이 비교표 작성

3교시 => 12페이지 정도 작성

1. 데이터 이관 절차 유의사항
=> 제낌

2. 범위관리, 위험관리, 일정관리, 예산관리, 품질관리, 의사소통관리, 자원관리
=> 각각에 대해 정의 관리 기법 표로 기술, 범위관리는 WBS, RAM, 위험관리는 PI매트릭스, 정성적/정량적분석, 회피/완화/전이/수용, 일정관리는 PERT, CPM, Fast Track, Crash, Resource Levelling, 예산관리는 기성고(EVA, 그래프, CPI, SPI), NPV, IRR, 품질관리는 Control Chart, 어골도, 품질통제, 품질보증, 의사결정트리, 파레토, 의사소통관리는 Formal Written, 킥오프미팅, 자원관리는 Resource Levelling으로 썰을 품

3. 행자부 IRM, ITA와의 관계 향후 발전방향
=> IRM을 ILM으로 썰을 품..ITA 주구장창 설명(개념, 프레임워크), IT거버넌스 비스무리하게 IRM을 ITA 하위로 집어 넣고, 나머지는 IT거버넌스, CoBit 4.0, CMMI, 6시그마, ITIL, ITSM, e-SCM, ISO20000을 한 그림으로 쎄려 넣음...

4. Computer Forensics 구조, 발전방향
=> 정의, 필요성, 절차(중간 이송절차를 빼먹었음...), 원칙(정당성, 신속성, Chain of Custody), 기법(data, system, network, application으로 구분), 발전방향은 Embedded Device, Data Mining 활용, Incident Management에 활용으로 썰을 품..

5. 소프트웨어 테스트
=> 테스트 개념, V-diagram, blackbox, whitebox, 상향식, 하향식, 통합, 단위, 뮤테이션, 리그레션, 경계값, 동등분할, 경로산출공식, 인스펙션, 워크스루, PSP/TSP 주구장창 다 쎄려넣음...

6. UML모드 자바코드 작성
=> 제낌

4교시 => 12페이지 작성

1. 성능향상 튜닝
=> 제낌

2. 정보화사업관리(PMO) 계약구조, 관리구조, 법제도 측면 발전방향
=> PMO 개념, 필요성, 종류(컨설팅, 내부조직), 정보화사업관리에서의 PMO(대충 PMO 기본 개념에 적절히 정보화 사업 버무림), 법제도적으로 대형사업시 PMO 도입 의무화 등으로 썰을 품...

3. 정보기술아키텍처 구축 단계, 메타모델, Architecting, Modeling 차이
=> ITA 개념, 자크만 프레임워크, 메타모델은 BRM, PRM, SRM, TRM, DRM으로 썰을 품...Architecting과 Modeling도 적당히..

4. Product Line 배경, 개발단계, 단계별 활동, 기존 방법론과 비교
=> Product Line 등장배경(구조적->정보공학->객체지향->CBD->?), Core Asset, 개발, 관리로 썰을 품.. CBD와 비교 했다가 좀 이상해서...RAD, RUP와 추가 비교표 작성

5. 소프트웨어 발주관리 핵심 수명주기 프로세스, 발주 프로세스, 공급 프로세스
=> ISO/IEC 12207(맞나?)을 TTA 표준 제정 및 수명주기 프로세스로 썰을 품...기본, 지원, 조직 세가지 영역 내 세부 구성요소 그림, 발주 프로세스는 일반적인 조달 절차로 썰을 품..RFI, RFP, 제안서, 입찰, 계약, 공급으로..공급 프로세스는 목표선정, SWOT 분석, 요구사항 분석, 개발, 시험, 공급, 유지보수로 썰을 품...

6. SaaS 개념, 현황, 국내외 기업
=> 제낌

REST(Representational State Transfer)

Fielding, Roy Thomas가 2000년 박사 논문으로 작성한 글이 그 원조젹으로 받아들여지는 것 같습니다.

첨부 파일로 올려 언제라도 볼 수있게 했습니다.

[WEB_ARCH.7z] 는

같은 아저씨가 2002년에 작성한 글 입니다.

"Principled Design of the Modern Web Architecture"

Hadoop

http://www.michael-noll.com/tutorials/writing-an-hadoop-mapreduce-program-in-python/

http://www.lunchpauze.com/2007/10/writing-hadoop-mapreduce-program-in-php.html

이젠 아무거나 막 퍼다 담습니다.

정작 중요한건 정리된 글을 본인의 이름을 걸고 써야 하는 데...

아쉽기만 합니다. ^^

When asked what they mean by scalability, a lot of people talk about improving performance, about implementing HA, or even talk about a particular technology or protocol. Unfortunately, scalability is none of that. Don’t get me wrong. You still need to know all about speed, performance, HA technology, application platform, network, etc. But that is not the definition of scalability.

Scalability, simply, is about doing what you do in a bigger way. Scaling a web application is all about allowing more people to use your application. If you can’t figure out how to improve performance while scaling out, its okay. And as long as you can scale to handle larger number of users its ok to have multiple single points of failures as well.

There are two key primary ways of scaling web applications which is in practice today.

• “Vertical Scalability” – Adding resource within the same logical unit to increase capacity. An example of this would be to add CPUs to an existing server, or expanding storage by adding hard drive on an existing RAID/SAN storage.
• “Horizontal Scalability” – Adding multiple logical units of resources and making them work as a single unit. Most clustering solutions, distributed file systems, load-balancers help you with horizontal scalability.

Every component, whether its processors, servers, storage drives or load-balancers have some kind of management/operational overhead. When you try to scale that, its important to understand what percentage of the resource is actually usable. This measurement is called “scalability factor“. If you loose 5% of a processor power every time you add a CPU to your system, then your “scalability factor” is 0.95. A scalability factor of 0.9 means you will only be able to use 90% of the resource.

Scalability can be further sub-classified based on the “scalability factor”.

• If the scalability factor stays constant as you scale. This is called “linear scalability“.
• But chances are that some components may not scale as well as others. A scalability factor below 1.0 is called “sub-linear scalability“.
• Though rare, its possible to get better performance (scalability factor) just by adding more components (i/o across multiple disk spindles in a RAID gets better with more spindles). This is called “supra-linear scalability“.
• If the application is not designed for scalability, its possible that things can actually get worse as it scales. This is called “negative scalability“.

If you need scalability, urgently, going vertical is probably going to be the easiest (provided you have the bank balance to go with it). In most cases, without a line of code change, you might be able to drop in your application on a super-expensive 64 CPU server from Sun or HP and storage from EMC, Hitachi or Netapp and everything will be fine. For a while at least. Unfortunately Vertical scaling, gets more and more expensive as you grow.

Horizontal scalability, on the other hand doesn’t require you to buy more and more expensive servers. Its meant to be scaled using commodity storage and server solutions. But Horizontal scalability isn’t cheap either. The application has to be built ground up to run on multiple servers as a single application. Two interesting problems which most application in a horizontally scalable world have to worry about are “Split brain” and “hardware failure“.

While infinite horizontal linear scalability is difficult to achieve, infinite vertical scalability is impossible. If you are building capacity for a pre-determined number of users, it might be wise to investigate vertical scalability. But if you are building a web application which could be used by millions, going vertical could be an expensive mistake.

But scalability is not just about CPU (processing power). For a successful scalable web application, all layers have to scale in equally. Which includes the storage layer(Clustered file systems, s3,etc), the database layer (partitioning,federation), application layer(memcached,scaleout,terracota,tomcat clustering,etc), the web layer, loadbalancer , firewall, etc. For example if you don’t have a way to implement multiple load balancers to handle your future web traffic load, it doesn’t really matter how much money and effort you put into horizontal scalability of the web layer. Your traffic will be limited to only what your load balancer can push.

Choosing the right kind of scalability depends on how much you want to scale and spend. In fact if someone says there is a “one size fits all” solution, don’t believe them. And if someone starts a “scalability” discussion in the next party you attend, please do ask them what they mean by scalability first.

References

1. Cost and Scalability
2. My linear scalability is bigger than yours

This entry was posted on Saturday, September 22nd, 2007 at 6:14 pm and is filed under architecture, scalability. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

시간 강연 제목 8:30a-9:00a 등록 및 교재배부 9:00a-9:50a 초청강연. 중국의 서비스 연구 및 산업계 동향 (Service related Research and Industry in China) 10:00a-10:50a 초청강연. 스트림 기반의 서비스 지능화 (Stream-based Service Intelligence) 11:00a-11:50a Greens: 실용적 서비스 개발 방법론 (Greens:Practical Methodology to Develop Services) 11:50a-1:00p 점심시간 1:00p-1:50p 초청강연. Social Website의 개념 및 활용 (Key Concepts and Applications of Social Websites) 2:00p-2:50p SOA, CC 서비스 모델링 기법 (Methods to Model SOA & CC Services) 3:00p-3:50p SOA, CC 서비스의 QoS 자율관리 기법 (Autonomous QoS Management for SOA & CC ) 4:00p-4:50p 서비스 분야의 첨단 기술 (State-of-the-Art Technologies in Services Ares) 4:50p-5:00p 차기 세미나 안내 주 최 : 주 관 : 일 시 : 장 소 : 브로셔: 정보통신산업진흥원 부설 SW공학센터 숭실대학교, MSSEC 연구센터, 한국소프트웨어기술진흥협회, 이노서비스( InnoService ) 2009년 10월 8일(목) 8:30am-5:00pm 숭실대학교 형남공학관 115호 [Download]

- Prof. C.H. Chi    현. 중국 칭화대학교 교수    Ph.D. Purdue University, USA - 김 원 교수    현, 경원대학교 종신교수 및 부총장    Ph.D. University of Illinois-Urbana-Champaign, USA - 김수동 교수    현. 숭실대학교, 컴퓨터학부 교수    MSSEC 센터장    Ph.D. University of Iowa, USA - MSSEC 책임 연구원    현. MSSEC 연구센터 연구원

사전 등록 - 이 세미나는 선착순 150명에 한하여 사전등록으로 진행 됩니다. - 좌석이 한정되어 있으므로 반드시 홈페이지를 통해 사전등록을 부탁 드립니다. - 사전등록 비용 5만원(중식, 교재비 포함) - 입금계좌: 우리은행 1005-201-417689( 예금주 : 이노서비스 ) 현장 등록 - 현장등록 비용 8만원(중식, 교재비 포함) - 이외 궁금하신 내용은 전화와 이메일로 문의해 주시기 바랍니다.

- 문의 : 02-826-0909 - email :help@otlab.ssu.ac.kr