У Microsoft есть хорошие технологии для desktop, это C# и WPF. В то же время MAUI это всё же бывший Xamarin, и больше про мобилки. А писать жрущие скотинки на JS и сувать тупо WebView это конечно печально.
Microsoft надо было развивать дальше WPF до крос-платформенного решения, как AvaloniaUI.
Но вообще поворот в сторону JS думаю из-за каких-то новых ключевых сотрудников, как-бы ни критиковать но популярность JS, успех того же Visual Studio Code, перевод других офисных продуктов на web/JS, в том числе и Teams, вся экосистнма продуктов офисапо сути объединяет система плагинов (веб приложений). Теперь ещё добавить LLM для популярных стеков в целях оптимизации и экономии.
Конечно понятно, что не хотят разрабатывать разные продукты под веб и под каждую ОС ... потому мы пришли к универсальным но спорным по производительности и потреблению.
Считаю, что если человек умеет работать в обоих направлениях: самостоятельно и в команде, то стоит задуматься о полной удалёнке, если конечно поболтать это не главная фича. В офис или к клиенту всегда можно заехать как любая иная командировка. Потому что когда появляется семья, то лучше уделить время семье, а не коллегам, большая часть которых забудет после ухода из компании. Даже школьные и студенческие связи крепче, чем коллеги на работе. Тем не менее всегда есть исключения, всё же зависит ещё от человека.
И нечего ИТ делать в офисе, это не ценность этой профессии. Можно, но не нужно. Ещё и повышенная нагрузка на транспортную систему города, трата времени на путь. Будьте более сознательными, это же не завод.
Если сравнивать с кодом где вручную без ORM фигачить везде execute с запросами. Ну как минимум сравниваем с наихудшим решением без какой-либо архитектуры. Тут не то что Domain модель делает лучше, да тут любая нормальная архитектура будет лучше...
Не было бы проще. Даже после вузов в области ИТ много какие компании дообучали даже специалистов. Где-то видел критику специалистов вуза по логистике со стороны бизнеса, тоже бизнесу нужно больше навыков и практики.
Тех же джунов в хорошие времена брали и своими курсами дообучали.
Даже если ну не помнишь всю теорию, но набрался опыта разработки, приходишь на собес, а там нужно ещё больше чего-то. Им нужно решить конкретную проблему, а не брать спеца который бы, даже если сам, покопался в новой для него проблеме. Это типичная в моём понимании проблема продуктовых компаний.
Зато в аутсорсах планка ниже, так как не знать прям всё это нормально. Специалист разберётся, ну когда конечно не совсем противоположность по опыту. А их дело его "продать" или продать разработку. Но тут часто разработка была на другую страну, то тут некоторая сложность по знанию языка коммуникации.
Согласен, что не всё можно помнить. Хотя немного помню конкретно их разницу.
И да, можно спросить ИИ, хотя я больше смотрю на документацию, так как бывает это закрытый проект и ИИ это как гадалка.
Тем не менее с интевью есть проблемы, когда даже десяток лет опыта не гарантирует, если красноречием не блестать. Проекты бывают огромные и долгие. Ну а что там рассказывать, проблем там было не меньше чем решений. Мы же не продажей проекта занимаемся, сложно бывает помнить все детали, но запоминается общий посыл, очень примерно как решалось, не всё приходилось решать а только какой-то кусочек.
Какая-то подмена понятий, то что работа автоматизируется и что-то заменяется более сложными инструментами это не значит что работа не нужна, это значит что происходят перемены, нарушается баланс. Если работа производит продукт или услугу, на неё есть спрос или спрос был сформирован, значит эта работа в данный момент времени нужна. Но опять же, иногда люди забывают, что ценность в результате, а не процессе и в больших компаниях это сильно размывается или забывают об этом.
Ну а бизнес он всегда ищет нишу, и бизнес очень часто имеет цикл жизни, рождения, роста, стагнации и ... постепенно "умирает") У кого-то конечно он очень долгий.
А вообще кто говорит про ненужную работу, то видать он сам делает ненужную работу.
Согласен, что в компаниях процессы не идеальные, но везде есть причины, не у всех компаний "безграничные" ресурсы и им надо искать доход. Плюс те же менеджеры в ИТ менеджат не один проект, и у них время тоже не резиновое. Поиск клиентов, которые будут платить за продукт/услугу, тоже дело не простое.
Лично я вижу много хотелок, перекладывание ответственности, напишите мне детальные таски, придумайте мне смысл. Мы живём в реальном мире, а не мире бесконечных ресурсов и времени. Таски делают чтобы не потерять, а уточнить всегда есть другие люди и надо немного общаться с ними.
А эти тиктоки и инстаграммы с инфоциганами ... напомнило мне про то что говорит сосед.
Смысл каждый ДЕЛАЕТ себе сам)
Мы делаем продукты и есть клиенты, которым конкретно что-то надо. А если продукт большой, то клиентов много и не видно ценности, но это не значит что её нет.
Лично у меня по наблюдениям опыт, что когда человек переходит в область критики налаживания процессов через не детальная задача, надо процессы менять, то в итоге человек с себя снимает ответственность, а потом вообще нихера не делает. А ещё и деньги получает за это, хотя позиция на то чтобы решать проблемы, а не перекладывать.
Обсуждение фич это полезно. Но дух статьи всё же претензии и вкусовщина.
Часть это просто про альясы и совместимость, ничего особого чтобы были претензии.
Больше возможностей ref это же афигенно. Я давно считаю, что C# делали именно так, чтобы выжимать все соки в managed, но при этом конструкции языка не на столько плохо читаемы, как у C++. Так же в отличии от Java, у котрого нету нормального понятия расширяемых value type, и отсутствие примитивов как тип в генериках, и вытекающие из этого проблемы и workarounds. Я бы сказал КОСТЫЛИ языков где нету расширяемых value type (структур).
Абсолютно согласен. Только, что они достаточно поздно перешли в cross-platform. Плюс когда он был Windows-only, то могу предположить, что кто-то мог не любить язык из-за того что был проприетарный runtime.
Но и сейчас сложнее догонять других. Нынче слишком популяр стал JS, как один язык на всё. При это такие языки имеют ряд особенностей и обходных путей, чтобы работал более менее эффективно. Ну а некоторым в кайф не думать о типах, и соответственно об производительности.
Так же у dotnet runtime нормальная версионность и выбора runtime, никогда не было проблем в множестве версий dotnet. После C# смотрю на всякие nvm, rvm, pyenv как на решение проблемы, которую могли бы решить изначально.
Использовал Avalonia в последних разрабатываемых утилита. Работает хорошо, мне как когда-то использующий WPF, понравилось, буду использовать и в новых проектах.
Из минусов, в последних версиях выкинули поддержку встроенного инспектора для отладки визуального дерева и стилей. И теперь только новыйч внешний, который требует вход. Ну вот это плохо.
Интересно что это оправдывает мои ожидания, что люди часто будут использовать ИИ, и тем самым учиться формулировать предложения несколько иначе. ИИ ведь взлетел именно своей дипломатичностью и его не редко использовали для решения конфликтов или например обоснование возврата товара в магазин.
Но на другой стороне у нас то, что обучение ИИ может впасть в "рекурсию", когда оно обучается на своих же данные, а данные например низкого "качества", будет меньше источников данных. И если это так и оставить, то ИИ скатится так же как люди, не на столько как не образованные совсем, но качество упадёт.
Тоже уже несколько лет стал применять такой вариант, или гибридный, потому с ростом проекта количество моделей становится большим, папки огромные или папок много, но они раскиданы на слои.
Потому удобнее, когда большая часть фичи и всего его моделей можно уложить в отдельный скоп, в отдельную папку.
Потом деление на namespace так же будет ограничено папкой, и не видеть эти тучи других объектов.
Достаточно спорный вывод, по статистике новых вопросов, что ИИ добил. Оно дейстивтельно убило. Потому что не могут вопросы бесконечно расти это раз. Ну а второе резкое падение вопросов это действительно по причине LLM, и это по мне основная причина.
Выглядит как Чем опасен Python, и как использовать готовые C-ые костыли, чтобы он работал хорошо.
Я, если честно, не понимаю, почему Python суют во все места, где он не предназначен. А затем создают C-ые костыли, начинку, чтобы решить проблему производительности.
А ещё не забываем обратную связь. С каждым разом будет становится всё больше "мусорных" данных, проектов, написанных самой же LLM. Если в её обучение будет это всё попадать, то это будет приводит к её вырождению и падению качества ответов.
Зависит от задачи. Потому что переключение контекста, когда потоки и так могут спать большую часть времени, не так сильно влияет. Но тут другой фактор, по-первых потоку надо выделять ресурсы, например, тот же стэк. Если часто создавать, то будет тратиться время на создание.
Я придерживаюсь, что если задача постоянная фоновая, то лучше напишу поток, который например делает опрос, инициирует сетевое общение для актуализации данных, чем буду городить это на Task-ах. И упаси делать LongRunning таски с циклом.
Thread имеют ещё полезную штуку как имена. Тоже удобно это устанавливать и в логах добавлять эту инфу.
Потому смотря где.
Для асинхронности и любой I/O операции и зависящих от неё, то конечно Task.
У Microsoft есть хорошие технологии для desktop, это C# и WPF. В то же время MAUI это всё же бывший Xamarin, и больше про мобилки. А писать жрущие скотинки на JS и сувать тупо WebView это конечно печально.
Microsoft надо было развивать дальше WPF до крос-платформенного решения, как AvaloniaUI.
Но вообще поворот в сторону JS думаю из-за каких-то новых ключевых сотрудников, как-бы ни критиковать но популярность JS, успех того же Visual Studio Code, перевод других офисных продуктов на web/JS, в том числе и Teams, вся экосистнма продуктов офисапо сути объединяет система плагинов (веб приложений). Теперь ещё добавить LLM для популярных стеков в целях оптимизации и экономии.
Конечно понятно, что не хотят разрабатывать разные продукты под веб и под каждую ОС ... потому мы пришли к универсальным но спорным по производительности и потреблению.
Считаю, что если человек умеет работать в обоих направлениях: самостоятельно и в команде, то стоит задуматься о полной удалёнке, если конечно поболтать это не главная фича. В офис или к клиенту всегда можно заехать как любая иная командировка. Потому что когда появляется семья, то лучше уделить время семье, а не коллегам, большая часть которых забудет после ухода из компании. Даже школьные и студенческие связи крепче, чем коллеги на работе. Тем не менее всегда есть исключения, всё же зависит ещё от человека.
И нечего ИТ делать в офисе, это не ценность этой профессии. Можно, но не нужно. Ещё и повышенная нагрузка на транспортную систему города, трата времени на путь. Будьте более сознательными, это же не завод.
Если сравнивать с кодом где вручную без ORM фигачить везде execute с запросами. Ну как минимум сравниваем с наихудшим решением без какой-либо архитектуры. Тут не то что Domain модель делает лучше, да тут любая нормальная архитектура будет лучше...
Не было бы проще. Даже после вузов в области ИТ много какие компании дообучали даже специалистов. Где-то видел критику специалистов вуза по логистике со стороны бизнеса, тоже бизнесу нужно больше навыков и практики.
Тех же джунов в хорошие времена брали и своими курсами дообучали.
Даже если ну не помнишь всю теорию, но набрался опыта разработки, приходишь на собес, а там нужно ещё больше чего-то. Им нужно решить конкретную проблему, а не брать спеца который бы, даже если сам, покопался в новой для него проблеме. Это типичная в моём понимании проблема продуктовых компаний.
Зато в аутсорсах планка ниже, так как не знать прям всё это нормально. Специалист разберётся, ну когда конечно не совсем противоположность по опыту. А их дело его "продать" или продать разработку. Но тут часто разработка была на другую страну, то тут некоторая сложность по знанию языка коммуникации.
Согласен, что не всё можно помнить. Хотя немного помню конкретно их разницу.
И да, можно спросить ИИ, хотя я больше смотрю на документацию, так как бывает это закрытый проект и ИИ это как гадалка.
Тем не менее с интевью есть проблемы, когда даже десяток лет опыта не гарантирует, если красноречием не блестать. Проекты бывают огромные и долгие. Ну а что там рассказывать, проблем там было не меньше чем решений. Мы же не продажей проекта занимаемся, сложно бывает помнить все детали, но запоминается общий посыл, очень примерно как решалось, не всё приходилось решать а только какой-то кусочек.
Какая-то подмена понятий, то что работа автоматизируется и что-то заменяется более сложными инструментами это не значит что работа не нужна, это значит что происходят перемены, нарушается баланс. Если работа производит продукт или услугу, на неё есть спрос или спрос был сформирован, значит эта работа в данный момент времени нужна. Но опять же, иногда люди забывают, что ценность в результате, а не процессе и в больших компаниях это сильно размывается или забывают об этом.
Ну а бизнес он всегда ищет нишу, и бизнес очень часто имеет цикл жизни, рождения, роста, стагнации и ... постепенно "умирает") У кого-то конечно он очень долгий.
А вообще кто говорит про ненужную работу, то видать он сам делает ненужную работу.
Согласен, что в компаниях процессы не идеальные, но везде есть причины, не у всех компаний "безграничные" ресурсы и им надо искать доход. Плюс те же менеджеры в ИТ менеджат не один проект, и у них время тоже не резиновое. Поиск клиентов, которые будут платить за продукт/услугу, тоже дело не простое.
Лично я вижу много хотелок, перекладывание ответственности, напишите мне детальные таски, придумайте мне смысл. Мы живём в реальном мире, а не мире бесконечных ресурсов и времени. Таски делают чтобы не потерять, а уточнить всегда есть другие люди и надо немного общаться с ними.
А эти тиктоки и инстаграммы с инфоциганами ... напомнило мне про то что говорит сосед.
Смысл каждый ДЕЛАЕТ себе сам)
Мы делаем продукты и есть клиенты, которым конкретно что-то надо. А если продукт большой, то клиентов много и не видно ценности, но это не значит что её нет.
Лично у меня по наблюдениям опыт, что когда человек переходит в область критики налаживания процессов через не детальная задача, надо процессы менять, то в итоге человек с себя снимает ответственность, а потом вообще нихера не делает. А ещё и деньги получает за это, хотя позиция на то чтобы решать проблемы, а не перекладывать.
Обсуждение фич это полезно. Но дух статьи всё же претензии и вкусовщина.
Часть это просто про альясы и совместимость, ничего особого чтобы были претензии.
Больше возможностей ref это же афигенно. Я давно считаю, что C# делали именно так, чтобы выжимать все соки в managed, но при этом конструкции языка не на столько плохо читаемы, как у C++. Так же в отличии от Java, у котрого нету нормального понятия расширяемых value type, и отсутствие примитивов как тип в генериках, и вытекающие из этого проблемы и workarounds. Я бы сказал КОСТЫЛИ языков где нету расширяемых value type (структур).
Абсолютно согласен. Только, что они достаточно поздно перешли в cross-platform. Плюс когда он был Windows-only, то могу предположить, что кто-то мог не любить язык из-за того что был проприетарный runtime.
Но и сейчас сложнее догонять других. Нынче слишком популяр стал JS, как один язык на всё. При это такие языки имеют ряд особенностей и обходных путей, чтобы работал более менее эффективно. Ну а некоторым в кайф не думать о типах, и соответственно об производительности.
Так же у dotnet runtime нормальная версионность и выбора runtime, никогда не было проблем в множестве версий dotnet. После C# смотрю на всякие nvm, rvm, pyenv как на решение проблемы, которую могли бы решить изначально.
Использовал Avalonia в последних разрабатываемых утилита. Работает хорошо, мне как когда-то использующий WPF, понравилось, буду использовать и в новых проектах.
Из минусов, в последних версиях выкинули поддержку встроенного инспектора для отладки визуального дерева и стилей. И теперь только новыйч внешний, который требует вход. Ну вот это плохо.
Когда переименовывается проект, а папку оно не меняет, и тогда нужно редактировать.
А еще бывали хвосты архитектуры конфигурации плюсов попадали, их проще было ручками удалить.
Ещё одна опция это обучающиеся материалы, что туда вошло, могло и это повлиять на этот эффект.
Интересно что это оправдывает мои ожидания, что люди часто будут использовать ИИ, и тем самым учиться формулировать предложения несколько иначе. ИИ ведь взлетел именно своей дипломатичностью и его не редко использовали для решения конфликтов или например обоснование возврата товара в магазин.
Но на другой стороне у нас то, что обучение ИИ может впасть в "рекурсию", когда оно обучается на своих же данные, а данные например низкого "качества", будет меньше источников данных. И если это так и оставить, то ИИ скатится так же как люди, не на столько как не образованные совсем, но качество упадёт.
Я тоже люблю выдумывать слова и делал это раньше, это не показатель ИИ =)
API же не отменяет, что для безопасности нужен ещё слой авторизации. А просто апиха, SDK для неё, то это ещё не сложные вещи.
Те кто хотел давать данные, и раньше делали API, а те кто не хотят, те и MCP не заведут.
Тоже уже несколько лет стал применять такой вариант, или гибридный, потому с ростом проекта количество моделей становится большим, папки огромные или папок много, но они раскиданы на слои.
Потому удобнее, когда большая часть фичи и всего его моделей можно уложить в отдельный скоп, в отдельную папку.
Потом деление на namespace так же будет ограничено папкой, и не видеть эти тучи других объектов.
Достаточно спорный вывод, по статистике новых вопросов, что ИИ добил. Оно дейстивтельно убило. Потому что не могут вопросы бесконечно расти это раз. Ну а второе резкое падение вопросов это действительно по причине LLM, и это по мне основная причина.
Выглядит как Чем опасен Python, и как использовать готовые C-ые костыли, чтобы он работал хорошо.
Я, если честно, не понимаю, почему Python суют во все места, где он не предназначен. А затем создают C-ые костыли, начинку, чтобы решить проблему производительности.
Примерно такая же ситуация и у NodeJS.
А ещё не забываем обратную связь. С каждым разом будет становится всё больше "мусорных" данных, проектов, написанных самой же LLM. Если в её обучение будет это всё попадать, то это будет приводит к её вырождению и падению качества ответов.
Зависит от задачи. Потому что переключение контекста, когда потоки и так могут спать большую часть времени, не так сильно влияет. Но тут другой фактор, по-первых потоку надо выделять ресурсы, например, тот же стэк. Если часто создавать, то будет тратиться время на создание.
Я придерживаюсь, что если задача постоянная фоновая, то лучше напишу поток, который например делает опрос, инициирует сетевое общение для актуализации данных, чем буду городить это на Task-ах. И упаси делать LongRunning таски с циклом.
Thread имеют ещё полезную штуку как имена. Тоже удобно это устанавливать и в логах добавлять эту инфу.
Потому смотря где.
Для асинхронности и любой I/O операции и зависящих от неё, то конечно Task.