Before anything like an Android device or iPhone existed, desktop computers were the battleground for the browser wars. The battle involved billions of dollars invested by a number of companies, all based on the premise that whoever ruled the desktop browser market would own the internet. Today, mobile devices account for nearly half of all website traffic. Back in the 1990s, however, almost all of the action on the web came from desktop machines, and the vast majority of those desktop machines were running some flavor of Microsoft Windows.
In the browser world, the first-mover advantage belonged to Netscape Communications Corporation. They built the Netscape Navigator browser that made the web accessible to millions for the first time. Netscape had more than 80% of the market, but they also had no shortage of competition. IBM had a browser for OS/2. Oracle had the Powerbrowser, a Netscape-compatible product that included something called the Database Markup Language. The real danger to Netscape, of course, came from the company that owned more than 80% of the world’s desktops: Microsoft.
Strategically, Netscape realized that the web needed to move past static web pages to reach its full potential. Even if they were created dynamically by something like a CGI script on the web server, pages didn’t change once they arrived in your browser. If you wanted to see even a slightly modified version of a page, you had to send a request back to the server and wait for a response. For all its sophistication, a web browser felt a lot like a dumb terminal attached to a mainframe. What web developers needed was a programming language that would run in the browser, taking advantage of the processing power of the desktop machine to give users a richer experience.
Welcome back to the final part of this multipart series about deploying modern web applications on Red Hat OpenShift. In the first post, we took a look at how to deploy a modern web application using the fewest commands.
In the second part, we took a deeper look into how the new source-to-image (S2I) web app builder works and how to use it as part of a chained build.
This third and final part will take a look at how you can run your app’s “development workflow” on OpenShift.
Continue reading “Modern web applications on OpenShift: Part 3 — Openshift as a development environment”
JSX is the more elegant way to compose the DOM within React classes, however, it does require an additional compile step, and there is a bit of added complexity when integrating with RequireJS.
Continue reading “Have some CoffeeScript with your React”
What created this need for me personally was the development of Log Reaper  which is a client side approach to parsing log files with no server side upload or processing. Log Reaper identifies and parses log files (of currently accepted types) in a Web Worker, then communicates the structured objects back to the browser where they are further map reduced and visualized.
Today, we’ll share a small victory in our DevOps journey at Red Hat IT. This cross-team collaboration has saved our IT organization some headaches and wasted time. We open-sourced the code, hoping it can help you, too.
The Dev problem, from Sam Van Oort:
Old, pruned git branches are sometimes re-created by accident, making a mess for our developers.
Continue reading “Git Bonsai, or Keeping Your Branches Well Pruned”
Hi, I’m Steve, a member of the Inception team at Red Hat. The Inception team was pulled from different parts of IT to foster DevOps culture in Red Hat. Though we’ve only been a team for a little over a month, we’ve been trying to do some early projects to make everyone’s lives easier.l
We spent quite a bit of time in our early meetings identifying pain points in the current processes. We talked with a few developers, ops folks, noted historical issues and ran with general brain storming. We heard a lot about configuration management, lack of information, redundant and time consuming tasks, and many more of what one expects when asking tech people what pains them.
Of course, Tim (another Incepticon) and I were itching to write some code so once the team identified a common issue for both developers and ops engineers we jumped in head first.
The rest of this post describes our journey from initially trying to implement a simple solution to improve the day-to-day lives of developers, through the technical limitations we experienced along the way, and finally arrives at the empathy for our developers we’ve gained from that experience. We’ll wrap up with a note on how Red Hat Software Collections (announced as GA in September) would’ve simplified our development process.
Continue reading “Feeling Developer Pain”
As you certainly know, DevOps is all the rage these days. While DevOps is many things, some pure “buzz” and some legitimate, we aren’t going to talk about all that. Instead, let’s talk about one small piece of the problem, simplifying the consistency of deployment platforms.
Part of what has made DevOps, and, by extension, Continuous Deployment concepts possible has been the simplification, at least on some vectors, of the modern data center. Starting with virtualization, extending to configuration management and deployment (e.g. satellite and puppet), and finally, the advent of the hybrid cloud, operational functions have become much simpler for the layperson. However, ensuring that your development environment is the same as production is still not a completely solved problem.
Continue reading “Leveraging RHSCL for DevOps”
Earlier this year we held an event called Red Hat Developer Exchange which is a one day conference for developers who leverage any of the Red Hat products. We had a great bunch of sessions but, one of the ones I did was about “Secure Development Practices.” What does that mean, you might ask?
Continue reading “Secure Development Practices”
This article will show you how to use two software collections of RHSCL 1.0 Beta for cutting edge development. We will create a Django 1.5 application (running on Python 3.3), that will use PostgreSQL 9.2 as a database.
Continue reading Using RHSCL: Django on Python 3 with PostgreSQL
You may have seen references to “software collections” in this blog, but this is different. “Red Hat Software Collections”, now in beta for the first time, is a collection of refreshed and supported web/dynamic languages and databases for Red Hat Enterprise Linux. Now you can have two versions of software on one OS, or refresh these languages and databases more frequently. See this list below!
Continue reading Red Hat Software Collections 1.0 Beta Now Available