Pull to refresh
1
0
Сергей @Chelyuk

User

Send message

Просто не берите принтеры Canon. С остальными проблем не помню.

Я остановился на среде Mate и Linux Mint.
Долго сидел на KDE, но после того как упёрся в его баг с тайлингом по хоткеям на цифровой клавиатуре. Оставил все попытки. 10 лет никто не хочет это починить. А я уже не могу без перекидывания окон на пол экрана или на другой монитор.
Gnome давно не понравился. Из коробки многое не работает, нужно допиливать постоянно из консоли или фиксить.
Когда покупал последний компьютер под Линукс, остановил выбор на AMD и Radeon. Помнил долгие муки с драйверами лет 15 назад под ATI. И был приятно удивлён увидеть видео теперь прямо в ядре.
Для игр придётся по-прежнему многое таскать для починки звука и видео, особенно для старых игр без поддержки FullHD. Если не хочется, есть всем известный трекер. Там игры вместе с собранным и настроенным под конкретную игру wine идут.

Так-то оно так. Но если двигаться в этом направлении. То практически всё сегодня многопоточно. Потому что процессоры многоядерные и зачастую мультитредовые. Тогда можно поставить гипервизор, развернуть N операционных систем, поднять в них любую среду и написать приложение которое будет в этом всём работать. Ну или просто какой-нибудь Kubernetes развернуть. Только всё это будет сделано вовсе вовсе не средствами языка программирования. И некоторые операции станут сильно дорогими в плане времени.

Что-то наблюддается некоторая мешанина терминов. Мне вот всегда было непонятно это стремление ссылаться на всякие странные сайты. С одной стороны там есть некая агрегация данных и знаний, с другой стороны, каждый использует своё видение видов, уровней, техник и методик тестов. Есть ISTQB и RUP. Чем они не угодили? Почему нельзя использовать их терминологию. Она хотя бы общепринята. Выделение тестирования изменений в одном уровне с функциональным и нефункциональным тестирование - крайне странно. Тестирование изменений ровно также включает функциональное и нефункциональное тестирование. Является общим множеством smoke, sanity & regression. Обычно виды тестов делят принципиально на функциональные и нефункциональные. А дальше внутри идёт ветвление которое спрашивать наизусть полностью не имеет смысла. Я обычно просто спрашиваю примеры.

Это не совсем рынок так устроен. Это так устроен круг людей проводящих технические собеседования. Которые иногда просто спрашивают то что нравится им самим, или просто находят вопросы в интернете. А кандидаты также находят ответы на эти вопросы. Всё таки нужно больше стараться отталкиваться от конкретной позиции, конкретного состава команды и продукта. Но как говорил один боксёр:"Все, но не каждый" могут так делать.
В реальности фреймворк на проекте поднимается 1 раз, ну может 2. Это не то знание, которое будешь применять каждый день. Для этого достаточно открыть документацию, прочитать, осознать и применить. Вот этот навык куда важнее, знания наизусть информации, которая и так всегда под рукой. Вот работу с git, ревью, составление тестовых сценариев, работа с тестовыми данными, просмотр результатов, триаж и починка CI - это действительно то что применяется каждый день.
Кроме того, надо понимать домен в котором работаешь. У меня на одном собеседовании волосы дыбом вставали. Когда спрашивали по Python перечни базовых методов, магисеские мотоды классов, декораторы и т.д. Когда я спросил зачем, то получил ответ который меня ввёл в ступор. Потому что обычно идут путём привлечения девеелоперов для написания моков и стабов и возможно базовых методов взаимодействия тест фреймворка с продуктом. Но тут решили что тестировщики должны помочь девелоперам переписать продукт под новую версию Python.
Но интервьювер вообще не принял в рассчёт одну такую маленькую деталь. Что продукт был медицинским. А тут по стандарту не могут быть никаких смешений взаимодействия разработчиков и тестировщиков. В идеале - это вообще должны быть люди из разных организаций с максимальным уровнем независимости на принятие решений.
Ну найдут они подходящего кандидата по соображениям тех интервьювера. Но при сдаче проекта внезапно осознают, что всё сделанное нужно переделать. Потому как FDA такую халтурку в жизни не пропустит, когда код писал и полностью тестировал один и тот же человек.
Так что сейчас есть наглядная проблема больших контор которые подводят унификацию требований для кандидатов сами не осознают область на которую эту унификацию стоит и можно расспространять.
Всё таки в идеале, интервью должны проводить люди имеющие прямое отношение к конкретному проекту. А сейчас получаем в большинстве случаев - когда интервьювер, в лучшем случае, получил строк 20 описания проекта. Пришёл проводить интервью, потому что за эту активность можно получить некий бонус. И задаёт вопросы, которые весьма интересны с точки зрения погружения в глубины языка. Но ответы на которые можно будет благополучно забыть ровно до следующего интервью.

