Как уже отмечалось много раз, за последнее время рынок видео-конференц-связи (ВКС) стремительно смещается в сторону программных решений. В статьях о подобных реализациях (Mind и Yealink) я подробно описал функционал, настройку и стоимость решения, но вопросу оборудования для ВКС было уделено незначительное внимание. Это не справедливо — каким бы ни был удобным и качественным сервис ВКС, при неудачно подобранном оборудовании для персональных рабочих мест или переговорных комнат, Вы не сможете оценить все достоинства программного решения.

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

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

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

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

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

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

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

Для тестового примера я создам небольшое приложение, которое рисует множество «целей» (кругов) на элементе canvas. Я буду использовать redux как хранилище данных, но эти советы подойдут и для многих других способов хранения состояния.
Так же эти оптимизации можно применять с react-redux, но для простоты описания я не буду использовать эту библиотеку.

Данные советы могут повысить производительность приложения в 20 раз.

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

Ник Бабич разработчик, теч энтузиаст и просто влюбленный в UX/UI специалист написал заметку в блоге UX Planet про бесконечную прокрутку, мы сделали адаптивный перевод материала специально для читателей Хабрахабр.



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

Аудиомания на м. Электрозаводская

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

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

В теории все эти рассказы звучат очень заманчиво – кажется, что для создания интернет-магазина нужно одно лишь большое желание и голова на плечах. На практике «долину смерти» преодолевает далеко не каждый e-commerce проект – даже если к его созданию основатели подходят со всей серьезностью, не боятся рисковать и готовы буквально жить на работе.
 
Мы в Аудиомании не только развили собственный электронный бизнес, но и за все время его существования пообщались и стали свидетелями большого количества взлетов и падений в e-commerce. И готовы рассказать о том, как делать не надо: в этом материале мы решили собрать наиболее часто встречающиеся ошибки, которые могут дорого стоить вашему онлайн-проекту еще на старте.

Надо начать, а там – как пойдет

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

До конференции PG Day'16 Russia остались считанные дни, расписание можно посмотреть на нашем сайте. Мы трудимся в поте лица, но тем не менее успеваем готовить для вас переводы самых интересных материалов о PostgreSQL. Сегодня представляем вашему вниманию перевод статьи Pat Shaughnessy о поведении запроса Select.

Готовясь летом к этой презентации, я решил изучить некоторые части исходного кода PostgreSQL на C. Я запустил очень простой запрос select и наблюдал, что Постгрес с ним делает, с помощью LLDB, отладчика C. Как Постгрес понял мой запрос? Как он нашел данные, которые я искал?



Этот пост — неформальный журнал моего путешествия через внутренности PostgreSQL. Я опишу пройденный мной путь и то, что я видел в процессе. Я использую серию простых концептуальных диаграмм, чтобы объяснить, как Постгрес выполнил мой запрос. В случае, если вы понимаете C, я также оставлю вам несколько ориентиров и указателей, которые вы можете поискать, если вдруг решите покопаться во внутренностях Постгреса.

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

Это история о том как создавался сайт интернет-магазина Сотмаркет и менялась работа с каналами привлечения трафика по мере роста компании.

Наверно, в мире данных нет подобного феномена настолько неоднозначного понимания того, что же такое Hadoop. Ни один подобный продукт не окутан таким большим количеством мифов, легенд, а главное непонимания со стороны пользователей. Не менее загадочным и противоречивым является термин "Big Data", который иногда хочется писать желтым шрифтом(спасибо маркетологам), а произносить с особым пафосом. Об этих двух понятиях — Hadoop и Big Data я бы хотел поделиться с сообществом, а возможно и развести небольшой холивар.
Возможно статья кого-то обидит, кого-то улыбнет, но я надеюсь, что не оставит никого равнодушным.

Демонстрация Hadoop пользователям

Предыстория: кто мы и как дошли до жизни такой

Мы — команда проекта JavaRush. А JavaRush, кто еще не в курсе, — это полностью автоматизированный обучающий онлайн-курс по Java. Когда-то давно, именно благодаря поддержке хаброюзеров и статьям на хабре, JavaRush и появился. В то время мы собирались переучить на программистов миллион человек.

Перевод поста Стивена Вольфрама "What Is Spacetime, Really?".
Выражаю огромную благодарность Кириллу Гузенко KirillGuzenko за помощь в переводе и подготовке публикации.

Примечание: данный пост Стивена Вольфрама неразрывно связан с теорией клеточных автоматов и других смежных понятий, а также с его книгой A New Kind of Science (Новый вид науки), на которую из этой статьи идёт большое количество ссылок. Пост хорошо иллюстрирует применение программирования в научной сфере, в частности, Стивен показывает (код приводится в книге) множество примеров программирования на языке Wolfram Language в области физики, математики, теории вычислимости, дискретных систем и др.

---

Содержание

Простая теория всего?
Структура данных Вселенной
Пространство как граф
Может быть, нет ничего, кроме пространства
Что есть время?
Формирование сети
Вывод СТО
Вывод ОТО (Общей теории относительности)
Частицы, квантовая механика и прочее
В поисках вселенной
Ок, покажите мне Вселенную
Заниматься физикой или нет — вот в чем вопрос
Что требуется?
Но пришло ли время?

