Русский
Русский
English
Статистика
Реклама

Программисты

Интервью с Дарреном Мерфом, руководителем удаленной работы в GitLab

22.07.2020 16:08:14 | Автор: admin


Даррен Мерф заведует всей дистанционной работой в GitLab, самой крупной в мире полностью удаленной компанией. Он занимается наймом сотрудников, их адаптацией, созданием рабочей культуры, поддержкой общения внутри команды (1300 человек!) и ещё многим другим. Мерф один из главных в мире сторонников удаленной работы. Он руководил десятками удаленных команд, составлял схемы перехода на удаленку для стартапов и крупных корпораций, работал во всех типах удаленных фирм, написал популярный гайд Remote Playbook, ну и сам уже 14 лет работает из дома.

В это странное и тяжелое время, требующее реорганизации для сотрудников и работодателей, Даррен провёл AMA через Slack. А мы в Rubrain собрали и перевели 10 лучших вопросов и ответов.

Вопрос 1 тренинги


Привет, Даррен! Мне интересно, есть ли у вас какие-нибудь ресурсы для наших HR, чтобы им было проще перевести свои тренинги по адаптации (особенно для новых членов команды) в дистанционный формат?

Даррен Мерф:

Да, это сложная задача для компаний, привыкших к найму и ориентации новых сотрудников лицом-к-лицу. Лучший совет, который я могу дать пусть все новые сотрудники в компании получают онбординг-товарища. Человека, с которым они могут связаться через Slack или Zoom каждый день, с любым вопросом. Это даёт им одну точку контакта, так что им не приходится думать, с кем связаться, и они не беспокоят всю компанию. Плюс это помогает им быстрее влиться в организацию, завести друзей, начинать чувствовать себя как дома. Вот как этот концепт онбординг-товарищей реализуется в GitLab: https://about.gitlab.com/handbook/general-onboarding/onboarding-buddies/.



Вопрос 2 перегорание


Что можно сделать, чтобы люди на удаленке не перегорали за несколько лет? Мне кажется, это большая проблема, и даже за эти несколько месяцев эффект уже ощущается. Я боюсь, что со временем результативность работы нашей команды программистов может сильно упасть.

Даррен Мерф:

Спасибо за отличный вопрос!

Если вы сразу нанимаете в команду разработчиков, которые хотят работать удаленно, проблема сама решает себя. В GitLab эффективность удержания сотрудников составляет больше 85%, потому что к нам приходят именно те, кто обожает трудиться из дома.

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

  • Обязательно создайте место для общения. Например, хорошо подходит лобби в Zoom, работающее 24/7, где люди могут собираться, общаться, болтать после дня (если им это нужно), прямо как в реальном пространстве офиса.
  • Подумайте о еженедельных/ежемесячных играх, шоу талантов, викторинах, общих сессиях игр/музыки/караоке. На прошлой неделе у нас проходило шоу талантов на 135+ человек с шести континентов, с судьями и призами. Было очень весело.
  • Создайте Slack-каналы для нерабочих вещей. Хороший канал с новостями, забавные видео котов-собак, канал для родителей, канал для фитнеса и так далее. Специально создавайте пути для появления дискурса внутри команды.

Большой гайд GitLab о том, как создавать возможности для неформального общения внутри команды, у нас здесь: https://about.gitlab.com/company/culture/all-remote/informal-communication/

Вопрос 3 культура


Привет Даррен, спасибо, что решил ответить на наши вопросы. Как GitLab умудрилась вырасти в компанию на 1300+ сотрудников, и всё равно сохранить свою культуру? Есть ли у тебя совет для стартапов или других фирм, которые постоянно растут, и постепенно теряют свою идентичность?

Даррен Мерф:

Хороший вопрос.

Если вкратце задокументируйте вашу культуру. Задокументируйте ваши ценности. Сделайте раздел на сайте, где каждый может о них почитать. Ценности масштабируются бесконечно, они не зависят от размера компании. Культура это не ощущение и не атмосфера. Это универсальные ценности, Полярная звезда, которая видна из любой точки земного шара и помогает вам направлять все бизнес-решения, большие или маленькие. Посмотрите, как детально ценности расписаны у GitLab. Это не 5-6 слов. Это тысячи слов, в подробностях описывающие, как мы поступаем в той или иной ситуации.


Удаленное собрание руководителей GitLab

Вопрос 4 вакансии


Даррен, мне нравится работать удаленно, но опыта пока мало. Возможно ли, что к концу 2020 года вакансий под такой труд будет больше из-за коронавируса, и вакансий тоже станет больше?

Даррен Мерф:

Гарантированно. Мир больше никогда не загонит этого джина обратно в бутылку. Глобальное распространение удаленных технологий из-за Covid-19 ускорилось как минимум на 10 лет. Мы прыгнули вперед. Все цифровые компании в мире, даже в тех местах, где офисы не закрыты, сейчас строят удаленную инфраструктуру. Разбился старый миф о том, что эту работу нельзя делать из дома.

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

Вопрос 5 старые компании


Есть ли у тебя идеи, почему некоторые компании настолько против удаленной работы? И даже против гибкого графика, позволяющего сотрудникам быстро переходить от работы из дома к работе в офисе?

Даррен Мерф:

По моему опыту, причина сопротивления чаще всего одна из этих трёх:

  • Часть бизнеса требует аппаратного обеспечения или производства, поэтому руководство уверено, что компания не может работать удаленно. Игнорируется факт того, что маркетинг, связь, финансы, HR, разработка и многие другие департаменты на удалёнке на самом деле показывают более высокую производительность. Проблемой становится мышление всё или ничего. Если какая-то часть фирмы не может работать удаленно, значит, и все остальные будут такими же.
  • Нормы. Часто дело просто в традициях. Компания развилась и стала успешной на предыдущей модели ведения бизнеса, поэтому руководители не хотят менять модель, адаптируясь под новые реалии. Они не знают другого пути и не хотят его изучать. Проще бороться с введением удалёнки, чем развиваться и становиться эффективным удаленным менеджером. Это именно проблема возрастных компаний, чаще всего команда стартапа таким страдать не станет.
  • Плохой опыт. У некоторых компаний был неудачный опыт попытки в удалёнку 10 лет назад, и теперь они предполагают, что всё удаленное автоматически плохо, и что работа так не пойдёт. Они не понимают, что с тех пор изобрели Slack и Zoom, мобильный интернет почти универсальный, Wi-Fi есть у каждого в доме и в любом ближнем кафе, а текущее поколение работников уже не могут представить свою жизнь без интернета. Мир прошел огромный путь за эти 10 лет, но многие этого не заметили. Чтобы вы представляли, 14 лет назад я работал на 6,5-килограммовом ноутбуке, заряд которого длился всего 20 минут. Сегодня удалёнка в тысячу раз проще.



Вопрос 6 смена карьеры


У меня больше 7 лет опыта сисадмином, теперь изучаю DevOps. Но не могу найти работу. Получается, что я сменил карьеру, и мой прежний опыт не засчитывается? Мне сейчас очень нужна удаленная работа.

Даррен Мерф:

Моя карьера тоже не прямая линия. У меня степень магистра по бизнесу, я работал журналистом, PR-агентом, в коммуникациях, разрабатывал стратегию для журнала о путешествиях, теперь работаю в GitLab. Предыдущий опыт не аннулировался. Главное показать свою ценность в интервью. Вы больше, чем кусок бумаги. Просто нужно, чтобы кто-то за другим концом стола дал вам возможность это показать.

Мой совет это продолжать учиться, и запастись терпением. Как-то я был 6 месяцев без работы, и, по ощущениям, это было 100 лет. И это с большим портфолио удаленной работы! Может быть, вам придется поговорить с сотнями людей, прежде чем 1-2 из этих дискуссий куда-нибудь вас приведут. Важно иметь группу поддержки, хотя бы группу единомышленников, и не падать духом в процессе поиска.

Вопрос 7 очистка Slack


Мне кажется, я прочитал, что GitLab стирает сообщения в Slack через какое-то время. Можете ли вы объяснить, в чём здесь плюс? В моей компании мы сильно зависим от истории Slack.

Даррен Мерф:

