Объяснение того, как пользоваться моим очередным (возможно) бесполезным проектом-велопипедом.
В статье подробно объясняется большинство моментов и приннципов работы NTW3. я старался сделать создание сайтов больше похожим на создание обычным приложений, благодаря чему получился необычный подход. Надеюсь, будет интересно почитать!
В данном руководстве рассмотрим, как можно кастомизировать вывод настраиваемых полей для фильтрации материалов Joomla через переопределение шаблона.
Мне 21 год и я работаю программистом всего 4 года, за это время я побывал на 2–3 мелких проектах и 3–4 проектах крупных компаний, таких как: Luxoft (упокой его душу), Альфа, ОТП, ГПБ и др. Так же я часто прохожу собеседования и в другие компании, чтобы «держать себя в форме», собирать статистику и т. п. Прохожу собеседования, в том числе и в крупные финтехи и пока что не хочу туда идти.
В разговорах со своими коллегами я очень часто слышал фразу «алгоритмы программистам не нужны», «алгоритмы никогда не используются в работе» и т. п. Я не являюсь ярым приверженцем того, что алгоритмы нужно учить и использовать их повсеместно, но я понимаю, как они могут помочь мне в жизни программиста.
Привет, Хаброжители!
Привет, Хабр! Мы приготовили для вас долгожданный подарок (из заголовка вы уже поняли, какой), но мы вам его просто так, как говорится, не отдадим 😃
Версионирование API является важной частью жизненного цикла API. Некоторые стили API, например, GraphQL, полностью игнорируют версионирование и называют это функцией. Другие, например, RESTful API, предоставляют разработчикам множество различных способов реализации версионирования.
Я считаю, что версионирование для API важно, но также слишком сложно. Это важно, потому что обратная совместимость критически важна в мире взаимосвязанных компаний, использующих API в качестве моста. В то же время это сложная проблема для команд разработчиков.
Все больше и больше компаний начинают понимать свои API как продукты. Компании будущего не будут работать в изоляции. Вместо этого они будут использовать API от сторонних поставщиков, предоставляя при этом свои API другим.
Опираясь на API других компаний, эти компании получат преимущество, так как смогут больше сосредоточиться на своем собственном бизнесе. В то же время, предоставляя свои собственные API в качестве продукта другим компаниям, они получат преимущество перед теми компаниями, которые не позволяют другим легко интегрироваться с ними. Все это приведет к выигрышной ситуации для участников. Я ожидаю, что этот тренд может только привести к экспоненциальному росту. Чем больше проблем легко решаемы с помощью интеграции с API, тем проще становится для других создавать новые бизнес-модели на его основе, что, в свою очередь, добавит больше API в экосистему.
Привет! Сегодня хочу поделиться опытом разработки многостраничного сайта и на конкретном примере рассказать, как действую, чем руководствуюсь и на что обращаю внимание с самого начала. Погнали.
После завершения главы 1 у вас должно получиться простое, но функциональное веб-приложение. Во второй части серии мега-учебника по Flask я собираюсь обсудить, как работать с шаблонами.
О программисты! Костяк цифровой эры, незримые прядильщики нашей онлайн-вселенной. Боковая ветвь человекообразных приматов, связанных тесными родственными узами с Homo Sapiens. Отличаются плохой осанкой, лёгкой степенью мизантропии и способностью решить любую проблему, заглянув в Google. Это густонаселённое племя пестрит восхитительным разнообразием, которое чётко прослеживается в стилях программирования и личностных характеристиках.
При разработке больших web-проектов нам часто приходится взаимодействовать с API сторонних или внутренних микросервисов. Когда количество таких взаимодействий растёт, настройки вызовов к другому API и подробности самих вызовов кратно множатся и могут растекаться по проекту.
В Домклике у нас микросервисная архитектура, и каждому сервису приходится взаимодействовать с десятком других. Чтобы межсервисное взаимодействие было предсказуемым, надёжным, удобным и отслеживаемым, мы следуем ряду практик при разработке, и в этой статье я расскажу вам о них.
Hello world!
По данным 2023 JavaScript Rising Stars библиотека htmx заняла второе место в разделе Front-end Frameworks (первое место вполне ожидаемо принадлежит React) и десятое место в разделе Most Popular Projects Overall.
htmx — это библиотека, которая предоставляет доступ к AJAX, переходам CSS, WebSockets и Server Sent Events прямо из HTML через атрибуты, что позволяет создавать современные пользовательские интерфейсы (насколько сложные — другой вопрос), пользуясь простотой и мощью гипертекста. На сегодняшний день у библиотеки почти 30 000 звезд на Github. Удивительно, что до такого решения мы додумались только сейчас, учитывая, что весь функционал был доступен уже 10 лет назад (вы сами убедитесь в этом, когда мы изучим исходный код htmx).
В этой статье мы с вами разберемся, как htmx работает. Но давайте начнем с примера ее использования.
С точки зрения разработчика, объекты в JavaScript довольно гибкие и понятные. Мы можем добавлять, удалять и изменять свойства объекта по своему усмотрению. Однако мало кто задумывается о том, как объекты хранятся в памяти и обрабатываются JS-движками. Могут ли действия разработчика, прямо или косвенно, оказать влияние на производительность и потребление памяти? Попробуем разобраться во всем этом в этой статье.
Возможно, вы думаете, что о подписках говорить особо нечего. Они определены в спецификации GraphQL, и должно быть очень ясно, как они работают и для чего они нужны.
Но на самом деле спецификация мало что говорит о транспортном слое. Фактически, она вообще не указывает транспортный слой. С одной стороны, это преимущество, потому что вы можете использовать GraphQL в самых разных средах. С другой стороны, у нас сейчас есть по крайней мере пять разных реализаций подписок GraphQL.
Это означает, что вы не можете просто использовать любой клиент GraphQL, подключиться к серверу GraphQL и ожидать, что все будет работать. Вам нужно знать, какой протокол поддерживает сервер и какой клиент вам нужно использовать. Это идеальная ситуация? Вероятно, нет, но мы собираемся это изменить!
Мы - создатели WunderGraph (открытый исходный код), первого облачного серверного GraphQL API Gateway. Одной из проблем, с которой мы столкнулись, была поддержка всех различных протоколов подписки GraphQL. Поскольку спецификация GraphQL строго агностична к протоколу, за годы было разработано несколько различных протоколов.
Если клиент хочет использовать подписку GraphQL, ему нужно знать, какой протокол использовать, и реализовать клиентскую сторону этого протокола.
С нашим Open Source API Gateway, мы делаем шаг вперед и объединяем все под одной крышей. Если вы смотрите на использование подписок GraphQL в вашем проекте, этот пост - отличный способ быстро ознакомиться с различными протоколами и их особенностями.
Здравствуйте, меня зовут Дмитрий Карловский и я... ради лулзов создал самый мемный фреймворк в индустрии.
Если вы давно следите за моей работой, то знаете, что одним из моих любимых пристрастий являются сравнения GraphQL, REST, tRPC и других технологий, в которых не упоминаются Relay и Fragments. В этом посте я объясню, почему я считаю Relay переломным моментом, как мы сделали ее в 100 раз проще в использовании и внедрении, и почему вам стоит обратить на нее внимание.
В самом начале своей карьеры я имел честь в одно лицо разрабатывать проект, предназначенный для массового пользователя. Надо сказать, что почти все основополагающие принципы того, как провалить проект, были соблюдены, однако, он до сих пор жив. Проект был предназначен для принудительного использования определенной категорией работников бюджетной сферы. Технического задания, аналитики, дизайн-документов, макетов в Фигме, лавандового смузи, и прочих этих ваших модных слов, без которых N лет назад строили БАМ и Траннсиб не было от слова совсем. Зато, были процессы “в бумаге”, которые требовалось оцифровать. Поэтому то, что можно было принять за ТЗ, выглядело как “Эти (работники) заполняют вот это (бумаги) потом несут тем (проверяющим) а дальше все это хранится, сделай чтобы они с компьютера могли загрузить и отправить, у нас тут целый этаж бумагами занят, пожар начнется - всему хана”. Используя весь свой багаж знаний и опыта в построении высоконагруженных систем (на этом месте я отошел от написания статьи сначала проржаться а потом поплакать), я приступил к реализации.
«Сделай работающим, сделай правильным, сделай быстрым». Это мантра, которую вы, вероятно, слышали раньше. Это хорошая мантра, которая помогает вам сосредоточиться на том, чтобы не переусложнять решение. Я пришел к выводу, что обычно достаточно сделать это правильно, обычно это достаточно быстро, если сделать это правильно.
Когда мы начали реализацию подписок GraphQL в Cosmo Router, мы сосредоточились на том, чтобы сделать это работающим. Это было несколько месяцев назад. Это было достаточно хорошо для первой итерации и позволило нам получить отзывы от наших пользователей и лучше понять проблемное пространство.
В процессе того, как мы делали это правильно, мы сократили количество горутин на 99% и потребление памяти на 90% без жертвования производительностью. В этой статье я объясню, как мы достигли этого. Использование Epoll/Kqueue сыграло большую роль в этом, но также переосмысление архитектуры, чтобы она была более событийно‑ориентированной.
left-pad из нескольких строчек кода, которые реализуют примитивную функцию вставки пробелов в левой части строк. Он был установлен в качестве зависимости в React, Babel и других пакетах. Автор и мейнтейнер left-pad решил в знак протеста отозвать его, что вызвало массовый сбой в работе веб-сайтов. После этого компания npm Inc. запретила авторам отзывать свои пакеты без разрешения администрации.
Наша команда Mobile Doc&Loc «Лаборатории Касперского» занимается подготовкой документации и локализации B2C-продуктов компании для мобильных устройств. Основная сложность (и одновременно фишка) нашей работы заключается в том, что необходимо регулярно подготавливать переводы на 34 языка в крайне сжатые сроки.
Меня зовут Юлиана Соломатина, я — Doc&Loc-инженер, и в этой статье я расскажу про инструменты-автоматизации, которые помогают нам справляться с наплывом задач и укладываться в дедлайны, не жертвуя при этом качеством. Кстати, многие из этих инструментов мы разработали сами.
