Pull to refresh
32
0
Send message

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

Если же говорить о стандартных алгоритмах, которые входят в решение, то здесь ситуация другая. Это спорт, и как в спорте заучиваются до автоматизма базовые движения, так и в олимпиадах по программированию Дейкстра и подобные алгоритмы пишутся наизусть, заученным шаблоном. И тут не то что граф зависимостей, а сам код символ в символ может совпадать у тех, кто готовился вместе или по одному учебнику. А ещё код скорее всего будет максимально похож у "сильных" участников на простых и средних по сложности задачах, где участники почти сразу видят оптимальный алгоритм и его и пишут без лишних действий в коде. Здесь говорю не по наслышке, был опыт ещё и проведения собственных контестов и проверки решений на некоторых олимпиадах, нередко код разных участников, которые точно писали сами, очень и очень похож, в том числе на нигде не опубликованное авторское решение.

Так что да, хотелось бы подробнее рассмотреть, какие ситуации рассматриваются в качестве исходной решаемой проблемы.

Было бы интересно об этом подробнее. Можно более формально, что вы имеете в виду под "сгущает краски" и засчёт чего возникает этот эффект?

На такие вопросы Гугл, наверное, должен отвечать американскому суду? А канал может радоваться, что Гугл сумел столько лет его сохранять.

Суть же, как я понял, в имитации окна браузера, вот на это надо обращать внимание - что открытое по ссылке окно может быть поддельным, и если оно предлагает авторизацию, то нужно убедиться не только в корректности адреса и проверке SSL, но и настоящее ли это окно.

А остальное - Steam, Discord, Nitro - шелуха, которая может полностью смениться в следующей мошеннической схеме.

Вопрос дилетанта с дивана, чтобы лучше понять проблему: что происходит, если попытаться сделать отдельную нейронную сеть, которая определяет токсичность высказывания? Какие препятствия возникают на этом пути?

Подскажите, пожалуйста, кто разбирается: разве, если бытовой компонент компьютера вроде видеокарты может быть введен из строя или поврежден в результате выполнения на компьютере программы, то разве это проблема программы, а не устройства, его драйвера или ОС?

То есть это похвально, что разработчик ПО принимает меры, но мне казалось, что в первую очередь должен суетиться производитель видеокарты.

Не помню кто сказал: "Отличная идея: использовать в качестве пароля то, что вы постоянно демонстрируете на публике и не можете изменить".

А для взрослых таких тренировок случаем нет? Немного даже завидно стало. Про психологию общения вообще здорово, это же в жизни постоянно встречается.

Вот эта одна из любимых (был уверен, что как раз из "Медвежонка", но теперь сомневаюсь: 4 варианта ответа, а не 5):

________ стоял ларёк с надписью "Шаверма".(А) В Москве на вокзале (Б) На вокзале в Москве (В) На московском вокзале (Г) На Московском вокзале

К нам в школу почему-то "Медвежонок" не заглядывал, а вот "Кенгуру" было обязательно ежегодно (возможно из-за физ-мат профиля). Но там действительно впечатления какого-то юмора в задачах не отложилось. Запомнилось разве что удивление, что олимпиаду можно запаковать в тест.

созданной экс-президентом США Дональдом Трампом

Трамп при этом пока дистанцируется от новой платформы... Создатели площадки утверждают, что экс-президент не финансирует Gettr.

Так в итоге он её создаёт или не он?

Сейчас же вроде майнят на больших SSD, вот и получится похож: тоже будет не достать.

Круто, спасибо. Попробую подключить ваш сервис. Хорошо, что API сделали совместимым.

Меня вот больше вопрос фотографий интересует. Возможно, у кого-то есть интересные варианты недорогих альтернатив Google Фото?

В Google Фото нравится, что автоматически загружает всё на сервер и что потом можно удалить загруженное с устройства, и хранение бесплатным было. В то же время у веб-версии интерфейс, как по мне, довольно не удобный, сложно, например, выгрузить пачкой фотографии за период.

По случаю изменений в Google Фото решил куда-то переехать. Пока думаю в AWS S3 загружать (наверное должен быть соответствующий софт для Android), а поверх потом можно будет какой-то каталогизатор прикрутить.

