If you are having this issue with latest Pock (0.8.1-5), you can follow instructions in this post to resolve it.

TL;DR: Downgrade the Dock widget to default version, drag it to Touch Bar and upgrade it to latest.

Downgrade the Dock widget

• Download the default version of Dock widget here.
• Unzip & Drag it to Install Widget popup from Pock.

Drag the Dock widget to Touch Bar

Upgrade the Dock widget to latest

Get Pock

For macOS only

Neovim’s Config

Neovim’s Config. GitHub Gist: instantly share code, notes, and snippets.

Gist262588213843476

EpicGames đang cho lấy free Grand Theft Auto V - Premium Edition (giá gốc là 24.99$). Anh em nào thích chơi GTA 5 mà chưa có điều kiện mua thì làm theo các bước dưới đây.

• Đăng ký tài khoản EpicGames Store nếu chưa có.
• Bật bảo mật 2 lớp (2FA) cho account.
• Vào link dưới để add game vào account của mình.

Grand Theft Auto V - Grand Theft Auto V: Premium Edition

The Grand Theft Auto V: Premium Edition includes the complete GTAV story, Grand Theft Auto Online and all existing gameplay upgrades and content. You’ll also get the Criminal Enterprise Starter Pack, the fastest way to jumpstart your criminal empire in GTA Online.

Epic Games Store

Chú ý: Hạn cuối cùng để lấy game free là ngày 21/05.

Nhiều thay đổi quá :D

New features

• Memberships & subscriptions
• New Wordpress Importer Plugin
• Support Image Galleries
• Bookmark Card
• Casper 3.0
• More free themes + Starter Theme for development
• Refreshed Ghost Admin
• Continuous Integration with Github Actions

Read more: Ghost 3

Vào một buổi sáng đẹp trời ngày nọ, mình đến công ty vào lúc 7h30, nhai tạm cái bánh mì que mua ở trên đường đi làm, thảnh thơi pha thêm cốc cafe cho tỉnh hẳn ngủ. Tranh thủ mở Slack ra check chợt thấy khách hàng kêu gào từ hơn 1 tiếng trước, nguyên nhân là end user phát hiện ra 1 lỗi liên quan đến phần điền thông tin vận chuyển trong màn hình thanh toán. Vứt cái bánh mì gặm dở sang 1 bên, mình vâng vâng dạ dạ với KH rồi bắt đầu mở server lên tái hiện lại thì thấy có bug đó thật.

Trong bụng lúc đó nghĩ: "Lạ vãi, chức năng này mình làm cũng gần nửa năm rồi, lúc đó cả KH cũng test xong rồi mới delivery mà giờ lại đẻ ra bug :-s". Vậy chỉ có thể là có ông nào đó sửa mất hàm dùng chung rồi không test kĩ lại rồi. Dự án này mình làm với khoảng hơn 10 người nữa nên chắc điều đó là điều không thể tránh khỏi. Tóm lại là phải tìm ra và fix càng nhanh càng tốt sau đó release hotfix để tránh ảnh hưởng đến end user.

Mở gitk ra xem từ lần release chức năng của mình có ai sửa file gì liên quan không thì thấy gần 200 commit liên quan 😳 WTF. Giờ mà ngồi dò từng commit kiểu checkout rồi tái hiện lại cũng hết cả hơi 🥶

Thử checkout vài commit gần đây nhất để check thì thấy bug đã có rồi, có nghĩa là cần phải check thêm những commit cũ hơn nữa. Nghĩ tới việc ngồi checkout lần lượt 200 commit để test làm mình toát mồ hôi hột, thôi thì nghĩ thử xem có cách nào lười được không? Cái khó ló cái khôn, hay là thử áp dụng tìm kiếm nhị phân xem, cứ chia đôi chỗ commit từ commit không lỗi của mình đến commit mới nhất. Sau đó kiểm tra xem tại commit đó có lỗi không, nếu không có lỗi thì mình tìm ở nửa còn lại, nếu có lỗi thì tiếp tục chia đôi và tìm tiếp.

Cách này có vẻ khả thi và đỡ tốn công hơn cách trước rồi, nhưng có 1 cái bất tiện đó là mình phải tự đếm và chia bằng tay, ngồi thử làm 1 step thì thấy ngồi dò dò rồi đếm từng commit vẫn mệt quá 😅Thử Google xem có cách nào đếm và chia commit theo kiểu binary search với keyword "git binary search" thì thấy kết quả đầu tiên nói về git bisect. Click đọc thử thấy mừng quá, đây đúng là thứ mình cần rồi.

git-bisect - Use binary search to find the commit that introduced a bug

git-bisect là một tool có sẵn trong package Git, nó sử dụng thuật toán tìm kiếm nhị phân để tìm ra commit đầu tiên gây ra bug.

Cách sử dụng cũng khá đơn giản như sau:

• Chạy tool git-bisect.
• Báo với git-bisect biết commit nào không bug (good), commit nào có bug (bad).
• git-bisect sẽ chạy từng bước và checkout 1 commit, mình chỉ việc check lại commit đó có bug hay không bằng cách nói với nó good hoặc bad.
• Sau khi chạy xong các bước, git-bisect sẽ chỉ ra commit đầu tiên mà gây ra lỗi.

