Имел опыт борьбы с подобными ботами (одна атака была успешной, но вместо крипто запустили скрипт майнинга биткойнов на половину ядер сервера ^^), для начала лечилось банальной сменой порта RDP из вне (3389 на любой другой) и переименованием учеток типа Администратор, admin, user, user1 и тд. на более несловарные.
А я бы не так классифицировал(в дополнение к варианту автора). ПО разрабатывается на заказ или берётся готовое.
Готовое может иметь разную реализацию: настольная коробка или в виде сервиса, ну и тд. Может иметь разную схему распространения: покупка, аренда и т.д. Плюс имеется разный подход к исходным кодам ПО.
1. На заказ:
Минусы: дорого, долго. Есть риск спустить время и деньги в трубу. Куча причин.
Плюсы: мы имеем что надо и ничего лишнего. Одежда шилась, так сказать, под нас.
2. Коробка:
Минусы: имеем нечто усредненное. Для меня и соседа. Одежда на человека среднего роста. Хорошо если я среднего роста =) По сравнению с заказной, как правило на внедрение коробки уходит больше сил. Так как приходится подстраивать свои процессы под заложенные в коробке.
Плюсы: быстро, дешево.
Выводы: коробка это быстрый старт, но как только компания выростает из возможностей коробки, та ей начинает везде жать. Под заказ — все под меня, но нужно точно рассчитать силы и время.
Идеал в общем случае: коробка, которая умеет легко кастомизироваться (силами чужих или своих спецов). Т.е. имеем быстрый старт, приемлимую цену, подтягиваем потребности бизнеса в коробку по мере их поступления.
В частном случае надо смотреть, каждый бизнес уникален + предложения на рынке ПО зачастую сложнее, чем кажутся.
про выводы… первые две записи работы с требованиями у аналитиков(пиарю как могу ^^):
1. Записывать.
2. Нумеровать.
А по поводу подобных клиентов (непривычно именовать их «инфантильными», скорее ветряными/ненадёжными/проблемными), при первом разговоре с ними как правило они дружелюбны, быстро соглашаются со всем (тут сразу первый раз прищуриваемся, как он это так быстро решения принимает), сильно упрощают действительность(мол что там, выпишем ключ. поставим и начнем работать) и т.д.
Ну и выводы такие же, фиксировать требования письменно в ТЗ, пусть и концептуальном. А главное сломить поток сознания в нормально русло. объяснить клиенту, что требования должны служить цели, быть понятными, непротиворечивыми, полными и т.д.(на диалекте клиента конечно).
Для меня вывод из эксплуатации как правило означает: клиент переходит с чего то на наш софт, необходимо вытащить оттуда все полезное. И вот некоторые производители софта подумали об этом и дали как минимум экспорт с минимальной гибкостью. А у некоторых все не очень.
Хотя вопрос конечно шире.
PS А про кайдзен я в курсе, графики для неподготовленного человека туманно идентичны (не подписаны оси, немного разный масштаб, чуть тут, чуть там). Без расшифровки не прокатит.
Еще в стадии записать Смерть(она же вывод из эксплуатации).
А по развитию — хорошо себя чувствует тот, чья система успевает за его потребностями(ну отстает по минимуму). Жизнь меняется значительно быстрее, чем кажется. Но, к сожалению, некоторые «покупатели» видят софт как «купил и забыл».
А еще «Поддержка? — Сами разберемся!», «Доработки — Почему так дорого, четверть стоимости коробки за небольшой модуль!». Тут я больше о коробочном софте для малого бизнеса.
PS А графики честно не понял =)
На тему сбора требований я бы дополнил статью следующими нюансами, имеющими место быть:
1. Один из залогов успеха сбора требований, четко понимать — кто есть кто. Принимает это лицо решения или нет. Бывают спонсоры, заказчики, пользователи. Надо понимать, кто заказчик и какие цели он ставит к системе, в которой будут трудиться сотрудники.
Опрашивая сотрудника, знакомясь с его видением системы (и требованиями к ней), можно на выходе получить полное противоречие целям заказчика. Работник хочет быть нужным и незаменимым, но при этом выполнять посильный для себя труд. У руководителей как правило другие цели ;)
2. От сотрудников мы получаем видение систему As_Is. Как правило то, как они сейчас работают. А на выходе нам надо систему под цели заказчика(To_Be). Опять включаем голову и не кидаемся делать 1в1, как просят сотрудники. Ну и к тому же, сотрудники как правило профаны в построении систем. Понятия целостности, полноты, непротиворечивости, реальности выполнения требований у них нет.
3. Как можно чаще задаем вопрос «Зачем?» и «Почему?», вместо «Что?» и «Как?». Аналитик должен понять суть вещей, а не потонуть в видении конечного решения сотрудниками.
Разумеется везде нужен здоровый компромисс, без крайностей. Прошу прощения, если кого задел очевидностью нюансов ^^. Просто частенько вижу, как на подобные грабли наступают новички в деле сбора требований. Список нюансов конечно можно продолжать. А вообще, на мой взгляд вот два первых правила сбора требования:
1. Требования надо записывать.
2. Требования надо нумеровать.
До смешного, сколько раз видел. как проблем можно было бы избежать, выполнив эти два примитивных тезиса.
Компания попыталась выставить подход к распространения своего ПО круче других подходов. Ну попытка зачтена ;)
Другое дело, что все минусы своего подхода умолчали. А некоторые минусы других решений притянули за уши.
А не случайным людям в ИТ, все эти подходы к распространению известны не по наслышке, со своими плюсами и минусами.Нет победителя, надо серьезно задумываться о выборе тех или иных подходов. У этой компании так исторически сложилось, тем и живут, ИМХО.
А у нас идет как коробка для десктопа (учетная система на .NET), так и SaaS (интернет-магазин к учетной системе на PHP) с правом выкупа.
И я бы сейчас склонился в сторону гибрида. Разнесенные части с заделом на некоторую автономность.
На многих языках есть реализация EventLoop-а: Ruby и EventMachine, C и Nginx, Pyton и Tornado, JavaScript и Nodejs, и тд. И у всех одна ниша применимости (как выше и писали): много i/o запросов, упирающихся в ожидание ответа сети/диска/сервиса, а не в процессор. С девизом «Никогда не останавливаем(не блокируем) цикл».
Ну и нода не самая быстрая реализация этого подхода. Хотя кому по душе JavaScript, то пойдёт.
По оценке интерфейса (раз уж стали сравнивать новую и старую версию), оставлю здесь очень простые, но вполне рабочие критерии сравнения:
0. Интерфейс должен решать задачу пользователя. Если не прошли этот пункт, дальше можно не оценивать.
1. Скорость, с которой решается задача пользователем. Количество кликов, капч, окон с вопросами и тд.
2. Количество ошибок на пути решения. Расположенные рядом кнопки удалить и запостить, вводящие в заблуждение подписи к полям и тд.
3. Скорость обучения пользователя работе с интерфейсом. Сначала привычка: стандартные контролы и подходы повышают скорость обучения. Логичные и заточенные под задачу клиента интфейсы так же повышают скорость.
4. Общая удовлетворенность пользователя от интерфейса. Вопрос привычки, ощущений и тд.
Впервые увидел эти(или подобные) критерии, кажется, у В.Головача. И с тех пор использую в работе и жизни. Без лишнего холивара прохожусь по критериям, сравниваю принимаю решение. Пункты 1-4 могут рассматриваться в любом порядке.
Мало знать, нужно применять.
Правильная(читай «нормальная») архитектура окупается с лихвой уже на первых этапах жизни приложения.
Тут не выбор быстро<=>точно, тут выбор быстро<=>медленно, Вы выбрали медленно. И чем больше книг в библиотеке и активнее пользователи — тем хуже поведение системы.
Но это ладно, пишите на ruby Вы отвратительно =) И тут же набежали ruby-хейтеры, про сахар, про манкинпатчинг сразу вспомнили (я никогда в жизни не патчил, думаю я не один такой).
Например следующий код можно выбросить из экшена search, это переливание ни к чему:
@books_for_s = [] books.each do |i|
@books_for_s.push i
end
И тут уже не знаю что посоветовать, может больше чужого кода смотреть, в туториалы с примерами кода вникать, стайлгайды глянуть, типовые ошибки новичков погуглить и тд.
Применительно к Вашему случаю, необходимо менять подход. У Вас стратегия: тащим все в память, перебираем с некой логикой, пользуемся. А в подобных задачах желательно на этапе записи в БД составить индекс, что бы потом силами БД простым запросом вытащить нужное. Т.е. чуть дольше пишем, но потом быстро считаем. БД уже хранит данные в нужном формате. А так как операций записи сильно меньше, то получаем большой выигрыш.
Правильно выше писали, правильно было бы использовать Elasticsearch, Sphinx и подобное.
Ну и на будущее, при обработке коллекций вместо вытягивания всей таблицы и затем перебора в памяти, используем find_each. Т.е. порционно выкачиваем записи из БД.
Это элементарные вещи. Но и Вы только в начале пути, потом разум будут волновать вопросы совсем другого порядка. Удачи!
Понятно, что код в мусорку. Но там в контроллере на каждый запрос поиска все книги из базы ползут в память, потом преобразуются в массив и тд тп. Никакого железа не хватит. Я про следующий код:
…
books = Book.all
books =
books.to_a.sort { |book1, book2| book2.getSearchIndex(params[:srch]) — book1.getSearchIndex(params[:srch]) }
…
Мне кажется подтормаживать должно уже на 100-500 книгах. На каких объемах гонялся код, подозрений не вызывало время ответа?
Все следят с интересом ^^
С виду развивается в нужном направлении. Все менее смахивает на Ruby, но не вызывает отторжение.
При грамотном пиаре ждет светлое будущее.
Поигравшись с Kemal-ом (по образу синатры), несложный API или простенькие сайтики уже можно городить. При запуске не ест ни память, ни процессор. Деплой тоже «несколько проще» рельсового.
К предыдущему посту про ActionCable в пятых рельсах — те же мысли возникли. Веб-сокеты на Kemal-е выглядят аккуратнее.
Готовое может иметь разную реализацию: настольная коробка или в виде сервиса, ну и тд. Может иметь разную схему распространения: покупка, аренда и т.д. Плюс имеется разный подход к исходным кодам ПО.
1. На заказ:
Минусы: дорого, долго. Есть риск спустить время и деньги в трубу. Куча причин.
Плюсы: мы имеем что надо и ничего лишнего. Одежда шилась, так сказать, под нас.
2. Коробка:
Минусы: имеем нечто усредненное. Для меня и соседа. Одежда на человека среднего роста. Хорошо если я среднего роста =) По сравнению с заказной, как правило на внедрение коробки уходит больше сил. Так как приходится подстраивать свои процессы под заложенные в коробке.
Плюсы: быстро, дешево.
Выводы: коробка это быстрый старт, но как только компания выростает из возможностей коробки, та ей начинает везде жать. Под заказ — все под меня, но нужно точно рассчитать силы и время.
Идеал в общем случае: коробка, которая умеет легко кастомизироваться (силами чужих или своих спецов). Т.е. имеем быстрый старт, приемлимую цену, подтягиваем потребности бизнеса в коробку по мере их поступления.
В частном случае надо смотреть, каждый бизнес уникален + предложения на рынке ПО зачастую сложнее, чем кажутся.
1. Записывать.
2. Нумеровать.
А по поводу подобных клиентов (непривычно именовать их «инфантильными», скорее ветряными/ненадёжными/проблемными), при первом разговоре с ними как правило они дружелюбны, быстро соглашаются со всем (тут сразу первый раз прищуриваемся, как он это так быстро решения принимает), сильно упрощают действительность(мол что там, выпишем ключ. поставим и начнем работать) и т.д.
Ну и выводы такие же, фиксировать требования письменно в ТЗ, пусть и концептуальном. А главное сломить поток сознания в нормально русло. объяснить клиенту, что требования должны служить цели, быть понятными, непротиворечивыми, полными и т.д.(на диалекте клиента конечно).
Хотя вопрос конечно шире.
PS А про кайдзен я в курсе, графики для неподготовленного человека туманно идентичны (не подписаны оси, немного разный масштаб, чуть тут, чуть там). Без расшифровки не прокатит.
А по развитию — хорошо себя чувствует тот, чья система успевает за его потребностями(ну отстает по минимуму). Жизнь меняется значительно быстрее, чем кажется. Но, к сожалению, некоторые «покупатели» видят софт как «купил и забыл».
А еще «Поддержка? — Сами разберемся!», «Доработки — Почему так дорого, четверть стоимости коробки за небольшой модуль!». Тут я больше о коробочном софте для малого бизнеса.
PS А графики честно не понял =)
1. Один из залогов успеха сбора требований, четко понимать — кто есть кто. Принимает это лицо решения или нет. Бывают спонсоры, заказчики, пользователи. Надо понимать, кто заказчик и какие цели он ставит к системе, в которой будут трудиться сотрудники.
Опрашивая сотрудника, знакомясь с его видением системы (и требованиями к ней), можно на выходе получить полное противоречие целям заказчика. Работник хочет быть нужным и незаменимым, но при этом выполнять посильный для себя труд. У руководителей как правило другие цели ;)
2. От сотрудников мы получаем видение систему As_Is. Как правило то, как они сейчас работают. А на выходе нам надо систему под цели заказчика(To_Be). Опять включаем голову и не кидаемся делать 1в1, как просят сотрудники. Ну и к тому же, сотрудники как правило профаны в построении систем. Понятия целостности, полноты, непротиворечивости, реальности выполнения требований у них нет.
3. Как можно чаще задаем вопрос «Зачем?» и «Почему?», вместо «Что?» и «Как?». Аналитик должен понять суть вещей, а не потонуть в видении конечного решения сотрудниками.
Разумеется везде нужен здоровый компромисс, без крайностей. Прошу прощения, если кого задел очевидностью нюансов ^^. Просто частенько вижу, как на подобные грабли наступают новички в деле сбора требований. Список нюансов конечно можно продолжать. А вообще, на мой взгляд вот два первых правила сбора требования:
1. Требования надо записывать.
2. Требования надо нумеровать.
До смешного, сколько раз видел. как проблем можно было бы избежать, выполнив эти два примитивных тезиса.
Раньше было меньше, частенько упирался в лимит.
Другое дело, что все минусы своего подхода умолчали. А некоторые минусы других решений притянули за уши.
А не случайным людям в ИТ, все эти подходы к распространению известны не по наслышке, со своими плюсами и минусами.Нет победителя, надо серьезно задумываться о выборе тех или иных подходов. У этой компании так исторически сложилось, тем и живут, ИМХО.
А у нас идет как коробка для десктопа (учетная система на .NET), так и SaaS (интернет-магазин к учетной системе на PHP) с правом выкупа.
И я бы сейчас склонился в сторону гибрида. Разнесенные части с заделом на некоторую автономность.
Ну и нода не самая быстрая реализация этого подхода. Хотя кому по душе JavaScript, то пойдёт.
0. Интерфейс должен решать задачу пользователя. Если не прошли этот пункт, дальше можно не оценивать.
1. Скорость, с которой решается задача пользователем. Количество кликов, капч, окон с вопросами и тд.
2. Количество ошибок на пути решения. Расположенные рядом кнопки удалить и запостить, вводящие в заблуждение подписи к полям и тд.
3. Скорость обучения пользователя работе с интерфейсом. Сначала привычка: стандартные контролы и подходы повышают скорость обучения. Логичные и заточенные под задачу клиента интфейсы так же повышают скорость.
4. Общая удовлетворенность пользователя от интерфейса. Вопрос привычки, ощущений и тд.
Впервые увидел эти(или подобные) критерии, кажется, у В.Головача. И с тех пор использую в работе и жизни. Без лишнего холивара прохожусь по критериям, сравниваю принимаю решение. Пункты 1-4 могут рассматриваться в любом порядке.
Правильная(читай «нормальная») архитектура окупается с лихвой уже на первых этапах жизни приложения.
Тут не выбор быстро<=>точно, тут выбор быстро<=>медленно, Вы выбрали медленно. И чем больше книг в библиотеке и активнее пользователи — тем хуже поведение системы.
Но это ладно, пишите на ruby Вы отвратительно =) И тут же набежали ruby-хейтеры, про сахар, про манкинпатчинг сразу вспомнили (я никогда в жизни не патчил, думаю я не один такой).
Например следующий код можно выбросить из экшена search, это переливание ни к чему:
@books_for_s = []
books.each do |i|
@books_for_s.push i
end
И тут уже не знаю что посоветовать, может больше чужого кода смотреть, в туториалы с примерами кода вникать, стайлгайды глянуть, типовые ошибки новичков погуглить и тд.
Правильно выше писали, правильно было бы использовать Elasticsearch, Sphinx и подобное.
Ну и на будущее, при обработке коллекций вместо вытягивания всей таблицы и затем перебора в памяти, используем find_each. Т.е. порционно выкачиваем записи из БД.
Это элементарные вещи. Но и Вы только в начале пути, потом разум будут волновать вопросы совсем другого порядка. Удачи!
…
books = Book.all
books =
books.to_a.sort { |book1, book2| book2.getSearchIndex(params[:srch]) — book1.getSearchIndex(params[:srch]) }
…
Мне кажется подтормаживать должно уже на 100-500 книгах. На каких объемах гонялся код, подозрений не вызывало время ответа?
С виду развивается в нужном направлении. Все менее смахивает на Ruby, но не вызывает отторжение.
При грамотном пиаре ждет светлое будущее.
Поигравшись с Kemal-ом (по образу синатры), несложный API или простенькие сайтики уже можно городить. При запуске не ест ни память, ни процессор. Деплой тоже «несколько проще» рельсового.
К предыдущему посту про ActionCable в пятых рельсах — те же мысли возникли. Веб-сокеты на Kemal-е выглядят аккуратнее.