Alexej Simakov

Такая функция называется Родительский Контроль (либо Parental Control по-английски). Найдите подходящую программу и пользуйтесь. Вот у Касперкого есть https://www.kaspersky.ru/safe-kids и наверняка у других "безопасников" похожие продукты имеются, ведь это известный рыночный сегмент.

А чтобы Вам не казалось не думали, что какое-то "наколенное" решение даст результат, почитайте это:
"Родительский контроль взламывается ребёнком на 1,2,3"
https://answers.microsoft.com/ru-ru/windows/forum/...

Как альтернативу такому подходу можно просто использовать трекер времени (типа https://www.manictime.com/ ) Просто обговорить с ребенком количество времени которое ему позволено проводить за компьютером, и сказать что вы будете делать такие замеры - получится у него контролировать себя или нет. Можно на спор. И если он справится то получит какую нибудь награду. Я думаю нужно развивать в ребенке самоконтроль, а не использовать методы начала прошлого века.
А использовать позицию силы (я могу отключить и отключу) - ни к чему хорошему кроме конфликтов не приведет. Нужно договориться о правилах. Обычно дети охотно соглашаются. А вот если они не соглашаются на договор, тогда можно включить позицию силы как альтернативу, тогда почувствуется, что если упираться - не получишь ничего, а если договориться то можно "нормально жить". Выполнять обещания и получать награды. Которых раньше не было. Но на такой подход терпение надо, сам знаю, не всегда оно это терпение есть.

Upd:
сегодня сам с ребенком (9 лет) разговор на эту тему вел:
- как ты думаешь сколько времени в день нужно играть в компьютер?
- ну часа два, ну три
- хорошо, а сколько времени нужно готовить уроки и тренировать правописание, чтение, и математику?
- ну два часа.
- хорошо, а что сначала, а что потом?
- ну сначала уроки а потом играть, потому что вечером уже нет сил чтобы делать уроки.
- а ты знаешь, что глаза у нас работают весь день? вот ноги например, они не всегда нагружены, мы много сидим. А глаза заняты весь день. Больше чем глаза занято только сердце - оно вообще никогда не останавливается, всю жизнь работает и днем и ночью. Как ты думаешь было бы хорошо дать глазам отдохнуть?
- ну да.
- знаешь от чего глаза устают?
- нет
- глаз тоже имеет мышцы и когда мы смотрим на что-то то эти мышцы напрягаются. Если не дать этим мышцам расслабляться то они не смогут так хорошо менять свою форму и задубеют, и тогда ты не сможешь смотреть вдаль и вблизь. Мышцы должны быть гибкими чтобы они быстро реагировали. Если мышцы глаз гибкие ты легко сможешь переключать зрение с близи в даль и наоборот. Попробуй смотреть на газету а потом на дерево за окном. Чувствуешь глазу нужно немного времени чтобы переключиться?
- да
- если все время смотреть только на близкие предметы - например на экран - мышцы переключающие на дальнее зрение ослабеют и ты станешь хуже видеть. поэтому рекомендуют не сидеть за экраном дольше чем 45 минут, и урок длится тоже не дольше 45 минут, чтобы глаза могли отдохнуть от тетради.
...

Конечно одного такого разговора будет недостаточно, но ребенок вполне понимает причину беспокойства родителей. Ни один ребенок не хочет расстраивать родителей. С ним можно договориться. Это превратится в своеобразную игру и всем от этого будет только польза.
Так же спросите почему ему бывает так трудно оторваться от игры? Проэкспериментируйте от какой игры легче оторваться и почему. Вы узнаете много интересного.
Ребенок познает мир, познает себя, задавайте ему вопросы, и ищите вместе ответы на них, ставьте эксперименты. Используйте проблемную ситуацию для получения новых знаний. (см. передачу Галилео, они там все ставят под вопрос, это очень увлекательно и познавательно)

Для всех основных языков есть драйвера/обертки/библиотеки/API для работы с базами данных и для отправки SQL запросов. Автоматизированные тесты часто пишут на скриптовых языках, они гибче и легче в изучении. (bash и powershell хоть и тоже скриптовые языки, имхо не легки в изучении. Это уже из области системного программирования)
Если система на фреймворке, то на сайте фреймворка есть как правило документация как проводить юнит-тестирование для этого фреймворка.
Когда говорят умение писать скрипты, я думаю подразумевают, что разработчик в имеет опыт с одним из ходовых скриптовых языков (php, python, ruby, groovy, js) и за короткое время (недели три-четыре) в состоянии изучить любой другой, на достаточном для выполнения задач уровне. Для человека с опытом программирования это как правило не проблема. Детали синтаксиса всегда можно в документации посмотреть.

Не уверен что делать так хорошая идея, но это возможно, получая аттрибут объекта через getattr и обращаясь к результату.

class Member:
  def all(self):
    print "hello member"

class September:
  def all(self):
    print "hello september"
  

class Field:
  def __init__(self):
    self.member = Member()
    self.september = September()

field = Field()
field.member.all()
getattr(field, "september").all()

Если бы "september" было бы названием фунцкции то вызов был бы просто getattr(field, "september")()
По второму вопросу, все так же. А через setattr можно менять значение аттрибута. А через dir(field) можно получить список всех обьявленных на элементе полей.

class Member:
  def __init__(self):
    self.name = "John"
    self.surname = "Galt"
member = Member()
print member.name
print getattr(member, "surname")
setattr(member, "surname", "Wayne")
print getattr(member, "surname")

Я совсем не специалист по правильной архитектуре классов, но первое что приходит на ум: обьявите переменную mess как private свойство наряду с AGENT, POST_URL и пр, только не делайте ее final. и сделайте для нее метод доступа getMessage. Если getMessage возвращает null, переменная не была записана.

Я бы начал со второй части, обьектного дерева браузера, применение js для изменения содержимого страницы. Повесить фунцкию на событие нажатия по кнопке. Сделать так чтобы картинка менялась при нажатии, и прочие мелочи. (Я бы не стал учиться вождению автомобиля с изучения устройства коробки передач) Тонкости ооп в js (часть 1) и пр. я бы отложил бы на потом.

Вопрос в том, достаточно ли вам для проведения конкретного набора тестов чистого пользовательского аккаунта или вам нужна чистая инсталляция системы. На этот вопрос можно ответить только зная что вы хотите протестировать. В принципе сбоить может и с новым аккаунтом и с чистой инсталляцией. Будут совершенно разные ошибки. Есть программы которые по причине недоработанности не запускаются из под пользователя, а только под администратором. Есть сбои когда программа при запуске из под пользователя дает сбой на всю систему. Столько разных сценариев, что может пойти не так. Если допустить, что вы хотите протестировать процесс инсталляции программы, то логично, что тестировать нужно и на чистой машине и под пользователем и под ограниченным пользователем, и под администратором. Поскольку для такого теста это определяющие факторы. А если вы тестируете нагрузку на память программы во время выполнения, то профиль пользователя вряд ли будет ключевым фактором. Опять же, если вы тестируете сохранение глобальных настроек программы, то тестировать нужно под как минимум двумя разными профилями, соответственно.

вам просто никогда не приходилось писать в команде. Как только у вашего кода появляется соавтор, код сразу становится человекочитаемее (в некоторой степени, чуть-чуть, ну да согласен не всегда, встречаются эгоисты). Просто представьте себе что вы будете передавать кому то код для дальнейшей разработки. Вы сами видите, что он не годится для того чтобы его можно было кому-то передать (даже себе самому в точке времени t+1), ну вот и улучшайте с учетом мнимого соавтора. Хорошая архитектура позволяет разделение труда, один пишет один модули а кто-то другой, пишет процедуры где используются эти модули. Увеличение количества модулей никак не влияет на количество процедур и наоборот.
Почитайте еще обязательно про ортогональность

Мне кажется это наименее существенный вопрос. Важно иметь проработанную концепцию игры. А ее графическое представление не так важно для успеха, как может показаться (см. Thomas Was Alone)

(до этого ее тестировать нельзя)

почему? почему кто-то должен ждать появления в мастер-ветке какой-то другой фичи
если при разработке этой фичи, той другой фичи которую ждут тоже не было. Вы тестируете итерацию разработки.
Представим себе мастер ветка содержит претродактиля, одна ветка разработки делает его фиолетовым, а другая ветка разработки делает ему крылья с перъями. Тестировать цвет и перья можно по отдельности, потому что они разрабатывались по-отдельности. Если вы будете тестировать перья и фиолетовость, вы уже тестируете перья под влиянием цвета, или цвет под влиянием перьев. т.е. делаете частичное интеграционное тестирование. Логично было бы тестировать фичи все таки отдельно, и когда наберется их какое-то количество делать общий интеграционный тест и потом сливать все в мастер-ветку.

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

:) все уже придумали для вас:

