Eu sou um DBA iniciante com muita experiência em programação.
Desenvolvi vários aplicativos CLI, não interativos, que resolvem algumas tarefas diárias repetitivas ou eliminam o erro humano de tarefas mais complexas, embora não tão diárias. Essas ferramentas agora fazem parte da nossa caixa de ferramentas.
Acho que os aplicativos CLI são ótimos porque você pode incluí-los em um fluxo de trabalho automatizado.
Também a filosofia Unix de fazer uma única coisa, mas fazê-lo bem, e deixar a saída de um processo ser a entrada de outra, é uma ótima maneira de construir um conjunto de ferramentas que se consolidaria em uma vantagem estratégica.
Meu chefe comentou recentemente que o desenvolvimento de ferramentas CLI é "retrógrado" ou constitui uma "regressão".
Eu disse a ele que discordei, porque a maioria das ferramentas do CLI que existem agora não são herdadas, mas projetos ao vivo com versões aprimoradas sendo lançadas o tempo todo.
Esse tipo de desenvolvimento é considerado "de trás para frente" no mercado?
Parece ruim em um rèsumè?
Eu também considerei todas as soluções se são web ou desktop, devem ter opções de linha de comando, não interativas. Algumas pessoas consideram isso um desperdício de recursos de programação.
Este objetivo é digno de um projeto de software?
Também acho que, para um aplicativo da Web ou de área de trabalho, ter uma interface CLI alternativa é uma ótima maneira de demonstrar que a lógica de negócios é completamente dissociada da GUI.
Ter a capacidade de trabalhar com um CLI não é o que eu consideraria de trás para frente. Parece ótimo em um currículo, especialmente se você pode girar em seu currículo com uma frase como "Usado (Powershell / Bash) para construir um conjunto de ferramentas de automação para enviar mensagens SMS quando o banco de dados estava inoperante".
Quando sou responsável por contratar pessoas, um conhecimento prático do CLI é algo que eu procuro.
Basicamente, trata-se de "usar a ferramenta certa para o trabalho".
Se você tiver que interagir com um usuário, você precisará de algum tipo de GUI. Temos décadas de pesquisa e experiência mostrando que elas tornam a computação muito mais intuitiva e produtiva. É por isso que as GUIs têm inexoravelmente dominado o mundo desde 1984: elas funcionam melhor para interagir com as pessoas.
Mas se você está automatizando um programa com scripts, seu programa não está interagindo com as pessoas; está interagindo com um script. E a melhor interface para isso é baseada em texto, por razões que devem ser intuitivamente óbvias.
O desenvolvimento de programas CLI para os usuários trabalharem diretamente é considerado atrasado e com boas razões. Mas se não é isso o que você está fazendo, se você está escrevendo ferramentas de produtividade de automação, então você não está fazendo nada errado dando-lhes uma CLI.
A Arte da Programação Unix de Eric Raymond é o trabalho canônico para o argumento que você está fazendo. Não vou tentar condensar seu excelente livro em alguns parágrafos. No entanto, tenha em mente que o argumento se aplica principalmente a programadores, administradores que automatizam tarefas usando scripts ou usuários avançados de softwares altamente técnicos como o CAD.
Mesmo com usuários altamente técnicos, você precisa considerar quais chapéus estão usando no momento. Por exemplo, eu escrevo software embutido para equipamentos de rede para ganhar a vida. Todos os nossos produtos têm uma CLI e uma GUI, mas os desenvolvedores quase preferem universalmente o CLI, devido à sua flexibilidade, capacidade de leitura, disponibilidade, velocidade, etc.
No entanto, exatamente o mesmo grupo de desenvolvedores prefere a GUI em nosso software de controle de versão, embora sua CLI seja mais poderosa e seja suportada e documentada tão bem quanto a GUI. A diferença é que somos os usuários finais do software de controle de versão, não administradores ou desenvolvedores.
Portanto, considere cuidadosamente quais funções seus usuários estão usando seus utilitários e planeje a interface do usuário de acordo. Se o seu chefe está mencionando isso, é provável que você precise melhorar a documentação e / ou treinamento no CLI, no mínimo. Se você está constantemente dizendo às pessoas que um recurso só está disponível na CLI quando eles o esperam para a GUI, você provavelmente precisará repensar suas prioridades de desenvolvimento, levando em conta as necessidades de seus usuários.
Não é apenas o Unix que é impulsionado por programas de linha de comando. A Microsoft também está indo nessa direção.
A Microsoft vem pressionando o PowerShell há algum tempo. Todos os softwares de servidor atuais (Exchange, SharePoint, Server 2012, System Center, etc.) podem ser completamente controlados por meio da linha de comando do PowerShell. E o PowerShell confia em pequenas funções que fazem uma coisa bem e canalizam dados para a próxima (embora canalize objetos em vez de apenas texto).
A maioria das GUIs desses programas é simplesmente uma interface para os comandos do PowerShell, muitos até informam quais comandos serão executados para facilitar a criação de scripts. Tudo o que você pode fazer da GUI que você pode fazer no PowerShell. O contrário não é verdadeiro - existem algumas funções expostas apenas no PowerShell.
Então, se * nix sempre fez isso, e a Microsoft está indo nessa direção ... não parece muito para trás para mim!
Eu definitivamente não diria que é uma coisa ruim. O bom dos programas CLI é que, ao implementá-los, você pode ter um escopo muito restrito. Por exemplo, se eu quiser escrever um clone cat ou "um programa para imprimir o conteúdo de um arquivo na tela", isso é muito viável com o CLI.
No entanto, e se você não usar o CLI, bem, então você teria um programa básico com uma GUI que mostrasse algum texto. Mas então você também tem que amarrar na abertura de um diálogo de arquivo e ligar isso ... mas então alguém também quer ser capaz de modificar o texto e salvá-lo em outro lugar ..
Scope creep é ridículo com aplicativos GUI. É extremamente fácil evitar o uso de aplicativos CLI. "Você quer editar o arquivo e salvá-lo novamente? cat foo > ed > bar " Com os aplicativos CLI é trivial para os usuários (não você, o desenvolvedor) combiná-lo com outras ferramentas.
Agora, dito isto, os programas CLI estão começando a ser vistos como "de trás para frente". Isso ocorre porque muito desenvolvimento de aplicativos nos dias de hoje acontece em mercados onde usuários combinando sua ferramenta com outras ferramentas é quase impossível. Eu não vou entrar nisso aqui, mas eu escrevi um postagem no blog sobre como "os marketplaces impõem a mentalidade de mestre-de-nada", que é o oposto completo de um aplicativo CLI bem projetado (fazer uma coisa e fazer isso bem)
A GUI e o CLI têm seu lugar. A GUI é ótima para permitir que um usuário execute determinadas operações prontas rapidamente. O CLI é para quando você quer fazer coisas que o GUI não permite que você faça. A CLI é geralmente mais poderosa e mais difícil de usar.
A boa ferramenta CLI permite que o usuário faça coisas em que a pessoa que escreveu a ferramenta nunca pensou. Um exemplo é o comando 'find' do UNIX. Este comando:
find . -type f -name xyzzy\* -maxdepth 5 -mtime +3 -exec rm {} \;
localiza os arquivos no diretório atual (mas limitados a 5 níveis abaixo) que têm um nome iniciando 'xyzzy' e foram modificados há mais de 3 dias e, em seguida, os excluem (nota: código não testado). E isso é um uso moderadamente simples. Você pode usar um gerenciador de arquivos para fazer esse tipo de coisa, mas levará mais tempo e estará propenso a erros. Claro, ser mais poderoso significa que o CLI pode ser mais facilmente mal utilizado e criar problemas para você mesmo!
Um bom desenvolvedor pode escrever uma ferramenta CLI de forma que também tenha uma GUI que permita a execução de um conjunto limitado de operações. O usuário pode começar com a GUI e aprender as complexidades da CLI depois.
Uma boa leitura (longa e tendenciosa (?)) na troca de CLI / GUI é em:
http://www.cryptonomicon.com/beginning.html
Não, não é de todo para trás.
A "direção" tem muito a ver com nossa perspectiva. Um usuário satisfeito com o caminho atual para interfaces simples, "uma experiência de todos os dispositivos", verá a CLI como um retrocesso ou uma regressão, com certeza. Não está de acordo com suas expectativas gerais.
Um programador, administrador ou usuário avançado pode vê-lo como a progressão lógica das ferramentas de acordo com sua experiência. Muitos deles começam usando ferramentas GUI. Quando eles querem ou precisam escalar, eles rapidamente descobrem porque a CLI existe e que a progressão ressoa com aqueles que estão construindo mais ferramentas CLI.
Existe isto por Paul Ferris: link
Para mim, pessoalmente, a ideia de sintaxe diferencia os dois. Quando a sintaxe está um pouco presente em uma GUI, o resultado quase nunca é bom e tão flexível quanto a sintaxe CLI bem pensada. Quando isso é acoplado a pipes e redirecionamento, a GUI fica inativa porque não é muito útil fora dos casos de uso planejados.
Minha preferência pessoal sobre isso é ferramentas CLI que oferecem uma opção --gui ou --verbose suficiente para permitir que um wrapper GUI interaja de uma forma robusta, incluindo barras de status e outros elementos básicos que as pessoas procuram na GUI.
É claro que o custo disso é essencialmente dois programas com um bastante inútil sem o outro, mas o maior benefício é poder incorporar uma ou mais ferramentas CLI em uma GUI personalizada sem modificação das referidas ferramentas CLI. Na maioria das vezes isso é feito apenas para oferecer uma opção GUI em uma determinada CLI, mas a ideia de conduzir várias ferramentas com uma GUI orientada a "processo" ou "caso de uso" pode fornecer resultados semelhantes ao encadeamento, redirecionamento e criação de scripts para esse caso de uso. disponibilizá-lo para pessoas que não realizariam essas operações com regularidade suficiente para atingir o domínio e, ao mesmo tempo, não inibir os usuários do CLI.
Eu encontrei essa abordagem no SGI IRIX e gostei muito dela. Eu encontrei-me usando a interface gráfica ou a linha de comando, conforme necessário, e o bom era saber exatamente o que os botões de fantasia estavam realmente fazendo.
Onde há muitos ambientes operacionais diferentes, os wrappers GUI podem diferir consideravelmente sem afetar a ferramenta CLI também.
Eu vejo isso no Linux hoje, com coisas como ferramentas de disco / sistema de arquivos, onde a GUI pode agregar muito valor até mesmo aos usuários familiares do CLI.
No caso de sistemas de arquivos / discos / dispositivos conhecidos, eliminar o CLI não é difícil, e pode ser roteirizado, é claro. Erros podem ser dolorosos no entanto.
Quando não são conhecidas, ou talvez a execução das operações não seja feita regularmente o suficiente para permanecer sólida e livre de erros, a execução da GUI fornece um ambiente que pode ser facilmente verificado, operações encadeadas e executadas com confiança. scripts necessários.