Не так давно я участвовал в проекте написания прошивки для некоторого устройства. В процессе работы возник вопрос, а как, собственно, взаимодействовать с «большим братом» (управляющим компьютером)? Поскольку в качестве «большого брата» закладывались совершенно разные устройства (различные смартфоны, планшеты, ноутбуки с различными ОС и прочее), планировалось использовать web-приложение, что диктовало использование JSON для обмена сообщениями.

В итоге получилась легкая и быстрая библиотека сериализации/десериализации JSON. Основные фичи данной библиотеки:

• в базовом функционале (без использования контейнеров STL) не использует динамическую память, вообще;
  
• состоит только из заголовочных файлов (headers-only);
  
• есть поддержка контейнеров STL;
  
• позволяет создавать расширения для обработки произвольных типов.
  

Я больше 15 лет при программировании использую логику Хоара и нахожу этот подход очень полезным и хочу поделится опытом. Естественно не надо «стрелять из пушки по воробьям», но при написании достаточно сложных алгоритмов или нетривиальных кусков кода применение логики Хоара сэкономит Ваше время и позволит внести элементы некоторого «промышленного» стандарта при программировании.

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

Аннотация

1. Есть страдание.
2. Есть причина страдания.
3. Есть прекращение страдания.
4. Есть путь, ведущий к избавлению от страданий.

4 благородные истины буддизма

Настоящая статья содержит описание раннего прототипа, который вводит понятие реплицируемого объекта (replicated object) или сокращённо replob. Такой объект является дальнейшим переосмыслением борьбы со сложностью кода, возникающего при программировании распределённых систем. Replob устраняет зависимость от стороннего сервиса и реализует согласованное изменение любых пользовательских объектов, представляющих соответствующие данные и функциональность. Эта идея основана на использовании выразительности языка C++ и объектно-ориентированного подхода, что позволяет использовать сложную логику внутри распределённых транзакций. Это позволяет значительно упростить разработку отказоустойчивых приложений и сервисов. Последующие статьи будут более детально объяснять развиваемый подход.

Введение

ПРЕДУПРЕЖДЕНИЕ. Почти все методы, указанные в статье, содержат грязные хаки памяти и ненормальное использование языка C++. Так что, если вы не толерантны к таким извращениям, пожалуйста, не читайте эту статью.

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

Введение

Apache и Nginx — 2 самых широко распространенных веб-сервера с открытым исходным кодом в мире. Вместе они обслуживают более 50% трафика во всем интернете. Оба решения способны работать с разнообразными рабочими нагрузками и взаимодействовать с другими приложениями для реализации полного веб-стека.

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

Если вы регулярно используете Git, то вам могут быть полезны практические советы из этой статьи. Если вы в этом пока новичок, то для начала вам лучше ознакомиться с Git Cheat Sheet. Скажем так, данная статья предназначена для тех, у кого есть опыт использования Git от трёх месяцев. Осторожно: траффик, большие картинки!

Содержание:

1. Параметры для удобного просмотра лога
2. Вывод актуальных изменений в файл
3. Просмотр изменений в определённых строках файла
4. Просмотр ещё не влитых в родительскую ветку изменений
5. Извлечение файла из другой ветки
6. Пара слов о ребейзе
7. Сохранение структуры ветки после локального мержа
8. Исправление последнего коммита вместо создания нового
9. Три состояния в Git и переключение между ними
10. Мягкая отмена коммитов
11. Просмотр диффов для всего проекта (а не по одному файлу за раз) с помощью сторонних инструментов
12. Игнорирование пробелов
13. Добавление определённых изменений из файла
14. Поиск и удаление старых веток
15. Откладывание изменений определённых файлов
16. Хорошие примечания к коммиту
17. Автодополнения команд Git
18. Создание алиасов для часто используемых команд
19. Быстрый поиск плохого коммита

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

В общем случае решение задачи слежения содержит три основных этапа:
– выделение сегментов;
– установление соответствия между выделенными сегментами и отслеживаемыми объектами;
– уточнение или прогнозирование положения объектов интереса.

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

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

Предисловие от автора оригинала:

В марте 2011 я написал черновик статьи про то, как команда, отвечающая за Google Chrome, разрабатывает и выпускает свой продукт — после чего я благополучно о нем забыл. Лишь несколько дней назад я случайно наткнулся на него. Пусть местами он уже устарел (Chrome форкнул WebKit в Blink в 2013 году, да и я сам больше не работаю в Google), я склонен считать, что изложенные в нем идеи все еще в силе.

Сегодня я собираюсь рассказать вам о том, как работает Chromium. Нет, речь пойдет не совсем о браузере Chrome, а скорее о Chromium — группе людей, занимающихся созданием браузера.

Над проектом Chromium работают сотни инженеров. Вместе мы коммитим в кодовую базу примерно 800 изменений каждую неделю. Мы также зависим от многих других больших и активно развивающихся проектов вроде V8, Skia и WebKit.

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

Каким образом все это продолжает работать? Почему «колеса» у этого «автобуса» еще не «отвалились»? Почему еще не все разработчики сошли с ума?

Привет, Хабр! Этой статьёй я открываю цикл материалов, посвящённых работе с большими данными. Зачем? Хочется сохранить накопленный опыт, свой и команды, так скажем, в энциклопедическом формате – наверняка кому-то он будет полезен.

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

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

Третьего дня, во время сортировки старых закладок, попалась мне на глаза блок-схема с алгоритмом выбора STL-контейнера. «Почему же для контейнеров есть, а для стандартных алгоритмов нет? — подумал я. — Это необходимо исправить». Подумано — сделано. Сперва планировалось за пару часов нарисовать нечто простенькое, но в дальнейшем обнаружилось, что алгоритмы никак не хотят умещаться в простенькую схему. Я слегка увлекся, и спустя два вечера схема вобрала в себя 84 алгоритма, а также немного дополнительной информации. Под катом можно увидеть, что получилось в итоге.

Всем привет! Меня зовут Андрей, я работаю в отделе разработки продуктов Veeam Software.

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



Сегодня я хочу рассказать свою историю.

Итак, начну с момента, когда мне исполнился 21 год, я уволился из рядов доблестной российской армии и оказался на серых и холодных улицах Санкт-Петербурга. Осень, отсутствие жилья и денег активировали все клетки головного мозга для ответа на вопрос: «Что делать?».

Под катом — краткое описание доклада про аспектно-ориентированное программирование и применение AspectJ-scripting, а также ссылки на материалы по теме и видеозапись выступления.

Вокруг постоянно говорят про Docker. Я знаю что вы отвечаете: «Это что-то про контейнеры, виртуализацию, облака», «У нас все и так работает», «Это все баловство», «Он не запустится на нашем старом ядре линукса», «Точно так же можно подготовить образ для облака и запустить его», «Можно просто настроить LXC, chroot или AppArmor». Вы знаете, что он вам не нужен. Очередная модная штука. В конце концов, просто лень разбираться. Но любопытно! Тогда, читайте. Это серия из шести заметок.

Если вы не слышали о контейнерах в Линуксе, вот список страниц, которые надо прочитать, чтобы понимать о чем речь:

• en.wikipedia.org/wiki/LXC
• en.wikipedia.org/wiki/UnionFS
• habrahabr.ru/post/253877
• www.docker.com/whatisdocker

Поставьте Docker, он небольшой. Для Windows и Mac можно просто поставить Toolbox: www.docker.com/toolbox. Создавать виртуальную машину и настраивать лучше из командной строки, а не через графическую обертку. Прочитайте несколько уроков из мануала. Здесь я пишу о том, чего в документации нет.

Docker — это не виртуализация.

Вот какой у меня линукс:

Welcome to Ubuntu 15.04 (GNU/Linux 3.19.0-15-generic x86_64)

Last login: Tue Aug 18 00:43:50 2015 from 192.168.48.1
gri@ubuntu:~$ uname -a
Linux ubuntu 3.19.0-15-generic #15-Ubuntu SMP Thu Apr 16 23:32:37 UTC 2015 x86_64 x86_64 x86_64 GNU/                                       Linux
gri@ubuntu:~$ free -h
             total       used       free     shared    buffers     cached
Mem:          976M       866M       109M        11M       110M       514M
-/+ buffers/cache:       241M       735M
Swap:         1.0G       1.0M       1.0G

Запускаю CentOS:

gri@ubuntu:~$ docker run -ti centos
[root@301fc721eeb9 /]# uname -a
Linux 301fc721eeb9 3.19.0-15-generic #15-Ubuntu SMP Thu Apr 16 23:32:37 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
[root@301fc721eeb9 /]# cat /etc/redhat-release
CentOS Linux release 7.1.1503 (Core)
[root@301fc721eeb9 /]# free -h
              total        used        free      shared  buff/cache   available
Mem:           976M         85M        100M         12M        790M        677M
Swap:          1.0G        1.0M        1.0G

Docker — это не chroot, их функционал частично совпадает. Это не система безопасности вроде AppArmor. Docker использует те же контейнеры, что и LXC, но интересен он не контейнерами. Docker — это ничего из того, что я думал о нем до того, как прочитал документацию.

