Привет, %username%. Сегодня предлагаем обсудить, как оперативно решать сложные задачи в разработке при помощи ментальных моделей. Их ещё называют паттернами мышления. Вероятно, на Хабре почти все слышали о «методе уточки». Но есть и другие, не такие известные модели, которые помогают работать — как отдельным разработчикам, так и целым командам. Как именно и что это за модели? Давайте посмотрим.
Нам известны 7 принципов тестирования и сейчас мы их подробно разберём.
Итак, приступим.
1. Исчерпывающее тестирование невозможно
2. Тестирование демонстрирует наличие дефектов, а не их отсутствие
3. Заблуждение об отсутствии ошибок
4. Раннее тестирование сохраняет время и деньги
5. Принцип скопления или кластеризация дефектов
6. Тестирование зависит от контекста
7. Парадокс пестицида
Зачем вообще они нужны и как могут помочь в понимании процесса тестирования? Это хороший вопрос. И если тщательно разобраться и следовать этим принципам, то можно избежать многих ошибок, недоразумений и неожиданных ситуаций в будущем.
В переводе с латинского При́нцип - это основа, начало, первоначало, и можно сказать, что принципы тестирования — это основы тестирования.
Прежде чем начать рассказывать о блокчейн-играх, я расскажу, для кого эта статья. Если вы опытный геймдевелопер и сами работаете с внедрением блокчейн-элементов в игры, то эта статья вряд ли будет для вас информативной. Статья написана для тех, кто только погружается в эту сферу, кто часто слышал выражения “блокчейн-игры” и “NFT в играх”, но не вполне понимал принципы их работы, и кому интересно понять основы этого широко обсуждаемого направления. Несмотря на обилие новостей по этой теме, материалов, посвященных введению в блокчейн-игры, не так много, поэтому людям зачастую непросто разобраться в основах. Статья не ставит целью поддержку блокчейн-игр, а призвана лишь ознакомить читателей с их базовой механикой и принципами работы.
Отслеживание и сбор данных является одной из ключевых составляющих успеха бизнеса в интернете. В этой статье я расскажу о том, как происходит отслеживание, какие методы бывают, их преимущества и недостатки, а также поделюсь своим опытом использования нового способа отслеживания - server-side tracking - в Fintech индустрии. Я постаралась рассказать об этом простыми словами и понятно структурировать информацию (мне в свое время не хватало именно таких статей для погружения в тему), и очень надеюсь, что эта статья будет для вас полезной.
Итак, начнем.
Выделяют два основных вида отслеживания потока транзакций: client-side tracking и server-side tracking.
Мы давно живём в цифровом мире, нас окружают полезные онлайн-сервисы, видеохостинги, стиминговые площадки, платформы для блогеров, новостные агрегаторы, интернет-магазины, маркетплейсы и многое другое. В этом мире живут не только IT-специалисты, в нем живём мы все вместе. Но до сих пор при общении между IT-специалистами и «неатишниками» возникает много непонимания, которое выливается во взаимные претензии. IT-специалисты часто жалуются о том, что их заставляют заниматься бесполезным трудом и не могут нормально сказать, чего от них хотят. Со стороны «неайтишников» часто слышится: «Ох уж эти программисты, опять долго, дорого и не то». Давайте разберёмся зачем IT и цифровизация нужна для неайтишников и как ими правильно пользоваться. На простом и понятном обеим сторонам языке.
Привет! Меня зовут Валерий, я руковожу группой QA Fullstack компании SimbirSoft. В сфере тестирования чаще всего выделяют группы QA-специалистов и SDET. Но сейчас многие компании задумываются об оптимизации расходов, особенно это актуально для проектов с длительным периодом эксплуатации, вроде небольших монолитов или внушительных размеров систем с множеством интеграций и микросервисов. Рано или поздно наступает момент, когда требуется подключать специалистов, которые не только хорошо разбираются в продукте и могут тщательно его протестировать, но и тех, кто могут писать автотесты. Убить двух зайцев сразу помогут QA фулстеки.
В этой статье расскажу о том, как QA фулстеки могут существенно улучшить тестирование ПО, на каких проектах они принесут пользу, а для каких задач и почему лучше обратиться к другим специалистам. Материал будет полезен всем, кто хочет обеспечивать качество ПО на высоком уровне и увеличивать скорость выпуска новых релизов, оптимизируя при этом расходы на найм дополнительных специалистов.
С прибавлением опыта QA-специалисту обычно становятся тесны рамки ручных проверок. Хочется ускорить свою работу, не теряя в качестве и улучшая процессы. В этом случае путь лежит в сторону автоматизации. И когда сотрудник совмещает навыки ручного тестирования и автоматизированного, к его определению добавляется «fullstack».
Чтобы выстроить комплексный процесс тестирования, мы в SimbirSoft стремимся растить и поддерживать таких специалистов. А как они сами понимают свои задачи на проекте, и что требуется изучить для старта, вы узнаете из этого материала. Он полезен для middle QA, которые видят себя fullstack-специалистами.
В данной статье я хочу поделиться своим опытом разработки интерфейсов с уровнем кастомизации вплоть до 100% (реальные 100%). При этом сохраняется обратная совместимость и возможность апдейтов. Магия? - Нет, это CDD!
На протяжении 5 лет мы пытались понять как эффективно выстроить продажи. Оказалось, что одна из проблем, это отсутствие хорошей коммуникации бизнеса и инженеров, что они говорят на разных языках. В этой статье мы на расскажем историю и отдадим накопленный опыт в этом вопросе. Надеемся статья поможет командам сблизится и найти дзен в своей работе.
Частенько бывает такая ситуация, когда программист ругает менеджера из за рабочего конфликта. Суть критики сводится к тому что менеджер вообще не понимает как устроена “реальная реальность” и пытается везде выехать на “софт-скилах”. Занимается “нетворкингом” вместо изучения чего то хотя бы на начальном уровне, в общем балабольствует и манипулирует понятиями и шаблонами оторванными от реального понимания действительности. А потом этот же программист, в своё свободное время, мечтая о собственном успешном стартапе, пытается создать ИИ общего назначения на основе языковой модели, загружает в обучающий набор данных гигабайты текстов и картинок, ожидая при этом практичного рассудочного мышления от создаваемой нейросети.
Когда я пыталась разобраться в этих двух определениях, мне на глаза попалась эта статья. Она помогла мне расставить всё по полочкам, надеюсь, поможет и вам.
Ежедневно IT-компании заключают множество контрактов, договоров или соглашений. Если с товарами и услугами всё прозрачно и понятно даже рядовому сотруднику, то с передачей прав даже у матёрых юристов и бухгалтеров случаются промахи. Я встречал немало Сублицензионных соглашений о передаче прав на программное обеспечение, которые содержали недоразумения, касающиеся исключительно определения ролей сторон — участников договора.
В классических договорах поставки мы встречаем такие роли: для принимающей стороны — это в основном Заказчик или Покупатель, а для передающей стороны — это Исполнитель, Продавец или Поставщик.
Есть ещё понятия Подрядчик, Генподрядчик и Субподрядчик, но интуитивно понятно, что это всё исполнители, т.е. продавцы товаров и услуг. Если же мы рассматриваем лицензионное соглашение, то здесь роли описаны иначе. В передаче прав на интеллектуальную собственность участвуют Лицензиары и Лицензиаты, ну или Сублицензиары и Сублицензиаты.
Кто это такие и где здесь можно ошибиться? Зачастую можно увидеть Сублицензионные соглашения, в которых участвуют две стороны: Лицензиат и Сублицензиат. Такие формы Договора я встречал у дистрибьюторов, корпоративных клиентов, на торговых площадках крупных государственных заказчиков. Также множество юридических ресурсов в интернете приводят подобные шаблоны в качестве примеров. При запросе обосновать логику выбора таких формулировок, все они ссылаются на Статью 1238 ГК РФ.
Я решила написать эту статью, потому что именно такой статьи мне очень не хватало несколько лет назад, когда я только начала карьеру в аналитике данных. Тогда я часто слышала слова «база данных», «реляционная база», «primary key», примерно понимала, что они означают, но единую картину в голове у меня сложить не получалось.
Всем привет! Меня зовут Александр Чуглин, я руководитель управления корпоративной архитектуры в Норникеле. У нас >1000 информационных систем и >4000 точек интеграции между ними, и всё это постоянно меняется. В таких масштабах важно правильно выстроить архитектуру предприятия, а затем и правильно ей управлять. Чтобы понять, по верному ли пути мы идём, важна сторонняя оценка и сравнение с мировыми практиками.
Для этого мы использовали одну из мировых методик. Нас тестируют, сравнивают с мировыми бенчмарками и дают заключение. Это как с английским языком: определи, какой у тебя уровень владения — продвинутый или начальный. Используется шкала от 1 до 5. Сегодня хочу рассказать, как мы смогли улучшить нашу оценку с 2 до 3, как собираемся покорять 4 и какие внедрённые практики помогли нам больше всего.
В этой статье я расскажу о том, какие сегодня существуют основные способы идентификации пользователя в бесконечном интернет-пространстве, и какие преимущества и недостатки у каждого из них.
Всем привет! И сегодня мы поговорим про то, о чем принято спорить до пены у рта или задумчиво молчать с непониманием происходящего. А именно, о разнице между такими существами айтишного бестиария, как системный аналитик (англ. SA или рус. СА) и бизнес-аналитик (англ. BA или рус. БА).
Вступление: кто и про что
Для начала небольшой дисклеймер. В IT я тружусь с 2015 года в найме и на 2-3 года дольше, если считать попытки в стартапы и бизнес, и за это время увидел массу интерпретаций ролей специалистов в разработке. Последние несколько лет я трудился в роли системного аналитика в двух компаниях, а ранее вдоволь понаблюдал за работой бизнес-аналитиков в еще одной, частично подменяя их по ситуации. В текущий момент я перешел к роли Product Owner на своем проекте в Innovative People, однако совсем недавно был ведущим в системной аналитике, так что память свежа.
Эта статья не является истиной в последней инстанции, да и ничто не может быть абсолютной истиной, так как в IT достаточно гибко работает подстройка функций члена команды под конкретные задачи компании и видение команды (и это хорошо!). Так что воспринимайте сей рассказ как обзорную информацию для тех, кто “хочет войти в IT”, либо “хочет войти в аналитику”, либо прямо сейчас столкнулся с задачей сборки команды и пытается разобраться, кого нанимать и для каких целей.
А теперь поехали.
Сейчас для меня очевидно, и это «не совпадение, я думаю» что некоторая часть участников IT сообщества и желающих в него влиться, может иметь искаженное представление о том, чем же занимаются QA на самом деле, какова их роль в команде, спринте и что за перспективы в профессии они могут иметь.
С юмором и пользой о стереотипах и наболевшем.
Привет!
Меня зовут Коля, и я системный аналитик.
В большинстве источников моделирование данных (в контексте создания приложений) рассматривается как последовательное создание трёх моделей данных - концептуальной, логической и физический. Такого порядка придерживаются, например, DMBOK2 и BABOK, а также многочисленные статьи в сети Интернет:
Рискну предложить несколько дополнений и уточнений к этому процессу - как на основании собственного опыта, так и обобщения опыта коллег, с которыми обсуждал этот вопрос.
Перед тем, как запускать свой сайт или приложение, в котором вы собираетесь использовать cookies или иные идентификаторы (local storage, AAID, UDID и т.д.) устройств/сессии пользователя, необходимо выполнить требования законодательства о персональных данных.
Зачем? Во-первых, вы выстраиваете открытые и честные отношения со своими пользователями. Во-вторых, вы будете готовы к проверкам регуляторов. В-третьих, вы сможете избежать штрафов, которые могут достигать 4% годового оборота своей компании.
Давайте разберемся, как онлайн-идентификаторы связаны с защитой персональных данных.
Согласно ФЗ «О персональных данных» и GDPR куки-файлы и иные идентификаторы пользователя относятся к персональным данным, поскольку позволяют теоретически определить конкретного субъекта или выделить его среди других лиц.
Наиболее известным делом по рассматриваемой нами теме стал судебный спор Vidal-Hall v. Google (2015). Используя сookieы-файлы, компания Google осуществляла сбор информации об интернет-трафике пользователей. Заявители, не будучи осведомлены о незаконных действиях ответчика, настаивали на привлечении последнего к ответственности за нарушение порядка использования сookies – персональных данных, которые позволяют вычислить пользователей.
Суд занял позицию истцов и положительно ответил на вопрос об отнесении Cookie-файлов к персональным данным, так как они, «не называя прямо субъекта … позволяют выделить его из всей массы пользователей, следовательно, отвечают критерию идентификации» [1].
Следовательно, в отношении cookies и прочих идентификаторов необходимо соблюдать требования законодательства.
