.NET Standard 2.0 관전 포인트

올 가을 .NET Standard 2.0이 출시된다.
이번 업데이트에서는 .NET Framework에서 꿀빨던 많은 API들을 최대한 수용하여 .NET Core로 이식 가능성을 중점으로 삼았다.
또한, Mono와 Unity 접근성을 최대한 확보하여 Mono에서 .NET Core 로 이동하여 통합 개발이 가능하도록 유도하였다.
그렇다면 대체 .NET Standard 2.0 에서 주의깊게 봐야 할 요소는 무엇이 있을 지, 알아보도록 하겠다.

1. .NET Framework와 .NET Core 간 상호작용

NETStandard20Libraries.png
출처: .NET Standard 2.0 – Making Sense of .NET Again

닷넷코어는 최신 표준인 1.6조차 .NET Framework 에서 .NET Core로 옮기는 데 부족한 API로 많은 어려움이 있었고,
게다가 Reflection API의 상당한 변경, AppDomain API 부재로 이를 사용한 라이브러리 이식에 많은 어려움이 있었다.
이번에 2.0의 메인 변경점이 바로 .NET Framework와 호환 가능한 API가 대거 추가된다는 점이다.
하지만 AppDomain 은 잘 쓰지 않는다. 이 글을 보고 있는 당신도 왜 AppDomain을 쓰는지 잘 모를 수 있을 것이다.
주로 플러그인 동적 로드 용도(라이브러리 동적 로드)로 쓰는데, .NET Core에서는 굳이 없어도 동적 라이브러리 로드 및 관리에 지장이 없다.
물론 .NET Core 에 API는 있지만 뭔 짓을 해도 PlatformNotSupportedException 예외가 나올 것이다.
어찌저찌 얘기해도 결론적으론 필요성이 전무하다는 거다. 이는 공식 FAQ에 나와 있다.
뱀발로, 기본적으로 닷넷 앱을 실행하면 자동적으로 1개의 AppDoamin 안에서 실행된다. 그리고 닷넷코어는 1개만 쓰도록 강제한다고 생각하면 된다.
어쨌든, 이런 아주 특이한 케이스를 제외하고는 최대한의 호환성 확보로 .NET Framework 와 .NET Core 간 호환에 지장이 없도록 했다는 것이 포인트.
그럼 이식 가능한 라이브러리(Portable Class Library)는 어떻게 되냐고? 일단은 살아있다. 일종의 플랫폼 간 다리로. 아직 이렇다 할 사안은 공식적으로 없다. 쓰고 싶은 사람은 쓰도록.
아무래도 한국 닷넷 개발자가 .NET Core로 이식한다면, 가장 맨붕 올 주는 부분이 바로 System.Data의 부족함일 것이다.
일단 추상 클래스는 원래대로 제공하되, ODBC 같은 특정 플랫폼용 API는 제공할 계획이 없다고 하니 이 점을 유의하면 되고,
특히 MSSQL 연동 시 .NET Framework에서는 아예 기본 제공이었던 점과는 달리 따로 분리되어 따로 불러와야 한다는 점만 주의하면 되겠다.
WCF나 WPF같은 경우 애초부터 윈도우 종속이기 때문에 절대 기대는 하지 말자. 다시말해, 닷넷 자체 플랫폼 종속 기능과, Remoting 기능을 기대하지 말라는 거다.
(단, XAML 자체는 독립 플랫폼 표준이 생겼기 때문에 플랫폼별로 Xamarin 등으로 새로 만들어야 하는 거 빼면 스펙 문제는 없다.)
이런 몇가지 예외 사항을 제외하면 대부분이 이식 가능하도록 배려했다고 한다.

2. .csproj 부활