• Logitech® Touch Mouse M600,
  
• Logitech Ultrathin Touch Mouse T630
  
• Rapoo T8 Wireless Laser Touch Maus
  
• Microsoft Surface Arc Mouse
  

ищите "touch mouse", "сенсорная мышь"

Upd.: как отметили в комментариях apple magic mouse 2 имеет механический щелчок, чего ни из одного обзора, ни из рекламы не понятно. Это еще раз напоминает нам о том, что сперва надо попробовать, т.к. описания в рекламе могут не давать всей необходимой информации о важных для пользователя нюансах.

Наверное общее правило такое: "если значение от чего-то зависит, нужно делать его гибким".

https://stackoverflow.com/questions/14093250/viewi...

Резиновые кольца специальные продаются.

если первый знак из symbols не встречается в строке ввода, возвращается 0.
для наглядности:

entered = str(input('Enter the string: '))

def check_spec_characters(inp):
    symbols = "[ ~`!@#$%^&*()_-+={}[]:>;',</?*-+ ]"
    for symbol in symbols:
        print (symbol+" in "+inp+" = "+ str((symbol in inp)))   

print (check_spec_characters(entered))

Да, чем ниже требуемая квалификация тем больше спрос на работу. Да, верстать страницу на фреймворке теперь стало малой квалификацией. Эти люди скорее всего не знают как работают эти инструменты/фреймворки, они не разбираются в дизайне, они не пишут тесты, они просто научились выполнять последовательность действий. Ну это как установить CMS - схема действий всегда одна и та же. Но решить ни одну программистскую задачу как правило они не в состоянии. Oни даже могут не уметь программировать на js. Тостер этому доказательство, тут >50% вопросов по азам javascript (ну по ощущениям).

Тест - это действие направленное на получение информации о системе.
Ручной тестировщик получает эту информацию вручную, автоматизатор с помощью компьютерных программ.
Почитать на первых порах рекомендую "Тестирование Дот Ком, или Пособие по жестокому обращению с багами в интернет-стартапах" Романа Савина.