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

Диагностика

В России и бывших республиках СССР широко используется термин «онкологическая настороженность», впервые введенный в 1948 году Савицким А.И., но современное его определение относится уже к 1979 году, и введен он был Петерсоном Б.Е. как «онкологическая грамотность». Он включает в себя 5 пунктов:

1. Знание клинических симптомов злокачественных опухолей на ранних стадиях.
2. Знание предраковых заболеваний и принципов их диагностики и лечения.
3. Тщательное обследование.
4. Исключение необоснованноо оптимизма — наоборот, врач обязан думать о возможности атипичного течения заболевания.
5. Знание принципов организации онкологической помощи и направление больного с обнаруженной или подозреваемой опухолью в специализированные онкологические учреждения.

Есть у нас одно .NET-приложение, которое умеет загружать и использовать плагины. Плагины — дело хорошее. Можно функционал расширять, можно оперативненько обновлять их со своего сайта, можно даже юзерам дать SDK и позволить писать свои плагины. Мы всё это и делали. Наши плагины представляли собой обычные .NET-сборки, которые нужно было подкинуть в определённую папку, откуда основное приложения их загружало и использовало. Ну, вы, наверное представляете как — Assembly.Load(), дальше ищем класс, реализующий необходимый интерфейс, создаём объект этого класса и т.д. Всё это работало давно, стабильно и ничто не предвещало беды. Но вдруг в какой-то момент появилась необходимость создать плагин, состоящий из нескольких файлов. В связи с этим было решено считать плагином не просто .NET-сборку (1 файл), а zip-архив, в котором может быть как одна сборка, так и несколько файлов. В связи с этим пришлось научить билд-сервер паковать плагины в архивы, а основное приложение — разархивировать их в нужное место. В общем-то задача на 10 строк кода. Ничто не предвещало беды. И вот скачиваю я с билд-сервера собранный архив с плагином, разархивирую его в нужную папку, запускаю приложение, и… не работает! Стоп, как не работает? Это ведь тот же плагин!

Дальше — больше. Прошу проделать ту же самую процедуру моего коллегу, на его компьютере. Он пробует — и у него всё работает! Но как же так? Одна версия приложения, один и тот же файл с билд-сервера. Какая-то разница в окружении? Сажусь за компьютер коллеги, пробую ещё раз — не работает! Он в этом время пробует на моём — работает! То есть получается, что файл «помнит», кто его разархивировал! Зовём третьего коллегу понаблюдать этот цирк. Последовательно, на одном и том же компьютере, по очереди делаем одни и те же действия: скачиваем архив с плагином, разархивируем в нужную папку, запускаем приложение. Когда это делаю я — программа не видит плагин, когда это делает коллега — всё работает. На третьем круге этих интересных экспериментов вдруг замечаем разницу в действиях: я разархивировал плагин стандартными средствами Windows, а мой коллега — с помощью 7-Zip. И то и другое вызывалось нами из контекстного меню архива, так что разницу в клик по не тому пункту вначале никто не замечал. Ну ок. Получается, файл, извлечённый из zip-архива с помощью 7-zip, отличается от того же файла из того же архива, извлечённого с помощью стандартного архиватора Windows?

Кстати, пока вы не открыли статью под катом, ответьте-ка сами для себя на вопрос, может ли такое быть, что содержимое файлов валидного zip-архива при разархивации 7-zip и через проводник Windows будет разным?

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

• изменение котировок
• действия пользователей в онлайн-игре
• отображала агрегированную информацию из соцсетей в различных проекциях

и т.д. Если вы так не умеете, то смузи уже не нальют.

Функцией партиционирования таблиц в PostgreSQL, к сожалению, активно пользуются пока не многие. На мой взгляд, очень достойно о ней рассказывает в своей работе Hubert Lubaczewski (depesz.com). Предлагаю вам еще один перевод его статьи!

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

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

Привет!
У меня сегодня небольшой праздник. Моя книга «Бизнес как игра» наконец-то доехала до полок. Ещё тёплая.

Из постов, которые я тут пишу уже лет пять, выросла книга. Упоротая, с такими вещами, которые обычно про бизнес не пишут. Внутри — 140 маленьких глав на страницу-две про разные аспекты бизнеса, по сути — баек. Начиналось всё с хабрапостов — и постепенно стало понятно, что их надо очень сильно менять, плюс писать куда больше про бизнес и управление.

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

