Терминология IT

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

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

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

Привет, %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”, либо “хочет войти в аналитику”, либо прямо сейчас столкнулся с задачей сборки команды и пытается разобраться, кого нанимать и для каких целей.

А теперь поехали.

Здесь можно найти ответы (в виде описания терминов) на вопросы в этой статье, к вакансии Unity мидл программист. Или попросту узнать что-нибудь новенькое. Статья будет постепенно дополнятся (возможно простейшими примерами).

Сейчас для меня очевидно, и это «не совпадение, я думаю» что некоторая часть участников IT сообщества и желающих в него влиться, может иметь искаженное представление о том, чем же занимаются QA на самом деле, какова их роль в команде, спринте и что за перспективы в профессии они могут иметь.

С юмором и пользой о стереотипах и наболевшем.

Привет!

Меня зовут Коля, и я системный аналитик.

В большинстве источников моделирование данных (в контексте создания приложений) рассматривается как последовательное создание трёх моделей данных - концептуальной, логической и физический. Такого порядка придерживаются, например, DMBOK2 и BABOK, а также многочисленные статьи в сети Интернет:

Рискну предложить несколько дополнений и уточнений к этому процессу - как на основании собственного опыта, так и обобщения опыта коллег, с которыми обсуждал этот вопрос.