Представлен (http://blogs.perl.org/users/yuki_kimoto/2016/05/gitprep-20-i...) выпуск платформы совместной разработки GitPrep 2.0 (http://gitprep.yukikimoto.com/), предоставляющей интерфейс очень близкий по оформлению к GitHub, но обеспечивающий только минимально необходимый набор возможностей. GitPrep написан на языке Perl с использованием фреймворка Mojolicious (http://mojolicious.org/). Для хранения данных задействован SQLite. Код распространяется под лицензиями Artistic и GPL (по аналогии с Perl).<center><a href="https://raw.githubusercontent.com/yuki-kimoto/gitprep/master... src="https://www.opennet.me/opennews/pics_base/0_1463290722.png&q... style="border-style: solid; border-color: #e9ead6; border-width: 15px;max-width:100%;" title="" border=0></a></center>
GitPrep может использоваться как самодостаточный продукт с минимальным числом зависимостей (требуется только git и Perl 5.10.1+), обслуживаемый встроенным http-сервером, или запускаться в режиме CGI на любом существующем сервере. Имеется поддержка аутентификации по открытым ключам, SSL и возможность отправки pull- и push-запросов через HTTP. Оценить GitPrep в работе можно на специально подготовленном демонстрационном сайте (http://perlcodesample.sakura.ne.jp//gitprep/gitprep.cgi/kimo...).Из доступных возможностей можно отметить такие разделы как список коммитов, релизы, ветки, графики активности разработчиков, форки репозиториев. В новом выпуске добавлена поддержка pull-запросов, возможность идентификации пользователя по email, средства для привязки к проектам отдельных настроек (кодировка, опции diff), переработан метод работы со временными файлами.
URL: http://blogs.perl.org/users/yuki_kimoto/2016/05/gitprep-20-i...
Новость: http://www.opennet.me/opennews/art.shtml?num=44431
GitLab killer? :)
prep (от preparatory) - "подготовительный, начальный". Видимо, приноравливаются к запиливанию мощной разработки мощного продукта, который будет конкурентноспособным гитхабом, -лабом и тп.
Врешь. A prep is typically one who is a follower of popular and mainstream culture, often identified by their wearing of hipster glasses, baseball jackets or anything associated with Justin Bieber or Zac Efron or any other prep in the public eye. Anyone who isn't a 'goff' really.
Пруф дай, где разработчики ссылаются именно на эту трактовку.
Нет пруфа - читай словарь англорусский, а не сленговый.
У тебя тоже нет пруфа, что они использовали именно официальное значение. Никто кроме разрабов не знает истинного значения названия. А значит мы оба не правы. Вывод - нет пруфа - не пиши чушь про препарэйшен
Вывод - тот аноним использовал слово "Видимо", т.е. это только его предположение.
Второй вывод - ты опять шастаешь по тредам с горящей задницей и агришься на всех.
Вас конечно же смущает, что слово "видимо" вообще в другом предложении находится
Не прикидывайтесь Саней герр Штаалем - я про него не смог сказать фразу "Ya tvoi dom truba S.Atahl.", а про Вас - смог. Вывод - вы выдаёте себя за не того анонима (тот регистрирован).
Вы абсолютно правы. Авторы проекта использовали случаный набор знаков, который совпал с prep - это же очевидно, потому что если придумывать названия проектов намеренно, то все названия уже были бы зарегистрированными торговыми марками и назвать новым названием новый продукт было бы просто невозможно. Пруф, в данном случае, полагаю, излишен, так как логика железна.
Не насилуй мой мозг. Я не говорил что Prep - просто набор букв. Я лишь сказал, что мы не знаем официальное ли значение слова имели ввиду разработчики или же жаргонное...Хотя, это вполне может быть абривиатурой или ДЕЙСТВИТЕЛЬНО набором букв, но я этого не утверждал!
Браво, прекрасная философия. Вижу, Вы большой поклонник Гриши Фридриховича Гегеля?
Его давно убил gogs
Gogs пока глючный.
SQLite как бы намекает... В общем "ынтерпрайз-ready" и прочее горизонтальное масштабирование, да.
ну так там же DBI так что скорее всего хоть MySql хоть PostgreSQL
Скорее, GitBlit, GitBucket и подобных.
Годнота да еще и на перле!
Любишь обмазываться несвежим?
Молодцы конечно, но... на перле? Зачем?
Да какая разница на чём написано? Человек умеет перл, поэтому на перле.
А "зачем?" - ну вопрос интересный конечно.
Большая разница. Чтобы поделием можно было пользоваться код должен быть просматриаемым другими людьми. Мало того, что перл давно сдох и оно в принципе нечитабельное дерьмо, так ещё и все перлисты дебилы ип пишут код максимально мудацки - прямо таки специально стараются чтобы он был write only.
Это вы хаскель не видели :-)
я видел столько, что тебе мб даже столько и не снилось.
Воу! Как же у вас всё-таки...
В общем, я бы на вашем месте не говорил за всю Одессу.
Вообще-то странно, что подобное пишет человек с ником, который является слоганом prefork сервера используемого в Mojolicious(фреймворк, на котором написан сабж)...
Всё нормально, это у тебя проблемы с причинно-следственными связями
Просто вы в Perl не могёте
Открыл код конкретного GitPrep-а - вполне читаемый код, странной фигни мало, словоблудия и отдельных классов на каждый чих - нету, каких-то сильно perл-specific наворотов - тоже. Вполне годно. То, что вы не просматриваете код на перле только потому, что он на перле - говорит многое о ваших качествах. "Пастернака не читал, но осуждаю" (с).
> Мало того, что перл давно сдохО чём нам ясно говорит релиз Perl6 и огромное количество пакетов в CPAN.
> оно в принципе нечитабельное дерьмо
Ага. Вот то ли дело код на Scala или на Java! :)
Последнее время на гитхабе у питон-проектов вижу такое:Requirements
python >= 2.6 or >= 3.3 (tested with version 2.6, 2.7, 3.3, 3.4, 3.5)
Эт тебе не 5.10+))
> Молодцы конечно, но... на перле? Зачем?Хотя бы затем, что прямо в новости написано: из зависимостей лишь git & Perl, т.е. сразу имеем отличную портируемость (хотя бы в пределах *NIX). Если средняя компания не может себе позволить держать сорсы у фик знает кого, она запросто развёртывает свой гитхаб, с реквестом и коммитами, получая забисплатна центральный репозиторий. Та же M$, судя по их C# и Студии, вообще не имела ничего подобного - каждый пилил своё.
Поддерживаю. Достаточно посмотреть на список зависимостей GitLab и попробовать поставить и настроить его не как готовую сборку. Там прелестно, что не смотря на то, что написан он вроде как на Ruby, при установке он тянет с собой Python. Потом ещё его настройка - тот ещё квест.Но большинство нынешних как бы админов и программистов это не волнует, потому что привыкли ставить всё подряд откуда попало. Иллюстрация этой мысли - популярность Docker. Большинству он нужен не как инструмент для самостоятельной подготовки образов для многократного развёртывания, а как замена знаний и навыков - с помощью Docker можно скачать и развернуть готовую систему, не вникая в то, на каких компонентах она построена и как они взаимодействуют. Туда же можно отнести популярность node.js со странным репозиторием, по которому могут расползаться черви и владельцы которого блокируют пакеты по первому же запросу от кого бы то ни было.
Инструмент вроде GitPrep, без лишних зависимостей и легко разворачиваемый на любом Unix (или даже на Windows + cygwin), очень востребован.
> Большинству он нужен не как инструмент для самостоятельной подготовки образов для многократного развёртывания, а как замена знаний и навыков - с помощью Docker можно скачать и развернуть готовую систему, не вникая в то, на каких компонентах она построена и как они взаимодействуют.В теории это вообще-то прекрасно. Т.к. автоматизирует рутинную работу которой заняты большинство админов. Правда этом сами админы становятся не так нужны как раньше :) Т.е. объективно остаются нужны только админы уровня "архитектор системы". Что в целом наверное не так уж и плохо. Мозг лучше применять не для того что бы горделиво разруливать рутину опираясь на "тайные знания", лучше его использовать как-то более творчески, на мой взгляд.
А вешать?! Вешать кто будет?! (С) один белый генерал
Вот когда у вас всё навернётся вспомните о: нужны только админы уровня "архитектор системы"
Хотя конечно "все в облака!" и спрос на админов резко пошёл вниз.
> Вот когда у вас всё навернётсяПри грамотном проектировании и вменяемом автоматизировании системы: "всё" не навернётся, если конечно сразу по всем ЦОДам не будет нанесён ядерный удар.
Ну да, тут можно сказать "всё красиво на бумаге", но я ведь не даром начал свой предыдущий пост с фразы "в теории" :) На практике всё обычно выходит несколько иначе. Впрочем, раз бизнес терпит, значит оно допустимо.> Хотя конечно "все в облака!" и спрос на админов резко пошёл вниз.
И мне кажется что это только начало.
PS Я сам админ если что, но считаю это не повод заниматься луддизмом.
> При грамотном проектировании и вменяемом автоматизировании системы: "всё" не навернётся,
> если конечно сразу по всем ЦОДам не будет нанесён ядерный удар.Да хде ж столько проекторов-то набрать? Тем более - устойчивых к ядерному удару?
> Да хде ж столько проекторов-то набрать?С нынешней системой образования - боюсь что нигде.
А ядерный удар и защита от него - это по части немного других проектёров.
Ну вот тогда будет нанята внешняя команда, которая на таких бедах специализируется и в состоянии быстро с ними разобраться - просто потому, что для них это рядовая задача, для которой есть все спецы, технологии и инструменты. Смысл на случай "всё навернулось" держать людей, которые, к тому же, не обладают соответствующей квалификацией по определению.В общем, ровно та же специализация и уход от ручного труда, что и везде.
Вас эффективный менеджер покусал ?
Обратитесь в поликлинику.
А что вам собственно не нравится? Мысль-то правильная. Ведь вы же наверное позвоните в диспетчерскую обслуживающую дом, если у вас трубу прорвёт канализационную, а не броситесь сами устранять проблему с гордым криком "Меня эффективный менеджер не кусал, я сам всё могу!"Другое дело - что бы можно было так работать, нужно что бы была всеобщая стандартизация и бригаде быстрого реагирования не нужно было себе мозг взрывать по неделе, что бы хоть что-нибудь понять. А вот с этим у бизнесов туго, так как для многих понесёт убытки. Потому вместо нормальной стандартизации (какой был например советский ГОСТ), мы имеем известную картинку про 14 несовместимых стандартов. Но конечно бизнес таки пытается раком-боком-ползком сделать это, всякие сустемг, докер-покер-рокеты и прочая новомодная приблуда тому порукой.
Если задачи уровня простой сайт на php, то конечно внешняя бригада подойдет. Но вот при хоть сколько-нибудь серьезных задачах нужно минимум пару недель только на то, чтобы нового специалиста ввести в команду админов. И никакие внешние профессионалы ничего не разрулят, хотя бы потому, что они не знают как оно должно работать. В идеале конечно вся система полностью грамотно и подробно задокументирована в едином месте, но в реальности я такого ни разу не видел.
Ну и уход в облака привел разве что к тому, что вместо "sysadmin" стали в вакансиях писать "devops".
Мне кажется вы невнимательно прочитали мой предыдущий пост. Ведь там именно про это и написано - без стандартизации и жёсткого её соблюдения ничего не выйдет, потому я и упомянул советский ГОСТ, который имел силу закона. Бизнес пытается это сделать, но делает как обычно и бывает в ситуации с тыщами конкурирующих "эффективных собственников" - долго, криво, косо, с кучей рудиментов. Но всё-таки делает.Вы пытаетесь спорить со мной в том в чём я с вами согласен.
Установка "до первой стрижки все головы разные" в реальности не работает, ибо сколь-либо серьезные задачи они сволочи разные и никакая стандартизация с этим ничего не сделает.
> ибо сколь-либо серьезные задачи они сволочи разные и никакая стандартизация с этим ничего не сделает.Я вам могу только посочувствовать с таким пониманием предмета. Однако практика показывает что во всех остальных сферах деятельности человека, которые не столь молоды, задачи удаётся стандартизировать и тем самым устранить содержание носителей тайных знаний. IT идёт ровно в ту же сторону, вопреки мнению луддитов об этом.
Только там, где задач не особо много. Но даже в этом случае решаются только частные случаи. Вот например самая древняя задача человека - добыть пожрать. Раскажите мне о том, как ее решают в общем виде ваши стандарты.
В общем виде это давно решается крупными торговыми сетями. У них есть строго определённая номенклатура товаров, определённые протоколы взаимодействий с поставщиками, то же самое в отношении покупателя.
Или это плохой пример и тут тоже "мало задач"? :)
Вот Вы знаете - SAPисты действительно считают, что после первой "стрижки" голова станет "одинаковой". И у них в какой-то мере это получается!!!
Но стригут они, конечно, знаатно =)
> советский ГОСТ, который имел силу закона.Сказочники - такие сказочники...
Коли в ход пошли голословные "фи", то я так понимаю что возражений по сути не будет.
Вы либо невнимательно читали, либо просто не имеете нужного опыта. Стандартизировать задачу типа простой сайт на php вполне можно. Но разных задач миллионы и каждый день тысячами появляются новые. И как вы собираетесь все это стандартизовать?
Если непонятно, то вот аналогия. Набор консольных утилит в линуксе более менее стандартизирован, но для решения задач администрирования недостаточно запустить одиночный ls или grep, а нужно их объединение в пайпы, а то и в скрипты. И вот получившиеся однострочники или скрипты стандартизовать на все случаи жизни уже не получится, их слишком много.
> Но разных задач миллионы и каждый день тысячами появляются новые. И как вы собираетесь все это стандартизовать?Сотнями и тысячами они получаются очень часто как раз потому что каждый строит свой клёвый велосипед на карданном валу с муфтой сцепления и квадратными колёсами. А потом приходится к каждому такому велу городить ещё сотню "совершенно уникальных, инновационных решений". И в итоге всё это преподносится как убойный аргумент однозначно доказывающий невозможность стандартизации велосипедов.
Однако, как верно заметил другой оратор - в промышленности это вполне успешно решено. Или вы страдаете синдромом богоизбранности IT'шной расы?> И вот получившиеся однострочники или скрипты стандартизовать на все случаи жизни уже не получится, их слишком много.
"Слишком много", конечно серьёзное число и весомый технический аргумент. А можно чуть-чуть конкретней?
Если подойти серьёзно, то большинство задач бьётся по достаточно крупным группам имеющим достаточно общие решения. Вот эти самые контейнеризации подобным как раз и заняты, в частности.
Опыта у меня конечно не 20 лет работы, но далеко не первый год работы с парками в сотни/тысячи машин с разнородными сервисами. Я чуть-чуть понимаю о чём говорю.
Все ваши возражения - не больше чем современный луддизм, впрочем мне кажется спорить в данном случае - только время терять. История и прогресс всё расставят по своим местам, наверное в ближайшие пару десятилетий. Имеем шансы дожить и посмотреть.
1) Наличие практически только "админа-архитектора", стандартный софт, занимающийся развертыванеим, управлением и мониторингом и развёртывание в облаках фактически гарантируют, что всё будет более-менее понятно.2) Практики стандартизации нарабатываются. Ровно как в программмировании сейчас можно прийти в любой нормальный проект для андроида/iOS и за неделю начать там что-то осмысленное писать. Потому что реально распространённых технологий мало, а современный подходы (хоть тот же скрам с юнит-тестированием) гарантируют, что задачи вменяемого размера и хорошо изолированы друг от друга.
3) пару недель чтобы въехать нужно тем, кому приходится въезжать в новую систему раз в год в лучшем случае. Если это становится специализацией - всё будет быстрее. Это ровно такой же специфический навык/технология, как и всё остальное, и ему можно научиться.
4) Никто не говорит о том, что "аварийщики" поднимут всё до идеала - достаточно хоть как-то рабочего состояния, когда от самый "архитектор" сможет в приемлемые сроки решить проблему.
В общем, сравни это, допустим, с сервисами по восстановлению информации на носителях - в теории обычный админ сбитой ФС может инфу вытянуть. Но у специалистов это выйдет на порядки быстрее, так как есть опыт и инструменты.
Сравнение серверных систем с г.внокодингом для телефончиков это прекрасно.
Больше вопросов не имею.
А то ж в "серверных системах" всё в шоколаде.
И не надо на "школоту-хипстоту" списывать. Посмотрите код от бородатого ISC, хоть в BIND хоть в DHCP. Куда уж серверней и олдскульней...
Разница в основном в том, что в телефончиках было кому (гуглу/эпплу) задать правила игры, да конкуренция побольше. В серверных системах просто больше времени уйдёт, чтобы эти правила выросли. Так же, как произошло в любых других отраслях промышленности. в том же машиностроении нет особых проблем с формализацией и передачей знаний, а сложность там и повыше часто.
Ох уж эти теоретики. Замени шеф-повара в ресторане или технолога на небольшом производстве и расскажи уходящим клиентам про стандарты.
А вы правда думаете что технолог на производстве, даже небольшом, работает без соблюдения стандартов? Можете привести примеры?
Что до ресторанов - то мягко говоря пример неудачный. Они обслуживают ничтожную часть населения, а IT обслуживает уже почти что большинство. Потому и решения в целом более общие.
Вот в ресторане пусть шеф-повар и сидит, кто ж против. А в массовом общественном питании он нужен чтобы принять полтора решения - а дальше дело за мальчиками-девочками клонами, тупо соблюдающими технологическую карту. И мальчиками/девочками чуть постарше, по другой технологической катри их проверяющими.То же самое и с небольшим производством - да сколько угодно, пусть выполняют редкие экзотические заказы. А на большом (где 90% клмиентов и денег) - стандартизация, ISO и люди-винтики. Кстати, небольшие производства часто остаются небольшими именно потому, что не в состоянии всё это внедрить.
> Вот в ресторане пусть шеф-повар и сидит, кто ж против. А в
> массовом общественном питании он нужен чтобы принять полтора решения - а
> дальше дело за мальчиками-девочками клонами, тупо соблюдающими технологическую карту.Рестораны - это и есть "массовое общественное питание".
Вы, по-моему, никогда не видели крупных собственных разработок. Это которые работают на большом количестве серверов, имеют сложные взаимосвязи и при этом, никому за пределами компании не известными.Типичная ситуация - что-то тормозит/сбрасывает сеансы пользователей/сыпет ошибками. Бывает нужно размотать хорошо запутанный клубок, чтобы найти звено, работающее необычно и потому вызывающее спорадические проблемы.
Стандартизация тут ничего не решает, потому что система не стандартная, эксплуатируется только у одного пользователя. Это значит - нет специалистов за пределами компании, которые могут быстро починить эту систему. Это значит - нет известных проблем и способов их лечения, потому что каждая проблема, с которой сталкивается владелец системы, не возникала больше ни у кого.
Всё. Теперь можете идти к своим стандартным клиентам и ставить им стандартную винду-десяточку. Там всё стандартно, все проблемы известны, все решения простые. А если не хватает мозгов починить - можно просто переустановить за пару часов.
В точку. Добавлю к этому, что в некоторых случаях эта нестандартная система еще и непрерывно меняется, причем зачастую быстрее, чем изменения успевают задокументировать.
Стандартное решение, понятно, применимо к большинству ситуаций, но не ко всем. Неужели это нужно специально объяснять?
Не надо понимать стандартизацию как "стандартное решение всех возможных проблем на всех уникальных велосипедах".> Бывает нужно размотать хорошо запутанный клубок, чтобы найти звено,
И:
> Стандартизация тут ничего не решаетВот именно это она в певрую очередь и дожна решать - не давать создавать такие "хорошо запутанные клубки", которые являются плодом "вольного творчества" многопоколенных династий админов.
Но повторюсь ещё раз - спорить достаточно бесполезно. Ближайшие годы нас рассудят независимо от нашего мнения о предмете обсуждения.
Ах, да, в догонку:> Вы, по-моему, никогда не видели крупных собственных разработок.
Это только по вашему, т.к. большая часть моего опыта работы связана именно с подобным балагано. Я скорее "никогда не видел простых сайтов на PHP", верней не занимался их профессиональным обслуживанием, как это делают например крупные хостеры.
Видел. И видел, как этот in-house выкидывали из-за дороговизны поддержки. Заменяя решениями, где более-менее отделена стандартная инфрастуктура от специфических сервисов, что уменьшало количество "тайных знаний" и мороки в разы."Система не стандартная, эксплуатируется только у одного пользователя" автоматом означает, что поддержка дорога. И ещё - что либо она уже сейчас проигрывает стандратным системам по эксплуатационным характеристикам, либо вскоре проиграет. Потому что если она в одном экземпляре - значит, это не основная деятельность предприятия. И на неё неизбежно будет тратиться меньше ресурсов, чем на то, что пишется под многих клиентов либо многими совместно. Исключение - гиганты вроде Гугла, конечно, но у тех с документированием/формализацией/автоматизацией всё в порядке, насколько я понимаю.
А насчёт десяточки - я в этом треде очень старался обходиться без оскорблений (чай, не с клоуном беседую), ожидаю и от вас того же. Хотя если абстрагироваться от десяточки - вариант неплохой и сто раз обкатанный - все данные храним где-то с нужными предосторожностями, а рабочую среду на любой чих сносим и раскатываем с нуля, потому что мы сделали так, что для нас это быстро и дёшево. И только если не помогает - тратим больше ресурсов на исследования "что проиошло и как лечить".
А это и есть об эффективности, без всякой иронии.Люди, которые сталкиваются с какой-то ситуацией каждый день, подготовлены к ней заведомо лучше, чем те, кто на подобное нарывается раз за многие годы. А исключение человеческого фактора - это вообще азы, всё IT об этом.
Это только для дворников работает. В IT все гораздо разнообразнее.
Почему-то мне кажется что вы как раз "дворник от IT" который не хочет развиваться и боится за своё место...
Было ещё разнообразнее. А становится всё более унифицированно по мере взросления отрасли. А так - и сейчас можно, скажем, одежду в ателье пошить, но потому не удивляйтесь, если в химчистке не будут знать, что с ней делать. Ничего ужасного, но разнообразие имеет свою цену, и большинство её платить, разумеется, не хочет, а значит - неизбежно всё сводится к стандартным решениям.
>В теории это вообще-то прекрасно. Т.к. автоматизирует рутинную работу которой заняты большинство админов. Правда этом сами админы становятся не так нужны как раньше :)Да-да. Из того, что есть инструмент автоматизации делается далеко идущий вывод о том, что админы будут не нужны. Эти образы Docker тоже кто-то делает, вообще-то. Я посмотрел несколько рандомных docker-файлов. Там не всё так радужно, как вы думаете. К тому же, админы нужны не только когда нужно развернуть систему, а и для того, чтобы потом её сопровождать. Любители докера как правило развёрнутые системы потом не обновляют даже. Это уже не говоря о решении проблем с производительностью, для чего нужно знать, как всё в системе взаимосвязано. А этого в docker-файле уже нет.
Подобных инструментов предостаточно - Puppets, Chef, Ansible. Docker - это инструмент довольно специфический.
>Т.е. объективно остаются нужны только админы уровня "архитектор системы". Что в целом наверное не так уж и плохо.
Да-да. Я уже вижу этих админов уровня "архитектор систем". Когда новичку попадается мощный инструмент, он просто им больше сломать может, чем если бы у него не было этого инструмента. А суть в том, что раз останутся нужны только админы уровня "архитекторы систем", это значит что каждый будет мнить себя архитектором, хотя пороха не нюхал.
>Мозг лучше применять не для того что бы горделиво разруливать рутину опираясь на "тайные знания", лучше его использовать как-то более творчески, на мой взгляд.
В этом я согласен. Но "тайные знания", как вы выражаетесь, в чужую голову не вложишь, так же как не вложишь их в docker-файл. Ждите появления большого количества как бы админов, которые ищут готовые docker-файлы, а когда не находят, будут заявлять начальству об отсутствии технической возможности. Когда развёрнутую ими систему взломают или она начнёт вдруг нещадно тормозить, они будут говорить о том, что docker-файл кривой.
Да что там, уже до появления docker'а существовал и существует целый класс админов, который пользуется "сборками". Я одного такого знаю, он за Asterisk вроде как отвечает. Но беда в том, что на серверах действительно установлена какая-то "сборка" с веб-интерфейсом, написанным какой-то местной конторой и проданной за деньги, на серверах не установлены обновления, да и сам релиз операционки уже не поддерживается. Он это на каком-то интуитивном уровне уже понимает и ищет новую "сборку". Казалось бы, проблем, настроить на отдельном сервере или виртуалке свежую операционку, установить Asterisk, да настроить безо всяких морд, оттестировать всё это и в несколько этапов обновить основные серверы, снеся или адаптировав самописный интерфейс? А вот нет же. А вы говорите "тайные знания". Многие же даже элементарных вещей зачастую не знают, не говоря уже об интуитивном представлении о плохом и хорошем, сформированным многолетней практикой.
О да, я следил за тем, как его во фряшные порты добавляли. Это просто нереальная боль с таким количесвтом зависимостей
Молодцы потому-что нa перле.
А где закладка issue?
це?: https://github.com/yuki-kimoto/gitprep/issues
Из вариантов за которыми ещё имеет смысл следить (или пробовать):
https://github.com/gitbucket/gitbucketНу и, конечно, GitLab. Но про него и так все в курсе.
Посмотрите https://gogs.io
О, это же годнота! Спасибо, идёт однозначно в "закладки".Причём, мне кажется, идеальный юз-кэйс для Го: не обязателен энтерпрайз JVM, не обязателен перформанс C/Rust, не нужен мозговзрыв на уровне типов от некоторых других языков. А нужно спокойненько фигачить RFC-шки, доки и тесты, а попутно звать новых контрибьюторов. Хорошая поддержка асинхронки и скромный жор памяти только к месту.
Думаю, взлетит.
А есть где-нить свежая дока по Mojolicious на русском? Сайт perl5doc.ru видел, но там по-моему все заброшено и поросло мхом, учитывая, что сейчас актуальная версия Mojolicious - 6.62.Вообще, судя по результатам гугла, в рунете пик популярности Mojolicious пришелся на 2010-2012 годы, а потом похоже все на него дружно забили, т. к в рунете я не нашел ни одной статьи или обзора по 6-ой версии.
В 2010-2012 годах (3я ветка и далее) он стал ЮЗАБЕЛЬНЫМ, и документации не было вообще нихрена.Сейчас POD'ы в модулях постепенно дописали, и этих статей как раз хватает чтоб понять принципы работы. А детали уточняются как раз из актуальной документации.
А ежели есть redmine с gitolite, эта штука ведь получается не особо нужна?
А ежели есть спинной мозг, то и головной не нужен.
пояснить не судьба? надо чванливо вякнуть и уйти в закат?
Вероятно, анонимус намекнул на то, что redmine и gitolite реализуют несколько более продвинутое окружение, чем сабж, и ничего общего с ним не имеют. Хотите развернуть свой локальный github для каких-нибудь студенческих проектов на 10 юзеров на слабом сервере -- юзайте сабж. Хотите что-то вроде gitlab, bitbucket или beanstalkapp -- оригиналы к вашим услугам.
От себя добавлю, что не понимаю причём здесь вообще redmine? Это же тасктрекер. Тасктрекеры тут вообще не причём кмк.
>От себя добавлю, что не понимаю причём здесь вообще redmine? Это же тасктрекер. Тасктрекеры тут вообще не причём кмк.Очень причем. Олдскул это тасктрекеры типа редмайна. ТО, что сделано в GitHub/GitPrep и т.п. ОЧЕНЬ сложно назвать тасктрекером. Так, "заметки" для ТП (да-да, именно их), которым не нужно знать про приоритеты, на кого задача назначена, простановки дедлайнов и т.п. Этим ТП нужно только быстро написать бла-бла и все. Ну, в реале вместо ТП выступают школо-пограммисты, а им как раз это и нужно -- лишь бы закомитить и забыть.
У пользователей git полно вариантов: монструозный GitLab, минималистичный и жрущий всего 20 мегабайт памяти gogs, сабж, ещё много чего... А для hg альтернативы Kallithea просто нет! В gogs планируется добавить поддержку ртути, но, как сказал сам автор, "by 2099 lol". Печально всё это.
Есть еще относительно легкий (java) SCM-manager
SVN, GIT, HG, bazzaar
Тоже относительно простой в настройке
Хорошая годная новость!
