Login | Register   
RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX

Posted by Gigi Sayfan on October 26, 2016

Virtual reality is here and many companies are working on VR devices, SDKs, content and frameworks. But, true presence and immersion requires high-end equipment at the moment. It will be several more years until really immersive VR is affordable and ubiquitous. In the mean-time, developers must work with today's limitations and constraints. One of the most interesting initiatives is WebVR. It seems to have a lot of support and can be used today for displaying VR content in the browser.

The main draw of WebVR is that it lets gazillions of Web developers take advantage of their experience, skills and tools to develop VR applications and content that will be broadly available. Facebook recently announced it has plans for ReactVR and the Carmel VR browser. The A-Frame project is built on top of three.js and allows you render VR content today. The major browser vendors are all aware of the promise of VR and are taking steps to enable it in their browsers.

It is rare to see the whole industry (or even different industries) aligned and collaborating early on open standards and, in general, taking the right steps to ensure this innovation reaches each and every person sooner rather than later. I'm very excited to see these developments. The matrix may be just 10 years away. You may be overjoyed or terrified, but don't be surprised. As far as alternatives to WebVR, many developers use the Unity game engine, which has good integration with VR SDKs and devices. The skill set and expertise to develop on Unity is not as ubiquitous among developers as Web development skills. I highly recommend that you check out those technologies and dip your toes in virtual reality.

Posted by Gigi Sayfan on October 18, 2016

Containers are making inroads into the mainstream. Many large organizations and startups deploy their software using containers and many other experiment with the technology or plan to do it. When talking about containers, Docker is the 800-pound gorilla. The recent awareness and popularity of containers for deploying complicated systems (often using micro-services architecture) can be credited in large part to Docker. But, Docker is not the only game in town.

There were a lot of complaints in the community about several aspects of Docker. In particular, it had serious security issues. Others are unhappy with the kitchen sink approach Docker is taking and its tendency to push out half-baked features. CoreOS is one of the harshest critics. CoreOS sees containers as a basic low-level infrastructure components. CoreOS developed a standard for application containers called appc and an implementation called rkt (pronounced rocket). Several large organizations and open-source projects support this effort. In particular, the Kubernetes Juggernaut, that competes with Docker swarm in the container orchestration area, has support for rkt containers. On the technical side, appc and Rkt have some benefits such as simplicity, performance and a clear specification.

It will be very interesting to see how the landscape evolves. Are developers going to stick with the incumbent, yet quickly innovating, Docker or are they going to flock to the supposedly superior newcomer? Are appc and rkt compelling enough for the mainstream developer to switch? I personally intend to dive into appc and rkt and find out for myself. The whole container scene is too young and fast moving to stick with Docker just because it was first.

Thanks for your registration, follow us on our social networks to keep up-to-date