А потом разработчики начинают отдавать фиксы даже не запуская проект после изменений. Зачем? Есть же тестировщик.
Ну и что, что он отдаст обратно через минуту после запуска. Мое время дороже.
На сколько я знаю, в ms sql только либо like 'abc%', который использует индекс, либо полнотекстовый.
Как только вы пытаетесь найти что-то после '%' ('abc%def') индекс больше не работает. Максимум можно использовать хак для «ends with» поиска ('%abc'), создав колонку с перевернутым значением и получив возможность использовать 'cba%' запрос.
Но ведь вы и раньше могли объявить абстрактный класс AbstractFileHandler, где метод Rename был бы реализован, а остальные методы объявлены как abstract.
В сущности тоже самое, просто проще синтаксис. Вохможно в заблуждение вводит именно то, что это интерфейс и не приходит в голову, что что-то может быть реализовано.
У меня небольшой опыт в реакте, поэтому вопрос, наверное, глупый. В чем смысл компонента Panel? Это же просто обёртка div с классом. У вас в index.jsx под этим самым panel еще один div с классом, но его же не вынесли в компонент.
И еще, зачем у вас в layout все children оборачиваются в div?
Подобную ошибку будет крайне непросто отследить. Дело в том, что для возникновения этой ошибки нужно, чтобы заказ оформлял бы особенный покупатель, а на один такой заказ, возможно, приходится 1000 обычных заказов.
А разработчик приложение в принципе не запускает, когда код пишет? И тестировщиков нет, судя по всему.
Поясните, пожалуйста, пример с Compare. Если cscLeft/cscRight равны null, то тогда left/right будет null и, соответственно, сработает одно из условий if.
Ну, как же это нет конкуренции. Вот вы говорите 4сек: получается, что когда я печатаю xxx вы отправите 3 запроса по 4 сёк. Что будет, если ответы вернутся в порядке 3-2-1.
Тут на самом деле более глобальный вопрос: вот вы вынесли все это в разметку, повесив реализацию на браузер, кто сказал, что решение браузера единственно верное и как его поведение переопредилить?
Не думаю, что вместо одного запроса, который грузит страницу целиком, отправлять кучу мелких запросов — это действительно лучшее решение. Где-то да, но не всегда и не везде.
Со ссылками на другие элементы у вас очень простые примеры. А что если div name содержит разметку, а не простой текст?
С поисковым запросом тоже вопрос, когда будет отправляться? На каждый новый символ? Как быть с отменой предыдущего запроса? С конкуренцией запросов?
Всё довольно сыро и неоднозначно.
Пока у меня был программист, который стоял у истоков создания этого приложения, который понимал всю эту штуку в целом, меня всё устраивало. Проблемы начались, когда я остался один.
Ну, так это проблема не Smart Client, а организации работы в команде. Если у вас только один понимает архитектуру проекта, то это закономерно приведет к таким последствиям, вне зависимости от того, какие инструменты, библиотеки и т.п. вы используете.
Безусловно. С этим никто не спорит. Но с точки зрения РП, как можно в самом начале оценить, будет разработчик правильно использовать или нет? Я могу поверить, что в этом есть что-то изящное, но простым смертным не всегда доступное. :)
Ну, я вот сейчас пишу проект на Smart Client — в самом начале выделил 2 недели на то, чтобы полностью продумать всю структуру проекта. Как view будет общаться с presenter'ом, как система будет реагировать на команды из view и т.п. Получил понятную, удобную и простую картину всего приложения. Нет вопросов, где писать каждый кусок кода.
Да, это личный проект, я могу потратить 2 недели на это(да и в реальном проекте, это тоже не так много). Но теперь, если со мной этот проект будет кто-то писать, то первое что будет сделано — это рассказано об архитектуре, почему так и какие плюсы минусы.
Если программист говорит, что что-то надо использовать, потому что это последнее достижение или все сейчас используют — то это ничего не говорит о понимании. Если он может полностью рассказать о том, как это использовать в рамках проекта, какие плюсы это принесет, какие ограничения есть и как это заменить, если придется переходить на что-то другое, то он понимает как правильно работать.
Хотел бы заступиться за Smart Client. На мой взгляд — это очень хороший набор инструментов для разработки приложений. В нем, конечно, есть недостатки, но сама суть — это шедевр. Я просто могу предположить, что либо вы не до конца поняли как устроен Smart Client, либо ваш проект использовал его не совсем правильно. С продуманной архитектурой, которую понимают все разработчики, вопросов поиска классов не возникает. У меня был опыт работы с проектом на Smart Client, который начали писать не особо думая о том, как правильно это делать (Вау! Глобальные события! Давайте их везде использовать!). Но потом, когда все привели в порядок не стало вопросов о том, где писать нужный кусок кода. Все понимали за что отвечает view, presenter, workitem, module и т.п.
На самом деле к DI/IoC надо прийти. Не пихать его бездумно везде, потому что это «модно, стильно, молодежно», а действительно понимать зачем он там. Я его начал использовать, когда в мелком проекте было по 2-3 реализации каждого этапа работы программы. Мне просто надоело комментировать конкретные реализации для запуска программы с определенной конфигурацией. Вот тут и пригодился DI/IoC, который одной строчкой мог переключить набор реализаций на запуске.
Все нужно уметь использовать и понимать, что как и зачем. Я тоже не люблю DI/IoC в проектах где всегда одна реализация, но когда-нибудь или «а вдруг!»… Обычно это никогда.
Я считаю, что эти правила — бред параноика. Я прекрасно понимаю, что, к сожалению, реальность в данный момент такова, что информацией в открытом доступе могут воспользоваться.
Но мой вопрос в другом — куда по-вашему лучше двигаться? В сторону тотальной анонимности или в сторону полного ее отсутствия?
Меня все время мучает вопрос: «но зачем?». Зачем вам нужно оставлять «самый анонимный комментарий на свете»? Почему вы, высказав свои мысли, прилагаете такие усилия, чтобы от этих мыслей отказаться?
Это да, но вот читая код, совершенно не понимаешь его смысла:
v is int
это проверка на тип, но после нее идет название переменной, которое по сути ни к чему не относится.
Если написать
if(v as int i)
то можно прочитать это как попытка приведения v к int переменной и запись результата в i.
И можно было бы сделать возвращение этим выражением true/false по аналогии со стандартной проверкой на null.
Основной смысл этого выражение — получение новой переменной с новым типом, а не проверка на тип. Поэтому я считаю, что именно As был бы уместнее.
А потом разработчики начинают отдавать фиксы даже не запуская проект после изменений. Зачем? Есть же тестировщик.
Ну и что, что он отдаст обратно через минуту после запуска. Мое время дороже.
Как только вы пытаетесь найти что-то после '%' ('abc%def') индекс больше не работает. Максимум можно использовать хак для «ends with» поиска ('%abc'), создав колонку с перевернутым значением и получив возможность использовать 'cba%' запрос.
В сущности тоже самое, просто проще синтаксис. Вохможно в заблуждение вводит именно то, что это интерфейс и не приходит в голову, что что-то может быть реализовано.
Так на сколько я понял кастомное решение тоже создает moment обьект. Возникает вопрос почему указание формата не сработало.
У меня небольшой опыт в реакте, поэтому вопрос, наверное, глупый. В чем смысл компонента Panel? Это же просто обёртка div с классом. У вас в index.jsx под этим самым panel еще один div с классом, но его же не вынесли в компонент.
И еще, зачем у вас в layout все children оборачиваются в div?
А разработчик приложение в принципе не запускает, когда код пишет? И тестировщиков нет, судя по всему.
Вы просто не работали с такими нагрузками, поиск в большом объеме — не редкость.
Ну, пусть даже будет маленький объем данных, кто гарантирует быстрый ответ сервера? Проблемы с сетью, сервером, базой и у вас что попало в интерфейсе.
Это не значит, что их не существует. В продакшне все бывает совсем не так как на dev окружении.
Ну, как же это нет конкуренции. Вот вы говорите 4сек: получается, что когда я печатаю xxx вы отправите 3 запроса по 4 сёк. Что будет, если ответы вернутся в порядке 3-2-1.
Тут на самом деле более глобальный вопрос: вот вы вынесли все это в разметку, повесив реализацию на браузер, кто сказал, что решение браузера единственно верное и как его поведение переопредилить?
Не думаю, что вместо одного запроса, который грузит страницу целиком, отправлять кучу мелких запросов — это действительно лучшее решение. Где-то да, но не всегда и не везде.
Со ссылками на другие элементы у вас очень простые примеры. А что если div name содержит разметку, а не простой текст?
С поисковым запросом тоже вопрос, когда будет отправляться? На каждый новый символ? Как быть с отменой предыдущего запроса? С конкуренцией запросов?
Всё довольно сыро и неоднозначно.
Ну, так это проблема не Smart Client, а организации работы в команде. Если у вас только один понимает архитектуру проекта, то это закономерно приведет к таким последствиям, вне зависимости от того, какие инструменты, библиотеки и т.п. вы используете.
Ну, я вот сейчас пишу проект на Smart Client — в самом начале выделил 2 недели на то, чтобы полностью продумать всю структуру проекта. Как view будет общаться с presenter'ом, как система будет реагировать на команды из view и т.п. Получил понятную, удобную и простую картину всего приложения. Нет вопросов, где писать каждый кусок кода.
Да, это личный проект, я могу потратить 2 недели на это(да и в реальном проекте, это тоже не так много). Но теперь, если со мной этот проект будет кто-то писать, то первое что будет сделано — это рассказано об архитектуре, почему так и какие плюсы минусы.
Если программист говорит, что что-то надо использовать, потому что это последнее достижение или все сейчас используют — то это ничего не говорит о понимании. Если он может полностью рассказать о том, как это использовать в рамках проекта, какие плюсы это принесет, какие ограничения есть и как это заменить, если придется переходить на что-то другое, то он понимает как правильно работать.
На самом деле к DI/IoC надо прийти. Не пихать его бездумно везде, потому что это «модно, стильно, молодежно», а действительно понимать зачем он там. Я его начал использовать, когда в мелком проекте было по 2-3 реализации каждого этапа работы программы. Мне просто надоело комментировать конкретные реализации для запуска программы с определенной конфигурацией. Вот тут и пригодился DI/IoC, который одной строчкой мог переключить набор реализаций на запуске.
Все нужно уметь использовать и понимать, что как и зачем. Я тоже не люблю DI/IoC в проектах где всегда одна реализация, но когда-нибудь или «а вдруг!»… Обычно это никогда.
Но мой вопрос в другом — куда по-вашему лучше двигаться? В сторону тотальной анонимности или в сторону полного ее отсутствия?
Что лучше — анонимность или ее отсутствие?
это проверка на тип, но после нее идет название переменной, которое по сути ни к чему не относится.
Если написать
то можно прочитать это как попытка приведения v к int переменной и запись результата в i.
И можно было бы сделать возвращение этим выражением true/false по аналогии со стандартной проверкой на null.
Основной смысл этого выражение — получение новой переменной с новым типом, а не проверка на тип. Поэтому я считаю, что именно As был бы уместнее.