Это задачки с https://exercism.io/ , он хорош, чтобы изучить или вспомнить синтаксис языка. Можно выбрать трек с менторами, тогда ваши решения будут отправляться на код-ревью. Я пошла этим путём, когда решала задачки на эликсире, было довольно полезно.

Что касается питона, то я немного писала на нём, когда выбирала, куда уйти с php в конце 2000-х. Это были какие-то простые пет-проекты, не для прода. В то время руби больше привлёк своей красотой и культурой (?), сейчас пытаюсь вспомнить истинные причины 😅. С тех пор питоном особо не занималась, разве что иногда становится интересно что-то вроде "а как там работает множественное наследование" и т.д. и я поверностно читаю на тему.

Если нет повода, то не так интересно изучать язык, который относительно похож на мой основной.
Как Авди писал (http://www.virtuouscode.com/2015/05/08/a-personal-programming-language-roadmap/):
> Python: a fine language, but too similar to Ruby to be worth re-acquainting myself at this point.
Вот и у меня что-то похожее.
Сейчас возник некоторый исследовательский интерес, хотя глубоко изучать питон так и не планирую.

Btw, буду на RubyRussia в субботу, буду рада пообщаться ✨

Открылась регистрация на хактоберфест
https://hacktoberfest.digitalocean.com/

Сегодня начинается хактоберфест, приходите контрибьютить ко мне на рабочий проект.
https://github.com/thepracticaldev/dev.to/issues

Стек - ruby/rails, на фронтенде preact(это почти как реакт :) и ванильный js.

Обратите внимание на задачи с тегами - "hacktoberfest", "help wanted", "good first issue"
Есть теги и по технологиям, начинаются с "tech" (например, "tech: html/css")

Парочка задач от меня:
- Уйти от вызовов delay (специфичных для DelayedJob) и сделать вместо них ActiveJob'ы ==> https://github.com/thepracticaldev/dev.to/issues/3136
Почти всё уже сделано руками контрибьютеров, осталось несколько пунктов.

- Удалить старые методы, связанные с уходом от DelayedJob ==> https://github.com/thepracticaldev/dev.to/issues/2950

- Добавить дату публикации подкаста ==> https://github.com/thepracticaldev/dev.to/issues/3498
Люди вызывались делать, но результата не видно, поэтому смело можно брать.

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

Доки по установке в readme проекта и здесь ==> https://docs.dev.to/installation/
Если что, обращайтесь (@lightalloy)

#devto

Недавно сделали интеграцию DEV со стекбитом, напишу про неё.
Stackbit -- это приложение для быстрого создания JAMstack-сайтов. JAMStack - это альтернатива традиционным CMS типа вордпресса, как-нибудь напишу про него подробнее.
Stackbit интегрирует генератор статический сайтов (jekyll, gatsby, hugo, etc), headless CMS (Netlify, Contentful, etc) и инструменты для деплоя (Netlify) + делает для вас репозиторий (пока только на гитхабе).

В нашем случае DEV выступает в качестве CMS. То есть если у вас есть посты на DEV, можно зайти в раздел "интеграции" в настройках, нажать кнопку "Connect to Stackbit", выбрать тему и генератор, и через некоторое время получить готовый сайт, примерно такой: https://terrific-velociraptor-e1366.netlify.com/
Доработать его можно просто внеся изменения в репозитории на гитхабе. Я практически ничего не меняла, поэтому сайт выглядит убого :D

С технической стороны реализовано так:
- когда первый раз интегрируетесь со стекбитом, даёте доступ oauth-приложению
- stackbit получает доступ, берёт данные о постах по апи, делает свою магию, и создаёт сайт
- stackbit по апи регистрирует вебхуки(https://en.wikipedia.org/wiki/Webhook) на DEV
- когда кто-то обновляет или создаёт пост, мы смотрим, есть ли соответствующие вебхуки, и отправляем события с нужной информацией на url'ы этих вебхуков

Вебхуки и события -- это интересная тема в техническом плане. Но мы пока решили остановиться на самом простом варианте, а потом посмотрим, в какую сторону развивать фичу. Сейчас реализация похожа на ту, которая описана в статье https://benediktdeicke.com/2017/09/sending-webhooks-with-rails/ , (только без коллбеков! 😂)

#devto #работа

1 и 2 ноября мы провели RailsGirls. Наконец-то напишу о нём.

Для тех, кто не знает, RailsGirls — это воркшоп для девочек и женщин, на котором они могут познакомиться с Ruby, Rails и программированием в целом.
Большая часть мероприятий RG нацелена на абсолютных новичков. За 1-2 дня научить программированию и даже дать основы невозможно, поэтому основная цель — просто показать, что такое программирование, дать идеи, как и чему дальше учиться, как в будущем начать карьеру.

Мы начали подготовку за 2 месяца, мне казалось, что у нас очень мало времени. Например, Django Girls требуют подавать заявку на мероприятие за 3 месяца. У RailsGirls всё более расслабленно. Мы еле добились ответа от организаторок :D (Линды Лиукас), но в итоге всё получилось, и мы смогли добавить информацию на официальный сайт. Организаторки глобальной инициативы особо не контролируют проведение локальных мероприятий. Есть кое-какие инструкции, но основные решения нужно принять самим. Например, составить расписание и решить какие материалы брать для воркшопа.

Само мероприятие мы рекламировали не так много, в основном вк, в "своём" паблике (code_sisters), в "сестра сестре" и немного в телеграме. Оттуда информация разошлась чуть дальше. Этого хватило, чтобы на 20 мест мы получили 80+ заявок. Мы постарались в первую очередь взять тех, у кого меньше знаний в it, но больше мотивации. Часто это субъективные вещи, + вмешивается случайность, поэтому состав получился разнообразный.

При подготовке у меня не было возможности делать то, что привязано к офису и городу, поэтому я переживала, как всё будет в этом плане. Но здесь всё было хорошо (Спасибо, Катя 💙) В остальном мероприятие тоже прошло без больших факапов, хотя многое можно было сделать лучше. Мы получили положительные отзывы, но хотелось бы узнать больше о том, что можно улучшить с т.з. участниц.

А вот то, чему на мой взгляд стоит уделить больше внимания.

- винда и техническая подготовка
Я сама давно не работала с виндой. Перед воркшопом мы попробовали вариант установки с RailsInstaller, обнаружили возможные проблемы и нашли решения. Но прямо перед мероприятием мне приспичило использовать wsl (windows subsystem for linux) + стандартную установку rbenv+ruby+etc, а не волшебный скрипт RailsGirls (в моей группе). На воркшопе сама установка прошла неплохо, но под конец wsl начала тормозить и начались странные ошибки, например, рандомно слетали права у файлов, завершить пришлось не на самой весёлой ноте.
Если бы я поэкспериментировала с wsl заранее, возможно, знала бы о таких проблемах.
Я ставила руби на винду в 2008-2009, через mingw или cygwin, и всё отлично работало. Но сейчас мне это уже не помогает :D

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

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

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

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

#railsgirls #моё

- "понятно, что ничего не понятно" (для участниц)
Частая тема в отзывах на воркшоп, но это как раз нормально в начале обучения. Если учиться регулярно, то со временем понимания будет больше.

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

Подборка статей от Shopify о том, как они справляются с огромным высоконагруженным монолитом.
https://twitter.com/rhymes_/status/1197115938501472263

(узнаю кое-что из Domain Driven Design)
Особенно мне понравилась идея "modular monolith". Он сочетает плюсы микросервисной архитектуры (чёткая структура, разделение зон ответственности) и монолита (отсутствие сложностей взаимодействия сервисов между собой). Конечно, Shopify проделали (и делают) огромную работу, чтобы к этому прийти. Мало у кого есть такая возможность, пока приложение не достигнет их масштабов, но всё равно кое-что можно "взять себе".

https://www.youtube.com/watch?v=ISYKx8sa53g
А вот доклад на ту же тему.

#книги 2019

https://basecamp.com/books/getting-real
"Getting Real" стала бесплатной. #книги

Выступила на Pyladies 13.02 с рекламой Ruby #моё

И DEV 😎

Как искать удалёнку?

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

Ещё я устраивалась на все работы "по объявлению". "По знакомству" как-то не попадалось привлекательных предложений: поначалу их вообще не было, а потом требования к работе взлетели до небес :D

Если говорить о поиске вакансий и изучении рынка труда, я больше люблю хоть сколько-то специализированные ресурсы (по тех. стеку, удалёнке или хотя бы просто айтишные), поэтому на хедхантер в поисках работы не хожу. Могу зайти из любопытства, посмотреть, что там за полторы вакансии в Вологде :D

Вот что я использовала для поиска и для анализа рынка:
- хабр карьера (бывший мойкруг)
- каналы в телеграме:
- @Remoteit
- @remotelist (собирает вакансии с разных сайтов, может попадаться не удалёнка или удалёнка только в US и тд. Самих вакансий очень много, надо копаться)
- @rubyjob (подставьте канал с вакансиями по своему тех.стеку)
- https://angel.co/ (работа в стартапах, есть и удалёнка, и офис, в т.ч. с релокацией. Поиск не очень удобный - при выборе удалёнки может всё равно выдавать варианты с офисом)
- stackoverflow jobs (https://stackoverflow.com/jobs)
- всякие weworkremotely (https://weworkremotely.com/)
Ещё помогает подписываться в соцсетях на интересующие компании, к-е нанимают по интересующей специализации, и вообще заглянуть на их сайты.
Во-первых можно сразу увидеть вакансии, а можно и просто найти контакты и написать им, если сильно туда хочется.

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

В прошлый раз я искала работу в конце 2018. С этого момента прошло уже много времени, но мне кажется, что это было совсем недавно, ведь до этого в Эврон я работала 8 лет. Я смотрела вакансии в источниках из списка выше в течение нескольких месяцев, но апплаилась не так много: на пару вакансий с angel.co, stackoverflow jobs, напрямую в компании.

Также и в DEV я увидела объявление у них в твиттере (или ещё где-то) и просто заапплаилась. Процесс тогда был довольно быстрым, даже без собеседования: просто анкета, обсуждение в почте, мини-тестовое в виде анализа проекта. Надо понимать, что контракторская позиция несёт мало рисков для работодателя и легко было организовать тестовый период, да и вообще легко "выселить" с работы в случае чего. Тем не менее, когда нанимали новых сотрудников в этот раз (конец 19-го, начало 20-го) процесс был куда более долгим и структурированным, как для контракторов, так и для сотрудников в США.

#поиск_работы@anna_codes

Мы снова делаем RailsGirls! (3 и 4 апреля в спб)
https://vk.com/railsgirls_spb
Делитесь с подругами, которые ещё не программируют, но хотят начать 👩🏻‍💻✨

Открыта подача заявок на RailsGirls Summer of Code.
Правила - https://railsgirlssummerofcode.org/students/application/

Стажировка пройдёт с июля по сентябрь 2020, можно участовать фулл-тайм или парт-тайм (40 или 20 часов)

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

Стажировка оплачиваемая, стипендия зависит от кол-ва "отработанных" часов. Я предполагаю, что и от места проживания тоже (рассчитают по прожиточному минимуму :D)
Проекты разные, теперь там далеко не только Ruby/Rails (https://teams.railsgirlssummerofcode.org/projects)

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

Прочитала "Shape Up" и одновременно попробовали первый цикл по похожей схеме на работе.
Книга описывает процесс работы в Basecamp. Работа ведётся 6-недельными циклами активной разработки с 2-хнедельными cooldown-ами между ними.

Сначала senior team (например, фаундеры) определяет области работы. Они пишут питчи, обсуждают их и выбирают, над чем именно команда разработки (builders) будет работать в следующем цикле. Эта работа по "шейпингу" ведётся параллельными циклами с командой разработки (https://bit.ly/2TkHTrE)

В начале цикла команды (у бейзкемпа это дизайнер + ~2 разработчика) получают питч, т.е. описание задачи.

Питч включает в себя:
- описание проблемы
- что примерно можно сделать за 6 недель
- наброски интерфейсов
- возможные детали, в которых можно надолго увязнуть (rabbit holes)
- и то, что точно делать не нужно.
Далее команда самоорганизуется, определяет задачи и выполняет их. Как именно, тоже описывается в книге. За 6 недель нужно выполнить работу и зарелизиться. По умолчанию цикл не продлевается. Cool-down используется для задач, до которых обычно не доходят руки: можно починить баги, исследовать новые технические возможности и тд + нужно определиться, что делать в следующем цикле.

Мне понравилось, что поднимаются проблемы:
- вымышленные vs "открытые" (discovered) задачи
В самом начале трудно определить, что именно нужно делать, и тем более сколько это займёт времени. Понятнее становится только когда начинаешь работать над задачей.
- число задач со временем только растёт, даже внутри нашей фичи/области работы, ограниченной питчем
Тут помогают чёткие дедлайны. Мы определяем, что успеем сделать до дедлайна, а не за какое время успеем "доделать" фичу, ведь доделывать можно бесконечно. Таким образом, имея дедлайн, мы делаем самое важное и релизим в состоянии "good enough". И речь тут идёт не о качестве продукта (типа релизим без тестов), а про урезанную функциональность. Как правило, важно далеко не всё, что изначально хотелось.

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

Мои заметки по книге - https://github.com/lightalloy/books-notes/blob/master/development/shape_up.md

Чуть позже расскажу, как у нас прошёл первый рабочий цикл.

#книги

Как мы начали использовать подход Shape Up в команде:
(определения питчей, шейпинга и т.д. в предыдущем посте)

Первый цикл, конечно, прошёл немного хаотично: в него попали встреча команды в Нью-Йорке и мои 2 отпуска по неделе (не в Нью-Йорке, к сожалению :D). Многие члены команды только начали работать и онбордились, что тоже добавило сложностей.

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

Что понравилось:
- чёткая область работы, на которую можно спокойно выделить время. До этого иногда было трудно определить, за какие именно задачи стоит браться, и как не распыляться между ними.
- чёткий дедлайн. Помогает определить, что будет "достаточно хорошо" и задеплоить фичу в срок, не растягивая работу бесконечно. Это касается не столько качества кода (не "фигачим код без тестов"), сколько необходимости урезать функциональность до необходимого минимума. Таким образом, делаем то, что действительно нужно, и не тратим время на сомнительные улучшения. Принцип "limited time, variable scope" здесь очень хорошо сработал. Кроме того, определять, что именно нужно, довольно интересно (особенно если члены команды всё-таки доступны для обсуждения)

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

Помимо этого, работа некоторых команд, например, oss (работа с контрибьютерами и не только) и SRE (Software Reliability) не вписывается в циклы и больше похожа на непрерывный процесс.
Конечно, процесс ещё не устаканился, очень многое обсуждаем и будем адаптировать под себя. Например, сейчас выделили на неделю больше на cooldown и, соответственно, шейпинг. Интересно посмотреть, как пойдёт дальше 👩🏻‍💻

#devto #работа

Присмотрела для себя новую книгу "Fundamentals of Software Architecture" =>
https://www.thoughtworks.com/books/fundamentals-of-software-architecture

Можно послушать подкаст и прочитать бесплатную главу, что я и сделала. Пока непонятно, насколько актуальна для меня сейчас, но это не так важно, т.к. темы интересные сами по себе + подобные знания обычно всё-таки получается использовать в том или ином виде (например, для размышлений о карьере :D)
Останавливает неудобный формат: либо бумага, либо киндл. Я бы предпочла пдф-ку, чтобы читать на компьютере: если покупать книгу за 40+$, хочется, чтобы было удобно 🤷🏻‍♀️

#книги