Весьма и весьма неоднозначная статья: вроде и есть полезное, а вроде и уйма пробелов. Производительность графовых БД для отдельных случаев даже лучше чем у релационных, так как поиск вершины на другом конце ребра это операция O(1), что значительно лучше чем поиск по FK. Да и насчет деления NoSQL: та же OrientDB является мультипрадигмной: хочешь Graph — без проблем, хочешь документную БД — элементарно, хочешь реляционную — тоже здесь (правда SQL далек от SQL92), ну а так же Key-Value. А если к этому добавить обертку типа Orienteer, то и бэкэенд для мобильного приложения или сайта без единого кода готов.
Я это к тому, что реляционные БД уходят на второй план так как не могут предоставить разработчикам «полный стэк» в сравнении с NoSQL разработками.
Есть страница(сайт), где время от времени появляются новые элементы. Хотелось бы чтобы подсказки показывались пользователю лишь раз и если он зашел второй раз и добавилась лишь одна кнопка, то все проигрывалось бы только для этой новой кнопки?
В том то и дело, что хероку при перезапуске все что пользователь «наделал» стирается полностью. Там если нужна персистентность, то надо использовать внешние ресурсы. А мы в Orienteer, естественно, хотели бы, чтобы при остановке ноды данные пользователя не пропадали. В docker есть volume фишка, но когда у тебя облако, то возникает проблема переноса volume на другую ноду по необходимости. Обычно люди через ZFS решают, но хотелось бы что-нибудь из коробки…
Если не секрет, то как решаете вопрос с персистентностью контейнеров? Или пока с этим не заморачивались и нода «стирается», ну или контейнер привязыватеся к той или иной ноде?
Хмм… А вот на Orienteer можно и вообще за 5 минут такое сделать причем вообще не кодируя. Но тема да — интересная… Какие есть ограничения у фреймворка? Т.е. какие задачи гарантировано не стали бы решать AllCountsJS?
А на что перешли? Мы вот на Apache Wicket — все тоже самое, но ооочень быстро. Ну и в Wicket можно докапаться до таких глубин, если надо — что Vaadin'у и не снилось.
Слабо понимаете как работают венчурные фонды. Между ними и реальными спекулянтами есть одна большая разница: последние четко знают где купить и где/когда конкретно продать. В отличии от них венчурные фонды в общем случае не знают куда придет проект: да они строят планы когда и за сколько можно продать, но это вилами по воде. Они вкладываются помимо денег своим опытом, инфраструктурой и связями чтобы совместно увеличивать стоимость компании.
Сам еще не перешел на Java 8, но глядя на это все стало весьма интересно: а кто-нибудь делал замеры производительности Stream API vs. for/foreach. И есть ли какие-то общие рекомендации когда и что лучше использовать.
Лучше бы поработали над «контекстностью» своей рекламы: уж очень неприятно, что они вставляют трейлеры для «кровавых фильмов» во время просмотра детьми мультиков…
Почему это невалидный? Вполне себе даже валидный. Но если вы намекаете на то, что контент надо хранить как единую сущность: то да — надо бы обернуть в CDATA.
К прошлому вашему посту не получилось вовремя дописать, так как его быстро закрыли.
Держите (с прошлого поста возможно что-то уже устарело):
1) Страницу «Как это работает» надо переработать полностью. Во-первых, из нее ничего не понятно, во-вторых графическое форматирование никуда не годится так как даже непонятно как читать блоки: слева на право или сверху вниз.
2) Стоит «локализировать» картинки. Зачем в России видеть Macy's и прочие магазины абсолютно не релевантные.
3) «О сервисе» в главном меню смотрится немного «странно» — особенно если взглянуть на содержание. Как минимум стоит отправить правее «как это работает»
4) Почти на каждом шагу повторения: 30%… 30%, купоны… купоны, сервис… сервисы… Режет глаза. Расслабьтесь, выпейте кофе и напишите легкий и красивый текст.
5) Блок «Мы в фейсбук» пустой
6) Стандартный блок с твитами в правом нижнем углу смотрится весьма странно… Акцент бы с него убрать как минимум, а как максимум вообще убрать:)
7) Что за трилистник в купонах у каждого лого? Я так понял это знак «избранных». В любом случае этот функционал у вас сейчас не работает.
8) Я нахожусь в США. Почему у меня по умолчанию Россия? Смотрите на языковую локализацию, а не на гео?
9) Вот с этим точно надо что-то сделать: при навигации по «купонам» часто одну страницу полностью занимает одно «лого»/один магазин. Отталкивает… Вам бы как-нибудь групировать купоны по магазинам.
10) Бледнозеленый на «бело-желтой» зебре смотрится отвратно.
11) Некоторые картинки на главной не центрированы, а эффект приближения обрезает название. Чуть поаккуратнее надо бы.
12) Ну и админку с дефолтного пути перенесите как минимум:)
Вопрос: зачем намеренно ограничивать себя? Если выбрали lisp/schema подобный синтаксис то почему бы не воспользоваться существующими библиотеками для этого? Некоторые из перечисленных ниже «java schema/lisp» библиотек хорошо интегрируются во внешние приложения.
1. Сlojure
2. JScheme
3. JLLL
4. Kawa
5. Помню была отличная библиотека skij от IBM, но что-то сейчас концов не нахожу…
Если замыкания, лямбда и прочее не нужно, то не факт что не понадобится…
Знаю, что с полученной прибыли на US площадках необходимо платить налоги. Как у вас с этим обстоят дела? Осуществляете ли помощь в оформлении налоговых документов?
Используем для того же OrientDB (http://www.orientechnologies.com/orientdb/) и Orienteer (http://orienteer.org/). Не без собственных костылей, но зато можно использовать преимущества OrientDB: key-value/document/graph DB/RDBM в одном флаконе + масштабируемость.
За наводку спасибо! Весьма интересно особенно «синтаксический сахар» в InfluxDB SQL для временных данных…
Если кратко, то не парьтесь:( Я им 5 лет назад на форуме провел подробный анализ их вебинтерфейса со всеми багами (покрайней мере мной найденными). Вы думаете они за это хоть что-то исправили? Ни одной!!!
Я это к тому, что реляционные БД уходят на второй план так как не могут предоставить разработчикам «полный стэк» в сравнении с NoSQL разработками.
Есть страница(сайт), где время от времени появляются новые элементы. Хотелось бы чтобы подсказки показывались пользователю лишь раз и если он зашел второй раз и добавилась лишь одна кнопка, то все проигрывалось бы только для этой новой кнопки?
Если нет пока — могу помочь. У вас хороший юзкейс для разрабатываемого мной ПО.
Держите (с прошлого поста возможно что-то уже устарело):
1) Страницу «Как это работает» надо переработать полностью. Во-первых, из нее ничего не понятно, во-вторых графическое форматирование никуда не годится так как даже непонятно как читать блоки: слева на право или сверху вниз.
2) Стоит «локализировать» картинки. Зачем в России видеть Macy's и прочие магазины абсолютно не релевантные.
3) «О сервисе» в главном меню смотрится немного «странно» — особенно если взглянуть на содержание. Как минимум стоит отправить правее «как это работает»
4) Почти на каждом шагу повторения: 30%… 30%, купоны… купоны, сервис… сервисы… Режет глаза. Расслабьтесь, выпейте кофе и напишите легкий и красивый текст.
5) Блок «Мы в фейсбук» пустой
6) Стандартный блок с твитами в правом нижнем углу смотрится весьма странно… Акцент бы с него убрать как минимум, а как максимум вообще убрать:)
7) Что за трилистник в купонах у каждого лого? Я так понял это знак «избранных». В любом случае этот функционал у вас сейчас не работает.
8) Я нахожусь в США. Почему у меня по умолчанию Россия? Смотрите на языковую локализацию, а не на гео?
9) Вот с этим точно надо что-то сделать: при навигации по «купонам» часто одну страницу полностью занимает одно «лого»/один магазин. Отталкивает… Вам бы как-нибудь групировать купоны по магазинам.
10) Бледнозеленый на «бело-желтой» зебре смотрится отвратно.
11) Некоторые картинки на главной не центрированы, а эффект приближения обрезает название. Чуть поаккуратнее надо бы.
12) Ну и админку с дефолтного пути перенесите как минимум:)
Удачи со стартапом!!!
Но если хочется просто попрактиковаться в реализации интерпретатора «языка-первопроходца», то тогда причины полностью понятны и поддерживаю!:)
1. Сlojure
2. JScheme
3. JLLL
4. Kawa
5. Помню была отличная библиотека skij от IBM, но что-то сейчас концов не нахожу…
Если замыкания, лямбда и прочее не нужно, то не факт что не понадобится…
За наводку спасибо! Весьма интересно особенно «синтаксический сахар» в InfluxDB SQL для временных данных…