Để làm việc hiệu quả hơn

Hãy làm việc một cách thông minh

Hồi tôi 17 tuổi, tôi học và làm việc ít nhất 20 tiếng một ngày. Tôi đến trường, làm bài tập giữa giờ nghỉ và quản lý một tổ chức phi lợi nhuận vào buổi tối. Lúc đó, sự chăm chỉ của tôi đã đưa đến cho tôi vô vàn cơ hội làm việc với các tổ chức hạng nhất và một sự nghiệp thành công. Nhưng thời gian trôi đi, và tôi nhận ra rằng, làm việc nhiều hơn nữa không phải là cách duy nhất đến thành công. Nhiều khi, làm việc ít hơn lại có kết quả tốt hơn.

Bạn hãy tưởng tượng một doanh nghiệp nhỏ, làm việc không ngừng nghỉ. Tuy nhiên, anh ấy sẽ không thể cạch tranh với các công ty quy mô hàng tỷ đô. Thời gian rất hạn chế. Mỗi doanh nhân chỉ có 24 giờ một ngày và 7 ngày trong tuần. Đối thủ của chúng ta luôn luôn có thể chi ra nhiều tiền hơn, xây dựng đội ngũ nhân viên lớn hơn, dành nhiều thời gian hơn cho một dự án. Vậy tại sao, có những công ty startup làm được những điều mà các công ty lớn không làm được? Facebook đã mua Instagram, một công ty gồm 13 nhân viên với giá hàng tỷ đô. Snapchat, một công ty startup với 30 nhân viên đã và đang từ chối lời mời từ các công ty lớn như Facebook và Google. Một phần thành công của họ là do may mắn – còn phần còn lại, là do tính hiệu quả.

“Chìa khóa thành công không phải là làm nhiều mà là làm một cách thông minh.”

Đây là 7 thứ thôi đã không làm nữa để trở nên hiểu quả hơn:

1. Hãy làm hiệu quả thay vì làm thêm giờ

Bạn đã bảo giờ tự hỏi mình rằng tại sao chúng ta lại làm việc 40 tiếng 1 tuần? Vào năm 1926, Henry Ford – người sáng lập của công ty Ford, đã thí nhiệm và tìm ra rằng: khi bạn giảm số lượng giờ làm của bạn từ 10 xuống 8 tiếng và giảm ngày làm trong tuần từ 6 còn 5 ngày, thì độ hiệu quả của bạn sẽ tăng lên.

Bạn càng làm nhiều, thì bạn sẽ càng trở nên kém hiệu quả dù trong ngắn hạn hay dài hạn.

Giấc ngủ cũng rất quan trọng. Để làm việc hiệu quả, bạn cần phải ngủ đủ số lượng thời gian. Đọc thêm >>

Bạn có biết rằng:

– Leonardo Da Vinci có nhiều dấc ngủ ngắn trong ngày và ngủ ít hơn vào buổi tối
– Napoleon đã không ngần ngại có những dấc ngủ ngắn hàng ngày
– Mặc dù rất xấu hổ về việc này, nhưng Thomas Edison vẫn ngủ trưa hàng ngày

Và còn rất nhiều ví dụ về các vĩ nhân khác đã không ngần ngại có nhữn dấc ngủ trưa. Bản thân tôi cũng bắt đầu ngủ 7-8 tiếng một ngày và cảm nhận rằng, mình đã trở nên hiệu quả hơn nhiều trong công việc của mình.

2. Nói ‘có’ ít thôi

Theo định luật Pareto thì 20% công sức tạo ra 80% sản phẩm, nhưng 20% sản phẩm sẽ ‘ngốn’ mất 80% công sức của bạn. Thay vì làm việc nhiều hơn, chúng ta nên tập trung vào mục tiêu chính. Chúng ta nên dừng nói “có” với các công việc mang lại ít hoặc không có kết quả.

“Sự khác biệt giữa người thành công và người rất thành công là người rât thành công nói không với gần như tất cả mọi thứ” – Warren Buffet

Vậy thì khi nào chúng ta nên nói “có” và khi nào nên nói “không”? Nếu bạn không quyết định được là công việc nào nên làm, thì bạn hãy thử làm Split Test (chia công việc ra làm 2 cột, 1 bên quan trong, 1 bên kém quan trọng). Tất cả chúng ta đều nói ‘có’ nhiều hơn là ‘không’ vì không ai thích là người xấu cả. Đọc thêm >>

3. Hãy để người khác giúp bạn thay vì tự mình làm tất cả

