.NET Core RC2 to RTM 마이그레이션

존나 쉽다. 걍 날 따라해라. 공통사항이다.

project.json 파일 아래 부분 수정

{ //...
    "Microsoft.NETCore.App": "1.0.0"
}

위 부분을 아래처럼 수정.

{ //...
    "Microsoft.NETCore.App": {
        "version": "1.0.0",
        "type": "platform"
    },
}

(만약 위처럼 안써있는 사용자 한정.)

그리고 다시 project.json 에서 모든 패키지 버전을 1.0.0-rc2-final 에서 1.0.0 로 수정.
대상: Microsoft.AspNetCore.*Microsoft.Extensions.* 여튼 저런 식으로 써있는 패키지 다.

비주얼 스튜디오 2015 사용자라면 닥치고 아래 절차에 따르면 된다.

  • Update 3 로 업데이트.
  • Tools Preview 2 설치. (뻘짓만 안하면 이전버전 언인스톨 안해도 됨)
  • .NET Core RC2 프로젝트 연다.
  • 프로젝트 컨텍스트 메뉴에서 Nuget 패키지 관리… 클릭.
  • 업데이트 탭 클릭.
  • 닥치고 모두 체크하고 업데이트 버튼 클릭.
  • 안심하고 화장실 갔다와.

끗. 이제 dotnet run 치고 ENTER 치면 언제 한듯 안한듯 깔끔하게 앱이 실행될 것이다.

composite / 2016년 6월 28일 / Piss Development / 0 Comments

.NET Core 1.0 RC2 to 1.0 RTM Migration

yeah, that’s quiet simple.

project.json

{ //...
    "Microsoft.NETCore.App": "1.0.0"
}

to,

{ //...
    "Microsoft.NETCore.App": {
        "version": "1.0.0",
        "type": "platform"
    },
}

and, change all ASP.NET and Core package version 1.0.0-rc2-final to 1.0.0.
affects: Microsoft.AspNetCore.* and Microsoft.Extensions.* for plain ASP.NET webapps or console app.

If you’re Visual Studio 2015 user, following this step:

  • Update to Update 3.
  • Install Tools Preview 2 (No uninstall required if not tuned.)
  • Open any .NET Core RC2 Project.
  • Click Manage NuGet packges... on project context menu.
  • click Updates Tab.
  • Check all and click Update.
  • have a tea time.

that’s all. just dotnet run and ENTER. hooray~

composite / 2016년 6월 28일 / Piss Development / 0 Comments

.NET Core RC2 Tools preview 1 Offline Installer

전에 비주얼 스튜디오 도구를 RC1에서 R2로 올리는 삽질기를 올렸었다.
그리고 RC2는 치사하게 오프라인 설치 파일을 제공하지 않는 것도 알려줬었다.

하지만 오프라인 설치하도록 하는 방법은 있다. 다행히도.
출처는 여기니 영어 좀 알면 정확한 사용법을 익히도록 한다.
아님 걍 날 따라해.

준비물

일반 사용자(또는 귀차니어)
* 비주얼 스튜디오 업데이트 2 (Express 제외한 모든 에디션)
* DotNetCore.1.0.0.RC2-VS2015Tools.Preview1.exe

고급 사용자
* 7집이나 반디집 등 CAB 파일 보거나 풀 수 있는 압축 프로그램 아무거나.

일반 사용자

  1. 받으라는 준비물을 받았으면 적당한 폴더에 옮긴다. 아님 말고.
  2. 설치 파일이 있는 폴더에 packages 폴더를 만든다.
  3. 설치 파일 목록이 든 텍스트 파일을 받아 packages 폴더에 놓는다.
  4. 목록을 urls.txt 등 편한 파일로 저장한다.
  5. packages 폴더에 powershell Get-Content urls.txt | ForEach-Object {Invoke-WebRequest $_ -OutFile $(Split-Path $_ -Leaf)} 스크립트 실행.
  6. 다 받았으면 압축하여 배포하던 공유하던 니맘대로 한다. 참고로 전체 크기는 거의 500MB에 육박한다.

고급 사용자

일반 사용자 2번까지 한 다음 아래 절차를 따른다.

  1. 압축 프로그램으로 설치 파일을 연다.
  2. 0이라는 파일이 있는데 실제 다운로드 설치파일 목록이 있는 XML 파일이다. 그걸 연다.
  3. 아무 에디터 열고 “찾기” 한 다음 정규식 체크하고 DownloadUrl="(.*?)" 입력한다. (Subline Text나 Atom 추천)
  4. 모두 선택 후 거기 나온 모든 URL을 추출한다. (선택하지 말고 다 받아야 한다. 한개라도 빠지면 온라인으로 받으려 나댈 것이다.)
  5. URL 목록을 만들었으면 일반 사용자 4번부터 따르면 된다.

이렇게 하고 압축하여 인터넷이 막힌 환경에서도 ASP.NET Core RC2 개발환경을 설치할 수는 있다.
근데… 문제는 ASP.NET Core 개발하려면 아직 인터넷 없이는 힘들긴 하지만,
나처럼 설치 더럽게 안되는 환경에서는 더없이 좋은 환경이 될 것이다.

아, 사족으로 나는 이것도 실패에서 결국 Github Issue 올렸다. 시발.

2016-06-24 업데이트:
Issue 원인은 DRM으로 인한 리소스 접근 실패. 문서보안이 화근이었다.
결국 포기. 다른컴 테스트해보니 존나게 잘 깔림. 시발 안해.

composite / 2016년 6월 23일 / Piss Development / 0 Comments

대한민국은 블록체인을 “꺼려한다”.

마침 기사가 하나 나와서 글을 싸지르도록 하겠다.
해킹안전지대 블록체인 온두라스도 한다는데…IT강국 한국은 뒷짐만

먼저 블록체인의 기본 원리부터 살피고 본론으로 들어가도록 하겠다.

블록체인

왼쪽이 기존에 사용하는 중앙집중 방식이고, 오른쪽이 블록체인 방식이다.
장부로 치자면, 왼쪽 기존방식은 하나의 중앙에서 장부 하나를 여러 기관에서 관리한다는 것이 되고,
오른쪽은 각자 장부를 가지고 있으면서 장부 갱신 때마다 모든 기관이 각자 장부에 기록하는 방식이 된다.
비트코인이 왜 부정행위가 어려운 지 써본 사람은 알 것이다.
해커가 비트코인 조작을 하려면, 모든 사용자의 장부를 모두 조작해야 한다. 현실적으로 매우 어려운 방법인 것이다.
하지만 기존 방식은 중앙 장부만 조작하면 된다. 히스토리가 남는다 해도, 신뢰도가 떨어진다. 하나만 있기 때문에.
그래서 블록체인이 안전한 이유가 성립되는 것이다.

여기서 본론으로 들어가기 전에 답이 나왔다.
바로 부정행위의 어려움으로 블록체인을 한국에서 꺼려하는 것이다.

아시다시피 한국은 OECD 명실상부 경제 범죄 1위 강국이다.
그렇다고 해서 이를 개선한다고? 윗분들이 주도하는데 왜?

여태까지 50만원짜리 의자를 900만원으로 뻥튀기 하고, 1인당 만원 낙지집을 10명이 갔다고 95만원 계산하는 국회의원이 나라 운영하는데…
보는 눈이 많은 방식인 블록체인을 도입하겠다는 건 부정행위자 입장으로 볼 때는 지옥인 것이다.
이건 내가 사기꾼 로비스트라도 블록체인 무조건 막아낼 것이다.

그렇다. 블록체인 할 의지도 없거니와 어떻게든 막아내는 게 대한민국의 숙명(?)인 것이다.
내 말이 좆시발 부정적인 개소리들로만 가득하다고? 현업 블록체인 기업 사장에게 물어봐라.
한번이라도 국내 블록체인 컨퍼런스 가봐라. 그런 생각 할 이유가 사라질 것이다. 니가 금수저가 아니라면.

composite / 2016년 6월 17일 / Dog's bullshit / 0 Comments

composite / 2016년 6월 10일 / Dog's bullshit / 0 Comments

[딥빡] ASP.NET Core RC1 -> RC2 Tools

