Джош Эванс рассказывает о хаотичном и ярком мире микросервисов Netflix, начиная с самых основ — анатомии микросервисов, проблем, связанных с распределенными системами и их преимуществ. Опираясь на этот фундамент, он исследует культурные, архитектурные и операционные методы, которые ведут к овладению микросервисами.

Около 15 лет назад моя мачеха, назовем ее Фрэнсис, стала чувствовать боль и слабость во всем теле, ей стало трудно стоять, и когда врачи в больнице немного привели ее в себя, у нее обнаружился паралич рук и ног. Это было ужасное испытание для нее и для нас, как оказалось, диагнозом стал синдром Гийона-Барре. Мне просто любопытно, кто-нибудь из вас слышал о такой болезни? О, довольно много людей! Надеюсь, вы получили эту информацию не из первых рук. Это аутоиммунное заболевание, острый полирадикулоневрит, при котором иммунная система человека поражает собственные периферические нервы.



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

Вернуться Дальше

Эта книга — недостающая глава, отсутствующая в каждой всеобъемлющей книге Python.

Frank Ruiz
Principal Site Reliability Engineer, Box, Inc.

В продолжение статьи на тему что сказать git, чтобы он сделал то, что вам нужно и перед статьей как создать PR в чужой Open Source проект на GitHub думаю стоит полезным рассказать о том, что такое git rebase.

До того, как я начал работать в одноклассниках я думал, что знаю как пользоваться системой контроля версий. Но там мне дали ссылку на документацию по git. Эту книгу можно читать бесконечно, но на мой взгляд для того, чтобы начать пользоваться git она абсолютно бесполезна. Это не проблема скажете вы и будете совершенно правы. На том же хабре есть куча статей на тему как пользоваться git. Но пару дней назад один мой товарищ попросил объяснить ему некоторые непонятые им моменты. Я объяснил, как смог и хочу поделиться просто еще одной шпаргалкой на тему «10 простых действий по использованию git в повседневной работе». Не такой уж и маленькой она получилась, поэтому я пока напишу только как работать с git для вашего рабочего проекта, а потом, отдельно, что делать если вы хотите вносить изменения в чужой проект.

На Хабре есть не только айтишники. Тут и электрики, и схемотехники, и химики, и маркетологи и кого только нет. И возможность переезда в другую страну в качестве специалиста широкого профиля интересна и им тоже. В довесок к истории Дудя и аналогичным статьям я хочу рассказать свою историю про переезд в США, на противоположный от Калифорнии берег с противоположной от IT профессии. Про жизнь, траты, поиск и смены работы и перспективы. Мне 36, я по образованию биотехнолог, семья — два человека, английский язык — так себе. Живу в Северной Каролине почти два года.

Поскольку написанного вышло много, вот короткая версия. При переезде практически гарантировано снижение социального статуса. Прожить можно на $1500. Средняя зарплата «неайтишника» $30к-50к в год. Средняя стоимость дома $200к. Получить медицинскую страховку бесплатно можно. Много плюшек от государства. Поиск нормальной работы очень нетривиален. Язык сам не учится, но есть бесплатные курсы. Жить комфортно. Наше образование никому не нужно. Очень многие мечтают о карьере в IT.

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

Статья для тех, кто хочет переехать работать в США. На Хабре есть несколько хороших статей про поиск работы в Америке. Тут я постараюсь добавить к ним собственный опыт и поделиться несколькими приемами, которые помогли мне получить долгожданный джоб оффер.

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

Я системный администратор, занимаюсь компьютерами, и сегодня мы поговорим о Kubernetes. Я постараюсь глубже окунуться в тему, рассмотрев, какие проблемы сисадмин может решить с помощью этого приложения, и также затрону некоторые моменты эксплуатации Puppet, которая вроде как вписалась в этот мир с помощью нового набора абстракций для работы приложения.
Пять или шесть лет назад Луис Андре Барросо и Урс Хёзл в статье «Дата-центр как компьютер» высказали мысль, что мы должны воспринимать центр обработки данных как один массивный компьютер. Нужно абстрагироваться от того, что дата-центр состоит из отдельных машин, и считать его одной логической сущностью. Как только вы попытаетесь использовать эту идею на практике, то сможете применять к дата-центрам принципы построения распределенных систем и распределенных вычислений.



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

Зачем это читать?

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

Я работаю в LinkedIn, который был приобретен Microsoft в 2016 году. У меня были предложения от Facebook, Bayer и разных стартапов, плюс множество собеседований с другими компаниями в Долине, включая Google и Tesla.

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

Целевая аудитория

