С примерами я могу помочь, поскольку тоже этим занимался. :)
Например, юзер может ввести:
— московская о, пушкино, пушкина 15-3-123
или даже еще проще
— пушкино пушкина 15-4-123
1. Пушкина — это улица или ошибка написания города? Если ошибка, то какая? Человек спутал о и а (пушкино/пушкина) или добавил случайно букву (пушкин/пушкина)?
2. Пушкино — это город? Село? Поселок? В какой области?
Или например,
— пушкино, тургенева 18а
Это именно «город Пушкино, ул. Тургенева, д18а» или «город Пушкино, мкр. Заветы Ильича, ул. Тургенева, д18а». Оба объекта находятся рядом, но имеют разный почтовый индекс и разные почтовые отделения. Местный, проживающий во втором адресе, как ни странно, скорее напишет первый адрес.
В этом кейсе ни приоритет, ни тип не сработают. Надо смотреть, какой номер дома завел клиент, и исходя из этого уже определять какой адрес он ввел. Но и этот способ не позволяет проверить достоверно — что же хочет клиент, если он ввел номер дома, например, д3.
Так что задача не тривиальна, а пример с пушкино выше поиск на n-gramm'ах даже близко не дает удовлетворительный результат.
Видимо, надо вытереть ноги, что бы не попасть под обвинение: «мы тебя уважили, чистое полотенце положили, а ты нас не уважил, не воспользовался нашим подарком?»
Видимо, надо вытереть ноги, что бы не попасть под обвинение: «мы тебя уважили, чистое полотенце положили, а ты нас не уважил, не воспользовался нашим подарком?»
Не всегда. Пример, компания где я работаю (федеральный оператор связи (не Ростелеком :) ). Есть бюджет ИТ. Финблок дает его увеличивать ежегодно в определенных пределах, привязанных к инфляции и объему абонентской базы. Что происходит внутри — никто толком не знает. ИТ-директор может купить 10 компьютеров для рабочих мест, а может вот такую байду, как описано в этой статье.
Делал я когда-то такое для себя (тыц). Даже периодически думаю реанимировать.
Идея (точнее даже реализация) заглохла в силу нескольких причин:
— появились весьма удобные офлайн-читалки на мобильных устройствах;
— появление в метро Wi-Fi и вообще большая доступность в метро Интернета;
— поймал себя на мысли, что скорее буду заново искать контент, чем обращаться к сохраненному (это сугубо моя индивидуальность, у меня даже «Избранное» браузера пустое).
Если же говорить о чем-то подобном в контексте ограничения доступа на работе, то есть масса способов его обойти. Самый простой — читать Хабр на мобильном устройстве. :) По косвенным признакам Вы из Москвы. Мобильный интернет сейчас дешев.
Нет, вопрос не в детском «а баба яга против». У меня сейчас есть несколько сервисов на зарубежных площадках. И по сути, у меня есть два варианта:
— нести затраты и делать телодвижения по их переносу и миграции данных в РФ
— поднять максимально дешевый слейв базы за недорого
Второй вариант очевидно дешевле. Это сродни тому, что в ответ на требование иметь «Уголок потребителя» в розничной точке, я просто повешу на крючок на веревочке книгу жалоб и предложений и привяжу к ней огрызок карандаша. Формально все выполнено.
Тут будет вопрос о том, кто несет бремя доказательства. Например, надзор предъявляет обвинение в хранение данных за рубежом. В теории, они должны это доказать (бремя доказательства на стороне обвинения). Но, в качестве доказательства они легко напишут, что обвиняемый не смог предоставить доказательства того, что база не в России. И при нынешнем состоянии наших судебных институтов это более чем проктит.
Следовательно, придется все равно открывать доступ, чтобы доказать свою позицию.
Увы. Смотрите мой комментарий выше. бекап не является "… базой данных, с использованием которой осуществляется обработка (извлечение, хранение)......".
У меня была такая же мысль. Но в законе четко прописано, что в РФ должны быть именно "… базы данных, с использованием которых осуществляется обработка (извлечение, хранение).....". Но и здесь есть тонкость. Я например, планирую поднять просто slave на дешевом россйском хостинге. А дальше, пусть надзор сам доказывает, что это не основная база данных. :)
То есть web-сервер, master-база, все скрипты — будут по прежнему, в Европе, и slave — в РФ. Букве закона это будет соответствовать, а духу… я не голосовал за нынешних, и у меня нет никаких моральных обязательств по отношению к ним. :)
Не всегда хочется просто использовать калькулятор. Иногда хочется посмотреть, что внутри, тогда доверия будет больше. :) Данная статья просто еще и раскрывает тему. Не слишком детально, может быть, тема действительно необъятна, но все же. :)
Зря Вы так. Вопросы поиска инвестора — тяжелые, а молодые специалисты не зная эту кухню, могут долго тыкаться в разные стороны, даже не понимая, почему их питчи не удачны. Эта статья описывает все правильно, и если кто-то рассмотрит ее как практическое пособие — то получит хорошую временную фору перед теми, кто воспримет ее теоретически.
Я согласен с автором насчет длинных презентаций, демо-продуктов, потенциальных покупателей. По моим наблюдениям, инвесторы лучше всего клюют на следующую «наживку» :) (в порядке приоритета):
— наличие потенциальных покупателей (идея + ретейловая сеть лучше, чем просто готовый продукт, даже в продакшн)
— команда (нужно иметь одного-двух с опытом успешного стартапа — это значительно повышает внимание инвестора)
— каналы продаж (если инестор поверит в их наличие и их масштабируемость — шансы высоки)
— готовый продукт в коммерции
— готовое демо (на уровне бетта-версии с основным функционалом)
Все остальное, на мой взгляд, в том числе просто идея, скриншоты, архитектура, технологии — практически не интересуют.
В опросе много сторон. :) Их можно свести в две категории — те, кто отвечает за стабильность решения и его архитектуру, и те, кто отвечает за продукт на рынке. Первые скажут про оптимизацию кода, и приведение его в модульное, расшияремое и поддерживаемое состояние. Вторые — скажут, фигня вопрос, все закрывайте заплатками, наращиванием железа. Главное — быстрее выпустить пресс-релиз о новой версии. Я это часто слышу в формулировке: «Ты же понимаешь, без нового функционала мы не можем проводить продвижение. А твой рефакторинг — он же ничего не меняет для клиента. Зачем ты это делаешь»
Эта история проще решается с помощью внешних GPS логгеров. Они работают по 5-6 часов и не сажают смартфон. У меня была в свое время мечта, чтобы кто-нибудь умел вытаскивать координаты из iPhone, которые он хранит практически всю жизнь, и пишет их в лог без уменьшения работы батарейки. Но увы. Так ничего на эту тему не появилось. А программный GPS logger сажал мой iPhone поначалу примерно за 1-1,5 часа.
Конечно, векторизируются, если они сделаны как генерируемые градиенты. Но я думаю, вот в чем дело.
У меня есть приложение, которые мне разрабатывали на заказ. Когда я сменил разработчиков, выяснились интересные подробности — оказалось, что приложение было просто нарезкой PSD-файла. То есть когда открывалось окно, все элементы на нем — кнопки, поля, и прочее — были рисунки, поверх которых как-то накладывалась логика. В принципе, я допускаю, что когда разработка идет не «для себя», а «для дяди», то проще и быстрее градиент (как пример) сделать просто растровой картинкой.
Далее можно представить ход рассуждений инженерной мысли. Если такой подход практикуется широко (а например, Apple прекрасно на этапе модерации знает архитектуру приложений в AppStore) — то тогда при выпуске телефонов с большим экраном и другим числом пикселей, придется масштабировать растр. При этом складывается парадоксальная ситуация — делать лучшую Ретину, и получить смазанные изображения. Это будет удар не по разработчикам нативных приложений, а по Apple. В момент старта новой модели многие могут сказать: фи, на пятерке качество на порядок лучше.
Соответственно, понимая что в перспективе придется переходить на большие экраны, выгодно поколением раньше перейти на векторную ОС, приложения для которой могут масштабироваться без потери качества. Более того, даже если кнопку сделают картинкой, но плоской, то она растянется без видимых искажений.
Например, юзер может ввести:
— московская о, пушкино, пушкина 15-3-123
или даже еще проще
— пушкино пушкина 15-4-123
1. Пушкина — это улица или ошибка написания города? Если ошибка, то какая? Человек спутал о и а (пушкино/пушкина) или добавил случайно букву (пушкин/пушкина)?
2. Пушкино — это город? Село? Поселок? В какой области?
Или например,
— пушкино, тургенева 18а
Это именно «город Пушкино, ул. Тургенева, д18а» или «город Пушкино, мкр. Заветы Ильича, ул. Тургенева, д18а». Оба объекта находятся рядом, но имеют разный почтовый индекс и разные почтовые отделения. Местный, проживающий во втором адресе, как ни странно, скорее напишет первый адрес.
В этом кейсе ни приоритет, ни тип не сработают. Надо смотреть, какой номер дома завел клиент, и исходя из этого уже определять какой адрес он ввел. Но и этот способ не позволяет проверить достоверно — что же хочет клиент, если он ввел номер дома, например, д3.
Так что задача не тривиальна, а пример с пушкино выше поиск на n-gramm'ах даже близко не дает удовлетворительный результат.
Идея (точнее даже реализация) заглохла в силу нескольких причин:
— появились весьма удобные офлайн-читалки на мобильных устройствах;
— появление в метро Wi-Fi и вообще большая доступность в метро Интернета;
— поймал себя на мысли, что скорее буду заново искать контент, чем обращаться к сохраненному (это сугубо моя индивидуальность, у меня даже «Избранное» браузера пустое).
Если же говорить о чем-то подобном в контексте ограничения доступа на работе, то есть масса способов его обойти. Самый простой — читать Хабр на мобильном устройстве. :) По косвенным признакам Вы из Москвы. Мобильный интернет сейчас дешев.
— нести затраты и делать телодвижения по их переносу и миграции данных в РФ
— поднять максимально дешевый слейв базы за недорого
Второй вариант очевидно дешевле. Это сродни тому, что в ответ на требование иметь «Уголок потребителя» в розничной точке, я просто повешу на крючок на веревочке книгу жалоб и предложений и привяжу к ней огрызок карандаша. Формально все выполнено.
Следовательно, придется все равно открывать доступ, чтобы доказать свою позицию.
То есть web-сервер, master-база, все скрипты — будут по прежнему, в Европе, и slave — в РФ. Букве закона это будет соответствовать, а духу… я не голосовал за нынешних, и у меня нет никаких моральных обязательств по отношению к ним. :)
Я согласен с автором насчет длинных презентаций, демо-продуктов, потенциальных покупателей. По моим наблюдениям, инвесторы лучше всего клюют на следующую «наживку» :) (в порядке приоритета):
— наличие потенциальных покупателей (идея + ретейловая сеть лучше, чем просто готовый продукт, даже в продакшн)
— команда (нужно иметь одного-двух с опытом успешного стартапа — это значительно повышает внимание инвестора)
— каналы продаж (если инестор поверит в их наличие и их масштабируемость — шансы высоки)
— готовый продукт в коммерции
— готовое демо (на уровне бетта-версии с основным функционалом)
Все остальное, на мой взгляд, в том числе просто идея, скриншоты, архитектура, технологии — практически не интересуют.
У меня есть приложение, которые мне разрабатывали на заказ. Когда я сменил разработчиков, выяснились интересные подробности — оказалось, что приложение было просто нарезкой PSD-файла. То есть когда открывалось окно, все элементы на нем — кнопки, поля, и прочее — были рисунки, поверх которых как-то накладывалась логика. В принципе, я допускаю, что когда разработка идет не «для себя», а «для дяди», то проще и быстрее градиент (как пример) сделать просто растровой картинкой.
Далее можно представить ход рассуждений инженерной мысли. Если такой подход практикуется широко (а например, Apple прекрасно на этапе модерации знает архитектуру приложений в AppStore) — то тогда при выпуске телефонов с большим экраном и другим числом пикселей, придется масштабировать растр. При этом складывается парадоксальная ситуация — делать лучшую Ретину, и получить смазанные изображения. Это будет удар не по разработчикам нативных приложений, а по Apple. В момент старта новой модели многие могут сказать: фи, на пятерке качество на порядок лучше.
Соответственно, понимая что в перспективе придется переходить на большие экраны, выгодно поколением раньше перейти на векторную ОС, приложения для которой могут масштабироваться без потери качества. Более того, даже если кнопку сделают картинкой, но плоской, то она растянется без видимых искажений.