Kurgan-Telecom Ru | Информационные технологии

Привет! Меня зовут Гриша, я UX-проектировщик Спортмастера. В этой статье я расскажу про все 10 эвристик Нильсена с советами по применению и простыми примерами. Независимо от того, создаете ли вы продукт с нуля или проводите UX-аудит — эти принципы помогут вам принимать более обоснованные решения. Ведь хороший интерфейс — это не только про красивую картинку, но и про удобство, понятность и предсказуемость взаимодействия. Именно это делает продукт по-настоящему дружелюбным к пользователю. 

Чтобы создавать такие интерфейсы, UX-дизайнеры по всему миру опираются на проверенные временем принципы — эвристики юзабилити. Их сформулировал в 1994 году эксперт по пользовательскому опыту Якоб Нильсен, и с тех пор они остаются основой для анализа и проектирования интерфейсов. Это не строгие правила, а скорее универсальные рекомендации, которые помогают находить и устранять проблемы в дизайне. Зато они успели стать своеобразной классикой и базой для тех, кто работает в этой сфере. Да-да, несмотря на то, что прошло 30+ лет.

Итак, давайте по порядку.

Всё началось с простой, но насущной проблемы: я хотел быстро передать файлы между своими устройствами — без интернета, без Bluetooth и без облаков.

41 ТБ/сутки по маршруту Oracle → Postgres Pro без остановки исходной системы — это не теория, а цифры последних тестов. Мы разложили миграцию на три этапа: быструю начальную загрузку, CDC из redo-логов и валидацию, и собрали их в ProGate. Как устроен конвейер, почему Go и где прячутся узкие места — расскажем в статье.

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

DRP (Digital Risk Protection) и ASM (Attack Surface Management) — это инструменты проактивной киберзащиты. Их ключевая задача — раннее обнаружение в сети вредоносной активности, нацеленной на компанию, и мониторинг её инфраструктуры на предмет уязвимостей. И DRP, и ASM позволяют превентивно реагировать на угрозы и предотвращать атаки, о которых иначе компания и не узнала бы. За подробностями добро пожаловать под кат!

Кажется, мы настолько привыкли к прогрессу нейронных сетей, что больше удивляемся, когда они чего-то не умеют, чем видя их новые достижения. Тем не менее, сегодняшние технологии искусственного интеллекта — это самое начало пути.

Интеллектуальные модели на основе нейронных сетей, при всех их впечатляющих возможностях, не лишены серьезных недостатков, зачастую являющихся обратной стороной достоинств. Отталкиваясь от используемой сегодня архитектуры, попытаемся определить возможные направления дальнейшего развития систем искусственного интеллекта (ИИ).

Около 10 лет назад мы получали «двойки» за ИТ-сервисы, но не понимали, почему так происходит. Сначала мы просто смотрели и не понимали, а что вообще делать. Потом стали искать виноватых. Потом начали ставить цели сотрудникам. А потом поняли, что дело не в ошибках, а в самой системе и подходе к оценке.

Меня зовут Алина, я в СИБУРе отвечаю за техподдержку. Делюсь с вами историей, как мы собственно ее чинили. Внутри – реальные заявки пользователей, наши мысли на этот счет и то, как это исправляли.

Эта история о нас. И, если честно, про то, как мы все научились быть чуть человечнее.

Переход от эмоций к логике. Пост не отрицает тревогу, но задаёт вопрос:

«А точно ли происходит катастрофа? Или нас пугает то, что мы больше не в центре экосистемы?»

Миф о вымирании — цифровая саванна или новая экосистема?

С позиции работника я давно всё написал, но позволь озвучить мои мысли с точки зрения бизнеса, ведь ты знаешь прекрасно что более 10 лет у меня была своя контора со штатом в среднем 10-12 человек с немалым количеством ИТ-проектов, большая часть из которых была собственными стартапами как и стартап в котором я у тебя работал, и там у меня 7 из 10 примерно были чистым чистым убытком, что более чем хороший результат.

