В корпоративной культуре Netflix промолчать, если считаешь что-то неправильным или неудачным, означает подвести себя и всех коллег. Это означает: у тебя был шанс помочь компании, но ты им не воспользовался.

Я бы не хотел умирать.

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

Случится ли это через 5 лет или через 100 - не так важно, до 200-летнего юбилея я однозначно не доживу. Экспоненциальный рост количества поломок в организме, приведет к тому, что в каждый следующий год моя вероятность умереть будет выше, чем в предыдущий. Удваиваясь каждые 7 лет, вероятность смерти достигнет 10% в год в 80-летнем возрасте, после чего продолжит расти, пусть и с несколько меньшей скоростью. Если я доживу до 100 лет (событие с вероятностью около 1:1000), то моя вероятность умереть в ближайший год будет в районе 25% и продолжит расти дальше.

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

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

Задача

В Uber применяется несколько технологий хранения информации, причем, хранение бизнес-данных зависит от того, какова модель приложения, в которой они применяются. Одна из таких технологий называется Schemaless и обеспечивает моделирование взаимосвязанных записей с представлением в виде одной строки из множества столбцов, а также версионирование для каждого столбца отдельно.

Schemaless в ходу уже пару лет, и там накапливаются данные Uber. Притом, что Uber консолидирует все практические кейсы в Docstore, Schemaless остается источником истины для различных клиентских конвейеров задач, тех, что существуют уже давно. Schemaless как таковая использует быструю (но дорогую) базовую технологию хранения данных, которая позволяет обходиться задержкой порядка нескольких миллисекунд при высоком показателе QPS (запросы в секунду). Кроме того, Schemaless развертывает для каждого региона несколько реплик, чтобы обеспечить сохранность и доступность данных при различных моделях отказов.

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

Мягкое удаление (soft deletion) — это популярная в энтерпрайз разработке стратегия удаления, когда вместо физического стирания та или иная запись помечается как удаленная, а потом фильтруется во всех запросах на чтение. Применение мягкого удаления может быть оправдано целым набором требований: аудит, возможность восстановления удаленных записей, а иногда необходимо уметь удалять данные, при этом сохраняя на них ссылки из других записей… 

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

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

Большая часть статьи никак не ориентированна именно на Node JS разработчиков и может быть полезна вне зависимости от языка программирования.

Ссылка на Github репозиторий с кодом к статье — https://github.com/pavlovdog/grafana-prometheus-node-js-example

Kalm — бесплатное приложение с открытым исходным кодом. Представляет собой стандартный контроллер Kubernetes, который можно установить в любой кластер (версии v1.15 и выше), включая Amazon EKS и Google GKE. Основная цель Kalm — предоставить разработчикам простой пользовательский интерфейс, чтобы упростить работу с K8s.

Давайте на секундочку представим, что будет если объединить React-компоненты и дженерики...

Прим. перев.: автор этой статьи — engineering manager из Испании, работающий в цифровой торговой площадке Adevinta, представленной в 16 странах, — делится своими наблюдениями о частых проблемах, которые он встречал у создателей микросервисов. Об этих вызовах стоит знать заранее, чтобы не столкнуться с ними тогда, когда их решение может оказаться слишком затратным.

Когда пост Мартина Фаулера о микросервисах вышел в 2014 году, команды, в которых я работал, уже занимались SOA-приложениями. Эта статья и последующий хайп коснулись почти каждой команды разработчиков в мире. Стек Open Source-софта от Netflix был самым крутым в то время, поскольку позволял инженерам по всему миру перенимать опыт Netflix в распределенных системах. Если мы взглянем на работу разработчиков программного обеспечения сегодня, более шести лет спустя, большая её часть касается архитектуры микросервисов.

Syn ack, Хабр!

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

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

Давай посмотрим, как же достигают своего успеха самые успешные компании на рынке АйТи.

Появление Docker привело к взрывному росту популярности контейнеров, но с тех пор появились и другие инструменты. К сожалению, разобраться в них может быть совсем непросто. Но мы попробуем! И если вы считаете себя единственным, кто всего этого пока не понимает, не волнуйтесь... Это не так!

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

Например, вы проверяли погоду в понедельник? Ваш мозг ошибочно экстраполирует эту погоду — хорошую или плохую — на оставшуюся неделю: прогноз на 7 дней с солнечным днем в первый день Увидев любую последовательность, мы используем первый элемент в качестве примера. Мы привносим черты этого первого элемента (например, хорошую погоду) во все последующие элементы.

Мы в Dropbox считаем, что управление инцидентами — это центральный элемент нашей системы по обеспечению надёжности. И хотя мы также используем проактивные методы, такие как хаос-инжиниринг (сhaos engineering), то, как мы реагируем на инциденты существенное влияет на опыт наших пользователей. Во время потенциального сбоя сайта или проблемы с продуктом на счету каждая минута.

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

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

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

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

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

Итак, из Лекции №4 - Создание продукта, общение с клиентами и рост стартапа вы узнаете следующее:

00:10 – Как пройти путь от 0 до большого количества клиентов?

01:30 – Необходимое условие стартапа – иметь достаточно свободного времени.

01:45 – Сколько времени нужно уделять стартапу?

02:35 – Какой план у неопытных стартаперов?

03:35 – Какие вопросы нужно задать себе как основателю стартапа?

05:30 – С чего нужно начинать решение проблемы?

06:45 – С чего начал решение своей проблемы проект HOMEJOY?

08:20 – Способы для изучения рынка стартапа.

09:00 – Как и зачем нужно изучать конкурентов?

10:00 – Как идентифицировать потенциальных клиентов?

10:30 – Последнее, что нужно сделать перед созданием продукта или услуги?

11:45 – Что такое MVP и зачем он нужен?

12:40 – Как и зачем позиционировать свой продукт?

13:20 – Какую роль играет слоган для стартапа?

14:00 – Каким образом привлечь первых клиентов?

15:30 – Как искать возможность для продвижения своего продукта?

17:45 – Что делать после привлечения первых клиентов?

19:00 – Для чего нужны отзывы клиентов?

20:00 – Зачем нужно собирать статистические данные о клиентах?

21:20 – Что такое кривая честности?

23:55 – Что нужно сделать до официального запуска проекта?

25:15 – Как производить масштабирование стартапа?

26:30 – Временная недееспособность лучше, чем паралич стартапа.

27:00 – Что такое подход Франкенштейна?

Привет Хабр! С вами Горшков Максим, специалист по информационной безопасности Cloud4Y. Мне выпала честь первому протестировать новый инструмент киберразведки: OSINT-SAN. Разрабатывал его мой коллега по ИБ Максим Пономарёв (Bafomet).

Вы первыми выходите на рынок с прорывным продуктом, который пользуется успехом, — но в итоге всё-таки закрываете бизнес. Бывает ли такое?

Бывает: именно это произошло с первой студенческой социальной сетью. За месяц в ней зарегистрировалось 75% студенческого городка. Увидев неоспоримый успех, создатели сайта бросили учебу и сосредоточились на проекте.

У сети Campus Network были все задатки Facebook, но год спустя она ушла в небытие.

Стартапы закрываются один за одним (что неудивительно), но в этом случае примечательно то, что очень многое было сделано правильно: сервис был запущен до Facebook и был гораздо более продвинутым.

Что же пошло не так? ‍

Редакс - Single-store стейт-менеджер, в котором к тому же принято группировать данные по объектам. Примерно так же, как в стейте классовых компонентов в реакте.

То есть, это совершенная противоположность атомарного подхода, которому, к примеру, следуют многие хуки реакта или Multi-store стейт-менеджеры (например Effector, где селекторы не нужны по определению - достаточно сторов).

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

В общем, раз в редаксе нет возможностей ни эффектора, ни MobX, нам лишь остается напрямую обращаться к данным, начиная с самого верха. Это превращается в нечто вроде state.foo.bar.baz. А если перед этим еще нужно произвести какие-то вычисления с участием других значений из стора?

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

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