Lê Quang Khải's Blog

I don't mind the pain, it's the hope that kills me

Introducing React Native Progressive Input — September 25, 2016
Deploy Jenkins using Slack Command — May 15, 2016

Deploy Jenkins using Slack Command

Story 

You are engineer, you use Jenkins for deployment? There will be time when you are outside or cannot touch your laptop but you need to deploy something to the system, access to Jenkins web interface on mobile is a nightmare. Luckily your company is using Slack for team communication. This might save you from the nightmare by having a Slack command to trigger remote build on Jenkins.


How?

The above story was what happened to me recently, at that time I thought there must be something that help me to do what I want. Started some search on Google about trigger build remotely using Slack command. There are some blog posts about this, some open source projects on github to accomplish this too. Finally I picked up jenkins-slack-command of @joshdholtz. It’s a project written in ruby and sinatra, pretty simple, it’s also very convenient to get started as the readme has a shortcut to create an app on heroku. Just need to follow the readme and you will have a working Slack command. Great work! 

However, there is risk when you just stop at what’s being offered by the app. Everyone who knows the command can deploy everytime, no restriction, no authorization… That’s obviously not what I want. In order to overcome this, I forked there project and modified a little bit. Find my forked repo at: https://github.com/khaiql/jenkins-slack-command

What is the difference?

I added one more environment variable called SLACK_CHANNEL_ID. It is the ID of the only channel that members of it can trigger the build. So, create a private channel, add all people who should be able to deploy to that one. But how can you find your Slack channel ID? I made it very easy by print out all params submitted to the app via Slack command. After having your heroku app up and running, the Slack command is also available to use. Execute the command in the channel that can trigger the build. You will see an error message saying that you haven’t setup the variable properly, with others params, find the channel ID from that. Now you know what to do, right? Simply get to setting page of your heroku app, add the missing environment variable and there you go 😁.
During setting up, you may encounter error. This is because your Jenkins is asking for a known account. Config it to make it buildable with a token. This will expose your jobs to others, but they cannot build, it’s not a big problem, I think 😁.

That’s all. Wonder where is the instruction? Find in the readme, very easy. Enjoy 😁

Scott

Protected: The new year (2016) is coming and I’m writing this for you — December 31, 2015
Chuyển từ Rails sang Lotus, why not now? — June 21, 2015

Chuyển từ Rails sang Lotus, why not now?

Mở bài

Rails là gì? => cái này thôi chắc không cần giới thiệu

Lotus là gì? => nói ngắn gọn thì Lotus là một web framework mới, sử dụng ngôn ngữ Ruby, tuy vẫn đang trong giai đoạn phát triển nhưng rất tiềm năng và cũng hay ho (theo quan điểm cá nhân).

Gần đây thì trong cộng đồng đang rộ lên xu hướng chỉ trích Rails khá nhiều, đại loại là xoay quanh vài chủ đề như

  • Kiến trúc monolithic, cũ rồi, mốt thời thượng là microservices kia
  • Anti-pattern
  • Monkey patching
  • Performance kém (cái này là vấn đề chung của Ruby luôn rồi :s)

Và rồi người ta rủ nhau bỏ Rails, theo Golang, hay nodejs, hay Erlang…

Từ những vấn đề được nhìn thấy ở Rails, có một vài anh siêu nhân đứng ra phát triển Lotus, một framework khác cũng viết bằng Ruby. Vì sinh sau mà, nên tất nhiên Lotus phải giải quyết được những khiếm khuyết của Rails thì mới có hi vọng phát triển. Và đến hiện giờ thì hình như các anh ấy vẫn đang đi đúng theo con đường đó. Nói lang mang nãy giờ thì chốt một câu là cá nhân tui thấy Lotus nó hay nên viết bài nhảm về Lotus thôi :)))

Khó khăn

