We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

Why develop a CLI (Command Line Interface) first?

00:00

Formal Metadata

Title
Why develop a CLI (Command Line Interface) first?
Title of Series
Number of Parts
132
Author
License
CC Attribution - NonCommercial - ShareAlike 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this
Identifiers
Publisher
Release Date
Language

Content Metadata

Subject Area
Genre
Abstract
One of the core concepts of Application Development, (not just in python), is the separation between the Business Logic and the User Interface. However there is a strong temptation to start with the user interface and add the business logic to it some methodologies emphasize this with the process of prototyping the (G)UI first. The danger is that your business logic code can get too entangled with the UI and a change of platform or framework becomes almost impossible. This presentation will show how to maintain a clear separation between the Business Logic and the User Interface by starting with a command line interface using argparse and growing a GUI on top. We will cover: - Why maintain the seperation - Using argparse - Adding a GUI layer with wxPython - Automating the GUI generation - Adding a web interface - Testing advantages of this approach - Scripting advantages - Some packaging models.
35
74
Thumbnail
11:59
Presentation of a groupUser interfaceGraphic designCodeMultiplication signMereologyQuicksortGraphical user interfaceMachine codeSoftware developerExpert system
Flow separationCodeGraphical user interfaceLogicSoftware maintenanceType theoryCommon Language InfrastructureEuler anglesElement (mathematics)PrototypeTime domainKeyboard shortcutStandard deviationLibrary (computing)MereologyCodeComputer fileGraphical user interfaceInformationFlagMachine codeParsingUtility softwareProcess (computing)BitParsingParameter (computer programming)MultiplicationAxiom of choiceDebuggerMappingDrop (liquid)Multiplication signSurjective functionIntegrated development environmentDrag (physics)Message passingEndliche ModelltheorieGUI widgetDefault (computer science)Expert systemReverse engineeringDegree (graph theory)Data storage deviceOnline helpDigital photographyMedical imagingAreaLogicModule (mathematics)Flow separationElectric generatorRevision controlLibrary (computing)MereologyGraphic designLine (geometry)CASE <Informatik>Software developerClique problemFront and back endsArc (geometry)Casting (performing arts)Computer programmingUser interfaceFlow separationoutputRight angleCuboid
CodeGraphical user interfaceVirtual realityStandard deviationComputer fileLine (geometry)Process (computing)Revision controlDifferent (Kate Ryan album)Multiplication signWeb browserFunction (mathematics)GUI widgetDemo (music)ParsingComputing platformInstallation artBitType theoryField (computer science)Social classComputer animation
Computer fileGraphical user interfaceComputer animation
Ewe languageUser interfaceQuicksortElectronic mailing listSet (mathematics)Parameter (computer programming)Line (geometry)Web pageData dictionaryMessage passingGraphical user interfaceString (computer science)Electric generatorGraph (mathematics)Computer animation
Drop (liquid)CodeGraphical user interfaceParameter (computer programming)Drag (physics)Slide ruleAreaComputer fileComputer animation
Keyboard shortcutMereologyStandard deviationLibrary (computing)User interfaceCommon Language InfrastructureLogicSoftware testingScripting languageEndliche ModelltheorieLibrary (computing)Standard deviationWeb 2.0Goodness of fitGraphical user interfaceParameter (computer programming)Java appletMathematicsVideo gameData dictionaryUser interfaceCuboidElectronic mailing listCodeElectric generatorType theoryOpen sourceDisk read-and-write headDirection (geometry)Module (mathematics)Computer-generated imageryScripting languageAuthorizationBitContext awarenessFront and back endsFlow separationConnectivity (graph theory)Different (Kate Ryan album)LoginOrder (biology)Multiplication signBlock (periodic table)Computer programmingWrapper (data mining)Software frameworkQuicksortMoving averageSet (mathematics)Computer fileEvent horizonField (computer science)Slide ruleMobile appMessage passingTotal S.A.Software testingParsingGroup actionAxiom of choiceUniform resource locatorServer (computing)Mapping
Multiplication signComputer animation
Transcript: English(auto-generated)
So Steve will now speak about why to develop a CIF first. So have fun. Hi there. I'm an engineer that works for BHGE, what used to be GE Oil and Gas, and used
Parthen quite a lot in my work. And this is why I think that it's a very good idea to actually produce a command line interface, even if you go over something that's eventually going to have a GUI interface or a web interface. So let's see how we go. OK. There's lots of things to think about before you actually
start doing a GUI. What controls are you going to be putting on there, what you need it to do, the functional things, which actually comes down to your code. After all, the really important part, unless you're a graphics designer, which I know there's a few here, is
what does the code do? Does it work? Putting a GUI on can take a lot of time. And if you're not a graphics designer, it tends to produce a mess. For many of us, struggle with that sort of thing. Great on the coding, but getting it looking nice and working, two different challenges.
Personally, I think putting a GUI on at the beginning can leave you trapped in things that you don't actually need, and spending a lot of time on the GUI development before you've done any coding. A lot of the experts always say
that separating your code into a front end and a back end, a business engine, or a GUI are a good practice. Putting a command line interface in first tends to be a nice, slender thing and gives you a degree of that separation.
Obviously, some things are pretty much hopeless without a GUI. A drawing package, graphics editing packages, you're going to have to put that in.
But a lot of the modules within those might well be suitable for having a command line interface anyway and should be developed separately. And you can find that if you put a command line interface in for your development, you end up with useful separate utilities as part of your package. One of the obvious areas that you're
going to definitely want a GUI, photo editing, photo manipulation. But ImageMagick is one of the most widely used image manipulation programs, and it's all on the command line. Any GUIs you get is bolt on.
Yeah? So think twice before you start with the GUI. Now, what's really nice, if you put a command line interface in, there are a couple of tools that will let you automatically create at least a first draft of your GUI. If you've developed your code to work on the command line,
tested it working on the command line, you know the code's working. You've maybe got to the useful utilities. If you can then bolt on a GUI rapidly, that might be the end of the job.
Or turn it over to the graphics designer. Yeah? Now, having done your code with the command line, you'll have decided things like, right, that needs to be a flag. Or that needs to be a file. You've decided what you actually need.
Once you've decided what you need, that tells you what you want in your GUI. Flags are going to be options, tick boxes, or toggle menus. A file is going to be the drag or drop or a file selector. Multiple files, same thing.
If you've got things that are exclusive choices, they're going to end up being radio buttons. But until you start coding, you're not going to find out. Unless you've got a really good spec. And frankly, that doesn't happen very often.
You've got a couple of choices. You can either make your own mapping from your command line options to a GUI. Or there's a couple of choices, GUI and QUIC. Which of those you use depends on a couple of issues.
If you've developed your command line using arg pass, then it's in the standard library. You can use GUI. And that will create you a WX widgets, WX Python GUI
interface. There's actually a couple of choices within the GUI library of how you go about it. But they're incredibly useful. If you've used QUIC for your command line, I know it's very popular. So that generates your GUI for you using QUIC.
Or gives you the option of doing it with QUIC. That will give you a QT5 GUI. A personality clearer QT rather than WX. Because there's licensing issues that my employer doesn't like with QT. WX is a much simpler licensing model.
But may vary between you. Personally, I also like using the arg pass method. Because basically, it comes down to something that's stored in a dictionary. And it's a lot easier to manipulate the dictionary if you can decide to roll your own GUI generation than it
is if you've got to parse helps and docstrings, which is what QT does for you. What QUIC does for you. I'm going to be concentrating on the WX widgets based
and arg pass. Apologies to anyone that loves QUIC. I think it clicks great. But in this case, we're going to skip it. So lots of examples in how to use arg pass. How many people have used it in the past? The vast majority.
How many haven't? Not many. So we don't need to go too much into what arg pass gives you. But a quick couple of examples. So in this case, we're creating in our parse arguments
a parser to do our parsing for us, adding a bit of information into it, adding a couple of arguments that we want, one or more input files. I know the text is a little bit small on there. And I'm not sure if I can zoom on this.
Let's try. I don't have the option, I'm afraid. I will be posting the actual code up onto GitHub. Let's try it.
Control. New feature in this IDE since this last time I tried that. So we've got a parser being created, given some information to store for the helps.
And we've added a couple, three arguments, one logic flag, reverse. It's fairly meaningless little example. And obviously, if we go to the command line,
we can just run that with, give it no information. It gives us our base message.
We ask for help. It tells us what our options are. And in this particular case, if we just give it a file name,
then it tells us what the options have been selected, which have been the defaults. We decide to go across to the simplest GUI version. We need to add two whole lines to our code,
an import of GUI and a decorator. The only difference between the two files. Now when we run it, we should get a GUI.
Not bad for two lines, is it?
OK, it's rough and crude. But it does more or less the job we need. One of the things I don't particularly like about this is that your files is a type-in or paste-in field. But luckily, argpass does give us a way around this.
Yep, WX Python is available and pip installable on most platforms and is Python 3 compatible now since version 4, which is a big step forward,
as is the pip install before it was in the XE to install, which was a little bit more troublesome. And you couldn't use it in virtual environments very easily. They made great strides on that. So if we go to our third example,
we've got exactly the same code again. This time, we're using GUI parser instead of our standard parser, yeah? And we've added to our infile option
an override of widget equals file chooser, yeah? So not a huge difference. This time, when I run it, we get a slightly different GUI.
We've got a Browse button. And we can pick our file or files.
And when we run it, it does everything nicely for us. And see there, we've got details of the file that's been opened as an IO stream, yeah?
So generating a GUI from command line, once you've got the command line, is easy, yeah? It's not the prettiest GUI. It's a good starting point, though. Just for a little example of rolling your own,
I pointed out that one of the things that distinguished click and arg pass is that arg pass isn't parsing your doc strings. It's generating. You're actually supplying a set of add arguments, yeah?
And those add arguments, when you look at it, could pretty much be a dictionary, a dictionary entry, yeah? Because you've got, for a particular line, a list of names to put it in, and then
a set of parameters which are named parameters. Sounds like a dictionary to me, yeah? So of course, when we come to rolling our own, we can use the same sort of trick.
In here, I've got a list of dictionaries,
one for the command line arguments, and one a base set of arguments,
a set of optional arguments, command line arguments or command line only arguments, and graph GUI only arguments. This is an example of rolling your own, yeah?
And basically, I'm parsing those and using those to generate a WX interface myself. And just to give you a flavor of what that looks like,
now this one, I've actually got a little bit sneaky. And it runs from the command line with no arguments. It will start the GUI, and I've got a drag and drop area
rather than a file chooser. But you can also use it from the command line with exactly the same code. If it got command line arguments, it processes them and runs. Doesn't start the GUI. So we've got the best of both worlds.
Quickly run through the rest of the slides. We've got options of running, installing it. Think about it, you've got the command line interface, a CGI web interface is going to take pretty much the same parameters.
A microservices interface is going to take the same parameters and pass them between. And if you're pipelining things, then you can do that again. It's all the command line. You can automate your tests,
make sure you've got your business logic. You haven't got to pay someone to click on things or spend a lot of time mocking things up or automating GUI clicks. You can just test your GUI separately. And if you happen to have to do a GUI in Arabic
or Chinese or something like that, the reasonable chance you won't even understand what the labels on the buttons are yourself. Get your backend right, and you're a long way there. Once we've done that, you can package it up into an EXE.
Plenty of ways of doing that. If you're on Windows or into an app for Mac, I'm afraid I don't do much Mac, so generating apps is a little bit outside my field. Or as I said, put it inside a container or on a web server, you've got all the options available.
And once I actually managed to get the code uploaded into GitHub, that'll be the URL that the code and the slides will be available at. Any questions?
Thank you. For the GUI arguments, you have to create two separate sets. There's a way of doing that. We only need to create one set of arguments that is useful for all sites. It depends on what you're doing.
For the GUI, I wanted to have the option of preserving which tick boxes were selected. And I didn't particularly, didn't want that option available for the command line. So just separating them out into two separate lists made life a little bit easier. And I could, in my dictionary of entries for all of them,
I had the option of putting extra parameters in that ArgPass wouldn't take that the GUI needed, and just filtering them if I was building the command line makes life very easy. Be nice to actually get a slight change to ArgPass
to give it an option for ignore any parameters you don't understand in this context. But then again, moaning about anything it doesn't understand is probably a good idea most of the time.
If so, that's great. That'd be good. Anyone else? Have you ever created results with choices? Because my company is just switching from ArgPass to SMED
because you can use non-modules, but you can first select a module that you want to have in the script. Mm-hmm, yeah. I've not used that particular approach, but again, if you've got a command line framework
that you can access the module, which either click or ArgPass can give you, then the magic of the ifdef main is very useful. I've had a lot of bits of larger programs that have actually turned out to be more useful
and more popular than the whole program, or certainly more used. But because I'd put a wrapper around them to be able to test them as a standalone, hey, we can use that, need it. So I've not tried that particular package and used it.
Anyone else? Yeah? In general, it tends to, the automatic generation tools tend to just go
on the order of the arguments and do their own thing. Obviously, with the roll your own example, I got to choose and say, right, these are all going to be in a block or a group, and then you can do it.
And it's actually not, I was pleasantly surprised how easy it was to generate your own automatically-generatable GUI rather than generating a GUI separately. It's pretty much a one-to-one. Yeah, almost every,
and of course you could take the same approach for rolling your own. If you want to use a different GUI library altogether, one that's not supported, then that's fine. You just work out your mappings, say, right, from my list of arguments, these are the options I need to produce, and the types of the options,
and just about every GUI library that I've come across gives you a way of selecting files or file paths. It gives you a way of selecting on-off options, a way of making choices, a way of triggering events. Not a lot else to do.
Any more? Is it possible to get the code that generates the GUI so that you can do minor customizations? Yeah, it's all open-source code. Library generates the GUI for you, but in the background it generates some code for that GUI to render. Is it possible to get that code? You could adjust the library.
The current libraries that don't, as far as I know, actually generate a GUI code as such. I think there's actually a couple of other libraries that do the same sort of thing but generate Java GUIs for you, for the web interfaces, and those you could probably tweak afterwards.
I'd discourage that, personally, because it's much better to change the way that the generation generates it so it will always generate it right. So when you make a change, you've got your change in your new GUI.
If you've got a customization step in between, then you're gonna be on holiday one day when a really urgent change needs making, and the customization step's not gonna happen. Yeah? And then, hey, that code that he's got, it's a total mess, yeah? Also, when the libraries are updated,
you always need to read how you're doing it, yeah. And because these are open source libraries, if you come up with a good way of, and if it's something that's a real improvement, you usually find the author will be willing to take it on and incorporate it in the library, or you can fork the library
and head your own direction. The joy of open source. Okay, last one. It is, you can use redirect to standard out
to a standard out window. Yeah, you can do, yeah. You can capture your standard out and redirect it, and where that redirection occurs to, you've normally got a choice about.
So you could have a component within your GUI to capture the standard out. The only problem is, of course, if your GUI fails to be built, you're not gonna be able to see your log. Okay, right, my time is just about up, I think. Yeah, it's about up. Okay, thank you, Steve.
Thank you. Thank you.