https://dbdb.io

Отличный сайт с кратким описание особенностей почти всех существующих баз данных.

Несколько примеров:

etcd: https://dbdb.io/db/etcd
postgresql: https://dbdb.io/db/postgresql
mysql: https://dbdb.io/db/mysql
redis: https://dbdb.io/db/redis
memcached: https://dbdb.io/db/memcached
mongodb: https://dbdb.io/db/mongodb
cassandra: https://dbdb.io/db/cassandra

🧙‍♀️Закончились праздники, возвращаемся к нормальному ритму!

Наш лучший специалист Александр Коваль уже достаточно давно делает python DSL для Elasticsearch elasticmagic.

https://github.com/anti-social/elasticmagic
Документация https://elasticmagic.readthedocs.io/en/latest/

По-сути это query builder для эластика, с АПИшечкой вдохновленной SQLAlchemy. В ридми написано very alpha, но мы этим пользуемся уже несколько лет и дико довольны.

А недавно наш лучший специалист Макс Киндрицкий сделал порт этой библиотеки на TypeScript. Теперь и на ноде можно работать с эластиком без слез на глазах

https://github.com/kindritskyiMax/elasticmagic-js

#python #javascript #elasticsearch #project

🐍 Конец официальной поддержки Python 2 породил очередную волну статей о переезде на третью версию.

Core-разработчик Mercurial, Gregory Szorc описал их историю миграции в двух частях. В первой хронология портирования, во второй - личное мнение автора о процессе миграции и самом Python 3.

Из интересного, первое упоминание Py3 в репозитории самого меркуриала появилось аж в 2008, затем небольшие изменения в C-extensions в 2010 году. Более-менее систематичная работа над портированием началась аж в 2015 году. А закончилась только в конце 2019! Разработчикам пришлось реализовать свой аналог six, т.е. слой абстракции, который скрывает разницу между 2й и 3й версиями. А также хак с импортом модулей, который на лету подменял все неаннотированные явно строки на byte, вместо ставшим стандартным в 3м питоне unicode.

Из личного мнения уже не удивляет фраза про то, что если бы начинали проект сейчас, писали бы его на Rust. Интересная мысль о том, что чрезмерное, по мнению автора, форсирование юникода в языке и стандартной библиотеке сделало Python языком, который не так удобно использовать в системном\низкоуровневом софте. Да и трудно спорить с тем фактом, что для многих первая юзабельная версия 3й ветки были Python 3.4/3.5, а это 5-7 лет с дня первого релиза 3.0.

https://gregoryszorc.com/blog/2020/01/13/mercurial%27s-journey-to-and-reflections-on-python-3/

#python

​​#!Terminate_registration 2020-01-16 23:59:59.99999+00

Коротше, 1 ДЕНЬ ДО КІНЦЯ РЕЄСТРАЦІЇ НА ХАКАТОН Int20h

💻 Хакатон Int20h – одне з найбільших щорічних змагань у сфері ІТ, яке організовують студенти локальної групи BEST Kyiv. Обравши категорію, учасники протягом 20 годин працюють над вирішенням завдань наших партнерів у режимі нон-стоп.

Цього року – ще більше цікавих кейсів, викликів, фану та кодингу! А партнерами, що допомагають нам робити хакатон кращим з кожним роком є такі компанії, як Genesis, EVO, Epam, Valtech, Ubiquiti Networks, Nikelektronika, Pango.co, Techiia і не тільки 😉

Категорії:
🕸 Web
📱 Mobile
📊 Data Science
🔌 Embedded

Обов'язкова умова реєстрації – наявність команди з 2-4 учасників. Якщо не маєш команди - обирай потрібний варіант у формі реєстрації та знаходь однодумців.

🗓 Дати проведення: 22-23 лютого
🏢 Місце проведення: EVO

Мерщій обирай категорію, збирай команду, та реєструйся. Та поспіши, часу залишилось лише до 16.01 включно‼️

У канала @defront день рождения! Мы не раз репостили у себя их обзоры, потому что они крутые - пишут шикарные саммари на интереснейшие статьи о фронтенде.
Желаем умных подписчиков, интересного контента и кайфа от процесса ;) Урааааа!

https://xn--r1a.website/defront/394

🕊 На форуме языка Swift опубликовали планы на будущее.

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

Из интересного:
- Language Server Protocol (API, которое позволяет удобно интегрироваться в редакторы и IDE),
- быстрые билды
- Swift Package Manager
- ABI stability - поддержка разных версий Свифта в одном рантайме

https://forums.swift.org/t/on-the-road-to-swift-6/32862

#swift

📱Раз уж начали про мобилочки

Shopify переходит на React Native. Начали присматриваться к нему еще с релиза в 2015 году. На тот момент были проблемы с производительностью и отсутствовала полная поддержка Андроида.

Современный RN выглядит гораздо более взрослой и стабильной платформой. Провели эксперимент, в котором переписали одно из своих iOS-only приложений и получили кросс-платформенность с 95% общего кода между iOS/Android. Теперь все новое - на React Native.

