The problem I want to discuss is quite strange to me. Several times I was working on the projects where code coverage was one of the key metrics. Unfortunately a lot of managers without technical background know that “High coverage guarantees stable project without regression bugs”. As a result instead of analyzing the project, code base and opportunities project comes to decision that “Unit Tests will save us all (and money, of course)”.
When you are starting the new project you probably facing an issue of picking up proper technical stack. There are dozens of frameworks (
Vue.js), libraries (
lodash), tools (
gulp) and even languages (
Reason) available for front-end developers. At this point of time most of the developers are starting to search information, comparison articles in the Internet. I’ve been working with the Angular (a.k.a. Angular2+) for last year and I want to share my thoughts about my personal experience.
Today I want to share some thoughts on the current state of NPM packages infrastructure. I’m pretty sure that NPM is very good thing:
- It’s easy to use. Seriously, I love the way it’s working. Recent changes, like adding
package.lock.jsonare making NPM better and better every day;
- It has a good community and it’s very popular. You can literally find everything that you need here;
However I’m a bit disappointed in the current state of dependency graphs for most of the popular packages.
Continue reading “NPM dependency hell”
Time goes on and I have a bunch of articles to read. As in the first post here is the list of five articles:
- A Complete Guide to Grid – CSS Grid is amazing. Seriously. And the good news is that you can already use it (with some limitations if you still need to support Internet Explorer). But anyway, this article is really good introduction with a lot of visual samples, I use it as a cheat sheet, because data is well-structured and contain a lot of visualization;
- The introduction to Reactive Programming you’ve been missing – this one is quite “old” but not outdated. I’d say the opposite. After the release of Angular which is heavily relies on RxJS this article is mandatory for reading. If you haven’t used streams before probably you’ll have issues at the beginning of your way. This article should be a guiding light for you;
- Debugging React performance with React 16 and Chrome Devtools. – this one is very basic but still can be useful if you’ve never monitored performance of your applications;
- Get Started With Analyzing Runtime Performance – one more good article describing available tools for performance analysis;
- Orinoco: young generation garbage collection – this one is more theoretical but still quite important. Because understanding how garbage collection is working is crucial for every developer;
That’s all for now. Thanks!
Nowadays the amount of articles, blog posts and other sources of information is so huge. It makes it impossible to read all of the posted text. So here is the list of 5 articles I’ve read recently which I found quite useful:
- The Shocking Secret About Static Types – this one I think quite interesting because it provides some thoughts regarding benefits of static types. If you are thinking regarding using TypeScript in your next project – consider reading this one;
- You Might Not Need TypeScript (or Static Types) – this one is like an continuation of the previous one. More thoughts, ideas and alternatives;
- Choosing a frontend framework in 2017 – actually this one is not about choosing a framework. It’s more about evolution of front-end architectures and patterns. Anyway I found this one very interesting;
That’s all for now. Thanks!
Automated regression testing on the big projects is one of the important approaches. A lot of projects are using this approach to reduce costs on manual regression testing, speed up the delivery, reduce costs of bug fixing. Automated UI testing is not an easy task because it’s tightly coupled with data, it’s highly dependent on HTML mark up, it’s slow (because communicating with browser via web driver, grabbing data from different HTML elements is slow), it’s really hard to verify visual issues with this approach (for example positioning of dialog on the viewport).
Continue reading “Visual regression testing”
I’ve started to write a small game on GitHub to try Node.js, because I’ve never touched Node.js during work hours. On my current project I’ve back-end written with Microsoft .NET. I’ve decided to not use any UI framework, I just added Browserify to share some code between front-end source code and back-end source code. I’ve written a small amount of code and tried to cover this code with Unit Tests. And at this point I found that I have nothing to cover…