Thứ Tư, 13 tháng 7, 2016

Cách fix lỗi khi không thể clean up được tortoise svn

Cuối ngày hôm nay, mình hì hụi mất tới hơn 1 tiếng đồng hồ vì không thể cleanup svn.
Đang nghi ngờ do svn lỗi. Mà đúng lỗi thật. Nhưng sợ mai vẫn không ăn thua. Nhờ anh HaiCV ra xem cho, nhưng anh Hải còn bận đi uống bia :|. Hết nói.

HungNM, anh TuanTD nghi vấn có thể mạng bị lag do mấy đồng chí MinhBQ, ThangTT chiếm đường truyền. HungNM còn gợi ý có con dao Thái mới mua. Làm lại nghĩ tới bài "Vè con dao":
"......
Con dao anh dài
Dài vừa năm tấc
Khi mài đã sắc
Phả lở núi rừng hoang
....
Con dao anh quay một phát
...
Con dao tôi sắc vô cùng 
Đốn trăm cây cũng ngã 
Chặt ngàn cây cũng ngã 
Cho nên thiên hạ 
Đều rèn theo kiểu dao này 
Trước dùng việc hàng ngày 
Sau vệ quốc, bình Tây 
Chặt quân thù như chém chuối"

Không biết hai đồng chí Minh, Thắng nghĩ sao!

Mình đã hỏi expert của mình thì được expert đưa ra câu trả lời như sau:

Somehow, svn is stuck on the previous operation. We need to remove this operation from it’s ‘work queue’. 
The data is stored in the wc.db sqllite database in the offending folder.

Câu trả lời là svn bị stuck bởi 1 operation nào đó trước đấy rồi. Và điều chúng ta cần làm là remove operation đó khỏi "work_queue" của nó. Thông minh kinh.

The data is stored in the wc.db sqllite database in the offending folder.
Câu này chắc là mỗi thư mục checkout svn, nó sẽ có 1 database wc.db để quản lý các operation thực hiện đối với thư mục đó.

Và các bước để thực hiện như sau:
1. Download sqlite3.exe
2. Bỏ vào thư mục đã checkout svn
3. Chạy command line của windows
4. CD tới thư mục checkout
5. Gõ sqlite3 .svn\wc.db
6. Gõ lệnh select các operation đang bị stuck trong queue bằng câu lệnh select:
Select * from work_queue
Tại bước này, sẽ hiển thị ra operation đang bị stuck ở đây
7. Delete operation đó bằng câu lệnh delete:
Delete from work_queue.
8. Sau đó kill sqlite bằng lệnh .exit
9. Chạy lại lệnh cleanup trong svn và hoàn tất.
Hình dưới đây, work_queue của mình đã clean rồi :D.
Good job!

sqlite3.exe có thể được download tại đường dẫn http://www.sqlite.org/download.html, chú ý chọn: sqlite-tools-win32-x86-3130000.zip thì mới chứa đủ bộ tool để quản lý các file SQLite database và hệ điều hành win 32 bit.

Hi vọng sẽ không ai bị lỗi stuck svn như mình vừa gặp nữa. Đồng thời cũng giải tỏa tâm lý cho 2 đồng chí Thắng và Minh không phải nơm nớp lo sợ bị cắt mất một số thứ gì đó :))





Chủ Nhật, 3 tháng 7, 2016

Go-live hụt (2/7/2016)

Mặc dù hôm nay đã là 4/7, thông tin cung cấp ở đây đã không còn nóng hổi tính thời sự. Cơ mà nhật ký mà. Hôm nay ghi lại sự việc đã diễn ra hôm thứ 7 cũng chả lấy gì làm lạ. Mà quan trọng là phải ghi lại không thì mấy hôm nữa là quên hết luôn.
Thứ 7 (2/7/2016) là một ngày cực kỳ căng thằng, không phải cho bên mình, mà là cho bên đối tác.
PM dự án (bên phía bank) đòi kiểu gì cũng phải golive trong tuần (tuần từ 28/6 tới 3/7) trong khi bug bên đối tác nhiều như lá vàng rụng mùa thu. Mà rụng kiểu quái gì mãi vẫn không hết lá!

Việc lệch mã dịch vụ của nhà cung cấp bên phía merchant sml đã được thông báo cho PM từ lâu lắm rồi (vài tháng trước), nhưng thứ nhất vì nó không ảnh hưởng tới phía mình, chỉ là config phía đối tác etc. Thứ 2 là mail thông báo đó cũng không phải từ tác giả gửi mà là từ PM Hùng mặc dù nội dung là tác giả viết cho :)). Thứ 3 là vì đối tác sml hơi bị khó tính. Thứ 4 là PM bank đã mail lại là sẽ mail hỏi đối tác sml.
Nên tác giả đã bỏ mặc chuyện đó (phải thừa nhận là có chút thiếu trách nhiệm).
Ngày trước go-live 1 ngày, bị nghiệp vụ bank add vào group support test cùng với đối tác sml. Thấy mã lỗi thì rõ là khi phát triển bên mình đã gặp rồi, kiểm tra mã dịch vụ thì đúng là sai thật. Thông báo là mã đó bên sml đã có lần bảo không tồn tại, và yêu cầu nghiệp vụ cung cấp lại. Nghiệp vụ bank như trên trời rơi xuống (cũng thông cảm vì cô bé đó không có thông tin gì về issue đó) và rồi đối tác sml hỏi: "Mai go-live mà tới h này vẫn truyền sai mã dịch vụ là sao". Cảm thấy bị ngu! Nghe câu hỏi cũng đủ biết tác giả của nó là ai :)).