Спрашивать-то, спрашивают. Только толку от этого. Вот сколько раз потом на практике понадобилось писать код маркером на доске?
Сколько проектов по тестированию требуют глубоких знаний базовых методов языка?
Куча проектов по поддержке, где вся работа сводится исключительно к написанию новых тестов и выпишиваеию старых. Кстати, я бы сказал они именно идеальная среда для начала карьеры. Есть куча примеров и можно по разбираться на текущей базе кода как всё работает. Никаких гарантий, что это будет наилучший вариант. Но для базы, понимания архитектуры фреймворка и базовых слоёв подойдёт.
В тестировании нэгораздо больше пользы от понимания тест фреймворков, их возможностей и ограничений.
Некоторые фреймворки вообще ломают логику базового языка.
Например, работа с Selenium в Python, всё равно превращает код в JAVA образный.
Поэтому лучше знать тестовые фреймворки и как их интегрировать. Почему Cypress подойдёт для тестирования онлайн магазинов, но не сложных бизнес приложений. Чем Playwright лучше Selenium. Чем так хорош pyTest и как его осилить после jUnit и TestNG. Как тесты параллелизировать и с какой CI.
Почему Azure в минимальной подписки не имеет смысла. И т.д.

Я вам блольше скажу. Алгоритмы, нынче, даже у тестировщиков на собеседованиях спрашивают.

Человек всегда выбирает на что тратить своё время. В маленьком городе - больше времени на себя, семью, но вероятно меньше зароботок. В большом городе - больше зароботок. Но нет времени самому приготовить себе обед, погулять с ребенком и в целом провести время с семьёй. И эти пробемы создают не технологии, а всё та же проблема плотности начеления и пробок. Либо ты будешь тратить 15-20 минут похода на работу пешком. Либо 2-3 часа сидеть в пробках в автомобиле, а потом пытаться выкроить время для спорзала. А все эти технологии - это лишь средства удовлетворить запрос конретного общества в конкретных условиях.

Каршеринг, всё таки несколько снижает транспортную нагрузку хоть и косвенно. Такие авто - меньше простаивают, а значит в случае приехал на работу и нет частной парковки, такое авто будет меньше занимать крайнюю полосу там где парковка допустима. Хотя, конечно общественный транспорт справляется с этой задачей намного лучше. Так же хорошо справляются электроскутеры, которые мопеды. Но это вещь тоже сезонная.

Что-то много недосказанности. А как же сторона DevOps и тулов?
ИМХО - мидл, должен хорошо знать техническую предментную область - язык программирования, паттерны, архитектуры - это всё легко учится из теории. А старшой - должен уже обладать более широкими софт скилами, знать разницу гибких и строгих методологий. И главное уметь плясать от продукта, а не от того что он умеет. Не совать везде - я так 20 лет он-лайн магазины писал и UI на приборку авто так же буду делать. А уметь выбрать оптимальную методику, архитектуру, паттерны. Уровень документации от самодокументируемого кода, до Detailed Design, Software&System Architecture документов. Объяснять мидлам и джунам, почему их супер-навыки в Vim в данной команде будут только во вред и что он не просто так потратил время на конфиг для IDE и настроили pre-commit git hooks. И сколько дрвгоценного времени это экономит. Ну и опять же это всё если проект для команды или нескольких команд. А если проект на 2 недели на коленке в одно лицо что-то состряпать. То тут не стоит убиваться и поднимать CI/CD на 4 энвайронментах. И писать конфиги, ревью чек-листы и архитектурные документы.

