На самом деле куки это наглядный пример как чисто инженерное решение для упрощения жизни разработчиков испоганили продаваны. И с текущей ситуацией от них действительно стоит отказаться. Есть поддерживаемые аналоги для хранения клиентских данных локально, у которых нет такой явной проблемы стороннего доступа.
Хотя сама идея была очень хороша и позволяла без лишних плясок связывать разные домены, особенно в эпоху iframe.
Что я вынес из этой статьи - если хочешь развивать пет-проект на общественных началах, то делай это анонимно и разворачивая в тех странах, где на законы плевали. Если захотят закопать, то закопают, даже просто "ради фана"
я писал на Go, учитывая что в итоге сама блокировка вышла одноточечной - переписать эту часть на асемблер под определенные ядра не проблема))
Но в целом 4нс на генерацию при асинхронном вызове для 1000 потоков и так неплохо.
Вообще разработчики недооценивают потребление таких мелких и рутинных операций, особенно если их инициализация не очевидна. И как избыток проверок способен в подобной "простой" функции умножать потребление ресурсов.
Привязка ко времени верна, а к "случайному числу" нет.
Даже если у вас изредка бывают максимум две записи в секунду - рандом может сложится. Вы то вложились "в размер" потому колизии маловеоятны (но все еще вероятны)
Обычно такие веши строят так - уникальный указатель сегмента (сервер, кластер, просто соль) отрезок времени с нужной точностью (дни, минуты, секунды, наносекунды) и инкрементное значение. Асинхронный доступ с блокировками для значения инкремента реализовать не сложно.
Из моей практики в строку из 6 символов (a-z0-9) впихнули возможность хранения трилионного диазона, или до 9999 уникальных записей в секунду в рамках кластера (максимальное количество кластеров 1200) с привязкой ко времени.
Давно уже в голове бродит мысль собрать эдакий коммуникатор, только с более экономным по потреблению центральным чипом, на ардуине. Вот только даже если плату отрисую - времени на прошивку будет не так много, а сделать железку только ради того что бы сделать такое себе
И вот мы дожили до того момента, когда ИБ большой фирмы будет контролировать и устанавливаемые плагины к IDE.
А вообще логично - если что то можно скомпроментировать, это скомпроментируют.
JetBrains очень круты и идея с плагинами себя окупила давно, но сама политика перекидывания все на плагины творит беду. Особенно это видно в последних версиях - стали пихать костыли, что бы хоть как-то ограничить.
Не так давно пришлось откатывать версию GoLand после обновления потому как отвалилось все-все на python (а он использовался много где, и для тестов и для билдинга). Причем это не системный косяк какой-то, сама IDE просто отказывалась принимать что либо связаное с python. Зачем делать универсальную удобную IDE под любую платформу (с фокусировкой но все же) что бы потом забирать эту самую универсальность?
В целом JetBrains куда-то не туда начинает постепенно скатыватся, все больше багов, все меньше именно развития IDE. Тот же их "новый дизайн" слизаный с "лучших практик" vsc и тому подобной херни, благо не так много продуктов где нельзя включить старый дизайн.
В начале весны обновлял комп и заодно проклацал их все новые продукты - ладно нишевые (впрочем все это уже у них было просто собрали под другой иконкой), но "блокнот" который они выкатили это что то с чем то. Ожидал мини-IDE от JetBrains а увидел в итоге внебрачного сына Obsidian и vsc, сына который вобрал худшее у родителей. По функционалу и юзабилити старый Kate на линуксе справлялся не хуже. Прям экономным я его бы не назвал. Ну и дизайн - казалось бы хуже уже нельзя, но они смогли.
Интеграцию с гитхабом пришлось по форумам искать - оказывается она сама вылезет строго в определенный момент и ты не можешь сразу при входе зайти в настройки и прописать ключ.
Настройки в целом - они бы еше просто yml текстом открывали, что бы "внести изменения"
Редактор - его нет. Никаких фишек IDE я не заметил, зато заметил что литнер слишком много хочет и если у си-файла нужно правильно подключить либу что бы ее нашло, то редактор даже не соизволит пытатся опознать код (тот же Kate и переменные подскажет и скобки найдет/свернет и тому подобное)
Дизайн - иногда мне кажется что в JetBrains завели отдел для толерантности. Как портят игры, так у них занимаются "продвижением" "полезных интерфейсов". И самое главное даже нельзя ничего переключить или поменять.
.
Я с JetBrains еще со времен когда было только два ide (их родной и шторм), всегда с удовольсвием продлевал глобальную лицензию так как они заработали каждую копейку этой суммы. Но смотря на динамику развития начинаю понемногу смотреть шире на мир в поисках аналогов. Понятное дело что сразу "мгновенно" не перескочить, но если скорость "улучщений" сохранится, то за новую среду разработки для разных языков нужно будет думать уже через 2-3 года.
Я себе на всякий пожарный сохранил на домашний сервер последние "стабильные" для меня версии всех IDE (тот же goLand уже не последний, "спасибо" за улучшения), хотя поможет ли это вопрос хороший - лицензия то смотрится с сервера, то есть разве что в режиме офлайна с кряком их юзать.
Но это все максимально бесполезно если разраб хлеб, который не знает про атомарность, не расписывает коммит и вообще пользуется гитом больше как трекером задач совмешенный с инструментом заливки изменений.
Сама идея WIP хорошая, но она для структурированного и коментируемого кода. Если у вас пишут "как бог пошлет" то лучше оставлять все 1005000 коммитов процесса, просто саму работу производить ветками и потом сливать. Нужно весь отрезок - смотри ПР, нужно понять по какой причине поменяли четко это место - смотришь коммит этой точки.
Кстати, единое форматирование коммитов и хуки для упрощения этого самого - вот что дейсвительно важно при работе с git в боевом долгосрочном проекте. А так же просто политика написания развернутого коммита, а не отписки с "fix" и тд.
У нас слишком децентрализованое решение, потому "всю базу положить" можно только если получить доступ ко всем нодам на уровне сегмента (страны). И все равно выйдут из спячки пасивки, которые только на чтение.
Данные разнесены по всем нодам, но индексы и первичка для поиска дублируются на каждую ноду в рамках сегмента (занимает до пары десятков гигов, но выйгрыш в стабильности и ускорении поиска в единой базе)
В теории если скомпроментировать "чистовые зеркала" а потом положить сеть, что бы пошло востановление с зеркала то можно сотворить беду. Потому собсвенно включение востановления и прочие критичные по функционалу дейсвия только с ручника. Это классика стульев, если безопасно то не совсем удобно, а если удобно то не совсем безопасно.
Мне вот другое интересно - неужели СДЭК настолько маленький стартап, что точка входа покрывает всю инфраструктуру?
Лично у меня в практике на проекте нагрузки на порядок меньше, но взлом отдельной ноды или даже глобальной админки не сильно повлияет на всю распределенную архитектуру.
Мне как создателю такой системы нужно пару дней что бы правильно все настроить для такого тотального шифрования. И это при условии что есть все доступы и я знаю всю систему в целом потому нет проблем с рассылкой и обходов фаерволов.
И то с бекапов все запустится в течении часа максимум. А даже если я повлияю на часовые бекапы и смогу как то внедрить скрипт на суточные бекапы, то все равно есть "холодные ноды" которые при потери связи со всей инфраструктурой автоматом запускаются и к ним уже можно "долить" самые актуальные бекапы (отдельная система только на чтение, сегмент бекапов в которые можно только дописывать, но не перезаписывать, система разворачивается так же только на чтение и спользуется для зеркалирования на боевой кластер который уже будет чтение-запись)
Сначала читал внимательно, но чем дальше тем сильнее "по диагонали".
Уже с начала идут взаимоисключающие параграфы, а дальше их только больше.
.
Резюмируя - у каждого рекрутера своя шиза и свое виденье. Ниже я по пунктам расписал, опираясь на то что "вычитал" тут.
На старте нужно максимально "приврать", но так что бы это было скорее преувеличением. Такой обман нужен для вхождения в воронку (10 просмотренных кандидатов из 300 откликов Карл!)
Стек лучше всего подгонять под вакансию. В "мастера на все руки" никто не поверит, а писать честно - не факт, что попадете в воронку.
Места работы - все что было писать стоит раздувая, например если джун, то младший разработчик такого-то стека и отдела. Если нет, то можно придумать, главное в юридических субъектах не поплыть, не стоит писать Гугл, Амазон и тд, зато можно с реестра надергать недавно закрытых ООО без контактов.
Опыт - отталкиваться от того что написали до этого.
Далее, когда первый созвон с рекрутером, нужно все подтверждать по тому что "преувеличил" и внимательно слушать что говорят тебе - это понадобится дальше.
Следущий этап - подгонка под вакансию. Делаем все что сказали рекрутеру или на что он обратил внимание.
•Если сказали что "наш тимлид посмотрит и там договоримся о техническом" то наводняем свой гитхаб "тематическими" проектами (идеально иметь несколько гитхабов под определенные требования, в резюме указать с ошибкой, а уже при вхождении в воронку "поправить" на нужную ссылку)
Если сказали что "мы проверим отклики с прошлых мест работы" то даем список номеров SIP-телефонии купленной на месяц ради такого (они до 1$ стоят) и через подстановку голоса рассказываем каким вы были хорошим подчиненным.
Если дали "подготовку под тестовое" то читаем все по этой теме, забиваем промты четко по этим темам в chatGPT (лучше платный), обустраиваем место созвона для возможности "списывать" и ставим на комп софт который подменяет изображение с видеокамеры (если комп позволяет то полная подмена лица на себя самого, лицо будет озвучивать то что вы говорите. Если комп слабый, то минимальный скрипт который перерисовывает глаза на фокусировку по центру. Для бедных можно использовать очки (можно прозрачные) и источник света за камерой, что бы блик закрывал зрачки)
Знаю случай когда кандидат нагуглил "текущих работников" и за звонкую монету договорился что бы его "рекомендовали" тем самым перейдя от созвона с рекрутером до заключения договора.
Если ожидается созвон с бизнесом (владелец, менеджеры и тд) то упор больше на, то что вы можете им дать и каких проблем можете не создавать.
Наступает этап второго созвона. Вкидываем все ресурсы предподготовки на эту проблему. Самое важное быть уверенным в себе и в своих ответах. Если теряешься, то "честно говорить" о волнении и смотреть в шпаргалки.
Аккуратнее с лайфкодингом, копипаст кусками будет заметен. Имеет смысл нейронку запускать на другом устройстве, а потом с него перепечатывать.
Так же стоит быть аккуратным при ответах на вопросы, на которые "вы ответили" по другим каналам. Это нормально когда "ваш начальник" рассказал про вас и то чем вы занимались одно, а вы немного другое (иная точка зрения). Более подозрительно когда оба слово в слово повторяют.
Если же впереди еще этапы, то рекурсивно проходимся по пунктам ранее.
Поздравляю, вы наняты!
.
У кого-то возникнет вопрос "А зачем врать? Мои лапищи и так закрывают небо!" скажу так: стандартизации для ширины лап нет, потому каждый рекрутер думает во что горазд (некоторые вообще на рыбках специализируются и с лапами впервые столкнутся). С другой стороны 90% резюме других кандидатов состоит их "преувеличений" потому что бы на их фоне выгодно выделятся, нужно "преувеличивать". А все этапы и первый месяц работы уже покажет кто вы есть "на самом деле"
Судя по описанию это знакомая политика "втихаря" перевести клиента с месячного на почасовой тариф.
Сталкивался с таким не раз - есть два варианта: - Новому клиенту дают "скрытую скидку" на неделю\месяц\квартал про которую говорится где-то в глубинах пользовательского соглашения. Через означенный срок тарификация становится без скидки и зачастую позволяет влезть в дикие минусы. - На этапе "заказа" услуги все ок, но опять-таки в пользовательском соглашении прописано, что тариф могут поменять по велению левой пятки. Дожидаются пока клиент не "подсядет" и переключают на "более удобный" тариф.
Все это делается для того что бы выманить как можно больше денег. У нормального сервиса есть куча оповещений и перед любым действием над твоим аккаунтом тебя проинформируют на всех доступных уровнях. Политика "учителя Сплинтера" применяется обычно или в очень мелких компаниях (зато дешево) или наоборот в очень крупных (применимо в основном только к СНГ-сектору, хотя встречаются редкие исключения)
Резюмируя - не хочешь с таким столкнутся, не экономь на критически важном и читай отзывы (хорошее пишут редко, зато плохое выливают тут же в форумы и отзовики)
Ну и бекапы, для реально важного сервиса (пусть и пет-проекта) можно было написать простой sh-скрипт который по крону на домашнем ПК "синхронизировал" бы базу. (исходных код в гите или иных)
Вы вот говорите за помехи и тд - а если в случае машины использовать тот самый "дешевый универсальный" но воткнуть частотный фильтр и усилитель?
Как я понял из вашего рассказа - единсвенное различие между дешевыми и дорогими рациями (пофиг аналог или цифра) это та самая стойкость к помехам. А стойкость важна.
В целом я думал для машины брать Anytone AT-D578UV PRO но почитав разное вчера/сегодня понял что нужно в первую очередь смотреть на то, есть ли на рацию открытые прошивки какие-то. На втором месте качество сигнала. И тут начинаются частности, так как качество (и силу) сигнала можно "догнать" разными модулями.
Последний вопрос - что лучше выбрать, цифру или аналог? В интернете это срач уровня какой язык программирования самый важный. Как "первую рацию" взял аналоговые (дешевле и проше) но за год пользования начинаю смотреть в сторону цифры. Во-первых, никого лишнего на канале, во вторых можно СМС, а не голосом. Пугает что из за помех цифра может "лечь". Что вы по этому поводу скажете? Из практики и тд. Интересует именно как способ связи в случае ЧП, особенно если нужно держать связь между машинами на трассе.
Не понял за удаленное управление - это передача цифры или таки голосом?
Но вообще у меня вопрос более комплексный - какую рацию выбрать и как над ней пошаманить для сугубо "евакуационных" нужд. Что бы на случай ЧП была связь как мин у меня с женой, плюс в машине стационарное на большую мощность.
В интернете много противоречивого, в том числе по поводу выбора циры или аналога. На сейчас взял пару баофенгов, но они как то такое себе как по мне. Одну рацию вообще перепаивать пришлось, там регулятор звука уже убитым был.
Все кто хоть раз пытался собрать хотя бы фрагмент памяти на логических елементах знает что заголовок статьи дичь.
Для того что бы просто работали большие схемы есть специальные моды и "опорные блоки" благодаря которым их работа поддерживается даже если они не в зоне видимости.
Но это ладно - нейронную сеть на редстоуне там точно никто не создавал. Максимум простое распознание по вбитым шаблонам, хотя я не отрицаю варинта что редстоун используется просто как "интерфейс" для передачи данных на какую то внешнюю сишную библиотеку распознания
Статья хорошая, но оставила послевкусие: "как прочитать лекцию о том, про что я ничего не знаю и не подать вида".
Как стенография или водяные знаки вообще относятся к криптографии? Это можно использовать в криптографии, для хранения контрольных сумм разного толка и прочих данных необходимых для подтверждения целостности, но назвать это "скрытой криптографией"....
Алгоритмы шифрования - ожидалось какого-то базового обзора обо всем и не о чем, с затрагиванием конкретных случаев и пояснением для чего они лучше. А на деле просто сказали "есть симметричное, есть ассиметричное, вот какие у него особенности". Ладно если это "обзорная" статья, но зачем тогда приводить пример с таблицами, отображающими время в микросекундах для шифрования и расшифрования (только симметричных алгоритмов)? Почему не привели такой же пример для асимметричных? Почему вообще в таблице DES, но нет AES? И это я не затрагиваю такие тонкие материи как стойкость, размер пакетов (для некоторых алгоритмов это критично и может затрагивать поставленную цель) или, боже упаси, быстрые проверки целостности без необходимости дешифровать весь пакет или комплексные подходы шифрованию для разных уровней данных.
В целом тема очень интересная и имеющая множество подводных. И даже на базовом уровне, затрагивая верха, что бы привлечь к своему курсу можно написать много разного. Но текущая подача наоборот отталкивает - если такое пишут в "обзорной статье", то что же тогда там "рассказывают" в специально подготовленном курсе?
Мда. Рекрутеры и так работают на отьебись, но как оказалось этого мало - давайте еще сильнее сузим входную воронку!
А потом "плач ярославны" о том что не могут никого найти на позицию...
Что бы была публикация на хабре вестимо!
Это как с научными работами - важен не результат, а процесс.
Какая великая беда, отказ от куков!
На самом деле куки это наглядный пример как чисто инженерное решение для упрощения жизни разработчиков испоганили продаваны. И с текущей ситуацией от них действительно стоит отказаться. Есть поддерживаемые аналоги для хранения клиентских данных локально, у которых нет такой явной проблемы стороннего доступа.
Хотя сама идея была очень хороша и позволяла без лишних плясок связывать разные домены, особенно в эпоху iframe.
Что я вынес из этой статьи - если хочешь развивать пет-проект на общественных началах, то делай это анонимно и разворачивая в тех странах, где на законы плевали. Если захотят закопать, то закопают, даже просто "ради фана"
я писал на Go, учитывая что в итоге сама блокировка вышла одноточечной - переписать эту часть на асемблер под определенные ядра не проблема))
Но в целом 4нс на генерацию при асинхронном вызове для 1000 потоков и так неплохо.
Вообще разработчики недооценивают потребление таких мелких и рутинных операций, особенно если их инициализация не очевидна. И как избыток проверок способен в подобной "простой" функции умножать потребление ресурсов.
Привязка ко времени верна, а к "случайному числу" нет.
Даже если у вас изредка бывают максимум две записи в секунду - рандом может сложится. Вы то вложились "в размер" потому колизии маловеоятны (но все еще вероятны)
Обычно такие веши строят так - уникальный указатель сегмента (сервер, кластер, просто соль) отрезок времени с нужной точностью (дни, минуты, секунды, наносекунды) и инкрементное значение. Асинхронный доступ с блокировками для значения инкремента реализовать не сложно.
Из моей практики в строку из 6 символов (a-z0-9) впихнули возможность хранения трилионного диазона, или до 9999 уникальных записей в секунду в рамках кластера (максимальное количество кластеров 1200) с привязкой ко времени.
такое себе.
По сути сейчас любая ардуина справится с подобным. Для "судного дня" нужно что-то по типу флипзеро, но с большим экраном и клавиатурой.
Например, вот такая платформа идеально подойдет: https://pl.aliexpress.com/item/1005005692235592.html
Причем на борту есть и LoRa потому можно использовать как универсальный комуникатор судного дня.
Потребление правда..
Давно уже в голове бродит мысль собрать эдакий коммуникатор, только с более экономным по потреблению центральным чипом, на ардуине. Вот только даже если плату отрисую - времени на прошивку будет не так много, а сделать железку только ради того что бы сделать такое себе
И вот мы дожили до того момента, когда ИБ большой фирмы будет контролировать и устанавливаемые плагины к IDE.
А вообще логично - если что то можно скомпроментировать, это скомпроментируют.
JetBrains очень круты и идея с плагинами себя окупила давно, но сама политика перекидывания все на плагины творит беду. Особенно это видно в последних версиях - стали пихать костыли, что бы хоть как-то ограничить.
Не так давно пришлось откатывать версию GoLand после обновления потому как отвалилось все-все на python (а он использовался много где, и для тестов и для билдинга). Причем это не системный косяк какой-то, сама IDE просто отказывалась принимать что либо связаное с python. Зачем делать универсальную удобную IDE под любую платформу (с фокусировкой но все же) что бы потом забирать эту самую универсальность?
В целом JetBrains куда-то не туда начинает постепенно скатыватся, все больше багов, все меньше именно развития IDE. Тот же их "новый дизайн" слизаный с "лучших практик" vsc и тому подобной херни, благо не так много продуктов где нельзя включить старый дизайн.
В начале весны обновлял комп и заодно проклацал их все новые продукты - ладно нишевые (впрочем все это уже у них было просто собрали под другой иконкой), но "блокнот" который они выкатили это что то с чем то. Ожидал мини-IDE от JetBrains а увидел в итоге внебрачного сына Obsidian и vsc, сына который вобрал худшее у родителей. По функционалу и юзабилити старый Kate на линуксе справлялся не хуже. Прям экономным я его бы не назвал. Ну и дизайн - казалось бы хуже уже нельзя, но они смогли.
Интеграцию с гитхабом пришлось по форумам искать - оказывается она сама вылезет строго в определенный момент и ты не можешь сразу при входе зайти в настройки и прописать ключ.
Настройки в целом - они бы еше просто yml текстом открывали, что бы "внести изменения"
Редактор - его нет. Никаких фишек IDE я не заметил, зато заметил что литнер слишком много хочет и если у си-файла нужно правильно подключить либу что бы ее нашло, то редактор даже не соизволит пытатся опознать код (тот же Kate и переменные подскажет и скобки найдет/свернет и тому подобное)
Дизайн - иногда мне кажется что в JetBrains завели отдел для толерантности. Как портят игры, так у них занимаются "продвижением" "полезных интерфейсов". И самое главное даже нельзя ничего переключить или поменять.
.
Я с JetBrains еще со времен когда было только два ide (их родной и шторм), всегда с удовольсвием продлевал глобальную лицензию так как они заработали каждую копейку этой суммы. Но смотря на динамику развития начинаю понемногу смотреть шире на мир в поисках аналогов. Понятное дело что сразу "мгновенно" не перескочить, но если скорость "улучщений" сохранится, то за новую среду разработки для разных языков нужно будет думать уже через 2-3 года.
Я себе на всякий пожарный сохранил на домашний сервер последние "стабильные" для меня версии всех IDE (тот же goLand уже не последний, "спасибо" за улучшения), хотя поможет ли это вопрос хороший - лицензия то смотрится с сервера, то есть разве что в режиме офлайна с кряком их юзать.
Реально - делай хорошо, плохо не делай. И все.
Но это все максимально бесполезно если разраб хлеб, который не знает про атомарность, не расписывает коммит и вообще пользуется гитом больше как трекером задач совмешенный с инструментом заливки изменений.
Сама идея WIP хорошая, но она для структурированного и коментируемого кода. Если у вас пишут "как бог пошлет" то лучше оставлять все 1005000 коммитов процесса, просто саму работу производить ветками и потом сливать. Нужно весь отрезок - смотри ПР, нужно понять по какой причине поменяли четко это место - смотришь коммит этой точки.
Кстати, единое форматирование коммитов и хуки для упрощения этого самого - вот что дейсвительно важно при работе с git в боевом долгосрочном проекте. А так же просто политика написания развернутого коммита, а не отписки с "fix" и тд.
У нас слишком децентрализованое решение, потому "всю базу положить" можно только если получить доступ ко всем нодам на уровне сегмента (страны). И все равно выйдут из спячки пасивки, которые только на чтение.
Данные разнесены по всем нодам, но индексы и первичка для поиска дублируются на каждую ноду в рамках сегмента (занимает до пары десятков гигов, но выйгрыш в стабильности и ускорении поиска в единой базе)
В теории если скомпроментировать "чистовые зеркала" а потом положить сеть, что бы пошло востановление с зеркала то можно сотворить беду. Потому собсвенно включение востановления и прочие критичные по функционалу дейсвия только с ручника. Это классика стульев, если безопасно то не совсем удобно, а если удобно то не совсем безопасно.
То есть идет борьба за монополию, я правильно понимаю?)
Мне вот другое интересно - неужели СДЭК настолько маленький стартап, что точка входа покрывает всю инфраструктуру?
Лично у меня в практике на проекте нагрузки на порядок меньше, но взлом отдельной ноды или даже глобальной админки не сильно повлияет на всю распределенную архитектуру.
Мне как создателю такой системы нужно пару дней что бы правильно все настроить для такого тотального шифрования. И это при условии что есть все доступы и я знаю всю систему в целом потому нет проблем с рассылкой и обходов фаерволов.
И то с бекапов все запустится в течении часа максимум. А даже если я повлияю на часовые бекапы и смогу как то внедрить скрипт на суточные бекапы, то все равно есть "холодные ноды" которые при потери связи со всей инфраструктурой автоматом запускаются и к ним уже можно "долить" самые актуальные бекапы (отдельная система только на чтение, сегмент бекапов в которые можно только дописывать, но не перезаписывать, система разворачивается так же только на чтение и спользуется для зеркалирования на боевой кластер который уже будет чтение-запись)
Сначала читал внимательно, но чем дальше тем сильнее "по диагонали".
Уже с начала идут взаимоисключающие параграфы, а дальше их только больше.
.
Резюмируя - у каждого рекрутера своя шиза и свое виденье. Ниже я по пунктам расписал, опираясь на то что "вычитал" тут.
На старте нужно максимально "приврать", но так что бы это было скорее преувеличением. Такой обман нужен для вхождения в воронку (10 просмотренных кандидатов из 300 откликов Карл!)
Стек лучше всего подгонять под вакансию. В "мастера на все руки" никто не поверит, а писать честно - не факт, что попадете в воронку.
Места работы - все что было писать стоит раздувая, например если джун, то младший разработчик такого-то стека и отдела. Если нет, то можно придумать, главное в юридических субъектах не поплыть, не стоит писать Гугл, Амазон и тд, зато можно с реестра надергать недавно закрытых ООО без контактов.
Опыт - отталкиваться от того что написали до этого.
Далее, когда первый созвон с рекрутером, нужно все подтверждать по тому что "преувеличил" и внимательно слушать что говорят тебе - это понадобится дальше.
Следущий этап - подгонка под вакансию. Делаем все что сказали рекрутеру или на что он обратил внимание.
•Если сказали что "наш тимлид посмотрит и там договоримся о техническом" то наводняем свой гитхаб "тематическими" проектами (идеально иметь несколько гитхабов под определенные требования, в резюме указать с ошибкой, а уже при вхождении в воронку "поправить" на нужную ссылку)
Если сказали что "мы проверим отклики с прошлых мест работы" то даем список номеров SIP-телефонии купленной на месяц ради такого (они до 1$ стоят) и через подстановку голоса рассказываем каким вы были хорошим подчиненным.
Если дали "подготовку под тестовое" то читаем все по этой теме, забиваем промты четко по этим темам в chatGPT (лучше платный), обустраиваем место созвона для возможности "списывать" и ставим на комп софт который подменяет изображение с видеокамеры (если комп позволяет то полная подмена лица на себя самого, лицо будет озвучивать то что вы говорите. Если комп слабый, то минимальный скрипт который перерисовывает глаза на фокусировку по центру. Для бедных можно использовать очки (можно прозрачные) и источник света за камерой, что бы блик закрывал зрачки)
Знаю случай когда кандидат нагуглил "текущих работников" и за звонкую монету договорился что бы его "рекомендовали" тем самым перейдя от созвона с рекрутером до заключения договора.
Если ожидается созвон с бизнесом (владелец, менеджеры и тд) то упор больше на, то что вы можете им дать и каких проблем можете не создавать.
Наступает этап второго созвона. Вкидываем все ресурсы предподготовки на эту проблему. Самое важное быть уверенным в себе и в своих ответах. Если теряешься, то "честно говорить" о волнении и смотреть в шпаргалки.
Аккуратнее с лайфкодингом, копипаст кусками будет заметен. Имеет смысл нейронку запускать на другом устройстве, а потом с него перепечатывать.
Так же стоит быть аккуратным при ответах на вопросы, на которые "вы ответили" по другим каналам. Это нормально когда "ваш начальник" рассказал про вас и то чем вы занимались одно, а вы немного другое (иная точка зрения). Более подозрительно когда оба слово в слово повторяют.
Если же впереди еще этапы, то рекурсивно проходимся по пунктам ранее.
Поздравляю, вы наняты!
.
У кого-то возникнет вопрос "А зачем врать? Мои лапищи и так закрывают небо!" скажу так: стандартизации для ширины лап нет, потому каждый рекрутер думает во что горазд (некоторые вообще на рыбках специализируются и с лапами впервые столкнутся). С другой стороны 90% резюме других кандидатов состоит их "преувеличений" потому что бы на их фоне выгодно выделятся, нужно "преувеличивать". А все этапы и первый месяц работы уже покажет кто вы есть "на самом деле"
Больше всего обидно когда отбирают старые юзернеймы, ради "продажи".
Хотя ты в свое время его зарегистрировал без проблем и использовал все это время.
Судя по описанию это знакомая политика "втихаря" перевести клиента с месячного на почасовой тариф.
Сталкивался с таким не раз - есть два варианта:
- Новому клиенту дают "скрытую скидку" на неделю\месяц\квартал про которую говорится где-то в глубинах пользовательского соглашения. Через означенный срок тарификация становится без скидки и зачастую позволяет влезть в дикие минусы.
- На этапе "заказа" услуги все ок, но опять-таки в пользовательском соглашении прописано, что тариф могут поменять по велению левой пятки. Дожидаются пока клиент не "подсядет" и переключают на "более удобный" тариф.
Все это делается для того что бы выманить как можно больше денег. У нормального сервиса есть куча оповещений и перед любым действием над твоим аккаунтом тебя проинформируют на всех доступных уровнях.
Политика "учителя Сплинтера" применяется обычно или в очень мелких компаниях (зато дешево) или наоборот в очень крупных (применимо в основном только к СНГ-сектору, хотя встречаются редкие исключения)
Резюмируя - не хочешь с таким столкнутся, не экономь на критически важном и читай отзывы (хорошее пишут редко, зато плохое выливают тут же в форумы и отзовики)
Ну и бекапы, для реально важного сервиса (пусть и пет-проекта) можно было написать простой sh-скрипт который по крону на домашнем ПК "синхронизировал" бы базу. (исходных код в гите или иных)
Еще более интересно)
Вы вот говорите за помехи и тд - а если в случае машины использовать тот самый "дешевый универсальный" но воткнуть частотный фильтр и усилитель?
Как я понял из вашего рассказа - единсвенное различие между дешевыми и дорогими рациями (пофиг аналог или цифра) это та самая стойкость к помехам. А стойкость важна.
В целом я думал для машины брать Anytone AT-D578UV PRO но почитав разное вчера/сегодня понял что нужно в первую очередь смотреть на то, есть ли на рацию открытые прошивки какие-то. На втором месте качество сигнала. И тут начинаются частности, так как качество (и силу) сигнала можно "догнать" разными модулями.
Спс, много интересного для себя узнал.
Последний вопрос - что лучше выбрать, цифру или аналог?
В интернете это срач уровня какой язык программирования самый важный.
Как "первую рацию" взял аналоговые (дешевле и проше) но за год пользования начинаю смотреть в сторону цифры. Во-первых, никого лишнего на канале, во вторых можно СМС, а не голосом.
Пугает что из за помех цифра может "лечь". Что вы по этому поводу скажете? Из практики и тд. Интересует именно как способ связи в случае ЧП, особенно если нужно держать связь между машинами на трассе.
Не понял за удаленное управление - это передача цифры или таки голосом?
Но вообще у меня вопрос более комплексный - какую рацию выбрать и как над ней пошаманить для сугубо "евакуационных" нужд. Что бы на случай ЧП была связь как мин у меня с женой, плюс в машине стационарное на большую мощность.
В интернете много противоречивого, в том числе по поводу выбора циры или аналога. На сейчас взял пару баофенгов, но они как то такое себе как по мне. Одну рацию вообще перепаивать пришлось, там регулятор звука уже убитым был.
Все кто хоть раз пытался собрать хотя бы фрагмент памяти на логических елементах знает что заголовок статьи дичь.
Для того что бы просто работали большие схемы есть специальные моды и "опорные блоки" благодаря которым их работа поддерживается даже если они не в зоне видимости.
Но это ладно - нейронную сеть на редстоуне там точно никто не создавал. Максимум простое распознание по вбитым шаблонам, хотя я не отрицаю варинта что редстоун используется просто как "интерфейс" для передачи данных на какую то внешнюю сишную библиотеку распознания
Статья хорошая, но оставила послевкусие: "как прочитать лекцию о том, про что я ничего не знаю и не подать вида".
Как стенография или водяные знаки вообще относятся к криптографии? Это можно использовать в криптографии, для хранения контрольных сумм разного толка и прочих данных необходимых для подтверждения целостности, но назвать это "скрытой криптографией"....
Алгоритмы шифрования - ожидалось какого-то базового обзора обо всем и не о чем, с затрагиванием конкретных случаев и пояснением для чего они лучше. А на деле просто сказали "есть симметричное, есть ассиметричное, вот какие у него особенности".
Ладно если это "обзорная" статья, но зачем тогда приводить пример с таблицами, отображающими время в микросекундах для шифрования и расшифрования (только симметричных алгоритмов)? Почему не привели такой же пример для асимметричных? Почему вообще в таблице DES, но нет AES?
И это я не затрагиваю такие тонкие материи как стойкость, размер пакетов (для некоторых алгоритмов это критично и может затрагивать поставленную цель) или, боже упаси, быстрые проверки целостности без необходимости дешифровать весь пакет или комплексные подходы шифрованию для разных уровней данных.
В целом тема очень интересная и имеющая множество подводных. И даже на базовом уровне, затрагивая верха, что бы привлечь к своему курсу можно написать много разного.
Но текущая подача наоборот отталкивает - если такое пишут в "обзорной статье", то что же тогда там "рассказывают" в специально подготовленном курсе?