Программист
С 2021 года я начал делать свою MMO игру обнаружив что нет готовых сервисов ни в России, ни за рубежом. Но сделать игру я мечтал со времен «Бойцовского клуба» и текстового «Амулета дракона», вдобавок уже был неплохим программистом.
Так и родилась идея написать свое решение Авторитарного сервера для 2D Mmo RPG игр и, как говорил Илон Маск, «Батут работает».
Я работаю в аутсорсе и недавно вернулась на один из проектов, с которого ушла год назад. К своему глубокому удивлению, ознакомившись с кодом, я поняла, что его никто не рефакторил весь этот год. При разговоре с коллегой, который работал над этим проектом, я выяснила, что время на рефакторинг отдельно не выделялось, и он его не успел провести.
Итак, что я имею сейчас? Что стало с кодом, который не рефакторили год? Вопрос риторический, и так понятно, что он превратился в легаси.
Например, эти замечательные константы под гнетом измененных требований превратились в функции.
Каждый автор, обдумывая статью, сталкивается с проблемой. С одной стороны хочется передать читателю крутую идею и тем самым принести большую пользу, а с другой страшно давать что-то “тяжелое”, потому что тема может оказаться неподъемной и следовательно бесполезной.
В первых материалах я описывал простые вещи. Эффективное обучение, работа памяти, правила ведения заметок, всё это очень полезно каждому из нас, особенно в начале пути. Также сюда можно отнести это небольшое руководство.
Cегодня же я хочу рассказать о чем-то более сложном и продвинутом. ВАЖНО! Если вы не совсем понимаете, что такое кривые забывания, метод заметок корнелла, зеттелькастен, то дальнейший текст будет вам мало полезен. Если нет необходимой базы и опыта, то дальше читайте на свой страх и меня потом не обвиняйте.
Изложенная ниже методика Зеттелькастен рисования на бесконечном канвасе (далее ЗРБК для удобства) мне не встречалась ранее, поэтому я скромно буду считать себя одним из первых её практикантов/изобретателей. Причем это не что-то абсолютно новое, а скорее соединение существующих методик и новых возможностей цифровых устройств.
Ура! Наконец-то вы написали столько строк кода, что можете позволить себе дом на берегу моря. Вы нанимаете лучшего архитектора, который уверяет, что у него появилась отличная идея по поводу вашего дома.
И вот вы приезжаете на торжественное открытие, и что вы видите? Ваш новый дом представляет собой внушительную пятиэтажную громадину из стали, бетона и стекла. Вы проходите через вращающиеся двери, и на роскошном мраморном полу остается песок. Внутри обнаруживаете стойку администратора, за которой находится лифт. Наверху — спальня и три гостевые комнаты в виде смежных офисных кабинок.
Часто разработчики программного обеспечения подходят к юнит-тестированию с подобным ошибочным мышлением. Они механически применяют все «правила» и лучшие практики, которые они усвоили из опыта написания продакшен кода, не проверяя, подходят ли они для написания тестов. В результате они строят небоскребы на пляже. О причинах этого явления и главное, как это изменить, в этой статье.
Прообраз code review появился в 60-х годах прошлого столетия, когда программы писали на перфокартах. Главной проблемой тогда было преобразование программного кода в машинный — компиляция. Это сложный процесс, чувствительный к ошибкам и структуре написанного кода. Если в процессе генерации всплывала одна незначительная ошибка, приходилось начинать процесс заново: набирать, проверять и занимать очередь доступа к системе, которая могла длиться месяцами из-за большого количества желающих воспользоваться компьютером. Из-за высокой цены ошибки программисты досконально проверяли перфокарты друг за другом.
Сегодня ошибки в информационных системах по-прежнему стоят недешево, хоть исправлять их попроще. Проверка кода одним программистом за другим получила широкое распространение и сегодня известна как практика code review.
В этой статье, я хотел бы обратить внимание на проблемы во взаимодействии, коммуникации между участниками команды разработки. Определить причины, предложить решение. Также в конце статьи вы можете найти список технических вопросов, ответы на которые помогут улучшить коммуникацию между отделами (арт и тех) с самого старта проекта.
Привет, Хабр!
Я решил посвятить свою первую статью SQL. Вопросы, рассмотренные ниже мне задавали на собеседованиях на позицию python-разработчика. Естественно отвечать правильно получалось не всегда, а если точнее то чаще не правильно, однако проведя N часов в рефлексии я составил перечень ответов, которыми пользуюсь до сих пор.
Данная информация предполагает знание основ языка запросов и я надеюсь, она окажется полезной для разработчиков, которые сейчас активно ищут работу а также, что ты прочитаешь этот текст до конца и добавишь свой вопрос к перечню (ну или поправишь неточности в существующих)
Эти заметки о своём вхождении в тимлидскую должность я решил сделать с самого начала, только когда начал искать должность тимлида. Вероятно, подсознательно мне захотелось побыть героем своего собственного рассказа, который проходит через приключения и в итоге добивается своей цели. Именно так оно и получилось: и цели я добился, и приключений было много. Также я понимаю, что подобный опыт в карьере может быть раз, два, ну три за всё время: когда отношения по работе переходят в совершенно иную форму. Потом, когда прошли первые месяцы, многое естественным образом начинает забываться или превращаться в рутину. Тем более мне хотелось сохранить свежий взгляд на то, как устроена эта должность и какие открытия я сделал, получив её. Предлагаю почтенной публике ознакомиться со своими выводами, которые я старался записывать по горячим следам.
После разработки виртуальной машины и компилятора в рамках хобби прошел год и захотелось попробовать реализовать ёмкий по алгоритмам проект по системному программированию.
Каждый разработчик "кровавого" enterprise в своей работе использует СУБД (SQL/NoSQL) и меня всегда искренне интересовало как они устроены в самом сердце, на самом низком уровне. Почитав документацию и исходный код SQLite и MongoDB, про используемые в индексах и интерпретаторах запросов алгоритмы, осознал, что несмотря на широкую распространенность и некую привычность, системы управления базами данных (СУБД) - это сложные программные продукты, реализация которых не всем под силу. Отлично - как раз то, что мне надо. С мотивацией разобрались, перейдем к делу.
Итак, для начала хорошо бы сформулировать высокоуровневую спецификацию требований. Boson - это легкая, встраиваемая документоориентированная база данных на С/С++
Всем привет!
В игре может быть множество элементов интерфейса, всплывающих окон и т. д., и когда появится необходимость изменить общий стиль, например цвет кнопки или текста, то придется это менять во всех созданных элементах, если используется старая система UI Canvas - uGUI (IMGUI забудем как страшный сон). Не так давно Unity предоставили новую систему UI Toolkit, вдохновленную веб-технологиями (HTML-CSS vs UXML-USS) и позволяющую изменить цвет, шрифт и другие свойства всех элементов в игре одним движением. Преимуществ много, например можно подключить веб-дизайнера, и он тут быстро освоится.
Как и ожидается при появлении новой технологии, внятная документация отсутствует, статей в интернете мало и информации в них кусочками. Официальную документацию стараются делать, но явно не для людей. А так как мы все ценим свое драгоценное время, когда еще и горят дедлайны, мы хотим быстро и без лишних затрат использовать все удобства в разработке. Целью данной статьи как раз и является помощь в быстром освоении нового подхода Unity в создании интерфейсов, чтобы не отвлекаться на рысканье в потоках бессвязной документации и продолжать реализовывать свою фантазию или фантазию заказчика. Давно не доходили руки до написания статьи, но пора бы уже уронить свою каплю в море.
Для демонстрации основных часто используемых функций займемся созданием окошка с вводом текста, выбором из подгружаемого кодом списка и обработкой нажатия кнопки. Пусть это будет меню кафешки, когда нам захотелось перекусить. Это будет для вас отправной точкой для создания более сложных интерфейсов.
Я решила написать эту статью, потому что именно такой статьи мне очень не хватало несколько лет назад, когда я только начала карьеру в аналитике данных. Тогда я часто слышала слова «база данных», «реляционная база», «primary key», примерно понимала, что они означают, но единую картину в голове у меня сложить не получалось.
Я работаю архитектором (Solution Architect если быть точным) в аутсорсинговой компании. В ходе работы я занимаюсь такими активностями как: дизайн и внедрение архитектурных решений, аудит систем заказчика и разного рода консультации вокруг архитектуры систем.
Иногда в разговоре с коллегами я говорю «спокойно, действуем ровно по учебнику». Но тут есть большая доля лукавства, т.к. одной книги где были бы собраны базовые принципы я так с ходу назвать не могу. По большей части это сборная солянка из разных книг, личного опыта и историй, рассказанных коллегами. Что-то освещено в одной из книг Фаулера, что-то есть в курсах от AWS.
В статье я решил собрать вместе список общих принципов, которых я стараюсь придерживаться, приступая к очередной задаче.
Я с удивлением обнаружил, что многие разработчики, даже давно использующие postgresql, не понимают оконные функции, считая их какой-то особой магией для избранных. Ну или в лучшем случае «копипастят» со StackOverflow выражения типа «row_number() OVER ()», не вдаваясь в детали. А ведь оконные функции — полезнейший функционал PostgreSQL.
Попробую по-простому объяснить, как можно их использовать.
