Search
Write a publication
Pull to refresh
-1
0
Send message
Какую такую надежность дает журналирование, если флешка внезапно помирает через 3 месяца?
А что на счет памяти, в скорость обращения к которой упираются современные процессоры, и которая теперь будет делиться между всеми этими ядрами?
Попробовал в опере. Если открыть html с такой картинкой с src на локальном диске, то система виснет. Если же открыть такую страницу по http, то не виснет.
Вся беда возникает, когда инструмент используют не только когда он что-то облегчает, а для всего подряд, т.е. пытаются сделать из конкретной тулзы инструмент на все случаи жизни. А потом идут длинные споры про то что инструмент не идеален, потому что он может не всё на свете. Так не бывает. Автоматизация всегда подразумевает какие-то ограничения. Инструмент применяют там, где он удобен. Остальное — уже какое-то извращение.
Cистема — что-то между CRM и 1С. Cущностей то около пол сотни. А вот запросов на каждую по несколько. Чтобы не писать генерацию SQL на каждый случай, зависящий от аргументов, я сделал один генератор SQL, который бы подходил в большинстве простых случаев.
В общем конечно же зависит от проекта. У меня это были в основном CRUD с фильтрами. А для отчетов конечно же отдельные классы с SQL. Тут ORM лишнее, согласен.
Как-то написал что-то типа ORM для себя, потому что надоело писать сотни одинаковых запросов. Про то как оно назывется даже и не знал тогда, что вылилось в велосипед. Просто сделал класс, представляющий таблицу в базе, где экзепляр класса — это запись в таблице, со стандартными функциями получения списка/удаления/сохранения, а так же функции построения кусочков sql-запроса (типа where, order by), которые можно переопределить. Наследуясь от этого класса можно переопределить таблицу, особенности полей и добавить методы с какими-то нетипичными/оптимизированными запросами. А сам класс-предок использует позднее связывание и строит sql с учетом особенностей потомка. Для больших результатов делал ленивую подгрузку (доп. класс с интерфейсом массива). В итоге удобно получилось и намного меньше писанины. С голым SQL теперь сталкиваюсь только для необходимой оптимизации и сильно нестандартных запросов. В общем быстрее получается написать свой кустарный ORM, чем писать сотни однообразных SQL-запросов и методов.
Зашел на вашу lyra. То есть каждый тест вконтактике теперь тоже можно назвать искусственным интеллектом?
Знаменитое фото врать не будет! image
Опять рекламная статья. Зачастили что-то с этим делом. Я ещё понимаю рекламные блоки где-то сбоку. Но вот так — это дело уничтожит репутацию хабра рано или поздно. То у них CRM постоянно какая-то, то PVS studio. Теперь вот это.
остаётся надеяться что люди будущего (или как они будут называться) придумают gzip, mp3, utf и всё такое точно в таком же виде как есть сейчас. и не подумают что все эти пленки — просто прикольное топливо для костра
Вот только поисковики не будут кликать по кнопке «ещё» и индексировать подгружаемый контент.
если не затруднит, скиньте, пожалста, ссылочку как с помощью nginx и php обрабатывать UDP. будет очень познавательно
Кроме соцсетей существуют и совершенно другие высоконагруженные проекты. Возможно кто-то проектирует что-то / вынашивает идею, где было бы очень полезно заранее знать с чем примерно придется иметь дело, когда нагрузка будет очень большой. Статья интересная, но читать трудновато, конечно.
Почему уж тайные? Очень многие шаред-хостеры держат индейцев, и подозреваю что в основном ради .ht-файлов. Потому что разрешать писать свои конфиги для nginx клиентам никто не даст.
А затем, что сервер может быть не для себя (хостинг, например) и требуется, чтобы были .htaccess файлы
Не обязательно. Может быть они чем-то кроме «этого» занимались. Да и 10 человеко-лет — это рабочее время.
2

Information

Rating
Does not participate
Registered
Activity