Mutabors: Умеет тигированные виланы, а больше мне ничего и не нужно, все через них сделал красиво. Циску это не напрягает, т.к. аппаратно делается.
Можно поподробнее? Мне нужно на VALN l2tp/pppoe настроить, от того и я микролинк этот хочу т.к. на нем можно клиента настраивать l2tp pppoe на двух или трех портах или больше, ну либо уже крайний случай успокоиться и настроить их на сервере т.е. вообще без маршрутизатора остаться, но так не хочется
А что у них за ошибки вы говорили, какие у микролинка проблемы?
_vb_: Не могу себе представить, как наличие комментов в коде может помочь определиться в отношении сколько нибудь большого проекта. Пусть те же 20-30К строк кода, из вашего примера. Тут уже играют роль другие вещи - наличие доков, какого то комьюнити и т.п. Даже график чекинов за последние полгода-год имхо больше скажет, если речь об опенсорсе.
Это конечно в первую очередь учитывается, без поддержки и доков все совсем плохо, но иногда то же самое API бывает настолько непродуманным, что доки не помогают.
Просто хочется и код глянуть, что там вообще есть, в код можно сильно не вникать в сам код, а читать комментарии, так многим проще можно и доки не смотреть а просто посмотреть сам продукт и как в нем все устроено вместе с примерами или какими то типовыми решениями, в общем все способы хороши я думаю, если работает :)
Нет, все таки мне интересно увидеть пример того про что вы говорите т.е. мне бы это было интересно. Джанго хороший пример, но только никак не подходит и за довольно большого кол-ва комментариев
Я вам про другое пытаюсь сказать. Комменты в коде в подавляющем большинстве случаев это костыли, подпирающие неряшливый код. Но вам ведь победить надо, да?
Мне вот приходится думать о нескольких разнородных вещах и отсутствие комментариев при какой угодно порядочности кода создают мне проблемы. Хорошо с популярными вещами как Джанго, они вроде как общепризнаны и доказывать что оно того стоит не нужно, но как быть с тем что ты видишь в первый раз и в принципе есть большие сомнения стоит оно того или нет, а вот момент когда нужно решать уже наступил
Я вам больше про то, что экономить время и не делать то что можно не делать по моему лучше
# Whether or not to signal a file-completion at the beginning of the loop. old_field_name = None counters = [0] * len(handlers)
Ну вам конечно как специалисту без этого понятно, по красоте кода что это значит, если комментарий убрать :)
А комменты в коде - это дружелюбие джанговского комьюнити.
Ну выше вы привели в пример его как проект где это вообще отсутствует :D Так приведите настоящий, без всяких "оговорок", где дружелюбие в самом коде и там правда не нужны эти пояснения :) А то выходит комьюнити так дружно, что все таки следует нормальным правилам и все документирует как и надо, а не режет :) Они кстати видели как строки то не экономят? Ужас один, вообще не думают об этом
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
# 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
_vb_: Хороший код значительно сокращает затраты времени на его сопровождение и развитие. Как новым человеком, так и автором спустя полгода-год. Меньше мест, куда при правках можно пристроить источник глюков.
Мне как то с трудом верится что ваш стиль в котором вам проще разобраться без комментариев будет понятен всем остальным :) Вам то понятно будет и споровождать его тоже будет проще, но во-первых это намного больше трудозатрат, во-вторых если после кто будет делать комментарии и документация так же нужны.
В примере выше можно и без них разобраться кому угодно, в 20-30к строк без комментариев тоже удобно разбираться? :) Ну если вам нравится, то конечно дело хозяйское, много ПО открытого страдает тем что у автором времени на творчество может и достаточно, но докумментации и толковых комментариев нет
Приведите уже в пример какое нибудь ПО по вашей модели которое в таком виде работает развивается и всем классно все с ходу понимают и никому не нужно ничего там пояснять. :) Естественно что-то больше чем скрипт голосовалки или гостевой, что-то более менее сложное, а то так тоже не интересно. В таких примерах можно и так разобраться, неважно какой-там код.
Ну в статье не совсем ясная оптимизация, проработать так 6-25к строк кода и будет, возможно, лучше но по моему сразу можно писать достаточно хорошо, оптимизация прироста производительности не дает, а читабельность падает - только автор знает каким хитрым способом и от чего он решил отказаться.
Поубирал скобки и говорит так лучше, а мне со скобками лучше везде где они есть или вообще без них как в том же Питоне.
А вот как потом лопатиш такой оптимизированный код где "все лишнее" выпили, так и начинаешь играть в разгадывание ребуса. Хорошо если код маленький, а если его много, начинаются проблемы.
Либо свой так оптимизировать. В скорости я не вижу никаких значительных плюсов, время уходит больше на это все, отладка... да то же самое, если ты сам оптимизировал и может совсем не то же самое, если не ты (т.е. отладка логики работы, потому что отладка остальных ошибок в принципе вообще пофиг какой код). Ценность его за это не повышается для конечного пользователя, время увеличивается на разработку.
Вот приведите пример, чем в практическом смысле это лучше?
дубль.....
Умеет тигированные виланы, а больше мне ничего и не нужно, все через них сделал красиво. Циску это не напрягает, т.к. аппаратно делается.
Можно поподробнее? Мне нужно на VALN l2tp/pppoe настроить, от того и я микролинк этот хочу т.к. на нем можно клиента настраивать l2tp pppoe на двух или трех портах или больше, ну либо уже крайний случай успокоиться и настроить их на сервере т.е. вообще без маршрутизатора остаться, но так не хочется
А что у них за ошибки вы говорили, какие у микролинка проблемы?
Mutabors,
А вот что я самое забыл то, мне нужно 4-5 WAN, а на циске что у вас или такого плана можно поднимать VLANы с маршрутизатора и настраивать l2tp/pppoe?
Т.е. чтобы сервер вообще во всем этом не участвовал
Мда, главное чтобы правда там было это видео/фото будет на что посмотреть :)
Не могу себе представить, как наличие комментов в коде может помочь определиться в отношении сколько нибудь большого проекта. Пусть те же 20-30К строк кода, из вашего примера. Тут уже играют роль другие вещи - наличие доков, какого то комьюнити и т.п. Даже график чекинов за последние полгода-год имхо больше скажет, если речь об опенсорсе.
Это конечно в первую очередь учитывается, без поддержки и доков все совсем плохо, но иногда то же самое API бывает настолько непродуманным, что доки не помогают.
Просто хочется и код глянуть, что там вообще есть, в код можно сильно не вникать в сам код, а читать комментарии, так многим проще можно и доки не смотреть а просто посмотреть сам продукт и как в нем все устроено вместе с примерами или какими то типовыми решениями, в общем все способы хороши я думаю, если работает :)
Вы меня победили, признаю. Довольны?
Нет, все таки мне интересно увидеть пример того про что вы говорите т.е. мне бы это было интересно. Джанго хороший пример, но только никак не подходит и за довольно большого кол-ва комментариев
Мне вот приходится думать о нескольких разнородных вещах и отсутствие комментариев при какой угодно порядочности кода создают мне проблемы. Хорошо с популярными вещами как Джанго, они вроде как общепризнаны и доказывать что оно того стоит не нужно, но как быть с тем что ты видишь в первый раз и в принципе есть большие сомнения стоит оно того или нет, а вот момент когда нужно решать уже наступил
Я вам больше про то, что экономить время и не делать то что можно не делать по моему лучше
_vb_,
old_field_name = None
counters = [0] * len(handlers)
Ну вам конечно как специалисту без этого понятно, по красоте кода что это значит, если комментарий убрать :)
Ну выше вы привели в пример его как проект где это вообще отсутствует :D Так приведите настоящий, без всяких "оговорок", где дружелюбие в самом коде и там правда не нужны эти пояснения :) А то выходит комьюнити так дружно, что все таки следует нормальным правилам и все документирует как и надо, а не режет :) Они кстати видели как строки то не экономят? Ужас один, вообще не думают об этом
p.s. Давайте честный пример :)
https://www.djangoproject.com/
Кода там существенно больше 30К строк.
multipartparser.py
"""
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):
Вы его вообще видели?
Хороший код значительно сокращает затраты времени на его сопровождение и развитие. Как новым человеком, так и автором спустя полгода-год. Меньше мест, куда при правках можно пристроить источник глюков.
Мне как то с трудом верится что ваш стиль в котором вам проще разобраться без комментариев будет понятен всем остальным :) Вам то понятно будет и споровождать его тоже будет проще, но во-первых это намного больше трудозатрат, во-вторых если после кто будет делать комментарии и документация так же нужны.
В примере выше можно и без них разобраться кому угодно, в 20-30к строк без комментариев тоже удобно разбираться? :) Ну если вам нравится, то конечно дело хозяйское, много ПО открытого страдает тем что у автором времени на творчество может и достаточно, но докумментации и толковых комментариев нет
Приведите уже в пример какое нибудь ПО по вашей модели которое в таком виде работает развивается и всем классно все с ходу понимают и никому не нужно ничего там пояснять. :) Естественно что-то больше чем скрипт голосовалки или гостевой, что-то более менее сложное, а то так тоже не интересно. В таких примерах можно и так разобраться, неважно какой-там код.
_vb_,
Ну в статье не совсем ясная оптимизация, проработать так 6-25к строк кода и будет, возможно, лучше но по моему сразу можно писать достаточно хорошо, оптимизация прироста производительности не дает, а читабельность падает - только автор знает каким хитрым способом и от чего он решил отказаться.
Поубирал скобки и говорит так лучше, а мне со скобками лучше везде где они есть или вообще без них как в том же Питоне.
А вот как потом лопатиш такой оптимизированный код где "все лишнее" выпили, так и начинаешь играть в разгадывание ребуса. Хорошо если код маленький, а если его много, начинаются проблемы.
Либо свой так оптимизировать. В скорости я не вижу никаких значительных плюсов, время уходит больше на это все, отладка... да то же самое, если ты сам оптимизировал и может совсем не то же самое, если не ты (т.е. отладка логики работы, потому что отладка остальных ошибок в принципе вообще пофиг какой код). Ценность его за это не повышается для конечного пользователя, время увеличивается на разработку.
Вот приведите пример, чем в практическом смысле это лучше?