Overcoming Command Line Allergies
•
0 gefällt mir•641 views
Getting comfortable with the command line while learning Drush, Features, and Git. A presentation for the 2015 PNW Drupal Summit.
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Andere mochten auch
Ähnlich wie Overcoming Command Line Allergies
Ähnlich wie Overcoming Command Line Allergies (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Overcoming Command Line Allergies
- 1. Overcoming Command Line Allergies Elaine Nelson v elainenelson.org
- 2. Caveats
- 3. What I want you to learn
- 4. Who am I?
- 5. WHY IS IT SO HARD?
- 7. WHY SHOULD I BOTHER?
- 9. Features + Git = Better Drupaling
- 10. The land of the “real” programmers
- 11. FIND YOUR COMFORT ZONE
- 12. IT’S DANGEROUS TO GO ALONE! TAKE THIS…
- 14. Make it a little nicer • clear (Mac only) • Different styles • Bigger type
- 16. Vim, nano, or whatever
- 17. The Googles • That XKCD flowchart https://xkcd.com/627/
- 18. The first time you try stuff, it might be terrible.
- 19. SAMPLE PROJECT
- 20. THIS IS THE PART WHERE WE CARGO CULT
- 21. Set up a web server! MAMP + command line https://www.mamp.info/ http://bramvandenbulcke.be/en/article/ installing-drush-mamp Acquia Dev Desktop https://www.acquia.com/products- services/dev-desktop
- 22. SAVE YOUR HANDS WITH DRUSH
- 24. Is this thing on? drush status
- 25. Module installation: the old way
- 26. Module installation drush en module_name
- 27. Always say YES drush en module_name --y
- 28. Advanced module tricks drush dl project_name drush en module_name-7.x-x.x
- 29. Updates drush up
- 30. drush cc all
- 31. How to go further • Beginner’s guide https://www.digitalocean.com/community/tutorials/a- beginner-s-guide-to-drush-the-drupal-shell • Full list of commands http://drushcommands.com/ • Drupalize Me https://drupalize.me/videos/what-drush?p=1156
- 32. A FEATURE IS A WHAT NOW?
- 33. Naming things is hard • Features is a module. • A feature is something made with Features. • A feature is also itself a module. The simplest way to create a setup of content types, views, and other stuff.
- 34. Install Features drush en features --y
- 36. Putting your Feature to work drush en feature_name --y
- 37. How to go farther • Drush commands to use with Features: https://www.drupal.org/node/960926 • Migrate works with Features • Drupalize Me (no, they’re not paying me)
- 38. GIT IS YOUR SAFETY NET
- 39. like Dropbox, but for Features
- 40. Again on the live
- 41. Adding changes Needs drush fu screenshot?
- 42. Stage > Commit > Push
- 43. Rolling back
- 44. Fetch > Pull > Revert
- 45. Tools for Git GUIs for Git • Cross-platform, free: Github & Sourcetree • My preference: Tower (Mac only, $69) Remote origin options • Github • Bitbucket • Gitlab
- 46. Add complexity as you need it • Rolling back, branching, merging • Git for Teams Emma Jane Hogbin Westby http://shop.oreilly.com/product/0636920034520.do
- 47. ALLERGY RELIEF
Hinweis der Redaktion
- Hi, today I’m going to talk you for a little bit about overcoming command line anxiety. I know it says allergies, but really, what we’re talking about is anxiety.
- Before I get started, a few caveats. I’m only covering Drupal 7. I don’t know what’s the same or different in Drupal 8. This is going to be very introductory material. But you should know your way around Drupal in the browser.
- That said, what I hope you’ll get out of this is confidence you can set up and run a web server on your local computer to run Drupal. That you’ll have some ideas of how Drush will make your life easier. I want you to see what’s cool about Features and why you’ll want to use Features together with Git. Everything in this talk will be on Slideshare and up on the summit website afterwards.
- So I’ve been using Drupal off and on for about 6 or 7 years. Currently I work at The Evergreen State College, where we’re in the process of migrating to Drupal from a proprietary CMS for our public-facing website. While I’ve been using computers of one sort or another since the early 90s, I’ve only rarely needed to use the command line. So I’m coming to this as someone with a lot of discomfort using command line tools.
- Why IS it so scary to use command line tools?
- I was recently reminded of the difference between cooking and baking. So if you’re making something like a stir-fry or a sauce, you can see what's happening as it happens. If it's not quite right, usually you can tweak it on the fly: turn down the heat, add a little salt or a little water. And most of the time, absolute precision isn't that important. There’s a pretty wide range of acceptable. On the other hand, baking gives you a double-whammy. First, you have to be precise with the ingredients. If you’ve ever left out or overdone salt or baking soda, you know what I’m talking about. Then, once it’s in the oven, there’s not much you can do about it, you’re just waiting. For me, the graphical user interface feels like cooking. Your hand is halfway there, and you turn aside. The affordances of a button let you hit approximately the right target. By contrast, with the command line, precision is everything and on top of that, there’s that chance that if you mistype or change your mind [shiny button]… You’ve destroyed everything. So it’s legitimately anxiety-inducing.
- Presumably you’ve gotten this far in life without needing it. I’m going to assume you have at least a vague thought that it might be worthwhile anyway, or you wouldn’t be sitting here. But I’ll give you a few reasons to encourage you to try these tools.
- [what IS Drush?] Drush is a tool that lets you do Drupal tasks from the command line. We use computers to make the boring stuff easier, right? For me, Drush is all about making boring tasks go more quickly. And it's pretty cool to take a really boring task and just type a single line and have it just go "poof!” On top of that, because Drush isn’t subject to the restrictions of loading a webpage in Drupal, some processes run faster that way.
- Features is a module that makes it possible to create a set of content types, views, and other configuration. Git is a version control system. They help you to break less stuff. If you use them, either separately or together, it’s easier to experiment, back out of your experiments, and move work from one site to another.
- Finally, because programmers write modules, and programmers use the command line, some modules like Features don’t make all of their tools available in the browser, or they write them so the easiest way to get at an error or a feature is through the command line.
- Sometimes command line is easier, and sometimes GUI is easier. And different people have different opinions about it. As I go through this, I'm going to switch back and forth, to remind you that you should use WHAT WORKS FOR YOU. ----- Meeting Notes (10/8/15 15:54) ----- gif of creamsicle with ps controller
- We’re going to start with some command line tools that will serve you well whatever you do.
- dir or ls: see what's in the folder you're in. use ls if you’re on a Mac; use dir if you’re on Windows. [dir = directory, ls = list] cd: go to another folder [cd = change directory] Drag and drop Right-click to paste (windows)
- clear: use clear just to not be overwhelmed by a wall of text. It pops the blank line you’re on to the top of the screen. [doesn’t work on Windows] On Mac, the Terminal application has quite a few nice font and color options. I was startled to find myself have more than one terminal window and using different color themes to tell them apart. On Windows, there’s a variety of replacements for the built-in “cmd.exe”, you want to go looking for “console” replacements.
- The up arrow is your friend. it's like scrolling through your history to find a thing. If you do the same thing over and over, which you might, then hitting the up arrow is faster and safer than typing out the command over again. F1 on windows has a similar effect.
- Especially in the setup phases of using these tools, at least on Mac, you may have to edit text files with a command line editor. There are at least two different command line text editors. They're weird. If you discover that you like one or the other, good for you. Either way, GOOD tutorials will include which key combos to use. http://ausdroid.net/wp-content/uploads/2013/07/Konami-Code.jpg
- You know this, or you wouldn’t have gotten this far, but being able to write a clear meaningful search query is your MOST POWERFUL tool. Use those error message for searching.
- The first time you try it, things may go horribly wrong. And that’s ok. Don’t try any of this stuff on anything mission critical or publically-facing, until you get a little more comfortable. You may end up doing everything and then ripping it out again. Stimpy aside, it’s going to be fine.
- Instead, it’s great to work on a little sample or hobby project. In this the presentation, any screenshots and demonstrations are going to come from a sample project that I’ve been working on. It’s a custom bestiary for role-playing games.
- Who knows what a cargo cult is? [if anyone looks baffled] Here’s the short version: In world war II, we set up lots of little temporary bases on lots of little Pacific islands that had never seen westerners. On some of those islands, the people associated the strange actions and objects of the Army with the amazing wonders that they brought, and adopted religious rituals that incorporated the shapes of WWII technology without knowing anything about the actual technology. On the assumption that if they do the rituals then they’ll get the things. Sometimes, for me anyway, getting command line tools up and running is a lot like being part of a cargo cult. Unlike those islanders, you can actually get pretty far with this cargo cult.
- In order to run Drupal locally so you can try out Drush and Features, you’ll need to install a local web server. I have my system down on my Mac at work, but have run into a number of annoying issues on my Windows computer at home. I’ll admit that if you’re running Windows, this is where you’ll need to go do some research. For example, I got WAMP (Windows, Apache, MySQL, and PHP) running, and even had Drupal installed, but never got Drush quite together. Last week I tried again with Aquia Dev Desktop, which is supposed to come with everything, and had weird issues that might’ve been a firewall problem? I know there’s several people here who do know how to get all this set up on Windows, so it’s totally doable. As far as I can tell, your best bet is probably the Aquia Dev Desktop. Which also comes for Mac, but I’ve set up my system using MAMP and this really nice tutorial.
- So once you’ve gotten through whatever cargo cult stuff you had to do, you’re ready for Drush! Most of what I’m going to walk through next is commands that reduce how much clicking you need to do. This will save you time and make your hands and wrists happier.
- Warnings!
- Navigate to the folder where your site is located on your hard drive. Remember that cd stuff? this is where that comes in.
- Just a reminder of how I installed modules before I started learning drush.
- Screenshots! * Tiny bonus trick that comes in handy later: contrib & custom folders. En = enable Also “--y” – use example of views ui
- Also with specific version CAUTIONARY NOTE: sometimes the thing you need is a module in a project that contains many modules, and the project itself isn’t actually a module! Where I’ve gotten tripped up: media, features_extra. If you type “drush en project_name” and after you’ve clicked all the “y”, and it keeps asking you to download, then you know you’re stuck. The other thing you can do is if you want a particular version of a module
- Up = update
- Clear cache
- Now we’ve got a taste of drush, we’re going to learn a bit about features. Features is one of those things in Drupal-land that can be really hard to wrap your head around. It’s taken me several tries, but when I got it, I realized it was magic!
- Mostly because words. It's called "Features" and you make a thing called a "feature" and that's also somehow a module? It took me at least three attempts before I really got it. The short version: in Drupal 7, it's the simplest way to put all your content types, Views, and a bunch of other stuff together if you want to move them from one site to another.
- So yes, it is a module, and you install it like any other module: drush en features --y
- And then you go back into the browser. For this site, I’ve created a content type called Monster, and it has some custom fields, and I’ve created a View that lists all the Monsters in a big table. To turn that into a feature, I go to Structure – Features, and then go to the Create a Feature screen, check the boxes for the content type, and the view, write a little description, and download, what turns out to be a tar file. When I unzip it, it turns out to look a lot like a module. And oddly enough, we’re going to treat it like one. Now, I can’t automatically download it, so I’m back to copying and pasting, but I can go into the command line, type drush en bestiary --y and when I go back to the browser, it’s listed on the page and enabled.
- Now that we’ve created a Feature, it’s going to be really easy to set up another site! For the purposes of this demo, that site is also on my local machine, but this works for a Drupal site that you might have hosted somewhere out there. Create your site as usual, then put the feature with your folder in your modules folder, and enable it either through Features in the browser, or like any other module. If you have “shell access”, that means you can even use Drush on your remote site. (Have you always been like: and why do I need shell access? This is why.) Now there’s a development bestiary locally, and a live bestiary somewhere else, and I didn’t have to go through clicking all the things to set the one site to be like the other site.
- I’m going to change the feature and move those changes in just a moment, but first, some resources to take with your Features work… If you’re feeling ambitious, you may want to check out Migrate, which seems terrifying because there’s no UI for setting data up for migration, but if you’ve written any PHP at all, it’s possible to figure out the code to write your own migrations. I’ve mentioned them before, but I think Drupalize Me has some really great tutorials for both Features and Migrate. I usually don’t get much out of video training, but these were great.
- Now I’m going to add another tool to this set with Git. Extra-strong caveat: I AM NOT A GIT EXPERT. About 80% of the time I use Git like a fancy-pants Dropbox. But wow, when you need the features of Git, you REALLY need them.
- At some point while you set up Drush, you end up installing Git in that kind of cargo-cult way I mentioned before. Now it’s actually going to be useful! You can totally use the command line with Git, and I’m going to show a little bit of that. But there are quite a few nice graphical Git clients. The Github app and Sourcetree are both cross-platform and free. I use Tower most of the time, which is NOT free. Our designer loves it, and I’ve to the same opinion. I’m going to turn that Feature into a repository, and I’m going to use the command line to do it. First I cd to the correct folder, then it’s just git init, and that makes a bunch of hidden files that git knows what to do with. But it’s not actually track the files until you manually add them with git add . The period means that it should just include everything. Then comes the “dropbox” aspect of using Git. By using git remote origin, I’m telling Git that it should connect this repository with some location out there. As far as where “out there” actually is, there’s github, bitbucket, gitlab, and so on. At work, we have a custom installation of Gitlab that’s only accessible on the local network. Then, finally, you push those files out to that place.
- Now I can go to my “live” site and turn the module folder over there into a repository as well. I can start by using the exact same commands in the command line, all the way up through adding the remote origin. But I’m going to stop there, because I already know that the remote and the local are the same. After all, I copied them myself by hand.
- Which means it’s time to start changing things! First we make a change to the view, something that already stored in the feature code, add description Now it shows up as Overridden. If I wanted to undo the change, I could use the “revert” function. But I don’t. I want this to be a permanent part of my feature. So I switch to the command line. Drush fl just shows pretty much the same thing as the browser. But drush fu bestiary will ADD those changes to the feature, rewriting the code in the files in my site. Because we’re all 12 or something, everybody snickers about drush fu. Of course, it stands for features update, and you can actually type drush features-update, but we’re all about saving time. Strongarm! What I also want is for the site’s name to be part of the bundle. But there wasn’t any way to do that when we created the feature. I need something called Strongarm. Personally, I think strongarm should be required for Features, because there’s even things about the content type that you can’t save without using strongarm. Now that I have strongarm enabled, I can at least in theory add more stuff to my Feature: but how? Fu works for integrating updates to existing parts of a feature, but I’ll need to do something else to add that site name. And takes us back to the browser: go to the Recreate tab, which looks just like how we created, but with everything prefilled. And now there’s a Strongarm section, too. So adding changes through recreate is just like how you originally created the feature. It’s possible to do this through Drush with features-export, but personally, I find it easier to decide what to add when I can see all the possibilities at once. ----- Meeting Notes (10/8/15 15:54) ----- override recreate revert
- We’re going to make a change in the list of environments to better match the language that’s used in the data we’re importing: “Ocean” to “Aquatic” and “City” to “Urban” Then run through updating the feature by running drush fu bestiary. And when I switch to Sourcetree, I can see the changes. I know I want to save those when I move the Feature to my live site, so I’m going to commit them. First I have to stage them, then I write a message. I think writing commit messages is a good gateway to write quality documentation. It helps me think about what this change means in as simple a way as possible. I’m choosing to just commit to my local repository, which gives me that second chance before I sent it to the files in the sky.
- Unless I get these screenshots, gonna have to handwave!!!!! So actually, this is a good spot to see something counter-intuitive in Features. If I head over to the browser and look at the feature there, it says that the site name is “overridden” – that’s because it still has the site name I used when I set this site up, and to Features, anything in the database that’s different from the code is an override, even if technically it happened before that thing was actually in the code. This is where I want to use Revert! Revert always means “make it like the code”. And now that I’ve pulled the newest code and reverted anything that had been different in the database, I’ve got a copy of my development setup all ready to go.
- There’s so much more you can do with Git. I’ve done a little bit with rolling back, branching, and merging, including working on a theme with my designer. Like I said, I’m in the middle of reading Git for Teams, and it’s great. She does everything in the command line, but it’s got a good mix of conceptual and practice.
- I hope this has reduced your anxiety and made the command line feel less scary, maybe even gotten you excited about things you could try out. I’ll say that I’ve had a lot of fun putting these tools together in my own work. Thank you!