Шифрование встроить не сложно, это оставим на домашнее заданее. Ведь делать какое-то универсальное шифрование смысла нету — тем и хороша защита, что у каждого она чем-то отличается.
Учитывая что валидация нужна каждый раз когда происходит покупка или восстановление покупки — о большой нагрузке волноваться не приходится. Обработка запроса занимает 200мс, 1 dyno worker следовательно будет обрабатывать до 5 запросов в секунду. Я буду очень богат, когда приближусь к пределу возможностей бесплатного сервера на heroku. При чем тут бедность мелкого разработчика?
Согласен. Сам использую 3 основные ветки, production, master и testing. Потому что так повелось что в master были разные дев плюшки. Вобще пост весьма хорош, т.к. описывает простую логику ведения проекта в нескольких ветках и если разобраться зачем это делается, то работать становится проще и мержить руками надо меньше.
не согласен совершенно. :) если я пью кофе каждое утро, не значит что все пьют кофе каждое утро. так что не надо обобщать.
Работаю под MacOS X. Я использую git в разработке уже несколько лет. Отлично с повседневными задачами справляется SourceTree, иногда я захожу в консоль что-то сделать, но только иногда.
Раньше я использовал GitX и пару его форков, тоже не жаловался.
идея хранения всех форков в одном репозитории весьма интересная, вполне может быть что именно для этих целей она и создавалась. потому как большая часть обьектов в .git/objects будут общими.
Что касается submodules, я с вами не соглашусь. Весьма бывает удобно вынести общий модуль для нескольких проектов в отдельный репозиторий. Например если над ними работают 2 разные комманды и основной проект будет хранить только ссылку на коммит с которым всё работает хорошо. Общий модуль обновился — ничего не поломалось. Когда нужны будут новые функции — обновили коммит в submodule протестировали, подпилили, то что отвалилось и уже стабильную связку закоммитили в репозиторий.
Или например есть 5 проектов с общим ядром. 3 проекта просто на поддержке, их лучше трогать чем реже тем лучше, только баги править. Еще 2 в активной разработке и под них в ядре делаются изменения. Общий submodule будет отличным решением в этой ситуации. Вобщем примеров можно много привести когда submodule жить помогает.
Присоединяюсь к вопросу. Интересуют и рабочие процессы, и рабочий график, и мифический день в неделю, когда можно работать над своим проектом. Как построена иерархия в команде и в компании и другие интересные моменты.
Я пока читал несколько постов про офисы гугла и их можно объединить одной фразой. «В Google вкусно кормят». Интересно было бы прочитать что-то с общей мыслью «В Google интересно работать.»
Рекомендую практикующим Obj-C программистам к ознакомлению: BlocksKit. И стиль написания и возможности из коробки помогают писать интересные вещи, для которых раньше требовались обходные пути. Например заменить делегаты блоками и не писать в UIAlertViewDelegate определение, какая же это мессага закрылась сейчас.
Я тоже подумал, что нужны опции: «Запретить будить меня последнему позвонившему» и «Пусть будит меня еще :)». Ну и трекать с какой частотой на человека сыплются плохие отзывы. Ибо если в сети заведется маньяк — можно будет снимать хороший такой триллер, основанный на реальных событиях.
Спасибо, за пояснение. Теперь буду знать. Вобще конечно если у результата много областей применения, а сам результат не так просто найти, то такого рода «готовые решения» весьма полезны. Я по работе с такого рода задачами не сталкивался, потому и решил уточнить. Чтобы расширить кругозор.
простите за невежество, но какое практическое применение может быть у знания, как раскрасить матрицу 17х17 и 18х18 четырьмя цветами без монохроматических прямоугольников? оно может лежать в основе другой математической теории? я попробовал сам представить и как-то ничего толком не смог придумать. только как предмет искусства наравне с визуальными иллюзиями на стену повесить.
Ну не знаю. Меня смущает перенос результата исследований одного стартапа на все приложения всех разработчиков. Может там и всё честно, но меня смущает. :) Приложения в iOS падают на удивление часто, но незаметно. Например это может быть килл приложения когда на устройстве мало памяти и надо убить кого-то в фоне. Или если приложение не успело запуститься за указанное время или завершиться за указанное время. Может это произошло и не по вине приложения, система его всё равно убьет. «Если пользователю надо — он перезапустит». Могут быть и скрытые ошибки в приложении, например приложение попробовало вызвать OpenGL функцию в то время пока оно было в фоне — будет убито сразу. Таким образом шансов умереть от рук системы в iOS много больше. :) Что и показывает статистика.
у Android ситуация не лучше. Точнее её ухудшают еще несколько факторов, а именно то что разработчики не могут физически протестировать приложение для всех устройств на которых приложение будет работать. Ну и возникают глюки с прорисовкой на части устройств или экзотические крэши. И приложения заливать проще, это тоже добавляет низкокачественных приложений в магазин. Но т.к. разрабатывать приложения под Андроид сложнее, на выходе получается меньше приложений от нубов, тех кто первый день как начал писать прилаги и решил сделать игруху про джастина бибера. Так что тут 50/50 процент толковых приложений среди всех приложений платформы приблизительно одинаков.
хорошо, если так не понятно, попробуем на пальцах. Есть 2 группы людей по 10 человек. У некоторых них есть пластиковая карточка нашего банка. Мы в банке проанализировали статистику что кашляют больше люди из первой группы — таким образом мы можем предположить, что люди в первой группе чаще болеют.
Такой анализ может только предположить что так дела обстоят, хотя никто вас не застрахует от случая что в первой группе чихают только держатели карточек банка, а во второй все остальные кроме держателей карточек этого же банка. Выборка должна быть случайна среди всех участников исследования, чтобы результаты распространялись на всех участников. Если же у нас есть 20 человек с каким-то общим признаком — результаты будут верны только для большей группы людей с тем же общим признаком. Но их нельзя переносить на всех людей в целом.
как тут заметили выше у такого рода сравнения есть проблемы с выборкой. т.е. сравнивают статистику крэшей только тех приложений, разработчики пользуется их сервисом, а далеко не всех приложений. И это делает все сравнения несостоятельными. Хотя глупо отрицать что в iOS случается такое что в новой версии iOS перестают работать какие-то ранее стабильные приложения.
Когда приложение выходит в апдейт они уже более лояльно относятся к нему на ревью. Хотя бывают косяки. У меня как-то был реджект из-за того что в приложении продавалось > 10 шт in-app purchase по 1$ за раз. Их напрягло что их именно больше 10 шт. Попросили создать отдельный in-app purchase айтем с большей стоимостью, чтобы число приобретенных за раз айтемов не превышало 10-ку… :) Пришлось подчиниться. Благо они детально расписали почему и чем они недовольны.
Что касается интерфейса приложений — перевод это большое дело, если приложение простое и рассчитано на массового пользователя. Это как правило хорошего тона, у пользователя должна быть возможность пользоваться приложением на родном языке и должна быть возможность выбора этого самого языка.
Практика показывает, что локализованные версии получают дополнительную волну скачиваний из тех стран где мало хорошо переведенных приложений. У меня опыт по скачиваниям из AppStore, но наверняка ситуация на других площадках похожая.
Учитывая что валидация нужна каждый раз когда происходит покупка или восстановление покупки — о большой нагрузке волноваться не приходится. Обработка запроса занимает 200мс, 1 dyno worker следовательно будет обрабатывать до 5 запросов в секунду. Я буду очень богат, когда приближусь к пределу возможностей бесплатного сервера на heroku. При чем тут бедность мелкого разработчика?
Работаю под MacOS X. Я использую git в разработке уже несколько лет. Отлично с повседневными задачами справляется SourceTree, иногда я захожу в консоль что-то сделать, но только иногда.
Раньше я использовал GitX и пару его форков, тоже не жаловался.
Что касается submodules, я с вами не соглашусь. Весьма бывает удобно вынести общий модуль для нескольких проектов в отдельный репозиторий. Например если над ними работают 2 разные комманды и основной проект будет хранить только ссылку на коммит с которым всё работает хорошо. Общий модуль обновился — ничего не поломалось. Когда нужны будут новые функции — обновили коммит в submodule протестировали, подпилили, то что отвалилось и уже стабильную связку закоммитили в репозиторий.
Или например есть 5 проектов с общим ядром. 3 проекта просто на поддержке, их лучше трогать чем реже тем лучше, только баги править. Еще 2 в активной разработке и под них в ядре делаются изменения. Общий submodule будет отличным решением в этой ситуации. Вобщем примеров можно много привести когда submodule жить помогает.
Я пока читал несколько постов про офисы гугла и их можно объединить одной фразой. «В Google вкусно кормят». Интересно было бы прочитать что-то с общей мыслью «В Google интересно работать.»
Такой анализ может только предположить что так дела обстоят, хотя никто вас не застрахует от случая что в первой группе чихают только держатели карточек банка, а во второй все остальные кроме держателей карточек этого же банка. Выборка должна быть случайна среди всех участников исследования, чтобы результаты распространялись на всех участников. Если же у нас есть 20 человек с каким-то общим признаком — результаты будут верны только для большей группы людей с тем же общим признаком. Но их нельзя переносить на всех людей в целом.
Практика показывает, что локализованные версии получают дополнительную волну скачиваний из тех стран где мало хорошо переведенных приложений. У меня опыт по скачиваниям из AppStore, но наверняка ситуация на других площадках похожая.