Всего найдено: 88
Здравствуйте! Поясните, пожалуйста,профессионально, опираясь на словари и справочники, почему первая часть сложных слов «демо» должна писаться слитно со второй частью? Я знаю, что верно слитное написание, но коллеги утверждают, что равноправен вариант с написанием через дефис. Спасибо.
Ответ справочной службы русского языка
Пишутся слитно сложные слова с первой иноязычной (интернациональной) частью, кончающейся на гласную. Перечень основных таких частей сложных слов с конечным о: авто-, агро-, астро-, аудио-, аэро-, баро-, бензо-, био-, вело-, вибро-, видео-, гекто-, гелио-, гео-, гетеро-, гидро-, гомо-, дендро-, зоо-, изо-, кило-, кино-, космо-, макро-, метео-, микро-, моно-, мото-, невро-, нейро-, нео-, орто-, палео-, пиро-, порно-, психо-, радио-, ретро-, сейсмо-, социо-, спектро-, стерео-, термо-, турбо-, фито-, фоно-, фото-, эвако-, экзо-, эко-, электро-, эндо-, энерго- (см.: Правила русской орфографии и пунктуации. Полный академический справочник / Под ред. В. В. Лопатина. М., 2006. § 117).
Первая часть сложных слов демо- встроилась в этот ряд, слова с этой частью пишутся в соответствии с уже имеющимися в русском языке моделями (демоверсия как аудиоверсия, видеоверсия, киноверсия…).
Добрый день, как пишется видео и фотосъемка (нужен дефис после видео)
Ответ справочной службы русского языка
Висячий дефис нужен: видео- и фотосъемка.
Здравcтвуйте!
Нужно ли выделять запятой выражение «вмеcте взятые» в cледующей фразе: «Ограничение в два чаcа в неделю на вcе экраны(,) вмеcте взятые: кино, телевидение, видео-игры и компьютерные игры.»
Этот вопроc поднималcя на форуме вот тут, но окончательного ответа я не нашла:
http://www.gramota.ru/forum/redaktor/70405/Спаcибо!
Ответ справочной службы русского языка
В справочнике Д. Э. Розенталя «Пунктуация» содержится рекомендация всегда обособлять оборот вместе взятое (во всех формах).
Обратите внимание: первая часть сложных слов видео… пишется слитно (видеоигры).
Здравствуйте, уважаемые сотрудники Грамоты!
Подскажите, пожалуйста, как верно написать онлайн-видеочат или онлайн-видео-чат?
Мы используем в наших текстах вариант «онлайн-видеочат», однако один из сотрудников ссылается на ваш ответ на вопрос № 277036 (онлайн-бизнес-модель) и использует вариант с двумя дефисами: онлайн-видео-чат.
Однако мне кажется, что это не совсем верно, поскольку бизнес-модель изначально пишется с дефисом, а видеочат — нет, и присоединение еще одного слова — не причина ставить дефис в слове, которое пишется слитно. Но допускаю, что я могу ошибаться и здесь действуют какие-то правила, о которых я не знаю.
Спасибо за помощь!
Ответ справочной службы русского языка
Вы правы. Пишется онлайн-видеочат (первая часть сложных слов онлайн- по общему правилу присоединяется дефисом к слову видеочат).
Добрый день!
Подскажите, пожалуйста, верно ли написание ВИДЕООБЪЯСНЕНИЕ?
Насколько я знаю, все слова с ВИДЕО пишутся слитно. А в интеренете пестрят видео-объяснение и видео объяснение. Как все-таки правильно?Спасибо!
Ответ справочной службы русского языка
Правильно слитное написание.
Здравствуйте! Как следует писать слово «видеоконференцсвязь»? Спасибо.
Ответ справочной службы русского языка
Правильно: видео-конференц-связь.
Здравствуйте!
Подскажите, пожалуйста, как правильно писать слова «фото-контент», «видео-контент» — слитно, раздельно или через дефис?
Имеется ввиду контент интернет-ресурсов, когда наравне с тектовой информацией пользователи выкладывают свои фотографии и видео.
Заранее спасибо.
Ответ справочной службы русского языка
Верно: фотоконтент, видеоконтент.
Здравствуйте! Подскажите, как пишется «фото-видео-галерея» ?
Спасибо!
Ответ справочной службы русского языка
Правильно: фотовидеогалерея.
Здравствуйте!
Подскажите, пожалуйста, как правильно писать:
видео-трафик
или без дефиса:
видео трафик?
Заранее большое спасибо!
Ответ справочной службы русского языка
Верно слитное написание: видеотрафик.
Как пишутся слова, в составе которых присутствует слово видео (видеосвязь, видео-мероприятие, видео-звонок и т.п.)?
Ответ справочной службы русского языка
Верно слитное написание: видеосвязь, видеозвонок, видеомероприятие.
Далее демонстрируется ряд коротких, но обладающих большой силой (???) видео-фрагментов.
Нужна ли здесь запятая? Какое правило применить?
Ответ справочной службы русского языка
Для постановки указанной запятой нет оснований. Слово видеофрагмент пишется слитно.
Здравствуйте, подскажите, пожалуйста, как правильно пишется: видео открытка, видео-открытка или видеооткрытка?
Ответ справочной службы русского языка
Первая часть сложных слов видео… пишется слитно: видеооткрытка.
Как правильно / целесообразно писать недавно появившееся слово «видео-ремаркетинг»?
Ответ справочной службы русского языка
Первая часть сложных слов видео… пишется слитно с последующей частью слова.
Правильно ли написание слова аудио/видео-оборудование (как вариант, A/V-оборудование)?
Ответ справочной службы русского языка
Корректно слитное написание: аудиовидеооборудование.
Доброго времени суток!
Скажите пожалуйста, как правильно писать: «видеоинтервью» или «видео-интервью».Буду благодарен за скорый ответ!
Ответ справочной службы русского языка
Правильно: видеоинтервью. Первая часть сложных слов видео… пишется слитно.
Первая история: Jaskell
Мне рассказывали когда-то о компании, которая писала бекенд на Java и хотела нанимать талантливых разработчиков. Чтобы привлечь их, эта компания размещала вакансии на Haskell, и потом уговаривала этих кандидатов все-таки писать на Java. По-моему, это не очень красиво (вешать ложное объявление — нехорошо), но нас сегодня интересует сама идея, лежащая в основе этой тактики: толковый разработчик важнее, чем стек, которым он пользовался в последнее время.
Вот небольшое видео, иллюстрирующее эту идею:
Вторая история: Kotlin
Когда мы нанимали разработчиков в проект Kotlin, мы не могли ограничиться только теми, кто уже разбирался в разработке компиляторов. На рынке было просто слишком мало таких людей, а наш проект еще не имел мировой известности. Тогда я и начал учиться распознавать на собеседованиях тех, кто сможет разобраться на месте и будет двигать проект вперед, хотя раньше работал в другой сфере.
Это оказалось не так-то сложно: все-таки любой программист пользуется каким-то языком программирования каждый день, и на собеседовании можно поговорить про то, как все это работает внутри. Любознательные инженеры знают, как устроены их любимые игрушки, так что с темами для разговора проблем не было.
По сути, мы брали в Kotlin тех, кто хорошо понимал не как работает компилятор, а что такое виртуальная машина, как устроены блокировки потоков в ОС, как устроены структуры данных, которые любой из нас использует каждый день и т.д.
Со временем Kotlin стал известным и успешным, и нам стало проще нанимать людей с профильным опытом. Они принесли в команду очень ценные знания, и мы все вместе сделали крутой востребованный продукт. Но по сей день, насколько я знаю, опыт именно в компиляторах не является обязательным условием для найма в Kotlin.
Из этой истории у меня два вывода:
-
Бывают условия, при которых выгоднее брать просто толковых разработчиков, а не специалистов в узкой области.
-
Специалисты в узкой области дают большой буст, и их обязательно надо тоже нанимать.
Третья история: Alter
Сейчас мы нанимаем разработчиков в Alter. Тут мы не компиляторы пишем, а платформу для психотерапии. Ничего особо экзотического: Python, Django, MySQL, вот это все. Каждый день помогаем сотням людей.
А принципы найма остались те же: мы упоминаем стек в описании вакансий только в разделе «Будет плюсом, но необязательно» потому, что кандидатам хочется знать, на чем написан проект. Не было ни одного кандидата, которого мы не стали бы рассматривать из-за стека.
Но почему-то мы время от времени слышим от знакомых и знакомых знакомых: «а вот я хотел(а) к вам в команду, но я на Java пишу, а у вас Python». Так я и решил написать этот пост.
Важные оговорки:
-
Мы нанимаем опытных разработчиков (Senior и Middle), учить с нуля нам не выгодно. Когда берем Middle, следим, чтобы был потенциал роста до квалификации Senior. Если кандидат застрянет на уровне Middle навсегда, в небольшой команде такой разработчик не очень нужен.
-
На собеседовании мы обсуждаем вопросы, общие для всех бекендовых стеков: как работает HTTP, что делать, чтобы сервис держал нагрузку, как проектировать схемы БД, как искать и устранять ошибки и т.д.
А зачем вообще так делать? Вам что, питонистов не хватает?
Если вам хватает, мы за вас рады 
Делать так стоит, только если затраты на поиск разработчиков на нужном стеке превышают затраты по онбордингу в этот стек. Ясное дело, если у вас очередь отличных специалистов, которые вдоль и поперек знают какую-нибудь Django (или на чем там у вас бек), то вы не будете смотреть кандидатов с опытом на FastAPI, PHP, Java и т.д. А если вы из десяти кандидатов скрепя сердце готовы взять одного, а он вам говорит, что неделю подумает, потому что у него тут еще три оффера намечается, то, наверное, вам имеет смысл подумать, как расширить воронку.
И, судя по общению с коллегами из других компаний, ситуация большинства работодателей в последнее время больше похожа на второй вариант.
То есть фундаментальная идея проста: человек, хорошо освоивший один инструмент, быстро переучится на другой, достаточно похожий. Если опытному человеку сложно освоить новый стек, то он, вероятно, достиг своего потолка, а это не очень хороший знак. Это дает нам возможность нанимать толковых программистов со всего рынка, а не только с некоторой его части.
Еще один момент, хоть и не такой важный: если кандидат выбирает компанию, а не стек, можно предположить, что он будет больше мотивирован в этой компании и оставаться, а не перейдет через полгода в другое место. Мелочь, а приятно.
Это как у Джоэла: Smart and gets things done?
Еще в 2006 года Joel Spolsky писал в своем The Guerrilla Guide to Interviewing (version 3.0), что достаточно знать о кандидате две вещи: толковый и доводит дело до конца (smart and gets things done). Зачем же тогда этот пост?
Во-первых, многие, и особенно кандидаты, до сих пор верят, что стек — это первый фильтр, по которому отсеиваются вакансии и резюме. Мне бы хотелось, чтобы больше людей понимало, что это далеко не всегда так.
Во-вторых, если ограничиться «smart and gets things done», онбординг может оказаться существенно дороже, чем если брать человека, который решал похожие задачи, просто другими инструментами. Так что мы для себя считаем, что бекендер-джавист превращается в бекендера-питониста как на том видео выше, а вот что там насчет других специализаций — это уже сложный вопрос, который в каждом конкретном случае надо решать индивидуально. Массовому читателю я готов рекомендовать только быстрый онбординг в другой стек, не в другую специализацию.
А всегда ли это так хорошо работает?
Как уже было сказано выше, главное, о чем нужно подумать: окупятся ли затраты на онбординг. При этом надо учитывать несколько существенных моментов.
Не любой разработчик захочет поменять стек
-
Кто-то привязан душой к своему любимому фреймворку и ни за что не «предаст» его. Ну, это не наш клиент, что делать.
-
Кто-то боится, что не справится быстро освоить новый стек. Даже если вокруг будут отзывчивые коллеги, готовые подсказать. Ну, имеет право, тоже не наш клиент.
Некоторые стеки отличаются сильнее, и между ними переход значительно тяжелее
-
Как правило, это связано с тем, что и задачи надо другие решать: если вчера писал обычный бек на PHP, а завтра надо делать highload на Java, онбордиться будет сложновато.
-
Некоторые платформы/проекты до сих пор используют более низкоуровневые абстракции. PHP, Node.js и Python более-менее избавляют от необходимости думать о тредах, а в Java при желании можно этого счастья хлебнуть ого-го сколько. Это зависит от того, как написан ваш Java-проект. Не надо ожидать, что онбординг питониста в мультитрединг будет таким же легким, как онбординг джависта в Django.
Чтобы быстро поменять стек, надо хорошо понимать основы
-
Если кандидат не очень уверенно пользуется своим основным языком программирования, то и новый ему осваивать будет не просто
-
Если HTTP-заголовки или SQL для кандидата — темный лес, тут не до смены стека
-
Если кандидат совсем не понимает, что его любимый фреймворк делает под капотом, ему будет сложно освоить новый фреймворк, который делает под капотом что-то другое
Команда должна помогать осваивать новый стек. Одно дело учиться самому, другое — когда вокруг сидят люди, которые знают новый стек вдоль и поперек. Только нужно, чтобы знания передавались, а для этого важно:
-
Поощрять вопросы и запросы на ревью
-
Быстро отвечать на вопросы, чтобы разблокировать товарища (если вопросы выглядят моментально гуглящимися, дружелюбно спросить в личке, в чем дело)
-
Вежливо и аргументированно подсказывать идиомы и разные фишечки на code review
-
Не ругать стек, с которого человек пришел, за недостаточно православное мировоззрение
Получается, для джунов этот подход не работает?
Тут как посмотреть. С одной стороны, для быстрого освоения нового стека надо хорошо знать старый, а Junior еще не успел в нем толком разобраться. С другой стороны, если ты и старый стек не очень знал, много ли ты потерял, пересев на новый?
На самом деле с Junior разработчиками вопрос вообще лежит в другой плоскости. Далеко не всем командам в принципе имеет смысл брать неопытных людей. То есть, если честно, скорее всего на предложение «нам трудно искать синьоров, давайте наберем джунов и доучим на месте», ответ: «отличная идея, но нам это не выгодно».
Не буду тут углубляться в анализ, но в целом понятно, что за обучение джунов вы платите не только их зарплатой, но и большим количеством внимания, которое их обучению уделяют более опытные разработчики. А они в это время могли бы двигать проект вперед. Ясно дело, что бывают очень бодрые джуны, которые учатся супер-супер быстро, и тогда их учить мега-выгодно, но если вы уже умеете нанимать таких джунов, то вы, наверное, или в хорошем ВУЗе преподаете для души, или у вас такие бюджеты на хайринг, что вам этот пост не очень интересен.
А разве смена стека — это не шаг назад в карьере?
Рекрутеры, а иногда и кандидаты, говорят: если я перейду на новый язык/стек, я в нем не буду таким профи, как в своем привычном языке/стеке — это ведь я стану менее ценным специалистом!
Честно говоря, мне немного грустно от такого подхода к жизни, но я стараюсь отнестись с пониманием и ласково объяснить, что
-
синтаксис языка выучить — это только в первый раз сложно, а третий-пятый язык уже учится гораздо легче,
-
твоя ценность как специалиста состоит не в том, что ты знаешь синтаксис языка и название стандартных функций фреймворка, а в том, что ты понимаешь, как система должна работать и в деталях, и в целом,
-
изучение нового иногда дает свежий взгляд на знакомые вещи, а это приносит многим людям удовольствие.
Вопрос в зал
А вот как вы думаете: для фронтэндеров это тоже работает? Мы пока пишем в своих вакансиях, что нужен опыт на React.js, но, может, зря мы так делаем?