Forem: Aleksey Pastuhov

Make Dart/Flutter test report readable

Aleksey Pastuhov — Tue, 17 Dec 2019 07:50:21 +0000

Hello there! I will try to be short.

Intro

Short

Flutter test report is not human-friendly.

Long

On my personal Flutter project, I’ve started the setup of Continuous Integration & Continuous Deployment. And in Flutter test report is difficult to use. The report is hard to read & understand in case of failure. Sure, in case of success, everything is good, because there is just one line.

Flutter has big error stack traces. When it has some exception not in your codebase, but in Flutter itself. I mean errors with positioning or sizing, and for them, you will see a few hundreds of lines in logs.

In the front-end development I like the dot notation usually used for unit tests. Dot notation is cool because it’s clear and you can identify skipped and failed tests easily. Such feature useful when you have over 500 tests in your project. But in Dart, there is no such thing, only default and machine reporter.

What to do?

Short

Here is a tool, I’ve created: dart_dot_reporter which makes report readable.

Long

dart_dot_reporter tool transforms machine results to the more readable and clear output. And here is an example:

If you are not familiar with Dot notation

. Dot for passed test
! Warning that test was skipped
X for Failed test

The summary line of icons will be displayed at the start of the report. And in case of skip or failure, it will display the name of the test after the icon on the new line.

I implemented a few features out of the box. If you want - you can:

hide skipped tests
show successful tests
append few error details after test name in case of error
display id number of the test (which is like the order number)
disable color

Also, later I plan to display top of tests which execution took too much time.

Alternative

In some cases, you can find a JUnit report also useful. junit
But in my case, I wanted to have a possibility to understand which test failed from logs or email/slack message with a fast look on the report.

Finally

And you can see the example of that tool usage here in “Run tests” section. Because I use dart_dot_reporter on CI for itself with GitHub actions, which I found useful for personal projects.

If you find some issues - write me a note or create a bug on GitHub.

How to manage Technical Debt

Aleksey Pastuhov — Wed, 14 Nov 2018 06:04:19 +0000

Originally posted on my blog apastuhov.com.

Today more people think about technical debt than 5 years ago. Because every project has a debt, but not everyone drives it. And even if they drive - they will just keep a snowball in most cases.

I want to share how I prefer to manage technical debt and what it gives to me in a result.

Definition and the problem

What Wikipedia tells us:

Technical debt (also known as design debt or code debt) is a concept in software development that reflects the implied cost of additional rework caused by choosing an easy solution now instead of using a better approach that would take longer.

If technical debt is not repaid, it can accumulate ‘interest’, making it harder to implement changes later on. Unaddressed technical debt increases software entropy.

In easy words, technical debt means a list of invalid solutions, which you or your team made by mistake. Do not forget - everyone can be wrong. So if you do not manage your debt - you will get the next list of problems.

Demotivated team
Have no ability to control project risks
Increased software entropy
Everyone would like to rewrite the whole project from scratch

Causes

List of causes can be very big, but I defined the most popular from my point of view.

Requirements are still being defined during development
Development starts before any design takes place
Business pressure
Lack of process or knowledge
Last minute specification changes
Poor technological leadership
Lack of collaboration
Outdated technologies
Bad development practices

You noted that most of those causes related to a business or a client. And this is true - in most cases, technical debt is filled-up in collaboration with your manager. You should hear the next phrase.

Do it now because we really need.

And then you come to some compromise via increasing of your technical debt.

Disclaimer: At the end of the article you will find a link to the full list of root causes.

Technical debt and PoC

If you work on a Proof of Concept, do not worry about technical debt. Because someone will replace PoC with the more stable solution. The issue that everyone on a project should be on a same page.

Column	Value
Number	13
Issue	Outdated README file
Cause	After creation of landing page, there were changes in a folder structure
Solution	Update the file
How to prevent?	Update the README file right with changes in structure in the same Pull Request
Initiated	21
Solved	25
Status	DONE
Assignee	Aleksey Pastuhov

Summary

Remember that you should monitor your debt iteratively, and take tasks into your sprints to get things done.

This is how I prefer to keep and manage technical debt. If you do right, you will have positive results:

A motivated team
You will be able to control technical risks
If there are no requirements or design - you have a lot of stuff to do
And you will be able to debate to your manager or a client that you need a sprint for code stabilization

Share your feedback and let me know how you used to manage technical debt.
Send me a message or tweet!

P.S.: Do not forget about prioritization! Just add “Priority” column, if it's required in your case.

Originally posted on my blog apastuhov.com.

Useful links

What makes it a good product

Aleksey Pastuhov — Mon, 21 May 2018 21:13:40 +0000

Originally posted on my blog.

A few weeks ago one colleague asked me a question - "What makes it a product good?". I am not a product manager but it seems to be an interesting question. As a developer, I know how applications are created and what problems they face.

From my point of view, it is impossible to create an ideal product. At least I haven't seen one. But let's define criteria and understand how to improve products even if they are not good enough.

Here is a short list:

Problem-solving
Recognition
No bugs
Stablity (not the same as a previous one)
Transparency
Predictability
Support provision
Activity

And much more. The more we think about it - more points we will identify. So let's stop to review everything step by step.

Problem-solving

First, a product should solve a problem. It should make your life easier, better! If product creates a problem and later solves it - I would say it is just a business to earn more money.

To be on the same page, let's take examples of every bullet point.

Bad: dad wants to read and edit notes on every device he has (laptop, PC, phone, tablet). So he finds an application, but here is a limitation to the number of devices. Dad was asked to pay an extra $5 just to keep data offline on his personal storage.

Good: a photographer has a problem with a big amount of photos and he needs to keep them somewhere. Here he meets cloud storages, which is great for storing big files.

Recognition

It does not matter how fancy User Interface or Artificial Intelligence under the hood you have. If no one knows about your application - nothing makes sense. I do not want to say you should ignore user's needs and not implement features, but do not forget to build a brand on the top of your product.

Bad: Look at the castle in the mountain without a road. There you can find tons of gold in that castle, but you have no clue how to get there. People do not know what they don't know.

Good: Google Keep for example - small and simple application has not so many features. But every Google user at least heard about it.

Good #2: If you need (or want) to get a good Git client with simple and fancy UI - you will find GitKraken. You may find it in some comparisons, articles. But after a research with Google you may see targeting advertisement about GitKraken.

No bugs

It can be mystical to someone, but I can say - it is possible to write a code without bugs. On the other hand, an application may have some logical bugs created by ideas or changes. You can find those bugs in time and in a specific use-case.

Continue reading the article and you will find an example on how to live with bugs. I do not want to copy-paste. :)

Stablity

Downtime, that is when you have a chance to disappoint your user. Even if we are talking about Google, GitHub, etc.. When your application fails - someone will joke in a manner "Did you see it?".

Bad: an app failed, not a single user has an idea why it happened and when it would work again, so they switch to another, more stable application.

Good: an app failed, and the user got an email with notification of the issue. Also, he can access a link and preview the status and progress. Just have a look at Bitbucket status page: https://status.bitbucket.org/.

Transparency

Every action should be clear to the user, he should understand all consequences. After pressing Save - display the notification about its results. Every icon should have a title with short (even 1 word is enough) description to display it on hover.

Bad: User paid for something, found out that money was charged, but he got no notification on the email/phone/any messenger. As a result - user feels robbed.

Good: After paying for a GitHub account - you get the notification on email, also you can review the history of all payments.

Predictability

When a user does something, he should be able to predict how it will work (save/delete/create).

Bad: I finished the article in one application, let's call it "Writer". But when I opened the article in the afternoon - I found out that a half of the article wasn't saved. But I expected the application to save my file.

Bad 2: The same was with one of the biggest cloud data storages. In 2-3 days after uploading a file, I found it was corrupted by a service so I could not delete/change/download the file.

There were examples of bad user flow or bugs I found. For good, I would say the app should do what users expect and do not fail on primary use-cases.

Good: When you want to change your email - it is inside of an area which is marked as dangerous. Also, you see a message informing you "Changing email may corrupt integrations with 3rd-party systems". And to change email you need to verify that they both are valid.

Support provision

Okay, let's return back to our bugs, how to live with them. A user should be able to get support and find an answer to his question. Even if it is a link to the documentation, forum or FAQ. Better than nothing.

Bad: I was trying to understand how to use one task management application, but there was no answer, help, introduction, link to any tutorial, nothing. As a result - I deleted the app.

Good: something went wrong. You see a pop-up which gives you an ability to contact developers, and you are sure that the issue will be fixed soon. Also, you get links to FAQ, useful status pages, etc.

Activity

Product evolving is amazing, but it's like balancing on a rope. On one side an application can be transformed into a piece of shit, due to requested changes from users. On the other side, we ignore users needs. As a result, everybody is disappointed.

Bad: Say “yes” to all feature requests users make:

Good: think about user's requests, analyze them, give a feedback, add new features without breaking the core idea.

Summary

Here I described my thoughts on how to improve the application, what makes it a good product. How to make users hate you. There are a lot of metrics, approaches to make something better, do not forget about it!

As soon as we are on the same page, let's define some "mark" to analyze your project. Sum the numbers and write in a comment.

[3] Problem-solving - Does your product make a life of the user easier?
[2] Recognition - How many people at least heard about your product?
[2] No bugs - What is the percentage of Open/Closed bugs? < 15% is ok
[2] Stable - When was the last crash in production?
[3] Transparency - Does your product fit GDPR requirements?
[2] Predictability - How many users' "bugs" you close as a "feature is not a bug"?
[2] Support provision - Can you share FAQ/Forum/Bug Report System?
[3] Activity - How often do you release to production?

Grade from 0 to 18:

0-8 - App is not good enough, there is a lot of stuff to improve.
8-14 - Product is good enough, maybe you have some clients.
14-18 - Totally great! Just a few steps to shine like a star. :)

Thanks for reading! Share your thoughts.

Note-taking software - Investigation

Aleksey Pastuhov — Tue, 28 Nov 2017 22:08:05 +0000

Originally published on my blog: apastuhov.com

As any other person, who would read that article - I wanted to structure my minds. And the best way to do it - writing notes! Somebody prefers to use a simple notebook with paper and a pen, but I am a software developer and most of my time I spend near my notebook/PC/mobile-phone, also I am not so good in writing by hand. :)

I use notes several years in a row, and I tried different applications to simplify the process. So I want to share my experience about note taking applications and offer some recommendations if you are looking for the best app for your needs.

And I want to warn you that it is my subjective opinion, and all thoughts are based on my personal needs.

Criteria definition

Here I want to describe criteria which I choose to define the best note-taking application.

Offline access - I like to travel, and most of all I prefer to write a text in a train, there is no internet access and no way to connect to remote.
Offline access from mobile - I separated that point from the previous one because some applications have offline access, but their mobile version is online-only.
Cross-platform - There are 3 different platforms I use every day: Android, Linux, and Windows. And I need to have a good cross-platform app with stable data synchronization.
Supports markdown - It is the best markup language with plain text formatting syntax!
Supports tables and keep images - Some markdown engines do not work with tables or images, actually, it is strange for me, because there is a specification what basic features markdown has.
Supports basic folder structure (at least 1-level depth) - In time I found that I need to group notes by folders(groups), and tags don't work here.
User-Friendly interface - UI should be clear, understandable, without any overhead and useless buttons/functions.

Nice to have:

Encrypt the data - Privacy is good, but I do not keep passwords or some valuable data in my notes, so it is not too critical for me.
FOSS - It would be great to contribute and improve the application.
Math support (LaTeX as example) - Just because I need it sometimes. ;)

Google Keep

There are a big amount of people who like it, but when I started to use it I found that interface is not so friendly and structured as I expected. It feels a bit chaotic for me. I disliked that panels where font size depends on the amount you wrote on the card.

Dropbox Paper

It is new enough and there was a time when it became too popular in one moment. I want to note that it has the GREAT editor, writing in Dropbox Paper is something I really like, for me, this was the best writing app.

Until I found that navigation between files really awful. It is unable to move to file B while you are editing file A.

Also home page.. - it shows the advertisement for me to connect a Slack (but I do not have any Slack connection on my personal email). I dismissed it but in time - I get the ad back again. And home page shows only Recent viewed files, but wait I have a structured data and I am not wondering about "the latest one". So to open a file in some directory I need to make 3 or 4 clicks and wait for page reloading for several times.

But still - the editor is good.

One Note

Microsoft has a good alternative to most note-taking apps. It has a big amount of hotkeys. And I used it for a long time, but it is good only on windows and mobile platforms. As most of the developers - I have Linux system on my work, and Web version of OneNote is too sloooow. So I cannot say that it is really cross-platform. But if you use only Windows as your main platform - One Note is a good app to use.

P.S.: I like that OneNote UI is organized as a simple notebook with colored bookmarks.

Evernote

Too complex, and too many features that I do not need also it needs money to support more than 2 devices. If payment is not a problem.. I still do not need next features in the Note-taking app:

Reminders
Different fonts families, sizes, colors in one note
Sharing on LinkedIn/Twitter/Facebook/Email etc.. (really who shares notes on facebook or twitter?))
Work chat... okay, but I need personal notes
Note from calendar
Note presentation
Search in PDF? nope.

