Мне всегда было интересно, как устроен Хабр изнутри, как построен workflow, как выстроены коммуникации, какие применяются стандарты и как тут вообще пишут код. К счастью, такая возможность у меня появилась, ведь недавно я стал частью хабракоманды. На примере небольшого рефакторинга мобильной версии попробую ответить на вопрос: каково это — работать тут фронтом. В программе: Node, Vue, Vuex и SSR под соусом из заметок о личном опыте в Хабре.Читать полностью »
В инвестировании есть понятие «Плохо сейчас — хорошо потом». Инвестор регулярно отщипывает 10, 20% или даже 30% своего заработка на будущее. Эти деньги он инвестирует в облигации, акции, ОФЗ, ETF — кто во что горазд. Сейчас, в моменте, инвестор отбирает у себя свой заработок, лишает себя каких-то благ, чтобы в будущем, на горизонте в 10-20 лет, получить пользу от инвестиций. Прибыль в будущем покроет сегодняшние лишения. Примерно такую же стратегию исповедует Алексей Охрименко (obenjiro), но применительно к разработке — лучше день потерять, а потом за 5 минут полететь.
На Frontend Conf 2018 Алексей рассказал, как потеряв кучу времени сейчас, в конечном счете его сэкономить потом. Этот доклад не о чувстве скуки и не о том, как бороться с монотонными и рутинными задачами, а о том как потратить время по максимуму — сколько есть, все потратить, и посмотреть, что из этого получится. В расшифровке доклада опыт написания инструментов для отладки, тестирования, оптимизации, скафолдинга и валидации под разные проекты. Бонусом Алексей расскажет о ряде уже существующих инструментов и о пользе, которую они приносят. Давайте выяснять, надо ли вообще на это тратить время.
О докладчике: Алексей Охрименко — разработчик в Avito Frontend Architecture, где немного улучшает жизнь миллионов людей. Ведет подкаст «5 min Angular», а в свободное ото сна и подкаста время организует Angular Meetup вместе с ребятами из Тинькофф, и выступает с огромным количеством разных и спорных докладов.
Читать полностью »
В Новосибирске прошла юбилейная, десятая конференция CodeFest. Программа была очень насыщенной: десять секций о разработке, тестировании, дизайне, управлении и развитии. Сотрудники True Engineering два дня конспектировали доклады, теперь хотим поделиться этой пользой с вами.
Надеемся, наш отзыв пригодится тем, кто будет смотреть видеозаписи выступлений. Часть презентаций уже опубликована в открытом доступе, поэтому мы дополнили некоторые отзывы ссылками на них. Доклады отсортированы по секциям.
Уважаемый читатель! Если вы не имеете понятия, что такое React и Redux, читать дальше не имеет смысла, дальше технический бред. Я серьезно, понимание к чему эта записка, требует работы с указанными библиотеками — несмотря на то, что я постараюсь писать понятно, это статья не начального уровня. А еще это личный опыт и мнение, основанные на практике.
Тут я надумал написать, а что собственно не так с использованием redux в моем проекте и тысячах других? Я же пишу приложения на react / redux эдак с апреля 2016 года(три года). Пора бы уже открыть некие интересности… А то лекции и доклады, особенно нацеленные на новичков, были, а вот какого-то взрослого взгляда назад и ретроспективы не было. А пока кто-то ставит звездочки пакетам, которые проверяют «а не 13 ли ты часом», я буду разбивать стену сложившихся стереотипов.
Читать полностью »
В прошлых статьях цикла мы обсудили безопасность памяти и безопасность потоков в Rust. В этой последней статье посмотрим на последствия реального применения Rust на примере проекта Quantum CSS.
Движок CSS применяет правила CSS на странице. Это нисходящий процесс, который спускается по дереву DOM, после расчёта родительского CSS дочерние стили можно вычислять независимо: идеальный вариант для параллельных вычислений. К 2017 году Mozilla предприняла две попытки распараллелить систему стилей с помощью C++. Обе провалились.
Разработка Quantum CSS началась, чтобы повысить производительность. Улучшение безопасности — просто удачный побочный эффект.
Привет! Представляю вашему вниманию перевод статьи "Refactoring — oops, I’ve been doing it backwards" автора Джастина Фуллера (Justin Fuller).
Я очень завишу от рефакторинга, и не боюсь признать это, но есть только одна проблема: я всегда делал это задом наперед. Видите ли, то, что я делал, можно было бы точнее описать как преждевременную абстракцию кода.
Мы все знаем о рефакторинге. Если вы прочитали хотя бы одну книгу по программированию или много времени сидите на Medium, то наверняка слышали об этом. Это важная концепция, которая делает код понятным, поддерживаемым и расширяемым.
Так почему рефакторинг не оправдал моих надежд?
Когда я писал свою последнюю библиотеку, мне потребовалось время, чтобы подумать об эволюции моего кода. Я понял, что до того, как у меня был полностью работающий продукт, и до того, как у меня были идеальные результаты моих модульных тестов, я преобразовал свой код в интерфейс, хотя не был даже уверен в том, понадобится-ли он мне. Я переместил код, сделал его расширяемым, многоразовым, но почему? Этот код даст мне окончательный результат, который мне нужен? Этого я еще не знал.
В конце концов, все получилось, но был ли мой код более сложным, чем нужно? Думаю, что да.Читать полностью »
Так случилось, что ваша программа написана на скриптовом языке — например, на Ruby — и встала необходимость переписать ее на Golang.
Резонный вопрос: зачем вообще может понадобится переписывать программу, которая уже написана и нормально работает?
Это продолжение истории, которая началась здесь, а продолжалась здесь и здесь.
В прошлой части я написал интеграционный тест, демонстрирующий процесс инициализации и выполнения полного набора обработчиков, извлекающих данные из базы. Но поскольку от написания этого теста, до его запуска, может пройти слишком длительное время, необходимое для кодирования не только обработчика, но и правил настройки для всех необходимых запросов к базе, то сегодня я решил реализовать его модульную версию, расчитанную на конфигурирование и запуск всего одного обработчика. Выглядит это тест вот как:Читать полностью »
В предыдущей части я остановился на том, что разрабатываемая мной команда реализует поведение, которое можно описать вот таким тестом:
it('execute should return promise', () => {
request.configure(options);
request.execute().then((result) => {
expect(result.Id).toEqual(1);
expect(result.Name).toEqual('Jack');
});
});Ускользает понимание своего или чужого кода?
Не можете вникнуть в алгоритм?
Проводите кучу время в отладке, но найти место неверной инициализации не получается, а хочется получать удовольствие от кодирования?
Вспомните о приведенных ниже правилах и примените их!
В статье не рассматриваются базовые правила именования переменных и функций, синтаксические отступы и масштабная тема рефакторинга. Рассматриваются 5 простых правил по упрощению кода и снижению нагрузки на мозг в процессе разработки.
Рассмотрим процесс восприятия данных, чтобы соотнести описанные правила с процессом восприятия и определить критерии простого кода.
Упрощенный процесс восприятия состоит из следующих этапов: