Category Archives: Language

Groovy를 터미널 스크립트로 사용하기

개인적으로 Groovy의 문법이 맘에들어서 Java 프로젝트에서 유닛테스트를 할 때라던가 많이 사용하는데
(Kotlin 프로젝트에는 보통 코틀린을 사용…)

새로운 기능을 몇 가지 발견해서 연동테스트의 스크립트 언어로 사용하려고 찾아봤다.

groovy의 grapes(@Grap)을 사용하면 개별 파일에서 의존성 관리가 된다던가
스크립트 언어로 쓸 수 있는 기능을 많이 만들어놓은 것 같다.

그런데 몇가지 실망한 포인트가…

  • Groovy 파일간에 import가 되지 않는다던가
  • @Grapes를 파일에 선언 해 놨는데 이걸 자동으로 임포트를 하지 않는 문제…
  • 클래스패스 설정을 할 때 jar파일을 사용해야하는 문제

그럼 … 못쓰겠군.

연동테스트 스크립트는 파이선이나 노드로 해야겠다.

그루비의 용도는

딱.

JVM에서 다이내믹하게 로딩해서 쓸 수 있는 스크립트 언어. 태생이 그렇기도 하고…
DSL형태를 만들기 쉽고


node.ts로 애플리케이션 만들기

과학상자로 자동차를 만들면 안되는거시야

꽤나 잘 굴러가긴 하겠지만 말이야…

enum

아예 없으면 없나보다 할텐데 어설프게 있는게 더 극혐이다.

export enum ArticleEnum {
  ADOC, MD,
}

export class ArticleConstant {
  static readonly ADOC = 'ADOC'
  static readonly MD = 'MD'
}

export type ArticleType = 'ADOC' | 'MD'

export default ArticleType

괜찮은 구조인지는 모르겠지만 대략 이렇게 처리를 해 버렸다.
단순히 enum을 이용해서 ===비교를 하면
class 안의 article: ArticleEnum은 ADOC ArticleEnum.ADOC는 0이라는 값이 나온다
0나오는건 당연한거긴한데
비교하면 0이랑 비교하는것처럼 다 false가 나온다.

취소. 이상하다.. 비교가 잘 된다.
전에 이런종류의 에러를 본 것 같은데
error TS2365: Operator ‘===’ cannot be applied to types 

메모리 공유

브라우저단에서 클라이언트 프로그램을 만들 때는 큰 문제가 되지 않던 부분인 쓰레드 관련 부분도 …
노드를 빠르게 해 주는 장점이기도 하지만 단점이기도 한 이 부분…
메모리를 공유해야 할 일이 있을 때 IPC또는 클러스터링 수준의 아키텍처를 만들어내야한다.

노드의 빠른 속도의 근본 이유이기도 하다.
그래서 간단한 형태로 많은 리퀘스트를 받는 애플리케이션을 만들때는 유용할 것 같다.

익셉션 처리

좀만 잘못하면 자꾸 뒈져버리니…
언어의 문제라기보다는 적절한 프레임웤이 없는게 문제라고 해야할 것 같다.

표준형태 없는 코드의 문제

이건 타입스크립트의 문제이긴 하지만

import winston from 'winston'
import * as winston from 'winston'

이 두개가 뭐가 다를까…
namespace가 선언되어 있는 경우
class가 선언되어 있는 경우
default export가 선언되어 있는 경우에 따라 임포트 방식이 달라져야한다.

소스코드를 봐야된다. ide를 좋은거 써야겠지…도큐먼트는 제대로 안나온게 많으니까
표준없는 코드는 여기저기서 문제를 일으킨다. 프로젝트가 커질수록 문제도 커지겠고…

장난감으로는 장난감만 만들자

노드 백엔드는 토이프로젝트까지만 사용하는걸로

프로토타이핑으로는 괜찮은 것 같다.

처음 배우기가 쉽다고 하지만 스프링에서 쓰던만큼 셋팅을 하려고 하니까 이것도 시간이 만만찮게 걸리는건 별 수 없는 것 같다.

잘 갖춰진걸로 쉽게 만들려면 RoR이 좋겠고
노드는 진짜 개판으로 짜기만 좋다. 이것저것 갖추려면 시간은 어차피 그만큼 걸린다.

Go 언어 사용 감상 – Generic이 없다는 것…

