GPT3 allows a simple and accessible API for accessing and using AI in an application. The application I wanted to create was a command line utility to quickly lookup commands and associated command line switches.
The language processing of GPT3 is well suited to process natural language questions and provide results across a wide multitude of obscure commands that would otherwise be difficult to memorize.
Getting Started
The development process starts in the playground of the OpenAI website. The examples section provides a number of examples, my command line bot was a modified version of a translation example.
You provide a number of examples and can then modify the options within GPT3 to increase or reduce randomness and provide alternatives for start/stop sequences. The beauty of GPT3 is that you don’t need to provide a lot of examples for the software to get really good at knowing the types of responses that you want.
With 5-6 samples the application was reliably producing useful results. The OpenAI playground makes it easy to export the API call as either a CURL command or as a short block of Python code.
The resulting Python code uses a library called openai and is otherwise six lines of code, two of those are actually unused. (yes I reported this bug.)
Google Colab
I had never previously written much Python code and Google Colab tool was a great way to get started. It’s essentially an interactive Python editing and debugging tool, and since it’s interactive and in the cloud there isn’t much setup needed.
I copied the exported code and started playing around. If you have a GPT3 API key you can try my initial version here.
In playing interactively, I was more easily able to figure out how to parse the JSON and I realized that including the platform name (Mac, Windows, Linux) helped the bot determine the appropriate platform specific commands and platform specific options and folders. This really improved the quality of results.
OpenAI API and limitations
The current version of the software doesn’t allow fine-tuning of the GPT3 completion API using your own database. For use-cases such as customer service or email completion, the ability to further train GPT3 on specific large data sets would be particularly useful. I do think this is coming as fine tuning was part of GPT2, but it hasn’t yet made its way into GPT3.
The other thing to note about the API is that it does take some practice and exploration. When providing a set of examples, it was difficult to unit-test the examples against known and desirable results. Very subtle changes in the prompts would yield very different results and the software would occasionally get stuck in a loop, feeding off of its own content.
Building the bot
Once I had the basic code working in Google Colab, I was able to get a version running on my computer. I had never programmed in Python and I ended up actually using GPT3 to help “auto-complete” some of my functions. I would do this by going back and forth with the playground with blocks of code. It wasn’t perfect but it felt much more natural and collaborative than the alternative of jumping back and forth between StackOverflow pages.
The core bot used the basic prompt from the playground example and a SQLite database to keep track of requests/responses and act as a local cache. This is likely overkill at this point but I thought it could be interesting if a general database of questions and answers could be compiled, filtered, enhanced and sorted over time. The database also acts as a speed and cost buffer since the GPT3 API is not free and not always the fastest.
Some examples:
$>cbot "How do I count the number of lines in a file?"
wc -l filename.txt
$>cbot "How do I get the mime type of a file?"
file filename.txt
$>cbot "How do I create a file with the text 'hello world'"
echo hello world > hello.txt
$>cbot "How do I open php in interactive mode?"
php -a
$>cbot "How do I set my email using git config?"
git config --global user.email "[email protected]"
$>cbot What is the current date
date
Advanced Tricks
After using the bot for a few weeks I started to add some more advanced functionality.
The -x option allows you execute the command directly. The -c option allows you to copy the answer into the clipboard (a little safer than just executing it.)
$>cbot -x "how do I put my computer to sleep"
Sleeping now...
The -g option allows you to ask general questions.
$>cbot -g "Who was the 23rd president?"
Herbert Hoover
Lastly, you can use cbot to save command shortcuts. So if you’ve remembered an obscure command you can save it for later.
$>cbot -s listall "ls -la"
Saving Shortcut
$>cbot -x listall
Open Source
While this code is open source, the problem is that currently OpenAI isn’t available openly and that API keys are only available to select developers. This makes it currently impossible to publish open-source software that is meant to be used by typical end-users.
I am hopeful that end-user API keys will be made available so that open-source AI software and tools can be made more broadly available.
Chris Moritz said…
*sigh
Jordi S. said…
And about this:
—
“If you can’t get the site to look exactly the way you want on every single browser then how can you claim that CSS is a good design tool or even a success?”
—
Ups, “to look exactly the way you want”? That is not what a web site is for. What about usability and accesibility? Users should be able to change font size; and they may have big or little screens; or … If you want control what users exactly see, give them a paper-sheet.
Greg Raiz said…
The problem is that it’s a an enormous pain with css.
I didn’t touch on accessibility but let’s call it a potential #11. People abuse css by turning lists into hover menus, fixing font-sizes so they don’t scale when the font increases and all sorts of other tricks that are totally not-accessible.
Jordi S. said…
well, I use Dreamweaver and let me tell that it’s not ‘great’ editing CSS. It’s probably better than any other editor, but there’s a lot of things that could be improved (although it’s a hard hard work).Sorry, I don’t exactly know what you mean by ‘high-end site’ (poor English, you see), but let’s take the model-for-ecommerce one: Amazon.
In Amazon users can change font size, the design ‘flows’ depending on screen-size, … Well, if you mean that designers want exactly “an usable design”, then I agree with you 🙂 But Amazon is not controlling design to the pixel (and they are doing right!).
Yes, you’re right: CSS may be wrong used against usability. But… it’s powerful, so it’s dangerous (as nuclear power is).
So I won’t say CSS sucks… No more than some tools suck, or some designers suck. CSS simply is not perfect 🙂
Ross Johnson said…
Every time I read posts such as this there always seems to be more of a “frusteration” than a good understanding and criticizm.
Your proposal to design a tool around the technology is a bit unrealistic. Shall we just convince all browser makers (including the ones that can’t even get CSS right) to just adopt a new technology?
Oh but wait, there is flash – and flash has it’s share of problems as well.
Once you get the hang of CSS it all makes sense and it is not frusterating anymore.
Mike G said…
Montoya said…
As a junior educator contributing to a college course with over 100 students learning CSS based design (as well as PHP programming), I can assure you that CSS is neither hard nor painful; if 100 students can learn it every year, and produce highly flexible, lightweight, and attractive designs with it, then maybe you just need to go back to school (and I say that without intending to offend you).
Greg Raiz said…
I can design something for print production in roughly 1/10th the time it takes to design something for the web using CSS.
The fact that you are blaming me for not understanding is just funny. Your own portfolio proves my point:
html { font-size:100.01%; }
As a designer you shouldn’t have to fight the CSS and the browser to get what you want.
Montoya said…
html { font-size:100.01%; }
wouldn’t be necessary if it wasn’t for IE 6 being so common, but who do you blame that on? The W3C CSS group, or Microsoft? Mind you, it’s a bug in Microsoft’s software. Maybe that will help you shift the blame in the right direction.
You said: “I can design something for print production in roughly 1/10th the time it takes to design something for the web using CSS.” Will your print design scale to the user’s window size? Will it allow the information to be used by multiple user agents (machines as well as humans, including humans who access the web in alternative ways rather than just visually)? Will it offer multiple styles? Will it be easy to modify in the future?
Or are we comparing apples and oranges?
The truth here is you don’t understand the web. You understand print design, and client side software, and even browsers, but that doesn’t give you any knowledge of how the web works. I still challenge you to really learn the medium, the technology, the research and the philosophy behind modern web design practices and why things work the way they do. If you did, you would understand why “problems” like cascading are actually features, and why this new way of looking at websites is a step ahead, not behind. Until then, you are entitled to your opinions, but you have no credibility to back them up.
Anonymous said…
Greg Raiz said…
Counter all 10 of my points if you want. Explain how a markup centric
language is better for design. Explain why consistency is not a problem. Explain why cascading is a good thing. Explain how things like CSS hover menus are a good for accessibility.
Go ahead and convince me. I’ll try to keep an open mind.
Scott said…
rebut your ten points on my own blog (not trying to spam; I felt it would get a bit long in the tooth to do it in your comments section).Mr. Montoya is corrent. You have a limited understanding of the medium. (Oh, and his website kicks ass.)
Greg Raiz said…
I believe CSS limits the creativity of designers by imposing technological constraints on visual designs. This may be because I come from a print background but that doesn’t change the fact that I still feel limited.
While CSS can be incrementally improved I personally think it’s important to think about how to make large improvements rather then incremental ones.
Michelle said…
Anonymous said…
Also, it is very easy to make your website look the same in all browsers.
Brett Mitchell said…
Of course, IE is and always will be the exception. While it is consistantly behind the other major browsers, support is slowly improving.
The point of the internet has evolved to be a source of information and entertainment that is widely available to everyone, everywhere – be it on a cell phone, by a visually impaired person with a braille keyboard, or your average citizen.
The internet isn’t a newspaper. You don’t have absolute control over what your viewers see. You seem to miss the point that the fact your viewers ultimately have control is the benefit of the internet – it’s customizable by individuals to meet their needs. If they need the font size larger, if they need to lower or raise the contrast, or they can’t see and they can have a browser speak to them.
CSS isn’t the be-all and end-all of design – you’re correct. If you want a design that aligns down to the pixel and has the perfect colours on every monitor/browser/platform, HTML is not your best bet to start with, and NO interactive language with the flexability of HTML could do that anyway.
HTML and CSS are easy to learn, cheap on bandwidth, viewable in every browser made in the last what, 6 years, including PDAs/cellphones…
What is your alternative?
Phillip Ryals said…
You push the idea that ‘something better’ should be created, either by fixing CSS or replacing it outright. I challenge you… how would YOU create this fictional superior method of describing a complicated design using RAW TEXT?
You see, from a designer /and/ programmer’s perpective, CSS is a very good tradeoff. No, I can’t draw a few boxes, apply some drop-shadows, scale some fonts, and see the results in a web browser. That’s life. Vector graphics for the web has been tried before in many many ways (anyone remember the Xcalibur BBS?) but it’s never taken off because it still requires more processing power than just rendering raw text.
The point is, you’re not going to get an easy-to-use method of creating complex designs. They’re complex, and so the method for creating them is complex. While CSS rendering isn’t predictable across all browsers (NOT the fault of CSS), it does indeed make many things possible that would otherwise never work.
Dean Hall said…
My rule of thumb is “Consistency, Consistency, Consistency” when it comes to a GUI. Neither CSS or anything else gives me an assurance of that. So I do what all developers do and I do whatever works. If CSS works for a project, then I use it. If it doesn’t look like it will, I use tables.
I thought this was a good article, with some valid points.
Anonymous said…
Anonymous said…
Anonymous said…
Most miss the point altogether, like:
Greg I just want to ask you what if I told you that Quark will no longer be supporting style sheets? Would you be ok with that? Even if you were working on a 120 page document? I’d be pissed, just like I would be pissed if they took away CSS.
This is irrelevant. Greg has not talked against the general idea of stylesheets, he talked against the CSS concept and implementation in particular. His points are specific and razor sharp, and could be used in designing a BETTER stylesheet language for the web. Like this point:
CSS captures styles not semantics or design intention. A design intention would be something like: “I want to balance these two columns” or perhaps “This text should line up with the logo image in the first column.” When designers do things like this:
#content{position:relative;top:32px;left:20%;width:40%;}They are capturing the style specifics not the design intention. Why 32 pixels? Why 40%? Perhaps the logo is 32px tall? Perhaps the other column is 60% wide? When the logo changes size or placement how will you know what styles to touch? There is a basic concept called parametric design that can be used to specify the parameters of the design.
Right on!
And since a lot of web pages nowadays are “web apps”, are you “css people” familiar with actual programming for GUIs? If you know GTK, QT, Java or what have you, they all have MULTIPLE layout models. CSS only has one, and a cripled one at that, the box model. A single model cannot solve all needs. (btw, almost all languages offer a table or grid layout manager, without sacrificing “fluidity”).
Some points:
a) The concept of styles is correct. It’s CSS that has it all wrong.
b) Design should be intention based and parametric. Hell, CSS does not even have parameters! If I want 20 design elements in my stylesheet to be 200px (or 20% or anything), I have to repeat myself 20 times over. When I want to change it to 200px it’s 20x times the work actually needed).
c) A lot of stuff should have been built in, in CSS and HTML and easier. Rounded corners? Blow me, just have something like:
#box {curve-top-right: 20px }
or have a way to define such effects in code blocks and share them.
etc…
Anonymous said…
Nick Presta said…
Oh, you mean like CSS3’s border radius property?
http://www.w3.org/TR/2002/WD-css3-border-20021107/#the-border-radius
Anders said…
Rich C said…
Web sites I build using CSS positioning for images are a lot more readable and maintainable than those I used to make using table-based layouts.
Greg Raiz said…
$logoh:120px;
$smallMargin:3px;
$largeMargin;10px;
.logo {height:logoh;}
.titletext {top:logoh+smallmargin;}
I’m using the $ show how you could declare a parameter/variable. This is still declarative so it’s not an ideal solution but at least it demonstrates how parameters could allow you to do things that are difficult or impossible to do via traditional cascading.
Anonymous said…
Or you can learn what cascading in CCS means and how to implement it.
Erm, cascading != parametric.
In the case I describe, for example, who told you that the 200px always refers to the same attribute (like width?). It could 200px of width for this element, 200px padding for the other, et al, used for implementing a consistent grid.
Or I could want a yellow background-color in one item, and a yellow foreground in some text or a yellow border in another. Cascading does not offer a way to define all these cases depending on a single color definition.
—
foljs
Daron said…
HTML, CSS, Javascript and all their evil offshoots are a result of:
* an inadequate and limited initial definition of the “web page” problem domain
* a crude, fatally flawed but simple to use initial technology (HTML)
* which lead to designers and programmers crufting up a mind boggling array of workarounds to fill the gaps (Tables and Spacer gifs)
* which spurred a belated attempt to redefine the underlying technologies by rigid academic edict mainly by non-designers (Cascading Style Sheets, XHTML, Widespread Deprecation)
* which was anyway largely undermined by the piecemeal and incompetent implementation of the new technologies in browsers and development tools (all of them)
* which is now all welded into place by the network effect, endless inert committees and monopolistic self interest. (Welcome to the Great Leap Backwards)
We are stuck with a kludge built on a kludge until we have a disruptive technology.
And Flash wasn’t it.
bjk2007 said…
Greg Raiz said…
bjk2007 said…
I did take the time to read it again after I had calmed down. I would have to say that while I disagree with you on several points, I do agree that CSS hasn’t done as well as it should have. Why? Simply browser support (IE). If we can’t get them to support CSS, how can we ever assume that they’ll support the newer and better theoretical CSS replacement language?
I guess the rest of my disagreements with you lie in a coder/designer mentality. You seem to be more of a designer while I’m actually a person whose strengths lie in coding, so we’re bound to disagree on how things should work.
Anonymous said…
IN PLAIN ENGLISH:
Not Microsoft, Netscape, Mac whatever can stop a standard being created, fact is those “browser companies” don’t make websites or web application (well they do make some) and developers NEED a standard so they aren’t writting 12 different lines to support 12 different venues. With these 2 standards (CSS2 and XHTML) we will have easier to maitain websites, portable applications, accessibility features for the blind/hearing impaired and about a million other applications.
SO TO ANY NEWBIE DO NOT LISTEN AND MAKE SURE TO USE CSS2 AND XHTML IN ALL FUTURE PROJECTS
Anonymous said…
josh said…
CSS is terrible. I’ve spent countless hours learning it and no matter what, the results are different from browser-to-browser.I can’t stand learning it, but at the same time I love the way some of these Css-driven sites are put together. I think to myself “I want that!” But it never happens. CSS is driving me insane. It always will drive me insane. Has potential, but it sucks.
John Nagle said…
CSS is, simply, a badly designed layout system. Even the rather simple system in Tk which lays out dialog boxes and windows is better. Tk is a nested-box system, but both “pack” (like CSS “float”) and “grid” (like tables) layouts are available in the same system. This is enough to handle most cases. Which “float” and “clear” are not. Page layout is forced to fall back on absolute positioning far too often.
The clever way to do layout would have been with a constraint system. Each box has four edges and four corners, and it would be possible to bind corners and edges to create any desired relationship between boxes. This is something one could express easily in a click and drag graphical tool. Want three columns the same height? Tie their adjacent bottom corners together.
Want to fill the page? Tie the outside corners to a page edge. Ten minutes to explain to an artist. Advanced use would involve priorities on constraints, so if something had to give in “fluid design” as the page size or type size changed, you could pick what gave first. (This could be extended to allow curved boundaries, even splines, but that might be overdoing it.)
The browser would have to have a constraint engine to resolve all the constraints, but there are known solutions to that problem.
Too many people drank the Kool-Aid on CSS. It’s just not that good a technology.
frostbyte said…
John Nagle said…
If CSS had a grid capability, it wouldn’t be so bad. But it doesn’t.
Anonymous said…
Anonymous said…
It was about separating format from markup to create data semantics.
Greg you are right on the nail. I wonder how many of these so called “CSS Designers” have the BIG profitable accounts.
Can you make the money with CSS on these sites using CSS, I dare you?
Look at these:
http://www.cosmopolitan.com/
http://www.elle.com/
http://www.nike.com
http://www.adidas.com
http://www.faithhill.com/
http://www.motley.com
http://www.imandd.com/index.html
Go on, make one of these (CNN for example) using CSS no hacks, js, pure w3c css. Publish the markup as a test and let us see that you know your css stuff.
Montoya you are the teacher, or is css only for the graphics blind? Prove Greg wrong, go ahead and make my day.
CSS can not do what the tables and flash can here. Forget semantics, forget standards, come and visit me for a little while in reality land. Bottom line people, hard cold cash it’s what matters.
Montoya get off you high horse and do something about it. Rewrite the standards so is more workable.
Use what works, and if you can separate format from markup with css and if tables have to be used so be it and format them in your css.