Пользователь
Многие книги по столярному и плотницкому делу начинаются с рассказа о правильной организации рабочего места и инструмента. Мне хочется верить, что навыки разработки – это тоже культура и мастерство. Рациональный подход к рабочему окружению позволяет снизить стоимость разработки и последующей доработки проекта благодаря раннему обнаружению проблем и повышению производительности труда разработчика. Тема, конечно же, обширна, и я планирую написать цикл статей:
Каждый выбирает свой "уровень погружения". Вам не обязательно следовать каждому пункту из этого поста. Моя цель — показать, насколько хорошо развита экосистема на данный момент и чего вы можете и не можете от неё получить. Делайте выводы самостоятельно. Хотите — меняйте прошивку полностью и переходите на microg. Хотите — просто поставьте на свой телефон f-droid прямо рядом с gplay. Хотите — не делайте ничего.
Давайте поговорим об экосистеме приложений свободных приложений с открытым исходным кодом на Android. Попробуем установить MicroG — свободную реализацию сервисов Google на Android. Посмотрим, как и зачем со всем этим жить.
Далеко ходить не нужно, в соседних постах можно найти множество примеров того, как разработчиков выгоняют из Google Play по тем или иным причинам, заставляя общаться с ботами без возможности реальной аппеляции. Некоторые типы приложений теперь принципиально невозможно распространять (например, блокировщики рекламы, да и в принципе приложения обхода любых ограничений).
Мне, как параноику, не нравится, что у стороннего лица появляется практически полный доступ к моему устройству. Google способен как минимум удалить с моего телефона любое приложение в любой момент и собрать с него произвольные данные. Более того, google play service — это огромное (стандартная поставка — 600Мб, минимальная — 95Мб) количество постоянно обновляющегося кода, часть которая работает с системными привилегиями. Для сравнения, дистрибутив MicroG может весить всего 4Мб.
Доброго времени суток.
У вас тоже есть знакомый react-разработчик, который рассказывает восхитительные истории о сайд-эффектах в redux? Нет?! Могу я стать этим человеком?
Автор взял на себя смелость не писать вводную часть о том, что же из себя представляет библиотека redux saga. Он надеется, что в случае недостаточности данных великодушный читатель воспользуется поиском хабра или официальным туториалом. Приводимые примеры во многом упрощены для передачи сути.
Эта статья содержит краткую выжимку из моего собственного опыта и опыта моих коллег, с которыми мне днями и ночами доводилось разгребать инциденты. И многих инцидентов не возникло бы никогда, если бы всеми любимые микросервисы были написаны хотя бы немного аккуратнее.
К сожалению, некоторые невысокие программисты всерьёз полагают, что Dockerfile с какой-нибудь вообще любой командой внутри — это уже сам по себе микросервис и его можно деплоить хоть сейчас. Докеры крутятся, лавешка мутится. Такой подход оборачивается проблемами начиная с падения производительности, невозможностью отладки и отказами обслуживания и заканчивая кошмарным сном под названием Data Inconsistency.
Если вы ощущаете, что пришло время запустить ещё одну аппку в Kubernetes/ECS/whatever, то мне есть чем вам возразить.
English version is also available.
Сегодня мы будем говорить про журналы событий, количественные метрики и наблюдение за всем этим с целью увеличения скорости реакции команды на инциденты и уменьшения времени простоя целевой системы.
Erlang/OTP как фреймворк и идеология построения распределенных систем дает нам регламентированные подходы к разработке, инструменты и реализацию стандартных компонентов. Допустим мы применили потенциал OTP и прошли весь путь от прототипа до продакшена. Наш Erlang проект прекрасно себя чувствует на боевых серверах, кодовая база постоянно развивается, появляются новые требования и функционал, в команду приходят новые люди, и все вроде бы хорошо. Но иногда что-то идет не так и технические проблемы, помноженные на человеческий фактор, могут привести к аварии.
Поскольку подстелить соломку абсолютно для всех возможных случаев отказов и проблем невозможно или же экономически нецелесообразно, то необходимо управленческими и программными решениями сократить время простоя системы в случае сбоев.
Поехать работать в Австралию или Таиланд, когда тебе 25 и нет семьи, не так и сложно. И таких историй большое количество. А вот переехать, когда тебе под 40, жена и трое детей (8 лет, 5 лет и 2 года) — задача другого уровня сложности. Поэтому хочу поделиться своим опытом переезда в Германию.
Про то, как искать работу за границей, оформлять документы и переезжать – было много сказано, повторяться не буду.
Итак, 2015 год, мы с семьей живем в Санкт-Петербурге на съемной квартире. Долго думали, как нам переезжать, что делать со школой, местами в садике и съемной квартирой. Нами было принято несколько важных решений:
Программируя вместе за одним компьютером, Джефф Дин и Санджай Гемават изменили курс компании — и весь Интернет. На иллюстрации: лучшие программисты Google иногда кажутся двумя полушариями одного мозга. Рисунок Дэвида Планкерта
Это перевод статьи Rachel Andrew, являющейся одним из разработчиков спецификаций CSS.
В короткой серии статей я собираюсь потратить некоторое время на детальную распаковку Flexbox — точно так же, как я делала в прошлом с grid. Мы рассмотрим, для чего был разработан Flexbox, что он действительно делает хорошо, а когда мы не можем выбрать его в качестве способа компоновки.
В этой статье мы подробно рассмотрим, что на самом деле происходит при добавлении display: flex в вашу таблицу стилей.
Привет, Хабр! Представляю вашему вниманию перевод статьи "Wormholes in JavaScript" автора Mathius Buus.
Компьютеры — интересные машины. В теории они представляются нам идеальными механическими математиками работающими с цифрами и хорошо выполняющими операции сложения, умножения и вычитания.
Однако, такая абстракция довольно обманчива. Она уводит нас от понимания того, что компьютер обрабатывает разные математические операции с разной скоростью. Если вы пишете на JavaScript (или на любом другом языке) и заботитесь о производительности написанных вами алгоритмов, очень важно понимать как работают компьютеры под капотом.
Если мы знаем на что способен компьютер, мы можем использовать кратчайшие пути или кротовые норы, чтобы сделать наши программы намного быстрее, чем мы ожидали.
Даже школьникам известно про существование различных систем счисления и тот факт, что не каждая конечная десятичная дробь является конечной дробью в двоичной системе счисления. Немногие задумываются о том, что вследствие этого факта операции над float и double не являются точными.
Если говорить про Erlang, то он, как и многие другие языки, реализует IEEE754 стандарт для float, в то время как стандартный тип Integer в Erlang реализован с использованием арифметики произвольной точности. Однако, хотелось бы иметь не только bigint, но и возможность оперирования рациональными, комплексными и числами с плавающей точкой с необходимой точностью.
В статье представлен минимальный обзор теории кодирования чисел с плавающей точкой и наиболее яркие примеры возникающих эффектов. Решение, обеспечивающее необходимую точность операций через переход в представление с фиксированной точкой, оформлено в виде библиотеки EAPA (Erlang Arbitrary Precision Arithmetic), призванной удовлетворить потребности финансовых приложений, разрабатываемых на Erlang / Elixir.
Всем привет. Как вы, возможно, знаете, раньше я все больше писал и рассказывал про хранилища, Vertica, хранилища больших данных и прочие аналитические вещи. Сейчас в область моей ответственности упали и все остальные базы, не только аналитические, но и OLTP (PostgreSQL), и NOSQL (MongoDB, Redis, Tarantool).
Эта ситуация позволила мне взглянуть на организацию, имеющую несколько баз данных, как на организацию, имеющую одну распределенную гетерогенную (разнородную) базу. Единую распределенную гетерогенную базу, состоящую из кучи PostgreSQL, Redis-ов и Монг… И, возможно, из одной-двух баз Vertica.
Работа этой единой распределенной базы порождает кучу интересных задач. Прежде всего, с точки зрения бизнеса важно, чтобы с данными, движущимися по такой базе, все было нормально. Я специально не использую здесь термин целостность, consistency, т.к. термин это сложный, и в разных нюансах рассмотрения СУБД (ACID и CAP теорема) он имеет разный смысл.
Ситуация с распределенной базой обостряется, если компания пытается перейти на микросервисную архитектуру. Под катом я рассказываю, как обеспечить целостность данных в микросервисной архитектуре без распределенных транзакций и жесткой связности. (А в самом конце объясняю, почему выбрал для статьи такую иллюстрацию).
