Разбирая завалы файлов на своем старом HDD, Seagate Barracuda 7200.10, объемом аж 80 гигабайт(сейчас туда влезет не всякая игра со стима) наткнулся на интересный документ, который выдавали программистам при приеме в дружную питерскую студию электроников. Он достаточно полно описывал набор знаний, на которые надо было ориентироваться при сдаче ежегодной аттестации. Но помимо соответствия некоторым придуманным требованиям, при поднятии грейда, первую роль конечно играло наличие закрытого объема задач, желание руководства и наличие позиции в штатном расписании.

Были конечно и свои рокстары, которые "спасли контору" или разработали какую-то уникальную технологию в рамках студии, перескочив несколько ступенек сразу, но таких были единицы. В массе же народ просто рос на своих задачах, поднимая грейд каждые 2-4 года. Так что, если кто искал "железные грейды" из кровавого "ентерпрайза" добро пожаловать под кат. Судя по тому, что раздавали этот документ всем желающим, думаю он не был особо секретным или под NDA, на всякий случай убрал оттуда упоминания некоторых продуктов и специфичных технологий. Ну и учтите, что документу скоро будет 10 лет в обед. Требования cгруппированы по областям знаний. Документ так и назывался EA Developer Competency Matrix, переводить на русский не стал, думаю и так все понятно написано. (Оригинал КДПВ тут)

Что вам может дать продуктовый подход к pet-проекту? Если смотреть на pet-проект не как на лабораторную работу, а как на будущий продукт, начинаешь лучше понимать весь цикл разработки. При таком подходе ты сперва выступаешь в роли заказчика: определяешь, какую задачу пользователя решаешь, как это сделать наилучшим образом, а потом подбираешь технологии, которыми легче всего реализовать функционал или которые хочется попробовать. В тексте я расскажу о развитии моего pet-проекта по созданию музыкального стримингового веб-приложения и чему удалось научиться, используя данный подход.

Привет всем, на связи Арсений Елисеев, я fullstack-разработчик в одном ИТ-интеграторе! Относительно недавно мы получили заказ на разработку веб-сервиса, который позволял бы нашим клиентам, владельцам электрокаров, строить маршруты и на их протяжении бронировать электронные зарядные станции под свои нужды. Я представил свою версию системы и хотел бы поделиться с вами ходом мыслей. Возможно, кто-то захочет прокомментировать мою модель или дать совет.

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

Hola, Amigos! На связи Саша Чаплыгин, Flutter-dev агентства продуктовой разработки Amiga и соавтор телеграм-канала Flutter. Много. Сегодня мы вновь займемся практикой! Расскажу об интересной теме — определение положения объекта на экране. Это может быть полезно, когда мы хотим понять, виден тот или иной виджет на экране в данный момент или нет.

В документации по UIKit компании Apple можно найти объяснение, что “структура приложений основана на шаблоне проектирования Model-View-Controller (MVC)”.

В материалах Apple по SwiftUI объяснений и даже просто ссылок на паттерны проектирования, похоже, нет. Попробуем сначала разобраться почему. Далее рассмотрим логичные и простые решения для построения как отдельных компонентов, так и уровень приложения с использованием состояний и property wrappers; подход, который логично обозначить как State-Model-View.

Однажды мне попалась на глаза статья про сотрудника, который реализовал в Excel книге полноценную игру с интерфейсом, противниками и другими механиками. Продолжив изучать эту тему, я увидел целый мир, в котором люди, используя не предназначенные для этого продукты, реализуют различные игровые механики. Эта мысль попала мне в голову, и после этого мне всегда хотелось самому реализовать нечто подобное.

Каждый день в YuSMP Group мы общаемся потенциальными заказчиками. Как правило, в финансовой части их интересует стоимость приложения или цена за час работы специалистов. Так или иначе, весь бюджет выстраивается вокруг проекта, и это правильно — важно рассчитать силы на берегу.

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

Капибара представляет собой уникальный проект, созданный группой энтузиастов в ответ на изменения на Пикабу, которые привели к потере его оригинального духа. Проект направлен на сохранение лучших сторон Пикабу, обеспечивая пространство для творческого самовыражения, где пользователи определяют ценность контента. Отличительной чертой "Капибары" является то, что тренды здесь создаются пользователями, а не алгоритмами, что способствует формированию сообщества единомышленников и выражению мнений.

Проект прошел несколько этапов разработки, включая формирование функциональных требований, CJM, Список фичей, определение архитектуры, разработку и успешный альфа-тест, на котором были выявлены и устранены наиболее критичные проблемы. На данный момент "Капибара" входит в новый этап своего развития – открытый бета-тест. Этот этап является важной вехой на пути к полноценному запуску проекта. Открытие бета-теста дает возможность всем желающим присоединиться к сообществу, оценить ресурс и внести свой вклад в его развитие. Код проекта находится в открытом доступе, позволяя участникам вносить свои предложения и улучшения в качестве авторов, пользователей, тестировщиков и разработчиков.

История проекта

Проект "Капибара", как идея, был зарожден 24 июля 2023 года в ответ на объявление о ключевых изменениях на пикабу . Ответный пост прожил всего час перед удалением, но за это время собрал огромное количество комментариев поддержки и предложения помощи в создании нового портала. Сразу после объявления идеи был создан телеграмм-чат, в который за первые сутки пришло 3,5 тысячи человек, а через несколько дней число участников достигло 9 тысяч. Из этого числа была сформирована команда разработчиков. Основная концепция "Капибары" заключалась в создании портала с акцентом на честной саморегуляции контента пользователями, прозрачности алгоритмов и открытом исходном коде. Ввиду острой потребности авторов в площадке для публикации уникального контента, команда быстро создала телеграм-бота, который принимал посты пользователей и публиковал их в канале, где другие могли оценивать и комментировать их.

Мы уже писали о «праве на ремонт» и преимуществах, которые новые законы дают владельцам как гаджетов, так и бытовой техники. Сейчас в некоторых странах продвигается и ещё одна идея — открытия пользователям проприетарного ПО для доступа к продуктам сторонних компаний. Навстречу владельцам своих смартфонов пошла даже Apple, несмотря на то, что ранее она всеми силами противилась внедрению подобных изменений. Подробности — под катом.

Сегодня с вами Никита Коробейников, iOS Team Lead в Surf. Никита объяснит, что такое Swift Macros, сравнит кодогенерацию от Apple со сторонними решениями: Liquid, Generamba, Sourcery и расскажет, как создать собственный Swift Macros. 

Меня зовут Куприёв Андрей, я Flutter‑разработчик в команде Центра развития финансовых технологий (ЦРФТ) Россельхозбанка. В этой статье мы рассмотрим, как реализовать поддержку протокола ГОСТ TLS в приложениях, разработанных на Flutter.

Flutter, с его привлекательным кроссплатформенным дизайном, завоевал сердца разработчиков мобильных приложений. Однако в областях, где конфиденциальность данных стоит превыше всего, безопасность приложений становится вопросом первостепенной важности. А определенные требования использования отечественных криптографических алгоритмов в области конфиденциальности и целостности делают эту задачу для Flutter‑разработчика весьма нетривиальной и увлекательной. Подробнее об этом и поговорим в статье.

Привет, Хабр!

Я Ануар, работаю в GlowByte и профессионально играю на нервах (шутка 😂).

К написанию статьи подвигла ситуация отсутствия в Рунете информации, как с использованием Delphi реализовать классическое трехзвенное приложение без использования фреймворков и каких-то приближенных к Microsoft технологий. Ниже следует текст немного в шутливой форме о мини-квесте «Как быстро написать распределенное многозвенное приложение на Delphi, использующее REST API». 

Целью было написать статью, которая бы коротко и ясно показывала, как реализовать такой функционал, так как не нашел статей и примеров именно по этой тематике и проблематике. Может, кому-то пригодится при освоении и понимании азов REST API. Возможно, кому-то статья покажется «для самых маленьких», но я надеюсь, что она будет полезна как в практическом смысле, так и теоретическом и поможет понять, как все это работает.

Hola, Amigos! На связи Саша Чаплыгин, Flutter-dev агентства продуктовой разработки Amiga. Мы с командой подготовили для вас перевод статьи о новинках Flutter в версии 3.19. Оригинал тут. Приятного чтения!

Это статья из серии с разбором задач отборочного этапа Yandex Cup 2023 по направлению iOS-разработка с призовым фондом почти в 9 000 000 рублей. Повторюсь, правильных ответов у меня не было, и решал я уже после окончания отборочного этапа. Если заметите какие-либо неточности в формулировках, в размышлениях, в ответах, буду рад обсудить это в комментариях.

Начнем!)

Между идеей и готовой для использования разработкой лежит долгий путь из продумывания концепции, формирования продукта, организации разработки и способов продвижения, развития проекта. IT-продукт невозможно создать в два щелчка. Сократить время на разработку и упростить поддержку и масштабирование продукта помогает Headless CMS – инструмент, о котором поговорим в этой статье.

Сегодня у нас вышел второй официальный пост о прогрессе в разработке уже на самом сайте

Продолжу рассказывать о развитии Капибары, опенсорсном проекте, цели которого воспроизвести лучшее что было на пикабу и не наступить на их же "грабли". Первая часть здесь: https://habr.com/ru/articles/759598/. Вторая часть здесь: https://habr.com/ru/articles/773234/

🌟 Сегодня у нас в арсенале кое-что интересное. 🌟

Новый редактор

Качество программного продукта — важный критерий. Однако не каждый способен его четко обозначить, а тем более объяснить, как его достичь. Как правило, у каждого члена команды свое представление о качестве. Это связано с тем, что в оценке в большей степени учитываются субъективные мнения. Правильнее сказать, что качество представляет собой набор критериев или параметров. И этот набор может отличаться в зависимости от личного опыта или профессиональной деятельности участника команды: пользователя, разработчика, тестировщика, аналитика, заказчика или др.

KPI (Key Performance Indicators) – ключевые показатели эффективности сотрудника, которые позволяют оценить достижение поставленных целей и задач, результативность работы в компании. С продажниками все понятно. Их эффективность можно измерить по сумме прибыли, которую они ежемесячно приносят компании. А вот с IT-специалистами дела обстоят сложнее. Как оценить разработчика с точки зрения ключевых показателей эффективности? Какие KPI можно внедрить? Об этом я и расскажу.