SimpleNote

For a long time, I was a big fan of SimpleNote. It is a good application for taking notes, which supports markdown and great offline access. But time changes and I got new requirements to group some notes, keep images and tables. And here I found that SimpleNote has next issues:

No folder structure
No internal image or tables in the markdown files
Web and Desktop views has not user-friendly Markdown / Preview switcher

Turtl

Nice and minimal application, but I do not know.. UI and UX a bit awkward for me, also I do not like panels. And I did not find application user-friendly when you have 20 notes in one group. It has same problems as Google Keep.

Standard Notes

Oh.. there was a moment when the app made a wow-effect. First of all - it is built by one person. That man is an example to follow. Second - it has good UX + UI and it is open-sourced. But it requires a big amount of money for such primitive feature as markdown. And I am not sure that it will work as I expect.

And from my side - my drafts has several tags and group notes by tags are not something I need.

Laverna

I give several chances to that app.. but every time I tried it - I had some problems with connection, login via Dropbox and so on, so web version is good, but desktop did not work for me.

No single app

When I reviewed a big amount of popular note-taking applications - I found that all of them have some issues. And I started to look at some applications which allows you to keep your notes on your personal storage(Dropbox, GDrive, custom server), and mobile devices will just connect to that storage, download, update the data and upload it back. At least on a desktop, you can use any editor you want.

I tried a big amount of them, I even paid money for some mobile applications, but they failed, all of those:

and more ...

And even more, but I do not want to spam with screenshots. :)

Some of them are useless, some are buggy, offline only, etc. So this is a fail.

Personal application

There was a moment when I decided to create my personal app to take notes, but in time and I started to work on several projects at the same time, so that project is frozen. But it did the basic part I need.

Boostnote

And the last, but not least, application. I found it a few weeks ago and.. it totally fits my vision of the best note-taking application!!! It does not track any private data. You can choose any data storage you want. It has pretty design, and the repository is alive, every new version is better than previous one. Also, you can fork it or contribute to OpenSource. But also it has some issues. Mobile app(at least Android version) is useless, but as soon as it is open-source - anyone can contribute or create his own vision of mobile app to make it better.

Comparison Table

Empty - Does not support/work out of the box
+ - Supports/work
? - Not sure

	Google Keep	Dropbox Paper	One Note	Evernote	Simple Note	Turtl	Standard Notes	Laverna	Boostnote
Offline desktop access	+		+		+	+	+	+	+
Offline mobile access	+	+	+	+	+	+	+
Cross-platofrm	+	+		+	+	+	+	+	+
Markdown		+		+	+	+		+	+
Tables		+	+	+		+		+	+
Attach Images	+	+	+	+				+	+
Folder Structure		+	+	+		+		+	+
UI			+		+		+	+	+
Security	?	?	?	?	?	+	+	+
FOSS						+	+	+	+
Math		+	+			+			+
Stable	+		+	+	+	+	+		+

Make a choice based on your personal requirements!

Summary

I found that most note-taking applications in time decided to change their vision from "make for people" to "make for teams and companies". And it makes me sad. Everything is moving from B2C to B2B and it may be good for business, but not always good for end users.

If you do not agree with my vision, but still looking for the best app for your needs, here is a list of links with good descriptions, criteria, and votes which helped me to write that article.

And do not forget to tell in comments: What note-taking app are you using?

Update:

Here is a list of other apps which are not listed in that article, but they may be interesting for you.

iaWriter - Mobile application is really good, but PC version is available only for Mac. Anyway it has stable synchonization with Dropbox or GDrive and offline mobile mode, so it can be used with any text editor on your desktop.
Typora - Good enough and feature reach, but has no mobile app.
WizNote - application from Chinna
Monospace - Good mobile editor, but GDrive sync (Pro feature) did not worked for me.

Currently, I am using Boostnote, it is not the best, but at least it is better than most of the apps. But also a good point to think about - is to use iaWriter with simple desktop Dropbox sync and custom text editor.

And do not forget to tell in comments: What note-taking app are you using?

Update 2:

For Apple(iOS and Mac) users here is another list:

Bear - Several guys recomended it, so it should be on top of that list :)
Quiver - Seems to be a briliant app for programmers
Apple Notes - Default Apple notes

Non typical way to organize and keep your notes:

Workflowy - Non standard way to organize your notes! Notebook for lists :)
Dynalist - Looks similar to previous one
Zim Wiki
Tiddly Wiki
Scrapbox

