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

Я попробовал Syncthing, бесплатную альтернативу с открытым исходным кодом. И знаете, что? Это стало освобождением. Разумность, простота, надежность, различные функции. Это приносит радость от использования и заставляет поверить в то, что распад цивилизации можно немного замедлить.

Синхронизация — это все, что я любил в компьютерах.

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

Продолжая тему устройства в FAANG, которую уже мы поднимали в нашем блоге, и специально к старту нового потока нашего курса по алгоритмам сегодня делюсь описанием пути Эско Обонга, старшего инженера-программиста Uber.

Эта история началась в 2015 году, когда стартап, к которому я присоединился как «сотрудник-основатель», закрылся через шесть месяцев после первого раунда инвестиций, и я искал новую работу. Первое моё собеседование было с  Codecademy, где на этапе телефонного разговора меня заверили: «Не волнуйтесь, мы не задаём сумасшедших вопросов об алгоритмах или что-то в этом роде». И я им поверил…

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

Django ORM (Object Relational Mapping) является одной из самых мощных особенностей Django. Это позволяет нам взаимодействовать с базой данных, используя код Python, а не SQL.
Based on schegel.net

Для демонстрации опишу такую модель:

from django.db import models

class Blog(models.Model):
    name = models.CharField(max_length=250)
    url = models.URLField()

    def __str__(self):
        return self.name

class Author(models.Model):
    name = models.CharField(max_length=250)

    def __str__(self):
        return self.name

class Post(models.Model):
    title = models.CharField(max_length=250)
    content = models.TextField()
    published = models.BooleanField(default=True)
    blog = models.ForeignKey(Blog, on_delete=models.CASCADE)
    authors = models.ManyToManyField(Author, related_name="posts")

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

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

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

Прим. перев.: Содержимое этой статьи не совсем типично для нашего блога. Однако, как многим известно, etcd находится в самом сердце Kubernetes, из-за чего данное исследование, проведённое независимым консультантом в области надёжности, оказалось интересным и в среде инженеров, эксплуатирующих данную систему. Кроме того, оно интересно в разрезе того, как Open Source-проекты, уже зарекомендовавшие себя в production, совершенствуются даже на таком, весьма «низком», уровне.



Хранилище пар «ключ-значение» (KV) etcd представляет собой распределённую базу данных, основанную на алгоритме консенсуса Raft. В ходе анализа, проведенного в 2014 году, мы обнаружили, что etcd 0.4.1 по умолчанию была подвержена так называемым stale reads (операциям чтения, возвращающим старое, неактуальное значение из-за запаздывания синхронизации — прим. перев.). Мы решили вернуться к etcd (в этот раз — к версии 3.4.3), чтобы снова детально оценить ее потенциал в области надежности и безопасности.

Здравствуйте! В статье я покажу, как написать и запустить на ноде Waves обычный dApp. Рассмотрим необходимые инструменты, методы и пример разработки.



Схема разработки dApps и обычных приложений почти не отличается:

• Пишем код
• Пишем автоматизированное тестирование
• Запускаем приложение
• Тестируем

Инструменты

1. docker для запуска ноды и Waves Explorer

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

• Вам постоянно будут нужны новые аккаунты с тестовыми токенами. Кран тестовой сети переводит по 10 WAVES каждые 10 минут.
• Среднее время блоков в тестовой сети – 1 минута, в ноде – 15 секунд. Это особенно ощутимо, когда транзакция требует нескольких подтверждений.
• В общедоступных тестовых нодах возможно агрессивное кэширование.
• Еще они могут быть временно недоступны из-за технического обслуживания.

Далее буду считать, что вы работаете со своей нодой.

2. Инструмент командной строки Surfboard

• Скачайте и установите Node.js с помощью ppa, homebrew или exe здесь: https://nodejs.org/en/download/.
• Установите Surfboard – инструмент, который позволит запустить тесты на существующей ноде.

npm install -g @waves/surfboard

3. Плагин Visual Studio Code

Шаг необязателен, если вы – не фанат IDE и предпочитаете текстовые редакторы. Все необходимые инструменты – это утилиты командной строки. Если используете vim, обратите внимание на плагин vim-ride.

