Coding alone in a fog

March 1, 2008 9:46 PM

In my quest to learn Ruby, I'm struggling to find everyday usable code examples that i can relate to. Might you suggest some ?

Thanks to the helpful advice to my previous question, I went out and bought "Code" and "Ruby by Example" and am diving (or attempting to) headlong into learning Ruby.

Thats all well and good, but I'm hitting a comprehension wall. All of the examples I'm finding are not anything I can relate to. (meaning = I dont see how they apply to me or my everyday life, so as soon as I start trying to learn them, my eyes (and brain) gloss over and my knowledge absorption rate goes down to nil.)

I understand that "hello world", "rename all files in this folder", and things like "99 bottles of beer" are meant to teach me basic concepts and structure of the syntax, but because these programs don't produce any tangible result in my everyday life, I find it immensely difficult to care about learning them. ( I realize this makes me sound like a typical snotty highschool student, but hear me out)

So, my question(s):
1.) if you are a Ruby (or other language) programmer. Can you cite specific examples of code (large and small) that you've written that you use EVERY DAY ? (bonus pts for source code I can actually download and tear apart)

2.) Could you point me to online resources/repositories of code examples that are actually things I might actually use?

I realize the common advice is: "Just find some problem your interested in solving and code it!!!" (meaning = the MeFi crowd in general cant know what "everyday useful" means to ME), but I'm hoping someone has run into this same problem and found something that worked for them to relate coding to their everyday life. If it makes a difference, my everday job is working IT in a datacenter. Monitoring servers and connections, and responding to outages/alerts regarding said equipment. But that doesnt mean I want my Ruby code to simply be scripts aimed at IT Sysadmin work. I'd love to be able to (eventually) write fully fledged programs or web-apps that the public at large might find useful.

I think the frustration I'm feeling is not being able to find the "bridge" (middle ground) between "Hello World" and "Look!, a functional program/web-app". What I'm hoping for is someone can point me to medium sized Ruby programs or online apps and say "This was created entirely in Ruby, its an easy to use program that produces this tangible result."

posted by jmnugent to computers & internet (28 comments total)

For web apps you might look around for Ruby on Rails tutorial material. It shouldn't take much effort to write the web app equivalent of "hello world"; alternately, you could start with learning to write CGI programs, since that doesn't need any framework like Rails. For "fully fledged programs", you'll want to learn whatever the dominant Ruby GUI toolkit is on your OS. (I just started Ruby myself, so I'm not sure, you might look here).

I would think that working in a datacenter provides endless opportunities to improve your life by writing little scripts. Any time you find yourself doing an annoying and repetitive task, take the extra time to write a program to automate it...

For a real hobby project, you could try writing a web server starting with the sockets API. It's educational and satisfying.
posted by qxntpqbbbqxl at 10:08 PM on March 1, 2008

The problem is that you're not already writing Web apps, and most of the Ruby tutorials out there are about Rails. As a sysadmin, you might be more engaged by Practical Ruby for System Administration.
posted by nicwolff at 10:12 PM on March 1, 2008

If it were me, I'd start working with databases and put my actual information in there. As in, my friends' and family's phone numbers, my appointment diary, maybe my accounts? If you're balancing your chequebook or some other real-world task, I'm sure it will be a lot more meaningful to you.

The good thing about it is you can have a simple command-line app which does "what's aunt Ethel's phone number?" or "show me all the cheques I wrote in December 07" or "do I have any meetings next Wednesday?" which will be immediately useful, and then you can turn that code into a web app when you're ready.

It'll be the same basic code under the hood, you'll just have output via HTML and input via forms.
posted by AmbroseChapel at 10:51 PM on March 1, 2008 [1 favorite has favorites]

1.) if you are a Ruby (or other language) programmer. Can you cite specific examples of code (large and small) that you've written that you use EVERY DAY ? (bonus pts for source code I can actually download and tear apart)

I think you need to just bite the bullet and code up stuff that you won't use every day. Then maybe something someday will strike you as needing.

But generally software projects (in my experience) fall into the five following categories.

1) Toy problems to learn stuff
2) Simple utilities (equivalent to the 'rename all the stuff in this folder' in complexity)
3) Stuff assigned on the job
4) Large projects.
5) Games.

I've really only written one piece of software that I used every day, for a couple of years, and it was a huge project, involving a GUI and a web-based thing that many people used. But, I mean this project was gigantic. It's something I kept adding onto as time went on, but even the most basic peices probably took weeks and weeks of time. Probably 1,200 lines of code at least. I just did a line count on the project folder and the thing is 6,500 lines of code. The average programmer writes about 5,000 lines of code a year.

The project I'm currently working on is 17,000 lines of code, in 250 java files. I suppose if I ever get done, I'd use it every day. (It's a RSS/Atom reader that feeds into a blog search engine).

But basically if software is going to be useful, it's either going to be a very simple utility, or it's going to be a massive application. Those massive applications are great ways to learn, but you've got to get practice writing small applications or you'll end up tripping all over yourself on a big project (IMO).

You also might want to consider writing some simple games. When I was learning to program for the first time, that's kind of what I started with. Simple little games (like 'paper/rock/scissors/dynamite'), as well as simple graphical games. Doing graphics really gives you an immediate feedback about what you're doing.

Ruby/SDL is a library that (among other things) lets you do graphics. So, if I were you I'd try using that. However, I have no idea how easy or difficult it is (meaning how much configuration and fenagling it will take to get it to work)

Also, what is your skill level? Have you ever programmed before, in another language? What is it you want to do with your software? Is it that you just want to know how to program, or is it that you think programming would be helpful in your job?
posted by delmoi at 11:02 PM on March 1, 2008 [1 favorite has favorites]

delmoi:
"Also, what is your skill level? Have you ever programmed before, in another language? What is it you want to do with your software? Is it that you just want to know how to program, or is it that you think programming would be helpful in your job?"

My (programming) skill level is basically zero/nothing (I'm 35yrs old, the only programming I did was BASIC and beginning Pascal in high school).

Mostly the reasons I want to learn programming are: (in no specific order)

--it looks good on the resume

--personal satisfaction of being able to say " I understand that." (instead of being just a run of the mill IT guy who is only good at hardware/OS troubleshooting)

--because I hate having creative technical ideas, but not being able to implement them because I only have skills in 1 area. I'd like to be able to complete an entire application or web-based app by myself, gaining satisfaction in knowing I had all the different skillsets it took to complete each step along the way.
posted by jmnugent at 11:11 PM on March 1, 2008

Ruby isn't that different a programming language, as Python wasn't that different 5 years ago and PHP 5 years before that.

delmoi raises a good point or two. Have you programmed before? To me it doesn't sound like you've had a lot of programming experience. But ruby is as good a language as any to start with.

You might not have a specific need for an application, but perhaps your company, club or hobby could use some sort of app? it's easier to get started if you have a valid reason, and you've given undertakings.
posted by mattoxic at 11:15 PM on March 1, 2008

Get involved in an open source project. Any "functional" program/web-app is more complicated than you might think. Useful software doesn't just happen. Actually, it's kind of a miracle when it comes about. The best way is to start maintaining some simple, useful software to see just how complex it actually is.

On preview: if you have zero to no programming experience, you really need to learn the basics with some stupid examples. Write a calculator or a simple blog/cms. All great musicians started out learning scales and chords. You can't skip the basics just because they're boring.
posted by anomie at 11:25 PM on March 1, 2008 [1 favorite has favorites]

delmoi:
"But basically if software is going to be useful, it's either going to be a very simple utility, or it's going to be a massive application."

Thats pretty much the impression I'm getting,... and I think the frustration I'm feeling is that the "simple utilities" are not useful/applicable to anything I need.. BUT, I'm not experienced enough in programming to write a "massive application".

So I guess what I'm asking is, (as a programmer)... how do you make the leap from writing simple scripts, to writing something larger that is actually useful ?

Put another way..... Here are some apps that I appreciate the usefulness of :
--winamp
--Google Photos screensaver
--Yahoo Widgets
--Metafilter (whatever the backend code/database/engine is, I wish I knew)

I realize with no coding experience, I have no hope (anytime soon) of writing a fully fledged app, BUT obviously other people have gotten there, so ??...
posted by jmnugent at 11:31 PM on March 1, 2008

anomie:
"You can't skip the basics just because they're boring."

No, I definitely dont want to skip the basics. I do honestly truely understand that I need to grasp the fundamentals before venturing deeper into the programming forest. I know I wont have success later on down the road without doing this.

Thats the other part thats frustrating me. A lot of the tutorials/walk-throughs are so very dry and poorly written. Taking 10 pages to describe a function and all the various switches you can use with that function ----I'm lost or asleep by about page 2.

I realize that code and syntax by its very nature is dry and boring and "geeky"... but I dont understand why someone cant write a code instruction book that explains things more clearly in a way that conceptual/visual people like myself can understand.
posted by jmnugent at 11:37 PM on March 1, 2008

You need to make the jump from "simple utilities" to "simple systems." A file update script is a utility. A system to manage files and run scripts on them is a system. Storing the logs/history and implementing an undo? Even better. Software systems are exciting and powerful.

on preview: Why's poignant guide to ruby kicks ass. I believe the author is a fellow mefite.
posted by anomie at 11:42 PM on March 1, 2008

Here is another thing thats on my mental "wishlist":

I wish there was a text-based code editor that had the following functionallity:

1.) Color coding.
All of the various syntax, functions, arrays,etc are color coded in such a way so that visually, I can (more easily) follow the code. I think TextMate has this functionality and I downloaded a demo of it. Will probably buy it, since it seems worth it.

2.) the ability to "step through" my code.
I would seriously LOVE to see a code editor that would (line by line) step through my code and tell me exactly what the computer is doing at each step. That would help me visualize the flow of logic and help me understand how the computer is interpreting the instructions I've given it.

I think one of the reason I'm feeling lost right now is because I get no feedback as the code is running. All I do is write a program and submit it to the computer and wait nervously while the computer god decides whether it likes my code or not. That period of no feedback (while the program is running) is nerve wracking, especially when all i get back at the end is some cryptic error code telling me "error in line 344" , which sucks when line 344 is 100 characters long and I have to sit and dig through it for an hour to find my mistake.
posted by jmnugent at 11:47 PM on March 1, 2008

Another thing: you should never be bored with programming, once you learn the basics. If something is boring, figure out why. Chances are you can automate it. Follow that chain and you will end up with generalized, useful software.
posted by anomie at 11:50 PM on March 1, 2008

anomie:
"on preview: Why's poignant guide to ruby kicks ass. I believe the author is a fellow mefite."

Yep,.. Why's Poignant Guide is one of the tutorials I'm working through. On the plus side, its one of the better tutorials I've found for visual/conceptual people like me. It builds slowly and takes a light hearted approach. On the down side, I feel like he goes a little overboard with the cartoons and imaginary dialogue/examples, to the point where it becomes difficult for me to follow how it applies to my everyday reality.

I really wish there was a book that was halfway between Poignant and Ruby by Example. (with a little visual / logic-flow / feedback built in)

I swear to almight jebus.. if I ever have an epiphany moment and become comfortable with coding. I'm going to write that type of book.
posted by jmnugent at 11:52 PM on March 1, 2008

This isn't exactly the answer you are looking for, but when trying to learn a new language (and I suspect it works as well for any language at all) I've found Project Euler incredibly useful. The first few questions aren't that difficult mathwise (that comes later), but they are fairly short, self contained, yet still interesting puzzles.
posted by aspo at 12:17 AM on March 2, 2008 [1 favorite has favorites]

So I guess what I'm asking is, (as a programmer)... how do you make the leap from writing simple scripts, to writing something larger that is actually useful ?

Years of work? Of course for me it programming has always been something I've enjoyed doing, I started (using C, actually) when I was about 12-13. Thinking back, it would probably be 6 or 7 years before I could write a 'major' program on my own. Probably my first 'major' project was an IRC client applet, that I actually wrote for a job I got in highschool. I think it was like 800 lines, and I was pretty impressed with myself. Projects just grew in complexity over time throughout highschool and college. I suppose it helps to have lots of free time and no job to worry about.

That said, at the time I felt like I "could program" pretty quickly. It's only in retrospect that I can see how little I knew at the time.

But look, bite the bullet and do the toy problems. Set a goal of writing 1,000 lines of ruby code (in multiple projects if you want). then see how much you know and what you'd like to do then.

You also might want to take a look at Processing which is kind of like a programming language for artists, basically it makes writing graphical programs easy. That would probably be really helpful. Doing graphical programming was a HUGE help in learning to program, because you can see what your code does. (I just found this old Windows 3.1 game I wrote in 1996, heh)

Anyway, good luck.
posted by delmoi at 12:17 AM on March 2, 2008

I realize that code and syntax by its very nature is dry and boring and "geeky"... but I dont understand why someone cant write a code instruction book that explains things more clearly in a way that conceptual/visual people like myself can understand.

The Head First series of books from O'Reilly are very, very visual -- so much so that other programmers on my team radiate disgust when looking at them for the first time. I've only read the design patterns book, but I found it to be technically solid and a better introduction to the subject matter than the Gang of Four book, which is the industry standard.

I can't vouch for Head First Programming directly because I've only read the sample excerpt. But it looks to be in the same vein as Head First Design Patterns so it may be worth your time. One caveat: they use Python as their first language, not Ruby. This is becoming more and more common; even MIT is using Python for introductory courses nowadays. Python and Ruby aren't very different, and what you learn in one will transfer to the other pretty well.

The other piece of advice I have is to find a project that you care about -- something that you do every day that you'd like to automate. Check the same news sites in the morning? Wouldn't it be cool to go to one place and see all the top headlines? Or get email notifications of headlines containing key terms?

Maybe those examples don't grab you, but find something that does. Then break it down into little pieces, and write those pieces. If you find a piece you don't know how to write, find some code that does something similar (like send email or open up a web page) and see how it works.

The point is to find something you want to make. So long as you have a cool project, the code won't seem nearly as dry and boring.

2.) the ability to "step through" my code.

You want something called a "debugger". It will let you stop your program at a particular point and then take a look around, inspecting variables and so on. Each programming language has its own debuggers. I've never done a big enough Ruby project to need a Ruby debugger, so I can't make a direct recommendation. Google seems to think ruby-debug (project page, rails-centric tutorial) is the way to go.
posted by amery at 3:07 AM on March 2, 2008

All languages are made up of certain basic requirements. They need variables, which is where programs store data while it's being worked on. They need the ability to make decisions, and as a branch of making decisions, they need to be able to loop. They need to be able to do calculations on their data. And, finally, they need to output something. Most languages also have ways to input data as well, but that's not absolutely required; you can hardcode your input data in the program itself, although that's not often done anymore.

There's layers and layers of stuff built on top of those basic features, but at the core, that's pretty much what languages need.

The most fundamental rule: you assemble complex behaviors out of simple ones. All programming is puzzle-solving. You have a need for a particular output, and programming is solving the puzzle of how to get the output you need. You're hitting the early wall of not understanding the tools you've been given to manipulate data yet. Everything kind of hangs on everything else, and very early, you don't have the knowledge web you need to understand and remember things. If you don't understand why you NEED to make loops, the details of how to make one won't easily stick. You need hooks in your head to hang knowledge from, and screwing the first few in is quite difficult. Once you grasp some of the basic concepts, all of a sudden things will start to make more sense. I've helped a number of early programmers who expressed exactly what you're expressing.... and the ones that have stuck with it have all gotten to the 'aha!' moment. They learn very quickly after that.

It might help if you could give us an idea of what kinds of problems you're trying to solve. It sounds like maybe you're trying to understand Ruby well enough to know what kinds of problems you can solve, assuming that this will suggest what you should then do with your new knowledge. This is a lot like being taught about what a hammer does, or what a screwdriver does; those things themselves don't tell you how to build a table, or even suggest that a table is possible.

With modern programming languages, you can build almost anything you can imagine, but first you have to imagine something. If you can give us an example of something that's tedious and annoying about your present job, we might be able to give you suggestions on how to approach a solution. Having a clear goal will help you organize what you're learning and let you feel better about ignoring the vast quantities of stuff you don't need right at this exact moment. :)

And don't feel bad... it takes awhile to learn this. If you're starting from nothing, again.... getting those first hooks into your head, understanding how computers represent data and manipulate it, is painful. The pain and confusion doesn't last forever. It may feel like you're beating your head on the wall, but boy does it feel good once those bricks start to give. :)

A book that looks like it might give you data in the way you're asking is Ruby Cookbook. Safari is a pretty good electronic book service from O'Reilly, where you can have electronic books on a virtual 'shelf' at any given time. It's $23/mo for ten book 'slots', which you can swap out every 30 days, or $43/mo for unlimited slots, every book O'Reilly publishes. They have 31 books in the 'Ruby' category. And, of course, you can just buy paper books if you'd prefer.
posted by Malor at 5:20 AM on March 2, 2008

Sigh. Last paragraph, "where you can have some number of electronic books"... left out 'some number of'. Sorry.
posted by Malor at 5:23 AM on March 2, 2008

I'm thinking back to my undergraduate education in CS and I can't help getting the feeling you're going about this backwards, in trying to learn the programming language first. I think this might be leading to the frustration you are experiencing.

So instead of looking at programming books, I suggest looking at examples of how people go about trying to solve problems by writing a program. For example. this Peter Norvig essay on solving Sudoku puzzles provides a great illustration of how you go from problem to program, and the additional things you have to think about once you have your first version of a solution. I'd suggest reading that just to get an idea of the process, and not try to understand every single bit of code (the code is in Python, anyway). His essay on writing a spelling corrector is also great in this respect.

(BTW, Norvig is Director of Research at Google and is the co-author of the leading textbook on AI. His web site's full of fun thing's to poke through, at least for me.)
posted by needled at 5:40 AM on March 2, 2008

The Ruby Cookbook IS code examples. Each section is in the form of:

1. you want to do something.
2. This is one example of some code that does that (possibly using 3rd party libraries).
3. Here is a discussion of what each part of the code does.

It's not intended to be a straight-through read, although that is a good idea to see what kind of stuff is in there. This might not solve your problem (which I share BTW), but it's a good resource anyway.
posted by ArgentCorvid at 7:32 AM on March 2, 2008

Hi,

Ruby Quiz. I don't know if it's being updated anymore, but it was a weekly quiz (with answers) of toy and real programming problems. The answers are in Ruby, so you can do the apples to apples thing.

Will

http://rubyquiz.com/
posted by willhslade at 8:38 AM on March 2, 2008 [1 favorite has favorites]

re: syntax-coloring text editor

Any good editor will do this, even for Ruby. I recommend gvim - there's a bit of a curve to learn the basic editing commands, but it's worth it.

re: debuggers

For interpreted languages like Ruby or Python, the interactive shell is a valuable debugging tool. While irb isn't going to let you step through code line by line, you can interactively test and reload small parts of your program to make sure they're working. The kind of debugger you're talking about is usually in the realm of compiled languages like C or Java.
posted by qxntpqbbbqxl at 12:05 PM on March 2, 2008

re: syntax-coloring text editor

If you are writing ruby on a Windows machine, the all-in-one distribution comes with Scite, which does a pretty good job of coloring your syntax.
posted by ArgentCorvid at 1:36 PM on March 2, 2008

I'd write a blog. Ruby especially makes it pretty easy to get a web page up and running pretty quickly if you start with a framework like Merb and from there you can fiddle as much as you like, either with database backends or simple file stores.

Why (of the poignant guide fame) has a new app called Shoes which lets you do simple GUI-based stuff in ruby, that might be fun to play with.

Email in profile if you want to chat about this stuff by the way.

Why's a mefite? No way!
posted by Skorgu at 6:16 PM on March 2, 2008

Programming is problem-solving. Specifically, by breaking elaborate complex problems into very well-defined fragments and tackling them one by one. Short, mentally-challenging exercises like codegolf and the afore-mentioned rubyquiz will hone your problem-solving skills. They offer lots of problems to choose from, so surely something there will tickle your fancy.

Since you mentioned TextMate, do put that trial version through its paces before that expires. Its power goes way beyond syntax highlighting. If you can't quite remember a method name, you can pull up a list of candidates in one keystroke. With two or three keystrokes it can conjure up a bunch of lines of code ready for you to just drop in a variable name or two to finish it off. If you're unsure what a particular keyword's purpose is, or what parameters that method expects, one keystroke calls up its documentation. You can also create or combine your own customizations to extend TextMate's featureset. Pragmatic Publishing has a TextMate book that introduces you to a lot of features, and uses Ruby throughout to demonstrate how to further extend TextMate's featureset. Talk about a practical application: code yourself a TM bundle to streamline your work for the datacenter. Or adapt the TM blogging bundle to handle something like twitter.

(Do try ruby-debug as suggested. Also download the ruby-debug Textmate bundle. Handy for scripting.)
posted by nakedcodemonkey at 6:50 PM on March 2, 2008

I felt the same way when I was trying to learn Python. The author was a big into object-oriented code, the examples were a bit artificial and overly complicated since they wanted to show inheritance, overriding methods and all stuff. The author was focused more on software methodology than on getting stuff done. (Actually, a lot of books fall into this same trap of talking at great length about object-orientation methodology, and forget to explain why you should organizing things into classes and when you shouldn't bother.)

The keyword you want is "recipe". googling "ruby recipes" brought this up:

http://www.crummy.com/writing/RubyCookbook/

These are all more goal-oriented snippits. So perhaps thats more appealing?

Looking at your interests, you list window applications written in c (winamp), widgets (written in javascript) and database web apps like metafilter. (cold fusion?) If you want to build a web-app I'm wondering why you've chosen ruby. You could write a metafilter type application with ruby, but if you're using rails, but i'm wondering if the framework and structure that rails provides is more confusing than valuable to a beginner. I would suggest learning the basics about how variables are passed from the browser to the server and back. PHP is probably the easiest way to do this. (probably lots of tutorials on messing with GET and POST requests and HTML forms.) Then you need to look at SQL and how data is stored and retrieved from a database. Eventually, you wil get into CSS, Javascript, AJAX/JSON, and all the latest goodies, but you should able to build a simple web app with PHP and HTML. A recipe for web apps has been to simply make a web front-end to a command line tool. (I wrote one for mpg123, a cmd line mp3 player years ago.)

The flow of web applications used to be very screen based. The browser would make a request and the server would generate an entire HTML page in response. That's changing with ajax/json, which is much more of an event-driven model. Every click of a button, or mouse-over generates an event, which triggers a piece of code. The trick is how not to end up with a giant mess of spaghetti code - and this is where object orientation starts to be come important. but it's a good learning exercise to build an event-driven application without objects, realizing that it's full of bugs and a mess, and then realizing how objects clean this up. If you like writing graphical interfaces, i would suggest playing with javascript and widgets. every widget can be opened up and inspected to see how it works.

Maybe you can post some suggestions of a tool you'd like to write? The key part of coding is breaking down the problem into manageable chunks. I'm sure we could help you come up with an approach that would get you to your goal.
posted by kamelhoecker at 7:14 PM on March 2, 2008

Hello fellow wannabe programmer. I feel your pain. I started with Ruby because several Ask Mefi threads recommend it for newbies. Getting past the 99 Bottles program into something I'd actually use seems like a huge leap. I took a cheap community college class on Ruby for beginners. While not really enlightening, it was good to simply talk about programming with another human.

The past several weeks I've found a lot of satisfaction working with Processing. Previously mentioned in this thread. You mentioned you're a visual learner, so it may be a better fit. It comes packaged with many basic code snippets, which you edit within the editor and run again. I've found this method of learning helps a lot - to be able to go into someone else's code and play around with the variables or methods, then I can visually see the how those changes affected the result. You get the example, and then you can go back and learn how it works, with that example in mind. While Processing won't be able to make anything that would be a future goal, it might provide the platform for you to grow with.
posted by nemoorange at 2:52 PM on March 3, 2008

Thanks Delmoi and Nemoorange for the suggestion on "Processing"... that looks like a really good fit for my learning style. I'm hoping the visual aspect will help alot in teaching me concepts of OO programming. I also like the open source angle, and that I can browse code examples, download and review them, and tweak them to teach myself things. Very cool.
posted by jmnugent at 10:19 AM on March 5, 2008