#reactivex

[pignose-barn]

Angular 2 그리고 웹 프론트엔드 (1/2)

한동안 마무리 지어야 하는 일때문에 정신이 없다가 이제서야 정리를 할 시간이 오게 되었다..

이 포스트에서는 Angular가 무엇인지 모르는 분들을 위해 Angular를 설명하는 내용을 채울까 한다.

Angular 2 그리고 웹 프론트엔드 (1/2) - 현재 글

Angular 2 그리고 웹 프론트엔드 (2/2)

Angular는 구글에서 만든 자바스크립트 프레임워크이다.

프레임워크이기 때문에 일반적으로 여러분이 아시는 jQuery, underscore, lodash 보다 규모가 큰 프로젝트다. (지원되는 기능의 폭도 넓으며 채택한 의존 라이브러리들도 많다.)

한글 발음으로 “앵귤러 제이에스"라고 발음하면 되며 여기서 Angular는 “앙상한" 이라는 단어를 가지고 있는데,

아무래도 뼈대를 갖춰주는 프레임워크라는 의미로 사용했을 것이라고 생각된다.

Angular 공식페이지에 기재된 워딩이  “One framework” (하나의 프레임워크)인데, 이는 Mobile까지 대응하겠다는 Angular의 목표가 깃들어있다.

Angular에 대해서 대체 무슨 프레임워크인가, 어떤 목적과 장점을 가지고 있는가에 대해서 궁금증이 많으실 것이라 생각된다.

사실 이 물음을 풀어드리기 위해서는 앞서 웹 프론트엔드 개발 동향을 먼저 설명해야 할 것 같다.

웹 프론트엔드의 변화

현재 웹 프론트엔드 개발에서 사용되는 툴이 많다! 너무 많다! (그리고 많아지고 있다!!)

(필자는 이 사진에 보여지는 앱보다 많은 앱을 사용했음에도 전체에 비해서는 절반도 채 되지 않는다.)

일부 개발자는 전통적인 프론트엔드 개발 방식대로 html과 javascript 그리고 css를 개발하고,

javascript 엘리먼트를 쉽게 찾을 수 있는 jQuery와 jQueryUI를 연동하여 서비스를 완성 했을 것이다 그리고 그렇게 개발하는 방법에 큰 불편함이 없었을 것이다.

결과적으로 오늘에서 이렇게 개발을 도와주는 앱이 많아진 것은 ECMA 5에서 ECMA 6로 자바스크립트 표준이 변경되고 있는 상황과,

Node.js 보급으로 인해 백엔드 서버 개발자가 점점 javascript를 사용하게 되면서 백엔드 기술 프론트엔드와의 경계가 허물어지고 있는 점.

그리고 거대한 웹 서비스 벤더사(구글, 페이스북)에서 프론트엔드 프로젝트에 기여를 하고 있는 점 이것들이 뭉치면서 아래와 같은 결과를 내었다.

웹 프론트엔드 개발에 백엔드 개발에서 요구되던 기능이 추가되고 있다.

ECMA6의 지원을 위한 서브 툴이 생겨나고 있다.

많은 모바일기기 지원으로 보다 빠른 웹을 시장이 원하고 있다.

많은 기존 자바스크립트 라이브러리들이 최신 기술을 수용하고 있다.

(웹 프론트엔드 개발자들은 공부할 것이 엄청나게 늘어나 버렸다.)

또한 이러한 변화가 프론트엔드의 러닝커브를 늘렸으며,

기존 개발 환경에 익숙하여 최신 동향을 살펴보지 않는 개발자들은

자리를 위협받는 상황이 오지않았나 조심스럽게 추측해본다.

웹 프론트엔드 도구들

그러면 아까 사진에 보여드린 수많은 앱 들이 도대체 무슨역할을 하나?

그리고 그것이 반드시 필요한가에 대해서도 설명을 드릴까 한다.

상당히 지루하고 딱딱한 내용이 될 것 같아 많은 링크와 사진을 첨부했다.

   1. npm, bower, yoman, yarn

이 4가지 서비스는 Pakcage Manager(패키지 매니저)라고 부르는 서비스다.

(yoman은 정확히 말하면 스캐폴딩(Scaffolding - 실제 작업을 하기 전 철골을 덧대듯이 작업에 필요한 최소한에 구조를 만들어주는 단계)만 해주는 서비스.)

쉽게 풀어보자면 프로젝트에 사용할 라이브러리를 직접 찾아 해당 파일을 원격지에서 다운받아 로컬 파일에 옮기지 않아도, 간단한 명령어로 추가/수정/삭제를 지원하고 의존성(Dependency)을 관리해주는 서비스들을 의미한다.

또한 라이브러리 배포와 호스팅/빌드/테스트 스크립트 정의도 가능하다.

      2. Typescript, Flow

타입스크립트는 자바스크립트에서 발생할 수 있는 문제(타입 검증)를 해결해주는 동시에 ECMA6의 스펙을 포함하여 지원하고 있으며 Microsoft와 Google이 협력하여 개발하고 있는 언어이다. Typescript를 통해 개발을 진행하게되면 런타임 단계에서 발생할 수 있는 오류를 미연에 방지할 수 있고 OOP 지향한 개발과 Dependency Injection(DI)등의 패턴을 구현할 수 있게 된다. React 프로젝트의 Flow또한 타입 검증을 지원해준다.

      3. Reactive Programming

과거에는 웹 페이지 이동 (빈 화면에서 로딩이 걸리고 새로운 페이지가 보여지는) 없이 데이터를 업데이트 하는 사이트는 드물었지만 지금은 웬만한 서비스에서 이 기술을 적용하고 있다. 이러한 비동기 통신은 콜백함수를 통해 전달이 되어야 했으며 이 때문에 콜백지옥이 발생하기도 했다. RX(ReactiveX) 프로젝트는 이러한 문제를 해결해주며, 옵저버 패턴을 제공하여 서로다른 컨텍스트에 데이터를 동시적으로 제공해줄 수 있다.  Redux, Flux 서비스는 이러한 데이터를 효율적으로 대상에게 전달할 수 있다. 참고로 AngularJS 2는 RxJS를 포함 할 수 있다.

     4. grunt, gulp, webpack

여러분이 만약 반복되는 작업을 조금이라도 재활용하여 효율적인 프로그래밍을 원했다면 CSS의 작성이 굉장히 피곤하게 느껴졌을 수 있다, LESS와 SASS, Stylus와 같은 기술은 이러한 반복되는 작업을 없애주고 더불어 색상 코드를 특정 % (밝게, 어둡게)와 같은 편의 함수를 제공한다. 다만 결국 브라우저는 CSS 문서만을 인식하기 때문에 .less .sass와 같은 확장자는 빌드단계에서 변경이 이루어져야 한다, 그 밖에도 빌드 단계에서 진행되야 하는 작업들 (ECMA6 파일을 ECMA5 파일로 변경, 문서 최적화, 코드 테스트, 카피라이팅 삽입, 문서 문법 검증, 번들링 등)을 도와주는 도구가 grunt, gulp, webpack과 같은 도구이며 이는 다시 npm등의 패키지 매니저 도구와 연동하여 사용하거나 IDE(통합 개발환경)에서 연동하여 빌드과정을 일관화 시킬 수 있다. 이렇게 되면 파편화 되있는 JS, CSS, HTML 문서를 하나로 합쳐주며 표준코딩을 지향하게 되며 하위 호환 여부 검토가 수월하고 예기치 못한 버그와 사이드이펙트를 미연에 방지 할 수 있게 된다.

     5. RequireJS 그리고 CommonJS와 AMD(Asynchronous Module Definition)

Node.js의 영향 중 하나라고 필자는 생각한다.

네이버 D2에서 작성한 글이 보기 좋아 링크를 공유한다.

