Python-сообщество

Согласен с andreytata

Лично я считаю:
1) Поиск альтернативных ФС иногда полезен
2) Если есть нормальное и подходящие решение стороннего производителя :) почему бы его и не использовать , а на питоне только связки сделать :)

Думаю вы сами должны решить, что именно важнее написать самому или довериться кому то!

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

Покажи :)

ZZZ, мне тоже было бы интересно посмотреть.

sypper-pit
Лично я считаю:
Думаю вы сами должны решить, что именно важнее написать самому или довериться кому то!

При выборе важно рассчитать силы - большая часть работы не написать - а отлаживать, тестировать и сопровождать.
Выбор готового решения, это способ делегировать всю работу по отладке и сопровождению этой части программы, с себя , на коллектив разработчиков решения.
Перед тем как доверится “готовому”
1. надо почитать их сыръё ( не круче ли они чем я всемогущий :) );
2. посчитать количество проектов использовавших это решение ( кто ещё посчитал что это решение надёжно );
3. посчитать общее количество пользователей этих проектов - потенциальных тестеров.
4. почитать сырцы проектов использовавших это решение ( как именно разработчики этому решению доверялись )

Если после всего этого сомнения всё-таки остались, то прикинуть трудоёмкость сокрытия API этого решения за самодельным абстрактным интерфейсом.
Т.е. стоимость работ по подготовке к грядущему отказу от данного решения в пользу какого-либо другого - втом числе самодельного, при этом “абстрагирование” может оказаться на порядок более трудоёмким чем написание с нуля. В процессе исполнения вышеприведенного пункта 4 - можно увидеть насколько разработчики доверяли этому решению и если использовали его через абстрактный интерфейс, а не рассыпали вызовы API по всем сырцам () - то попробывать перетащить этот интерфейс к себе.

ЗЫ: Хотя описываемый мной подход - обязателен при планировании проектов для коллективных разработок ( ответственность давит ), Но тем не менее к своему собственному времени жизни то-же нужно относится бережливо. Иначе может сложиться ситуация ЛЫСОГО ПАРИКМАХЕРА, типа душа парень - доверить можно всё… кроме СТРИЖКИ. :)

Про время согласен :) а вот что касается лысого скажу только 1 :), всегда у самого небрежного цирюльника причёска зависит от напарника :)
К примеру качественного IPS биллинга на питоне я не встретил , так что придётся писать самому и думаю надо и натирование и выдерживание в БД определённых запросов и чтоб любой чайник на любую платформу мог поставить , без дополнительного мозго_любства :) чтоб можно было управлять железом(SNMP к примеру), а то какой не возьмёшь то или танцевать с бубном или плати :) … тут дело такое хочеш качество делай для себя сам :) , а времени у меня пока хватает :) язык же надо осваивать вот счя еще BSDA (BSDP надеюсь) получить надо :)

ЗЫЖ
Что касательно времени , тут дело такое иногда наши ,,работодатели,, нас на#бывают так что сил нет меня в этом порадовал последний мой работодатель ТГК14 типа гарантии и прочее они там предложили ага кк же на#балово полное 2 месяца у них там жил не выходя в рабских условиях , а они только посмеялись над тем что ,,дурачек,, за них сделал и получили свою разницу в карман , так что уже никакого желания работать с ними нет. Так что кто хочет заработать себе геморой милости просим в отдел ИТ ТЭЦ1(Улан-Удэ)

Отредактировано (Март 9, 2009 23:51:28)

Блин, ребят, совершенно нет времени и сил добить код. Как добирусь – отпишусь.
Ну а если в двух словах, то я продумал, что именно мне нужно и отказался от правки содержимого пакета, но можно переписать концовку и всё будет замечательно. По крайней мере для моих нужд этого достаточно.
Сам пакет предсавляет из себя такую вот билеберду:
4 байта – magic “ZPK ”
4 байта – интегер, представляющий номер байта, откуда начинается инфо-часть.
Тут у нас данные. Много и прямо подряд. Никаких разделителей, ничего.
4 байта – интегер с размером последующей инфы. Может показаться лишним, но это такой вот момент задела на расширение.
Сообветственно инфа в YAML. В ней представленна meta-инфа пакета и инфа о файлах (с meta, конечно же) и, что самое главное, байт начала, байт конца файла в пакете, контрольная сумма и имя обработчика.
Обработчик, это прежде всего сжатие gzip, которое, кстати, я пока не победил… Ну ничего, чуть времени и эта чуда-юда капиталирует перед мощью моего интеллекта! :-)

Э… Дык это-же “Electronic Arts Interchange File Format 1985 (EA IFF 85)” пра-древний СТАНДАРТ на формат макинтошевских файлов данных.
Осталось тока добавить четырхбайтовый код типа инфы “чанк” чтобы сделать формат масштабируемым.
Прочтите спецификацию - мож на идеи какие наведёт.
Дожил и до наших дней в файлах растрового изображения *.iff (с упаковкой внутри и без )
И в несколько извращенном виде, в формате *.lwo для хранения данных трехмерной графики “LightWave3D”
Но раньше использовался на МАС для всех нужд в том числе и для сетки и для емуляции FS для пачки мелких файлов хранимых как один файл приличного размера.
Сишная либа EAIFF писана на таком древнем плайн С, что нынешние С++ программеры прочесть сырец не в состоянии - спрашивают ДА СИ ЛИ ЭТО ? :)

ЗЫ: Всё ли новое на поверку оказывается давно забытым ?

А всегда всё новое это ремикс к старому :)