Posts
49
Comments
149
Trackbacks
0
Making a Case For The Command Line

This blog post has moved:

http://gruffcode.com/2013/06/30/making-a-case-for-the-command-line/

posted on Sunday, June 30, 2013 4:03 PM Print
Comments
Gravatar
# re: Making a Case For The Command Line
Vladimir Kocjancic
7/1/2013 1:38 PM
Why don't you create WCF service for administration on server and deploy client that connects with it to development team?
--------------
http://www.lotushints.com
Gravatar
# re: Making a Case For The Command Line
RobG
7/2/2013 4:45 AM
Funny, I have a different outlook. I prefer to build all my services as libraries. I frequently have small console app's to test these, but I can also have test suites, server processes and GUI app's all utilise the same library.

I believe most software should be constructed this way. That way if you want to support a new UI/service model, the core component should be available for reuse.
Gravatar
# re: Making a Case For The Command Line
AD
7/2/2013 6:12 AM
So instead of using an existing tool (like SSH) for piping commands one way and their results back the way, you've written a web page to do it?

A better alternative might be to provide a page with some sort of bootstrapper link which fires up a pre-authenticated SSH session. I bet such a tool already exists.
Gravatar
# re: Making a Case For The Command Line
Jeff Williams
7/2/2013 8:01 AM
I would agree with RobG. Make your service as a library. Then wrap that in a command line client to test or make a functional command line interface. Then you can wrap it in a UI or web based frontend, knowing that the core functionality will work and is reusable.
Gravatar
# re: Making a Case For The Command Line
Jesse
7/2/2013 9:32 AM
@Vladimir: You could certainly create a WCF service to host and run the code needed for these internal tools, but I think that's still more overhead and work than a simple command-line based approach. Also, letting users execute the text commands from within a web application that they already are very familiar with is convenient.
Gravatar
# re: Making a Case For The Command Line
Jesse
7/2/2013 9:37 AM
@RobG and Jeff: You have a good point that I think shows an aspect of this approach that I didn't call out very well in the post. What I'm advocating really isn't all that far off from what you guys are saying.
There's no reason that the code needed to actually perform the task that these internal tools needs to perform can't live in a library that is separate from the web application. In fact, that's exactly how I plan on building this. The library could be referenced by the web application, and expose a single point through which you submit the commands to be parsed and executed. You could end up putting any kind of UI over the top of that separate library. To start out, I'm just using a simple page in a web application because it's convenient and all of the plumbing that I need is already there.
Gravatar
# re: Making a Case For The Command Line
sakamoto
7/2/2013 10:10 AM
I have been working on a similar approach. I did write my own command line parser/dispatcher server side. I was also able to use the same sub system client side to provide various useful services. Here are a few notes/thoughts:

- I am using webapi/MVC. This allows my Javascript calls to map to the same code that my CLI is using.
- There is an open source web based CLI on GitHub. Needs work but was a great starting point. I was actually able to port my C# dispatching arch to the web and run a CLI from a web page. This CLI can not only send commands back to the server, but can also be used to interact with the local client (local storage, etc.).
- The command line vector is just a Controller so I was easily able to use the same authorization scheme.
- My command 'controllers' and command vector methods are decorated with attributes. This allows a startup scanner to identify and register the functionality with the dispatcher.
- Because of WebApi's self hosting capability, I was able to use the same architecture in my service as well (authentication was a little tricky, IIRC). So I can use the same client to connect to my web server or my windows service. Both servers are using a common user store.

All in all, I am a big believer in having a CLI. Once you have it in place, you will continually find use cases for it. Whether it be utility apps, testing, config...
Gravatar
# re: Making a Case For The Command Line
Dan Sutton
7/2/2013 12:45 PM
I find myself agreeing with RobG's approach of building libraries: it seems to me that writing stuff which runs at the command line and then patching it together is a method of deliberately keeping one's coding style in some way tied to obsolete platforms. I have no doubt that it works... and one hopes that the coffee machine works too, because I can envision needing to go and make coffee while waiting for the resultant programs to run... OK, OK - I'm being facetious... but in reality, what happens if you write command-line oriented stuff is that ultimately, you end up forgetting what any of the commands actually do, and if you write enough of this stuff, it becomes unmaintainable at a certain size.
Gravatar
# re: Making a Case For The Command Line
John Q
7/2/2013 2:23 PM
Great idea, this has worked for me. We just did a CRUD app using C# LINQ with initial prototyping in web pages, then as the database grew in complexity we moved the same code around into utility libraries and a console app evolved. One other benefit of this approach: We always use the utility app to do the bulk changes into the db, and can see the log file (who did what when). Every time we needed to do an operation, we quickly added a new command-line switch to handle it. The code was then readily available if we ever needed to do that again. Sure, lots of switches, but if we forget what "-updatesystemstats:true" means, we still know how to read the code and figure it out.
Gravatar
# re: Making a Case For The Command Line
Pat
7/2/2013 2:55 PM
If you haven't already thought of it, you might want to include a way to upload a sequence of commands from a file. The risk is that as soon as you have that, you may find you also want conditional execution and all the other features of a full scripting language. Implementing those features can become an entire project in and of itself.
Gravatar
# re: Making a Case For The Command Line
j
7/29/2013 10:45 AM
Another alternative that I like to do similar is to write small powershell cmdlets.
You get options / flags / command line handling / doco almost for free (once you learn the PS way).
Then from a PowerShell command prompt, the user types Import-Module yourCmdLet.dll and then:
Update-Customer -customerId 123 -firstname Jesse -lastname Taber

[CmdLet(VerbsData.Update, "Customer"]
public class UpdateCustomerCmd : PsCmdlet
{
[Parameter]
public string CustomerId { get; set; }
[Parameter]
public string FirstName { get; set; }
...

protected override void ProcessRecord()
{
...
}
}

Post Comment

Title *
Name *
Email
Comment *  
Verification
Meta
Tag Cloud