Pull to refresh
20
0

iOS-разработчик

Send message

Следует понимать, что импортированные модули буду собираться вместе с проектом, а не только в момент подключения.

Скажите, пожалуйста, использовали ли или рассматривали инструменты вроде этого - https://guides.cocoapods.org/plugins/pre-compiling-dependencies.html? Если да, то какие результаты?

Я в данном случае не спорю и не высказываю свое мнение ни в одну из сторон, цель — разобрать с непредвзятой точки зрения плюсы и минусы обоих способов. Если беспристрастно — отсутствие места на диске аналогично разрушительно и для Realm, и для UserDefaults.
А вот про «много еще» было бы интересно послушать — правда, желательно, с обеих сторон. Если это возможно, конечно. На этом примере открывается одна из сравнительно редких возможностей решить одну задачу двумя разными способами и сравнить их на практике. Как правило бывает, что разработчики выбирают одно из решений, реализуют его. И видят все плюсы/минусы полученного решения, а плюсы/минусы других решений можно оценить только умозрительно. А в вашем случае можно сесть, составить таблицу параметров и расставить оценки кандидатам. Получится объективный счет.
Понятно. Вопрос появился из-за того, что проблема с миграциями — не от их наличия, а от обращения с ними. Сам-то инструмент полезный. Собственно, если переехать на UserDefaults — то вопрос с миграциями останется. Вот только, по моему мнению, он проигрывает Realm: если у Realm миграции предусмотрены штатно, то в UserDefaults их к тому же и нет (то есть проблем становится больше: и завести, и правильно использовать).
Ну и, кроме того, Realm имеет настройку удалять БД при миграциях: можно их не писать, а просто чистить базу. Как я понял из ответа, примерно к тому же и пришли в UserDefaults.
Да, меня интересовала разница в количестве кода исключительно, не объем бандла.
Еще относительно UserDefaults. Как решили вопрос миграций в них?
А удалось посчитать реальную разницу в размере кода? Как я понял, одним из недостатков Realm был увеличенный объем. Realm убрали, заменили репозиториями — и какой эффект в этом отношении получился в числах? Скажем, убрали 1000 строк кода, а добавили 10. Не считали?
Насколько я знаю, подобное можно реализовать в Jira. Частично это есть в отчетах, частично в интерфейсе (можно помечать определенным цветом карточки, которые подпадают под определенный запрос на JQL). Да и многие компании допиливают стандартный функционал кастомным (отчеты, выгрузки, алерты и прочее).
Думаю, что так как тонкостей рабочего процесса очень много, то и инструмент получается неуниверсальным. А потому они, наверное, и есть, просто известны в узких кругах — каждый инструмент в своем кругу.
Я такого инструмента не знаю, да и не искал. Мне неясно, как он сможет вычислить, что «уже времени не хватает»? Для этого он должен знать обо всех задачах, об их оценках, а также уметь трекать фактически потраченное время. Со всеми накладными расходами на эту бюрократию. А тогда это уже не простой инструмент.
Вообще можно сделать отслеживание статуса задачи и времени в Jira, например, чтобы писал в слак/подсвечивал цветом просроченные задачи. Но, видимо, это не то, что вам нужно.
Подразумевал это в пункте «Принимаем меры», но явно не прописал, да.
На самом деле я имел в виду скрытый смысл: «пресс-секретарь» — от слова «пресс», а не «пресса». А ваше предложение тоже подходит
Мы все больше приходим к выводу, что значительно сложнее сформировать опыт внутри нас, чем вообще узнать, как это делается. Чужого опыта действительно очень много, но если его просто взять и применить, это не сделает компанию опытнее. Поэтому от ситуации «мы нашли, как кто-то решил проблему, похожую на нашу» до ситуации «мы умеем решать нашу проблему» куда сложнее дойти, чем просто найти решение.
>>А, ну то есть вы отличаетесь от хабра тем, что статьи другой тематики? Ну то есть вы — просто другой блог, на другие темы.
Не только этим. Да — мы блог. Да — коллективный. Да — выглядит это похожим на хабр (по внешнему виду). Но цели у нас с хабром разные — у хабра даже очень хорошая, стоящая статья с огромным рейтингом через год опускается так, что ее найти без конкретной ключевой фразы, забитой в поиск, невозможно — хабр ориентирован на свежесть. У нас же ориентация как раз на пользу, хотя по свежести выдача также есть. Сравните сами — выберите какой-нибудь приличный по возрасту блог на хабре, представьте, что Вы в теме только начинаете разбираться, и попробуйте найти то, что нужно на первых порах новичку. На самом верху будут, в лучшем случае, статьи об очень продвинутых вещах, в худшем случае, новости. Так что по концепции проект ближе к википедии.

