trman

unphar.com

<?php
function test() {
}

$ref = new ReflectionFunction('test');
echo $ref->getFileName().':'.$ref->getStartLine().PHP_EOL;

Tools - Deployment - Browse Remote Host

Да, стояли ранее галочки.
Также увеличили значение по умолчанию (время хранения авторизации) глобально в PHP, через значение параметра session.gc_maxlifetime (в настройках PHP, файл php.ini)

Попробую обобщить, помню свою панику когда первый раз открыл vim

Выриант 1:
- Жмем v (vim переходит visual mode, выделяет все от текущей позиции курсора)
- двигаем курсор ( можно стрелочками, можно hjkl, можно web%$ как угодно)
- нажимаем y

Вариант 2:
Если речь идет о строках, надо решить эту проблему

Просто я допустим захлотел скопировать 10, а скопировал 11, как без выделения я это пойму без вставки, наверное что никак

- набираем :set relativenumber
- определяем сколько строк надо скопировать по нумерации строк слева (допустим 43)
- нажимаем y43y

Профит
P.S. копировать можно не только строки
можно слова yw
можно от текущей позиции до конца строки y$
можно от начала блока до его конца y%

Вариантов много и каждый д%#@, как хочет.

Поправил ответ, так будет логичнее.
Ниже приведены инструменты, которые использую лично я и причины почему.

1. docker-окружение
(в 90% случаев для веб-разработки достаточно php -S 0.0.0.0:8000)
виртуальные машину становятся нужны:
- когда надоест переустанавливать хост-систему из-за обилия хлама
- когда работаешь с несколькими проектами имеющие специфические (разные) настройки окружения(php, web-сервер, база)
- когда надоест решать проблемы в команде из-за того что по разному настроено окружение

2. git - система контроля версий
Помнить что ты и когда изменял, должен не человек, а машина.
Это необходимо:
- чтобы не испортить всю работы за прошедший год нажав del
- чтобы определить кто из команды злодей и все испортил
- чтобы не думать как перенести свежую версию проекта с одной машины на другую

3. composer - пакетный менеджер для php
Нужно, когда лениво помнить все ссылки на все php библиотеки, самому качать их, подключать в автозагрузку

4. behat + phpspec
Тесты нужны:
- когда хочется почувствовать себя безопасности и для сладко спать ночь, забыв о кошмарах о сломанном коде
- когда в production все снова сломалось
- когда ты написал одну новую фичу, а сломал три

5. zsh
Хорошей консолью приятно пользоваться, работа идет быстрее.
Консоль есть жизнь, жизнь есть shell.

6. tmux
Мало одно окошка в консоли, тогда tmux идет к вам.
В качестве бонуса получите возможность парного программирования совершенно бесплатно

7. tmuxinator
Надоело каждый раз открывать кучу окон для tmux, попробуйте его )
8. vim
- Потянуло на что-нибудь необычное?
- Хочется эффективнее писать код ?
Ну что открыли vim? В первый раз? Поздравляю закрыть вы его не сможете )
Вызывает зависимость при частом потреблении

9. continuous integration сервер
Вообще ci сервер это одушевленная машина. Это твой тамагочи, ты кормишь его хорошим кодом, он радуется и ты видишь приятный зеленый огонек. Если ты дал с код от скажет что не вкусно. Ну а если ты ему, что гнилое он будет долго на тебя орать плохими словами. Со временем он растет и учится делать более серьезные вещи, и начнет помогать тебе:
Его скилы:
- он может сам выполнить 10 минутные тесты
- подготовить и опубликовать проект
- рассказать о твоем коде, даже то что ты не знаешь
Он легко обучается и ты легко сможешь научить его удивительным вещам.

10. куча линтеров на pre commit hook
Чтобы ci не кормить плохими продуктами, хорошо бы проверять что ты сделал до отправки на сервер. Что бы не забыть это сделать git сам работу.

