Сохраняй посты, комментируй и ставь оценки
На западе набирают популярность увеличители экранов, которые делают из вашего ноутбука полноценный рабочий стол с несколькими мониторами. Стоимость такой приблуды на Амазоне — 250 евро или 25 тысяч рублей.
Владельцы кофеен: 🤦♂️🤦♂️🤦♂️
Китайцы сделали идеальный транспорт, для работников которых вызвали в офис.
"Chuck Norris through the years!" I understand everything, but the situation does not change at all :(
Это не у Чака наступает старость, а у старости наступает Чак.
История произошла вот прямо сейчас и чуть не закончилась моим конфузом.
В своё время я оставлял разные заявки на биржах труда на подработку удалённо. Ну,, оставил и забыл. И тут на днях мне пришло письмо о том что компания ООО «Снабполиграф» отреагировала на мою заявку "оператор ПК". Пишет некая "Юлия Козлова"
Ай, какая коварная приставочка Re. Как будто мы с ними общались... Но я это не сразу прочухал. не сразу я прочухал и то, что пишут мне с разных адресов.
Возникли вопросы и к адресу почты - корпоративные адреса читаются нормально.
Но окончательно мне открыл глаза вот эти моменты:
Попробовал выделить название фирмы, чтобы пробить в поиске и понял, что весь этот текст - вставленная в тело письма картинка.
Вот что показали Яндекс карты по указанному адресу
Эх, а как лакомо выглядели задания...
Какую только шушеру Яндекс не регистрирует...
В ассорти было что-то про унитаз и поиски налички..... Короче, моя история в тему.
Я уже давно закупаюсь на аптека ру, потому что бюджетных аналогов в моей ближайшей аптеке никогда не было. Несколько первых заказов удачно оплачивал картой, а потом аптека-пвз сказала, что оплата только налом. Ок, искал нал, бегал до банкомата 1.5 км в другую сторону.... а потом мне это надоело. Прихожу за очередным заказом (около 800р) в аптеку, собираюсь оплатить картой, фармацевт отказывается, ссылаясь на приказ начальства. Прошу телефон начальства, говорю, что не удобно бегать до банкомата, предлагаю выход - оплачиваю заказ картой и покупаю что-то из ассортимента аптеки или пусть накинут процент/комиссию в пределах разумного. Но начальство было непреклонно. Задаю контрольный вопрос про оплату картой, получаю очередной отказ и уже через пол часа со спокойной душой отправляю обращение в роспотребнадзор по факту отказа принять оплату банковской картой.
Через некоторое время звонит телефон, в трубке инспектор РПН. Спросила всю историю по этому случаю, попросила прийти в общественную приемную. В назначенный день был на месте. В приемной уже сидели представители аптеки. Владелец как раз показывал расчеты по выгоде от оплаты заказов картой и уверял, что "чуть ли не в убыток себе они сотрудничают с аптекой.ру". Я снова высказался по этому поводу, представители аптеки пытались доказать мне, что это всё "публичная оферта" и если я согласился на условия аптеки.ру, то не могу предъявлять претензии к аптеке-пвз. Спор заходил в тупик и я ушел.
Через неделю получил заказное письмо. РПН отчитался, что на аптеку-пвз составлен протокол по статье№. Штраф по этой статье от 30 до 50К. Вот такая экономия. Зажопить эквайринг 1-3% от 800 рублей и заплатить штраф 30к минимум, плюс геморой по предоставлению всей отчетности за год.
Сейчас эта аптека-пвз спокойно принимает оплату картой.
Пикабу познавательный и образовательный. Вот и теперь, очередной гуру бизнеса делится с нами своими ценными мыслями про бизнес. Поскольку в строительстве или там барбершопах я не сильно разбираюсь, глаз зацепился за металлообработку. Ну и в камментах попробовал поуточнять, что же имеется в виду.
Итак. Гражданин рекомендует входить в токарное дело имея:
"Универсальный набор это дип в состоянии на 3- + любой заводской новый или с консервации или после восстановления + Фрезер. Но надо быть умнее. Открой фирму ндс20% и закинь рекламку на авито, сайт сделай. Также найди токарей в своём городе и области. Поработай перекупом в ноль, тогда поймешь какая оснастка нужна. Может и самому точить не придется."
Для тех, кто не знает, ДИП300 производился с 34 по 68 годы, имеет массу от 4 тонн и длину от 4 метров. Стоят такие нынче от 200К в состоянии "ушатан в хлам". Основное у этого станка - диаметр обработки над станиной в 600мм.
Следующим предлагается взять любой заводской новый или с консервации. Ну тут, поскольку конкретики нет, будем считать, что это аналог 16К20, например. Это миллиона 2,5-3 готовить надо. Шешнашка весит от 3 тонн и имеет длину от 3 метров. Это для понимания размеров помещения важно. Т.к. если станов у нас 4 в длину и 1,2 в ширину, но на самом деле, с учётом рабочего пространства вокруг это 6 в длину и 2,5 в ширину. Т.е. 15 квадратов на один станок.
Пока остановимся на этом и осмотримся. Вот, допустим, у нас таки есть деньги на 2 станка. Это уже 2,5 ляма, надо отметить, включая такелажные работы и перевозку. Что же мы можем сделать на этом наборе прям сразу после включения в розетку? Ничего. Вот да. Вот так вот, прям НИ ЧЕ ГО.
Поясню. Даже для того, чтобы просто выточить "палку" длиной 500мм и диаметром пусть будет 138мм, нужно:
взять заготовку. Пруток стали диаметром 150мм. и отрезать 500мм +припуск на торцевую обработку. Чем? Очевидно, ленточной или мехпилой. Об этом не сказано ни слова. А без этого, магии скорее всего не получится. И если 50мм ещё можно перерезать отрезным, то болванку на 100мм+ диаметром уже не получится... если рационально, конечно. Ленточная пила (с гидроразгрузкой и подачей СОЖ) стоит от 150 бу хор.сост и занимает внезапно примерно 3 кв.м.
ежели у нас на хозяйстве есть ДиП с диаметром в 600, значит надо на нём обдирать хотя бы 300-миллиметровые брёвна? Кстати, ленточная пила для такого размера уже будет стоить 250+. Ну ладно. А как это бревно ворочить? Скажем так, масса заготовки Ф150х500 составит 70 килограмм. Т.е. в одну каску ваще никак (на регулярной основе), учитывая, что рабочая область станка находится примерно на уровне низа рёбер, но к ней надо тянуться вперёд... Нужна кран-балка, портальный кран или хотя бы гаражный.
окей, заготовка есть. Отпилили, на кранбалке перевезли к ДиПу, поставили в патрон. А чем обрабатывать то? Резцов надо много. Прям вот очень много... Прям вот десятки килограмм. Разных! Причём я не уверен, что на ДиП можно купить современный резец с мехкреплением. Скорее всего, такие "лопаты" как на этом монстре только напайные. Т.о. надо заводить газовый пост: баллон пропана, баллон кислорода, шланг, горелка, серебряно-латунный припой...
окей, вот мы припаяли пластинку к резцу. Но она же тупая. Её надо точить. Для этого нужен заточной станок или точило. А лучше два. А на них - камни разные повесить. На одном обычные "кирпичи", а на втором алмазные. Чтобы удобно было. Потому что менять камни - это ещё и балансировать их. Т.е. по-быстренькому не сделаешь.
отлично, вот мы сделали первый проход... ага, пока только первый, а уже у нас внезапно 2-3 вспомогательных станка есть +грузоподъёмное оборудование. А чем измерить? Надо измериловку закупать. Обычный штангель подойдёт только для заготовительных операций. Для частого, быстрого и точного измерения нужен цифровой, желательно не с алика (они так себе). А если хотя бы иногда делать детали не под сварку, а с полем допуска в 5 соток (очень частая задача у практикующего токаря) - это нужно иметь комплект микрометров. А они идут интервалами по 25мм. Т.е: 0-25, 25-50, 50-75 и т.д. У меня их, например, до 300мм. Нужно иметь нутромеры. Они опять же идут интервалами, но по 50мм. Но и стоят гораздо дороже. Чтобы проверить штангель перед работой (прикиньте, это нужно!) - нужно иметь хотя бы один набор концевых мер длины. А для проверки микрометров - плоскопараллельные меры. А чтобы выставить заготовку не на глаз, кстати, неплохо бы иметь индикатор на стойке. А лучше парочку. В измериловку можно закопать вообще любые деньги. Это не фигура речи. У меня потрачено уже больше 150 тыщ на всё это и конца-края не видать... Постоянно нужно то и это.
Это мы рассмотрели изготовление просто цилиндрической детали заданного размера. Но таких задач мне лично за годы работы приходило от силы несколько раз... А для изготовления таки изделий с несколькими диаметрами, расточками, канавками и т.д. понадобятся планшайбы обычные и универсальные, патрон четырёхкулачковый, люнеты подвижные и неподвижные, комплект свёрл минимум штук на 50, комплект развёрток, резьбонарезной инструмент, оснастка для задней бабки всякая... как минимум живой конус и живой гриб, а лучш ещё иметь и центр-патрон... переходников с разных конусов на разные конуса много не бывает опять же. Т.е. чисто только токарной оснастки у меня более 700 килограмм. Ну эта та, которая больше никуда особо не применяется.
Но ведь наш гуру предлагал ещё и фрезерок заиметь. Помимо денег (это от 300К) это так же тащит за собой кучу оснастки. Т.е. на фрезер у меня килограмм 400-500 точно будет. Это и фрезы и расточные головки и тиски разные и прижимы\прихваты, параллелек и домкратиков только два ящика! И, кстати, фрезу на точиле уже не заправишь. Это надо иметь универсально-заточной станок и уметь им пользоваться. Комплектный будет стоить от 300К. И к нему, кстати, тоооооже нужна гора оснастки.
В целом, получается так: станок сам по себе это как автомобиль без колёс. Он полностью работоспособен, за одним маленьким нюансом. Он никуда не поедет... Короче, это я к чему, прежде чем кидаться в "бизнес по металлообработке" сперва хотя бы чуток поймите о чем там речь.
Всем привет.
UPD. Опять получился длиннопост с большим количеством текста в формате моих пояснений - простите, но не представляю как по-другому можно что-то объяснить, вроде стараюсь не графоманить.
В этом посте, наконец, приведу один из примеров того, как может быть написано техническое задание (кто-то может придраться, что это не ТЗ, а какой-то другой вид документа - да, возможно, но как-то сформировалась привычка для упрощения, что ТЗ - это любой документ, в котором описывается техническая постановка задачи, которую разработчик должен реализовать), в котором описываются требования к методу получения информации по конкретному объекту.
Шаблонов, на самом деле много и от команды к команде отличаются. Где-то СА просто пишут, что "метод должен получать объект User из базы Users и дальше отдавать его вызывающей стороне" - и это вся постановка. В каких-то командах упарываются и пишут ТЗ на микросервис целиком, в связке статьи в git в формате asciidoc + swagger (yes, I like it и отдельно про это тоже расскажу).
Но в большинстве случаев принято что-то среднее между этими крайностями - системному аналитику важно описать следующее:
То, какие данные метод получит на вход и правила валидации для них;
То, что метод должен сделать с этими данными, т.е. какую бизнес-логику выполнить;
То, что метод должен вернуть в ответ вызывающей стороне.
Допустим, нам нужно описать какой-нибудь метод, который получает любую бизнес-сущность по ее идентификатору.
Один из шаблонов, позволяющий это описать выглядит так (к сожалению, приходится скриншотом, потому что пикабу не умеет в таблицы (или я не умею в таблицы на пикабу)):
Если кто хочет посмотреть "вживую" или попользовать шаблон - вот ссылка на страницу моего конфлю (вроде должна работать).
Теперь по шагам:
Описание метода. Что он делает, для чего предназначен. Можно описать что-то конкретное, если сервис работает как-то специфично, такую краткую выжимку, что сторонним людям не приходилось анализировать его целиком;
URI или URL метода. Состоит из одного из типовых глаголов плюс сам путь, по которому данный метод будет доступен. Про всякие best practices нейминга расскажу отдельно, в комментариях под предыдущим постом спрашивали;
Разрешения или Permissions. Если у вас есть ролевая модель и вам нужно разграничить доступ к каким-либо ресурсам среди пользователей с разными ролями - то вступает в дело данная строка таблицы. В ней нужно перечислить те роли, у которых есть доступ до данного метода;
Параметры запроса, который должны (или могут) быть переданы на вход данного метода. Т.к. у нас очень простой метод, то у нас их нет. Единственный атрибут в виде идентификатора пользователя ( ) передается напрямую в ссылке. Т.е. пример запроса будет просто выглядеть вот так: GET /users/22 - дай мне пользователя с идентификатором 22.
Пункт больше для удобства, в случае, если у вас большая система и много взаимодействующих компонентов. Описываете, кто будет дергать ваши метод. Как минимум это нужно для того, чтобы потом, когда вы будете дорабатывать их - было понятно влияние. В данном случае, если вдруг метод поменяется мажорным образом, добавится какой-нибудь новый обязательный параметр - вы не забудете доработать еще и фронт.
Параметры ответа. Все варианты того, что ваш метод вернет вызывающей стороне после выполнения своей внутренней логики. Перечисляем как успешные коды ответа и всё их содержимое, так и ошибочные.
Непосредственно описание бизнес-логики метода. Т.е. что метод должен сделать с атрибутами, переданными на вход, и что должен вернуть.
Теперь немного про описание самой логики работы любого сервиса. Кому-то может показаться это сложным, но на самом деле все немного проще. Вам просто логически нужно представить у себя в голове, что должен вообще в принципе сделать ваш метод и попытаться придумать - как он должен это сделать.
На этом примере - у вас стоит бизнесовая задача (например): есть админка со списком пользователей, администратор нажимает на какую-то конкретную карточку пользователя, с целью просмотреть всю информацию по нему - в этот момент, как раз фронт откроет отдельную экранную форму и вызывает наш метод, передавая туда идентификатор искомого пользователя (который он ранее получил из другого метода, который получает массив пользователей, что-то вроде GET /users), чтобы получить всю нужную информацию для отображения.
Далее представляем что наш метод должен сделать, чтобы вернуть информацию по этому пользователю. Самое логичное - надо сначала найти его. Для этого нужно залезть в таблицу с пользователями и найти такого пользователя, у которого идентификатор будет совпадать с тем, что нам передали в запросе. Нашли - круто, не усложняем и возвращаем успешный успех фронт с передачей в теле ответа всей необходимой информации.
А что делать если не нашли? Вообще, технически такого быть не должно, потому что это значит, что у фронта устаревшая или недостоверная информация и нужно с этим разбираться - откуда он взял идентификатор, которого не существует? Но представим, что после того как админ открыл страницу со списком пользователей и до того, как перешел в карточку конкретного - другой админ удалил ее. В этом случае надо вернуть ошибку, что такой объект не найден.
Ну и всегда (по моему мнению), во всех методах нам нужно валидировать входящий запрос до того, как начать основную бизнес логику. Потому что зачем нам это делать и тратить драгоценное время и ресурсы, если мы заранее знаем, что запрос не валиден? Т.е. как минимум нам нужно проверить rq на соответствие контракту, что все обязательные атрибуты пришли и пришли в корректном формате. Как максимум выполнить еще всякие кастомные валидации, по типу тех же проверок на роли.
Также заранее поясняю, что в ответе ссылка на объект User (пользователь) ведет на описание атрибутивного состава объекта (в моем примере в конфлю нет, потому что я этого не сделал, но на боевых задачах - да), поэтому не нужно расписывать и дублировать этот объект еще и тут. Однако, если вам нужно передать не весь объект, а только его часть, например, не возвращать на фронт какие-то пароли пользователей или другие конфиденциальные данные, чтобы их не "схачили" - то нужно отдельно это указывать.
И еще поясню немного про пункт 1.b - особенно внимательные наверняка про него что-нибудь скажут. Пока писал, подумал, что можно использовать этот метод не только для админа, но и переиспользовать его на случай, когда обычный пользователь хочет получить информацию по себе же, например, когда открывает свой профиль. Вместо того, чтобы делать отдельный метод - просто разграничиваем права. Если он захочет запросить информацию о ком-то другом (если фронт подведет), то ему вернется болт.
P.S.: По традиции - буду признателен за вопросы про карьеру\профессию\чему угодно связанному со сферой IT - постараюсь ответить на всё.
P.P.S.: Также веду телеграмм-канал, в котором делюсь разным про профессию и про свой путь в ней. Есть и хардовая информация (асинхронные, синхронные интеграции, примеры ТЗ\шаблонов написания микросервисов), так и более софтовая - см. закрепленный дайджест.
Всем привет.
Небольшое предисловие. Я осознаю, что этим постом я вступаю на охрененно тонкий лёд. Если уж к моему предыдущему посту были претензии за то, что я посмел использовать HTTP 404, то уже интересно, какие комментарии последуют после выхода этого поста, в любом случае - you are welcome!
Но тут стоит уточнить, что все те подходы (разные), по которым мы проектируем сервисы - они разные как раз потому, что нет единых mandatory правил к архитектуре приложений, которым если не следуешь - твоя система ломается и больше никогда в жизни не заработает, даже если ты исправишь ее. Есть лишь РЕКОМЕНДАЦИИ, а их многие интерпретируют по-разному и это тоже нормально. Для кого-то свойственно не использовать коды ошибок вообще и передавать их в теле ответа с HTTP 200, для кого-то нет. Ни один из этих подходов не является не правильным.
И нет никаких технических ограничений в принципе. Ты можешь спокойно использовать метод GET для удаления объекта, если ты его так напишешь (не делайте так) или использовать метод PUT, вместо POST, для создания объекта (так уже можно, если понимаешь почему). Главное, чтобы ты понимал как эти тонкости реализации правильно применять. Если сомневаешься - используй методы по классике, хуже от этого он работать не будет.
Да, можно уже прям сейчас кидать тапками.
Теперь уже к основному телу сабжа. Сейчас расскажу про ряд лучших практик, которые можно применять. @VRock, ты как раз спрашивал по поводу конвенции о наименовании ресурсов, тут про это тоже будет.
1. Имя endpoint'а - это существительное, а не глагол. Это одна из самых распространенных ошибок, которые я когда либо встречал (и сам совершал, естественно). Например, было в моей практике и такое - POST /generateMultipleDocument.
Тут важно понимать, что метод - это уже глагол и еще раз дублировать его в наименовании эндпоинта не нужно.
В идеале, в данном варианте будет POST /documents
Не везде от этого можно избавиться, но в большинстве случаев всё-таки можно, если потратить время на придумыванием вариантов (опять же - по факту нейминг ни на что, кроме красоты и структурированности вашего проекта не влияет. А на сколько это важно - решать вам или вашей команде).
1.1. Используйте множественное число. В большинстве случаев, при проектировании методов, работающих с вашим ресурсом - эти методы будут работать не с единственный экземпляром этого ресурса, поэтому название эндпоинта должно быть во множественном числе.
Если же нужно указать, что из всего массива экземпляров ресурса вам нужно получить\обновить\удалить какой-то конкретный, то помещайте идентификатор этого ресурса в URL, передавая его в path.
Например, вот так:
/documents
/documents/
Вместо:
/document
/document/
1.2. Используйте "/" для обозначения иерархии и в принципе используйте вложенность ресурсов.
Например, если мы именуем наш ресурс, как users//playlists//songs - это значит у мы хотим работать со всеми песнями, конкретного плейлиста конкретного пользователя. И сразу понятна иерархичность этих ресурсов.
1.3. Не используйте "/" как закрывающий символ вашего URI.
Вариант users//playlists//songs сильно лучше, чем users//playlists//songs/
1.4. Используйте "-" для разделения составных слов.
Заглавные буквы использовать нельзя, поэтому привычный lowCamelCase нам не подойдет. Если писать всё слитно - очень не читабельно.
Поэтому вместо /applications//creditcardhistory, куда лучше использовать /applications//credit-card-history.
2. Не забывайте про версионирование микросервиса. Почти любой сервис с течением времени развивается и обрастает все большим количеством функций. Если сервис при создании получил версию 1.0.0, то при добавлении какой-нибудь логики в него, добавлении нового метода или полного рефакторинга - версия должна измениться.
Например:
host/v2/documents вместо host/v1/documents после внесения мажорной доработки.
Основные правила версионирования - в случае, если меняется логика незначительно, не добавляется/изменяется обязательность атрибутов, то инкрементируется минорная версия.
В случае если был полный или частичный рефакторинг, менялись обязательные параметры (например, добавлен новый атрибут, который является обязательным), возможно при добавлении нового метода (тут вопрос к разработчикам, в этом случае тоже мажорная версия повышается или т.к. это не влияет на работу подписантов то пофиг?) - инкрементируется мажорная версия.
В этом случае, все подписанты (системы, использующие ваш сервис) вашего микросервиса должны в обязательном порядке переехать на новую версию вашего микросервиса, иначе они не смогут взаимодействовать с ним. Например, если вы добавили обязательный атрибут, то они будут получать в ответ на каждый запрос ошибку, если не доработаются и не начнут его передавать, что приведет к полной поломке этого процесса.
Однако, это не всегда обязательно - в случае, если появляется такая мажорная доработка, но ваши подписанты не готовы дорабатываться одновременно с вами (причин этому может быть множество) - вы можете выкатить одновременно две версии микросервиса, v1 и v2 и поддерживать их обе. Те, кто доработался будут использовать v2, остальные предыдущую версию. Это несет неудобства и затраты, но в любом случае лучше, чем допускать неработоспособность интеграции. В дальнейшем, когда все ваши подписанты доработаются - поддержку предыдущей версии можно остановить.
Примечание: структура версионирования такова: первая цифра - это мажор, вторая цифра - это минор, третья цифра - это патч. Про первые две я уже сказал, а последняя используется только разработчиками. Насколько я понимаю, она повышается вообще каждый раз когда вносят изменения в сервис, но тут могу быть не прав.
3. Используйте пагинацию.
Отправка большого объема данных на фронт, в ответ на его запрос о получении информации по массиву каких-либо объектов, не самая лучшая идея. Как минимум, если вернуть ему тысячи объектов, лежащих в базе и попадающих под выборку - он столько все равно не отобразит, но очень задумается.
Поэтому принято выполнять пагинацию таких данных (от слова page - страница), т.е. возвращать ему часть всей коллекции в каждом запросе. Например - 15, 30, 50 элементов + информацию о текущем положении полученной информации в общей выборке. Почитать про это можно более подробно где-нибудь тут (первая попавшаяся ссылка, я не вчитывался, не реклама).
4. Используйте коды ответов HTTP правильно и эффективно.
Их достаточно много (https://developer.mozilla.org/ru/docs/Web/HTTP/Status) и их можно использовать по назначению. Все знать и использовать не обязательно, но вот примеры их использования
Использовать 201 "Created", вместо 200 "OK", в случае если вы в POST действительно создаете какой-то ресурс. Используется только в POST (ну и в PUT, в ряде частных случаев).
Использовать 204 "No Content", вместо 200 "OK" для DELETE. Это ответ на успешный запрос и он не будет возвращать тело, что и не нужно для данного метода.
Не забывайте использовать 401 "Unauthorized", 403 "Forbidden" и 404 "Not found" вместо безликого 400 "Bad Request", когда это уместно. Как правило 400 кодом пользуются когда нужно ответить на какую-то ошибку валидации или в случае возникновения бизнесовой ошибки, которую вы заранее можете предсказать (очень настоятельно рекомендую хотя бы дополнять код ответа еще и кодом бизнесовой ошибки в этом случае и желательно ее текстом (error.code и error.message соответственно).
Для валидации желательно тоже).
А для всего остального можно и специальные коды использовать.
P.S.: По традиции - буду признателен за вопросы про карьеру\профессию\чему угодно связанному со сферой IT - постараюсь ответить на всё.
P.P.S.: Также веду телеграмм-канал, в котором делюсь разным про профессию и про свой путь в ней. Есть и хардовая информация (асинхронные, синхронные интеграции, примеры ТЗ\шаблонов написания микросервисов), так и более софтовая - см. закрепленный дайджест.
Недавно завирусилась история о том, как кандидат вписал себе в резюме фиктивных два года опыта и прошел интервью на позицию в ИТ-компанию. Правда потом об этом узнали, и его вроде как уволили. Я не придал этому значения, пока мне не рассказали, что в одной онлайн-школе этому прям учат студентов, такая вот "гарантия трудоустройства". А на днях в одном из hr-чатов выложили фейковое резюме тестировщицы с 2 годами опыта, которая не смогла ответить ни на один технический вопрос.
В общем, весь этот треш оказался ближе, чем кажется. Не буду рассказывать, что обманывать нехорошо. Но я обратился за рекомендациями к Оле - HR в ИТ, карьерному консультанту и автору канала про карьеру, с которой мы трудоустроили уже ни один поток моих учеников.
Далее от ее лица.
Итак, последствия таких обманов могут быть разными:
(1) резюме могут закинуть по разным чатам и потом, чтобы найти работу, придется менять еще и фамилию (внутри одной сферы обычно тесно общаются и репутация дорога)
(2) в крупных компаниях есть службы безопасности, которые проверяют биографию еще до трудоустройства.
(у меня, кстати, был случай, когда клиентке отказали на последнем этапе из-за того, что данные из анкеты не совпали с реальностью)
(3) даже если все получилось, но в процессе работы информация вскрылась, могут и скорее всего уволят.
!(4) и что-то новенькое: hh.ru, на котором размещаются резюме, начал проверять точность информации и связываться с работодателями.
Поэтому поговорим о том, как можно привлечь внимание к себе, чтобы потом не уволили, как в этом случае:
(1) Начинать искать как можно раньше (когда изучена уже какая-то база), потому что то, что дают на курсах не всегда равно требованиям компаний. Чем больше смотрите вакансии и общаетесь, тем лучше понимаете, что нужно рынку.
(2) Использовать нетворкинг - знакомиться с людьми, которые работают в тех компаниях, куда вы хотите. Даже просто написать и попросить зарефералить. Теория с рукопожатиями тоже работает (у меня так много клиентов и знакомых нашли работу)
*кстати, консультант тут тоже обычно помогает и закидывает резюме по своим каналам (это, конечно, не гарантия успеха, но повышает конверсию)
(3) Резюме должно быть продумано до мелочей, из самого базового:
➡️ название должности должно соответствовать названиям вакансий, т.е не "специалист", а максимально конкретно;
➡️на первом месте должен быть опыт по той вакансии, на которую вы хотите, даже если это учебный опыт;
➡️ расписать подробно навыки, которые вы получили на обучении, лучше сразу с примерами из практики.
(4) Брать из предыдущего опыта все навыки, которые могут быть полезны. Смена направления — это не начинать с нуля, всегда есть переносимые навыки. Например, опыт ведения коммуникации и работа в команде, который есть у всех, и другие soft skills. Успех поиска 50/50 зависит от hard и soft skills.
(5) Использовать сопроводительные письма и писать вдумчивые отклики на позиции (спам-рассылка скорее всего не даст результата). А вот резюме + нормальное сопроводительное можно отправлять не только на hh, но и напрямую в компании, даже если вакансии нет, вас могут добавить в базу и написать позже.
*я всегда читаю, когда вижу, что человек постарался, а иногда даже даю обратную связь и помогаю скорректировать.
(6) Использовать разные источники поиска, в том числе рассматривать стажировки, после которых можно трудоустроиться (иногда это быстрее, чем искать вакансии).
Да, рынок очень поменялся за последние несколько лет, и все эти шаги объединяет активность и инициативность. Пробуйте разные гипотезы, потому что если не делать, то точно не получится. И пишите в комментариях, если нужен подробный разбор того, как правильно составлять резюме.
Я думаю многие из вас так или иначе сталкивались, либо слышали, про такой прием при поиске работы - как завышение своего стажа (либо накручивание его вообще, если его совсем нет). А одна из последних прочитанных мной новостей (реальных или нет - это уже другой вопрос), сподвигла меня написать свое мнение на этот счет.
Вообще, за 2023 год история с накруткой опыта набрала прям очень большую популярность, потому что было много успешных кейсов, о которых многие спешили поделиться в соц сетях.
Появились даже несколько каналов, в которые такие истории регулярно публикуются (рекламировать, конечно не буду). Некоторые из них правда заканчивались очень неудачно для решивших поделиться, потому что их работодатели наткнулись на эти посты и неприятно удивились. Поэтому если уж вы воспользовались таким способом, то хотя бы не распространяйтесь об этом =)
И подобные методики даже полу-официально предлагали некоторые известные и крупные курсы, которые обещали своим студентам гарантию трудоустройства, а тут, как известно, все способы хороши.
Как это работает?
На самом деле очень просто, т.к. основная проблема это не пройти техническое собеседование, а именно дойти до него. Прорваться сквозь труднопреодолимый барьер рекрутеров\HR, которые часто даже не смотрят резюме в котором нет хотя бы года релевантного опыта. Поэтому люди просто добавляют некий выдуманный опыт строчкой в резюме и это сразу же повышает конверсию просмотров, заинтересованность рекрутеров и соответственно количество "проходок" на собеседование. А всё потому, что у работодателя нет возможности убедиться в реальности того опыта, который указан в резюме. По крайней мере на уровне HR, а иногда и на уровне СБ, насколько я понимаю.
А уж спустя несколько собесов, научиться отвечать социально одобряемым образом на вопросы интервьюера (благо они очень часто одинаковые) - достаточно не сложно. Особенно если ты за энное количество собесов научился держаться уверенно, прокачал скилл их прохождения ив целом производишь благоприятное впечатление. Даже если у тебя слабенькая база. Если ты еще и действительно учился, понимаешь тему, готовился и так далее - то это еще сильнее облегчает собес.
Поэтому данный способ достаточно часто срабатывает в плюс и ты начинаешь получать офферы.
Не буду давать моральную оценку данному способу, потому что все хотят найти достойную работу, а конкуренция далеко не маленькая. Если есть лазейка чтобы попасть на работу и начать зарабатывать деньги - ну что ж, дело сугубо материальное, осуждать это я не в праве.
❕Однако, лично мое мнение в том, что не нужно перебарщивать. Я имею ввиду то, что если у вас совсем нет опыта - не нужно сразу устраиваться на миддла или сеньора, накручивая слишком большой опыт (такое, судя по некоторым историям, тоже реально).
Одно дело без опыта начать работать джуном - от тебя многого ждать не будут, вполне может прокатить и тебя не "раскроют". Но если ты пройдешь на того же миддла и даже не сможешь разговаривать с командой на одном языке - то в чем смысл? Не говоря уже о том, что ты не сможешь выполнять свои задачи самостоятельно, чего ждут от специалиста этого уровня, поэтому испытательный вы вряд ли пройдете, да еще и потом можете столкнуться с различного рода неприятностями
Поэтому единственный совет - подходите ко всему разумно.
P.S. своим студентам я такое не рекомендую и даже не упоминаю такой вариант. Я предпочитаю вариант с повышением конверсии и внимания со стороны рекрутеров через улучшения качества резюме. Добавление ключевых слов, переиспользование текущего опыта, казалось бы не релевантного, в рамках новой профессии и так далее. Все это вполне возможно и без обмана (хотя, конечно, возможно не так эффективно как докрутить себе год или два, ведь придется искать работу месяц, а может и не один).
P.S.: По традиции - буду признателен за вопросы про карьеру\профессию\чему угодно связанному со сферой IT - постараюсь ответить на всё.
За большим количеством постов с полезной информацией про системный анализ - заглядывайте на канал, в закрепленном дайджесте можете найти что-то интересное для себя.
Что же это такое ваш контент-менеджер?
Контент-менеджер - это тот, кто отвечает за создание, редактирование и управление контентом на различных платформах, включая социальные сети, блоги, веб-сайты и мессенджеры, такие как Telegram. Их цель - обеспечить постоянный поток интересного, полезного и привлекательного контента, который привлечет и удержит аудиторию.
Что делает ваш этот контент-менеджер?
- Разработка контент-стратегии:
Определение целей и задач контента, выбор тематики, определение ключевых аудиторий и платформ для размещения контента.
- Создание контента:
Написание текстов, создание изображений, видео и других медиа-материалов в соответствии с контент-стратегией.
- Редактирование и оформление:
Обработка и редактирование контента для обеспечения его качества, удобства чтения и визуальной привлекательности.
- Распространение контента:
Планирование и размещение контента на различных платформах, ведение расписания публикаций, а также взаимодействие с аудиторией и отслеживание реакций.
- Аналитика и оптимизация:
Анализ эффективности контента, изучение метрик и обратной связи, а также внесение корректив в стратегию на основе полученных данных.
Зачем вам нужен контент-менеджер?
Контент-менеджер поможет вам создать сильный и эффективный контент, который будет привлекать и удерживать вашу аудиторию в Telegram.
Они обеспечат постоянный поток интересного и актуального контента, который поможет вам достигнуть ваших целей и выделиться среди конкурентов.
Готовы поднять свой контент на новый уровень?
Тогда вам придется искать хорошего контент-менеджера.
Ещё больше про Telegram, маркетинг и свою жизнь, я пишу в своём канале
Так же жду ваши вопросы, буду рад на них ответить.
Начать делать хоть что-то.
Когда ты начал, дальше уже нюансы и мелкие трудности которые решаются в моменте.
Приведу топ 3 сложности которые чаще всего я встречал.
1. Выбор тематики.
В одном чате одну тематику советуют, в другом чате другую, а предыдущую тематику из первого чата хаят.
И что же выбрать ?
Разберем вариант когда бюджет подходит под многие тематики.
Анализируем тематики которые на хорошем подъеме и пользуется в данный момент популярностью.
Условно видите как часто рекомендуют тематику, пошли в сервисы аналитики и посмотрели на сколько она активна.
2. Рекламный креатив.
Прямо самая боль всех админов это подобрать креатив который будет вести подписчика в приемлемую цену.
Креативы так же очень быстро выгорают, по этому всегда нужно держать руку на пульсе и контролировать процесс.
3. Закуп рекламы и продажа рекламы.
Для не знающего азов, действительно кажется что это самое трудное, и сам я так думал когда закупал на свой самый первый канал ( были даже мысли найти закупщика, но из-за того что не нашел, стал сам закупщиком в итоге )
По факту закуп рекламы и продажа - это алгоритм, следуя которому успешно можно закупать и продавать рекламу, проблема в том, что этой информации очень мало в открытом доступе, но если взять консультацию или обучится, то в дальнейшем трудностей это не вызовет.
Не забывайте о том, что рынок постоянно меняется, что-то стареет, что-то появляется новое.
По этому всегда нужно получать новые знания, не пренебрегайте консультациями и прочими методами поиска новой информации.
Ещё больше про Telegram, маркетинг и как можно заработать там, я пишу в своём канале
Так же жду ваши вопросы, буду рад на них ответить.
Разногласия в коллективе способны похоронить проект еще до начала работы. Собрать эффективную команду из разных по уровню спецов помогут правила совместной работы — вспоминаем наиболее важные из них.
Сколько раз видел: приходит новый менеджер и с ходу обещает начальству поднять производительность команды в три раза. Люди сначала вкалывают 24/7, остаются работать вечерами и на выходные, терпят замечания — а потом почему-то массово увольняются.
Большинство мыслит так: чем больше делаешь, тем больше результатов, тем продуктивнее. Но продуктивность — это соотношение результата и ресурсов. Чем меньше ресурсов потратишь на достижение цели, тем лучше.
Есть простые правила, которые помогут снизить расход ресурсов в команде, избежать конфликтов, перекладывания ответственности, демотивации. А в результате — добиться цели без жертв.
Негативный настрой сжирает и без того скудные ресурсы нашего мозга. Поэтому старайся всегда поддерживать в команде позитивное и конструктивное общение. Если кто-то что-то предлагает — это круто.
В то же время, не стесняйся давать обратную связь и не прячь негатив в себе — это ни к чему хорошему не приведёт. Но важно при этом настроиться на поиск решения проблемы, а не жонглировать словами или сводить личные счёты.
Не люблю, когда говорят: я не умею, мне сложно, не получится. Так бывает, когда коллеги, сотрудники или близкие люди ленятся или пытаются «изобрести велосипед» вместо того, чтобы воспользоваться успешными практиками. Посмотри, как эта задача уже решалась. Адаптируй решение под нужды проекта или личные цели. Воплоти в жизнь и следи за результатом.
Придумывать своё легче на основе чужого опыта.
Мы не можем быть одинаково эффективны во всех областях. Кто-то лучше рисует, кому-то хорошо даются языки. Экстравертам в команде нормально, а интровертам приходится не сладко.
Если у тебя что-то не получается, не бойся просить помощи у коллег или руководителя. Проект скорее пострадает не от твоей некомпетентности, а от того, что ты о ней умолчишь.
В дополнение к предыдущему правилу — не забывай помогать коллегам. Как говорится:
Нужно только подойти к вопросу разумно — не выполнять работу за других и не позволять себе перегрузки, но быть готовым прийти на помощь и принять на себя удар.
Лучшее враг хорошего. Продуктивная команда — это всегда баланс: «сделать на отлично» одно дело или просто «сделать» несколько. Второй вариант часто эффективнее, поэтому не скатывайся в перфекционизм. И другим не давай.
Видишь тренд? Зафиксируй, расскажи другим. Поделись наблюдениями, выводами, инициируй обсуждение. Команда должна иметь общее видение по конкретному проекту и по отрасли в целом. Если за бортом останется по-настоящему стоящая идея или вы провороните крутую возможность на рынке, это неизбежно приведёт к провалу.
В эффективной команде не бывает пустых совещаний, созвонов и мозговых штурмов. Собираться нужно исключительно для решения какой-то проблемы. Чтобы не тратить время впустую, фиксируй договорённости, ответственных и другие результаты собрания.
А неэффективных «болтунов», которые готовы в любой момент оторваться от работы, чтобы поучаствовать в каком-нибудь совещании, надо отсеивать.
Коллективная ответственность часто порождает коллективную безответственность. Всегда следи (если это в твоей компетенции), чтобы у каждой задачи и каждого проекта был наблюдатель — человек, который контролирует все этапы и оценивает результат.
Не забудь выяснить и за что отвечаешь лично ты, а также кто будет контролировать твою работу. И относись внимательнее к своей зоне ответственности.
Время от времени усиливай и перепроверяй свой опыт и знания.
«Я всегда закладывал 500 000 на рекламный бюджет на старом месте»
— так себе аргумент для защиты твоей стратегии продвижения.
«Я подсчитал: заложив, как минимум, 500 000 рублей в рекламных бюджет, мы получим нужный охват и прибыль»
— к этому аргументу уже стоит прислушаться.
Старайся доказывать свои знания и опыт с помощью объективных фактов: цифр, аналитики, исследований, лучших практик отрасли.
При создании команды, выбирай лучших. В футболе сила команды определяется не умениями форвардов, а выносливостью защиты и центра. То же самое в проектной работе — нужно быстро убрать из коллектива слишком слабых специалистов, чтобы они не влияли на итоговый результат.
Каждый участник команды неизбежно действует в своих личных целях. Чтобы команда была эффективной, эти цели должны совпадать с целями проекта, ну или хотя бы находиться в той же стороне. Если цели разойдутся, участник перестанет приносить пользу команде и проекту.
Маленькие ежедневные задачи порождают обилие маленьких ежедневных решений. Прислушивайся к мнениям коллег: каждый из них решает тысячи проблем ежедневно, каждый обладает хорошим обзором своей части проекта.
Полезно будет объединить эти маленькие тактические решения и применять для решения стратегических задач. При этом вы все сможете достичь больших результатов с меньшими затратами ресурсов.
Если ты не супер-звезда на гастролях, постарайся снизить уровень претензий и ожиданий, работая в команде. Будь мультикультурным: научись поддерживать общие командные ценности, а также принимать ценности каждого ее участника. Какими бы странными они ни казались. Позитивный настрой, взаимоуважение и поддержка сделает вашу команду еще эффективнее.
Не имеет значения — руководишь ты командой или просто выполняешь задачи. Помни, что «продуктивность» не равно «результаты». По-настоящему продуктивной станет та команда, которая будет соблюдать правила совместной работы и затратит на достижение тех же результатов меньше ресурсов.
