Ну допустим, сходил, даже оффер получил, где гарантия, что я реально буду столько зарабатывать? И что будет с дальнейшей перспективой? К примеру, на текущем месте работы так или иначе, а зп пересматривается и повышается, но при этом повторю, не покидает ощущение, не основанное ни на чем, что недоплачивают.
Если пройду собес и предложат больше кидать все идти к ним? А если это больше станет финалом снова идти куда-то? А если окажется, что соврали и на самом деле это все я получу только через пачку условий? Бежать назад?
Какой-то очень не надежный вариант со сменой рабочего места каждый год...
Какие-то проблемы на ровном месте. Стандартый UIScrollView реализует эту возможность, а коллекции (UITableView, UICollectionView) наследуются от UIScrollView. Что касается подскраливаний, то логику для них можно дописать в делегата UIScrollView и все будет ок.
Даже живя в одной квартие, просто поговорить бывает удобнее по телефону, во время прогулки. Лицом к лицу вообще не нравится, то настроения нет, то занят чем-то, то еще что-то. А так, вышел прогуляться, появилась тема + настроение, набрал да поговорил.
Скажу по секрету: плохо, очень плохо, что у моих родителей было другое мнение. Если бы у них было другое мнение мне бы не пришлось сливать кучу времени на работу, а оставшееся свободное проводить в играх и за чтением хабра.
У вас просто зависимость от детей, избавляйтесь от нее.
Я вот в свои 32 не хочу ни жены ни детей. Вообще не хочу. Никак не хочу. От детей трясет, дети — это такой ужасный раздражающий и отвлекающий фактор, что просто невозможно. Как представлю, что я сел играть в доту, а тут ребенок лезет на руки, так сразу злоба берет и хочется этого ребенка куда-то деть. Вот я его и дел: не создавал. Лишнее это. Глупое.
Мало того, что ребенку придется жить в этом ужасном мире только потому, что его папаша с мамашей верили в важность их генов (а гены на 90%+ у всех одинаковы, вот ведь забава), так еще и самому постоянно тратить жизнь и ресурсы на потребности этого лишнего человека.
В общем, я избавился от детской зависимости, советую вам так же. Если хотите, могу научить играть в компьютерные игры. Пользы в реальном мире не много, как и от кучи остальных дел (самое полезное просто позволяет поддерживать уровень жизни здесь и сейчас, так что «фу такое, но делать надо», остальное бессмысленно), но хотя бы интересно и без всяких неожиданных факторов и бесячих раздражителей.
Умный человек поступает по контексту, выбирает подход исходя из задачи и уместности, остальные...
Как же тяжело бывает объяснить это напарнику, кто везде пихает одно и тоже потому что "а вот 5 лет назад я сделал иначе и мне дали по рукам" (или аналог).
Доступен по документации, но не работает по факту. Как и нет достоверных данных, будет он крешить на 14.0.0 или нет. У меня в практике были случаи, когда апи, доступное с 11.2 реально существовало только в 12.0.
А посему совершенно не понятно, зачем пытаться использовать то, что не имеет смысла до определенной версии iOS. На практике это даст просто больше проблем и, если у меня проблемы с отслеживанием путей установки аппа возникли только с 14.5, то у тех, кому лень дописать .5, эти проблемы были при ближайшем обновлении приложения на всех версиях iOS 14.
Конечно красный цвет — сомнительная история для использования как цвет текста, поэтому к вам обязательно придет дизайнер или заказчик и попросит поменять цвет на другой. В таком случае вы это сможете сделать не более чем за минуту просто переопределив свой primaryTextColor.
Отличный подход, если вы хотите получить 100500 багов в UI, которые задолбаетесь потом находить.
Серебряной пули нет и этот подход не исключение. Как простое пояснение годится, но если кто задается вопросом как делать гибко и ловко, то вот совет: так называемый primary цвет не должен быть глобальным. Их стоит вводить больше чем одну копию, делить либо по модулям, либо, что даже лучше, по сценариям использования. Например, если у нас текст на белом фоне — это одна ситуация, а если он на желтом — это другая. Если мы поменяем цвет текста с красного на синий — проблем не будет. Но если поменяем с красного на желтый — часть мест сломается (желтый на желтом нечитаем). Бороться с этим можно добавлением еще одного цвета, уже для желтого фона. Пусть даже изначально он будет совпадать с цветом для белого фона.
П.С. Не обзывайте цвета так по-дурацки, я задолбался подбирать что есть что, когда работал с facebook sdk и настраивал их контроллер. Распихали как надо в дизайне, обозвали видимо по очередности добавления в код, в итоге primary — подпись под кнопкой, secondary — заголовок в шапке, а thirdary — текст на кнопке. Как я должен догадаться, что мне надо выставить thirdary цвет чтобы задать цвет текста кнопки? И где гарантии, что вместе с этим я не сломал цвет подложки где-то еще, ведь там он мог оказаться таким же, а значит это тоже thirdary! В общем, не делайте так, пишите код для людей, а не для компьютера.
Ну, начнем с того, что в последние годы дока у эплов вполне себе ничего. Да и раньше была не плохой.
Отсутствие описания иногда бывает, не успели дописать, через год обычно появляется. Исключения есть, но обычно это что-то старое, хоть и полезное.
Но что более важно: нельзя узнать как оно работает прочитав описание одного метода. У эплов есть еще руководства (Guidelines) и, более ценные, ролики wwdc. Пока не научился смотреть wwdc тоже не понимал, как можно по доке с чем-то разобраться, особенно когда принципиально новый фреймворк вышел без хорошего описания где-то в начале. А как wwdc начал включать, так оказалось, что норм все.
Так что не все так однобоко, как кажется.
а я вот наоборот, только сильнее убедился, как был прав, что проигнорил все эти непотребства. Сейчас смотрю на их проблемы и на то, кем стали все эти люди (особенно те, за чьей юбкой мог бегать), и радуюсь каждый раз. Считай пронесло, что не «вляпался».
Интересный момент: опять чиновники решили за всех, какая из реальностей лучше :)
Можно подумать, что если реальная реальность не нравится, то запрет сразу заставит ее полюбить. Прямо так и вижу: ой все, интернет нельзя, пойду зарядку для айфона собирать…
вы просто не в «теме» :)
1. apple получает не за приложение, а за покупки приложения и внутри приложения
2. 30% в первый год, далее 15%
3. apple уже что-то говорило про обязательную продажу приложений на mac os через appstore, по идее пока не строго, но со временем они хотят к этому придти
4. ничто не мешает apple принуждать так же совершать покупки внутри приложений на mac os с комиссией.
так что деньги как аргумент — это аргумент, но я не уверен, что он сработает.
в конце концов всегда можно внести ограничения в версию mac os, запускаемую на iPhone.
Ну и кто виноват в том, что вы на это согласились?
Для сравнения, у нас, в РБ, сегодня запускают первую «нашу» АЭС. Строили русские и китайцы. Построена по проекту РФ. Питается только топливом из РФ. Если РФ решит поднять стоимость топлива в 10000 раз, кто будет виноват в том, что эта АЭС не сможет просто взять и отказаться от этого топлива? Разве РФ?
Если уж пишите tutorial, писать его на максимально корректных примерах, потому что те, то будет этому tutorial доверять, будут брать код отсюда как есть.
Во все не вникал, но вот, например, этот пример отлично демонстрирует как написать не надежный код, который будет ломаться если случится ситуация, когда второй вызов requestProducts случится до того, как отработает первый.
Можно было бы сказать, что эта ситуация не рассматривалась вовсе и пусть думают сами, но ведь вызов
productRequest?.cancel()
присутствует, что говорит о том, что данная функция позволяет вызывать ее несколько раз подряд.
Так вот проблема здесь в том, что completion (который в доке часто обызвают в completionHandler, но то спорный момент) просто сохраняется, заменяя собой предыдущий, но не вызывая предыдущий.
Если писать код хорошо, нужно либо не допускать таких ситуаций, либо бросать ошибку в предыдущий completion до того, как он затрется, либо просто их накапливать.
В текущей же реализации код, который вызвал requestProducts ранее, просто не получит ответа через completion и окажется в вечном ожидании.
Возможно, это вам лично так удобно. У меня хоть и мелкая (на десяток человек), но статистика — большинство жутко недовольно и допускает такое только как спец-аварийный вариант.
ну что я могу сказать, на собеседованиях я завернул уже 4 человека с биркой seniour, последний имел на 2 года больше опыта, чем я, и при этом не знал элементарных основ.
Так что да, кому что нравится. У нас в компании народ отборный, поэтому часто мысли совпадают, а посему мало кто стремится растягивать строки до невероятных широт.
А теперь попробуйте сохранить текст комментария в архиве.
unicode нам поможет. Если его мало — base64 нам поможет. Не вижу вообще никаких проблем куда-то сохранить текст. Самая легкая из задач. Вон, и habr с ней справляется в лучшем виде.
Автор возмущён тем, что десктоп задвигается на второй план и все больше компаний делают упор на мобильный рынок. Под мобильник делается классное приложение, а под десктоп плохонькая веб страничка и на этом все. При этом посыл автора «че за фигня, десктоп жеж круче мобилки и важнее ее». Я привёл в пример меня и показал, что это уже не совсем так. Не берусь судить хорошо ли это, но мобильник сегодня — это как маленький десктоп для кучи рутинных задач. Он не заменяет десктоп на все 100, но во многих не очень сложных рутинных задачах справляется лучше. И это так не из-за искусственного перекоса, а потому что мобильник просто стал на это способен.
Вот сразу и передёрг про "300 символов". На самом деле, я думаю, у вас слишком простые задачи :)
100 символьный текст отлично читается на мобилке. У меня были разные проекты, в истории 10 лет работы в продуктовой компании, и нет, я не делаю код ревью с мобильника каждый день. Но несколько раз я смотрел код с мобильника, когда было лень включать десктоп или был в дороге. И само собой правки были не на уровне «переписали пол проекта». Хотя, если был просто новый компонент — он тоже на ура читался с мобилки. Сложнее всего смотреть сложный дифф с кучей мелких изменений. Да ещё и на длиннющих строках. Но с этим и на десктопе бывают проблемы. Мне раз попался файл, где вся последовательность из блоков (лямбда функций) не умещалась на моих 27 дюймах. От начала до конца надо было примерно 50 дюймов. Так что, косяк тут явно не в мобильнике.
"Красивая вёрстка" это голубая полоска слева? Не вижу ничего такого, что объясняло бы слово "красиво"… ну ладно, вот я для данного конкретного постинга включил галочку Markdown.
Ага, она самая. Красиво же, и сразу читается лучше.
Ну допустим, сходил, даже оффер получил, где гарантия, что я реально буду столько зарабатывать? И что будет с дальнейшей перспективой? К примеру, на текущем месте работы так или иначе, а зп пересматривается и повышается, но при этом повторю, не покидает ощущение, не основанное ни на чем, что недоплачивают.
Если пройду собес и предложат больше кидать все идти к ним? А если это больше станет финалом снова идти куда-то? А если окажется, что соврали и на самом деле это все я получу только через пачку условий? Бежать назад?
Какой-то очень не надежный вариант со сменой рабочего места каждый год...
В вакансиях всегда указано "зп по результатам собеседования" или "возможная зп от $100 до $10000".
Теперь осталось узнать, как понять платят мне нормально или не доплачивают?
Какие-то проблемы на ровном месте. Стандартый UIScrollView реализует эту возможность, а коллекции (UITableView, UICollectionView) наследуются от UIScrollView. Что касается подскраливаний, то логику для них можно дописать в делегата UIScrollView и все будет ок.
Даже живя в одной квартие, просто поговорить бывает удобнее по телефону, во время прогулки. Лицом к лицу вообще не нравится, то настроения нет, то занят чем-то, то еще что-то. А так, вышел прогуляться, появилась тема + настроение, набрал да поговорил.
Скажу по секрету: плохо, очень плохо, что у моих родителей было другое мнение. Если бы у них было другое мнение мне бы не пришлось сливать кучу времени на работу, а оставшееся свободное проводить в играх и за чтением хабра.
Я вот в свои 32 не хочу ни жены ни детей. Вообще не хочу. Никак не хочу. От детей трясет, дети — это такой ужасный раздражающий и отвлекающий фактор, что просто невозможно. Как представлю, что я сел играть в доту, а тут ребенок лезет на руки, так сразу злоба берет и хочется этого ребенка куда-то деть. Вот я его и дел: не создавал. Лишнее это. Глупое.
Мало того, что ребенку придется жить в этом ужасном мире только потому, что его папаша с мамашей верили в важность их генов (а гены на 90%+ у всех одинаковы, вот ведь забава), так еще и самому постоянно тратить жизнь и ресурсы на потребности этого лишнего человека.
В общем, я избавился от детской зависимости, советую вам так же. Если хотите, могу научить играть в компьютерные игры. Пользы в реальном мире не много, как и от кучи остальных дел (самое полезное просто позволяет поддерживать уровень жизни здесь и сейчас, так что «фу такое, но делать надо», остальное бессмысленно), но хотя бы интересно и без всяких неожиданных факторов и бесячих раздражителей.
Умный человек поступает по контексту, выбирает подход исходя из задачи и уместности, остальные...
Как же тяжело бывает объяснить это напарнику, кто везде пихает одно и тоже потому что "а вот 5 лет назад я сделал иначе и мне дали по рукам" (или аналог).
А посему совершенно не понятно, зачем пытаться использовать то, что не имеет смысла до определенной версии iOS. На практике это даст просто больше проблем и, если у меня проблемы с отслеживанием путей установки аппа возникли только с 14.5, то у тех, кому лень дописать .5, эти проблемы были при ближайшем обновлении приложения на всех версиях iOS 14.
Никогда не понимал, если фича доступна с iOS 14.5, почему ее внедряют с 14.0? Что сложного написать #available(iOS 14.5, *)?
Отличный подход, если вы хотите получить 100500 багов в UI, которые задолбаетесь потом находить.
Серебряной пули нет и этот подход не исключение. Как простое пояснение годится, но если кто задается вопросом как делать гибко и ловко, то вот совет: так называемый primary цвет не должен быть глобальным. Их стоит вводить больше чем одну копию, делить либо по модулям, либо, что даже лучше, по сценариям использования. Например, если у нас текст на белом фоне — это одна ситуация, а если он на желтом — это другая. Если мы поменяем цвет текста с красного на синий — проблем не будет. Но если поменяем с красного на желтый — часть мест сломается (желтый на желтом нечитаем). Бороться с этим можно добавлением еще одного цвета, уже для желтого фона. Пусть даже изначально он будет совпадать с цветом для белого фона.
П.С. Не обзывайте цвета так по-дурацки, я задолбался подбирать что есть что, когда работал с facebook sdk и настраивал их контроллер. Распихали как надо в дизайне, обозвали видимо по очередности добавления в код, в итоге primary — подпись под кнопкой, secondary — заголовок в шапке, а thirdary — текст на кнопке. Как я должен догадаться, что мне надо выставить thirdary цвет чтобы задать цвет текста кнопки? И где гарантии, что вместе с этим я не сломал цвет подложки где-то еще, ведь там он мог оказаться таким же, а значит это тоже thirdary! В общем, не делайте так, пишите код для людей, а не для компьютера.
Отсутствие описания иногда бывает, не успели дописать, через год обычно появляется. Исключения есть, но обычно это что-то старое, хоть и полезное.
Но что более важно: нельзя узнать как оно работает прочитав описание одного метода. У эплов есть еще руководства (Guidelines) и, более ценные, ролики wwdc. Пока не научился смотреть wwdc тоже не понимал, как можно по доке с чем-то разобраться, особенно когда принципиально новый фреймворк вышел без хорошего описания где-то в начале. А как wwdc начал включать, так оказалось, что норм все.
Так что не все так однобоко, как кажется.
Ну и само собой: не женат и не жалею :)
кстати про
мне вот всегда говорили, что я не правильный и нуждаюсь в лечении / корректировке именно потому что я за юбками и не бегал…
сейчас вот читаю ваш комментарий и возникает вопрос: кто из судей прав то?
Можно подумать, что если реальная реальность не нравится, то запрет сразу заставит ее полюбить. Прямо так и вижу: ой все, интернет нельзя, пойду зарядку для айфона собирать…
Скорее просто больше травиться чем-нибудь будут.
1. apple получает не за приложение, а за покупки приложения и внутри приложения
2. 30% в первый год, далее 15%
3. apple уже что-то говорило про обязательную продажу приложений на mac os через appstore, по идее пока не строго, но со временем они хотят к этому придти
4. ничто не мешает apple принуждать так же совершать покупки внутри приложений на mac os с комиссией.
так что деньги как аргумент — это аргумент, но я не уверен, что он сработает.
в конце концов всегда можно внести ограничения в версию mac os, запускаемую на iPhone.
Для сравнения, у нас, в РБ, сегодня запускают первую «нашу» АЭС. Строили русские и китайцы. Построена по проекту РФ. Питается только топливом из РФ. Если РФ решит поднять стоимость топлива в 10000 раз, кто будет виноват в том, что эта АЭС не сможет просто взять и отказаться от этого топлива? Разве РФ?
Есть предложение.
Если уж пишите tutorial, писать его на максимально корректных примерах, потому что те, то будет этому tutorial доверять, будут брать код отсюда как есть.
Во все не вникал, но вот, например, этот пример отлично демонстрирует как написать не надежный код, который будет ломаться если случится ситуация, когда второй вызов requestProducts случится до того, как отработает первый.
Можно было бы сказать, что эта ситуация не рассматривалась вовсе и пусть думают сами, но ведь вызов присутствует, что говорит о том, что данная функция позволяет вызывать ее несколько раз подряд.
Так вот проблема здесь в том, что completion (который в доке часто обызвают в completionHandler, но то спорный момент) просто сохраняется, заменяя собой предыдущий, но не вызывая предыдущий.
Если писать код хорошо, нужно либо не допускать таких ситуаций, либо бросать ошибку в предыдущий completion до того, как он затрется, либо просто их накапливать.
В текущей же реализации код, который вызвал requestProducts ранее, просто не получит ответа через completion и окажется в вечном ожидании.
ну что я могу сказать, на собеседованиях я завернул уже 4 человека с биркой seniour, последний имел на 2 года больше опыта, чем я, и при этом не знал элементарных основ.
Так что да, кому что нравится. У нас в компании народ отборный, поэтому часто мысли совпадают, а посему мало кто стремится растягивать строки до невероятных широт.
unicode нам поможет. Если его мало — base64 нам поможет. Не вижу вообще никаких проблем куда-то сохранить текст. Самая легкая из задач. Вон, и habr с ней справляется в лучшем виде.
Автор возмущён тем, что десктоп задвигается на второй план и все больше компаний делают упор на мобильный рынок. Под мобильник делается классное приложение, а под десктоп плохонькая веб страничка и на этом все. При этом посыл автора «че за фигня, десктоп жеж круче мобилки и важнее ее». Я привёл в пример меня и показал, что это уже не совсем так. Не берусь судить хорошо ли это, но мобильник сегодня — это как маленький десктоп для кучи рутинных задач. Он не заменяет десктоп на все 100, но во многих не очень сложных рутинных задачах справляется лучше. И это так не из-за искусственного перекоса, а потому что мобильник просто стал на это способен.
100 символьный текст отлично читается на мобилке. У меня были разные проекты, в истории 10 лет работы в продуктовой компании, и нет, я не делаю код ревью с мобильника каждый день. Но несколько раз я смотрел код с мобильника, когда было лень включать десктоп или был в дороге. И само собой правки были не на уровне «переписали пол проекта». Хотя, если был просто новый компонент — он тоже на ура читался с мобилки. Сложнее всего смотреть сложный дифф с кучей мелких изменений. Да ещё и на длиннющих строках. Но с этим и на десктопе бывают проблемы. Мне раз попался файл, где вся последовательность из блоков (лямбда функций) не умещалась на моих 27 дюймах. От начала до конца надо было примерно 50 дюймов. Так что, косяк тут явно не в мобильнике.
Ага, она самая. Красиво же, и сразу читается лучше.