ASP.NET Core RC2가 나왔고, 비주얼 스튜디오 도구가 나왔다.
하지만 언제나 그랬듯이 Beta 에서 RC1 로 순탄하게 업그레이드 될 리 없었는데,
그때는 걍 베타 삭제하고 RC1 설치하면 바로 해결됐다.
하지만 RC1 지우려고 했는데 이번엔 뜬금없이 설치 파일을 요구한다.
설치 파일명은 AspNet5.ENU.RC1_Update1_KB3137909.exe 이다.
만약 취소하면 삭제가 취소된다.

마소 이 개생퀴들아!

RC2 나오자마자 파일 지워버렸잖아!

이 파일 어떻게 구해 썅것들아!!!!!

그래서 구글링 했는데 다행히도 쉽게 찾을 수 있었다.
필요한 사람 다운받아라. 그리고 설치하지 마라. 안될 거다.
AspNet5.ENU.RC1_Update1_KB3137909.exe
그리고 삭제 시 파일 요구할때 이 파일을 선택하면 속 시원히 지워질 것이다.

그리고 RC2 설치하면 된다. 속 시원히 설치될 것이다.

만약 파이프니 알 수 없는 오류니 안되는 경우가 있는데,
일단 안타깝게도 오프라인 설치가를 제공하지 않고 있다.
온라인 설치 파일을 다운받고,
다운 폴더를 콘솔 창에 열어
DotNetCore.1.0.0.RC2-VS2015Tools.Preview1.exe /layout
치면 원만하게 설치가 완료된다.
그리고 깔아주시면 된다.
그리고 어디 백업하던지 해서 남겨라. RTM 나오면 삭제할 때 필요하게 될 지도 모른다.

참고(영문)
ASP.NET 5 RC 1 Update 1 Offline Installer

추가 업데이트

나처럼 재수없게 새 프로젝트 생성하거나 웹 프로젝트가 안열릴때
RC1 삭제 시 웹개발 도구가 덩덜아 날아간 경우가 있다.
에휴… 프로그램 및 기능에서 비주얼 스튜디오 변경 클릭 후 웹 개발 도구 체크해주자.

composite / 2016년 5월 27일 / Piss Development / 0 Comments

From node-webkit to Electron 1.0

이 글은 Github 소속 Electron의 메인 개발자인 Cheng Zhao(@zcbenz)의 기고글을 번역한 글이다.
원문: From node-webkit to Electron 1.0
시간에 쫓기고 작성하다 보니 오역이 있을 수 있다. 오역 교정 환영한다.

아니 프리랜서가 시간관리도 못하고 왜 시간에 쫓겨다녀?

한국 프리랜서는 용병이 아니라 그냥 사업자를 빙자한 근로자거든요 ㅋ


이 글을 통해 내가 node-webkit를 재구성하다가 Electron 프로젝트를 시작하게 된 내역을 기고한다. 내역을 좋아하는 애들을 위해 커밋 내역과 관련 링크를 달아주었다.

DOM에서 node.js 모듈 불러오기

모든 것의 시작은 2011년 @rogerwang 이 만든 마법의 모듈 node-webkit이었다.
이 node.js 모듈은 웹킷으로 하나의 브라우저 창을 띄워주는 것도 모자라, node.js 모듈까지 사용하는 마술까지 부렸다.

Node.js 코드 단은 이랬고,

var nwebkit = require('nwebkit')
nwebkit.init({'url' : 'index.html'}, function () {
  nwebkit.context.runScript('')
})

그리고 index.html 내용은 이랬다.

<html><body>
<p id="output"></p>
<script>
require('fs').readdir('.', function (err, files) {
  var result = ''
  files.forEach(function (filename) { result += filename + '<br/>' } )
  document.getElementById('output').innerHTML = result
});
</script>
</body></html>

이 데모로는 아직 시판하기엔 부족한 점이 많았지만, 충분히 성공 가능성이 있었다.

크롬 임베디드 엔진을 사용하다.

그 당시 node-webkit 에서 가장 큰 문제였던 게 있는데, 웹킷 라이브러리 기능을 리눅스 외에 사용하기엔 너무나 버거웠다.
그래서 @rogerwang 은 이 모듈을 웹킷에서 크로미움을 애플리케이션에 넣는 인터페이스를 제공하는 크롬 임베디드 프레임워크로 바꿔 해결했다.

