Реляционные базы данных (РБД) используются повсюду. Они бывают самых разных видов, от маленьких и полезных SQLite до мощных Teradata. Но в то же время существует очень немного статей, объясняющих принцип действия и устройство реляционных баз данных. Да и те, что есть — довольно поверхностные, без особых подробностей. Зато по более «модным» направлениям (большие данные, NoSQL или JS) написано гораздо больше статей, причём куда более глубоких. Вероятно, такая ситуация сложилась из-за того, что реляционные БД — вещь «старая» и слишком скучная, чтобы разбирать её вне университетских программ, исследовательских работ и книг.

На самом деле, мало кто действительно понимает, как работают реляционные БД. А многие разработчики очень не любят, когда они чего-то не понимают. Если реляционные БД используют порядка 40 лет, значит тому есть причина. РБД — штука очень интересная, поскольку в ее основе лежат полезные и широко используемые понятия. Если вы хотели бы разобраться в том, как работают РБД, то эта статья для вас.

Вот уже как неделю английская версия the art of command line висит в секции trending на Github. Для себя я нашел этот материал невероятно полезным и решил помочь сообществу его переводом на русский язык. В переводе наверняка есть несколько недоработок, поэтому милости прошу слать пулл-реквесты мне сюда или автору оригинальной работы Joshua Levy вот сюда. (Если PR отправите мне, то я после того, как пересмотрю изменения отправлю их в мастер-бранч Джоша). Отдельное спасибо jtraub за помощь и исправление опечаток.

Добрый день!

Недавно прочитал очень интересную статью про обработку 50 гигабит/с на сервере и вспомнил, что у меня в черновиках лежит статья про то, как мы год назад разрабатывали систему мониторинга видео-потоков с общим объёмом трафика до 100 Гбит/с. Ещё раз “вычитал” её и решил представить на суд разработчиков. Статья больше посвящена анализу протоколов и поиску архитектурного решения, нежели тюнингу всевозможных подсистем linux’а, потому что мы пошли по пути распределения нагрузки между сервером и сетевыми пробниками, которые подключаются к транспортным потокам 10 Gigabit Ethernet.



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

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



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

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

Если вы последний год пользовались мобильными приложениями от ВКонтакте (пусть даже не официальными), то этот материал раскроет немного данных по тому, как у нас это время работают пуш уведомления. Пушилка реализована на языке Go, и рассылает до 9 миллиардов пушей в сутки на четыре целевых платформы: GCM, APNS, MPNS, WNS.

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

В последние несколько лет MongoDB приобрела огромную популярность среди разработчиков. То и дело в интернете появляются всякие статьи, как очередной молодой популярный проект выкинул на свалку истории привычные РСУБД, взял в качестве основной базы данных MongoDB, выстроил инфраструктуру вокруг неё, и как все после этого стало прекрасно. Даже появляются новые фреймворки и библиотеки, которые строят свою архитектуру целиком на Mongo (Meteor.js например).

По долгу работы я примерно 3 года занимаюсь разработкой и поддержкой нескольких проектов, которые используют MongoDB в качестве основной БД, и в этой статье хочу рассказать, почему на мой взгляд с MongoDB далеко не все так просто, как написано в мануалах, и к чему вы должны быть готовы, если вдруг решите взять MongoDB в качестве основной БД в ваш новый модный стартап :-)

Все что описано ниже можно воспроизвести с использованием библиотеки PyMongo для работы с MongoDB из языка программирования Python. Однако скорее всего с аналогичными ситуациями вы можете столкнуться и при использовании других библиотек для других языков программирования.

Abstract: как работает open-iscsi (ISCSI initiator в linux), как его настраивать и чуть-чуть про сам протокол ISCSI.

Лирика: В интернете есть множество статей довольно хорошо объясняющих, как настроить ISCSI target, однако, почему-то, практически нет статей про работу с инициатором. Не смотря на то, что target технически сложнее, административной возни с initiator больше — тут больше запутанных концепций и не очень очевидные принципы работы.

ISCSI

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

NAS vs SAN

Существует два метода доступа к данным, находящимся на другом компьютере: файловый (когда у удалённого компьютера запрашивают файл, а какими файловыми системами это сделано — никого не волнует), характерные представители NFS, CIFS (SMB); и блочный — когда у удалённого компьютера запрашивают блоки с дискового носителя (аналогично тому, как их читают с жёсткого диска). В этом случае запрашивающая сторона сама себе делает на блочном устройстве файловую систему, а сервер, отдающий блочное устройство, знать не знает про файловые системы на нём. Первый метод называют NAS (network attached storage), а второй — SAN (storage area network). Названия вообще указывают на другие признаки (SAN подразумевает выделенную сеть до хранилищ), но так сложилось, что NAS — это файлы, а SAN — это блочные устройства по сети. И хотя все (?) понимают, что это неправильные названия, чем дальше, тем больше они закрепляются.

Классические компьютерные игры начались ещё, собственно, до появления компьютеров в виде интерактивных книг. Скорее всего, в детстве у вас была одна такая либо Браславского, либо вообще из цикла про Стальную Крысу Гаррисона.



Смысл очень прост: внутри подаётся сюжет, который зависит от вашего выбора. Простейшее ветвление такое: вы дошли до развилки. Если вы хотите повернуть направо, откройте страницу 11, если налево – 182. На соответствующих страницах будет продолжение истории про то, что случится после вашего выбора.

Базовый сюжет строился в виде системы узлов и переходов. За один проход вы задействовали примерно 25-35% страниц книги.



То есть техническая вариативность сводилась к тому, что вы всё равно получали 80% основного сюжета, но просто не всегда линейно и не всегда с одной и той же точки зрения. И автоматизации там не было почти никакой, кроме того, что вы листали страницы.

Моя статья расскажет Вам как принять 10 миллионов пакетов в секунду без использования таких библиотек как Netmap, PF_RING, DPDK и прочие. Делать мы это будем силами обычного Линукс ядра версии 3.16 и некоторого количества кода на С и С++.



Сначала я хотел бы поделиться парой слов о том, как работает pcap — общеизвестный способ захвата пакетов. Он используется в таких популярных утилитах как iftop, tcpdump, arpwatch. Кроме этого, он отличается очень высокой нагрузкой на процессор.

Итак, Вы открыли им интерфейс и ждете пакетов от него используя обычный подход — bind/recv. Ядро в свою очередь получает данные из сетевой карты и сохраняет в пространстве ядра, после этого оно обнаруживает, что пользователь хочет получить его в юзер спейсе и передает через аргумент команды recv, адрес буфера куда эти данные положить. Ядро покорно копирует данные (уже второй раз!). Выходит довольно сложно, но это не все проблемы pcap.

Кроме этого, вспомним, что recv — это системный вызов и вызываем мы его на каждый пакет приходящий на интерфейс, системные вызовы обычно очень быстры, но скорости современных 10GE интерфейсов (до 14.6 миллионов вызовов секунду) приводят к тому, что даже легкий вызов становится очень затратным для системы исключительно по причине частоты вызовов.

Также стоит отметить, что у нас на сервере обычно более 2х логических ядер. И данные могут прилететь на любое их них! А приложение, которое принимает данные силами pcap использует одно ядро. Вот тут у нас включаются блокировки на стороне ядра и кардинально замедляют процесс захвата — теперь мы занимаемся не только копированием памяти/обработкой пакетов, а ждем освобождения блокировок, занятых другими ядрами. Поверьте, на блокировки может зачастую уйти до 90% процессорных ресурсов всего сервера.

Хороший списочек проблем? Итак, мы их все геройски попробуем решить!

Как построить график по n точкам? Самое простое — отметить их маркерами на координатной сетке. Однако для наглядности их хочется соединить, чтобы получить легко читаемую линию. Соединять точки проще всего отрезками прямых. Но график-ломаная читается довольно тяжело: взгляд цепляется за углы, а не скользит вдоль линии. Да и выглядят изломы не очень красиво. Получается, что кроме ломаных нужно уметь строить и кривые. Однако тут нужно быть осторожным, чтобы не получилось вот такого:

Недавно потребовалось мне сделать небольшую прогу под Windows. Раньше мне не доводилось разрабатывать под нее.
Сама программа несложная, написалась относительно быстро. Намного больше времени отъела сборка ее под винду. Понятно, что выбранные инструменты (Python3 + Qt5) не родные, а универстальные, но что потребуется столько времени затратить на сборку, я не предполагал.
Соответственно, хочется поделиться практикой, может кому еще придется стучаться лбом в эту стену.
Под катом выстраданная инструкция как легко собирать PyQt5 приложения в single-file.exe не требующий инсталлятора.

Другие статьи цикла:
Хроники лаборатории: как мы молотый кофе считали софтом для анализа клеточных структур
Компот из кофейных сухофруктов. Знакомимся с каскарой — лучшим другом велосипедиста

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

На Хабре/Гиктаймсе уже не раз обсуждался кофе и все, что с ним связано. Я решил написать пост, посвященный этому напитку и различным эффектам кофеина с медицинской точки зрения. Если хватит времени — возможно это будет цикл статей с экспериментами над людьми, computer vision и прочим непотребством. Увидим. А пока, товарищи кофеиноманы и им сочувствующие, добро пожаловать под кат.

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

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

Мы испытываем серьезную нехватку талантов, хотя индустрия довольно молода. Большинство софтверных проектов проваливаются, и практически все превышают бюджет. А лучшая идея, которую могут предложить сильнейшие умы, сводится к «Есть несколько стандартных способов решения подобных проблем, но наши решения часто не срабатывают. Единственное, что можно сделать — это попробовать и посмотреть на результат».

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

На самом деле, попытка оценивать людей временными интервалами – слишком упрощенный способ для таких тонких материй, как знание и профессиональный опыт. Но дела обстоят именно так. И если продолжать классифицировать специалистов подобным образом, то самое время нашей индустрии брать тайм-аут. Есть разница между человеком с 10-летним опытом, и тем, кто за то же время стал опытнее в 10 раз.


Постер из сериалa «Компьютерщики»

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

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

Но в итоге я всё же сделал усилие над собой: сначала немного вник в азы торговли акциями, а потом наконец решился и начал торговать акциями на фондовых рынках США (NYSE, NASDAQ, AMEX). И, самое главное, я понял, что купить акции — это не так уж и сложно, как казалось раньше, и даже не так затратно (в плане накладных расходов), как я предполагал. И в этой статье я хочу поделиться исключительно своим опытом в данной области в виде общих теоретических сведений и практического руководства (HOWTO) для новичков.

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

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

Разделил статью на две части:

1. В первой части рассмотрим теоретические основы торговли акциями.
2. Во второй части будет практическое руководство для новичков по покупке и продаже акций.

Привет хабр!

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

"Пфф, ссылки они и в Африке ссылки, чего тут разбираться?" — скажете вы, тогда я задам вопрос:

Что есть что и куда нас приведет?

• http://example.com
• www.example.com
• //www.example.com
• mailto:user@example.com

Если вы не знаете однозначного ответа или вам просто интересно и если вы не боитесь огромного количества трехбуквенных аббревиатур — милости прошу под кат.

Предлагаю читателям «Хабрахабра» перевод текста «Why we encrypt» авторства гуру информационной безопасности Брюса Шнайера.

Шифрование защищает наши данные. Оно защищает наши данные на компьютерах и в дата-центрах, защищает их во время передачи через интернет. Защищает наши видео-, аудио- и текстовые разговоры. Защищает нашу частную информацию. Защищает нашу анонимность. Иногда защищает наши жизни.

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

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

Этот урок описывает метод планирования течения игры и навигации юнитов, который использует многоагентные потенциальные поля. Он основан на работах под номерами [1, 2, 3]. (Смотри в конце статьи ссылки на используемые материалы)

В этой статье я расскажу о своём опыте создания отдельного сервера («ферма» уж больно громко сказано) для рендеринга видео в домашних условиях.




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

Вторая проблема – это монтаж самого видео. Несмотря на то, что современные компьютеры становятся мощнее, развитие видеокамер тоже не стоит на месте и получившиеся видео файлы становятся всё тяжелее и тяжелее. И, как следствие, их становится проблематично обрабатывать. Когда монтируешь продолжительный фильм, то предпросмотр трека с наложенными фильтрами и переходами начинает подгружать процессор и изображение начинает лагать, делая творческий процесс монтажа утомительным. Из того, что я пробовал, самый продуктивный был iMovie, что предустановлен на всех Маках. Даже фильм продолжительностью в 45 минут можно было редактировать без особых проблем на относительно маломощном макбуке. Можно было применить любой фильтр и увидеть результат в окне предпросмотра без каких-либо лагов. Так что владельцам маков тут повезло. Один минус у iMovie: во время работы он начинает потреблять непомерное количество дискового пространства. Видимо, это связано с агрессивным кэшированием для редактирования и предпросмотра.

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

Недавно мы в «Я люблю ИП» закончили курсы по дизайну от trydesignlab.com. И это одна из самых важных статей, которую нам посоветовал ментор в процессе обучения. Именно поэтому мы решили её перевести. Посмотреть все наши работы с курсов можно в ВКонтакте по тэгу #design101@iloveip.

Вступление

Сначала о главном. Это руководство не для всех. Это руководство прежде всего для:

• разработчиков, которые хотят уметь делать хорошие интерфейсы для себя, если вдруг прижмёт;
• UX-дизайнеров, которые знают, что хороший UX-дизайн продаётся лучше в красивой UI-упаковке.

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

А пока давайте я расскажу, что вы найдёте в этой статье.