Вот вам свежая ссылка на личного ассистента почти похожего содержания и перфоманса без подчёркиваний. В ней совсем не про решалу, но требования просто сказка (как раз те самые рабочий день 24/7).
Подскажите, в чём именно у вас выражается торможение микросервисов? Как и какой оверхед они накладывают на сеть у вас? На сколько понимаю, даже простецкий хостер (сугубо для примера) сейчас гарантировано даёт 1 Гб/с между виртуалками. И если смотреть задержки распростанения пакета, то они в пределах милисекунды или даже долей милисекунды
Работа в IT сейчас все равно, что должность продавца в магазине лет 40 назад, — уважаемая и с разными интересными перспективами.
40 лет назад, как раз во времена Андропова, у продавца в магазине была высокая перспектива пойти по этапу. И было за что. Как и не были эти барыги и спекулянты уважаемыми - знаменитый советский сервис.
Дефицит IT-специалистов — это серьезная проблема, которая требует комплексного подхода.
1 Инвестиции в подготовку разработчиков
2 Глобальный поиск талантов
3 Выравнивание гендерного состава
1 Сейчас интернет завален всевозможными курсами на разных языках и для разных культур. Куча литературы и виртуальных лабораторий. Видеолекций просто тьма. Невообразимое количество дорожных карт по тем или иным направлениям в ИТ. Изучай не хочу. И что качество и уровень разработчиков сильно выросли? 2 Вот нашли талант. Дальше что? Что можете ему предложить? Какие гарантии имеете предоставить? То что он будет завален бесполезной работой? Таланту нужно место для приложения своих умений. Что у нас с такими местами? Ну чтобы без ветрянных мельниц в виде бесконечных отчётностей или постоянных согласований на каждый чих. Чтобы без бюрократии, чинопочитания, местечковой аристократии (госуха), чтобы современные проекты на актуальные темы (не импортозамещение). В сухом остатке толком предложить нечего. 3 С этим вообще непонятно. Предлагаете поиграть в модную игру в западных компаниях, когда нанимаются люди не по знаниям и умениям, а по разнорядкам спускамым сверху. В начале статьи писали чушь про уважаемых с интересными перспективами продавцов в магазинах периода конца коммунизма. Так вот одной из многочисленных причин того развала было то, что набирали на работу согласно партийной благонадёжности и принадлежности, а не по реальным знаниям и умениям. С другой стороны, у нас в вакансиях ИТ пока ни разу не наблюдал требования к полу соискателя. У нас реально можно из-за возраста получить отлуп, а не из-за пола. Или эйджизм это не та проблема, которую необходимо решать?
Дефицит человеческих ресурсов — фундаментальная проблема рынка труда России.
Не надо прятать за такими высокими фразами реальную проблему. С человечискими ресурсами пока не так уже плохо, но там (на небосводе) постоянно думают об этом. Фундоментальная проблема рынка труда России в острой нехватке высококвалифицированных, образованных, порядочных и ответственных низкооплачиваемых специалистов. Всё остальное демогогия и от лукавого.
Компании, которые не ищут джунов, испытывают острый кадровый голод.
Несколько лет наблюдаю за разными группами в мессенжерах и социальных сетях специализированными по поиску работы в ИТ. И складывается впечатления, что мидлы особенно не нужны. Как и не наблюдается острого кадрового голода. Откуда ему взяться вообще, если очень много компаний ушло с рынка, осталась в основном госуха, банки и нефтянка - по сути таже госуха. Ну вот взяла компания джуна, что с ним дальше делать? На реальный проект его не пустишь одного, сеньора к нему не приставишь, его давно мидлы обложили. Что с ним делать?
После ещё пары десятков таких собеседований я понял, что рынок не изменился ни разу, но при этом вообще не похож на то, что было буквально 2-3 года назад.
Не могу сказать, что прям весь такой ИТ аксакал и больше всех повидал на своём веку, только повспоминав своих и знакомых историй, могу сказать, что 8-10 лет назад было такое же положение дел. Ну разве что рекрутеры звонили на телефон или писал на электронную почту, а не как сейчас в мессенжеры и профили социальных сетей.
После этого забавно слышать от комьюнити-рекрутеров, что на рынке дефицит специалистов, не могут найти хорошего мидла-сеньора месяцами, при этом под их порогом орава толковых и не очень ребят, которые жаждут работать на галерах
С ними иногда бывает крайне забавно. Доходило до того, что напрямую у бизнеса спрашивал, знают ли те, что творят при поиске их сотрудники? А именно: - резюме без фотографии? сразу в корзину - на фотографии к резюме слишком фривольно выглядит (присутствует вейп, кальян или вызывающего вида майка) сразу в корзину - в письме от кандидата только ФИО, название вакансии и приаттаченное во вложении резюме ? Без небольшого описания самого себя или самопрезентации в теле письма? сразу в корзину
И это не мои сказки, это из их жалоб на Linkedin, как им трудно приходится искать кандидатов.
вы знаете что такое NDA?
Знакомый практикующий юрист и владелец небольшой юридической компании по совместительству, решил себе сделать сайт и обратился в соответствующие компании, которые занимаются изготовлением сайтов. И вот когда вопрос дошёл до юридической стороны сделки непередаваемому веселью юриста не было предела. Поэтому не стоит надеяться, что в наших Палестинах NDA или его подобие имеет особую силу.
старшему разработчику в другой команде парочку таких каверзных вопросов и был послан с фразой
Да, всё так. Иногда даже не от каверзных вопросов, но фундаментальных на собеседовании можно сразу словить минусов в карму.
По итогу сейчас мы имеем: Дикую нехватку рабочих рук в команде. Постоянно не укладываемся в очередные дедлайны. Вопросы со стороны начальства о большой загрузке и медленно достигаемых результатах. "Всезнающего" техлида, на которого давит начальство, который давит на меня.
Мы имеем дефицит высококвалифицированных (с той самй БАЗОЙ) и ответственных и опытных, но низкооплачиваемых специалистов.
Можно своё мнение прибавить, как взгляд с соседней колокольни? По ходу работы постоянно сталкиваюсь с разработчиками и с результатами их труда. Это основная часть моей работы. Сам себя разработчиком не считаю, хотя постоянно пишу тот или иной код (HCL, CI/CD, скрипты автоматизации), изучаю техническую литературу, которая иногда заходит в область разработки. Каюсь, периодически пишу на Go. Этим всего лишь хочу сказать, что совсем не далёк от темы разработки и подробностями, связанными с этим.
Уже который месяц подряд наблюдаю как команда с дюжину разработчиков пытается осилить проект на описываемом языке программирования. И вот что вынес в качестве наблюдений за командой разработки:
Go — императивный или декларативный?
Не поверите, многие уверены что функциональный
Что будет, если читать из закрытого канала?
Что будет, если писать в закрытый канал?
У нас проект пока в стадии разработки, поэтому пока не до каналов и что с этим связано. Если надо, будем потом необходимое внедрять (с)
Главный недостаток стандартного логгера?
Стандартный логгер для некоторых был открытием
Есть ли для Go хороший orm?
Короче, есть GORM, его берём. (с) На попытки уточнить данный выбор относительно других, был просто проигнорирован. Мало ли чего знаю, им виднее
Какой у вас любимый линтер?
С большим трудом своей командой протолкнули линтер в CI. Но жить ему там похоже не долго
Способы поиска проблем производительности на проде?
Ну что за вопросы? Для этого есть специальная команда эксплуатации. И с данным мнением встречаюсь вообще на протяжении многих проектов
Стандартный набор метрик prometheus в Go -программе?
Прометей это вотчина девопсов или команды эксплуатации либо мониторинга, если таковая есть
Какие технологические преимущества языка Go вы можете назвать? Наводящие вопросы: чем отличается goroutine от OS thread?
Тут мы попадаем на очень зыбкую почву многопоточности, и всеми связанными с этим познаниями. Что такое поток исполнения, где именно он исполняется и отличие его от процесса. Отдельная тема (неплохо раскрытая Тоненбаумом) варианты реализации многопоточности (в контексте пользователя, в контексте ОС, гибридная). И то что многопоточность и асинхронность это совершенно разные вещи. Но это уже отдельная боль. И когда по тому или иному поводу (обычно связанному с потреблением аппаратных ресурсов) начинается разговор про потоки исполнения, то выясняется, что для многих они тождественны процессам ОС
Какие технологические недостатки языка Go вы можете назвать?
Нет классов, наследования, полиморфизма, перегрузки. Очень сильно не хватает точки запятой в конце строк
можно ли сделать жидкость с плотностью бетона, сохраняющую свои свойства в приемлемом диапазоне температур
С плотностью в 13 раз большей подойдёт? Она ещё замерзает при -38.8 и закипает при +356. Раньше довольно массово использовалась в выпрямителях переменного тока электро локомотивов. В одном выпрямителе было около 25 кг.
О дефиците кадров в российском IT не говорит только ленивый. Некоторые пишут, что на рынке не хватает около 170 тысяч опытных специалистов, а другие и вовсе считают, что айтишников нужно ещё миллион.
Вот кому верить? В других статьях по найму пишут с точностью до наоборот: рынок перегрет, мидлы мало кого интересуют, потому что сеньоров невалом, как быть с джунами никто не знает. А есть ещё т. н. "вкатуны". Не верите? У вас про это в следующем абзаце:
Но самим программистам от этого не легче. На одну хорошую вакансию дикая конкуренция: иногда больше 40 человек на место.
В последнее время рынком «рулят» соискатели, а не работодатели.
И это при конкурсе от 40 человек на место? В описании первого этапа своих собеседований поведали:
Мы стараемся использовать все инструменты для работы с потенциальными кандидатами, ведь на одну вакансию иногда приходится обработать до 50 специалистов.
И заметьте, про джунов у вас ни слова в тексте нигде. Вы их даже не рассматриваете.
Если рекрутер не знает о каких-нибудь ваших компетенциях, значит, их нет.
Как это коррелирует с требованием делать резюме компактнее, короче и лаконичнее? Чтобы легко помещалось на два листа. Иначе листать, а тем более читать не досуг и вообще занимает много рабочего времени. Вот как сделать короткое резюме, например, специалисту уровня senior с такими пожеланиями:
Помимо стандартных пунктов «стек технологий» и «опыт работы», хорошо бы указывать достижения и результаты решения комплексных задач на предыдущих позициях. Это должны быть факты, которые подтверждают именно ваш вклад в реализацию проектов. Например, самая крупная задача, над которой пришлось работать. Это поможет ещё до первого созвона понять, какие умения есть у спеца и в чём он лучше других кандидатов.
На первом интервью не спрашивайте о зарплате. Рекрутер просто не знает, что ответить, потому что финансовый вопрос зависит от скилов спеца и решается уже после технического интервью
Стоит ли верить такой басне? Разве на нового специалиста не рассчитывается ФОТ, или счёт полностью открыт и если специалист подходящий, то никаких средств не жалко?
Иногда руководитель задаёт вопрос на логику, чтобы понять, как мыслит соискатель.
Позволителен ли кандидату аналогичный шаг, чтобы понять как мыслит руководитель? Вдруг предпочитаемый способ мышления не совпадает или даже полностью противоположный.
У нас были сильные кандидаты, которые во время интервью с рекрутером курили кальян или вейп. Или которые проходили собеседование в трусах — и мы это видели.
А писали в начале о кадровом голоде, колоссальной нехватке специалистов и что теперь кандидат выбирает работодателя. Кому верить?
В качестве финального совета хочу сказать: не пытайтесь устроиться абы куда. Старайтесь найти команду, которая будет уважать вас как профессионала и разделять ваши ценности.
Легко сказать, когда в одном месте пишут одно, в другом противоположное. О многом важом и интересном не пишут совсем.
Верится с таким трудом, что не верится совсем. И тому есть множество примеров ещё совремён царя Гороха, примеры тому высказывания сетования Ивана Кулибина на равнодушие и бюракратизм родимых чиновников и написанное не на пустом месте стихотворение Николая Некрасова.
Если кто-то скажет, что описанные времена прошли, то не совсем так. В одном известном НИИ есть отдельная столовая для руководства, больше похожая по обслуживанию на ресторан, и обычная столовая для челяди, хоть и высокообразованной. Подобных примеров, если постараться, можно привести множество. Поэтому местечковая аристократия, чинопочитание и кумовство живут и процветают. И знаменитое отечественная парадигма мироустройства: "Я начальник - ты дурак!" никуда не девалось.
Поэтому думать и писать о том, что изобретателям и первопроходцам стоит ждать поощрений за их открытия и новации из разряда научной фантастики. Множество комментариев выше тому подтверждение. Как и показательная история с русским Илоном Маском.
Вообще думал ознакомлюсь с чем-то новым и интересным в области хранения и обработки данных, примерные сравнительные цифры увижу, помечтаю о применении, может быть коллегам предложу попробовать. Но даже нигде в тексте не встретил названия хоть одной МБД, относительно которой всё писалось и сравнивалось. Разочарование да и только, как и куча вопросов к тексту и уровню интеллекта целевой аудитории, для которой предназначалься текст.
В отличие от традиционных баз данных, где данные хранятся в виде таблиц, в МБД основное внимание уделяется анализу данных и созданию быстрых и эффективных запросов.
Нальзя сказать, что традиционные (в данном контексте реляционные базы - РСУБД) хранят данные в виде таблиц. Физический движок хранения у всех разный и представляет данные на носителе по разному и таблицами там мало пахнет. И это не главное. Непонятно другое: какое отношение имеет способ хранения данных РСУБД к основному вниманию уделяемому анализу данных и созданию быстрых и эффективных запросов? Как данные хранятся в МБД и в чём отличие от хранения в РСУБД?
Они представляют данные в форме кубов, где каждая ось представляет собой отдельное измерение, а значения представляются в виде ячеек.
Из курса математики знаю про матрицы, про тензоры слышал, многомерные вектора. Но тут сдаюсь и не могут представить описанную топологию. Картинок по тексту ни одной.
В отличие от реляционных баз данных, где каждая операция над данными включает в себя чтение и фильтрацию отдельных строк таблицы
Множество операций в РСУБД побольше будет.
Еще одним важным преимуществом МБД является их способность обрабатывать большие объемы данных. Благодаря оптимизации архитектуры базы данных и использованию сжатия данных, МБД обладают высокой скоростью выполнения запросов и масштабируемостью.
Это в том или ином ввиде размазано и повторяется по всей статье. При этом нет ни слова про какие такие оптимизации идёт речь. Сжатие данных умеют многие базы данных, которые совсем даже не реляционные. Масштабируемость интересная тема. Какая она в МБД, в чём преимущетво перед РСУБД?
Также МБД предоставляют возможность создания сложных и гибких отчетов и дашбордов.
Эх...
Представьте себе гигантскую таблицу, где каждая строка олицетворяет собой уникальный набор данных, а каждый столбец – это отдельный атрибут или измерение. Многомерные базы данных добавляют третье измерение, называемое «кубом».
Несколько вопросов. 1 куда и как добавляется третье измерение, называемое кубом? 2 можно ли называть реляционную базу многомерной у которой две идентичные по числу кортежей и атрибутам таблицы, только с различающимися данными в ячейках?
Вместо того, чтобы делать сложные и медленные запросы к базе данных, используя многомерные базы данных, мы можем быстро получать необходимую информацию и принимать соответствующие деловые решения.
А не надо к базе делать сложные и медленные запросы, чтобы терять время необходимое для деловых решений. То что к базе делают сложные и медленные запросы, совершенное не её беда.
В МБД данные агрегируются ....
Довольно часто по тексту встречается эта фраза, такое впечатление, что МБД агрегируют данные перманентно, и даже когда к ним не делают никакие запросы.
Агрегирование происходит путем суммирования, усреднения или иной обработки данных внутри куба.
Агрегирование вообще от чего-то зависит? Как и кем решается, что и как будет агрегироваться?
Это позволяет сократить количество данных, которые необходимо обрабатывать для анализа, что повышает производительность и ускоряет время выполнения запросов.
Насколько точен будет анализ после сокращения количества данных? Ничто не мешает сократить количество данных для анализа в любой базе данных для повышения производительности и ускорения времени выполнения запросов.
Вообще текст напоминает статью написанную ИИ с беглым просмотром результата без всяких попыток осмысления написанного. При этом удивляет другое.
Не суть скольки мерное хранилище представляет из себя мозг, какие и как выполняются там запросы. Это не имеет никакого значения, чтобы провести небольшой анализ. Статья по сути никакая. Вообще. Нет ни примерных цифр для сравнения, нет ни одного маломальского рисунка, для удобства восприятия многомерной (вообще, по заголовку расчитывал на размерность большую трёх) структуры базы данных, нет даже названия МБД, которая бралась для рассмотрения. Есть только постоянные увещевания в той или иной форме, что "Важным преимуществом многомерных баз данных является способность быстро агрегировать данные и проводить сложные аналитические операции". Только при этом статья висит в топах, где и приметил её. Что-то мне подсказывает, выложи такое обыкновенный смертный пользователь, а не сотрудник корпаративного блога, плюсов сталье вряд ли столько поставили, может быть и минусов напихали. И в топах ей не светиться.
Хабр, я понимаю, ничего личного -- просто бизнес (не зря домен .com). Только это статья уровня реферата студента кулинарного техникума (отсыл к лирическому образу Г. Хазанова). Что дальше? Сочинения школьников на тему...? Зашквар про ИТ от Дани Милохина?
Хорошая статья. Не смотря на краткость изложения всё понятно и есть над чем задуматься. А именно над тем, что с парадигмами как и с безопасностью надо изначально определяться на начальном этапе проектирования системы. Чтобы потом не было мучительно больно во время инцидента и после, когда по итогам надо передлывать и менять то, что уже закоменело. Причём, это касается не только инфраструктуры, кода или процессов, но и манеры мышления людей.
От себя ещё бы добавил распространённый метод защиты без отношения к какой-либо парадигме - вахтёр. Издалека напоминает парадигму zero trust, только потому что носитель этого метода изначально считает всех сотрудников (а не систему) недостойными доверия. Блокируется всё что можно и нельзя, из-за чего достаётся легетимному трафику (отваливаются некоторые мобильные клиенты и пользователи на старых ОС). При этом за ним сохраняются полные админские права на всё и везде.
двух самых популярных систем контейнеризации: Docker и Kubernetes
Kubernetes это вроде про оркестрацию.
И Docker, и Kubernetes ведут свою родословную от виртуальных машин, которые, в свою очередь, зародились еще в 60-х.
Kubernetes не имеет никакого отношения к родословной виртуальных машин. Вообще. Ближе к управлялкам виртуальными машинами. Говоря про виртуализацию, обычно понимаем гипервизоры с их абстрагированием аппаратной части. Docker тогда больше не про виртуализацию, а про изоляцию процесса в контейнере от остальных процессов в ОС с помощью механизмов ядра. В windows и MacOs как раз виртуализация вместо контейнеров, потому что их ядра не поддерживают эти механизмы.
Jail представляла собой систему виртуализации, позволявшую запускать внутри FreeBSD еще несколько экземпляров FreeBSD, которые использовали то же ядро, но собственное независимое окружение и набор приложений.
Представляла собой изоляцию процесса (песочницу) и внутри клетки не было нескольких экземпляров ОС, которые использовали то же ядро. По своей сути они мало чем отличались от нынешних контейнеров, но управлялись криво. И если бы разработчики не кинулись срочно делать свой гипервизор (виртуалку), может быть сейчас сидели на контейнерах от FreeBSD.
Вот, что вспоминает режиссёр фильма Ридли Скотт: «Она вообще отказалась подтягивать трусики и бриться. В 1979 году нам пришлось заплатить кому-то около 5 тысяч долларов за то, чтобы он удалил все ее рыжие волосы с каждого кадра. На это ушли недели!»
Практически все оконные интерфейсы построены в event-driven paradigm много лет тому назад. С компьютерными игрушками тоже самое много лет тому назад. Практически основа облака Амазон. Их первый сервис был как раз брокер сообщений, а не виртуальные машины. Это совсем не новый, но крайне палезный паттерн в случае микросервисов. Только его надо уметь, чтобы не скатиться в синхронную архитектуру через брокер сообщений, или как ещё назвать))
Практически каждый язык программирования можно рассматривать с точки зрения микроядерной архитектуры - идея для автора))
Советы правильные, советы хорошие, советы нужные и статья честная. Только мы ещё далеко от них. Не смотря на то что ИТ во многих вещах впереди планеты всей, в управлении очень часто наблюдается архаика и принцип "Я начальник - ты дурак". Особенно у нас
Обычно в таких случаях возможна остановка пользовательской виртуальной машины. И с обязательным уведомлением об этом по почте/СМС/мессенжеру. По опыту помню деятельность некоторых клиентов доходила до предупреждений со стороны самого Spamhaus заблокировать наши сети. При этом сам клиент отвечать особенно не спешил на наши обращения. Но никаких резких блокировок не было, тем более удаления.
А вообще эта история напоминает случайное удаление руками или что-то накосячили в скриптах очистки. Ну приплели от себя про скрипты для DDoS-атаки. Такие заявления обычно подкрепляются скриншотами мониторинга, где виден всплеск нелегитимного трафика.
Снова на большую часть вопросов нет ответов, а по факту лишь общие слова про специфику работу предприятий и зависимость от этого специфики DevOps инженера. Только статья изначально про Ситилинк и его внутренние процессы разработки. Про то как и по каким образом искались Рембо и почему имевшиеся DevOps инженеры оказались эникеями. Причём тут металлургическое предприятие?
Было мнение, что "Senior Pipeline developer" на позицию DevOps-инженер, который K8s сам не разворачивал (никогда. Даже для саморазвития), в Linux познания уровня пользователя - это не инженер по практикам DevOps (ведь это методология). Согласен, мнение довольно серьёзное и не лишённое здравого смысла касаемо части Ops. С другой стороны, как обстоят дела у Рембо с частью Dev? Написание башизмов, ролей Ансибла, чартов или манифестов и небольших скриптов автоматизации на питоне это вообще не про Dev.
Вот вам свежая ссылка на личного ассистента почти похожего содержания и перфоманса без подчёркиваний. В ней совсем не про решалу, но требования просто сказка (как раз те самые рабочий день 24/7).
Подскажите, в чём именно у вас выражается торможение микросервисов? Как и какой оверхед они накладывают на сеть у вас? На сколько понимаю, даже простецкий хостер (сугубо для примера) сейчас гарантировано даёт 1 Гб/с между виртуалками. И если смотреть задержки распростанения пакета, то они в пределах милисекунды или даже долей милисекунды
Вот сегодняшний свежачёк
40 лет назад, как раз во времена Андропова, у продавца в магазине была высокая перспектива пойти по этапу. И было за что. Как и не были эти барыги и спекулянты уважаемыми - знаменитый советский сервис.
1 Сейчас интернет завален всевозможными курсами на разных языках и для разных культур. Куча литературы и виртуальных лабораторий. Видеолекций просто тьма. Невообразимое количество дорожных карт по тем или иным направлениям в ИТ. Изучай не хочу. И что качество и уровень разработчиков сильно выросли?
2 Вот нашли талант. Дальше что? Что можете ему предложить? Какие гарантии имеете предоставить? То что он будет завален бесполезной работой? Таланту нужно место для приложения своих умений. Что у нас с такими местами? Ну чтобы без ветрянных мельниц в виде бесконечных отчётностей или постоянных согласований на каждый чих. Чтобы без бюрократии, чинопочитания, местечковой аристократии (госуха), чтобы современные проекты на актуальные темы (не импортозамещение). В сухом остатке толком предложить нечего.
3 С этим вообще непонятно. Предлагаете поиграть в модную игру в западных компаниях, когда нанимаются люди не по знаниям и умениям, а по разнорядкам спускамым сверху. В начале статьи писали чушь про уважаемых с интересными перспективами продавцов в магазинах периода конца коммунизма. Так вот одной из многочисленных причин того развала было то, что набирали на работу согласно партийной благонадёжности и принадлежности, а не по реальным знаниям и умениям. С другой стороны, у нас в вакансиях ИТ пока ни разу не наблюдал требования к полу соискателя. У нас реально можно из-за возраста получить отлуп, а не из-за пола. Или эйджизм это не та проблема, которую необходимо решать?
Не надо прятать за такими высокими фразами реальную проблему. С человечискими ресурсами пока не так уже плохо, но там (на небосводе) постоянно думают об этом. Фундоментальная проблема рынка труда России в острой нехватке высококвалифицированных, образованных, порядочных и ответственных низкооплачиваемых специалистов. Всё остальное демогогия и от лукавого.
Несколько лет наблюдаю за разными группами в мессенжерах и социальных сетях специализированными по поиску работы в ИТ. И складывается впечатления, что мидлы особенно не нужны. Как и не наблюдается острого кадрового голода. Откуда ему взяться вообще, если очень много компаний ушло с рынка, осталась в основном госуха, банки и нефтянка - по сути таже госуха.
Ну вот взяла компания джуна, что с ним дальше делать? На реальный проект его не пустишь одного, сеньора к нему не приставишь, его давно мидлы обложили. Что с ним делать?
Не могу сказать, что прям весь такой ИТ аксакал и больше всех повидал на своём веку, только повспоминав своих и знакомых историй, могу сказать, что 8-10 лет назад было такое же положение дел. Ну разве что рекрутеры звонили на телефон или писал на электронную почту, а не как сейчас в мессенжеры и профили социальных сетей.
С ними иногда бывает крайне забавно. Доходило до того, что напрямую у бизнеса спрашивал, знают ли те, что творят при поиске их сотрудники? А именно:
- резюме без фотографии? сразу в корзину
- на фотографии к резюме слишком фривольно выглядит (присутствует вейп, кальян или вызывающего вида майка) сразу в корзину
- в письме от кандидата только ФИО, название вакансии и приаттаченное во вложении резюме ? Без небольшого описания самого себя или самопрезентации в теле письма? сразу в корзину
И это не мои сказки, это из их жалоб на Linkedin, как им трудно приходится искать кандидатов.
Знакомый практикующий юрист и владелец небольшой юридической компании по совместительству, решил себе сделать сайт и обратился в соответствующие компании, которые занимаются изготовлением сайтов. И вот когда вопрос дошёл до юридической стороны сделки непередаваемому веселью юриста не было предела. Поэтому не стоит надеяться, что в наших Палестинах NDA или его подобие имеет особую силу.
Да, всё так. Иногда даже не от каверзных вопросов, но фундаментальных на собеседовании можно сразу словить минусов в карму.
Мы имеем дефицит высококвалифицированных (с той самй БАЗОЙ) и ответственных и опытных, но низкооплачиваемых специалистов.
Можно своё мнение прибавить, как взгляд с соседней колокольни? По ходу работы постоянно сталкиваюсь с разработчиками и с результатами их труда. Это основная часть моей работы. Сам себя разработчиком не считаю, хотя постоянно пишу тот или иной код (HCL, CI/CD, скрипты автоматизации), изучаю техническую литературу, которая иногда заходит в область разработки. Каюсь, периодически пишу на Go. Этим всего лишь хочу сказать, что совсем не далёк от темы разработки и подробностями, связанными с этим.
Уже который месяц подряд наблюдаю как команда с дюжину разработчиков пытается осилить проект на описываемом языке программирования. И вот что вынес в качестве наблюдений за командой разработки:
Не поверите, многие уверены что функциональный
У нас проект пока в стадии разработки, поэтому пока не до каналов и что с этим связано. Если надо, будем потом необходимое внедрять (с)
Стандартный логгер для некоторых был открытием
Короче, есть GORM, его берём. (с)
На попытки уточнить данный выбор относительно других, был просто проигнорирован. Мало ли чего знаю, им виднее
С большим трудом своей командой протолкнули линтер в CI. Но жить ему там похоже не долго
Ну что за вопросы? Для этого есть специальная команда эксплуатации. И с данным мнением встречаюсь вообще на протяжении многих проектов
Прометей это вотчина девопсов или команды эксплуатации либо мониторинга, если таковая есть
Тут мы попадаем на очень зыбкую почву многопоточности, и всеми связанными с этим познаниями. Что такое поток исполнения, где именно он исполняется и отличие его от процесса. Отдельная тема (неплохо раскрытая Тоненбаумом) варианты реализации многопоточности (в контексте пользователя, в контексте ОС, гибридная). И то что многопоточность и асинхронность это совершенно разные вещи. Но это уже отдельная боль.
И когда по тому или иному поводу (обычно связанному с потреблением аппаратных ресурсов) начинается разговор про потоки исполнения, то выясняется, что для многих они тождественны процессам ОС
Нет классов, наследования, полиморфизма, перегрузки. Очень сильно не хватает точки запятой в конце строк
С плотностью в 13 раз большей подойдёт? Она ещё замерзает при -38.8 и закипает при +356. Раньше довольно массово использовалась в выпрямителях переменного тока электро локомотивов. В одном выпрямителе было около 25 кг.
Вот кому верить? В других статьях по найму пишут с точностью до наоборот: рынок перегрет, мидлы мало кого интересуют, потому что сеньоров невалом, как быть с джунами никто не знает. А есть ещё т. н. "вкатуны".
Не верите? У вас про это в следующем абзаце:
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
И это при конкурсе от 40 человек на место? В описании первого этапа своих собеседований поведали:
И заметьте, про джунов у вас ни слова в тексте нигде. Вы их даже не рассматриваете.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Как это коррелирует с требованием делать резюме компактнее, короче и лаконичнее? Чтобы легко помещалось на два листа. Иначе листать, а тем более читать не досуг и вообще занимает много рабочего времени.
Вот как сделать короткое резюме, например, специалисту уровня senior с такими пожеланиями:
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Стоит ли верить такой басне? Разве на нового специалиста не рассчитывается ФОТ, или счёт полностью открыт и если специалист подходящий, то никаких средств не жалко?
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Круто. А что такое лайфкодинг?
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Позволителен ли кандидату аналогичный шаг, чтобы понять как мыслит руководитель? Вдруг предпочитаемый способ мышления не совпадает или даже полностью противоположный.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
А писали в начале о кадровом голоде, колоссальной нехватке специалистов и что теперь кандидат выбирает работодателя. Кому верить?
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
У рекрутеров скорее всего сложность с выбором резюме, которое будет просмотрено и которое будет выкинуто сразу (неудачники никому не нужны).
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Легко сказать, когда в одном месте пишут одно, в другом противоположное. О многом важом и интересном не пишут совсем.
Верится с таким трудом, что не верится совсем. И тому есть множество примеров ещё совремён царя Гороха, примеры тому высказывания сетования Ивана Кулибина на равнодушие и бюракратизм родимых чиновников и написанное не на пустом месте стихотворение Николая Некрасова.
Если кто-то скажет, что описанные времена прошли, то не совсем так. В одном известном НИИ есть отдельная столовая для руководства, больше похожая по обслуживанию на ресторан, и обычная столовая для челяди, хоть и высокообразованной. Подобных примеров, если постараться, можно привести множество. Поэтому местечковая аристократия, чинопочитание и кумовство живут и процветают. И знаменитое отечественная парадигма мироустройства: "Я начальник - ты дурак!" никуда не девалось.
Поэтому думать и писать о том, что изобретателям и первопроходцам стоит ждать поощрений за их открытия и новации из разряда научной фантастики. Множество комментариев выше тому подтверждение. Как и показательная история с русским Илоном Маском.
Вообще думал ознакомлюсь с чем-то новым и интересным в области хранения и обработки данных, примерные сравнительные цифры увижу, помечтаю о применении, может быть коллегам предложу попробовать. Но даже нигде в тексте не встретил названия хоть одной МБД, относительно которой всё писалось и сравнивалось. Разочарование да и только, как и куча вопросов к тексту и уровню интеллекта целевой аудитории, для которой предназначалься текст.
Нальзя сказать, что традиционные (в данном контексте реляционные базы - РСУБД) хранят данные в виде таблиц. Физический движок хранения у всех разный и представляет данные на носителе по разному и таблицами там мало пахнет. И это не главное. Непонятно другое: какое отношение имеет способ хранения данных РСУБД к основному вниманию уделяемому анализу данных и созданию быстрых и эффективных запросов? Как данные хранятся в МБД и в чём отличие от хранения в РСУБД?
Из курса математики знаю про матрицы, про тензоры слышал, многомерные вектора. Но тут сдаюсь и не могут представить описанную топологию. Картинок по тексту ни одной.
Множество операций в РСУБД побольше будет.
Это в том или ином ввиде размазано и повторяется по всей статье. При этом нет ни слова про какие такие оптимизации идёт речь. Сжатие данных умеют многие базы данных, которые совсем даже не реляционные.
Масштабируемость интересная тема. Какая она в МБД, в чём преимущетво перед РСУБД?
Эх...
Несколько вопросов.
1 куда и как добавляется третье измерение, называемое кубом?
2 можно ли называть реляционную базу многомерной у которой две идентичные по числу кортежей и атрибутам таблицы, только с различающимися данными в ячейках?
А не надо к базе делать сложные и медленные запросы, чтобы терять время необходимое для деловых решений. То что к базе делают сложные и медленные запросы, совершенное не её беда.
Довольно часто по тексту встречается эта фраза, такое впечатление, что МБД агрегируют данные перманентно, и даже когда к ним не делают никакие запросы.
Агрегирование вообще от чего-то зависит? Как и кем решается, что и как будет агрегироваться?
Насколько точен будет анализ после сокращения количества данных? Ничто не мешает сократить количество данных для анализа в любой базе данных для повышения производительности и ускорения времени выполнения запросов.
Вообще текст напоминает статью написанную ИИ с беглым просмотром результата без всяких попыток осмысления написанного. При этом удивляет другое.
Не суть скольки мерное хранилище представляет из себя мозг, какие и как выполняются там запросы. Это не имеет никакого значения, чтобы провести небольшой анализ. Статья по сути никакая. Вообще. Нет ни примерных цифр для сравнения, нет ни одного маломальского рисунка, для удобства восприятия многомерной (вообще, по заголовку расчитывал на размерность большую трёх) структуры базы данных, нет даже названия МБД, которая бралась для рассмотрения. Есть только постоянные увещевания в той или иной форме, что "Важным преимуществом многомерных баз данных является способность быстро агрегировать данные и проводить сложные аналитические операции". Только при этом статья висит в топах, где и приметил её. Что-то мне подсказывает, выложи такое обыкновенный смертный пользователь, а не сотрудник корпаративного блога, плюсов сталье вряд ли столько поставили, может быть и минусов напихали. И в топах ей не светиться.
Хабр, я понимаю, ничего личного -- просто бизнес (не зря домен .com). Только это статья уровня реферата студента кулинарного техникума (отсыл к лирическому образу Г. Хазанова). Что дальше? Сочинения школьников на тему...? Зашквар про ИТ от Дани Милохина?
Windows containers offer two distinct modes of runtime isolation: process and Hyper-V isolation.
Hyper-V isolation - это совсем не про kernel features механизмы: cgroup, namespaces
Хорошая статья. Не смотря на краткость изложения всё понятно и есть над чем задуматься. А именно над тем, что с парадигмами как и с безопасностью надо изначально определяться на начальном этапе проектирования системы. Чтобы потом не было мучительно больно во время инцидента и после, когда по итогам надо передлывать и менять то, что уже закоменело. Причём, это касается не только инфраструктуры, кода или процессов, но и манеры мышления людей.
От себя ещё бы добавил распространённый метод защиты без отношения к какой-либо парадигме - вахтёр. Издалека напоминает парадигму zero trust, только потому что носитель этого метода изначально считает всех сотрудников (а не систему) недостойными доверия. Блокируется всё что можно и нельзя, из-за чего достаётся легетимному трафику (отваливаются некоторые мобильные клиенты и пользователи на старых ОС). При этом за ним сохраняются полные админские права на всё и везде.
Kubernetes это вроде про оркестрацию.
Kubernetes не имеет никакого отношения к родословной виртуальных машин. Вообще. Ближе к управлялкам виртуальными машинами.
Говоря про виртуализацию, обычно понимаем гипервизоры с их абстрагированием аппаратной части. Docker тогда больше не про виртуализацию, а про изоляцию процесса в контейнере от остальных процессов в ОС с помощью механизмов ядра. В windows и MacOs как раз виртуализация вместо контейнеров, потому что их ядра не поддерживают эти механизмы.
Представляла собой изоляцию процесса (песочницу) и внутри клетки не было нескольких экземпляров ОС, которые использовали то же ядро. По своей сути они мало чем отличались от нынешних контейнеров, но управлялись криво. И если бы разработчики не кинулись срочно делать свой гипервизор (виртуалку), может быть сейчас сидели на контейнерах от FreeBSD.
Вот, что вспоминает режиссёр фильма Ридли Скотт: «Она вообще отказалась подтягивать трусики и бриться. В 1979 году нам пришлось заплатить кому-то около 5 тысяч долларов за то, чтобы он удалил все ее рыжие волосы с каждого кадра. На это ушли недели!»
Практически все оконные интерфейсы построены в event-driven paradigm много лет тому назад. С компьютерными игрушками тоже самое много лет тому назад. Практически основа облака Амазон. Их первый сервис был как раз брокер сообщений, а не виртуальные машины. Это совсем не новый, но крайне палезный паттерн в случае микросервисов. Только его надо уметь, чтобы не скатиться в синхронную архитектуру через брокер сообщений, или как ещё назвать))
Практически каждый язык программирования можно рассматривать с точки зрения микроядерной архитектуры - идея для автора))
Иногда проходит испытательный срок и даже несколько релизов, до того как поймёшь с кем на самом деле работаешь
Советы правильные, советы хорошие, советы нужные и статья честная. Только мы ещё далеко от них. Не смотря на то что ИТ во многих вещах впереди планеты всей, в управлении очень часто наблюдается архаика и принцип "Я начальник - ты дурак". Особенно у нас
Помню-помню предки тоже самое предки говорили про первые компьютеры)))
Обычно в таких случаях возможна остановка пользовательской виртуальной машины. И с обязательным уведомлением об этом по почте/СМС/мессенжеру. По опыту помню деятельность некоторых клиентов доходила до предупреждений со стороны самого Spamhaus заблокировать наши сети. При этом сам клиент отвечать особенно не спешил на наши обращения. Но никаких резких блокировок не было, тем более удаления.
А вообще эта история напоминает случайное удаление руками или что-то накосячили в скриптах очистки. Ну приплели от себя про скрипты для DDoS-атаки. Такие заявления обычно подкрепляются скриншотами мониторинга, где виден всплеск нелегитимного трафика.
Снова на большую часть вопросов нет ответов, а по факту лишь общие слова про специфику работу предприятий и зависимость от этого специфики DevOps инженера. Только статья изначально про Ситилинк и его внутренние процессы разработки. Про то как и по каким образом искались Рембо и почему имевшиеся DevOps инженеры оказались эникеями. Причём тут металлургическое предприятие?
Было мнение, что "Senior Pipeline developer" на позицию DevOps-инженер, который K8s сам не разворачивал (никогда. Даже для саморазвития), в Linux познания уровня пользователя - это не инженер по практикам DevOps (ведь это методология). Согласен, мнение довольно серьёзное и не лишённое здравого смысла касаемо части Ops. С другой стороны, как обстоят дела у Рембо с частью Dev? Написание башизмов, ролей Ансибла, чартов или манифестов и небольших скриптов автоматизации на питоне это вообще не про Dev.