На Хабре ввели новый WYSIWYG-редактор постов, а старый позже отключат. Идея в том, чтобы пользователям не требовалось иметь дела с HTML-тегами, и публиковать записи свободно мог любой не-айтишник. Но вот вопрос: не доставит ли это неудобств айтишникам?
Возможно, те кто постарше, еще помнят price.ru. Вот и я еще помню те времена, когда Яндекс Маркета не было вообще. И даже был период, когда я пытался делать аналог price.ru для американского заказчика, и при этом amazon.com был у нас всего-лишь одним из многих сайтов - источников сведений о товарах (книгах, CD-ROM и т.п.), при том не самым крупным, и еще был живой yahoo... В общем, с тех пор многое изменилось.
Потом появился Яндекс Маркет, сильно вырос Амазон, и скажу прямо - много лет я использовал их как основной инструмент для поиска нужных мне товаров. А теперь вот подумываю, не уйти ли куда-то, на e-katalog скажем (шутка, там свои проблемы)? Или найти другое решение, получше?
Идея что фронтенд это "для джунов", расстраивает меня тем, что никто не скажет так про другие специализации.
Кто-то может сказать, что неплохо, если б автор компилятора был более "фуллстековым".
Но они не скажут, что "писать компиляторы это для джунов".
Это перевод треда Yehuda Katz из твиттера. Под фронтедом здесь подразумеваются именно браузерные приложения на JS (и, отчасти, вся JS-экосистема).
По сути, когда люди говорят «фронт для джунов», они делают несколько больших ошибок. Вот две из них:
С увеличением количества обслуживаемых продуктов наша дизайн-система начала разваливаться. Вырос порог входа для дизайнеров и работать с ней стало труднее. В статье расскажу как мы перешли на модульную архитектуру и не растеряли консистентность.
Вот немного вводных, которые позволят понять, похож наш случай на ваш или не очень.
Есть несколько продуктов.
Один продукт могут делать несколько команд дизайнеров и разработчиков.
Есть Web, Mobile и Desktop.
Есть много легаси и неконсистентности.
Дизайнер в одном продукте может не знать что происходит в другом.
Всем привет! Меня зовут Елизавета Добрянская, я frontend-разработчик в компании ДомКлик. Моя команда занимается разработкой сервисов, предназначенных для коммуникаций с клиентом.
В этой статье я поделюсь своим кратким обзором внедрения стейт-менеджера Effector в продуктовый проект на стеке React + TypeScript, а также покажу на примере, как легко это можно сделать.
Содержание:
Немного предыстории
Первая встреча с Effector
Боль как начало
FT4232H – это интегральная микросхема преобразователя USB – UART, поддерживающая режим High Speed на стороне USB и имеющая четыре порта на стороне UART.
Подключив к этой микросхеме EEPROM-память можно задать специфические режимы работы или изменить данные производителя.
Разберемся на примере и сконфигурируем FT4232H непосредственно в системе под управлением GNU/Linux. Делать это будем с помощью утилиты ftdi_eeprom.
Привет.
В первой части была рассмотрена возможность использования Raspberry Pi 4 в качестве десктопа с установленной «родной» операционной системой Raspbian. Но как известно, с недавних пор Ubuntu v20 64-bit «официально» доступна для Raspberry Pi — посмотрим, как это работает.
Что из этого получилось, подробности под катом.
Читать полностью »
В этой статье хочу рассказать и поделиться своим мнением насчет пользовательских интерфейсов scada-систем и систем диспетчеризации в целом.
Основная направленность нашей работы — разработка комплексных систем диспетчеризации инженерных и технических коммуникаций. Проще говоря, построение системы «умного» дома, но в масштабах складов, логистических центров или, например, торгового центра.
Первая версия сервиса Яндекс.Драйв была запущена за два месяца после начала разработки, а затем практики пришлось постепенно менять. Руководитель мобильной разработки Драйва Кирилл Кожухар обсудил все шаги при создании и проработке дизайна, поделился своим видением того, как приложение должно эволюционировать, и проанализировал, как менялся UI.
— Всем привет, меня зовут Кирилл, я занимаюсь iOS-версией Яндекс.Драйва. Мы решили подготовить не совсем технический доклад, обсудить то, как развивается проект на самых ранних этапах, когда только все начинается, закладывается. Это так называемый этап MVP.
Доклад будет состоять из двух частей. В первой части поговорим о том, каких процессов мы придерживались на старте, какие у этих процессов были плюсы и минусы. Вторая часть — о том, как эти процессы повлияли на UI, который мы разработали в самой первой версии, какие у этого UI нашлись минусы и как мы их устраняли.
Читать полностью »