Да, мы стираем! Чтобы заставить использовать Slack для его лучшей цели, неформального общения. Если ничего не стирать, бесконечное число непрочтенных сообщений могут плохо сказываться на психике и продуктивности. Они мешают сосредоточиться, найти состояние потока. Если ваша жизнь зависит от пингов в Slack, это рецепт к выгоранию.

Поэтому мы удаляем все сообщения через 90 дней. Если ваша команда это знает, они никогда не запросят поток сообщений для контекста проекта. Вместо этого они будут вынуждены обсуждать и заканчивать обсуждение работы там, где это положено. Люди не предназначены для того, чтобы вести сотню дискуссий одновременно, часть из которых началась год назад. Мозги начинают просить тайм-аут.

Вопрос 8 работа в GitLab


Привет, Даррен, три вопроса:

Что является самой сложной частью вашей работы в качестве руководителя удаленного отдела?

Как много из ваших 1300+ коллег перегорают от удаленной работы и изоляции (учитывая, что у вас есть руководство, как этого избежать)?

Сколько людей покинули GitLab, потому что они хотели вернуться обратно в офис? Как часто уходят от вас, если сравнивать с традиционными компаниями в индустрии?

Даррен Мерф:
  • Самое сложное дать понять, что люди должны давать себе возможность действительно работать по-другому. В GitLab преуспевают те, кто сбрасывает прежний рабочий багаж у двери, и пользуются этой возможностью, чтобы начать думать по-новому. Но это тяжело. У всех людей есть прошлый опыт, который окрашивает всю их дальнейшую работу, они верят, что так надо, хотя это не так.
  • Перегорает у нас очень мало людей, потому что мы делаем всё, чтобы такого избежать. Почитать о наших методах можно здесь: https://about.gitlab.com/company/culture/all-remote/mental-health/. Ещё я помог создать бота в Slack, который напоминает всем членам нашей команды брать время для себя, отходить от работы каждый месяц (это оплачивается). Вы можете ввести это хоть сегодня https://about.gitlab.com/handbook/paid-time-off/#monthly-reminder-to-consider-taking-pto. Проще сделать так, чтобы предыдущий сотрудник не перегорел, чем каждый раз искать нового.
  • С нами продолжает работать больше 85% сотрудников, которые к нам пришли это намного выше среднего уровня по индустрии (81%). Люди, которые ценят работу на удалёнке, по моему опыту, часто очень преданны хорошему работодателю.



Вопрос 9 начало удалёнки


Привет, Даррен, можешь ли ты дать совет людям, которые меняют карьеру и хотят перейти на удаленку в IT-компанию? Я знаю несколько людей, которым это дается очень сложно, потому что у них нет Х лет опыта. Их услуги как программистов не требуются, их не принимают даже в статусы джуниоров, хотя они ходят на курсы и имеют навыки в других похожих отраслях, которые потом можно было бы использовать. Любой совет был бы очень кстати, спасибо!

Даррен Мерф:

Без сомнения, это сложно. Хотя постепенно становится легче. Тут нет магического способа сразу получить работу. Моей первой удаленной работой был низкооплачиваемый фриланс, который я постепенно развил и сделал из этого что-то наподобие карьеры. Многие работники не хотят начинать оттуда, но это одна из опций.

Второй вариант взять на себя похожую работу, и постепенно создавать портфолио, которое позволит вам выглядеть презентабельно. Не обязательно сразу работать из дома. Руководителям проще позволить показавшему себя сотруднику перейти на удалёнку.

Вопрос 10 что в будущем


Даррен, что больше всего изменилось в твоих мнениях по поводу удаленной работы в последние 1-2 года?

Даррен Мерф:

Раньше мне казалось, что эта сфера будет расти медленно, и станет более популярным методом цифрового труда где-то к тому времени, как мой сын (ему сейчас 1 год) будет начинать искать работу. Теперь я думаю, это будет нормальным и широко принятым способом работы для сотен миллионов уже к 2021-му.

Изменения в сфере происходят буквально каждый месяц. Мы сейчас наблюдаем гигантский социальный и культурный сдвиг, который запишут в учебники по истории. Такой же по силе, как изобретение конвейера в начале XX века. Работа теперь поменяется навсегда.
Подробнее..

Подкаст Хочу в геймдев 10

27.07.2020 14:05:23 | Автор: admin

Это подкаст "Хочу в геймдев", и у нас вышел уже 10-й, юбилейный выпуск, в котором мы рассказываем о профессии разработчик игр (программист) на Unreal Engine.


Что это за подкаст? Подкаст Хочу в геймдев это инструмент для тех, кто хочет попасть в игровую индустрию, но не знает как, куда и зачем, с чего начать и как действовать.


Раньше мы говорили в общем о различных специализациях в игровой индустрии, а в этом выпуске начинаем подробно разбирать одну конкретную профессию.



Подробную информацию о подкасте, о всех вышедших на сегодня выпусках вы можете посмотреть на сайте подкаста>>>
Все выпуски вы можете послушать на ресурсах (тайминг есть в описании каждого выпуска):
Youtube, Вконтакте, Яндекс Музыка, Itunes, Google Podcasts, Castbox, Spotify
Приятного прослушивания!


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


Ведущие выпуска и приглашенный эксперт:



Вячеслав Уточкин, Олег Доброштан, Александр Мураш и Владимир Алямкин


Путь эксперта
Разрабатывать свои игры, рассказывать свои истории Владимир захотел с 10 лет, вдохновляясь такими играми, как, Diablo, DOOM. Starcraft


Выход Gothic послужил катализатором, и наш эксперт решил сделать свою Готику с вампирами и духами смерти. Опыта разработки не было, а основные прикладные навыки развивались в сфере создании трехмерной графики и анимации.
Общение с единомышленниками происходило на форуме gamedev.ru, там, пообщавшись с программистами, Владимир понял, что ему нужно вникнуть во всевсё сферы самому и разобраться в программировании.
Попытки игровой разработки завершились уходом из индустрии в сферу заказного софта, работу по техническим заданиям.
Возвращение в геймдев произошло в 2009-10 годах, на данный момент Владимир имеет за плечами 9 лет опыта разработки в Unreal Engine и является Tech Lead Pushkin Studio в My.Games.




С чего начать тем, кто пока ничего не умеет, но хочет стать программистом игр?


Программист очень техническая специальность, по сути это функция, решающая задачу.
При отсутствии знаний о программировании и геймдеве, можно начинать с позиции технического геймдизайнера, в этом случае пойдет прокачка сразу по двум веткам: программированию и гейм-дизайну.


Если есть желание начать именно программистом, то стоит получить академическое образование: изучить либо C# или C++, эти языки практически одинаковы в освоении (в геймдев разработке), нужно читать специализированную литературу, причем, прочитав половину книги можно приступать к написанию кода.




Полезные источники информации для начинающего программиста, где искать информацию?


  • Специализированные сообщества. Общайтесь, развивайтесь вместе с другими людьми, это очень важно для быстрого роста в любом деле.
  • Определившись с движком изучайте опыт других, делитесь своим. У Unreal Engine есть замечательный Telegram канал и сообщество Вконтакте. В этих сообществах обитает большое число грамотных специалистов, которые помогут и подскажут. Также, до сих пор существует форум GameDev.ru.
  • В англоязычном сегменте можно посоветовать форум Epic Games, канал в discord.
  • Учебные курсы, например Udemy, в сжатой и удобной форме подаются основы разработки на C++. Главное изучать не только повторяя тот материал, который вам подается, но пробовать сделать что-то свое, заимствуя некоторые механики из только что усвоенного материала.

Какие качества характера (и не только) программиста важны и нужны?


  • Увлеченность непосредственно процессом, программирование должно заводить, щекотать мозг.
  • Сосредоточенность на своем деле: человек должен уметь и любить выстраивать логические конструкции у себя в голове.
  • Важны soft skills, умение общаться, одних hard skills в геймдеве недостаточно, т.к. все завязано на команду и ваше умение общаться и быть на одной волне обязательно повлияет на принятие решения.
  • Знание английского языка на уровне чтения и понимания технической документации.



Должен ли программист уметь/любить играть в игры?


За редким исключением, да. Геймдев программист должен играть в игры.
Если ты не играешь, если тебе это неинтересно, то зачем ты пошел в геймдев?


Есть куда более специфичные области, в которых больше денег славы и прочего, которые никак не связаны с играми.
Основная цель разработчика создать конечный продукт. Намного легче сделать игры, понимая их изнутри, делая продукт более качественным и приятным для игрока.
Ведь все, что мы делаем, оценит конечный пользователь и именно для него мы стараемся.




C# или C++, Unity или Unreal Engine? что выбрать и почему?


Нужно начать с того, что просто запустить оба движка, посмотреть демки, примеры, мини-игры, как реализованы с точки зрения кода.


Глобальной разницы нет, это просто инструменты со своими особенностями.
На старте заморочки не важны. Ситуация меняется динамично, основываться на востребованности не стоит. Что больше нравится, игры в которые играешь на чем сделаны, если нравятся игры на Unreal делайте на них.
Также можно расширить кругозор другими движками, Godot, например.
Выбор должен быть основан на мотивации и личном восприятии.


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


С точки зрения востребованности в сторах (App Store, Google Play), то какого-то одного фаворита тут нет, используются разные движки, в зависимости от предпочтений разработчиков и задач, которые перед ними стоят.


Специфика работы в российском геймдеве, заключается в том какие игры делаются. Российский геймдев очень хорошо умеет делать мобильные игрушки, в этом плане мы конкурируем с мировыми разработчиками, отсюда такая высокая востребованность разработчиков мобильных, социальных игр.




Про важность резюме для программиста. Что поможет получить приглашение на собеседование?


  • Оформляйте резюме аккуратно и грамотно, сделав резюме на коленке, не стоит рассчитывать на приглашение.
  • Используйте шаблоны, например на сайте hh.ru есть раздел, посвященный оформлению резюме.
  • Ваше резюме это образец вашего кода, помните это.

Какие вопросы на собеседовании задают junior-кандидатам? Что важно знать для прохождения собеседования?


Можно выделить три направления:


  1. В первую очередь, если ко мне приходит программист на позицию junior, я задам вопрос про плюсы, причем вопросы несложные, которые можно найти в тех самых задачах и книгах, о которых упоминалось выше. Мне надо понимать, как у человека работает мозг, насколько у него выстроено логическое мышление и понимание работы алгоритмов.
  2. При условии того что у человека есть технический уровень чтобы писать код, второй вопрос будет про то, чем он занимается сам. На старте важно наличие любых своих проектов, нужно показать что ты делал, как решал конкретные задачи. Какие есть свои наработки, прототипы. Альтернатива выполнение тестового задания с объяснением решения задач.
  3. Вопросы внутренней мотивации человека, такие как: Какие задачи вы планируете решать, придя к нам? К чему стремитесь и куда хотите развиваться? Что вами движет и почему именно геймдев? Близки ли вам проекты, которые мы реализуем?



Важен ли внешний вид программиста при прохождении собеседования?


Элементарная гигиена, опрятность и соответствие обстановке вполне достаточные требования к внешнему виду. Запрета на татуировки или пирсинг нет, цвет волос также не играет никакой роли. :)


Ссылки по теме подкаста:


Пример тестового задания для программиста: https://github.com/PushkinStudio/pushkinstudio.github.io/blob/master/tournaments/README.md
Опросник по C++: https://cloud.mail.ru/public/4vK7/3A2JQNrVQ


Онлайн-Круглый стол 19.08: https://games.hse.ru/lecture/
Онлайн-День открытых дверей по программе Менеджмент игровых проектов: https://games.hse.ru/openday
Личная страничка Владимира Алямкина: https://www.facebook.com/vladimir.alyamkin
Личная страничка Олега Доброштана, куда можно написать вопросы для следующих выпусков: https://www.facebook.com/oleg.dobroshtan
Сайт подкаста: http://podcast.hsbi.ru/

Подробнее..

Перевод Самая серьёзная проблема HTML? Разработчики, разработчики, разработчики

27.05.2021 12:14:32 | Автор: admin
image

Мы можем насмехаться над Баллмером за этот полубезумный нервный срыв, но его месседж попал в цель. Если не дать разработчикам инструменты и знания, которые необходимы для работы с вашей системой, они не только будут испытывать трудности, но и не смогут развивать то, над чем вы работаете!

Увы, на практике мы видим, что в этом отношении сами разработчики могут быть своими худшими врагами. Они выбирают ужасные фреймворки, заставляющие их трудиться больше, а не продуманней, или намеренно бравируют своим незнанием фундаментальных основ и копируют чужой код в надежде, что он выполнит нужную задачу.

Ни в одной области это так не очевидно, как в высокомерном, пофигистском, а то и откровенно презрительном отношении к HTML. Нет пределов для бесконечных благоглупостей и ошибочных заявлений от тех, кто не способен написать ни одной строки на этом языке.

Если в двух словах, разработчики воспринимают HTML недостаточно серьёзно, но что произойдёт, если вы укажете им на их слабость? В ответ мы дождёмся только бесконечный поток бессмысленных оправданий того, почему их нельзя отвлекать на его правильную реализацию!

Список слабых оправданий


HTML это ненастоящий язык программирования

Это последовательность команд, которым следуют компьютеры для выполнения задачи. Если и есть другое определение языка программирования, то за четыре десятка лет написания ПО я его не слышал. Является ли от Тьюринг-полным? Нет но тем не менее он сообщает компьютеру, как передать грамматическое и структурное значение контента в машинонезависимом виде. Есть правила по использованию его тэгов, порядка и синтаксиса.

Никого не волнует код, если для пользователя он выглядит правильно

Ровно до того момента, как вы не столкнётесь с незрячими пользователями. HTML это не только то, как выглядит страница Нет! Исправлюсь HTML вообще не о том, как что-то выглядит. HTML нужен для того, что сообщить, какими должны быть элементы с точки зрения грамматики и структуры, чтобы user-agent мог передать это значение пользователю. Поэтому для описания того, как должны выглядеть элементы, у нас есть CSS. Если любой из ваших тэгов, id или классов сообщает о том, как элементы должны выглядеть, то вы выбрали неподходящий код, исходя из неверных предпосылок.

Скринридеры (ПО для чтения страницы вслух), электронные книги со шрифтом Брайля, TTY всё это невизуальные целевые объекты; и не забывайте, что у поисковых движков тоже нет глаз. Им нет ни малейшей разницы, как выглядит ваша страница.

Кроме того, людям важно, что ваша страница медленнее или её хостинг обходится дороже, или она нарушает правила доступности для людей с ограничениями, или она забивает весь доступный канал. Несемантическая разметка, бесконечные и бессмысленные DIV, не делающие ничего, presentational classes все они складываются и влияют на результат!

Вы будете слышать те же оправдания для множества других аспектов веб-разработки, и почти всегда это ложь. Будь то плохая/поломанная семантика, проблемы с доступностью для людей с ограничениями, раздутый необязательный JS, использование технологий веб-приложений для того, что приложением быть не должно, и т.д., и т.п.

Очень часто при использовании всего этого пользователь понимает, что что-то не так, но не может этого объяснить. Пользователи не программисты, они не знают, в чём ошибка и кто в ней виноват, но они ощущают, что что-то не так, всё вкривь и вкось.

А как насчёт следующего несчастного неудачника, которому придётся поддерживать результат вашего труда, в котором собраны все ошибки из списка, как НЕ нужно использовать HTML? Люди всегда болтают о том, как их ужасный поломанный фреймворк должен помогать в совместной работе. Как в два или десять раз больший объём кода, не соответствующий базовым правилам HTML и нарушающий само предназначение этого языка, может улучшить совместную работу?

Но примеры во фреймворках работают именно так, а их писали специалисты

Они не специалисты в веб-разработке. Скорее, специалисты в маркетинге, пропаганде и обмане. Разметка в примерах таких систем, как Bootstrap и Tailwind это кошмарные практики HTML. Они воняют ужасной смесью заявлений я не хочу изучать HTML и CSS и я скучаю по разметке 1990-х, отказываясь от двадцати с лишним лет прогресса. Только потому, что их используют миллионы сайтов (большинство не может ошибаться), а самозванные эксперты поют им хвалебные оды (апелляция к авторитету), не делает их или подобные практики хорошими.

С ванильным кодом работать сложнее

Сложным делаете его вы. В том-то и проблема: игнорируя семантические правила структурирования и весь смысл предназначения HTML, вы усложняете работу с ним. Способствует этому и то, что приманки для нубов наподобие W3Schools (aka W3fools) переполнены неточной информацией, вульгарными упрощениями и полным отсутствием большинства из базовых концепций HTML.

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

Вообще, Tailwind проще, чем ванильные HTML/CSS, достаточно просто выучить более 500 классов, 90% из которых уже существуют в виде свойств CSS, а затем игнорировать почти все правила того, как должен использоваться HTML!

Если вы не поняли, это был сарказм.

Вы придаёте слишком большую важность HTML



Я постоянно слышу эту чушь, и меня раздражает её недальновидность!

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

HTML это фундамент и краеугольный камень. Если им пренебречь, то не удивляйтесь, что результаты будут полной катастрофой.

И в самом деле, многие заблуждения, которыми веб-разработчики убеждают себя не беспокоиться о будущем, не отличаются от тех, которые приводят ко всем инженерным катастрофам. Экономия на качестве, игнорирование спецификаций или конечного пользователя, подпитывание собственного эго; к тому же многие совершают фатальную ошибку путают искусство с проектированием.

Последняя ошибка приводит к возникновению зданий, ослепляющих людей отражённым их окнами солнечным светом: некто, возомнивший себя художником, убеждает людей в костюмах потратить миллиарды на проект, в котором форма важнее функции.

Но HTML не даёт нам инструментов, которые нужны для обеспечения UX

Это оправдание имеет множество разных версий, но в целом они подразумевают написанное выше. Говорящие это почти всегда относятся к поклонникам веб-приложений или одностраничных приложений, они пытаются использовать JavaScript везде, они не заботятся о доступности для людей с ограничениями и настаивают, что пользователям почему-то нужны все их модные причиндалы для улучшения user experience.

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

И результаты их работы вы УЖЕ СЕЙЧАС видите во всей нашей отрасли: хрупкие, распухшие, медленные решения, которые способен улучшить скриптинг, настолько затормаживают системы корзин интернет-магазинов, что многие из них даже неспособны поддерживать аптайм (привет, Zotac); при этом пользователи ожесточённо жмут на F5, надеясь, что им всё-таки удастся купить видеокарту. Из-за перезагрузки всей страницы целиком и повторного запуска скрипта все функции приложения приводят только к УМЕНЬШЕНИЮ скорости загрузки страницы. И ещё сильнее это проявляется, если вы плюёте на разметку, пользуясь presentational classes.

А поскольку скрипты можно отключать, и генерируемый скриптами контент сложнее для скринридеров, электронных книг со шрифтом Брайля, и так далее, одностраничные приложения (single-page application, SPA) нарушают правила доступности для людей с ограничениями.

Я не говорю, что SPA и им подобные не имеют разумных способов применения, но если вы не можете создать простую корзину или банковский портал с быстрой загрузкой, который мало теряет от отключения скриптов, то вам, вероятно, не стоит заниматься работой на какой бы то ни было бизнес. Веб-приложения НЕ должны использоваться для чего-то столь смехотворно простого, как корзина на веб-сайте!

И если вы думаете, что использование скриптинга для этого действительно улучшает user experience, то вы, очевидно, не тестировали систему на реальных пользователях и реальном трафике! По крайней мере, не выполняли реального сравнения разделения задач с использованием кэша в загрузках нормальных страниц и на страницах с новомодными скриптами.

То есть во всём виноват веб-разработчик?


Ни в коем случае. Вернёмся к началу статьи и к крикам Баллмера разработчики, разработчики, разработчики.

Когда он разыгрывал свою небольшую сценку, она была призвана решить проблему того, что в конце 90-х Windows ни в коем случае не была на первом месте, потому что разработчики часто не использовали предоставляемые компанией Microsoft инструменты. Лучшую документацию по Windows API напечатала Borland. Люди использовали инструменты не от Microsoft, потому что визуальные языки считались игрушками. Они так сильно отставали от технологий веб-разработки, то можно сказать, что они и сейчас пытаются их догнать!

У W3C и WhatWG есть похожие проблемы с тем что так называемые спецификации попросту написаны не для людей, которые пишут веб-сайты. Позвольте мне повторить: спецификация языка, используемого для написания веб-сайтов, предназначена не для людей, которые на самом деле пишут веб-сайты. Она написана для людей, которые пишут user-agents! Браузер это user-agent, но UA не всегда браузер.

На самом деле, это такой абсурд, что идиотическая версия динамичного документа WhatWG ссылается на MDN, чтобы её могли понять простые смертные.

Примечание: я даже не буду начинать рассуждения о том, насколько тупой является сама идея динамичного документа (living document), особенно потому что в реальных HTML-документах отсутствует отслеживание версий. HTML 5, который был валиден в прошлом году, становится сегодня невалидным HTML 5, а сегодняшний валидный HTML 5 может стать невалидным завтра? Отличный способ сделать валидацию совершенно бесполезной!

Простой факт: для получения описаний значений тэгов на простом английском приходится обращаться к сторонним источникам, многие из которых даже не согласуются друг с другом. Более того, W3C стала совершенно беззубой, она слепо соглашается со всем, что говорит WhatWG, даже несмотря на то, что WhatWG многократно доказала, что она не имеет достаточной квалификации для создания потомка HTML 4 Strict. Принятие EMBED в качестве валидного тэга, создание и/или поддержка тэгов, избыточных относительно OBJECT, больше не поддерживаемый (к счастью) тэг HGROUP, показавший, что они даже не понимают, для чего нужны нумерованные заголовки и как их использовать По признанию многих, кто над ним работал, задача HTML 5 на самом деле никогда не заключалась в создании спецификации или стандарта, говорящего нам, как создавать полезные веб-сайты! Она заключалась в документировании того, делают ли сегодня люди правильно или неправильно, и того, что браузеры могут поддерживать, но не того, что они должны поддерживать! Учитывая то, что во время разработки HTML 5 большинство разработчиков всё ещё вбивало HTML 3.2 и набрасывало поверх него извращённый doctype HTML 4, к чему удивляться, что всё оказалось таким скоплением плохих, устаревших и старомодных практик?

Если уж разработчики не воспринимают HTML достаточно серьёзно, то обвинять в этом стоит тех, кто разрабатывал его как спецификацию; даже назвать подобное именем HTML 5 было таким серьёзным преступлением против веб-разработки Как преступлением против музыки стало вручение Грэмми Билли Эйлиш за её бесталанные творения.

W3C и WhatWG даже не воспринимаются серьёзно другими организациями по стандартизации, и на то есть причина.

Каким же должно быть решение?


Неплохо бы для начала добиться от разработчиков, чтобы они не воспринимали HTML как недоразвитого ребёнка от мира языков программирования. В частности, заставить их практиковать семантическую разметку с разделением представления от контента, что сильно повысит юзабилити, доступность и эффективность.

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

Но нам нужна не просто улучшенная официальная документация, необходимо урезать язык, сделать его более ориентированным на задачи. Возродить многие идеи, которые содержались в HTML 5 до того, как W3C выкинула их на помойку и приняла версию WhatWG. Тот факт, что Microsoft потратила десятки лет на то, чтобы IE препятствовал нам использовать OBJECT ещё не причина не только сохранять тэг IMG, но и добавлять множество новых тэгов без нужды (VIDEO, AUDIO). Просто потому, что художники и жулики от маркетинга любят открывать для пользователя новые окна, нравится ему это или нет, ещё не причина того, чтобы в спецификации было TARGET="_BLANK".

Более того, ЯВНОЕ использование и значения тэгов необходимо поместить в центр спецификации, а может быть, даже в отдельное руководство по использованию для тех, кто по-прежнему живёт в 1997 году.

Создание более простой, чистой и полезной версии HTML, которая станет руководством для нас всех не такая уж сложная задача.

Кроме того, нам полезно будет, если при её создании меньший вес будут иметь разработчики браузеров. Microsoft, Mozilla, Apple и Google имеют огромное влияние на W3C и WhatWG, и это совершенно неэтично. Их вес в процессе принятия решений противоречит самой концепции свободного и открытого веба.



На правах рекламы


Эпичные серверы это VDS для размещения сайтов от маленького интернет-магазина на Opencart до серьёзных проектов с огромной аудиторией. Создавайте собственные конфигурации серверов в пару кликов!

Присоединяйтесь к нашему чату в Telegram.

Подробнее..

Полюбите программиста

12.09.2020 08:21:14 | Автор: admin

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

Источник: PikabuИсточник: Pikabu

Disclaimer: статья написана сотрудником, ночью, не согласована и т.д. Короче, изложенное может совпадать, а может и не совпадать с позицией компании.

Не требуйте невозможного

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

Правда, абзац звучит очень странно? Вы не такой (такая)? А таких немало. Увы, зачастую программист получат задания, которые невозможно реализовать в одиночку или без привлечения дополнительных технических ресурсов. Увы, пользователи часто не подозревают, что существуют IDE, библиотеки, ограничения языка программирования и технологий, в конце концов. Если вам в голову пришла очередная гениальная идея, не требуйте жёсткого исполнения от вашего коллеги-разработчика, а проведите минимальное исследование клиентской потребности и обсудите вопросы на уровне концепции. Программист всегда заинтересован в создании нового, крутого продукта со своим именем в авторах, и его уровень опыта и адекватности может спасти даже самую бредовую идею.

Не торопите программиста

За сроки ещё вчера можно смело наказывать и депремировать если ты хочешь ещё вчера, почему ты приносишь своё ТЗ программисту сегодня? Почему ты не принёс его позавчера или месяц назад? Почему ты протянул время, а программист вместе с задачей должен получить срок ещё вчера или самый короткий дедлайн?

Работа программиста обычно выглядит так: проектирование анализ прототипирование написание кода тестирование дебаггинг сбор проекта рефакторинг. Причём эти этапы могут быть совмещены, перемешаны, дополнены и т.д., а внешне всё выглядит как стук по клавишам. И, кроме скорости набора, работа программиста это работа мысли, это исследовательский труд. Если вы коллега и торопите коллегу-программиста, то вы рискуете нарваться на обиду и непонимание; если вы руководитель и давите на программиста, он будет вынужден выполнить ваше требование за счёт исключение одного или нескольких этапов. А программа без тестирования и без рефакторинга беда на продакшене.

Поэтому перед тем, как приступить к проекту, обсужда йте с программистом временные рамки его работы, попросите описать и обосновать затраты времени на конкретные задачи. Исходя из этого планируйте работу менеджеров и свои обещания клиентам. Программист не виноват, если вы не умеете планировать.

Не изобретайте законы разработки

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

  • а ты переключись на Linux, он всё умеет (во дела!);

  • а почему ты с новой строчки вот здесь написал? (мне платят за строчки кода, разве не знал);

  • может, через SQL сделать? (а может, через одно место специально для тебя);

  • пиши код в блокноте, блокнот труъ, я читал (ну и читай свой блокнот дальше);

  • у тебя тут заглавными написано, отожми Caps Lock (DELETE FROM MY_SPACE).

Это немного веселит и поднимает настроение, но в конечном итоге очень раздражает. Разработчик учился, у него есть свои методы, свои предпочтения по стеку разработки, навыки работы с определёнными компонентами. И даже если вы нагуглите, что конкретную задачу проще решить на Go, а не на Python, ваш разработчик не бросится учить новый язык программирования. Программист готов отвечать за работу, выполненную комфортными для него средствами. Не навязывайте ему стек, идеи, правила, особенно если вы не разбираетесь, а просто целенаправленно поискать ответ на свой вопрос в интернете.

Не считайте разработчиков приложением

Разработчик не равно компьютер, программист не равно программа. Соответственно, он может задуматься над задачей, попросить больше времени, ошибиться и даже отказаться от задачи, если понимает, что с ней не справится и готов аргументировать свой отказ. Точно так же, как он хочет есть, пить, спать и жить отличной от работы жизнью. Поэтому не загружайте разработчика неоплачиваемой сверхурочной работой да, не факт, что он откажется, но вполне возможно, что он выгорит и пойдёт в сторону другого работодателя и более адекватных коллег.

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

Пустите программиста в бизнес-процессы

Поверьте мне на слово, если ваш программист освоил высшую математику, паттерны, объектно-ориентированное программирование, алгоритмы, то и ваш сложнейший бизнес-процесс оптовых продаж удобрений он освоит. Если ваш разработчик или штатный программист будет внутри бизнес-процесса, он будет в несколько раз полезнее. То же самое касается автоматизации: если он понимает, как именно работает компания, как организованы коммуникации и основные процессы, он сможет эффективно сопровождать внедрение и дорабатывать ь доступными средствами вашу CRM, ERP, PM и проч. софт. Таким образом, автоматизация будет грамотной и рабочей, а не серым камнем в пять пудов.

Не забудьте поздравить ваших программистов

Сегодня нерабочий день и поздравлений может быть несколько меньше. Но в понедельник вы вернётесь в офис и там будут они ваши главные помощники в современном мире технологичного бизнеса: аналитики BigData, программисты 1С, суровые разработчики на С++ или Delphi, модные разработчики Go и Kotlin, маги и волшебники PHP и JavaScript, высоконагруженные Java-разработчики и многие другие покорители стеков технологий.

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

P.S.: ну а я, пользуясь случаем, поздравляю нашу команду разработки RegionSoft CRM (и остальных наших продуктов) с Днём программиста, желаю частых и крутых релизов, новых интересных требований и бесконечного развития без того удобной и классной программы. Эти правила я осознала, работая с вами.

Подробнее..

Алгоритмы и написание кода на собеседованиях полезно, но необязательно

11.12.2020 20:11:43 | Автор: admin
Этой теме уже десятки лет как собеседовать и почему, нужно ли знать алгоритмы программисту или нет, и так далее.

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

Кажется, проблема лежит глубже, и все смешалось в кучу.



О многомерности вопроса собеседований


Тут можно очень много говорить, но в целом, вопрос в определениях. Люди рассуждают о собеседованиях, не задав уточняющие вопросы (как на собеседовании к задачам).

Во-первых, какие бывают области разработки ПО? Вспомним миры Джоэла Спольски. Уже это будет давать разные требования к собеседованиям.

Во-вторых, что за компания? Стартап, big tech, галера, веб-студия, интернет-магазин, или контора с IT-отделом, где основной бизнес другой?

В-третьих, что такое сеньор? В комментариях к посту верно отметили, что в сеньора смешивают все архитекторов, ведущих программистов, узкоспециализированных специалистов и так далее.

Далее, какие цели и какого собеседования? Бывают собеседования для поточного набора, бывают поиски звезд, бывают поиски людей с конкретными навыками работы и опытом в технологии, и так далее.

О роли пути в профессию


И, конечно, не стоит забывать про культуру. Знаете, в музыке или в науке есть особое разделение на своих и остальных. Типа, есть у тебя образование профильное и стандартный путь, или нет (в музыке это выражается в обучении более 10-15 лет: ДМШ училище консерватория, к примеру). И мне, имеющему опыт без музыкального образования выступления на сцене с профессиональными музыкантами, хорошо знакомы вопросы ты что заканчивал / у кого учился, которые выделяют своих от остальных.

Программисты получают образование в области CS. Нередко многие из них проходят отбор через олимпиады, где решают специализированные задачи. Учат тонну матана и разных других дисциплин в том числе уже набившие оскомину структуры данных и алгоритмы.

Думаю, немалая часть противостояния лежит в том, что часть программистов имеют профильное образование и считают тру программистами тех, кто прошел схожий с ними путь. А другая часть самоучки (вспомним знаменитое Google: 90% of our engineers use the software you wrote (Homebrew), but you cant invert a binary tree on a whiteboard so fuck off.).

И это не изменится, пока будут как минимум два крупных источника прихода в профессию и два представления о том, кто такой программист и что он обязан уметь.

Какие предварительные выводы?


В общем-то, если принять вышеописанное во внимание, то все становится на свои места.
Если в компании Гугл есть культура людей, которые впитали с вуза, что программист это человек со знанием алгоритмов и структур данных, то они таким образом и построят набор.

Считайте, как поступление в вуз все сдают математику и физику, готовятся к экзаменам (и потом успешно забывают к концу учебы тут, правда, замечу, что поступал до ЕГЭ и у нас в каждый вуз были свои типовые задачи и по ним готовились отдельно). Возможно, за этим есть A/B тесты бизнес-подхода к набору, где алгоритмы наиболее эффективно определяют качества человека (способен ли тупо физически выучить все, может ли думать так, как думают будущие коллеги), который будет успешен в компании.

Если в компании АльфаБетаГамма (название выдумано) работают с Джавой и нужно знание нюансов всего стэка, то будет разумнее спрашивать пет-проекты или нюансы по технологии, ибо нужен будет опыт.

При этом, если зарплата хорошая и поток большой нубов из-за большой суммы да, поставят на входе задачи типа напишите пузырек, чтобы не тратить время (собеседование минимум полдня подготовка + созвон + вернуться обратно в рабочий режим) на тех, кто решил попытать удачи (на Хабре уже была статья про войти в айти, и не одна).

Если же в компанию ДельтаДзета (название тоже выдумано) берут по рекомендации архитектора на серьезную должность, то с ним пообщаются по профессии, с уважением, и не будут задрачивать на дебильных задачах.

Однако, если в вышеописанных случаях происходит то, что всегда происходит человеческий фактор типа внутренней политики то либо усталый программер на силой навязанном ему собеседовании будет валить кандидатов, либо будет валить потенциальных конкурентов, либо что-то еще.

Немного о пользе алгоритмов


Я по образованию инженер-робототехник, и у меня были некоторые курсы, которые есть у программистов, но далеко не все. И изначально всегда относился со скепсисом к алгоритмам, ибо первая реакция, когда кто-то пишет, кто не читавший Кнута не есть программист, негативная.

Со временем, изменил свое отношение, и считаю, что это как школа. Ты тупо впитываешь знания, полученные лучшими умами за прошлые десятилетия. Чтобы понять, и если потом нужно будет быстро нагуглить или написать самому. Стал испытывать удовольствие, когда прорешал N задач на Codewars, и прочитав на русском + проработав упражнения отличной книги Питон и алгоритмы (всем рекомендую, есть еще на английском).

Поднимается самооценка, когда в общении с коллегами знаешь такие термины. Плюс ощутимо развивается мозг, который познает новое. После этого даже взялся за два пет-проекта (на Джанго и node.js), возможно, выложу на Хабре и в опен-сорс, как доведу код до смотрибельного состояния, чтобы в комментариях не сильно распекали.

Ну и конечно, если вы хотите работать над реально крутыми задачами или с крутыми языками, то нужно не забывать про матрицу компетентности программиста.

Рано или поздно, начинается граница, для которой нужно иметь некий запас знаний и навыков (например, в играх математику, работу с графами, памятью, рекурсией и тд; в data science, как хорошо недавно писали линейную алгебру, статистику + системы аналитики), которые придется освоить.

И лучше сделать это по кайфу и размеренно, в рамках собственного развития, чем, как пишут, насильно и имея два набора знаний для работы и для собеседований.
Подробнее..

Создаём свою идеальную программерскую раскладку или Недооценённый AltGr

09.01.2021 14:22:36 | Автор: admin

*Примечание: чтобы в полной мере ощутить все преимущества новой "кастомной" раскладки, необходимо уверенно владеть десятипальцевым слепым вводом (иначе последующие действия не имеют никакого смысла).

Что здесь написано?

  • Осуждение QWERTY

  • Немножко об альтернативных раскладках

  • На чём печатаю Я

  • AltGr (правый Alt) и что с ним можно сделать

  • MSKLC: собираем раскладку

Шаг 1: Выбор базовой раскладки клавиатуры

Поскольку стоит цель разработать "идеальную" раскладку, то сначала необходимо позаботиться о том, как будут расположены символы на клавиатуре.

Немного отсебятины: Я, как и все, изучая десятипальцевый слепой ввод, печатал на всем знакомой QWERTY-раскладке. В процессе использования, испытывался лютый дискомфорт (возможно нас таких и не очень много): уставал левый указательный палец, правый безымянный и мизинец (даже несмотря на то, что P - далеко не самый частотный символ в английском языке). Также было замечено, что пальцы при печати сильно вытягиваются - как бы пытаются уйти подальше друг от друга.

Чтобы ответить на вопрос, почему так происходит, я создал Excel-файл, в котором наглядно показана нагрузка на каждый символ, и добавил таблицу частотности букв английского языка (результат на скрине).

Вот здесь как раз всё встаёт на свои места: T находится довольно далеко от основной позиции пальцев, плюсом буквосочетания AT/TA, TE/ET, ST/TS, DT, CT, NU/UN, NI/IN, NO,ON заставляют пальцы вытягиваться. Также я отметил главную неприятную особенность QWERTY, о которой конечно-же многие знают - это то, что основным по нагрузке является на домашний, а верхний ряд. Про перегрузку левой или правой руки ничего говорить не буду, так как на планете есть как правши, так и левши, но для левшей у меня плохие новости: если посмотреть на клавиатуру, то можно заметить, что снизу вверх клавиши смещаются ВЛЕВО, что удобно лишь правой руке.

Что по альтернативным раскладкам?

Начнём с того, что разные раскладки проектировались по-разному и преследовали разные цели: наиболее развёрнуто, научно и точно рассказано в этом посте: О вопросах сравнения и оптимизации клавиатурных раскладок / Хабр (habr.com)

  • Dvorak: все гласные влево, максимальное чередование и минимизация использования нижнего ряда любой ценой -> повышение скорострельности.

  • Colemak/Workman: A влево, остальные гласные вправо, повышение эргономичности - расстояния, которые преодолевают пальцы при вводе текста, "Мы круче Dvorak'a!!!"

  • Capewell: нафиг чередования, даёшь эргономичность и идеальный межпальцевый баланс!

  • Carpalx: математические модели, системы штрафов, optimizing.

  • Minimak 4, 8, 12 keys: улучшаем QWERTY с минимальными усилиями!

  • ARENSITO: У вас есть Ergodox или Maltron? Тогда я к вам!!!

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

Что бы там не говорили про то, что альтернативные раскладки нисколько не быстрее стандартной QWERTY, что на 99% правда, фактом является то, что люди переходящие на подобный раскладки идут на этот "трудный в освоении" шаг ради комфорта, а не скорости. Комфорт - это не пустой звук, я сам через это прошёл и очень доволен результатом, да в некоторых программах Ctrl+C и Ctrl+V приходится нажимать не как в QWERTY, но что мешает вводить комбинации двумя руками??? Верно, ничего не мешает.

К чему пришёл Я???

За основу я взял раскладку Dvorak, модифицированный Capewell'ом - Capewell-Dvorak, в котором символ L больше не нажимается правым мизинцем, что очень здорово. Я заметил, что клавишу N в QWERTY мне очень легко нажимается (вспоминаем как смещены символы в нижнем ряду) и там как раз поставили L, да и в принципе, раскладка вышла неплохая. Но, как вы поняли, и здесь есть маленький изьян, из-за которого пришлось немного откатиться к классическому Dvorak'у, а именно ZXCV,а точнее символ C (такое можно простить только Colemak/Workman и Carpalx'у, ибо гласные и K находятся справа, но не в этом случае)

Вследствие чего была произведена "маленькая" модификация, в результате которой я получил, то, что нужно. Действовал я чисто по ощущениям, для этого понадобилось время.

Шаг 2: Ставим всё необходимое на базу

Кто-то может возразить насчёт "программерской" клавиатуры, ибо уже есть Dvorak programmer. Да, он есть, но все спец-символы находятся в верхнем ряду. В то же время хочется нажимать все основные программерские символы в домашнем ряду, чем Dvorak programmer порадовать не может.

Я же предлагаю использовать AltGr (почти Ctrl+Alt, ибо AltGr+Del не работает как Ctrl+Alt+Del, то есть не работает) он же правый Alt, работает как Shift, точнее создаёт новый "чистый" слой клавиш, в который можно засунуть ещё кучу символов. Однако отмечу, что нужно научиться нажимать AltGr только правым мизинцем, тогда никаких проблем в его использовании не возникнет. Также я заметил, что почему-то на правый Alt стараются частотные символы не заводить, даже в домашний ряд, ограничиваясь диакритическими знаками, математическими знаками и греческим алфавитом. Скорее всего, это объясняется некоторой сложностью в использовании AltGr, а именно неправильное нажимание неправильным пальцем.

Теперь открываем блокнот и переписываем все спец-символы, чтобы не забыть: все скобки, кавычки, апострофы, звёздочки, амперсанды, собачки, или даже диакритические знаки!

Агась, базовая раскладка есть, спец-символы не забыли, теперь можно приступать с сборке нашей супер-раскладки. Отрываем MSKLC (да-да, я Winдузятник) и вбиваем свои символы, не забывая всё проверять и тестировать. Перед сборкой очень рекомендую везде понажимать и посмотреть, какие функции содержит MSKLC, что такое Dead Key, как провести тест (там всё очень просто).

Жмём Shift и прописываем, что будет вводиться при зажатом Shift'е, большие буквы и стандартный спец-символы. Ещё можно предусмотреть спец-символы на месте точки и запятой (у меня это ! и =).

Теперь то, ради чего мы здесь собрались: AltGr!!! (не забудьте убрать галочку с Shift, иначе символы будут вводиться не с AltGr, а с AltGr+Shift, на которую (если это кому-то нужно) можно поставить цифры или даже шаблонные тексты)

Я расположил спец-символы следующим образом: слева - все виды скобок, справа - операторы и другие спец-символы. Самые частотные из них находятся в домашнем ряду, что упрощает их ввод. Вверху я расположил комбинируемые диакритические знаки "на все случаи жизни".

Ещё раз напомню, что правый Alt нажимается правым большим пальцем (да-да от так умеет, причём легко). Таким образом, остальные пальцы не сдвигаются с места, позволяя легко вводить спец-символы, почти как без него, тут нужно немного попрактиковаться.

Ура, вы расставили все клавиши так, как вам нужно, теперь осталось всё это добро собрать и установить на компьютер: открываем Project -> Properties, будем свойства задавать

Задаём имя, описание (которое будет выскакивать при переключении раскладки), остальное по желанию.

После того как всё введено, жмём "Build DLL and Setup Package", после успешной установки перезагружаем ПК и радуемся новой установленной раскладке (старую можно удалить в настройках).

В итоге получается максимально комфортная раскладка, при кодинге в которой нужно делать минимальные пальцедвижения для ввода кода, скобок, операторов, тэгов и прочего (смотря на чём вы кодите)

Подытожим: для идеальной раскладки необходимо:

  1. Идеальная базовая раскладка

  2. Удобно расставленные спец-символы

  3. Программа MSKLC

  4. Много практики (если не печатаете на альтернативной раскладке)

Подробнее..

Все научились программировать. А дальше-то что?

10.03.2021 10:18:02 | Автор: admin

Где-то в мире живёт Серёжа тридцатилетний продавец обуви и отец троих детей.

Представим, что Серёже в какой-то момент надоело продавать одинаковые туфли и захотелось делать одинаковые лендинги. Он почитал статьи в интернете, посмотрел 70-часовые разборы разборов по вёрстке на Ютубе, прошёл курсы. Даже купил Алгоритмы Скиены, но пока не открывал. В общем, любым способом научился программировать.

Как ему теперь поступить, чтобы мечта максимально хорошо начать карьеру стала реальностью (если это вообще выполнимо)? Как и в любой профессии, есть несколько вариантов. Сколько из них хороших непонятно, будем разбираться.


Вводные: Серёжа любым способом научился программировать. Что ему делать дальше?

Ничего не менять

Нормальный вариант, если JavaScript показался какой-то ерундой, а после флексов и гридов до сих пор снятся кошмары (мне вот снятся, а я их даже не изучал). Можно вернуться к своей прошлой работе, найти новую, где босс получше и денег побольше, или пройти ещё какие-нибудь курсы. Все остаются при своих, вин-вин.

Главное смириться с тем, что продавать туфли придётся ещё долго.

Кому подходит: всем.

Минусы: туфли сами себя не продадут.

Пробовать себя во всём

Языков, инструментов и фреймворков просто тьма. Типичное заблуждение новичков звучит примерно так:

Так, надо попробовать вон тот форк переиздания пятой версии реакта, и NoSQL хвалят, а ещё Svelte неожиданно пробивается в топы. С другой стороны есть друзья с проектами на Wordpress и разработка плагинов для плагинов jQuery на фрилансе. Там всё понятно, да и PHP не очень сложный.

Так-то оно так. Но здесь важно составить план, что и в каком порядке изучать (например, никогда не прикасаться к Java), иначе можно оказаться в ситуации, когда вы знаете всего понемногу, но нигде не дотягиваете даже до джуна. Хотя даже здесь есть выход можно пойти менеджером проектов.

Джейсон Стэтхем, II в. до н.э.Джейсон Стэтхем, II в. до н.э.

Кому подходит: всем, кому не понравилось, что 1+1 не равно двум в каждый из разов.

Минусы: каша в голове, если работать без плана.

Не продавцами обуви едиными. Вот истории людей, которые таки попробовали и таки стали разработчиками: маркетолог, чиновник, мама двоих детей, юрист, архитектор, металлург.

Углубляться в технологию

Другой подход сфокусироваться и заниматься конкретным языком или технологией. Если выучили JavaScript, то плотно заняться практикой в веб-приложениях. Если C# подумать, подходит ли вам имя Филипп.

Например, можно сделать пару лендингов для друзей или знакомых, у которых есть своё дело. Можно бесплатно или за совсем мелкий прайс вряд ли кто-то откажется от хорошо сделанной страницы с калькулятором, которую можно прикрутить к профилю в каталоге компаний. Лично от меня: если у вас есть знакомый владелец парикмахерской, пожалуйста, сделайте ему сайт, они почему-то все поголовно ужасные. Прям в голове не укладывается.

Другой путь придумать полезный сервис, работающий каким-нибудь API, со всякими элементами управления, чтобы практиковаться в JavaScript. Здесь может быть проблема с инновационной идеей, поэтому полезным сервисом может быть даже очередной таск-трекер. Главное понимать, как всё внутри работает, но если вы сделали всё самостоятельно, то это не проблема. Такой проект можно выложить на GitHub он пригодится на собеседованиях и при большой удаче может сойти за тестовое задание.

Я бы не стремилась выучить всё подряд. а закрепить на практике навыки, полученные в обучении. Тут как с языками без практики, можно быстро всё забыть. Особенно, если ты новичок и у тебя опыта нет пока. Поэтому я бы

искала стажировку

вписалась бы в какой-то проект за еду

сделала бы сайт, чтобы мама могла продавать вязанные салфетки

сделала бы сайт для какой-то благотворительной штуки

откликалась бы на кучу вакансий с тестовыми и делала бы все тестовые

сделала бы свой какой-то проект.

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

Лера Зелёная, продюсер цифровых продуктов HTML Academy

Кому подходит: тем, кто готов выделить свободное время на проекты, за которые скорее всего не заплатят.

Минусы: за них скорее всего не заплатят.

Готовиться к собеседованиям

Собеседования ещё один путь, и нельзя сказать, что параллельный, потому что совсем без опыта на собеседование вряд ли пригласят. Но если мы говорим о том, что какие-то умения в разработке уже есть, то нормально.

Опытные разработчики иногда ходят по компаниям даже без мысли устраиваться туда. Это как спорт знаете, людей посмотреть, себя показать (или вдруг денег предложат побольше). А вот новичкам полезно разобраться, что происходит на собеседованиях, о чём спрашивают и чего говорить вообще никогда-никогда нельзя. Например, никогда не говорите, что вы 1С-программист, если не ищете работу 1С-программиста.

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

Короткий список дел такой:

  • Попасть на как можно большее количество собеседований, чтобы понять, каких знаний и навыков не хватает, и подтягивать эти темы.

  • Если дадут, то брать тестовые задания и делать их как можно быстрее.

Кому подходит: тем, кто уже готов ко всем этим взрослым деловым переговорам о работе.

Минусы: нужно много времени.

Учиться на работе

Если так вышло, что после одного из собеседований удалось выйти на работу, расслабляться рано. Нужно учиться как можно больше, к тому же, где-то поблизости наверняка будут более опытные разработчики.

Важно впитывать как губка и изучать то, что можно практически применить. Если работа со стеком React, то не нужно бросаться и учить Svelte, потому что он популярный. Выучишь, когда мидлом станешь и надо будет расти вширь для сеньора. там уже не будет выбора, нужно будет очень много работать, а значит не получится прокрастинировать.

Кому подходит: всем, кто уже прям готов.

Минусы: хорошие туфли всё равно стоят дорого, придётся потрудиться.

И кажется, этого на первых порах будет достаточно.


Любой путь начинается с первого шага. Во фронтенде можно начать с бесплатных тренажёров по основам HTML и CSS или с курса Профессиональная вёрстка сайтов. А с промокодом SKUCHNO цена станет ещё приятнее.

Подробнее..

Почему разработчикам так много платят опыт Netflix, Wistia и Stripe

30.09.2020 20:16:11 | Автор: admin

Даже в период пандемии и глобальной экономической неопределенности рынок труда в сфере ИТ живет по своим правилам. Здесь есть компании, которые готовы платить сотрудникам все больше, и видят в этом возможность к развитию.

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

Причина #1: В 10 раз лучше, чем нормально

Еще в 1960-х годах было проведено знаменитое исследование, в рамках которого девять разработчиков разной квалификации должн были за отведенное время решить ряд задач от написания кода до поиска багов. Исследователи предполагали, что лучший из разработчиков в среднем справится с заданием в 2-3 раза лучше. Однако оказалось, что наиболее умелый программист оказался гораздо лучше самого слабого он в 25 раз быстрее находил баги, на 20 минут быстрее справился с задачей по написанию кода, а его код работал в 10 раз эффективнее.

Генеральный директор Netflix Рид Гастингс в колонке на сайте CNBC упомянул это исследование и прокомментировал его:

У меня ограниченное количество денег на зарплаты, и есть проект, который нужно завершить. Передо мной встает выбор: нанять 10-25 инженеров средней руки или взять одну рок-звезду, которой я заплачу гораздо выше рынка, если это потребуется. В течение моей карьеры я пришел к выводу, что лучшие разработчики дают ценности не больше в 10 раз, это может быть и 100 раз.

[..]

Если вам нужен кто-то на операционную позицию например, мороженщик то самый лучший из них сможет запихивать шарики с мороженым в 2-3 раза большее количество рожков, чем обычный сотрудник. Но всегда будет лимит продуктивности, так что компания со средними сотрудниками и средней зарплатой будет себя хорошо чувствовать. А там, где необходим креатив, лучшие люди могут показывать результат в 10 и более раз лучше чем нормально.

По мнению топ-менеджера, такие сотрудники могут не просто решать лучше технические задания, но они более креативны и видят концептуальные паттерны, недоступные коллегам среднего уровня.

Причина #2: Талантливые инженеры помогают менеджерам

Помимо непосредственной результативности работы, найм только талантливых разработчиков помогает компании становиться эффективнее в целом. По мнению Гастингса, управление людьми это в целом непростая задача. А хорошо управлять середняками еще труднее, и на это уходит больше времени. В то же время команды, состоящие по большей части из дорогостоящих звезд по естественным причинам меньше, ими проще управлять.

Рид ГастингсРид Гастингс

В итоге компания естественным образом становится более эффективной в разных сферах от создания кода, до использования инструментов автоматизации.

Причина #3: Компания больше работает над публичным образом

Необходимость нанимать сильных разработчиков для того, чтобы выжить в конкурентной борьбе, также стимулирует компании лучше работать над публичным образом, доносить свое видение, философию и рассказывать о культуре.

К примеру, видеоплатформа Wistia активно рассказывает о важных вехах в жизни проекта. Таких, как например, решение взять кредит на выкуп доли изначальных инвесторов. Помимо этого, основатели часто записывают видео о различным мероприятиях, проходящих в офисе:

В итоге инженеры, которые выбирают, куда им пойти работать, могут проанализировать всю эту информацию о получить больше представления о компании, которая уступает по размеру IT-гигантам. И если культура им понравится, это может сыграть ключевую роль. А побочный эффект такой открытости компанию лучше понимают и ее текущие и потенциальные клиенты.

Причина #4: Сильные инженеры улучшают рекрутинг

Необходимость нанимать сильных инженеров заставляет компании более вдумчиво подходить к рекрутингу. CTO Stripe Грег Брокман рассказывал, что компания применяет для решения этой задачи принципы маркетинга замеряет метрики для определения эффективности каналов привлечения кандидатов, проводит эксперименты и постоянно оценивает их.

В частности, опытные разработчики не любят, когда им пишут рекрутеры, поэтому появляются инструменты, которые позволяют им даже вакансии получать тогда и так как им удобно. Например, некоторые российские компании используют бот, который присылает вакансии по нужному профилю и формату (удаленка/страна) прямо в Telegram.

Заключение

Несмотря на то, что выводы любимого Ридом Гастингсом исследования про 10x разработчиков разделяют не все (достаточно почитать этот тред на Hacker News), очевидно, что инженеры помогают компаниям становиться лучше. И делают они это не только с помощью написания кода и поисков багов, поэтому и их зарплаты скорее всего продолжат расти.

Подробнее..

Я не понимаю, почему у программистов всё хорошо

07.10.2020 18:18:13 | Автор: admin

Я никогда не работал программистом, но постоянно пишу о разработке и иногда сталкиваюсь с ребятами, которые пишут код. И они почему-то всегда рыцари в сияющей броне. У них всё хорошо.

И я вообще не могу понять, что с ними не так. Почему никто не рассказывает о проблемах? В чём ерунда? Где подвох?Неужели у всех всё хорошо?

Программисты зарабатывают нормально денег, почти стали прилично одеваться, могут легко сменить работу, если заколебало. Из минусов в голову приходит только выгорание, но как-то, знаете ли, это маловато минусов для очень ответственной работы, от которой в компании зависят CTR, BTL, KPI, SVG и HTML.

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

Программисты выгорают

Это всем известно, и не удивлюсь, если где-то уже написали учебник о том, как не выгорать. Поэтому не буду пересказывать любые другие статьи о выгорании. Перебор с нагрузкой, скучные задачи, депрессия бум, выгорание. Тут даже особо ничего не добавишь.

Новые технологии появляются слишком быстро

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

Все коллеги не очень

Довольно тяжело работать, когда продакт ничего не понимает в разработке, проджект ничего не понимает в словах продакта, дизайнеры тормозят со своим очередным Зеплином, а редактор ругается, что его не спросили, как назвать кнопку.

А это только 11 утра, тестировщики и девопс ещё спят.

На собеседования приходят неотёсанные юнцы

Некоторым программистам однажды приходится собеседовать других людей. И говорят, что невозможно держать себя в руках приходят и не знаю, какие параметры у пятой перегрузки метода ToString(), или как правильно накромсать слайсы в Go. Конечно, приходится опускать их на землю, и портить себе настроение.

А без настроения-то вообще не работается. Хорошо, что у программистов есть печеньки.

До мидла карабкаться и карабкаться

Начинающим вообще тяжко, особенно если учились самостоятельно непонятно, где взять опыт, как делать типовые задачи, а тут ещё тимлид приходит и просит план развития и быстренько поменять стили у заголовков. Конечно, в интернете иногда встречаются понятные и развёрнутые инструкции для развития, но даже их не всегда хватает (надо же в закладки добавить, а потом не забыть), чтобы быстро разобраться.

Вроде мало кто остаётся джуном навсегда, но перспектива так себе, согласитесь.

Что там ещё

Проходить код-ревью портить настроение себе. Проводить код-ревью портить настроение другим. Джира виснет, комп недостаточно мощный, юзеры жалуются. Я не знаю, поэтому приходится додумывать.

Поэтому хочу спросить у Хабра. Программисты всех сортов, что вам не нравится в вашей работе? Какие минусы? Расскажите то, о чём никто никогда не рассказывает.

Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru