Category: финансы

Category was added automatically. Read all entries about "финансы".

flow

Утечки информации

Увидел очередное упоминание старого трика, как владельцы могут отслеживать упоминания своих сайтов в чужой закрытой корпоративной переписке, теперь из мессенджеров типа Slack: http://justinjackson.ca/slack/

Сейчас не девяностые, и современные браузеры давно поддерживают rel="noreferrer", надёжно и полностью закрывающий эту дыру. Но в том же Slack есть только возможность включить доисторический фикс с blind redirect, который по дефолту выключен.
flow

Управление с помощью воображения

Нашёл проект на кикстартере, цель - финансирование серийного производства датчика мыслей:
http://www.kickstarter.com/projects/tanttle/emotiv-insight-optimize-your-brain-fitness-and-per

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

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

Пока с такими "словарями" проблема даже при управлении голосом. Редактирование текста с помощью голоса в MS Word крайне затруднено, а системы вроде Siri являются стабильным источником анекдотов. Однако, и здесь есть подвижки: Using Python to Code by Voice ( https://www.youtube.com/watch?v=8SkdfdXWYaI ). Чем больше подобной деятельности (включая простейшие словарики из магических слов "туды", "сюды" и "кыш" для чтения френдленты), тем больше опыта в этой области, будет увеличиваться количество удобных массовых решений.

Так и в управлении силой мысли. Открывающиеся возможности того будущего, которое уже сейчас. Главное, чтобы оставалась надёжная физическая кнопка Undo. Иначе сон разума приведёт к привычным последствиям.
flow

Код это не активы

Недавно читал историю проекта OS/2, операционной системы от IBM, которая некоторое время позиционировалась как альтернатива Windows. Забавный факт - разработчики и менеджеры гордились большим количеством строк кода, сравнивали, соревновались. Подобные "специальные олимпиады", как и любые другие тенденции, ведущие к увеличению количества кода, десятилетиями гробят большие и малые проекты. До среднеменеджеров долго доходит, что код это не активы.

Я ненавижу программировать. И другим не даю. Код хорош в research, быстро приходит и быстро уходит. В production он остаётся висеть вечным грузом.

Каждая строчка исходника (на выбранном вами языке программирования) или датасета это расходы, кредит с процентами. Постоянные затраты на осознание, отладку, поддержку, модернизацию. Это _всегда_ минус. Плюсы проявляются косвенно - счастье пользователя (не путать с количеством фич), прибыль бизнеса (не путать со счастьем пользователя), etc. Или не проявляются вообще.

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

С кодом ещё хуже. Требуется на порядки больше когнитивных ресурсов на понимание и изменение. Кроме того, есть ещё один множитель расходов - методологии. Чем больше методологий в проекте, тем дороже любое наблюдение или модернизация. Каждый новый класс со своей спецификой getElementByPos или addEventHandler, каждый модификатор private - это отдельный гвоздь в крышку гроба вашего проекта. Должны быть люди, осознающие пространство и время вашего приложения или сервиса, целиком, иначе проект становится непознаваемым и неконтролируемым. Подход "на каждый класс по индусу" не спасает, не возвращает контроля за ситуацией. Помогает только замена классов на общие структуры данных, а обилия методологий на одну (или небольшой набор).

Можно сократить код и данные. Заменить несколько страниц кода на компактную таблицу коэффицентов. Или наоборот, таблицу на выражение-однострочник. Главное - не плодить методологии. В этом смысле полезны EDSL, так как позволяют минимизировать количество кода, и, при этом, всё же интегрировать работу с данными своей предметной области в общую методологию проекта. Но вредны DSL, так как заведомо привносят отдельные методологии.

Сторонний код это тоже расходы. Новые методологии (сразу), а также риск того, что его тоже придётся отлаживать и дописывать/допиливать самостоятельно. Как пример срабатывания риска, любое современное middleware в области GUI вам придётся допиливать и обходить баги, будь оно хоть бесплатное, хоть покупное-с-поддержкой.

Кроме того, сторонние технологии могут стать лимитирующим фактором. Если плохие методологии и Java-style-overengineering это просто увеличение расходов, то использование Eclipse platform это гарантия дерьмового пользовательского интерфейса в вашем продукте. Впрочем, увы, слишком много факторов могут стать такой же гарантией.

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

Управленческое

По мотивам
http://ailev.livejournal.com/1066861.html
и
http://vitus-wagner.livejournal.com/844634.html

При каких условиях крупные организации могут сохранять работоспособность:

1. Прозрачность.

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

2. Ответственность.

Решения принимают люди. Если надо принять решение, для которого нет полномочий - придётся идти к начальству, это понятно. Однако, при бюрократии люди прикрываются инструкцией - "я только забиваю гвозди, как написано в бумажке, что они плохо скрепляют не моя проблема". У любой инструкции есть авторы (подписи, печати, ...). Если инструкция противоречит реальности или просто неэффективна, то ответственность любого исполнителя минимизировать потери и оповестить непосредственное начальство о ситуации. В наш цифровой век - желательно задачей в глобальной issue tracking system, с соответсвующим тэгом о необходимости корректировки регламентов компании. Далее задача может привести или не привести к изменению инструкций, или вообще быть отправлена наверх, если на данном уровне недостаточно полномочий. Однако, любое решение или не-решение на личной ответственности менеджера. И топ-менеджеры тоже будут отвечать перед советом директоров.

3. Скорость.

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