Это же, блин, и отличает хабр от всяких пикабу и подобных гавноресурсов.
Если тебе говорят что ты гавно, то, хотя бы, объясняют причины. И есть шанс поработать над собой и стать лучше. И контент лучше подготавливать.
И статья, честно говоря, с моей точки зрения — мусор
Отлично — ты ведь мог написать в чем я не прав, верно? И в следующий раз увидел бы более качественную статью. Но ты этого не сделал.
Об этом и речь вот в этой самой статье.
Стараешься, делаешь что-то — а тебе минусов пачку лепят и сиди думай что не так.
На что ты рассчитываешь вообще с таким подходом? :-)
Ну в этом спойлере было написано что это шутка и всё. К автору с оригинальным циклом статей про go&Катю я отношения не имею.
Просто в тот момент показалось забавным. Ну вот, как оказалось, неудачная, хоть и безобидная, шутка гробит хороший контент :-)
А ну да, насчет всё ок — статья пол дня не существовала, а если в топ дня не выйти то, как бы, дальше уже и тоже не пройдет. Счетчик никто не возвращает.
Подтверждаю.
Написав пост про разработку онлайн игры с нуля и указав 1 ссылку на игру — пост был удалён и аккаунт отправлен в ридонли. С техподдержкой удалось договориться что оттуда выпиливают все ссылки и упоминания и, вроде, ок.
Пытался договориться о "помощи для стартапов", т.к. проект пока убыточный (находится в ЗБТ) — сказали нет. И ссылки нельзя.
Ну что ж, значит и писать мне смысла особо нет про кучу увлекательных штук. А подобный материал вообще фиг найдешь — сам столкнулся, пришлось по крупицам собирать ото всюду.
Когда-нибудь, конечно, напишу. Но это уже будет чисто для себя, по настроению.
Могу за себя сказать: я стал комментировать сильно меньше, когда в одном из постов дал реф ссылку (которая давала бонус пришедшему, а не мне) по доброте, а меня взяли и выпилили. Т.е. писал я хорошие статьи, не пиисал — вообще не важно. Никаких предупреждений, ничего.
Как уже выше упоминали с минусами тоже самое. Стоит сказать что то неугодное аудитории — всё.
Последнюю статью и карму вместе с ней заминусили потому что добавил шуточный спойлер «про катю». Ну ок.
Ещё очень напрягает когда пишешь не очень простую статью (я это определяю по общению с десятками разработчиков различного уровня и видя что не знают ряда вещей) а кто-нибудь обязательно скажет «ну это же очевидно», а потом добавит что HTML (сам по себе) является human-friendly, показывая полное непонимание темы. И это реально обидно. Стараешься что-то объяснить, делишься своим опытом, а тебе говорят что это всё фигня, показывая что сами же ничерта не поняли. Может, конечно, стоит более просто и более конкретно писать, но, по факту, с чуть более сложными темами выходит что надо как раз более абстрактно говорить, т.к. в каждом случае свои особенности будут и их надо учитывать. Конкретный же пример, в тупую скопированный, работать не будет в других условиях. Т.е. кто-нибудь скопирует и напишет потом — а вот он наврал, ничерта это не работает. Работает! Надо просто головой думать когда делаешь что то.
HTML это тоже не human-friendly вид.
В human-friendly его превращает браузер.
HTML является частным случаем XML. С данными в XML вопросов же нет, да? JSON тоже самое, в принципе.
Разница в том, что HTML содержит дополнительную служебную информацию.
Повторюсь — нет никакой принципиальной разницы в каком формате у нас возвращаются данные.
Если убрать из HTML всю служебку мы получим чистый контент разбитый семантически на логические блоки, который мы ровно точно так же можем распарсить в то, что нам требуется.
По факту парсинг JSON, XML, HTML или чего-либо отличается только наличием библиотек или встроенных инструментов.
Может быть как-нибудь напишу статью «Как обрабатывать миллион одновременных геораспределённых соединений и не обосраться» с конкретными примерами, когда NDA закончится и настроение будет.
В данном случае изменение в любом случае затрагивает клиентскую часть, т.к. клиенту необходимо сообщать о данной ошибке.
Разруливание подобной ситуации к масштабированию имеет косвенное значение. Даже, скорее, это бизнес-задача, а никак не про масштабирование. В пример могу привести wikia — у моей игры есть там неофициальная вики, и люди жаловались о потере одновременных правок. Это реальная проблема была. Даже в таком крупном проекте решена плохо.
Как я уже говорил — в случае оптимизации и разноса по большому количеству серверов пути API будут одни и те же, хотя даже сервера могут находится в разных странах. И вот возврат этой ошибки — как раз сделает API.
Кэширование? Нет ничего проще! Масштабирование? Легко! Версионирование? Проще простого!
Как вы сказали дальше — универсальных решений нет. Именно по этому это уже не легко. Нет универсального решения -> надо подключать мозг.
Я могу написать сотни статей с конкретными юзкейсами. Но мне это не интересно :-) Да и смысла осоьбо не имеет, т.к. каждый новый случай, ваш случай, уже всё равно не в один из них не уложится. Как видишь даже с твоим вопросом я сразу предложил несколько вариаций, в зависимости от контекста. А таких ситуаций бесконечное множество.
Ок, поясню.
Если нашим продуктом является, например, сайт.
Пользователь октрыл сайт (SPA), браузер делает запрос к API и выводит данные. Как бы это настолько очевидно что не пользователь лично делает этот запрос, что мне казалось излишнем подобное комментировать.
Если нашим API воспользовался сторонний разработчик — он либо получил данные к себе, либо вывел их в приложение конечному пользователю. Так или иначе пользователь увидел в продаже нужный ему чайник и купил его. У вас или через партнёра — деньги вы имеете в любом случае.
Принципиальной разницы кто является клиентом API — пользователь или сторонняя программа, нет, т.к. стороннюю программу так же используют люди.
Дальше часть не очень понятна. В тексте статьи и так сказано что возвращать необходимо требуемыми способами.
В качестве интересного примера с внешней API можно взглянуть на Eve online, для которых делают вплоть до игровых онлайн казино.
В них играют пользователи, но, что бы играть, нужна платная подписка. В итоге сторонние разработчики за бесплатно продвигают твой товар (игру).
Если продолжаем про игры. Можно глянуть, например, Neverwinter. Из браузера ты можешь управлять отправкой помощников на задания. В WOW ты можешь мониторить аукцион. Таких примеров очень много.
Конечно, сразу определить какие действия разрешить — сложно, но вот выдавать ряд информации сразу возможно (например ситуацию на рынке).
Как я уже сказал, это не просто полезно, а приносит деньги владельцем проектов.
Какое отношение к разработке API имеет статическая страница для людей, пусть и приносящая 10 штук?
Это иллюстрация преимущества контента. Непосредственно к разработке API пример не относится.
Расскажите-ка лучше, как избежать потери апдейта (т.е. информации) при обновлении одного ресурса двумя клиентами одновременно.
Вопрос не достаточно полный что бы корректно ответить. Так же, зависит от информации, которую модифицируем. Приведу несколько примеров. Коль назвали монгу, применимо к ней.
Общее золото в игре. Вместо выборки и установки нового значения мы можем использовать $inc — в таком случае обе операции, не зависимо от порядка, пройдут успешно. Отвечая на вопрос, что же делать если золото ушло в минус после подобной операции — откат софтварной транзакции и вывод информации о недостатке золота.
В случае если это некая статья, на подобии википедии, то тут мы можем применить несколько вариантов.
Храним историю изменений. Во время отправки текста помимо идентификатора записи указывается номер ревизии, и, в случае если он был изменён, возвращаем неудачу, сохраняя информацию во временное хранилище и показывая актуальные изменения. Вместо прямой выборки данных используем выборку обновлением, с указанием ревизии. Таким образом если документ не выбрался -> были изменения, если выбрался, то он сразу же был помечен новой ревизией.
Банально храним дату изменения и при отправке изменений указываем от какого времени были эти изменения, в случае несоответствия показываем пользователю изменения и даем возможность решить что делать.
Ну а то, что Вы рассказали — это банальное разделение приложения на слои, причем весьма, весьма посредственное (но это все же лучше, чем пришедшие от пользователя данные после валидации пихать сразу в Монгу).
По какой-то причине в технически сложных статьях, как мне кажется, всегда отмечают что это всё просто и легко.
Так вот это не просто и не легко, и умеет это не такая большая доля разработчиков на самом деле.
В случае если у вас всё окружение умеет подобное и применяет — это мега круто. Значит вам удалось попасть в общество экспертов.
причем весьма, весьма посредственное
В чем посредственность — хотелось бы услышать конкретно. Что не так? Как лучше? Я рад учиться, если ошибся где то.
Удалил. Вероятно mannaro прав.
Честно говоря даже не предполагал что из-за шутки будут сливать хороший пост и карму.
Ладно бы откомментировал кто — ты не прав, на самом деле делать надо вот так и вот так.
После вот такой вот фигни никакого желания писать сюда нету, на самом деле.
Как уже писали до этого — сперва определимся насчет суммарного веса всех скриптов в gzip — если менее 100кб то грузим вместе, одним.
Объединять стоит только библиотеки, которые необходимы для отрисовки, иначе лучше отложить их загрузку.
Насчет публичных CDN — тут надо принимать решение по безопасности. Если произойдет подмена скрипта на публичном CDN на вирусный (с кейлоггером, например), то ваш сайт пострадает. Тут все зависит от сайта и от уровня паранойи :-)
Всё зависит от сайта.
Как ты себе представляешь, например, онлайн стриминг в веб 1.0? С перезагрузкой страниц и всем прочим. Вот тут и начинаются проблемы.
На страницы не спроста лепят кучу скриптов и остальных вещей. Вовсе не для того, что бы просто навесить. Их вешают что бы у тебя были взаимодействия моментальные. Что бы ты мог лайк поставить, увидеть чужие лайки здесь и сейчас, комментарий написать и так далее.
Для ряда сайтов, конечно, самых простых, такое подойдет от части, но — если посмотришь на описание, то от самого сайта не всё зависит, но так же играет роль его расположение и т.п.
Если тебе говорят что ты гавно, то, хотя бы, объясняют причины. И есть шанс поработать над собой и стать лучше. И контент лучше подготавливать.
Отлично — ты ведь мог написать в чем я не прав, верно? И в следующий раз увидел бы более качественную статью. Но ты этого не сделал.
Об этом и речь вот в этой самой статье.
Стараешься, делаешь что-то — а тебе минусов пачку лепят и сиди думай что не так.
На что ты рассчитываешь вообще с таким подходом? :-)
Просто в тот момент показалось забавным. Ну вот, как оказалось, неудачная, хоть и безобидная, шутка гробит хороший контент :-)
Написав пост про разработку онлайн игры с нуля и указав 1 ссылку на игру — пост был удалён и аккаунт отправлен в ридонли. С техподдержкой удалось договориться что оттуда выпиливают все ссылки и упоминания и, вроде, ок.
Пытался договориться о "помощи для стартапов", т.к. проект пока убыточный (находится в ЗБТ) — сказали нет. И ссылки нельзя.
Ну что ж, значит и писать мне смысла особо нет про кучу увлекательных штук. А подобный материал вообще фиг найдешь — сам столкнулся, пришлось по крупицам собирать ото всюду.
Когда-нибудь, конечно, напишу. Но это уже будет чисто для себя, по настроению.
Как уже выше упоминали с минусами тоже самое. Стоит сказать что то неугодное аудитории — всё.
Последнюю статью и карму вместе с ней заминусили потому что добавил шуточный спойлер «про катю». Ну ок.
Ещё очень напрягает когда пишешь не очень простую статью (я это определяю по общению с десятками разработчиков различного уровня и видя что не знают ряда вещей) а кто-нибудь обязательно скажет «ну это же очевидно», а потом добавит что HTML (сам по себе) является human-friendly, показывая полное непонимание темы. И это реально обидно. Стараешься что-то объяснить, делишься своим опытом, а тебе говорят что это всё фигня, показывая что сами же ничерта не поняли. Может, конечно, стоит более просто и более конкретно писать, но, по факту, с чуть более сложными темами выходит что надо как раз более абстрактно говорить, т.к. в каждом случае свои особенности будут и их надо учитывать. Конкретный же пример, в тупую скопированный, работать не будет в других условиях. Т.е. кто-нибудь скопирует и напишет потом — а вот он наврал, ничерта это не работает. Работает! Надо просто головой думать когда делаешь что то.
В human-friendly его превращает браузер.
HTML является частным случаем XML. С данными в XML вопросов же нет, да? JSON тоже самое, в принципе.
Разница в том, что HTML содержит дополнительную служебную информацию.
Повторюсь — нет никакой принципиальной разницы в каком формате у нас возвращаются данные.
Если убрать из HTML всю служебку мы получим чистый контент разбитый семантически на логические блоки, который мы ровно точно так же можем распарсить в то, что нам требуется.
По факту парсинг JSON, XML, HTML или чего-либо отличается только наличием библиотек или встроенных инструментов.
API запрос может идти через HTTP.
HTTP это протокол передачи данных, а какие там уже данные — вопрос третий.
Хотя эта суть не очень относится к теме поста.
Разруливание подобной ситуации к масштабированию имеет косвенное значение. Даже, скорее, это бизнес-задача, а никак не про масштабирование. В пример могу привести wikia — у моей игры есть там неофициальная вики, и люди жаловались о потере одновременных правок. Это реальная проблема была. Даже в таком крупном проекте решена плохо.
Как я уже говорил — в случае оптимизации и разноса по большому количеству серверов пути API будут одни и те же, хотя даже сервера могут находится в разных странах. И вот возврат этой ошибки — как раз сделает API.
Как вы сказали дальше — универсальных решений нет. Именно по этому это уже не легко. Нет универсального решения -> надо подключать мозг.
Я могу написать сотни статей с конкретными юзкейсами. Но мне это не интересно :-) Да и смысла осоьбо не имеет, т.к. каждый новый случай, ваш случай, уже всё равно не в один из них не уложится. Как видишь даже с твоим вопросом я сразу предложил несколько вариаций, в зависимости от контекста. А таких ситуаций бесконечное множество.
Если нашим продуктом является, например, сайт.
Пользователь октрыл сайт (SPA), браузер делает запрос к API и выводит данные. Как бы это настолько очевидно что не пользователь лично делает этот запрос, что мне казалось излишнем подобное комментировать.
Если нашим API воспользовался сторонний разработчик — он либо получил данные к себе, либо вывел их в приложение конечному пользователю. Так или иначе пользователь увидел в продаже нужный ему чайник и купил его. У вас или через партнёра — деньги вы имеете в любом случае.
Дальше часть не очень понятна. В тексте статьи и так сказано что возвращать необходимо требуемыми способами.
В качестве интересного примера с внешней API можно взглянуть на Eve online, для которых делают вплоть до игровых онлайн казино.
В них играют пользователи, но, что бы играть, нужна платная подписка. В итоге сторонние разработчики за бесплатно продвигают твой товар (игру).
Если продолжаем про игры. Можно глянуть, например, Neverwinter. Из браузера ты можешь управлять отправкой помощников на задания. В WOW ты можешь мониторить аукцион. Таких примеров очень много.
Конечно, сразу определить какие действия разрешить — сложно, но вот выдавать ряд информации сразу возможно (например ситуацию на рынке).
Как я уже сказал, это не просто полезно, а приносит деньги владельцем проектов.
Это иллюстрация преимущества контента. Непосредственно к разработке API пример не относится.
Вопрос не достаточно полный что бы корректно ответить. Так же, зависит от информации, которую модифицируем. Приведу несколько примеров. Коль назвали монгу, применимо к ней.
Общее золото в игре. Вместо выборки и установки нового значения мы можем использовать $inc — в таком случае обе операции, не зависимо от порядка, пройдут успешно. Отвечая на вопрос, что же делать если золото ушло в минус после подобной операции — откат софтварной транзакции и вывод информации о недостатке золота.
В случае если это некая статья, на подобии википедии, то тут мы можем применить несколько вариантов.
По какой-то причине в технически сложных статьях, как мне кажется, всегда отмечают что это всё просто и легко.
Так вот это не просто и не легко, и умеет это не такая большая доля разработчиков на самом деле.
В случае если у вас всё окружение умеет подобное и применяет — это мега круто. Значит вам удалось попасть в общество экспертов.
В чем посредственность — хотелось бы услышать конкретно. Что не так? Как лучше? Я рад учиться, если ошибся где то.
Честно говоря даже не предполагал что из-за шутки будут сливать хороший пост и карму.
Ладно бы откомментировал кто — ты не прав, на самом деле делать надо вот так и вот так.
После вот такой вот фигни никакого желания писать сюда нету, на самом деле.
Уже скоро (относительно).
Объединять стоит только библиотеки, которые необходимы для отрисовки, иначе лучше отложить их загрузку.
Насчет публичных CDN — тут надо принимать решение по безопасности. Если произойдет подмена скрипта на публичном CDN на вирусный (с кейлоггером, например), то ваш сайт пострадает. Тут все зависит от сайта и от уровня паранойи :-)
Как ты себе представляешь, например, онлайн стриминг в веб 1.0? С перезагрузкой страниц и всем прочим. Вот тут и начинаются проблемы.
На страницы не спроста лепят кучу скриптов и остальных вещей. Вовсе не для того, что бы просто навесить. Их вешают что бы у тебя были взаимодействия моментальные. Что бы ты мог лайк поставить, увидеть чужие лайки здесь и сейчас, комментарий написать и так далее.
Для ряда сайтов, конечно, самых простых, такое подойдет от части, но — если посмотришь на описание, то от самого сайта не всё зависит, но так же играет роль его расположение и т.п.