PayUp и его рекламный ролик

А вот и видеоряд сервиса PayUp:

P.S. http://itech-notes.blogspot.com/2014/09/pay-up.html

Цепочка 'почему?'

Начинаете новое дело? Хотите понять, что в вашей жизни важно? Участвуете в обсуждении рабочих задач с коллегами?
Просто спросите "зачем?"

И скорее всего, одного такого вопроса/ответа будет мало, и понадобится задать второй, третий и ещё несколько вопросов "почему" да "зачем".

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

Ну, в целом понятно.
Надо понимать, что до бесконечности копать не следует. По моему мнению, 3-4, максимум 5 итераций вполне достаточно.

Вот несколько примеров от умных людей :)

 

На курсе основные практики архитектора ПО тренер Александр Уланов обращал внимание участников - архитектору обязательно нужно общаться с заказчиком и через серию уточнений-вопросов "Зачем? Почему? Для чего?" выявлять, что же требуется реализовать. Чтобы удовлетворить базовую потребность заказчика, а не какие-то "левые" идейки.

 

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

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

Вот ещё очень интересный опрос от Макса Пастухова, в котором речь идёт, по сути, о том же:

Задайте себе вопрос: зачем вам нужен бизнес? ... Не торопитесь с ответом: чаще всего он отнюдь не лежит на поверхности. Задайте себе несколько: "А зачем?" ... Непрерывная череда "зачем" может привести вас к пониманию своих истинных мотивов. Это - вопрос отнюдь не пары минут раздумий. Не торопитесь, пусть даже "переваривание" своих ответов и поиск новых вопросов "Зачем?" займет пару недель. ...

В общем, можно этот подход назвать цепочка 'почему?' (ну, или 'why' / 'what for' chain для тех, кто очень любит английский :))

Подход, который одинаково полезен и для бизнеса, и для работы, и для life management.

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

P.S. Если у кого-то есть примеры по теме - поделитесь, пожалуйста.

Static code analysis 3: обзор инструментов и заключение

Это третья часть цикла. Начало: http://itech-notes.blogspot.com/2014/09/sca-1.html и http://itech-notes.blogspot.com/2014/09/sca-2.html.

Рабочие итоги 2k14

Итоги подводить нужно. Чтобы обратить внимание на хорошие результаты или на неудачи. Чтобы вообще понять - а что же я год делал-то?

Импорт закрытого ключа в jks-хранилище

Для работы с ключами/сертификатами в java активно использую keytool: просто, понятно и "всегда под рукой".

Но иногда случается так, что на руках оказывается пара "закрытый ключ + сертификат", которую надо импортировать в jks:

Certificate.cer
Private.key

Но keytool возможности импорта не даёт (http://itech-notes.blogspot.com/2013/02/keytool.html).

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

Дело неблагодарное

Цитата из случившегося разговора:

"Долгосрочного плана у нас нет - как показывает практика, это дело неблагодарное."

Вот ведь ххх!

За этими словами в 99% (или даже в 100% ?) случаев скрывается непонимание.

Заказчики не понимают, чего они вообще хотят.  

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

Не, ну это же нормально, да, у нас же ведь не было долгосрочного плана, поэтому новые "хотелки" ничему не противоречат?!

Разработчики не понимают, что им делать. И либо ничего не делают, либо делают так, как удобнее/легче/прикольнее/... им самим.

Мол, давно вот brainfuck хотелось попробовать, напишу-ка я на нём самый важный алгоритм, то-то преемник кода порадуется!

Лиды и менеджеры не понимают, какие устанавливать сроки, какие требуются ресурсы, какие приоритеты известны, и т.д. и т.п.

Саша на сервере и Петя на мобильном приложении сделали уже по 50% своей работы! Круто, поставим галочки и закроем таски! 

Вот только их проценты ни разу не синхронизированы, и в результате система имеет реальный 0.

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

В общем, как показывает моя практика - когда понимание есть, когда цель видна, то и направление / шаги сами собой появятся. А оттуда и план подтянется. И проект от этого только выиграет. Требование хоть и недостаточное, но обязательное.

Pay Up

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