당신은 그 CEF를 사용하여 개발한 node-webkit 코드를 볼 수 있다. node.js 비동기 기능을 수행하도록 만들기 위해, 거기에는 크로미움 메시지를 node.js 입출력 라이브러리인 libuv로 대체하는 패치가 있었다. 그러나 이제 그 패치는 더이상 찾을 수 없었다. 왜냐하면 NW.js 의 Chromium fork 저장소가 이미 오래전에 rebase 해버렸기 때문에. 이제 그 당시 커밋 내역으로 돌아갈 수 없게 됐다.

인턴으로 취직

당신은 @rogerwang 오랫동안 오픈 소스를 지원했던 인텔에 일하고 있다는 사실을 알고 있는가? 놀랍게도 인텔이 오픈소스를 위한 인턴을 구했다. 이보다 더 좋은 인턴쉽이 있었던가?

Intel OTC

2012년 여름, 나는 한참 졸업을 앞둔 대학생이었을 때 여름 인턴쉽을 찾으러 다녔다. 그 때 바로 인텔의 구인란이 눈에 보였는데, 인텔은 node.js의 오픈소스 프로젝트 node-webkit 개발자가 필요하다고 했다. 나는 이때다 싶어서 지원했고 운좋게 붙었다.

그리하여 나는 그 node-webkit 를 개발하기 시작했다.

컨텐트 쉘

첫번째로 내가 했던 업무는 node-webkit의 CEF 브랜치 개선이었다. 그리고 개발하면서 정말 어렵게 해냈다.
node.js가 V8 API를 직접 호출하면서 CEF는 크로미움의 컨텐트 모듈을 입히는 자체 API를 연동한다.
당신이 크로미움과 node.js를 연동하고 싶다면 중간에 CEF를 엮이지 않게 달아야 할 것이다.

그래서 기존 코드를 향상시키는 대신 아예 컨텐트 쉘을 재구성하는 쪽을 택했다. 크로미움을 최소한으로 사용한 가벼운 브라우저를 구현하기 위해.

결과는 꽤 좋았고 node.js 통합이 가능한 작은 브라우저를 획득했다. 그리고 난 그 node-webkit 0.2.1 버전으로 릴리스를 배포했다.

node-webkit를 프레임워크로

node-webkit는 node.js 모듈이기 이전 독립적인 브라우저였었다. 왜 여태까지 이 프레임워크로 HTML과 자바스크립트로 데스크탑 앱을 만들지 않았지? 나는 그 때 몇 개월간 그 아이디어를 행동에 옮겼다.

먼저 나는 node-webkit의 패키징 시스템을 추가했다. 아이디어는 게임 프레임워크인 LÖVE framework 를 슬쩍했다. 그 아이디어는 앱을 ZIP 아카이브로 만들고 node-webkit 실행 파일을 합치면, node-webkit 실행 시 그 아카이브를 풀고 아카이브에 포함된 앱을 실행하는 식이었다.

Packaging node-webkit

몇가지 구현 항목이 있다면, package.json 에 윈도우 속성을 넣거나, DOM 요소 확장, 브라우저 보안 모델 삭제, DOM 요소에 네이티브 파일시스템 도입, 그리고 끝없는 버그 수정 등이다.

한가지 재밌는게 가장 어려운 도전이 있다면 아무래도 node.js 네이티브 모듈 도입이었다. 나는 V8에 OpenSSL을 도입하기 위해 따로 기호(Symbols)를 추가해 크로미움에 패치하고, NSS와 OpenSSL 사이에 충돌이 일어나는 node.js 기호도 수정해 패치했다. 이렇게 윈도우용 원시 코드 node.lib 커스텀 패치를 제공하여 node-webkit에 네이티브 모듈이 돌아가도록 했다.

이리하여 node-webkit v0.2.5 배포 후, 왠지 안정된 느낌을 받았다.

자체 API 추가

이번엔 API 제공하는 데 DOM을 여전히 격리되고 있고, DOM 제공이 너무 제한적인 부분인 현실에 내 생각을 말해본다.
예를 들면 네이티브 메뉴와 여타 텍스트가 들어간 메시지박스 등.

