Привет! Я — Ваня, лид платформенной команды в Тинькофф Бизнес.
Мое любимое занятие — открывать вкладку DevTools и проверять, сколько весят артефакты сайта. В этой статье расскажу, как мы сократили вес приложения на 30% силами платформенной фронтенд-команды за один день без изменения кода сайта. Никаких хитростей и регистраций — только nginx, docker и node.js (опционально).
На JavaScript легко писать. Достаточно взять пару библиотек или модный фреймворк, прочитать несложный туториал и все — через пару часов у вас простой работающий интерфейс.
Проблемы начинаются, когда интерфейс становится сложнее. Вот тут без глубокого понимания JavaScript не обойтись. Важно, чтобы даже большой и сложный интерфейс оставался быстрым и отзывчивым. Отзывчивость, как правило, достигается за счет использования асинхронных функций. Попробуем разобраться, как устроена асинхронность в JavaScript.
Как известно, в JavaScript нельзя создать несколько функций, различающихся только списком параметров: последняя созданная перезапишет предыдущие. Про различие на уровне типов параметров говорить не приходится вообще. Обычно, если программист хочет создать функцию с множественным интерфейсом, он пишет что-то вроде такого:
// getRectangleArea(x1, y1, x2, y2) или
// getRectangleArea(width, height)
function getRectangleArea(x1, y1, x2, y2) {
if(arguments.length==2) return x1*y1;
return (x2-x1)*(y2-y1);
}
* This source code was highlighted with Source Code Highlighter.
Пока пример выглядит не очень страшно, однако интерфейсов может со временем стать заметно больше, тогда функция станет плохочитаема. Посмотрим, что можно с этим сделать.
Прошли те дни, когда мне, в процессе разработки, приходилось тратить время, переключаясь между терминалом, браузером и редактором. Теперь всё делается иначе — быстрее и удобнее. Сегодня я расскажу об оптимизации повседневных дел React-разработчика. А именно, речь пойдёт о том, как связать Visual Studio Code и Google Chrome. Это даст возможность отлаживать браузерный код в редакторе.
Хакер — человек, который наступает на грабли, которые спрятаны в сарай и закрыты на замок
Mongoose — самый популярный модуль для работы с mongodb на javascript. Примеры на сайте позволяют достаточно быстро и успешно начать его использовать, однако mongoose имеет ряд неожиданных особенностей, которые могут заставить программиста начать выдирать волосы на голове. Именно об этих особенностях я и собираюсь рассказать.
Я, будучи разработчиком мобильных приложений, часто нуждаюсь в backend-сервисах для хранения пользовательских данных, авторизации и прочего. Конечно, для подобных задач можно использовать BaaS (Parse, Backendless, etc…). Но свое решение — это всегда более удобно и практично.
И я все же решил изучить совершенно неизвестные для меня технологии, которые сейчас весьма популярны и позиционируются, как легко осваиваемые новичками и не требующие глубоких знаний и опыта для реализации масштабных проектов. Вот и проверим вместе, может ли неспециалист написать свой эффективный и правильный бэкенд.
В данной статье будет рассмотрено построение REST API для мобильного приложения на Node.js с использованием фреймворка Express.js и модуля Mongoose.js для работы с MongoDB. Для контроля доступа прибегнем к технологии OAuth 2.0 с помощью модулей OAuth2orize и Passport.js.
Пишу с позиции абсолютного новичка. Рад любым отзывам и поправкам по коду и логике!
Как вы уже догадались из названия статьи, сегодня речь пойдет о самом популярном, разве что после Singleton, шаблоне проектирования MVC, хотя такое сравнение не совсем уместно. Понимание концепции MVC может помочь вам в рефакторинге и разрешении неприятных ситуаций в которые, возможно попал ваш проект. Дабы восполнить пробел, мы реализуем шаблон MVC на примере простого сайта-визитки.
О Mobile First написано достаточно много и есть хорошие книги на эту тему. И все равно большинство разработчиков и компаний не используют его в своих проектах или не знают вообще об этом подходе.
Поэтому хочу рассказать вам о нем вкратце и с примерами, это будет полезной информацией для тех кто не слышал об этом подходе.
Я постараюсь ответить на три основных вопроса:
Дорогие друзья! Сегодня выходит наш юбилейный сотый дайджест. Огромное спасибо вам за то, что выпуск за выпуском читаете нас. Только благодаря вам мы пересекли этот рубеж!
Под катом вас также ждет конкурс с призами от интернет-магазина ITStuff.
Недавно завершился одесский этап крупной международной конференции IT NonStop 2015. Спикеры были не ограничены жесткими рамками тем и направлений, каждый мог поделиться с аудиторией тем, что казалось важным и актуальным именно ему. В итоге мы получили массу отличных докладов на разные темы.
Уже довольно долгое время я задаюсь вопросом: «Может ли в наших суровых реалиях жить и развиваться Open Source проект?». Этот вопрос меня периодически тревожит, так как я сам являюсь автором одного такого проекта — WysiBB. Я задавал подобный вопрос на различных ресурсах, были вопросы и на Тостере. Но по сути все сводилось к тому, что в русскоязычном сегменте интернета не работают кнопки «Поддержать проект», «Пожертвовать» и т.д. и развиваться могут только проекты с огромной аудиторией и/или платными функциями.
В чем суть?
Но вот наконец в один прекрасный день, я наткнулся на интересную идею, как можно получать некоторые финансовые вливания в развитие и видеть, какие фичи наиболее востребованы пользователями. Эту идею я увидел на сайте Robomongo(кто не знает, это GUI для MongoDB). И ее суть заключается в следующем: пользователю предоставляется возможность выбрать из списка issues(с джитхаба) наиболее его тревожащую и пожертвовать средства на ее доработку. Когда пользователь делает пожертвование, рейтинг приоритетности этой фичи повышается. Так автор проекта получает средства на свой кошелек и видит какие фичи имеют наивысший приоритет(больше всего пожертвований) и соответственно являются наиболее востребованными. Автор приступает к их разработке в первую очередь, проект развивается, а пользователь получает долгожданную фичу. Мне эта идея понравилась и я решил реализовать подобный механизм на своем проекте, а когда начал работу над этим сервисом, понял что такой сервис может быть полезен не только для меня. Так появился на свет GitFund.
Шесть лет назад мне было 43 года, и я не умел программировать вообще. Ну, может немного на Бэйсике, который преподавали в институте, как вы понимаете, очень давно.
В книжном магазине попалась мне на глаза книга «Программирование для iPhone/iPad» и, будучи человеком любознательным, я решил попробовать. Купил книгу, MacBook Air (iPad у меня тогда уже был), установил XCode и начал с примеров из книги. Когда я получил общее представление о том, как что работает, мне захотелось сделать что-то полезное. Так как для программиста очень полезным, или скорее даже необходимым, является знание английского языка, я решил создать такое приложение.
Семь месяцев назад, сидя за столом на кухне в своей старенькой квартире, расположенной в оживленном районе Тегерана, я повторил то, что уже делал тысячи раз. Открыв ноутбук, я разместил очередную запись в своем блоге. Это была первая запись за последние шесть лет — мое сердце разрывалось.
С середины мая разработчики мобильных приложений под iOS были вынуждены отключать авторизацию через ВКонтакте по требованию Apple, либо использовать „костыль“ — pull request. Аргументация модераторов Apple была проста:
22.4 Apps that enable illegal file sharing will be rejected „Приложения, которые позволяют нелегальное распространение файлов будут отклонены“.
Последние месяцы мне по долгу службы приходилось изучать и контролировать большое количество дизайна. Критерии совершенно обычные — следить за текстом, внимательно вчитываясь в каждую фразу. И следить чтобы дизайн выполнял свои задачи.
Спустя время я выделил несколько неочевидных вещей, на которые старался обращать внимание, и в большинстве случаев находил ошибки. Получился небольшой чеклист. Очень полезный как для самопроверки, так и для проверки чужого дизайна. Им с вами и спешу поделиться:
