User
Ситуация получилась следующая.
Компания переделывала сайт и сказал, что необходимо сделать его максимально гибким, чтобы, во-первых, можно было дизайн обновлять просто, во-вторых, сделать ещё несколько подразделов на базе готового функционала (вроде как SaaS фишка для заказчиков).
"Разработчик – это человек, который переводит мысли заказчика на язык машины"
@mikita_du
Идея статьи появилась год назад, думал назвать «Вёрстка в 2021», но как-то затянулось… Весной 2021 года Microsoft объявила, что с 15 июня 2022 года прекращается поддержка IE11 (да, не для всех версий Win 10, но всё же), а значит, к выходу статьи уже останется менее полугода до знаменательного события, когда не придётся верстать под IE.
Для меня же это значит, что можно будет по полной использовать новые стандарты браузеров, в частности – css-variables, grid layout.
Н. Кобринский, В. Пекелис «Быстрее мысли» — Молодая гвардия, 1959
Когда все вокруг измеряют Гигабайтами, Петабайтами, Зетабайтами и т.д., все компании гордятся своей БигДатой, вспоминать о битах в приличном обществе воспринимается как моветон. Однако и биты иногда бывают полезны. Темой для разговора послужила одна типовая классическая задачка, лежащая в области опросов.
Является продолжением серии предыдущих публикаций.
Переход на 1С ERP – какие есть варианты?
Если поставить себя на место менеджера, которому руководство компании поручило изучить вопрос с покупкой и внедрением «1C:ERP Управление предприятием» (далее - ERP), то в этом случае возможны следующие варианты действий:
• собрать команду из своих сотрудников (IT-персонал, программисты, аналитики) и осуществить процесс подготовки и внедрения исключительно своими силами;
• обратиться к «своему» поставщику программ 1С и поручить ему полностью разработку и реализацию проекта внедрения;
• организовать конкурс и выбрать самого щедрого на обещания или дешевого по цене;
• зайти на сайт 1С и из внушительного списка компаний-франчайзи выбрать самых опытных, которые внедряли ERP словно «арбузы выращивали», «в больших количествах и крупных размеров»;
• можно улучшить поиск и выбрать поставщиков, которые внедряли ERP в компаниях «родной» сферы деятельности;
• самые «умные и продвинутые» наберут в поиске Яндекса «внедрение 1C ERP» и изучат предложения и сайты компаний из первой двадцатки и Яндекс директ.
Естественно в этом списке присутствует определенная ирония, но давайте действительно проанализируем механизмы того, как принимаются решения по внедрению ERP. И выделим главные факторы, влияющие на это.
Часть 1. ConfigurationManager
Часть 2. WebApplicationBuilder
В предыдущем посте я сравнивал новый WebApplication с универсальным хостом. В этом посте я рассмотрю код, лежащий в основе WebApplicationBuilder, чтобы увидеть, как он обеспечивает более чистый, минимальный API хостинга, при этом обеспечивая ту же функциональность, что и универсальный хост.
Виртуализация сетевых функций (NFV) и облачные сетевые функции (CNF) продолжают набирать популярность в отрасли телекоммуникаций. Виртуализация помогает сократить капитальные и операционные затраты, отделяя сетевые функции от инфраструктуры и обеспечивая гибкость и масштабируемость. Несмотря на широкое распространение этой технологии, организации по-прежнему сталкиваются с трудностями при ее реализации в повседневной работе.
Одна из главных сложностей — наладить процесс управления сетевыми функциями и их оркестровки. Телеком-компании должны создавать виртуализированные сетевые функции, при этом поддерживать высокое качество обслуживания и внедрять постоянно появляющиеся инновации. Технология 5G, скорее всего, продержится еще 5–8 лет, прежде чем уступить место 6G. Переход на сети нового поколения обходится дорого, и если средний доход на абонента не будет покрывать капитальные затраты, телеком-компании не смогут сохранить свои прибыли.
С каждым годом число автомобилей на дорогах неуклонно растет, все больше загрязняя окружающую среду, ухудшая мобильность транспортных средств и увеличивая число аварий и смертей на дорогах. Множество умов уже давно стараются разработать безопасное для участников движения решение, позволяющее увеличить пропускную способность дорог. Было предложено множество вариантов: летательные средства передвижения, подземные автомобильные магистрали и даже надземная система путепроводов. Однако у каждого предложенного варианта есть различные сложности в реализации.
Среди прочих одним из самых перспективных проектов по увеличению безопасности и пропускной способности автомагистралей является технология подключенных и автономных транспортных средств (CAV - Connected and Automated Vehicle). Основная её идея состоит в том, чтобы использовать инфраструктуру, оборудованную дорожными блоками (RSU - Road Side Unit), для сбора информации о транспортных средствах, оснащенных бортовым блоком (OBU - On-Board Unit), в форме базовых сообщений безопасности (BSM - Basic Safety Messages). В таком случае CAV'ы получают информацию о ситуации на дороге не только с помощью сенсоров, радаров и лидаров, как обычные автомобили, оборудованные автопилотом, но и "общаются" друг с другом и с окружающей инфраструктурой. Это и позволяет CAV'ам и остальным участникам движения действовать автономно, оттого и более эффективно. Однако и в этом проекте есть проблема - наличие общей сети, к которой подключены все автомобили. Общая сеть рождает риск кибератак злоумышленников. В данной статье будет приведено возможное решение - устойчивая к атакам система управления потоком.
Всем привет! На связи команда ad-hoc аналитики X5 Tech.
Сегодня подробно обсудим применение стратификации для повышения чувствительности оценки AB экспериментов.
Для начала предлагаю вспомнить очень старую, но мудрую сказку Шарля Перро про кота в сапогах:
Кот, доставшийся по наследству одному из сыновей мельника, не просто стал его слугой, энергичным и находчивым. Котяра отличился умом и сообразительностью, благодаря смекалке он помог своему хозяину добиться успеха, стать богатым и завоевать сердце красавицы - принцессы…
Выражении «купить кота в мешке» описывает не менее старинный способ мошенничества:
Метод «продать кота в мешке» применялся на ярмарках, когда человеку, желающему купить молочного поросёночка или кролика, давали мешок, в который, вместо зайки или хрюшки, незаметно подсаживали кота. В настоящее время «купить кота в мешке» означает покупку какого-то товара или услуги без понимания реальной ценности, не особо разбираясь в его свойствах и назначении, не проверяя качество, поверив на слово ловкому продавцу.
Карма была одним из первых механизмов, появившихся на Хабре. И сколько она существовала, столько же времени были посты о том, что она работает не так, как ожидает конкретный автор. И что если срочно не принять меры, то Хабр вот-вот загнётся.
Большинство предложений разбивались о какие-то специфические особенности Хабра и ситуации, которые изначально не брались в расчёт. Иногда присутствовало здоровое зерно логики. Встречались и чрезмерно сложные фантазии. Мы читали каждый такой пост и комментарии к нему, мотали на ус, делали какие-то расчёты, но всё же не спешили вносить изменения. В функцию, которая может и не идеально, но всё же 15 лет проработала основой пользовательской регуляции.
Но сегодня мы анонсируем два изменения в механизме кармы.
И снова всем привет!
На этот раз рассмотрим извлекающие методы, которым нужны эталонные рефераты для обучения. При этом эти методы всё ещё могут лишь выбирать предложения из оригинального текста. К методам этой группы и относятся описываемые ниже SummaRuNNer и BertSumExt.
Статьи цикла:
1) Постановка задачи автоматического реферирования и методы без учителя
2) Извлекающие методы автоматического реферирования ⬅️
3) Секреты генерирующего реферирования текстов
Есть такой миф, что открытое программное обеспечение более качественное и безопасное, чем закрытое. Много раз это обоснованно ставилось под сомнение. Существует примеры, когда в открытом коде находили эпичные уязвимости, которые скрывались от разработчиков и пользователей долгие годы. Я считаю, что качество проекта зависит от того, как руководители разработки построили процесс и какие методологии/инструменты используются, а не от того, открыт или закрыт проект.
Тем не менее по-прежнему живо поверье, что открытый проект — это хорошо. Мол, тысячи глаз людей могут изучать код, и кто-то да заметит ошибку. Мысль развивать не буду, думаю, вы понимаете, что я имею в виду.
Неотъемлемым атрибутом таких компаний, как Uber, Twitter и LinkedIn, являются обновления в режиме реального времени: уведомления, сопровождающие вашу поездку, в Uber, твиты друзей и полезные советы отраслевых экспертов можно, которые получить и переслать в течении нескольких секунд. Как только информация попадает в сеть, она сразу становится доступной для всех вокруг. Пользователям всегда будет нравится эта простая и быстрая доступность информации - они всегда находятся в поиске подобных улучшений качества их жизни.
Одним из главных требований к каталогу является возможность быстро искать и находить его элементы по различным критериям.
Существует множество подходов к реализации таких требований. Это и nosql решения и механизмы работы с json в реляционных СУБД. До nosql эпохи, решать такие задачи приходилось средствами реляционных БД.
Основная причина по которой реляционные СУБД плохо подходят для решения таких задач это разнообразие характеристик товаров. Набор характеристик к примеру для одежды и смартфонов будет совершенно разный. В самом деле не создавать же для каждой категории товаров отдельную таблицу с со своим набором реквизитов.
По этой причине в большинстве случаев в реляционных БД используется EAV (Entity Attribute Value) модель данных в тех или иных вариациях.
Недостатков у такой модели множество. Чаще всего EAV модель критикуют чрезмерную сложность, так же за то, что по сути схема данных храниться в самих данных.
Есть мнение, что EAV вообще является анти паттерном, что тоже не лишено оснований, однако надо заметить, что есть и другое мнение, что лучше такая схема, чем вообще отсутствие таковой.
Рискуя навлечь на себя гнев сообщества хочу представить свой вариант реализации каталога. Это не совсем EAV, скорее его по мотивам.
Я использовал его в различных проектах много лет, его достоинства чрезвычайная простота, действительная универсальность и хорошая скорость выборки, что на первый взгляд не кажется очевидным.
Всё описанное далее предполагает использование СУБД Postgresql.
Мы подготовили путеводитель по законам и подзаконным актам в области ИБ, схему для базовой навигации и поиска решений распространенных проблем.
Она сбережет время и поможет найти документы, в которых прописаны те или иные требования по защите информации, инструкции по работе с различными видами данных, состав проектной документации и так далее.
Думаю, многих любителей электроники зацепила волна обсуждений видео на канале Veritasium ( EN | RU ). Я его видел в рекомендациях на YT, но смотреть не стал, так как заголовок «Большое заблуждение об электричестве», скорее, оттолкнул. Через какое-то время мой друг-физтех задал мне задачу из этого видео, я интуитивно выбрал тот ответ, который был указан как правильный в видео. Но потом в рекомендации YT полетели «В чём ошибся Veritasium?» и так далее, тут я уже не смог пройти мимо. И делюсь своими мыслями.
В настоящее время информационные технологии достигли высочайшей степени автоматизации разработки программного обеспечения. Мы умеем разрабатывать сложные распределённые приложения в кооперации многих команд, разделив систему на части так, чтобы минимизировать зависимость между подсистемами. У нас есть многочисленные техники и методики, полученные на основе огромного опыта создания программных систем, которые объясняют, как именно лучше выделять и отделять предметную область и другие части из системы. Мы умеем так изолировать эти части, что можем менять фреймворки для различных уровней архитектуры, использовать разные универсальные языки программирования (УЯП) и всё это существует вместе, масштабируется, выдерживает большие нагрузки, позволяет выполнять доработку компонентов, не переписывая всю систему. По большей части. Можем, когда хотим.
Прекрасно! Но почему мы до сих пор этого не делаем? Почему так много времени уделяем той части программной составляющей, которая не имеет отношения к предметной области – интерфейсу пользователя, вспомогательным слоям, работе с базой данных и постоянному связыванию этих частей с кодом предметной области в различных фреймворках? Неужели это настолько важно? Почему мы часто начинаем разработку с продумывания интерфейса между компонентами вместо того, чтобы просто писать логику предметной области? Из раза в раз. Уже много лет. Несмотря на технические возможности делать всё правильно.