Примерно так же понял, что электронная ведётся в любом случае, и вопрос по сути - а хотите ли вы оставить бумажный бэкап. После этого ответ для меня стал очевиден.

Кадровые события в электронном виде отправляются работодателем в ПФР в любом случае, вне зависимости от формы трудовой книжки, - отчёт СЗВ-ТД.

Как говорится, "аффтар, пеши исчо"! Тем более что есть следующая часть истории.


Серьёзно, меня лично очень радуют статьи про личный опыт в бизнесе, при этом без рекламы франшиз, как это часто встречается на разных других ресурсах. А Мосигра сейчас про бизнес не пишет по понятным причинам.


Про фестивали, это блин да, если хочешь почувствовать себя спасающим мир героем — работа на фестивале хорошее место для этого. Первые опыты будут примерно такими (ну и, конечно, в части случаев мир спасти удастся не целиком, а в части — удастся, но высокой ценой в прямом смысле). С опытом ситуация должна меняться, и в идеале хорошему организатору в день фестиваля через пару часов после открытия становится нечего делать. Только после прошлого опыта вгоняет в ступор: непонятно, что идёт не так, ведь раньше надо было бегать и решать миллион проблем. Главное понимать, что как раз так и есть нормально.

По-моему, замечательная статья! Очень наглядно показывает, как мы порой любим уходить в технические делали решения частной задачи проекта интересным нам способом и упускаем общую картину. Газон в итоге так и не полит (и задачу явно можно было решить проще), зато сделана система распознавания проплешин травы.


Сам себя нередко на таком часто ловлю, стараюсь вовремя это отслеживать и возвращаться к общей задаче.

Понравилось про программистов, которые оценили разработку в несколько раз выше low-code решения, и про то, как программисты "не воспринимают low-code, потому что боятся потерять работу".


Разве стал бы специалист (любой области) отказываться от инструмента, если он позволяет выполнять ту же работу эффективнее? Я сам порой для некоторых "на коленке" проектов использовал bubble, а для других часами искал подходящие сервисы в надежде сделать проект меньшими усилиями. Но на практике часто уже на этапе знакомства с платформой видишь, что проект в неё в итоге не впишется. И с bubble такая же история: можно быстро сделать прототип, но чем дальше развиваешь, тем понятнее, что нужно быстрее с него слезать и делать "классическое" решение. (Хотя, конечно, там, где дальше прототипа дело не пошло и функционал прототипа простой — время экономится.)


Отсюда и оценка в IT-отделе в несколько раз выше: вероятно, специалисты сразу видят детали проекта и потенциальные узкие места чуть дальше и глубже и закладывают это в оценку. Есть вероятность, что в итоге придётся сделанное за 25к переписывать, вложив ещё 170к, заложенные IT-отделом. Наконец, странно, что это всё происходит внутри одной компании, и никто не попытался выяснить (по крайней мере в статье не рассказано), как же так получилось-то, что сотрудники другого отдела могут сделать то же самое и в несколько раз дешевле, чем их же IT? Тут много чего можно быть же. Либо есть проблемы в HR — люди не на своих местах и нужно тех ребят переместить в IT, раз они так круто делают ПО. Либо более дешёвое решение имеет какие-то недостатки — и тогда неплохо бы обсудить их и соотнести с планами и приоритетами бизнеса. Либо есть проблема в проджект менеджменте — не было человека, который бы состыковал видение программистов и пользователей, они друг друга не поняли, и программисты оценивали более сложную задачу, чем реально нужно было пользователям. А вместо всего этого поверхностно показывается: смотрите, как дёшев low-code, и вот какие нехорошие программисты.

В порядке обсуждения: "Языки программирования с однобуквенным названием"
Ещё можно было бы как-то обыграть в заголовке то, что здесь названия со всеми буквами алфавита, хотя не знаю насколько такие вольности уместны в переводе.
Сложность ещё в правилах, которые автор статьи для себя установил, что в названии допустимы другие символы кроме букв и цифр, это непросто сформулировать коротко.
Но, кажется, слово "название" должно присутствовать в заголовке для формирования правильного ожидания.

Название этой статьи в таком случае должно было быть "Языки программирования, название которых содержит только один буквенный символ" (над формулировкой, конечно, нужно ещё работать)

1
23 ...

Information

Rating
Does not participate
Registered
Activity