Заметил, что макбук начал жутко лагать. Зашел в диспетчер и увидел своп на 27 гигабайт.
Оказалось текла вкладка на гугл-докс с открытым файлом в spreadsheets — файлик то всего ничего, десяток столбцов и десяток строк с мизерным текстовым содержимым.
Но как только его открывал — вкладка начинала кушать память огромными темпами))
Так что 200-300 мегабайт на страничку — это еще по божески :-D
Учитывая качество решения и новый принцип отслеживания тача, Вам должно быть не трудно разработать игральные кости, шахматы — да и вобще сам подход разработки подобных аксессуаров, которые будут определяться на столе.
Чтобы для них можно было узнавать идентификатор, местоположение, ориентацию (в 3 плоскостях). Можно и дальше развить эту мысль)
Развивая в этой плоскости, можно старым добрым тактильным ощущениям игр добавить немного виртуальной реальности и часть функций подсчета сопутствующих показателей и подсказок — перенести с больной головы, на здоровую компьютерную ))
Лучше тогда не один, а все параметры начинающиеся с определенного префикса. Так часто делают в платежных системах и клиент сам может решить, сколько параметров ему нужно и что они будут означать.
Все эти доводы не являются достаточным оправданием для подмены понятия «первая реализация используемая в реальных системах» на «зародились в сообществе».
Я просто оставил ссылку, чтобы пытливые умы могли более детально посмотреть историю акторов при желании. В интернетах порой бывает трудно найти первоисточник и выяснить истинное положение вещей. Мне кажется надо придерживаться фактов и стараться избегать искажения информация при повествовании.
Если не знать контекста (а мы в данном случае не знаем) в котором делаются эти вызовы и для чего — мы не можем ответить на вопрос — как это повлияет на работу приложения.
Возможно, что никак. Представьте себе — такое тоже бывает, что делаются бессмысленные ни на что не влияющие вызовы. Да и чему удивляться после таких дыр в апи?
Давайте не делать необоснованных предположений. Мы же все таки программисты и мы пишем конкретные инструкции для программ, которые не зависят от предположений сторонних людей(если это не предусмотрено программой). В практически абсолютном большинстве мы даже рандом используем синтетический ))
Многие совсем разучились читать или понимать, что читают. Я не говорил, что его не надо переписывать. Я довольно четко написал «для этого» — что в контексте комментария, на который я отвечал имелось ввиду «переписывание ДЛЯ закрытия дыр». Всем программистам стоит начинать с курса внимательности, понимательности и точности изъяснения.
И кстати еще не факт, что оно отвалится. Если оно хотя бы более менее грамотно построено, то оно перестанет получать часть данных, которые оно и так не отображало. Для примера там где приходил список всех, придет только список доступных для конкретного авторизованного пользователя.
Не потакайте школоте, и да не окажетесь среди них.
Что за школьники минусуют? Видно те же, что и пишут такие андроид приложения с дырами. Любой безопасник Вам объяснит, что все дыры связанные с работой апи лечатся и закрываются на сервере — других вариантов нет и быть не может.
Расскажите мне господа минусовальщики, где и как Вы можете нарисовать такие дыры в клиентском приложении, если апи Вам просто не отдаст данные без соответствующей авторизации и прав чтения конкретной информации?
Или можете даже статью написать, как чинить дыры в апи посредством исправления андроид приложения. Это будет крайне полезно для тех лиц, которые пользуются уязвимостями апи. Отлично же — приложение исправили, стадо успокоили, ответственных наградили. А дыра в апи как была так и осталась, все кто пользовался — также и будут продолжать пользоваться.
Вы тоже не правы. Вы бы хоть поинтересовались причинами, по которым акка перешла на спрей. И они вовсе не связаны с производительностью. У нетти никогда не было проблем с производительностью. И ваш прирост в тестах объясняется не переходом на акку(спрей), а совсем другими нюансами.
Вы товарищ не очень владеете вопросом, но больно агрессивно отстаиваете свои ничем не подкрепленные мысли.
Следующий топик будет назван «Работа над ошибками или Секреты форматирование постов в блогах так, чтобы текст, изображения, отдельные смысловые блоки и иже с ними не сливались в одну вертикальную кашицу»? )
Оказывается все в порядке. Автор допустил синтаксическую ошибку в css не закрыв комментарий. В итоге часть правил начиная с margin-left у parent относились к классу outside.
Можете объяснить следующее поведение?
Если взять последний пример и поставить margin-left: 20px; у parent, то outside сдвигается влево на 20px, а parent и daughter остаются на месте.
Мне кажется вполне логичным попробовать добавить режим работы от сети, с целью считывания raw показаний и внесения в базу браслета своих жестов, после чего можно raw отключать и браслет сможет дальше считывать жесты по словарю.
Заметил, что макбук начал жутко лагать. Зашел в диспетчер и увидел своп на 27 гигабайт.
Оказалось текла вкладка на гугл-докс с открытым файлом в spreadsheets — файлик то всего ничего, десяток столбцов и десяток строк с мизерным текстовым содержимым.
Но как только его открывал — вкладка начинала кушать память огромными темпами))
Так что 200-300 мегабайт на страничку — это еще по божески :-D
Чтобы для них можно было узнавать идентификатор, местоположение, ориентацию (в 3 плоскостях). Можно и дальше развить эту мысль)
Развивая в этой плоскости, можно старым добрым тактильным ощущениям игр добавить немного виртуальной реальности и часть функций подсчета сопутствующих показателей и подсказок — перенести с больной головы, на здоровую компьютерную ))
Я просто оставил ссылку, чтобы пытливые умы могли более детально посмотреть историю акторов при желании. В интернетах порой бывает трудно найти первоисточник и выяснить истинное положение вещей. Мне кажется надо придерживаться фактов и стараться избегать искажения информация при повествовании.
Модели акторов 40 лет!
Возможно, что никак. Представьте себе — такое тоже бывает, что делаются бессмысленные ни на что не влияющие вызовы. Да и чему удивляться после таких дыр в апи?
Давайте не делать необоснованных предположений. Мы же все таки программисты и мы пишем конкретные инструкции для программ, которые не зависят от предположений сторонних людей(если это не предусмотрено программой). В практически абсолютном большинстве мы даже рандом используем синтетический ))
И кстати еще не факт, что оно отвалится. Если оно хотя бы более менее грамотно построено, то оно перестанет получать часть данных, которые оно и так не отображало. Для примера там где приходил список всех, придет только список доступных для конкретного авторизованного пользователя.
Не потакайте школоте, и да не окажетесь среди них.
Расскажите мне господа минусовальщики, где и как Вы можете нарисовать такие дыры в клиентском приложении, если апи Вам просто не отдаст данные без соответствующей авторизации и прав чтения конкретной информации?
Или можете даже статью написать, как чинить дыры в апи посредством исправления андроид приложения. Это будет крайне полезно для тех лиц, которые пользуются уязвимостями апи. Отлично же — приложение исправили, стадо успокоили, ответственных наградили. А дыра в апи как была так и осталась, все кто пользовался — также и будут продолжать пользоваться.
Вы тоже не правы. Вы бы хоть поинтересовались причинами, по которым акка перешла на спрей. И они вовсе не связаны с производительностью. У нетти никогда не было проблем с производительностью. И ваш прирост в тестах объясняется не переходом на акку(спрей), а совсем другими нюансами.
Вы товарищ не очень владеете вопросом, но больно агрессивно отстаиваете свои ничем не подкрепленные мысли.
Просто айтишник и угон чужого акка на хабре? Нестыковочка)
Если взять последний пример и поставить margin-left: 20px; у parent, то outside сдвигается влево на 20px, а parent и daughter остаются на месте.
*Исходный код примера