Пользователь
Как мы боролись с документированием API на наших проектах, и как мы немного сошли с ума
У вас на проекте порядок с документацией на API? Скорее всего нет. И в нашей компании порядка не было.
Не будем рассказывать, к каким печальным последствиям приводит ошибочная, устаревшая или вовсе отсутствующая API-документация. Почему же на большинстве проектов не удаётся решить такой, казалось бы, несложный вопрос?
Кто интересуется темой рисующих нейросетей знают, что сейчас самый продвинутый и часто используемый интерфейс для Stable Diffusion (далее SD) это Automatic1111. Он позволяет использовать, вероятно, все существующие возможности SD на сегодня. Множество расширений, регулярные обновления и поддержка сообщества делают его мощным и удобным инструментом для генерации изображений. Но есть и альтернативные решения, одно из которых я сегодня рассмотрю.
Статья подойдет как тем кто уже пользуется Automatic1111, так и тем кто только планирует более глубоко погрузиться в мир "процедурного рисования".
С наступающим наступившим вновь наступающим, Хабр.
Новый год – точка, после которой все мы собираемся что-то начать, чем-то заняться, в чём-то поднатореть. Сегодня я расскажу об одном из таких вариантов – что можно начать и как к этому подойти.
Конечно, про литкод все слышали и, казалось бы, о чём тут рассказывать? Ну задачник, перед техсобесами можно открыть на день-два. Но для того рассказать и стоит, дабы чуть разбавить это мнение.
С сайтом несколько больно знакомиться, он отпугивает вездесущими приписками "premium", пользуясь славой ресурса для техсобесов продвигает функционал вроде списков компаний, где встречался вопрос n и симуляции интервью в компанию m, да и сам не особо стремится рассказать о себе, потому в нём зачастую и видно голый задачник с одной страницей "problems".
За всем этим теряется важный пункт – а можно ли использовать сайт не для механического зазубривания популярных вопрос-ответов, а для изучения/закрепления алгоритмов и структур данных? Можно. Но подход к этому нужно формировать самостоятельно.
Доброго времени суток! Я самоучка, никогда не получал образования в сфере IT, не работал программистом и не проходил каких-либо специализированных курсов в этой сфере. Акцентирую внимание на этом в самом начале для того, чтобы было понимание, что данная статья не претендует на статус профессионального руководства “как надо работать с Elasticsearch (далее по тексту просто ES)”, это не панацея, если можно так выразиться. Все описанное, лишь основано на моем личном опыте и понимании схемы и структуры документов, ориентированной на использовании для построения фасетного поиска в интернет-магазине к которому я пришел при изучении и разработке. Т.е статья рассчитана больше на новичков без личного опыта и представления работы с NoSQL базами данных, коей и является ES.
Все, кто сталкивался с версткой писем, знают, что там по-прежнему используется табличная верстка, инлайновые стили, css хаки, устаревшие теги и т.д. И все это ради поддержки всех (или, вернее сказать, большинства) почтовых клиентов: различных версий Outlook, веб-интерфейсов почтовиков и мобильных почтовых клиентов.
Но индустрия не стоит на месте - все активнее для верстки писем применяются емейл-фреймворки. О них и пойдет речь дальше. Сравним 2 из них: MJML и Ampier framework (хотел добавить еще и Zurb Foundation for email, но они в последних публикациях уже не говорят о поддержке outlook, да и в принципе устарели).
MJML - самый известный и популярный емейл-фреймворк, признанный сообществом. На его основе работают всевозможные визуальные емейл-билдеры, и по факту он является стандартом в зарубежном емейл-маркетинге, хотя в России не все о нем знают.
Ampier - это мой емейл-фреймворк, который создавался на основе личного многолетнего опыта работы в сфере емейл-маркетинга. В нем я постарался учесть все те проблемы и сложности, с которыми сталкивается верстальщик писем. Идея была в том, чтобы не просто обеспечить “приемлемое отображение” в большинстве клиентов”, а дать свободу верстальщику, при этом не обременяя его вопросами совместимости с устаревшими почтовыми клиентами. Ну и, плюс ко всему, дать возможность заложить в единый код как html, так и AMP-версию письма. Но в этой статье речь пойдет пока что только о html.
Чтобы сравнить эти емейл-фреймворки, сверстаем следующее письмо, а потом посмотрим на получившийся код и качество отображения в различных почтовых клиентах.
Akamai Technologies - американская компания, занимающаяся защитой веб-ресурсов от ботов с помощью своего продукта Bot Manager. В её портфолио числятся такие гиганты ритейла, как Nike, Adidas и Asos, для которых особенно важен контроль за ботами, автоматизирующими процесс выкупа редких/лимитированных товаров с целью их перепродажи по завышенной цене. В данной статье мы взглянем на скрипт антибота Akamai и рассмотрим, какие методы обнаружения через JavaScript в нём используются. Не знаете почему обнаруживается ваш selenium? Добро пожаловать!
Чтобы найти работу в международной команде, а потом успешно работать, мало говорить на английском, нужно уметь переписываться. Писать на английском бывает страшно: тут и страх сделать ошибку, и нехватка опыта. Разберем по пунктам, почему так бывает и чем конкретно можно себе помочь, если в ближайшем будущем этот навык будет очень нужен.
Может ли kubernetes сделать жизнь админов небольших и средних компаний проще или же это шайтан-машина для кровавого enterprise и оголтелых стартапов?
Вы когда-нибудь задумывались над тем, как вы создаете виртуальные машины?
Как правило, это долгий и скучный процесс, богатый ручной работой.
Автоматизация сбора информации с различных ресурсов - обычная задача для людей разных сфер деятельности. Жаль, что не всегда бывает достаточно сделать простой GET запрос и разобрать полученный html. Веб-сайты, с которых собираются данные, принимают защитные меры для предотвращения автоматизированных запросов. Одной из таких мер является использование cloudflare. Сегодня мы посмотрим, как cloudflare выявляет ботов через javascript и коснёмся темы деобфускации скриптов.
Ранее (11 февраля 2019) пост уже публиковался мной с таким заголовком, но был отправлен в небытие по причине смерти домена, а как следствие и сервиса с ним связанного. Причин тогда было две — статистика скачивания докер-образа оставляла желать лучшего, и цена за продление домена (что был зарегистрирован в nic) стала для меня неожиданно выше той, которую я был морально готов заплатить за него.
Но есть время не продлять домены разбрасывать камни, а есть время извиниться за сделанную ошибку. Все, кому сервис был полезен, кто им пользовался и однажды заметил что он (localhost.tools) не резолвится — приношу свои извинения, и исправляю ситуацию (лучше поздно чем никогда, верно?).
Ниже я вкратце расскажу о чем вообще идёт речь, что изменилось, и как этим всем пользоваться. Для нетерпеливых, традиционно — репозиторий и ссылочка на сайт.
Общаться в профессиональной среде, ходить на конференции и митапы, просто посидеть вечерком в приятном баре с профессионалом высокого уровня и обсудить какие-то классные идеи: всё это может помочь в работе. Среди нужных ресурсов одно из первых мест занимают книги.
Под катом я расскажу вам о литературе, которая оказала на меня влияние как на управленца и разработчика. И, как мне кажется, может быть полезна любому, кто хочет вырасти в этих областях.
Я люблю давать простые задачки студентам на лекции. Во-первых, понятно, скольких мы потеряли, во-вторых, это переключение из режима потребления информации в режим выдачи результатов, в третьих — возможность проявить себя для шустрых. Сплошные плюсы!
Одна из простых задач звучит так: «При переводе картинки из цветового пространства RGB в YUV мы выполняем прореживание, то есть выкидываем каждый четный столбец и каждую четную строку в компонентах U и V (все компоненты пикселя по 1 байту). Вопрос: во сколько раз меньше данных у нас стало?» Эта операция называется chroma subsampling и широко используется при сжатии видео, например.
Забавно, что когда-то давно, когда винчестеры были меньше, а дискеты больше, студенты реально отвечали на этот вопрос быстро. А в последние годы регулярно народ в ступор впадает. Приходится разбирать по частям: «Если выкинуть каждую четную строку и каждый четный столбец, во сколько раз меньше данных будет у компоненты?» Почти хором: «В четыре». Начинаю подкалывать: «Отлично! У нас было 3 яблока, первое осталось как есть, а от второго и третьего осталось по четвертинке. Во сколько раз меньше яблок у нас стало?» Народ ржет, но, наконец-то, дает правильный ответ (заметим, не все).
Это было бы смешно, если бы от способности быстро в уме прикинуть результат не зависела способность быстрее создавать сложные алгоритмы.
И хорошо видно, как эта способность в широких массах студентов заметно плавно падает. Причем не только в нашей стране. Придуман даже специальный термин: «цифровое слабоумие» ("digital dementia") — снижение когнитивных способностей, достаточно серьезное, чтобы повлиять на повседневную деятельность человека.
Кому интересно как теряют мозг студенты масштабы бедствия и что с этим делать — добро пожаловать под кат!
В каждом продукте есть сценарии, которые могут привести к разрушительным последствиям. Например, какая-то команда может уничтожить важные данные или внести серьезные изменения в систему. Поэтому важно четко и понятно предупреждать об этом и помогать пользователю принимать осознанные решения.
В этой статье собрала основные принципы создания текстов для экранов подтверждения, которым следуют Apple, Microsoft и Google.
Привет! Хочу поделиться историей миграции сервисов логирования и трейсинга с компонентов Elastic Stack на Grafana Stack и тем, что из этого вышло. До миграции у нас в М2 использовались достаточно классические схемы:
В этой статье я хочу рассказать о том, как расширяются возможности ASP.NET Core по обработке запросов к веб-серверу с помощью самостоятельно написанных компонентов конвейера обработки.
Обычно для разработки серверной части веб-приложений (по-простому — бэка) с помощью ASP.NET Core имеет смысл использовать базирующиеся на нем фреймворки высокого уровня: MVC Core, Razor Pages и т.д.: они позволяют с минимумом усилий решать типовые задачи. Но встречаются задачи нетиповые, которые требуют для своего решения перейти на более низкий уровень (или, по крайней мере, понимать, что на этом уровне происходит) — на уровень базовых возможностей ASP.NET Core. И в этой статье как раз рассказывается об использовании одной из этих базовых возможностей — компонентов middleware, из которых создается конвейер обработки запросов к веб-серверу. Далее в статье я буду называть их компонентами-обработчиками, потому что официальный перевод из документации от MS — "ПО промежуточного слоя" — он некрасив и не описывает их функции. Конкретно в статье рассматривается, какие средства предоставляет фреймворк ASP.NET Core для создания самописных компонентов-обработчиков. И особое внимание уделено тому, как эти компоненты могут получить доступ к другой базовой возможности ASP.NET Core — сервисам, которые зарегистрированы в контейнере сервисов (он же — "DI-контейнер"), как к стандартным для ASP.NET Core, так и к самописным.
