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

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

Как сделать участие в олимпиаде привлекательным для ребенка

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

От редакции блога: наверняка многие помнят историю про поселок программистов в Кировской области — начинание экс-разработчика из Яндекса впечатлило многих. А наш разработчик решил создать свое поселение в братской стране. Передаем ему слово.



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

Как и многие разработчики, я не привязан к офису. Что делает человек, который не обязан ежедневно ездить в контору? Один отправится жить на Бали. Другой осядет в коворкинге или на родном диване. Я же выбрал совсем другое направление и переехал на хутор в белорусских лесах. И теперь от меня до ближайшего приличного коворкинга 130 километров.

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

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

Профессиональная литература — сложный вопрос, особенно если говорить о литературе для руководителей в сфере IT. Чтобы понять, на что потратить вечно не хватающее время, мы опросили подписчиков канала «Тимлид Леонид» и собрали подборку из полусотни книг*. А затем добавили отзывы наших тимлидов к самым популярным. Так как список ниже глубоко субъективен и основан на отзывах незнакомых вам людей, оценивать литературу мы будем в «сферических совах».

---

1. «Джедайские техники. Как воспитать свою обезьяну, опустошить инбокс и сберечь мыслетопливо» / Дорофеев Максим

TL;DR

Из книги вы узнаете:

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

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

Оценка: 6,50 сферических сов.

---

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



Кстати, обо мне. Меня зовут Наташа, я работаю в Skyeng на позиции Data Scientist и вовлечена в разработку различных продуктов компании. Почему я заговорила о внезапных звонках? Общение голосом с клиентам, которые только хотят начать или по какой-то причине резко прервали обучение — часть модели работы в компании. Звонки помогают вовлечь и вернуть людей в процесс изучения языка, либо напрямую узнать, что же пошло не так. Одна из моих последних задач — анализ работы нашего колл-центра. Я помогла им подобрать оптимальное время для выхода на контакт со студентами по всей России и СНГ: потому что звонки в случайное время суток никто не любит, а бесить собственных пользователей — последнее дело.

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

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



Вот, например, Краснодар. По части климата там всё отлично: мягкая, довольно тёплая зима; жаркое, но не до адского пекла, лето; Чёрное море — в 120 км, Азовское — в 140. Жизнь заметно дешевле, чем в столицах, а сам город меньше — а потому тише и спокойнее. Кроме того, у Краснодара есть бонусы, каких не может предложить Таиланд: например, достаточно активное IT-сообщество. И не только.

Привет, в следующий вторник на Таганке планируются теплые ламповые посиделки: будет Артем Науменко с рассказом про инфрастуктуру как продукт, Виталий Добровольский с докладом про балансировку кластера Kafka и ведущие профильного подкаста с пока секретной темой для обсуждения. А еще мы ожидаем специального гостя из северной столицы — Виталия Левченко, организатора питерской SRE-тусовки.

UPD. Места в зале закончились, но мы проведем трансляцию на этом канале. Подключайтесь онлайн!



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

Привет, этим постом мы хотим вызвать тимлидов на разговор. А точнее, запустить проект “ТимлидПозвонит”, в котором раз в две-три недели наши Петр anotherpit, Кирилл flashhhh и Артем arasskosov будут звонить интересному гостю через Google Meet и общаться на наболевшую тему.

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

1. Я собеседовал вслепую

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

Я не люблю такие обобщения. Да, что-то есть только в «двух столицах»: когда мы (JUG Ru Group) делали конференцию в Новосибирске, столкнулись с отсутствием нужного оборудования. Но в том же городе живёт известный многим Тагир lany Валеев, там он работает над IntelliJ IDEA, готовит крутые доклады и хабрапосты. И как тогда говорить, что там нечего делать?

Скоро мы проведём в Петербурге фестиваль TechTrain со слоганом «Узнай, чем живут другие», и там будут представлены многие IT-сообщества. А недавно в отпуске я ездил поездами по городам Транссиба, и фестиваль подал мне идею: в поездке узнать, чем живут айтишники в других городах, пообщавшись с активистами местных IT-сообществ. Я расспрашивал о их деятельности, о том, что в городе с IT, и о решении жить не в Москве. Делюсь с Хабром результатами.

Полтора года назад, читая работы про уязвимости Meltdown и Spectre, я поймал себя на том, что не очень понимаю разницу между сокращениями i.e. и e.g. Т.е. по контексту вроде бы понятно, но потом вроде бы как-то и не совсем то. В результате я тогда сделал себе небольшую шпаргалку именно по этим сокращениям, чтобы не путаться. И тогда же появилась идея этой статьи.

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

Привет, я Алексей, full-stack разработчик платформы Vimbox. Когда я пришел в Skyeng, здесь решали, стоит ли тратить время на систему автотестов и попросили меня поделиться опытом с предыдущей работы. А такой опыт у меня был: к моменту ухода с предыдущего места мы написали на php и крутили больше 3 тысяч тестов. В итоге я сделал небольшую внутреннюю презентацию, рассказывающую о граблях, на которые успел наступить за несколько лет разработки этих автотестов, борьбы за их скорость, читабельность кода и общую эффективность. Презентация показалась коллегам полезной, поэтому я переложил ее в текст, чтобы оказаться полезным также и более широкой аудитории.

Для начала – термины, о которых пойдет речь в статье:

• Приемочный тест – end-to-end тест: здесь браузер или эмулятор браузера исполняет сценарий
• Модульный тест (юнит тест) – тест метода
• Функциональный тест – тест контроллера или компонента, если речь о фронтенде
• Фикстура – состояние тестового окружения, необходимое для работы теста (глобальные переменные, данные в БД и прочие участники сценария теста)

Привет, я Андрей Шальнев, QA Automation Lead в проекте Skyeng Vimbox. В течение года мы с командой занимались оптимизацией процессов автоматического тестирования и сейчас вплотную подошли к ее финальной стадии. А это хороший повод выдохнуть, пересмотреть бэклог и подвести какие-то промежуточные итоги. Для Хабры я решил сделать подборку из десяти наиболее полезных и при этом простых вещей, которые помогли нам справиться с задачей оптимизации автотестов. Надеюсь, статья пригодится QA-командам в растущих компаниях, где старые процессы тестирования уже не справляются с нагрузкой, и вопрос реорганизации встает ребром.

Всем привет, меня зовут Виталик, я senior фронтенд-разработчик Skyeng. Наша команда делает онлайн-платформу Vimbox для изучения английского языка. Примерно год назад мы с дизайнером доделали небольшой UI kit, искоренивший хаос в интерфейсе и кодовой базе.

Оказалось, что в компании не мы одни хотели UI kit, и к нам стали приходить другие команды за советом «как написать собственный». Нам удалось отговорить их от этой затеи, пообещав темизировать свой – это сэкономило компании сотни часов разработки. Выбирая решение, мы рассмотрели Angular Material, кастомизированные сборки и CSS Variables и в итоге остановились на последних, несмотря на их слабую совместимость с SCSS, основой имевшегося UI kit. Под катом – подробности того, что мы сделали.

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

• Объединение iOS- и Android-разработчиков в одну команду
• Создание рабочих групп для решения сложных задач
• Экономия на ведении документации
• Написание общего кода

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

Techlead Skyeng Кирилл Роговой (flashhhh) выступает на конференциях с докладом, в котором рассказывает о навыках, развивать которые стоит каждому хорошему разработчику, чтобы стать лучшим. Я попросил его поделиться этой историей с читателями Хабры, передаю Кириллу слово.

Миф про хорошего разработчика гласит, что он:

1. Пишет чистый код
2. Знает много технологий
3. Быстрее кодит задачи
4. Знает кучу алгоритмов и шаблонов проектирования
5. Умеет отрефакторить любой код по Clean Code
6. Не тратит время на непрограммистские задачи
7. 100% мастер своей любимой технологии

Так видят идеальных кандидатов HRы, и вакансии, соответственно, выглядят тоже так.

Но мой опыт говорит, что это не сильно соответствует действительности.

Управление временем – это на самом деле не решение, а часть проблемы

Автор статьи: Адам М. Грант, американский ученый-психолог и писатель; профессор Уортонской школы бизнеса; автор трёх бестселлеров Нью-Йорк Таймс, а также книги «В работу с головой. Паттерны успеха от IT-специалиста».

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

«Это прозвучит, как шутка, но на самом деле всё серьёзно, — признался он. – Единственное, что мне пришло в голову – пить меньше воды, чтобы не бегать так часто в туалет».

В 20-м веке жизнь и работа людей шли по плану. На работе (упрощая — можно представить завод) у людей имелся четкий план на неделю, на месяц, на год вперед. Упрощая: тебе надо выпилить 20 деталей. Никто не придет и не скажет, что деталей теперь надо выпилить 37, а кроме того, написать статью с размышлениями о том, почему форма этих деталей именно такая — и желательно вчера.

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

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

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

Утром 1 октября 1970 года ученый-компьютерщик Виктор Глушков вошел в Кремль, чтобы встретиться с Политбюро. Он был настороженным человеком с пронзительными глазами в черных очках, с таким типом ума, который, решая одну проблему, мог найти параллельно метод решения всех аналогичных проблем. В тот момент у Советского Союза возникла серьезная проблема. Годом раньше Соединенные Штаты запустили ARPANET, первую распределенную компьютерную сеть с коммутацией пакетов, которая со временем породит интернет, каким мы его знаем сегодня. Распределенная сеть изначально была разработана с целью опередить СССР, позволяя компьютерам ученых и правительственных лидеров США обмениваться информацией даже в случае ядерной атаки. Это была высшая точка технологической гонки, и Советы должны были чем-то ответить.

Некоторое время назад «Мой круг» принял участие в дискуссии, организованной нашими друзьями из Index School и посвящённой трудоустройству начинающих специалистов. Организаторы поставили перед участниками встречи следующую проблему:

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

Дискуссия получилась оживленной, и  еще больше заострила поставленные вопросы. Мы решили изучить тему начинающих ИТ-специалистов глубже и провели опрос среди пользователей «Хабра» и «Моего круга». Собрали более 2000 ответов, визуализировали их с помощью диаграмм и сегодня рады поделиться получившимися результатами.

В августе @eyeofhell, voldar и их коллеги по сообществу MoscowPython начали записывать подкаст Python Junior. Это — расшифровка избранных моментов одного из выпусков.



Валентин Домбровский: Ты ведешь Telegram-канал addmeto. Говоришь про всякое прекрасное будущее, технологии и так далее. Какую роль Python будет играть в этом всем, на твой взгляд?

Григорий Бакунов aka bobuk: Очевидно, куда двигается все программирование. Мы чем дальше, тем ближе к Lego.

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

И поэтому Python сейчас так и рванул.