Мне вот тоже ростелеком начал названивать. Проблема в том, что они так часто поднимают цену, что я не успеваю настраивать автопополнение. А недавно вообще тариф поменяли. Разумеется, без всяких уведомлений.
Популяция, Выборка, Ошибка первого рода, Ошибка второго рода, Синхрофазотрон… Не статья, а конспект едва ли не целого семестра по математической статистике. Никому, кроме (бывших) слушателей этих лекций, она понятна не будет.
Впечатляет. Я пару лет назад делал нечто подобное на pgrouting, и там используется двунаправленный Дейкстра, вероятно, неспроста. Неплохо было бы здесь его добавить в сравнение. Ещё можно было бы и BFS/DFS включить для наглядности...
Можно было бы попробовать сжать gzip'ом — карта Москвы из 47МБ превращается в 7.1МБ. Но при таком подходе у меня не было бы контроля над скоростью распаковки данных — их бы пришлось парсить javascript'ом на клиенте, что тоже повлияло бы на скорость инициализации.
gzip распаковывается браузером.
Это не самый эффективный способ сжатия, но его очень легко реализовать и можно очень быстро восстановить начальный граф на клиенте.
Ну а на сколько эффективнее (меньше) получилось чем JSON, XML/gzip?
Я просто приведу цитату из одного моего любимого произведения Стругацких (1964г.):
Упомянутое уже невежество в вопросах магии как науки играет с авторами злые
шутки на протяжении всей книги. Так, например, формулируя диссертационную
тему М. Ф. Редькина, они допустили четырнадцать (!) фактических ошибок.
Солидный термин «гиперполе», который им, очевидно, очень понравился, они
вставляют в текст сплошь и рядом неуместно. Им, по-видимому, невдомек, что
диван-транслятор является излучателем не м-поля, а мю-поля; что термин
«живая вода» вышел из употребления в позапрошлом веке; что таинственного
прибора, под названием аквавитометр, и электронной машины под названием
«Алдан», в природе не существует; что заведующий вычислительной лабораторией
крайне редко занимается проверкой программ — для этого существуют
математики-программисты, которых в нашей лаборатории двое и которых авторы
упорно называют девочками.
В пещерах не было дамских журналов (в тексте выше вполне чётко о них говорится) и всяких там барби. И не было их до середины 20 века. И женщин-программистов на заре было гораздо больше чем мужчин, а теперь наоборот.
Я отнюдь не утверждаю что все девочки такие, я лишь говорю что жертв такого стереотипного воспитания сегодня предостаточно.
Мне кажется, что старое доброе приложение-счетчик, будет идеальным для этого примера.
Обожаю такие обороты. Очевидно, оно идеально, потому что на чем-то более приближенном к действительности (сложном) cycle.js уже показывает себя не так выгодно?
Может всё таки делается ещё один запрос непосредственно к приложению? Но всё равно, почему какое то левое приложение, которому явно не давали разрешения, имеет доступ к персональным данным?
Я правильно понимаю, что при таком подходе образ на Docker Hub не будет значиться как Automated Build? Для открытых проектов это как бы важно. Мне кажется, можно научить трэвис инициировать автосборку на хабе.
Неплохо бы переименовать статью, чтобы не вводить в заблуждение что здесь речь идет не только о MS и Oracle (и немножко про MySQL) и не тратить чужое время.
Есть такая замечательная штука как Ansible (несправедливо не упомянутая в статье), которая будет делать всё это за вас. А есть ещё не менее прекрасный Docker. Но на самом деле это всё мелочи. Я обязательно прочитаю остальные части (кстати, неплохо бы их осмысленно озаглавить), и тогда уже задам вопросы по существу. И да, не заметил что перевод.
Решил написать развёрнутый комментарий. Читал статью с большим интересом, подумал: вдруг она убедит меня в том, что Go нужен? Но по ходу статьи все более становилось похоже что автор убеждает себя. Аргументы, скажем так, несостоятельные. Пройдёмся подробнее.
Многопоточность. GIL — это особенность реализации. Она действительно не позволяет использовать многопоточное программирование, но польза от него в веб-приложениях крайне сомнительная (разве что вам действительно необходимо в рамках одного запроса делать какие-то трудоёмкие и параллелящиеся операции; при этом если используется библиотека типа sklearn или numpy, то там параллелизм будет). Дропбоксовцы пилили свою реализацию питона — "Pyston", и кажется даже без GIL (но это не точно). Она была очень быстрой в бенчмарках, но вот прирост производительности в реальном веб-приложении (ради чего всё и затевалось) оказался неприлично маленьким, в итоге её забросили. Так что не GIL'ом единым. В реальных приложениях всякие UWSGI справляются с задачей превосходно. Кстати, в приведённой статье про C10K перечислены Nginx, Tornado и т.д. как решения данной проблемы. В любом случае, ничего сложного в этом нет.
Фоновые задачи. Да, без них никуда. И да, их как правило следует писать как часть приложения. Но я не вижу ничего плохого (и даже наоборот) в использовании Celery или Resque (да, с redis в качестве бэкенда).
В этом случае та огромная сложность, введенная в первую очередь для возможности использования популярного скриптового языка [для создания веб-прилолжения], оказывается ненужной.
Что?
Особенно учитывая, что Python или Ruby приносят мало выгоды, когда весь вывод — это JSON.
Ну современные СУБД умеют отдавать JSON (тот же Postgres), зачем вообще нужна прослойка в виде Go? Даёшь веб-приложения на PL/SQL!
ORM не нужен. Ок… Только не забывайте предохраняться от SQL-инъекций. При миграции деликатно промолчу.
Фреймворк не нужен. Ок… Только не забывайте предохраняться от XSS, CSRF и т.д.
Другая проблема, общая для фреймворков, это то, что они абстрагируют низкоуровневые механизмы от разработчика так, что со временем они становятся настолько загадочными, что буквально невозможно понять, что у них там на самом деле происходит.
Конечно, лучше когда детали реализации на поверхности. Ну или спрятаны в пакет (особенно бинарный).
То, что начинается с лексического псевдонима для одной строки JavaScript становится слоем в слоях транспайлеров, минимайзеров, поверх хелперов, скрытых где-то в подзависимостях.
Я понимаю что это реверанс в сторону нода, но на клиенте от транспайлинга JS тоже откажемся? Что дальше, нафиг ES6? Вернёмся к ActiveX?
А ещё в статье вообще не описаны недостатки Go. Я сам с ним не знаком, но на мой взгляд это в первую очередь своеобразный синтаксис и ООП (точнее, его отсутствие), вместо которого применяется нечто вроде monkey-патчинга, который с моей точки зрения является особо опасным антипаттерном.
Итог: Я так и не увидел ни одного преимущества Go. Перспектива пилить велосипед на каждый чих меня скорее отталкивает. И всё ради чего? Аргумент "патаму что сложна" меня как то не удовлетворяет.
Ну смотрите: сейчас кто то проникнется вашими идеями, начнёт проект на Go. А потом проект взлетит. А потом внезапно придёт осознание что redis таки нужен. А потом nginx с HTTPS. А потом фоновые задачи тоже неплохо бы вынести отдельно (ну там горизонтальное масштабирование и т.п.). И даже жуткий Puppet (ну или не такой жуткий Ansible). И в итоге все описанные преимущества сойдут на нет. А что имеем в итоге? "Ручной" SQL. Ручное управление сессиями. Да вообще всё ручное. И все детали реализации на поверхности.
А ещё кеширование можно организовать средствами Си и вызывать из Go. Ощущается странная мания внести вообще всё внутрь своего приложения. Перечисленные инструменты разрабатывались под конкретные задачи и справляются с ними хорошо, так зачем делать велосипед? А отказ от фреймворков подразумевает что делать его придётся с нуля. HTTPS тоже сами делать будете?
Конечно, стандартная отписка:
Мне вот тоже ростелеком начал названивать. Проблема в том, что они так часто поднимают цену, что я не успеваю настраивать автопополнение. А недавно вообще тариф поменяли. Разумеется, без всяких уведомлений.
Лучше просто исправьте его.
Кстати, хотелось бы услышать про то, как у вас устроен бэкап.
Вы и сейчас запутываете :(
Что да то? Стоит или не стоит?
Из продолжения, конечно, становится понятно, но это всё равно не дело.
Популяция, Выборка, Ошибка первого рода, Ошибка второго рода, Синхрофазотрон… Не статья, а конспект едва ли не целого семестра по математической статистике. Никому, кроме (бывших) слушателей этих лекций, она понятна не будет.
Впечатляет. Я пару лет назад делал нечто подобное на pgrouting, и там используется двунаправленный Дейкстра, вероятно, неспроста. Неплохо было бы здесь его добавить в сравнение. Ещё можно было бы и BFS/DFS включить для наглядности...
gzip распаковывается браузером.
Ну а на сколько эффективнее (меньше) получилось чем JSON, XML/gzip?
Не совсем так: ключами объекта могут быть ТОЛЬКО строки. Если использовать число в качестве ключа объекта, оно будет преобразовано в строку.
Не понял, в чём проблема? "Программист" жалуется что не смог нормально открыть CSV в экселе? Про JSON уж промолчу… Куда мы катимся?
Я отнюдь не утверждаю что все девочки такие, я лишь говорю что жертв такого стереотипного воспитания сегодня предостаточно.
Обожаю такие обороты. Очевидно, оно идеально, потому что на чем-то более приближенном к действительности (сложном) cycle.js уже показывает себя не так выгодно?
Угу, особенно деревья и хэш-таблицы.
Может всё таки делается ещё один запрос непосредственно к приложению? Но всё равно, почему какое то левое приложение, которому явно не давали разрешения, имеет доступ к персональным данным?
Я правильно понимаю, что при таком подходе образ на Docker Hub не будет значиться как Automated Build? Для открытых проектов это как бы важно. Мне кажется, можно научить трэвис инициировать автосборку на хабе.
Неплохо бы переименовать статью, чтобы не вводить в заблуждение что здесь речь идет не только о MS и Oracle (и немножко про MySQL) и не тратить чужое время.
Есть такая замечательная штука как Ansible (несправедливо не упомянутая в статье), которая будет делать всё это за вас. А есть ещё не менее прекрасный Docker. Но на самом деле это всё мелочи. Я обязательно прочитаю остальные части (кстати, неплохо бы их осмысленно озаглавить), и тогда уже задам вопросы по существу. И да, не заметил что перевод.
Решил написать развёрнутый комментарий. Читал статью с большим интересом, подумал: вдруг она убедит меня в том, что Go нужен? Но по ходу статьи все более становилось похоже что автор убеждает себя. Аргументы, скажем так, несостоятельные. Пройдёмся подробнее.
Многопоточность. GIL — это особенность реализации. Она действительно не позволяет использовать многопоточное программирование, но польза от него в веб-приложениях крайне сомнительная (разве что вам действительно необходимо в рамках одного запроса делать какие-то трудоёмкие и параллелящиеся операции; при этом если используется библиотека типа sklearn или numpy, то там параллелизм будет). Дропбоксовцы пилили свою реализацию питона — "Pyston", и кажется даже без GIL (но это не точно). Она была очень быстрой в бенчмарках, но вот прирост производительности в реальном веб-приложении (ради чего всё и затевалось) оказался неприлично маленьким, в итоге её забросили. Так что не GIL'ом единым. В реальных приложениях всякие UWSGI справляются с задачей превосходно. Кстати, в приведённой статье про C10K перечислены Nginx, Tornado и т.д. как решения данной проблемы. В любом случае, ничего сложного в этом нет.
Что?
Ну современные СУБД умеют отдавать JSON (тот же Postgres), зачем вообще нужна прослойка в виде Go? Даёшь веб-приложения на PL/SQL!
Конечно, лучше когда детали реализации на поверхности. Ну или спрятаны в пакет (особенно бинарный).
Я понимаю что это реверанс в сторону нода, но на клиенте от транспайлинга JS тоже откажемся? Что дальше, нафиг ES6? Вернёмся к ActiveX?
А ещё в статье вообще не описаны недостатки Go. Я сам с ним не знаком, но на мой взгляд это в первую очередь своеобразный синтаксис и ООП (точнее, его отсутствие), вместо которого применяется нечто вроде monkey-патчинга, который с моей точки зрения является особо опасным антипаттерном.
Итог: Я так и не увидел ни одного преимущества Go. Перспектива пилить велосипед на каждый чих меня скорее отталкивает. И всё ради чего? Аргумент "патаму что сложна" меня как то не удовлетворяет.
Ну смотрите: сейчас кто то проникнется вашими идеями, начнёт проект на Go. А потом проект взлетит. А потом внезапно придёт осознание что redis таки нужен. А потом nginx с HTTPS. А потом фоновые задачи тоже неплохо бы вынести отдельно (ну там горизонтальное масштабирование и т.п.). И даже жуткий Puppet (ну или не такой жуткий Ansible). И в итоге все описанные преимущества сойдут на нет. А что имеем в итоге? "Ручной" SQL. Ручное управление сессиями. Да вообще всё ручное. И все детали реализации на поверхности.
А ещё кеширование можно организовать средствами Си и вызывать из Go. Ощущается странная мания внести вообще всё внутрь своего приложения. Перечисленные инструменты разрабатывались под конкретные задачи и справляются с ними хорошо, так зачем делать велосипед? А отказ от фреймворков подразумевает что делать его придётся с нуля. HTTPS тоже сами делать будете?