Ученый без "хирша" -- не ученый, а наработать "хирш" можно только публикуясь в Scopus/WoS.
То что журналист/писатель может получать деньги за статьи -- не имеет смысла обсуждать. За Научную же публикацию вы с вероятностью 99% деньги от Издательства получать не будете.
Я говорю про то, что статья в этом журнале не будет "научной" и для научного сообщества не будет отличаться от заметки на "Фонтанке". Список ВАК тут -- минимальное требование на звание рецензируемого журнала. Фактически котируются только Scopus/WoS и то не все, а только Q1/Q2.
Если мы говорим о журналистской просветительской деятельности, то да, такие журналы и пути есть, с этим сложно поспорить.
Я не знаю ни одного котирующегося научного журнала, который платит. За рецензирование то в лучшем случае сертификатами одаривают (~100 франков скидки в MDPI, 1 месяц подписки Scopus в Elsevier, например)
За научные статьи и монографии никто не платит авторам. Откройте любой журнал Springer или Elsevier там будут две опции публикации: бесплатно для автора и статьи за пейволом, платно для автора (несколько тысяч долларов) и статьи в открытом доступе. Обе модели не предполагают доход автора вообще.
Отчисления платятся за учебники -- это да, вероятно. Но, это копейки в академической среде, ибо тиражи мизерные нужны .
Проблема поднятая в статье скорее не о публикациях как таковых, а о мусоре который публикуется, цитируется и цитирует только ради факта публикации и цитирований. Особенно этим грешат индусы и китайцы в силу многочисленности групп, что позволяет эффективно раздувать цитируемость. Мне например несколько раз в неделю падает предложение на рецензию очередной "прорывной" статьи от индусов/китайцев с 0.99999 качества, закрытым кодом и датасетом. И зачастую, эти статьи проходят в OA журналы без особых проблем, даже несмотря на сопротивление некоторых рецензентов (сопротивляющихся не большинство, ибо остальным или лень или они такие же, преследующие свои интересы в духе "процитируйте вот этот список и я одобряю статью").
По итогу, сейчас становится все сложнее и сложнее найти SOTA подход, который реально работает и который реально запустить просто потому что все затоплено статьями и докладами низкого уровня без кода и данных.
Хорошая книга (пособие) нужны, в первую очередь, как вы и сказали, для новичков: получить более-менее системное изложение проблемы. А когда какое-то системное понимание есть, то можно спокойно использовать документацию.
Не могу похвастаться идеальным знанием языка, но нак получилось, что пришлось использовать (и да, "дискомфорт" при общении ранее -- это мягко сказано). Так вот сейчас могу сказать, ИМХО, что такие барьеры из-за изначально некорректной методики изучения: мы получали двойки, тройки, подколы и нагоняи за косяки в грамматике, произношении и т.д., что приводит к подсознательной осторожности (это нормально, мозг минимизирует риск негативного подкрепления) при использовании языка и, собственно, дискомфорта. По факту же, если с тобой хотят объясниться, то объяснятся, и не стоит бояться косячить в общении (по крайней мере в случаях, когда это не влияет на бизнес процессы, документы и т д.).
Итого: хочешь выучить язык --- ищи где говорить на этом языке (минимальной грамматики уже достаточно для рядового трёпа о машинах/еде/фреймворках).
Описанные в статье техники -- это скорее способы подсунуть ссылку для перехода. Однако, учитывая, что сейчас Qr кодами все заклеено, я бы не исключал возможность эксплуатации уязвимостей в библиотеках их чтения. Не очень большой, но все же достаточный для пары команд инициализации, объем данных в Qr код затолкать можно. Что-нибудь в духе CVE-2023-40889
Десять лет назад, я не утруждаясь находил что почитать на Хабре утром, днём и вечером, причем статьи от небезызвестного Ализара тогда казались ширпотребом посредственного качества.
Сейчас статей не меньше (но, по ощущениям, и не больше), но Ализарщина часто оказывается чуть ли не единственным, что можно почитать.
Безусловно, попадаются интересные и хорошие работы, но подавляющее большинство -- маркетинговый флуд наполовину сочиненный нейросетями. И, внезапно, если ее вообще убрать, то контента станет катастрофически мало.
Это я к чему: контента не больше, больше стала доля инфомусора в нём.
Почему у меня каждый раз когда я читаю методички по Agile & Co складывается стойкое ощущение, что я читаю методичку для воспитателей детского сада?..
Тут на примере цели:
Fun: ну да, разработчики -- дети, и просто "оптимизация" -- это не понятно и не интересно. Хз, лично мне оптимизация выглядит интереснее, чем лозунги в духе приведенного в примере
Outcome‑oriented: ну цель -- это по определению результат. Процедуры для достижения целей -- это задачи.
Collaborative: вообще ахтунг... Это как? Манипулировать сотрудниками так, чтобы они думали, что краткосрочные бизнес требования -- это из собственное желание!? На сколько я понимаю, люди нынче в основном за деньги работаю, а не за грамоты.
Ultimate: цель это цель, актуальность цели -- отдельная структурная единица, всё-таки. (Это, кстати, яркий пример зачем нужно высшее образование: опыт написания ВКР/Диплома хоть в какой-то степени выстраивает понимание структурных единиц "введения в работу")
Singular: ну тут без комментариев, в целом очевидный факт, но имхо, как замечено выше, малоприятный для реальной разработки. Например, у меня два разраба: один оптимизирует поиск по БД, а второй в это время вполне может заниматься, скажем, исправлением бага в API. Какой смысл их сажать одновременно на одну задачу для одного человека -- не ясно.
Я обычно прошу (и сам коммичу) фиксировать блокноты (jupyter, с выводами, да большие, но удобнее) и пайплайны, даже если не вполне успешно работает. Не единожды доставал из репозиториев код годовой и более давности, когда внезапно понадобилась подобная идея в вообще другом контексте. Плюс, помогает избегать повторений экспериментов, ну и подобие отчётов без лишнего бумагомарания
Даже в случае защиты, тренировка (обучение) формулировать свои мысли и оформлять в связный отчет -- важный момент. Я, например, регулярно сталкивался с неспособностью прокомментировать полученные экспериментальные результаты письменно.
Лично мне приносили на защиту мои же лабораторные работы (мной же и выложенные в свое время) практически 1 в 1 , очевидно, что сложно сделать сильно уникальный отчёт. И нередко вполне успешно защищали его.
Так что Для разрешения вопроса с "списал работу" давно применяется защита этой работы, где компетентному преподавателю не составит труда разобраться освоен ли материал или нет.
Сложность, вероятно, возникает в областях, где текст -- это и есть самоцель (журналистика, например). Но тут, пожалуй, не детектирование вообще может быть критерием, ибо журналиста который пишет как ИИ вряд-ли можно называть высококлассным
В некоторых областях уже давно код генерируется в значительной доле. Некоторые системы управления из матлаба целиком выгружаются в виде сгенерировано кода для целевой платформы.
Проблема в том, что при генерации по правилам можно гарантировать качество. При генерации по случайным распределениям (нейросети) -- гарантировать качество можно только в терминах "в среднем", что, вероятно, допустимо для типичных Crud/тестов(и то спорно), но для более критичных областей -- далеко не факт.
Почему именно Agile и continuous deployment? В некоторых случаях необходимо обеспечивать полный цикл тестирования перед обновлением...
Тут скорее надо в принципе заняться описанием и оптимизацией процессов разработки (читать как понятную последовательность взаимодействий между участниками), Agile это или водопад -- дело десятое.
Задачи, как вы видите, разные. Наличие хорошо описанной задачи в джире не поможет вам найти коммит и его содержание (то есть комментарий коммита), где что-то сломали (никто же не ломает код просто так).
Если у вас опытная команда с единым пониманием ведёт -- подобные соглашения и так выполняются +/- без формальностей, но ни целиком опытной ни тем более когда много людей думают одинаково не бывает. Потому на помощь приходят регламенты, которые по сути своей фиксируют поведение в рамках рабочего процесса. Бонусом, кстати, упрощение онбоардинга (оно проще дать регламент по наймингу коммитов, чем словами объяснять, как тут принято)
ИИ это не только обучить модельку и сделать презентацию. Как минимум, ИИ -- это огромное количество расчетов, для которых (внезапно) питон оказывается медленным. Так, например ядро Triton Inference Server почти на 90% написано на C/C++.
Кроме того, ИИ не только в облаках но и на устройствах, в том числе весьма ограниченных по производительности, где тоже нужно делать embedded решения.
Ученый без "хирша" -- не ученый, а наработать "хирш" можно только публикуясь в Scopus/WoS.
То что журналист/писатель может получать деньги за статьи -- не имеет смысла обсуждать. За Научную же публикацию вы с вероятностью 99% деньги от Издательства получать не будете.
Я говорю про то, что статья в этом журнале не будет "научной" и для научного сообщества не будет отличаться от заметки на "Фонтанке". Список ВАК тут -- минимальное требование на звание рецензируемого журнала. Фактически котируются только Scopus/WoS и то не все, а только Q1/Q2.
Если мы говорим о журналистской просветительской деятельности, то да, такие журналы и пути есть, с этим сложно поспорить.
Он даже не в списке ВАК =), я уж не говорю про Q1/2 "Белый Список" (Scopus + WoS)
Я не знаю ни одного котирующегося научного журнала, который платит. За рецензирование то в лучшем случае сертификатами одаривают (~100 франков скидки в MDPI, 1 месяц подписки Scopus в Elsevier, например)
Если знаете -- подскажите =)
За научные статьи и монографии никто не платит авторам. Откройте любой журнал Springer или Elsevier там будут две опции публикации: бесплатно для автора и статьи за пейволом, платно для автора (несколько тысяч долларов) и статьи в открытом доступе. Обе модели не предполагают доход автора вообще.
Отчисления платятся за учебники -- это да, вероятно. Но, это копейки в академической среде, ибо тиражи мизерные нужны .
Проблема поднятая в статье скорее не о публикациях как таковых, а о мусоре который публикуется, цитируется и цитирует только ради факта публикации и цитирований. Особенно этим грешат индусы и китайцы в силу многочисленности групп, что позволяет эффективно раздувать цитируемость. Мне например несколько раз в неделю падает предложение на рецензию очередной "прорывной" статьи от индусов/китайцев с 0.99999 качества, закрытым кодом и датасетом. И зачастую, эти статьи проходят в OA журналы без особых проблем, даже несмотря на сопротивление некоторых рецензентов (сопротивляющихся не большинство, ибо остальным или лень или они такие же, преследующие свои интересы в духе "процитируйте вот этот список и я одобряю статью").
По итогу, сейчас становится все сложнее и сложнее найти SOTA подход, который реально работает и который реально запустить просто потому что все затоплено статьями и докладами низкого уровня без кода и данных.
Там скорее всего дешёвый инкрементальный энкодер. Более дорогие абсолютные таких проблем лишены.
Хорошая книга (пособие) нужны, в первую очередь, как вы и сказали, для новичков: получить более-менее системное изложение проблемы. А когда какое-то системное понимание есть, то можно спокойно использовать документацию.
Если у вас уже есть готовые модели (и все что для них надо) для предсказания временных рядов, то трудозатраты сводятся к замене датасета.
Не могу похвастаться идеальным знанием языка, но нак получилось, что пришлось использовать (и да, "дискомфорт" при общении ранее -- это мягко сказано). Так вот сейчас могу сказать, ИМХО, что такие барьеры из-за изначально некорректной методики изучения: мы получали двойки, тройки, подколы и нагоняи за косяки в грамматике, произношении и т.д., что приводит к подсознательной осторожности (это нормально, мозг минимизирует риск негативного подкрепления) при использовании языка и, собственно, дискомфорта. По факту же, если с тобой хотят объясниться, то объяснятся, и не стоит бояться косячить в общении (по крайней мере в случаях, когда это не влияет на бизнес процессы, документы и т д.).
Итого: хочешь выучить язык --- ищи где говорить на этом языке (минимальной грамматики уже достаточно для рядового трёпа о машинах/еде/фреймворках).
Описанные в статье техники -- это скорее способы подсунуть ссылку для перехода. Однако, учитывая, что сейчас Qr кодами все заклеено, я бы не исключал возможность эксплуатации уязвимостей в библиотеках их чтения. Не очень большой, но все же достаточный для пары команд инициализации, объем данных в Qr код затолкать можно. Что-нибудь в духе CVE-2023-40889
Десять лет назад, я не утруждаясь находил что почитать на Хабре утром, днём и вечером, причем статьи от небезызвестного Ализара тогда казались ширпотребом посредственного качества.
Сейчас статей не меньше (но, по ощущениям, и не больше), но Ализарщина часто оказывается чуть ли не единственным, что можно почитать.
Безусловно, попадаются интересные и хорошие работы, но подавляющее большинство -- маркетинговый флуд наполовину сочиненный нейросетями. И, внезапно, если ее вообще убрать, то контента станет катастрофически мало.
Это я к чему: контента не больше, больше стала доля инфомусора в нём.
Почему у меня каждый раз когда я читаю методички по Agile & Co складывается стойкое ощущение, что я читаю методичку для воспитателей детского сада?..
Тут на примере цели:
Fun: ну да, разработчики -- дети, и просто "оптимизация" -- это не понятно и не интересно. Хз, лично мне оптимизация выглядит интереснее, чем лозунги в духе приведенного в примере
Outcome‑oriented: ну цель -- это по определению результат. Процедуры для достижения целей -- это задачи.
Collaborative: вообще ахтунг... Это как? Манипулировать сотрудниками так, чтобы они думали, что краткосрочные бизнес требования -- это из собственное желание!? На сколько я понимаю, люди нынче в основном за деньги работаю, а не за грамоты.
Ultimate: цель это цель, актуальность цели -- отдельная структурная единица, всё-таки. (Это, кстати, яркий пример зачем нужно высшее образование: опыт написания ВКР/Диплома хоть в какой-то степени выстраивает понимание структурных единиц "введения в работу")
Singular: ну тут без комментариев, в целом очевидный факт, но имхо, как замечено выше, малоприятный для реальной разработки. Например, у меня два разраба: один оптимизирует поиск по БД, а второй в это время вполне может заниматься, скажем, исправлением бага в API. Какой смысл их сажать одновременно на одну задачу для одного человека -- не ясно.
Я обычно прошу (и сам коммичу) фиксировать блокноты (jupyter, с выводами, да большие, но удобнее) и пайплайны, даже если не вполне успешно работает. Не единожды доставал из репозиториев код годовой и более давности, когда внезапно понадобилась подобная идея в вообще другом контексте. Плюс, помогает избегать повторений экспериментов, ну и подобие отчётов без лишнего бумагомарания
Даже в случае защиты, тренировка (обучение) формулировать свои мысли и оформлять в связный отчет -- важный момент. Я, например, регулярно сталкивался с неспособностью прокомментировать полученные экспериментальные результаты письменно.
До кого-то дошло, до кого-то нет.
Лично мне приносили на защиту мои же лабораторные работы (мной же и выложенные в свое время) практически 1 в 1 , очевидно, что сложно сделать сильно уникальный отчёт. И нередко вполне успешно защищали его.
Так что Для разрешения вопроса с "списал работу" давно применяется защита этой работы, где компетентному преподавателю не составит труда разобраться освоен ли материал или нет.
Сложность, вероятно, возникает в областях, где текст -- это и есть самоцель (журналистика, например). Но тут, пожалуй, не детектирование вообще может быть критерием, ибо журналиста который пишет как ИИ вряд-ли можно называть высококлассным
В некоторых областях уже давно код генерируется в значительной доле. Некоторые системы управления из матлаба целиком выгружаются в виде сгенерировано кода для целевой платформы.
Проблема в том, что при генерации по правилам можно гарантировать качество. При генерации по случайным распределениям (нейросети) -- гарантировать качество можно только в терминах "в среднем", что, вероятно, допустимо для типичных Crud/тестов(и то спорно), но для более критичных областей -- далеко не факт.
Почему именно Agile и continuous deployment? В некоторых случаях необходимо обеспечивать полный цикл тестирования перед обновлением...
Тут скорее надо в принципе заняться описанием и оптимизацией процессов разработки (читать как понятную последовательность взаимодействий между участниками), Agile это или водопад -- дело десятое.
Джира -- это для трека задач
Git -- это для трека кода
Задачи, как вы видите, разные. Наличие хорошо описанной задачи в джире не поможет вам найти коммит и его содержание (то есть комментарий коммита), где что-то сломали (никто же не ломает код просто так).
Если у вас опытная команда с единым пониманием ведёт -- подобные соглашения и так выполняются +/- без формальностей, но ни целиком опытной ни тем более когда много людей думают одинаково не бывает. Потому на помощь приходят регламенты, которые по сути своей фиксируют поведение в рамках рабочего процесса. Бонусом, кстати, упрощение онбоардинга (оно проще дать регламент по наймингу коммитов, чем словами объяснять, как тут принято)
ИИ это не только обучить модельку и сделать презентацию. Как минимум, ИИ -- это огромное количество расчетов, для которых (внезапно) питон оказывается медленным. Так, например ядро Triton Inference Server почти на 90% написано на C/C++.
Кроме того, ИИ не только в облаках но и на устройствах, в том числе весьма ограниченных по производительности, где тоже нужно делать embedded решения.