Це з ним трапилось починаючи з версіі 10. Можна скачати стару версію і вона працьє нормально. discussion.evernote.com/...​legacy-version-625-until
Для Android я використовую теж стару версію 8.13.3, скачав десь apk файл.

дякую, виглядає непогано, може перейду на ньго

evernote legacy, але можливо перейду на іншу систему, бо починаючи з версії 10 розробка evernote пішла не туди.

блін, тут на ДОУ російскою, срочно перекладемо

А в нас англійскою мовою сайт, мені цей закон не подобається

Знайшли кого цитувати — псевдобанкіра Фурсу

Из английской википедии: Рейд Хоффман — исполнительный председатель LinkedIn. В декабре 2018 года New York Times опубликовала статью, в которой утверждалось, что Хоффман «вложил 100 000 долларов в эксперимент, в ходе которого была применена вдохновленная Россией тактика политической дезинформации в Facebook» во время специальной гонки в Сенат 2017 года в Алабаме, которая якобы была нацелена на избирателей Роя Мура. Хоффман не сразу ответил. Позже в том же месяце он извинился, заявив также, что не знал, чем занималась некоммерческая организация American Engagement Technologies или AET из Вашингтона, округ Колумбия.

Я в этом не специалист, но придумал как найти. Надо зайти в гугл, набрать linux kernel unit test и кликнуть на первом же результате поиска. www.kernel.org/...​ev-tools/kunit/index.html

Если бы моей целью было покрыть эту функцию тестами (я не говорю что это надо делать), то первый тест, который бы я написал для функции __lws_close_free_wsi_final проверял бы что ей можно передать NULL и она не крешится.
Следующий тест проверял бы, что она вызывает wsi->a.context->pt[(int)wsi->tsi]; задав свои заглушки в тесте для a.context и tsi (эти заглушки и есть мок объект конкретно для этого теста). Больше этот тест ничего бы не проверял. И так далее, отдельный тест со своим мок объектом для каждого конкретного теста.

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

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

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

Все правильно, только по TDD интерфейс тоже проектируется в процессе написания теста. Например,
1. мы пишем тест, который вызывает несуществующий метод.
2. Тест не компилируется.
3. Значит переключаемся на написания кода. Пишем объявление несуществующей функции, но функция будет пока с пустым телом (заглушка).
4. Тест компилируется, таким образом интерфейс доработан.
Далее, если тесты проходят, вносим следующее изменение в тесты, если не проходят, продолжаем дорабатывать код.

Возможно здесь вы имеете ввиду интеграционные тесты, а не юнит тесты.
ru.wikipedia.org/...​теграционное_тестирование
ru.wikipedia.org/...​ki/Модульное_тестирование

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

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

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

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

У меня противоположное мнение по этому вопросу

Сперва декомпозируем техническое задание на фичи и заводим их в любимый баг-трекер в виде тасок.
Также нужно правильно распределить приоритеты тасок: не делаем фичу Б, если она не может работать без фичи А — сначала делаем фичу А.
Далее пишем модульные тесты на первую фичу и проверяем, проходят ли они. Это своего рода тестирование самих тестов. Желательно написать сразу позитивный и негативный тест под фичу.
Приступаем к написанию кода бизнес-логики. Код фичи готов, когда все тесты пройдены.
Рефакторим код, если это нужно.
Повторяем цикл с новой фичей.

Я не согласен с таким пониманием основного цикла TDD. Вот как по моему мнению его понимал Кент Бек (ru.wikipedia.org/wiki/Бек,_Кент) и понимаю и выполняю его я и рекомендую всем понимать его именно так:
1. Убедится что все тесты проходят
2. Написать минимальный тест который падает или внести минимальное изменение в существующий тест, чтобы он упал.
3. Максимально быстро, не думая о качестве кода, внести минимальное изменение в код, такое чтобы тест перестал падать, причем добавлять только код, необходимый для того чтобы тест прошел и не добавлять код, который «все равно понадобится»
4. Убедится что все тесты проходят
5. Провести рефакторинг
6 Вернуться к началу цикла

Весь цикл в идеале должен занимать две минуты.

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

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

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

Я думаю, имеется ввиду, что если кандидат понимает, что это стандартная манипуляция с использованием принципа «дефицита времени», то ему или ей это может не понравиться.

Мы ввели недавно другой бонус: за выполнение самого сложного из наших тестовых заданий. Бонус выплачивается даже за нерабочее решение, но только в том случае, если мы НЕ БЕРЕМ человека на работу.