웹 페이지에서 서비스를 개발할 때 여러 Javascript 라이브러리를 합쳐 하나의 완성된 서비스를 만든다. 이때 이 라이브러리를 하나의 모듈로 볼 때 그 모듈에 대한 표준이 없다는 것이다. 따라서 각각의 라이브러리들은 서로다른 라이브러리 제공방식을 사용하고 있고 이를 이용하는 개발자는 각각의 라이브러리마다 다른 방식의 사용법 (같은 라이브러리라도 버전마다 달라지기도 한다.)을 이용해야하고 또 이러한 부분은 굉장히 비효율적으로 이용된다. (케익 한조각을 먹기위해 케익 전체를 사야하는 상황)

이를 해결하기 위해 나온 모듈 제공 방식이 CommonJS와 AMD이다.

각각의 사용형태가 다른 모듈들을 제공하는 하나의 표준을 만들어 그것을 지향하면 라이브러리 추가와 확장이 훨씬 쉬워지며 이는 큰 프로젝트에서도 모듈의 관리가 용이하며 효율적이다. 하지만 이 방식을 사용해도 마찬가지로 브라우저에서는 지원하지 않기 때문에 (다만 ECMA6는 import 키워드를 제공한다.) 이를 번들링 하기 위한 systemjs, Jspm, Rollup.js, Webpack등의 서비스가 존재한다

      6. jasmin, chai, mocha

규모가 큰 프로젝트 일수록 소스관리가 중요하여 자칫 하나의 수정사항이 사이드이펙트(다른 비즈니스 로직에 직/간접적으로 영향이 가는 것)가 발생 할 수 있다.

이는 라이브서비스에 커다란 이슈이며 이를 해결하기 위해 QA와 테스트케이스가 존재한다. 다만 규모가 크고 지원하는 플랫폼이 넓으며 수많은 페이지와 버그가 발생하는 환경을 시연하기 어려운 요소가 발생되면 이러한 테스트는 사람이 직접하기 어렵고 특히 애자일 방법론을 사용하는 개발 환경에서는 이러한 과정이 거의 불가능에 가깝다. 결국 이를 해결하기 위해서는 자동화된 개발 테스트 환경이 필요하다.

프론트엔드 개발도 마찬가지로 유닛 테스트를 지원하는 서비스가 있다. 가상의 DOM Mock에 라이브러리의 모든 케이스를 테스트해보고 결과적으로 테스트의 결과를 확인할 수 있게 제공하여 서비스 배포이전에 모든 기능에 안전성을 검토 할 수 있다.

      7. istanbul, blanket, JSCoverage

이전에 말한 유닛테스트는 서비스 되고있는 소스코드의 얼마나 많은 부분을 테스트 해주는지에 대한 부분이 상당히 중요하다. (많은 부분이 자동화 테스트를 지원할 수록 서비스는 안정적이고 신뢰를 보장하기 때문) 하지만 얼마나 많은 부분의 소스코드에 테스트를 지원하는지 사람이 알기에는 어렵다고 볼 수 있다. 이 때문에 얼마나 많은 부분이 테스트가 되었는지, 다시말해 얼마나 코드가 커버(Cover)되었느냐는 커버리지(Coverage)라는 용어를 사용하여 지표를 결정한다. 유닛 테스트 도구와 연동하여 커버리지 도구를 사용하게 되면 커버리지 지표를 리포트로 제공받게 된다.

      8. JSDoc

JSDoc은 javascript 모듈에서 사용되는 각각의 클래스, 함수들에 대한 정의를 JSDoc에서 정의한 표준 주석양식에 맞춰 작성하게 되면 그에따른 자동화된 개발 래퍼런스 문서가 만들어지게 된다. 마크다운 문서로 래퍼런스 문서를 제공하여 gitbook 같은 호스팅 서비스에 등재하게 되면 하나의 인쇄물로서 출력도 가능하다. 이러한 방법은 개발자가 일일히 래퍼런스 문서를 만들지 않아도 래퍼런스 문서를 만들 수 있는 이점이 있으며 표준화된 주석 사용으로 협업 및 인수인계가 원할하게 된다. 사실 다른 Doc 툴도 있지만 해당 서비스가 가장 유력하다.

