sheriff

Sounds like Netta was doing due diligence on the relationship.

And yet the reality is that there is no shortage of free pianos listed on my local Craigslist that no one has picked up yet.

Drake is nice for these kinds of data dependencies.

https://github.com/Factual/drake

I play both guitar and pedal steel. The tapping techniques that would be used on a horizontal 6-string guitar would be impractical on a steel guitar (lap or pedal) because the action is too high and there are no frets.

It's odd to me that the proposed Minimal Skeleton for tracking a bug doesn't include:

* who reported the issue * what they reported happening * what they expected to happen instead

For many reported bugs, it is clear what the actual problem is and what needs to be done to resolve it. In this case, it can feel like unnecessary overhead to track the bug in a separate system from the rest of the development work queue.

But it's worthwhile to have a place to track bug reports that can't yet be acted on by writing code. Sometimes it's not immediately clear what is happening or what should be done about it. Sometimes you need to reach out to the reporter(s) for more information or to let them know progress has been made.

Even with well-understood bugs, there can be a many-to-many relationship between the bug and the development work to be done. Sometimes you have many people reporting the same issue in different ways, and it's not initially clear that there's a shared root cause. Sometimes one bug report is best addressed in multiple phases of development work.

I'd argue that there's always someone who's managing all of the above, even if they're not using separate bug tracking software to formally do so. But as a team grows, making the investment to "show your work" a little more can make it a lot easier to collaborate and delegate.

neat! thanks

