“Chỉ có kẻ ngốc mới cố gắng kiếm tiền hàng ngày từ chứng khoán” – Bài học từ trader huyền thoại Jessive Livermore

Jesse Lauriston Livermore nổi danh là một trong các nhà kinh doanh vĩ đại của thế kỷ 20. Chỉ một số ít người có khả năng kiếm được lợi nhuận lớn, hoặc mất tất cả, nhanh như Livermore. Được biết đến như một “con bạc trẻ liều lĩnh” bởi cách ông ta dám đầu cơ một lượng lớn cổ phiếu hoặc hàng hóa, Livermore đã sống theo đúng cách thức kinh doanh của mình – tiến hết sức lực về phía trước.

Ông ta cũng rất nổi tiếng đối với giới nữ vì vẻ bề ngoài bảnh trai và cách sống hào nhoáng trong giàu sang của mình. Mặc dù thời đại của ông đã qua nhưng những trader đời sau vẫn luôn coi ông là một tượng đài học tập, và những bài học của ông để lại vẫn có ý nghĩa cho đến tận ngày nay.

Sau đây là những bài học của ông mà thế hệ sau nên học hỏi:

Dòng tiền liên tục đổ vào thị trường, hằng ngày luôn có kẻ mua người bán tuy nhiên không phải lúc nào bạn cũng có thể kiếm được tiền mỗi ngày. Chỉ có kẻ ngốc mới cố gắng kiếm tiền hàng ngày hàng tuần từ chứng khoán.

Mọi thứ ngoài bản chất tốt vẫn còn mang tính thời điểm. Có thời điểm bạn không thể kiếm được tiền hoặc có thể mất tiền, do vậy đừng cố gắng kiếm tiền mọi thời gian trong đầu tư bởi có thể bạn sẽ bị khánh kiệt. Tài khoản đầu tư thực chất cũng như một cổ phiếu, và một ví dụ điển hình là cổ phiếu VNM mặc dù đi lên liên tục trong gần 10 năm nay nhưng có những lúc nó vẫn phải chững lại hoặc suy giảm trong ngắn hạn.

Đừng cố đoán trước xu hướng của thị trường cho tới khi những dấu hiệu từ hệ thống giao dịch của bạn xác nhận điều đấy. Trâu chậm đôi khi vẫn uống được nước trong!

Đôi khi có những nhà đầu tư tự hỏi tại sao nếu đã tăng thì không mua sớm hơn vì được giá rẻ hơn, tuy nhiên đầu tư thực chất cũng là 1 trò chơi xác xuất và khi thị trường đưa ra những tín hiệu chắc chắn phù hợp với hệ thống giao dịch khả năng thắng của bạn mới cao, đồng nghĩa với việc rủi ro của bạn giảm xuống so với việc bạn tham gia thị trường quá sớm.

Chuyển động thực sự của thị trường cần thời gian để hoàn thành, không phải dừng lại trong một ngày.

Nhiều nhà đầu tư luôn tự hỏi tại sao nhiều khi tin tốt cho thị trường ra nhưng thị trường vẫn không chạy, sở dĩ có điều này bởi bản thân cổ phiếu hay thị trường đều phải có giai đoạn tích lũy và phải hoàn thiện thì giá mới chuyển động theo chiều hướng phù hợp với điều kiện ở thời điểm đấy. Do vậy nếu không có lòng kiên nhẫn chờ đợi biến động thực sự của thị trường xảy ra, rất có thể nhà đầu tư sẽ lâm vào trạng thái mua đỉnh bán đáy ngắn hạn do chán nản.

Suy nghĩ không tạo ra tiền, chỉ có lòng kiên nhẫn mới tạo ra tiền.

Để kiếm được tiền cần chờ đợi những biến động thực sự từ thị trường diễn ra, do vậy việc bạn suy nghĩ rằng thị trường sẽ lên hay xuống sẽ chẳng giúp bạn kiếm ra tiền nếu bạn không đủ kiên nhẫn đợi những tín hiệu chắc chắn từ hệ thống giao dịch của mình,

Dù bạn có giỏi đến đâu, thua lỗ luôn tồn tại trong quá trình đầu tư