https://engineering.shopify.com/blogs/engineering/react-native-future-mobile-shopify

#react #reactnative #webpower

Внезапно, про PHP. Комьюнити выбирает как развивать язык, вводить ломающие совместимость изменения и не повторять ошибок Python 2/3, Perl 5/6 и других героев.

Будущее развитие PHP

https://github.com/nikic/php-rfcs/blob/language-evolution/rfcs/0000-language-evolution.md

Никита опубликовал черновик RFC с предложением установить механизм введения в язык новых глобальных или ломающих обратную совместимость фич. И рассмотрел возможные пути решения:

1. Новый язык (P++)
При всех своих недостатках, одно из преимуществ тут в том, что можно делать совершенно радикальные изменения. Например, убрать $ из переменных. Но мы помним судьбу Perl/Raku.

2. Editions (редакции/издания)
Идея позаимствована из Rust, в разработку которого Никита тоже вовлечён.
По сути, это набор обратно-несовместимых изменений, объединенных под одним именем. Такой вариант интересен как с технической так и с маркетинговой точки зрения.

3. Директивы declare на каждую фичу
То есть на каждое крупное изменение вводить отдельную директиву по типу strict_types.
___

Поскольку против нового языка уже неофициально проголосовали и единогласно отмели идею, то дальше Никита рассматривает технические аспекты реализации единшов/директив.
Варианты тут такие:

• Текущая реализация с объявлениями в каждом файле
declare(strict_types=1) или в случае едишнов declare(edition=2020)

• Новый открывающий тег
Например, для едишнов: <?php2020

• Указание директив для пространств имён (RFC)

namespace_declare('Vendor\Lib', [
    'strict_types' => 1,
    'no_dynamic_properties' => 1,
    // ...
]);

• Ввести понятие пакета в PHP
Прототип этого варианта оформлен в виде пул-реквеста.
Пакет надо будет явно объявлять в каждом файле.

<?php

package "nikic/php-parser";

namespace PhpParser\Node;

• Что-то на основе файловой системы
Например добавлять файл .package.php в корне пакета, который будет содержать нужную метаинформацию.

В конце Никита подводит выводу, что оптимальный вариант — это едишны + declare директивы в каждом файле.

☕️ В JavaMagazine опубликовали статью о Records, которые завезут в следующую версию Java.

Records уменьшают бойлерплейт для data-only структур данных, автоматические геттеры и конструкторы. Почему бы и нет?

https://blogs.oracle.com/javamagazine/records-come-to-java

#java

📼 И сразу добью шикарным докладом 1998 (!!!) года Гая Стила про развитие языков программирования.

Крайне рекомендую посмотреть. Во-первых, любопытно как Стил топит за добавление в Java дженериков (привет, golang) и перегрузки операторов. Во-вторых, сама подача материала - не хочу спойлерить, но форма подчеркивает содержание - программистам всегда нужно строить мелкие абстракции чтобы перебраться на более высокий уровень. И важно сделать это просто.

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

https://www.youtube.com/watch?v=_ahvzDzKdB0

P.S. Можете еще почитать о самом Гае Стиле на википедии. Это один из гигантов computer science, и мы стоим на его плечах в том числе

#video

Вспомнил крутую статью с пачкой Serverless паттернов, все про AWS, но и 1в1 на других провайдерах применяется)

Текст можно особо не читать, достаточно картинки глянуть, все просто и понятно.

https://www.jeremydaly.com/serverless-microservice-patterns-for-aws/

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

Спойлер: Dart - да, GoLang - нет. Потому что GC, большой рантайм и негативный опыт использования.

https://fuchsia.googlesource.com/fuchsia/+/refs/heads/master/docs/project/policy/programming_languages.md#Go

#fuchsia #c #cpp #dart #rust #golang

Там FB свой мессенджер переписывает, и эт конечно интересно-полезно, хотя много чего не досказано. Понравились коменты с ХН:

So, they've reduced 1.7M lines of code to 360K. Let's pause here for a moment:

- NumPy is 360K lines mostly C
- Postgres is around 2.1M of C
- Go 1.13 is around 1.5M of Go code
- Rust 1.37 is around 1.2M of Rust code iirc
- core llvm is around 3M of C++ iirc
...
A chat app is 1.7M. A chat app...

Makes me feel sorry for all the time spent/wasted by all those devs, many of whom are unquestionably brilliant and could've worked together on something truly awesome, big and useful. But we all know that doesn't pay the bills and so here we are.

> that includes payments, camera effects, extensive social integrations, stories, GIFs, reactions, games, polls, voice recording, calling, video chat
To be fair, this is part of the problem ^

https://engineering.fb.com/data-infrastructure/messenger/
https://news.ycombinator.com/item?id=22466462

Да, конечно мерять все в SLOC это так себе метрика, но и пренебрегать ею неправильно.

📝 webpack двигается в сторону micro frontends.
Micro frontends - это идея микросервисов переложенная на фронтенд, то есть части страницы делятся на самостоятельные изолированные приложения. Эти части могут быть реализованы разными командами и на разном технологическом стеке.
https://micro-frontends.org

Представим себе крупный сервис с множеством функциональных частей: поиск, фильтры, каталог, реклама, навигация и т.д.
Очень часто эти части могут встречаться на одной странице, но при этом разрабатываться разными командами и с использованием разных подходов к разработке (ведь каждая команда лучше знает "как правильно" ;)). В этом случае встает некоторое количество вопросов, например:

Как разделить большую кодовую базу на микро-приложения?

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

Как части приложения могут "общаться" между собой?

Например, в условиях SPA (single page application) фильтры могут влиять на каталог.

Как обеспечить реиспользование зависимостей?

Например, на странице загружен блок, который использует react и redux. Чуть позже, на страницу, динамически, подъезжает второй блок, который тоже использует react. Проблема в том, что этот блок разрабатывается другой командой, собирается и релизится отдельно от первого. Здесь необходимо обеспечить совместимость двух блоков и реиспользование уже загруженных на страницу зависимостей - второй блок не должен заново загружать на страницу react, а должен реиспользовать уже загруженный.

Около месяца назад было предложено архитектурное решение для webpack https://github.com/webpack/webpack/issues/10352 и буквально несколько дней назад были сделаны первые демо.
Описание решения можно найти тут https://medium.com/@ScriptedAlchemy/bcdd30e02669, а потыкать можно вот эту демку https://github.com/mizx/mfe-webpack-demo

Если коротко, то идея заключается в том, что совершенно разные собранные бандлы могут реиспользовать различные части друг-друга - одни бандлы предоставляют (expose) свои части (например UI-компоненты или целое приложение), а другие бандлы эти части импортируют и используют.
Фича все еще в разработке

#webpack #webpack5 #microfrontends

🎙 Ура, 9 выпуск WatEvoCast! В этот раз про PyConBy'20
Apple Podcast
#watevocast

👩‍💻 Внезапно на hackernews в топ вышла статья на вики про Катерину Ющенко, украинскую программистку, которая написала один из первых адресных языков программирования.

Сейчас развитие этих идей мы видим в указателях (pointers), адресной арифметике и прочих важных штуках.

Катерина Ющенко на Википедиях: укр, рус, англ
Тред на хакерньюз

#person #girlpower #cs

🐍 Вышла очередная альфа следующего релиза Python 3.9. Главное, что нас ожидает:

1. Новые операторы у диктов для слияния (dict1| dict2) и дополнения (dict1 |= dict2). Все существующие варианты решения такой пустяковой проблемы либо достаточно громоздкие, либо неочевидны синтаксически
2. Расширение аннотаций. В данный момент большая часть аннотаций - это аннотации типами. Хотя в целом эта фича имеет гораздо больше потенциал. От валидции, до навешивания новой логики переменной. Новый класс Annotated позволит это исправить
3. Переход на релизный цикл раз в год. До этого конкретной даты не было и релиз происходил тогда, когда разработчики считали что продукт готов

Код фриза для версии еще не произошло, возможно появиться еще что-то интересное.

#python

📺 Регулярные встречи разработчиков Evo по понятным причинам переезжают в онлайн. Прямо сейчас начинаем трансляцию первой такой встречи на ютубе.

Наш лучший специалист Александр Мостовенко будет рассказывать о типизации в TypeScript

https://youtu.be/Yd_otKlrf1I

🍴 Почти лонгрид о том, как git стал главной системой контроля версий. От первых версий Линуса до покупки Microsoft`ом GitHub.

#git

https://www.welcometothejungle.com/en/articles/btc-history-git

Недавно в Firefox была обнаружена проблема с кешированием данных в Twitter. Любой пользователь с физическим доступом к компьютеру теоретически мог прочитать чужие личные сообщения. Мартин Томсон из команды разработки Firefox рассказал, почему это произошло, в статье "Twitter Direct Message Caching and Firefox".

Чтобы предотвратить кеширование контента в браузерах, сайт должен отправить в ответе http-заголовок Cache-Control: no-store. В любом другом случае в Firefox начинает работать механизм эвристического кеширования. Этот механизм используется для предсказания, какой контент может быть закеширован и на какое время. Контент без Cache-Control: no-store сохраняется в кэше на семь дней. Как вы наверное уже догадались Twitter не отправлял этот заголовок в ответе из-за чего в Firefox включался механизм кеширования. Вместо него Twitter отправлял заголовок Content-Disposition, который используется для добавления метаинформации (например, имени файла) к загружаемым файлам. В статье говорится, что в "other browser" (как я понимаю Chrome) наличие этого заголовка отключает кеширование, но это поведение не является частью стандарта.

Какие можно сделать выводы из этой истории? Нужно проверять работу сайта в разных браузерах (Chrome, Firefox, Safari) и не стоит полагаться на поведение браузера, которое не соответствует стандартам.

#firefox #cache #http

https://hacks.mozilla.org/2020/04/twitter-direct-message-caching-and-firefox/