PHP изначально проектировался для stateless серверов для лучшей масштабируемости. При таком подходе действительно не плохая идея забыть о уборке мусора, все равно все освободим одним блоком после короткоживущего запроса. Apache выделяет и освобождает память под запросы большими блоками, что очень быстро. Такой подход позволяет обрабатывать безумное количество запросов (википедия, к примеру).
Нет смысла писать долгоживущие процессы на PHP. Даже со сборщиком мусора можно получить утечки в C-шных расширениях. Apache не расчитан на вебсокеты, он будет использовать память и пул тредов/процессов не эффективно. Это совершенно другой класс задачь, под который нужные другие инструменты. Для очень-быстрого масштабируемого front-end'а PHP подходит очень не плохо.
P.S. мои 2 года PHP, затем 3 года Python/Django (нынешнее время) подсказывают мне, что каждый инструмент имеет свою нишу и один не сильно лучше другого.
Виноваты не устройства, а странная привычка некоторых операционных систем запускать все подряд с самых разных накопителей с правами пользователя, которые до недавнего времени не ограничивались. Autorun, ведь его кто-то придумал…
У вас есть внутренний API и его аналог, опубликованный через REST. Вам ничего не мешает внутренний API также опубликовать через SOAP или вебсокеты. Другое дело, что с вебсокетами вы меняете сам принцип запрос-ответ на потоковое вещание, что выглядит как минимум странно.
Для питона есть Sphinx. Он не только строит документацию, включая в нее API доку из исходников, но и может запускать тесты из docstring'ов. Или просто запускать тесты во время билда, кому как нравиться. Главное, что можно не ограничиваться только API докой, можно писать полноценную документацию. Пример и сорцы. Просто пример, как это может быть чуть более кратко.
Выглядит будто наше пространство плотное и чем больше скорость объекта, тем больше его сопротивление, тем больше нужна сила/энергия на его преодоление. Но что, если есть какое-то иное пространство с меньшей «плотностью»? Пусть супер массивные или супер горячие, супер малые или еще какие «супер» тела могут на это менее плотное пространство переходить. И там скорость света будет выше. Хотя это все фантазии.
Мне кажется, что вывод «нет шутника» не доказан. Не возможно двигаться быстрее света, да, но о перемещениях вне нашего пространства вроде ничего запретного не было. Но я дилетант, буду благодарен за любое опровержение.
и причина её рождения для нас будет выглядеть как следствие.
И это не возможно? Если отделить «реальность» от наблюдения, разве не возможна такая реальность, что звезда родиться и умрет, двигаясь выше скорости света в нашу сторону. Пусть это будет в каком то особом пространстве, где это возможно, излучая в «обычном пространстве» свет. Да, мы увидим смерть звезды раньше и ее рождение будет для нас «следствием». Не знаю, получиться ли просмотреть жизнь звезды наоборот или там будут какие другие эффекты, но смысл один: наблюдение, привязанное к нашему времени, не одно и то же, что и «реальное событие».
Аналогия: TCP/IP пакеты могут приходить совершенно в разных последовательностях. Вместо отрицания реальности, мы научились по некоторому признаку (счетчик) восстанавливать оригинальную последовательность во времени. Зная расстояние до сервера, можно уточнить самое малое время, требуемое сигналу на прохождение по медным кабелям. Вселенная эволюционирует и вот уже от сервера до нашего провайдера лежит быстрое оптоволокно с быстрыми роутерами и минимальное время сократилось. Часть пакетов идет по старым кабелям, часть по новым. От провайдера у нас тот самый старый кабель, так, что об изменениях мы ничего не знаем. Мы же не приходим в ужас, наблюдая «будущие» пакеты раньше чем «прошлые».
Я сейчас напишу глупость, но все же не вижу причинно-следственных проблем
с возможностью двигаться быстрей скорости света. Допустим родилась звезда на
расстоянии тысячи световых лет от нас. Прожила она всего год и собирается
взорваться. Тут некий шутник мгновенно переносит звезду к нам поближе на
расстояние 500 световых лет. Финал жизни звезды мы увидим раньше ее рождения
и начнем рассуждать: звезда не может умереть раньше своего рождения, а значит
это две разных звезды. И это наше личное заблуждение, не имеющее ничего общего
с «реальностью».
Быть может есть какие-то признаки, по которым можно доказать, что оба события
связаны с одной звездой, но наблюдаем мы их в не правильной последовательности.
Это наталкивает на мысль, что звезда движется со скоростью превышающей скорость
света. В конечном итоге, картинка, что идет со скоростью света не одно и то же,
что и «реальное событие». Будет немного не приятно, что глядя на небо и на часы
в руке нельзя быть уверенным в истинной последовательности наблюдаемых событий.
При таком взгляде путешествие назад во времени остается без ответа, но двигаться
быстрей скорости света вроде не запрещено. Разделяются такие понятия как событие и
его наблюдение в разных точках пространства/времени. Буду благодарен за
умозрительный эксперимент, дающий какое либо противоречие.
У нас на экзамене запрещено находиться с включеным телефоном. Если издаст звук или просто возьмешь его в руки, то будешь выпровожен за дверь. Пересдача в следующем блоке. Никто права не качает.
Проходил стаж в одной компании, что разрабатывает баллоны и стенды для подобных операций. Вводиться катетер в сосуд, выводиться на нужную позицию, надувается физ. раствором и все, канал чист. В особо запущенных случаях с баллоном идет стенд - металлическая сетка цилиндром. Расширяется баллоном и остается на месте в сосуде, не давая ему снова слипнуться/зарасти. Катетер. Больше рекламы.
Есть шанс, что он еще подешевеет. Бук расчитан на потребление сервисов из сети (в реальном времени), 32GB SSD явно на это намекает. Доходы с сервисов могут уйти на скидки к буку в будущем.
Экран хороший. Явно основные расходы туда ушли. Если бы еще умел поворачиваться на 180, превращаясь в подобие большого планшета — вообще было бы отлично. Потреблялке стевых сервисов важны экран, батарейка и интерфейсы (SD читалка, к примеру, сразу с фотика на Picasa). Батарейка как-то не вызывает теплых чувств.
«Фон» событий не меняется от строчки к строчке. Достаточно отслеживать скорость перелистывания и предполагать где сейчас читатель. Смена фона будет максимум раз на параграф, лучше реже, иначе может раздражать. Идея хорошая и не сложная в реализации, но потребуются хорошие семплы шумов (город, кафе, религиозное бормотание, смех в опиумной и т.д.).
Тут личность скорее не ООП, а Jav'иус, человек для которого ООП только в лице Java (чистый ООП красив для моделирования). А это упор не на поведение (как примеру интерфейсы в go), а на иерархию типов. В итоге имеем разного рода адаптеры, proxy и прочее.
А если кратко: попытка забивать одним молотком все «гвозди». Отрицание самой идеи, что под разные задачи языки отличные от Java/C# могут справляться лучше. Ну и конечно истерика при виде связки Erlang + Lua (drive-in) для сильно нагруженного сервиса.
Да, WSDL можно вынести в отдельну личность. Все его проблемы в Java – отсутствие мета-программирования, как итог: генерация статичного кода. Это не проблема языка, это проблема мышления.
Как нужно написать тесты, чтобы потом пришлось выделить половину ресурсов на их поддержку?
Главная проблема — сложность тестов и несоотствствие со спецификациями, которые тест проверяет. Количество тестов может расти, но каждый индивидуальный тест должен быть в идеале простым. С новым функционалом должно расти количество, но не сложность тестов. С изменяющимися спецификациями изменяются тесты, что просто, если сами тесты простые. На практике, если каждый тест стал безобразно большим и сложным, то тут поработала темная сторона. Малейшее изменение спецификации (неизбежно) потребует много времени на обновление тестов. В итоге команда делиться на тех, кто пишет фичи и тех, кто тащит на себе тяжелые и быстро устаревающие тесты.
Если каждый отдельный тест становиться безобразно сложным, то пора точней разобраться в спецификации и разбить каждый тест на более мелкие и простые. Ну и не бояться выбрасывать старые тесты.
Дарт ООПиум. Вечно молодой и задорный ситх, главное оружие которого «Молот ООП». С легкостью берется писать на любом языке, но не способен профессионально овладеть ничем, кроме Java/C#. В итоге мыслит в Java/C#, что сразу отражается на коде: безумное количество «классов», *Factory, попытки закодить типозависимость в языках с duck-typing и многое другое. Изнасиловал JavaScript введя дескрипторы типов и их проверку, incapsulation через getter/setter properties, наследование с глубоким деревом «типов». Презирает мета-программирование и всячески пытается его уничтожить. По этой причине не понимает и отвергает Ruby/Python. Обожает SOAP сервисы и генерить десятки классов из WSDL. Еще больше любит пересобирать и деплоить весь проект, когда меняется мелочь в WSDL. Пытался подчинить себе Erlang, но сдался - нет классов; сейчас молиться на Akka.
Эх, решил же для себя, не комментировать не технические топики… не удержался, слили карму))
Я не разделяю политику литреса. Не защищаю их. Не работаю на них. Я просто довольный пользователь, не более. И еще я отличаю руководство проекта от самого проекта, связанных с ним инженеров и т.п. Литрес как продукт мне нравиться (эх, сейчас в минус уйду)). Литрес как организация - говно.
Это как Apple. Организация, точнее юридический отдел - говно. Инженеры - молодцы. Мак буки - хороший продукт (хотя телефоны говно). А за игру на патентах надо ставить к стенке. Любая организация - это много народу с разными интересами. Так вот взбучка руководства за наезды — это хорошо. А вот если это скажется на сервисе и он исчезнет, как минимум один человек пожалеет. Удобно у них.
Эх, жалко, что все так вышло. LitRes хороший портал. Регулярно покупаю книги в ePub и отказ от DRM'а (читай на любой читалке) их самый большой плюс. Также удобно, что книги продолжают лежать на аккаунте, можно всегда вернуться и дочитать с их собственной читалки.
Они просто ступили, такое бывает. Хочется извинений (уже извинились) и восстановления всех пострадавших приложений. Но так не хочется, что бы их толпой «затоптали».
Самое интересное в таких видео - разговоры пилотов в тимспике. Командная работа. Но почему то в подавляющем большинстве видео все разговоры убирают и накладывают (не редко убогую) музыку. В итоге не посвященному человеку совсершенно не ясно, что происходит на экране.
Видео с тимспиком - редкие брильянты в куче Евовского видео на ютубе. Жаль, что традиця резать разговоры до сих пор в моде.
Нет смысла писать долгоживущие процессы на PHP. Даже со сборщиком мусора можно получить утечки в C-шных расширениях. Apache не расчитан на вебсокеты, он будет использовать память и пул тредов/процессов не эффективно. Это совершенно другой класс задачь, под который нужные другие инструменты. Для очень-быстрого масштабируемого front-end'а PHP подходит очень не плохо.
P.S. мои 2 года PHP, затем 3 года Python/Django (нынешнее время) подсказывают мне, что каждый инструмент имеет свою нишу и один не сильно лучше другого.
Мне кажется, что вывод «нет шутника» не доказан. Не возможно двигаться быстрее света, да, но о перемещениях вне нашего пространства вроде ничего запретного не было. Но я дилетант, буду благодарен за любое опровержение.
И это не возможно? Если отделить «реальность» от наблюдения, разве не возможна такая реальность, что звезда родиться и умрет, двигаясь выше скорости света в нашу сторону. Пусть это будет в каком то особом пространстве, где это возможно, излучая в «обычном пространстве» свет. Да, мы увидим смерть звезды раньше и ее рождение будет для нас «следствием». Не знаю, получиться ли просмотреть жизнь звезды наоборот или там будут какие другие эффекты, но смысл один: наблюдение, привязанное к нашему времени, не одно и то же, что и «реальное событие».
Аналогия: TCP/IP пакеты могут приходить совершенно в разных последовательностях. Вместо отрицания реальности, мы научились по некоторому признаку (счетчик) восстанавливать оригинальную последовательность во времени. Зная расстояние до сервера, можно уточнить самое малое время, требуемое сигналу на прохождение по медным кабелям. Вселенная эволюционирует и вот уже от сервера до нашего провайдера лежит быстрое оптоволокно с быстрыми роутерами и минимальное время сократилось. Часть пакетов идет по старым кабелям, часть по новым. От провайдера у нас тот самый старый кабель, так, что об изменениях мы ничего не знаем. Мы же не приходим в ужас, наблюдая «будущие» пакеты раньше чем «прошлые».
с возможностью двигаться быстрей скорости света. Допустим родилась звезда на
расстоянии тысячи световых лет от нас. Прожила она всего год и собирается
взорваться. Тут некий шутник мгновенно переносит звезду к нам поближе на
расстояние 500 световых лет. Финал жизни звезды мы увидим раньше ее рождения
и начнем рассуждать: звезда не может умереть раньше своего рождения, а значит
это две разных звезды. И это наше личное заблуждение, не имеющее ничего общего
с «реальностью».
Быть может есть какие-то признаки, по которым можно доказать, что оба события
связаны с одной звездой, но наблюдаем мы их в не правильной последовательности.
Это наталкивает на мысль, что звезда движется со скоростью превышающей скорость
света. В конечном итоге, картинка, что идет со скоростью света не одно и то же,
что и «реальное событие». Будет немного не приятно, что глядя на небо и на часы
в руке нельзя быть уверенным в истинной последовательности наблюдаемых событий.
При таком взгляде путешествие назад во времени остается без ответа, но двигаться
быстрей скорости света вроде не запрещено. Разделяются такие понятия как событие и
его наблюдение в разных точках пространства/времени. Буду благодарен за
умозрительный эксперимент, дающий какое либо противоречие.
На каком основании она уничтожилась? Опишите этот процесс.
Экран хороший. Явно основные расходы туда ушли. Если бы еще умел поворачиваться на 180, превращаясь в подобие большого планшета — вообще было бы отлично. Потреблялке стевых сервисов важны экран, батарейка и интерфейсы (SD читалка, к примеру, сразу с фотика на Picasa). Батарейка как-то не вызывает теплых чувств.
Ждем скидок в 40% и оно может пойти на ура.
А если кратко: попытка забивать одним молотком все «гвозди». Отрицание самой идеи, что под разные задачи языки отличные от Java/C# могут справляться лучше. Ну и конечно истерика при виде связки Erlang + Lua (drive-in) для сильно нагруженного сервиса.
Да, WSDL можно вынести в отдельну личность. Все его проблемы в Java – отсутствие мета-программирования, как итог: генерация статичного кода. Это не проблема языка, это проблема мышления.
Главная проблема — сложность тестов и несоотствствие со спецификациями, которые тест проверяет. Количество тестов может расти, но каждый индивидуальный тест должен быть в идеале простым. С новым функционалом должно расти количество, но не сложность тестов. С изменяющимися спецификациями изменяются тесты, что просто, если сами тесты простые. На практике, если каждый тест стал безобразно большим и сложным, то тут поработала темная сторона. Малейшее изменение спецификации (неизбежно) потребует много времени на обновление тестов. В итоге команда делиться на тех, кто пишет фичи и тех, кто тащит на себе тяжелые и быстро устаревающие тесты.
Если каждый отдельный тест становиться безобразно сложным, то пора точней разобраться в спецификации и разбить каждый тест на более мелкие и простые. Ну и не бояться выбрасывать старые тесты.
Я не разделяю политику литреса. Не защищаю их. Не работаю на них. Я просто довольный пользователь, не более. И еще я отличаю руководство проекта от самого проекта, связанных с ним инженеров и т.п. Литрес как продукт мне нравиться (эх, сейчас в минус уйду)). Литрес как организация - говно.
Это как Apple. Организация, точнее юридический отдел - говно. Инженеры - молодцы. Мак буки - хороший продукт (хотя телефоны говно). А за игру на патентах надо ставить к стенке. Любая организация - это много народу с разными интересами. Так вот взбучка руководства за наезды — это хорошо. А вот если это скажется на сервисе и он исчезнет, как минимум один человек пожалеет. Удобно у них.
Они просто ступили, такое бывает. Хочется извинений (уже извинились) и восстановления всех пострадавших приложений. Но так не хочется, что бы их толпой «затоптали».
Эх, не надо резать разговоры. Если видео ускорено, от можно накладывать просто части самого интересного.
Видео с тимспиком - редкие брильянты в куче Евовского видео на ютубе. Жаль, что традиця резать разговоры до сих пор в моде.