Вы разработчик, который хочет повернуть свою карьеру в сторону более совершенной модели DevOps? Вы являетесь классическим Ops-инженером и хотели бы получить представление о том, что означит DevOps? Или же вы не являетесь ни тем, ни другим и, потратив некоторое время на работу в области ИТ-технологий, хотите поменять работу и понятия не имеете, с чего начать?
Если да, то читайте дальше, чтобы узнать, как можно стать инженером DevOps среднего уровня за шесть месяцев! Наконец, если вы уже много лет занимаетесь DevOps, то все равно сможете почерпнуть много полезного из этого цикла статей и узнать, где находится отрасль интеграции и автоматизации в данный момент и куда она стремится в своем развитии.

Последний год я так или иначе пишу приложения на Flutter для iOS и Android. До этого у меня был и есть 5 летний опыт работы с Xamarin. Это были замечательные 5 лет. Благодаря Xamarin и моей любви к этому фреймворку я, в принципе, перешел в стан разработчиков, этот инструмент помог заработать мне немалых денег, знаний и найти замечательных коллег. Так почему же сейчас я пишу на Flutter? Короткий ответ, потому что Flutter покрывает все потребности кросс-платформенной разработки.

Немного истории

Поправьте меня если я не прав, но 2009 год был во многом ключевым для мобильной разработки в целом и кроссплатформенной разработки в частности. В 2009 вышел iPhone 3gs, который позволял запускать сторонние приложения из AppStore. Впервые эта возможность появилась в годом ранее в iPhone 3g, но по настоящему массовым, «народным» айфоном стал 3gs. Опять же, годом ранее, в сентябре 2008 Android был представлен публике и в 2009 многие производители телефонов стали пробовать Android для своих новый моделей телефонов. Весной 2009 компания Nitobi представила PhoneGap — новый фреймворк для создания кроссплатформенных приложений на основе HTML5, CSS и JS. В том же году, в сентябре компания Ximian выпустила MonoTouch, который позволял писать iOS приложения с использованием Mono и C#. В том же 2009, в декабре, компания Rovio Entertainment выпустила игру для iOS и, на минуточку, Maemo, которая во многом положила начало индустрии мобильных игр — Angry Birds. Последний пример здесь не случайно.

В статье "Contemporary Front-end Architectures" рассмотрены архитектуры фронт-энда с точки зрения потоков данных в исторической ретроспективе.

Материал состоит из трех частей

1. Теория и история
2. Реализация

3. Перспективы

Дисклеймер:

Я не программирую с трёх лет, не знаю наизусть Кнута, не являюсь призёром олимпиад по информатике и чемпионатов по спортивному программированию, не училась в MIT. У меня за плечами образование по информатике и 6 лет опыта в коммерческой разработке. И до недавнего времени я не могла пройти дальше первого технического скрининга в IT-гиганты из FAANG (Facebook, Amazon, Apple, Netflix, Google и подобные), хотя предпринимала несколько попыток. 

Но теперь всё изменилось, я получила несколько офферов и хочу поделиться опытом, как можно к этому прийти. Речь пойдёт о позиции Software Engineer в европейских офисах перечисленных компаний.

Осенью прошлого года в московском офисе Яндекса прошла первая Школа бэкенд-разработки. Мы сняли занятия на видео и сегодня рады поделиться на Хабре полным видеокурсом Школы. Он позволит вам научиться промышленной разработке на Python. Авторы лекций — опытные разработчики в Яндексе. К каждому видео приложены ссылки на примеры и полезные материалы.

Для изучения курса нужно знать основы Python и понимать, как приложения развёртываются на серверах. Мы ждём, что вы умеете делать запросы к базам данных и знаете, как создаются веб‑приложения, — хотя бы на начальном уровне.

Привет, меня зовут Александр Васин, я бэкенд-разработчик в Едадиле. Идея этого материала началась с того, что я хотел разобрать вступительное задание (Я.Диск) в Школу бэкенд-разработки Яндекса. Я начал описывать все тонкости выбора тех или иных технологий, методику тестирования… Получался совсем не разбор, а очень подробный гайд по тому, как писать бэкенды на Python. От первоначальной идеи остались только требования к сервису, на примере которых удобно разбирать инструменты и технологии. В итоге я очнулся на сотне тысяч символов. Ровно столько потребовалось, чтобы рассмотреть всё в мельчайших подробностях. Итак, программа на следующие 100 килобайт: как строить бэкенд сервиса, начиная от выбора инструментов и заканчивая деплоем.



TL;DR: Вот репка на GitHub с приложением, а кто любит (настоящие) лонгриды — прошу под кат.

Изображение: Unsplash

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

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

Я решил разобраться, так ли это на самом деле или в реальности не всё так просто. Для этого я поговорил с Денисом Неклюдовым, Staff Engineer в компании Lyft (конкурент Uber) и автором DevJobAccelerator. Итак, посмотрим, как на самом деле выглядит карьерный путь разработчиков в Кремниевой долине – от старта до компенсаций в миллионы долларов.

Кажется, тема «зачем нужен Kubernetes», уже раздражает. Хочется сказать: «все кому надо — давно уже поняли», однако я разделил бы технических (и околотехнических) работников на тех, кто «понял и знает как использовать», и тех, кто «понял, но хочет знать, как сделать знания актуальными».

Возможно, вы менеджер, который последние 10 лет работал на одном и том же стеке; возможно, вы разработчик, который поддерживает старое решение или пишет на привычном языке в привычной среде. Возможно, вы просто перешли из технического в организационный менеджмент и вдруг выяснили, что все, что вы знали, больше не актуально, и хочется понять — есть ли какой-то относительно простой сценарий, как это можно догнать. Я постараюсь дать советы, основываясь на собственном опыте, — от человека, который осознал, что, находясь на организационном управлении, скоро будет выражаться словами «Kubernetes — это эффективная технология, мы должны стремиться к ее применению», не вполне понимая, что лежит за этими словами и за всей технической культурой, развившейся в последнее время.

Почему я считаю важным уметь менять парадигму технологического мышления?

REPL (read-eval-print loop) бесполезен в Python, даже если это волшебный IPython. Сегодня я предложу одно из возможных решений этой проблемы. В первую очередь доклад и мое расширение TheREPL будет полезны тем, кого интересует более быстрая и эффективная разработка, а также тем, кто пишет stateful-системы.


— Меня зовут Александр, я в Яндексе работаю программистом. Пишем мы в моей команде на Python, на Go пока не перешли. Но в свободное от работы время я, как ни странно, тоже программирую и делаю это на очень динамическом языке — Common Lisp. Он, пожалуй, даже более динамический, чем Python. Его особенность заключается в том, что сам процесс разработки устроен несколько иначе. Он более интерактивный и итеративный, потому что в REPL на Lisp вы можете делать всё: создавать новые и удалять старые модули, добавлять методы, классы и удалять их, переопределять классы и т. д.

Перевод статьи подготовлен специально для студентов базового и продвинутого курсов «Математика для Data Science».

---

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

P(A|B) = P(B|A) * P(A)/P(B)

Вот так она выглядит, но что это значит и как работает? Сегодня мы это узнаем и углубимся в теорему Байеса.

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

Десять лет назад очевидно было то, что JavaScript имеет все шансы, так сказать, править миром. За эту честь сражались и другие платформы — такие, как Java, Flash и Silverlight. Всем этим трём платформам нужны, для работы в браузерах, специальные плагины. Все три меняют HTML-подход к формированию интерфейсов на что-то другое. Это позволило им уйти далеко вперёд от JavaScript в плане возможностей. Например — они умели проигрывать видео, выводить анимацию, рисовать что-то на экране. Всё это другие платформы поддерживали задолго до появления стандартного тега <video>, механизмов CSS-анимации и HTML-элемента canvas. Но всё это стало причиной их краха. Так, когда в мире начался бум мобильного интернета, и когда это было учтено в HTML, другие платформы оказались не у дел.



Ирония есть и в том, что происходит сейчас. В то самое время, когда JavaScript царствует в мире веб-разработки, появился один проект, вроде бы не особенно масштабный, который, когда-нибудь в будущем, способен стать убийцей JavaScript. То, о чём мы тут говорим, началось с экспериментальной технологии asm.js. Как это может выглядеть? Прежде чем ответить на этот вопрос — давайте немного притормозим и поговорим о современном положении дел.

Совсем недавно мы опубликовали статью с описанием проблем одной из самых популярных технологий, используемых в IT, и на наше удивление она вызвала достаточно живой интерес (во всяком случае для технической статьи). Поэтому мы решили на этом не останавливаться, и сегодня мы «идем в гости» к одному из самых популярных продуктов на российском рынке разработки бизнес-приложений — платформе 1С.

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

Статей с критикой 1С на Хабре достаточно (например, один, два, три), но, на мой взгляд, они либо слишком много внимания уделяют всяким мелочам, вроде неправильной организации меню, либо рассуждают о слишком абстрактных вещах, в которых 1С, возможно, и не виноват. В этой же статье, как и в статье про SQL, речь пойдет исключительно о фундаментальных (и вполне осязаемых) проблемах, которые касаются всех и каждого, кто разрабатывает / дорабатывает решения на 1С, и приводят либо к существенному росту порога вхождения, либо к серьезному падению производительности, либо к значительным трудозатратам со стороны разработчика.