>>И движок — блоговский.
Отнюдь, тут Вы не правы. Если Вы имели в виду атрибуты блога — то они такие же, конечно, ведь это удобно, нужно и привычно. Если внутренняя реализация — то тоже нет, это не livestreet.

>>Лично я вот — вижу просто блог
>>Проект должен как-то наглядно показывать свою уникальность и особенность

С таким же успехом я могу сказать автору очередного сайта в интернете: «А зачем ваш сайт? Лично я вот открыл исходный код страницы, и вижу там такие же теги, как на любом другом сайте. Да и на самом сайте у вас картинки какие-то, текст, ссылки. У других все то же самое. Вы же понимаете, что я не буду это все читать, втыкать во все. Вы же должны чем-то отличаться. Вот если бы у вас был зеленый шрифт на фиолетовом фоне, я бы вас запомнил». Утверждение утрированное, но смысл примерно тот же. А люди, заинтересовавшиеся проектом есть, да и faq читают многие, многие спрашивают вопросы по нему. Хотелось бы собрать думающую аудиторию, а не просто тех, кому понравилась нестандартная реализация — со временем она примелькается, станет обыденной, и интерес пропадет.

Ответы также прошу рассматривать не столько в качестве полемики, сколько в качестве объяснений, которые могут пригодиться другим. А то, что есть проблемы с пониманием целей и особенностей проекта — Вы правы, не все понимают сразу всё. К сожалению, саму уникальность не запихнешь в 5 слов.
Цель проекта — в накоплении полезной информации, а не просто в написании постов, а сделан он в виде коллективного блога, ибо такую форму сочли наиболее удобной. Кстати, от того же хабра отличия есть: на хабре у статей очевидная IT-направленность, и, кроме того, довольно много статей новостных.

То, что на начальном этапе будет копипаст — да, скорее всего, по-другому не обойтись. Но в будущем ресурс сделан не для этого, потому Ваше предложение о массивах ссылок не подходит.

Зачем читать FAQ — если Вас действительно интересует этот вопрос, то лучше почитайте. Я могу Вам объяснить различия и здесь, другое дело, имеет ли это смысл, если в FAQ-е этому посвящен не один раздел. Будет тот же копипаст из нашего FAQ-a сюда, да и простыни в комментариях. Хотя, если хотите, я могу, пожалуйста.

Если Вы прочитали краткое описание проекта, то Вам действительно может быть неочевидна разница. Ибо краткое описание несет в себе основные тезисы без доп.информации (дабы быть действительно кратким, а то его никто не будет читать), а потому оно насыщенно. Потому (если действительно интересен проект и его реализация) могу посоветовать статьи на сайте в сообществе nextdeep.com, которые подробнее описывают его устройство и работу (например, вот эта), тот же надоевший FAQ, ну или можем продолжить общение в комментариях, если Вам так удобнее.
Конкретне отличия от похожих проектов и концепций можно почитать в FAQe.
Кат как раз есть — то, что автор не офромил статью подобным образом — минус ему.

По поводу очередного блога — есть отличия. Проект создан не для того, чтобы люди высказывали просто свои мысли, а для того, чтобы они формировали интересную более-менее постоянную информацию и помогали таким образом ее найти другим. Копипаст не приветствуется, как, собственно, и везде, однако для начального заполнения в виде примеров сошел и он (кстати, и сейчас есть вполне оригинальные статьи, без копипаста, от авторов проекта и сторонних пользователей).
Да, будут. Это ссылка сообщества nextdeep.com/apple.com/iphone. Впрочем, проверьте сами — в данный момент второго измерения не существует. Создайте его, напишите статью — и там будет существовать что-то.
Проект как раз посвящен более-менее (насколько это возможно) постоянным данным. Например, новость о том, что сегодня вышла очередная версия php, к примеру, там не к месту. Вот если Вы напишете, что же там такого поменялось, да не просто поменялось, а как Вы на нее переходили, и что из этого вышло (то есть нечто уникальное, changelog можно и на оф.сайте почитать), то будет полезно.
А что касается пользы материалов — ненужные данные будут минусоваться. Если они устарели, и кому-то мешают — минусуйте. Если они так и висят со своим рейтингом — значит, не мешают никому или всем пофиг. Если потеряли свою пользу — будут болтаться внизу, и человек до них просто не дойдет. Так что мусорки не получится.
1

Information

Rating
Does not participate
Location
Москва, Москва и Московская обл., Россия
Registered
Activity