Привет всем! Меня зовут Юля, я фронтенд-разработчик, наставник на курсах по JS и React и организатор профессионального сообщества Tbilisi JS. В Практикуме я помогаю студентам на курсе «React-разработчик».

За время работы в разных компаниях и над разными проектами я поняла, что Git — это не только (и не столько!) знание самой технологии и конкретных команд, но и определённая культура взаимодействия, практики, подходы, договорённости. Всё это помогает участникам команды лучше понимать друг друга и работать быстрее и чётче.

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

В статье я хочу рассказать об одной очень интересной теории разработки документации на системы и программы. Её авторы утверждают, что создали ни много ни мало «Великую Единую Теорию Документации» (The Grand Unified Theory of Documentation). Мы привыкли с опаской относиться к заявлениям о том, что кто-то обнаружил сокровенную истину и раскрыл её профессиональному сообществу. В теории изложены идеи и правила, которые мы встречаем в разных методиках разработки документации и сами применяем на практике.

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

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

WebGPU — это мощный GPU-API для веба, поддерживает продвинутые рендеринговые конвейеры и вычислительные конвейеры GPU. WebGPU ключевым образом отличается от WebGL своей поддержкой вычислительных шейдеров и буферов хранения данных. В WebGL такие возможности отсутствуют, а WebGPU, в свою очередь, позволяет целиком выполнять в браузере мощные приложения, требующие вычислений на GPU. Речь может идти о самых разных приложениях, от GPGPU (напр., симуляции, обработка/анализ данных, машинное обучение, т.д.) до конвейеров рендеринга на основе GPU-вычислений — а также о многих других приложениях в этом спектре.

В этой статье мы оценим вычислительную мощность WebGPU, сравнив её с показателями Vulkan. Для этого мы реализуем классический алгоритм «марширующие кубы» (Marching Cubes) для WebGPU. Алгоритм марширующих кубов почти без оговорок относится к чрезвычайно параллельным, в составе этого алгоритма выполняется два глобальных шага редукции, необходимых для синхронизации местоположений рабочих элементов и вывода потоков. Поэтому данное решение — отличный вариант GPU-параллельного алгоритма, который стоит первым делом попробовать на новой платформе. Дело в том, что он достаточно сложен, чтобы API испытал давление сразу по нескольким направлениям сверх элементарных параллельных операций диспетчеризации в ядре. При этом он не столь сложен, чтобы на его реализацию требовалось существенное время, а также он не превращается в узкое место из-за ограничения производительности ЦП.

Здраствуйте меня зовут Дмитрий, как-то гуляя по сайту Aliexpress я наткнулся на стол для 3-d принтера Falshforge Creator Pro. И он мне так понравился, что я решил создать самодельный 3-d принтер на основе этого стола. А заодно я поделюсь с вами моим опытом принтеростроения.

Всем привет! Я Виктор Брыксин, руковожу разработкой Яндекс Телемоста. В статье поговорим про декомпозицию задач в проекте и как можно получить реальные сроки его выполнения.

Спойлер: вы все равно ошибетесь, прогнозируя сроки. Но что можно сделать? Минимизировать шанс на ошибки и сделать их менее фатальными. Я расскажу про рабочие инструменты, которые помогли мне в свое время, — брать их на вооружение или нет, решайте сами. Если вы не знаете, как подступиться к декомпозиции сложного проекта и с чего начать, — эта статья вам в помощь.

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

Кратко напомню суть парадокса

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

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

Попросим бегущего кота четыре секунды (по его часам) бежать вправо со скоростью 75% скорости света, потом развернуться и прибежать с той же скоростью назад.
Вот визуализация на диаграмме.

В последние годы перед инженерами нередко ставят задачу спроектировать SLI для тех компонентов, которые они поддерживают. Более или менее понятно, какие SLIs следует применять для пользовательских сервисов и как их рассчитывать. Однако для инфраструктурных команд попытка внедрить SLI сопряжена с рядом сложностей. Далее я расскажу несколько историй об этом и поделюсь выводами, к которым я пришел.

Современная наука, и физика в частности, имеют в своей основе одну, как я полагаю, ложную аксиому. И если её поправить, то всё научное мировоззрение значительно изменится и многое станет гораздо более ясным. Это аксиома о том, что человеческие способности познания Мира безграничны и рано или поздно, при более совершенных приборах и способах исследования, мы познаем всё и до конца.

Когда-то люди считали Землю центром, вокруг которого вращаются и Солнце и звёзды. Коперник разрушил такое представление людей об устройстве Мира. Пришло время разрушить ещё одно неверное представление, о том, что человек это существо, способное генерировать абсолютно объективное знание о Мире с помощью своего сознания.

Привет! Меня зовут Алина Бузинова, я менеджер продукта Отелло, сервиса бронирования отелей от 2ГИС.

Для молодого продукта на конкурентном рынке часто важна скорость доставки полезных решений. Планировать шестимесячную разработку и не получать ожидаемого профита — непозволительная роскошь. Так, после генерации идей, направленных на поиск решений для роста конверсий продукта, мы решили, что готовы выделить на проверку каждой из гипотез не более трёх дней, а на дорогие интеграционные — максимум две недели.

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

Привет, Хабр! Меня зовут Грант, я уже 5 лет занимаюсь backend-разработкой в SimbirSoft, а с 2021 года возглавляю Backend-отдел компании в Краснодаре. В последние несколько лет неоднократно замечаю, что на входном интервью соискатели часто путают принципы разработки. Поэтому в этой статье решил разобрать, как проще их понимать, какие связи между ними прослеживаются, стоит ли учить все или что-то можно пропустить. А еще попробую раскрыть некоторые особенности, какие секреты скрывают популярные принципы разработки.

Предыстория

Пересматривал я один из любимых советских фильмов детства - "Акванавты". Ностальгия по молодости, потрясающие (на те времена) сцены подводных съемок (после этого фильма пошел в секцию подводного плавания)...

И вот на моменте, где ГлавныйГерой (советский акванавт Соболев) плывет на подводном буксировщике я вспомнил, что в ту детскую пору я много чего пытался придумать для подобного "подводного передвижения". Нечто принципиально подобное делали, конечно, для боевых пловцов, начиная со второй мировой, но это всё-таки не для простых людей. И вспомнил, что видел в продаже более простые "подводные скутеры", "подводные буксировщики" - игрушки, ставшие возможными и доступными для гражданских лиц только в нынешнее время.

А сколько стоит такой буксировщик? Я посмотрел - от 40 до 100 тыр. Для редкого развлечения ("лето в Челябинске короткое и малоснежное", да еще не каждый погожий день выпадает на выходные) - мне показалось дороговато. А можно сделать такой девайс самостоятельно? (как обычно ноют старички типа меня -"а вот мы! а вот в наше время! сами себе игрушки делали!". Детство в советские времена было знаменательно тем, что изрядная доля делалась своими руками (отливка солдатиков из свинца, тачки на подшипниках, пайка усилителей и цветомузык, даже в секции подводного плавания моноласты и удлинненки себе делали сами), по тем самым советским "дендрофекальными технологиям".

Конечно, сейчас возможностей больше, нам помогают трудолюбивые китайцы. Да и технологии шагнули вперед (тот большой цилиндр на КДПВ - это, вообще-то, просто фонарик , а не буксировщик - о том, что в таком объеме можно разместить аккумулятор значимой ёмкости даже мыслей не возникало). Поэтому было решено попробовать сделать себе такую игрушку своими руками.

Привет! Меня зовут Настя, я UX-дизайнер в отделе технологических проектов «Леруа Мерлен». Мы занимаемся разработкой внутреннего технологического портала — это единый фронт, где продуктовые команды могут получить услуги других команд в режиме Self-Service. Мы предоставляем инструмент для управления инфраструктурой продукта, формируем рекомендации по оптимизации расходов и агрегируем всю информацию о продукте в одном месте.

Сегодня я хочу рассказать о том, как UX-дизайнеру выстраивать работу с пользовательскими ожиданиями и ограничениями системы, чтобы получить максимально эффективный сервис или продукт.

Привет, Хабр! Меня зовут Валентин Лебедев, я отвечаю за мониторинг в Газпромбанке. Мой опыт в области построения систем мониторинга — более двенадцати лет, из которых последние шесть — строил мониторинг для крупного и сверхкрупного бизнеса. 

Статья будет полезна специалистам, строящим ядро/платформу мониторинга, и пользователям, ежедневно с ним взаимодействующим.

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

На моей практике Event Storming успешно использовался в проектировании игр, именно об этом я расскажу в данной статье.

С нашей относительно ограниченной точки обзора на Земле нам удалось многое узнать о нашей Вселенной. Многие из этих открытий достойны не более чем обновлённой записи в каком-нибудь каталоге. Но некоторые оказались глубоко революционными, полностью изменив наше представление о космосе и о нашем отношении к нему.

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

Всем привет! Меня зовут Юля Алёхина, я дизайнер в AGIMA. В этой статье поговорим об инклюзивном дизайне, о том, почему он касается не только людей с инвалидностью и как правильно аргументировать важность доступности в общении с заказчиком. Еще расскажу, как наш дизайн-отдел учился работать с доступностью, о наших новых целях и планах на будущее.