TomasHuk

Эмм..

for item in your_list:
    print(item['id'], item['username'])

ilyakhaustov, ну тогда и я повыделываюсь)

print('\n'.join('%s %s' % (item['id'], item['username']) for item in your_list))

Представьте что нет никакой ложки докера.

1) Есть одна физическая машина. Вы устанвливаете софт, разные приложухи, базы, web сервера, заходят тестовые юзеры, что-то запускают. Первая проблема - вы не понимаете кому что надо, кто владелец файлов, приложух, зачем висят демоны и кто за это ответственнен. Как выход, вы решаете это разделить на виртуалки.

2) У вас есть физическая машина + на ней виртуалки. Вы выделяете под каждую задачу свою виртуалку, там сидят отдельные пользователи, вы навели какой то порядок. Появляется задача - пользователи хотят php 6, а его нет, хотят python3, а его нет, хотят Mongo, а она старой версии. Вы обновляете репозитарии, качаете новые пакеты, ставите, часть пользователей довольны, часть нет - им нужна старая версия какая была. Упс!

3) Одна физическая машина + еще больше виртуальных машин. Вы разделили всех пользователей так, чтобы никто не дрался за версии софта, если нужен php6 - иди на эту машину, нужен php5 - вот на эту. Все счастливы, но появляются разработчики, которые говорят буквально так - "а у меня на рабочей машине все работает, я перенес все как было на виртуалку, а у меня появляется ошибка missing library libXXX.so.X". И вы понимаете что вам остается только создать полную копию машины разработчика, чтобы софт поехал на этой виртуалке без ошибок... И тут появляется Docker! :)

4) Docker решает именно эту проблему. Вам не нужно заботится о софте который установлен на сервере/виртуалке. Вы просто берете и переносите софт со всеми "кишками" на другой сервер и он просто работает. Работает за счет того, что все "кишки" это слои файловой системы нанизанные как бисер друг на друга. Дополнительно решается проблема свободного места, т.к слои многократно переиспользуются контейнерами, если вам нужен php + одна библиотека, а другому php + другая библиотека, вы используете (грубо говоря) слой php, а для дополнительной библиотеки делаете отдельный слой, одновременно другой человек делает над php другой слой и вы не деретесь между собой и не видите чужих библиотек. Это грубо и скорее всего ради одной библиотеки никто новый слой не делает, делают слой пожирнее.

Все запущенные процессы Docker помещает в изолированную среду процессов, файловой системы и сетевого стека. Есть много особенностей по работе с Docker, т.к он предполагает, что в одном контейнере вы запускаете один процесс. Если вам нужно запустить целый набор демоном, тут появляются проблемы, нужно писать шелл-скрипт, который все это поднимет в контейнере. Так же есть особенности по сети, файловой системе. Для кого то Docker спасение и решение всех проблем, но я как сисадмин от этого всего не в восторге.

К экрану скотчем приклеена монета. Вот описание проекта и програмный код. А тут статья на Хабре.

Идея такая:
- покажите клиенту форму для ввода данных
- клиент заполняет эту форму и нажимает OK
- вы обрабатываете сигнал о закрытии окна и скрываете его
- далее, метаданные из окна никуда не делись, вы можете продолжить их использовать. (ну например это было окно настроек программы и вы сохраняете данные на диск).
- как только решите, что никакие данные из этого окна более не нужны, то смело уничтожайте его.

А почему вам датчики не обозначить как некий блок в виде прямоугольника с буквой А и номером блока? А от этого блока к ПЛК подвести необходимое количество соединений.
Мы так поступаем, когда к схеме подключён например резистивный матричный тачскрин. На Э3 нарисован разъём, куда припаян тачскрин, на э7, если не ошибаюсь, Блоками изображён тачскрин и наша плата и дана схема соединения тача с платой.

Недавно отсканировал ВСЕ альбомы. Ушло пару недель (несколько тысяч фото)

Из опыта:
Сканировать с максимальным разрешением - реально НЕ нужно. Переглядывать фотки раз в десять лет, причем важно просто разглядеть что там, а не высматривать щербинки и родинки. Поэтому на 600 DPI хватает выше крыши для всех обычных семейных фото, а для фоток сделанных мыльницей - 300 dpi за глаза.

Отдельные фотки для реставрации, можно постараться отсканить с бОльшим разрешением, 1200, аккуратно прижимать, но нужно понимать, что если вы начнете реставрировать сами, то через 30-40 фоток вам это надоест, и вы поймете что не так уж и важно сверх-качество. Следовательно хорошо подумайте, стоит ли фотка дополнительных усилий, или ее в общую стопку. Редкие студийные фото, сделанные не на цифровые камеры тоже можно отсканить в 1200.

Слайды, диафильмы - 1200 хватило. немного размыто, но на самом деле сами слайды не дают слишком большое разрешение, то есть сканируя слайд на 2400, особо качества не добавилось, а размер - в разы. Его потом просто неудобно смотреть.

На что нужно обращать внимание:
1) Положение фото на сканере. Чем ровнее положить, чем аккуратнее закрыть крышкой, тем ровнее будет фотка, проще обрезать, меньше работы.
2) Сразу придумать каталогизацию. Пока фото сканируется, можно его переименовать, положить в нужный каталог.
Вот такое - не очень.
серый_альбом/фото10.jpg
белый_альбом/фото10.jpg

А сквозная нумерация - гораздо лучше, особенно если в будущем фотки будут перекладываться из папки в папку.
серый_альбом/фото10.jpg
белый_альбом/фото20.jpg

В идеале, если альбомы велись корректно, то год-месяц-день_номер.jpg. Если с этим тяжело, можно например 2001-xx-xx-01.jpg, будет хотя бы год.

Bookmate.

webGL: demo.f4map.com

https://habrahabr.ru/auth/settings/notifications/
https://geektimes.ru/auth/settings/notifications/
https://megamozg.ru/auth/settings/notifications/
https://toster.ru/my/notices
freelansim.ru/my/mail_subscription
https://moikrug.ru/preferences/notifications

Это карта всех возможных состояний и вариантов взаимодействия вашего приложения\сайта