앞서 닷넷코어 팀이 1.0 Preview에 예고한 것처럼, project.json 방식에서 다시 .csproj 방식으로 돌아온다.
.csproj 방식은 XML 으로 관리하는 방식인데, 닷넷 팀도 기존에 강력한 프로젝트 관리 형식을 버린다는 건 낭비라고 판단한 듯 하다.
분명 JSON 방식은 사람이 읽기가 쉽고 간결하며, 프로젝트 관리에 지장은 크게 없었지만, 닷넷의 모든 것을 수용하기엔 해결해야 할 과제가 많았기에 돌아온 것으로 보면 된다.
그래서 .NET Framework 에서 .NET Core로 이식하거나 그 반대로 마이그레이션 하는 접근성을 한층 더 높여줬다고 보면 된다.

3. 뭐야? 이게 다야?

그렇다. 이게 다다. 공식적으로 닷넷 2.0 최종 버전의 소개는 이게 다다.
뭘 더 바랬는지 모르겠지만, .NET Standard 는 스펙이다. 구현체는 .NET Framework 와 .NET Core다.
스펙에서는 플랫폼 간 이식에 중점삼아 스펙을 구성하여 이걸 .NET Framework 와 .NET Core 으로 구현한 것이다. 이게 다다.
C# 표준도 향상된다. 하지만 이는 .NET Standard와는 상관이 없다. C#은 언어 스펙이기 때문이다. 당연히 최신 언어 스펙을 .NET Standard 1.x 사용하는데 크게 지장이 없다.
.NET Framework 4.5 부터는 언어 스펙이 올라가도 사용하는 데 지장이 없다는 걸 C# 6.0에서 보여주었다. 그렇기에 따로 봐야 할 문제다.
물론 가능하면 새로운 앱을 만들거나 마이그레이션을 해야할 경우가 생기면 .NET Standard 최신 버전을 따르는 게 유리할 수밖에 없다. 1.x 는 API 텀이 너무 많기 때문이다.

글 쓴 나도 허무하다. 하지만 이번 업데이트 만큼은 기대해도 좋다. 왜냐면 닷넷 그대로 덜 만져서 탈윈도우 플랫폼을 꾀할 수 있는 기회가 되기 때문이다.
지금 당장 테스트하고 싶으면 .NET Core 2.0 Preview를 설치하면 된다. 거기서 크게 달라질 거 없다고 한다.

여담으로, Standalone 프로젝트(사내용 앱 등)은 특정 플랫폼, 특정 API를 쓰는 경우가 많기 때문에 그 프로젝트 자체를 마이그레이션하려는 멍청한 짓은 하지 말자. 어자피 갈아 엎어야 한다.

composite / 2017년 8월 11일 / Piss Development / 2 Comments

nw.js 한국어 활동을 중단하다.

다들 Electron 쓰는 거 안다. 그래서 단도직입적으로 말하겠다. nw.js 활동 관뒀다.
시간에 쫓기고 관련 프로젝트도, 수요도 없으며, nw.js 쓰던 개발자들도 모두 Electron으로 옮긴 데는 이유가 있다.
뭐, 어찌보면 나의 변명을 싸지르는 글이기도 하다. 일단 나열하겠다.

미미한 수요

현재 많은 개발자들은 데스크탑 앱을 간편하게 제작하는 데 Electron 으로 개발하고 있을 것이고, nw.js 라는 놈이 있었나 하는 사람들은 깊게 파기 시작하다보면 아하 할 것이다.
당연하겠지만, Electron은 개발자 친화적인 프레임워크를 구축하였기에 더 많이 채택된 것이다. 즉, 이런 이유로 Electron을 선택한 것이다.

  • node.js 에 익숙한 개발자들의 익숙한 개발환경 구축 용이
  • ASAR 패키징을 통한 기본적으로 손쉬운 패키징
  • 많은 사용자 커뮤니티 층과 Issues
  • 성능과 기술 수용속도가 유리
  • 견고하고 안정적인 업데이트 주기

당연하겠지만 첫번째 이유가 가장 큰 이유 되시겠다.
물론 nw.js도 나름대로 장점이 있다.

  • node.js 에 익숙하지 않아도 구축 가능한 개발 환경
  • 자바스크립트 소스코드 보호를 위한 nwjc 제공

