Метод двух указателей
Одна из базовых техник решения алгоритмов.
В примерах видна суть: мы пользуемся тем, что при увеличении значения одного указателя значение другого указателя тоже может только увеличиваться. Если мы перебираем i в порядке возрастания, то j тоже будет только возрастать — поэтому не надо перебирать каждый раз заново, можно просто продолжать с предыдущего значения.
Когда применять?
Если требуется решить задачу с поиском подмассивов или подстрок.
Многие задачи, решаемые двумя указателями, можно решить и бинпоиском ценой дополнительного logN в сложности решения.
Одна из базовых техник решения алгоритмов.
В примерах видна суть: мы пользуемся тем, что при увеличении значения одного указателя значение другого указателя тоже может только увеличиваться. Если мы перебираем i в порядке возрастания, то j тоже будет только возрастать — поэтому не надо перебирать каждый раз заново, можно просто продолжать с предыдущего значения.
Когда применять?
Если требуется решить задачу с поиском подмассивов или подстрок.
Многие задачи, решаемые двумя указателями, можно решить и бинпоиском ценой дополнительного logN в сложности решения.
❤5👍2🔥1🌭1
Наш любимый паттерн в иос. Куда не глянь в системные АПИ, то почти везде синглтон. Нужно разобрать в чем же прикол и когда же будет полезен.
Назначение:
Гарантирует, что у класса есть только один экземпляр, и предоставляет к нему глобальную точку доступа.
Мотивация:
Для некоторых классов важно, чтобы существовал только один экземпляр. Хотя в системе может быть много принтеров, но возможен лишь один спулер. Должны быть только одна файловая система и единственный оконный менеджер. В цифровом фильтре может находиться только один аналого цифровой преобразователь (АЦП). Бухгалтерская система обслуживает только одну компанию.
Применимость:
- должен быть ровно один экземпляр некоторого класса, легко доступный всем клиентам;
- Предоставляет глобальную точку доступа. Единственный экземпляр должен расширяться путем порождения подклассов, и клиентам нужно иметь возможность работать с расширенным экземп ляром без модификации своего кода.
- Клиенты должны получать только доступ через свойство shared
Почти реализации требуют скрыть конструктор по умолчанию и создать публичный статический метод, который и будет контролировать жизненный цикл.
- Нарушает принцип единственной ответственности класса.
- Маскирует плохой дизайн.
- Проблемы многопоточности.
- Требует постоянного создания Mock-объектов при юнит-тестировании.
- Какой-нибудь душнила прибежит и скажет нужен обязательный приватный init
Пример взят из официальной доки эйпла
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥5👍4💅2
Не решал 100 задач на литкоде — не программист
Ну че, кто пойдет тренить алгосы в топ 2 ит компанию СНГ? (После авито)
https://yandex.ru/yaintern/algorithm-training
Ну че, кто пойдет тренить алгосы в топ 2 ит компанию СНГ? (После авито)
https://yandex.ru/yaintern/algorithm-training
Тренировки Яндекса по алгоритмам, ML и DevOps
Новый сезон Тренировок по алгоритмам и ML
👍8
Как плохой дизайн стоил шесть разрабов
Когда сталкивался с плохим дизайном, то не сразу это понимал. Еще чаще не понимают те, кто запроектировал. Эффект икеи. То когнитивное искажение, что увеличивает в глазах стоимость дерьма, сделанное своими руками.
Самым запоминающим случаем стала подработка парт-тайм в одном крупном приложении. Только после заподозрил неладное, когда уже сказали об ушедших пяти разрабах до меня и как же долго меня искали.
Плохой дизайн — это когда простые вещи долгие и сложные. Хочешь открыть дверь в туалет, но на этой двери замок, ключ к которому генерится рандомно. Зачем? Внезапно стал грабителем банка био-материалов. В добавок появляются неожиданные сюрпризы. Нажимаешь на смыв, а выключается свет. Выключатель же выполняет функцию смыва. Почему?
Мы хотим обвинить других в непонимании наших дизайнерских решений. Ведь я же живу, удобно. А вон те, смотрите, ноют. Но всё стоит на общих правилах. Первый из них — не изобретай велосипед.
Хороший дизайн сложно достичь и легко потерять. Оригинальность фразы из пабликов вк, но суть передает хорошо. Отлично запроектированная система почти никогда не получится с первого раза. Для нее нужен хороший опыт, тонкости которого приходят со временем. Опыт приводит к проверенным практикам. Проверенные практики избавляют от изобретения велосипедов. Но это не значит, что мы должны от него отказываться. Хороший дизайн полезен для новичков и тебя, если код требует сопровождения.
Еще бывает, что соло разработчики специально шифруют решения. Искусственно повышая свою стоимость, изобретая паттерны, которые поймут только они. Приковывают себя наручниками к батареи и глатают ключ. Спустя время другие же просто не захотят жить в этом болоте. А тебе этот мир стал абсолютно понятным.
Прошедшие временем практики облегчают разработку. Особенно новым разработчикам. Каждый раз изобретая что-то свое лучше задавать вопрос "А не делал ли кто-то это до меня?". Почти всегда ответ будет, что делал. Следующий вопрос: "А чем мое изобретение лучше?". Почти всегда ответ будет, что ничем.
С помощью общих паттернов можно улучшить порог вхождения, документацию и сопровождение. Да и в конце концов деньги и время. А если это не важно, то большой вопрос зачем ты это делаешь.
P.S. Если ты подумал про дизайн интерфейсов, то перечитай
Когда сталкивался с плохим дизайном, то не сразу это понимал. Еще чаще не понимают те, кто запроектировал. Эффект икеи. То когнитивное искажение, что увеличивает в глазах стоимость дерьма, сделанное своими руками.
Самым запоминающим случаем стала подработка парт-тайм в одном крупном приложении. Только после заподозрил неладное, когда уже сказали об ушедших пяти разрабах до меня и как же долго меня искали.
Плохой дизайн — это когда простые вещи долгие и сложные. Хочешь открыть дверь в туалет, но на этой двери замок, ключ к которому генерится рандомно. Зачем? Внезапно стал грабителем банка био-материалов. В добавок появляются неожиданные сюрпризы. Нажимаешь на смыв, а выключается свет. Выключатель же выполняет функцию смыва. Почему?
Мы хотим обвинить других в непонимании наших дизайнерских решений. Ведь я же живу, удобно. А вон те, смотрите, ноют. Но всё стоит на общих правилах. Первый из них — не изобретай велосипед.
Хороший дизайн сложно достичь и легко потерять. Оригинальность фразы из пабликов вк, но суть передает хорошо. Отлично запроектированная система почти никогда не получится с первого раза. Для нее нужен хороший опыт, тонкости которого приходят со временем. Опыт приводит к проверенным практикам. Проверенные практики избавляют от изобретения велосипедов. Но это не значит, что мы должны от него отказываться. Хороший дизайн полезен для новичков и тебя, если код требует сопровождения.
Еще бывает, что соло разработчики специально шифруют решения. Искусственно повышая свою стоимость, изобретая паттерны, которые поймут только они. Приковывают себя наручниками к батареи и глатают ключ. Спустя время другие же просто не захотят жить в этом болоте. А тебе этот мир стал абсолютно понятным.
Прошедшие временем практики облегчают разработку. Особенно новым разработчикам. Каждый раз изобретая что-то свое лучше задавать вопрос "А не делал ли кто-то это до меня?". Почти всегда ответ будет, что делал. Следующий вопрос: "А чем мое изобретение лучше?". Почти всегда ответ будет, что ничем.
С помощью общих паттернов можно улучшить порог вхождения, документацию и сопровождение. Да и в конце концов деньги и время. А если это не важно, то большой вопрос зачем ты это делаешь.
P.S. Если ты подумал про дизайн интерфейсов, то перечитай
👍8💯3
Поговорим о не особо популярных паттернах, но встречающихся гораздо чаще, чем мы ожидаем. На секунду даже удивился, что это устаканенный паттерн.
Один раз я встречал его на горе проекте, который взял концепцию ReactorKit, но смешал это с Worker'ами и Observer'ами.
Реакторы идеально ложатся на event-driven архитектуры. Где у нас есть общее событие для приложения, которое может повлиять на состояние экранов в разных местах. Допустим достижение нового уровня изменит наносимый и получаемый урон, откроет новые диалоги и локации.
Реактор — это тот паттерн, который поможет управлять нашими событиями. Он как телефоный оперетор, который отвечает на звонки и переводит их на необходимые контакты.
В мире иос — реактором можно назвать обработку нажатий. Где есть Event Loop, который СИНХРОННО по-умолчанию выполняет обработку событий: тачи, таймеры, сигналы ОС. Очень важная деталь в синхронности, потому что если асинхронно, то это паттерн проактор.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍59
В авито есть общие ценности. Я о них уже писал в начале карьеры и напишу о них на 9м месяце.
Больше всех мне нравится ценность «действуй масштабно и смело». С ней даже произошло пару забавных моментов. О них позже.
Эта ценность стала понятней после десятков спринтов, а еще сильнее, когда начал делать симулятор иосера. Она говорит об умении отпустить задачи.
Теперь о забавных ситуациях. Сама ценность говорит о потенциальном скоп-дропе, о задачах на которые ты согласился, но потом отбросил из-за низкой приоритетности. В этот момент владельцы этих задач могут написать нехороший фидбэк на перф ревью. Ведь их задачи не масштабные и амбициозные по-твоему мнению.
Благо этот вопрос решается здравым смыслом и оценками большинства.
Это очень важный принцип, который помогает в целеполагании и развитии.
Зрелый разработчик может опустить задачу с минимальным импактом пожертвовав немного внешними показателями, ради большей выгоды. Пусть даже ее не получив и потерпел поражение. Сама смелость приветствуется
Главное часто не проигрывать 😉
Please open Telegram to view this post
VIEW IN TELEGRAM
👍6❤2🔥2
Event Loop — это цикл, который обрабатывает события. Это не уникальная особенность iOS платформы. Такой механизм почти всегда используются в графических интерфейсах (Windows) и на серверах (node.js) .
События, которые обрабатывает Event Loop:
- Нажатие кнопок, клавиатуры
- Вводные данные от устройств, датчиков
- Сообщения от других потоков и программ
У каждого потока есть свой собственный Event Loop, но он может не работать и придется запускать самому.
Автор статьи сам с нуля делает свой Event Loop. Очень полезно понять как все работает кодом, когда же почти всегда о ранлупе говорят только концептуально. В cтатье и ограничение иттераций, и реализация очереди для тасок с нуля
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥14⚡1👍1
Что будет в консоли?
Anonymous Quiz
2%
С, B, A, A
17%
B, C, A, C
16%
A, B, C, C
2%
A, C, B, C
41%
A, B, C
1%
C, A, B
20%
B, C
👍5🔥1
Нет смысла повторять, что для итшника уметь учиться — жизненная необходимость. В отличии от других консервативных сфер, где технологии и навыки не меняются десятилетия, наш инструмент работы может измениться следующим апдейтом.
Мы в такой сфере, что любой навык может устареть еще на этапах согласования и утверждения учебного материала. Хоть нас всех в будущем заменят chatGPT и ИИ, все универы перестанут быть нужны и люди станут лишними. Вот уже в пятый раз получаю образование. Просто на бессознательном уровне начинаю погружаться в методы и техники. Да и вырос в семье учителей. В процессе вношу заметки и хочу поделиться:
Хороший препод должен не только дать знания, но и замотивировать их получить. От хорошего препода важно не только ожидать профессиональной экспертизы, но и навыки организовывать сессии и делать инструменты обмена знаний. Для себя выделю, что мотивацию считаю важнее.
Многие преподы могут обладать высоким уровнем экспертизы, но поделиться и научить не способны даже до базового уровня. Скилл менторинга и педагога также важен для работы. Когда технический специалист просто не обладает нужной экспертизой педагогики, которая помогает шарить знания эффективно.
На этом абзаце должна быть нагло всунута реклама какого-нибудь курса иосников от яндекс.практикума, но мне никто не хочет платить миллиарды. Но тема о другом. Этот принцип высокой экспертизы и удобного шаринга хочется оцифровать в симуляторе иосника.
Вероятнее всего вы знаете примеры уже хороших учебных порталов и скините мне их. Тут нет в планах делать сайты и тп, а скорее создать живое комьюнити актуальных знаний по нашей специфике
Please open Telegram to view this post
VIEW IN TELEGRAM
👍9
Концепции мотивации
Кстати, делюсь контентом с учебы. Знаю, среди вас есть те, кто уже тимлид и руководит человеками. Ща прохожу основы менеджмента и знакомлюсь с основами мотивации. Как делать свою и чужую работу более эффективной. Знать более прикладные и предметные инструменты считаю полезно на любых уровнях. И это не про косметические решения: мотивирующие истории и лозунги в стиле "просто делай", а почти научные подходы.
Любая мотивация делится на 2 концепции: процессуальная и содержательная.
1️⃣ Процессуальная — эти теории базируются на причинах, по которым люди выбирают как им себя вести. Сюда относятся:
Теория ожиданий по Вруму — где подразумевается, что исполнитель лучше понимает работу, если знает как его вознаградят. А вознаграждение должно учитывать потребности вознаграждаемого.
Теория справедливости по Адамсу. В основе нее лежит старая добрая идея равенства. Модель хрупкая и простая, за что неоднократно подвергалась сомнению.
Теория X и теория Y. Это две теории подходят к мотивациям с двух противоположных сторон: авторитарной и демократической
Кстати, делюсь контентом с учебы. Знаю, среди вас есть те, кто уже тимлид и руководит человеками. Ща прохожу основы менеджмента и знакомлюсь с основами мотивации. Как делать свою и чужую работу более эффективной. Знать более прикладные и предметные инструменты считаю полезно на любых уровнях. И это не про косметические решения: мотивирующие истории и лозунги в стиле "просто делай", а почти научные подходы.
Любая мотивация делится на 2 концепции: процессуальная и содержательная.
1️⃣ Процессуальная — эти теории базируются на причинах, по которым люди выбирают как им себя вести. Сюда относятся:
Теория ожиданий по Вруму — где подразумевается, что исполнитель лучше понимает работу, если знает как его вознаградят. А вознаграждение должно учитывать потребности вознаграждаемого.
Теория справедливости по Адамсу. В основе нее лежит старая добрая идея равенства. Модель хрупкая и простая, за что неоднократно подвергалась сомнению.
Теория X и теория Y. Это две теории подходят к мотивациям с двух противоположных сторон: авторитарной и демократической
👍5🔥5
365 дней богу Алгоритмов: Отчет за третью неделю
Еженедельный отчет. Эта неделя прошла чуть сложнее из-за резкого дефицита времени, но получилось как получилось.
Как всегда где-то брутфорсил, где-то костылил, где-то подсматривал. Связанные списки какая-то срань. Где они вообще полезные?
17. Минимальная сумма подмассивов. Медиум таска из задач в сборнике техник двух поинтеров. Решил не сразу и чуть в лоб. Мб медиумы не нужно брать с начала недели пока
18. Реверс слов в массиве. Решил задачу в лоб и по общим решениям оказалось, что и не самое худшее
19. Удалить дубликаты в отсортированном связанном списке. Все время забываю, что связанный список — это референс тайп.
20. Каждый индекс сумма прошлых элементов. Одна из легчайших из легких
21. Кол-во хороших пар. Брутфорснул
22. Сабсущность. Смотря на решение пары дней назад даже не понимаю каким воспаленным мозгом я к нему пришел
23. Реверс связанного списка. Ну тут изи. Комментов нет
Один из главных выводов — работа над ошибками. Все же к некоторым задачам нужно приходить снова подтянув теорию и практику
#365_дней_богу_алгоритмов
Еженедельный отчет. Эта неделя прошла чуть сложнее из-за резкого дефицита времени, но получилось как получилось.
Как всегда где-то брутфорсил, где-то костылил, где-то подсматривал. Связанные списки какая-то срань. Где они вообще полезные?
17. Минимальная сумма подмассивов. Медиум таска из задач в сборнике техник двух поинтеров. Решил не сразу и чуть в лоб. Мб медиумы не нужно брать с начала недели пока
18. Реверс слов в массиве. Решил задачу в лоб и по общим решениям оказалось, что и не самое худшее
19. Удалить дубликаты в отсортированном связанном списке. Все время забываю, что связанный список — это референс тайп.
20. Каждый индекс сумма прошлых элементов. Одна из легчайших из легких
21. Кол-во хороших пар. Брутфорснул
22. Сабсущность. Смотря на решение пары дней назад даже не понимаю каким воспаленным мозгом я к нему пришел
23. Реверс связанного списка. Ну тут изи. Комментов нет
Один из главных выводов — работа над ошибками. Все же к некоторым задачам нужно приходить снова подтянув теорию и практику
#365_дней_богу_алгоритмов
⚡4❤2🐳2👍1🔥1