Updated and expanded version of DriverPack Online - the first in importance, 16 by number
When you support hundreds of office and home PCs, you can’t do without a set of universal drivers. Without a doubt, the most popular solution here is DriverPack Full, which has a huge driver base, 10 Gb in size! These are as many as 910,000 drivers assembled and tested manually.
If you need to configure only 1 computer, then you do not want to download 10 Gb at all, so DriverPack Online was made. He had his flaws, which we tried to fix in a new release. So let’s dwell in more detail on the most interesting development points.
It was decided to rewrite and reverse engineer DriverPack Online from scratch. Our goal was to make an easy and simple application that provides the user with the functionality of the Full version.
We used the same technology stack . I know that there are people who do not like HTA. But, friends, this works the way our users need.
Any admin who at least once wrote VBScript scripts or riveted a “business card site” can easily file DriverPack for himself without any problems. No compilation, just HTML and JavaScript, which even a student will understand.
And yes, we experimented with node-webkit - it did not suit us.
There are many standard solutions on the web, and we were able to transfer them to Desktop. Using the Statistics.js script, events are sent from the application to Google Analytics and Yandex.Metrica.
Statistics.js can:
The syntax for sending events is quite simple: Thanks to this, we can analyze problems, find failed or incompatible drivers and configurations even before users write about it ... And in the end, we need to understand how convenient and understandable the product is to the user. Here's what the map of events sent from DriverPack looks like:
In Google Analytics, external events are sent via the Measurement Protocol protocol, so its integration did not cause problems. But, we went further and learned how to throw ClientID from the site, right into the application! This is necessary so that you can understand where the user originally came from and by what search phrase and associate this with what he is doing inside the application.
From the site to the ClientID application, it is forwarded through the file name, like this: We can tell in detail about how easy it is to configure it, but in another post, if anyone is interested.
Google Analytics is good, but two tools are better, so I turned to Metrica. The huge minus of Google Analytics is the “sampling” that is enabled for resources with high traffic. It beats data very hard and you can’t believe such statistics anymore. Yandex.Metrica helps us verify / confirm the conclusions made on data from Google Analytics.
I had to tinker with Metric, as they don’t have any REST API for sending events. But, we were able to make friends with regular JavaScript tracking code with HTA.
By sending events about user actions (hits) to the "Metric", we also send a JSON object containing information about the configuration of the computer.
The Metrics interface allows you to work with this data and find very interesting insiders: below is a screen with failure indicators for using our application on computers of users of two groups: with a RAM capacity of 1 Gb or more than 2 Gb.
From this diagram it can be concluded that users of computers with 1 Gb of RAM on board have a 1.5 times higher failure rate than users of computers with more memory. This is a fairly simple conclusion, but sometimes there are really super unobvious things.
HTA - runs on the Internet Explorer engine, so DriverPack should work correctly in completely different environments and run on different engines. If we neglect the impossible combinations of the form “Window 8.1 x IE6” , we can say that the number of options is the Cartesian product [Windows ver] x [IE ver] - this is a lot, not to mention what happens to the antivirus zoo on users' computers.
To
test all this, we: 1. Raise a series of virtual machines;
2. The latest version of the application is deployed through Dropbox;
3. Unit tests are launched every minute through the scheduler;
4. Reports from machines are collected in one Dropbox folder.
Thus, we significantly reduced the cost of the testing process.
We cover the application code with auto tests. But testing 910,000 drivers on virtual machines is not possible. Therefore, we created the "Remote Driver Testing Laboratory" , which was described on Habré.
All this in a new, in our opinion, minimalistic design.
Download DriverPack Online: http://drp.su/en/
Page on GitHub: https://github.com/DriverPackSolution/DriverPack-Solution/tree/DriverPack-16
Change Log: https://github.com/DriverPackSolution/ DriverPack-Solution / commits / DriverPack-16? Page = 1
PS Thanks to those who responded to one of our previous publications.
You really helped us improve DriverPack a bit: make it fast and reliable, and at the same time simple and understandable for any user. Special
thanks to Denis Sedchenko for the design of the application.
If you need to configure only 1 computer, then you do not want to download 10 Gb at all, so DriverPack Online was made. He had his flaws, which we tried to fix in a new release. So let’s dwell in more detail on the most interesting development points.
From scratch
It was decided to rewrite and reverse engineer DriverPack Online from scratch. Our goal was to make an easy and simple application that provides the user with the functionality of the Full version.
We used the same technology stack . I know that there are people who do not like HTA. But, friends, this works the way our users need.
Any admin who at least once wrote VBScript scripts or riveted a “business card site” can easily file DriverPack for himself without any problems. No compilation, just HTML and JavaScript, which even a student will understand.
And yes, we experimented with node-webkit - it did not suit us.
Analytics
There are many standard solutions on the web, and we were able to transfer them to Desktop. Using the Statistics.js script, events are sent from the application to Google Analytics and Yandex.Metrica.
Statistics.js can:
- Work with sending Events to GA (category, action, label);
- Supports Dimensions (settings in statistics.config);
- Probros ClientID from the site;
- Generation ClientID if it has not forwarded;
- Generate the correct URL to send via Measurement Protocol;
- Sending events to Yandex.Metrica (via yaCounter.hit ()).
The syntax for sending events is quite simple: Thanks to this, we can analyze problems, find failed or incompatible drivers and configurations even before users write about it ... And in the end, we need to understand how convenient and understandable the product is to the user. Here's what the map of events sent from DriverPack looks like:
statistics.event(
{
category: 'desktop',
action: 'opened',
label: '16.1.1'
}
);
Google Analytics and ClientID
In Google Analytics, external events are sent via the Measurement Protocol protocol, so its integration did not cause problems. But, we went further and learned how to throw ClientID from the site, right into the application! This is necessary so that you can understand where the user originally came from and by what search phrase and associate this with what he is doing inside the application.
From the site to the ClientID application, it is forwarded through the file name, like this: We can tell in detail about how easy it is to configure it, but in another post, if anyone is interested.
download.drp.su/online/DriverPack-Online_2089238336.1403776545.exe
Yandex.Metrica
Google Analytics is good, but two tools are better, so I turned to Metrica. The huge minus of Google Analytics is the “sampling” that is enabled for resources with high traffic. It beats data very hard and you can’t believe such statistics anymore. Yandex.Metrica helps us verify / confirm the conclusions made on data from Google Analytics.
I had to tinker with Metric, as they don’t have any REST API for sending events. But, we were able to make friends with regular JavaScript tracking code with HTA.
By sending events about user actions (hits) to the "Metric", we also send a JSON object containing information about the configuration of the computer.
The Metrics interface allows you to work with this data and find very interesting insiders: below is a screen with failure indicators for using our application on computers of users of two groups: with a RAM capacity of 1 Gb or more than 2 Gb.
From this diagram it can be concluded that users of computers with 1 Gb of RAM on board have a 1.5 times higher failure rate than users of computers with more memory. This is a fairly simple conclusion, but sometimes there are really super unobvious things.
Auto tests
HTA - runs on the Internet Explorer engine, so DriverPack should work correctly in completely different environments and run on different engines. If we neglect the impossible combinations of the form “Window 8.1 x IE6” , we can say that the number of options is the Cartesian product [Windows ver] x [IE ver] - this is a lot, not to mention what happens to the antivirus zoo on users' computers.
To
test all this, we: 1. Raise a series of virtual machines;
2. The latest version of the application is deployed through Dropbox;
3. Unit tests are launched every minute through the scheduler;
4. Reports from machines are collected in one Dropbox folder.
Thus, we significantly reduced the cost of the testing process.
Driver testing
We cover the application code with auto tests. But testing 910,000 drivers on virtual machines is not possible. Therefore, we created the "Remote Driver Testing Laboratory" , which was described on Habré.
All this in a new, in our opinion, minimalistic design.
In the end
Download DriverPack Online: http://drp.su/en/
Page on GitHub: https://github.com/DriverPackSolution/DriverPack-Solution/tree/DriverPack-16
Change Log: https://github.com/DriverPackSolution/ DriverPack-Solution / commits / DriverPack-16? Page = 1
Changelog of the new version, carefully!
PS Thanks to those who responded to one of our previous publications.
You really helped us improve DriverPack a bit: make it fast and reliable, and at the same time simple and understandable for any user. Special
thanks to Denis Sedchenko for the design of the application.
Only registered users can participate in the survey. Please come in.
Has DriverPack Solution Online interface improved in your opinion?
- 67.8% Yes 211
- 11.5% No 36
- 20.5% I do not see significant changes 64