Thế tại sao nên chuyển sang Lotus bây giờ? Trước tiên nói về những khó khăn nếu chuyển từ Rails sang Lotus

  • Không quen :v, mặc dù đều là Ruby cả, nhưng lúc mới chuyển từ Rails sang Lotus thì cảm giác nó cứ kì kì thế nào ấy, tóm lại thì là do không quen :))
  • Ít document, tính đến giờ thì toàn mò mò đọc docs từ github của Lotus thôi chứ chưa thấy có nhiều bài tutorial hay book về Lotus như Rails
  • Gems, Ruby và Rails nổi tiếng một phần ở thư viện gem rất chi là bự của nó. Với Lotus, chúng ta vẫn có thể sử dụng được các Ruby gems, nhưng phải nói không với Rails gem. Rails gem tức là những gems mà depend on Rails ấy. Vậy nên nếu giờ làm Lotus thì… chắc phải tự viết khá nhiều😦
  • Vẫn còn chưa hoàn thiện, nếu so sánh với Rails thì hiện tại Lotus vẫn còn đang chưa cung cấp đủ các công cụ cho người dùng. Ví dụ, Rails có lệnh rails generate, Lotus cũng có lotus generate. Cơ mà Lotus thì chưa có lệnh lotus destroy như rails T_T, phải xóa bằng tay. Cơ mà chắc là chưa có thôi chứ không phải là không có.

Lợi ích

Khó khăn chồng chất, tuy nhiên, nếu chuyển sang dùng Lotus bây giờ, bạn sẽ nhận được gì?

  • Vì thiếu docs, tutorial nên khi nào gặp lỗi hay gì gì đó không chạy thì phải lọ mọ vào source code của Lotus để đọc xem nó được implement như nào, có phải bug của Lotus không hay bug của mình. Xem nhiều đâm ra hiểu, mà hiểu thì sẽ triển khai hiệu quả hơn => biết đâu còn có thể contribute cho Lotus
  • Vì thiếu gems nên phải tự viết, ví dụ như trong rails mình có devise, quá khỏe, cơ mà lotus thì không, tự viết đi nhé. Tuy có hơi cực nhưng bù lại mình hiểu chính xác mình cần cái gì, và chỉ implement vừa đủ dùng, không thừa, không thiếu. Vì thiếu gem nên biết đâu siêng siêng viết một cái gem cho cộng đồng, sau này lại được người ta dùng nhiều => một cảm giác thật là sung sướng :)).
  • Thiếu tutorial => nên giờ làm Lotus rồi viết blog, chia sẽ kinh nghiệm cho cộng đồng, lỡ sau này Lotus phát triển mạnh thì blog của bạn được người ta vào xem nhiều nhiều, tăng view, được nổi tiếng, hú hú :)))))

Rủi ro

Lợi có rồi, hại có rồi, giờ đến risk. Vì hiện tại Lotus vẫn đang trong gia đoạn phát triển, version mới cứ ra đều đặn vậy đó, dùng bây giờ sau này phải update chắc mệt lắm :-s. Ví dụ như hiện tại Lotus đang ở version 0.3.2, nhưng vài ngày nữa là launch version 0.4.0. Không biết khi official launch có thay đổi thât hay không nhưng mình có xem trước thì structure của 0.4.0 khác so với 0.3.2 :v. Cái risk nữa là lỡ bây giờ xài Lotus mà sau này nó chết yểu thì… (cơ mà chắc không đâu).

Kết bài

Mấy cái khó khăn, lợi ích, rủi ro lung tung trên kia là do mình đang mò mò làm Lotus, tự rút ra thôi, đúng sai không quan tâm. Bài viết nhảm đến đây là hết🙂

Project đang mần nè: https://github.com/khaiql/ss-tweets

pic6_thumb.png

Debug Ruby/Rails application with byebug — April 11, 2015

Debug Ruby/Rails application with byebug

1. Introduction

Nói đơn giản ngắn gọn thì byebug là một gem cung cấp các commands để hỗ trợ cho việc debugging ruby applications. Về chi tiết cụ thể, các bạn có thể xem thêm trên github của byebug. Các tính năng chính của byebug:

  • Stepping: thực thi các câu lệnh theo trình tự. Nếu trước đây bạn sử dụng các IDE như Visual Studio, Eclipse hay RubyMine, bạn có thể debug application step by step, ví dụ như step over, step in, step out. Tuy nhiên, nếu sử dụng text editor (sublime, emacs…), bạn không có sẵn các tính năng đó, cài thêm byebug, bạn sẽ có🙂.
  • Breaking: tạo breakpoint, conditional breakpoint…
  • Evaluating: Basic REPL functionality
  • Tracking: theo dõi sự thay đổi của variables hay các dòng lệnh khi thực thi

2. Commands trong byebug

Command Aliases Subcommands
backtrace btwhere
break
catch
condition
continue
delete
disable breakpoints display
display
down
edit
enable breakpoints display
eval
finish
frame
help
history
info args breakpoints catch display file files line program
irb
kill
list
method instance
next
pp
pry
ps
putl
quit exit
restart
save
set autoeval autoirb autolist autosave basename callstylefullpath histfile histsize linetrace listsize post_mortemstack_on_error verbose width
show autoeval autoirb autolist autosave basename callstylefullpath histfile histsize linetrace listsize post_mortemstack_on_error verbose width
source
step
thread current list resume stop switch
tracevar
undisplay
up
var all constant global instance local

