На фоне падения Теслы, смотрю на все остальные проекты Маска все более скептично. Я всегда думал, что главная проблема всех этих внедряемых решений сенсоров - зарастание их соединительной тканью. И это касаетеся всего - от датчиков глюкозы для диабетиков, которым уже лет 20, и вплоть до нейролинка.
Да нет же, подход вполне однозначный: разработчик должен задавать уточняющие вопросы, но только такие, которые его величество собеседующий сочтет стоящими исходя из своего опыта и уровня интеллекта.
Вы описали сейчас человека-кадровое агенство, что достаточно редкий случай. Кадровик в большой компании может реально заниматься ибд, чтобы показать что он нужен. Девочки-однодневочки из мелких кадровых агенств получают процент с тех мифических "n-окладов специалиста", если вообще не на зп. Потому собеседуют все, что общается. Часто с целью набить себе базу резюме и потом уже стать человеком-кадровым агенством. Ну и часто вакансии прилетающие в эти агенства - та еще дрянь, и в агенстве сразу понимают, что под такие требования никого толком не найдут, но отчитаться перед заказчиком/начальником надо, мол �
Тут тащем-то еще смешнее. Обычно любители услышать вопросы хотят услышать конкретные вопросы, которые бы пришли в голову именно им, зачастую на основании не просто их опыта, на опыта на конкретном проекте. Поэтому в угадайку можно играть долго и с позором проиграть, расписавшись в полном отсутствии у тебя телепатических навыков.
Всего-то мировая рецессия, западные айти-гиганты выкинули на мороз тысячи программистов, весь СНГ токсичен или рискован для найма на аутсорс. Что же могло случиться?
Потеря интереса и мотивации: Разработчики обычно живут для новых вызовов и задач. Если вы вдруг перестали волноваться и вдохновляться тем, что вы делаете, это может быть знаком начинающегося выгорания.
Это бред. Во-первых разработчики - люди, которые живут ради своих интересов: семьи, детей, хобби, решения каких-то своих проблем и задач, для которых нужны деньги. Во-вторых на дворе 2023 год и все айти - это повторение типовых решений в рамках конкретных бюджетов и конкретных технологий. Чем тут вдохновляться - хрен знает, если у вас хотя бы 5 лет опыта. Бизнесу не нужны люди признающие свои интересы и адекватно оценивающие уровень задач. Ну это вообще вечная проблема бизнеса и разработчиков: бизнес хочет, чтобы последние были умные, но только в плане профдеятельности, а во всех остальных случаях интеллект должен магическим образом отключаться.
Физические симптомы: Выгорание может проявляться физически, такие как бессонница, головные боли, и даже проблемы с желудком. Ваше тело часто говорит вам о вашем эмоциональном состоянии.
Да, от тяжелой работы организм изнашивается. Как и от возраста. Бизнесу не нужны больные и уставшие.
Снижение производительности: Если вы стали медленнее и менее продуктивными, это может быть признаком выгорания. Вы уже не тот "молниеносный кодер", что были раньше.
Не знаю что можно молниеносно выдавать кроме крудов самого низкого качества. Но при чем тут тогда вдохновляющие задачи? Бизнесу не нужны, те кто медленно выдает продукт.
Изоляция и отчуждение: Вместо того, чтобы общаться с коллегами и делиться идеями, вы начали избегать общества, чувствуя себя одиноко в своем профессиональном мире.
Ну знаете ли... При молниеносном написании кода не до идей, нужно код выдавать, раз-раз-раз! А при описании вдохновения от типовых рутинных задач даже понимающие коллеги могут недобро посмотреть. А делиться идеями, если речь не о какой-то R&D штуке, к которой даже большинство современных стартапов не имеют никакого отношения, не имеет смысла - все уже придумано до вас. Бизнесу не нужны люди, дающие думающие что-то свое, даже если они думают молча.
Цинизм и отношение к работе: Выгорание может сделать вас циничным и негативно настроенным по отношению к вашей работе и коллегам. Вы начинаете видеть только проблемы и недостатки.
Бизнесу не нужны люди, замечающие недостатки.
Короче, на новоязе современного бизнеса и HR, "выгоревший разработчик" - это просто человек трезво смотрящий на ситуацию, не готовый вкалывать сверхурочно, человек со спавшими розовыми очками, или просто не принимающий официальную ложь, используемую для не финансовой мотивации. А "предотвращение выгорания" - увольнение таких из компании. Если раньше были обычные люди и "вовлеченные" и бизнес хотел именно последних, то теперь произошла стигматизация обычных до уровня выгоревших. А вовлеченные стали выдаваться за норму.
Мои критерии удаленки того, что вакансия чревата проблемами или трудоустройство маловероятно:
- вопросы "на сколько баллов из 1488 оцениваете себя по стэку..." . Скорее всего кадровое агентство собирает резюме или неадекваты просто.
- какие-то на редкость специфические вопросы, требования годов опыта для сочетаний фреймворков и библиотек, которые и на миг сочетать не хочется, а тут требуют сразу годы. Или "кэшировали ли вы сессии редисом в кубернетисе на проекте, где у кота бухгалтера был синдром аспергера?".
- попытки незнающего человека поймать вас на нестыковках в чистой логике без знания матчасти. Человек пытается скрыть свое незнание, коммуникации могут быть в дальнейшем такие же - постоянные доказательства того, что вы не верблюд.
- отдельный этап собеседования с ПМ, СЕО и т.д., если компания больше 5 человек. Признак сильно развитой корпоративной шизы или что шиза у конкретного руководителя, или шиза была у последнего соискателя и теперь все боятся повторения.
- собес где присутствуют одновременно HR и технические специалисты. Скорее всего HR - надсмотрщик.
- наличие вопросов ставящих под сомнение очевидные истины: вы очередной сотрудник - они очередная компания, вы готовы хорошо работать и получать за это хорошее вознаграждение, остальное - как получится
- девочки-херки задают вопросы ответы на которые они заведомо не понимают. Вроде рассказать им про свой любимый паттерн проектирования.
- требования интереса к работе на сеньорских должностях с 10+ годами опыта. Если человек обучаемый, то он за это время может прийти к выводу, что общая картина не особо меняется, нужно просто учить новые/модные/узкоспециализированные костыли.
- зарплатная вилка x2. Очевидно, что если можно платить меньше, то никто не будет платить больше. Формальные причины найдутся.
- тестовое задание, которое порождает уточняющие вопросы, ответы на которые порождают еще больше уточняющих вопросов или же вопросов о профпригодности проверяющего
- на собеседовании просят назвать слабые стороны, провалы, почему уволились с предыдущей работы и т.п.
- спрашивают про красные флаги и чего вы не потерпите на рабочем месте, настойчиво не принимая варианты ответа типа "все люди хорошие, с любыми можно найти общий язык", и при том не давая самих примеров красных флагов
- на техническом собеседовании вас собеседует малолетний петух в возрасте до 25 лет. Даже если йуное дарование превосходит вас в плане интеллекта и памяти на основную терминологию, вы все равно не сможете указать ему на границы применимости используемых им терминов, исходя из вашего опыта. И даже если петух по факту вы, то у юного дарования не хватит такта доходчиво вам объяснить в чем вы неправы. Так что, независимо от исхода таких петушиных боев, финал для вас неутешителен.
Да, частота входит в поддиапазон LTE. Но и у древнего иридиума частота тоже 1.6 ГГц, что формально входит в LTE. Но вы же не будете утверждать, что иридиумы - это обычные LTE смартфоны?
Про физику меня смущает тот факт, что у терминала старлинка мощность от 50 до 90 вт и там ФАР дающая направленность. В смартфоне вроде бы до 3 ватт и всенап
Просто в REST со стандартом проблема, его по сути нет. Есть рекомендации и устоявшаяся практика. Чем Вам Method+URL+параметр не нотация?
Потому что "нотация" GraphQL создана из рассчета, что у нас волшебный сервер, который одинаково эффективно возвращает запрошенные данные. И пофиг как там GraphQL ложится на внутреннюю предметную область, аппаратные ограничения, уже реализованные способы доступа к объектам. За исключением простых случаев, ситуация когда фронтендщики диктуют схему доступа к данным, пусть и прекрываясь технологией, черевата проблемами с производительностью и неоптимальной организацией хранения данных. Потому что для фронтендщика не будут видны под капотом ключи MySQL, лимиты на внешние апи, внутренная организация кэширования. И REST, на мой взгляд, куда лучше справляется как с учетом этих особенностей, так и защитой фронтеднщиков от этих ненужных деталей.
К тому же олновесная реализация нотации GraphQL для всех сущностей системы может стоить дорого. А реализация ограниченного подмножества будет по сути не особо отличаться от REST. Только вместо ендпоинтов для сущностей нужно будет создавать ресолверы для новых сущностей.
А вот возможность получить на сервер запрос всех полей и связанных с ними записей думаю сильно плохо скажется на его здоровье. Интересно посмотреть статистику отказа в обслуживании таких endpoint’ов.
Если пытаться на ендпоинте сделать логику выборки из базы как в авторезолверах, строящих запросы по аннотациям в ORM, то все может быть очень печально. А если сделать выборку вручную написанными запросами, созданными специально под конкретный флоу, то все может быть в разы лучше чем у GraphQL.
Большей части людей нужен профессиональный бизнес консультант под лычкой дата-саентиста, чтобы платить можно было как инженеру, а спрашивать как с бизнес-партнера.
А в чем плюс? Только возня с ее описанием. В случае простых рест запросов можно вообще забить на нотации и трафик и слать объекты целиком, с посылом - все что есть в ответе есть и в объекте. В случае сложных запросов десять раз подумаешь, а не проще ли было сделать конкретный ендпоинт для этого запроса, который бы слал конкретные объекты предстваления, не завязанные на схему, а нужные только для представления.
Возможность указания только тех полей, что нужно
В REST это тоже делалось задолго до создания GraphQL. Параметр fields в конце URL.
Можно за один запрос получить данные с разных backend-ов
Обожаю этот аргумент! Вы когда-нибудь писали кастомный резолвер, который вам соберет сложный объект по нескольким микросервисам? Это одинаковая головная боль, что для REST, что для GraphQL. Только в случае последнего вам придется писать резольвер по-настоящему общего назначения, который будет работать для всех полей и связанных объектов, и потом решать проблемы производительности с этим чудом. В случае REST такие вещи хотя бы ограничивают универсальность применения одним ендпоинтом и доступными для него спидхаками и упрощениями выборки.
Можно получать связанные данные (пользователь + его заказы, например)
Да можно, вопрос какой ценой нагрузки на сервер. Вероятно, можно написать хаки для ресольвера, чтобы он какие-то случаи запросов покрывал джойнами, а не выборкой связанных данных отдельными подзапросами. Но чем такие оптимизации принципиально отличаются от создания специализированного рестового ендпоинта?
Запросы к бекендам могут параллелиться без изменения логики в клиенте
Больше скажу, самая кринжовая статья оказалась от автора $mol. Нет, я даже еще больше скажу! Автор статьи, автор видео и автор $mol - это один человек!
Вот с этого замечательного комментария должны начинаться все статьи по портированию линуксов на андройдодевайсы и кнопочники на дешевых SoC. Потому что многие люди даже тут не понимают всю глубину анальной огороженности телефонных SoC. И соответственно всю бесперспективность попыток что-то туда полноценно портировать.
Потому что скорость распрстранения сигнала конечна. Чем меньше процессор, тем меньше проблем с согласованием частоты между его блоками.
Большие процессоры типа М1 - это начало конца. Признание того что мы не можем больше существенно увеличить скорость процессора. Максимум - выделить устоявшиеся алгоритмы для обработки видео, изображений, шифрования в отдельные аппаратные блоки. Да, такие блоки меньше кушают и быстрее работают, но на все случаи жизни аппаратных блоков не напасешься.
На фоне падения Теслы, смотрю на все остальные проекты Маска все более скептично. Я всегда думал, что главная проблема всех этих внедряемых решений сенсоров - зарастание их соединительной тканью. И это касаетеся всего - от датчиков глюкозы для диабетиков, которым уже лет 20, и вплоть до нейролинка.
Да нет же, подход вполне однозначный: разработчик должен задавать уточняющие вопросы, но только такие, которые его величество собеседующий сочтет стоящими исходя из своего опыта и уровня интеллекта.
Вы описали сейчас человека-кадровое агенство, что достаточно редкий случай. Кадровик в большой компании может реально заниматься ибд, чтобы показать что он нужен. Девочки-однодневочки из мелких кадровых агенств получают процент с тех мифических "n-окладов специалиста", если вообще не на зп. Потому собеседуют все, что общается. Часто с целью набить себе базу резюме и потом уже стать человеком-кадровым агенством. Ну и часто вакансии прилетающие в эти агенства - та еще дрянь, и в агенстве сразу понимают, что под такие требования никого толком не найдут, но отчитаться перед заказчиком/начальником надо, мол �
Тут тащем-то еще смешнее. Обычно любители услышать вопросы хотят услышать конкретные вопросы, которые бы пришли в голову именно им, зачастую на основании не просто их опыта, на опыта на конкретном проекте. Поэтому в угадайку можно играть долго и с позором проиграть, расписавшись в полном отсутствии у тебя телепатических навыков.
Всего-то мировая рецессия, западные айти-гиганты выкинули на мороз тысячи программистов, весь СНГ токсичен или рискован для найма на аутсорс. Что же могло случиться?
Это бред. Во-первых разработчики - люди, которые живут ради своих интересов: семьи, детей, хобби, решения каких-то своих проблем и задач, для которых нужны деньги. Во-вторых на дворе 2023 год и все айти - это повторение типовых решений в рамках конкретных бюджетов и конкретных технологий. Чем тут вдохновляться - хрен знает, если у вас хотя бы 5 лет опыта. Бизнесу не нужны люди признающие свои интересы и адекватно оценивающие уровень задач. Ну это вообще вечная проблема бизнеса и разработчиков: бизнес хочет, чтобы последние были умные, но только в плане профдеятельности, а во всех остальных случаях интеллект должен магическим образом отключаться.
Да, от тяжелой работы организм изнашивается. Как и от возраста. Бизнесу не нужны больные и уставшие.
Не знаю что можно молниеносно выдавать кроме крудов самого низкого качества. Но при чем тут тогда вдохновляющие задачи? Бизнесу не нужны, те кто медленно выдает продукт.
Ну знаете ли... При молниеносном написании кода не до идей, нужно код выдавать, раз-раз-раз! А при описании вдохновения от типовых рутинных задач даже понимающие коллеги могут недобро посмотреть. А делиться идеями, если речь не о какой-то R&D штуке, к которой даже большинство современных стартапов не имеют никакого отношения, не имеет смысла - все уже придумано до вас. Бизнесу не нужны люди, дающие думающие что-то свое, даже если они думают молча.
Бизнесу не нужны люди, замечающие недостатки.
Короче, на новоязе современного бизнеса и HR, "выгоревший разработчик" - это просто человек трезво смотрящий на ситуацию, не готовый вкалывать сверхурочно, человек со спавшими розовыми очками, или просто не принимающий официальную ложь, используемую для не финансовой мотивации. А "предотвращение выгорания" - увольнение таких из компании. Если раньше были обычные люди и "вовлеченные" и бизнес хотел именно последних, то теперь произошла стигматизация обычных до уровня выгоревших. А вовлеченные стали выдаваться за норму.
Мои критерии удаленки того, что вакансия чревата проблемами или трудоустройство маловероятно:
- вопросы "на сколько баллов из 1488 оцениваете себя по стэку..." . Скорее всего кадровое агентство собирает резюме или неадекваты просто.
- какие-то на редкость специфические вопросы, требования годов опыта для сочетаний фреймворков и библиотек, которые и на миг сочетать не хочется, а тут требуют сразу годы. Или "кэшировали ли вы сессии редисом в кубернетисе на проекте, где у кота бухгалтера был синдром аспергера?".
- попытки незнающего человека поймать вас на нестыковках в чистой логике без знания матчасти. Человек пытается скрыть свое незнание, коммуникации могут быть в дальнейшем такие же - постоянные доказательства того, что вы не верблюд.
- отдельный этап собеседования с ПМ, СЕО и т.д., если компания больше 5 человек. Признак сильно развитой корпоративной шизы или что шиза у конкретного руководителя, или шиза была у последнего соискателя и теперь все боятся повторения.
- собес где присутствуют одновременно HR и технические специалисты. Скорее всего HR - надсмотрщик.
- наличие вопросов ставящих под сомнение очевидные истины: вы очередной сотрудник - они очередная компания, вы готовы хорошо работать и получать за это хорошее вознаграждение, остальное - как получится
- девочки-херки задают вопросы ответы на которые они заведомо не понимают. Вроде рассказать им про свой любимый паттерн проектирования.
- требования интереса к работе на сеньорских должностях с 10+ годами опыта. Если человек обучаемый, то он за это время может прийти к выводу, что общая картина не особо меняется, нужно просто учить новые/модные/узкоспециализированные костыли.
- зарплатная вилка x2. Очевидно, что если можно платить меньше, то никто не будет платить больше. Формальные причины найдутся.
- тестовое задание, которое порождает уточняющие вопросы, ответы на которые порождают еще больше уточняющих вопросов или же вопросов о профпригодности проверяющего
- на собеседовании просят назвать слабые стороны, провалы, почему уволились с предыдущей работы и т.п.
- спрашивают про красные флаги и чего вы не потерпите на рабочем месте, настойчиво не принимая варианты ответа типа "все люди хорошие, с любыми можно найти общий язык", и при том не давая самих примеров красных флагов
- на техническом собеседовании вас собеседует малолетний петух в возрасте до 25 лет. Даже если йуное дарование превосходит вас в плане интеллекта и памяти на основную терминологию, вы все равно не сможете указать ему на границы применимости используемых им терминов, исходя из вашего опыта. И даже если петух по факту вы, то у юного дарования не хватит такта доходчиво вам объяснить в чем вы неправы. Так что, независимо от исхода таких петушиных боев, финал для вас неутешителен.
Вы немного лукавите, там не LTE.
https://www.reuters.com/technology/new-iphones-have-qualcomm-satellite-modem-new-apple-radio-chips-2022-09-17/
Да, частота входит в поддиапазон LTE. Но и у древнего иридиума частота тоже 1.6 ГГц, что формально входит в LTE. Но вы же не будете утверждать, что иридиумы - это обычные LTE смартфоны?
Про физику меня смущает тот факт, что у терминала старлинка мощность от 50 до 90 вт и там ФАР дающая направленность. В смартфоне вроде бы до 3 ватт и всенап
А смысл там сидеть, если физика покинула чат?
Потому что "нотация" GraphQL создана из рассчета, что у нас волшебный сервер, который одинаково эффективно возвращает запрошенные данные. И пофиг как там GraphQL ложится на внутреннюю предметную область, аппаратные ограничения, уже реализованные способы доступа к объектам. За исключением простых случаев, ситуация когда фронтендщики диктуют схему доступа к данным, пусть и прекрываясь технологией, черевата проблемами с производительностью и неоптимальной организацией хранения данных. Потому что для фронтендщика не будут видны под капотом ключи MySQL, лимиты на внешние апи, внутренная организация кэширования. И REST, на мой взгляд, куда лучше справляется как с учетом этих особенностей, так и защитой фронтеднщиков от этих ненужных деталей.
К тому же олновесная реализация нотации GraphQL для всех сущностей системы может стоить дорого. А реализация ограниченного подмножества будет по сути не особо отличаться от REST. Только вместо ендпоинтов для сущностей нужно будет создавать ресолверы для новых сущностей.
Если пытаться на ендпоинте сделать логику выборки из базы как в авторезолверах, строящих запросы по аннотациям в ORM, то все может быть очень печально. А если сделать выборку вручную написанными запросами, созданными специально под конкретный флоу, то все может быть в разы лучше чем у GraphQL.
Большей части людей нужен профессиональный бизнес консультант под лычкой дата-саентиста, чтобы платить можно было как инженеру, а спрашивать как с бизнес-партнера.
А в чем плюс? Только возня с ее описанием. В случае простых рест запросов можно вообще забить на нотации и трафик и слать объекты целиком, с посылом - все что есть в ответе есть и в объекте. В случае сложных запросов десять раз подумаешь, а не проще ли было сделать конкретный ендпоинт для этого запроса, который бы слал конкретные объекты предстваления, не завязанные на схему, а нужные только для представления.
В REST это тоже делалось задолго до создания GraphQL. Параметр fields в конце URL.
Обожаю этот аргумент! Вы когда-нибудь писали кастомный резолвер, который вам соберет сложный объект по нескольким микросервисам? Это одинаковая головная боль, что для REST, что для GraphQL. Только в случае последнего вам придется писать резольвер по-настоящему общего назначения, который будет работать для всех полей и связанных объектов, и потом решать проблемы производительности с этим чудом. В случае REST такие вещи хотя бы ограничивают универсальность применения одним ендпоинтом и доступными для него спидхаками и упрощениями выборки.
Да можно, вопрос какой ценой нагрузки на сервер. Вероятно, можно написать хаки для ресольвера, чтобы он какие-то случаи запросов покрывал джойнами, а не выборкой связанных данных отдельными подзапросами. Но чем такие оптимизации принципиально отличаются от создания специализированного рестового ендпоинта?
Чтобы что?
Больше скажу, самая кринжовая статья оказалась от автора $mol. Нет, я даже еще больше скажу! Автор статьи, автор видео и автор $mol - это один человек!
Вот с этого замечательного комментария должны начинаться все статьи по портированию линуксов на андройдодевайсы и кнопочники на дешевых SoC. Потому что многие люди даже тут не понимают всю глубину анальной огороженности телефонных SoC. И соответственно всю бесперспективность попыток что-то туда полноценно портировать.
Выглядит как будто статью писал ИИ.
Промтов, скриншотов диалога с ИИ нет
Зачем перегонять код из JS в PHP - непонятно, особенно учитывая что у вас в гитхабе лежат несколько проектов на Vue.js
исходного кода на JS, который был перегнан в PHP тоже нет, чтобы оценить качество трансляции.
"Токен законопослушного платежеспособного человека с низкой компьютерной грамотностью из неподсанкционного региона" (с)
Б Э К А П Ы
Э
К
А
П
Ч
И
К
И
Швитые люди живущие в швитых домиках, одним словом.
Вся статья в одной картинке
Потому что скорость распрстранения сигнала конечна. Чем меньше процессор, тем меньше проблем с согласованием частоты между его блоками.
Большие процессоры типа М1 - это начало конца. Признание того что мы не можем больше существенно увеличить скорость процессора. Максимум - выделить устоявшиеся алгоритмы для обработки видео, изображений, шифрования в отдельные аппаратные блоки. Да, такие блоки меньше кушают и быстрее работают, но на все случаи жизни аппаратных блоков не напасешься.