Category: Do

Authentication & WebView & React Native

May 29, 2019 by Hien Nguyen·Comments Off

You have an idea. You already had a responsive web app, it works well for mobile. It leads you to the thought of having a MVP mobile app to engage users: an app is built by embedded web-view. You also know React Native can help you build a cross-platform app. Very good solution: a React Native app with few WebView screens that point to correct links. Life is so easy, right? Unfortunately, it’s not.

Problems

You are right. It’s a great solution until you need to implement the authentication. There are at least 2 problems if your app requires user login.

Firstly, “remember me” doesn’t work although it works well on web. You need to enter credential whenever the app opens (in cold start).

Secondly, 3rd party authenticators like Google, Facebook… doesn’t work. You tap on “Login by Facebook”, Facebook login page is opened inside the app. Although you already logged in on Facebook app or OS browser, you need to enter Facebook credential whenever the app opens.

The reason is that WebView doesn’t share any data with OS browser. Each time the app starts, a “fresh” browser is initiated. It means there is no cookies, token, history… are stored by default.

There is only one weird function on your app while the rest are working perfectly. Yes, only one. But it kills your whole app. Do you know anyone who is willing to type username & password anytime he opens the app? Yes, if the app relates to very sensitive personal data like personal finance. But your app doesn’t.

Solutions

There are many solutions. I will describe the simplest one with less code change in your existing web app.

Facebook login

Let’s firstly solve the problem with 3rd party authenticators. I use Facebook as an example, you could treat others in the same way. The steps could be:

Handle event in WebView to detect user tapping on Facebook login button
Open client Facebook login, get the access token
Pass token to server to authenticate user

First step is setting up the Facebook SDK, please follow here: https://github.com/facebook/react-native-fbsdk

Second step is handling user tapping on Facebook login link on app, onNavigationStateChange of WebView is the good function to work on. Passing the token to server could be simply made by GET calling from WebView.

The code looks like:

import React from 'react';
import { View, ActivityIndicator } from 'react-native';
import { WebView } from 'react-native-webview'
import { LoginManager, AccessToken } from "react-native-fbsdk";

class App extends React.Component {
  webViewRef;
  constructor(props) {
    super(props);
    this.state = {
      facebookToken: null
    };
  }

  onNavigationStateChange(navState) {
    var url = navState.url;
    var self = this;

    if (url.includes('facebook.com')) {
      webViewRef.stopLoading();
    }

    if (url.includes('https://facebook.com') || url.includes('https://www.facebook.com')) {
      LoginManager.logOut()
      LoginManager.logInWithReadPermissions(["email", "public_profile", "user_link"]).then(
        function (result) {
          if (result.isCancelled) {
            if (webViewRef.canGoBack()) 
              webViewRef.goBack();

            self.setState({
              facebookToken: null
            })
          } else {
            AccessToken.getCurrentAccessToken().then(
              (data) => {
                self.setState({
                  facebookToken: data.accessToken.toString(),
                })
              }
            )
          }
        },
        function (error) {
          if (webViewRef.canGoBack()) 
            webViewRef.goBack();

          self.setState({
            facebookToken: null
          })
        }
      );
    }
  }

  render() {
    return (
        <View>
          <WebView ref={WEBVIEW_REF => (webViewRef = WEBVIEW_REF)}
              source={{ uri: (this.state.facebookToken) ? "https://yourcompany.com/FacebookNativeLogin?accessToken=" + this.state.facebookToken : "https://yourcompany.com/Login" }}
              onNavigationStateChange={this.onNavigationStateChange.bind(this)}
            />
        </View>
    );
  }
}

export default App;

import React from 'react';

import { View, ActivityIndicator } from 'react-native';

import { WebView } from 'react-native-webview'

import { LoginManager, AccessToken } from "react-native-fbsdk";