3. Hướng dẫn sử dụng cơ bản

Phần này chỉ giới thiệu cơ bản cách sử dụng, để xem hướng dẫn đầy đủ, các bạn có thể xem tại trang guide của byebug. Trong phần này sẽ chỉ giới thiệu cách debug rails application. Khi muốn debug một dòng nào đó trong ứng dụng, bạn chỉ cần đặt câu lệnh byebug ở ngay phía trên dòng muốn debug. Về cơ bản, có thể xem bản thân lệnh byebug như là một breakpoint. Ở đây mình có một name_cards_controller và mình muốn debug action create (tạo mới một name card), nên mình đặt dòng lệnh byebug ở ngay dòng đầu tiên bên trong action create. Screen Shot 2015-04-11 at 11.14.18 AMTiếp theo, tiến hành chạy rails server, thực hiện hành vi sẽ gọi đến action create, tức là tạo mới một name_card object. Lúc này trong cửa sổ terminal của rails server, execution sẽ dừng ở dòng byebug. Screen Shot 2015-04-11 at 11.24.14 AMLúc này bạn có thể evaluate giá trị của các variable trong context hiện tại. Các commands bạn có thể hỗ trợ cho bạn:

  • next: move đến execution của dòng tiếp theo, ví dụ ở đây đang ở dòng 26, khi gõ next, con trỏ sẽ nhảy đến dòng 27
  • step: nếu tại dòng 26, bạn gõ step, byebug sẽ nhảy vào definition của method create_params, tương tự như khi bạn sử dụng step in trong các IDE phổ biến
  • up: tương tự như step out, sau khi step in tại dòng 26, debugger nhảy vào method create_params, muốn nhảy ra lại, các bạn gõ lệnh up
  • pp: viết tắt của pretty print, giúp bạn xem value của một variable nào đó đã được format cho dễ nhìn.
  • continue: thoát debugger và tiếp tục execution của app.
  • help <command>: xem description của command

Ngoài ra các bạn cũng có thể đặt thêm breakpoints bằng lệnh break, gõ h break để biết cách sử dụng.

4. Sử dụng byebug với sublime text

sublime-debugger là một project được phát triển từ byebug, cung cấp khả năng debug trực tiếp ngay trên sublime text như đặt breakpoint, next, step… Xem thêm cách cài đặt tại website của sublime debugger.

5. Hết bài
111614_1812_DependencyI4.png

Restore mongo database from remote to local in single command — March 14, 2015

Restore mongo database from remote to local in single command

If you are developing rails application with mongodb, sometime you may want to synchronise your production database, or remote database to local for development or testing purpose. The following command will help you do that:

mkdir tmp-dump && cd tmp-dump && mongodump --host [YOUR_DB_SERVER] -u [DATABASE_USER] -p [DATABASE_PASSWORD] -d [DATABASE_NEED_TO_RESTORE] rake db:drop && rake db:create && mongorestore && cd .. && rm -rf tmp-dump

Firstly, open terminal and change current directory to your rails app folder. Next, replace content in square brackets (and the brackets as well) with your corresponding information. Press ENTER and wait for the job done🙂

Credit: Li Soon – techlist developer

pic6_thumb.png


(adsbygoogle = window.adsbygoogle || []).push({});

Các giai đoạn đầu tư, phát triển của một startup — December 22, 2014

Các giai đoạn đầu tư, phát triển của một startup

Như thông thường, đầu tiên sẽ có một phần giải thích lý do của bài viết. Bài này thì không viết, phần lớn là dịch lại và biến tấu sơ sơ, vẽ vời chút ít cho vui từ bài viết gốc: How Funding Works – Splitting The Equity Pie With Investors. Tại dạo gần đây cứ suốt ngày nghe mấy cái funding rounds, như seed, rồi Series A, B, C, rồi exited, blah blah, mà không hiểu bản chất của nó lắm, vậy nên google. Thấy bài này viết hay, nội dung sinh động, cộng với việc đang bị rảnh cuối tuần nên viết cho vui. Vào chủ đề chính, vì đa phần là dịch lại nên đơn vị tiền tệ trong bài viết là dollar, ngữ cảnh cũng sang chảnh cỡ bên Mỹ, vậy nên đừng ai comment bảo, sao tiền nhiều thế nhé J.