Даже если исключить финансовое неравество. У жителей мегаполисов и меньших городов - разные запросы и потребности. В мегаполисе сложно без авто добраться до работы, кинотеатра, любимого ресторана и т.д.
В маленьких городах - это зачастую довольно просто сделать пешком. Кроме того улицы не столь перегружены автомобилями, поэтому собственный автомобиль доставляет больше радости.
Вот еду можно заказывать одинаково. Хотя в целом, чем меньше город, тем размереннее ритм жизни.
Поэтому для скорейшего возврата инвестиций сервисы и откатывают в районах с большей плотностью населения, а значит упрощенной логистикой, большим колличеством потенциальных клиентов и более высокой платежеспособность. В меньших городах, даже при равной плетажеспособности, люди реже будут пользоваться такими же сервисами, просто потому что не нужно.
До 1991 года города строились по принципу пешей доступности, чтобы людям не нужен был личный автомобиль, всё необходимое можно было получить пешком, школы, детские сады, магазины, рынки, поликлиники. В остальных случаях общественный транспорт всё решает. Даже время работы практически всего в городах разное. В небольших, практически всё открывается к 8 часам утра. В крупных даже детские сады и школы могут начинать занятия в 9-10 часов. Потому что иначе просто не успеют родители привезти детей через пол-города по пробкам, а сотрудники также не успеют на работу. Но и заканчивают в малых городах к 4 часам после полудня. А в мегаполисах вполне нормально работать до 7-8 часов вечера. Современный мегаполис - это страшный микс устаревающих районов с пешей доступностью всего, непонятного хаоса застройки на протяжении 20 лет. И потом опять вернулись к комплексной застройке с сервисами в пешей доступности на территории ЖК. В меньших городах за те самые 20 лет не строилось практически ничего за редким исключением.
В сёлах, опять же другая картина, там без авто никто не живёт практически из за больших растояний.
Но и там картина изменилась, всё меньше людей живут с подсобного хозяйства. И всё больше живут обеспеченные люди, которые могут себе позволить и дом побольше и соответственно и автомобиль или 2-3 на семью. Они опять же вряд ли будут пользоваться каршерингом, а предпочтут купить в личное пользование.
Например, как выглядит доставка продуктов в Греции в городке с населением 4-5 тысяч. Просто в определённое время один и тот же фермер едет на своём грузовичке, останавливается каждые 500 метров. К нему выходят люди и покупают необходимые им продукты. Зачем им отдельный сервис доставки? Ну и размеры города - таковы, что за 10 минут его можно полностью пройти пешком.

Поднять локальное зеркало репозитория пакетов и прописать настройки на него.
Как никак все менеджеры пакетов должны их откуда-то скачивать.

Патенты вышли и сейчас идёт активный бум на рынке. Год назад участвовал в проекте нового робота от Medtronic. Самая интересная часть не раскрыта, синхронизация времени между кучей нод в устройстве. Особенно, учитывая, что далеко не все они используют RTOS. Как правило на консоли хирурга все таки не QNX.

Тут всё несколько глубже. DevOps - человек, растёт из того же места, что и модное заблуждене под названием SCRUM. В котором из ролей всего ничего Product Owner, Scrum Master и Scrum Team. И все равно, что в этот Scrum Team нужны: разработчики, тестировщики, бизнес-аналитики, дизайнер ...

К чему это я всё? А к тому что это классная абстракция-прослойка удобная для рубахи парня - менеджера. Недавно вычитал на просторах, как бедным менеджерам без технического образования и бэкграунда тяжело живётся разбираясь между всеми этими разношёрстными трудягами из-за кого не попадают сроки или упал прод. И мол вот она серебрянная пуля - а мы скажем, что нет между ними разницы и помогут нам тут SCRUM и DevOps. И сразу жизнь у менеджера стала сладкая, сразу понятно у кого перфоманс просел. И руководить сразу проще стало, а что SCRUM ведь про self-organized team. Так и появились мифы о Universal Soldier(aka Cross-functional Team) и DevOps - человек.

Лучшая ложь - это та, в которой есть примерно 15% правды.

"Половина - не бывает большей или меньшей. Но, к сожалению, большая половина класса этого не понимает." (с)