둘 다 오픈소스다. 그리고 하나는 Github, 하나는 Intel 이 주도한다.
결국 nw.js 의 업데이트 속도와 Issue는 느려졌고, Intel의 보수적 개발 덕분에
수요자들을 충족시키지 못했다. 자연스레 Electron의 압승으로 현재 진행중이다.

여기서 Electron을 선택할 수밖에 없는 수요층이 있는데, 바로 실시간 처리를 하는 업자들이다.
대표적인 예로 메신저, 화상 회의나 채팅 등이 있다. 그리고 여러분이 많이 쓰는 Slack이 대표적 업체다.
개발하던 패턴대로 개발하면 되기 때문이다. node.js 관련된 여러 기술들을 그대로 가져다 쓸 수 있다.
물론 네이티브로 갈 땐 얘기가 달라지지만.

기술적으로 Electron은 nw.js에 비해 프론트엔드와 백엔드 컨텍스트가 완전히 분리되어 있다.
이 때문에 명확한 컨텍스트 관리라는 평가를 받고 있기도 하다.

랜섬웨어 프레임워크???

파일을 무작정 암호화 하고 파일을 인질삼아 금품을 요구하는 랜섬웨어.
이 프로그램을 만드는 데스크탑 프레임워크의 쌍벽이 있는데,
하나는 .NET WinForm이고, 또 하나는 nw.js 다.
그래서 보안개발자들 입장에서는 nw.js 는 비트코인처럼 혐오하는 프레임워크일 지도 모른다.
당연하겠지만 node.js 에 익숙하지 않은 개발자들에게 nw.js는 접근성이 용이하다.
왜냐면 그냥 웹 페이지만 띄우고 package.json 쓰고 실행만 하면 땡이기에.
그래서 어느 백신은 nw.js 들어가기만 해도 걸러내는 오진을 선보이기도 했다.
결국 nw.js 는 Electron 개발자 중 아는 개발자들에게 웃음거리가 됐고 불명예스러운 프레임워크가 됐다.

Github의 윈윈전략

Electron은 Github의 주요 기술이다. Atom Editor는 그 기술을 통해 제공하는 컨텐츠일 뿐이다.
거리낌없이 Electron을 오픈했고, 기업들은 이를 선택했다. MS도 거리낌없이 선택했다.
이리하여 Github은 거대한 플랫폼 시장을 형성하는 데 성공했고, 이제 Github 종속된 대기업이 많아졌으며,
세계적 브랜드 네이밍을 어마어마하게 키운 업체가 되었다. 한국 직원이 아직도 없다는 건 무시하자.
(참고로 중국과 일본은 있는데 한국은 없다는 점에 카타르시스를 느끼는 병신이 본인이다. Github Enterprise는 중국과 일본에 현지 서비스가 가능하지만 한국은 없다고 한다. 지금도.)

그에 반해 nw.js 도 많은 노력을 기울였고 Electron을 탄생시킨 프로젝트였지만,
이제 말하는데 nw.js 프로젝트를 인텔이 이끄는 걸 아는 사람도 별로 없더라. 허..

브랜드 파워는 이런 단순한 곳에서 출발하여 거대한 시장을 이끌어내고 있다.

나 이제 뭐하냐…

일단 Electron 에반젤리스트들은 한국에도 꽤 많아졌다. 물 들어올 때 노 저어 이름 석자 알린 사람도 꽤 있다.
그런 면에서 나는 비주류에 노를 젓다 썰물 다 가 고립된 상태인 것이다.
지금 내 꼬라지를 짤방으로 마무리하며 시간상 여기까지 싸지르도록 하겠다.

둠가이

composite / 2017년 7월 11일 / Dog's bullshit, Piss Development / 0 Comments

자, 자바커들아, 게이물 시작하지. Porject Jigsaw 통과.

지난 6월 27일, 내 예상과는 달리 직쏘가 통과되어, JDK 9에 당당히 포함할 수 있게 되었다.
직쏘 반대하느라 A4용지 30여페이지를 날린 레드헷만 끝가지 반대 입장을 고수했고, 나머지는 오라클 영업력에 뻑이 갔는지 모두 찬성했다고 한다.

자바 개발자들에게 여태까지 버텨왔던 하위 호환성. 이제 개나 주게 생겼다.
하지만 그건 문제가 아니다. 왠만한 언어 스펙도 이런 고통을 안고 업그레이드 했다.
가장 대표적인 게 Python인데, 유니코드 지원이 강화한 대신 유용(?)한 API를 삭제했다고 원성을 높여
아직도 2.7을 쓰는 프로젝트와 제품이 즐비한 상황이다.
자바도 뭐 이미 그꼴 날 건 뻔할 뻔자지만, 당분간 자바개발자들은 임베디드나 모바일 계통이 아닌 이상은
계속 Java 8을 보고 있을 것으로 보인다.

직쏘를.araboja

정식 명칭으로 “자바 플랫폼 모듈 제계(Java Platform Modulule System)”라는 이름을 가지게 되었으며, JSR-277 번호를 가지고
2011년 프로젝트를 시작하여 원래 자바 7에 추가할 예정이었다. 하지만 구조적 문제가 해결되지 않아 자바 8에서도 보류하는 아픔을 겪었다.
직쏘에 기대를 거는 이유는 하나다. 여태까지 고질적인 자바의 문제를 해결할 핵심 기능을 가지고 있었기 때문이었다.
자바의 고질적인 원흉인 캡슐화 문제는 뭐 이미 옛날부터 제기해왔지만, 당시 닫혀 있었던 구조상 해결할 수 없어 그저 수용만 했던 개발자들이 대부분이었다.
하지만 자바의 오픈 이후 이를 개선할 수 있는 움직임이 생겼으며, 이 중 하나가 바로 직쏘다.

대부분의 자바 개발자는 이런 반응을 보일 것이다.

  • 크로스 플랫폼으로 잘만 돌아가고 있는데 왜?
  • 메모리 문제? 그저 사양만 늘려주면 빠르고 깔끔하잖아?
  • 경량화? 경량화 할 디바이스가 어딨다고…

근데, 리조트 프로젝트 했었는데, POS를 자바로 개발하려는 시도가 있었다. 하지만 낮은 사양에 높은 처리능력을 요구하기에 자바는 맞지 않았고 닷넷으로 갔다.
관련 프로젝트를 해본 사람이라면 안다. 왜 자바를 POS에 접목시키는 게 쉽지 않았는지. 웹 말고.
하지만 모듈 시스템을 탑재하면 더 가벼워진 이미지로 적은 메모리로도 POS 시스템을 돌릴 수 있다고 생각해보자.
속 시원하지 않겠는가?

이 중 큰 원인이 바로 자바의 상속 시스템인데. rt.jar 파일 아는가? 자바에 모든 API가 있는 라이브러리다.
그만큼 무겁다. 더럽게 무겁다. 모든 자바 프로그램은 절대 이 라이브러리를 거역할 수가 없다.
닷넷의 경우 얘기가 틀린데, 닷넷은 GAC이라는 레지스트리급 쓰레기가 있지만, 대신 모듈이 분리되어 필요한 것만 갖다가 쓸 수 있다.
그래서 시작 속도 뿐 만 아니라 성능 면에서도 유리하다. 예를 들어,
자바는 웹을 아예 안 써도 웹 API를 가지고 가야 한다. 하지만 닷넷은 안쓰면 안가져가도 된다. 이 차이인 것이다.
그러나 직쏘와 함께하면 자바도 웹 안쓰면 웹 안들고 가도 동작하도록 할 수 있다. 말 다했다.