Như ở mục 1 đã đề cập, có những giai đoạn bạn sẽ không kiếm được tiền hoặc là mất tiền và bạn phải chấp nhận điều đó. Thua lỗ ở đây là chi phí cho quá trình kiếm lợi nhuận, việc bạn cần làm là tối thiểu chi phí đấy.

Luôn có một kế hoạch trước khi giao dịch.

Cảm xúc luôn là kẻ thù trong việc trading, để hạn chế được cảm xúc có lẽ bạn cần có 1 kế hoạch trước khi giao dịch và kỷ luật cao để làm theo kế hoạch. Có như vậy mới tránh được những giao dịch mang tính cảm tính và hạn chế được thua lỗ trong quá trình đầu tư.

Read More »

Tôi đã ngừng ý định giúp đỡ người khác, và tôi khuyên bạn cũng nên như thế!

Đây là những lời của CamMi Phạm, một blogger thành công, người đặt ra các quy tắc về giúp đỡ mọi người trong cuộc sống.

Mẹ tôi dạy tôi rằng: "Đừng bao giờ cố gắng đưa ra lời khuyên hay cố gắng giúp đỡ bất cứ ai khi mà họ yêu cầu." Tôi đã luôn nghĩ rằng có lẽ mẹ tôi hơi vô tâm hoặc thuộc tuýp người lạnh lùng. Nhưng khi trưởng thành, tôi bắt đầu nhận ra rằng bà đã đúng. Mẹ tôi là một trong những người tốt bụng nhất trên đời, ít nhất là đối với tôi.

Xã hội luôn luôn nhấn mạnh về sự cần thiết trong việc giúp đỡ mọi người. Và tôi cũng luôn tâm niệm rằng bản thân sẽ làm tốt điều đó!

Ai đó nói với bạn rằng bạn nên giúp đỡ người khác vô điều kiện, kể cả khi họ không mong đợi. Tất nhiên là sự tử tế có thể thay đổi cuộc sống của một người trong nhiều trường hợp. Tuy nhiên, bất cứ sự việc nào cũng đều có hai mặt của nó.

Không phải mọi thứ đều xấu. Tương tự như vậy, không phải mọi thứ đều tốt. Nghĩa là việc giúp đỡ mọi người không phải là điều tồi tệ, và chẳng phải lúc nào cũng là điều tuyệt vời. Dưới đây là những lý do tại sao tôi dừng lại việc giúp đỡ tất cả mọi người, và tôi khuyên bạn cũng nên như thế:

1. Đừng giúp đỡ người không xứng đáng nhận sự trợ giúp từ bạn

"Khi bạn trưởng thành, bạn sẽ phát hiện ra rằng bạn có hai bàn tay, một là để giúp đỡ chính mình, và một là để giúp đỡ những người khác." - (Sam Levenson) 

Trong quá khứ, khá nhiều lần người ta mời tôi đi uống cà phê chỉ để "tận dụng chất xám của tôi". Nếu đó là một người giàu có, với số tiền đáng mơ ước trong các tài khoản ngân hàng, vậy mà họ vẫn muốn "tận dụng" não bộ của tôi một cách free (miễn phí) thì rõ là không thể chấp nhận được. Thậm chí, họ còn không bận tâm trả tiền cà phê cho tôi. 

Họ không hiểu rằng tôi cũng có một gia đình để nuôi, có những hóa đơn cần chi trả hàng tháng, và có cả những khoản nợ đã đến kỳ thanh toán. Họ không nhận ra rằng để dành thời gian cho việc đi cà phê với họ, tôi sẽ phải bù lại khoảng thời gian đã mất đó và làm việc tới tận 2 giờ sáng.

Nếu họ không nghĩ rằng thời gian của tôi là có giá trị, thì tôi cũng sẽ không dành thời gian cho họ! Cho nên, nếu ai đó không quan tâm tới bạn, thì bạn không cần phải giúp đỡ họ. Bởi vì họ không xứng đáng nhận được sự giúp đỡ đó.

Bây giờ khi một ai đó cần sự giúp đỡ, tôi sẽ đưa ra một mức giá được cho là phù hợp với đôi bên. Điều này nghe có vẻ hơi "thực dụng", nhưng ít ra cũng sẽ làm cho cuộc sống của tôi dễ dàng hơn và tôi hạnh phúc hơn khi biết sự giúp đỡ của mình được ghi nhận bằng một giá trị cụ thể nào đó. Cũng chính vì vậy mà mọi người sẽ suy nghĩ nghiêm túc hơn trước khi họ quyết định yêu cầu điều gì đó từ tôi. Nếu ai đó không thể đủ khả năng để chi trả, tôi thường cung cấp cho họ những sự lựa chọn phù hợp hơn.

Mọi người sẽ luôn luôn cố gắng để khai thác bạn nếu bạn cho phép họ. Nhưng thực tế là bạn không có thời gian để giúp đỡ tất cả mọi người, vậy nên hãy chỉ giúp những người xứng đáng được giúp đỡ từ bạn mà thôi. Và tôi có hai quy tắc dành cho bạn:

Quy tắc 1: Không bao giờ cung cấp bất cứ thứ gì miễn phí.

Quy tắc 2: Không bao giờ quên quy tắc 1.

Hãy nhớ rằng, người đầu tiên bạn cần phải giúp đỡ là CHÍNH BẠN! Nếu giúp mọi người không làm cho bạn cảm thấy vui vẻ và thoải mái, thì đơn giản là bạn không cần phải làm điều đó.

Đôi khi bạn cần phải là ích kỷ và đặt mình quan trọng hơn bất cứ ai. Bỏ qua những gì xã hội đang thúc giục bạn làm đi, vì xã hội không hề chịu trách nhiệm cho cuộc sống của bạn. Bạn nghèo đói hay giàu sang, xã hội cũng mặc kệ!

2. Đừng giúp đỡ người không đánh giá cao sự trợ giúp của bạn

Nhược điểm lớn nhất của tôi là tôi luôn muốn giúp đỡ mọi người. Tôi giúp mọi người kể cả khi không biết họ có yêu cầu hay không. Nhưng bạn không bao giờ biết khi nào lòng tốt ấy có thể làm tổn thương đến bạn.

Một khách hàng cũ của tôi đang gặp trục trặc trong việc kinh doanh. Tôi cùng các chiến hữu trong team của mình đã dành một vài ngày phân tích tất cả các dữ liệu để tìm ra những vấn đề tồn tại.

Đó không phải là công việc của chúng tôi và chúng tôi cũng không hề yêu cầu họ chi trả cho điều đó. Chúng tôi chỉ làm vì chúng tôi quan tâm đến sự thành công của khách hàng. Team của tôi đã tìm thấy một số vấn đề nghiêm trọng với mô hình kinh doanh và chiến lược của vị khách hàng đó. Nhưng khi chúng tôi nêu ra các vấn đề, vị khách hàng đã nổi giận. 

Chúng tôi đã làm điều đó xuất phát từ lòng tốt, và khi chúng tôi nói với khách hàng những gì họ không muốn nghe, lập tức, chúng tôi bị chỉ trích hoặc ghét bỏ. Chỉ vì chúng tôi đã cho ý kiến ​​chuyên môn của mình.

Cách dễ nhất để biến bạn bè của bạn thành kẻ thù là cung cấp cho họ những lời khuyên mà họ không muốn nghe.

Khi tôi muốn giúp đỡ một người nào đó, nghĩa là tôi thực sự mong muốn làm điều đó. Nhưng nhiều khi, mọi người không sẵn sàng chấp nhận sự giúp đỡ của tôi. Cũng dễ hiểu. Bởi tất cả mọi thứ đều cần có thời gian để thay đổi và hầu hết mọi người đều không dễ dàng đối mặt với những sự thật tiêu cực.

Vì vậy mà tôi khuyên bạn không nên cung cấp lời khuyên khi mọi người chưa sẵn sàng tiếp nhận nó. Rất có thể vào một ngày nào đó, họ sẽ trở nên cáu kỉnh và đổ lỗi ngược lại cho bạn chỉ vì công việc của họ không đạt được kết quả như mong đợi.

