HTTP — вещь прекрасная: протокол, который просуществовал более 20 лет без особых изменений.



Это вторая часть серии по веб-безопасности: первая часть была «Как работают браузеры».

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

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

При обсуждении HTTP, тем не менее, мы всегда должны различать семантику и техническую реализацию, поскольку это два совершенно разных аспекта работы HTTP.

Исследуем эпичные провалы редизайна и мотаем на ус. Менеджер по продукту заходит в отдел дизайна и заказывает редизайн сайта. «Наш сайт выглядит таким старым! У всех наших конкурентов есть более яркие сайты. Давайте перепроектируем его. Кнопки с разноцветными тенями — это будущее!»

Дизайнер: «Хорошо, давайте начнем с тестирования юзабилити».
ПМ: «У вас есть 3 недели, и я хочу, чтобы все цвета были заменены на ярко-розовый, ярко-синий или оранжевый».

Вот как вы убиваете свой коэффициент конверсии. Хотя приведенный выше сценарий может быть диким преувеличением, увидев количество компаний, радикально перерабатывающих свой бренд каждый год, то окажется что это не так. Просто посмотрите на Facebook, который выглядит как новый почти каждый раз, когда я открываю его. На Facebook есть целая группа, состоящая из 3 тысяч участников, которые отслеживают любую деталь, которую изменила компания.

1993 год выдался более щедрым на чудеса, чем все предыдущие. Это был единственный раз, когда мы поставили перед собой задачу создать игру, которая была бы настолько хорошей, насколько это было возможно в то время. Мы не ставили перед собой такие задачи ни до DOOMa, ни после. Это было идеальное время, чтобы совершить невозможное.

Мы наивно составили неправдоподобный список технологических чудес, которые мы планировали создать, и смело заявили в пресс-релизе в январе 1993 года, что DOOM станет основным источником падения рабочих показателей во всем мире. Мы действительно верили в это и усердно работали в том году, чтобы это стало реальностью. Я не рекомендую писать пресс-релиз на старте вашего проекта, особенно такого.

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


Chrome и lynx

Браузер — это движок рендеринга. Его работа заключается в том, чтобы загрузить веб-страницу и представить её в понятном для человека виде.

Хоть это и почти преступное упрощение, но пока это все, что нам нужно знать на данный момент.

• Пользователь вводит адрес в строке ввода браузера.
• Браузер загружает «документ» по этому URL и отображает его.

«Мастер совершает больше ошибок, чем новичок — попыток»

Прошлый список тренировочных проектов набрал 50к прочтений и 600 добавлений в избранное. Вот еще один список интересных проектов для практики, для тех кто хочет добавки.

1. Текстовый редактор

Цель текстового редактора — уменьшить усилия пользователей, пытающихся преобразовать их форматирование как валидную разметку HTML. Хороший текстовый редактор позволяет пользователям форматировать текст по-разному.

В какой-то момент каждый использовал текстовый редактор. Так почему бы не создать его самостоятельно?

В прошлой статье мы ознакомились с реликтовыми сортировками слияния (вызывающих прежде всего исторический интерес). А что в тренде сегодня?

«Я бы прочитал книгу теолога о программировании.»
— Дональд Кнут

На Youtube есть серия из коротких 97 роликов, где Дональд Кнут рассказывает про свою жизнь. Пару лет назад я начал публиковать самые интересные моменты, а вот сейчас решил продолжить знакомить читателей с образом мыслей и способом принятия решений «самого великого программиста всех времен и народов».



«3:16» — это книга, которая отличается от любой другой книги, которая когда-либо была написана. Я полагаю, что наконец-то созрел, чтобы написать такую книгу. Во всяком случае, 3:16 — это изучение Библии в другом ракурсе, не имеющее аналогов. Попробую пояснить.

Для ученых из области компьютерных наук естественно изучать сложные вещи, разбивая их на множество простых вещей и затем исследовать случайно выбранную часть. Таким образом, собирая несколько частей, они имеют представление в целом. Это похоже на опрос Гэллапа.

72

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

Однажды, в 70-е, я задался вопросом, а что если я таким образом «исследую» Библию?

