This book is new. If you'd like to go through it, then join the Learn Code Forum to get help while you attempt it. I'm also looking for feedback on the difficulty of the projects. If you don't like public forums, then email email@example.com to talk privately.
Exercise 49: sed
You implemented a "baby version" of sed in exercise 9 when you were learning how to make quick and dirty hacks. In this exercise you'll attempt another exact faithful copy of the command. In the Study Drills of Exercise 48 you were tasked with creating a module from your ed implementation. If you didn't do that, then you'll need to do this for your sed command and have sed use it.
How is your process working out? Are you finding that it's helping you on these longer projects? Are there things you think you need to change? Have you been collecting metrics or do you feel that you are past that now? Take the time before you start this exercise to look through your journal and see how much you've improved since you started the book.
The challenge for this exercise is to take code from the ed project in Exercise 48 and reuse it in this project. The concept or "reusability" is central to how software works, but many times planning for reuse in a project leads to disaster. Too often people design software so that every component can be used in other software, but in doing so they merely overcomplicate the design with no real plan to use anything in any other project. It's better to make software that is discrete and stands on its own, and then pull pieces out that you can use when starting another project.
I typically write my software with absolutely no concern for reusability. I do not care if parts of the project will be used in other projects. I only care that this one piece of software works well and has high quality. When I start a new project I'll go look at other things I've written and see if there's anything I can use again. If there is I spend the time in the older project to pull out the part I can use into a module. This makes my reuse process look like this:
- Implement a fully working high quality piece of software with automated tests. Do not care about any part of it being used by any other software.
- Start a new project that might use code from the other project.
- Go back to the first project and pull the code out into a separate module, making this first project use it and change absolutely nothing else.
- Once all my original automated tests run fine with the module in place in the original project, I use the module in the new project.
- Finally, attempting to use the new module in the new project will find changes I need to make in the module. I'll make the changes and make sure they work with the original software as well.
You cannot do this without automated tests, so if your ed project didn't have tests I'm wondering if you've been reading this book or not. Go back and make sure you have full coverage of your ed project with your tests.
First you'll want to pull out the parts of the ed project that handle the commands and put it in a module that ed uses without breaking the tests. This will honestly be one of the hardest parts of this project since sed mostly just uses those but without the modal nature of ed's interactive interface.
Next, you'll either want to grab your old code from Exercise 9 and dust it off or start over from scratch on this new project. Once you have that decided you'll begin by implementing as much of sed as possible using the ed module. The creativity in this exercise is deciding what exactly is necessary for both projects to use, then placing that in the module.
Your goal with this implementation is to make an exact and faithful a copy of the sed comand. There is no creativity in this part of the exercise. Just try to be as meticulous as you possibly can and use automated testing to confirm that your command and the original sed work the same.
Finally, as you work on sed you'll find things you need in the module. You'll need to make the changes to the module, get them working in sed, then go back to ed and make them work there. This process of bouncing between three projects will be a challenge, so I suggest you keep to your 45 minute time chunks so you don't get burned out context switching.
- As you worked on the module were there any coding habits you found made it difficult to pull the code out? What are they?