«За что я люблю Россию, так это за низкие налоговые ставки» — анонимуc

С ростом дохода у охотника за уязвимостями все более остро становится вопрос о налогах. После определенных сумм мне стало жалко отдавать 13% (даже несмотря на то, что у коллег из США это вообще 30%). К тому моменту я уже слышал об упрощенке для ИП и решил провести ресерч, чтобы понять как я могу уменьшить сумму налога законными способами.

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

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

В этом смысле опыт Леона Файера, которым он делился на DevOpsConf, не то чтобы прямо уникален, но помноженный на стаж и количество различных ролей, которые он за 20 лет успел на себя примерить, очень полезен. Под катом хронология событий за 90 дней и много баек, над которыми приятно посмеяться, когда они происходят с кем-то другим, но с которыми не так уж весело сталкиваться лично.

Леон очень колоритно рассказывает по-русски, поэтому если у вас есть 35-40 минут, то рекомендую смотреть видео. Текстовая версия для экономии времени ниже.

Как проверить идеи, архитектуру и алгоритмы без написания кода? Как сформулировать и проверить их свойства? Что такое model-checkers и model-finders? Требования и спецификации — пережиток прошлого?

Привет. Меня зовут Васил Дядов, сейчас я работаю программистом в Яндексе, до этого работал в Intel, ещё раньше разрабатывал RTL-код (register transfer level) на Verilog/VHDL для ASIC/FPGA. Давно увлекаюсь темой надёжности софта и аппаратуры, математикой, инструментами и методами, применяемыми для разработки ПО и логики с гарантированными, заранее определёнными свойствами.

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

Не буду лукавить: основная задача статьи — возбудить интерес. Так что в ней будет минимум пространных рассуждений и максимум конкретики.

В апреле ко мне постучались организаторы Слёрм — курсов по Kubernetes — потестировать и рассказать своё впечатление:

Дмитрий, Слёрм — это трехдневный интенсив по Kubernetes, плотное учебное мероприятие. Вряд ли вы сможете о нем написать, если просто посидите два часа на первой лекции. Вы готовы полноценно участвовать?

Перед слёрмом надо было пройти подготовительные online-курсы по ansible, docker и ceph.
Затем в репах взять код и точные инструкции, по которым уже на лекциях проходить каждую командную строчку за строчкой с ведущими.

— Подтверждаю, что готов полноценно участвовать в обоих курсах.

И после этого обеспечена напряженная работа на 6 дней (базовый Слёрм и МегаСлёрм) в аудитории, битком набитой сисадминами.

Без рекомендуемого трехлетнего практического опыта

*Примечание: статья посвящена сертификационному экзамену Google Cloud Professional Data Engineer, который был актуален до 29 марта 2019 г. После этого произошли некоторые изменения — они описаны в разделе «Дополнительно»*


Толстовка Google: есть. Серьезное выражение лица: есть. Фото из видеоверсии этой статьи на Ютубе.

Хотите заполучить новенькую толстовку, как у меня на фото?

Или, может, вас интересует сертификат Google Cloud Professional Data Engineer и вы пытаетесь понять, как его получить?

За последние несколько месяцев я прошел несколько курсов и параллельно работал с Google Cloud — для подготовки к экзамену Professional Data Engineer. Затем я пошел на экзамен и сдал его. Через несколько недель прибыла толстовка — но сертификат пришел быстрее.

В этой статье будут приведены некоторые сведения, которые могут оказаться полезны, и шаги, которые я предпринял для получения сертификата Google Cloud Professional Data Engineer.

Переведено в Alconost

Введение от переводчика

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

Это свободная расшифровка (или долгий парафраз?) моей презентации на организованной Genetec конференции ConnectDev'16.

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

Если вы читаете Twitter, вы, вероятнее всего, знаете что Hooks  -  это новая фича React, но вы можете спросить, как мы на практике можем их использовать? В этой статье мы покажем вам несколько примеров использования Hooks.
Одна из ключевых идей для понимания заключается в том, что Hooks позволяют использовать state и другие возможности React без написания классов.

Краткий мастер-класс по разработке инфраструктурного кода

В октябре этого года я выступил с докладом на конференции HashiConf 2018, где рассказал о 5 ключевых уроках, которые я и мои коллеги из Gruntwork усвоили в процессе создания и поддержки библиотеки из более чем 300 000 строк инфраструктурного кода, используемой в производственных системах сотнями компаний. В этой публикации я поделюсь видео и слайдами с выступления, а также сокращенной текстовой версией описания 5 основных уроков.

Видео и слайды

Вступление: DevOps сейчас — в «каменном веке»

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

Что лучше использовать при разработке софта — нативные или веб-технологии? Холивар по этому поводу закончится ещё не скоро, но мало кто станет спорить, что нативные функции полезно продублировать для использования в браузерах или WebView. И если когда-то приложения для звонков существовали исключительно отдельно от браузера, то теперь их легко реализовать и в вебе. Разработчик Григорий Кузнецов объяснил, как пользоваться технологией WebRTC для P2P-соединений.


— Как вы все знаете, в последнее время появляется довольно много приложений, в основу которых заложен прямой обмен данными между двумя браузерами, то есть P2P. Это всевозможные мессенджеры, чаты, звонилки, видеоконференции. Также это могут быть приложения, которые производят какие-то распределенные вычисления. Пределы фантазии никак не ограничиваются.

Привет, Хабр! Представляю вашему вниманию перевод статьи "Understanding How Graal Works — a Java JIT Compiler Written in Java".

Введение

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

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

Проходя собеседование на позицию Product Owner я понял, что у меня серьезный пробел по бизнес метрикам в Agile проекте, т.к. работаю в госструктуре. В русском сегменте информация достаточно скудная. В английском сегменте очень понравилась статья Ashwinee Kalkura. Поэтому решил сделать немного вольный перевод. Оригинал статьи здесь.

Что значат метрики для Agile команд?

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

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

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

И как тогда понять, что именно нужно измерить? Для меня ближайший путеводитель — это 7-й принцип в Agile Manifesto — «работающее программное обеспечение — лучший измеритель прогресса». Если Вы можете определить, что является для Вас рабочим программным обеспечением, становится легче измерить прогресс.

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

Я все еще не до конца понял, как так получилось, но в прошлом году я слово за слово подписался прочитать курс по Deep Learning и вот, на удивление, прочитал. Обещал — выкладываю!

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

Материалы курса были опробованы на студентах кафедры АФТИ Новосибирского Государственного Университета, поэтому есть шанс, что по ним действительно можно чему-то научиться.

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

На рынке есть куча инструментов для ревью кода с готовыми сценариями использования, рекомендациями и правилами. GitHub, Phabricator, FishEye/ Crucible, GitLab, Bitbucket, Upsource — список можно долго продолжать. Мы в Badoo тоже в своё время с ними работали: в своей предыдущей статье  я рассказывал нашу историю ревью кода и о том, как мы пришли к изобретению собственного «велосипеда» — решения Codeisok.

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

Именно поэтому другую часть айсберга можно и не заметить.

Согласно данным аналитического агентства «АВТОСТАТ», по итогам октября 2017 года объем рынка легковых автомобилей с пробегом в России составил 473 тыс. единиц, а по итогам 10 месяцев 2017 года — около 4,4 млн единиц, что на 1,5% больше, чем год назад.

Источник: www.autostat.ru/press-releases/32145

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

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

Представляем вам двенадцатую лекцию курса «Биология поведения человека» Роберта Сапольски про генетику поведения.

В этой лекции Уильям Питерсон и Том МакФадден знакомят нас с эндокринологией. Они рассказывают об основах эндокринной системы, о пептидных и стероидных гормонах, о процессах, с помощью которых мозг управляет гормонами, и о влиянии гормонов на мозг.

Под катом список переведенных лекций.

Перевод статьи Синди Шридхаран.

В этой статье автор собирается:

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

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

Эта мысль красной нитью пойдет сквозь материал под катом, и она, пожалуй, требует пояснения. Статья основана на докладе Николая Алименкова, к которому он подошёл не просто прогретым, а горящим после дискуссии с Алексеем Виноградовым о подходах к написанию тестов: методом прямого кода или при помощи паттернов. Нужны ли какие-то еще паттерны, кроме PageElement, Steps, PageObject?! С чего кто-то решил, что паттерны усложняют код, заставляют нас тратить время на создание ненужных (?) boilerplate-простыней? SOLID вам не угодил? А ведь все они создавались с учётом всего накопленного опыта сообщества разработчиков и они знали, что делают.

Николай xpinjection Алименков – известный Java-разработчик, Java техлид и delivery-менеджер, основатель XP Injection. В настоящее время является независимым разработчиком и консультантом, Agile/XP коучем, спикером и организатором различных конференций

Автоматизация тестирования имеет собственный набор задач, так что существует и набор полезных паттернов проектирования для этой области. В докладе Николай рассказывает обо всех известных паттернах и подробно описывает их с практическими примерами.



В основу этого материала легло выступление Николая Алименкова на конференции Heisenbug 2017 Piter под названием «Паттерны проектирования в автоматизации тестирования». Слайды здесь.

Программирование — достаточно молодая область знаний, однако, в ней уже существуют базовые принципы «хорошего кода», рассматриваемые большинством разработчиков как аксиомы. Все слышали о SOLID, KISS, YAGNI и других трех- или четырех- буквенных аббревиатурах, делающих ваш код чище. Эти принципы влияют на архитектуру вашего приложения, но помимо них существуют архитектурные стили, методологии, фреймворки и много чего еще.

Разбираясь со всем этим по отдельности, меня заинтересовал вопрос — как они взаимосвязаны? Пытаясь выстроить иерархию и вдохновившись небезызвестной пирамидой Маслоу, я построил свою пирамиду «архитектуры приложения».

О том, что из этого вышло — читайте под катом.

Что делать, если хочется побольше узнать про нейронные сети, методы распознавания образов, компьютерное зрение и глубокое обучение? Один из очевидных вариантов — подыскать для себя какие-либо курсы и начать активно изучать теорию и решать практические задачи. Однако на это придется выделить значительную часть личного времени. Есть другой способ — обратиться к «пассивному» источнику знаний: выбрать для себя литературу и погрузиться в тему, уделяя этому всего полчаса-час в день.

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