November 11 2017, 18:19

“Me and my shoulder buddy.” View from above of Morskie Oko. Route (incomplete) here:

(add another 3.5 km) Nikolay Iakovlev

November 11 2017, 09:54

If last time was an introductory walk, today I chose a challenging trail. Blizzard, snowdrifts, elevation change – 1000 meters (reached 1800m), time spent on a loop trail around three lakes – 8 hours. Some sections were genuinely tough, taking about five minutes to get past ten difficult meters. They are easier in the summer. Wildly happy:) loads more photos, some really cool ones, but it could have been better: the weather wasn’t sunny, with blizzard and snowfall.

November 10 2017, 13:22

I noticed something interesting while on a business trip. Here, my alarm is set for seven in the morning every day (though tomorrow it will be at five, actually). Quite often, around five minutes before or so, I wake up by myself, right before the alarm. And I wake up on the first try. It doesn’t matter what time I go to sleep, even if it’s just 5 hours before. Yesterday, I woke up to the alarm, but noticed that my dream logically concluded right at the alarm time. Apparently, somewhere deep in the head, the “biological clock” ticks with quite high precision, adjusting every time I look at the clock. And when I go to sleep intending to wake up at seven, somewhere in the sleep, the brain evaluates how much time is left until seven and tries to get enough sleep in that time, or even show me a dream. I wonder if there were experiments where people went to sleep intending to wake up at seven, but their alarms were secretly set for later?

I watched the first part of Simon Shnoll’s lecture on biological clocks – but it’s not about what I’m writing above, it’s just the same term. But the lecture is interesting,

November 07 2017, 14:35

Today, I did something I’m proud of (it always happens when you dabble a bit in something that’s not quite your field, and it works out).

In my project, there are currently about a thousand content pages, hundreds of functional components, many of which are used on many pages, with either unique or common configurations. The client updates both the components’ configurations and their composition on the pages, and as often happens with such volumes, fixing something in one place breaks something in another. And the task is to keep all this under control.

What I did: On my server, a graphic snapshot is created for all pages of the site – a set of images with a complete copy of the page at the moment the snapshot is taken. Each picture is stored in folders corresponding to the language, country, site, and hierarchical categories. All are available on the web. Graphic copies of individual page components are stored in a similar manner. Every day. There is a mechanism to visualize changes. Of course, when changes appear where they were not expected, it is both good and bad. Bad, because it means someone did something wrong, and good because it was detected early.

I can’t show anything; it’s a commercial project.

Technologies: python, selenium, chromedriver, imagemagick.

November 05 2017, 07:14

An interesting task has arisen. In the Hybris admin panel, there is no way to record all administrator actions so that later, if something happens, we can understand who messed up. Some objects keep their change history and there is a reference to the data changer, but various operations leave at best entries in the log, but never with a reference to a specific administrator.

Analyzing server logs is also futile because admin panels are now built on Single Page Application.

I’ve come up with an idea of how to implement such logging for any system, not just Hybris. I am trying to find such a ready-made tool, but have not succeeded yet. It’s relatively easy to make. If you understand Chrome extensions, we could try to make a PoC together.

The idea is as follows:

1. The administrator logs into the site’s admin panel (not necessarily Hybris).

2. A Chrome extension understands that the opened site is from the list for operation logging and switches to work mode.

3. At certain events, like “data input in a form,” “clicking on an element,” the system performs the operation logging and sends the results to the server. Namely:

a) takes a screenshot of the screen and highlights the area where the element is located (or the entire screen if it’s easier, for starters).

b) adds additional metadata to the screenshot, if able to extract it (for example, for a textarea – the text entered)

c) adds the operator ID.

d) puts the screenshot with metadata in a queue for sending.

e) gradually processes the queue by sending the screenshots to the server

On the server, the screenshots fall into a FIFO stack, accessible for analysis by a super admin if a problem arises.

I see the following disadvantages:

1. Unclear how to implement drag-n-drop, for example. Also unclear how to determine if a user has filled out a form (just entered something and left the textarea—should a screenshot be sent in this case? idk)

2. Not always easy to enrich screenshots with metadata. For example, an onClick handler might be on an empty div while another div may contain the active element with data.

3. A lot of attention to system security

4. Possible system slowdown due to constant screenshot uploads. If actively clicking in the admin panel, outgoing traffic could be about 1Mb/sec. Potentially could cause slowdowns. But still, this is not a very big problem.

If there are experts in Chrome Extensions – welcome. Maybe, we can sketch a PoC together?

P.S. In the comments, they ask why not analyze the requests. Here’s why: