В личные на vc.ru мне пришел такой фидбэк.

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

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

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

Прообраз 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.
Попробую по-простому объяснить, как можно их использовать.

Геймдизайнерами не рождаются, геймдизайнерами становятся

Этап 0 — планирование

• архитектурные преимущества иммутабельности;
• создание эффективного персистентного векторного типа на основе RRB-деревьев;
• разбор архитектуры на примере простого текстового редактора.

Введение