Буквально пару дней назад в Денвере закончилась очередная, уже 5-я по счёту, крупнейшая конференция по Go – GopherCon. На ней команда Go сделала важное заявление – черновики предварительного дизайна новой обработки ошибок и дженериков в Go 2 опубликованы, и все приглашаются к обсуждению.

Я постараюсь подробно пересказать суть этих черновиков в трёх статьях.

Как многим, наверняка, известно, в прошлом году (также на GopherCon) команда Go объявила, что собирает отчёты (experience reports) и предложения для решения главных проблем Go – тех моментов, которые по опросам собирали больше всего критики. В течении года все предложения и репорты изучались и рассматривались, и помогли в создании черновиков дизайна, о которых и будет идти речь.

Итак, начнём с черновиков нового механизма обработки ошибок.

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

Виктор Гюго; фотографию сделал Этьен Карьят в 1876

К лету 1830 года Виктор Гюго столкнулся с невозможным дедлайном. За двенадцать месяцев до этого знаменитый французский автор договорился со своим издателем, что напишет для него новую книгу, "Собор Парижской Богоматери".

Но вместо работы над книгой, весь год Гюго занимался другими проектами, развлекал гостей, и откладывал работу с текстом. Его издатель всё больше раздражался из-за продолжавшейся прокрастинации автора, и среагировал, установив пугающий крайний срок для сдачи книги. Он потребовал, чтобы Гюго закончил книгу к февралю 1831 – то есть, менее, чем за шесть месяцев.

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

Есть такая поговорка: «Хочешь сделать хорошо — сделай сам».

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

Всем привет!

Компания Netсracker уже много лет разрабатывает и поставляет enterprise-приложения для мирового рынка операторов связи. Разработка таких решений достаточно сложна: в проектах участвуют сотни людей, а количество активных проектов исчисляется десятками.

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

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

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

Источник

При работе любого enterprise-приложения образуются данные: это файлы логов, метрики, информация об активности пользователей, исходящие сообщения и т. п. Правильные манипуляции над всеми этими данными не менее важны, чем сами данные. Если вы — архитектор, разработчик или выпускающий инженер, желающий решать подобные проблемы, но пока не знакомы с Apache Kafka, то именно из этой замечательной книги вы узнаете, как работать с этой свободной потоковой платформой, позволяющей обрабатывать очереди данных в реальном времени.

Для кого предназначена эта книга

«Apache Kafka. Потоковая обработка и анализ данных» написана для разработчиков, использующих в своей работе API Kafka, а также инженеров-технологов (именуемых также SRE, DevOps или системными администраторами), занимающихся установкой, конфигурацией, настройкой и мониторингом ее работы при промышленной эксплуатации. Мы не забывали также об архитекторах данных и инженерах-аналитиках — тех, кто отвечает за проектирование и создание всей инфраструктуры данных компании. Некоторые главы, в частности 3, 4 и 11, ориентированы на Java-разработчиков. Для их усвоения важно, чтобы читатель был знаком с основами языка программирования Java, включая такие вопросы, как обработка исключений и конкурентность.

В этой статье мы расскажем о курсе «Языки веб-программирования», который читается на кафедре «Компьютерные системы и сети» (ИУ-6) МГТУ им. Н.Э. Баумана. Примеры приводятся на Ruby, а сам курс и представляет собой 16 видеолекций, доступных бесплатно на канале Технострим. В «Бауманке» курс читается для студентов второго курса, уже знакомых с высокоуровневыми языками программирования, такими как Pascal, C++ или Java. Основной акцент делается на системное понимание технологий, используемых в веб-программировании, а не на глубину освоения именно технологий Ruby. Поэтому курс также будет полезен слушателям, имеющим отрывочные знания о веб-технологиях на любых языках.

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

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

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

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

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

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

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

Как стать техническим директором, что делать во внештатных ситуациях, как добиваться повышения зарплаты и карьерного роста, а также как устроена разработка Am.ru — об этом мы беседуем в четырнадцатом выпуске ток-шоу для программистов «Oh, My Code».


Ведущий программы — технический директор медиапроектов Павел Щербинин, гость — Александр Мельничук, технический директор Am.ru.

Здравствуйте, коллеги!

Напоминаем всем, что у нас вышла отличная книга Марка Прайса "C# 7 и .NET Core. Кросс-платформенная разработка для профессионалов". Обратите внимание: перед вами уже третье издание, первое издание было написано по версии 6.0 и на русском языке не выходило, а 3-е издание вышло в оригинале в ноябре 2017 года и охватывает версию 7.1.


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