Đó cũng là lý do mà tôi chẳng bao giờ nhận giúp đỡ một ai nữa khi mà cảm thấy họ có vẻ không thật sự tôn trọng lòng tốt và sự nhiệt thành của tôi. Và ít ra thì như thế cũng có nghĩa là tôi sẽ có nhiều thời gian hơn cho bản thân mình.

3. Đừng giúp đỡ người khác nếu bạn không đủ khả năng

Đây là một trong những điều quan trọng nhất. Giúp đỡ một ai đó khi bạn không đủ khả năng là điều vô cùng tồi tệ. Tôi đã làm điều này rất nhiều lần, và đến ngày hôm nay tôi vẫn hối tiếc vì đã làm điều đó.

Một vài năm trước, cha mẹ tôi đi nước ngoài và yêu cầu tôi chăm sóc ngôi nhà của họ, tôi đã gặp khó khăn trong việc chăm sóc cây cảnh. Có khi tôi tưới chúng quá đẫm, nhưng cũng có khi tôi để chúng khô hạn. 

Một tháng sau khi cha mẹ tôi trở lại, tất cả các cây đều đã chết. Nếu tôi không nhận lời với họ, có lẽ một người sành sỏi về chăm sóc cây cảnh sẽ được thuê để làm điều đó. Và như vậy thì đám cây cảnh của cha tôi sẽ không bị chết thê thảm. Sau lần ấy, cho tới tận bây giờ, cha tôi đã không yêu cầu tôi chăm sóc cây cảnh thêm một lần nào nữa. 

Hãy nhớ, sự nhiệt tình cộng với sự ngu dốt chính là sự phá hoại!

Cung cấp sự trợ giúp khi bạn không thể làm tốt công việc sẽ là lợi bất cập hại. Bạn sẽ khiến cho mọi người bỏ lỡ cơ hội để tìm sự giúp đỡ khác tốt hơn. Và lòng tốt của bạn cũng có thể làm tổn thương người khác, trong một số trường hợp. Một trong những cách dễ nhất để tiêu diệt một mối quan hệ là cố gắng trao đi sự giúp đỡ vượt quá khả năng của mình.

Vậy nên, đừng quá dễ dàng gật đầu trước khi nhận một yêu cầu trợ giúp nào. Hãy suy nghĩ thật kỹ! Bởi một hành động ngẫu nhiên của sự tử tế có thể thay đổi cuộc sống của một ai đó, nhưng nó cũng có thể phá hủy cuộc sống của một ai đó.

Read More »

Visual studio crash with Microsoft.WITDataStore.dll error

Clear everything in Team Foundation cache folder:
C:\Users\phongcao.nguyen\AppData\Local\Microsoft\Team Foundation\5.0\Cache

Read More »

Error: XMLHttpRequest on the main thread is deprecated

To avoid this warning, do not use:

async: false

in any of your $.ajax() calls. This is the only feature of XMLHttpRequest that's deprecated.

The default is async: true, so if you never use this option at all, your code should be safe if the feature is ever really removed (it probably won't be -- it may be removed from the standards, but I'll bet browsers will continue to support it for many years).

Another reason (In my case):

- using : async: false

- Call CountAsync() (Iqueryable):

        public virtual int Count(Expression<Func<TEntity, bool>> where)
        {
              return where == null ? _dbSet.AsQueryable().CountAsync().Result :            _dbSet.Where(where).CountAsync().Result;
        }

Read More »

the differences between using a static lock object (code A) and a non-static lock object (code B) for a synchronized block

The difference is simple: if the locked-on object is in a static field, then all instances of MyClass*will share that lock (i.e. no two objects will be able to lock on that object at the same time).

If the field is non-static, then each instance will have its own lock, so only calls of the method on the same object will lock each other.

When you use a static lock object:

• thread 1 calls o1.foo()
• thread 2 calls o1.foo(), will have to wait for thread 1 to finish
• thread 3 calls o2.foo(), will also have to wait for thread 1 (and probably 2) to finish

When you use a non-static lock object:

• thread 1 calls o1.foo()
• thread 2 calls o1.foo(), will have to wait for thread 1 to finish
• thread 3 calls o2.foo(), it can just continue, not minding thread 1 and 2

Which one of those you'll need depends on what kind of data you try to protect with your synchronized block.

As a rule of thumb, you want the lock-object to have the same static-ness than the operated-on value. So if you manipulate non-static values only, you'll want a non-static lock object. If you manipulate static values only, you'll want a static lock object.

When you manipulate static and non-static values, then it'll become complicated. The easy way would be to just use a static lock object, but that might increase the size of the synchronized-block more than absolutely necessary and might need to more lock contention than desired. In those cases you might need a combination of static and non-static lock objects.

In your particular case you use the lock in the constructor, which will only ever be executed once per instance, so a non-static lock-object doesn't make any sense here.

http://stackoverflow.com/questions/18356795/static-versus-non-static-lock-object-in-synchronized-block

Read More »

Expression vs Func with Entity Framework

Sometimes developers don't know whether they should use a Func<> or an Expression<Func<>> with the Entity Framework and LINQ. The distinction was critical in a situation I faced today.

Our application was having performance problems, and Red Gate's excellent ANTS profiling tool pointed to a method that, reduced to its essence, was like what you see below. Context is an Entity Framework context, and MyEntities is one of the entity tables in the context. 

IEnumerable<MyEntity> LoadMyEntities(Expression<Func<MyEntity, bool>> predicate)
{
    return Context.MyEntities.Where(predicate);
}

The idea is that a caller can pass in a predicate in the form of a Lambda. The compiler will turn the Lambda into a LINQ Expression, which can be passed to the method in the 'predicate' parameter.

int id;
// Set the id somehow and then...
var theEntity = LoadMyEntities(e => e.UniqueId == id).Single();

The profiler told us that LoadMyEntities was being called many, many times and it was taking a large fraction of our CPU time. The simple change below solved the problem. Can you guess why?

public IEnumerable<MyEntity> LoadMyEntities(Func<MyEntity, bool> predicate)
{
    return Context.MyEntities.Where(predicate);
}

The parameter is now a Func<> instead of an Expression<Func<>>. The reason this makes a difference is that a predicate that's in the form of an Expression is passed to SQL server, but a predicate that's passed as a Func is not. Normally, you'd want SQL Server to do as much for you as possible, and an Expression would be the right choice, but in this case we'd like to pre-load the entire table in the context -- which is exactly what a Func will do. (This the same point I made in Falling in Love with LINQ, Part 7.) Step by step...

1. The Where extension method has two flavors. One extends IQueryable and takes an Expression parameter. The other extends IEnumerable and takes a Func.
2. Because 'predicate' is now a Func, the Where that extends IEnumerable is used.
3. The Entity Framework's fluent interface for constructing SQL queries is based on IQueryables, not IEnumerables. Therefore, the fluency stops just before the Where. The part of the statement that gets passed to the Entity Framework is just Context.MyEntities.
4. Context.MyEntities therefore returns the entire table to the context.
5. The entire table is now filtered with the predicate, and the value we really want is returned.
6. The next time the method is called, the Entity Framework realizes that the record we want is already in the context. (In my case, we were querying by the primary key, and EF is apparently smart enough to know that if there's a record in the context with that ID, it won't find an additional such record in the database.) Since we don't go out to SQL Server, we save lots of time. Obviously there are occasions when you would not want this, but in our case it was exactly what we wanted. The table was relatively small, and the same context was queried hundreds of times.

In the original version, the predicate was an Expression, so the compiler used the Where that extends IQueryable. The predicate was thus passed to SQL Server, which dutifully returned just one row to the context. The next time we called LoadMyEntities, Entity Framework had to call SQL Server again.

The change from Expression to Func gave us a 6-fold reduction in CPU usage! But again, your situation may call for an Expression. The important thing is to know the difference, and now you do!

Link: http://fascinatedwithsoftware.com/blog/post/2012/01/10/More-on-Expression-vs-Func-with-Entity-Framework.aspx

Read More »

Handler "has a bad module "ManagedPipelineHandler" in its module "

Ran command:

%windir%\Microsoft.NET\Framework64\v4.0.30319\aspnet_regiis.exe -i

If I had been on a 32 bit system, it would have looked like the following:
%windir%\Microsoft.NET\Framework\v4.0.21006\aspnet_regiis.exe -i

Read More »