An example of what I'm thinking about, which I don't think Darcs can do (I'd love to be wrong):

Alice and Bob both branch off of master at the same point. In Alice's branch, she moves function `foo` into a different module/file. In Bob's branch, he changes `foo` to handle a new condition. Both wish to merge into master.

Whoever merges later is going to have a merge conflict, and have to resolve it manually, using their human understanding of the semantics of both changes. It's clear to me how that conflict should likely be resolved, but as long as those changes are presented as text diffs, I don't expect my VCS to be smart enough to figure that out on its own.

It would be interesting to explore other ways of representing changes, such that a computer would understand how to compose them in more situations like this.

You can quickly come up with examples of changes which conflict in a way that should probably always require human intervention: Say Alice and Bob each wish to assign the same constant to different values.

So, I don't expect that you could completely remove the need for developers to manually resolve tricky conflicts. At least, not without completely changing how we express changes to programs, which may well be a non-starter for practical purposes.

I'm unfamiliar with Darcs, but thanks for calling it to my attention. Based on a quick look, it appears Darcs uses text diffs, so it's not quite what I'm talking about, but it's definitely interesting.

I came here to post something similar. I'll add that many of the hard things we do with Git seem to do with re-ordering or re-combining of the underlying changes. If we want to make it easier to reason about changes to a set of changes, then I think we really want those changes to have some properties which they don't currently have.

It's powerful for Git to treat changes as line-by-line text diffs, because it allows us to manage changes to any textual data. But what if, instead, we borrowed an idea from distributed databases, and implemented all changes as commutative operations on a Conflict-free Replicated Data Type (CRDT)?

I think almost every example of difficult rebasing would get significantly easier, but at what cost? We'd have to completely rethink how we write programs, because this would drastically limit the types of changes to a program that were valid. I wouldn't be surprised if this would require us to develop in entirely new languages.

There might be some meat to this idea, but again, I don't think we'd get there by mining existing Git graphs.

This article is from 2015, and as a result, that is the last reported year.

I found a more up-to-date data set at http://federal-budget.insidegov.com/ which is consistent with the reported years, and includes both earlier years and an estimate for 2016. Unfortunately, it seems the deficit is growing again, with an estimate of -$616 billion for 2016.

It's also worth looking at earlier years -- nothing before 2009 was higher than $464 billion. Looking at a longer timeline, it seems clear that the general trend is towards a bigger deficit, but the impact of the subprime mortgage crisis means we can play games with statistics by framing our timeline around that year.

This is similar to the trick used by Ted Cruz to argue against climate change, by insisting on presenting the data on an 18-year timeline, so that it would start in 1997 and include that year's abnormally high temperatures caused by an El Niño weather pattern.

http://www.cbsnews.com/news/fact-check-ted-cruzs-claims-abou...

I think one of the big problems with cities is how static their layouts can be. Many years from now, I like to imagine that cities will be made of movable parts that can be rearranged throughout the day to take match the changing needs of the people.

For instance -- there's no need for me to sleep in an expensive part of town, but there's also no need for me to be awake while my bedroom is shifted out into the outskirts. This would be something like Bruce Willis' character's apartment in The Fifth Element, but I don't think we have to wait until we're building cities in space to start working on this.

Similarly, if there's a diner that closes after 3PM, why should I ever have to walk past its empty storefront later in the day? The popularity of food trucks is evidence that there is value in being able to move supply around to find the demand and that we can reorganize our cities on a short time-scale. We don't even need to wait for the parts to be self-driving, as nice as that would be.

Jay Kreps, architect of Kafka, calls it a log.

https://engineering.linkedin.com/distributed-systems/log-wha...

Here's an O(N) solution to the `findSum` problem in Ruby:

  def findSum(array1, array2, sum)
    complements = array1.map{|x| sum - x}.reverse

    i = complements.count - 1
    j = array2.count - 1

    while i >= 0 && j >= 0
      return true if complements[i] == array2[j]

      if complements[i] > array2[j]
        i -= 1
      else
        j -= 1
      end
    end

    false
  end

This was covered on The Office: https://www.youtube.com/watch?v=l8uCNOKODf4

Looks like Ruby. Why use a Hash instead of the built-in Set class?

The motive for running the farm is because some people will pay for the likes.

The motive for someone running a farm to also send likes to non-customer pages is to make it harder for Facebook to detect the fraudulent likes.

Belkin's Wemo[1] line does pretty much what you're suggesting. I've got a few of their units, and I've been pretty happy with them.

[1] http://www.belkin.com/wemo/

I think there are two distinct use-cases for posting to HN, and I think the OP's pain can be partially connected to the fact that both types of posts get treated identically.

The first use-case is "Person A discovers Thing X on the Internet and wants to discuss it critically with the people on HN."

The second use-case is "Person B wants to share Thing Y that they made, in hopes that the people on HN will give positive feedback."

As a reader, you can choose to treat the two types of posts differently, but without a conscious effort, I think the default behavior is to use a consistent approach to all posts on the site. The result is that either real industry news doesn't get reviewed very critically, or personal projects get reviewed more critically than the poster would have hoped.

The post was entirely about flaws in its parent post's reasoning. The flaws were correctly identified. What does this have to do with your assumptions about the author's perspective?

Purchased this to check it out, since I couldn't figure out how to use the vouchers.

Thanks for posting this example. It's pretty responsive... not sure if I would have known it was PhoneGap.

One bug report: Divide-by-zero seems to act as if nothing happened, rather than reporting an error or NaN value.

I would love it if the OP would chime in here, so we could see what the RubyMotion folks are missing.

Could someone please recommend any PhoneGap-based apps that they consider "best-of-breed?"

People write articles hating on popular technologies for the same reason you went after your provocative title... because it's great linkbait.

If the average is currently $X after N purchases, that means they have taken in $(N * X). When the next person pays $(X + 1), the total is now $((N * X) + (X + 1)) == $(((N + 1) * X) + 1). The new average is $(X + (1 / (N + 1))), which is guaranteed to be higher than the previous average, even if $(X + 1) < $10.

If the average is currently $X after N purchases, that means they have taken in $(N * X). When the next person pays $(X + 1), the total is now $((N * X) + (X + 1)) == $(((N + 1) * X) + 1). The new average is $(X + (1 / (N + 1))), which is guaranteed to be higher than the old average.

And it will gradually increase the average every time someone chooses that option.

Why couldn't the web browser also make phone calls?

s/Costumer Service/Customer Service/

I agree that this would be great, but I don't see anything in the docs which suggests this task-to-email linkage is available via the API. If I'm overlooking something, please let me know, as I would definitely like to use that.

Usage being total checkins per month?

I'd be more interested in a comparison of engagement (checkins per account per month) over time. The first metric can hide declining engagement if there are sufficiently many latecomers who haven't burnt out yet.