Дак одним из преимуществ Sony Xperia — это наличие спец-режима Stamina, который должен усыплять любую излишнюю активность приложений тогда, когда экран выключен.
У меня же, после одного из официальных обновлений сервер медиа где то дня три парсил мою музыку, всякие картинки и видео, плеер walkman качал обложки для альбомов и т.д. Всё это время к розетке в конце дня он успевал еле-еле.
Ну и приложения, которые кушают батарею в основном и так видно в расшифровке «электропитания». Кроме собственно «ОС андроид» и «сервер медиа». Последний — скорее всего потому что я собственно слушаю музыку. Первый же — не понятно.
У меня есть вопрос по поводу времени жизни батареи.
С каждым новым апдейтом приходится выключать некоторые службы, которые усиленно потребляют батарею. В апдейте 4.3 во первых был уменьшен режим энергосбережения батареи с 30% до 20%. Плюс, пока не выключил самые очевидно-левые для меня «службы»(разнообраные social engine) — Android OS было в первых строчках потребителей батареи.
Ну и с каждым новым апдейтом телефон живёт всё меньше(что может быть и субъективно, т.к и батарея телефона не молодеет).
Так вот, где же ваша хвалёная стамина? Почему не усыпляет всякие приложения которые пассивно не дают уснуть основному процу? Почему % включения режима энергосбережения не вынесен в отдельный столбец, который можно будет поправить?
Я на своём телефоне в основном слушаю музыку через блютуз, иногда принимаю звонки и сёрфлю. В таком режиме хотелось бы что бы телефон жил 2-2.5 дня(сейчас под конец дня — 50%, под утро уже 35% и пора на зарядку). А то под «сервер медиа» и «ос андроид» очень похоже что скрываются самые большие статьи расходов батареи, которые абсолютно не очевидны обывателю. Хотелось бы понять куда именно уходит батарея.
Ответ прост — рендер самой страницы на стороне клиента.
Технология уже давно обкатана и нетривиальна в обращении.
Аналог — любой шаблонизатор на JS, но для этого ещё нужно написать «ядро» приложения хоть какое-то, которое склеит страницу воедино и т.д…
Ну, про Z2 не скажу, но первая версия с каждым новым апдейтом живёт всё меньше. Раньше держала два дня спокойно(после 30% включался режим супер-экономии и так он мог ещё дня 4 лежать в качестве звонилки). Сейчас и режим экономии стал на 20%, и хватать стало только на сутки. При этом я чаще всего слушаю музыку по блютузу, и ОС андроида жрёт даже больше чем весь этот функционал что я использую.
У Z2 заявлена батарея в 3.2 мАч что чуть больше чем у Z1. Но при этом и мощнее начинка. Так что имхо — ожидать примерно такого же — полтора дня можно носить спокойно, под конец второго дня можно ждать разряда.
Возможно. Просто не силён в терминологии.
Я, например, обычно делаю jQuery-way — если нужно что то пересчитать то вот есть ивент recount и в случае изменения — его нужно дёрнуть, а там подтянутся все необходимые переменные из источников. Таким образом очевидно что конкретно откуда берётся.
Ну и конкретно с замыканиями — в своей практике я не использовал «локальные» функции которые имеют доступ к «приватным» переменным. Возможно я просто не сильно утруждал себя оптимизацией кода и исключением «глобальных переменных»(как пример — ajaxAbort).
На самом деле благодаря таким комментам я всё чаще и чаще задумываюсь о повышении своего уровня, хотя бы для общения на «общепринятом» языке. Но — нет времени на теорию, сейчас больше всего нужно время на изучение новых инструментов разработки. Например я давно хочу сделать «передовой» сайт со всякими фичами вроде SAAS/LESS и full-stack JS сайте. К сожалению, я работаю в достаточно консервативной сфере, где с одной стороны работодатель даёт крайне ограниченное время на такого рода эксперименты, а с другой — менеджеры говорят что клиенты не увидят разницы. Но время на само-обучение я всёравно трачу, иначе просто рано или поздно превращусь в осталого динозавра, как сейчас — прогеры на каком нить делфи.
Блин, я наверное нарвусь на праведный гнев, но меня обязывает мой ник чего-нибудь написать в этом топике.
Я самоучка. Университет хоть и профильный, но нихрена не дал в плане программирования.
Я не знаю терминов, серьёзно. И когда умные люди начинают говорить про всякие «бинарные деревья» я ввергаюсь в панику и думаю что мой уровень ниже плинтуса, хоть и имею достаточно опыта и знаний в своём деле. Пытаюсь «догнать» терминологию, вот например узнал про замыкания и области видимости функций. Поможет ли мне это в работе? Нет, пытался придумать применение — не нашёл. Упростит ли это поддержку кода? Нет, т.к происходят неочевидные вещи.
Я согласен, бывают разные случаи, в том числе и при оптимизации кода. Так ли сильно нужно это клиентам? Не думаю.
Присоединюсь к мнению — лучше за два дня сделать работающий интерфейс чем за два месяца сделать правильный интерфейс. А быдлокодинг — все через него прошли, и он проходит с опытом. Я искренне буду рад если мне покажут какой то новый способ решения который будет оптимальнее, но пока таких — увы и ах — не находилось(хоть я и не гуру фронтенд разработки, библиотек не писал, и ни разу не TheShock).
Можете хоть сто раз меня назвать Junior и «быдлокодер», но если я встречусь с проблемой которую я не смогу решить — я это загуглю и углублюсь. Пока что в современных практиках я нахожу схожий со своим подход в программировании.
честно — сейчас уже линк найти трудно. Я попытаюсь, но видел перед НГ информацию о том, что автопром и медицина больше всего инвестируют в исследования. А они не обходятся без передовой электроники.
Про автопром сам многого не знаю, но например те же автоматические автомобили. Просто представьте СКОЛЬКО инвестировали в исследования и технологии в этой области. Настоящая, компактная и с низким потреблением энергии система реального времени.
А про медицину — ну, большинство было перечислено выше. Это и human brain project(который имеет массу профита), тот же геном человека и т.п вещи. В потребительской электронике нет таких перспектив, она — до сих пор лишь побочный продукт(соразмерный с требованием рынка приложений). Не говоря уж о высокочастотном трейдинге, который, ИМХО — не несёт столько же профита как и тот же проект о геноме человека.
Вообщем, я действительно на данный момент не имею аргументов в поддержку моего мнения и не могу ОБЪЕКТИВНО доказать что HFT не несёт пользы обществу, да и не хочу ничего доказывать. Моё мнение по прежнему неизменно — я НЕ ЗНАЮ зачем конкретно существует эта область и какой её вклад(он определённо есть, судя по тем же статьям из хабра. Например, квантовые сети вполне могли бы быть проинвестированы таким родом трейдинга).
За сим считаю нашу дискуссию завершённой, т.к ни я, ни вы не привели весомых аргументов в разъяснении изначального вопроса.
>> Но если бы спроса на домашние гигафлопы не было
Спрос на домашние гигафлопы образуют две вещи — новые технологии(развлечения + профессиональный софт) и кривизна рук программистов.
>> мы бы не имели сейчас столь дешевой и высокопроизводительной электроники.
имели бы. Потому что в первую очередь это нужно было войскам. Во вторую -научным институтам. То что «высокопроизводительная электроника» попала в руки к обывателю — всего лишь побочный продукт был на то время. Хотя, и сейчас, сравнивая объём рынка потребительской электроники существенно ниже в млрд $ с такими областями как например автопром и медицина, которые являются основными потребителями передовых технологий.
>> Аналогично, запрещая HFT вы не только отбираете у каких-то несимпатичных вам людей их Феррари.
Друг, ничего не попутал? Мне всёравно какие там деньги крутятся и сколько их у кого. Я просто не понимаю ценности этих торгов.
>> квалифицированных математиков и программистов
которые, по моему личному субьективному мнению — могли бы найти применение в более полезных областях для всего общества.
>> забираете сколько-то миллиардов долларов в год с рынка высокоскоростных сетей и топовых серверных процессоров и FPGA.
угу. Протянуть канал напрямую что бы ТОЛЬКО общаться между биржами ради 10 мс выгоды — коонечно, достойное применение финансов. Хоть мне и понравилась технология передачи данных по UDP напрямую от точки до точки.
>>а вы, судя по вашей уверенной позиции, его как-то ухитрились выполнить?
Опять таки, ничего не путаешь? Я просто не понимаю для чего он существует.
>> Покажите пожалуйста, как размер кванта торгов в 5 минут выводится из принципов гуманизма и равенства?
Выше читайте.
>> Где та фундаментальная константа с размерностью времени, что отделяет честные торги от обмана?
Поставить эксперимент, не? Запустить одинаковое количество людей, имеющих примерно равную квалификацию в торгах, и дать каждому на принятие решения купить/продать/остаться 1-2-3-4-5 и т.д минут. Какая группа будет успешнее и получит за N времени наибольшую выгоду — такое ограничение и принять. Хотя это всё лишь теория.
>>По-правде, у меня сейчас ощущение, что вы просто бросаетесь случайными словами, не задумываясь над их смыслом.
Вы точно внимательно читали мои комменты? Лично мне фиолетово на существование высокоскоростных бирж. Я не владею ни знаниями, ни навыками. В этом вопросе я обыватель, который с интересом посматривает на такого рода статьи, но не понимает чем же ценна такого рода деятельность.
>> На минутку представьте себе мир, в котором, лет 40 назад, вам была бы дана власть сказать «никакому разумному человеку не нужен домашний компьютер с мощностью в гигафлопы».
никакому разумному человеку не нужен домашний компьютер с мощностью в гигафлопы что бы сидеть в контакте.
Не нужен в этом случае == не необходим. И утилизировать его мощности он не сможет. У меня у самого комп, которому уже 9 лет.
>> Вот именно, что если бизнес прибыльный — значит он и производит пользу для общества. Иначе — кто за него платит?
В идеальном мире нет коррупции. В нём мегакорпорации не могут задавить ларёк с мороженым, а возможность открыть своё дело в любой сфере бизнеса может любой. Но это — идеальный мир, идеальный само-контролирующися свободный рынок. На данный момент имеет то, что не любой бизнес приносит явную и максимальную(мб даже оптимальную между своими интересами и интересами общества) пользу для общества.
>> Если же польза для общества — это то, что вы (или какая-то социальная группа) считает правильным
безусловная польза для человеческого общества — это следование принципам гуманизма и равенства. Всё остальное — субъективная польза той или иной группы людей. Я надеюсь что не нужно приводить примеры.
И, пожалуй, закончим философскую дискуссию, мне _просто_ не понятно что же такое высокочастотный трейдинг, если не законный «обман» системы?
И вообще, реквестирую статью «а что было бы, если высокочастотный трейдинг ограничили бы временным интервалом в 5 минут».
>> В чем профит переложения на js опроса на существования картинки?
Меньше нагрузка на веб-сервер, меньшее количество настроек, потенциально — меньше шансов запороть всю систему с помощью кривых рук.
Ну и не вижу особой разницы между получением 404 и редиректом с JS и тем же, но реализованным на стороне сервера. Хоть в случае с JS действительно будет медленнее за счёт обслуживания http.
>> Как js должен сжимать?
canvas -> scale. Очень быстро сжимает прямо на GPU. Профит в том что время серверное вообще не тратиться.
О поддержке canvas можете не заикаться — необходимый функционал работает везде, кроме ie 8(пользователи которого не оценят ваш адаптивный дизайн).
Кроме того, возможно реализовать любой «интеллектуальный» алгоритм сжатия.
>> Сначала загрузить полную, потом пережать на клиенте и отдать нам? Грузите все, что хотите?))
Если нет уже сжатой картинки — скачать полную и сжать. После этого(или вместе с этим) послать асинхронный запрос на сервер на сжатие этой картинки в кэш.
При такой схеме никаких проблем с правами на запись не будет.
Преимущества того или иного подхода нужно оценивать в реальных системах.
Я думаю если будет много графики и разных клиентов — имеет смысл распределить загрузку.
>> Пережатие картинки происходит раз для каждого разрешения и не так долго, как можно подумать.
А так, представьте себе, можно будет сжимать картинку не под определённые разрешния а под конкретно пользовательские!
почему бы в таком случае не переложить работу веб-сервера на js? Сгенерировать урл(ну типа там resized_image_1024_768.jpg), попытаться его загрузить(на том же js), на fail — уже отправить запрос напрямую в php и получить сгенерированную картинку?
и ещё дальше — почему бы не переложить работу по сжиманию картинки на js? В том числе и с отправкой кэша на сервер(рисково правда давать права на запись)?
И не надоест ли клиенту ждать пока его картинки подгрузятся?
PS с пережимом картинок сам сталкивался и писал небольшую функцию которая отслеживает все связи. Это была фото-галерея на собственном движке, нужно было хранить мини-картинку, побольше превьюху, ещё больше одну и оригинал. Делал всё на загрузке картинки в базу. Правда там было известно что где показывать.
>>Меня, если честно, очень удивляют такие комментарии от ИТшников. Скажите, неужели есть ДЕЙСТВИТЕЛЬНАЯ необходимость, чтобы ваш
>> ноутбук выполнял ~10 миллиардов арифметических операций в секунду?
Честно — лично мне в повседневной жизни — не нужно, в большинстве случаев я не утилизирую и 90% мощностей своих компьютеров(хоть и есть варианты монетизировать их мощности, и это не только криптовалюты).
Есть игры, есть тяжёлые программы — они ТРЕБУЮТ больших мощностей. Но в целом, это является следствием продукта который я хочу использовать, в таком случае в этом ЕСТЬ потребность.
>> А есть какой-то бизнес, который не строится на использовании преимущества?
бизнес должен производить какой либо продукт. Он всегда строится на преимуществах, в том числе — законодательных(в том числе законы и ограничивают преимущество одних над другими). Но в то же время — бизнес делает что то полезное. Не только для своего кармана, но и для общества в целом(иначе, в идеальном мире — он не был бы прибыльным).
Мне непонятно то, что конкретно является продуктом высокочастотного трейдинга кроме собственно говоря спекуляции — ни один продукт не может достигнуть покупателя за такой короткий срок(в том числе и вывести деньги с биржи в виде финансов на счету). Старые, ручные биржи — между прочим так и работали. Показывается котировка, собираются заявки, обрабатываются, показывается следующая котировка на основе этих заявок. Возможно чем то не устраивала эта система(скоростью, очевидно), но мне всё-равно не понятна суть высокочастотной торговли.
Статью не читал(за что извиняюсь), но я вот о чём — неужели есть ДЕЙСТВИТЕЛЬНАЯ необходимость в НАСТОЛЬКО быстрых операциях?
Ведь по факту такой род трейдинга — чистая спекуляция и использование преимущества(а я первый узнал).
Почему бы биржам не ввести например 5-ти минутные интервалы между обработкой всех заявок? Заявки поступают в очередь, а потом оттуда выполняются.
Эдакие 5-ти минутные фьючерсы на общих основах.
Хотя возможно что я просто не понимаю смысла в биржах, на которых «работают» роботы.
>>> Что в итоге (предположим влезло 2 абзаца) приведёт к обрезанию как показано выше.
Разве что если будут блоки и без заголовка и с заголовком. Иначе — предусматривается в css что блок должен содержать заголовок и 3 строки текста под ним, и пишется такое ограничение — у заголовка вот такая высота строки плюс 3 высоты у текста. И высота исчисляемая, в em-ах и зависит от размеров шрифта. Если меняется сам размер элементов то высота блока переопределяется(больше шрифт — значит и больше блоки. Меньше шрифт — меньше блоки. Нужно другое соотношение — поправь. Не хочешь править — подключи препроцессор и забудь про калькуляцию размеров блока как про страшный сон).
Ну вообщем, не вижу смысла дальше обсуждать — дальше уж нужно писать отдельную статью про расово-верный способ сверстать блок с ограничением по высоте, чего я делать не особо хочу(нет времени). И на самом деле — подходит любой из них, в том числе и с обрезанием текста.
Именно, если контроллируете. Собственно, любой контент должен быть предусмотрен дизайном, иначе всёравно будут проблемы.
1. Отступ сверху и снизу задаётся с помощью line-height(вообще в целом высота строки. Достаточно указать 110%(или 1.1) например и у нас сверху 5% шрифта отступ и снизу). Отступ слева при помощи text-indent(только для того что бы выделить что начался новый абзац). Отступ слева-справа у всего текста — с помощью отдельного контейнера. Если нужно что бы заголовок отделялся от текста — то это отдельный контейнер для текста.
2. 1-2 px не велика проблема, обычно и не видно будет(если текст не сверх-сжат). Но вообще то, что заголовки требуют разного размера шрифтов — проблема дизайна(на одной странице — разные размеры шрифтов у заголовков). Точечно решается присваиванием классов родительскому контейнеру с ограничением по высоте, т.к по факту это — другой контейнер с другим типом текста. Если заголовки меняются во всех таких контейнерах то просто поправить значение в css(ну и «пересобрать» css-файлик что бы остальные значения подтянулись).
3. Честно — не верстал с flexbox'ом пока, но не вижу никаких проблем- flexbox контроллирует ширину, а обрезание текста происходит из за высоты. Высота известна — это большой заголовок + высота строк. Количество интересующих нас строк тоже известно, как и их высота(line-height). Хотя и могу предположить что в Вашей ситуации иначе было нельзя.
В вебе всё так же. Дизайнер разрабатывает разные варианты поведения у страницы и контента, верстальщик реализует. Если появляется что то «неожиданное» — косяк обоих. Темболее что контроллировать внезапно появляющиеся контейнеры ещё сложнее чем неожиданные элементы в тексте, как раз таки подгон лишних контейнеров и есть вручную приведение страницы к нужному виду, а если верстать текст то будет понятно как он должен выглядеть и себя вести, и заботиться об единожды написанных правилах нужно только тогда, когда появляются элементы ломающие вёрстку(соотвественно чем лучше дизайнер и верстальщик — тем меньше «поломок»).
multicolumn и прочее появились как нативная альтернатива js-костылям, и это правильно. Темболее что мода пошла как раз таки от «классических» верстальщиков текста в каких нить газетах/журналах.
Я не говорю о том что мы контроллируем СКОЛЬКО контента находится в контейнере или как конкретно должен выглядеть каждый находящийся в нём символ. Мы, как верстальщики, всего лишь описываем правила поведения текста в этих контейнерах. Если появилось то, что ломает вёрстку то это косяк двух(ну или даже трёх) человек — дизайнера и верстальщика за то что не предусмотрели(и того кто контент добавил и головой не подумал).
А то так можно будет, в случае массового распространения — делать офигительные пранки )
У меня же, после одного из официальных обновлений сервер медиа где то дня три парсил мою музыку, всякие картинки и видео, плеер walkman качал обложки для альбомов и т.д. Всё это время к розетке в конце дня он успевал еле-еле.
Ну и приложения, которые кушают батарею в основном и так видно в расшифровке «электропитания». Кроме собственно «ОС андроид» и «сервер медиа». Последний — скорее всего потому что я собственно слушаю музыку. Первый же — не понятно.
С каждым новым апдейтом приходится выключать некоторые службы, которые усиленно потребляют батарею. В апдейте 4.3 во первых был уменьшен режим энергосбережения батареи с 30% до 20%. Плюс, пока не выключил самые очевидно-левые для меня «службы»(разнообраные social engine) — Android OS было в первых строчках потребителей батареи.
Ну и с каждым новым апдейтом телефон живёт всё меньше(что может быть и субъективно, т.к и батарея телефона не молодеет).
Так вот, где же ваша хвалёная стамина? Почему не усыпляет всякие приложения которые пассивно не дают уснуть основному процу? Почему % включения режима энергосбережения не вынесен в отдельный столбец, который можно будет поправить?
Я на своём телефоне в основном слушаю музыку через блютуз, иногда принимаю звонки и сёрфлю. В таком режиме хотелось бы что бы телефон жил 2-2.5 дня(сейчас под конец дня — 50%, под утро уже 35% и пора на зарядку). А то под «сервер медиа» и «ос андроид» очень похоже что скрываются самые большие статьи расходов батареи, которые абсолютно не очевидны обывателю. Хотелось бы понять куда именно уходит батарея.
Технология уже давно обкатана и нетривиальна в обращении.
Аналог — любой шаблонизатор на JS, но для этого ещё нужно написать «ядро» приложения хоть какое-то, которое склеит страницу воедино и т.д…
У Z2 заявлена батарея в 3.2 мАч что чуть больше чем у Z1. Но при этом и мощнее начинка. Так что имхо — ожидать примерно такого же — полтора дня можно носить спокойно, под конец второго дня можно ждать разряда.
Я, например, обычно делаю jQuery-way — если нужно что то пересчитать то вот есть ивент recount и в случае изменения — его нужно дёрнуть, а там подтянутся все необходимые переменные из источников. Таким образом очевидно что конкретно откуда берётся.
Ну и конкретно с замыканиями — в своей практике я не использовал «локальные» функции которые имеют доступ к «приватным» переменным. Возможно я просто не сильно утруждал себя оптимизацией кода и исключением «глобальных переменных»(как пример — ajaxAbort).
На самом деле благодаря таким комментам я всё чаще и чаще задумываюсь о повышении своего уровня, хотя бы для общения на «общепринятом» языке. Но — нет времени на теорию, сейчас больше всего нужно время на изучение новых инструментов разработки. Например я давно хочу сделать «передовой» сайт со всякими фичами вроде SAAS/LESS и full-stack JS сайте. К сожалению, я работаю в достаточно консервативной сфере, где с одной стороны работодатель даёт крайне ограниченное время на такого рода эксперименты, а с другой — менеджеры говорят что клиенты не увидят разницы. Но время на само-обучение я всёравно трачу, иначе просто рано или поздно превращусь в осталого динозавра, как сейчас — прогеры на каком нить делфи.
Я самоучка. Университет хоть и профильный, но нихрена не дал в плане программирования.
Я не знаю терминов, серьёзно. И когда умные люди начинают говорить про всякие «бинарные деревья» я ввергаюсь в панику и думаю что мой уровень ниже плинтуса, хоть и имею достаточно опыта и знаний в своём деле. Пытаюсь «догнать» терминологию, вот например узнал про замыкания и области видимости функций. Поможет ли мне это в работе? Нет, пытался придумать применение — не нашёл. Упростит ли это поддержку кода? Нет, т.к происходят неочевидные вещи.
Я согласен, бывают разные случаи, в том числе и при оптимизации кода. Так ли сильно нужно это клиентам? Не думаю.
Присоединюсь к мнению — лучше за два дня сделать работающий интерфейс чем за два месяца сделать правильный интерфейс. А быдлокодинг — все через него прошли, и он проходит с опытом. Я искренне буду рад если мне покажут какой то новый способ решения который будет оптимальнее, но пока таких — увы и ах — не находилось(хоть я и не гуру фронтенд разработки, библиотек не писал, и ни разу не TheShock).
Можете хоть сто раз меня назвать Junior и «быдлокодер», но если я встречусь с проблемой которую я не смогу решить — я это загуглю и углублюсь. Пока что в современных практиках я нахожу схожий со своим подход в программировании.
Про автопром сам многого не знаю, но например те же автоматические автомобили. Просто представьте СКОЛЬКО инвестировали в исследования и технологии в этой области. Настоящая, компактная и с низким потреблением энергии система реального времени.
А про медицину — ну, большинство было перечислено выше. Это и human brain project(который имеет массу профита), тот же геном человека и т.п вещи. В потребительской электронике нет таких перспектив, она — до сих пор лишь побочный продукт(соразмерный с требованием рынка приложений). Не говоря уж о высокочастотном трейдинге, который, ИМХО — не несёт столько же профита как и тот же проект о геноме человека.
Вообщем, я действительно на данный момент не имею аргументов в поддержку моего мнения и не могу ОБЪЕКТИВНО доказать что HFT не несёт пользы обществу, да и не хочу ничего доказывать. Моё мнение по прежнему неизменно — я НЕ ЗНАЮ зачем конкретно существует эта область и какой её вклад(он определённо есть, судя по тем же статьям из хабра. Например, квантовые сети вполне могли бы быть проинвестированы таким родом трейдинга).
За сим считаю нашу дискуссию завершённой, т.к ни я, ни вы не привели весомых аргументов в разъяснении изначального вопроса.
Спрос на домашние гигафлопы образуют две вещи — новые технологии(развлечения + профессиональный софт) и кривизна рук программистов.
>> мы бы не имели сейчас столь дешевой и высокопроизводительной электроники.
имели бы. Потому что в первую очередь это нужно было войскам. Во вторую -научным институтам. То что «высокопроизводительная электроника» попала в руки к обывателю — всего лишь побочный продукт был на то время. Хотя, и сейчас, сравнивая объём рынка потребительской электроники существенно ниже в млрд $ с такими областями как например автопром и медицина, которые являются основными потребителями передовых технологий.
>> Аналогично, запрещая HFT вы не только отбираете у каких-то несимпатичных вам людей их Феррари.
Друг, ничего не попутал? Мне всёравно какие там деньги крутятся и сколько их у кого. Я просто не понимаю ценности этих торгов.
>> квалифицированных математиков и программистов
которые, по моему личному субьективному мнению — могли бы найти применение в более полезных областях для всего общества.
>> забираете сколько-то миллиардов долларов в год с рынка высокоскоростных сетей и топовых серверных процессоров и FPGA.
угу. Протянуть канал напрямую что бы ТОЛЬКО общаться между биржами ради 10 мс выгоды — коонечно, достойное применение финансов. Хоть мне и понравилась технология передачи данных по UDP напрямую от точки до точки.
>>а вы, судя по вашей уверенной позиции, его как-то ухитрились выполнить?
Опять таки, ничего не путаешь? Я просто не понимаю для чего он существует.
>> Покажите пожалуйста, как размер кванта торгов в 5 минут выводится из принципов гуманизма и равенства?
Выше читайте.
>> Где та фундаментальная константа с размерностью времени, что отделяет честные торги от обмана?
Поставить эксперимент, не? Запустить одинаковое количество людей, имеющих примерно равную квалификацию в торгах, и дать каждому на принятие решения купить/продать/остаться 1-2-3-4-5 и т.д минут. Какая группа будет успешнее и получит за N времени наибольшую выгоду — такое ограничение и принять. Хотя это всё лишь теория.
>>По-правде, у меня сейчас ощущение, что вы просто бросаетесь случайными словами, не задумываясь над их смыслом.
Вы точно внимательно читали мои комменты? Лично мне фиолетово на существование высокоскоростных бирж. Я не владею ни знаниями, ни навыками. В этом вопросе я обыватель, который с интересом посматривает на такого рода статьи, но не понимает чем же ценна такого рода деятельность.
никакому разумному человеку не нужен домашний компьютер с мощностью в гигафлопы что бы сидеть в контакте.
Не нужен в этом случае == не необходим. И утилизировать его мощности он не сможет. У меня у самого комп, которому уже 9 лет.
>> Вот именно, что если бизнес прибыльный — значит он и производит пользу для общества. Иначе — кто за него платит?
В идеальном мире нет коррупции. В нём мегакорпорации не могут задавить ларёк с мороженым, а возможность открыть своё дело в любой сфере бизнеса может любой. Но это — идеальный мир, идеальный само-контролирующися свободный рынок. На данный момент имеет то, что не любой бизнес приносит явную и максимальную(мб даже оптимальную между своими интересами и интересами общества) пользу для общества.
>> Если же польза для общества — это то, что вы (или какая-то социальная группа) считает правильным
безусловная польза для человеческого общества — это следование принципам гуманизма и равенства. Всё остальное — субъективная польза той или иной группы людей. Я надеюсь что не нужно приводить примеры.
И, пожалуй, закончим философскую дискуссию, мне _просто_ не понятно что же такое высокочастотный трейдинг, если не законный «обман» системы?
И вообще, реквестирую статью «а что было бы, если высокочастотный трейдинг ограничили бы временным интервалом в 5 минут».
Меньше нагрузка на веб-сервер, меньшее количество настроек, потенциально — меньше шансов запороть всю систему с помощью кривых рук.
Ну и не вижу особой разницы между получением 404 и редиректом с JS и тем же, но реализованным на стороне сервера. Хоть в случае с JS действительно будет медленнее за счёт обслуживания http.
>> Как js должен сжимать?
canvas -> scale. Очень быстро сжимает прямо на GPU. Профит в том что время серверное вообще не тратиться.
О поддержке canvas можете не заикаться — необходимый функционал работает везде, кроме ie 8(пользователи которого не оценят ваш адаптивный дизайн).
Кроме того, возможно реализовать любой «интеллектуальный» алгоритм сжатия.
>> Сначала загрузить полную, потом пережать на клиенте и отдать нам? Грузите все, что хотите?))
Если нет уже сжатой картинки — скачать полную и сжать. После этого(или вместе с этим) послать асинхронный запрос на сервер на сжатие этой картинки в кэш.
При такой схеме никаких проблем с правами на запись не будет.
Преимущества того или иного подхода нужно оценивать в реальных системах.
Я думаю если будет много графики и разных клиентов — имеет смысл распределить загрузку.
>> Пережатие картинки происходит раз для каждого разрешения и не так долго, как можно подумать.
А так, представьте себе, можно будет сжимать картинку не под определённые разрешния а под конкретно пользовательские!
и ещё дальше — почему бы не переложить работу по сжиманию картинки на js? В том числе и с отправкой кэша на сервер(рисково правда давать права на запись)?
И не надоест ли клиенту ждать пока его картинки подгрузятся?
PS с пережимом картинок сам сталкивался и писал небольшую функцию которая отслеживает все связи. Это была фото-галерея на собственном движке, нужно было хранить мини-картинку, побольше превьюху, ещё больше одну и оригинал. Делал всё на загрузке картинки в базу. Правда там было известно что где показывать.
>> ноутбук выполнял ~10 миллиардов арифметических операций в секунду?
Честно — лично мне в повседневной жизни — не нужно, в большинстве случаев я не утилизирую и 90% мощностей своих компьютеров(хоть и есть варианты монетизировать их мощности, и это не только криптовалюты).
Есть игры, есть тяжёлые программы — они ТРЕБУЮТ больших мощностей. Но в целом, это является следствием продукта который я хочу использовать, в таком случае в этом ЕСТЬ потребность.
>> А есть какой-то бизнес, который не строится на использовании преимущества?
бизнес должен производить какой либо продукт. Он всегда строится на преимуществах, в том числе — законодательных(в том числе законы и ограничивают преимущество одних над другими). Но в то же время — бизнес делает что то полезное. Не только для своего кармана, но и для общества в целом(иначе, в идеальном мире — он не был бы прибыльным).
Мне непонятно то, что конкретно является продуктом высокочастотного трейдинга кроме собственно говоря спекуляции — ни один продукт не может достигнуть покупателя за такой короткий срок(в том числе и вывести деньги с биржи в виде финансов на счету). Старые, ручные биржи — между прочим так и работали. Показывается котировка, собираются заявки, обрабатываются, показывается следующая котировка на основе этих заявок. Возможно чем то не устраивала эта система(скоростью, очевидно), но мне всё-равно не понятна суть высокочастотной торговли.
Ведь по факту такой род трейдинга — чистая спекуляция и использование преимущества(а я первый узнал).
Почему бы биржам не ввести например 5-ти минутные интервалы между обработкой всех заявок? Заявки поступают в очередь, а потом оттуда выполняются.
Эдакие 5-ти минутные фьючерсы на общих основах.
Хотя возможно что я просто не понимаю смысла в биржах, на которых «работают» роботы.
Разве что если будут блоки и без заголовка и с заголовком. Иначе — предусматривается в css что блок должен содержать заголовок и 3 строки текста под ним, и пишется такое ограничение — у заголовка вот такая высота строки плюс 3 высоты у текста. И высота исчисляемая, в em-ах и зависит от размеров шрифта. Если меняется сам размер элементов то высота блока переопределяется(больше шрифт — значит и больше блоки. Меньше шрифт — меньше блоки. Нужно другое соотношение — поправь. Не хочешь править — подключи препроцессор и забудь про калькуляцию размеров блока как про страшный сон).
Ну вообщем, не вижу смысла дальше обсуждать — дальше уж нужно писать отдельную статью про расово-верный способ сверстать блок с ограничением по высоте, чего я делать не особо хочу(нет времени). И на самом деле — подходит любой из них, в том числе и с обрезанием текста.
1. Отступ сверху и снизу задаётся с помощью line-height(вообще в целом высота строки. Достаточно указать 110%(или 1.1) например и у нас сверху 5% шрифта отступ и снизу). Отступ слева при помощи text-indent(только для того что бы выделить что начался новый абзац). Отступ слева-справа у всего текста — с помощью отдельного контейнера. Если нужно что бы заголовок отделялся от текста — то это отдельный контейнер для текста.
2. 1-2 px не велика проблема, обычно и не видно будет(если текст не сверх-сжат). Но вообще то, что заголовки требуют разного размера шрифтов — проблема дизайна(на одной странице — разные размеры шрифтов у заголовков). Точечно решается присваиванием классов родительскому контейнеру с ограничением по высоте, т.к по факту это — другой контейнер с другим типом текста. Если заголовки меняются во всех таких контейнерах то просто поправить значение в css(ну и «пересобрать» css-файлик что бы остальные значения подтянулись).
3. Честно — не верстал с flexbox'ом пока, но не вижу никаких проблем- flexbox контроллирует ширину, а обрезание текста происходит из за высоты. Высота известна — это большой заголовок + высота строк. Количество интересующих нас строк тоже известно, как и их высота(line-height). Хотя и могу предположить что в Вашей ситуации иначе было нельзя.
В вебе всё так же. Дизайнер разрабатывает разные варианты поведения у страницы и контента, верстальщик реализует. Если появляется что то «неожиданное» — косяк обоих. Темболее что контроллировать внезапно появляющиеся контейнеры ещё сложнее чем неожиданные элементы в тексте, как раз таки подгон лишних контейнеров и есть вручную приведение страницы к нужному виду, а если верстать текст то будет понятно как он должен выглядеть и себя вести, и заботиться об единожды написанных правилах нужно только тогда, когда появляются элементы ломающие вёрстку(соотвественно чем лучше дизайнер и верстальщик — тем меньше «поломок»).
multicolumn и прочее появились как нативная альтернатива js-костылям, и это правильно. Темболее что мода пошла как раз таки от «классических» верстальщиков текста в каких нить газетах/журналах.
Я не говорю о том что мы контроллируем СКОЛЬКО контента находится в контейнере или как конкретно должен выглядеть каждый находящийся в нём символ. Мы, как верстальщики, всего лишь описываем правила поведения текста в этих контейнерах. Если появилось то, что ломает вёрстку то это косяк двух(ну или даже трёх) человек — дизайнера и верстальщика за то что не предусмотрели(и того кто контент добавил и головой не подумал).