Puppy's paw

단순히 프로그램내에서 변경되지 않길 바라는 변수에 final을 쓴다고만 알고 있었다.

실제로 개발을 할 때 그렇게 쓰기도 했지만 굳이 안써도 문제되는 상황은 없었다.

그런데 lambda를 공부하면서 익명 메서드를 넘기면서

final 변수가 강제로 필요하게 됐고.

왜 만들어 논지 알게 됐다.

자바 입문할 때 익명 클래스 만들 때 그냥 안되니까 final을 썼던 기억이 난다.

그때는 왜 안되는지 따지기에는 너무 어려워 보였었다.

자동 생성되는 트리거말고는 써본 적이 없다.

오라클에서 다중 입력을 하는데  시퀀스가 증가되질 않아서 제약조건 에러가 발생한다.

그래서 insert전에 각행에서 시퀀스가 따로 실행되게 만들었다.

create or replace trigger pst_trg

    before insert on positions

    for each row

begin

    :new.pst_num := SEQ_PST_NUM.nextval;

end;

다른데 어떻게 적용해야 할 지 모르겠지만 일단 신기하네~

투자자 - 시행사 - 하청업체 

시행사와 하청업체는 협력업체 관계

이런 구조에서 시행사에서 PM이 나오고

하청업체 개발자들(나)과 일을 한다.

하나의 일에만 전념한다면 프로젝트가 성공적으로 가겠지만

두 업체 모두 개발이 체계적으로 잡혀있지 않은 경우 참 힘들다.

만1년이 되가는 개발자(나) 매일 야근하면서 피곤에 쩔어 개발중

프로그램 전체 구조를 볼 수가 없다.

자꾸 뭔가 새로운게 생기지 않길 기도하고 걱정하면서 개발한다.

PM과 하청업체 관리자는 개발에 대한 관심보다 자기일 하기 바쁘다.

개발은 늦어지지고 본인들 생각과 결과물은 점점 거리가 멀어진다.

해야 할게 너무 많다. 개발 직접 도와줄거 아니면 나한테 아무말 안시켰으면 하는 마음

결국 시험테스트날 문제가 터진다.

시행사와 하청업체는 서로 말이 달라 티격태격

예상 했던 일이다.

어떻게 하면 이일을 막을 수 있었을 까

나한테는 어느정도 책임이 있는 걸까

어째든 다음에 내가 이런 일을 막으려면

아무리 개발할 시간이 부족해도 요구사항에 대한 우선 순위를 표를 만들어서

매일 보고하는 수 밖에 없을 것 같다.

내 실력이 어느정도 위치인지 계속 눈치를 봐왔지만 이제 그럴 필요 없는 것 같다.

그냥 지금 상황은 내가 주도해서 다 하는게 차라리 낫다.

개발일정이 조금이라도 늦어지면 철저히 보고를 해야 겠다.

답답하면 사람 더 뽑겠지

그리고 늦어지는 이유를 설명하고 야근은 배째야겠다.(하지만 그럴 수 있을까?)

물론 내 삽질로 늦어진거면 마무리 지어야한다.

답답하면 직접 개발하던가~

프로퍼티를 쓰는 것도 좋겠지만

왠지 enum이 멋져보인다.

javascript에서도 따로 네임스페이스를 둬서 관리하는 것이 좋은 것 같다.

javascript는 package가 없다

하지만 package.json 이라는 파일을 많이 본적이 있다.

아마도 프레임워크에서 쓰는 것으로 추측된다.

아는 프레임 워크는 없지만

javascript트도 package관리의 필요성이 절실히 느껴졌고

namespace를 package처럼 쓰기로 했다.

클래스 패키지는 아니지만

여러 사이트의 api를 짬뽕해서 쓰다보니(이런 프로젝트는 최대한 피하도록 합시다.)

관련 url 주소들을 패키지화해서 관리하는 것도 괜찮다.

값들을 final로 주고 싶지만 json 내부 요소들은 const지정을 할 수 없다.

이렇게하면 to_char를 쓰는 번거로움을 줄일 수 있다.

<property name="connectionInitSqls">

            <list>

            <value>ALTER SESSION SET NLS_DATE_FORMAT = 'RRRR-MM-DD HH24:MI:SS'</value>                

            </list>            

</property>

ALTER SESSION SET NLS_DATE_FORMAT = 'YYYY MM DD';

링크 목록들 하드코딩하지 말고 묶어서 뿌리는 좋은 방법이 없을 까

단순히 DB에 넣어놓고 불러오는 건 스마트 하지 않은 것 같다.

개발문서에서 불러와서 DB에도 넣고 링크도 넣고

문서에서 계층 구조로 뽑아내야 하는데 쉽지 않다.

시간만 있으면 할 수 있을 텐데

svn repository /conf 로 들어간다

svnserve.conf

[general]

anon-access = none

auth-access = write

password-db = passwd

authz-db = authz

realm = repository 제목

passwd

user1 = 1234

user2 = 1234

authz

[/] //root에서 시작되는 경로

user1 = rw

user2 = rw

svnserve 데몬 재 시작

service svnserve restart

ps -ef | grep svnserve

MVC패턴으로 작업하거나 기존의 소스들을 보다보면

항상 interface를 먼저 작성하고 impl 클래스를 구현한다.

하지만 지금까지 해온 프로젝트들 중에서 interface가 없어도 아무런 문제가 없는 경우가 상당히 많았다.

interface를 써야한다고 누군가를 설득해야할 때 이런 경우 설명할 수 없었다.

해봤자 교과서에 나오는 결합도를 낮추고 다형성을 추구한다는 말로는 명확히 설명할 수 없다.

스프링 관련 책에서 postProcessor관련 부분을 보는 중

객체를 캐시가능한 개체로 교체하게 되면 인터페이스가 아닌 기존 설정 클래스로 불러오는 과정에서 에러가 발생한다.

이전 객체는 새 객체로 교체 되었기 때문이다.

이런 경우 인터페이스를 통해 불러오게 된다면 같은 인터페이스를 구현한 객체들을 교체해도 예외가 발생하지 않는다.

간신히 interface와 serviceImpl의 필요성을 느낄 수 있었다.

그런데 스프링 AOP로 구현한다면 proxy객체로 반환할 텐데 이 경우 그대로 serviceImpl을 쓸 수 있는 것 아닌가 생각이 든다.

테스트를 해봐야 하는데 음...