그때 나는 자체 API를 제공하는 제공할 수 있는 걸 생각해 냈다. 바로 require('nw.gui') 같은 빌트인 모듈. NW.js 써봤다면 알 것이다. 그때 나는 메뉴를 생성하거나, 트레이, 메시지 창 등을 API에 넣었다. 지금 NW.js의 원형인 셈이다.

내가 새 릴리스를 배포할 때마다 이런 아이디어를 유지했고, node-webkit v0.3.6 버전으로 피날레를 장식했다.

다른 GUI 프레임워크와는 달리 크로미움의 특별한 점 하나가 있는데, 바로 멀티 프로세스 아키텍쳐라는 점이다. 크로미움 브라우저는 웹 페이지를 실행하고 GUI를 띄우면서 응답해야 하기에 웹 페이지에 GUI 모듈 제공은 너무나 힘들었다.

이렇게 해서 웹 페이지 내에 브라우저 처리를 하기 위한 내 첫번째 시도는 이랬다.
먼저 크로미움을 싱글 프로세스로 돌린다. 허나 이건 너무나도 불안정하게 돌아간다.
이번엔 그냥 네이티브 GUI API를 렌더러 프로세스에 호출하도록 해봤다.
하지만 몇몇 플랫폼에서 GUI 요소와 프로세스를 직접 핸들링할 수가 없었다.
그래서 찾은 마지막 방법은 IPC 메시지를 통해 GUI 모듈을 node-webkit에 입혔다.
이렇게 해서 렌더러 프로세스 중에도 상시 행동이 가능했고,
브라우저 프로세스 간이나 주어진 일을 완료하면 메시지를 보낼 수 있게 됐다.

node-webkit 홍보

node-webkit 같은 프레임워크는 사용자가 가장 중요하다. 많은 사용자를 가지고 만드는 데 있어서 가장 중요한 것들도.

그래서 내가 node-webkit를 개발하는 동안 최대한 홍보도 해왔다. node.js 메일링 리스트에 소개글도 올렸고, 답글도 달아줬다.
node-webkit 게시들을 달며 node-webkit 발표도 했고, node-webkit 샘플 앱도 제작했다.
이렇게 나는 전 세계에 내 힘으로 node-webkit를 알리는 계기를 만들었다.

그리고 node-webkit 개발을 중단하기 전에 Github 별을 천여개 씩이나 받았다. Github에 상위 C++ 프로젝트 10위 안에도 들었다.

첫 사용자

내게 node-webkit 첫 사용자는 정말 중요한 순간이었다. @ibdknoxLight Table editor 을 node-webkit 를 통한 웹 기술로 다시 탄생시켰다. 이후 많은 이들이 node-webkit 에 주목받고 많은 도움이 들어왔다. 이렇게 기쁜 순간을 만들어준 @ibdknox 에게 감사의 말을 전한다.

그 다음 해에 Light Table는 node-webkit 에서 Electron 으로 자리를 옮겼다. 왠지 오랜 친구가 돌아온 것 같았다.

GitHub으로 이동

어느날 Github 에서 비밀리에 Atom 에디터를 시작하면서, @nathansobo 가 node.js로 데스크탑 앱을 개발하는 사람을 구하고 있었다.
나는 Atom을 node-webkit에 마이그레이션하기 위해 필요할 때마다 node-webkit를 개선하는 조건으로 그와 계약했다.

이렇게 반년동안 node-webkit를 개발하다가 인텔 인턴쉽은 이렇게 끝났다. 바로 나는 Github 고객지원부로 일하기 시작했다. 그리고 동시에 node-webkit 개발을 중지하고 뒷일은 @rogerwang 이 모두 맡게 됐다.

Contribution Graph

왜 이렇게 뜨거운 감자인 node-webkit 개발을 중단했을까? 어자피 내가 Github으로 이동하는데 전혀 영향도 없었고, 누가 프로젝트를 운영하는데 나는 상관이 없으니까.

