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

Уйма места, около четверти здания, отведено под зелень. Хотя это могли бы быть рабочие места или залы для совещаний. Откуда у Безоса появилось такое несвойственное расточительство?

Разве что, если обилие зелени в офисе – это и есть экономия…

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

Недавно я выступал на конференции Saint TeamLead Conf 2019, в докладе я рассказал о том, как смог найти ряд проблем в рабочем процессе и потом постепенно поборол их. Здесь я постараюсь описать наиболее ценные практики, которые мне помогли не только наладить рабочий процесс, но и перестать издеваться над разработчиками. У сотрудников изменилось отношение к компании в целом и рабочему процессу.

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

И вот недавно при подготовке к очередному выпуску подкаста "Цинковый прод" я узнаю, что Google опубликовал свод правил по проведению Code Review, битком набитый ценными мыслями. Весь материал довольно объемный и не влезет в одну статью, поэтому я постараюсь выделить наиболее интересные (мне) мысли.

Итак, поехали

Хабр, привет!

Меня зовут Марина Могилко, я кофаундер онлайн-платформы LinguaTrip.com.

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

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

Итак, начинаем! Осторожно: под катом мини-словарик на все случаи жизни.

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

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

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

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

В общем, добро пожаловать в кабину поезда «Аэроэкспресс» и в рабочий день машиниста. Причём не обычного, а Алексея Александровича Назарова — человека, который испытывал первые швейцарские составы компании Stadler, принимал их для России и учил других машинистов обращаться с ними.

Перед каждым сервисом, генерирующим хотя бы 1 Мбит/сек трафика в интернете возникает вопрос: «Как? по TCP или по UDP?» В прикладных областях, в том числе и платформах доставки уже сложились предпочтения и традиции принятия подобных решений.

По идее, если бы, к примеру, однажды один ленивый разработчик не попробовал развернуть свой ML на Python (потому что только его и знал), мир скорее всего никогда не проникся бы такой любовью к презренному «супер-джава-кодерами» языку. А сегодня слабости этого языка в прошлом контексте применения безоговорочно обеспечивают ему первенство в развертывании и запуске многочисленных майнерских А/Б.

Сравнивать можно многое: ARM с Intel, iOS и Android, а Mortal Kombat с Injustice. И нарваться на космический холивар, поэтому вернемся к теме доставки огромных объемов разноформатного контента.

Десять лет назад все были абсолютно уверены, UDP — это что-то про негарантированную доставку. Если нужен надежный протокол — это TCP. И вопреки традициям в этой статье мы будем сравнивать такие, кажущиеся несравнимыми вещи, как TCP и UDP.


Осторожно, под катом 99 иллюстраций и схем и все важные.

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

Я не люблю такие обобщения. Да, что-то есть только в «двух столицах»: когда мы (JUG Ru Group) делали конференцию в Новосибирске, столкнулись с отсутствием нужного оборудования. Но в том же городе живёт известный многим Тагир lany Валеев, там он работает над IntelliJ IDEA, готовит крутые доклады и хабрапосты. И как тогда говорить, что там нечего делать?

Скоро мы проведём в Петербурге фестиваль TechTrain со слоганом «Узнай, чем живут другие», и там будут представлены многие IT-сообщества. А недавно в отпуске я ездил поездами по городам Транссиба, и фестиваль подал мне идею: в поездке узнать, чем живут айтишники в других городах, пообщавшись с активистами местных IT-сообществ. Я расспрашивал о их деятельности, о том, что в городе с IT, и о решении жить не в Москве. Делюсь с Хабром результатами.

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

И, как вы уже наверное догадались, я буду использовать FOSRestBundle — замечательный bundle, который и поможет нам реализовать backend.

Здесь не будет примеров как работать именно с Ангуляром, я буду описывать исключительно только работу с Symfony FosRestBundle.

Для работы нам так же понадобится JMSSerializerBundle для сериализации данных из Entity в JSON или другие форматы, исключения некоторых полей для той или иной сущности (например пароль для API метода получения списка пользователей) и многое другое.

Подробнее можете почитать в документации.

Ровно 15 лет назад, в этот самый день, своими дрожащими коленками я переступил порог офиса небольшого провинциального интернет-провайдера. Моя первая настоящая работа в качестве программиста. Знаний почти нет. Тонкий испуганный голосок откуда-то из желудка советует развернуться и убежать подальше, пока окончательно не опозорился. Глубокий вдох-выдох, и вот генеральный директор уже ведет меня в небольшую комнатку-подвальчик, показывает на полуразобранный компьютер, видавший лучшие времена: «Это твое рабочее место. Устраивайся». Так началась моя карьера.

Но перенесемся в настоящее. Сейчас я пишу эти строки, сидя в удобном офисе престижного БЦ в центре Москвы. За плечами работа с крупными международными брендами и разработка сложных fintech приложений. Сотни книг прочитано и десятки статей написано. Мания величия давно вылечена. Менеджерские позиции опробованы и отвергнуты. Душевное равновесие найдено. Любовь к профессии сохранена. Однако это не статья из серии “Какой я молодец. Делай, как я и тоже будешь молодцом”. Эта статья о том, какие ошибки я совершал и что можно было сделать лучше. Эта статья — ретроспектива моей карьеры.

Кратко о спецификациях:

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

На сегодня существует два (если знаете другие проекты, напишите пожалуйста в комментариях) успешных и популярных проекта на PHP, позволяющих описывать бизнес-правила в спецификациях и фильтровать наборы данных. Это RulerZ и Happyr Doctrine Specification. Оба проекта являются мощными инструментами со своими преимуществами и недостатками. Сравнение этих проектов потянет на целую статью. Здесь же я хочу рассказать, что нам привнес новый релиз в Doctrine Specification.

Добрый день уважаемые друзья! Сегодня мне бы хотелось рассказать, а главное, показать вам — как проходит операция по установке имплантата — со всеми инструментами и прочим. Если про процесс удаления зуба, в частности зуба мудрости — я уже рассказывал, то настало время поговорить о чем-то более серьезном.

ВНИМАНИЕ!-Uwaga!-Pažnju!-Attention!-Achtung!-Attenzione!-ВНИМАНИЕ!-Uwaga!-Pažnju!

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

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

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

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

Вот уже около трех лет я использую в работе принципы Spec By Example, Domain Driven Design и CQRS. За это время накопился опыт практического применения этих практик на платформе .NET. В статье я хочу поделиться нашим опытом и выводами, которые могут быть полезными командам, желающим использовать эти подходы в разработке.

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

Привет! Сегодня я хочу поделиться советами по написанию совершенного понятного кода, взятые из книги Питера Гудлифа «Ремесло программиста // Практика написания хорошего кода».

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

Приветствую вас, хабровчане, решил поделиться с сообществом переводом довольно часто (по личным наблюдениям) упоминаемого поста SOLID Go Design из блога Dave Cheney, который выполнял для собственных нужд, но кто-то говорил, что нужно делиться. Возможно для кого-то это окажется полезным.

SOLID дизайн Go

Этот пост на основе текста из основного доклада GolangUK прошедшего 18-ого Августа 2016.
Запись выступления доступна в YouTube.

Привет, Хаброжители! Если вам давно кажется, что вся разработка и развертывание в вашей компании донельзя замедлились — переходите на микросервисную архитектуру. Она обеспечивает непрерывную разработку, доставку и развертывание приложений любой сложности.

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

Предлагаем ознакомиться с отрывком «Управление транзакциями в микросервисной архитектуре»

Всем привет!

Предваряя сегодняшнюю переводную публикацию, сразу отметим, что этот текст задуман как follow-up недавнему дискуссионному материалу "Прекратите усердствовать с комментариями в коде". Нас настолько впечатлила развернувшаяся там дискуссия и 189 комментариев по состоянию на 19.07.2019, что мы решили дать здесь слово и другому автору с портала Medium (Кристоферу Лейну), который практически по всем принципиальным вопросам полемизирует с тезисами Брайана Норлендера, автора первой статьи. Отметим, что в оригинале данная статья вышла на месяц позже предыдущей (16 мая и 16 июня), но собрала практически вдвое меньше аплодисментов (706 против 1,5K на момент публикации перевода). Посмотрим, что будет на Хабре…



Снимок взят с сайта rawpixels.com от автора Pexels

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

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

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