samarudge

Songkick is on a mission to bring the magic of live music to fans everywhere. Since 2007, we've set about making it as easy, fun and fair as possible for you to see your favorite artists live. Right now, more than 15 million music fans across the globe use Songkick to track their favorite artists, discover awesome concerts and never ever miss out.

We're looking for developers with the ability to take on a range of challenges: from developing our highly scalable website and mobile apps, to integrating with other platforms (streaming services, social networks), to large-scale data acquisition and processing.

We do our best work when we're happy, respectful and relaxed. Our values and work ethic have got us far, and as we grow we'll never shake that small startup feel. Earlier this year we became part of the Warner Music Group family, opening up epic new realms of opportunities to bring fans and artists closer together.

If you're interested, there's more info on our jobs page at songkick.com/jobs, or reach out to me directly on smudge [at] songkick.com

I couldn't (quickly) find documentation on how to get the value of a specific cookie, but the server could send a user ID in a header or something Varnish can easily access to be used in the above function.

Varnish supports the ESI (Edge-Side Includes) standard, which allows it to cache fragments of a page, and for the cache server to build them again. It also allows you to completely bypass the cache for certain fragments. This is also supported by a number of CDNs (Fastly, Akamai). I've used the ESI technique several times and have been able to achieve a >98% cache hit rate on Fastly for a site with dynamic per-user content. Even the cache misses are only responsible for rendering a small component of the page

The HTTP library (requests) by default will pull a gzipped version of the resolvers list from Github (Content-Length returned for current version is 59029 compared to 239359 with gzip disabled). Compressing with `gzip -9` gives me a file size of 49648 so I don't think the added complexity of having to consciously deal with the compression in the application outweighs the small gain over the standard HTTP compression Github and Requests provide by default.

I had looked at pre-downloading the resolvers file in the setup script, unfortunately there doesn't seem to be a decent, reliable way to do it. If people download the source and run `setup.py install` it's easy but I'd imagine most people will just install with `pip` or `easy_install` which makes things a bit more complicated since nether of them seem to run post install actions.

Both good suggestions though, I'll keep them on my todo list.

> CentOS is one of the reasons that the RHEL ecosystem is the default. It helps to give us an ubiquity that RHEL might otherwise not have if we forced everyone to pay to use Linux. So, in a micro sense we lose some revenue, but in a broader sense, CentOS plays a very valuable role in helping to make Red Hat the de facto Linux.[0]

[0]http://readwrite.com/2013/08/13/red-hat-ceo-centos-open-sour...

* Documentation Time

If you've got a big project, it could take weeks, even months to properly document some software to a position where it could be used by someone outside of the company. Sure you have your internal documentation but it can often be incomplete, or make assumptions that the person reading it knows about other bits of the company.

* Deployment

Big projects will often use very specialized hardware, software and environments, to the point where it could be nearly impossible to deploy outside of the company. It could depend on internal services that can't be open sourced because there still used, or are an important part of the business. Take Google Reader, yes it would be nice if it was open sourced, but internally it probably uses services, databases, APIs specialized just for Google, it's probably been optimized to work on Google's hardware, with their webserver, with their OS build etc.

Reddit is another example of this, Reddit's code is open source, and while it can be deployed, it's not easy. This seems mostly because it's been built to work on a very specialized set of software versions, and in a very specific environment. Larger open source projects tend to be tested on a multitude of environments, with applications only deployed or built internally, there's no point because you can very accurately control your environment.

* Some of the code is still used

Some, or even big chunks of the code could still be being used in current software. If you've got a library that's particularly useful, you might keep using it. If it works there's no point re-writing it just for a new project.

* The code is very bad

We all know it happens, a project contains terrible code, bad bugs and maybe even security issues, they never bothered getting fixed because they were never noticed. Given the opportunity to look through the code people might pick up on these issues and it would look bad on the company.

* Open source is complicated

Open source seems to come along with a whole host of fun things to deal with, GitHub issues, ranty blog posts, forks, copyright, licenses can all get a bit complicated. Even if it's old software that isn't used anymore you probably need to do some degree of management before things get too out of hand. Even a single tweet can have a big impact on a company, or a products reputation, so particularly at larger companies they'd probably want it managed in some way.

Anyone else got anything to add?

Certainly when it comes to security, authors should do their best to ensure users of the tool are educated, when there's a security issue with any large software product, particularly open source, that's mostly down to poor configuration or ill-informed users, the authors are instantly criticized, but I think it should be the same for any general features in a tool that targets a specific functionality. This particular "best practice" is quite easy to find, and the tool is very specifically targeted towards validation, yet has something that's against best practice and could potentially cause frustration for people who use this tool, and people who use the stuff created using this tool.

Source: https://github.com/guillaumepotier/validator.js/blob/master/...

http://davidcel.is/blog/2012/09/06/stop-validating-email-add... http://stackoverflow.com/a/202528/744180 (others, just Google)

You need to set the 'Access-Control-Allow-Origin' header to get them to work in Firefox. More info at https://developer.mozilla.org/en-US/docs/HTTP/Access_control...

Also, why use `manager.arg` for documenting arguments, why not just use Python docstrings?

So ima take the hit of being a stupid person and ask, what's the difference? Why should I use this over bootstrap-wysihtml5 (or why should I use bootstrap-wysihtml5 over this)?

Some people put links to twitter/other social networks on their blogs but since probably >99% of the visitors to Hank's blog will get there from somewhere else in his network (Twitter, Youtube or any one of our number of community sites).

So yeah, don't feel to bad, Tumblr confuses even those of us who consider ourselves "social-media competent"

http://youtube.com/crashcourse

http://youtube.com/scishow

http://twitter.com/hankgreen

http://en.wikipedia.org/wiki/Hank_Green

(In addition to that, he's also my employer, but that might not be relevant to you)

https://news.ycombinator.com/item?id=5453373

https://news.ycombinator.com/item?id=5453191

https://news.ycombinator.com/item?id=5452780

> © 2013 PeerCDN, Inc. Site design inspired by Meteor.

Using Requests to download the document, pump it into PyQuery and you can use any jQuery style selectors to get text, attributes and all sorts of other stuff.

Example; Here's how to scrape the hacker news homepage https://gist.github.com/samarudge/035ab8aaca224415cb49 (that code could probably be improved but I only spent a couple of minutes on it)

It's still listed as the top trending repo of the day/week/month (http://dft.ba/4RAM https://github.com/explore/month)

Doesn't seem to specify exactly what `artwork` was used without permission.

Wednesday morning seems like a good time for internet drama =O

As an example, you can currently watch Madagascar, in full, for free on BBC iPlayer (http://www.bbc.co.uk/iplayer/episode/b00gd77z/Madagascar/).

While there is an argument that programs produced by the BBC should be DRM free, there is no way larger, and independent studios would allow their content uploaded DRM free.

Personally, I want the BBC (and other sites) to be able to use technology like HTML5 video, because I don't like flash, and it's unlikely the studios are going to suddenly decide their OK with DRM free video, I'm not necessarily /for/ DRM in HTML5, but I don't see any other way around it for now.

While you can argue all you want about how DRM is useless and easily broken, as yet no-one has managed to convince big TV and movie (and even game) studios of that. The BBC is just doing what it feels it needs to in order to be able to deliver video using the latest technology, while keeping it's partners happy.

> "The cost of running and deploying your own server just to monitor the errors maintenance in your application for a lot of users isn’t really practical – there’s a lot of and cost involved with maintenance and upkeep"

I don't really understand this, we just stick it on our app/db servers alongside our other applications. The cost is $0 and it takes about 5 mins to set up, it's just a Django app.

If you don't like dealing with it directly, use something like MongoEngine so you're not working with the raw queries, or if having readable, easy to understand queries is important, use a SQL database.

Everything is a compromise, with Mongo's query language you're sacrificing readability for performance.

( This is not a comparison of a SQL database to Mongo, just the time it takes for a SQL engine to parse the query into an execution plan )