Один технический специалист нашей компании PayOnline, которая занимается автоматизацией приема платежей, предложил перевести статью автора Pascal de Vink, который проработал тим-лидом уже 2 года. Когда Pascal только занял эту должность, оказалось, что ко многим вещам он был просто не готов. Эта статья поможет избежать многих ошибок на пути от разработчика к лидеру команды. Ниже идет непосредственно перевод.

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

Меньше заниматься разработкой

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

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

Зачем и для кого статья?

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

Здесь не будет пересказа манов (документации), и статья никак не отменяет и не заменяет их чтение. Вместо этого я расскажу о главных вещах (командах, приемах и принципах), которые надо осознать с самого начала работы в unix shell-е, чтобы работа происходила эффективно и приятно.

Статья касается полноценных unix-подобных окружений, с полнофункциональным шеллом (предпочтительно zsh или bash)и достаточно широким набором стандартных программ.

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

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

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

Практика — это когда всё работает, но никто не понимает, как. Теория — когда ничего не работает, но все точно знают, почему. Мы же пришли к сочетанию теории с практикой: ничего не работает — и никто не понимает, почему.

В функционировании любого растущего бизнеса — не только в IT, но и в других областях — наступает момент, когда заброшенные в дальний угол и уже успевшие покрыться благородной патиной проблемы становится невозможно игнорировать. Их последствия дают о себе знать в самых неожиданных ситуациях. Есть не один десяток методик, позволяющих разобраться с проблемами и заставить бизнес работать, но начинать приходится всегда с одного и того же: анализа первопричин этих самых проблем. И сегодня Роботам хотелось бы поговорить об этом — не только переведя статью о методах поиска первопричин бизнес-тренера по IT и специалиста по Agile, Scrum и Kanban Хенрика Книберга — но и рассказав о том, как Роботы исправили несколько собственных поломок.

В предыдущей части мы обсудили библиотеку BetterVectorDrawable, реализующую VectorDrawable для Android 4.0+.
В этой части речь пойдет о преобразовании изображений из SVG в vector drawable XML.

Перевод от Alconost

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



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

Образцовые же карьеры больше похожи на такой график. Здесь есть периоды замедления роста и что-то вроде ключевых точек, где карьера “выстреливает”.



Разные цвета? Это смены направлений: из разработки в продуктовый менеджмент, из продаж в основатели стартапа и т.п.

На графике есть и неудачи. И знаете, почему? Потому что быть лучшим предполагает некоторый риск. А если принять достаточно рисков, то обязательно в чем-то оступитесь.

Принимая во внимание все вышесказанное, позвольте дать вам 15 советов о ваших карьерных выборах, кодинге, амбициях и всем остальном.

Однажды Федерик Мазелла (ныне гендиректор BlaBlaCar) пытался уехать из Парижа к родственникам в Вандею. Так и не найдя вариантов по разумной цене и в удобное время он был вынужден купить билет на поезд за 115 евро. В 2006 году совместно с партнерами Мазелла запустил BlaBlaCar.

В России сервис был запущен в феврале 2014 года. Это была первая страна за пределами Европы, куда вышла компания. Сегодня у BlaBlaCar около 20 миллионов пользователей во всем мире, которые ежемесячно совершают через нее около 4 миллионов поездок.

Операционный директор и сооснователь BlaBlaCar Николас Брюссон рассказал РБК о причинах запуска в России и встрече с Алексеем Лазоренко и командой сервиса по поиску попутчиков «Подорожник», о том, почему компания не выйдет в США и Китай, о принципиальной разнице между Uber и BlaBalaCar.

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

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

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

Прочтите внимательно эту статью, если вы применяете упрощенную систему налогообложения с объектом налогообложения «доход» по ставке 6 процентов и продаете игры или приложения в Google Play, Apple App Store, а также прочий цифровой контент — например, 3D-модели — в Steam, Unity Asset Store или на других площадках, в условиях договоров с которыми фигурируют комиссии, агентские вознаграждения и прочие формы разделения выручки между сторонами.

Из материала вы узнаете:

• Почему разработчику желательно обладать хотя бы базовой юридической грамотностью
• Чем с точки зрения Гражданского кодекса являются игры и приложения и какие права на них есть у разработчиков помимо авторского права
• Что такое агентский договор и почему все это важно при работе по договору с Apple или Google
• Кто такой налоговый суслик и почему он может превратиться в пушного зверя
• Какой «подвох» существует для применяющих «упрощенку» в части определения налоговой базы
• Почему налог на добавленную стоимость (НДС) продолжает преследовать нас, даже когда мы не являемся его плательщиками
• Как, с точки зрения Федеральной налоговой службы, облагаются НДС внутриигровые покупки (InApp Purchases)

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

P. S. В статье нет спойлеров!

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

Приветствую.

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

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

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

Поиск чего-то похожего на Tydlig ничего не дал, и было принято решение писать свое приложение.

Что из этой затеи получилось:

Всем привет!

В нашей компании, помимо разработки собственной СУБД, также занимаются заказными разработками по самым разным направлениям, от суровых java-энтерпрайз приложений до небольших мобильных приложений. Наши команды стараются использовать передовые технологии и фреймворки. И как раз я являюсь представителем одной из таких команд. Сегодня хочу поделится опытом разработки на AngularJS и парой мыслей о проектировании веб приложения с использованием этого фреймворка.

Я хотел бы рассказать вам об утилите, с которой вы сможете забыть о боли создания документации для Web API. О том как это сделать прошу всех под кат.

Статья 1. Почему я не преподаю SOLID

Если вы разговариваете с кем-то, кому небезразлично качество кода, уже достаточно скоро в разговоре всплывёт SOLID — аббревиатура, помогающая разработчикам запомнить пять важных принципов объектно-ориентированного программирования:

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

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

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

Известный провайдер heroku поддерживает манифест, который называется «12-факторное приложение» (Twelve-Factor App). Это набор лучших практик для разработки современных веб приложений на любой платформе. Практики описывают приложения, которые готовы:

• к горизонтальному масштабированию;
• к непрерывному развертыванию;
• к современным облачным хостингам.

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

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

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

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

Когда вы только начинаете работать, то у вас все ясно и понятно, задач не так много, вы представляете как с ними работать. Но со временем появляется мысль «у меня столько задач!!! что с ними делать? за что взяться?», либо просто приходит осознание, что задач накопилось очень много. В этом случае вам поможет тайм-менеджмент.

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

Тайм-менеджмент по сути это совокупность действий по тренировке осознанного контроля над временем, посредством которого можно существенно увеличивать свою продуктивность и эффективность.

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

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

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