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



В ЦФТ эту проблему решили регулярные встречи с инженерами один на один. Встречи помогают: вовремя выявить проблемы в работе, профессионально развиваться, повышать мотивацию и находить новые смыслы. О том, как готовиться ко встречам, какие вопросы задавать и как регулярно их проводить, расскажет Михаил Емельянов. Теперь вы будете знать, что делать, если инженер сказал: «Нам нужно поговорить...»

Михаил Емельянов — Head of Android Department в ЦФТ. В IT-разработке 12 лет, с Android — 10, из которых 2 года руководит командой Android-разработки в ЦФТ. Разрабатывал проект мультимедиа, различные проекты в финтехе и запускал стартапы.

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

Недавно в уютном чатике дата сатанистов подняли вопрос, как правильно "продавать" внутренние проекты по машинному обучению. Оказалось, что многие из нас весьма брезгливо относятся к экономическому обоснованию своей деятельности. Меж тем, чтобы провести минимальную оценку рентабельности проекта, никакого MBA не нужно — в небольшой статье (10 страниц текста, ке-ке-ке) я расскажу вам, что такое рентабельность инвестиций, как оценить её для внутреннего проекта, какую роль в этом играет Proof of Concept, и почему в реальной жизни всё может пойти не так. Делать мы всё это будем вокруг вымышленного проекта по автоматизации составления расписаний для колл-центра. Добро пожаловать под кат!

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

К сожалению, некоторые невысокие программисты всерьёз полагают, что Dockerfile с какой-нибудь вообще любой командой внутри — это уже сам по себе микросервис и его можно деплоить хоть сейчас. Докеры крутятся, лавешка мутится. Такой подход оборачивается проблемами начиная с падения производительности, невозможностью отладки и отказами обслуживания и заканчивая кошмарным сном под названием Data Inconsistency.

Если вы ощущаете, что пришло время запустить ещё одну аппку в Kubernetes/ECS/whatever, то мне есть чем вам возразить.

English version is also available.

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

Рассказ будет состоять из четырех смысловых блоков:

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

1. Высокоэффективные коммуникации: 4 типа позиционной коммуникации. Эта часть посвящена техническим вопросам, связанным с построением высокоэффективной коммуникации. Грубо говоря, что нужно делать в конкретной ситуации, для того чтобы коммуникация была эффективна.
   

1. Мастерство: 4 уровня развития компетентности. Здесь поговорим про личное мастерство руководителя, который осуществляет свое управленческое воздействие через коммуникацию.
   

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

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

Введение

Я хотел бы рассказать об опыте применения практик DDD к существующему Ruby on Rails проекту. Изначально, мы имели монолит, который писался 10 лет. Основная трудность проекта была в достаточно сложных процессах, и высокой связанности. Нам удалось не только декомпозировать приложение на отдельные сервисы, но и существенно повысить читаемость кода, сделать описываемые процессы прозрачными.

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

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

Введение

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

В данной статье я хотел бы сделать краткий обзор основных принципов DDD, а также поделиться личным опытом их применения. Более подробно будет рассказано о коммуникационных и структурных подходах с примерами их реализации.

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

В языке C# с самого начала поддерживалась передача аргументов по значению или по ссылке. Но до версии 7 компилятор C# поддерживал только один способ возврата значения из метода (или свойства) — возврат по значению. В C# 7 ситуация изменилась с введением двух новых возможностей: ref returns и ref locals. Подробнее о них и об их производительности — под катом.

Введение

С момента написания мной предыдущей статьи по оптимизации этой связки прошло довольно много времени. Тот многострадальный Pentium 4 c 512Мб памяти, обслуживающий одновременно до тысячи человек на форуме и до 150,000 пиров на трекере уже давно покоится на какой-нить немецкой, свалке, а клуб сменил уже не один сервер. Всё сказанное в ней всё ещё остаётся актуальным, однако есть вещи которые стоит добавить.
Статья большая, так что будет поделена на логические блоки:

0. Зачем вообще что-то оптимизировать?
  
1. Оптимизация ОС (FreeBSD)
  1.1 Переход на 7.х 
  1.2 Переход на 7.2
  1.3 Переход на amd64
  1.4 Разгрузка сетевой подсистемы
  1.5 FreeBSD и большое кол-во файлов
  1.6 Softupdates, gjournal и mount options
  
2. Оптимизация фронтенда (nginx)
  2.1 Accept Filters
  2.2 Кеширование
  2.3 AIO
  
3. Оптимизация бэкенда
  3.1 APC
  3.1.1 APC locking
  3.1.2 APC hints
  3.1.3 APC fragmentation
  3.2 PHP 5.3
  
4. Оптимизация базы данных
  4.1 MySQL 
  4.1.1 Переход на 5.1
  4.1.2 Переход на InnoDB
  4.1.3 Встроеный кеш MySQL - Query Cache
  4.1.4 Индексы
  
4.2 PostgreSQL
  4.2.1 Индексы
  4.2.2 pgBouncer и другие.
  4.2.3 pgFouine
  
4.3 Разгрузка базы данных
  4.3.1 SphinxQL
  4.3.2 Не-RDBMS хранилище
  4.4 Кодировки
  4.5 Асинхронность
  
Приложение. Мелочи.
  1. SSHGuard или альтернатива.
  2. xtrabackup
  3. Перенос почты на другой хост
  4. Интеграция со сторонним ПО
  5. Мониторинг
  
 6. Минусы оптимизации

Проблема stateful-приложений в Kubernetes

Конфигурация, запуск и дальнейшее масштабирование приложений и служб осуществляются просто, если речь идёт о случаях, классифицируемых как stateless, т.е. без сохранения данных. Такие сервисы удобно запускать в Kubernetes, пользуясь его стандартными API, потому что всё происходит «из коробки»: по стандартным конфигурациям, без привлечения какой-либо специфики и магии.

Проще говоря, для запуска в кластере из контейнеров ещё пяти копий бэкенда на PHP/Ruby/Python требуется лишь 5 раз поднять новый сервер и скопировать исходники. Поскольку и исходники, и init-скрипт лежат в образе, масштабирование stateless-приложения становится совсем элементарным. Как хорошо известно любителям контейнеров и микросервисной архитектуры, сложности начинаются для приложений категории stateful, т.е. с сохранением данных, таких как базы данных и кэши (MySQL, PostgreSQL, Redis, ElasticSearch, Cassandra…). Это касается как софта, самостоятельно реализующего кворумный кластер (например, Percona XtraDB и Cassandra), так и софта, требующего отдельных управляющих утилит (такого, как Redis, MySQL, PostgreSQL…).

Сложности возникают по той причине, что исходников и запуска сервиса становится не достаточно — нужно выполнить еще некоторые действия. Как минимум — скопировать данные и/или присоединиться к кластеру. А если точнее, то эти сервисы требуют понимания, как их правильно масштабировать, обновлять и переконфигурировать без потери данных и их временной недоступности. Учёт этих потребностей и называется «эксплуатационными знаниями» (operational knowledge).

Добро пожаловать во вторую часть руководства по нейронным сетям. Сразу хочу принести извинения всем кто ждал вторую часть намного раньше. По определенным причинам мне пришлось отложить ее написание. На самом деле я не ожидал, что у первой статьи будет такой спрос и что так много людей заинтересует данная тема. Взяв во внимание ваши комментарии, я постараюсь предоставить вам как можно больше информации и в то же время сохранить максимально понятный способ ее изложения. В данной статье, я буду рассказывать о способах обучения/тренировки нейросетей (в частности метод обратного распространения) и если вы, по каким-либо причинам, еще не прочитали первую часть, настоятельно рекомендую начать с нее. В процессе написания этой статьи, я хотел также рассказать о других видах нейросетей и методах тренировки, однако, начав писать про них, я понял что это пойдет вразрез с моим методом изложения. Я понимаю, что вам не терпится получить как можно больше информации, однако эти темы очень обширны и требуют детального анализа, а моей основной задачей является не написать очередную статью с поверхностным объяснением, а донести до вас каждый аспект затронутой темы и сделать статью максимально легкой в освоении. Спешу расстроить любителей “покодить”, так как я все еще не буду прибегать к использованию языка программирования и буду объяснять все “на пальцах”. Достаточно вступления, давайте теперь продолжим изучение нейросетей.

Traction в дословном переводе означает «тяга» или «сила сцепления». А в мире стартаперов «трекшн» – оценка того, как команде удается претворить бизнес-модель в жизнь. Проще говоря, трекшн – это «сцепление» стартапа с его дорогой (road map).

Зачем нужны трекшн-митинги

Трекшн-митинги устраивают всевозможные акселераторы и посевные фонды. Возможно и проведение внутренних трекшн-митингов в компании, когда вся команда отчитывается перед инвесторами или отделы отчитываются друг перед другом.

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



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

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

Гостем очередного выпуска «Без Слайдов» стал Леонид Игольник, бизнес-ангел из Кремниевой Долины, экперт по управлению инженерами и инженерией, осенью по случаю заехавший в Питер на одну из наших конференций. О чем мы поговорили с Лёней:

• кто такой Леонид Игольник, чем он занимался и занимается;
• о создании конкурентного преимущества;
• о стартапах и их выживании;
• о B2B, бизнесах-платформах и цифровых траснформациях «традиционных» бизнесов;
• о бизнес-ангелах;
• о деньгах;
• о культуре «выращивания» стартапов;
• об отношении к неудачам в Долине;
• о том, как формируется цена компании.

Вот видео:


Под катом — традиционно, расшифровка. Приятного прочтения!

Несколько лет назад я разрабатывал для одного большого телекома новую информационную систему. Нам приходилось взаимодействовать со всё нарастающим количеством веб-сервисов, открываемых более старыми системами или бизнес-партнёрами. Как вы понимаете, мы получили добрую порцию SOAP-ада. Заумные WSDL, несовместимые библиотеки, странные баги… Где только возможно мы старались продвинуть — и использовать — простые RPC-протоколы: XMLRPC или JSONRPC.

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

В статье описаны:

1. Manifesto for Agile Software Development
2. Agile Manifesto — IBM version
3. MoreAgile Manifesto
4. Agile Manifesto 2.1
5. Manifesto for Half-Arsed Agile Software Development
6. Declaration of Interdependence
7. Programming, Motherfucker
8. Software Craftsmanship Мanifesto
9. DevOps Manifesto

Я только что закончил семь собеседований в компаниях Кремниевой долины. В конечном итоге я принял предложение разработки программного обеспечения в Facebook.

Вот как я готовился к этим собеседованию и чему я научился на этом пути.

Мой многолетний путь в Кремниевую долину

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

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

Я оставил свое место в качестве ведущего инженера iOS в чудесной компании в Мельбурне и я вернулся обратно в мой родной город Перт, чтобы учиться. Тут я буду готовиться к переговорному процессу которое ждет меня в Кремниевой долине. Я знал, что это будет невероятно сложно и тяжело.

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

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

Несмотря на то, что можно найти не одну статью, объясняющую принцип метода обратного распространения ошибки в сверточных сетях (раз, два, три и даже дающих “интуитивное” понимание — четыре), мне, тем не менее, никак не удавалось полностью понять эту тему. Кажется, что авторы недостаточно внимания уделяют обычным примерам либо же опускают какие-то хорошо понятные им, но не очевидные другим особенности, и весь материал по этой причине становится неподъемным. Мне хотелось разложить все по полочкам для самого себя и в итоге конспекты вылились в статью. Я постарался исключить все недостатки существующих объяснений и надеюсь, что эта статья ни у кого не вызовет вопросов или недопониманий. И, может, следующий новичок, который, также как и я, захочет во всем разобраться, потратит уже меньше времени.

Зона комфорта — это зло. Хоть и приятное, даже очень. Но зло. Особенно, если речь идет о саморазвитии и изучении языков. Если каждый день в работе использовать довольно простые лексику и грамматику с минимальными изменениями, есть большая вероятность, что вы начнете забывать всякие там Conditionals или Future Perfect. Конечно же, нужно поддерживать язык на должном уровне и развивать его, поэтому мы попросили наших преподавателей поделиться книгами, которые им в этом помогают. Так что готовьтесь к подборке для высоких уровней и не только!

Произношение

Ship or Sheep? An Intermediate Pronunciation Course

В этом пособии вы найдете неплохой тест, который покажет ваши слабые стороны (всякие там “сри” или “фри”). Даже если ничего подобного не обнаружится, учебник стоит пройти от начала до конца, и вот почему:

За пять дней, с 24 по 28 июля 2017 года, я прошел собеседования в LinkedIn, Salesforce Einstein, Google, Airbnb и Facebook; все пять компаний предложили мне работу. Это был замечательный опыт и я понимаю, как мне повезло, что мои усилия оправдали себя, поэтому решил написать об этом. Здесь я расскажу о том, как готовился к собеседованиям, как они проходили и какое впечатление произвели на меня компании.

Как все началось

Я отработал в Groupon почти три года. Это моя первая работа, там были и прекрасные люди, и отличные проекты. Мы делали всякие интересные штуки, вводили перемены внутри компании, публиковали материалы и все в таком духе. Но со временем я стал ощущать, что темп моего самообразования стал затухать (попросту говоря, замедляться), мне не хватало пищи для ума. К тому же, как и всякого разработчика ПО из Чикаго, меня тянуло в Область залива Сан-Франциско — ведь там столько известных компаний.

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

SQL пробуждается и наносит ответный удар силам тьмы — NoSQL

С самого начала компьютерной эры человечество собирает экспоненциально растущие объемы данных, и вместе с этим растут требования к системам хранения, обработки и анализа данных. Из-за этого в последнее десятилетие разработчики ПО отказались от SQL как от устаревшей технологии, которая не могла масштабироваться вместе с растущими объемами данных — и в результате появились базы данных NoSQL: MapReduce и Bigtable, Cassandra, MongoDB и другие.

Однако сейчас SQL возрождается. Все основные поставщики облачных услуг предлагают популярные управляемые сервисы реляционных баз данных: Amazon RDS, Google Cloud SQL, база данных Azure для PostgreSQL (запущена буквально в этом году) и другие. Если верить компании Amazon, ее совместимая с PostgreSQL и MySQL база данных Aurora стала «самым быстрорастущим сервисом в истории AWS». Не теряют популярности и SQL-интерфейсы поверх платформ Hadoop и Spark. А в прошлом месяце поддержку SQL запустила и Kafka. Авторы статьи скромно признаются, что и сами разрабатывают новую базу данных временных рядов, которая полностью поддерживает SQL.

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

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

Часть 1. Новая надежда