Рассуждать о том, что сайт должен быть доступен всегда — моветон и банальность, но 100% доступность, хотя и является обязательным требованием, чаще всего по-прежнему недоступный идеал. Сейчас на рынке существует масса решений, которые обещают максимальный uptime или предлагают решения для его увеличения, но их применение мало того, что не всегда помогает, в некоторых случаях даже может привести к увеличению рисков и снижению доступности проекта. В этой статье мы пройдемся по классическим ошибкам, которые с которыми мы постоянно сталкиваемся. Большинство проблем — элементарные, однако люди допускают их вновь и вновь.

Содержание

1. Введение в Computer Science
2. Структуры данных и Алгоритмы
3. Системное программирование
4. Распределенные системы
5. Базы данных
6. Объектно-ориентированный дизайн и разработка софта
7. Искусственный интеллект
8. Машинное обучение
9. Веб-разработка и интернет-технологии
10. Concurrency
11. Компьютерные сети
12. Разработка мобильных приложений
13. Математика для программистов
14. Теория информатики и языки программирования
15. Архитектура компьютера
16. Безопасность
17. Компьютерная графика
18. Работа с изображениями и компьютерное зрение
19. Интерфейс Человек-Компьютер
20. Вычислительная биология
21. Прочее

Содержание

• Вопросы и ответы
  
• Введение
  
  • Пре-реквизиты
    
  • Настройка компьютера
    
  
  
• 1.0 Играем с Busybox
  
  • 1.1 Docker Run
    
  • 1.2 Терминология
    
  
  
• 2.0 Веб-приложения и Докер
  
  • 2.1 Статические сайты
    
  • 2.2 Образы
    
  • 2.3 Наш первый образ
    
  • 2.4 Dockerfile
    
  • 2.5 Docker на AWS
    
  
  
• 3.0 Многоконтейнерные окружения
  
  • 3.1 SF Food Trucks
    
  • 3.2 Сети Docker
    
  • 3.3 Docker Compose
    
  • 3.4 AWS Elastic Container Service
    
  
  
• 4.0 Заключение
  
  • 4.1 Следующие шаги
    
  • 4.2 Фидбек автору
    

Вопросы и ответы

Что такое Докер?

Определение Докера в Википедии звучит так:

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

Ого! Как много информации.

С началом эпохи HTML5, рынку понадобилось большое количество JavaScript программистов. Многие специалисты по другим языкам, начали массово переориентироваться на JavaScript. Я много раз видел, как программисты с большим опытом ругали этот, один из самых гибких и могучих, язык, не понимая его принципов. В этой статье я постараюсь рассказать суть и философию JavaScript. Здесь будет всего 4 строчки кода и много-много того, что не напишут в учебниках. Обещаю, что вы полюбите этот язык, или по крайней мере, станете эффективнее в нём. Итак, поехали!

По следам интернетовских поисков замены самого культового и дефективного типа файлов

5 ноября 1999 года было объявлено «Днём сжигания всех гифок» [Burn All GIFs Day]. Если бы вы тогда зашли на домашнюю страницу этого проекта, вы бы увидели план его реализации, такой же простой, как его название: «В День сжигания всех GIF все пользователи GIF собираются в Unisys и сжигают все свои файлы GIF». Сопровождали всё это гордые антиподы GIF – файлы формата PNG.

Несмотря на шутку, связанную со сжиганием файлов, сопровождаемую забавной просьбой «потушить все гифки перед тем, как уйти», выражаемое недовольство было реальным, а миссия – настоящей: раз и навсегда избавить веб от его бича, формата GIF.

К тому моменту формату было уже больше десяти лет, он зародился лет за пять до самой сети, и он начинал устаревать. Он поддерживал жалкие 256 цветов. Его возможности анимации были хуже, чем у бумажного блокнота. Он явно был недоразвит по сравнению с любым более новым форматом файлов. И кроме всего прочего, держатели патентов уже пять лет угрожали судебными исками пользователям формата. Ко «Дню сжигания всех гифок» он уже находился на краю пропасти. Специалисты по форматам файлов и будущему сети обступили устаревший формат, вооружившись картинками с факелами и вилами в формате PNG.

И всё же, каким-то образом, мы с вами оказались в такой вот ситуации. Прошло 17 лет, а GIF не умер. Он правит интернетом.

Привет GT!
4 июня в Москве пройдёт очередной фестиваль музыкальных технологий Synthposium. На нём соберутся любители синтезаторов, чтобы крутить ручки, собирать патчи, нажимать на клавиши и восхищаться звуками.
Нас тоже пригласили сделать для фестиваля что-нибудь прикольное.
И мы собрали аналоговый оптический синтезатор.

(Осторожно, трафик!)

Добрый день.

Для своей первой статьи я выбрал одну из самых успешных своих поделок: HDMI-passthrough аналог Ambilight от Philips, далее я будут называть эту композицию «Атмосвет».

Введение

В интернетах не очень сложно найти готовые/открытые решения и статьи как сделать Амбилайт для монитора/телевизора, если ты выводишь картинку с ПК. Но в моей мультимедиа системе вывод картинки на телевизор c ПК занимает только 5% времени использования, большее кол-во времени я играю с игровых консолей, а значит нужно было придумать что-то свое.

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

Сегодня у многих IT-компаний есть собственные bounty-программы (или программы по поиску уязвимостей). Badoo — в их числе.

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

Со времени старта нашей bounty-программы прошло три года. Нам до сих пор продолжают присылать сообщения участники со всего мира.

Мы хотим усилить интерес к ней, в том числе со стороны иностранных исследователей. Поэтому мы, во-первых, открыли страничку с нашей программой на крупнейшем портале исследователей hackerone.com, а во-вторых — увеличили суммы вознаграждений за найденные уязвимости! Теперь сумма вознаграждения, в зависимости от категории, начинается от £100 и может достигать £1000, сумма супер-премии составляет £2000 (а это более 200 000 рублей по текущему курсу!) и даже больше, если обнаруженная уязвимость представляет реальную угрозу для наших пользователей.

Введение

Давненько мы ничего не публиковали про SAP, и сегодня мы рассмотрим уязвимость, которая затрагивает любое SAP решение от старинного R/3 до новомодной HANA. Имя этой уязвимости – межсайтовый скриптинг (XSS). Статья эта, вопреки нашему обычному повествованию про поиск и эксплуатацию уязвимости, будет по большей части посвящена защите от данной уязвимости.

Межсайтовый скриптинг — одна из самых распространенных уязвимостей вообще, и в продуктах SAP в частности. Так, за 12 лет в SAP было обнаружено 628 XSS-уязвимостей, что составляет 22% от всех уязвимостей в SAP. Только исследователи ERPScan нашли 52 XSS-уязвимости в SAP, и то потому, что больше времени уходило на написание Advisory и бюрократические моменты, чем на непосредственный поиск уязвимостей. Более подробная информация по всем уязвимостям может быть изучена в нашем исследовании "Analysis of 3000 vulnerabilities in SAP", а мы переходим к основной части.

5-я авеню в Нью-Йорке, 1974

На фотографиях городских улиц 70-х и ранних 80-х годов почти всё выглядит так же, как сегодня. Большинство зданий, одежда (не считая подкладок под плечи). Но что сильно отличается – все автомобили выглядят, как квадратные коробки, особенно по сравнению с обтекаемыми закруглёнными кузовами почти любого современного автомобиля.





Это преобразование, на которое не так часто обращают внимание, одно из самых заметных, случившихся с машинами за последние 50 лет. А в США это случилось за несколько лет, начиная с 1986-го. Можно даже назвать точный год, когда некоторые модели превратились в обтекаемые — Buick LeSabre, который в 1991 году был гораздо более угловат, чем в 1992.

В мае 2010 году произошел один из крупнейших биржевых обвалов — за считанные минуты рынок потерял триллион долларов. Это событие получило название Flash Crash, а одним их главных его виновников власти США и Велокбритании назвали скромного трейдера из Лондона. Мы представляем вашему вниманию адаптированный перевод рассказа издания Bloomberg о главном герое этой истории.

История одного из самых драматичных моментов во всей истории Уолл-стрит началась в скромном доме на западной окраине Лондона, где постоянно слышен шум снижающихся для посадки в Хитроу самолетов. Именно здесь жил трейдер Навиндер Сингх Сарао (Navinder Singh Sarao), и до этого дня он ничем не выделялся из тысяч таких же, как он.