11. gulp
gulp - это еще один твой помощник.
как если использовать, как watcher файлов + livepreview, можно забыть о F5 в браузере

12. bower
Тоже что и composer но для управления ассетами. Это я о всяких jQuery и Bootstrap

666. Линукс
Даже если не хочется ставить как хост-систему, его все равно надо знать. Ваш код будет работать на нем )

Linux? Cron
Windows? Sheduler

let filter = BX.Main.filterManager.getById('ИД ФИЛЬТРА');
  let values = filter.getFilterFieldsValues();
  
   values['НАЗВАНИЕ ПОЛЯ'] = 'Значение для фильтра ';

  filter.getApi().setFields(values);
  filter.getApi().apply();

\CModule::includeModule("sale"); или \Bitrix\Main\Loader::includeModule('sale');

Гриды заюзать

зачем вам вообще клиент?
никогда не понимал зачем для линукса он нужен вообще?
у тебя в навигаторе есть кнопочка подключить фтп и пользоваться им как обычной файловой системой.
если вы работаете часто тоо можно создать закладки.
Если прям совсем бесшовный ( я так делаю)
монтирую их
https://help.ubuntu.ru/wiki/%D0%BC%D0%BE%D0%BD%D1%...

вопрос зачем вам сторонние решения если сама ос ( в отличие от винды)
может напрямую работать через этот протокол ?
Про sftp я вообще помолчу

Понятие еnd-to-end обозначает всего-навсего классификацию тестов по уровню, на котором тестируется система, и, само по себе, ничего не говорит ни о том, какие конкретно должны быть эти тесты, ни о том, какую роль они играют в общей стратегии обеспечения/проверки качества и, также, не является методикой тестирования. (Методика - это совсем другое понятие.)

Для понимания сути этого понятия хорошо сравнить его с модульным ("нижний" уровень) и интеграционным ("средний") тестированием на каком-нибудь конкретном примере. Давайте рассмотрим некий сферический webshop в вакууме. Предположим, в нем есть 50 классов и для большинства из них написаны модульные тесты. Они проверяют исключительно функционал конкретного модуля (чаще всего, класса), т.е. тот, что зависит только от самого модуля и ни от чего чего более. Потом есть интеграционные тесты. Они проверяют корректность работы отдельных "модулей", если их собрать вместе согласно архитектурe. Например, работает ли правильно "Корзина", состоящая, в свою очередь, из 10 классов (предварительно проверенных модульными тестами), или "Корзина", подключенная к "Вебморде" и т.д. Где-то повыше в этой иерархии есть такие интеграционные тесты, которые проверяют конкретный функционал всей системы. Например, отправляется ли юзеру мейлом копия оплаченного заказа...

И вот тут начинается самое интересное для понимания того, что такое end-to-end тестирование! Можно представить себе тест, проверяющий, что соответствующий мейл генерируется и сбрасывается SMTP серверу. Если SMTP сервер не рассматривать, как часть разрабатываемой системы, то этот тест вполне можно назвать end-to-end тестом (послали кучку HTTP запросов через "Вебморду" и проверили сброс мыла на SMTP - все зашибись!). Однако, если настройки и эксплуатация SMTP сервера - часть проекта (например, заказана разработка webshop "под ключ"), может оказаться, что это мыло будет отфильтровано каким-нибудь спам-фильтром, превысит лимит почтового ящика пользователя... короче, не дойдет до него. Тогда этот же самый тест уже нельзя считать end-to-end, а нужно бы было написать тест, проверяющий приход мыла в POP3/IMAP ящик. (Опять же, если это действительно нужно! Ибо, в зависимости от конкретных функциональных и нефункциональных требований, архитектор и QA инженер вполне могут найти возможность обеспечить адекватный контроль качества и без такого теста.)

