Trước ngày 10/10, Hà Nội thông báo dừng bắn pháo hoa tại 29 điểm, chỉ bắn pháo hoa nghệ thuật tại Mỹ Đình.
Nhiều người thắc mắc không biết số lượng pháo hoa đã được chuẩn bị ở 29 điểm này sẽ được xử lý như thế nào.
Sau ngày 10/10, các báo cáo thống kê của các bệnh viện lớn ở Hà Nội cho thấy, số lượng bệnh nhân phải nhập viện do chấn thương cổ tăng mạnh.
Cũng theo các báo cáo này, khi được hỏi, các bệnh nhân đều có điểm chung là đã đi xem bắn pháo hoa ở Mỹ Đình.
Những cơn gió lang thang. Hết ngày này qua ngày khác, đi qua những vùng đất.
Đến và đi không lưu luyến, không đắn đo. Cứ bay đi, thanh thản và nhẹ nhàng.
Đến một ngày, cơn gió tan đi và không còn gì cả.
Nhiều lúc, anh muốn làm cơn gió em ạ. Như vậy thì vô nghĩa quá.
Một lần nữa, mình làm nh khóc. Lần này là những giọt nước mắt đau đớn thực sự.
Bao nhiêu tình cảm, niềm tin, tất cả đều mất hết rồi.
2 từ chia tay thật dễ nói, nhưng đằng sau nó là rất nhiều nước mắt và đau khổ.
Mình đã bỏ cuộc khi ở gần cuối con đường, để đi theo những cảm xúc điên rồ của bản thân. Không biết mình làm đúng hay sai nữa.
Có lẽ, nỗi đau bây giờ sẽ còn dễ dàng hơn nhiều so với nỗi đau sau này.
Mình đau quá, nhìn gương mặt nh, mình làm gì thế này :(.
Đối tượng dự thi: Sinh viên Việt Nam.
Chủ đề cuộc thi là viết các ứng dụng về bảo mật các thông tin cá nhân đối với các điện thoại sử dụng hệ điều hành Android.
Nội dung bảo mật xoay quanh các vấn đề:
Sản phẩm dự thi đề cao tiêu chi về tính độc đáo, giải pháp sáng tạo của ứng dụng, tính thực tiến, khả thi và thương mại hóa…
Ứng dụng có thể thế hiện bằng Tiếng Việt, Tiếng Anh, hoặc tiếng Nhật, và chưa được thương mại hóa tại bất kỳ địa phương nào ở Việt Nam và trên thế giới.
Là sinh viên có quốc tịch Việt Nam hoặc quốc tịch nước ngoài nhưng gốc Việt Nam đang sinh sống, làm việc, học tập ở trong nước và ở nước ngoài.
Người tham gia dự thi đăng ký trực tiếp theo mẫu www.lifetimetech.vn/contest/AndroidContest.doc gửi về địa chỉ adroidcontest@lifetimetech.vn hoặc tải mẫu đăng ký để điền thông tin dự thi gửi qua đường bưu điện hoặc fax đến Ban Tổ chức cuộc thi “Xây dựng ứng dụng bảo mật trên Mobile Android” Công ty Lifetime Technologies Vietnam-Japan, tầng 3 – Trung tâm sáng tạo 3D Việt Nam, Nguyễn Phòng Sắc kéo dài, Cầu Giấy – Hà Nội.
Tất cả thông tin bằng tiếng Việt gồm:
Gửi qua đường bưu điện đến Ban Tổ chức cuộc thi “Xây dựng ứng dụng bảo mật trên Mobile Android”
Thời gian nộp đăng ký và ứng dụng, game dự thi dự kiến từ 20/08/2010 đến 20/10/2010 (tính theo dấu bưu điện xác nhận từ nơi gửi).
Một số thời điểm có thể thay đổi theo điều kiện thực tế của công tác tổ chức
Ban Giám khảo gồm: công ty Lifetime Technologies, cùng các chuyên gia có uy tín trong ngành Viễn thông, Công nghệ di động từ Nhật Bản.
01 giải nhất trị giá 20.000.000 VNĐ
Các sản phẩm tham gia sẽ có cơ hội nhận được sự hỗ trợ để thương mại hóa từ Lifetime Technologies và các nhà đầu tư phía Nhật Bản
BAN TỔ CHỨC |
Bài toán đặt ra ban đầu như sau:
Một Client cần sử dụng/triệu gọi đến 1 Service. Xem mô hình bên dưới
Client service
Như mô hình trên cho thấy, client cần có 1 Service Stub (hiểu như là một thể hiện giả của service) để thao tác với Service. Service Stub này có nhiệm vụ tìm kiếm, khởi tạo thể hiện của Service, và gọi service mỗi khi cần.
Phương pháp này làm việc bình thường khi chỉ có 1 client và 1 service, tuy nhiên khi số lượng client tăng lên, thì khối lượng code phải tạo ra cũng tăng theo cấp số cộng. Do mỗi client đều phải cài đặt 1 service Stub của riêng mình. Còn khi số lượng Service tăng lên, thì khối lượng code tăng theo cấp số nhân. Như vậy, mô hình này có nhược điểm rất lớn là làm tăng khối lượng công việc phải làm, thêm vào đó, việc cài đặt stub ở mỗi client sẽ làm cho việc maintain mất nhiều chi phí hơn.
Để khắc phục, xem mô hình sau:
Service Locator
Service Locator được tạo ra để thực hiện vai trò như của Service Stub ở mô hình trên. Tuy nhiên, với mô hình này, các client có thể dùng chung Service Locator.
Như vậy, mỗi client chỉ cần liên kết với Service locator là có thể gọi được service mà không cần phải cài đặt nhiều code.
Sử dụng Service Locator đem lại nhiều lợi ích, như:
– Giảm khối lượng code
– Đơn giản hóa client.
– Tách biệt client với Service, tạo nên quan hệ lỏng lẻo, tăng khả năng tùy biến, thay đổi.
– Thống nhất
– dễ maintain.
The 1st sample, chúng ta hãy xem xét đến những công ty sản xuất ô tô.
Với cùng 1 chức năng là chế tạo ra những chiếc ô tô, nhưng mỗi công ty lại có những chủng loại ô tô của riêng mình. BMW có Sedan, Rover, X series,….
Trong khi Toyota có Camry, Innova, hay Land Cruise,…
The 2nd sample, trong những hệ thống có lưu trữ dữ liệu, chúng ta thường biết đến đối tượng DataBase Connection,
với chức năng tạo và thể hiện 1 kết nối tới cơ sở dữ liệu, nhưng với từng loại cơ sở dữ liệu khác nhau, chúng ta có những kết nối khác nhau:
SQL Server có SqlConnection, MySQL Server có MySqlConnection ACCESS có OLE DBConnection,…
2 Ví dụ trên cho thấy 1 hiện tượng: cùng 1 loại đối tượng, với cùng 1 chức năng, nhưng với từng loại cụ thể hơn lại cho kết quả khác nhau. Đây có thể coi là ý tưởng cơ bản của Factory Method Pattern, tuy nhiên Factory Method còn làm được nhiều hơn thế. (more…)
Framework là tập hợp các thành phần (class, dll, library,…) kết hợp với nhau, cung cấp các chức năng mang tính tổng quát, mà người sử dụng (developer) có thể tái sử dụng hoặc ghi đè cho phù hợp với ứng dụng sẽ được tạo ra trên nền Framework.
Về khái niệm, Framework có phần giống với Thư viện phần mềm (Software Library). Nhưng Framework có những đặc trưng riêng của nó. Đó là:
Bắt đầu học Design Pattern. Càng đọc càng cảm thấy ức chế.
Không phải là mình không hiểu, mà là mình không tìm được từ để diễn đạt. Những khái niệm tiếng Anh, viết thì đơn giản, sao dịch ra tiếng Việt khó thế không biết.
Start to learn Design Pattern. The more reading, the more inhibition!
I can understand, but I can’t express what I understand. They’re too abstract. It’s easy to write by Eng, but hard to translate into Vietnamese.
Problem:
Trong nhiều trường hợp, yêu cầu cần phải kiểm soát được quá trình tạo ra đối tượng và kiểm soát vòng đời của đối tượng, trong khi đối tượng này được rất nhiều đối tượng khác của hệ thống gọi đến. Trường hợp thường gặp nhất là cần đảm bảo tại mọi thời điểm chỉ có duy nhất một thể hiện của 1 đối tượng tồn tại.
Solution: Singleton pattern
(more…)