Эстонский не похож на индо-европейские, другая семья языков, артиклей нет, есть глагол аналог to be (бытия), нет будущего времени, имеются два инфинитива глагола (в русском и прочих один). Например Если <<я ИДУ ПИТЬ>>, то ПИТЬ будет в одной форме инфинитива, поскольку действие, если <<я ХОЧУ ПИТЬ>> то в другом инфинитиве, поскольку чувства. Ну и прочие мелочи.
Русский, нет соединительного глагола а-ля to be(отсюда есть мнения, что поэтому в русской философии не так много внимания уделялось онтологии в зависимости от западной), артиклей, вместо системы времен используются совершенные/несовершенные формы и так далее.
Английский — понятно.
Испанский — два типа глаголов ser, estar как говорили выше, одни больше к бытию, другие к состоянию. Сложная система времен (в сложноподчиненных предложениях)
Знаком с теорией Сепира-Ворфа хорошо. Она в целом противоречит сама себе, как они могли понять язык индейцев, если утверждают некий языковый солипсизм в мягкой форме.
На любом языке можно выразить любую мысль. Серьезно, просто языковые конструкции разные, но когнитивный аппарат у нас очень гибкий.
Я бы сказал что говорящим на одном языке часто бывает сложнее понять друг-друга, особенно если люди думают по разному, из разных классов, по разному верят в символы (относятся к политике и живут в разных пузырях)
У нас есть регистрация, где выдается токен на устройство. Все что без токена откидывается. Тут проблема в том, что публика оченõь разная, и даже два-три дополнительных поля ввода играют роль и ухудшают user experience. Например в начале у нас было поле введение имени (нажатие, печатать), выбор языка (нажатие, дропдаун, выбор языка — 2 нажатия), возраст — нажатие, кнопка Зарегестрироваться — всего 5 нажатий. Мы поставили две кнопки (По русски — По эстонски) и поле ввода имени, всего 2 нажатия. Вводить цифры дополнительная сложность. Мы ограничиваем еще на инфра стороне, но да, некоторые, кто знал, голосовали из дома.
Голоса учитываются только те, у кого валидный токен полученный на момент регистрации.
В театре есть Wi-Fi, но большинство сидят на 4G, и у нас бывали проблемы когда рядом происходило какое либо массовое мероприятие и вышка оказывалась перегружена, из-за чего у части людей возникали затыки с голосованием.
<<мы сможем определить, выводит ли она требуемую строку.>> Hет, в общем виде не можем. Автор статьи не до конца понимает. Теорема Райса говорит что не существует общего доказательства того, что программа делает то что надо(выводит нужную строку), которая следует из проблемы остановки машины Тьюринга, которая в свою очередь следует из теоремы о неполноте Геделя. Отсюда вся эта армия тестировщиков в ИТ и бесконечно обновляющийся Windows без определенного времени, что обновление закончится через 2 минуты и не больше…
Да, сняли с языка.
Но все же не выкидываем Дебаг. И то и то полезно.
Но в целом, именно хорошее логгирование позволит понять почему именно в проде через неделю-две что то падает. Мультипоточность, утечки памяти, и прочие вещи связанные с CAP теоремой ловятся часто только через логи. НО. Часто возникают ситуации, когда надо идти и смотреть в ключевых точках что происходит, и от этого никуда не деться.
Мир не черно белый. Нет одного правильного подхода. Серединный путь, как говорил еще Будда про ИТ разработку.
Да будут счастливы все те, кто уверен наперед что он знает как оно должно быть. Автомобиль, переднеприводный, мощность до 200 киловатт, дизель, салон кожаный темный, купе, крыша нежесткая. И кому рынок ответит не фи, а да-да-да.
Пока ты не вышел в прод и не получаешь реальную, еще раз, реальную обратную связь, а не инженерные предположения как оно должно быть, и должно быть ли вообще, можно пилить все что угодно.
И скорость прогресса, после выхода в прод, получения обратной связи от людей кто будет пользоваться, вырастает в разы. Ну вот реально. кто пробовал, тот знает.
Но желаю удачи с уверенностью знания наперед. :)
Эффект Даннинга-Крюгера во всей красе помноженный на хамство. Автор смешал все в кучу, декларативное с императивным. На любые вопросы, тыкает прочитайте определение. Схоластика в 21 веке. При чем о философии науки даже и не слышал :) про математику, абстракции, языки программирования и прочее даже говорить не хочется. Хочется развидеть.
Что правильнее Лямбда исчисление Черча, машины Тьюринга, или вообще циклические теги? Очень мило, если бы не хамство, выглядели попытки натянуть математические концепты на «химические элементы»
является совокупностью бредово-казённо-абсурдных высказываний наподобие:
Процессор Пентиум — это логическое устройство. Любое действие процессора определяется логикой этого процесса.
Горлов А. В.
vs.
Факты:
1. Всё в окружающем мире состоит из мельчайших неделимых химических элементов и поэтому за основу главного объекта необходимо брать именно химический элемент обладающий множеством моделей поведения.
Скорее всего потому, что метрики уже писались в Инфлюкс для визуализации в Графане. Плюс мы умеем хорошо готовить эту базу.
Но у нее есть тоже свои особенности, которые надо учитывать. Или вот например свежее, поначалу я грешил на графану, почему и открыл issue там но github.com/grafana/grafana/issues/11482
Хотя проблема наблюдалась только в графане, моя система не имела проблем.
По большому счету сделать коннектор к другой базе не проблема, там достаточно имплементировать интерфеис, который должен возвращать данные в формате pandas.DataFrame
Я пробовал несколько подходов, ARIMA, Twitter ESDA. Но по факту лучше всего оказалось считать моделью данные с предыдущей недели пройденные скользящими средними и разбросом с окном 60 минут (гранулярность 1 минута). Баундариз считается как значение трех значений скользящего разброса по обеим сторонам.
В дальнейшем я хочу считать модель по данным 4 недель, усредняя их и давая уменьшающиеся веса по мере удаленности.
Если на той неделе был инцидент, то я пока просто не беру эту неделю, хотя писал функцию которая вырезает этот кусок из предыдущих недель. Аутлаером считается то, что выходит за границы.
У меня сейчас интересный проект отпочковавшийся от этой системы. Это магистерская работа для нашего интерна. Мы можем представить метрики как матрицы, и идти по ним конволюционными ядрами, которые подстроены под поиск градиента (падения или подъема).
В прошлом году были удачные академические публикации о применении этого метода с финансовыми рынками. Я писал о своем воспроизведении на английском тут.
Я напишу если этот подход будет удачным. Но теоретически все должно получиться.
Да, у меня были сложности с тем как на русском определить термины. Это сложно.
Monitoring, Anomalies, Alerts это разные термины.
Поэтому возможна путаница.
В некотором смысле параметры все равно приходится подкручивать ручками. Падение на 40% от среднего на сайтах с десятками тысяч пользователей — проблема. На других брендах где среднее порядка сотни на часовом интервале падение на 40% норма. Это тонкий баланс. Универсальные алгоритмы и подходы как правило работают плохо. И в то же время хочется быть как можно более универсальным.
Да, я чищу явные выбросы. Просматриваю метрики и ищу слишком сильную динамику подьема. Но там еще есть свой технический долг :)
Обычный матан. Сходящиеся и расходящиеся ряды. Единственное, что многие после универа это подзабывают, а так никакой сверх математикой тут и не пахнет. Если курил матан в свое время, то все вполне легко решаемо, даже если и подзабыл.
На самом деле, когда проводишь какое то количество собеседований, то очень видно как огромное количество людей, позиционирующих себя как серьезные девелоперы инженеры, отсеиваются на азах. Отсюда и попаболь которая сквозит во всех этих удивленных вопросах, о том зачем это надо, я фулл стек инженер, и мне не надо знать ни абстракты, ни структуры данных, я пользуюсь готовыми. В любом серьезном бэкэнде, особенно критичном по скорости или обьему, таких вопросов даже не ставится. Это кирпичики, и инструменты для разбиения сложности. Со сложностью можно по разному бороться, но ООП в принципе и было представлено как адекватное решение многих проблем. В этом плане интересно написал Б. Страуструп в своей культовой С++, расказывая о проблемах и сложностях кодовой базы в десятки тысяч строк кода. Я сейчас проектирую большие API и проблемы борьбы со сложностью там встают как нельзя больше, код готорый мы генерируем из схем весь абстрактный, то есть все классы абстрактные, расширение функциональности происходит от наследования от них. Это все тонкие вопросы и серебряной пули нет.
Здесь в ссылке есть отличный пост на эту тему.
https://blog.codinghorror.com/why-cant-programmers-program/
Согласен. Это must have.
Сам сеичас по работе занимаюсь анализом и прогнозом временных рядов, ищу решение. Но имея опыт в сфере биржевых систем могу сказать сразу, все анализы временных рядов в этой сфере не более чем кидание монетки. Движение цен не предсказывается. Цена может пойти как вверх так и вниз. Задним числом конечно же все это можно уже обосновать. Впрочем как обучающая статья, анализ бизржевой информации вполне может использоваться.
Судя по тому как заминусовали, я могу сделать вывод о текущем уровне части читателей Хабра. Если утверждение о том, что за 10 лет в индустрии про абстракт классы можно забыть (мы говорим о разработчиках и архитекторах) то по сути, здесь уже не о чем говорить. О конкретных количествах абстракт классов ушедших в прод тоже. Я не считаю. Концепция абстракт классов это инструмент, инструмент для лучшей борьбы со сложностью, DRY и все такое. Не вижу смысла вести дискуссию с людьми, кто не понимает элементарных вещей. Я думаю на собеседовании этот вопрос по прежнему остается актуальным. Кто бы что не говорил.
На прошлой неделе два абстракт класса.
Пример из жизни, когда реализуется какая либо общая функциональность для различных имплементаций.
Например генераторы кода для С, Java, Json схем, из XML схем.
Эстонский не похож на индо-европейские, другая семья языков, артиклей нет, есть глагол аналог to be (бытия), нет будущего времени, имеются два инфинитива глагола (в русском и прочих один). Например Если <<я ИДУ ПИТЬ>>, то ПИТЬ будет в одной форме инфинитива, поскольку действие, если <<я ХОЧУ ПИТЬ>> то в другом инфинитиве, поскольку чувства. Ну и прочие мелочи.
Русский, нет соединительного глагола а-ля to be(отсюда есть мнения, что поэтому в русской философии не так много внимания уделялось онтологии в зависимости от западной), артиклей, вместо системы времен используются совершенные/несовершенные формы и так далее.
Английский — понятно.
Испанский — два типа глаголов ser, estar как говорили выше, одни больше к бытию, другие к состоянию. Сложная система времен (в сложноподчиненных предложениях)
Знаком с теорией Сепира-Ворфа хорошо. Она в целом противоречит сама себе, как они могли понять язык индейцев, если утверждают некий языковый солипсизм в мягкой форме.
На любом языке можно выразить любую мысль. Серьезно, просто языковые конструкции разные, но когнитивный аппарат у нас очень гибкий.
Я бы сказал что говорящим на одном языке часто бывает сложнее понять друг-друга, особенно если люди думают по разному, из разных классов, по разному верят в символы (относятся к политике и живут в разных пузырях)
Голоса учитываются только те, у кого валидный токен полученный на момент регистрации.
В театре есть Wi-Fi, но большинство сидят на 4G, и у нас бывали проблемы когда рядом происходило какое либо массовое мероприятие и вышка оказывалась перегружена, из-за чего у части людей возникали затыки с голосованием.
Но все же не выкидываем Дебаг. И то и то полезно.
Но в целом, именно хорошее логгирование позволит понять почему именно в проде через неделю-две что то падает. Мультипоточность, утечки памяти, и прочие вещи связанные с CAP теоремой ловятся часто только через логи. НО. Часто возникают ситуации, когда надо идти и смотреть в ключевых точках что происходит, и от этого никуда не деться.
Мир не черно белый. Нет одного правильного подхода. Серединный путь, как говорил еще Будда про ИТ разработку.
Пока ты не вышел в прод и не получаешь реальную, еще раз, реальную обратную связь, а не инженерные предположения как оно должно быть, и должно быть ли вообще, можно пилить все что угодно.
И скорость прогресса, после выхода в прод, получения обратной связи от людей кто будет пользоваться, вырастает в разы. Ну вот реально. кто пробовал, тот знает.
Но желаю удачи с уверенностью знания наперед. :)
Что правильнее Лямбда исчисление Черча, машины Тьюринга, или вообще циклические теги? Очень мило, если бы не хамство, выглядели попытки натянуть математические концепты на «химические элементы»
горшочек не вари.
vs.
Но у нее есть тоже свои особенности, которые надо учитывать. Или вот например свежее, поначалу я грешил на графану, почему и открыл issue там но
github.com/grafana/grafana/issues/11482
Хотя проблема наблюдалась только в графане, моя система не имела проблем.
По большому счету сделать коннектор к другой базе не проблема, там достаточно имплементировать интерфеис, который должен возвращать данные в формате pandas.DataFrame
Я пробовал несколько подходов, ARIMA, Twitter ESDA. Но по факту лучше всего оказалось считать моделью данные с предыдущей недели пройденные скользящими средними и разбросом с окном 60 минут (гранулярность 1 минута). Баундариз считается как значение трех значений скользящего разброса по обеим сторонам.
В дальнейшем я хочу считать модель по данным 4 недель, усредняя их и давая уменьшающиеся веса по мере удаленности.
Если на той неделе был инцидент, то я пока просто не беру эту неделю, хотя писал функцию которая вырезает этот кусок из предыдущих недель. Аутлаером считается то, что выходит за границы.
В прошлом году были удачные академические публикации о применении этого метода с финансовыми рынками. Я писал о своем воспроизведении на английском тут.
Я напишу если этот подход будет удачным. Но теоретически все должно получиться.
Monitoring, Anomalies, Alerts это разные термины.
Поэтому возможна путаница.
В некотором смысле параметры все равно приходится подкручивать ручками. Падение на 40% от среднего на сайтах с десятками тысяч пользователей — проблема. На других брендах где среднее порядка сотни на часовом интервале падение на 40% норма. Это тонкий баланс. Универсальные алгоритмы и подходы как правило работают плохо. И в то же время хочется быть как можно более универсальным.
Да, я чищу явные выбросы. Просматриваю метрики и ищу слишком сильную динамику подьема. Но там еще есть свой технический долг :)
Здесь в ссылке есть отличный пост на эту тему.
https://blog.codinghorror.com/why-cant-programmers-program/
Сам сеичас по работе занимаюсь анализом и прогнозом временных рядов, ищу решение. Но имея опыт в сфере биржевых систем могу сказать сразу, все анализы временных рядов в этой сфере не более чем кидание монетки. Движение цен не предсказывается. Цена может пойти как вверх так и вниз. Задним числом конечно же все это можно уже обосновать. Впрочем как обучающая статья, анализ бизржевой информации вполне может использоваться.
Пример из жизни, когда реализуется какая либо общая функциональность для различных имплементаций.
Например генераторы кода для С, Java, Json схем, из XML схем.
Я не о том уместен или неуместен вопрос, а об отмазке забыл за 10 лет. А в прод он Визуал Бейсик запускал?