One of our goals every year with SATURN is to create a solid technical program that is informative, engaging, and lasting. When evaluating proposals for the program, the review committee uses the following guidelines to help decide whether a proposal is a good match for this year’s conference. In these guidelines, the term “session” is used generically to describe any talks, workshops, tutorials, and so on in the conference program.
Informative sessions share meaningful insights with lessons that attendees will be able to apply directly with their teams after the conference.
- Is the information proposed relevant to one of the topic themes in this year’s conference?
- Are there succinct lessons supported by real-world examples, research, or direct experience?
- Is the topic of broad or general interest?
- Can the lessons be applied beyond small sub-communities of practice?
sessions create an active learning environment that promotes information retention and generally gets attendees excited about the topics discussed.
The SEI Architecture Technology User Network (SATURN) Conference 2015 will be held at the Lord Baltimore Hotel in Baltimore, Maryland, April 27--30, 2015. We are pleased to announce that the co-technical chairs of SATURN 2015 will be George Fairbanks of Google and Michael Keeling of IBM. Based on your feedback in the hallways in Portland and from post-conference surveys, George, Michael, and the rest of the SATURN technical committee have designed SATURN 2015 to better meet your needs in a practitioner-oriented technical conference.
The SATURN 2015 Call for Submissions is now open. As described in the Call, we will immediately begin a rolling-acceptance process for proposal submissions, so submit early to get feedback and improve your chances.
What’s New for 2015
Since James Lewis and Martin Fowler published their article on Microservices in March 2014, the microservices architecture pattern has been the subject of much debate in the blogosphere: Is there a good definition for it (or not), is it another form of SOA (or not), is it an answer to the monolith (or not), is it a fad or the next big thing? The following blog posts contribute to the discussion on some of these topics.
Failing at Microservices: Please avoid our mistakes!: Richard Clayton’s Unrepentant Thoughts on Software and Management recently included a blog post about his team’s attempt to implement a microservice architecture, four reasons why it failed, and some recommendations for avoiding these problems.
Microservices for the Grumpy Neckbeard: Chris Stucchio discusses what he sees as the two camps of the debate about microservices, the hipsters who see their many benefits and the neckbeards who are more suspicious, and describes an architecture that may serve to bring the two camps together.
By Jørn Ølmheim and Harald Wesenberg Statoil ASA We were fortunate enough to be able to participate at SATURN 2014. For Jørn, this was his first time at SATURN, while for Harald it was the fourth SATURN conference. As always, we knew that the quality of the conference content is high, and we were looking forward to a fun week with learning new and interesting ideas from other practitioners. In this group of excellent presentations and tutorials there were many that stood out, but to us George Fairbanks' talk on teaching architecture was definitely one of the greatest. Many of the more experienced participants at the conference recognized George's experiences of trying to teach the importance of architecture to the junior team members with varying degree of success, so we were well motivated for a discussion about how this can be done better. Many of us recognize the challenges of motivation and lack of commitment both from your peers and the company to spend time on such activities.
DevOps: Definitions and Misconceptions
This month, Ben Kepes at Forbes reported on ScriptRock’s efforts to raise funding from investors to expand their operations in “To Help DevOps-ify The World.” Kepes opens with an explanation of how ScriptRock must first differentiate its product and services from vendors selling “DevOps in a box.” More agile software development in less time, however, may not fit neatly in that box. Here are some links to definitions of DevOps that include components that exist outside of the box.
Defining DevOps Might Be Harder Than Defining Design: In the Under Development podcast series, Bill Higgins and Michael Coté explain DevOps, metrics, and “the processes used by designers vs. software developers vs. management consultants vs. wedding planners.”
Stephany Bellomo of the SEI will be speaking at the Unicom DevOps Chicago Summit on September 18, 2014 on "Design Implications of DevOps." Here is an abstract of Stephany's talk:
Wearable computing is coming to the masses in the forms of fitness, gaming, and medical devices while non-consumer markets such as defense and aerospace continue to push for advanced wearable technologies to enhance safety, mobility, and efficiency in places most people will never go. Here are some recent examples of the state-of-the-art technology in wearable computing and then some that, with a little tech-know-how, you can make at home:
Intel Battles Parkinson’s Disease with Big Data and Wearable Tech: Mike Wheatley at Silicon Angle describes a new project at Intel, in which a Big Data analytics platform combined with a wearable device will produce a better record of symptoms experienced by Parkinson’s patients .
The Inside Story of the Oculus Rift: Peter Rubin at Wired reports that, with the Rift, Oculus hacks the visual cortex to make a virtual-reality headset that doesn’t cause “cold sweat syndrome.”
The Cardboard Project: Google Developers show how you can build your own basic VR headset with a smartphone and some basic items that you can get at the hardware store.
Raspberry Pi GPS Helmet Cam: Martin O’Hanlon at Stuff About Code used his Raspberry Pi-based car cam to develop a helmet cam, takes it snowboarding, and record data about speed, altitude, and temperature.
Test-Driven Development: Dead or Alive?
Back in the Spring, a single blog post sparked a debate that on the surface seems absurd. Is TDD actually useful and still relevant? The discourse that followed and is still following this discussion is spectacular and spans Twitter, blogs, and a series of video debates. We thank Michael Keeling of Never Let Down for bringing this debate to our attention.
TDD is dead. Long live testing.: David Heinemeier Hansson, the creator of Ruby on Rails, discusses the death of test-driven development and the need to transition from unit testing to system testing.
Is TDD Dead?: Martin Fowler engages Hansson and Kent Beck in a series of video conversations on the topic of test-driven development and its impact on software design, including confidence, test-induced design damage, and cost.