Продолжаем рассказывать о полезных инструментах для пентестера. В новой статье мы рассмотрим инструменты для анализа защищенности веб-приложений.

Наш коллега BeLove уже делал подобную подборку около семи лет назад. Интересно взглянуть, какие инструменты сохранили и укрепили свои позиции, а какие отошли на задний план и сейчас используются редко.

Асинхронное программирование за последнее время стало не менее развитым направлением, чем классическое параллельное программирование, а в мире JavaScript, как в браузерах, так и в Node.js, понимание его приемов заняло одно из центральных мест в формировании мировоззрения разработчиков. Предлагаю вашему вниманию целостный и наиболее полный курс с объяснением всех широко распространенных методов асинхронного программирования, адаптеров между ними и вспомогательных проемов. Сейчас он состоит из 23 лекций, 3 докладов и 28 репозиториев с множеством примеров кода на github. Всего около 17 часов видео: ссылка на плейлист.

С недавних пор меня просто заваливают приглашениями на собесы. Я прихожу, мы болтаем за жизнь, а потом мне делают оффер, как будто техническое интервью уже позади, и я подтвердил свои скиллы заочно. Но у меня нет супер-страницы на гитхабе, мое резюме такое серое, как будто меня заставляли его составлять. Единственное доказательство, что я чего-то стою — это моя способность отвечать на технические вопросы. Но теперь мне их почти не задают.

Дело в том, что я написал сюда несколько статей, и они стали популярными. Вроде звучит нормально и заслуженно. Раз я говорю о своем опыте и знаниях в публикациях, а люди их одобряют, то зачем эти формальности на собесах — мой скилл «комьюнити-апрувд».

Вот только почти все статьи не про разработку — в них нытье про мою депрессию. Я-то рад, что мне больше не надо никому ничего доказывать. Но вы что, с ума сошли котировать разрабов за такую чушь? Я думаю, сошли, и вижу тревожные симптомы этого везде.

Дайджест собирает свежие статьи по дизайну интерфейсов, а также инструменты, паттерны, кейсы, тренды и исторические рассказы с 2009 года. Я тщательно фильтрую большой поток подписок, чтобы вы могли прокачать свои профессиональные навыки и лучше решить рабочие задачи. Предыдущие выпуски: апрель 2010-март 2019.

Проблема с отображением картинок возникла с момента появления адаптивности в интернете. Мы хотим, чтобы сайт хорошо смотрелся на любом планшете, телефоне, в портретной или ландшафтной ориентации экрана, а также на супербольших дисплеях 5K. Также на рынке появились Retina-дисплеи с высокой плотностью пикселей (DPI), где обычные картинки выглядят размытыми. Растет доля мобильного трафика, и крупные ресурсы нацелены на экономную загрузку изображений. Рассмотрим, как решают эти проблемы на сайтах Apple, Tilda и блог-платформе Medium.

Я большой фанат тестирования. Я пишу об этом в блог и почтовую рассылку, я обсуждаю это c другими разработчиками в свободное время, я зашел так далеко, что даже создал обучающий курс по тестированию в Go.

Но несмотря на всю мою любовь к тестированию, я не рекомендую его новичкам.

Звучит дико, правда? В этой статье я собираюсь пояснить свою точку зрения более детально, но весь смысл, в итоге, сводится к двум пунктам:

1. Начинающим не хватает знаний, чтобы писать что-либо кроме самых простых тестов. Это неизбежно приводит к следующему пункту…
2. Пытаться тренировать навыки, необходимые для написания реалистичных тестов, одновременно с обучением программированию крайне тяжело

Я понимаю, что это, в принципе, один пункт. В любом случае, я разбил его на два для того, чтобы было проще понять.

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

Автор материала, перевод которого мы публикуем, говорит, что в мире разработки программного обеспечения «архитектурным проектированием» можно назвать процесс конструирования приложения, в ходе которого его стремятся сделать качественным, надёжным и хорошо поддающимся поддержке. При этом паттерны (шаблоны) проектирования позволяют оперировать понятиями, представляющими собой подходы к решению распространённых проблем. Эти решения могут варьироваться от абстрактных, концептуальных, до предельно конкретных. Их знание позволяет разработчикам эффективно друг с другом общаться.