AngularJS 2에 대한 설명을 위한 포스팅이었으나, 최근들어 웹 프론트엔드 개발 동향이 많이 변하고 있어 그 부분을 중점적으로 정리해보았다.

다음시간에는 Angular 2와 Angular 1 그리고 ReactJS를 주제로 중점적으로 다뤄보는 시간을 가져보도록 하자. 아디오스!

[black7375]

ReactiveX/RxAndroid

RxJava bindings for Android. Contribute to ReactiveX/RxAndroid development by creating an account on GitHub.

안드로이드 라이브러리를 찾던 중, 함수형 프로그래밍의 장점을 그대로~~ 이식 가능한 것을 발견했다!!!

https://github.com/JakeWharton/RxBinding 이랑 추가해서 쓰면 될 듯.

처음 써보는 사람들은 누구나 할 수 있는 RxJava, 지금 시작하기!, RxAndroid로 리액티브 앱 만들기 #1를 참고하면 될 듯.

[sundeepgupta]

Making Sense of FlatMap: An Rx Story

Originally published on Medium.

We’ve been using Rx for a while now and across a variety of projects. Yet we continue to learn new things - in this case, a clear understanding of FlatMap.

My team and I recently discovered a bug in one of our projects, and the culprit turned out to be the FlatMap operator—or rather, our misuse of it. I don’t know why, but FlatMap was a recurring source of confusion. (And the official Rx docs didn’t really shed much light on the subject.) Fortunately for us, we eventually gained clarity around the FlatMap operator using a real-life analogy that I thought would be worth sharing:

FlatMap is like the combining or flattening of commits pushed by a growing team of developers on a project.

Think of a team of developers on a project that uses a Continuous Integration (CI) service to build each pushed commit. The CI is interested in all of the commits pushed by all of the developers, including newly added ones, on the project.

FlatMap Analogy. Animation by Deyu Wang

We can dig into this more with code—in this case, Swift (and RxSwift). First, let’s define the objects we’ll need.

class Project { private let developerSubject = PublishSubject<developer>() var developerStream: Observable<developer> { return developerSubject.asObservable() } func addDeveloper(_ developer: Developer) { developerSubject.onNext(developer) } func stop() { developerSubject.onCompleted() } } class Developer { private let commitSubject = PublishSubject<commit>() let name: String init(_ name: String) { self.name = name } func startCoding() -> Observable<commit> { return commitSubject.asObservable() } func stopCoding() { commitSubject.onCompleted() } // Helper to externally simulate coding activity. func pushCommit(_ hash: String) { commitSubject.onNext(Commit(author: name, hash: hash)) } } struct Commit { let author: String let hash: String } class CI: ObserverType { func on(_ event: Event<commit>) { switch event { case .next(let commit): print("CI is building \(commit).") case .completed: print("CI stopped.") case .error(let error): print("CI errored: \(error).") } } }

Type Declarations

Now let’s instantiate things and hook it all up.

let project = Project() let jim = Developer("Jim") let anna = Developer("Anna") let bob = Developer("Bob") let ci = CI() project.developerStream .flatMap { developer -> Observable<commit> in print("\(developer.name) started coding...") return developer.startCoding() } .subscribe(ci)

Setup Objects

We flatMap the developerStream onto each developer’s commits. The resulting stream is subscribed to by the CI.

Looking closer, in the flatMap closure, for each developer emitted on developerStream, we return the developer’s stream of commits via the startCoding() function. This allows the flatMap to observe the commits emitted by all developers and then flatten them into a single output stream. The CI subscribes to this output stream so it can build each commit.

Let’s play with this to see what happens when we start adding developers and pushing commits. The trailing comments are the output from the print()s.

project.addDeveloper(jim) // Jim started coding... jim.pushCommit("1") // CI is building Commit(author: "Jim", hash: "1"). project.addDeveloper(anna) // Anna started coding... jim.pushCommit("2") // CI is building Commit(author: "Jim", hash: "2"). anna.pushCommit("3") // CI is building Commit(author: "Anna", hash: "3"). jim.pushCommit("4") // CI is building Commit(author: "Jim", hash: "4").

Normal Operation

Notice how even after Anna is added to the project, Jim remains “active” and the CI continues to see Jim’s additional commits. Jim’s commit stream returned from startCoding() doesn’t get replaced by Anna’s. Further, the order in which each developer is added doesn’t matter. The CI only sees the commits in the sequence they are pushed. The CI doesn’t care about the developers themselves, it only cares about their commits.

Taking a closer look, our flatMap subscribes to the commits from each developer received from developerStream. Even when new developers are received, those subscriptions continue to live on. This enables the commits from both Jim and Anna to be combined and flattened into a single output stream.

Wait — how is this different from **Merge?**

Instead of FlatMap, we could of course use the Merge operator to combine commits from multiple developers into a single stream. If the project’s developers are known and fixed, this would be fine, as Merge takes a static list of observables.

Observable.merge([jim.startCoding(), anna.startCoding()]).subscribe(ci)

However, if Bob came along to join the project at a later point, we’d have to handle that somehow. With FlatMap, since we subscribe to new developers being added, it’s handled for us already. Bob’s commits would automatically be taken into account and added to the flatMap’s output stream. Thus, we could say that Merge is for a static list of observables, while FlatMap is for a dynamic list of observables.

So, that’s most of it. But let’s get a more complete (Rx joke) understanding of how FlatMap works by exploring complete and error events.

Completions

It’s easy to start things, hard to complete them.

This saying is very true for FlatMap. In a nutshell, the CI will receive the completed event once all “active” observables in the chain have completed.

Let’s look at an example where, after some normal operation, only the project stops. Will the CI stop?

project.addDeveloper(jim) // Jim started coding... project.stop() project.addDeveloper(bob) bob.pushCommit("1") jim.pushCommit("2") // CI is building Commit(author: "Jim", hash: "2").

Completing the Project (Parent Observable)

No, the CI doesn’t stop. After the project stops, adding Bob has no effect because developerStream has already completed so he’s never “activated” in the flatMap. Thus, when Bob pushes a commit, the CI doesn’t see it. However, existing project members like Jim are free to continue pounding away and pushing commits which do get built by the CI.

Now let’s examine when, instead of the project stopping, every developer on the project stops. Will the CI stop?

project.addDeveloper(jim) // Jim started coding... project.addDeveloper(anna) // Anna started coding... jim.stopCoding() anna.stopCoding() jim.pushCommit("1") project.addDeveloper(bob) // Bob started coding... bob.pushCommit("2") // CI is building Commit(author: "Bob", hash: "2").

Completing the Developers (Child Observables)

No, the CI doesn’t stop. As shown, when all the project’s developers stop, it affects neither the CI nor the project. Bob is still able to join the project afterwards and push commits which the CI builds.

The only way to stop the CI’s subscription is to stop the project and all existing developers:

project.addDeveloper(jim) // Jim started coding... project.addDeveloper(anna) // Anna started coding... project.stop() jim.stopCoding() anna.stopCoding() // CI stopped. project.addDeveloper(bob) bob.pushCommit("1") jim.pushCommit("2")

Completing the CI’s Subscription

It’s worth noting here that if no developers are ever added to the project, calling project.stop() would also stop the CI.

Errors

error events work as expected. When either the project or any added developer errors, the CI will receive the error event and the whole chain stops working.

Conclusion

Now that we know how FlatMap actually behaves, we’re able to use it with more confidence and in the right places.

The easiest way to play with this code (or any RxSwift code) on your own is to use the RxSwift repo’s playground. To get a closer look at things, including when the isDisposed event is being emitted, you may want to add this code to the playground along with some debug operators.

Acknowledgements

I’d like to thank Eli Burnstein for helping shape and edit this article, Deyu Wang for creating the visual animation, and everyone on my project team for helping me better understand FlatMap.

[zxsu]

A good place to learn RxJS with a good category and better live code examples.

[nodejsdevelopment-blog]

ReactiveX Web and Mobile Application Development Company in India (RxJS)

ReactiveX

Reactive Application Development Company in India (RxJS)

Reactive Application Development

Why to use ReactiveX (RxJS) ?

One question you may ask yourself, is why RxJS  What about Promises? Promises are good for solving asynchronous operations such as querying a service with an XMLHttpRequest , where the expected behavior is one value and then completion. The Reactive Extensions for JavaScript unifies both the world of Promises, callbacks as well as evented data such as DOM Input, Web Workers, Web Sockets. Once we have unified these concepts, this enables rich composition.

What is ReactiveX ?

ReactiveX is a library for composing asynchronous and event-based programs by using observable sequences.

It extends the observer pattern to support sequences of data and/or events and adds operators that allow you to compose sequences together declaratively while abstracting away concerns about things like low-level threading, synchronization, thread-safety, concurrent data structures, and non-blocking I/O.

It is sometimes called “functional reactive programming” but this is a misnomer. ReactiveX may be functional, and it may be reactive, but “functional reactive programming” is a different animal. One main point of difference is that functional reactive programming operates on values that change continuously over time, while ReactiveX operates on discrete values that are emitted over time.

Why Use Observables?

The ReactiveX Observable model allows you to treat streams of asynchronous events with the same sort of simple, composable operations that you use for collections of data items like arrays. It frees you from tangled webs of callbacks, and thereby makes your code more readable and less prone to bugs.

///Declare an observable public ISubject<MouseEventArgs> MouseMove; ///Publish data MouseMove.OnNext(args); ///Subscribe to an observable MouseMove.Subscribe(args => Display(args));

What all apps can be benefitials using RxJS ?

Stock quote

Tweets

Computer events

Video Streaming apps

Live feeds/News apps

Geo-location tracking

Web service requests, etc.

Reactive Programming

ReactiveX provides a collection of operators with which you can filter, select, transform, combine, and compose Observables. This allows for efficient execution and composition.

You can think of the Observable class as a “push” equivalent to Iterable, which is a “pull.” With an Iterable, the consumer pulls values from the producer and the thread blocks until those values arrive. By contrast, with an Observable the producer pushes values to the consumer whenever values are available. This approach is more flexible, because values can arrive synchronously or asynchronously.

Write us for more information at

[email protected]

http://www.linkites.com

Reactive Application Development

Software Development Company

Reactive Programming  

#reactive #reactivex #reactiveprogramming #linkites #softwaredevelopmentcompany #softwaredevelopment #softwarecompany #india #ReactiveExtensions #Rxjs #androidrxjava #reactiveapplicationdevelopment #reactiveapps #reactivewebapps  #Webapplication #indore

[papirtigris]

An API for asynchronous programming with observable streams

[maximalartzone]

You can't observe me I'm not an Observable http://goo.gl/EHfDqL #sticker #observable #rxjs #reactivex #javascript

[zxsu]

ReactiveX Operations Table of Contents Resources ReactiveX Operations Sample Source code 1 Resources http://ift.tt/14szmWqhttp://ift.tt/1O34Pkjhttp://ift.tt/1zXz2Mz 2 ReactiveX Operations To understand ReactiveX, We must consider everything as a stream, after that, the operations of ReactiveX stream was so complicated, that we can trade them as a new language, which operates the stream. The ReactiveX's Official document classify its operations as following categories: Creating Observables Transforming Observables Filtering Observables Combining Observables Error Handling Operations Observable Utility Operators Conditional and Boolean Operators Mathematical and Aggregate Operators BackPressure Operators Connectable Observable Operators Operators to Convert Observables Beside above categories, ReactiveX also provides the strategy to practice those operations, a decision Tree of Observable Operators. 3 Sample Source code A snapshot of source code is worth a bunch of theory. So I write some boilerplate code to illustrate How above operations to running in code. http://ift.tt/1Ssn2dT At the time of those writing, I just wrote the RxJava implementation, and I will add more codes for another Language implementation.