Из личного опыта все упирается в начальный настрой конкретного разработчика, который отвечает за этот аспект проекта. Если руки чешутся, то в абсолютно любом стандарте и технологии можно найти минусы и оправдать написание своего велосипеда. 🤷♂️
А что вы делаете с исследовательскими задачами? Когда задачу без прототипа не оценить, когда надо побегать по отделам и договориться про совместное решение и тому подобное?
Здорово, что продолжает работы в этом направлении! С наступившим (к слову)!
ИТ оно, ведь, разное бывает. Спустя два года мне все также актуально понимать на завершение каких проектов в рамках полугодия можно надеяться. Сейчас, правда, начинаю больше думать про понятное закладывание рисков в сроки. ИМХО в ИТ сроки часто пробалтываются именно из-за неучтенных рисков.
Код в данном случае важен, но успешность стартапа определяют так же маркетинг, свободность ниши, количество денег на поддержку проекта до выхода в плюс и пр. Думаю, из-за этих сложностей все не так просто.
А что из списка кроме DoS специфично именно для API на GraphQL? Любую другую атаку можно повторить на тот же Swagger, другие фреймворки для API и обычный «простой» API.
Думаю, «утверждающие функции» вообще никто не говорит. В целом такие термины не стоит переводить т.к. они напрямую растут из фактического имени функции в коде. Так что «assert-функции» вполне достаточно.
А до этого сколько лет подряд заходили на StackOverflow?
Скажу про себя. Кодю 15 лет. Начал в школе, понемногу на первых курсах и яростно уже на последних и далее. Так вот регулярно открывать стак перестал только лет 5 назад.
Стак даёт офигенную площадку для обучения, поиска ответа на самые заковыристые вопросы. И это замечательно.
Так что нет смысла в высокомерном «ЧЯДНТ» (может и невсокомерно, но выглядит именно так). Просто SO служит отличную службу на первых порах и скорей всего уже будет не особо нужен с 8+ опытом. Это не значит, что не надо читать доку, но неэффективно читать всю доку подряд ото всех технологий, что используются в стеке.
Да, пожалуй, если это, например, команда разработки фреймворка или БД, то инженеры могут нагенерить толковых задач.
На продуктовые команды, получается, LTS не очень ложится? С трудом представляю как инженеры изучают рынки, предлагают фичи с предсказуемым и измеримым результатом, работают с маркетингом для освещения релиза и пр.
Интересно, но без примера непонятно.) Можно пример хотя бы абстрактного проекта на LTS?
Пока все очень туманно и неясно откуда деньги в таких командах, кто ставит задачи, как находятся желающие их решать и самое главное, какой срок жизни у предполагаемого проекта. Пока больше похоже на «рандомно наговнокодили и разбежались») не в обиду всей статье, конечно.
Поэтому по крайней мере в США можно избежать ответственности за раскрытие NDA, если раскрытая инфа проливает свет на недобросовестность компании. См. случай с Facebook Files. Хотя конкретно этот кейс с Фейсбуком, ИМХО, спорный относительно "недобросовестности".
Давно читаю фронтенд подборки, спасибо вам за это)
Есть одно пожелание, и не принимайте его слишком близко. Это мое ИМХО.
Web3 — это сейчас откровенный скам. У него нет определения, нет работающих пользовательских сервисов с понятной моделью монетизации. Зато есть миллион платных курсов, платных сервисов, помогающих сделать свой "web3 app", хватает инфоцыган и, конечно, есть возможность купить пукающую радугу за 100 баксов. И, самое главное в рамках этой подборки, оно никак не связано с фронтендом.
Поэтому просьба не участвовать в распространении скама)
Если ты тимлид команды из 3-4 человек и пилите один продукт, тут вообще не вижу причин и самому код писать (важно только не брать критовые части себе).
А вот когда человек уже 10-15, то, кажется, в большинстве случаев у тебя не будет достаточного погружения во все контексты, чтобы эффективно принимать технические решения.
Сам в такой ситуации не был (не так уж долго был на руководящей позиции), но в рулетке кейсов на podlodka team lead crew это обсуждали и сошлись, что норм в таких случаях искать помощи из-вне, как на уровне компании, так и позвать внешнего консультанта.
Мягко говоря странно, что автор вроде как начинающая разработчица, но в курсе подковерных вопросов сообществ python и golang.
Из личного опыта все упирается в начальный настрой конкретного разработчика, который отвечает за этот аспект проекта. Если руки чешутся, то в абсолютно любом стандарте и технологии можно найти минусы и оправдать написание своего велосипеда. 🤷♂️
Клевая статья, спасибо!
А что вы делаете с исследовательскими задачами? Когда задачу без прототипа не оценить, когда надо побегать по отделам и договориться про совместное решение и тому подобное?
Здорово, что продолжает работы в этом направлении! С наступившим (к слову)!
ИТ оно, ведь, разное бывает. Спустя два года мне все также актуально понимать на завершение каких проектов в рамках полугодия можно надеяться. Сейчас, правда, начинаю больше думать про понятное закладывание рисков в сроки. ИМХО в ИТ сроки часто пробалтываются именно из-за неучтенных рисков.
Код в данном случае важен, но успешность стартапа определяют так же маркетинг, свободность ниши, количество денег на поддержку проекта до выхода в плюс и пр. Думаю, из-за этих сложностей все не так просто.![]()
А что из списка кроме DoS специфично именно для API на GraphQL? Любую другую атаку можно повторить на тот же Swagger, другие фреймворки для API и обычный «простой» API.
Начнём и закончим тем, что все большие новые фичи ue 5 просто адски тормозят, сильна приставках нового поколения, что на мощных ПК. 🤷♂️
Какой в них смысл, если целевая аудитория их все-равно не потянет?
Статья хорошая.
Думаю, «утверждающие функции» вообще никто не говорит. В целом такие термины не стоит переводить т.к. они напрямую растут из фактического имени функции в коде. Так что «assert-функции» вполне достаточно.
А до этого сколько лет подряд заходили на StackOverflow?
Скажу про себя. Кодю 15 лет. Начал в школе, понемногу на первых курсах и яростно уже на последних и далее. Так вот регулярно открывать стак перестал только лет 5 назад.
Стак даёт офигенную площадку для обучения, поиска ответа на самые заковыристые вопросы. И это замечательно.
Так что нет смысла в высокомерном «ЧЯДНТ» (может и невсокомерно, но выглядит именно так). Просто SO служит отличную службу на первых порах и скорей всего уже будет не особо нужен с 8+ опытом. Это не значит, что не надо читать доку, но неэффективно читать всю доку подряд ото всех технологий, что используются в стеке.
О, спасибо! Сразу понятнее.
Да, пожалуй, если это, например, команда разработки фреймворка или БД, то инженеры могут нагенерить толковых задач.
На продуктовые команды, получается, LTS не очень ложится? С трудом представляю как инженеры изучают рынки, предлагают фичи с предсказуемым и измеримым результатом, работают с маркетингом для освещения релиза и пр.
Интересно, но без примера непонятно.) Можно пример хотя бы абстрактного проекта на LTS?
Пока все очень туманно и неясно откуда деньги в таких командах, кто ставит задачи, как находятся желающие их решать и самое главное, какой срок жизни у предполагаемого проекта. Пока больше похоже на «рандомно наговнокодили и разбежались») не в обиду всей статье, конечно.
Ха, вчера читал новость про рекордный пиковый онлайн в CS. Неужели из-за вот этого всего?)
Поэтому по крайней мере в США можно избежать ответственности за раскрытие NDA, если раскрытая инфа проливает свет на недобросовестность компании. См. случай с Facebook Files. Хотя конкретно этот кейс с Фейсбуком, ИМХО, спорный относительно "недобросовестности".
Давно читаю фронтенд подборки, спасибо вам за это)
Есть одно пожелание, и не принимайте его слишком близко. Это мое ИМХО.
Web3 — это сейчас откровенный скам. У него нет определения, нет работающих пользовательских сервисов с понятной моделью монетизации. Зато есть миллион платных курсов, платных сервисов, помогающих сделать свой "web3 app", хватает инфоцыган и, конечно, есть возможность купить пукающую радугу за 100 баксов. И, самое главное в рамках этой подборки, оно никак не связано с фронтендом.
Поэтому просьба не участвовать в распространении скама)
Согласен! Сам играл в вов, но не доиграл с моментом с КЕК и только сегодня узнал правду)
Если под генерацией кода имеется виду scaffolding (сниппеты с темплейтами), то это встроенная фича VS Code, т.ч. п. 3 тоже yes.
По пункту 4 не очень ясно, что хочется. Запуск сборки веб-пака?) Это-то точно есть.
🤝
Думаю, все зависит от числа подчиненных.
Если ты тимлид команды из 3-4 человек и пилите один продукт, тут вообще не вижу причин и самому код писать (важно только не брать критовые части себе).
А вот когда человек уже 10-15, то, кажется, в большинстве случаев у тебя не будет достаточного погружения во все контексты, чтобы эффективно принимать технические решения.
Сам в такой ситуации не был (не так уж долго был на руководящей позиции), но в рулетке кейсов на podlodka team lead crew это обсуждали и сошлись, что норм в таких случаях искать помощи из-вне, как на уровне компании, так и позвать внешнего консультанта.
В статье ж пишет, что экспертизу должны растить подчинённые. Твоя ж задача теперь это искать таланты и помогать им расти.
Техлид, в моем понимании, это как раз эксперт без команды, но с решающим словом с т. з. реализации.