Развитие начинающей компании в XXI веке

Отправлено 14 июл. 2020 г., 02:53 пользователем Deni Baskovsky   [ обновлено 14 июл. 2020 г., 02:55 ]

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

Организация

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

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

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

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

Оплата

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

Контракт

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

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

Алгоритм планирования по З.А.С.О.С.'у

Отправлено 6 июл. 2020 г., 20:36 пользователем Deni Baskovsky   [ обновлено 6 июл. 2020 г., 20:36 ]

Представим, что вы делаете сценарий презентации используя планинг из статьи.
  1. Замечание. Допустим, вы пошли покурить в парк и вам пришла в голову хорошая идея фотографии для презентации. Вы занесли ее в заметки.
  2. Абстрагирование.После прогулки вы пришли домой, включили компьютер, открыли директорию "Презентация", в ней создали директорию "Картинки", куда скопировали отснятый материал. В комментарии презентации добавили текстовые сообщения.
  3. Слияние.Спустя пару часов работы, вы включили MindBox и начали приводить в порядок свою директорию "Презентация". Прочитанные идеи сформировались в узлы MindBox. Часть из них обросла согласуемыми между собой связями. После чего, сценарий написания презентации становится понятным.

    Зачем же еще нужны оставшиеся два пункта? Ответ прост: для организация проделанной работы. Дело в том, что задачи обычно нельзя сделать за один день, их требуется разбить на несколько маленьких задач и следить за прогрессом.Пойти покурить является пунктом в обязательстве "бросить курить", а прогуляться по парку пунктом "проводить больше времени на свежем воздухе". В первом случае пункт был проигнорирован и составлен штраф; во втором случае, пункт был успешно выполнен.
Этот алгоритм в ProstoDiary выполняется в обратной последовательности.
  1. Виртуальный ассистент устройства (читай: Siri) оповещает пользовательского бота об изменении свойства "Location" во время нахождения в парке.
  2. Бот анализирует кучу оповещений (читай: включая подключенных сторонних ассистентов, таких как "HealthAssistant - лечащий врач"), выявляя ранее заданные обязательства (читай: "бросить курить" и "проводить больше времени на свежем воздухе").
  3. Бот изучив кучу, формирует семантический граф (читай: внешне похожий на ментальную карту, только машиночитаемый) и публикует его на закрытом стенде.
  4. Подключенные внешние ассистенты получают возможность использовать открытые только для них узлы (читай: для своих ML).
  5. Итоговым результатом которых, становится Замечание - уведомление, значащее по-сути, переосмысленную машиной идею.

goto Interactive Software.app

Отправлено 3 июл. 2020 г., 21:54 пользователем Deni Baskovsky

С последними правками прилетела PWA версия для AMP сайта. Благодаря чему появился совершенно новый пользовательский опыт работы с сайтом. AMP кэшируется в поисковой выдаче, а после того как пользователь зайдет на страницу через Service Worker закэшируеются статические ресурсы в память браузера для оффлайн работы. 
Размер приложения составляет 571кб.

Информация про файлы и ссылки в сети

Отправлено 21 июн. 2020 г., 22:16 пользователем Deni Baskovsky

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

Прежний сценарий вида URL → FILE (TEXT/Binary) заменяется на новый URL → Document (JSONLD) → FILE (Binary).

- Что это значит для ProstoDiary?
Файлы не будут сохраняться, все ресурсы будут оставаться в том приложении ассистенте, где они были созданы. Для разработчиков ассистентов это значит что можно не присылать боту ProstoDiary этот файл, ограничившись только проверенным документом JSONLD.

- Каким образом другие приложения станут отправлять документы JSONLD?
В более ранней статье я обозначил путь для внедрения интерфейса OpenAPI построенного на Action Schema.org.

- Что если File перестанет хостится в приложении?
Пользователь не сможет получить “сырые данные”, но у него останется вся история будто они есть. Это значит, например, что загруженная фотография исчезнет, но через бота можно будет узнать: погоду в момент снимка, число людей на снимке, и прочую метаинформацию. Возможно в будущем слияние множества метаинформации будет способно воссоздать утерянную фотографию.

Идея: рейтинг доверия

Отправлено 19 июн. 2020 г., 22:07 пользователем Deni Baskovsky   [ обновлено 19 июн. 2020 г., 22:30 ]

На базе ProstoDiary хочу сделать функционал пристального наблюдения долговых обязательств. 

К примеру, некто N берет у M в долг в $100. После чего эта сумма маркируется всеми следующими финансовыми транзакциями M, таким образом, что продавец K видит в M должника с рейтингом доверия 3 бала (этот рейтинг увеличивается если должник вовремя возвращает свой долг и наоборот уменьшается в противном случае). В случае падения рейтинга до уровня в 2 бала, N может отправить запрос-просьбу на ограничение продажи M продавцам. Допустим, K продавец знаком с N кредитором и соглашается ему помочь (в таком случае он может повысить свой социальный рейтинг, о нем позже). В этом случае M становится ограниченным для совершения покупок у K до тех пор, пока M не поднимет свой рейтинг (отправка N $100).

Технически реализовать это уже возможно, цифровизация в РФ достигла более-менее нормального уровня. Теперь благодаря ботам вполне можно автоматизировать проверку в ФФСП.

P.S. Причины по которым описанное выше не делается на законодательном уровне вполне ясны. Но я считаю, что именно предприниматели используя свои идеи должны добиваться изменения законов от власти, никак не наоборот.

Идея приложения: Счетчик факапов

Отправлено 17 июн. 2020 г., 22:53 пользователем Deni Baskovsky

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

ProstoDiary: OpenAPI + JSON-LD

