токен выданный в личном кабинете в dev.hh.ru действует примерно 2 недели. каждые 2 недели или чаще можно получать новый.
если хочется получить «постоянный токен», нужно зарегистрировать приложение, провести авторизацию приложения (можно вручную, хватит curl'а), затем получить пару access token + refresh token, их можно будет по истечению 2-х недель поменять на новую пару access token + refresh token и так далее.
ограничение времени жизни access token'а сделано по соображением безопасности.
Расскажу про свой опыт и задам пару вопросов. Надеюсь alexeikh мне поможет.
Мы давно в компании ищем подходящий инструмент для code review (git). Опробовали много всего и gerrit и crew (http://crew-cr.org/) и ещё кучу каких-то поделок. Сейчас пока остановились на встроенном в gitLab (http://gitlabhq.com/), так как GitLab мы используем для всего остального связанного с git.
В общем, попробовали сегодня развернуть critic.
Мы для этого сразу выделили отдельную вирт машину в нашем «облаке». На неё взгромоздили ubuntu server 12.04.
Авторизацию сделали так: установили critic с авторизацией «host» (т.е. на совести Apache), в Apache включили авторизацию через mod_authnz_external + pwauth + authnx_unixgroup.
Всё это наличиствует в пакетах, настройка ограничивается небольшими модификациями вирт. хоста для Apache, который генерит установщик critic:
Alias /static-resource/ "/usr/share/critic/resources/"
<Directory "/usr/share/critic/resources">
Options Indexes MultiViews FollowSymLinks
AllowOverride None
Order allow,deny
Allow from all
ExpiresActive On
ExpiresDefault A2592000
<[слеш]Directory>
<[слеш]VirtualHost>
(если кто-то будет брать за основу не забудьте [слеш] заменить на символ, в исходном виде это ломало тег spoiler).
В итоге в critic попадают тем, кому создали аккаунт на сервере и добавили в группу critic. Этих же прав будет достаточно для push'инга веток на code review.
Судя по тому, что приложение wsgi'ное позже apache мы возможно заменим чем-то более подходящим.
Дальше настроили репозитории. Для этого пользователю critic сделали deploy ключ к нужным нам репозиториям в GitLab (технически для управления git там gitolite).
Репозитории успешно загрузили, отправили тестовый review. Попробовали пописать комментов и issues. Всё в общем и целом не плохо пошло. Возможно нам хотелось бы немного поправить мелочи в интерефейсе и логике. При удачном стечении обстоятельств стоит ожидать от нас Merge Request'ов на GitHub'e.
Но тут и возникает вопрос: как не бились так и не поняли, как по результатам review поправить код и добавить к review новые комиты? Нужно создать новую ветку? Что-то запушить в /r/user/branch или как?
Буду благодарен за помощь. Так как чтение всего встоенного Tuturial и FAQ не дали ответа.
В OS X, кстати, python тоже вполне неплохо ставиться и через MacPorts. При этом можно держать несколько версий. По факту, я, например, держу 4 штуки. Даже можно менять дефолтную версию (остальные будут вызываться как pythonx.y).
Наверное можно и через HomeBrew или pythonbrew ставить, но пока это не пробовал.
Именно так он и поступает :) За подробностями можно заглянуть в ext/spl/php_spl.c (и поискать php_spl_object_hash), причём базовый хеш намерено рандомизируется в кажом вызове.
Я таким образом хотел проиллюстрировать, что это один и тот же объект. Можно это понять и через var_dump, но как-то менее наглядно, плюс мне нужно было значение в виде переменной.
Уточню, что созданный «чистый» объект будет жить до конца выполнения скрипта и будет всегда использоваться для создания новых объектов. Однако при хотябы каком-нибудь изменении будет создаваться копия, куда уже эти изменения и попадут.
P.S Что-то по воскресеньям не могу излагать мысли в простом виде: )
если хочется получить «постоянный токен», нужно зарегистрировать приложение, провести авторизацию приложения (можно вручную, хватит curl'а), затем получить пару access token + refresh token, их можно будет по истечению 2-х недель поменять на новую пару access token + refresh token и так далее.
ограничение времени жизни access token'а сделано по соображением безопасности.
Вероятно тут все же имелся ввиду контравариантный функтор.
P.S за статью спасибо.
Очень жаль будет потерять возможность читать новости в прекрасном Reeder для iPad.
Ошибка была в том, что мы использовали короткий формат, находясь при этом не в ветке '/r/...', а в исходной, которая послужила основой для неё.
Спасибо за помощь.
Кому интересно, шаги должны быть такие:
error: src refspec r/testdev/super-fix does not match any.
error: failed to push some refs to 'testdev@example.com:/var/git/sandbox.git'
Хук на месте, его создал сам critic в своих локальных версиях репозиториев.
Мы давно в компании ищем подходящий инструмент для code review (git). Опробовали много всего и gerrit и crew (http://crew-cr.org/) и ещё кучу каких-то поделок. Сейчас пока остановились на встроенном в gitLab (http://gitlabhq.com/), так как GitLab мы используем для всего остального связанного с git.
В общем, попробовали сегодня развернуть critic.
Мы для этого сразу выделили отдельную вирт машину в нашем «облаке». На неё взгромоздили ubuntu server 12.04.
Авторизацию сделали так: установили critic с авторизацией «host» (т.е. на совести Apache), в Apache включили авторизацию через mod_authnz_external + pwauth + authnx_unixgroup.
Всё это наличиствует в пакетах, настройка ограничивается небольшими модификациями вирт. хоста для Apache, который генерит установщик critic:
ServerAdmin your-mail@example.com
ServerName host.name.example.com
#setup unix auth
AddExternalAuth pwauth /usr/sbin/pwauth
SetExternalAuthMethod pwauth pipe
WSGIApplicationGroup %{GLOBAL}
WSGIProcessGroup critic-main
WSGIDaemonProcess critic-main processes=2 \
threads=25 \
home=/usr/share/critic \
python-path=/etc/critic/main:/usr/share/critic \
user=critic \
group=critic
WSGIImportScript /usr/share/critic/wsgistartup.py \
process-group=critic-main \
application-group=%{GLOBAL}
WSGIScriptAlias / /usr/share/critic/wsgi.py
WSGIPassAuthorization Off
<Directory "/usr/share/critic">
AuthType Basic
AuthName critic
AuthBasicProvider external
AuthExternal pwauth
AuthzUnixgroup on
Require valid-user
Require group critic
<[слеш]Directory>
# Possible values include: debug, info, notice, warn, error, crit,
# alert, emerg.
LogLevel warn
ErrorLog /var/log/critic/main/error.log
CustomLog /var/log/critic/main/access.log combined
Alias /static-resource/ "/usr/share/critic/resources/"
<Directory "/usr/share/critic/resources">
Options Indexes MultiViews FollowSymLinks
AllowOverride None
Order allow,deny
Allow from all
ExpiresActive On
ExpiresDefault A2592000
<[слеш]Directory>
<[слеш]VirtualHost>
(если кто-то будет брать за основу не забудьте [слеш] заменить на символ, в исходном виде это ломало тег spoiler).
В итоге в critic попадают тем, кому создали аккаунт на сервере и добавили в группу critic. Этих же прав будет достаточно для push'инга веток на code review.
Судя по тому, что приложение wsgi'ное позже apache мы возможно заменим чем-то более подходящим.
Дальше настроили репозитории. Для этого пользователю critic сделали deploy ключ к нужным нам репозиториям в GitLab (технически для управления git там gitolite).
Репозитории успешно загрузили, отправили тестовый review. Попробовали пописать комментов и issues. Всё в общем и целом не плохо пошло. Возможно нам хотелось бы немного поправить мелочи в интерефейсе и логике. При удачном стечении обстоятельств стоит ожидать от нас Merge Request'ов на GitHub'e.
Но тут и возникает вопрос: как не бились так и не поняли, как по результатам review поправить код и добавить к review новые комиты? Нужно создать новую ветку? Что-то запушить в /r/user/branch или как?
Буду благодарен за помощь. Так как чтение всего встоенного Tuturial и FAQ не дали ответа.
Наверное можно и через HomeBrew или pythonbrew ставить, но пока это не пробовал.
nichol.as/benchmark-of-python-web-servers
Всё замечание в статью.
Удивительно, сколько пользуюсь virtualenv, а узнал об этом только сейчас при выходе venv.
Сейчас внесу коррективы, спасибо.
Я таким образом хотел проиллюстрировать, что это один и тот же объект. Можно это понять и через var_dump, но как-то менее наглядно, плюс мне нужно было значение в виде переменной.
P.S Что-то по воскресеньям не могу излагать мысли в простом виде: )