Я использую unless только в одном единственном случае — в качестве замены простого условия if с отрицанием, т.к. в простом условии можно знак восклицания не заметить при беглом взгляде на код.
Т.е. вместо if(!$a) пишу unless($a) или вместо if(!($a > 5)) пишу unless($a > 5).
Одна из целей FizzBuzz как раз в том, чтобы увидеть пример кода кандидата.
Если бы вы пришли ко мне на собеседование и написали решение в таком виде — вы бы не прошли :)
Вот за такой код в реальном проекте я готов оторвать руки, у меня нет ни малейшего желания распутывать хитросплетения воспаленного мозга автора кода, когда нужно что-то исправить или просто понять, что код делает. Сравните
Было бы интересно услышать ответы на следующие вопросы.
1. Вы ограничиваете скорость отдачи видеофайлов?
2. Отдача происходит непосредственно с файлового сервера, или проксируется через сервер конвертации?
3. Каждый видеофайл хранится в одном экземпляре на одном файловом сервере?
4. На файловых серверах raid1?
5. Что делаете при обнаружении горячего видеофайла, когда, к примеру, несколько десятков человек одновременно смотрят его?
Для загрузки картинок (небольших файлов) ваш код условно подходит.
По-нормальному, надо без извращений с ручным формированием тела запроса использовать FormData
Любой файлообменник рано или поздно ждет один из нижеописанных вариантов:
1. Уход в небытие
2. Переход на агрессивную рекламу
3. Переход на премиум-аккаунты и урезание возможностей непремиум-пользователей
Затраты на содержание файлообменника достаточно велики — сервера, каналы, ломающиеся диски и т.д., и нужно где-то брать деньги для этого.
А что делать дальше в ситуации, когда вы активировали уведомление на сайте, но пользователь его не прочел?
Очевидно, что при активации уведомления на сайте вам нужно поместить задание на отсылку письма в очередь, которое (задание) будет выполнено в заданное время. Если в течение заданного промежутка времени пользователь «прочитал» уведомление на сайте, то вам нужно удалить это задание из очереди, если не прочитал и настал час Х — выполнить это задание и послать письменное уведомление.
А теперь сложите всё вместе (отслеживание онлайновости через сохранение в мемкэше информации на каждый чих пользователя), создание системы уведомлений на сайте с возможностью пометки их «прочтенными», колбек на событие «прочтения» уведомления на сайте и очередь заданий на отсылку писем. И вы получите примерную оценку сложности подобной системы.
Уважаемый, если вы относите себя к таким программистам, и в личку (или здесь) сможете досконально описать схему реализации вплоть до используемого ПО и примерные сроки её внедрения (включая программирование), то я вам поставлю плюс за комментарий, если не сможете — минус. Согласны?
Вы хотя бы примерно представляете себе сложность реализации подобной схемы?
Есть мнение, что небольшие сайты не станут с ней возиться именно по причине её сложности.
2. Вся логика очереди загрузки (и fallback в том числе) реализована в javascript. Изначально так сложилось потому, что JS для нас саппортить гораздо легче и проще, нежели код плагинов (хорошо, что в Silverlight это C#, в случае Flash это птичий язык под названием Actionscript).
Как это реализовано.
Каждый плагин (Flash и Silverlight) сделан максимально простым: он умеет показывать диалог выбора файла, вызывать JS-callback о выборе файла(ов) и загружать файлы на заданный адрес, вызывая колбэки прогресса загрузки, окончания загрузки и ошибок загрузки. После своей инициализации на странице плагин вызывает JS-callback; если после вставки кода плагина на страницу в течение заданного таймаута callback не был вызван — значит либо что-то не так с плагином, либо банерорезка его «зарезала», либо просто медленный канал/компьютер у пользователя. В этом случае мы откатываемся: в случае отката на Flash повторяется такая же процедура ожидания, в случае отката на iframe нам нужен только javascript, поэтому никакого ожидания нет.
3. Не смотрели, потому что имхо технология пока находится в стадии альфы.
Возможно посмотрим тогда, когда nginx будет нативно их поддерживать.
Пока мы следим за развитием JS FileAPI и ждем, когда ребята из мозиллы разродятся Blob'ами и Firefox4 выйдет из состояния беты для того, чтобы сходный функционал дозагрузки можно было реализовать только лишь средствами JS, без помощи Silverlight.
Да, мы знаем об этой баге в Safari под MacOS…
Это либо баг сафари, либо сильверлайта.
Если вас не затруднит, не могли бы вы посниферить http-запросы при загрузке страницы? :)
Кстати, вспомнил еще одну причину ограничения размера чанка сверху — это антивирусы (пламенный привет лаборатории Касперского), которые всенепременно хотят проверить, что же пользователь отправляет в сеть, и тем самым при загрузке больших файлов провоцируют таймауты в Flash-загрузчике, которые (таймауты) в Flash'е увы нам неподвластны.
будем делать чанками, ибо IO-операции так принято делать
Так в том всё и дело, что сильверлайт позволяет читать файл чанками, и даже отправлять чанками в пределах одного POST-запроса, периодически делая Flush. Но видимо из-за невозможности вручную выставить Content-Length сильверлайт целиком буферизует запрос (несмотря на Flush'и) и только после полной буферизации (когда он уже знает длину запроса) добавляет к запросу заголовок Content-Length и отправляет его на сервер.
Самым «вкусным» в виде Blob вы не воспользовались.
Нельзя использовать readAsBinary, на больших файлах это сожрет всю память юзера.
А вы пробовали вешать обработчик на xhr.upload.onprogress?
Т.е. вместо if(!$a) пишу unless($a) или вместо if(!($a > 5)) пишу unless($a > 5).
Если бы вы пришли ко мне на собеседование и написали решение в таком виде — вы бы не прошли :)
foreach my $i (1..100) {
unless($i % 3) {
print «Fizz»;
}
unless($i % 5) {
print «Buzz»;
}
if($i % 3 && $i % 5) {
print $i;
}
print "\n";
}
1. Вы ограничиваете скорость отдачи видеофайлов?
2. Отдача происходит непосредственно с файлового сервера, или проксируется через сервер конвертации?
3. Каждый видеофайл хранится в одном экземпляре на одном файловом сервере?
4. На файловых серверах raid1?
5. Что делаете при обнаружении горячего видеофайла, когда, к примеру, несколько десятков человек одновременно смотрят его?
По-нормальному, надо без извращений с ручным формированием тела запроса использовать FormData
1. Уход в небытие
2. Переход на агрессивную рекламу
3. Переход на премиум-аккаунты и урезание возможностей непремиум-пользователей
Затраты на содержание файлообменника достаточно велики — сервера, каналы, ломающиеся диски и т.д., и нужно где-то брать деньги для этого.
Очевидно, что при активации уведомления на сайте вам нужно поместить задание на отсылку письма в очередь, которое (задание) будет выполнено в заданное время. Если в течение заданного промежутка времени пользователь «прочитал» уведомление на сайте, то вам нужно удалить это задание из очереди, если не прочитал и настал час Х — выполнить это задание и послать письменное уведомление.
А теперь сложите всё вместе (отслеживание онлайновости через сохранение в мемкэше информации на каждый чих пользователя), создание системы уведомлений на сайте с возможностью пометки их «прочтенными», колбек на событие «прочтения» уведомления на сайте и очередь заданий на отсылку писем. И вы получите примерную оценку сложности подобной системы.
С нетерпением жду пост об определении онлайновости пользователя.
Есть мнение, что небольшие сайты не станут с ней возиться именно по причине её сложности.
Глюк рендеринга сафари, проявлялся только под MacOS почему-то…
2. Вся логика очереди загрузки (и fallback в том числе) реализована в javascript. Изначально так сложилось потому, что JS для нас саппортить гораздо легче и проще, нежели код плагинов (хорошо, что в Silverlight это C#, в случае Flash это птичий язык под названием Actionscript).
Как это реализовано.
Каждый плагин (Flash и Silverlight) сделан максимально простым: он умеет показывать диалог выбора файла, вызывать JS-callback о выборе файла(ов) и загружать файлы на заданный адрес, вызывая колбэки прогресса загрузки, окончания загрузки и ошибок загрузки. После своей инициализации на странице плагин вызывает JS-callback; если после вставки кода плагина на страницу в течение заданного таймаута callback не был вызван — значит либо что-то не так с плагином, либо банерорезка его «зарезала», либо просто медленный канал/компьютер у пользователя. В этом случае мы откатываемся: в случае отката на Flash повторяется такая же процедура ожидания, в случае отката на iframe нам нужен только javascript, поэтому никакого ожидания нет.
3. Не смотрели, потому что имхо технология пока находится в стадии альфы.
Возможно посмотрим тогда, когда nginx будет нативно их поддерживать.
Пока мы следим за развитием JS FileAPI и ждем, когда ребята из мозиллы разродятся Blob'ами и Firefox4 выйдет из состояния беты для того, чтобы сходный функционал дозагрузки можно было реализовать только лишь средствами JS, без помощи Silverlight.
Это либо баг сафари, либо сильверлайта.
Если вас не затруднит, не могли бы вы посниферить http-запросы при загрузке страницы? :)
2. Он похоже не умеет деградировать при наличии банерорезок.
Так в том всё и дело, что сильверлайт позволяет читать файл чанками, и даже отправлять чанками в пределах одного POST-запроса, периодически делая Flush. Но видимо из-за невозможности вручную выставить Content-Length сильверлайт целиком буферизует запрос (несмотря на Flush'и) и только после полной буферизации (когда он уже знает длину запроса) добавляет к запросу заголовок Content-Length и отправляет его на сервер.