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

На основании результата голосования в статье Теория Графов в Игре Престолов, я перевожу обучающий материал Эрика Германи (Erik Germani), который получил социальный граф связей из 5 первых книг серии «Песнь льда и пламени», лёгший в основу вышеупомянутой статьи. Статья не содержит подробного описания методов машинного обучения, а скорее рассказывает как на практике можно использовать существующие инструменты для поиска авторов диалогов в тексте. Осторожно, много букв! Поехали.

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

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

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

Данная статья является попыткой ответить на эти вопросы хотя бы в первом приближении.

На сегодняшний день разработчики PHP ведут работу над API уровня С. И в этом посте я буду по большей части рассказывать о внутренней разработке PHP, хотя если по ходу повествования встретится что-то интересное с точки зрения пользовательского уровня, то я буду делать отступление и объяснять.

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

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

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

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

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

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

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

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


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

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

Первое, что я заметил — множество советов как все настроить под большую нагрузку. Читайте их внимательно, обычно в тексте найдете, что речь про «высокую нагрузку» в 15-20 тысяч клиентов в сутки. У нас клиентов примерно миллион, активных, ежедневных.

У нас нет денег и мы все делаем за свой счет, поэтому экономим. Итог — весь миллион клиентов обслуживается на одном сервере, вот на таком — EX-60 на hetzner.

Здравствуйте, уважаемые читатели!

Некоторое время назад у нас вышел перевод фундаментальной орейлевской книги о фреймворке Hadoop:



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

Поэтому мы решили опубликовать перевод статьи Ананда Кришнасвами, появившейся в блоге Thoughtworks еще в 2013 году, где автор пытается проанализировать, в каких случаях уместно использовать Hadoop, а в каких — излишне.

Надеемся, что материал покажется интересным, вызовет полемику, а Вы поделитесь Вашими впечатлениями о работе с Hadoop и поучаствуете в опросе.

Вы еще не сохраняете десятки миллионов событий в день? К вам еще не забегают менеджеры с кричащим вопросом — когда твой дорогущий кластер на «надцати» машинах посчитает агрегированную статистику по продажам за неделю (а в глазах читается: «чувак, ребята на php/python/ruby/go решают задачу за час, а ты со своей Бигдатой тянешь время днями, доколе?»)? Вы еще не вскидываетесь ночью в холодном поту от кошмара: «разверзлось небо и на вас, ваших коллег и весь нафиг город вывалилось огромная куча… Бигдаты и никто не знает, что с этим всем теперь делать»? :-)

Есть еще интересный симптом — в компании скапливается много-много логов и кто-то, по фамилии, отдаленно звучащей как «Сусанин», говорит: «коллеги, а в логах на самом деле сокрыто золото, там есть информация о путях пользователей, о транзакциях, о группах, о поисковых запросах — а давайте это золото начать извлекать»? И вы превращаетесь в «извлекателя» добра из терабайт (и их десятков) информационного водопада под мотивирующие советы: «а разве нельзя в потоке получать ценную для бизнеса информацию, зачем гонять часами кластера?».

Если это не о вас, тогда и не заходите под кат, ибо там — треш и жесткий технологический трепет…

Не успели мы рассказать о новых роутерах семейства EdgeRouter, как Ubiquiti радует нас новой новинкой, на этот раз в области видеонаблюдения.
Рассмотрим новинку в линейке видеокамер — беспроводную мегапиксельную камеру, помещающуюся в кармане и не требующую прокладки Ethernet кабеля.
Забегая вперёд, скажу, что, следуя логике X линейки оборудования, новинка получилась компактнее, доступнее и при этом не хуже по параметрам, чем предшествующие модели.

Одним из самых больших нововведений в PHP 5.5 будет поддержка генераторов и корутин (сопрограмм). Генераторы уже достаточно были освещены в документации и в нескольких других постах (например в этом или в этом). Сопрограммы же получили очень мало внимания. Это гораздо более мощный, но и более сложный для понимания и объяснения, инструмент.

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

Генераторы

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

Введение

В статье хотелось бы поднять вопросы отличия использования Python для web-разработки по сравнению с оной на PHP. Надеюсь, статья не приведет к холиварам, так как она вовсе не о том, какой язык лучше или хуже, а исключительно о технических особенностях Python.

Во всех руководствах в описаниях REST дают простые примеры, типа вот вам пользователи, они будут ресурсом /users, вот вам один пользователь, он будет /users/[id] и действия с ним добавить\удалить\изменить.

А что если действия сложные или комплексные и не вписываются в GET\POST\DELETE?

«Только со смертью догмы начинается наука.»
// Галилео Галилей

«Я начал завидовать рабам. Они всё знают заранее. У них твёрдые убеждения.»
// х/ф Марка Захарова «Убить дракона» по мотивам пьесы Евгения Шварца

