Забавно то, что в коде, с которым мне приходилось иметь дело, для string самая частая проверка это IsNullOrEmpty, а не просто на null и тут получается, что для string параметров все равно if писать придется.
А еще есть массивы, которые проверяют не только на null, но и на Length>0, а так же элементы массива на null + если массив строк, то и IsNullOrEmpty :)
Да, у каждого свои требования к такого рода устройствам, это я согласен. Когда я выбирал себе устройство просмотрел несколько вариантов и время работы поставил в приоритет т.к. устройство выбирал именно ради датчиков и трекинга, а не потенциальной возможности поставить что угодно.
Часы прошли уже путь от дополнения к телефону к практически самостоятельному устройству. Ждем появления дополнений к часам, которые тоже в свою очередь превратятся в комбайны. Видимо так выглядит прогресс )
Что бы не вдаваться в детализацию наличия/отсутствия функций посмотрите пожалуйста описание Garmin Enduro - именно с этими часами я сравниваю часы из статьи.
Это смотря что иметь ввиду под "функциями", я говорю с точки зрения использования, в wearOS нет ничего такого уникального, что меня могло бы заинтересовать как пользователя, а вот как часто требуется заряжать - важно.
Нет, не wearOS. Нужные датчики + постоянный мониторинг + запись трека + уведомления + NFC + Bluetooth + ANT+ + установка дополнений и настройка основного экрана + водонепроницаемость.
2 дня автономность? Жесть. У меня сейчас практически аналогичные по функциям часы (нет измерения давления, детекта храпа и гарнитуры) и они живут в среднем не менее 21 дня, включая 30 часов записи трека, который пишется достаточно точно.
Необязательно заниматься гонками, для обычных тренировок это все тоже нелишнее. Велотуризмом не занимаюсь, а вот тренировки 4 раза в неделю по 30 — 40км по трейлам как раз и привели к использованию гармина т.к. бывало обидно что работаешь, а потом или сегмент не подхватился или «телепорт» словил. Ну и показатели отслеживать удобнее.
За 20 лет эпизодически приходилось собеседовать программистов и реально наблюдается тенденция к увеличению количества кандидатов, но очень сильно падает их квалификация.
После ряда экспериментов пришли к выводу, что иметь (например) трех квалифицированных (и более дорогих) разработчиков лучше (и дешевле!), чем пять болванчиков и лида к ним.
Есть же редакторы типа https://prosemirror.net/ которые дают документ в JSON, а генерация HTML по JSON может быть любая + можно обновлять генерацию не меняя уже созданные документы.
На основе https://prosemirror.net/ есть еще https://tiptap.dev/ для тех, кто использует VueJS.
Физ. нагрузка в начале дня — это замечательная вещь, уже несколько лет регулярно занимаюсь 3 — 5 раз в неделю зимой лыжами, летом велосипед (кросс — кантри, дает нагрузку не только на ноги).
Достаточно много положительных моментов и физических и психологических, если случаются перерывы, то организм начинает требовать нагрузку.
Интенсивность занятий на лыжах 14-16 км в день с хорошим градиентом, на велосипеде 30-40км по лесу, по продолжительности выходит около 2 часов на тренировку в день.
Переход (он же transition) это линия между состояниями, запускать переход лучше triggerом. У перехода может быть условие доступности (guard) который может запретить выполнять переход.
OnEnter/OnExit не очень удобно использовать на практике, действие должно принадлежать переходу и запускаться на выполнение по triggerу если guard этого перехода разрешает.
Благодаря паре trigger + guard можно делать всякие интересные вещи: один trigger может быть указан для нескольких переходов с условиями доступности и выполнять только первый доступный переход, можно готовить список доступных переходов например для отображения кнопок в UI, можно сделать несколько разных переходов из состояния 1 в состояние 2.
Визуально удобно располагать статусы горизонтально от начального, размещая на этой линии основные переходы и статусы, выше/ниже этой линии располагать альтернативные пути переходов и чем дальше от основной, тем они менее вероятны. При этом выше основной линии — "хорошие" переходы, ниже — "плохие" или "нежелательные". Так же нужны обратные переходы. при таком подходе схема будет читаться намного легче.
В XML с описанием конечного автомата лучше отделить описание структуры состояний/переходов от данных для отображения этой структуры — будет проще понимать что там происходит.
По отчету Минфина среднее количество участников — 2.9, подавляющее количество закупок — единственный источник + эл. аукцион.
"Когда-то думали, что 94ФЗ — дно, но снизу постучал 44ФЗ" — это мнение людей, которые вынуждены с этим всем жить. Проблем там море и регулярно добавляются новые. Красивые цифры отчетов экономии рисуются исходя из взятых с потолка начальных цен (даже несмотря на обязательность обосновывать их).
"Экосистема цифрового мира закупок" сейчас в части гос.закупок стоит на болоте, а не на нормальных бизнес-процессах и конца этому не видно.
Ужас какой, нет конечно. На Vuejs реализованы сложные части UI, которые через обычный DOM+jQuery сделать конечно можно, но получается на порядок сложнее Vuejs компонент.
Vuejs компоненты являются частью других компонент, которые могут иметь свой Razor шаблон, так и рендерится обычними helperами. SPA работает с использованием HistoryJS и получает от сервера HTML, в котором может использоваться VueJS.
Эх, было время когда мы так же писали. Но прошло время, поменялся подход и из проекта выкинули примерно 60% кода с учетом того, что полезные для пользователя функции добавлялись.
И у нас отлично уживается Razor с Vuejs в SPA.
Посмотрел я на главу этой книги и для меня все стало понятно: в книге, именно в главе с упоминанием ОПЗ рассматривается не вычисление выражений человеками, а приводится пример использования описываемой в этой главе структуры данных — стека и ОПЗ там используется всего лишь для иллюстрации использования стэка для реализации преобразования инфиксной записи в ОПЗ.
Ни о каком насилии над личностью там нет, просто алгоритм (по сути "сортировочная станция" + вычисление с использованием стэка) хорошо демонстрирует приемы работы со стэком.
Позволю себе процитировать начало этого раздела (стр. 152):
Разбор арифметических выражений
Итак, в этой главе были описаны три разные структуры данных. Давайте немного сменим тему и рассмотрим важное практическое применение одной из этих структур.
И далее стр. 154:
На нескольких ближайших страницах подробно рассматривается процесс преобразования выражений из инфиксной записи в постфиксную. Алгоритм не из простых, так что не огорчайтесь, если что-то покажется непонятным. Если вы чувствуете, что начинаете вязнуть в теории, переходите к разделу «Вычисление постфиксных выражений». Чтобы понять, как создаются постфиксные выражения, полезно рассмотреть процесс вычисления их результата — например, вычисления значения 14 для выражения 234 + ×, постфиксного эквивалента 2 × (3 + 4).
Автор книги мог с тем же успехом иллюстрировать работу стэка на примере построения дерева выражения, но тогда пришлось бы картинок порисовать побольше.
В топике я вижу попытку донести мысль о том, что вычислить выражение в инфиксной записи человеку методом П-П проще, чем методом преобразования в ОПЗ с последующем вычислением выражения в ОПЗ. Но это ж понятно, что одна операция проще, чем две.
Спор же (на over 200+ каментов) идет вокруг реализации этих алгоритмов и эффективность реализации П-П против "сортировочной станции" + вычисление с использованием стэка вызывает абсолютно обоснованные сомнения. (В топике о реализации говорит как минимум отсылка к использованию Regex)
И еще одна цитата из книги (опять же стр. 152):
Материал данного раздела в каком-то смысле можно рассматривать как «до-
полнительное чтение». Он не обязателен для понимания книги, а в вашей повсе-
дневной работе вам вряд ли придется часто писать код разбора арифметических
выражений
Т.е. мало того, что там не учат ОПЗ в обязательном порядке, а только как пример использования, так и находится это в "доп. материалах" и речи о "насаждении ОПЗ" и "обязаловке" для вычисления именно этим методом там нет.
Думаю дальнейшая переписка по этой теме бессмысленна.
Обратите внимание на то, что ОПН в своем сообщении я ни разу не упомянул.
При отсутствии понимания, что стэк с числами и строка с числами с точки зрения мат. вычислений это таки две большие разницы, разговор об эффективности алгоритмов чуть более, чем полностью бессмыслен.
Забавно то, что в коде, с которым мне приходилось иметь дело, для string самая частая проверка это IsNullOrEmpty, а не просто на null и тут получается, что для string параметров все равно if писать придется.
А еще есть массивы, которые проверяют не только на null, но и на Length>0, а так же элементы массива на null + если массив строк, то и IsNullOrEmpty :)
Да, у каждого свои требования к такого рода устройствам, это я согласен. Когда я выбирал себе устройство просмотрел несколько вариантов и время работы поставил в приоритет т.к. устройство выбирал именно ради датчиков и трекинга, а не потенциальной возможности поставить что угодно.
Часы прошли уже путь от дополнения к телефону к практически самостоятельному устройству. Ждем появления дополнений к часам, которые тоже в свою очередь превратятся в комбайны. Видимо так выглядит прогресс )
Что бы не вдаваться в детализацию наличия/отсутствия функций посмотрите пожалуйста описание Garmin Enduro - именно с этими часами я сравниваю часы из статьи.
Это смотря что иметь ввиду под "функциями", я говорю с точки зрения использования, в wearOS нет ничего такого уникального, что меня могло бы заинтересовать как пользователя, а вот как часто требуется заряжать - важно.
Нет, не wearOS. Нужные датчики + постоянный мониторинг + запись трека + уведомления + NFC + Bluetooth + ANT+ + установка дополнений и настройка основного экрана + водонепроницаемость.
2 дня автономность? Жесть. У меня сейчас практически аналогичные по функциям часы (нет измерения давления, детекта храпа и гарнитуры) и они живут в среднем не менее 21 дня, включая 30 часов записи трека, который пишется достаточно точно.
Необязательно заниматься гонками, для обычных тренировок это все тоже нелишнее. Велотуризмом не занимаюсь, а вот тренировки 4 раза в неделю по 30 — 40км по трейлам как раз и привели к использованию гармина т.к. бывало обидно что работаешь, а потом или сегмент не подхватился или «телепорт» словил. Ну и показатели отслеживать удобнее.
Это только кажется, что смарта достаточно, а в реальности отдельное специализированное устройство дает:
За 20 лет эпизодически приходилось собеседовать программистов и реально наблюдается тенденция к увеличению количества кандидатов, но очень сильно падает их квалификация.
После ряда экспериментов пришли к выводу, что иметь (например) трех квалифицированных (и более дорогих) разработчиков лучше (и дешевле!), чем пять болванчиков и лида к ним.
Есть же редакторы типа https://prosemirror.net/ которые дают документ в JSON, а генерация HTML по JSON может быть любая + можно обновлять генерацию не меняя уже созданные документы.
На основе https://prosemirror.net/ есть еще https://tiptap.dev/ для тех, кто использует VueJS.
Ну по асфальту проехаться это жесть, в лесу безопаснее — на собственном опыте несколько раз убеждался, поэтому в город не выезжаю.
Физ. нагрузка в начале дня — это замечательная вещь, уже несколько лет регулярно занимаюсь 3 — 5 раз в неделю зимой лыжами, летом велосипед (кросс — кантри, дает нагрузку не только на ноги).
Достаточно много положительных моментов и физических и психологических, если случаются перерывы, то организм начинает требовать нагрузку.
Интенсивность занятий на лыжах 14-16 км в день с хорошим градиентом, на велосипеде 30-40км по лесу, по продолжительности выходит около 2 часов на тренировку в день.
Немного советов из собственного опыта:
По отчету Минфина среднее количество участников — 2.9, подавляющее количество закупок — единственный источник + эл. аукцион.
"Когда-то думали, что 94ФЗ — дно, но снизу постучал 44ФЗ" — это мнение людей, которые вынуждены с этим всем жить. Проблем там море и регулярно добавляются новые. Красивые цифры отчетов экономии рисуются исходя из взятых с потолка начальных цен (даже несмотря на обязательность обосновывать их).
"Экосистема цифрового мира закупок" сейчас в части гос.закупок стоит на болоте, а не на нормальных бизнес-процессах и конца этому не видно.
Ужас какой, нет конечно. На Vuejs реализованы сложные части UI, которые через обычный DOM+jQuery сделать конечно можно, но получается на порядок сложнее Vuejs компонент.
Vuejs компоненты являются частью других компонент, которые могут иметь свой Razor шаблон, так и рендерится обычними helperами. SPA работает с использованием HistoryJS и получает от сервера HTML, в котором может использоваться VueJS.
Эх, было время когда мы так же писали. Но прошло время, поменялся подход и из проекта выкинули примерно 60% кода с учетом того, что полезные для пользователя функции добавлялись.
И у нас отлично уживается Razor с Vuejs в SPA.
Посмотрел я на главу этой книги и для меня все стало понятно: в книге, именно в главе с упоминанием ОПЗ рассматривается не вычисление выражений человеками, а приводится пример использования описываемой в этой главе структуры данных — стека и ОПЗ там используется всего лишь для иллюстрации использования стэка для реализации преобразования инфиксной записи в ОПЗ.
Ни о каком насилии над личностью там нет, просто алгоритм (по сути "сортировочная станция" + вычисление с использованием стэка) хорошо демонстрирует приемы работы со стэком.
Позволю себе процитировать начало этого раздела (стр. 152):
И далее стр. 154:
Автор книги мог с тем же успехом иллюстрировать работу стэка на примере построения дерева выражения, но тогда пришлось бы картинок порисовать побольше.
В топике я вижу попытку донести мысль о том, что вычислить выражение в инфиксной записи человеку методом П-П проще, чем методом преобразования в ОПЗ с последующем вычислением выражения в ОПЗ. Но это ж понятно, что одна операция проще, чем две.
Спор же (на over 200+ каментов) идет вокруг реализации этих алгоритмов и эффективность реализации П-П против "сортировочной станции" + вычисление с использованием стэка вызывает абсолютно обоснованные сомнения. (В топике о реализации говорит как минимум отсылка к использованию Regex)
И еще одна цитата из книги (опять же стр. 152):
Т.е. мало того, что там не учат ОПЗ в обязательном порядке, а только как пример использования, так и находится это в "доп. материалах" и речи о "насаждении ОПЗ" и "обязаловке" для вычисления именно этим методом там нет.
Думаю дальнейшая переписка по этой теме бессмысленна.
Сильно прочищают мозги тесты и профилирование, очень хорошо избавляют от "бумажной мудрости".