simple ONLINE relationship database design tool

http://aquerytool.com/aquerymain/index/

관계형 데이터베이스 디자인툴 괜찮은 것은 역시 erwin일것이다.
윈도우용이고 비싸다는 점만 제외하면.

db 설계할때 일반적으로는 복잡한 기능을 사용하지 않고
구조도(?)와 DDL 생성 기능을 주로 사용한다고 하면
위 사이트는 매우 좋은 선택이 될 것이다.

ormlite 첫인상

바쁘다는 핑계로 ORM 책 페이지가 넘어가지 않고 있었다.

그러다가 새로운 프로젝트를 하나 만들게 생겼는데,

android에서 local db를 사용해야 할 일이 생겼다.

해본 사람들이라면 알겠지만

...저거 테이블 또... 하다가 신음소리가 절로 나오는 그런 순간이 아닐 수 없다.

그냥 막 하기 싫고, 누가 좀 대신 타이핑 해줬으면 싶은 마음이 굴뚝같고,

그런 일이 일어날리는 없고.

그래서 검색잠시 해본 결과 ormlite가 android도 지원한다는게 아닌가.

나무 위에 올라가 있는데 하늘에서 동아줄이 내려온 기분이 이럴까?

몇 챕터 읽지는 못했지만 ormlite로 냅다 달려봤다.

erd로 그려진 테이블과 칼럼들을 바탕으로

model 클래스들을 만들었다.

그리고 어노테이션으로 관계들을 매핑해주고, OrmLiteSqliteOpenHelper를 상속해서 sqliteDatabaseHelper 클래스를 만들어서 onCreate, onUpgrade 메서드를 구현해주면 끝!

테이블 생성은 메서드 단 하나,  TableUtils.createTable()로 끝!

기본적인 CRUD는 문제없었다.

칼럼 join 테스트만 한번 해보면 어쨌거나 android에서 db로 머리 썩힐 일은 이제 없을 것이다!

행복하다.

Thank You, ORM!

Java에서 Unchecked cast warning 제거하기

Map<String, Object>을 이용해서 여러 개의 ArrayList<MyObject>들을 넘겨주게 된 경우가 있었다.

지금 다시 작업한다면 그럴 여지를 만들지 않겠지만,
value = map.get(key) 같은 형태로 map의 value를 가져오면 Unchecked cast warning이 발생한다.

@SuppressWarnings("unchecked")를 추가해주면 warning은 무시되지만
뭔가 찝찝하다고 생각되면 번거롭지만 다음과 같이 하면 된다.

java스럽게 복잡한데 속은 시원하다.

android logcat 필터링하기 - 원치 않는 로그 제거하기

logcat 로그 메시지를 원하는 것만 추려보려면?
정규식을 이용해야 한다.

Android Studio에서 logcat - Edit Filter Configuration을 실행하자.

Log Tag, Log Message, Package Name은 정규식을 적용할 수 있는데,

Log Tag에서 dalvikvm이 뿌리는 로그를 제거해보자.

^(?!(dalvikvm))

다른 것들을 추가하려면 아래와 같이 적용할 수 있다.

유틸리티 클래스 대신 객채지향!

객체지향에 대해 다시 한번 생각을 해보게 되었다.

데이터는 없고,
객체와 행위만 있다는 말이 의미 심장하다.

트위터의 2015 3/4 분기 적자 소식을 보며

http://www.businesspost.co.kr/news/articleView.html?idxno=18963

트위터가 3/4분기도 적자를 냈다고 한다.

트위터 서비스 자체는 사용하고 있지 않지만, 트위터의 영향을 직/간접적으로 받고 있는 개발자인 이상 트위터가 좀 지속적으로 버텨줬으면 좋겠다.

fabric.io로 묶여 있는 crashlytic이라든지, answer, beta 등과 같은 서비스들은 너무 유용하다.

... 뭐 좋은 서비스들인 만큼 하루아침에 사라지기 보다는 어디론가 인수되어 버리겠지만.

clojure 첫인상

언어의 표현력이 좋다,
간결하다,
타입추론한다,
함수형이다... 이런것들은 2차원적인 문제라는 것을 다시금 느꼈다.

요컨대 언어는 도구일뿐 구현보다 설계, 결국 아키텍처가 더 중요하다는 것이다.

어떤 로직을 구현하는데 있어서
특정 언어로 한계가 있는데 다른 언어로 쉽게 할 수 있다면
그때 사용하는 것이 이상적으로 보인다.

어떤 언어를 쓰더라도 Persistance Layer가 없을 수 없고
Presentation Layer가 없을 수 없다.

물론 이리저리 type casting 하다보면
이게 뭐하는 짓인가 하는 생각이 들기도 하지만
그건 어디까지나 domain class modeling이 잘못되었다는 의미이지
type casting을 생략할 수 있다고 해서
생산성이 비약적으로 높아지는 결과로 이어질 거 같지는 않다.

clojure에 대해 더 공부하기보다는 같은 시간을 orm에 대해 공부하는 데 사용하게 될 것 같다.