Мне, как практику, сложно понять актуальность изложенных подходов без привязки к конкретным примерам.
Предлагаю написать продолжение статьи с конкретными примерами, с рассказами насколько хорошо/плохо всё это работало на его задачах. Очень полезная будет статья. Спасибо заранее.
Вот только вчера вечером закончил реализацию небольшой библиотеки для многопоточности на С++ для одного кроссплатформенного фреймворка. Класс может работать как автономно, так и использовать пул потоков. Кроме того, в нём есть конвейер на основе очереди исполнения, который сильно уменьшает необходимость в объектах синхронизации, а в простых случаях делает их и вовсе ненужными. И всё это работает стабильнее, и прочее, и прочее.
Я бы с радостью поделился и кодом, и идеями с народом, с радостью бы выслушал критику. Но где взять время для написания статей?.. Всё делается в спешном порядке, для очередных проектов. Нет возможности даже нормально ответить по комментариям к предыдущим статьям.
Вы не путайте идею создать сайт для продажи отвергнутых заказчиком логотипов и монетизацию данного конкретного сайта.
С моей точки зрения, идея хорошая. С тем, что логотипы на сайте — готов согласиться, но не как профессионал, а как обыватель. Цену в данном случае определит рынок, и здесь бы, видимо, помог аукционный подход.
Не совсем так. Поскольку, наверняка, на кадрах берутся общие опорные точки, то отсутствующие части картинки берутся из прошлых кадров, где требуемые исходные точки видны. Проблема в том, что при этом меняется взаимное расположение трёхмерных объектов, т.е. информацию в прошлом кадре недостаточно преобразовать по соответствующим матрицам. Отсюда, кстати, и идёт такой «плавающий» эффект: изображение перспективно «растянуто» иначе, но этого недостаточно для глаза, т.к. он очень хорошо «ловит» мелкие взаимные пересечения объектов трёхмерной сцены.
Выше — не интерфейс, а схема.
Далее.
Люди выберут тот интерфейс, которым удобнее пользоваться. Бесполезные красоты простого пользователя пугают — он не знает куда нажимать. Проверено на практике.
Оператора просто не надо выбирать. По-моему, тут даже обсуждать нечего. Вбил номер — положил деньги. Остальное — «от лукавого».
В нижней части — не поиск, а просто таблица операторов. Никакой виртуальной клавиатуры.
Что касается флешки. На набор номера я трачу ~4 секунды. Дольше доставать флешку и ждать пока она определится. Не говоря уже о потенциальной опасности подхватить вирус.
Большое спасибо что поделились процессом создания интерфейса.
Теперь по существу.
Меня всегда удивляло, зачем терминалам делают такой цветастый, громоздкий, многостраничный интерфейс. Его сложность отпугивает многих, особенно представительниц прекрасного пола. Я уже не говорю о людях постарше. Глядя на всё это многоцветное великолепие, люди просто теряются.
Предлагаю вам упростить интерфейс. Всё нижеследующее — правах «имхо».
Не нужно делать выбор оператора связи. Клиент всё равно вводит код. Код однозначно определяет оператора. Я бы убрал лишний шаг.
Также я бы убрал переход по множеству страниц. Набрали номер телефона. Нам написали: «воткните деньги». Воткнули хоть одну купюру — появилась крупная кнопка «Оплатить». Нажали — отошли. Всё!
Хотите дополнительных возможностей? Поместите их внизу, некрупным, более слабо выделяющимся на более блеклом фоне. Ваш 1% продвинутых клиентов прекрасно их найдёт и разберётся. Остальным они не будут отсвечивать.
Итого, 1 основная страница, на которой будут сидеть почти все. Удобно ведь!
Думаю если бы в самой Америке всё было так безоблачно как Вы говорите, и спрос на стартапы «на стороне» (как Вы выразились) отсутствовал, ни какой речи о подобном постановлении не было бы.
Скажу больше. Поскольку американские сенаторы сначала выдвинули такой законопроект, а через год снизили планку входа, то скорее всего это означает что необходимость во внешних стартапах только растёт.
На мой взгляд, отличие в софте — родном и дополнительном.
К сожалению, открытые платформы пока не могут похвастаться таким качеством (да и количеством тоже) программ.
Также хочу отметить, что обе основные платформы (одна формально открытая, другая формально закрытая) имеют довольно серьёзные проценты с продаж программ сторонних производителей. Что само по себе «не айс».
Если данные будем хранить в контейнере с авто-удалением (см. статью), то память не утечёт, даже если колбэк не будет вызван.
В случае, если диспетчирование не нужно, я готов согласиться с тем, что следовало бы без фанатизма по отношению к этому подходу, спокойно передать в конструктор потока указатель в обёртке вроде smart_ptr (не shared_ptr!).
К сожалению, в реальной жизни всё оказывается сложнее. Как правило, мы не готовы качать «сколько угодно» больших кусков в память за раз. Имея контейнер, мы всегда можем регулировать, сколько единиц данных и какого размера у нас открыто (и кому-то придётся постоять в очереди — это лучше чем нехватка памяти или дикий своп). Диспетчирование будет очень полезно при отладке: оно упростит отслеживание возможных утечек памяти.
Резюмирую. Ваша реализация через smart_ptr — гораздо легче shared_ptr, что делает его хорошей альтернативой моему подходу в простом случае.
То что предлагаю здесь я, не намного лучше или хуже использования умного указатель без подсчёта ссылок — в общем случае. В реальной жизни, я бы воспользовался любым из них, в зависимости от необходимости диспетчирования.
Предлагаю написать продолжение статьи с конкретными примерами, с рассказами насколько хорошо/плохо всё это работало на его задачах. Очень полезная будет статья. Спасибо заранее.
Я бы с радостью поделился и кодом, и идеями с народом, с радостью бы выслушал критику. Но где взять время для написания статей?.. Всё делается в спешном порядке, для очередных проектов. Нет возможности даже нормально ответить по комментариям к предыдущим статьям.
С моей точки зрения, идея хорошая. С тем, что логотипы на сайте — готов согласиться, но не как профессионал, а как обыватель. Цену в данном случае определит рынок, и здесь бы, видимо, помог аукционный подход.
Желаю вам успеха.
Далее.
Люди выберут тот интерфейс, которым удобнее пользоваться. Бесполезные красоты простого пользователя пугают — он не знает куда нажимать. Проверено на практике.
Оператора просто не надо выбирать. По-моему, тут даже обсуждать нечего. Вбил номер — положил деньги. Остальное — «от лукавого».
В нижней части — не поиск, а просто таблица операторов. Никакой виртуальной клавиатуры.
Что касается флешки. На набор номера я трачу ~4 секунды. Дольше доставать флешку и ждать пока она определится. Не говоря уже о потенциальной опасности подхватить вирус.
Схематично это бы выглядело так:
Теперь по существу.
Меня всегда удивляло, зачем терминалам делают такой цветастый, громоздкий, многостраничный интерфейс. Его сложность отпугивает многих, особенно представительниц прекрасного пола. Я уже не говорю о людях постарше. Глядя на всё это многоцветное великолепие, люди просто теряются.
Предлагаю вам упростить интерфейс. Всё нижеследующее — правах «имхо».
Не нужно делать выбор оператора связи. Клиент всё равно вводит код. Код однозначно определяет оператора. Я бы убрал лишний шаг.
Также я бы убрал переход по множеству страниц. Набрали номер телефона. Нам написали: «воткните деньги». Воткнули хоть одну купюру — появилась крупная кнопка «Оплатить». Нажали — отошли. Всё!
Хотите дополнительных возможностей? Поместите их внизу, некрупным, более слабо выделяющимся на более блеклом фоне. Ваш 1% продвинутых клиентов прекрасно их найдёт и разберётся. Остальным они не будут отсвечивать.
Итого, 1 основная страница, на которой будут сидеть почти все. Удобно ведь!
стульяденьги, нанять пятерых американских моделей, после чего вернуться и спокойно работать на Родине?Скажу больше. Поскольку американские сенаторы сначала выдвинули такой законопроект, а через год снизили планку входа, то скорее всего это означает что необходимость во внешних стартапах только растёт.
К сожалению, открытые платформы пока не могут похвастаться таким качеством (да и количеством тоже) программ.
Также хочу отметить, что обе основные платформы (одна формально открытая, другая формально закрытая) имеют довольно серьёзные проценты с продаж программ сторонних производителей. Что само по себе «не айс».
youtube.com/watch?v=F0m-X_ORUhQ
В случае, если диспетчирование не нужно, я готов согласиться с тем, что следовало бы без фанатизма по отношению к этому подходу, спокойно передать в конструктор потока указатель в обёртке вроде smart_ptr (не shared_ptr!).
К сожалению, в реальной жизни всё оказывается сложнее. Как правило, мы не готовы качать «сколько угодно» больших кусков в память за раз. Имея контейнер, мы всегда можем регулировать, сколько единиц данных и какого размера у нас открыто (и кому-то придётся постоять в очереди — это лучше чем нехватка памяти или дикий своп). Диспетчирование будет очень полезно при отладке: оно упростит отслеживание возможных утечек памяти.
Резюмирую. Ваша реализация через smart_ptr — гораздо легче shared_ptr, что делает его хорошей альтернативой моему подходу в простом случае.
То что предлагаю здесь я, не намного лучше или хуже использования умного указатель без подсчёта ссылок — в общем случае. В реальной жизни, я бы воспользовался любым из них, в зависимости от необходимости диспетчирования.