# Bắt đầu git-bisect
git bisect start

# Báo cho git-bisect biết commit không có bug (commit hash: abcdef)
git bisect good abcdef

# Báo cho git-bisect biết commit có bug (commit hash: fedcab)
git bisect bad fedcab

# Sau khi git-bisect chạy qua mỗi step, check lại bug và report
# Report bad nếu commit hiện tại có bug
# Report good nếu commit hiện tại không bug
git bisect bad
git bisect good

# Đến step cuối cùng, git-bisect sẽ show ra commit đầu tiên mà gây ra bug.

Vì việc show commits vi phạm an toàn thông tin cho nên mình sẽ không show ra, nhưng hy vọng video dưới đây sẽ giải thích được cũng như hướng dẫn cách sử dụng git bisect cho mọi người.

Ngoài cách sử dụng git bisect thủ công như trên, mình có thể chạy git bisect tự động thông qua git bisect run <command>. Lúc đó, ở mỗi step, git bisect sẽ tự động thực thi command mà mình đã set, nếu command đó có exit code là 0 đồng nghĩa với good, khác 0 đồng nghĩa với bad.

Giả sử mình đang có 1 API bị lỗi, server trả về response không đúng, mình sẽ viết một đoạn script nhỏ trong đó thực hiện tạo 1 request đến API đó, nếu trong response trả về đúng như ý muốn của mình thì sẽ exit 0, còn không thì exit 1. Và chỉ cần như thế, git bisect sẽ làm nốt phần việc còn lại cho mình, mình có thể dành thời gian làm việc khác thay vì mất công ngồi reproduce bug bằng tay.

git bisect start

git bisect good abcdef
git bisect bad defabc

git bisect run python3 request.py

Vậy là sau một hồi mày mò tìm hiểu, cũng nhờ bản tính lười có sẵn trong người mà mình đã tiết kiệm được khá nhiều thời gian ngồi điều tra bug, nếu mà cứ làm bằng tay kiểu trâu bò chắc cũng mất cả ngày trời 😳Sau khi fix được bug, KH cũng rất vui mừng và dành hết lời khen ngợi tinh thần làm việc cũng như chất lượng công việc của mình với cấp trên của mình. Cũng chính vì đó mà cuối năm đó mình đã được công ty trao tặng 1 cái cúp cực kì ý nghĩa với mình 🤪

Hy vọng bài viết này sẽ có ích với mọi người. Cái đoạn trên mình viết cho vui chứ không phải thật đâu 😬😬😬Hẹn mọi người ở bài viết khác nhé.

Vừa rồi mình có làm GitHubArchive, đây là một project mã nguồn mở có chức năng gửi email thống kê các top các repository của GitHub trong ngày. Cụ thể là top 25 repository mới nổi được nhiều người đánh dấu (star) nhất và top 25 repository được nhiều người đánh dấu (star) nhất trong ngày.
Bạn có thể xem qua về newsletter này ở đây.

Khi làm xong project này, mình phải chạy cronjob để lấy dữ liệu theo thời gian định kỳ (1 ngày/3 ngày/7 ngày) vào lúc 0h sáng.

Cấu trúc của một cronjob như sau:

Nếu muốn cronjob chạy 1 ngày/lần lúc 00:00 thì chỉ cần dùng cấu trúc: 0 0 * * * ruby daily.rb

Tuy nhiên, để chạy 3 ngày/lần hay n ngày/lần thì không đơn giản chỉ dùng 0 0 */3 * *. Bởi vì nếu tháng nào có 31 ngày thì cronjob sẽ chạy liên tục 2 ngày liên tiếp 31 và ngày 1 tháng sau => sai.

Bạn có thể xem thống kê các lần chạy ở dưới đây: (Mình lấy mốc là ngày 2015-03-25)

hoặc đây

Vấn đề được đặt ra là: Làm thế nào để cronjob chạy được chính xác mỗi N ngày xác định nào đó? N ở đây thậm chí có thể lớn hơn 31?

Cách 1: Lưu lại lần chạy cuối cùng và check mỗi khi chạy.

Cách này mình đã từng dùng ở 1 số project đã từng làm, cụ thể như sau:

• Set cronjob chạy script 1 ngày 1 lần.
• Sau mỗi lần script chạy, lưu lại thời gian chạy vào DB hoặc file.
• Trước khi script được chạy, check khoảng thời gian từ lần chạy cuối cùng đến thời gian hiện tại, nếu số ngày cách nhau bằng N thì xử lý tiếp, còn không thì không xử lý nữa.

# crontab -e
0 0 * * * ruby 3days.rb

N = 3 # days
last_execution = read_file('/data/execution_logs.txt')
if day_diff(current_date, last_execution) != N:
  return
# Your logic
# Example: Send campaign email
write_file('/data/execution_logs.txt')

Cách 2: Tính toán trực tiếp từ Unix time.

Note: Cách này sẽ gặp vấn đề với DST (Daylight Saving Time) và các múi giờ khác UTC.

Với những ai chưa biết Unix time là gì thì đây là định nghĩa trên Wikipedia.

