В 1940-1960-х гг. существовала такая профессия, как «компьютер» и первыми «компьютерами» были женщины. Их нанимали, чтобы они делали сложные математические расчеты для военных и НАСА, (например, при работе над запуском Explorer 1 или когда началась программа «Меркурий»)
Такая отсылка выдаёт слабое понимание исторических реалий.
В те времена мужчины проектировали, руководили, придумывали алгоритмы и принимали инженерные решения. Женщины составляли отчеты, заполняли бумаги, набивали код на перфокартах.
На сайте NASA прямым текстом написано, что за успех Explorer ответственны трое мужчин, а в проекте Меркурий нет женщин на ключевых должностях.
Заниматься "сложными математическими расчетами" значит сидеть и нудно забивать десятки формул в калькулятор. Это рутинная работа для высвобождения ключевого персонала.
Даже сейчас можно найти пример таких "комьютерщиц". В больницах врачи не заполняют отчеты, не считают статистику по заболеваниям. Это делает отдел статистики. Отдел состоит полностью из женщин. Эти женщины ничего не программируют, но делают "сложные статистические и аналитические расчеты".
Как вы понимаете, есть принципиальная разница между такими "расчетницами" и программистками.
А давайте сделаем так, чтобы наше поколение начало понемногу избавляться от этих гендерных стереотипов!
Бездумное повторение чужих мыслей — база для стереотипного мышления. Вся статья построена на попсовой интерпретации фактов, которые наоборот только закрепляют все изложенные проблемы. Возникает вопрос. Вы в какую сторону воюете?
Основной посыл статьи — это призыв к переменам, чтобы мы начали замечать проблемы женщин и самих женщин.
Замечать и решать реальные проблемы людей сложно когда внимание и пространство для диалога заполняет инфо-мусор.
Как нужно привлекать или вернуть профессионалов в Российскую отрасль?
Для начала перестать думать что профессионалы это наивные энтузиасты, которые вам за спасибо будут развивать отрасль.
Проблемы кадров нет, есть проблема в головах руководства российских компаний, которые думают что зарплата в номинальном выражении аналогичная зарплатам 2010 года может кого-то привлечь или способствовать развитию отрасли.
Сначала они рассказывают как храбро принимают риски, как сложно найти инвесторов и выйти на рынок. А потом они же идут и вливают деньги в рекламные компании своего игрового продукта, где разовая рекламная интеграция может стоить как месячная зарплата опытного сценариста или художника.
Не удивительно что после этого профессионал лучше пойдет стримить или канал на ютубе создаст, чем будет вкладывать силы в такую отрасль.
Про самостоятельные инди команды я вообще молчу. Ты еще думать не начал про свой проект, а уже должен государству налогами, отчетами и т.д. С некоторых пор вот не можешь инструменты для разработки получить, потому что не оплатить. Чувствуешь себя подпольщиком и нелегалом каким-то пока собираешь команду для разработки игры.
После этого рассказы про поддержку и гранты на проекты по повестке выглядят как издёвка.
Интересно что падением морали вы считаете доверчивость и низкую образованность людей, которые ведутся на схемы мошенников. Я вот всегда думал что мораль это про боевой дух и настроение (от которого зависит соблюдение установленных норм и правил).
В этом смысле упаднические мнения и комментарии вроде вашего эту самую мораль и опускают. Сложно работать, создавать и творить когда из каждого угла говорят как всё плохо и безнадежно потеряно. Адепты Блиновской хотя бы верят в свой успех.
Возможно даже стоит поучиться у этих мошенников в некоторых вопросах мотивации людей. Например, может для поднятия трудовой мотивации в стране нужна идея и привлекательная цель, которую бы люди хотели достигать, используя понятные правила и вознаграждения?
А пока такой цель нет, увы, ничего не остается многим как идти на марафон желаний и прочие курсы успеха.
Опять же, когда зависимость подключается в одну строчку, то не такая это и проблема.
Проблема серьёзнее чем кажется.
Как только ваши требования становятся чуть кастомнее чем использование одного Rust фреймворка, проблема зависимостей становится явной:
статическая типизация
трейты для чужих структур реализовывать нельзя
банально конфликт общих зависимостей
Например, мы хотим сделать геоинформационный сервис. Для этого нам понадобятся библиотеки для работы с пространственными данными, геокодированием, JSON.
Всё перечисленные библиотеки будут работать по отдельности, но не вместе. Чтобы их использовать придется написать кучу обёрток, адаптеров, маперов. Не факт, что это реализуемо в принципе.
Но не нужно тащить всё в стандартную библиотеку, это наносит прямой ущерб портируемости языка.
Можно подсмотреть как это сделано, например, в мире C#. Там в стандартной библиотеке есть интерфейсы для системных и базовых вещей. Основные вендоры типа Microsoft так же поставляют набор интерфейсов, но уже на пользовательском уровне. Сторонний разработчик может реализовать эти интерфейсы, это даёт его работе большую популярность, а сообщество взамен получает интегрируемое решение.
В Rust сейчас некоторые разработчики стараются выпускать набор интерфейсов для той области в которой работают. Но это не помогает, я думаю просто из-за человеческого фактора. Кто будет слушать каких-то там ноунеймов? Кажется что Rust очень нужен сильный покровитель, крупный вендор, на авторитет которого массовый разработчик будет реагировать, по аналогии с Microsoft или Google.
Ситуацию осложняет сила и изобразительность макросов. Ладно интерфейс, некоторые библиотеки приносят буквально свои DSL, правила мета программирования и прочие прелести кодогенерации.
Для выявления мотивирующих факторов на последнем этапе собеседования мы с HR проводим стресс-интервью.
Конечно, позже открываем карты: говорим, что это был стресс-тест, в действительности этим не нужно заниматься вовсе или в таком большом объёме.
Ловко вы разложили карты и обыграли этих шулеров айтишников!
А то приходят к вам в банк, скрывают свою внутреннюю мотивацию, не дают честным начальникам понять что же такое предложить вместо зарплаты, чтобы специалист работал за троих и был признателен компании за такую возможность.
Приведите пример когда нужен unique, но не primary key. По моему primary key и unique отличаются только тем, что unique может быть null
SQLite используют для конфигурации клиентских приложений, ручной работы с данными и даже как формат упаковки данных для передачи между приложениями.
Первичного ключа может не быть если есть:
Накопление данных, затем идентификация
Построение уникального индекса после того как заполнили таблицу
Проверка уникальности для колонки с динамической типизацией
Человекочитаемость и эргономика, несколько равноправных идентификаторов, явное указание колонок в ссылке и т.д.
Это конечно не значит что нужно использовать UNIQUE вместо первичного ключа в общем случае, но учитывать стоит если мы хотим получить гибкое и функциональное решение.
Иначе получится как у разработчика Tortoise ORM. Не знаю, как сейчас, но в начале он на полном серьёзе думал что у вас в каждой таблице есть колонка с названием "id" как первичный ключ. Все операции ORM были реализованы на этом допущении. Думаю не нужно пояснять чем такое решение плохо.
А зачем лишать себя целостности по внешним ключам, если она есть из коробки?
В SQLite проверка целостности опциональная, должна включаться при каждом подключении клиента специальной PRAGMA.
Если ваша система распределенная, есть много клиентов, или какие то из этих клиентов недоверенные, то считайте что проверки нет. Любой клиент может эту проверку не включать и таким образом испортить данные, несмотря на внешние ключи.
Это конечно не значит что всем нужно бежать и реализовывать свой механизм целостности, вместо штатного, на уровне приложения или ORM. Но как минимум такая попытка имеет смысл.
SQLite умеет динамически выбирать размер целочисленных данных в зависимости от фактической размерности значений. Это актуально только для процесса сериализации данных на хранение.
Клиентский драйвер вам всегда будет распаковывать и выдавать 64 битное знаковое число.
Его название в схеме таблицы не более чем сахар для адаптации различных диалектов SQL, можете называть как хотите: NUMERIC, INTEGER, INT, BIGINT, etc.
Хотя SQLite называют СУБД, фактически это просто библиотека для работы с массивом данных через SQL подобный интерфейс. Поэтому реализация некоторых аспектов ORM на уровне приложения может быть не ошибкой, а необходимостью.
Вот для примера, несколько интересных моментов по вашим замечаниям:
SQLite может вообще не контролировать соответствие схемы таблицы и типов передаваемых данных. Если добавить сюда динамичную природу Python, то инкапсуляция всей работы с данными в ActiveRecord уже не плохая идея.
Первичного ключа может не быть, физически даже ROWID в таблице может не быть. Так что использование UNIQUE частая и уместная практика в SQLite.
Проверка целостности по внешним ключам - опциональная для SQLite фича, полностью по желанию клиента. Поэтому использование собственной реализации через JSON может быть оправдано.
Подключение к SQLite это просто получение ручки на файл или оперативную память. Дорогостоящих операций установки соединения или прогрева отдельного процесса тут нет. Зато бывают сценарии когда нужно закрывать соединение для слаженной работы с локом файла.
Стоит учитывать специфику. Некоторые практики, привычные нам по опыту работы только с "большими СУБД", могут быть просто не применимы для SQLite.
Мы не закрываем себя шаблоном условного тимлида, который должен делать сразу 3 функции — технического лидера, строить процессы и работать с людьми и никак иначе. Мы создали настолько гибкую систему что команды самостоятельно начали под нее адаптироваться, самостоятельно распределять роли кто что возьмет, кто какую ответственность будет выполнять в продукте.
Тимлид должен выпонять сразу 3 функции потому что всё это одно целое. Здоровая атмосфера и мотивация членов команды прямо зависит от адекватности рабочих процессов, которые невозможно поставить без понимания технологических особенностей работы команды.
Зато подобное жонглирование ролями решает "проблему" автономного тимлида, который может слишком амбициозно отстаивать интересы своей команды перед вышестоящим руководителем. Полномочия распыляются и остаются только обязанности, которые теперь можно беспрепятственно требовать со всей команды. Так ведь?
Если я не прав, можете привести в пример какую из должностей топ-менеджеров вы по такой же системе распилили на несколько ролей и дали всем желающим эти роли брать на себя? По идее у топов ответственность и функциональный охват больше чем у тимлидов продуктовых команд.
Сообщество Хабра ценит содержательные статьи или оригинальный авторский взгляд. Дешёвое копирайтерство, повышение индекса цитируемости и переработка известного материала ради повышения собственной видимости здесь встречают прохладно.
Ваша статья никак не раскрывает тему и удивительным образом имеет структуру и содержание аналогичное первой статье в гугле по теме обратной связи. Блок ссылок и количество обработчиков материала для это статьи при этом непропорционально велик.
Такая публикация может расцениваться обывателями Хабра как наплевательское отношение. В краткосрочной перспективе это может привести к большому количеству негативных отзывов, которые испортят настроение вашей команде писателей статей. В долгосрочной перспективе это может привести к разрушению HR бренда вашей компании. Кандидаты будут меньше заинтересованы в ваших вакансиях. Заказчики будут меньше заинтересованы в сотрудничестве, потому что вы перестанете справляться с работой из-за нехватки кадров.
Детали на заводе перед изготовлением могут проходить испытания в аналитических системах: продуваются на аэродинамику, рассчитываются по матмодели, перепроверяются вручную проектной группой и т.д.
А вот ПО может поставляться частью программно-аппаратного комплекса или в виде коробочного решения, которое будет работать долгими релизными циклами без обновлений.
Так что получается разницы в подходах нет, инженерный опыт организации труда на заводах применим и для разработки ПО.
То не является исключением. Наши программы работают преимущественно с представлением материальных объектов, потому что нужны нам преимущественно для улучшения материального мира.
Исключением как раз являются некоторые предметные области, где объекты изначально виртуальные: игры, информация, и т.д.
Для примера. Какой код нужно написать чтобы у всех пользователей Хабра появились верифицированные паспортные данные? Это ведь не материальные объекты, по вашей логике, верно понимаю? На ваш взгляд, насколько это реализуемо и будет ли это быстрее чем изготовление деталей на заводе?
Если у вас не нашлось времени проконсультироваться с юристом или финансистом, то при чем тут эджайл?
Вопрос ведь в том когда это время для консультаций выделить. На старте проекта, в процессе проектирования и анализа бизнес требований или спустя N итераций гибкой методологии разработки.
Получается что гибкие методологии разработки подвержены рискам растраты ресурсов и создания нежизнеспособных продуктов, точно так же как и более консервативные методологии.
Эджайл про разработку ПО, а не про утрясание юридических моментов.
Программное обеспечение потому так и называется что является обеспечением какого-то человеческого опыта. Не стоит забывать что код и его разработка не цель, а всего лишь средство:
Вам не нужно ПО "Яндекс.Лавка", вам нужна доставка продуктов домой
Вам не нужно ПО "YouTube", вам нужно посмотреть видео
Вам не нужно ПО "Хабр", вам нужно читать статьи и обсуждать темы
Поэтому разработка действительно полезного и качественного ПО не может быть отделима от условий мира, окружающего человека.
Ну и вообще я всегда думал что понимание полезности продукта в основе любой гибкой методологии, странно что вы это разделяете. Если вы написали ПО которым нельзя пользоваться из-за юридических моментов то какой же это эджайл?
На моем "тривиальном" проекте более миллиона строк кода. Клиентская база - весь крупный ритейл Западной Европы. Работаем по канбану. Спокойно переписываем что хотим и когда хотим. Спокойно обновляем версии языка и фреймворков. Что мы делаем не так?
В своих рассуждениях вы фокусируетесь на средствах разработки, как будто это и есть цель гибких методологий. Но гибкие методологии утверждают что нужно фокусироваться на работающем продукте, а не формальных средствах.
Крупный ритейл Западной Европы действительно не тривиальный как сервис и продукт? Активно развивается? Вы каждую неделю разрабатываете обеспечение для новых моделей и форматов сбыта товара? Может быть меняете правила рынка?
Проект может быть объёмным по коду, но не обязательно это свидетельствует о концептуальной сложности развития продукта.
Или речь идёт о поддержке, предоставлении ещё одной витрины или интеграции с партнёром поверх существующих CRM, CMS, SAP? Тогда никаких вопросов, канбан тут идеально подходит.
Но вообще я не настаиваю. Будет здорово, если вы сможете рассказать про реальные примеры успешного применения гибких методологий для развития крупного ритейла. Таких примеров не хватает в любом обсуждении про эджайл.
Разработка ПО конечной целью имеет производство данных или оказание услуг с помощью этих данных. Поэтому аналогии на производство материальных объектов уместны.
Если вы 3 года разрабатывали новый B2C стартап, наращивали клиентскую базу, гибко шаг за шагом развивали продукт и только на финишной прямой поняли что, например, проведение платежей между клиентами невозможно в принципе по законодательству вашей страны — у вас большая проблема впустую потраченных ресурсов.
Ощущение, что скиловый коллектив может переделывать ПО хоть каждую неделю возникает если проект тривиален в своей сути или просто не запланирован на реальную эксплуатацию. Например, это характерно для многих наивных стартапов, которые делают без какой либо реально бизнес модели. Не удивительно что там Agile заходит на ура.
Речь о том что извращенное представление Agile методик исключает анализ задач как сложный и дорогой этап разработки, заменяя его "легковесными обсуждениями" по любому поводу.
В примере zodchiy задача была бы выполнена реально за 10 минут без согласований, если бы аналитик (дизайнер) изначально написал в задаче необходимый цвет.
Крупные продуктовые компании могут себе позволить релизные циклы по полгода и даже больше. Причины могут быть разные: монопольное положение на рынке, много ресурсов, и т.д.
Поэтому разработка новых продуктов возможна без быстрого TTM.
Ваш личный опыт предполагает что разработка новых продуктов возможна только в формате быстрого TTM, MVP и т.д.
Получается, обсуждая разработку нового продукта, вы бы положительно оценили кандидата который фактически не подходит вашим процессам и темпу разработки (который привык работать без TTM и MVP).
Выше в комментах вы уже говорили что вопросов будет несколько, можно будет уточнить. Согласен. В целом я просто хотел раскрыть мысль, что оценка даже односложных ответов лишена объективности. Делать выводы о техническом опыте человека сложно, что и говорить про психологический мир на скрининге.
Вот тут уже я бы поспорил. Все мы читали Карнеги-like книги, и умеем в нужные моменты выглядеть милыми и пушистыми.
Навыки Карнеги можно применять и в отношении рекрутера на сркрининге. Особенно если вы уже прошли несколько собеседований и примерно представляете тренды HR вопросов.
Добавьте стрессовую ситуацию собеседования - и человек совсем меняет своё обычное поведение.
Фит интервью проводят на заключительных этапах. Кандидат уже более менее уверен в собственных силах, потому что прошёл техническое собеседование. Интервьюеры с предыдущих этапов выглядят как знакомые. Всё это помогает избавиться от стресса.
Тут можно даже навредить: если кандидат с перепугу сделает грубую ошибку в общении, то коллектив его запомнит именно по ней. Рекрутёр же всё-таки менее подвержен первому впечатлению (по крайней мере, теоретически).
Так а цель у нас какая? Мы хотим получить мнение рекрутера или узнать получится ли у людей найти общий язык?
Проблема в том что рекрутер не работает в коллективе. Его впечатление – формальный этап в процессе найма. Влиять на производственную культуру и быть её представителем он не может, потому что буквально не занимается производственными задачами.
На фит интервью у вас есть реальная возможность посмотреть как у людей получается находить общий язык. Ну сделает кандидат одну ошибку, я думаю коллектив адекватных людей на это не обратит внимания. Другое дело если вся встреча состоит из ошибок, тогда это повод задуматься.
Он же не психолог. Да и психологу на это надо гораздо больше, чем одно интервью.
Да, изначально я и отреагировал на наглость и легкомысленность совета делать психологический портрет по скринингу.
К объективным скринингам претензий не имею. Примеры, которые вы приводите, разумны и в целом похоже мы одинаково понимаем проблему.
"В работе вы больше цените стабильность или динамичность?" Оба ответа правильные, но выбравшего первый вариант лучше включить в команду поддержки работающего продукта, а второй - в команду разработки нового.
Как быть разработчикам, которые хотят разрабатывать новый продукт в комфортных условиях, вдумчиво, без спешки? А если под "стабильностью" человек подразумевает социальные гарантии и четкий бизнес план развития компании в текущих реалиях?
Получается, вы бы их всех отправили на поддержку?
Первая проблема скрининга в этом. Вы принимаете решение на основе домыслов и собственного субъективного представления. Гораздо лучше работает, скажем, фит интервью, на котором коллектив может пообщаться с новым кандидатом в живую. С него вы получите объективный опыт общения людей, их впечатления и оценку "впишется" или нет.
Вторая проблема в заучивании ответов. Если у вас в вакансии написано "стартап", то большинство кандидатов вам и будут отвечать как им нравится динамичность, челендж и создание чего-то нового. Поэтому скрининг лучше применять только для грубого отсева по объективным критериям. Например, можно узнать умеет кандидат разговаривать на английском или нет, какие ожидания по зарплате.
Я согласен с вашим описанием проблемы и важностью темы, которую затрагивает автор. Но его утверждения, мягко скажем, сомнительны. Рекрутера, который готов предоставить психологический портрет по скринингу, едва ли можно назвать опытным. И советовать такое начинающим рекрутерам – ошибка, на мой взгляд.
Однако, я не претендую на истину, и изначально спрашивал без подвоха. Может быть у вас есть ещё примеры вопросов, которые действительно помогают что-то понять про человека на скрининге?
Такая отсылка выдаёт слабое понимание исторических реалий.
В те времена мужчины проектировали, руководили, придумывали алгоритмы и принимали инженерные решения. Женщины составляли отчеты, заполняли бумаги, набивали код на перфокартах.
На сайте NASA прямым текстом написано, что за успех Explorer ответственны трое мужчин, а в проекте Меркурий нет женщин на ключевых должностях.
Заниматься "сложными математическими расчетами" значит сидеть и нудно забивать десятки формул в калькулятор. Это рутинная работа для высвобождения ключевого персонала.
Даже сейчас можно найти пример таких "комьютерщиц". В больницах врачи не заполняют отчеты, не считают статистику по заболеваниям. Это делает отдел статистики. Отдел состоит полностью из женщин. Эти женщины ничего не программируют, но делают "сложные статистические и аналитические расчеты".
Как вы понимаете, есть принципиальная разница между такими "расчетницами" и программистками.
Бездумное повторение чужих мыслей — база для стереотипного мышления. Вся статья построена на попсовой интерпретации фактов, которые наоборот только закрепляют все изложенные проблемы. Возникает вопрос. Вы в какую сторону воюете?
Замечать и решать реальные проблемы людей сложно когда внимание и пространство для диалога заполняет инфо-мусор.
Недавно открыл для себя пользу профильных социальных сетей в этом вопросе. В той же хаброкарьере можно найти компанию и по списку её сотрудников:
Понять какой опыт имеют ключевые сотрудники компании, откуда они пришли
Попросить обратную рекомендацию, узнать о причинах увольнения тех кто ушел
Для начала перестать думать что профессионалы это наивные энтузиасты, которые вам за спасибо будут развивать отрасль.
Проблемы кадров нет, есть проблема в головах руководства российских компаний, которые думают что зарплата в номинальном выражении аналогичная зарплатам 2010 года может кого-то привлечь или способствовать развитию отрасли.
Сначала они рассказывают как храбро принимают риски, как сложно найти инвесторов и выйти на рынок. А потом они же идут и вливают деньги в рекламные компании своего игрового продукта, где разовая рекламная интеграция может стоить как месячная зарплата опытного сценариста или художника.
Не удивительно что после этого профессионал лучше пойдет стримить или канал на ютубе создаст, чем будет вкладывать силы в такую отрасль.
Про самостоятельные инди команды я вообще молчу. Ты еще думать не начал про свой проект, а уже должен государству налогами, отчетами и т.д. С некоторых пор вот не можешь инструменты для разработки получить, потому что не оплатить. Чувствуешь себя подпольщиком и нелегалом каким-то пока собираешь команду для разработки игры.
После этого рассказы про поддержку и гранты на проекты по повестке выглядят как издёвка.
Интересно что падением морали вы считаете доверчивость и низкую образованность людей, которые ведутся на схемы мошенников. Я вот всегда думал что мораль это про боевой дух и настроение (от которого зависит соблюдение установленных норм и правил).
В этом смысле упаднические мнения и комментарии вроде вашего эту самую мораль и опускают. Сложно работать, создавать и творить когда из каждого угла говорят как всё плохо и безнадежно потеряно. Адепты Блиновской хотя бы верят в свой успех.
Возможно даже стоит поучиться у этих мошенников в некоторых вопросах мотивации людей. Например, может для поднятия трудовой мотивации в стране нужна идея и привлекательная цель, которую бы люди хотели достигать, используя понятные правила и вознаграждения?
А пока такой цель нет, увы, ничего не остается многим как идти на марафон желаний и прочие курсы успеха.
Проблема серьёзнее чем кажется.
Как только ваши требования становятся чуть кастомнее чем использование одного Rust фреймворка, проблема зависимостей становится явной:
статическая типизация
трейты для чужих структур реализовывать нельзя
банально конфликт общих зависимостей
Например, мы хотим сделать геоинформационный сервис. Для этого нам понадобятся библиотеки для работы с пространственными данными, геокодированием, JSON.
Всё перечисленные библиотеки будут работать по отдельности, но не вместе. Чтобы их использовать придется написать кучу обёрток, адаптеров, маперов. Не факт, что это реализуемо в принципе.
Но не нужно тащить всё в стандартную библиотеку, это наносит прямой ущерб портируемости языка.
Можно подсмотреть как это сделано, например, в мире C#. Там в стандартной библиотеке есть интерфейсы для системных и базовых вещей. Основные вендоры типа Microsoft так же поставляют набор интерфейсов, но уже на пользовательском уровне. Сторонний разработчик может реализовать эти интерфейсы, это даёт его работе большую популярность, а сообщество взамен получает интегрируемое решение.
В Rust сейчас некоторые разработчики стараются выпускать набор интерфейсов для той области в которой работают. Но это не помогает, я думаю просто из-за человеческого фактора. Кто будет слушать каких-то там ноунеймов? Кажется что Rust очень нужен сильный покровитель, крупный вендор, на авторитет которого массовый разработчик будет реагировать, по аналогии с Microsoft или Google.
Я так же думал 3 года назад. Воз и ныне там.
Ситуацию осложняет сила и изобразительность макросов. Ладно интерфейс, некоторые библиотеки приносят буквально свои DSL, правила мета программирования и прочие прелести кодогенерации.
Ловко вы разложили карты и обыграли этих шулеров айтишников!
А то приходят к вам в банк, скрывают свою внутреннюю мотивацию, не дают честным начальникам понять что же такое предложить вместо зарплаты, чтобы специалист работал за троих и был признателен компании за такую возможность.
SQLite используют для конфигурации клиентских приложений, ручной работы с данными и даже как формат упаковки данных для передачи между приложениями.
Первичного ключа может не быть если есть:
Накопление данных, затем идентификация
Построение уникального индекса после того как заполнили таблицу
Проверка уникальности для колонки с динамической типизацией
Человекочитаемость и эргономика, несколько равноправных идентификаторов, явное указание колонок в ссылке и т.д.
Это конечно не значит что нужно использовать UNIQUE вместо первичного ключа в общем случае, но учитывать стоит если мы хотим получить гибкое и функциональное решение.
Иначе получится как у разработчика Tortoise ORM. Не знаю, как сейчас, но в начале он на полном серьёзе думал что у вас в каждой таблице есть колонка с названием "id" как первичный ключ. Все операции ORM были реализованы на этом допущении. Думаю не нужно пояснять чем такое решение плохо.
В SQLite проверка целостности опциональная, должна включаться при каждом подключении клиента специальной PRAGMA.
Если ваша система распределенная, есть много клиентов, или какие то из этих клиентов недоверенные, то считайте что проверки нет. Любой клиент может эту проверку не включать и таким образом испортить данные, несмотря на внешние ключи.
Это конечно не значит что всем нужно бежать и реализовывать свой механизм целостности, вместо штатного, на уровне приложения или ORM. Но как минимум такая попытка имеет смысл.
А нет же. Сам сказанул не то, сам себя поправлю.
По официальной документации SQLite, действительно есть NUMERIC тип, и это совсем не то же самое что и INTEGER.
Мне как и автору видимо привычно числа с фиксированными точностью и масштабом называть DECIMAL, поэтому такая путаница возникла.
SQLite умеет динамически выбирать размер целочисленных данных в зависимости от фактической размерности значений. Это актуально только для процесса сериализации данных на хранение.
Клиентский драйвер вам всегда будет распаковывать и выдавать 64 битное знаковое число.
Его название в схеме таблицы не более чем сахар для адаптации различных диалектов SQL, можете называть как хотите: NUMERIC, INTEGER, INT, BIGINT, etc.
Хотя SQLite называют СУБД, фактически это просто библиотека для работы с массивом данных через SQL подобный интерфейс. Поэтому реализация некоторых аспектов ORM на уровне приложения может быть не ошибкой, а необходимостью.
Вот для примера, несколько интересных моментов по вашим замечаниям:
SQLite может вообще не контролировать соответствие схемы таблицы и типов передаваемых данных. Если добавить сюда динамичную природу Python, то инкапсуляция всей работы с данными в ActiveRecord уже не плохая идея.
Первичного ключа может не быть, физически даже ROWID в таблице может не быть. Так что использование UNIQUE частая и уместная практика в SQLite.
Проверка целостности по внешним ключам - опциональная для SQLite фича, полностью по желанию клиента. Поэтому использование собственной реализации через JSON может быть оправдано.
Подключение к SQLite это просто получение ручки на файл или оперативную память. Дорогостоящих операций установки соединения или прогрева отдельного процесса тут нет. Зато бывают сценарии когда нужно закрывать соединение для слаженной работы с локом файла.
Стоит учитывать специфику. Некоторые практики, привычные нам по опыту работы только с "большими СУБД", могут быть просто не применимы для SQLite.
Тимлид должен выпонять сразу 3 функции потому что всё это одно целое. Здоровая атмосфера и мотивация членов команды прямо зависит от адекватности рабочих процессов, которые невозможно поставить без понимания технологических особенностей работы команды.
Зато подобное жонглирование ролями решает "проблему" автономного тимлида, который может слишком амбициозно отстаивать интересы своей команды перед вышестоящим руководителем. Полномочия распыляются и остаются только обязанности, которые теперь можно беспрепятственно требовать со всей команды. Так ведь?
Если я не прав, можете привести в пример какую из должностей топ-менеджеров вы по такой же системе распилили на несколько ролей и дали всем желающим эти роли брать на себя? По идее у топов ответственность и функциональный охват больше чем у тимлидов продуктовых команд.
Вот вам обратная связь по модели SOR.
Сообщество Хабра ценит содержательные статьи или оригинальный авторский взгляд. Дешёвое копирайтерство, повышение индекса цитируемости и переработка известного материала ради повышения собственной видимости здесь встречают прохладно.
Ваша статья никак не раскрывает тему и удивительным образом имеет структуру и содержание аналогичное первой статье в гугле по теме обратной связи. Блок ссылок и количество обработчиков материала для это статьи при этом непропорционально велик.
Такая публикация может расцениваться обывателями Хабра как наплевательское отношение. В краткосрочной перспективе это может привести к большому количеству негативных отзывов, которые испортят настроение вашей команде писателей статей. В долгосрочной перспективе это может привести к разрушению HR бренда вашей компании. Кандидаты будут меньше заинтересованы в ваших вакансиях. Заказчики будут меньше заинтересованы в сотрудничестве, потому что вы перестанете справляться с работой из-за нехватки кадров.
Детали на заводе перед изготовлением могут проходить испытания в аналитических системах: продуваются на аэродинамику, рассчитываются по матмодели, перепроверяются вручную проектной группой и т.д.
А вот ПО может поставляться частью программно-аппаратного комплекса или в виде коробочного решения, которое будет работать долгими релизными циклами без обновлений.
Так что получается разницы в подходах нет, инженерный опыт организации труда на заводах применим и для разработки ПО.
То не является исключением. Наши программы работают преимущественно с представлением материальных объектов, потому что нужны нам преимущественно для улучшения материального мира.
Исключением как раз являются некоторые предметные области, где объекты изначально виртуальные: игры, информация, и т.д.
Для примера. Какой код нужно написать чтобы у всех пользователей Хабра появились верифицированные паспортные данные? Это ведь не материальные объекты, по вашей логике, верно понимаю? На ваш взгляд, насколько это реализуемо и будет ли это быстрее чем изготовление деталей на заводе?
Вопрос ведь в том когда это время для консультаций выделить. На старте проекта, в процессе проектирования и анализа бизнес требований или спустя N итераций гибкой методологии разработки.
Получается что гибкие методологии разработки подвержены рискам растраты ресурсов и создания нежизнеспособных продуктов, точно так же как и более консервативные методологии.
Программное обеспечение потому так и называется что является обеспечением какого-то человеческого опыта. Не стоит забывать что код и его разработка не цель, а всего лишь средство:
Вам не нужно ПО "Яндекс.Лавка", вам нужна доставка продуктов домой
Вам не нужно ПО "YouTube", вам нужно посмотреть видео
Вам не нужно ПО "Хабр", вам нужно читать статьи и обсуждать темы
Поэтому разработка действительно полезного и качественного ПО не может быть отделима от условий мира, окружающего человека.
Ну и вообще я всегда думал что понимание полезности продукта в основе любой гибкой методологии, странно что вы это разделяете. Если вы написали ПО которым нельзя пользоваться из-за юридических моментов то какой же это эджайл?
В своих рассуждениях вы фокусируетесь на средствах разработки, как будто это и есть цель гибких методологий. Но гибкие методологии утверждают что нужно фокусироваться на работающем продукте, а не формальных средствах.
Крупный ритейл Западной Европы действительно не тривиальный как сервис и продукт? Активно развивается? Вы каждую неделю разрабатываете обеспечение для новых моделей и форматов сбыта товара? Может быть меняете правила рынка?
Проект может быть объёмным по коду, но не обязательно это свидетельствует о концептуальной сложности развития продукта.
Или речь идёт о поддержке, предоставлении ещё одной витрины или интеграции с партнёром поверх существующих CRM, CMS, SAP? Тогда никаких вопросов, канбан тут идеально подходит.
Но вообще я не настаиваю. Будет здорово, если вы сможете рассказать про реальные примеры успешного применения гибких методологий для развития крупного ритейла. Таких примеров не хватает в любом обсуждении про эджайл.
Разработка ПО конечной целью имеет производство данных или оказание услуг с помощью этих данных. Поэтому аналогии на производство материальных объектов уместны.
Если вы 3 года разрабатывали новый B2C стартап, наращивали клиентскую базу, гибко шаг за шагом развивали продукт и только на финишной прямой поняли что, например, проведение платежей между клиентами невозможно в принципе по законодательству вашей страны — у вас большая проблема впустую потраченных ресурсов.
Ощущение, что скиловый коллектив может переделывать ПО хоть каждую неделю возникает если проект тривиален в своей сути или просто не запланирован на реальную эксплуатацию. Например, это характерно для многих наивных стартапов, которые делают без какой либо реально бизнес модели. Не удивительно что там Agile заходит на ура.
Речь о том что извращенное представление Agile методик исключает анализ задач как сложный и дорогой этап разработки, заменяя его "легковесными обсуждениями" по любому поводу.
В примере zodchiy задача была бы выполнена реально за 10 минут без согласований, если бы аналитик (дизайнер) изначально написал в задаче необходимый цвет.
Крупные продуктовые компании могут себе позволить релизные циклы по полгода и даже больше. Причины могут быть разные: монопольное положение на рынке, много ресурсов, и т.д.
Поэтому разработка новых продуктов возможна без быстрого TTM.
Ваш личный опыт предполагает что разработка новых продуктов возможна только в формате быстрого TTM, MVP и т.д.
Получается, обсуждая разработку нового продукта, вы бы положительно оценили кандидата который фактически не подходит вашим процессам и темпу разработки (который привык работать без TTM и MVP).
Выше в комментах вы уже говорили что вопросов будет несколько, можно будет уточнить. Согласен. В целом я просто хотел раскрыть мысль, что оценка даже односложных ответов лишена объективности. Делать выводы о техническом опыте человека сложно, что и говорить про психологический мир на скрининге.
Навыки Карнеги можно применять и в отношении рекрутера на сркрининге. Особенно если вы уже прошли несколько собеседований и примерно представляете тренды HR вопросов.
Фит интервью проводят на заключительных этапах. Кандидат уже более менее уверен в собственных силах, потому что прошёл техническое собеседование. Интервьюеры с предыдущих этапов выглядят как знакомые. Всё это помогает избавиться от стресса.
Так а цель у нас какая? Мы хотим получить мнение рекрутера или узнать получится ли у людей найти общий язык?
Проблема в том что рекрутер не работает в коллективе. Его впечатление – формальный этап в процессе найма. Влиять на производственную культуру и быть её представителем он не может, потому что буквально не занимается производственными задачами.
На фит интервью у вас есть реальная возможность посмотреть как у людей получается находить общий язык. Ну сделает кандидат одну ошибку, я думаю коллектив адекватных людей на это не обратит внимания. Другое дело если вся встреча состоит из ошибок, тогда это повод задуматься.
Да, изначально я и отреагировал на наглость и легкомысленность совета делать психологический портрет по скринингу.
К объективным скринингам претензий не имею. Примеры, которые вы приводите, разумны и в целом похоже мы одинаково понимаем проблему.
Как быть разработчикам, которые хотят разрабатывать новый продукт в комфортных условиях, вдумчиво, без спешки? А если под "стабильностью" человек подразумевает социальные гарантии и четкий бизнес план развития компании в текущих реалиях?
Получается, вы бы их всех отправили на поддержку?
Первая проблема скрининга в этом. Вы принимаете решение на основе домыслов и собственного субъективного представления. Гораздо лучше работает, скажем, фит интервью, на котором коллектив может пообщаться с новым кандидатом в живую. С него вы получите объективный опыт общения людей, их впечатления и оценку "впишется" или нет.
Вторая проблема в заучивании ответов. Если у вас в вакансии написано "стартап", то большинство кандидатов вам и будут отвечать как им нравится динамичность, челендж и создание чего-то нового. Поэтому скрининг лучше применять только для грубого отсева по объективным критериям. Например, можно узнать умеет кандидат разговаривать на английском или нет, какие ожидания по зарплате.
Я согласен с вашим описанием проблемы и важностью темы, которую затрагивает автор. Но его утверждения, мягко скажем, сомнительны. Рекрутера, который готов предоставить психологический портрет по скринингу, едва ли можно назвать опытным. И советовать такое начинающим рекрутерам – ошибка, на мой взгляд.
Однако, я не претендую на истину, и изначально спрашивал без подвоха. Может быть у вас есть ещё примеры вопросов, которые действительно помогают что-то понять про человека на скрининге?