Пользователь
ЧТО?
В этом году мы готовим 11-й DUMP - масштабную конференцию для всего IT-сообщества. Более 2000 участников придут за практической пользой и инструментами, которые сразу можно интегрировать в работу команд. А ещё за общением, идеями и трендами!
Лучшие в своих направлениях спикеры подготовят доклады в 11 секциях: Backend, Frontend, Design, Team, Product, Тестирование & QA, Mobile, DevOps, GameDev, Science (возвращение легендарной секции) и ML&DS (впервые на конференции).
Программа каждой секции рассчитана на полный день - это как 11 конференций под одной крышей! Но участники могут свободно перемещаться между залами. Кроме докладов будут нетворкинг, дискуссии, активности, вкуснейший кофе, обед и, конечно, мерч от партнёров.
Станьте частью большого события, оформите свой экспертный опыт и создайте крутой доклад с помощью наших программных комитетов. DUMP - это возможность пообщаться с коллегами, выступить на большую аудиторию и получить качественную запись своего доклада ;)
Недавно проводил конференцию по обмену опытом среди программистов 1С. В числе прочих, там делился своим опытом весьма примечательный человек по имени Захар. Примечателен он тем, что создал и развивает стабильную систему обслуживания клиентов.
Начал он с показателей – деньги, удержание клиентов, оценки качества – цифры действительно интересные, необычные для рынка сопровождения 1С. На всякий случай поясню: сопровождение 1С – это периодическое выполнение задач по программированию разной степени сложности, ну и банальная тех.поддержка.
Казалось, после цифр он перейдёт к организации процесса, и там будут стандартные клише вроде «мы работаем качественно», «не пишем go-no-code» и «искренне хотим помочь клиенту». Ан нет. Оказалось, дело в дофамине.
Написание своего шахматного движка - обширная тема, про которую пишут целые книги.
Однако очень многие шахматные программы работают со "стандартными" правилами шахмат и не могут работать при других правилах, хотя существуют сотни вариаций шахмат.
В этой заметке я покажу, каким образом можно написать достаточно быстрый и гибкий шахматный движок на С++, в котором можно задавать произвольный размер доски, расположение фигур, и создавать новые типы шахматных фигур.
Я запрограммировал 15 шахматных вариаций - для каждой опишу неожиданные ходы и результаты партий компьютера друг с другом.
В мире происходят страшные события, и фондовый рынок в каком-то смысле является их отражением. В этой статье я объясняю некоторые происходящие сейчас на рынке явления — возможно, эта информация поможет вам избежать убытков от продажи активов по несправедливой цене.
Мало просто сменить свою сферу работы на IT, желательно еще и стать хорошим разработчиком. Бывший тимлид и консультант Александр Усков рассказывает, как понять, что перед вами плохой разработчик и что с ним вообще можно делать
В этой статье мы разберем признаки слабых разработчиков, которые можно обнаружить на собеседовании, в ходе совместной работы или даже в процессе неформального разговора в курилке. Важное уточнение — все описанное в нашей статье не стоит рассматривать как чек-лист формальных правил. Это скорее некоторые закономерности, каждая из которых не является гарантией того, что перед вами — «плохой» разработчик. Но, если в одном человеке сочетаются несколько из них, то вероятность этого сильно увеличивается.
Привет хабровчанам! Я — главный редактор Xakep.ru Андрей Письменный (и это моя настоящая фамилия, если кто вдруг сомневался). После многолетнего перерыва «Хакер» возвращается с постами для «Хабра», но в этот раз вместо выборочной публикации наших статей мы будем писать посты специально для сообщества.
Одна из тем, которые я хотел бы освещать здесь — это история «Хакера». Но сначала — небольшой апдейт. В нем я постараюсь ответить на все вопросы, которые нам задают люди, давно (или вообще никогда) не заходившие на Xakep.ru. Кто мы, как мы работаем и почему еще не вымерли :-)
А если вопросы останутся, буду рад ответить в комментариях.
Вот уже в десятый раз подряд открывает свои двери Клуб анонимных Дедов Морозов.
Идея совершенно проста:
Несколько месяцев я изучал тему интернет мошенничества с целью собрать наиболее полный список действий, которые обезопасили бы меня от жуликов и их махинаций. Итогом изучения стал чек-лист, которым хочу поделиться со всеми. Его цель - сделать взлом цифровых активов сложным и бессмысленным.
Наткнулся на любопытный материал, в котором автор систематизировал и записал свой опыт инженера-программиста в 20 тезисов. Я работаю в коммерческой разработке ПО больше 25 лет, и этот текст отозвался во мне практически каждой буквой — большинство советов я тоже регулярно практикую, не облекая их в формат ёмких афоризмов. В общем, решил сделать перевод.
Особенно отзываются пункты «стройте компактные системы» и «лучший код — это отсутствие кода». Последний совет я превращаю в цитату из какого-то второсортного фильма про самураев: «Лучшая победа — та, которую ты одержал, не доставая меч из ножен» (думаю, сослуживцы за моей спиной уже закатывают глаза). И, конечно, бесконечные разговоры про легендарных 10x-программистов постоянно хочется прервать советом не связываться с 0,1x-программистами (которые реально существуют, в отличие от 10x).
Long, long time ago… Нет, не так. 4 месяца назад я рассказал вам, как из клея и резиновых сапог создать с нуля свой стратостат с телеметрическим модулем и видеокамерой. Я так же описал наш опыт запуска и поиска этого метеозонда, обозначив несколько возникших проблем. Что ж. Мы анализировали, анализировали и доанализировались до четвертого шара. И сейчас я расскажу вам, что произошло за это время, почему он четвертый, и где пропавшие два. Эта часть будет менее технической, т.к. изменений конструкции почти не было, но те что были — имеют значение. Если вы вне контекста, то эту часть советую читать только после прочтения первой (хотя бы технических разделов). Ссылка на первую часть ниже. Будет много фото, видео и графиков. Поехали?
Мультизагрузочная флешка, сколько раз она меня выручала, с нее я чистил компы от вирусов, ставил Оси и т.д. В общем объяснять для чего она на хабре не нужно. Я знаю две самых известных утилиты для создания МФ - Easy2Boot и Win Setup From USB. Чем отличается Ventoy от них? Сейчас посмотрим.
Самый плохой разработчик — тот, который всё делает по ТЗ. А самый лучший код — не написанный.
«Моя задача — писать код, я разработчик!» — да, это очень удобная позиция. Но людям, которые не только программируют, но ещё и общаются с коллегами, организуют собственную работу и понимают предметную область, платят больше. Потому что они приносят бизнесу больше пользы. Разработчики, которых надо микроменеджерить, чтобы они делали свою работу, никому не нужны.
Основная обязанность разработчика — это решить проблему. Не написать код, не отдать задачу на тестирование, а решить проблему. Писать код по спецификациям может любой дурак (на самом деле тоже нет). А вот решать проблемы — нет. Для этого надо думать и брать на себя ответственность.
Это история не про любовь, мир, жвачку и миссию компании, а про простую способность сделать свою работу так, чтобы она была сделана хорошо. И да, для этого разработчик должен не только уметь программировать, но и уметь общаться с другими людьми, уметь доносить свои мысли, уточнять и понимать, что вообще происходит. То есть уметь договариваться. Да, разработчик должен уметь организовывать свою работу: раскладывать проблему на задачи. Ещё он должен интересоваться продуктом (проектом). Не потому что разработчик так его любит, и не потому, что этого требует Agile, а потому, что живой интерес к продукту и понимание его ценности увеличивает качество решений и стоимость разработчика на рынке. Знание предметной области и её ограничений — первейшее требование для того, чтобы принять правильное техническое и архитектурное решение. И очевидно, что чем меньше руководитель тратит сил на управление сотрудником и чем больше получает результат, — то есть чем выше автономность сотрудника, его самостоятельность и беспроблемность, — тем он ценнее при прочих равных.
Впервые увидел этот странный график в лаборатории университета. Невзрачный листок, ксерокопированный из старой книги, был наклеен на стену рядом с роторным испарителем. Листок, очевидно, использовали часто, но берегли, словно в нём содержалось какое-то древнее могучее заклинание… Впоследствии, схожего рода графики попадались мне и в других лабораториях, словно составляли неотъемлемую часть перегонки с вакуумом. Затем похожие рисунки встречались на страницах разной технической литературы. Их называли номограммы. Научиться ими пользоваться оказалось до смешного просто, но кто и как их в своё время сделал — оставалось загадкой.
Номограмма, что часто используется при перегонке с вакуумом приведена на рисунке ниже.
Допустим, вы провели реакцию в растворителе, а теперь собираетесь его удалить (выпарить), чтобы собрать продукт реакции. Растворитель улетучивается изнурительно медленно, а чтобы ускорить процесс, вы решаете его нагреть, но вот беда — греть раствор нежелательно, так как продукт реакции от нагревания может испортиться. Создав пониженное давление, вы уменьшите температуру кипения растворителя и сумеете его отделить не причинив вреда растворенному в нем веществу. При нормальном атмосферном давлении 760 мм ртутного столба вода кипит при 100 С, однако, при давлении 40 мм кипит уже при 34 С.