Если тебе очень повезло найти человек-оркестр, который может совмещать devops, backend, frontend, базы, администрирование серверов и решать задачи, которые в инете не обсуждались – то это очень повезло и с таким человеком можно пощупать идею в режиме «давай покреативим», как было в октябре 2021го, чисто чтобы оформилась идея, стали понятны примерно объемы работ, технологии, а главное монетизация.

Когда идея оформлена и всё понятно – человек-оркестр переводится в статус teamlead, и набирается команда. Тимлид 50% рабочего времени занимается решением сложных задач, где он реально эффективен, 50% времени тратит на то, чтобы координировать работу команды, которая делает рутину, которая составляет минимум 80% проекта, мотивируя команду не руганью, а раздачей премий отличившимся. Это ускоряет разработку минимум в 3-4 раза, и снижает риск, что проект к моменту завершения будет не актуален (обойдут конкуренты, изменится ситуация, появится GPT 5, который будет делать то что должен был делать проект и т.п.)

 Команду набирает именно тимлид, а не инвестор-гуманитарий в режиме «у меня тут есть старый приятель, он вроде что-то шарит, его надо как-то задействовать», «у меня есть крутые админы, которые по факту просто разводилы», «у меня есть ребята, которые съели собаку на ИИ, и оказывается, что если они и съели, то ножку от чихуа», «есть Вася – он будет заниматься соцсетями, который оказывается реально крут»… Всё это плохо заканчивается в 75% случаев, с Васей повезло, с остальными конфликты и трата времени пустая, но в целом это лишь тормозит разработку, особенно если ты в реальности не разбираешься в технической стороне вопроса.

08.08.2025, Джейсон Рэйнбоу, SpaceNews

В то время как государственные программы и частные предприятия закладывают основу для устойчивого присутствия на Луне, несколько пионеров коммерческой космонавтики начинают обращать свое внимание на более отдаленные области.

Марс обещает новые горизонты для торговли, охватывающие добычу ресурсов и научные услуги, даже несмотря на то, что его коммерческая жизнеспособность остается гораздо более отдаленной и неопределенной, чем у Луны.

SpaceX является одним из самых громких голосов, отстаивающих коммерческий путь к Красной планете, намереваясь запустить туда свои первые корабли Starship уже в 2026 году — если ей удастся преодолеть трудности разработки самой большой в мире ракеты.

Картинка: ArtPhoto_studio, Macrovector, Freepik

Мы живём в постоянно дорожающем мире: с каждым годом какой-либо очередной компонент нас «радует» своей повысившейся стоимостью. 

Не исключение и моторное топливо — которое у многих, имеющих машину, уже превратилось в отдельный «объект инвестирования», так же как и «работа на фаянсового друга» :-D

Но на самом деле смешного здесь мало.

Тем не менее, потенциально есть практически неисчерпаемый океан энергии, для доступа к которому не нужно быть «правильным человеком, знающим правильных людей и владеющим правильным участком с запасами нефти в правильной стране», так как к этому океану имеют доступ все: это воздушный океан над нашей головой!

Он содержит просто огромное количество потенциального топлива в виде газов! 

Конечно, не всё так просто, однако, даже известная нефть является «углеводородом» — чуете, куда ветер, то бишь «газ» дует? ;-) 

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

В четверг, 7 августа, в 20:00 по мск состоялось долгожданное событие в мире ИИ — OpenAI представила ChatGPT 5. В этой статье я собрал всю важную информацию из прошедшей демонстрации — это поможет понять, что же нового случилось в GPT 5 и чего ожидать от этой нейросети.

Эта модель не просто эволюционный шаг, а качественный скачок, позиционируемый как «разговор с экспертом». В статье мы разберем ключевые нововведения презентации, впечатляющие результаты в бенчмарках и практические возможности (вплоть до генерации приложений!).

Хотите системно вырастить сеньора из джуна? Собрать идеальную команду за пару кликов? Прозрачно развивать hard- и soft-навыки сотрудников? Я, Владимир Тимонов, главный разработчик ЕвразТехника ИС и управляющий продуктом ИС «Матрицы компетенций», расскажу, как мы справляемся с этими вызовами в ЕВРАЗе.

