- 1
Привет, я вот сайт пишу, каталог, на заказ, ну короче, считаю себя говнокодером. Хочу попросить более опытных что ль, оценить. Сказать так это или нет. Ссылочку на гитхаб чуть позже присобачу.-
PHP / Говнокод #17874
+145
Запостил:
proweber1,
27 Марта 2015
Follow us!
Пароль для скачивания qazWSXedcRFV123, решил без гитхаба обойтись
> http://rghost.ru/
гитхаб - это здесь ---> http://github.com/
Нахуя?
>>Пароль
>Нахуя?
Боится, что боты-сканеры ргоста запалят его исходники.
Надеюсь без git не обошелся?
Или вообще если хранилище на локалхосте.
Настраивать проще (git init и репа готова), не засирает проект папками .svn, с ветками удобней работать.
этого давно уже нет, несколько лет точно.
http://habrahabr.ru/post/70330/
«1) Он не может просто выкачать часть файлов (каталог из репозитория, а не весь репозиторий). Когда объемы репозиториев измеряются в гигабайтах, то это критично. Я иногда на работе по часу тупо выкачиваю код.
2) Система веток похожа на токийское метро, как в ней вообще разобраться?
3) Rebase - одна из самых частых операций и она по большому счету приводит К ПРАВКЕ ИСТОРИИ. Отличный способ всех запутать. Megre вместо переливания кода из ветки в ветку вообще делает единую.
4) Нет аутентификации. Буду коммитить тоже от имени Линуса Торвальдса. Если в моем коде что-то не так пусть он разбирается.
5) "Кроссплатформенность". GIT не знает что такое аттрибуты файлов и как файл может быть блокирован. В итоге пораждается куча багов.
Да и просто раздражает это дебильное "у меня точка спереди, меня никто не видит". Давайте еще дату изменения что ли в имени хранить? И правда доступа? Да вообще весь файл пусть в имени хранится, хули.
6) Все файлы в каталоге по умолчанию считаются под контролем. В итоге заебешься добавлять бинарники, конфиги и всякий хлам в .gitignore.
7) Децентрализация. Попали лишние тэги на сервер - пизда, их теперь все кому не лень будут пушить до скончания веков. Вообще что бы то ни было лишнее удалить почти невозможно.
8) Ветки хранятся в одном каталоге. Если в ветках добавлялись и или удалялись каталоги, то свич + пуш запушит лишний проект. Идеальный способ разнести какую-то херню из одной ветки во все.
9) Мне сейчас нужно чтобы кусок кода у меня лежал в папке с проектами, а кусок - в вебруте для IIS. Разница:
- TFS VSC похуй где файлы на диске. В решении => ок, всё уже работает.
- В GIT нет решений этой проблемы. Не работает и никогда не будет.»
по умолчанию pull не обновляет список серверных веток и нужно писать еще и prune.
Итого: даже удаление ветки зачастую почти невозможная операция, ибо если другой разработчик её уже видел, то после удаления её с сервера у него останется и её локальная копия, и фантом серверной ветки. То что он может комитить в локальную по большому счету никого не ебет, но при пуше автоматически, без всяких предупреждений и даже сообщений после будет заново создана серверная ветка и в неё даже затащится вся история что там была.
Просто ад какой-то. Не испытывать проблем с гитом можно только в двух случаях:
- ты единственный разработчик, который пользуется конкретным репозиторием
- ты такой же ебнутый как авторы гита»
> Все файлы в каталоге по умолчанию считаются под контролем.
Это же пипец! Апплодисменты авторам за фэйл.
> Это же пипец! Апплодисменты авторам за фэйл.
Вот в этом пункте как раз брехня. Гит добавляет под контроль только то, что ты скажешь ему добавлять. Если ты сказал ему "добавь всю папку" и не указал, какие маски надо исключать, то что он должен добавить? :)
P.S. Out of source билд рулит. Бесит, когда система сборки засирает папку с исходниками объектниками, бинарниками, конфигами и прочим говном.
Вроде в 2.0 сделали, чтобы git push без параметров пушил только одну ветку, но я всё равно всегда писал куда пушить и всегда буду.
Щелк правой кнопкой - создать хранилище,куда проще?
svn уже давно создает .svn только в корне.
Чтобы не копировать проект на 100500 раз ради экспериментов. Чтобы запиливать новые фичи не ломая основную ветку.
P.S. Я тоже после svn думал: "да нахуй мне эти ветки на локалхосте?!".
А нормальная нумерация версий -однозначный плюс.
Гит тоже умеет нумеровать. Если историю в мастере не переписывать и теги с места на место не перевешивать - нумерация даже будет стабильной. Но в svn номера ревизий однозначней и проще, да.
> зачем для экспериментов создавать ветки
Как минимум - чтобы отложить на пару дней пиление этой самой ветки и пофиксить что-то в master'е (основной ветке).
32 битным хексом?
>Как минимум - чтобы отложить на пару дней пиление этой самой ветки и пофиксить что-то в master'е (основной ветке).
Хз, как то потребности в этом еще не было. В таком случае может бы тупо новый реп создал.
Че-то типа 1.6.3-32
> В таком случае может бы тупо новый реп создал.
Ну а я про че писал? :) "Чтобы не копировать проект на 100500 раз ради экспериментов". Да и не всегда знаешь, когда надо будет скопировать. А ветки в гите вообще нахаляву делаются. Тут бесполезно объяснять, надо попробовать и подсесть ;)
Кстати, а что будет при коллизии хеша? Я так понимаю, это - уникальный идентификатор, а история может быть в любое время переписана?
1.0.5 - имя последнего тега на пути от начального коммита до текущего
35 - количество коммитов после этого тега
d7d219a - кусок от хеша коммита, чтобы можно было быстро его найти
на гитхабе я бы мог даже не скачивая посмотреть, а теперь мне виртуалку снова запускать
P.S. Вон какой-то вирус же был, который достаточно было увидеть в каталоге, и винда радостно исполняла нужный ему код...
от деархивации ничего не будет. но в целом я распиздяй и скормить произвольную хуету интепретатору для меня обычно не проблема. после пары rm -rf на сервере я стараюсь всегда минимизирвоать возможные последствия какой-нибудь гранитной стеной.
линукс сам по себе ничем не защищен.
http://www.effectivelanguagelearning.com/language-guide/language-difficulty
Да, там на англиЦком
Использование phing: вообще плюс, но я этой xml-дрочилкой никогда не буду пользоваться
Использование коханы: минус, кохана это пиздец
> @license Open Source
Используй конкретную, все обычно ставят MIT и всё.
> * Изменяем before, для того, чтобы проверить, прилетел
> * хуев AJAX запрос, или пизда членистоногая какая-нибудь,
> * а нам таких нахуй не надо! Хакеры ёбанные!
лол.
мне уже начинает нравиться
> * ajax запросов, а может где и еще, но жопой чую что он нужен
слушай, вообще тут твое творчество вроде было недавно
> * инЕцЕализацЫя стандартных перемеНых, вот кАроче.
> * В этом методе у нас происходит инициализация стандартных
> * переменных для шаблона, дабы избежать вывода ошибок
> * во время работы сайта, в продакшен версии, ну конечно
> * мы еще переведем сайт в продакшен решим, вырубим вывод
бля, если б я был HR, у тебя был бы солидный приоритет при устройстве!
* сранных ошибок, но все же.
Модули сами себя не вынесут
Сложно понять, что там диктует кохана, а что по твоей воле сделано, но
* @access protected
* @param null $file
* @param array $params
* @return View
*/
protected function render_content($file = NULL, array $params = array())
Зачем ты пишешь access protected, если он и так стоит ниже? Зачем @param null, если очевидно, что туда передается строка, а null - это просто "компонент, выбери сам?". Определять вот эти значения по умолчанию и уровень доступа - задача парсилки, которая это использует. Ну и @param array - с таким объявлением аргумента разве что кретин не поймет, что это массив. Другое дело - что в нем должно лежать? Сам контекст рендеринга? Набор конфигурации для рендеринга, в которой контекст должен лежать строго под определенным ключом?
Ну и установка зависимостей через phing - это не дело, оно все должно жить в composer.json. Прямо в нем же объявляешь новые репы, и все оно само скачивается.
Что до автоопределния null, а не string - ну епт, шторм-то не знает, что у тебя на уме, а язык даже чересчур динамический.