Каждый ModelView выступает в роли модели/контроллера для ведомых ModelView и в качестве отображения для владеющего ModelView. Часть логики может выноситься как в чистые Model, так и в чистые View, которые являются лишь вырожденными случаями ModelView.
$my_user_list $my_view
- \Owner ModelView
users? /$my_user
kids /
<= Row*0 $my_user_row
user <= user*
$my_user_row $my_card
- \Having ModevView
user $my_user
avatar => image
nickname => message
$my_card $my_view
- \View not Model
kids /
<= Image $my_image
uri <= image \about:blank
<= Message $my_text
text <= message \
$my_user $my_model
- \Model not View
avatar? \
nickname? \
✅ Каждый ModelView полностью контролирует внутренние ModelView и ничего не знает про внешние. ✅ Любой ModelView может шариться между разными другими ModelView на любом уровне композиции. ✅ Изменение интерфейса ModelView требует изменения только лишь его владельцев. ✅ Фрактальная структура легко масштабируется на приложения любого размера.
При работе с проджект-менеджерами мы в AGIMA придерживаемся общепринятой классификации: джуниор — миддл — сеньор. Какими навыками должен обладать каждый из них, рассказываем в отдельной статье. А чтобы определить грейд, используем внутреннее грейдовое тестирование.
Наша грейдовая система не привязана к зарплатам — она растет вне зависимости от грейда. Менеджер сдает тест на новый уровень, если хочет работать над более амбициозными задачами.
Для подготовки к тесту достаточно нашей Wiki, базы знаний. Все регламенты в ней разбиты по уровням: как раз для джунов, миддлов и сеньоров. На сегодняшний день у нас более 200 вопросов для разных уровней. Но на самом «экзамене» ответить нужно на 20. Тестирование проходит онлайн в системе INDIGO.
В тестах мы используем вопросы разных типов: с одним ответом, с несколькими, с полем для свободного ввода. У каждого вопроса свой вес. Считается, что успешно пройденный тест — это 80% правильных ответов. Любой вопрос можно разобрать после тестирования. А если сотрудник не согласен с результатом — то и оспорить.
Плюсы такой системы:
помогает адаптировать стажеров;
помогает менеджерам проанализировать свой опыт;
мотивирует больше читать и погружаться в профессию;
она не привязана к зарплате и не давит на человека;
позволяет в игровой форме запоминать регламенты.
Кроме того, тестирование помогает нам улучшать качество базы знаний. Как — рассказываем в нашем блоге.
Вышла вторая редакция проекта PLB (Programming Language Benchmark) по тестированию производительности решения типовых задач на различных языках программирования. В ней измеряется производительность кода для умножения матриц и решения задачи расстановки 15-ферзей, а также дополнительно оценивает поиск решений в игре Судоку и определение пересечений двух массивов.
Код для тестирования PLB написан на 20 языках программирования. Наиболее высокую производительность показала реализация тестовых приложений на языке C (при компиляции в clang). На втором месте оказался язык Zig, на третьем Nim, на четвёртом Mojo. Далее примерно на одном уровне следуют D, Java, JavaScript-платформа Bun и Rust, а после них Go, Crystal и V.
Высокие результаты показали Node.js, Dart, Lua и C#. Хорошие показатели у Java и C# объясняются использованием отдельной стадии JIT-компиляции, в то время как в Dart, Bun, Node.js, Julia, LuaJIT, PHP, PyPy и Ruby3 (YJIT) JIT-компиляция выполняется на лету и затрагивает только часто выполняемый код. JavaScript-платформа Bun заметно обогнала Node.js. Относительно медленными оказались результаты у Julia и Swift.
Наихудшие показатели производительности выявлены у PHP, Ruby, Perl и CPython, при этом производительность PHP оказалась примерно в 4 раза выше, чем CPython.
Дополнение: В реализации на языках Rust, D и Julia внесены оптимизации, которые позволили Rust занять второе место, D - третье, Julia - 7, а V показаллучший результат в nqueen+matmul.
