КМК, паниковать рано. В любом случае, либо будет форк под более либеральной лицензией под эгидой тех же KDE или KDAB. Либо QtC будет вынуждена более лояльно относиться к сообществу.
Я, честно говоря, за форк, так как QtC ударилось в Automotive, QML и прочий Embedded, хотя от Qt, чтобы соответствовать времени, требуется совсем другое: полноценный веб/мобильный тулкит. А вот у тех же KDE есть Kirigami и большой ряд других вещей в KDE Frameworks, которые неплохо было бы включить в новый форк.
А насчёт перехода на другой стек технологий варианты есть: wxWidgets, Electron+JS, gtkmm и другие. Но торопиться пока не нужно, с Qt всё будет хорошо.
По поводу престижности высшего образования согласен, нужно увеличивать престижность.
Для этого необходимо:
Перестать требовать наличие высшего образования на должностях, которые фактически его не требуют (в IT с этим более-менее, хотя встречаются странные работодатели).
Увеличивать престижность колледжей и техникумов, тогда студенты, которые не рассчитывают идти в науку, будут поступать в колледж.
(главное) Убрать призыв в армию, из-за которого около половины студентов стремятся в вуз, лишь бы получить отсрочку.
По поводу проектного образования. Я полностью согласен с необходимостью введения проектного образования в школах и вузовских- (и бизнес-) оценок результатов (вместо ЕГЭ, разумеется). Это полезно и для мотивации к обучению и в будущем поможет открывать для себя интересные и полезные идеи.
"Сириус" я считаю шагом не в правильном направлении, а куда-то в сторону по нескольким причинам:
Он рассчитан на каких-то специальных детей, и не факт, что методы преподавания можно будет перенести на общеобразовательные школы. Нужно внедрять сразу в общеобразовательные школы и корректировать общеобразовательную программу.
Будучи, фактически, закрытыми клубами, такие "спецшколы" нарушают принцип равного доступа к образовательным технологиям и фактически дискриминируют других обучающихся.
Являясь пет-проджектом президента, он отвлекает на себя внимание и деньги, которые нужно потратить на реформу системы образования в целом, а не пытаться построить одну супер-школу за баснословные деньги (половина из которых отправилась в карманы "правильных людей").
И да, несколько таких школ, которые планируется воткнуть в разных регионах к 2025 — это тоже зло, так как к ним тоже применимы п. 1, 2 и 3 выше.
Сириус — на мой взгляд, это одна из самых крутых вещей, который были когда-либо сделаны в нашем образовании. Сама идея о том, что дети могут учиться и создавать что-то нужное обществу, хоть и не нова, но не может не радовать. Во многих конкурсов проектов, о которых мы говорили выше, главный приз — поездка в Сириус.
А, по-моему, совсем наоборот. Сириус — это катастрофа. Проблемы все те же, что и при любой другой гиперцентрализации: оттягивание на себя денег и фокуса внимания системы образования. Вместо развития школ и университетов, в которых учатся >99% населения, развивается некоторая единственная и неповторимая "школа для избранных" с мутными критериями отбора. Получается такой вот "объект гордости", когда остальное образование в глубокой яме.
Сейчас более продвинутый стек — fastapi + pydantic. Преимущества перед aiohttp — наличие переиспользуемых middleware, совместимость с ASGI, возможность использовать uvloop без каких-либо изменений в коде.
Нет, вы не правы. Приложения нужны, в первую очередь, разработчикам для достижения их личных целей. Цели могут быть разные: самообразование, строчка в резюме, личный бренд, продажа за деньги, оказание услуг и т.д. Исходя из целей и ресурсов разработчики выбирают инструменты.
Если цель — быстро и без головной боли поставлять приложения юзерам — разработчик выберет snap/flatpak/appimage, потому что вне зависимости от дистрибутива у разработчика всегда будут одни и те же версии зависимостей и простая доставка приложения и обновлений до пользователя. И не придётся иметь дела с зоопарком дистрибутивов и их версий.
Если бы при выборе технологий всегда руководствовались совершенством технологий или мнением группы "продвинутых" людей, то мы бы не увидели многих приложений на electron, отжирающем память, таких как slack, postman, visual studio code, skype и прочих. Но они существуют и очень успешны.
Да, snap плох и всё такое. Для пользователей. А представьте себя на месте разработчика приложений. Нужно опакетить приложение для ubuntu, fedora, slackware, debian, arch… и ещё с десяток дистрибутивов. Надеяться на мейнтейнеров в поставке свежих версий приложений не приходится. С библиотеками швах, новых нет и всё такое.
Snap (и flatpak, и appimage) — это штуки для разработчиков, который сильно упрощают жизнь, потому что не нужно думать о зоопарке дистрибутивов и деплой упрощается в разы.
Для этого есть GPON, который как раз предназначен, чтобы тащить им последнюю милю до частников. По цене он достаточно выгоден для провайдеров: сеть пассивная и построена на пассивных делителях. Да и по скорости он вполне хорош.
Для Python есть замечательный фреймворк Scrapy, который предназначен для написания веб-краулеров. Их коробки поддерживает многопоточность и прочие вкусные штуки.
Для GraphQL, в таких случаях, имеет смысл писать отдельный API Gateway, который будет делать запросы к остальному беку по HTTP API, преобразовывать и отдавать наружу GraphQL.
Совершенно не согласен с позицией, что за онлайн-встречами будущее. Во встречах важно личное общение, и именно в этом их ценность.
В планах у них есть добавление чего-то типа buildah для сборки, что позволит собирать без запущенного докер-демона, но пока нет.
Подмяли в хорошем смысле, конечно. Я помню Eclipse ADT и был очень доволен, что теперь Android Studio основан на IDEA.
Учитывая, что джеты в сначала подмяли под себя Android Studio, это не выглядит каким-то сюром.
Что мешает отредактировать статью прямо сейчас?
Преимущество 5 ГГц для дома в том, что стены гасят его сильнее и "пятёрка" не особо выходит за пределы квартиры, загрязняя эфир.
Если сравнивать с KDevelop, то IntelliJ — тот ещё тормоз.
КМК, паниковать рано. В любом случае, либо будет форк под более либеральной лицензией под эгидой тех же KDE или KDAB. Либо QtC будет вынуждена более лояльно относиться к сообществу.
Я, честно говоря, за форк, так как QtC ударилось в Automotive, QML и прочий Embedded, хотя от Qt, чтобы соответствовать времени, требуется совсем другое: полноценный веб/мобильный тулкит. А вот у тех же KDE есть Kirigami и большой ряд других вещей в KDE Frameworks, которые неплохо было бы включить в новый форк.
А насчёт перехода на другой стек технологий варианты есть: wxWidgets, Electron+JS, gtkmm и другие. Но торопиться пока не нужно, с Qt всё будет хорошо.
А вот нужны, потому что без патентов:
По поводу престижности высшего образования согласен, нужно увеличивать престижность.
Для этого необходимо:
По поводу проектного образования. Я полностью согласен с необходимостью введения проектного образования в школах и вузовских- (и бизнес-) оценок результатов (вместо ЕГЭ, разумеется). Это полезно и для мотивации к обучению и в будущем поможет открывать для себя интересные и полезные идеи.
"Сириус" я считаю шагом не в правильном направлении, а куда-то в сторону по нескольким причинам:
И да, несколько таких школ, которые планируется воткнуть в разных регионах к 2025 — это тоже зло, так как к ним тоже применимы п. 1, 2 и 3 выше.
А, по-моему, совсем наоборот. Сириус — это катастрофа. Проблемы все те же, что и при любой другой гиперцентрализации: оттягивание на себя денег и фокуса внимания системы образования. Вместо развития школ и университетов, в которых учатся >99% населения, развивается некоторая единственная и неповторимая "школа для избранных" с мутными критериями отбора. Получается такой вот "объект гордости", когда остальное образование в глубокой яме.
Или они просто поставят pytesseract и ничего не изменится.
Сейчас более продвинутый стек — fastapi + pydantic. Преимущества перед aiohttp — наличие переиспользуемых middleware, совместимость с ASGI, возможность использовать uvloop без каких-либо изменений в коде.
Нет, вы не правы. Приложения нужны, в первую очередь, разработчикам для достижения их личных целей. Цели могут быть разные: самообразование, строчка в резюме, личный бренд, продажа за деньги, оказание услуг и т.д. Исходя из целей и ресурсов разработчики выбирают инструменты.
Если цель — быстро и без головной боли поставлять приложения юзерам — разработчик выберет snap/flatpak/appimage, потому что вне зависимости от дистрибутива у разработчика всегда будут одни и те же версии зависимостей и простая доставка приложения и обновлений до пользователя. И не придётся иметь дела с зоопарком дистрибутивов и их версий.
Если бы при выборе технологий всегда руководствовались совершенством технологий или мнением группы "продвинутых" людей, то мы бы не увидели многих приложений на electron, отжирающем память, таких как slack, postman, visual studio code, skype и прочих. Но они существуют и очень успешны.
При обновлении он не удалится, особенно, если его используют какие-то приложения. А третий нужно запускать как python3, дабы не было путаницы.
Да, snap плох и всё такое. Для пользователей. А представьте себя на месте разработчика приложений. Нужно опакетить приложение для ubuntu, fedora, slackware, debian, arch… и ещё с десяток дистрибутивов. Надеяться на мейнтейнеров в поставке свежих версий приложений не приходится. С библиотеками швах, новых нет и всё такое.
Snap (и flatpak, и appimage) — это штуки для разработчиков, который сильно упрощают жизнь, потому что не нужно думать о зоопарке дистрибутивов и деплой упрощается в разы.
Для этого есть GPON, который как раз предназначен, чтобы тащить им последнюю милю до частников. По цене он достаточно выгоден для провайдеров: сеть пассивная и построена на пассивных делителях. Да и по скорости он вполне хорош.
Только вот обновиться нужно, да и софт пересобрать. Осталось всего 18 лет, чтобы сделать это.
Для Python есть замечательный фреймворк Scrapy, который предназначен для написания веб-краулеров. Их коробки поддерживает многопоточность и прочие вкусные штуки.
Для GraphQL, в таких случаях, имеет смысл писать отдельный API Gateway, который будет делать запросы к остальному беку по HTTP API, преобразовывать и отдавать наружу GraphQL.