Русский
Русский
English
Статистика
Реклама

Разработка

Перевод Реализация epoll, часть 2

05.11.2020 16:06:36 | Автор: admin
Публикуя перевод первой статьи из цикла материалов о реализации epoll, мы провели опрос, посвящённый целесообразности перевода продолжения цикла. Более 90% участников опроса высказались за перевод остальных статей. Поэтому сегодня мы публикуем перевод второго материала из этого цикла.



Функция ep_insert()


Функция ep_insert() это одна из самых важных функций в реализации epoll. Понимание того, как она работает, чрезвычайно важно для того чтобы разобраться в том, как именно epoll получает сведения о новых событиях от файлов, за которыми наблюдает.

Объявление ep_insert() можно найти в строке 1267 файла fs/eventpoll.c. Рассмотрим некоторые фрагменты кода этой функции:

user_watches = atomic_long_read(&ep->user->epoll_watches);if (unlikely(user_watches >= max_user_watches))  return -ENOSPC;

В этом фрагменте кода функция ep_insert() сначала проверяет, не превышает ли общее количество файлов, за которым наблюдает текущий пользователь, значения, заданного в /proc/sys/fs/epoll/max_user_watches. Если user_watches >= max_user_watches, то функция немедленно прекращает работу с errno, установленным в ENOSPC.

После этого ep_insert() выделяет память, пользуясь механизмом управления памятью slab ядра Linux:

if (!(epi = kmem_cache_alloc(epi_cache, GFP_KERNEL)))  return -ENOMEM;

Если функции удалось выделить объём памяти, достаточный для struct epitem, будет выполнен следующий процесс инициализации:

/* Инициализация ... */INIT_LIST_HEAD(&epi->rdllink);INIT_LIST_HEAD(&epi->fllink);INIT_LIST_HEAD(&epi->pwqlist);epi->ep = ep;ep_set_ffd(&epi->ffd, tfile, fd);epi->event = *event;epi->nwait = 0;epi->next = EP_UNACTIVE_PTR;

После этого ep_insert() попытается зарегистрировать коллбэк в файловом дескрипторе. Но прежде чем мы сможем об этом поговорить, нам нужно познакомиться с некоторыми важными структурами данных.

Структура poll_table это важная сущность, используемая реализацией poll() VFS. (Понимаю, что в этом можно запутаться, но тут мне хотелось бы объяснить, что функция poll(), которую я тут упомянул, представляет собой реализацию файловой операции poll(), а не системный вызов poll()). Она объявлена в include/linux/poll.h:

typedef struct poll_table_struct {  poll_queue_proc _qproc;  unsigned long _key;} poll_table;

Сущность poll_queue_proc представляет тип функции-коллбэка, который выглядит так:

typedef void (*poll_queue_proc)(struct file *, wait_queue_head_t *, struct poll_table_struct *);

Член _key таблицы poll_table, на самом деле, является не тем, чем он может показаться на первый взгляд. А именно, несмотря на имя, наводящее на мысль о некоем ключе, в _key, на самом деле, хранятся маски интересующих нас событий. В реализации epoll _key устанавливается в ~0 (дополнение до 0). Это значит, что epoll стремится получать сведения о событиях любых видов. В этом есть смысл, так как приложения пользовательского пространства могут в любое время менять маску событий с помощью epoll_ctl(), принимая все события от VFS, а затем фильтруя их в реализации epoll, что упрощает работу.

Для того чтобы облегчить восстановление в poll_queue_proc исходной структуры epitem, epoll использует простую структуру, называемую ep_pqueue, которая служит обёрткой для poll_table с указателем на соответствующую структуру epitem (файл fs/eventpoll.c, строка 243):

/* Структура-обёртка, используемая в очереди */struct ep_pqueue {  poll_table pt;  struct epitem *epi;};

Затем ep_insert() инициализирует struct ep_pqueue. Следующий код сначала записывает в член epi структуры ep_pqueue указатель на структуру epitem, соответствующую файлу, который мы пытаемся добавить, а затем записывает ep_ptable_queue_proc() в член _qproc структуры ep_pqueue, а в _key записывает ~0.

/* Инициализация таблицы с использованием коллбэка */epq.epi = epi;init_poll_funcptr(&epq.pt, ep_ptable_queue_proc);

После этого ep_insert() вызовет ep_item_poll(epi, &epq.pt);, что приведёт к вызову реализации poll(), связанной с файлом.

Давайте рассмотрим пример, в котором используется реализация poll() TCP-стека Linux, и разберёмся с тем, что именно эта реализация делает с poll_table.

Функция tcp_poll() это реализация poll() для TCP-сокетов. Её код можно найти в файле net/ipv4/tcp.c, в строке 436. Вот фрагмент этого кода:

unsigned int tcp_poll(struct file *file, struct socket *sock, poll_table *wait){  unsigned int mask;  struct sock *sk = sock->sk;  const struct tcp_sock *tp = tcp_sk(sk);  sock_rps_record_flow(sk);  sock_poll_wait(file, sk_sleep(sk), wait);  // код опущен}

Функция tcp_poll() вызывает sock_poll_wait(), передавая, в качестве второго аргумента, sk_sleep(sk), а в качестве третьего wait (это ранее переданная функции tcp_poll() таблица poll_table).

А что представляет собой sk_sleep()? Как оказывается, это всего лишь геттер, предназначенный для доступа к очереди ожидания событий для конкретной структуры sock (файл include/net/sock.h, строка 1685):

static inline wait_queue_head_t *sk_sleep(struct sock *sk){  BUILD_BUG_ON(offsetof(struct socket_wq, wait) != 0);  return &rcu_dereference_raw(sk->sk_wq)->wait;}

Что же sock_poll_wait() собирается делать с очередью ожидания событий? Оказывается, что эта функция выполнит некую простую проверку и потом вызовет poll_wait() с передачей тех же самых параметров. Затем функция poll_wait() вызовет заданный нами коллбэк и передаст ему очередь ожидания событий (файл include/linux/poll.h, строка 42):

static inline void poll_wait(struct file * filp, wait_queue_head_t * wait_address, poll_table *p){  if (p && p->_qproc && wait_address)    p->_qproc(filp, wait_address, p);}

В случае с epoll сущность _qproc будет представлять собой функцию ep_ptable_queue_proc(), объявленную в файле fs/eventpoll.c, в строке 1091.

/** Это - коллбэк, используемый для включения нашей очереди ожидания в* состав списков процессов целевого файла, работу которых надо возобновить.*/static void ep_ptable_queue_proc(struct file *file, wait_queue_head_t *whead,       poll_table *pt){  struct epitem *epi = ep_item_from_epqueue(pt);  struct eppoll_entry *pwq;  if (epi->nwait >= 0 && (pwq = kmem_cache_alloc(pwq_cache, GFP_KERNEL))) {    init_waitqueue_func_entry(&pwq->wait, ep_poll_callback);    pwq->whead = whead;    pwq->base = epi;    add_wait_queue(whead, &pwq->wait);    list_add_tail(&pwq->llink, &epi->pwqlist);    epi->nwait++;  } else {    /* Нам нужно сообщить о возникновении ошибки */    epi->nwait = -1;  }}

Сначала ep_ptable_queue_proc() пытается восстановить структуру epitem, которая соответствует файлу из очереди ожидания, с которым мы работаем. Так как epoll использует структуру-обёртку ep_pqueue, восстановление epitem из указателя poll_table представлено простой операцией с указателями.

После этого ep_ptable_queue_proc() просто выделяет столько памяти, сколько нужно для struct eppoll_entry. Эта структура работает как связующее звено между очередью ожидания файла, за которым ведётся наблюдение, и соответствующей структурой epitem для этого файла. Для epoll чрезвычайно важно знать о том, где находится голова очереди ожидания для файла, за которым ведётся наблюдение. В противном случае epoll не сможет позже отменить регистрацию в очереди ожидания. Структура eppoll_entry, кроме того, включает в себя очередь ожидания (pwq->wait) с функцией возобновления работы процесса, представленной ep_poll_callback(). Возможно, pwq->wait это самая важная часть во всей реализации epoll, так как эту сущность используют для решения следующих задач:

  1. Мониторинг событий, происходящих с конкретным файлом, за которым осуществляется наблюдение.
  2. Возобновление работы других процессов в том случае, если возникает такая необходимость.

После этого ep_ptable_queue_proc() присоединит pwq->wait к очереди ожидания целевого файла (whead). Функция, кроме того, добавит struct eppoll_entry в связный список из struct epitem (epi->pwqlist) и инкрементирует значение epi->nwait, представляющее собой длину списка epi->pwqlist.

А вот тут у меня возникает один вопрос. Почему epoll нужно использовать связный список для хранения структуры eppoll_entry внутри структуры epitem одного файла? Не нужен ли epitem лишь один элемент eppoll_entry?

Я, правда, не могу точно ответить на этот вопрос. Насколько я могу судить, если только некто не собирается использовать экземпляры epoll в каких-нибудь безумных циклах, список epi->pwqlist будет содержать лишь один элемент struct eppoll_entry, а epi->nwait для большинства файлов, скорее всего, будет равняться 1.

Хорошо тут то, что неясности вокруг epi->pwqlist никак не отражаются на том, о чём я буду говорить ниже. А именно, речь пойдёт о том, как Linux уведомляет экземпляры epoll о событиях, происходящих с файлами, за которыми осуществляется наблюдение.

Помните то, о чём мы говорили в предыдущем разделе? Речь шла о том, что epoll присоединяет wait_queue_t к списку ожидания целевого файла (к wait_queue_head_t). Несмотря на то, что wait_queue_t чаще всего используется как механизм возобновления работы процессов, это, по сути, просто структура, хранящая указатель на функцию, которая будет вызвана тогда, когда Linux решит возобновить работу процессов из очереди wait_queue_t, прикреплённую к wait_queue_head_t. В этой функции epoll может принять решение о том, что делать с сигналом возобновления работы, но у epoll нет необходимости возобновлять работу какого-либо процесса! Как можно будет увидеть позже, обычно при вызове ep_poll_callback() возобновления работы чего-либо не происходит.

Полагаю, ещё стоит обратить внимание на то, что механизм возобновления работы процессов, применяемый в poll(), полностью зависит от реализации. В случае с файлами TCP-сокетов голова очереди ожидания это член sk_wq, сохранённый в структуре sock. Это, кроме того, объясняет необходимость использования коллбэка ep_ptable_queue_proc() для работы с очередью ожидания. Так как в реализациях очереди для разных файлов голова очереди может оказаться в совершенно разных местах, у нас нет способа обнаружить нужное нам значение wait_queue_head_t без использования коллбэка.

Когда именно осуществляется возобновление работы sk_wq в структуре sock? Как оказалось, система сокетов Linux следует тем же OO-принципам проектирования, что и VFS. Структура sock объявляет следующие хуки в строке 2312 файла net/core/sock.c:

void sock_init_data(struct socket *sock, struct sock *sk){  // код опущен...  sk->sk_data_ready  =   sock_def_readable;  sk->sk_write_space =  sock_def_write_space;  // код опущен...}

В sock_def_readable() и sock_def_write_space() осуществляется вызов wake_up_interruptible_sync_poll() для (struct sock)->sk_wq с целью выполнения функции-коллбэка, возобновляющей работу процесса.

Когда же будут вызываться sk->sk_data_ready() и sk->sk_write_space()? Это зависит от реализации. Рассмотрим, в качестве примера, TCP-сокеты. Функция sk->sk_data_ready() будет вызвана во второй половине обработчика прерывания в том случае, когда TCP-подключение завершит процедуру трёхстороннего рукопожатия, или когда для некоего TCP-сокета будет получен буфер. Функция sk->sk_write_space() будет вызвана при изменении состояния буфера с full на available. Если помнить об этом при разборе следующих тем, особенно той, что посвящена срабатыванию по фронту, эти темы будут выглядеть интереснее.

Итоги


На этом мы завершаем второй материал из цикла статей о реализации epoll. В следующий раз поговорим о том, чем именно занимается epoll в коллбэке, зарегистрированном в очереди возобновления выполнения процессов сокета.

Пользовались ли вы epoll?



Подробнее..

Перевод Автоматизация DevOps

06.11.2020 18:09:43 | Автор: admin
Возникает такое ощущение, что в наши дни термин DevOps понимают очень по-разному. Я, являясь DevOps-экспертом в OutSystems, отвечаю на вопрос о том, что такое DevOps, говоря, что это механизм, ускоряющий доведение до потребителей полезных возможностей программ. Это нечто большее, чем некий навык, или должность, или инструмент. DevOps это парадигма, меняющая производственную культуру в сфере разработки ПО.

Главное тут ускорение процесса доставки изменений программ в продакшн-окружение и усиление возможностей циклов обратной связи в конвейере подготовки новых версий программ к работе. Это позволяет быстро, ещё на стадии разработки, узнавать о проблемах, и быстро их исправлять. Именно поэтому можно обратить внимание на то, что такие понятия, как CI/CD и автоматизация тестирования тесно связаны с DevOps.



Но DevOps это ещё и улучшение взаимодействия между разработчиками и другими специалистами. Это ликвидация организационной разобщённности. Это открытие пути для инноваций через эксперименты и возможность измерить воздействие каждого изменения кода на бизнес. А значит возможность действовать с учётом результатов подобных измерений.

Недавно я рассказывал об автоматизации DevOps на TechTalk. Если вас интересует эта тема предлагаю вам взглянуть на мою статью.

Зачем в DevOps нужна автоматизация?


Огромный плюс автоматизации DevOps заключается в том, что это повышает скорость и гибкость разработки приложения и доставки их конечному пользователю. Автоматизация устраняет узкие места и позволяет отказаться от больших объёмов ручного труда. Кроме того, вместе с автоматизацией процессов приходит и их стандартизация, что ещё сильнее сокращает вероятность возникновения ошибок или оплошностей, характерных для ручных подходов к решению задач.

Давайте, для примера, посмотрим на то, как вручную обрабатывается типичный запрос от клиента, направленный на внесение изменений в функционал приложения. Клиент отправляет операционной группе электронное письмо со сведениями о том, что ему хотелось бы видеть в программе. Операционная группа передаёт сообщение разработчикам, которые начинают работу над задачей. После того, как дело будет сделано, новая версия приложения попадает к тестировщикам, которые, после завершения испытаний, сообщают о его результатах разработчикам. Этот процесс повторяется до тех пор, пока новая версия приложения не будет наконец развёрнута в продакшне.

При таком подходе к внесению изменений в программы многое может пойти неправильно. Тут могут проявиться недостатки в рабочих процессах, последствия ручного вмешательства в процессы, задержки в обмене сообщениями. Кто-то может что-то неправильно понять Автоматизируя DevOps-процессы можно раз и навсегда решить некоторые из этих проблем.

В ходе автоматизации DevOps собирают в единую систему инструменты, используемые специалистами, работающими над программами на разных стадиях её жизненного цикла. При этом обеспечивается прозрачность процессов, высокая скорость выхода новых версий программ, упрощается развёртывание проектов.


Различные этапы работы над проектом неразрывно связаны

Инструменты для автоматизации DevOps


Существует просто невероятное количество DevOps-инструментов. Вы, возможно, уже пользуетесь некоторыми из них.


DevOps-инструменты (источник)

Хочу рассказать о моих любимых инструментах, применяемых на различных стадиях жизненного цикла программных проектов.

Jenkins


Jenkins это средство для автоматизации CI/CD-процессов, предназначенное для мониторинга выполнения повторяющихся задач. Это опенсорсный проект, который может работать на различных платформах. В нём имеется несколько встроенных плагинов, предназначенных для создания CI/CD-конвейеров. С использованием CI/CD-сервера Jenkins можно автоматизировать различные стадии работы над приложением.

Azure DevOps


Azure DevOps Server это тоже инструмент CI/CD-автоматизации, возможности которого охватывают весь жизненный цикл приложения. Этот проект разработан компанией Microsoft, он даёт в распоряжение разработчиков, благодаря использованию Team Foundation Version Control (TFVC) или Git, систему контроля версий. Он поддерживает систему отчётов, системы управления требованиями и проектами, средства для автоматической сборки, тестирования и выпуска проектов.

Selenium


Selenium это кросс-платформенный фреймворк для тестирования веб-приложений. Среди его возможностей можно отметить средства для записи и выполнения тестов, позволяющие создавать тесты без необходимости изучения какого-либо языка программирования. Он, кроме того, поддерживает особый язык для написания тестов (Selenese). Писать тесты можно и с использованием других языков программирования, в состав которых входят Java, C#, Groovy, Perl, PHP, Python и Ruby

Applitools


Applitools это проект, направленный на тестирование и мониторинг пользовательского интерфейса приложения, выполняемые как часть CI/CD-процесса. Программа контролирует самые важные функции приложений и внешний вид их интерфейсов. Поддерживается автоматизированная работа с веб-приложениями, с мобильными и нативными проектами.

Browserstack


Browserstack это ещё один инструмент для автоматизации тестирования, облачная платформа для тестирования веб-проектов и мобильных приложений, которая позволяет программистам проверять свои разработки с использованием различных браузеров, операционных систем, реальных мобильных устройств. При этом тем, кто пользуется Browserstack, не нужно заботиться о создании или поддержке собственного парка виртуальных машин, устройств или эмуляторов.

Appium


Appium это опенсорсный инструмент для автоматизации тестирования приложений. С его помощью можно запускать скрипты и тестировать нативные, мобильные, гибридные приложения. Он поддерживает и тестирование веб-приложений, и приложений, созданных для платформ Android и iOS с использованием веб-драйвера.

Tricentis


Tricentis Tosca это программа, которую можно использовать для сквозного тестирования приложений. В ней объединено множество аспектов тестирования. Среди них создание тестовых случаев, автоматизация тестирования, тестирование с последующим выведением данных, формирование аналитических сведений по результатам испытаний графических пользовательских интерфейсов и API.

Sauce Labs


Sauce Labs позволяет запускать тесты в облачной среде, давая в распоряжение тестировщиков обширную инфраструктуру, рассчитанную на проведение автоматизированных и ручных испытаний настольных и мобильных приложений. Этот проект поддерживает выполнение тестов с помощью Selenium, Appium и JavaScript-фреймворков для модульного тестирования. Он, кроме того, даёт в распоряжение тестировщиков возможности защищённого протокола Sauce Connect, позволяющего тестировать проекты, находящиеся за файрволами клиентов.

ElasticSearch


ElasticSearch это самая популярная поисковая система корпоративного класса, предназначенная для решения задач мониторинга и аналитики. Она предлагает пользователям возможности распределённой полнотекстовой поисковой системы с веб-интерфейсом, основанным на HTTP, поддерживающей JSON-документы, не имеющие схемы.

OutSystems


Существуют платформы для разработки приложений, в состав которых входят DevOps-механизмы, способные поддерживать работу над приложением на протяжении всего их жизненного цикла. Одна из таких платформ OutSystems.

Итоги


В этом материале мы рассмотрели некоторые инструменты для автоматизации DevOps. Надеемся, они вам пригодятся.

Как вы автоматизируете DevOps?



Подробнее..

Перевод Реализация epoll, часть 4

09.11.2020 20:17:29 | Автор: admin
Это последний материал из серии четырёх статей (часть 1, часть 2, часть 3), посвящённой реализации epoll. Тут речь пойдёт о том, как epoll передаёт события из пространства ядра в пользовательское пространство, и о том, как реализованы режимы срабатывания по фронту и по уровню.



Эта статья написана позже остальных. Когда я начинал работу над первым материалом, самой свежей стабильной версией ядра Linux была 3.16.1. А во время написания данной статьи это уже версия 4.1. Именно на коде этой версии ядра и основана данная статья. Код, правда, изменился не особенно сильно, поэтому читатели предыдущих статей могут не беспокоиться о том, что что-то в реализации epoll очень сильно изменилось.

Взаимодействие с пользовательским пространством


В предыдущих материалах я потратил довольно много времени на объяснение того, как работает система обработки событий в ядре. Но, как известно, ядру надо передать сведения о событиях программе, работающей в пользовательском пространстве для того чтобы программа могла бы воспользоваться этими сведениями. Это, в основном, делается с помощью системного вызова epoll_wait(2).

Код этой функции можно найти в строке 1961 файла fs/eventpoll.c. Сама эта функция очень проста. После вполне обычных проверок она просто получает указатель на eventpoll из файлового дескриптора и выполняет вызов следующей функции:

error = ep_poll(ep, events, maxevents, timeout);

Функция ep_poll()


Функция ep_poll() объявлена в строке 1585 того же файла. Она начинается с проверки того, задал ли пользователь значение timeout. Если так и было, то функция инициализирует очередь ожидания и устанавливает тайм-аут в значение, заданное пользователем. Если пользователь не хочет ждать, то есть, timeout = 0, то функция сразу же переходит к блоку кода с меткой check_events:, ответственному за копирование события.

Если же пользователь задал значение timeout, и событий, о которых ему можно сообщить, нет (их наличие определяют с помощью вызова ep_events_available(ep)), функция ep_poll() добавляет сама себя в очередь ожидания ep->wq (вспомните то, о чём мы говорили в третьем материале этой серии). Там мы упоминали о том, что ep_poll_callback() в процессе работы активирует любые процессы, ожидающие в очереди ep->wq.

Затем функция переходит в режим ожидания, вызывая schedule_hrtimeout_range(). Вот в каких обстоятельствах спящий процесс может проснуться:

  1. Истекло время тайм-аута.
  2. Процесс получил сигнал.
  3. Возникло новое событие.
  4. Ничего не произошло, а планировщик просто решил активировать процесс.

В сценариях 1, 2 и 3 функция устанавливает соответствующие флаги и выходит из цикла ожидания. В последнем случае функция просто снова переходит в режим ожидания.

После того, как эта часть работы сделана, ep_poll() продолжает выполнять код блока check_events:.

В этом блоке сначала проверяется наличие событий, а затем выполняется следующий вызов, где и происходит самое интересное.

ep_send_events(ep, events, maxevents)

Функция ep_send_events() объявлена в строке 1546. Она, после вызова, вызывает функцию ep_scan_ready_list(), передавая, в качестве коллбэка, ep_send_events_proc(). Функция ep_scan_ready_list() проходится в цикле по списку готовых файловых дескрипторов и вызывает ep_send_events_proc() для каждого найденного ей готового события. Ниже станет понятно, что механизм, предусматривающий применение коллбэка, нужен для обеспечения безопасности и многократного использования кода.

Функция ep_send_events() сначала помещает данные из списка готовых файловых дескрипторов структуры eventpool в свою локальную переменную. Затем она устанавливает поле ovflist структуры eventpool в NULL (а его значением по умолчанию является EP_UNACTIVE_PTR).

Зачем авторы epoll используют ovflist? Это сделано ради обеспечения высокой эффективности работы epoll! Можно заметить, что после того, как список готовых файловых дескрипторов был взят из структуры eventpool, ep_scan_ready_list() устанавливает ovflist в значение NULL. Это приводит к тому, что ep_poll_callback() не попытается присоединить событие, которое передаётся в пользовательское пространство, обратно к ep->rdllist, что может привести к большим проблемам. Благодаря использованию ovflist функции ep_scan_ready_list() не нужно удерживать блокировку ep->lock при копировании событий в пользовательское пространство. В результате улучшается общая производительность решения.

После этого ep_send_events_proc() обойдёт имеющийся у неё список готовых файловых дескрипторов и снова вызовет их методы poll() для того чтобы удостовериться в том, что событие действительно произошло. Зачем epoll снова проверяет здесь события? Делается это для того чтобы убедиться в том, что событие (или события), зарегистрированное пользователем, всё ещё доступно. Поразмыслите над ситуацией, когда файловый дескриптор был добавлен в список готовых файловых дескрипторов по событию EPOLLOUT в тот момент, когда пользовательская программа выполняет запись в этот дескриптор. После того, как программа завершит запись, файловый дескриптор уже может быть недоступным для записи. Epoll нужно правильно обрабатывать подобные ситуации. В противном случае пользователь получит EPOLLOUT в тот момент, когда операция записи будет заблокирована.

Тут, правда, стоит упомянуть об одной детали. Функция ep_send_events_proc() прилагает все усилия для того чтобы обеспечить получение программами из пространства пользователя точных уведомлений о событиях. При этом возможно, хотя и маловероятно, то, что доступный набор событий изменится после того, как ep_send_events_proc() вызовет poll(). В этом случае программа из пользовательского пространства может получить уведомление о событии, которого больше не существует. Именно поэтому правильным считается всегда использовать неблокирующие сокеты при применении epoll. Благодаря этому ваше приложение не будет неожиданно заблокировано.

После проверки маски события ep_send_events_proc() просто копирует структуру события в буфер, предоставленный программой пользовательского пространства.

Срабатывание по фронту и срабатывание по уровню


Теперь мы наконец можем обсудить разницу между срабатыванием по фронту (Edge Triggering, ET) и срабатыванием по уровню (Level Triggering, LT) с точки зрения особенностей их реализации.

else if (!(epi->event.events & EPOLLET)) {    list_add_tail(&epi->rdllink, &ep->rdllist);}

Это очень просто! Функция ep_send_events_proc() добавляет событие обратно в список готовых файловых дескрипторов. В результате при следующем вызове ep_poll() тот же файловый дескриптор будет снова проверен. Так как ep_send_events_proc() всегда вызывает для файла poll() перед возвратом его приложению пользовательского пространства, это немного увеличивает нагрузку на систему (в сравнении с ET) если файловый дескриптор больше не доступен. Но смысл этого всего заключается в том, чтобы, как сказано выше, не сообщать о событиях, которые больше недоступны.

После того, как ep_send_events_proc() завершит копирование событий, функция возвращает количество скопированных ей событий, держа в курсе происходящего приложение пользовательского пространства.

Когда функция ep_send_events_proc() завершила работу, функции ep_scan_ready_list() нужно немного прибраться. Сначала она возвращает в список готовых файловых дескрипторов события, которые остались необработанными функцией ep_send_events_proc(). Такое может произойти в том случае, если количество доступных событий превысит размеры буфера, предоставленного программой пользователя. Кроме того, ep_send_events_proc() быстро прикрепляет все события из ovflist, если таковые имеются, обратно к списку готовых файловых дескрипторов. Далее, в ovflist опять записывается EP_UNACTIVE_PTR. В результате новые события будут прикрепляться к главному списку ожидания (rdllist). Функция завершает работу, активируя любые другие спящие процессы в том случае, если имеются ещё какие-то доступные события.

Итоги


На этом я завершаю четвёртую и последнюю статью из цикла, посвящённого реализации epoll. Я, в процессе написания этих статей, был впечатлён той огромной умственной работой, которую проделали авторы кода ядра Linux для достижения максимальной эффективности и масштабируемости. И я благодарен всем авторам кода Linux за то, что они, выкладывая результаты своей работы в общий доступ, делятся своими знаниями со всеми, кто в них нуждается.

Как вы относитесь к опенсорсному программному обеспечению?



Подробнее..

Перевод Таблицы и CSS-свойство float в современной веб-разработке

11.11.2020 12:15:25 | Автор: admin
Больше двадцати лет тому назад таблицы были основным HTML-средством для оформления веб-страниц. Таблицы давали веб-мастерам стабильный механизм для создания сайтов, имеющих некие признаки дизайна. Содержимое страниц больше не должно было идти строго сверху вниз. Материалы можно было размещать в ячейках таблиц, располагавшихся слева направо и сверху вниз. В те времена это казалось большим достижением.

Таблицы, правда, никогда не предназначались для создания макетов страниц. А тот, кто использует таблицы в таком качестве сегодня, сталкивается с самыми разными проблемами. Таблицы были удобным хаком, но лишь в своё время. Они могли принести много пользы, особенно тому, кто пытался создать какой-нибудь необычный макет, который, используя то, чем пользовались до таблиц, создать было нельзя.



Для современного веб-дизайнера совершенно очевидно то, что макеты страниц, основанные на таблицах, кроют в себе массу неприятностей. Одна из них, очень серьёзная, связана с доступностью материалов. Применение элементов <table>, <th>, <tr> и <td> не способствует созданию доступных страниц. Особенно в случаях, когда с их помощью создают сложных структуры из глубоко вложенных друг в друга таблиц. Средства для чтения текстов с экрана, которые, помимо их прямого предназначения, обычно используют как инструмент для оценки доступности контента, испытывают сложности с формированием связного текста на основе материалов, оформленных в виде таблиц. Это не говорит о том, что таблицы это плохо. Речь идёт лишь о том, что они не предназначены для создания макетов.

Взгляните на этот пример, размещённый на CodePen.


Страница, макет которой основан на таблицах

Попробуйте прочитать текст этой страницы с помощью какого-нибудь средства для чтения с экрана, вроде VoiceOver.

На первый взгляд макет этой страницы выглядит как нечто вполне современное. Но при его создании использовались исключительно HTML-таблицы. Этот пример демонстрирует тот факт, что использование таблиц для оформления чего-то, не являющегося обычными табличными данными, быстро приводит к неоправданному разрастанию кода и к ухудшению доступности контента.

Можно подумать, что таблицам, после всей той критики, которой они подвергаются уже многие годы, нет места в веб-дизайне. Если вы сами никогда не выпускали в продакшн макеты, основанные на таблицах, то вы, наверняка, слышали байки тех, кто так делал. Или, скорее, не байки, а страшные сказки. Кажется, что мы превратили таблицы в нечто вроде Internet Explorer среди HTML-элементов.

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

Таблицы созданы для представления данных, между которыми имеется семантическая связь, таких данных, которые лучше всего выводить в виде блоков, идущих друг за другом. Поэтому сегодня, в 2020 году, мы вполне можем пользоваться HTML-таблицами. И они, скорее всего, не потеряют актуальности ещё очень долго.

Вот пример использования HTML-элемента <table> для вывода именно тех данных для оформления которых и предназначены таблицы.


Табличные данные, оформленные с помощью элемента <table>

В начале 2000-х годов, когда веб двинулся в сторону стандартизации, таблицы, в роли инструмента для создания макетов страниц, отошли на второй план. Им на замену пришли другие механизмы, среди которых стоит особо отметить CSS-свойство float. Тогда на улице дизайнеров и разработчиков наступил настоящий праздник. Дело в том, что это значило, что у них, впервые, появился настоящее средство для реализации механизма разделения ответственности. А именно, HTML-разметка и CSS могли решать именно те задачи, для решения которых они предназначены. С помощью HTML можно было описывать содержимое страниц, а с помощью CSS настраивать внешний вид этого содержимого. Это сделало код страниц чище и улучшило возможности по его поддержке. А это, в результате, позволило уделить внимание веб-стандартам, вроде доступности контента, и даже более продвинутым вещам наподобие SEO.

Посмотрите на этот пример, а лучше попробуйте его послушать.


Страница, при создании которой используются обычные HTML-элементы и CSS-свойство float

Почувствовали разницу?

Раньше многие из нас работали с плавающими элементами, оформленными с помощью CSS-свойства float. Это свойство было задумано как механизм, позволяющий организовывать обтекание изображений текстом. При таком подходе материалы можно прижимать к левой или правой сторонам страницы, но при этом не изымать их из нормального потока документа. В наше время, когда появились CSS Grid и Flexbox, плавающие элементы, как в своё время таблицы, отошли на второй план. Может, дело в том, что теперь те задачи, которые решали с их помощью, можно решить с помощью более совершенных инструментов. А может в том, что за ними закрепилась дурная слава, как за таблицами, которые долго использовали и долго критиковали.

Но CSS-свойство float всё ещё вполне применимо и актуальности оно не потеряло! На самом деле, его необходимо использовать для обеспечения функционирования свойства shape-outside. Взгляните на этот пример.


Применение свойства float в современном веб-дизайне

Вполне обоснованный вариант использования свойства float заключается в настройке обтекания текстом цитат, оформленных с помощью элемента <blockquote>. Вот как это выглядит.


Оформление элемента <blockquote>

CSS-механизмы, вроде Grid, Flexbox, многоколоночных макетов, занимают почётное место среди лучших инструментов современного веб-дизайнера. Они дают нам огромные возможности по созданию макетов, делают код чище, а содержимое страниц доступнее. Можно ожидать того, что они ещё многие годы будут популярны и востребованы.

Вот пример уже знакомого вам макета, при разработке которого не использовалось никаких хаков или неоправданно больших объёмов кода. Этот макет создан с помощью Flexbox.


Страница, макет которой создан с помощью Flexbox

Итоги


В следующий раз, когда вам придётся думать о том, применять или нет HTML-таблицы или CSS-свойство float, вы сможете принять обоснованное решение. Сделать это можно будет, зная о том, для чего предназначены таблицы и плавающие элементы. Я вовсе не жду того, что тот, кто дочитал до этого места, с энтузиазмом примется, к месту и не к месту, вставлять в свой код таблицы и свойство float. Тут главное помнить о том, что это инструменты, отлично подходящие для решения определённых задач. Это неотъемлемая часть арсенала современного веб-разработчика. Нужно лишь правильно и оправданно их использовать.

Пользуетесь ли вы HTML-таблицами и CSS-свойством float?



Подробнее..

Перевод Raspberry Pi в роли сервера для хостинга сайтов

20.11.2020 12:14:59 | Автор: admin
Raspberry Pi это недорогой одноплатный компьютер, отличающийся крайней экономичностью в плане потребления электроэнергии. Он хорошо подходит на роль платформы, на базе которой создают устройства, которые постоянно должны быть включены. Среди множества способов применения Raspberry Pi можно выделить использование этого компьютера в качестве веб-сервера. И, на самом деле, хостить сайты на Raspberry Pi очень просто. Если посчитать стоимость услуг обычного хостинг-провайдера, то окажется, что они не так уж и дёшевы. Альтернативой таким услугам может стать собственный хостинг на Raspberry Pi, обслуживание которого не стоит практически ничего. Кроме того, платформа Raspberry Pi постоянно развивается, поэтому тому, кто решает ей пользоваться, можно не беспокоиться о том, что в будущем ему придётся работать с устаревшим аппаратным и программным обеспечением.



Сильные стороны Raspberry Pi-хостинга


У хостинга сайтов на Raspberry Pi есть немало преимуществ перед использованием для этой цели традиционных серверов. Вот некоторые из них:

  • Обычный хостинг дорог.
  • Raspberry Pi весьма экономичен в плане потребления энергии.
  • Raspberry Pi легко транспортировать.
  • Круглосуточная работа обычного сервера означает большие энергозатраты.

Кроме прочего, организовать хостинг на Raspberry Pi можно за считанные минуты. При этом подойдёт любая версия Raspberry Pi. В результате оказывается, что тот, у кого есть Raspberry Pi и хороший интернет, может без проблем хостить собственный сайт и ни о чём не беспокоиться.

Хостинг сайта на Raspberry Pi


В этом материале я приведу пошаговое руководство по организации хостинга сайтов на Raspberry Pi. Если вам нужен подобный хостинг рекомендуется читать этот материал, ничего не пропуская, и тут же делать то, о чём идёт речь. А перед началом работы просмотрите статью это позволит вам получить общее представление о том, что вы должны будете сделать, и о том, что вам для этого понадобится.

Аппаратные средства


Для организации хостинга на Raspberry Pi вам понадобится следующее:

  1. Raspberry Pi. Полагаю, не стоит и говорить о том, что перед началом этого проекта вам понадобится Raspberry Pi. Но, всё же, скажу. При этом постарайтесь обзавестись самой современной версией Raspberry Pi она обеспечит более высокую производительность.
  2. Маршрутизатор или модем. Они нужны для подключения Raspberry Pi к интернету. Порой интернет-провайдеры дают пользователям устройство, позволяющее подключить к интернету ограниченное количество пользовательских устройств. В такой ситуации, чтобы упростить подключение к интернету множества устройств, пригодится маршрутизатор.
  3. Ethernet-кабель. Лучше всего подключать Raspberry Pi к интернету именно с помощью кабеля. Так можно добиться более высокого качества соединения. Но можно использовать и Wi-Fi-адаптер встроенный или внешний.

Шаг 1: настройка операционной системы на Raspberry Pi


Подключите microSD-карту к компьютеру и отформатируйте её. Загрузите NOOBS (New Out Of Box Software). Это установщик операционных систем, рассчитанный на новичков. После завершения загрузки архива распакуйте его и скопируйте файлы на только что отформатированную microSD-карту.

Вставьте карту в Raspberry Pi, подключите к плате блок питания, клавиатуру, монитор и мышь. Raspberry Pi начнёт загружаться, вы увидите экран выбора операционной системы, которую нужно установить. Если на этом этапе что-то пошло не так вероятнее всего блок питания или HDMI-кабель подключены недостаточно надёжно. Поэтому проверьте подключение кабелей к Raspberry Pi.

Если у вас нет опыта работы с Raspberry Pi, то на экране выбора операционной системы я рекомендую выбрать Raspbian. Ещё один хороший вариант Adafruit. Установка операционной системы займёт некоторое время. Проследите за тем, чтобы всё это время Raspberry Pi не выключался бы.


Экран выбора операционной системы

После того, как вы увидите сообщение Image applied successfully, вы можете щёлкнуть по кнопке Return и Raspberry Pi перезагрузится. После завершения перезагрузки вы увидите графический интерфейс установленной ОС.

Шаг 2: взаимодействие с Raspberry Pi-сервером по SSH


На этом шаге мы настроим подключение к Raspberry Pi-серверу по SSH. Протокол SSH позволяет организовать безопасное соединение между компьютером и Raspberry Pi, используемое для передачи данных. С помощью такого соединения, кроме того, можно, пользуясь инструментами командной строки, управлять Raspberry Pi.

Теперь, когда в вашем распоряжении имеется ОС Raspbian, установленная с использованием свежей версии NOOBS, то у вас, вероятно, установлено и всё необходимое для работы с SSH. Для того чтобы организовать соединение компьютера и Raspberry Pi вам понадобится узнать IP-адрес платы. Для этого воспользуйтесь следующей командой:

sudo ifconfig

То, что вам нужно, можно найти в верхней части экрана. Если вы подключили Raspberry Pi к интернету с использованием Ethernet-кабеля, в начале блока, содержащего нужный вам адрес, будет eth0. Если вы пользуетесь Wi-Fi, то там будет wlan0. В обоих случаях то, что нам нужно, идёт после inet addr:. Именно этот адрес и можно использовать для подключения к Raspberry Pi с компьютера.


Выяснение IP-адреса Raspberry Pi

Если ваш компьютер работает под управлением Windows, вам понадобится SSH-клиент. Например PuTTY. Для настройки подключения понадобится указать в поле Host Name IP-адрес, оставив в поле Port 22. Если нажать на Enter, PuTTY откроет окно терминала, в котором у вас попросят имя пользователя (по умолчанию pi) и пароль (по умолчанию raspberry) для подключения к Raspberry Pi. Введите их и вы готовы к удалённой работе с вашим новым сервером.


Окно настройки SSH-подключения

Если вы пользуетесь Mac или каким-нибудь дистрибутивом Linux, то всё необходимое для организации SSH-подключения у вас уже, наверняка есть. Вам, для подключения к Raspberry Pi, достаточно выполнить в терминале следующую команду:

ssh pi@IP ADDRESS

Если IP-адрес платы выглядит как 192.167.2.2, вам нужно будет модифицировать эту команду так:

ssh pi@192.167.2.2

Потом вам зададут вопрос о пароле. Стандартный пароль (raspberry) можно сменить на что-то более надёжное.

Шаг 3: обновление ПО Raspberry Pi


После того, как вы подключились к Raspberry Pi с компьютера по SSH, нужно, перед установкой Apache, привести систему в актуальное состояние. Для того чтобы это сделать, можно воспользоваться следующими командами:

sudo apt-get updatesudo apt-get upgrade

Система обновится, вы будете готовы к установке Apache.

Шаг 4: установка Apache


Если вы пытаетесь превратить Raspberry Pi в нечто такое, что способно хостить сайты, то вам понадобится специальное ПО. Например Apache. Это опенсорсный и совершенно бесплатный HTTP-сервер, который и позволит сделать из Raspberry Pi веб-сервер.

После загрузки установочных файлов Apache достаточно всего лишь одной команды для его установки:

sudo apt-get install apache2 php5 libapache2-mod-php5

Эта команда, правда, устанавливает не только Apache. Она отвечает за установку некоторых других пакетов, вроде PHP и PHP-библиотеки для Apache. Возможности PHP могут нам понадобиться, например, для организации подключения сайта к базе данных.


Успешная установка Apache

После того, как установка завершится, нужно, для активации программы, перезапустить её с помощью следующей команды:

sudo service apache2 restart

Затем, чтобы убедиться в том, что Apache работает нормально, можно воспользоваться такой командой:

sudo service apache2 status


Проверка правильности работы Apache

Если в выводе вышеприведённой команды имеется зелёный текст active (running), это значит, что всё работает как надо. Если сервер по какой-то причине будет выключен, запустить его снова можно так:

sudo service apache2 start

После этого вы сможете обращаться к Raspberry Pi с компьютера. Например, можете открыть браузер и перейти в нём по такому адресу (содержащему ранее выясненный IP-адрес платы, который использовался для подключения к ней по SSH):

http:// 192.167.2.2

В браузере будет выведена страница, сообщающая об успешной установке Apache.

Шаг 5: создание простого веб-сайта


После того, как на Raspberry Pi завершится установка Apache, сервер будет выдавать при обращении к нему простейшую стандартную HTML-страницу, сообщающую о том, что сервер работает.


Простая страница

Если вы хотите поменять эту страницу на что-то своё перейдите в папку /var/www/ и внесите в index.html свой код. Сделать это в терминале можно так:

cd /var/www/sudo nano index.html

Проверить то, что получилось можно, как и прежде, обратившись к серверу из браузера.

Шаг 6: настройка FTP


У вас, вероятнее всего, уже есть сайт, который вы хотите хостить на Raspberry Pi. Его нужно лишь перенести на сервер. Для этого удобно пользоваться FTP. Установим vsftpd (Very Secure FTP Daemon):

sudo chown -R pi /var/wwwsudo apt install vsftpd

После установки vsftpd нужно выполнить некоторые настройки.

Откроем файл настроек vsftpd:

sudo nano /etc/vsftpd.conf

Для начала надо изменить значение настройки anonymous_enable с YES на NO. Потом надо раскомментировать следующие строки:

#local_enable=YES#write_enable=YES

В конец файла надо добавить следующее:

force_dot_files=YES

Благодаря этому можно будет видеть файлы, имена которых начинаются с точки, вроде .htaccess.


Настройка vsftpd

После завершения редактирования файла vsftpd.conf надо нажать CTRL+X для сохранения файла и выхода из терминала. Подтвердить выполнение операции можно, введя Y и нажав на Enter. В итоге нужно перезапустить vsftpd:

sudo service vsftpd restart

Теперь можно будет подключаться к Raspberry Pi и выгружать на сервер, в директорию /var/www/html, материалы сайта.

Шаг 7: получение доменного имени


Теперь вы можете загружать на сервер материалы своего сайта и заходить на сайт из локальной сети. Но вот никому другому ваш сайт пока не доступен. Для того чтобы к сайту могли обращаться пользователи интернета, нужно сделать ещё кое-что. Далее речь пойдёт об одном из самых важных этапов настройки Raspberry Pi-сервера.

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

Если у вас нет статического IP-адреса, и ваш интернет-провайдер постоянно меняет ваш IP-адрес, можно воспользоваться сервисом No-IP, который будет автоматически обновлять связь между доменным именем и вашим текущим IP-адресом. Для того чтобы воспользоваться этим сервисом, нужно создать на нём бесплатную учётную запись и зарегистрировать доменное имя, вроде rspi.no-ip.org. После этого нужно установить некоторые программы на Raspberry Pi:

cd /usr/local/src/sudo wget http://www.no-ip.com/client/linux/noip-duc-linux.tar.gztar xf noip-duc-linux.tar.gzsudo rm noip-duc-linux.tar.gzcd noip-2.1.9-1/sudo make install

После этого у вас спросят имя пользователя и пароль, затем начнётся установка. Далее, нужно сделать так, чтобы No-IP-клиент запускался бы автоматически при включении Raspberry Pi. Для этого надо отредактировать файл rc.local:

cd /etc/sudo nano rc.local

В него надо добавить такую строку:

sudo noip2

Сохраните и закройте файл. После этого перезагрузите Raspberry Pi командой sudo reboot.

Шаг 8: посещение веб-сайта


После того, как настроена связь IP-адреса и доменного имени сайта, войти на него можно, введя в адресной строке браузера его доменное имя. При использовании сервиса No-IP работу системы можно проверить такой командой:

sudo noip2 -S


Проверка noip2

Если вам удастся узнать валидный PID, это значит, что всё работает нормально.

Шаг 9: улучшение производительности и безопасности


Организация хостинга на базе Raspberry Pi это довольно просто, но Raspberry Pi это не лучший сервер в плане производительности. Если вам не хватает производительности вашего сервера вы можете попробовать её улучшить.

Один из способов улучшения производительности Raspberry Pi-сервера использование для размещения материалов сайта USB-диска вместо SD-карты. При таком подходе сократится время, необходимое на доступ к данным.

В целом же можно отметить, что на Raspberry Pi-сервере лучше всего хостить простые статические сайты.

Если говорить о безопасности, то рекомендуется поменять стандартный пароль на что-то более надёжное. Для смены пароля можно воспользоваться командой passwd. Это повысит безопасность системы.

Организация LAMP-хостинга


Если вы полагаете, что статический HTML-сайт это для вас слишком просто, и что вам нужно что-то более продвинутое, то вам, возможно, подойдёт LAMP-сервер. Такой сервер поддерживает PHP и MySQL, что позволяет обеспечить работу интерактивных веб-сайтов. Если вы хотите использовать эту систему сначала установите сервер Apache, а затем MySQL. Для установки MySQL и соответствующих PHP-компонентов выполните следующую команду:

sudo apt install mysql-server php-mysql -y

После этого перезапустите Apache:

sudo service apache2 restart

Далее, нужно установить PHP:

sudo apt install php -y


LAMP-сервер

После завершения установки нужно снова перезапустить Apache, используя вышеупомянутую команду. Теперь LAMP-сервер готов к работе и в вашем распоряжении имеются PHP и MySQL, позволяющие создавать продвинутые веб-проекты.

Итоги


Мы разобрали несколько вариантов хостинга сайтов на Raspberry Pi. Как видите, такой хостинг не так уж и сложно настроить. Но тут нужно учитывать то, что возможности Raspberry Pi, в сравнении с обычным хостингом, ограничены. Правда, если вам нужно хостить простой статический сайт, то такой хостинг вам вполне подойдёт. Вам, кроме того, нужно будет принять во внимание вопросы производительности и безопасности.

Я искренне надеюсь на то, что вы добьётесь успеха в настройке и использовании Raspberry Pi в роли HTTP-сервера.

Как вы организовали бы хостинг, основанный на Raspberry Pi?



Подробнее..

Перевод Загрузка операционной системы с виниловой пластинки

25.11.2020 12:06:49 | Автор: admin
Большинство компьютеров загружаются с встроенного накопителя. Это может быть обычный жёсткий диск или SSD. Иногда они загружают ОС из сети, или, в крайнем случае, если загружаться больше неоткуда, с USB-флешки или с DVD. Как по мне так всё это скука смертная. Как насчёт загрузки ОС с виниловой пластинки?


10-дюймовая пластинка, время проигрывания которой составляет 6 минут 10 секунд при скорости 45 оборотов в минуту это загрузочный диск DOS размером 64512 байт

Для проведения этого необычного эксперимента персональный компьютер (а точнее IBM PC) подключён к проигрывателю виниловых пластинок через усилитель. Тут имеется маленький ROM-загрузчик, управляющий встроенным кассетным интерфейсом PC (который, пожалуй, никогда и никем не используется). Этот загрузчик вызывается BIOS в том случае, если все остальные способы загрузки не сработали (то есть загрузка с дискеты и с жёсткого диска). Проигрыватель воспроизводит аналоговую запись содержимого небольшого RAM-диска, предназначенную только для чтения, размер которой составляет 64 Кб. В этой записи имеется ядро FreeDOS, модифицированное мной так, чтобы его размер уложился бы в существующие ограничения. Здесь же есть компактный вариант COMMAND.COM и пропатченная версия INTERLNK, которая позволяет передавать файлы по принтерному кабелю и переделана так, чтобы она работала бы в FreeDOS. Загрузчик читает образ диска с пластинки через кассетный модем, записывает образ в память и загружает с его использованием ОС. Полагаю, не так уж всё это и сложно.


Виниловый загрузчик в ROM (он ещё может быть записан на жёсткий диск или на дискету, но это уже будет нечестно)

Если немного углубиться в технические детали, то окажется, что перед нами некий симбиоз BootLPT/86 и 5150CAXX без поддержки порта принтера. Он тоже хранится в ROM, в слоте расширения BIOS, но это необязательно. Для подключения усилителя к компьютеру используется кабель, аналогичный тому, что применяется в 5150CAXX, но тут не используется передача данных от компьютера к подключённому к нему устройству.

Кассетный интерфейс это всего лишь выход, представленный каналом 2 таймера динамика PC и вход, который представлен 4 каналом порта C 8255A-5 PPI (PC4, I/O-порт 62h, бит 4). Для программной (де)модуляции используются возможности BIOS INT 15h.

Загрузочный образ это тот же 64-килобайтный образ RAM-диска BOOTDISK.IMG, ссылку на загрузку которого можно найти здесь. Данные образа, с использованием 5150CAXX, преобразуются в вид, совместимый с протоколом IBM cassette tape, а получаемый аудиосигнал уходит прямо в систему записи виниловых пластинок.

Запись осуществляется с использованием кривой выравнивания RIAA, которую предварительный усилитель обычно обращает в процессе воспроизведения звука. Но делает он это не идеально. А значит на усилителе нужно выполнить коррекцию сигнала. Именно поэтому я и воспользовался усилителем, так как мне не удалось получить нужный сигнал, подав звук на компьютер сразу от предусилителя. В моём случае, используя винтажный усилитель Harman&Kardon 6300 и интегрированный предусилитель MM Phono, мне пришлось убавить высокие частоты (-10дБ/10кГц), поднять басы (+6дБ/50Гц) и уменьшить уровень громкости до получения пиков примерно в 0,7 вольта, что позволило предотвратить искажения звука. Всё это делалось, конечно, при отключённой коррекции фазы и громкости.

Безусловно, кассетному модему совершенно наплевать на то, откуда именно приходит сигнал. При этом, конечно, важно, чтобы запись была бы чистой, не содержала бы щелчков и треска (винил) или недостатков, связанных с модуляцией или частотой сигнала (магнитная лента). Всё это может прервать поток данных. Правда, звук вполне может немного плавать, скорость воспроизведения может варьироваться в пределах 2-3%. Это не мешает правильной передаче данных.


EPROM-модуль с загрузчиком

Итоги



Загрузка компьютера с проигрывателя виниловых пластинок

Вот и всё! Если кому-то нужен загрузчик, сделанный для чипа 2364 (через адаптер можно использовать и чипы 2764), то его код можно найти здесь. Он рассчитан на работу с IBM 5150 с монохромным дисплеем и с как минимум 512 Кб RAM, что (вот уж совпадение) напоминает компьютер, с которым экспериментирую я. Ссылку на образ загрузочного диска можно найти в этом материале. А вот тот же образ, но уже в звуковом виде.

Приходилось ли вам загружать компьютеры с использованием каких-нибудь необычных способов?



Подробнее..

Перевод Подробности об использовании CSS-функции minmax() в Grid-макетах

29.11.2020 12:04:16 | Автор: admin
Существует множество руководств, в которых рассматриваются общие вопросы работы с CSS Grid, с механизмом, позволяющим создавать сеточные макеты. Я и сам немало об этом писал. Но я обратил внимание на то, что у многих разработчиков возникают сложности с использованием CSS-функции minmax(). Пожалуй, дело тут в том, что большинство существующих публикаций на эту тему либо не вдаются в детали, либо не включают в себя достаточного количества пояснений и примеров из реального мира. А minmax() это очень мощная и полезная функция. Именно по этой причине я и решил написать данную статью. Это нечто вроде полного руководства по minmax(), задача которого дать читателям то, чего не дают им другие публикации на эту тему.



Здесь мы в подробностях обсудим возможности функции minmax() в применении к сеточным макетам, поговорим о том, как, когда и почему ей стоит пользоваться. Тот, кто проработает эту статью, сможет полноценно и со знанием дела применять эту функцию в своих проектах.

Общие вопросы использования minmax() в Grid-макетах


В спецификации CSS о функции minmax(min, max) сказано, что она определяет диапазон размеров, которые больше или равны min и меньше или равны max.

Эту функцию можно использовать в качестве значения, задающего параметры столбцов или строк Grid-макета. Рассмотрим простой пример:

.o-grid {display: grid;grid-template-columns: minmax(200px, 500px) 1fr 1fr;grid-gap: 1rem;}

Вот как это будет выглядеть на схеме.


Результат применения функции minmax() при создании Grid-макета

Проанализируем этот макет:

  1. Здесь имеется сетка с тремя столбцами.
  2. Ширина первого столбца задана как minmax(200px, 500px). Минимальная ширина этого столбца составляет 200px, максимальная 500px.
  3. Два других столбца имеют ширину 1fr. Это означает, что они займут оставшееся свободное пространство.

Продолжим эксперименты с этим примером, учитывая то, что при его создании нужно принимать во внимание внешний вид страницы в областях просмотра разной ширины. Что произойдёт в том случае, если область просмотра окажется очень узкой? Если коротко это описать, то получится, что на экране появится горизонтальная полоса прокрутки. Полагаю, нет такого человека, которому это понравится, за исключением тех случаев, конечно, когда наличие полосы прокрутки предусмотрено дизайнером.


Горизонтальная полоса прокрутки

В результате оказывается, что функция minmax(), сама по себе, не поддерживает создание отзывчивых макетов. А это значит, что поведением страницы приложения на экранах разной ширины нам нужно управлять самостоятельно. Ниже, в разделе практических примеров, мы к этому вернёмся.

Проверка правильности использования функции minmax()


Если значение min, переданное функции minmax(min, max), больше значения max, то значение max будет проигнорировано. В результате в конструкции minmax(min, max) реально использоваться будет лишь минимальное значение.


Если значение min больше значения max значение max игнорируется

Кроме того, важно помнить о том, что значение вроде 1fr нельзя использовать в качестве значения min. Оно может быть использовано только в роли значения max. При этом подобная ситуация хуже, чем та, когда min больше, чем max! Система проигнорирует всю конструкцию, содержащую подобное объявление.


Нельзя использовать 1fr в качестве значения min

Использование нуля в качестве значения min функции minmax()


Что произойдёт в том случае, если попытаться воспользоваться конструкцией вида minmax(0, 500px)? Пожалуй, вы уже знаете ответ на этот вопрос. Ширина столбца будет, как минимум, нулевой, и при этом она не превысит 500px. То есть ширина столбца будет меняться в достаточно широких пределах.


Ширина столбца может изменяться в диапазоне от 0 до 500px

Простой сеточный макет


Представим, что нам надо создать сеточный макет, состоящий из 3 колонок. Мы поступим так:

.o-grid {display: grid;grid-template-columns: minmax(200px, 1fr) minmax(200px, 1fr) minmax(200px, 1fr);grid-gap: 1rem;}

Колонки будут иметь минимальную ширину в 200px. Вот как они будут выглядеть.


Макет, минимальная ширина столбцов которого равна 200px

Избежать троекратного повторения конструкции minmax(200px, 1fr) можно, воспользовавшись функцией repeat():

.o-grid {display: grid;grid-template-columns: repeat(3, minmax(200px, 1fr));grid-gap: 1rem;}

Вышеприведённые стили вполне работоспособны, но пользоваться подобными конструкциями не рекомендуется. Поговорим о том, почему это так.

Ручное изменение количества столбцов


Если в подобном макете понадобится изменить количество столбцов, то делать это нужно будет вручную, редактируя код. Как по мне, так это не имеет смысла. Технология CSS Grid способна на большее, чем может показаться на первый взгляд.

Проблема появления горизонтальной полосы прокрутки


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


Горизонтальная полоса прокрутки

Как справиться с этой проблемой? Надо сообщить браузеру о том, что количество столбцов должно быть уменьшено в том случае, если ширины области просмотра недостаточно для вывода всего макета.

При разработке Flexbox-макетов это делается путём добавления свойства flex-wrap: wrap к родительскому элементу макета:

.parent {display: flex;flex-wrap: wrap;}


Flexbox-макет, в котором используется свойство flex-wrap: wrap, и макет, в котором это свойство не используется

При проектировании Grid-макетов для достижения подобного эффекта можно воспользоваться ключевыми словами auto-fill и auto-fit.


Сеточный макет, в котором применяются auto-fit/auto-fill, и макет, в котором эти ключевые слова не применяются

Использование ключевых слов auto-fit и auto-fill


Для того чтобы справиться с проблемой жёсткой настройки количества столбцов сеточного макета, мы можем воспользоваться возможностями ключевых слов auto-fit и auto-fill. При этом надо отметить, что между ними существует довольно-таки тонкое различие.

Так, при использовании auto-fit и при наличии свободного места элементы сетки будут растянуты. А применение auto-fill приводит к тому, что элементы растягиваться не будут. В результате дополнительное свободное пространство окажется незанятым, ширина элементов меняться не будет.


Результаты применения ключевых слов auto-fill и auto-fit

При использовании этих ключевых слов может получиться один и тот же результат. Это зависит от ширины области просмотра страницы. Но при определённой ширине области просмотра различия между ними будут уже вполне заметными.

Вот видеозапись, в которой показано поведение макетов, созданных, соответственно, с использованием auto-fill и auto-fit.


Исследование поведения макетов, созданных с использованием ключевых слов auto-fill и auto-fit

Распределение свободного пространства между столбцами auto-fit-макета


Вот видео, в котором прямоугольник, обведённый пунктирной линией, представляет свободное пространство. Когда, при использовании ключевого слова auto-fit, ширина области просмотра достаточно велика, браузер свернёт это свободное пространство и распределит его ширину между элементами сетки.


Распределение свободного пространства между столбцами auto-fit-макета

Распределение свободного пространства между столбцами auto-fill-макета


Если говорить о применении ключевого слова auto-fill, то тут браузер поступает со свободным пространством иначе. А именно, при увеличении ширины области просмотра ширина элементов не увеличивается. При этом размер свободного пространства (оно, в этом видео, выделено пунктиром) растёт.


Распределение свободного пространства между столбцами auto-fill-макета

Сценарии использования и практические примеры


Карточки, основанные на сеточном макете



Карточки

Полагаю, что функцию minmax() чаще всего используют для оформления карточек, применяя её при создании элемента-контейнера.

.wrapper {display: grid;grid-template-columns: repeat(auto-fill, minmax(250px, 1fr));grid-gap: 1rem;}

Когда я начал изучать технологию Grid, я неуютно чувствовал себя, глядя на свойство grid-template-columns, использованное в этом примере. Тут важно обратить внимание на то, как поведёт себя страница в областях просмотра, ширина которых меньше 250px. Дело в том, что в таких ситуациях на экране появится вертикальная полоса прокрутки.


Появление вертикальной полосы прокрутки в области просмотра, ширина которой меньше 250px

Решить эту проблему можно двумя способами. Первый заключается в использовании медиа-запросов. В основе этого способа лежит идея, в соответствии с которой grid-template-columns устанавливается в 1fr. А когда ширина области просмотра достаточно велика применяется minmax():

.wrapper {display: grid;grid-template-columns: 1fr;grid-gap: 1rem;}@media (min-width: 300px) {.wrapper {grid-template-columns: repeat(auto-fill, minmax(250px, 1fr));}}

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

.wrapper {display: grid;grid-template-columns: repeat(auto-fill, minmax(min(100%, 250px), 1fr));grid-gap: 1rem;}

Я использовал тут, в качестве первого значения функции minmax(), функцию сравнения min(). Вот что здесь происходит:

  • Если ширина области просмотра меньше, чем 250px, первым значением, передаваемым minmax(), будет 100% ширины родительского элемента.
  • Если ширина области просмотра будет больше, чем 250px, тогда первым значением minmax() будет 250px.

Тут мы вышли на более удачное решение проблемы и при этом использовали меньший объём CSS-кода. Если вы хотите ближе познакомиться с CSS-функциями сравнения вот мой материал об этом.

Использование единицы измерения ch при настройке элемента-контейнера


Мне кажется интересным пример использования функции minmax() при создании макета, предназначенного для отображения материалов статей. В данном примере содержимое статьи центровано по горизонтали.

.wrapper {display: grid;grid-template-columns: minmax(1rem, 1fr) minmax(auto, 70ch) minmax(1rem, 1fr);grid-gap: 1rem;}

Первый и последний столбцы играют вспомогательную роль, управляя свободным пространством. Нас тут интересует центральный столбец. Обратите внимание на то, что при его настройке использована конструкция вида minmax(auto, 70ch). Это означает, что максимальной шириной данного столбца является ширина, которую занимают 70 символов, выстроенных в одну строку. Это идеальное количество символов на строку, обеспечивающее комфортное чтение текста.


Макет, предназначенный для вывода текста статьи

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


Статья на экране мобильного устройства

Проблема, возникающая при необдуманном использовании ключевого слова auto-fit


У того, кто впервые узнал о ключевом слове auto-fit, может возникнуть желание использовать его повсюду. Но тут есть одна проблема, которая проявляется тогда, когда содержимое сетки (например количество карточек) меняется, а разработчик не контролирует это содержимое.

.wrapper {display: grid;grid-template-columns: repeat(auto-fit, minmax(250px, 1fr));grid-gap: 1rem;}

Тут описана сетка, используемая для вывода карточек. Когда имеется 4 карточки макет выглядит замечательно. Но если карточка всего одна она растянется на всё свободное пространство.


Проблема необдуманного использования auto-fit

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


Вывод карточки с изображением

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

Пользуетесь ли вы CSS-функцией minmax() в Grid-макетах?



Подробнее..

Recovery mode Спецификация классификации методологии безопасной разработки

20.11.2020 04:16:11 | Автор: admin

Аннотация


В статье представляется исследование спецификации методов, средств и методологий безопасной разработки, которая принята на территории РФ, включая перенятый опыт от зарубежных коллег, "бестпрактик", канонов и иного рода вариатив, которые применяются в настоящее время.


Исследование рассматривается со стороны коммерческого сектора и самых эффективных форматов безопасной разработки. Исследование рассматривается с применением в практической части данных вариатив и их специфик в целом, и частном формате. Целью данной статьи является передача опыта и аналитика данных применяемых методологий, методов и средств разработки в защищенном исполнении. В статье представлен анализ, соответствующий разбор действующего рынка, законодательства, в части касающейся разработки информационных систем и сред в защищенном исполнении, которая именуются также как безопасная разработка, и которая с каждым днем набирает "критическую массу" популярности в различных отраслевых компаниях из-за ужесточения рекомендаций и требований регуляторов ИБ [1].


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


Введение


Данная статья базируется на принципах и процессах автоматизации ИС и сред организации, где рассматривается вопрос со стороны личной практики как руководителя, так и разработчика. В статье представлено практическое оценочное мнение и его эффективность. Частично статья касается вопроса со стороны OWASP TOP 10, но акцент на этом будет поставлен в последующих статьях. Стоит отметить, что не рассматривается практика сертификации, аттестации, выполнении требований опытных лабораторий, проектирования ПО по ПП РФ 608, включая приказ ФСТЭК России 55 и иных документов по безопасной разработке в данном направлении. Рассматривается формат представления универсальных характеристик разработки в безопасном исполнении, автоматизации, оптимизации, масштабируемости, адаптации БП (бизнес процесс), в формате ГОСТ Р 56939.


В коммерческом секторе РФ отсутствует установленное понятие для всех ветвей организации управления организации, в сфере прямо или косвенно касающихся IT и смежных с данными подразделений, такого как: ИС (информационная система) и среда. В том числе отсутствует понимание ее классификации в целом и частном порядке. В общепринятом представлении на рынке в потребительской сфере также отсутствует понимание построения структуры и непосредственно семантики работы ИС и сред. Данный общепринятый формат объясняется следующим образом, что методы, средства и методологии разработки по созданию, оптимизации, масштабируемости, итерационной интеграции, введению в промышленную эксплуатацию каноничны, во всем промежутке времени, которые парраллелелись по различным специфичным и обособленным между собою направлениям с применением разного рода подходов и методов для их реализаций. В последствии чего стали возникать угрозы, риски и последствия инцидентов для организаций, которые занимались обработкой, хранением информации, в том числе остро возник вопрос по ОИБ (обеспечение ИБ) информации: целостности, доступности, конфиденциальности. Этот вопрос также будет разобран отдельно в следующих статьях, где стоит отметить, что важнейшим аспектом стало на сегодня ОИБ КИИ РФ, также отдельно взяло направление по оценке рисков и инцидентов, в формате СУИБ (система управления информационной безопасности) и многое другое. В последствии данных форматов и форм-факторов возник вопрос безопасной разработки в организациях, где направление стало развиваться в геометрической прогрессии и набирать экспоненциальные обороты.


Информация и ИС в безопасной разработке


Приведем ИС в автоматизированном исполнении по типам, которые имеются на сегодняшний день и в связи с которыми разрослись методы, средства и методологии их реализации в разработке, проектировании и прототипировании, а именно:


  1. Автоматизированные системы управления:
    1.1. Техническими процессами;
    1.2. Предприятием;
    1.3. Производством.
  2. Системы автоматизированного проектирования и расчета, проектирования технологических процессов;
  3. Автоматизированные системы научных исследований;
  4. Автоматизированные системы обработки, передачи данных и БД, такие как:
    4.1. Автоматизированные информационно-поисковые системы;
    4.2. Автоматизированные системы информационно-терминологического обслуживания.
  5. Автоматизированные информационные системы, представляющие из себя агрегаторы информации;
  6. Автоматизированные системы технологической подготовки производства;
  7. Автоматизированные системы контроля и испытаний;
  8. Автоматизированные комплексные системы, методологические функциональные возможности специфик предприятий;
  9. Автоматизированные информационные системы общего назначения;
  10. Автоматизированные системы научно-технологической формации, оптимизации и сведения;
  11. Автоматизированные системы нормативно-правовой документации, нормативно-методического и методологического обеспечения управления предприятием;
  12. Автоматизированные обучающие системы организации;
  13. Автоматизированные системы виртуальной реальности;
  14. Автоматизированные профессионально ориентированные системы, экономические информационные системы, такие как:
    14.1. Бухгалтерские;
    14.2. Банковские;
    14.3. Рынка ценных бумаг;
    14.4. Маркетинговые;
    14.5. Продажные.
  15. Автоматизированные информационные системы профильного назначения по БП организаций.

Исходя из приведенного формата стоит дать определение термина информация, применяемого в безопасной разработке, касательно АИС (автоматизированная информационная система) в отношении действующего законодательства РФ, а именно:


  1. Это совокупность сведений, не зависимо от их формы, которые представляют из себя формализованный или не формализованный вид сообщения в независимой и ликвидной, либо не ликвидной форме;
  2. Это система комбинирования взаимодействующих элементов, организованных и структурированных форматов для достижения определенных поставленных целей и задач [2-5].

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


Отметим, что в следствии сбора и обработки информационных данных, последующего воссоздания, воздействия и изменения информации на ней отражается политика взаимодействия процессов анализа и синтеза, представляемая обобщением организационных, технологических, технических, программно-аппаратных и информационных средств, и методов. Данные формы объединены в ИС и среды с целью их архивного сбора, хранения, обработки и выдачи информации для выполнения опосредованных функций и политик внутри, и вне организации.


С точки зрения ФЗ РФ 149 с изменениями и дополнениями, приводится следующее определение, такое как: Информационная система это совокупность содержащейся в базах данных информации и обеспечивающих ее обработку информационных технологий и технических средств. Следовательно, отметим, что ИС представляется как прикладная подсистема, которая ориентирована на сбор, хранение, поиск и обработку текстовой или фактографической информации, работающая в режиме диалога с пользователем.


Далее отметим универсальные характеристики для безопасной разработки ИС, такие как:


  1. Основное назначения функционирования: сбор, хранение и обработка информации;
  2. Нацеленность функционирования АИС под потребительские нужны и цели, при необходимости реализации: объединения и распараллеливания функциональных возможностей АИС на подразделения и структуры, непосредственно самой организации;
  3. Представление проектирования интерфейса, в том числе соотношения UI/UX, прикладного программно-аппаратного обеспечения, как принцип минимальной содержательной достаточности для представление реализации взаимодействия функционирования АИС с исключением эксплуатационной возможности НДВ (не декларированных возможностей), в целом и частном.

Общая спецификация методологий по безопасной разработки ПО


Под спецификацией методологии понимается объединение перечня средств и методов, применяющихся в специфике деятельности организации, со стороны теории и практики разработки, включая прототипирование. Методологией является формат объединения методов, средств и технологий, применяющихся во время всего жизненного цикла процесса разработки и прототипирования ПО в организации. Данный формат является совокупностью практически выработанного и действующего формата в узконаправленной специфике организации для всей программно-аппаратной части и комплекса в целом. Следовательно стоит отметить, что также под методологией безопасной разработки ИС понимается организация процессов прототипирования и выстраивания ИС и сред, таких как: обеспечения управления процессами для гарантированного выполнения ТТ, ТЗ и реорганизации процессов [6-10].


Приведем список-перечень задач для достижения обеспечения действенности методологии безопасной разработки ИС и среды, состоящей из:


  1. Представления разработки и внедрения в промышленную эксплуатацию АИС, отвечающей целевым нуждам и спецификации по политикам работы организаций, в том числе ТТ и законодательных актов РФ, а также внутренних политик организаций и предъявленных к ним требований;
  2. Предоставления гарантий выполнения требований действующих регуляторов из специфики организации и приложений на разработку и интеграцию АИС с заданными параметрами, относительно ТТ и ТЗ в течение утвержденного календарного плана, а также оговоренного бюджета на разработку. Данный формат также может рассматриваться исходя из применяемых методов разработки ПО;
  3. Представления сопровождения технической и методологической части обучения, также модификации и масштабирования системы для обеспечения соответствия целевых нужд организаций, в том числе формата поддержания S.M.A.R.T.;
  4. Представления обеспечения разработки и внедрения в промышленную эксплуатацию АИС, отвечающей требованиям оптимизированности, переносимости, масштабируемости, адаптивности;
  5. Представления возможности вариативного использования в АИС разработанных средств и методов в программно-аппаратном обеспечении, СУБД, СУИБ и тому подобное. Отметим, что данный формат зависит от политик применяемых организацией, а также ее сферы деятельности.

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


Опираясь на сводную классификацию проектной части работы Одинцова И.О.: "Профессиональное программирование. Системный подход", следует выделить:


  1. Классификацию по ядрам методологий, в которой утверждается, что имеет место быть ядру методологии с методами, которые уточняются дополнительными особенностями, а сами ядра определяются способами описания их алгоритмов, где к ним соотносятся:
    1.1. Методология императивного программирования, которая характеризуется принципом последовательного изменения состояния операнд итерационным образом, ориентированная на классическую модель Джона фон Неймана, получившей широкое практическое и теоретическое применение, с такими концепциями как:
    1.1.1. Метод последовательного изменения состояний, поддерживаемый концепцией алгоритма;
    1.1.2. Метод потокового управления на исполнение, в итерационном контроле.
    1.2. Методология объектно-ориентированного программирования (ООП), которая использует объектные декомпозиции. Отметим, что статическая структура ИС и сред описывается в терминах объектов и связей между ними, а поведение системы описывается в терминах обмена сообщениями между объектами, как в UI/UX и системном программировании. Пример: инкапсуляция, то есть абстрактный тип данных, его наследование и полиморфизм, с применение таких методов как:
    1.2.1. Метод объектно-ориентированной декомпозиции, который заключается в выделении объектов и связей между ними, поддерживающийся концепциями инкапсуляции, наследования и полиморфизма;
    1.2.2. Метод абстрактных типов данных, который лежит в основе инкапсуляции, поддерживающийся концепцией абстрагирования;
    1.2.3. Метод пересылки сообщений, который заключается в описании поведения системы в терминах обмена сообщениями между объектами, поддерживаемый концепцией сообщения.
    1.3. Методология функционального программирования как способ составления программно-аппаратной части, в которой единственным действием является вызов функции, как вариативы, то есть способа расчленения программно-аппаратной части на отдельные сектора, где имеет место быть формат введения имени для функции и задания для него вычисляющего значения, применяемый с такими методами концепций как:
    1.3.1. Метод аппликативности, где: программно-аппаратная часть есть выражение, которое подставлено из функции к аргументу, состоящему из определения функции, представляющей собой вызов от другой функций и вложенной друг в друга, поддерживается концепцией функции;
    1.3.2. Метод рекурсивного поведения, который заключается в самоповторяющемся поведении, то есть возвращающемуся к самому себе, поддерживается концепцией рекурсии;
    1.3.3. Метод настраиваемости, который заключается в порождении новых программных объектов по специальному образцу, где значения соответствующих выражений применяется как порождающая функция к параметрам образца [11].
    1.4. Методология логического программирования, где программно-аппаратная часть содержит описание проблемы в терминах фактов и логических формул, а решение проблемы ИС и среды выполняется с помощью механизмов логического вывода, где применяются такие методы и концепции как:
    1.4.1. Метод единообразия, где используется применение механизма логического доказательства ко всей программе;
    1.4.2. Метод унификации, то есть механизм сопоставления с образцом для создания и декомпозиции структур БД.
    1.5. Методология программирования с ограничениями, при котором в ПО определяется тип данных для его решения, где предметная область шифруется на соответствующие ограничения значений искомого решения, которая находится в ИС и средах. В данной методологии предлагается двухуровневая архитектура, которая интегрируется как компонент ограничения программно-аппаратного компонента. В данном формате подразумевается описательная модель вычислений, где программа содержит описание понятий и задач в формате поддерживания концепции модели.
  2. Классификацию по топологической специфике самой методологий то есть форм-факторы топологии на базе методологии со способностью выбора самих методов для получения уточненного ядра, с такими методами и концепциями как:
    2.1. Последовательная декомпозиция алгоритма решения задачи сверху вниз в итерационной детализации, которая начинается с общей задачи и обеспечивает ее структурированность, которая поддерживается концепцией алгоритма;
    2.2. Метод модульной организации частей программы, где происходит разбиение программы на специальные компоненты, которые поддерживаются концепцией модуля;
    2.3. Использование структурного кодирования, где используется кодирование трех основных управляющих конструкций, которые поддерживаются концепцией управления.
  3. Классификацию по реализационной специфике методологии, где применяется использование каждого из ядер методологии с конкретной спецификой. В данной классификации определяется некоторая организация аппаратной поддержки, такая как: централизованная или параллельная, использующаяся для централизованных архитектур;
  4. Классификацию по смешанной методологии, которая включает объединение методов нескольких методологий, таких как методологии функционального и логического программирования;
  5. Классификацию по идейной задумке Петрова В.Н.: "Технологии разработки программного обеспечения", являющейся методологией RAD (Rapid Application Development). Данная методология носит наименование методологии быстрой разработки приложений. Целевая предпосылка в области инструментальных средств быстрой разработки приложений основана на таких элементах как:
    5.1. Объёмное положение разработчиков, которые разрабатывают АИС со всей спецификой и вариацией относительно ТТ, ТЗ. Например: минимальная группа разработчиков, представляет из себя от 2 до 10 человек, для большей части вариатива, может достигать до 100 разработчиков, такая специфика прослеживается в основном в игровой индустрии;
    5.2. Тщательная проработка производственного графа работ кадрового состава организации, его оптимизации и управления над ним, так же влияющий на календарный план разработки и прототипирования. Данный граф по временным отрезкам представляется от 2 до 6 месяцев, в среднем, но все зависит от целевых нужд организации для АИС, согласно ТТ и ТЗ.

Следует отметить, что приведенные методологии позволяют обеспечить безопасную разработку в организации по всем БП, что в свою очередь облегчит функционирование организации и управления кадровым составом, а это позволить повысить рентабельность и ликвидность конечного продукта. Данные форматы являются опосредованными и целостным, где позволят предотвратить методы и меры по OWASP TOP 10, что снизит риски и шансы возникновения инцидентов, а также их расследований по семейству ISO/IEK 27000.


Принципы выбора методологий в безопасной разработке


Исходя из приведенных методологий и адекватного подхода руководящего состава можно сэкономить финансы организации, а также оптимизировать все процессы внутри и вне организации, что также относится к выполнению рекомендаций и требований регуляторов в ИБ. Если рассматривать вопрос со стороны противодействия злоумышленникам, это также позволит минимизировать все возможные риски конечного продукта, но есть обратная сторона "медали", когда "бизнес" делает упор на скорость и принимая критичные риски для продукта, что в свою очередь показывает нынешнюю практику разработки продуктов на рынке РФ. Отмечу, что иностранные коллеги привыкли ставить "во главу" ИБ и минимизацию рисков связанных с утечкой конфиденциальной информации на всех этапах жизненных циклов. По описанному формату имеются определенные принципы при выборе методологий в организациях для разработки и прототипирования ПО.


Следовательно, первоочередно стоит привести классическую (каноническую, монументальную) методологию, которая применяется исходя из наличия следующих принципов, таких как:


  1. Четкое понимание необходимого и конечного функционала, дизайна, прототипа интерфейса UI/UX и всей грядущей разработки АИС, то есть присутствует детализация специфики АИС. Стоит отметить, что она является четко регламентированной, с конечным конкретным ТЗ и ТТ, где описано: что и как должно работать;
  2. Формализованные целевые нужды конечного потребителя, тогда когда разработчики и руководящий состав, включая Заказчика представляют четкую "картину" в документированном виде, то есть: создается подробное ТЗ, где данная дефиниция регламентируется полноценным процессным состоянием каждого элемента в АИС, которая также содержит полноценное описание в цикле по специализированным алгоритмам, включая детализацию по UI/UX;
  3. Конечные требования к АИС являются стабильными, вследствие чего потребитель не дополняет условий по изменению функциональности АИС во время ее разработки, модернизации, исключая возможный формат блочного масштабирования в рамках текущих отношений;
  4. Представление итерационного процесса в формации аналитики, где проектирование и разработка ТЗ строго линейно.

Отметим, что данный формат является конечным и применимым для безопасной разработки со стороны конечных кейсов и задач, которые стоят перед разработчиками. Но у данного формата могут возникнуть специфичные проблемы при масштабировании и адаптации, которые в значительной степени будут влиять на финансы организации. Приведенная методология является популярной по рынку РФ, а также практичной при разовых работах с определенными подрядчиками, которая рассчитана на реализацию продукта в конечном виде и без формата поддержания далее. Такой формат является наиболее деструктивным для разработки долгосрочных продуктов, так как не поддерживается пролонгирование действий по ОИБ в системах и подсистемах продукта и не позволяет контролировать в полной мере риски организации, с учетом выполнения требований и рекомендаций регуляторов ИБ.


Приведем далее более гибкую адаптивную методологию, которая применяется по следующим принципам, таким как:


  1. Предоставляются не понятийные, изменчивые требования к АИС;
  2. Потребителю предоставляется разрабатываемая АИС только в общих очерках, где предполагается внесение изменений функциональности или дизайна разрабатываемой АИС посредственно в сам момент произведения процесса разработки;
  3. Представление необходимости быстрого получения первых вариаций версионности продукта и дальнейшего масштабирования исходя от нужд организации и решений Digital, в момент работающего АИС;
  4. Представление решаемой задачи посредством программно-аппаратного комплекса АИС неэффективно поддается документированию по объективным причинам;
  5. Представление реализации всех требований к проекту, вновь внесенных в том числе, которые варьируется как добавочный ликвидный запас временного отрезка для разработки и прототипирования.

Приведенная методология позволяет спрогнозировать разностороннюю вариативность при разработки и прототипировании продукта, исходя из общего формата различных пользовательских кейсов, в том числе со стороны злоумышленник по типу: "а как бы это сделал я?". Методология позволяет предопределить возможные вариативные изменения в процессе разработки и контролировать итерационность получаемого продукта, что позволяет "бизнесу" контролировать риски, в том числе со стороны финансирования организацией. Отмечу, что приведенные принципы схожи с возможностью изменения продукта исходя из метрик при анализе для "бизнеса", что позволяет в процессе разработки контролировать все жизненные циклы и процессы версионности продукта, в том числе монетизирования. Этот формат подходит для долгосрочных продуктов, которым необходимо иметь возможность постоянной монетизации и частично быть конкурентноспособными исходя из максимизации перекрытия спроса предложением [12].


Следует предоставить и разобрать самые признанные и распространённые манифесты для представления гибкой безопасной разработки ПО, таких видов как:


  1. Manifest for Agile Software Development, который был разработан с целью альтернативного решения в плане использования канонической методологии для разработки ПО и поддержания максимизации выходных параметров для продукта из ресурсов организации;
  2. SCRUM реализуемая посредством создания "резервирования свойств системы", под резервом свойств понимается набор функциональных систем, которые необходимы для реализации, а функции описываются с помощью пользовательских сценарных подходов. Отличительная черта данной методологии представляется как проведение ежедневных митингов и обсуждений, которые называются stand-up, где в ходе совещания задаются каждому разработчику вопросы, такого типа:
    2.1. Что удалось выполнить для решения той или иной итерации за день?
    2.2. Какие были проблемы в моменте реализации?
    2.3. Что и как планируется сделать за сегодняшний день?
    2.4. Как происходит интеграция и оптимизация ПО в данном интервале?
    2.5. Иные виды вопросов исходя из практики организации.
  3. Экстремальное программирование: eXtreme Programming, XP, которое обладает простотой решения, интенсивной разработкой малыми группами состава разработчиков, спецификой активного общения, где также "бизнес" напрямую вовлечён в процесс разработки;
  4. Семейство методологий Crystal разработанная Алистером Коберном, который рассматривал процесс разработки как конечную целенаправленную игру, где утверждается, что у этой игры есть следующие цели, такие как:
    4.1. Основная цель, которая заключается в успешном закачивании разработки проектной части и внедрении в промышленную эксплуатацию;
    4.2. Вспомогательная цель, которая представляется в подготовке к следующей игре, для которой необходима определенного рода документация для разработки в виде оптимизированного и адаптированного исходного кода. Данная вариатива облегчает последующее масштабирование, а также поддержку продукта и тому подобное.
  5. Адаптивная методология, под наименованием: Adaptive Software Development, ASD это альтернатива традиционного ориентирования на процессы, посредством методов управления разработкой, где результат представляется как минимизация процессов при максимальном увеличении взаимодействий между людьми. Также данная методология базируется на принципах непрерывной адаптации, где постоянные вариативные изменения в проектной части становятся нормированной практикой. В данном случае жизненный процессный цикл: "Планирование Проектирование Конструирование" изменен на более адаптивный и динамичный, такой как: "Обдумывание Взаимодействие Обучение;
  6. Функционально-ориентированная разработка, под наименованием: Feature Driven Development, FDD, где та или иная функция реализовывается за две недели, если даже сценарии использования являются достаточно малыми, которые включают пять основных процессов:
    6.1. Разработка общих моделей;
    6.2. Составление списков необходимых функций для ПО;
    6.3. Планирование исполнительных работ над функциями;
    6.4. Проектирование самих функции;
    6.5. Конструирование самих функции.

Отмечу, что данные манифесты являются применимыми, но не всегда корректно, так как имеется практика введения только положительных методов из них, а не полноценного формата контроля и управления, где руководящий состав организации считает, что это будет наиболее эффективно, нежели чем процесс полноценной интеграции конкреной системы, что приводит к не корректному взаимодействию внутри команды и процесса разработки дающего только отрицательный характер влияния на "бизнес". Для безопасной разработки ПО считаются важными данные аспекты методологии, управления, разработки и проектирования, так как они позволяют решить подавляющую часть проблем связанных с рисками и инцидентами ИБ, в том числе выполнить и перекрыть требования, и рекомендации регуляторов ИБ и обезопасить конечный продукт, а также "бизнес". В том числе учитываются специалисты по PenTest, DevSecOps и так далее, так как профильные специалисты с опытом смогу предоставить ОИБ организации [13-15].


Выводы


Стоит отметить, что разработка и проектирование ПО при безопасной разработке основывается на базе функциональности ИС и совокупных сред, спроектированных относительно конечного ТТ и ТЗ. Также не мало важно понимание руководящего состава организации в обоснованности и целях безопасной разработке, где весомым показателем в данной ситуации являются оценочные метрики бизнеса в отношении рисков, которые фокусируются на целевых функциях ПО для монетизации. Данные функции разрабатываются и интерпретируются на вывод в необходимом количественном и качественном формате сведений, посредством представленных систем и подсистем в СУИБ, а не в процессе их верификационного построения.


В статье приведены конечные форматы смежных политик ИБ на базе методологий безопасной разработки ПО, включая методов и средств управления, включая оценочные метрики бизнеса под определенными видами нагрузок, стрессовых режимов по БП, а также в виде количественных и качественных характеристик обрабатываемой информации.


В статье описаны методологии безопасной разработки, которые зависят в полной мере от применяемого режима работы в организации, включая формации управленческих методологий. Рассмотрена вариативность методологий безопасной разработки относительно ИС и сред, где достигнут результат приведения практических особенностей и политик взаимодействий между управленческими методологиями, а также методами и средствами прототипирования, разработки, что показывает в свою очередь современные представления обеспечения безопасной разработки.


Приведенные методологии безопасной разработки могут предоставить организациям увеличение прибыли, контроль версионности, предотвращение вторжений, минимизаций рисков и обеспечить доверенный уровень среди своих пользователей, что поднимет активы и пассивы организации.


P.S.: если ставите минус, прокомментируйте, пожалуйста, дабы в будущем мне не допускать подобных ошибок.


Литература

[1] Федеральный закон Об информации, информационных технологиях и защите информации 149 ФЗ от 27 июля 2006 года;
[2] ГОСТ Р 6.30-2003 Унифицированная система организационно-распорядительной документации;
[3] ГОСТ Р 7.0.8.-2013 "Делопроизводство и архивное дело Термины и определения";
[4] ГОСТ 6.10.4-84 Придание юридической силы документам на машинном носителе и машинограмме, созданным средствами вычислительной техники;
[5] ГОСТ 6.10.5-87 Унифицированные системы документации. Требования к построению формуляра-образца;
[6] Доктрина информационной безопасности;
[7] Федеральный закон от 21 июля 1993 года 5485-1О государственной тайне;
[8] О закрытом административно-территориальном образовании;
[9] Астахова Л.В. Теория информационной безопасности и методология защиты информации: методическое пособие / Л.В. Астахова. Челябинск: Изд-во ЮУрГУ, 2007. 359 с.;
[11] Юдин, Э.Г. Методология науки. Системность. Деятельность / Э.Г. Юдин. М.: Эдиториал УРСС, 1997. 246 с.;
[12] Князева Т. Отечественные системы автоматизации делопроизводства;
[13] Комарова А.В., Менщиков А.А, Коробейников А.Г. Анализ и сравнение алгоритмов электронной цифровой подписи ГОСТ Р 34.10-1994, ГОСТ Р 34.10-2001 и ГОСТ Р 34.10-2012// Вопросы кибербезопасности. 2016. 1 (19). С. 51-56;
[14] Боровский А. С., Ряполова Е. И Построение модели системы защиты в облачных технологиях на основе многоагентного подхода с использованием автоматной модели;
[15] Захаренков А.И., Бутусов И.В., Романов А.А., Степень доверенности программно-аппаратных средств как показатель качества замещения импорта // Вопросы кибербезопасности. 2017. 4 (22). С. 2-9.

Подробнее..

Recovery mode Безумная система

18.11.2020 22:19:29 | Автор: admin

Сегодня на Хабре вышла публикация о том что мы безумны. На первый взгляд, в ней просто расписываются минусы экспресс-курсов вхождения на рынок труда, к которым большинство состоявшихся специалистов действительно настроены с небезосновательным скепсисом.

Однако по пристальном рассмотрении, в публикации, под маской инженера беспокоящегося о престиже профессии, проступает оскал... безумной системы.

Рассмотрим поставленные перед нами идеи внимательнее и ответим на них. Для этого будем использовать только то, что автор сам сообщил нам.

Всё началось с желания моего хорошего друга стать крутым разработчиком
. . .
группа таких же вайтишников набрана, галера несётся в светлое будущее
. . .
слушателей пичкали информацией с онлайн курсов
. . .
каждый оценивал себя на 7-8 баллов из 10, при этом рассуждая о базовых вещах


Сперва закроем вопрос о курсах. Они действительно не дают по настоящему фундаментальных знаний в информатике. Курсы заточены по быстрому переквалифицировать человека из другой профессии на решение типичных бизнес проблем в IT, таких как переливание json-ов между сервисами и базой, и прочую знакомую нам рутину. И свою задачу курсы решают целиком.
Судите сами, может ли неудавшийся менеджер Коля, прошедший полгода курсов, запилить очередной CRUD? С ревью техлида? С четко поставленным техническим заданием?
Ответ: безусловно да, может. А большего от него и не требуется. Если же Коля, наловчившись на решениях таких задач, разовьет свои навыки, то бизнес получает даром выращенного под нужные условия специалиста с лояльностью к компании. Одни плюсы!
При этом курсы, как бы мы не смеялись с примитивности подхода, освобождают сильных специалистов для по настоящему интересных задач, оставляя скучные вещи новичкам.

С этим разобрались, что дальше насчет возмущения автора о лычках?

Cбербанк. Да, этот мастодонт принял несколько таких специалистов к себе в штат на должности разработчиков. И не абы каких, а самых настоящих старших инженеров.
. . .

МТС Банк. Данная организация предложила по результатам собеседования должность Senior разработчика ещё одному соискателю.
. . .
Senior разработчик, это человек, который может управлять другими людьми и принимать решения. Вы с ума сошли?


Давно пора понять, особенно тем кто заявляет о себе, что давно работает в IT, что само собеседование не больше чем сделка на рынке труда. Здесь нет ни четких планок как в закрытой ремесленной гильдии, ни испытаний как в секте асасинов. И это просто отлично!
Все решает умение кандидата продать свои навыки работодателю по самой выгодной цене, и желание работодателя купить подходящего разработчика повыгоднее. А дальше в действие вступают законы рынка о спросе и предложении. Как правило, поскольку 99% типовых задач это вышеупомянутый CRUD, люди после курсов с умением их писать, подходят здесь точно так-же как отучившийся в вузе пять лет и отслуживший в армии один год, по всем понятиям "правильный" специалист.
В реальности не существует фиксированных должностей сеньоров, мидлов, джунов, старших, младших и т. д. Это всего лишь шкала зарплаты, которая в разных компаниях отличается. Ни для кого не секрет, что уйдя мидлом из одной компании можно сразу же устроиться сеньором в другую, и наоборот, что некоторые компании желая сэкономить ищут по всем требованиям сеньора, но на должность мидла. А где-то всех этих детсадовских лычек вообще нет.

Но тогда чего же на самом деле боится автор? А боится он именно ...конкуренции!

Они обесценивают годы выжигания монитором глаз инженеров, которые учились и практиковались, практиковались и учились. Почему кто-то решил, что быть программистом проще пареной репы, но при этом жить дорохо бахато? А тут условный курс сделает это всё якобы за пару месяцев, а добрые собеседующие это подтвердят.

Среднестатистический выпускник ВУЗа (рассматриваем только тех кто реально учился) идёт на зарплату в 40-80к в надежде почерпнуть хоть маломальский опыт работы для дальнейшего роста, понимая что больше он не стоит. Зато самозванец на полном серьёзе претендует на место старшего инженера.

Встает логичный вопрос, если автор действительно высококлассный инженер, то как ему могут угрожать js-формошлепы и писатели CRUD-ов? Если он после своего великолепного технического образования конкурирует наравне с ними, то может быть дело все-таки именно самом в авторе, а не в некоей "системе", о которой он упоминает нам в публикации и комментариях?
А во вторых, действительно ли нужно фундаментальное техническое образование чтобы писать CRUD? Высшее образование нужно тем кто занимается наукой, серьезными расчетами, аналитикой, чтобы потом как раз ставить задачи программистам. Если автор получил высшее образование чтобы писать формочки на .NET, и теперь жалуется на конкуренцию, то при всей моей любви к .NET автор сделал не самый умный выбор и может винить только себя.

их пичкают информацией о том, как обмануть систему с непоколебимым видом.

. . .
самозванец на полном серьёзе претендует на место старшего инженера

"А что, так можно было?" Здесь автор что-то начинает понимать насчет рынка, но вместо правильных выводов включается зависть и желание "расставить всех по местам".

Почему кто-то решил, что быть программистом проще пареной репы
. . .

Тем, кто принимает решения об оффере, внимательно смотреть на опыт работы и реальные навыки, образование наконец.

Вот тут то мы и подошли к сокрытой сути статьи. Зависть автора побуждает не стать лучше и прокачать свои навыки, а закрепостить других и не лишать его возможности клепать формочки дальше.

Это та самая знакомая всем нам "система", которая уже давно принята, работает и поглотила государственные учреждения и компании. Безумный формализм, дающий людям со слабыми навыками реальной работы, быть защищенным в тепле от рыночной конкуренции, благодаря формальным критериям отбора по образованию.

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

А на рынке труда, в частных компаниях, никакой "системы" нет. Есть конкуренция и возможность добровольно выбирать где и с кем ты хочешь работать. На чьей вы стороне решать только вам. Удачного дня!

Подробнее..

Перевод Что нового в C 9.0

13.11.2020 16:21:32 | Автор: admin
В преддверии старта нового потока курса C#-разработчик представляем вашему вниманию обзор нововведений. Среди них новый метод доступа к свойству init, не позволяющий изменять свойства после инициализации, with-выражения для изменения свойств объекта прямо здесь и сейчас, записи и новые возможности сопоставления шаблонов. Подробности, конечно же, под катом.





Это официально: вышел C# 9.0! Еще в мае я написал в блоге о планах C# 9.0, а ниже обновлённая версия этого поста, соответствующая тому, что мы сделали по факту. С каждой новой версией C# мы стремимся к большей ясности и простоте в обычных ситуациях кодирования, и C# 9.0 не исключение. На этот раз особое внимание уделяется поддержке краткого и иммутабельного представления форм данных.

Свойства только для инициализации


Инициализаторы объектов весьма удивительны. Они дают клиенту якобы очень гибкий и читаемый формат для создания объекта, а также особенно хороши для создания вложенных объектов, где целое дерево объектов создаётся за один раз. Вот простой пример:

var person = new Person { FirstName = "Mads", LastName = "Torgersen" };

Инициализаторы объектов также освобождают автора типа от написания большого количества шаблонных конструкций всё, что им нужно сделать написать какие-то свойства!

public class Person{    public string? FirstName { get; set; }    public string? LastName { get; set; }}

Единственное большое ограничение на сегодня: для работы инициализаторов объектов свойства должны быть мутабельными: они функционируют, сначала вызывая конструктор объекта (по умолчанию, без параметров в данном случае), а затем присваивая его сеттерам свойств. Свойства только для инициализации исправляют ситуацию! Они вводят метод доступа init, то есть вариант метода доступа set, который может быть вызван только во время инициализации объекта:

public class Person{    public string? FirstName { get; init; }    public string? LastName { get; init; }}

При таком объявлении приведённый выше клиентский код все еще корректен, но любое последующее присвоение свойств FirstName и LastName это ошибка:

var person = new Person { FirstName = "Mads", LastName = "Nielsen" }; // OKperson.LastName = "Torgersen"; // ERROR!

Так, свойства только для инициализации защищают состояние объекта от мутаций после завершения инициализации.

Методы доступа init и поля только для чтения


Поскольку методы доступа init могут вызваться только во время инициализации, им разрешено изменять поля заключающего их класса только для чтения, точно так же, как это можно сделать в конструкторе.

public class Person{    private readonly string firstName = "<unknown>";    private readonly string lastName = "<unknown>";    public string FirstName     {         get => firstName;         init => firstName = (value ?? throw new ArgumentNullException(nameof(FirstName)));    }    public string LastName     {         get => lastName;         init => lastName = (value ?? throw new ArgumentNullException(nameof(LastName)));    }}

Записи


В основе классического ООП лежит идея о том, что объект обладает сильной идентичностью и инкапсулирует изменчивое состояние, которое развивается с течением времени. C# всегда отлично работал в этом смысле, но иногда вы хотите почти прямо противоположного, и здесь значения по умолчанию C#, как правило, мешают, делая работу крайне трудоёмкой. Если вы хотите, чтобы весь объект был неизменяемым и вел себя как значение, вам следует рассмотреть возможность его объявления как record:

public record Person{    public string? FirstName { get; init; }    public string? LastName { get; init; }}

Запись это всё еще класс, но ключевое слово record наделяет класс дополнительным поведением, которое подобно поведению значения. Вообще говоря, записи определяются своим содержанием, а не идентичностью. В этом отношении записи гораздо ближе к структурам, но все же являются ссылочными типами. Хотя записи могут быть изменяемыми, они в первую очередь созданы для лучшей поддержки неизменяемых моделей данных.

With-выражения


При работе с неизменяемыми данными общий шаблон создание новых значений из существующих для представления нового состояния. Например, если бы наша человек изменил фамилию, мы представили бы его как новый объект копию старого, за исключением фамилии. Этот метод часто называют недеструктивной мутацией. Вместо того чтобы представлять человека через какое-то время, запись представляет состояние персоны в данный момент. Чтобы поддержать этот стиль программирования, записи допускают новый вид выражений: with-выражения:

var person = new Person { FirstName = "Mads", LastName = "Nielsen" };var otherPerson = person with { LastName = "Torgersen" };

With-выражения используют синтаксис инициализатора объекта, чтобы указать, что именно отличается в новом объекте от старого объекта. Можно указать несколько свойств. Это выражение работает, фактически копируя полное состояние старого объекта в новое, а затем мутируя его в соответствии с инициализатором объекта. Это означает, что свойства должны иметь метод доступа init или set, затем изменяемый в with-выражении.

Равенство на основе значения


Все объекты наследуют виртуальный метод Equals(object) класса object. Это поведение используется как основа для статического метода Object.Equals(object, object), когда оба параметра ненулевые. Структуры переопределяют этот метод, чтобы иметь равенство на основе значений, сравнивая каждое поле структуры и рекурсивно вызывая для полей Equals. Записи делают то же самое. Это означает, что в соответствии с их значением две записи могут быть равны друг другу, не будучи одним и тем же объектом. Например, если мы снова изменим фамилию в Person:

var originalPerson = otherPerson with { LastName = "Nielsen" };

Теперь у нас будет ReferenceEquals(person, originalPerson) ложь (это не один и тот же объект), но Equals(person, originalPerson) истина (они имеют одинаковое значение). Наряду с основанным на значении Equals, есть также основанное на значении переопределение GetHashCode(), которое будет работать вместе с ним. Кроме того, записи реализуют интерфейс IEquatable <T> и перегружают операторы == и !=, Так что поведение, основанное на значениях, последовательно проявляется во всех этих различных механизмах равенства.

Равенство значений и мутабельность не всегда хорошо сочетаются. Одна из проблем заключается в том, что изменение значений может привести с течением времени к изменению результата GetHashCode(), что неудачно, когда объект хранится в хеш-таблице! Мы не запрещаем мутабельные записи, но и не поощряем их, если вы не продумали последствия!

Наследование


Записи могут наследовать от других записей:

public record Student : Person{    public int ID;}

With-выражения и равенство значений хорошо работают вместе с наследованием записей, поскольку они учитывают весь объект среды выполнения, а не только тип, под которым объект известен статически. Скажем, я создаю Student, но сохраняю его в переменной Person:

Person student = new Student { FirstName = "Mads", LastName = "Nielsen", ID = 129 };

Выражение with по-прежнему будет копировать весь объект с сохранением типа среды выполнения:

var otherStudent = student with { LastName = "Torgersen" };WriteLine(otherStudent is Student); // true

Таким же образом равенство значений гарантирует, что два объекта имеют один и тот же тип среды выполнения, а затем сравнивает все их состояния:

Person similarStudent = new Student { FirstName = "Mads", LastName = "Nielsen", ID = 130 };WriteLine(student != similarStudent); //true, since ID's are different

Позиционные записи


Иногда полезно иметь более позиционный подход к записи, при котором её содержимое задается с помощью аргументов конструктора и может извлекаться с помощью позиционной деконструкции. Вполне возможно в записи указать свой собственный конструктор и деконструктор:

public record Person {     public string FirstName { get; init; }     public string LastName { get; init; }    public Person(string firstName, string lastName)       => (FirstName, LastName) = (firstName, lastName);    public void Deconstruct(out string firstName, out string lastName)       => (firstName, lastName) = (FirstName, LastName);}

Но существует гораздо более короткий синтаксис для выражения точно того же:

public record Person(string FirstName, string LastName);

Код объявляет только инициализирующие открытые авто-свойства и конструктор, и деконструктор, так что вы можете написать:

var person = new Person("Mads", "Torgersen"); // positional constructionvar (f, l) = person;                        // positional deconstruction

Если вам не нравится автоматически сгенерированное свойство, вы можете определить свое собственное свойство с тем же именем, и сгенерированный конструктор и деконструктор просто будут использовать его. В этом случае параметр находится в области действия, которую можно использовать для инициализации. Скажем, например, вы предпочитаете, чтобы FirstName было защищенным свойством:

public record Person(string FirstName, string LastName){    protected string FirstName { get; init; } = FirstName; }

Позиционная запись может вызывать базовый конструктор следующим образом:

public record Student(string FirstName, string LastName, int ID) : Person(FirstName, LastName);

Программы верхнего уровня


Написание простой программы на C# требует значительного количества шаблонного кода:

using System;class Program{    static void Main()    {        Console.WriteLine("Hello World!");    }}

Это не только ошеломляет новичков в языке, но и загромождает код, добавляя уровни отступов. В C# 9.0 вы можете написать программу на самом верхнем уровне, вот так:

using System;Console.WriteLine("Hello World!");

Допускается любое выражение. Программа должна выполняться после using и перед любыми объявлениями типа или пространства имен в файле, и это возможно только в одном файле, точно так же, как на данный момент у вас может быть только один метод Main. Допустимы return и await. А если вы хотите получить доступ к аргументам командной строки, то args доступен как магический параметр.

using static System.Console;using System.Threading.Tasks;WriteLine(args[0]);await Task.Delay(1000);return 0;

Локальные функции это форма выражений, они также разрешены в программе верхнего уровня. Ошибкой будет вызывать их из любого места за пределами раздела выражений верхнего уровня.

Улучшено сопоставление шаблонов


В C# 9.0 добавлено несколько новых типов шаблонов. давайте рассмотрим их в контексте этого фрагмента кода из туториала по сопоставлению шаблонов:

public static decimal CalculateToll(object vehicle) =>    vehicle switch    {       ...        DeliveryTruck t when t.GrossWeightClass > 5000 => 10.00m + 5.00m,        DeliveryTruck t when t.GrossWeightClass < 3000 => 10.00m - 2.00m,        DeliveryTruck _ => 10.00m,        _ => throw new ArgumentException("Not a known vehicle type", nameof(vehicle))    };

Простой шаблон типа


Сейчас, когда тип совпадает, шаблон типа должен объявлять идентификатор даже если это пустой идентификатор _, как в DeliveryTruck _ выше. Но в C# 9.0 можно просто написать тип:

DeliveryTruck => 10.00m,

Шаблоны отношений


В C# 9.0 введены шаблоны, соответствующие операторам отношений <, <= и так далее. Так что теперь вы можете записать часть DeliveryTruck вышеуказанного шаблона как вложенное выражение switch:

DeliveryTruck t when t.GrossWeightClass switch{    > 5000 => 10.00m + 5.00m,    < 3000 => 10.00m - 2.00m,    _ => 10.00m,},

Здесь > 5000 и < 3000 шаблон отношений.

Логические шаблоны


Наконец, вы можете комбинировать шаблоны с логическими операторами and, or и not, записанными в виде слов, чтобы избежать путаницы с операторами в выражениях. Например, случаи вложенного switch выше можно расположить в порядке возрастания вот так:

DeliveryTruck t when t.GrossWeightClass switch{    < 3000 => 10.00m - 2.00m,    >= 3000 and <= 5000 => 10.00m,    > 5000 => 10.00m + 5.00m,},

В середине and используется для объединения двух реляционных паттернов и формирования паттерна, представляющего интервал. Обычно шаблон not применяется к шаблону констант null, как в not null. Например, мы можем разделить обработку неизвестных случаев в зависимости от того, являются ли они null:

not null => throw new ArgumentException($"Not a known vehicle type: {vehicle}", nameof(vehicle)),null => throw new ArgumentNullException(nameof(vehicle))

Также not удобен в содержащих is-выражения условиях if вместо громоздких двойных скобок:

if (!(e is Customer)) { ... }

Можно написать только это:

if (e is not Customer) { ... }

Фактически в таком выражении is not мы позволяем вам как-то назвать Customer для дальнейшего использования:

if (e is not Customer c) { throw ... } // if this branch throws or returns...var n = c.FirstName; // ... c is definitely assigned here

Выражения new и целевой тип


Целевой тип это термин, который мы употребляем, когда выражение получает свой тип из контекста того места, где оно используется. Например, null и лямбда-выражения всегда целевые. Выражения new в C# всегда требовали явного указания типа (кроме неявно типизированных выражений массива). В C # 9.0 можно не указывать тип, если есть чёткий тип, которому присваивается выражение.

Point p = new (3, 5);

Это особенно удобно, когда у вас много повторений, например, в массиве или инициализаторе объекта:

Point[] ps = { new (1, 2), new (5, 2), new (5, -3), new (1, -3) }; 

Ковариантные return


Иногда полезно указать, что переопределение метода в производном классе имеет более конкретный возвращаемый тип, чем объявление в базовом типе. C# 9.0 позволяет это сделать:

abstract class Animal{    public abstract Food GetFood();    ...}class Tiger : Animal{    public override Meat GetFood() => ...;}

И многое другое


Узнать о полном наборе функций C# 9.0 можно в документации Что нового в C# 9.0.
А с промокодом HABR можно получить дополнительные 10 % к скидке, указанной на баннере.

image



Рекомендуемые статьи


Подробнее..

Много эпитетов, ни слова о команде и другие ошибки в составлении вакансии

14.11.2020 14:23:20 | Автор: admin

В IT большой спрос на специалистов, а их поиск стоит дорого (десятки и сотни тысяч рублей). От хорошо составленной и привлекательной вакансии зависит как долго компания будет искать человека и насколько качественные кадры будут откликаться на предложения.

В идеале, хорошая вакансия отвечает на все вопросы кандидата: чем занимается компания, кого они ищут и зачем, что надо делать, с кем и с чем придется работать, условия работы и сколько платят. К сожалению, часто вакансии составлены так, что не отвечают и на половину вопросов и даже скорее отпугивают. Рассмотрим типичные ошибки, чтобы их не допускать.

Эта статья подойдет HR, рекрутерам и всем, кто выполняет полностью или частично их функции. Также будет полезна тимлидам, техлидам или CTO, когда возникнет потребность в разработчиках.

Слишком много эпитетов или слишком мало информации

Здесь два варианта событий.

Ноль информации

Иногда встречаются скудные описания, из которых непонятно что за компания ищет человека. Для молодых организаций это нормально рассказать особо нечего. Но бывает так, что у организации нет ни сайта, ни телефона и никак ее не найти. Уже хорошо, если есть почта на gmail.com.

Такое бываетТакое бывает

В этом случае вакансия не удостаивается внимания людей, которые знают себе цену. Скорее всего, откликнутся новички, для которых важен сам факт опыта работы и особо не важно, где его получать (не всегда, конечно).

Как исправить. Просто добавьте больше информации и контакты.

Неуместная высокопарность. Если выбирать между описанием истории компании и информацией о том, что предложат кандидатам, где они будут работать, над чем работать и сколько получать, то скорее выбору будет в пользу второго. Поэтому, например, разрабатывать новое, поддерживать старое и интегрировать кажется нечётким описанием. Хотелось бы большего.

Хорошо, если компания публичная, корпоративные правила требуют добавлять большие описания истории, ничего не поделаешь. Но бахвальство выглядит неуместно для малоизвестных. Например, ниже приходится продираться сквозь миссии, описание краудлендинга (зачем-то) и ценности, чтобы добраться до двух строк обязанностей.

Как исправить. Первое решение сократить лишнее. Преимущество небольших компаний в гибкости, так зачем утяжелять текст вакансии?

Второе разместить блок с описанием официального дилера вниз, а требования, обязанности и условия расписать подробнее. Например, Wargaming крупная и заметная компания по разработке игр (чего уж там). Но они сначала пишут то, что важно кандидатам, а уже внизу опциональное описание компании.

Третье решение убрать высокопарные обороты про многолетнюю историю упорного труда (они выглядят шаблонно, как молодая динамичная компания). Вместо них можно добавить конкретики: какие проекты реализованы, над чем сейчас работают. Например, так.

Или так.

Трудно понять кто нужен и зачем

Переходим к блоку обязанностей. Сюда кандидат смотрит, чтобы понять, какие задачи надо решать до того, как он попадёт на собеседование. Обычно работу выбирают не меньше, чем на год-два, поэтому кандидатам не безразлично чем они будут заниматься всё это время. И это явно не поддержка существующих и развитие новых проектов, под которыми может скрываться что угодно.

Как исправить. Банально, но добавить подробностей, например, разработка какого именно функционала в каком именно ПО. Примерно так.

Разносторонние обязанности также настораживают.

Настораживает также, что не требуется опыта работыНастораживает также, что не требуется опыта работы

Как исправить. Не навешивать лишних и противоположных обязанностей, например, по разработке приложений и администрированию. Если бэкенд, то это бэкенд, а не бэкенд, немного приложений и еще сверстать вон там надо.

Старайтесь не писать банальные требования к кандидатам. Знания и опыт понятия расплывчатые. Обязанности программиста-разработчика явно не могут уместиться в одну строку из шести слов, но постоянно встречаются вакансии в которой требуются знания (подставьте слово). Этой болезнью страдают как фермерские хозяйства, так и серьезные IT-компании.

Как исправить. Писать подробнее: что подразумеваете под опытом и знаниями. Например, под пониманием принципов ООП подразумеваются шаблоны проектирования, принципы объектно-ориентированного дизайна и TDD или достаточно знать разницу между абстрактным классом и интерфейсом?

Да, всё это можно узнать на собеседовании. Но зачем терять время своё и кандидатов? Опытный и уверенный в себе специалист просто не будет тратить на вакансию время, просто потому что HR или рекрутер не удосужился потратить своё, чтобы описать вакансию подробнее.

Ни слова о команде

Разработчикам не безразлично с кем они будут работать и как. Поэтому всегда смущают вакансии, где ищут супергероев или разбрасываются высокими словами.

По описанию кажется, что планы большие, но пока ничего не готово и придётся выстраивать процессы лично.

Как исправить. Описывать коллектив приземленнее. Например, что суперпрофессионалы означает, что коллеги пишут статьи в блог, выступают на конференциях и еще успевают работать.

В идеале, описание команды это отдельный блок. Мало кто (даже из крупных компаний) так заморачивается. Но зато понятно, что ищут человека, а не функцию.

Условия работы

Обычно этот пункт описывают достаточно подробно.

Но часто описания стандартные: офис, 5/2, соблюдение ПК. Чем они отличаются от остальных непонятно.

Как исправить. Добавить нюансы и изюминку. Перед написанием вакансии определитесь, что действительно может привлечь кандидата. Даже самые обычные и стандартные условия можно описать подробнее.

Некоторые работодатели прямо говорят о важных вопросах, например, сверхурочных.

Об этом важно писать. Если у в компании частые переработки, нужно предупредить. Скрывать нет смысла: хорошо, если кандидат узнает об этом на собеседовании, а если на испытательном сроке?Не все готовы к переработкам, но зато откликнутся те, кого это не смущает.

Иногда в вакансиях приукрашивают: супер-офис класса А, печеньки, чай и галактические проекты. Но на деле оказывается, что офис в промзоне, а печеньки и чай будут, если скинуться в начале месяца.

Как исправить. Иногда кажется, что в компании вообще ничего особенного нет и остаётся только приврать. Ну нет и нет лучше ничего не писать, чем врать.

Итого по пунктам

Как составлять вакансию для IT-специалиста? Подходить со здравым смыслом:

  • Добавлять описание компании, но без высокопарности и хвастовства.

  • Чётче формулировать требования и обязанности. Писать код или поддерживать старые проекты и создавать новые звучит также, как работать работу.

  • Подробнее описывать команду: сколько человек, какая специализация у каждого, кто руководитель, как друг с другом общаются.

  • Описывать условия как есть, чтобы через неделю не искать нового разработчика. Печеньки не удержат.

На этом все, надеемся, что статья была полезной. Если не хотите отсеивать вакансии из которых непонятно кто нужен и зачем, заходите на headz.io. Наша модерация пропускает только подробные вакансии и выясняет у работодателя всё, что понадобится разработчикам, а алгоритм подберёт подходящие по уровню и стеку.

Подробнее..

Из песочницы Вы безумны, остановитесь пока не поздно

18.11.2020 14:04:51 | Автор: admin
image

Привет Хабр! Всего каких-то пару лет назад на страницах нашего любимого ресурса красовались вдохновляющие статьи успешного успеха, как вчерашний сантехник / таксист / сварщик / сутенёр успешно интегрировался в IT сообщество и начал зарабатывать 100500$ в секунду левой пяткой. Здорово, не правда ли? Но всё ли так радужно с этими историями с точки зрения действующих разработчиков? Прошу под кат.


Ты кто такой?


Позвольте представиться. Я являюсь обычным .NET разработчиком в рядовой государственной компании, основным способом заработка которой является разработка программного обеспечения. За спиной оконченный с отличием %City%ГТУ где-то за МКАДом, служба в рядах Вооружённых Сил России, и мечтания о светлом будущем. Звёзд с неба не хватаю и на роль нового Короля разработки не претендую (привет Фил).

Как и многие, я познакомился с программированием ещё в школьные годы. Правда, в силу возраста, я начинал с Pascal в красивой IDE. Потом были поделки калькуляторов всех мастей на Delphi, которые даже использовались при решении домашних задач по математике. Потом учёба в университете, великий и могучий C++, понимание что всё тлен и путешествие в чудесный мир C# с LINQ и асинхронностью.

Вы резонно можете спросить, к чему эта биография? Постараюсь объяснить кратко. Когда в силу не зависящих от меня обстоятельств необходимо было решить, какую профессию получать, я твёрдо был уверен, что программирование это моё, поэтому колебаний было минимум. Я помню бессонные ночи не останавливающегося кодинга, которые вставляли не по-детски. Помню книги, знания из которых я поглощал медленно и размеренно, на 30 страниц в день сотня-другая строк кода. Потом переезд в северную столицу, волнительные первые собеседования, первые офферы и понимание своих слабых сторон. Как мне кажется, подобный путь проходило большинство разработчиков.

Но что происходит сейчас в мире информационных технологий? На каждом углу реклама курсов, которые сделают из тебя настоящего программиста за 21 день с гарантированным трудоустройство сразу на позицию %Language% Middle Developer. Разговоры о том, что программировать уже нечего, достаточно только объединить готовые решение, заботливо скомпилировав и отправив в удалённый репозиторий. Разглагольствования некоторых медийных личностей, утверждающих что программисты больше не нужны (вы поняли о ком я), на фоне разговоров о безумных зарплатах в IT. И даже крупные компании, такие как Google, вносят сумбур. Какое-то время назад я посмеивался над этим, но уже не до смеха

Так больше продолжаться не может


Всё началось с желания моего хорошего друга стать крутым разработчиком, пускай это будет Алексей. Алексей амбициозный парень в возрасте 25+, окончивший 11 классов и не доучившийся в техникуме на технической специальности, не имеющей с IT ничего общего. Я, как единственный знакомый программист, был привлечён консультантом по новому для него миру. Главный вопрос был с чего начать и что делать. Я конечно же начал советовать читать умные книги, но этот способ не подошёл. Алексею не хватало усидчивости вчитываться в каждое слово, поэтому абзацы и даже целые главы читались по диагонали без единой попытки перевести код со страниц в IDE с красивой подсветкой. Если человек не видит результат, он начинает искать серебряную пулю. Так вышло и в этой ситуации. Был оплачен доступ к популярному онлайн ресурсу, предлагающему задачи для решения в онлайн компиляторе. Но роста не было, как оказалось не было понимания базовых вещей. Алексей не опускал руки и упорно продолжал долбиться в закрытые двери, при этом моей виной было непонимание этого аспекта, и последовавшая за этим фатальная ошибка предложение поехать туда, где водятся программисты, в надежде устроиться стажёром. Приехав в большой город, Алексей тут же приступил к поиску работы. Но к большому сожалению (этого следовало ожидать), предложений по работе не поступало. Через какое-то время Алексей решил, что нужно что-то более действенное, и начал искать новую серебряную пулю. Этой серебряной пулей оказался один из многочисленных онлайн курсов по программированию.

Без имён и фамилий


По правде сказать, я отнёсся к этой затее с большим недоверием. Но контракт уже подписан, группа таких же вайтишников набрана, галера несётся в светлое будущее. И так, что из себя представляют эти курсы. Кратко подготовка будущих специалистов к собеседованию, с попытками направить человека в нужные темы в надежде дать понимание глубоких механизмов языка. Да, именно языка. В понимании местной публики программиста программистом делает знание языка и его фреймворков, не более. Тут стоит оговориться о слушателях этих курсов. Я был свидетелем знакомства группы. Как и ожидалось, люди достаточно разношерстные, разных возрастов (были очень немолодые), полов и профессий, 90% из которых о языках программирования услышали только вчера. Но всех их объединяло одно желание стать Middle разработчиком с заработной платой от 100 000 рублей по окончании курсов. Достаточно амбициозно и смешно, подумал я про себя. Судя по лёгкой улыбке на лице владельца курсов на том конце монитора при озвучивании желаний, уверен, он думал точно так же.

Прошло время, слушателей пичкали информацией с онлайн курсов, расположенных на популярных платформах (интересно, авторское право соблюдено?), каждому дали наставника, который должен был учить и строго экзаменовать. В конце курсов предполагалась практика на боевом проекте длительностью несколько недель, для закрепления знаний. Пришло время выпуска, мне было интересно чем это всё закончится. И тут мне в руки попало видео с закрытого разговора владельца курсов, который опрашивал бывших выпускников на предмет их текущих успехов. И тут я, мягко говоря, очень удивился. Для некоторых соискателей, нет ничего сложного в собеседованиях, по их словам. Максимум что могут спросить по их мнению, это, например, что такое коллекция и что такое список. На вопрос о сложных темах, таких как многопоточность, отвечают, что это сложно и проще просто выучить, как я понимаю речь идёт о заучивании определений. Team Lead по их мнению, это этакий менеджер, который тупо получает деньги и что-то там рассказывает команде, поэтому почему бы и не стать им сразу. Духовный лидер же подначивает кандидатов в IT: Нужно торговаться на собеседованиях, 150 не деньги.

Стоит оговориться, что на вопрос оценки их знаний, каждый оценивал себя на 7-8 баллов из 10, при этому рассуждая о базовых вещах. Синдром самозванца не про них.

Мошенничество или лайфхак?


Мне был интересен вопрос, каким образом будут позиционировать людей после курсов, обладающих нулевым опытом, но жаждущих позиции Middle разработчика? Всё просто, им нарисовали год опыта работы в компании! Да, вот так просто. Гугл ничего не знает об этой организации, от слова совсем. Ни единого упоминания, количество найденных страниц всего одна, ведущая на какой-то агрегатор случайных слов. Ну да ладно, настоящего самозванца точно выявят на собеседовании, не зря на Хабре столько статей от HRов и разработчиков с историями о том, как правильно собеседовать. К огромному сожалению, оказалось что всё это не более чем трёп о сферическом коне в вакууме. Уж простите.

Я не могу обойтись без громких имён компаний, корпоративные блоги которых, в том числе, присутствуют на ресурсе. По заявлению выпустившихся вайтишников, они устроились туда на позиции разработчиков. Дальше пойдёт критика, целью которой является попытка заставить руководство корпораций внимательно присмотреться к своему штату и кандидатам.

Сбербанк. Да, этот мастодонт принял несколько таких специалистов к себе в штат на должности разработчиков. И не абы каких, а самых настоящих старших инженеров. Это в то время, когда появляются статьи о сливах данных пользователей и гневных заявлений что пропадают деньги с карточек, лежащих на верхней полке антресоли в книге с двойным дном. Я всегда думал на этот счёт, что там работают высококлассные спецы, блог которых я читал и восхищался, а деньги пропадают только из-за неграмотности пользователей. Возможно это так и есть, но кредит доверия потерян.

МТС Банк. Данная организация предложила по результатам собеседования должность Senior разработчика ещё одному соискателю. Хорошо, Middle разработчик это хоть и самостоятельная боевая единица, но за ним всё равно приглядывают старшие коллеги. Но Senior разработчик, это человек, который может управлять другими людьми и принимать решения. Вы с ума сошли? Какие решения может принимать человек, который понятия не имеет что такое настоящая работа программистом, да ещё и учить других жизни?

И ряд других компаний.

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

Чем это плохо?


Качество кадров. Это главное. От качества кадров зависит качество продукта, качество кодовой базы, безопасность, производительность. Это взгляд со стороны разработчика. Со стороны бизнеса, это скорость разработки, потому что для неопытного разработчика все задачи будут в новинку, соответственно решения задач будут занимать гораздо больше времени, и не только своего. Это очевидно. Заберись такой бриллиант повыше, и весь этот поток /*цензура*/ кода польётся в продакшн без код ревью на радость пользователям и людям, которые будут это поддерживать в будущем.

А какое решение?


Понять сочувствующим, что отрасль не резиновая, перестав показывать всем вокруг свою состоятельность и крутость голубых кровей.

Очнуться всем тем, кто подписывается под рекламой подобного. Уверен, эти люди рассуждают о том, что они вне конкуренции. Опытные разработчики, прошедшие через огонь и медные трубы. Только вот один вопрос: зачем платить такие деньги опытному программисту, если то же самое сделает вайтишник, но гораздо дешевле. И плевать что решение будет, мягко говоря, не оптимальное, и даже не факт, что безопасное. Про best practice я вообще молчу.

Тем, кто принимает решения об оффере, внимательно смотреть на опыт работы и реальные навыки, образование наконец. Резюме этих людей не содержат ссылки на репозитории с их pet projects, потому что их нет. За то пестрят названиями самых актуальных инструментов, используемых в разработке. Всё по методичкам от умных HR, как сделать классное резюме. Уличить в обмане реально сложно, потому что их пичкают информацией о том, как обмануть систему с непоколебимым видом. При этом им придумывают легенду о предыдущем месте работы с предположительными вопросами от интервьюера и вариантами ответа.

Для тех, до кого не доходит и они продолжают рекламировать курсы для тех, кто хочет войтивайти игнорировать их деятельность. Люди рубят сук на котором сидят, и ещё больше раздувают этот пузырь, который рано или поздно лопнет. Производимый контент этих людей чаще всего реально полезный и качественно сделанный, что нивелируется способом монетизации.

Вместо заключения


Скорее всего моя позиция по курсам, со стороны выглядит как не прикрытая ненависть и агрессия. Так и есть после того, как я это увидел изнутри. Но это относится к курсам готовящим вайтишников. Для курсов переподготовки уже действующих специалистов только за, хоть сам и не пользовался их услугами. Я знаю несколько реально крутых вайтишников, которые действительно много читали и изучали, годами программировали, и наконец нашли своё место под солнцем. Это вызывает только уважение. Для тех кто хочет за пару месяцев стать программистом только потому что платят, увы, к таким я отношусь негативно. Они обесценивают годы выжигания монитором глаз инженеров, которые учились и практиковались, практиковались и учились. Почему кто-то решил, что быть программистом проще пареной репы, но при этом жить дорохо бахато? А тут условный курс сделает это всё якобы за пару месяцев, а добрые собеседующие это подтвердят.

Среднестатистический выпускник ВУЗа (рассматриваем только тех кто реально учился) идёт на зарплату в 40-80к в надежде почерпнуть хоть маломальский опыт работы для дальнейшего роста, понимая что больше он не стоит. За то самозванец на полном серьёзе претендует на место старшего инженера. Если это правила игры я их не понимаю. Не забывайте, это бизнес, который зарабатывает на том, что актуально. Если завтра будет актуально быть мясником, появятся соответствующие курсы как грибы после дождя, и вероятнее всего с теми же наставниками.

Рекомендация владельцам курсов: предлагаю открыть курсы подготовки хирургов длительностью 3 месяца, не зависимо от образования. Пользуйтесь. Там же ничего сложно, бери в руку скальпель и режь, а другие хирурги покажут как надо уже в больнице, ведь неделя практики даёт те же знания что и год университета, давно известный факт. Но это уже другая история
Подробнее..

Перевод Финальные классы в PHP, Java и других языках

23.11.2020 12:04:01 | Автор: admin
Использовать финальные классы или не использовать финальные классы? Вот в чём вопрос. А еще в том, когда и как это делать правильно.



Почему стоит использовать финальные классы


Максимальное уменьшение области видимости


Когда вы видите у класса префикс final, вы понимаете, что этот класс не может быть расширен любым другим, что не только делает его более читаемым, но и позволяет вам быть уверенным в том, что область действия логики ограничена этим конкретным классом.

Поощрение подхода композиция вместо наследования


Принцип открытости/закрытости гласит: класс должен быть открыт для расширения, но закрыт для изменений.

Если по какой-либо причине (хорошо понимая саму причину) вы решите использовать наследование, тогда просто удалите ключевое слово final, и всё готово.

Если вы по умолчанию не можете расширять класс (потому что он финальный), вы помогаете себе, думая прежде всего об использовании композиции вместо наследования.

Почему этот класс не финальный?


Если мы стремимся к композиции, а не к наследованию, то мы должны стараться избегать наследования, насколько это возможно, и использовать его только тогда, когда это действительно необходимо. Наследование в ООП часто используется неправильно.

Заблуждения


Когда мы в первый раз изучали ООП, мы приводили классический пример наследования. Тем не менее, когда Алан Кей создал Smalltalk, наследование не было его главной концепцией. Основной концепцией был обмен сообщениями, то есть вы можете отправлять сообщения объектам, а они инкапсулируют в себе данные и логику. Вы можете изменять их поведение, используя различные объекты, что на самом деле является композицией. Но в итоге концепция наследования настолько популярна, что в конечном счёте затмевает композицию.

Выгоды от использования финальных классов


  • Понятные контракты. Использование интерфейсов заставит вас мыслить в терминах связей между объектами.
  • Изолированные блоки кода без побочных эффектов. Внедрение интерфейсов в качестве зависимостей устранит все неприятные побочные эффекты кода, над которым вы работаете.
  • Тестируемость. Подмена на фиктивные зависимости чрезвычайно проста, если они являются интерфейсами.
  • Низкая и управляемая сложность. Поскольку всё изолировано, вам не нужно беспокоиться о волнообразных изменениях. Это значительно снижает сложность вашего кода.
  • Низкая когнитивная нагрузка. С уменьшением сложности ваш мозг сможет сосредоточиться на самом важном.
  • Гибкость кода. Удаляя любую ненужную связь, вы сможете рефакторить намного легче, чем раньше.
  • Уверенность в себе. Возможность тестировать свой код изолированно не оставляет сомнений в правильности его изменения.

Композиция вместо наследования


  • Если вы чувствуете необходимость перенастроить объект, изменить части алгоритма или переписать часть реализации, подумайте о создании нового класса вместо переопределения существующего.
  • Допустим, вам нужно создать иерархию классов, где подклассы являются подходящими заменами своего родительского класса. Это была бы классическая ситуация, когда вы всё ещё можете подумать о наследовании. Однако результат может быть даже лучше, если вы наследуетесь не от конкретных родительских классов, а от абстрактных интерфейсов.

Что вам следует начать делать [вместо того что вы делаете сейчас]


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

Итого: Интерфейсы Финальные классы Композиция
Подробнее..

Грозовая туча помогает разрешать конфликты

18.11.2020 14:04:51 | Автор: admin

В основе многих наших действий или бездействий лежат неразрешенные конфликты.

Конфликтами пронизана вся наша жизнь, каждый день. Казалось бы, мы должны к ним давно уже привыкнуть и осознав это предпринимать соответствующие действия, но нет, обычно мы предпочитаем оставить всё в подвешенном нерешенном состоянии.

Такова природа человека конфликты кажутся совершенно неразрешимыми, а когда часто к ним добавляется еще и подсознательная боязнь неудач, которая есть почти у всех, то конфликт превращается в настоящую беду.

Элияху Голдрат, создатель Теории Ограничений, говорил, что конфликтов на самом не существует и мир живет в гармонии. Просто никто не пытается разобраться в причинах конфликтной ситуации.

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

Многие практики Теории Ограничений утверждают, что Грозовая туча работает.

Давайте проверим и попробуем применить разработанный Голдратом алгоритм к нескольким типичным конфликтам из области ИТ. Посмотрим, как это может нам помочь.

Конфликт: Подрядчик не начинает разработку до тех пор, пока не составит полное ТЗ

Многие ИТшники либо сами работали на фрилансе, либо заказывали у кого-то работу. Это действительно страшно начнешь работу, она растянется и в результате выйдешь в минус. Денег не получишь, да еще и должен будешь. Придется либо доделывать проект бесконечное количество времени, либо бросать. Никто этого не хочет.

Ровно такое же опасение возникает и у аккаунтов-менеджеров при миллионных заказах. Фрилансер может и потерпит какое-то количество времени без денег, а вот компании-подрядчику придется все это время платить зарплату сотрудникам из своих средств, что иногда может быть очень разорительным.

Часто подрядчики делают ТЗ для того, чтобы не вкладывать в разработку кратное количество ресурсов, N раз переписывая код. Т.е. у подрядчиков зачастую есть уверенность в том, что им заплатят деньги, но при этом есть и четкое понимание, что полученные средства окупят лишь маленькую долю от фактических затрат в отсутствие ТЗ.

Как быть? Ведь заказчик хочет начать работу прямо сейчас и готов бросить всё, если Вы не начнете, и уйти к другому исполнителю. Конечно, ему нет никакого смысла ждать пока подрядчик напишет ТЗ (если вообще напишет). Это потеря его времени и, на самом деле, упущенной выгоды.

Какое же решение принять подрядчику?

Уже сейчас, из самой формулировки конфликта очевидно, что действие Начать работу только после составления ТЗ вызвано отсутствием гарантии получения денег от заказчика.

Т.е. причиной действия Начать работу только после составления ТЗ является необходимость Обеспечить гарантию получения денег.

Теперь рассмотрим вторую часть конфликта. Почему заказчик настаивает на том, чтобы начать работу прямо сейчас, без ТЗ? Что он хочет с помощью этого избежать?

Очевидно, что он не хочет затягивать создание своего продукта. Он хочет получить его как можно быстрее и считает, что составление ТЗ только всё затянет.

Т.е. причиной действия Начать работу прямо сейчас, без ТЗ является необходимость Быстрее создать продукт.

Но при это оба, и заказчик и подрядчик хотят создать это продукт. Т.е. у них общая цель Создать продукт

Каждому пункту конфликта принято давать буквенное название: A, B, C, D, D.

Итак, конфликт полностью сформулирован. Это так называемая диаграмма Грозовая туча.

Проведём быструю проверку. Условие C должно конфликтовать с действием D, а условие B должно конфликтовать с действием D. Всё верно, они конфликтуют, значит формулировка конфликта составлена правильно.

Для того, чтобы разогнать эту грозовую тучу необходимо разобраться в причинах конфликта. Пропишем причины (предпосылки), почему действия D и D необходимы для обеспечения условий B и C.

Найти их проще, если перевернуть формулировку условия на обратную и подумать при каких условиях это обратное условие сбудется. Это и будет наши опасения и причины необходимости соблюдения прямой формы условия. Смысл от этого не изменится, а формулировать причины станет легче.

Было: Быстрее создать продукт. Обратная формулировка: Старт разработки бесконечно затягивается.

Было: Обеспечить гарантию получения денег. Обратная: Деньги за сделанную работу не оплачивают

B-D (при каких условиях старт разработки бесконечно затягивается?):

- Составление ТЗ занимает много времени

- Согласование ТЗ занимает еще больше времени в разы больше. Это огромные простои

- Есть понимание, что конечный продукт не будет в итоге таким как в ТЗ, его всё равно придется менять, т.к. люди не провидцы и не предсказатели

- ТЗ часто используют в качестве давления на заказчика и есть риск не получить продукт, который я хочу

- После получения денег подрядчик часто исчезает бросив продукт недоделанным. По сути, это просто выброс денег в мусор

C-D (причины, почему деньги за сделанную работу не выплачиваются):

- Типична ситуация, когда заказчик не знает, чего хочет и заставляет бесконечно доделывать продукт при этом не оплачивая сделанную работу до момента полного завершения проекта. А этот момент обычно сильно затягивается

- Подрядчик вынужден выплачивать зарплату разработчикам из своих средств, чтобы они доделывали продукт. Это выводит проект в минус.

- Обычно разработка сильно затягивается из-за все новых и новых требований заказчика. Он никак не может остановиться

- Объем работ должен быть ограничен, чтобы заказ окупился

Как не трудно заметить, конфликт очень серьезный. Как найти решение, которое полностью его устраняет?

Э.Голдрат говорит, что суть конфликта скрывается в деталях. Его причиной может быть либо неправильная (ложная) предпосылка, либо непонимание предпосылок, на которых основывает своё видение противоположная сторона.

Можно придумать такое решение, которое либо вскрывает неверную предпосылку, либо удовлетворяет сразу всем предпосылкам всех сторон конфликта (причем полностью, а не частично).

Давайте подумаем За предпосылки сомневаться не приходится это то, что в действительности часто происходит в реальности. Значит надо придумывать что-то иное.

Очевидно, что подрядчик прав в том, что объем работ должен быть ограничен, чтобы заказ окупился. Заказ ведь заключается на фиксированную сумму, в которую включен ограниченный объем работ.

Каким образом можно совместить ограниченный объем работ и быстрый старт разработки? Очевидно, что чем меньше объем работы, тем точнее его предсказать и тем быстрее начать и проще сделать.

Решение напрашивается само собой договариваться не на огромный проект, а на небольшие куски/итерации, которые быстро делаются и быстро оплачиваются.

Если проект большой и хочется зафиксировать в нём большую сумму, то можно заключить рамочное соглашение и оговорить, что деньги оплачиваются не в конце, а по частям, по мере разработки и сдачи итераций небольшого объема.

И, кстати, не все компании-подрядчики требуют деньги на счет прямо сейчас. Кому-то достаточно просто официально подписанных бумаг и соглашения, что этап работы закрыт и обязателен к оплате.

Давайте посмотрим, что случится с предпосылками конфликта, если применить найденное решение.

Опасение заказчика

- Составление ТЗ занимает много времени

На короткую итерацию ТЗ составить быстро, а то и вовсе можно обойтись без него заменив макетами экранов.

- Согласование ТЗ занимает еще больше времени в разы больше. Это огромные простои

На небольшой объем и согласование-то не особо требуется, т.к. согласующие очень быстро могут со всем ознакомиться и дать свой ок.

- Есть понимание, что конечный продукт в итоге будет не таким как в ТЗ, его всё равно придется менять, т.к. люди не провидцы и не предсказатели

Реализация небольшими партиями позволит менять продукт не в самом конце (как обычно делают), а в начале и по ходу разработки. В результате в самом конце доработок либо вообще нет, либо они минимальны.

- ТЗ часто используют в качестве давления на заказчика и есть риск не получить продукт, который я хочу

У подрядчика отпадает необходимость давить на заказчика, т.к. он уже получил свои деньги.

- После получения денег подрядчик часто исчезает, бросив продукт недоделанным. По сути, это просто выброс денег в мусор

Получая деньги небольшими партиями подрядчик, наоборот, заинтересован продолжать сотрудничество. Он готово делать продукт хоть бесконечно, лишь бы ему за это платили.

Бонус для заказчика теперь можно смело нанимать разработчиков давая им небольшой объем работ для проверки и рискуя только небольшой суммой.

Опасения подрядчика

- Типична ситуация, когда заказчик не знает, чего хочет и заставляет бесконечно доделывать продукт, при этом не оплачивая сделанную работу до момента полного завершения проекта. А этот момент обычно сильно затягивается

При небольшом объеме разработки заказчик совершенно точно определиться с тем, что он хочет видеть в очередной итерации. Он будет вынужден. Ему это очень просто будет сделать, т.к. объем небольшой.

- Подрядчик вынужден оплачивать зарплату разработчикам, чтобы они доделывали продукт. Это выводит проект в минус.

При оплате за небольшие итерации деньги будут на счете подрядчика не дожидаясь полного завершения проекта. Это в разы выгоднее.

- Обычно разработка сильно затягивается из-за все новых и новых требований заказчика. Он никак не может остановиться

Новые требования заказчика становятся даже выгодными. Подрядчику выгодно, чтобы они появлялись.

- Объем работ должен быть ограничен, чтобы заказ окупился

Он однозначно ограничен.

Да! Решение полностью исключает все опасения! Грозовая туча работает!

Внесём дополнительные осложнения для подрядчика

Представим, что подрядчик заключил договор с большой компанией, в условиях которой прописана полная оплата после полной реализации и приемки проекта. Деньги большие, поэтому подрядчик взялся за проект.

Для больших компаний (особенно с госучастием) зачастую неприемлемы условия договоров без конечного фактического результата, требуемого бюджетом/вышестоящими органами.

Как закрыть опасения? Как сделать так, чтобы оплата осуществлялась по небольшим итерациям в проекте, котором УЖЕ чётко прописано, что оплата только в конце?

Давайте составим грозовую тучу и посмотрим на неё внимательно.

Причиной возникновения конфликта часто становятся неверные (ложные) предпосылки. Для их определения Голдрат в своих выступлениях (можно найти на Youtube) рекомендует задавать предельно простой вопрос: Really?! (Да ну?!)

Действительно ли внутреннему аудиту большой компании нужно показывать работающий продукт? Точно?! Вы действительно уверены, что нужно доводить готовый продукт до приёмо-сдаточных испытаний? Вы уверены?!

По умолчанию да, но что, если пойти и объяснить сотрудникам внутреннего аудита чем хорош подход с короткими итерациями?

Стоило бы поставить под сомнение, что ситуацию нельзя изменить. Заказчику, как было показано ранее, тоже выгодно работать по итерациям. Там же не глупые люди сидят.

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

Конечно, есть шанс, что ничего не случится, но тогда ситуация не будет отличаться от текущей и подрядчик ничего не теряет. Ну а что, если внутренний аудит пойдет навстречу?..

Приведенные выше примеры это ситуации из реальной жизни, с которыми автору статьи периодически приходилось и приходится сталкиваться.

Переход разработки на короткие итерации действительно помогает. Помогает и заказчикам и подрядчикам. К сожалению, далеко не всегда им пользуются. И даже там, где уже вовсю работает Scrum (разработка короткими итерациями) внутри компании, для работы с внешними подрядчиками часто применяют стандартные контракты водопадной разработки.

Но это отдельная история.

Целью статьи было рассказать Вам о том, что с помощью Грозовой тучи можно найти очень интересные, часто прорывные решения.

Вероятно, изложенный в статье способ применения диаграммы Грозовая туча покажется Вам полезным. Было бы очень интересно увидеть Ваши примеры её использования.

На Ваши комментарии автор с удовольствием ответит и примет к сведению Ваши замечания.

P.S. История, рассказанная одним из рецензентов после прочтения статьи.

Просишь пример? Пожалуйста.

Приехал из Чехии наш русский предприниматель весьма далекий от ИТ, но хороший бизнесмен. Ему нужно было срочно найти специалиста, который бы переработал где-то приобретенную, но не совсем подходящую ИС на Oracle.

В Чехии он не нашел подходящих вариантов. Договор с фирмами его не устраивал как раз по причине того, что надо было разрабатывать ТЗ и расписывать работы на весь договор, платить сразу приличные деньги, а он четко даже не представлял, что ему, собственно, нужно.

При разговоре стало понятно, что одним специалистом-универсалом там явно не обойтись, нужно было как минимум три разных специалиста. Помню его унылую физиономию и вздох: Да, видно придется сдаваться.

Тогда я предложил ему следующую форму договора: он платит за работу двух специалистов в течение трех месяцев, мы поставляем именно тех специалистов, которые нужны в данный период разработки. План работ на первое время очевиден, к концу трехмесячного срока будет готов план на следующий период или даже несколько (планирование методом набегающей волны).

Такой вариант заказчика устроил, т.к. он мог контролировать объем и нужность работ, а также видеть справедливость траты его денег. В таком режиме он продолжает работать уже несколько лет

Подробнее..

Кто сказал мяу бывший разработчик из Amazon создал переводчик с кошачьего

10.11.2020 12:07:03 | Автор: admin

Технический менеджер компании Akvelon Хавьер Санчес создал приложение переводчик с кошачьего. По его мнению, MeowTalk поможет выйти отношениям с питомцами на новый уровень.

Приложение основано на машинном обучении и опирается на большие данные. Принцип работы программы напоминает приложение Shazam, которое помогает узнать исполнителя песни в реальном времени по части мелодии. В Meow Talk также одним касанием активируется кнопка дешифровщика.


Через несколько секунд выдается вероятное значение мяуканья.


С предложенным вариантом можно согласиться или выбрать другой вероятный оттенок перевода из всплывающего списка.


С помощью программы можно выяснить, желает ли питомец есть, испытывает ли он любовь, боль или просто зовет маму. Разработчик обещает, что пользовательский ввод обучит приложение понимать конкретного кота.

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

По мнению Санчеса, приложение будет полезно для установления тесного контакта хозяев с кошками, полностью меняя культуру их общения.
Мнение эксперта

В естественной среде обитания кошки общаются между собой в основном с помощью языка тела (позы, взгляды, положение хвоста, ушей и т.д.) и запахов (метки). Вокальные сигналы используют минимально. Но в процессе массового одомашнивания кошки начали подстраиваться под человека, и теперь звуки занимают значительную часть их лексикона.

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

Юлия Кавелич (фелинолог, зоопсихолог, заводчик мейн-кунов)
Хавьер Санчес ранее участвовал в разработке платформы машинного обучения Алексы, персонального голосового ассистента от Amazon. В компании Джефа Безоса он трудился полтора года. Программист объясняет, что работа по созданию приложения еще один шанс для него осуществить взаимодействие и исследовать голосовые технологии, пусть и не совсем однозначные и даже урчащие.

К проекту в Akvelon относятся вполне серьезно. Один из аргументов усилившиеся связи между питомцами и их владельцами во время пандемии и локдауна. В этот период многие были ограничены в перемещениях и встречах с людьми, проводя большую часть времени наедине с домашними животными. Поэтому решение give your cats a voice выглядит вполне адекватным.

На сайте Amazon в разделе навыков Novelty and humor Алексы можно увидеть скилл Meow Talk для разговоров с кошками. Возможно, время перейти от шуток к реальности.

Подробнее..

Как оптимизировать работу аэропортов с помощью машинного обучения

05.11.2020 18:21:17 | Автор: admin

Как научиться применять методы машинного обучения, поставить задачу, выбрать модель, найти данные для её обучения и упростить работу аэропортов за пару месяцев, обнаружив связь между биржевыми индексами и дневным количеством пассажиров? Проще, чем может показаться.

Наша команда более десяти лет разрабатывает приложения, которые управляют работой крупнейших аэропортов: Франкфурт, Дублин, Манила, Джакарта, Майами, Пекин. Аэропорты используют приложения для оптимального управления ресурсами, организации работы и контроля за потоками информации аэропортов, координации расписания рейсов.

Аэропорты, использующие наши приложенияАэропорты, использующие наши приложения

Крупные аэропорты обслуживают сотни тысяч пассажиров, тысячи тонн грузов и сотни самолётов в день. Так, за 2019 год аэропорт Франкфурта обслужил более 70 миллионов пассажиров, более двух миллионов тонн грузов и более пятисот тысяч самолётов. То есть, в день аэропорт обслуживал порядка 190 тысяч пассажиров, более пяти тысяч тонн грузов, более тысячи самолётов. Такие показатели связаны с огромным количеством человеческих и материальных ресурсов. Для типичного пассажира внутренняя работа аэропорта представляется чёрным ящиком. Мы проходим набор рутинных процедур: собственную регистрацию, регистрацию или получение багажа, трансфер до самолёта и полёт. Кажется, всё достаточно просто, однако, это лишь вершина айсберга. Каждый видимый нами процесс включает в себя десятки подпроцессов, в которых задействованы сотни людей. Логично, что задачей менеджеров аэропорта является оптимизация процессов для снижения затрат на привлечение сотрудников и других ресурсов. Мы попытались решить это задачу.

Идея звучит достаточно просто: Если вы знаете, сколько пассажиров обслуживает аэропорт в конкретный день вы знаете, какой набор ресурсов для этого потребуется: сколько сотрудников должно выйти на работу, сколько автобусов будет использовано для доставки пассажиров к самолётам, сколько горючего этим автобусам потребуется. Таким образом, задача сводится к определению количества пассажиров в аэропорту в конкретный день в будущем. Это позволит менеджменту привлекать заранее известное количество ресурсов, а значит, точнее рассчитывать расходы. Поставленная задача является задачей регрессии, в которой необходимо установить зависимость количества пассажиров от других параметров.

Следующим шагом стал подбор параметров, которые могли бы оказать влияние на количество пассажиров. Первыми в голову пришли характеристики искомого дня:

  • Время года. Туристические сезоны отчётливо прослеживаются и вносят существенный вклад в количество пассажиров. В авиации принято использовать астрономические сезоны, поэтому и мы опирались именно на них.

  • День недели. От дня недели зависит как количество туристических рейсов, так и количество рабочих перелётов.

  • Праздник и его характер. Информация о том, является ли день праздничным, продолжительность праздника, характер праздника (религиозный или общественный). Череда праздников, как правило общественных, может мотивировать людей совершать перелёты.

Важнейшим же шагом на пути к решению задачи стало предположение о влияние экономической ситуации в стране на пассажиропоток. А именно о том, что экономической рост стимулирует пассажиропоток, и между двумя этими величинами существует зависимость. Для динамической оценки состояния экономики мы решили использовать DAX, а также уровень занятости населения.

DAX

Deutscher Aktienindex German stock index важнейший фондовый индекс Германии. Индекс вычисляется как среднее взвешенное по капитализации значение цен акций крупнейших акционерных компаний Германии.

Ежедневные значения DAX, а также процент работающих граждан Германии были взяты с Yahoo Finance. Для обучения модели использовались данные о ежедневном количестве пассажиров в аэропорте за 2018 и 2019 год, взятые на kaggle. Сезонность, день недели и характер праздничности дня мы посчитали вручную. На подготовительном этапе были использованы исключительно открытые источники, данные из которых были сгруппированы в единый датасет.

Влияние состояния экономики на пассажиропоток не носит молниеносный характер. Должно пройти время для того, чтобы люди ощутили изменения на себе. Поэтому судить о текущем дне по текущему DAX не совсем справедливо. Нужно было найти оптимальный сдвиг DAX от текущей даты по величине коэффициента корреляции между DAX и количеством пассажиров. Такой поиск обозначил 5 различных сдвигов со схожим результатом: от 15 до 19 дней относительно текущей даты.

Следующим шагом был выбор используемой модели. Нашей целью было получение минимального значения MAE, которое говорило бы об ошибке в (количество людей / день). Были испробованы различные варианты разбиения датасета на тест и трейн, различные сдвиги DAX относительно текущего дня, различные модели и их параметры. Конкретно были рассмотрены Linear Regressor, Random Forest, Gradient Boosting, SGDRegressor. Параметры для моделей подбирались с помощью GridSearchCV.

MAE

Mean Average Error

Расчёт ошибки и точности предсказания происходил отдельно для каждого сдвига DAX для каждой модели. Результатом каждого прогона были графики как на картинке ниже. На каждом из таких графиков изображено реальное количества пассажиров из данных теста (синим) и график предсказаний модели на данных того же тестового датасета (оранжевым). Для уверенности в правильном обучении модели и недопущении её переобучения также сравниваются показатели MAE для теста и трейна. Их близость говорит о корректности обучения. Решение о компетентности модели и выборе данных принимались на основе MAE, однако привычный показатель score модели для каждого набора (сдвиг DAX + модель) тоже принимался во внимание.

Графики для Linear Regression со сдвигом DAX в 15 дней Графики для Linear Regression со сдвигом DAX в 15 дней

При построении всех возможных комбинаций стало понятно, что с использованием любой модели наилучший результат достигается при использовании DAX со сдвигом в 15 дней. Как говорилось выше, при выборе модели, мы ориентировались на минимальность MAE. На основе этого критерия была выбрана модель Gradient Boosting с ошибкой в 297 человек. Это означает, что ошибка в день в среднем составляет вместительность одного самолёта.

Следующим шагом стало сохранение обученной модели с помощью pickle, использование REST API для взаимодействия с моделью и создание Docker-образа. После контейнеризации получаем готовое приложение, которое отвечает на вопрос о количестве пассажиров в аэропорту через 15 дней, исходя из DAX, уровня безработицы и информации о том, является ли день праздничным. Данное решение может быть встроено в инфраструктуру любого аэропорта при наличии данных о пассажиропотоке в прошлом. Необходимо лишь переобучить модель на данных конкретного аэропорта.

Это был первый проект подобного рода для нашей команды. Приложение вот-вот начнёт использоваться заказчиками, но мы уже строим планы по его дальнейшему усовершенствованию и хотим продолжить использовать машинное обучение для решения других задач. Если у вас есть вопросы, пишите в комментариях, буду рад ответить на них.

Подробнее..

Как мы контроллер управления элементами наружной рекламы делали (часть 2)

15.11.2020 02:05:31 | Автор: admin

В предыдущей части статьи мы рассмотрели этап начала проектирования системы. Сейчас я хочу рассказать какое устройство получилось в итоге.



Часть 1
Часть 2

В обсуждение первой части был затронут вопрос измерения напряжения и тока. Поэтому я решил осветить его более подробно. Как я уже писал ранее, датчиками напряжения и тока у нас в схеме являются трансформаторы. Для измерения напряжения используется миниатюрный трансик BV 201 0145, а для датчика тока AC-1020:



С них снимаются напряжения, которые оцифровываются встроенным в микроконтроллер АЦП. Аналоговая часть показана ниже:



Датчик тока нагружается на резистор R3. Стабилитрон VD3 защищает от резких всплесков напряжения, вызванных короткими бросками тока. Резисторы R2, R4 задают нулевую точку в районе 1,8В. Аналогично сделано для трансформатора напряжения. Только там делитель на резисторах R8 и R10, т.к. трансформатор в нашем случае выдаёт номинальное напряжение 12 В.

Оцифровку мы осуществляем с частотой 1000 Гц в течение 200 мс. На основе полученных значений рассчитываем RMS. Быстрый расчёт квадратов значений мы производим прямо в прерывании. После накопления 200 выборок уже в основном цикле программы осуществляется окончательный расчёт с использованием чисел с плавающей точкой.

Для чего нужно измерение RMS и как его лучше сделать хорошо описано вот в этой статье.

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

  • Набор из трёх галогеновых ламп мощностью по 500 Вт
  • Датчик тока, описанный выше
  • Электросчётчик Энергомера СЕ102М
  • Преобразователь USB-RS-485
  • Автоматический выключатель

Счётчик мы используем в качестве образцового измерителя напряжения в сети и тока нагрузок. Модель СЕ102М очень удобна тем, что, во-первых, подключается всего двумя проводами к преобразователю USB-RS-485 (внутри счётчика имеется собственный преобразователь питания), а, во-вторых, не требует для считывания данных ввода серийного номера. Вроде мелочи, но удобства в пользовании счётчиком они прибавляют.

Протокол обмена хорошо описан в руководстве от производителя. Так что сложностей с программной реализацией не возникало.

Кстати, по счётчикам можно отдельную небольшую статью написать. В своё время я с ними плотно работал, в итоге в некоторых наших устройствах реализована поддержка четырёх популярных моделей: Инкотекс-СК Меркурий 206, Энергомера СЕ102, Энергомера СЕ102М и IEK STAR 104/1.

Общий вид стенда получился такой:



Для автоматизации была разработана несложная программа, которая считывает данные со счётчика, управляем встроенными реле контроллера и автоматически подбирает коэффициенты для измерителя тока и напряжения:

Обычно мы используем штрих-коды для серийных номеров наших устройств. Их очень удобно вводить при помощи сканера штрих-кодов:



Но в данном случае девайс был заказным, и заказчик попросил выполнить серийник просто в виде крупных цифр на лицевой панели.

Программа по итогу калибровки сохраняет все данные в нашей внутренней системе. Там записывается кто, когда что проверял и соответствующий список параметров. Самые важные это серийный номер и MAC-адрес.

Кстати, по поводу MAC-адресов. Мы покупаем их в виде микросхем 24AA025E48-I/SN производства Microchip. При оптовой закупке они обходятся недорого, при этом очень удобны в использовании. MAC-адрес считывается по интерфейсу I2C.

Теперь что касается связи с сервером. На начало разработки основной функционал у нас уже имелся. Это несложный Web-сервис, написанный на ASP.net и отдельная серверная программа для обмена данными с железом. Каждый контроллер раз в минуту передаёт информационный пакет по протоколу UDP. Серверное ПО разбирает его, сохраняет данные в базе (с прореживанием до раза в час) и дополнительно запоминает внешний IP-адрес и порт, с которого пришёл пакет. Это нужно для управления контроллером с сервера.

Так как фактически 100% устройств расположены за NAT, то требуется учитывать некоторые особенности. Основная из них заключается в том, что некоторые NATы имеет малый тайм-аут для выделения внешнего порта клиенту (менее минуты). Процент таких по нашей статистике не очень большой, но это в любом случае приводит к необходимости уменьшения интервала отправки данных мониторинга от контроллера на сервер для поддержания выделенного порта.

Сразу напишу почему мы используем именно UDP-, а не TCP-соединение, хотя наше устройство, естественно, имеет реализацию обоих протоколов. Выбор UDP обосновывается всего лишь простотой использования и малыми вычислительными затратами как со стороны контроллера, так и со стороны сервера. Да, он не гарантирует доставку пакетов данных, но нужно понимать, что это легко реализуется протоколом более высокого уровня, который работает поверх UDP. Кроме того, при передаче данных мониторинга потеря нескольких пакетов в сутки абсолютна несущественна, особенно учитывая, что при сохранении в базу мы их всё равно прореживаем и сохраняем данные только раз в час. А вот при удалённом управлении контроллером, например, при включении/выключении реле в ручном режиме, работает система запрос-ответ и осуществляется несколько попыток отправки команды.

Помимо этого через сервер у нас реализовано удалённое обновление прошивок контроллеров. Оно так же работает по UDP. Правда обновление работает в полуавтоматическом режиме. Всё таки нехорошо запускать его в автомате в произвольный момент, так как это может привести к проблема в работе у конечных пользователей. Представьте как они удивятся, если средь бела дня Ethernet-реле отключить у них какую-то нагрузку и перезапуститься :-)

В заключение хочу сказать, за последние два года мы произвели почти тысячу таких устройств. Все она находятся в онлайне. Ещё около двух тысяч других контроллеров также постоянно общаются с нашим сервером. В целом всё работает достаточно устойчиво. Хотя функционал мы, конечно, постоянно расширяем. Например, недавно мы выпустили моб. приложение для удалённого управления нашими устройствами через Интернет. Но о нём напиши как-нибудь в следующий раз
Подробнее..

Kingston Design-In новые опции для бизнеса

18.11.2020 16:23:31 | Автор: admin


Для решения вопроса адаптации продукции под потребности заказчика, компания Kington приняла решение развить направление Design-in SSD. Процесс интеграции оборудования еще никогда не был столь прост. Смотрим, что придумала компания Kingston

Технический прогресс не стоит на месте и ранее принятые стратегии развития IT инфраструктуры перестают работать ввиду ограниченности интерфейсов. Старые стандарты сменяются новыми, частично теряя совместимость, но при этом предоставляя большие возможности масштабирования. Особенно этот острый вопрос сильно затрагивает область систем хранения данных.

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

Поэтому пропадает возможность найти то самое нужное только тебе решение в рознице, которое будет полностью отвечать всем необходимым запросам по производительности и совместимости. А если и находятся несколько претендентов, то либо с ненужным дополнительным функционалом, либо со слишком высокой ценой. Чтобы оградить заказчика от всех этих проблем, компания Kingston придумала программу Design-in SSD, способная удовлетворить практические любые потребности.

Ключевые моменты Design-in SSD




IT сфера, как и многие другие сферы производства и разработки рано или поздно достигают пика развития. На этом этапе важно понимать не только то, что вы производите, но и каким боком Вы повернуты к клиенту. Kingston не боится вести прямой диалог с заказчиком, поэтому открывает для себя новое направление программу Design-in в сфере производства SSD накопителей. Ведь любой потребитель, особенно интегратор, проектировщик или разработчик, хочет получать наибыстрейший отклик от производителя на проблемные аспекты внедрения и поддержки оборудования.

Кастомизация

Готовые шаблоны с артикулами, разработанные в соответствии с широкими спектрами потребностей клиентов. Вследствие чего, заказчику можно выбрать предварительный набор функций и свойств SSD заранее проверенный специалистами Kingston. По требованию проекта изменению могут быть подвергнуты различные параметры SSD, начиная от номера SKU, заканчивая прошивкой под выносливость SSD или наоборот, максимальной скорости. Можно менять SMART атрибуты, пороговые значения, название модели, изготовление маркировки и упаковки накопителя.



Одним из примеров удачной кастомизации в рознице для РФ является SSD HyperX Fury 3D. Продукт, изначально планируемый только для рынка стран СНГ, но сейчас нашел себе место в массовом производстве и продается во многих странах. Более подробно с ним можно ознакомиться здесь. Данный проект появился исключительно благодаря запросам ритейлеров и поставщиков, а те учитывали требования пользователей в бюджетном сегмента SSD, в котором нет лишних опций, но его производительность должна соответствовать средним игрокам на рынке. Соответственно его специально сделали для рынка СНГ, но из-за отличного соотношения цены и скорости Kingston HyperX Fury 3D пришелся по нраву остальному миру.

Учет требования заказчика

Для этого адаптируется прошивка накопителя, выбирается фиксированная конфигурация связки контроллера, микросхем NAND, p/n и т.п. Особенное внимание уделяется совместимости SSD для конкретного проекта или используемого оборудования. Так как некоторые производители отвергают любую возможность использования сторонних комплектующих в своих системах. На этом этапе прошивка получает специальные записи для определения статуса свой-чужой в системе. А после интеграции SSD обновить firmware такого SSD общераспространяемой прошивкой невозможно.

Вашу персонализированную и адаптированную прошивку будут поддерживать специалисты Kingston, и каждый релиз проверять на совместимость. Помимо фактической проверки в обязательном порядке будут внесены записи в пакет документов к SSD, иными словами, каждый шаг документируется.



Перед массовой поставкой заказчик получит экземпляры SSD для проверки на своем оборудовании. Процесс напрямую поддерживают специалисты Kingston для внесения корректировок либо улучшения совместимости и производительности оборудования. Благодаря прямому взаимодействию с командой инженеров Kingston любые проблемы будут решаться в кратчайшие сроки.

Помимо вышеперечисленных шагов программы для SSD Kingston, прошедших этап кастомизации под заказчика, остается 3-летняя гарантия производителя и бесплатная техническая поддержка. Время полного цикла согласования занимает менее 3 месяцев, производство еще несколько недель. Минимальное количество не регламентировано.



Кастомизация форм-фактора и размеров. Сама программа имеет достаточно широкий диапазон возможностей, в том числе заказ SSD практически любых интерфейсов (М.2, mSATA) и SSD малых емкостей.
2,5 дюймы 7 мм SATA;
M.2 SATA 2280 и 2242;
mSATA;
M.2 NVMe 2230 и 2280;
BGA чипы NVMe 11x13 мм с контроллером.

Сегменты рынка для программы Design-in SSD

Естественно, обычному покупателю пользоваться возможностями Design-in SSD не обязательно, да и просто не нужно. Она рассчитана на специализированные области применения:



Перечень применения будет только расширяться, потому как областей для SSD на данный момент не мало, а в будущем они только будут расти. И под каждую задачу разумнее адаптировать железо персонально. Так, достигается максимальная совместимость и производительность.

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

Начальное количество SSD для старта работы по Design-in рассматривается из любого требуемого количества, хоть от одной штуки, особенно если речь идёт об уже готовых решениях Kingston. Конечно, в зависимости от сложности кастомизации, цена за единицу может варьироваться, и в каких-то случаях гораздо выгоднее снизить стоимость единицы товара за счет увеличения количества.

В данных таблицах представлены все модели в полном объеме, 64, 128 и 256, включая довольно экзотические 64 ГБ NVMe SSD и форм-факторы 2230 и 2242, которые сложно найти в розничных магазинах.





План производства SSD Kingston


Начиная с октября 2020 года Kingston внедряет в свои SSD BiCS4 3D TLC NAND память взамен BiCS3 3D TLC NAND производства Kioxia. Но у заказчиков программы Design-in SSD остается возможность использования BiCS3 3D TLC NAND и получать от производителя твердотельные накопители малого объема.


Важным отличием Kingston остается поддержка и производство 4 типов SATA SSD: 2,5 дюйма, M.2 2242, M2 2280 и mSATA.


NVMe линейка получит нового поставщика NAND памяти. В портфеле NVMe носителей появятся бюджетные модели с контроллером, где оперативная память компьютера будет выделяться для кеша SSD.

Выводы




Kingston это не просто производитель SSD, компания представила программу Design-in SDD и превратилась в надежного партнера по интеграции. Если вам не хочется тратить время на подбор комплектующих для своего проекта, быть уверенным в 100% совместимости, оперативно получать поддержку, то программа Kingston Design-in SSD позволяет:

Выбирать среди накопителей SSD SATA и NVMe, созданных для проектировщиков и разработчиков систем;

Получать фиксированный BOM и Firmware, обеспечивающие стабильную работу в рамках вашего проекта, а все изменения и обновления контролируются и документируются для ведения отчетности и понимания какие были внесены исправления и улучшения;

Один из этапов программы предусматривает инженерную поддержку при проектировании, производстве и внедрении;

Kingston позаботится о предварительной квалификации перед массовым производством, плюс вы получите глобальную поддержку Kingston может координировать свои действия с ODM или CM по всему миру, если это необходимо;

Гарантия трехлетняя ограниченная гарантия и бесплатная техническая поддержка;
В совокупности Kingston предлагает полное решение под ключ на основе выпускаемых SSD для внедрения в проекты любой сложности, с последующей поддержкой.

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

Подробнее о программе Design-in.

Предлагаем читателям оставить свои комментарии о том, каких опций им не хватает в SSD сегодня, чего бы они добавили, а самые оригинальные посты будут вознаграждены подарками Kingston.

Для получения дополнительной информации о продукции Kingston обращайтесь на официальный сайт компании.
Подробнее..

Из песочницы Помощник в проведении технического интервью и совместный кодинг

20.11.2020 16:08:20 | Автор: admin


Сколько мне довелось пройти технических собеседований на фронтенд разработчика, столько разных способов и инструментов на них использовали интервьюеры.

Чат в одном месте, созвон в другом, кодинг в третьем. Ой, что-то не работает этот сервис, а расшарь-ка экран. Ой, код решения отвалился, ну напиши снова И без того стрессовая ситуация для кандидата превращается в неприятную карусель.

И по такому же сценарию выстроена структура интервью чаще хаос, перескакивания с темы на тему.

Я пытаюсь сделать простой, удобный и бесплатный сервис для технического собеседования, как для интервьюера, так и для кандидата. Всё в одном месте для всех: заметки, отчет и прочие фичи для интервьюера, и удобный редактор, полноценный и красивый фидбек на почту и т.п. для кандидата.

Чтобы всё было предсказуемо и по стандартам, ведь столько статей о правильном проведении интервью написано на хабре. Есть чем вдохновляться.

Назвал его Meet2Code.

Что есть на данный момент:

  • Анкета на каждый раздел собеседования. Задачи, вопросы и пункты знаний всё можно оценить, засечь время и оставить заметку.





  • Совместный кодинг в реальном времени. Удобная работа с задачами из списка: в один клик отправляешь в редактор, замеряешь время, оцениваешь.





  • Создание шаблонов для интервью разделы, вопросы, навыки, задачи.





  • Ну и собственно, отчёт: общий и по каждому разделу, задаче или вопросу.





Над текущим функционалом ещё нужно работать, но, я надеюсь, уже понятна основная концепция. Пока нет никакого бэка для хранения данных, всё храню просто в локалсторадж браузера. Под мобильные тоже пока сделал простой адаптив, для просмотра не вырви глаз, дизайн не продумывал.

Если кому-то интересно, пишу сервис на React, TypeScript, MobX.

Почему решил написать статью


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

Над чем я работаю сейчас и какие фичи планирую внедрять:

  • Личный кабинет хотелось бы видеть как можно раньше.
  • Прокачать редактор кода
  • Отчёт о результате понятный и простой.
  • Запуск кода (пока только js и библиотеки).
  • Сгенерировать красивый фидбек на email кандидату.
  • Создание библиотеки вопросов, задач, навыков, чтобы можно было шаблоны собирать из готовых компонентов, в первую очередь, кастомных.
  • Удобство создания и работы с шаблоном (сортировка, редактирование элементов).
  • Добавлять метки о важности, времени, сложности и т.п. к вопросам/задачам.
  • Интеграция со своими сервисами и со сторонними (например, hh).
  • И в последнюю очередь, звонки из браузера.

и дальше ещё много мощных фич, колонка в трелло с ними очень высокая.

Конечно же под всё это дело в первых рядах будут задачи по созданию API.

В общем, попробуйте этот инструмент, если он вам покажется полезным. Я дождусь обратной связи, сделаю выводы и в случае положительной реакции форсированно буду воплощать свои фантазии и ваши рекомендации/пожелания.

А пока я буду допиливать текущее состояние.

beta.meet2code.com
Подробнее..

5accessibilityинструментов вChromeDevTools

29.11.2020 14:18:58 | Автор: admin

Введение

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

Небольшой дисклеймер, я знаю, что многие из вас активно пользуютсяDevTools, тем не менее, я напомню, что для открытияDevToolsудобно использовать сочетание клавишCmd+Shift+ C /Ctrl+Shift+ C.

Accessibilityinspector.

Помимо DOM браузер строитAccessibilityTree(AOM,AccessibilityObjectModel) или Дерево специальных возможностей (чуть подробнее тут). СоответственноAccessibilityinspectorпозволяет просматривать информацию в этом дереве, аналогично тому, как вы просматриваете структуру DOMдевера, во вкладкеElements.

По большей части AOM содержит информацию из ARIA иroleатрибутов, именно с помощью них программы экранного доступа пытаются определить предназначение DOM элемента.

Найти этот и инструмент можно во вкладкеElements, в дополнительной вкладкеAccessibility.

Accessibilityinspector в DevToolsAccessibilityinspector в DevTools

Эмулятор плохого зрения.

С помощьюDevToolsвы можете понять, как видят ваш сайт пользователи с различными нарушениями зрения.

Для того чтобы включить эмуляцию проблем со зрением откройтеDevTools, кликните на три точки на верхней панели. В выпадающем списке выберете менюMoretools, дальшеRendering. В низу откроется дополнительная панель, прокрутите ее до самого конца, там будетпукт Emulatevisiondeficiencies.

Результат работы эмулятора плохого зренияРезультат работы эмулятора плохого зрения

На момент написания статьиDevToolsэмулирует следующие нарушения:

  • Нечеткое зрение

  • Протанопияищи цветовая слепота (помните такие тесты в ГИБДД где среди кружочков необходимо увидеть цифру?)

  • Дейтеранопия - частичная цветовая слепота, в основном к зеленому цвету.

  • Тританопия- частичная цветовая слепота обычно в синежёлтых, фиолетовокрасных цветов.

  • Ахроматопсия илидальтонизм - полная цветовая слепота

Я думаю, очевидно, что данный список не в полной мере покрываетпроблеммысо зрением, возникающие у отдельных людей, тем не менее размещая текст на каком-то цветном фоне, стоит проверить его читабельность..

Lighthouseумеет находить очевидные проблемы на вашем сайте, в том числе и проблемы с доступностью. Поскольку в данной статье мы рассматриваем только доступность, то отключим все остальное и протестируемХабрна наличие проблем сAccessibility.

Настройка и результат работы Lighthouse на сайте habr.comНастройка и результат работы Lighthouse на сайте habr.com

Lighthouseпроверяет такие вещи как:

  • ARIA - атрибуты

  • ROLE - атрибуты

  • Контраст

  • Langатрибуты в HTML

  • Tabindexна формах

  • Наличие описания в атрибутахalt

  • И многое другое

Если посмотреть отчет, то основные проблемы в том, что не все ссылки и кнопки подписаны, а на некоторых картинках отсутствует описание в атрибутеalt. Это значит, что незрячий пользователь будет слышать что-то вроде ссылка, кнопка,изображение, без понимания предназначения данного элемента на странице

Контрастность

Когда речь заходит о доступности контраст очень важен. Это можно понять, если применить эмуляцию не четкого зрения.

Чтобы понять, насколько элемент выделяется от фона вDevToolsесть специальный инструмент, который может проанализировать контраст определенного элемента.

Что узнатькоэфициентконтрастности какого-либо элемента необходимо открытьDevTools, затем выберете любой текстовый элемент, и найдите CSS свойствоcolor

Инструмент измерения контрастности в DevToolsИнструмент измерения контрастности в DevTools

Если посмотреть на скриншот, то можно выделить три основных показателя:

  • текущее значение контраста

  • Минимально допустимое значение контраста (АА)

  • Достаточно значение контраста (ААА)

Inspectelementtooltip

Последний инструмент в сегодняшнем списке, в целом дублирует функциивыше описанныхинструментов. И самое главное, если вы открываетеDevToolsс помощью горячих клавиш, то он сразу активен. Так же его можно активировать кликнув по кнопке спинктограммойстрелки в верхней панелиDevTools.

InspectelementtooltipInspectelementtooltip

ВInspectelementtooltipвыводится сводная информация о выделенном элементе, в том числе общая информация по доступности.

Заключение

Готовя статью, я наткнулся на цитату, которая отлично передает мое отношение к вопросу доступности сайтов

Доступность не обязана сразу быть идеальной, она просто должна быть немного лучше, чем вчера.Леони Уотсон на FronteersConf

Спасибо за внимание, надеюсь, эти инструменты помогут вам сделать ваши проекты чуть доступнее.

Подробнее..

Категории

Последние комментарии

© 2006-2020, personeltest.ru