Pull to refresh
41
0
ETC.Dema @ETCDema

User

Send message

Забавно то, что в коде, с которым мне приходилось иметь дело, для string самая частая проверка это IsNullOrEmpty, а не просто на null и тут получается, что для string параметров все равно if писать придется.

А еще есть массивы, которые проверяют не только на null, но и на Length>0, а так же элементы массива на null + если массив строк, то и IsNullOrEmpty :)

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

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

Что бы не вдаваться в детализацию наличия/отсутствия функций посмотрите пожалуйста описание Garmin Enduro - именно с этими часами я сравниваю часы из статьи.

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

Нет, не wearOS. Нужные датчики + постоянный мониторинг + запись трека + уведомления + NFC + Bluetooth + ANT+ + установка дополнений и настройка основного экрана + водонепроницаемость.

2 дня автономность? Жесть. У меня сейчас практически аналогичные по функциям часы (нет измерения давления, детекта храпа и гарнитуры) и они живут в среднем не менее 21 дня, включая 30 часов записи трека, который пишется достаточно точно.

Необязательно заниматься гонками, для обычных тренировок это все тоже нелишнее. Велотуризмом не занимаюсь, а вот тренировки 4 раза в неделю по 30 — 40км по трейлам как раз и привели к использованию гармина т.к. бывало обидно что работаешь, а потом или сегмент не подхватился или «телепорт» словил. Ну и показатели отслеживать удобнее.

Это только кажется, что смарта достаточно, а в реальности отдельное специализированное устройство дает:


  1. Более точную запись трека
  2. Подключение дополнительных по Ant+: пульсометр, датчик каденса, скорость с колеса, мощность
  3. Все собираемые данные пишутся в единый файл и его можно взять и загружать на разные сервисы
  4. Подсказки по сегментам с ведением по сегменту и сравнение с "тенью" или КОМом
  5. Защищен от неприятностей
  6. Можно быстро посмотреть текущую информацию т.к. и крепление и экран и элементы интерфейса для этого оптимизированы
  7. Более удобное управление на ходу/в перчатках
  8. Более продолжительная работа от одного заряда
  9. Внезапный звонок не сносит работающее приложение и не ломает запись
  10. Средство связи не расходует свой заряд

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

Есть же редакторы типа https://prosemirror.net/ которые дают документ в JSON, а генерация HTML по JSON может быть любая + можно обновлять генерацию не меняя уже созданные документы.
На основе https://prosemirror.net/ есть еще https://tiptap.dev/ для тех, кто использует VueJS.

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

Физ. нагрузка в начале дня — это замечательная вещь, уже несколько лет регулярно занимаюсь 3 — 5 раз в неделю зимой лыжами, летом велосипед (кросс — кантри, дает нагрузку не только на ноги).
Достаточно много положительных моментов и физических и психологических, если случаются перерывы, то организм начинает требовать нагрузку.
Интенсивность занятий на лыжах 14-16 км в день с хорошим градиентом, на велосипеде 30-40км по лесу, по продолжительности выходит около 2 часов на тренировку в день.

Немного советов из собственного опыта:


  1. Переход (он же transition) это линия между состояниями, запускать переход лучше triggerом. У перехода может быть условие доступности (guard) который может запретить выполнять переход.
  2. OnEnter/OnExit не очень удобно использовать на практике, действие должно принадлежать переходу и запускаться на выполнение по triggerу если guard этого перехода разрешает.
  3. Благодаря паре trigger + guard можно делать всякие интересные вещи: один trigger может быть указан для нескольких переходов с условиями доступности и выполнять только первый доступный переход, можно готовить список доступных переходов например для отображения кнопок в UI, можно сделать несколько разных переходов из состояния 1 в состояние 2.
  4. Визуально удобно располагать статусы горизонтально от начального, размещая на этой линии основные переходы и статусы, выше/ниже этой линии располагать альтернативные пути переходов и чем дальше от основной, тем они менее вероятны. При этом выше основной линии — "хорошие" переходы, ниже — "плохие" или "нежелательные". Так же нужны обратные переходы. при таком подходе схема будет читаться намного легче.
  5. В 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):


Материал данного раздела в каком-то смысле можно рассматривать как «до-
полнительное чтение». Он не обязателен для понимания книги, а в вашей повсе-
дневной работе вам вряд ли придется часто писать код разбора арифметических
выражений

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


Думаю дальнейшая переписка по этой теме бессмысленна.

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

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

Information

Rating
Does not participate
Location
Москва, Москва и Московская обл., Россия
Date of birth
Registered
Activity

Specialization

Fullstack Developer, Software Architect
Lead
Web development
Vue.js
HTML
CSS
JavaScript
.NET Core
ASP.NET MVC
PostgreSQL
Linux