한마디로 자바의 입지를 한 층을 넘어 더 다양한 분야에 뛰어들게 해주는 샘물같은 존재다. 그걸 모르는 자바 개발자들은 지금에도 만족하며 잘 개발하고 있겠지만.
게다가 이런 현상을 유지하는 데 한몫한 업체가 바로 의외에 있었는데, 구글이다. 그렇다. 안드로이드다.
하지만 안드로이드는 개발 시 자바를 언어로 쓸 뿐, 오라클의 JVM을 쓰지 않고 아예 독립적으로 개발한 JVM으로 돌리고 있다.
게다가 딸려나오는 라이브러리도 많다. 그리고 이들 모두를 상속받아야 안드앱 개발이 가능하다.
따라서 모듈 시스템에 수혜를 받기엔 가상머신부터 틀려서 일단 패스하고.

이클립스 실행하는 데 느리다고 생각하는 사람 많을 거다. 더럽게 무겁기도 유명한 비주얼 스튜디오보다도 느리다. 인텔리제이도 시작 속도 예외는 없다.
그걸 빠르게 해 주겠다는데. 왜?

직쏘가 어떻게 구현되고 돌아가는지는 얘기가 너무 길어지니 직접 검색해서 보도록 하자. 한글 블로그에도 많이 소개되어 있다.

직쏘의.problem

이렇게 자바에게 날개를 달아주는 녀석이지만, 많은 자바 개발자들이 우려하고 있는 점이 있다면 바로 하위 호환성을 꼭 빼놓을 수 없다.
자바 1.5부터 추가된 제네릭의 경우는 객체 소멸(Type Erasure)을 통해 컴파일 때에만 제네릭을 검사하고 런타임 상는 제네릭 없이 돌아가도록 구현하였다.
그래서 닷넷과는 달리 Map 클래스와 Map<Key, Value> 클래스. 제네릭이 있던 없던 같은 클래스로 취급하는 것이다. 닷넷은 다른 클래스로 취급한다.
결국 1.4 때 제네릭 없었던 클래스처럼 써도 무방할 정도인 것이고, 성능상 이점이 없으며, 그저 자바의 방향인 Strong Typed에 부합될 뿐이었다.
그리고 자바 1.8부터 도입된 람다식의 경우 이미 익명 클래스로 충분히 소화해낼 수 있기 때문에 간소화된 것만 빼면 하위 호환성에 큰 지장은 없다는 것이다.
하지만 직쏘는 그 이전 버전에 대체할 수 있는 환경이 아예 없다. 하위 호환성을 유지하려면 직쏘를 아예 쓰지 말아야 할 정도이다.
여태까지 하위 호환성을 최대한 생각했기에 개발자 입장에서는 큰 난관이 아닐 수 없다.
만약 버전을 올리고 개발했을 때, 문제가 생기면 해당 버전에 맞게 개발하고 컴파일 하면 됐다. 하지만 직쏘는 그게 안된다. 다 버려야 한다는 것이다.
그래서 자바 API를 닷넷에 쓰게 해주는 IKVM.NET 개발자는 모듈 시스템의 복잡도 때문에 더 이상 새 자바에 대응하지 않겠다는 공식 입장을 피력할 정도.
그리고 이 불안은 현재진행형이며, 정식 버전이 나오면 1.9를 바라볼 사람이 얼마나 될 지 의문이다.

자, 자바 개발자들이여, 이제 게임을 시작하지. 직쏘.

composite / 2017년 7월 5일 / Piss Development / 0 Comments

프로젝트 직쏘는 희망이 없다?

자바 9가 올해 7월 말 즈음 출시될 가운데 안타까운 소식이 들어왔다.

바로 JCP(Java Commnity Program) 총괄 리뷰에서 프로젝트 직쏘가 많은 반대에 부딪혀 빛을 못볼 위기에 처해 있다는 것이다.
DZone – Java Zone – EC Rejects Jigsaw

직쏘 프로젝트 참여자들은 30일 내에 보완 후 다시 리뷰를 진행해야 하는데,
다음 리뷰에서 실패하면 직쏘는 자바 9에서도 볼 수 없는 시스템이 될 것이다.

프로젝트 직쏘는 익히 알다시피 하여 짤막하게 소개한다. SI/SM 개발자들은 관심없이 1.6 이하 버전이나 쳐 만지겠지만.
현재 자바는 JVM 내에 돌아가는데, JVM이 자바에 있는 핵심 라이브러리 외에도 사용자가 추가한 라이브러리 모두 안고 가기 때문에
성능 문제는 여러 방면에서 제기된 문제가 있었으며, 이로 인해 특히 임베디드 장비에서 자바를 꺼려하는 이유이기도 하다.
그래서 안드로이드 자바는 아예 달빅 등으로 자바를 재구성 해서 안드로이드 전용 자바 환경을 만들었던 이유이기도 하다.
물론 안드도 성능 이슈는 피할 수 없긴 매한가지지만.

어쨌든, 이걸 해결하고자 모듈 시스템으로 필요한 라이브러만 쓰고, 쓰는 곳으로만 최적화하고, 이식 가능(Portable)한 프로그램을 만들기 위해
꾸려진 프로젝트가 JSR 376q번 프로젝트 직쏘다.

하지만 프로젝트 직쏘는 당연하겠지만 많은 반대에 부딪혔다. 특히 이번 반대의 가장 주역이 바로 상업용 리눅스로 유명한 대기업 “레드햇”인데,
프로젝트 직쏘에 대한 문제점을 34페이지를 썼다.

DZone에서 언급한 주요 내용은 아래와 같다.

The patterns introduced within Jigsaw are (in some cases) going to be extremely difficult to fix even in a later release, and will create backwards- and forwards-compatibility problems that will be very difficult to unwind

직쏘에서 제시한 패턴은 이후 자바 출시를 할 때 여러 면에서 거대한 장벽을 유발한다. 그리고 상위, 하위 호환성 측면에서도 난관이 많을 것으로 보인다.

Due to lack of one to one mapping of use cases (or sufficient interoperability capabilities) and other restrictions, we are concerned that there will likely be two worlds of Java software development: the Jigsaw world, and the “everything else” world (Java SE Classloaders, OSGi, JBoss Modules, Java EE, etc)

일대일 연계에 대한 문제와 여러 제한 사항으로 인해 우린 자바 개발자들이 직쏘 세계와 현재 자바 세계(Java SE Classloaders, OSGi, JBoss Modules, Java EE, etc)를 두가지로 나눠 개발하는 광경을 볼 지도 모른다.

그렇다. 레드햇은 자바의 기본적인 목표인 “하나의 코드를 여러 플랫폼으로”에서 거리가 먼 직쏘에 거리를 둔 것이다.
이외 IBM, SAP 등 여러 거대 개발기업도 반대 의사를 표시했으며, 세계에서 가장 큰 자바 커뮤니티인 런던 자바 커뮤니티는 강한 반대 의사를 표시했다고 한다.
우리가 많이 쓰는 개발 툴 제작사 이클립스 재단도 반대 의사를 표시했다.

물론 찬성도 있다. 자바를 주도하는 오라클, V2COM, 후지쯔 등인데,
후찌즈는 “EC 회원들이 직쏘에 많은 집중을 하는 만큼 다음 투표에서 해결되길 바란다.” 라며 찬성 의사를 표시했다. 그렇다. 실질적인 반대 의사인 것인데 찬성한 것이다.
SouJava 라는 업체는 처음에 찬성을 하다 반대 의사를 표시했는데. 역시 사용자 접근성 결여를 이유로 반대 표시를 한 것이다.

결국 접근성 문제와 여러 제한 사항, 호환성 문제를 이유로 많은 커뮤니티와 업체에서 반발한 것이다.
우려한 대로 말이다.

닷넷 진영에서는 프로젝트 직쏘 때문에 다 갈아엎어야 하는 iKVM.NET 개발을 포기하기로 했고, 자바를 기반으로 한 스칼라나 코틀린에서는 대응이 안되어 있는 상황.
이렇게 준비가 되어 있지 않은데 우린 대체 무슨 희망으로 직쏘를 지지했던 것인가를 다시한 번 생각하게 한다.