Vào bài

Giả sử chúng ta có một startup kiểu mẫu, họ được đầu tư khoảng $15,000 từ gia đình và bạn bè, sau 3 tháng, họ được nhận thêm $200,000 từ angel investor, và $2 triệu từ một Venture Capital 6 tháng sau nữa. Nếu mọi thứ đều ổn, từ giả sử trên ta sẽ vẽ ra được infographic như hình bên dưới:

Đối lập với khái niệm ‘funding’ là ‘bootstrapping’, nghĩa là các công ty startup phát triển dựa vào nguồn vốn nội lực. Một vài công ty điển hình cho mô hình này là MailChimp và AirBnB.

Mỗi lần kêu gọi đầu tư, bạn sẽ phải chia bớt một phần cổ phần công ty cho người khác. Càng được đầu tư nhiều, lượng cổ phần bạn phải san sẻ càng nhiều, và mỗi người sở hữu cổ phần đều trở thành co-owner của công ty.

Bạn có thể liên tưởng cổ phần công ty như một cái bánh, và mỗi lần nhận được đầu tư, rõ ràng bạn phải để dành cho họ một phần của cái bánh (hay gọi là miếng bánh). Ban đầu thì cái bánh của bạn nhỏ xíu, nhưng qua mỗi lần đầu tư, cái bánh sẽ to dần lên, và một miếng bánh của cái bánh to to chắc chắn sẽ nhiều hơn so với cái bánh nhỏ xíu ban đầu của bạn.

Ví dụ như Google, Larry và Sergey, mỗi người sở hữu khoảng 15% của cái bánh, nhưng bạn thấy họ giàu như thế nào đấy :3.

Các giai đoạn đầu tư

Idea stage

Giai đoạn đầu tiên chỉ có mỗi bạn mà thôi. Bạn có một vài ý tưởng mà bạn cho là hay, rồi sau một thời gian đau đầu nhức não, ban quyết định chọn một ý tưởng tiềm năng nhất có thể để triển khai. Lúc này bạn sỡ hữu 100% cái bánh, nhưng mới là bánh vẽ, chưa có giá trị thực sự. Thực tế thì lúc này chắc bạn cũng chưa nghĩ đến chuyện mở công ty hay phần trăm cổ phần cổ phiếu gì đâu.

Co-founder stage

Khi bắt đầu triển khai, bạn sẽ nhận ra rằng việc triển khai một mình sẽ rất tốn thời gian, và cũng khó khăn nữa. Vậy là bạn quyết định tìm một người đồng sáng lập. Người này thường là ai đó mà bạn thân thiết, tin tưởng, hiểu được tiềm năng của ý tưởng mà bạn muốn làm. Sau một thời gian tìm hiểu, làm việc, bạn cảm thấy họ thật sự tâm huyết với dự án của bạn, bạn đề nghị họ trở thành co-founder của dự án. Lúc này thì cái bánh vẫn còn là bánh vẽ, và cổ phần cũng chỉ là thứ mơ hồ, không tiền, thứ quyền lợi duy nhất mà bạn có thể mang lại cho người bạn này sẽ chỉ có thể là, again, cổ phần. Mặc dù là mơ hồ nhưng nếu dự án thành công, mọi chuyện sẽ khác, bây giờ bạn cần quyết định bạn sẽ share bao nhiêu cho người đồng sáng lập? Lúc này bạn sẽ nghĩ, idea là của bạn, vậy nên bạn sẽ được hưởng % cao hơn so với người kia, đây cũng là suy nghĩ của chính mình khi offer 40% cổ phần cho một bạn co-founder trong project mà mình định triển khai. Tuy nhiên, nhờ đọc bài viết gốc, mình nhận ra rằng suy nghĩ này hoàn toàn là sai lầm. Cụ thể, ở thời điểm này, dự án của bạn cũng chưa có gì nhiều, tất cả chỉ có idea, nhưng ở thời đại mà 10 ý tưởng chỉ đáng giá một cốc bia, việc nghĩ rằng ý tưởng của mình là độc nhất vô nhị quả thật là thiển cận. Người bạn đồng sáng lập cũng phải bỏ ra công sức gần như bạn, cũng sẽ chịu những rủi ro nhất định, vậy nên bạn nên chia cho họ 50% cổ phần, nếu không bạn sẽ làm giảm động lực của chính người co-founder. Trong hợp tác, ta cần tôn trọng đối tác của mình, và bản chất của tôn trọng trong trường hợp này chính là sự công bằng.

