Saturday, September 20, 2014

How to be good learner

Tuesday, August 19, 2014

Từ tính toán thông minh đến Marketing Automation trong thời đại Big Data

Đây là 1 chủ đề hơi khô khan, nó thích hợp hợp cho dân academics (PhD, Master,,..) hơn 1 engineer như mình (vốn thích làm thực tế, coding và ứng dụng hơn là viết paper và chém gió #_# ), nhưng trí tưởng tượng là một thói quen khó bỏ.

Mới nhận cuốn sách Social Physics từ Amazon shipping về hôm qua , đây là cuốn sách mới nhất của giáo sư Alex Pentland, một trong 7 data scientist hàng đầu trong lĩnh vực Big Data. Nó có khá nhiều thông tin, ý tuởng và mô hình tóan hấp dẫn. Bài blog sẽ ghi lại các suy nghĩ , ý tuởng sau khi đọc vài chuơng chính.

Mục đích bài blog: đưa ra các vấn đề khi xã hội ngày càng số hóa (từ PC đến smartphone, Internet Of Things), ý tuởng và cách thức để xây dựng một hệ thống marketing thông minh (smarter marketing by big data) để hiểu rõ và can thiệp cơ chế luân chuyển giá trị (money), các patterns sử dụng data của con nguời trên Social Network (GS.Alex Pentland gọi đó là Social Physics). Điều này sẽ vô cùng có giá trị nếu kết hợp với các hệ thống kinh doanh online

Câu hỏi số 1: Sẽ như thế nào nếu linh hồn (your mind) và cái tôi của chính bạn được số hóa (Digitizing) ?

Tính cách, nhu cầu, hành vi, … của bạn được chuyển từ thế giớ thực (vật lý) sang thế giới của những con số bit và byte (digitization, matrix, Internet, social media, …) và nó sẽ phản hồi lại những thông tin có ích với bạn như thế nào ?

Trước hết là vấn đề ứng dụng và mô hình kinh doanh:

Trong 1 nền kinh tế ngày càng được số hóa, tất yếu các phương tiện (media) sẽ được phát triển (có cầu thì sẽ có cung). Dù bạn làm dịch vụ gì trên Internet (games, truyền thông, mạng xã hội, …) mục đích cuối cùng cũng là phục vụ khách hàng tốt hơn (vì họ mới thực sự là người trả lương cho bạn).

Để hiểu được khách hàng, theo 1 cách thủ công (sale offline) công ty cần có 1 đội làm dịch vụ chăm sóc khách hàng (CRM). Việc này có thể hiểu như là thu thập, lắng nghe và lưu thông tin khách hàng 1 cái database. Sau đó là các công việc tối ưu thông tin từ nhu cầu (feedback, demand) đến team manager và cuối cùng là cung ứng (supply) 1 sản phẩm mới.

Đối với 1 hệ thống để phân tích cung – cầu trực tuyến, nhu cầu về 1 độ trễ ngày càng thấp (near-real-time or real-time) là tất yếu. Thế giới số hóa thì cạnh trạnh bằng 2 thứ chính là : thông tin (Google có search-engine) và tốc độ đưa thông tin (và Google trả kết quả rất nhanh).

Ví dụ: Ngân hàng, bất động sản sẽ không thất bại nếu họ chịu khó lắng nghe khách hàng nhiều hơn (nhà nhiều và ai có khả năng và nhu cầu đây). Tham khảo thêm: http://socialphysics.media.mit.edu/2014/01/20/ecology-and-topology-in-the-financial-world

Không phải tự nhiên mô hình Agile trong software sinh ra, vì đơn giản thế giới thay đổi rất nhanh, nhu cầu thay đổi. Những quy trình làm software kiểu cũ (6 tháng release) sẽ không thể thích ứng linh hoạt theo nhu cầu phát triển sản phẩm ngày càng nhanh (fail).

Một đất nước sẽ không sụp đổ nếu họ phản ưng nhanh, thay đổi để đáp ưng với nhu cầu của người dân và tình hình (kinh tế, xã hội, …)

Tới đây, hi vọng bạn đã hiểu các bài toán kinh doanh và các vấn đề phát sinh cho một xã hội cần real-time hơn các thông tin giá trị.

Trong suốt các quá trình lịch sử của con nguời, khả năng thích nghi với môi truờng (context), sao chép (cloning) và cải tiến (innovation) là cách đơn giản mà mọi xã hội phát triển và tiến hóa.

“It is not the strongest of the species that survives, nor the most intelligent, but the one most responsive to change.”

Charles Darwin

Vấn đề công nghệ để hiện thực ý tuởng này như thế nào ?

User sẽ tương tác và tiếp nhận thông tin qua các thiết bị có kết nối Internet.
HTTP Service Layer sẽ tiếp nhận các thông tin của user cung cấp (feedback, click, like, comment, add photo, read a article, …)
Các entity thông tin sẽ chuyển qua 1 dịch vụ fuzzy-hash, nó giống như 1 hàm hash nhưng sử dụng tính toán fuzzy logic
Kết quả nó chuyển các thông tin user đến thế giới của các actors (http://en.wikipedia.org/wiki/Actor_model)
Nói đơn giản, actor là đối tương tính toán gọn nhẹ gồm có 2 thuộc tính là trạng thái (state) và hành vi (behavior ). Bạn có thể code nó thao tác với dữ liệu (Redis, mySQL, …). Gọi các actor khác nhau, 1 actor có thể 1 hàm tối ưu hành vi cho việc mua sắm, xem tin tức, đọc 1 sách, xem phim, … tính toán các mô hình xác xuất, đưa khả năng và bỏ vào 1 mailbox. 1 đối tượng khác sẽ đọc mailbox để show các thông tin mà user mong muốn có thể thấy,biết, nghe, …
Về phần hiện thực, bạn có thể dùng framework này, http://akka.io

Mình đã hiện thực một hệ thống để tìm các xu huớng xã hội ở mức độ near-real-time với nền tảng công nghệ Rfx, sample Java code, https://github.com/mc2ads/rfx/blob/master/rfx-stream/src/test/java/rfx/sample/social/tracking/TrackingUserTopology.java

Ý tuởng quan trọng chính là mô tả các mối quan hệ thông tin bằng hàm xác xuất / hàm số giữa các đối tuợng tạo ra data (actor / consumer ) và các object mang thông tin (VD: 1 chai Cocacola).

Điều này có ý nghĩa trong hệ thống marketing thông minh, nơi gía trị thật của mối quan hệ giữa nguời tiêu dùng và mặt hàng luôn không rõ ràng. Giá trị (value) đuợc mô tả bằng 1 đối tuợng hàm functor (có khả năng tính tóan từ các data và tham số) sẽ phản tính dynamic của hệ thống hơn.

Sandy Pentland: "Social Physics: How Good Ideas Spread" | Talks at Google

Các cuốn sách thú vị khác cùng chủ đề:

Wednesday, April 9, 2014

Introduction to FRP - Why Applicative Functors?

Many if not all FRP (Functional Reactive Programming) libraries, reactive-banana included, export an API that is based on functors, applicative functors or other higher-kinded types like arrows. This section explains why that is and what it means for the novice Haskell programmer.

The idea of time-varying values

The two main data types of the reactive-banana library are behaviors and events. The type constructor Behavior represents a time-varying value, i.e. you can think of it as a function

type Behavior a = Time -> a

On the other hand, the type constructor Event represents a sequence of event occurrences. Think of it as a list

type Event a = [(Time,a)]

Pictorially, you could represent them like this: a behavior traces the evolution of a value over time

while an event consists of several, possibly simultaneous event occurrences.

The promise of functional reactive programming is that these two notions allow you to code interactive programs like animations, graphical user interfaces (GUI) and so on much more easily and declaratively than previously possible. Indeed, representing, say, the position of a player character on the screen as a function of time is a remarkable and powerful idea. Of course, you can only fathom this idea if you are used to programming languages with first-class functions.

Now, you could just take these two type definitions above and use them to code animations to your heart’s content; after all, they are legal Haskell code. This is pretty much what Conal Elliott and Paul Hudak did in their seminal paper “Functional Reactive Animation”. Unfortunately, the computational costs of this approach are prohibitive. While trading clock cycles for expressivity is often worth it, the costs here are much more than a constant factor. A direct implementation is simply not practical.

Abstraction and combinators

The solution to the problem above is, of course, abstraction. The FRP library gives us two data types Behavior and Event which behave very much like the definitions above. Internally, however, the library represents them very differently. But as long as these types behave as we desire, the difference is of no concern to us.

More precisely, the library not only gives us two types constructors Behavior and Event, but also a carefully chosen set of combinators (functions) for them. In reactive-banana version 0.2, the combinators are these:

filter  :: (a -> Bool) -> Event a -> Event a
accumE  :: a -> Event (a -> a) -> Event a
stepper :: a -> Event a -> Behavior a
apply   :: Behavior (a -> b) -> Event a -> Event b

instance Functor Event
instance Functor Behavior
instance Applicative Behavior
instance Monoid (Event a)

As you can see, some of the combinators are actually given by type class instances.

The deal with combinators is this: you may still think of Behavior as a function Time -> a, but you may no longer define a behavior directly, like b = \t -> 2*t. Instead, you may only use the combinators above to define new behaviors. This restriction to a certain set of functions is what guarantees an efficient implementation.

Some of these combinators, namely the type classes instances, belong to very general abstractions, like functor, applicative functor and monoid. They are applicable (pun intended) far beyond FRP, so understanding will pay off for other things as well. This is no surprise: every higher-kinded type, i.e. a type with a parameter, is simply very likely to belong to some of the abstractions here. Monads would be another common example, but it just so happens that they don’t show up in reactive-banana.

To learn more about applicative functors and the other type classes, have a look at Brent Yorgey’s Typeclassopedia. Understanding applicative functors is also very useful for understanding the apply combinator.

So much for the general philosophy behind every FRP library. The specific meaning and utility of the combinators in the reactive-banana library will be explained subsequently.

Heinrich Apfelmus
Fri, 06 May 2011 19:34:31 +0200

Source: http://apfelmus.nfshost.com/blog/2011/05/06-frp-why-functors.html