내가 보건데 자바 9에서도 직쏘는 보기 힘들 것으로 보인다.
별 거 아닌 것처럼 보여도. 자바 2.0이면 모를까 자바 1.x 에 직쏘를 넣는다는 건 엄청난 변화이고, 기존 자바 개발자들이 한국 SI/SM 개발자처럼 정체된 자바 환경을 접해야 할 지도 모르기 때문이다.
직쏘를 적용하는 순간부터 하위 호환성을 포기해야 하고, 상위 호환성을 걱정해야 하며, 그리고 자바 직쏘에 대한 또다른 지식과 구조를 개발자들이 알아야 하니, 기존 개발자들에게는 큰 난관이 아니 예상할 수 있겠는가.

composite / 2017년 5월 18일 / Piss Development, Waldo Translation / 0 Comments

웹 기반의 컴퓨터 원격 통합관리 : ULTERIUS

https://ulterius.io/

  • 컴퓨터 시스템 모니터링 지원
  • 설치가 필요없는 원격 데스크탑 지원
  • 해당 컴퓨터 탐색기를 웹으로, 업로드 다운로드 당연히 지원.
  • 파워쉘 등 강력한 원격 실행환경 지원
  • 플러그인 지원 (완벽하지 않음)

이런 솔루션은 돈을 줘도 할 말 없는 솔루션인데 MPL 2.0 오픈소스인 C# 서버 앱이다.
.NET 4.5 이상을 지원하는 가능한 모든 윈도우에서 지원한다. 그렇다. 당연히 윈도우 전용이다.

composite / 2017년 3월 17일 / Dog's bullshit / 0 Comments

잠긴 글: Toad for Oracle 12.1

이 콘텐츠는 비밀번호로 보호되어 있습니다. 보려면 아래에 비밀번호를 입력해주세요:

composite / 2017년 3월 17일 / 미분류 / 0 Comments

윈도우 10 ISO 다운받기 (물론 합법)

최근들어 윈도우 10 ISO가 필요하게 되어 링크를 들러봤더니…

ISO 다운로드 선택 박스는 안뜨고 그저 도구 다운로드만 뜰 것이다.
그렇다. 윈도우 운영체제는 막힌 거다.

하지만 불가능하지는 않다. OS를 속이고 들어가면 되는데,
그냥 user agent 를 바꿔주는 확장을 깔면 해결된다.
크롬이나 불여우는 암거나 확장 깔고 OS 바꿔치기 하고 접속하면 되며, (맥~)
IE나 Edge는 확장은 없고 대신 F12 개발자 도구를 통해 바꿀 수 있다.

내가 쓰는 속이는 user agent 문자열 예제는 아래와 같다.
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36

그러하다. 그리고 접속하면 ISO 다운받을 운영체제 선택박스 화면이 뜰 것이다.
그 뭐냐… 누군가가 선택박스 핵 걸어서 하위 버전 다운받는 것도 통하는 지는 안해봤다. 난 그저 윈도 10만 있으면 되니까.

불법은 아니고 합법이다. 어자피 제품 키는 없다. 정당한 제품 키 없이 쓰면 불법이고, 쓰면 합법인 거다.

composite / 2017년 3월 16일 / Piss Development / 0 Comments

프론트엔드에게 setTimeout 함수는 단순한 함수가 아니다!!!

일단, 지금 내가 좆같이 외부망 막힌 프론트엔드 개발짓거리 하고 있는 관계로 블로그질을 잘 못하겠지만,
이런 일을 자주 겪어 존나 머리가 쌓이기만 하기에 내 메모리 릴리즈 하는 개념으로 글 씨지르겠다.

프론트엔드 개발하다 보면 이런 경우를 겪는다. 특히 화면 변경할때 말이지.
화면을 변경하다 보면 갑자기 스크립트 오류가 나거나, 원하는 화면이 안나올 때가 있다.
이것으로 머리 싸매다가, 안되겠다. 지연시켜서 뿌려야겠다는 생각으로 setTimeout 함수를 쓰면
원하는 화면변경이 이루어진다. 이상할 정도로.
더 웃긴 현싱은, 타임아웃 주기를 0으로 해도 잘된다는 것이다. 이게 대체 어떻게 된 거지?