---

Сто лет назад Альберт Эйнштейн опубликовал общую теорию относительности — блестящую, элегантную теорию, которая пережила целый век и открыла единственный успешный путь к описанию пространства-времени (пространственно-временного континуума).

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

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

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

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

Во-первых, такой подход казался не слишком перспективным — хотя бы потому, что модели, которые я изучал (клеточные автоматы), казалось, работали так, что это полностью противоречило всему тому, что я знал из физики. Но где-то в 88-м году — в то время, когда вышла первая версия Mathematica, я начал понимать, что если бы я изменил свои представления о пространстве и времени, возможно, это к чему то бы меня привело.

D3.js (или просто D3) — это JavaScript-библиотека для обработки и визуализации данных с невероятно огромными возможностями. Я, когда впервые узнал про нее, наверное, потратил не менее двух часов, просто просматривая примеры визуализации данных, созданных на D3. И конечно, когда мне самому понадобилось строить графики для небольшого внутреннего сайта на нашем предприятии, первым делом вспомнил про D3 и с мыслью, что “сейчас я всех удивлю крутейшей визуализацией”, взялся изучать исходники примеров…

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

Если вы никогда не слышали про Алана Кэя, то как минимум слышали его знаменитые цитаты. Например, это высказывание 1971 года:

The best way to predict the future is to invent it.
Лучший способ предсказать будущее это изобрести его.

У Алана очень яркая карьера в информатике. Он получил Премию Киото и Премию Тьюринга за работу над парадигмой объектно-ориентированного программирования. Он был одним из первопроходцев в области персональных компьютеров и графического интерфейса, он разработал Smalltalk — один из первых самых влиятельных языков программирования всех времен.

У нас в Хекслете, особенно в чате, постоянно поднимается вопрос «что такое ООП» и «что имел ввиду Алан Кэй на самом деле». В этой заметке собраны интересные цитаты Алана о состоянии современной разработки, ООП и языке Лисп.

Введение

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

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

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

Итак — эти 7 правил:

1. Скука убивает
2. Прежде чем начать, выясните точно для себя, какие действия вы ожидаете от читателя, осилившего ваш труд
3. Пишите в соответствии с правильно сформированной структурой
4. Избегайте неоднозначных местоимений
5. Ясность = иллюстрации + слова
6. Когда имеете дело с понятиями, концепциями и т.п., используйте логическую иллюстрацию и пример
7. Не опасайтесь переделок

Здравствуйте, Хабр!

В ближайшее время читайте пост о русском переводе долгожданной книги "Создание Микросервисов" Сэма Ньюмена, которая уже отправилась в магазины. Пока же мы предлагаем почитать перевод статьи Аруна Гупты, автор которой описывает самые интересные паттерны проектирования, применимые в микросервисной архитектуре

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

Вам будет интересно почитать, если вы:

• Не довольны своим таск-менеджером, так как он очень сложный/неудобный
• Работаете с небольшой командой
• Часто взаимодействуете с коллегами через месенджеры, и вам хотелось бы иметь таск-менеджер под рукой
• Хотели бы начать знакомство с простым и понятным таск-менеджером

Решение распространяется под лицензией GNU GPL, ссылка на репозиторий будет в конце статьи.

Предисловие

В прошлом году решил для себя вплотную познакомиться c Python, а в последствии перебраться на него с PHP. На данный момент моя стезя — веб-разработка, а потому осваивать новый язык я начал именно со стороны веба, в частности, с обзора доступных фреймворков и проектов на них. Познакомившись с возможностями TurboGears, web2py, Django, я всё таки поддался «тренду» и погрузился в мир Django.

На протяжении почти года я честно пытался подружиться с ним. Написал несколько простеньких проектов, но монструозность фреймворка отпугивала, обилие «батареек» путало выбор, а с некоторыми ограничениями не хотелось мириться. Душа требовала лаконичности и однозначности, что в конечном счете привело меня к знакомству с Flask. Изучив документацию по фреймворку и смежным проектам (Jinja2, Werkzeug), я проникся идеологией и стал вплотную изучать фреймворк.

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

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

В последние годы REST (REpresentational State Transfer) стала стандартной архитектурой при дизайне веб-сервисов и веб-API.

В этой статье я покажу вам как просто создавать RESTful веб-сервисы используя Python и микрофреймворк Flask.

Что такое REST?

Характеристика системы REST определяется шестью правилами дизайна:

• Клиент-Сервер: Должно быть разделение между сервером, который предлагает сервис и клиентом, который использует ее.
• Stateless: Каждый запрос от клиента должен содержать всю информацию, необходимую серверу для выполнения запроса. Другими словами, сервер не обязан сохранять информацию о состоянии клиента.
• Кэширование: В каждом запросе клиента должно явно содержаться указание о возможности кэширования ответа и получения ответа из существующего кэша.
• Уровневая система: Клиент может взаимодействовать не напрямую с сервером, а с произвольным количеством промежуточных узлов. При этом клиент может не знать о существовании промежуточных узлов, за исключением случаев передачи конфиденциальной информации.
• Унификация: Унифицированный программный интерфейс сервера.
• Код по запросу: Сервера могут поставлять исполняемый код или скрипты для выполнения их на стороне клиентов.