Comments 23
Надеюсь кому-то это было интересно :-)
у вас отличная и нескучная статья!
(продолжает дальше смотреть как в соседнем ноутбуке один С & С++ & Qt проект для automotive компилирутеся и линкуется в течение 6 часов)
Хочу поделиться с вами историей как два админа программили и что из этого вышло.
Ничего не получилось...
Не понял, в чём смысл говорить о многопоточности Руби и не использовать горутины в Go вообще.
Про руби это просто отступление. Результаты не участвовали в общем забеге. Мне просто было интересно как это работает именно в руби.
К тому же у нас же не стояла задача использовать многопоточность или как то ещё оптимизировть работу. Мы использовали максимально простой и прямолинейный подход. Можете считать что это Just for fun ))
На Java обход файлов можно сделать в 1 строку, примерно так
Files.walk(Paths.get(directory))
.filter(Files::isRegularFile)
// .filter(pattern::matches)
.collect(Collectors.toList())Причем стоит regex pattern вынести в final static singleton, аналогично про DateTimeFormatter (не используйте SimpleDateFormat вообще).
Плюс используется одна из худших json библиотек по производительности, посмотрите лучше в сторону https://github.com/ngs-doo/dsl-json или http://jsoniter.com/
Спасибо, в следующий раз я буду иметь это ввиду.
Но прошу учесть что на java я писал вообще первый раз и в таких тонкостях ещё не разбираюсь.
А 1 строка работает быстрее?
Не сравнивал, но скорее да.
Первый вариант использует старый IO API в котором даже баги не чинят https://bugs.java.com/bugdatabase/view_bug.do?bug_id=4285834
Второй вариант должен использовать новый NIO API и не создавать лишнего мусора для хранения списка файлов.
…оказался в топе, жалко…
С первого раза неправильно прочитал.
Разве логи не хранятся в виде текста в файлах .log?
Причем тут .json?
Или я что то упускаю? Для чего вся эта работа с json?
PowerShell 5.1 - имеет из коробки ConvertFrom-Json. Да менее функциональный, но....
$Files = Get-ChildItem -Path $LogPath | Select-Object FullName
А для чего сия манипуляция?
Почему не Get-ChildItem -Path $LogPath | ForEach-Object ?
Да, действительно имеет. Похоже я немного перепутал причино-следственные связи.
В ps7 мне не удалось загрузить System.Web.Script.Serialization.JavaScriptSerializer, по этому использовал стандартный командлет. Но во время написания стать мне почему то вспомнилось наоборот - что в ps5 не смог найти ConvertFrom-Json.
Почему не Get-ChildItem -Path $LogPath | ForEach-Object ?
Не люблю такие конструкции. Их не удобно дебажить.
Инверсия зависимости. Такой цикл проще обернуть например в функцию или метод, ведь в качестве параметра он принимает только абстрактный список.
ИМХО такой код более читабельный.
Я понимаю что в рамках 40 строк скрипта это все притянуто за уши. Но в скриптах по 900 и более строк ООП+SOLID заметно упрощают жизнь. Описал класс, реализовал методы, в экземпляре получил что то абстрактное, передал в другой класс. Кода классов на 890 строк, алгоритма работы скрипта на 10. ))
SOLID - это хорошая привычка, даже без ООП.
900 строк в скрипте? А точно тогда надо брать скриптовый язык? У нас нет другого выбора?
Я имел ввиду: "Зачем получать массив объектов типа Файл, а дальше преобразовывать его в массив объектов с одним полем в виде строки, если сразу можно передать сие чудо в конвейер?".
Ааа... Оу.. Да, конечно, совершенно не за чем ))) Кажется я хотел получить просто массив строк, но зачем то сделал массив объектов с одним полем. ))
Конечно есть, а зачем? Скрипт нативный для всех систем, соответственно его можно запускать из шары (не нужен деплой на все сервера). Скрипт не нуждается в дополнительных библиотеках для совей работы, т.к. использует Import-PSSession или -Command или вообще Invoke-Command. Скрипт написан так, что ему все равно на версию ps. Скрипт хорошо структурирован и комментирован. В случае необходимости исправления могут вноситься фактически на лету из любого места с помощью блокнота.
А теперь смотри, мы берем какой нить c# и пишем там один единственный метод
using System.Net.NetworkInformation;
public static bool PingHost(string nameOrAddress)
{
bool pingable = false;
Ping pinger = null;
try
{
pinger = new Ping();
PingReply reply = pinger.Send(nameOrAddress);
pingable = reply.Status == IPStatus.Success;
}
catch (PingException)
{
// Discard PingExceptions and return false;
}
finally
{
if (pinger != null)
{
pinger.Dispose();
}
}
return pingable;
}Компилируем, берем екзешник кладем в шару.
Запускаем и "The application to execute does not exist: '\\share\share\ConsoleApp14.dll'"
Ага, ок, забыли библиотеку, сами виноваты.
Перенесли, запускаем второй раз и "A fatal error occurred. The required library hostfxr.dll could not be found." А это чо такое, я же ни чего такого не использовал? А это не тот фреймфорк. И это даже без использования каких то иных библиотек.
Прекрасно когда есть возможность держать все сервера в одинаковом и актуальном состоянии, но в реальной жизни к сожалению это не всегда возможно ))
Резюмирую все вышесказанное. Скриптом проще ))) А т.к. инструмент выбирается соответственно задачи, то и нет смысла от него отказываться. ))
Хотел ведь написать, что брать скрипт из 900 строк так же малооправдано как для копирования файлов разворачивать SAP.
Для наглядности. Есть скрипт который висит на обработчике события создания пользователя в AD
Вот что он делает:
Вычитка самого события из журнала винды.
Установка необходимых для работы, сторонних систем, атрибутов пользователю АД.
Вычитка данных о почтовых серверах из AD.
Определение первого доступного почтового сервера.
Создание почтового ящика на удаленном сервере.
Определение наименее загруженного файлового сервера, на основании объемов и количества уже существующих монтировок.
Создание VHD диска на определенном сервере.
Монтирование этого диска на удаленном сервере, выдача прав на этот диск.
Назначение FSRM квоты на этот диск.
Внесение изменений в JSON файл на этом сервере для другого скрипта автоматической монтировки.
Присвоение этого диска в качестве хома пользователю AD.
Создание служебной папки папки на удаленном сервере, назначение прав.
Создание пользователя в корпоративном месенджере.
Формирование и отправка двух приветственных письма, с HTML раскраской, картинками, вложенными фалами.
Формирование и отправка лог работы скрипта админам.
Все это оформлено классами, украшено обработчиками разнообразных ошибок, логированием и т.д.
Вас долго пытали, что бы вы отказались от C#/Python/Etc? :)
Кажется мы скоро свалимся в холивар PS vs etc. ))))
На самом деле, нативность и доступность с лихвой перекрывает возможные неудобства.
А дабы вас порадовать скажу что я реализовывал веб сервер с REST на PS. Писал GUI формы в винде на нем же. И даже писал некий аналог DHCP сервера, на основе группы, для дальнейшей интеграции в cisco. Получился не плохой аналог куска cisco ise ?
Притча о семи с половиной языках