새로운 언어를 공부할 때 언어별 특성에 따라 다른 접근방법을 사용해야한다.
요즘은 Go언어로 뭘좀 해 보려고 했는데…

언어의 특성 때문에 yaml의 설계마저도 달라져야 한다는 것을 알게 됐다.
(내가 너무 자바스타일로 구조를 잡는건지도 모르겠다

간단한 빌드 툴을 만들면서 아래와 같은 형태의 제네릭 리스트를 yaml로 만들었는데

  • DockerWork
    • Dockerimage
    • Dockerrepo
    • Dockerfile

당연하다는 듯이 제네릭?오브젝트리스트? 형태로 만들어 버렸다.
Go언어를 잘 못해서 그런것일 수도 있는데 뭔가 만들기가 난감하다.
제네릭이 필요했는데 Go언어에는 그게 없었다.
커뮤니티 검색도 좀 해봤는데 generic 지원을 요청하는 이슈가 많았지만
고언어에는 그게 필요없다~ 라는 의견으로 마무리

강타입에 정적타입이면서 generic이 없다니…

위의 문제를 해결할 때
자바 – 제네릭,
파이썬 – 오브젝트리스트
C언어 – !!노개다
Go언어 – !!노가다
아마 다른언어는 다 비슷한 스타일일거다.

Go언어는 C언어에 가까운 해결방법을 찾으라는 것 같다.
python처럼 is type체크를 하고 형변환 없이 사용할 수 있다면 또 모르겠는데..
그게 아니니 더 난감하다.

뭔가 편하고 깔끔한 방법이 있는데 못 찾는건지.. 아마 없을 것 같다.
덕타이핑과 인터페이스 ifelse 떡칠이 답일 것 같다.

말 나온김에 덕타이핑도…
Duck typeing 덕분에 발생하는 복잡함

다음과 같은 코드가 있다면

type Writer interface {
Write(p []byte) (n int, err error)
}


자바할 때 처럼 이 인터페이스의 이름을 찾는다면?
나올수도 있고 안 나올수도 있다.

덕타이핑이라고

구현체 사이에 의존관계가 없기 때문에 레퍼런스 검색이 힘들다
동일한 패턴의 인터페이스를 몽땅 검색해야 되는데
자바 개발을 하던 습관이 남아서 그런지 좀 난감하다.

장점일 수도 있고.. 단점일 수도 있는 이 부분..
상속이 없는 것도 덕타이핑의 일부 특성이라고 봐야할 것 같다

기본 문법도 쉽고 간단한 코드를 만들기도 쉽지만
언어 자체가 쉽다?? 글쎄….
데이터 구조를 다루기 힘든 언어인지 익숙해지지 않아서인지…

고 언어 후기

  • 간단한 코드를 짜기는 쉬울 것 같다.
  • 실행 속도가 빠르다? 글쎄…
  • 실행파일을 만들어서 설치하기 쉽다

[도서] RxJava를 활용한 리액티브 프로그래밍

왜?

보통은 개발을 하다가 필요하다고 생각되는 기능을 검색하거나
기술블로그를 보면서 재밌어 보이거나 필요해 보이는 것들을 찾아서 공부하는데
RxJava는 별로 필요성이 안 느껴져서 관심을 갖지 않았다.

그냥 Reactive 프로그래밍을 가능하게 해주는 프레임워크?로
GUI프로그래밍 할 때나 사용하겠지 … 하고 말았었다.
개인적으로는 웹개발을 하면서는 쓰레드나 Callback 지옥을 경험해본 일이 없어서..
여러 시스템에 연동하는 복잡한 서비스를 만드는 경우에는 사용하면 좋으려나

— 좀 다른 얘기지만 저번에 어느 회사 면접볼 때 Observer Pattern 얘기가 나왔을 때 눈똥그래져서 물어보시던데.. RxJava를 아는지 체크 해 본려고 했던건가

키워드 및 요약정보

자바와 안드로이드를 위한 리액티브 프로그래밍 구현체
함수형 프로그래밍의 영향
비동기 이벤트 기반 프로그램 – 스트림 방식
서버에도 적용

Rx(ReactiveExtension) 함수형프로그래밍에 영향을 받았지만 FRP(Functinoal Reactive Programming)은 아니다.
Observable/Observer<T>
Producer
Subscription/Subscriber<T>


포기.. 무슨 클래스 메서드 하나하나 다 설명을 해놨는데
안그래도 텍스트로 소스보면 몇배나 더 걸리는데 하나하나 보려면 한달은 걸리겠다.
그래서
1~2단원 앞쪽 개념설명과 인덱스만 훑어보고 넘어간다.
중요한 부분만 뽑아서 보고싶은데 편집이 불친절해서 골라먹기도 힘들게 돼 있다.
아예 필요없는 책이라고는 못하겠는데 좀 어려운 것 같다.
RxJava Getting Started같은 문서나 보고 그냥 쓰다가
필요성이 느껴질 때 다시 봐야겠다.

Kotlin in Action : 코틀린 컴파일러 개발자가 직접 알려주는 코틀린 언어 핵심

이 책은 좀 마음에 든다. 그래도 돈이 없어서 사진 않겠다.

개념설명과 예시가 잘 나와있고 번역도 걸리는거 없이 자연스럽게 읽힌다.
책의 수준은 자바를 어느정도 알아야 제대로 볼 수 있을 것 같다.
람다까지는 어느정도 할 줄 알아야…

본인쨩은 자바도 할 줄 알고 코틀린도 튜토리얼보면서 대강 익힌 후에 책을 봐서 좀 더 편하게 본것같기도 하다.

자바 특징

자바를 소개하는 책에는 자바가 간결하고 쉽다고 했지만… 그건 C,C++하던 사람들 얘기고
본인쨩은 C#을 먼저 하고 자바를 시작해서 그런지
처음에 자바 문법 극혐스러웠다. 

코틀린 써본 느낌

코틀린은 완성된 자바같다.
자바의 혐오스러운 부분을 배제해서 간결하고 직관적이다.

자바와의 호환성을 유지하기 위해 많은 부분을 희생한 것 같다.
자바코드 가져올 때 null타입 체크를 포기한거나 …
그런거나…또 뭐가 있더라
패키지 구조에서 인터널 스코프, sealed도 뭔가 문제가 있었던 것같은데, immutableCollection이 바이트코드에선 퍼블릭이라거나

몇 가지 문제 때문에 코틀린에서 만든 라이브러리를 자바에서 쓰면 좀 불편할 것 같다.

자바도 8에서 람다, 9에서 모듈을 적용하면서 열심히 따라오고는 있는데
자바19정도 되면 코틀린처럼 변하지 않을까

no-java kotlin 버전???

레거시 지원도 좋지만 가끔은 과감하게 포기하면서 발전 해 가면 좋겠다.

[도서] 해커와 화가 – 비아웹?? 창업자의 글 모음

비아웹.. 야후에 팔렸다는데 잘 모르겠다.
비싸게 팔렸겠지?

성공한 벤처기업인이라 그런지… 아니면 이런 사람이라 성공한 사업가가 될 수 있었던건지.. 
경제인의 시야를 가지고 있다. 공돌이가 아닌

근원적인 가치를 부로 정의하고 영어로는 wealth라고 썼을래나..
money,화폐,돈과 구분해서 생각할 줄 아는

나는 에너지와 혁신을 경제발전의 근원?으로 보고 있었는데 나만 그런건 아니었나 싶다.
미국에는 이런 생각을 가진 사람이 많은건가

리습

  1. 조건문conditional – if then else
  2. 함수의 타입function type – 함수도 변수처럼 타입
  3. 재귀 recursion
  4. 동적 타이핑 dynamic typing – 모든변수는 궁극적으로 포인터, 변수가 아니라 값, 변수 할당은포인터 자체를 복사
  5. 가비지 컬렉션 garbage collection
  6. 표현으로 이루어진 프로그램 
  7. 심볼 타입 symbol type – 문자열을 가리키는 포인터
  8. 심볼과 상수의 트리를 이용하는 코드를 위한 표기 방식 notation 
  9. 언어 전체를 계속 사용할 수 있음 – 읽는시간, 컴파일하는시간, 실행시간에 대한 구분이 없어서 동시에 실행 가능

매크로.. 뭔지 이해가..

리습존니짱. 개좋아.

lisp계열 clojure는 몇번이나 도전을 했는데… 중도포기의 연속..

요즘 시간을 내서 작은 모듈이라도 만들어보려고 하는데 잘 될까?