Pull to refresh
58
0
Edtech на удаленке @Skyeng-Habr

Пишем код, который меняет систему образования

Send message

Счастье в метриках: про приоритизацию, потребности и эмоции

Reading time 11 min
Views 2.5K

Skyeng в этом году отпраздновал свою девятую годовщину. Все девять лет у компании есть 2 вида клиентов: ученики и преподаватели. Про учеников вы точно слышали, а вот про преподавателей — скорее всего нет.

Девять лет с компанией сотрудничают тысячи учителей со всего мира, сейчас их примерно 13 000. Преподаватели — партнеры сервиса и его же пользователи.

Меня зовут Алёна Медведева, я менеджер продукта для учителей в Skyeng. Моя базовая задача — сделать так, чтобы учитель делал то, что у него получается лучше всего – проводил уроки. А моя команда обеспечивает ему мягкую незаметную поддержку на остальных шагах.

Но так было не всегда.

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

В этой статье я расскажу:

Читать далее
Total votes 8: ↑7 and ↓1 +6
Comments 0

«Ну что, я уже мидл?»: байки из-за кулис онлайн ИТ-курсов

Reading time 10 min
Views 16K

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

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

Читать далее
Total votes 21: ↑14 and ↓7 +7
Comments 9

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

Reading time 8 min
Views 12K

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

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

Читать далее
Total votes 19: ↑18 and ↓1 +17
Comments 2

Как мы делали планшет

Reading time 10 min
Views 18K

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

Читать далее
Total votes 133: ↑131 and ↓2 +129
Comments 84

Как мы быстро распилили монолит, когда командам стало тесно

Reading time 6 min
Views 5.7K

Преподаватели Skyeng не сразу попадают «на передовую» — для начала они проходят отбор и обучение. Направление найма и онбординга преподавателей появилось в 2015 году — тогда же был сделан первый коммит в наш (уже бывший) легаси-монолит. Прежняя команда активно его поддерживала и старалась развивать, но в один момент ей стало объективно сложно справляться со всеми проектами. Так появилась моя команда.

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

Читать далее
Total votes 24: ↑22 and ↓2 +20
Comments 9

Грабли WebRTC: как мы допиливали чужой велосипед

Reading time 5 min
Views 13K

В пике на нашей образовательной платформе проходит до 4 тысяч уроков в час. Основной инструмент общения преподавателя и студента — видеосвязь, потому что для обучения важно видеть и слышать друг друга. В самом начале мы использовали Skype, но его нельзя было интегрировать в платформу и логировать уроки. Потом мы перешли на SaaS-решения, но это оказалось очень дорого. Мы начали искать альтернативы и 2016 году отказались от покупных решений в пользу WebRTC и Janus. Теперь дорабатываем видеоконференции под образовательную платформу силами собственной команды. Да, пришлось копнуть глубже и потоптаться по граблям чужой технологии.
Рассказываем, как мы выкручивались и улучшали видеосвязь, чтобы она не попадала в топ жалоб от клиентов.

Читать далее
Total votes 30: ↑28 and ↓2 +26
Comments 20

Трассировка и логирование в микросервисах: как мы втаскивали единый стандарт на 30 независимых команд

Reading time 6 min
Views 14K
Сервисы падали, падают и будут падать

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



Например, наша команда сопровождения маркетинга в Skyeng знала: пользователь с таким-то айдишником нажал в личном кабинете кнопку «Сменить преподавателя» — постучался в наш сервис, дальше ушло три сообщения, в очереди было 2 вызова сервисов и эти сервисы ответили 200. Но на самом деле, что было у команд сопровождения учителей или биллинга, к которым мы стучались, не знал никто…

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

Читать дальше →
Total votes 38: ↑37 and ↓1 +36
Comments 15

НЕкостыль: gRPC-клиент на PHP в продакшене

Reading time 4 min
Views 13K
Привет! Я хочу показать, что завести gRPC на PHP — это нормальное боевое решение, которое пишется быстро, легко разворачивается и может быть для вас проще, чем сокеты.


Читать дальше →
Total votes 21: ↑20 and ↓1 +19
Comments 12

Мне кажется, дело не в языке, а в том, как на нем пишут

Reading time 4 min
Views 8.7K
«Летом между 2 и 3 курсом я пошла искать работу — а в Новосибе того времени почти все вакансии для ребят без опыта были про PHP. Начинала с очень простых вещей — WordPress, Drupal… Потом писала бэкенды на Yii и много еще разного. Go впервые попробовала в 2014-м, вдохновившись докладом, и затем часто находила работу, связанную с разработкой на нем, через сообщество.

Считается, что Go гораздо проще поддерживать, чем PHP. Я не согласна. Видела очень много чистого, легко читаемого и поддерживаемого кода на PHP, а сейчас время от времени встречаю много плохо написанного кода на Go. Проблемы начинаются тогда, когда мы не следуем лучшим практикам языков и систем, которые разрабатываем… Или когда выбираем для своих задач не тот инструмент», — Елена Граховац, руководитель ПК GolangConf 2019 и соведущая подкаста GolangShow.


В эту субботу днем обсудим типичные ошибки выбора в стриме с Леной, Сашей Макаровым и другими замечательными людьми. Подключайтесь.
Total votes 33: ↑26 and ↓7 +19
Comments 8

«Конституция» для разработчиков: как страничка на GitHub помогает нам не ругаться уже год

Reading time 7 min
Views 17K
Год назад моя команда выросла: усложнялась бизнес-логика, по сути, мы делились на три подкоманды — в каждой были как новички, так и те, кто работал в компании годами. Подкоманды сфокусировались на своих направлениях, и хотя все пилили биллинг, перестал работать принцип общей зоны ответственности. Да и практики, которые работали у «старичков», не всегда подходили новому коллективу.



Обычно для сплочения команд мы практикуем выезды: ребята, в остальное время работающие на удаленке из своих городов, собираются в одной точке мира. Днем вместе проходят часть спринта, вечером вместе развлекаются. Но сроки поджимали, поэтому мы пошли другим путем. Вот что мы придумали — и кажется, такой подход может использовать любая команда, в которой нет авторитарного управления.
Читать дальше →
Total votes 55: ↑53 and ↓2 +51
Comments 22

Ищем смысл в код-ревью

Reading time 6 min
Views 7.2K
«Как-то давно мы делали код-ревью, отписывая комменты в почте с указанием номера строк. Это было очень весело. Из плюсов: никто по диффам ничего не смотрел, смотрели в IDE. Но был и минус: после какого-то мержа номера строк менялись».
Александр Макаров, Yii
«В нашей компании есть интересно понятие — стул-реквест. Это когда в рамках одного офиса разработчик подкатывается к тебе на стуле и говорит: „Посмотри, это же быстрее, чем пул-реквест создавать“».
Антон Морев, WormSoft

Недавно на ютубе прошла публичная запись подкаста SDCast о код-ревью. Мы отобрали и расшифровали самое интересное из выпуска.
Total votes 18: ↑18 and ↓0 +18
Comments 18

История одной блокировки и разблокировки в Google Play

Reading time 5 min
Views 10K
Все началось в 6 утра 12 мая. На связанную с нашими аккаунтами почту пришло «письмо несчастья».

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


Почта no-reply как бы намекала...
Читать дальше →
Total votes 44: ↑43 and ↓1 +42
Comments 45

«Я — первый слепой разработчик в своей компании». Часть 1

Reading time 4 min
Views 27K
То, что я не вижу, стало ясно в первые месяцы после рождения. Сколько родители ни пытались, зрение восстановить не удалось. С четырёх лет я учился читать и писать по Брайлю.

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



Вот уже полгода я работаю настоящим software engineer. В самой обычной команде. До сих пор не верится)

Как я начал программировать

Total votes 108: ↑106 and ↓2 +104
Comments 94

Удаленка как угроза

Reading time 2 min
Views 19K
Среди сценариев, как будет выглядеть мир после пандемии, я не видел одного. Очень грозного и максимально вероятного. Удаленка ударит по тем, кто привык работать абы как. А больше всего таких, очевидно, в Москве.
Читать дальше →
Total votes 43: ↑25 and ↓18 +7
Comments 119

Рефакторим параллельно с разработкой: наш опыт и два чек-листа

Reading time 6 min
Views 9.2K


Для множества команд рефакторинг — это боль. Потому что если ты занимаешься рефакторингом, то не разрабатываешь основной продукт, а если не занимаешься — растет технический долг проекта. В какой-то момент команды приходят к мысли: «Давайте разграничим рефакторинг и разработку и выделим на него, например, 20% наших человеко-часов, а остальное время продолжим заниматься разработкой!» Мысль эта неплохая, вот только дело в том, что на каждые 100 разработка-часов вы никогда не получите 20 чистых часа рефакторинга. Потому что «разработка» — это не только работа с кодом.