Thời gian Unix (tiếng Anh: Unix time, Epoch time hay POSIX time) là hệ thống mô tả một điểm trong thời gian. Thời gian Unix được định nghĩa bằng số giây kể từ 00:00:00 theo giờ Phối hợp Quốc tế (UTC) ngày 1 tháng 1 năm 1970, trừ đi giây nhuận. Mỗi ngày được xử lý như thể nó chứa chính xác 86400 giây, vì vậy số giây nhuận sẽ không được tính.

Đây là cách lấy ra Unix time cho 1 số ngôn ngữ, những ngôn ngữ khác bạn có thể tự tìm hiểu thêm nhé.

# Python
import time
int(time.time())

# PHP
strtotime('now');

# JS
# Do now() và getTime() trả về millisecond, không phải second nên phải chia cho 1000
Math.floor(Date.now()/1000)
Math.floor(new Date().getTime()/1000)

# MySQL
SELECT UNIX_TIMESTAMP();

# Bash
date +%s

Ý tưởng của cách này chính là chia nhóm các ngày kể từ 1970-01-01 00:00 (the Epoch) cho đến thời gian mà bạn chọn theo N ngày. Cụ thể là đổi ngày sang Unix time để tính ra số ngày kể từ the Epoch và dùng phép toán Modulo (phép toán chia số lấy số dư) để lấy ra những ngày có số dư giống nhau khi chia cho N.

Giả sử N của mình là 3, và mốc thời gian mình chọn là 2019-02-19 00:00 thì mình sẽ chia nhóm như sau:

# https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date/UTC

# Group 1
1970-01-01 00:00 => 0 mod 3 = 0 (Date.UTC(1970,0,1,0,0,0,0) / 1000 / 86400 % 3 === 0)
1970-01-02 00:00 => 1 mod 3 = 1 (Date.UTC(1970,0,2,0,0,0,0) / 1000 / 86400 % 3 === 1)
1970-01-03 00:00 => 2 mod 3 = 2 (Date.UTC(1970,0,3,0,0,0,0) / 1000 / 86400 % 3 === 2)


# Group 2:
1970-01-04 00:00 => 3 mod 3 = 0 (Date.UTC(1970,0,4,0,0,0,0) / 1000 / 86400 % 3 === 0)
1970-01-05 00:00 => 4 mod 3 = 1 (Date.UTC(1970,0,5,0,0,0,0) / 1000 / 86400 % 3 === 1)
1970-01-06 00:00 => 5 mod 3 = 2 (Date.UTC(1970,0,6,0,0,0,0) / 1000 / 86400 % 3 === 2)


...


# Group ...:
...
2019-02-18 00:00 => 17945 mod 3 = 0 (Date.UTC(2019,1,18,0,0,0,0) / 1000 / 86400 % 3 === 2)
2019-02-19 00:00 => 17946 mod 3 = 0 (Date.UTC(2019,1,19,0,0,0,0) / 1000 / 86400 % 3 === 0)
2019-02-20 00:00 => 17947 mod 3 = 0 (Date.UTC(2019,1,20,0,0,0,0) / 1000 / 86400 % 3 === 1)
2019-02-21 00:00 => 17948 mod 3 = 0 (Date.UTC(2019,1,21,0,0,0,0) / 1000 / 86400 % 3 === 2)
2019-02-22 00:00 => 17949 mod 3 = 0 (Date.UTC(2019,1,22,0,0,0,0) / 1000 / 86400 % 3 === 0)
...

Từ kết quả phía trên, có thể nhận thấy nếu chọn mốc là 2019-02-19 00:00 thì để script có thể chạy 3 ngày 1 lần liên tục mình chỉ việc cho script chạy vào những ngày có cùng kết quả mod 3 bằng 0.

Cuối cùng, thay vì cách 1 phải lưu lại lần chạy gần nhất vào file hoặc DB rồi lấy ra so sánh thì ta chỉ cần tính toán bằng một vài phép toán đơn giản như trên thôi.

# crontab -e
0 0 * * * ruby 3days.rb

N = 3 # days
NUMBER_SECONDS_A_DAY = 86400
first_execution = '2019-02-19 00:00'
remainder = (unix_time(first_execution) / NUMBER_SECONDS_A_DAY) % N
# Or hard-code remainder for faster calculation
# remainder = 0

if current_unix_time % N !== remainder:
  return
# Your logic
# Example: Send campaign email

Mình thì mình không thích viết phần điều kiện check trên trong script cho lắm nên mình thường viết luôn trong file crontab như sau:

# crontab -e
0 0 * * * bash -c '(($(date +\%s) / 86400 \% 3 == 0)) && ruby 3days.rb'

Trên đây là 2 cách mà mình biết để xử lý vấn đề phổ biến với crontab đó là chạy cronjob tuần tự theo số ngày định sẵn. Bài này được bắt đầu viết từ đầu năm 2015 mà giờ mới viết xong thế nên câu cú lủng củng hay sai chỗ nào thì comment cho mình biết với nhé 🤪

Hiện tại thì project GitHubArchive của mình cũng đã dừng hoạt động rồi, nếu bạn quan tâm tới newsletter tương tự như thế thì hãy subscribe ChangelogNightly nhé 😁