먼저, 자바스크립트는 싱글 쓰레드라는 것. 아주 질리도록 들었을 것이다. 비동기도.

하지만 잊지 말아야 할 점은 이 싱글 쓰레드가 하필 화면을 표현하는 렌더링 시점에도 블로킹 현상이 일어나는 점을 간과해서는 안된다.
즉, 스크립트 실행중인 시점에 DOM에 어떤 변화가 찾아올 지 우린 예상할 수 없다는 것이다. 왜냐? 싱글 쓰레드로 하나씩만 진행하기 때문에.
그럼 왜 setTimeout 함수는 회피할 수 있을까? 간단하다.
위 그림을 보면 setTimeout 블록으로 등록된 timer 스레드는 그저 다음 실행 시점으로 예약만 하고 이 스레드에 도달해야 실행되기 때문이다.
그렇다면 왜 setTimeout은 분명 1초인데 1초 빨리 실행하거나 1초보다 늦게 실행하기도 하는가?
먼저, node.js 개발해본 시람은 알겠지만 거기는 setTimeout 함수는 없고 process.nextTick 함수를 사용한다. 그렇다.
원리는 비슷하다. 빠르게 tick 하면서 스크립트가 실행된다. 게임이나 영상으로 치자면 프레임 단위에 무슨 이벤트가 일어난다는 것이다.
보통 1 tick 하면 1/1백만 초다. 백만분의 1초. 하지만 setTimeout은 아무리 최소값이라도 4/1000초.
클라이언트 스크립트에서 tick 단위를 허용기엔 가뜩이나 렌더링이 스레드 예약하고 블록거는데 무슨 일이 일어날 지 검증이 안 된 상황.
자, 일단 여김가지 갔으면 이제 setTimeout 함수로 예약한 함수 루틴은 나머지 구문을 실행한 후 실행하는 것을 알 수 있다.
즉, 렌더링에 시간을 벌어주어 렌더링 후 화면 변경에 대한 정보를 불러오고 쓰는 데 정확도를 높일 수 있는 그런 트릭인 것이다.
그런 고로 화면을 변경할 때, 특히 DOM 데이터를 주고받거나 다룰 때 setTimeout 함수는 DOM 렌더링 시간을 벌어주어 원하는 사용자 처리를 도와주는 프론트엔드에게 고마운 함수인 것이다. 감사하며 쓰도록 하자.

참고: Why is setTimeout(fn, 0) sometimes useful?

composite / 2017년 1월 9일 / Piss Development / 1 Comment

[공지] 블로그 복구 완료.

공지는 존댓말인 거 좀 알고 넘어갑시다.

어쨌든 간에 예기치 못했다고 하는 사고가 일어나 꽤 오랜 시간동안 블로그 활동도 못했었죠.
12월 초 복구 소식을 듣고 기쁜 마음으로 도메인 복구를 했습니다.
이런… 11월 초까지 쓴 글이 손실됐군요. 뭐… 하드가 손상됐다고 하니… 아… 아쉽긴 하지만.
복구에 힘쓴 제공자에게 감사의 말씀을 드립니다. 아, 복구 전엔 나누미라고 써있는 호스팅 업체(…?)입니다.
초창기에 무료로 제공해주셔서 다시한번 감사의 말씀을 드립니다.

이제… 뭐합니까?

composite / 2016년 12월 8일 / Notice / 0 Comments

극단주의의 유행

국내 친여권 극단주의 일베.
국내 여성 극단주의 메갈.
해외 이슬람 극단주의 IS.
미국 금권 극단주의 트럼프.

지금은 대 극단주의 시대.

나? 종말 극단주의자임 개기지 마셈 ㄳ.
에라이 지구 멸망해버려라 ㅋ

그리고 지구는 멸망했다. 끗.

composite / 2016년 7월 20일 / Dog's bullshit / 0 Comments

1 2 3 22