При это российские судьи получают намного меньше многих из своих иностранных коллег. Средняя зарплата российского судьи составляет 7 411 евро. Немецкий судья зарабатывает 53 688 евро, испанский – 23 033 евро, чешский – 14 365 евро.
я думаю есть смысл указать, что речь идет о годовой зарплате, а то у людей могут немного глаза на лоб полезть от несчастных судей, получающих 7 411 евро в месяц.
Безусловно возможность заходить через Яндекс была уже давно.
Временность\неопределенность в том — как долго такая возможность сохранится. Срок действия домена tut.by истекает через год. Шансы что к тому времени у tut.by появится новый законный хозяин неизвестны.
При этом новый хозяин (если это будет новое юр. лицу) наверняка не унаследует договор с Яндексом.
Непонятно когда истечет договор между Яндекс и tut.by, ну и плюс этот договор Яндексу крайне не выгоден (вспоминаем законодательству Республики Беларусь об ответственности за сотрудничество с неблагонадежными контрагентами), а также что у Яндекс есть свои юр.лица в РБ, в которых врядли они хотят видеть маски-шоу.
Ну и почта tut.by на Яндексе — это не полноценная почта, многие вещи без доступа к tut.by сделать нельзя.
Я думаю в этом и дело. Счета Тут арестованы, платить некому, так что я бы ожидал полного удаления всех почтовых ящиков, кроме может быть тех, которые имеют подписку на услуги Яндекса, типа музыки. Но официальной инфы нет :(
Это, безусловно, вариант. Но, боюсь 99.999% пользователей это как то уж слишком. Большинство до сих пор называют корпус ПК «процессором», а Chrome/Edge/IE — «интернетом»
Контр пример: альтернативная имплементация TCP/IP стека в обход ядра Linux, реализация fail-safe протокола UDP без нарушения существующих патентов, ускорение выполнения исходного кода для процессора определенной архитектуры…
Это я к чему — в определенных условиях задачи могут быть типовыми. Это не является доказательством того, что все задачи (или даже большинство) — типовые.
Я не нашел исследования «типичности» задач в среднем по индустрии. Скорее всего потому, что измерять среднее для крайне неоднородной индустрии — дело неблагодарное.
Но без обозначения границ применимости — доказать, что утверждение «Большая часть задач разработчика однотипны и уже имеют решения. Часто работа сводится к поиску готового решения в интернете и адаптации его под нужды конкретного проекта.» ложное — дело одного case study.
Большая часть задач разработчика однотипны и уже имеют решения. Часто работа сводится к поиску готового решения в интернете и адаптации его под нужды конкретного проекта.
а откуда инфа? Данное утверждение, как минимум, противоречит моему опыту, и де-факто общепринятому подходу к разработке как исследовательской задаче.
А нет, случаем, статьи на английском языке? Надо скинуть кое-каким коллегам. (если вдруг нет — могу подготовить и опубликовать перевод на хабре/medium в течении недели-трех, если Вам интересно. Правда заранее предупреждаю — я не профессиональный переводчик и не лингвист, так что качество может быть несколько средним.)
мне кажется отличное описание. Наверное, стоит провести вебинар по TDD — мне кажется многие коллеги, которые делают выводы о TDD особо никогда не пробовали.
получается как *не читал, но осуждаю*
Мне нравится такой подход — "тест как гипотеза".
Ведь, в противном случае, как мы поймем, что мы наиследовали своим кодом? Разве что читать логи, что не всегда реально (если их тыщи)
Окей, я готов согласиться в том, что это субъективный фактор.
Я, например, предпочитаю смотреть Pull Request начиная с тестов — так я могу понять чего пытались достичь, и более внимательно\продуктивно рассмотреть сам предложенный код.
Но я не могу исключить возможности, что этот метод работает не для всех.
У меня за плечами эдак лет 13 профессиональной разработки, и среди них знание как обойти дерево понадобилось аж 1 раз - на собесе в амазон.
По достоверной информации сотрудниками самими амазон после собеседования ни одно дерево не обходилось
А можно ссылку почитать?
Мне тоже интересно, но вот уже скоро месяц, а Яндекс молчит...
1) нельзя поменять свое имя
2) не у всех есть возможность поменять пароль (не знаю от чего зависит, но отсылает некоторых на tut.by https://forum.onliner.by/viewtopic.php?t=147146&start=1540). Часть смогла поменять пароль через кандебобер
3) риск несанкционированного доступа к вашему почтовому ящику (https://www.belrynok.by/2021/05/21/chto-segodnya-proishodit-s-tut-by-kirill-voloshin-otvetil-na-voprosy-zhurnalistov/)
4) нет никаких гарантий, что доступ к ящику сохранится в сколь-угодно продолжительном времени. Мой прогноз — примерно через год домен tut.by прекратит существование, а с ним перестанет работать и почта. Это может произойти и раньше
Временность\неопределенность в том — как долго такая возможность сохранится. Срок действия домена tut.by истекает через год. Шансы что к тому времени у tut.by появится новый законный хозяин неизвестны.
При этом новый хозяин (если это будет новое юр. лицу) наверняка не унаследует договор с Яндексом.
Непонятно когда истечет договор между Яндекс и tut.by, ну и плюс этот договор Яндексу крайне не выгоден (вспоминаем законодательству Республики Беларусь об ответственности за сотрудничество с неблагонадежными контрагентами), а также что у Яндекс есть свои юр.лица в РБ, в которых врядли они хотят видеть маски-шоу.
Ну и почта tut.by на Яндексе — это не полноценная почта, многие вещи без доступа к tut.by сделать нельзя.
Сейчас требования к документам сильно выросли, я вдохновился статьей и пробовал сам. Получилось только с нескольких попыток и без юристов не обошлось
Это я к чему — в определенных условиях задачи могут быть типовыми. Это не является доказательством того, что все задачи (или даже большинство) — типовые.
Я не нашел исследования «типичности» задач в среднем по индустрии. Скорее всего потому, что измерять среднее для крайне неоднородной индустрии — дело неблагодарное.
Но без обозначения границ применимости — доказать, что утверждение «Большая часть задач разработчика однотипны и уже имеют решения. Часто работа сводится к поиску готового решения в интернете и адаптации его под нужды конкретного проекта.» ложное — дело одного case study.
а откуда инфа? Данное утверждение, как минимум, противоречит моему опыту, и де-факто общепринятому подходу к разработке как исследовательской задаче.
получается как *не читал, но осуждаю*
Часть проверки теряется, это безусловно.
Мне нравится такой подход — "тест как гипотеза".
Ведь, в противном случае, как мы поймем, что мы наиследовали своим кодом? Разве что читать логи, что не всегда реально (если их тыщи)
Я думаю, если речь идет о платном приложении, нестабильность горячих клавиш может легко стать причиной неуспеха.
Я вот очень сильно переживаю, если у меня хоткеи не работают надежно.
И не тестировать такой функционал — это не уважать пользователя, а писать ненадежный софт — не уважать себя. Разве нет?
Есть отличная глава "QA should find nothing" из книги Clean Coder.
-> почему не заранее?
Я, например, предпочитаю смотреть Pull Request начиная с тестов — так я могу понять чего пытались достичь, и более внимательно\продуктивно рассмотреть сам предложенный код.
Но я не могу исключить возможности, что этот метод работает не для всех.
Может ли предположить, что тесты выступают как ubiquitous language, понятный всем разработчикам\заинтересованным лицам?