Уже пару лет и дня не проходит, чтобы я не услышал (или не прочитал) от людей, начинающих новые проекты, фразу типа «Возьмем серверный движок для REST API и MVC, и погнали». Сначала я думал, что у этих слов есть один источник, может книжку какую завезли во все магазины или где-то в топе поисковиков лежит статья, зомбирующая разработчиков. Если же выяснять у них, что они понимают под REST и MVC, то можно повредиться умом. Ну с MVC уже все ясно, об этом я уже давно писал, ничего не изменилось, только усугубилось, стоит набрать в Google Images «mvc» и мы увидим страшное, стрелочки в любые стороны. Ну а про REST отвечают следующее: ну как же, нам нужно из браузерного GUI и мобильного приложения вызывать серверные методы, например: setUserCity(userId, cityId) или calculateMatrix(data) или startVideoConverter(options, source, destination) а потом мы столкнемся с большой нагрузкой и архитектура REST все решит. Дальше я задаю вопросы, от которых глаза округляются уже у тех, кто недавно еще горел праведной верой, рвался в бой и точно знал, что к чему в этом мире. Теперь можно перейти к рассмотрению терминологической катастрофы, в эпицентре которой мы с вами пребываем.

После моего обзора китайской IP-видеокамеры ( habrahabr.ru/post/146344 ) у меня появилась возможность опробовать автономную IP-видеокамеру, позволяющую вести интернет-видеотрансляцию без использования компьютера.



Это ip-камера Micro Digital MDC-i4220 со специальной прошивкой, поддерживающей сервис ivideon.
Камера продаётся за 5500 рублей. Существует также модель с Wi-Fi MDC-i4220w, она стоит 7000 рублей. Это не дороже такой же камеры с обычной прошивкой.

Прежде всего расскажу о том, что позволяет делать камера и зачем это может пригодиться.

Камера настраивается буквально за пять минут, подключается к проводному интернету или в неё вставляется модем Yota (скоро обещают сделать поддержку 3G-модемов), после чего на сайте ivideon.ru или через приложения для iPad/iPhone/Android можно смотреть живое видео с камеры. Кроме того, видео можно внедрять на сайты и в блоги. Очень важно, что для работы камеры не нужен выделенный ip-адрес. Она работает везде, где есть интернет и скорость канала достаточна для передачи видео.

Я вижу два варианта использования такой камеры:

• Создание общедоступной вебкамеры
• Видеонаблюдение

1 часть. Заземление
(общая информация, термины и определения)

2 часть. Традиционные способы строительства заземляющих устройств
(описание, расчёт, монтаж)

3 часть. Современные способы строительства заземляющих устройств
(описание, расчёт, монтаж)

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

Д. Основные способы строительства

Д1. Модульное заземление (для обычных грунтов)

Д1.1. Особенности решения

Д1.1.1. Универсальность и простота применения
Д1.1.2. Долгий срок службы
Д1.1.3. Зависимость уменьшения сопротивления заземления от увеличения глубины электрода
Д1.1.4. Суперкомпактность
Д1.1.5. Никакой сварки

Д1.2. Расчёт получаемого сопротивления заземления
Д1.3. Монтаж
Д1.4. Достоинства и недостатки

Д2. Электролитическое заземление (для вечномёрзлых или каменистых грунтов)

Д2.1. Особенности решения

Д2.1.1. Простота применения в вечномёрзлых или каменистых грунтах
Д2.1.2. Компактность
Д2.1.3. Образование талика
Д2.1.4. Никакой сварки

Д2.2. Расчёт получаемого сопротивления заземления
Д2.3. Монтаж
Д2.4. Достоинства и недостатки

Д. Основные способы строительства

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

Предисловие

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

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



У меня сейчас не топовая, довольно старая конфигурация, но её производительность мне вполне подходит:
Intel Core 2 Duo E7500 2.93Ггц
8Гб DDR3 SDRAM
2Тб HDD Seagate 5900 Green
Я путём небольших вложений заставил-таки свой компьютер работать бесшумно.

Рассмотрим по отдельности все шумные узлы системного блока, такие как:

• Видеокарта. Обычно наиболее шумный элемент
• Процессор. Тоже не очень тихий узел системы
• Блок питания. Также как правило содержит вентилятор
• Прочее. Мало ли что там ещё гудит

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

Перевод третьей лекции из курса «Структура интерпретация компьютерных программ».

Это самый известный курс по программированию за последние 25 лет; с 1980г читается в MIT, а с недавних пор что-то подобное читается и в Беркли.

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

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

Приятного просмотра!

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

Вы никогда не задумывались, что такое огонь?
А если получили ответ — остались ли довольны ответом? Ведь всегда можно пойти на уровень глубже и задать еще одно «почему?»

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