Another finding is next application:

Joplin - Has terminal client - but I did not test it!

Also, most from DevTo community using GIT to keep and sync up personal notes. Here is a short description how to do it:

Use GitHub/GitLab/BitBucket/etc to keep the repository with notes
Use any desktop text editor: Vim, Emacs, VSCode, SublimeText, Notepad, etc and GIT
Use some mobile application to clone the repository, edit and then sync the data. For Android I tried Pocket Git and MGit and they worked as I expected.

That approach is interesting enough and can be a good choice for developers!

Originally published on my blog: apastuhov.com

Subscribe to read more articles!

Evolution of Interaction

Aleksey Pastuhov — Thu, 09 Nov 2017 19:36:08 +0000

Originaly published on my blog apastuhov.com

If you write frontend application - I assume that it interacts with backend API server. If your app is small - you do not think about architecture and scaling. But if it is a big LTS application - you need to think about it! Why? Because You will develop and support that application in future, so just pray that you wont hate yourself in time. I want to tell you how people often develop an interaction between UI and API.

To be on the same page, lets define that Interaction - is an object/class/method/function that allows you to send requests to a backend server.

No silver bullet or Types of architecture

You can try to search some solution! And you may find some guidelines or libraries, also it may be a part of a framework you use, like angular.$resource. In general, there will be 4 types of Interaction architecture.

On-flight
Factory
Singleton
"Micro" services

So you will find that there is no silver bullet, which will be the best or the most popular.

I do not want to describe the implementation of every approach because it is your job. :) I want to show how you will use it, pros and cons.

On-flight or jQuery style

I suppose you remember how popular jQuery was, maybe it is still the best tool for somebody. jQuery provided us a big amount of good things, one of them - is a short notation of the AJAX. No XmlHttpRequest more, just simple $.ajax.

So the first style - is to write an AJAX query immediately when you need it.

jQuery.ajax.get(
  'http://super-app.com/api/client',
  {
    success: function(data) {
      client = data;
    },
    error: function() {
      console.error('blah blah blah');
    }
  }
);

I do not want even to discuss why that way is bad. If you will try to write SPA in a such way - you may find that all your requests are scattered by your application. And if you will make a small error - you will find it, only when user will do the action to run that query.

And as always - one day someone would say "We need some time for refactoring".

Factory

Now we have a configuration of all our requests, and you create them dynamically when you need. For example resource in angular 1.x, someone may say that example is not good, but I want to note that implementation may vary. The idea of the factory - generate objects (requests in our case) dynamically depending on some configuration.

Lets imagine two most popular interfaces with configuration:

request.setup({
  host: 'http://super-app.com/api/'
});

Usage #1:

request(
  'GET',
  'client',
  function(data) {
    clientData = data;
  },
  function() {
    console.error('error handler');
  }
);

Usage #2:

var client = request('client');
client.get(
  function(data) {
    clientData = data;
  },
  function() {
    console.error('error handler');
  }
);

Singleton

Singleton - is the most popular pattern in software development. So we have a single class to keep all requests and configurations.

api.getProjectList();
api.getProjectById(1);
api.updateClient(instance);
api.deleteUser(1);
// ... and so on

The approach is not so bad, but api.js will grow in time. So it becomes really hard to change and to add new queries. Gritting one's teeth you will add new methods to the file, and one day you will decide that you need to split it.

I assume that your architecture will be next:

-/ api
 |- client.js
 |- project.js
 |- user.js
  \ api.js

And usage will be changed to the next one:

api.project.getList();
api.project.getById(1);
api.client.update(instance);
api.user.delete(1);
// ... and so on

It looks nice and understandable, but there is one small problem - separation of contests. So working with project API - you have an access to client API and you can remove it, instead of a project. That is why you need to isolate classes.

"Micro" services

No, wait! I do not want to talk about some big changes to split everything. I just want to note that every such file as ./app/api/client.js is a service. And we do not need that singleton to keep the composition of all that services.

projectApi.getList();
projectApi.getById(1);
clientApi.update(instance);
userApi.delete(1);
// ... and so on

It seems that last solution is ideal. But the more services you have - the more imports and dependencies you need. Some can say that you need to separate by logic and make some groups of services. But it is a long way to discuss.

Summary

Every solution has pros and cons, and only you can define what is relevant for you.

I told you how to develop an interaction between UI and API. And I hope you defined what approach is the best for you! Write your comment and let me know!

P.S.:

