Как это ни удивительно, но ни в конституции РФ, ни в законах РФ нет требования обеспечивать доступ именно к ютубу, ватсапу и тд, да ещё и с конкретными скоростями и конкретной надёжностью. Следовательно сомневаюсь в каких-либо перспективах у данных дел именно по таким причинам.
Даже в таком случае это вопрос не одного дня и даже не одного месяца, по сути у разработчиков выбор - или плати, или переноси релиз на неопределенное время.
Определенно знали заранее. Если бы не упал - они бы везде и всюду парились, что первые и вообще передовые да ещё и без особого финансирования смогли. А так просто не срослось. Бывает.
Да взять хотя бы такой базовый сценарий работы за компьютером - как работа с файлами, прямо базовая база. Файндер - это буквально худший файловый менеджер эвер.
Понимаю, что не зная альтернативы ко всему можно привыкнуть, но имея альтернативу из домашнего пк с виндой и убунтой, за 8 лет корпоративных макбуков я не смог, и считаю абсолютно алогичным в файндере работу с каталогами.
Зашел почитать актуальные сейчас вопросы, увидел какие-то совсем уж эджкейсы современных возможностей, которые сами по себе то в реальности ближайшие лет 5 можно будет встретить только в документации, а уж подобные нюансы вообще никогда. Ясно, понятно.
С общедоступными нейросетками жаловаться на туториал, когда нейросетка может буквально объяснить любой термин и смысл написанного построив любые желаемые и понятные пользователю аналогии?
Предсказать довольно просто, если вы полностью контролируете ассортимент. Если в магазине будет только овсянка и макароны - то с очень высокой вероятностью можно предсказать, что через 2 года на завтрак человек будет овсянку, а на обед - макароны, за неимением чего-то другого.
Ведь то что человек "будет есть" и то что он "хочет съесть" - может различаться.
Всё несколько сложнее. Хоть нейросетки и помогают с рутиной, но требуют квалифицированной проверки и допиливания результата из-за галлюцинаций.
Подобное мизерное освобождение от рутины может привести к увольнению разве тогда, когда над одним проектом работают десятки людей одинаковой компетенции, за счёт уменьшения рутины. В реальности же такое не часто встречается, чаще большие проекты делятся на небольшие функциональные команды, ведь частая смена контекста снижает погруженность и производительность уже человека.
Соответственно, экономия идёт и ещё долго будет идти не от увольнения 1300 из этих 25000, а от выполнения большего объема задач сотрудником за то же время и чуть более быстрых сроков реализации задач.
В очень отдаленной перспективе использование "ИИ" подобным образом как раз и может дать бесконечную реиграбельность. Условно - поменял пару параметров при запуске и у тебя уже совершенно другая игра в совершенно другом сеттинге с совершенно другими событиями по сюжету. Бесконечная реиграбельность.
Сейчас в новости это конечно не более чем первый шаг младенца, но перспективы просто огромны.
Это лишь означает, что для решения подобной редкой задачи достаточно просто знать, что за графы такие, а дальше рнд и вперёд. Знать все возможные алгоритмы на графах заранее для решения вовсе не обязательно.
А это не особо важно, где денег хватит - там и придётся перекупать.
Все равно кроме этих двух способов решения проблемы дефицита опытных разработчиков - других способов не предусмотрено. Ну не прилетят из космоса с инопланетянами прям завтра десятки и сотни тысяч свободных мидлов и сеньоров. И через год не прилетят, и через 10 лет тоже. И ни какие курсы или универы не будут выдавать десятки тысяч мидло-сеньоров в год.
>> не хватает и программистов ... далеко не всегда могут найти себе работу ... индустрия нуждается в качественных кадрах
Ничего нового для решения проблемы кадров не придумать:
чтобы завтра можно было закрыть позицию на мидла или сеньора, надо не обманываться, что завтра после курсов или универа вдруг волшебным образом будут выходить мидлы с 3+ лет опыта работы и сеньоры с 6+ лет, а нанимать джунов с 0 лет опыта уже сегодня.
либо перекупать зарплатами у других стран, где таких мидлов таки взяли на работу 3+ года назад джунами.
Похоже мы немного о разных задачах для примеров говорим.
Маленьким простым примерам - место в документации, просто показать использование очередной фичи коротким куском кода.
Большое сложное приложение - позволяет показать в реальной жизни жизнеспособность либы, применяемость различных фич либы, различные трейдофы (а они есть всегда) и как их оптимальнее обыгрывать и тд. Да еще и в процессе переписывания такого приложения повсплывает всякое, что заставит выпустить еще десяток версий.
Предлагается, как бы, либа, вокруг которой будет строиться всё приложение и мало кому хотелось бы самому собирать все возможные грабли, а в итоге понять, что тоже самое на реакте было бы лучше, удобнее, быстрее, производительнее, понятнее, протестированнее, менее глючное, да еще и разрабов не надо переучивать.
Как верно замечено, нужен минимум Realworld, а еще лучше какая-нибудь большая админка на реакте, взять тот же react-admin. Чем больше в проекте разнообразных фич будет покрыто - тем больше кейсов выплывет, когда либу придется переписывать и патчить, порой отказываясь от неудачных решений и концепций вообще.
Сейчас, на основе этой статьи как-бы особой ценности от либы не видно вообще, кроме того, что будет чуть меньше строк кода из-за отсутствия useState да useCallback, но получив за это фактическое отсутствие реактивности. Это очень странный кейс для продвижения.
Ну право, сейчас не времена jQuery, чтобы можно было выехать только на наличии jsx синтаксиса. Нужны реальные причины, для чего разрабу брать в проект неоттестированную либу с кучей неизвестных подводных камней, о которой только известно то, что на ней покороче туду-листы с каунтерами получаются.
Именно, потому что если какие-то решения хороши для каунтера и тудушки, то это совсем не означает, что они будут хороши для чего серьезного, с кучей фич и требований.
Я бы не назвал полноценными приложениями - мелкие примеры на десяток файлов.
Еще раз - основная проблема продвижения очередного "убийцы реакта" в том, что на самом реакте люди, от которых зависит выбор стека (хотя бы для внутренних проектов компаний, на внешние никто в здравом уме не потянет кота в мешке), понаписали многие сотни тысяч и миллионы строк кода, понимают минусы-плюсы различных решений на реакте, знакомы с десятками и сотнями библиотек, знают, что при росте проекта всегда смогут найти разработчиков. Им от этих мелких примеров - ни холодно ни жарко.
Нужен действительно большой проект и в первую очередь ориентированный на всякие админки (только на подобных проектах еще возможно затянуть в прод не самое популярное решение "для опыта", если мы говорим о чем-то больше туду-листа на гитхабе). Со всякими графиками, формами, таблицами, пагинациями, правами и тд.
Все эти примеры в репе - конечно окей, но в реальности это было просто потерей времени, которое ничего не даст. Я серьезно, ищите большую админку и переписывайте на свою либу сопровождая серией статей с процессом переписывания и выводами - выводами в чем плюс выбрать именно данную либу, на фоне уже имеющихся и привычных многим решений.
Маленький пример маленького компонента - это конечно весело показывать в выгодном свете. Но если хочется именно попытаться собрать комьюнити и попробовать занять хоть немного места в нише фронта, то видится мне, что для популяризации очередного "убийцы реакта", надо не показывать очередной каунтер с кнопкой, а брать большой серьезный проект на том же гитхабе и переписывать его на своего "убийцу реакта".
И писать уже большую серию статей с конкретными примерами, в чем именно стало лучше и проще и выводами, по типу:
кодовая база сократилась на N%
размер бандла сократился на M%
скорость сборки ускорилась на L%
производительность на клиенте улучшилась на K%
время разработки теоретически могло сократиться на J человекочасов
Без серьезного подхода и серьезных выводов - на либе и через год максимум кто-то набросает очередной каталог фильмов и очередные туду-листы.
Если человек не считает легаси кодом код своего прошлого проекта - то за всё это время с того проекта он ничему не научился и ничего нового не узнал, остался стоять на месте.
И опять же ни слова о конкретных сервисах, о чем и речь. Сервис =\= способ.
Как это ни удивительно, но ни в конституции РФ, ни в законах РФ нет требования обеспечивать доступ именно к ютубу, ватсапу и тд, да ещё и с конкретными скоростями и конкретной надёжностью. Следовательно сомневаюсь в каких-либо перспективах у данных дел именно по таким причинам.
Даже в таком случае это вопрос не одного дня и даже не одного месяца, по сути у разработчиков выбор - или плати, или переноси релиз на неопределенное время.
Определенно знали заранее. Если бы не упал - они бы везде и всюду парились, что первые и вообще передовые да ещё и без особого финансирования смогли. А так просто не срослось. Бывает.
Да взять хотя бы такой базовый сценарий работы за компьютером - как работа с файлами, прямо базовая база. Файндер - это буквально худший файловый менеджер эвер.
Понимаю, что не зная альтернативы ко всему можно привыкнуть, но имея альтернативу из домашнего пк с виндой и убунтой, за 8 лет корпоративных макбуков я не смог, и считаю абсолютно алогичным в файндере работу с каталогами.
Просто есть лишние токены для разбора с помощью ИИ сопроводительных, которые также будут сгенерированы с помощью ИИ.
Зашел почитать актуальные сейчас вопросы, увидел какие-то совсем уж эджкейсы современных возможностей, которые сами по себе то в реальности ближайшие лет 5 можно будет встретить только в документации, а уж подобные нюансы вообще никогда. Ясно, понятно.
С общедоступными нейросетками жаловаться на туториал, когда нейросетка может буквально объяснить любой термин и смысл написанного построив любые желаемые и понятные пользователю аналогии?
Предсказать довольно просто, если вы полностью контролируете ассортимент. Если в магазине будет только овсянка и макароны - то с очень высокой вероятностью можно предсказать, что через 2 года на завтрак человек будет овсянку, а на обед - макароны, за неимением чего-то другого.
Ведь то что человек "будет есть" и то что он "хочет съесть" - может различаться.
Всё несколько сложнее. Хоть нейросетки и помогают с рутиной, но требуют квалифицированной проверки и допиливания результата из-за галлюцинаций.
Подобное мизерное освобождение от рутины может привести к увольнению разве тогда, когда над одним проектом работают десятки людей одинаковой компетенции, за счёт уменьшения рутины. В реальности же такое не часто встречается, чаще большие проекты делятся на небольшие функциональные команды, ведь частая смена контекста снижает погруженность и производительность уже человека.
Соответственно, экономия идёт и ещё долго будет идти не от увольнения 1300 из этих 25000, а от выполнения большего объема задач сотрудником за то же время и чуть более быстрых сроков реализации задач.
В очень отдаленной перспективе использование "ИИ" подобным образом как раз и может дать бесконечную реиграбельность. Условно - поменял пару параметров при запуске и у тебя уже совершенно другая игра в совершенно другом сеттинге с совершенно другими событиями по сюжету. Бесконечная реиграбельность.
Сейчас в новости это конечно не более чем первый шаг младенца, но перспективы просто огромны.
Это лишь означает, что для решения подобной редкой задачи достаточно просто знать, что за графы такие, а дальше рнд и вперёд. Знать все возможные алгоритмы на графах заранее для решения вовсе не обязательно.
А это не особо важно, где денег хватит - там и придётся перекупать.
Все равно кроме этих двух способов решения проблемы дефицита опытных разработчиков - других способов не предусмотрено. Ну не прилетят из космоса с инопланетянами прям завтра десятки и сотни тысяч свободных мидлов и сеньоров. И через год не прилетят, и через 10 лет тоже. И ни какие курсы или универы не будут выдавать десятки тысяч мидло-сеньоров в год.
>> не хватает и программистов ... далеко не всегда могут найти себе работу ... индустрия нуждается в качественных кадрах
Ничего нового для решения проблемы кадров не придумать:
чтобы завтра можно было закрыть позицию на мидла или сеньора, надо не обманываться, что завтра после курсов или универа вдруг волшебным образом будут выходить мидлы с 3+ лет опыта работы и сеньоры с 6+ лет, а нанимать джунов с 0 лет опыта уже сегодня.
либо перекупать зарплатами у других стран, где таких мидлов таки взяли на работу 3+ года назад джунами.
Похоже мы немного о разных задачах для примеров говорим.
Маленьким простым примерам - место в документации, просто показать использование очередной фичи коротким куском кода.
Большое сложное приложение - позволяет показать в реальной жизни жизнеспособность либы, применяемость различных фич либы, различные трейдофы (а они есть всегда) и как их оптимальнее обыгрывать и тд. Да еще и в процессе переписывания такого приложения повсплывает всякое, что заставит выпустить еще десяток версий.
Предлагается, как бы, либа, вокруг которой будет строиться всё приложение и мало кому хотелось бы самому собирать все возможные грабли, а в итоге понять, что тоже самое на реакте было бы лучше, удобнее, быстрее, производительнее, понятнее, протестированнее, менее глючное, да еще и разрабов не надо переучивать.
Как верно замечено, нужен минимум Realworld, а еще лучше какая-нибудь большая админка на реакте, взять тот же react-admin. Чем больше в проекте разнообразных фич будет покрыто - тем больше кейсов выплывет, когда либу придется переписывать и патчить, порой отказываясь от неудачных решений и концепций вообще.
Сейчас, на основе этой статьи как-бы особой ценности от либы не видно вообще, кроме того, что будет чуть меньше строк кода из-за отсутствия useState да useCallback, но получив за это фактическое отсутствие реактивности. Это очень странный кейс для продвижения.
Ну право, сейчас не времена jQuery, чтобы можно было выехать только на наличии jsx синтаксиса. Нужны реальные причины, для чего разрабу брать в проект неоттестированную либу с кучей неизвестных подводных камней, о которой только известно то, что на ней покороче туду-листы с каунтерами получаются.
Именно, потому что если какие-то решения хороши для каунтера и тудушки, то это совсем не означает, что они будут хороши для чего серьезного, с кучей фич и требований.
Я бы не назвал полноценными приложениями - мелкие примеры на десяток файлов.
Еще раз - основная проблема продвижения очередного "убийцы реакта" в том, что на самом реакте люди, от которых зависит выбор стека (хотя бы для внутренних проектов компаний, на внешние никто в здравом уме не потянет кота в мешке), понаписали многие сотни тысяч и миллионы строк кода, понимают минусы-плюсы различных решений на реакте, знакомы с десятками и сотнями библиотек, знают, что при росте проекта всегда смогут найти разработчиков. Им от этих мелких примеров - ни холодно ни жарко.
Нужен действительно большой проект и в первую очередь ориентированный на всякие админки (только на подобных проектах еще возможно затянуть в прод не самое популярное решение "для опыта", если мы говорим о чем-то больше туду-листа на гитхабе). Со всякими графиками, формами, таблицами, пагинациями, правами и тд.
Все эти примеры в репе - конечно окей, но в реальности это было просто потерей времени, которое ничего не даст. Я серьезно, ищите большую админку и переписывайте на свою либу сопровождая серией статей с процессом переписывания и выводами - выводами в чем плюс выбрать именно данную либу, на фоне уже имеющихся и привычных многим решений.
Маленький пример маленького компонента - это конечно весело показывать в выгодном свете. Но если хочется именно попытаться собрать комьюнити и попробовать занять хоть немного места в нише фронта, то видится мне, что для популяризации очередного "убийцы реакта", надо не показывать очередной каунтер с кнопкой, а брать большой серьезный проект на том же гитхабе и переписывать его на своего "убийцу реакта".
И писать уже большую серию статей с конкретными примерами, в чем именно стало лучше и проще и выводами, по типу:
кодовая база сократилась на N%
размер бандла сократился на M%
скорость сборки ускорилась на L%
производительность на клиенте улучшилась на K%
время разработки теоретически могло сократиться на J человекочасов
Без серьезного подхода и серьезных выводов - на либе и через год максимум кто-то набросает очередной каталог фильмов и очередные туду-листы.
Если человек не считает легаси кодом код своего прошлого проекта - то за всё это время с того проекта он ничему не научился и ничего нового не узнал, остался стоять на месте.