К сожалению, у нас нет времени на естественный отбор. Он требует нескольких поколений. Я не хочу ждать, пока меня отберёт естественный отбор. Поэтому приходится общаться с тем, что имеем
Вообще, для меня это правило представляет серьёзную проблему. Я не задаю вопросов, потому как способен сам найти ответ, но очень часто нахожу неточности в ответах, которые способен исправить/уточнить в комментах. Но из-за 50 необходимых балов сделать я этого не могу.
Хм. Правило 50ти балов тут так же присутствует. В результате, зная ответ на вопрос, его невозможно дать. И если на основном сайте это нивелируется числом уже активных пользователей, то тут это может стать проблемой.
Немного странный вопрос: как залогиниться на русском Stack Overflow? Я в упор не вижу формы логина или каких-либо признаков того, что я уже залогинен (при этом я залогинен на основном Stack Oveflow)
В рамочку и на стену, вне зависимости от языка программирования. Код некоторых товарищей выглядит так, как будто их штрафуют за каждый лишний пробел или перенос строки.
Вы подошли к сбору пожертвований не с того конца. Патрион подходит для продуктов с относительно коротким циклом «отдачи»: он отлично подойдёт авторам веб-комексов, ютуберам не желающим захламлять свои видео рекламой, музыкантам. Для них он и создан.
Лично я, в отличии от того же Кикстартера, разработчикам игр на Патреоне не пожертвую ни копейки, и вот почему:
По итогам компании на Кикстартере есть:
— заявленные сроки проекта, в которые нужно уложиться;
— конкретный объём работ, которые нужно проделать;
— конкретный бюджет;
— ответственность за невыполнение;
На Патреоне же всё это отсутствует и компания фактически не кончается: «платите нам деньги, пока мы жуём сопли, а проект мы выкатим когда-нибудь потом, если вообще выкатим»
Имхо, регекспы — переоцененный инструмент. Да, он неплохо решает определённый подкласс задач: например, поиск email в тексте, вычленение телефона номера из форматированной строки, etc. Но для него так же есть как слишком простые (поиск символов в подстроке), так и слишком сложные (парсинг файлов) задачи.
Конкретно тут в голову приходят несколько реализаций, которые будут не длиннее по коду и уж точно будут работать быстрее. Доберусь до чего-нибудь с xcode — скину пример.
textContainerInset даёт константную ошибку, так что это точно не оно. lineFragmentPadding… Может быть.
Я обычно создаю CTFramesetter и использую CTFramesetterSuggestFrameSizeWithConstraints.
На win7 x64 где-то в районе Beta 3 резко возросло потребление памяти. Раза этак в 2. Если раньше самый «толстый» процесс потреблял 160мб памяти, то теперь — периодически переваливает за 300.
Как вы решили неточность расчёта размера текста?
Если ничего не изменилось за 2 мажорные версии iOS — boundingRectWithSize и, собственно, UITextView используют разные движки рендера текста. И результирующие размеры не совпадают.
Собственно, типичная ситуация: на 100 строк текста шрифтом Helvetica Neue boundingRectWithSize: даёт ошибку больше, чем высота двух строк.
Но вот основной проблемой остаётся прокрутка в середину таблицы — эта операция требует полного пересчёта всех промежуточных ячеек, либо кучи магии с перепозиционированием.
К сожалению, Эппловская документация грозится полной блокировкой работы с UIKit из фонового потока — со следующей мажорной версии iOS попытка обратиться к интерфейсу из фонового потока будет кидать исключение.
Так же, используя autolayout, вы можете кешировать размер ячеек без предварительного расчёта совсем: в методе cellWillDisplay: размеры ячеек уже рассчитаны и вы можете получить актуальный frame ячейки.
К сожалению, у нас нет времени на естественный отбор. Он требует нескольких поколений. Я не хочу ждать, пока меня отберёт естественный отбор. Поэтому приходится общаться с тем, что имеем
>… хотя, вы только что использовали Хабр, как вопросник…
Вы так говорите, как будто это плохо :) Вопрос на 100% релевантен теме обсуждения :)
В рамочку и на стену, вне зависимости от языка программирования. Код некоторых товарищей выглядит так, как будто их штрафуют за каждый лишний пробел или перенос строки.
Лично я, в отличии от того же Кикстартера, разработчикам игр на Патреоне не пожертвую ни копейки, и вот почему:
По итогам компании на Кикстартере есть:
— заявленные сроки проекта, в которые нужно уложиться;
— конкретный объём работ, которые нужно проделать;
— конкретный бюджет;
— ответственность за невыполнение;
На Патреоне же всё это отсутствует и компания фактически не кончается: «платите нам деньги, пока мы жуём сопли, а проект мы выкатим когда-нибудь потом, если вообще выкатим»
Конкретно тут в голову приходят несколько реализаций, которые будут не длиннее по коду и уж точно будут работать быстрее. Доберусь до чего-нибудь с xcode — скину пример.
Я обычно создаю CTFramesetter и использую CTFramesetterSuggestFrameSizeWithConstraints.
Быстрее и читабельнее пройтись циклом по символам строки.
Если ничего не изменилось за 2 мажорные версии iOS — boundingRectWithSize и, собственно, UITextView используют разные движки рендера текста. И результирующие размеры не совпадают.
Собственно, типичная ситуация: на 100 строк текста шрифтом Helvetica Neue boundingRectWithSize: даёт ошибку больше, чем высота двух строк.
Так же, используя autolayout, вы можете кешировать размер ячеек без предварительного расчёта совсем: в методе cellWillDisplay: размеры ячеек уже рассчитаны и вы можете получить актуальный frame ячейки.