Во первых, не обязательно использовать чистый React Native, можно сильно упростить себе жизнь просто работая с Exponent SDK, к примеру.
Во-вторых, не все фреймворки одиноково полезны, то есть не всегда плагины для фреймворков выполняют заявленный функционал, что приводит следующему выводу — всегда призодится углубляться во внутренний кода React Native, чтобы понять как сделать даже самую простую анимацию, к примеру. Просто взять и использовать «из коробки» практически ничего нельзя, однако это не должно отражаться на отношении к фреймворку.
Если у вас негативный опыт использованиия, то скорее всего он не оправдал ваших ожиданий. А фреймворк сам по себе замечательный, исклюичтельно положительно отношусь к транспилерам и кросскомпиляции, это действительно спасает.
Попробуйте Exponent SDK, он будет немного более удобным.
У меня Intel 386 работал — я его полюбил за то что это реально был прорыв в то, без чего сейчас жизнь невозможна — многозадачные многопользовательские ОС.
В любом случае, сотрудники бывают разные, как и компании. Не самая удачаная идея сделать ставку на подобную компанию уникальных, собранных «по крупице» людей. Жизнь непредсказуема. С моей точки зрения, чем незаменимее сотрудник и чем лучше он вписывается в коллектив — тем хуже, — потому что заменить оказывается некем и нет времени на продбор следующего кандидата. Все должны быть если не на 100%, заменимы (то есть другой сорудник может выполнить 100% обязанностей первого), то на 33-50 процентов — точно, то есть 2 или 3 сотрудника смогут размазать корзину обязанностей между своим monkey buisiness, без заметных для бизнеса последствий). Естесственно, временно. Естессвенно с бонусами. Никто не хочет работать на 50% дольше, чем это обычно необходимо.
Вы понимаете, когда на карте нарисованы все дороги, а навигатор (Яндекс) проводит маршрут до конечной точки, находящейся в 100 метрах от автомобиля, длиной около 10 километров (sic!), то тут просто начнёшь задумываться, а что за фигня?
Yandex pathfinding игнорирует соотношение маршрута по прямой и найденного маршрута в соотношении 1:100 (чуть менше — 1:99) — это реально круто, по вашему?
Попробуйте доехать до ул. Александры Монаховой, 95к4, например. Просто езжайте по ул. Поляны и игнорируйте все предложения навигатора свернуть, повернуть, и разверуться, доезжая до ул. Академика Понтрягина.
Во первых, фраза «В веб приложениях вообще нет событий.» не верна.
Событие — это в данном контексте переход состяния системы из одного состояния в другое — присутствует всегда. Вы же зашли на этот сайт, чтобы написать этот пост? А какое событие произошло при этом? Вы авторизовались. Да, после того, как пользователю была создана страница, и состояние приложения передано на клиент/сервер, помнить состояние страницы не обязательно.
Но вы путаете два разных понятия — системы без/с сохранением состояний и MVC. Полушать вас, так для реализации MVC на сервере достаточно лишь знать ООП. Тогда вопрос — а почему классический ASP.NET Web Forms 2.0, так и не стал Меккой программирования? Между тем, он реализован полностью как ООП.
В случае с тонким клиентом, веб-приложением, состояние системы как набор параметров, сохраняеся на клиенте, однако сервер в более широком понимании, чем просто обработчик HTTP запросов, может хранить какое-то время память о вас, и о ваших постах, чтобы оптимизировать количество обращений к базе данных, слою DAL, BL и т.д, но это не имеет ровным счётом никакого отношения к тому, как реализована архитектура сервера.
MVC потому и пользуется огромной популярностью среди серверных, в том числе JS-фреймворков, потому что он позволяет решить главную проблему — сильную связь между компонентами, M и V. Это необходимо в первую очередь для оптимизации цикла разработки и сопровождения программного кода. Например, написав на «голом» PHP код для серверной части, вы очень скоро придёте к тому, что постоянно изменяющиеся требования к системе будут усложнять код, делать его трудночитаемым и сложно сопровождаемым, и ситуация со временем будет выходить у вас из под контроля. Для анализа использования MVC в серверных framework-ов полезно почитать о них в web. Очень популярен полностью ООП-фреймворк PHP Laravel 5.
О нём вы можете почитать тут habrahabr.ru/post/249911/, прежде чем утверждать, что "… грамотное применение ООП в любом случае нам даст систему, разделённую на слабо связанные части."
Важно понимать, что ASP.NET Web Forms, это не ASP.NET MVC 5, или ASP.NET MVC 6. У этого фреймворка отсутсвовала поддержка MVC на уровне архитектуры системы. Хотя при разработке фреймворка, изначально, команда разработчиков рассматривала этот вариант архитектуры. Но по политичнским соображениям, и в том числе, из-за сложности разработки, отказалась от его реализации — потому что требовалась совместимость с ASP, и модель ASP.NET Web Forms, как казалось, достаточно хорошо реализовывал принципы ООП — инкапсуляция, полиморфизм, наследование. Например, был разделён код HTML и сопровождающий его код на C# на уровне модулей — то есть по разным фалам, из-за чего усложнилось написание сложного кода. Впоследствии, по этой же причине, стал популярен стиль программирования «лапша» — в результате код стало сложно не только читать, ни и сопровождать, так как отладчик мог отлаживать как V- часть, так и M- часть. Условно говоря, получалась такая «зебра» из кода View, и кода Model каждой страницы, без какого-либо управления. Привязать модель к странице не получалось, использование шаблонных серверных элементов управления выходом не стали, так как привязка осуществлялась с помошью отдельного мини языка привязки через DataItem, с использованием механизма Binding, без использования принципов, используемых на данным момент — семантическая привязка — по именованию и местоположению серверных тегов.
Дело в том, что основным побочным эффектом от отказа от использования MVC, главной особенностью архитектуры ASP.NET Web Forms 2.0, стало то, что фреймворк буквально вынуждал разработчиков использовать ViewState, сессионные переменные, заботясь о той или иной реализации (того-же MVC) самостоятельно, что приводило к ошибкам проектирования и прктически 100% неправильному использованию ASP.NET. Это в свою очередь приводило к особенно сильной нагрузке на web-сервер, увеличению трафика и уменшению responsiveness страницы и сайта в целом. По сути, часто состояние системы (View + Model — это ViewState + SessionState) передавалось целиком от клента к серверу практически при каждом запросе.
Вот перечисленные выше недостатки — это и есть оснвной недостаток от отказа от использования MV* в web-приложениях. Это было характерно не только для ASP.NET Web Forms 2.0, но и для большинства фреймворков, в том числе на PHP, и польностью реализующие принципы ООП, хоть и в меньшей степени.
Еще раз, сравните Lаravel 5 и ASP.NET Web Forms 2.0. В первом реализован MVC на очень глубоком уровне, у ворого нет даже близко предствления о MVC. Более того, при разработке ASP.NET Web-Forms, разработчики архитектуры не использовали MVC в принципе.
1. Тесты надо ПИСАТЬ на основе TDD и существующего API
2. Исходный код вам НЕ ДАДУТ
3. Готов писать один и тот же тест и выполнять его же сто раз БЕЗ использования средств АВТОМАТИЗАЦИИ
>при вставке мы сначала ищем позиции в списках на всех уровнях и формируем массивы prev[]
как раз для конкурентной записи/чтения и нужны эти самые lock-free структуры данных.
Ещё бы анализ размерностей, для которых этот алгоритм «оптимален», или «достаточно эффективен» и вот ещё-бы сравенение с другими решениями… а то верить на слово очень непросто, всё-таки…
Спасибо за статью!
Хочу поделиться моим опытом:
Во первых, не обязательно использовать чистый React Native, можно сильно упростить себе жизнь просто работая с Exponent SDK, к примеру.
Во-вторых, не все фреймворки одиноково полезны, то есть не всегда плагины для фреймворков выполняют заявленный функционал, что приводит следующему выводу — всегда призодится углубляться во внутренний кода React Native, чтобы понять как сделать даже самую простую анимацию, к примеру. Просто взять и использовать «из коробки» практически ничего нельзя, однако это не должно отражаться на отношении к фреймворку.
Если у вас негативный опыт использованиия, то скорее всего он не оправдал ваших ожиданий. А фреймворк сам по себе замечательный, исклюичтельно положительно отношусь к транспилерам и кросскомпиляции, это действительно спасает.
Попробуйте Exponent SDK, он будет немного более удобным.
«Успешность не в процентах, а в сумме денег. Поэтому проценты считать бессмысленно.»
ЖК «Бунинский»
Вы понимаете, когда на карте нарисованы все дороги, а навигатор (Яндекс) проводит маршрут до конечной точки, находящейся в 100 метрах от автомобиля, длиной около 10 километров (sic!), то тут просто начнёшь задумываться, а что за фигня?
Yandex pathfinding игнорирует соотношение маршрута по прямой и найденного маршрута в соотношении 1:100 (чуть менше — 1:99) — это реально круто, по вашему?
Попробуйте доехать до ул. Александры Монаховой, 95к4, например. Просто езжайте по ул. Поляны и игнорируйте все предложения навигатора свернуть, повернуть, и разверуться, доезжая до ул. Академика Понтрягина.
habrastorage.org/files/09a/268/a66/09a268a668764ff2976bafd8b661e841.png
Событие — это в данном контексте переход состяния системы из одного состояния в другое — присутствует всегда. Вы же зашли на этот сайт, чтобы написать этот пост? А какое событие произошло при этом? Вы авторизовались. Да, после того, как пользователю была создана страница, и состояние приложения передано на клиент/сервер, помнить состояние страницы не обязательно.
Но вы путаете два разных понятия — системы без/с сохранением состояний и MVC. Полушать вас, так для реализации MVC на сервере достаточно лишь знать ООП. Тогда вопрос — а почему классический ASP.NET Web Forms 2.0, так и не стал Меккой программирования? Между тем, он реализован полностью как ООП.
В случае с тонким клиентом, веб-приложением, состояние системы как набор параметров, сохраняеся на клиенте, однако сервер в более широком понимании, чем просто обработчик HTTP запросов, может хранить какое-то время память о вас, и о ваших постах, чтобы оптимизировать количество обращений к базе данных, слою DAL, BL и т.д, но это не имеет ровным счётом никакого отношения к тому, как реализована архитектура сервера.
MVC потому и пользуется огромной популярностью среди серверных, в том числе JS-фреймворков, потому что он позволяет решить главную проблему — сильную связь между компонентами, M и V. Это необходимо в первую очередь для оптимизации цикла разработки и сопровождения программного кода. Например, написав на «голом» PHP код для серверной части, вы очень скоро придёте к тому, что постоянно изменяющиеся требования к системе будут усложнять код, делать его трудночитаемым и сложно сопровождаемым, и ситуация со временем будет выходить у вас из под контроля. Для анализа использования MVC в серверных framework-ов полезно почитать о них в web. Очень популярен полностью ООП-фреймворк PHP Laravel 5.
О нём вы можете почитать тут habrahabr.ru/post/249911/, прежде чем утверждать, что "… грамотное применение ООП в любом случае нам даст систему, разделённую на слабо связанные части."
Важно понимать, что ASP.NET Web Forms, это не ASP.NET MVC 5, или ASP.NET MVC 6. У этого фреймворка отсутсвовала поддержка MVC на уровне архитектуры системы. Хотя при разработке фреймворка, изначально, команда разработчиков рассматривала этот вариант архитектуры. Но по политичнским соображениям, и в том числе, из-за сложности разработки, отказалась от его реализации — потому что требовалась совместимость с ASP, и модель ASP.NET Web Forms, как казалось, достаточно хорошо реализовывал принципы ООП — инкапсуляция, полиморфизм, наследование. Например, был разделён код HTML и сопровождающий его код на C# на уровне модулей — то есть по разным фалам, из-за чего усложнилось написание сложного кода. Впоследствии, по этой же причине, стал популярен стиль программирования «лапша» — в результате код стало сложно не только читать, ни и сопровождать, так как отладчик мог отлаживать как V- часть, так и M- часть. Условно говоря, получалась такая «зебра» из кода View, и кода Model каждой страницы, без какого-либо управления. Привязать модель к странице не получалось, использование шаблонных серверных элементов управления выходом не стали, так как привязка осуществлялась с помошью отдельного мини языка привязки через DataItem, с использованием механизма Binding, без использования принципов, используемых на данным момент — семантическая привязка — по именованию и местоположению серверных тегов.
Дело в том, что основным побочным эффектом от отказа от использования MVC, главной особенностью архитектуры ASP.NET Web Forms 2.0, стало то, что фреймворк буквально вынуждал разработчиков использовать ViewState, сессионные переменные, заботясь о той или иной реализации (того-же MVC) самостоятельно, что приводило к ошибкам проектирования и прктически 100% неправильному использованию ASP.NET. Это в свою очередь приводило к особенно сильной нагрузке на web-сервер, увеличению трафика и уменшению responsiveness страницы и сайта в целом. По сути, часто состояние системы (View + Model — это ViewState + SessionState) передавалось целиком от клента к серверу практически при каждом запросе.
Вот перечисленные выше недостатки — это и есть оснвной недостаток от отказа от использования MV* в web-приложениях. Это было характерно не только для ASP.NET Web Forms 2.0, но и для большинства фреймворков, в том числе на PHP, и польностью реализующие принципы ООП, хоть и в меньшей степени.
Еще раз, сравните Lаravel 5 и ASP.NET Web Forms 2.0. В первом реализован MVC на очень глубоком уровне, у ворого нет даже близко предствления о MVC. Более того, при разработке ASP.NET Web-Forms, разработчики архитектуры не использовали MVC в принципе.
Что вы выберете?
1. Тесты надо ПИСАТЬ на основе TDD и существующего API
2. Исходный код вам НЕ ДАДУТ
3. Готов писать один и тот же тест и выполнять его же сто раз БЕЗ использования средств АВТОМАТИЗАЦИИ
программист со стажем 25 лет
Комментарий:
Вот это «игра за 14 дней»? или всё-таки «игра за 14 дней от гуру, который потратил годы разработки на написание движков к играм»?
>при вставке мы сначала ищем позиции в списках на всех уровнях и формируем массивы prev[]
как раз для конкурентной записи/чтения и нужны эти самые lock-free структуры данных.
Ещё бы анализ размерностей, для которых этот алгоритм «оптимален», или «достаточно эффективен» и вот ещё-бы сравенение с другими решениями… а то верить на слово очень непросто, всё-таки…