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

Всем привет. Ниже представлена расшифровка доклада с Big Monitoring Meetup 4.

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

В докладе будет сравнение Thanos и VictoriaMetrics — проектов для долгосрочного хранения метрик Prometheus.

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

Дело в том, что ИТ-сфера одновременно бурно развивается (все еще) и в то же время полна множества устоявшихся стереотипов.

Современный backend разнообразен, но всё-таки подчиняется некоторым негласным правилам. Многие из нас, кто разрабатывает серверные приложения, сталкивается с общепринятыми подходами, такими как Clean Architecture, SOLID, Persistence Ignorance, Dependency Injection и прочими. Многие из атрибутов серверной разработки настолько заезжены, что не вызывают никаких вопросов и используются бездумно. О некоторых много говорят, но никогда не используют. Смысл остальных же либо неправильно интерпретирован, либо перевран. Статья рассказывает о том, как построить простую, совершенно типичную, архитектуру backend, которая не только может без какого-либо ущерба следовать заветам известных теоретиков программирования, но и в некоторой степени может их усовершенствовать.

Эта статья о том, как однажды мы решили немного улучшить внутренний инструмент SelfTester, применяемый для проверки качества работы анализатора PVS-Studio. Улучшение было несложным и выглядело полезным, но создало нам много проблем, и впоследствии выяснилось, что лучше бы мы его не делали.

Service Mesh — известный архитектурный паттерн для интеграции микросервисов и перехода на облачную инфраструктуру. Сегодня в облачно-контейнерном мире обойтись без него довольно сложно. На рынке уже доступны несколько open-source реализаций service mesh, но их функциональности, надежности и безопасности далеко не всегда достаточно, особенно когда речь идет о требованиях больших финансовых компаний масштаба всей страны. Поэтому мы в Сбертехе решили кастомизировать Service Mesh и хотим рассказать о том, что в Service Mesh круто, что не очень и что мы с этим собираемся сделать.

Жил был моряк. У него было две любимых женщины в разных портах, и он хотел детей – вот только не решил, одного или двух. Он решил кинуть монету. Орел – будет один ребенок от одной из женщин (к которой первой зайдет в порт по работе – это уж как получится), решка – сделает по ребенку каждой женщине. Неизвестно, как выпала монета, и как его бросала судьба по миру, но вы – его ребенок. Какова вероятность, что вы – его единственный ребенок?

Всем привет!

В преддверии Нового года мы решили порадовать вас еще одним релизом YouTrack.

В этом посте я расскажу, какие улучшения вошли в YouTrack 2018.4.

Облачное хранилище позволяет не только хранить данные, но и обеспечивать совместную работу с ними в NAS.

Простое объяснение простоты

КДПВ с областями, которые нам придется посетить, чтобы ответить на ГЛАВНЫЙ вопрос.

Предисловие

Я часто слышал совет: сделай проще.

А что значит простой? Когда мы говорим, что объект X — простой, каковы наши ожидания от X? Когда мы говорим, что какая-то вещь проще чем другая — как мы это оцениваем?

Что проще:
“Небольшое предложение из пяти слов” или слово “Дезоксирибонуклеиновый”?
“6*5” или “481”?

Или так:
У вас есть экран настроек. Пять пунктов из них относятся к графике, другие пять к уведомлениям. Надо ли вам создавать отдельные пункты «графика» и «уведомления» в основном меню? Или оставить все 10 пунктов на одном экране? Что будет проще для пользователя?

Перевод поста пользователя Reddit

За последний год я провёл более 50 телефонных собеседований, и наблюдал, как люди делали одни и те же ошибки снова и снова. В интернете можно найти много советов по поводу навыков, полезных для прохождения интервью, но я не видел текстов, где бы описывались стратегии, помогающие людям преуспеть. Я думаю, что у большей части наших кандидатов, дошедших до интервью, есть необходимые навыки, однако они просто нервничают и не применяют эти навыки эффективно. Чтобы был ясен контекст, наша фирма – это стартап на 100 человек, а до второго раунда интервью доходят порядка 50% людей.

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

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

Но с такими возможностями часто приходит полное отсутствие уважения к участникам проекта других профессий. Это отсутствие уважения может оказаться настолько глубоким, что порождает в уме разработчика твёрдую уверенность, что он не только самый ценный участник программного проекта, но и необходим компании в целом. К сожалению, хотя лишь малое число разработчиков способны накапливать что-либо напоминающее богатство, многие ведут себя так, словно они следующие Марк Цукерберг, Билл Гейтс или Стив Джобс; хотя это очень далеко от истины. Это приводит к личностным проблемам, которые так же увлекательно наблюдать со стороны, как страшно созерцать в себе.

Массачусетский Технологический институт. Курс лекций #6.858. «Безопасность компьютерных систем». Николай Зельдович, Джеймс Микенс. 2014 год

Computer Systems Security — это курс о разработке и внедрении защищенных компьютерных систем. Лекции охватывают модели угроз, атаки, которые ставят под угрозу безопасность, и методы обеспечения безопасности на основе последних научных работ. Темы включают в себя безопасность операционной системы (ОС), возможности, управление потоками информации, языковую безопасность, сетевые протоколы, аппаратную защиту и безопасность в веб-приложениях.

Лекция 1: «Вступление: модели угроз» Часть 1 / Часть 2 / Часть 3

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


Константы формы, созданные на компьютере. Два верхних изображения имитируют воронку и спираль, возникающие после приёма LSD. Нижнее левое – соты, создаваемые марихуаной. Нижнее правое – паутина.

Перевод A Complete Machine Learning Project Walk-Through in Python: Part One.

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

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

Обнаружение аномалий — одна из важнейших функций для решений в области «интернета вещей» (IoT), которые собирают и анализируют временные изменения в потоке данных от различных датчиков. Во многих случаях поток данных со временем не претерпевает значительных изменений. Однако если они появляются, это чаще всего означает, что в системе возникла аномалия, способная нарушить её работу. В этой статье я расскажу, как использовать модуль Time Series Anomaly Detection сервиса машинного обучения Azure Machine Learning для определения аномальных показателей датчиков.

На geektimes есть хабы «Читальный зал» (про литературу для гиков), «Научная фантастика» (про научную фантастику), «Киберпанк» (про киберпанк). Как-то так повелось, что в эти хабы всякие деятели стали публиковать свои рассказы. Причём, это не только небольшие зарисовки, для лёгкого пятничного чтения, но и этакие «мыльные оперы»: в реальном времени можно следить, как авторы пишут главы рассказов, можно сказать, «Special for GT».

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



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

Описание процессов машинного перевода основанного на базе правил (Rule-Based), машинного перевода на базе фраз (Phrase-Based) и нейронного перевода

В этой публикации нашего цикла step-by-step статей мы объясним, как работает нейронный машинный перевод и сравним его с другими методами: технологией перевода на базе правил и технологией фреймового перевода (PBMT, наиболее популярным подмножеством которого является статистический машинный перевод — SMT).

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

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

«Ну что, без драки? Волейбол — так волейбол!»
Ну что же, USB — так USB

Не в моих правилах баловать читателя КДПВ, но не мог удержаться.

Но начнем мы, как и было обещано, со службы времени в МК. Рассмотрим связанную с этой службой задачу — имеется набор чисел и среди них следует выделить те, которые не превосходят некоторое другое наперед заданное число. А переходя к времени, можно сказать, что нам нужно будет определить момент, когда наше текущее время (Т) станет на величину интервала (И) больше, чем начало отсчета интервала (С).

Как мы можем решить эту задачу, и причем тут Уроборос?

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

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

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

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