달력

8

« 2019/8 »

  •  
  •  
  •  
  •  
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
2019.06.16 18:42

새로운 Text.Json APIs 공부하는 것2019.06.16 18:42

며칠전에 VS 2019의 새로운 뉴스 채널에 올라온 기사가 있었다.

새로운 "Try the new System.Text.Json APIs" 라는 제목의 뉴스였는데, 링크를 따라서 들어가면, System.Text.Json APIs라는 블로그의 제목을 마주하게 된다.

 

[.Net Blog]

 

이전에도 "이상하다"라고 생각하기도 하였는데,

왜? .Net에서는 공식적인 라이브러리와 API로 "JSON"을 지원하지 않는가? 라는 질문을 최근까지 해왔었다. 

왜냐하면, Web과 Mobile에서 기본적인 API 통신 프로토콜로는 JSON은 이전의 XML의 위상을 이미 넘어섰기도 하였지만, HttpClient와 같은 라이브러리는 다른 서버로 부터 Data를 받아서 처리하기 위해서 또 다른 라이브러리를 찾아서 설치하여야 하는 불편함이 있었기 때문이다.

물론 JSON.Net 이라는 걸출한 라이브러자가 있기 때문일수 있지만, 이는 MS도 Open 소스화된 표준화된 라이브러리도 아니기 때문에, 매번 Newtonsoft에서 만든 이 라이브러리를 이용할 때마다 드는 생각은 "도대체 무슨 이유 때문일까?" 라는 질문이었다.

 

"Newtonsoft"에서 개발되어서 사용했던 JSon.Net 라이브러리는 이전기 XML 기반으로 Serialize와 Desirialize를 처리해 주던 기능에서 JSON으로 영역을 확대하였다. 

Object와 Array를 잘 처리해 주기도 하였지만, 빠른 속도와 JSON Path 지원과 같은 많은 기는을 제공하는 것이 정점이었고, LINQ에 대한 지원 또한 잘 해 주었다.

 

그런데, 늦었지만 이제라도 .Net Core 3.0에 포함된다고 하니, 다운로드 하는 번거러움은 한가지 줄어들것 같지만, 아직은 .Net Core 3.0 Preview6이기 때문에 공식적인 사용은 조금만 더 기다려야 할 것 같다.

 

새로운 System.Text.Json은 성능적인 면에서 JSON.net과 유사하면, 여지것 잘 사용하여 왔더 "JSon.Net"과의 Dependency를 줄여주는 방향으로 개발이 되고 있다.

 

위 링크에 있는 Blog를 보면, 어떻게 사용하는지에 대한 동영상 가이드와 셈플 코드가 있다

 

가장 기본적인 사용법은 아래와 같이 선언을 하고 Serialization을 사용하면 된다.

using System.Text.Json;
using System.Text.Json.Serialization;

이외의 몇가지 사용예들이 있는데, 아직 정식버전은 아니지만, 거의 바뀌지는 않을 것이다. 참고만 하면 될듯...

 

성능에 대해서도 JSon.Net과도 별 차이가 없다. (아래 참고)

 

JSON deserialization (input)

Description RPS CPU(%) Memory(MB)
Newtonsoft.Json – 500 B 136,435 95 172
System.Text.Json – 500 B 167,861 94 169
Newtonsoft.Json – 2.4 KB 97,137 97 174
System.Text.Json – 2.4 KB 132,026 96 169
Newtonsoft.Json – 40 KB 7,712 88 212
System.Text.Json – 40 KB 16,625 96 193

 

JSON serialization (output)

Description RPS CPU(%) Memory(MB)
Newtonsoft.Json – 500 B 120,273 94 174
System.Text.Json – 500 B 145,631 94 173
Newtonsoft.Json – 8 KB 35,408 98 187
System.Text.Json – 8 KB 56,424 97 184
Newtonsoft.Json – 40 KB 8,416 99 202
System.Text.Json – 40 KB 14,848 98 197

 

새로운 "Text.Json"에 대한 API 문서는 다음을 보면된다.

https://docs.microsoft.com/ko-kr/dotnet/api/system.text.json?view=netcore-3.0

'공부하는 것' 카테고리의 다른 글

새로운 Text.Json APIs  (0) 2019.06.16
요즘 내가 공부하는 것  (0) 2019.06.07
Visual Studio Code 1.0 정식 Released  (2) 2016.04.16
알고리듬 성능비교 - Selection Sort  (0) 2016.02.27
Byte and Bit에 대해서...  (0) 2009.10.20
GRails 공부 자료들...  (0) 2009.10.04
Posted by 행복상자
2019.06.07 19:55

요즘 내가 공부하는 것 공부하는 것2019.06.07 19:55

몇 개월 전에 Visual Studio 2019가 새로이 나왔다.

몇 개월 전에 나오기는 했지만, Beta 버전도 개인적으로 사용하면서 VS 2017과 비교해보려고 했으나, 이전에 만들어 놓은 Application을 고치거나 개선할 일이 없어서, 현 상태를 유지가 전부였다.

 

요즘은 Windows Application이나 프로그램을 개발하는 사람을 주변에서 찾기가 어렵다.

