Ruby命令行应用开发指南：打造用户体验卓越的工具

unix

textbook

需积分: 6 179 浏览量更新于2024-07-17 收藏 4.71MB PDF 举报

身份认证购VIP最低享 7 折!

领优惠券(最高得80元）

资源详情

资源推荐

We can then discuss particular lines using a numbered list:

❶ Here we define a new method named

upper_case_file

❷ We check for

nil

here, so we don’t get an exception from

File.open

❸ Finally, we uppercase the line we read from the file before printing it with

puts

Testing

The Ruby community loves testing; test-driven development is at the heart

of many great Ruby applications, and the community has a wide variety of

tools to make testing very easy. We’ll even be looking at some in Chapter 8,

Test, Test, Test, on page 117. We won’t, however, be doing much testing until

then. While you should absolutely test everything you do, it can be somewhat

distracting to explain a concept or best practice in the context of a unit test,

especially with some of the unique features and challenges of a command-

line application.

So, don’t take the lack of testing as an endorsement of cowboy coding.

. We’re

omitting the tests so you can take in the important parts of making an awe-

some command-line application. Once you’re comfortable with these best

practices, the information we’ll discuss about testing will leave you with all

the skills you need to test-drive your next command-line app.

Online Resources

At the website for this book,

you’ll find the following:

• The full source code for all the sample programs used in this book.

• An errata page, listing any mistakes in the current edition (let’s hope that

will be empty!).

• A discussion forum where you can communicate directly with the author

and other Ruby developers. You are free to use the source code in your

own applications as you see fit.

Note: If you’re reading the ebook, you can also click the little gray rectangle

before the code listings to download that source file directly.

http://en.wikipedia.org/wiki/Cowboy_coding

http://pragprog.com/titles/dccar2

Introduction • xiv

report erratum • discuss

Acknowledgments

This book started as part of the Pragmatic Programmers’ “PragProWriMo,”

which isn’t much more than some budding authors posting their daily writing

stats to a forum

every day during the month of November. This book is very

different from the 170 pages I produced in November 2010, but I wrote almost

every day, proving that I could actually produce a book’s worth of material

and that writing command-line applications in Ruby was a large enough

topic to fill a book!

I had no particular plans to do anything with the manuscript I wrote, but

when Travis Swicegood, author of Pragmatic Version Control with Git [Swi08],

posted in the forum that his PragProWriMo manuscript had been accepted

for development, I thought I’d submit mine as well. So, while Travis wasn’t

the inspiration for the material in this book, he certainly was the inspiration

for turning this material into a book.

There are a lot of people to thank, but I have to start with my wife, Amy, who

has been amazingly supportive and encouraging. She even let me install Ruby,

vim, and Cygwin on her Windows laptop for testing.

I’d like to thank my editor, John Osborn, for his patience and advice as well

as for inadvertently giving me a crash course in technical writing.

Next, I’d like to thank all the technical reviewers who gave me invaluable

feedback on my manuscript at various stages of its development. They include

Paul Barry, Daniel Bretoi, Trevor Burnham, Jeff Cohen, Ian Dees, Avdi Grimm,

Wynn Netherland, Staffan Nöteberg, Noel Rappin, Eric Sendlebach, Christo-

pher Sexton, and Matt Wynne.

Finally, I’d like to thank the many programmers who’ve contributed to the

open source projects I mention in the book, including, but probably not lim-

ited to, the following: Aslak Hellesøy, TJ Holowaychuk, Ara Howard, Yehuda

Katz, James Mead, William Morgan, Ryan Tomayko, Chris Wanstrath, and,

of course Yukihiro “Matz” Matsumoto, who created such a wonderful language

in which to write command-line apps.

With all that being said, let’s get down to business and start making our

command-line apps a lot more awesome!

10.

http://forums.pragprog.com/forums/190

report erratum • discuss

Acknowledgments • xv

CHAPTER

Have a Clear and Concise Purpose

You need to solve a problem. It might be that you need two systems to talk

to each other that weren’t designed for it. Or you may need to run some

automated yet complex task periodically. Or, you may want to build simple

productivity tools to help you work. This is where the command line shines,

and these are the kinds of problems you’ll learn to solve in this book.

Although it may seem obvious that a focused, single-purpose app is more

desirable than one with a “kitchen sink” full of features, it’s especially

important for command-line apps. The way in which command-line apps get

input, are configured, and produce output is incredibly simple and, in some

ways, limiting. As such, a system of many single-purpose apps is better than

a system of fewer (or one) complex apps. Simple, single-purpose apps are

easier to understand, are easier to learn, are easier to maintain, and lead to

more flexible systems.

Think of your command-line tasks as a set of layers: with the basic foundation

of the standard UNIX tools, you can create more complex but still focused

command-line apps. Those can be used for even more complex apps, each

built on simpler tools below. The popular version control system

git

follows

this design: many of

git

’s commands are “plumbing” and are not intended for

regular use. These commands are then used to build “porcelain” commands,

which are still simple and single-purpose but are built using the “plumbing.”

This design comes in handy because, every once in a while, you need to use

the “plumbing” directly. You can do this because

git

was designed around

tools that each have a clear and concise purpose.

This chapter will set the stage for everything we’ll be learning in the book.

We’ll look at two common problems and introduce two command-line apps

to solve them. As a means of demonstrating more clearly what we mean by

having a “clear and concise purpose,” each problem-solving app will get an

report erratum • discuss

iteration in this chapter. The first version of each app will be naive and then

quickly revised to be more single-purpose, so we can see firsthand the level

of function we want our apps to have.

1.1 Problem 1: Backing Up Data

Suppose our small development team is starting work on our company’s

flagship web application. This application is heavily data-driven and highly

complex, with many features and edge cases. To build it, we’re going to use

an Agile methodology, where we work in two-week “sprints.” In each sprint,

we’ll have a list of “user stories” representing the work we’re doing. To officially

complete a user story, we’ll need to demonstrate that story functioning

properly in a shared development environment.

To be able to demonstrate working features, we’ll have a set of databases with

specially chosen data that can simulate all of our edge cases and user flows.

Setting up this data is time-consuming because our app is complex, so even

though this data is fake, we want to treat it like real production data and

back it up. Since we’re constantly changing the data as we work, we want to

save the state of each database every single day of the current iteration. We

also want to keep a backup of the state of each database at the end of every

iteration. So, if we’re on the fifth day of our third iteration, we want to be able

to access a backup for iterations 1 and 2, as well as backups for the first four

days of the third iteration.

Like with most teams, at our company, we can’t rely on a system administrator

to back it up for us; we’re a fledgling start-up, and resources are limited. A

command-line app to the rescue! We need an app that will do the following:

• Do a complete dump of any MySQL database

• Name the backup file based on the date of the backup

• Allow the creation of our “end-of-iteration” backup, using a different

naming scheme

• Compress the backup files

• Delete backups from completed iterations

Let’s take a quick stab at it. We’ll set up a

Hash

that contains information

about all the databases we want to back up, loop over it, and then use Ruby’s

backtick operator to call

mysqldump

, followed by

gzip

. We’ll also examine the

first argument given to our app; if it’s present, we’ll take that to mean we

1. You need to have both of these commands installed.

gzip

is standard on most UNIX

and Mac computers.

mysqldump

requires installing MySQL. You can learn about MySQL

http://dev.mysql.com/doc/refman/5.5/en/installing.html

Chapter 1. Have a Clear and Concise Purpose • 2

report erratum • discuss

剩余211页未读，继续阅读

qq_40790657

粉丝: 0
资源: 4

Ruby命令行应用开发指南：打造用户体验卓越的工具

vue.js轮播组件vue-awesome-swiper@3.1.3 实现轮播图

tarball tarball data for vue-awesome-swiper@http://172.168.251.67:4873/vue-awesome-swiper/-/vue-awesome-swiper-3.1.3.tgz

cnpm install swiper@5.x vue-awesome-swiper --save

Nuxt2 npm下载之后 怎么搭载在config.js Vue-Awesome-Swiper

ERROR in ./node_modules/.store/vue-awesome-swiper@5.0.1/node_modules/vue-awesome-swiper/index.js 6:0-49

<input type="text" class="chaitem" name="" id="" placeholder="给你推荐 香烟爱上火柴"> 我这段代码如何在input里面的提示文字前面加个放大镜图标

peer vue@"3.x" from vue-awesome-swiper@5.0.1

index.js:167 ./src/main.js Module not found: Error: Can't resolve 'font-awesome/css/font-awesome.min.css' in 'C:\Users\a\zyx\src' @ ./src/main.js 7:0-47 @ multi (webpack)-dev-server/client?http://localhost:8080 webpack/hot/dev-server ./src/main.js

如何在main.js中引入font-awesome样式

vue.js版本为2.7.14，elementui版本为2.15.13，vue-router版本为3.6.5， Less 3.x 版本和 Less-loader 7.x 版本,swiper版本为5.4.5，与之适配的vue-awesome-swiper版本为多少,

github c语言学习

如何为icon图标设置样式

nuxt中使用 vue-awesome-swiper

2006-2021 中国各地万达广场地理分布数据.zip

【创新未发表】Matlab实现布谷鸟优化算法CS-GRU实现风电数据预测算法研究.rar

最新资源

Nuxt2 npm下载之后怎么搭载在config.js Vue-Awesome-Swiper

<input type="text" class="chaitem" name="" id="" placeholder="给你推荐香烟爱上火柴">

我这段代码如何在input里面的提示文字前面加个放大镜图标