Я признаю, что услуга уникальна просто потому, что услугу оказывает человек, а человеческий фактор хуже рандома :) Но на самом деле, мы тут говорим скорее о сложных услугах. Прокатить человека на маршрутке, конечно, можно по-разному, но по результату услуга мало чем будет отличаться. В принципе, даже сантехник одну и ту же работу может выполнить с разным уровнем качества. Но для простых услуг эти погрешности не так важны клиенту, поэтому смысла рассматривать их нет.
Мне больше нравится вот этот ход мыслей:
Более того, ведь если бизнес не может отказаться от клиента, то это значит, что бизнес супер сильно связан с потоком клиентов, он не находится в стабильности и здесь явно что-то не так. Для бизнеса это крайне печальный вариант.
Правило, что заказов всегда должно быть больше, чем бизнес может обработать.
К тому, что для клиента эта услуга неуникальна в большинстве случаев. В силу того, что он пользуется ей один раз и о качестве исполнения узнаёт постфактум. Он начинает сравнивать только если заказывает ещё раз ту же самую услугу. У него уже есть опыт, и он видит различия между «сантехниками», хотя для выработки правильных критериев выбора ему потребуется много попыток.
Но до того, как услуга будет исполнена, он знает только, что есть 80 сантехников, которые вроде все профессионалы, и могут починить его кран за 500 рублей. И поэтому для него услуга неуникальна.
Илья, верно, что каждая услуга уникальна. Но как клиент узнает, чем эти 80 сантехников, которые «отремонтируют кран, что он не будет течь и возьмут за это 500р» отличаются друг от друга? Как он узнает это до того, как выберет конкретного сантехника для починки своего крана?
В JavaScript прорва возможностей — он действительно очень гибок. Мое личное мнение — надо использовать свой набор библиотек под конкретный проект, и принимать определенные Code Style Conventions. Но, конечно, в моих проектах никогда не было миллиона строк кода =)
Есть приложение TimeLogger2 для iOS. Насчет андроид не в курсе. Думаю, оно не одно такое. Пользуюсь примерно месяц, и скажу честно — через какое-то время оно само отнимает время (забыл отметить, что делаешь — приходится высчитывать), но чтобы самоорганизоваться в начале — может быть полезным
Я занимаюсь всем — и вебом, и мобильными приложениями. И не считаю никакую из этих областей для себя трудными ;) Но имею возможность сравнивать. Понятно, что для команды разработчиков вкупе с дизайнером никакая задача не будет трудной. Вопрос только в том, что затраты на разработку интерфейсов мобильных приложений возрастают из-за дробления разновидностей устройств.
Да, конечно, мобильные сайты и мобильные приложения — это почти одно и то же (думаете вы). Но все же, в мобильных приложениях намного больше интерфейса, это не сайты, где можно применить responsive design, например, и все будет выглядеть зашибись.
Мы создаем столько же вариантов графики, и вопрос как раз в том, как скоро этого перестанет хватать, и как много вариантов разрешения экрана нам еще предстоит увидеть.
В игровых приложених все проще, да. И кроме того, можно задать минимальные требования, чтобы упростить задачу, и не делать приложение для тех пользователей, которым оно все равно не нужно.
Приложения под десктоп пишутся под одну ось, или на одной мультиплатформе, и как правило используются «резиновые» решения. Эти резиновые решения, так же как и в вебе, одинаково работают на всех вариантах разрешения экрана.
На мобильных же платформах есть существенное отличие: маленький экран и сильно ограниченная оперативная память. Что создает проблемы при создании приложений с большим кол-вом графики и/или неординарным дизайном, который довольно сложно масштабировать при разрешениях от 320х240 до 1280х800.
Статья как раз о том, что это сложно для маленьких независимых разработчиков. Понятно, что это без проблем могут себе позволить крупные компании.
Нет, оно рационально для любых таблиц, содержимое которых берется большими кусками в отсортированном виде. Если даже будут новые данные, кол-во поисков по диску все равно будет существенно меньше, чем если утилиту не использовать.
Спасибо, исправил (скопировал опечатку с первоисточника).
Индекс не будет использоваться, но сами подумайте, какие возможности существуют с функциональным индексом! Вы можете, например, написать свою функцию, которая будет определять вес записи по некоторым из ее полей, и сортировать по этому весу.
Кстати, подсказка. В тех СУБД, в которых нет функциональных индексов, вы можете создать отдельное поле для результата функции, и при создании/редактировании записи вычислять и записывать новое значение этого поля. Тогда заменой функционального индекса будет простой индекс по этому полю.
Никак не пойму, зачем было переходить с Node.js на Python
Мне больше нравится вот этот ход мыслей:
Правило, что заказов всегда должно быть больше, чем бизнес может обработать.
p.s. не узнал меня что ли?)
Но до того, как услуга будет исполнена, он знает только, что есть 80 сантехников, которые вроде все профессионалы, и могут починить его кран за 500 рублей. И поэтому для него услуга неуникальна.
Мы создаем столько же вариантов графики, и вопрос как раз в том, как скоро этого перестанет хватать, и как много вариантов разрешения экрана нам еще предстоит увидеть.
На мобильных же платформах есть существенное отличие: маленький экран и сильно ограниченная оперативная память. Что создает проблемы при создании приложений с большим кол-вом графики и/или неординарным дизайном, который довольно сложно масштабировать при разрешениях от 320х240 до 1280х800.
Статья как раз о том, что это сложно для маленьких независимых разработчиков. Понятно, что это без проблем могут себе позволить крупные компании.
Индекс не будет использоваться, но сами подумайте, какие возможности существуют с функциональным индексом! Вы можете, например, написать свою функцию, которая будет определять вес записи по некоторым из ее полей, и сортировать по этому весу.
Кстати, подсказка. В тех СУБД, в которых нет функциональных индексов, вы можете создать отдельное поле для результата функции, и при создании/редактировании записи вычислять и записывать новое значение этого поля. Тогда заменой функционального индекса будет простой индекс по этому полю.
Возможно, у вас баттхерт оттого, что вы не смогли вычислить аккаунты автора в социальных сетях и блогах?