----
OpenDaylight Developer Spotlight: Devin Avery
// OpenDaylight blogs
OpenDaylight accepted seven student interns for the summer of 2014 to work in the community and receive hands-on development experience in SDN. Each intern worked closely with an active OpenDaylight developer as their mentor on a project that suited interest and community need.
This blog series aims to showcase the interns chosen and the projects they actively worked on, the mentors who aided in their professional development and the overall experience of working in an open source community to create a common platform for SDN and NFV.
Devin Avery joined Brocade's SDN team and the OpenDaylight Project in April 2014. As committer on the controller project, Devin is using his seven years of experience developing model based enterprise, MSP and CSP infrastructure monitoring applications (written in java and running in karaf) to help OpenDaylight move from labs into production. Devin current lives in and works out of his New Hampshire home and holds a BS in Computer Science from the University of New Hampshire.
What project in OpenDaylight are you working on? Any new developments to share?
I am a committer on the controller project with a primary focus of encouraging MD-SAL adoption among the community. Using models to represent "things" is a great way to separate business logic from common infrastructure. This creates more time to focus on the business value for our customers. The challenge is figuring out how we can make a model-driven engine that people desire to use. By documenting, refactoring, and refining tutorials, we have made great strides on increasing the usability of MD-SAL APIs. In addition, the weekly MD-SAL calls and email threads continue to offer up many suggestions on how we can continue to improve interactions with our current modeling core.
When and how do you get your best coding done? At night listening to music? In the morning with a cup of coffee?
I get my best coding done in the early morning when I am well rested and alone – there is something peaceful about the quiet of 6 and 7 am. A little Ace of Base or Rob Zombie can also go along way towards helping me focus.
OpenDaylight's first software release debuted in February 2014. What do you think is most important for the project to focus on for Helium and future releases?
There are two things I think OpenDaylight needs to focus on: The first is that we need to consolidate our internal controller platforms (AD-SAL vs. MD-SAL). Having multiple controller platforms only serves to divide our resources and confuse our customers and developers alike. By aligning to a single controller platform we can focus our collective resources and achieve much more than we could as individual groups. As we align to a single controller platform the need for greater collaboration, communication and compromise will only increase. Even though machines are binary (for now), we humans have the luxury of infinite possibilities. It should never be "your way" or "my way," instead it should be "our way". The majority of the time that will result in the best solution for our customers.
My bias for a model-based platform leads me to the second item that is critical for us to work on in the next release. We must come together to define a common, layered, set of reusable models. The best modeling platform in the world will fail if the models it processes are disjoint, chaotic and confusing. There is already evidence of this confusion in our modeling platform today (i.e. topology vs inventory). Unless we take steps to correct and improve our models, both existing and future, we will fail to be successful with our customers. To be effective at defining models we will have to strike a balance between discussion and action. We don't have years, months or even weeks to discuss and debate every nuance of a given model. We need to allow for compromise and accept that we can, and should, redesign models in the future as needs change.
What advice would you give to someone just getting started in an open source project?
The best advice I have is to actively get involved in the community. Find some aspect of the project that is of interest to you and start contributing. Contributing doesn't necessarily have to mean writing code. Documenting functionality is a great way to learn a new product or feature and to introduce yourself to the community. The first thing my colleagues and I did when we joined OpenDaylight is spend a week revising and updating the documentation for the MD-SAL toaster example. Adding unit tests, integration tests, and tutorials are great alternatives to writing new functionality. Any of these options are a great way to immerse yourself in a new community - open or otherwise.
What is the best piece of developer advice you've ever received?
Your code can use simple algorithms but that will make your APIs more complex. Or your code can use complex algorithms, which will result in simpler APIs.
Developers tend to have a very technical way of thinking about and solving problems. Often times the technicality of solution ends up in the API, making it more complex. The best thing you can do is let the customer define the API. That way you know the API will be easy for the customer to use and we can then use that simple API to drive the technical solution. And remember - even internal code and functionality have customers - they just happen to be the consuming developers.
----
Shared via my feedly reader
Sent from my iPhone
No comments:
Post a Comment