deco

I've always wondered why they never built features to allow fans to pay artists directly on the platform.

It seems like it could have been viable, even if they had to implement a manual review / whitelisting process to make sure an artist has appropriate rights to sell a song while preventing people from selling bootlegs and unlicensed DJ mixes. Even taking a 10-15% cut, compared to Apple's 30%, would probably have generated significant revenue. The 'Buy' buttons on songs and playlists that can be linked to any URL have been a part of the product for as long as I can remember, and for the majority of artists those buttons have been the only way to earn money from being on SoundCloud (aside from less directly related things like parlaying SoundCloud popularity into touring revenue). Instead of SoundCloud collecting payments when this button is clicked by a user, they've instead sent all of this traffic off to iTunes, Bandcamp, and any number of other retail and streaming outlets artists choose to link to.

Quick ways to spend money on SoundCloud with a saved payment method could've opened up all kinds of other businesses for SC to tap into such as ticket sales, merch, etc.

I'm not a huge fan of speculating on what could of been with companies, especially when they're in trying times like SC is now, but I can't help but wonder how the last few years could've played out differently if SC had stayed focused on an artist + fan platform instead of moving into more traditional major label catalog streaming.

We are at the tail end of introducing Webpack to an ~8yr old codebase and this has been our approach:

* Allocate training time for all team members to go through some e-learning courses / tutorials about Webpack (Frontend Masters, egghead.io, etc) and UMD (assorted tutorials / blog posts)

* After much hand-wringing we decided that for our situation converting our all-over-the-place JS codebase to UMDs with global fallbacks was the most flexible approach. This allows us to use the same code both in Webpack bundles and in our existing litany of <script> tags. Introducing Webpack has forced us to pay down a lot of technical debt during the process, something that has been years overdue but had to get done eventually. It's been frustrating having to clean up the mess made by developers who no longer work here but ¯\_(ツ)_/¯

* Created a long-running feature branch where we added Node.js and Webpack dependencies to our existing Java / Spring / Maven project

* As internal libraries are converted to UMD, merge them into the feature branch and add them to the appropriate Webpack bundle. Any 3rd party JS libraries that are available via npm have been removed from our codebase and are now pulled in as dependencies via package.json

* Put everything behind feature toggles

* Experiment with our CD / CI pipelines using the Webpack feature branch to make sure we can reliably break the Maven build when something goes wrong with Webpack / Node.js, generate fresh bundles for hot / partial deploys, and get things deployed to an app server in one of our dev environments without any issues

* Do demos every 2-3 weeks for both our team and other teams / managers to show progress, share lessons learned, etc

All of this has unfolded along with our regular workload over the last 3 months or so. We've taken a measured approach with small steps along the way and it's worked out well.

A lot of people are off for the holidays so my guess is we'll start introducing Webpack bundles into production sometime in mid-late January.

As an added benefit, this project has been used to establish a bit of a beachhead with respect to introducing Node.js to our various codebases so we can start doing automated testing, modern JS dependency management, code linting / style enforcement, and providing better developer tools to the team(s) that write JS / CSS / etc.

Skrillex has a longstanding deal w/ Atlantic leftover from his earlier band From First to Last. His label OWSLA is an imprint on Big Beat, which itself is a subsidiary of Atlantic. The cost of this was probably shared between Big Beat / OWSLA, Atlantic, and the artist himself (or his management team Blood Company). These sorts of deals get pretty convoluted when major labels are involved.

Either way, a very cool interactive experience. The only criticism I have is that they completely ignored mobile/tablet/non-Flash -- it's a Flash-based game, but if you visit the site on a non-Flash device you don't even get an alternate "Sorry, your device is not supported" message.

I think it's worth noting that someone who develops an eating disorder like anorexia is mostly hurting themselves through emotional distress and physical damage to their body. The emotional pain their friends and family experience when such a disorder takes hold of a loved one is part of the situation as well.

When someone pursues the goal of becoming ridiculously rich they get into the position of being able to inflict great financial and emotional pain on a much larger number of people. The Enron executives who contributed to the destruction of many people's pensions and heads of state who siphon government funds to support their royal lifestyles while their citizens starve are two prime examples.

I'm not trying to trivialize eating disorders nor am I saying that pursuit of wealth is inherently bad, but history has numerous examples of how greed can cause people to carry out extremely inhumane actions that affect large numbers of other people.

For my tech work: Basecamp, Beanstalk, and Ballpark.

For my music work: Soundcloud and ArtistData.

I've left the software (well, web) world multiple times under different circumstances. I don't regret any of my hiatuses. Taking detours off your career path gives you a unique experience, a new perspective, and broadens your skill set beyond what you're usually able to pick up in a single industry. The cross-discipline experience (in my case, music vs technology) I've gained is priceless to me on both a personal and professional level and I'm very happy with the decisions I made. Go ahead and veer off the beaten path while you're young, it's only going to get harder the longer you wait. The financial ramifications of my decisions have not set me back very much, if at all, and what I may have lost in money I've more than made up for in lived experiences.

I updated my 3G to iOS4 and noticed a serious performance hit along the same lines as the original poster. Rebooting the phone brought things back up to speed though, with some functions seeming snappier than they were under 3.x (Safari being the stand-out example). The phone has been running fine over the past couple of days since the reboot, so I'm not sure if there's a problem with how the upgrade is carried out on the phone that causes the slowness, or if there are some memory issues in iOS4 that will necessitate periodic rebooting of 3G models.