Vamos ser Programador com Devfon

static 그리고 접근제한자

static

• static 멤버는 class 안에 실제로 존재
  • 즉, object의 선언 없이 사용 가능한 멤버

public class Test{
    static int s = 0;
    int t = 0;

    public static void print1(){
        System.out.println("s = " + s);
//      System.out.println("t = " + t);
//      non-static member 접근 불가
    }

    public static void print2(){
        System.out.println("s = " + s);
        System.out.println("t = " + t);
    }
}

• Java에서의 프로그램은 class들의 집합이기 때문에 main 함수 역시 class 내에 존재해야 함
  • 하지만 class의 객체 생성 없이 main method는 실행되어야 하기 때문에 항상 static으로 선언되어야 함
• static 멤버 변수의 접근 방법?
  • 'object명'. 과 같이 해도 정상작동하는 경우 많으나, 엄격한 compile 규칙을 따른다면 틀린 것
  • 따라서 class에 속하는 멤버이므로, '클래스명'. 과 같이 접근하는 것이 정석

public class Test {
    static int s = 10;
    int t = 0;
    
    public static void print1() {
        System.out.println("s = " + s);
    }
    
    public void print2() {
        System.out.println("s = " + s);
        System.out.println("t = " + t);
    }
    
    public static void main(String[] args) {
        Test test1 = new Test();
        test1.t = 100;
        test1.print2

        // static 멤버 접근 방법
        Test.s = 100;
        Test.print1();
    }
}

• static 멤버의 용도
  • main method
  • 상수 혹은 클래스 당 하나만 유지하고 있으면 되는 값
    • ex) Math.PI, Systemo.out
  • 순수하게 기능만으로 정의되는 method
    • ex) Math.abs(k), Math.sqrt(n), Math.min(a, b)

접근 제어: public, private, default, protected

• public: 클래스 외부에서 접근이 가능
• private: 클래스 내부에서만 접근 가능
• default: 동일 패키지에 있는 다른 클래스에서 접근 가능
• protected: 동일 패키지의 다른 클래스와 다른 패키지의 하위 클래스에서도 접근 가능

데이터 캡슐화

• 모든 데이터 멤버를 private으로 만들고 필요한 경우 public한 get/set method를 제공
• 객체가 제공해주는 method를 통하지 않고서는 객체 내부의 데이터에 접근할 수가 없음
  • 함부로 데이터를 접근하거나, 수정할 수 없음
• 이것이 data encapsulation 혹은 information hiding

popit 멘토링 데이 Review

개발자들의 글을 발행하는 서비스 popit에서 진행한 멘토링 데이를 다녀왔다. 2개의 타임 세션으로 나누어 진행된 이번 멘토링의 경우, 세션 별로 본인이 선택한 멘토 3분 중 1분을 랜덤으로 배정 받아 멘토링을 받는 방식으로 진행되었다. 나는 두 세션 모두 데이터 관련 멘토를 신청해서인지 모두 데이터 관련 멘토로 배정을 받아 멘토링 시간을 보내게 되었다.

윤xx 멘토님(Melon)

• Melon 빅데이터 팀 근무
  • 프레임워크 개발 -> 빅데이터 엔지니어(Hadoop, HBase)
  • 음악 추천 팀 using Ni-Fi
• 좋은 아키텍쳐를 사용할 수 있는 조건?
  • 위에서 시켜주어야 한다!
  • 정말로 시켜주었 때 수행할 수 있는 능력을 가지고 있어야 하기 때문에 결국 관련 공부를 계속 이어가야 함
• feedly 사용해서 공부 계속 이어나가는 것 추천(Get feeds from various sites)
  • 이전에 내가 무엇을 공부해야하는지를 알아야 함
  • 내가 가진 기술과 업계 동향을 수신받으며, 역량을 키워야 함
• 데이터 팀의 구성은 과학자 3명:분석가 10명 정도
• 600개의 자소서는 HR에서 걸러짐 -> 60개 자소서 넘어오면 결국 보는 것은 8개..
  • 이후, 1차 테스트 -> 2차 면접
  • 면접은 당장의 실력보다, 기술을 따라가고자 하는 의지를 보는 경우가 많음
    • 회사에서 시간을 주어줄 때 학습할 수 있으면 됨
  • +) 프로토콜, 알고리즘 등 개발자로서 평생 가져가야 하는 지식들도 잘 갖추고 있어야 함
• why NiFi?
  • 기술 선택할 때는 그 시점에 가장 유행하는 기술을 사용하는 것이 좋음
  • 실시간 데이터 수집에 NiFi 사용
    • ETL을 모두 처리하는 NiFi
    • Flume - Kafka - NiFi
  • 각 에이전트에 Flume 사용
    • 통계자들에게 넘기기 위해 원시코드 사용하기 보다는 SQL을 이용하는 편
  • CDC: 데이터를 캡쳐 및 저장하는 기능(CRUD 모두 캡쳐)
    • Query Table Capture
