Цели

Планировать 3 цели на 9 недель спринты. По завершении спринта проводить анализ результатов и планировать новый спринт. Пример:

  ЦЕЛЬ №1: ПОПРОБОВАТЬ ПРЕДПРИНИМАТЕЛЬСТВО НА ВКУС.
  Этап 1. Узнать о преимуществах и недостатках карьеры из первых рук.

  1. Составить список 100+ предпренимателей получивших финансирование.
  2. Найти их профили в соцсетях (Facebook, Linkedin).
  3. Списаться/созвониться с 10+ и расспросить их о плюсах/минусах карьеры.

  Этап 2. Начать изучение предметной области.

  1. Пройти курс по стартапам на courcera/edx.
  2. Прочитать "Zero to One, Disciplined Enterpeneurship".
  3. Подписаться на 5+ блогов успешных предпринимателей.

  Этап 3. Влиться в предпринимательскую тусовку.

  1. Составить список мероприятий для стартапа на 2 месяца.
  2. Присоединиться к 5+ группам Facebook для начинающих предпринимателей.
  3. Посетить 5+ конференций/питч-сессий.

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

Выбор целей

Спросить себя "почему" 5 раз подряд. Например:

  Цель: Я хочу разработать мобильное приложение для ежедневника "Космос"

  1. Почему ты хочешь разработать это приложение? - Я хочу, чтобы моим
  ежедневником могли пользоваться люди, которые не любят бумажное
  планирование. Это расширит круг пользователей "Космос".

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

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

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

  5. Почему тебе нужно заряжать батарейку? - Без внешней подпидки мне
  сложно двигаться вперёд в карьере и в личном развитии.

Мотивация

"Морковка сзади" - дедлайны. Дедлайн должан держать в тонусе. 9 недель оптимальный срок, чтобы не прокрастинировать, т.к. дедлайн за углом.

"Морковка спереди". Потратьте 5-10 минут чтобы детально описать вкусную "морковку". Это может быть что угодно: поездка на отдых, нужный гаджет, какая-то покупка. Главное - чтобы "морковка" была желанной.

Ключевой навык успешного человека - упёртость. Это не то же, что упрямство. Упёртость можно и нужно тренировать. Каждый раз, когда вы превозмогаете своё "не хочу", она становится сильнее. Только так. Каждый день. Даже когда "муза не пришла" и дела хочется перенести на завтра. Шаг за шагом. Падение за падением. Спринт за спринтом.

Продуктивный день

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

1. Все входящие задачи скидываем в todo-лист.
2. Ежедневное планирование в конце рабочего дня на следующий день.
3. Разбить задачи на 25-минутные отрезки ("помидоры").
4. 5 "помидоров" до обеда, 5 - после.
5. Приоритетные задачи выполнять в первой половине дня.
6. Оставить "буферное" время для неотложных задач.
7. Каждую задачу зафиксировать в календаре.

Еженедельный трекинг прогресса

"Каждое воскресенье я завариваю чашку душистого чая и подвожу итоги прошедшей недели."

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

Достижения недели? 
Чему удалось научиться?
Что я могу улучшить в будущем?

Планирование отдыха на следующую неделю. Например, заранее приобрести билеты, пригласить друзей, запланировать поход.

"... Беседуйте с ребёнком, используя продвинутый слованный запас. Вовлекайте его в разговоры между взрослыми. Читайте ему вслух. Пореже ругайте его и почаще обращайтесь к нему с замечаниями, поощряющими его исследовать окружающий мир. Избегайте лишних стрессов... Стресс может отрицательно влиять на способности к обучению и решению очередных проблем, так как наносит ущерб проводящим путям между лимбической системой и профронтальной зоной коры. Наиболее тяжёлые стрессы могут отражаться и на памяти."

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

"Физические упражения полезны для ребёнка... Тренировка крупных мышечных групп действительно способствует более интенсивному росту нейронов... физические упражнения улучшают кровоснабжение головного мозга. Упражнения положительно влияют на интеллект даже если начать заниматься относительно поздно."

В книге так же описаны ряд упражнений-игр для развития рабочей памяти и контроля внимания детей. Некоторые упражнения очень похожи на упражнения wikium.ru. Так же описана польза медитативных упражнений (дыхательные, специальные позы, осознание собственного тела).

Самоконтроль.

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

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

Учите детей гибкости, хвалите за усердие

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

Не награждайте детей за то, что доставляет им удовольствие

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

Эффективное наставничество

