I’m testing out how to serve up videos for this Projects The Hard Way blog and I’m finding that most solutions kind of suck, but the best one of all the suckle is VimeoPro. To test it out, I’ve uploaded the video for Exercise 26 of the soon to be released Learn C The Hard Way that shows me implement the logfind project in C. This exercise is the full exercise video, and you can view it at videos.projectsthehardway.com where I’ll be posting them.
Vimeo, in their infinite stupendous wisdom have decided that the default video format for VimeoPro profile pages is the lowest quality possible. That means by default you will see grainy text and it’ll look like crap. I’m sure there is some option, deep in the bowels of this weird profile UI that says, “Hey, show all my videos at HD quality by default.” But, I can’t find it, so make sure you click the HD button on the vimeo player if you can’t stand grainy text.
Why C First
There’s been a few folks who wanted these projects implemented in different languages other than Python, so I think I’ll try to do both in C and Python if the projects allow for it. Since I already had this video from the C book I decided I’d put it up as a first test and to show people how I might do a similar project in C. I’ll do another video showing me implement the Python project in real time, with a voiceover talking about how I’m working.
My idea with the videos, which I did in Learn C The Hard Way is that I hacked on the projects the way I actually do them. When I code a project I don’t sit there and narrate while I code. I just code. Usually at a coffee shop with annoying music and people reading poetry. I decided I’d go to my usual place and work on the project like normal, and record everything I did, mistakes and all. Then the video is a real account of how I would really build it, but just watching me code is rather boring and doesn’t tell you what I was thinking. To augment the video I then perform a voiceover talking about my thought process at the time and why I made certain mistakes and how I might have done things better.
The video I just posted isn’t done in this style since it’s a simpler project and I’d already done it a billion times before. Instead this video is broken down into each discrete step, and then I talk about the code for each step.
Please watch the video and drop me a comment either here, on the video page, or email firstname.lastname@example.org and I’ll review them and adapt the videos for the Python recording. Keep in mind that you may not know C, so just watch how I explain how I did each step and then wait for the Python project to drop.
Hello everyone. I have a couple of Projects The Hard Way announcements for you to read. First off, if you register your copy of Learn Python The Hard Way you’ll get a copy of one of the videos from my Learn More Python The Hard Way where I did a live class showing how to create a series of small projects in Python. The class was the first foray into doing project based books and will be continued with this blog.
Second, InformIT is selling Learn Python The Hard Way for $14.99 today so if you haven’t purchased it yet then you’ll need it to keep going with the projects I do on the blog.
Third! I have just finished putting together the final videos of Learn C The Hard Way which you can pre-order now for the August release. I put in a huge amount of work on the videos, so I’m hoping they kick ass and help lots of people get very good at writing and debugging C code. Really the whole book is about breaking, hacking, and debugging C code.
Lastly! Since I had so much fun doing the videos for LCTHW that demonstrate breaking and debugging, I’m going to be doing each of the projects on this blog in both Python and C. That way you get to see them created in two languages, and then I’ll use the C projects to create a whole series of videos on debugging C code. I really feel like there’s not very many good resources on how to actually break and fix code, and C is the perfect language for teaching that since it’s both easy to break but difficult to debug.
Now that my videos for the C book are done I’m going to start the projects back up and show everyone how I’d make the logfind project in both Python and C. This will be a video post, so I need to find a decent video hosting service and then I’ll have something for everyone soon.
The first project that we’ll try is called logfind. It’s nothing more than a simple version of grep so you can learn a few simple basic things in Python:a
- Opening files based on regular expressions in a file.
- Scanning those files for strings from command line arguments.
- Create a complete installable Python project.
The purpose of logfind is to make it easier for someone on a computer to quickly scan all their log files without having to explicitly declare every file on the command line. Your job is to create a python project according to the LPTHW Project Skeleton that implements the logfind description and that someone else can install. Your score on this project will be based on how far you get in a week’s time, so I’ll tell you how to stage it so you have something working at all times.
The logfind tool is designed to let me find all the log files that have at least one instance of some text by just typing this:
$ logfind zedshaw
The results of this will be a list of all files that have one instance of the word ‘zedshaw’ in them, which I can then pass to another tool if I want.
The user level features I want for logfind are:
- I specify what files are important in a ~/.logfind file, using regular expressions.
- Logfind takes any number of arguments as strings to find in those files, and assumes I mean and. So looking for “zed has blue eyes” means files that have “zed AND has AND blue AND eyes” in it.
- I can pass in one argument, -o (dash oh) and the default is then or logic instead. In the example above -o would change it to mean “zed OR has OR blue OR eyes”.
- I want to be able to install logfind on my computer and run it like other projects. However, don’t push this to PyPI as that’ll really annoy people.
- Extra bonus points if you can let me specify regular expressions as things to find in files.
- Finally, speed counts, so whoever can make the fastest logfind will win the prize. The prize is nothing, but you know you want it.
There are a few developer level features you should attempt:
- Make sure you include automated tests. In fact you may want to create skeleton tests that have each of the above features and then work toward those. A good “automated test” to start with is a simple test_logfind.sh file that just runs your local bin/logfind with different parameters. After that make Python automated tests as described in LPTHW Automated Testing.
- Using argparse for the options, which is honestly overkill at this point but is a good additional exercise.
- Writing a README.md file.
- Posting it to GitHub and using git from the beginning.
Scaling Up Slowly
That is a lot of work for someone who’s just an early coder and not very experienced. How can you possibly tackle this and get it all right?! By scaling your project up slowly a piece of a time rather than do the whole thing in one slog. Here’s how you do that:
- Turn the challenge into a TODO list then refine this list with more tasks you think you’ll need to do to complete it.
- Take the list, and start with the simplest thing you currently know how to do. I’d say that’s creating a project skeleton.
- Once you have this first simple thing, what else can you do that depended on it or that is now open to you. Once you have a project skeleton it’s time to run git init . to get your git running. Once you have git running you can go learn about git. Once you learn about git you can go put it on github.com. There, you just knocked out three more tasks.
- Refine your TODO list further after you complete each task. Do you really need all those features? Take them off your list for now. Is there something you realize needs to be done now? Add it to the list.
- You then simply continue this process until you’ve either run out of time or have it working.
Clues To Come
This is the first challenge, and to give you a chance at tackling the problem with no help, I will stop for now. In the middle of the week I’ll post another post where I lay out a list of possible steps and clues for solving it, but not a solution. Then next week on Monday I’ll post a video where I demonstrate my solution and a github project for you to get and compare with mine.
Post a comment if you have questions, but keep in mind I’m trying to be annoying and make you solve this on your own first. I may ignore your comment until it’s clue time. You can also ask me at @lzsthw on Twitter.
I’m going to work on the next evolution of a book I need to write that presents a series of projects for early coders. The idea is that after you learn the basics of programming you need to work on projects. There are a few books out there that present challenges, but many times those are little puzzles or interesting math problems. There’s not many books that present problems that are approachable by early coders, but are a little more realistic.
I actually do not know how this book will shape up, and every time I sit down to work on it I’m honestly sort of overwhelmed by what I could present vs. what other people actually need. I feel like the best approach then is to simply present a whole slew of projects to interested people, and then see what projects shake out as the best ones.
The first projects on the blog will be simple copying of existing command line tools. It’ll be very simple, and anyone who’s learned the basics from my Learn Python The Hard Way or Learn Ruby The Hard Way you should be able to handle it. The solutions will be in Python but I’ll review projects in Ruby too.
During the course of this experiment I will try out a few different things:
- Using videos to demonstrate the projects and the solutions.
- Doing code reviews of select student’s projects in videos to show people how to critique code.
- Possibly starting a Slack chat for students.
I’m going to keep things simple at first and just write a few blog posts describing the first projects. These will be very simple to just try the format out and get it working.
Feel free to drop a (moderate) comment if you have ideas or requests.