Привет! Меня зовут Алексей Пьянков, я главный программист в компании Спортмастер. Скажу сразу, что «главный» не значит «самый главный из всех программистов», нет, это только название, такой очаровательный перевод для «Senior+"».

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

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

И начну именно с 2012 года.

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

Наткнувшись на материал по принципам чистый код для TypeScript и прочитав его решил взяться за его перевод. Здесь я хочу поделиться с вами некоторыми выдержками из этого перевода, так как некоторые моменты чистого кода для TypeScript повторяют такие же принципы для JavaScript, я их здесь описывать не буду, если будет интересно перевод для JS уже публиковался на хабре(@BoryaMogila) или же можете ознакомится с ними в первоисточнике.

У тебя есть всё — высокая должность, зарплата в несколько сотен тысяч рублей, надёжность и стабильность государственной корпорации, ранговые корпоративные игры. У тебя малиновые штаны — и подчинённые разве что не приседают и не делают «Ку».

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

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

С этого осознания начинается долгий путь к самому себе.

Мне повезло взять интервью у человека, который проделал «путь в тысячу ли» из топ-менеджера государственной корпорации, полностью изучил изнутри систему и смог вырваться, отказаться от социальных условностей и выйти из-под давления общества. Ему понадобилось три года, чтобы найти себя и справиться с последствиями профессионального выгорания.

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

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

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

Полбеды, если он просто шутит, вроде, «разработка приносит мне столько бабок, что поработаю два часа и найму трех нищих врачей стричь мне лужайку». Хуже, когда говорит серьезно: «Ты зря стал писать код. Вся ирония этой индустрии в том, что став хорошим разработчиком, ты обретаешь навыки, которые приводят тебя к выводу, что разработчиком быть плохо».

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

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

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

Конечно, скажете вы, можно написать скрипт, который будет делать все это за нас. Но тут возникает проблема. Скрипт может написать только программист или человек, который понимает, как это делать. Поддерживать скрипт придется ему же. Мы нашли более простое и логичное решение — это семантическое моделирование.

Семантическое моделирование позволяет всю логику работы доски в Trello записать на естественном языке.

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

---

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

Мысли Криса Койера

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

От переводчика

Всем привет, с вами Максим Иванов, и сегодня мы поговорим на довольно острую тему в сфере веб-разработки. Как утверждает Крис Койер, frontend-разработчик должен разбираться в очень многих вещах, о которых не все даже и задумываются. Конечно, мы должны понимать, что frontend-разработчик не главный в процессе разработки любого онлайн-сервиса или ПО в целом. На ту же позицию frontend-разработчика вы найдете больше откликов на вакансию, чем на позицию backend-разработчиком. Но почему же тогда Крис Койер считает, что работать frontend-разработчиком сложнее, ибо ты должен специализироваться во всем. Конечно, ситуаций в жизни очень много, разные компании по-разному используют своих специалистов, но в чем наверняка должен разбираться frontend-разработчик? Об этом мы сегодня и поговорим. Жду комментариев на эту тему, а сейчас приступим.

Дэн Бриклин (Dan Bricklin), соавтор первой программы для работы с электронными таблицами VisiCalc, очень любил снимать видео. Тридцать лет назад это было странное хобби, потому что приходилось повсюду таскать с собой громоздкую видеокамеру. Однако, благодаря Бриклину сейчас мы имеем возможность увидеть редчайшие записи, такие как презентация компьютера Mac Стивом Джобсом в 1984 году.

Ещё одно видео записано на компьютерной выставке COMDEX в ноябре 1983 года. Дэн Бриклин ходил между стендами и снимал всё подряд. Если перемотать на 6 мин 55 сек, то можно увидеть стенд Microsoft и демонстрацию графического интерфейса Windows. Видеозапись сделана за два года до официального релиза Windows 1.0, который состоялся 20 ноября 1985 года!

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

Традиционно рекомендации по обучению десятипальцевой печати сводятся к двум советам:

• тратить нервы на клавиатурные тренажеры вроде пресловутого «Соло на клавиатуре»;
• заклеить подписи на клавишах.

Научиться печатать на клавиатуре вслепую при помощи этих способов — издевательство над собой. Каждый, кто пробовал «Соло», хотя бы раз в ярости бил по клавиатуре кулаком, и практически никто не дошел до конца. А кто пробовал заклеивать надписи на клавишах, вскоре отрывал наклейки обратно, потому что без навыка и без подписей печатать невозможно, а жить дальше как-то надо.

Что если я скажу вам, что есть абсурдно простой, состоящий из одного пункта способ научиться слепой печати без этих дурацких органичений?
 

В моей практике довольно часто возникают ситуации, когда на презентации работы присутствует большая аудитория. Например,  пять и более человек. Директор, менеджер, «начальник транспортного отдела», люди, которые просто мимо проходили. В одной из крупных компаний на презентацию позвали… уборщицу… Буквально: «Марья Васильевна, зайдите, посмотрите! Что вы видите?».
Когда на презентации присутствует такое количество людей, вероятность того, что работа будет принята, зачастую равна нулю.

Предварительная подготовка.
Вы должны знать всё о  своей работе, все паразитные ассоциации, все подводные камни. Будьте готовы ответить на любой вопрос о вашей работе, пояснить сокральный смысл каждого изгиба. Сделайте немного больше, чем от вас ожидают. Это всегда вам  плюс.

"… и пусть никто не уйдет обиженным..."

или пусть уходят, зато

"… правду говорить легко и приятно..."

---

Собственно проблема

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

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

Компания знает, что всегда нужно сообщать причины отказа, иначе «карма компании упадет, а бизнесу будет нанесен непоправимый урон». Сам по себе этот тезис явно спорный, но безусловно, элементарная этика требует поставить все точки над «i» и корректно завершить общение с соискателем. Поэтому будем отвечать всем и всегда.

Формулировать отказы дело не такое уж и простое. Хорошо, если есть четкая объективная причина, в которой «ничего личного — только бизнес». Ну, например:

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

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

Еще хуже, когда очевидно, что озвучивание реальной причины отказа вызовет разочарование и даже обиду претендента. Вот описание ситуаций-задачек, которые основаны на опыте проведения технических собеседований на позиции C++ и .NET разработчиков, а также тестировщиков в компании среднего размера, успешно работающей на рынке аутсорсинга более 10 лет. Все эти ситуации почти реальны, но специально сделано так, что полностью по всем описанным обстоятельствам не проецируются на конкретных людей. Все эти люди интересны, а в перспективе или при изменении каких-то обстоятельств могут быть просто необходимы. Со всеми из них происходило общение, проведены собеседования, они все вполне симпатичные люди. Но прямо сейчас никого из них принять на работу компания не готова.

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

---

Последнее время в Сети активизировалось брожение вокруг космических изысканий. И это понятно, то там новые солнечные батареи изобрели, с удивительным КПД, то здесь микроспутники стандартизировали и Arduino в космос запустили, то то, то это. А когда Curiosity удачно примарсился и стал передавать изображения, тут уж сам Бог велел общественности взорваться в обсуждениях.
И это закономерно, назрело уже, так сказать. Больно уж много времени прошло с полета первого спутника, первого человека и высадки на луну. А воз, как говорится, и ныне там. Кардинально нового в космической отрасли ничего не произошло, никаких громких прорывов, только улучшения и улучшения… Отсюда и повышенный интерес к теме, люди чувствуют, что пришло время для новых свершений.

Далее прошу под кат, будет много эмоций и фотографий.

Eric Ligman, Директор по партнерским программам компании Microsoft, опубликовал в блоге ссылки на большую бесплатную коллекцию книг Microsoft по самым разным направлениям: SharePoint, Visual Studio, Windows Phone, Windows 8, Office 365, Office 2010, SQL Server 2012, Azure, Cloud, Lync, Dynamics CRM и т.д.

*Желтый заголовок, не обращайте внимания. На самом деле название поста «Почему я не люблю смотреть длинные видео, когда можно сказать тоже самое в двух словах», но он бы был не таким привлекательным.

Я не против YouTube, как и не против всех других видео-хостингов(наверное, исключая vimeo, которое отвратительно воспроизводится на мобильных устройствах и старых браузерах.). Они позволили очень быстро и легко делиться видео(помните, эти ужасные ссылки на сайтах «скачать видео-ролик, avi, 5.4mb»?), что, несомненно, плюс.



Конечно, в НЕКОТОРЫХ случаях без видео не обойтись.

Но вот что мне категорически не нравится — видео-обзоры, и большинство видео-инструкций.
Сейчас я играюсь с планшетом Ramos W6HD, и в числе прочих, ставил прошивку, собранную одним из энтузиастов. Позволю себе привести пример с этой страницы.

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

У меня, как и у многих других программистов, есть слабость: я очень люблю различные планерки, на которых обсуждаются новые проекты и идеи. Все презентации в моем представлении делятся на 3 вида: муторное чтение цифр успеваемости начальника транспортного цеха, демонстрации системы из рук и презентация идей и решений при помощи построителя презентаций. Если с демонстрацией системы из рук программисты знакомы по сдаче лабораторных в университетах, а монотонно читающие тексты «коты баюны», постепенно вымирают как класс, то с презентациями у нашего брата явный напряг. Менеджеры еще прошли либо просмотрели курсы «молодого построителя презентаций», то молодежь ограничилась книгами типа «Уроки ПоверПоинта за 24 часа» или хуже того, один раз увидели и самотыком изучили сей продукт буржуазной экономики. Поэтому, просмотр их презентаций вызывает приступ тошноты, не говоря уже о том, что их часто перебивают, вызывая на «живое» общение. Ориентироваться в их презентациях невозможно и зачастую бессмысленно. А ведь для того чтобы создавать красивые презентации нужно немного. Попробую составить список «наставлений для программистов», что делать нельзя и что нужно.

Интервьюер: Итак, вы считаете себя плотником?
Плотник: Всё верно. Это именно то, чем я занимаюсь.

Интервьюер: Как долго вы занимаетесь этим?
Плотник: Десять лет.

Интервьюер: Очень хорошо. А теперь я бы хотел задать вам несколько технических вопросов, чтобы оценить, насколько вы впишетесь в нашу команду. Договорились?
Плотник: Конечно, было бы неплохо.

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

Интервьюер: Да, я понимаю, но не могли бы вы подсказать мне, сколько у вас опыта именно с коричневыми? Ну, плюс-минус.
Плотник: Я действительно понятия не имею. С того момента, как дом построен, меня не волнует, в какой цвет его покрасят. Может, шесть месяцев?

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