Воспитывая своих детей, постарайтесь держать в голове правило "пяти С" Марка Леппера (control, challenge, confidence, curiosity, context): поощряйте в ребёнке ощущение контроля, ставьте перед ним сложные задачи, внушайте ему уверенность, возбуждайте его любопытство и, давая ему задание соотносите его с контекством: с реальным миром или ситуацями из кинофильмов и ТВ-программ"

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

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

#!/bin/bash

sshfs remote_host:/home/user/.keepassx /home/user/.keepassx && \
/usr/bin/keepassx && \
fusermount -u /home/user/.keepassx

В Debian требуется чтобы пользователь находился в группе fuse:

sudo gpasswd -a user fuse

Семантическое Версионирование 2.0.0-rc.2

В мире управления процессом разработки есть понятие "ад зависимостей" (dependensy hell). Чем больше растёт ваша система и чем больше библиотек вы интегрируете в ваш проект, тем больше вероятность оказаться в этой ситуации.

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

В качестве решения данной проблемы я предлагаю простой набор правил и требований, которые определяют как назначаются и увеличиваются номера версий. Для того чтобы эта система работала, вам необходимо определить публичный API. Он может быть описан в документации или определяться самим кодом. Главное, чтобы это API было ясным и точным. Однажды определив публичное API, вы сообщаете об изменениях в нём особым увеличением номера версий. Рассмотрим формат версий X.Y.Z (главная, второстепенная, патч). Баг-фиксы, не влияющие на API, увеличивают патч версию, обратно совместимые добавления/изменения API увеличивают второстепенную версию и обратно несовместимые изменения API увеличивают главную версию.

Я называю эту систему "Семантическое Версионирование" (Semantic Versioning). По этой схеме номера версий и то, как они изменяются, передают смысл содержания исходного кода и что было модифицировано от одной версии к другой.

Спецификация Семантического Версионирования (SemVer)

Слова "ДОЛЖЕН" (MUST), "НЕ ДОЛЖЕН" (MUST NOT), "ОБЯЗАТЕЛЬНО" (REQUIRED), "СЛЕДУЕТ" (SHOULD), "НЕ СЛЕДУЕТ" (SHOULD NOT), "РЕКОМЕНДОВАННЫЙ" (RECOMMENDED), "МОЖЕТ" (MAY) и "НЕОБЯЗАТЕЛЬНЫЙ" (OPTIONAL) в этом документе должны быть интерпретированы в соответствии с RFC 2119.

1. ПО, использующее Семантическое Версионирование, должно объявить публичное API. Это API может быть объявлено самим кодом или существовать строго в документации.  Как бы ни было это сделано, оно должно быть точным и исчерпывающим.
2. Обычный номер версии ДОЛЖЕН иметь формат X.Y.Z, где X, Y и Z - положительные целые числа. X - главная версия, Y - второстепенная версия и Z - патч версия. Каждый элемент ДОЛЖЕН численно увеличиваться на единицу. Например: 1.9.0 -> 1.10.0 -> 1.11.0.
3. После релиза новой версии пакета содержание этой версии НЕ ДОЛЖНО быть модифицировано. Любые изменения ДОЛЖНЫ быть выпущены как новая версия.
4. Главная версия ноль (0.y.z) предназначена для начальной разработки. Всё может измениться в любой момент. Публичное API не должно рассматриваться как стабильное.
5. Версия 1.0.0 определяет публичное API. После этого релиза номера версий увеличиваются в зависимости от того, как изменяется публичное API.
6. Патч версия  Z (x.y.Z | x > 0) ДОЛЖНА быть увеличена только если содержит обратно совместимые баг-фиксы. Определение баг-фикс означает внутренние изменения, которые исправляют некорректное поведение.
7. Второстепенная версия (x.Y.z | x > 0) ДОЛЖНА быть увеличена, если новый обратно совместимый функционал представлен в публичном API.  Она ДОЛЖНА быть увеличена, если какой-либо функционал публичного API помечен как устаревший (deprecated). Она МОЖЕТ быть увеличена в случае реализации нового функционала или существенного усовершенствования в приватном коде. Она МОЖЕТ включать в себя изменения, характерные для патчей. Патч версия ДОЛЖНА быть обнулена, когда увеличивается второстепенная версия.
8. Главная версия X (X.y.z | X > 0) ДОЛЖНА быть увеличена, если в публичном API представлены какие-либо обратно несовместимые изменения. Она МОЖЕТ включать в себя изменения, характерные для уровня второстепенных версий и патчей. Когда увеличивается главная версия, второстепенная и патч версия ДОЛЖНЫ быть обнулены.
9. Предрелизная версия МОЖЕТ быть обозначена добавлением дефиса и серией разделённых точкой идентификаторов, следующих сразу за патч версией. Идентификаторы ДОЛЖНЫ содержать только латинские буквы, цифры и дефис [0-9A-Za-z-]. Предрелизные версии имеют более низкий приоритет, чем соответствующая релизная версия. Примеры: 1.0.0-alpha, 1.0.0-alpha.1, 1.0.0-0.3.7, 1.0.0-x.7.z.92.
10. Сборочные мета-данные МОГУТ быть обозначены добавлением знака плюс и ряда разделённых точкой идентификаторов, следующих сразу за патч или предрелизной версией. Идентификаторы ДОЛЖНЫ содержать только латинские буквы, номера и дефис [0-9A-Za-z-]. Сборочные мета-данные СЛЕДУЕТ игнорировать, когда определяется старшинство версий. Поэтому два пакета с одинаковой версией, но разными сборочными мета-данными, рассматриваются как одна и та же версия. Примеры: 1.0.0-alpha+001, 1.0.0+20130313144700, 1.0.0-beta+exp.sha.5114f85.
11. Порядок версий ДОЛЖЕН рассчитываться путём разделения номеров версий на главную, второстепенную, патч и пред-релизные идентификаторы. Именно в перечисленном порядке (Сборочные мета-данные не фигурируют в расчёте). Главная, второстепенная и патч-версии всегда сравниваются численно. Очерёдность пред-релизных версий ДОЛЖНА быть определена сравнением наборов идентификаторов, разделённых точкой следующим образом: идентификаторы, состоящие только из цифр, сравниваются численно, буквенные идентификаторы или дефисы сравниваются лексически в ASCII-порядке. Численные идентификаторы всегда имеют низший приоритет, чем символьные. Примеры: 1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-beta.2 < 1.0.0-beta.11 < 1.0.0-rc.1 < 1.0.0.

