Все потоки

Продолжение Работа нотном редакторе MuseScore. Часть 5.2

В любом нотном тексте, сложнее чем запись одной мелодии, возникает необходимость многоголосой записи.

Нешаблонное применение встроенных шаблонов

Задачи окружают нас повсюду — и дома, и на работе, и во всяческих аспектах нашей повседневной жизни. У каждого со временем появляются собственные приёмы и методики работы со списками задач. Кто-то предпочитает специальные программы, кто-то по старинке всё записывает в бумажный ежедневник. Есть и те, кто вообще не занимается специальным планированием, но при этом всё успевает чудесным образом.

За долгие годы работы в IT такие методики и принципы выработались и у меня. Например, «Принцип пустого почтового ящика». Или «Принцип постепенного проявления». Они проверены временем и помогают мне успешно ориентироваться в окружающем потоке задач. В этой статье я хочу поделиться с вами этими принципами. Возможно, какие-то из них покажутся вам полезными и пригодятся.

BigQuery и другие аналитические хранилища в сочетании с современными BI инструментами перевернули работу с данными за последние годы. Возможность обрабатывать терабайты информации за секунды, интерактивные дашборды в DataStudio и PowerBI, сделали работу очень комфортной.

Однако если посмотреть глубже, можно увидеть - выиграли от этих изменений в основном профессионалы, владеющие SQL и Python и бизнес пользователи на руководящих позициях, для которых разрабатываются дашборды.
А как быть с сотнями миллионов сотрудников, для которых главным инструментом анализа был и остается Microsoft Excel?

 Привет всем, добро пожаловать в раздел о сокращении Big O. В первой части мы познакомились с BigO нотацией, а сегодня вы узнаете, как взять большой сложный алгоритм и свести его до минимального значения Big O. После прочтения данной статьи вы сможете взглянуть на любой алгоритм и определить, что представляют собой различные компоненты в рантайме. Итак, давайте выясним, как на самом деле анализировать и определять Big O любого алгоритма.

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

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

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

В этой статье разберем, как можно было этого избежать.

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

Об архитектурных неудачах, ошибках планирования и прочих косяках при разработке игры в свободное время.

Недавно на работе столкнулись с интересной ситуацией, о которой захотелось написать тут, потому что случай довольно интересный, хотя как и оказалось простой. На одном из агрегатов, управляемым контроллером от Allen Bradley Compact Logix L33ER, в контроллере постоянно сыпались предупреждения, а точнее даже минорный ошибки (Minor Faults) - которые на функциональность никак не влияют, но раздражают своим присутствием. В секунду по нескольку десятков таких ошибок без перерыва: Type 04 Program fault (Code 04) Arithmetic overflow. Result of an arithmetic instruction out of range, что переводится примерно как "Арифметическое переполнение. Результат арифметической инструкции вышел за предел."

Привет, Хабр!

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

Программирование или другие увлекательные задачи и как следствие сотни подгоревших блюд и замен посуды.

Попытки решить это недоразумение с помощью таймеров и самодисциплины со временем сходили на нет. Возможно можно было бы посмотреть в сторону мультиварки (или налаживания более прочных отношений с противоположным полом), но к моменту решения я уже был знаком c ESP8266.

Как оказалось, нужно совсем не много

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

Какие у нот частоты? Почему они такие? Как рассчитать частоту любой ноты в любом аккорде? Как добиться необычного звучания? Когда новый релиз у Моцарта?

Настройка Visual Studio Code для работы над проектами Django немного отличается от типичного сетапа для pure Python проектов. Например, в Django мало пользы от mypy, так как он не поддерживает типы Django. Точно также дела обстоят с линтерами, которые, без предварительной настройки, работают с кодом Django неправильно.

Привет, Хабр!

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

Логистическая регрессия — это алгоритм классификации в машинном обучении для прогнозирования вероятности категориально зависимой переменной. В логистической регрессии зависимые переменные — это двоичные (бинарные) переменные, содержащие 1 (да, успех, и так далее) или 0 — нет, неудача, и так далее. Другими словами, логистическая регрессия прогнозирует P(Y=1) как функцию от X. Подробный и ясный пример — к старту нашего флагманского курса по Data Science.

Все снова большой привет, спустя полгода! Сегодня мы будем продолжать работать на движке Factorio в попытках разобраться, какой же Архитектурный стиль по каким аспектам является хорошим или плохим!

Welcome!

Сегодня мы рассмотрим SOA и даже сравним его с Monolith-архитектурой!

Протоколу давно пророчат светлое будущее в качестве замены HTTP. Об этом мы говорили в одном из прошлых материалов. И сегодня решили взглянуть, как обстоят дела с внедрением IPFS и какие факторы замедляют распространение.

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

Началось все в далёком 2020 году. Правительство выпустило новый стандарт по ведению бухгалтерского учета договоров аренды. Абсолютно новые принципы ведения учёта потребовали серьёзных доработок инструментов бухгалтеров.

Моя команда методологов, изучив нормативный акт, подготовила инструкцию, описывающую порядок бухгалтерского учёта в компании, а затем на основании инструкции разработала документ, который фиксировал принципы построения учёта с точки зрения информационных систем. Важно отметить, что документ готовился на основании вводных, полученных от бухгалтеров и бизнеса. В компании было множество видов договоров аренды, у каждого из которых были свои нюансы, и которые следовало бы учесть. Всё это нашло отражение в нашем Confluence-документе.

Итак, документы готовы, переданы в подразделение,  которое выделило руководителя проектов. Началась работа.

Проект изначально стали продвигать по принципам waterfall: все шаги согласовывались со всеми стейкхолдерами, работа не двигалась до тех пор, пока все согласования не были получены. Каждую неделю отчетное собрание с руководителями финансового блока, руководителями ИТ-блока, департамента аренды, на котором демонстрировались картинки графиков, нарисованные в Excel. 

Самое удивительное в этих совещаниях заключалась в том, что они не давали ощущения целостности проекта. Не было понимания того, где находятся работы, когда будет продукт, когда будет описание. Совещания сводились к обсуждению конкретных стримов, кто что не передал, кто кому не ответил. Также в ходе проекта мои подчинённые, методологии, были привлечены к анализу и проверке технических заданий, формируемых ИТ. Получив первые ТЗ, я задал логичный, как мне казалось вопрос: а где описание архитектурой модели? Я понимаю, что наше описание принципов функционирования системы было не совершенным, предложенные решения были пересмотре ИТ, но как должна была выглядеть система в итоге надо зафиксировать на основании выработанных решений. На мой запрос ИТ ответили, что система выстраивается в процессе работ и каждый инструмент прорабатывается по мере очереди. 

В последнее время на Twitter чуть ли не из каждого утюга льется критика по поводу оверинжиниринга. Даже некоторые вполне технически подкованные люди заявляют, что Твиттер можно было бы поддерживать вообще одному - мол, "подумаешь, твиты хостить, 80% всех микросервисов ему не нужны".

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

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

Точно вам говорю, вы не одиноки: все, кто стремится измениться, проходят стадии неудач. Это нормально. Вам нужно принять этот факт, вы же не можете научиться кататься на велосипеде без падений, просто рассматривайте ваш процесс научения похудению как любой новый навык, для обучения которому требуется время, теоретические знания и практика, конечно, на первых порах с ошибками, потом ошибок будет становиться все меньше и меньше. И в конце вы научитесь «катиться» по дороге изменений на вашем «велосипеде похудения» и достигните цели.