I want to mention that the more you write - the more you repeat yourself and others. Who knows, maybe we will return to simple jQuery style one day. :)

Dead code problem

Aleksey Pastuhov — Sat, 04 Nov 2017 00:42:03 +0000

Originally published at apastuhov.com on November 3, 2017

You work with the big code base and your project has hundreds or even thousands of files? I assume that you have dead code in your project. I want to tell you about the problem of dead code and how we can deal with it. But first, let's define what code can be called dead.

Dead code definition

Dead code is any code which will never be executed. It may be some condition, loop or any file which was simply created but wasn't used in your project.

Why is it a problem?

It is a problem because that code has no sense! You can drop it and everything will work as well. I want to mention base problems of dead code:

A newcomer will read it, and he/she would try to understand that code, or even use it.
It takes some space in your repository and working directory.
It would be interpolated by your IDE, so it will eat more memory than it needs.

And here is what will happen with your project if you have dead code.

Why is it a problem of JavaScript?

JavaScript is a very active programming language. There are billions of applications and plugins developers create every day. For example, NPM (package manager for Node JS applications) has more than 450 000 packages, see modulecounts! It is more than 1 TeraByte of code! I assume that one package has 2MB size. And I am sure that more than 25% of it - is a dead code... which is used by nobody.

You do not work with NodeJS? Are you front end developer? Good! I assume that your client changes his mind. :) And you will develop all the features he wants. But you will do it in a hurry, so you will not have any time to fix old code, or even drop it.

Any existing solutions

If you Google it, you would find that everybody uses Google Closure, or WebPack. But I insist that it is not a real solution to the problem. That tools will just remove dead code for public scripts. But they do not tell you what code you should remove.

Solutions in other programming languages

Let's look at some other popular languages:

Python - vulture
C, C++, C#, TCL - coco
Java - proguard

No comments.. JavaScript is an outsider.

What is an ideal solution

Heh.. we saw that there are some analogs for other languages. So let's imagine some ideal solution for JavaScript. It must detect:

Unreachable code
Oxbow code
Dead store
Dead files

Unreachable code

Permanent return statement.

function temp() {
    return 1;
    var a = 2; // Dead Code
}

Needless conditions.

function temp() {
    var a = 2;
    if (a > 3) {
         return 3; // Dead Code
    }
}

Needless loops.

function temp() {

    var a = 2;

    while (false) {

         return 3; // Dead Code

    }

}

Oxbow code

function temp() {

    // ...

    function private_calculation() {

        return 22;

    }

    // ...

    this.calc = function () {

        // Previously private_calculation was called here...

        return 22;

    }

    // ...

}

Dead store

function func(a, b) {

    var x;

    var i = 300;

    while (i--) {

        x = a + b; // Dead store

    }

}

Dead files

Just imagine that you have some file with code, but that file isn't used at all in your project: no import, no <script src="..."> link to that file.

Summary

Here I told you about JavaScript problem of dead code and how we can deal with it. For now, there is no solution which will tell us what code can be safely removed.

Write here your opinion - What features must have a tool for dead code? And I will update current post!

Update (Sep 2017)

Starting from version 59 of Chrome you can test your code usage coverage with dev-tools.

https://developers.google.com/web/updates/2017/04/devtools-release-notes#coverage

It is really good tool to define old/outdated/dead code, but it has one big issue:

It tells you how much code was used, versus how much was loaded.

To define unused code - you need to go through all features on your website via clicking on all the buttons on your UI.

Forem: Aleksey Pastuhov

Make Dart/Flutter test report readable

Intro

Short

Long

What to do?

Short

Long

Alternative

Finally

How to manage Technical Debt

Definition and the problem

Causes

Technical debt and PoC

Popular solution

More precise solution

Issue - Cause - Solution - Prevention

Initiated vs Solved

Status and Assignee

Example of an item

Summary

Useful links

What makes it a good product

Problem-solving

Recognition

No bugs

Stablity

Transparency

Predictability

Support provision

Activity

Summary

Note-taking software - Investigation

Criteria definition

No single app

Personal application

Comparison Table

Summary

Update:

Update 2:

Evolution of Interaction

No silver bullet or Types of architecture

On-flight or jQuery style

Factory

Singleton

"Micro" services

Summary

Dead code problem

Dead code definition

Why is it a problem?

Why is it a problem of JavaScript?

Any existing solutions

Solutions in other programming languages

What is an ideal solution

Unreachable code

Oxbow code

Dead store

Dead files

Summary

Update (Sep 2017)