Если статьи пишутся для зачёта - это печально. Как вариант для статей необходимых перед защитой магистерской работы - думаю должно иметь право на жизнь. Habr - довольно уважаемый ресурс, полагаю лучше многих "изданий", которые печатают статьи без редакции и пруфридинга.
Возможно в этом и кроется разница в качестве статей. Смотря какую задачу решали студенты, допуск к защите или один из многих зачётов.

Молодцы конечно, но выглядит как микроскопом по гвоздями. Ключевая проблема - заказчик постоянно меняет требования. Я понимаю,когда речь в рынке и необхомисти перехода с ДВА на электромотор. Но когда так поступает внутренний заказчик, это прямой вопрос к его компетенции в коммуникации. Зачем терпеть кучу не компетентные людей в компании и исключительно в угоду им устраивать дорогую смену процессов? Смена 20 десятков людей на более компетентные и умеющих думать наперед даст ещё больший эффект,за гораздо более скромные вложения.

И ещё вопрос если нужен был Enterprise Agile + Scrum, почему не SAFE или Nexus SCRUM?

Вот есть пару моментов в которые верится с трудом.

  1. Что будет с камерами, если их заслепят криво настроенные встречные или дальним на подъёме?

  2. Камеры на столько крутые что уже отличают картинки от реальности? Это в Европе хорошо, рекламой дороги не усыпаны. А у нас можно увидеть огромные рекламные щиты в десять метров от дороги. А если там повесят рекламу с другой дорогой или еще чем.

  3. Есть еще весёлые фигурки школьников возле пешеходных переходов. Тут конечно и радары с лидерами не спасут, но очень интересно как Тесла себя поведёт.

Просто нужно найти того кто будет готов платить за твои навыки в том что тебе нравиться. Сложно найти в своей стране, ищи в другой. Это требует времени, навыков в коммуникации и изучения иностранных языков. Так что это действительно не проблема программирования, это проблема людей, которые готовы ради сиюминутных денег угробить свою жизнь, семью, карьеру. Это просто очередной карго-культ. Редко заканчивается чем-то хорошим для участников культа. И может непредсказуемо выстрелить в окружающих. Сейчас это в основном усложняет жизнь HR, где так уж совпало тоже оказалось много желющих, без понимания что они там делают. Поэтому необходимо просматривать в N раз больше резюме и примерно во столько же раз больше проводить собеседований. Иногда, правда, некоторые личности всё равно просачиваются и могут стать проблемой для ряда проектов. Правда это чаще связано с менеджментом пришедшем в IT нежели с программистами/тестировщиками/аналитиками. Нескольких человек технических можно нейтрализовать или разбавить грамотными. А вот 5 менеджеров на проект не поставят, чтобы нейтрализовать 1го не особо компетентного.

АСУТП пошло путем создания своих языков, потому что все остальные языки программирования возникли позже. Тут смысл был дать возможность программировать технологам и инженерам, потому что слова программист тогда еще даже толком небыло. А когда появилось, таких людей было крайне мало, чтобы обслужить всю промышленность. Как должен был данный инструмент быть создан для людей которых еще не существовало?
SCADA тут конечно несколько сбоку, но отрасль накладывает свой отпечаток. Изначально для отображения использовались картонно-деревянные стенды с лампочками и цифровыми блоками. Вероятно, они были даже более читаемые, менее вредные для зрения, и даже возможно красивее интерфейсов особенно на первых дисплеях. Когда производство дисплеев стало дешевле, чем работа напильником по дереву, стали ставить дисплеи и изобрели SCADA системы для отрисовки всего того с чем прекрасно справлялись стенды из картона или дерева с лампочками. Собственно инструмент создавался для людей которые уже работали на производстве и создан намеренно просто, чтобы не требовалось дорогостоящее переобучение персонала. Вероятно сейчас стоит пересмотреть данную парадигму, потому как программисты уже не такой дефицит и скорее инженеров способных разобраться в релейных схемах или хорошо оперирующих элементами Буллевой логики найти будет посложнее.

Information

Rating
4,327-th
Location
Киев, Киевская обл., Украина
Date of birth
Registered
Activity