(Прим. переводчика: пожалуйста, комменты по вашим рекомендациям перевода присылайте в личку, статья лежала 2 года в черновиках, вот решил доделать Кнута, так что помогайте, дедушка крайне непросто говорит)

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

Язык визуального программирования — это такой язык, который позволяет программисту создавать программы, манипулируя графическими элементами, а не печатая текстовые команды. Известным примером является Scratch, язык визуального программирования родом из MIT, который используется для обучения детей. Его преимущества заключаются в том, что он делает программирование более доступным для новичков и не-программистов.

В 1990-х годах было очень популярное движение по внедрению визуального программирования в корпоративную среду с помощью так называемых CASE-инструментов, где корпоративные системы можно было бы определять с помощью UML и генерировать [их код] без необходимости в привлечении обученных разработчиков программного обеспечения. Это связано с концепцией «round tripping» («туда и обратно»), где система может быть смоделирована визуально, программный код будет генерироваться из полученных моделей, а любые изменения кода могут быть возвращены обратно в модель. Увы, подобные инструменты так и не смогли выполнить свою миссию, и большинство из экспериментов [по их внедрению] в настоящее время в значительной степени заброшены.

Сортировки слиянием работают по такому принципу:

1. Ищутся (как вариант — формируются) упорядоченные подмассивы.
2. Упорядоченные подмассивы соединяются в общий упорядоченный подмассив.

«Я художник, я так вижу!»

«Интернет страдает от отсутствия разумной стандартизации.»

Подключаемся к холивару. А вы за кого?



Недавно на Medium было опубликовано мое противоречивое эссе. Почему все веб-сайты выглядят одинаково? (aka «О визуальной усталости паутины»). Эссе «хайпануло». Пока я пишу это, оно получило более 55 000 просмотров, 27 000 просмотров, 11.300 хлопков и 60 комментариев. Я, очевидно, нервничал.

Итак — спасибо за отзывы. Приятно начинать оживленные дебаты. Но мне трудно адресовать каждое замечание индивидуально. Обратная связь, которую я получил, разнообразна, и комментарии на Medium и Twitter довольно противоречивы. Не вдаваясь в подробности, большая часть обсуждения сводится к известному аргументу «творчество против юзабилити».

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

Примечание автора спустя 42 года после публикации:

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

Любая организация, проектирующая систему (трактуется здесь шире, чем просто информационная система), неизбежно создаст такую модель, которая будет повторять коммуникационную структуру самой организации.

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

Предлагаю вам ознакомиться с материалом, а потом оглянуться и поискать его в других сферах.

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

Как комитеты создают новое?

Мелвин Конвей (Melvin E. Conway)
Оригинал PDF.

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

И самое классное: адаптивность будет добавлена с помощью одной строки CSS.
Это означает, что нам не нужно загромождать HTML лишними классами (Col-sm-4, col-md-8) или создавать медиа-запросы для каждого размера экрана.

Рассмотрим все подробнее.

Двадцать лет назад, когда я начал свою карьеру в дизайне, я делал множество фэйковый вещей.

Я еще отчетливо помню, когда я разрабатывал свои собственные обложки для CD известных групп, создавал фейковый сайт для электронной торговли со своими друзьями, воссоздавал известные логотипы в графическом редакторе «Corel Draw», переделывал популярный вебсайт просто для того, чтобы посмотреть, что бы я сделал иначе, и создавал фэйковый логотипы для несуществующих продуктов, которые ещё не существовали.

Вы можете сказать: «Какая пустая трата времени на неоплачиваемую работу».
Я бы ответил: «Боже, вы не понимаете тонкостей проектирования для реального мира».

Но все эти фейковые работы оказались чрезвычайно важны для моей карьеры.

Я только что закончил семь собеседований в компаниях Кремниевой долины. В конечном итоге я принял предложение разработки программного обеспечения в Facebook.

Вот как я готовился к этим собеседованию и чему я научился на этом пути.

Мой многолетний путь в Кремниевую долину

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

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

Я оставил свое место в качестве ведущего инженера iOS в чудесной компании в Мельбурне и я вернулся обратно в мой родной город Перт, чтобы учиться. Тут я буду готовиться к переговорному процессу которое ждет меня в Кремниевой долине. Я знал, что это будет невероятно сложно и тяжело.

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

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

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

Вот мои 3 (+1 бонусная) наиболее распространенные рекомендации по код-ревью.

Рекомендация 1: Выбрасывайте исключения, если что то идет не так

Зачастую паттерн выглядит так:

List<String> getSearchResults(...) {
  try {
    List<String> results = // make REST call to search service
    return results;
  } catch (RemoteInvocationException e) {
    return Collections.emptyList();
  }
}

Этот паттерн вызвал перебои в одном из мобильных приложений, над которыми я работал. Поиск на стороне сервера, который мы использовали, начал выбрасывать исключения. Оказалось, на серверном API приложения был некоторый код, похожий на приведенный выше. Поэтому приложение получало 200 ответ сервера и с радостью показывало пустой список для каждого поискового запроса.

«Мастер совершает больше ошибок, чем новичок — попыток»

Предлагаем 8 вариантов проектов, которые можно сделать «по фану», дабы получить реальный опыт разработки.

Проект 1. Клон Trello

Клон Trello от Indrek Lasn .

Что вы освоите:

• Организация маршрутов обработки запросов (Routing).
• Drag and drop.
• Как создавать новые объекты (доски, списки, карточки).
• Обработка и проверка входных данных.
• Со стороны клиента: как использовать локальное хранилище, как сохранять данные в локальном хранилище, как читать данные из локального хранилища.
• Со стороны сервера: как использовать базы данных, как сохранять данных в базе, как читать данные из базы.

Тут пример репозитория, сделанного на React+Redux.

tl;dr

• GIF — это круто, но в плане качества и производительности они ужасны.
• Замена GIF на video хорошая идея, но есть недостатки: они не подгружаются предварительно, используют range запросы.
• Сегодня вы можете использовать img src =".mp4" в Safari Technology Preview.
• Предварительные результаты показывают, что mp4s в тегах отображаются в 20 раз быстрее и декодируются в 7 раз быстрее, чем GIF-эквивалент — в дополнение к тому, что размер файла равен 1/14!
• Фоновые CSS-видео и адаптивные видео могут стать клевой фишкой.
• Наконец, синемаграфы будут без недостатков GIF.
• Теперь мы ждем, когда другие браузеры пойдут следом: этот пост весит — 46 МБ на Chrome, и всего 2 МБ в Safari TP.

Особая благодарность: Эрику Портису, Джеку Ноблу, Джону Дэвису, Дорону Шерману и Йоаву Вайсу.

Модуль CSS Grid — это фантастический инструмент для создания макетов веб-сайтов. Он позволяет вам экспериментировать с макетами быстрее, чем любой другой инструмент, которые я пробовал.

В этой статье я научу вас, как это сделать.

Во-первых, я объясню HTML и CSS, которые нам нужны для этой задачи, которую я разбил на четыре части. Как только вы с этим разберетесь, мы перейдем к экспериментам с макетами.

Если вы совершенно не знакомы с CSS Grid, вам может понадобиться просмотреть мою предыдущую статью Учим CSS Grid за 5 минут.

Интерфейс CS-Playground-React

Я программист-самоучка. Это значит, что я постоянно имею дело с синдромом самозванца. Для меня не редкость чувствовать, что я неполноценный, и я в невыгодном положении для понимания сложных концепций информатики.

Я никогда не разбирался в математике. И я всегда привязывал сильные математические навыки к своей естественной способности преуспеть в программировании. Я чувствую, что мне приходится больше работать, чем другим (у которых есть врожденные навыки к математике), чтобы изучать одни и те же понятия. С этой идеей, глубоко укоренившейся в моем мозгу, я был уверен, что никогда не смогу научиться чему-либо, например, обходить деревья двоичного поиска, и как мысленно анализировать рекурсивные кошмары, такие как сортировка слиянием.

Зайдите на CS-Playground-React, простую браузерную JavaScript-песочницу для изучения и практикования алгоритмов и структур данных.

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