По хорошему добавить бы в тс нормальную реализацию ко- и контр- вариантности, возможность избавиться от номинальной типизации - и тогда можно было бы разговаривать :)
Я не против строгой типизации, я против тайпскрипта как полумеры :)
Вот я такой. 32 года, 15 лет коммерческого опыта. 7 лет была своя компания, закрыл, потому что нравится быть прежде всего инженером. Всё это время программирую (причем на одном языке, потому что всё еще в кайф), рассказываю обо всём этом на конференциях и (мой святой грааль) учу кучу сопутствующего — психология, педагогика, ораторка и так далее чтобы эффективно преподавать программирование
Я, признаться, был изрядно удивлен, когда увидел диагноз. Настолько, что прям промотал вверх и кликнул в профиль, чтобы убедиться что это тот самый PaulMaly. Право, так не стоит :)
Тем не менее ищу разработчика реализовать пару вещей на J2ME в существующем опенсорс проекте. Не за бесплатно конечно :) И проект от Nokia/Microsoft. В личку (: На фрилансим — мертвое царство
Сразу говорю — не для холивара, а чтоб собрать мнения
Dojo vs ExtJS / Sencha Touch — преимущества и недостатки в сравнении.
Вопрос платности ExtJs рассматривать не хотелось бы, ибо тривиально
С Dojo я знаком слабо, но приведу парочку аргументов за и против для затравки:
— AMD вместо своего механизма загрузки в Sencha — как следствие — проще интегрировать сторонние библиотеки
— у Sencha очень вкусная инфраструктура сборки проекта (Sencha CMD) которая умеет и кофе варить :)
На тему мнемоники пи, я в свое время наткнулся на мнемонику «это я знаю и помню прекрасно, пи многие знаки мне лишни, напрасны». По количеству букв в каждом слове восстанавливается на 2 знака меньше чем в стихотворении, приведенном автором, но как-то легче мне это запомнить
В Doctrine Extensions Tree невозможно стандартными методами (moveUp, moveDown) менять местами корневые элементы. При попытке это сделать «вылазит» исключение с соответствующим сообщением. Поведение, право сказать, странное и неожиданное, но приходиься мириться.
Изменять порядок следования корневых узлов деревьев (когда у нас не дерево, а «лес») архитектурно невозможно (все они представлены как отдельные деревья с lft = 1). Согласен, что сообщение об ошибке должно быть гораздо более user-friendly, сегодня или завтра поправлю
Такие ситуации происходят в случае сбоя при удалении элементов дерева из-за наличия foreign ключей
Спасибо за баг-репорт, если получится написать вменяемый тест-кейс — за сутки поправлю
Стоит одному значению этих полей в любом элементе дерева стать неправильным — это приведет к поломке всего дерева. Поломку, которую исправить практически невозможно, учитывая сложность рассчета вышеуказанных полей, помноженную на количество элементов дерева.
Эх, надо все-таки реализовать в Nested Sets метод repair. «на всякий случай»
Основная идеология работы с ветками — каждая ветка содержит «чистую» одну единицу функциональности. Т.е. то что кто-то в file2 внес изменения, не нужные для работы вашей функциональности не является поводом для слияния.
В то же время человеку осуществляющему merge вашей ветки с апстримом может быть сложно разрешить конфликты (т.к. он не знает вашего кода). В таком случае полезно делать rebase вашей ветки относительно общей, чтобы сохранялись два принципа:
1. В вашей ветке — только коммиты относящиеся к новой одной единице функциональности
2. Ветка без проблем может быть влита в мастер
И да и нет. Ключ -m позволяет заранее задать сообщение для merge-коммита. Поведение по-умолчанию — создать стандартное сообщение.
Теперь же если -m (или -no-edit) не указано, поведение по-умолчанию — вывести редактор для создания соощения
К сожалению так сделать нельзя. «Ветка» в git — это просто именованный указатель на какой-то коммит (голова ветки). Вычислить принадлежность того или иного коммита в истории этой ветки к «самой ветке» архитектурно невозможно.
Поскольку у нас над «функциональными» ветками обычно работает 1 человек, мы просто делаем rebase ветки относительно апстрима
По хорошему добавить бы в тс нормальную реализацию ко- и контр- вариантности, возможность избавиться от номинальной типизации - и тогда можно было бы разговаривать :)
Я не против строгой типизации, я против тайпскрипта как полумеры :)
Не стоит безапелляционно говорить "не могут". GitLab - 400 инженеров, монолит с одним вынесенным сервисом (gitaly), деплои два раза в день
Dojo vs ExtJS / Sencha Touch — преимущества и недостатки в сравнении.
Вопрос платности ExtJs рассматривать не хотелось бы, ибо тривиально
С Dojo я знаком слабо, но приведу парочку аргументов за и против для затравки:
— AMD вместо своего механизма загрузки в Sencha — как следствие — проще интегрировать сторонние библиотеки
— у Sencha очень вкусная инфраструктура сборки проекта (Sencha CMD) которая умеет и кофе варить :)
Писал по памяти
server { listen 80; server_name *.*; location / { root /var/www/$host; index index.html index.php; } }:(
Изменять порядок следования корневых узлов деревьев (когда у нас не дерево, а «лес») архитектурно невозможно (все они представлены как отдельные деревья с lft = 1). Согласен, что сообщение об ошибке должно быть гораздо более user-friendly, сегодня или завтра поправлю
Спасибо за баг-репорт, если получится написать вменяемый тест-кейс — за сутки поправлю
Эх, надо все-таки реализовать в Nested Sets метод repair. «на всякий случай»
Юзабилити подобных программ крайне важно
В то же время человеку осуществляющему merge вашей ветки с апстримом может быть сложно разрешить конфликты (т.к. он не знает вашего кода). В таком случае полезно делать rebase вашей ветки относительно общей, чтобы сохранялись два принципа:
1. В вашей ветке — только коммиты относящиеся к новой одной единице функциональности
2. Ветка без проблем может быть влита в мастер
Теперь же если -m (или -no-edit) не указано, поведение по-умолчанию — вывести редактор для создания соощения
Поскольку у нас над «функциональными» ветками обычно работает 1 человек, мы просто делаем rebase ветки относительно апстрима