Looking for DevNation 2017 CFP
You may have seen (or maybe missed) that in 2017, DevNation will be folded into Red Hat Summit 2017.
Continue reading Looking for DevNation 2017 CFP
Tag: DevNation
Red Hat Summit, DevNation, and an Application Development call for papers
Red Hat Summit has always catered to multiple user roles and this year will be no different. What will be different in 2017 is an expanded focus on professional application developers much like DevNation has done in recent years. As such, we will not be hosting a separate DevNation event alongside Summit 2017. Instead, Summit will include more advanced Application Development sessions, CodeStarters, labs, birds of a feathers, a new “Developer Zone” in the expo area, and much more.
What does this mean for you?
- Attendees: Every attendee can now access everything that’s developer-related and at no extra cost.
- Speakers: You now have a larger audience to share your application development story, plus you and co-presenters get access to the entire Summit event.
Speakers: submit your Application Development proposals today!
Continue reading “Red Hat Summit, DevNation, and an Application Development call for papers”
Help, I accidentally hit CTRL-ALT-F8 on my Red Hat Enterprise LInux VM on Hyper-V!
Last week, I attended a DevNation talk, “Getting Started with C# on Red Hat Enterprise Linux and OpenShift”, given by Scott Hunter from Microsoft. The first thing Scott asked was, “Does anyone know how to recover from hitting CTRL-ALT-F8 in Red Hat Enterprise Linux?”
Continue reading Help, I accidentally hit CTRL-ALT-F8 on my Red Hat Enterprise LInux VM on Hyper-V!
Push it Real Good: Continuous Delivery for the people at the push of a button and repo
The Problem
Several months back, our emerging Developer Programs engineering team assembled during the last breaths of Brno’s Czech winter and dedicated a full day towards a deceptively complex task:
Be a user. Assemble in groups and, using a technology stack of your choosing, conceive of and create an application to be presented to the full team in 6 hours.
Keep in mind that I hold my colleagues in extremely high regard; they’re capable, creative, and experienced. Surely churning out a greenfield demo application would be a laughable exercise done by lunch affording us the rest of the afternoon to take in local culture (read: Czech beer).
So we started to break down the tasks and assign people to ’em:
- Bootstrap the application codebase
- Provision a CI environment to build and test
- Stand up a deployment environment
- Hook everything together so we’re all looking at the same thing through the dev cycle
We wanted the same conceptual infrastructure we use in delivering Red Hat products and our open source projects – authoritative systems and Continuous Delivery.
And therein lies the problem. Of the 6 hours spent on this exercise, I noted that every team spent over four and a half hours getting themselves set up and hacked furiously on their real job – the application – in the final sprints.
But that’s not the real problem.
The real problem is that users, all across the globe, have the problem.
And in this moment, it crystallized that it was now our mission to fix this.
Our industry has given developers wonderful tooling, frameworks, and runtimes. With containers, we even have standardized deployment. And by the way, we require that you load your own containers onto the boat.
We’re missing a unified, cohesive story which brings applications out of the development environment and into service.
Continue reading “Push it Real Good: Continuous Delivery for the people at the push of a button and repo”
DevNation Live Blog: CDK 2.0: Docker, Kubernetes, and OSE on your desk
As a systems engineer, I enjoy building deploying production and pre-production services. These production services tend to be built at scale in a highly redundant architecture. The problem has always been how do we give developers a sandbox that matches production in all the ways that matters– but without the pain (and love), overhead, compute and networks resources actual production environments require. Moreover, how does one snapshot this environment so it can be recreated at will. This has been a holy grail in IT for a while. While there have many, many attempts at solving this problem, they all seem to have pitfalls and don’t really serve the purpose.
Enter the CDK…
An exciting development in this space is the Red Hat Container Development Kit. Langdon White, Platform Architect at Red Hat gave his presentation on using CDK 2.0, which is a container CDK based on Vagrant, Docker, Kubernetes, and OpenShift. It also has Eclipse integration… basically, everything someone needs to build production-quality applications for use on OpenShift.
Langdon starts with decomposition being a major driving factor in today’s software development world. Docker gives us a major step-forward in decomposition and helps with the separation between system errata updates and what the application actually requires. The CDK will help in your journey to re-architect your applications and “sprinkle in some devops” (one of my favorite new phrases from the DevNation keynote).
The CDK runs on Windows, Mac and Linux (of course). It ships with Vagrant files allowing you to easily execute the CDK VMs without having to install everything yourself. The CDK Eclipse has plugin integration for Vagrant, allowing one to run the VMs from within Eclipse, which is kind of cool. From there you can start the OpenShift Local VM for deploying your code, mimicking a production push.
Still within Eclipse, you can define your Dockerfile, giving your container all the dependencies your application requires, including the base image. Of course, you can define multiple ones of each tier of your application, all without leaving your development environment.
Continue reading “DevNation Live Blog: CDK 2.0: Docker, Kubernetes, and OSE on your desk”
DevNation 2016 Keynote Recap
This morning at DevNation we talked about the past and the future. A past that helped create some of the fundamental building blocks of application development and a future where we can reimagine them all.
As part of the open source community, Red Hat has worked with countless individuals and organizations over the past 20+ years to solve some of the biggest problems and provide technology that many businesses rely on today. It was great to have so many of those people in the audience and online today during DevNation and we thanked them for the years of collaboration and support.
One of the biggest contributions that Red Hat and the community have made to enterprise software is the evolution of the Java ecosystem. Today, we were pleased to announce that we will be working with IBM, Tomitribe and others to continue to evolve enterprise Java so that it can meet the demands of modern app development and become the runtime environment for microservices. You can find more details and information about the announcement here on the Red Hat Developer blog.
Today, we also reaffirmed our commitment to the Eclipse platform with the release of Red Hat JBoss Developer Studio 10. This release coincides with the release of Eclipse Neon, the latest version of the Eclipse IDE. With the latest version you’ll be able to take advantage of Neon’s new features as well as support for Red Hat JBoss Enterprise Application Platform 7 (JBoss EAP) and Red Hat Container Development Kit (CDK) CDK 2.1. The latest version is available here as part of the Red Hat Developer program.
Continue reading “DevNation 2016 Keynote Recap”
A common interface for building developer tools
“There is already a command line for it, why can’t my favorite editor support this language?” As a developer, you’re probably familiar with this sentiment, and in reality there has never been a better time to be a software developer.
Developers have access to a growing list of languages, frameworks, libraries, and technologies that can help them solve the problems they are tasked to tackle. However, the abundance of choices often hinders the ability of Integrated Development Environments (IDEs) and code editors to support such an abundance of choice. As a result, developers often choose to use multiple IDEs and editors for building their solutions, in order to get access to best IDE support.
IDEs are frequently architected to have direct access to the tools related to the technology for which they were designed — for programming languages this often means that IDE has access to parsers, compilers and an in memory presentation of the developed code usually in the form of an Abstract Syntax Tree (AST). This approach also means that IDE developers need to create and maintain these tools.
As an example, Eclipse Java Development Tools (JDT) project provides a compiler for Java and a Java editor which in turn uses the AST generated to implement features like code assist, outlines, refactoring, etc.
Another approach is to define an API that the IDE will invoke to provide language features. In this architecture, the IDE has no real knowledge of the programming language and instead relies on the implementations of the interface.
We think this approach has a couple of advantages: first, it allows the interfaces to be implemented by the communities that create the technology, and so know it best; second, it frees up IDE developers for what they know best — we think this results in better IDEs and editors.
Unfortunately, we do not get the full benefits of the approach because there are as many of such interfaces defined as there are editors and IDEs.
Continue reading “A common interface for building developer tools”