И вот заодно дико классная классическая книжка по регекспам и не только. Помимо прочего, рассказывают, почему нельзя парсить Html с помощью regex: en.wikipedia.org/wiki/Introduction_to_Automata_Theory,_Languages,_and_Computation
Выше в комментариях я писал, что частично это из-за wpf.
Частично из-за того, что garbage collection не выполняется часто (на самом деле программа потребляет около 70 мегабайт), а каждый поиск добавляет 0-10 мегабайт (в зависимости от числа совпадений) (в следующих версиях я собираюсь запускать сборку мусора принудительно).
И главное--кэш всех папок занимает очень много места, 40 мегабайт на моем компьютере (его можно оптимизировать и сократить в два раза, и даже больше), но для первой версии я решил этого не делать--хотелось посмотреть, понадобится ли она вообще кому-нибудь.
А подскажите, какой путь вы вводите в «Exclude template»? (предполагается, что там будут не полные пути а-ля C:\Windows, а имена папок («Windows») или шаблоны имен папок («Win.*»)).
Дело даже не в том, что оно халтурное, а в том, что оно невыгодно в целом. Представим, что было б, если б профессию СЕО запретили:
1. поисковик выдавал бы только релевантные результаты
2. бизнесу не пришлось бы тратить деньги на сео
3. освободилась бы куча людей, из которых можно сделать полезных членов общества (пожарников, там; программистов)
4. поисковикам бы не пришлось тратить деньги на постоянное изменение алгоритмов, внедрение, тестирование
Но из-за стихийного процесса развития сео, который выгоден бизнесу в коротком временном и пространственном масштабе, мы имеем то, что имеем :-(
Я не вполне понимаю вас, к сожалению. В .Net сборка, по-моему, одинакова для любого типа мусора: три поколения, проход по ссылкам до стека (roots), очередь freachable, и т.п. И все эти манипуляции занимают какое-то время.
Я буду только рад, если вы допишете этот функционал сами (нужно поменять только один класс, притом покрытый тестами) :-). А может быть, и у меня дойдут руки до этого--но не в ближайшее время.
Да, я думал над такой возможностью, но решил пока не реализовывать--сохранить время для основного функционала. И я пока не решил, стоит ли оно того: если набирать такие сложные пути, то сам смысл использования утилитки теряется--проще зайти в эксплорер и дойти до нужной папки.
Откровенно говоря, с WPF я преследовал еще и корыстный интерес--попробовать его после прочтения книжки и тестового проекта. Но теперь вынужден согласиться с вами--на WinForms было бы разрабатывать быстрее и проще, и само приложение было бы легковесней.
Мне показалось, что WPF, мягко говоря, все еще далеко не зрелый: многие вещи даже из WinForms не поддерживаются (например, отключение кнопок minimize и maximize в окошке); оказалось, что если в списке (ListBox) поставить width=auto, то ширина рассчитывается по _видимым_ элементам--то есть при скроллинге она может меняться, и сам скроллинг безумно медленный--пришлось ставить костыли. И миллион таких вещей.
Model-View-View Model даже для такого маленького приложения оказался недостаточным.
Я года 3-4 до этого писал на .net (и сейчас пишу, как можно заметить :-) ), и тоже думал, что это правда.
Но все-таки это ненормально, когда пустое приложение на WPF поглощает 40-60 мб оперативной памяти сразу же (можете проверить, создав пустой проект в Visual Studio). Я пользуюсь еще классной утилитой Manic Time--с ней такая-же беда. Это что касается памяти.
Jit компиляция медленная--с этим даже Рихтер согласен (потому я добавил прекомпиляцию ngen в инсталлере, так же делает и Paint.Net, и Visual Studio, и Sql Server Management Studio).
Сборка мусора, я уверен, медленная. Есть вот такой open-source проект для моделирования гидродинамики (на C++): www.palabos.org/. Так вот, в нем _нигде_ не пользуются виртуальными функциями, только шаблонный полиморфизм, потому что виртуальные функции--это медленно (это я сам замерял тестами в своей программке для CFD). А garbage collection--это невероятно медленно.
Да, я в курсе, но вот от необходимости совершать все эти действия я и хотел бы избавиться (открыть explorer, перевести взгляд на адресную строку, щелкнуть на ней, печатать полный путь, нажимая tab и тп) (собственно, и постарался объяснить в статье).
И заодно добавить поиск по неполному имени (prog fil вместо downloaded program files) (это быстро и вы даже можете не знать точное имя).
И, кроме того, удобно искать папку только по имени, не будучи уверенным, где она находится (например, вы подзабыли, находится ли каталог Blah-Blah в папке Program Files или Program Files (x32))--вам придется два раза набирать путь, если сразу не угадаете.
И мне нравится возможность просматривать список соответствий сразу же при нажатии клавиш (чтоб иметь возможность изменить запрос, если я ошибся в имени папки).
1. Нет, к сожалению, не работает. Но идея отличная--как будет время, постараюсь сделать. Мне этого тоже не хватает)
2. Тоже классная идея, спасибо, и тоже, надеюсь, через какое-то время добавлю
Я не спорю, но идея в том, что при прочих равных для создания сайта на хорошей технологии надо полгода опыта, а на плохой--3 года.
Например, ASP.NET и ASP.NET MVC. ASP.NET--полный отстой, и, к примеру, даже с тремя годами опыта вам понадобится 2 месяца, чтоб сделать сайтик. А с ASP.NET MVC человеку с месяцем опыта понадобится 1 месяц, чтоб сделать тот же сайтик.
Потому что в ASP.NET MVC лучшая архитектура (более прозрачная, меньше скрытых зависимостей, меньшая связность компонент и тп), и он лучше соответствует парадигме веба. Фраза «Возможно вы просто не сделали DOM.sinkEvents» намекает на те же проблемы, что есть в ASP.NET; но не на 100%))
Я не работал с GWT, но, мне кажется, ваш комментарий намекает на то, почему разработка может быть медленной: нужно не забыть использовать dom.sinkEvents (и откуда-то узнать об этом). И будет еще миллион мест, где нужно вызвать/настроить/объявить/изменить какую-нибудь мелочь.
Связка js/html/css, помимо single responsibility и modularity подкупает своей прозрачностью.
И вот еще что. «у хорошего начальника главная задача взрастить человека»--это тоже, на мой взгляд, крайне негативный подход. Это одна из задач начальника. А другая--обеспечить комфортную работу подчиненным. И вы ее не выполняете таким образом.
Я говорю о том же. Это плохой, медленный метод. Даже если вы сможете быстро научить человека ваять код, то можете отбить всякое желание продолжать развиваться, и стать, например, архитектором продукта. То есть даже если (хотя и это не так, по-моему--см. выше) в короткой перспективе это хороший метод, то в длительной--точно нет.
По-моему, это ужасный метод. В первую очередь, он противоречит ценностям гуманизма, которые и так не распространены на постсоветском пространстве--и то, что вы считаете его действенным--лишнее тому подтверждение.
А если детально--то такая критка вовсе не конструктивная, а излишне агрессивная; она демотивирует; она приводит к стрессу, что плохо само по себе (мы ведь работает не просто для того, чтобы работать, а чтобы обеспечивать комфортное существование себе и другим); стресс ухудшает качество работы, так что это неэффективный метод; такие отношения излишне иерархичны (типа «я начальник, ты говно»), поэтому подавляют инициативу в подчиненных и коллегах и конструктивную критику с их стороны (в agile ведь есть ретроспективы итераций!); методом легко злоупотреблять (потому что чувство власти--довольно сильное чувство); и, что хуже всего, он очень легко копируется в будущем (потому что он апеллирует к властолюбию и тщеславию; и это сравни дедовщине), и обученный таким методом сам будет продолжать его использовать, обучая других.
Слава богу, у меня не было ни одного старшего коллеги или мэнеджера с такими замашками (но был преподаватель на военке), и если бы попался--я постарался бы уволиться. И советую всем знакомым (начинающим работу)--если вам попадается такой мэнеджер, то, скорее всего, увольнение/уход от него--лучший выход (конечно, все зависит от деталей: от зарплаты или, может, человек очень грамотно и сбалансированно им пользуется, не злоупотребляя, или коллектив просто отличный).
Выше в комментариях я писал, что частично это из-за wpf.
Частично из-за того, что garbage collection не выполняется часто (на самом деле программа потребляет около 70 мегабайт), а каждый поиск добавляет 0-10 мегабайт (в зависимости от числа совпадений) (в следующих версиях я собираюсь запускать сборку мусора принудительно).
И главное--кэш всех папок занимает очень много места, 40 мегабайт на моем компьютере (его можно оптимизировать и сократить в два раза, и даже больше), но для первой версии я решил этого не делать--хотелось посмотреть, понадобится ли она вообще кому-нибудь.
1. поисковик выдавал бы только релевантные результаты
2. бизнесу не пришлось бы тратить деньги на сео
3. освободилась бы куча людей, из которых можно сделать полезных членов общества (пожарников, там; программистов)
4. поисковикам бы не пришлось тратить деньги на постоянное изменение алгоритмов, внедрение, тестирование
Но из-за стихийного процесса развития сео, который выгоден бизнесу в коротком временном и пространственном масштабе, мы имеем то, что имеем :-(
Но спасибо за фидбек!
Мне показалось, что WPF, мягко говоря, все еще далеко не зрелый: многие вещи даже из WinForms не поддерживаются (например, отключение кнопок minimize и maximize в окошке); оказалось, что если в списке (ListBox) поставить width=auto, то ширина рассчитывается по _видимым_ элементам--то есть при скроллинге она может меняться, и сам скроллинг безумно медленный--пришлось ставить костыли. И миллион таких вещей.
Model-View-View Model даже для такого маленького приложения оказался недостаточным.
Но все-таки это ненормально, когда пустое приложение на WPF поглощает 40-60 мб оперативной памяти сразу же (можете проверить, создав пустой проект в Visual Studio). Я пользуюсь еще классной утилитой Manic Time--с ней такая-же беда. Это что касается памяти.
Jit компиляция медленная--с этим даже Рихтер согласен (потому я добавил прекомпиляцию ngen в инсталлере, так же делает и Paint.Net, и Visual Studio, и Sql Server Management Studio).
Сборка мусора, я уверен, медленная. Есть вот такой open-source проект для моделирования гидродинамики (на C++): www.palabos.org/. Так вот, в нем _нигде_ не пользуются виртуальными функциями, только шаблонный полиморфизм, потому что виртуальные функции--это медленно (это я сам замерял тестами в своей программке для CFD). А garbage collection--это невероятно медленно.
И заодно добавить поиск по неполному имени (prog fil вместо downloaded program files) (это быстро и вы даже можете не знать точное имя).
И, кроме того, удобно искать папку только по имени, не будучи уверенным, где она находится (например, вы подзабыли, находится ли каталог Blah-Blah в папке Program Files или Program Files (x32))--вам придется два раза набирать путь, если сразу не угадаете.
И мне нравится возможность просматривать список соответствий сразу же при нажатии клавиш (чтоб иметь возможность изменить запрос, если я ошибся в имени папки).
2. Тоже классная идея, спасибо, и тоже, надеюсь, через какое-то время добавлю
Например, ASP.NET и ASP.NET MVC. ASP.NET--полный отстой, и, к примеру, даже с тремя годами опыта вам понадобится 2 месяца, чтоб сделать сайтик. А с ASP.NET MVC человеку с месяцем опыта понадобится 1 месяц, чтоб сделать тот же сайтик.
Потому что в ASP.NET MVC лучшая архитектура (более прозрачная, меньше скрытых зависимостей, меньшая связность компонент и тп), и он лучше соответствует парадигме веба. Фраза «Возможно вы просто не сделали DOM.sinkEvents» намекает на те же проблемы, что есть в ASP.NET; но не на 100%))
Связка js/html/css, помимо single responsibility и modularity подкупает своей прозрачностью.
А если детально--то такая критка вовсе не конструктивная, а излишне агрессивная; она демотивирует; она приводит к стрессу, что плохо само по себе (мы ведь работает не просто для того, чтобы работать, а чтобы обеспечивать комфортное существование себе и другим); стресс ухудшает качество работы, так что это неэффективный метод; такие отношения излишне иерархичны (типа «я начальник, ты говно»), поэтому подавляют инициативу в подчиненных и коллегах и конструктивную критику с их стороны (в agile ведь есть ретроспективы итераций!); методом легко злоупотреблять (потому что чувство власти--довольно сильное чувство); и, что хуже всего, он очень легко копируется в будущем (потому что он апеллирует к властолюбию и тщеславию; и это сравни дедовщине), и обученный таким методом сам будет продолжать его использовать, обучая других.
Слава богу, у меня не было ни одного старшего коллеги или мэнеджера с такими замашками (но был преподаватель на военке), и если бы попался--я постарался бы уволиться. И советую всем знакомым (начинающим работу)--если вам попадается такой мэнеджер, то, скорее всего, увольнение/уход от него--лучший выход (конечно, все зависит от деталей: от зарплаты или, может, человек очень грамотно и сбалансированно им пользуется, не злоупотребляя, или коллектив просто отличный).