class App extends React.Component {

webViewRef;

constructor(props) {

super(props);

this.state = {

facebookToken: null

};

}

onNavigationStateChange(navState) {

var url = navState.url;

var self = this;

if (url.includes('facebook.com')) {

webViewRef.stopLoading();

}

if (url.includes('https://facebook.com') || url.includes('https://www.facebook.com')) {

LoginManager.logOut()

LoginManager.logInWithReadPermissions(["email", "public_profile", "user_link"]).then(

function (result) {

if (result.isCancelled) {

if (webViewRef.canGoBack())

webViewRef.goBack();

self.setState({

facebookToken: null

})

} else {

AccessToken.getCurrentAccessToken().then(

(data) => {

self.setState({

facebookToken: data.accessToken.toString(),

})

}

)

}

function (error) {

if (webViewRef.canGoBack())

webViewRef.goBack();

self.setState({

facebookToken: null

})

}

);

}

render() {

return (

<View>

<WebView ref={WEBVIEW_REF => (webViewRef = WEBVIEW_REF)}

source={{ uri: (this.state.facebookToken) ? "https://yourcompany.com/FacebookNativeLogin?accessToken=" + this.state.facebookToken : "https://yourcompany.com/Login" }}

onNavigationStateChange={this.onNavigationStateChange.bind(this)}

</View>

);

}

export default App;

There are some notes:

Line 20: we should let WebView stop loading to avoid strange UI: a popup of Facebook login on app on the top of Facebook web login screen (on app). It also stops WebView being redirected from https://facebook.com to https://m.facebook.com that lets the popup show twice.
Line 24: Facebook LoginManager caches the access token, calling logOut() before logInWithReadPermissions() helps app detects if user logout the app from other Facebook areas (web etc).
Line 64: you need to implement FacebookNativeLogin on server side then setting cookies etc.

Now it works? Yes, but not really. User is still required to press Facebook login when he opens the app. If you want “auto login”, componentDidMount could be a simple solution.

componentDidMount() {
  var self = this;
  AccessToken.getCurrentAccessToken().then(
    (data) => {
      if (data && data.accessToken) {
        self.setState({
          facebookToken: data.accessToken.toString(),
        })
      } else {
        self.setState({
          facebookToken: null
        });
      }
    }
  );
}

componentDidMount() {

var self = this;

AccessToken.getCurrentAccessToken().then(

(data) => {

if (data && data.accessToken) {

self.setState({

facebookToken: data.accessToken.toString(),

})

} else {

self.setState({

facebookToken: null

});

}

);

}

Remember me

Now it’s time for “remember me” function. The common solution is using the cookies. If you already had it running for web, your hands wouldn’t be much dirty. There is a simple solution with CookieManager, you could find it here: https://github.com/joeferraro/react-native-cookies

Well, let’s combine it with componentDidMount above:

componentDidMount() {
  CookieManager.get('https://yourcompany.com').then((res) => {
    if (res['.App.ApplicationCookie']) {
      this.setState({
        loggedIn: true,
        facebookToken: null
      });
    } else {
      var self = this;
      AccessToken.getCurrentAccessToken().then(
        (data) => {
          if (data && data.accessToken) {
            self.setState({
              loggedIn: true,
              facebookToken: data.accessToken.toString(),
            })
          } else {
            self.setState({
              loggedIn: false,
              facebookToken: null
            });
          }
        }
      )
    }
  });
}

componentDidMount() {

CookieManager.get('https://yourcompany.com').then((res) => {

if (res['.App.ApplicationCookie']) {

this.setState({

loggedIn: true,

facebookToken: null

});

} else {

var self = this;

AccessToken.getCurrentAccessToken().then(

(data) => {

if (data && data.accessToken) {

self.setState({

loggedIn: true,

facebookToken: data.accessToken.toString(),

})

} else {

self.setState({

loggedIn: false,

facebookToken: null

});

}

)

}

});

}

Some notes:

Line 3: replace it with your correct cookies
Line 5: I introduce loggedIn state because Facebook login is separated with your system username/password login. It lets you update uri in WebView of render() function above with a condition combined by loggedIn and facebookToken. But it’s not difficult, right? Hmm, loggedIn isn’t a good name.

Done? Almost. You could see it works really well on Android but not on iOS. In cold start, CookieManager.get() returns value on Android but doesn’t on iOS. Then storing and restoring cookies programmatically is a solution. AsyncStorage could help https://facebook.github.io/react-native/docs/asyncstorage.html. Just add the few lines of code to onNavigationStateChange to store the cookie and set it back on componentDidMount. Fortunately, CookieManager.set() only works on iOS.

Know issues

I hope it help you overcome the common issue of web-view app. I don’t want to put the setting cookies into existing functions because they are too long now. You should refactor it after getting it run.

Is the solution simple? Yes. Is it perfect? No. There are some small issues:

We call GET to FacebookNativeLogin with accessToken. Might POST be a bit better?
What if the cookies is expired? Is it good to still keep user login? A solution is storing username/password by AsyncStorage and injecting Javascript to auto fill username/password text fields. But I don’t prefer storing any data like that.

But if you are interested in those topics, I will go into the example next post.

377 total views, 4 views today

Singleton: dùng hay không?

May 23, 2018 by Hien Nguyen·Comments Off

Nhân tiện mọi người có vẻ hào hứng về chủ đề nho nhỏ này và đang viết được, viết nôt kẻo ít hôm lại lười.

Trả lời ngắn gọn là dùng. Dùng chứ. Nhưng dùng thế nào cho đúng thì phải hiểu rõ một chút. Bài viết này cố gắng cung cấp nhiều góc nhìn để cân nhắc.

Vì sao ra đời?

Trong GoF, Singleton được đưa ra với mục đích sau: “Ensure a class only has one instance, and provide a global point of access to it.” – “Đảm bảo một class chỉ có duy nhất một instance, và cung cấp một điểm truy cập duy nhất trên toàn cục tới instance.”

Cái gì hay?

Hay thì rõ rồi, nó cung cấp ý tưởng của việc một instance duy nhất, điều mà chúng ta gặp trong nhiều bài toán thực tế: một ứng dụng được khởi tạo, một cấu hình hệ thống, một logger… Tôi cá là nhiều người không biết tới Singleton thì không biết giải quyết bài toán này thế nào.

Runtime:
- Không giống như static trong class, object và các giá trị trong đó chỉ được khởi tạo khi cần thiết. Memory và cả CPU đều được tiết kiệm.
- Cho phép chủ động quản lý life cycle, giải phóng khi cần thiết.
Design:
- Abstract hơn sử dụng static trong class;
- Có khả năng thừa kế;
- Có thể kếp hợp với những design pattern khác.

Cái gì dở?

Dở thì cũng có, bởi vậy mới có nhiều tranh luận.

Tư tưởng: Singleton trong GoF dở cơ bản về tư tưởng bởi nó giải quyết 2 bài toán khác nhau (dù có vẻ liên quan): “Ensure a class only has one instance, and provide a global point of access to it.”
- Một class có duy nhất một instance;
- Cung cấp một điểm truy cập duy nhất trên toàn cục tới instance.
- Tác giả đã vô tình kèm cả lời giải trong bài toán với giả định: để có một điểm truy cập toàn cục duy nhất thì chỉ có duy nhất một instance được tạo ra từ một class. Bài toán “một điểm truy cập” có thể được giải quyết bởi Facade, Wrapper… không nhất thiết phải là Singleton.
Design:
- Coupling: Vì là global state nên các thành phần bị gắn chặt với nhau;
- Khó / không thể viết test;
- Viết dễ sai sót, để lại lỗ hổng (xem bài trước Singleton có thực sự dễ?).
Runtime:
- Không “thân thiện” với theading.

Nên dùng thế nào?

Như vậy, ta thấy rằng đa phần những thứ dở của design pattern này là ở tư tưởng global state. Vậy nên những ai yêu thích functional programming thì sẽ rất anti-pattern này. Cũng đúng thôi, GoF sinh ra cho OOP, không phải FP. Và thời đại của GoF (1994) cũng không quan tâm nhiều tới concurrency – bài toán trở thành rất cơ bản trong thời đại này. Bởi vậy, việc sử dụng Singleton có chút thay đổi. Có 3 điều cần chú ý:

Concurrency: Global state là điều tệ hại cho concurrency. Hãy giảm thiểu tối đa nếu có thể. Global state bẻ cong cách suy nghĩ về luồng và gây mệt mỏi cho việc debug trong concurrency. Nếu bạn muốn thiết kế hệ thống tối ưu hiệu năng và concurrency thì không sử dụng Singleton cũng là một ý hay.
Memory:
1. Lưu cái gì? Global state cũng là một ý hay vì khiến việc thiết kế và lập trình dễ dàng hơn, nó chỉ không hay khi bạn không cân nhắc tới nên lưu gì. Rất nhiều thứ có thể nhìn dưới góc độ một instance nếu chúng ta không có khả năng khái quát hoá. Logger là Singleton không? Hay có errorlog, accesslog? Database là single thì lưu cả database? Hay chỉ connection? Hay chỉ connectionString? Lưu ít nhất có thể.
2. Lưu khi nào? Nhiều người hay gắn Singleton với life cycle của cả ứng dụng, kèm theo việc lưu trữ nhiều, hoặc giữ strong reference dẫn đến GC không thể hoạt động; sớm muộn gì cũng gây ra memory leak. Khởi tạo muộn nhất có thể, giải phóng sớm nhất có thể.
Language: Cần lưu ý cách sử dụng trong từng ngôn ngữ (xem bài trước Singleton có thực sự dễ? và Singleton:threading() in Java), mỗi ngôn ngữ khác nhau sẽ có vấn đề khác nhau. Dù design pattern là mức thiết kế song đừng mang nguyên cách cài đặt từ ngôn ngữ này sang ngôn ngữ khác, hãy nhìn vào diagram và đặc trưng ngôn ngữ.

Trên đây là một số góc nhìn, gợi ý để bạn dùng Singleton đúng hơn. Không có đúng hay sai khi dùng Singleton, dùng đúng hay không mới là vấn đề.

1,682 total views, 5 views today

Singleton.threading() in Java

May 23, 2018 by Hien Nguyen·Comments Off

Bài trước về Singleton có thực sự dễ, tôi nhận được vài comment rất chuẩn về cách cài đặt xử lý với theading. Vì bài trước tập trung nói về Singleton và các vấn đề có thể gặp phải với reflection, threading, serializable… nên tất cả những giải pháp đưa ra chỉ dừng ở mức ý tưởng không làm bạn đọc phân tâm. Bài này nói rõ hơn về xử lý theading khi cài đặt Singleton.

Tôi sẽ đi vào cài đặt “chuẩn” đã đưa cuối bài Singleton có thực sự dễ trước:

public class AppConfig {
    private static volatile AppConfig self;
    
    private AppConfig() {
        if (self != null) { 
            throw new UnsupportedOperationException("Use getInstance()"); 
        }
    } 
    
    public static synchronized AppConfig getInstance() {
        if (self == null) {
            self = new AppConfig();
        }
        return self;
    }
}

public class AppConfig {

private static volatile AppConfig self;

private AppConfig() {

if (self != null) {

throw new UnsupportedOperationException("Use getInstance()");

}

public static synchronized AppConfig getInstance() {

if (self == null) {

self = new AppConfig();

}

return self;

}

Khi phân tích về threading trong bài trước bạn thấy tôi viết “Vậy nên cần phải synchronized việc tạo object.”. Nếu để ý kỹ, có 2 phần thay đổi:

synchronized được thêm vào method getInstance()
volatile được thêm vào self (phần này được tôi lờ đi)

Có mấy vấn đề ở đây liên quan tới threading bạn nên biết.

synchronized cần phải tối thiểu

Cần phải khẳng định ngay rằng cách viết trên cho hiệu năng rất thấp. synchronized sẽ thực hiện việc lock method khiến các thread không thể invoke method song song, chúng buộc phải invoke tuần tự. Nếu có 100 thread gọi getInstance(), thread thứ 100 sẽ nhận được object AppConfig sau khi 99 thread trước đã hoàn thành. Sẽ tốt hơn nếu object AppConfig được tạo ra bởi thread đầu tiên, 99 thread còn lại có thể đồng thời được nhận lại object AppConfig.

Double check locking nên được sử dụng trong trường hợp này. Double check locking là một design pattern phổ biến trong bài toán về threading, kiểm tra lock trước khi thực sự lock method (theo nguyên lý return as soon as possible).

public static synchronized AppConfig getInstance() {
    if (self == null) {
        synchronized (AppConfig.class) {
            if (self == null) {
                self = new AppConfig();
            }
        } 
    }
    return self;
}

public static synchronized AppConfig getInstance() {

if (self == null) {

synchronized (AppConfig.class) {

if (self == null) {

self = new AppConfig();

}

return self;

}

if (self == null) được thực hiện 2 lần, nên pattern này được gọi là double check. Đừng bỏ câu lệnh thứ 2 nếu bạn không muốn một hệ quả tai hại (100 object được tạo ra… tuần tự, tại sao?). Đấy là lý do tôi muốn synchronized cả method để ai đọc cũng hiểu.

Chỉ lock những statement thực sự cần thiết và không nhiều hơn mức cần thiết là nguyên lý cơ bản của threading.

synchronized vẫn chưa đủ

Ngay cả khi bạn không bỏ đi câu lệnh if (self == null) nào, vẫn có thể có hàng chục object AppConfig được tạo ra.

(http://tutorials.jenkov.com/images/java-concurrency/java-volatile-1.png)

Hãy nhớ, máy tính có đến mấy loại bộ nhớ, nên việc đảm bảo dữ liệu đồng nhất không dễ. Lan man 1 chút về kiến trúc máy tính qua hình trên:

Main memory là RAM.
CPU xử lý dữ liệu được nạp vào bộ nhớ của CPU, không phải RAM. Bởi vậy dữ liệu được sao chép theo trình tự RAM -> Lx ->… -> L2 -> L1 cache. Trong lúc đấy hàng triệu thứ đã xảy ra.
Tưởng tượng, counter là self, khi 2 thread bắt đầu, self = null, được copy vào cache. Sau đó dù có synchronized thì 2 CPU vẫn lấy giá trị trên 2 cache độc lập để ra quyết định. Kể cả sau khi xử lý xong, giá trị vẫn được giữ trên cache đến khi thực sự cần đưa xuống RAM.

Vậy là ta phải dùng volatile để giá trị của biến luôn được tham chiếu tới RAM khi thay đổi. Vậy đây là giá trị duy nhất.

Còn cách nào khác không?

Nếu để ý, bạn thấy volatile trở nên vô dụng khi ta lock toàn bộ method. Tức là cách cài đặt của tôi ở cuối bài trước là rất ngớ ngẩn. Thật ra tôi cố tình viết vậy, ai không hiểu về threading thì vẫn có giải pháp chạy đúng; người hiểu biết về threading thì có hint đi tiếp.

Tôi không muốn đi sâu vào threading vì vấn đề này phụ thuộc ngôn ngữ, nền tảng. Hy vọng bạn hiểu rằng một design pattern đơn giản như Singleton cũng cần cài đặt cẩn thận và hiểu biết sâu sắc.

Kết

Có 2 vấn đề muôn thưở của lập trình: performance và memory. Bài này đề cập tới performance. Một số comment khác về việc không quản lý tốt life cycle khi sử dụng Singleton gây ra memory leak. Tôi sẽ cố gắng viết sau.

Và đừng hỏi tại sao lập trình lại phải biết kiến trúc máy tính. Bởi vì code không chạy trên máy tính thì chạy ở đâu? Nền tảng quan trọng lắm.

1,127 total views, 1 views today

Singleton có thực sự dễ?

May 21, 2018 by Hien Nguyen·Comments Off

Khi nói về Design Patterns, gần 100% những người tôi tiếp xúc đều thực hành Singleton như một design pattern phổ biến và dễ nhất (nhiều người chỉ biết/nhớ mỗi Singleton trong GoF). Tôi thường có 2 câu hỏi:

Sử dụng Singleton và static trong class có gì khác nhau?
Có tự tin cài đặt đúng Singleton?

Thường thì mọi người gặp khó khăn ở câu hỏi #1, và rất chắc chắn ở câu hỏi #2. Tôi thấy, #2 khó hơn #1 nhiều, và nếu bạn không tự tin trả lời #2 thì tôi khuyên bạn nên sử dụng static trong class thay vì Singleton. Tại sao? Đọc tiếp nhé.

Sử dụng Singleton và static trong class có gì khác nhau?

Nếu bạn chưa rõ về câu hỏi thì tôi giải thích thêm một chút: Mục đích của Singleton là tạo ra một object duy nhất trên toàn ứng dụng, kéo theo các thuộc tính của nó cũng là duy nhất; điều này hoàn toàn giống / có thể thực hiện bởi thuộc tính static của class – là nơi duy nhất lưu trữ dữ liệu. Ví dụ:

// Using Singleton 
public class AppConfig { 
    public int appId;
    private static AppConfig self;

    public static AppConfig getInstance() {
        if (self == null) {
            self = new AppConfig();
        }
        return self; 
    } 
}

config = AppConfig.getInstance();
appId = config.appId;

// Using Singleton

public class AppConfig {

public int appId;

private static AppConfig self;

public static AppConfig getInstance() {

if (self == null) {

self = new AppConfig();

}

return self;

}

config = AppConfig.getInstance();

appId = config.appId;

// Using static
public class AppConfig {
    public static int appId; 
}

appId = AppConfig.appId;

// Using static

public class AppConfig {

public static int appId;

}

appId = AppConfig.appId;

Cả 2 cách cài đặt trên, appId đều chỉ có một nơi duy nhất để lưu trữ và truy xuất giá trị. Sử dụng static theo #2 gọn và tường minh hơn, vậy cần gì Singleton?

Để ý một chút, một cách cài đặt sử dụng class, một cách sử dụng object. Có 2 sự khác nhau giữa class và object trong trường hợp này:

Life-time: Life cycle của class gắn với ứng dụng, life cycle của object gắn với việc sử dụng. Sử dụng static trong class, những thuộc tính này sẽ được load theo class khi chạy ứng dụng; sử dụng Singleton, những thuộc tính này sẽ được load chỉ khi object được khởi tạo. Trong cả 2 trường hợp, thuộc tính không được tự động giải phóng cho tới khi ứng dụng kết thúc. (do object vẫn có reference được giữ bởi self, tồn tại theo class).
Abstraction: Sử dụng static trong class là concrete implement, sử dụng object cho một tầng abstraction nữa nên dễ thay đổi hơn. Ví dụ, chúng ta cần thay đổi AppConfig sang WindowsAppConfig, theo #2, tất cả mọi nơi truy cập tới appId đều phải sửa đổi; theo #1, nơi duy nhất cần thay đổi là AppConfig.getInstance() (có thể không cần thay đổi nếu áp dụng với những design pattern khác như Factory, DI).

Chẳng có gì đặc biệt, lý thuyết thôi. Chính xác, và vì thế bạn vẫn cài đặt Singleton như đã học? Nhưng thử tìm hiểu thêm nhé.

Có tự tin cài đặt đúng Singleton?

Cài đặt Singleton thế nào?

Dễ ợt, có 2 việc:

Đặt constructor là private để object không thể khởi tạo được từ bên ngoài.
Cung cấp 1 method duy nhất trả về giá trị static

Code thường được cài đặt như sau:

public class AppConfig {
    private static AppConfig self;
    public int appId; 
    
    private AppConfig() {
    } 
    
    public static AppConfig getInstance() {
        if (self == null) {
            self = new AppConfig();
        }
        return self;
    }
}

// Use
AppConfig config = AppConfig.getInstance();
appId = config.appId;

public class AppConfig {

private static AppConfig self;

public int appId;

private AppConfig() {

}

public static AppConfig getInstance() {

if (self == null) {

self = new AppConfig();

}

return self;

}

// Use

AppConfig config = AppConfig.getInstance();

appId = config.appId;

Có một vài câu hỏi phía dưới.

Chỉ có đúng 1 object được tạo ra?

Bạn có chắc rằng với cách cài đặt trên chỉ có đúng 1 object có thể được tạo ra? Còn cách nào có thể tạo ra object không?

Reflection là một trong những thứ rất hay ho của một số ngôn ngữ (những ngôn ngữ khác nhau có thể có những tên gọi khác nhau: runtime reference…), và cũng là một thứ khó bởi nó nâng abstraction lên mức runtime. Những pattern như Object Mapper hay DI… không dễ cài đặt nếu không có reflection. Thử đoạn code sau nhé.

public class AppConfig {
    private static AppConfig self;
    public int appId; 
    
    private AppConfig() {
        appId = new Random().nextInt(100);
    } 
    
    public static AppConfig getInstance() {
        if (self == null) {
            self = new AppConfig();
        }
        return self;
    }
    
    public static void main(String[] args) {
        AppConfig config = AppConfig.getInstance();
        System.out.println(config.appId);
        
        AppConfig appConfig = null;
        try {
            Class<AppConfig> clazz = AppConfig.class;
            Constructor<AppConfig> constructor = clazz.getDeclaredConstructor();
            constructor.setAccessible(true);
            appConfig = constructor.newInstance();
        } catch (NoSuchMethodException | InvocationTargetException | IllegalAccessException | InstantiationException e) {
            e.printStackTrace();
        }
        System.out.println(appConfig.appId);
    }
}

public class AppConfig {

private static AppConfig self;

public int appId;

private AppConfig() {

appId = new Random().nextInt(100);

}

public static AppConfig getInstance() {

if (self == null) {

self = new AppConfig();

}

return self;

}

public static void main(String[] args) {

AppConfig config = AppConfig.getInstance();

System.out.println(config.appId);

AppConfig appConfig = null;

try {

Class<AppConfig> clazz = AppConfig.class;

Constructor<AppConfig> constructor = clazz.getDeclaredConstructor();

constructor.setAccessible(true);

appConfig = constructor.newInstance();

} catch (NoSuchMethodException | InvocationTargetException | IllegalAccessException | InstantiationException e) {

e.printStackTrace();

}

System.out.println(appConfig.appId);

}

Output của đoạn code trên thường sẽ là 2 số nguyên khác nhau, chính là appId. Về lý thuyết, appId chỉ được gán giá trị một lần duy nhất khi khởi tạo object. Như vậy đã có 2 object config và appConfig được tạo ra. Điều chúng ta mong muốn là config và appConfig là 2 biến cùng tham chiếu tới 1 object trong bất cứ trường hợp nào. Vậy nên giải pháp là kiểm soát constructor.

private AppConfig() {
    if (self != null) { 
        throw new UnsupportedOperationException("Use getInstance() to create object."); 
    }
    appId = new Random().nextInt(100);
}

private AppConfig() {

if (self != null) {

throw new UnsupportedOperationException("Use getInstance() to create object.");

}

appId = new Random().nextInt(100);

}

Chỉ có đúng 1 object được tạo ra?

Bạn có chắc rằng với cách cài đặt trên chỉ có đúng 1 object có thể được tạo ra? Còn cách nào có thể tạo ra object không?

Threading là một trong những thứ rất hay ho nhưng cũng làm đau đầu developer vì nó không đi theo flow thông thường. Thử đoạn code sau nhé.

public class AppConfig {
    private static AppConfig self;
    public int appId; 
    
    private AppConfig() {
        if (self != null) { 
            throw new UnsupportedOperationException("Use getInstance()"); 
        }
        appId = new Random().nextInt(100);
    } 
    
    public static AppConfig getInstance() {
        if (self == null) {
            self = new AppConfig();
        }
        return self;
    }
    
    public static void main(String[] args) {
        Thread threadDownload = new Thread(new Runnable() {
            @Override
            public void run() {
                AppConfig config = AppConfig.getInstance();
                System.out.println(config.appId);
            }
        });

        Thread threadUpload = new Thread(new Runnable() {
            @Override
            public void run() {
                AppConfig config = AppConfig.getInstance();
                System.out.println(config.appId);
            }
        });

        threadDownload.start();
        threadUpload.start();
    }
}

public class AppConfig {

private static AppConfig self;

public int appId;

private AppConfig() {

if (self != null) {

throw new UnsupportedOperationException("Use getInstance()");

}

appId = new Random().nextInt(100);

}

public static AppConfig getInstance() {

if (self == null) {

self = new AppConfig();

}

return self;

}

public static void main(String[] args) {

Thread threadDownload = new Thread(new Runnable() {

@Override

public void run() {

AppConfig config = AppConfig.getInstance();

System.out.println(config.appId);

}

});

Thread threadUpload = new Thread(new Runnable() {

@Override

public void run() {

AppConfig config = AppConfig.getInstance();

System.out.println(config.appId);

}

});

threadDownload.start();

threadUpload.start();

}

Hãy thử chạy một vài lần vì cơ hội gặp trường hợp hai số khác nhau được in ra thấp hơn ví dụ trên. Tương tự ví dụ trên, ta có thể khẳng định: có 2 object đã được tạo ra. Sai lầm ở đâu? Hãy để ý method getInstance(), điều gì xảy ra nếu câu lệnh if (self == null) được thực thi đồng thời ở cả threadDownload và threadUpload? Chúng đều đúng, và câu lệnh tạo object và return vẫn được tiếp tục trên 2 thread độc lập, và trả ra 2 object độc lập. Vậy nên cần phải synchronized việc tạo object.

public class AppConfig {
    private static volatile AppConfig self;
    public int appId; 
    
    private AppConfig() {
        if (self != null) { 
            throw new UnsupportedOperationException("Use getInstance()"); 
        }
        appId = new Random().nextInt(100);
    } 
    
    public static synchronized AppConfig getInstance() {
        if (self == null) {
            self = new AppConfig();
        }
        return self;
    }
}

public class AppConfig {

private static volatile AppConfig self;

public int appId;

private AppConfig() {

if (self != null) {

throw new UnsupportedOperationException("Use getInstance()");

}

appId = new Random().nextInt(100);

}

public static synchronized AppConfig getInstance() {

if (self == null) {

self = new AppConfig();

}

return self;

}

Chỉ có đúng 1 object được tạo ra?

Bạn có chắc rằng với cách cài đặt trên chỉ có đúng 1 object có thể được tạo ra? Còn cách nào có thể tạo ra object không?

Serializable có thể là một vấn đề. Chúng ta muốn lưu lại cấu hình AppConfig xuống file sau đó load lại khi cần. Thử đoạn code sau nhé.

public class AppConfig implements Serializable {
    private static volatile AppConfig self;
    public int appId;
    
    private AppConfig() {
        if (self != null) { 
            throw new UnsupportedOperationException("Use getInstance()"); 
        }
        appId = new Random().nextInt(100);
    } 
    
    public static synchronized AppConfig getInstance() {
        if (self == null) {
            self = new AppConfig();
        }
        return self;
    }
    
    public static void main(String[] args) {
        AppConfig config = AppConfig.getInstance();
        
        try {
            // Save config to file
            ObjectOutput objectOutput = new ObjectOutputStream(new FileOutputStream("app.conf"));
            objectOutput.writeObject(config);
            objectOutput.close();
            System.out.println(config.appId);
            System.out.println(config);


            // Load config from file
            ObjectInput objectIutput = new ObjectInputStream(new FileInputStream("app.conf"));
            config = (AppConfig) objectIutput.readObject();
            objectIutput.close();
            System.out.println(config.appId);
            System.out.println(config);
        } catch (IOException | ClassNotFoundException ex) {
            ex.printStackTrace();
        }
    }
}

public class AppConfig implements Serializable {

private static volatile AppConfig self;

public int appId;

private AppConfig() {

if (self != null) {

throw new UnsupportedOperationException("Use getInstance()");

}

appId = new Random().nextInt(100);

}

public static synchronized AppConfig getInstance() {

if (self == null) {

self = new AppConfig();

}

return self;

}

public static void main(String[] args) {

AppConfig config = AppConfig.getInstance();

try {

// Save config to file

ObjectOutput objectOutput = new ObjectOutputStream(new FileOutputStream("app.conf"));

objectOutput.writeObject(config);

objectOutput.close();

System.out.println(config.appId);

System.out.println(config);

// Load config from file

ObjectInput objectIutput = new ObjectInputStream(new FileInputStream("app.conf"));

config = (AppConfig) objectIutput.readObject();

objectIutput.close();

System.out.println(config.appId);

System.out.println(config);

} catch (IOException | ClassNotFoundException ex) {

ex.printStackTrace();

}

Bạn sẽ thấy output có dạng này:

28
singletontester.AppConfig@55f96302
28
singletontester.AppConfig@776ec8df

singletontester.AppConfig@55f96302

singletontester.AppConfig@776ec8df

Tức là giá trị của object (các properties như appId) được giữ nguyên song object thực chất đã được tạo mới (tìm hiểu thêm về method toString()). Như vậy không đảm bảo 1 object được tạo ra duy nhất trên toàn bộ life cycle của ứng dụng. Vì cơ chế deserialize sẽ tạo mới object. Chúng ta cần sửa thành:

public class AppConfig implements Serializable {
    private static volatile AppConfig self;
    public int appId;
    
    private AppConfig() {
        if (self != null) { 
            throw new UnsupportedOperationException("Use getInstance()"); 
        }
        appId = new Random().nextInt(100);
    } 
    
    public static synchronized AppConfig getInstance() {
        if (self == null) {
            self = new AppConfig();
        }
        return self;
    }
    
    protected AppConfig readResolve() {
        return getInstance();
    }
}

public class AppConfig implements Serializable {

private static volatile AppConfig self;

public int appId;

private AppConfig() {

if (self != null) {

throw new UnsupportedOperationException("Use getInstance()");

}

appId = new Random().nextInt(100);

}

public static synchronized AppConfig getInstance() {

if (self == null) {

self = new AppConfig();

}

return self;

}

protected AppConfig readResolve() {

return getInstance();

}

Chỉ có đúng 1 object được tạo ra?

Bạn có chắc rằng với cách cài đặt trên chỉ có đúng 1 object có thể được tạo ra? Còn cách nào có thể tạo ra object không?

Đáng tiếc là vẫn còn, clone thì sao?

Kết

Singleton “chuẩn” nên được cài đặt như sau:

public class AppConfig {
    private static volatile AppConfig self;
    
    private AppConfig() {
        if (self != null) { 
            throw new UnsupportedOperationException("Use getInstance()"); 
        }
    } 
    
    public static synchronized AppConfig getInstance() {
        if (self == null) {
            self = new AppConfig();
        }
        return self;
    }
}

public class AppConfig {

private static volatile AppConfig self;

private AppConfig() {

if (self != null) {

throw new UnsupportedOperationException("Use getInstance()");

}

public static synchronized AppConfig getInstance() {

if (self == null) {

self = new AppConfig();

}

return self;

}

Bài viết này tôi lấy cảm hứng từ: https://medium.com/exploring-code/how-to-make-the-perfect-singleton-de6b951dfdb0, viết lại theo cách dễ đọc hơn.
Đến đây chắc bạn đã hiểu tại sao tôi khuyến nghị dùng static trong class nếu bạn không thực sự rõ về Singleton. Với class bạn không có vấn đề với serializable và reflection… Điều bạn gặp phải về threading có thể được IDE warning.
Hãy nhớ nhé, Singleton không dễ đâu.

3,144 total views, 10 views today

5 năm lần 1 với Planday

May 9, 2018 by Hien Nguyen·Comments Off

Đánh dấu một chặng đường, ghi lại vài dòng kỷ niệm.

Chiều 9/5/2013, tôi gặp Mikkel tại sân bóng, “tìm hiểu” nhau độ 30 phút trên đường đi bộ từ sân bóng ra quán bia. Mikkel nói chuyện về sản phẩm, công ty, mong muốn mở văn phòng development tại Việt Nam sau một số trải nghiệm không tốt với Ấn Độ. Tôi hỏi Mikkel “chắc chắn sẽ không mở văn phòng development tại Trung Quốc?”, Mikkel trả lời “không bao giờ”. Vậy là đủ để tôi tạm đồng ý trên quan điểm, cũng vừa khi tới quán bia hơi. Hai bên tập trung nhậu thêm 30 phút nữa cùng đội bóng, nói thêm dăm ba câu chuẩn bị cho cuộc gặp tiếp theo vào sáng hôm sau.

Sáng 10/5, tôi chạy xe qua khách sạn Mikkel ở, cùng đi bộ tới một nhà hàng gần đó để dùng bữa sáng. Hai bên chỉ đơn giản có những điểm chung: dùng iPhone, dùng Macbook để code .NET (đều dùng Thinkpad trước đó, chuyển sang Macbook vì có thêm project về iOS; với Mikkel chính là app Planday) – đủ vui để bắt đầu câu chuyện. Sản phẩm đâu? Source code đâu? Định hướng ra sao?… được trao đổi sau khi cả 2 gọi món. Món lên, thảo luận xong, chuyển sang chuyện phiếm. Ăn xong, cả hai gọi cafe và cùng thảo luận về bước tiếp theo. Mikkel nói đã gửi CV của tôi cho những cộng sự ở CPH, tất cả đều hài lòng; tôi chỉ ra một số lỗi nhỏ trên website và sản phẩm Planday nhận ra khi tìm hiểu về Planday tối hôm trước.

9:00 giờ gặp, 10:30 chia tay. Chốt. Tôi đã nhận lịch dạy của học kỳ tới nên sẽ chờ tới khi xong việc ở ĐH FPT sẽ bắt đầu làm việc tại Planday. Mikkel nhờ một công ty của bạn tại Việt Nam chuẩn bị hợp đồng. 23/5 ký hợp đồng. 15/7 chính thức làm việc.

Cả hai gần như bộc lộ cách làm việc của mình và hiểu cách làm việc của nhau ngay trong lần gặp đầu tiên: vui vẻ nhưng nhanh gọn, không rào đón nhưng đủ cẩn trọng (làm rất nhiều việc background, tìm hiểu trước; gặp gỡ chỉ tập trung trao đổi để quyết định nhanh). Hai người sau đó vẫn giữ cách thức này để làm việc với nhau trong gần 4 năm; mỗi năm Mikkel sang Việt Nam 1-2 lần, hầu hết các quyết định được đưa ra trên đường đi taxi từ sân bay về văn phòng; hoặc khi Mikkel rời văn phòng vào buổi chiều, hỏi “Hiển, có muốn ra ngoài hút thuốc không?” – tôi tiễn Mikkel ra ngõ, vừa đi vừa hút thuốc, khi thuốc tàn cũng là lúc Mikkel bắt được taxi, thảo luận xong. Thời gian còn lại để làm việc, giao lưu với những cộng sự ít gặp. Những lần tôi làm việc tại HQ cũng không khác. Làm ra làm, chơi ra chơi.

5 năm cùng Planday là thời gian đáng nhớ: thời gian “sóng gió” khiến tôi thay đổi cả về con người, cuộc sống, công việc; và cả gia đình – tất cả đồng điệu và phù hợp tới kỳ lạ. 5 năm chứng kiến startup đi từ siêu nhỏ tới series B; góp tay vào một nơi đi từ nhỏ như gara tới văn phòng thứ 3 đẹp đẽ. 5 năm đã cho tôi rất nhiều bài học. Một số trong đó là:

Winner takes all? Lúc nào cũng có bài toán để giải.

5 năm trước, Planday nằm trong số những công ty tăng trưởng ấn tượng nhất Đan Mạch, song vẫn không có gì đáng kể – một doanh nghiệp tăng trưởng 100% từ 100 khách hàng khác hẳn doanh nghiệp tăng trưởng 100% với 10.000 khách hàng. Với tư cách là sản phẩm nhỏ, ít người dùng, Planday mất nhiều chi phí liên hệ và phát triển để tích hợp với những hệ thống khác. Tại Việt Nam, Planday là con số không: không văn phòng, không công ty; với chẳng tư cách gì cả, kiếm người đồng hành cũng khó khăn.

Giờ, Planday vẫn nằm trong số những công ty tăng trưởng ấn tượng nhất Đan Mạch, với quy mô khác biệt và thu hút những ánh nhìn đầu tư toàn cầu. Với tư cách sản phẩm có nhiều người dùng, các sản phẩm khác cũng bắt đầu muốn được tích hợp vào hệ sinh thái. Tại Việt Nam, Planday đã có văn phòng, có tư cách pháp nhân, những cộng sự tiềm năng cũng không còn ngây ngô “công ty này làm gì?” trong lần đầu gặp mặt.

5 năm trước là bộn bề công việc. Giờ, mọi chuyện có trở nên dễ dàng? Vẫn bộn bề công việc… khác.

Khi Planday bắt đầu với những khách hàng đầu tiên tại Copenhagen, tất nhiên là không dễ dàng, Mikkel làm tất cả mọi công việc: phát triển, chăm sóc khách hàng, thu tiền… Sau khi phủ được một phần thị trường, việc bán hàng dễ dàng đến kỳ lạ, “Nửa nhà hàng ở Copenhagen đã dùng Planday rồi, bạn muốn đi sau không?”; thì có bài toán khác: giới hạn thị trường. Muốn mở rộng thì phải đi ra những thị trường mới, lại bắt đầu lại nhưng không thể giống cách cũ: chọn thị trường nào? chọn ngành nào?… Giải xong phần nào thì đến bài toán mới: đi cùng ai? chọn nhà đầu tư nào để phát triển hết tiềm năng?

Khi Planday bắt đầu với những công việc tại Việt Nam, tôi phụ trách nhiều việc: phát triển, tuyển dụng, văn phòng… Sau khi có những cộng sự, những dòng code đầu tiên, việc phát triển thêm một tính năng hay tuyển thêm một cộng sự mới không còn tốn nhiều thời gian như trước thì có bài toán khác: làm sao để các nhóm làm việc hiệu quả ở quy mô lớn hơn? Giải xong phần nào thì đến bài toán mới: làm sao duy trì sáng tạo? làm sao để các thành viên phát triển hết tiềm năng?

Winner takes all. Winner là ai? All là cái gì? Startup dù có là unicorn thì vẫn chẳng hiểu là nên tranh đấu với ai ngoài chính mình của ngày hôm qua. Winner là kẻ chiến thắng được chính mình do giải quyết được bài toán của ngày hôm qua và được luôn bài toán của ngày hôm nay – all.

Chừng nào còn đi được, còn được giải những bài toán mới là còn mừng. Giải mãi một bài toán là thất bại.

Thực sự không có gì? Chăm chỉ, tập trung và niềm tin thì sao?

Tôi vẫn hay nói đùa “Các ông startup ở Việt Nam có nghề dự event hay quan hệ cộng đồng à? Sao không thấy tập trung làm sản phẩm, toàn thấy lang thang chém gió ở các event và tương tác Facebook?”. Nói là vậy nhưng cũng không thể phủ nhận rằng đấy là việc nên làm.

5 năm trước, Planday tại Việt Nam có gì? Không văn phòng, không tư cách pháp nhân, không bánh vẽ… chỉ có một ít… tiền và chút uy tín cá nhân. 3 năm là khoảng thời gian tôi phải giải thích cho các ứng viên rằng “Nếu bạn nhận được offer letter thì đừng ngạc nhiên vì nó được gửi từ bộ phận nhân sự của công ty R, mời bạn ký hợp đồng với công ty P nhưng bạn làm việc cho Planday” – giống công ty ma không? Nhưng thành lập doanh nghiệp thời điểm đó không phù hợp vì khiến bộ máy phức tạp và kéo theo hàng loạt những công việc khác cùng khoản tiền ký quỹ lớn của doanh nghiệp FDI. Tôi may mắn nhờ vả được người lo giúp những vấn đề về hồ sơ, pháp lý, kế toán… để tập trung vào việc xây dựng nhóm và sản phẩm. Nhưng như vậy là chưa đủ, làm sao để tìm kiếm cộng sự? Với quan hệ và uy tín cá nhân, tôi tìm được những cộng sự đầu tiên, những cộng sự tiếp theo không dễ dàng – và không thể phủ nhận Facebook hay event cũng giúp sức một phần. Điều khác biệt là tôi không thích chém gió, kết nối sáo rỗng; tôi xuất hiện tại sự kiện và trên Facebook để giới thiệu về một môi trường khoáng đạt, một sản phẩm chất lượng, một cách làm việc khoa học… tại Planday. Rất nhiều ứng viên sau đó tìm đến Planday sau khi đã tìm hiểu qua talk, Facebook hay blog cá nhân của tôi. Một thời gian, tôi và Planday tại Việt Nam gần như không có ranh giới đến mức nhiều người lầm tưởng rằng đây là công ty của tôi. Để làm tốt, luôn cần nỗ lực cao; để tự tin nói rằng mình làm tốt, luôn cần nỗ lực thêm một chút, tin thêm một chút.

Thời gian đầu là bộn bề của sản phẩm, kỹ thuật, văn phòng, tuyển dụng, xây dựng thương hiệu… đã giúp tôi học được rất nhiều; dẫn đường bằng niềm tin và đi qua từng ngày bằng chăm chỉ, tập trung vào từng thứ một. Tôi xa rời dần chuyện trà trưa, những cuộc nhậu vô bổ và tập trung hơn để làm việc. Sẽ luôn có những khoảng trống để chúng ta có thể phủ lấp chỉ bằng việc cố gắng thêm một chút, tập trung hơn một chút. May mắn là những cộng sự của tôi đều như vậy. Mikkel làm việc rất nhiều (so với chuẩn của người Đan Mạch), luôn nỗ lực giải quyết công việc trong ngày. 10 giờ tới, 4 giờ rời văn phòng không bao giờ đồng nghĩa với thời gian làm việc. Ngày làm việc luôn cần bắt đầu từ 8 giờ (thậm chí 6 giờ), kết thúc 11-1 giờ đêm và bất cứ thời gian nào không dành cho gia đình. Thời gian đầu, khi thông tin bị tập trung nhiều, tôi nói với mọi người rằng mọi email, message… đều được tôi đọc trong tối đa 2 giờ (thời gian tối đa tôi trong sân bóng – khoảng thời gian duy nhất không thể liên lạc).

Tôi nghĩ rằng, với những startup cứ kêu rằng họ chẳng có gì, thì đúng là họ không có gì thật. Những thứ cuối cùng là niềm tin, thời gian để tập trung, chăm chỉ làm thêm một việc nữa cũng đã bị đánh mất khi họ ngồi đó và phàn nàn.

Thay đổi thế giới, chiến lược lớn, tầm nhìn xa có thể là vitamin nhưng thực dưỡng hàng ngày của startup chính xác là get shit done – từng việc một.

Tìm được partner đúng gần như là tất cả.

Mikkel và board của Planday rất nhất quán áp dụng chính sách partnership. Đến một thị trường, địa phương mới, việc đầu tiên là tìm partner và phải tìm đúng partner sau đó uỷ thác dần công việc. Về bản chất, tất cả đều là nhân viên của Planday, đều có những chính sách như mọi nhân viên khác song mọi phát ngôn và hành động đều thể hiện một sự tôn trọng khác biệt. Planday và tôi luôn mong muốn mang những nhân viên lại gần nhau để không có bất kỳ sự khác biệt nào giữa các văn phòng. Song khác biệt văn hoá tại một tổ chức đa quốc gia luôn là điều cần được thừa nhận; và sẽ có những người làm công việc “cầu nối”. Văn hoá đi trước, công việc đi sau. Công việc sẽ gần như không thể chạy khi các bên chưa hiểu rõ những nét văn hoá của cộng sự. Hiểu văn hoá là nền tảng để hiểu con người nằm trong văn hoá đó. Có hiểu mới tôn trọng. Có tôn trọng mới làm việc được.

Tại Planday Việt Nam, tôi đóng vai trò “cầu nối”, đảm bảo những cộng sự mới phù hợp với văn hoá chung, hiểu đúng và tôn trọng những đồng nghiệp khác, ở văn phòng khác. Những việc này chưa bao giờ được đặt trong JD (mà tôi cũng chưa bao giờ có JD cụ thể), nhưng là việc phải làm. Tôi cũng thích công việc đó; nó đúng với mong muốn của tôi về việc xây dựng một môi trường Agile; nó hợp với Mikkel vì Mikkel chưa biết nên làm thế nào tại Đan Mạch. Lịch sử Planday chứng kiến không ít thất bại tại các thị trường, bản thân Mikkel cũng có trải nghiệm không tốt tại Ấn Độ nên mọi người đều hiểu rằng, quan trọng là tìm được đúng partner – người hiểu đúng văn hoá, đúng mục tiêu.

Mỗi lần nói chuyện không về công việc cụ thể, Mikkel thường hỏi tôi “Hiển, có hài lòng với công việc không?”, thường là 3 lần / năm. Suy nghĩ của Mikkel rất đơn giản “nhiệm vụ của tao là làm cho mày hài lòng, việc còn lại là của mày”. Khi muốn làm việc trực tiếp với một ai đó, nếu có cảm giác lạ, Mikkel đều cẩn thận hỏi xem nên làm thế nào.

Trong giai đoạn đầu tôi cũng rất may mắn tìm được những cộng sự tuyệt vời. Có người miệng nói là tay làm ngay, có người còn phân tích chán – nhưng thế kết hợp lại hay, vừa khéo nên code viết ra đẹp như mơ. Tôi cũng may mắn nhờ vả được một số công việc hành chính, nhân sự (đúng nghĩa là nhờ) tới những người mà mình chỉ cần nói là xong, chẳng cần làm gì thêm. Đến nay thì Planday Việt Nam cũng có gần 30 cộng sự tuyệt vời, đủ để tôi có thời gian đi ra ngoài, giao lưu, học hỏi. Nghĩ ra, thì Planday đi nhanh vì tìm được những partner đúng, và tôi làm được nhiều việc cũng vì có những partner đúng.

Quan trọng là đi với ai, lo gì không đi tới đâu.

Xây dựng đội ngũ: Tin tưởng và trao quyền là hành động, không phải bởi nói suông.

Trao quyền là thứ được người ta nói quá nhiều trong thời buổi ngày nay nhưng hành động thường không tương xứng với những lời đao to búa lớn. Mikkel, qua những hành động của mình, chính là người dạy tôi nhiều nhất những bài học về trao quyền. Khi Mikkel tin và trao quyền cho ai, Mikkel cho họ không gian gần như tuyệt đối để thực hiện. Tất nhiên, cho tới khi họ chứng minh rằng không đáng để tin nữa.

Dự án đầu tiên tôi thực hiện là migrate database và thực hiện một function lớn ảnh hưởng tới toàn bộ code base. Việc migrate DB với rất nhiều optimize vẫn cần không dưới 6 giờ. Sau 1 tháng, tôi nói với Mikkel “chúng ta cần khoảng 3 tuần nữa”; 2 tuần sau Mikkel hỏi “vẫn theo kế hoạch chứ?”, tôi trả lời “còn một chút nữa thôi là chúng ta có thể sẵn sàng”, Mikkel soạn email gửi cho toàn bộ khách hàng, thông báo rằng Planday sẽ bảo trì hệ thống và down time trong 12 giờ vào ngày đã đinh. Đó là lần down time lâu nhất trong 5 năm. Không cân nhắc, không xét đoán, không kiểm tra. Sẽ là hơi quá để nói business sẽ sụp đổ nếu việc migrate / deploy không thành công; song chắc chắn không khách hàng nào hài lòng khi hệ thống phải liên tục bảo trì. Mikkel rất đặc biệt, biết rất nhiều nhưng luôn cố dại khờ để đặt niềm tin vào một số người; và khi tin tưởng thì sẵn sàng đánh cược. Không tin tưởng, không trao quyền, không đánh cược, startup không thể đi nhanh. Đó là bài học lớn đầu tiên.

Thật ra Mikkel và tôi đều là tuýt người thích kiểm soát, luôn muốn đảm bảo mọi thứ được xảy ra theo cách nó-nên-vậy để tối thiểu rủi ro. Cả hai đều là những kẻ mơ mộng trong an toàn . Trong giai đoạn đầu, Mikkel kiểm soát rất nhiều, chỉ một số ít không nằm trong số đó. Sẽ rất tuyệt khi trao quyền cho một người có thói quen kiểm soát; sẽ là thảm hoạ khi trao quyền cho một người không thích hoặc không có khả năng kiểm soát. Đó là bài học lớn thứ hai.

Những người làm việc hiệu quả nhất với Mikkel và tôi là những người đủ khả năng kiểm soát, kiên trì đeo bám mục tiêu, luôn cập nhật thông tin và tìm kiếm tư vấn khi cần thiết; họ đương nhiên được quyền và chịu trách nhiệm trao quyền cho bất kỳ ai họ tin tưởng. May mắn cho tôi rằng ngay trong thời kỳ đầu, đã có những cộng sự tuyệt vời để có thể trao quyền; họ đủ say mê để muốn kiểm soát và đủ khả năng kiểm soát trong phạm vi của mình. Tôi thực sự, thực sự may mắn vì có được điều ấy. Về lý thuyết, đó là hệ quả của việc tôi kiên trì tìm kiếm những người phù hợp; song tôi phải thừa nhận rằng mình rất may mắn có được đủ những người phù hợp từ rất sớm và đúng thời điểm.

Lasse, một cộng sự thân thiết của tôi, cũng thuộc tuýt như vậy. Lần gọi điện đầu tiên giữa Lasse với cộng sự tại Hà Nội không thực sự suôn sẻ: “how are you?”, “I’m 30 years old”. Nhưng Lasse vẫn tin rằng “không sao đâu, sẽ ổn thôi”. Và mọi thứ ổn thật.

Tin tưởng, trao quyền và đừng quên plan B.

Xây dựng đội ngũ: Luôn có cơ hội với sự thật.

Trước đây tôi luôn thắc mắc startup, doanh nghiệp nhỏ làm sao tìm kiếm được cộng sự tốt? Không tương lai, không hình ảnh (cả thật và ảo), ít tiền… làm sao cạnh tranh trong tuyển dụng? Cho tới khi chính mình phải làm việc đó. Planday tại Việt Nam khởi đầu bằng việc ngồi chung với một văn phòng khác trước khi tồn tại 1.5 năm trong văn phòng rộng 14m2. Nhiều khi họp tôi xuống quán cafe. Phỏng vấn thì đưa ứng viên qua phòng họp mượn tạm. Và tất nhiên, chẳng nhiều ứng viên tốt nào hào hứng với việc tham gia một nhóm như vậy; họ đơn giản còn nhiều lựa chọn. Không phải có vì lịch sự không, tôi nhận được nhiều email từ chối theo kiểu “mình ấn tượng khi nói chuyện với Hiển, giá mà Hiển…”, rồi blah blah điền vào chỗ trống: ở công ty to hơn, có tương lai hơn, có cơ hội thăng tiến hơn, đề xuất mức lương cao hơn…

“Anh muốn cả đời đi bán nước đường hay cùng tôi thay đổi thế giới?” – xin lỗi, câu nói đó chỉ xuất hiện trong truyền thuyết, thế giới có mấy Steve Jobs? Tuy vậy, đấy vẫn là bài tuyển dụng kinh điển của startup và doanh nghiệp nhỏ nếu họ không muốn định vị mình thấp hơn, chấp nhận những ứng viên thấp hơn. Tôi là người thực tế và không giỏi vẽ bánh. Tôi gần như không bao giờ nói về tương lai quá xa của việc triệu đô, thay đổi thế giới, thăng chức… với những cộng sự tiềm năng. Tôi định vị Planday tại Việt Nam là một cơ hội học tập. Tôi luôn nhất mực khẳng định rằng đấy là lợi thế duy nhất của Planday so với những lựa chọn khác mà ứng viên đang có trong tay. Ở đây không có văn phòng đẹp nhất, và sẽ không bao giờ có văn phòng đẹp nhất; ở đây không có những chế độ tốt nhất, và mọi người vẫn phải tự đi mua đồ ăn khi hết bằng tiền của công ty; ở đây không có mức lương cao nhất thị trường. Nhưng ở đây chắc chắn sẽ là môi trường khoáng đạt nhất; ở đây sẽ là nơi có cách làm việc khoa học nhất; ở đây sẽ là nơi bạn có cơ hội tiệm cận đẳng cấp của developer trên thế giới. Và ở đây có một kho thông tin được transparent; để dù bạn ở đẳng cấp nào thì vẫn còn muôn vàn thứ có thể học được về cách một sản phẩm đi ra thế giới, cách cá nhân và một nhóm làm việc cùng nhau hiệu quả. Và chừng nào tôi còn ở đây, bạn luôn có ít nhất một cộng sự không ngừng học tập và chia sẻ. Ở đây không xây dựng cho bạn một sự nghiệp thẳng tiến lên những vai trò manager, nhưng bạn có rất nhiều không gian để phát triển chuyên môn, và nếu chịu khó học hỏi, bạn luôn có cơ hội đủ kỹ năng để tham gia hay làm manager của bất kỳ đội nhóm sản phẩm nào tại Việt Nam. Khi ứng viên lưỡng lự, tôi cho họ xem source code.

Tham gia Planday là chấp nhận rủi ro nhưng tham gia Planday bạn luôn sẵn sàng có khả năng đi tới bất kỳ nơi đâu. Tất cả là sự thật. Có một thời gian, việc tuyển dụng không tiến triển, nhiều cộng sự nói với tôi rằng “anh khó tính quá, mà không có bánh vẽ thì làm sao tuyển?” – nhưng tôi không thể nói về những thứ tôi không chắc như ngày mai, ngày kia… Tôi chỉ thấy vui vẻ khi nói sự thật và cộng sự của mình nói sự thật. Điều này làm chậm rất nhiều quá trình mở rộng nhưng nó đủ tốt để tạo sự tin tưởng với những người lựa chọn tham gia Planday. Mà đó mới thực sự là những người tôi cần quan tâm.

Planday tại Đan Mạch cũng vậy, giai đoạn đầu việc tuyển dụng cũng chẳng dễ dàng hơn, nhưng cũng từ sự thật, Mikkel tìm kiếm được những cộng sự rất chất lượng từ Skype, VISA…

Bây giờ, khi Planday có tiếng hơn, có văn phòng đẹp hơn, có nhiều chế độ hơn… có nhiều người chủ động tìm đến; tôi vẫn không muốn nói về ngày mai hay một tương lai quá xa (thực tế là chúng tôi cũng chẳng có những thứ đó), tôi vẫn muốn định vị Planday là một cơ hội học tập và phát triển bản thân.

Startup đừng nên vẽ mình hoành tráng quá đến mất cơ hội của sự thật. Quan trọng là sự thật đủ tốt.

Xây dựng đội ngũ: Con người là đầu tiên và cuối cùng.

Thực hiện công việc: con người là điều đầu tiên. Phân tích hậu quả: con người là điều cuối cùng.

Bài toán được phát hiện ra bởi con người, và cần giải quyết trước nhất bởi con người. Con người là điểm bắt đầu chứ không phải công cụ hay máy móc. Nếu có việc gì cần làm ngay, hãy thực hiện ngay, quy trình hay công cụ sẽ đi sau nếu việc đó lặp lại. Trước khi code, hãy ngồi nói chuyện với nhau. Cách thức, kiến trúc nào là tốt? Là cách thức, kiến trúc mà cả nhóm tự tin trong việc đảm bảo chất lượng. Có hàng tá những thứ khách hàng của Planday được hưởng lợi chỉ qua nỗ lực rất nhanh của cá nhân và hệ thống theo sau đó khi có khách hàng tiếp theo.

Khi phân tích những hậu quả, những điều bất ổn, con người luôn là yếu tố được xem xét sau cùng. Có điều gì không ổn? Quy trình có buộc chân chúng ta ở đâu không? Manager và Planday còn support được gì? Cần thay đổi gì?… “Có phù hợp với nhau không?” là câu cuối cùng tôi muốn nghĩ tới. Tôi có nhiều quyết định về nhân sự khiến cộng sự khó hiểu, một số chia tay ngay trong 1-2 tháng đầu tiên, một số chia tay sau một thời gian dài dù hiệu quả làm việc rất thấp. Tôi chỉ nhìn thấy thời điểm, đấy đúng là thời điểm tôi đã đủ dữ liệu để khẳng định đó thực sự là vấn đề “con người”. Có cộng sự tôi mất rất nhiều thời gian hàng ngày để học tiếng Anh cùng, cho họ giảm thời gian làm việc để tự học thêm, động viên, treo thưởng… nhưng thấy bạn bắt đầu thoả mãn và ngừng phát triển cũng là thời điểm chia tay. Với những người chủ động chia tay, tôi cũng sẽ tìm hiểu, nếu đó là vấn đề “con người” (cơ hội cho bản thân…), tôi sẽ không giúp họ thay đổi quyết định.

Đây là một trong những thay đổi rất lớn của cá nhân tôi trong 10 năm qua. Bản tính trời sinh là sự nghi kỵ con người, cho rằng mọi thứ xàm xí đều do con người mà ra (tôi nghĩ nhiều người giống tôi, thật khó nghĩ khác khi chúng ta sống trong môi trường này). Tôi đặc biệt biết ơn 4 năm làm việc tại Đại học FPT và 5 năm làm việc tại Planday – nơi cách ly tôi khỏi những thứ xàm xí để tập trung làm việc với những con người trong trắng, ngây thơ và văn minh. Khi ở ĐH FPT, đa phần tiếp xúc với giảng viên và sinh viên – chắc quay bài là lỗi lớn nhất. Khi ở Planday, thật khó để tìm thấy một người Bắc Âu nào không tử tế; văn phòng Việt Nam cũng vậy: “không nói xấu sau lưng” là nguyên tắc số 1. Tính cách của tôi dần được thay đổi. Giờ đây tôi rất ngại phải làm những thủ tục hành chính hay tham gia những đội nhóm “có vấn đề về con người”.

Nếu đã coi con người là tất cả, hãy để con người trải dài từ đầu tiên tới cuối cùng.

Linh hoạt hay là quan trọng: Chúng ta chẳng thể biết hết về ngày mai.

Tôi đương nhiên sẽ nói về linh hoạt. Tham gia vào một suốt một chặng đường chuyển mình của startup phát triển không chậm, không thể không nhận thấy cái giá của sự linh hoạt. Không linh hoạt là chết, có phải lời nói quá không?

Nguồn lực của startup không bao giờ đủ để làm những việc lãng phí và vô nghĩa nên chỉ có tập trung và linh hoạt là giải pháp. Chuyện có một khoản tiền nhỏ và phải cân nhắc nên mở văn phòng hay tuyển thêm người hay mua dịch vụ… là chuyện thường xuyên. Cân nhắc khi nào chịu, khi nào trả technical debts, product debts… là chuyện cần thiết. Nguyên chuyện packaging và pricing cũng rất vui: một thời gian sản phẩm được tách thành 2 gói, basic và advanced; một thời gian sau lại hợp lại làm một, bán một giá; một thời gian sau lại tách ra… Sản phẩm cũng vui: một thời gian dùng custom control, một thời gian sau dùng native control theo OS… Tích hợp cũng vui: một thời gian tích cực tích hợp; một thời gian cố gắng không phân mảnh; rồi lại tích cực tích hợp… Công nghệ cũng vui: một thời gian duy trì công nghệ đồng nhất; một thời gian chấp nhận phân mảnh; rồi lại đồng nhất…

Nghe có quen quen? Tôi gặp hàng trăm câu chuyện như vậy qua những buổi nói chuyện trong cộng đồng, mọi người ca thán rằng thấy “loay hoay, lúc thế này, lúc thế khác; chẳng hiểu đi được tới đâu”. Và tôi chỉ ước mọi người đừng hỏi “Planday có thế không?”. Startup không như vậy thì sống kiểu gì? Nhưng “loay hoay” và “linh hoạt” có một ranh giới mà chỉ trong cuộc mới hiểu và họ hiểu bởi họ sở hữu dữ liệu. Quan trọng là, dữ liệu cho anh thấy, anh đã giải được bài toán hiện tại chưa, nếu chưa mà anh cứ tiếp tục thì sẽ là “loay hoay”, nếu khẳng định được để anh đi tiếp hay chuyển sang bài toán khác thì sẽ là “linh hoạt”.

Một đặc tính nổi bật (và là lợi thế) của các công ty Bắc Âu là khả năng ra quyết định và chuyển mình nhanh. Nhưng tất cả đều được minh bạch và giao tiếp tốt nên việc hoài nghi về “một thứ gì đó khác trong quyết định” không thường xảy ra. Văn phòng Hà Nội được xây dựng với định hướng trở thành nơi phát triển quan trọng về hệ thống. Một thời gian ngắn sau, mobile trở thành việc quan trọng nên ngay lập tức có thêm nhóm làm mobile. Một thời gian sau, việc mở rộng nhóm hệ thống không thực sự khả thi do không tìm được nhân sự đủ tốt, cùng lúc đó là cơ hội để có những nhân sự chất lượng tại Đan Mạch, phần công việc được chuyển giao lại… Rất nhiều những chuyện như vậy vẫn xảy ra, đòi hỏi doanh nghiệp phải linh hoạt để giải quyết các bài toán về sản phẩm, thị trường, nhân sự, công nghệ…

Đúng sai là chuyện của khoảnh khắc, linh hoạt để bắt đúng khoảnh khắc.

Phải làm, muốn làm và được làm: Ranh giới mong manh.

Tại startup, sẽ là một ranh giới rất, rất mong mong manh giữa 3 loại công việc: phải làm, muốn làm, được làm. Startup gần như không có giới hạn về những việc “được làm”, có muôn vàn công việc để “muốn làm”, và một ít việc “phải làm”. Đừng quá nhầm lẫn, startup có cả một thế giới những việc “cần làm” nhưng rất ít người định hình rõ công việc cho bạn; nên nếu bạn coi “phải làm” là hệ quy chiếu thì bạn cũng chẳng bận rộn hơn so với làm việc trong một tổ chức ổn định. Thậm chí là nhàn hơn. Thật sự là như vậy. “Không phải việc của tôi” là câu nói luôn đúng trong startup, bởi startup làm gì có JD cụ thể, làm gì có process cụ thể? Mà cũng chẳng ai mất công đi tranh cãi, ăn thua việc đó làm gì cho tốn thời gian, còn cả ngàn việc “cần làm”. Bởi câu nói đó, khi được nói ra, cũng đúng như chuyện “chúng ta không hợp nhau”. Thế thôi.

Làm việc tại startup là nghệ thuật của xác định những việc “cần làm”, chuyển chúng thành việc “phải làm”; và chẳng cần chờ tới may mắn đâu, đó thường là những việc bạn “được làm” – quan trọng đó có phải là việc bạn “muốn làm” hay không. Vận hành startup cũng vậy, là nghệ thuật của việc tối đa số “muốn làm” của cá nhân và “cần làm” của tổ chức khớp với “được làm” (đủ khả năng). Đó là cách tạo ra giá trị lớn nhất trong một nguồn lực giới hạn.

Có một câu chuyện vui. Khi mở văn phòng tại Việt Nam, tôi là người phụ trách gần như mọi công việc. Thời đó tôi lấy bừa title “Team Lead” vì cũng chẳng biết đặt là gì nhưng cũng cần title để nói chuyện, phỏng vấn, giao tiếp với bên ngoài. Sau này, Planday phát triển, mỗi người mới vào đều có title và JD cụ thể. Vào một ngày đẹp trời gần đây, board nhận ra tôi chưa bao giờ được có title hay JD một cách chính thức; tôi tất nhiên cũng chẳng để ý. Nhưng giờ đặt thế nào thì cũng conflict với công việc và các vị trí hiện tại. Cuối cùng chốt bừa một cái, còn vẽ organizational chart, dù JD của tôi không thực sự đúng với title. Để duy trì startup spirit, nên giờ dù Planday đã “nề nếp”, JD của tôi vẫn rất mở.

Startup nào cũng có những giai đoạn, những người gom những việc “phải làm”, “muốn làm” và “được làm” trộn vào với nhau và get shit done.

Khởi nghiệp: giấc mơ của bạn, không phải của chung.

Điều tôi cực kỳ ấn tượng và tôn trọng Mikkel bởi sự rõ ràng về chuyện khởi nghiệp. Mikkel rất đam mê, rất chăm chỉ với việc lập trình, việc làm sản phẩm, việc giúp đỡ người dùng và luôn mong muốn mọi người chung tay xây dựng giá trị cho người dùng song Mikkel không bao giờ bắt ép mọi người làm việc đến điên rồ như mình. Mikkel luôn tôn trọng không gian cá nhân và chỉ yêu cầu mọi người làm việc có trách nhiệm.

Bản tính thận trọng và hiểu biết rộng giúp Mikkel không bao giờ đưa Planday vào tình thế khó xử, ít nhất ở vấn đề tài chính. Không ít lần dòng tiền công ty chỉ ra rằng Planday chỉ đủ tuyển thêm 1 người, người làm sản phẩm, UX hay development? Hay mua thêm công cụ / dịch vụ? Hay mở văn phòng? Tất cả được cân nhắc kỹ lưỡng để không ai phải làm thêm việc. Trong 3 năm, 4 lần Mikkel hỏi rằng “Hiển, có cần người support không? Mày còn phải đá bóng mà? Tao phải làm việc trực tiếp với chừng này người và biết sẽ bận đến mức nào.”. Lần thứ 4 là khi chúng tôi quyết định sẽ chính thức có tư cách pháp nhân tại Việt Nam.

Những điều này giúp tôi thay đổi suy nghĩ khá nhiều, giống như Mikkel, tôi chỉ yêu cầu mọi người có trách nhiệm với công việc như đã cam kết với công ty. Tất nhiên, startup có hàng ngàn việc cần làm, ai cố gắng làm thêm, tôi rất trân trọng; nhưng không có nghĩa rằng những người không xả thân sẽ bị nguyền rủa hay ghẻ lạnh – điều hay xảy ra tại những doanh nghiệp khác khi những ông chủ luôn muốn nhân viên xả thân cho giấc mơ của mình. CB, CEO của Planday, lần nào gặp cũng nói “mỉa” rằng: Hiển, người Đan Mạch không làm việc thứ 7 – để chỉ trích chính sách làm việc sáng thứ 7 tại Việt Nam của tôi (thật ra là để học, không phải làm việc).

Khởi nghiệp không hẳn là giấc mơ chung. Không ai phải chết cho giấc mơ của người khác chính là tiền đề cho một mối quan hệ bền vững.

Không nhậu không chết được đâu.

Gắn kết đội ngũ và gắn kết đội ngũ với manager luôn là một trong những ưu tiên hàng đầu của mọi tổ chức và manager. Có ba phương pháp cực hiệu quả thường thấy là nhậu, nhậu và nhậu. Công bằng mà nói, chẳng đội nhóm nào gắn kết được mà thiếu nhậu – đấy là lúc người ta có thể dễ dàng cười vào quá khứ, trải lòng về hiện tại và mơ mộng về tương lai – những chất liệu làm nên sợi dây gắn kết trong đội nhóm. Học hỏi từ những đàn anh đi trước, tôi cũng đã thử áp dụng trong nhóm của mình, sinh ra một thứ gọi là “big Friday” hàng tuần (đến giờ chúng tôi vẫn dùng “thuật ngữ” này cho việc nhậu – nhưng không phải hàng tuần): đưa nhau ra quán. Tại HQ chúng tôi cũng có một chương trình tương tự, gọi là “Friday bar” nhưng chỉ tại văn phòng và kéo dài dưới 1 giờ, mọi người tập trung nói chuyện nhiều hơn là uống.

Một thời gian rất ngắn, tôi bắt đầu lược bỏ chuyện nhậu, thu gọn 2-3 lần / năm; những cuộc nhậu tự phát vẫn tiếp tục nếu có thành viên thích thú, tôi không phản đối; song tôi chỉ tham gia 2-3 cuộc nhậu được coi là “chính thức” và biến những cuộc đó thành những ấn tượng mọi người không thể nào quên. Một phần tôi muốn tiết kiệm thời gian làm việc, một phần để giảm áp lực tới các thành viên rằng nhậu không phải là công việc, bất kỳ ai cũng có quyền từ chối nếu không hứng thú, chẳng cần phải phán đoán ý sếp hay lo sợ mất cơ hội biết thêm thông tin trên bàn nhậu.

Và kết quả là… chẳng có gì khác biệt. Tôi không phản đối việc các manager gắn kết nhân viên thông qua nhậu, song tôi không phải là fan của việc nhậu và cũng không cho rằng đấy là cách hay khi bị lạm dụng, nó quá mất thời gian và không tạo ra nhiều giá trị. Nhậu rất tuyệt để thực hiện ice breaking, song đừng sử dụng nhậu làm sợi dây gắn kết nhau trên đường dài. Sao không thay việc nhậu hàng tuần, hàng tháng bằng việc học hàng tuần, hàng tháng? Tôi thích cảm giác mỗi khi CB hay Mikkel nhíu mày “Hiển, mai là thứ 7 rồi, uống đi mà”.

Về lâu dài, các manager / leader nên gắn kết với đội ngũ và để họ gắn kết với nhau thông qua sự tôn trọng, thấu cảm và suồng sã rất tốt nhưng startup còn nhiều việc lắm, có đáng đánh đổi thời gian thế không?

————————————————–

5 năm là một chặng đường đủ dài để cho tôi rất nhiều bài học qua những con người, những bài toán rất khác nhau. Tôi vẫn không bao giờ nói về một tương lai quá dài, “chừng nào vẫn còn bài toán để giải, vẫn còn thứ để học, tôi sẽ vẫn tiếp tục”. Và thật may mắn, đến giờ, vẫn còn.

1,211 total views, 1 views today

Blockchain explained by simple Java code

April 11, 2018 by Hien Nguyen·Comments Off

Following my problem with KFC system, let’s see another real world problem: The food shop chain with a central hotline/database couldn’t work sometimes because of single point that needs to be always up. If the order database could be distributed, the high availability of the system could be increased. It’s when blockchain shows its value by all distributed shops store the copy of single order database.

Blockchain is combination of block and chain. Block is unique and stores the data/information, chain stores a sequence of blocks that each block points to the previous one.

This article describes the simple blockchain that’s used to store the orders of all food shops in the system.

Let’s start with Block with a simple version of Order.

public class Block {
    public String hash;
    public String previousHash;
    public Order order;
    public long timeStamp;
    
    public Block(Order order, String previousHash) {
        this.order = order;
        this.previousHash = previousHash;
        this.timeStamp = new Date().getTime();
        
        this.hash = Generator.generateHash(
                this.previousHash 
                + this.timeStamp 
                + this.order.toString());
    }
    
    public static Block getGenesisBlock() {
        Order order = new Order("Its me", "Nothing", 0);
        Block block = new Block(order, "");
        block.timeStamp = 0;
        block.hash = Generator.generateHash(
                block.previousHash 
                + block.timeStamp 
                + block.order.toString());
        return block;
    }
}

public class Block {

public String hash;

public String previousHash;

public Order order;

public long timeStamp;

public Block(Order order, String previousHash) {

this.order = order;

this.previousHash = previousHash;

this.timeStamp = new Date().getTime();

this.hash = Generator.generateHash(

this.previousHash

+ this.timeStamp

+ this.order.toString());

}

public static Block getGenesisBlock() {

Order order = new Order("Its me", "Nothing", 0);

Block block = new Block(order, "");

block.timeStamp = 0;

block.hash = Generator.generateHash(

block.previousHash

+ block.timeStamp

+ block.order.toString());

return block;

}

One Block has the unique ID, called hash, with time the block is generated, called timeStamp, and hash of the previous block, called previousHash. Block has order that store the food order data.

The first block that doesn’t have previous one, called genesis block, should be hard-coded.

A BlockChain has a list of block with some add-in methods like validateBlock() or validate() the block chain.

public class BlockChain implements Cloneable {
    private final ArrayList<Block> chain;
    
    public BlockChain() {
        this.chain = new ArrayList<>();
        this.chain.add(Block.getGenesisBlock());
    }
    
    public ArrayList<Block> getBlocks() {
        return (ArrayList<Block>) chain.clone();
    }
    
    public long size() {
        return chain.size();
    }
    
    public void add(Block block) {
        if (validateBlock(chain.get(chain.size() - 1), block)) {
            chain.add(block);
        } else {
            throw new IllegalArgumentException("Invalid block");
        }
    }
    
    public String getLastHash() {
        return this.chain.get(this.chain.size() - 1).hash;
    }
        
    public boolean validateBlock(Block previousBlock, Block block) {
        return block.previousHash.equals(previousBlock.hash);
    }
    
    public boolean validate() {        
        ArrayList<Block> subChain = (ArrayList<Block>) chain.subList(1, chain.size() - 1);
        Block previousBlock = chain.get(0);

        for (Block currentBlock : subChain) {
            if (!validateBlock(previousBlock, currentBlock)) {
                return false;
            }
            previousBlock = currentBlock;
        }
        
        return true;
    }
    
    @Override
    public Object clone() throws CloneNotSupportedException {
        return super.clone();
    }
}

public class BlockChain implements Cloneable {

private final ArrayList<Block> chain;

public BlockChain() {

this.chain = new ArrayList<>();

this.chain.add(Block.getGenesisBlock());

}

public ArrayList<Block> getBlocks() {

return (ArrayList<Block>) chain.clone();

}

public long size() {

return chain.size();

}

public void add(Block block) {

if (validateBlock(chain.get(chain.size() - 1), block)) {

chain.add(block);

} else {

throw new IllegalArgumentException("Invalid block");

}

public String getLastHash() {

return this.chain.get(this.chain.size() - 1).hash;

}

public boolean validateBlock(Block previousBlock, Block block) {

return block.previousHash.equals(previousBlock.hash);

}

public boolean validate() {

ArrayList<Block> subChain = (ArrayList<Block>) chain.subList(1, chain.size() - 1);

Block previousBlock = chain.get(0);

for (Block currentBlock : subChain) {

if (!validateBlock(previousBlock, currentBlock)) {

return false;

}

previousBlock = currentBlock;

}

return true;

}

@Override

public Object clone() throws CloneNotSupportedException {

return super.clone();

}

The reason of class BlockChain implementing interface Cloneable should be describe later.

Now each food shop, called Node, has a single blockchain. To make sure all nodes store the same blockchain, we must firstly make sure all nodes can ‘know’ others. Following:

If the node is started without connectedNode, it’s the first node
If the node is started with connectedNode, it asks the connectedNode for the list of nodes in the network, calling to getNodes(). Then the node tells those existing nodes that it wants to connect to the network, calling to registerToNetwork()

public class Node {
    public String address;
    
    protected BlockChain blockChain;
    private ArrayList<Node> nodes;
    
    public Node(String address, Node connectedNode) {
        this.address = address;
        blockChain = new BlockChain();
        
        if (connectedNode != null) {
            registerToNetwork(connectedNode);
            try {
                getBlockChain(connectedNode);
            } catch (CloneNotSupportedException ex) {
                Logger.getLogger(Node.class.getName()).log(Level.SEVERE, null, ex);
            }
        } else {
            nodes = new ArrayList<>();
        }
    }
    
    public void add(Block block) {
        try {
            this.blockChain.add(block);
        } catch (IllegalArgumentException e) {
            if (this.nodes.size() > 0) {
                try {
                    getBlockChain(this.nodes.get(0));
                } catch (CloneNotSupportedException ex) {
                    Logger.getLogger(Node.class.getName()).log(Level.SEVERE, null, ex);
                }
            }
        }
    }
    
    public void mine(Block block) {
        this.blockChain.add(block);
        this.nodes.forEach((node) -> {
            node.add(block);
        });
    }
    
    private void registerToNetwork(Node connectedNode) {
        this.nodes = connectedNode.getNodes();
            this.nodes.add(connectedNode);
            this.nodes.forEach((node) -> {
                node.register(this);
            });
    }
    
    private void getBlockChain(Node connectedNode) throws CloneNotSupportedException {
        this.blockChain = (BlockChain) connectedNode.blockChain.clone();
    }
    
    public ArrayList<Node> getNodes() {
        return (ArrayList<Node>) this.nodes.clone();
    }
    
    public void register(Node node) {
        this.nodes.add(node);
    }
}

public class Node {

public String address;

protected BlockChain blockChain;

private ArrayList<Node> nodes;

public Node(String address, Node connectedNode) {

this.address = address;

blockChain = new BlockChain();

if (connectedNode != null) {

registerToNetwork(connectedNode);

try {

getBlockChain(connectedNode);

} catch (CloneNotSupportedException ex) {

Logger.getLogger(Node.class.getName()).log(Level.SEVERE, null, ex);

}

} else {

nodes = new ArrayList<>();

}

public void add(Block block) {

try {

this.blockChain.add(block);

} catch (IllegalArgumentException e) {

if (this.nodes.size() > 0) {

try {

getBlockChain(this.nodes.get(0));

} catch (CloneNotSupportedException ex) {

Logger.getLogger(Node.class.getName()).log(Level.SEVERE, null, ex);

}

public void mine(Block block) {

this.blockChain.add(block);

this.nodes.forEach((node) -> {

node.add(block);

});

}

private void registerToNetwork(Node connectedNode) {

this.nodes = connectedNode.getNodes();

this.nodes.add(connectedNode);

this.nodes.forEach((node) -> {

node.register(this);

});

}

private void getBlockChain(Node connectedNode) throws CloneNotSupportedException {

this.blockChain = (BlockChain) connectedNode.blockChain.clone();

}

public ArrayList<Node> getNodes() {

return (ArrayList<Node>) this.nodes.clone();

}

public void register(Node node) {

this.nodes.add(node);

}

To make sure blockchain consistently, when a node mines a block, it needs to notify all nodes in the network by method mine(). In this problem, it means a food shop creates order for a customer.

It is. A blockchain is ready. Class Store and FoodBlockChainTest are for testing: it creates 3 stores (kfc, burger, pho) and registers them to the network, each store simulates creating the orders and add them to blockchain. You should see the result in your console. This example is just simulated by distributing the system in threads, that’s why I used Cloneable to get it looked like ‘distributed’ without references. In the real blockchain, methods like getNodes(), getBlockChain(), register()… should be called by REST or RPC.. and each node has it owned isolated data. But networking isn’t our focus here, you can easily write some extra code.

public class Store extends Node implements Runnable {
    
    public Store(String address, Node connectedNode) {
        super(address, connectedNode);
    }
    
    public void testOrders() throws InterruptedException {
        String[] customerName = {"Messi", "Ronaldo", "Pogba"};
        String[] orderDetails = {"KFC", "Burger", "Wine" };
        Random random = new Random();
        
        for (int i = 0; i < 3; i++) {
            Block block = new Block(
                    new Order(customerName[random.nextInt(3)], orderDetails[random.nextInt(3)], random.nextInt(50)),
                    this.blockChain.getLastHash()
            );
            try {
                this.mine(block);
                System.out.println(String.format("%s mined: %s", address, block.hash));
            } catch (IllegalArgumentException ex) {
                System.out.println(String.format("%s mined invalid block: %s", address, block.hash));
            }
            Thread.sleep(random.nextInt(3) * 1000 + 100);
        }
    }
    
    public void printBlockChain() {
        System.out.println("------ Block chain of [" + address + "] ------");
        
        this.blockChain.getBlocks().forEach(block -> {
            System.out.println(block.hash);
        });
        
        System.out.println("------ END ------");
    }

    @Override
    public void run() {
        try {
            testOrders();
        } catch (InterruptedException ex) {
            Logger.getLogger(Store.class.getName()).log(Level.SEVERE, null, ex);
        }
    }
}

public class Store extends Node implements Runnable {

public Store(String address, Node connectedNode) {

super(address, connectedNode);

}

public void testOrders() throws InterruptedException {

String[] customerName = {"Messi", "Ronaldo", "Pogba"};

String[] orderDetails = {"KFC", "Burger", "Wine" };

Random random = new Random();

for (int i = 0; i < 3; i++) {

Block block = new Block(

new Order(customerName[random.nextInt(3)], orderDetails[random.nextInt(3)], random.nextInt(50)),

this.blockChain.getLastHash()

);

try {

this.mine(block);

System.out.println(String.format("%s mined: %s", address, block.hash));

} catch (IllegalArgumentException ex) {

System.out.println(String.format("%s mined invalid block: %s", address, block.hash));

}

Thread.sleep(random.nextInt(3) * 1000 + 100);

}

public void printBlockChain() {

System.out.println("------ Block chain of [" + address + "] ------");

this.blockChain.getBlocks().forEach(block -> {

System.out.println(block.hash);

});

System.out.println("------ END ------");

}

@Override

public void run() {

try {

testOrders();

} catch (InterruptedException ex) {

Logger.getLogger(Store.class.getName()).log(Level.SEVERE, null, ex);

}

public class FoodBlockChainTest {
    /**
     * @param args the command line arguments
     */
    public static void main(String[] args) {
        Store kfc = new Store("KFC Vietnam", null);
        Store burger = new Store("Burger King", kfc);
        Store pho = new Store("Pho", kfc);
        
        Store[] stores = {kfc, burger, pho};
        
        for (Store store : stores) {
            Thread thread = new Thread(store);
            thread.start();
        }
        
        try {
            Thread.sleep(10000);
        } catch (InterruptedException ex) {
            Logger.getLogger(FoodBlockChainTest.class.getName()).log(Level.SEVERE, null, ex);
        }
        
        for (Store store : stores) {
            System.out.println("");
            store.printBlockChain();
        }
    }
}

public class FoodBlockChainTest {

/**

* @param args the command line arguments

public static void main(String[] args) {

Store kfc = new Store("KFC Vietnam", null);

Store burger = new Store("Burger King", kfc);

Store pho = new Store("Pho", kfc);

Store[] stores = {kfc, burger, pho};

for (Store store : stores) {

Thread thread = new Thread(store);

thread.start();

}

try {

Thread.sleep(10000);

} catch (InterruptedException ex) {

Logger.getLogger(FoodBlockChainTest.class.getName()).log(Level.SEVERE, null, ex);

}

for (Store store : stores) {

System.out.println("");

store.printBlockChain();

}

It’s of course not a real blockchain that you can use now. There are many things that this article didn’t mention: chain conflict, Proof of Work, sub chain, confirmation… But I hope you can get the idea of blockchain and its value through a simple code. It just a start, I will get back with another topic later.

Full code should be found here: https://github.com/hiennvn/simple-blockchain-java

2,645 total views, 3 views today

How a team setup a software project

February 17, 2018 by Hien Nguyen·Comments Off

How could we have the high performance team for a software development project at getting started? It may take long time to get a team having the same mindset and working together with high performance but with the good setup at the beginning, time would be shorter. Five things below, in my opinion, are simple but very important that every software development team should do.

0. Working method

Very important. Remember that in the first step, we don’t have a team that targets the same goal, we have a group of people that works in the same project even though in a sustainable organization where the working method or process is defined. So what we need to form a team?

Mission & vision: No one works without the vision and objective. A group needs it at least to become a team. It’s a direction for team and also a glue to get people worked together.

Working agreement: What team commit to do? I try my best to complete the day job or I just want to work at most 6 hours daily no matter the result is? It must be agreed in team.

Write down mission & vision and working agreement in a eye-catching place to remind everyone in team. Before all, let’s discussed and agreed in team, and get everyone signed off.

Choose a working method: Everyone in team has to understand how they work together. It’s good to pick a “standard” method or framework to start with such as Scrum, Kanban… in order to help people more easily to understand and follow. In case of people don’t understand it right, make sure they get trained to reach the level of start.

Working method (or process) must be visualized

1. Team collaboration tools

When working method is set, team needs a tool for collaboration. If team chooses Scrum or Kanban, team board is more than important. It can be the physical board or online board such as Jira, Trello, Pivotal Tracker…

Choose a single official toolset. A lot of good communication tools today makes team difficult to decide. Slack or Skype? Google Docs or Zoho?… Then team never feels happy enough with one tool, Slack is good but Skype has better video call quality. Choose both? No. Let choose a single official tool where every main information, decision, solution… are placed there. Extra discussion can be worked over others that the contributors feel comfortable with. It helps people simply find the decision.

Choose a single official tool where every main information, decision, solution… are placed there

2. Source code version control

I don’t need to explain more about the needs of source code version control. Choose one that all team members are familiar with, otherwise it will become the headache by overhead. Git is the best one today. But Git is so uncomfortable without diff tools. Meld, Kdiff3, WinMerge… are the good tools that work for most of Git clients.

Choose which?

3. IDE & team environment settings

IDE / text editor is a sword to kill dragons. Find the best one. It’s so easy to have an agreement in team if the project is working on .NET, iOS… with the vendor tool. There’s a bit harder with the language or technology that can be done by many choices. TextMate or Atom, Sublime or InteliJ for PHP? Which is the best for Android, Eclipse or Android Studio?

Once team chooses a single IDE, set the team environment settings and make sure to manage it in the right place, good one usually is source code repository. Keeping team environment settings reduce the conflict issues that usually be the overhead. It also helps for continuous integration and continuous delivery.

Environment shouldn’t be a place for personal creativity at beginning. Do it later.

4. Continuous delivery pipeline

Agile is becoming standard working method today, then continuous delivery and continuous deployment is crucial. The age of continuous integration was passed by, team needs more powerful toolset that’s near production or staging. That’s why DevOps is becoming important in developing software service.

That’s a pattern for setting up a software project that should be longer than 2 months within more-than-3-persons team. It’s very important with the initial setup with a specific method or toolset the team uses – it becomes material for improvement after each iteration. Lacking of agreement on a single method or toolset get the road harder to success.

1,213 total views, no views today

Anti-IF pattern

November 15, 2017 by Hien Nguyen·Comments Off

Lập trình không dùng if-else, có được không?

If-else thật xấu xí

Đối diện với một bài toán, lập trình viên (LTV) thường phải trả lời câu hỏi: Đây là bài toán đặc thù hay phổ quát? Bài toán “số ít” hay “số nhiều”? Và thông thường, câu trả lời sẽ quyết định thành quả tiếp theo. Ví dụ, con chó kêu gâu gâu?” là bài toán số ít. Ta có thể viết thế này:

if (dog.startTalking())
    return "gâu gâu";

1 2	if (dog.startTalking()) return "gâu gâu";

Thật đơn giản. “Con chó kêu gâu gâu, con mèo kêu meo meo” thì sao? Vẫn là bài toán số ít thôi.

if (animal.startTalking()) { 
    if (animal == DOG)
        return "gâu gâu";
    else
        return "meo meo"; 
}

if (animal.startTalking()) {

if (animal == DOG)

return "gâu gâu";

else

return "meo meo";

}

Thật đơn giản. “Con chó kêu gâu gâu, con mèo kêu meo meo, con vịt kêu quạc quạc” thì sao? Vẫn là bài toán số ít thôi.

if (animal.startTalking()) { 
    if (animal == DOG) 
        return "gâu gâu"; 
    else if (animal == CAT)
        return "meo meo"; 
    else if (animal == DUCK) 
        return "quạc quạc";  
}

if (animal.startTalking()) {

if (animal == DOG)

return "gâu gâu";

else if (animal == CAT)

return "meo meo";

else if (animal == DUCK)

return "quạc quạc";

}

Thật đơn giản. À từ từ, chuyển sang switch cho đẹp mắt.

switch (animal) {
    case DOG:
        return "gâu gâu";
    case CAT:
        return "meo meo"; 
    case DUCK: 
        return"quạc quạc";
}

switch (animal) {

case DOG:

return "gâu gâu";

case CAT:

return "meo meo";

case DUCK:

return"quạc quạc";

}

Đẹp đẽ quá rồi. Tuyệt vời.

Bạn có thấy câu chuyện trên quen thuộc trong cuộc sống hàng ngày của LTV? Khi if-else bắt đầu phát huy sức mạnh, làm ơn đừng chuyển sang switch – chẳng hay ho gì đâu. Khi if-else bắt đầu phát huy sức mạnh, chính là khi nó bắt đầu trở nên xấu xí, chính là khi chúng ta cần phải xem lại cách đánh giá bài toán của mình. Đây không phải là bài toán số ít ngay từ đoạn code #2. Các LTV cần hiểu đúng đắn rằng đây là bài toán số nhiều ngay từ khi nó có dấu hiệu là bài toán số nhiều, thay vì cứ else-if và hy vọng giữ nó là bài toán số ít.

LTV có thể sống mà không cần if-else?

Có, dùng switch thôi. Không không, tiêu đề trên để cho vui thôi. Câu hỏi thực sự là “chúng ta có thể lập trình mà không sử dụng câu lệnh rẽ nhánh (conditional statement)?”. Vâng, không dùng if-else, switch,…?

Từ thưở đầu học lập trình, ai trong chúng ta cũng biết những thứ căn bản nhất của một ngôn ngữ lập trình (NNLT): variable, array, conditional, loop statement. Lâu dần chúng ta coi đó là điều nghiễm nhiên của một NNLT. Nhưng bạn cần biết rằng, âu lệnh if-else còn nhiều điểm xấu xí khác, từ logic cho tới runtime speed, memory… nên một số NNLT hoàn toàn không có if-else.

Vậy thì sống làm sao? Làm sao để giải bài toán trên mà không dùng if-else? OOP – polymorphism là một giải pháp. Thử xem:

class Animal { 
    talk(); 
} 

class Dog : Animal { 
    talk() {
        return "gâu gâu"; 
    } 
} 

class Cat : Animal { 
    talk() {
        return "meo meo"; 
    } 
} 

class Duck : Animal { 
    talk() {
        return "quạc quạc"; 
    } 
} 

// something here
animal.talk();

class Animal {

talk();

}

class Dog : Animal {

talk() {

return "gâu gâu";

}

class Cat : Animal {

talk() {

return "meo meo";

}

class Duck : Animal {

talk() {

return "quạc quạc";

}

// something here

animal.talk();

Không có gì huyền bí cả, bạn có thể tham khảo tại blog của Martin Fowler về pattern này.

Nếu bạn muốn thực hành nhiều hơn, có thể tìm đến Anti-IF pattern tại đây.

No if-else

Về lý thuyết, chúng ta hoàn toàn có thể lập trình mà không sử dụng if-else. Tại các buổi Code Retreat thường có 1 session mà LTV nhất định không sử dụng if-else khi lập trình ngay cả khi NNLT đó hỗ trợ. Mục tiêu là luyện tập khả năng ít phụ thuộc vào conditional statement để hình thành tư duy abstract. Như ví dụ trên, câu lệnh if-else thực sự quá mạnh mẽ, đến nỗi các LTV không thể tránh được cám dỗ, giải bài toán theo “số ít” và tạo ra những thiết kế sai lầm, vi phạm nguyên tắc open-closed cơ bản.

Nếu bạn chưa biết thực hành thế nào, hãy tới một buổi Code Retreat cho biết.

1,201 total views, 1 views today

Category: Do

Problems

Solutions

Facebook login

Remember me

Know issues

Vì sao ra đời?

Cái gì hay?

Cái gì dở?

Nên dùng thế nào?

synchronized cần phải tối thiểu

synchronized vẫn chưa đủ

Còn cách nào khác không?

Kết

Sử dụng Singleton và static trong class có gì khác nhau?

Có tự tin cài đặt đúng Singleton?

Cài đặt Singleton thế nào?

Chỉ có đúng 1 object được tạo ra?

Chỉ có đúng 1 object được tạo ra?

Chỉ có đúng 1 object được tạo ra?

Chỉ có đúng 1 object được tạo ra?

Kết

Winner takes all? Lúc nào cũng có bài toán để giải.

Thực sự không có gì? Chăm chỉ, tập trung và niềm tin thì sao?

Tìm được partner đúng gần như là tất cả.

Xây dựng đội ngũ: Tin tưởng và trao quyền là hành động, không phải bởi nói suông.

Xây dựng đội ngũ: Luôn có cơ hội với sự thật.

Xây dựng đội ngũ: Con người là đầu tiên và cuối cùng.

Linh hoạt hay là quan trọng: Chúng ta chẳng thể biết hết về ngày mai.

Phải làm, muốn làm và được làm: Ranh giới mong manh.

Khởi nghiệp: giấc mơ của bạn, không phải của chung.

Không nhậu không chết được đâu.

0. Working method

1. Team collaboration tools

2. Source code version control

3. IDE & team environment settings

4. Continuous delivery pipeline

If-else thật xấu xí

LTV có thể sống mà không cần if-else?

No if-else

If-else thật xấu xí