Отправлено 14 июн. 2020 г., 23:35 пользователем Deni Baskovsky   [ обновлено 14 июн. 2020 г., 23:47 ]

C обновлением Public API v5 используется новый механизм передачи сообщений. 

Идея: совместить текущий JSON RPC 2 с JSON-LD для будущего оформления всего этого добра через стандарт OpenAPI.

Суть: любой внешний ассистент сможет загружать/выгружать валидный JSON и декодировать его результаты для наполнения собственной онтологии API используя schema.org. Тем самым, появится типизация параметров для генерации новых запросов.

Плюсы: возможность более четкого понимания клиент-серверного общения; будущая возможность обучения ИИ для клиент-серверного взаимодействия.

Минусы: дополнительная нагрузка на передачу и парсинг данных. 

Пример:
curl -X POST \
-H "Verification: $MARKETPLACE_SIGN" \
-H "Authorization: Bearer $JWT_TOKEN" \
-H "Content-Type: application/json" \
-H "Accept: application/schema+json" \
--data '{"jsonrpc":"2.0","method":"ping","params": $ACTION_JSONLD,"id":1}' \
http://127.0.0.1:9000/api

Где MARKETPLACE_SIGN - ключ подключенного ассистента;
JWT_TOKEN - токен приложения;
ACTION_JSONLD - вида:
{
'@context': {
      mainEntity: 'schema:mainEntity',
      schema: 'http://schema.org/',
      agent: 'schema:agent',
      name: 'schema:name',
      startTime: 'schema:startTime',
      object: 'schema:object',
      target: 'schema:target',
      result: 'schema:result',
      actionApplication: 'schema:actionApplication',
      subjectOf: 'schema:subjectOf',
      abstract: 'schema:abstract',
      description: 'schema:description',
      instrument: 'schema:instrument',
      encodingFormat: 'schema:encodingFormat',
      identifier: 'schema:identifier',
      provider: 'schema:provider',
      participant: 'schema:participant',
      value: 'schema:value',
      url: 'schema:url',
      email: 'schema:email',
      geo: 'schema:geo',
      addressCountry: 'schema:Country',
      addressLocality: 'schema:Text',
      addressRegion: 'schema:Text',
      streetAddress: 'schema:Text',
      postalCode: 'schema:Text',
      address: 'schema:address',
      latitude: 'schema:latitude',
      longitude: 'schema:longitude'
    },
    '@id': 'https://t.me/chat#100326480',
    agent: { '@type': 'Organization', email: 'tg@gotointeractive.com' },
    participant: { '@type': 'Organization', email: 'posrednik@example.com' },
    startTime: '2020-06-15',
    instrument: {
      '@type': 'Thing',
      name: 'Core',
      url: 'https://github.com/gotois/core'
    },
    target: { '@type': 'EntryPoint', actionApplication: [Object] },
    '@type': 'AllocateAction',
    name: 'Ping',
    result: {
      '@type': 'CreativeWork',
      encodingFormat: 'text/plain',
      mainEntity: [Array]
    },
    'https://w3id.org/security#proof': { '@graph': [Object] }
}

Свершилось! Презентация ProstoDiary

Отправлено 14 июн. 2020 г., 07:19 пользователем Deni Baskovsky   [ обновлено 14 июн. 2020 г., 12:36 ]

Как говорят венчурные инвесторы: "У стартапера в наличии всегда должно быть два готовых инструмента: краткий питч и презентация проекта". Презентация, хоть и далека от канонов, зато готова. Как тут не вспомнится, что самая большая сложность в реализации любого проекта - побороть собственное неверие <в успех>. Всё прочее - небольшие трудности, которые решаются обыкновенным регулярным трудом.

Немного исторических фактов.
Перед презентацией дочитал книгу "Визуальное Мышление", которую купил еще в 2014 ради того, чтобы сделать презентацию "Qweeto". Книга пылилась 6 лет, но она того стоит, прочтите.

node-fatsecret

Отправлено 30 мая 2020 г., 10:18 пользователем Deni Baskovsky

На npm доступна моя либа node-fatsecret. Собрал пакет из прежнего FoodAssistant'a. Из интересного, либа написана с использованием нового стандарта модулей - mjs. 
Ниже демонстрация поиска продукта "mango". 

Foods table

Отправлено 30 мая 2020 г., 06:25 пользователем Deni Baskovsky   [ обновлено 30 мая 2020 г., 06:26 ]

Прикладываю наработки по Food assistant'у.

Шаг 1: Создаем таблицу

CREATE UNLOGGED TABLE IF NOT EXISTS foods (
  id SERIAL PRIMARY KEY,
  title TEXT UNIQUE,
  protein NUMERIC (5, 2) default NULL,
  fat NUMERIC (5, 2) default NULL,
  carbohydrate NUMERIC (5, 2) default NULL,
  kcal NUMERIC (5) default NULL
);

-- Хранимая процедура поиска по title мультиязычно
CREATE OR REPLACE FUNCTION to_tsvector_multilang (title TEXT) RETURNS tsvector as $$
SELECT to_tsvector('russian', $1) ||
       to_tsvector('english', $1) ||
       to_tsvector('simple', $1)
$$ LANGUAGE SQL IMMUTABLE;

-- Полнотекстовый поиск по тайтлу
CREATE INDEX idx_gin_foods ON foods USING GIN (to_tsvector_multilang(title));

Шаг 2: Импортируем CSV файл

Шаг 3: Выполняем запрос

SELECT id, title, protein, fat, carbohydrate, kcal FROM foods
WHERE to_tsvector('russian', title) @@ plainto_tsquery('russian', 'Вермут');


БД содержит 522 элемента. Получить все необходимые данные можно на gist.

1-10 of 218