내가 알고 있던 개발자분들은 벌써 오래전에 JAVA나 서버 개발자로 전환하거나 다른 길을 찾아서 일을 하고 있다.

 

회사에서도 10년 전에는 조직내에서 Server 개발자가 단지 4명 밖에 없고, 외주와 협력업체를 통해서 프로젝트를 진행하는 경우가 많았다. 10년도에는 iOS와 안드로이드로 전향한 개발자들이 많았었는데, 지금은 그 쪽 분야도 거의 Red Ocean이다. 하지만 정말 Red Ocean은 Windows 환경에서 개발하는 분야쪽이 아닐까라는 생각이 든다.

 

Windows Phone은 이미 사업적으로 실패한지 오래되어서, Windows Phone을 위한 개발 환경은 의미가 없어진지 이미 오래 되었다.

 

MS는 이미 오래전에 Cloud로 방향을 선회하고, 개발자들을 잘 지원하기 위한 툴들을 제공하는데 많은 노력을 해오고 있다. 이미 내가 가장 많이 사용하는 툴은 Visual Studion Code이다. Ultra editor를 사용한지는 오래되었지만, 요즘은 큰 파일을 열어볼때 가끔 한번씩 사용하고, VS Code를 매일같이 사용하고 있다. 

가볍고, 기능 지원이 정말 빠르고, 윈도우 환경과 Mac에서도 지원을 한다라는 장점이 크다.

 

VS 2019가 나오고 별다른 차이점을 느끼고 있지 않았다.

VS 2017은 이전에 사용하던 VB에 대한 추억을 잊지 못해서, 개발 환경을 지원하기 위한 간단한 Rest API를 호출하고 테스트 할 수 있는 툴을 만들었었다. (사실, Java console 버전, nodejs로 만든 Web버전 등이 있다.)

그런데 Window 10환경의 지원을 위해서 UWP나 WPF가 필요해 보였기 때문에, 이 둘을 살펴보면서 XAML에 대해서 보고, 테스트 해보고 있는 중이다.

 

사실 XAML을 이용하는 UWP와 WPF가 WinForm 환경보다 좋다라고는 이야기 못하겠다.

기본적으로 HTML의 느낌이 물씬 나는데, 개발을 더 쉬게 만들어 준다고는 이야기 하기 어렵기 때문이다. 

다른 의미의 직관을 주기도 하지만, 익숙하던 기능을 사용하지 않고 새로이 익혀야하기 때문인지 낯설기도 하지만 생각되로 UI가 만들어 지지 않기 때문이다.

 

기존에 WinForm에서는 바로 되던 것이 안되는 것이 혼란스럽기도 하지만, 배우는 과정이기 때문에 계속 시행착오가 필요하다라고 생각한다.

 

그런데, 불편하다고 생각하는 것은 나만의 생각일까?

정말 Designer가 UI를 만들어 줄까?

 

UI에 Style을 넣고 고급진 UX를 만드는 것에는 필요해 보이기는 한데, 간단한 툴을 만들어 사용하려는 개발자에게는 너무 과하지 않나 생각이 든다. 

반응형 UI를 UWP에서 제공한다고 하는데, 웹의 그것에 비해서 얼마나 많이 사용할지는 모르겠다.

 

오늘도 짬짬히 Layer를 나누고, Split과 그리드로 화면을 나누어서 그리면서 생각나는대로 글은 남겨본다.

'공부하는 것' 카테고리의 다른 글

새로운 Text.Json APIs  (0) 2019.06.16
요즘 내가 공부하는 것  (0) 2019.06.07
Visual Studio Code 1.0 정식 Released  (2) 2016.04.16
알고리듬 성능비교 - Selection Sort  (0) 2016.02.27
Byte and Bit에 대해서...  (0) 2009.10.20
GRails 공부 자료들...  (0) 2009.10.04
Posted by 행복상자

2019년도가 되면서 새롭게 VS Code의 업데이트된 주요 기능들이다.




"No reload on extension install " 이 기능은 이전에 Extention Plugin을 설치하거나 업데이트 할때마다, 다시 Plugin을 로드해주어야 했었는데, 이번에 개선되어서, 설치 또는 업데이트만 하면 자동으로 리로드가 된다.

알렴서 사용하기 때문에 조금 불편하다고 생각했었는데, 이번 1.31버전에서 개선되었다.


"Main menu updates"는 새롭게 "Go(이동)" 메뉴가 추가 되어서 파일또는 패널의 이동을 도와줄수 있도록 기능들을 모았다. 이전에는 줄간 이동을 위해서 "Ctrl-G"만 사용하였는데, 유사한 기능들이 추가 되었다.


그리고, VS Code에서 사용하고 있던 nodejs ver 8.9는 nodejs ver 10.2 로 업데이트 되었다.

 

Realtime으로  IDE의 색상 테마를 변경할수 있는 기능도 추가 되었는데, 색상은 Dark테마로만 사용하고 있어서 잘 사용할 것 같지는 않다. 그외에 IDE사용에 추가된 가능들은 사용하면서 필요할때 다시 볼 생각이다.


Posted by 행복상자



스프링프레임워크를 사용해서 Restful API를 개발할때, RequestHeader 정보를 가져오는 방법이다.

요즈음에 대세가된 SpringBoot를 이용할 경우에 다른 설정은 크게 필요하지는 않다.

 

"@RestController"를 이용하여, 컨트롤러를 선언해주고, "@GetMapping" 어노테이션을 이용하여, "http://localhost:8080/headerinfo" 라고 호출하였을때, 실행되도로 정의했다. 이때 호출되는 RequestHeader값은 "@RequestHeader" 어노테이션을이용하여 "headers"라는 변수를 통해서 넘겨받을 수 있다.

package net.happyzoo.happzoo;

import lombok.extern.slf4j.Slf4j;
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.http.HttpHeaders;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RequestHeader;
import org.springframework.web.bind.annotation.RestController;
import reactor.core.publisher.Mono;

import java.util.Map;

@SpringBootApplication
@Slf4j
public class HappzooApplication {

@RestController
public static class GetControllerPractice
{
@GetMapping("/headerinfo")
Mono<Map<String, String>> getHeaderInfo(@RequestHeader HttpHeaders headers)
{
log.info(headers.toSingleValueMap().toString());

return Mono.just(headers.toSingleValueMap());
}

}


public static void main(String[] args) {
SpringApplication.run(HappzooApplication.class, args);
}

}

위는 Sample 코드이며, Lombok을 이용하여 @Slf4j를 선언해주면, 로그를 남길수 있도록 했는데, Lombok를 사용하지않으면, 선언에서 제외하면 된다.


실행 결과는 다음과 같이 Map의 형태로 반환해서 Mono로 전달하면 Client에서 결과값을 받을수 있다.

return Mono.just(headers.toSingleValueMap());


Terminal에서는 

  curl -X GET http://localhost:8080/headerinfo

와 같이 명령을 실행해서 호출하거나, Chrome 브라우져에서 실행해보면 확인할 수 있다.

IntelliJ에 내장된 Rest Client를 이용해서 호출한 결과이다. Json의 Object형태로 결과를 받아왔다.




Posted by 행복상자

나는 SF영화를 좋아한다. 

현실적이지 않기 때문에 상상력을 동원할수 있어서이기도 하고, 미래의 모습을 영화를 통해서 예측할 수 있어서 이기도 하다. 누군가의 상상을 또는 예측을 스크린을 통해서 이해할수 있어서 이기도 하다.

 

"트랜스포머"가 2007년도에 한국에 개봉을 하면서, 어렸을때 보았던 로봇 애니메이션과 만화속의 이미지를 그대로 스크린을 통해서 보게되었다. 이는 로봇영화에 대한 소년기 남자들 로망을 어른이 되어 있는 나에게 충족시켜 주었었다.

상상을 통해 그려보던 모습을 마치 살아 있는양 스크린 속의 변신 로봇의 모습은 거침없이 뛰어다녔었다. 


근래 10년동안에서 가끔씩 나오는 "트랜스포머" 시리즈는 처음의 감동은 아닐지라도, 향수와 추억을 머금고 있어서인지, 시리즈가 나올때마다 만나야 되는 영화가 되었다. 그러나, 새로운 이야기가 영화로 나올때마다, 스케일과 물량은 커졌지만, 이야기 측면에서는 커다란 감흥을 주지는 못해왔다. 상업적인 영화이기 때문이지만, 다음 영화에 대한 기대감이 점차 사라졌기 때문에 시리즈에 대한 위기감이 컸다.


지난주에 보았던 범블비는 이전에 보았던 트랜스포먼와는 다른 형식의 영화이다. 트랜스포머의 "프리퀄"이라고 이야기 하고 싶지는 않다. 이야기의 처음은 전쟁중에 지구로 오게된 "범블비"의 여정의 과정을 보여주지만, 트랜스포머의 기원과 오토봇과 디셉티콘의 전쟁에 대한 오랜 이야기의 시작을 말해주지는 않는다. 


80년대를 살아본 사람에게는 추억과 이야기 거리를 줄 수 있는 영화이다.




"범블비"는 한소녀와의 우연한 만남을 통해서 서로 자극 받고 성장하는 성장 드라마와 같았다. 

이전에는 동물 또는 다른 사람과의 만남을 통해서, 다른 사람 또는 매개체를 통해서 갈등과 트라우마를 극복하는 영화들이 많았기에, 이야기의 플롯은 너무나도 심플하기만 하다.


갈등의 관계도 가족간의 이해를 바탕으로 한꺼플씩 오해를 벗으면서, 어느덧 이야기는 마무리가 된다.

그리고, 새로운 이야기의 시작을 알리면서 영화는 종료된다.


선과 악의 관계도 명확하고, 아군과 적국의 관계도 명확하게 보여주어서, 이전의 "트랜스포머"의 복잡해지 상호관계를 단순하게 만들어 주었다. 이러한 단순한 관계는 "범블비"를 "트랜스포머" 시리즈중에도 역대급으로 만들어 주었다.





Posted by 행복상자