Và thế là lại có một cuộc họp. Trong cuộc họp, nghiệp vụ bank bảo đẩy trạng thái của tất cả các lỗi lên thành critical. Thế thì go-live làm sao được.

Thứ 7, đối tác ETC không fix xong được lỗi, và PM Hùng thông báo go-live hoãn lại và lùi tới hôm sau (tức chủ nhật). Mà kể buồn cười thật, test uat mà nghiệp vụ chả thông báo mấy ông đối tác support. Dữ liệu trên test của họ có phải lúc nào cũng active đâu mà khi test đòi: sao nó trả về thế này, sao nó thế kia. Rõ là bullshit!
Mà cũng đúng thôi, đến nội bộ liên quan mà còn chả biết bao h go-live thì làm sao mà thông báo cho đối tác. Làm toàn mình đi hỏi bên backend đã đẩy abcxyz lên chưa, bên đối tác môi trường test thế nào... Chỉ tốn dollar của mình! Dollar thì cũng ko phải vấn đề (nhà có điều kiện) mà cơ bản là chả hiểu quy trình các ông làm ăn cái kiểu khỉ gì.

Tới 3h, lại họp đánh giá xem chủ nhật có go-live được hay không, nhiều dự đoán là không. Và đúng là không thật. Khổ thân đối tác ETC bị loạn hết cả cào cào lên. Hỏi tác giả toàn mấy câu ném đá không chịu được.

Đồng chí LongPN, đi chơi 1 tuần về vẫn kịp go-live :d. Hồi tối còn gửi cái ảnh, đầu quấn khăn, râu thì không cạo, hệt Hồi giáo luôn :)). Làm lại nhớ, tác giả không giống Hồi giáo gì, mà sao bị gọi là Taliban nhỉ :|

Sáng mai, PM HungNM thông báo, ko phải về họp phòng mà mấy anh em ở lại canh miếu, support đối tác ETC.
Sao thấy mình như culi thế này!





Thứ Sáu, 1 tháng 7, 2016

Tường thuật trực tiếp tiền golive

Tường thuật trực golive hỗ trợ ETC UAT - Thế quái nào thành ra fix bug ESB

Hôm nay là ngày 1/7/2016, cả team chuẩn bị cho lần golive toàn bộ của ESB phase 1 diễn ra vào ngày mai (2/7/2016). Không cần phải nói nhưng đề cập lại cho team biết là mai mình golive sẽ có Hùng Oppa nhé :)).

Lẽ ra là chỉ cần 1 vài đồng chí (3 thanh niên trong ảnh) ở lại trực golive thôi, nhưng khi vừa xuống lót dạ để chuẩn bị ra sân cầu thì PM HungNM đã dí cái điện thoại vào mặt: Diệp nó đang tìm chị.
Ăn cái bánh giò xong lên phòng thỉ cà phòng trống trơn :|. Loanh quanh một lúc phát hiện ra là có lỗi ESB. Dữ liệu từ bên đối tác trả về qua data power phải xóa đi trường id 120 mới verify được, vậy nên khi trả dữ liệu cho client, thì trường dữ liệu đó bị thiếu.
Rồi lại gặp phải vấn đề cần phải map lại trong code.
Thật là khùm khoằm làm tác giả mất cả một buổi đánh cầu rồi :(.

Tuy nhiên ở lại với mấy thanh niên này cũng vui phết. Mấy anh em ở lại mà mặt cứ cười nhăn ra. ThangTT thì như bị down vậy. Nhìn cái mặt buồn cười kinh lên được.

Sau đó, PM HungNM, tuổi trẻ trèo cao, rớt xuống ao có ngày mời ra chọn món nhé. Các member khác thế nào cũng ghen tị =))
Tác giả đúng là mẫu người vui sướng cùng hưởng, cực khổ cùng chịu. Đến khi ăn xong mấy cái bánh hambuger vẫn còn nhờ tới em HuyenNTH phải giữ lại mấy gói tương ớt, tương cà cùng túi nilon để có lúc nào em ấy còn dùng. HungNM và ThangTT còn có ý thức tiết kiệm hơn, uống xong Pepsi còn rủ nhau ra nhà vệ sinh nam để rửa 2 cái cốc để sau còn dùng.
Đúng là những công dân tốt, rất nhớ lời Bác dạy. Mà kể cũng đảm bảo vì cái cốc nó có nắp, nếu chuột có trèo lên thì vẫn không lo hôn môi xa với chuột =)).

Dưới đây là một số hình ảnh cho ace tham khảo:


Mấy thanh niên golive mà trong vui ghê

ThangTT trực golive trông down kinh lên được 
PM HungNM mặt hớn không chịu được

21h20 fix bug xong rồi. Hi vọng mọi việc sẽ suôn sẻ!!!












Cuối cùng cũng được PM cho ăn :))