Тим Феррисс в своей книге The 4-Hour Workweek описывает похожую модель в подробностях, в применении к американским реалиям. Также можно найти немало историй успешной реализации в его блоге (ссылка).
На мой взгляд, работает оно не так часто, чтобы стать стабильным решением для начающего предпринимателя. Но те, кому удается раскрутить карусель, довольны.
Задумка хорошая. Недостаток заключается в том, что художник должен не допустить ошибки в названии компа, но это не так сложно поправить.
Подводить подобный скрипт начинает тогда, когда появляется необходимость что-то поменять в интерфейсе; когда надо задать элемент, внутри которого будут дочерние элементы (иерархия); когда надо для одной кнопки задать разные картинки для разных состояний; когда надо сделать анимированный элемент и т. д. Эти задачи решить можно, но они все будут полагаться на набор соглашений. А соглашения могут быть легко нарушены либо из-за простой ошибки, либо из-за недопонимания.
А как, например, задать картинку для прогресс-бара или скролл-бара, который потом будет программно реализован? И как сделать, чтобы в разных экранах использовались одни и те же картинки, чтобы вносить изменения надо было только в одну из них, а не в обе копии?
Этот скрипт хорошо подходит для экспорта картинок, чтобы их потом программно можно было расположить. Для создания пользовательского интерфейса фотошоп не годится. Лучше смотреть в сторону флеша, там тоже есть джаваскрипт. А есть еще Adobe Flash Catalyst. Но это все high-end тулзы, включая сам фотошоп, если его покупать.
Одним словом, для создания полноценного интерфейса одного экспорта картинок не достаточно. И простого универсального решения я пока что не нашел.
Гит не умеет коммитить что-либо по своему желанию. Он коммитит только то, на что вы ему укажите. Опишите, пожалуйста, подробнее, что у вас за промежуточный вывод и каким образом гит считает своим долгом его закоммитить.
Хороший способ поощрить развитие IT-граммотности среди учащихся школ и выявить в них хакерские способности. Тех, кто сам додумается, как обмануть сканер, будут принимать в колледж по собеседованию, без экзаменов.
He was the reason many of us got into this industry, or even care about technology at all. He made the computer personal, and the smartphone fun. Bill Gates may have put a computer on every office desk, but it was Steve Jobs who put one in every dorm room and bedroom and living room. And then, years later, he repeated the trick, putting one in every bag and every pocket, thanks to the iPad and iPhone. If you use a computer or smartphone today, it is either one he created, or an imitation of his genius.
Со смешанным переводом идея хорошая, но реализация не очень. Попробуйте отображать текст в две колонки, слева английский, справа — русский. Еще было бы круто подсвечивать предложение в обоих колонках при наведении на него курсора. В противном случае проще будет выделить кусок и перевести в гугле, чем искать в другом абзаце нужное место.
Конечно. Если в вашей стране официально апп стора нету, а вы в нем зареганы с помощью фальшивой кредитки, вы нелегал.
Кроме того, если вам из США привезли гифт-карту и вы желаете ею воспользоваться для регистрации в iTunes/Mac/App Store, вам необходимо будет указать адресные данные США. Регистрация пройдет успешно, но технически ваш аккаунт нелегален.
Вывод: делать виртуальные методы публичными не очень хорошо.
Насчет обычных методов спорить не буду, а вот деструктор практически всегда должен быть виртуальным, так как теоретически у вас нету 100-процентной уверенности в том, что кто-нибудь не захочет наследовать от вашего класса.
На мой взгляд, вывод из статьи должен быть таким — если в классе есть хотя бы один виртуальный метод, то и деструктор должен быть обязательно виртуальным. Если же в классе виртуальных методов нету, то необходимо в комментарии пояснить, что он не предназначен для наследования. Если же все-таки может возникнуть необходимость наследовать от класса, деструктор должен быть виртуальным. Это покрывает случаи использования класса другими людьми или вами же, но в другом проекте или контексте.
Если класс будет использоваться только в пределах одного проекта, тогда правила устанавливаются из соображений целесообразности для данного конкретного проекта.
Каким образом мозиловцы сделали аппаратное декодирование? Я считал, что данная возможность доступна только производителям аппаратной части и разработчикам драйверов.
Если парсить надо будет весь файл, лучше преобразовать его в plist. В этом случае можно править файл в XML, а потом конвертировать его в двоичный формат во время сборки cocoa-проекта. А при загрузке получите желанный NSDictionary одним вызовом метода класса NSPropertyListSerialization.
На мой взгляд, парсить непосредственно XML стоит только если надо считать только его часть (в этом случае выгодней использовать event-based механизм) или если он скачивается приложением из инета (только здесь ваша реализация может быть не только удобной, но и эффективной). Во всех остальных случаях проще написать скрипт на питоне (который по умолчанию комплектуется модулем plistlib) для конвертации XML в plist.
На мой взгляд, работает оно не так часто, чтобы стать стабильным решением для начающего предпринимателя. Но те, кому удается раскрутить карусель, довольны.
Вы получаете тот же указатель, а объект, на который этот указатель ссылается, имеет на один реф каунт больше.
Если же у вас весь объект помещается в указатель, как в данном случае, никаких рефкаунтов ему и не нужно. Пока жив указатель, жив и объект.
Откуда взялась эта клевета? Apple создали собственную libc++ и поддерживают уже практически весь С++11.
Указывайте источники, пожалуйста, иначе грош цена такой информации.
developer.apple.com/library/ios/#documentation/general/Reference/InfoPlistKeyReference/Articles/iPhoneOSKeys.html
Подводить подобный скрипт начинает тогда, когда появляется необходимость что-то поменять в интерфейсе; когда надо задать элемент, внутри которого будут дочерние элементы (иерархия); когда надо для одной кнопки задать разные картинки для разных состояний; когда надо сделать анимированный элемент и т. д. Эти задачи решить можно, но они все будут полагаться на набор соглашений. А соглашения могут быть легко нарушены либо из-за простой ошибки, либо из-за недопонимания.
А как, например, задать картинку для прогресс-бара или скролл-бара, который потом будет программно реализован? И как сделать, чтобы в разных экранах использовались одни и те же картинки, чтобы вносить изменения надо было только в одну из них, а не в обе копии?
Этот скрипт хорошо подходит для экспорта картинок, чтобы их потом программно можно было расположить. Для создания пользовательского интерфейса фотошоп не годится. Лучше смотреть в сторону флеша, там тоже есть джаваскрипт. А есть еще Adobe Flash Catalyst. Но это все high-end тулзы, включая сам фотошоп, если его покупать.
Одним словом, для создания полноценного интерфейса одного экспорта картинок не достаточно. И простого универсального решения я пока что не нашел.
gizmodo.com/5838847/steve-jobs-is-dead
Кроме того, если вам из США привезли гифт-карту и вы желаете ею воспользоваться для регистрации в iTunes/Mac/App Store, вам необходимо будет указать адресные данные США. Регистрация пройдет успешно, но технически ваш аккаунт нелегален.
Вот, например, вырезка из www.apple.com/legal/itunes/us/terms.html про гифт-карты для американского iTunes Store:
Насчет обычных методов спорить не буду, а вот деструктор практически всегда должен быть виртуальным, так как теоретически у вас нету 100-процентной уверенности в том, что кто-нибудь не захочет наследовать от вашего класса.
На мой взгляд, вывод из статьи должен быть таким — если в классе есть хотя бы один виртуальный метод, то и деструктор должен быть обязательно виртуальным. Если же в классе виртуальных методов нету, то необходимо в комментарии пояснить, что он не предназначен для наследования. Если же все-таки может возникнуть необходимость наследовать от класса, деструктор должен быть виртуальным. Это покрывает случаи использования класса другими людьми или вами же, но в другом проекте или контексте.
Если класс будет использоваться только в пределах одного проекта, тогда правила устанавливаются из соображений целесообразности для данного конкретного проекта.
Смелое заявление) Не могли бы вы продемонстрировать примеры работ? Просто интересно, насколько вы смогли поднять уровень рисования за семестр.
На мой взгляд, парсить непосредственно XML стоит только если надо считать только его часть (в этом случае выгодней использовать event-based механизм) или если он скачивается приложением из инета (только здесь ваша реализация может быть не только удобной, но и эффективной). Во всех остальных случаях проще написать скрипт на питоне (который по умолчанию комплектуется модулем plistlib) для конвертации XML в plist.