Там использовалась акустика Martin Logan SL-3 — это не то же самое что IEM наушники. С хорошими наушниками этот эксперимент врядли сработал бы. Но доказать будет сложно.
От провода зависит как звук передастся от источника к приемнику. Т.е. чем качественнее провод, тем меньше потерь при передаче и искажений + хорошие провода обычно дольше живут, хотя это смотря как их использовать.
Хе. словил хейтера =)
Да, я знаю что такое «арматура» и что ее использовали очень давно для весьма специфических целей. И косяки мне известны.
Я согласен, что маркетинг — зло, но не стоит из-за этого списывать продукт в утиль и бросаться на всех, кто нашел в этом продукте смысл. Хоть технология и не новая, но сейчас ее довели до того, что в относительно небольшой корпус можно вместить до 4х арматур, что и позволило значительно улучшить звучание.
Действительно, однодрайверные наушники — фуфло редкостное. Нормальные динамические их как стоячих обойдут по всем параметрам, но вот двухдрайверные — это совершенно другой звук. Лично мне 2х-драйверные арматуры нравятся по звучанию значительно больше чем динамические наушники, хоть и стоят дороже. И я слышу разницу, причем весьма ощутимую. И да — я слушал много динамических наушников разных фирм и уровней, сравнивать есть с чем.
На тему ремонта — в хачь-палатку на ремонт отдавай свои наушники, не стоит посылать туда других. В такой палатке как минимум нет качественных проводов для замены, а плохой провод и звук убьет и сдохнет быстро. Пара таких «ремонтов» и наушники можно выбрасывать. И это еще если они их вообще сумеют разобрать-собрать =)
PS: я сравниваю только внутриканальные наушники
PSS: слух у меня хороший, не жалуюсь и я уже вышел за рамки нормальности т.к. звук многих динамических наушников меня не радует, да и некоторые арматуры тоже не ахти. Просто я нашел «свои» арматурки и не хочу с ними расставаться ибо лучше них за адекватную цену я ничего не слушал.
Хоршая статья. Многое объясняет.
Разве что не полностью согласен с одним минусом — «Узкая звуковая сцена». Это справедливо не для всех IEM. Есть экземпляры с довольно широкой сценой (Creative Aurvana In-Ear 3, например), хотя большинство действительно с довольно узкой сценой.
Срок службы при постоянном использовании обычно сильно ограничивается проводом. У меня провода живут 1-1,5 года, после чего их приходится либо чинить, либо менять (что довольно дорого и мало кто берется, особенно если арматурки). Есть модели со съемным кабелем, что удешевляет замену, но при этом сами наушники сильно дорожат, что довольно печально. Как вариант — найти мастеров, которые модифицируют наушники так, что кабель будет съемным. Я вот свои Aurvanы недавно отдал на такую модификацию. Вместе с проводом это стоило 80% цены наушников. Первоначально хотел купить новые, но за адекватную цену совершенно ничего хотябы такого-же по качеству звучания не нашел — дешевле было модифицировать. Результат пока не тестировал — в процессе пересылки. Как приедут — отпишусь о результате, если не забуду.
1. В свернутом режиме можно зажать "<<" или ">>"
2. В свернутом режиме нажать на название трека и перейти в полный режим, где уже и перемотать куда надо
Решения не особо эффективные, но они есть.
Верю. Еще есть подкасты, аудиокники и толстые однофайловые сборники/альбомы музыки (может еще чего, но я не встречал).
Что мешает при открытии трека перемотать ползунком на нужное место?
По умолчанию трек открывается полном режиме, где есть ползунок, т.е. приблемы как бы нет =)
Вообще-то все работает… по крайней мере у меня =)
У музыки нет ползунка тоьлко в свернутом виде, но как по мне он там и не нужен. И вообще я не понимаю зачем это нужно при прослушивании уже отобранной музыки.
Видео html 5 имеет достаточно управления — play/pause, fullscreen, полоса прокрутки.
Другое дело если плеер html5 кастомизирован, тогда косяков много, но это касается всех мобильных платформ. Как показала практика — меньше всего проблем при использовании стандартного html5 плеера (winphone/android) или вообще отдавать видео файл операционке (ios).
я показывал "===" C# программистам, они были в диких непонятках. Без понимания что код делает, его сложно понять, т.е. нужно идти и rtfm. А в мануале описаны основы и правила по которым что-то работает и как правило все работает как описано (что-то не припомню особых фейков). Да и при желании на пхп можно написать код, который вынесет мозг кому угодно, но будет работать как требовалось =) Код не может объяснить как конкретно он работает в разных случаях. Тут нужно все тестить. Или просто прочитать мануал =) Да, там могут не оговариваться дикие особенности, но после понимания что есть разница между == и ===, программист должен проклятсь нестрогую типизацию и начать думать как сравнивать правильно в том или ином случае.
В посте, конечно, приводятся примеры крайне неожиданные, хотя ни один из них я за 5 лет использования PHP не словил. Больше проблем было из-за вот этих табличек: PHP сравнения, пока не выучил =)
И вообще: PHP — отвратительный язык, с кучей граблей и т.п. Не используйте его! ;-)
PS: мечтаю о введении возможности указывать тип данных переменным
Мануал — истина в первой инстанции, а об особенностях все давно написано в комментариях к мануалу. Если вы встретили что-то совсем странное и необъяснимое — этого с очень высокой вероятностью нет в книгах, а если и есть, то фиг найдете среди сотен тех самых книг. Да и по-настоящему опытные программеры книг почти никогда не пишут — им это не нужно, они и без книг зарабатывают прилично.
Основы и особенности PHP прекрасно и чаще всего в полной мере описаны в мануале (в английской версии). Для этого не нужны книги и статьи, которые по сути дублируют мануал.
Если вы переходите с другого языка — потрудитесь почитать основы нового языка. Там покрыты все основные особенности и возможности языка. Более того — это бесплатно и вам точно не наврут, как это бывает в книгах.
По сути всю статью можно было уместить в ссылку на мануал про типы данных, их приведение и сравнение + добавить строчку «Внимательно читайте что возвращает функция и ознакомьтесь с примерами».
Да пребудет с вами Разум.
Тогда получается, что основное различие — сложность реализации грамотного подхода и знании косяков и особенностей СУБД. Лично мне куда проще грамотно реализовать БД на постгресе чем на мускле и я точно буду знать что все что я делаю будет работать так как описано в документации, ни больше, ни меньше. Да, не все в постгресе делается просто и удобно, зато работает как надо, а это куда важнее удобства =)
MariaDB, я тоже пробовал, но по производительности на той же БД с выключенным кешированием на сайте постгрес ее выиграл с довольно большим отрывом в условиях большого количества запросов (не помню точно сколько было запросов в БД, но на страницу лилось 40 запросов в секунду, мускл сдох на 25-30, мария — пережила спам, но довольно туго). С кешированием итак все понятно, хотя мускл и тут умудрился сдохнуть (я так и не выяснил почему, перепробовал кучу настроек, переустановил сервер, снес и заново залил БД — толку 0)
Мне, видимо, повезло в универе поучить стандартный sql с основными его возможностями. Стандарт — прекрасен. А вот диалект mysql довольно сильно отличается от стандартного sql как минимут своей условной типизированностью и особенностями в выполнении запросов (на сколько помню group by делает совершенно не то, что должен по стандарту). Да и что-то я не заметил чтобы запросы в mysql кешировались (я имею ввиду query cache и сохранения плана выполнения запроса) — сколько не запускай запрос, он будет выполнятся столько же сколько и предыдущий. В постгресе — после первого запроса, последующие аналогичные запросы выполняются в разы быстрее. Да и все неправильные запросы, проходящие в мускле вылетаю в постгресе, что на самом деле правильно — лучше знать об ошибке, чем потом биться головой об стены пытаясь понять что и где косячит
Да, минус ужасен, надо возвращатся на мускл =)
Я уже прилично порботал с обоими СУБД и сложилось устойчивое мнение, что мускл значительно проще для освоения т.к. в нем слабая типизированность и много допущений и упрощений, которые в итоге губят производительность. Постгрес же — строгий, я когда только начал на него переходить очень сильно этому обрадовался. Строгость многих отпугивает ибо заставляет думать. Потом еще выяснилось что постгрес умеет кучу всего, что в мускле считается нестабильным, медленным или недостаточно допиленным функционалом. Или вообще отсутствует. Как по мне — в постгресе нет ничего сверх сложного, нужно лишь усвоить несколько отличий и привыкнуть к ним.
Полезные советы. Но вот у меня все чаще возникает вопрос — почему так часто для высоконагруженных проектов используется mysql, который разрабатывался для баз данных среднего объема и требует дико шаманских настроек чтобы работать достаточно быстро?
Я уже 2 раза (1 раз сам, 2й раз досталось по наследству) напоролся на грабли с производительностью mysql и зарекся его использовать для проектов с потенциально высокой нагрузкой. Те проекты и новые используют posgresql. Уже 3 года я не сталкивался с проблемами производительности — работает как часики + куча полезных возможностей типа триггеров.
Может мне кто-нибудь объяснить почему postgresql использут значительно реже чем mysql?
Многообещающий фреймворк стал чуть ли не единственной нормальной (быстрой) заменой других фреймов.
У меня уже руки чешутся попробовать, но пока не на чем — существующий проект уже довольно большой чтобы его переписывать =(
Опробую на одной из своих идей, вдруг он еще круче чем на словах? =)
PS: Ну вот за что? За что вы так с нами жестоко? =(
4й вариант, конечно прекрасен, но невозможен при использовании PDO т.к. нет альтернативы для pg_affected_rows/pg_cmdtuples и нет возможности вызвать их из-за отсутствия ресурса, который они требуют.
Также в сам postgres не нашел возможности узнать какую-либо информацию о позиции курсора.
Есть еще варианты?
Если имеется доступ к таблице, то в чем проблема выкачать ее всю?
1. Учитывая количство акаунтов, у RIOT наверняка очень хитрая БД (распределенная или чего пострашнее, я не особо разбираюсь в этом). Это усложняет быстрое получение всех данных. Так и получается, что не все данные стырены.
2. Попытка стянуть сразу все данные приведет к ощутимой нагрузке на БД и каналов передачи данных, а это наверняка мониторится. Т.е. нужно тянуть понемногу чтоб не спалиться.
3. Процесс стягивания спалили и он небыл завершен (объясняет почему только «для небольшого количества пользователей» были стянуты «имена, фамилии и зашифрованые секретные вопросы с ответами»)
На тему укрепления продольных мышц спины: очень хорошо помогает совмещение катания на роликах (тех, котороый одеваются на ноги) и плавание. Лучше всего регулярно.
Уточню про ролики: желательно не просто кататься по прямой, а пробовать различные слаломные элементы — многие из них требуют несильных вращательных движений туловища, постоянное смещение центра тяжести и прочих «мягких» издевательств над телом. К тому же катание помогает разгрузить мозг, что для IT-шников тоже приветствуется =)
PS: из личного опыта — пол года катания на роликах (+ бассейн/море) и я уже почти забыл про дискомфорт в пояснице и вообще чувствую себя лучше. «Почти» потому, что не каждую неделю могу выделить время на катание или плавание, в результате чего иногда все-же неприятные ощущения возвращаются.
Когда выбирал переслушал cx начиная с 300-2 и ie4 (ie5 и выше были уже за пределами толщины кошелька). IE4 однозначно лучше и чище звучат. Ради интереса потом провел тест на максимальной громкости. Результат слегка удивил т.к. качество почти не ухудшилось и барабанные перепонки остались на месте =)
cx-400 вообще не смог вставить — орут как бешенные, а искажения даже на 80% громкости очень серьезные.
PHP pastie.org/927648
Время — 30 минут / финальный вариант достигнут после 3го запуска
с достаточным набором тестов для чисел. Строки не тестил, но теоретически поддерживаются =)
Решение возможно не совсем стандартное т.к. использовал рекурсию (мне так захотелось) и возможность сравнивать строки, а вариант из википедии или другие варианты не смотрел ибо было бы читерством =)
Да, я знаю что такое «арматура» и что ее использовали очень давно для весьма специфических целей. И косяки мне известны.
Я согласен, что маркетинг — зло, но не стоит из-за этого списывать продукт в утиль и бросаться на всех, кто нашел в этом продукте смысл. Хоть технология и не новая, но сейчас ее довели до того, что в относительно небольшой корпус можно вместить до 4х арматур, что и позволило значительно улучшить звучание.
Действительно, однодрайверные наушники — фуфло редкостное. Нормальные динамические их как стоячих обойдут по всем параметрам, но вот двухдрайверные — это совершенно другой звук. Лично мне 2х-драйверные арматуры нравятся по звучанию значительно больше чем динамические наушники, хоть и стоят дороже. И я слышу разницу, причем весьма ощутимую. И да — я слушал много динамических наушников разных фирм и уровней, сравнивать есть с чем.
На тему ремонта — в хачь-палатку на ремонт отдавай свои наушники, не стоит посылать туда других. В такой палатке как минимум нет качественных проводов для замены, а плохой провод и звук убьет и сдохнет быстро. Пара таких «ремонтов» и наушники можно выбрасывать. И это еще если они их вообще сумеют разобрать-собрать =)
PS: я сравниваю только внутриканальные наушники
PSS: слух у меня хороший, не жалуюсь и я уже вышел за рамки нормальности т.к. звук многих динамических наушников меня не радует, да и некоторые арматуры тоже не ахти. Просто я нашел «свои» арматурки и не хочу с ними расставаться ибо лучше них за адекватную цену я ничего не слушал.
Разве что не полностью согласен с одним минусом — «Узкая звуковая сцена». Это справедливо не для всех IEM. Есть экземпляры с довольно широкой сценой (Creative Aurvana In-Ear 3, например), хотя большинство действительно с довольно узкой сценой.
Срок службы при постоянном использовании обычно сильно ограничивается проводом. У меня провода живут 1-1,5 года, после чего их приходится либо чинить, либо менять (что довольно дорого и мало кто берется, особенно если арматурки). Есть модели со съемным кабелем, что удешевляет замену, но при этом сами наушники сильно дорожат, что довольно печально. Как вариант — найти мастеров, которые модифицируют наушники так, что кабель будет съемным. Я вот свои Aurvanы недавно отдал на такую модификацию. Вместе с проводом это стоило 80% цены наушников. Первоначально хотел купить новые, но за адекватную цену совершенно ничего хотябы такого-же по качеству звучания не нашел — дешевле было модифицировать. Результат пока не тестировал — в процессе пересылки. Как приедут — отпишусь о результате, если не забуду.
2. В свернутом режиме нажать на название трека и перейти в полный режим, где уже и перемотать куда надо
Решения не особо эффективные, но они есть.
Что мешает при открытии трека перемотать ползунком на нужное место?
По умолчанию трек открывается полном режиме, где есть ползунок, т.е. приблемы как бы нет =)
У музыки нет ползунка тоьлко в свернутом виде, но как по мне он там и не нужен. И вообще я не понимаю зачем это нужно при прослушивании уже отобранной музыки.
Видео html 5 имеет достаточно управления — play/pause, fullscreen, полоса прокрутки.
Другое дело если плеер html5 кастомизирован, тогда косяков много, но это касается всех мобильных платформ. Как показала практика — меньше всего проблем при использовании стандартного html5 плеера (winphone/android) или вообще отдавать видео файл операционке (ios).
В посте, конечно, приводятся примеры крайне неожиданные, хотя ни один из них я за 5 лет использования PHP не словил. Больше проблем было из-за вот этих табличек: PHP сравнения, пока не выучил =)
И вообще: PHP — отвратительный язык, с кучей граблей и т.п. Не используйте его! ;-)
PS: мечтаю о введении возможности указывать тип данных переменным
Основы и особенности PHP прекрасно и чаще всего в полной мере описаны в мануале (в английской версии). Для этого не нужны книги и статьи, которые по сути дублируют мануал.
Если вы переходите с другого языка — потрудитесь почитать основы нового языка. Там покрыты все основные особенности и возможности языка. Более того — это бесплатно и вам точно не наврут, как это бывает в книгах.
По сути всю статью можно было уместить в ссылку на мануал про типы данных, их приведение и сравнение + добавить строчку «Внимательно читайте что возвращает функция и ознакомьтесь с примерами».
Да пребудет с вами Разум.
MariaDB, я тоже пробовал, но по производительности на той же БД с выключенным кешированием на сайте постгрес ее выиграл с довольно большим отрывом в условиях большого количества запросов (не помню точно сколько было запросов в БД, но на страницу лилось 40 запросов в секунду, мускл сдох на 25-30, мария — пережила спам, но довольно туго). С кешированием итак все понятно, хотя мускл и тут умудрился сдохнуть (я так и не выяснил почему, перепробовал кучу настроек, переустановил сервер, снес и заново залил БД — толку 0)
Мне, видимо, повезло в универе поучить стандартный sql с основными его возможностями. Стандарт — прекрасен. А вот диалект mysql довольно сильно отличается от стандартного sql как минимут своей условной типизированностью и особенностями в выполнении запросов (на сколько помню group by делает совершенно не то, что должен по стандарту). Да и что-то я не заметил чтобы запросы в mysql кешировались (я имею ввиду query cache и сохранения плана выполнения запроса) — сколько не запускай запрос, он будет выполнятся столько же сколько и предыдущий. В постгресе — после первого запроса, последующие аналогичные запросы выполняются в разы быстрее. Да и все неправильные запросы, проходящие в мускле вылетаю в постгресе, что на самом деле правильно — лучше знать об ошибке, чем потом биться головой об стены пытаясь понять что и где косячит
Я уже прилично порботал с обоими СУБД и сложилось устойчивое мнение, что мускл значительно проще для освоения т.к. в нем слабая типизированность и много допущений и упрощений, которые в итоге губят производительность. Постгрес же — строгий, я когда только начал на него переходить очень сильно этому обрадовался. Строгость многих отпугивает ибо заставляет думать. Потом еще выяснилось что постгрес умеет кучу всего, что в мускле считается нестабильным, медленным или недостаточно допиленным функционалом. Или вообще отсутствует. Как по мне — в постгресе нет ничего сверх сложного, нужно лишь усвоить несколько отличий и привыкнуть к ним.
Я уже 2 раза (1 раз сам, 2й раз досталось по наследству) напоролся на грабли с производительностью mysql и зарекся его использовать для проектов с потенциально высокой нагрузкой. Те проекты и новые используют posgresql. Уже 3 года я не сталкивался с проблемами производительности — работает как часики + куча полезных возможностей типа триггеров.
Может мне кто-нибудь объяснить почему postgresql использут значительно реже чем mysql?
У меня уже руки чешутся попробовать, но пока не на чем — существующий проект уже довольно большой чтобы его переписывать =(
Опробую на одной из своих идей, вдруг он еще круче чем на словах? =)
PS: Ну вот за что? За что вы так с нами жестоко? =(
Также в сам postgres не нашел возможности узнать какую-либо информацию о позиции курсора.
Есть еще варианты?
1. Учитывая количство акаунтов, у RIOT наверняка очень хитрая БД (распределенная или чего пострашнее, я не особо разбираюсь в этом). Это усложняет быстрое получение всех данных. Так и получается, что не все данные стырены.
2. Попытка стянуть сразу все данные приведет к ощутимой нагрузке на БД и каналов передачи данных, а это наверняка мониторится. Т.е. нужно тянуть понемногу чтоб не спалиться.
3. Процесс стягивания спалили и он небыл завершен (объясняет почему только «для небольшого количества пользователей» были стянуты «имена, фамилии и зашифрованые секретные вопросы с ответами»)
Уточню про ролики: желательно не просто кататься по прямой, а пробовать различные слаломные элементы — многие из них требуют несильных вращательных движений туловища, постоянное смещение центра тяжести и прочих «мягких» издевательств над телом. К тому же катание помогает разгрузить мозг, что для IT-шников тоже приветствуется =)
PS: из личного опыта — пол года катания на роликах (+ бассейн/море) и я уже почти забыл про дискомфорт в пояснице и вообще чувствую себя лучше. «Почти» потому, что не каждую неделю могу выделить время на катание или плавание, в результате чего иногда все-же неприятные ощущения возвращаются.
cx-400 вообще не смог вставить — орут как бешенные, а искажения даже на 80% громкости очень серьезные.
pastie.org/927648
Время — 30 минут / финальный вариант достигнут после 3го запуска
с достаточным набором тестов для чисел. Строки не тестил, но теоретически поддерживаются =)
Решение возможно не совсем стандартное т.к. использовал рекурсию (мне так захотелось) и возможность сравнивать строки, а вариант из википедии или другие варианты не смотрел ибо было бы читерством =)