Зачем использовать семантическое версионирование?

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

Простой пример демонстрирует, как Семантическое Версионирование может сделать "ад зависимостей" вещью из прошлого. Представим библиотеку, названную "Firetruck". Она требует Семантически Версионированный пакет под названием "Ladder". Когда Firetruck был создан, Ladder был 3.1.0 версии. Так как Firetruck использует функционал версии 3.1.0,  вы спокойно можете объявить зависимость от Ladder версии 3.1.0, но менее чем 4.0.0. Теперь, когда доступен Ladder 3.1.1 и 3.2.0 версии, вы можете интегрировать его в вашу систему и знать, что он будет совместим с текущим функционалом.

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

Если это звучит соблазнительно, всё что вам нужно - это начать использовать Семантическое Версионирование, объявить, что вы его используете, и следовать правилам. Добавьте ссылку на этот сайт в вашем README, тогда пользователи будут знать правила и извлекать из этого пользу.

FAQ

Что я должен делать с ревизиями в 0.y.z на начальной стадии разработки?

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

Как я узнаю, когда пора делать релиз 1.0.0?

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

Не препятствует ли это быстрой разработке и коротким итерациям?

Главная версия 0 как раз и означает быструю разработку. Если вы изменяете API каждый день, вы должны быть на версии 0.y.z или на отдельной ветке разрабоки работать над следующей главной версией.

Даже если малейшие обратно несовместимые изменения в публичном API требуют выпуска новой главной версии, не закончится ли это тем, что очень скоро версия станет 42.0.0?

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

Документирование всего API - слишком много работы!

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

Что мне делать, если я случайно зарелизил обратно несовместимые изменения как второстепенную версию?

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

Что я должен делать, если я обновляю свои собственные зависимости без изменения публичного API?

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

Что я должен делать, если исправление бага вернуло код в состояние совместимости с публичным API (т.е. появилось расхождение в документации публичного API и кодом)?

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

Что делать с устаревшим функционалом?

Объявление функционала устаревшим - это обычное дело в ходе разработки и часто необходимо для продвижения вперёд. Когда вы объявляете устаревшим часть публичного API, вы должны сделать две вещи: (1) обновить вашу документацию, чтобы дать пользователям узнать об этом изменении; (2) выпустить новый релиз с увеличением второстепенной версии. Прежде чем вы полностью удалите устаревший функционал в релизе с увеличением главной версии, должен быть как минимум один второстепенный релиз, содержащий объявление функционала устаревшим, чтобы пользователи могли плавно перейти на новый API.

About

 Авторство спецификаций Семантического Версионирования принадлежит Tom Preston-Werner, основателю Gravatars и соучредителю GitHub.

 Если вы хотите оставить отзыв, пожалуйста, задайте вопрос на GitHub.

 License

 Creative Commons - CC BY 3.0 http://creativecommons.org/licenses/by/3.0/

Оригинал: http://semver.org
Перевод: А.В.Янчарук