Довольно много участвовал в олимпиадах в 00-х, в школьных и вузовских, личных и командных, правда только своего региона. И пока не понимаю решаемой проблемы. Возможно, что-то изменилось за это время, или это мы такие честные были и поэтому про читерские способы не знали. Но даже технически, если регламенты только не изменились, не понятно, как на олимпиаде возможен плагиат, если только не говорим о каких-то заочных форматах. Да даже если и говорим. Потому что на нормальной олимпиаде/контесте задачи пишутся под конкретное мероприятие. Базовые алгоритмы всем известны, но суть задачи не в том, чтобы написать стандартный алгоритм (не считая "утешительных" задач). Соответственно, списать можно разве что у соседа. А этот способ читерства решается организационно - расстановкой рабочих мест, наблюдением со стороны оргкомитета.
Если же говорить о стандартных алгоритмах, которые входят в решение, то здесь ситуация другая. Это спорт, и как в спорте заучиваются до автоматизма базовые движения, так и в олимпиадах по программированию Дейкстра и подобные алгоритмы пишутся наизусть, заученным шаблоном. И тут не то что граф зависимостей, а сам код символ в символ может совпадать у тех, кто готовился вместе или по одному учебнику. А ещё код скорее всего будет максимально похож у "сильных" участников на простых и средних по сложности задачах, где участники почти сразу видят оптимальный алгоритм и его и пишут без лишних действий в коде. Здесь говорю не по наслышке, был опыт ещё и проведения собственных контестов и проверки решений на некоторых олимпиадах, нередко код разных участников, которые точно писали сами, очень и очень похож, в том числе на нигде не опубликованное авторское решение.
Так что да, хотелось бы подробнее рассмотреть, какие ситуации рассматриваются в качестве исходной решаемой проблемы.
Суть же, как я понял, в имитации окна браузера, вот на это надо обращать внимание - что открытое по ссылке окно может быть поддельным, и если оно предлагает авторизацию, то нужно убедиться не только в корректности адреса и проверке SSL, но и настоящее ли это окно.
А остальное - Steam, Discord, Nitro - шелуха, которая может полностью смениться в следующей мошеннической схеме.
Вопрос дилетанта с дивана, чтобы лучше понять проблему: что происходит, если попытаться сделать отдельную нейронную сеть, которая определяет токсичность высказывания? Какие препятствия возникают на этом пути?
Подскажите, пожалуйста, кто разбирается: разве, если бытовой компонент компьютера вроде видеокарты может быть введен из строя или поврежден в результате выполнения на компьютере программы, то разве это проблема программы, а не устройства, его драйвера или ОС?
То есть это похвально, что разработчик ПО принимает меры, но мне казалось, что в первую очередь должен суетиться производитель видеокарты.
Вот эта одна из любимых (был уверен, что как раз из "Медвежонка", но теперь сомневаюсь: 4 варианта ответа, а не 5):
________ стоял ларёк с надписью "Шаверма".(А) В Москве на вокзале (Б) На вокзале в Москве (В) На московском вокзале (Г) На Московском вокзале
К нам в школу почему-то "Медвежонок" не заглядывал, а вот "Кенгуру" было обязательно ежегодно (возможно из-за физ-мат профиля). Но там действительно впечатления какого-то юмора в задачах не отложилось. Запомнилось разве что удивление, что олимпиаду можно запаковать в тест.
Меня вот больше вопрос фотографий интересует. Возможно, у кого-то есть интересные варианты недорогих альтернатив Google Фото?
В Google Фото нравится, что автоматически загружает всё на сервер и что потом можно удалить загруженное с устройства, и хранение бесплатным было. В то же время у веб-версии интерфейс, как по мне, довольно не удобный, сложно, например, выгрузить пачкой фотографии за период.
По случаю изменений в Google Фото решил куда-то переехать. Пока думаю в AWS S3 загружать (наверное должен быть соответствующий софт для Android), а поверх потом можно будет какой-то каталогизатор прикрутить.
Примерно так же понял, что электронная ведётся в любом случае, и вопрос по сути - а хотите ли вы оставить бумажный бэкап. После этого ответ для меня стал очевиден.
Как говорится, "аффтар, пеши исчо"! Тем более что есть следующая часть истории.
Серьёзно, меня лично очень радуют статьи про личный опыт в бизнесе, при этом без рекламы франшиз, как это часто встречается на разных других ресурсах. А Мосигра сейчас про бизнес не пишет по понятным причинам.
Про фестивали, это блин да, если хочешь почувствовать себя спасающим мир героем — работа на фестивале хорошее место для этого. Первые опыты будут примерно такими (ну и, конечно, в части случаев мир спасти удастся не целиком, а в части — удастся, но высокой ценой в прямом смысле). С опытом ситуация должна меняться, и в идеале хорошему организатору в день фестиваля через пару часов после открытия становится нечего делать. Только после прошлого опыта вгоняет в ступор: непонятно, что идёт не так, ведь раньше надо было бегать и решать миллион проблем. Главное понимать, что как раз так и есть нормально.
По-моему, замечательная статья! Очень наглядно показывает, как мы порой любим уходить в технические делали решения частной задачи проекта интересным нам способом и упускаем общую картину. Газон в итоге так и не полит (и задачу явно можно было решить проще), зато сделана система распознавания проплешин травы.
Сам себя нередко на таком часто ловлю, стараюсь вовремя это отслеживать и возвращаться к общей задаче.
Понравилось про программистов, которые оценили разработку в несколько раз выше low-code решения, и про то, как программисты "не воспринимают low-code, потому что боятся потерять работу".
Разве стал бы специалист (любой области) отказываться от инструмента, если он позволяет выполнять ту же работу эффективнее? Я сам порой для некоторых "на коленке" проектов использовал bubble, а для других часами искал подходящие сервисы в надежде сделать проект меньшими усилиями. Но на практике часто уже на этапе знакомства с платформой видишь, что проект в неё в итоге не впишется. И с bubble такая же история: можно быстро сделать прототип, но чем дальше развиваешь, тем понятнее, что нужно быстрее с него слезать и делать "классическое" решение. (Хотя, конечно, там, где дальше прототипа дело не пошло и функционал прототипа простой — время экономится.)
Отсюда и оценка в IT-отделе в несколько раз выше: вероятно, специалисты сразу видят детали проекта и потенциальные узкие места чуть дальше и глубже и закладывают это в оценку. Есть вероятность, что в итоге придётся сделанное за 25к переписывать, вложив ещё 170к, заложенные IT-отделом. Наконец, странно, что это всё происходит внутри одной компании, и никто не попытался выяснить (по крайней мере в статье не рассказано), как же так получилось-то, что сотрудники другого отдела могут сделать то же самое и в несколько раз дешевле, чем их же IT? Тут много чего можно быть же. Либо есть проблемы в HR — люди не на своих местах и нужно тех ребят переместить в IT, раз они так круто делают ПО. Либо более дешёвое решение имеет какие-то недостатки — и тогда неплохо бы обсудить их и соотнести с планами и приоритетами бизнеса. Либо есть проблема в проджект менеджменте — не было человека, который бы состыковал видение программистов и пользователей, они друг друга не поняли, и программисты оценивали более сложную задачу, чем реально нужно было пользователям. А вместо всего этого поверхностно показывается: смотрите, как дёшев low-code, и вот какие нехорошие программисты.
В порядке обсуждения: "Языки программирования с однобуквенным названием"
Ещё можно было бы как-то обыграть в заголовке то, что здесь названия со всеми буквами алфавита, хотя не знаю насколько такие вольности уместны в переводе.
Сложность ещё в правилах, которые автор статьи для себя установил, что в названии допустимы другие символы кроме букв и цифр, это непросто сформулировать коротко.
Но, кажется, слово "название" должно присутствовать в заголовке для формирования правильного ожидания.
Название этой статьи в таком случае должно было быть "Языки программирования, название которых содержит только один буквенный символ" (над формулировкой, конечно, нужно ещё работать)
Довольно много участвовал в олимпиадах в 00-х, в школьных и вузовских, личных и командных, правда только своего региона. И пока не понимаю решаемой проблемы. Возможно, что-то изменилось за это время, или это мы такие честные были и поэтому про читерские способы не знали. Но даже технически, если регламенты только не изменились, не понятно, как на олимпиаде возможен плагиат, если только не говорим о каких-то заочных форматах. Да даже если и говорим. Потому что на нормальной олимпиаде/контесте задачи пишутся под конкретное мероприятие. Базовые алгоритмы всем известны, но суть задачи не в том, чтобы написать стандартный алгоритм (не считая "утешительных" задач). Соответственно, списать можно разве что у соседа. А этот способ читерства решается организационно - расстановкой рабочих мест, наблюдением со стороны оргкомитета.
Если же говорить о стандартных алгоритмах, которые входят в решение, то здесь ситуация другая. Это спорт, и как в спорте заучиваются до автоматизма базовые движения, так и в олимпиадах по программированию Дейкстра и подобные алгоритмы пишутся наизусть, заученным шаблоном. И тут не то что граф зависимостей, а сам код символ в символ может совпадать у тех, кто готовился вместе или по одному учебнику. А ещё код скорее всего будет максимально похож у "сильных" участников на простых и средних по сложности задачах, где участники почти сразу видят оптимальный алгоритм и его и пишут без лишних действий в коде. Здесь говорю не по наслышке, был опыт ещё и проведения собственных контестов и проверки решений на некоторых олимпиадах, нередко код разных участников, которые точно писали сами, очень и очень похож, в том числе на нигде не опубликованное авторское решение.
Так что да, хотелось бы подробнее рассмотреть, какие ситуации рассматриваются в качестве исходной решаемой проблемы.
Было бы интересно об этом подробнее. Можно более формально, что вы имеете в виду под "сгущает краски" и засчёт чего возникает этот эффект?
На такие вопросы Гугл, наверное, должен отвечать американскому суду? А канал может радоваться, что Гугл сумел столько лет его сохранять.
Суть же, как я понял, в имитации окна браузера, вот на это надо обращать внимание - что открытое по ссылке окно может быть поддельным, и если оно предлагает авторизацию, то нужно убедиться не только в корректности адреса и проверке SSL, но и настоящее ли это окно.
А остальное - Steam, Discord, Nitro - шелуха, которая может полностью смениться в следующей мошеннической схеме.
Вопрос дилетанта с дивана, чтобы лучше понять проблему: что происходит, если попытаться сделать отдельную нейронную сеть, которая определяет токсичность высказывания? Какие препятствия возникают на этом пути?
Подскажите, пожалуйста, кто разбирается: разве, если бытовой компонент компьютера вроде видеокарты может быть введен из строя или поврежден в результате выполнения на компьютере программы, то разве это проблема программы, а не устройства, его драйвера или ОС?
То есть это похвально, что разработчик ПО принимает меры, но мне казалось, что в первую очередь должен суетиться производитель видеокарты.
Не помню кто сказал: "Отличная идея: использовать в качестве пароля то, что вы постоянно демонстрируете на публике и не можете изменить".
А для взрослых таких тренировок случаем нет? Немного даже завидно стало. Про психологию общения вообще здорово, это же в жизни постоянно встречается.
Вот эта одна из любимых (был уверен, что как раз из "Медвежонка", но теперь сомневаюсь: 4 варианта ответа, а не 5):
К нам в школу почему-то "Медвежонок" не заглядывал, а вот "Кенгуру" было обязательно ежегодно (возможно из-за физ-мат профиля). Но там действительно впечатления какого-то юмора в задачах не отложилось. Запомнилось разве что удивление, что олимпиаду можно запаковать в тест.
Так в итоге он её создаёт или не он?
Сейчас же вроде майнят на больших SSD, вот и получится похож: тоже будет не достать.
Круто, спасибо. Попробую подключить ваш сервис. Хорошо, что API сделали совместимым.
Меня вот больше вопрос фотографий интересует. Возможно, у кого-то есть интересные варианты недорогих альтернатив Google Фото?
В Google Фото нравится, что автоматически загружает всё на сервер и что потом можно удалить загруженное с устройства, и хранение бесплатным было. В то же время у веб-версии интерфейс, как по мне, довольно не удобный, сложно, например, выгрузить пачкой фотографии за период.
По случаю изменений в Google Фото решил куда-то переехать. Пока думаю в AWS S3 загружать (наверное должен быть соответствующий софт для Android), а поверх потом можно будет какой-то каталогизатор прикрутить.
Примерно так же понял, что электронная ведётся в любом случае, и вопрос по сути - а хотите ли вы оставить бумажный бэкап. После этого ответ для меня стал очевиден.
Кадровые события в электронном виде отправляются работодателем в ПФР в любом случае, вне зависимости от формы трудовой книжки, - отчёт СЗВ-ТД.
Как говорится, "аффтар, пеши исчо"! Тем более что есть следующая часть истории.
Серьёзно, меня лично очень радуют статьи про личный опыт в бизнесе, при этом без рекламы франшиз, как это часто встречается на разных других ресурсах. А Мосигра сейчас про бизнес не пишет по понятным причинам.
Про фестивали, это блин да, если хочешь почувствовать себя спасающим мир героем — работа на фестивале хорошее место для этого. Первые опыты будут примерно такими (ну и, конечно, в части случаев мир спасти удастся не целиком, а в части — удастся, но высокой ценой в прямом смысле). С опытом ситуация должна меняться, и в идеале хорошему организатору в день фестиваля через пару часов после открытия становится нечего делать. Только после прошлого опыта вгоняет в ступор: непонятно, что идёт не так, ведь раньше надо было бегать и решать миллион проблем. Главное понимать, что как раз так и есть нормально.
По-моему, замечательная статья! Очень наглядно показывает, как мы порой любим уходить в технические делали решения частной задачи проекта интересным нам способом и упускаем общую картину. Газон в итоге так и не полит (и задачу явно можно было решить проще), зато сделана система распознавания проплешин травы.
Сам себя нередко на таком часто ловлю, стараюсь вовремя это отслеживать и возвращаться к общей задаче.
Понравилось про программистов, которые оценили разработку в несколько раз выше low-code решения, и про то, как программисты "не воспринимают low-code, потому что боятся потерять работу".
Разве стал бы специалист (любой области) отказываться от инструмента, если он позволяет выполнять ту же работу эффективнее? Я сам порой для некоторых "на коленке" проектов использовал bubble, а для других часами искал подходящие сервисы в надежде сделать проект меньшими усилиями. Но на практике часто уже на этапе знакомства с платформой видишь, что проект в неё в итоге не впишется. И с bubble такая же история: можно быстро сделать прототип, но чем дальше развиваешь, тем понятнее, что нужно быстрее с него слезать и делать "классическое" решение. (Хотя, конечно, там, где дальше прототипа дело не пошло и функционал прототипа простой — время экономится.)
Отсюда и оценка в IT-отделе в несколько раз выше: вероятно, специалисты сразу видят детали проекта и потенциальные узкие места чуть дальше и глубже и закладывают это в оценку. Есть вероятность, что в итоге придётся сделанное за 25к переписывать, вложив ещё 170к, заложенные IT-отделом. Наконец, странно, что это всё происходит внутри одной компании, и никто не попытался выяснить (по крайней мере в статье не рассказано), как же так получилось-то, что сотрудники другого отдела могут сделать то же самое и в несколько раз дешевле, чем их же IT? Тут много чего можно быть же. Либо есть проблемы в HR — люди не на своих местах и нужно тех ребят переместить в IT, раз они так круто делают ПО. Либо более дешёвое решение имеет какие-то недостатки — и тогда неплохо бы обсудить их и соотнести с планами и приоритетами бизнеса. Либо есть проблема в проджект менеджменте — не было человека, который бы состыковал видение программистов и пользователей, они друг друга не поняли, и программисты оценивали более сложную задачу, чем реально нужно было пользователям. А вместо всего этого поверхностно показывается: смотрите, как дёшев low-code, и вот какие нехорошие программисты.
В порядке обсуждения: "Языки программирования с однобуквенным названием"
Ещё можно было бы как-то обыграть в заголовке то, что здесь названия со всеми буквами алфавита, хотя не знаю насколько такие вольности уместны в переводе.
Сложность ещё в правилах, которые автор статьи для себя установил, что в названии допустимы другие символы кроме букв и цифр, это непросто сформулировать коротко.
Но, кажется, слово "название" должно присутствовать в заголовке для формирования правильного ожидания.
Название этой статьи в таком случае должно было быть "Языки программирования, название которых содержит только один буквенный символ" (над формулировкой, конечно, нужно ещё работать)