Хабр, привет!

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

Раньше я их выкладывал в группе продукта облачной IDE mr. Gefest, это были сборки из 5-8 решений. Но теперь у меня стало скапливаться по 15-30 скриптов в разных тематиках (кнопки, меню, подсказки и так далее).

Такие большие наборы следует показывать большему числу специалистов. Поэтому выкладываю их на Хабр. Надеюсь они будут Вам полезны.

Представленная информация будет полезна тем, кто планирует учиться или работать в США.
Своим постом я уточняю и дополняю недавнюю публикацию на эту же тему от 14 декабря 2015 — «Опыт эвалюации дипломов в США (WES)» пользователя yakorolev — habrahabr.ru/post/273069

1. Упомянутая в публикации на habrahabr организация WES входит в более глобальную структуру — National Association of Credential Evaluation Services (NACES). Помимо WES, ещё 18 других организаций предосталяют услуги по переводу education credentials к принятым в США. Список, состоящих в NACES организаций — www.naces.org/members.html

Из опыта code-review и ответов на StackOverflow набралось немало моментов, касающихся Java Collections API, которые мне казались очевидными, но другие разработчики о них почему-то не знали или знали, но не чувствовали уверенности их применять. В этой статье я собираю в общую кучу всё, что накопилось.

Содержание:

1. List.subList
2. PriorityQueue
3. EnumSet и EnumMap
4. Set.add(E) и Set.remove(E) возвращают булево значение
5. Map.put(K, V), Map.remove(K), List.set(idx, E), List.remove(idx) возвращают предыдущий элемент
6. Map.keySet() и Map.values()
7. Arrays.asList может быть ключом
8. Collections.max
9. LinkedList, Stack, Vector, Hashtable

Atlassian Confluence — мощное решение для развертывания Enterprise Wiki в организации (хотя, нет никаких технических проблем с тем, чтобы использовать его и дома — лицензия на 10 пользователей стоит всего 10 американских долларов в год). И лично мне Confluence нравится тем, что имеет дружелюбный интерфейс и позволяет интуитивно понятно редактировать контент, с легкостью дополняя его визуальными составляющими, что позволяет в итоге получить красивые и удобные для просмотра страницы. Кстати, этот пост тоже написан в Confluence.

Как-то я посчитал, что 1 минута простоя hh.ru в будни днем затрагивает около 30 000 пользователей. Мы постоянно решаем задачу снижения количества инцидентов и их длительности. Снизить количество проблем мы можем правильной инфраструктурой, архитектурой приложения — это отдельная тема, ее мы пока не будем брать во внимание. Поговорим лучше о том, как быстро понять, что происходит в нашей инфраструктуре. Тут как раз нам и помогает мониторинг.

В этой статье на примере hh.ru я расскажу и покажу, как покрыть мониторингом все слои инфраструктуры:

• client-side метрики
• метрики с фронтендов (логи nginx)
• сеть (что можно добыть из TCP)
• приложение (логи)
• метрики базы данных (postgresql в нашем случае)
• операционная система (cpu usage тоже может пригодиться)

Привет, Хабр. Прошло почти 2 года после моего последнего поста. Очень рад, что он оказался для многих полезным. За эти 2 года мы сделали очень многое. И мне хотелось бы поделиться опытом и своими впечатлениями.

С 20 заведений-клиентов из одной страны мы выросли почти до 4 000 из 12 стран. Наша команда выросла в 5 раз. Открыли офис в Москве и Варшаве. Выпустили приложение, помимо iOs и Web, еще на Android и Windows. Значительно увеличили функционал. Перевели Poster на 5 языков. За последний квартал приняли участие в 3-х международных выставках. Тесно дружим с такими компаниями как Epson, Microsoft, Intel. За нами пристально следят несколько крупных инвесторов. Европейская компания предложила нам поглощение.

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

Подборка ссылок на патентную информацию и поисковые ресурсы в интернете.
Версия 1.0. Будем дополнять.
Поделитесь в комментариях своими ресурсами. Будем благодарны и добавим в пост для удобства.

Из диалога двух программистов:
— Кажется, у нас дыра в безопасности!
— Слава Богу, хоть что-то у нас в безопасности…

1. Введение

Пару лет назад мы уже затрагивали тему безопасности в веб-приложениях. Тогда в рамках исследовательских работ был реализован собственный Service Provider для интеграции с продуктом Shibboleth по протоколу SAML 2.0.

В сегодняшней статье речь снова пойдет о безопасности веб-приложений. Мы сделаем небольшой обзор продукта KeyCloak (доселе оставленного без внимания сообществом Habr).



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

И снова: хоть и не глянцевое, но «живое» фото отдела продаж

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

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

Наша компания растёт, полагаться на человеческий фактор всё сложнее и сложнее, а многочисленные клиенты ожидают мгновенной реакции на свои заявки.

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

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

В сентябре этого года в Киеве прошла конференция, посвящённая большим данным — BigData Conference. По старой традиции, мы публикуем в нашем блоге некоторые материалы, представленные на конференции. И начинаем с доклада Александра Демидова.

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

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

Всем доброго времени суток. Конечно, для живущих в мегаполисах эта статья мало чем пригодиться, однако, для людей, живущих «рядом с сельским хозяйством» думаю будет полезной. Буквально недавно всем известная компания DJI выпустила на рынок новинку – «Agras MG-1» — коптер, который является «распылителем». Попросту говоря, это октокоптер, несущий на борту бак с жидкостью и распылителем. «О! Додумались наконец-то» — подумал я. Именно эта идея была темой моей диссертации в институте, однако, сидящие там «профессора» сказали: — « А что тут нового? С самолетов-то уже опрыскивали, и научной новизны тут по сути нет». Ну и после нескольких таких фраз я понял, что никому у нас это не надо кроме меня. А делать то, что никому не надо я не люблю. Честно сказать было неприятно, что такую инновацию по сути «запинали ногами». На этом моя «научная» деятельность и утихла.

А эту статью я решил написать после того, как увидел ценник на новый DJI Argas, и этот ценник был 15000 $. Вы издеваетесь?! $15000 за коптер, красная цена которому 4 тысячи, ну максимум 5 со всей его суперэлектроникой.

Схема отработки аварии первого уровня в «Мультикарте»

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

Это неправда. Просто до этого не было методологии и английского названия, а сами системы были. Первым проектом, который стали «называть по правилам», была инфраструктура «Альфы». В Сбербанке и «Транснефти», насколько я знаю, отказоустойчивая инфраструктура тоже была испокон веков, но только называлась «резервный центр обработки данных». И так далее.

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

Ну и, конечно, истории былинных провалов.

Современный веб-ресурс представляет из себя постоянно развивающийся механизм со множеством апдейтов и усовершенствований. Они нацелены на улучшение производительности, повышение конверсии, оптимизации работы и удобства использования. Но при этом по тем или иным причинам могут быть допущены ошибки, которые могут привести к компрометации веб-ресурса. Это могут быть «забытые» служебные скрипты, недостаточный контроль за данными, отсутствие проверок доступа, вывод различных ошибок и многое другое. Для используемой CMS в публичном доступе могут появиться эксплоиты, позволяющие получить доступ к тому или иному функционалу веб-приложения, при помощи которых злоумышленник может нанести вред или попытаться получить критичные данные. Многие уязвимости, эксплуатируемые среднестатическим злоумышленником, лежат на поверхности и не требуют глубоких познаний или квалификации для их эксплуатации.

Exasol — это современная высокопроизводительная проприетарная СУБД для аналитики. Ее прямые конкуренты: HP Vertica, Teradata, Redshift, BigQuery. Они широко освещены в Рунете и на Хабре, в то время как про Exasol на русском языке нет почти ни слова. Нам бы хотелось исправить эту ситуацию и поделиться опытом практического использования СУБД в компании Badoo.

Exasol базируется на трех основных концепциях:

1. Массивно-параллельная архитектура (англ. massive parallel processing, MPP)

SQL-запросы выполняются параллельно на всех нодах, максимально используя все доступные ресурсы: ядра процессоров, память, диски, сеть. Понятие «мастер ноды» отсутствует — все серверы в системе равнозначны.

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

2. Колоночное хранение (англ. columnar store)

Exasol хранит данные в колоночной форме, а не в форме отдельных рядов, как в классических СУБД. Каждая колонка хранится отдельно, разделяется на большие блоки, сортирируется, сжимается и равномерно распределяется по всем нодам.