The “find” command, which searches directories for files, is great but requires a lot of options to perform a simple search. Usually I want to search the current directory for a specific file name, but doing that requires all this typing:
find ./ -iname "*my_search_term*"
What I would like to be able to is just type: f my search term
and have it match files that look like that. Here’s a little bash script I call “find.sh” that does it:
then just put the following in your ~/.bashrc alias f="/location/to/find.sh"
This script takes the arguments, converts spaces to wildcards, then does a case-insensitive search of the current directory. So “f foo bar” gets translated to find ./ -iname "*foo*bar*"
My bicycle route takes me out of Medford, through Somerville and Cambridge, and then across the Salt & Pepper Bridge into Boston. Crossing that bridge is like turning a video game up to Hard Mode — all the bike lanes disappear and suddenly there are double-parked cars to contend with. I ride fully alert and very defensively, so if a cab cuts me off taking a right turn I’m rarely surprised.
Today I biked in and, as always, it was smooth sailing until I crossed that bridge. On Congress Street there was a black SUV in front of me moving slowly and straddling two lanes. I could see through the rear window that he was on a cell phone. I employed my usual strategy and backed way off, giving him space to drive erratically, but he was moving so slowly that I had to pass him or stop. He drifted over toward the left lane and seemed satisfied with that choice, so I started approaching him on the right.
That, of course, is when he saw some sort of traffic ahead, slammed on the brakes, and took a hard right into my lane. I hit the brakes, which my bike has because I like being able to stop quickly. On the scale of 1 to 10, 1 being a light tap and 10 being a death grip, I had to apply about an 8 of pressure. Alarming, but not life-flashing-before-my-eyes. I’m stopped, he stopped, there is honking behind us.
(You may notice that so far we are in Regular Universe Boston.)
I’m someone that never honks in traffic because by the time I realize I should be honking the other asshole is already halfway down the block. But today I gave that guy the biggest finger ever and a loud FUCK YOU to go with it. And he saw it. At that point he did not try to run over me, so I was already feeling good about myself.
I took off, and soon a car pulled up alongside me with the window rolled down. I was ready for it: you asshole bikes shouldn’t be on the road, get on the sidewalk, etc etc. Instead I heard:
“Did you see that guy? On the phone! I don’t know how you guys do it.”
Then another cyclist rode up alongside me and checked to make sure the guy in the car wasn’t giving me static. I said something like “He’s being a good guy!” I found it hard to find words to express that the guy in the car was “being nice.” This is a very foreign concept and my language seems to have difficulty expressing the idea. The cyclist said the asshole in the SUV pissed off like three more cars behind us, and all that honking was definitely for him.
If a cyclist can get cut off — while passing on the right no less — and still get support from other Boston drivers, I have to wonder if I’m in the right universe.
Unfortunately for the Occupy protesters’ messaging, this guy is right: Boston Globe reporter on Occupy Boston arrests
Based on the videos I’ve seen, I pretty much agree. The Boston Police did show restraint, although that one guy just getting pushed over seemed unprovoked.
However: It’s clear that there’s a lot of propaganda coming out of the city now, between blaming the arrests on “anarchists” or evicting “to protect the plants.” It’s clear to me what this was: a show of force to tell Occupy Boston “we’ll let you have your little crappy plot of land next to the big ugly vent, but don’t think about getting any bigger.” The lawn next to Dewey Square was just a big barely-utilized field before, so who cares if a bunch of tents pop up for (as the city thinks) a couple weeks? But if they’d allowed the tents to remain in the next park, Occupy would have quickly outgrown that area and would have continued to move down the greenway. Occupy Boston is a manageable protest right now. If it remains manageable, nothing will come of it. Nothing will change if everyone’s still comfortable.
I attended a general assembly at Occupy Boston on Thursday night and I got to see, as the slogan goes, “what democracy looks like.” A week earlier I’d attended the initial planning session and thought the group was laughably over-organized. There were subcommittees, a series of hand gestures, and a complicated procedure for calling on speakers and making decisions. At thursday’s meeting the reason for all that process became clear: it’s really, really hard to get passionate individuals to stay on topic.
We spent an hour discussing (arguing would be too strong a word) whether to add a specific general idea to a list of ideas that will be considered for inclusion on a document in the future. That overstates things a little: a lot of the discussion was clarifying whether or not the specific topic would be announced right away, or if it would be held back until the whole document was done. The worry was that by announcing this single topic, the media would assume this was the primary concern for the group. This was an important discussion to have, and I think everyone was happy with the decision that was reached.
But it’s easy to see how, based on the rules of process, it will be hard to come to an agreement on actual details. Right now anyone can veto a proposal, and as the vague amorphous anger becomes more specific someone is going to be annoyed with the result. As an example, either the Paul-ies are going to be mad that Ending the Fed isn’t a major priority, or a non-Paul-y (like me) is going to be mad that Ending the Fed is a major priority. As long as a decision hasn’t been made, every protester assumes that the group agrees with him or herself.
The Boston protest is still in its early stages, and the facilitators running the meetings are still getting a hang of the complicated process. I think they need to have a stronger hand and make sure the process is going ahead as it’s been defined. Then, as the rest of the people learn the rules it will get easier to stay on topic. There are always going to be idiots who offer a “friendly amendment” as an excuse to inject whatever personal pet issue they are obsessed with, but they’ll just be like the annoying radio show caller that gets shut down quickly.
The support for the movement is growing daily, with unions, (more unions), ice cream manufacturers, and general folk of all stripes joining up. And with a high degree of tolerance coming from the Boston Police, I think Occupy Boston will have the time they need to mature.
Two posts in one day? This will really skew the average. I recorded a new mix in anticipation of… something fun happening later this summer. I kept this one on the shorter side, under 50 minutes. My mixing (in a technical sense) is getting better, I’m at the point where there are some little drifts but I pull it back fairly quickly. On the creative side, there’s one track that sticks out as not quite fitting in with those around it, but it’s not a huge problem.
Tracklist:
Knobs – Reality
dml – forstenried
Truncate (Audio Injection) – Truncate.16 – Original Mix
The last time I used my neato binaural microphones was 2006, and that makes me feel guilty. Every so often I find them in a drawer and think, “I should really use these sometime.” During the last huge thunderstorm I tried to use them, but by the time I figured out how to record audio on linux (yeah, I know) the storm was basically over. Tonight it’s raining again and my recording system works. And since we live next to the train, I made sure to check the schedule first to make sure a train would pass while I was recording. Now you, too, can pretend you live in Medford next to the tracks.
This recording should be listened to with headphones. That way you’ll get the full 3D-sound effect.
(ps, I don’t know who makes this little audio playback applet, but it’s great. I stole it from another web page, but if anyone knows whose this is, let me know.)
I’ve been doing more programming than usual recently, both at work writing scripts for managing video media, and at home working on the Mixxx DJ software. It seems 90% of my time is spent debugging, and the more difficult a bug is the more I find myself falling into an unproductive death spiral: try to fix the problem by tweaking a little code, recompile, test, fail, repeat. I’ll think that if I just change this one variable, or move this one bit code I’ll be done, but no it’s still broken and two hours later I’ve gotten nowhere. I keep having to relearn the same lesson: you can’t debug well if you don’t have good information.
Often my first stabs at debugging involves sprinkling print statements around my programs ((This article might be rendered entirely irrelevant if you work the Right Way, using debugging interfaces, stepping through code, and looking at live backtraces. But I suspect a lot of people start with print statements)). For simple problems this can actually work well, but as bugs get more tricky and complicated trying to analyze all that screen barf of can be difficult and a huge waste of time. It’s important to recognize when you’re not getting anywhere.
One problem I’ve been working on is the audio processing in Mixxx. When a DJ is using turntables to play music, and especially when they are scratching, the music changes speed radically, often in a tiny fraction of a second. The music will speed up, slow down, and reverse direction. The playback code has to mimic this bending, stretching, and warping that happens on an actual record player. If there are any errors in the math, it will cause ugly and unacceptable pops and clicks in the playback.
The old Mixxx code had a lot of clicks, buzzes, and pops. Certain playback speeds would cause noise, scratching would cause loud snaps, slow speeds caused rapid popping. I wasted several days trying to analyze those clicks by looking at printouts of variables, and only after I got to the point of complete frustration did I take a step back and think about how to attack the problem better.
I had been testing my code with actual music, and that was difficult because actual music often looks random up close — it’s hard to discern where the errors are in all that noise. So step one was to analyze data for the simplest possible case: a sine wave. Any errors would show up as large deviations from the smooth wave. This is a basic first step in making debugging easier: create a simple test-case. If you’re working on a huge data set, or a giant calculation, or a massive document, pare it down to the bare essentials necessary to reproduce the bug.
But even using a sine wave I couldn’t figure out what was going on. With 44,100 samples per second, there was too much data to analyze based on printed-out numbers. I recalled a bit in Michael Crichton’s “Terminal Man” ((This is why Google Books is a good idea)) that explains the problem:
“People,” Gerhard said, in mock irritation. “They just can’t handle machine data.” It was true. Machines could handle column after column of numbers. People needed to see patterns.
The book then proceeds to show both a list of numbers and a graph — the difference in readability is immediately apparent.
With some help from my dad and brother, both of whom often need to plot data, I was able to write a small script to display my debugging information: A graph of a vinyl-stretched sine wave
This was a major breakthrough: find the best way to visualize your variables. I’m working with audio data, so a plot is a good choice. It took me a whole day just to adapt my program to write the audio data to a file and to write a new program to display that data, but once I was done the errors showed up as obvious spikes in the graphs. Moreover, by the shape of the waves I could get an idea of why certain clicks were happening: an off-by-one error here, a rounding error there, etc.
The graph above shows several variables: the actual generated sound wave (green), a reference sample (red), playback speed (cyan) ((except that when playback speed is zero, I set it to -5000 so I can see it clearly)), and some other internal variables. If I see a spike I can look at the other lines and figure out where to start looking for a problem — the rate going from negative to positive (a record scratch), perhaps. The output above is correct — a smooth curve that is gradually brought back to zero when the turntable stops. (OK so that linear part at the end is not ideal, it should really be a curve — but otherwise it’s good.)
This is what the old, incorrect code looks like by the way. Notice the obvious errors in the graph, how the green line jumps up and down suddenly:
Bad Mixxx sound stretching
This method debugging could still be improved. I need to get up and scratch the turntable manually to generate data. Time spent triggering a bug is wasted. Every second you’re clicking around is time not spend debugging, which is why you need to make testing quick and easy. A bad test case is one that requires you click some options, open a file, manipulate some UI elements, and then eventually trigger the bug. An ideal test case would be a single command or button in the UI that performs a test. This keeps your mind focused on the bug, not on the boring, repetitive actions needed to trigger the bug.
Debugging is already a slow, painful process, and the prospect of writing extra code and programs just to debug your code can feel like superfluous work. But time spent writing good test cases and analyzation tools will more than pay itself back. Not only will you solve a bug more quickly, you may not have been able to solve the bug otherwise. It’s hard to get out of the tweak, recompile, test, repeat cycle, but you won’t get unstuck until you make your job easier:
Recognize when you’re not getting anywhere
Create a simple test-case
Find the best way to visualize your variables
Make testing quick and easy
With my Mixxx work, I still haven’t made testing quick and easy. I should probably write an internal test-case that loads the sine wave and performs a few basic scratches automatically. But even doing only two out of three of the steps got me out of the debugging death spiral.
I had a near-disaster experience while cooking last weekend and, because it wasn’t a disaster, made me feel like I had reached a new competence level when it comes to my cooking skills. In the past I’ve never been able to get a recipe right the first (second, third…) time. I would forget a stage of the process, or mis-time several parts so that by the time the last item was finished everything else would be cold. Constant practice has helped with those issues, but they never really go away.
Last Friday I was planning something fairly daring for me:
A recipe I had never made before
combined with a second item I had never made before
in a way that was my own idea
Normally this would be a movie with the sub-title, “A recipe… for disaster!“, but I felt up to the challenge. Specifically, I planned to make an Israeli cous cous gratin (basically a casserole) and top it with seared giant portobello mushroom tops.
Everything was going smoothly with the gratin, so once that was safe and in the oven I could switch over and concentrate on the mushrooms. I had read something on Salon about sauteing mushrooms, so I poured a bunch of oil in a pan and started to cook the mushrooms.
A minute or two in to the process, I did something that was very new for me while cooking: I realized that sauteing was not working. The mushrooms were gigantic, almost an inch thick, and they were just soaking up all the oil. They weren’t going to get cooked at all. Even a few years ago I would have just kept cooking them, hoping for the best. Instead I calmly determined my worst case scenario: I would have a gratin but no mushrooms on top. So it wouldn’t be the end of the world.
I think this realization (we’ll always have gratin) helped take the pressure off and freed me to do the second new thing, which was try to figure out, OK, how should I cook these things then? And quickly? The next logical choice seemed to be to try broiling them. That would be fast, and would cook them all the way through. Of course this solution led to yet another problem, because of course my gratin was already in the oven. Turning on the broiler would burn it. Still not panicking (well ok a little), thought, heh heh, it’s a casserole so I can just take it out for a few minutes, then put it back in when I’m done broiling. The dish will keep it warm.
Deciding this was the best option, I removed the mushrooms from the pan and put them on foil, then removed the casserole from the oven and put it on the still-warm spot on the stove (which would warm it better than nothing). I put in the portobellos, turned on the broiler, and prayed. As they cooked, it looked like the mushrooms were burning, but the calmer part of my brain realized they were just giving off steam.
A short few minutes later the shrooms seemed cooked, I served everything, and it was delicious.
I don’t think I’ll get to the point where I can create blends of spices and flavors of my own invention — half the time I suggest an idea Char looks at me like I’m crazy and explains that this doesn’t go at all with that. But I can make small permutations and adaptations, and I can mostly get something right the first time, and that’s better than I ever thought I’d do.
Across the country, elected officials in privileged communities are caught between a fervor to hold down taxes and a fervor to maintain good schools, well-paved streets, an ample police force, generous library hours and other premium public services that set a community like Bronxville apart.
Good schools, well-paved streets, an ample police force, and generous library hours: these are what constitute “premium services” in America, 2011.