Hello, Habr! Недавно мы получили от “Известий” заказ на проведение исследования общественного мнения по поводу фильма «Звёздные войны: Пробуждение Силы», премьера которого состоялась 17 декабря. Для этого мы решили провести анализ тональности российского сегмента Twitter по нескольким релевантным хэштегам. Результата от нас ждали всего через 3 дня (и это в самом конце года!), поэтому нам нужен был очень быстрый способ. В интернете мы нашли несколько подобных онлайн-сервисов (среди которых sentiment140 и tweet_viz), но оказалось, что они не работают с русским языком и по каким-то причинам анализируют только маленький процент твитов. Нам помог бы сервис AlchemyAPI, но ограничение в 1000 запросов в сутки нас также не устраивало. Тогда мы решили сделать свой анализатор тональности с блэк-джеком и всем остальным, создав простенькую рекурентную нейронную сеть с памятью. Результаты нашего исследования были использованы в статье “Известий”, опубликованной 3 января.



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

Всем привет! Я Максим Андреев, программист бэкенда Облака Mail.Ru. В свободное время я люблю искать баги. В сегодняшнем посте я хочу рассказать об одной довольно интересной уязвимости, которую я нашёл и зарепортил в bug bounty нескольких крупных компаний, за что получил солидное вознаграждение. Уязвимость заключается в следующем: если сформировать специальный видеофайл и загрузить его на сервер, то:

• можно получить на нём SSRF;
• можно получить local file read;
• если пользователь скачает этот файл, то автоматически будет подвержен уязвимостям, даже если его не откроет: можно будет получить доступ к данным на компьютере пользователя и узнать его имя.

В этой части я дойду до момента, когда пришла смс-ка «Не звони и не пиши мне больше!!!!»

В ресторане заиграла почти забытая песня. Вы слушали её в далёком прошлом. Сколько трогательных воспоминаний способны вызвать аккорды и слова… Вы отчаянно хотите послушать эту песню снова, но вот её название напрочь вылетело из головы! Как быть? К счастью, в нашем фантастическом высокотехнологичном мире есть ответ на этот вопрос.

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

Мобильные технологии и невероятный прогресс в области обработки звука дают разработчикам алгоритмов возможность создавать приложения для распознавания музыкальных произведений. Одно из самых популярных решений такого рода называется Shazam. Если дать ему 20 секунд звучания, неважно, будет ли это кусок вступления, припева или часть основного мотива, Shazam создаст сигнатурный код, сверится с базой данных и воспользуется собственным алгоритмом распознавания музыки для того, чтобы выдать название произведения.

Как же всё это работает?

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

Если вы знаете, как валидировать email-адрес, поднимите руку. Те из вас, кто поднял руку — опустите её немедленно, пока вас кто-нибудь не увидел: это достаточно глупо — сидеть в одиночестве за клавиатурой с поднятой рукой; я говорил в переносном смысле.

До вчерашнего дня я бы тоже поднял руку (в переносном смысле). Мне нужно было проверить валидность email-адреса на сервере. Я это уже делал несколько сот тысяч раз (не шучу — я считал) при помощи классного регулярного выражения из моей личной библиотеки.

В этот раз меня почему-то потянуло ещё раз осмыслить мои предположения. Я никогда не читал (и даже не пролистывал) RFC по email-адресам. Я попросту основывал мою реализацию на основе того, что я подразумевал под корректным email-адресом. Ну, вы в курсе, что обычно говорят о том, кто подразумевает. [прим. перев. Автор имеет в виду игру слов: «when you assume, you make an ass out of you and me» — «когда вы (что-то) подразумеваете, вы делаете /./удака из себя и из меня»]

И обнаружил кое-что занимательное: почти все регулярные выражения, представлены в интернете как «проверяющие корректность email-адреса», излишне строги.

Здравствуйте, меня зовут Александр Зеленин и я веб-разработчик. Я расскажу, как сделать так, чтобы ваш сайт открывался быстро. Очень быстро.

Пост — резюме

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

Недавно, на хакатоне от Petamelon нам в руки попал датасет с ~6 000 000 резюме с НН. Там, естественно, не было никаких персональных данных и контактов, но было много других интересных вещей: ожидаемая зарплата, возраст, пол, примерный адрес, образование и индустрии, в которых человек ищет работу. Было решено попробовать использовать эти данные в нашем проекте про выбор школ. Идея заключалась в том, чтобы определить в каких индустриях работают выпускники школ и сколько примерно зарабатывают. Но я, конечно, не удержался и построил кучу других бесполезных, но прикольных таблиц и графиков.

Распределение резюме по возрасту имеет интересную форму и как будто разделено на две части: до окончания института и после:


В Москве с возрастом ожидаемая зарплата выходит на плато в ~50 000 рублей: