Article translated from Oliver Emberton blog abetterlife.quora.com
Перевод статьи abetterlife.quora.com/How-to-master-your-time-1

Секрет тайм менеджмента прост: приемы джедая

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



Можете думать о Татьяне как о воплощении Вашей мечты, Вашего вдохновения – пусть это самое важное в Вашей жизни.

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

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

Признаться, Фотошоп — это не самая сложная компьютерная программа из существующих (поскольку, будем откровенны, цифровые изображения — это не самая сложная часть компьютерной науки). Однако, он все-таки весьма сложен. Причин несколько. Во-первых, в Фотошопе много функций и, следовательно, возможностей. Во-вторых, он стар (он очень стар, он… ну вы понимаете :-) — почти моего возраста! Такая долгая история разработки означает, что создатели Фотошопа прошли долгую дорогу, и у них не было возможности пересмотреть основные концепции или переделать какие -то вещи заново. Совместимость и все такое. И потом, зачем чинить то, что не сломалось?

Images by about.com

Однако, сегодня ночью меня посетила идея… нет, ИДЕЯ! И теперь она сидит у меня в голове, стучится и просится наружу, хочет быть рассказанной, опубликованной и обсужденной. А что может быть лучше интересного обсуждения!

Итак...

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

Я бы хотел сегодня привести очень интересный отрывок из его дневника. Сегодня модно писать о том, как многое успевать, как быть эффективным, ка организовать бизнес и т.д. и т.п. К сожалению, как заметил Стивен Кови в своей книге «7 навыков высокоэффективных людей» (сам бы в жизни не читал по причине такого названия, но друг очень рекомендовал, прочитал книгу, очень доволен) сегодняшняя литература об управлении и личной эффективности сводиться к простому выписыванию рецептов решения стандартных проблем. Что-то типа аспирина на все случаи жизни. Редко встретишь книгу или статью затрагивающую глубинные мотивы, принципы внутренней жизни и целостности человека. Но сейчас не об этом… Хочу поделиться отрывком из дневника Франклина. Этот человек много достиг, поднялся с низов общества не имея официального образования, уверен, что много можно почерпнуть из его жизни.

Наверняка вы видели такую картинку.

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

Ответ на статью.

Если вы не разрабатываете ПО для машин или систем автоматического поддержания жизни и тд — нижесказанное работает для вас при грамотном применении.

Сразу скажу — не моя идея, в статье «Проектирования больше нет?» сам Мартин Фаулер писал об эволюционном рефакторинге. А Боб Мартин даже целую книгу запилил с примером поэтапного развития приложения (и не одним), назвав «Быстрая разработка ПО» и продемонстрировав умение виртуозно материться на Java и C++.

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

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

Хотите знать, как я обычно участвую в таких спорах?

— Так какие же тесты пишешь ты сам?
— Мнэ-э…

— Когда же ты пишешь тесты?
— Мнэ-э…

— Ты вообще тесты пишешь?
— Мнэ-э…

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

Но как раз сейчас у меня, кажется, есть эта парочка часов.

_{Не в совокупности ищи единства, но более – в единообразии разделения.
Козьма Прутков}

Немного воды вначале

Нельзя не заметить, что аспектно-ориентированное программирование с каждым годом берет новые рубежи популярности. На хабре было уже несколько статей посвященных этому вопросу, от Java до PHP. Пришло время обратить свой взор на С/C++. Теперь я в первом же абзаце признаюсь, что речь пойдет не об «настоящих аспектах», но о чем-то, близко с ними связанном. Также рассуждение будет вестись в контексте embedded-проектов, хотя описываемые методы могут применяться где угодно, но именно embedded, это та область, где эффект будет максимально ощутимым. Еще я буду использовать слова «хидер» и «дефайн» для обозначения, соответственно, «заголовочного файла» и «макроопределения». Сухой и академичный язык это хорошо, но в данном случае, мне кажется, все будет проще понять, если пользоваться устоявшимися англицизмами.

        Приветствую. Микроядра редко появляются на Хабре, но на неделе был  топик о GNU/Hurd, где вспоминали  разные микроядра и известные проекты. Было сказано много неточностей, так что я решил рассказать о том, как обстоят дела в отрасли с нашей точки зрения. Дело в том, что мы активно участвуем в развитии проектов Fiasco.OC и Genode и ведем разработки на их основе, так что нам есть о чем рассказать.

Под катом — мой вольный перевод (части) одной любопытной статьи Пола Грэма, описывающей принципиальную разницу между расписанием типичного менеджера и типичного «maker-a» — разработчика в частности.

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

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

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

