>FileAPI.event.on(input, «change», function (){… });
Мне кажется, здесь лучше поменять местами первые два параметра, по аналогии как метод .on() сделан у jQuery.on(). Слово «on» как бы говорит — «на событие инпута реакция такая-то» — .on('change', input, fn)
>Безусловно, библиотеки отличаются функциональностью
Было бы полезно, если бы вы добавили в статью табличку со сравнением функциональности библиотек и сложность API. Статья от этого только выиграет, а то сейчас только на основании результатов тестов быстродействия выбор осуществить всё-таки сложновато.
В телекоме используется для роутинга пакетов (как я понял, для этого Эрланг и разработали), в серверах приложений (слышал, что кое-где на эрланге пишут сервер для онлайн игры). В общем, везде, где нужно что-то быстро обработать поточно, причём массово, высокопараллельно и супернадёжно.
Не совсем так. Подвинуть посредников будет крайне сложно. Например, Гугл сейчас даёт рекламодателям не столько способ донесения рекламного послания до потребителя, сколько сопутствующий сервис — таргетирование рекламы (а для этого у гугла годами собираемая гигантская база), аналитика по рекламе, всякие важные настройки, которые очень важны для рекламодателей. Современная реклама — это не просто баннер.
При всём уважении к open-source сообществу и его важному вкладу в современное общество, но всё-таки создать большой сложный open-source продукт сейчас крайне тяжело (см. например habrahabr.ru/post/194628/). Просто не найдётся столько человеко-часов, чтобы разработать подобную гугл систему (хотя бы на 10%), которая бы удовлетворила рекламодателей. Разве что краудфандинг может помочь…
Сделайте-сделайте! Можно будет и историю с отменой сделать.
Только хотел предложить сделать кнопку «предыдущий кот», чтобы можно было вернуть результат предыдущей генерации. А то столько чудесных котиков пролистывается, пока жмякаешь на кнопку «Generate!»…
А ещё слайдеры для кастомной настройки кота. Ведь в коде много рандомных параметров — вот все рандомы в слайдеры переделать хорошо бы.
Разве? Автор не указал, какую именно систему исследовал. Первый скриншот окна логина как бы намекает на десктоп.
Но в любом случае, я видел такие системы мобильного дневника — с клиентом в виде программы.
Я занимался разработкой подобной системы как раз в 2009 году (когда это ещё не было трендом:). В момент, когда начал разрабатывать, подобные системы были только в Екатеринбурге и Казани, даже в Москве ещё не было.
Разрабатывал на базе веб-технологий, на php+mysql. По интерфейсу получилось гораздо лучше, чем все эти десктоп-клиенты, плюс нет проблемы с апдейтами.
Хотел сделать несколько комментариев к статье.
>Очень много школ в нашей стране уже переведены на электронные системы контроля успеваемости учащихся, а остальные подтягиваются к этой планке
Сейчас уже в нашем городе практически все школы подключены к подобной системе. Когда мы запустились, мы в нашем городе были первыми, но уже через полгода появились 5 (пять!) конкурентов, причём некоторые из них с приличными бюджетами и административным ресурсом — внедрять их шклоы вынуждает администрация города.
>Директора и учителя в восторге
На самом деле, я столкнулся с тем, что не все директора хотят себе такую систему, хотя мы предлагали оплачивать время заполняющих. Просто то ли боялись чего-то, то ли «намекали», что просто так не интересно внедрять. Учителя же боялись этого, как огня — очень мало из них кто умеет хоть чуть-чуть за компьютером работать (по крайней мере, из тех, с кем мы столкнулись). Интерфейс у нас был максимально приближён к внешнему виду классного журнала, лишние движения делать не надо было.
>Через раз работающие СМС сервисы оповещения об оценках, а то и вовсе не работающие.
Мы использовали надёжного партнёра по рассылке смс — один из ведущих sms-шлюзов. Удобно, хотя и дороговато. А вот некоторые из конкурентов использовали обычный сотовый для рассылки, рассылали через программу.
В общем, мы подключили две школы и три колледжа, и всё загнулось (по разным причинам, в том числе перечисленным выше). А потом развивать стало невыгодно — конкурировать с современными высокобюджетными системами невозможно.
Будут вопросы по реализации или организации — спрашивайте, отвечу.
ой, точно, прошу прощения… Ну, надеюсь, JekFdrv тоже прочитал моё сообщение.
Насчёт FabricJs — он больше подходит для рисования на канвасе, для создания интерактива на странице. В общем-то, флэш, вы правы. Тоже нужная вещь, просто инструмент для другой задачи.
Следили за интересной чередой реализации солнечной системы на canvas-е? habrahabr.ru/post/163703/ — «История одного хабраспора» habrahabr.ru/post/163893/ — то же самое на LibCanvas habrahabr.ru/post/163893/#comment_5852425 реализация на FabricJs
Не совсем так. Изначально функциональность нынешнего Atom-а была внутри библиотеки LibCanvas. Уже после автор вынес её в отдельную библиотеку, чтобы было удобнее развивать и то, и другое. И, имхо, для большого js-проекта в любом случае нужна какая-нибудь util-библиотека. Prototype, underscore, отчасти jQuery. Или вот Atom.
А насчёт высокого порога — вам нужна хорошая игра или простота? Но, с другой стороны, я сам ничего серьёзного на ней не делал, но библиотека показалась очень мощной. Поэтому и указал её вам для полноты, вдруг вы не сталкивались. Но, похоже, вы уже смотрели её. Вам виднее, конечно.
Есть ещё FabricJs, но не знаю, она скорее всего не подойдёт для большинства игр.
А зачем возвращать вновь созданную сущность? Ведь клиент только что передал все данные, которые были необходимы для создания сущности, значит, у клиента они и так есть. Разве что вернуть айдишник, как выше отметил BenderRodriguez. Или если сервер дозаполняет некоторые важные поля сущности, тогда можно рассмотреть — либо вернуть только их (для уменьшения трафика), либо всё-таки возвращать всю сущность (для удобства).
>Мне кажется, что наше обсуждение больше переходит в холливар. Предлагаю перейти в личку.
А зря, мы ведь читаем и учимся. :) Хорошо видеть две стороны одной проблемы. За то и люблю хабр, что комменты к статьям очень ценные бывают.
Я где-то читал, что файнридер разбивает картинку буквы на отдельные примитивы — окружности, дуги, линии, и по библиотеке символов находит ближайшие похожие буквы.
Я вот думаю подобную игрушку подарить отцу, он как раз готовится выйти на пенсию — времени будет достаточно (между рыбалками:). Сам он достаточно продвинутый для того, чтобы скачать модель, да и поднастроить принтер тоже сможет отвёрткой да молотком. Может, и моделирование осилит. Что думаете о таком применении?
Вообще-то, есть разные человеческие расы: ru.wikipedia.org/wiki/Раса.
Хотя бы известная классификация — европеоиды, монголоиды и негроиды. Или некоторые говорят о расах по разным группам крови.
Хотя существуют разные классификации (http://ru.wikipedia.org/wiki/Расовые_классификации), и некоторые даже отрицают существование рас, но на мой взгляд, это больше в угоду политкорректности.
Но о чём вы говорите, в принципе, понятно. Но категорично заявлять «Нет понятия человеческая раса» некорректно.
Мне кажется, здесь лучше поменять местами первые два параметра, по аналогии как метод .on() сделан у jQuery.on(). Слово «on» как бы говорит — «на событие инпута реакция такая-то» — .on('change', input, fn)
>Безусловно, библиотеки отличаются функциональностью
Было бы полезно, если бы вы добавили в статью табличку со сравнением функциональности библиотек и сложность API. Статья от этого только выиграет, а то сейчас только на основании результатов тестов быстродействия выбор осуществить всё-таки сложновато.
При всём уважении к open-source сообществу и его важному вкладу в современное общество, но всё-таки создать большой сложный open-source продукт сейчас крайне тяжело (см. например habrahabr.ru/post/194628/). Просто не найдётся столько человеко-часов, чтобы разработать подобную гугл систему (хотя бы на 10%), которая бы удовлетворила рекламодателей. Разве что краудфандинг может помочь…
Только хотел предложить сделать кнопку «предыдущий кот», чтобы можно было вернуть результат предыдущей генерации. А то столько чудесных котиков пролистывается, пока жмякаешь на кнопку «Generate!»…
А ещё слайдеры для кастомной настройки кота. Ведь в коде много рандомных параметров — вот все рандомы в слайдеры переделать хорошо бы.
Но в любом случае, я видел такие системы мобильного дневника — с клиентом в виде программы.
Разрабатывал на базе веб-технологий, на php+mysql. По интерфейсу получилось гораздо лучше, чем все эти десктоп-клиенты, плюс нет проблемы с апдейтами.
Хотел сделать несколько комментариев к статье.
>Очень много школ в нашей стране уже переведены на электронные системы контроля успеваемости учащихся, а остальные подтягиваются к этой планке
Сейчас уже в нашем городе практически все школы подключены к подобной системе. Когда мы запустились, мы в нашем городе были первыми, но уже через полгода появились 5 (пять!) конкурентов, причём некоторые из них с приличными бюджетами и административным ресурсом — внедрять их шклоы вынуждает администрация города.
>Директора и учителя в восторге
На самом деле, я столкнулся с тем, что не все директора хотят себе такую систему, хотя мы предлагали оплачивать время заполняющих. Просто то ли боялись чего-то, то ли «намекали», что просто так не интересно внедрять. Учителя же боялись этого, как огня — очень мало из них кто умеет хоть чуть-чуть за компьютером работать (по крайней мере, из тех, с кем мы столкнулись). Интерфейс у нас был максимально приближён к внешнему виду классного журнала, лишние движения делать не надо было.
>Через раз работающие СМС сервисы оповещения об оценках, а то и вовсе не работающие.
Мы использовали надёжного партнёра по рассылке смс — один из ведущих sms-шлюзов. Удобно, хотя и дороговато. А вот некоторые из конкурентов использовали обычный сотовый для рассылки, рассылали через программу.
В общем, мы подключили две школы и три колледжа, и всё загнулось (по разным причинам, в том числе перечисленным выше). А потом развивать стало невыгодно — конкурировать с современными высокобюджетными системами невозможно.
Будут вопросы по реализации или организации — спрашивайте, отвечу.
Насчёт FabricJs — он больше подходит для рисования на канвасе, для создания интерактива на странице. В общем-то, флэш, вы правы. Тоже нужная вещь, просто инструмент для другой задачи.
Следили за интересной чередой реализации солнечной системы на canvas-е?
habrahabr.ru/post/163703/ — «История одного хабраспора»
habrahabr.ru/post/163893/ — то же самое на LibCanvas
habrahabr.ru/post/163893/#comment_5852425 реализация на FabricJs
А насчёт высокого порога — вам нужна хорошая игра или простота? Но, с другой стороны, я сам ничего серьёзного на ней не делал, но библиотека показалась очень мощной. Поэтому и указал её вам для полноты, вдруг вы не сталкивались. Но, похоже, вы уже смотрели её. Вам виднее, конечно.
Есть ещё FabricJs, но не знаю, она скорее всего не подойдёт для большинства игр.
libcanvas.github.io/ и поищите статьи по теме на хабре.
А зря, мы ведь читаем и учимся. :) Хорошо видеть две стороны одной проблемы. За то и люблю хабр, что комменты к статьям очень ценные бывают.
Хотя бы известная классификация — европеоиды, монголоиды и негроиды. Или некоторые говорят о расах по разным группам крови.
Хотя существуют разные классификации (http://ru.wikipedia.org/wiki/Расовые_классификации), и некоторые даже отрицают существование рас, но на мой взгляд, это больше в угоду политкорректности.
Но о чём вы говорите, в принципе, понятно. Но категорично заявлять «Нет понятия человеческая раса» некорректно.