Segey

Segey
Рейтинг
404
Регистрация
23.08.2005
Интересы
СДРК

дубль.....

Mutabors:
Умеет тигированные виланы, а больше мне ничего и не нужно, все через них сделал красиво. Циску это не напрягает, т.к. аппаратно делается.

Можно поподробнее? Мне нужно на VALN l2tp/pppoe настроить, от того и я микролинк этот хочу т.к. на нем можно клиента настраивать l2tp pppoe на двух или трех портах или больше, ну либо уже крайний случай успокоиться и настроить их на сервере т.е. вообще без маршрутизатора остаться, но так не хочется

А что у них за ошибки вы говорили, какие у микролинка проблемы?

Mutabors,

А вот что я самое забыл то, мне нужно 4-5 WAN, а на циске что у вас или такого плана можно поднимать VLANы с маршрутизатора и настраивать l2tp/pppoe?

Т.е. чтобы сервер вообще во всем этом не участвовал

Мда, главное чтобы правда там было это видео/фото будет на что посмотреть :)

_vb_:
Не могу себе представить, как наличие комментов в коде может помочь определиться в отношении сколько нибудь большого проекта. Пусть те же 20-30К строк кода, из вашего примера. Тут уже играют роль другие вещи - наличие доков, какого то комьюнити и т.п. Даже график чекинов за последние полгода-год имхо больше скажет, если речь об опенсорсе.

Это конечно в первую очередь учитывается, без поддержки и доков все совсем плохо, но иногда то же самое API бывает настолько непродуманным, что доки не помогают.

Просто хочется и код глянуть, что там вообще есть, в код можно сильно не вникать в сам код, а читать комментарии, так многим проще можно и доки не смотреть а просто посмотреть сам продукт и как в нем все устроено вместе с примерами или какими то типовыми решениями, в общем все способы хороши я думаю, если работает :)

_vb_:
Вы меня победили, признаю. Довольны?

Нет, все таки мне интересно увидеть пример того про что вы говорите т.е. мне бы это было интересно. Джанго хороший пример, но только никак не подходит и за довольно большого кол-ва комментариев

Я вам про другое пытаюсь сказать. Комменты в коде в подавляющем большинстве случаев это костыли, подпирающие неряшливый код. Но вам ведь победить надо, да?

Мне вот приходится думать о нескольких разнородных вещах и отсутствие комментариев при какой угодно порядочности кода создают мне проблемы. Хорошо с популярными вещами как Джанго, они вроде как общепризнаны и доказывать что оно того стоит не нужно, но как быть с тем что ты видишь в первый раз и в принципе есть большие сомнения стоит оно того или нет, а вот момент когда нужно решать уже наступил

Я вам больше про то, что экономить время и не делать то что можно не делать по моему лучше

_vb_,

# Whether or not to signal a file-completion at the beginning of the loop.
old_field_name = None
counters = [0] * len(handlers)

Ну вам конечно как специалисту без этого понятно, по красоте кода что это значит, если комментарий убрать :)

А комменты в коде - это дружелюбие джанговского комьюнити.

Ну выше вы привели в пример его как проект где это вообще отсутствует :D Так приведите настоящий, без всяких "оговорок", где дружелюбие в самом коде и там правда не нужны эти пояснения :) А то выходит комьюнити так дружно, что все таки следует нормальным правилам и все документирует как и надо, а не режет :) Они кстати видели как строки то не экономят? Ужас один, вообще не думают об этом

p.s. Давайте честный пример :)

_vb_:
https://www.djangoproject.com/

Кода там существенно больше 30К строк.

multipartparser.py

def parse(self):
"""
Parse the POST data and break it into a FILES MultiValueDict and a POST
MultiValueDict.

Returns a tuple containing the POST and FILES dictionary, respectively.
"""
# We have to import QueryDict down here to avoid a circular import.
from django.http import QueryDict

encoding = self._encoding
handlers = self._upload_handlers

# HTTP spec says that Content-Length >= 0 is valid
# handling content-length == 0 before continuing
if self._content_length == 0:
return QueryDict(MultiValueDict(), encoding=self._encoding), MultiValueDict()

# See if the handler will want to take care of the parsing.
# This allows overriding everything if somebody wants it.
for handler in handlers:
result = handler.handle_raw_input(self._input_data,
self._meta,
self._content_length,
self._boundary,
encoding)
if result is not None:
return result[0], result[1]

# Create the data structures to be used later.
self._post = QueryDict('', mutable=True)
self._files = MultiValueDict()

# Instantiate the parser and stream:
stream = LazyStream(ChunkIter(self._input_data, self._chunk_size))

# Whether or not to signal a file-completion at the beginning of the loop.
old_field_name = None
counters = [0] * len(handlers)

try:
for item_type, meta_data, field_stream in Parser(stream, self._boundary):
if old_field_name:
# We run this at the beginning of the next loop
# since we cannot be sure a file is complete until
# we hit the next boundary/part of the multipart content.
self.handle_file_complete(old_field_name, counters)
old_field_name = None

try:
disposition = meta_data['content-disposition'][1]
field_name = disposition['name'].strip()
except (KeyError, IndexError, AttributeError):

Вы его вообще видели?

_vb_:
Хороший код значительно сокращает затраты времени на его сопровождение и развитие. Как новым человеком, так и автором спустя полгода-год. Меньше мест, куда при правках можно пристроить источник глюков.

Мне как то с трудом верится что ваш стиль в котором вам проще разобраться без комментариев будет понятен всем остальным :) Вам то понятно будет и споровождать его тоже будет проще, но во-первых это намного больше трудозатрат, во-вторых если после кто будет делать комментарии и документация так же нужны.

В примере выше можно и без них разобраться кому угодно, в 20-30к строк без комментариев тоже удобно разбираться? :) Ну если вам нравится, то конечно дело хозяйское, много ПО открытого страдает тем что у автором времени на творчество может и достаточно, но докумментации и толковых комментариев нет

Приведите уже в пример какое нибудь ПО по вашей модели которое в таком виде работает развивается и всем классно все с ходу понимают и никому не нужно ничего там пояснять. :) Естественно что-то больше чем скрипт голосовалки или гостевой, что-то более менее сложное, а то так тоже не интересно. В таких примерах можно и так разобраться, неважно какой-там код.

_vb_,

Ну в статье не совсем ясная оптимизация, проработать так 6-25к строк кода и будет, возможно, лучше но по моему сразу можно писать достаточно хорошо, оптимизация прироста производительности не дает, а читабельность падает - только автор знает каким хитрым способом и от чего он решил отказаться.

Поубирал скобки и говорит так лучше, а мне со скобками лучше везде где они есть или вообще без них как в том же Питоне.

А вот как потом лопатиш такой оптимизированный код где "все лишнее" выпили, так и начинаешь играть в разгадывание ребуса. Хорошо если код маленький, а если его много, начинаются проблемы.

Либо свой так оптимизировать. В скорости я не вижу никаких значительных плюсов, время уходит больше на это все, отладка... да то же самое, если ты сам оптимизировал и может совсем не то же самое, если не ты (т.е. отладка логики работы, потому что отладка остальных ошибок в принципе вообще пофиг какой код). Ценность его за это не повышается для конечного пользователя, время увеличивается на разработку.

Вот приведите пример, чем в практическом смысле это лучше?

Всего: 7644