На самом деле есть ровно одна важная вещь — удобство. Пользователи не имеют ничего против того чтобы брать музыку и фильмы в аренду, если это удобнее и дешевле чем покупать. Пользователи в массе своей, даже совсем не против отправлять Apple (или Microsoft, или Линусу Торвальдсу) свои данные, если это повышает удобство использования устройством (я делаю это осознанно, и когда гугл, или jetbrains, или кто-то ещё предлагает мне выбор, я достаточно часто осознанно соглашаюсь). Я не надеюсь, что FSF создаст более удобную для пользователя экосистему, чем коммерческие компании. Я долгое время использовал убунту/дебиан/федору на ноутбуке, потом переехал на мак, а сейчас снова вернулся на убунту на какое-то время. К маку(который на тот момент я взял впервые) я привык за неделю. С убунтой(которой я пользовался раньше), я не могу подружиться уже третью неделю(юнити писали марсиане для марсиан, гном 3 лучше, но нестабилен). И так везде. Нет той ответственности перед пользователем, наверное.
Но что ещё важно. Такие ребята, как FSF делают всё правильно. Пока они есть, у Apple, Microsoft и других закрытых компаний, есть граница, которую они не должны переходить. Повышая параноидальность людей, FSF как раз обеспечивает уровень этой границы у большой массы покупателей различной техники, не позволяя вендорам делать слишком многое.
У «Крепости», был законченый сюжет, тут же это скорее набросок, который едва ли будет закончен.
Плюс, визуальный стиль здесь и там, они совсем разные. Тут он действительно более детальный, и реалистичный.
Но итоговое впечатление от «Крепости» у меня было сильнее.
1) Насколько я знаю, гугл поддерживает многоаккаунтность(пруф). Не знаю, насколько глубоко – не пользовался. Но вроде должен без проблем переключать. В андроиде, помнится, тоже можно добавить несколько гугл аккаунтов.
2) Из соцсетей которыми я пользуюсь, в Г+ самый высокий процент уникального контента. Комментарии в ВК/ФБ/Твиттере вообще лучше не читать, в Г+ комментарии значительно чище. Возможно это из-за меньшего количества народа, или как раз привязки основного аккаунта по умолчанию, – но сидеть там приятнее.
Резюмируя: если то что сейчас в Г+ это – не взлетел, то как по мне, так остальным соцсетям было бы тоже лучше не взлететь. Меньше мусора.
С деплоем всё хорошо, я деплою на DigitalOcean, а там достаточно заменить Vagrantfile на:
Скрытый текст
Vagrant.configure("2") do |config|
config.vm.box = "mokote/debian-7"
config.vm.define :do_instance_name
config.vm.synced_folder "salt/roots/", "/srv/"
config.vm.provision :salt do |salt|
salt.minion_config = 'salt/minion'
salt.run_highstate = true
salt.verbose = true
end
config.vm.provider :digital_ocean do |provider, override|
override.ssh.private_key_path = '~/.ssh/id_rsa'
override.vm.box_url = 'https://github.com/smdahlen/vagrant-digitalocean/raw/master/box/digital_ocean.box' # тупо заглушка
provider.client_id = 'client_id'
provider.api_key = 'api_key'
end
end
установить плагин vagrant-digitalocean.
$ vagrant plugin install vagrant-digitalocean
и деплоить через capistrano, или тупо git.
Если на обычный сервер, я думаю стоит посмотреть доки по SaltStack и настроить masterless конфиг(там достаточно поднять агента и скопипастить/rsync'нуть найтройки в /srv/salt. Правда запускать потом вручную надо), а дальше работать по аналогии.
Конфиги – централизованый узел системы. Если искать только там – это не проблема. Без DI искать надо и в конфиге и в компонентах и в расширениях и вообще везде по проекту(особенно если это статический хелпер, например).
Лучше 10 файлов конфига, чем 200 файлов .php. Аннотации для DI – конечно хуже, но, как правило, они контекстны хотя-бы.
Где используется отлично видно, если сделать Find Usages в том же PhpStorm.
Так и я о том же. А при использовании DI достаточно зайти в конфиг.
куда далее пойдёт по коду в случае сильного использования DI-контейнера
По моему достаточно знать lifecycle фреймворка, или библиотеки которую используешь. Да и в Yii, из-за хитрых геттеров, бихейвиоров и ивентов, ничуть не проще угадать куда пойдет выполнение, мне кажется.
Что значит не завели функциональные тесты? Отлично работают.
Забыл уточнить, я использую Codeception и у меня не получилось.
Не только у меня кажется
1) Низкая связанность хоть и хорошая штука в общем, но сильно портит API во многих случаях. В Yii она просто не нужна. Оттестировать мы можем любой код.
Только функциоанльные тесты на первой версии так и не завели, помнится. Насчет портит API – достаточно спорно. Оно становится несколько сложнее, возможно.
— Сильно повышается порог вхождения, хоть принцип сам по себе и простой.
Вот все эти истории про порог вхождения, и подтверждают мои слова о фрилансерском фреймворке. Поощряется подход «тяп-ляп и в продакшн». Нет необходимости глубокого изучения темы.
— Сложнее отлаживать. Код размазывается по конфигам, куче компонент, вырастает количество слоёв вертикально.
Как правило при высоком покрытии кода тестами отладка логики становится почти не нужна. Ну и насчет отладки – breakpoint'у всё равно в каком он слое, он брякнется когда выполнение дойдет до него.
Поэтому мы пользуемся DI умеренно и чаще без контейнера.
Ну в итоге это и становится единственным возможным сценарием, причем из-за фреймворковского менеджера компонентов, даже он затруднен.
Что касается стандартных компонентов, особых проблем с их перекрытием быть не должно.
Как я уже говорил, главная проблема – высокая связанность, остальные вытекающие.
Мы стараемся избежать ситуации, когда пакет блог может использовать swift mailer, пакет feedback, zend mailer, какой-то ещё пакет, какой-то ещё мейлер
При использовании модулей этот сценарий не исключается, кстати.
Про отслеживание где и что используется как-то у вас странно. Поставьте нормальную IDE. Про поддержку не согласен. Зависит больше от кода проекта, чем от фреймворка.
А как в Yii отследить что и где используется? У меня больше 20 моделей, связанных друг с другом, 4 приложения и куча компонентов и Behavior'ов. Как узнать, где используется модель User когда происходит ломающее BC изменение в ней? Только Ctrl+F(или интуиция) ибо нет централизованного DI контейнера где можно посмотреть куда была проброшена модель.
1) Для того, чтоб что-то использовать отдельно – не нужно затачивания под это. Нужна низкая связанность, которая является одним из критериев качества кода, кстати.
2) Чем же? Видеть где и что может поломаться при изменении заходя только в конфиг – лишь одна из многих плюшек DI.
Интересное наблюдение. Yii я бы назвал самым фрилансерским фреймворком. На нем очень просто написать, что-то работающее. Но в большинстве случаев, поддерживать проект на Yii – боль и страдание. Ибо фреймворк не пытается направлять программиста в нужное русло, и когда дело касается стандартных компонентов – связывает по рукам и ногам. Проблема с перекрытием внутренних классов фреймворка – это только вершина айсберга. Приходя в проект, ты вообще не знаешь его строения. Ctrl+F становится единственным способом отследить где и что используется.
Почему-то Symfony 2 или Zend 2, обычно намного проще поддерживать, даже если код писал не ты.
Отличный материал =)
Вы не планируете после публикации на хабре, опубликовать перевод на гитхаб?
Удобно всё видеть в одном месте, а не кучей постов, пусть и с оглавлением.
Вроде статья почти без картинок, а вы всё равно на что-то отвлеклись.
В начале:
>Я всегда изучал новые инструменты (будь это демоны, утилиты, библиотеки, языки или сервисы)
И в конце:
>Выходить из своей зоны комфорта — изучая новый язык — ключ к объединению всех наших технологий; именно воспринимая и обсуждая идеи с другими сообществами, мы улучшаем свой навык решения проблем — с использованием лучших решений, и лучших инструментов. Так что выбирайтесь на встречи или конференции, слушайте подкасты и читайте статьи про другие языки, даже если вы не заинтересованы в использовании этих языков.
Моя позиция:
не важно в GG ты, или нет, снимай там где можно и не снимай где нельзя.
За съемку видео в неположенном месте, где есть соответствующие обозначения – ответственность, и опять же неважно в GG ты, или нет. Ясно или неясно – вообще не имеет значения, по моему.
Но я начинаю понимать вашу позицию. Думаю какой-то внешний индикатор съемки в GG должен быть(например заметная мерцающая красная лампочка), чтобы в них вообще было возможно посещение мест где снимать запрещено. По аналогии с камерами, которые в таких местах не забирают, а просто не дают использовать.
Нет, я скорее о том, что в примере выше было указано место в котором съемка должна быть ограничена даже сейчас.
А когда я говорил о запрещении, GG я подразумевал содержимое топика и группу людей готовых лоббировать Анти-GG инициативы.
То что у нас разные списки мест в которых допускается свободная съемка я уже понял =)
Но что ещё важно. Такие ребята, как FSF делают всё правильно. Пока они есть, у Apple, Microsoft и других закрытых компаний, есть граница, которую они не должны переходить. Повышая параноидальность людей, FSF как раз обеспечивает уровень этой границы у большой массы покупателей различной техники, не позволяя вендорам делать слишком многое.
Плюс, визуальный стиль здесь и там, они совсем разные. Тут он действительно более детальный, и реалистичный.
Но итоговое впечатление от «Крепости» у меня было сильнее.
Думаю имелось в виду ситуация, когда сервак сейвит данные напрямую в БД вместо обработки информации о действиях, а вся логика реализована на клиенте.
2) Из соцсетей которыми я пользуюсь, в Г+ самый высокий процент уникального контента. Комментарии в ВК/ФБ/Твиттере вообще лучше не читать, в Г+ комментарии значительно чище. Возможно это из-за меньшего количества народа, или как раз привязки основного аккаунта по умолчанию, – но сидеть там приятнее.
Резюмируя: если то что сейчас в Г+ это – не взлетел, то как по мне, так остальным соцсетям было бы тоже лучше не взлететь. Меньше мусора.
PHP.
brainstorage.me/ligser
github.com/ligser
twitter.com/AbsolutePlus
установить плагин
vagrant-digitalocean.и деплоить через capistrano, или тупо git.
Если на обычный сервер, я думаю стоит посмотреть доки по SaltStack и настроить masterless конфиг(там достаточно поднять агента и скопипастить/rsync'нуть найтройки в /srv/salt. Правда запускать потом вручную надо), а дальше работать по аналогии.
Ansible вот как-то пропустил, как и Docker. Возможно позже попробую и напишу сравнение :)
Лучше 10 файлов конфига, чем 200 файлов .php. Аннотации для DI – конечно хуже, но, как правило, они контекстны хотя-бы.
Так и я о том же. А при использовании DI достаточно зайти в конфиг.
По моему достаточно знать lifecycle фреймворка, или библиотеки которую используешь. Да и в Yii, из-за хитрых геттеров, бихейвиоров и ивентов, ничуть не проще угадать куда пойдет выполнение, мне кажется.
Забыл уточнить, я использую Codeception и у меня не получилось.
Не только у меня кажется
Только функциоанльные тесты на первой версии так и не завели, помнится. Насчет портит API – достаточно спорно. Оно становится несколько сложнее, возможно.
Вот все эти истории про порог вхождения, и подтверждают мои слова о фрилансерском фреймворке. Поощряется подход «тяп-ляп и в продакшн». Нет необходимости глубокого изучения темы.
Как правило при высоком покрытии кода тестами отладка логики становится почти не нужна. Ну и насчет отладки – breakpoint'у всё равно в каком он слое, он брякнется когда выполнение дойдет до него.
Ну в итоге это и становится единственным возможным сценарием, причем из-за фреймворковского менеджера компонентов, даже он затруднен.
Как я уже говорил, главная проблема – высокая связанность, остальные вытекающие.
При использовании модулей этот сценарий не исключается, кстати.
А как в Yii отследить что и где используется? У меня больше 20 моделей, связанных друг с другом, 4 приложения и куча компонентов и Behavior'ов. Как узнать, где используется модель User когда происходит ломающее BC изменение в ней? Только Ctrl+F(или интуиция) ибо нет централизованного DI контейнера где можно посмотреть куда была проброшена модель.
2) Чем же? Видеть где и что может поломаться при изменении заходя только в конфиг – лишь одна из многих плюшек DI.
Интересное наблюдение. Yii я бы назвал самым фрилансерским фреймворком. На нем очень просто написать, что-то работающее. Но в большинстве случаев, поддерживать проект на Yii – боль и страдание. Ибо фреймворк не пытается направлять программиста в нужное русло, и когда дело касается стандартных компонентов – связывает по рукам и ногам. Проблема с перекрытием внутренних классов фреймворка – это только вершина айсберга. Приходя в проект, ты вообще не знаешь его строения. Ctrl+F становится единственным способом отследить где и что используется.
Почему-то Symfony 2 или Zend 2, обычно намного проще поддерживать, даже если код писал не ты.
Вы не планируете после публикации на хабре, опубликовать перевод на гитхаб?
Удобно всё видеть в одном месте, а не кучей постов, пусть и с оглавлением.
В начале:
>Я всегда изучал новые инструменты (будь это демоны, утилиты, библиотеки, языки или сервисы)
И в конце:
>Выходить из своей зоны комфорта — изучая новый язык — ключ к объединению всех наших технологий; именно воспринимая и обсуждая идеи с другими сообществами, мы улучшаем свой навык решения проблем — с использованием лучших решений, и лучших инструментов. Так что выбирайтесь на встречи или конференции, слушайте подкасты и читайте статьи про другие языки, даже если вы не заинтересованы в использовании этих языков.
не важно в GG ты, или нет, снимай там где можно и не снимай где нельзя.
За съемку видео в неположенном месте, где есть соответствующие обозначения – ответственность, и опять же неважно в GG ты, или нет. Ясно или неясно – вообще не имеет значения, по моему.
Но я начинаю понимать вашу позицию. Думаю какой-то внешний индикатор съемки в GG должен быть(например заметная мерцающая красная лампочка), чтобы в них вообще было возможно посещение мест где снимать запрещено. По аналогии с камерами, которые в таких местах не забирают, а просто не дают использовать.
А когда я говорил о запрещении, GG я подразумевал содержимое топика и группу людей готовых лоббировать Анти-GG инициативы.
То что у нас разные списки мест в которых допускается свободная съемка я уже понял =)