Tôi đã từng quản lý một cộng đồng rất lớn, nhưng đến một thời điểm, tôi đã không thể làm việc này nữa. Tôi đã cố gắng làm tất cả mọi thứ, nhưng điều đó đã quá sức của tôi. Nhưng thay vì đổ vỡ thì cộng đồng đó đã tự đứng lên. Các thành viên làm việc tốt hơn nhiều so với những gì tôi đã làm. Và khi đó, tôi đã hiểu sức mạnh của cộng đồng và vì sao các công ty lớn lại phải dùng đến user-generated content (nội dung hướng người dùng)

Người dùng biết họ muốn gì và họ muốn thế nào tốt hơn người làm. Theo Octoly thì các video hướng người dùng trên youtube có lượng người xem gấp 10 lần video do các nhà sản xuất up lên. Khi tìm thông tin về sản phẩm, hơn nửa số lượng người Mỹ (51%) tin thông tin do người dùng khác viết, 16% tin website của công ty và 14% tin quảng cáo. Vì vậy, chúng ta phải biết cách sử dụng sự giúp đỡ từ người ngoài.

Điều quan trong là chúng ta phải biết tìm đến sự giúp đỡ khi chúng ta cần đến. Chũng ta không thể tự làm hết mọi việc được. Tốt nhất là nên để cho chuyên gia trong lĩnh vực đảm nhiệm công việc đó thay bạn. Điều này sẽ cho phép bạn có nhiều thời gian làm những thứ mình cần làm hơn. Thay vì tốn thời gian để tìm hiểu, hãy để các chuyên gia giúp bạn.

Và kể cả khi họ không giúp được gì, có bạn bè bên cạnh cũng sẽ giúp bạn trở nên hiệu quả hơn.

4. Mạnh dạn thay vì quá cầu toàn

Tiến sỹ Simon Sherry, trường đại học Dalhousie đã nói “Chúng tôi tìm ra rằng, sự cầu toàn làm cho chúng tôi, trở nên kém hiệu quả hơn. Một tiến sỹ càng cầu toàn thì sẽ càng kém hiệu quả”. Đọc thêm >>

Sau đây là một số vấn đề của việc cầu toàn:

– Mất nhiều thời gian hơn cho một công việc
– Vì chờ đợi tình huống hoàn hảo mà họ bỏ qua rất nhiều cơ hội. Trong kinh doanh, nếu đấy là thời điểm hoàn hảo thì bạn đã quá muộn rồi.
– Họ không nhìn được bức tranh tổng quát vì họ quá tập trung vào các chi tiết.

Thời điểm hoàn hảo là NGAY BÂY GIỜ!

5. Hãy nghĩ cách tự động hóa nó

Theo bài nghiên cứu của Tethys Solution, một đội 5 người tốn 3%, 20%, 25%, 30% và 70% thời gian vào nhiệm vụ lặp đi lặm lại đã giảm thời gian xuống còn 3%, 10%, 15%, 15% và 10% sau 2 tháng suy nghĩ, cắt giảm công việc không cần thiết và tăng sự hiệu quả của họ.

Nhiều người quên rằng, thời gian chính là tiền bạc. Người ta thường tự làm mọi thứ, vì như vậy sẽ tiết kiệm được chi phí. Quản lý một thư viện Instagram với 30 ảnh thì thật là dễ dàng. Nhưng nếu bạn phải quản lý đến 30 000 cái ảnh và video trên 5 phần mềm khác nhau thì sao? Bạn sẽ cần một phần mềm chuyên dụng để quản lý hình ảnh và video, như Filemobile chẳng hạn. Nếu bạn không tìm ra được giải pháp thì bạn có thể thuê người làm cho bạn.

Hãy nhớ rằng bạn cần chi tiền để làm ra được nhiều tiền hơn nữa và thời gian là tài sản quý giá nhất của bạn.

6. Hãy minh chứng quyết định của mình bằng data thay vì chỉ đoán

Trên thế giới này có rất nhiều bài nghiên cứu với câu trả lời cho hầu hết các câu hỏi của bạn. Ví dụ, bạn có biết rằng con người dễ xao nhãng công việc từ trưa cho đến 4 giờ chiều nhất? Thông tin này đã được chứng minh bởi một bài nghiên cứu của Rodert Matchock, tiến sỹ tâm lý học tại đại học bang Pennsylvania. Và nếu bạn không tìm được data bạn cần, bạn luôn có thể làm Split test.

Ví dụ tuần trước chúng tôi đã làm một số test để tìm ra cách tối ưu hóa chế dộ xem ảnh trước cho Twitter. Đọc thêm >>

Bạn hãy hỏi bản than ‘làm cách nào mình có thể đo đếm và tối ưu hóa mọi thứ?’

7. Hãy cho mình được nghỉ ngơi.

Nhiều người không nhận ra rằng, chúng ta đang tự kìm hãm bản thân khi chúng ta quá chú tâm vào một vấn đề nào đó. Có những lúc bạn phải rời khỏi việc mình đang làm và có một chút thời gian cho bản thân. Những lúc thế này rất tốt cho não và tinh thần của bạn. Đọc thêm >>

Chúng ta cần phải quán chiếu lại bản thân. Nhiều khi câu trả lời sẽ đến với bạn mà bạn không cần phải đi tìm nó.

Kết luận

Chúng ta không thể trở nên hiệu quả hơn chỉ sau một đêm. Như tất cả mọi thứ trên thế giới này, bạn phải tự cố gắng để đạt được nó. Cơ hội sẽ không đến nêu bạn chỉ ngồi đợi. Điều quan trọng là bạn phải tìm hiểu về chính cơ thể mình và tìm ra cách tốt nhất để tối ưu hóa năng lượng của bản thân để có được thành công và một cuộc sống hạnh phúc hơn.

(Sưu tầm)

Read More »

ActionResult Subtypes

ActionResult is an abstract class that can have several subtypes.

• ViewResult - Renders a specifed view to the response stream
• PartialViewResult - Renders a specifed partial view to the response stream
• EmptyResult - An empty response is returned
• RedirectResult - Performs an HTTP redirection to a specifed URL
• RedirectToRouteResult - Performs an HTTP redirection to a URL that is determined by the routing engine, based on given route data
• JsonResult - Serializes a given ViewData object to JSON format
• JavaScriptResult - Returns a piece of JavaScript code that can be executed on the client
• ContentResult - Writes content to the response stream without requiring a view
• FileContentResult - Returns a file to the client
• FileStreamResult - Returns a file to the client, which is provided by a Stream
• FilePathResult - Returns a file to the client

Read More »

Cách xem chi tiết của exception trong C# (vd với EntityValidationErrors)

Giả dụ bạn chạy chương trình và bắt được một exception: "Validation failed for one or more entities. See 'EntityValidationErrors' property for more details". Exception đưa ra thông báo lỗi rất chung chung và không xác định được chính xác lỗi là do đâu ngay cả khi bạn đã view detail của exception. 

Hãy làm theo cách sau:

- Nhấn tổ hợp phím Shift + F9 để hiện màn hình QuickWatch 
- Copy đoạn code sau và paste vào ô text Expression: ((System.Data.Entity.Validation.DbEntityValidationException)$exception).EntityValidationErrors

$exception sẽ hiển thị bất cứ exception nào được ném ra trong đoạn mã hiện tại đang chạy, ngay cả khi nó không bị bắt và gán cho một biến nào.

Read More »

Singleton pattern

Trong thực tế, có rất nhiều đối tượng chúng ta chỉ cần duy nhất một thể hiện của chúng như: thread pools, caches, ghi log...Nếu có quá nhiều đối tượng này, có thể sẽ là nguyên nhân gây ra lỗi trong ứng dụng của chúng ta.
Hãy tưởng tượng Singleton pattern giống như tờ bookmark khi đọc sách. Tờ bookmark có thể đặt ở bất cứ đâu trong quyển sách và mỗi quyển sách chỉ nên có 1 bookmark. Nếu chúng ta có nhiều hơn 1 bookmark thì sẽ có khả năng gây nhầm lẫn cho chúng ta khi chúng ta ko biết được chúng ta đang đọc đến đoạn nào của cuốn sách. 
Singleton pattern đảm bảo chỉ một và duy nhất một đối tượng được khởi tạo. Singleton pattern cho ta cách truy vấn toàn cục giống như biến toàn cục (mà không có những điểm bất lợi giống biến toàn cục). Nếu dùng biến toàn cục thì bạn sẽ phải khởi tạo đối tượng ngay khi ứng dụng khởi động. Còn đối với Singleton, đối tượng sẽ được khởi tạo chỉ khi nào cần.
Đối tượng dùng Singleton thì sẽ không có public contructor, contructor sẽ là private.
Những điểm bất lợi của biến toàn cục so với singleton:
- khó biết được giá trị hiện tại của biến vì nó được set ở mọi nơi, điều gì xảy ra nếu có nhiều method set, get đồng thời giá trị của biến.
- phải hiểu một khối lượng code lớn tương tác với biến thì mới hiểu được đoạn code hiện tại đang xem xét mà có sự tương tác với biến toàn cụ

Chúng ta bắt đầu với cách thứ nhất

using System;

public class Singleton
{
   private static Singleton instance;

   private Singleton() {}

   public static Singleton Instance
   {
      get 
      {
         if (instance == null)
         {
            instance = new Singleton();
         }
         return instance;
      }
   }
}

Theo cách làm trên thì trong môi trường multi-thread, tại một thời điểm có thể có 2 thread cùng chạy vào đoạn kiểm tra biến instance == null và nó sẽ tạo ra 2 thể hiện của class. Như vậy cách này không đảm bảo Singleton trong môi trường multi-thread.

Cách 2: Đảm bảo tính thread-safe của class

public sealed class Singleton
{
   private static volatile Singleton instance;
   private static object syncRoot = new Object();

   private Singleton() {}

   public static Singleton Instance
   {
      get 
      {
         lock (syncRoot) 
         {
            if (instance == null) 
               instance = new Singleton();
         }

         return instance;
      }
   }
}

Đoạn code trên sử dụng một shared object để lock phần code kiểm tra instance == null và đảm bảo chỉ có duy nhất 1 thread được phép khởi tạo instance. Cách làm này đảm bảo tính thread-safe của class Singleton nhưng lại gây ảnh hưởng về mặt hiệu năng của chương trình. Như các bạn thấy, mỗi lần gọi đến Instance là hàm lock cũng được gọi. Vì thế ta có cách dưới đây:

using System;

public sealed class Singleton
{
   private static volatile Singleton instance;
   private static object syncRoot = new Object();

   private Singleton() {}

   public static Singleton Instance
   {
      get 
      {
         if (instance == null) 
         {
            lock (syncRoot) 
            {
               if (instance == null) 
                  instance = new Singleton();
            }
         }

         return instance;
      }
   }
}

Bạn có thể thấy cách thứ 3 này đảm bảo tính thread-safe của class Singleton mà không phải gọi lại hàm lock mỗi lần sử dụng. Đây cũng là cách mà Microsoft khuyên bạn nên sử dụng khi thiết kế một Singleton class.

Read More »

C# 2 – Cơ chế yielding và ‘yield’ keyword trong Iteration

“yield” – Một từ khóa có vẻ lạ lẫm với bạn nhưng đã được ứng dụng từ lâu trong lĩnh vực lập trình và trong khá nhiều ngôn ngữ. Từ khóa này gắn liền với các kĩ thuật như Generator, Coroutine và các đối tượngiterator. Ta sẽ khám phá cơ chế và cách sử dụng của từ khóa này như thế nào.

Giới thiệu

Theo MSDN:

The yield keyword signals to the compiler that the method in which it appears is an iterator block. The compiler generates a class to implement the behavior that is expressed in the iterator block. In the iterator block, the yield keyword is used together with the return keyword to provide a value to the enumerator object. This is the value that is returned, for example, in each loop of a foreach statement. The yield keyword is also used with break to signal the end of iteration.

Có thể hiểu đơn giản là “yield” sẽ kết hợp với từ khóa “return” cho phép trả về các giá trị từ trong vòng lặp, và sau đó nó có thể trở lại vòng lặp và tiếp tục cho phần tử tiếp theo.

Điều này khá kì lạ nhưng nếu bạn đã đọc các link từ Wikimedia trong lời mở đầu thì bạn sẽ hiểu được một cách rõ ràng. Điều mà tôi muốn nhắc tới ở đây là “yield return” sẽ không làm cho phương thức chứa nó kết thúc mà vẫn tiếp tục chạy cho đến khi kết thúc vòng lặp và thực thi xong câu lệnh cuối cùng. Muốn kết thúc phương thức bạn phải dùng một cặp từ khóa khác là “yield break”.

Quy định

–       Không đặt “yield” trong các khối unsafe.

–       Các tham số của phương thức, toán tử, accessor (getter / setter) không được dùng các từ khóa ref hoặc out.

–       “yield return” chỉ có thể được đặt trong khối try nếu như nó được theo sau bởi khốifinally.

–       “yield break” có thể đặt trong các khối try và catch nhưng không được đặt trong khốifinally.

–       Không dùng “yield” trong anonymous method.

Cách dùng

Để sử dụng “yield return”, bạn chỉ cần tạo một phương thức với kiểu trả về là một IEnumerable(mảng và collection trong .Net đều implement interface IEnumerable)  với vòng lặp và dùng “yield return” để trả về các giá trị cần thiết trong thân vòng lặp.

