Lập trình viên từ 2-3 năm kinh nghiệm có thể đạt mức lương 5-6 triệu => WTF

Phần AI này về cơ bản cũng là phần thi lập trình giải thuật như các bài thuộc phần Code contest. Tuy nhiên thay vì viết chương trình nhận input và in ra output để vượt qua các test cases thì trong phần này các đội chơi sẽ viết chương trình điều khiển một con bot, nhận input vào là trạng thái (state) của game và output ra nước đi thích hợp (trong game lần này đơn thuần là trái phải trên dưới ) Phần thi này có sự đối kháng giữa các team dưới dạng trò chơi trực quan, hơn nữa lại không có giới hạn cụ thể nào cho việc làm xong/chưa xong, nên kích thích sự sáng tạo của các đội chơi rất nhiều. Có lẽ vì vậy mà em thấy thú vị chăng

Cảm ơn bạn đã góp ý. Việc dùng DI khó debug chỉ đến từ kinh nghiệm bản thân đã gặp trong một vài trường hợp cụ thể khi mới làm quen với DI, nếu có kinh nghiệm rồi bạn hoàn toàn tháy nó dễ dàng hơn. Việc tạo ra instance ở Runtime là tùy vào cách khai báo và quản lý life cycle, cũng như scope của DI container. Đơn cử như Android, thư viện mình hay sử dụng là Dagger 2 thì việc khởi tạo các instance sẽ găn liền với life cycle của ứng dụng cũng như các View Component, có scope rất rõ ràng và tất nhiên là 'when we need you, we give it to you'.

thanks god

Cảm ơn chia sẻ của anh

Nice post! Rất thiết thực. Tks chủ thớt nhé!

Trên kia chỉ là giời giải tham khảo, còn có thể tối ưu, nhưng cũng đủ để dùng với bài Code Puzzle lần này rồi.

Em muốn lời giải tuyệt đối thì có thể tìm hiểu thêm ở paper dưới đây http://slovesnov.users.sourceforge.net/bullscows/bulls_and_cows.pdf hoặc xem source code này https://github.com/vpavlenko/bulls-and-cows/blob/master/solver.py

Thank chụy nhóe, em đang mần về cái này

Về cơ bản thì phần thi AI lấy ý tưởng từ game http://splix.io/ , em chơi thử để nắm luật nhé. Các đội chơi sẽ viết source code cho bot rồi đưa lên hệ thống, hệ thống sẽ chạy các bot theo từng turn, bot của các đội chơi sẽ tuỳ vào tình huống mà đưa ra các quyết định di chuyển theo hướng lên, xuống, trái, phải để chiếm được nhiều đất nhất hoặc hạ gục được đối phương là thắng cuộc nhé.

E đang là sinh viên năm cuối, theo dõi thấy phần thi AI thi đấu khá hay nhưng thực sự chưa hiểu nhiều về phần thi này lắm. Rất mong có một bài viết nói về AI ạ trong CodeWar ạ (bow)(bow)

hihi, đẹp k

Vâng ạ. Em cảm ơn anh. Em tìm hiểu cái này cũng khá lâu nên chưa update được. Em sẽ có bài dùng Angular CLI với Rails sau ạ

Các bạn làm ơn đọc cách tạo ứng dụng trên trang document của Angular.io chút đi, phiên bản 2.0 đã final, giờ cũng đã final luôn bản 4, mà các bạn vẫn làm app với angular rc. Hơn nữa, sử dụng "quick start" chỉ dành khi bạn muốn biết nó chạy thế nào, chứ để dùng cho production thì config mệt. Bây giờ Angular CLI khá ngon rồi, các bạn có thể build app bằng CLI xong ship cục production vào app Rails cho khỏe.

Oh, cái avatar

Đây là bài dịch trong sách Design Patterns for Dummy mà

Chào bạn, Cảm ơn bài viết của bạn. Mình có góp ý nhỏ để bài viết này hoàn thiện hơn đó là bạn nên chỉnh sửa phần mở đầu và kết thúc vì cách bạn tiếp cận và hiểu về docker mình thấy nó chưa có đúng. Ví dụ như "Docker thực sự cung cấp cho chúng ta một giải pháp mới cho công việc ảo hoá" => docker không phải là giải pháp ảo hoá, nó cũng không phải là một công nghệ ảo hoá ở mức hệ điều hành như LXC hay OpenVZ. Có thể ban đầu tiếp cận hơi có chút nhầm lẫn, bạn nên đính chính lại để bài viết chính xác hơn và các bạn sau này đọc cũng không có bị hiểu sai về docker.

Mình hỏi một chút là trên 1 server mình cái 1 MySQL nhưng cấu hình cho chạy 2 port hay như thế nào?

"Mình xin đưa ra một số trường hợp khá thú vị của PHP mà có thể bạn ít dùng, và có lẽ bạn không nên dùng =))" cạn lời :v

Mình nghĩ bạn nên thêm phần demo vào hoặc là chụp lại ảnh động cái mà bạn đã hoàn thành thì bài viết sẽ trực quan cho người đọc hơn đấy

@khanh.nguyen Hi Khánh,

Mình không đồng ý với ý tưởng "tương tác giữa view và presenter". View (interface) nên passive nhất có thể, nó không nên biết về implementation của presenter. Nếu có sự tương tác từ cả 2 phía sẽ dẫn đến việc 2 class này liên kết quá chặt với nhau, như vậy thì cũng không khác gì vanilla Android - một activity chứa hết tất cả - chỉ khác ở chỗ bạn có nhiều file hơn thôi.

Về việc bạn muốn có một cái nhìn tổng quan về những thứ mà presenter làm, nhưng class presenter lại quá to? Đơn giản nếu bạn đang dùng Android Studio, bạn có thể vào Code->Folding->Collapse All, tất cả method body sẽ được ẩn đi và chỉ giữ lại tên hàm, như vậy cũng đâu có khác gì nhìn vào interface đúng không?