아시다시피, 난 인텔에서 다른 사람의 프로젝트를 진행하고, 프로젝트의 결정권을 가질 수도 없었다. 아무렴 어떤가.
그냥 난 누구의 방해도 없이 node-webkit을 재구성할 수 있고 기능을 추가하면서 장난감 조립하듯이 일하는 게 좋았으니까.
어느날 node-webkit 오픈 소스 규모 커지기 시작했고 말 나오기 무섭게 나의 node-webkit의 권한은 상실됐다.
새 버전을 배포하는 데 있어서 책임이 상급 엔지니어에게 이관되어
내가 일할 수 있는 범위가 사실상 줄어들었고, 내가 좋아하는 기능을 넣을 수 없었다.

비난할 이유가 없다. 인텔 말고도 다른 회사도 그러니. 하지만 단도직입적으로, 더이상 참을 수 없었다.

더 나은 데스크탑 프레임워크 제작

내가 Atom 개발에 참여했을 때, Atom은 CEF에 파일시스템을 운영하기 위한 자바스크립트 바인딩으로 이루어져 있었다. 이게 Atom이 node-webkit로 마이그레이션한 계기가 됐지만, node-webkit가 그때당시 결함이 많다 보니 앞길이 순탄치 않았다.

그래서 난 결국 자체 네이티브 쉘을 만들어 해결하기로 했다. 새로운 쉘은 node-webkit를 개선하는 대신 몇가지 근본적 구조를 바꾸는 방향으로 재구성했다.

이리하여 이 쉘에게 atom-shell 이라고 이름 지었다.

node-webkit 에서 Electron 1.0 까지

그 이후 Electron과 NW.js 에 무슨 일이 일어났는지 내역을 정리했다. Atom과 Atom-shell 은 오픈 소스로 배포했고 그 atom-shell은 Electron으로 개명했고, node-webkit는 NW.js 로 이름을 바꿨다.

그리고 저번 주말에 드디어 Electron 1.0 을 배포했다.

Contribution Graph

Electron은 NW.js의 파생인가?

아마 내가 받은 질문 중 가장 많이 받은 질문이고, 내가 이 글을 쓴 이유이기도 하다. 기술적으로는 Electron은 node-webkit 0.3.6을 재구성했다. 내가 마지막으로 배포한 버전이고 이걸 끝으로 node-webkit 개발을 중단했으니. 그러고 보니 Electron은 원래 node-webkit와 아주 다른 노선을 밟았다.

그러니까 재대로 얘기 좀 하자면, NW.js는 내가 node-webkit 개발한 걸로 시작했고, Electron은 내가 다시한번 node-webkit에 파고든 작품이다.


복터진 개발자네. 군기잡힌 인턴 개발자에서 Electon 메인 개발자가 되기까지…

composite / 2016년 5월 25일 / Piss Development, Waldo Translation / 2 Comments

node.js의 웹 기반 데스크탑 앱 프레임워크 비교

nw.js

내가 많이 사용해봐서 잘 안다.

뭐래 병신이…

장점

  • 초보자에게도 쉬운 접근성
  • 크롬 확장 및 API 지원
  • nwjc를 통해 지적 재산권 보호 기능 지원 (소스 코드 보호해준다고.)
  • 키오스크, 항상 위, 트레이, 메뉴, 투명화 등 기본적으로 앱에 필요한 기능 지원
  • 웹 컨텍스트 기준으로 프론트엔드 개발에 능하다.

단점

  • 존나 무겁다. 크롬의 대부분 기능을 담았기 때문에.
  • 자체적으로 앱 패키징이 없기 때문에 타 모듈 등을 사용해야 한다. (근데 맥은 존나 편함 ㄳ)
  • 소스코드 보호기능은 당연하지만 성능이 30% 이상 하락하므로 필요한 곳만 사용.
  • node.js 확장 중 네이티브 확장 지원이 그지같다. node-gyp로 가져온다 해도 다시 nw-gyp 써야 함.
    업데이트: 0.13부터 이제 nw-gyp 안써도 됨. (윈도우는 개발자에 한해 한가지 뭐 해야함 아 귀찮.)
  • 피드백 속도가 좀 느리다 (Github Issue 피드백이 평균 7일이라고 함. 참고로 같은 Issue 트래킹에 Electron은 평균 1일.)

Electron

한국에서 가장 많이 알려지고 애용하는 프레임워크.

내가 nw.js 홍보했더니 구려 터졌다고 꺼지라더라.

