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

Содержание

• Вопросы и ответы
  
• Введение
  
  • Пре-реквизиты
    
  • Настройка компьютера
    
  
  
• 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 Фидбек автору
    

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

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

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

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

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

Всем привет!

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

Разработка под FPGA (ПЛИС) — это не просто какой-то язык. Это очень объемная область, с огромным количеством подводных камней и нюансов.

В этой статье вы найдете:

• список тем, которые должен освоить начинающий разработчик под FPGA
• рекомендуемую литературу по каждой из тем
• набор тестовых вопросов и лабораторных работ
• классические ошибки новичков (и советы по исправлению)

Добро пожаловать под кат!

Представляю общественности утилиту RealSync (GPL). Ее призвание — облегчить работу тех, кто периодически мучается от лагов сетевой папки Samba при поиске/редактировании файлов веб-проекта. Идея RealSync в том, что вы теперь работаете с файлами сайта на локальной машине в привычной IDE, а результат, как и прежде, смотрите на удаленном разработческом веб-сервере, куда RealSync копирует изменения в реальном времени. В результате вы можете, например, запустить поиск по всем файлам в IDE — они же локальные, а не подключены через сетевую папку по Samba, так что поиск работает очень быстро; при этом ваш Ctrl+S продолжает попадать на сервер моментально, как и при работе через сетевую папку.

RealSync — утилита для Windows, MacOS и Linux, позволяющая в реальном времени содержать на удаленном сервере точную копию файлов (например, скриптов на PHP, Python, Ruby и др.) из папки на вашем локальном компьютере, даже в условиях плохой связи, когда вы работаете из дома. Все изменения, производимые в локальной папке, попадают на сервер практически моментально (задержка около 0.2 с), независимо от того, сколько этих изменений и каким именно образом они были внесены (хоть через IDE, хоть через Блокнот или Far).

Главное отличие RealSync от аналогов — в том, что он крайне устойчив к нестабильности интернет-соединения, реконнектам и тайм-аутам. При этом используется SSH-соединение, доступ через которое конфигурируется автоматически при первом запуске утилиты (т.е. не нужно возиться с ключами — настройка производится в интерактивном режиме).

Фактически, случайно «убить» RealSync почти невозможно. Вы можете держать его постоянно свернутым в трее и забыть про его существование (CPU он почти не ест). Если утилита видит, что соединение разорвалось на длительный срок, автоматически запускается знакомый многим алгоритм RSYNC для быстрого копирования большого количества различий. В режиме же реального времени применяется собственный протокол поверх SSH, чтобы при нажатии Ctrl+S в редакторе вы сразу же видели изменения на сервере. Передача файла сопровождается приятным «треньканьем» (отключаемым при необходимости в конфиге), а временная потеря связи — покраснением иконки (когда связь восстановится, иконка обратно станет серой, а RealSync «догонит» накопившиеся изменения).

И зачем этот велосипед, когда есть Samba или Денвер или XAMPP?

Представляю на ваш суд ещё один перевод коанов о Мастере Фу на русский язык. В данный сборник вошли все коаны, на данный момент опубликованные на сайте Эрика Реймонда. Надо сказать, что сам Эрик личность весьма неординарная, но упоминания в данной статье стоящая. Помимо холиваров в списках рассылки всевозможных проектов за его авторством также несколько серьёзных трудов о Unix — в том числе и о сообществе, без которого экосистема современных открытых проектов не была бы возможной (полный список книг). Идея перевести коаны в очередной раз пришла мне в голову во время чтения одного из таких трудов, а именно «The Art of Unix Programming», поскольку многое из скрытого смысла коанов становится ясно только после прочтения очередной главы оттуда.

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

Если вы знаете, почему после выполнения `hset mySey foo bar` мы потратим не менее 296 байт оперативной памяти, почему инженеры instagram не используют строковые ключи, зачем всегда стоит менять hash-max-ziplist-entries/hash-max-ziplist-val и почему тип данных, лежащий в основе hash это и часть list, sorted set, set — не читайте. Для остальных я попробую об этом рассказать. Понимание устройства и работы хеш таблиц в Redis критически важно при написания систем, где важна экономия памяти.

О чём эта статья — какие расходы несёт Redis на хранения самого ключа, что такое ziplist и dict, когда и для чего они используются, сколько занимают в памяти. Когда hash хранится в ziplist, когда в dicth и что нам это даёт. Какие советы из модных статей об оптимизации Redis не стоит воспринимать всерьёз и почему.

Если вы знаете, почему простая строка `strings` в Redis займёт в оперативной памяти 56 байт — вам, думаю, статья не будет интересна. Всем остальным я попробую рассказать, что такое строки в Redis и почему использующему эту базу данных разработчику важно понимать, как они устроены и работают. Это знание особенно важно, если вы пытаетесь рассчитать фактическое потребление памяти вашим приложением или планируете строить высоко нагруженные системы статистики или учёта данных. Или, как часто бывает, пытаетесь срочно понять, почему вдруг ваш экземпляр redis стал потреблять неожиданно много памяти.

В первой части я сказал, что хеш таблица это немного LIST, SET и SORTED SET. Судите сами — LIST состоит из ziplist/linkedlist, SET состоит из dict/intset, а SORTED SET это ziplist/skiplist. Мы уже рассмотрели словарь (dict), а во второй части статьи будем рассматривать структуру ziplist — вторую наиболее часто применимую структуру под капотом Redis. Посмотрим на LIST — вторая часть его «кухни» это простая реализация связного списка. Это пригодится нам, чтобы внимательно рассмотреть часто упоминаемый совет об оптимизацию хеш таблиц через их замену на списки. Посчитаем сколько памяти требуется на накладные расходы при использовании этих структур, какую цену вы платите за экономию памяти. Подведём итоги при работе с хеш таблицами, при использовании кодировки в ziplist.

В прошлый раз мы закончили на том, что сохранённые с использованием ziplist 1,000,000 ключей заняли 16 мб оперативной памяти, тогда как в dict эти же данные потребовали 104 мб (ziplist в 6 раз меньше!). Давайте разбираться какой ценой:

В своей предыдущей статье я вкратце коснулся темы создания High Availability решения на основе демона heartbeat. Однако, как выяснилось, что-то сложнее чем 2-х узловой кластер на нем делать не так уж удобно. Изучение проблемы вывело меня на след проекта Pacemaker. Его-то мы сейчас в кратце и рассмотрим.

Некоторое время назад, в силу определенных причин, мне пришла в голову мысль о том, чтобы начать изучать какой-нибудь новый язык программирования. В качестве альтернатив для этого начинания я определил два языка: Java и Python. После продолжительного метания между ними и сопутствующих нытья и долбежки головой о стену (у меня с новыми языками всегда так — сомнения, раздумья, проблема выбора и т.д.), я все-таки остановился на Python. Окей, выбор сделан. Что дальше? А дальше я стал искать материал для изучения…

Многие мои друзья и знакомые крутят пальцем у виска или задаются вопросом: не жмёт ли мне череп, когда узнают, что я пишу драйвера под Linux. Слово “драйвер” окутано каким-то почти мистическим смыслом, и постичь Дао его написания способны лишь избранные гуру.
К счастью это не так. Не знаю, как обстоят дела с написанием драйверов под другие операционные системы, в т.ч. и наиболее популярные, но под linux, вне зависимости от аппаратной архитектуры драйвера пишутся очень просто. Для написания драйвера необходимы базовые знания языка си, представление о работе ОС линукс (базовые), понимание того, что мы хотим получить, желание чтения документации и исходных кодов, ну и усидчивость. Всё.
Вы хотите посмотреть как написать драйвер для своего устройства? Тогда ныряйте под кат!

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

До сих пор мы варились в собственном соку – VLAN’ы, статические маршруты, OSPF. Плавно росли над собой из зелёных студентов в крепких инженеров.
Теперь отставим в сторону эти игрушки, пришло время BGP.

Сегодня мы

• Разбираемся с протоколом BGP: виды, атрибуты, принципы работы, настройка
• Подключаемся к провайдеру по BGP
• Организуем резервирование и распределение нагрузки между несколькими линками
• Рассмотрим вариант резервирования без использования BGP – IP SLA

(оригинал — Jasper St. Pierre, разработчик GNOME Shell, взято отсюда)

Это обзорная статья о составных частях графического стека Linux и том, как они уживаются вместе. Изначально я написал её для себя после разговоров об этом стеке с Оуэном Тейлором, Рэем Строудом и Эдэмом Джексоном (Owen Taylor — мэйнтейнер Gnome Shell; Ray Strode — мэйнтейнер большого количества десктопных пакетов сообщества RedHat; Adam Jackson — разработчик графического стека Gnome Shell и интеграции с XOrg; прим. переводчика). 

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