Проблема null не в том что его надо избегать а в том когда метод который !не должен! возвращать null начинает его возвращать. Т.е. это уже перетекает в плоскость логики и ожиданий от вызывающего кода. Но тоже самое будет например в случае если метод возвращает int но четко написано что отрицательных значений не может быть а потом бац и возвращается отрицательное значение которое вызывающий код явно не будет ожидать.
Тут еще важный момент что нужна не просто вышка а вышка по айтишной или околоайтишной специальности. Потому что например инженер-озеленитель после окончания вышки также имеет и высшее техническое образование и является инженером но обладает ли он той же базой знаний как инженер учившийся на айтишной специальности?
Для многих удаленка удобна из-за отсутствия необходимости добираться по много времени в пробкам в часы пик до работы, также открылись возможности куда-то сходить рядом с домом сразу после работы а не ехать еще час и более и уставшим плюхнуться на диванчик. Незабываем про возможность пойти отвести детей в садик/выгулять собаку/сходить в магаз/сделать какие-то дела в рабочее по факту время и в большинстве это происходит без ущерба для работы.
Кстати, если в России ручной тестировщик и автотестер — обязательные члены любой команды
громкое заявление что они обязательные, за время моей работы просто тестировщик (обычно ручник) когда был и был именно в моей команде а не как это бывает в отдельном отделе тестирования то это уже было прям радость. А так тестированием занимались кто угодно но кроме тестировщиков.
От того, что в библиотеке старые подходы она хуже работать не станет.
Библиотека хуже работать не станет но если Вам вдруг по каким-то причинам понадобиться открыть ее и разобраться с багом каким-нибудь или даже доработать под себя потому что ее давно не обновляли вот тогда то и начнутся трудности. И чем она старее она тем больнее с ней будет работать.
Откройте любую старую С++ библиотеку и у Вас хлынет кровь из глаз потому что ее писали десятки лет назад используя старую версию компилятора, использовались старые функций из стандартной библиотеки которые могут быть уже deprecated, старые подходы к решению типовых задач, старые паттерны и т.п.
Это прекрасно, и во все библиотеки накатывается автоматически? Потому что если нет то проблему старых библиотек это не решает. Рентабельность любого подобного механизма покажет себя только через годы когда будет все еще что-то написанное ниже на нцать версий языка и надо будет это что-то мигрировать на последнюю версию. Или если автор библиотеки считает что ему не нужна новая версия языка и он хочет навсегда остаться на одной.
Конечно накопятся разные проблемы, но тех, которые заложены в сами основы языков и культуры С/С++ точно не появятся.
Они решены на момент создания языка, конечно они не появятся. Еще раз мысль в том что 30 лет назад когда С++ стал тем кем он стал не существовало той критической массы знаний и подходов которые есть сейчас и даже цели создания были другими, С++ это продукт своего времени, да сейчас он кажется сложным/странным/неудобным/неочевидным, но через 30 лет Rust также будет таким же старым языком потому что мир не стоит на месте.
Если Rust будет придерживаться обратной совместимости как C++ то через 30 лет также обрастет кучей "старых подходов", "сахарком", "библиотеками написанными черт пойми как" и т.п. На мой взгляд любое сравнение давно существующего языка с новым которым решил какие-то проблемы которые есть в старом абсолютно бессмысленно. Через 30 лет существования Rust-а появиться новый язык который также решит какие-то проблемы Rust-а которые накопились за эти 30 лет его существования.
Это увеличит время вывода продуктов на рынок, но уже готовятся законодательные нормы, которые заставят поставщиков ПО серьёзнее относиться к безопасности.
Боюсь что законодательные нормы только усугубят ситуацию, чтобы писать очень качественное ПО с акцентом на безопасность надо умножать любой бюджет на 2 (кто знает может даже на 22) и время соответственно, надо писать тесты, запускать инфру для тонны проверок (еще и проверять код всех зависимостей), контролировать исполнителей и т.п. бизнесы/государства точно готовы заплатить за это? А готовы ли конечные пользователи заплатить цену намного большую чем у конкурентов? Законодательная база фундаментально это ситуацию не изменит, просто уменьшит количество подрядчиков.
<input> заточен именно под это, особенно при правильной настройке.
Заточено под что? Различие в работе даже между html движками на голом input-e будут заметны. И если надо настраивать (особенно для каждого движка по своему) то простите грошь цена такому "классному" инструменту, проще использовать нативный контрол который просто из коробки будет таким как надо.
А вообще, как это ни странно, для кого я работал, все, наоборот, хотели кросс-платформенную унификацию дизайна.
Я говорил не про дизайн а про поведение нативных контролов. Дизайн понятно можно накидать быстро а вот повторить поведение/анимации/навигацию/системные вызовы/интеграции и чтобы пользователь ничего не заметил тут уже сложнее. Например ну допустим повторили Вы экран iOS приложение до пикселя но при взаимодействии с чем-то в нативном контроле вызвается системная менюшка или функцию например а в Вашем аналоге такое реализовать просто невозможно.
Из rich-вещей я написал на HTML аналог
И немного занудства, корректно говорить написал на "Web технологиях" потому что явно вы использовали и CSS и JS а то выглядит как будто Вы пользовались только HTML.
Что-то лучше в описании интерфейса чем HTML/CSS/JS вряд ли можно придумать. Тут вопрос в том а точно оно Вам надо в десктопным/мобильных приложениях? Например в мобильных приложениях есть нативные контролы которые имеют нативное поведение к которому привыкли пользователи но Вам в Вашем WebBrowserBasedApplication необходимо самому это реализовывать и когда в новом sdk что-то меняется да надо снова догонять.
Мобильные и десктопные HTML-приложения можно писать на C++, C#, Java, JS, Rust… Веб-приложения (у которых бизнес-логика на стороне сервера) можно писать на C#, Java, PHP, ROR и т.п.
Это зависит от приложения, если Вам только отобразить "также как на сайте" и все то да, но если надо использовать нативные фичи на полную, есть какая-то логика которую можно выполнять на стороне приложения но которая изначально написана на стороне сервера, то тут уже не все так однозначно.
Но вопрос-то остается открытым — вы бы взяли себе такого кандидата?
Вопрос взять или нет кандидата определяет собеседование а не строчки в резюме/сопроводительном письме и если бы он (кандидат) его прошел и показал требуемый набор знаний то я бы его взял. Выше Вы пишете "Но самое интересное в конце в блоке «О себе» — готов бить лица за критику. Мы правильно поняли?" а если Вы все же неправильно поняли?
По крайней мере профессионализм по одной строчке в статье мы точно не определяем.
Простите но из Вашей статьи непонятно этот кандидат был отсеян на этапе чтения сопроводительного письма или уже после/перед прохождения собеседования? Дальше идет скриншот примера где сложно сказать в чем проблема и кто кому пишет? И самое главное непонятно в чем суть - начальник написал двум исполнителям которые что-то одно делают(или разное?) о проблеме и каждый из них написал что это не его ответственность? Это может быть как проблемой начальника и организации в целом так и проблемой исполнителей. Начальник вместо того чтобы разбираться просто матом послал первого из них разбираться, это может говорить и о том что исполнитель плохой и футболит и о том что начальник вместо того чтобы разобраться "кто виноват и что делать" просто ставит ультиматумы первому попавшемуся исполнителю. Я к тому что пример не коррелирует или слабо коррелирует с указание строчки в сопроводительном письме и определении кого то как нестабильного, нестабильность <> неисполнительность. Более того определить будет ли человек футболить или нет на работе невозможно просто читая резюме, да даже на собеседовании это вряд ли получиться определить, только когда он начнет работать это выясниться и то это может проявиться через время когда он успокоиться что не потеряет место или например если выгорит.
Я говорил о Вашем утверждении из статьи где Вы говорите что не будете менять стек. Не очень понятно причем здесь мое желание? Моя мысль в комментарии выше как бы намекает что если завтра измениться востребованность Вашего стека на рынке то с наибольшей вероятность Вам также придется переобуться на актуальную технологию просто чтобы быть востребованным на рынке.
Я уже не поменяю стек, ибо понимаю, что частые переключения стека могут привести к деградации опыта и обесценению навыков. В результате я могу оказаться менее востребованным на рынке труда, и потребуются годы, чтобы достичь того уровня, который у был до изменений.
Просиживание штанов в одном стеке наоборот приводит к "деградации" опыта и в один прекрасный момент этот самый стек может стать не актуальным что уже ударит по востребованности на рынке труда поэтому не все так однозначно.
Ну допустим мы используем голый SQL. Завтра меняется структура и что требуется сделать? Найти по поиску все места где использовались измененные таблицы и поменять заменой или руками и так каждый раз, так удобней работать?
Проблема null не в том что его надо избегать а в том когда метод который !не должен! возвращать null начинает его возвращать. Т.е. это уже перетекает в плоскость логики и ожиданий от вызывающего кода. Но тоже самое будет например в случае если метод возвращает int но четко написано что отрицательных значений не может быть а потом бац и возвращается отрицательное значение которое вызывающий код явно не будет ожидать.
Это близкая специальность к архитектору (не ПО а из строительных направлений).
Тут еще важный момент что нужна не просто вышка а вышка по айтишной или околоайтишной специальности. Потому что например инженер-озеленитель после окончания вышки также имеет и высшее техническое образование и является инженером но обладает ли он той же базой знаний как инженер учившийся на айтишной специальности?
Для многих удаленка удобна из-за отсутствия необходимости добираться по много времени в пробкам в часы пик до работы, также открылись возможности куда-то сходить рядом с домом сразу после работы а не ехать еще час и более и уставшим плюхнуться на диванчик. Незабываем про возможность пойти отвести детей в садик/выгулять собаку/сходить в магаз/сделать какие-то дела в рабочее по факту время и в большинстве это происходит без ущерба для работы.
громкое заявление что они обязательные, за время моей работы просто тестировщик (обычно ручник) когда был и был именно в моей команде а не как это бывает в отдельном отделе тестирования то это уже было прям радость. А так тестированием занимались кто угодно но кроме тестировщиков.
Библиотека хуже работать не станет но если Вам вдруг по каким-то причинам понадобиться открыть ее и разобраться с багом каким-нибудь или даже доработать под себя потому что ее давно не обновляли вот тогда то и начнутся трудности. И чем она старее она тем больнее с ней будет работать.
Откройте любую старую С++ библиотеку и у Вас хлынет кровь из глаз потому что ее писали десятки лет назад используя старую версию компилятора, использовались старые функций из стандартной библиотеки которые могут быть уже deprecated, старые подходы к решению типовых задач, старые паттерны и т.п.
Проблемы старых библиотек не в том что они не компилируются а в том что они написаны на старых редакциях языка с использованием "старых подходов".
Это прекрасно, и во все библиотеки накатывается автоматически? Потому что если нет то проблему старых библиотек это не решает. Рентабельность любого подобного механизма покажет себя только через годы когда будет все еще что-то написанное ниже на нцать версий языка и надо будет это что-то мигрировать на последнюю версию. Или если автор библиотеки считает что ему не нужна новая версия языка и он хочет навсегда остаться на одной.
Они решены на момент создания языка, конечно они не появятся. Еще раз мысль в том что 30 лет назад когда С++ стал тем кем он стал не существовало той критической массы знаний и подходов которые есть сейчас и даже цели создания были другими, С++ это продукт своего времени, да сейчас он кажется сложным/странным/неудобным/неочевидным, но через 30 лет Rust также будет таким же старым языком потому что мир не стоит на месте.
Если Rust будет придерживаться обратной совместимости как C++ то через 30 лет также обрастет кучей "старых подходов", "сахарком", "библиотеками написанными черт пойми как" и т.п. На мой взгляд любое сравнение давно существующего языка с новым которым решил какие-то проблемы которые есть в старом абсолютно бессмысленно. Через 30 лет существования Rust-а появиться новый язык который также решит какие-то проблемы Rust-а которые накопились за эти 30 лет его существования.
"упрощая игру в игры" :) Игра в игру, новое измерение.
Боюсь что законодательные нормы только усугубят ситуацию, чтобы писать очень качественное ПО с акцентом на безопасность надо умножать любой бюджет на 2 (кто знает может даже на 22) и время соответственно, надо писать тесты, запускать инфру для тонны проверок (еще и проверять код всех зависимостей), контролировать исполнителей и т.п. бизнесы/государства точно готовы заплатить за это? А готовы ли конечные пользователи заплатить цену намного большую чем у конкурентов? Законодательная база фундаментально это ситуацию не изменит, просто уменьшит количество подрядчиков.
Заточено под что? Различие в работе даже между html движками на голом input-e будут заметны. И если надо настраивать (особенно для каждого движка по своему) то простите грошь цена такому "классному" инструменту, проще использовать нативный контрол который просто из коробки будет таким как надо.
Я говорил не про дизайн а про поведение нативных контролов. Дизайн понятно можно накидать быстро а вот повторить поведение/анимации/навигацию/системные вызовы/интеграции и чтобы пользователь ничего не заметил тут уже сложнее. Например ну допустим повторили Вы экран iOS приложение до пикселя но при взаимодействии с чем-то в нативном контроле вызвается системная менюшка или функцию например а в Вашем аналоге такое реализовать просто невозможно.
И немного занудства, корректно говорить написал на "Web технологиях" потому что явно вы использовали и CSS и JS а то выглядит как будто Вы пользовались только HTML.
Что-то лучше в описании интерфейса чем HTML/CSS/JS вряд ли можно придумать. Тут вопрос в том а точно оно Вам надо в десктопным/мобильных приложениях? Например в мобильных приложениях есть нативные контролы которые имеют нативное поведение к которому привыкли пользователи но Вам в Вашем WebBrowserBasedApplication необходимо самому это реализовывать и когда в новом sdk что-то меняется да надо снова догонять.
Это зависит от приложения, если Вам только отобразить "также как на сайте" и все то да, но если надо использовать нативные фичи на полную, есть какая-то логика которую можно выполнять на стороне приложения но которая изначально написана на стороне сервера, то тут уже не все так однозначно.
Вопрос взять или нет кандидата определяет собеседование а не строчки в резюме/сопроводительном письме и если бы он (кандидат) его прошел и показал требуемый набор знаний то я бы его взял. Выше Вы пишете "Но самое интересное в конце в блоке «О себе» — готов бить лица за критику. Мы правильно поняли?" а если Вы все же неправильно поняли?
Простите но из Вашей статьи непонятно этот кандидат был отсеян на этапе чтения сопроводительного письма или уже после/перед прохождения собеседования? Дальше идет скриншот примера где сложно сказать в чем проблема и кто кому пишет? И самое главное непонятно в чем суть - начальник написал двум исполнителям которые что-то одно делают(или разное?) о проблеме и каждый из них написал что это не его ответственность? Это может быть как проблемой начальника и организации в целом так и проблемой исполнителей. Начальник вместо того чтобы разбираться просто матом послал первого из них разбираться, это может говорить и о том что исполнитель плохой и футболит и о том что начальник вместо того чтобы разобраться "кто виноват и что делать" просто ставит ультиматумы первому попавшемуся исполнителю. Я к тому что пример не коррелирует или слабо коррелирует с указание строчки в сопроводительном письме и определении кого то как нестабильного, нестабильность <> неисполнительность. Более того определить будет ли человек футболить или нет на работе невозможно просто читая резюме, да даже на собеседовании это вряд ли получиться определить, только когда он начнет работать это выясниться и то это может проявиться через время когда он успокоиться что не потеряет место или например если выгорит.
Определение что человек нестабильный по одной строчке в резюме это признак профессионализма. Какие еще заболевания можно определить таким образом?
Я говорил о Вашем утверждении из статьи где Вы говорите что не будете менять стек. Не очень понятно причем здесь мое желание? Моя мысль в комментарии выше как бы намекает что если завтра измениться востребованность Вашего стека на рынке то с наибольшей вероятность Вам также придется переобуться на актуальную технологию просто чтобы быть востребованным на рынке.
Просиживание штанов в одном стеке наоборот приводит к "деградации" опыта и в один прекрасный момент этот самый стек может стать не актуальным что уже ударит по востребованности на рынке труда поэтому не все так однозначно.
Ну допустим мы используем голый SQL. Завтра меняется структура и что требуется сделать? Найти по поиску все места где использовались измененные таблицы и поменять заменой или руками и так каждый раз, так удобней работать?