#Things I googled for but didn't find - Atom Things I googled for but didn't find - RSS IFRAME: http://www.blogger.com/navbar.g?targetBlogID=3082589280007776602&blogNa me=Things+I+googled+for+but+didn't+find&publishMode=PUBLISH_MODE_BLOGSP OT&navbarType=BLUE&layoutType=LAYOUTS&searchRoot=http://mwilden.blogspo t.com/search&blogLocale=en_US&homepageUrl=http://mwilden.blogspot.com/& vt=1715335372190939973 skip to main | skip to sidebar Things I googled for but didn't find Tuesday, March 29, 2011 How to list all filenames except those in git repositories I wanted to see the names of all Vim source files in my ~/.vim directory. Because I use pathogen and submodules, there are a lot of .git directories under there, and I didn't want to list those. So I learned how to use the find command's 'not' operator, and it was easy: find . \! -path "*.git*" If you're curious, the reason I wanted to do this was to see if Vim authors typically use dashes or underscores to separate words in filenames. The answer: dashes (usually). Posted by Mark Wilden at 1:22 PM 0 comments Links to this post Labels: vim git find Saturday, January 15, 2011 Your product is not as important to us as it is to you I own a Mint. Is that a stupid name, or what? Especially when there's another hot product by that name which predates it. There's no way Mint will ever achieve the brand loyalty of Roomba, because its aficionados don't have a special word to use. I own a Mint. What's that?? A Mint is a Roomba for swiffing hard floors. And it's a great gadget, if pricey ($250). It quietly goes about its business, using a fixed infrared navigation beacon to build a map of your floor, chairs, stairs and other obstacles while it swiffs up the dust and cat hair. I really love it. The other day, the power went out. And the Mint, which was recharging, went berserk. It started beeping and flashing its lights in a realistic display of a machine frightened out of its wits. "I'm without power! Saaaaaave me!!!" Because, of course, in a major power outage, my first concern is whether my cleaning robot has enough charge left to swiff the bathroom. This behavior obviously made sense to the machine's designers. They reasoned that if you were recharging your Mint, you'd want to know if that function failed. But imagine if all rechargeable appliances behaved this way. You'd go around from appliance to appliance, calming them down, unplugging their chargers, whispering reassuring words... How does a design flaw like this happen? My belief it's because of the tunnel vision caused by working day and night on a product, putting your heart and soul into it. To you, it's the most important thing in the world. So you tend to forget that for other people, it's just a minor aid to keeping floors clean. It's just not that important to us. But that's not what prompted this blog post. It was this: [Screen+shot+2011-01-15+at+8.3702+++Sat+1-15-11.png] This is the output from a Ruby on Rails upgrade tool. It checks your project to see what you might need to change to upgrade it from Rails 2 to Rails 3. An excellent utility. But you can see that its designers too got caught up in the importance of their own work. If a message is important, why, let's display it in red! If it's less important, a subtle grey is best. And then let's use two more colors for other categories of information. This is the equivalent of using on an HTML page. Dudes, it's a commandline console. We're not playing Nethack here. We can read simple black and white. But we can't read this because it assumes it's being run on a terminal with a black background! (It doesn't look any more attractive on such a terminal, but at least you can see what it says). This mistake by the utility's designers arises, I think, from the same sense of the work product's self-importance shown in the Mint. In both cases, they were so focused on making their product useful that they didn't take a step back to consider it in the context of all the other products out there, of which their baby is just one. Remember, it may be the most important thing in your life while you're working on it. But it's not the most important thing in our life. Posted by Mark Wilden at 9:10 PM 1 comments Links to this post Labels: mint, roomba, ruby on rails Sunday, December 5, 2010 Why I love solo programming (and why I hated working for Pivotal) About a year ago, I wrote a post about why I don't like pair programming (and why I left Pivotal). This is the flip side. I've been working for the California Academy of Sciences for the past five months. I'm creating an NSF-funded website for ant taxonomists: antcat.org. It's the best job I've ever had in 25 years as a programmer. There are a number of reasons: I get to work at a museum where I can go and look at amazing fish, lizards, and butterflies every day, on a greenfield application in Rails, for an intelligent and easy-going boss, for an audience of scientists, in Golden Gate Park, ten minutes from my house. The pay is "only" 100K, which is less than I've made in quite a few years. But there's health insurance, and I get to work the tidepool exhibit a couple of times a week. But the #1 plus is that I work alone. I'm not proud of enjoying this so much. I'd much prefer it if I liked being part of a vibrant and innovative team - even pairing with them. But I don't. Quite simply, at this job I get to do things the way I want. That means 95% test-driven. It means agile - doing the simplest thing that could possibly work. It means adding Solr when I want. It means really learning Javascript for the first time. It means applying the lessons learned over a quarter of a century of experience in my field. And it means not having to argue about it. Maybe it's just been my bad luck, but I've never seemed to have worked with people who share my views on lean development, agile methodology, OOP, database design, or even structured programming. Views I've learned from reading people like Martin Fowler and Kent Beck. Obvious things that these guys just take for granted, like avoiding premature optimization, or following the single responsiblity principle. So my interaction with my fellow developers has always seemed to involve a lot of arguing. I've become much more diplomatic and polite over the years, and I'm much quicker to concede a point (after all, I might be wrong). But there comes a point where you get tired of being the OOP "purist" (I'm not). You just want to do it right. Now, I'm very aware of what I'm missing out on by working alone. My way may not in fact be right. I might not learn about other ways that I would end up embracing. I no doubt create more bugs. I sometimes make bad design decisions that cost me time. All these things would be tempered by working in a team, including pairing. And as far as pairing is concerned, I know for a fact that I'm not as productive as when I pair-programmed at Pivotal. We got some amazing results, just chugging through the feature list. The only problem is that I hated it. I also know that I seem to be arguing for the "cowboy coder" style of development. These guys are a real pain to deal with on a team. But what if there's no team? I know too that you'll hear this argument more frequently from members of my generation than the young pups who grew up on agile methods. All I can say is that I do tend to embrace the more leading-edge ideas - OOP in 1989, TDD in 2000, lean today. That's been the cause of many of my disagreements! When it comes down to it, I believe that the only intelligent criterion for behavior is happiness. The only reason for a person to do something is because it makes them happy (in the long or short term). The bottom line is that this way makes me happy. FOLLOWUP: There are a couple of things I mentioned in the original post that might have been missed if you just read this one: 1) I think pair programming is a great way of doing software development (just not for me), and 2) Pivotal Labs is an awesome place to work. Posted by Mark Wilden at 1:17 PM 19 comments Links to this post Labels: pair programming Saturday, December 4, 2010 Two modifiers in one statement (Ruby) I never tried this before, but I like it: return if shows.empty? unless show_if_empty Posted by Mark Wilden at 4:32 PM 0 comments Links to this post Labels: ruby Tuesday, November 23, 2010 Beware of RSpec's before :all When you add data in an RSpec before :all, it's not inside the transactions RSpec places around each test. rake spec clears the database before running all the specs, but the data created in before :all will hang around after it runs. This introduces an order dependency between specs. A spec that assumes the database (or one table) is empty will run fine if it runs before the before :all, but can fail if it runs after. Your specs can start failing just because you reorganized them, which changed their run order. I've been bitten by this three or four times. The moral is to not create data in a before :all if other code assumes that data isn't there. Posted by Mark Wilden at 11:53 AM 2 comments Links to this post Labels: rspec Sunday, August 8, 2010 Code gets cut off in blog posts When you put code inside 
 in a Blogger post, if it's too
   wide for its column, the excess just gets cut off. The solution is to
   use 
