Пользователь
В прошлой части мы немного коснулись теории и остановились на определении лишних компонентов. В этой части мы продолжим определять лишнее, коснёмся вопросов экстремальной экономии, а также закрепим всё выводами.
Если не читали первую часть, настоятельно рекомендую это сделать, чтобы оставаться в контексте.
Итак, продолжим.
Всем привет, меня зовут Артемий, я работаю старшим Android-разработчиком в команде пользовательского профиля в RuStore. Мой опыт в индустрии уже 8 лет. За это время я успел поработать в разных проектах и компаниях. У меня был опыт работы в проекте, в котором было свыше 300 модулей и больше 60 Android-разработчиков. Такие условия заставляют задуматься о масштабируемости на принципиально ином уровне.
Сегодня я расскажу о способах обеспечения масштабируемости проекта и как этому может навредить неправильное восприятие Чистой Архитектуры (далее — ЧА). Предупреждаю сразу, это лонгрид в двух частях!
Откровенно говоря, я не думал, что компании ухватятся за нейросети: во-первых, сразу рассыпается стратегия клиентоцентричности, во-вторых, доверие к автоматизации кажется до предела странным. Ну то есть с 70-х годов средства автоматизации в бизнесе неизбежно вызывали подозрение, а тут внезапно нечто располагает к себе так, что некоторые готовы проводить сокращения в маркетинге, продажах, да даже в разработке и тестировании. Кажется, что за нейросетью маячат продуктивность, экономия, эффективность и всяческий интенсивный рост. А на самом деле, с нами случилось то, что повторялось в истории не раз и не два. Добро пожаловать в очередной карго-культ!
В этой статье я попытался придать систематический вид основным видам тестирования, которые я нашел в различных источниках. Идея для этой статьи зародилась у меня, когда я обнаружил, что в интернете существует множество разнообразных классификаций, и многие отличаются друг от друга. Вначале я начал это исследование для себя, но затем решил поделиться результатами со всеми, надеясь, что оно пригодится другим, как и мне.
Человека далёкого от клиентской разработки на Windows все эти термины определённо путают. И даже среди MS-сообщества регулярно возникают споры жив UWP или мёртв. Причем главный вопрос в этом споре - а что же такое UWP?
Вот уже года 3 Microsoft проводит "рефакторинг" в своём "королевстве". Несколько устав видеть одни и те же споры в твиттере, и оставлять одни и те же комментарии на хабре, я решил расписать как же многочисленные UI-фреймворки MS соотносятся между собой. Кто из них больше мёртв. Возможно, кому-то это поможет в выборе технологии для будущего проекта.
В ряде случаев приложение, написанное на языке Objective-C, для улучшения функционирования и расширения его возможностей, приходится переписывать на Swift. Осуществление перевода на язык Swift сразу всего кода не всегда рационально, гораздо разумным представляется переписывание класса за классом. При этом сборка становится гибридной и соответственно необходимо делать так, чтобы все объявления были видимы в коде на обоих языках.
Ввиду того, что крупные проекты содержат множество файлов понять как последние связаны друг с другом может быть затруднительным. В этой связи прежде чем приступить к переводу логичным явилось бы создание скриптов, которые позволят визуализировать зависимости между файлами Objective-C и сделать анализ проекта более удобным и понятным.
Привет! Меня зовут Павел Лакосников, я тимлид команды бэкенд-инженеров в Авито. Сегодня расскажу про свой любимый подход к разработке Trunk Base Development, сравню его с другими моделями ветвления и подсвечу его достоинства и нюансы.
Краткий обзор трёх моделей ветвления: Central Workflow, Git Flow, Trunk Based Flow, с акцентом на моего фаворита — Trunk Based Flow.
«Если бы WASM+WASI существовали в 2008 году, нам бы не пришлось создавать Docker. WebAssembly на сервере — будущее компьютерных технологий», — считает Соломон Хайкс, соучредитель корпорации Docker и автор Docker Open Source Initiative.
Сравнительно недавно Docker объявил о поддержке WebAssembly на базе WasmEdge. А мы перевели фундаментальный, но практичный материал о том, как пользоваться этой технологией в экосистеме Docker и чем Wasm-контейнер отличается от классического.
В каждой отрасли бизнеса, каждой компании, как правило, используется целый зоопарк ПО. Одни системы «из коробки» умеют взаимодействовать с «соседними» продуктами, другие же приходится дорабатывать. За десятилетия существования веба как отрасли сформировались следующие практики межсетевого взаимодействия:
В данной статье мы поговорим о веб-сервисах. Чем они отличаются от прочих способов и какие они бывают.
Я устроился в небольшую компанию, которая сделал круд‑приложуху на 20 таблиц типа «заметки» и активно ее продавала госорганам за невменяемый бабос.
У нас был 3(три) Т‑Р-И статуса юзера. Anonym → Logined → Phone_Confirmed. Молодой талант до меня увидел в этом граф, и написал класс на 200+ строк, реализующий алгоритм Флойда‑Уоршелла, прикрутил стейт‑машину и не найдя интересных задач, c блеском прошел собес в Яндекс и свалил.
Меня наняли сеньором, и я каюсь ничерта не понял, алгоритм прекрасно работал на первой ступени, на второй давал сбои, тоскливо погуглил этот алгоритм, стер все к черту и написал: if(status==Logined & phone!=null){status=Phone_Confirmed}.
Один коллега посмотрел на меня с немой благодарностью, а начальник офигел и сказал, что код нерасширяем и захардкожен, а тот алгоритм мог пройти за время логN через тысячу вершин и по истечению испытательного урока меня уволили нах, так как мой технический уровень не соответствовал их высоким требованиям, впрочем выдали три зарплаты и я благодарен этим людям. Мой код оставили, тот так и не смогли починить.
Это было вступление.
Уважаемый Яндекс, Сбер и прочая! Я умею быстро решать задачи и кратно увеличивать выхлоп простыми решениями. Я самый умный программист, среди всех ваших работников! Я — НадНадсеньор! Сейчас докажу.
Потому что, только я могу решить задачку, которую вы уже 10 лет решить не можете, когда прилетает пуш‑уведомление или смс и в твоем всплывающем окне написано:
«Ваш шестизначный пароль доступа в наше приложение: 123...»
Тем, кто только начинает свой путь в разработке, сейчас сложно. Помимо малого количества вакансий ещё и везде реклама курсов, обещающих работу мидла через 6 недель обучения (а ведь когда-то я думал, что никто не переплюнет знаменитое «С++ за 21 день»).
С другой стороны лагеря бородатые сеньоры, последний раз искавшие работу где-то лет 10 назад, утверждающие, что высшее образование обязательно для того, чтобы красить кнопки. Ведь не может быть такого, что их годы, проведённые в ВУЗе, бесполезны. Истина, как обычно, где-то посередине, но найти эту середину придётся самостоятельно, готовых решений нет. Но я могу вам помочь.
Для этого предлагаю глянуть на типичные задачи разработчика под Android. Статья поделена на две части — в первой я описываю работу в команде и какие навыки для этого нужны, во второй части расскажу, что нужно для создания новой функциональности в приложении или для исправления старого. Иначе говоря, первая часть про людей, вторая — про код.
