Это зависит от стиля «доказательства», конечно, но в любом случае не забывайте, что вы принимаете на работу не сумму знаний, а живого человека, и работать он будет с живыми людьми.
У меня есть табличка с задачами todo_tasks, там есть поля id, name и created_timestamp. Я хочу найти самую раннюю задачу, т.е. ту, у которой значение в created_timestamp минимально. «Найти строку» — т.е. найти её идентификатор id, либо сразу всю строку. Без подзапросов или джойнов на стандартном SQL вы такое не напишете. Как-то так, например:
SELECT *
FROM todo_tasks
WHERE created_timestamp = (
SELECT MIN(created_timestamp)
FROM todo_tasks
GROUP BY created_timestamp
)
Да, но всё равно для достаточно частой задачи получения строки с экстремальным значением в этом декларативном языке нужно встать на уши, и выглядит полученная конструкция неинтуитивно. Предполагаю, что и оптимизатор там нетривиальный для распознавания таких ситуаций.
Ну не знаю. В СУБД да, это стандартный подход, и меня это несколько смущало всегда. В Java рядом с Collections.sort есть Collections.min и Collections.max, и всё равно все фигачат сортировку для поиска граничных элементов.
Спросят как раз те, кто уловит подвох. Большинство соискателей говорят «отсортирую и возьму первый элемент», а сложность такого решения в среднем будет линеарифмическая. И даже на вопрос «а можно проще?» отвечают не все.
Я не говорил, что интервьюер не ошибается, я лишь говорил, что он не будет спрашивать о том, в чём не разбирается. Да, к его чести, он признал ошибку, но это плюс ему, а не вам. Не забывайте про человеческий фактор. Вот вы пришли к техническому специалисту, потенциальному будущему начальнику или наставнику, и в первый час общения с ним доказали ему, что он ошибается в том, в чём, как ему казалось, он разбирается. Как вы считаете, у человека возникнет желание с вами работать? Говорят, что «умников» никто не любит — здесь под «умниками» понимаются не просто грамотные специалисты, а те, кто любит спорить и доказывать чужую неправоту там, где это ну совершенно необязательно.
На такие задачи многие специалисты по фронтэнду и мобильной разработке справедливо делают удивлённые глаза: «зачем мне это?»
Самое простое — дайте человеку todo-список и функцию сортировки и попросите найти самую раннюю по дате задачу. Далеко не все уловят подвох и спросят «а зачем сортировать, когда достаточно одного прохода?»
Или попросите в том же списке организовать возможность связи между задачами, но попросите не дать пользователю возможности сохранять задачи с кольцевыми ссылками, например.
Помимо знаний, которые действительно можно утрамбовать в краткосрочную память за несколько дней (как перед экзаменом), есть ещё навыки, опыт, кругозор, которые приобретаются сотнями и тысячами человеко-часов.
Перед тем, как приложение сделает вызов к операционной системе, эта обертка перехватит этот вызов и проверит политику – можно ли это действие выполнять данному пользователю?
А предусмотрена ли защита данных, которые такое контейнеризованное приложение сохраняет на устройство или передаёт наружу, скажем, в веб-сервисы предприятия? Есть ли end-to-end-шифрование этой информации между локальным хранилищем и удалёнными сервисами? Нужно ли пользоваться какими-то специальными API контейнера для работы с данными, или всё автоматически и прозрачно?
Ну представьте себе ветвистый вложенный-перевложенный if в процедурном коде. Там тоже есть множество блоков, конкретная последовательность выполнения которых на момент компиляции вам неизвестна и определяется состоянием. Чем это не «комбинированная функция из множества блоков» в ваших терминах? И она тоже компонуется каждый раз по-разному в рантайме. Да что там, в Java вы на этапе компиляции в большинстве случаев даже не знаете, какой именно код будет фактически исполнен при вызове метода у объектной переменной, потому что все методы (кроме статических, финальных и приватных) являются виртуальными.
Что-то я не понял вашу мысль. Где вы увидели динамическую композицию? Все действия (функции) известны на этапе компиляции, их «стыкуемость» друг с другом статически проверена с помощью системы типов — опять же на этапе компиляции. Да, если рассмотреть какой-нибудь функциональный, но всё же динамически типизированный JavaScript, аналогичные паттерны не будут поддерживаться статической системой типов, и там композиция кода действительно будет динамической, но это именно особенность системы типов языка, а не парадигмы ФП.
«Сложность пошаговой отладки» — странная формулировка применительно к ФП. В функциональном коде просто нечего «пошагово отлаживать», т.к. он не «пошаговый», а декларативный. Сложность чтения функционального кода — это миф и исключительно дело привычки.
Совершенно верно, именно так и выглядел мой пример в своей первой версии. Но потом мне показалось, что эти дополнительные преобразования несколько затуманивают монадический паттерн, а задача была именно его здесь продемонстрировать. А так получается, что мы ушли от одного бойлерплейта, а пришли к другому: о)
Но это же не туториал по использованию Optional, таких руководств тоже предостаточно. Задача статьи была продемонстрировать, как реализован паттерн монады в разных классах, естественно, я не стал погружаться в детали использования этих классов в разных юзкейсах.
Если вам нужна особая обработка отсутствия объекта на каком-то конкретном шаге, возможно, такой код вам и не подойдёт. Но в подавляющем большинстве случаев, с которыми я сталкивался, это как раз бывает неважно.
Если вы имеете в виду логирование в функциональном коде, то его логичнее всего сделать либо внутри применяемых функций, либо (что ещё лучше) внутри монадического объекта, так как логирование само по себе побочный эффект.
Типовая структура у нас пока не выработалась, в веб-приложениях она зависит от используемого фреймворка, поэтому я не стал её здесь описывать. Темы наилучших практик я обязательно затрону в следующих статьях.
Благодарю за отзыв! Чуть выше я объяснял, что задачи сравнивать технологии не было, просто я описал введение в новую технологию с позиции себя как преимущественно Java-разработчика.
Спасибо за ссылку, при написании статьи я её пропустил.
Да, нашим разработчикам уже приходилось устанавливать node, в основном для всевозможных утилит веб-разработки — bower, gulp, brunch и т.д. Но тут стояла задача использовать node именно для разработки.
Всё это очень кьютные технологии, хорошо годящиеся для фрилансерства и типовых веб-приложений, но в команде и на крупных проектах, когда задачи каждый день разные, модели большие и часто меняющиеся, а делать надо всегда быстро, они масштабируются очень плохо. Ну вот нужно вам разработать прототип несложного приложения, формочек, скажем, на 40, и сущностей на 100, десяток отчётов, несколько бизнес-процессов, штук пять прикладных ролей и пару админских. Сколько вы будете писать такой прототип на JSP+JSTL, а главное, что вы будете с ним делать, когда заказчик даст отмашку, и разработанный вами прототип нужно запихнуть в команду из 6-8 разработчиков, готовых колбасить? Не забудьте, что разработчикам надо будет прикручивать аутентификацию и авторизацию через какой-нибудь ADFS, интегрироваться со СМЭВ, ещё с какими-нибудь очередями с распределёнными транзакциями, отпиливать модули для ДМЗ, обеспечивать кластеризацию и отказоустойчивость и т.д. А главное, им обязательно придётся несколько раз повернуть вашу прекрасную модель на 180 градусов в разных местах, пока она не согнётся в конька-горбунка. Удачи!
Самое простое — дайте человеку todo-список и функцию сортировки и попросите найти самую раннюю по дате задачу. Далеко не все уловят подвох и спросят «а зачем сортировать, когда достаточно одного прохода?»
Или попросите в том же списке организовать возможность связи между задачами, но попросите не дать пользователю возможности сохранять задачи с кольцевыми ссылками, например.
А предусмотрена ли защита данных, которые такое контейнеризованное приложение сохраняет на устройство или передаёт наружу, скажем, в веб-сервисы предприятия? Есть ли end-to-end-шифрование этой информации между локальным хранилищем и удалёнными сервисами? Нужно ли пользоваться какими-то специальными API контейнера для работы с данными, или всё автоматически и прозрачно?
«Сложность пошаговой отладки» — странная формулировка применительно к ФП. В функциональном коде просто нечего «пошагово отлаживать», т.к. он не «пошаговый», а декларативный. Сложность чтения функционального кода — это миф и исключительно дело привычки.
Если вам нужна особая обработка отсутствия объекта на каком-то конкретном шаге, возможно, такой код вам и не подойдёт. Но в подавляющем большинстве случаев, с которыми я сталкивался, это как раз бывает неважно.
Если вы имеете в виду логирование в функциональном коде, то его логичнее всего сделать либо внутри применяемых функций, либо (что ещё лучше) внутри монадического объекта, так как логирование само по себе побочный эффект.
Спасибо за ссылку, при написании статьи я её пропустил.
Да, нашим разработчикам уже приходилось устанавливать node, в основном для всевозможных утилит веб-разработки — bower, gulp, brunch и т.д. Но тут стояла задача использовать node именно для разработки.