꾸준함의 미학

어느 덧.. 멘붕의 시간이 끝나고..

포스팅을 못한 지난 달동안 너무 많은 일이 있었다

달이를 떠나보낸거.. 연봉상승도 다른 직원들에 비해 작았던 거..

일본출장도 4박 5일로도 갔다오고 (물론 그 속에도 정말 많은 일이 있었다ㅎㅎ)

또 이 프로젝트에서도 이렇게 고생하게 되고, 뺀질대는 사람을 만나서 스트레스도 받고 말이지..

혼돈의 나날이였다

그러면서 느낀 거는.. si는 나랑 맞지 않는 거 같다..

좋은 프로젝트도 있다고 하지만 현재 4번 다 이런 프로젝트가 아니였나?

어떠한 설명도 하지 않고 하라면 하라는 식이니 말이다 ㅠ

프로젝트하면서 영혼이 깎이는 느낌이 들어서 이번 프로젝트까지만 하고, 그만 둘 생각이다

물론 자금적인 부분도 있기 때문에 바로는 그만 못둔다ㅠ 그래도 모아두고 그만둬야지

그동안 부담감때문에 공부하던거나, 기록을 남기지 못했던 죄책감을 벗어두고,

나도 좀 즐기면서 삶을 살아갈 생각이다

잘해야한다 배워야한다 비전공자 라는 부담감으로 너무 누르지 않았나?

늦게 시작한 만큼 쫓아가기 바쁘다는 것도 사실이지만, 그렇게 되면 내가 너무 질릴거 같은걸

그래서 천천히 내 템포에 맞춰서 내 관심사에 맞춰서 개발을 할 생각이다

직장은 음 모르겠다 현재 생각으로는 내가 그리고 싶은 개발을 하고 싶기때문에

또 개발에 한정되고 싶지 않다~ 다양한 시도를 해보자

내일이면 만 31살인 나.. 화이팅이다

Buffered streams typically only call the native ouput API once the buffer is full.

* native 기본 typically 일반적으로

Sometimes it is appropriate to write from a buffer befor it is full.

this is called flushing.

* appropriate  적절한

This can be done by calling the flush method which is included in all alll output steam classes:

outStream.flush();

However, it is not always necessary to manually flush a buffer. For example, the close method automatically flushes the buffer before closing the stream.

* manually 수동으로 necessary 필요한

Using unbuffered I/O like FileReader can be inefficient because the read requests are handled directly by the operating system.

* directly by the operating system 운영 체제에서 직접, inefficient 비효율적

Using buffered streams can make a program more efficient. Data is written to or read from a buffer, and the native API is only called when the buffer is full. This reduces the number of necessary expensive operations like disk accecss or network activity.

A buffered stream an be created by passing an unbuggered stream object to a buffered stream constructor. For example:

input = new BufferedReader(new FileReader("in.txt"));

output = new BufferedWriter(new FileWriter("out.txt"));

Using generic classes in Java can sometimes result in verbose syntax for example : 

* verbose 수가 많은 inference 추론

Map<Integer, List<String>> hashMap = new HashMap<Integer, List<STring>>();

In Java 7+, we can simplify this by using the compiler's ability to infer the type arguments from context.

This allows us to avoid specifying the same type arguments multiple times.

The previous example now becomes :

Map<Integer, List<String>> hashMap = new HashMap<>();

We now only have to state the type arguments once.

The compiler will be able to infer from this assignment statement that the type of the new HashMap<>() should be <Integer, List<String>>.

The following class can accept and return any type of object.

It cannot, however, accept primitive types (그러나 기본 유형을 허용할 수는 없습니다.)

public class Box {
	private Object object;
    public void set (Object object){
    	this.object = object;
    }
    public Object get(){
    	return object;
    }
}

If we want to create a class that can accept and return any type, we need to replace references in our code to Object with a generic type variable T.

public class Box<T> {
	private T t;
    public void set (T t){
    	this.t = t;
    }
    public T get(){
    	return t;
    }
}

In a generic class,  the <> following the class name is the type parameter.

This is how you would instaniate an object of Box class that can accept and return any type:

* following 다음 instaniate 인스턴스화 하다.

* This is how you would instaniate  이것이 당신이 인스턴스화하는 방법입니다

* This is how you would 이것이 당신이 ~ 하는 입니다

Box<Integer> box1 = new Box<Integer>();

Box<Integer> box2 = new Box<>();

Sometimes it may be appropriate to write a generic method, however it will not be possible for it to accept every type while still maintaining all the necessary functionality.

To solve this, use bounded type parameters to restrict generic methods from accepting arguments of particular kind.

* accepting 수락 , particular 특정한 restrict  얽매다

public <T extends Shape>
	void drawAll(List<T> shapes){
    	for (Shape s : shapes){
        	a.draw(this);
        }
    }
}

The above method is used to draw a list of shapes. Writing a generic method with an unbounded type parameter would cause problems because lists of other types cannot be drawn in this way.

By specifying that <T extends Shape> we guarantee that only Shape objects can be passed to the method.

* The above 위 의 specifying 지정, guarantee 보장하다