Fri
Jun
13

Things that annoy me in computing



Even to this day, these things exist. What gives?

  1. Browser inconsistencies - please, don’t get me started
  2. Non-secure login - there is NO GOOD REASON as to why I should need to log into your website without SSL. Most of you have it, why isn’t it the default? By you not redirecting me to the SSL version by default, you are telling me, “Our system resources are more important that your security.”. Thanks.
  3. State of Wireless - tell me again, why isn’t it fast, secure and absolutely everywhere?
  4. Network hopping - although this has gotten better it is still not idea. My computer/software needs to figure out which network I’m on and not on. And while I’m at it, if I have multiple available and credentials for all, then use them!

Argh!

Wed
Jun
4

My Commute via Public Transportation



I decided that I was going to take public transport (or, not use my car) to work, for several reasons:

  1. Inject a little activity into my life (as I use my bike or a scooter to get to and from the stops, etc)
  2. See if I can do anything productive during that time. FYI, I wrote this blog on the bus.
  3. My son loves buses and trains. As he gets older we’ll start to use them more on our weekend excursions.
  4. Just for fun and to see how long it would take vs. by car.
  5. Learn a little about my transportation options as well as roads I never drive down.
  6. If I can save a few bucks and help the environment too, why not?

Background

In the suburbs of Long Island, public transportation is mildly useful but totally uncool. It is not acceptable to not have a car, even if it is by choice. Now that I travel back to LI often, I’ve come to rely on PT (or, transportation other than my own personal car) I see how lousy it really is, which is probably due to the fact that only people who can’t afford a car (or can’t drive for some reason) use it for the most part.

Here in the Bay Area, however, that is not the case. People of all types use public transportation. It is definitely better than the bus system on LI, but not as robust and fast as the NYC system. It also gets confusing as there are several different transit systems here and depending on where you are and where you want to go, you may use more than one.

I use VTA as I’m traveling inside Santa Clara county. Plus, it is free for me to ride thanks to Y!.

Planning and Preparation

I used the public transportation feature of Google Maps for my initial planning. It is very cool, but not without its flaws. The VTA website and a paper-copy of the VTA schedule were my best friends during the week. Also, a big thanks to my co-workers for the advice and tips along the way.

My bike had been chained to my storage closet in my complex with the front wheel removed since I arrived here in CA, so on Memorial Day I decided to put it back together, cleaned it up and put air in the tires. The bike is nothing fancy - just a cheap Huffy I bought a few years ago. It has knobby tires that are made for dirt and makes a swooshing noise when I ride. But, I’m not a pro cyclist - I just need something to get me from point A to point B.

VTA fully supports using your bike for this purpose and describe what they offer on the bus and light rail here. In short, up to 4 bikes on a bus, 6 on the light rail.

I’ve already seen lots of bikes on PT - ten-speeds, old clunkers, mountain bikes, pro-bikes, BMX bikes, folding bikes, tandem bikes and even bikes with banana seats. Its all about getting around.

Here are some of the highlights from my journey:

5/27
Bus was 2 minutes late. One other bike in the rack. Bike is simple to put in - just place front wheel in and pull the hook over the front tire (although, I was still worried about my bike falling out). I also had the outer slot, but I saw the other bike owner get his bike out OK. Another Y! got on the bus a few stops later and sat right in front of me, so I thought I’d follow him, but he got off at Great America. Stops are announced which is very helpful, too.

Light Rail and Bike rack - that totally sucks - just hold your bike if you can. Especially if you have a heavy mountain bike like mine.

Ride home was fine - I skipped the plan big G gave me to opt for the route returning home. I goofed, however (see what happens when you cross the big G?) and took a train 15 minutes too early, which left me at the connecting bus stop for 15 minutes. But, now I know.

The only other downside is that I need to cross a major road on the way home, with no traffic light. Argh.

5/28 - signed up for free wifi - a little slow, and doesn’t seem to work on the bus itself, but hey, it is free. It would be nice if just worked everywhere, though, as I wouldn’t need a broadband card. Oh well.

A couple of Y!s were at the bus stop this morning. It seems that people tend to not use public transport everyday but rather just a few times a week. I’ve had conservations with other Y!s and one said he saved $30 a week plus wear-and-tear by just using PT twice a week. Pretty cool.

