Как связаны размер данных и хайлоад/не хайлоад?
Если бы вы прочитали статью, то увидели бы что основной челендж был связан с синхронизацией, кол-вом коннекшенов и трафиком (хоть решили они эти проблемы и в лоб).
Почему выбрали GitHub, а не свой локальный VCS сервер? А то я сколько в разных компаниях видел — все исходники хранят у себя.
Не совсем понял, что значит «хранят у себя». Git — распределенная система, у всех разработчиков есть исходники, а github — просто точка синхронизации. В случае, если гитхаб внезапно отключится — вы всегда можете на любом сервере сделать чекаут, дружно добавить этот сервер в remote-ы и продолжать работать, только без удобняшек.
Ну и собственно удобняшки от github, из-за которых его используют:
1. Удобные пулл-ревесты, комментарии, картинки и т.п.
2. Высокий аптайм, свои серваки почаще лежат.
3. Система прав (группы, r/o, все дела).
4. Markdown из коробки.
5. Удобный viewer (блейм/raw/поиск, все дела).
Очень много предложений, которые вообще очень сложно понять.
Вот например (взял первый попавшийся абзац):
>Это может не касаться React на серверной стороне, но было бы странно, создавать компоненты, которые бы отличались в этом плане на серверной и клиентской стороне.
Помимо пунктуации и повторений «серверной стороне — серверной стороне» — тут очень сложно вообще понять, что хотел сказать автор.
Возможно стоит просто писать своими словами, типа:
«Можно было бы не делать это на сервере, но это странно — создавать компоненты, которые по-разному работают на бэкенде и фронтенде».
P.S.
> я неохотно проповедую изоморфные JavaScript приложения — это вообще перл =)
«в 21часов 30 минут» — о_О
А если написать «Сегодня в 21час 30 минут», то получим «Распознано как: + сегодня [21 30 ми:00]»
Ну, и сам код причиняет боль, да…
Статья, которую вы привели — очень клевая, она мне в свое время помогла понять, как это делается.
А вот то, как вы обернули все это в какой-то странный класс с Help-ом и Errorer-ом — это вообще не круто.
Статья «Есть робот-медуза». Круто.
Как она будет решать проблемы распространения пятен, какие технологии, как собираются защищаться от жесткой соленой воды — это же гикам только интересно, а у нас фишки.нет.
Я правильно понял, что вам смешно потому что вы знаете лишь про системы, устанавленные в советское время на самолеты типа Ан-24, где корундовый резец пишет по пленке?
UPD: это к комментарию выше.
Автору могу посоветовать использовать enumerate, не изменять аргументов функций и вообще почитать доку. Хотя код оформлен гламурненько =)
Пиши тесты, пиши документацию, тестируй, мой руки перед едой…
К тому же в компаниях покрупнее большую часть этих функций берут на себя менеджеры, тестировщики и аналитики.
Если бы вы прочитали статью, то увидели бы что основной челендж был связан с синхронизацией, кол-вом коннекшенов и трафиком (хоть решили они эти проблемы и в лоб).
А рассказывать варгеймингу про производительность вообще смешно.
Ехало шифрование через шифрование,
видит шифрование — шифрование.
Сунуло шифрование шифрование в шифрование,
Шифрование, шифрование шифрование шифрование.
На мой взгляд, полезность -> 0.
Не совсем понял, что значит «хранят у себя». Git — распределенная система, у всех разработчиков есть исходники, а github — просто точка синхронизации. В случае, если гитхаб внезапно отключится — вы всегда можете на любом сервере сделать чекаут, дружно добавить этот сервер в remote-ы и продолжать работать, только без удобняшек.
Ну и собственно удобняшки от github, из-за которых его используют:
1. Удобные пулл-ревесты, комментарии, картинки и т.п.
2. Высокий аптайм, свои серваки почаще лежат.
3. Система прав (группы, r/o, все дела).
4. Markdown из коробки.
5. Удобный viewer (блейм/raw/поиск, все дела).
Как-то так.
Вот например (взял первый попавшийся абзац):
>Это может не касаться React на серверной стороне, но было бы странно, создавать компоненты, которые бы отличались в этом плане на серверной и клиентской стороне.
Помимо пунктуации и повторений «серверной стороне — серверной стороне» — тут очень сложно вообще понять, что хотел сказать автор.
Возможно стоит просто писать своими словами, типа:
«Можно было бы не делать это на сервере, но это странно — создавать компоненты, которые по-разному работают на бэкенде и фронтенде».
P.S.
> я неохотно проповедую изоморфные JavaScript приложения — это вообще перл =)
Иногда кажется, что автор перевода просто забил на смысл и переводит слова.
А если написать «Сегодня в 21час 30 минут», то получим «Распознано как: + сегодня [21 30 ми:00]»
Ну, и сам код причиняет боль, да…
menu = MenuItem('Main menu', sub_items = [
MenuItem('Functions', style=...),
TwitterMenuItem(style=...)
]
render(menu)
Потому что сейчас ваш инит-метод — макароны.
P.S. Простите, не работают теги =(
Ммм, я вижу стремный градиент из разряда «секретарь осваивает возможности Microsoft Word».
Простите.
А вот то, как вы обернули все это в какой-то странный класс с Help-ом и Errorer-ом — это вообще не круто.
Как она будет решать проблемы распространения пятен, какие технологии, как собираются защищаться от жесткой соленой воды — это же гикам только интересно, а у нас фишки.нет.
Правда, это без приведения к стрингу =/
Еще есть epytext, мне он больше нравится: epydoc.sourceforge.net/manual-epytext.html#fields
UPD: это к комментарию выше.
Автору могу посоветовать использовать enumerate, не изменять аргументов функций и вообще почитать доку. Хотя код оформлен гламурненько =)
«Я работал программистом и не знал, откуда берутся дети деньги...»
«Менеджеры нужны для того...»
«Какие фичи нужно включать в продукт»
Конец.
И как он стал менеджером-то?
К тому же в компаниях покрупнее большую часть этих функций берут на себя менеджеры, тестировщики и аналитики.