Приходилось (да и приходится по сей день) иметь дело с проектом, который переехал с MSSQL на MySQL, когда упёрся в ограничения бесплатной версии первого. Из замеченных на практике неудобств MySQL: отсутствие filtered index-ов, отсутствует insert/update + output, дефолтный utf8 на самом деле урезанный, некоторая глючность Workbench, дотнетовский провайдер в сочетании с EntityFramework генерит скрипты для миграции, которые приходится немного подправлять руками. Отдельно кусается мучительно медленное добавление столбцов в большие таблицы, но тут я не могу с уверенностью сказать, лучше ли с этим обстоит дело в MSSQL, т.к. на одинаковых объёмах не сравнивал. Некоторые запросы после переезда начинают работать заметно медленнее.
Другое дело, что оправдывает ли всё это тех денег, которые просит MSSQL — вопрос хороший. Но для проектов, влезающих в Express-версию, я явно предпочту его.
Буквально на прошлой неделе наткнулся на очень милую граблю: HtmlAgilityPack при попытке распарсить одну невалидную html-ину улетел в stack overflow, чем и положил весь процесс =\ Никто не в курсе, как с обработкой кривых данных из реального веба у конкурентов (в основном интересует AngleSharp, как наиболее живой и вкусный на вид)?
Обязательно =) Но для начала и просто вертикальные вкладки были бы серьёзным поводом обратить внимание на Я.Браузер. А если их потом трансформируют в дерево или придумают какой-либо иной удобный механизм группировать табы «по сессии», будет совсем шикарно.
Кстати да. Тоже натыкался на это ограничение (правда уже не помню в каком именно браузере), когда нужно было в целях тестирования работать с сайтом параллельно из-под нескольких разных аккаунтов. Приходилось доставать запасной браузер, а там IE со всем связанным с ним геморроем… В общем, отдельные сессии для отдельных инкогнито окон — это добро.
Исходя из базовой идеи, что сайты – это приложения, мы изначально ориентировались на группировку по домену
Нет, это так не работает =( По крайней мере для меня было бы удобнее умным образом группировать вкладки, имеющие общий «источник». Дело в том, что вкладки в браузере открываются не просто так, а ради достижения конкретной цели. Чаще всего отправной точкой является какой-то запрос в гугле. Или страница со списком цен на товар в яндекс.маркете. Или ещё что-то, хоть лента новостей какая-нибудь. Суть в том, что все вкладки, открытые с этой страницы, равно как и все вкладки, открытые с них, логически являются одной группой — это может быть куча разных сайтов, но конкретные страницы этих сайтов посвящены решению общей задачи. Появляется новая задача — делаем жест мышью для новой вкладки и растёт новая группа.
Очень классно это соображение визуализировал автор аддона Tree Style Tab для FF. Какие-то детали его решения могут быть неидеальными, но по-моему сама идея поистине великолепна, и я был бы очень рад увидеть в Яндекс.Браузере работу с вкладками, вдохновлённую чем-то подобным.
Я надеюсь, опция размещения их слева или справа тоже входит в рассматриваемый вариант =) Негусто нынче с браузерами, которые такое умеют… А фича чудовищно удобная.
Ну я и не заявляю категорично, что делать иначе — бред, или что такое решение единственно правильное (или вообще правильное). Я просто отметил, что у размещения панели снизу есть свои плюсы. По большому счёту, мне на данный момент вообще без разницы где она расопложена, т.к. я в каком-то смысле тот самый «средний пользователь», для которого закладок не было в первом релизе ХромоОперы =) Двухуровневый Speed dial для меня лично оказался более удобным.
К слову, про исследования. А вы не рассматривали идею открыть публичный uservoice? Обычно это намного более удобный способ структурирования, приоритизирования и обсуждения пожеланий, чем парсинг жалоб из комментариев к постам. Причём удобный как для разработчиков, так и для юзеров.
Кстати, у меня диаметрально противоположное мнение насчёт расположения панели Speed dial / Bookmarks в нижней части окна: это окно открывается по жесту мышью вниз, поэтому мне удобнее видеть панель снизу.
Возможно я не репрезентативен, но у меня чаще встречаются вопросы в духе «есть ли смысл идти к остановке» или «к остановке какого автобуса топать», и возникают типично перед выходом, а не в пути. Для подобных кейсов браузерная версия была бы очень в тему.
«Уии, вертикальные табы!» — подумал я, увидев на скриншоте возможность прилепить табы налево или направо. «Блин, а как теперь отключить сжирающие кучу места превьюшки?» — опечалился, поставив браузер.
Also, если зафулскринить браузер на правом мониторе, то менюшка по кнопке V отображается в правом верхнем углу левого монитора. И ещё по куче интерфейсных деталей хочется накидать фидбэк. Лучше сюда или на форум?
Also #2: есть какой-нибудь блог или иное место, где можно было бы следить за развитием браузера? Проект потенциально интересный, я бы не отказался одним глазом поглядывать на ченджлоги.
Видно, что над внешним видом постарались, и местаим выглядит действительно симпатично. Но, к сожалению, по функционалу для моих юз-кейсов это абсолютнейший промах. Ключевая часть браузера — табы — работает совсем не так как хочется.
Как и во всех остальных современных браузерах, панель вытянута горизонтально, что ставит крест на идее комфортной работы с большим количеством табов. Таскбар у меня расположен слева на левом мониторе, браузер же обычно на правом, и табы хочется прилепить направо, чтобы упирались в край экрана.
Теперь табы ещё и отжирают дополнительное место по вертикали в дополнение к заголовку.
Группировка табов работает нелогично и в такой реализации я для себя вижу в ней больше вреда чем пользы. Как обычно плодятся вкладки: запрос в гугле — открываем пачку вкладок с него — оставляем нужные. Новая вкладка — ещё один запрос — снова пачка вкладок. И т.д. Даже в виде линейного списка эти гугловские вкладки выступают своего рода визуальным разделителем «поисковых сессий». Авторы аддона Tree style tab для FF пошли дальше и воплотили этот концепт в виде дерева — и это самая классная идея организации табов, что я когда-либо видел. Что же делает группировка вкладок по доменам? Просто берёт и ломает границы разных поисковых сессий, смешивая их в одну большую кучу.
Пользуясь случаем, баг: клик по вкладке не работает, если кликать на самый нижний пиксель, что как раз дико удобно делать, поскольку там заканчивается экран.
А можно всё-таки немного сравнения с конкурентами? =) Что-то же послужило причиной написания своего решения, интересно было бы узнать, чем именно не устроил тот же Jurassic. Когда я где-то год назад присматривался к JS-движкам, остановился именно на нём: он показался самым зрелым и активно развивающимся. (Правда потом пришёл к выводу, что для моих нужд удобнее просто взять и заюзать PhantomJS, но это совсем другая история.)
Вполне возможно, что вы правы и in the long run переписать всё на DataFlow было бы оптимальнее. С другой стороны, в процессе пришлось узнать много интересного про мемори барьеры и иже с ними, так что как минимум академический смысл во всей этой затее присутствует.
Пользуясь случаем: а в DataFlow есть аналог очереди с приоритетами? Беглый просмотр неймспейса на MSDN результата не дал.
Он не то чтобы принципиально не угодил, я с интересом к нему присматриваюсь. Но пока сложилось впечатление, что оптимальное использование DataFlow — выстроить на нём весь пайплайн обработки даннных, что немного оверкилл для моих целей.
Я бы все-таки отказался от new TItemQueue() в сторону защищенного конструктора.
Мысль про protected конструктор интересная. Явно проще и элегантнее, чем для передачи пачки параметров писать враппер, реализующий IProducerConsumerCollection. Я подумаю ;)
Вместо TaskCompletionSource в _awaiterQueue лучше хранить обобщенный делегат вида bool ItemConsumer<TItem&rt;(TItem value). Это позволит очень просто реализовать операцию TakeFromAny.
Я думаю в направлении interface IConsumer с похожим методом — навскидку кажется, что так реализация TakeAnyAsync() получится немного чище. Но пока не берусь утверждать как будет на самом деле, идея пока на стадии обкатывания в голове.
Другое дело, что оправдывает ли всё это тех денег, которые просит MSSQL — вопрос хороший. Но для проектов, влезающих в Express-версию, я явно предпочту его.
Нет, это так не работает =( По крайней мере для меня было бы удобнее умным образом группировать вкладки, имеющие общий «источник». Дело в том, что вкладки в браузере открываются не просто так, а ради достижения конкретной цели. Чаще всего отправной точкой является какой-то запрос в гугле. Или страница со списком цен на товар в яндекс.маркете. Или ещё что-то, хоть лента новостей какая-нибудь. Суть в том, что все вкладки, открытые с этой страницы, равно как и все вкладки, открытые с них, логически являются одной группой — это может быть куча разных сайтов, но конкретные страницы этих сайтов посвящены решению общей задачи. Появляется новая задача — делаем жест мышью для новой вкладки и растёт новая группа.
Очень классно это соображение визуализировал автор аддона Tree Style Tab для FF. Какие-то детали его решения могут быть неидеальными, но по-моему сама идея поистине великолепна, и я был бы очень рад увидеть в Яндекс.Браузере работу с вкладками, вдохновлённую чем-то подобным.
Also, если зафулскринить браузер на правом мониторе, то менюшка по кнопке V отображается в правом верхнем углу левого монитора. И ещё по куче интерфейсных деталей хочется накидать фидбэк. Лучше сюда или на форум?
Also #2: есть какой-нибудь блог или иное место, где можно было бы следить за развитием браузера? Проект потенциально интересный, я бы не отказался одним глазом поглядывать на ченджлоги.
Пользуясь случаем: а в DataFlow есть аналог очереди с приоритетами? Беглый просмотр неймспейса на MSDN результата не дал.
Мысль про protected конструктор интересная. Явно проще и элегантнее, чем для передачи пачки параметров писать враппер, реализующий IProducerConsumerCollection. Я подумаю ;)
Я думаю в направлении interface IConsumer с похожим методом — навскидку кажется, что так реализация TakeAnyAsync() получится немного чище. Но пока не берусь утверждать как будет на самом деле, идея пока на стадии обкатывания в голове.