Пользователь
Последние пару лет я помогаю клиентам нашего облака внедрять DevOps-практики и делюсь своим опытом инженера DevOps. К сожалению, вопросы про информационную безопасность возникают у клиентов зачастую тогда, когда уже что-то произошло. У меня как у любителя киберзащиты постепенно накопилась целая подборка ИБ-кейсов, которыми хочется поделиться.
В статье собрал правила безопасности контейнеров, о которых часто забывают, но потом снова вспоминают на поучительных примерах.
У нас в компании много иностранных проектов. Пройти интервью не всегда легко, даже если много и регулярно общаешься на английском. Поэтому наша команда преподавателей создала курс Project Interviews in English, который мы решили сделать доступным для всех желающих. Меня зовут Инна, я координировала создание курса и сегодня поделюсь полезными советами из него.
Как по мне достаточно важная, хотя и холиварная тема. Думаю каждый из нас задавал себе вопросы: "можно не дублировать проверки?", "а не усложняю ли я?", "да как же это сделать нормально?!".
Эта статья аккумулирует в себе те практики, которые мне близки и которых я придерживаюсь в разработке.
Текст рассчитан не на новичков, потому нормально, если по ходу чтения какие-то понятия будут вам неизвестны, я постарался коротко раскрыть их здесь, а также указал ссылки на посты в моём телеграм канале Beer::PHP , которые могут чуть подробнее раскрыть то или иное понятие.
Начнем мы сразу с доменного слоя нашего приложения, то есть с бизнес логики нашего приложения.
В CMake 3.19 и 3.20 был зарелижен CMakePresets.json, который позволяет пользователям указывать общие параметры настройки, сборки и тестирования и делиться ими с другими пользователями. Мы добавили поддержку CMakePresets.json в Visual Studio и создали расширение CMake Tools для Visual Studio Code. Теперь вы можете вызывать CMake с CMakePresets.json в Visual Studio, в Visual Studio Code, в конвейере непрерывной интеграции и из терминалов в Windows, Linux и macOS.
Интеграция CMake Presets теперь доступна в Visual Studio 2019 16.10 Preview 2 и CMake Tools 1.7.
Научный метод, каким мы его знаем, формировался на протяжении тысяч лет в ходе преодоления череды философских кризисов. В этом посте я хочу рассказать про две величайшие проблемы в философии науки и вызовы, стоящие перед ней в настоящем.
Проблема неполной индукции
Знаменитый древнегреческий философ Аристотель в своем трактате «Аналитика» выделяет два вида возможных умозаключений - индуктивное и дедуктивное.
Дедуктивное умозаключение - это логический вывод о частных случаях исходя из общего правила. Индуктивное умозаключение - это логический вывод об общем правиле исходя из частных случаев.
Классическим примером дедукции, которую сам Аристотель называл силлогизм, является следующее рассуждение: все люди смертны (общее правило), Сократ - человек (частный случай), следовательно Сократ смертен (дедуктивный вывод).
Индукцию Аристотель делил на два вида: полную и неполную. Полная индукция - это вывод общего правила на основе свойств всех элементов множества, а неполная - это предположение об общем правиле на основе части элементов множества.
Где же держать бизнес логику приложения?
"Та че уж там парится - прямо в компонентах." - скажут некоторые. И в некоторых ситуациях это правильное и удобное решение.
Но что если мы все-таки хотим чего-то большего? Например, масштабируемости, несколько юзер интерфейсов, лёгкой смены дизайна. Тогда логично разделить приложение на два слоя. Слой бизнес логики и слой представления.
Как написано на сайте reactjs.org, React - это библиотека для создания UI.
А для модели и бизнес логики написано несколько других замечательных библиотек.
Так уж получилось, что проекты, на которых я работал, использовали redux. Поэтому дальше речь про него. А конкретней - про то, как построить бизнес логику в большом react/redux приложении, чтобы потом не закрывать рукой глаза при виде того огромного количества редюсеров, экшенов и так далее и тому подобное.
В наш век распределенных микросервисов постоянно возникают распределенные проблемы. Это самые обычные computer science проблемы, но они распределены по разным серверам или даже разным датацентрам. Для их решения часто выдумывают много разного. Не делайте так, просто возьмите ZooKeeper. Он, несмотря на то что придуман бумерами, просто работает. Он решит немалую часть ваших проблем с распределенными системами.
Привет, меня зовут Сергей и я фронтендер в KTS.
Server Side Rendering часто применяется в разных проектах. Существуют крутые фреймворки для React – NextJS и Gatsby. Но в то же время любой фреймворк диктует архитектуру приложения, а это приводит к проблемам в больших приложениях. Поэтому часто можно встретить собственные сборки для SSR.
В статье описаны шаги создания собственной библиотеки для серверного рендеринга на React.
Разговоры о том, останутся ли верстальщики без работы, длятся годами. Как только появляется новая программа или плагин для автоматизации вёрстки, специалистам начинают тут же пророчить бессрочный отпуск. Но стоит ли всерьёз относиться к таким разговорам?
Уже сейчас есть множество конструкторов, которые позволяют создавать сайты без знания HTML и CSS. Существуют плагины и программы, которые сами создают код на основе макета. Есть даже нейросети, почти полностью автоматизирующие процесс вёрстки. Но ни одна из этих программ всё еще не смогла полностью заменить человеческий труд и лишить верстальщиков работы.
Представляю вашему вниманию руководство по Sequelize.
Sequelize — это ORM (Object-Relational Mapping — объектно-реляционное отображение или преобразование) для работы с такими СУБД (системами управления (реляционными) базами данных, Relational Database Management System, RDBMS), как Postgres, MySQL, MariaDB, SQLite и MSSQL. Это далеко не единственная ORM для работы с названными базами данных (далее — БД), но, на мой взгляд, одна из самых продвинутых и, что называется, "battle tested" (проверенных временем).
ORM хороши тем, что позволяют взаимодействовать с БД на языке приложения (JavaScript), т.е. без использования специально предназначенных для этого языков (SQL). Тем не менее, существуют ситуации, когда запрос к БД легче выполнить с помощью SQL (или можно выполнить только c помощью него). Поэтому перед изучением настоящего руководства рекомендую бросить хотя бы беглый взгляд на SQL. Вот соответствующая шпаргалка.
Это первая из 3 частей руководства, в которой мы поговорим о начале работы с Sequelize, основах создания и использования моделей и экземпляров для взаимодействия с БД, выполнении поисковых и других запросов, геттерах, сеттерах и виртуальных (virtual) атрибутах, валидации, ограничениях и необработанных (raw, SQL) запросах.
Я постараюсь быть максимально лаконичным (надеюсь, без ущерба для полноты изложения материала). Я также постараюсь излагать материал максимально простым языком. Большинство примеров, приводимых в руководстве, заимствованы из официальной документации.
Гитхаб экшены, как я познавал ci/cd
Всем Алоха. Все слышали про ci/cd, про то что он должен быть в каждой компании и то что он упрощает нам жизнь. У всех свой ci/cd.
Кто-то предпочитает Jenkins. Особенно если у вас куча микросервисов, команд и процессов, то при помощи Дженкинса можно достаточно гибко настроить ci/cd в компании. Кто-то использует GitLab actions и для каждого репозитория настраивает свои пайплайны и процессы. Достаточно удобно и просто настраиваемый механизм сборки и доставки артефактов на стенды. Не чуть не хуже GitHub actions. Это было открытием для меня что в GitHub появился такой функционал, о котором мы поговорим позже. Ну и конечно всеми «любимый» скриптовый ci/cd. Пачка скриптов, которые нужно выполнить в определенной последовательности чтобы собрать и задеплоить артефакты. Есть ещё так сказать хэнд мэнуал ci/cd. Но это особый вид извращения, с которым не пожелаю столкнуться никому. В котором нужно собрать артефакты у себя на машине и по какому нить ридми выполнять команды в терминале, лазить по ssh смотреть, что все копировалось, перезапускать сервисы и другие развлечения.
Передо мной стояла задача спроектировать и написать новый сервер для проекта. Изначально я закидывал джарники на сервак руками, чтобы проверить работоспособность и настроить сервер. Хэнд мэнуал деплой. В какой то момент меня это начало бесить и я задумался об автоматизации этого процесса. Как вы понимаете девопса или того кто шарит в этом у меня под рукой в компании не оказалось. Очень круто, если у вас есть такой человек. У меня был выбор сделать скрипт деплой, чего я искренне не хотел, потому что в целом не любитель копаться в терминале и скриптах, когда этого можно избежать. Поднять дженкинс и настроить там джобы и пайплайны. Вариант оч классный для большой компании, а мне нужен деплой лишь одного сервера, а не тысячи микросервисов. Да и чего таить, знаний как настраивать дженкинс с нуля у меня было чуть меньше чем ноль.
Собрали для вас много полезных ссылок, шпаргалок, мероприятий и книжек в нашем новом полезном дайджесте. Оставайтесь с нами – станьте частью DevNation!
- Ребята, кажется, вы таймаутите. Вот трейс, на котором видно, что мы не дождались от вас ответа за 2 секунды.
- Ничего подобного, у нас все норм — мы за 200 миллисекунд отвечаем в 99% запросов. А вот вы по какой-то причине часто преждевременно обрываете соединение.
Такой разговор однажды произошёл у нас в Ozon между моей командой личного кабинета продавца и коллегами, которые пишут сервис аутентификации. Причина проблемы оказалась в дефолтных настройках Go для пула HTTP-соединений. Как так вышло, как мы обнаружили проблему и как исправлять подобные ситуации в микросервисах на Go – об этом моя сегодняшняя история.
Автор нашей новой переводной статьи утверждает, что Knative — лучшее, что только могли придумать во Вселенной! Вы согласны?