장점

  • 가볍다. 크롬의 핵심 기능만 넣었기 때문에.
  • 앱의 Hang 및 Crash 처리를 자체적으로 지원.
  • HTML5 및 ECMAScript 6 등 가장 최신 기술을 가장 빠르게 지원
  • 자체적으로 쉽게 사용 가능한 앱 패키징 및 업데이트 모듈 지원
  • 항상 위, 트레이, 메뉴, 투명화 등 기본적으로 앱에 필요한 기능 지원
  • 절약 모드를 무력화하는 API 및 웹 표준 DRM 등 더 다양한 기능 지원

단점

  • 크롬 확장 미지원
  • 소스 보호 기능이 없어 타 모듈(enclose.js 등)을 사용해야 함.
    (Electron 메인 개발자인 Cheng Zhao(@zcbenz)는 퍼포먼스를 위해 이를 지원하지 않겠다고 못박음)
  • Electron은 컨텍스트 구분이 nw.js에 비해 뚜렷함.
    이런 이유로 nw.js에서 쉽게 jQuery 지원했던게 Electron에서 쉽게 안되는 이유이기도 함.
    자세한 내용은 해당 FAQ 참고.
  • node.js 확장 중 네이티브 확장 지원이 그지같다. node-gyp로 가져온다 해도 다시 electron-gyp 써야 함.

node-thrust

앤 또 뭐냐…

몰라 시발.

장점

  • node.js 뿐만 아니라 Go, Python, Ruby 등의 언어 지원
  • 자체 IPC 원격 통신 제공
  • 저장 경로 사용자화 및 다른 방식의 쿠키 저장소 지원
  • 자체 프록시 기능 지원

단점

  • 데스크탑 앱의 모든 기능을 지원하지 않음. (다행히도 투명화는 지원)
  • file:// 프로토콜 미지원 (node-thrust에 자체 웹 서버가 있는 이유)
  • 프론트엔드와 백엔드 사이 연동 미지원 (예: 프론트엔드에서 node.js 모듈 바로 못씀)
  • 뜨고는 있지만 아직 부족한 문서

내가 뭐 부가설명 쓰려 했는데 까먹은 관계로 여기까지.

composite / 2016년 5월 18일 / Piss Development / 0 Comments

Microsoft Edge 브라우저가 빡치는 이유

윈도우 10에 내장된 Edge.
옛날 유럽에 IE 끼워팔기 논란에 휩싸였던 IE의 역사를 딛기는 개뿔 일단 OS 종속적 인터넷 브라우저다.
뭐 물론 이후 윈도우에서 선택적으로 프로그램 추가 제거에 포함되는 쾌거(?)도 낳았던 논란이다.
사실 그렇게 따지면 Mac OS의 Safari는 뭐냐 시발?

어쨌든 Edge. 크롬의 초창기를 보는 듯한 브라우저이다. 초기화 속도도 빠릿빠릿하고 페이지 불러오는 속도도 빠릿빠릿하다.
물론 크롬처럼 확장 기능 많아지고 이것저것 덕지덕지 붙이는 날이 온다면 어떻게 될지는 그때 가봐야 알 것 같고.
ACID 점수가 점진적으로 높게 간다는건 좋은 징조 아니던가.

하지만 역시 IE보다도 불편하게 만드는 Edge의 문제점을 짚어보고 사용 시 유념하고 넘길 건 넘어가야겠다.

뒤로가기와 앞으로가기 버튼의 히스토리 부재

이건 진짜 용서할 수 없는 부재다. IE보다도 불편하게 만드는 가장 큰 주범이다.
특히 리디렉트가 더럽게 많은 한국사이트와 소셜로그인으로 인한 다중 리디렉트 이후에는 정말 빡치게 만든다.
원하는 이전 페이지를, 예를 들어 구글 검색하다 레딧 들어가서 구글 로긴 하고 레딧 댓글 달다가 다시 구글 검색결과로 돌아가는 시나리오를 생각해보자.
히스토리 내역도 안보여주고, 오로지 감으로만 몇번 연속 클릭질을 해야 하니 얼마나 짜증 이빠이지 아니한가.
그렇다고 개발자도구 키고 history.go(-2) 이지랄 하리? 하아…

SSL 있어? 신뢰할 수 있는 사이트네. 근데?

