Бинари (классические бинари, не текстовый xml с другим расширением) плохо пакуются. Из собственной практики — у нас когда-то дизайнеры захотели в гите держать историю своей работы над проектами. PSD, PNG, ещё куча форматов. Файлы, соответственно, здоровенные. Через месяц все задолбались таскать туда-сюда по сети десятки гигабайт данных (копия всего огромного файла на коммит при каждом малейшем изменении) и удалили гит. Теперь счастливы.
Плюс ещё у автора есть «автоудаление резервных файлов старше 10 дней» — в гите такое не провернёшь автоматически или в два клика, до того же ребейза ещё дорасти надо (а скриптом даже я боюсь ребейз делать, чревато). Git чертовски хорош, и я каждый день, пользуясь им, благодарю Линуса за такую клёвую штуку, но… Везде есть своё но =)
Так, хорошо, три клика на коммит, а с остальными проблемами что делать? С забывчивостью и с коллегами, которые по сети файлики изменяют? У автора — автоматически всё и все счастливы.
Не понял, почему git эффективнее проводника при работе с бинарями? Считаем: в гите — новая версия файла + накладные расходы (информация о коммите, история и прочее), в проводнике — просто новая версия файла. Не намного, но хуже получается. Вот с текстовыми файлами (исходные коды, вот это вот всё) хорошо — там только diff хранится (для этого git и делался, собственно), а с бинарями всё не так хорошо, увы и ах. Я в курсе за git attributes, если что.
Ок, ок, а сколько кликов на создание версии? Напомню, у автора она делается автоматически. А если забудешь закоммитить? А если коллега отредактировал и не закоммитил?
Или предлагается писать скрипт, который будет коммитить файлы автоматически? Тогда это уже не пять кликов.
Я уже не говорю про то, что гит «by design» не предназначен для версионирования бинарей — для этого есть другие, «более лучшие» инструменты. Честное слово, незачем пихать везде и всегда один и тот же инструмент, нужно отталкиваться от задачи. Git — не панацея и не «серебряная пуля», у него куча недостатков, и в то же время огромное количество достоинств, поэтому он так популярен. Но применять его нужно с умом и в нужном месте =)
Автор — молодец, быстро и эффективно решил вопрос доступными средствами. Хотя соответствие его ника содержанию статьи меня, конечно, слегка смущают.
Я хорошо знаком с git и вижу, что описанное решение при указанных начальных условиях лучше, проще и эффективнее.
Незачем стрелять из пушки по воробьям, каждому инструменту — своё время и место.
Возвращается «404 Not found» — но ресурс (коллекция, элемент) ведь есть и это вводит в заблуждение.
По логике вещей должен вернуться, например, «405 Method Not Allowed» — ресурс (коллекция, элемент) есть, но метод к нему не применим — не реализован или запрещён.
Пытался рассказать своими словами, получилось не очень, поэтому пошёл и нашёл неплохое объяснение:
Внутренние типы в Python, будучи написанными на C, представляют собой огромную структуру с большим количеством ссылок на функции, реализующие базовые операции: работу с памятью для этих объектов, получение и установку аттрибутов, сравнение и т.д. Многие (но не все) из этих методов пробрасываются на уровень Python (например, метод __repr__), однако сишный код вызывает эти внутренние функции напрямую через указатели (например, функция type->tp_repr), и такие вызовы не попадают на уровень Python и не обрабатываются механизмом поиска методов Python.
Так вот, CPython, регистрируя новый внутренний тип, автоматически создаёт словарь, в который складывает названия для всех специальных («магических») методов и слоты с соответствующими функциями в сишном коде. Поэтому мы, собственно, и можем вызывать эти функции (get, __init__ и другие прочие) для встроенных типов. Ключи этого словаря не могут указывать напрямую на указатели на сишные функции, вместо этого они указывают на специальные объекты (слоты), которые, собственно, и реализуют всю работу по вызову соответствующих сишных функций из Python.
Say hello to Google, которые, насколько я знаю, раньше частенько применяли два пробела в качестве отступов и CamelCase в названиях функций (не смог найти подтверждения в их сегодняшнем code style guide).
Но в целом да, я согласен с мыслью, что PEP8 должен стать библией для начинающих программистов, и за несоблюдение PEP8 их нужно безжалостно гонять по кругу ссаными тряпками до тех пор, пока не научаться писать красивый код.
Без этой самой «моды» никуда не денешься со стадии «ранние адепты». К тому же на nodejs мало кто переходил с других языков, в основном client-side разработчики ломанулись писать серверный код (но не будем о грустном), и в этом заключается секрет популярности ноды.
Бинари (классические бинари, не текстовый xml с другим расширением) плохо пакуются. Из собственной практики — у нас когда-то дизайнеры захотели в гите держать историю своей работы над проектами. PSD, PNG, ещё куча форматов. Файлы, соответственно, здоровенные. Через месяц все задолбались таскать туда-сюда по сети десятки гигабайт данных (копия всего огромного файла на коммит при каждом малейшем изменении) и удалили гит. Теперь счастливы.
Плюс ещё у автора есть «автоудаление резервных файлов старше 10 дней» — в гите такое не провернёшь автоматически или в два клика, до того же ребейза ещё дорасти надо (а скриптом даже я боюсь ребейз делать, чревато). Git чертовски хорош, и я каждый день, пользуясь им, благодарю Линуса за такую клёвую штуку, но… Везде есть своё но =)
Не понял, почему git эффективнее проводника при работе с бинарями? Считаем: в гите — новая версия файла + накладные расходы (информация о коммите, история и прочее), в проводнике — просто новая версия файла. Не намного, но хуже получается. Вот с текстовыми файлами (исходные коды, вот это вот всё) хорошо — там только diff хранится (для этого git и делался, собственно), а с бинарями всё не так хорошо, увы и ах. Я в курсе за git attributes, если что.
Или предлагается писать скрипт, который будет коммитить файлы автоматически? Тогда это уже не пять кликов.
Я уже не говорю про то, что гит «by design» не предназначен для версионирования бинарей — для этого есть другие, «более лучшие» инструменты. Честное слово, незачем пихать везде и всегда один и тот же инструмент, нужно отталкиваться от задачи. Git — не панацея и не «серебряная пуля», у него куча недостатков, и в то же время огромное количество достоинств, поэтому он так популярен. Но применять его нужно с умом и в нужном месте =)
Автор — молодец, быстро и эффективно решил вопрос доступными средствами. Хотя соответствие его ника содержанию статьи меня, конечно, слегка смущают.
Незачем стрелять из пушки по воробьям, каждому инструменту — своё время и место.
Возвращается «404 Not found» — но ресурс (коллекция, элемент) ведь есть и это вводит в заблуждение.
По логике вещей должен вернуться, например, «405 Method Not Allowed» — ресурс (коллекция, элемент) есть, но метод к нему не применим — не реализован или запрещён.
Why? Because fuck you, that's why.
Так-то, по большому счёту, PEP8 всё, что угодно разрешает:
Это ведь просто набор рекомендаций, не более того.
Во-первых, исходники Python, конечно же (ссылка выше).
Во-вторых, статьи из различных источников, навскидку вспомнил блог Laurent Luce (посты старые, но интересные):
— Python threads synchronization: Locks, RLocks, Semaphores, Conditions, Events and Queues
— Python list implementation
— Python string objects implementation
— Python dictionary implementation
Но их много разных, можно просто поискать в интернете.
В-третьих, различные доклады с конференций (PyCon, EuroPython) тоже интересно посмотреть-послушать, но выборочно.
Say hello to Twisted.
Say hello to Google, которые, насколько я знаю, раньше частенько применяли два пробела в качестве отступов и CamelCase в названиях функций (не смог найти подтверждения в их сегодняшнем code style guide).
Но в целом да, я согласен с мыслью, что PEP8 должен стать библией для начинающих программистов, и за несоблюдение PEP8 их нужно безжалостно гонять по кругу ссаными тряпками до тех пор, пока не научаться писать красивый код.