В компании нашу команду по противостоянию DDoS-атакам называют «отбрасыватели пакетов» (the packet droppers — прим. пер). Пока все остальные команды делают клёвые штуки с проходящим через нашу сеть трафиком, мы развлекаемся поиском новых способом избавиться от него.


Фотография: Brian Evans, CC BY-SA 2.0

Умение быстро отбрасывать пакеты очень важно в противостоянии DDoS-атакам.

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

28-29 мая в Сколково пройдет фестиваль конференций РИТ++. На стенде Ingram Micro Сloud мы устраиваем битву в игре-головоломке CloudPipe за главный приз — электросамокат. Побороться за другие награды можно удаленно, регистрация и подробности на cloudpipe.win

И это не единственная активность Ingram Micro Cloud на РИТ++. На разных конференциях можно будет еще послушать выступления наших ребят. Подробности — под катом.

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

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

Прошёл второй день РИТ++, и по горячим следам мы хотим рассказать о том, как всем миром пытались сломать нашу голосовалку. Под катом — код, метрики, имена победителей и самых активных участников, и прочие грязные подробности.

UPD 6 июня, 13:00 Промежуточные итоги половины дня (играем до 18.00)


UPD 6 июня, 12:40

361K RPS Голосуй за свой ЯП? #ritfest2017 high load голосование https://t.co/CbbDhHJKNj @IngramCloud pic.twitter.com/mT6jfI9L4G

— Alex Hayorov (@hayorov) June 6, 2017

6 июня, 10:00
Сегодня второй день! Мы добавили мощностей и немного изменили дизайн, теперь вы можете видеть топ-5 голосующих.



Приходите на наш стенд рядом с конгресс-холлом.

Всем привет! Серией данных дайджестов на Habrahabr хотелось бы продолжить некогда начатую alrusdi, Dead_Angel, WarmongeR идею опубликования свежих новостей, статей, релизов из мира Python.

Планируется выпускать дайджест 2 раза в месяц. Это будет не очень большие по размеру статьи с интересными (на взгляд автора) материалами из мира Python. Будут очень приветствоваться присланные актуальные материалы, которые будут добавлены в ближайший дайджест, а также люьые замечания и предложения.

А теперь к делу!

Часть 1	Часть 2	Часть 3	Часть 4

Продолжим изучать общие принципы работы со стандартными коллекциями (модуль collections в ней не рассматривается) Python. Будут рассматриваться способы объединения и обновления коллекций с формированием новой или изменением исходной, а также способы добавлять и удалять элементы в изменяемые коллекции.

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

Оглавление:

1. Объединение строк, кортежей, списков, словарей без изменения исходных.
2. Объединение множеств без изменения исходных.
3. Объединение списка, словаря и изменяемого множества с изменением исходной коллекции.
4. Добавление и удаление элементов изменяемых коллекций.
5. Особенности работы с изменяемой и не изменяемой коллекцией.

Работать в Sketch легко. Многие знают, как использовать базовые функции. Но не все работают с плагинами, которые расширяют возможности программы. Я расскажу о 7 полезных дополнениях, которые помогают оптимизировать трудозатраты и автоматизировать некоторые задачи.

Небольшой хинт: большинство плагинов, про которые идет речь, доступны в Sketch Toolbox. Это отдельная небольшая программа с поиском и возможностью быстрого удаления/установки плагинов.

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

В примерах используется JavaScript ES2015). (Почему JavaScript?)

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

В документе используются термины из спецификации Fantasy Land spec по мере необходимости.

Arity (арность)

Количество аргументов функции. От слов унарный, бинарный, тернарный (unary, binary, ternary) и так далее. Это необычное слово, потому что состоит из двух суффиксов: "-ary" и "-ity.". Сложение, к примеру, принимает два аргумента, поэтому это бинарная функция, или функция, у которой арность равна двум. Иногда используют термин "диадный" (dyadic), если предпочитают греческие корни вместо латинских. Функция, которая принимает произвольное количество аргументов называется, соответственно, вариативной (variadic). Но бинарная функция может принимать два и только два аргумента, без учета каррирования или частичного применения.

Мысли Криса Койера

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

От переводчика

Всем привет, с вами Максим Иванов, и сегодня мы поговорим на довольно острую тему в сфере веб-разработки. Как утверждает Крис Койер, frontend-разработчик должен разбираться в очень многих вещах, о которых не все даже и задумываются. Конечно, мы должны понимать, что frontend-разработчик не главный в процессе разработки любого онлайн-сервиса или ПО в целом. На ту же позицию frontend-разработчика вы найдете больше откликов на вакансию, чем на позицию backend-разработчиком. Но почему же тогда Крис Койер считает, что работать frontend-разработчиком сложнее, ибо ты должен специализироваться во всем. Конечно, ситуаций в жизни очень много, разные компании по-разному используют своих специалистов, но в чем наверняка должен разбираться frontend-разработчик? Об этом мы сегодня и поговорим. Жду комментариев на эту тему, а сейчас приступим.

Frontend Guidelines

Правила и руководства оформления, форматирования HTML, СSS и JavaScript кода. Его цель — повысить качество кода и облегчить совместную работу и поддержку инфраструктуры.

От переводчика

Приветствую всех снова, меня зовут Максим Иванов, и сегодня я подготовил перевод, который, возможно, окажется для вас полезным. Бенджамин Де Кук (Benjamin De Cock), разработчик из Бельгии, собрал некоторые указания по оформлению кода, которые позиционируют себя как лучшие практики по написанию HTML, CSS, JS. Конечно, существует множество рекомендаций, например, есть хороший гайдлайн от Google, наверное, есть еще что-то, однако, если следовать хотя бы некоторым из них, то можно надеяться, что ваш код станет лучше. В отдельных случаях следование этим гайдлайнам не полезно, а совсем наоборот. В общем и целом, все зависит от вашего опыта и виденья дела, если вы новичок, то скорее вам будет полезно оценить то, что пишут другие и в обществе считается верным, если вы гуру, то наверное вам и не нужны гайдлайны, которые написаны непонятно кем на ваш взгляд. Итак, приступим.

Всего через два месяца после версии 2.6 вышел Git 2.7 с новыми возможностями, исправлениями и улучшениями производительности. Что интересного он нам приготовил? Я расскажу о нескольких новинках, которые показались интересными команде Bitbucket.

Полноценный набор команд git worktree

Команда git worktree появилась в Git 2.5, она позволяет выгружать и одновременно работать со многими ветками репозитория в отдельных папках. Например, если нужно сделать срочную правку, но при этом не хочется трогать текущую рабочую копию, можно просто выгрузить нужную ветку в новую папку с помощью команды:

$ git worktree add -b hotfix/BB-1234 ../hotfix/BB-1234
Preparing ../hotfix/BB-1234 (identifier BB-1234)
HEAD is now at 886e0ba Merged in bedwards/BB-13430-api-merge-pr (pull request #7822)

Что-то в последнее время технические статьи о виртуализации (да и не только о виртуализации) скатываются к формату «в новой версии ожидается такая фича». Складывается ощущение, что разбор механизмов и описание опыта, проблем и решений интересны только зарубежным экспертам. С другой стороны, есть такая проблема у экспертов — если что-то изучил, оно становится элементарным и воспринимается само собой разумеющимся, настолько, что писать об этом как-то глупо. Особенно если уже было кем-то описано где-то. Когда-то. На каком-то языке. Ниженаписанное — плод консолидации личных заметок, сначала предназначавшийся для личного упорядочивания мыслей, но наупорядочив значительный объём текста, подумал, что кому-то может пригодиться.

Типовая проблема «виртуализаторов» — владелец сервиса, заказчик или пользователь жалуется, что у него «тормозит» виртуальная машина. Так как виртуализация предполагает консолидацию большого количества ВМ на базе одного комплекта аппаратных ресурсов, переподписку (overprovision — когда мы предполагаем, что серверы не затребуют одновременно максимум своих ресурсов, а значит, например, в 40 ГБ физической памяти мы можем натолкать не 10 серверов по 4 ГБ RAM, а 15, используя Dynamic Memory), а кроме того, серверы могут тормозить и из-за ошибок в программных компонентах и их настройках, то каждый раз приходится решать за что хвататься и куда смотреть в первую очередь. Особенно, если с таким ёмким описанием проблемы, как «тормозит машина» не предоставлено никакой диагностической информации, как чаще всего и бывает. Под катом небольшое руководство для этого случая.