Nếu cả hai bạn vẫn đi làm công việc full-time để có chi phí trang trải cuộc sống, dành thời gian còn lại để phát triển idea thì không có gì đáng nói. Nhưng nếu như vậy thì khả năng dự án fail, hay thời gian phát triển bị kéo dài ra là rất cao, bởi bạn sẽ không còn đủ thể lực để tiếp tục làm việc sau 8, 9 tiếng làm việc ở cơ quan. Thông thường, bạn và co-founder sẽ sử dụng khoản tiền tiết kiệm được để sống sót trong khoản thời gian làm việc full-time để phát triển sản phẩm. Cho đến khi… cả hai cùng hết tiền. Lúc này bạn nghĩ đến việc kêu gọi đầu tư để có thể tiếp tục thực hiện ước mơ của mình. Bạn có thể tìm đến các vườn ươm, hay các nhà đầu tư mạo hiểm (Venture Capital), tuy nhiên, ai sẽ đầu tư cho một sản phẩm thậm còn chưa có hình hài cụ thể. Vậy nên bạn nghĩ đến những nguồn đầu tư khác, gọi là

The Family and Friends Round: ngay từ tên gọi, đây là lúc bạn có thể kêu gọi đầu tư từ chính gia đình hay bạn bè. Giả sử như chú của bạn rất giàu, bạn chấp nhận đổi 5% cổ phần lấy $15,000. Vậy là bạn có thêm tiền để sống và phát triển dự án trong vòng 6 tháng tới. Bên cạnh gia đình hay bạn bè còn có một dạng nhà đầu tư gọi là ‘accredited investors’, là những người có từ 1 triệu dollar trong ngân hàng, hay có thu nhập hàng năm vào khoảng $200,000, là những người đủ thông minh để có những đầu tư khôn ngoan, mạo hiểm. Tìm được đầu tư từ những người như vậy chủ yếu dựa vào quan hệ xã hội của bạn.

Đăng ký công ty

Để đảm bảo tính pháp lý cũng như quyền lợi cho người chú đã đầu tư cho bạn $15,000, bạn cần phải đăng ký công ty của mình với cơ quan chức năng, quy định rõ người chú sẽ sỡ hữu 5% cổ phần. Ngoài ra, bạn còn để dành 20% cổ phần cho ‘những nhân viên trong tương lai của bạn’, gọi là option pool. Bạn không nhất thiết phải để dành lượng cổ phần này, tuy nhiên, việc này không phải không có lợi:

  1. Những nhà đầu tư sẽ muốn có một phần option pool
  2. Bạn và co-founder có thể sử dụng lượng cổ phần này khi cần làm việc gì đó

The angel round

Với số tiền $15,000 của ông chú giàu có, 6 tháng tiếp theo nhanh chóng trôi qua, và tiền lại hết. Bây giờ để tiếp tục có thể phát triển dự án, bạn cần phải kêu gọi thêm đầu tư. Các lựa chọn bạn có thể có lúc này:

  1. Các vườn ươm doanh nghiệp, hay một vài doanh nghiệp hỗ trợ startup – tại đây bạn sẽ được cung cấp tài chính, nơi làm việc và cả advisors. Tuy nhiên nguồn tài chính thì khá hạn hẹp, khoảng $25,000, chỉ chiếm khoảng 5 đến 10%. Ở TP HCM thì có SHTP ở khu công nghệ cao, hình như MLab cũng dạng này, tất nhiên Google is free, nên nếu bạn quan tâm có thể tìm hiểu thêm.
  2. Angels – thiên thần – Am I talking about Di Maria? Đùa thôi, angel ở đây là các nhà đầu tư. Mức đầu tư bình quân ở angel round là khoảng $600,000 (theo số liệu HALO report). Tuy nhiên, các ‘thiên thần’ cũng không phải là nhà đầu tư mù quán, họ chỉ chịu bỏ tiền nếu họ thấy công ty của bạn đáng giá khoảng 2.5 triệu đô. Làm sao để biết công ty của bạn đáng giá bao nhiêu? Không biết, việc của bạn là cố gắng chứng minh tiềm năng và những gì bạn đang có, càng nhiều càng tốt. Giả sử bạn có thể show ra vài prototype cho dự án, và bạn tìm được một angel nào đó. Họ đánh giá dự án của bạn khoảng 1 triệu đô, vậy nên họ đầu tư vào $200,000, great \m/

Vậy cổ phần mà bạn phải chia cho angel là bao nhiêu phần trăm? 20% không phải là câu trả lời đúng. Tổng giá trị công ty của bạn lúc này sẽ bằng giá trị trước khi được nhận đầu tư, cộng khoản tiền sẽ được đầu tư:

equa 1

Như vậy, lượng cổ phần bạn phải chuyển nhượng cho angel là 200,000/1,200,000 = 1/6 = 16.7%

Chia lại cái bánh

Bây giờ bạn phải chia lại cổ phần cho mọi người, bao gồm bạn, co-founder và ông chú. Vì angel sẽ có 1/6 cái bánh nên lượng cổ phần còn lại của mỗi người sẽ bị trừ đi 1/6 (xem infographic).

Oh man, miếng bánh của bạn vừa bị giảm đi, liệu có đáng lo? Câu trả lời là không, vì mỗi lần nhận được đầu tư, cái bánh của bạn sẽ to hơn, do đó lượng giá trị bạn sở hữu cũng sẽ tăng lên. Tuy nhiên, mọi sự việc đều có tính chất hai mặt. Vì qua mỗi vòng đầu tư, bạn sẽ mất dần quyền quản lý công ty của bạn. Vậy nên, hãy chỉ nên kêu gọi đầu tư khi cần thiết. Chỉ nên nhận tiền từ những người bạn tin tưởng và tôn trọng.

Venture capital round

Cuối cùng, dự án của bạn cũng gần hoàn thiện, nhờ các khoản đầu tư duy trì trước đó, đã đến lúc bạn phải release version đầu tiên ra thị trường. Bạn bắt đầu tiếp cận đến các nhà đầu tư mạo hiểm, VCs. Các VCs sẽ cho bạn bao nhiêu? Không dưới $500,000. Giả sử lúc này công ty của bạn được đánh giá khoảng 4 triệu dollar, họ quyết định đầu tư cho bạn 2 triệu, công thức tính toán cổ phần của VC và những người đã tham gia trước đó cũng tương tự như angel round:

equa 2

Bây giờ công ty không còn là của bạn nữa, nó đã thuộc quyền kiểm soát của nhà đầu tư. Vòng đầu tư đầu tiên từ VC gọi là Series A. Sau này bạn có thể kêu gọi thêm các nhà đầu tư khác, tên gọi các vòng tương ứng sẽ là Series B, C… Đến một lúc nào đó, sẽ có một trong ba trường hợp sau đây xảy ra:

  • Bạn xài hết tiền của nhà đầu tư, không ai chịu đầu tư thêm nữa => bạn die
  • Bạn nhận được lượng tiền đầu tư đủ để xây dựng lên một đế chế khiến cho các doanh nghiệp lớn phải e ngại, hoặc thích thú, và quyết định mua lại công ty của bạn.
  • Sản phẩm của bạn rất tốt, mọi việc đi đúng hướng, mang lại lợi nhuận, sau nhiều vòng đầu tư, bạn quyết định công khai doanh nghiệp (go public), niêm yết công ty lên sàn, hay gọi là IPO.

Tại sao lại IPO?

Về bản chất, IPO chỉ là một cách khác của việc kêu gọi đầu tư, nhưng lần này bạn có thể nhận tiền từ hàng triệu người. Thông qua việc IPO, công ty có thể bán cổ phần trên thị trường chứng khoán, và ai cũng có thể mua cổ phần của công ty bạn. Do đó, bạn có thể nhận được tiền đầu tư dễ dàng hơn thông qua việc bán bớt cổ phần, đây chính là lý do đầu tiên.

Lý do thứ hai, trước khi IPO, những người tham gia vào dự án của bạn, bao gồm cả bạn đều giữ những cổ phiếu giới hạn – restricted stock. Bạn không thể chỉ đơn giản mang những cổ phiếu này ra chợ và bán để lấy lại tiền, vì chúng chưa được chứng thực bởi cơ quan chức năng. IPO sẽ làm việc này. Vậy nên, trước khi được kiểm chứng, ai dám chắc bạn không treo đầu dê bán thịt chó, ai dám chắc những người mua cổ phiếu của bạn sẽ không bị lừa đảo. Chính nhờ IPO, bạn và các nhà đầu tư khác có thể bán, biến lượng cổ phiếu này thành tiền thật.

