Проблемы там скорее с разбиением на строки — нет классических пробелов и нельзя разбивать на произвольном месте,
В интернете говорят что Maximum Matching — стандартный алгоритм для разбиения японских текстов на слова. В этой лекции class.coursera.org/nlp/lecture/127 где-то с 10-ой минуты про него рассказывают. Но там нужен словарь японских слов.
1. В статье сказано почему нам не подошёл phpcs — он мог проверить формат, но не мог отформатировать код.
2. Про автоформат.
Вы настаиваете что автоформат всего репозитория в нашем случае было бы правильным решением? Почему?
Очевидно что если бы мы решили его делать, то это был бы отдельный комит, но всё равно это сделало бы работу с репозиторием менее удобной — менее удобно было бы получать историю по всем строкам, задетым в момент форматирования. Баду репозиторий существует наверное более 8 лет, вопрос с форматированием кода начали решать где-то 3-4 года назад (могу ошибаться, точно не помню). То есть большАя часть кода в репозитории за первые 4-5 лет в git blame указывала бы на коммит автоформата, вместо того чтобы указывать на реальные «боевые» коммиты. С таким репозиторием неудобно работать.
И не стоит думать что мы сразу кинулись писать php экстеншен, сначало конечно был простенький скриптик на чистом php.
На остальные вопросы затрудняюсь ответить — я лишь пользователь phpcf, а не его разработчик.
> пожамкать им в два клика целый проект?
именно этого нам и хотелось избежать. Изначально (примерно 6-8 лет назад), у нас не было никакого стандарта. Точнее он был, но скорее как рекомендации и во многих местах он не был соблюден. Компания росла и в какой-то момент вопросы стандарта кодирования стали возникать всё чаще.
Было 2 варианта — отформатировать разом весь репозиторий, или сделать так чтобы весь новый код был по стандарту, а старый код постепенно бы менялся/рефакторился и тем самым попал бы под новое форматирование.
Полный реформат репозитория не понравился тем что сильно загрязнится история в git-е — много строк кода будут ссылаться на комит в котором был сделан реформат. Это неудобно потому что нам довольно часто приходится читать старый код, искать кто и почему написал ту или иную строку кода. Поэтому был выбран второй вариант
Какое-то поверхностное описание.
В компании должно быть достаточно программистов, чтобы в случае подобной ситуации можно было бы выделить хотя бы одного человека разобраться в причине.
Далее в компании должен быть кто-то (тех-лид, архитектор, хз кто, может быть несколько человек) кто бы мог оценить что в данном конкретном случае выгоднее — купить память или заоптимизировать. Оптимизация — это не обязательно рефакторинг, это может быть маленький, хорошо задокументированный костыль :)
Универсального ответа нет — иногда нужно рефакторить/оптимизировать, иногда нужно покупать железо. Бесконечно железо покупать не сможешь, рано или поздно упрёшься в какие-то лимиты
А как отечественные django-девелоперы относятся к грядущей замене терминов master/slave на leader / follower в django? github.com/django/django/pull/2692
Если бы не неопределенность с двумя версиями питона (второй и третьей) которая длится уже несколько лет, то я бы однозначно за питон голосовал.
А так, питон конечно получше, но он не идеален и у него тоже свои проблемы.
Слабо верится. Фреймворк конечно замедляет выполнение процесса, но 23 секунды — это из области фантастики. Скорее всего где-то в фреймворке что-то не так используется, где-то неявные лишние вызовы чего-то, запись в папку с миллионом файлов или sleep(23) от предыдущего недовольного сотрудника
Спасибо
:)
2. Про автоформат.
Вы настаиваете что автоформат всего репозитория в нашем случае было бы правильным решением? Почему?
Очевидно что если бы мы решили его делать, то это был бы отдельный комит, но всё равно это сделало бы работу с репозиторием менее удобной — менее удобно было бы получать историю по всем строкам, задетым в момент форматирования. Баду репозиторий существует наверное более 8 лет, вопрос с форматированием кода начали решать где-то 3-4 года назад (могу ошибаться, точно не помню). То есть большАя часть кода в репозитории за первые 4-5 лет в git blame указывала бы на коммит автоформата, вместо того чтобы указывать на реальные «боевые» коммиты. С таким репозиторием неудобно работать.
И не стоит думать что мы сразу кинулись писать php экстеншен, сначало конечно был простенький скриптик на чистом php.
На остальные вопросы затрудняюсь ответить — я лишь пользователь phpcf, а не его разработчик.
именно этого нам и хотелось избежать. Изначально (примерно 6-8 лет назад), у нас не было никакого стандарта. Точнее он был, но скорее как рекомендации и во многих местах он не был соблюден. Компания росла и в какой-то момент вопросы стандарта кодирования стали возникать всё чаще.
Было 2 варианта — отформатировать разом весь репозиторий, или сделать так чтобы весь новый код был по стандарту, а старый код постепенно бы менялся/рефакторился и тем самым попал бы под новое форматирование.
Полный реформат репозитория не понравился тем что сильно загрязнится история в git-е — много строк кода будут ссылаться на комит в котором был сделан реформат. Это неудобно потому что нам довольно часто приходится читать старый код, искать кто и почему написал ту или иную строку кода. Поэтому был выбран второй вариант
В компании должно быть достаточно программистов, чтобы в случае подобной ситуации можно было бы выделить хотя бы одного человека разобраться в причине.
Далее в компании должен быть кто-то (тех-лид, архитектор, хз кто, может быть несколько человек) кто бы мог оценить что в данном конкретном случае выгоднее — купить память или заоптимизировать. Оптимизация — это не обязательно рефакторинг, это может быть маленький, хорошо задокументированный костыль :)
Универсального ответа нет — иногда нужно рефакторить/оптимизировать, иногда нужно покупать железо. Бесконечно железо покупать не сможешь, рано или поздно упрёшься в какие-то лимиты
github.com/django/django/pull/2692
А так, питон конечно получше, но он не идеален и у него тоже свои проблемы.
Вопрос риторический
Скоро стартует похожий стенфордский курс class.stanford.edu/courses/HumanitiesScience/StatLearning/Winter2014/about
Было бы класно, если бы вы их выложили в itunes, например как itunes.stanford.edu/
Будете ли продолжать использовать хаскель дальше или же откажетесь от него?