Porkbun đang liên kết với CSSWeekly/SitePoint để tặng cho người dùng mua domain .design miễn phí năm đầu tiên. Có vẻ như chương trình này diễn ra thường niên thì phải vì năm ngoái mình cũng đã lấy 1 cái rồi. Chú ý là sang năm tiếp theo phí sẽ là 34.48$ nhé.

Ngoài được free 1 năm domain, PorkBun còn cho thêm 1 mailbox có giá trị 24$/năm để làm email cá nhân nữa. Mình đang dùng Google Suite nên cũng không cần lắm :D

Cuối cùng, link đăng ký đây nhé: http://bit.ly/free_design_domain

Update 2020/04/28: Chương trình vẫn còn anh em nhé.

Sau hơn 3 năm kể từ ngày phần 6 ra mắt, đến giờ mình mới có thời gian để tiếp tục sở thích sưu tầm quote này. Phần lớn các ảnh trong post này được lấy từ một vài group như: BnR Typography, You're my Lumière, Tumblr Vietnam...

Bạn cần 15 phút để đọc bài này.

Từ trước đến giờ, mình cũng đã dự khá nhiều buổi presentation, nhưng thú thật là không có quá 25% slide khiến mình hài lòng xD.

Mình nhận thấy, hầu hết mọi người khi làm slide thường mắc 1 số lỗi căn bản như:

1. Quá nhiều chữ trong 1 slide.

Khoảng 95% các slide dính lỗi này là slide dùng giải thích 1 khái niệm nào đó.
Như mình đã từng xem, có bạn còn ném cả 1 đoạn trong Wikipedia dài tầm 20 dòng, tràn cả chữ ra ngoài slide chỉ để giải thích 1 thuật ngữ mà đến chính bản thân đọc còn không hiểu.

Để khắc phục vấn đề này, thì mình thường giải quyết theo hướng sau:

• Hãy để ý các từ khóa chính, đưa các ý chính thành gạch đầu dòng.
• Người dùng sẽ dễ tiếp nhận thông tin hơn nếu slide chỉ có khoảng 1-2 ý và chỉ gói gọn trong 4-6 dòng. Nếu nội dung dài thì có thể tách ra làm 2 hay nhiều slide.

2. Màu chữ và màu nền không tương phản với nhau.

• Cố gắng sử dụng màu sắc tương phản nhưng dễ đọc.
• Hãy bật slide lên và ngồi xuống các vị trí của khán giả để xem trước. Bởi vì có thể màu sắc bạn sử dụng dễ đọc trên màn hình máy vi tính nhưng sẽ khó đọc khi trình chiếu qua máy chiếu.
  Một số link tham khảo: https://viget.com/inspire/color-contrast
  http://contrastchecker.com/

3. Dùng clip art, word art.

No comment. Bạn xem lại đồng hồ xem năm nay là năm bao nhiêu nhé.

4. Hình ảnh sử dụng trong slide chất lượng kém, scale sai tỉ lệ.

Trường hợp này mình cũng gặp khá là nhiều, đơn giản vì mọi người lười tìm ảnh khác chất lượng cao, lười crop ảnh.

• Hãy cố gắng tìm các ảnh có độ phân giải lớn và độ nét cao.
• Nếu ảnh kích cỡ không phù hợp, bạn nên crop ảnh thay vì scale bằng tay, làm như thế sẽ trông buồn cười y như bạn vào nhà gương ý.
• Bạn cũng nên crop ảnh khi cần người xem tập trung vào chi tiết nào đấy của bức ảnh.

5. Sử dụng nhiều font chữ trong 1 slide.

• Đừng dùng quá 3 font chữ trong 1 slide nếu bạn không muốn làm người xem hoa mắt.
• Hãy sử dụng các font chữ dễ nhìn, tránh mấy cái font kiểu bay bướm hay cổ điển (trừ khi slide của bạn giới thiệu về font...).

Hiện tại Google cũng có khá nhiều font free ở đây, xem trước ở đây. Thay vì sử dụng các font quen thuộc như Arial, Times New Roman, Calibri... thì bạn hãy thử làm mới slide bằng các font của Google xem.

6. Lạm dụng quá nhiều hiệu ứng (animation/transition).

Việc thêm hiệu ứng vào slide sẽ làm người dùng bớt nhàm chán, tuy nhiên, hãy dừng lại ở mức vừa đủ và hợp lý.

• Nên sử dụng cùng kiểu transition giữa các slide, tốc độ nhanh (0.5~1 s)
• Không nên đặt thời gian thực hiện animation quá lâu.
• Sử dụng animation phù hợp, các block không hiển thị chồng chéo lên nhau.

7. Bài presentation không có cấu trúc.

Hãy cho người xem biết được bài presentation của bạn có cấu trúc như thế nào bằng cách hiển thị mục lục. Ngoài ra, trước khi chuyển sang thuyết trình về một vấn đề mới, bạn cũng nên có 1 slide dành cho việc tóm tắt ngắn gọn vấn đề vừa thuyết trình xong.

8. Slide không ăn nhập gì với nội dung trình bày.