Ví dụ thay vì viết một phương thức Foo1() để lấy một mảng int từ 0 đến một số nào đó như dưới đây:

1 2 3 4 5 6 7 8 9

public static IEnumerable Foo1(int number) {     int[] numbers = new int[number];     for (int i = 0; i < number; i++)     {         numbers[i] = i;     }     return numbers; }

Bạn có thể thay thế phương thức trên bằng phương thức sau:

1 2 3 4 5 6 7

public static IEnumerable Foo2(int number) {     for (int i = 0; i < number; i++)     {         yield return i;     } }

Rõ ràng là thay vì trả về nguyên một đối tượng IEnumerable, ta sẽ trả về từng phần tử riêng lẻ và khi kết thúc phương thức, bạn không cần phải return thêm bất kì đối tượng nào.

Bạn có thể chạy thử đoạn mã sau:

Listing 1:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23

using System; using System.Collections;   public class YieldTest {     public static IEnumerable Foo2(int number)     {         for (int i = 0; i < number; i++)         {             yield return i;         }     }       static void Main()     {         foreach (var item in Foo2(10))         {             Console.Write(item);         }           Console.Read();     } }

Output:

0123456789

Bạn có thể đặt break point tại dòng 10 và dòng 18 (hai dòng được highlight) và chức năng debug continue (F5) thì sẽ thấy rằng hai break point này sẽ thay phiên nhau được kích hoạt. Điều này chứng tỏ rằng chương trình có thể nhảy qua lại giữa hai phương thức mà không làm mất trạng thái hiện tại của chúng.

Giả sử bạn muốn thoát ra khỏi phương thức khi i = 5, ta cần sửa lại phương thức Foo2() trên:

1 2 3 4 5 6 7 8 9

public static IEnumerable Foo2(int number) {     for (int i = 0; i < number; i++)     {         if (i == 5)             yield break;         yield return i;     } }

Ưu điểm

Một ưu điểm của việc dùng “yield” mà bạn có thể thấy ngay ở ví dụ đầu tiên là số lượng dòng code sẽ được giảm đi.

Hơn nữa, vì hai phương thức làm việc luân phiên nhau, bạn không cần thiết phải tạo hoặc lấy nguyên một danh sách các phần tử để duyệt. Điều này được áp dụng trong những trường hợp như tìm kiếm, số lượng phần tử cần duyệt sẽ được giảm bớt tùy theo vị trí của phần tử cần tìm.

Cơ chế hoạt động

Trong phương thức Foo2() mới này, bạn sẽ không nhận thấy sự khác biệt nếu thay yield break bằng break bởi vì khi vòng lặp bị kết thúc bằng break thì phương thức cũng kết thúc theo. Muốn kiểm tra sự khác biệt, bạn hãy dùng Console.WriteLine() in gì ra màn hình ở cuối phương thức Foo2() trên.

Khi dùng ILDasm.exe phân tích Listing 1 ta nhận thấy compiler đã tạo ra một lớp con trong lớp YieldTest:

Hoặc dùng một Reflector của hãng thứ ba để disassemble lớp này ra mã C# ta được code tổng quát sau:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26

private sealed class <Foo2>d__0 : IEnumerable<object>, IEnumerable, IEnumerator<object>, IEnumerator, IDisposable {     // Fields     private int <>1__state;     private object <>2__current;     public int <>3__number;     private int <>l__initialThreadId;     public int <i>5__1;     public int number;       // Methods     [DebuggerHidden]     public <Foo2>d__0(int <>1__state);     private bool MoveNext();     [DebuggerHidden]     IEnumerator<object> IEnumerable<object>.GetEnumerator();     [DebuggerHidden]     IEnumerator IEnumerable.GetEnumerator();     [DebuggerHidden]     void IEnumerator.Reset();     void IDisposable.Dispose();       // Properties     object IEnumerator<object>.Current { [DebuggerHidden] get; }     object IEnumerator.Current { [DebuggerHidden] get; } }

Như vậy bạn có thể rằng đây thực chất là một lớp làm việc dựa trên IEnumertor với các phương thức chính là MoveNext(), Reset() và property Current.

Dựa theo phương pháp này, bạn có thể dễ dàng cài đặt và tự tạo ra kĩ thuật tương tự “yield” để dùng trong các ngôn ngữ không hỗ trợ từ khóa này chẳng hạn như VB.Net.

Nguồn : yinyangit.wordpress.com

Read More »