Автор в своем описании забыл прадедушку noSQL систем — Lotus Domino. И этот прадедушка до сих пор крепок и не впал в маразм, хотя багаж прошлого изрядно осложняет жизнь.
Теперь про конкретику. Я начал писать приложения на Lotus еще в середине 90-х. Плюсом была быстрота реализации проекта, кроссплатформенность, масштабируемость и документоориентированная модель данных, а огромным минусом было быстродействие и сложность перестройки ума головы с реляционной на нереляционную модель данных. С тех пор много воды и версий Lotus утекло, но основные проблемы все равно остались. Они лежат в самой идеологии документоориентированной модели. Не надо замыкаться на слабых сторонах продукта, надо просто уметь их избегать.
Мы до сих пор разрабатываем приложения на Lotus, но при этом практически всегда в системах с большими объемами данных, закладываем интеграцию с реляционной СУБД на нижнем уровне. По крайней мере, в Lotus это делается несложно и различными способами. Начиная от встроенных механизмоов синхронизации, кончая Web сервисами.
Бизнес логику однозначно проще делать на noSQL, а вот всякие редкоизменяемые и однозначно связанные объекты с большим количеством записей, типа логов, редко требуемых архивов, каталогов товаров или объектов, проще выносить в SQL.
Разберем тот же пример с профилем игрока.
В рамках гибридной реализации — профиль храниться в NoSQL хранилище и довольно часто используется.
При этом хранилище с историей скилзов, к примеру, можно реализовать как SQL, т.к. там будет огромное число стандартных записей — полная история изменения скилзов. Протокол обмена, к примеру, Web сервисы. При необходимости изменения какого-либо скилза игрока дергается соответствующий сервис на SQL системе, который вносит изменения в скиллз конкретного игрока. Триггер в таблице скилзов, в свою очередь, определяет значение нового скилза и дергает Web сервис на стороне noSQL системы, который и записывает измененный скилз в профиль конкретного игрока.
Надо просто на этапе планирования архитектуры приложения определить что где будет храниться и четко прописать интерфейсы взаимодействия.
И не стоит забывать о еще одном преимуществе такой архитектуры — при повышении нагрузки довольно просто будет разнести SQL и noSQL подсистемы по разным серверам и резко снизить загруженность Front end.
noSQL как и SQL, имеют свои сильные и слабые стороны. Это просто инструменты, которыми надо уметь пользоваться. И никто не мешает в рамках одного проекта часть данных хранить в noSQL, а часть в SQL хранилищах.
А пятилетнюю гарантию религия не позволяет?
Я тоже отдаю старые ящики, но не через 3, а через 5 и более лет, т.к. покупаю вместе с железкой расширенную гарантию.
Я говорю про код во внутренних проектах или, как в данном случае — статьи о программировании для начинающих. В международных — не только переменные, но и камменты должны быть по английски.
А почему же тогда мы здесь общаемся на русском, а не на английском?
Почему обязательным требованием к системам, разрабатываемым для наших заказчиков, является не только русскоязычный интерфейс пользователя, но и все остальное, вплоть до диагностических сообщений в логах ( правда там допускается использовать отдельные иностранные термины )?
Почему те же Microsoft, Cisco, IBM и прочая постоянно вкладывают солидные деньги для переводов технической документации на русский язык?
Вы не находите, что англоязычные форумы иногда очень тяжело читать, даже при native владении английским, особенно, когда проблему обсуждают малазиец, немец и австралиец? А если в беседу встревают японцы с китайцами, это вообще полный караул. Очень напоминает диалоги таджикских и молдавских строителей на русском.
Я информацию ищу сначала в документации, потом на русскоязычных форумах, а на англоязычные иду в последнюю очередь.
мне больше нравится Ctrl+Shift, но не в падлу использовать Ctrl+Alt и Cmd+Space.
Если серьезно, то уже несколько раз сталкивался с таким кодом. Читабельность реально выше.
Родной язык воспринимается быстрее, даже при хорошем знании английского.
А если следовать Вашей логике, то и все комментарии надо писать на хорошем английском языке.
Абсолютно правильная идея. Что мы делаем — очевидно из кода.
Кстати!
С появлением UTF-8 переменные и процедуры можно обзывать по русски.
Мало кто этим пользуется, но переменная УбитыеВороны, для русскоязычного, намного информативнее чем банальный VoronaCnt :)
Причем положительный результат должен быть получен до 21:00 субботы, чтобы в воскресенье спокойно восстановить все из бэкапа и проверить восстановленное.
А у левого кодера задача «по бырому слепить» и денег получить. Главное, чтобы на экране красиво было, т.к. кодера в лучшем случае контролирует начальник IT отдела, а в большинстве случаев просто местный маркетолог, ответственный за сайт.
Он наверное проконтролировал, и даже, возможно, получил счет, который отдал своему начальству…
А потом к счету потребовали свежий договор, который чем-то не устроил местных юристов, потом выписку из ЕГРЮЛ ( вернее его украинского аналога ), потом визирование в отделе экономической безопасности и.т.д. А поезд в это время ушел.
Я знаю несколько случаев, когда админ или начальник отдела в последний момент платили свои деньги и вместо спасибо получали по шапке, т.к. этот платеж надо было все равно проводить.
Классическая ситуация, когда сайт заказывали и принимали маркетологи, далекие от интернета. Причем, зачастую, чтобы не связываться с собственной СБ, заказывают хостинг на внешней площадке.
Более — менее работающая схема по безопасности банковского, да и вообще любого серьезного сайта, это в случае, когда все решения по движку и размещению сайта решают IT-шники, находящиеся под контролем IT-шника с структуре службы безопасности. Вот тогда возникает реальный конфликт интересов, не позволяющий маркетологам принимать в работу дырявые сайты.
Кто хочет, тот по любому научится.
Вообще, на мой взгляд, популяризация техник взлома на специализированных ресурсах, повышает общий уровень информационной защищенности общества. Т.к. умные прочитав, будут делать выводы и закрывать существующие бреши и дыры, а для дураков есть, и успешно работают законы Дарвина.
Потери 0,5 dB/m — на частоте 2000 у очень тонкого кабеля. У хорошего кабеля потери 0,15 — 0,35, правда стоимость и толщина существенно выше.
Далее, в вашей схеме основные потери на переходниках. Не надо использовать переходники. Заказывайте сразу необходимый вам разъем, желательно максимально хорошего качества, и в заводском обжиме.
маршрутизатор на столб вешать не надо, равно как и модем. Выносим только антенну. Ведь даже промышленный модем/маршрутизатор, как правило, не предназначен для улицы. Можно использовать антенну с 15 метровым кабелем. Я написал какой кабель используется мною.
Конечно берите промышленный вариант. Он существенно устойчивее. А если позволяют финансы, то лучше сразу взять маршрутизатор.
По поводу кабеля: у меня используется RADIOLAB 5D-FB Extra Low Loss Coax MIL-C-17D. как раз 15 метров, а железка стоит внизу.
Теперь про конкретику. Я начал писать приложения на Lotus еще в середине 90-х. Плюсом была быстрота реализации проекта, кроссплатформенность, масштабируемость и документоориентированная модель данных, а огромным минусом было быстродействие и сложность перестройки ума головы с реляционной на нереляционную модель данных. С тех пор много воды и версий Lotus утекло, но основные проблемы все равно остались. Они лежат в самой идеологии документоориентированной модели. Не надо замыкаться на слабых сторонах продукта, надо просто уметь их избегать.
Мы до сих пор разрабатываем приложения на Lotus, но при этом практически всегда в системах с большими объемами данных, закладываем интеграцию с реляционной СУБД на нижнем уровне. По крайней мере, в Lotus это делается несложно и различными способами. Начиная от встроенных механизмоов синхронизации, кончая Web сервисами.
Бизнес логику однозначно проще делать на noSQL, а вот всякие редкоизменяемые и однозначно связанные объекты с большим количеством записей, типа логов, редко требуемых архивов, каталогов товаров или объектов, проще выносить в SQL.
Разберем тот же пример с профилем игрока.
В рамках гибридной реализации — профиль храниться в NoSQL хранилище и довольно часто используется.
При этом хранилище с историей скилзов, к примеру, можно реализовать как SQL, т.к. там будет огромное число стандартных записей — полная история изменения скилзов. Протокол обмена, к примеру, Web сервисы. При необходимости изменения какого-либо скилза игрока дергается соответствующий сервис на SQL системе, который вносит изменения в скиллз конкретного игрока. Триггер в таблице скилзов, в свою очередь, определяет значение нового скилза и дергает Web сервис на стороне noSQL системы, который и записывает измененный скилз в профиль конкретного игрока.
Надо просто на этапе планирования архитектуры приложения определить что где будет храниться и четко прописать интерфейсы взаимодействия.
И не стоит забывать о еще одном преимуществе такой архитектуры — при повышении нагрузки довольно просто будет разнести SQL и noSQL подсистемы по разным серверам и резко снизить загруженность Front end.
Никто не мешает передавать по HTTP ряд файлов с расширением JPEG. Легально?
А что внутри?
Я тоже отдаю старые ящики, но не через 3, а через 5 и более лет, т.к. покупаю вместе с железкой расширенную гарантию.
Почему обязательным требованием к системам, разрабатываемым для наших заказчиков, является не только русскоязычный интерфейс пользователя, но и все остальное, вплоть до диагностических сообщений в логах ( правда там допускается использовать отдельные иностранные термины )?
Почему те же Microsoft, Cisco, IBM и прочая постоянно вкладывают солидные деньги для переводов технической документации на русский язык?
Вы не находите, что англоязычные форумы иногда очень тяжело читать, даже при native владении английским, особенно, когда проблему обсуждают малазиец, немец и австралиец? А если в беседу встревают японцы с китайцами, это вообще полный караул. Очень напоминает диалоги таджикских и молдавских строителей на русском.
Я информацию ищу сначала в документации, потом на русскоязычных форумах, а на англоязычные иду в последнюю очередь.
Если серьезно, то уже несколько раз сталкивался с таким кодом. Читабельность реально выше.
Родной язык воспринимается быстрее, даже при хорошем знании английского.
А если следовать Вашей логике, то и все комментарии надо писать на хорошем английском языке.
Кстати!
С появлением UTF-8 переменные и процедуры можно обзывать по русски.
Мало кто этим пользуется, но переменная УбитыеВороны, для русскоязычного, намного информативнее чем банальный VoronaCnt :)
А потом к счету потребовали свежий договор, который чем-то не устроил местных юристов, потом выписку из ЕГРЮЛ ( вернее его украинского аналога ), потом визирование в отделе экономической безопасности и.т.д. А поезд в это время ушел.
Я знаю несколько случаев, когда админ или начальник отдела в последний момент платили свои деньги и вместо спасибо получали по шапке, т.к. этот платеж надо было все равно проводить.
Более — менее работающая схема по безопасности банковского, да и вообще любого серьезного сайта, это в случае, когда все решения по движку и размещению сайта решают IT-шники, находящиеся под контролем IT-шника с структуре службы безопасности. Вот тогда возникает реальный конфликт интересов, не позволяющий маркетологам принимать в работу дырявые сайты.
Вообще, на мой взгляд, популяризация техник взлома на специализированных ресурсах, повышает общий уровень информационной защищенности общества. Т.к. умные прочитав, будут делать выводы и закрывать существующие бреши и дыры, а для дураков есть, и успешно работают законы Дарвина.
Далее, в вашей схеме основные потери на переходниках. Не надо использовать переходники. Заказывайте сразу необходимый вам разъем, желательно максимально хорошего качества, и в заводском обжиме.
По поводу кабеля: у меня используется RADIOLAB 5D-FB Extra Low Loss Coax MIL-C-17D. как раз 15 метров, а железка стоит внизу.