HTTPS 를 통해 접속된 사이트라면 주소표시줄 옆에 자물쇠 아이콘이 있어 안전한 사이트임을 보여준다.
근데 그다음엔 어쩌란 말인가. 진짜 이 사이트가 정말 신뢰된 사이튼지 아닌지 검증하고 싶은데?
인증서를 볼 수 없다. IE도 크롬도 불여우도 다 인증서 정보 보여주는데 IE는 그딴거 없다.
다행히도 비주류(?) 브라우저라 망정이지 이건 정말 개선해야 한다.
주류였으면 피싱은? SSL 스니핑 등 다양한 공격을 구분할 수 있는 수단은? 개발자 도구 여는거? 지랄.

HTTP 오류 페이지 그만 좀 보고싶다.

엣지는 HTTP 오류 코드가 나오면 정말 친근한 페이지가 여러분을 반길 것이다. 400이던 404던 500이던…
하지만 개발자에게는 정말 지랄같지 아니할 수 없다. 오류 내용 보려면 개발자 도구 켜고 내용 볼 수 밖에 없다.
아 그래… 맞아.. 하긴… 이건 개발자가 볼 페이지긴 하지… 근데 이건 아니자나…
다행히도 Edge가 오류 페이지를 보여주는 조건이 있다고 한다.
Prevent Edge browser hiding HTTP error pages

In Internet Explorer, as long as the server returned more than 512 bytes of data in the response, it would display the response, but in Edge, that’s not enough.

원래 IE에서는 HTTP 오류 코드를 받을 때 응답 내용 크기가 512바이트를 넘기면 사이트에서 제공하는 오류 페이지를 보여준다고 한다. 하지만 Edge는 이걸로 부족하다고.

https://www.hackcraft.net/error/badrequest/

이 경우 400 HTTP 오류를 보여주는데 페이지 내용이 표시된다. 크기는 2.17KB라고 한다. 보여준다. 이런 식으로 조건을 만족하면 되나보다.

아 손아파. 일단 여기까지.

composite / 2016년 5월 17일 / Piss Development / 0 Comments

자바 개발시 Hot Swapping 종류

Java Server Hotspot

  • JDK 설치하면 기본적으로 제공
  • 메소드 내용을 수정한 뒤 재시작 없이 반영
  • 그게 다임. 내용 수정 외의 수정은 모두 재시작해야 함.

jRebel

  • 상용으로 유료 솔루션
  • 자바 코드 어떻게 수정해도 재시작 없이 반영
  • Spring 플러그인에 한해 XML 설정도 재시작 없이 반영
  • 왠만한 WAS 및 환경에서 사용가능 (국내한정 JEUS는 되긴 하지만 공식 미지원)
  • 적은 코드 변경에는 아주 빠른 Reload
  • 변경 코드가 많을수록 Overhead 심각 (이건 어느 솔루션도 못피함. 이건 무조건 재시작삘.)

Spring loaded

  • 무료이며 오픈소스
  • 스프링만 적용 가능 (전자정부는 되겠지 뭐)
  • 스프링 자바 및 XML, properties 변경 시 적용
  • 스프링 외 플러그인 설정파일 변경 지원 안함.
  • 현재 톰캣만 지원. 나머지 WAS 보증불가
  • 몇몇 사용자에서 재시작이 안되는 문제가 보고되고 있음

Spring boot devtools

  • 무료이며 오픈소스
  • Spring boot만 적용 가능 (상속 때문에 일반 spring 적용 불가)
  • spring boot 및 상속 가능한 모든 자바 및 설정 파일 변경 시 적용
  • spring boot 돌아가는 어떤 WAS 상관 없이 지원 (JEUS는 모름)

닷넷커: ㅋㅋ ASP.NET (MVC 포함)은 기본 전체 홧스왑 수준인데 고생한다.
자바커: MS 종속적이고 비싸기만 하며 오픈소스 없는 놈이 말이 많어.
닷넷커: 이제 크로스플랫폼 지원하고 소스는 이미 오픈된지 오래임.
자바커: 그러던가. 어자피 한국에서는 영원히 잊혀질 기술임 ㅗ.

composite / 2016년 5월 12일 / Piss Development / 0 Comments

1 2 3 21