Had to leave work early on Wednesday because my wife had plans. The public transport schedule accommodated me just fine. I was a little too early for the train leaving Y!, but had the connection to the bus optimized so I only waited two or 3 minutes.

6/2 - rode my scooter to the bus stop. That is more of a workout than I thought! It also shows that I am out of shape.

The scooter is cool because it folds up but I do wish the platform was a little bigger. I bought the “pro” model of the scooter as it supports my weight - you would think that bigger people would have larger feet and hence they would make the platform larger. Not so.

6/3 - missed the bus by 30 seconds - a very nice woman actually took myself and a fellow Y! up the road (about 4 miles) to catch the bus. Never got her name, but thank you!

6/4 - bus was late - missed my train, but Y! shuttle to the rescue!

Lessons Learned

  • not all stops are listed in the schedule, pick the one before and add a few minutes
  • bus with a bike: when you see the bus coming, look and see how many bikes are on the rack. If no bikes, position your bike so the front tire faces you and put in on the kickstand as you will need to pull down the rack. The bike goes on slot closest to the bus. If there is one bike already on the rack, position the front tire away from you. If there are two bikes, you’ll be taking it on the bus.
  • bike and light rail - hold it if you can - the bike racks are a pain and not worth it for a short trip
  • my commute with a car - 25-35 minutes. Commute with bike/PT - 55 - 113 minutes (57 on average).
  • once you learn where you need to said transportation to, position yourself accordingly. There are benefits to riding the front or back of the train, etc.
  • personal pref, but I don’t like the seats in the front of the bus that face each other. However, if you have a bike and the rack is full you may end up here.
  • riding a scooter is about 1/2 as fast in my situation but twice the workout. Riding a scooter also confines you to the sidewalk so be on the lookout for cracks, etc.
  • Caveat - you are at the mercy of the transit schedule if there is an emergency
Mon
Apr
14

Hiring Developers and the Big Picture



I’ve been sitting on this for about a year and now that it has come up yet again, I just have to comment.

This got started when I got caught up in reading the recent thread on the NYPHP mailing list about interviewing developers and its reference to Joel Spolsky’s, “The Guerrilla Guide to Interviewing” (v. 3.0 10/2006). I discovered that he actually wrote a book on the topic as well (don’t click the link, please).

I don’t know how to say this any other way: All these people got it wrong.

If you read through the threads I’ve linked to, you see that this quickly becomes “me too” party where everyone interjects their criteria/question as to not feel inadequate. So, whats the best answer? There is none, but here are my thoughts on the issue:

  • Every situation is different. Since every place of employment is different, a standardized test won’t help unless you are doing things in a standardized way. My experience: as much as well all crow about wanting standards, engineers generally don’t - unless it was their standard, of course.
  • You don’t always want the Alpha. I see the discussion go from a request for a junior developer to questions for veterans. This is not a car, where you are hoping to get a Ferrari for a Chevy price. These people need to fit in and grow with your organization. If you manage to get an “expert” for that junior position, they are just going to leave, so don’t bother. Rather than looking at how much you can spend on this new hire, you should be looking at what you NEED for the company to grow. Hiring a junior person is really for backfill (or if you can’t afford a senior person) so the requirement needs to be different, as well as the questions.
  • I won’t get long winded, but rather than fun algorithm tests that only prove if the user has seen the latest parlor tricks, you need to assess their experience, skill level, and THEIR goals. All of this fun should be done at the phone screen level, so when they are here in person, you should seriously be considering them. So, do this:

  • Read their resume, go in and start talking to them. Ask them about their resume and items
  • As you go through each item, as them in detail about it. If you are experienced as you think you are, you should be able to delve pretty deeply. This also conveys to the candidate that simple BS isn’t going to work with you
  • Give them a problem to work on and see how they tackle it. This is open-ended, and you should see technical knowledge mixed in with a get-it-done attitude.
  • The last one is pretty important. You really don’t care if they can solve the carnival game you gave them at the interview, you really care if they can handle whatever may come at them in the future. I think this is the part that people don’t get. Language, platform, etc, don’t really matter at that point. If you are looking for a true expert, you need to look for the traits that one displays:

  • Technical experience: not syntax, but concepts
  • STRONG communication skills. This is a deal breaker. They can’t speak and write, they are out. No matter the position.
  • Roll with it/Get it done mentality. You should be looking for that person to consistently try to solve the problem, coming at it from different angles and won’t stop until it is fixed or they re-assess the problem itself (IMO it takes a real expert to see this).
  • So, make a pot of coffee and sit and have a chat with the person. You’ll never know what you don’t know without it.

    Sat
    Mar
    29

    Mark Shuttleworth talk in SF



    Last Tuesday I had the privilege of hearing Mark Shuttleworth speak at the BALUG meeting in SF. The format is a little different than with other groups I’ve attended over the years as it was held in a restaurant in Chinatown. You needed to RSVP and pay for dinner ($13) but it was certainly well worth it.

    I (thought) I planned well for this trip: that day I took the free Y! shuttle up the SF office (on Sansome) and worked from there. The meeting was only a few blocks away and I made sure to get there really early. I got a great seat, met some great people and waited for dinner and the talk.

    The highlights:

  • As he put it, we need to “best express the next”. Others have said the same but we all know it’s true. If we want Linux to succeed on the desktop it really as to be “better” than anything else. Better, is of course, subjective, but Mark is referring to allowing people to better achieve their goals through software. Expressing themselves with more control and granularity. All-the-while making our apps easy to use with less headaches during installation and configuration.
  • He would use Redhat on servers rather than Ubuntu if the application was certified. I find that to be a very noble and positive statement. Use what is best for the job and play nice with others.
  • The Novell deal was bad for open source. The sentiment is that the deal promoted a false sense of security to potential buyers and didn’t really seem to benefit open source at all. It only muddied the water with potential adopters as they might buy into Novell to “keep from getting sued” or at least “be protected” should they be sued.
  • Codecs and DRM are definitely holding us back. New content and media needs to be available to everyone, regardless of platform.
  • He fondly referred to his time spent on the Soyuz as “farting around in outer space”. That was absolutely hilarious.
  • Unrelated to the talk, I was absolutely AMAZED with how many people owned the OLPC I would say out of 300 people about 30% owned one.
  • It was a short, but great talk. BALUG seems to get some great speakers so I’ll definitely be going back.

    The irony:

    So, for all of my planning upfront, I still managed to get home at 2AM. Leaving the restaurant, I got on the right bus going the wrong way, which caused my house of cards to tumble. Missed the train out of SF by 5 minutes, which caused me to miss the connecting light rail to my car. We’ll see if I get this right next time.

    PS: Here’s a fun link: Bug #1 for Ubuntu, filed by Mark Shuttleworth himself. Thanks to Jeff Boulter for the link.

    Fri
    Nov
    30

    Fun with Make



    I usually don’t have a reason to muck around with GNU make but I find myself sitting on a train from Ronkonkoma to Jamaica (LI to Queens, in New York) with not much to do (and no internet access), so I figured I’d do some scribbling. (BTW, I’m using the shell in Mac OS X for this, but all of these commands should work fine on Linux, for using make on Windows, check out sourceforge.net for options)

    The man page provides some good info but what is really helpful is the info documentation. To access it, type:

    info make

    Info is usually too verbose for what people are looking for when working with the shell, but since make is more than just a simple shell command it is definitely worth a read.

    So, what is make?

    From the man page:

    “The purpose of the make utility is to determine automatically which pieces of a large program need to be recompiled, and issue the commands to recompile them.”

    So, think of it as a management system for your program. As mentioned in the documentation, make is not limited to compiled programs, or even programs at all. If you have some type of file that needs a command (or set of commands) executed after it is modified you can use make for the job!

    An example.

    So, lets create a small C program. We’ll call it junk.c:

    #include

    int main()
    {

    printf(”Hello World\n”);
    return 0;

    }

    Simple enough, right? Good. Now, I would normally compile this program with:

    cc junk.c -o junk

    and once you do that, you’ll see that you have an executable called ‘junk’ which you can run with

    ./junk

    (if not, check permissions and see if you actually have an executable file called ‘junk’)

    Fine. So, lets throw make into the mix. We’ll create a file called “Makefile” (notice the capital ‘M’, the capital ‘M’ is not required, but is convention and convenient as it separates this file from your source files in the same directory) in the same directory. That file looks like this:

    # Makefile
    # build junk executable

    junk : junk.o

    junk.o : junk.c
    cc junk.c

    so, once you this file created, lets run the make command:

    make

    You should receive output similar to this:
    ~/junk supertom$ make
    cc junk.o -o junk
    ~/junk supertom$

    If you run make again, you should receive output similar to this:

    ~/junk supertom$ make
    make: `junk' is up to date.
    ~/junk supertom$

    That’s the whole idea behind the make command. It acts as a manager for your program files. If they need to be recompiled they will be, otherwise it will do nothing. May not be a big deal with our simple program but if you are dealing with lots of program files compiling only the modified files is a big time saver. To force make to recompile in this case just remove the junk executable.

    Ok, back to our example. Looking at our Makefile, “junk” is the ultimate name of our executable and to build it, we need junk.o. In terms of make, both junk and junk.o are called targets. You can think of targets as appearing to the left of the ‘:’ in the file. So, the “junk” target needs file “junk.o” and “junk.o” needs junk.c. Notice the command:

    cc junk.c

    This is command to be run when that target is encountered. Commands that you want executed by make must be prefaced by a tab. The make utility is actually pretty smart when it comes to C files, so if you look at the makefiles for current applications it might not be so verbose. Don’t forget, however, that make can be used for other things, so take not of what is going on in our example.

    Ok, lets pick it up a bit:

    # Makefile
    # builds the junk executable

    prg = junk
    objects = junk.o

    $(prg) : $(objects)

    # what would normally explicitly be here...
    #junk.o : junk.c

    # make knows what to do with .c files so you can actually leave it out
    # it knows that .c -> .o
    # junk.o :

    # and, we can put a var in, like this:
    $(objects) :

    # .IGNORE gets us around the problem of rm not finding the files to delete
    .IGNORE clean :
    rm $(prg) *~ *.o

    tarup :
    tar -czf $(prg).tar.gz $(prg).c

    So, what are the targets in this file? junk, clean and tarup. “junk” is our first target and is the one that will be executed if no other targets are specified. “clean” runs the rm command to remove backup and .o files and tarup executes a command to create a tarball of junk.c. So, I can execute these targets with:

    make clean
    make (or make junk)
    make tarup

    We’ve introduced some new concepts in our Makefile, so lets discuss briefly. One is the concept of variables. See prg and objects at the top? Yup, those are vars. Similar to the bash shell, we declare and initialize with no distinct chars, but then use it with $ and parentheses. You’ll also see that we’re a little less verbose about what is going on. As I mentioned earlier, make is smart about C files and knows what to do with them.

    We’ve also introduced the “phony” target .IGNORE which keeps us from receiving errors from the rm command. Ever try to rm something that didn’t exist? You’ll receive an error. Maybe not such a big deal to you now, but if you try to include it in a dependent sequence of commands, like

    make clean && make

    make will never execute because make clean will return with a status of 1 if there are no ~* or *.o files.

    So, my train ride is about over, but here are some thoughts/reasons/ideas on how/when to use make for non-compiled applications:

    • Creating a “package” out of your application - especially in web programming, we tend to think of these files as separate, but they are heavily dependant on each other. You could use make to create a tarball of your app
    • Things that need to happen before or after a “build” - update a build file with date/time information, suck in a sql file that needs to be included in the package, tag a cvs/svn branch or include some other metadata
    Wed
    Oct
    31

    My 1st California Earthquake



    So, it is official: Last night at 08:04:54 PM PST I experienced my first earthquake. It had a magnitude of 5.6 and I have to say we were pretty close to the epicenter. Nothing fell off of our shelves and nothing was damaged, but the family was pretty “shaken up” (no pun intended) about the whole thing (Ok, pun intended).

    Here are some links:
    Recent earthquakes - it is the “big” square.
    earthquake.usgs.gov
    Moderate earthquake hits Northern California - Y! News