Ngoài ra còn có một nhóm người muốn bạn thực hiện việc IPO – những nhà ‘investment bankers’, không biết dịch ra tiếng Việt như nào, nhưng đại loại là những công ty trong lĩnh vực tài chính có uy tín, ví dụ như Goldman Sachs hay Morgan Stanley, xem thêm định nghĩa tại đây. Họ sẽ gọi cho bạn, đề nghị được hỗ trợ cho bạn toàn bộ những thủ tục hành chính, giấy tờ liên quan đến IPO, chủ động liên hệ với những khách hàng tiềm năng và bán cổ phiếu giúp bạn. Tất nhiên, không ai làm không công cả, đổi lại, investment banker sẽ được hưởng 7% tổng giá trị bạn thu được thông qua IPO. Như trong infographic, startup của bạn raised được $235,000,000 trong đợt IPO, như vậy họ sẽ nhận được 7%, tức là khoảng 16.5 triệu (chỉ trong vòng 2 đến 3 tuần làm việc của một team khoảng 12 chuyên viên ngân hàng). So great!!

Trở thành nhân viên đầu tiên của một startup

Nội dung cuối cùng của bài viết, đã bao giờ bạn nhận được lời mời tham gia phát triển startup, và được hứa hẹn chia cổ phần chưa? Chắc rồi. Thông thường, ở thời điểm đầu của dự án, bạn không thể trả lương cao cho nhân viên được, ngoài ra còn cả những rủi ro cho nhân viên trong trường hợp công ty của bạn fail chẳng hạn, vậy nên bạn đồng ý chia cho họ một phần miếng bánh, để họ làm việc cùng với bạn. Và IPO chính là thời điểm đổi đời của người nhân viên đó.

The end.

P.S: bài dài mà ít hình quá, chắc ế, lol

pic6.png

Status sáng thứ 4 — November 26, 2014

Status sáng thứ 4

Sài Gòn chẳng mấy người quen, cơ mà ngẫm lại thì cũng không hẳn. Có quán cafe, đến nơi không cần gọi, không cần lên tiếng, cứ lững thừng ngồi. Cô chủ quán đợi mình ăn sáng xong mới mang ra ly cafe với ly trà nóng. Đó không phải là quen thì gọi là gì.

1476308_718707471474400_668715029_n

Sáng đi làm, dù dậy sớm hay dậy trễ, chả hiểu sao vẫn rề rà đến 9h kém mới dắt xe ra khỏi nhà. Rồi lại vội vội vàng vàng, lượn lách, đánh võng, chạy cho lẹ để còn kịp đến quán uống cafe, thế mới lạ!

Hết!

Dependency Injection (DI) in ruby — November 17, 2014

Dependency Injection (DI) in ruby

Dependency Injection là gì?

Theo Wikipedia

Đại khái thì dependency injection là một pattern trong thiết kế phần mềm, thường được áp dụng để đảm bảo không vi phạm nguyên lý dependency inversion trong thiết kế hướng đối tượng. Tham khảo SOLID princinles.

Toàn bộ phần định nghĩa trên chung quy lại cũng chỉ là… định nghĩa, chắc mọi người đọc xong cũng chưa hình dung được DI thực chất để làm gì. Vậy mục đích, hay lợi ích mà DI mang lại là gì? Như đã nói trong phần định nghĩa, DI thường được áp dụng để tuân theo nguyên lý dependency inversion. Mục đích của dependency inversion là để giảm sự phụ thuộc trực tiếp giữa các đối tượng, thay vào đó nên có sự phụ thuộc trung gian thông qua một lớp trừu tượng, như vậy sẽ tạo sự linh hoạt, dễ bảo trì cũng như thay đổi khi cần thiết. Hình như vẫn còn khá… mơ hồ. Tóm tắt lại thì người ta dùng DI để có thể dễ dàng thay đổi sự phụ thuộc vào một object ở run time, áp dụng nhiều nhất và thiết thực nhất trong testing. Đến đây thì hết biết giải thích tiếp như nào để khỏi mơ hồ luôn.

Trong các ngôn ngữ lập trình như C# hay Java, DI là một pattern rất quan trọng, người ta còn viết ra các thư viện IoC container, mục đích là để inject đúng dependency object vào đúng nơi, đúng lúc. Tuy nhiên, với Ruby thì khác, đây là một ngôn ngữ rất mở, meta programming rất mạnh, ngoài ra còn có method stub rất lợi hại, ví dụ:

def publish!

self.update published_at: Time.now

end

Với các ngôn ngữ khác, method này rất khó để test vì giá trị của Time.now thay đổi theo thời gian, ta cần áp dụng DI thì mới có thể test dễ dàng được. Nhưng với Ruby, mọi chuyện hết sức dễ dàng:

Time.stub(:now) { Time.new(2012, 12, 24) }
article.publish!
assert_equal 24, article.published_at.day

Chính vì vậy nên hiện tại vẫn có hai luồng tranh luận khác nhau rằng DI có cần thiết cho Ruby hay không. Vụ này mọi người có thể thảo luận thêm với nhau trong phần comment. Riêng quan điểm của mình thì là cần thiết, tại sao? Tại vì nó giúp đảm bảo code vẫn tuân theo nguyên tắc Dependency Inversion trong SOLID, mà đã tuân theo thì ắt hẳn là có lợi nhiều hơn hại (cho maintenance, changing…). À lý do nữa đó là nếu mình bảo là không cần thiết thì sẽ không có phần bên dưới của bài viết này😀.

Ví dụ

Thông thường, có ba cách để hiện thực dependency injection:

  • Thông qua property (attribute accessor)
  • Thông qua constructor
  • Thông qua method parameter

Giả sử có class Car (xe hơi), xe hơi thì cần có động cơ, khởi động xe hơi tức là khởi động động cơ, tức là method start của xe hơi sẽ gọi đến method start của động cơ (Bridge pattern):

Ở ví dụ trên thì chúng ta áp dụng DI thông qua attribute engine, và ta cũng implement một getter method trả về giá trị default. Giả sử nếu không muốn sử dụng default engine, ta có thể khởi tạo một object khác:

Cách dùng constructor hay method parameter cũng không khác mấy, tùy vào tình huống mà ta sử dụng linh hoạt.

Tham khảo:

Strategies for Rails Logging and Error handling — October 30, 2014

Strategies for Rails Logging and Error handling

Today I have some questions about how the logging is doing in our project – Techlist. From Justin, he said that we don’t usually log the exception by catching them in the rescue block but use some gem for automatically handle this for us, Redis, for example, not sure if I really catch what he means😀. From my past projects with .NET, I logged the exceptions and stack trace to db, then I find it’s really easy for me to figure out what was wrong, so I think it’s really weird, especially for RoR, so I decided to investigate to this topic.

After reading some blogs, I think it is worth to write down what I leant. For all products we release to customer, it’s really bad if we don’t know what was wrong, where it happened, it’s even worse if:

  1. You don’t have a clear log message that identify exactly what went wrong
  2. You didn’t get automatically notified via email that something went wrong. Instead, the customer told the customer service rep that there’s an issue, the responsible developers should be notified

You see, logging is indeed important for every projects, RoR is not an exception also. However, logging is art, yeah, and developer who writes log appropriately is an artist, j/k. I will not mention about how to setup logger in this post, google is free. I will just quote the “logging strategy in rails” got from this blog.

  1. Avoid rescuing/catching if you can’t do anything with the exception. For example, in a model method, you might be calling that from a controller, but you also might be calling that from some scheduled job. Thus, it’s hard to say what the right action should be. A special case is calling raise without arguments: sometimes it is reasonable to catch all exceptions, logging the exception, and then re-raising it like it was never caught.
  2. If you catch an exception, consider if you should re-throw the exception because code at a different level will be able to handle the exception more properly.
  3. Consider how the code is being invoked, such as from a call to generate HTML or an ajax request, or maybe a batch job. All of these cases have very different needs for how the error should be handled.
  4. Be sure you understand the order of your rescue clauses matter. This article The Universe between begin and end provides a good explanation. Basically put the most specific exception types first and something like rescue => e last.
  5. Ruby does not support the concept of a “cause” with an exception. Thus, if you catch an exception and are going to re-throw a different exception, then it’s important to log the stack of the original exception, or else that information will be lost.
  6. Test the logging of the exception in both development and production mode. You want to ensure that any exception prints clearly regardless of Rails environment.
  7. A good way to test error handling is to temporarily put in raise ArgumentError (or whatever other error), and see how the exception is handled, both by the logger and the UI.
  8. The worst scenario is catching an exception and failing to log any messages. This can make troubleshooting a problem very tricky.

That’s all, you may say that “hey, why did you write it in English, your readers are Vietnamese”. Hmm, the reason is that I’m so lazy to translate the “quoted content” to Vietnamese, so I chose English, even my English is not very good, lol. Forgive my laziness, please😀

%d bloggers like this: