Для большинства достаточно крупных проектов используются именно Мэйкфайлы, а не autotools, причём написанные людями Мэйкфайлы. Это хорошо ложится в практику ежедневных билдов.
Вы будете смеяться, но в Windows мэйк используется ещё шире, чем юниксах. 95% известным мне проектов собираются в Виндах с помощью микрософтского nmake.
Но чем сложнее становится проект, тем сложнее становятся Мэйкфайлы. Всё больше уровней включений (include) становится в Мэйкфайлах.
Постепенно, с ростом проекта, поддерка Мэйкфайлов становится всё более и более утомительной, затратной. И тут уже действительно недостатки мэйка становятся видны невооруженным глазом. Но есть другая система, которая написана специально, чтобы преодолеть недостатки мэйка (Особенно зависимости, обслуживание зависимостей). Я говорю об Apache Ant. ant.apache.org/
Да, корни Анта из Жавы, но он применим для сборки систем на любых языках программирования, на любых ОС.
Тем кто планирует писать немаленькие программы/системы настоятельно рекомендую обратить внимание на Ant.
Речь идёт не о замене командных строк баша, а о том, что питоновские скрипты вполне заменяют шеловские обычные скрипты. Автор как раз это и показывал в статье.
Разве вам не приходилось видеть установочные скрипты на многие тысячи строк?
Речь о том, что можно реализовать их на Питоне и они будут изящными. Причём очень важный момент: в них можно использовать всю мощь Питона и задействовать возможности для использования которых в традиционных скриптах пришлось бы писать Си-шные утилитки.
Я знаю bash и Windows PowerShell, но теперь я использую для всего именно Питон.
Главное преимущество Питона: он МОЩНЕЕ чем просто язык сценариев; это полноценный язык программирования. Т.е. написать скрипт не труднее чем на баше, но если нужно можно добавить какую угодно функциональность. А для традиционных скриптов пришлось бы писать и использовать программу на Си.
Спасибо за модуль.
Только я бы хотел указать на главный недостаток вашей реализации. Нет, это не загрузка проца.
Главный недостаток: им практически невозможно пользоваться. Поясняю, что я имею в виду: Допустим я хочу нажать тег справа. Пока я его ловлю он быстро едет в центр и далее налево. Слева его поймать тоже невозможно, потому, что он едет обратно. Т.е. пользователь через десяток секунд неизменно понимает, что ловить теги нужно в центре. ;-)
Вот на снимке я играю в игру «поймай CMS». Как видно в Опере не такая уж большая загрузка проца. 25% от старенького, слабенького двухядерника.
Т.е. вам нужно улучшить удобство использования скрипта в первую очередь. Сравните с исходным: там есть около четырёх секунд, чтобы нажать ссылку, да и сами ссылки гораздо крупнее.
MVC был придуман в начале 80-х в smalltalk,
в 1996 в книге сейчас известной как GoF был введён шаблон проектирования Observer (Наблюдатель) — более общий случай MVC.
Рассмотрите его: Observer design pattern
Он улучшит код ровно на столько на сколько вы ему подадите плохих данных.
Т.е. результат недвусмысленно связан со статистическими характеристиками исходных данных.
Вы же будете исходные данные создавать? Вот какие константы скормить Рендому() — то и получится. Я имею в виду не его инициализацию большим числом, чтобы числа получись как-бы случайные. Я имею в виду характеристики распределения (дисперсия, мат ожидание, закон...)
(И, да, равномерное распределение можно преобразовать в любое другое).
Но вот с синдромом «Not Invented Here» не всё так очевидно.
Привожу отрывок из статьи Джоэла Сопольски:
In-ter-est-ing. I hadn't known that. I guess that explained why Excel had its own C compiler.
By now I'm sure many of my readers are rolling on the floor laughing. «Isn't Microsoft stupid,» you're thinking, «they refused to use other people's code and they even had their own compiler just for one product.»
Not so fast, big boy! The Excel team's ruggedly independent mentality also meant that they always shipped on time, their code was of uniformly high quality, and they had a compiler which, back in the 1980s, generated pcode and could therefore run unmodified on Macintosh's 68000 chip as well as Intel PCs. The pcode also made the executable file about half the size that Intel binaries would have been, which loaded faster from floppy disks and required less RAM.
Перевод:
Ин-те-ре-снень-ко. Я этого не знал. Я ломал голову почему Эксель имеет свой собственный компилятор Си.
Но сейчас, я уверен, многие из моих читателей катаются по полу от смеха. Думая, «Ну не тупицы ли в Микрософте», «они отвергли использования чужого кода и у них даже есть свой собственный компилятор для одного продукта»
Но не факт, братец! Яростно независимая точка зрения команды Экселя также означала, что они делали поставки вовремя, их код был неизменно высокого качества, и у них был компилятор, который (оглядываясь на 80-е) генерировал пи-код по этому мог исполняться в неизменном виде на 68000-ых процессорах Макинтошей и на Интеловских ПК. Пи-код также сделал их исполняемые файлы приблизительно в два раза меньше, чем были бы на Интеле, и которые быстрее загружались в с дискет и требовали меньше памяти.
От себя добавлю:
Команда Экселя (и теперь МС офиса) продолжает свою линию, и выпускает к 2007 году офис2007. С изумительными красивыми, и очень быстрыми контролами.
И очень стабильный-безглючный. За эти два года был только один баг, для которого я скачал патч, и то так, на всякий случай.
Что сделал я первым делом после того как увидел офис 2007 в какнун Нового года?
(Не, ну, разумеется нулевым делом я его потыкал и разнообразно оценил, а вот потом?)
А сразу потом я подумал: «Я ХОЧУ эти контролы! Они красивые! Они быстрые! Они безглючные!» Я стал лазить по сайту МС, качал бета-версию Визуальной Студии 2008. А их нет. Это НЕстандартные контролы. Как и всегда в офисе. Они недоступны!
И повелось тут подражателей великое множество. Библиотеки контролов, выглядящих «также как офис» заполонили сайты через месяц. Все-все-все они были тормозными. Причём некоторые непрелично. Даже контролы от тайного лидера контролостроения тормозили.
Контролы были не просто недоступны, они недоступны даже для МС. И вот, через полтора года, Микрософт ПОКУПАЕТ библиотеку лучшего из подражателей и распространяет её бесплатно с первым сервис-паком для Визуальной Студии 2008.
(Кстати, это библиотека питерской компании за что им большая уважуха и всемирная известность в узких кругах).
Резюме:
Так что, господа, не всё так ясно с синдромом «Изобретено не здесь». Читайте статью.
1. Откройте habr.css любым редактором (notepad, он же блокнот, подойдёт)
2. Скопируйте все стили из него.
3. Добавьти их в ваш файл.
уточнил инструкцию.
Давайте вместе определим почему не работает. (Через личные сообщения)
Вы будете смеяться, но в Windows мэйк используется ещё шире, чем юниксах. 95% известным мне проектов собираются в Виндах с помощью микрософтского nmake.
Но чем сложнее становится проект, тем сложнее становятся Мэйкфайлы. Всё больше уровней включений (include) становится в Мэйкфайлах.
Постепенно, с ростом проекта, поддерка Мэйкфайлов становится всё более и более утомительной, затратной. И тут уже действительно недостатки мэйка становятся видны невооруженным глазом. Но есть другая система, которая написана специально, чтобы преодолеть недостатки мэйка (Особенно зависимости, обслуживание зависимостей). Я говорю об Apache Ant. ant.apache.org/
Да, корни Анта из Жавы, но он применим для сборки систем на любых языках программирования, на любых ОС.
Тем кто планирует писать немаленькие программы/системы настоятельно рекомендую обратить внимание на Ant.
Эта статья важна именно для Windows, потому, что там нет установленых по умолчанию bash и Windows PowerShell.
Разве вам не приходилось видеть установочные скрипты на многие тысячи строк?
Речь о том, что можно реализовать их на Питоне и они будут изящными. Причём очень важный момент: в них можно использовать всю мощь Питона и задействовать возможности для использования которых в традиционных скриптах пришлось бы писать Си-шные утилитки.
Главное преимущество Питона: он МОЩНЕЕ чем просто язык сценариев; это полноценный язык программирования. Т.е. написать скрипт не труднее чем на баше, но если нужно можно добавить какую угодно функциональность. А для традиционных скриптов пришлось бы писать и использовать программу на Си.
Ему искреннее спасибо.
Там люди привыкли платить. Т.е. они знают, что любая работа должна быть оплачена и считают это само-собой разумеющимся, нормальным и логичным.
Никто не попросит нахаляву что-нибудь добавить.
Только я бы хотел указать на главный недостаток вашей реализации. Нет, это не загрузка проца.
Главный недостаток: им практически невозможно пользоваться. Поясняю, что я имею в виду: Допустим я хочу нажать тег справа. Пока я его ловлю он быстро едет в центр и далее налево. Слева его поймать тоже невозможно, потому, что он едет обратно. Т.е. пользователь через десяток секунд неизменно понимает, что ловить теги нужно в центре. ;-)
Вот на снимке я играю в игру «поймай CMS». Как видно в Опере не такая уж большая загрузка проца. 25% от старенького, слабенького двухядерника.
Т.е. вам нужно улучшить удобство использования скрипта в первую очередь. Сравните с исходным: там есть около четырёх секунд, чтобы нажать ссылку, да и сами ссылки гораздо крупнее.
в 1996 в книге сейчас известной как GoF был введён шаблон проектирования Observer (Наблюдатель) — более общий случай MVC.
Рассмотрите его: Observer design pattern
Т.е. результат недвусмысленно связан со статистическими характеристиками исходных данных.
Вы же будете исходные данные создавать? Вот какие константы скормить Рендому() — то и получится. Я имею в виду не его инициализацию большим числом, чтобы числа получись как-бы случайные. Я имею в виду характеристики распределения (дисперсия, мат ожидание, закон...)
(И, да, равномерное распределение можно преобразовать в любое другое).
Но вот с синдромом «Not Invented Here» не всё так очевидно.
Привожу отрывок из статьи Джоэла Сопольски:
Перевод:
Статья (англ.): In Defense of Not-Invented-Here Syndrome
От себя добавлю:
Команда Экселя (и теперь МС офиса) продолжает свою линию, и выпускает к 2007 году офис2007. С изумительными красивыми, и очень быстрыми контролами.
И очень стабильный-безглючный. За эти два года был только один баг, для которого я скачал патч, и то так, на всякий случай.
Что сделал я первым делом после того как увидел офис 2007 в какнун Нового года?
(Не, ну, разумеется нулевым делом я его потыкал и разнообразно оценил, а вот потом?)
А сразу потом я подумал: «Я ХОЧУ эти контролы! Они красивые! Они быстрые! Они безглючные!» Я стал лазить по сайту МС, качал бета-версию Визуальной Студии 2008. А их нет. Это НЕстандартные контролы. Как и всегда в офисе. Они недоступны!
И повелось тут подражателей великое множество. Библиотеки контролов, выглядящих «также как офис» заполонили сайты через месяц. Все-все-все они были тормозными. Причём некоторые непрелично. Даже контролы от тайного лидера контролостроения тормозили.
Контролы были не просто недоступны, они недоступны даже для МС. И вот, через полтора года, Микрософт ПОКУПАЕТ библиотеку лучшего из подражателей и распространяет её бесплатно с первым сервис-паком для Визуальной Студии 2008.
(Кстати, это библиотека питерской компании за что им большая уважуха и всемирная известность в узких кругах).
Резюме:
Так что, господа, не всё так ясно с синдромом «Изобретено не здесь». Читайте статью.
Для этих тестовых данных не изменит картины, а вот на реальных данных ухудшило бы производительность IndusCode() однозначно (и, существенно).