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
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.
> 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
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]
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.
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.
It validates emails with a regex. I'm not sure how many times it's been discussed that you shouldn't validate emails with a regex, but please stop validating emails with a regex.
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" =/
How does this compare to Fabric? Fabric offers a load of extra stuff to do with SSH/Deployment, but just looking at the basic features of running Python tasks from the command line, why should I use this over Fabric?
Also, why use `manager.arg` for documenting arguments, why not just use Python docstrings?
Would it increase security to include the user-agent, or part of the user-agent, in the HMAC secret? So the secret was "abc123Mozilla[etc]", that would then presumably require identical browsers to work, at the expense of logging everyone out every time their browser updates. Or include all, or part of the IP address to restrict the network.
Would adding a HMAC string to the cookie value not get around this issue? For example, Tornado has the set_secure_cookie method (http://www.tornadoweb.org/en/stable/web.html#tornado.web.Req...), would this not prevent this sort of attack? Even if a script modified the cookies, they would never (well, hopefully never) be able to generate the correct HMAC token so the server could just discard the cookies. You'd still be able to sign a user out but there wouldn't be a security issue (I think). Anyone smart able to verify/refute?
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)?
Yeah Tumblr can be silly. I've been into Tumblr for a while, and prior to about 6 months ago it was nearly impossible to find the original source of something without trawling through pages of "notes".
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"
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