Если хотя бы два разработчика в команде разбираются в паттернах, разговор о решении проблем, встающих перед командой, становится весьма продуктивным. Если о паттернах знает лишь один член команды, то обычно просто бывает разъяснить то, что он знает, другим членам команды.



Цель этой статьи заключается в том, чтобы заинтересовать читателей чем-то вроде формального представления знаний в сфере разработки программного обеспечения, продемонстрировав им идею паттернов проектирования и описав несколько паттернов, которые интересны тем, что они нашли применение в современной JavaScript-Разработке.

В данной статье я хочу осветить тонкости работы с SVG-графикой, SVG анимацию (в том числе и path), проблемы и способы их решения, а также разнообразные подводные камни, коих в SVG огромное множество. Эту статью я позиционирую как подробное руководство.



Здесь не будет никаких плагинов, библиотек и прочего, речь пойдет только о чистом SVG.
Единственный инструмент, который я буду использовать, это Adobe Illustrator.

Мир каскадных таблиц стилей непрерывно совершенствуется. Все больше и больше веб-разработчиков осознают, что, хотя они, как им кажется, знают CSS, до полного понимания им далеко. В последние годы язык сильно развился, поэтому даже те разработчики, которые когда-то были искусны в CSS, сегодня могут получить абсолютно новые навыки, чтобы наверстать упущенное. Данная книга призвана удовлетворить эти потребности: обеспечить глубокое владение языком и привести к успеху в новых разработках и применении новейших возможностей CSS.

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

Некоторые темы: анимация, типографика, гибкие контейнеры и даже CSS-стек — достойны отдельных книг. Цели автора — конкретизировать ваши знания, помочь ликвидировать пробелы в них и привить вам любовь к языку CSS.

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

Рассказывает Юрий Никулин, руководитель службы разработки технической документации.

Для начала давайте определим, что такое производительность. В классическом понимании, это время на производство единицы продукции или количество продукции, произведенное в единицу времени.

Например, это количество произведенных телефонов за месяц или количество времени на производство тысячи телефонов. Возникает вопрос, как измерять интеллектуальный труд, которым занимается наш отдел.

Итак, вы решили стать программистом.

Возможно, вам интересно создавать что-то новое.

Возможно, вас манят большие зарплаты.

Быть может, вы просто хотите сменить сферу деятельности.

Не суть.

Важно — вы решили стать программистом.

Что же теперь делать?

Разработчики сходят с ума от самых странных вещей. Мы все предпочитаем считать себя супер-рациональными существами, но когда дело доходит до выбора той или иной технологии, мы впадаем в некое подобие безумия, перескакивая от комментария на HackerNews к посту в каком-нибудь блоге, и вот уже будто в забытье, мы беспомощно плывем по направлению к самому яркому источнику света и покорно преклоняемся перед ним, абсолютно позабыв о том, что именно мы изначально искали.

На часах 7:15 утра. Наша техподдержка завалена работой. О нас только что рассказали в передаче «Good Morning America» и множество тех, кто впервые посещает наш сайт, столкнулось с ошибками.

У нас настоящий аврал. Мы, прямо сейчас, до того, как потеряем возможность превратить посетителей ресурса в новых пользователей, собираемся выкатить пакет исправлений. Один из разработчиков кое-что подготовил. Он думает, что это поможет справиться с проблемой. Мы размещаем ссылку на обновлённую версию программы, пока ещё не ушедшей в продакшн, в чат компании, и просим всех её протестировать. Работает!

Наши героические инженеры запускают скрипты для развёртывания систем и через считанные минуты обновление уходит в бой. Внезапно число звонков в техподдержку удваивается. Наше срочное исправление что-то поломало, разработчики хватаются за git blame, а инженеры в это время откатывают систему к предыдущему состоянию.



