(под рифму из хоровода)

Привет, Хабр! Кто-то ещё может помнить меня по обзорам, которые я публиковал тут задолго до Вилсакомов. Перейдя в Хабр, я перестал этим заниматься, так как посчитал это не очень правильным — писать публикации про продукты в обычные хабы, в то время как компаниям для этого требуется заводить блог. Но мало кто знает, что желание писать про интересные девайсы у меня никуда не делось, просто я стал это делать реже (пару раз в год) и в другом месте (у себя в блоге).



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

В развитие дискуссии «Проблемы научных публикаций».

Основные функции научных журналов – выбор наиболее интересных статей, установление отсутствия ошибок в них и издание.
Редакции отбирают статьи. Их интересы совпадают с интересами издателей не совсем и ещё меньше с интересами науки. Даже в своих интересах, редакторы часто принимают ошибочные решения в силу их сложности.
Рецензенты выявляют ошибки в статьях. Они тоже часто ошибаются. Уже хотя бы потому, что большую часть рецензий пишут молодые учёные и аспиранты.

Сегодня, техническое распространение носителей информации, т.е. издание, происходит в Интернете почти бесплатно.

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

Иллюстрация киберздоровья

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

На примере интервью Данила Ишутина, взятого у него Яной Химченко на чемпионате мира по DOTA2 (The International) в 2015-ом году, рассмотрим характерную картину его общего физического состояния, а также один любопытный психологический нюанс, из этого состояния вытекающий.

Выраженный синдром Марфана, как правило, подразумевает гипермобильность суставов, что делает гражданина Ишутина ценнейшей иллюстрацией интересующих нас эффектов, т.к. деформация опорно-двигательного аппарата, вызванная длительным сидением за компьютером, проявляется при дисплазии соединительной ткани гораздо полнее и быстрее.
Цитаты взяты из работы «Физические нагрузки современного человека» НАУКА (1982), В.П.Загрядский, З.К.Сулимо-Самуйлло. Книга рекомендуется к ознакомлению всем работникам операторского профиля.

Введение

Эта статья является компиляцией другой статьи. В ней я намерен сконцентрироваться на инструментах для работы с Big data, ориентированных на анализ данных.

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

Существует множество инструментов, используемых для работы с данными, каждый из которых имеет свои преимущества и недостатки. Большинство из них ориентировано на OLAP, но некоторые также оптимизированы для OLTP. Часть из них использует стандартные форматы и сосредоточена только на выполнении запросов, другие используют свой собственный формат или хранилище для передачи обработанных данных в источник в целях повышения производительности. Некоторые из них оптимизированы для хранения данных с использованием определенных схем, например «звезда» или «снежинка», но есть и более гибкие. Подводя итог, имеем следующие противопоставления:

• Хранилище данных против Озера
• Hadoop против Автономного хранилища
• OLAP против OLTP
• Движок запросов против OLAP механизмов

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

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

В ноябре 2011 года проектная организация мостов Луисвилля и Южной Индианы через реку Огайо опубликовала документ на 595 страниц, который должен был поставить финальную точку в споре по поводу шоссе, длившемся несколько десятилетий. Проект, мягко говоря, оказался противоречивым.

В то время, как множество городов по всем США пытались понять, нужны ли им городские шоссе в деловых районах, Луисвилл принялся за их строительство с удвоенной силой. Он не только хотел оставить печально известную «спагетти-развязку» им. Кеннеди, где узлом завязываются шоссе 64, 65 и 71 – он хотел её надстроить. Политический альянс, продвигающий этот проект, пытался расширить шоссе I-64, чтобы удвоить количество полос, а также построить новый мост недалеко оттуда, вниз по течению. Это удвоило бы количество полос пересекающих реку, с 6 до 12, «всего» за $2,5 млрд.

^{Нью-Йорк во всей красе}

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

От автора: Бытует мнение, что английский очень легкий язык, а американский английский и подавно. Но это миф. В статье я покажу, почему это не так, рассказав свою историю изучения американского английского во время поездок по США. Кроме того, расскажу об акцентах/диалектах отдельных штатов. С ними можно познакомиться в ряде фильмов — под катом несколько примеров. В целом, если вы изучаете английский, эта статья лишней не будет. На роль образовательного материала она не претендует, но для общего развития вполне годится.

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

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

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

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

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

Наблюдая за работой десятков разных IT-компаний из разных сегментов я с уверенностью заявляю: так называемое «делегирование полномочий» в 90% случаев — фикция и способ самоутверждения менеджера. Потому что делегирование, это двунаправленный процесс, в котором должен быть не только сильный исполнитель (что очевидно), но и умный, со стальными нервами руководитель. И сейчас объясню, почему.

Возможно, ваша компания захочет перейти на архитектуру микросервисов и автоматизировать рабочие процессы (в этом посте блога я не вдаюсь в мотивацию, но вы, возможно, захотите прочитать о 5 Workflow Automation Use Cases You Might Not Have Considered или BizDevOps — the true value proposition of workflow engines). Это ставит вас в ряд со многими нашими клиентами. Как правило, у вас возникнут вопросы:

• Область применения и границы — какой рабочий процесс вы хотите автоматизировать и как он ложится на несколько микроуслуг, или разраниченный контекст в вашем ландшафте. Я ограничен объемом этого поста, поэтому я не затрону эту тему сегодня, но вы, возможно, захотите прочитать Avoiding the «BPM monolith» when using bounded contexts или Real-Life BPMN.
• Стек и инструменты — какой движок процессов я могу использовать?
• Архитектура — я запускаю движок процесса централизованно или децентрализованно?
• Управление — кто владельцы модели рабочего процесса и как ее развертывать?
• Операции — как мне сохранить контроль?

Фреймворк Spring Integration умеет отдавать текущее состояние всех EIP-компонентов и их связей в виде JSON-графа. Это кажется очень удобным для изучения и отладки, но увы, ни один из нагугливаемых инструментов (коих всего-то раз /два) не даёт достаточной гибкости для визуализации и анализа такого графа. В этой статье я покажу, как решить эту проблему путем импорта графа в графовую СУБД Neo4j, где такая гибкость стоит на первом месте.

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

Источник