.
   Posted by Mark Wilden at 11:14 AM 0 comments Links to this post

Saturday, December 26, 2009

The Hidden Meaning of Christmas?

   [EMBED]
   This video purports to show that stories of the birth and death of
   Jesus Christ were based on astronomical events. I was not convinced.
   The first tip-off is when the narrator says "Sirius...on Dec 24th
   aligns with the three brightest stars in Orion's belt." Stars don't
   line up with each other on particular days of the year. They are fixed
   (for all intents and purposes). There's nothing special about Dec 24th.
   Also, the stars in Orion's Belt don't point directly to Sirius, as the
   video implies.
   The narrator then says that Orion's Belt and Sirius point to the rising
   sun on that day. This is just not true. The image below shows the
   relation of these bodies at sunrise on Dec 24, 300AD (around the time
   when the Christmas myth was created) at Jerusalem. The image is not
   substantially different on Dec 25, or even in the year 2009.
   Sirius and Orion's Belt on the right clearly point nowhere near the Sun
   on the left.
   The other main inaccuracy of the video (which is in fact its entire
   point) is that on Dec 25 the Sun rises in Crux, the Southern Cross.
   Apart from the fact that Crux is hard to see from the Northern
   Hemisphere, the image shows that the Sun is nowhere near the Southern
   Cross (center) at that time.
   Posted by Mark Wilden at 10:20 AM 1 comments Links to this post
   Labels: astronomy, christmas, jesus
   Older Posts Home
   Subscribe to: Posts (Atom)

Contributors

     * Mark Wilden
     * Mark Wilden

   counter for blogger

Links

     * My website
     * Facebook

Labels

     * rails (4)
     * mysql (2)
     * pair programming (2)
     * ruby (2)
     * vim (2)
     * aptana (1)
     * astronomy (1)
     * blogs (1)
     * c++ (1)
     * cache (1)
     * christmas (1)
     * feminism (1)
     * games (1)
     * gem (1)
     * git (1)
     * helper (1)
     * iMovie (1)
     * import (1)
     * jesus (1)
     * literature (1)
     * macvim (1)
     * mint (1)
     * oop (1)
     * orson welles (1)
     * os x (1)
     * pivotal (1)
     * prince of persia (1)
     * project (1)
     * roomba (1)
     * rspec (1)
     * ruby on rails (1)
     * sierra on-line (1)
     * subversion (1)
     * svn (1)
     * svn:ignore (1)
     * textmate (1)
     * time capsule (1)
     * tinytext (1)
     * vi (1)
     * video (1)
     * vim git find (1)