행복한 개발자,HEIDI

스프링 프레임워크에 대해 깔끔하게 정리해 놓은 글이 있어 가져왔다. 출처: https://asthtls.tistory.com/896 [포장빵의 IT] 스프링 프레임워크의 장점 빠른 구현 시간 쉬운 관리 개발자들의 역량 획일화 검증된 아키텍처의 재사용과 일관성 유지 스프링 프레임워크의 특징 1. 경량(Lightweight) 스프링은 여러 개의 모듈로 구성되어있으며, 각 모듈은 하나 이상의 JAR 파일로 구성됨. 몇 개의 JAR 파일만 있으면 개발과 실행이 가능하다. 스프링 프레임워크가 POJO(Plain Old Java Object)형태의 객체를 관리함[POJO는 클래스를 구현하는데 특별한 규칙이 없다.]. 2. 제어의 역행(IoC, Inversion of Control) 비즈니스 컴포넌트 개발 시 낮은 ..

젠킨스 빌드를 실행시켰는데 프로젝트에서 빌드warning이 10개정도 나왔다ㅜㅜ VS에서 빌드할때 에러만 신경썼던 탓에 warning이 뜬것을 인지하지 못하고 push 했다....ㅎㅎㅎ 얼른 수습해보자 CA1001 warning이 뜨면서 IDisposable 형식 XXX의 멤버가 만들어지므로 XXX에 IDisposable을 구현하십시오. 어쩌고 뜨는 데 무슨 소리인지 1도 모르겠다. 우선 기본 배경을 살펴보자 warning 뜨는 기본배경: webservice reference (.net 웹서비스참조) 는 프로젝트 당 1개씩만 객체가 생성되어야 한다. 만약 객체를 1개이상 생성했다면 객체의 life cycle을 개발자가 관리해야 한다.(unmanaged resource). API에서 svc 파일을 만들고 ..

전자 결재 업무를 맡은지 6개월도 되지 않았을 때 데이터 처리 엔진이 너무 느려서 컴플레인을 받은 적이 있다. 사용량이 급격하게 늘은 탓도 있는 것같다... 계속 인지하지 못했는데 컴플레인이 들어와서 아이쿠 싶었다. 엔진이 워낙 레거시 시스템이고(주석을 보면 2006년 개발흔적도 있다....) 중요한건 관련 히스토리를 아는 분들이 퇴사하셔서 회사에 안계신다. 워낙 web에만 관심이 쏠려있는 시스템이라 엔진은 심지어 코드 형상관리도 되어있지 않았다ㅜㅜ 급하게 전임자의 PC 백업 파일을 뒤적거리다가 가장 최신인것같은 엔진 코드를 찾아서 연락해보니 운영계에 배포되어있는 엔진과 버전이 일치한지는 모르겠다고한다.....ㅜㅜ 그래도 이거라도 급하게 회사 git에 올려서 지금이라도 버전관리를 시작했다. 데이터 처리가..

일을 하면서 특정 모듈을 개발해야했었다. 내가 관리하던 도메인에서 다른 도메인으로 데이터를 전송하는 것이었는데, 배포 환경 등 여러가지 이유때문에 어려움이 있었다. 우선, 데이터 전송 방법에는 처음 생각하던 것이 두가지가 있었다. 1. AJAX를 이용한 데이터 전송 1 ) ASPX에서 AJAX 호출 스크립트를 작성 2 ) ASPX.CS에서 암호화 등 전송할 데이터를 가공 3 ) ASPX.CS에서 ScriptManager 로 정의한 스크립트 호출 2. ASP.NET 웹 서비스 참조 1 ) 웹 서비스 참조 추가 2 ) 객체 사용 ※ https://ojava.tistory.com/63 웹 서비스 참조 방법은 해당 링크에서 친절하게 설명해주어 잘 따라하면 된다.. 가 아니라 여기서 애를 많이 먹었다. 해당 링크..

진행하는 웹 프로젝트에서 @CrossOrign을 쓰는 부분이 있어 알고리즘을 정리해보았다. 사실 알고리즘이라고 할 것도 없지만... 머리 속이 복잡하고 자꾸 잊어버리는 성격때문에 그림으로 표현해보았다. urlA를 통해 urlB를 접속할때에만 로그인이 허용되도록 구현한것이다. urlA 계정으로 어떠한 활동을 하면 urlB에 이전에 계정이 생성된다. @CrossOrign을 이용한 해당 알고리즘을 통해 urlA인증을 받는 것이라고 할수 있다. 스프링 @CrossOrigin 에 대한 설정은 또 다음기회에..

웹 프로젝트를 진행하면서 두개의 서버에 데이터를 주고받아야하는 경우가 생겼다. 이러한 경우는 처음이라... 열심히 삽질을 하여 알게된 지식들을 잊어버리지 않기 위해 정리하겠다. 1. 동일 출처 정책(Same Origin Policy) 자바스크립트 엔진 표준 스펙에 동일 출처 정책이라는 것이 있다. 이는 자바스크립트에서 다른 출처의 문서나 스크립트 등 자원과 상호작용하지 못하도록 막은 보안 정책이다. 참고사이트: https://www.w3.org/Security/wiki/Same_Origin_Policy https://en.wikipedia.org/wiki/Same-origin_policy 아래의 위키백과에 있는 표를 보면 어떠한 경우에 동일 출처정책에 위반되는 지 알수 있다. 프로토콜,도메인,포트번호가 ..