Не буду копаться щас в гугле, но вообще была куча статей плюс кажется даже в НЙ Таймс что раньше беленькие наушники эпол были буквально манком для грабителей и даже полиций НЙ выпускала рекомендацию менять дефолтные наушники на другие в НЙ. Когда эпол ввела там эти секьюрити чипы что телефон хрен перерошьешь - грабежи упали драматически, потому что на краденые айфоны упали цены на черном рынке и они могли уже идти только на запчасти. Я это не к тому что эпол не барыги. Я к тому что оценивая их действия надо исходить из того что их главный рынок это штаты. А штаты это уникальная страна со своей уникальной спецификой. Почти такая же уникальная как Китай. Я помню еще знакомый из Сан Франциско мне рассказывал что видел как грабители выхватывали телефон и увидев что это айфон - выбрасывали.
Приятно что вы со мной соглашаетесь, но давай-те таки не путать твердое с длинным. Одно дело понимание массивов, хэш-таблиц и структур данных это одно, а навык разворачивания RTB дерева не выходя за границы L1 кэша микропроцессора — это другое. И этот навык требуется лучшем случае 0.1 проценте компаний и обычно это отражено в спецификации работы. Этот навык можно отточить. Но он будет абсолютно бесполезен в остальных случаях. А вот насколько грамотно человек будет подходить к архитектуре, читаемости, расширяемости и майнтейнабилити кода это никак не скажет. Понятно, что в дверь FAANGов стучится весь мир — они могут творить что угодно со своими собеседованиями. Но как я уже отметил этот фильтр работает для них не всегда, а теперь мы еще и имеем целую саб-индустрию которая ориентирована помочь людям пройти в FAANG. Прям как оптимизация сайта под поисковую выдачу гугла. Что в целом не плохо. Но оставим FAANGи в покое, работает для них и ладно, они и правда в уникальной ситуации.
Что подобный фильтр дает остальным компаниям мне не ясно. Особенно учитывая что они зачастую сидят по уши в легаси коде написанном вот такими вот LeetCode девелоперами (прошу прощениям за оценочный термин) и не знают что с ним делать. И прямым текстом тебе говорят "У нас много проблем и нам надо с этим взлететь".
ЗЫ: Я тут должен отметить что у нас тут с вами лирическое отступление не связанное непосредственно с Вашей статьей, а с топиком в комментарии.
Я обычно в таких случаях заканчиваю интервью и говорю: "спасибо большое, но мы видимо не сработаемся, я не пришел сюда красно-черные деревья разворачивать". Я там еще понимаю когда FAANGи могут гнать что хотят, хотя я знаю людей которых они наняли которым было не лень год на LeetCode сидеть и хихикаю. Но когда какой то невнятный стартап или какой нить оффлайн бизнес монстр что то подобное начинает выдавать — это конечно полнейшая глупость. В общем, стоит видеть лица собеседующих в этот момент.
ЗЫ: Самое забавное что один из FAANGов мне звонит с периодичностью в 2 года и мы заканчиваем разговор одинаково "Я к вам в Лондон летал? Летал. Мы 7 часов искали наибольший общий палиндром и тд? Искали. Нашли? Нашли. Вас все равно что то не устроило? Не устроило. Я снова делать тоже самое не хочу и время на алгоритмы не тратил с тех пор, у меня есть более интересные дела. — Ну может вы попробуете, мы пришлем вам материалы как готовиться. — Нет спасибо. Тем более у вас там очередь со всего шарика стоит, что вы мучаете бедного узбекского мальчика.". И так переодически повторяется. А благодаря вышеупомянутым людям я еще и прекрасно понимаю что я и не очень хочу там работать. Вот так и развлекаем друг друга :)
ЗЗЫ: Вообще я не понимаю рекрутеров. Если у человека есть опенсорные проекты — там можно все сказать про то как он кодит и как архитектурно подходит к делу. А по тому как он закрывает ишью — можно понять какой он в общении. Можно сразу пропускать все стадии и если все устраивает сразу обсуждать деньги, а не ускорять энтропию вселенной бессмысленным бредом.
Примерно так и есть. Никто не сказал что каждая часть вайпера это одна сущность. И его просто стоит держать в голове что бы задумываться о тех же протоколах которые как вы тоже верно отметили тоже должны быть.
Я не являюсь адептом вайпера если кому то показалось. Но практически любой код который я видел и который мне нравится будет условно разделен на подобные слои. А мой собственный уж точно.
А собственно никто и не сказал что вайпер это фреймворк. Фреймворк это что то что можно загрузить как библиотеку. Вайпер всего лишь позволяет не ломать голову над названиями разных сущностей из разных слоев. Остальное от лукавого.
Вы фактически сказали тоже самое что и я только назвав тоже самое другими словами. Все должно быть составным. И на этом можно остановиться потому что мыслим мы одинаково. Просто забудьте слово вайпер. И мы тут же окажемся в согласии о том что автор понимает вайпер слишком буквально — как 5 сущностей…
ЗЫ: я нигде не сказал что авторизация является частью конпки лайк.
Я хотел бы вам написать "Вы не понимаете — это другое" :) Но напишу так. Все должно быть сбалансировано конечно. И то что вы пишете имеет смысл если это какая то уникальная кнопка. Понятия слишком много не существует если того требует задача. Но если мы вернемся к кнопке лайк и посмотрим на ее бизнес задачу, допустим что бы поставить лайк пользователь должен быть авторизован, то есть только кликнув на кнопку пользователю может быть показан логин экран, после успешного прохождения авторизации (а может и процесса создания аккаунта) нужно будет потом отправить состояние лайк на бэкэнд и обновить состояние кнопки. Вы же не будете разруливать это в каждой вью модели (или бог знает что там экраном управляет) экрана который поддерживает лайки? Понятно что вы как то вычлените это. Но зачем вью модели экрана в целом знать о том что что то на экране может быть лайкнуто? А я часто вижу код что каждая вью модель знает про то что есть кнопка/ки лайк и редиректит в эту вычлененую чать -то есть фактически бессмысленный копи паст? При этом копка лайк допустим разная если это лист сущностей или экран деталей сущности. А еще с текстом без текста, а еще отправляет разную аналитику но выглядит при этом одинаково? А еще возможно за кнопку лайк отвечает вообще другая команда? Вот вам тут и пригодится и слабая связанность и отдельный вайпер для кнопки. Отделяем мух от котлет и властвуем.
У нее действительно слабая связанность. Просто ее часто неправильно готовят. Представим что у вас в приложении есть несколько UITableView, для тейбл вью у вас один вайпер на всех, у каждой ячейки в таблице свой собственный вайпер — позволяет вам переиспользовать ячейку в разных таблицах — ей не нужно знать где она. Допустим одна и таже ячейка может иметь или не иметь кнопку "Like" — извлекаем ее из ячейки и делаем ей собственный вайпер. Вот вам и слабая связанность и полное переиспользование кода и Р. Мартин счастлив. Впрочем это относится не только к вайперу, но и ко всяким вью моделям и тд.
Я даже больше скажу - улицу переходишь и уже по другому говорят. :)
Спасибо за статью. А можно добавить чуть больше подробностей о физиологии и процессах в будущем?
Не буду копаться щас в гугле, но вообще была куча статей плюс кажется даже в НЙ Таймс что раньше беленькие наушники эпол были буквально манком для грабителей и даже полиций НЙ выпускала рекомендацию менять дефолтные наушники на другие в НЙ. Когда эпол ввела там эти секьюрити чипы что телефон хрен перерошьешь - грабежи упали драматически, потому что на краденые айфоны упали цены на черном рынке и они могли уже идти только на запчасти. Я это не к тому что эпол не барыги. Я к тому что оценивая их действия надо исходить из того что их главный рынок это штаты. А штаты это уникальная страна со своей уникальной спецификой. Почти такая же уникальная как Китай. Я помню еще знакомый из Сан Франциско мне рассказывал что видел как грабители выхватывали телефон и увидев что это айфон - выбрасывали.
С одной стороны согласен с вам, с другой стороны делает кражу устройства бесмысленной
А разве propertyWrapper не только для var?
Что то мне кажется было проще транслятор, который бы котлин в свифт переводил. Помню был такой лет 15 назад, который Си Шарп в джаву переводил.
Приятно что вы со мной соглашаетесь, но давай-те таки не путать твердое с длинным. Одно дело понимание массивов, хэш-таблиц и структур данных это одно, а навык разворачивания RTB дерева не выходя за границы L1 кэша микропроцессора — это другое. И этот навык требуется лучшем случае 0.1 проценте компаний и обычно это отражено в спецификации работы. Этот навык можно отточить. Но он будет абсолютно бесполезен в остальных случаях. А вот насколько грамотно человек будет подходить к архитектуре, читаемости, расширяемости и майнтейнабилити кода это никак не скажет. Понятно, что в дверь FAANGов стучится весь мир — они могут творить что угодно со своими собеседованиями. Но как я уже отметил этот фильтр работает для них не всегда, а теперь мы еще и имеем целую саб-индустрию которая ориентирована помочь людям пройти в FAANG. Прям как оптимизация сайта под поисковую выдачу гугла. Что в целом не плохо. Но оставим FAANGи в покое, работает для них и ладно, они и правда в уникальной ситуации.
Что подобный фильтр дает остальным компаниям мне не ясно. Особенно учитывая что они зачастую сидят по уши в легаси коде написанном вот такими вот LeetCode девелоперами (прошу прощениям за оценочный термин) и не знают что с ним делать. И прямым текстом тебе говорят "У нас много проблем и нам надо с этим взлететь".
ЗЫ: Я тут должен отметить что у нас тут с вами лирическое отступление не связанное непосредственно с Вашей статьей, а с топиком в комментарии.
Я обычно в таких случаях заканчиваю интервью и говорю: "спасибо большое, но мы видимо не сработаемся, я не пришел сюда красно-черные деревья разворачивать". Я там еще понимаю когда FAANGи могут гнать что хотят, хотя я знаю людей которых они наняли которым было не лень год на LeetCode сидеть и хихикаю. Но когда какой то невнятный стартап или какой нить оффлайн бизнес монстр что то подобное начинает выдавать — это конечно полнейшая глупость. В общем, стоит видеть лица собеседующих в этот момент.
ЗЫ: Самое забавное что один из FAANGов мне звонит с периодичностью в 2 года и мы заканчиваем разговор одинаково "Я к вам в Лондон летал? Летал. Мы 7 часов искали наибольший общий палиндром и тд? Искали. Нашли? Нашли. Вас все равно что то не устроило? Не устроило. Я снова делать тоже самое не хочу и время на алгоритмы не тратил с тех пор, у меня есть более интересные дела. — Ну может вы попробуете, мы пришлем вам материалы как готовиться. — Нет спасибо. Тем более у вас там очередь со всего шарика стоит, что вы мучаете бедного узбекского мальчика.". И так переодически повторяется. А благодаря вышеупомянутым людям я еще и прекрасно понимаю что я и не очень хочу там работать. Вот так и развлекаем друг друга :)
ЗЗЫ: Вообще я не понимаю рекрутеров. Если у человека есть опенсорные проекты — там можно все сказать про то как он кодит и как архитектурно подходит к делу. А по тому как он закрывает ишью — можно понять какой он в общении. Можно сразу пропускать все стадии и если все устраивает сразу обсуждать деньги, а не ускорять энтропию вселенной бессмысленным бредом.
Примерно так и есть. Никто не сказал что каждая часть вайпера это одна сущность. И его просто стоит держать в голове что бы задумываться о тех же протоколах которые как вы тоже верно отметили тоже должны быть.
Я не являюсь адептом вайпера если кому то показалось. Но практически любой код который я видел и который мне нравится будет условно разделен на подобные слои. А мой собственный уж точно.
А собственно никто и не сказал что вайпер это фреймворк. Фреймворк это что то что можно загрузить как библиотеку. Вайпер всего лишь позволяет не ломать голову над названиями разных сущностей из разных слоев. Остальное от лукавого.
Вы фактически сказали тоже самое что и я только назвав тоже самое другими словами. Все должно быть составным. И на этом можно остановиться потому что мыслим мы одинаково. Просто забудьте слово вайпер. И мы тут же окажемся в согласии о том что автор понимает вайпер слишком буквально — как 5 сущностей…
ЗЫ: я нигде не сказал что авторизация является частью конпки лайк.
Я хотел бы вам написать "Вы не понимаете — это другое" :) Но напишу так. Все должно быть сбалансировано конечно. И то что вы пишете имеет смысл если это какая то уникальная кнопка. Понятия слишком много не существует если того требует задача. Но если мы вернемся к кнопке лайк и посмотрим на ее бизнес задачу, допустим что бы поставить лайк пользователь должен быть авторизован, то есть только кликнув на кнопку пользователю может быть показан логин экран, после успешного прохождения авторизации (а может и процесса создания аккаунта) нужно будет потом отправить состояние лайк на бэкэнд и обновить состояние кнопки. Вы же не будете разруливать это в каждой вью модели (или бог знает что там экраном управляет) экрана который поддерживает лайки? Понятно что вы как то вычлените это. Но зачем вью модели экрана в целом знать о том что что то на экране может быть лайкнуто? А я часто вижу код что каждая вью модель знает про то что есть кнопка/ки лайк и редиректит в эту вычлененую чать -то есть фактически бессмысленный копи паст? При этом копка лайк допустим разная если это лист сущностей или экран деталей сущности. А еще с текстом без текста, а еще отправляет разную аналитику но выглядит при этом одинаково? А еще возможно за кнопку лайк отвечает вообще другая команда? Вот вам тут и пригодится и слабая связанность и отдельный вайпер для кнопки. Отделяем мух от котлет и властвуем.
У нее действительно слабая связанность. Просто ее часто неправильно готовят. Представим что у вас в приложении есть несколько UITableView, для тейбл вью у вас один вайпер на всех, у каждой ячейки в таблице свой собственный вайпер — позволяет вам переиспользовать ячейку в разных таблицах — ей не нужно знать где она. Допустим одна и таже ячейка может иметь или не иметь кнопку "Like" — извлекаем ее из ячейки и делаем ей собственный вайпер. Вот вам и слабая связанность и полное переиспользование кода и Р. Мартин счастлив. Впрочем это относится не только к вайперу, но и ко всяким вью моделям и тд.
Я бы поставил минут просто за "Мне нравится XCode". Но не буду :)
Какой вы программист?
пришел, увидел, наследил
Это правда по Р.Мартину?
+1
Хорошо бы упомянуть такой паттерн для UI тестов как Робот
Вычеркивайте меня тоже. Этот тест никакого отношения к Мартину не имеет.
С языка снял :)
Плюс один.
Cartage всегда был странным. Как будто зонтик в кармане открываешь каждый раз.