Điều này thì không phải bàn cãi rồi. Cần tránh trường hợp slide hình con gà mà mình lại nói về con vịt (mặc dù cả 2 đều là gia cầm), trừ khi bạn muốn ẩn dụ kiếp trước của con vịt bạn đang nói là con gà trên slide.

9. Không ghi rõ nguồn khi sử dụng tài liệu, hình ảnh của người khác.

Ăn quả nhớ kẻ trồng cây. Hãy tôn trọng công sức của người khác bằng cách xin phép hoặc dẫn nguồn nếu bạn có sử dụng tài nguyên của họ trong slide của mình.

10. Ý thức của người làm slide

Đây là điều quan trọng nhất, hãy tôn trọng khán giả bằng cách cố gắng trau chuốt nội dung slide, dành thời gian để chuẩn bị cho bài presentation của mình.

Kết luận
Trên đây là 10 điều mà cá nhân mình đúc kết ra được sau khi được xem khá nhiều buổi presentation. Sau khi đọc bài này, hy vọng kỹ năng làm slide của bạn sẽ được cải thiện một cách đáng kể. Ngoài ra, bạn có thể biết thêm được những thứ khá hay ho khác trong slide dưới đây:

Đây là một slide khá hay mà mình tìm được (mình đã chia sẻ từ khá lâu trên blog này rồi nhưng bài đó bị xóa rồi thì phải :D)

Bài này được draft từ năm 2015, nếu có gì lỗi thời mong các bạn bỏ qua :o

Nếu bạn có ý định hỏi cái thằng viết bài này làm slide có tốt không thì câu trả lời là: "Không biết" nhé. Ahihi. Câu hỏi đó để dành cho khán giả chắc có ý nghĩa hơn là tự mình trả lời.

"vs" Questions

1. http://stackoverflow.com/questions/804115 (rebase vs merge).
2. https://www.atlassian.com/git/tutorials/merging-vs-rebasing (rebase vs merge)
3. https://www.atlassian.com/git/tutorials/undoing-changes/ (reset vs checkout vs revert)
4. http://stackoverflow.com/questions/2221658 (HEAD^ vs HEAD~) (See git rev-parse)
5. http://stackoverflow.com/questions/292357 (pull vs fetch)
6. http://stackoverflow.com/questions/39651 (stash vs branch)
7. http://stackoverflow.com/questions/8358035 (reset vs checkout vs revert)
8. http://stackoverflow.com/questions/5798930 (git reset vs git rm --cached)

General Questions

1. http://stackoverflow.com/questions/5788037 (Recover from git reset --hard).
2. http://stackoverflow.com/questions/1146973/ (Revert all local changes to previous state)
3. http://effectif.com/git/recovering-lost-git-commits (Recovering lost commit)
4. https://stackoverflow.com/questions/79165 (Migrating from SVN)
5. https://davidwalsh.name/squash-commits-git (Combining multiple commits into one using git rebase).

Website Reference

1. http://gitready.com/ (Git Tips and Tricks with explanation)
2. https://github.com/git-tips/tips (Repo for most common git tips)
3. http://gitimmersion.com/ (Small Online Book)
4. http://think-like-a-git.net/
5. http://www.ohshitgit.com (Take a look)
6. https://github.com/nvie/gitflow (Alternative branch model for git.)
7. https://github.com/magit/magit (Git GUI for Emacs).

Fast Git Reference

0. First download the cheetsheat from official: http://git-scm.com
1. For starters and intermediate, focus on only these commands:
   • Configuring : config, help.
   • Creating : init, clone.
   • Make Changes: status, diff, add, commit, reset, rm, mv (not important).
   • Branching & Merging: branch, checkout, merge, stash
   • Review History: log, tag, diff, show
   • Update and Publish: fetch, pull, push, remote.
   • Very Imp: reflog . http://effectif.com/git/recovering-lost-git-commits
2. Commands that are not in official cheatsheet (and advanced): revert, apply, cherry-pick, rebase, clean, show-ref, update-ref, ls-files
   • Debugging Commands: bisect, blame.
3. git stash is lightweight alternative to git branch.
4. Git has three stages:
   • Committed : means data is safely stored in your local database.
   • Modified : means you've changed the file but not committed.
   • Staged : means you've marked a modified file in its current version to go into your next commit snapshot.
5. Workflow of git:
   • Working Directory: holds the actual files
   • Index: Acts as a staging area. That is, snapshot for next commit. Will be done by git add command.
   • HEAD : Points to the last commit (and current branch) you've made.
6. Anything that is committed in Git can almost be recovered. However files which are not committed can't be recovered.
7. Description of Update and Fetch Commands:
   • remote: it only manage set of track repositories.
   • fetch: You can fetch new work from that remote server after cloning. Not similar to clone. You can later merge that repo with your existing with merge command.
   • pull: Automatically fetch and merge newest commit from remote server to local branch. By default, it combines fetch and merge.
   • push: This will push to the remote server from local branch.
8. When you do branch switching, files in your working directory will change to match that branch.
9. Using git reflog you can get back your destroyed commit (done via git reset --hard) using either
   • git checkout -b newBranchName <shaViaReflog>
   • git reset --hard <shaViaReflog>
     But use it in rare cases, because you reflog keep state via sha and it's hard to see which sha belongs to specific commit.
