Задача не из лёгких, но решаемая... По моему скромному наблюдению.
Сейчас эпоха перемен и трансформаций. Тенденции зародились намного раньше, было тяжело с поиском и 10 лет назад. А сейчас многократно усложнилось.
Сразу скажу - пересидеть не получится. Изменения необратимы.
Корпорации - это фабрики грёз. А каталоги вакансий - это их витрина. То, что скрывается под "этическим корпоративным" языком, когда то имело суть конкретных задач для самых избранных. Сейчас же, на этом языке может говорить каждый, а суть давно потеряна. Ложь идёт не от корысти, а от бессилия.
В этом и состоит суть перехода. От напильника - к смыслу. От обёртки - к способу мышления.
Соискатель покупает не позицию, а источник мышления и вдохновения. Покупает, конечно, за своё время. Бизнес продаёт "огонь", магнит для притяжения истинных искателей.
Если отбросить лирику, то начинайте кормить людей правдой. Создайте им вызов. Конкретно и без воды. Напишите уже в вакансии, что конкретно вам нужно сделать и почему это так важно. Дайте возможность вам что-то предложить. Притягивайте не знатоков, а исследователей. Сильнее не тот, кто знает "var" в JS, а тот, кто видит глубже. Т.е. может разложить стратегию движения по этапам, с объяснением каждого этапа. LLM тут не поможет просто потому, что не обучена на внутренних коммерческих практиках. Т.е. 90% реальной честной информации от неё скрыто. Поможет только опыт, исследование и вдумчивость.
Соискателям следует искать то, что зажигает. А зажигает - значит мотивирует. А мотивация вовлекает в желание помогать и проявляться. Расскажите, как именно вы готовы раскрыться и проявить себя по этой задаче, на этой позиции, в этой компании, именно сейчас. Не ждите технических вопросов - задавайте их сами! "Как у вас устроено то, или это?" "А почему именно так?". Хвалите, радуйтесь и накидывайте решения. Но будьте честны. Учитесь говорить "я не знаю" и не бойтесь учиться. Помните: не бизнес покупает вас, а вы покупаете бизнес, который должен будет вас кормить и о вас заботиться, в обмен на ваше личное время.
Будущее - это площадки обучения инженерному мышлению, подготовки нейронных связей к определенному состоянию. Оценка - не за навыки, а за гибкость и глубину.
Будущий спрос не в знатоках языков и технологий, а в опытных бото-водах, способных направить рой машин. Оценка по уровням мышления и способности создавать смысл.
При всём уважении к команде исследователей, ума не приложу, как они рассчитывали полезность ответов, не получая обратной связи. Это всё равно, что самому себе отзывы ставить на фрилансе: "Я сэкономил тысячи часов своим клиентам, уж мне-то лучше знать!" Чего скромничать? Сразу бы рассчитали сколько тысяч долларов сэкономил каждый пользователь:) А там и до "мотивированного" повышения цен раз 5 не далеко...
Очень основательное исследование, спасибо! На минутку даже показалось, что автор сам является одним из разработчиков модуля. 😊
Тем не менее, присоединюсь к предыдущим комментариям. PyDantic - это не замена dataclass, он решает другие задачи. Тяжело, сложно, монструозно. Сам по себе состоит из двух модулей, с внутренней сериализацией структур с Python в Rust, и обратно. К тому же, тянет за собой ещё 3 сторонних модуля...
Основное преимущество pydantic в том, что то, что он делает - делает неплохо и достаточно стабильно. Проверено годами. Плюс, его возможности относительно легко встроить в свою собственную мета фабрику классов. Это хороший плюс относительно альтернативных библиотек, которые создают изолированные объекты и общаются с внешним миром через свои специализированные конверторы.
На своём опыте испытал те же самые проблемы и с первым "бананом":
Модель не понимает частичку "не".
Модель плохо понимает относительные наречия "немного", "чуть-чуть" итд
Один объект желательно описать в одном предложении. Фраза "мужчина одет в куртку. Он стоит у стены" может быть расценена, как два человека. Иногда помогает ввод имени, например, "Андрей одет в куртку. Андрей стоит у стены"
Если описано большое количество деталей, часть из них будет обязательно потеряна. Лучше добавлять детали по чуть-чуть встречными генерациями.
Камеру достаточно сложно правильно расположить с первого раза. Проще ей управлять встречными генерациями "камера подлетает к ...", "поворачивается", итд
Очень хорошо работают референсные изображения, так как, они направляют "фантазию" модели в нужное русло. Однако, будьте осторожны, потому что, из референсов берутся не только объекты, но и общая стилистика. Например, мультяшный референс полностью разрушит ваш фото реализм, даже, если упрямо будете упрашивать в промпте.
Модель плохо работает с лицевыми эмоциями, делая упор на улыбки и позитив. Поэтому, эмоции надо детализировать многословно и детально, если вам нужна "драма", например.
И да, модель лучше всего работает на том, что чаще всего встречается в сети. Например, может не понять ваше описание вымышленного устройства или, скажем, существа. А также, гораздо лучше рисует женщин, чем мужчин 👯
Ну и не забываем про цензуру:
полёт над реалистичным городом - бан
летящий дрон - скорее всего, бан
дети до 18 - скорее всего, бан
торговые марки или что-то похожее - бан
что, угодно, что вы не ожидали, но планировали сделать - возможно, бан Единственный плюс - за бан деньги не берут.
SQL Express абсолютно бесплатный и даёт достаточно щедрые лимиты из коробки. Основное преимущество его в том, что, если вы вошли в зоопарк решений от Microsoft примерно вначале нулевых, когда это было ещё популярно, то вам уже, скорее всего уже не выбраться.
В то время MsSQL был действительно чем-то прорывным и очень удобным. Настолько, что на нём даже писали полноценный Тьюринг-код.
Томик "SQL Server 2000" на 500+ страниц был долго моей настольной школьной книгой. Такого трепета и уважения к базам данных я не испытывал ни до, ни после.
Жаль, что книга оказалась намного лучше самого продукта... Но это уже другая история :)
Согласен с тем, что в Python (желательно было упомянуть это в заголовке статьи) работа с датами из коробки выполнена не очень элегантно. Лучше, чем во многих других языках, но всё ещё недостаточно.
Однако, в плюсах описано удобства для веб приложений и API, которые не очень понятны. Веб приложениям как раз выгоднее получать и отдавать время в UTC+0 для того, чтобы клиентский модуль мог провести локальные вычисления под зону пользователя.
С русификацией разницы времени приятно видеть. Однако, почему в примере ниже вывод "красивой даты" уже не русифицирован?
В целом, полезное исследование. Желаю автору более предметно проработать применимость и, кто знает, может и найдёт своего ценителя. Из весьма логичного продолжения, предложил бы подать commit на рассмотрение в ядро Python. Маленьким радостям там тоже бывают рады.
У меня возврат на "домашний экран" чаще возвращает на боковой экран, с которого я запускал последнее приложение, так что приходится экран смахивать раза 2, а иногда 3, если я запускал из полного списка приложений
Большой блямбой можно, конечно, сделать, но это уже не самый очевидный трюк. Понадобится особый лаунчер.
На кнопочном не надо "выцеливать" кнопки - они вот, под рукой :) Цифра = буква. Например, найти "мама" = 52... Найти "андрей" = 253...
Забыл добавить, что во время поиска контакта любит вылетать какое-нибудь "супер-пупер" важное уведомление, которое эту строку поиска скрывает напрочь. Приходится отмахиваться, как от мухи. А потом судорожно вспоминать: "а что же там такое было"?
на тех телефонах, которые для звонков
Фраза сделала мой день :)))
Я не фанат кнопочных телефонов. Скорее, хочу передать ощущения эргономики, которые были действительно удобны, и которые давно забыты. А кнопки... может и действительно поспешили убирать все сразу.
Посыпаю голову пеплом. Не поленился, нашёл у себя несколько старых фото на этот телефон. Даже скрипт написал по поиску по EXIF. Что сказать... Действительно, сочные, живые... однако, размытость и зернистость совсем уже не вызывает тех самых эмоций. Интересно, получается, устроен мозг - он больше помнит эмоции, чем реальные факты :) Когда мы пересматривали эти фото в 2008-2010, эмоций было гораздо больше... Даже, больше, чем вызывают современные аппараты. Спасибо, собственно, что вернули на землю. Но в остальном, телефон был действительно удобный. Я так не радовался ни до, ни после.
По поводу современных моделей: вопрос даже не в оборудовании, и ни в умной обработке - есть какой-то тонкий ускользающий смысл... Что мы действильно сохраняем и для чего?
Самое ценное в разделе "А как надо?". Остальное как-то сильно размыто красноязычным разумом 🙂
От себя добавлю, что бизнесу, использующему ИИ также важно донести риски отказов этого самого ИИ. То есть, работа не должна быть парализована, если какой-то облачный сервис отвалится. А люди должны быть обучены, как жить по старинке)
Больше претензии не к опен сорсу. Тут всё понятно, ребята стараются, как могут. Больше претензия к коммерческому. Тот же Андроид - сколько ему лет - жутко неудобный. Адресная книга и звонилка - будто сделано школьником за один вечер. Пока кого-то наберёшь - весь экран облапаешь. И так во всём. Ощущение, что это не телефон, а какая-то экспериментальная консоль с прилепленым изолентой телефоном. До сих пор скучаю по кнопочному sony ericsson k810i... Любой контакт находился и вызывался на 3 физических нажатия кнопки. Перезвонить - два нажатия. Камера запускалась и фоткала одной кнопкой. А качество снимков на 3M пикселя с ксеноном, которые она делала, я уже почти 20 лет жду на флагманах... Всё как-то усложняется, добавляются свистелки и перделки, картиночки, декорации, безопасность, персонализированность, ИИ, прости б-же... А удобство целевого использования - зачем? Я на нём читал книги и новости, слушал музыку. Был даже Opera Mini и онлайн мессенджер. Вместо громозких банковских приложений - компании наоборот делали облегчённые версии сайтов, которые грузились секунды даже через GRPS. Ничего лишнего - всё строго по делу. В общем, я могу продолжать долго ))
Все эти разговоры про неравенство и несправедливость, как правило, упираются в нежелание больше платить. Логично же предположить, что если корпорации продают вам дешёвый аппарат, то, скорее всего, товаром являетесь вы.
На самом деле, я и сам техногик. Люблю прошивать и дорабатывать. Но у меня больше претензии не к слежке, а к качеству софта. Я бы даже сказал к сложившейся культуре: делать быстрые негодные продукты без уважения к пользователю, и откровенно врать. Но это совсем другая история...
Очень жизненно, прямо каждую боль на себе прочувствовал, пока читал.
Крайне недооценённая тема, полезная даже для тех, кто только начинает свой стартап. Грамотное проектирование роста с самого начала помогает избежать потребности в дорогих решениях и дюжинах инженеров в будущем.
От себя бы ещё добавил несколько. Боли много не бывает.
Определиться, какие таблицы нуждаются в шардировании. Действительно ли у нас выросла таблица пользователей, или всё-таки их данные (заказы, транзакции, статьи, сообщения)? Возможно, пользователей можно отделить, а данные уже шардировать.
Посмотреть, можем ли мы провести партиционирование исторических данных. Это умеют СУБД, и это не сложно.
Можем ли мы часть данных убрать в холодный архив и вырезать из горячей базы? Радикально? Зато надёжно.
Можем ли мы ввести лимиты по доступу к данным на уровне тарификации клиентов? Ограничить количество обращений одним, и снять ограничения другим. Баланс нагрузки под контролем.
На какие дополнительные риски мы попадаем, если у нас персональные данные, прости г-ди, разлетаются по шардам?
А оно вам точно надо? Этот вопрос повторяю за автором. Можно даже сказать горизонтально шардирую ) Если вы не владелец проекта, то убедитесь сначала, что ваши старания и ответственность будут хорошо приняты и вознаграждены. И что боли действительно доходят до начальства. Иначе, бегите...
Спасибо ещё раз за статью. Автору и всем желаю хорошего терпения, выдержки и поменьше болей в этой нелегкой жизни 😊
практичный язык с кучей библиотек и проблем, которые проявляются на больших проектах
это можно сказать про любые языки и библиотеки без исключения, разве нет? особенно, если учитывать, что 90% того, что вы используете, написано энтузиастами в свободное время
На всякий случай, добавлю от себя для размышлений, если когда-нибудь вернётесь в этой проблеме на Python. Сам многократно сталкивался с ограничениями существующих фреймворков, поэтому, для себя отважился написать свой.
Ваш запрос решается примерно так:
class User(DBTable):
name: str
class Order(DBTable):
user: User
status: str
...
q1 = (
User.query('users_with_completed_orders'). # name is just for SQL decoration
select('pk').
filter(lambda x: x.orders.status == 'completed')
)
q2 = User.query()
sub = q2.with_query(q1)
(
q2.select_objects(). # trick to select '*'
select(new_orders_count=lambda x: x.orders.pk.count).
filter(lambda x: (x << sub) & (x.orders.status == 'new')).
sort_by('name')
)
for x in q2:
print(x)
это генерирует немного другой запрос, но с аналогичной логикой
WITH
users_with_completed_orders AS (
SELECT
"user".id AS "id"
FROM "public"."user" AS "user"
LEFT JOIN "public"."order" AS "user__orders"
ON "user".id = "user__orders".user
WHERE
"user__orders".status='completed'
)
SELECT
"user".name AS "name",
"user".id AS "id",
count("user__orders".id) AS "new_orders_count"
FROM "public"."user" AS "user"
LEFT JOIN "public"."order" AS "user__orders"
ON "user".id = "user__orders".user
WHERE
"user".id IN (SELECT * FROM users_with_completed_orders) AND "user__orders".status='new'
GROUP BY
1,
2
ORDER BY
"user".name
то есть, сначала материализуется выбор всех клиентов с законченными заявками, а потом, по нему выбирается список с новыми. Результат примерно такой:
Либо, можно сделать немного менее производительный запрос, зато более короткий:
q3 = (
User.query().
select_objects().
select(new_orders_count=lambda x: x.orders('new').pk.count_distinct).
filter(lambda x: x.orders('new').status == 'new').
filter(lambda x: x.orders('completed').status == 'completed')
)
for x in q3:
print(x)
Здесь соединение с таблицей заявок дважды, но фильтр отбрасывает те записи, по которым не было законченных заявок. То есть, результат тот же.
SELECT
"user".name AS "name",
"user".id AS "id",
count(DISTINCT "user__orders_new".id) AS "new_orders_count"
FROM "public"."user" AS "user"
LEFT JOIN "public"."order" AS "user__orders_new"
ON "user".id = "user__orders_new".user
LEFT JOIN "public"."order" AS "user__orders_completed"
ON "user".id = "user__orders_completed".user
WHERE
"user__orders_new".status='new'
AND "user__orders_completed".status='completed'
GROUP BY
1,
2
Можно оформить ещё через `SUM(CASE ...)`, но получится более громоздко...
По сути, ваша задача появилась из достаточно нестандартных требований. То есть, вы в одном запросе должны и получать статус клиента, и делать по нему аналитику. В идеале, конечно, статус клиента лучше рассчитывать где-то ещё и сохранять. Тогда любая ORM легко справится.
Тем не менее, если фреймворк вам понравится, буду рад челленджам на любые нестандартные запросы ;)
Хорошее, полезное напоминание. Приятно было прочитать, если не брать во внимание достаточно вырожденные примеры.
Я бы ещё добавил:
Не забывать type hints там, где нет очевидной логики на уровне линтеров.
Не забывать про NamedTuples, dataclass для группировки предметных данных.
Обратить внимание на логику разделения модулей. Там есть нетривиальные ходы.
Про list comprehension ничего не сказано, а стоило бы.
На самом деле, все трюки и не перечислить в одной статье. Python даёт очень много мощных инструментов, преимущество которых не всегда лежит на поверхности.
Во первых, у Python есть свои Дзен постулаты (import this). С виду шутка, но по сути, установки очень сильные, которые повлияли на развитие языка на всём протяжении времени.
Во вторых, язык пропитан принципом DRY. Это придаёт некоторую однозначность в решении тех или иных задач, набор отличных хорошо известных и поддерживаемых модулей.
Как бы не было много критики про принудительные отступы, как часть синтаксиса, но, это действительно приучает форматировать свой код.
Всё это создаёт некоторый вайб надёжности, практичности и уважения. Я бы далее сказал, заботы.
Конечно, простота языка относительна. Она заканчивается примерно там, где приходится углубляться в мета классы, перегрузку операторов, декораторы, множественное наследование и функциональное программирование. Можно очень изящно написать абстрактный эффективный код, который вы сами уже через два дня не поймёте 😊 Отдельное недоразумение - перекраска функций в async.
Задача не из лёгких, но решаемая... По моему скромному наблюдению.
Сейчас эпоха перемен и трансформаций. Тенденции зародились намного раньше, было тяжело с поиском и 10 лет назад. А сейчас многократно усложнилось.
Сразу скажу - пересидеть не получится. Изменения необратимы.
Корпорации - это фабрики грёз. А каталоги вакансий - это их витрина. То, что скрывается под "этическим корпоративным" языком, когда то имело суть конкретных задач для самых избранных. Сейчас же, на этом языке может говорить каждый, а суть давно потеряна. Ложь идёт не от корысти, а от бессилия.
В этом и состоит суть перехода. От напильника - к смыслу. От обёртки - к способу мышления.
Соискатель покупает не позицию, а источник мышления и вдохновения. Покупает, конечно, за своё время. Бизнес продаёт "огонь", магнит для притяжения истинных искателей.
Если отбросить лирику, то начинайте кормить людей правдой. Создайте им вызов. Конкретно и без воды. Напишите уже в вакансии, что конкретно вам нужно сделать и почему это так важно. Дайте возможность вам что-то предложить. Притягивайте не знатоков, а исследователей. Сильнее не тот, кто знает "var" в JS, а тот, кто видит глубже. Т.е. может разложить стратегию движения по этапам, с объяснением каждого этапа. LLM тут не поможет просто потому, что не обучена на внутренних коммерческих практиках. Т.е. 90% реальной честной информации от неё скрыто. Поможет только опыт, исследование и вдумчивость.
Соискателям следует искать то, что зажигает. А зажигает - значит мотивирует. А мотивация вовлекает в желание помогать и проявляться. Расскажите, как именно вы готовы раскрыться и проявить себя по этой задаче, на этой позиции, в этой компании, именно сейчас. Не ждите технических вопросов - задавайте их сами! "Как у вас устроено то, или это?" "А почему именно так?". Хвалите, радуйтесь и накидывайте решения. Но будьте честны. Учитесь говорить "я не знаю" и не бойтесь учиться. Помните: не бизнес покупает вас, а вы покупаете бизнес, который должен будет вас кормить и о вас заботиться, в обмен на ваше личное время.
Будущее - это площадки обучения инженерному мышлению, подготовки нейронных связей к определенному состоянию. Оценка - не за навыки, а за гибкость и глубину.
Будущий спрос не в знатоках языков и технологий, а в опытных бото-водах, способных направить рой машин. Оценка по уровням мышления и способности создавать смысл.
Приготовьтесь. Нас ждёт интересное время! 😊
При всём уважении к команде исследователей, ума не приложу, как они рассчитывали полезность ответов, не получая обратной связи.
Это всё равно, что самому себе отзывы ставить на фрилансе: "Я сэкономил тысячи часов своим клиентам, уж мне-то лучше знать!"
Чего скромничать? Сразу бы рассчитали сколько тысяч долларов сэкономил каждый пользователь:) А там и до "мотивированного" повышения цен раз 5 не далеко...
Очень основательное исследование, спасибо! На минутку даже показалось, что автор сам является одним из разработчиков модуля. 😊
Тем не менее, присоединюсь к предыдущим комментариям. PyDantic - это не замена dataclass, он решает другие задачи. Тяжело, сложно, монструозно. Сам по себе состоит из двух модулей, с внутренней сериализацией структур с Python в Rust, и обратно. К тому же, тянет за собой ещё 3 сторонних модуля...
Основное преимущество pydantic в том, что то, что он делает - делает неплохо и достаточно стабильно. Проверено годами. Плюс, его возможности относительно легко встроить в свою собственную мета фабрику классов. Это хороший плюс относительно альтернативных библиотек, которые создают изолированные объекты и общаются с внешним миром через свои специализированные конверторы.
Отличная статья! Спасибо, что поделились опытом!
Не хватает немного подробностей:
Как тестировали? Сами или с помощью агента, и почему так?
На что конкретно ушло 4 часа? Сколько из них работала сама модель? Сколько токенов/денег потрачено?
Предусматривали ли защиту от ДОСа нерелевантными вопросами?
Как предусмотрена обратная связь по удовлетворенности пользователя ответом?
Возможно, было бы неплохо предусмотреть систему замещающих алертов в случае падений или обслуживаний основных сервисов.
Желаю автору и команде успехов, стабильности и меньше вопросов от клиентов! 😎
На своём опыте испытал те же самые проблемы и с первым "бананом":
Модель не понимает частичку "не".
Модель плохо понимает относительные наречия "немного", "чуть-чуть" итд
Один объект желательно описать в одном предложении. Фраза "мужчина одет в куртку. Он стоит у стены" может быть расценена, как два человека. Иногда помогает ввод имени, например, "Андрей одет в куртку. Андрей стоит у стены"
Если описано большое количество деталей, часть из них будет обязательно потеряна. Лучше добавлять детали по чуть-чуть встречными генерациями.
Камеру достаточно сложно правильно расположить с первого раза. Проще ей управлять встречными генерациями "камера подлетает к ...", "поворачивается", итд
Очень хорошо работают референсные изображения, так как, они направляют "фантазию" модели в нужное русло. Однако, будьте осторожны, потому что, из референсов берутся не только объекты, но и общая стилистика. Например, мультяшный референс полностью разрушит ваш фото реализм, даже, если упрямо будете упрашивать в промпте.
Модель плохо работает с лицевыми эмоциями, делая упор на улыбки и позитив. Поэтому, эмоции надо детализировать многословно и детально, если вам нужна "драма", например.
И да, модель лучше всего работает на том, что чаще всего встречается в сети. Например, может не понять ваше описание вымышленного устройства или, скажем, существа. А также, гораздо лучше рисует женщин, чем мужчин 👯
Ну и не забываем про цензуру:
полёт над реалистичным городом - бан
летящий дрон - скорее всего, бан
дети до 18 - скорее всего, бан
торговые марки или что-то похожее - бан
что, угодно, что вы не ожидали, но планировали сделать - возможно, бан Единственный плюс - за бан деньги не берут.
Всем приятного креатива! 😊
SQL Express абсолютно бесплатный и даёт достаточно щедрые лимиты из коробки. Основное преимущество его в том, что, если вы вошли в зоопарк решений от Microsoft примерно вначале нулевых, когда это было ещё популярно, то вам уже, скорее всего уже не выбраться.
В то время MsSQL был действительно чем-то прорывным и очень удобным. Настолько, что на нём даже писали полноценный Тьюринг-код.
Томик "SQL Server 2000" на 500+ страниц был долго моей настольной школьной книгой. Такого трепета и уважения к базам данных я не испытывал ни до, ни после.
Жаль, что книга оказалась намного лучше самого продукта... Но это уже другая история :)
Согласен с тем, что в Python (желательно было упомянуть это в заголовке статьи) работа с датами из коробки выполнена не очень элегантно. Лучше, чем во многих других языках, но всё ещё недостаточно.
Однако, в плюсах описано удобства для веб приложений и API, которые не очень понятны. Веб приложениям как раз выгоднее получать и отдавать время в UTC+0 для того, чтобы клиентский модуль мог провести локальные вычисления под зону пользователя.
С русификацией разницы времени приятно видеть. Однако, почему в примере ниже вывод "красивой даты" уже не русифицирован?
В целом, полезное исследование. Желаю автору более предметно проработать применимость и, кто знает, может и найдёт своего ценителя. Из весьма логичного продолжения, предложил бы подать commit на рассмотрение в ядро Python. Маленьким радостям там тоже бывают рады.
У меня возврат на "домашний экран" чаще возвращает на боковой экран, с которого я запускал последнее приложение, так что приходится экран смахивать раза 2, а иногда 3, если я запускал из полного списка приложений
Большой блямбой можно, конечно, сделать, но это уже не самый очевидный трюк. Понадобится особый лаунчер.
На кнопочном не надо "выцеливать" кнопки - они вот, под рукой :) Цифра = буква. Например, найти "мама" = 52... Найти "андрей" = 253...
Забыл добавить, что во время поиска контакта любит вылетать какое-нибудь "супер-пупер" важное уведомление, которое эту строку поиска скрывает напрочь. Приходится отмахиваться, как от мухи. А потом судорожно вспоминать: "а что же там такое было"?
Фраза сделала мой день :)))
Я не фанат кнопочных телефонов. Скорее, хочу передать ощущения эргономики, которые были действительно удобны, и которые давно забыты. А кнопки... может и действительно поспешили убирать все сразу.
Ну, у меня как-то сложнее получается:
Разблокировать телефон.
Выйти из приложения, которое запущено.
Перейти на главный экран с бокового экрана, который был открыт ранее.
Аккуратно найти и нажать на экране звонилку.
Аккуратно выбрать контакт из последних или натыкать первые буквы.
Откроется контакт со списком номеров - выбрать определённый и нажать.
Выбрать сим карту для вызова или мессенджер (про мессенджеры можно и другим маршрутом).
Звоню :)
Как было на кнопочном:
Джойстик влево.
Джойстик вниз. Возможно, повторить.
Возможно, нажать пару цифр для поиска по T9.
Вызвать.
Понимаете разницу? Я мог набрать вызов хоть на ходу, хоть в кармане, хоть с закрытыми глазами. И всё за 1-2 секунды. Вот об этом я и скучаю )
Посыпаю голову пеплом. Не поленился, нашёл у себя несколько старых фото на этот телефон. Даже скрипт написал по поиску по EXIF. Что сказать... Действительно, сочные, живые... однако, размытость и зернистость совсем уже не вызывает тех самых эмоций. Интересно, получается, устроен мозг - он больше помнит эмоции, чем реальные факты :) Когда мы пересматривали эти фото в 2008-2010, эмоций было гораздо больше... Даже, больше, чем вызывают современные аппараты. Спасибо, собственно, что вернули на землю.
Но в остальном, телефон был действительно удобный. Я так не радовался ни до, ни после.
По поводу современных моделей: вопрос даже не в оборудовании, и ни в умной обработке - есть какой-то тонкий ускользающий смысл... Что мы действильно сохраняем и для чего?
Самое ценное в разделе "А как надо?". Остальное как-то сильно размыто красноязычным разумом 🙂
От себя добавлю, что бизнесу, использующему ИИ также важно донести риски отказов этого самого ИИ. То есть, работа не должна быть парализована, если какой-то облачный сервис отвалится. А люди должны быть обучены, как жить по старинке)
Больше претензии не к опен сорсу. Тут всё понятно, ребята стараются, как могут. Больше претензия к коммерческому.
Тот же Андроид - сколько ему лет - жутко неудобный. Адресная книга и звонилка - будто сделано школьником за один вечер. Пока кого-то наберёшь - весь экран облапаешь. И так во всём. Ощущение, что это не телефон, а какая-то экспериментальная консоль с прилепленым изолентой телефоном.
До сих пор скучаю по кнопочному sony ericsson k810i... Любой контакт находился и вызывался на 3 физических нажатия кнопки. Перезвонить - два нажатия. Камера запускалась и фоткала одной кнопкой. А качество снимков на 3M пикселя с ксеноном, которые она делала, я уже почти 20 лет жду на флагманах...
Всё как-то усложняется, добавляются свистелки и перделки, картиночки, декорации, безопасность, персонализированность, ИИ, прости б-же... А удобство целевого использования - зачем? Я на нём читал книги и новости, слушал музыку. Был даже Opera Mini и онлайн мессенджер. Вместо громозких банковских приложений - компании наоборот делали облегчённые версии сайтов, которые грузились секунды даже через GRPS. Ничего лишнего - всё строго по делу.
В общем, я могу продолжать долго ))
Есть же вполне освоенный рынок защищённых кнопочных (и не только) телефонов для богатых.
Даже хорошая статья на Хабре 10 лет назад была.
Все эти разговоры про неравенство и несправедливость, как правило, упираются в нежелание больше платить. Логично же предположить, что если корпорации продают вам дешёвый аппарат, то, скорее всего, товаром являетесь вы.
На самом деле, я и сам техногик. Люблю прошивать и дорабатывать. Но у меня больше претензии не к слежке, а к качеству софта. Я бы даже сказал к сложившейся культуре: делать быстрые негодные продукты без уважения к пользователю, и откровенно врать. Но это совсем другая история...
Очень жизненно, прямо каждую боль на себе прочувствовал, пока читал.
Крайне недооценённая тема, полезная даже для тех, кто только начинает свой стартап. Грамотное проектирование роста с самого начала помогает избежать потребности в дорогих решениях и дюжинах инженеров в будущем.
От себя бы ещё добавил несколько. Боли много не бывает.
Определиться, какие таблицы нуждаются в шардировании. Действительно ли у нас выросла таблица пользователей, или всё-таки их данные (заказы, транзакции, статьи, сообщения)? Возможно, пользователей можно отделить, а данные уже шардировать.
Посмотреть, можем ли мы провести партиционирование исторических данных. Это умеют СУБД, и это не сложно.
Можем ли мы часть данных убрать в холодный архив и вырезать из горячей базы? Радикально? Зато надёжно.
Можем ли мы ввести лимиты по доступу к данным на уровне тарификации клиентов? Ограничить количество обращений одним, и снять ограничения другим. Баланс нагрузки под контролем.
На какие дополнительные риски мы попадаем, если у нас персональные данные, прости г-ди, разлетаются по шардам?
А оно вам точно надо? Этот вопрос повторяю за автором. Можно даже сказать горизонтально шардирую ) Если вы не владелец проекта, то убедитесь сначала, что ваши старания и ответственность будут хорошо приняты и вознаграждены. И что боли действительно доходят до начальства. Иначе, бегите...
Спасибо ещё раз за статью. Автору и всем желаю хорошего терпения, выдержки и поменьше болей в этой нелегкой жизни 😊
Тогда почему по-вашему, Python столь популярен?
это можно сказать про любые языки и библиотеки без исключения, разве нет?
особенно, если учитывать, что 90% того, что вы используете, написано энтузиастами в свободное время
На всякий случай, добавлю от себя для размышлений, если когда-нибудь вернётесь в этой проблеме на Python. Сам многократно сталкивался с ограничениями существующих фреймворков, поэтому, для себя отважился написать свой.
Ваш запрос решается примерно так:
это генерирует немного другой запрос, но с аналогичной логикой
то есть, сначала материализуется выбор всех клиентов с законченными заявками, а потом, по нему выбирается список с новыми. Результат примерно такой:
Либо, можно сделать немного менее производительный запрос, зато более короткий:
Здесь соединение с таблицей заявок дважды, но фильтр отбрасывает те записи, по которым не было законченных заявок. То есть, результат тот же.
Можно оформить ещё через `SUM(CASE ...)`, но получится более громоздко...
По сути, ваша задача появилась из достаточно нестандартных требований. То есть, вы в одном запросе должны и получать статус клиента, и делать по нему аналитику. В идеале, конечно, статус клиента лучше рассчитывать где-то ещё и сохранять. Тогда любая ORM легко справится.
Тем не менее, если фреймворк вам понравится, буду рад челленджам на любые нестандартные запросы ;)
Хорошее, полезное напоминание. Приятно было прочитать, если не брать во внимание достаточно вырожденные примеры.
Я бы ещё добавил:
Не забывать type hints там, где нет очевидной логики на уровне линтеров.
Не забывать про NamedTuples, dataclass для группировки предметных данных.
Обратить внимание на логику разделения модулей. Там есть нетривиальные ходы.
Про list comprehension ничего не сказано, а стоило бы.
На самом деле, все трюки и не перечислить в одной статье. Python даёт очень много мощных инструментов, преимущество которых не всегда лежит на поверхности.
На копейках расти дадут, на объемах будут скидывать. Слишком очевидная и сладкая ликвидность.
return x in l and l.index(x)Возвращает индекс или False.
Это самый короткий способ. Можно чуть длиннее через тернарный оператор.
Python популярен, потому что мудро спроектирован.
Во первых, у Python есть свои Дзен постулаты (import this). С виду шутка, но по сути, установки очень сильные, которые повлияли на развитие языка на всём протяжении времени.
Во вторых, язык пропитан принципом DRY. Это придаёт некоторую однозначность в решении тех или иных задач, набор отличных хорошо известных и поддерживаемых модулей.
Как бы не было много критики про принудительные отступы, как часть синтаксиса, но, это действительно приучает форматировать свой код.
Всё это создаёт некоторый вайб надёжности, практичности и уважения. Я бы далее сказал, заботы.
Конечно, простота языка относительна. Она заканчивается примерно там, где приходится углубляться в мета классы, перегрузку операторов, декораторы, множественное наследование и функциональное программирование. Можно очень изящно написать абстрактный эффективный код, который вы сами уже через два дня не поймёте 😊 Отдельное недоразумение - перекраска функций в async.