По моему опыту, в таких проектах надо сначала внимательно выслушать и опросить представителей стороны заказачика, провести с ними несколько встреч. Но потом уже писать ТЗ самому, никого больше не слушая, давить авторитетом, и говорить что ты лучше знаешь как реализовать такой проект. Конечно, по ходу написания ТЗ нужно задавать заказчику появляющиеся вопросы, но ни в коем случае не давать ему влезать в составление проекта. Включайте режим «Мы вас выслушали, мы профессионалы, теперь мы объясняем что и как надо делать.»
В противном случае проект практически гарантированно утонет в обсуждениях, новых «гениальных» идеях, и бесконечном потоке псевдоэкспертов со стороны заказчика.
Утверждают что почти все популярные истории, мифы, сказки, легенды, фильмы, книги вообще сводятся в одной и той же сюжетной линии если снять с нее внешнюю оболочку. Причем это не зависит от страны, времени и культуры. Подробнее в Википедии по слову «Мономиф»
Благодарю! Я сам планировал провести эти эксперименты, написать тестовые скрипты. А вы все сделали за меня. Огромное спасибо!
Сейчас соберу сервер и погоняю ваши тесты на реальном железе, а потом и на реальном legacy-софте с реальными данными. Но думаю теперь уже вполне понятно чего можно ожидать.
1000 файлов в каталоге это беда для fat32. Файловые системы из linux этим не страдают
У меня как раз сейчас стоит задача положить около миллиона файлов в один каталог. (Зачем? Ответ — иначе придется сильно перепиливать legacy-код, а этого делать не хочется.)
Каталог планируется разместить на отдельном 10 терабайтном HDD на ext4, который через симлинк будет подключен к основной файловой системе.
Формально пишут, что число файлов в одном каталоге ext4 не ограничено. Утверждают что поиск файла в директории в ext4 идет по B-tree, т.е. вроде должен быть быстрым на большом количестве записей. Но все равно опасаюсь «подводных камней».
Подскажите, пожалуйста, на какие проблемы я могу нарваться?
В принципе получилось не так уж и специализированно. Там было и форматирование и формулы. Но было одно важное требование — листы и ряды можно было создавать только последовательно. Собственно за счет этого и удалось добиться огромной скорости и экономии ресурсов.
Сталкивался с подобной задачей. Формирование больших экселей на PhpExcel приводило к кошмарному расходу RAM и занимало часы времени. Я изучил известные на то время альтернативы, и в итоге был вынужден создать свой велосипед.
Для этого был изучен формат .xlsx. Оказалось что это обычный архив с кучей xml файлов (данные, стили, настройки...), картинок и прочих вспомогательных файлов. Используя эти файлы как примеры, был создан собственный велосипед с набором необходимых функций, которые работал в сотни (!) раз быстрее и практически не расходовал память. Объем потребляемой памяти не зависил от объема данных.
Правильным выбором оказалось формирование xml файлов без всяких библиотек и готовых решений, а просто путем дозаписи строчек в файл. Именно это позволило не расходовать RAM как большинство других решений и не хранить сложные структуры данных в памяти. После формирования всех xml файлов и добавления вспомогательных статических файлов и изображений, они архивировались и получался готовый .xlsx файл.
Спасибо. Если C#/WinForms действительно легко освоить на базовом уровне, я пожалуй уделю им неделю-другую своей жизни. Потребность в быстром написании всяких простых БД и утилит есть, а использовать для этого мой родной web-стек часто крайне не эффективно и избыточно.
Я последний раз занимался созданием Desctop приложений в начале 2000-ых. Delphi и С++ Builder тогда были очень удобными инструментами для создания несложных приложений типа:
— Корпоративных баз данных с множеством табличек и формочек (зачастую 90% делалось drag-and-drop)
— Программы для работы с железом
— Всякие не сильно навороченные утилиты
Из плюсов был:
— Очень низкий порог вхождения
— Толковые IT-шники осваивали платформу на базовом уровне буквально за неделю, после чего уже могли писать несложный, но вполне рабочий софт
— Большое количество специалистов любого уровня квалификации на рынке.
А какие сейчас платформы пришли на смену? Чтобы было также просто, но функционально и с простым освоением?
А ведь есть какие то стандартные методики описания лиц человека, которые используют например, органы правопорядка. Может попытаться использовать для себя эти методики, если у вас прозопагнозия. Типа не можешь это делать на уровне инстинкта, сделай это научным способом.
Мне кажется запоминать имена в массовом порядке не сильно проще чем запоминать номера телефонов. Особенно если это распространенные имена, то они не более запоминабельные чем цифры.
Та же проблема еще с раннего детства. Вот несколько лет назад узнал что это называется «Прозопагнозия», но видимо легкая ее форма.
Если я общаюсь с человеком часто и много, то я его узнаю без проблем. А вот если лишь изредка, то очень плохо запоминаю. Встретив его случайно на улице я могу не узнать совсем, а иногда могу подумать что он похож на знакомого, но уверенности у меня не будет.
Я уже давно научился выкручиваться. Если я прихожу на встречу где могут быть знакомые люди, я смотрю им в глаза и слежу за реакцией. По реакции легко понять, знакомы мы или нет. Ну и есть масса других приемов.
Оказывается, что у моего отца такая же проблема, но он тоже к этому прекрасно приспособился.
Кстати, у меня еще похоже и легкая форма дисграфии, которая в современном мире компенсируется спеллчекарами и компиляторами. Возможно это связанные вещи.
Мне бы было интересно узнать как правильно организовать работу с webpack-ом в реальных сложных проектах где совместно ведется работа и над фронтэедом и над бэкэндом (в моем случае PHP). Хочется понять как лучше все это лучше разложить по папкам. Что и как делать доступным через веб-сервера, а что закрывать. Как сделать так, чтобы на продакшен не попадали лишние файлы из пакетов, такие как документация, примеры, вспомогательные скрипты, но попадали необходимые ресурсы типа картинок.
О да. У меня был видимо один из первых Поисков. (Про «Поиск 2» я не слышал до настоящего момента.) Мой поиск был — омерзительным аппаратом. Работал в разы медленнее чем XT, с дисководом работал тоже в несколько раз медленнее. Отвратительная реализация CGA, которая работала нормально только в графическом режиме, но в текстовом практически не поддерживала работу с цветом (цвет символов мог быть только белый или зеленый, фон символов — всегда черный). Половина программ на этом чуде вообще не запускалась.
Кстати его отдавали каким то умельцам, они что то там перепаивали, навешивали и перепрошивали, после чего компьютер начал работать быстрее, изменилась раскладка клавиатуры, и в разы ускорилась работа с дисководом. А главное больше программ на нем стало запускаться.
Да, основы программирования я освоил на этом компьютере, но ностальгии никакой нет, только в вспоминаю глюки и мучения.
А вот у одноклассника был похожий компьютер МК-88. Вот это была моя мечта! Тоже аналог XT, но практически полностью совместимый с ним и не тормозящий. Полноценный CGA видеоконтроллер. Все что запускалось на XT работало и на МК-88.
Меня всегда завораживала работа производственных линий. Сотни механизмов движутся в едином танце, а на выходе получается готовый товар. Интересно, как такие линии проектируют и создают. Ведь я так понимаю они уникальные и делаются под каждое производство индивидуально. Готовую линию вряд ли купишь в магазине. Или это какие то стандартные, совместимые между собой агрегаты, которые выстраивают в ряд чтобы получилась линия?
Что то похожее и у меня. Только мне приходится разрабатывать не сайты, а скорее веб-приложения.
Много раз пытался перейти на популярные фреймворки и добавлять к ним кучу разных плагинов, библиотек. Весило это все очень много, а использовалась лишь малая часть их функционала. И самое обидное, что во всем этом зоопарке регулярно не хватало фишек которые мне удобны и приходилось все это допиливать.
В итоге плюнул и написал собственный PHP-фремворк который делает то что мне требуется в большинстве приложений. С ним же сразу в комплекте идут JavaScript/CSS компоненты типа CKEditor, Bootstap итп, Фреймоворк занимается роутингом, авторизацией, имеет компактную обертку над SQL базами данных… и кучу мелочей с которыми мне приходится постоянно сталкиваться. Там же функционал для быстрого построения CRUD редакторов баз данных, который путем описания позволяет строить древовидные и табличные редакторы.
Менюшки, навигацию, авторизацию тоже делает движок, хотя при необходимости стандартное поведение можно переопределить.
Подключается к проектам через симлик. Я постоянно чуть чуть дорабатываю фремворк работая над своими приложениями и доработки фреймворка автоматически распространяются на остальные проекты. Так получается оперативнее чем постоянно использовать отдельный git для фреймворка.
В общем, для создания нового приложения, ставятся симлинки на фреймворк, настраивается конфигурационный файл, после чего начинаем писать контроллеры, представления и модели в отдельной директории приложения.
Как ни печально, но у меня этот подход оказывается более эффективным чем классический.
Мне рассказывали как фотки и картинки «сканировали» в спектрум. Брали фотку, клали на нее оргстекло расчерченное в клеточку, одна клеточка — одно знакоместо 8х8 пикселей, и по пикселям с клавиатуры вводили пиксели в графический редактор, попутно подгоняя цвета знакомест.
И ведь очень неплохо иногда получалось.
А потом наверное купили его, освоили программирование, стали программистом, и теперь зарабатываете много денег. В общем ваше потраченное на работу лето многократно окупилось ))
Нежели прямо на машинных кодах реально программировать? Я об этом слышал, но не верил. Все таки Z80 это не древний программируемый калькулятор, где действительно программу вводили вводя коды. Инструкций много, разные модификации, операнды. Опять же, как быть с переходами, ведь добавив инструкцию, другие адреса смещаются. Я думал что термин «программирование в кодах» на самом деле подразумевает программирование на ассемблере.
В противном случае проект практически гарантированно утонет в обсуждениях, новых «гениальных» идеях, и бесконечном потоке псевдоэкспертов со стороны заказчика.
Сейчас соберу сервер и погоняю ваши тесты на реальном железе, а потом и на реальном legacy-софте с реальными данными. Но думаю теперь уже вполне понятно чего можно ожидать.
Каталог планируется разместить на отдельном 10 терабайтном HDD на ext4, который через симлинк будет подключен к основной файловой системе.
Формально пишут, что число файлов в одном каталоге ext4 не ограничено. Утверждают что поиск файла в директории в ext4 идет по B-tree, т.е. вроде должен быть быстрым на большом количестве записей. Но все равно опасаюсь «подводных камней».
Подскажите, пожалуйста, на какие проблемы я могу нарваться?
Для этого был изучен формат .xlsx. Оказалось что это обычный архив с кучей xml файлов (данные, стили, настройки...), картинок и прочих вспомогательных файлов. Используя эти файлы как примеры, был создан собственный велосипед с набором необходимых функций, которые работал в сотни (!) раз быстрее и практически не расходовал память. Объем потребляемой памяти не зависил от объема данных.
Правильным выбором оказалось формирование xml файлов без всяких библиотек и готовых решений, а просто путем дозаписи строчек в файл. Именно это позволило не расходовать RAM как большинство других решений и не хранить сложные структуры данных в памяти. После формирования всех xml файлов и добавления вспомогательных статических файлов и изображений, они архивировались и получался готовый .xlsx файл.
— Корпоративных баз данных с множеством табличек и формочек (зачастую 90% делалось drag-and-drop)
— Программы для работы с железом
— Всякие не сильно навороченные утилиты
Из плюсов был:
— Очень низкий порог вхождения
— Толковые IT-шники осваивали платформу на базовом уровне буквально за неделю, после чего уже могли писать несложный, но вполне рабочий софт
— Большое количество специалистов любого уровня квалификации на рынке.
А какие сейчас платформы пришли на смену? Чтобы было также просто, но функционально и с простым освоением?
Если я общаюсь с человеком часто и много, то я его узнаю без проблем. А вот если лишь изредка, то очень плохо запоминаю. Встретив его случайно на улице я могу не узнать совсем, а иногда могу подумать что он похож на знакомого, но уверенности у меня не будет.
Я уже давно научился выкручиваться. Если я прихожу на встречу где могут быть знакомые люди, я смотрю им в глаза и слежу за реакцией. По реакции легко понять, знакомы мы или нет. Ну и есть масса других приемов.
Оказывается, что у моего отца такая же проблема, но он тоже к этому прекрасно приспособился.
Кстати, у меня еще похоже и легкая форма дисграфии, которая в современном мире компенсируется спеллчекарами и компиляторами. Возможно это связанные вещи.
Кстати его отдавали каким то умельцам, они что то там перепаивали, навешивали и перепрошивали, после чего компьютер начал работать быстрее, изменилась раскладка клавиатуры, и в разы ускорилась работа с дисководом. А главное больше программ на нем стало запускаться.
Да, основы программирования я освоил на этом компьютере, но ностальгии никакой нет, только в вспоминаю глюки и мучения.
А вот у одноклассника был похожий компьютер МК-88. Вот это была моя мечта! Тоже аналог XT, но практически полностью совместимый с ним и не тормозящий. Полноценный CGA видеоконтроллер. Все что запускалось на XT работало и на МК-88.
Много раз пытался перейти на популярные фреймворки и добавлять к ним кучу разных плагинов, библиотек. Весило это все очень много, а использовалась лишь малая часть их функционала. И самое обидное, что во всем этом зоопарке регулярно не хватало фишек которые мне удобны и приходилось все это допиливать.
В итоге плюнул и написал собственный PHP-фремворк который делает то что мне требуется в большинстве приложений. С ним же сразу в комплекте идут JavaScript/CSS компоненты типа CKEditor, Bootstap итп, Фреймоворк занимается роутингом, авторизацией, имеет компактную обертку над SQL базами данных… и кучу мелочей с которыми мне приходится постоянно сталкиваться. Там же функционал для быстрого построения CRUD редакторов баз данных, который путем описания позволяет строить древовидные и табличные редакторы.
Менюшки, навигацию, авторизацию тоже делает движок, хотя при необходимости стандартное поведение можно переопределить.
Подключается к проектам через симлик. Я постоянно чуть чуть дорабатываю фремворк работая над своими приложениями и доработки фреймворка автоматически распространяются на остальные проекты. Так получается оперативнее чем постоянно использовать отдельный git для фреймворка.
В общем, для создания нового приложения, ставятся симлинки на фреймворк, настраивается конфигурационный файл, после чего начинаем писать контроллеры, представления и модели в отдельной директории приложения.
Как ни печально, но у меня этот подход оказывается более эффективным чем классический.
И ведь очень неплохо иногда получалось.