10. git cherry-pick is a low level version of rebase.
11. For advanced user who want to explore more, see gitflow. A Git extensions for creating repo operations using different branch model.

Tips and Shortcuts

Most used commands are: init, clone, status, log, add, commit, reset, rm, branch, checkout, merge, stash

    ## -- Initializing a new git repository
        $$ git init

    ## -- Useful git log commands
        $$ git log --oneline        ## print short sha in one line
        $$ git log -3               ## show only first 3 commit
        $$ git log --author="John"  ## show commits only by this author


    ## -- Cloning a git repository
    ## The other protocols are: ssh, ftp, file://, http(s):// etc...
        $$ git clone git://github.com/something/foo.git

    ## -- Show the status of file
        $$ git status -s  # in short format

    ## -- Add the file to staging area.
        $$ git add foo.js bar.js   ## `--` is used to seperate files from `add` options.
        $$ git add .    # add all the files

    ## -- Show what have changed since you last commit
        $$ git diff  ## with a `--cached` option, show the changes that will go into the next commit snapshot.

    ## -- Commit the changes after you add the files to staging area
        $$ git commit -m 'with an inline message'

    ## -- Auto-commit and track changes to modified file.
    ## NOTE: The files you've not added doesn't track by commit with `-a` command.
        $$ git commit -a -m 'with an inline message'

    ## -- Ammend last commit (i.e, merge to previous commit)
    ## https://nathanhoad.net/git-amend-your-last-commit
    ## After doing `git add .`
        $$ git commit --amend   # alternate is `git reset --soft HEAD~`.
        ## amend a commit without changing previous message
        $$ git commit --amend --no-edit


    ## -- Unstage file from the index only.  See `git reset` also.
    ## NOTE: `git rm` without `--cached` will simply remove the file from both index and working directory.
        $$ git rm --cached  # exact opposite of git add.

    ## -- Throw away local changes after commit (Use with caution)
        $$ git checkout <file>  
        # if the branch name and file name are same, then do this
        $$ git checkout -- <file>
        ## for all changes (it's perfect for time travel on previous commit)
        $$ git checkout -f # or `git reset --hard` (but previous one is more safer because with that you're in detached state.)


    ## Delete a single entry from git reflog. (git reflog is useful as it keeps 2 months history).
        $$ git reflog delete HEAD@{N}    ## `N`: 1,2 etc... or <sha>

    ## Undo the last commit, but keep the history and adds a new history
    ## http://stackoverflow.com/questions/27032850/ (for `git reset` vs `git revert` with image)
        $$ git revert

    ## -- check where HEAD is
        $$ git show-ref

    ## Remove the initial commit (git reset doesn't work here, it works only after second commit)
    ## http://stackoverflow.com/questions/6632191/how-to-revert-initial-git-commit
        $$ git update-ref -d HEAD


    ## Push a specific branch
        $$ git push origin <mylocalbranch>

    ## -- Detailed explaination of `git reset` (all three options). P.S. Use git checkout for time travel.
    ## http://stackoverflow.com/a/6866485/2092405
    ## NOTE: All the below three options remove log, so if you want to get back to previous state, you can pick
    ## <sha> from git reflog and do git reset on this.
    ## Suppose the structure is
         A-B-C
             ↑ (master)
    ## Then, nuke commit C and never see it again. Do this:
        $$ git reset --hard HEAD~1
        ## the result is:
             A-B
               ↑ (master)
       ## To undo this command, use;
           $$ git reset --hard <newShaOfReflog>  ## or (git reset --hard HEAD@{1})

    ## Undo the last commit, but keep your changes in working directory.
    ## It will delete the index the from git log also and show you untracked and unstaged files:
        $$ git reset HEAD~1  ## move the pointer one index back (or git reset --mixed HEAD~1)
        ## the result is:
        A-B-C
          ↑ (master)
        ## To undo this command, use;
            $$ git reset <newShaOfReflog>  ## or (git reset HEAD@{1})

    ## Undo the last commit, but don't touch the index and working directory.
    ## When you do git status, you'll see that the same files are in the index as before.
    ## In fact, right after this command, you could do `git commit` and you'd be redoing the same commit you just had.
        $$ git reset --soft HEAD~1


    ## Add a changed file to old commit (not last commit). I.E., fix up old commit
    http://stackoverflow.com/a/2719659/2092405

    ## merge a specific commit from one branch to another branch.
        ## make sure you're in the branch where you want merge.
        $$ git cherry-pick <commit-id-of-feature-branch>

    ## Merge two specific commit together (using rebase)
    http://stackoverflow.com/questions/2563632/how-can-i-merge-two-commits-into-one

    ## Modify a specific commit in git
    http://stackoverflow.com/questions/1186535/how-to-modify-a-specified-commit-in-git
    ## if you're getting this error. Needs a single revision. See this: http://stackoverflow.com/questions/26174757/
    ## Option: 2
        $$ git checkout <shaToThatCommit>
        $$ touch newfile.txt
        $$ git add .
        $$ git commit --amend --no-edit
        $$ git rebase --onto HEAD <shaToThatCommit> master  ## it will do automatic git checkout to master branch


    ## Branching and Merging
    ## ---------------------
    ## List out all the branches
        $$ git branch
    ## Create a new branch `testing` at your last commit
        $$ git branch testing
    ## Switch to branch
        $$ git checkout testing
    ## Shortcut to create a new branch and checkout
        $$ git checkout -b newbranch
    ## Delete a branch
        $$ git branch -d testing
    ## Merge the <branch> on the current working branch
    ## Merge tip: If you're doing merge say, from `wip` to `live` branch and you've edit `live` branch files
    ## then it will not undo changed file which is what we want.
    ## Also, merge conflict occurs when same file changed in both branch, you merged. You can reverse the merge conflict
    ## with `--abort` option
        $$ git merge testing    ## this will merge `testing` branch onto current (`master`) branch.
    ## checkout arbitrary commits instead of branch
        $$ git checkout HEAD~2
    ## Undo deleted branch
        $$ git reflog    ## to see the hash code of branch before deletion.
        $$ git checkout <hashcodeFromReflog>  ## to restore, and then create the same branch from there.

Git reset vs Git revert

NOTE: git revert is advanced command and it may accidently delete your files, if you haven't committed.
http://stackoverflow.com/questions/8358035/whats-the-difference-between-git-revert-checkout-and-reset

• Basically git revert undo changes with new commit history (i.e., introduce a new commit that reverse the specified one) while git reset (with --hard) BEWARE. Any changes to tracked files in the working tree and index are discarded.
• git reset (with --soft) option doesn't touch the index file nor working tree. In this case, index file is staged but not committed and right after this command you can use git commit.
• git reset (with --mixed) option reset the index but not the working tree. In this case, index file is not staged, so after this command you have to use git add and git commit.

Git rm and Git reset

git rm remove the file from the index (with --cached option).
git reset is specifically about updating the index, moving the HEAD.
These two options are equivalent only when we first add a file. After that with git reset you can move the index while with git rm --cached, you completly destroy the index.

Fix a "head detached from" message

See: http://stackoverflow.com/questions/10228760/fix-a-git-detached-head
Summary: Basically checkout the branch using git checkout branchname

Relative Refs

https://www.atlassian.com/git/tutorials/refs-and-the-reflog/refspecs
The ~ character lets you reach parent commits. For eg: The following display the grandparent of HEAD:
git show HEAD~2. The ~ character will always follow the first parent of a merge commit.
If you want to follow different parent, use ^ character
For eg: If HEAD is the merge commit, then following returns the second parent of HEAD:
git show HEAD^2
Some examples:

    # Only list commits that are parent of the second parent of a merge commit
    $$ git log HEAD^2
    # Remove the last 3 commits from the current branch
    $$ git reset HEAD~3
    # Interactively rebase the last 3 commits on the current branch
    $$ git rebase -i HEAD~3

Git "fetch", "pull", "push", "remote"

NOTE: You can't push to non-bare repository if the branches are same on both remote and local server
By default updating the current branch with non-bare repo is denied. If you're the only user, you can set git config
git config --bool core.bare true and then delete all files except .git in remote.
http://stackoverflow.com/a/2933656/2092405
Some common git urls:

    ssh://[user@]host.xz[:port]/path/to/repo.git/
    git://host.xz[:port]/path/to/repo.git/
    http[s]://host.xz[:port]/path/to/repo.git/
    ftp[s]://host.xz[:port]/path/to/repo.git/
    [user@]host.xz:path/to/repo.git/
    /path/to/repo.git/
    file:///path/to/repo.git/

git pull is basically shorthand for git fetch followed by git merge FETCH_HEAD
git fetch: Downlaod new data and branches from remote repository
git push: Push your new branches to remote repository.
git remote: Manage (list, add and delete) remote repository aliases.

1. To push local repository to your server

    ## On your server (create a bare repository)
    $$ git init --bare repo.git
    ## On local
    $$ git remote add origin ssh://server/var/www/frontend.git
    $$ git push origin master
    ## After that, use:
    $$ cd /var/www/; git init; git clone frontend.git

    ## or alternative way without bare repository
    ## switch to different branch locally
    ## and then on your server
    $$ git init
    ## from local repository
    $$ git push ssh://server/path/to/git otherBranch
    ## then merge the otherBranch to master in remote repository

    ## Shortcut without switching repository
    $$ git remote add origin ssh://server/path/to/git
    $$ git push origin master:someOtherBranch       ## this push from master to `someOtherBranch`.

END

Source: eashish93's gist

Sau 4 năm phát triển, từ giữa năm 2013 đến tận tháng 7/2017, cuối cùng Ghost cũng release được phiên bản stable 1.0.0.

Mình chắc là một trong những người dùng Ghost đầu tiên ở VN :v Phiên bản đầu tiên mình dùng hình như là 0.3.0 thì phải. Sau khi dùng thử Ghost thì mình cũng làm được 1 theme nho nhỏ tên là Rush và bán trên Gumroad, rồi sau này cho làm open source ở đây. Đợt đó Ghost mới ra, ít theme nên cũng bán được vài chục bản :D. Nhờ tiền bán theme đó mà mình mới có đủ tiền để năm nay cưới vợ :v.

Tính mình thì thích thử nghiệm những cái mới, chính vì thế, mỗi lần Ghost có phiên bản mới là lại hào hứng upgrade ngay khi có thể, thỉnh thoảng lại gặp lỗi khi migrate vì các phiên bản mới có "break changes", ví dụ như từ 0.4 lên 0.6 hay 0.7 gì đó, hoặc từ 0.11 lên bản 1.0 alpha. Có lần còn phải export db ra, tạo app mới, chuyển dữ liệu sang app Ghost mới thủ công. Rõ khổ =((.

Hôm nay thấy có email báo server bị down, vào check thì thấy có thông báo Ghost-Cli có version mới 1.0.0 nên mới biết là Ghost đã ra 1.0.0 từ 3 ngày trước rồi. Thế là bay vào upgrade ngay từ 1.0.0-rc2 lên. Cứ tưởng upgrade ngon lành, xong lại bị lỗi về config của Ghost-Cli @@, phải sửa lại file config của Ghost CLI bằng tay rồi mới start được Ghost.

Mà thôi, nói lảm nhảm hơi nhiều, mọi người nếu có ai hứng thú hoặc đang dùng Ghost phiên bản cũ thì thử dùng version 1.0.0 này xem :D Từ phiên bản này đã có thể cài đặt Ghost dễ dàng hơn bằng Ghost-CLI rồi.

Ai gặp vấn đề gì với Ghost hoặc gặp lỗi khi migrate lên version 1.0.0, nếu cần support thì cứ contact với mình nhé \m/

Chiều nay mới nhận được email quảng cáo từ LCN, đại loại là:

Chúng tôi đã phát triển hệ thống transfer domain mới đến nỗi hộc cả máu. Hệ thống mới đó sẽ giúp cho việc transfer domain của bạn sang hệ thống của chúng tôi nhanh hơn, dễ dàng hơn, giá rẻ hơn so với trước đây.
Chính vì thế, từ giờ cho đến hết tháng này, mọi domain .com, .net, .org transfer sang chỗ chúng tôi sẽ đều được free hết.

Cách đây 3 năm mình cũng có thuê hosting ở LCN tầm 1 năm, thấy dùng cũng tạm ổn. Mỗi tội trang quản lý nhìn chán quá 😅 Nhưng chắc đỡ củ chuối hơn P-"X" nào đó của Việt Nam 😒

Để transfer domain sang LCN, anh em làm như sau:

1. Truy cập vào trang Transfer Domains của LCN tại đây.

2. Nhập domain vào ô How many domains would you like to transfer?.
   

3. Nhập coupon sau vào ô Promo Code.
   FREETRANSFER

4. Thanh toán và đợi 1 hoặc 2 ngày, sau khi domain được chuyển về LCN thì sẽ tự động được gia hạn thêm 1 năm nữa 🤑🤑🤑

Chú ý

• Domain phải được unlock thì mới transfer được.
• Mỗi account chỉ được sử dụng coupon 1 lần, không biết tạo nhiều account có vấn đề gì không??? 😎
• Coupon sẽ hết hạn vào lúc: 23:59 ngày 30/06/17.

Chưa phim nào đem lại cho tôi một cảm giác dịu dàng như Sekaichuu. Với cốt truyện dễ gặp (và dễ đoán): một mối tình trung học đẹp nhưng dang dở, thế nhưng những gì Sekaichu mang lại còn nhiều hơn sự nối tiếc hay nỗi buồn, mà đó là những niềm vui, nụ cười, sự quan tâm ấm áp của gia đình, sự thương yêu của thầy cô, và tình bạn trong sáng của tuổi học trò.

Aki và Saku yêu nhau khi hai người mười bảy tuổi. Aki mất năm 17 tuổi. Hai câu đơn giản là đủ để tóm tắt cho toàn bộ phim, thế nhưng đâu là điểm đặc biệt để tôi khóc cười suốt 11 tập phim?

Source: 勇気100% Blog

Thấy phim này hay quá nên reup lại hồi 5 năm trước, hôm nay tự dưng nhìn thấy tờ bìa trước của sách (Socrates in Love) nên share lại.

"Socrates in Love" là tên truyện, còn "Crying Out Love, In the Center of the World (世界の中心で、愛をさけぶ, Sekai no Chūshin de, Ai o Sakebu)" là tên phim. Cá nhân mình thích phim hơn truyện, một phần là vì truyện diễn biến nhanh hơn phim, đọc truyện không để lại nhiều cảm xúc lắm. Một phần khác là mình thích Haruka Ayase (Aki) từ phim "Cyborg She" (Cyborg Girl, 僕の彼女はサイボーグ, Boku no Kanojo wa Saibōgu) YNWIM :v

Nhạc phim Cyborg She cũng bài hay lắm, mặc dù không hiểu lắm nhưng đoạn Jiro được quay lại nơi mình ở ngày xưa, nhạc bài này vang lên nghe vẫn rất cảm động.

Xem 11 tập + tập ĐB của phim Crying Out Love, In the Center of the World ở đây nhé: