T-shape во фронтенде. Опыт Sportmaster Lab


Делаем веб лучше


Что лучше для web-приложений - монолит или микросервисы? Многие ответят на этот вопрос, что, мол, все инструменты хороши, если их использовать по назначению. В таком случае у меня, как у человека, в силу своего возраста, довольно консервативного и неохотно воспринимающего непроверенные временем концепции, возникает другой вопрос - а чем хорош монолит? Где его ниша? Стоит ли переключаться на микросервисы или монолит ещё не изжил себя и на мой век хватит?
В фокусе моих интересов не гигантские web-приложения типа Gmail, Facebook, Twitter, а web-приложения, созданные на базе таких платформ, как Wordpress, Drupal, Joomla, Django, Magento и им подобным. Под катом мои субъективные мысли на этот счёт. Ничего нового - всё те же 33 буквы кириллицы и 26 букв латиницы вперемешку.

Здравствуйте, меня зовут Дмитрий Карловский и я… дизайнер. Дизайнер от слова design (проектирование), а не от слова style (дизайн). Я разрабатываю высокоуровневый фреймворк $mol. Одна из основных концепций которого — Лего. То есть это набор очень маленьких кирпичиков с простым и универсальным интерфейсом коммуникации. Комбинируя эти кирпичики в разных комбинациях можно строить приложения любой сложности.
Но, чтобы приложение не выглядело как лоскутное одеяло, а было лаконичным и опрятным, необходимо, чтобы выполнены эти кирпичики были в едином стиле, а располагать их можно было в любой комбинации, не теряя опрятности.
Поэтому, мы разработали математически выверенный концепт дизайна, суть которого можно уловить из следующей шпаргалки:

Далее я расскажу, почему всё именно так, и никак иначе...
Часто информация, которая отображается пользователю и имеет свойства разметки, хранится в базе данных и сразу в формате HTML. Я уверен, что те, кто хоть раз создавал свой блог, Хабр или что-то подобное, скажут: «Да, было». Но что, если я предложу другой подход? Использовать JSON.
Давайте вместе разберёмся в преимуществах и недостатках такого подхода к хранению данных.



<table>, <th>, <tr> и <td> не способствует созданию доступных страниц. Особенно — в случаях, когда с их помощью создают сложных структуры из глубоко вложенных друг в друга таблиц. Средства для чтения текстов с экрана, которые, помимо их прямого предназначения, обычно используют как инструмент для оценки доступности контента, испытывают сложности с формированием связного текста на основе материалов, оформленных в виде таблиц. Это не говорит о том, что таблицы — это плохо. Речь идёт лишь о том, что они не предназначены для создания макетов.







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

Добрый день, уважаемые читатели. Эта статья посвящена проблеме, с которой сталкиваются разработчики более-менее серьезных веб-сайтов, а именно – проблеме автоматического обновления скриптов в браузере пользователя после деплоя.
Суть проблемы заключается в том, что одностраничное приложение, загруженное в браузере пользователя, не знает о том, что скрипты были только что изменены, и, следовательно, необходимо обновиться. С точки зрения пользователя это выглядит как непонятные ошибки, возникающие на ровном месте, или как отказ приложения выполнять свои функции. Все это – следствие того, что версия скриптов на сервере изменилась, и приложение просто не может их найти и загрузить.
Конечно, все решается нажатием на F5, но в данной статье я покажу, как можно автоматизировать это действие, избавить пользователя от головной боли и сделать это красиво.



Подборка свежих уроков, видео и пакетов по фреймворку Laravel за неделю.
