Slashdot Mirror
Taco Bell Programming
theodp writes "Think outside the box? Nah, think outside the bun. Ted Dziuba argues there's a programming lesson to be learned from observing how Taco Bell manages to pull down $1.9 billion by mixing-and-matching roughly eight ingredients: 'The more I write code and design systems, the more I understand that many times, you can achieve the desired functionality simply with clever reconfigurations of the basic Unix tool set. After all, functionality is an asset, but code is a liability. This is the opposite of a trend of nonsense called DevOps, where system administrators start writing unit tests and other things to help the developers warm up to them — Taco Bell Programming is about developers knowing enough about Ops (and Unix in general) so that they don't overthink things, and arrive at simple, scalable solutions.'"
So if I limit myself to 8 keywords my code has less defects and is more maintainable?
Can I get a server logging system, hold the email notifications. Can I get extra rotating log files with that?
Reminds me of a job interview I did once with an old guy, he had around 30 different programming languages on his resume. I asked him which programming language was his favorite, expecting it to be something like Lisp or Forth, but he said, "shell script." I was a bit surprised, but he said, "it lets me tie pieces in from everywhere and do it all with the least amount of code."
I wasn't entirely convinced, but he did have the resume. Seems Mr Dziuba is from the same school of thought. I read the full introduction to the DevOps page and I'm still not entirely sure what it's about. We should work together and deliver on time, or something like that.
Qxe4
Good grief, I think this is yet another useless article from the Ted Dziuba/Jeff Atwood/Joel Spolsky crowd. They spew out article after article after article with, in my opinion, bullshit "insights" that don't hold any water in the real world. Yet they've developed such a large online following, mainly of "web designers", "JavaScript programmers" and "NoSQL DBAs", that it tricks a lot of people in the industry into thinking what they say actually has some usefulness, when it usually doesn't.
Yeah, it's great when we can write a few shell or Perl scripts to perform simple tasks, but sometimes that's just not sufficient. Sometimes we do have to write our own code. While UNIX offers a very practical and powerful environment, we shouldn't waste our time trying to convolute its utilities to all sorts of problems, especially when it'll be quicker, easier and significantly more maintainable to roll some tools by hand.
You can easily have a little more or less salt, sugar or flour in your food. However, software is not so forgiving. Change one character and you screw up badly. Lets face it, software is hard to write and it is even harder to write good software.
Although re-use is a good thing and scripting many common problems instead of coding in [insert low-level language] is also good. But this should be common sense for any /good/ programmer. Good tools make bad programmers look slightly less bad, but fuck up anyway. Good tools make good programmers gurus.
...you insensitive clod!
8 commands. period. no more, no less. Super maintainable, cross platform and...
bah, who am I kidding?
...spike
Ewwwwww, coconut...
When I saw the title I thought it was a book review of a new O'Reilly release of that name.
From over a decade ago: Taco Bell's Five Ingredients Combined In Totally New Way
I think of that article every time Taco Bell adds a "new" item on their menu.
I limit myself to two bits. A 0 and a 1.
Why would I need 8?
Seriously, what's going on with the articles here? "My code is like a Taco"? Is that flying because of CmdrTaco's username?
Nothing new here:
1) Code reuse. Woopdeedoo. The whole industry has invested heavily in many paradigms for reusing code: The reusable library, module reuse, object reuse etc.
2) Stringing Unix commands together is news? Did I just take a Deloriane back to 1955? (Well that's a slight exaggeration. Unix has only been around since the 70s)
Finally, who wants to compare their code reuse to a crappy junk food chain? I'd rather think of myself as a professional that earns commensurate pay than a junk food server who needs to be trained to ask "would you like fries with that?".
These posts express my own personal views, not those of my employer
From over a decade ago: Taco Bell's Five Ingredients Combined In Totally New Way
I think of that every time Taco Bell adds a "new" item to their menu.
Dear Slashdot: next time you want to mess with the site, add a rich-text editor for comments.
I made most of a SOAP server using static files and Apache's mod_rewrite. I could have done the whole thing Taco Bell style if I had only manned up and broken out sed, but I pussied out and wrote some Python.
It seems that only software he knows counts as "Taco Bell ingredients". I'd trust Axis (or any other SOAP library) much more than sed to parse a web service request. Heck, if you discount code that you don't directly maintain, SOAP requires very little code other than the functionality of the service itself. I had a boss like this once. He would let you do anything as long as you used tools he was familiar with, but if you brought in a tool that he didn't know, you had to jump through a thousand extra testing hoops. He stopped doing actual work and got into management in the early 90's, so he pretty much didn't know any modern tool. He once made me do a full regression test on a 50KLOC application to get approval to add an index to a Microsoft SQL Server table.
The complexity people seem to delight in putting into things always amazes me. I was recently working at a major bank (they didn't like me eventually as I'm bad at authority structures). Anyway the area I was working on involved opening bank accounts from the web site. Complicated, right? The new account holder has to choose the type of account they want (of about 7), enter their details (name, address, etc), and press go. Data gets passed about, the mainframe makes the account, and we return the new account number.
Gosh.
So why, oh tell me why, did they use the following list of technologies (usually all on the same jsp page) [I may have missed some]
HTML
CSS
JSP (with pure java on the page)
Javascript (modifying the page)
JQuery
XML
XSLT
JDBC with Hibernate
JDBC without Hibernate
Custom Tag library
Spring (including AOP)
J2EE EJBs
JMS
Awesome. All this on each of the countless pages, each custom designed and built. Staggering. In fact, the site needed about 30 pages, many of them minor variations of each other. The whole thing could have been built using simple metadtata. It would have run faster, been easier to debug and test (the existing system was a nightmare), and easily changeable to suit the new business requirements that poured in.
So instead of using one efficient, smart programmer for a while, then limited support after that, they had a team of (cheap) very nervous programmers, furiously coding away, terrified lest they break something. And yes, there were layers and layers of software, each overriding the other as the new programmer didn't understand the original system, so added their own. Palimpsest, anyone?
And yet, despite my offers to rebuild the whole thing this way (including demos), management loved it. Staggering.
But I still like to keep things simple. And yes, my name is Simon. And yes, I do want a new job.
"Cats like plain crisps"
So now Taco Bell is a reference for both cooking and programming ? I ate there exactly once and it tasted like sucking ass off a dead donkey. I pity the people who've been forced to eat there since a young age and now think this is 'food'. Yeah, flamebait, etc...
Non-Linux Penguins ?
Unexpected comparison of trained coders / developers, many with certifications and degrees, to untrained sub-GED Taco Bell employee... well... frankly, knuckle-draggers.
Also, I don't care if your code is minimal and profitable, if it gives me a sore stomach as Taco Bell does, I'm opting for something more complex and just... better. Better for me, better for everyone.
I get the appeal of promoting minimalistic coding styles with food concepts, and it's a refreshing change from the raggedy car analogies... but come on. Taco Bell? Really??
There's a spot in User Info for World of Warcraft account names? Really?
Well, actually left, left, left.
If the goal is to provide high level primitives that can be aggregated to meet the requirements of a specific task ... It would seem to me this boils down to being so obvious as to not be worth stating.
Is it not always in the best interests of the designer to seek to use the best tool for the job?
Using a shell script is not better than writing a perl program to accomplish the same goal. There are only syntatic differences in how the solution is encoded. Architecturally there is zero difference.
I am wary of examples derived to fit nicely into a pardigram.
Shell programming tends often to break down very rapidly when there is a need for domain specific data processing. It is great for sorting, filtering or aggregation of results unfortunatly not so much beyond that.
I would agree with the statement high level RAD design tools are underused and undervalued in general.
I once had a pair of command line tools that both printed lists of words (usernames, actually, one per row), and I wanted to find out how many unique ones there were. Obviously, the right hand side part of the pipeline was going to be something along the lines of " | sort -u | wc -l", but then I got utterly stuck by the left hand side. How can I combine the STDOUTs of two processes? Do I really need to resort to using temporary files? Is there really no tool to do the logical opposite of the "tee" command?
You are probably thinking: "Oh, you silly person, that's so trivial, you must be very incompetent", but in case you aren't, you might want to spend a minute trying to figure it out before reading on. I even asked a colleague for help before realizing that the reason I could not find a tool for the task was quite an obvious one: such a tool does not exist. Or actually it kinda does, but only in an implied sense: what I was hoping to achieve could be done by the humble semicolon and a pair of parens. I only had to put the two commands in parens to run them in a subshell, put a semicolon in between, so one will run after the other is finished, and I was done. I guess it was just that the logical leap from "This task is so simple, there must be a tool for this" to "just run the commands one after another" was too big for my feeble mind to accomplish.
So I guess the moral of the story is, even if you want to use just one simple tool, you may be overthinking it :-)
I read the linked Devops article and know even less about than before I read the article. It's full of management buzzwords and I'm sure a CIO would love it, but what does it mean?
How does Devops help?
The Devops movement is built around a group of people who believe that the application of a combination of appropriate technology and attitude can revolutionize the world of software development and delivery.
Beyond this multi-disciplinary approach, the Devops movement is attempting to encourage the development of communication skills, understanding of the domain in which the software is being written, and, crucially, a sensitivity and passion for the underlying business, and for ensuring it succeeds.
oh yeah, that clears it up. All it takes is a passion for the underlying business and it's sure to succeed!
This is why I hire generalised experts, not specified experts. The wider the knowledge set of a developer, the better holistic solutions they can provide. Have an oracle dba? Every problem is solved with oracle. Got a java-only dev? Everything solved in java.
Tool sets and solutions on a large/broad project are often solved best with a broad range of technologies understood and built by a team.
If your software project is comparable to crappy fast food then your doing something wrong. Code obesity is killing our kids! On a more serious note, if you're reusing code you may be bringing along a lot of unnecessary fat that you really didn't need to. If you really want a lean mean program you will not be bringing in feature-laden libraries, you'll have to rewrite some stuff yourself.
The very top chefs and cooks will use 5-8 ingredients at the most to make dishes, they understand the importance of simplicity. A few really good ingredients combined expertly is by far the winning strategy. Something like a McDonalds hamburger will have dozens of ingredients when you count all the additives, without which it would be unpalatable.
I've seen some pretty impressive meals with even less ingredients. I worked in a restaurant that perhaps had no more than 20 ingredients on the entire menu at a time, if you exclude condiments.
Seasoned programmers will cook code with color and flavor, not coloring and flavoring.
After logging in slashdot still does not take you back to the page you were on. It's been that way for 20 years.
Shell scripting is fine for stuff that *only you* are going to use. It's just not robust enough for use in anything important, that more than one person might actually use. For example, handling paths with spaces is pretty damn hard - loads of scripts can't handle them.
...by mixing-and-matching roughly eight ingredients
Funny thing, there: it's more like hundreds of ingredients, if you count an ingredient as... well, an ingredient. Hell, even their "tortillas" alone probably have at least three different kinds of preservatives in them. Sure they'll kill you... but hey, in theory your corpse won't need as much embalming if you need enough 7-Layer burritos!
Mexican food's great, but it's essentially all the same ingredients, so there's a way you'd have to deal with all these stupid questions. "What is nachos?" "...Nachos? It's tortilla with cheese, meat, and vegetables." "Oh, well then what is a burrito?" "Tortilla with cheese, meat, and vegetables." "Well then what is a tostada?" "Tortilla with cheese, meat, and vegetables." "Well then what i-" "Look, it's all the same shit! Why don't you say a spanish word and I'll bring you something." - Jim Gaffigan
Software development is a craft with already half-a-century of knowledge, full of characteristics of its own. We should stop trying to adapt examples of other craft/engineering/whatever and focus more on ours. We already have some good ideas of what works and what doesn't, and running to the methodological fad of the week is one that doesn't.
Frankly, getting ideas on how to program from how Taco Bell cooks its food? I wonder if I would ever bother to ask cooking tips from RMS.
Once, about 20 years ago, I worked for a company who's line of business generated a VERY large amount of data which for legal reasons had to be carefully reduced, archived, etc. There were various clusters of VMS machines which captured data from different processes to disk, from where it was processed and shipped around. There were also some of the 'new fangled' Unix machines that needed to integrate into this process. The main trick was always constantly managing disk space. Any single disk in the place would probably have 2-10x its capacity worth of data moving on and off it in an given day. It was thus VITAL to constantly monitor disk usage in pretty much real time.
On VMS the sysops had developed a system to manage all this data which weighed in at 20-30k lines of code. This stuff generated reports, went through different drives and figured out what was going in where, compared it to data from earlier runs, created deltas, etc. It was a fairly slick system, but really all it did was iterate through directories, total up file sizes, and write stuff to a couple report files, and send an email if a disk was filling up too fast.
So one day my boss asks me to write basically the same program for the Unix cluster. I had a reputation as the guy that could figure out weird stuff. Even had played a small amount with Unix systems before. So I whipped out the printed Man pages and started reading. Now I figured I'd have to write a whole bunch of code, after all I'm duplicating an application that has like 30k lines of code in it, not gigantic but substantial. Pretty soon though I learned that every command line app in Unix could feed into the other ones with a pipe or a temp file. Pretty soon I learned that those apps produced ALL the data that I wanted and produced it in pretty much the format that I needed. All that I really had to do was glue it together properly. Pretty soon I (thank God it starts with A) I found awk, and then sed. 3 days after that I had 2 awk scripts, a shell script that ran a few things through sed, a cron job, and a few other bits. It was maybe 100 lines of code, total. It did MORE than the old app. It was easy to maintain and customize. It saved a LOT of time and money.
There's PLENTY to recommend the KISS principle in software design. Not every problem can be solved with a bit of shell coding of course, but it is always worth remembering that those tools are tried and true and can be deployed quickly and cheaply. Often they beat the pants off fancier approaches.
One other thing to remember from that project. My boss was the one that wrote the 30k LoC monstrosity. The week after I showed her the new Unix version, I got downsized out the door. People HATE it when you show them up...
"Malo periculosam, libertatem quam quietam servitutem." -- Jefferson
So what does McDonalds programming look like?
soylentnews.org Go there to enjoy the people!
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
Brainfuck has just eight commands. Coincidence?
In all seriousness, in pondering the success of In-n-out, a number of things have come up. The simplicity of the menu is part of it; but other things too.
Simply selling few items won't help you if those items are absolute crap. Otherwise, we'd all be eating at Taco Bell every night, discussing our latest Brainfuck coding project.
For all intensive purposes, "whom" is no longer a word. That begs the question, "who cares"?
... or write a tiny ruby script that does the same in the same amount of code, but resembling English instead of random stuff.
It's not Taco Bell. It's mexican food. Nearly all mexican food is made from just a few ingredients, mixed different ways.
yo quiero taco bell
I thought there were 6 - up, down, strange, charm, top and bottom?
Man who leaps off cliff jumps to conclusion.
No, it's up, down, sideways. sex-appeal and peppermint.
Quidnam Latine loqui modo coepi?
Sums up well where this comes from. Who's going to maintain that mess? Or to pick up your genderized metaphor, who's going to clean up after you, chef? There's a reason these tools with their arcane interfaces have become unpopular.
A big problem with shell programming is that the error information coming back is so limited. You get back a numeric status code, if you're lucky, or maybe a "broken pipe" signal. It's difficult to handle errors gracefully. This is a killer in production applications.
Here's an example. The original article talks about reading a million pages with "wget". I doubt the author of the article has actually done that. Our sitetruth.com system does in fact read a million web pages or so a month. Blindly getting them with "wget" won't work. All of the following situations come up routinely:
That's just reading the page text. More things can go wrong in parsing.
Even routine reading of some known data page requires some effort to get it right. We read PhishTank's entire XML list of phishing sites every three hours. Doing this reliably is non-trivial. PhishTank just overwrites their file when they update, rather than replacing it with a new one. (This is one of the design errors of UNIX, as Stallman once pointed out. Yes, there are workarounds they could do.) So we have to read the file twice, a minute apart, and wait until we get two identical copies. Then we have to check for 1) an empty file, 2) a file with proper XML structure but no data records, and 3) an improperly terminated XML file, all of which we've encountered. Then we pump the data into a MySQL database, prepared to roll back the changes if some error is detected.
The clowns who try to do stuff like this with shell scripts and cron jobs spend a big fraction of their time dealing manually with the failures. If you do it right, it just keeps working. One of my other sites, "downside.com", has been updating itself daily from SEC filings for over a decade now. About once a month, something goes wrong with the nightly update, and it's corrected automatically the next night.
The premise is to use the fewest number of ingredients, thus conceptualizing it in my terms is more efficient ;-)
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
Now can you? 'Nuff said !!
When Taco Bell says make a Run for the border, what that means is make a run for the toilet !!
RidinTheStormOutWaitinForTheFallout !!
I bet you think you're some fucking clever, don't you?
Taco Bell may only use 8 ingredients, but their food tastes like shit.
Personally I would advocate making a quality product, using only the best ingredients/techniques required for each particular menu item.
Over the years I've seen a lot of effort put into creating apps to do things that existing apps already do very well. It's done to learn how to write code in some select language or because someone thinks they can improve on older stuff by writing it in whatever language they fall in love with, adding a GUI, annoyingly verbose debug messages (and ZERO documentation) or add some annoying and recurring "Are You Sure You Want To Do Blah?" dialogs, or just because they grew up on Windows and the command line scares them. But in most cases the reinvented wheels do poorly, are too complicated, waste more resources, have more bugs, take more time to do stuff or have too many, um, "features". There is no need to waste time and effort to reinvent everything and stuff them into some all-in-one, monolithic app. Just need a bit of intelligence to make use of what is already there and already works. Work smarter, not harder. Stop wasting time and money on doing the same things over again and move on to something new.
Bugs do indeed create employment. One has only to look at the whole industry that sprung up around Microsoft and all it's crap products.
Yeah, while this may be a viable methodology in some cases (I'm certainly no expert, so I won't say for sure), the Taco Bell analogy seemed weak.
I listen to both RIAA and non-RIAA stuff if I like the music, tangential business/politics nonwithstanding.
..but on the other hand, Taco Bell makes taste-less, repetitive crap. The author is probably unaware of this, but part of the reason that Taco Bell is a successful company is because of the near-slavery conditions and pay that keeps their supply-chain costs extremely low: http://www.ciw-online.org/2004-05news.html If there is a lesson to be learned here, I think it's that you can be *economically* successful by exploiting lots of people and cranking out low-quality, low-cost products. That lesson works for programming as well - and that dynamic is part of the changing global market in that field. I think life (and programming) can be about more than just KISS Principles and profitability - right?
Psst,
" | sort | uniq -c "
Will sort and then count repetitive lines and output count, line. You can pipe the result back through sort -n if you want a frequency sort or sort -k 2 for item sorting.
Really it's components rather than ingredients, but Taco Bell does have more than 8
corn tortilla (variations)
cilantro
lime
sour cream
flour tortilla (a few variations)
chicken
beef
pork (at some locations)
refried beans
rice
tomatoes
cheese
lettuce
the four salsas (mild, hot, fire, verde)
and if one is forced to eat fast food, one can do better there than McD's shit
Brainfuck missed.
What part of "gestalt" don't you understand?
Oh, and to output a pipe to multiple processes you just need to use tee.
tee >(process1) >(process2) >(process3) | process4
After which you could use something to join the files back together. I've used such a syntax to pipe the output of an application over ssh while also taking a sha1sum without the need to save it locally.
Let me rephrase this concept from a programmer's perspective:
Unix Beard: "We don't need any programming staff! Anything requested by the business units can be done with a small shell script. GUIs are unnecessary. Analysis is unnecessary. All you need is a sysadmin!"
You old UNIX farts aren't the only people guilty of this sort of nonsense, either. I know a certain DBA that thinks all programming should be done in the database itself, BY DBAs, using stored procedures.
In BOTH cases, the subtext of the message is "Nobody should use any tools that are not provided on the command line, nobody should ever try to improve on what already exists, all this modern stuff programmers work with is scary and we old timers want everyone to stop using it and do things in a way we understand."
Pretty ridiculous if you ask me.
Let's make a new rule: We should all stick to what WE do, and leave everyone else alone to do what THEY do without constantly pestering them to let us expand our turf.
Thus spake the master programmer:
"When the program is being tested, it is too late to make design changes." (Tao)
It leaves results in your shorts.
His examples are find, xargs, and wget.
It's a sad day when "man discovers UNIX command line" is a headline on Slashdot.
Just wait until he discovers perl.
But it's true. Too many young and not-so-young programmers lack basic UNIX command line and Perl skills. If you get asked to perform a backend data processing, network, or system task, and lack these skills, the best thing you can do is admit that you lack these skills and ask someone else to assist. The worst thing you can do is to built an elaborate multi tier POS to solve such a problem, but I've known no shortage of contractors and hot shot developers who take this as an opportunity to do just that.
and it's about how ppl use their brain and knowledge
it's not about sth else......
Ted makes an excellent point. I once needed a tool to synchronise a text file which had transactional profile data. Simply using scp and some shell scripting I was able to achieve this. Only 25 lines of code too. There is a lot to be said for using the tools at hand versus re-inventing the wheel.
This task is so simple, there must be a tool for this
the tool is the shell. the tool is evidently so natural for you to use, that you forgot you were using it
I bet you think you some clever bot.
I have nothing to lose but my bindings.
This reminds me of an amusing text I read a while back, Academic Programmers - A Spotter's Guide, particularly the Unix Macro Magician. That being said, I think far too many people are far too willing to reinvent the wheel and wallow in complexity. It's as if some people think they won't be taken seriously or not be considered valuable if they create simple systems from pre-existing components. I always like to point out that Physicists get paid to make models as simple as possible; that's why they make some of the best coders.
Nathan's blog
In sh and derivatives, you type:
{ program1; program2; } | program3
The { and } enclose a block of commands that are executed in order. The block acts like it glues the standard output, error and input together. So you can do odd things like:
cat useless_use_of_cat.txt | { sort -u | sed -e 's/waste not/want not/g'; } | tail -1
This also works with the while and for loops. So you can write a loop that reads from a file with the "<" operator and pipes that to something else.
Don't forget that last ; before the }. It's an annoying one to forget.
"You cannot have a General Will unless you have shared experiences. You cannot be fair to people you don't know."
toco bell units are 486 dx systems. and they charge a arm and a lag for replacement parts. what there parts provider charges for a motherboard replacement toco bell can go buy new machines off store shelf's. in fact when i worked at toco bell me and the tec had a long chat bought how there provider was overcharging for parts. he said they where proptery and couldent get them elseware. so i pointed them to microatx towers that costed far less and where mutch more powerful then 486 machines. the store i used to work at closed due to it being in a dieing mall. and i think later the entire mall. but i have been in toco bells and notced they systems all have been replaced with modern touch screen interfaces. makes you wonder if they took what i said to hart and relised they where getting ripped off.
How about
( ( process_a &); process_b ) | sort | uniq
?
thegodmovie.com - watch it
Mix a bunch of stuff together and the only thing that it results in is a exploding stream of shit.
We can write those features in Java for you. But it might take another 6 months for you to work out all the bugs in a production system.
“Common sense is not so common.” — Voltaire
I develop exclusively on Unix & Linux, and I find that my peer developers have little understanding of the Unix way. They want to force things the hard way by writing a lot of code, rather than learning a bit about the utilities and services already provided. It is especially bad at places I work because there is a lot of kernel development going on, and it is often the case that there are kernel developers who can barely operate a Unix system. They often want to fix a problem by changing the kernel, which in a normal universe should make everyone nervous, but in my universe they get a pat on the back!
“Common sense is not so common.” — Voltaire
that only works if the two processes are writing to stdout a line at a time. otherwise their output will get mumbled together. the standard unix programs do write line-at-a-time, but you still need to be careful
Will be a pretty boring universe without leptons.
GAAH! MY PRINTER IS ON FIRE!!! PUT IT OUT! PUT IT OUT!
``The more I write code and design systems, the more I understand that many times, you can achieve the desired functionality simply with clever reconfigurations of the basic Unix tool set.''
I am glad he figured that out. Unix contains a lot of useful commands and functions. Every programmer would do well to learn them, so they can use them when needed.
What also helps a lot is knowing your programming language well. By that, I mean not just the standard library, but also the fundamentals of the language. Know how things fit together, which things are efficient and which things are costly, and how to design good APIs in that language. Better yet: know this for multiple languages - different languages for different tasks. It's easy to learn a new programming language when you already know how to program, and doing so will provide you with new insights, so go ahead and learn another language.
It is also useful to know tools and libraries that aren't a standard part of the operating system. Of course, there are very many of those and learning them all might be a bit much. Still, knowing a handful and having heard of others can help a lot. No need to write, debug, and maintain your own code for parsing CSV, XML, YAML, or whatever the file format of the season is. Beware of bugs and misfeatures, though. Many libraries, even commonly used ones, contain bugs. Many libraries also contain choices that may or may not be a good idea for what you want to do.
All in all, you can get a long way by just knowing what other people have already done for you. Thanks to free software, you can often use this work in your projects. The world wide web has made it fairly easy to find things that you may use. A lot of software can be made by taking a bunch of libraries and writing some code to stitch it together and make it do stuff. Or, as Mr. Dziuba found out, by mixing together some command-line tools. I am glad he is discovering the strengths of Unix and getting excited enough about them to tell the world about it.
Stitching things together from existing components is not all there is to programming, however. You can go a long way doing just that, and many people make a living that way, but there are some things which are best solved or can only be solved by thinking hard and coming up with some clever code to do exactly the right thing. And somebody needs to write those tools and libraries, too. Compared to putting some existing components together, it's hard work for small results, but I find this to be the most rewarding part of programming. You're really coming up with something new here, making something clever and useful that wasn't available before.
Please correct me if I got my facts wrong.
Summary: Bourne scripting can be pretty effective.
You finally made it! Welcome to the 70ies.
(Try building a system with simpleton commands like you show and you will eventually find yourself alone at night at the coffee maker. Trying to keep awake while solving yet another scaling problem. "Friends" feeling very sorry for you in their sleep.)
I hadn't the slightest objection to his spending his time planning massacres for the bourgeoisie... (P.G. Wodehouse)
Taco Bell programming fails when your needs extend beyond 'putting food on the table'. I love syslog, I use it every day. But it has numerous limitations:
1) each log entry has a very limited size. For most needs, syslog is enough. But what happens when you want to svae 100,000 characters of input? At this point, syslog fails.
2) You need High Availability - Unix is all about a single system, when you have a cluster of operations that scale in need beyond a single system, you have trouble.
That said, the point is well taken! Use the appropriate tool for the job!
I have no problem with your religion until you decide it's reason to deprive others of the truth.
So you admit to being a 2-bit programmer? :)
Who thought of that stupid idea? My job is to keep the servers running. My job is NOT to make sure the developers write good code.
-- Will program for bandwidth
Your link is to them ENDING their boycott... in 2004... so not sure what your point is there.
and get rid of this namby pamby hippy OO crap :-)
and replace all this bloated xml - what wrong with Holerith statements.
How can I combine the STDOUTs of two processes? Do I really need to resort to using temporary files? Is there really no tool to do the logical opposite of the "tee" command?
You are probably thinking: "Oh, you silly person, that's so trivial, you must be very incompetent", but in case you aren't, you might want to spend a minute trying to figure it out before reading on. I even asked a colleague for help before realizing that the reason I could not find a tool for the task was quite an obvious one: such a tool does not exist.
Google for the term "named pipe". Shove both files into the hole, pull one file out.
"Science flies us to the moon. Religion flies us into buildings." - Victor Stenger
Wow, programming strategies based on a strawman (re Taco Bell) argument. Has "win" written all over it.
The gist of article seems to be that for many tasks people should combine the powerful Unix standard commands like find, grep, xargs, sed, etc instead of writing dedicated programs in lower level languages such as Ruby, Python, Java etc. This idea is not new, and many of the people around here have heard it 15 or more years ago. Being a developer, I always liked the perspective of having to write lesser code.
However, the Unix command line and shell script approach never really worked for me, especially if other people in the team wrote them. The main reasons for that are:
All of this could be overcome by measures such as checking $?, redirecting stderr, using temporary files, configuring encodings properly, documentation comments and so on. However, this rarely ever happens in practice.
For the past couple of years I have been using ant for many tasks formerly delegated to shell scripts. Its main advantages are:
Of course it's not perfect. For example, it uses XML and consequently contains some syntactic noise, it lacks advanced string operations, there are no pipes and sometimes seemingly trivial things result in a lot of messing around with properties. Nevertheless I rarely see a need to write shell scripts anymore except for simple launchers. YMMV but despite ant initially being a build tool for Java developers, we use it for many sysadmin-like tasks with great success and a small amount of development time.
No no no, you're still thinking procedurally!
You shall see a cow on the roof of a cotton house.
I thought there were 6 - up, down, strange, charm, top and bottom?
Try to build an electron with that...
Channels, Adapters, Routers, Filters, Transformers, Splitter/Aggregator, Delayer, Bridge?
Very original.
There's some things shell scripting can do well, and there many things it can't do well - writing large complex programs that make it easy to drop in new functionality without changing existing code is one of them.
I thought it was up, down, left, right, B, A, select and start?
That's exactly right.
In related news, I believe that people don't like shell scripts for what amounts to aesthetics. If you think a custom-rolled 30K-line C app built by some in house programmer is somhow inherently more robust than what an experienced unix geek throws together, please explain which is more likely to change in the next apt-get:
The original article by this Dziuba guy is typical of new geeks that suddenly discover the wisdom of Unix design - he knows he's clever, and thinks he's now way more clever because he noticed that pipelines make sense. In ten more years, he might learn to be a bit more humble. Old bearded unix geeks who seem really smug to new hotshot coders who are going to change the world are smug for a reason.
I forget what 8 was for.
Lines of code is a rough measurement for the amount of work you put into a project. There are coefficients for which language you use, and some minor adjustment for coding policy.
But more importantly, it's a measurement of FAILURE. The more work you put into a project to get it done, the worse you are as a programmer.
Do they use strange, charm, top and botton at Tacobel now? Those literaly blow!
Rethinking email
I love it, someone after my own heart.
Yes, I'll skip the kewl k1ds who make jokes about 8 bits, and read what he's saying.... In the early nineties, I was helping a sr. staff scientist where I worked pick a GIS for the company. One was something called APE 3, from several universities. I cracked up when I saw it running: there was a window on one side, and you could drag and drop... and all it was doing was GUI-ifying std. Unix pipes and filters.
These days, I'm sure you need Sup3rK3wl with GUIness, which can only run an a graphics card suitable for the next generation of games....
Too many just don't pay attention to what tools are already there, just like folks didn't (and still don't) look at what functions are in the std. libraries.
Say it, brother.
mark
Comparing the OSI model of networking to a 7 layer Taco Bell burrito
http://pablotron.org/files/7_layer_burrito.html
This is not my sig
Left, Right, Left, Right, B, A, Select, Start
https://www.eff.org/https-everywhere
Psst,
" | sort | uniq -c "
Will sort and then count repetitive lines and output count, line. You can pipe the result back through sort -n if you want a frequency sort or sort -k 2 for item sorting.
The problem was not figuring out how to count the unique items. It's the part before the pipe that was difficult. The poster needed to combine the results of two different commands and then compute the unique items. The solution would have to be, logically, "command1 + command2 | sort | uniq -c".
Unless you can find a way to pass the output from command1 through command2, you will lose command1's data. The solution he/she found was elegant: (command1):(command2) | someKindOfSort. My syntax is probably wrong. If you were simply pointing out a better way to sort, then please disregard.
Correct syntax would be (command1; command2) | command3, which is what was described in Meriahven's post.
he was an idiot when he was sewing his nonsense on The Register
Now he's here.
Another nail in /.'s coffin
I agree with the general sentiment of "you can solve a lot of problems just using UNIX and not big fancy things." That doesn't really have much to do with the random DevOps swipe and shows a fundamental lack of understanding of it.
DevOps grew out of a couple major needs. The first is for developers and sysadmins to collaborate more. Do you like the old practice of "developers make it all happen, and toss their demented creation over to you a week before go live and say 'figure out how to make this run in production'"? As developers have largely uptaken agile development methods, it's gotten even harder for traditional sysadmin teams to work with them to make sure that the end system is going to have good availability, performance, security, etc. I don't think a desire to have operations folks engaged from conception with products/projects to be "sucking up to the developers."
The second is to advance the state of the sysadmin practice. It has stagnated somewhat in recent years. It's not old tools that are the problem (again, yay UNIX) but the processes and practice - structured process turned into the huge unusable beast called ITIL and so many admins have apparently decided that the way they do business really shouldn't change from the 1970s. But Visible Ops, the agile systems administration movement, the growth of automation tools like Chef/Puppef/cfengine, etc. mean that we need to bring system administration up to the same level of professionalism as programming can achieve. Why exactly should your sysadmin scripts not be source controlled? Why should you not write tests - not for others' code, but for yours? Why shouldn't you automate system builds like code builds, even moving to continuous build cycles? In the increasingly virtualized/cloud world, "infrastructure as code"
Here at National Instruments we have a DevOps implementation to develop some new SaaS products. It's a single team with developers and sysadmins on it. Provisioning and monitoring are built into the apps from scratch. All our sysadmin stuff is kept in source control. We script things rather than doing them by hand. Developers write unit and integration tests for their code; admins write unit and integration tests (we call them "monitors") for our assets. We all work in iterations and work tasks on a burndown chart. Bugs in the systems are tracked in the same system the developers use. All of our systems get built and booted and have software and apps loaded on them completely automatically. And that's awesome! Sure, it's not the good old "lurk like a troll in the back room and make developers cry when they come around" model, but you know, different strokes I guess.
diff -uN file1.out
sort -u file2 > file2.out
diff -uN file1.out file2.out
I read both the articles, and this is what I gathered...
The guy who preaches the Taco Bell model, in his own words, he is using a few simple components strung together to make complex applications. The utilities he refers to are probably not news for anyone who ever read Slashdot. He comes off very much like the guy who would re-invent a square wheel, rather than learn and use newer tools that might just be even better suited for the job. The irony is, he isn't really thinking outside the box. Nor does he have the experience to even comment on software development or systems management, as he points out "this is a path that I am just beginning."
I've got nothing against the thousand of simple Unix tools which can be chained together. But I also know there are limits to what you can do with those tools. The DevOps guy calling for a shift of thinking in I.T., in my opinion is hitting close to home. Read both articles, and seriously tell me who you would rather have on your team? On the one hand, you've got Taco Bell dude who just wrote his first Shell script. On the other hand, you've got the more experienced guy who you may not agree with, but just maybe he's on to something.
/^([Ss]ame [Bb]at (time, |channel.)){2}$/
Clever is a taboo word in programming. Anyone who's spent hours debugging a bash script, or hours searching google trying to figure out how to do something in SQL that would take 3 minutes to program in a programming language, would know this.