Нормальная тема, лучше чем смотреть на стандартный вывод. Любителям настраивать все под себя должно понравиться. Думаю, можно расширить проект. Добавить выбор стиля прогресс бара. Пускай это будет репозиторий стилей и одновременно тулза для их смены. Чтобы опенсурс сообщество добавило в твой проект другие приколы. Для этого придется переименовать пакет.
Я бы вообще не разделял эти понятия. Есть процесс обеспечения качества и есть процесс его проверки. Это просто части одного целого. От размера проекта и компании зависит то, кто чем занимается. В маленьком проекте организацией и выполнением занимается один человек, в большой — уже есть куча ролей, каждая из которых делает какой-то свой кусок.
Описанный подход является ни чем иным, как моделью водопада и используется с прошлого века. Современные подходы к разработке по ортогонально отличаются. Аджайл появился не просто так, а именно в связи с проблемами, которые возникают в случае с описанной выше моделью.
Спасибо за апдейт. Теперь понятно, что это не связано с тестированием программного обеспечения. А относится к анализу / проверке входящей информации, которая еще не дошла до непосредственного использования в ПО. Я бы даже переименовал статью в «Подходы к анализу больших данных» и поменял бы раздел, так как сейчас раздел «тестирование IT систем».
Полагаю, тогда в статье нехватает контекста. Чтобы статья воспринималась в должном смысле. Надо объяснить так, чтобы стало понятно, почему бизнес процесс допускает попадание в бд невалидных данных.
По моему мнению, данные являются следствием работающего бизнес-процесса. Бизнес процесс — это люди и технические средства, объединенные в граф последовательностей.
Если люди могут вставлять в фамилию цифры — это говорит о том, что бизнес процесс непроработан до конца, это означает, что проблема совсем не в данных, а в качестве процесса выявления требований. То есть, "бага" на самом деле возникла при общении с заказчиком, когда было разрешено вставлять любые символы в фамилию. Когда требования уточняются или меняются и это затрагивает данные пользователей, нужно запустить процесс миграции данных, то есть, в случае с фамилией, заставить пользователей до определенной даты поменять свои данные на корректные. Пример можно найти в госуслугах — ты вводишь свои паспортные данные и далее неизвестно как, может быть даже руками людей, эти данные валидируются, они никак не попадают сразу в категорию валидных данных.
Как мне кажется, статья больше вводит в заблуждение, чем даёт какую-то пользу.
Что касается реального тестирования данных — то этот термин относится к тест дизайну, а точнее к одному из видов тест дизайна — анализу значений.
Например, что будет, если ввести в поле возраста 150 лет, или что будет, если ввести фамилию на двух разных алфавитах. Объект тестирования при этом не данные, а интерфейс пользователя. И это самый обычный тест.
Как мне кажется, терроризм здесь совсем ни при чем. Простой вопрос, кто мешает поднять "террористам" на каком-нибудь инстансе свой маленький сервер для использования какого-нибудь своего мессенджера, ставит Жарова в идиотское положение.
Это не было "просто сидением на месте". Человек трудился два года и старался быть лучше. В такой компании 2 года пролетают как пара месяцев — незаметно.
Вы ошибаетесь. Есть 1000 человек в фирме. Их приняли на зарплату. Подходит год. Два. Цены в магазине подверглись инфляции, потребительская корзина подорожала. Теперь, через два года, зарплата тысячи людей упала на величину реальной инфляции.
При этом мест как было 1000 так и осталось.
Вы как будто выдумываете какие-то условия, чтобы поспорить, вероятно так.
В итоге комитет решает, с какой скоростью индексировать зарплаты. Есть ежегодный бюджет на повышение. Бюджет на повышение конечно же завязан на прибыль компании. Таким образом, у каждого есть шанс на повышение. Но поскольку в Google система верхнеуровневого планирования устроена совершенно идиотским способом, невозможно выполнить требования для этого повышения. Получается, что менеджмент, принимающий идиотские решения всегда в плюсе, а расплачивается инженер, которому внезапно отменили проект.
Я не вижу смысла далее разглагольствовать на эту тему.
Предлагаю вначале воспользоваться гуглом. Уже давно написана куча статей на эту тему. Эта статья была явно лишней. Также хорошей практикой является чтение оригинальной документации, она бы закрыла 90% вопросов, освещенных в статье.
Мне это напомнило MVC паттерн. Так и есть. Вью — игровая сетка. Ее источник — данные в массиве. Контроллер — процесс взаимодействия пользователя с экраном.
Как мне кажется, стоит вспомнить heartbleed в openssl. Код, открытый сообществу, все равно содержал уязвимость. Прежде всего, уязвимость — это баг, такой же баг, как и все остальное. И баги будут всегда, хоть в закрытом, хоть в открытом проекте, хоть в коде, хоть где-либо ещё.
Необходимо сравнение по крупным городам. При этом для каждого города нужно вывести планку средней зарплаты по городу без учёта специальности.
На мои вопросы ответили специалисты из России, Украины, Беларуси, США, Великобритании, Польши, Германии, Израиля, а также представители транснациональных компаний.
Неправильно складывать заплаты Беларуси, России и США в одну корзину. Экономики этих стран разные совершенно. Более показательно было бы соотношение зарплаты к среднему уровню доходов населения по отдельным странам и мегаполисам.
Скверная подача материала. Статья в стиле копирайтерских статей, где текст раздувается для нужного объема. В этом стиле в газетах пишите, здесь инженерный ресурс.
Краткое содержание: революция, революция, революция, перевернет мир новейшая технология.
Ввод каких-то ограничений на развитие ии, или ввод защиты населения от уменьшения рабочих мест — это костыли, которые не решают проблему, а лечат одни симптомы, при этом создавая новые проблемы. Мне кажется, никто из них не решился посмотреть проблеме в глаза.
С общей точки зрения проблема сводится к конкуренции видов:
Людей и машин. Из этого вытекает очевидное следствие: людей на планете слишком много. Поэтому еще одно костыльное решение — это сдерживание роста популяции.
Это тоже не решает проблемы, потому что рано или поздно и этого сдерживания будет недостаточно.
На мой взгляд, что станет решением проблемы — это симбиоз видов. Отработанный самой же природой механизм совместного выживания.
Что такое симбиоз человека и машины? Это вживление технологий в человека. За примерами далеко ходить не нужно. Уже давно люди вживляли себе чипы в руку, тестируя таким образом этот самый симбиоз. Уже есть разработки rfid в руке и автоматические замочные системы, открывающие дверь, если ее открывает хозяин. То есть тут в принципе уже проблема решается сама собой. Естественным образом.
Если представить, что текущее положение симбиоза — лишь зачаток. В будущем можно представить себе "интернет мозгов" на базе IoT, google-линзы или google-глаз вместо текущих очков, скоростную память с интеграцией нейронов.
Все это позволит человечеству двигаться дальше.
Мне поэтому очень странно читать все это, что написано выше, потому что вроде как это эксперты в своей области.
Нормальная тема, лучше чем смотреть на стандартный вывод. Любителям настраивать все под себя должно понравиться. Думаю, можно расширить проект. Добавить выбор стиля прогресс бара. Пускай это будет репозиторий стилей и одновременно тулза для их смены. Чтобы опенсурс сообщество добавило в твой проект другие приколы. Для этого придется переименовать пакет.
Я бы вообще не разделял эти понятия. Есть процесс обеспечения качества и есть процесс его проверки. Это просто части одного целого. От размера проекта и компании зависит то, кто чем занимается. В маленьком проекте организацией и выполнением занимается один человек, в большой — уже есть куча ролей, каждая из которых делает какой-то свой кусок.
Описанный подход является ни чем иным, как моделью водопада и используется с прошлого века. Современные подходы к разработке по ортогонально отличаются. Аджайл появился не просто так, а именно в связи с проблемами, которые возникают в случае с описанной выше моделью.
Полагаю, тогда в статье нехватает контекста. Чтобы статья воспринималась в должном смысле. Надо объяснить так, чтобы стало понятно, почему бизнес процесс допускает попадание в бд невалидных данных.
Как-то всё это очень странно.
По моему мнению, данные являются следствием работающего бизнес-процесса. Бизнес процесс — это люди и технические средства, объединенные в граф последовательностей.
Если люди могут вставлять в фамилию цифры — это говорит о том, что бизнес процесс непроработан до конца, это означает, что проблема совсем не в данных, а в качестве процесса выявления требований. То есть, "бага" на самом деле возникла при общении с заказчиком, когда было разрешено вставлять любые символы в фамилию. Когда требования уточняются или меняются и это затрагивает данные пользователей, нужно запустить процесс миграции данных, то есть, в случае с фамилией, заставить пользователей до определенной даты поменять свои данные на корректные. Пример можно найти в госуслугах — ты вводишь свои паспортные данные и далее неизвестно как, может быть даже руками людей, эти данные валидируются, они никак не попадают сразу в категорию валидных данных.
Как мне кажется, статья больше вводит в заблуждение, чем даёт какую-то пользу.
Что касается реального тестирования данных — то этот термин относится к тест дизайну, а точнее к одному из видов тест дизайна — анализу значений.
Например, что будет, если ввести в поле возраста 150 лет, или что будет, если ввести фамилию на двух разных алфавитах. Объект тестирования при этом не данные, а интерфейс пользователя. И это самый обычный тест.
Вот как-то совсем не зашло.
Как мне кажется, терроризм здесь совсем ни при чем. Простой вопрос, кто мешает поднять "террористам" на каком-нибудь инстансе свой маленький сервер для использования какого-нибудь своего мессенджера, ставит Жарова в идиотское положение.
Спасибо за перевод. Мне кажется, надо быть маньяком, чтобы всю эту описанную схему придумать.
Это не было "просто сидением на месте". Человек трудился два года и старался быть лучше. В такой компании 2 года пролетают как пара месяцев — незаметно.
Очевидно, что чтобы поправить систему, нужно чтобы топ менеджмент изменил регламент работы комитета, потому что ситуация несправедливая и бредовая.
Вы ошибаетесь. Есть 1000 человек в фирме. Их приняли на зарплату. Подходит год. Два. Цены в магазине подверглись инфляции, потребительская корзина подорожала. Теперь, через два года, зарплата тысячи людей упала на величину реальной инфляции.
При этом мест как было 1000 так и осталось.
Вы как будто выдумываете какие-то условия, чтобы поспорить, вероятно так.
В итоге комитет решает, с какой скоростью индексировать зарплаты. Есть ежегодный бюджет на повышение. Бюджет на повышение конечно же завязан на прибыль компании. Таким образом, у каждого есть шанс на повышение. Но поскольку в Google система верхнеуровневого планирования устроена совершенно идиотским способом, невозможно выполнить требования для этого повышения. Получается, что менеджмент, принимающий идиотские решения всегда в плюсе, а расплачивается инженер, которому внезапно отменили проект.
Я не вижу смысла далее разглагольствовать на эту тему.
Про 2048.
Мне это напомнило MVC паттерн. Так и есть. Вью — игровая сетка. Ее источник — данные в массиве. Контроллер — процесс взаимодействия пользователя с экраном.
Как мне кажется, стоит вспомнить heartbleed в openssl. Код, открытый сообществу, все равно содержал уязвимость. Прежде всего, уязвимость — это баг, такой же баг, как и все остальное. И баги будут всегда, хоть в закрытом, хоть в открытом проекте, хоть в коде, хоть где-либо ещё.
Тогда просто отредактируйте статью, поскольку это предложение сбивает с толку, большое спасибо
Необходимо сравнение по крупным городам. При этом для каждого города нужно вывести планку средней зарплаты по городу без учёта специальности.
Неправильно складывать заплаты Беларуси, России и США в одну корзину. Экономики этих стран разные совершенно. Более показательно было бы соотношение зарплаты к среднему уровню доходов населения по отдельным странам и мегаполисам.
Скверная подача материала. Статья в стиле копирайтерских статей, где текст раздувается для нужного объема. В этом стиле в газетах пишите, здесь инженерный ресурс.
Краткое содержание: революция, революция, революция, перевернет мир новейшая технология.
Не совсем корректное определение. Философия Python комментирует использование ООП по-своему.
Про это есть отдельная глава «ООП»:
docs.python-guide.org/en/latest/writing/structure/#object-oriented-programming
Я это вижу по-другому:
Ввод каких-то ограничений на развитие ии, или ввод защиты населения от уменьшения рабочих мест — это костыли, которые не решают проблему, а лечат одни симптомы, при этом создавая новые проблемы. Мне кажется, никто из них не решился посмотреть проблеме в глаза.
С общей точки зрения проблема сводится к конкуренции видов:
Людей и машин. Из этого вытекает очевидное следствие: людей на планете слишком много. Поэтому еще одно костыльное решение — это сдерживание роста популяции.
Это тоже не решает проблемы, потому что рано или поздно и этого сдерживания будет недостаточно.
На мой взгляд, что станет решением проблемы — это симбиоз видов. Отработанный самой же природой механизм совместного выживания.
Что такое симбиоз человека и машины? Это вживление технологий в человека. За примерами далеко ходить не нужно. Уже давно люди вживляли себе чипы в руку, тестируя таким образом этот самый симбиоз. Уже есть разработки rfid в руке и автоматические замочные системы, открывающие дверь, если ее открывает хозяин. То есть тут в принципе уже проблема решается сама собой. Естественным образом.
Если представить, что текущее положение симбиоза — лишь зачаток. В будущем можно представить себе "интернет мозгов" на базе IoT, google-линзы или google-глаз вместо текущих очков, скоростную память с интеграцией нейронов.
Все это позволит человечеству двигаться дальше.
Мне поэтому очень странно читать все это, что написано выше, потому что вроде как это эксперты в своей области.