То же ядро, память, файловая система, а дистрибутивы, библиотеки и пользователи — разные.

Docker — это инструмент объекто-ориентированного проектирования

Регулярно возникает вопрос, является ли конфигурация nginx частью веб-приложения. Системные администраторы спорят с разработчиками. Но недавно в мире появились devops и захотели вместо последовательно-процедурного вызова команд из bash думать привычным OOP. Docker дает инкапсуляцию, наследование и полиморфизм компонентам системы, таким как база данных и данные. Это значит, что можно провести декомпозицию всей информационной системы, выделить приложение, web-сервер, базу данных, системные библиотеки, рабочие данные в независимые компоненты, внедрять зависимости из конфигов, и заставить все это работать одной группой, одинаково на разных компьютерах.

Такой подход можно использовать, чтобы снизить потери рабочего времени дорогих front-end разработчиков на настройку базы данных и Nginx. Чтобы уйти от vendor lock-in. Не обломаться когда openssl на сервере не поддерживает cipher, используемый в API госучреждения. Чтобы приложение работало независимо от версии PHP или Python на сервере заказчика. Создавать open source не только в виде кода, но и настройкой пакетов из нескольких приложений, написанных на разных языках, работающих на разных слоях OSI.

Вопреки названию и первому впечатлению, которое возникает у большинства обывателей — «Big Data» не является просто «большими данными» и даже не объединяет под собой все массивы с неограниченными (или постоянно обновляющимися и расширяющимися) данными.

На самом деле «Big Data» — это в первую очередь подходы, инструменты и методы обработки непосредственно данных. Которые, в свою очередь, чаще всего не структурированы, многообразны и разнородны.

И, что наиболее важно, «Big Data» — это новая секция 2015 года в рамках программы HighLoad++, впервые предложенная, к слову, именно на встрече докладчиков. Первые, единичные, доклады, появились еще в прошлых годах:

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

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



В качестве классического примера приводим перевод недавнего материала от подразделения IBM Watson:

Публикуем статью Павла Дубова, студента ФИВТ МФТИ, преподавателя курса Алгоритмы. Олимпиадное программирование в 1С: Клубе программистов и тренера нашей олимпиадной сборной.



Рано или поздно перед любым школьником, планирующим поступать в приличный вуз на IT-специальность, встаёт вопрос: как и к чему готовиться? Безусловно, самый банальный ответ — готовиться к ЕГЭ, доводя самоконтроль до исступлённого автоматизма, чтобы избегать ошибок в ответственные моменты. Но есть и другой путь, позволяющий не только дать себе дополнительные шансы, но и приобрести навыки, необходимые для устройства на работу в хорошие компании.

Это путь изучения алгоритмического программирования. Помимо всего вышеперечисленного, это очень увлекательно и забавно.

На данный момент существует несколько уровней олимпиад по информатике. На самом «высоком» уровне находится Всероссийская олимпиада школьников. Получение диплома на этой олимпиаде гарантирует участнику поступление в любой вуз по соответствующему профилю без экзаменов. Олимпиады других уровней в зависимости от вуза могут давать либо поступление без экзаменов, либо 100 баллов на ЕГЭ по информатике. Для таких льгот требуется набрать минимальный балл на самом ЕГЭ — обычно 65 баллов, что, в общем, при условии получения диплома труда не составляет. Распределение олимпиад по уровням каждый год публикует Минобрнауки в интернете. Так как олимпиад несколько, можно попытать успеха несколько раз и таким образом упростить себе задачу.

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

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

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



Лекция был прочитана в Малой Школе анализа данных, которую Яндекс организует для старшеклассников. Автор — Александр Шень. Окончил мехмат МГУ, под руководством Владимира Успенского, ученика Колмогорова, защитил диссертацию «Алгоритмические варианты понятия энтропии». Сейчас является сотрудником Института проблем передачи информации им. А.А. Харкевича РАН и Лаборатории Национального центра научных исследований Франции. Научные интересы: алгоритмы, колмогоровская сложность, логика, теория информации. Почти все книги, которые Александр Ханиевич написал о математике и программированию, находятся в свободном доступе.

Под катом — расшифровка лекции.

Привет, хабр!



Как и обещал, продолжаю публикацию статей, в которой описываю свой опыт после прохождения обучения по Data Science от ребят из MLClass.ru (кстати, кто еще не успел — рекомендую зарегистрироваться). В этот раз мы на примере задачи Digit Recognizer изучим влияние размера обучающей выборки на качество алгоритма машинного обучения. Это один из самых первых и основных вопросов, которые возникают при построении предиктивной модели

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