А разве отдельной бесплатной лицензии для студентов больше нет? Не знаю, как сейчас, а раньше туда входила вся линейка корпоративных IDE, включая CLion.
Вот именно, оно чисто рекомендательный характер носит, точно так же, как и одинарное подчёркивание. И даже по официальному гайду PEP 8 не полагается в __ никаких особых смыслов вкладывать (относительно _), а использовать исключительно для символов, которые могут нежелательно в дочернем классе переопределиться.
Нет, всё, что делает двойное подчёркивание - автоматически добавляет в начало имени члена имя класса. Это инструмент для избежания конфликтов имён между родителем и наследником, не более того.
Плохой совет. Правильный совет - если пользуетесь централизованным хостингом, настраивайте там protected branches. Расчитывать на то, что никто никогда не ошибётся - безумие.
кнопки "вперёд" и "назад" поверх ролика должны переключать видео (нужно редко), а не мотать (нужно постоянно)
Главная проблема даже не в этом, а в том, что быстрый двойной тап таки перематывает видео, а если чуть-чуть задержаться, успевают появиться эти кнопки и поведение кардинально меняется.
Я наоборот, на дух не переношу проводные мыши. Остановился на офисных логитеках, но из тех, что чуть подороже и с дополнительными кнопками. Никаких претензий к ним нет за годы использования.
По идее, если Apple для китайского рынка айфоны напрямую с китайских же фабрик поставляет, то ни о каких пошлинах речи не должно быть. А вот если часть комплектующих они при этом везут из США, то конкретно с этих комплектующих Китай будет пошлины взимать (а потом при ввозе готового айфона в США повторные пошлины уже от американцев).
Насколько я знаю, уже много лет как во-первых, разработчики основных компиляторов участвуют в разработке стандарта, и могут попросить доработать предложение, если его тяжело реализовать, во-вторых, предложение принимают только после того, как хотя бы в одном из компиляторов оно реализовано.
Другое дело, что для больших и сложных фич в итоге всё равно получается, что на момент публикации стандарта они частично реализованы только в одном компиляторе, частично только в другом, и ни на одном компиляторе невозможно этим нормально пользоваться.
То, что CentOS Stream это совсем другой продукт, чем старый CentOS я понимаю, поэтому и пишу, что последний закрылся. Но вот википедия в качестве проектов, продолжающих развитие CentOS, указывает AlmaLinux и Rocky Linux. С ними-то что не так?
Который с 2014 года принадлежал Red Hat, а после закрытия лёг в основу пары крупных форков, которые продолжают ровно те же самые возможности пользователям предоставлять?
Я ещё раз внимательно посмотрел на ваши схемы, и понял, что у вас кружочки одинакового цвета это один и тот же коммит, с одним и тем же хэшем (вчера у меня сложилось впечатление, что это черри-пикинг тех же изменений). Тогда действительно никакого форс-пуша не будет, и замечание про потерю коммитов, соответственно, не актуально.
Актуальным остаётся замечание, что с ветками ничего не мешает точно так же процессы построить. Просто вместо support:release и dev:release будут ветки, условно hotfix и release-testing, в которые будут периодически мёржиться изменения из release (что у вас уже делается на шаге 7, только шаг 6 перестанет быть нужен). Использовать merge commit или fast-forward для залива протестированной версии в release уже отдельный, совершенно не связанный вопрос (моё имхо -- fast-forward + tag вполне уместно).
Помню, по неопытности как-то умудрился переставить голову своей рабочей ветки на другой коммит без моих изменений. Но даже тогда удалось всё восстановить, нагуглив команду для вывода коммитов без веток.
Если я всё правильно понял, на шаге 9 вы делаете форс-пуш в public:release. И именно в возможности так делать видите преимущество нескольких репозиториев.
Так с ветками тоже можно форс-пушнуть одну ветку в другую, и результат будет ровно тот же самый. Только идея в любом случае очень сомнительная. Как минимум, вы теряете тот коммит, из которого собирался ver-1.2.3-fix1, ушедший в релиз. Как максимум, рискуете и сами изменения случайно потерять.
Для банковских приложений, как я понимаю, главная проблема — авторизация. В вебе нельзя безопасным образом сделать авторизацию по биометрии, и вам придётся каждый раз вводить пароль.
А разве отдельной бесплатной лицензии для студентов больше нет? Не знаю, как сейчас, а раньше туда входила вся линейка корпоративных IDE, включая CLion.
Вот именно, оно чисто рекомендательный характер носит, точно так же, как и одинарное подчёркивание. И даже по официальному гайду PEP 8 не полагается в
__никаких особых смыслов вкладывать (относительно_), а использовать исключительно для символов, которые могут нежелательно в дочернем классе переопределиться.Нет, всё, что делает двойное подчёркивание - автоматически добавляет в начало имени члена имя класса. Это инструмент для избежания конфликтов имён между родителем и наследником, не более того.
Плохой совет. Правильный совет - если пользуетесь централизованным хостингом, настраивайте там protected branches. Расчитывать на то, что никто никогда не ошибётся - безумие.
Играю в игру
И любые комбинации из этих четырёх пунктов у меня регулярно происходят одновременно.
Да, но только правой рукой, и только если она уже лежит на столе. Если я сижу, откинувшись назад в кресле, до пробела дотянуться несопоставимо проще.
Главная проблема даже не в этом, а в том, что быстрый двойной тап таки перематывает видео, а если чуть-чуть задержаться, успевают появиться эти кнопки и поведение кардинально меняется.
Я наоборот, на дух не переношу проводные мыши. Остановился на офисных логитеках, но из тех, что чуть подороже и с дополнительными кнопками. Никаких претензий к ним нет за годы использования.
Не вижу проблем, у меня в свежевыпущенном Heroes of Hammerwatch 2 примерно столько выдаёт комп.
По идее, если Apple для китайского рынка айфоны напрямую с китайских же фабрик поставляет, то ни о каких пошлинах речи не должно быть. А вот если часть комплектующих они при этом везут из США, то конкретно с этих комплектующих Китай будет пошлины взимать (а потом при ввозе готового айфона в США повторные пошлины уже от американцев).
Знает. Во всех переписках был один собеседник-человек и один бот, и у интеррогатора только два варианта ответа: человек в чате А или в чате Б.
Они пишут, что в среднем переписка содержала 8 сообщений. Ограничения такого не было, просто за пять минут сложно больше успеть.
Насколько я знаю, уже много лет как во-первых, разработчики основных компиляторов участвуют в разработке стандарта, и могут попросить доработать предложение, если его тяжело реализовать, во-вторых, предложение принимают только после того, как хотя бы в одном из компиляторов оно реализовано.
Другое дело, что для больших и сложных фич в итоге всё равно получается, что на момент публикации стандарта они частично реализованы только в одном компиляторе, частично только в другом, и ни на одном компиляторе невозможно этим нормально пользоваться.
Если интересно посмотреть примеры, мы лет эдак десять назад делали LiriOS, дистрибутив Linux со своим DE и набором приложений. Весь GUI на QML.
То, что CentOS Stream это совсем другой продукт, чем старый CentOS я понимаю, поэтому и пишу, что последний закрылся. Но вот википедия в качестве проектов, продолжающих развитие CentOS, указывает AlmaLinux и Rocky Linux. С ними-то что не так?
Который с 2014 года принадлежал Red Hat, а после закрытия лёг в основу пары крупных форков, которые продолжают ровно те же самые возможности пользователям предоставлять?
Я ещё раз внимательно посмотрел на ваши схемы, и понял, что у вас кружочки одинакового цвета это один и тот же коммит, с одним и тем же хэшем (вчера у меня сложилось впечатление, что это черри-пикинг тех же изменений). Тогда действительно никакого форс-пуша не будет, и замечание про потерю коммитов, соответственно, не актуально.
Актуальным остаётся замечание, что с ветками ничего не мешает точно так же процессы построить. Просто вместо support:release и dev:release будут ветки, условно hotfix и release-testing, в которые будут периодически мёржиться изменения из release (что у вас уже делается на шаге 7, только шаг 6 перестанет быть нужен). Использовать merge commit или fast-forward для залива протестированной версии в release уже отдельный, совершенно не связанный вопрос (моё имхо -- fast-forward + tag вполне уместно).
Помню, по неопытности как-то умудрился переставить голову своей рабочей ветки на другой коммит без моих изменений. Но даже тогда удалось всё восстановить, нагуглив команду для вывода коммитов без веток.
Если я всё правильно понял, на шаге 9 вы делаете форс-пуш в public:release. И именно в возможности так делать видите преимущество нескольких репозиториев.
Так с ветками тоже можно форс-пушнуть одну ветку в другую, и результат будет ровно тот же самый. Только идея в любом случае очень сомнительная. Как минимум, вы теряете тот коммит, из которого собирался ver-1.2.3-fix1, ушедший в релиз. Как максимум, рискуете и сами изменения случайно потерять.
Для банковских приложений, как я понимаю, главная проблема — авторизация. В вебе нельзя безопасным образом сделать авторизацию по биометрии, и вам придётся каждый раз вводить пароль.