Если мы говорим о зрелых командах, а не сжатых в материальную точку мини-коллективах на 3-5 человек, то «разработка» включает в себя еще целую массу различных активностей команды кроме написания кода. В «разработку» можно записать так нелюбимые многими митинги, работу с документацией, ведение отчетности в таск-менеджерах и так далее. Все это съедает примерно 30% от наших часов, выделенных на разработку. И как-то незаметно у нас получается, что вместо картины «80 часов кодим, 20 часов рефакторим» мы получаем неприглядную цифру в ~13 часов на, непосредственно, сам рефакторинг, потому что все остальное было поглощено другими активностями.

Ниже мы расскажем, как все же совместить разработку с рефакторингом так, чтобы технический долг проекта не рос, будто снежный ком, а еще поговорим о правильном распределении времени и расстановке приоритетов.
Total votes 36: ↑31 and ↓5 +26
Comments 15

Когда стоит проверять гипотезу о не меньшей эффективности?

Reading time 9 min
Views 3.8K

Статья от команды Stitch Fix предлагает использовать подход клинических исследований не меньшей эффективности (non-inferiority trials) в маркетинговых и продуктовых A/B тестах. Такой подход действительно применим, когда мы тестируем новое решение, имеющее преимущества, неизмеряемые тестами.

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

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

В любом случае, этот подход кажется интересным, т.к. за счет уменьшения необходимого размера выборки может увеличить скорость тестирования, а, значит, и скорость принятия решений. — Дарья Мухина, продуктовый аналитик мобильного приложения Skyeng.
Читать дальше →
Total votes 19: ↑19 and ↓0 +19
Comments 0

Управляем асинхронностью в PHP: от промисов к корутинам

Reading time 7 min
Views 18K


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


Представляем перевод статьи из блога бэкенд-разработчика Skyeng Сергея Жука.

Читать дальше →
Total votes 26: ↑22 and ↓4 +18
Comments 2

Гид по параллельному масштабированию Amazon Redshift и результаты тестирования

Reading time 6 min
Views 2.2K
image

Мы в Skyeng пользуемся Amazon Redshift, в том числе параллельным масштабированием, поэтому статья Стефана Громолла, основателя dotgo.com, для intermix.io, показалась нам интересной. После перевода — немного нашего опыта от инженера по данным Данияра Белходжаева.

Архитектура Amazon Redshift позволяет масштабирование путем добавления новых узлов в кластер. Необходимость справляться с пиковым количеством запросов может привести к избыточному резервированию узлов (over-provisioning). Параллельное масштабирование (Concurrency Scaling), в отличие от добавления новых узлов, наращивает вычислительную мощность по мере необходимости.

Параллельное масштабирование Amazon Redshift дает кластерам Redshift дополнительные мощности для обработки пикового количества запросов. Оно работает путем перенесения запросов на новые «параллельные» кластеры в фоновом режиме. Запросы маршрутизируются на основе конфигурации и правил WLM.
Читать дальше →
Total votes 9: ↑8 and ↓1 +7
Comments 0

Асинхронный PHP. Зачем?

Reading time 7 min
Views 28K
image

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

Представляем перевод статьи бэкенд-разработчика Skyeng Сергея Жука.
Читать дальше →
Total votes 27: ↑22 and ↓5 +17
Comments 18

Как исследователи в Uber применяют и масштабируют знания о поведении человека

Reading time 10 min
Views 7K
image

Мы подготовили для читателей Хабры перевод статьи команды Uber Labs. Коллеги из Uber описывают процесс работы аналитиков узкоспециализированного типа (в области науки о поведении) в рамках огромной корпорации, как устроено их взаимодействие с аналитиками других типов (UX-исследователи, продуктовые аналитики) и коллегами из других команд (продуктовых, внутренней разработки), какие задачи они решают и как к ним подходят. Комментирует материал Глеб Сологуб, директор по аналитике Skyeng.

В Uber Labs мы стремимся использовать идеи и методы науки о поведении, чтобы создавать интуитивно понятные и приятные программы и продукты. Члены нашей команды имеют ученые степени по психологии, маркетингу и когнитивным наукам, обладают знаниями предметных областей — таких, как принятие решений, мотивация и обучение, методологические возможности в дизайне экспериментов, а также являются экспертами по статистическому моделированию и причинно-следственным подходам. Эти знания позволяют нам глубоко анализировать проблемы повышения степени удовлетворенности клиентов, а благодаря нашему опыту в области методологии и статистики мы можем измерить влияние удовлетворенности на бизнес (одним из таких подходов является моделирование посредника).
Читать дальше →
Total votes 17: ↑15 and ↓2 +13
Comments 0
1

Information

Rating
Does not participate
Works in
Registered
Activity