How To Run Quake 2 For Free on OpenShift

We've been adding a lot of great features to OpenShift lately but we've also been working on some cool demos behind the scenes. The OpenShift operations team loves this cloud stuff and we love pushing it to its limits. We've also got a few gamers on hand, so with that in mind we worked to get quake2-gwt up and running on OpenShift. This version of Quake 2 runs in your web browser.

This is one of those ah-hah moments for some people who haven't seen much HTML5 content before. Everything in the demo is running either on OpenShift or in your browser.

Let's get started!

To get started the first thing you need is to get an OpenShift account at http://openshift.redhat.com/. Then create a jbossas-7 app either in the web interface or via the command-line tools:

$ rhc app create -a quake2 -t jbossas-7

This will have created a simple "hello-world" jbossas-7 application. These next steps will override that repo with the quake2 quickstart repo that has already been prepared.

$ cd quake2

$ git remote add upstream -m master \

git://github.com/wshearn/openshift-quickstart-quake2.git

$ git pull -s recursive -X theirs upstream master

Last to do is a push:

$ git push

Read more: OpenShift

QR: 

Posted via email from Jasper-net

"JavaScript: it’s not just for browsers anymore... One developer’s journey from C# to JavaScript"

Why JavaScript, why now?

Earlier this year I left the comfortable world of XAML and WPF behind and began developing almost exclusively in JavaScript. My daily focus has also switched from developing desktop applications to Single Page Applications (SPAs) using ASP.NET MVC and KnockoutJS: but, as we’ll see, JavaScript does not restrict me to web development.

I was discussing this change of direction with a good friend of mine and he asked whether that wasn’t a little extreme. I suppose it would certainly seem that way, especially for someone who has made a name for himself in the XAML community. I would not make such a drastic change lightly. I thought long and hard before making the move and, after twelve years in one place, I even changed jobs to facilitate the effort. I thought it would be worthwhile to share some of my reasoning behind this latest change of direction.

Not long after I had made the switch, I had the pleasure of hearing Douglas Crockford speak at a conference. Mr. Crockford, as most people insisted on calling him, is the author of “JavaScript the Good Parts” (by O’Reilly), JSLint, and JSON, and is a member of the ECMAScript Standards body. I’ll never forget the quote he made that “JavaScript is tragically important”. My one line take on this is that, for all its faults and foibles, JavaScript cannot be ignored.

JavaScript is ubiquitous. Every PC, Mac, laptop, tablet, slate, netbook, ultrabook, and smart phone that is out there in the wild today runs JavaScript. It’s already there, it’s already installed, and it’s amazingly consistent across the different operating systems and devices. It took a while for me to realize that JavaScript comes closer than either Java or .NET to fulfilling the old promise of “write once run anywhere”. If for no other reason than universal reach, JavaScript is a serious language.

The ubiquitous nature of JavaScript means that the pain of framework and platform deployment is a thing of the past. The browser is the platform, the Internet is the deployment model. Thanks to the browser manufacturers there are no frameworks to deploy, no installers to execute, no administrator permissions issues, and virtually no versioning issues. Regardless of your personal feelings about JavaScript it is undoubtedly the single most important computer language in the world today.

Read more: Greg's Cool [Insert Clever Name] of the Day

Read more: A Sudden Move: One developer’s journey from C# to JavaScript

QR: 

Posted via email from Jasper-net

Как мы читаем код

В рамках исследований движений глаза Майк Хансен и Эрик Холк провели любопытный эксперимент. Используя айтрекер Tobii TX300 частотой 300 Гц, они сравнили поведение глаз опытного и начинающей программистов при чтении кода программы Python, вывод которой являлся вопросом поставленной задачи.

В результате съемки данных для «новичка» было получено следующее видео.

Read more: Habrahabr.ru

QR: 

Posted via email from Jasper-net

Free virtual test devices

Introduction 

When testing Android applications (or any mobile device applications for that matter) nothing beats running it on an actual, physical device whilst connected to your favorite IDE, I think most developers would agree with this. Physical devices, however, cost money and for a hobby developer the price can sometimes become an insurmountable obstacle.

Background 

Having finally released my first Android app into the wild it only took someone a few minutes to find the first bug that only exist on certain devices, this tip outlines the steps I took to find and fix it without having to buy a new device.   

The bug 

The bug I had in my application was causing the screen to go completely black for a brief, 2 seconds, period, it wasn't happening on any of the four different devices I have available for testing and I had never seen it using the emulator either.

The actual code that caused the bug was this line;

canvas.saveLayerAlpha(

     0, 

     0, 

     canvas.getWidth(), 

     canvas.getHeight(), 

     (int)(Math.min(1.0f, alpha) * 255.0f), 

     Canvas.HAS_ALPHA_LAYER_SAVE_FLAG);

...

...

4. Samsung RTL (remote test lab)

This step is the cool step, this step is my tip! 

Having failed to prove and resolve debug using my normal plan of attack I stumbled across Samsung Remote Test Lab, this is a series of devices that you can get remote access to using a Java Web Start application. 

You can find the test lab here; http://developer.samsung.com/remotetestlab/ 

To get access you'll need a developer account, which is free, and some credits, which are also free. Fifteen minutes of time on a device costs 1 credit and you get 20 credits per day to use. 

Read more: Codeproject

QR: 

Posted via email from Jasper-net