Притча о семи с половиной языках

Кажется мы скоро свалимся в холивар PS vs etc. ))))

На самом деле, нативность и доступность с лихвой перекрывает возможные неудобства.

А дабы вас порадовать скажу что я реализовывал веб сервер с REST на PS. Писал GUI формы в винде на нем же. И даже писал некий аналог DHCP сервера, на основе группы, для дальнейшей интеграции в cisco. Получился не плохой аналог куска cisco ise ?

Притча о семи с половиной языках

Для наглядности. Есть скрипт который висит на обработчике события создания пользователя в AD

Вот что он делает:

• Вычитка самого события из журнала винды.

• Установка необходимых для работы, сторонних систем, атрибутов пользователю АД.

• Вычитка данных о почтовых серверах из AD.

• Определение первого доступного почтового сервера.

• Создание почтового ящика на удаленном сервере.

• Определение наименее загруженного файлового сервера, на основании объемов и количества уже существующих монтировок.

• Создание VHD диска на определенном сервере.

• Монтирование этого диска на удаленном сервере, выдача прав на этот диск.

• Назначение FSRM квоты на этот диск.

• Внесение изменений в JSON файл на этом сервере для другого скрипта автоматической монтировки.

• Присвоение этого диска в качестве хома пользователю AD.

• Создание служебной папки папки на удаленном сервере, назначение прав.

• Создание пользователя в корпоративном месенджере.

• Формирование и отправка двух приветственных письма, с HTML раскраской, картинками, вложенными фалами.

• Формирование и отправка лог работы скрипта админам.

  Все это оформлено классами, украшено обработчиками разнообразных ошибок, логированием и т.д.

  
  

Притча о семи с половиной языках

3. Ааа... Оу.. Да, конечно, совершенно не за чем ))) Кажется я хотел получить просто массив строк, но зачем то сделал массив объектов с одним полем. ))

2. Конечно есть, а зачем? Скрипт нативный для всех систем, соответственно его можно запускать из шары (не нужен деплой на все сервера). Скрипт не нуждается в дополнительных библиотеках для совей работы, т.к. использует 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." А это чо такое, я же ни чего такого не использовал? А это не тот фреймфорк. И это даже без использования каких то иных библиотек.

Прекрасно когда есть возможность держать все сервера в одинаковом и актуальном состоянии, но в реальной жизни к сожалению это не всегда возможно ))

Резюмирую все вышесказанное. Скриптом проще ))) А т.к. инструмент выбирается соответственно задачи, то и нет смысла от него отказываться. ))

Притча о семи с половиной языках

Да, действительно имеет. Похоже я немного перепутал причино-следственные связи.

В ps7 мне не удалось загрузить System.Web.Script.Serialization.JavaScriptSerializer, по этому использовал стандартный командлет. Но во время написания стать мне почему то вспомнилось наоборот - что в ps5 не смог найти  ConvertFrom-Json.

Почему не Get-ChildItem -Path $LogPath | ForEach-Object ?

1. Не люблю такие конструкции. Их не удобно дебажить.

2. Инверсия зависимости. Такой цикл проще обернуть например в функцию или метод, ведь в качестве параметра он принимает только абстрактный список.

3. ИМХО такой код более читабельный.

Я понимаю что в рамках 40 строк скрипта это все притянуто за уши. Но в скриптах по 900 и более строк ООП+SOLID заметно упрощают жизнь. Описал класс, реализовал методы, в экземпляре получил что то абстрактное, передал в другой класс. Кода классов на 890 строк, алгоритма работы скрипта на 10. ))

Притча о семи с половиной языках

Спасибо, в следующий раз я буду иметь это ввиду.

Но прошу учесть что на java я писал вообще первый раз и в таких тонкостях ещё не разбираюсь.

Притча о семи с половиной языках

Про руби это просто отступление. Результаты не участвовали в общем забеге. Мне просто было интересно как это работает именно в руби.

К тому же у нас же не стояла задача использовать многопоточность или как то ещё оптимизировть работу. Мы использовали максимально простой и прямолинейный подход. Можете считать что это Just for fun ))

Притча о семи с половиной языках

Наверное да, но чисто субъективно мней как то роднее 4.8. Но на коре наверное тоже есть смысл попробовать написать.

Притча о семи с половиной языках

Спасибо )) И желаю терпения Вам ))

Притча о семи с половиной языках

Честно говоря я не в курсе. На сколько я понимаю коллега либо сам написал экспортер в json, либо использовал какие то стандартные средства для этого. Может быть раньше у него был другой механизм обработки. Но суть в том что входные данные у меня были именно такими.