Мечта любой IT-компании — обучение в стиле Нео из «Матрицы»: загрузил программу, и через минуту сотрудник уже мастер React и Kubernetes. Увы, реальность сложнее.

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

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

Разработчик в ЕВРАЗе: больше, чем просто код

Матрица компетенций – известный и хорошо себя зарекомендовавший инструмент в управлении персоналом. Существуют известные шаблоны таких матриц. Но мы решили разработать свой стандарт. ЕВРАЗ – компания крупная, у нас есть много особенностей, которые необходимо учитывать при оценке IT-специалистов. Так давайте пойдем от самого понятия «разработчик». Как он выглядит в металлургическом гиганте? Чем отличается его работа от коллег в продуктовых IT-компаниях или финтех-стартапах? В чем особенность этой роли и  почему матрица компетенций становится для нас не просто инструментом оценки, а настоящим компасом в профессиональном развитии, расскажем в этой статье.

Даже при высоком трафике посадочная страница не всегда приносит нужное количество лидов. Важно корректно выстроить логику коммуникаций с пользователем. Николай Лобанов, директор по маркетингу в click.ru, поделился примерами из опыта и рассказал, что на самом деле влияет на конверсию страниц.

Всё больше проектов появляется на Unreal Engine — от великого "Ведьмака" до не менее великой "The Day Before". И чем больше проект, тем выше цена одной незамеченной ошибки. Когда число строк кода переваливает за несколько тысяч, даже самый внимательный разработчик может не заметить неочевидный баг. И тут на помощь приходит он — PVS Studio, который помогает снизить риск попадания багов в ваши UE-проекты.

В современной веб-разработке качественная документация так же важна, как и качественный код. Когда ваше приложение разрастается до десятков или сотен компонентов, функций и модулей, становится практически невозможно удерживать в памяти все детали их работы. Хорошая документация не только облегчает поддержку проекта в долгосрочной перспективе, но и значительно ускоряет вхождение новых разработчиков в команду.

В этой статье мы рассмотрим два популярных подхода к документированию фронтенд-кода: JSDoc и Storybook. Они решают схожие задачи, но совершенно разными способами и с разным фокусом.

Представьте, что вы нанимаете капитана корабля. Если дать ему лишь общую инструкцию («плыви на восток»), он может проплыть мимо цели. Но если снабдить его навигационными картами, метеоданными и чёткими метриками –  он приведёт корабль в нужную гавань. Именно так работает сильный профиль должности.

Если поискать в интернете решение задачи «How to read HttpServletRequest multiple times», то можно найти множество ответов - и на Stack Overflow, и на Baeldung. Но все ли они подходят для всех случаев?

На конференции Black Hat USA 2025 исследователь Shota Matsuo представил доклад о новом классе угроз под названием Shade — платформе для загрузки зловредного ПО из UEFI, способной обходить почти все современные средства защиты.

Я постарался сделать краткий обзор Shade.

Ричард Талер — экономист и нобелевский лауреат. Он адепт поведенческой экономики — такого направления экономической науки, в котором учитывается влияние психологии на потребительские решения. Во времена, когда родился Ричард Талер, о поведенческой экономике не слышали: тогда её попросту не существовало. На своём исследовательском пути талантливому и чуткому экономисту приходилось рьяно отстаивать право новой поведенческой экономики на то, чтобы её знали, признавали и использовали на практике.

Джордж Мартин, автор «Песни Льда и Огня», прекрасно вплетает сюжеты из реальной истории в свои произведения. Делает он это довольно медленно, порой пуская ветра вместо выпуска «Ветров Зимы», но всё же делает мастерски.
Так уж вышло, что в основном в своих статьях я разбираю эпоху паруса, и меня попросила моя боевая подруга написать о сражении, которое стало «прототипом» единственного крупного сражения на воде в книгах из цикла ПЛиО.
Естественно, речь пойдёт о Битве на Черноводной.