Внимание! В статье содержатся примеры работы до релизной (до v1.0.0) версии библиотеки.
Скоро выйдет ещё одна статья. Эта только в качестве ознакомления. Всю необходимую для использования библиотеки информацию можно получить в README и комментариях в коде.

Картинка для привлечения внимания:

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

1. Использование системы контроля версий.
2. Грамотное комментирование кода.
3. TDD или хотя бы простое юнит-тестирование кода.

Для первого пришлось освоить азы git, и создать свой первый репозиторий на github. Для второго выбрал JsDoc, из-за которого пришлось перебраться с notepad++ на sublime text (только там был соответствующий плагин).
А вот с третьим, неожиданно для меня, возникли серьёзные трудности.

UPD: Пользователь Sabubu рассказал о том, что IT-директор компании Burger King начал публично угрожать автору расследования.

Вступление

Первое расследование о приложении Burger King создало резонанс в СМИ, а также оказалось в топе Пикабу, TJournal, и Хабрахабр.

Как выяснилось — людям небезразличен шпионаж за ними.

Расследование понравилось и хакерам. С момента публикации, на мой блог совершили десятки хакерских атак.

---

Примечание: все ссылки на официальные ответы и ресурсы Burger King — архивные, в целях предотвращения редактирования либо подмены своих постов администрацией Burger King после или во время написания данной статьи.

Для архивирования ссылок используется проверенный сервис archive.is.

Все оригинальные ссылки — в конце данной статьи.

---

Часть I. Ответы.

Компания Burger King молчала и нагло игнорировала вопросы своих клиентов в течении целого дня после публикации расследования, и ответила только после прямого обращения РосКомНадзора.

Какой ответ мы получили?

Все знают, что вода с маслом не смешивается.

Кто помнит школьную физику, легко назовёт третью жидкость, не смешивающуюся с этими двумя: ртуть.

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

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

Тогда вопрос №2: а сколько можно найти взаимно несмешиваемых жидкостей, которые не страшно принести домой, чтобы показать демку детям?

Мне удалось собрать пять. Собственно, их сливанием вот в эту пробирку мы в статье и займёмся.

Поехали?

Совершенствоваться в сфере разработки — это не только писать хороший код, но и читать о том, как его писать.

Привет, хабр! Продолжаю делиться полезными подборками. Совсем недавно я опубликовал 2 поста с перечнем Github репозиториев: Часть1 и Часть2. На этот раз предлагаю вашему вниманию подборку полезных книг для разработчиков. Кому интересно — добро пожаловать под кат.

Привет, Хаброжители! Хотите разобраться в технологии Биткоин на глубоком концептуальном уровне?

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

Основы технологии Биткоин; хеш-функции и цифровые подписи; криптография и алгоритмы шифрования; анатомия транзакций; верификация и пропускная способность; хард- и софт-форки

От вас не требуется продвинутых навыков программирования, но базовое представление об основах — базах данных, компьютерных сетях, веб-серверах и (о ужас!) математики — не будет лишним.

«Люди важнее, чем идеи.»
— Y Combinator

Многие из лучших идей, которые мы финансировали, были идеями, которые нас удивили, а не идеями, которых мы ждали.

Тем не менее, есть некоторые темы стартапов, которые нам очень интересны. Ниже приведен обновленный запрос на стартапы (Request for Startups, RFS), в котором излагаются некоторые из этих идей в общих чертах.

1. A.I.
2. Bio
3. Brick and Mortar 2.0
4. Carbon Removal Technologies
5. Cellular Agriculture and Clean Meat
6. Cleaner Commodities
7. Computer Security
8. Diversity
9. Education
10. Energy
11. Enterprise Software
12. Financial Services
13. Future of Work
14. Government 2.0 (NEW)
15. Healthcare
16. Improving Memory
17. Longevity and Anti-aging
18. One Million Jobs
19. Programming Tools
20. Robotics
21. Safeguards Against Fake Video
22. Supporting Creators
23. Transportation & Housing
24. Underserved Communities
25. Voice Apps
26. VR and AR

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

Как собрать статистику комментариев к страницам в Confluence?

Да и зачем это может понадобиться?

Я из компании Luxoft.
Предлагаю ознакомиться с расшифровкой доклада Андрей Сальников из Data Egret "Инструменты создания бэкапов PostgreSQL" . В конце обновленная сводная таблица по инструментам

Данный доклад посвящен доступным инструментам бэкапирования PostgreSQL. Логические backup, бинарные backup, встроенные средства бэкапирования и сторонние инструменты. Нужны ли инкрементальные backup, когда они могут действительно помочь. Посмотрим, когда и какой инструмент уместнее использовать. Как лучше автоматизировать процесс бэкапирования и проверки целостности сделанного бэкапа. Посмотрим вблизи на инструменты, такие как pg_dump, pg_basebackup, barman, wal-e, wal-g, pgbackrest, BART и pg_probackup.

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

Доброго времени суток, друзья!

На днях пересмотрел «Матрицу». Слушайте, до чего же классный фильм (это касается только первой части). В очередной раз обратил внимание на «падающие» строчки с иероглифами на ихних экранах (намеренно использовал слово «ихних» забавы ради). Задумался о том, как это можно реализовать… максимально простым способом (ибо лень). Вот что у меня получилось.

CoreHard – C++ конференция, проходящая в Минске дважды в год, весной и осенью. С 2015 года мы выросли из небольшого сообщества энтузиастов в крупную региональную конференцию. Мы стараемся совмещать знания признанных мастеров мира С++ с развитием локального С++ движения, активно привлекая докладчиков из местных белорусских, российских и украинских компаний.

Спешим поделиться с хабровчанами топ-10 свежеиспеченных видео с нашей недавно отшумевшей конференции.

Итак, поехали: топ-10 докладов по оценкам зрителей.

Эта статья из серии, посвященной ликбезу в области космических технологий.

Starlink — план SpaceX раздавать интернет через десятки тысяч спутников — главная тема в посвященной космосу прессе. Еженедельно выходят статьи о последних достижениях. Если в общем-то схема ясная, да ознакомившись с отчетами в Федеральной комиссии связи, хорошо мотивированный человек (скажем, ваш покорный слуга) может накопать очень много деталей. Тем не менее с этой новой технологией по-прежнему связано много заблуждений, даже у просвещенных обозревателей. Нередко попадаются статьи, в которых Starlink сравнивают с OneWeb и Kuiper (среди прочих) так, будто они конкурируют на равных. Другие авторы, явно озабоченные благом планеты, вопиют о космическом мусоре, космическом праве, стандартах и безопасности астрономии. Надеюсь, что дочитав эту — довольно длинную — статью, читатель лучше поймет и проникнется идеей Starlink.

Предыстория

Недавно одна моя знакомая QA Engineer, которая долгое время работала в вялотекущем проекте, где круг ее обязанностей был строго очерчен, сменила работу и устроилась в свежезапущенный проект. Просидев пару дней без обозначенных сверху заданий, и откровенно заскучав, она пошла к руководству с вопросом «Что мне делать?» на что получила многозначительный ответ «Организуй свою работу». И тут она впала в ступор «А это как?». И правда, как?

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

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

Кое-кто отозвался, что я пишу о «прописных истинах», но при этом я получила хороший отклик в комментариях и личных сообщениях из разряда «было полезно», «то, что мне сейчас нужно» и т.п. Но были и вопросы. Вопросы, по большей части, сводились к той «боли», которая не минует ни одного QA за его карьеру:

• как эффективно взаимодействовать с разработчиками?
• как выстраивать работу с ними так, чтобы они приняли: на проекте есть еще одно мнение, мнение QA, и оно тоже важно?
• как побудить их взаимодействовать, например, при построении совместной автоматизации тестирования, когда они не настроены к совместной работе?
• как действовать в том случае, когда твоих технических навыков в стеке используемых технологий просто не хватает?

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

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

Книга даст вам возможность глубже освоить язык Python, проверить себя на испытанных временем задачах, упражнениях и алгоритмах. Вам предстоит решать десятки заданий по программированию: от самых простых (например, найти элементы списка с помощью двоичной сортировки), до сложных (выполнить кластеризацию данных методом k-средних). Прорабатывая примеры, посвященные поиску, кластеризации, графам и пр., вы вспомните то, о чем успели позабыть, и овладеете классическими приемами решения повседневных задач.

Почему двенадцать?

Если вы посмотрите на клавиатуру, то увидите, что в каждой октаве содержится 12 полутонов.
В случае фортепиано это всего лишь значит, что между, например, "до" первой октавы и "до" второй октавы расположено 11 клавиш. Вместе с одним из "до" (например, до второй октавы) мы получим 12 клавиш: до#, ре, ре#, ми, фа, фа#, соль, соль#, ля, ля#, си, до.

Но почему 12?

Может быть это просто случайность? Вот нравилось нашим предкам число 12, у них везде 12: 12 месяцев, 12 знаков зодиака, 12 колен Израилевых, 12 апостолов,… и здесь решили, пусть будет 12, и так и повелось. Или все же здесь есть объективный закон, и это число не случайно?

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

Я должен признаться. Я ненавижу docker. Всей своей душой. Это самая ужасная софтина, которую я видел за последние 10 лет.

С одной стороны, я очень уважаю одноименную компанию. Ребята из Docker Inc. реально популяризировали контейнеризацию. Теперь о ней не знает только ленивый. С другой стороны, ничего принципиально нового они не изобрели — контейнеризация на момент, когда Docker "выстрелил", уже существовала более 30 лет (начиная от chroot, вспомним еще jails и zones, ну, и наконец-то — namespaces & cgroups).

Круто, что docker реально ускоряет разработку во множество раз. Если вести ее правильно, то даже без потери в качестве. В любом случае, docker здесь, от него не деться и приходится им пользоваться.

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

Disclaimer: все написанное ниже является личным мнением автора и может как отражать реальность, так и не отражать реальность. Материал строго провокационного характера и основной целью является не унизить или обидеть кого бы то ни было, а скорее заставить людей включить голову и осознать масштабы глубин (с).

Как тимлид, я хочу поддерживать широкий кругозор. Вокруг множество источников информации, книг, которые интересно прочитать, но не хочется тратить время на ненужные. И я решил узнать, как коллеги выживают в потоке информации и за счет чего поддерживают себя в тонусе. Для этого опросил 50 ведущих экспертов, с которыми мы работали на разных проектах. Это были разработчики, тестировщики, аналитики, архитекторы, специалисты hr, devops, внедрения и сопровождения, менеджеры среднего и высшего звена.



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