Эванс написал хорошую книжку с хорошими идеями. Но этим идеям не хватает методологической основы. Опытным разработчикам и архитекторам на интуитивном уровне понятно, что надо быть как можно ближе к предметной области заказчика, что с заказчиком надо разговаривать. Но не понятно как оценить проект на соответствие Ubiquitous Language и реального языка заказчика? Как понять, что домен разделен на Bounded Context правильно? Как вообще определить используется DDD в проекте или нет?

Последний пункт особенно актуален. На одном из своих выступлений Грег Янг попросил поднять руки тех, кто практиукует DDD. А потом попросил опустить тех, кто создает классы с набором публичных геттеров и сеттеров, располагает логику в «сервисах» и «хелперах» и называет это DDD. По залу прошел смешок:)

Как же правильно структурировать бизнес-логику в DDD-стиле? Где хранить «поведение»: в сервисах, сущностях, extension-методах или везде по чуть-чуть? В статье я расскажу о том, как проектирую предметную область и какими правилами пользуюсь.

Привет, Хабр! Представляю вашему вниманию перевод статьи «What habits made me a better Software Engineer?» от Sonny Recio.

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

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

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

Если вас заинтересовали мои слова, вот некоторые из привычек, которые я сформировал, чтобы стать успешным. Вы их можете также использовать:

Привет, Хабр! Представляю вашему вниманию перевод статьи Samer Buna «React.js Frequently Faced Problems».

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

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

На самом деле, если вы сконцентрируетесь на одной вещи, например на создании сайта на простейшем HTML/CSS/JavaScript без библиотек, а потом добавите фреймворк по типу React’а, ваш путь от новичка до профессионала пройдет гораздо удобнее и приятнее.

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

Изучающие английский язык рано или поздно сталкиваются с неправильными глаголами: ненавистной как минимум сотней необходимых в быту глаголов, которые имеют по три формы. И все эти три формы надо зубрить, зубрить, зубрить! Неужели английский без них не может обойтись? И вообще, почему в русском неправильных глаголов нет, а в английском есть? Можно ли как-нибудь обойтись без них? Для ответов на все эти вопросы нам надо обратиться к истории языка.

Ньютон — Лейбниц, Лобачевский — Гаусс, Белль — Грей, Бонд — Лассель… Эти пары фамилий объединяет одно: их можно привести как примеры так называемых множественных открытий: ситуаций, когда несколько учёных или изобретателей делают свою работу одновременно и независимо.

Нечто похожее произошло и с моим проектом. Чуть менее года назад я приступил к разработке системы генерации HTML — вёрстки на основе растрового изображения. Прошло немного времени, и в мае 2017 года была опубликована работа под названием pix2code, при этом получив неплохое распространение в специализированных СМИ. Время шло, я не отчаивался, двигаясь по своему пути. Но недавно произошло страшное: разработчики из FloydHub на основе pix2code создали свою нейронную сеть, верстающую сайты на основе картинок. В рунете эту новость подхватили, и о релизе FloydHub стало известно большому количеству людей. И это в тот момент, когда согласно заранее заданному мною же плану я должен был выпускать своё демо. Но, как известно, лучшее – враг хорошего, и желание улучшить проект «ещё и ещё» отложило релиз на неопределённое время.

В этот момент я понял: кодить, это, конечно, хорошо, но надо выносить свою работу в свет. Встречайте: «Щелкунчик» — альтернатива pix2code с блэкджеком, но, увы, без нейронок.

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

1. Переносимость. Окружение должно быть легко воспроизводимо на различных машинах.
2. Изолированность. Окружение не должно влиять на версии установленных библиотек и программ на машине разработчика.
3. Гибкость. Окружение должно позволять собирать релизы для различных версий Golang и Linux (разные версии дистрибутивов и glibc).
4. Повторяемость. Не должно быть магии и тайных знаний, то есть все шаги сборки проекта и зависимостей должны быть описаны кодом.

Продолжаем обзор самых популярных докладов HighLoad++ 2017 по тематике тимлидерства. В этой части мы расскажем о выступлениях для уже состоявшихся руководителей — в первую очередь о движении из тимлида на более высокие посты. Ну и немного поговорим о психологии.

В компании, где я работаю — большинство сервисов запускаются и работают в docker-контейнерах.

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

Для человека, написавшего около сотни docker-образов и запускающего их несколько раз в день — такой вопрос уже не стоит, но когда я разбирался с докером в давние времена — мысль "Как же писать код в докере? Это же сверхнеудобно!" долго была актуальной.

В статье я опишу свои практики работы с образами docker, которые позволяют писать код "как у себя в home", и даже лучше.