• Oozie로 data batch 역할 수행
• 오픈소스는 사용 상 문제가 생기면 소스 코드를 열어보는 수 밖에 없음
  • 소스 코드를 이해할 수 있는 사람이 조직에 있어야 하는 이유
  • 소스 코드를 이해할 수 없으면 해당 기술을 도입하면 안되는 것으로 간주해도 무방
• Open source는 version up을 잘 하지 않음
  • Version up 하는데 1달 여의 시간이 드는데, 그에 비해 큰 효용 X
• 장애 발생 시 대체 컨텐츠 발생시키면 큰 문제가 없음
• Melon의 경우 Web log가 일 평균 4-50G 발생하는 수준
• 업무를 통한 실력의 향상을 추구하는 것이 주니어 때는 바람직함
• 빅데이터 라는 Terminology 사용하는 것도 중요
  • 고객에게 팔리는 용어를 사용하는 것
• 본인의 경우 아티스트와 사용자의 '친밀도' 시스템 도입하면서 멜론에 Hadoop 도입하게 됨
  • 데이터에 분석에 대한 고객의 needs가 충분히 있었던 시점
• 데이터 엔지니어에게 Hadoop은 기본 중의 기본
  • manual에 적힌 지식을 자신의 지식으로 소화하는 것이 중요(why this Option? / Working algorithm 등)
• 취업 이후에나 비즈니스 이해도를 갖추어야 함
  • 이전까지는 Basic concepts에 대한 이해가 더 중요
• 데이터 엔지니어는 tensorflow에서 나온 output을 pipeline화하는 할 줄 알아야 함
  
  

홍xx 멘토님(SK)

• 바이오-인포매틱스: data로 질병 연구
  • 인간 게놈 프로젝트: 무질병자와 질병자의 신체적 특성 비교(SMP)
  • 한 사람 sequencing하면 대략 4TB의 데이터가 나옴
  • 바이올로지는 system 만드는 것을 연구로 삼음
• J2EE에서 Spring으로 넘어가던 과도기 시절 웹 개발 시작
• Grid Computing / Parallel Computing 시대
• Network Management System으로 SK 시작
  • 고객의 경험 품질을 지수화 시키는 프로젝트
  • 큰 데이터를 다뤄본 경험이 중요!
    • 1시간에 2천 억건의 데이터 발생 -> 하루 100TB
  • +) 데이터웨어하우스: 나뿐만 아니라 다른 사람들도 데이터를 활용할 수 있는 환경을 구축하는 프로젝트
• 처음 빅데이터 플랫폼 시작은 바이올로지 논문 사이트에서의 검색
  • Like search에서의 성능 향상을 위해 관심 가지게 됨
  • 더그 커팅의 Lucene
  • Lucene의 한글화 지원하도록 재컴파일 하는 wiki 작성
  • 이후, Apache Nutch
• Hadoop은 삼성에서 적용하기 시작
• 오픈 소스의 활성화에 큰 기여를 한 Hadoop
  • Storage 시장이 많이 바뀜
  • Oracle과 같은 솔루션 기업이 아닌 오픈 소스의 활용이라는 결정으로 바뀌게 됨
• 순수 엔지니어로 성공하기 어려운 한국 사회
  • SI기업들의 Man/Month -> 돈 깎기 싸움 -> 환경 악화
  • 성공하기 위해서는 정말 실력이 좋거나 vs 10년 정도 같은 업무를 반복했거나
• 플랫폼에 쌓이는 데이터를 가지고 무언가를 만들고 싶어하는 현 시장
  • 많은 회사에서 데이터 관련 부서를 관리하려는 경향 생김
• 앞으로도 데이터 시장은 오래 갈 트렌드인 것 같음
• SK의 Data Transformation 팀
  • 부문 직속 팀일 정도로 높은 rank에 자리하는 data 팀
  • 분산형 조직(Best) Data 관련 기획 팀 / Big data platform 팀 / data service 팀...
  • cf) 기능형 조직은 필요로 할 때에만 채용하는 수준
• 도메인 전문가 + 데이터 엔지니어 + 데이터 분석가로 구성되어야 그나마 성공확률이 높아짐
  • 도메인 전문가가 없으면, 나머지 둘은 무엇을 할 줄 모름
  • 자기 영역에 먼저 전문가가 되고, 이후 다른 한 도메인을 잘 하는 정도로 공부해야 함
  • 대개 분석으로 도메인 확장하나, 혹은 다른 한 쪽의 도메인 확장할 수도 있음
    • 그 같은 전문가가 별로 없기 때문에 자기만의 장점을 갖출 수 있음
• 서비스를 IT를 잘 모르고 사용하는 사람들도 사용할 수 있도록 제공하면 인정 받고 역량이 성장됨
• 데이터에 대한 오너십을 가진 부서를 가진 곳을 가는 것이 개발자로서의 성장에 도움이 됨
  • 데이터에 접근하는 것이 사실 더 어렵기 때문
• 학생 수준에서는 하나의 기술을 deep하게 파는 것이 아니라 다양한 기술을 공부해보는 것이 중요
  • 그의 장단점을 볼 줄 아는 안목을 길러야 함

두다지 서버 개발자 양성 프로그램 Week 8

8번 째 멘토링

네트워크의 Transport Layer와 Network Layer에 대한 공부를 마치고, 그에 대한 정리를 멘토링을 통해 하였다. 또한 지난 주에 과제로 제출되었던 UDP로 TCP 구현하기 과제의 일부를 해서 갔다. 네트워크를 공부하며 느끼는 점은 물리적 계층에 가까워지는 Layer일수록 그 깊이가 더 깊어 이해하기가 힘들다는 것이다. 아직 Link Layer는 추가적으로 학습하지 못했지만 지금까지 이해한 것보다 어려울 것 같다는 느낌을 강하게 받았다.. 작년부터 전산학을 공부함에 있어 네트워크가 계속 발목을 잡는 듯한 느낌을 받는다. 앞으로 서버 개발자를 목표하기 위해서는, 멘토링 이후에도 네트워크는 추가적으로 공부를 더 해서 제대로 이해하고 넘어가야 할 것이다.

학습한 것에 대한 리뷰

• UDP는 socket을 통해 1:1 연결을 하기 때문에 header에 2가지 정보를 포함해야 함
  • destination IP, destination Port number
• TCP는 welcome socket 하에 1:n의 연결을 하기 때문에 header에 4가지 정보를 포함해야 함
  • destination IP, destination Port number, source IP, source Port number
• Network Layer에서 IP protocol은 비신뢰적 전송
• 네트워크 지원 하의 혼잡 제어는 single bit 전송을 통해 이루어짐
• 2-way handshaking의 경우, Client의 중복된 conn_req를 Server가 Client의 종료 이후 받게 되면, Server가 socket을 열게 되는 half open connection의 문제가 발생할 수 있음
• c언어 헤더 include 순서
  • 내 헤더를 가장 마지막에 작성해줌
• debugging을 위해 logger 사용하자
• 항상 unittest 하기
  • 내 프로그램이 잘 작동한다는 것은 unittest로 검증한 후에 시나리오 대로 동작시켜보아야 함
• C에서 fread는 읽어온 것만큼만 전달하도록 readcount 변수를 추가적으로 사용해주어야 함
  
  

Computer Network

• Transport Layer는 process 간 연결을 도와주는 계층
• Application 단에서 Transport 계층에게 명령하여 상대 host에게 데이터를 전송
• 왜 3-way handshake / flow control / congestion control을 하게 될까?
  • 서로 다른 계층에서의 성능 보장을 신뢰하지 못하기 때문
  • 네트워크 통신에서의 변수가 통제된 상황에서는 무조건 성능의 보장 가능
    • 그러나, 현실 네트워크는 그렇지 못하기 때문에 통제 되지 않은 상황을 고려한 프로토콜이 필요한 것
• 전송 과정에서 거치는 hop의 성능을 알지 못하는 윗단
  • Transport Layer에서는 그저 최선의 상황을 가정해서 전송하는 것
• Congestion control에서는 doubling의 threshold를 어떻게 잡을 까에 대한 문제 있을 수 있음
  • 결국, threshold를 잘 모르기 때문에 doubling을 구현하는 것
  • 일종의 땜빵코드(best effort..)
  • 절반으로 줄이는 TCP Tahoe도 같은 개념
  • Packet loss는 일종의 congestion 발생했다는 signal 처럼 이용되는 것
• 네트워크 내의 여러 상황 때문에 General Purpose 상황에서 네트워크 이용률을 50%까지 올리는 것도 매우 어려운 일
• 2-way handshake에는 다양한 문제가 있음
  • half open connection / doubly connected...
  • Server가 연결에 대해 보낸 ACK와 ACK 이후 즉시 보낸 data의 순서가 보장되지 않음
  • 따라서 서로가 정상적으로 연결(혹은 연결 해제)되었다는 것을 인지하고 communicate하는 것이 좋음!
    • cf. close는 4-way handshake
    • close 상황이 완전히 이루어지기 전에 유실되었던 segment의 전송 등을 고려하여 연결의 종료가 이루어짐
      
      

다음 주 까지의 assignment

• 네트워크 과제 마무리
  • Packet에 TCP header 부여
  • listen() for. 3-way handshake 구현
  • flow control 구현 (순서 보장)
  • Fake Router 구현
    • Get datas from Client & send datas to Servers