Всем привет! Меня зовут Владислав Шиханов, я ведущий программист в CDEK. В этой статье я хочу рассказать о том, как мы пришли к проектированию и review плана разработки до начала реализации задачи, что это дало и как повлияло на скорость и качество разработки. Также поделюсь практическим руководством: как проектировать и проверять технический дизайн, чтобы это было быстро и удобно. Статья будет полезна разработчикам любой квалификации, но особенно тимлидам и менеджерам для внедрения практики в командах.

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

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

В продолжение темы о метаниях компаний между удаленным, офисным и гибридным форматами хочется поговорить о бизнес-процессах. Любой из форматов работы будет хорош, если нормально эти самые процессы выстроить. А сотрудники не станут возмущаться, если не менять правила игры прямо “в полете”. 

Мы в свое время настроили удаленный формат и работаем так уже почти семь лет. Продолжаем допиливать детали, но в общих чертах можем отчитаться о том, что “контроль без контроля” действительно работает. В этой статье рассказываем, как он устроен.

Проблемы при входе в IT и вопросы к компаниям по трудоустройству джунов очень острые, но почему-то об этом все молчат.

Начнем цикл статей нашей компании легко и непринужденно, с темы из мира front-end. Надеюсь, что статья будет полезна тем, кто хоть как то связан с миром front-end. Предупреждаю, что backend разработчикам может быть скучновато из-за того, что у них давно все стандартизировано)

Когда я провожу собеседование на позицию React разработчика, обычно задаю общий вопрос об архитектуре - "как бы ты строил архитектуру своего приложения и почему?". После обсуждения, я начинаю рассказывать небольшую часть материала из этой статьи, 5% по содержанию, приводя тезисы, по которым можно будет собрать общую картину моего видения. И обычно получаю положительную обратку. Поэтому решил изложить этот материал более развернуто здесь. Буду отправлять ссылку тем, кому это может пригодиться.

Браузеры стали частью нашей повседневной жизни. Но задумывались ли вы когда-нибудь о том, как они на самом деле работают?

Эта статья приоткроет завесу магии, скрывающуюся за кулисами веб-браузеров.

Давайте начнем!

Введение

function factorial(n){
    var result = 1;
    while(n){
        result *= n--;
    }
    return result;
}

function factorial(n, result){
    result = result || 1;
    if(!n){
        return result;
    }else{
        return factorial(n-1, result*n);
    }
}

Два года назад я задался вопросом "Как мне все успевать?". Вопрос пришел в веселой компании усталости, прокрастинации и выгорания...

Иллюстрация из работы Г.М. Адельсон-Вельского и Е.М. Ландиса 1962 года

Деревья поиска — это структуры данных для упорядоченного хранения и простого поиска элементов. Широко применяются двоичные деревья поиска, в которых у каждого узла есть только два потомка. В этой статье рассмотрим два метода организации двоичных деревьев поиска: алгоритм Адельсон-Вельского и Ландиса (АВЛ-деревья) и ослабленные АВЛ-деревья (WAVL-деревья).

Привет, друзья!

Представляю вашему вниманию адаптированный и дополненный перевод этой замечательной статьи.

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

Последние пять лет я работаю в аутсорсинге, поэтому часто занимаюсь запуском новых продуктов. Чаще всего первый шаг - создание так называемого MVP (minimum viable product).

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

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

Сегодня я расскажу, как мы вышли из этого треугольника (мое выступление на эту тему).

Привет! Меня зовут Мария Аменд, я разработчик в Naumen. Когда я только пришла в компанию, не знала, что такое файловые хранилища и как с ними работать. Однако первые мои задачи были связаны именно с этим, поэтому пришлось разобраться, что это такое, и как файлы хранятся в системе. 

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

Представьте, что в кафе на застолье пришел веган. Его друзья, зная это, специально выбрали кафе с отдельным меню для веганов. Но в нем только макароны с кабачками и вишневый компот, а в обычном меню есть и картошка, и салаты и другая еда, в которой достаточно заменить пару ингредиентов, чтобы веган мог это есть. Естественно, гость в недоумении? Почему макароны с кабачками? Для чего вообще отдельное веганское меню?

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