Таким образом, end-to-end тесты, это такие интеграционные тесты, которые воздействуют на систему через ее самые внешние интерфейсы и проверяют ожидаемую реакцию системы через эти же интерфейсы. Почему именно интеграционные? Потому, что это единственное, что можно о них сказать наверняка: они по определению не могут быть модульными тестами. А все остальное: являются ли они одновременно приемочными, нагрузочными или еще какими - зависит только от общих плана/стратегии тестирования и той роли, которые эти тесты в них играют.

Преимущество у динамически типизированных языков, конечно, не в синтаксисе, а в семантике.

Благодаря определению типов во время исполнения программы сильно облегчается метапрограммирование. Очень сильно облегчается. Оно, в свою очередь, упрощает всю остальную работу.

Благодаря гибкости кода в рантайме (см. тот же duck typing) и интроспекции (анализ свойств объектов и кода) получается на порядок проще и быстрее писать универсальные алгоритмы и конструкции вроде декораторов, всяческих ORM и подобных вещей. Это сильно упрощает интерфейсы библиотек, что в совокупности ведёт к более простому коду и к плавной кривой обучения новичков.

Из моей практики (5 лет писал на C++, потом столько же на Python, эти сроки немного пересекались) могу сказать, что с точки зрения ошибок типизации (а собственно их и ставят в недостаток динамически типизированным языкам) разница минимальна — они очень редки и все отлавливаются автоматическими тестами. Конечно, если у вас руки откуда надо растут, а если не откуда надо, то эти ошибки будут далеко не самой большой проблемой. Поэтому в области разработки софта, не требовательного к производительности, такие языки рулят.

Преимущество же статически типизированных языков в том, что, налагая дополнительные ограничения на программиста и на гибкость кода, они позволяют компилятору получить дополнительную информацию о программе и сделать более специфичные операции. Однако нынче почти везде используют JIT и это частично нивелирует разницу в производительности.

В итоге мы получаем классическую дилемму: повышение уровня абстракции против повышения уровня специализации. У каждого пути есть свои плюсы и минусы.

По производительности питона ссылок уже накидали, но в любом случае тут надо исходить из требований конкретной задачи — проще взять и протестировать самому.

Забавно читать ответы.

Когда читал Философию Java, автор высоко оценивал python. И не с проста. Как и Java, у Python свои плюсы.

По производительности что Python, то и Java примерно равны. Python имеет "нативный" byte-code, если так можно выразиться (не смотря на то, что его портировали и на CIL, и на JVM, и на сам Python). Так что здесь паритет.

По удобству зависит от проекта и задач. Если цель - сделать как можно быстрее, то Python явно удобнее. Ибо можно набросать прототип в интерактиве, немного подправить его и вауля - проект "готов". Если цель надёжность - наш выбор Java: статическая типизация и компилируемость выявляет сотни ошибок ещё до запуска приложения.

Стоит заметить, что вэб в Java развит очень сильно. Причём настолько, что он просочился до клиентских вэб-приложений (и умер лет 10 назад), хотя backend всё равно в разы сильнее. Что это значит? Это значит, что для Java есть множество отличных фреймворков, ориентированных на web. Каноничная реализация ООП позволяет использовать паттерны банды четырёх "из коробки". Интерфейсы, если ими уметь пользоваться, решают. Python же не создавался как web-движок, а создавался просто как удобный инструмент для быстрого программирования как прикладных, так и теоретических задач. В этом помогает всё - и сахарный синтаксис, и крутейшие итераторы, и пресловутый интерактивный режим, и невероятные slice'ы, и неплохие лямбды, и красивый код. RoR, если говорить о языке фреймворка, так же сильно похож на Python, но магии в нём много больше. Но Python-приложения тяжко отлаживать. Можно пару лет вести баг, который окажется из-за того, что мы не проверили возможность преобразования объекта к строке в аргументах. Динамическая типизация, причём очень хардовая из всех, наверное, это и дар и проклятие.

Собственно, если вопрос стоит "стоит ли изучать", то да, конечно стоит. Как и Java, Python - мультипарадигмальный язык, и те практики, которые Вы изучите в Python несомненно улучшат код в Java.