Немного не в тему, но меня давно мучает вопрос про таймауты. Как организуется с ними работа в Фантоме. К примеру, я делаю чтение с жесткого диска. После запроса данных с жёсткого диска, но до их полного получения машина засыпает. Допустим, после пробуждения, стейтлесс асинхронность и транзакции позлят продолжить чтение файла с того места где программа остановилась. С точки зрения программы прошли доли секунды (вернее, несколько инструкций процессора), но если взять таймаут как разницу времени, то он может оказаться достаточно большим, чтобы решить, что в процессе чтения данных есть проблемы.
Как предполагается отличать проблемный (долгий) таймаут, от таймаута выспавшейся программы?
Забыл упомянуть о плюсах и минусах Noodl.
Плюсы:
* Большая гибкость. Многое можно сделать без программирования.
* Поддержка жестов
* Можно визуально проследить, события влияют на объекты
Минусы:
* Нет готовых шаблонов, склеивая которые можно получить приложение.
* Нет ни каких инструментов для создания и использования ранее созданных проектов в новых проектах. Т.е. нет функций копипасты и импорта. К счастью, проекты в формате json, поэтому можно пользоваться обычным текстовым редактором.
Другими словами, если нужно попробовать интерактивные элементы интерфейса с анимацией, которые ещё ни кто не реализовал, то стоит попробовать воспользоваться Noodl. Но если нужно множество стандартных элементов интерфейса, то стоит поискать что-нибудь другое.
Вы так стремитесь побыстрее рассказать, что всегда забываете дать попробовать. Где ссылки на сайт, на пример приложения и на пример данных? Нам момент публикации комментария их нет.
А вообще у меня есть претензия к databoom. Сервис позиционирует себя инструмент прототипирования. Но если для fluidui вполне нормально, что труд дизайнера лишь образец, а фронтенд разработчик напишет полностью свой код, то для работы с данными это не нормально, что этот код нельзя использовать повторно и приходится полностью его переписывать, причём под другую базу данных. Как следствие, проще написать прототип сразу под нужную базу данных, чем тратить время на databoom. Например, у QuickBlox таких проблем нет, сначала прототип, а потом приложение на той же платформе.
А ведь у databoom есть практически всё, чтобы использовать его для создания приложений, кроме правильной аутентификации. Ну нельзя сделать такое приложение, в котором можно было бы разместить кнопку «Зарегистрироваться», т.к. пользователей можно заводить только в админке databoom. Даже если пользователей ограниченное количество, и завести их вручную, то нет ни какого разделения доступа к данным. А это значит, что для каждого пользователя нужно заводить свою коллекцию, опять же вручную. И, самое главное, у пользователя нет ни какой возможности сделать запись своей коллекции доступной другому пользователю приложения.
Лично я понял это так. Браузер анализирует посещаемые страницы. И определяет ваши интересы (теги). К примеру, вы посещаете сайты с танками, значит на вас вешается тег «танк». Браузер заранее скачивает (в свободное от основной работы время) рекламу танков предоставляемую гуглом и другими операторами рекламы. Когда вы посещаете сайт с рекламными блоками, реклама не грузится, а подставляется из рекламного кеша. Вы понимаете, что реклама танков вам не интересна, всё равно купить не сможете, поэтому снимаете тег «танк» (и другие теги тоже) и вешаете тег «велосипеды со скидкой 70% в Саратове».
Как предполагается отличать проблемный (долгий) таймаут, от таймаута выспавшейся программы?
Плюсы:
* Большая гибкость. Многое можно сделать без программирования.
* Поддержка жестов
* Можно визуально проследить, события влияют на объекты
Минусы:
* Нет готовых шаблонов, склеивая которые можно получить приложение.
* Нет ни каких инструментов для создания и использования ранее созданных проектов в новых проектах. Т.е. нет функций копипасты и импорта. К счастью, проекты в формате json, поэтому можно пользоваться обычным текстовым редактором.
Другими словами, если нужно попробовать интерактивные элементы интерфейса с анимацией, которые ещё ни кто не реализовал, то стоит попробовать воспользоваться Noodl. Но если нужно множество стандартных элементов интерфейса, то стоит поискать что-нибудь другое.
А вообще у меня есть претензия к databoom. Сервис позиционирует себя инструмент прототипирования. Но если для fluidui вполне нормально, что труд дизайнера лишь образец, а фронтенд разработчик напишет полностью свой код, то для работы с данными это не нормально, что этот код нельзя использовать повторно и приходится полностью его переписывать, причём под другую базу данных. Как следствие, проще написать прототип сразу под нужную базу данных, чем тратить время на databoom. Например, у QuickBlox таких проблем нет, сначала прототип, а потом приложение на той же платформе.
А ведь у databoom есть практически всё, чтобы использовать его для создания приложений, кроме правильной аутентификации. Ну нельзя сделать такое приложение, в котором можно было бы разместить кнопку «Зарегистрироваться», т.к. пользователей можно заводить только в админке databoom. Даже если пользователей ограниченное количество, и завести их вручную, то нет ни какого разделения доступа к данным. А это значит, что для каждого пользователя нужно заводить свою коллекцию, опять же вручную. И, самое главное, у пользователя нет ни какой возможности сделать запись своей коллекции доступной другому пользователю приложения.