Full-stack web developers, especially Clojure.

Rally Software is hiring for several positions, in all our locations (Boulder and Denver CO, Seattle WA, Raleigh NC, and Helsinki Finland).

In particular, I am interested in finding experienced polyglot programmers to join the team that I work on, which does backend infrastructure-type projects, working almost exclusively in Clojure. We are located at Rally's main office in Boulder, and offer relocation.

Feel free to contact me directly with questions ( chrisperkins99@gmail.com ).

- Chris Perkins

I like backpack because I can reorder and drag items between lists easily. There is even a checkbox beside each item, which I get an unreasonable amount of satisfaction by clicking.

So thank you, Amy, for proving me wrong.

This exact thing here -- the idea that "no one will pay for it" or a question of whether there is "still opportunity" -- is why hanging around HN without the right mental filters is detrimental to your success.

There is not only "still" opportunity in boring sectors like time tracking, there's LOTS of it. LOTS and lots. The more people who use a tool, the more pain they experience, the more people who are left out by certain viewpoints on how to build or run the tool, etc., who discover they need an alternative.

"Startups" may be sexy and exciting, but the basic tools people have to use to run their businesses and their lives still suck goatnuggets. And these basics are a friggin gold mine. :)

There is MORE opportunity there than in some green field where nobody has gone before, because there's a reason nobody has gone there before.

As for time tracking being something "no one will pay money for," tell that to all the businesses who I'm sure make wayyyyy more than we do -- Harvest, FreshBooks, RescueTime, toggl, mite, etc. For a long time, the only compelling reason to upgrade to the higher level of Basecamp was because it came with (the most terrible) time tracking. And lots of people upgraded.

People who say things like "no one will pay for that" pretty much never do their research. What they mean is "I won't pay for that," which is totally immaterial, just so much self-absorbed gasbaggery. They simply can't imagine that anyone is different from them. And there are tons of those people in the "startup scene."

If you just open your eyes and look at the businesses you interact with every day, and look at how long they've been in biz, how many people they employ, what kinds of promotions they do, etc., you will see that there are a bazillion businesses like mine -- and much much much bigger -- which never make tech news coverage, they just quietly tick along making millions a year. I know a guy whose business has millions in revenue a year from a Wordpress plugin that you've never heard of.

But it's unsexy so HNers aren't generally interested. :)

So I pretty much hang around here for the occasional breaking news & the opportunity to spread the gospel. This discussion will turn into a series of blog posts so I'm getting something out of it too :)

Bam! Quad-negative! Top that.

If, on the other hand, the intent is to prove that I suck at video games, then it's a resounding success.

A lot of the Python scripts that I see at work look like either C programs or glorified batch files. I'll definitely point people to this when they are ready and willing to move on to the next level.

Well done.

Suggestion: one thing I didn't see mentioned is switching from "if s.find(c) == -1: ..." to "if c in s: ...". I see people do that a lot.

Still, I had to test just to be sure:

    test_cases = [
        # haystack, needle, expect
        ('abcdefg', 'a', True),
        ('abcdefg', 'b', True),
        ('abcdefg', 'bcd', True),
        ('abcdefg', 'h', False),
    ]
    
    for haystack,needle,expect in test_cases:
        # find version
        is_found = haystack.find(needle) != -1
    
        # in version
        is_in = needle in haystack
    
        # confirm
        print haystack, needle, expect, '-->', (is_found, is_in)
        assert is_found == expect
        assert is_found == is_in

I think this is covered implicitly by the two "Use in where possible" sections. Although as Tim Peter's The Zen of Python states, which is also quoted in the tutorial, "explicit is better than implicit." If people are doing that despite knowledge of the in keyword then I suppose that just proves Tim's point.

  if c not in s: ...

  if s.find(c) == -1: ...

In Excel, if you're entering data, you press 'tab' to move to the next column, and when you're done with that row, you press Return and it kicks you down and back into the leftmost column. Very handy, since it saves you a mouse movement or many left-arrow presses to get back to the start column. At least the last version of OO Calc I played with didn't mimic this behavior properly---pressing Return just dropped to the next row in the same column, even after entering several columns of data.

Excel may not be the greatest program in the world (let's be honest, it's a bloated monster), but it does a few things right.