1,648 karma · joined August 15, 2010
A better looking, easier to use buy-now button doesn't have to increase sales by much to offset the additional cost. Besides, pricing models can change pretty easily.
All iOS apps must use HLS for videos longer than 10 minutes and Apple verifies compliance during the app store review process. As mentioned, with AirPlay all HLS media files are downloaded directly by the AppleTV, not piped through your device. I can tell you from experience it works very well.
There's a lesson in this for all you contractors out there. Take money up front (I used to expect 50% for small projects, but less for larger ones.) Don't assume your client necessarily has the money to pay once you've completed the job.
Sounds like the concern is that when an error is raised inside an actor, the error is swallowed by that actor's thread. If you were waiting for it to respond you're end up with a mysterious timeout error and no idea where it came from. That's a good issue, one I definitely struggled with.
Internally, we're addressing this problem by building our actors in such a way that they return a Status.Failure when an error is raised, using unit tests to ensure a response is always sent even when an error occurs. Typically, our responder functions are built from a number of Futures composed using the tools provided by Akka. This works well in some cases, when an error is raised early in a function composed from many Futures it gets passed right to the OnError handler to return an appropriate response. In the case where you get a mysterious timeout it can definitely make debugging difficult. Akka's excellent logging has saved us there many times.
The goal was to lean on Akka whenever possible, adding elements to the Smoke DSL only when absolutely necessary. We've been able to make this work in some pretty non-trivial applications. Will that work for everyone? Hard to say. Your mileage may vary.
Combine Scala's flexibility with the importance of HTTP to so many of us, I'm not surprised (nor disappointed) to see a lot of variety in this space. I hope we'll see even more of them as the language matures.
We didn't see any of those libraries as an ideal solution to our problem so we built our own. If this solves a problem for you as well, I'd be happy to hear that. If not, I'd love to hear how you think it could be improved.
Smoke is a smaller, more focused tool. You will find a lot of things Spray does that Smoke does not. Smoke has a significantly different DSL, relying on Akka's composable Futures to take care of things like error handling.
Smoke evolved through an attempt to build the simplest possible asynchronous HTTP services on top of Akka, without sacrificing any of the key features we needed to deploy those services at scale.
The goal of Smoke is not so much to compete with Spray as it is to provide an HTTP-service-focused alternative to Finagle (https://github.com/twitter/finagle) that uses Akka Futures instead of Twitter Futures, and includes everything we needed to build, test and deploy those services quickly.
So far, it's been working quite well for us.
It's much lighter weight than play2 or play2-mini (https://github.com/typesafehub/play2-mini built on top of play2). , but does provide some similar functionality. There's definitely a whole lot less code in Smoke. That may be a good thing or a bad thing, depending on your perspective.
These apps just highlight how unnecessary the service provider is for the delivery of HBO content. Sure, the numbers might not make sense for HBO but they're still going to have to spend the next ten years explaining to customers why they need to pay $100/month, subscribing to a full suite of TV channels, just to watch Game of Thrones on their iPad.
Meanwhile, AMC is making TV that's just as good with a business model that embraces cort-cutters. As streaming becomes more mainstream, HBO is going to have to keep explaining why you can watch Mad Men in iTunes the day after it airs but you have to wait almost a year to stream an episode of Game of Thrones (legally). And their reasons aren't going to satisfy anyone except execs at Time Warner and the service providers.
Streaming isn't going away. How long can a content brand stand against its viewers in the age of rampant piracy? I have a feeling we're about to find out.
At mDialog, our product powers video delivery for some of the largest, most well-known brands in the world and helps bring the most popular shows to connected devices like the iPhone, iPad, Apple TV, Android, and Roku. We partner with the most successful device manufacturers and are considered thought leaders in the future of television broadcasting. We believe we are at the dawn of new age in broadcasting and are the technology leaders enabling the shift.
We're looking for developers willing to help us unleash the power of Scala and Akka (http://akka.io), two core technologies powering the mDialog platform. While there aren't yet many experienced Scala developers, we have successful team members with backgrounds in Ruby, C#, C++ and, of course, Java. At mDialog you will gain experience with functional programming, distributed systems, messaging and adaptive bitrate video streaming. If you've got a passion for software you'll succeed on our dev team, regardless of your current day-job language.
If you're interested, please visit http://www.mdialog.com/careers.html or email cdinn@mdialog.com.
In my opinion the point of building out a test suite isn't to reach 100% code coverage, it's to allow developers working on the application the ability to refactor quickly and aggressively during the development process while remaining confident that it will still perform correctly when they're ready to release. Poorly written tests (or over-testing) will slow down refactoring and hinder development. But, in my experience, not having the right tests can mean firing up your application and manually testing after each small code change to prevent regression. Understanding the trade-off is key to helping developers answer the ubiquitous question: "do I need to test this"?
This role for unit tests is described effectively in Chapter 1 of Martin Fowler's awesome Refactoring book (or Refactoring, Ruby Edition, if that suites you. That's the version that's on my desk right now.) This use case is also highlighted in Eric Evans' book Domain Driven Design, where he highlights one of my favourite application development techniques: "refactoring to deeper insight." Both books are among my favourites.
Adding features to an application isn't just about appending files and lines of code, it's also about changing existing code to allow the new features to fit comfortably into the application's domain model. If you can accomplish that goal with "light integration tests" go for it. That'll mean much less overhead during refactoring and will do a good job of enforcing correctness. If your application contains a robust domain model (which it very well might) you may find unit tests useful for maintaining model integrity during development. This is probably what's meant by "Naturally, some parts of a complex app will behave like a library". When you change the domain model you'll have to change tests for all the affected classes and that's a good thing. It explicitly highlights how your change affected the model, which you should certainly understand before committing your changes.
I will admit this distinction is hard to communicate to first-time TDDers. However, I've found that after having to eat their own dog food for a few iterations (adding features to your own code) smart developers quickly find the sweet spot. The less code you write, the less you have to maintain. But too few test or poorly written tests can slow you down just as much.
At mDialog, our product powers video delivery for some of the largest, most well-known brands in the world and helps bring the most popular shows to connected devices like the iPhone, iPad, Apple TV, Android, and Roku. We partner with the most successful device manufacturers and are considered thought leaders in the future of television broadcasting. We believe we are at the dawn of new age in broadcasting and are the technology leaders enabling the shift.
We're a startup looking for talented people who are excited about working with leading edge technology in a nascent space: video streaming and advertising to connected devices. As a member of our downtown Toronto team, you will contribute to the core product, be involved with product strategy, contribute to prioritizing our product roadmap and own the development of features.
We're looking for Scala/Java Developers (Scala experience a big plus), Project Manager and Senior Technical Writer and several other positions.
Details here: http://www.mdialog.com/careers.html
Does anyone know how those retention clauses usually work?
I've always thought the key to understanding REST is understanding idempotence. Is HTTP request to mark an order as paid idempotent? If so, a PUT/PATCH should be fine. If not (say, you're actually transferring funds) then a POST should be used. This key principle will help make your URL design choices much easier. In your example, the PATCH API appears idempotent, making the suggested POST replacement sort of confusing to me.
When it comes to modeling application processes using HTTP, understanding which requests are repeatable without consequence and which aren't is very important. It's hard to talk about modeling processes RESTfully without talking about idempotence. It's at the heart of the protocol's design.
RESTful thinking needn't be harmful for application processes as long as you do it effectively.
Unfortunately I expect you'll never get money from a bureaucrat without a little paperwork. Still, you're missing out if you don't even try.