Купил недавно дешевые наушники Fisher вот такие fischer-products.com/index.php?route=product/product&path=20&product_id=91. У них провод из какого-то жесткого пластика и он ВООБЩЕ не запутывается. Т.е. суешь в карман как попало, вытащил, встряхнул и все, они распутались. Рекомендую. После сенхайзеров просто сказка.
Даже уникальное приложение надо как-то продвинуть. Если в России понятно — залатил айфонс.ру и ты уже в топе, то куда бежать для других сторов мне пока не совсем понятно.
А почему заминусовали? Логика судя по опыту именно такая. Это доказывает например то, что если беслатное приложение сделать платным — оно взлетит в топе засчет хвоста из нескольких бесплатных дней.
Главное не переборщить. Была какая-то программа поиска продуктов по штрих-коду, которая требовала установленную другую программу для распознавания штрих-кодов. Без нее не работала. Распознавание шло через урл. Ужасно все это выглядело.
А на js в сафари можно определить canOpenUrl? Урлы были бы гораздо популярнее, если когда мы открываем обычную http ссылку на сайт (из твиттера, например), если есть соответствующее приложение — открывать его.
Про ошибки не согласен, как и все :) Удобнее, когда протокол по возможности само-документированный, т.е. по ошибке программисту понятно, что случилось. Я бы делал что-то вроде { success:'false', errorCode:12345,errorText:'Нешмогла' }, где errorText это текст именно для программиста. А на клиенте по коду уже показываем нормальную диагностику. Если обработка такого кода не предусмотрена, на клиенте можно хотя бы errorText показать.
По wsdl возможно и правда для больших проектов. На малом проекте, где не больше 50 типов сущностей имхо все же проще json руками описать. Тем более достаточно описать один раз классы, а при парсинге через setValue:forKey: все значения заполнять. А за свой кастомный xml вообще надо руки отрывать, его парсить просто задолбаешься, т.к. он не накладывается отднозначно на структуры языка.
Понятно, спасибо. С авторизацией должно быть удобно.
10 000 уникальных это круто, думаю вряд ли кто-то в ближайшее время перевалит за такое число комментирующих :)
Это может быть еще полезно тем, что не у всех может быть настроена почта на устройстве. Да и написать коммент обычно морально проще, чем идти на личное общение с разработчиком.
В свое время намучился с ios-мордой для get-satisfaction, в итоге просто вставили webview с ним.
Не совсем понятно по статье:
— как считаются 10 000 пользователей, при ценообразовании. Это 10 000 фидбеков? Или 10 000 уникальных запусков приложения?
— что в итоге с авторизацией? Как пользователь логинится?
Не решил еще для себя, чем лучше такой сервис, чем просто кнопка с email-ом. Вопросы повторяются редко, а если и повторяются, на сервисе их опять же будут одинаковые задавать. Читать старое никто не утруждается. А других преимуществ не особо видно.
Нужно сделать один веб-проект. Питон знал поверхностно, Руби не знал совсем. Но так меня пробесило, что до сих пор Джанго не поддерживает 3й Питон (сколько ему уже лет?!), что решил выучить Руби и писать на рельсах…
Десктоп обсуждать смысла нет — если пишем windows-приложение нет оснований писать не на С#, если не-windows, то наоборот — писать на C# смысла нет.
Все-таки спор скорее про серверную часть корпоративной трехзвенки (с клиентом-браузером или другим толстым или тонким клиентом). И тут сервер на windows или linux — думаю для многих первоочередной вопрос. Потом уже выбор языка. Вопрос конечно не в цене, а вообще в выборе платформы. Я бы при всей любви к C# не стал завязываться на виндовые сервера.
А кто-то действительно может утверждать, что Java как язык в чем-то удобнее С#? Минус у C# только один, но он для многих краеугольный: винда. Те, кто не готов с нею связываться, просто вынуждены писать на Java…
Брейкпоинты как-то почему-то через раз работали, когда я последний раз мучил SenTestKit.
В какой-то презентации про GHUnit (другой движок для тестов) видел аргумент «не нужно иметь PHD, чтобы дебажить тесты» :)
А UIAutomation вы в итоге где-нибудь используете? Проблема с UI-тестами, что хорошо бы их писать тестировщику, т.к. девелоперу обычно некогда и лень. Но нужно серьезно уметь программировать, чтобы их написать. Cucumber пытается это исправить, но ИМХО не до конца.
А меня наоборот бесит, когда по нажатии на ссылку переключается на браузер молча.
А на js в сафари можно определить canOpenUrl? Урлы были бы гораздо популярнее, если когда мы открываем обычную http ссылку на сайт (из твиттера, например), если есть соответствующее приложение — открывать его.
По wsdl возможно и правда для больших проектов. На малом проекте, где не больше 50 типов сущностей имхо все же проще json руками описать. Тем более достаточно описать один раз классы, а при парсинге через setValue:forKey: все значения заполнять. А за свой кастомный xml вообще надо руки отрывать, его парсить просто задолбаешься, т.к. он не накладывается отднозначно на структуры языка.
10 000 уникальных это круто, думаю вряд ли кто-то в ближайшее время перевалит за такое число комментирующих :)
Это может быть еще полезно тем, что не у всех может быть настроена почта на устройстве. Да и написать коммент обычно морально проще, чем идти на личное общение с разработчиком.
Не совсем понятно по статье:
— как считаются 10 000 пользователей, при ценообразовании. Это 10 000 фидбеков? Или 10 000 уникальных запусков приложения?
— что в итоге с авторизацией? Как пользователь логинится?
Не решил еще для себя, чем лучше такой сервис, чем просто кнопка с email-ом. Вопросы повторяются редко, а если и повторяются, на сервисе их опять же будут одинаковые задавать. Читать старое никто не утруждается. А других преимуществ не особо видно.
Все-таки спор скорее про серверную часть корпоративной трехзвенки (с клиентом-браузером или другим толстым или тонким клиентом). И тут сервер на windows или linux — думаю для многих первоочередной вопрос. Потом уже выбор языка. Вопрос конечно не в цене, а вообще в выборе платформы. Я бы при всей любви к C# не стал завязываться на виндовые сервера.
В какой-то презентации про GHUnit (другой движок для тестов) видел аргумент «не нужно иметь PHD, чтобы дебажить тесты» :)
А UIAutomation вы в итоге где-нибудь используете? Проблема с UI-тестами, что хорошо бы их писать тестировщику, т.к. девелоперу обычно некогда и лень. Но нужно серьезно уметь программировать, чтобы их написать. Cucumber пытается это исправить, но ИМХО не до конца.