Fullstack Developer
Однажды, в качестве тестового задания на позицию PHP разработчика была предложена задача реализации сервиса проверки номеров паспортов граждан РФ на предмет нахождения в списке недействительных. Текст задания был лаконичным: «Пользовательская база 10 миллионов, время ответа 1 миллисекунда, аптайм 99%».
Не густо, но попробуем сделать из этого конфетку.
Программист ставит себе на тумбочку перед сном два стакана. Один с водой — на случай, если захочет ночью пить. А второй пустой — на случай, если не захочет.Давайте разбираться — когда сортировка в запросе точно не нужна и несет с собой потерю производительности, когда от нее можно относительно дешево избавиться, а когда сделать из нескольких — одну.
Прим. перев.: автор этой статьи — Ben Nadel, сооснователь и главный инженер InVision App Inc. Миссию своей команды, поддерживающей серверную инфраструктуру компании, он сам характеризует как «advocate for the users», т.к. её главная цель — гарантировать пользователям InVision «получение опыта, который они заслуживают». Его опыт — яркая иллюстрация того, что микросервисы не серебряная пуля.
Если вы следите за мной в Твиттере, то наверняка заметили, что периодически я публикую победные твиты о возвращении одного из наших микросервисов в InVision обратно в монолит. Обычно эти твиты сопровождаются гифкой, в которой Танос вставляет последний Камень бесконечности в Перчатку бесконечности. Нахожу ее вполне уместной, поскольку воссоединение камней придает Таносу невероятную силу — так же, как воссоединение микросервисов придает силу мне и моей команде. Меня много раз спрашивали, почему я избавляюсь от микросервисов. Настало время поделиться своими мыслями по поводу этого путешествия в мире разработки веб-приложений…
"Отзывчивый" - в данной ситуации означает "изменяющийся в зависимости от окружающих реалий".
Предлагаю вниманию свой взгляд с иллюстрациями на сущность «отзывчивого», развиваемого дизайна. Меня заинтересовал конспект лекции об «отзывчивом дизайне», поскольку текущая наша разработка идёт именно в таком ключе — функционал добавляется понемногу, в процессе уточнения и переосмысления задач, без революций, с хорошим пренебрежением к академической идеальности и законченности, которой в процессе развития просто не имеет права быть. Это по-своему замечательно — пренебрегать правилами валидности (они — для будущего), кроссбраузерности (функционал есть, но отображается в IE c долей снисхождения) и концептуальности до момента, пока функционал системы не определён. Она имеет только те куски «мяса», которые работают, отработавшие куски постепенно удаляются. Именно это описывает Кент Бек в своей лекции, поэтому так живы и богаты ассоциации с его классификацией о четырёх стратегиях.
Здравствуйте. Меня зовут Ник, я фронтенд разработчик (жидкие аплодисменты). Кроме того, что я пишу код, я преподаю в Школе программистов hh.ru.
Записи наших лекций от 2018-2019 учебного года можно посмотреть на youtube
В этом году у меня была лекция про оптимизацию производительности фронтенда, и я решил превратить ее в текстовый формат. Материал получился большим, так как лекция была длительностью 3 часа. Поэтому получился текстовый альманах.
Вот презентация для тех, кому неохота читать лонгрид, но при этом хочется иметь базовое представление о контенте.
Лонгридом можно пользоваться как справочником, чтобы не читать за один присест. Вот список тем, которые мы затронем:
Ночь. Стук в дверь. Открыть. Стоят двое. "Верите ли вы в Event loop, нашу главную браузерную цепочку?" Вздохнуть. Закрыть дверь. Лечь досыпать. До начала рабочего дня еще 4 часа. А там уже ивент лупы, лейауты и прочая радость…
В первой части мы говорили о первой загрузке и работе с ресурсами. Сегодня я расскажу о второй части оптимизации производительности фронтенда. О том, что происходит с нашей страницей, когда она загружена, на что уходит процессорное время и что с этим делать. Ключевые слова: event loop, paint \ repaint, layout \ reflow, composite.
Бывает, что посмотрев на старый код, мы говорим: «Его проще переписать, чем поменять». Печально, если речь идет о нашем собственном коде, с такой любовь написанном несколько лет назад. Head of Developer Relations в Evrone Григорий Петров в своем докладе на TechLead Conf 2020 разобрал проблемы, которые приводят к такой ситуации, и рассказал, как бороться с Software complexity problem.
В этой статье пересекаются, казалось бы, непересекаемые вещи: нейрофизиология, проклятие нулевой цены копирования, когнитивная и социальная интуиция. И, конечно же, в ней поднимается тема сложности кода. Вы узнаете о том, откуда она берется, почему ее нельзя убрать и как с ней жить.
Все говорили – переходи на rust! Начинай пользоваться самым-самым языком, который самый любимый язык на stackoverflow и всё такое.
Я тяжело вздохнул и огляделся. Ну опять двадцать-пять. Ладно, давайте разбираться, как правильно покрывать всё ржавчиной.
Профессионально я программирую уже 17 лет. В далёкие-предалёкие времена я начал изучать программирование с x86 Assembly. Такой жестокий подход к изучению компьютера дал мне глубокое понимание того как работает процессор и что делают другие языки программирования. Учить новые языки для меня никогда не было проблемой. Я их просто учил. C, C++, шарпы, ГО, тысячи разных скриптов и фреймворков. Чего уж там, ещё один язык, можно и выучить.
Ага.
Только вот не с этой ржавой развалюхой. Я просидел две недели над официальным руководством, пялился в VSCode и не мог выдавить из себя больше чем fn main() {}. Ну какого же чёрта? Я просто закрыл глаза, открыл руководство на рандомной странице и начал его читать. И прикол в том, что я понял о чём там говориться. И тут до меня дошло… Руководство написано наизнанку. Начало и конец ничуть не лучше чем в Мементо Кристофера Нолана. Они как-то умудрились запутать в общем-то нормальное руководство. После этого всё пошло получше.
Ржавые шестерёнки заскрипели и начали крутиться. Программа пошла-поехала. Если хотите знать как я внедрил rust в продакшин, как я ему научился и что из этого вышло – добро пожаловать под кат. Реальные люди, коммиты, примеры и никаких todo-list и хеллоу-ворлдов.
Всем привет! Меня зовут Сергей, я работаю в команде Тинькофф. Сегодня я хочу рассказать, как мы в Тинькофф приходили к классической пирамиде тестирования.
Рассказ будет в трех частях:
- Трудности, с которыми нам пришлось столкнуться, и как мы их преодолевали.
- Конкретные решения по некоторым распространенным кейсам при написании интеграционных тестов.
- Подход к написанию E2E-тестов (тестов, покрывающих взаимодействие всех систем приложения, включая back-end и пользовательский интерфейс) с использованием паттерна PageObject, пришедшего к нам из мира веб-разработки.
Всем привет! Меня зовут Кирилл Поляков, я QA-инженер в компании Lamoda. Мы тестируем бекэнд большой e-commerce платформы. В этой статье я расскажу, как мы пришли к автотестам на языке разметки для тестирования микросервисов и делаем это с помощью инструмента собственной разработки – Gonkey, который позволяет использовать стандартизированный набор решений и легко писать тесты на Go.
