Pull to refresh
8
0
Алексей Хлебников @alexeikh

User

Send message
В целом с комментом согласен, но наезд на Руби не в тему.

Руби 1.8 вышел в 2003 году, а Руби 2.0 в 2013. Так что с «2.5 года» вы как-то погорячились. И уж не помню, что там сломали в 2.0, но помню, что весь старый код, который я пробовал с новой версией интерпретатора, продолжал работать. Не спорю, что какие-то мелочи может и сломали, но, читая вас, создаётся впечатление, что прям вообще всё сломали и на новой версии даже и пытаться не стоит запускать старый код. Это, конечно, не так.

Выберите лучше другой пример. И проверьте его на достоверность. Или не приводите вообще.
Да и тут вопрос, кто над кем надругался. :) Так-то очень мучительно было эти обёртки делать.
Потому что надо было собирать для платформ, которые не поддерживают глобальные переменные.
Однопоточность сначала была фичей, а потом стала проблемой. :)

Насчёт кастомных браузеров и вообще кроссплатформенности — так и есть. Я на эту тему доклад делал.

Статья на тему доклада: https://lvee.org/ru/abstracts/155
Слайды: https://lvee.org/uploads/image_upload/file/385/Alexei_Khlebnikov.Crossplatform.2015-06-07.pdf

В этих материалах есть и общая информация об архитектуре (код ядра vs код платформы). Не очень много, всё-таки NDA.

И, «чтоб 2 раза не вставать», хочу порекомендовать отличную конференцию — LVEE.org, на которой я и делал тот доклад.
Готов демо-сервер: github.com/jensl/critic/issues/6#issuecomment-10189430. К сожалению, read-only, но создано 1 review, в нём несколько коммитов и issues/notes.
> следующее, при довольно стандартном использовании, если внезапно скачки напряжения, соответственно PC уходит в ребут (у меня нет упса), после перезагрузки, опера просто не сохраняла вкладки. Смотрел файл (точное название не помню) настроек, заполнен NULL'ами.

Я думаю, это ОС не успела записать данные из дискового кэша на сам диск при внезапной перезагрузке. И Опера тут, к сожалению, ничего сделать не может. У меня такое несколько раз было, не в Опере. Один раз даже конфиг KDM-а забило нулями, и он аварийно выходил при запуске, так что невозможно было через иксы залогиниться. Пришлось исследовать и исправлять проблему из консоли.
Нужно запушить новые коммиты в r/user/branch. В ветку с «r/» префиксом, это важно. Я так понимаю, при этом должен выпониться git pre-receive hook github.com/jensl/critic/blob/master/hooks/pre-receive, который и даст знать Critic-у про новый коммит.

Хук то установили? Вот здесь дока, если что: git-scm.com/book/en/Customizing-Git-Git-Hooks.
Да, и правда, Github Enterprise ставится внутри организации. И да, согласен, дороговато. А для огромной корпорации оно и дороже будет, там цена растёт линейно от количества пользователей.
> Как ограничивать доступ к ФС?

Как я понимаю, имеется в виду доступ к ФС репозитория, и доступ туда есть только через git. Ну, тогда так же, как и просто к любому git-репозиториию. И Critic тут вообще не при делах. У меня такое чувство, что я не понял вопроса.

UPD. А, или речь про то, что встроенный в Critic repository viewer будет показывать весь код, до которого сможет дотянуться сам? Это да, будет.

> Как назначить пользователя без прав редактирования?

Без прав редактирования review, то есть добавления проблем и замечаний? Это да, никак.

> Правильно понимаю концепцию, что при обновлении репов создаётся новая ветка?

«При обновлении репов»? Я бы сказал, «при создании review». Да, при создании review создаётся новая ветка. Та самая, с префиксом «r/».

> И что с работай с репами, отслеживаемыми другими системами (мой случай — это директория gitolite, к которой прикручен, допиленный под себя ,gitlist, репы администрируются через плагин redmine)?

Critic интересуют только ветки с префиксом «r/». Поэтому я не вижу причин для конфликтов с другим софтом, как то gitolite, gitlist или redmine.

Кроме repo viewer-a, который, как я сказал, пользователям Critic покажет всё, что видит сам Critic, что может быть нежелательно.

> Понял, что интеграция с web-интерфейсами git есть, а что кроме просмотра там делать не ясно.

В repo viewer-e — разве что review создать. А вот в созданном review можно выделить мышкой один или несколько коммитов, в них найти изменённые файлы, в них найти и выделить мышкой строки кода, и Critic предложит создать проблему (issue) или замечание (note). А также напротив имён файлов есть галочки, которые если проставить — просмотренный файл в данных коммитах будет помечен как проинспекированный. Но эта галочка доступна только инспекторам (reviewers). Чтобы стать инспектором, надо или добавить себя явно, там в review есть кнопка типа «Add reviewers», или заранее добавить фильтр «для каталогов (думайте: модулей) таких-то назначать меня инспектором». Обычно ответственный за модуль назначает себя его инспектором 1 раз, и после этого ему приходят уведомления обо всех review, содержащих изменения кода в этом модуле, а также он автоматически назначается инспектором своих модулей в каждом новом review. Т.е. фильтры срабатывают при создании review.
В Critic нет никакого экрана логина для пользователя. По крайней мере, я никогда не видел. Когда я пользуюсь Critic, я вхожу на сервер, используя HTTP authentication. Не знаю, кто его предоставляет, сам Critic или Apache.

> Назначение web-интерфейса, кажется, сведено к добавлению репов и редактирования уведомлений.

БОльшая часть web-интерфейса предназначена для работы над review. Но review должно существовать, чтобы над ним можно было работать. Если открытые review существуют, и вы на них подписаны — они находятся в Dashboard. Чтобы подписаться на review определённых каталогов — надо создать фильтр с каталогом, внутри которого находятся интересующие файлы. Каталог может быть "/", тогда произойдёт подписка на все каталоги и файлы. Чтобы создать review, надо затолкнуть ветку в git репозиторий Critic-a с префиксом «r/». Это возможно через web-интерфейс, или просто через git push.
Тут вопрос не только в деньгах, но и в доверии своего кода и его обсуждений сторонней компании. Даже если вы доверяете, что Github ничего плохого не сделает, вдруг его взломают?

Также, в случае собственного сервера у организации больше контроля, во всех смыслах. Например, есть полный доступ к базам данных. В случае миграции на другую code review system (или другую VCS), есть возможность написать преобразователь данных из формата одной системы в формат другой. Можно дописать интеграцию с другим софтом, использующимся в компании. Да много всего.

А что там есть из функционала? Я заметил только, что можно комментировать строки кода. И можно комментировать одну и ту же строку несколько раз, таким образом «ведя беседу».

К примеру, в Critic есть:
* Понятие «review» наподобие бага в BTS.
* Workflow для review: сoздание, инспектирование, создание записей о проблемах и замечаниях, работа над проблемами и замечаниями, одобрение, закрытие.
* Понятия собственно «проблемы» и «замечания».
* Отдельные потоки обсуждения каждой проблемы, если например, для тех же строк создано несколько «проблем».
* Возможность привязывания проблемы и замечания к диапазону строк, а не к одной строке.

Т.е. даже в базовом функционале Critic отличается от «Github reviewer-a», примерно как BTS отличается от обсуждения бага в мэйллисте.

Ну и плюс ещё те плюшки, которые собственно описаны в статье.
Большое спасибо за скриншоты! А то я уж думал, как и скриншоты сделать, и NDA соблюсти, и персональную копию Critic не ставить.

> безопасностью ребята не заморачивалсь

Что имеется в виду?

> Ждём обновлений и нормальных манов

Документации и правда немного, но она есть. Видите на скриншотах линк «Tutorial» сверху? Там вкратце, да, к сожалению вкратце, описаны наиболее популярные use-case-ы, как то создание review, rebasing, etc. То же самое можно почитать здесь: github.com/jensl/critic/tree/master/tutorials. Также есть немного документации здесь: github.com/jensl/critic/tree/master/documentation.

Возможно, наш Developer Relations Team напишет статью или несколько на dev.opera.com/, чтоб было попонятней.

И я могу на вопросы поотвечать, правда я сам никогда Critic не ставил и не админил, только пользовался. Можно начать, если интересно. У вас получилось создать review?
Действительно, поддерживается только git. Потому что Critic был изначально написан как внутренняя система для использования в Опере и в инфраструктуре Оперы. Решение о выпуске Critic «наружу» и открытии кода было принято позже. Потому что система получилась действительно хорошей, а, так как Critic не конкурирует с основным бизнесом Оперы, почему бы не выпустить её и не сделать мир лучше?

Планов по добавлению других VCS, насколько я знаю, нет. Опере и Йенсу это просто не нужно. Кому нужно — могут собраться вместе и, собственно, дописать поддержку Mercurial или чего другого, благо исходники есть и лицензия позволяет.
Многие команды gdb можно сокращать до одного символа:

Запустить программу: run или r
Шаг вперёд: next или n
Войти в функцию: step или s
Поставить новый breakpoint: break или b
«Отпустить» выполнение до следующего breakpoint-а: continue или c

Иногда до двух-трёх символов:
Отключить breakpoint 3: disable 3 или dis 3
Включить breakpoint 3 обратно: enable 3 или en 3
Выполнять код до строчки 123: advance 123 или adv 123
Выполнять код до конца функции: finish или fin

Конечно, не совсем шорткаты, но почти.
Также можно запускать переключаться между обычной командной строкой и TUI c с помощью «Ctrl-X A» или «Ctrl-X Ctrl-A», т.е. не важно, когда вы отжали Ctrl после Ctrl-X.

Information

Rating
Does not participate
Location
Oslo, Oslo, Норвегия
Registered
Activity