분명히 알았는데, 다시 되짚어 보려니 뭔가 모호해서 generics를 정리해보기로 했다. 글로 하나씩 정리해보는 거랑 그냥 알고 있다고 생각하는 거랑 생각보다 큰 차이라는 걸 요즘 들어 느낀다. 오늘은 <Object> 와 <? extends Object> 의 차이.

한동안 못 보다가 다시 틈 날 때마다 알고리즘 문제를 하나씩 보고 있다. 전에는 백준에 주로 갔었는데 요샌 귀찮아서 Hackerrank에서 하나씩. 그리고 이제부터 푸는 문제는 차차 정리해서 올리기로! 예전에 풀었던 문제들도 언젠가…

오늘은 Sherlock and Cost 문제를 풀었고, Algorithms에 Dynamic Programming 카테고리에 있는 문제다.

Hexo blog source(.md) 파일도 git으로 관리할 수 있을까?

Hexo로 블로그 시작한 지 4일 째. 이것저것 해보고 Tistory 글도 하나씩 옮겨오다 보니 작성하는 포스트 원글 자체도 git으로 관리하고 싶어졌다. Hexo를 써보면 알겠지만, hexo deploy 하면 public 디렉토리에 생성된 정적 파일들(html)만 github으로 올려진다. 그래서 문득 포스트 원본은 내 컴퓨터에서 날리면 답이 없는건가? 싶은 생각이 든 것.

블로그를 github으로 옮겨볼까, 하고 생각한 지 좀 되었다. 원래 Tistory를 쓰고 있었는데 Markdown을 지원하지 않는 것이 영 불편했기 때문이다. 그냥 가볍게 토막글도 쓰고 싶었는데 Tistory에 글 쓸 생각하면 부수적인 작업들 때문에 점점 더 손이 안 갔다. 그래서 머나먼 길을 돌아 결국 이렇게 새로 블로그를 내었다. 사실 어제까지만 해도 Tistory 백업이 되는 줄 알고 무작정 옮긴건데 작년 말부터 안된다네…^^… 망했다. 뭐 어쨌든 원래 올렸던 글들도 다 Markdown으로 작성했던 거였고, 대부분은 가지고 있으니 앞으로 천천히 올리든 뭐, 하지. 이미 날짜 테스트도 끝냈다! 그냥 날짜만 오래전 날짜를 써도 잘 반영이 되더군! 나중에 옛날 글을 반영하고 이 글을 보면 약간 이상한 모양새가 되긴 하겠다.

JUnit Rules - System-Rules

요즘 Scala test code를 열심히 작성하는 중이다. 당연히 ScalaTest 사이트를 뻔질나게 드나드는 중인데, 본래 Scala와도 그다지 친하지 않았는데 ScalaTest는 당연히 낯선 친구라서 어려워 하고 있다. 오늘 회사에서 누군가가 남겨놓고 떠난 코드에 얄팍하게나마 테스트 코드를 작성하던 중에 코드 내에 System.getenv를 호출하는 부분이 있다는 걸 알았고, 테스트만을 위해 로컬에 환경변수를 설정하기엔 몹시 애매한 상황이어서 아니 이걸 어떻게 하지??? 하다가 JUnit rules형태의 System-Rules라는 library가 있다는 걸 알게 되었다. 들어가보면 알겠지만 java.lang.System을 사용하는 테스트 코드를 지원하는 JUnit rules라고 보면 될 것 같다. 여러가지 System관련 rule이 있는데 환경변수를 이용할 수 있는 rule 사용법은 다음과 같다.

this

내가 좋아하는 The Zen of Python 이 나옴 *_*

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

>>> import this
The Zen of Python, by Tim Peters

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!

Upper Bounded Wildcards

변수에 대한 제한을 좀 느슨하게 하기 위해 upper bounded wildcard를 사용할 수 있다. 예를 들어, List<Integer>, List<Double>, 그리고 List<Number>를 다루는 메소드를 작성하고 싶다고 해보자; 이건 upper bounded wildcard를 이용해 작성할 수 있다.

React’s diff algorithm 글을 보고 번역 말 옮기기
영어 공부 할 셈 시작했는데 중간에 내팽개쳐 놨다가 이제서야 겨우 ㅜㅜ
영어 공부해야 겠다는 사실과 번역엔 영어+한국어 실력이 같이 필요하다는 사실만 깨달음.

회사에서 Kafka를 사용해볼 일이 생겨서 설치를 했다. 윈도우 설치 방법도 쉽게 검색할 수 있었고, 제대로 설치했는데 cmd에서 실행하려고만 하면

1

실행시 지정된 경로를 찾을 수 없습니다.