Why I don’t code in my free time, and why you should not, too.

Just read a story that bogged my mind. A “Technical/team lead” told a story, as him, an interviewer, asked “a very good” candidate about what does he/she like, and what does he/she do on his/her spare time. The answers were reading books, watching movies, and cooking.

The candidate¬†did not get hired. The interviewer expected him/her to “work” on his/her spare time. Like a pet project – to learn something new, or to sharpen the skills.

I’m glad I was not neither in that kind of interview, nor I have that kind of boss.

Continue reading “Why I don’t code in my free time, and why you should not, too.”

1600 vs 1400 vs 1200 rpm washing machine

I got this question before – and now I bought one, I hope I can help you choosing the right washing machine.

You might have read other answers on the Internet – and yes most of them are saying a 1200 rpm washing machine is as good as a 1600 rpm one, in term of the dryness of the clothes.

Wrong!

That might be true with synthetic clothes – which are the easiest ones to dry. But for cotton, it’s a big different. I tried same clothes with both 1400 rpm and 1600 rpm and my clothes are noticeable drier when it comes out of 1600 rpm mode. 1200 rpm, of course, is not even close.

That means the time you need to dry it, as well as the consumption of the dryer, will be less.

And to endure 1600 rpm spinning speed, the washing machine must be sturdier and more balanced. In other words, it must be built better – so you can expect it to last longer. You can see that in same series, the higher model which supports 1600 rpm is always heavier than the lower end models. Yes – it’s to support the faster rotation.

So if you have cotton clothes, and if you can afford it, I would suggest to go to 1600 rpm one.

Episerver Commerce performance optimization – part 2

Or lock or no lock – that’s the question.

This is the second part of the series on how can you improve the performance of Episerver Commerce site – or more precisely, to avoid the deadlocks and 100% CPU usage. This is not Commerce specific actually, and you can apply the knowledge and techniques here for a normal CMS site as well.

It’s a common and well-known best practice to store the slow-to-retrieve data in cache. These days memory is cheap – not free – but cheap. Yet it is still much faster than the fastest PCIe SSD in the market (if your site is running on traditional HDD, it’s not even close). And having objects in cache means you won’t have to open the connection to SQL Server, wait for it to read the data and send back to you – which all cost time. And if the object you need is a complex one, for example a Catalog content, you will also save the time needed to construct the object. Even if it’s fast, it is still not instantaneous, and it will cost you both memory and CPU cycles. All in all – caching is the right way to go. But how to get it¬†right?

One common mistake for to have no lock when you load the data for the first time and insert it into cache.

Continue reading “Episerver Commerce performance optimization – part 2”

May I trust your site?

If your site has exceeding ads, or you ask me to disable my adblocker, then no.

If your site ask me to subscribe to your newsletter after 5 seconds, then no.

If your site has no comment section, then no.

If you don’t moderate your comment section and it’s full of spam, then no.

If your site open pops up, then no.

If you site doesn’t have HTTPS, then that might raise suspects. (Yes you should look up in the address, this site is not HTTPS-enabled, and that’s entirely my fault, but I would never ask for your information more than a name and an email address (you don’t have to give a real one)). I know, I should have spent time to enable HTTPS on this site, I’m just too busy writing content (another way to say I’m lazy).

 

 

Find indexing job + HierarchicalCatalogPartialRouter: A note

I ran into this problem recently and while in the end it’s quite simple issue (Everything is simple if we understand it, right?), it costed me quite many hairs in the process – as it involved debugging with 3 solutions – Find.Commerce (where the problem appears), Commerce (where the router does the work), CMS Core (where the routers are handled). It was both fun, and confusing.

The problem as a customer has this code in an initialization module:

Continue reading “Find indexing job + HierarchicalCatalogPartialRouter: A note”

Episerver Commerce performance optimization – part 1

This is a first part of a long series (which have no planned number of parts) as the lessons I learned during trouble shouting customers’ performance problems. I’m quite of addicted to the support cases reported by customers, especially the ones with performance problems. Every time I jump into such support case, I’ll be with less hairs, but I also learn some new things: ¬†Implementations are different from cases to cases, but there are some common mistakes which will hurt your website performance. This series will try to point out those mistakes so you get your performance gain, for (almost) free:

Mistake 1: Loading to much content

It’s easy to load contents, especially with the new content APIs. Given an universal ContentReference, you can load a content with a simple line of code. By default, the loaded content is cached, so you might think it’s cheap, or even free to load a content. Think again.

Continue reading “Episerver Commerce performance optimization – part 1”