Автор материала, перевод которого мы сегодня публикуем, полагает, что всего этого можно было бы избежать благодаря TDD.

Сегодня я расскажу, как подготовить стартап к выходу на Product Hunt, какие шаги стоит предпринять до этого, и как подогревать интерес к проекту в день и после публикации.

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

Продолжаем говорить о людях, которые повлияли на становление open source.

/ фото Sebastiaan ter Burg CC BY-SA

Ричард Столлман

Ричард Мэтью Столлман родился в 1953 году в семье учителя и продавца печатных станков. С раннего возраста он увлекался вычислительными машинами. Столлман читал книги по программированию и техническую документацию ЭВМ.

Это вторая часть из цикла четырех статей о разработке физических продуктов. Если вы пропустили Часть 1: Формирование идеи, обязательно её прочтите. Вскоре вы сможете перейти к Части 3: Конструирование и Части 4: Валидация. Автор: Ben Einstein. Оригинал Перевод выполнен командами фаблаба FABINKA и проекта РУКИ.

Часть 2: Дизайн

Каждый шаг на стадии дизайна – изучение клиента, каркасное моделирование (wireframing, подробнее по-русски), визуальный прототип – нужен для проверки гипотез, как будет выглядеть продукт и как пользователи будут взаимодействовать с ним.


Рисунок 2.1 Этапы дизайна продуктов

Привет, Хаброжители! У нас вышла книга по языку запросов GraphQL. Мы решили поделиться переводом главы «Анатомия запросов GraphQL»

«Снежный клык» (Snowtooth) — выдуманный горнолыжный курорт. Ради примеров в данной главе мы сделаем вид, что это настоящая гора и мы там работаем. Мы рассмотрим, как веб-команда «Снежного клыка» использует GraphQL для предоставления информации в режиме реального времени: сведений о состоянии подъемников и лыжных трасс. Лыжный патруль «Снежного клыка» может открывать и закрывать подъемники и трассы непосредственно со смартфона. Чтобы следовать примерам в этой главе, обратитесь к интерфейсу «Снежного клыка» на платформе GraphQL Playground (snowtooth.moonhighway.com/).

Введение

Вот не люблю я изобретать велосипед и статью я бы эту не написал, но пришлось. Про REST сказано уже довольно много. Многие поставщики веб служб готовы клясться, что их службы являются RESTful. Во время собеседования вы точно услышите хотя бы несколько вопросов про REST, независимо от того это собеседования для бэкенд, мобайл или фронтенд разработчика. Я вот помню как-то во время одного собеседования меня задали такой вопрос: «Вот вы написали в своем резюме, что знайте REST․ Ответьте пожалуйста, какой HTTP код вы получите, если при запросе к RESTful сервису ресурс не найден?». Ответ 404 был принят единогласно. Если честно, я так и не понял, как этот вопрос помог понять знаю ли я REST или нет, но одно могу уверенно сказать: REST понимают далеко не все. Вот некоторые вопросы, которые мучали меня долгое время:

1. Зачем REST стал таким трендовым? Это архитектура была же предложена еще в 2000 году?
2. Что я получу если моя служба будет RESTful?
3. Как определить является ли служба RESTful или нет?
4. Как правильно должны создаваться URL REST служб?
5. Какие http методы и коды должны быть использованы в RESTful службе?

Если вы не можете дать исчерпывающего ответа хотя бы на один из этих вопросов, то продолжайте чтение. Если вы можете однозначно ответить на все эти вопросы, можете привести формат правильного URL, считайте, что GET, POST, PUT, DELETE обязательно должны соответствовать CRUD операциям с ресурсами, то вам обязательно надо продолжать чтение.

Привет всем. Хочу поделиться с вами некоторыми из расширений для Хрома, которые я использую при разработке, анализе сайтов, в работе с GitHub и просто в повседневной жизни. Уверен, что для большинства читателей, список этих расширений не будет открытием, но те, кто узнает о них впервые и установит, несомненно будут наслаждаться работой с новыми инструментами.