Мое ИМХО пусть лучше будет С-style код но с четкой и понятной архитектурой, чем непонятная лапша из «красивого идиоматического Python» кода. К сожалению наблюдается обычно обратная ситуация и вся мощь и гибкость языка используется для того чтобы максимально запутать читателя такого кода.
Пинг падать уже не будет т.к. скорость света не вырастет :)
Другое дело что на самом деле важна половина пинга т.к. пинг это пересылка пакета в обе стороны.
В нашем случае сервер будет стримить картинку на ваш монитор т.е. только в одну сторону. обратно будут идти пакеты управления но они не так чувствительны к задержкам как видео сигнал.
Отличная статья.
Вы не пытались вынести расчеты на GPU? GPU должно быть намного быстрее чем потоки CPU. Если пытались какие проблемы возникли и почему отказались от такого решения?
Зачем запускать скрипт me_run чтобы из него запустить скрипт runme?? напоминает троллейбус из буханки :).
гораздо проще текущей директорией вима сделать корень проекта в котором лежит нужный скрипт и запускать его напрямую без каких то костылей.
Когда мыделаем pull или clone центрального репозитория, то мы должны забрать все изменения оттуда. Т. е. не только последнюю версию файла, а все дельты и снепшоты. В моем решении во время pull скачиваются только новые или обновленные файлы и только один раз.
Тут я с Вами согласен, однако стоит уточнить что все дельты скачиваются только если их у Вас еще не было, как правило при первоначальном checkout, потом передаются только изменения.
Кроме того это не отменяет того факта, что большие репозитории с большими файлами не получится хранить в Github или Bitbucket.
Вроде бы гитхаб не имеет жесткого ограничения на размер репозитория? Раньше я видел что ограничение было 2Гб и они предлагали предоставить больше места по требованию.
Меркуриал и гит не хранят дельты если размер дельт больше определенного процента размера файла, в такой ситуации они хранят копии файлов:
Для меркуриала есть механизм снепшотов который гарантирует что не требуется накладывать больше дельт чем нужно для получения целого файла
Гит оперирует всегда полными обьектами, расчет дельт выполняет нижний уровень который отвечает за хранение и для бинарников он как раз и будет держать копии файлов вместо дельт.
Кроме того я думаю что даже сжатие/расжатие дельт значительно быстрее скачки файлов по сети из облака
И в итоге ваш контролер будет работать только с 1 классом?
Как раз код со статическими методами сможет работать с одним классом, а обьект параметр может принадлежать любому классу наследнику My_Class.
И чем Dependency Injection поможет в данном случае?
Dependency Injection поможет избежать дублирования логики инциализации.
User::find($id);
Ваш пример не совсем корректен т.к. не достаточно контекста чтобы определить насколько данный код хорош или плох.
Могу высказать свое ИМХО по этому поводу.
class View — скорее всего это класс из ядра фреймворка и его изменение не планируется. соответственно статические метода для него вцелом допустимы.
class User — удобный и логичный метод по созданию обьектов. Однако скорее всего рано или поздно прийдется изменять логику обработки пользователей (например создать отдельный класс для анонимных пользователей или пользователей с особыми правами) в таком случае статический метод может помешать таким изменениям так что в данном случае он скорее не оправдан. Кроме того такой метод затруднит тестирование кода если мы захотим подложить в этот контроллер тестовых пользователей.
class Controller {
private $my_class;
public __construct(My_Class $myClass) {
$this->my_class = $myClass;
}
public function foo(){
return $this->my_class->foo();
}
public function bar(){;
return $this->my_class->bar();
}
}
Никто не говорит что инициализацию надо проводить каждый раз. А вам полезно было бы посмотреть на фреймворки а именно паттерн Dependancy Injection и его использование.
Ну по сути проблема не большая, параметры по ссылке дейстивтельно используются не часто (но иногда бывает полезно при обработке больших массивов например).
Тем не менее возможно стоило бы указать это как ограничение просто для того чтобы сэкономить кому то время и нервы.
Не знаю как в свежих версиях PHP но раньше были проблемы в случае передачи параметров по ссылке.
Насколько я помню func_get_args возвращала копию параметров и соответственно внутри функции по ссылке они уже не изменялись.
Ну об этом и речь — во всех примерах кода в посте огромное количество коментариев и большинство из них избыточны.
На мой взгляд такие коментарии просто засоряют код т.к. никакой пользы от них нет и со временем если их не обновлять они могут только запутать.
Гораздо лучше иметь чистый код чем запутанный и непонятный с кучей устаревших коментариев.
// Загружаем лайаут с помощью функции loadLayout
// в качестве параметра передаем переменную $_response которая является массивом и содержит ключ 'layout'
loadLayout($_response['layout']);
Редактирование комитов нужно прежде всего для того чтобы каждый changeset содержал набор красивых и завершенных изменений.
За счет этого можно делать комиты очень часто не парясь насчет каждого комита, а перед пушем изменений — все поправить.
Пример линии комитов: 1) Added extension point for new cool feature
2) Implemented new feature // Данный комит содержит баг
3) debug
4) typo
6) some other stuff
5) temp
7) fix for stupid bug
Если вы зальете такие комиты в любую системы контроля версий то ничего хорошего в итоге не будет
В гите вы имеете возможность поправить историю и привести ее к виду:
1) Added extension point for new cool feature
2) Implemented new feature // данный комит содержит код фичи без бага т.к. фикс был залит сверху
Таким образом можно просто удалить ненужные изменения (дебаги и посторонние изменения) и оставить только ценные
Если ошибка один раз появилась, то мы просто исправляем функцию, зачем нам писать тест для этой ошибки? Её больше не будет!
Судя по Вашей статье вы пишите код ровно для того чтобы он отработал 1 раз и после его выбрасываете.
В таком случае для Вас действительно тесты могут быть бесполезны.
В других ситуациях код может работать и поддерживаться годами и тогда одна и таже ошибка может появляться несколько раз и вполне логично это предотвратить написанием теста.
Кроме того через полгода-год даже автор кода забудет как он должен работать и тут опять помогут хорошие тесты
Но нет смысла писать маленькие тесты для каждой функции. Они итак работают хорошо.
Тесты можно писать не после написания рабочего кода а одновременно с ним.
Вероятно когда вы пишите свои маленькие функции которые идеально работают вы каким то образом проверяете то что они действительно работают хорошо — например запускаете отладчик и смотрите на соответствие выходных параметров ожидаемым. Тест может делать тоже самое и при этом его можно написать один раз и запускать так часто как вам нужно.
На мой взгляд Вы просто не достаточно разобрались что такое тесты и зачем они нужны и необоснованно обобщаете свой опыт на всю веб разработку
Другое дело что на самом деле важна половина пинга т.к. пинг это пересылка пакета в обе стороны.
В нашем случае сервер будет стримить картинку на ваш монитор т.е. только в одну сторону. обратно будут идти пакеты управления но они не так чувствительны к задержкам как видео сигнал.
Вы не пытались вынести расчеты на GPU? GPU должно быть намного быстрее чем потоки CPU. Если пытались какие проблемы возникли и почему отказались от такого решения?
А если серьезно то лучше не пишите скрипты по записи в БД пока не разберетесь с основами безопасности.
гораздо проще текущей директорией вима сделать корень проекта в котором лежит нужный скрипт и запускать его напрямую без каких то костылей.
Тут я с Вами согласен, однако стоит уточнить что все дельты скачиваются только если их у Вас еще не было, как правило при первоначальном checkout, потом передаются только изменения.
Вроде бы гитхаб не имеет жесткого ограничения на размер репозитория? Раньше я видел что ограничение было 2Гб и они предлагали предоставить больше места по требованию.
Для меркуриала есть механизм снепшотов который гарантирует что не требуется накладывать больше дельт чем нужно для получения целого файла
Гит оперирует всегда полными обьектами, расчет дельт выполняет нижний уровень который отвечает за хранение и для бинарников он как раз и будет держать копии файлов вместо дельт.
Кроме того я думаю что даже сжатие/расжатие дельт значительно быстрее скачки файлов по сети из облака
Вопрос а чем собственно предложенное решение лучше чем родное хранение бинарников в меркуриал или гит?
Поправлю: MapReduce тоже может использовать индексы — в функции mapReduce есть query параметр который позволяет сузить первоначальную выборку.
Как раз код со статическими методами сможет работать с одним классом, а обьект параметр может принадлежать любому классу наследнику My_Class.
Dependency Injection поможет избежать дублирования логики инциализации.
Ваш пример не совсем корректен т.к. не достаточно контекста чтобы определить насколько данный код хорош или плох.
Могу высказать свое ИМХО по этому поводу.
class View — скорее всего это класс из ядра фреймворка и его изменение не планируется. соответственно статические метода для него вцелом допустимы.
class User — удобный и логичный метод по созданию обьектов. Однако скорее всего рано или поздно прийдется изменять логику обработки пользователей (например создать отдельный класс для анонимных пользователей или пользователей с особыми правами) в таком случае статический метод может помешать таким изменениям так что в данном случае он скорее не оправдан. Кроме того такой метод затруднит тестирование кода если мы захотим подложить в этот контроллер тестовых пользователей.
Никто не говорит что инициализацию надо проводить каждый раз. А вам полезно было бы посмотреть на фреймворки а именно паттерн Dependancy Injection и его использование.
Тем не менее возможно стоило бы указать это как ограничение просто для того чтобы сэкономить кому то время и нервы.
Не знаю как в свежих версиях PHP но раньше были проблемы в случае передачи параметров по ссылке.
Насколько я помню func_get_args возвращала копию параметров и соответственно внутри функции по ссылке они уже не изменялись.
На мой взгляд такие коментарии просто засоряют код т.к. никакой пользы от них нет и со временем если их не обновлять они могут только запутать.
Гораздо лучше иметь чистый код чем запутанный и непонятный с кучей устаревших коментариев.
Надеюсь намек понятен :)
За счет этого можно делать комиты очень часто не парясь насчет каждого комита, а перед пушем изменений — все поправить.
Пример линии комитов:
1) Added extension point for new cool feature
2) Implemented new feature // Данный комит содержит баг
3) debug
4) typo
6) some other stuff
5) temp
7) fix for stupid bug
Если вы зальете такие комиты в любую системы контроля версий то ничего хорошего в итоге не будет
В гите вы имеете возможность поправить историю и привести ее к виду:
1) Added extension point for new cool feature
2) Implemented new feature // данный комит содержит код фичи без бага т.к. фикс был залит сверху
Таким образом можно просто удалить ненужные изменения (дебаги и посторонние изменения) и оставить только ценные
github.com/Mikkeren/FizzBuzzEnterpriseEdition
Судя по Вашей статье вы пишите код ровно для того чтобы он отработал 1 раз и после его выбрасываете.
В таком случае для Вас действительно тесты могут быть бесполезны.
В других ситуациях код может работать и поддерживаться годами и тогда одна и таже ошибка может появляться несколько раз и вполне логично это предотвратить написанием теста.
Кроме того через полгода-год даже автор кода забудет как он должен работать и тут опять помогут хорошие тесты
Тесты можно писать не после написания рабочего кода а одновременно с ним.
Вероятно когда вы пишите свои маленькие функции которые идеально работают вы каким то образом проверяете то что они действительно работают хорошо — например запускаете отладчик и смотрите на соответствие выходных параметров ожидаемым. Тест может делать тоже самое и при этом его можно написать один раз и запускать так часто как вам нужно.
На мой взгляд Вы просто не достаточно разобрались что такое тесты и зачем они нужны и необоснованно обобщаете свой опыт на всю веб разработку