![](http://webcf.waybackmachine.org/web/20201112024918im_/https://habrastorage.org/getpro/habr/avatars/eab/364/193/eab36419344dc0ed056f430c3212263f.png)
Приглашаем на митап «Apache Kafka в вопросах и ответах» 17 ноября в 19:00
- Блог компании Southbridge,
- Системное администрирование,
- Серверное администрирование,
- Управление разработкой,
- DevOps
Вы отправляете кому-то анонимный подарок на НГ, а кто-то отправляет вам. Круговорот счастья!
Хо-хо-хо, я в деле!ping 127.0.0.1 -n 1201 > nul
rundll32 powrprof.dll,SetSuspendState 0,1,0
shutdown -s -t 00
Всем привет! Это очередной выпуск новостей Yii. Как обычно, в выпуске вас ждут релизы Yii 2, прогресс Yii 3, важные вести о Yii 1 и другие новости. Приятного чтения и будьте здоровы. — Александр Макаров
Привет, Хабр!
Я время от времени провожу собеседования, и когда вопрос касается React key, чаще всего я вижу недоумевающий взгляд, намекающий “Да, там и спрашивать вроде нечего?”. Если Вам кажется React key понятным и простым, тогда давайте проведем мини собеседование (данная статья является расшифровкой видео)
Я уже давно не студент, но в свободное время изучаю материалы по Computer Science. Мне нравится получать знания и делиться ими. Недавно я наткнулся на любопытную задачу в известном учебнике "Алгоримы: Построение и Анализ". В этой статье я продемонстрирую принципы динамического программирования, используя эту задачу. Она интересная, не очень сложная и для её решения не требуется писать какие-то дополнительные структуры данных или библиотеки. Формулировка умещается в одно предложение:
Найти самую длинную палиндромную подпоследовательность в слове w
длиной n
.
Кому интересно, прошу под кат.
При создании программного обеспечения все мы, как команда, соглашаемся следовать набору рекомендаций, которые обычно считаются лучшими практиками. Но во время разработки разработчики могут нарушить эти правила по незнанию или нежеланию. Обычно мы полагаемся на ревью кода или инструменты проверки качества кода, такие как SonarQube , PMD и т.д. для проверки таких нарушений. Но некоторые из рекомендаций могут быть решениями, которые нельзя автоматизировать с помощью SonarQube, PMD и т.д.
Например, обычно я хочу следовать приведенным ниже рекомендациям для моих приложений на основе Java:
1. Следуйте трехуровневой структуре (уровни веб, сервис, репозиторий), где любой уровень может взаимодействовать только с непосредственным нижним уровнем, а нижний уровень не должен взаимодействовать с верхним уровнем. т.е. веб-уровень может взаимодействовать с уровнем сервиса, уровень сервиса может взаимодействовать с уровнем репозитория. Но уровень репозитория не может взаимодействовать с сервисным или веб-уровнем, сервисный уровень не может взаимодействовать с веб-уровнем.
2. Если приложение большое, мы могли бы захотеть следовать структуре Package-By-Feature, где только компоненты Web и Service являются public, а остальные компоненты должны быть package-private.
3. При использовании внедрения зависимостей Spring не используйте внедрение на основе поля и предпочитайте внедрение на основе конструктора.
Таким образом, может быть много правил, которым мы хотим следовать. Хорошая новость заключается в том, что мы можем проконтролировать выполнение этих рекомендаций с помощью JUnit тестов с использованием ArchUnit.
Мне очень сильно импонируют namespace'ы в таких языках программирования, как Java и PHP. Настолько сильно, что я даже как-то запилил о них статью на Хабре. С тех пор прошло уже почти два года, но namespace'ы в Javascript за это время так не появились. "А если бы я делал namespace'ы в JS для самого себя, то какими бы они были?" - подумалось мне. Под катом - мои соображения, какие же namespace'ы мне нужны в JavaScript'е.
Эту неделю я решил посвятить потокам данных в SwiftUI. В этой статье мы обсудим разницу между обертками свойств (property wrappers) @StateObject, @EnvironmentObject, и @ObservedObject, поскольку я знаю, что это самая запутанная тема для новичков в SwiftUI.
Зачем нужны обертки свойств в SwiftUI?
SwiftUI использует неизменяемые (immutable) типы структур для описания иерархии представлений. Все представления, которые предоставляет SwiftUI, неизменяемые. Вот почему SwiftUI дает нам набор оберток свойств - для обработки изменений данных. Обертки свойств позволяют нам объявлять себя внутри представлений SwiftUI, но хранить данные вне представления, объявляющего обертку.
Delta Lake 0.4.0 включает Python API и преобразование Parquet в таблицу Delta Lake на месте
Мы рады объявить о релизе Delta Lake 0.4.0, в котором представлен Python API, улучшающий манипулирование и управление данными в Delta-таблицах. Ключевыми фичами этого релиза являются:
- Python API для DML и служебных операций (#89) - теперь вы можете использовать Python API для обновления(update)/удаления(delete)/слияния(merge) данных и выполнения служебных операций (а именно, vacuum и history) в таблицах Delta Lake. Они отлично подходят для создания сложных рабочих нагрузок в Python, например, операций медленно меняющихся измерений (SCD - Slowly Changing Dimension), слияния изменений данных для репликации и операций upsert из потоковых запросов. Для получения более подробной информации читайте документацию.
- Convert-to-Delta (#78) - теперь вы можете преобразовать таблицу Parquet в таблицу Delta Lake на месте без перезаписи каких-либо данных. Эта функция отлично подходит для преобразования очень больших таблиц Parquet, которые было бы довольно затратно перезаписывать в Delta-таблицу. Более того, этот процесс обратим - вы можете преобразовать таблицу Parquet в таблицу Delta Lake, поработать с ней (например, удалить или объединить) и легко преобразовать ее обратно в таблицу Parquet. Для получения более подробной информации читайте документацию.
- SQL для служебных операций - теперь вы можете использовать SQL для выполнения служебных операций vacuum и history. Смотрите документацию для получения дополнительных сведений о том, как настроить Spark для выполнения этих специфичных для Delta Lake команд SQL.
Больше информации вы можете найти в примечаниях к релизу Delta Lake 0.4.0 и в документации по Delta Lake > Удаление, обновление и слияние таблиц.
Здравствуйте, меня зовут Дмитрий Карловский и я… дизайнер. Дизайнер от слова design (проектирование), а не от слова style (дизайн). Я разрабатываю высокоуровневый фреймворк $mol. Одна из основных концепций которого — Лего. То есть это набор очень маленьких кирпичиков с простым и универсальным интерфейсом коммуникации. Комбинируя эти кирпичики в разных комбинациях можно строить приложения любой сложности.
Но, чтобы приложение не выглядело как лоскутное одеяло, а было лаконичным и опрятным, необходимо, чтобы выполнены эти кирпичики были в едином стиле, а располагать их можно было в любой комбинации, не теряя опрятности.
Поэтому, мы разработали математически выверенный концепт дизайна, суть которого можно уловить из следующей шпаргалки:
Далее я расскажу, почему всё именно так, и никак иначе...