This article in English: GTD Implementation via New Google Keep and Calendar Features

За последние годы Google Keep и Calendar значительно расширили свою функциональность, что дает возможность построить более удобную реализацию методологии GTD (Getting Things Done) на их основе. Ранее я уже публиковал материал с реализацией GTD на основе Google Calendar. Представленный теперь материал можно рассматривать как обновленную реализацию GTD на тех же принципах, но с использованием более современных средств.

В моем материале 2015 года в качестве базового элемента для всех пяти фаз управления рабочим процессом (Control) в системе GTD был выбран один и тот же сервис — Google Calendar. Теперь на различных фазах в качестве базовых элементов будут использоваться два разных сервиса — Calendar и Keep — в соответствии с приспособленностью их функционала для отдельных фаз.

• Calendar теперь будет использоваться в качестве базы для фазы обзора (Review-Reflect), а также для фазы выполнения (Do-Engage).
• Keep будет использоваться в качестве базы для фазы сбора (Collect-Capture), фазы обработки (Process-Clarify) и фазы организации (Organize).

Реализация GTD в Google Calendar (развернут список ближайших действий на неделю):


Pеализация GTD в Google Keep (категория ближайших действий):

Скоро новый год, и, как и в прошлом году, одним из самых актуальных вопросов для любой семьи остается вопрос «куда уходят деньги?». Все мы периодически задаемся этим вопросом, и очевидно, что для его решения нужна внутрисемейная финансовая отчетность (как для любой организации). Я пытался использовать бухгалтерские программы desktop, а также мобильные приложения, но так и не нашел подходящего решения. Есть хорошие бесплатные программы, но у них, как правило, нет функции совместного доступа, а платные требуют покупки лицензии для каждого пользователя. Полный набор критериев, который сложился у меня, и который хотелось бы видеть в программе для ведений семейной бухгалтерии:

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

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

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

Постановка задачи

Пусть нам нужно создать программой на языке Python вот такую таблицу:



Особенности этой таблицы:

• задана ширина столбцов;
• верхняя ячейка является объединением A1:E1;
• в некоторых ячейках настроены: формат отображения, размер шрифта, жирность, выравнивание текста и цвет фона;
• значения в последнем столбике вычислены формулой (например, в E4 написано =D4-C4);
• нарисована граница под ячейками A3:E3;
• присутствует Пикачу (но это останется как домашнее задание для энтузиастов).

Интересно? Тогда добро пожаловать под кат.

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

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

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

1. Структура и схема.
2. Представление и доступность.
3. Выбор используемых графиков.
4. Усовершенствование контекста.

Часть 1. Структура и схема

Давайте для начала остановимся и зададим себе два вопроса: кто наша целевая аудитория и каковы её цели?

Знание своей целевой аудитории и её задач критически важно для остальной части работы. Если ваша ЦА — руководители разработки, которым нужно знать высокоуровневую информацию о функционировании системы, то нужные им данные будут сильно отличаться от тех, которые необходимы приходящему инженеру.

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

Автоматизировал задание файловых ассоциаций, то есть выбор программы которая будет открывать файл из Explorer/Finder. И делюсь.

Сначала проблематика. Файлы нужных расширений часто не открываются по умолчанию ничем, а если открываются, то каким-нибудь iTunes. Под windows нужные ассоциации, бывает, и вовсе теряются при установке (или даже деинсталяции) программ: снесёшь, бывало, GIMP, а ico-файлы перешли во владение от привычного просмотрщика файлов к стандартной Photo Gallery. Почему? Зачем? Неизвестно… А если нашёл новый редактор или, по разным причинам, свежая инсталляция? А если компьютер не один? В общем, кликать мышками в диалогах — развлечение такое себе.

Вместо этого я сохранил два файлика на Dropbox и теперь привести компьютерный мир к привычному состоянию можно почти мгновенно. И чего ждал столько лет… Далее рецепт для Windows и macOS.

Эта история случилась в реальной компании, несмотря на то, что некоторые имена и события вымышлены.

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

Все чаще и чаще я слышу от разработчиков и читаю в статьях, что шаблоны проектирования (они же дизайн-паттерны) никому не нужны. Мол, они появились во времена «цветения» UML, RUP, CASE систем и прочих чересчур «сложных» инструментов, подходов и практик. А сейчас самое важное — это код рабочий написать, да побыстрее. На умные толстые книжки ни у кого нет времени, разве что для прохождения собеседования. Тех, кто хочет обсудить данную тему, прошу под кат.

В процессе разработки нескольких Интернет-сервисов мы заметили, что значительная часть их функционала является общей, и руководствуясь принципом DRY (Don't Repeat Yourself — не повторяйся), приняли решение вынести общий функционал в отдельный модуль.

К модулю были предъявлены следующие требования:

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

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



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

Посмотрим как они выкрутятся?

Представьте на минутку обычного программиста. Допустим, его зовут Вася и ему нужно сделать анимированную менюшку на сайт/десктоп приложение/мобильный апп. Знаете, которые выезжают сверху вниз, как меню у окна Windows или меню с яблочком у OS X. Вот такое.

Начинает он с одного выпадающего окошка, тестирует анимацию, выставляет ease out 100% и наслаждается полученным результатом. Но вскоре он понимает, что для того, чтобы управлять менюшкой, хорошо бы знать закрыто оно сейчас или нет. Мы-то с вами тут программисты опытные, все понимаем, что нужно добавить флаг. Не вопрос, флаг есть.

var opened = false;

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

var opened = false;
var animating = false;

function onClick(event) {
  if (animating) return;
  if (opened) close();
  else open();
}

Через какое-то время Васе говорят, что меню может быть полностью выключено и неактивно. Не вопрос! Мы-то с вами тут программисты опытные, все понимаем, что… нужно добавить ЕЩЕ ОДИН ФЛАГ! И, всего-то через пару дней разработки, код меню уже пестрит двустрочными IF-ами типа вот такого:

if (enabled && opened && !animating && !selected && finishedTransition && !endOfTheWorld && ...) { ... }

Вася начинает задаваться вопросами: как вообще может быть, что animating == true и enabled == false; почему у него время от времени все глючит; как тут вообще поймешь в каком состоянии находится меню. Ага! Состояния... О них дальше и пойдет речь.

Знакомьтесь, это Вася.

 

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

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

Заинтересовавшихся прошу под кат.

Знания — Идеи — Созидание

Знание — новая информация посредством которой решается какая то проблема.
Идея — способность видеть проблему и ключ к ее решению.
Созидание — процесс практической реализации идеи.



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

Знания

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

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

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

Хотя метод был разработан и представлен в 2001 году Полом Виолой и Майклом Джонсом [1, 2], он до сих пор на момент написания моего поста является основополагающим для поиска объектов на изображении в реальном времени [2]. По следам топика хабраюзера Indalo о данном методе, я попытался сам написать программу, которая распознает эмоцию на моём лице, но, к сожалению, не увидел на Хабре недостающей теории и описания работы некоторых алгоритмов, кроме указания их названий. Я решил собрать всё воедино, в одном месте. Сразу скажу, что свою программу успешно написал по данным алгоритмам. Как получилось рассказать о них ниже, решать Вам, уважаемые Хабрачитатели!

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