Статья содержит перечень ресурсов для онлайн-обучения, представляющих интерес преимущественно для программистов.

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

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

Далее в посте:

1. С какой стати писать компиляторы?
2. Общий план
3. Анализ текста
4. Практический пример
5. Как это работает?

Если ты всегда мечтал написать свой язык программирования — добро пожаловать. Здесь ты наверняка найдёшь для себя что-нибудь интересное.

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

Пишет yawnt следующее:

С каждым днём мне всё интереснее тема компиляторов, интерпретаторов и дизайна языков программирования в целом. И я решил поделиться с народом ссылками на собранные мной материалы (большую часть мне самому ещё предстоит прочитать :<). Надеюсь, кому-нибудь они окажутся полезными.

Я не включил (и не собираюсь) в список ссылки на официальную документацию, т. к. считаю очевидным, что первым делом следует смотреть именно туда ;P.

Данная статья является кратким конспектом по книге "Andre Kukla: Mental Traps"

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

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

Продолжение перевода статьи Джона Оллспоу о личных качествах ведущих разработчиков.

Зрелые разработчики не жалуются просто так

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

В качестве введения

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

Это перевод статьи, написанной Джоном Оллспоу, который на данный момент является старшим вице-президентом технического отдела в Etsy.

Продолжение перевода здесь

В нашей сфере деятельности нам доступны огромные объёмы знаний, в особенности тех, которые позволяют разработчику стать эффективным. Но почему-то, несмотря на существование множества книг о специфических задачах и обязанностях менеджеров в нетехнических областях, я практически не вижу новых книг или статей о том, как стать хорошим ведущим разработчиком. Замечательным исключением, конечно, являются статьи Кейт Maцудайры [от переводчика: на фотографии, кстати, именно она], немало написавшей о культурных составляющих инженерии.

Но в то же время, все мои знакомые преуспевающие разработчики помнят своих наставников, которые научили их тому, что значит быть „ведущим“.

«Покой — это ложь. Есть только страсть.
Через страсть я познаю силу.
Через силу я познаю могущество.
Через могущество я познаю победу.
Через победу мои оковы рвутся.
И Великая Сила освободит меня.»
— Кодекс ситов

Я хочу поговорить о темной стороне кода и о том, к чему это приводит. Что я понимаю под темной стороной кода? С моей точки зрения — это такой код, который был написан программистами, которые поддались желанию написать кое-как, исходя из своих собственных целей, а не целей продукта. Они оставили покой (размеренное написание кода согласно практикам) в угоду страсти (код ради кода). А если есть темная сторона, то есть и ее представители — Темные властелины, Дарты. Вот о них мы сегодня и поговорим.

В первой части я рассказал о причинах, побудивших меня заняться построением своего “умного дома”, и об используемом “железе”.
Но “железо”, само по себе, умным быть не может, главное это “софт”. Вот об этой стороне своего проекта я и хочу рассказать в этой части. Банальное управление освещением с пульта, конечно, выглядит круто в глазах непосвященной публики, но “ума” тут никакого.
Так что же такого умного можно сделать? И, главное, как?

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

• Кухня-студия (кухня совмещенная с холлом/коридором), три точки освещения.
• Необходимо управлять освещением из двух точек. У входа в квартиру и на кухне.

Варианты решения:

• Покупаем, так называемые, проходные выключатели, ставим три штуки на кухню, три в коридоре — вот оно счастье. Вот только получилось, что от коридора на кухню нужно вести 9 жил кабеля, некрасиво, спрятать некуда.
• Покупаем готовые решения по управлению одним источником с нескольких точек.
  Точных чисел не помню, но получалось что-то около 10000р за точку освещения + 1000р за каждый выключатель, итого 36000р. Жаба.
• Как это ни странно, но эту идею высказала жена, в общем-то далекая от IT: “ А помнишь, ты светофор в Яндексе делал? Может тут тоже что-то сам сообразишь?”
  В самом деле, а почему бы и нет, подумал я?

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

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

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

Для начала, несколько фактов, которые относятся ко всем работникам интеллектуального труда. Задача, прерванная по ходу выполнения, занимает в два раза больше времени и содержит вдвое больше ошибок, чем та же задача, которая выполнялась без прерывания (Czerwinski:04). Офисные сотрудники вынуждены отвлекаться при выполнении 57% задач (Mark:05). Опросы говорят о том, что сотруднику требуется в среднем 15 минут, чтобы вернуться в нормальный ритм после того, как его отвлекли (vanSolingen:98).