samarudge

Songkick | Full Stack Software & Platform Engineers | London, UK | Fulltime | ONSITE

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

> the Varnish HTTP cache has been used very successfully to speed up WordPress. But Varnish doesn’t help a lot with logged-in traffic > This is caching that Varnish and other “normal” HTTP caches (including CloudFlare) could not have done

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

If you could that would be greatly appreciated. This is the first time I've put something on Pypi so not completely familiar with it.

Thanks!

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.

I don't work for a big company, so this is purely speculation, but there could be many reasons why it's not done.

* 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?

I guess it depends on one's perspective. You are probably right that someone will send a pull request to add it if it's not there, but I think authors of tools should always do their best to encourage users to do things correctly, especially issues like this which can easily be found without even knowing it's an issue (Google-ing "Email Regular Expression" brings up results for me on the first page recommending it's not a good idea)

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.

Got this exact same thing, tried it on the device (Nexus 4) play store, it lets me view the app, hit install, accept the permissions then says "The item that you were attempting to purchase could not be found" =/