sferik

At least they moved fast.

Breaker is a social podcast software company. Learn more at https://www.breaker.audio/i/about.

We are currently looking to hire two people:

1. A full-time senior iOS developer, preferably ONSITE in San Francisco, but open to REMOTE.

2. A part-time community manager, starting at ~10 hours per week, with an opportunity to scale with the company. REMOTE friendly. Must love podcasts.

More information at https://www.breaker.audio/i/jobs.

Please send inquiries to jobs@breaker.audio

Can someone who doesn't like symbols help me understand the downsides of them?

I wish I had been clearer in my talk but I only had 30 minutes and wanted to cover other topics. Here is a more comprehensive argument against symbols in Ruby:

In every instance where you use a literal symbol in your Ruby source code, you could you could replace it with the equivalent string (i.e. calling Symbol#to_s on it) without changing the semantics of your program. Symbols exist purely as a performance optimization. Specifically, the optimization is: instead of allocating new memory every time a literal string is used, lookup that symbol in a hash table, which can be done in constant time. There is also a memory savings from not having to re-allocate memory for existing symbols. As of Ruby 2.1.0, both of these benefits are redundant. You can get the same performance benefits by using frozen strings instead of symbols.

  "string".freeze.object_id == "string".freeze.object_id

  def measure
    t0 = Time.now
    yield
    t1 = Time.now
    return t1 - t0
  end

  N = 1_000_000

  puts measure { N.times { "string" } }
  puts measure { N.times { "string".freeze } }
  puts measure { N.times { :symbol } }

1. Symbols and frozen strings offer identical performance, as I claim above.

2. Allocating a million strings takes about twice as long as allocating one string, putting it in into a hash table, and looking it up a million times.

3. You can allocate a million strings on your 2015 computer in about a tenth of a second.

If you’ve optimized your code to the point where string allocation is your bottleneck and you still need it to run faster, you probably shouldn’t be using Ruby.

With respect to memory consumption, at the time when Matz began working on Ruby, most laptops had 8 megabytes of memory. Today, I am typing this on a laptop with 8 gigabytes. Servers have terabytes. I’m not arguing that we shouldn’t be worried about memory consumption. I’m just pointing out that it is literally 1,000 times less important that it was when Ruby was designed.

Ruby was designed to be a high-level language, meaning that the programmer should be able to think about the program in human terms and not have to think about low-level computer concerns, like managing memory. This is why Ruby has a garbage collector. It trades off some memory efficiency and performance to make it easier for the programmer. New programmers don’t need to understand or perform memory management. They don’t need to know what memory is. They don’t even need to know that the garbage collector exists (let alone what it does or how it does it). This makes the language much easier to learn and allows programmers to be more productive, faster.

Symbols require the programmer to understand and think about memory all the time. This adds conceptual overhead, making the language harder to learn, and forcing programmers to make the following decision over and over again: Should I use a symbol or a string? The answer to this question is almost certainly inconsequential but, in the aggregate, it has consumed hours upon hours of my (and your) valuable time.

This has culminated in objects like Hashie, ActiveSupport’s HashWithIndifferentAccess, and extlib’s Mash, which exist to abstract away the difference between symbols and strings. If you search GitHub for "def stringify_keys" or "def symbolize_keys", you will find over 15,000 Ruby implementations (or copies) of these methods to convert back and forth between symbols and strings. Why? Because the vast majority of the time it doesn’t matter. Programmers just want to consistently use one or the other.

Beyond questions of language design, symbols aren’t merely a harmless, vestigial appendage to Ruby. They have been a denial of service attack vector (e.g. CVE-2014-0082), since they weren’t garbage collected until Ruby 2.2. Now that they are garbage collected, their behavior is even closer to a frozen string. So, tell me: Why do we need symbols, again?

I should mention, I’d be okay with :foo being syntactic sugar for a frozen string, as long as :foo == "foo" is true. This would go a long way toward making existing code backward compatible (of course, this would cause some other code to break, so—like everything—it’s a tradeoff).

I’m curious how Europe’s tech hubs (specifically London, Paris, and Berlin) compare to U.S. cities.

I suspect Berlin would compare quite favorably, despite the relatively high German tax rate. I moved there 18 months ago and currently pay €500 ($565) for a one-bedroom apartment in a nice part of town (Prenzlauer Berg). In San Francisco, I paid 5X that for a studio apartment in Hayes Valley.

That’s just one project. For a better representation of my overall activity, see https://github.com/sferik?tab=activity.

This is getting ridiculous:

https://github.com/sferik/t/pull/142/files

https://github.com/sferik/t/pull/143/files

https://github.com/sferik/t/pull/144/files

Shameless.

The problem with this funding model is that it encourages fluff pull requests, such as this one: https://github.com/sferik/t/pull/138/files.

If there was no financial incentive, I would probably merge it but now I'm questioning the motivations of the committer. If I merge this, it means there will be less money for someone else, who makes a more significant contribution in the future.

Personally, I prefer Gittip’s model to incentivize open-source contributions, if only because it doesn’t create this kind of noise for project maintainers.

That’s what I was trying to do but apparently I fail at HN. Is it too late to add 0 as an option?

The account isn't verified but it was just retweeted by @pschiller, so it appears to be legit.

Yes, that's the point. As people spend more of their time and attention on social media relative to other media, where will those branding budgets go? Not to Google (well, actually, that's why they bought YouTube...but not to Google Search).

Twitter is one of the few outlets where brands can effectively communicate their message online. That's the theory, anyway. You can argue that Twitter is a bad medium for branding but arguing that it's a bad medium for direct response advertising is missing the point.

What you are describing is direct response advertising.

There is another type of advertising called branding. Budweiser doesn’t spend $25 million per year advertising during the Super Bowl because they expect you to see the advertisement and immediately order a beer at the bar. Instead, Budweiser is trying to tell you a story about their brand to evoke an emotional response that will be stored deep in your amygdala such that every time you go to buy beer in the future you will reflexively choose Budweiser.

Google is better for direct response advertising; Twitter is better for branding.

PS: There is more money in brand advertising.

This looks awesome! I can hardly wait for Vagrant 1.1 to be released.

The patch I applied does not use YAML.tagged_classes.

YAML is aliased to Psych:

irb(main):001:0> require 'yaml'

=> true

irb(main):002:0> YAML

=> Psych

MultiXML version 0.5.2 is now released.

A new gem release is in the works and should be pushed tomorrow. In the mean time, you can use this workaround.

That's correct. But I'm planning to remove this functionality anyway, just to be safe. It's too easy to accidentally open this vulnerability and it's unclear what the valid use-case is for parsing YAML or symbols from XML.

When I implemented this functionality, it was only to be compatible with the Rails parser.

You could follow @richhickey on Twitter or just read Hacker News ;)

The rules were changed in 2010 to allow texting/tweeting.

Here's a link to this year's official WSOP rules: http://www.wsop.com/2012/2012-WSOP-Rules.pdf (see section 61 on Communication)

Here's the relevant part: "Participants not involved in a hand (cards in muck) shall be permitted to text/email at the table, but shall not be permitted to text/email any other Participant at the table."

Arguably, a public tweet could be interpreted as a text or email to another participant at the table, but the rules are not enforced that way and tweeting is a generally accepted practice by pros and amateurs alike.

T happens to be written in Ruby but it's a CLI, not a Ruby library. The fact that it is packaged as a gem is incidental. T was designed to be called from a command line shell and to interoperate with other Unix utilities like grep, cut, awk, bc, wc, xargs, etc. All output is streamed to stdout, so it actually makes just as much sense to call t from a shell script (or, for that matter, from a Perl or Python script) as it does from Ruby.

I was torn about what to call them. I actually tweeted a request for suggestions: https://twitter.com/sferik/status/193015186045681665

I got some interesting replies but ended up going with "leaders" based on the logic that if someone follows you, you are their leader. Simple and easy to remember.

That said, I'm still open to other suggestions.

For a good explanation of why it's a good idea to always use semicolons in your JavaScript, take a look at: http://lucumr.pocoo.org/2011/2/6/automatic-semicolon-inserti...

Thank you for pointing this out. Before I started the project, I requested permission from Wilson Miner to use the stylesheets and javascripts from Django and added his name to the acknowledgments, but I neglected to add the BSD license.

This error has been corrected in: https://github.com/sferik/merb-admin/commit/b5462f4b73d44447...

LOL! Any designers out there?

Given your response, you might be surprised at the number of angel (or even Series A) investments made almost exclusively on the basis of the individuals involved, sans any tangible product or traction.

The thing that holds Kickstarter projects together is putting one's own credibility on the line. The people who pledge, understand that it would not be worth me publicly destroying my reputation for $2000. And since I haven't solicited pledges above $64, I would argue that I'm taking on a much greater risk than any individual contributor.

I view Kickstarter primarily as a tool for customer discovery, to gauge whether a project is worth my time. It has the added benefit of building momentum behind the project by creating a small army of people who are, quite literally, invested in it.

There are probably other names for this process, but I like to call it IDD: icon-driven development.

This totally solves the problem I asked about a month ago. Thanks! http://news.ycombinator.com/item?id=1453143

I've always believed the biggest single moment of destruction of future programmers is when Microsoft stopped shipping BASIC (plus the full source code of the games GORILLA.BAS and NIBBLES.BAS) with DOS/Windows.

I've been holding out to read Rework until I can get it on iPad. This was just the dose I needed to get me through.