У меня тоже давно сомнения в честности бота, но всё равно интересно придумать в очередной раз тактику захвата территории, да ещё и с несколькими противниками. Если хочется чего-то попроще, то делаю карту мелких или средних островов и один за другим захватываю острова, окружая кораблями и высаживая артиллерию.
Из старых игр периодически могу заново поиграть в Half-Life, Max Payne, NFSU, Empire Earth. Что-то прям как будто заставляет внутри немного понастальгировать, вспомнить ощущения от игр и снова забыть их на несколько лет.
Где-то в 2003-м в деревне у бабушки посреди ночи видел нечто, что можно было бы принять за НЛО. Светлая точка далеко из-за горы поднялась вверх, а затем резко полетела в сторону под углом порядка 90 градусов. Свет пульсировал, как если бы он вырывался из сопла ракеты. Возможно, где-то там была военная база и проходили испытания.
Думаю, абсолютно все случаи т.н. НЛО вполне объяснимы простыми вещами. Просто раньше придумывали богов, а теперь - инопланетян.
Кажется, любая грамматика одинаково сложная, если ты её не используешь.
Английский начинал учить ещё в школе, изучая кучу правил параллельно. Шло очень сложно и медленно. Но реально английский начал хорошо развиваться, когда начал читать книги на английском (сначала по разработке), смотреть некоторые каналы на YouTube на английском (без субтитров) и, наконец, жить за границей, очень часто используя в общении. Также намеренно начал заставлять себя думать на английском, что позволяет расширить словарный запас и повторять уже изученное (кажется, сейчас я чаще думаю на английском, чем на русском). Почти все свои посты и статьи пишу либо сразу на английском, либо делаю перевод, а ChatGPT вносит правки и помогает таким образом узнавать, как правильно.
Сейчас учу испанский на английском через DuoLingo, находясь в испаноязычной среде. Помимо того, что такой подход к обучению на порядок проще и быстрее, чем это было в школе (за пару лет неспешного обучения с нуля дорос до B1 и уже не спрашиваю "hablas ingles?"), этот способ также помогает учить английский, т.к. некоторые конструкции или слова мне никогда ранее не встречались, которые встречаются в процессе обучения испанскому (например, "recital").
Аналогично и с грамматикой языков программирования. Так только на второй своей работе программистом я перестал заглядывать в шпаргалку с правильным написанием SQL-запросов, т.к. там мы их использовали очень много. Просто практика. А сейчас разбуди среди ночи - с закрытыми глазами напишу.
Аналогично и в разработке. На прошлом месте работы понял, что совершенно не нужно перенапрягаться, чтобы работать столь же эффективно, как и остальные (и даже лучше). Реальное время работы составляло порядка 4-5 часов максимум и, когда вынужден был уволиться из-за переезда, сказали, что работал при этом очень быстро и хорошо (за пару месяцев до этого команду сократили вдвое, т.к. основной цикл разработки стартапа завершился). Уроки танцев сразу после работы просто заставляли меня заканчивать вовремя, не задерживаясь на работе более, чем на 10 минут. И оказалось, что никому и не нужно, чтобы я задерживался.
Будучи джуном, я привык, что надо стараться сделать за день максимально много - и это хорошо, даже правильно, пока ты новичок и надо нарабатывать опыт. Будучи мидлом, всё продолжилось в том же духе - хотелось как можно поскорее вырасти. А уже в качестве сеньора не сразу удалось притормозить и понять, что качество работы оценивается не количеством написанных строк и, если можно сделать задачу, даже не открывая код, то так и надо делать. Так появились задачи, которые мне банально не хотелось выполнять после прочтения описания, т.к. чувствовался от них какой-то душок. Во всех таких случаях она на следующий день отменялась. Но для этого нужна насмотренность и хорошее понимание проекта.
В целом, продолжаю в том же духе. При этом задачи заканчиваются быстрее, чем время, на них отведённое.
Тоже была подобная история, где кто-то собирался сделать шахматы (что уже вызвало вопросы) и дали мне, случайному человеку, ссылку на код. Я посмотрел глазами - что-то действительно похоже на шахматы. Потом снова списались, а меня в ответ просят скриншот прислать. Не понимаю, какой именно, а мне говорят, что запущенной программы, на что я ответил, что не запускаю незнакомый код на компе. После этого человек по-быстрому удалился, даже профиль на LinkedIn вскоре пропал. Я об этом с подробностями там же пост и написал.
Они эффективны, пока ты не начинаешь читать такой код. Разные исключения обрабатываются по-разному и никогда не угадаешь, как очередное исключение будет обработано, пока не прочитаешь код всего стека вызовов методов от контроллера до твоего десятого по счёту метода.
goto тоже по-своему эффективен, пока не начинаешь читать такой код. (Вспомнилось, как последний раз я их использовал как блок, подобный finally. Это было лет 15 назад в Delphi.)
Они и продолжают решать определённые проблемы, например, когда в DI не дописали интерфейс и у нас случился NullReferenceException в методе или ArgumentException в контроллере, если туда это дописали. Это ошибка программиста, которая решается один раз и там больше не должно быть исключения. А пользователь, соответственно, не должен видеть содержимого этого исключения.
Но если нам просто надо провалидировать данные и сообщить пользователю о неверных данных, это подобно использованию топора там, где нужен пинцет.
Я считаю, что исключение - это такое сообщение, текст которого конечный пользователь не должен видеть. Он только для внутреннего использования и в идеале исключение не должно повторяться, если его один раз поправили.
Я о том и говорю, что исключения должны быть только там, где программа даже не должна работать дальше. Если в API вместо положительного числа пришло отрицательное, то это просто ошибка валидации и мы возвращаем BadResult(ModalState). Если же кидать исключение на каждую проверку вместо того, чтобы вернуть сообщение об ошибке и далее тот же BadResult с этим текстом, то ничего хорошего из этого не выйдет.
Это просто примеры, чтобы не перегружать не важными словами и кучей ненужных для этого классов. Каждый волен делать так, как пожелает.
В простых API моно и бросать исключения. Но вложенность до вызова десятка методов один за другим и каждый может выбросить какое-то исключение, часть из которых логируется, часть игнорируется, часть выбрасывается дальше с новым текстом или даже новым типом, код превращается в ад. Читать его очень трудно, понять логику - ещё труднее. А потом пользователи говорят, что нажатие на одну кнопку возвращает осмысленный текст, а на другую похожую - заглушку. Потом оказывается, что одно и то же исключение в одном месте перехватывается и просто логируется где-то на полпути к контроллеру, а в другом - перебрасывается дальше.
Получается, что у каждого такого метода может быть несколько состояний: вернул результат, выбросил ValidationException, выбросил NotFoundException, выбросил FooBarException, и т.д. И каждый надо учесть. У Result зависит от подхода. Можно всегда Ok(result) возвращать, можно разбить на Ok и BadResult, можно сделать больше и вообще на клиенте обрабатывать.
В статье я написал, что try-catch используется, но только там, где это действительно необходимо.
Конечно, middleware на случай непредвиденных ошибок есть. Но всё, что можно предвидеть, уходит в Result. Проблема middleware в том, что он одинаково ловит и "wrong id", которое нужно показать пользователю, и null reference со stack trace, которое не нужно показывать пользователю. В моём коде туда попадает только то, что не должно попадать на глаза пользователю для логирования, отправки уведомления об ошибке и показа пользователю заглушки.
Я искал позиции для Senior .NET developer. Конечно, для разных вакансий всё может сильно отличаться. Я все свои отклики записываю в файл, указывая сайт и статус. Самое забавное, что некоторые компании присылают отказы даже спустя месяцы, хотя могли уже и не заморачиваться.
Без проблем нашёл работу через hh в прошлом году. Что я делал не так? А пару раз в неделю на LinkedIn приходят предложения.
Сначала из-за границы принципиально пробовал искать через LinkedIn, Glassdoor, Indeed и пр. По ощущениям, в среднем было порядка 30-50% ответов, пусть даже с отказом. Было мало интервью или невыполнимые условия. Где-то были задания. Потом задолбался и через 3 недели уже была работа, найденная через hh.
Конечно, обвинить сайты в том, что не получается найти работу, - гораздо проще, чем подойти к поиску работы со всей ответственностью, как к отдельной работе.
Когда занимался автоматизацией, где-то 13 лет назад поступил запрос посчитать возможность автоматизации карьера для автоматического вывоза материала. Т.е. есть водитель и грузовик, который будет загружен конвейером. Всё остальное, от въезда до выезда - без людей. На выезде водитель даже сам забирает распечатанную накладную по грузу. Сделал им коммерческое предложение, но до разработки, к сожалению, не дошло. К сожалению, не знаю, к чему они пришли. Но предложение по автоматизации карьера потом было добавлено в наше КП. Так что удивляет, что сейчас об этом пишут так, будто только сейчас это стало чем-то особенным. Конечно, карьеры разные бывают. Но, тем не менее.
Недавно для себя открыл сценариста Тейлора Шеридана и понял, что можно смотреть не только фильмы определённого режиссёра или платформы, к чему мы уже привыкли, но и сценариста. Это "Йеллоустоун" и все его приквелы, "Король Талсы", "Землевладелец", "Спецназ: Львица" и пр. Он возвращает на экран сильных героев, решающих проблемы, на которых приятно смотреть, за развитием которых интересно наблюдать. У них тоже есть слабости, но не в том виде, в котором показывают последнее время. При том сильные герои - не персонажи комиксов, а живые люди со своими интересными историями. А то, что в "Йеллоустоуне" чуть ли не половина экранного времени уделена красоте природы и обычному ковбойскому быту - особенно радует, позволяя одновременно и расслабиться, и следить за динамичным сюжетом.
У меня тоже давно сомнения в честности бота, но всё равно интересно придумать в очередной раз тактику захвата территории, да ещё и с несколькими противниками. Если хочется чего-то попроще, то делаю карту мелких или средних островов и один за другим захватываю острова, окружая кораблями и высаживая артиллерию.
Из старых игр периодически могу заново поиграть в Half-Life, Max Payne, NFSU, Empire Earth. Что-то прям как будто заставляет внутри немного понастальгировать, вспомнить ощущения от игр и снова забыть их на несколько лет.
На ПК есть Underground, Most Wanted и остальные. Лучший саундтрек у Underground. До сих пор некоторые треки оттуда в плейлисте.
Где-то в 2003-м в деревне у бабушки посреди ночи видел нечто, что можно было бы принять за НЛО. Светлая точка далеко из-за горы поднялась вверх, а затем резко полетела в сторону под углом порядка 90 градусов. Свет пульсировал, как если бы он вырывался из сопла ракеты. Возможно, где-то там была военная база и проходили испытания.
Думаю, абсолютно все случаи т.н. НЛО вполне объяснимы простыми вещами. Просто раньше придумывали богов, а теперь - инопланетян.
Кажется, любая грамматика одинаково сложная, если ты её не используешь.
Английский начинал учить ещё в школе, изучая кучу правил параллельно. Шло очень сложно и медленно. Но реально английский начал хорошо развиваться, когда начал читать книги на английском (сначала по разработке), смотреть некоторые каналы на YouTube на английском (без субтитров) и, наконец, жить за границей, очень часто используя в общении. Также намеренно начал заставлять себя думать на английском, что позволяет расширить словарный запас и повторять уже изученное (кажется, сейчас я чаще думаю на английском, чем на русском). Почти все свои посты и статьи пишу либо сразу на английском, либо делаю перевод, а ChatGPT вносит правки и помогает таким образом узнавать, как правильно.
Сейчас учу испанский на английском через DuoLingo, находясь в испаноязычной среде. Помимо того, что такой подход к обучению на порядок проще и быстрее, чем это было в школе (за пару лет неспешного обучения с нуля дорос до B1 и уже не спрашиваю "hablas ingles?"), этот способ также помогает учить английский, т.к. некоторые конструкции или слова мне никогда ранее не встречались, которые встречаются в процессе обучения испанскому (например, "recital").
Аналогично и с грамматикой языков программирования. Так только на второй своей работе программистом я перестал заглядывать в шпаргалку с правильным написанием SQL-запросов, т.к. там мы их использовали очень много. Просто практика. А сейчас разбуди среди ночи - с закрытыми глазами напишу.
Аналогично и в разработке. На прошлом месте работы понял, что совершенно не нужно перенапрягаться, чтобы работать столь же эффективно, как и остальные (и даже лучше). Реальное время работы составляло порядка 4-5 часов максимум и, когда вынужден был уволиться из-за переезда, сказали, что работал при этом очень быстро и хорошо (за пару месяцев до этого команду сократили вдвое, т.к. основной цикл разработки стартапа завершился). Уроки танцев сразу после работы просто заставляли меня заканчивать вовремя, не задерживаясь на работе более, чем на 10 минут. И оказалось, что никому и не нужно, чтобы я задерживался.
Будучи джуном, я привык, что надо стараться сделать за день максимально много - и это хорошо, даже правильно, пока ты новичок и надо нарабатывать опыт. Будучи мидлом, всё продолжилось в том же духе - хотелось как можно поскорее вырасти. А уже в качестве сеньора не сразу удалось притормозить и понять, что качество работы оценивается не количеством написанных строк и, если можно сделать задачу, даже не открывая код, то так и надо делать. Так появились задачи, которые мне банально не хотелось выполнять после прочтения описания, т.к. чувствовался от них какой-то душок. Во всех таких случаях она на следующий день отменялась. Но для этого нужна насмотренность и хорошее понимание проекта.
В целом, продолжаю в том же духе. При этом задачи заканчиваются быстрее, чем время, на них отведённое.
Тоже была подобная история, где кто-то собирался сделать шахматы (что уже вызвало вопросы) и дали мне, случайному человеку, ссылку на код. Я посмотрел глазами - что-то действительно похоже на шахматы. Потом снова списались, а меня в ответ просят скриншот прислать. Не понимаю, какой именно, а мне говорят, что запущенной программы, на что я ответил, что не запускаю незнакомый код на компе. После этого человек по-быстрому удалился, даже профиль на LinkedIn вскоре пропал. Я об этом с подробностями там же пост и написал.
В том проекте, где у вас сотни
throw, обязательно будет что-то вродеtry { ...} catch {}, в лучшем случаеtry { ...} catch { logger.Log(); }.Они эффективны, пока ты не начинаешь читать такой код. Разные исключения обрабатываются по-разному и никогда не угадаешь, как очередное исключение будет обработано, пока не прочитаешь код всего стека вызовов методов от контроллера до твоего десятого по счёту метода.
goto тоже по-своему эффективен, пока не начинаешь читать такой код. (Вспомнилось, как последний раз я их использовал как блок, подобный finally. Это было лет 15 назад в Delphi.)
Они и продолжают решать определённые проблемы, например, когда в DI не дописали интерфейс и у нас случился NullReferenceException в методе или ArgumentException в контроллере, если туда это дописали. Это ошибка программиста, которая решается один раз и там больше не должно быть исключения. А пользователь, соответственно, не должен видеть содержимого этого исключения.
Но если нам просто надо провалидировать данные и сообщить пользователю о неверных данных, это подобно использованию топора там, где нужен пинцет.
Я считаю, что исключение - это такое сообщение, текст которого конечный пользователь не должен видеть. Он только для внутреннего использования и в идеале исключение не должно повторяться, если его один раз поправили.
Нет, просто мне лично нравится, когда в один экран влазит больше кода, а пустые строки только там, где я их оставил.
Я о том и говорю, что исключения должны быть только там, где программа даже не должна работать дальше. Если в API вместо положительного числа пришло отрицательное, то это просто ошибка валидации и мы возвращаем BadResult(ModalState). Если же кидать исключение на каждую проверку вместо того, чтобы вернуть сообщение об ошибке и далее тот же BadResult с этим текстом, то ничего хорошего из этого не выйдет.
Это просто примеры, чтобы не перегружать не важными словами и кучей ненужных для этого классов. Каждый волен делать так, как пожелает.
В простых API моно и бросать исключения. Но вложенность до вызова десятка методов один за другим и каждый может выбросить какое-то исключение, часть из которых логируется, часть игнорируется, часть выбрасывается дальше с новым текстом или даже новым типом, код превращается в ад. Читать его очень трудно, понять логику - ещё труднее. А потом пользователи говорят, что нажатие на одну кнопку возвращает осмысленный текст, а на другую похожую - заглушку. Потом оказывается, что одно и то же исключение в одном месте перехватывается и просто логируется где-то на полпути к контроллеру, а в другом - перебрасывается дальше.
Получается, что у каждого такого метода может быть несколько состояний: вернул результат, выбросил ValidationException, выбросил NotFoundException, выбросил FooBarException, и т.д. И каждый надо учесть. У Result зависит от подхода. Можно всегда Ok(result) возвращать, можно разбить на Ok и BadResult, можно сделать больше и вообще на клиенте обрабатывать.
В статье я написал, что try-catch используется, но только там, где это действительно необходимо.
Конечно, middleware на случай непредвиденных ошибок есть. Но всё, что можно предвидеть, уходит в Result. Проблема middleware в том, что он одинаково ловит и "wrong id", которое нужно показать пользователю, и null reference со stack trace, которое не нужно показывать пользователю. В моём коде туда попадает только то, что не должно попадать на глаза пользователю для логирования, отправки уведомления об ошибке и показа пользователю заглушки.
Я искал позиции для Senior .NET developer. Конечно, для разных вакансий всё может сильно отличаться. Я все свои отклики записываю в файл, указывая сайт и статус. Самое забавное, что некоторые компании присылают отказы даже спустя месяцы, хотя могли уже и не заморачиваться.
Без проблем нашёл работу через hh в прошлом году. Что я делал не так? А пару раз в неделю на LinkedIn приходят предложения.
Сначала из-за границы принципиально пробовал искать через LinkedIn, Glassdoor, Indeed и пр. По ощущениям, в среднем было порядка 30-50% ответов, пусть даже с отказом. Было мало интервью или невыполнимые условия. Где-то были задания. Потом задолбался и через 3 недели уже была работа, найденная через hh.
Конечно, обвинить сайты в том, что не получается найти работу, - гораздо проще, чем подойти к поиску работы со всей ответственностью, как к отдельной работе.
Когда занимался автоматизацией, где-то 13 лет назад поступил запрос посчитать возможность автоматизации карьера для автоматического вывоза материала. Т.е. есть водитель и грузовик, который будет загружен конвейером. Всё остальное, от въезда до выезда - без людей. На выезде водитель даже сам забирает распечатанную накладную по грузу. Сделал им коммерческое предложение, но до разработки, к сожалению, не дошло. К сожалению, не знаю, к чему они пришли. Но предложение по автоматизации карьера потом было добавлено в наше КП. Так что удивляет, что сейчас об этом пишут так, будто только сейчас это стало чем-то особенным. Конечно, карьеры разные бывают. Но, тем не менее.
В статье не хватило слов "жирдяи", "дрыщи". Неприятно было читать - не дочитал. Надеюсь, больше не будете писать... используя столь неприятный язык.
Аналогично. Давным-давно добавил RSS (тогда ещё в Google Reader) и с тех пор так и пользуюсь.
Сейчас смотрю обновления в Feedly. Очень удобно в приложении пролистывать всё ненужное, а потом на компе смотреть отфильтрованное.
Недавно для себя открыл сценариста Тейлора Шеридана и понял, что можно смотреть не только фильмы определённого режиссёра или платформы, к чему мы уже привыкли, но и сценариста. Это "Йеллоустоун" и все его приквелы, "Король Талсы", "Землевладелец", "Спецназ: Львица" и пр. Он возвращает на экран сильных героев, решающих проблемы, на которых приятно смотреть, за развитием которых интересно наблюдать. У них тоже есть слабости, но не в том виде, в котором показывают последнее время. При том сильные герои - не персонажи комиксов, а живые люди со своими интересными историями. А то, что в "Йеллоустоуне" чуть ли не половина экранного времени уделена красоте природы и обычному ковбойскому быту - особенно радует, позволяя одновременно и расслабиться, и следить за динамичным сюжетом.